What's happening here is that program EMPBPGM1 has bound a run-unit and has read the record with db-key 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 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 V65 T13 T:000000150 EMPBPGM1 P:EMPBPGM1 C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01
IDMS DC001001 V65 T13 Txn/RU ID RU NAME SUBSC User ID
IDMS DC001001 V65 T13 000039872 EMPBPGM1 EMPSS01 USER01
IDMS DC001001 V65 T13 000039873 EMPBPGM2 EMPSS01 USER01
IDMS DC001002 V65 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 (db-key) involved.