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.

Table 2. Types of libraries
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.

Table 3. Types of runtime environments
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. See Example 1. Full (self-contained) runtime environment.
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. See Example 2. Base runtime environment.
Sharing-with-base runtime environment	Runtime environment containing LPAR-specific libraries and referencing the base libraries configured in a base runtime environment. See Example 3. Sharing-with-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. See Example 4. Sharing-with-full runtime environment.
Sharing-with-SMP/E runtime environment	Runtime environment containing LPAR-specific libraries and referencing the libraries managed by SMP/E. See Example 5. Sharing-with-SMP/E runtime environment.

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.

Quick start suggestion for a runtime environment configuration

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.

Tip

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 2. Full runtime environment on a single system

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.

Figure 3. Full runtime environments on several systems

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.

Figure 4. Base runtime environment

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.

Figure 5. Sharing-with-base runtime environment

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.

Figure 6. Sharing-with-full runtime environment

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.

Figure 7. Sharing-with-SMP/E runtime environment