Recovering the RECON data sets

Steps for recovering your RECON data set depend on the set up of your RECON data set and the situation.

The following paragraphs discuss various scenarios for recovering a RECON data set.

A Spare RECON data set is available
If an I/O error occurs on a RECON data set and a spare data set is available, DBRC copies the good RECON data set to the spare, and then activates the spare.

If, however, you want to analyze the RECON data set error, before deleting and redefining the discarded RECON data set, make a copy of it for later problem diagnosis.

A Spare RECON data set is not available
If a spare RECON data set is not available, all currently executing jobs continue processing using the RECON data set in single mode. If you specified the STARTNEW parameter in the INIT.RECON or CHANGE.RECON command, DBRC allows new jobs to start with only one RECON data set. This is not recommended as it jeopardizes the integrity of the system.

If one of the data sets in the set of RECON data sets becomes unusable by DBRC, you need to deallocate the RECON data set that is unusable and allocate a new spare.

Both RECON data sets are not usable:
It is unlikely that both RECON data sets would be not usable. If, however, both RECON data sets ever become unusable, follow this procedure:

Procedure

  1. Stop all jobs that require access to the RECON data set.
  2. Optional: Use the AMS REPRO command to back up the RECON data sets if you can access both of them.
  3. Use the AMS utility to delete and redefine your RECON data sets.
  4. Use the AMS REPRO command to restore one of the RECON data sets.
  5. Use the AMS REPRO command to restore the other RECON data set from the first.
  6. Use the LIST.RECON command to list one of the RECON data sets. Evaluate the list and determine which DBDSs have been updated since you made the backup in step 2. If you cannot determine which DBDSs have been updated, assume that all have been updated.
  7. Use the CHANGE.IC command with the INVALID parameter to mark all image copy records that are in error for all applicable DBDSs in step 6.
  8. Make an image copy of all applicable DBDSs in step 6.
  9. Use the BACKUP.RECON command to make a backup copy of the RECON data sets.

The RECON data sets are now restored and resynchronized with the databases.

If you do not control an excessive number of databases, it might be easier to follow this procedure:

  1. Stop all jobs that require access to the RECON data set.
  2. Define new RECON data sets.
  3. Initialize these RECON data sets.
  4. Register the environment. Always keep a backup copy of the most recently initialized, but not-yet-used, RECON data set available.
  5. Take image copies of all databases.

Finally, before you proceed with your regular operations, clean up the new RECON data set by, for example, closing any open, out-of-date OLDSs with the NOTIFY.PRILOG command.