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

    GUID-A0570109-A351-4348-A0F9-D791FB665B46-low.png

  • Multiple DBC subsystems are running in the same sysplex but on different LPARs, 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
    GUID-FAB4932C-E8D7-42AD-82BD-C92B0F239E0C-low.png

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 containing product code accessing 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 RTCS system registry is used to find the LGC product-specific registry datastore, you need to use a special ZDBCssid DD statement in the product CLISTS and batch jobs to retrieve the option set for the correct DBC Group.

For more information about the ZDBCssid DD statement, see:


 

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