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.

Support for multiple NGL registries

By using multiple registries, different products can use a separate registry for its NGL data. For example, MainView Transaction Analyzer can have one NGL registry, while MainView for Java Environments can have its own NGL registry and BMC System Performance for DB2 can use a unique NGL registry independent of the other products. NGL also supports sysplex sharing of the NGL registry that enables NGL instances on separate or the same LPAR to use the same registry.

The NGL registry definition (REGISTRY DD) in the DBC started task procedure is optional. Support is based on defining the target NGL registry using the RTCS Indirect Registry Definition facility (IRDF). By using IRDF, you can define the NGL registry name to RTCS and RTCS will retain that information in the RTCS system registry. NGL agent initialization, based on the start parameters for the agent, determines the registry configuration and in conjunction with RTCS, allocates the proper registry for that agent.

Default behavior during installation

The default behavior of the Installation System at the ZNGLA30 FMID level is to prompt the installer for the NGL registry name and construct the necessary jobs that define the registry if required. The DBC started task procedure will include a REGISTRY DD statement, and the <STARTAGENT> <PARMS> for the NGL agent statement will specify PR=Y. This behavior is required to support a mixed environment of pre-ZNGLA30 FMIDs with ZNGLA30 FMID agents.

To implement the ZNGLA30 enhanced registry support after installation:

  1. Verify that the <LOADLIB> statements for the NGR product specify the load libraries from the ZNGLA30 installation.
  2. Follow the Implementing multiple NGL registries instructions (see Implementing-multiple-NGL-registries) to customize the required NGL agents for the enhanced registry support.
  3. If all NGL agents are at the ZNGLA30 FMID level and using the enhanced registry support, the //REGISTRY DD can be removed from the DBC started task procedure.

Installation into an existing environment

ZNGLA30 operates in compatibility mode with ZNGLA20 or earlier. If you wish to exploit the new NGL registry features provided by ZNGLA30 and ZNGLA30 is being installed into an existing DBC environment with products that might be running with ZNGLA20 or earlier, the NGL registry agent, NGR, must be upgraded to the ZNGLA30 level. NGR at the ZNGLA30 level is downward compatible and supports NGL registry features for ZNGLA20 and earlier releases. Any NGL agent can continue to be at the ZNGLA20 or earlier level using the NGR registry agent at ZNGLA30 until the products using that NGL agent are upgraded. The NGR agent at ZNGLA20 and earlier do not support the new registry features for ZNGLA30.

 

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

Common mainframe infrastructure 2016 release