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.
To determine various related ENQ statistics regarding
authorized and unauthorized requesters, use ISGQUERY REQINFO=ENQSTATS
by ASID to query:
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. For
more information about ISGADMIN, see
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:
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. |
Copyright IBM Corporation 1990, 2014
|