Had a situation pop up where our system operator at one of our branches
attempted to do the quarterly "SAVE 21", which he has done successfully in the
past, but this time it failed at the point where it does the
CHGMSGQ MSGQ(QSYSOPR) DLVRY(*BREAK) SEV(99)
During my initial attempt to run SAVE 21 to test his problem, I was stopped
right at the menu option because I did not have the two special authorities
required to run the command (forget what they are right now). The system
operator *did* have these two authorities and, so, he got past the menu and
started the SAVE 21 processing.
It hit me as strange that the application choked on the CHGMSGQ even though he
had the two required special authorities. I dug a little deeper and
discovered that our security officer had removed the 'update' & 'delete' Read
authorities for *PUBLIC from the QSYSOPR message queue object. My solution
was to add the system operator's user ID to the authority list with *CHAN GE
Next time he does a SAVE 21, he'll get past the point where he was stopped
before. But what other objects have had their authorities changed? Maybe
ENDSBS? Maybe other functions?
Is this the scenario where I need to consider using adopted authority? In
essence, let anyone who has access to a specific "Save Everything" menu
option, regardless of their special authorities, be able to run that option
which, in turn, effectively performs a SAVE 21 without running into *any*
authority problems? And in this way, could I then remove the system
operator's *CHANGE authority from the QSYSOPR message queue (and move him back
into the *PUBLIC group), so that he cannot issue CHGMSGQ QSYSOPR the from the
So much to learn.
Dan Bale says "Ban Dale!"
IT - AS/400
248-362-4400 Ext. 4952
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: firstname.lastname@example.org
This mailing list archive is Copyright 1997-2020 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