Decision 2: What types of runtime environments to set up
A runtime environment is a logical grouping of runtime libraries that are referenced by started tasks running on a z/OS® image. When you configure monitoring servers and monitoring agents, you begin by defining a runtime environment of a certain type, which determines the number and types of runtime libraries required. System proximity, available storage space, and product maintenance strategy are all factors used to determine the type of runtime environment you require for a set of products.
| Type of library | Description |
|---|---|
| Runtime libraries | General term for libraries referenced by started task procedures. |
| 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. |
The distinction among library types helps 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 and simplify the application of maintenance across z/OS images.
| 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. |
| 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. |
In deciding which type of runtime environment you want to configure, take into account the following considerations:
- Number of LPARs
A best practice is to have a single runtime environment per LPAR. Based on the workload being monitored in an LPAR, it might make sense to have different runtime environment "templates" based on the commonality of monitoring in the LPARs. For example, if there are LPARs that primarily run transaction workloads (CICS®, WebSphere®), and LPARs that primary run databases (for example, Db2® or IMS), then two runtime environment templates might be defined, one for monitoring the transaction subsystems, one for monitoring the database subsystems.
- Shared DASD
If shared DASD is in place, runtime environments can be defined and maintained on a single LPAR without having to move the updated data sets to the target system. Without shared DASD, you will either have to maintain separate installation environments on the systems not sharing DASD, or use one system for the installation environment to create and maintain runtime environments, and then have a process to move new or updated runtime environments to the target system.
- SMP/E CSI environments
A single SMP/E CSI (consolidated software inventory) environment for the products is simpler to manage, but is also less flexible when moving to different product levels. Multiple CSI environments provide more flexibility, but require more effort to maintain. Since a runtime environment is associated with a set of SMP/E target libraries, multiple CSIs may mean either more runtime environments, or the need to manage the association of runtime environments with an SMP/E CSI environment (for example, by a physical system or a set of LPARs). For more information, see Decision 1: Why to install into a shared CSI.
- Maintenance
SMP/E maintenance is added to the product target libraries. When a runtime environment is sharing with the SMP/E target libraries, the runtime environment is updated when the SMP/E maintenance is applied. Base and full runtime environments are updated only after they are loaded after the SMP/E maintenance. This configuration provides additional flexibility, as the SMP/E maintenance can be applied and tested before updating the base or full runtime environments (and any sharing runtime environments that share with the base or full runtime environment).
- If you plan to install monitoring agents on many z/OS images, you can get good results with a sharing-with-base or sharing-with-SMP/E type of runtime environment. See the following examples for considerations when using any type of sharing environment.
- If you want to test quickly, use a sharing-with-SMP/E type of runtime environment runtime environment .
- If you want to test your configuration on an isolated test system, use a full, self-contained type of runtime environment.