IAM Journal Restore programs overview

• IAMBREST—Automatically invoked under IAM/RLS or IAM/PLEX to do a backout recovery for batch jobs that abend using the IAM/RLS or IAM/PLEX journals.
• IAMJREST—Runs as a batch job and uses the IAM basic log data sets produced by non-RLS file updates or the IAM/RLS or IAM/PLEX log data sets or logstream.
• IAMRREST—Runs as a batch job and uses the logstream journals created by the FRLOG the LOGREPLICATE and the LOGSTREAM specifications.

IAMBREST is automatically invoked by IAM/RLS or IAM/PLEX when a job with data sets under control of IAM/RLS or IAM/PLEX abends and Dynamic Job Backout is set. This utility has no external parameters. IAMBREST performs a backout on all recoverable IAM files that the job step used, up to the most recent syncpoint or to the beginning of the job step, if there are no syncpoints.

The IAM journal processing is selected via IDCAMS Define parameters or IAM overrides or both. For more information about using the various journal processing options, see IAM Journal and Recovery for non-RLS processing in IAM-RLS-Journaling for IAM/RLS, and IAM/PLEX Journaling for IAM/PLEX.

The distinction between IAMRREST and IAMJREST is that IAMRREST handles journal recovery for the logstream data format that is controlled by the LOGREPLICATE and FRLOG specification. IAMJREST handles journal recovery of the journal data from the basic journal process or the IAM/RLS or IAM/PLEX journals. The format of those records is different than the FRLOG/LOGREPLICATE records with a documented format available for user utilization. IAMJREST does have some additional keywords and functionality related to the IAM/RLS and IAM/PLEX environment that IAMRREST does not have.

IAMRREST retrieves Logstream based on journal records via the IAMLOGVR address space if the Logstream specified is managed by the IAMLOGVR address space.

The logstream journals with LOGREPLICATE or FRLOG format can be used by data sets being processed by IAM/RLS or IAM/PLEX, however, the IAM record sharing function is not able to utilize those logs for the IAM record sharing environment. For general undo (backout) and redo (forward recovery) the programs perform the same function just with a different format for the journal records. The keywords and JCL are otherwise identical.

One of the features of using the IAM journal processes is to help improve data availability by reducing the frequency of backing up the complete data set, for example, rather than backing up the complete data set daily, the complete data set can be backed up less frequently, while backing up the IAM journal data set on a daily basis. This provides the same level of recovery capability, while reducing the backup time. Recovery from batch job abends can also be improved by using the ability to back out the file updates that were done by the job steps, as opposed to restoring the data set and rerunning file updates to get back to where the failure occurred.

The capabilities of IAMJREST and IAMRREST include:

• Perform a forward recovery to restore a data set to a specific point in time. After an IAM data set has been restored from a backup copy, IAMJREST or IAMRREST depending on type of journal used can be used to apply selected updates to the data set from the journal file.
• Perform a back out (or backwards) recovery. This type of recovery will back out changes from the specified job steps, to restore a data set to an image prior to the start of the desired job or job step.
• For IAMJREST only, it will release record locks being held after performing a backout or alternatively without performing a recovery. Forward Recovery Process.

Forward recovery process

In the forward recovery process the files with the updated records are selected from the journal. The forward recovery process begins by independently restoring the file’s contents from a backup copy. After a successful restore, the file is updated using the RESTORE FORWARD command with all of the updated records that are on the journal, up to the specified point in time. Actually, the process sorts the selected journal records by key (or RBA for ESDS files) and the time stamp. Then it will only apply to the IAM file the most recent update for each record.

To perform a forward recovery, the journal file must contain after images by specifying one of the following parameters:

• FRLOG set to REDO or ALL
• LOGREPLICATE
• LOG(ALL)
• JRNAD set to AFTER or BOTH

To perform a forward recovery encompassing all of the file updates, then the IAM journal must be specified when the file is defined using the IDCAMS parameters or the IAM CREATE override parameters.

For a typical journal set up to perform forward recoveries, the journal data set should be backed up and emptied at the same time of the data set backup. This eliminates the need of identifying any start point for the forward recovery process, as is done by specifying any of the ‘FROM’ keywords on the restore command. However, there may be a need to use the ‘TO’ keywords to identify an end point.

For example, if there are seven nightly jobs that update a file, called A, B, C, D, E, F, and G. The situation we are setting up a recovery for is a media failure that occurred while job F was running for the third time this week. The job stream can be restarted with job E. We need to restore up to and including job D that ran on the third day. So, the RESTORE command would be:

This would apply the updates for all seven jobs on the first two days, and up through and including job D on the third day. When completed, the data set is ready for rerunning job E, and moving forward.

Backout recovery process

In the backout recovery process the most recent updates to a data set are removed by updating the data set using the before images of records, which are the images of records prior to being updated or deleted. Before images also include images of inserted records, which causes a record deletion by a back out recovery. A back out recovery is used for restoring a data set to the contents it had prior to the start of job or job steps that updated the data set. While a forward recovery can be used if all of the after images have been collected, it will probably be faster just to back out the updates from the failed job rather than reapply what might be several days worth of updates.

To perform a back out recovery process, the journal must contain the undo images (or before update) of the updated records by specifying one of the following depending on journal type used:

• FRLOG set to UNDO or ALL
• LOGREPLICATE
• LOG(ALL) or LOG(UNDO)
• JRNAD set to BEFORE or BOTH

If you want to always back out the updates from any job, then ensure to provide the specification on a CREATE override, just as you would with when using a forward recovery. However, if you only want to provide back out ability for selected jobs, the ACCESS override could be specified for the jobs on which you want to have the backout recoverability.

When setting up the control card for a back out recovery, you want to back out the updates from one or more jobs or job or both, steps that are at the end of the journal data set. You do not need to specify any ‘TO’ keywords to terminate selection, but you would specify some of the ‘FROM’ keywords, or just the JOBNAME or STEPNAME or both keywords.

For example, if job G was the last update job to run, and it abended in one of the steps updating the IAM file. To back out all of the updates made by job G, the restore command would be:

If the journal data set may contain multiple jobs by the name of G, the control statement would be changed to

RESTORE BACKOUT,JOBNAME=G,JOBID=JOBnnnnn or:

Another example would be if you have run jobs A, B, C, D, E, F, and G, with job G abending. For logistical reasons you need to restart with job E. The control statement would look like:

Command summary

The IAM Journal Restore programs have the following commands or functions:

• RESTORE—Invokes either the forward or back out recovery processing.
• RELEASE—Releases the record locks for the specified job without performing a recovery.(IAMJREST only)