Local and global resources

When an application uses a macro (ISGENQ, ENQ, DEQ, and RESERVE) to serialize resources, global resource serialization uses the RNL, various global resource serialization installation exits, and the scope on the macro to determine whether a resource is a local resource or a global resource.

A local resource is a resource requested with a scope of STEP or SYSTEM. It is serialized only within the system processing the request for the resource. If a system is not part of a global resource serialization complex, all resources (with the exception of resources serialized with the RESERVE macro), regardless of scope (STEP, SYSTEM, SYSTEMS), are local resources.

A global resource is a resource requested with a scope of SYSTEMS or SYSPLEX. It is serialized among all systems in the complex.

The ISGENQ, ENQ, DEQ, and RESERVE macros identify a resource by its symbolic name. The symbolic name has three parts:

Major name:: qname
Minor name:: rname
Scope:: The scope is one of the following:
STEP
SYSTEM
SYSTEMS
SYSPLEX

Example: On the ISGENQ, ENQ or DEQ macro, a resource could have a symbolic name of APPL01,MASTER,SYSTEM. The major name (qname) is APPL01, the minor name (rname) is MASTER, and the scope is SYSTEM. Global resource serialization identifies each resource by its entire symbolic name. That means a resource that is specified as A,B,SYSTEMS is considered a different resource from A,B,SYSTEM or A,B,STEP because the scope of each resource is different.

Note: In addition, the ISGENQ macro uses the scope of SYSTEMS and the scope of SYSPLEX interchangeably, so a resource with the symbolic name of A.B.SYSTEMS would be the same as a resource with the name A.B.SYSPLEX.

GRS users define the QNAME/RNAME of resources. As such, the user defines their usage and meaning. See the ENQ/DEQ Summary table in z/OS MVS Diagnosis: Reference for definitions of the used ENQ resources (QNAME/RNAME). It is helpful for the users to know the usage when observing ENQ/RESERVE activity and contention.

In general, global resource serialization identifies a resource with a scope of STEP or SYSTEM as a local resource, and a resource with a scope of SYSTEMS as a global resource. Because users of some previous versions of MVS™ could serialize access to resources across multiple systems only through a reserve, whether the user specified SYSTEM or SYSTEMS on the ENQ macro did not affect resource serialization. Therefore, your installation might have programs that specify ENQ with a scope of SYSTEM for resources that you would want global resource serialization to identify as global resources. You might also have programs that specify ENQ with a scope of SYSTEMS for resources that you would want global resource serialization to identify as local resources.

To ensure that resources are treated as you want them to be without changes to your applications, global resource serialization provides three resource name lists (RNLs):

The SYSTEM inclusion RNL lists resources requested with a scope of SYSTEM that you want global resource serialization to treat as global resources.
The SYSTEMS exclusion RNL lists resources requested with a scope of SYSTEMS that you want global resource serialization to treat as local resources.
The RESERVE conversion RNL lists resources requested on the RESERVE macro that you want global resource serialization to suppress the reserve.
Note: For the correct use of the conversion RNL, see RESERVE conversion.

By placing the name of a resource in the appropriate RNL, you can cause global resource serialization to process it as you want. The RNL enables you to build a global resource serialization complex without first having to change your existing programs, though you might at some time want to change these programs.

Deciding how to use the RNLs to define your resource processing needs is a major part of the planning for a global resource serialization complex; the process is described in detail in Selecting the data. To make the most effective use of the RNLs, you also need to understand how a global resource serialization complex processes requests from an application programming interface (API).