• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Old Stuff, New Ways: Avoiding Record Locks

    March 3, 2015 Jon Paris

    Note: The code accompanying this article is available for download here.

    Recently I was teaching a group of RPGers the joys of qualified data structures. I happened to mention how much simpler some of the new DS capabilities had made the techniques I use to avoid problems caused by record locks. It turned out that more than half of the audience had never heard of the technique. I guess that we all have a tendency to think that the techniques and tools that we use are common knowledge amongst other programmers. As an educator I should perhaps be less prone to this tendency than others, but nevertheless I often fall into this trap. With that realization came the thought that perhaps a tip or two on modern versions of such techniques would be a good idea.

    This first tip involves that record lock technique. The intent of the technique is to avoid situations where a user displays a record for update, and then goes off to the bathroom, break room, or whatever, and leaves the terminal signed on with the record locked. This can often cause another application to come to a grinding halt when it encounters the locked record. For this reason I’ve always believed it to be a good idea not to lock the record when it is being displayed, but rather only lock it during the actual update process, i.e., when the user submits the modified data.

    The disadvantage to this approach, of course, is that there is a possibility that the record could be changed by another process during the interval between it being initially displayed to the user and the subsequent update operation being performed. In order to protect against this the program maintains a copy of the original record and compares it with the version retrieved immediately prior to performing the update. In the event that the data has changed, an error message is sent to the user to inform them and ask them to redo the update if necessary. If there was no change in the data, then the update can proceed. For years I used multiple-occurrence data structures (MODS) in order to implement this technique, but switched to the version I’m discussing here as soon as DS arrays and DS I/O became available back in the V5R2 timeframe.

    So, the basic process is to read the record, without locking it, into DS array element 1. The data is then displayed to the user for update. Once the user requests the update, then the record is read again, this time into element 2. Elements 1 and 2 are now compared for equality. If they match then the update proceeds. If they do not, the user is notified and the latest version of the data presented.

    That’s the basic technique, now let’s look at the code that implements it. Note that while I have used fixed-format D specs in this text, the download version of the source includes a fully free version. (There has to be a better term that that!).

    Let’s begin by looking at the two data definitions that play a major role. At (A) you can see that I’ve defined a two element data structure array named custRec using the LikeRec keyword. At (B) the record for the display file fields is defined. This is also a likeRec DS and, as you will see later, defining it in this fashion makes it easy to copy the required data from the database record to the display format and vice versa thanks to EVAL-CORR.

    (A)  D custRec         DS                  Likerec(TestRec: *All) Dim(2)
    
    (B)  D displayRec      DS                  LikeRec(Disprec: *All)
    

    Moving on to the logic for loading and displaying a record, there are two things to note about the CHAIN. First is the use of the opcode extender N, which tells RPG not to lock the record even though the file is specified for update. The second is the use of the first custRec array element as the result field. This feature, in case you have not seen it before, has been available for externally described files since V5R2. I will briefly describe some of its other benefits later in this tip.

    If the requested record is found the EVAL-CORR (D) is used to load all the display file fields from the record image.

    (C)    Chain(N) displayRec.ARCode TestFile custRec(1);
    
           If %Found(TestFile);
    
    (D)      Eval-corr displayRec = custRec(1);
    

    The real meat of the process takes place in the update subprocedure. We begin at (E) by once again chaining to the file but note that this time the record is loaded into the second element of the array. This enables us to compare (F) the initial version of the record, i.e., the one we displayed to the user, with the latest version. Notice also that we did not use the N extender on this chain and therefore the record will have been locked for update. If the two record images are identical then the update can proceed. Again Eval-Corr (G) is used to copy the updated information from the display record to database image one. This image is then used to update the file.

    If the two images were not identical, then the user is advised that the record has been updated since it was originally displayed, and is prompted to try again. The important part of this process is shown at H. First the current record content is copied to the display file and then record array element 1 is also set to the current record content so that it is ready for comparison if and when the operator requests an update. Last but not least, the record lock is released (I) so that we don’t create the very situation we were trying to avoid. That’s the entire process.

    (E)    Chain displayRec.ARCode TestFile custRec(2); // Read and lock record
    
    (F)    If custRec(1) = custRec(2); // Compare with original
                                       // If no changes then update can proceed
    
    (G)      eval-corr custRec(1) = displayRec; // Update record image
             Update TestRec custRec(1);
    ...
           Else;
    ...
    (H)      eval-corr displayRec = custRec(2); // Reset display screen
             custRec(1) = custRec(2);  // and set image 1 to current record
    (I)      Unlock TestFile;
    

    Benefits Of Data Structure I/O

    For those of you unfamiliar with the use of DS I/O, there are a number of benefits that make it worth your consideration.

    First, as demonstrated in this example, it is a simple matter to retain multiple instances of a record either by using an array or simply by using different data structures. No need to copy the data before reading another record.

    Second, in many cases the I/O operation will be faster than when using the conventional RPG approach. The reason for this is simply that it is faster to move a large number of bytes from the record buffer to the DS than it is to move each of the fields individually.

    Third, it can help you avoid decimal data errors. But that is a whole topic in itself and will be the subject of my next tip.

    Jon Paris is one of the world’s most knowledgeable experts on programming on the System i platform. Paris cut his teeth on the System/38 way back when, and in 1987 he joined IBM’s Toronto software lab to work on the COBOL compilers for the System/38 and System/36. He also worked on the creation of the COBOL/400 compilers for the original AS/400s back in 1988, and was one of the key developers behind RPG IV and the CODE/400 development tool. In 1998, he left IBM to start his own education and training firm, a job he does to this day with his wife, Susan Gantner–also an expert in System i programming. Paris and Gantner, along with Paul Tuohy and Skip Marchesani, are co-founders of System i Developer, which hosts the new RPG & DB2 Summit conference. Send your questions or comments for Jon to Ted Holt via the IT Jungle Contact page.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    LaserVault

    Integrate Virtual Tape to Automate Your Backups And Strengthen Your Ability To Recover From Cyber Attacks And Disasters

    With most IT departments stretched thin, finding something that can quickly free up IT time is definitely a bonus. That’s why it’s important to stop and take a look at integrating virtual tape into your backup and recovery. Virtual tape is one of those technologies where once you have it, you’ll wonder why you didn’t do it sooner. See a demo and get a $50 gift card.

    But what is it about using virtual tape that makes it so worthwhile? Why is it that so many IBM i shops are already using or considering using virtual tape for all or part of their backup and recovery systems?

    Virtual tape and virtual tape libraries offer a way to both simplify and strengthen backup and recovery operations. By incorporating virtual tape technology, automation of backups becomes possible resulting in hundreds of hours saved annually for IT departments and personnel.

    “We needed to find a replacement that would lower the maintenance cost and reduce complexity of our backup and recovery functions without a major disruption to our operations.” David Fray, Director of Enterprise Systems, ABC Financial

    LaserVault ViTL is a virtual tape and tape library solution developed specifically for use with IBM Power Systems (from AS/400 to iSeries to Power 9s). With ViTL you can:

    • Replace physical tape and tape libraries and eliminate associated delays
    • Automate backup operations, including the ability to purge or archive backups
    • Remotely manage your backups – no need to be onsite with your server
    • Save backups to a dedupe appliance and the cloud
    • Recover your data at lightspeed greatly improving your ability to recover from cyberattacks
    • And so much more

    Sign-up now to see a ViTL online demo and get a $50 Amazon e-gift card when the demo is complete as our way of saying thanks for your time. Plus when you sign-up you’ll receive a free facts comparison sheet on using virtual tape vs tape so you can compare the functionality for yourself.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    LaserVault:  Outperforming Tape: Faster IBM i Backups with Fibre Channel. Webinar - March 3
    BCD:  Modernize Your IBM i Document Design and Distribution. Free Webinar: March 5
    System i Developer:  Upgrade your skills at the RPG & DB2 Summit in Dallas, March 17-19

    IBM Boosts Capacity On FlashSystem Arrays There Is No Lack Of RPG Programmers, IBM i Community Contends

    Leave a Reply Cancel reply

Volume 15, Number 04 -- March 3, 2015
THIS ISSUE SPONSORED BY:

WorksRight Software
Bug Busters Software Engineering
Northeast User Groups Conference

Table of Contents

  • Old Stuff, New Ways: Avoiding Record Locks
  • Case-Insensitive Searching Of Spooled Files
  • Git To GitHub

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Guild Mortgage Takes The 20-Year Option For Modernization
  • IBM i Licensing, Part 3: Can The Hardware Bundle Be Cheaper Than A Smartphone?
  • Guru: The Finer Points of Exit Points
  • Big Blue Tweaks IBM i Pricing Ahead Of Subscription Model
  • We Still Want IBM i On The Impending Power E1050
  • DRV Brings More Automation to IBM i Message Monitoring
  • Managed Cloud Saves Money By Cutting System And People Overprovisioning
  • Multiple Security Vulnerabilities Patched on IBM i
  • Four Hundred Monitor, June 22
  • IBM i PTF Guide, Volume 24, Number 25

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2022 IT Jungle

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.