An overview of CA Datacom Forward Recovery and Backward Recovery processing, using RXX files.

Document ID : KB000018722
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

This is a high-level overview of the processing for CA Datacom Forward Recovery and Backward Recovery, using RXX files

Solution:

As you run application programs, the expectation is that the programs will always process the data correctly, and the devices on which the files are stored will also work correctly. Unfortunately, not all programs are perfect, and not all disk devices work correctly forever. This means that a database might sometime need to be processed to either back out some erroneous updates, or a database might need to be rebuilt from a backup point forward to a device failure.

This is a process known as Backward Recovery (to roll back some updates) or Forward Recovery (to recover forward from a fixed starting point.). In order to accomplish this, you will recover the problem database(s) using the RXX records produced from a DBUTLTY SPILL of the log file (LXX) to a recovery file (RXX). This document will cover some of the primary points and questions that many users have when using this utility.

The first thing to tell the utility is what the input will be - the RXX files. The RXX file allocation (with z/OS DD or z/VSE DLBL statements) must start with the oldest file, and concatenate subsequent RXX files through the latest or most recent RXX file. This is the same for both Forward or Backward Recovery.

Next, we need to identify the date/time range of the records to process. This is always of the format oldest.date.time/latest.date.time. There is one extra consideration here - for Backward Recovery, the latest date can be in the future, or at least equal to or beyond the latest date/time of the RXX file. Another recommendation is to always code latest.date.time for a Backward Recovery to the current time - the time you are running the job.

At this point, we have identified the RXX input source in order from oldest to latest, and we have determined the range of RXX records to process, from oldest to latest. Now, we can either do a Forward or Backward recovery - internally, we start at the oldest.date.time and bring the updates forward for Forward Recovery, and for Backward Recovery we start at the latest.date.time (or end of the file) and process backwards.

There are a couple assumptions about this process:

  1. For Forward Recovery, we assume that the starting point is a backup file that was reloaded, and the oldest.date.time will be the same as that backup date/time. The utility will check that the oldest RXX record to process will match the state of the record using the oldest "Before" image.
  2. For Backward Recovery, we assume that the starting point is the current file state, and that we have all the log records available in the set of RXX files to roll back to the oldest.date.time. The utility will look at the latest "After" record in the RXX, and expect the current record in the database will match it.

There are many other options, settings and selection criteria that can be specified to provide a great amount of flexibility and power to update your databases as you desire.

For more information about these settings and about the process, please refer to the CA Datacom/DB Database and System Administration Guide, in the section "Using Recovery" and the CA Datacom/DB DBUTLTY Reference Guide, in the section "RECOVERY (Rebuild a Database)."

As always, please contact CA Technologies support for CA Datacom if you have further questions.