MVS™ allows a connected coupling facility application to request the following lock services through the IXLLOCK macro:

• Obtain either shared or exclusive ownership of a resource that is not currently owned or is pending ownership by this connected user and optionally assign additional user-defined ownership attributes. (REQUEST=OBTAIN)
• Alter the attributes of an owned resource or replace a previous OBTAIN or ALTER request which is pending on the contention exit resource request queue with a more current request. (REQUEST=ALTER)
• Release ownership of a resource or, if an outstanding request has been left pending on the contention exit resource request queue, replace the pending request with the more current request to release the resource ownership. As with the ALTER request, you can request that a resource be released before you have received the results of a previous request to OBTAIN or ALTER. (REQUEST=RELEASE)
• Process multiple requests for resources with a single IXLLOCK invocation. A lock request block specifies each individual request. You can request that the system service up to 128 requests. The set of request types (OBTAIN, ALTER, or RELEASE) supported by a PROCESSMULT request is a function of the version of the IXLLOCK macro. Version 1 of the IXLLOCK macro supports the PROCESSMULT request type and requires a coupling facility of CFLEVEL=2 or higher. (REQUEST=PROCESSMULT)

The IXLLOCK macro requires that you provide a predefined set of user exit routines that are necessary to accomplish the locking function. You specify the addresses of these routines when you connect to the lock structure with the IXLCONN macro.

• The contention exit is executed to resolve contention for a resource. Through the contention exit parameter list (IXLYCEPL), the contention exit can potentially direct XES to grant or deny a request for a resource, modify the ownership characteristics of one or more of the current resource owners, notify a current resource owner that contention exists, or take no action at all. The contention exit that is executed is that of the connected user that XES has assigned contention management responsibilities.
• The notify exit can be executed to inform a user that contention exists for a resource that the user owns. Only the contention exit of the connected user chosen to manage the resource contention can request that the notify exit be executed. The notify exit parameter list (IXLYNEPL) provides the user with information about all the current owners and requestors of the resource, in which the user can choose to update its interest in the resource and possibly eliminate the contention. The synchronous update is accomplished with the IXLSYNCH macro.
• The complete exit is the means by which XES presents the results of a user's request that could not be processed immediately but was processed asynchronously. The complete exit also is used to notify a user that its ownership state of a resource has been changed (regranted) by the connected user that is managing contention for the resource.
• The event exit is the means by which XES reports error and status conditions to connected users. Though not specific to locking functions, use of the event exit must be considered when designing a locking protocol.