This is the third in a series of TechTips about record lock issues. Part 1 and Part 2 offered techniques for preventing record lock from ever occurring, which is the best option. But that's not always possible. For example, staffs working with third-party applications may be reluctant or unable to modify the code, yet still have legacy applications that interact with the third-party data files. In such cases, one possible solution is to modify the legacy application to test for record lock.

Testing for record lock requires additional error-handling logic within the program. Once the record lock error is detected, the program must then determine how to respond to the error. A simple example involves an interactive application where a user enters a key value. The program will chain to the file and test for record lock, as shown below.

The "E" operation extender indicates that if an error such as record lock occurs, instead of ending the program and passing an error back to its caller, the program will set on an error flag and continue processing with the next statement. The program then tests for an error using the %ERROR built-in function and, if an error occurs, calls a simple CL program named SNDERRMSG, whose code is displayed below. After that, normal screen-handling logic is used to redisplay the screen and display the error message.

This program retrieves the last record sent to the RPG program's program message queue and then reissues it as an informational message so that it can easily be displayed on the screen using common message subfile techniques. The message will look something like the one shown below.

As you can see, the message contains the record number being locked as well as the job and user who have it locked. This greatly assists operators in resolving the conflict and allowing the program to proceed by retrying the operation.

So if you can't prevent record lock, don't give up. You can still test for and respond to record lock errors when they happen. This example may require some adaptation to fit into your particular programming model, but the basic principle applies: If you can trap for the error, you can control the behavior of your program when it occurs and take advantage of the valuable information in the IBM-supplied error message.

Stay tuned for the fourth and final TechTip in the record lock series.

Kevin Forsythe, author of SQL for eServer i5 and iSeries, has over 20 years of experience working with the iSeries platform and its predecessors. He has been a member of the DMC team for the past nine years. Kevin's primary responsibility is providing iSeries education, but he also provides customers with project management, system design, analysis, and technical construction. In addition to his technical skills (RPG IV, CL, OS/400, SQL, FTP, Query, VB, Net.Data), Kevin possesses the ability to communicate new and complex concepts to his students. He has been the primary instructor for DMC's iSeries-based AS/Credentials training courses since 1997 and has authored courses such as Advanced ILE, SQL, Embedded SQL, Operations Navigator, and Intro to WebSphere Studio. An award-winning speaker, he has spoken at every COMMON Conference since the spring of 2000.