Replicating the DBC by using a different DBC group
Use this procedure if you need to change the setup of the DBC to accommodate more than one DBC group in the same sysplex or on the same LPAR and your products require the LGC agent. This is not the default configuration, so some manual steps are required.
In Product-deployment-for-infrastructure-components, the DBCs for T1 and T2 are already operational and you want to replicate it to P1 using a different DBC group to isolate production from test in the same sysplex.
Using this procedure is recommended in the following situations:
Multiple DBC subsystems are running on the same LPAR but are in different DBC groups, as shown in the following figure.
Different DBC groups on one LPAR
Multiple DBC subsystems are running in the same sysplex, they are in different DBC groups, and the RTCS system registry is shared, as shown in the following figure.
Multiple DBC groups sharing one RTCS system registry
For example, assume that you have DB2 subsystems that represent the test and production environments on the same LPAR (or in the same sysplex where the RTCS system registry is shared). You should separate the DBC subsystems that are monitoring those DB2 subsystems so that you can roll maintenance into production in a controlled manner. The test and production DBC subsystems will use separate runtime data sets, option sets, and LGC product-specific registry datastore. Because the installation is set up to use the RTCS system registry to find the LGC product-specific registry datastore, you need to use a special ZDBCssid DD statement statements in some of the installation jobs to direct TEST or PROD to its own datastore.