Implementing a legacy multiple-RMGR configuration

This legacy RMGR configuration enables IMS systems that participate in a data-sharing environment to use the same RMGR resources and functions. BMC now provides the RMGR configuration to serve this purpose with less effort to implement, maintain, and operate RMGR components. BMC no longer recommends the RMGR configuration unless you are using the APPLICATION RESTART Control (AR/CTL) suspend-and-resume interface.

In a legacy multiple-RMGR configuration for an environment in which two or more IMS systems will share data, you must set up a sharegroup and create an RMGR for each IMS that is involved in data sharing. The RMGRs must belong to the same RMGR sharegroup, whether the IMS systems are running on one operating system or on different systems in a sysplex environment. Each IMS system is connected to its own RMGR. One repository is shared by all RMGRs that belong to the sharegroup.

In the repository, you must create a sharegroup environment record. You can also create IMS environment records if needed; if any IMS system in the sharegroup is at a different version level than the one defined in the sharegroup definition record, an individual IMS environment record is required. When you submit function requests through the ISPF interface or the Batch Interface utility, you can specify the sharegroup name or an RMGR name.

When you configure RMGR for use in a SYSPLEX environment, the procedure is identical to configuring RMGR in a data-sharing environment. You must set up a sharegroup and create an RMGR for each IMS system in the SYSPLEX.

The following figure shows a typical data-sharing environment.

Typical data-sharing environment

To achieve all of the functionality that RMGR is designed to provide in an IMS data-sharing or sysplex environment, an RMGR instance must be configured and available for each IMS instance that is involved in data sharing. This requirement applies whether an IMS instance is on the same or different system image as the other IMS instances, as long as the IMS instances communicate with each other by using the Cross-System Coupling Facility (XCF).

RMGR provides considerable functionality even if only one RMGR instance is available to participate in an IMS data-sharing environment. The following functions and utilities are available in this case:

• Batch Interface utility (the functions that do not require IMS commands)

• Check Assets function

• Automatic Delete/Define (DRAMS) utility

• Find Recovery Points function

• Group Build function

• Group Rebuild function

• Group Validation function

• Log Analysis function

• Disaster Recovery RECON Cleanup (DRRCN) utility

• Recovery Advisor functions (available only with BRS)

• Create Recovery JCL function (/DBR of databases must be done manually)

When only one RMGR instance is used in a data-sharing environment, the unavailable RMGR functionality is related to issuing and validating IMS commands across all of the IMS instances. The following RMGR functionality is unavailable in this case:

• Hold Point of Consistency (HPC) function: issuing /DBR and /STA commands to create quiet points for recovery

• IMS Command utility: issuing various IMS commands in batch

• Log Sync function: issuing /SWI command to synchronize log switches across multiple IMS instances

To implement a legacy multiple-RMGR configuration

1. Decide on a 4-character sharegroup name. The name of the sharegroup is unique value for RMGR use; it does not need to match the value of an IMSGROUP keyword, and it must be different from the IMS IDs of the IMS systems in the sharegroup. This name must also be different from the RMGR name.
2. If an RMGR configuration does not already exist for at least one of the IMS systems that belongs to the data-sharing group, create an RMGR configuration as described in Customizing Recovery Manager functions and utilities or Creating a new RMGR configuration from a model.
3. Add a SHAREGROUP keyword to the control statement data set of the existing or new RMGR. For more information, see Managing the RMGR started task or job.
4. Stop and restart the RMGR. RMGR creates an empty sharegroup environment record.
5. Update the sharegroup environment record. For more information, see Working with IMS/sharegroup environment records.
6. Copy the existing RMGR startup procedure to create an RMGR for each IMS system that is involved in data sharing. For more information, see Managing the RMGR started task or job.
7. Copy the RMGR SYSIN control statement that you created in Step 2 to create a SYSIN control statement for each new RMGR.
   1. Change the IMSID keyword value to reflect the IMS ID of the IMS that the RMGR will serve.
   2. Create a JCL PDS for each new RMGR, and change the JOBPDS keyword value to refer to the data set name of the new JCL PDS.
   3. Ensure that the SHAREGROUP keyword value refers to the same sharegroup environment record.
   4. Ensure that the REPOSITORYBASE keyword value refers to the same repository as the existing RMGR.
   5. Change any other keywords as necessary.
8. Start the new RMGR.
9. If any of the following elements are different between a new IMS in the sharegroup and the existing IMS, create an IMS environment record for each IMS that has a difference. For more information, see Working with IMS/sharegroup environment records.

   • RESLIB (different releases or PUT levels)

   • MODSTAT

   • ACBLIBs

   • RSENAMEs (if the IMS is XRF-capable)

10. Modify the JCL that starts each IMS control region in the sharegroup as follows:
    1. Insert the BMC product load library ahead of RESLIB in the STEPLIB concatenation.
    2. If the CPU authorization password for the BMC product is not located in the BMC product load library, insert the library that contains the product authorization password table in the STEPLIB or BMCPSWD DD concatenation.
11. Stop and start each IMS system in the sharegroup.