DEADLOK='iiii,kkkk' parameter for procedures

Use the DEADLOK='iiii,kkkk' parameter in procedure to specify the local deadlock-detection interval in seconds or milliseconds (iiii) and the number of local cycles (kkkk) that are to occur before a global detection is initiated.

The LOCKTIME parameter in the DFSVSMxx member of the IMS PROCLIB data set is also associated with IRLM deadlock management. See Enabling the IRLM lock timeout function for more information.

iiii: A 1- to 4-digit number from 1 to 9999 that specifies the length of time in seconds (1 - 99) or milliseconds (100 - 9999) that is used for the IRLM local deadlock detection interval. Values less than 100 are recognized in seconds with 5 seconds being the maximum used. Values from 100 to 9999 are treated as milliseconds and IRLM truncates this to even 100 millisecond increments, with a maximum value of 5000 (5 seconds).
Note: Once IMS TIMEOUT candidates time out, they remain timeout candidates and are presented to the timeout exit each Global deadlock cycle. IMS creates SMF 79.15 records when candidates are presented which are written to the SMF data sets (if enabled). If timeout candidates are found and the value for iiii is subsecond, there are many SMF 79.15 records written per second until the tasks are no longer waiting in IRLM.
kkkk: Specifies the number of local deadlock cycles performed before global deadlock detection is performed. The default is 1.

In data sharing environments, IRLM synchronizes all of the DEADLOK values in the group to the values specified on the most recent IRLM to join the group. The DEADLOK value may be changed by starting a member with the values desired, or by issuing the MODIFY irlmproc, SET, DEADLOCK= command.

Recommendation: Make sure that the installation specifies the same value for DEADLOK on all its IRLM start-up procedures, and use the START irlmproc command or the MODIFY command to override this value only when the interval must be changed from its original value.

If all members of a sysplex group do not support subsecond deadlock processing, the value range used by the group is 1 to 5 seconds, with values specified less than 1 second, changed to 1 second.

Recommendation: Specify the same values for the DEADLOK parameter on all your IRLM startup procedures if you do not want the value for the last IRLM to connect to the group to become the value for all.

Deadlock processing time is minimal if the number of locks that are HELD and WAITING is small. However, deadlock processing can affect system performance when IRLM encounters a real deadlock situation.

The amount of time to run deadlock processing is directly proportional to the number of resources HELD (this is a minor time component) plus the number of WAITERs (this is a major time component) on those resources.

If the WAITERs increase as a result of a real deadlock situation, the deadlock must be found as quickly as possible. The larger the number of WAITERs, the longer deadlock processing takes to find and break the deadlock. While deadlock processing is running, nothing else is happening with respect to that particular IRLM! The effect on performance is particularly significant in a Sysplex environment because any IRLM that is running deadlock processing can cause other members to slow down or stop processing if they need this IRLM to process another request.

The previous paragraph might imply that you should have the DEADLOK parameter on the local IRLM set as high as possible, which would cause deadlock processing to run the least. However, if a deadlock situation exists, the faster it is detected and broken, the better the system runs.

Recommendation: Carefully choose a value for the deadlock frequency that is high enough so that deadlock processing runs often enough to resolve deadlock situations and at the same time is low enough so that system performance is minimally affected. If you have many threads that are capable of becoming WAITERs, it is important to find and break that deadlock as quickly as possible before the WAIT chains require deadlock processing to run seconds (or even minutes) to perform a single local deadlock cycle. To find and break the deadlock is especially important in a Sysplex environment where multiple local cycles are required to break each deadlock, which in turn causes WAITERs to back up on all systems.

Recommendation: Monitor your system application programs for the actual number of deadlocks that IRLM had to break. If you find that the number of these deadlocks is low (or non-existent), you could raise the local deadlock value. If, however, you find that there are a lot of deadlocks that needed to be broken, you might consider having a low deadlock value.

Another aspect of deadlock processing and how it affects system performance is the number of locks that are held. IRLM must evaluate all held resources to check for WAITERs. Therefore, the amount of time that deadlock processing takes depends on the number of held resources (more held resources equals more deadlock processing time).