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 Open link .

Avoiding ZDBCssid

If necessary, you could avoid needing the ZDBCssid designation by using a different configuration. Sample scenarios are as follows:
  • Multiple DBC subsystems are running in the same sysplex, they are in different DBC groups, and the RTCS system registry is shared. See Multiple DBC groups sharing one RTCS system registry.

    To avoid use of ZDBCssid in this situation, you could set up the RTCS system registry to be shared per DBC group. For more information, see Controlling sharing of the RTCS system registry.

  • Multiple DBC subsystems are running on the same LPAR but are in different DBC groups. See Different DBC groups on one LPAR.

    To avoid use of ZDBCssid in this situation, use either of the following options:

    • Require the DBC subsystem registered as defaultdbc to always start first.

    • Set up a dedicated DBC group to be registered with the defaultdbc parameter, include only the LGC agent in it, and always require the DBC group to start before the other DBC subsystems.

    Use the following procedure if you want to create a DBC that will be in a different DBC group from the one registered as the defaultdbc:

    1. Review the section of the installation system reference manual that describes product deployment. In this scenario, you will start by running the $300 series of jobs.

      Run the $$JCLCPY job to create a new JCL data set for this deployment scenario.

    2. Review product-specific configuration guides for any set up required for these products to use the DBC and its agents.

    3. Modify the infrastructure symbolic variables as follows:

      1. In Symbolic variables contained in $$INCINF member, locate the rows that contain the entry 'Different DBC started task,' 'Different DBC Group,' or 'Different DOMPLEX NAME' in the fourth column.

      2. Use the symbolic variables in the second table column of those rows.

    4. Begin running the installation jobs with the $300 series of jobs.

      (For System and SQL Performance) Review the $310VDOM job. If your original install specified to reuse the DOM VSAM data sets, but you need to create new ones, then contact BMC Customer Support for a sample job.

      Note

      Do not run the $310VLGC job. In this scenario, the defaultdbc will be the only DBC that has an active LGC agent and its datastore will contain option sets for all the products.

    5. Consider the following when running the $400 series of jobs:

      • (For NGL) If your original install specified to reuse NGL, then you will not have a $410VNGL job. If you do not have a $410VNGL job and you need to create a new one for this environment, contact BMC Customer Support for a sample.

        For the $450STRT job, start the DBC started task that was registered as the defaultdbc. Make sure that the LGC agent defined to the task is active. Then start the DBC for this new environment.

      • (For LGC) Do not run the $463LGCD job. It is not needed in this scenario because the task uses the LGC registry from the defaultdbc.

        Note

        • Do not run any of the LGC steps in the $465INIT job. These steps define the LGC agent to the DBC. This is not necessary for this scenario because the task uses the LGC agent from the defaultdbc.

        • Do not run $470LGCR. This job registers the LGC templates, which was already done for the LGC in the defaultdbc. The first step of this job, LGCLIST, will list all DBC groups and LGC registries and indicate which DBC is registered as the defaultdbc. You could run this step to verify the defaultdbc.

        • (Before running the $490RGIM job (if generated)) If your original install specified to migrate LGC option sets for your products, the job will copy the option sets from the previous version to the new version and then update certain values for new data set names, plan names, and so on. If your new environment does not have any option sets to migrate, contact BMC Customer Support to get a sample job that will create a new option set.

    6. Run the $500 series of jobs (if generated).

    7. Replicate the installation to other DB2 subsystems using the $700 series of jobs.

      See Replicating the installation to other DB2 subsystems.

    8. Verify that the products are working correctly:

      • Check the DBC log and DBCPRINT for messages to ensure that the product agents are running successfully.

      • Invoke the product CLIST (if applicable) or run a batch job to verify that the products are working correctly.

If you need help with a specific situation or you need more information, contact BMC Customer Support.

Was this page helpful? Yes No Submitting... Thank you

Comments