Skip to Content
Information
Space announcement We are no longer updating this version of the documentation for the infrastructure components (DBC, LGC, and NGL).  You can no longer leave comments on it. For the latest version of the documentation, see Common Mainframe Infrastructure 2022 release.

Overview of deployment

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.

Some users already have their own procedures; these users simply want to know what additional steps 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
  • BMC Workbench (GUD), BMC Subsystem Optimizer for zEnterprise (BRD), LGC, NGL, and DOM agents defined and running under the DBC subsystem
  • NGL private or shared registry data set
  • LGC private registry data set, which can be shared across multiple DBC subsystems within the same DBC group
  • DBC repository data set
  • (Pool Advisor only) DOMVARS and PMDHIST data sets

You can combine these components into different configurations across LPARs, depending on whether you are sharing DBC groups, RTCS system registries, and LGC private registries.

Examples of possible deployment environments

The following figure illustrates an environment in which different LPARs have different RTCS registries but share the LGC private registry and the DBC group name. In this example, both LPARs share:

  • Runtime data sets
  • LGC registry
  • DBC group
  • Product option sets

System with non-shared RTCS system registry, shared LGC private registry, and shared DBC group name

GUID-40F1FE64-69BE-407F-A8C1-1008E56A1285-low.png

The DOM, BRD, and LGC agents and the DBC subsystem communicate across the coupling facility (XCF).

The following figure illustrates an environment in which different LPARs share:

  • RTCS registries
  • LGC private 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 shared RTCS system registry, shared LGC test, and shared DBC group

GUID-8035E4EE-870D-4537-8118-C34AED406DA8-low.png

Figure 3 illustrates an environment in which different LPARs have:

  • Different RTCS registries
  • Different LGC private 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 the LGC, DOM, and DBC do not communicate across the coupling facility.

System with non-shared RTCS system registry, non-shared LGC private registry, and different DBC group names

GUID-6939779F-0A94-4114-A6C6-21A3C2C77678-low.png

Warning

Note

Because the example shown in Figure 3 uses a separate LGC private registry on each LPAR, the names of the 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
Success

Tip

If choosing between a configuration like the one shown in Figure 1 and the one shown in Figure 2, consider basing your decision on whether RTCS has already been configured as non-shared.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

Common mainframe infrastructure 2016 release