Two tasks are deadlocking on the same database resource

Document ID : KB000012779
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

Two tasks are accessing the same database at the same time. It is perfectly possible that they run into a deadlock situation with each other.

In such case, CA IDMS catches this deadlock, abends one of the tasks (with an xx29 error status), and writes messages DC001000, DC001001 and DC001002 into the IDMS log. These messages also identify the database resources which were the subject of the deadlock. Usually, they consist of two DIFFERENT resources.

However, it is also possible that only ONE database resource is involved in the deadlock.

Example :

DC001000 V67 T15 T:000000093 TSK1     P:DCEMP2   C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01          
DC001001 V67 T15 Txn/RU ID  RU  NAME   SUBSC    User ID             FE - ID1  FE - ID2  FE - ID3  FE Tskcd
DC001001 V67 T15 000034139  DCEMP2    EMPSS01   USRA03           
DC001000 V67 T15 T:000000095 TSK2     P:DCEMP2   C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01          
DC001001 V67 T15 Txn/RU ID  RU  NAME   SUBSC    User ID             FE - ID1  FE - ID2  FE - ID3  FE Tskcd
DC001001 V67 T15 000034140  DCEMP2    EMPSS01   USRA01           
DC001002 V67 T15 T:000000095 TSK2     P:DCEMP2   C:DEAD DEADLOCKED ON R:LTXNLOCK 00000008 0124FF01       

In this case, both tasks TSK1 and TSK2 ran into a deadlock with each other on the same database record with dbkey 75007:1

 

Question:

Is this normal, and if so under what circumstances can this happen ?

Environment:
IBM z/OS, z/VSE, z/VM
Answer:

This is how the above situation could happen :

Task TSK1 starts a Cobol/DC program DCEMP2, and opens an UPDATE run unit against the EMPDEMO database. It reads an EMPLOYEE with EMP-ID 0001. When this EMPLOYEE record is read, CA IDMS places a shared lock on the record.

Assume that, at that time, task TSK2 also starts a DC program, opens an UPDATE run unit against the same EMPDEMO database and also reads EMPLOYEE with EMP-ID 0001. Again, CA IDMS places a shared lock on the record.

Then, TSK1 wants to update that EMPLOYEE record. To do so, CA IDMS needs to put an exclusive lock on the record. However, the shared lock set by TSK2 prevents us from placing the exclusive lock, and as such, TSK1 goes into a wait.

After that, TSK2, in turn, also wants to update the EMPLOYEE record. Here too, CA IDMS needs to place an exclusive lock on the record, but this cannot be done, due to the shared lock held by TSK1. Result : TSK2 goes into a wait.

The deadlock detector (RHDCDEAD) of CA IDMS detects this situation and will abend one of the tasks. The deadlock messages will point to the same database resource as illustrated above.

 

Additional Information:

More information about locking can be found in our Navigational DML Programming Reference, section Run Units, Locks, and Database Transactions which can be found using following url :

https://docops.ca.com/ca-idms-ref/19/en/navigational-dml-programming-reference/run-units-locks-and-database-transactions