program-1 accesses segment-A, then segment-B
while at the same time,
program-2 access segment-B, then segment-A
This creates an AB-BA deadlock, halting progression for both applications.
Additional, more complex scenarios are also possible with three or more programs.
The first line of defense against deadlocks is to avoid coding deadlock scenarios into your applications.
However, when a deadlock does occur, IMS DB Control can help by detecting deadlocks caused by contention for IMS database data.
When a deadlock occurs, DB Control chooses a loser and terminates the DLI call returning an FD status code. This FD status code triggers a system-issued ROLLBACK operation on behalf of the application program. IMS BMP and CICS programs receive the FD status code in response to the DLI call. IMS transactions automatically restart.
The deadlock loser is chosen based on the application type, number of DLI calls, and duration of execution. An IMS MPP is chosen before a CICS transaction, and a CICS transaction is chosen before a BMP. When the sessions involved in a deadlock are all of the same program type, the number of DLI calls in the current unit-of-work is compared and the session with the lowest number is chosen as the loser. If the number of DLI calls in the current UOW match, the session with the shortest duration is chosen as the loser.
By setting the ES_IMS_DEADLOCK_WAIT environment variable, you can delay the algorithm that tests for deadlocks. This ensures that DB Control threads don't spend CPU cycles at every data contention point:
ES_IMS_DEADLOCK_WAIT=n
Where n is expressed in milliseconds in the range of 1-65535. The default value is 1000 milliseconds.
To help diagnose application deadlocks, the following environment variable triggers a system dump when a deadlock is detected.
ES_IMS_DUMP_ON_DEADLOCK=1