Admin Alert: When You Can't Answer Record Lock Errors

Published: November 9, 2011

by Joe Hertvik

Recently, a client had a problem with Power i record allocation messages. When a program crashed with an RPG1218 record lock inquiry message, the system didn't ask for a message reply. Instead, it automatically answered the message with a "D" to dump program data and end the job. The client didn't want this to happen. He'd rather answer the message himself and retry the allocation. Here's what happened and how it applies to all i OS shops.

A Common Problem

The first thing to understand is that this is a fairly common i OS situation. It isn't magic or a system bug. By default, the operating system is configured so that in certain situations, all RPGxxxx inquiry messages (message IDs RPG0000-RPG9999) for a job are automatically answered with a D--whether you want that to happen or not.

This situation involves your machine's System Reply List (SRL) and the way your user jobs are configured. Here's what happened in my RGP1218 situation, and how you can stop it from happening in your shop.

The Basic Problem

For this situation, the basic problem occurs when a user program crashes on a file record allocation error. This occurs when one program reads and locks a file record that another program wants to update. When this happens, the requesting program crashes and it usually sends the following RPG1218 inquiry message to the QSYSOPR message queue on your system.

&1 &2 is unable to allocate a record in &5 (R C G S D F).

This is an easy message to answer. RPG1218 typically shows up in your system operator message queue as an Inquiry message and you have the choice of entering one of six responses in reply. The entered response tells the operating system what to do in this situation. Although six valid responses are accepted, the three most common responses for an RGP1218 inquiry message are:

• R--Retry retrieving the locked record and continue running the program. You usually use "R" after your target record is released by the holding program.
• C--Stop processing and cancel the program.
• D--Stop processing and dump all the job information into a spooled file printout attached to the job (what's happening in the example).

The drill is simple if you are able to answer an RPG1218 inquiry message. Find the program that is locking your desired record, make sure the program has finished processing the record and that it has released the record, and then reply with an "R" to restart the input operation. If the record is now free, processing will continue.

The problem is that in our example situation, the system isn't allowing you to issue a response to this Inquiry message. Instead, it is automatically answering the RPG1218 message with a "D", so that the program dumps out all its program data.

Now given that this same situation can happen on almost any iSeries, System i, or Power i partition with any RPGxxxx inquiry message , there are two relevant questions.

1. Why does this happen?
2. How can you stop it from happening on your system or on any other system?

Why = System Reply List

In this case, the problem lies with the partition's System Reply List (SRL). The SRL is an i operating system construct that contains predefined responses for common system inquiry messages. You can view and work with your SRL by running the Work with Reply List Entries (WRKRPYLE) command.

WRKRPYLE

This command will show you a screen that looks something like this:

The SRL contains a list of i OS message IDs, the system reply to automatically use for that particular message, and some other information that doesn't matter in this example. If a job is configured to use the system reply list to automatically answer inquiry messages, the operating system will feed the designated reply to the job without ever sending the inquiry message to the QSYSOPR message queue. For more information on the System Reply List, see the stories referenced at the bottom of this article.

And that's what was happening with the RPG1218 inquiry message referenced here. By default, the system reply list has an entry for Message ID RPG0000. RPG0000 is a generic RPG system entry value that tells the operating system that if any RPGxxxx message is displayed that needs a reply, the operating system should automatically answer that message with a D, which will stop processing and dump all program information. The RPG0000 SRL entry is shipped with the OS/400, i/OS, and i operating systems.

So if your user's jobs are configured to use the SRL to answer their inquiry messages, when an RPG1218 message comes up telling the job the record is locked, the operating system dumps its data and ends the program that's trying to allocate the record.

Determining If a Job Is Using the SRL for System Messages

To see if your user jobs are configured to use the SRL to answer inquiry messages, run the following Display Job (DSPJOB) command on one of the jobs:

DSPJOB JOB(Job number/User ID/Job name) OPTION(*DFNA)

This will show you the job's Job Definition Attributes. Page over to the third page of this display and you'll see a screen that looks something like this:

If the job is set up to send inquiry messages to the QSYSOPR message, the Inquiry Message Reply parameter will be set to Required (*RQD as shown here). This means that the job is requiring you to enter a message response when an inquiry message such as an RPG1218 occurs.

In my example, when we looked at the Job Definition Attributes configuration of one the jobs where the system is automatically answering RPG1218 allocation inquiry messages with a D, the Inquire Message Reply parameter looked like this.

When the Inquire message reply value is set to *SYSRPYL (System Reply List), the operating system will automatically answer error inquiry messages with an appropriate value from the SRL.

So the morale is this: When user jobs are set up to use the System Reply List to automatically answer inquiry messages, those jobs will automatically dump program data whenever an RPGxxxx inquiry message occurs. The reply comes from the default RPG0000 entry in the SRL.

Curing the Problem . . . If You Want To

To convert your users from using the system reply list for answering inquiry messages (*SYSRPYL) to requiring the user to enter a value for inquiry messages (*RQD), you can reconfigure your user jobs to ensure that the Inquiry Message Reply value is set to *RQD, instead of *SYSRPYL after they log on. This can be done by changing the Inquiry Message Reply parameter (INQMSGRPY) of the user's associated job description or by ensuring this value is set correctly when the user signs on to the system.

But there is one danger to watch out for when modifying the Inquiry Message Reply value for a user job or changing the System Reply List. There may be a reason that your user jobs are set up to use the SRL, rather than having users enter their own replies when an inquiry message occurs. Some older pieces of software rely on using the SRL to cover their own flaws. Depending on the package, the SRL may be the only thing stopping your users and Help Desk from encountering numerous inquiry messages that are easily avoided when the SRL is being used.

So if you're in this situation, do some research and give some thought as to whether you really want to turn off the System Reply List message answering feature. Decide if it's the right solution for your problem.

RELATED STORIES

Basic i/OS Error Monitoring and Response, Part 1

Basic i/OS Error Monitoring and Response, Part 2

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot