Local and global resources

The ISGENQ macro recognize two types of resources: local resources and global resources.

A local resource is a resource identified on ISGENQ, ENQ or DEQ by a scope of STEP or SYSTEM. A local resource is recognized and serialized only within the requesting operating system. The local resource queues are updated to reflect each request for a local resource. If a system is not operating under global resource serialization (that is, the system is not part of a global resource serialization complex), all resources requested are treated as local resources.

If a system is part of a global resource serialization complex, a global resource is either identified on the ENQ or DEQ macro by a scope of SYSTEMS, or on the ISGENQ macro by a scope of SYSTEMS or SYSPLEX.

If your system is part of a global resource serialization complex, global resource serialization might change the scope value during its resource name list (RNL) processing. If the resource appears in the SYSTEM inclusion RNL, a resource with a scope of SYSTEM can have its scope converted to SYSTEMS or SYSPLEX. If the resource appears in the SYSTEMS or SYSPLEX exclusion RNL, a scope of SYSTEMS or SYSPLEX can have its scope changed to SYSTEM. This procedure is described in Selecting the data section of z/OS MVS Planning: Global Resource Serialization.

Through the RNL parameter on ISGENQ, you can request that global resource serialization not perform RNL processing and, therefore, not change the scope value of a resource. It is recommended that you use RNL=YES, the default, which tells global resource serialization to perform RNL processing. Use RNL=NO only when you are sure that you never want the scope value to change. An example of the use of RNL=NO is in a cross-system coupling facility (XCF) complex, where you can be certain that certain data sets always need a scope value of SYSTEMS or SYSPLEX and other data sets always need a scope value of SYSTEM or SYSPLEX. In a sense, RNL=NO overrides decisions your system programmer makes when that programmer places resource names in the RNLs.

Alternate serialization products have the ability to provide additional global resource serialization. As such, a resource may be local (SYSTEM scope) from a global resource serialization perspective but actually be globally managed by an alternate serialization product. See Determining the resulting scope for more details.