msgq break handling program
Steve Richter
called recursively?
chgmsgq msgq(qsysopr) dlvry(*break) pgm(mypgm)
When a message arrives in the message queue my break handling program
is called. The issue I am having is when a 2nd message arrives in the
message queue before the break handling program has returned from
handling the first message, the 2nd message does not break into the
break handling program.
Is this clear? Am I correct that the message queue break handling
program has to return before the system calls the break handler program
with the next message?
thanks,
-Steve
Jonathan Bailey
I also found that behaviour. I think that the msgq knows the break
handling program is already active so even if the program is
recursive/re-entrant it will not be called. It dosnt always seem to be
called when the user is displaying messages including program messages
like the 'enter CDIR' type. I use a remote screen view program which
uses this method to interrupt the users job & grab their screen.
The other alternative I have considered is strsrvjob then trcjob with
an exit program specified. It works OK on a 1 off basis (eg a 1 line cl
pgm with rollback as the command) but the exit program is called
multiple times & you have to take that into account. The advantage is
that a batch job with no workstation message queue can also be
targetted.
Jonathan.
Steve Richter
Jonathan Bailey wrote:
> Steve Richter wrote:
> > Is it a rule that a message queue break handling program cannot be
> > called recursively?
> > chgmsgq msgq(qsysopr) dlvry(*break) pgm(mypgm)
> >
> > When a message arrives in the message queue my break handling program
> > is called. The issue I am having is when a 2nd message arrives in the
> > message queue before the break handling program has returned from
> > handling the first message, the 2nd message does not break into the
> > break handling program.
> >
> > Is this clear? Am I correct that the message queue break handling
> > program has to return before the system calls the break handler program
> > with the next message?
> >
> > thanks,
> >
> > -Steve
>
> I also found that behaviour. I think that the msgq knows the break
> handling program is already active so even if the program is
> recursive/re-entrant it will not be called.
that is the behavior I see also. The system appears to call the break
handler for every message in the queue, regardless of when the message
arrives in the queue.
What I am trying to do is mimic the behavior of the QSYSOPR message
queue when it is in break mode, with the addition of automated handling
of some of the messages. The problem is that when the break handler
calls my DSPMSG equivalent program to display the contents of the
message queue, the break handler does not get called again until the
message queue display program exits.
To get around this I am spawning a 2nd job which will run the break
handler code. Then I have a 2nd message queue that is used to break
into the interactive job and display the just arrived QSYSOPR messages.
A bit more code than I had planned for...
-Steve
Jonathan Bailey
I dont think I studied it so well as you - I imagined some messages did
not lead to the break program running.
I think its behaviour makes som sense though. If you had so many
messages the break handler might never complete before the next message
arrives and so at th end of the day just as everyone leaves the final
message will be processed & appear on the 2nd users screen, followed by
the penultimate message & so on leaving the 1st message to come out
last. Or am I just being a bit pessimistic? I think you would get some
swapping of messages if it was allowed to happen. Maybe you could try
making the 1st instruction of the handler could reset the message Q to
be in break mode & point to the correct program & see if this overrides
its waiting.
Jonathan
scot...@cox.net
Have you looked into using the System Reply list for automated message
handling? This is surely preferable to the gyrations of spawning batch
jobs to pre-process messages.
Also you should take especial care when you muck around with the
QSYSOPR message queue you can serverely impact your system if you make
a mistake.
Steve Richter
I want replies dependent on the job that is sending the message and
also the text content of the message itself.
> Also you should take especial care when you muck around with the
> QSYSOPR message queue you can serverely impact your system if you make
> a mistake.
How so? I assume the system writes all messages to the history log no
matter what the qsysopr message queue break handler does. Also, when
you:
chgmsgq qsysopr *break pgm(yourpgm *ALWRPY)
you can use the 2nd element of the PGM parm to specify users can still
manually reply to messages in the queue.
-Steve
scot...@cox.net
handling program for the QSYSOPR message queue.
However, since you have decided to go with a batch job, why not make
that batch job simply poll QSYSOPR every 30 seconds or so and use
RCVMSG to process any messages that have arrived in queue since the
last poll cycle
Steve Richter
scot...@cox.net wrote:
> The command help for CHGMSGQ says specifically to not assign a break
> handling program for the QSYSOPR message queue.
that seems to be overly restrictive wording on the part of IBM.
Regardless of what is done by the msgq break handler, you can still
dspmsg qsysopr to display and respond to messages in the qsysopr msgq.
What you lose is ability to break the qsysopr messages on the display.
There are many shops that dont have someone monitoring the message
queue, so I dont see the reason for high concern. Anyway, I have
written my own version of DSPMSG QSYSOPR to break and display the
messages to the operator.
>
> However, since you have decided to go with a batch job, why not make
> that batch job simply poll QSYSOPR every 30 seconds or so and use
> RCVMSG to process any messages that have arrived in queue since the
> last poll cycle.
because I only want the messages that are not automatically responded
to to break on the display in the computer room for the operator to
respond to. If an *inq message breaks on the qsysopr message queue the
operator will assume a response is needed. But if the background job is
responding every interval to some messages things could ge confusing.
-Steve
gb
> > The command help for CHGMSGQ says specifically to not assign a break
> > handling program for the QSYSOPR message queue.
>
> that seems to be overly restrictive wording on the part of IBM.
or perhaps IBM knew that it wasn't going to be that easy to do it - as you
are now finding out... ;-)
> because I only want the messages that are not automatically responded
> to to break on the display in the computer room for the operator to
> respond to. If an *inq message breaks on the qsysopr message queue the
> operator will assume a response is needed. But if the background job is
> responding every interval to some messages things could ge confusing.
So, why not have a second message queue (QSYSOPR2) also in break mode in the
QSYSOPR job. In your break handing program, pass any messages that need
attention to the QSYSOPR2 queue. In your break handling program, loop around
before returning and read any messages that have arrived in the meantime.
This (should) hopefully get around the not-being-called-if-already-active
problem and the operator will still respond to break messages in his/her
usual way.
HTH
GB
Steve Richter
I like that idea. The only problem is retaining the SENDER info in the
messages moved from one message queue to another. When you press F1 to
display the message in the queue I want to see the job the message was
sent from. There is also the issue of directing inquiry message
replies back to the original sender.
-Steve