Continue Contention Management

Subsequent to its first invocation of the contention exit, XES may invoke the exit at each of the following times while the connector remains the contention manager:

A new request is received for the resource while contention exists
Once the entries on a resource request queue have been determined to be incompatible and as long as the incompatible condition exists, any new request for the resource causes the contention exit to be given control. Note that XES determines the state of the resource request queue after all actions specified during the previous invocation of the contention exit have been performed.
The completion of notify exits
When a resource request queue is presented to the contention exit, the connected user that is managing the contention can indicate that the notify exit of resource owners be scheduled for processing. After all specified notify exits have completed, the contention exit is again given control. The resource request queue reflects the changes, if any, that connected users made to their ownership of the resource in the notify exit.

Note that the contention exit may supply a return code specifying that if the results of notify exit processing cause contention to cease, XES is not to redrive the contention exit.
Failure of a previous grant request
If XES is unable to grant a pending request as specified by the contention exit, XES redrives the contention exit with an indication in the CEPL of the failure. Among the reasons for the failure to grant the request are an associated record data entry operation which could not be completed or a loss of connectivity to the lock structure.
The resource request queue presented to the contention exit reflects all updates made in the previous invocation of the exit, but may or may not contain an entry for the user whose request has failed.
- If the failed request was for a resource that was not previously owned, the updated resource request queue will not contain an entry for the failed request.
- If the failed request was to update (ALTER) an already owned resource, the updated resource request queue will contain an entry for the resource that reflects the ownership state of the resource before the failed attempt to update it.
Note: Any requests to execute notify exits that were made during the invocation of the contention exit which specified to grant a request are cancelled.
During recovery processing for a failed connection
XES removes entries representing a failed or disconnected user from all resource request queues as part of its cleanup processing. If cleanup occurs for a request queue that is being managed by a surviving connected user then the updated request queue is presented to the contention exit of that user with an indication that recovery has occurred.

Note that XES will not interrupt the normal processing flow to inform the contention exit that a failure has occurred. For example, if a contention exit is waiting for responses from notify exits to complete at the time that cleanup is being performed on the resource request queue then the contention exit will be informed of the failure at the time that it is invoked with the results of the notify exits. In this case, the contention exit parameter list will indicate that the queue reflects results of notify exit processing, as well as recovery actions.

In summary, the contention exit may be informed of a change in the resource request queue due to failures during any invocation. This includes when the exit is called for normal processing such as presentation of new requests and results of notify exit processing, as well as through a separate invocation when the failure represents the only change in the queue. If an application's protocol calls for its contention exit to be sensitive to failures of related users, the exit should check the failure indicator (CEPLRECOVERY) during each invocation of the exit.

Note that the CEPLREASONFLAGS indicate why the contention exit has been given control. The CEPLNOTIFYRESPONSE, CEPLGRANTFAILED, and CEPLRESTARTAFTERDEFER flags are mutually exclusive. However, it is possible for the CEPLRECOVERY flag to be set to ON in conjunction with one of the other CEPLREASONFLAGS.