RESTART command: Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
m (Automatically generated page update)
Line 1: Line 1:
This RESTART utility command
==Summary==
requests that the utility issue the equivalent of a user
<dl>
abend in [[Model 204]] for the indicated user or task.
<dt>Privileges
This command should be used only as a last resort when a <var class="product">Model 204</var>
<dd>User 0
Online is looping or hung and all efforts to clear up the situation have
<dt>Function
failed [[Bump Command]].
<dd>Restarts <var class="product">Model&nbsp;204</var> and optionally, recovers files after a system failure
In this situation, the only options left are to cancel (FORCE under CMS)
</dl>
the run or to issue the RESTART utility's RESTART command.
==Syntax==
The RESTART command is preferable because:
<p class="syntax">RESTART [ROLL BACK [TO <i>yy.ddd hh:mm:ss.th</i>]]
<ul>
  [IGNORE (<i>filelist</i>)]
  [ERROR {CONTINUE | STOP | <u>OPERATOR</u>}]
  [NODYNAM]
  [ROLL FORWARD | RERUNRB]
  Where
</p>
<ul>
<li>
<p>ROLL BACK option requests that <var class="product">Model&nbsp;204</var> invoke the ROLL BACK facility.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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.
<table>
 
<tr> <th>
<p>Option </p>
</th> <th>
<p>Indicates that...</p>
</th> </tr>
 
<tr> <th><var>
<p>IGNORE </p>
</var></th> <td>
<p>The IGNORE option will force <var class="product">Model&nbsp;204</var> recovery to skip processing of the listed filenames. For example: </p>
<p class="code">IGNORE (FILE1, FILE2, FILE3, FILE4)
</p>
<p>The filenames may have been allocated either statically or dynamically. </p>
<p>IGNORE (<i>filelist</i>) may appear anywhere in the RESTART command. The file list must be enclosed in parentheses, even if only one file is specified.</p>
</td> </tr>
<tr> <th><var>
<p>CONTINUE </p>
</var></th> <td>
<p>ROLL BACK processing is continued even if <var class="product">Model&nbsp;204</var> cannot open all the files to be recovered.</p>
</td> </tr>
<tr> <th><var>
<p>OPERATOR </p>
</var></th> <td>
<p>The operator is prompted as to whether to continue if <var class="product">Model&nbsp;204</var> cannot open all the files to be recovered. OPERATOR is also the default. </p>
</td> </tr>
<tr> <th><var>
<p>STOP </p>
</var></th> <td>
<p>ROLL BACK processing is not continued if <var class="product">Model&nbsp;204</var> cannot open all the files to be recovered.</p>
</td> </tr>
 
</table>
</p>
</li>
<li>
<li>
The Online might intercept the abend, possibly take a snap dump, and
<p>NODYNAM option indicates that no files are to be dynamically allocated during recovery.</p>
then continue running.
</li>
<li>
<li>
Even if the Online does not continue, it might at least intercept the
<p>ROLL FORWARD option request that <var class="product">Model&nbsp;204</var> invoke the ROLL FORWARD facility after running the ROLL BACK facility.   </p>
abend and terminate &ldquo;cleanly&rdquo;, preventing files from being broken
</li>
and eliminating the need to run recovery.
Cancelling or forcing the Online ensures:
<ul>
<li>Any file with active updating transactions will be left broken.
<li>Recovery will have
to be run before the Online files can be used again.
</ul>
<li>
<li>
The RESTART command will generally result in a CCASNAP being taken
<p>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.</p>
rather than (or in addition to) a SYSMDUMP, SYSUDUMP, or VMDUMP.
<p> 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: </p>
CCASNAPs are generally easier to deal with than other types of dumps.
<p class="code">M204.2741: ROLLBACK/ROLLFORWARD MUST BE RUN PRIOR TO RERUNRB - RECOVERY CANCELLED.
</ul>
</p>
 
<p>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:</p>
The ''abend_code'' must be a 1- to 3-digit hexadecimal code that
<p class="code">M204.0143: NO FILES CHANGED AFTER LAST CP, RESTART BYPASSED
indicates the abend code to be used for the artificially generated
M204.0145: THE FOLLOWING FILES CANNOT BE RECOVERED:
abend.
</p>
Under CMS, the abend code must be between 0C1 and 0CF.
</li>
Any dumps will indicate the specified abend code.
</ul>
 
==Example==
'''Note:'''
<p class="code">RESTART ROLL BACK TO 88.300 10:58:16.98 -
It is important to inform the support personnel that are examining the dump
ERROR OPERATOR
that the abend code was artificially generated by the RESTART utility
</p>
and that the situation was actually a hung or looping Online.
==Usage notes==
 
The RESTART command restarts <var class="product">Model&nbsp;204</var> after a system failure. RESTART is used in conjunction with the checkpoint, ROLL BACK, and ROLL FORWARD facilities available to the system manager. 
To prevent accidentally terminating a user or an Online, a user number
<p class="note"><b>Note:</b> If you plan to use the <var class="product">Model&nbsp;204</var> 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. </p>
can be specified on the RESTART command.
<p>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: </p>
When a user number is specified on the RESTART command, no simulated
<p class="code">M204.0357: INVALID RESTART OPTION: RERUNRB INCOMPATIBLE WITH ROLL FORWARD
abend will occur if the indicated user is not running in the Online.
</p>
For example:
<p>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: </p>
<p class="code">RESTART 0C4 USER 23
<p class="code">M204.2564: filename HAS ALREADY BEEN RECOVERED USING THIS CCARF
</p>
====Submitting RESTART without options====
<p> If no options are given, the following dialog occurs:</p>
<p class="code"><b>RESTART</b>
IS ROLL BACK RECOVERY REQUIRED?
(YES)
(NO)
IS ROLL FORWARD ALSO REQUIRED?
(YES)
(NO)
</p>
<p>YES can be abbreviated Y. NO can be abbreviated N.</p>
<p>When the RESTART command is executed, <var class="product">Model&nbsp;204</var> must determine whether to invoke the ROLL BACK and/or ROLL FORWARD processing. If RESTART is issued without options, <var class="product">Model&nbsp;204</var> prompts you as shown above.</p>
<p>If the system manager does not include the ROLL BACK argument in the RESTART command and replies NO to the ROLL BACK prompt, <var class="product">Model&nbsp;204</var> 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.</p>
====Rolling back and rolling forward====
<p>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 <var class="product">Model&nbsp;204</var> 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.</p>
<p>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, <var class="product">Model&nbsp;204</var> 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, <var class="product">Model&nbsp;204</var> 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.  </p>
<p>If the system manager includes the ROLL FORWARD argument in the RESTART command or replies YES to the ROLL FORWARD prompt, <var class="product">Model&nbsp;204</var> reapplies as many file updates as possible after performing ROLL BACK. <var class="product">Model&nbsp;204</var> recovery facilities are also discussed in the <var>Model&nbsp;204 System Manager's Guide</var>.</p>
====RESTART under z/VSE====
<p>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 command|DEFINE DATASET: Data set or file characteristics]] for more information on this requirement.</p>
====Ignoring files on RESTART====
<p>The IGNORE option enables you to remove a problem file from restart, thus allowing successful recovery of the remaining non-problem files. </p>
<p>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.</p>
<p>An informational message, M204.2915, is issued during RESTART when a named file is IGNOREd.</p>
====Example of processing output with IGNORE option on RESTART====
<p>The following example shows processing output with the IGNORE option: </p>
<p class="code">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
</p>
</p>
simulates a 0C4 abend if user 23 is running.
====Recovering dynamically allocated data sets====
If user 23 is not running, no abend will be simulated.
<p>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 the <var>Model&nbsp;204 File Manager's Guide</var>.</p>
 
<p>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. </p>
If no user is running (a hung Online), it might be necessary to issue
====Undoing ROLL FORWARD processing====
the RESTART command with a task number instead.
<p>ROLL FORWARD processing cannot specify a stopping point. Updates are reapplied to the place where RESTART recovery began. </p>
Unless running MP/204, the task number must be specified as 0.
<p>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 desires:</p>
If MP/204 is running, the task number must be 0 (for the maintask) or
<p class="code">RESTART ROLL BACK ROLL FORWARD
the subtask number (from 1 to NMPSUBS) to be restarted.
RESTART RERUNRB */same as RESTART ROLL BACK RERUNRB/*
For example
RESTART ROLL BACK TO 03.204 14:23:18.98 RERUNRB
<p class="code">RESTART 0A9 TASK 0
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
</p>
</p>
simulates a 0A9 abend on the <var class="product">Model 204</var> maintask.
<p>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. </p>
Note that it is almost always preferable to specify a user number
<p class="note"><b>Note:</b> 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 intermediate locations, and then roll them forward to the job end as many times as you wish.</p>
rather than a task number on the RESTART command.
[[Category:Commands]]
 
[[Category: Operator commands]]
[[Category: Commands]]

Revision as of 01:05, 28 February 2013

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

  • 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.

  • NODYNAM option indicates that no files are to be dynamically allocated during recovery.

  • ROLL FORWARD option request 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.

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 are also discussed in the Model 204 System Manager's Guide.

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 the Model 204 File Manager's Guide.

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 desires:

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 intermediate locations, and then roll them forward to the job end as many times as you wish.