Recovery facilities

Dynamic backout and batch backout support behave differently in non-data sharing and data-sharing environments.

• Dynamic backout

  In non-data sharing and data-sharing environments, an online IMS subsystem dynamically backs out the uncommitted database changes of an application program and discards its uncommitted output messages under either of these conditions:

  • The program fails.
  • The program requests backout with a rollback call.

  In a data-sharing environment, however, IRLM locks and status indicators in the RECON data set ensure integrity by protecting uncommitted changes from sharing subsystems. Operation of the system and other programs continues uninterrupted.

  Related reading:  See IMS Version 15.2 Database Administration for detailed information about dynamic backout.

• Batch backout support

  DBRC improves database integrity by interfacing with IMS restart dynamic backout and the Batch Backout utility to control access to databases in need of backout. DBRC creates a BACKOUT record to track each unit-of-recovery (UOR) for each database in need of backout. DBRC verifies logs that are input to the Batch Backout utility.

  BACKOUT records are created for online subsystems. BACKOUT records are not created for DL/I batch subsystems unless dynamic backout was being used and it failed.

  Prior to performing an emergency restart with the COLDSYS parameter (/ERESTART COLDSYS), run batch backout with either the COLDSTART or ACTIVE parameter. After the batch backout completes, DBRC creates a BACKOUT record for all in-flight and indoubt UORs as candidates for backout. The next IMS restart promotes candidate UORs to backout-needed status and DBRC sets BACKOUT NEEDED=ON in the database records in the RECON data set.

  When dynamic backout fails, a BACKOUT record is created with a UOR indicating dynamic backout failure and DBRC sets BACKOUT NEEDED=ON in the database record in the RECON data set.

  When the databases are backed out successfully, DBRC resets the backout flags in the database records (in the RECON data set) appropriately and updates the BACKOUT records. When backout processing for all of the UORs have been completed, DBRC deletes the BACKOUT record from the RECON data set.

  For DBCTL, if you choose not to back out an unresolved indoubt UOR, use either the DELETE.BKOUT or CHANGE.BKOUT command to remove the unresolved indoubt UOR from the BACKOUT record in the RECON data set.

  DBRC commands are available to update BACKOUT records if needed. The need to make manual changes to the backout record should be minimal.

  Attention: Use the DELETE.BKOUT or CHANGE.BKOUT commands with extreme caution because you could compromise database integrity.

  DBRC verifies the validity of the logs used as input to the Batch Backout utility. DBRC checks the input log volumes to ensure that they are in the correct sequence, that all the needed logs are provided, and that they are properly closed. When you include ACTIVE or COLDSTART statements in the Batch Backout utility SYSIN statement, DBRC performs an additional check to ensure all volumes related to restart are included. For DL/I batch logs, a check is also performed to ensure that the correct volumes are from the last batch execution.

  Attention: If BYPASS LOGVER is included in the SYSIN statement of the Batch Backout utility, then DBRC does not verify the input log and the Batch Backout utility does not notify DBRC about the UORs. Existing UORs are updated when backout processing has completed successfully.
  Although DBRC's backout support protects databases from damage caused by the most common errors, the following list describes some other possible sources of damage to databases:

  • If an IMS subsystem abends and an /ERE COLDSYS command is issued before the in-flight and indoubt UORs have been identified to DBRC (by a Batch Backout run), the databases associated with those in-flights and in-doubts are not protected from erroneous updates until the first Batch Backout run using the COLDSTART or ACTIVE statements.
  • Including logs from multiple runs of a batch job in the same log data set (by specifying DISP=MOD) makes log verification unreliable.
  • You can modify the RECON data set with DBRC commands. Careless use of these commands could lead to errors, such as:
    • Allowing backouts that should not be performed.
    • Allowing other subsystems access to databases that need to be backed out.
  • The Batch Backout BYPASS LOGVER control statement allows backouts to be performed when information in the RECON data set indicates that the input log is invalid or that the backouts are not needed. Careless use of this control statement can cause backouts to be performed that should not be performed.
  • Unregistered databases are not protected from being used while backout is needed.
  • Backing out a normally terminated job (that did not use IRLM) after a time-stamp recovery was performed (to recover the database to a point in time prior to this log) makes log verification unreliable. DBRC will erroneously validate that the log can be used as input because the log being backed out is the last log for this subsystem name (SSID).

  Related reading: See IMS Version 15.2 Database Administration and IMS Version 15.2 Database Utilities for more information about UORs, the database backout process, and the Batch Backout utility.

• Forward recovery
  The process of recovering a database in a data-sharing environment has certain similarities to recovering a database in a non-data sharing environment. In both environments, use DBRC for database recovery and use the following as input to the recovery process:

  • The most recent image copy of the lost database
    Note: If HALDB Online Reorganization is used for the starting point of recovery, then an image copy is not needed because all database changes will be on the log data set(s).
  • The recovery log data set (RLDS) or all pertinent system log data sets used since that copy was made
  Recommendation: Use the RLDS as input to the recovery process. The RLDS is a more efficient input to the recovery process than the pertinent system log data sets because the RLDS contains only database change log records.

  If you are using the Database Recovery Control utility for forward recovery and block-level data sharing is involved, you might require the additional step of change accumulation.

  Related reading: See IMS Version 15.2 Database Administration for further discussion of forward recovery.