Locks and Deadly Locks

Locks

Locks are normal.

GO CMDLCK

RPG reads an entire record into a program which will be updating the record on some account, item, customer, order, whatever. Different programs in the hands of different users might be updating different fields such as:

• Inventory Totals
• $ Financials
• Alphabetical descriptions

We want to avoid conflicts between the different people who might be updating different fields in the same records at the same time.

Without locks, there is the danger that several programs might read in the data on some record into the program work area, change one or more fields, and be doing this concurrently with some other program. Thus when one program writes copy of the data back to the file, with one field updated, the other programs still have copy of the data prior to this update, then when they write the data back with their field updated, the earlier program's update is lost.

One way that programs avoid this is to temporarily lock that which is to be updated until each program has done its thing, then release the record for other programs to access. Normally program access, update, replace, is over in microseconds so users not notice this is going on. However, sometimes we have poorly written programs, and users who get called away from their work station while they are in middle of an update program, so whatever record they were on is locked until they get back from the interruption, need to go to the bathroom, or lunch, or whatever.

For the victim here, it is like someone slammed on the brakes of 400 productivity, it seems like their program has locked up. Well in reality their program is waiting on someone else to get done. There was nothing wrong with their program until they cause it to be abnormally ended because they think something is wrong with it. Now something is wrong, because of the abnormal ending.

Deadly Locks

Deadly Locks are a symptom of poor software design and/or poor implementation practices.

A program may need to lock several files before updating them all, the unlock all of them.

Let's suppose program A has locked files 1 2 and is about to lock #3 except target-3 is already locked by program B which tried to do its locking in sequence 4 3 2 and it is got 4 and 3 locked and now needs to lock 2 but program A has bot that locked.

Program A will wait until Program B is done with file 3, then lock it, do the updates, release locks on 1 2 3.

Program B will wait until Program A is done with file 2, then lock it, do the updates, release locks on 4 3 2.

Except in this scenario, called a deadly embrace, both programs will wait forever.