IRLM delays in a data sharing environment

IRLM can experience delays in child lock propagation

The following events can cause IRLM to experience delays in child lock propagation:

  • Member recovery

    XES delays work but does not inform IRLM of the failed connection.

  • Loss of connectivity of a lock structure

    XES delays work but does not request IRLM to rebuild or disconnect a lock structure.

  • XES is slow to process a lock request for an undetermined reason.

IRLM can also experience a delay in P-lock negotiation. A common reason for a delay in P-lock negotiation is that an active log is full, and Db2 is waiting for the operator to mount an archive tape.

If your data sharing system experiences delays in child lock propagation or P-lock negotiation, you can request dumps of all IRLM instances in the data sharing group when a delay for child lock propagation lasts 45 seconds or more, or a delay for P-lock negotiation lasts two minutes or more. Issue this console command to request IRLM dumps for delays in child lock propagation: 
MODIFY irlmproc,DIAG,DELAY
Issue this console command to request IRLM dumps for delays in P-lock negotiation: 
MODIFY irlmproc,DIAG,PLOCK
Issue this console command to request IRLM dumps for either type of delay: 
MODIFY irlmproc,DIAG,ALL

You need to issue MODIFY irlmproc,DIAG commands on only one member of a data sharing group. These commands are sent to all peer members to capture the same dumps from each member. A MODIFY irlmproc,DIAG command is active for only a single incident on a single member. After dump processing is triggered for a specific incident, dump collection for later incidents of that type are disabled. If diagnosis of another incident is needed, issue the MODIFY irlmproc,DIAG command again.