Mysterious AS/400 record locking
Home > IT Answers > AS/400 > Mysterious AS/400 record locking
Bogeybetsy
325 pts.
0
Q:
Mysterious AS/400 record locking
Record lock, AS/400 Records, AS/400 administration
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?
ASKED: Jan 17 2009  10:44 AM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
RELATED QUESTIONS
0
Philpl1jb
24610 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
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.

Phil
Last Answered: Jan 18 2009  2:46 AM GMT by Philpl1jb   24610 pts.
  •   
0
0
RSS - Discussions Help
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Aalekhine68   15 pts.  |   Jan 18 2009  9:08AM GMT

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?

 

Philpl1jb   24610 pts.  |   Jan 19 2009  2:59AM GMT

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

 

Gilly400   23625 pts.  |   Jan 19 2009  12:33PM GMT

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.

 
0