Re: Can I send a reply message?

[CRPence <CRPbottle@xxxxxxxxx>]

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