Admin Alert: Solving i5/OS Inquiry Message Whodunits
February 18, 2009 Joe Hertvik
|
Occasionally, a user, operator, administrator, or programmer will incorrectly answer an i5/OS inquiry message, causing system problems. When that happens, it can help to quickly discover how the message was answered, if only to prevent the offending job or user from incorrectly answering it again. This week, I’ll look at some investigative techniques for answering that classic i5/OS question: Who answered that inquiry message? Using QSYSOPR To Find An Answering Job While investigating inquiry message whodunits, an administrator’s first instinct is to display the system operator message queue (QSYSOPR) where the inquiry message originally appeared. When inquiry messages are fresh, a user can find and answer the message directly from QSYSOPR by typing in the following Display Message (DSPMSG) command. DSPMSG MSGQ(QSYSOPR) As most administrators know, this command shows QSYSOPR messages in display mode, where you can see all the operator messages along with any input fields to reply to unanswered messages. Running DSPMSG this way shows most of the information that is associated with an inquiry message. It does not show you the identity of the user or job that replied to a particular message. So running DSPMSG in display mode is a cold lead if you’re looking for the identity of the user and job that replied to a message. However, that doesn’t mean that you can’t uncover the responder’s identity by using DSPMSG. You can easily find out which user answered an inquiry message by using DSPMSG to generate a spooled file of all QSYSOPR inquiry messages, like this: DSPMSG MSGQ(QSYSOPR) OUTPUT(*PRINT) MSGTYPE(*INQ) This command produces an inquiry message history report for QSYSOPR. Once you have the printout, it’s easy to search for the user or job name that answered a particular message, because your spooled file output will contain a group of entries that look something like this for every inquiry message on the system.
CPA0701 99 INQUIRY CPF2817 received by PROGRAM at 3000. (C D I R)
PROGRAM JOEH 752967 QCLXERR 0000 02/10/09
99 VALID RPY Reply . . : C
JOESPC JOEH 752955 QMHSCLVL 0000 02/10/09
The first two lines of each grouping show you the actual error message that was answered, and the job that created the error message. The third line shows you the inquiry message response that was entered and what kind of reply was entered. The final line shows you the job name and the user name that sent the message reply. In this case, the printout shows you that the message was answered by user JOEH with a reply of ‘C’ (cancel), and that the reply was accepted as a valid reply (VALID RPY). And that’s usually the end of the game. You’ve uncovered the culprit and you can move on to other things. Or can you? What If A Job Answers Its Own Inquiry Message? The first example I’ve shown here is easy to decipher. The program needed an inquiry message answered and a user named JOEH replied. But what if you’re looking for a message reply and the DSPMSG spooled file output shows you something like this?
CPA4002 99 INQUIRY Verify alignment on printer PRINTER1. (I G N R E C)
PRINTER1 QSPLJOB 751959 QWPXPRMA 0000 02/09/09
99 SYSRPYL RPY Reply . . : I
PRINTER1 QSPLJOB 751959 QMHSNINQ 0000 02/09/09
In this case, the system is telling you that the message was answered by the job that issued it (PRINTER1), the message was replied to with an ‘I’ (ignore), and that the message reply type was SYSRPYL RPY. You got your answer but now you’re confused. What the heck does SYSRPYL RPY mean and how can a running job answer its own message? In this case, SYSRPYL RPY means that the message was answered from the System Reply List (SRL). The SRL contains a list of pre-defined responses that can be automatically used to answer inquiry messages inside a specific job, one of which was set up to respond to the inquiry message listed in the spooled file. To read a decent primer on how the SRL works, see this entry from the i5/OS Information Center for Version 5, Release 4. For printer jobs, the job will automatically take any responses from the SRL, if the list already contains a reply for that inquiry message. For non-printer jobs, the job can be enabled to answer the message by retrieving a reply from the SRL. You can configure any submitted job to retrieve SRL responses by performing one of the two following actions. 1. Using the Submit Job (SBMJOB) command to submit the job with the Inquiry Message Reply (INQMSGRPY) parameter set to *SYSRPYL. When doing this, your SBMJOB command will look like this: SBMJOB CMD(CALL PGM(PROGRAM)) INQMSGRPY(*SYSRPYL) With INQMSGRPY set up this way, the job will automatically retrieve any available inquiry message responses from the system reply list, provided an SRL entry exists for the message to be answered. 2. Changing the Inquiry Message Reply (INQMSGRPY) parameter to *SYSRPYL on the Job Description that your submitted job uses. Every job in the system has a job description parameter, which tells the system which job description to use when running the job. Job descriptions contain basic information for submitting work to the system, including the default job queue to submit the job to, the initial library list for the job, the printer device or output queue for spooled files, and the default inquiry message reply. A user’s default job description name is set up in their user profile under the job description (JOBD) parameter, and their job description name can be referenced or changed by using either the Work with User Profiles (WRKUSRPRF) command or the Change User Profile (CHGUSRPRF) command. By default, when a new job is submitted to the system through the Submit Job command, SBMJOB is run with these defaults: SBMJOB CMD(CALL PGM(PROGRAM)) JOBD(*USRPRF) INQMSGRPY(*JOBD) This means that the running job will retrieve its runtime parameters from the job description specified in the user profile running the submitted job, as specified in the JOBD(*USRPRF) parameter. The job will then retrieve its’ Inquiry Message Reply parameter from the user’s job description (the INQMSGRPY parameter). So if the default job description for a particular user designates *SYSRPYL as its Inquiry Message Reply value, any job that is running under a user profile using that job description will also automatically use *SYSRPYL as the job’s Inquiry Message Reply value. To view or change job descriptions on your system, use either the Work with Job Descriptions (WRKJOBD) or the Change Job Description (CHGJOBD) command. Be careful, however, when setting up a job description to automatically use the SRL for batch jobs. I recently ran into a situation where a well-known vendor package had some job descriptions set up to use the SRL for all inquiry messages. The problem was that i5/OS pre-loads the system’s SRL with a generic entry for handling any RPG error, designated by message identifier RPG0000, which makes the entry valid for all RPG inquiry messages with message IDs between RPG0000 to RPG9999. What’s more, that SRL has a pre-defined response of ‘D’ (dump the program) for the generic RPG entry. The vendor had set up its batch jobs to automatically answer inquiry messages by using the SRL entries, and when one of those jobs hit an RPG error, it automatically performed a program dump and ended the job stream rather than giving the staff time to look at the message and figure out what was wrong. The morale is that system reply entries can hurt you as well as help you, if you’re not careful. How About Default Inquiry Message Replies? In additional to seeing VALID RPY and SYSRPYL RPY as inquiry message reply types, you may also see reply values in your QSYSOPR spooled file that look like this:
RNQ0907 99 INQUIRY Decimal-data error occurred (C G D F).
PROGRAM JOEH 752836 QRNXIE
99 MSGDFT RPY Reply . . : C
PROGRAM JOEH 752836 QMHSNINQ
When an inquiry message reply shows MSGDFT RPY, it means that the inquiry message was answered from the default reply associated with the message ID. There are a few situations where a job will use the default message reply for inquiry messages, but the most common is when a job is submitted with the Inquiry Message Reply parameter set to *DFT, like this: SBMJOB CMD(CALL PGM(PROGRAM)) INQMSGRPY(*DFT) When running this way, the job will always answer any inquiry messages with the default reply for that message. To view the default reply for any particular message, run the following Work with Message Description (WRKMSGD) command. WRKMSGD MSGID(Message_id) MSGF(Message_file_name) Where Message_id is equal to the message identifier for the inquiry message and Message_file_name is equal to the message file that the message identifier definition is stored in. For the RNQ0907 message shown in this example, you would run WRKMSGD this way. WRKMSGD MSGID(RNQ0907) MSGF(QRNXMSG) Once you are on the WRMKSGD screen, take option 5=Display Details, and then take option 5=Display Message Attributes, to see the default reply for that message. That’s the reply that will be used when a job’s INQMSGRPY parameter is set to *DFT. The Case Is Solved As you can see, identifying who is answering inquiry messages is very easy with i5/OS. The system offers you a few basic tools for identifying the culprit and understanding why certain messages are automatically answered in the system. Once you know how to identify where a message came from, you can take steps to make sure that unexpected messages are answered consistently with no surprises. RELATED RESOURCES
|
