Sample Locking Protocol — Implementation

The following illustrates Application A's implementation of the protocol using the user data.

A utility program is scheduled to perform maintenance operations on the first 100 records of data set XYZ and submits a request to do so. Instance 1 of Application A receives the request and issues an IXLLOCK request for exclusive access of data set XYZ, with user data indicating that the request is to access records 1 through 100.
XES grants the IXLLOCK request. The utility program begins its maintenance procedures starting with record 1 of data set XYZ.
Instance 2 of Application A receives a user request to update record 6 of data set XYZ. Instance 2 issues an IXLLOCK request for exclusive access of data set XYZ, with user data indicating that the request is to access record 6.
XES recognizes that there is an incompatible request for the resource, data set XYZ, and chooses a contention exit to manage the contention.
The contention exit chosen to manage the resource contention examines the resource request queue, as presented in the contention exit parameter list (CEPL), and determines that the serialization held by Instance 1 on behalf of a utility program is preventing access by Instance 2 on behalf of a user. The contention exit instructs XES to schedule the notify exit of Instance 1 by setting the appropriate indicators in the CEPL entry that represents Instance 1's ownership of the resource.
When control returns from the contention exit, XES examines the CEPL and determines that the contention exit has requested that the notify exit of Instance 1 be run. XES schedules the notify exit of Instance 1, passing the resource request queue in the form of a NEPL.
The notify exit of Instance 1 receives control and examines the resource request queue in the NEPL. Meanwhile, the utility program continues its processing and has completed processing the first 20 records of data set XYZ. The notify exit determines that the utility program no longer needs access to those 20 records, and updates the user data in the NEPL to indicate that it needs serialization only to records 21 through 100. The change in ownership reflected in the updated NEPL is committed by invoking the IXLSYNCH service. Additionally, the notify exit might need to update the application's control structures to reflect the change in ownership status that was committed with the IXLSYNCH service. The notify exit then returns control to XES.
XES presents the updated resource request queue (in the CEPL) to the contention exit.
Note that XES will not add any new requests for the resource to the resource request queue until it has had a chance to examine any changes made as a result of the invocation of the notify exit.
The contention exit examines the resource request queue and determines that the user request for record 6 is NOT in conflict with the utility program, whose user data now indicates that it is serializing records 21 through 100. The contention exit instructs XES to grant Instance 2's request.