System and media recovery - Revision history

Goff: /* Data sets required for the MERGEJ utility */

2024-08-20T08:07:24Z

Data sets required for the MERGEJ utility

← Older revision		Revision as of 08:07, 20 August 2024
Line 2,554:		Line 2,554:
	<li>z/OS and CMS operating systems</li>		<li>z/OS and CMS operating systems</li>

	<li>SORTIN01 through SORTINnn, sequentially numbered, not to exceed ~~SORTIN32~~, which define the journal files from the original updating <var class="product">Model 204</var> runs being recovered as input to the MERGEJ utility</li>		<li>SORTIN01 through SORTINnn, sequentially numbered, not to exceed SORTIN99 with Model 204 V7.8 and above or 32 for releases up to /including Model 204 V7.7, which define the journal files from the original updating <var class="product">Model 204</var> runs being recovered as input to the MERGEJ utility</li>

	<li>SORTOUT to define the single output file</li>		<li>SORTOUT to define the single output file</li>
Line 2,577:		Line 2,577:
	<p>		<p>
	The following examples illustrate further operating system-specific considerations.</p>		The following examples illustrate further operating system-specific considerations.</p>

	===z/OS MERGEJ example===		===z/OS MERGEJ example===
	<p class="code">// EXEC PGM=MERGEJ		<p class="code">// EXEC PGM=MERGEJ

JDamon: /* UTILJ REPORT options */

2018-07-24T23:43:57Z

UTILJ REPORT options

← Older revision		Revision as of 23:43, 24 July 2018
Line 1,922:		Line 1,922:
	<tr>		<tr>
	<td align="right">2</td>		<td align="right">2</td>
	<td>Individual journal records formatted in only ~~hexadecimal~~</td>		<td>Individual journal records formatted in hexadecimal only</td>
	</tr>		</tr>

	<tr>		<tr>
	<td align="right">4</td>		<td align="right">4</td>
	<td>Journal blocks in only ~~hexadecimal~~ </td>		<td>Journal blocks in hexadecimal only</td>
	</tr>		</tr>

	<tr>		<tr>
	<td align="right">8</td>		<td align="right">8</td>
	<td>Histogram showing the size ranges of the blocks written in a run~~, which is helpful in determining size and number of buffers.~~</td>		<td>Histogram showing the size ranges of the blocks written in a run</td>
	</tr>		</tr>
	</table>		</table>
Line 1,975:		Line 1,975:
	<li><code>DCB BLOCKSIZE</code> is the size of each journal buffer. In this example, the buffer is the default size, 6749 bytes. </li>		<li><code>DCB BLOCKSIZE</code> is the size of each journal buffer. In this example, the buffer is the default size, 6749 bytes. </li>
	</ul>		</ul>

	===UTILJ return codes===		===UTILJ return codes===
	<p>		<p>

JAL: change to mixed case

2018-04-25T16:39:37Z

change to mixed case

← Older revision		Revision as of 16:39, 25 April 2018
Line 197:		Line 197:
	A commit is the process of ending a transaction and making the transaction updates permanent. A commit is performed by issuing: </p>		A commit is the process of ending a transaction and making the transaction updates permanent. A commit is performed by issuing: </p>
	<ul>		<ul>
	<li><var>~~COMMIT~~</var> statement</li>		<li><var>Commit</var> statement </li>

	<li><var>~~COMMIT RELEASE~~</var> statement</li>		<li><var>Commit Release</var> statement </li>

	<li>Host Language Interface <var>IFCMMT</var> call</li>		<li>Host Language Interface <var>IFCMMT</var> call </li>
	</ul>		</ul>
	<p>		<p>
Line 212:		Line 212:
	SOUL transactions are ended by any one of the following events: </p>		SOUL transactions are ended by any one of the following events: </p>
	<ul>		<ul>
	<li>A <var>~~BACKOUT~~</var> statement, the transaction is ended after the back out is complete</li>		<li>A <var>Backout</var> statement, the transaction is ended after the back out is complete</li>

	<li>A <var>~~COMMIT~~</var> statement</li>		<li>A <var>Commit</var> statement</li>

	<li>A <var>~~COMMIT RELEASE~~</var> statement</li>		<li>A <var>Commit Release</var> statement</li>

	<li>End of a subsystem procedure, unless overridden in the subsystem definition</li>		<li>End of a subsystem procedure, unless overridden in the subsystem definition</li>
Line 271:		Line 271:
	</ul>		</ul>
	<p>		<p>
	See ~~the <var class="book">Rocket Model 204 Host Language Interface Reference Manual</var>~~ for a discussion of Host Language Interface transaction behavior.</p>		See [[HLI: Transactions]] for a discussion of Host Language Interface transaction behavior. </p>

	===Back out mechanism===		===Back out mechanism===
	<p>		<p>
	Transaction back out logically reverses transactions by applying compensating updates to files participating in the transaction. For example, the logical reversal or back out of a <var>~~STORE RECORD~~</var> statement is equivalent to processing a <var>~~DELETE RECORD~~</var> statement. </p>		Transaction back out logically reverses transactions by applying compensating updates to files participating in the transaction. For example, the logical reversal or back out of a <var>Store Record</var> statement is equivalent to processing a <var>Delete Record</var> statement. </p>
	<p>		<p>
	Compensating updates for incomplete transactions are stored temporarily in a back out log in CCATEMP and then deleted when the transaction is committed or backed out.</p>		Compensating updates for incomplete transactions are stored temporarily in a back out log in CCATEMP and then deleted when the transaction is committed or backed out.</p>

JAL: /* Lock-pending-updates locking mechanism */ add `s`

2018-04-25T16:16:57Z

Lock-pending-updates locking mechanism: add <var>s

← Older revision		Revision as of 16:16, 25 April 2018
Line 293:		Line 293:
	<li>Released by:</li>		<li>Released by:</li>

	<li>SOUL <var>~~BACKOUT~~</var>, <var>~~COMMIT~~</var>, and <var>~~COMMIT RELEASE~~</var> statements</li>		<li>SOUL <var>Backout</var>, <var>Commit</var>, and <var>Commit Release</var> statements</li>

	<li>Host Language Interface <var>IFBOUT</var>, <var>IFCMMT</var>, and <var>IFCMTR</var> calls</li>		<li>Host Language Interface <var>IFBOUT</var>, <var>IFCMMT</var>, and <var>IFCMTR</var> calls</li>
Line 300:		Line 300:
	</ul>		</ul>
	<p class="note"><b>Note:</b>		<p class="note"><b>Note:</b>
	The SOUL <var>~~RELEASE RECORDS~~</var> statement does not release the LPU lock.</p>		The SOUL <var>Release Records</var> statement does not release the LPU lock. </p>

	===Back out and constraint logs===		===Back out and constraint logs===
	<p>		<p>

DCameron: /* Understanding an extended quiesce */

2018-01-23T14:53:41Z

Understanding an extended quiesce

← Older revision		Revision as of 14:53, 23 January 2018
Line 1,550:		Line 1,550:
	<p>		<p>
	File commands that start update units remain in a nonbumpable, swappable wait until the extended quiesce ends. File updating IFAM threads remain in nonbumpable, swappable waits during extended quiesce.</p>		File commands that start update units remain in a nonbumpable, swappable wait until the extended quiesce ends. File updating IFAM threads remain in nonbumpable, swappable waits during extended quiesce.</p>

	====Signing on IFAM threads during an extended quiesce====		====Signing on IFAM threads during an extended quiesce====
	<p>		<p>

Dme: /* Media recovery NonStop/204 */

2017-12-27T12:01:17Z

Media recovery NonStop/204

← Older revision		Revision as of 12:01, 27 December 2017
Line 1,529:		Line 1,529:
	</p>		</p>

	==Media recovery NonStop/204==		==<b id="nonStop"></b>Media recovery NonStop/204==
	<p>		<p>
	Media recovery restores an individual <var class="product">Model 204</var> file, not the entire database as discussed in [[#ROLL BACK facility\|ROLL BACK facility]], from a backed up version of the file. </p>		Media recovery restores an individual <var class="product">Model 204</var> file, not the entire database as discussed in [[#ROLL BACK facility\|ROLL BACK facility]], from a backed up version of the file. </p>

ELowell at 17:05, 30 October 2017

2017-10-30T17:05:13Z

← Older revision		Revision as of 17:05, 30 October 2017
Line 489:		Line 489:
	<ul>		<ul>
	<li>In Model 204 version 7.6 and earlier, ROLL BACK processing reapplies page images to the files by reading the CHKPOINT stream backward.</li>		<li>In Model 204 version 7.6 and earlier, ROLL BACK processing reapplies page images to the files by reading the CHKPOINT stream backward.</li>
	<li>In Model 204 version 7.7 and later, roll back pass 1 reads the recovery data set forward, and roll back pass 2 begins at the checkpoint and reads the recovery dataset forward (not backward), applying the ~~pre-images~~. This allows the CHKPOINT (and CHKPNTS) to support LARGE datasets (up to 16 million tracks). Duplicate records are not written, so the checkpoint remains smaller and less likely to fill.</li>		<li>In Model 204 version 7.7 and later, roll back pass 1 reads the recovery data set forward, and roll back pass 2 begins at the checkpoint and reads the recovery dataset forward (not backward), applying the preimages. This allows the CHKPOINT (and CHKPNTS) to support LARGE datasets (up to 16 million tracks). Duplicate records are not written, so the checkpoint remains smaller and less likely to fill.</li>
	</ul></p>		</ul></p>
	<p>		<p>

JDamon: /* Message for the Operator */

2017-10-12T19:09:39Z

Message for the Operator

← Older revision		Revision as of 19:09, 12 October 2017
Line 535:		Line 535:
	</p>		</p>
	<p>		<p>
	The message gives the processing sequence number and date-time stamp. It is issued at the Operator's console for each occurrence of ~~an hour~~ change in the date-time stamp of the CCARF update records.</p>		The message gives the processing sequence number and date-time stamp. It is issued at the Operator's console for each occurrence of a minute change in the date-time stamp of the CCARF update records.</p>
	<p>		<p>
	You could receive a maximum of 24 such messages in a 24-hour period.</p>		You could receive a maximum of 24 such messages in a 24-hour period.</p>

ELowell: /* RESTART recovery requirements - CCATEMP, NFILES, NDIR */

2017-06-08T20:06:51Z

RESTART recovery requirements - CCATEMP, NFILES, NDIR

← Older revision		Revision as of 20:06, 8 June 2017
Line 1,295:		Line 1,295:
	The RESTART value for: </p>		The RESTART value for: </p>
	<ul>		<ul>
	<li><var>NFILES</var> ~~may need increase by as much as two~~ greater than ~~set~~ in ~~the Online CCAIN, if CCAGRP and CCASYS were opened by~~ the Online.</li>		<li><var>NFILES</var> must be greater than or equal to the value for NFILES specified in the Online.</li>

	<li><var>NDIR</var> ~~may need~~ to ~~increase by as much as three to accommodate CCATEMP, CCAGRP, and CCASYS, if they were opened by~~ the Online.</li>		<li><var>NDIR</var> must be greater than or equal to the value for NDIR specified in the Online.</li>

	<li>~~CCATEMP in RESTART must be at least as large as that in the job that is being recovered. Verify that the CCATEMP data set allocation or~~ <var>TEMPPAGE</var> in RESTART ~~meets this requirement~~. </li>		<li><var>TEMPPAGE</var> (CCATEMP) in RESTART must be greater than or equal to the value for TEMPPAGE specified in the Online. </li>
	</ul>		</ul>
	<p>		<p>

ELowell: /* ROLL BACK processing, Pass 2 */

2016-08-17T16:52:41Z

ROLL BACK processing, Pass 2

← Older revision		Revision as of 16:52, 17 August 2016
Line 488:		Line 488:
	In Pass 2:		In Pass 2:
	<ul>		<ul>
	<li>In Model 204 version 7.6 and earlier, ROLL BACK processing reapplies page images to the files by reading the CHKPOINT stream ~~backwards~~.</li>		<li>In Model 204 version 7.6 and earlier, ROLL BACK processing reapplies page images to the files by reading the CHKPOINT stream backward.</li>
	<li>In Model 204 version 7.7 and later, roll back pass 1 reads the recovery data set forward, and roll back pass 2 begins at the checkpoint and reads the recovery dataset forward (not backward), applying the pre-images. This allows the CHKPOINT (and CHKPNTS) to support LARGE datasets (up to 16 million tracks). ~~In 7.7, duplicate~~ records are not written, so the checkpoint remains smaller and less likely to fill.</li>		<li>In Model 204 version 7.7 and later, roll back pass 1 reads the recovery data set forward, and roll back pass 2 begins at the checkpoint and reads the recovery dataset forward (not backward), applying the pre-images. This allows the CHKPOINT (and CHKPNTS) to support LARGE datasets (up to 16 million tracks). Duplicate records are not written, so the checkpoint remains smaller and less likely to fill.</li>
	</ul></p>		</ul></p>
	<p>		<p>