This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
DB2 Product Setup & Deployment
We have several LPARs in a SYSPLEX: some are Production LPARs and others are for Development.
We don't want to share Production datasets with Development partitions.
What recommendations do you have to set the LGC registry up in this SYSPLEX?
I will use two functional areas TEST and PROD for a better understanding and try to cover several types of implementation.
Let's say that you have LPARS that ONLY have PROD on them, so say 4 LPARS for PROD and 4 for DEV, and you do not want them to talk to each other, you want to keep them separate with the products, then I would do the following:
1. Setup RTCS on each TEST LPAR. The RCTS group will need to be changed in the OSZINIxx member to be a TEST group and the RTCS registry will also need to exist. We suggest that they for TEST, the registry and group are shared on the TEST lpar. So, you have an OSZINIxx member for TEST, and a different one for PROD lpars. I would suggest that the names have PROD or TEST in the group and the registry to make it easy to identify, or something that will mean PROD or TEST to them.
2. Once RTCS is setup on the TEST lpars, you then want to register the LGC registry to RTCS for TEST. I would suggest that all the TEST lpars share the same LGC registry. The LGC registry name will have an DBCGROUP and XCFGROUP also. I would suggest that the names contain something that make it easy to identify this as a TEST. Note, the LGC registry dataset should only be registered to a single DBCGROUP/XCFGROUP, do not have the same LGC registry dataset registered to more than 1 group. I recommend 1 LGC for a functional area like TEST that is shared. It typically is much easier to control this way and less maintenance needed.
3. Setup a DBC on each lpar. Each DBC will have a DBC repository that is specific to that DBC. I suggest having the DBC ssid as part of the DBC repository name. The DBC repository is created when the DBC is started. The DBC is a task handler. So instead of all of the products having a started task, we have the DBC and the DBC starts agents for products under it. An example is DOM and NGL. The DOM agent is the Data Collector for MainView and Apptune, NGL is the Logger agent. Both run under the DBC. If you do not have MainView DB2 or Apptune, you would not have DOM defined to run under the DBC. The DBC repository contains what agents to start. The XML that defines what agents to start is done at install time.
When a DBC is started, the DBCGROUP is used to look at RTCS and find the LGC registry dataset that is for that group and at that point, the DBC now has access to the LGC registry. The LGC registry contains the product options for each release of the product. If we look at Apptune, the DOMPLEX and filters are in the LGC for v11.2. When an upgrade to V12.1 is done, the options are copied into the new release area from the previous release. Both the V11.2 and V12.1 options are stored in the LGC now. Both V11.2 and V12.1 can be run from this on LGC registry. Many products and versions are stored in the LGC registry at the same time. The correct options are used based on the version of the agent that is running under the DBC.
This would be how a TEST system would be setup, PROD would be setup the same only using PROD.
Now, there are times that both TEST and PROD are on the same system at the same time. In this case, the RTCS registry and group I would suggest be set for PROD. I would then have 2 DBCGROUPS each with its own LGC registry registered to RTCS. The PROD DBC group would be default. I would then have 2 DBC's on the system, one for PROD, one for TEST. The DBC's would use different libs to keep them separated. In this way, the PROD and TEST both exist on the system, but do not really touch each other. You can upgrade TEST and not impact PROD in the future. This same concept can be used to isolate a single product. If you need to have MVI separate for some reason, you would step a DBCGROUP for MVI and register that group to RTCS. You would then install MVI into that DBC.
I normally recommend that the LGC and RTCS registries be shared across functional areas. So, TEST LPARS share LGC and RTCS, and PROD lpars have a different LGC and RTCS registry. This typically allows for the least amount of maintenance while keeping TEST and PROD separate while allowing products to communicate across the functional lpars.
If you want to have a different LGC for each LPAR, then I would suggest the following:
1. Do not SHARE the RTCS repository
2. Register a unique DBCGROUP/XCFGROUP with LGC, a registry on each LPAR.