Adding records (File architecture) - Revision history

JAL: link repair

2015-03-23T14:52:10Z

link repair

← Older revision		Revision as of 14:52, 23 March 2015
Line 28:		Line 28:
	<ul>		<ul>
	<li>All field names, the values of coded fields, and some <var>FRV</var> fields are converted into fixed-length codes from Table A. </li>		<li>All field names, the values of coded fields, and some <var>FRV</var> fields are converted into fixed-length codes from Table A. </li>

	<li>All other attributes of the referenced fields are noted for use during the execution. </li>		<li>All other attributes of the referenced fields are noted for use during the execution. </li>
	</ul></li>		</ul></li>
Line 35:		Line 36:
	<li>A physical internal record number (IRN) is assigned in Table B, taking the <var>[[BRESERVE parameter\|BRESERVE]]</var> parameter into account to determine if there is enough space on the page to store the record. </li>		<li>A physical internal record number (IRN) is assigned in Table B, taking the <var>[[BRESERVE parameter\|BRESERVE]]</var> parameter into account to determine if there is enough space on the page to store the record. </li>

	<li>If there are any ~~pr/eallocated~~ fields, the fields in the [[#Table D (File ~~Architecture~~) Record ~~Map~~\|record map]] are added to the record. </li>		<li>If there are any preallocated fields, the fields in the [[Table D (File architecture)#Record map of preallocated fields\|record map]] are added to the record. </li>

	<li>Then, for each field value pair in the <var>STORE RECORD</var> statement (none are required, an "empty" record can be created if no fields are referenced):		<li>Then, for each field value pair in the <var>STORE RECORD</var> statement (none are required, an "empty" record can be created if no fields are referenced):

JAL: add link

2015-03-02T20:20:04Z

add link

← Older revision		Revision as of 20:20, 2 March 2015
Line 19:		Line 19:
	All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.</p>		All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.</p>
	<p>		<p>
	For more information, see [[Data maintenance]] or the <var class="book">Rocket Model~~ ~~204 Host Language Interface Reference Manual</var>.</p>		For more information, see [[Data maintenance]] or the <var class="book">[[Media:M204 HLIReference V75.pdf\|Rocket Model 204 Host Language Interface Reference Manual]]</var>.</p>

	==How Model 204 adds records to a file==		==How Model 204 adds records to a file==

JAL: more conversion cleanup

2015-01-14T21:54:21Z

more conversion cleanup

← Older revision		Revision as of 21:54, 14 January 2015
Line 1:		Line 1:
	==Adding a record to a file==		==Adding a record to a file==
	<p>		<p>
	This ~~section~~ describes the process to add a record to a Model 204 file. It presumes that the file has already been [[CREATE command: File\|created]] and [[INITIALIZE command\|initialized]], and that all fields and field groups needed in this action are defined to the file. </p>		This page describes the process to add a record to a Model 204 file. It presumes that the file has already been [[CREATE command: File\|created]] and [[INITIALIZE command\|initialized]], and that all fields and field groups needed in this action are defined to the file. </p>
	<p>		<p>
	~~And a~~ reminder: while fields and field groups may, generally, be defined to the file at any time, some field attributes (for example, the pre-allocation of fields with the OCCURS attribute), may only be defined in a file to which no data has yet been added.</p>		A reminder: while fields and field groups may, generally, be defined to the file at any time, some field attributes (for example, the pre-allocation of fields with the <var>OCCURS</var> attribute), may only be defined in a file to which no data has yet been added.</p>

	<p>		<p>
	The addition of the record is driven by the SOUL [[Data maintenance#STORE RECORD statement\|STORE RECORD ~~statement~~]] with an (optional) list of ''fieldname'' value pairs, as in the following example: </p>		The addition of the record is driven by the SOUL <var>[[Data maintenance#STORE RECORD statement\|STORE RECORD]]</var> statement with an (optional) list of ''fieldname''=''value'' pairs, as in the following example: </p>

	<p class="code">STREC: STORE RECORD		<p class="code">STREC: STORE RECORD
Line 15:		Line 15:
	</p>		</p>
	<p>		<p>
	Alternatively, you can use the Host Language Interface IFBREC, IFPUT, and IFSTORE calls, which also require a list of name = value pairs.</p>		Alternatively, you can use the Host Language Interface <var>IFBREC</var>, <var>IFPUT</var>, and <var>IFSTORE</var> calls, which also require a list of "name = value" pairs.</p>
	<p>		<p>
	All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.</p>		All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.</p>
Line 22:		Line 22:

	==How Model 204 adds records to a file==		==How Model 204 adds records to a file==
	<p>The process of adding a new record to a ~~file,~~ <var class="product">Model 204</var> is as follows:</p>		<p>
			The process of adding a new record to a <var class="product">Model 204</var> file is as follows. Like all SOUL code, the process consists of two parts: </p>
	<ol>		<ol>
	<li>~~Like all User Language code, the process consists of two parts; first the~~ code is compiled:		<li>The code is compiled:
	<ol>		<ul>
	<li>All field names, the values of coded fields and some FRV fields are converted into fixed-length codes from Table A.		<li>All field names, the values of coded fields, and some <var>FRV</var> fields are converted into fixed-length codes from Table A. </li>
	<li>All other attributes of the referenced fields are noted for use during the execution.		<li>All other attributes of the referenced fields are noted for use during the execution. </li>
	</ol>		</ul></li>

	<li>~~Presuming the code compiles, in~~ the evaluation process, when the STORE RECORD statement is executed:		<li>In the evaluation process after compilation, when the <var>STORE RECORD</var> statement is executed:
	<ol>		<ul>
	<li>A physical internal record number (IRN) is assigned in Table B taking the [[BRESERVE parameter]] into account to determine if there is enough space on the page to store the record.		<li>A physical internal record number (IRN) is assigned in Table B, taking the <var>[[BRESERVE parameter\|BRESERVE]]</var> parameter into account to determine if there is enough space on the page to store the record. </li>

	<li>If there are any ~~preallocated~~ fields, the fields in the [[#Table D (File Architecture) Record Map\|record map]] are added to the record.		<li>If there are any pr/eallocated fields, the fields in the [[#Table D (File Architecture) Record Map\|record map]] are added to the record. </li>

	<li>Then, for each field value pair in the STORE RECORD statement (none are required, an "empty" record can be created if no fields are referenced):		<li>Then, for each field value pair in the <var>STORE RECORD</var> statement (none are required, an "empty" record can be created if no fields are referenced):
	<ol>		<ol>
	<li>The field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E).		<li>The field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E). </li>

	<li>Of course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File architecture)\|Table X]]).		<li>Of course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File architecture)\|Table X]]). </li>

	<li>If the field is indexed, the necessary updates occur to Tables C and D.		<li>If the field is indexed, the necessary updates occur to Tables C and D. </li>
	</ol></ol>		</ol></li>
			</ul></li>
	</ol>		</ol>

JAL at 20:54, 22 January 2014

2014-01-22T20:54:30Z

← Older revision		Revision as of 20:54, 22 January 2014
Line 1:		Line 1:
	==Adding a record to a file==		==Adding a record to a file==
	<p>This section describes the process to add a record to a Model 204 file. It presumes that the file has already been [[CREATE command: File\|created]] and [[INITIALIZE command\|initialized]], and that all fields and field groups needed in this action are defined to the file. </p>		<p>
	<p>And a reminder: while fields and field groups may, generally, be defined to the file at any time, some field attributes (for example, the pre-allocation of fields with the OCCURS attribute), may only be defined in a file to which no data has yet been added.</p>		This section describes the process to add a record to a Model 204 file. It presumes that the file has already been [[CREATE command: File\|created]] and [[INITIALIZE command\|initialized]], and that all fields and field groups needed in this action are defined to the file. </p>
			<p>
			And a reminder: while fields and field groups may, generally, be defined to the file at any time, some field attributes (for example, the pre-allocation of fields with the OCCURS attribute), may only be defined in a file to which no data has yet been added.</p>

	<p>The addition of the record is driven by the ~~User Language~~ [[Data maintenance#STORE RECORD statement\|STORE RECORD statement]] with an (optional) list of ''fieldname'' value pairs, as in the following example. </p>		<p>
			The addition of the record is driven by the SOUL [[Data maintenance#STORE RECORD statement\|STORE RECORD statement]] with an (optional) list of ''fieldname'' value pairs, as in the following example: </p>

	<p class="code">STREC: STORE RECORD		<p class="code">STREC: STORE RECORD
Line 11:		Line 14:
	END STORE		END STORE
	</p>		</p>
	<p>Alternatively, you can use the Host Language Interface IFBREC, IFPUT, and IFSTORE calls, which also require a list of name = value pairs.</p>		<p>
	<p>All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.</p>		Alternatively, you can use the Host Language Interface IFBREC, IFPUT, and IFSTORE calls, which also require a list of name = value pairs.</p>
	<p>For more information see ~~the <var class="book">Rocket Model 204 User Language Manual</var>~~ or the <var class="book">Rocket Model 204 Host Language Interface Reference Manual</var>.</p>		<p>
			All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.</p>
			<p>
			For more information, see [[Data maintenance]] or the <var class="book">Rocket Model 204 Host Language Interface Reference Manual</var>.</p>

	==How Model 204 adds records to a file==		==How Model 204 adds records to a file==
	<p>The process of adding a new record to a file, <var class="product">Model 204</var> is as follows:</p>		<p>The process of adding a new record to a file, <var class="product">Model 204</var> is as follows:</p>
	#Like all User Language code, the process consists of two parts; first the code is compiled:		<ol>
	~~##all~~ field names, the values of coded fields and some FRV fields are converted into fixed-length codes from Table A		<li>Like all User Language code, the process consists of two parts; first the code is compiled:
	~~##all~~ other attributes of the referenced fields are noted for use during the execution		<ol>
	#Presuming the code compiles, in the evaluation process, when the STORE RECORD statement is executed:		<li>All field names, the values of coded fields and some FRV fields are converted into fixed-length codes from Table A.
	~~##a~~ physical internal record number (IRN) is assigned in Table B taking the [[BRESERVE parameter]] into account to determine if there is enough space on the page to store the record		<li>All other attributes of the referenced fields are noted for use during the execution.
	~~##if~~ there are any preallocated fields, the fields in the [[#Table D (File Architecture) Record Map\|record map]] are added to the record		</ol>
	~~##then~~, for each field value pair in the STORE RECORD statement (none are required, an 'empty' record can be created if no fields are referenced):
	~~###the~~ field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E)		<li>Presuming the code compiles, in the evaluation process, when the STORE RECORD statement is executed:
	~~###of~~ course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File architecture)\|Table X]] )		<ol>
	~~###if~~ the field is indexed, the necessary updates occur to Tables C and D.		<li>A physical internal record number (IRN) is assigned in Table B taking the [[BRESERVE parameter]] into account to determine if there is enough space on the page to store the record.

			<li>If there are any preallocated fields, the fields in the [[#Table D (File Architecture) Record Map\|record map]] are added to the record.

			<li>Then, for each field value pair in the STORE RECORD statement (none are required, an "empty" record can be created if no fields are referenced):
			<ol>
			<li>The field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E).

			<li>Of course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File architecture)\|Table X]]).

			<li>If the field is indexed, the necessary updates occur to Tables C and D.
			</ol></ol>
			</ol>

	==Considerations when adding many records to a file==		==Considerations when adding many records to a file==
	<p>If you are adding a large number of records to a file, consider these alternatives for increased efficiency: </p>		<p>
			If you are adding a large number of records to a file, consider these alternatives for increased efficiency: </p>
	<ul>		<ul>
	<li>Deferred updates. Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[Deferred update feature]] describes how to use deferred updates.</li>		<li>Deferred updates.
	<li>File Load utility. If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. See [[File Load utility]] for more information.</li>		<p>
			Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[Deferred update feature]] describes how to use deferred updates.</p></li>

			<li>File Load utility.
			<p>
			If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. See [[File Load utility]] for more information.</p></li>
	</ul>		</ul>
	~~<p> </p>~~
	[[Category:File architecture]]		[[Category:File architecture]]

JAL at 21:05, 2 January 2014

2014-01-02T21:05:54Z

← Older revision		Revision as of 21:05, 2 January 2014
Line 3:		Line 3:
	<p>And a reminder: while fields and field groups may, generally, be defined to the file at any time, some field attributes (for example, the pre-allocation of fields with the OCCURS attribute), may only be defined in a file to which no data has yet been added.</p>		<p>And a reminder: while fields and field groups may, generally, be defined to the file at any time, some field attributes (for example, the pre-allocation of fields with the OCCURS attribute), may only be defined in a file to which no data has yet been added.</p>

	<p>The addition of the record is driven by the User Language [[Data ~~Maintenance~~#STORE RECORD statement\|STORE RECORD statement]] with an (optional) list of ''fieldname'' value pairs, as in the following example. </p>		<p>The addition of the record is driven by the User Language [[Data maintenance#STORE RECORD statement\|STORE RECORD statement]] with an (optional) list of ''fieldname'' value pairs, as in the following example. </p>

	<p class="code">STREC: STORE RECORD		<p class="code">STREC: STORE RECORD

ELowell at 22:45, 18 December 2013

2013-12-18T22:45:42Z

← Older revision		Revision as of 22:45, 18 December 2013
Line 25:		Line 25:
	##then, for each field value pair in the STORE RECORD statement (none are required, an 'empty' record can be created if no fields are referenced):		##then, for each field value pair in the STORE RECORD statement (none are required, an 'empty' record can be created if no fields are referenced):
	###the field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E)		###the field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E)
	###of course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File ~~Architecture~~)\|Table X]] )		###of course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File architecture)\|Table X]] )
	###if the field is indexed, the necessary updates occur to Tables C and D.		###if the field is indexed, the necessary updates occur to Tables C and D.

Admin at 22:18, 18 December 2013

2013-12-18T22:18:06Z

← Older revision		Revision as of 22:18, 18 December 2013
Line 25:		Line 25:
	##then, for each field value pair in the STORE RECORD statement (none are required, an 'empty' record can be created if no fields are referenced):		##then, for each field value pair in the STORE RECORD statement (none are required, an 'empty' record can be created if no fields are referenced):
	###the field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E)		###the field value pair is added to the record (for a Table E update, only the pointer is added to the field in Table B and the LOB itself is added to Table E)
	###of course, normal extension record rules apply (as discussed in [[Table B (File ~~Architecture~~)\|Table B]] or [[Table X (File Architecture)\|Table X]] )		###of course, normal extension record rules apply (as discussed in [[Table B (File architecture)\|Table B]] or [[Table X (File Architecture)\|Table X]] )
	###if the field is indexed, the necessary updates occur to Tables C and D.		###if the field is indexed, the necessary updates occur to Tables C and D.

Admin: Admin moved page Adding Records (File Architecture) to Adding records (File architecture) without leaving a redirect

2013-12-18T21:04:08Z

Admin moved page Adding Records (File Architecture) to Adding records (File architecture) without leaving a redirect

← Older revision	Revision as of 21:04, 18 December 2013
(No difference)

ELowell at 21:19, 13 December 2013

2013-12-13T21:19:01Z

← Older revision		Revision as of 21:19, 13 December 2013
Line 32:		Line 32:
	<ul>		<ul>
	<li>Deferred updates. Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[Deferred update feature]] describes how to use deferred updates.</li>		<li>Deferred updates. Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[Deferred update feature]] describes how to use deferred updates.</li>
	<li>File Load utility. If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. [[ File Load ~~Utility#File Load Utility\|File Load Utility~~]] ~~describes the File Load utility~~.</li>		<li>File Load utility. If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. See [[File Load utility]] for more information.</li>
	</ul>		</ul>
	<p> </p>		<p> </p>
	[[Category:File architecture]]		[[Category:File architecture]]

ELowell at 23:07, 12 December 2013

2013-12-12T23:07:11Z

← Older revision		Revision as of 23:07, 12 December 2013
Line 31:		Line 31:
	<p>If you are adding a large number of records to a file, consider these alternatives for increased efficiency: </p>		<p>If you are adding a large number of records to a file, consider these alternatives for increased efficiency: </p>
	<ul>		<ul>
	<li>Deferred updates. Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[ Deferred ~~Update Feature#Deferred Update Feature\|Deferred Update Feature~~]] describes how to use deferred updates.</li>		<li>Deferred updates. Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[Deferred update feature]] describes how to use deferred updates.</li>
	<li>File Load utility. If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. [[ File Load Utility#File Load Utility\|File Load Utility]] describes the File Load utility.</li>		<li>File Load utility. If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. [[ File Load Utility#File Load Utility\|File Load Utility]] describes the File Load utility.</li>
	</ul>		</ul>
	<p> </p>		<p> </p>
	[[Category:File architecture]]		[[Category:File architecture]]