Using Lock Services (IXLLOCK)

The XES lock services allow sysplex-wide serialization in a multi-system data sharing environment. The services provided through the IXLLOCK macro enable authorized applications to obtain shared or exclusive serialization on user-defined logical resources. Additionally, you can implement your own locking protocols through the inclusion of user data. The XES lock services offer the additional benefits of allowing you to assist in the management of contention in the data sharing environment and of providing failure recovery options by retaining data about serialized resources that will persist across system outages.

The IXLLOCK macro provides services that allow you to request:
  • Shared or exclusive ownership of a resource (OBTAIN)
  • A change to the attributes of a resource that you currently own or are attempting to own (ALTER)
  • Release of the shared or exclusive ownership of a resource or cancel a previously submitted request that is pending (RELEASE).
  • Processing of multiple resource requests with a single macro invocation (PROCESSMULT). The types of resource requests that are supported are a function of the version of the IXLLOCK macro.

When you request an XES lock service, you must be connected to a lock structure in a coupling facility. The lock structure is the repository for the lock table that is used to monitor the serialization of resources in the sysplex and for the data being recorded for recovery purposes.

Intrinsic to the XES lock services are the user exit routines that provide the negotiation and contention management protocols for the data sharing application. The contention exit and the notify exit collaborate to resolve contention for shared resources. Other exits used by the XES lock services are the complete exit, to report the completion of a previously submitted request for a resource and the event exit, to report the occurrence of an event in the sysplex, such as another user failing, which might affect your processing.

Specifying the IXLLOCK ADUPREQSEQNUM or REQVERSION keywords will result in the generation of at least a version 4 parameter list. A version 4 parameter list requires system-managed asynchronous duplexing support. If a version 4 parameter list is used on a system that does not support it, the request is rejected for the unsupported parameter list version (IxlRsnCodeBadVersion#). Macro IXCYQUAA defines the QuReqRfAsyncDuplex bit in the QuReqFeatures string that can be used to test for system-managed asynchronous duplexing support. Use IXCQUERY REQINFO=FEATURES to get the QuReqFeatures string. It can be assumed that systems at a z/OS level that later than V2R2 will support system-managed asynchronous duplexing.