Time stamp recovery with PITR and database updates on multiple UOR

Time stamp recovery with PITR (point-in-time recovery) and database updates on multiple UOR (units of recovery) is described here.

The following diagram shows time stamp recovery with PITR (point-in-time recovery) and database updates on multiple UOR (units of recovery).

Figure 1. Time stamp recovery with PITR (point-in-time recovery) and database updates on multiple UORs (units of recovery)
The figure shows three vertical lines representing units of recovery. On the lines are markers indicating updates to database data sets.

The vertical lines in this diagram represent UOR scopes for three UORs that update database data sets in common.

  • The first entry of each line is the beginning of a UOR.
  • The last entry of each line is the end of the sync point for that UOR.

For purposes of this figure, it is assumed that no other UORs have updated any of the database data sets or areas on the recovery list. A time stamp recovery with PITR is run for databases DBa and DBb.

If you did not specify the NOCHECK parameter, a message is issued that indicates that databases DBc and DBd might need to be recovered by using time stamp recovery with PITR with the original recovery time.

After a time stamp recovery with PITR completes, the databases that are marked as recoverable in the RECON and areas cannot be started (the START command fails) nor can they be used by IMS batch jobs until an image copy is taken for each database data set and area (the IC NEEDED flag is set ON in the RECON).

If you take a nonstandard image copy, you must set the IC NEEDED flag to OFF in the RECON by issuing the DBRC CHANGE.DBDS command with the ICOFF parameter. Therefore, the STAGLOBAL and STALOCAL parameters that you specified are ignored for time stamp recovery with PITR.