Unable to Allocate Record Buffer Clear Form to Continue

We have a persistent problem with application jobs waiting on record locks with an RNQ1218 (unable to allocate a record in file &7) message. The record is only temporarily locked because by the time my help desk looks at it, the lock is gone and the program resumes after answering the message with an 'R' (Retry). Any ideas what we can do so we're not constantly answering record lock messages?

–Bob

In your case, the first thing is to determine why a constantly needed record is always being locked and to devise a fix. This could be a case where increasing traffic causes record locks and your programming staff needs to look at it and devise a fix as soon as possible.

While you're waiting for programming to implement a fix, you might want to employ an auto-answer technique, where the system automatically feeds a Retry ('R') response to any RNQ1281 error messages a fixed number of times, before the system gives up and writes an inquiry message to QSYSOPR.

Here's how I usually structure a utility program for automatically answering an inquiry message.

→ Monitor the QSYSOPR message queue for the presence of any RNQ1218 error messages.

→ Automatically reply with an 'R' (Retry) when an RNQ1218 message first occurs for a job. Note the job information (job name and number) of the job that generated the RNQ1218 message.

→ Wait one to five minutes after feeding the 'R' reply to the job and check for additional RNQ1218 messages. Check for new RNQ1218 messages every few minutes.

→ If additional RNQ1218 messages appear for the same job, answer each message with an 'R' reply until the automated monitoring program sends three 'R' replies to the same job.

→ After the automated monitoring program sends three RNQ1218 replies to the same job, stop sending automatic 'R' replies and allow the new RNQ1218 message to be written out to the QSYSOPR message queue without a reply, where someone must finally deal with it.

The idea here is that your automated program will take three tries to answer your RNQ1218 message. If the RNQ1218 message for that particular job doesn't go away after three 'R' replies, the program gives up and waits for someone to manually fix the problem.

I've done this on Power i machines and it's very effective. You can generally set up this type of monitoring in one of two places.

→ In a custom-written CL program that you set up to run as an always-up server in one of your batch subsystems or in the QSYSWRK subsystem.

→ Inside your IBM i monitoring software, if the package allows you to monitor and answer.

Writing a custom-written program for this function can be a drag. So I suggest that you see if you can implement this capability inside a third-party IBM i monitoring package. Most of the third-party monitoring packages have the ability to auto-reply to specific inquiry messages. In our shop, we set up a monitor to constantly query QSYSOPR for any RNQ1218 messages and answer the messages as described above. If the record lock can't be resolved after three tries, the package will send an email and text out to the technician on duty, and the technician will sign on, investigate, and solve the problem manually.

The nice thing about setting up RNQ1218 monitoring is that once you have the initial monitoring framework down, you can add monitors to answer other inquiry messages as the need arises (such as answering a file full message where you might want to increase the file size by three increments before calling for help).

There's one thing I will caution you about with automatic message replies for RNQ1218. Don't try to use your IBM i System Reply List entries (WRKRPYLE) to solve this issue. If you try to configure this technique in WRKRPYLE, the system will issue an automated reply every time the RNQ1218 is issued. It won't stop issuing 'R' replies after three tries, as outlined above. The System Reply List is not what you want in a serious record lock situation, as your jobs could wind in an answering loop where 'R' replies are continuously issued and the record lock is never resolved. So stay with using a third-party monitoring package or a custom-written package, if no third-party software is available.

HTH

–Joe

Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.

You can read Joe's weekly blog atjoehertvik.com. You can follow Joe on Twitter @JoeHertvik. You can also add Joe to your professional network on LinkedIn by clicking here.

---

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

jonestheivereeted.blogspot.com

Source: https://www.itjungle.com/2013/07/24/fhg072413-story03/

Share this post