COMPACTB command - Revision history

DCameron: /* Example: file statistic changes */

2019-02-11T12:50:22Z

Example: file statistic changes

← Older revision		Revision as of 12:50, 11 February 2019
Line 110:		Line 110:
	</p>		</p>
	<p>		<p>
	The value of the <var>BQLEN</var> parameter changed. When the original extensions were deleted, a page became suitable for reuse and was placed on the Reuse Queue. In this example unused pages were used for new extensions. If new extensions are placed on a page from the Reuse Queue, <var>BQLEN</var> might decrease.</p>		The value of the <var>[[BQLEN_parameter\|BQLEN]]</var> parameter changed. When the original extensions were deleted, a page became suitable for reuse and was placed on the Reuse Queue. In this example unused pages were used for new extensions. If new extensions are placed on a page from the Reuse Queue, <var>BQLEN</var> might decrease.</p>

	==Example: compacting extensions==		==Example: compacting extensions==

DCameron: /* Usage */

2019-02-11T12:47:13Z

Usage

← Older revision		Revision as of 12:47, 11 February 2019
Line 34:		Line 34:
	==Usage==		==Usage==
	<ul>		<ul>
	<li>The data compactor is a CPU- and I/O-intensive process, so do not compact data at your site during high load periods. To avoid monopolizing system resources, the data compactor checks for a <var>BUMP</var> command or for long request conditions at the following intervals:		<li>The data compactor is a CPU- and I/O-intensive process, so do not compact data at your site during high load periods. To avoid monopolizing system resources, the data compactor checks for a <var>[[BUMP_command\|BUMP]]</var> command or for long request conditions at the following intervals:
	<ul>		<ul>
	<li>When compacting files with Table X, the check for a bump or for long request conditions is done		<li>When compacting files with Table X, the check for a bump or for long request conditions is done

DCameron: /* Syntax */

2019-02-11T12:43:59Z

Syntax

← Older revision		Revision as of 12:43, 11 February 2019
Line 22:		Line 22:

	<ul>		<ul>
	<li>Table B: <code>((BSIZE - BHIGHPG) / BSIZE) * 100</code> </li>		<li>Table B: <code>((<var>[[BSIZE_parameter\|BSIZE]]</var> - <var>[[BHIGHPG_parameter\|BHIGHPG]]</var>) / BSIZE) * 100</code> </li>

	<li>Table X: <code>((XSIZE - XHIGHPG / XSIZE) * 100</code> </li>		<li>Table X: <code>((<var>[[XSIZE_parameter\|XSIZE]]</var> - <var>[[XHIGHPG_parameter\|XHIGHPG]]</var> / XSIZE) * 100</code> </li>
	</ul></li>		</ul></li>

DCameron: /* Syntax */

2019-02-11T12:41:01Z

Syntax

← Older revision		Revision as of 12:41, 11 February 2019
Line 19:		Line 19:
	<li><var>TO</var> <var class="term">eeee</var> indicates the ending logical record number where the compactor stops working.</li>		<li><var>TO</var> <var class="term">eeee</var> indicates the ending logical record number where the compactor stops working.</li>

	<li><var>FREE</var> <var class="term">nn</var> indicates the percentage of unused or free pages (Table B or Table X) that can be used by the data compactor for new extension records. The default is 10 percent. The percent of free pages is calculated as follows:		<li><var>FREE</var> <var class="term">nn</var> indicates the percentage of unused or free pages (Table B or [[Table_X_(File_architecture)\|Table X]]) that can be used by the data compactor for new extension records. The default is 10 percent. The percent of free pages is calculated as follows:

	<ul>		<ul>

DCameron: /* Syntax */

2019-02-11T12:35:13Z

Syntax

← Older revision		Revision as of 12:35, 11 February 2019
Line 15:		Line 15:
	Where: </p>		Where: </p>
	<ul>		<ul>
	<li><var>FROM</var> <var class="term">ssss</var> indicates the starting Table B page number where the compactor starts looking for extensions. The default is zero.</li>		<li><var>FROM</var> <var class="term">ssss</var> indicates the starting [[Table_B_(File_architecture)\|Table B]] page number where the compactor starts looking for extensions. The default is zero.</li>

	<li><var>TO</var> <var class="term">eeee</var> indicates the ending logical record number where the compactor stops working.</li>		<li><var>TO</var> <var class="term">eeee</var> indicates the ending logical record number where the compactor stops working.</li>

DCameron: /* Summary */

2019-02-11T12:33:52Z

Summary

← Older revision		Revision as of 12:33, 11 February 2019
Line 6:		Line 6:
	<dd>Combine as many [[Record_(File_architecture)#Extension_records\|extension records]] as possible into one extension record for the current or specified file.		<dd>Combine as many [[Record_(File_architecture)#Extension_records\|extension records]] as possible into one extension record for the current or specified file.
	<p class="note"><b>Note:</b>		<p class="note"><b>Note:</b>
	An automatic optimization occurs if a base record has only one extension record, and the combined base plus extension record will fit on the page currently occupied by the base record. In that case, the result of compaction is a single base record and the elimination of the extension.</p>		An automatic optimization occurs if a [[Record_(File_architecture)#Base_records\|base record]] has only one extension record, and the combined base plus extension record will fit on the page currently occupied by the base record. In that case, the result of compaction is a single base record and the elimination of the extension.</p>
	</dl>		</dl>

DCameron: /* Summary */

2019-02-11T12:25:57Z

Summary

← Older revision		Revision as of 12:25, 11 February 2019
Line 4:		Line 4:
	<dd>File Manager		<dd>File Manager
	<dt>Function		<dt>Function
	<dd>Combine as many extension records as possible into one extension record for the current or specified file.		<dd>Combine as many [[Record_(File_architecture)#Extension_records\|extension records]] as possible into one extension record for the current or specified file.
	<p class="note"><b>Note:</b>		<p class="note"><b>Note:</b>
	An automatic optimization occurs if a base record has only one extension record, and the combined base plus extension record will fit on the page currently occupied by the base record. In that case, the result of compaction is a single base record and the elimination of the extension.</p>		An automatic optimization occurs if a base record has only one extension record, and the combined base plus extension record will fit on the page currently occupied by the base record. In that case, the result of compaction is a single base record and the elimination of the extension.</p>

ELowell: /* Reviewing data compactor statistics */ - very minor formatting

2017-03-31T16:34:53Z

Reviewing data compactor statistics: - very minor formatting

← Older revision		Revision as of 16:34, 31 March 2017
Line 84:		Line 84:
	At the end of processing, the compactor prints the following statistics:</p>		At the end of processing, the compactor prints the following statistics:</p>
	<p class="code">M204.2749: NUMBER OF BASIC RECORDS PROCESSED: <var class="term">nnnn</var>		<p class="code">M204.2749: NUMBER OF BASIC RECORDS PROCESSED: <var class="term">nnnn</var>
	M204.2750: NUMBER OF EXTENSION RECORDS BEFORE COMPACTION: <var class="term">nnnn</var>		M204.2750: NUMBER OF EXTENSION RECORDS BEFORE COMPACTION: <var class="term">nnnn</var>
	M204.2751: NUMBER OF EXTENSION RECORDS AFTER COMPACTION: <var class="term">nnnn</var>		M204.2751: NUMBER OF EXTENSION RECORDS AFTER COMPACTION: <var class="term">nnnn</var>
	M204.2752: NUMBER OF NOT PROCESSED (LOCKED) RECORDS: <var class="term">nnnn</var>		M204.2752: NUMBER OF NOT PROCESSED (LOCKED) RECORDS: <var class="term">nnnn</var>

JAL: minor cleanup

2015-02-13T17:05:15Z

minor cleanup

← Older revision		Revision as of 17:05, 13 February 2015
Line 33:		Line 33:

	==Usage==		==Usage==
	<p>		<ul>
	The data compactor is a CPU- and I/O-intensive process, so do not compact data at your site during high load periods. To avoid monopolizing system resources, the data compactor checks for ~~bump~~ or long request conditions at the following intervals:~~</p>~~		<li>The data compactor is a CPU- and I/O-intensive process, so do not compact data at your site during high load periods. To avoid monopolizing system resources, the data compactor checks for a <var>BUMP</var> command or for long request conditions at the following intervals:
	<ul>		<ul>
	<li>		<li>When compacting files with Table X, the check for a bump or for long request conditions is done
	~~<p>~~		when one of the following milestones (whichever comes first) is reached:
	When compacting files with Table X, the check for bump or long request conditions is done ~~for every~~:~~</p>~~
	<ul>		<ul>
	<li>		<li>30 compacted records</li>
	<p>30 compacted records~~, or</p>~~
	</li>

	<li>		<li>30 processed Table B pages</li>
	<p>30 processed Table B pages~~, or</p>~~
	</li>

	<li>		<li>30 logically deleted records</li>
	<p>30 logically deleted records~~,</p>~~		After the check, the counter is reset and processing continues until the next time one of the milestones is reached; and so on.</ul></li>
	</li>
	</ul>
	~~whichever comes first.~~ </li>

	<li>		<li>When compacting files with no Table X, <var>COMPACTB</var> allows higher priority users to run at every 30 records read, whether the records are compacted or not. </li>
	<p>When compacting files with no Table X, <var>COMPACTB</var> allows higher priority users to run at every 30 records read, ~~regardless of~~ whether the records are compacted or not. </p>		</ul></li>
	</li>
	</ul>		<li>The data compactor commits at every record compacted.
	<p>
	The data compactor commits at every record compacted.~~</p>~~
	<p>		<p>
	If your system crashes, only one record compaction might be lost. Data is never lost. The worst that might happen when the system crashes is that after recovery processing, one record, and only one, would have either of these:</p>		If your system crashes, only one record compaction might be lost. Data is never lost. The worst that might happen when the system crashes is that after recovery processing, one record, and only one, would have either of these:</p>
Line 69:		Line 59:
	<p>		<p>
	You cannot reclaim space for orphaned chains without a file reorganization. There is no backout for the data compactor.</p>		You cannot reclaim space for orphaned chains without a file reorganization. There is no backout for the data compactor.</p>
	<p>		</li>
	The compactor takes preimages of all the pages it will change and writes a journal record, containing all compacted extensions for each compaction, which might require that you increase the checkpoint and journal data set sizes.</p>
	<p>		<li>The compactor takes preimages of all the pages it will change and writes a journal record, containing all compacted extensions for each compaction, which might require that you increase the checkpoint and journal data set sizes.</li>
	There is no restriction on record length or number of extension records for the data compactor, as long as there is enough free space on pages to hold the compacted records.</p>
	<p>		<li>There is no restriction on record length or number of extension records for the data compactor, as long as there is enough free space on pages to hold the compacted records.</li>
	The <var>COMPACTB</var> command maintains the same logical order (which is visible to programs) of extension records in the compacted records as in the original record. The physical order of extension records (that is, the order of the page numbers) might differ.</p>
			<li>The <var>COMPACTB</var> command maintains the same logical order (which is visible to programs) of extension records in the compacted records as in the original record. The physical order of extension records (that is, the order of the page numbers) might differ.</li>
			</ul>

	====Setting the DELETE argument====		====Setting the DELETE argument====

JAL: more conversion cleanup

2015-02-13T16:00:39Z

more conversion cleanup

Show changes