Summary of Recovery Steps for Failed Connector to a Serialized List Structure

The previous The topic "Recovering Locks Held by Failed or Failing Connections" described in detail the considerations involved in planning recovery actions for a failed connector to a serialized list structure. This topic presents the key steps in time order to help you understand the sequence of events associated with the failure of a persistent connector:

A persistent connector fails while holding locks.
Peer connectors are notified of the failure through their event exits.
Peer connectors respond to this failure by performing recovery processing for the failed connector's work in progress and for locks held by the failed connector. Recovery could involve stealing locks held by the failed connector. Locks that are stolen from the failed connector by peer connections will not become persistent locks.
Peer connections provide an event exit response.
When all event exit responses are received by the system, it cleans up the failed connection.
If any peer connector indicated RELEASECONN=YES on its event exit response, the failed connector becomes undefined.

If the failed connector becomes failed persistent:

The system releases all locks associated with the connector that are held by the system.
All locks still held by the failed connector become persistent locks and have their LOCKDATA fields reset to zero.
The connector becomes failed persistent.
The system fails requests by surviving connectors to obtain the failed connector's persistent locks.
The system honors requests by surviving connectors to steal the failed connector's persistent locks.
When a new instance of the failed connector reconnects to the structure:
- It is reassigned its persistent locks, which now have their LOCKDATA fields set to 0. The reassigned locks are no longer considered persistent when they are reassigned to the connector; they are now ordinary locks held by the connector, subject to normal serialized list processing.
- Its notify exit can begin receiving control at once if there are requests for a lock held by the connector.
- The connector should issue the IXLLIST macro with LOCKOPER=READNEXT to identify any reassigned (previously persistent) locks it holds, and take appropriate recovery actions to handle the work that was in progress at the time of the failure.
- The connector should release the reassigned (previously persistent) locks once it has performed the recovery actions since the persistent locks and their resources have been cleaned up.

If the failed connector becomes undefined:

The system releases all locks associated with the connector — those that are owned by the connector and those that are held by the system on the connector's behalf.
The connector becomes undefined.
There are no persistent locks since the connector is no longer persistent.