Thorbjørn Ravn Andersen wrote:
I am looking at making our web interface be more responsive when a
job goes in message waiting (which has been discussed before).
I cannot locate information about the proper way to send a reply
message to the job in MSGW from Java, so the operator does not need
to log into a green screen and locate the job and press 7, or see all
by selecting 8 from the main menu to see those in QSYSOPR. Any
suggestions about how to tackle this? Should I look in the QSYSOPR
message queue to see or some other magical way?
Presumably already known, includes that SNDRPY is available from:
The QUSRJOBI in v6r1 is finally given the support that has been
available in QSPRWRTI for many releases; i.e. the message queue name &
library, and the message key. I do not recall if that information is
then used first in QMHRCVM and then QMHSNDRM, or only the latter.
Regardless, reference the following message thread and API documentation
for more information about this capability:
Note: the message thread of the first link above, has posts
describing how [best] to get WRKACTJOB to show the MSGW jobs.
Since v5r3, using the inquiry message exit point, an exit program
registered for QIBM_QMH_REPLY_INQ may be an option. That exit combined
with either Default Reply or System Reply List established for the
Inquiry Message Reply handling for the job, would allow the exit to set
the desired reply value. This may not be desirable, as it affects all
inquiries [and notify messages, which mostly should be left alone], but
the logic can limit action to specific named jobs.
For releases prior to IBM i 6.1, some message APIs may assist.
That the inquiry message [for which a reply message is being awaited]
would be in QSYSOPR versus some other message queue, is an assumption.
The message wait action could be against any *MSGQ; or the *EXT message
queue for an interactive job. An inquiry message that is in QSYSOPR may
be able to be _inferred_ to be /the message/ effecting the MSGW, when
the inquiry message is unanswered [next message not a reply.?] and the
/sender/ information from that message matches the job in MSGW status.
The *SYSOPR messages could be reviewed for such a message via a list of
messages in the queue, or by receiving each iteratively without removing
them; e.g. starting with *LAST then *PRV until the inquiry message of
interest is found. If the /assumption/ that QSYSOPR will be generally
acceptable, then the following APIs might assist:
Approaching the problem instead from the waiting job, the last
message in the joblog should be an inquiry or perhaps a sender's copy of
the inquiry; generally, but a change job requested against that job may
leave a later message. Some messages may be known only to go to QSYSOPR
or some other message queue, or the message data may even indicate where
the reply is expected. Finding the message in that message queue is
then redirected to the above processing. The time of the inquiry being
sent would be known using this method, which may be of value for
processing the messages on the message queue. One of the following APIs
could assist for this approach:
Note: The job in MSGW would presumably also hold a lock on the
message queue from which it was awaiting a reply, however a job may have
other message queues locked, so a list of held locks would probably
_not_ be a worthwhile method to infer the *MSGQ.