When one transaction needs exclusive use of some resource, which is already held by another transaction, which is waiting for a transaction exclusively held by the first transaction, a dead lock occurs. The only way of breaking deadlocks is to cancel both the transactions.

There are 3 major causes for deadlocks. When a record is being updated or deleted the transaction has exclusive lock on that record. This record may be required by some other transaction. Say for example transaction A wants to update record 1 and for updating the record, it has to read record 1 form another file say file 2. So it gets exclusive control over record 1 of file 1. During the same time transaction B tries to delete record 1 from file 2, so it tries and gets an exclusive lock on record 1 of file 2. But before deleting the record, the transaction has to check the status field in the record 1 of file 1. So transaction A waits for transaction B to release the file 2 while transaction B waits for A to do the same with file 1. The result is a Deadlock.

Another situation is where a VSAM (KSDS, ESDS or RRDS) file is being modified. Here the transaction gets exclusive control over not only the record but also the Control Interval (CI). This can cause deadlocks. A third case, is where the resource, say the file has been defined as recoverable. In the case of recoverable resources, the record will remain locked till the Logical Unit of Work is finished or a Sync point is requested. This also causes deadlocks.

The transaction deadlocks can be very costly and frustrating to the user of the on-line system. Hence always try to avoid them. If possible, on-line updates, deletes, etc., which locks the resource should be avoided. Instead batch jobs can be run for doing the same jobs.

The READ for UPDATE command should be paired with WRITE, DELETE or UNLOCK command so that the exclusive lock is released. The WRITE with MASSINSERT option should be followed up with an UNLOCK command and while doing the mass insert no other operation should be performed until the UNLOCK command is issued.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Mainframe Topics