ARMBSRR—System resource recovery

The ARMBSRR program enables you to create batch jobs at the local site to restore Db2 system resources at the recovery site before you recover applications. The jobs execute in two phases at the recovery site, an initialization phase (Phase 1) followed by a recovery phase (Phase 2). The jobs do not require any ISPF facilities at either site.

In a non-data-sharing environment, you must run ARMBSRR for each Db2 subsystem that is included in your disaster recovery planning. We recommend that Db2 be active when you run the program. Otherwise, some steps in the process are not generated and others may not be optimized.

In a data sharing environment, you must run ARMBSRR once for each Db2 data sharing object set that is included in your disaster recovery planning. Db2 must be active on the member on which you run ARMBSRR, but other members do not need to be active.

ARMBSRR supports data sharing when the data sharing object set includes members with different IBM Db2 version levels. In these cases, you should execute ARMBSRR to connect to the member with the higher version level. For example, if a data sharing object set has both Db2 Version 11 members and Db2 Version 12 members, you should execute ARMBSRR to connect to a Db2 Version 12 member.

Recovery simulation for ARMBSRR

The ARMBSRR program can generate JCL to simulate recovery of system resources for a disaster recovery.

Recovery simulation is a feature of the Recovery Management for Db2 solution and requires the solution password. The recovery simulation feature simulates all aspects of recovery up to, but not including, the actual I/O. You may find disaster recovery simulation useful in reducing your disaster recovery testing costs.

The ARMBGEN program can simulate the recovery of application resources. For more information, see ARMBGEN—Backup and recovery JCL. Online support for both system and application recovery simulation is also available. For more information about simulation, see the Recovery Management for Db2 documentation.

Recovery estimation for ARMBSRR

The ARMBSRR program can generate JCL to estimate recovery of system resources for a disaster recovery. Estimation is only available with the Recovery Management for Db2 solution. The recovery estimation feature provides an estimate in hours and minutes for the recovery time.

Hardware mirroring support

BMC AMI Recovery Manager supports systems that include DASD hardware mirroring technology as part of their remote site recovery planning.

ARMBSRR supports two levels of hardware mirroring. The first level is for systems that mirror the Db2 BSDS and active logs. The second level is for systems that mirror the catalog and directory data sets in addition to the BSDS and active logs. The JCL generated by ARMBSRR bypasses those steps made unnecessary by the hardware mirroring.

You indicate the level of hardware mirroring using the online interface or by specifying the HWLEVEL option in the ARMBSRR JCL.

In addition, if your system is mirroring only one copy of the BSDS and active logs, you specify which offsite data set copy is being used by using the online interface or by specifying the option in the ARMBSRR JCL.

For systems using hardware mirroring, preparations for disaster recovery are somewhat different than those used for standard systems because updates are being made to the remote site in near real time. For Level 1 systems, you can run ARMBSRR after making backups of the catalog and directory data sets. For Level 2 systems, you can run ARMBSRR at a user-defined frequency.

Extending the recovery point at the disaster recovery site

BMC AMI Recovery Manager supports disaster recovery scenarios where the target application objects have been copied by methods other than Db2 (such as full volume dumps or XRC) and log only recovery is desired.

In these scenarios, you continue to ship archive logs to the disaster recovery site after running ARMBSRR at the local site. This type of recovery recognizes the additional logs and modifies the BSDS and the conditional restart point. To extend the recovery point at the disaster recover site, BMC AMI Recovery Manager uses the following options and programs:

• DREXTEND NO|YES option for ARMBSRR
• LOGONLY NO|YES option for ARMBGEN

• ARMBCOR program—ARMBCOR manipulates the value of the ARMBSDR member in the CNTL data set to ensure that all data sharing members are processed. The JCL generated for ARMBCOR should not be modified.
• ARMBSDR program—The ARMBSDR program finds the most recent BSDS and archive logs at the disaster recovery site (for each member if data sharing) and updates the BSDS. ARMBSDR also adds a new conditional restart control record to the BSDS. For more information about ARMBSDR, see ARMBSDR—Extend recovery point at disaster recovery site.

About JES support

ARMBSRR supports both JES2 and JES3 systems by generating JCL that is optimized to use the job routing features of each.

To enable JES support

BMC AMI Recovery Manager assumes that each subsystem is running with JES2 and that the JES2 IDs are the same as the operating system IDs. If this is not true for your system, you must do one of the following steps:

• For data sharing JES3 systems, you must add the JES3NAME= option to the ARM$OPTS member of the .CNTL file for each Db2 subsystem.
• For data sharing JES2 systems, if the JES2 ID is different than the operating system ID, you must add the JES2NAME= option to the ARM$OPTS member of the .CNTL file. (If the JES ID is the same as the operating system ID, you do not need to add this option.)

Job routing cards

ARMBSRR generates appropriate routing cards, as follows:

• For JES2 data sharing systems, the following is generated with the JESID:

  /*JOBPARM SYSAFF=ssid

• For JES3 data sharing systems, the following is generated with the JESID:

  //*MAIN SYSTEM=ssid

  Important

  For non-data-sharing systems, the /*JOBPARM and //*MAIN cards are not required.

How ARMBSRR selects a subsystem recovery point

The value of the default subsystem recovery point selected by ARMBSRR depends on the following items:

• Which version of Db2 is used and whether the mode is data sharing or non-data-sharing
• Which of the following types of archive log are sent to the recovery site:
  • Recovery site log copy generated by ARMBARC (or PACLOG)
  • One of the local site copies (as specified by OFFSITE NO ARCHIVE1 or ARCHIVE2)

• The parameters of ARMBSRR, which can specify a recovery point

  The default value of the recovery point determined by ARMBSRR is shown in the following table for different Db2 and archive log scenarios.

Default subsystem recovery point selection

 You can override the default by specifying the parameter LASTRBA= or LASTLRSN= in your job EXEC statement, as follows:

• For a non-data-sharing environment, use LASTRBA to specify the hexadecimal value of the starting RBA of the archive log that you want BMC AMI Recovery Manager to use as the last archive log at the recovery site.
• For a data sharing environment, use LASTLRSN to specify the hexadecimal value of the starting LRSN of the archive log you want BMC AMI Recovery Manager to use as the last archive log at the recovery site.
• For coordinated recovery, set LASTRBA or LASTLRSN to the keyword CRRPOINT. ARMBSRR will locate the RBA or LRSN of the last CRRPOINT contained in the repository table. Optionally, you can use CRRPOINT (value) to give a specific point. The value is the RBA or LRSN in the table in hexadecimal format. ARMBCRC must have been run to update the table.

This section contains the following topics: