Record (File architecture) - Revision history

JAL: mixed case for For Record Number

2018-04-26T21:47:43Z

mixed case for For Record Number

← Older revision		Revision as of 21:47, 26 April 2018
Line 49:		Line 49:
	===Internal record number===		===Internal record number===
	<p>		<p>
	The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[Record loops#~~FOR RECORD NUMBER~~ processing\|~~FOR RECORD NUMBER statement~~]]), it is not a permanent identifier: when the file is reorganized, the position where a record is reloaded may be quite different than where it was before. </p>		The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the <var>[[Record loops#For Record Number processing\|For Record Number]]</var> statement), it is not a permanent identifier: when the file is reorganized, the position where a record is reloaded may be quite different than where it was before. </p>

	<p>The IRN (represented by a single bit in a bitmap) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bitmaps (File architecture)\|Bitmaps]] for more information.</p>		<p>The IRN (represented by a single bit in a bitmap) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bitmaps (File architecture)\|Bitmaps]] for more information.</p>

DCameron: /* Extension records */

2017-12-14T11:02:32Z

Extension records

← Older revision		Revision as of 11:02, 14 December 2017
Line 37:		Line 37:
	When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record), one or more extension records are stored.</p>		When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record), one or more extension records are stored.</p>

	<p>If [[Table X (File architecture)\|Table X]] is enabled, all such extensions are stored there, otherwise the extension(s) are stored in Table B.</p>		<p>If [[Table X (File architecture)\|Table X]] is enabled, all such extensions are stored there, otherwise the extension(s) are stored in Table B.</p>

	===Record growth===		===Record growth===

JAL: misc formatting

2016-09-01T19:15:55Z

misc formatting

← Older revision		Revision as of 19:15, 1 September 2016
Line 103:		Line 103:
	====Large objects====		====Large objects====
	<p>		<p>
	~~The subsections that follow describe the two ways that large~~ objects (data longer than 255 bytes) can be handled in a Model 204 record.</p>		Large objects (data longer than 255 bytes) can be handled in a Model 204 record in two ways: </p>
			<ul>
	~~=====~~Native large objects in Table E~~=====~~		<li>Native large objects in Table E
	<p>		<p>
	Large objects stored as part of a record contain a pointer locally (within the record) to the starting point of the large object in Table E.</p>		Large objects stored as part of a record contain a pointer locally (within the record) to the starting point of the large object in Table E.</p>
			<p>
			Starting in Model 204 V7.5, large objects can be handled by using the <var>[[FILEORG parameter\|FILEORG]]</var> X'100' bit. See [[Table E (File architecture)\|Table E]] for the full discussion.</p></li>

	<p>~~Starting in Model 204 V7.5, large objects can be handled by using the <var>[[FILEORG parameter\|FILEORG]]</var> X'100' bit. See [[Table E (File architecture)\|Table E]] for the full discussion.</p>~~		<li>Large objects without Table E

	~~=====~~Large objects without Table E~~=====~~
	<p>		<p>
	If Table E is not enabled, and the File Manager still wants to store data that is more than 255 bytes long, storage must be done by the application code. </p>		If Table E is not enabled, and the File Manager still wants to store data that is more than 255 bytes long, storage must be done by the application code. </p>
			<p>
	<p>The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes. The application must: </p>		The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes. The application must: </p>
	<ol>		<ol>
	<li>Parse the input data into 255-byte chunks to store it. </li>		<li>Parse the input data into 255-byte chunks to store it. </li>
	<li>String the chunks together again to read it. </li>		<li>String the chunks together again to read it. </li>
	</ol>		</ol></li>
			</ul>

	<p>For efficient storage of large objects, Rocket Software recommends enabling Table E.</p>		<p>For efficient storage of large objects, Rocket Software recommends enabling Table E.</p>

	[[Category:File architecture]]		[[Category:File architecture]]

JAL: link repair

2015-03-23T14:44:32Z

link repair

← Older revision		Revision as of 14:44, 23 March 2015
Line 3:		Line 3:
	A Model 204 <b>record</b> is a collection of fields (either individual, in field groups, or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.</p>		A Model 204 <b>record</b> is a collection of fields (either individual, in field groups, or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.</p>

	<p>Each record is variable in length and need contain only the fields (some or all of those contained in the [[File architecture ~~overview~~#Internal file ~~directory~~\|internal file ~~directory~~ in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.</p>		<p>Each record is variable in length and need contain only the fields (some or all of those contained in the [[Table A (File architecture)#Internal file dictionary\|internal file dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.</p>

	<p>There is only a limited fixed format for data within a record (preallocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique internal record number (IRN) that is used by the system to build index entries for the record. The IRN is temporary and will likely change when the file is reorganized.</p>		<p>There is only a limited fixed format for data within a record (preallocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique internal record number (IRN) that is used by the system to build index entries for the record. The IRN is temporary and will likely change when the file is reorganized.</p>

JAL: link repair

2015-03-23T14:37:18Z

link repair

← Older revision		Revision as of 14:37, 23 March 2015
Line 3:		Line 3:
	A Model 204 <b>record</b> is a collection of fields (either individual, in field groups, or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.</p>		A Model 204 <b>record</b> is a collection of fields (either individual, in field groups, or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.</p>

	<p>Each record is variable in length and need contain only the fields (some or all of those contained in the [[#~~Table A (File Architecture)~~ Internal ~~File Dictionary~~\|~~Internal File Dictionary~~ in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.</p>		<p>Each record is variable in length and need contain only the fields (some or all of those contained in the [[File architecture overview#Internal file directory\|internal file directory in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.</p>

	<p>There is only a limited fixed format for data within a record (preallocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique internal record number (IRN) that is used by the system to build index entries for the record. The IRN is temporary and will likely change when the file is reorganized.</p>		<p>There is only a limited fixed format for data within a record (preallocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique internal record number (IRN) that is used by the system to build index entries for the record. The IRN is temporary and will likely change when the file is reorganized.</p>

JAL at 20:14, 5 August 2014

2014-08-05T20:14:11Z

← Older revision		Revision as of 20:14, 5 August 2014
Line 81:		Line 81:
	<li>The order they were [[Data maintenance#ADD statement\|ADD]]ed (which always adds the entity at the end of the record)		<li>The order they were [[Data maintenance#ADD statement\|ADD]]ed (which always adds the entity at the end of the record)

	<li>An [[~~Operations on~~ multiply occurring fields#INSERT statement\|INSERT statement]].		<li>An [[Processing multiply occurring fields and field groups#INSERT statement\|INSERT statement]].
	</ul>		</ul>
	Hence, once past the preallocated fields, the application code controls the relative order of the data in the record.</p>		Hence, once past the preallocated fields, the application code controls the relative order of the data in the record.</p>

ELowell at 16:51, 12 May 2014

2014-05-12T16:51:53Z

← Older revision		Revision as of 16:51, 12 May 2014
Line 73:		Line 73:
	===Data===		===Data===
	<p>		<p>
	If there are any preallocated fields in a file (see the [[Field design ~~(File management)~~#Preallocated fields (OCCURS attribute)\|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File architecture) Record Map\|the record map in Table D]].</p>		If there are any preallocated fields in a file (see the [[Field design#Preallocated fields (OCCURS attribute)\|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File architecture) Record Map\|the record map in Table D]].</p>

	<p class="note">'''Note:''' For the sort or hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size), it will be the first field in the record map. If it is not preallocated, it will be the first "field value pair" in the record.</p>		<p class="note">'''Note:''' For the sort or hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size), it will be the first field in the record map. If it is not preallocated, it will be the first "field value pair" in the record.</p>
Line 89:		Line 89:
	====Preallocated fields====		====Preallocated fields====
	<p>		<p>
	All records stored in a Model 204 file will contain all of the [[Field design ~~(File management)~~#Preallocated fields (OCCURS attribute)\|preallocated fields]] (those with the <var>OCCURS</var> attribute) (if any) for that file. These are stored based on the [[Table D (File architecture)#Record map of preallocated fields\|Record map of preallocated fields]] stored in Table D.</p>		All records stored in a Model 204 file will contain all of the [[Field design#Preallocated fields (OCCURS attribute)\|preallocated fields]] (those with the <var>OCCURS</var> attribute) (if any) for that file. These are stored based on the [[Table D (File architecture)#Record map of preallocated fields\|Record map of preallocated fields]] stored in Table D.</p>

	====Field value pairs====		====Field value pairs====

JALWiccan: Automatically generated page update

2014-04-17T21:02:53Z

Automatically generated page update

← Older revision		Revision as of 21:02, 17 April 2014
Line 73:		Line 73:
	===Data===		===Data===
	<p>		<p>
	If there are any preallocated fields in a file (see the [[Field design (File management)#Preallocated fields\|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File architecture) Record Map\|the record map in Table D]].</p>		If there are any preallocated fields in a file (see the [[Field design (File management)#Preallocated fields (OCCURS attribute)\|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File architecture) Record Map\|the record map in Table D]].</p>

	<p class="note">'''Note:''' For the sort or hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size), it will be the first field in the record map. If it is not preallocated, it will be the first "field value pair" in the record.</p>		<p class="note">'''Note:''' For the sort or hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size), it will be the first field in the record map. If it is not preallocated, it will be the first "field value pair" in the record.</p>
Line 89:		Line 89:
	====Preallocated fields====		====Preallocated fields====
	<p>		<p>
	All records stored in a Model 204 file will contain all of the [[Field design (File management)#Preallocated fields\|preallocated fields]] (those with the <var>OCCURS</var> attribute) (if any) for that file. These are stored based on the [[Table D (File architecture)#Record map of preallocated fields\|Record map of preallocated fields]] stored in Table D.</p>		All records stored in a Model 204 file will contain all of the [[Field design (File management)#Preallocated fields (OCCURS attribute)\|preallocated fields]] (those with the <var>OCCURS</var> attribute) (if any) for that file. These are stored based on the [[Table D (File architecture)#Record map of preallocated fields\|Record map of preallocated fields]] stored in Table D.</p>

	====Field value pairs====		====Field value pairs====

JAL: /* Data */

2014-01-24T20:24:38Z

Data

← Older revision		Revision as of 20:24, 24 January 2014
Line 77:		Line 77:
	<p class="note">'''Note:''' For the sort or hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size), it will be the first field in the record map. If it is not preallocated, it will be the first "field value pair" in the record.</p>		<p class="note">'''Note:''' For the sort or hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size), it will be the first field in the record map. If it is not preallocated, it will be the first "field value pair" in the record.</p>

	<p>After the preallocated fields comes the rest of the data: a series of field value pairs, field groups, and/or pointers to large objects. These will be physically positioned in either of the following:		<p>After the preallocated fields comes the rest of the data: a series of field value pairs, field groups, and/or pointers to large objects. These will be physically positioned according to either of the following:
	<ul>		<ul>
	<li>The order they were [[Data maintenance#ADD statement\|ADD]]ed (which always adds the entity at the end of the record)		<li>The order they were [[Data maintenance#ADD statement\|ADD]]ed (which always adds the entity at the end of the record)

	<li>~~Positioned by an~~ [[Operations on multiply occurring fields#INSERT statement\|INSERT statement]].		<li>An [[Operations on multiply occurring fields#INSERT statement\|INSERT statement]].
	</ul>		</ul>
	Hence, once past the preallocated fields, the application code controls the relative order of the data in the record.</p>		Hence, once past the preallocated fields, the application code controls the relative order of the data in the record.</p>

	<p>~~Each~~ of the four ~~is briefly described below~~, but refer to the specific topic for each for further detail:</p>		<p>The following subsections further describe each of the four record data components, but refer to the specific topic for each for further detail.</p>

	====Preallocated fields====		====Preallocated fields====
Line 119:		Line 119:
	<li>Parse the input data into 255-byte chunks to store it. </li>		<li>Parse the input data into 255-byte chunks to store it. </li>
	<li>String the chunks together again to read it. </li>		<li>String the chunks together again to read it. </li>
	</ul>		</ol>

	<p>For efficient storage of large objects, Rocket Software recommends enabling Table E.</p>		<p>For efficient storage of large objects, Rocket Software recommends enabling Table E.</p>

	[[Category:File architecture]]		[[Category:File architecture]]

JAL at 20:14, 24 January 2014

2014-01-24T20:14:31Z

Show changes