When a failed persistent connector reconnects to a serialized list structure, the locks previously held by the connector, which remained as persistent locks, are reassigned to the connector. When a lock becomes persistent, the system sets its LOCKDATA field to zero. Once the connector is reassigned its persistent locks, the locks are no longer persistent. They are ordinary locks subject to normal serialized list processing. The LOCKDATA value of zero identifies a lock as having been persistent.

When you reconnect to a serialized list structure and you might own persistent locks, you should perform recovery processing for the work you were doing at the time of the failure. When you are finished with this recovery processing, you should reset any locks you no longer need. To identify the locks you own, scan the lock table using LOCKOPER=READNEXT with a LOCKCOMP containing your connection ID.

Once a failed persistent connector reconnects to the list structure, the connector's notify exit will begin receiving control when contention occurs for locks held by that connector. When the notify exit receives control for contention involving a formerly persistent lock, the NEPLOWNERPERSISTENTLOCK bit in the notify exit parameter list (NEPL) is set to indicate that the LOCKDATA associated with the lock is not valid (the LOCKDATA field is set to zero because the lock became persistent).