Mysterious AS/400 record locking

560 pts.
AS/400 administration
AS/400 Records
Record lock
We have been experiencing a surge in the number of occurrences of record locks in our shop. We make sure we follow the rules for preventing record locks. But I have seen programs where the UNLOCK is not used even though the UPDATE operation is embedded in between If-EndIf statements. At first I thought these were the culprits but on further investigation, I found out that the record locks are released because these programs end with *InLR = *On. I say this because these progams are not maintenace programs. Although they are used by the maintenace programs, they run instantaneously. Now this question lingers in my mind in the absence of any other leadds: Is it possible for these programs not to release the record lock when the AS400 session hangs when the programs are running? Or is it possible for these programs to accidentally hold on to the record lock infinitely when other jobs attempt to contend for a lock to the same record?

Answer Wiki

Thanks. We'll let you know when a new response is added.

When an rpg program reads/or chains a file with update it will lock the record until
– the read/chain has (n)
– an update is issued
– an unlock is issued
– another read/chain is made by the file on the same access path
– the file is closed
– the program/job ends

However, these rules changed considerably with commitment control — is that in use?

If SQL is in use select for update can put on broader locks in conjunction with the commitment sql commit level.

It’s possible to capture the details of record locks — while they are in effect — file – record # – locking process/program/user.

Hope others have better advise.

Do your maintenance programs share the access paths with your utility programs? I’m not certain how that affects the setting of *inlr in the parent program.


Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Aalekhine68
    Hi Phil, Thank you for your answer. Commitment control is not in use. And yes I have instructed someone to look at who is locking the record the moment it happens. The problem is I am not around when the record locks happen. And I am just disappointed at the people who are because they do not know what to do to determine the cause. What they do is ask the users to write defect reports and let these occurrences go. Oh well... Also, the files do not share their data paths. I am just curious about what happens if the session hangs. Are those codes that do not unlock the records and whose UPDATE statements are embedded in between If-EndIf statements holding locks indefinitely? I think this is a question for one of the experts like Barbara Morris, huh?
    15 pointsBadges:
  • philpl1jb
    since those programs are ending with *INLR *on the files are closed and the records are not locked. The DBMS will wait for the length of time on the record wait variable on the file. If this is 1 sec then you might get time outs more frequently than if the file is set at 60 seconds. Phil
    54,090 pointsBadges:
  • Gilly400
    Hi, What do you mean by "when the session hangs"? Do you mean that the job is being ended for some reason? If for some reason a job is disconnected (someone cancels their emulation session for example) and the job doesn't end - then the job will likely still have locks in place. Another thing to look out for in your programs is the RETURN opcode or the *INRT indicator - if these are used before the *INLR is seton, then your files may stay open and locks may stay in place. Regards, Martin Gilbert.
    23,730 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: