Deferred update feature - Revision history

Ekern: /* Deferred updates and large (FILEORG X'200') files */

2022-03-18T18:45:41Z

Deferred updates and large (FILEORG X'200') files

← Older revision		Revision as of 18:45, 18 March 2022
Line 13:		Line 13:

	===<b id="defUpdtX200"></b>Deferred updates and large (FILEORG X'200') files===		===<b id="defUpdtX200"></b>Deferred updates and large (FILEORG X'200') files===
	<p>The <var>[[FILEORG parameter\|FILEORG]]</var> parameter X'200' setting supports large files, allowing files to hold up to 48M records.</p>		<p>The <var>[[FILEORG parameter\|FILEORG]]</var> parameter X'200' setting supports large files, allowing files to hold up to <var>[[FILEORG parameter#large_files\|48M records]]</var>.</p>
	<p>		<p>
	The deferred index update feature was implemented well before the existence of <var>FILEORG</var> X'200' files, when the maximum number of records possible in a file was 16M. At that time, only three bytes were required to represent record numbers up to 16M - 1, so the format of the deferred index update records optimized record numbers to three bytes. However, if using <var>FILEORG</var> X'200' files, an extra byte is required to represent the record numbers for deferred index updates.		The deferred index update feature was implemented well before the existence of <var>FILEORG</var> X'200' files, when the maximum number of records possible in a file was 16M. At that time, only three bytes were required to represent record numbers up to 16M - 1, so the format of the deferred index update records optimized record numbers to three bytes. However, if using <var>FILEORG</var> X'200' files, an extra byte is required to represent the record numbers for deferred index updates.

Dme: /* Deferred updates and large (FILEORG X'200') files */

2017-07-06T23:30:13Z

Deferred updates and large (FILEORG X'200') files

← Older revision		Revision as of 23:30, 6 July 2017
Line 12:		Line 12:
	When a file is opened in deferred update mode, <var class="product">Model 204</var> protects the file by making it impossible to free the file in that <var class="product">Model 204</var> run. This limitation is necessary to protect the file from being updated before the deferred updates have been applied. All files are closed completely (free) at the end of the <var class="product">Model 204</var> job.</p>		When a file is opened in deferred update mode, <var class="product">Model 204</var> protects the file by making it impossible to free the file in that <var class="product">Model 204</var> run. This limitation is necessary to protect the file from being updated before the deferred updates have been applied. All files are closed completely (free) at the end of the <var class="product">Model 204</var> job.</p>

	===Deferred updates and large (FILEORG X'200') files===		===<b id="defUpdtX200"></b>Deferred updates and large (FILEORG X'200') files===
	<p>The <var>[[FILEORG parameter\|FILEORG]]</var> parameter X'200' setting supports large files, allowing files to hold up to 48M records.</p>		<p>The <var>[[FILEORG parameter\|FILEORG]]</var> parameter X'200' setting supports large files, allowing files to hold up to 48M records.</p>
	<p>		<p>

JAL: misc formatting

2017-03-14T22:32:37Z

misc formatting

Show changes

JAL: misc formatting

2017-03-14T19:40:03Z

misc formatting

← Older revision		Revision as of 19:40, 14 March 2017
Line 200:		Line 200:
	===Deferring updates to ORDERED fields===		===Deferring updates to ORDERED fields===
	<p>		<p>
	When the updates to ORDERED fields are deferred to the variable-length data set, the space requirements for the variable-length deferred update data set are one record for each occurrence of an ORDERED field that is added or deleted of a length equal to:</p>		When the updates to <var>ORDERED</var> fields are deferred to the variable-length data set, the space requirements for the variable-length deferred update data set are one record for each occurrence of an <var>ORDERED</var> field that is added or deleted of a length equal to the following is written to the data set:</p>
	<p class="code">15 + the length of the ORDERED field value being added or deleted ~~is written to the data set~~		<p class="code">15 + the length of the ORDERED field value being added or deleted</p>
	</p>		<p class="note"><b>Note:</b> The length of an <var>ORDERED NUMERIC</var> deferred numeric value is always 8. The numeric values of an <var>ORDERED NUMERIC</var> field are always stored as <code>FLOAT 8</code> numbers in the Ordered Index, even if the numbers are stored as <code>FLOAT 16</code> in Table B. The length of an <var>ORDERED NUMERIC</var> deferred non-numeric value is the length of the value.</p>
	<p class="note"><b>Note:</b> The length of an ORDERED NUMERIC deferred numeric value is always 8. The numeric values of an ORDERED NUMERIC field are always stored as FLOAT 8 numbers in the Ordered Index, even if the numbers are stored as FLOAT 16 in Table B. The length of an ORDERED NUMERIC deferred non-numeric value is the length of the value.</p>
	<p>		<p>
	A changed field writes two records: one record to delete the old value and one record to add the new value. </p>		A changed field writes two records: one record to delete the old value, and one record to add the new value. </p>

	===Deferring updates to KEY and NUMERIC fields===		===Deferring updates to KEY and NUMERIC fields===
	<p>		<p>
	When the updates to KEY and NUMERIC ~~range~~ fields, as well as ORDERED fields, are deferred to the variable-length data set, the additional space required in the variable-length deferred update data set is as follows:</p>		When the updates to <var>KEY</var> and <var>NUMERIC RANGE</var> fields, as well as <var>ORDERED</var> fields, are deferred to the variable-length data set, the additional space required in the variable-length deferred update data set is as follows:</p>
	<table style="width:80%">		<table style="width:80%">
	<tr class="head">		<tr class="head">

JAL: misc formatting

2017-03-14T00:13:55Z

misc formatting

← Older revision		Revision as of 00:13, 14 March 2017
Line 156:		Line 156:
	</p>		</p>
	<p>		<p>
	For fixed-length deferred update CMS files, the FILEDEF statement must specify "BLOCK 24" for files stored on disk. This results in a blocking factor of one and prevents errors from occurring during checkpointing. </p>		For fixed-length deferred update CMS files, the FILEDEF statement must specify <code>BLOCK 24</code> for files stored on disk. This results in a blocking factor of one, and it prevents errors from occurring during checkpointing. </p>
	<p>		<p>
	For FILEORG X'200' files the LRECL should be 25 and, in fact, ~~defaults to~~ that. ~~By a happy coincidence the~~ default BLKSIZE works for both FILEORG X'200' and non-FILEORG X'200' files ~~and~~ so is used for both. So to eliminate worries about jobs working on files ~~either~~ with or without FILEORG X'200', the best approach is to not specify ~~the~~ LRECL and BLKSIZE ~~and allow it~~ to default.		For <var>FILEORG</var> X'200' files, the LRECL should be 25 and, in fact, that is the default. The default BLKSIZE works for both <var>FILEORG</var> X'200' and non-<var>FILEORG</var> X'200' files, so it is used for both. Therefore, to eliminate worries about jobs working on files with or without <var>FILEORG</var> X'200', the best approach is to <i>not</i> specify LRECL and BLKSIZE, allowing them to default.
	</p>		</p>

Line 178:		Line 178:
	===DCB parameters for variable-length data sets===		===DCB parameters for variable-length data sets===
	<p>		<p>
	The default DCB parameters for the variable-length data sets are: </p>		The default DCB parameters for the variable-length data sets for non-<var>FILEORG</var> X'200' files are: </p>
	<p class="code">RECFM=VB .		<p class="code">RECFM=VB .
	LRECL=270 BLKSIZE=6000 .		LRECL=270 BLKSIZE=6000 .
	</p>		</p>
	~~for non-~~FILEORG X'200' files ~~and~~		For <var>FILEORG</var> X'200' files, the parameters are:
	<p class="code">RECFM=VB .		<p class="code">RECFM=VB .
	LRECL=271 BLKSIZE=6000 .		LRECL=271 BLKSIZE=6000 .
	</p>		</p>
	~~for FILEORG X'200' files.~~
	<p>		<p>
	For z/VSE, set the BLKSIZE parameter with the DEFINE DATASET command. </p>		For z/VSE, set the BLKSIZE parameter with the <var>DEFINE DATASET</var> command. </p>
	<p>		<p>
	You can override the BLKSIZE on the data set or file definition statement. If enough space is available, set BLKSIZE to a full track for most efficient processing. See the description of SPCORE on [[#Setting the SPCORE parameter\|Setting the SPCORE parameter]]. </p>		You can override the BLKSIZE on the data set or file definition statement. If enough space is available, set BLKSIZE to a full track for most efficient processing. See the description of <var>SPCORE</var> on [[#Setting the SPCORE parameter\|Setting the SPCORE parameter]]. </p>
	<p>		<p>
	The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files. If using a mix of FILEORG X'200' and non-FILEORG X'200' files the best strategy is to either not explicitly specify LRECL ~~and so let~~ it default~~, or to specify~~ LRECL 271, which will work for both FILEORG X'200' and non-FILEORG X'200' files.</p>		The length of the variable deferred index update entries is 270 for non-<var>FILEORG</var> X'200' files, and it is 271 for <var>FILEORG</var> X'200' files. If using a mix of <var>FILEORG</var> X'200' and non-<var>FILEORG</var> X'200' files, the best strategy is either of these: </p>
			<ul>
			<li>Do not explicitly specify LRECL, letting it default.</li>

			<li>Specify <code>LRECL 271</code>, which will work for both <var>FILEORG</var> X'200' and non-<var>FILEORG</var> X'200' files.</li>
			</ul>

	===Deferring updates to ORDERED fields===		===Deferring updates to ORDERED fields===
Line 199:		Line 203:
	<p class="code">15 + the length of the ORDERED field value being added or deleted is written to the data set		<p class="code">15 + the length of the ORDERED field value being added or deleted is written to the data set
	</p>		</p>
	<p class="note"><b>Note:</b> The length of an ORDERED NUMERIC deferred numeric value is always 8. The numeric values of an ORDERED NUMERIC field are always stored as FLOAT 8 numbers in the Ordered Index, even if the numbers are stored as FLOAT 16 in Table B. The length of an ORDERED NUMERIC deferred ~~nonnumeric~~ value is the length of the value.</p>		<p class="note"><b>Note:</b> The length of an ORDERED NUMERIC deferred numeric value is always 8. The numeric values of an ORDERED NUMERIC field are always stored as FLOAT 8 numbers in the Ordered Index, even if the numbers are stored as FLOAT 16 in Table B. The length of an ORDERED NUMERIC deferred non-numeric value is the length of the value.</p>
	<p>		<p>
	A changed field writes two records: one record to delete the old value and one record to add the new value. </p>		A changed field writes two records: one record to delete the old value and one record to add the new value. </p>

JAL: misc formatting

2017-03-13T23:22:55Z

misc formatting

JAL: /* Sorting the variable-length deferred update data set */ misc formatting

2017-03-13T22:20:03Z

Sorting the variable-length deferred update data set: misc formatting

ELowell at 17:02, 13 March 2017

2017-03-13T17:02:35Z

← Older revision		Revision as of 17:02, 13 March 2017
Line 191:		Line 191:
	You can override the BLKSIZE on the data set or file definition statement. If enough space is available, set BLKSIZE to a full track for most efficient processing. See the description of SPCORE on [[#Setting the SPCORE parameter\|Setting the SPCORE parameter]]. </p>		You can override the BLKSIZE on the data set or file definition statement. If enough space is available, set BLKSIZE to a full track for most efficient processing. See the description of SPCORE on [[#Setting the SPCORE parameter\|Setting the SPCORE parameter]]. </p>
	<p>		<p>
	The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files. If using a mix of FILEORG X'200' and non-FILEORG X'200' files the best strategy is to either not explicitly specify LRECL and so let it default, or to specify LRECL 271 which will work for both FILEORG X'200' and non-FILEORG X'200' files.</p>		The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files. If using a mix of FILEORG X'200' and non-FILEORG X'200' files the best strategy is to either not explicitly specify LRECL and so let it default, or to specify LRECL 271, which will work for both FILEORG X'200' and non-FILEORG X'200' files.</p>

	===Deferring updates to ORDERED fields===		===Deferring updates to ORDERED fields===
Line 329:		Line 329:
	==Sorting the fixed-length deferred update data set==		==Sorting the fixed-length deferred update data set==
	<p>		<p>
	If you use a fixed-length deferred update data set, it must be sorted by some job step after the first phase step. For non-FILEORG X'200' files, the fixed-length records are 24 bytes long and must be sorted in ascending order by the first 16 bytes using the standard EBCDIC collating sequence. For FILEORG X'200' files, the fixed-length records are 25 bytes long and must be sorted in ascending order by the first 17 bytes using the standard EBCDIC collating sequence.</p>		If you use a fixed-length deferred update data set, it must be sorted by some job step after the first phase step.</p>
			<ul>
			<li>For non-FILEORG X'200' files, the fixed-length records are 24 bytes long and must be sorted in ascending order by the first 16 bytes using the standard EBCDIC collating sequence.</li>
			<li>For FILEORG X'200' files, the fixed-length records are 25 bytes long and must be sorted in ascending order by the first 17 bytes using the standard EBCDIC collating sequence.</li>
			</ul>
	<p>		<p>
	Any sort utility can be used to perform the sort of the fixed-length deferred update data set under z/OS, z/VSE, or z/VM. The basic JCL for the IBM SORT Utility is described in the following paragraphs. Refer to the appropriate IBM manual for additional information. </p>		Any sort utility can be used to perform the sort of the fixed-length deferred update data set under z/OS, z/VSE, or z/VM. The basic JCL for the IBM SORT Utility is described in the following paragraphs. Refer to the appropriate IBM manual for additional information. </p>
Line 358:		Line 362:
	<p class="code">SORT FIELDS=(1,17,CH,A)		<p class="code">SORT FIELDS=(1,17,CH,A)
	</p>		</p>
	for FILEORG X'200' files. Note that the FILEORG X'200' file SORT FIELD statement works OK for non-FILEORG X'200' files ~~too~~.		for FILEORG X'200' files. Note that the FILEORG X'200' file SORT FIELD statement also works for non-FILEORG X'200' files.
	<p>		<p>
	The effect of this statement is to sort the records in ascending order by the first 16 bytes. </p>		The effect of this statement is to sort the records in ascending order by the first 16 bytes. </p>
Line 566:		Line 570:
	</p>		</p>
	for non-FILEORG X'200' files and		for non-FILEORG X'200' files and
	~~Use the following DCB subparameters:~~
	<p class="code">RECFM=VB		<p class="code">RECFM=VB
	LRECL=271 BLKSIZE=27975 (1/2 track on a 3390 disk)		LRECL=271 BLKSIZE=27975 (1/2 track on a 3390 disk)
	</p>		</p>
	for FILEORG X'200' ~~file~~. Or better still, don't specify the DCB subparameters and let them default.		for FILEORG X'200' files. Or better still, don't specify the DCB subparameters and let them default.
	<p>		<p>
	In z/VSE, specify the physical record format for the SORTIN data set using the SORT program's RECORD statement. </p>		In z/VSE, specify the physical record format for the SORTIN data set using the SORT program's RECORD statement. </p>
Line 601:		Line 604:
	<li><var class="term">aa</var> is the sort field length, the value of (<var class="term">vl</var> - 5). It represents the length of the entire data portion of the expanded sort record.</li>		<li><var class="term">aa</var> is the sort field length, the value of (<var class="term">vl</var> - 5). It represents the length of the entire data portion of the expanded sort record.</li>

	<li><var class="term">vl</var> is a length parameter. See [[#Setting the variable-length sort parameter (vl)\|Setting the variable-length sort parameter (vl)]]. The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files but 271 can be used for either.</li>		<li><var class="term">vl</var> is a length parameter. See [[#Setting the variable-length sort parameter (vl)\|Setting the variable-length sort parameter (vl)]]. The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files, but 271 can be used for either.</li>

	<li><var class="term">xxx</var> is OS for z/OS or CMS for z/VM, depending on the operating system.</li>		<li><var class="term">xxx</var> is OS for z/OS or CMS for z/VM, depending on the operating system.</li>

Alex: /* SORT control statements */

2017-03-11T00:48:18Z

SORT control statements

← Older revision		Revision as of 00:48, 11 March 2017
Line 592:		Line 592:
	<b>Syntax for z/OS and z/VM</b>		<b>Syntax for z/OS and z/VM</b>
	<p class="syntax">SORT FIELDS=(5,<span class="term">aa</span>,CH,A)		<p class="syntax">SORT FIELDS=(5,<span class="term">aa</span>,CH,A)
	RECORD TYPE=V,LENGTH=(~~270~~,<span class="term">vl</span>,~~270~~,<span class="term">vl</span>)		RECORD TYPE=V,LENGTH=(271,<span class="term">vl</span>,271,<span class="term">vl</span>)
	MODS E15=(OI15<span class="term">xxx</span>,1800),E35=(OI35<span class="term">xxx</span>,1300)		MODS E15=(OI15<span class="term">xxx</span>,1800),E35=(OI35<span class="term">xxx</span>,1300)
	END		END
Line 601:		Line 601:
	<li><var class="term">aa</var> is the sort field length, the value of (<var class="term">vl</var> - 5). It represents the length of the entire data portion of the expanded sort record.</li>		<li><var class="term">aa</var> is the sort field length, the value of (<var class="term">vl</var> - 5). It represents the length of the entire data portion of the expanded sort record.</li>

	<li><var class="term">vl</var> is a length parameter. See [[#Setting the variable-length sort parameter (vl)\|Setting the variable-length sort parameter (vl)]]. The length of the variable deferred index update entries is 270.</li>		<li><var class="term">vl</var> is a length parameter. See [[#Setting the variable-length sort parameter (vl)\|Setting the variable-length sort parameter (vl)]]. The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files but 271 can be used for either.</li>

	<li><var class="term">xxx</var> is OS for z/OS or CMS for z/VM, depending on the operating system.</li>		<li><var class="term">xxx</var> is OS for z/OS or CMS for z/VM, depending on the operating system.</li>
Line 610:		Line 610:
	<b>Syntax for z/VSE</b>		<b>Syntax for z/VSE</b>
	<p class="syntax">SORT FIELDS=(5,<span class="term">aa</span>,CH,A)		<p class="syntax">SORT FIELDS=(5,<span class="term">aa</span>,CH,A)
	RECORD TYPE=V,LENGTH=(~~270~~,<span class="term">vl</span>,~~270~~,<span class="term">vl</span>)		RECORD TYPE=V,LENGTH=(271,<span class="term">vl</span>,271,<span class="term">vl</span>)
	MODS PH1=(OI15,1800),PH3=(OI35,1300)		MODS PH1=(OI15,1800),PH3=(OI35,1300)
	END		END

Alex: /* Required sort JCL and EXEC statements */

2017-03-11T00:45:50Z

Required sort JCL and EXEC statements

← Older revision		Revision as of 00:45, 11 March 2017
Line 565:		Line 565:
	LRECL=270 BLKSIZE=27998 (1/2 track on a 3390 disk)		LRECL=270 BLKSIZE=27998 (1/2 track on a 3390 disk)
	</p>		</p>
			for non-FILEORG X'200' files and
			Use the following DCB subparameters:
			<p class="code">RECFM=VB
			LRECL=271 BLKSIZE=27975 (1/2 track on a 3390 disk)
			</p>
			for FILEORG X'200' file. Or better still, don't specify the DCB subparameters and let them default.
	<p>		<p>
	In z/VSE, specify the physical record format for the SORTIN data set using the SORT program's RECORD statement. </p>		In z/VSE, specify the physical record format for the SORTIN data set using the SORT program's RECORD statement. </p>

← Older revision		Revision as of 23:22, 13 March 2017
Line 13:		Line 13:

	===Deferred updates and large (FILEORG X'200') files===		===Deferred updates and large (FILEORG X'200') files===
	<p>The [[FILEORG parameter\|FILEORG X'200']] setting supports large files, allowing files to hold up to 48M records.</p>		<p>The <var>[[FILEORG parameter\|FILEORG]]</var> parameter X'200' setting supports large files, allowing files to hold up to 48M records.</p>
	<p>		<p>
	The deferred index update feature was implemented well before the existence of FILEORG X'200' files, when the maximum number of records possible in a file was 16M. At that time, only three bytes were required to represent record numbers up to 16M - 1, so the format of the deferred index update records optimized record numbers to three bytes. However, ~~when~~ using FILEORG X'200' files, an extra byte is required to represent the record numbers in deferred index updates.		The deferred index update feature was implemented well before the existence of <var>FILEORG</var> X'200' files, when the maximum number of records possible in a file was 16M. At that time, only three bytes were required to represent record numbers up to 16M - 1, so the format of the deferred index update records optimized record numbers to three bytes. However, if using <var>FILEORG</var> X'200' files, an extra byte is required to represent the record numbers for deferred index updates.
	</p>		</p>
	<p>		<p>
	This means that when converting a file to FILEORG X'200', you might need to modify reorg jobs to ~~accomodate~~ the longer record numbers. ~~On the plus side~~, most ~~of the~~ changes should work with non-FILEORG X'200' files if common infrastructure is used for files that are a mix of FILEORG X'200' and non-FILEORG X'200'. The rest of this page indicates where values need to be ~~tweaked~~ for FILEORG X'200' files.		This means that when converting a file to <var>FILEORG</var> X'200', you might need to modify reorg jobs to accommodate the longer record numbers. Fortunately, most such changes should work with non-<var>FILEORG</var> X'200' files if common infrastructure is used for files that are a mix of <var>FILEORG</var> X'200' and non-<var>FILEORG</var> X'200'. The rest of this page indicates where values need to be adjusted for <var>FILEORG</var> X'200' files.
	</p>		</p>

Line 31:		Line 31:
	===First phase of deferred update===		===First phase of deferred update===
	<p>		<p>
	The first phase of the deferred update process involves executing whatever configuration of <var class="product">Model 204</var> would be run if updates to the index were not being deferred: BATCH204, ONLINE, IFAM1, or IFAM4. Storing new records or changing existing records proceeds normally until the <var class="product">Model 204</var> file is put into deferred update mode by a special form of the OPEN command or the IFOPEN call. Thereafter, only Table A, the internal file dictionary, and Table B, the VISIBLE data, of the file are updated. </p>		The first phase of the deferred update process involves executing whatever configuration of <var class="product">Model 204</var> would be run if updates to the index were not being deferred: BATCH204, ONLINE, IFAM1, or IFAM4. Storing new records or changing existing records proceeds normally until the <var class="product">Model 204</var> file is put into deferred update mode by a special form of the <var>OPEN</var> command or the <var>IFOPEN</var> call. Thereafter, only Table A, the internal file dictionary, and Table B, the <var>VISIBLE</var> data, of the file are updated. </p>
	<p>		<p>
	The index information pertaining to FOR EACH VALUE (FRV), KEY, NUMERIC RANGE, and ORDERED retrieval fields is not added directly to Table C and Table D. Instead, it is written to one or two deferred update data sets for processing in later job steps. </p>		The index information pertaining to <var>FOR EACH VALUE</var> (<var>FRV</var>), <var>KEY</var>, <var>NUMERIC RANGE</var>, and <var>ORDERED</var> retrieval fields is not added directly to Table C and Table D. Instead, it is written to one or two deferred update data sets for processing in later job steps. </p>
	<p class="note"><b>Note:</b> The index update generated by a ~~FILE RECORDS UNDER~~ statement is never deferred.</p>		<p class="note"><b>Note:</b> The index update generated by a <var>File Records Under</var> statement is never deferred.</p>

	====Query results between deferred update phases====		====Query results between deferred update phases====
	<p>		<p>
	For example, suppose that you add the field name = value pair NAME = MURRAY to an existing record in file PEOPLE. PEOPLE is in deferred update mode, and the NAME field is KEY and VISIBLE. If the record is retrieved by some other (preexisting) KEY field, a ~~PRINT~~ NAME statement prints MURRAY, because the field is VISIBLE and is, therefore, stored in Table B. However, the statement FIND ALL RECORDS FOR WHICH NAME = MURRAY does not find the record, because the index information NAME = MURRAY has not yet been added to Tables C and D. </p>		For example, suppose that you add the field name = value pair <code>NAME=MURRAY</code> to an existing record in file <code>PEOPLE</code>. <code>PEOPLE</code> is in deferred update mode, and the <code>NAME</code> field is <var>KEY</var> and <var>VISIBLE</var>. </p>
			<p>
			If the record is retrieved by some other (preexisting) <var>KEY</var> field, a <code>Print NAME</code> statement prints <code>MURRAY</code>, because the field is <var>VISIBLE</var> and is, therefore, stored in Table B. However, the statement <code>FIND ALL RECORDS FOR WHICH NAME = MURRAY</code> does not find the record, because the index information <code>NAME=MURRAY</code> has not yet been added to Tables C and D. </p>

	===Second phase of deferred update===		===Second phase of deferred update===
Line 44:		Line 46:
	The second phase of the deferred update process is executed only after the first phase of deferred update process is complete. The second phase of the deferred update process sorts each of the deferred update data sets created in the first phase, then applies the updates to Tables C and D.</p>		The second phase of the deferred update process is executed only after the first phase of deferred update process is complete. The second phase of the deferred update process sorts each of the deferred update data sets created in the first phase, then applies the updates to Tables C and D.</p>
	<p>		<p>
	Applying the sorted updates from the deferred update data sets adds the information necessary to perform retrievals based on the new KEY, NUMERIC RANGE, and ORDERED retrieval field values. For instance, after applying the deferred updates, the retrieval statement FIND ALL RECORDS FOR WHICH NAME = MURRAY finds the record in the previous example. </p>		Applying the sorted updates from the deferred update data sets adds the information necessary to perform retrievals based on the new <var>KEY</var>, <var>NUMERIC RANGE</var>, and <var>ORDERED</var> retrieval field values. For instance, after applying the deferred updates, the retrieval statement <code>FIND ALL RECORDS FOR WHICH NAME = MURRAY</code> finds the record in the previous example. </p>

	====Additional job steps in a deferred update====		====Additional job steps in a deferred update====
	<p>		<p>
	If the file contains FRV (FOR EACH VALUE) fields, applying the deferred index updates to Tables C and D generates an additional deferred update data set. This additional deferred update data set contains more deferred index updates for fields with the FRV ~~(for-each-value)~~ attribute, which must also be sorted, and the sorted deferred updates applied to Tables C and D. </p>		If the file contains <var>FRV</var> (<var>FOR EACH VALUE</var>) fields, applying the deferred index updates to Tables C and D generates an additional deferred update data set. This additional deferred update data set contains more deferred index updates for fields with the <var>FRV</var> attribute, which must also be sorted, and the sorted deferred updates applied to Tables C and D. </p>
	<p>		<p>
	For example, suppose that the NAME field described previously also has the FRV attribute and that MURRAY is a new value of NAME that has never occurred in any record. The statement ~~FOR EACH VALUE OF~~ NAME does not find the value MURRAY until certain information is added to Tables C and D. This information is contained in the additional deferred update data set.</p>		For example, suppose that the <code>NAME</code> field described previously also has the <var>FRV</var> attribute and that <code>MURRAY</code> is a new value of <code>NAME</code> that has never occurred in any record. The statement <code>For Each Value of NAME</code> does not find the value <code>MURRAY</code> until certain information is added to Tables C and D. This information is contained in the additional deferred update data set.</p>
	<p>		<p>
	The procedure for deferring updates to the index normally requires multiple job steps instead of the one job step required if the updates are not deferred. The deferred update feature can use three, five, or seven job steps, depending on the attributes of the fields being deferred and the number of deferred update data sets specified on the OPEN command or the IFOPEN call. The specific job steps required for deferred update processing are described in detail in the section [[#Job steps\|Job steps]]. </p>		The procedure for deferring updates to the index normally requires multiple job steps instead of the one job step required if the updates are not deferred. The deferred update feature can use three, five, or seven job steps, depending on the attributes of the fields being deferred and the number of deferred update data sets specified on the <var>OPEN</var> command or the <var>IFOPEN</var> call. The specific job steps required for deferred update processing are described in detail in the section [[#Job steps\|Job steps]]. </p>

	==Opening deferred update files==		==Opening deferred update files==
Line 62:		Line 64:
	===Deferred update OPEN syntax===		===Deferred update OPEN syntax===
	<p>		<p>
	The <var>OPEN</var> command and the <var>IFOPEN</var> [[~~Media:M204 HLIReference V75.pdf~~\|Host Language Interface]] function have special forms that place the file being opened into deferred update mode. In these forms, you can specify one or two deferred update data sets. </p>		The <var>OPEN</var> command and the <var>IFOPEN</var> [[Host Language Interface (HLI)\|Host Language Interface]] function have special forms that place the file being opened into deferred update mode. In these forms, you can specify one or two deferred update data sets. </p>
	~~<b>Syntax</b~~>
	<p>		<p>
	The <var>OPEN</var> command syntax in this case is: </p>		The <var>OPEN</var> command syntax in this case is: </p>
Line 74:		Line 75:
	<li><var class="term">filename</var> is the name of the <var class="product">Model 204</var> file to be opened.</li>		<li><var class="term">filename</var> is the name of the <var class="product">Model 204</var> file to be opened.</li>

	<li><var class="term">dsname1</var> is the name of the fixed-length deferred update data set. If <var class="term">dsname1</var> is supplied in the OPEN command, deferred updates to KEY and NUMERIC RANGE fields are written to this data set.</li>		<li><var class="term">dsname1</var> is the name of the fixed-length deferred update data set. If <var class="term">dsname1</var> is supplied in the <var>OPEN</var> command, deferred updates to <var>KEY</var> and <var>NUMERIC RANGE</var> fields are written to this data set.</li>

	<li><var class="term">dsname2</var> is the name of the variable-length deferred update data set. If <i>dsname2</i> is supplied in the OPEN command, deferred updates to ORDERED fields are written to this data set. If only <var class="term">dsname2</var> is supplied in the OPEN command, all index updates are written to this data set. If <var class="term">dsname2</var> is not supplied in the OPEN command, updates to ORDERED fields are not deferred. </li>		<li><var class="term">dsname2</var> is the name of the variable-length deferred update data set. If <var class="term">dsname2</var> is supplied in the <var>OPEN</var> command, deferred updates to <var>ORDERED</var> fields are written to this data set. If only <var class="term">dsname2</var> is supplied in the <var>OPEN</var> command, all index updates are written to this data set. If <var class="term">dsname2</var> is not supplied in the <var>OPEN</var> command, updates to <var>ORDERED</var> fields are not deferred. </li>
	</ul>		</ul>

	<b>Naming conventions</b>		<b>Naming conventions</b>
	<p>		<p>
	A deferred update data set must have a name starting with the letters TAPE. It can be placed on ~~either~~ magnetic tape or a direct access device.</p>		A deferred update data set must have a name starting with the letters <code>TAPE</code>. It can be placed on magnetic tape or a direct access device.</p>
	<p>		<p>
	For example:</p>		For example:</p>

← Older revision		Revision as of 22:20, 13 March 2017
Line 545:		Line 545:
	===Variable-length sort keys===		===Variable-length sort keys===
	<p>		<p>
	When you use a variable-length deferred update data set, it must be sorted by a job step after the deferred data set first phase. The variable-length records can vary in length from 16 to 270 and must be sorted into ascending order. Unlike fixed-length deferred update records, which contain a fixed-length sort key, variable-length deferred update records for ORDERED fields contain a variable-length sort key. </p>		When you use a variable-length deferred update data set, it must be sorted by a job step after the deferred data set first phase. The variable-length records can vary in length from 16 to 270 (or 271, for <var>FILEORG</var> X'200' files), and they must be sorted into ascending order. Unlike fixed-length deferred update records, which contain a fixed-length sort key, variable-length deferred update records for <var>ORDERED</var> fields contain a variable-length sort key. </p>
	<p>		<p>
	Because no standard sort program supports variable-length sort keys, two sort exits are provided to transform the variable-length sort keys into fixed-length sort keys. Transforming variable-length sort keys is done in the E15 sort exit. The E15 sort exit expands variable-length ORDERED deferred update records into fixed-length records. </p>		Because no standard sort program supports variable-length sort keys, two sort exits are provided to transform the variable-length sort keys into fixed-length sort keys. Transforming variable-length sort keys is done in the E15 sort exit. The E15 sort exit expands variable-length <var>ORDERED</var> deferred update records into fixed-length records. </p>
	<p>		<p>
	This process produces longer sort records, which can increase the time and resources required to produce sorted output. Because sorting performance is quite sensitive to record length, be sure to set the expanded length as part of setting up ~~sort control statements (see~~ [[#SORT control statements\|SORT control statements]]).</p>		This process produces longer sort records, which can increase the time and resources required to produce sorted output. Because sorting performance is quite sensitive to record length, be sure to set the expanded length as part of setting up [[#SORT control statements\|SORT control statements]].</p>

	===Sort utilities===		===Sort utilities===
	<p>		<p>
	Any sort utility that supports sorting variable-length records and the use of the E15 and E35 sort exits can be used to perform the sort. The basic JCL for the IBM SORT Utility is described in the following paragraphs. Refer to the appropriate sort utility manual for additional information. </p>		Any sort utility that supports sorting variable-length records and the use of the E15 and E35 sort exits can be used to perform the sort. The basic JCL for the IBM SORT Utility is described in the following paragraphs. Refer to the appropriate sort utility manual for additional information. </p>
	<p>		<p>
	The z/VM SORT command cannot be used, because it cannot accommodate sort exits. </p>		The z/VM <code>SORT</code> command cannot be used, because it cannot accommodate sort exits. </p>

	===Required sort JCL and EXEC statements===		===Required sort JCL and EXEC statements===
Line 561:		Line 561:
	When writing JCL or z/VM EXECs for sorting, use the following statements:</p>		When writing JCL or z/VM EXECs for sorting, use the following statements:</p>
	<ul>		<ul>
	<li>SORTIN is the variable-length deferred update data set.</li>		<li><code>SORTIN</code> is the variable-length deferred update data set.</li>

	<li>Specify the SORTOUT DCB parameters as shown in the first phase step on [[#DCB parameters for variable-length data sets\|DCB parameters for variable-length data sets]]. In z/OS and z/VM, set DCB subparameters explicitly. </li>		<li>Specify the <code>SORTOUT</code> DCB parameters as shown in the first phase step on [[#DCB parameters for variable-length data sets\|DCB parameters for variable-length data sets]]. In z/OS and z/VM, set DCB subparameters explicitly. </li>

	<li>Use the following DCB subparameters:		<li>Use the following DCB subparameters for non-FILEORG X'200' files:
	<p class="code">RECFM=VB		<p class="code">RECFM=VB
	LRECL=270 BLKSIZE=27998 (1/2 track on a 3390 disk)		LRECL=270 BLKSIZE=27998 (1/2 track on a 3390 disk)
	</p>		</p>
	for ~~non-~~FILEORG X'200' files ~~and~~		Use the following for <var>FILEORG</var> X'200' files:
	<p class="code">RECFM=VB		<p class="code">RECFM=VB
	LRECL=271 BLKSIZE=27975 (1/2 track on a 3390 disk)		LRECL=271 BLKSIZE=27975 (1/2 track on a 3390 disk)
	</p>		</p>
	~~for FILEORG X'200' files.~~ Or better still, don't specify the DCB subparameters and let them default.		Or better still, don't specify the DCB subparameters and let them default.
	<p>		<p>
	In z/VSE, specify the physical record format for the SORTIN data set using the SORT program's RECORD statement. </p>		In z/VSE, specify the physical record format for the <code>SORTIN</code> data set using the SORT program's RECORD statement. </p>
	</li>		</li>

	<li>Specify CCAPRINT (SYSLST in z/VSE) in the step that sorts the variable-length deferred update data set. CCAPRINT is the <var class="term">ddname</var>, FILEDEF, or DLBL that points to the sort error message output data set. </li>		<li>Specify <code>CCAPRINT</code> (<code>SYSLST</code> in z/VSE) in the step that sorts the variable-length deferred update data set. <code>CCAPRINT</code> is the <var class="term">ddname</var>, FILEDEF, or DLBL that points to the sort error message output data set. </li>

	<li>Specify CCAIN in the step that sorts the variable-length deferred update data set. CCAIN must contain the sort control statements. SYSIN and CCAIN must point to copies of the same sort control statements.		<li>Specify <code>CCAIN</code> in the step that sorts the variable-length deferred update data set. CCAIN must contain the sort control statements. SYSIN and CCAIN must point to copies of the same sort control statements.
	<p>		<p>
	In z/VSE, the CCAIN DLBL is not needed when sorting the variable-length deferred update data set.</p>		In z/VSE, the CCAIN DLBL is not needed when sorting the variable-length deferred update data set.</p>
	</li>		</li>

	<li>CCAEXITS, the <var class="term">ddname</var> of the library containing the sort exits, is used only in the z/OS environment. For information on installing the sort exits, see ~~the Rocket <var>~~Model~~ ~~204 installation ~~guide<~~/~~var> for your operating system~~.</li>		<li><code>CCAEXITS</code>, the <var class="term">ddname</var> of the library containing the sort exits, is used only in the z/OS environment. For information on installing the sort exits, see [[Model 204 installation on IBM z/OS#Link the Model 204 utility load modules\|Link the Model 204 utility load modules]].</li>
	</ul>		</ul>

	===SORT control statements===		===SORT control statements===
	~~<b>For z/OS and z/VM</b>~~
	<p>		<p>
	The syntax of SORT control statements is sort-package and operating-system specific, the following example of a SYSIN control statement is applicable for z/OS and z/VM:</p>		The syntax of SORT control statements is sort-package and operating-system specific, the following example of a <code>SYSIN</code> control statement is applicable for z/OS and z/VM:</p>

	<b>Syntax for z/OS and z/VM</b>		<b>Syntax for z/OS and z/VM</b>
Line 604:		Line 603:
	<li><var class="term">aa</var> is the sort field length, the value of (<var class="term">vl</var> - 5). It represents the length of the entire data portion of the expanded sort record.</li>		<li><var class="term">aa</var> is the sort field length, the value of (<var class="term">vl</var> - 5). It represents the length of the entire data portion of the expanded sort record.</li>

	<li><var class="term">vl</var> is a length parameter. See [[#Setting the variable-length sort parameter (vl)\|Setting the variable-length sort parameter (vl)]]. The length of the variable deferred index update entries is 270 for non-FILEORG X'200' files and 271 for FILEORG X'200' files, but 271 can be used for either.</li>		<li><var class="term">vl</var> is a length parameter. See [[#Setting the variable-length sort parameter (vl)\|Setting the variable-length sort parameter (vl)]]. The length of the variable deferred index update entries is 270 for non-<var>FILEORG</var> X'200' files and 271 for <var>FILEORG</var> X'200' files, but 271 can be used for either.</li>

	<li><var class="term">xxx</var> is OS for z/OS or CMS for z/VM, depending on the operating system.</li>		<li><var class="term">xxx</var> is OS for z/OS or CMS for z/VM, depending on the operating system.</li>
	</ul>		</ul>
	<p>		<p>
	The exact syntax for the MODS statement is operating-system and sort-package dependent.</p>		The exact syntax for the <code>MODS</code> statement is operating-system and sort-package dependent.</p>

	<b>Syntax for z/VSE</b>		<b>Syntax for z/VSE</b>