Replicating the installation to other DB2 subsystems

The procedures in this section offer two methods for replicating DB2 objects to other DB2 subsystems. You can use the Multiple Subsystem Install (MSSID) method through the Installation System, or you can use product deployment.

Note

BMC products use product-specific DB2 objects for some features. The same product code base can be used with many DB2 subsystems at differing DB2 versions and modes. The procedures in this section are based on the following assumptions:

  • Only the DB2 objects need to be created.
  • The product suite of data sets from another installation will be used to run the relevant jobs.

Use the procedure that best suits your situation:

  • To replicate DB2 objects by using MSSID
    The Installation System's MSSID method replicates the DB2 objects to other DB2 subsystems with just a few changes to the original DB2 subsystem values. This method generates a JCL data set for each subsequent subsystem.
  • To use product deployment
    Product deployment requires running a job to copy the JCL data set and then changing some values in the INCLUDE members before running the jobs.

To replicate DB2 objects by using MSSID

  1. Invoke the installation CLIST.
  2. Select the install project that was used for the full install on the initial DB2 subsystem.
  3. From the Execute Project panel, select Configuration Option 6 Multiple SSID install for DB2 Products only.
  4. Complete the MSSID options for the DB2 subsystems for which you want to replicate the installation.

    You can change the job card and other options for each subsystem, if necessary.

    When you finish specifying options, the Installation System generates the $S00JCL job.

  5. Run the generated $S00JCL job.

    This job replicates a JCL data set for each DB2 subsystem. Each data set contains jobs to run for that subsystem, customized with the correct DB2 libraries.

  6. Run the $700 series installation jobs for each DB2 subsystem, taking the following details into consideration:
    • Before running the $729DOP1 job (if generated):

      • If your original install specified to migrate the DOPTS modules for your products, the job will include a pppDOPT step (where ppp is the product code) to copy the existing DOPTS modules forward to the new version. The job will also include a pppMERGE step to create a new DOPTS module from default values, but this step will be commented out.

      • If your new environment does not have any DOPTS modules to carry forward, then comment out the pppDOPT step and uncomment the pppMERGE step. Review the symbolic variables for these steps in the $$INCDB2 member. Copy any variables that need to change to the $$INCUSR member and change the values there

    • If your original install specified to migrate DB2 data, other migrate jobs will be generated such as $763MIGP, $765MIG, $766MIG, $767COPY. Do not run these jobs if your new environment does not have any DB2 data to migrate.

    • For those BMC products that use an LGC option set and generate a $770IVP job, ensure that the option set that the job is using exists before running the job. The DBC started task must be running and the LGC agent must be activated in order to access the option set.

To use product deployment

  1. Run the $$JCLCPY in the install JCL to make a copy of the original JCL to be used for deployment.
  2. Edit the $$INC members to change any values needed for this deployment.

    Tip

    Instead of editing each $$INC member for new values, copy the SET statements for variables you want to change to the $$INCUSR member. Any values in the $$INCUSR member will override the values in the other $$INC members. When specifying only the variables that have to change from one system to another in the $$INCUSR member, it speeds up locating and changing the values and helps to keep you organized.

  3. Use your own process to transport the runtime data sets to the other environment if necessary.
  4. Run all of the $700 series jobs in order, taking the following details into consideration

    • Before running the $729DOP1 job (if generated):

      • If your original install specified to migrate the DOPTS modules for your products, the job will include a pppDOPT step (where ppp is the product code) to copy the existing DOPTS modules forward to the new version. The job will also include a pppMERGE step to create a new DOPTS module from default values, but this step will be commented out.

      • If your new environment does not have any DOPTS modules to carry forward, then comment out the pppDOPT step and uncomment the pppMERGE step. Review the symbolic variables for these steps in the $$INCDB2 member. Copy any variables that need to change to the $$INCUSR member and change the values there.

    • If your original install specified to migrate DB2 data, other migrate jobs will be generated such as $763MIGP, $765MIG, $766MIG, $767COPY. Do not run these jobs if your new environment does not have any DB2 data to migrate.

    • For those BMC products that use an LGC option set and generate a $770IVP job, ensure that the option set that the job is using exists before running the job. The DBC started task must be running and the LGC agent must be activated in order to access the option set.

    Best practice

    BMC recommends that you use the product deployment method if you need to deploy the products to other sysplexes or LPARs. For more information, see the Installation System documentation.

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

Comments