Structure or connection persistence occurs

Structures on the failed CF become persistent or structure connections become failed-persistent. This might happen for the following reasons:

Structure rebuild failed.
- An alternate CF did not exist.
- Structure rebuild is not supported by the owning application.
An application failure occurred.

If the application that owns a persistent structure or connection is restarted while the CF remains unavailable, its attempt to connect to the structure may not succeed (see A Review of the Concept of Persistence). A recovery bind is maintained, represented by the persistent structure or failed-persistent connection, to the instance of the structure that was in use at the time of the failure. Until and unless connectivity to the CF containing that structure is restored, z/OS® does not know whether the CF has truly failed (with the loss of structure data that implies), or z/OS has simply lost connectivity to the CF (with the implication that access to the data will be restored when connectivity to the CF is restored). This recovery bind will be maintained until one of the following events occurs:

Connectivity to the CF is restored, and the structure is found to still exist (a loss and regain of connectivity scenario)
Connectivity to the CF is restored, and the structure is found to no longer exist (a true CF failure scenario)
Deletion of the structure or connection is forced (for example, via the SETXCF FORCE system command).

Thus, if you want to restart the application and have it allocate another instance of the structure in an alternate CF, you must first break the recovery bind to the old instance of the structure by deleting the persistent connections or the structure before structure allocation succeeds. See A Review of the Concept of Persistence before proceeding with structure or connection deletion.