Re: QSYSOPR MSGs

Thanks Patrik, Rob

I failed to mention that the user should receive both QSYSOPR MSGs
AND his own MSGs.

I think that issuing CHGUSRPRF USRPRF(UserA) MSGQ(QSYSOPR)
will alienate the user from his/her own MSGs.

Right?


Gad

from: Rob Berendt <robertowenberendt@xxxxxxxxx>
subject: Re: QSYSOPR MSGs

Options include:

User permanent
CHGUSRPRF USRPRF(SAMPLE) MSGQ(QSYSOPR) DLVRY(*NOTIFY)

Job level:
CHGMSGQ MSGQ(QSYSOPR) DLVRY(*NOTIFY)

Either could use *BREAK instead of *NOTIFY. Experience has told me those
users who insisted on *BREAK soon stop using that session because it's
irritating as it keeps interrupting their work. Now they get no
notification in their current session. But heaven help you if you ask

them

if you'd rather you change them to just *NOTIFY. Odd, but true.

Other options include a message monitoring solution which sends them an
email. Commercial solutions are available which allow you to taylor it a
bit more based on severity, message content, etc. You can roll your own

if

you'd rather.


On Tue, May 28, 2024 at 12:58?AM Gad Miron <gadmiron@xxxxxxxxx> wrote:

Hello guys

Is there a way to have a user receive QSYSOPR MSGs?
(setting the user class to *SYSOPR does not do the trick)


TIA
Gad

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.