Selecting the data

This contains the following topics:

Restrictions: Some applications are not affected by the resource name lists (RNLs) because they do not require GRS for managing ENQ beyond a single system. Therefore, if you need to, or prefer to use an alternate method of serializing global resources in a sysplex, you can specify GRSRNL=EXCLUDE on the GRSRNL system parameter. It is important to remember that EXCLUDE must be used with caution. When you specify GRSRNL=EXCLUDE, note the following facts:

Only resources identified as SCOPE=SYSTEMS,RNL=NO on the ENQ macro are still managed by global serialization in the complex.
You cannot specify the SET GRSRNL=xx command.
A sysplex-wide outage is required to switch to an alternate method of serializing global resources (with only one exception, for more information, see Migrating from GRSRNL=EXCLUDE to a set of RNLs ).

The rest of this topic assumes that you have not specified GRSRNL=EXCLUDE.

To ease migration to protecting resources as global resources, global resource serialization provides three RNLs:

SYSTEM inclusion RNL
SYSTEMS exclusion RNL
RESERVE conversion RNL

The RNLs allow you to change resource scopes and convert reserves. IBM® supplies default RNLs, shown in Figure 1. You can modify the contents of the RNLs to define the resource serialization requirements of your installation. You can also use the ISGNQXIT and ISGNQXITFAST installation exits to indicate that global resource serialization is to bypass RNL processing for SYSTEM and SYSTEMS requests. This topic contains information you can use to select the resource names to place in each RNL.

Rule: A major reason for carefully planning the contents of the RNLs is that the RNLs installed in all systems in the complex must be exactly the same. During its initialization, global resource serialization checks to make sure that the RNLs on each system are indeed identical. If they are different, global resource serialization does not allow the system to join the complex.

When the sysplex matches the complex, you can use the SET GRSRNL command to change the RNLs dynamically. The procedures for changing RNLs for the ring and star complex are the same. For more information see Changing the RNL.

Naming resources in the appropriate RNL enables you to build a global resource serialization complex without modifying any existing programs. Therefore, your decisions about resources will probably focus on two questions:

What are my installation's short-term goals for the global resource serialization complex? Or, what must we do with the RNLs to get benefits from the complex as quickly as possible?
What are my installation's long-term goals for the global resource serialization complex? Or, what changes might we make to existing programs and procedures to make resource serialization more efficient?

Answering the first question requires you to analyze your use of data sets on shared DASD volumes to select the resources that are causing contention problems. As you do this analysis, focus on resources that are known to cause problems, such as resources that are frequently involved in interlocks. Consider whether a shared DASD volume accessed by the complex must also be accessed by systems outside the complex. Answering the second question might require you to analyze the data set naming conventions at your installation.

You must also understand how global resource serialization uses the resource names in the RNLs and what suggestions and recommendations exist for various situations.

Once you have completed your plan, see z/OS MVS Initialization and Tuning Reference for information on defining your RNLs in the GRSRNLxx parmlib member.