Minor changes are by default collapsed in the page history.
No changes
The page does not exist yet.
Failed to load changes
Version by on
Leave Collaboration
Are you sure you want to leave the realtime collaboration and continue editing alone? The changes you save while editing alone will lead to merge conflicts with the changes auto-saved by the realtime editing session.
Overview of using ZDBCssid to designate non-default DBC groups
By default, when the LGC agent receives requests to retrieve option sets, it will query the RTCS system registry to find the name of the DBC group that was registered as the default group. Each individual RTCS system registry can have only one DBC group that is registered as the default.
In the situations described in Replicating-the-DBC-by-using-a-different-DBC-group, you can keep the TEST option sets separate from the PROD option sets by specifying the ZDBCssid designation on TEST to override the registered default DBC group of PRODPLEX. Use the ZDBCssid designation only when you must override the default DBC group.
For DBC groups that are not registered as the default group, you will need to use the special ZDBCssid designation in:
The product CLISTs
Any jobs that execute LGCUTIL
Any jobs that retrieve and use an LGC option set
You can designate only one DBC group with the defaultdbc element per RTCS system registry. In other words, each RTCS system registry can have only one default DBC group designated (meaning a one-to-one correlation). All other DBC groups need to use the ZDBCssid designation.
Conditions
Action
Multiple DBC subsystems on the same LPAR
If the DBC subsystems are in different DBC groups, one group must be registered with the defaultdbc value. Others must use the ZDBCssid designation.
Multiple DBC subsystems in the same sysplex
If the DBC subsystems are in different DBC groups and your RTCS registry is shared across the sysplex, one group must be registered with the defaultdbc value. Others must use the ZDBCssid designation.
