Understanding runtime environments
Your next planning task is to decide what types of runtime environments to set up for the components you plan to deploy on your z/OS® images.
Fill out the Worksheet: Information for configuring your runtime environment as you read this section.
A runtime environment is a logical grouping of runtime libraries that are referenced by started tasks as they run on a z/OS image. When you run the Configuration Tool to configure the Advanced Allocation Management monitoring agent, you start this process by defining a runtime environment of a certain type, which determines the number and types of runtime libraries required.
Table 2 summarizes the types of libraries created during installation and configuration of the Advanced Allocation Management product.
Type of Library | Description |
---|---|
Runtime libraries | General term for libraries referenced by started task procedures. Includes SMP/E target, base, and LPAR-specific libraries. |
SMP/E target libraries
Abbreviated &thilev. |
SMP/E maintained target libraries. |
Base libraries
Abbreviated &rhilev or &rhilev.&rte. |
Read-only
runtime libraries that the configuration process does not alter and
that are shareable between systems. These libraries physically exist
in a full or base runtime environment, or as SMP/E target libraries
(if a runtime environment shares with SMP/E).
The base libraries can contain the actual data sets maintained by SMP/E, or a copy of them. Use a clone or copy of the SMP/E installation libraries for a production environment. |
LPAR-specific libraries
Abbreviated &rhilev.&rte. |
Runtime libraries that are built during configuration to run on a specific logical partition (LPAR). These libraries contain the unique elements required for a particular LPAR and cannot be shared among z/OS images. |
Table 3 explains the types of runtime environments that you can create during product configuration.
Type of runtime environment | Description |
---|---|
Full (self-contained) runtime environment | Runtime environment containing a full set of dedicated libraries, consisting of both LPAR-specific libraries and a copy of the SMP/E installation read-only base libraries eligible for sharing with other runtime environments. |
Base runtime environment | Runtime environment containing exclusively read-only, shareable base libraries, which are a subset of the libraries needed to run monitoring agents. Therefore, they must be shared by another runtime environment. |
Sharing-with-base runtime environment | Runtime environment containing LPAR-specific libraries and referencing the base libraries configured in a base runtime environment. |
Sharing-with-full runtime environment | Runtime environment containing LPAR-specific libraries and referencing the base libraries configured in a full runtime environment. |
Sharing-with-SMP/E runtime environment | Runtime environment containing LPAR-specific libraries and referencing the libraries managed by SMP/E. |
The distinction among library types allows you to optimize your product environment. For example, by allocating common base libraries to a single runtime environment that can be shared by other runtime environments, you can substantially reduce the amount of disk space required, as well as simplify the application of product maintenance across remote z/OS images.
There are many variables and lots of information to consider when deciding on a runtime environment configuration for your installation. To get you started quickly, here are a couple of suggestions:
- In most cases, you can get good results with a sharing-with-base or sharing-with-SMP/E type of runtime environment.
- If you want to test Advanced Allocation Management on an isolated test system, use a full, self-contained type of runtime environment.
Possible configurations using runtime environments
The following five examples show different types of runtime environment configurations. The way you choose to set up your runtime environments depends on your site requirements and maintenance procedures.
The data set name (DSN) is composed of the high-level qualifier (&hilev), followed by the mid-level qualifier (&rte), followed by the low-level qualifier. The field settings and library names shown are for illustrative purposes only.
Example 1. Full (self-contained) runtime environment
The full runtime environment contains all libraries required by a particular IBM® product and is the easiest runtime environment to create. This type of runtime environment can be defined in any situation but is most suitable if at least one of the following statements is true:
- Your installation comprises only a single z/OS image.
- You want each z/OS image to be independent.
- You are creating a runtime environment for a specific combination of monitoring agents that do not exist in any other runtime environment.
The following example represents a full runtime environment called RTE1 that is completely self-contained. All base libraries and LPAR-specific libraries are allocated within RTE1. The base libraries in a full runtime environment are a copy of the SMP/E installation libraries.
RTE Name: RTE1 Type: FULL Hilev: IBM.OMXE Midlev: RTE1 Shares with: (none)
LPAR-specific library DD DSNAME resolution:
//RKANPARU DD DSN=IBM.OMXE.RTE1.RKANPAR DD DSN=IBM.OMXE.RTE1.RKANPARU
Base library DD DSNAME resolution:
//RKANMODL DD DSN=IBM.OMXE.RTE1.RKANMODL
This type of runtime environment is illustrated in Figure 2.
Figure 3 shows the way a full runtime environment can be expanded to more than one z/OS image. Each runtime environment is self-contained; the three runtime environments X, Y, and Z on systems A, B, and C do not share any libraries.
Example 2. Base runtime environment
The base runtime environment allocates shareable base libraries only. A base runtime environment must be used in conjunction with a sharing-with-base runtime environment (see Example 3. Sharing-with-base runtime environment) to provide the complete set of libraries required to run the installed monitoring agents. The base runtime environment and the sharing-with-base runtime environment must be defined for the same combination of monitoring agents.
A base runtime environment is typically used when storage devices are shared or when monitoring agents maintenance synchronization across systems is desired. Sharing base libraries avoids unnecessary duplication, saves disk space, and simplifies the application of monitoring agents maintenance to a common point.
The following example represents a base runtime environment called RTE2.
RTE Name: RTE2 Type: BASE Hilev: IBM.OMXE Midlev: (none) Shares with: (none)
LPAR-specific library DD DSNAME resolution:
*There are no LPAR-specific libraries in a BASE RTE.
Base library DD DSNAME resolution:
//RKANMODL DD DSN=IBM.OMXE.RKANMODL
This type of runtime environment is illustrated in Figure 4.
Example 3. Sharing-with-base runtime environment
The sharing-with-base configuration is a good choice for environments where storage devices are shared. Using the base runtime environment for common data sets, the sharing-with-base runtime environment contains only LPAR-specific libraries. The base runtime environment cannot contain the LPAR-specific libraries required to run the installed monitoring agents. The base runtime environment and the sharing-with-base runtime environment must be defined for the same combination of monitoring agents.
The Configuration Tool resolves product configuration elements to point at the LPAR-specific libraries and the base runtime environment libraries as necessary.
The following example represents a sharing-with-base runtime environment called RTE3, which obtains its base library information from the base runtime environment (RTE2).
RTE Name: RTE3 Type: SHARING Hilev: IBM.OMXE Midlev: RTE3 Shares with: BASE RTE2
LPAR-specific library DD DSNAME resolution:
//RKANPARU DD DSN=IBM.OMXE.RTE1.RKANPAR DD DSN=IBM.OMXE.RTE1.RKANPARU
Base library DD DSNAME resolution:
//RKANMODL DD DSN=IBM.OMXE.RKANMODL
This type of runtime environment is illustrated in Figure 5.
Example 4. Sharing-with-full runtime environment
The sharing-with-full runtime environment allocates LPAR-specific libraries only, and in this example, obtains its base library information from a full runtime environment that contains the same combination of monitoring agents.
This configuration can also be used for environments where storage devices are shared, although the base/sharing pair is the preferred approach.
The following example represents a sharing-with-full runtime environment called RTE4, which obtains its base library information from the full runtime environment (RTE1).
RTE Name: RTE4 Type: SHARING Hilev: IBM.OMXE Midlev: RTE4 Shares with: FULL RTE1
LPAR-specific library DD DSNAME resolution:
//RKANPARU DD DSN=IBM.OMXE.RTE1.RKANPAR DD DSN=IBM.OMXE.RTE1.RKANPARU
Base library DD DSNAME resolution:
//RKANMODL DD DSN=IBM.OMXE.RTE1.RKANMODL
This type of runtime environment is illustrated in Figure 6.
Example 5. Sharing-with-SMP/E runtime environment
The sharing-with-SMP/E runtime environment allocates LPAR-specific libraries only and obtains its base library information from target libraries managed by SMP/E. Note that the target SMP/E libraries must be copies (cloned) rather than the system libraries. See the appendix on making a copy of your system software (cloning) in z/OS and z/OS.e Planning for Installation.
Use the sharing-with-SMP/E configuration if at least one of the following statements is true:
- Space is limited on storage devices. This configuration method does not allocate base libraries in the runtime environment, thereby reducing storage requirements.
- You want to activate SMP/E applied OMEGAMON® product maintenance immediately.
The following example represents a sharing-with-SMP/E runtime environment called RTE5, which obtains its base library information from SMP/E target libraries.
RTE Name: RTE5 Type: SHARING Hilev: IBM.OMXE Midlev: RTE5 Shares with: SMP/E Target Libraries Hilev (SMP): INSTALL.SMPE
LPAR-specific library DD DSNAME resolution:
//RKANPARU DD DSN=IBM.OMXE.RTE1.RKANPAR DD DSN=IBM.OMXE.RTE1.RKANPARU
Base library DD DSNAME resolution:
//RKANMODL DD DSN=IBM.OMXE.SMPE.TKANMODL
The sharing-with-SMP/E type of runtime environment is illustrated in Figure 7.