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 at some point 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 allocation structure for both Forward and 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:
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 documentation section called "Using Recovery" and the DBUTLTY Reference section called "RECOVERY (Rebuild a Database)."
As always, please contact CA Technologies support for CA Datacom if you have further questions.