About ARMBGEN

You can use ARMBGEN in the following ways:

• Code JCL to run ARMBGEN to create backup or recovery JCL. This method completely avoids using a TSO session.
• Use online support that is provided by BMC AMI Recovery Manager to create ARMBGEN JCL. This approach requires only a short TSO session.

You can optionally update the backup and recovery options for the specified object set or object sets. This is the OBJECTSET UPDATE feature of the ARMBGRP program and all options are described in detail in ARMBGRP—Object set creation and maintenance. If you do not change the options in the ARMBGEN syntax, ARMBGEN uses the options that are currently in effect for each object set or object sets.

About XUNCHANGED processing in local subsystem recovery

During local full subsystem recoveries, BMC AMI Recovery Manager uses the XUNCHANGED option of ARMBGEN to identify and exclude objects that have not changed between the recovery time and the current time.

This process can significantly reduce recovery time by avoiding unnecessary recoveries.

BMC AMI Recovery Manager first analyzes SYSCOPY and SYSLGRNX information to identify objects that appear to be unchanged and mark them as unchanged. After the Db2 catalog is recovered, BMC AMI Recovery Manager compares information in the Db2 catalog with the information stored in the BMC AMI Recovery Manager log range file that is built by program ARMBLGR during the preparation for local subsystem recovery. BMC AMI Recovery Manager does the following comparisons, which may result in an object that is marked unchanged being marked for recovery:

• For each table space identified as unchanged and for all indexes belonging to the unchanged table spaces, BMC AMI Recovery Manager compares the following values with those in the Db2 catalog. If any difference is found, BMC AMI Recovery Manager marks the table space or index for recovery.
  • DBID
  • PSID
  • PART
  • INSTANCE
  • IPREFIX
  • VCAT name
  • CREATE timestamp
• BMC AMI Recovery Manager runs a comparison to identify table spaces that exist in the Db2 catalog but that are not in the BMC AMI Recovery Manager log range file (a condition that means the table space was dropped after the recovery point). BMC AMI Recovery Manager marks any table spaces found in this condition for recovery.
• BMC AMI Recovery Manager runs a comparison to identify indexes that exist in the Db2 catalog but that are not in the BMC AMI Recovery Manager log range file (a condition that means the index was dropped after the recovery point). BMC AMI Recovery Manager marks any indexes found in this condition for recovery.
• BMC AMI Recovery Manager identifies orphan VSAM data sets that were created after the recovery point and marks them for deletion.

Using ARMBGEN in full subsystem recovery

You can use ARMBGEN to provide more automation for the recovery of an entire Db2 subsystem.

Large applications such as SAP often require that the entire subsystem be included in the backup and recovery process. At the local site, the system resource recovery program, ARMBSRR, generates JCL to recover the subsystem to a prior point in time using a conditional restart. When ARMBSRR is completed, you can run the batch log range analysis program, ARMBLGR, to identify objects that have not changed between the recovery point and the current time. You can then generate application recovery JCL by using ARMBGEN and specifying the XUNCHANGED option. This action excludes unchanged objects from the recovery, thus improving recovery performance.

Using ARMBGEN in planning disaster recovery

You can use ARMBGEN to provide more automation for the recovery of your applications in a disaster recovery situation.

At the local site, the system resource recovery program, ARMBSRR, updates the archive history file with the end relative byte address (RBA) of the disaster recovery point. When ARMBSRR is completed, you can generate application recovery JCL by using ARMBGEN and specifying RESTARTRBA as the recovery type. ARMBGEN uses the end RBA, which was updated by the ARMBSRR job, to generate ready-to-run application recovery jobs that you can transport to the recovery site.

You can also use ARMBGEN to simulate and estimate recovery. Simulation can pinpoint any missing resources or tape copies that are not usable. Estimation can provide information about long-running objects and overall recovery time. (Simulation and estimation are only available with the Recovery Management for Db2 solution.)

You might realize a significant improvement in data set sizing accuracy with this technique when the operating system catalog information is available at the local site but not at the recovery site. 

About BACKOUT recovery

A BACKOUT recovery does not require image copies to perform a point-in-time recovery. Instead, it backs out the log records to undo or redo the changes that occurred between the selected point in time and the current point.

This method returns the spaces and indexes to the required state without the overhead of restoring image copies, or rebuilding or restoring indexes. In most cases, the BACKOUT recovery strategy is dramatically faster than traditional forward recovery. See the REORG PLUS for DB2 documentation for more information about the BACKOUT option.

The backout to forward recovery strategy (BACKOUT AUTO) uses both the BACKOUT recovery and the traditional forward recovery functionality of BMC AMI Recover for point-in-time recoveries. Using this strategy, BMC AMI Recovery Manager generates JCL for BMC AMI Recover to first attempt to back out the spaces that need to be recovered. If any spaces cannot be backed out, BMC AMI Recover automatically performs a forward recovery for those spaces. This option is only valid when you are using BMC AMI Recovery Manager as part of the Recovery Management for Db2 solution.

You can also use BACKOUT when you choose Db2 RECOVER (DSNUTILB) as the recovery utility. The default value is NO. BACKOUT with DSNUTILB has the same restrictions as BACKOUT with BMC AMI Recover.

If DSNUTILB is selected as the recovery utility and the Db2 version is less than Version 10, BMC AMI Recovery Manager changes BACKOUT to NO and continues.

Be aware of the following limitations:

• BACKOUT AUTO is invalid with DSNUTILB.
• If you specify BACKOUT AUTO or BACKOUT YES, you must choose one of the following recovery points:
  • TOQUIESCE
  • TOCOMMONRECPT
  • TOLOGPOINT

  • TOTIMESTAMP (Recovery Management solution only)

    Recovery to CURRENT, TOCOPY, or TORESTARTRBA are not valid choices with a backout recovery.

• BACKOUT recovery requires that spaces be undamaged and not be in RECP, RECP*, RBDP, RBDP*, PSRCP, PSRBD, GRECP, WEPR, or STOPE status or have an LPL range. BACKOUT also cannot be used for the following spaces:
  • LOB spaces
  • NOT LOGGED spaces
• The following table lists options that conflict with BACKOUT AUTO.