|
YIKES! This is not a good idea! > > Your best bet would be to specify *PUBLIC *EXCLUDE on the message queue > QSYSOPR. You should also be aware that QSYSOPR is cleared down every time > you IPL, so it may not necessarily be a user accidentally hitting F13 or > F16. If you remove anyone's authority to write (*ADD) messages to QSYSOPR, you run the risk of getting your system wrapped into a tight little ball! Any batch job that generates an error message will submit that message to the QSYSOPR message queue under the authority of the *CURRENT user of the batch job. If that user does not have enough authority to send a message to the QSYSOPR message queue, and exception is generated and an error message will be sent to the QSYSOPR message queue (again), which will cause another exception, and another error message, and round and round you go. If you want to remove a user's authority answer messages in the QSYSOPR message queue you can either lock the message queue to an active job (like the console) or you can remove the user's *READ access to the queue (I know, it's counter intuitive) but make sure that the user still has *OPR and *ADD authority. When you answer a message in a message queue, you are really sending a new message (hence the *ADD) to the message queue that is a reply to an existing message (not a *CHANGE as you might guess). So removing the *READ capability will get you closest to the results you seek. jte
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.