Programming Considerations

In certain instances, XES must quiesce the activity of user exits in order to perform cleanup processing. The following illustrates scenarios where this processing occurs:

Connection Termination
When a user disconnects or abnormally terminates, XES will force to completion any user exits executing on behalf of that user by issuing a PURGEDQ against the appropriate units of work. Note that if a connector terminates while a rebuild is in progress, any exits pertaining to both the original and the new structures will be forced to completion. In addition to forcing the currently executing user exits to completion, XES will also prevent any new invocations of these exits by cancelling any events that are pending presentation.
Rebuild Stop
When a connector provides an event exit response for the Rebuild Stop event, XES will force to completion any exits that are executing on behalf of that user's connection to the new structure by issuing a PURGEDQ against the appropriate units of work. Similar to connector termination processing, the user exits pertaining to the new structure will not be presented with any additional events. Note that any user exits executing on behalf of the original structure are unaffected by rebuild stop processing.
Completion of a Rebuild
When a connector provides an event exit response for the Rebuild Cleanup event, XES will force to completion any user exits that are executing on behalf of that user's connection to BOTH the original and the new structures by issuing a PURGEDQ against the appropriate units of work. No new events will be presented to the user exits on behalf of the original structure (as it is being discarded). Normal user exit processing will resume for the rebuilt structure upon completion of the rebuild process.

A user exit must be sensitive to conditions that can occur as a result of actions taken by XES and must be able to handle these as appropriate. For example, if a user exit has suspended itself, when the PURGEDQ is issued the system abends the user exit's unit of work with a retryable X'47B' abend and gives control to the user exit's recovery routine. (Note that although the recovery routine can retry, the user exit can not re-suspend itself because the system will fail any request to suspend a unit of work that has been the target of a PURGEDQ.) If the recovery routine percolates back to the system, its associated connection is terminated.

Avoiding Deadlocks

XES serialized connection recovery processing, such as that for cleaning up for a disconnected or failed peer connection, and rebuild processing serializes against mainline IXLLOCK and IXLSYNCH requests by obtaining internal latches. To avoid potential deadlocks, exploiters of IXLLOCK and IXLSYNCH requests should consider having a separate unit of work available or specify a MODE/MODEVAL with the request that allows control to be returned whenever XES encounters a delay. This would allow responses to required events to be provided in a timely manner.

In situations such as when a connector to a lock structure fails and a surviving connector's event exit receives the DISCFAILCONN event, but cannot provide the response for it until a previously issued IXLLOCK or IXLSYNCH request completes, a deadlock condition might be experienced when the request gets serialized behind an internal latch held by XES serialized connection recovery. The deadlock might result bacause the exploiter cannot respond to the required DISCFAILCONN event until the IXLLOCK or IXLSYNCH request completes, and XES cannot complete IXLLOCK or IXLSYNCH processing until the response to the DISCFAILCONN is received (allowing XES serialized connection recovery serialization to be released).