CHECKPOINT command: Difference between revisions
m (remove Sys Man guide) |
|||
(8 intermediate revisions by 3 users not shown) | |||
Line 2: | Line 2: | ||
<dl> | <dl> | ||
<dt>Privileges | <dt>Privileges | ||
<dd>Any user can issue a CHECKPOINT command without arguments; a system manager or the operator at the console can issue a CHECKPOINT command with arguments. A system administrator might be able to issue a CHECKPOINT command with certain arguments, dependent upon the setting of the CHKPRIV parameter. | <dd>Any user can issue a <var>CHECKPOINT</var> command without arguments; a system manager or the operator at the console can issue a <var>CHECKPOINT</var> command with arguments. A system administrator might be able to issue a <var>CHECKPOINT</var> command with certain arguments, dependent upon the setting of the <var>[[CHKPRIV_parameter|CHKPRIV]]</var> parameter. | ||
<dt>Function | <dt>Function | ||
<dd>Requests that <var class="product">Model 204</var> perform a checkpoint | <dd>Requests that <var class="product">Model 204</var> perform a checkpoint | ||
Line 12: | Line 12: | ||
Where: | Where: | ||
<ul> | <ul> | ||
<li>CHECKPOINT | <li><var>CHECKPOINT</var> commands with no arguments, <code>CHECKPOINT TRAN</code> and <code>CHECKPOINT SUBTRAN</code>, specify by default or explicitly the type of checkpoint request. Any logged in user can issue a <var>CHECKPOINT</var> command with no arguments to attempt a transaction checkpoint. | ||
<p>A system manager can issue any form of the command.</p> | <p>A system manager can issue any form of the command.</p> | ||
<p>The setting CPTYPE is not used by this command.</p> | <p>The setting <var>[[CPTYPE_parameter|CPTYPE]]</var> is not used by this command.</p> | ||
<p> | <p> | ||
Any system administrator can issue one or more forms of the command, if allowed by the setting of CHKPRIV, a non-resettable CCAIN parameter.</p> | Any system administrator can issue one or more forms of the command, if allowed by the setting of <var>[[CHKPRIV parameter|CHKPRIV]]</var>, a non-resettable [[Controlling_system_operations_(CCAIN)|CCAIN]] parameter.</p> | ||
<table> | <table> | ||
<tr class="head"><th>Setting</th> <th>System administrator can do...</th></tr> | <tr class="head"><th>Setting</th> <th>System administrator can do...</th></tr> | ||
<tr><td> | <tr><td>X'01'</td> <td><var>TRAN</var> and/or <var>SUBTRAN</var></td></tr> | ||
<tr><td> | <tr><td>X'02'</td> <td><var>MESSAGE</var></td></tr> | ||
<tr><td> | <tr><td>X'04'</td> <td><var>ABORT</var></td></tr> | ||
<tr><td> | <tr><td>X'08'</td> <td><var>EXTENDED QUIESCE</var></td></tr> | ||
</table></li> | </table></li> | ||
<li>TRAN, the default, specifies to take only transaction checkpoints, as they were in Version 5.1 and earlier.</li> | <li><var>TRAN</var>, the default, specifies to take only transaction checkpoints, as they were in Version 5.1 and earlier.</li> | ||
<li>SUBTRAN specifies to take transaction and sub-transaction checkpoints. See [[Checkpoints: Storing before-images of changed pages#Overview of sub-transaction checkpoints|Overview of sub-transaction checkpoints]] to determine whether you should consider this option and what else is required of your set up.</li> | <li><var>SUBTRAN</var> specifies to take transaction and sub-transaction checkpoints. See [[Checkpoints: Storing before-images of changed pages#Overview of sub-transaction checkpoints|Overview of sub-transaction checkpoints]] to determine whether you should consider this option and what else is required of your set up.</li> | ||
<li>ABORT keyword aborts a pending request for a checkpoint.</li> | <li><var>ABORT</var> keyword aborts a pending request for a checkpoint.</li> | ||
<li>MESSAGE keyword displays the status of the most recent checkpoint.</li> | <li><var>MESSAGE</var> keyword displays the status of the most recent checkpoint.</li> | ||
<li>SET EXTENDED QUIESCE keywords place the Online into an extended quiesce immediately after the next successful checkpoint. Once placed into an extended quiesce, no file updating can take place until the extended quiesce ends. The checkpoint that is taken at the end of Model 204 initialization or recovery is not available for extended quiesce processing. | <li><var>SET EXTENDED QUIESCE</var> keywords place the Online into an extended quiesce immediately after the next successful checkpoint. Once placed into an extended quiesce, no file updating can take place until the extended quiesce ends. The checkpoint that is taken at the end of Model 204 initialization or recovery is not available for extended quiesce processing. | ||
<p> | <p> | ||
The command is ignored if the Online is already in an extended quiesce. Issuing the command multiple times is the same as issuing it once.</p> | The command is ignored if the Online is already in an extended quiesce. Issuing the command multiple times is the same as issuing it once.</p> | ||
<p> | <p> | ||
If you define a ring stream journal that has an OFFLOAD data set defined, then when the extended quiesce begins, Model 204 issues internally an OFFLOAD STREAM command for the ring stream journal.</p></li> | If you define a ring stream journal that has an <code>OFFLOAD</code> data set defined, then when the extended quiesce begins, Model 204 issues internally an <var>[[OFFLOAD_command|OFFLOAD STREAM]]</var> command for the ring stream journal.</p></li> | ||
<li>UNSET EXTENDED QUIESCE keywords reverse the effect of the SET EXTENDED QUIESCE option. The command is ineffective if the: | <li><var>UNSET EXTENDED QUIESCE</var> keywords reverse the effect of the <var>SET EXTENDED QUIESCE</var> option. The command is ineffective if the: | ||
<ul> | <ul> | ||
<li>Online is in an extended quiesce state</li> | <li>Online is in an extended quiesce state</li> | ||
<li>CHECKPOINT SET EXTENDED QUIESCE command has not been issued</li> | <li><code>CHECKPOINT SET EXTENDED QUIESCE</code> command has not been issued</li> | ||
</ul> | </ul> | ||
<p> | <p> | ||
Issuing this command multiple times is the same as issuing it once.</p> | Issuing this command multiple times is the same as issuing it once.</p> | ||
<p> | <p> | ||
Issuing a CHECKPOINT UNSET EXTENDED QUIESCE command when the Online is not yet available for extended quiesce processing, results in the following error: </p> | Issuing a <code>CHECKPOINT UNSET EXTENDED QUIESCE</code> command when the Online is not yet available for extended quiesce processing, results in the following error: </p> | ||
<p class="code">M204.2612: CHECKPOINT COMMAND UNSUCCESSFUL - <var class="term">reasons</var></p> | <p class="code">M204.2612: CHECKPOINT COMMAND UNSUCCESSFUL - <var class="term">reasons</var></p> | ||
</li> | </li> | ||
<li>END EXTENDED QUIESCE keywords terminate an extended quiesce. This command also restarts the checkpoint pseudo subtask and file updating can resume in the Online. If the parameter CPQZSECS=< | <li><var>END EXTENDED QUIESCE</var> keywords terminate an extended quiesce. This command also restarts the checkpoint pseudo subtask and file updating can resume in the Online. If the parameter <code><var>[[CPQZSECS_parameter|CPQZSECS]]</var>=<i>nnnn</i></code> is specified, and neither a <code>CHECKPOINT SET EXTENDED QUIESCE</code> nor <code>CHECKPOINT UNSET EXTENDED QUIESCE</code> command is issued within <var class="term"> nnnn</var> seconds of the start of an extended quiesce, the action specified on the parameter <var>[[CPQZACTN parameter|CPQZACTN]]</var> is initiated.</li> | ||
</ul> | </ul> | ||
==Usage notes== | ==Usage notes== | ||
< | <ul> | ||
<li>The <var>CHECKPOINT</var> command requests that a checkpoint be performed. The <var class="product">Model 204</var> [[Checkpoints:_Storing_before-images_of_changed_pages|checkpoint facility]] provides a means of recovering a valid copy of a database in case of a system failure. The checkpoint facility operates by logging images of any changed file pages to a checkpoint data set. | |||
<p>When a CHECKPOINT command is run, <var class="product">Model 204</var> does not close any currently open files or groups. <var class="product">Model 204</var> automatically generates a unique identifier to be associated with the checkpoint.</p> | <p> | ||
<p>After the checkpoint has been performed successfully, <var class="product">Model 204</var> informs the operator and the audit trail of the date and time that the checkpoint was completed.</p> | When a checkpoint is performed, updating is temporarily suspended, the database is brought to a valid state, and marker records are written on the data set. If a subsequent system crash occurs, the database can be rolled back in time to its status at the time of a previous checkpoint. For a detailed explanation of checkpointing and system recovery, refer to [[Checkpoints: Storing before-images of changed pages]] and [[System and media recovery]].</p> | ||
< | <p> | ||
< | When a <var>CHECKPOINT</var> command is run, <var class="product">Model 204</var> does not close any currently open files or groups. <var class="product">Model 204</var> automatically generates a unique identifier to be associated with the checkpoint.</p> | ||
<p> | |||
After the checkpoint has been performed successfully, <var class="product">Model 204</var> informs the operator and the audit trail of the date and time that the checkpoint was completed.</p></li> | |||
<li>The security required for the <var>ABORT</var> and <var>MESSAGE</var> keywords is the same as for the <var>CHKABORT</var> and the <var>CHKMSG</var> commands.</li> | |||
<li>When a <var>CHECKPOINT</var> command with an <var>END</var>, <var>SET</var>, or <var>UNSET</var> keyword is issued in a valid context, the following message is displayed: | |||
<p class="code">M204.2611: CHECKPOINT SET/UNSET/END COMMAND SUCCESSFUL | <p class="code">M204.2611: CHECKPOINT SET/UNSET/END COMMAND SUCCESSFUL | ||
</p> | </p> | ||
<p>When a CHECKPOINT command with a SET, UNSET, or END keyword is issued in an invalid context, the following message is displayed: </p> | <p> | ||
When a <var>CHECKPOINT</var> command with a <var>SET</var>, <var>UNSET</var>, or <var>END</var> keyword is issued in an invalid context, the following message is displayed: </p> | |||
<p class="code">M204.2612: CHECKPOINT SET/UNSET/END COMMAND UNSUCCESSFUL - <var class="term">reason</var> | <p class="code">M204.2612: CHECKPOINT SET/UNSET/END COMMAND UNSUCCESSFUL - <var class="term">reason</var> | ||
</p> | </p></li> | ||
</ul> | |||
[[Category: System administrator commands]] | [[Category: System administrator commands]] | ||
[[Category: System manager commands]] | [[Category: System manager commands]] | ||
[[Category: | [[Category: User commands]] | ||
[[Category:Commands]] | [[Category:Commands]] |
Latest revision as of 15:40, 7 February 2019
Summary
- Privileges
- Any user can issue a CHECKPOINT command without arguments; a system manager or the operator at the console can issue a CHECKPOINT command with arguments. A system administrator might be able to issue a CHECKPOINT command with certain arguments, dependent upon the setting of the CHKPRIV parameter.
- Function
- Requests that Model 204 perform a checkpoint
Syntax
CHECKPOINT [TRAN | SUBTRAN | ABORT | MESSAGE] [[SET | UNSET | END] EXTENDED QUIESCE]]
Where:
- CHECKPOINT commands with no arguments,
CHECKPOINT TRAN
andCHECKPOINT SUBTRAN
, specify by default or explicitly the type of checkpoint request. Any logged in user can issue a CHECKPOINT command with no arguments to attempt a transaction checkpoint.A system manager can issue any form of the command.
The setting CPTYPE is not used by this command.
Any system administrator can issue one or more forms of the command, if allowed by the setting of CHKPRIV, a non-resettable CCAIN parameter.
Setting System administrator can do... X'01' TRAN and/or SUBTRAN X'02' MESSAGE X'04' ABORT X'08' EXTENDED QUIESCE - TRAN, the default, specifies to take only transaction checkpoints, as they were in Version 5.1 and earlier.
- SUBTRAN specifies to take transaction and sub-transaction checkpoints. See Overview of sub-transaction checkpoints to determine whether you should consider this option and what else is required of your set up.
- ABORT keyword aborts a pending request for a checkpoint.
- MESSAGE keyword displays the status of the most recent checkpoint.
- SET EXTENDED QUIESCE keywords place the Online into an extended quiesce immediately after the next successful checkpoint. Once placed into an extended quiesce, no file updating can take place until the extended quiesce ends. The checkpoint that is taken at the end of Model 204 initialization or recovery is not available for extended quiesce processing.
The command is ignored if the Online is already in an extended quiesce. Issuing the command multiple times is the same as issuing it once.
If you define a ring stream journal that has an
OFFLOAD
data set defined, then when the extended quiesce begins, Model 204 issues internally an OFFLOAD STREAM command for the ring stream journal. - UNSET EXTENDED QUIESCE keywords reverse the effect of the SET EXTENDED QUIESCE option. The command is ineffective if the:
- Online is in an extended quiesce state
CHECKPOINT SET EXTENDED QUIESCE
command has not been issued
Issuing this command multiple times is the same as issuing it once.
Issuing a
CHECKPOINT UNSET EXTENDED QUIESCE
command when the Online is not yet available for extended quiesce processing, results in the following error:M204.2612: CHECKPOINT COMMAND UNSUCCESSFUL - reasons
- END EXTENDED QUIESCE keywords terminate an extended quiesce. This command also restarts the checkpoint pseudo subtask and file updating can resume in the Online. If the parameter
CPQZSECS=nnnn
is specified, and neither aCHECKPOINT SET EXTENDED QUIESCE
norCHECKPOINT UNSET EXTENDED QUIESCE
command is issued within nnnn seconds of the start of an extended quiesce, the action specified on the parameter CPQZACTN is initiated.
Usage notes
- The CHECKPOINT command requests that a checkpoint be performed. The Model 204 checkpoint facility provides a means of recovering a valid copy of a database in case of a system failure. The checkpoint facility operates by logging images of any changed file pages to a checkpoint data set.
When a checkpoint is performed, updating is temporarily suspended, the database is brought to a valid state, and marker records are written on the data set. If a subsequent system crash occurs, the database can be rolled back in time to its status at the time of a previous checkpoint. For a detailed explanation of checkpointing and system recovery, refer to Checkpoints: Storing before-images of changed pages and System and media recovery.
When a CHECKPOINT command is run, Model 204 does not close any currently open files or groups. Model 204 automatically generates a unique identifier to be associated with the checkpoint.
After the checkpoint has been performed successfully, Model 204 informs the operator and the audit trail of the date and time that the checkpoint was completed.
- The security required for the ABORT and MESSAGE keywords is the same as for the CHKABORT and the CHKMSG commands.
- When a CHECKPOINT command with an END, SET, or UNSET keyword is issued in a valid context, the following message is displayed:
M204.2611: CHECKPOINT SET/UNSET/END COMMAND SUCCESSFUL
When a CHECKPOINT command with a SET, UNSET, or END keyword is issued in an invalid context, the following message is displayed:
M204.2612: CHECKPOINT SET/UNSET/END COMMAND UNSUCCESSFUL - reason