Learn how to write an inquiry-handling exit program.
This is the third in a series of articles related to inquiry messages. The first two articles, "Beyond Watches" and "Validating Inquiry Message Responses," introduced the use of the reply-handling exit point QIBM_QMH_REPLY_INQ. With this exit point, you are able to validate the reply and, if you want, change the reply after the end user responds to an inquiry message. The current article introduces another exit point in the system. This exit point, QIBM_QMH_HDL_INQEXT, allows you to intercept an inquiry message before the end user is involved. That is, your exit program can directly provide the appropriate response without any operator involvement.
This exit point, new with V6R1, is documented here.
Based on the RNQMGR program used in "Validating Inquiry Message Responses," the sample program RNQINT, RNQ Intercept, is provided below:
dRNQInt pr ExtPgm('RNQINT')
d CallType 10i 0 const
d QualMsgQName 20 const
d MsgKey 4 const
d MsgID 7 const
dRNQInt pi
d CallType 10i 0 const
d QualMsgQName 20 const
d MsgKey 4 const
d MsgID 7 const
dSndRply pr extpgm('QMHSNDRM')
d MsgKey 4 const
d QualMsgQName 20 const
d ReplyText 65535 const options(*varsize)
d LenReplyText 10i 0 const
d RmvMsg 10 const
d QUSEC likeds(QUSEC)
d CCSID 10i 0 const options(*nopass)
d AllowReject 10 const options(*nopass)
dRcvMsg pr extpgm('QMHRCVPM')
d Receiver 1 options(*varsize)
d LenReceiver 10i 0 const
d Format 8 const
d CSE 10 const
d CSECtr 10i 0 const
d MsgType 10 const
d MsgKey 4 const
d WaitTime 10i 0 const
d MsgAction 10 const
d ErrCde likeds(QUSEC)
d LenCSE 10i 0 options(*nopass) const
d QualCSE 20 options(*nopass) const
d CSEType 10 options(*nopass) const
d CCSID 10i 0 options(*nopass) const
d AlwDftRpyRjct 10 options(*nopass) const
dSndMsg pr extpgm('QMHSNDM')
d MsgID 7 const
d QualMsgF 20 const
d MsgDta 100 options(*varsize) const
d LenMsgDta 10i 0 const
d MsgType 10 const
d MsgQNames 20 const
d NbrMsgQNames 10i 0 const
d RpyMsgQ 20 const
d MsgKey 4
d ErrCde likeds(QUSEC)
d CCSID 10i 0 options(*nopass)
dPSDS sds 429 qualified
d MsgID 40 46
d JobName 244 253
d JobUsr 254 263
d JobNbr 264 269
/copy qsysinc/qrpglesrc,qmhrcvpm
/copy qsysinc/qrpglesrc,qusec
dMsgInfo ds based(MsgPtr) qualified
d MsgHdr likeds(QMHM010001)
dRNQ_Msg ds based(MsgRplDtaPtr)
d Procedure 1 10
d PgmName 11 20
d Library 21 30
d Statement 31 40
dMsgQName ds
d NtfyQ 10 inz('PGMR')
d NtfyQLib 10 inz('QGPL')
dMsgTxt s 256
dMsgPtr s *
dMsgRplDtaPtr s *
dInqMsgKey s 4
/free
monitor;
if ((MsgID = 'RNQ0100') or
(MsgID = 'RNQ0102') or
(MsgID = 'RNQ0103') or
(MsgID = 'RNQ0121'));
if PSDS.JobUsr = 'JOE_PGMR';
// Do not notify support or set response when inquiry
// message is from developer working on new code
else;
MsgTxt = (MsgID + ' in job ' +
%trimr(PSDS.JobName) + '/' +
%trimr(PSDS.JobUsr) + '/' +
%trimr(PSDS.JobNbr));
QUSBPRV = 0;
// Determine size of information available with inquiry
// message, allocate that storage, and then receive all
// information related to the message
RcvMsg(QMHM010001 :%size(QMHM010001) :'RCVM0100' :'*EXT'
:0 :'*ANY' :MsgKey :0 :'*SAME' :QUSEC);
MsgPtr = %alloc(QMHBAVL02);
if MsgPtr <> *NULL;
RcvMsg(MsgInfo :QMHBAVL02 :'RCVM0100' :'*EXT' :0
:'*ANY' :MsgKey :0 :'*SAME' :QUSEC);
if MsgInfo.MsgHdr.QMHDRTN00 >= 30;
MsgRplDtaPtr = MsgPtr + %size(QMHM010001);
MsgTxt = %trimr(MsgTxt) + ' running program ' + PgmName;
select;
when (CallType = 1);
select;
when PgmName = 'ABC001';
SndRply( MsgKey :QualMsgQName
:'D' :1 :'*NO' :QUSEC);
MsgTxt = %trimr(MsgTxt) +
', option D taken.';
other;
SndRply( MsgKey :QualMsgQName
:'C' :1 :'*NO' :QUSEC);
MsgTxt = %trimr(MsgTxt) +
', option C taken.';
endsl;
other;
MsgTxt = %trimr(MsgTxt) + 'CallType ' +
%char(CallType) + ' found.';
endsl;
else;
MsgTxt = %trimr(MsgTxt) + ' running program *N';
endif;
dealloc MsgPtr;
else;
MsgTxt = %trimr(MsgTxt) + 'Storage problem in RNQINT';
endif;
SndMsg(' ' :' ' :MsgTxt :%len(%trimr(MsgTxt)) :'*INFO'
:MsgQName :1 :' ' :InqMsgKey :QUSEC);
endif;
endif;
on-error;
MsgTxt = 'RNQINT failure with message ' + PSDS.MsgId +
' in handling initial error ' + MsgID;
SndMsg(' ' :' ' :MsgTxt :%len(%trimr(MsgTxt)) :'*INFO'
:MsgQName :1 :' ' :InqMsgKey :QUSEC);
endmon;
*inlr = *on;
return;
/end-free
Assuming that the QSYSINC library (option 13 of the operating system) is installed on your system, you can create the program RNQINT into library VINING using the CRTBNDRPG command:
CRTBNDRPG PGM(VINING/RNQINT)
To have the RNQINT program in library VINING called whenever an inquiry message is sent to an interactive job's external message queue, you use the Add Exit Program (ADDEXITPGM) command:
ADDEXITPGM EXITPNT(QIBM_QMH_HDL_INQEXT) FORMAT(INQE0100) PGMNBR(*LOW) +
PGM(VINING/RNQINT)
To stop the system from calling the RNQINT program, you can use the Work with Registration Information (WRKREGINF) command:
WRKREGINF EXITPNT(QIBM_QMH_HDL_INQEXT) FORMAT(INQE0100)
Option 8 (Work with exit programs) from the displayed panel will then show you all exit programs that are called for the exit point. From here, you can then use option 4 (Remove) for the entry showing the exit program RNQINT in library VINING.
The vast majority of the logic seen in RNQINT is the same as in RNQMGR. The key differences are the:
- parameters passed to RNQINT
- use of the Send Reply Message (QMHSNDRM) API
Rather than the eight parameters passed to RNQMGR, RNQINT receives four parameters. The four parameters are the call type, the qualified message queue where the inquiry message is located, the message key, and the message ID. In V6R1, call type is always set to a value of 1, indicating that an inquiry message needs a reply. Likewise, the qualified message queue name is always set to the value *EXT, indicating that the inquiry message is located in the job's external message queue. The message key and message ID parameters are used in the same manner as they are in the RNQMGR exit program.
Several of the parameters that were passed to the RNQMGR program when using the reply-handling exit point are related to the exit program returning a new reply value for the inquiry message. The RNQINT program does not need these parameters as it uses the Send Reply Message (QMHSNDRM) API, which is documented here. Where RNQMGR sets the Reply, LenReply, and ReplyAcnCode variables to the appropriate values, RNQINT simply calls the QMHSNDRM API to provide a reply to the inquiry message.
When calling QMHSNDRM, the first parameter identifies the message key associated with the inquiry message. This value was passed to RNQINT as the third parameter when the exit program was called by the system exit point. The second parameter is the qualified message queue name where the inquiry message is located. This value was passed to RNQINT as the second parameter when the exit program was called. The third parameter passed to QMHSNDRM is the reply value that RNQINT has determined by examining the message replacement data for the inquiry message. If the program encountering the RNQ failure is ABC001, a dump is requested using a reply value of D. If the program is not ABC001, then the program is cancelled using a reply value of C. The fourth parameter passed to QMHSNDRM is the length of the returned reply value: 1 in both the case of a dump or cancel request. The fifth parameter indicates whether or not the inquiry message, and the program's reply to the inquiry message, should be removed from the message queue. The value *NO indicates that the message should not be removed. The sixth parameter is the standard error code structure found with most system APIs.
And that's it! You have now automated responses to the four selected RNQ inquiry messages, eliminating the need for an end user to respond to the error situation. And you've done so using an exit program that can respond with different replies, depending on the specific error and error-related data.
One usage note, however, is worth pointing out. When you are using the inquiry-handling exit point, the reply-handling exit point, discussed in the previous articles, still applies. That is, your inquiry-handling exit program (RNQINT) may send a reply to the inquiry message that the reply-handling exit program (RNQMGR from the previous article) changes (or rejects though the RNQMGR program as written does not take advantage of this reject capability). In this situation, various messages, including escape messages, may be sent to the inquiry-handling exit program. The introduction to the inquiry-handling exit point provides additional details on what messages may be sent and under what circumstances.
In the case of a rejected reply, RNQINT, as written, will send a message to the message queue QGPL/PGMR because of the active monitor. The end user would then be presented with the original inquiry message. The easy way to avoid this situation is to make sure both the inquiry-handling exit program and the reply-handling exit program are in agreement on how specific messages should be handled. Alternatively, RNQINT could re-call the QMHSNDRM API with a different reply, one that hopefully the reply handler would accept.
If you have any API questions, send them to me at
LATEST COMMENTS
MC Press Online