Record Locking

7/27/2019 Record Locking

1/3

Question:Hi everyone. We have a problem with several users trying to access the same record,at the same time. The timeout parm on the logical is set to 60 sec. and may notbechanged, because of another problem, but that another story :-) Is there anywaytotell there is a lock on a record without having to wait until the request timesout ??I use rpg/400. Please help..-------------------------------------------------------------------------------

Answer(s):Maybe you can create another logical file with the same key, using the same DDSbutgiving the object a different name. That way you don't have to use OVRDBF if atcreationtime you set the waiting time to just a few seconds. In the other hand you haveto determineif that is a good option; maybe you have already a lot of LF's and adding a newone wouldslow down you system's performance. I hope you find what you need between all the answers. :-)

-------------------------------------------------------------------------------Great. OSITim has mentioned OVRDBF in the first answer to the question. If you prolong the time,the user doesn't know why she/he cannot proceed. Most users will think that theAS/400-programis looping or crashed, just like their PC-programs do from time to time. Or theythink that theAS/400 is extremely slow and they ask whether to buy a Pentium-processor for theAS/400. Theymight even use Attn-2 to cancel or turn off the terminal (don't laugh! This shithappens!) toget rid of the Input Inhibited syndrome. This is the worst case scenario, as the

applicationprogram is most likely in a dangerous situation, from the point of view of the data. ---So if the techniques described so far aren't good enough, combine them with theold-fashionedway: some fields in the database that say "This record is locked by interactivejobnbr/user/jobsince timestamp".The applications are not allowed to lock records when they wait for user's input.They fill the fields mentioned above instead. They have to use error indicatorsonevery update/write, however. If something goes wrong, the program should do what

the MISpersonnel would do. (An AS/400 is said to be operator-less. Programmers should pay attentionto this point, especially when they have an OS that enables them to!) Batch programs do notchange the locked-fields, except they change the same fields that the user is enabled to change.But this should be avoided by means of mutexes or a self-written mechanism. If this is notpossible, the batch-program has to exclude soft-locked records. (10 of 11 record


2/3

s processed - 1not processed. Does this sound familiar?)Applications are not allowed to crash, they have to monitor everything (as mentioned above).Otherwise the soft-locker-fields still soft-lock the record, although the application isn'tactive any more. (Extremely uncomfortable with TCP/IP and changing device names!) That's whyi suppose to store the job number, user and job name. If the application runs into a "soft-lock",it might check whether the other job is still running. So, put as many thought-pieces togetheras you want and build a solution. OS/400 offers enough power to do it.-------------------------------------------------------------------------------

You can overwrite the record wait time in a CL pgm before calling the RPG pgm orin aQCMDEXC call before opening the file in the RPG pgm itself--------------------------------------------------------------------------------

I have this problem and the solution I came up with is :1. Use the error indicator on your chain command2. Immediately after your chain check the error indicator

3. At this point you can send the user a message telling them that the record isin use or asi did call a cl to send the operator/mis person a message to the effect that

???? has arecord lock.

4. They can then find the person who probably went on break with the record lefton their screen

and have them get out of it.5. You can then let the user enter a "r" to retry and have the program loop backto the chain

command or have the mis person handle the retry and the program automaticallyloop back to

the chain.

--------------------------------------------------------------------------------That's right... User B can be batch just as easily as interactive. In one application,with five users updating a database of 25,000 applicants and 40,000 certificaterecords,the record-lock condition happened around twice a year over a period of six years.No batch was involved, so take care on taking the ris--------------------------------------------------------------------------------

Another scenario:1. User A reads record 1 (no lock) and sits on it.

2. Another (batch) process changes information in the record that is not on UserA's screen.3. User A wants to update the record, but is informed that the record has changed.How annoying! We generally take the risk that 2 users might interfere and don'tworry about it.In the more than 10 years that my company is in business we never had a complaint from any ofour about 200 customers (which doesn't mean that it did not happen, of course).We once


3/3

developed a program template where only the fields that were modified on the screen wereoutput to the file, but it was a lot of coding, so we dropped it.--------------------------------------------------------------------------------

Since the original poster is new to the technique, it should be pointed out thatthe recordcontents should be rechecked before the update occurs.1. User A reads record 1 (no lock) and sits on it.2. User B reads record 1 (no lock) also.3. User B quickly re-reads the record (with lock) and updates it.4. User A finally re-reads the record (with lock) and updates it also.If the program doesn't verify that the record contents have changed between steps 1 and 4.User A will overwrite User B's changes.--------------------------------------------------------------------------------You might try using the error indicator on the CHAIN or READ operation you are using.I believe it's the LO column, but not sure. On the other hand, why is everyone locking a recordfor such a long time? Is this a file update program that someone likes to sit onfor a while,and not realize the problem they are causing? Or, could it be solved by using ano lock on the

input operation and then re-inputting (ie. CHAIN, READ) when actual update occurs? Then again,you could use a data q attached to the display file to kick someone off if theysit on the samerecord for more than say 45 seconds or so. This could be a design problem. I would look intousing the no lock option on your input operation until right before you do the update as afirst solution.--------------------------------------------------------------------------------

How is a SETLL and a READ different from a CHAIN on an input only file? This iswas

you're saying, right?--------------------------------------------------------------------------------

If you are not doing updates, then use SETLL then READ to retrieve the record.If you are using CHAIN, then use the 'N' to not lock the record. Hope this helps.-------------------------------------------------------------------------------

When you chain to the file, also use a low indicator. If it comes on, the recordisunavailable-so give your user a message to try later. Also, you might want to exploretechniques that limit record locking.

-------------------------------------------------------------------------------

If you can't *change* the WAITRCD parameter, then why don't you try usingthe OVRDBF with WAITRCD(0) in those programs that you don't want to have wait.

Documents

Record Locking