Locks and Deadly Locks

This is one of the scenarios of Degradation trouble shooting ... the 400 seems to have put on brakes with performance ... what could be the cause of this?

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 update programs avoid this is to temporarily lock that which is to be updated until each update program has done its thing, then release the record for other update 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.

Provided Inquiry programs and Report Programs are not doing any updating, they have unfettered access to the data, so their access is not slowed down by the locking. Only the update programs are affected.

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, then 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 has got 4 and 3 locked and now needs to lock 2 but program A has got 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.

One of the two programs will have to be killed, and it is up to IT in consulation with what users are doing, to determine which kill will do the least damage.

Once we have identified that certain programs are at risk of this happening, human procedures can be put in place to avoid reoccurence, such as always run program A and B on same JOBQ so they never doing their updates at same time. Failure to adhere to such a rule of thumb is what I mean by poor implementation.

Next is the question of whether this software can be fixed. What changes to Program A and B so that they can run at same time without conflict.