File design - Revision history

DCameron: /* Maintaining the reuse queue */

2019-02-06T15:01:29Z

Maintaining the reuse queue

← Older revision		Revision as of 15:01, 6 February 2019
Line 114:		Line 114:
	<p>		<p>
	When a page is removed from the queue, indicating that it no longer contains reusable record numbers, the reuse queue chain pointer on that page is set to zero and the pointer on the previous page in the queue is adjusted accordingly.</p>		When a page is removed from the queue, indicating that it no longer contains reusable record numbers, the reuse queue chain pointer on that page is set to zero and the pointer on the previous page in the queue is adjusted accordingly.</p>

	=====Understanding eligible and ineligible reuse queue pages=====		=====Understanding eligible and ineligible reuse queue pages=====
	<p>		<p>

ELowell: /* Enhanced data handling files (X'100') */

2017-07-14T22:59:50Z

Enhanced data handling files (X'100')

← Older revision		Revision as of 22:59, 14 July 2017
Line 301:		Line 301:
	</ul>		</ul>

			Setting the X'100' bit requires additional overhead in Table B, as described in <var>[[FILEORG parameter\|FILEORG]]</var>.

	If X'100' is set, the X'80' bit is automatically also set.		If X'100' is set, the X'80' bit is automatically also set.

	<~~blockquote~~ class="note">		<p class="note"><b>Note:</b> <var>FILEORG</var> X'100' files cannot be loaded via <var>[[FLOD_command\|FLOD]]</var> or <var>[[FILELOAD_command\|FILELOAD]]</var> except with a <var class="product">[[Fast/Reload]]</var> Load All Information (<var>[[Fast/Reload statements#The LAI statement\|LAI]]</var>) <var>FLOD/FILELOAD</var> program.</p>
	<p><b>Note:</b> <var>FILEORG</var> X'100' files ~~may not~~ be ~~accessed~~ via <var>FLOD</var> or <var>FILELOAD</var>. The ~~following message is produced if this is attempted:~~</p>
	<~~p class="code"~~>~~M204:2903: FILEORG=X'100' IS NOT SUPPORTED DURING~~ FLOD/FILELOAD
	</p>
	</~~blockquote~~>

	Enhanced data handling files are available as of version 7.5 of Model 204.		Enhanced data handling files are available as of version 7.5 of Model 204.

	====<b id="x200"></b>Large file support (X'200')====		====<b id="x200"></b>Large file support (X'200')====
	Setting this <var>FILEORG</var> bit allows for a file to hold up to 48 million records (versus 16M records without this setting).		Setting this <var>FILEORG</var> bit allows for a file to hold up to 48 million records (versus 16M records without this setting).

JAL: add ID to Large file support

2017-07-11T23:07:16Z

add ID to Large file support

← Older revision		Revision as of 23:07, 11 July 2017
Line 311:		Line 311:
	Enhanced data handling files are available as of version 7.5 of Model 204.		Enhanced data handling files are available as of version 7.5 of Model 204.

	====Large file ~~enhancement~~ (X'200')====		====<b id="x200"></b>Large file support (X'200')====
			Setting this <var>FILEORG</var> bit allows for a file to hold up to 48 million records (versus 16M records without this setting).
	Setting this <var>FILEORG</var> bit allows for a file to hold up to 48 million records.

	<ul>		<ul>
	<li>Space on file pages is used just as efficiently as a non-<var>FILEORG</var> X'200' file. There is one extremely small overhead: the extension record pointers are 4 bytes rather than 3, just as in a file that contains Table X. In fact, if there is any but the very smallest number of extension records, using Table X recommended, so that all of the (up to 48M) record numbers are available for base records. </li>		<li>Space on file pages is used just as efficiently as a non-<var>FILEORG</var> X'200' file. There is one extremely small overhead: the extension record pointers are 4 bytes rather than 3, just as in a file that contains Table X. In fact, if there is any but the very smallest number of extension records, using Table X is recommended, so that all of the (up to 48M) record numbers are available for base records. </li>

	<li>May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.</li>		<li>May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.</li>

JAL: misc formatting

2017-07-11T19:18:21Z

misc formatting

← Older revision		Revision as of 19:18, 11 July 2017
Line 316:		Line 316:

	<ul>		<ul>
	<li>Space on file pages is used just as ~~efficienlty~~ as a non-FILEORG X'200' file. There is one extremely small overhead - the extension record pointers are 4 bytes rather than 3, just as in a file ~~which~~ contains Table X. In fact, if there is any but the very smallest number of extension records, ~~it is recommended to use~~ Table X, so that all of the up to 48M record numbers are available for base records.		<li>Space on file pages is used just as efficiently as a non-<var>FILEORG</var> X'200' file. There is one extremely small overhead: the extension record pointers are 4 bytes rather than 3, just as in a file that contains Table X. In fact, if there is any but the very smallest number of extension records, using Table X recommended, so that all of the (up to 48M) record numbers are available for base records. </li>

	<li>May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.</li>		<li>May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.</li>
	<li>A few considerations are required for [[Deferred update feature#defUpdtX200\|deferred updates]].
			<li>A few considerations are required for [[Deferred update feature#defUpdtX200\|deferred updates]]. </li>
	</ul>		</ul>

Dme: /* Large file enhancement (X'200') */

2017-07-06T23:36:41Z

Large file enhancement (X'200')

← Older revision		Revision as of 23:36, 6 July 2017
Line 316:		Line 316:

	<ul>		<ul>
			<li>Space on file pages is used just as efficienlty as a non-FILEORG X'200' file. There is one extremely small overhead - the extension record pointers are 4 bytes rather than 3, just as in a file which contains Table X. In fact, if there is any but the very smallest number of extension records, it is recommended to use Table X, so that all of the up to 48M record numbers are available for base records.
	<li>May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.</li>		<li>May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.</li>
			<li>A few considerations are required for [[Deferred update feature#defUpdtX200\|deferred updates]].
	</ul>		</ul>

ELowell: /* Separate logical files */

2017-04-11T16:28:15Z

Separate logical files

← Older revision		Revision as of 16:28, 11 April 2017
Line 469:		Line 469:
	<li>Heavily updated data can be separated from data that is rarely or never updated, thus simplifying checkpointing and backup procedures.</li>		<li>Heavily updated data can be separated from data that is rarely or never updated, thus simplifying checkpointing and backup procedures.</li>

	<li>User access to logically separate data can be controlled easily by means of file security (see [[Model 204 security features\|File security]]).</li>		<li>User access to logically separate data can be controlled easily by means of file security (see [[Model 204 security features#File security\|File security]]).</li>
	</ul>		</ul>

	===File groups===		===File groups===
	<p>		<p>

JALWiccan: Automatically generated page update

2017-04-07T21:17:04Z

Automatically generated page update

← Older revision		Revision as of 21:17, 7 April 2017
Line 352:		Line 352:
	</ul>		</ul>
	<p>		<p>
	You can also specify record security for individual records in a file and supply a record security key. See [[~~Security~~\| Security]] for details on Security and <var>PRIVDEF</var> options.</p>		You can also specify record security for individual records in a file and supply a record security key. See [[Model 204 security features\| Security]] for details on Security and <var>PRIVDEF</var> options.</p>
	<p class="note"><b>Note:</b> Most of the file access will likely be done through [[Application Subsystem development\|Application Subsystems]] (APSY). The security options for APSY access are set in its definition.</p>		<p class="note"><b>Note:</b> Most of the file access will likely be done through [[Application Subsystem development\|Application Subsystems]] (APSY). The security options for APSY access are set in its definition.</p>

Line 469:		Line 469:
	<li>Heavily updated data can be separated from data that is rarely or never updated, thus simplifying checkpointing and backup procedures.</li>		<li>Heavily updated data can be separated from data that is rarely or never updated, thus simplifying checkpointing and backup procedures.</li>

	<li>User access to logically separate data can be controlled easily by means of file security (see [[~~Security~~\|File security]]).</li>		<li>User access to logically separate data can be controlled easily by means of file security (see [[Model 204 security features\|File security]]).</li>
	</ul>		</ul>

JAL: link repair

2016-02-17T01:56:40Z

link repair

← Older revision		Revision as of 01:56, 17 February 2016
Line 93:		Line 93:
	=====Reusing record numbers=====		=====Reusing record numbers=====
	<p>		<p>
	In order to use space on any page for a new record, a record number must be available on that page. To be useful, an unordered file must either be designed with many extra record numbers per page, or must use the reuse record number (RRN) option. See [[#Reuse Record Number (X'40')\|Reuse Record Number (X'40')]].</p>		In order to use space on any page for a new record, a record number must be available on that page. To be useful, an unordered file must either be designed with many extra record numbers per page, or must use the reuse record number (RRN) option. See [[#Reuse Record Number (X'04')\|Reuse Record Number (X'04')]].</p>

	=====Planning open space=====		=====Planning open space=====

JAL: /* Reuse Record Number (X'40') */ typo

2016-02-17T01:23:06Z

Reuse Record Number (X'40'): typo

← Older revision		Revision as of 01:23, 17 February 2016
Line 164:		Line 164:
	</ul>		</ul>

	====Reuse Record Number (X'40')====		====Reuse Record Number (X'04')====
	<p>		<p>
	The Reuse Record Number (RRN) feature allows <var class="product">Model 204</var> to reuse the record number of a deleted record for a new record, if a record number is available on the Table B page to which the new record is added. Consider the following points during the design of applications that allow record number reuse: </p>		The Reuse Record Number (RRN) feature allows <var class="product">Model 204</var> to reuse the record number of a deleted record for a new record, if a record number is available on the Table B page to which the new record is added. Consider the following points during the design of applications that allow record number reuse: </p>
Line 283:		Line 283:
	<p>		<p>
	Some <var class="product">Model 204</var> features locate records through explicit use of record numbers, notably the SOUL <var>POINT$</var> retrieval condition and the Host Language Interface <var>IFPOINT</var> function. Avoid dependence upon record numbers wherever possible, because a record number that at one time pointed to a record that was deleted can, at some later time, again point to a valid record, which is not the same record originally stored with that record number. </p>		Some <var class="product">Model 204</var> features locate records through explicit use of record numbers, notably the SOUL <var>POINT$</var> retrieval condition and the Host Language Interface <var>IFPOINT</var> function. Avoid dependence upon record numbers wherever possible, because a record number that at one time pointed to a record that was deleted can, at some later time, again point to a valid record, which is not the same record originally stored with that record number. </p>

	====Optimized field extraction files (X'80')====		====Optimized field extraction files (X'80')====
	When this option is set, all non-preallocated (non-<var>OCCURS</var>) fields are preceded by a field-value length byte.		When this option is set, all non-preallocated (non-<var>OCCURS</var>) fields are preceded by a field-value length byte.

ELowell: /* Entry order files */

2016-01-28T23:02:03Z

Entry order files

← Older revision		Revision as of 23:02, 28 January 2016
Line 68:		Line 68:
	In ordinary <var class="product">Model 204</var> files, each new record is simply stored in the available space after any other records in Table B. When a set of records is retrieved from such files, the records are processed in the order in which they were stored. This order is <var class="term">chronological</var>. These files are known as <b>entry order files</b>. </p>		In ordinary <var class="product">Model 204</var> files, each new record is simply stored in the available space after any other records in Table B. When a set of records is retrieved from such files, the records are processed in the order in which they were stored. This order is <var class="term">chronological</var>. These files are known as <b>entry order files</b>. </p>
	<p>		<p>
	Entry order files are the most widely used <var class="product">Model 204</var> files. They provide full inverted file capabilities but do not support the unordered file, ~~sort~~ file, and hash key file facilities described later in this section. If you require sorted output, you can include the <var>SORT</var> statement in a SOUL request, use the <var>IFSORT</var> call in a <var class="product">[[Media:M204 HLIReference V75.pdf\|Host Language Interface]]</var> program, or specify the <var>ORDERED</var> attribute.</p>		Entry order files are the most widely used <var class="product">Model 204</var> files. They provide full inverted file capabilities but do not support the unordered file, sorted file, and hash key file facilities described later in this section. If you require sorted output, you can include the <var>SORT</var> statement in a SOUL request, use the <var>IFSORT</var> call in a <var class="product">[[Media:M204 HLIReference V75.pdf\|Host Language Interface]]</var> program, or specify the <var>ORDERED</var> attribute.</p>
	<p>		<p>
	In an entry order file, new records are added only after other records in the file. A fixed number of pages is assigned to Table B of the file by the <var>CREATE</var> command. You can increase the number of pages any time, subject only to the limits of the total disk space available (or 16M pages). You can decrease them at any time to the value of the <var>[[BHIGHPG parameter\|BHIGHP]]</var> parameter plus one. When an attempt is made to store another record in a file that has insufficient space available at the end of the file, the transaction is backed out if possible, and an error message is issued; the file might also be marked full. This occurs even though numerous records in the file might have been deleted. </p>		In an entry order file, new records are added only after other records in the file. A fixed number of pages is assigned to Table B of the file by the <var>CREATE</var> command. You can increase the number of pages any time, subject only to the limits of the total disk space available (or 16M pages). You can decrease them at any time to the value of the <var>[[BHIGHPG parameter\|BHIGHP]]</var> parameter plus one. When an attempt is made to store another record in a file that has insufficient space available at the end of the file, the transaction is backed out if possible, and an error message is issued; the file might also be marked full. This occurs even though numerous records in the file might have been deleted. </p>

	In an entry order file, space made available by deleting records can be reused for the expansion of existing Table B records, but cannot be reused for adding new records to the file. These records must be added in whatever space is available after all the other records in the file.		In an entry order file, space made available by deleting records can be reused for the expansion of existing Table B records, but cannot be reused for adding new records to the file. These records must be added in whatever space is available after all the other records in the file.

	====Unordered files (X'20')====		====Unordered files (X'20')====
	<p>		<p>