Break-handler program on QSYSOPR

[Anthony LaMark]

Hi All,

I have a break-handler program on the QSYSOPR message queue. Everything
works exactly as advertised except that the operators are complaining that
they can not interact with the QSYSOPR from the green-screen 5250 using
DSPMSG. Stated differently, when I issue the CHGMSGQ command to associated
the break-handler program with the QSYSOPR message queue, CHGMSGQ obtains an
exclusive lock on the message queue. The break-handler program does not
manipulate or remove the messages, it only reads from the queue. Is it
possible to have a break-handler program that does not obtain an exclusive
lock? Here is the CHGMSGQ command:
CHGMSGQ MSGQ(QSYSOPR) DLVRY(*BREAK) PGM(LIB/PGM *ALWRPY) SEV(10)

Thanks in advance,
Tony

[Dan Hicks]

IIRC, QSYSMSG message queue was invented to address this problem.
It mirrors some of the messages in QSYSOPR, but I don't recall how
it was all supposed to work.

--
Dan Hicks
If everything is coming your way, you're in the wrong lane.

[Anthony LaMark]

Hi Dan,
I have read up on QSYSMSG but it does not get any application messages so it
is not sufficient for the task I have implemented. Thanks for responding
though...any other thoughts?

"Dan Hicks" <danh...@ieee.org> wrote in message
news:3FE62825...@ieee.org...

[Dan Hicks]

I'm way over my head here (I'm Java, and before that DataBase), but
you might be able to do something with ADDRPYMSG (or whatever it is).

--
Dan Hicks
There are only two lasting bequests we can hope to give our
children. One of these is roots, the other, wings. --Hodding Carter

[Scott]

The ROBOT/CONSOLE product by Helpsystems used to have this problem
years ago, but they found some way around it.

Instead of using a break handler, is there an API you could use to
read the messages and possibly avoid the lock?

Scott Lindstrom

[Drew Dekreon]

well, instead of installing a handler on qsysopr, what about having a
job running in batch that does a rcvmsg on qsysopr with a remove message
*no. The operators would be unaffected and you could still peek at the
messages coming in.

[QMAGIC]

You almost have it.

Look below.
Break handling attributes: PGM
Break handling program . . . . > PGM
Library . . . . . . . . . . > LIB
Allow other jobs to reply . . > *ALWRPY

*NOALWRPY:
When the message queue is in *BREAK mode with a brea
handling program other than *DSPMSG specified, other
jobs can display the message queue, but cannot reply
to inquiry messages on the message queue.

*ALWRPY:
When the message queue is in *BREAK mode with a break
handling program other than *DSPMSG specified, other
jobs can reply to inquiry messages on the message
queue.

By setting the "Allow other jobs to reply" to "*ALWRPY" should (It
works for me.) allow the operators to interact with the messages as
well.

Hope this helps.
Dan

"Anthony LaMark" <ant...@excsoftware.com> wrote in message news:<cXmFb.34617$pY.30269@fed1read04>...

[Anthony LaMark]

Hi Dan,

First off, thank you for responding. I am still unclear as to how to solve
the problem since what you have described, appears to be what I am doing.
The only thing that I don't understand is "When the message queue is in
*BREAK mode with a break handling program other than *DSPMSG specified...".
What indicates that the break-handling program has *DSPMSG specified and
what does that mean and (most importanly) how to I specify this attribute
for the CL break-handling program?

Thanks again,
Tony

"QMAGIC" <dann...@cox.net> wrote in message
news:b2431aa9.03122...@posting.google.com...

[Anthony LaMark]

Hi Scott,

Thanks for the input. Is there an API I could use? I will have to research
this in more depth but in my initial research, I did not see anything like
this. I am leaning towards the fact that I might have to code something up
in ML (assembler)...which is another issue since IBM does not provide much
information for programmers who want to program in ML on the AS400 system.
This is odd since on MVS (z/OS), there is a ton of manuals and information.

Thanks,
Tony

"Scott" <scl...@yahoo.com> wrote in message
news:6d85b916.03122...@posting.google.com...

[Anthony LaMark]

Hi Drew,

Thanks for the suggestion but that is exactly what my break-handler program
does (see the break-handler example documented by IBM) right now.

Thanks again,
Tony

"Drew Dekreon" <drew_dekreonATchugachelectricDOTcom> wrote in message
news:vuev9v2...@corp.supernews.com...

[QMAGIC]

Anthony,

When I read your first message I understood that the break message
program was working and the only issue was that the operators were not
able to answer messages manually. This should be correctable by
changing the "Allow other jobs to reply" to "*ALWRPY". But I guess
I've missed something. If you like to send me more detail or perhaps
the code your trying to get to work I'll load it on my system at home
and take a look at. I'm on V5r1m0.

Dannelson2...@cox.net Please remove ".nojunkmail".

Dan

"Anthony LaMark" <ant...@excsoftware.com> wrote in message news:<sPHHb.85365$pY.60775@fed1read04>...

[ccrump1222]

Hi, folks.

Question: what are you montoring for?

I wrote a Control Language monitor program to catch any critical messages related to ASP full, disk
failures, and user profiles disabled, and I'm not using the QSYSOPR message queue.

Interested?

CJ

[John]

Only just noticed this thread so hopefully I'm not missing anything.
I'm not sure how the operators accessed the queue before but is there a
reason they can't issue the CHGMSGQ instruction (with the break handling
program mentioned) themselves? It could be added in an initial program to
their profile...