z/OS MVS Planning: Global Resource Serialization
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Limiting global resource serialization requests

z/OS MVS Planning: Global Resource Serialization
SA23-1389-00

Global resource serialization allows an installation to share symbolically-referenced resources between tasks. The installation must write its applications to share DASD, and is responsible for establishing the protocol to ensure data set integrity. A global resource serialization request is an ISGENQ (ENQ) or RESERVE request that causes an element to be added to any queue in the global resource serialization queue area.

If you build a multisystem sysplex, you automatically build a global resource serialization complex with it. As the systems join the sysplex, the systems join the global resource serialization complex. See z/OS MVS Setting Up a Sysplex for information about a sysplex and how your installation can use global resource serialization.

Use ISGQUERY or GQSCAN to obtain the status of resources and requesters of resources.
Understanding concurrent request counts: Each ENQ, DEQ, RESERVE and ISGENQ request typically causes an update to either the concurrent unauthorized or authorized count, depending on the authority of the requester. An ENQ or ISGENQ REQUEST=OBTAIN request will cause the respective count to increment.
  • Typically an ENQ, RESERVE or ISGENQ REQUEST=OBTAIN request will cause the respective count to increment.
  • ENQ RET=CHNG, RET=TEST, ISGENQ REQUEST=CHANGE and REQUEST=OBTAIN TEST=YES do not cause the count to increment
  • DEQ and ISGENQ REQUEST=RELEASE cause the count to decrement.
  • GQSCAN and ISGQUERY REQINFO=QSCAN can also cause an increment of the count, but only when there is insufficient answer area space for the results and a resume token is returned.
  • GQSCAN and ISGQUERY REQINFO=QSCAN requests are always added to the unauthorized count — even when the service issuer is authorized.
To determine various related ENQ statistics regarding authorized and unauthorized requesters, use ISGQUERY REQINFO=ENQSTATS by ASID to query:
  • Peak address space count of concurrent ENQs
  • Current address space count of concurrent ENQs
  • Current address space specific concurrent ENQ maximums
  • Current system wide concurrent ENQ maximums
  • Largest peak address space count of concurrent ENQs across the system
  • ASID of the address space with that largest peak.

There are thresholds for the number of requests that global resource serialization will accept from a single address space. These thresholds prevent one address space (job, started task, or TSO/E user) from generating enough concurrent requests to exhaust the resource queue area.

If these values do not suit your installation's needs, you can change them by using the ISGADMIN macro. The ISGADMIN service can raise subsystem-specific maximums for unauthorized and authorized requesters. For unauthorized callers, the threshold value supplied by IBM® is 16,384 (X'4000'). For authorized callers, the threshold value supplied by IBM is 250,000 (X'3D090'). The threshold values apply to an individual system in your global resource serialization complex, so different systems can have different limits.

The system does not reset the values to the system defaults when a job or the cross memory owning TCB terminates. As such, it is the responsibility of the ISGADMIN REQUEST=SETENQMAX invoker to issue a corresponding ISGADMIN REQUEST=RESETENQMAX or REQUEST=SETENQMAX to the previous values when control is given up and the higher values are no longer required. The system does not stack ISGADMIN SETENQMAX requests. An ISGADMIN REQUEST=RESETENQMAX can undo a previous setting. When the higher values are no longer required, issuing an ISGQUERY REQINFO=ENQSTATS can obtain the values to be restored.

In an urgent situation, you can use the SETGRS command to set the limits overall. Applications that require higher values must take the overall system requirements into consideration and properly manage limit requirements through the ISGADMIN service.

As each ISGENQ, ISGQUERY, ENQ, RESERVE, and GQSCAN request is received, global resource serialization determines if increasing the count will exceed the allowed threshold value. If the threshold will be exceeded, GRS will issue:
  • A return code of X'0C01' for ISGENQ OBTAIN requests to indicate the limit of concurrent resource requests is reached.
  • A return code of X'0C06' for ISGQUERY requests.
  • An abend X'538' for an unconditional ENQ or RESERVE
  • A return code of X'18' for a conditional ENQ or RESERVE
  • A return code of X'14' for GQSCAN requests that do not fit into the caller's buffer; the requests are not queued and a TOKEN is not provided.

Before an abend, messages ISG368E and ISG369I monitor the address spaces that are approaching the maximum amount. If a particular subsystem requires more ENQs than normal, use ISGADMIN service to raise the maximum ENQ amount of that subsystem for unauthorized and authorized requesters.

ENQ or RESERVE requests from authorized callers use the MASID (matching ASID) and MTCB (matching TCB) parameters to allow a further conditional control of a resource. One task issues an ENQ or RESERVE for a resource specifying a matching ASID; if the issuing task does not receive control, it is notified whether the matching task has control (which allows the issuing task to use the resource even though it could not acquire the resource itself). This process requires serialization between the issuing and requesting tasks.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014