Sample Locking Protocol

The following illustrates a protocol in which an application uses IXLLOCK with user data to achieve its multi-system data sharing.

Application “A” is a multi-system application whose data is maintained in data sets residing on shared DASD. The application is required to access the data on behalf of requests from end users of the application as well as on behalf of utility functions that are periodically scheduled to perform maintenance activities. User requests are for a single record in the data set; utility requests are for a block of records on which maintenance is to be performed. The application is required to maintain the integrity of the shared data while providing efficient access to both types of processes. To accomplish this, the application has designed a locking protocol based on the XES lock services. A detailed description of the protocol follows.

Purpose

To provide a protocol that allows user requests for a resource to take precedence over utility requests for the same resource.

Design

All resource requests are to indicate whether they are user-initiated or utility-initiated and are to specify the exact records of the data set to which they require access. User requests will be served on a first-in first-out (FIFO) basis and will take precedence over utility requests. Under certain circumstances, utility functions that are current owners of a resource might need to negotiate the resource ownership. The negotiation is to be accomplished in the notify exit and could result in the utility function maintaining a subset of its resource ownership in order to allow the user request to be granted.

Requirements

The application must conform to the following:

Any request to access the data must result in the application issuing an IXLLOCK request specifying a resource name equal to the name of the data set containing the specified data.
A request to read the data must result in an IXLLOCK request for shared access; a request to update the data must result in an IXLLOCK request for exclusive access.
The user data specified with the IXLLOCK request must contain:
- Values indicating the first and last sequential records to be accessed.
- A process identifier field to indicate on whose behalf the serialization is being obtained. For example, if the request is to service a user, then the field will contain a value that indicates “user-initiated”.

The following table shows the required information that the application must specify to accomplish various requests for data access.

Table 1. Required Information for Application A. Information to be specified on an IXLLOCK request as a result of various tasks.
Action	Required Access
User request to read record 2 of data set ABC.	Shared access of resource, data set ABC, with user data indicating a first record of 2, last record of 2, and process identifier indicating “User”.
User request to update record 1 of data set DEF.	Exclusive access of resource, data set DEF, with user data indicating first record of 1, last record of 1, and process identifier indicating “User”.
Utility routine to perform maintenance activities on the first 100 records of data set GHI.	Exclusive access of resource, data set GHI, with user data indicating a first record of 1, last record of 100, and process identifier indicating “Utility”.

Rules of the Sample Protocol

The protocol defines the following rules for the management of contention.

If a request is made that requires access to a record within a block that is already serialized, then it is treated as a conflict.
Conflicting user requests are processed in FIFO (first-in first-out) order.
User access is to be given priority over access by utility functions.
Negotiation is required when utility functions that hold serialization conflict with a new user request for the resource.

Rule 1 — Conflict
XES recognizes contention on a resource level, which is the data set level in this protocol. This implies that requests to access the same data set in incompatible states will result in XES assigning management responsibilities to the contention exit of one of the instances of the application. Contention exit processing is to examine the first and last record indicators in the user data to determine if the requests are to access different portions of the data set and thus are compatible. For example,
- Instance 1 of Application A receives a user request to read record 2 of data set XYZ. Instance 1 issues an IXLLOCK request for shared access of data set XYZ, with user data indicating that the request is to access record 2.
- XES grants the IXLLOCK request.
- Instance 2 of Application A receives a user request to update record 8 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 8.
- 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 user data and determines that the requests are to access different records in the data set. The contention exit instructs XES to grant Instance 2's request.
Rule 2 — FIFO Order
If two or more user-initiated requests for the same resource cause contention, contention exit processing is to handle the requests in the order in which they are received. For example,
- Instance 1 of Application A receives a user request to read record 2 of data set XYZ. Instance 1 issues an IXLLOCK request for shared access of data set XYZ, with user data indicating that the request is to access record 2.
- XES grants the IXLLOCK request.
- Instance 2 of Application A receives a user request to update record 2 of data set XYZ. Instance 2 issues an IXLLOCK request for exclusive access of data set XYZ, with user data indicating the request is to access record 2.
- 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 user data and determines that the requests are to access the same record in the data set and notes that both requests are user-initiated. The contention exit instructs XES to leave Instance 2's request pending.
- When Instance 1 (who owns the resource in a shared state) completes its processing, it issues an IXLLOCK request to release its interest in data set XYZ.
- The release request is added to the resource request queue and presented to the contention exit who continues to manage this occurrence of contention.
- The contention exit examines the request queue and sees that Instance 1 is releasing its interest in the resource and that the request by Instance 2 is still pending on the request queue. The contention exit instructs XES to grant Instance 2's request.
  Note that when XES receives control back from the contention exit and processes these requests, the resource will no longer be in contention as the request queue will contain one exclusive owner (Instance 2). The contention exit will, therefore, have completed its duties as contention manager. Should another instance of contention for this resource occur, this contention exit is not necessarily the one that XES will choose to manage the contention.
Rule 3 — User Precedence
When requests from a utility function conflict with user-initiated requests that currently hold serialization on the resource, the utility request must wait until the user releases its serialization.
Rule 4 — Negotiation
When requests from a user conflict with a utility function that currently holds serialization on the resource, the conflict is resolved by negotiation, as follows.
- XES informs the current resource owner (the utility function) that there is contention for the resource through its notify exit.
- The notify exit of the utility function can examine the resource request queue, as presented in the notify exit parameter list (NEPL), to determine if it is able to change its current ownership characteristics and thus allow access to be granted to the user.