I’d like to thank Angela Newton for writing this blog article. Angela Newton is the team leader of the IBM i work management team and her responsibilities also include system APIs and message handling. Thanks, Angela!
Have you ever signed on to your system in the morning, only to find the batch job you kicked off the night before is sitting there waiting for someone to reply to an inquiry message? Or maybe you have had the opposite problem where you noticed an inquiry message had already been responded to before you had a chance to see it and it wasn't the reply you wanted?
Inquiry messages can be very useful and help a program take the proper action, but they can also be a problem if they hold up a job if they aren’t responded to in a timely fashion, or a nuisance if sent too often and the response is always the same. Or they can just be confusing if they get an automatic reply in some cases but not others.
The Inquiry Message Reply (INQMSGRPY) job attribute defines how inquiry messages are to be answered. This is defined in the job description and can be changed by the CHGJOB command. You can also set it on the SBMJOB and BCHJOB commands. To see what the job attribute is set to, use DSPJOB or WRKJOB, option 2. This job attribute can have one of the following three values:
System Reply List
If *SYSRPYL is specified for the job's INQMSGRPY value, the system reply list will be used to reply to the message. Use the WRKRPYLE (Work with reply list entries) command to see the reply list entries and ADDRPYLE to add a new entry. The system reply list entries are searched for a matching message ID and compare value. If a match is found, the reply list entry is used to determine what reply to send, ('C' for cancel, for example). This allows the job to continue uninterrupted without any user intervention. The system reply list is searched in order by sequence number, and the first entry found that matches the message ID is used. The message ID in the reply list entry can be *ANY, a generic message ID, or a specific message ID. Generic message IDs are message IDs that end with 00 or 0000. For example, CPA0000 would match any message ID with a CPA prefix; CPA0700 would match any message ID in the range CPA0700 to CPA07FF.
Delivery Mode of the Message Queue
Sometimes even when a job’s INQMSGRPY is set to *RQD, you may find an inquiry message sent by that job still had a default reply sent to it. How can this happen?
If the inquiry message is being sent to a standard message queue (QSYSOPR, workstation message queue, user message queue, etc.), the delivery mode of the message queue can make a difference. If the delivery mode is set to *DFT, the default reply will be sent for the message. The delivery mode is set by the Change Message Queue (CHGMSGQ) command. The delivery mode of a message queue can be determined from the DSPMSG or WRKMSG display. In basic assistance level, press F22 to see the delivery mode. In intermediate assistance level, the delivery mode is shown at the top of the screen.
Inquiry vs. Notify Messages
This might seem obvious to point out that the INQMSGRPY job attribute applies only to inquiry messages (*INQ). But there is another type of message that looks a lot like an inquiry message, and that is a notify message (*NOTIFY). Notify messages can sometimes be confused with inquiry messages because they usually have replies sent to them also. But notify messages are program-to-program messages. A reply sent to a notify message is determined by how the receiving program monitors and handles the message, and the user has no control over the reply.
Other Ways an Inquiry Message May be Answered
If you have confirmed the INQMSGRPY job attribute, system reply list and delivery mode are all set correctly but you are still puzzled by how a message reply is being sent, or if the automatic reply is not what you expect, here are a few more considerations:
- When an inquiry message is sent to the *EXT message queue in an interactive job, and the job attribute is set to *RQD, the Display Program Messages display will be shown to the user with the message along with a place to enter a reply. The message usually lists the possible choices for a reply, for example "I" to ignore, "C" to cancel, or “R” to retry. If the user presses enter without typing a reply, the default reply (defined for that message) will be sent. The default reply will also be sent when an inquiry message is sent to *EXT in a non-interactive job with INQMSGRPY(*RQD).
- Deleting an inquiry message by either clearing a message queue or individually removing it will also cause the default reply to be sent before the message is deleted. For example, an inquiry message is sent to QSYSOPR and is waiting for a reply, but before you notice the message, the system operator clears the message queue. The default reply will be sent in this case and the program waiting on the inquiry message will continue.
- Most inquiry messages wait indefinitely for a reply, but it is possible to set a specific wait time (see the Send Program Message (QMHSNDPM) API). If the wait time expires before the user enters a reply, the default reply is sent and control returns to the sending program. If the wait time is 0, the inquiry message is sent, but the Display Program Messages screen is not displayed, and the default reply is sent immediately.
- There are two exit points in the path of sending and replying to inquiry messages:
To determine if either of these exit points may be involved in the inquiry reply handling on your system, you can use the WRKREGINF command to see if any exit programs are registered. You will also find diagnostic messages logged in the job log when an exit program is used to replace or reject a reply to an inquiry message.
For more information on message handling in general, see the IBM i Information Center. The messages topic is hidden away under Programming>Control language.