Auto-Answering Record Lock Errors And More On Returning An IBM i Box

February 26, 2014 Hey, Joe

My Power i system is driving me crazy with RPG1218 record lock messages. Because of the way one of our applications was written, we receive RPG1218 messages several times a day. The record lock only lasts a minute. When we enter a retry on the locked record, the system is always able to update the record. Is there any way to auto-answer these record locks?

–Bert

Well the first thing I’d do is have your applications staff figure out why that program is causing so many record locks and fix it. (Ha.) Barring that, I may have a solution that will help with your record lock error message blues.

The problem is that one or more program instances are requesting the same record for update at the same time. I’ve seen persistent record lock errors happen with website order entry programs, where the same routine is constantly called from different website instances. It usually only takes a short amount of time to update the record, so by the time you answer the message, the locked record has been updated and released. And because a number of instances update that record every day, this cycle repeats its self over and over again.

There’s a classic solution to this problem. It involves your IBM i system monitoring software. Here’s the drill for taking care of this record locking issue through monitoring.

Step 1 is to go into your IBM i system monitoring software and set up a new monitor that reacts when either of the following inquiry messages appear in the QSYSOPR message queue.

RNX1218 in message file QRNXMSG in library QSYS – Unable to allocate a record in file &7.
RPG1218 in message file QRPGMSGE in library QSYS – &1 &2 is unable to allocate a record in &5 (R C G S D F).

These monitors should be set up to send out alerts whenever these messages are detected.

Step 2 is to check your system monitoring documentation and determine what it takes to change the monitor created in step 1 into an Actions monitor. The terminology may differ from package to package but an Actions monitor does the following:

Sends a reply to an error inquiry message.
Waits a specified amount of time before checking the results of the message reply, say three minutes.
If the message reply successfully answers the message after the specified number of times, no alert is sent out regarding the message and the monitor goes back to sleep.
If the message reply doesn’t successfully answer the message after the specified number of tries, send out an alert regarding the message.
Repeat steps 1 – 4 a specified number of times until the problem is resolved, say five times.

Finally in Step 3, change the monitor in Step 1 to auto-answer the RNX1218 and RPG1218 messages with an ‘R’=Retry reply, according to template researched in Step 2. The result will be that once an RPG128 or RNX1218 message is detected in QSYSOPR, the system will try to auto-answer the message three times with an ‘R’ before either resolving the message or sending out an alert that a problem needs attention. Coded with the right parameters, this will resolve most of your record lock error messages and allow you to let the system do the work, not you.

This technique worked for us at one of our clients, and most major software packages offer an auto-reply function such as this one. If you don’t have a system monitoring package, check out thecommunity post of IBM i software monitoring packages at joehertvik.com.

–Joe

Update On Wiping Or Removing Disk Drives When Returning An Old Power i Machine

In 2010, I wrote an article on how to erase IBM i disk drives when you decommission a system. The purpose of erasing a drive is to ensure that the organizational data contained on your disk drives is not returned to your leasing company with your machine. The technique I outlined involved using the IBM i procedure to install and reinitialize your disk drives, cleansing the disk on your machine. There are also other techniques you can use to clear your disk to the United States’ Department of Defense standards, which are more stringent.

I updated this technique last issue to discuss how after initializing your disk drives, you can also break your disk drive RAID sets by rearranging the disk drives (removing and reinstalling the drives in a different location) in your disk tower. The combination of initializing your drives and breaking your RAID drives is a good way to ensure your old corporate data is safe.

But this week, I found a third technique for protecting your disk and partition data when returning an old machine to a leasing company or selling it to another party. After cleaning your drives and breaking up your RAID sets, you can also delete the partition profiles on your Hardware Management Console (HMC). Your power systems machine uses the profile partitions stored in the HMC to assign resources to each partition and to power up each partition. If you delete the profiles after cleaning your disk drive and breaking your RAID sets, it’s very doubtful that anyone will be able to reconstruct or read any organizational data from your old machine and its attached hard drives.

Deleting a partition profile is easy. Open your HMC software and go to the partition’s page under your server. Right-click on the partition profile you want to delete and take the options to delete the partition profile from the HMC.

Joe Hertvik is an IBM i SME and 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, featuring multiple IBM i ERP systems. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.