CCAPRINT: A Newsletter Excerpt for Model 204® Users	June 10, 2007

	Model 204: The RERUNRB Option and the RESTART Command	Printer-friendly version

USE OF AND ACCESS TO PRODUCTS AND FEATURES ARE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE USER’S SOFTWARE LICENSE. THE PRESENTATION OF MATERIAL HEREIN DOES NOT, IN ANY MANNER, MODIFY SUCH TERMS AND CONDITIONS.

The RERUNRB Option and the RESTART Command
By James Damon

The RESTART command initiates recovery of a Model 204 system that may have been damaged by an abnormal termination such as a power failure or an operating system crash. This command is usually the only command in a single user run of Model 204 that is always executed prior to bringing up an Online. This way, a decision as to whether or not to run recovery is not required; recovery is always run prior to bringing up the Online. If recovery has no work to do, because the previous Online terminated normally and took a checkpoint (which is the case most of the time), the process is short and the messages shown in Figure 1 are issued:

Figure 1.

However, this article is not about running recovery on an ordinary day, but instead on the odd day that recovery is required.

Running Recovery

When recovery is required and completes successfully, you might see messages similar to those in Figure 2.

Figure 2.

In Figure 2, both roll back and roll forward recovery completed successfully, although the JUDGMNTS file was not recovered, because it was missing. Perhaps a DD card had been removed. The missing file could be recovered separately, in a subsequent recovery run using the same RESTART and CCARF datasets. However, none of the other files can be recovered again since they have already been recovered. An attempt to rerun recovery exactly as before would result in the messages shown in Figure 3.

Figure 3.

Introducing RESTART RERUNRB

The RERUNRB option to the RESTART command can be used to recover all files, even the ones previously recovered, in a new recovery run using the same RESTART, CCARF and, if sub-transaction checkpoints were enabled, RESTARTS dataset and a new CHKPOINT dataset.

The syntax of the RESTART command with the RERUNRB option is shown in Figure 4.

Figure 4.

Making Recovery More Flexible

The RERUNRB option causes roll back recovery to be rerun even though some or all of the files participating have already been successfully recovered. The same recovery datasets used previously are required in the run using RERUNRB. With this option, it is now possible to completely rerun a previously successful recovery for reasons such as:

• Some files were missing from the original recovery, or
• You want to rerun roll back only and not perform roll forward recovery, or
• You want to rerun roll back recovery and then remove some files so that they do not participate in a subsequent roll forward recovery

Limitations Associated with RERUNRB

The RERUNRB option works only if no updates, other than those being applied by recovery, have been made to the files involved. In other words, if any new updates are made to a file before recovery completes successfully, the messages shown in Figure 5 are issued.

Figure 5.

These messages indicate that the date/time stamp of the last recorded update in file HISTORY is later in time than the last recorded update to that file in the RESTART dataset. Therefore, the file has been updated following the Online failure and before recovery has completed successfully. This file will not participate in recovery.

Also, if sub-transaction checkpoints were enabled in the run being recovered, RERUNRB can only be used after a successful recovery run. Otherwise, the message shown in Figure 6 is issued:

Figure 6.

In Summary

The requirement to use RERUNRB should be rare. However, if you find that recovery needs to be rerun for any reason following a previously successful recovery, and you have not yet brought up the next updating job, RERUNRB can be used to provide that capability.

Home DownloadsFeedback

Contact CCA Webmaster
Copyright 2008