The connection disposition (CONDISP) allows you to specify how to handle a connection to a coupling facility structure that ends abnormally. The connection disposition determines in the event of a failure whether or not the connection remains defined to the structure. (A failed connection can be the result of a task, address space, or system failure, or REASON=FAILURE on the IXLDISC macro. See Disconnection Because of Failure.)

A connection disposition of KEEP indicates that when the connection fails, the failed connection remains defined as a failed-persistent connection and the structure remains allocated. For a connection disposition of KEEP, you must specify a connect name (CONNAME) on IXLCONN. The system uses the connect name to determine when you can reestablish the connection after a failure has occurred. CONNAME uniquely identifies your connection to the structure.

If a connection with a disposition of KEEP fails, the system considers the connection to be in a failed-persistent state. The connection remains in that state until a new instance of the failed connection, a peer connection, or an operator or program take actions to change it. When the application restarts and reissues an IXLCONN request for the structure, the same CONNAME that was specified on the previous IXLCONN request must be specified. If the reconnection is successful, IXLCONN returns a return code X'4'. The CONARECONNECTED flag in the connect answer area (IXLYCONA) is set to indicate that the connection has been reestablished.

A peer connection can indicate after recovery processing that a connection should no longer be failed-persistent by issuing IXLEERSP or by setting a return code in the event exit parameter list (IXLYEEPL). See Deleting Failed-Persistent Connections. Once all peer connections have completed their recovery processing for the failed connection and have responded to the Disconnect/Failed User event, the failed-persistent connection can be deleted. The operator can use the SETXCF FORCE command or an authorized program can issue the IXLFORCE macro to delete a failed-persistent connection.

A connection disposition of DELETE indicates that the connection should become undefined to MVS™ in the event of a failure. If the connection disposition is DELETE, then you are not required to specify CONNAME; however, if you do not provide a connection name, MVS generates one.

If the connection terminates normally (disconnect with REASON=NORMAL or REASON=DELETESTR ), the persistence attribute for the connection does not apply, and so the connection becomes not defined. However, if a connector to a lock structure disconnects with REASON=NORMAL or REASON=DELETESTR while still owning resources associated with the lock structure, XES converts the reason to REASON=FAILURE.