Re: Can I send a reply message?

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:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/apis/QMHSNDRM.htm

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:
http://archive.midrange.com/rpg400-l/200802/msg00332.html
http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/apis/qusrjobi.htm

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.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/mh1.htm

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:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QMHLSTM.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QGYOLMSG.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/Qmhrcvm.htm

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:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QMHLJOBL.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QGYOLJBL.htm

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.

Regards, Chuck