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.