RESTART command

Summary

Privileges

User 0

Function

Restarts Model 204 and optionally, recovers files after a system failure

Syntax

RESTART [ROLL BACK [TO yy.ddd hh:mm:ss.th]] [IGNORE (filelist)] [ERROR {CONTINUE | STOP | OPERATOR}] [NODYNAM] [ROLL FORWARD | RERUNRB]

Where:

• The ROLL BACK option requests that Model 204 invoke the ROLL BACK facility.
• TO yy.ddd hh:mm:ss.th is the timestamp ID of a checkpoint. If the TO keyword with timestamp argument is not specified, the database is rolled back to the latest checkpoint.
• ERROR option indicates the way in which errors in opening files are handled. If ERROR is specified, you must also specify one of three options described in the following table:

  Option	Indicates that...
  IGNORE	The IGNORE option will force Model 204 recovery to skip processing of the listed filenames. For example: IGNORE (FILE1, FILE2, FILE3, FILE4) The filenames may have been allocated either statically or dynamically. IGNORE (filelist) may appear anywhere in the RESTART command. The file list must be enclosed in parentheses, even if only one file is specified.
  CONTINUE	ROLL BACK processing is continued even if Model 204 cannot open all the files to be recovered.
  OPERATOR	The operator is prompted as to whether to continue if Model 204 cannot open all the files to be recovered. OPERATOR is also the default.
  STOP	ROLL BACK processing is not continued if Model 204 cannot open all the files to be recovered.

• The NODYNAM option indicates that no files are to be dynamically allocated during recovery.
• The ROLL FORWARD option requests that Model 204 invoke the ROLL FORWARD facility after running the ROLL BACK facility.
• The RERUNRB option lets you undo operationally successful ROLL FORWARD processing. The RERUNRB option specifies that ROLL BACK processing can operate upon a file that was updated beyond the date-time of the checkpoint record. The RERUNRB option forces ROLL BACK processing to reuse the RESTART data set from the previous recovery. Then a file that was rolled forward may be rolled back and/or rolled forward as many times as required.

  You can use the RERUNRB option only after a successful Roll Forward. You cannot use it to rerun a previously failed recovery, otherwise you will generate the following message:

  M204.2741: ROLLBACK/ROLLFORWARD MUST BE RUN PRIOR TO RERUNRB - RECOVERY CANCELLED.

  Without the RERUNRB option, a file that has been rolled forward may not be rolled back again and will receive either of the following messages:

  M204.0143: NO FILES CHANGED AFTER LAST CP, RESTART BYPASSED M204.0145: THE FOLLOWING FILES CANNOT BE RECOVERED:

Example

RESTART ROLL BACK TO 88.300 10:58:16.98 - ERROR OPERATOR

Usage notes

The RESTART command restarts Model 204 after a system failure. RESTART is used in conjunction with the checkpoint, ROLL BACK, and ROLL FORWARD facilities available to the system manager.

Note: If you plan to use the Model 204 system recovery facilities, RESTART must be the first command issued by User 0, immediately following the last user parameter line in the User 0 input.

Both the NODYNAM and RERUNRB options imply ROLL BACK processing. ROLL FORWARD processing is mutually exclusive with RERUNRB processing. If both are specified, RESTART processing aborts with the following message:

M204.0357: INVALID RESTART OPTION: RERUNRB INCOMPATIBLE WITH ROLL FORWARD

If recovery fails but some of the files were successfully recovered, a subsequent recovery run (secondary recovery) may generate the following information message, which does not result in an error condition, for files previously recovered:

M204.2564: filename HAS ALREADY BEEN RECOVERED USING THIS CCARF

Submitting RESTART without options

If no options are given, the following dialog occurs:

RESTART IS ROLL BACK RECOVERY REQUIRED? (YES) (NO) IS ROLL FORWARD ALSO REQUIRED? (YES) (NO)

YES can be abbreviated Y. NO can be abbreviated N.

When the RESTART command is executed, Model 204 must determine whether to invoke the ROLL BACK and/or ROLL FORWARD processing. If RESTART is issued without options, Model 204 prompts you as shown above.

If the system manager does not include the ROLL BACK argument in the RESTART command and replies NO to the ROLL BACK prompt, Model 204 does not perform ROLL BACK, and the new Online job starts immediately. The database is left in the state it was in at the time of the system failure. In general, if the previous Online job ended abnormally or if the entire system crashed, the ROLL BACK facility should be invoked.

RESTART recovery requirements

For information on recovery requirements for CCATEMP, NFILES, and NDIR, see RESTART recovery requirements.

Rolling back and rolling forward

The system manager can request ROLL BACK and/or ROLL FORWARD processing for system recovery. ROLL BACK processing rolls back to the specified checkpoint all updates made to Model 204 files since the time of that checkpoint. This process leaves the database in a consistent state. Then, ROLL FORWARD processing reapplies as many updates performed prior to the system failure as possible.

If ROLL BACK is performed, all files are rolled back to the specified checkpoint. Any changes made to files since that time are undone. If a checkpoint is not specified, Model 204 rolls back to the last checkpoint. During ROLL BACK processing, errors in opening files are handled as specified in the ERROR clause. Regardless of this argument, Model 204 sends to the operator's console a list of files that can be rolled back and a list of those that cannot be rolled back.

If the system manager includes the ROLL FORWARD argument in the RESTART command or replies YES to the ROLL FORWARD prompt, Model 204 reapplies as many file updates as possible after performing ROLL BACK. Model 204 recovery facilities, including ROLL BACK and ROLL FORWARD, are also discussed in System and media recovery.

RESTART under z/VSE

Under z/VSE, the DEFINE DATASET command must precede the User 0 parameter line in the CCAIN input stream, if tape journals or checkpoint datasets are used in RESTART recovery. Refer to DEFINE DATASET: Data set or file characteristics for more information on this requirement.

Ignoring files on RESTART

The IGNORE option enables you to remove a problem file from restart, thus allowing successful recovery of the remaining non-problem files.

The IGNORE option automatically forces the RERUNRB option. This means that all files not ignored will be rolled back, even if there had been a previous recovery run using the same RESTART and CCARF data sets.

An informational message, M204.2915, is issued during RESTART when a named file is IGNOREd.

Example of processing output with IGNORE option on RESTART

The following example shows processing output with the IGNORE option:

M204.2512: ROLL BACK WILL USE THE FOLLOWING DATASET: RESTART M204.1523: EOF REACHED IN FIRST PASS OF RESTART STREAM AFTER SEQ# 5558 OF 11.181 17:10:36.0 M204.2915: IGNORE SPECIFIED FOR FILE K100VAIL BUT RECOVERABLE UPDATES WERE AVAILABLE M204.2915: IGNORE SPECIFIED FOR FILE DEBCPROC WHICH HAD NO RECOVERABLE UPDATES M204.2915: IGNORE SPECIFIED FOR FILE K100UTAH BUT RECOVERABLE UPDATES WERE AVAILABLE M204.0148: THE FOLLOWING FILES WILL BE ROLLED BACK: M204.0149: K100FIJI M204.0149: K100MOAB M204.0149: K100HILO M204.0149: K100KONA M204.0149: K100THAI M204.0149: K100SNOW M204.0149: K100TBLE M204.0149: K100TBLX M204.0157: ROLLED BACK TO TRANSACTION CHECKPOINT 11.181 17:09:36.33 M204.0158: END OF ROLLBACK

Recovering dynamically allocated data sets

Data sets that were dynamically allocated are normally closed and released after recovery. Therefore, you must reallocate the data sets when recovery is over. However, if a dynamically allocated data set was opened in deferred update mode and the NODYNAM option is not chosen, the data set remains opened and allocated after recovery. In this way deferred updates performed after recovery do not overwrite records sent to the deferred update data set before the system failure. The deferred update feature is explained in detail in Deferred update feature.

If the NODYNAM option is chosen, files that were dynamically allocated before a system failure are not dynamically allocated during recovery. The only files recovered are those specified in the JCL for recovery. Under z/VM, only files specified through FILEDEF statements are recovered.

Undoing ROLL FORWARD processing

ROLL FORWARD processing cannot specify a stopping point. Updates are reapplied to the place where RESTART recovery began.

Recovery may be run multiple times, even when successful. For example, if multiple checkpoints were taken then the same recovery run may be submitted with any one of the following RESTART commands to recover the file to whatever stage the user wants:

RESTART ROLL BACK ROLL FORWARD RESTART RERUNRB */same as RESTART ROLL BACK RERUNRB/* RESTART ROLL BACK TO 03.204 14:23:18.98 RERUNRB RESTART ROLL BACK TO 03.204 14:23:18.95 RERUNRB RESTART ROLL BACK TO 03.204 14:23:18.71 RERUNRB RESTART ROLL FORWARD

Because the RESTART command must be the first command in a run, each of the previously listed RESTART commands must be in a separate recovery run.

Note: After recovery is successful, you can use the RERUNRB option to force the roll back to recur. By running RESTART commands similar to the previous sequence, one after another, you can roll files back to the job start or to intermediate locations, and then roll them forward to the job end as many times as you want.

See also

• System and media recovery for information on RESTART recovery data sets, RESTART recovery requirements, rerunning RESTART recovery, sub-transaction checkpoints, and more.
• The RESTART operator command is an entirely different command, which requests a user abend of a Model 204 user or task, for example, to break a CPU loop.