It is possible to encounter a situation where a deadlock involves only one task. How can a task deadlock on itself? Messages such as the following are seen on the log:
IDMS DC001000 V1 T13 T:000000150 EMPBPGM1 P:EMPBPGM1 C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01
IDMS DC001002 V1 T13 T:000000150 EMPBPGM1 P:EMPBPGM1 C:DEAD DEADLOCKED ON R:LTXNLOCK 00000008 0124FF01
Release: All supported releases.
What's happening here is that program EMPBPGM1 has bound a run-unit and has read the record with dbkey x'0124FF01' (75007:1). It has then called another program which has bound its own run-unit, and has read the same record and is also trying to update it. This results in a deadlock. One of the tasks is aborted with an xx29 error-status and the other is allowed to proceed.
In the above example, the T:00000150 identifies the task, not the transaction. By enabling DEADLOCK_DETAILS=ON in SYSIDMS, extra DC001001 messages are written which help identify the two transactions and the program name.
IDMS DC001000 V1 T13 T:000000150 EMPBPGM1 P:EMPBPGM1 C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01 IDMS DC001001 V1 T13 Txn/RU ID RU NAME SUBSC User ID IDMS DC001001 V1 T13 000039872 EMPBPGM1 EMPSS01 USER01 IDMS DC001001 V1 T13 000039873 EMPBPGM2 EMPSS01 USER01 IDMS DC001002 V1 T13 T:000000150 EMPBPGM1 P:EMPBPGM1 C:DEAD DEADLOCKED ON R:LTXNLOCK 00000008 0124FF01
Note also that in this case where only one task is involved, there can also only be one resource (dbkey) involved.
The solution to the deadlock itself is either to use TRANSACTION SHARING, or to change the application program structure such that they share the same run-unit.