Step 1. Plan to share parmlib members

When planning to share parmlib members, ask yourself the following questions:

Do two or more systems require identical resource names in the parmlib members to be shared?
If so, you need not specify system symbols in the parmlib members; the systems can share the contents of the parmlib members without the benefit of system symbols. However, if the systems require unique names for resources (such as jobnames) specified in those members, you must specify system symbols to generate unique values for those names.

For example, if every system that shares parmlib uses the same set of APF authorized libraries, the systems can share the PROGxx parmlib member. Because the definitions in PROGxx are identical for each system, there is no need to specify system symbols in PROGxx.
What resource definitions are good candidates for sharing?
If your goal is to greatly simplify your operating environment, the answer will be: As many as possible! If two or more systems require different names for a resource, define the resource with a system symbol in parmlib; then define different substitution texts for the system symbol on each system that is to share the parmlib definition. Now you have one convenient place to maintain the definition. If you follow the same process with all parmlib definitions that require unique values, you can view a multisystem environment as a single system image with one point of control.

Be aware that there are also reasons you might not want to share certain resource definitions. Perhaps the release level of MVS™ prevents you from using system symbols on a particular system; or perhaps one or more systems do not require a particular resource. Whatever the case, your installation must examine the resources it defines in parmlib and determine the extent to which they can be shared.
An example of a resource definition that can be shared is a definition for a page data set. Because systems cannot share page data sets, installations must define unique page data sets for each system in a sysplex. You might want to assign unique names to the page data sets so you can easily identify them. Suppose that you had three systems, named SYS1, SYS2, and SYS3, that share the same IEASYSxx member. To specify unique names for the page data sets on the different systems, you could specify the following in the IEASYSxx parmlib member:
```
 PAGE=PAGE.&SYSNAME..LOCAL1
```
When each system processes IEASYSxx, it calls into use a predefined page data set with the name that results from the symbolic substitution, as follows:
- PAGE.SYS1.LOCAL1 on system SYS1
- PAGE.SYS2.LOCAL1 on system SYS2
- PAGE.SYS3.LOCAL1 on system SYS3
Do I need to share system parameters that specify unique values in the IEASYSxx parmlib member?
When the systems in your environment require unique parmlib members, you can specify system symbols in one or more shared IEASYSxx members to indicate unique member suffixes. Do this only when it is not possible to share the same members. In other words, try to specify system symbols in parmlib definitions first, as described in Step 2. Determine where to use system symbols in parmlib. If you cannot share a member with any degree of efficiency, create a new member with a unique suffix; then specify a system symbol in IEASYSxx that resolves to the suffix you want to use on each system.

For example, suppose systems SYS1, SYS2, and SYS3 require unique CLOCKxx parmlib members. You can take the following steps:
1. Create three unique members: CLOCKS1, CLOCKS2, and CLOCKS3.
2. Specify the following in the shared IEASYSxx member:
```
CLOCK=&SYSCLONE.
```
If your installation accepts the default substitution text for &SYSCLONE (the last two characters in the system name), the CLOCK parameter in IEASYSxx will specify the following for each system:
- CLOCKS1 on system SYS1
- CLOCKS2 on system SYS2
- CLOCKS3 on system SYS3
Do I want to provide substitution texts for static system symbols, or do I want to accept the system defaults?
The system provides default substitution texts for the &SYSCLONE, &SYSNAME, and &SYSPLEX system symbols. See the descriptions of the default substitution texts in Table 1. If the default texts are not acceptable to your installation, you can define your own substitution texts in parmlib. For example, if a system always runs on the same logical partition (LPAR), the system might be able to accept the default for the &SYSNAME system symbol (because &SYSNAME can default to the LPAR name).
Do I need to define additional static system symbols?
The static system symbols that are defined to the system might be sufficient to uniquely identify resources. If your installation requires additional static system symbols, you can define at least 800 additional static system symbols in the IEASYMxx parmlib member.
Do I want to define the &SYSPLEX static system symbol early in system initialization so other parmlib members can use it?
You can optionally specify the sysplex name in both the COUPLExx and LOADxx parmlib members. The sysplex name is also the substitution text for the &SYSPLEX system symbol. When you specify the sysplex name in both LOADxx and COUPLExx, the substitution text for &SYSPLEX is defined early in system initialization, which allows all parmlib members to use the defined substitution text. When the sysplex name is defined only in COUPLExx, the system does not define the substitution text for &SYSPLEX until late in system initialization. The system substitutes the text LOCAL for any instances of &SYSPLEX that occur before COUPLExx is processed.

If you plan to use the &SYSPLEX system symbol in parmlib, IBM® suggests that you specify the same sysplex name in both LOADxx and COUPLExx. See Step 5. Code support for system symbols in LOADxx for details.
Do I want to ensure that the substitution text for &SYSCLONE is unique on all systems?
&SYSCLONE is a 1-2 character shorthand notation for the system name (unless your installation changes the substitution text to another value). IBM suggests that you use &SYSCLONE in places where the substitution text for &SYSNAME is too long, such as parmlib member suffixes.

Each system in a sysplex must specify a unique SYSCLONE value. Message IXC217I will be issued if the substitution text for the symbol &SYSCLONE is not unique in a sysplex.
Do I plan to use system symbols in other interfaces? If so, are there any considerations to make for those interfaces when I define system symbols in parmlib?
Parmlib is not the only place where you can use system symbols to share resources that require unique values. After you read this topic, see the following books for information about sharing resources in the listed interfaces:
Application or vendor programs

See the topics on how to substitute text for system symbols in application programs in z/OS MVS Programming: Assembler Services Guide.

Dynamic allocations

See the topic on coding dsname allocation text units in z/OS MVS Programming: Authorized Assembler Services Guide.

Job control language (JCL) for started tasks

See the topic on how to specify system symbols in JCL in z/OS MVS JCL Reference.

System commands

See the topic on using system symbols in system commands in z/OS MVS System Commands.

Time Sharing Option Extensions (TSO/E) Logon Procedures

See the topic on how to set up logon processing in z/OS TSO/E Customization.

When defining static system symbols in parmlib, consider that the listed interfaces might want to use those system symbols.