No matter how the messages were deleted. When the *DLT data
authority is removed from the *MSGQ object for the user, then the F11
and both of F13 and F16 are disabled for that user; i.e. CPD2419 "Not
authorized to delete messages." would be the effect for each of those
attempts to delete messages.
And while the missing *DLT data authority also would have prevented
the CHGMSGQ DLVRY(*BREAK) request due to CPF2408 "Not authorized to
message queue QSYSOPR.", a CLP that adopted authority to allow the
CHGMSGQ will have no implications for the function of the "Display
Messages" feature. When presented via the explicit command request to
DSPMSG or when presented implicitly by an event to present a message in
break mode, the "Display Messages" feature is not activated with the CLP
that did the adoption, that CLP will not be in the program stack, so the
user can not delete messages from the queue. The adopted authority
would be in effect only for the CHGMSGQ request.
Regards, Chuck
On 12 Mar 2013 07:18, rob@xxxxxxxxx wrote:
We don't know she cleared QSYSOPR. F13? F16? CLRMSGQ?
If she used F13 or F16 then cute wrappers for DSPMSG aren't going to
cut it. <<SNIP>>
Michael Schutte on 03/12/2013 09:39 AM wrote:
Create a CL for her to call instead.
On Tue, Mar 12, 2013 at 9:37 AM, Jeff Crosby wrote:
Every day our billing clerk serves as the de facto system
operator. When she comes in she does a CHGMSGQ QSYSOPR *BREAK
SEV(30) so that any QSYSOPR messages break to her.
Today she accidentally cleared QSYSOPR. Not a catastrophe but we
don't want repeats.
A google search indicated that removing the *DLT authority would
prevent her from deleting messages or clearing the queue. Great,
except she then was not allowed to do the CHGMSGQ QSYSOPR *BREAK
SEV(30). Catch 22! <<SNIP>
