Field group (File architecture) - Revision history

JAL: /* Field groups and Table B storage considerations */ add link

2015-04-01T23:04:14Z

Field groups and Table B storage considerations: add link

← Older revision		Revision as of 23:04, 1 April 2015
Line 57:		Line 57:
	<p>The costs:</p>		<p>The costs:</p>
	<ul>		<ul>
	<li>Every record in a <var>FILEORG</var> X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.</li>		<li>Every record in a <var>[[FILEORG parameter\|FILEORG]]</var> X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.</li>

	<li>As is true of all <var>FILEORG</var> X'100' files, the field name representations (as held in [[Table A (File architecture)\|Table A]] and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this might be offset by the physical absence of fields defined as part of the group.</li>		<li>As is true of all <var>FILEORG</var> X'100' files, the field name representations (as held in [[Table A (File architecture)\|Table A]] and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this might be offset by the physical absence of fields defined as part of the group.</li>

JAL: /* Field groups and Table B storage considerations */

2015-04-01T23:03:17Z

Field groups and Table B storage considerations

← Older revision		Revision as of 23:03, 1 April 2015
Line 57:		Line 57:
	<p>The costs:</p>		<p>The costs:</p>
	<ul>		<ul>
	<li>Every record in a FILEORG=X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.</li>		<li>Every record in a <var>FILEORG</var> X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.</li>

	<li>As is true of all FILEORG=X'100' files, the field name representations (as held in [[Table A (File architecture)\|Table A]] and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this might be offset by the physical absence of fields defined as part of the group.</li>		<li>As is true of all <var>FILEORG</var> X'100' files, the field name representations (as held in [[Table A (File architecture)\|Table A]] and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this might be offset by the physical absence of fields defined as part of the group.</li>
	</ul>		</ul>

JAL at 20:32, 5 August 2014

2014-08-05T20:32:19Z

← Older revision		Revision as of 20:32, 5 August 2014
Line 5:		Line 5:
	<p>The idea of a <b>physical field group</b> is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[Field group design]] for details.)</p>		<p>The idea of a <b>physical field group</b> is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[Field group design]] for details.)</p>

	<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[~~Operations on~~ multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>		<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Processing multiply occurring fields and field groups]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>

	==Performance==		==Performance==

Mlarocca at 13:43, 1 August 2014

2014-08-01T13:43:01Z

← Older revision		Revision as of 13:43, 1 August 2014
Line 75:		Line 75:
	<p>As mentioned above, every field group has a unique ID.</p>		<p>As mentioned above, every field group has a unique ID.</p>

	<p>This ID can be read with the <var>[[$~~FIELDGROUPID~~]]</var> function, and it is also displayed by the <var>[[Basic SOUL statements and commands#PRINT ALL INFORMATION (or PAI) statement\|Print All Information]]</var> statement.</p>		<p>This ID can be read with the <var>[[$FieldgroupId]]</var> function, and it is also displayed by the <var>[[Basic SOUL statements and commands#PRINT ALL INFORMATION (or PAI) statement\|Print All Information]]</var> statement.</p>

	<p>By itself, the ID is just for uniqueness, but it has an interesting use that is invaluable in debugging: you can determine the order in which things happened to a file.</p>		<p>By itself, the ID is just for uniqueness, but it has an interesting use that is invaluable in debugging: you can determine the order in which things happened to a file.</p>

Dme at 04:38, 10 May 2014

2014-05-10T04:38:17Z

← Older revision		Revision as of 04:38, 10 May 2014
Line 3:		Line 3:
	Data items do not normally exist on their own. In the case of addresses, for example, a series of fields exist for each address (house number, city, state, zip code) which clearly operate interdependently. </p>		Data items do not normally exist on their own. In the case of addresses, for example, a series of fields exist for each address (house number, city, state, zip code) which clearly operate interdependently. </p>

	<p>The idea of a <b>physical field group</b> is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[~~Field group design (File management)\|~~Field group design]] for details.)</p>		<p>The idea of a <b>physical field group</b> is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[Field group design]] for details.)</p>

	<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Operations on multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>		<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Operations on multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>
Line 68:		Line 68:
	Take as an example a financial application where you are tracking a number of types of income over time. You have a field group containing a date and a number of income types: salary, interest, dividends, and so forth. It is likely that the majority of people whose data you are keeping have only a few of the many types of interest, so your record might have mostly zeros.</p>		Take as an example a financial application where you are tracking a number of types of income over time. You have a field group containing a date and a number of income types: salary, interest, dividends, and so forth. It is likely that the majority of people whose data you are keeping have only a few of the many types of interest, so your record might have mostly zeros.</p>
	<p>		<p>
	If so, by adding a [[Field design ~~(File management)~~#DEFAULT-VALUE (DV) attribute\|default value]] of 0 and a [[Field design ~~(File management)~~#STORE-DEFAULT (SD) and STORE-NULL (SN) attributes\|store default]] of NONE (the default for [[Field design ~~(File management)~~#AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes\|exactly one]] fields in field groups), none of the 0s would be physically stored (but would be treated as if they were).</p>		If so, by adding a [[Field design#DEFAULT-VALUE (DV) attribute\|default value]] of 0 and a [[Field design#STORE-DEFAULT (SD) and STORE-NULL (SN) attributes\|store default]] of NONE (the default for [[Field design#AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes\|exactly one]] fields in field groups), none of the 0s would be physically stored (but would be treated as if they were).</p>

	<p>For many files, implementing field groups will improve both performance and space utilization.</p>		<p>For many files, implementing field groups will improve both performance and space utilization.</p>

JAL at 18:18, 4 April 2014

2014-04-04T18:18:27Z

← Older revision		Revision as of 18:18, 4 April 2014
Line 1:		Line 1:
	==Overview==		==Overview==
	<p>Data items do not normally exist on their own. ~~If we take~~ the case of addresses, for example, ~~there are~~ a series of fields ~~that~~ exist for each (house number, city, state, zip code) which clearly operate interdependently. </p>		<p>
			Data items do not normally exist on their own. In the case of addresses, for example, a series of fields exist for each address (house number, city, state, zip code) which clearly operate interdependently. </p>

	<p>The idea of a physical field group is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[Field group design (File management)\|Field group design]] for details.)</p>		<p>The idea of a <b>physical field group</b> is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[Field group design (File management)\|Field group design]] for details.)</p>

	<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Operations on multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>		<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Operations on multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>

ELowell: /* Overview */

2014-03-21T20:20:31Z

Overview

← Older revision		Revision as of 20:20, 21 March 2014
Line 2:		Line 2:
	<p>Data items do not normally exist on their own. If we take the case of addresses, for example, there are a series of fields that exist for each (house number, city, state, zip code) which clearly operate interdependently. </p>		<p>Data items do not normally exist on their own. If we take the case of addresses, for example, there are a series of fields that exist for each (house number, city, state, zip code) which clearly operate interdependently. </p>

	<p>The idea of a physical field group is to take these related fields and package them as a single entity so they can be read and updated with a single operation.</p>		<p>The idea of a physical field group is to take these related fields and package them as a single entity so they can be read and updated with a single operation. (See [[Field group design (File management)\|Field group design]] for details.)</p>

	<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Operations on multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>		<p>Such packaging not only improves the readability and maintainability of SOUL programs (see [[Operations on multiply occurring fields]] for the details of the SOUL statements involved), but it also makes the Model 204 processing far more efficient.</p>

Admin at 23:15, 22 January 2014

2014-01-22T23:15:16Z

Show changes

JAL: /* Field Group Identifiers */

2014-01-13T21:37:57Z

Field Group Identifiers

← Older revision		Revision as of 21:37, 13 January 2014
Line 74:		Line 74:
	<p>As mentioned above, every field group has a unique ID.</p>		<p>As mentioned above, every field group has a unique ID.</p>

	<p>This ID can be read with the [[$FIELDGROUPID ~~function~~]] and is also displayed by the <var>[[Basic SOUL statements and commands#PRINT ALL INFORMATION .28or PAI.29 statement\|Print All Iinformation]]</var> statement.</p>		<p>This ID can be read with the <var>[[$FIELDGROUPID]]</var> function and is also displayed by the <var>[[Basic SOUL statements and commands#PRINT ALL INFORMATION .28or PAI.29 statement\|Print All Iinformation]]</var> statement.</p>

	~~<p>While, by itself, the ID is just for uniqueness, there is an interesting use for it, in that you can tell the order that things happened to a file, which is invaluable in debugging.</p>~~




			<p>While, by itself, the ID is just for uniqueness, there is an interesting use for it, in that you can tell the order that things happened to a file, which is invaluable in debugging.</p>


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

Admin at 22:14, 18 December 2013

2013-12-18T22:14:40Z

← Older revision		Revision as of 22:14, 18 December 2013
Line 59:		Line 59:
	<p>Every record in a FILEORG=X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.</p>		<p>Every record in a FILEORG=X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.</p>

	<p>As is true of all FILEORG=X'100' files, the field name representations (as held in [[Table A (File ~~Architecture~~)\|Table A]] and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this might be offset by the physical absence of fields defined as part of the group.</p>		<p>As is true of all FILEORG=X'100' files, the field name representations (as held in [[Table A (File architecture)\|Table A]] and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this might be offset by the physical absence of fields defined as part of the group.</p>

	===Space saving and default and null values===		===Space saving and default and null values===