Customizing after installation
Deploying products that use the infrastructure components requires careful planning. This overview illustrates how you might combine these components into different configurations across LPARs. Although each user's environment is unique, this document attempts to cover a variety of typical situations.
You might already have your own procedures, in which case you only want to know the additional steps that are required to set up the new components for different environments.
Requirements for each LPAR
Each LPAR must have the following components (depending on the product installed):
- RTCS started task
- DBC started task
- (Optional) NGLARCH started task
- (Depending on the products installed) BMC Workbench (GUD), BMC Subsystem Optimizer for zEnterprise (BRD), LGC, NGL, DB2 Data Collector (DOM), and MainView Logger (MVL) agents defined and running under the DBC subsystem
- (Pool Advisor only) DOMVARS and PMDHIST data sets (These data sets are allocated dynamically by the product when it starts and are shared across the DBC group.)
You can combine these components into different configurations across LPARs, depending on whether you are sharing DBC groups and RTCS system registries.
Examples of possible deployment environments
System with a non-shared RTCS system registry, shared LGC product-specific registry, and shared DBC group name
The following figure illustrates an environment in which different LPARs have different RTCS registries but share the LGC product-specific registry and the DBC group name. In this example, both LPARs share:
- Runtime data sets
- LGC product specific registry
- DBC group
- Product option sets
The DOM, BRD, and LGC agents and the DBC subsystem communicate across the coupling facility (XCF).
System with a shared RTCS system registry, shared LGC product-specific registry, and shared DBC group
The following figure illustrates an environment in which different LPARs share:
- Runtime data sets
- RTCS registries
- LGC product-specific registry
- DBC group name
- Product option sets
This example is similar to the previous one but demonstrates that the same setup can be achieved whether the RTCS system registry is shared or unshared.
System with a non-shared RTCS system registry, non-shared LGC product-specific registry, and different DBC group names
The following figure illustrates an environment in which different LPARs have:
- Different runtime data sets
- Different RTCS registries
- Different LGC product-specific registries
- Different DBC group names
- Different product option sets
The configuration in the following example enables you to keep TEST separate from PROD so that none of the agents communicate across the coupling facility.
Because the example uses a separate LGC product-specific registry on each LPAR, the names of the BRD, DOM, and GUD option sets might be the same on each LPAR but will be different instances.
Choosing a configuration
The configuration that best suits your environment depends on:
- Whether RTCS is already configured (and if so, whether it is configured as shared or non-shared)
- How many DBC groups you want to have in a sysplex
- Whether you need to have more than one DBC started tasks running on the same LPAR