Field value pairs (File architecture): Difference between revisions
mNo edit summary |
No edit summary |
||
(12 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
==Overview== | ==Overview== | ||
<p>The basic unit of storage inside a Model 204 record is the field value pair (or, more literally, "field = value pair"). A record or a field group contains a series of field groups and field value pairs.</p> | <p> | ||
The basic unit of storage inside a Model 204 [[Record (File architecture)|record]] is the field value pair (or, more literally, "field name = value pair," specifying the field's name and value). A record or a [[Field group design|field group]] contains a series of field groups and field value pairs.</p> | |||
A record can contain multiple field value pairs for fields with the [[Field design | A record can contain multiple field value pairs for fields with the [[Field design#OCCURS_attribute|OCCURS attribute]]. | ||
A record or a field group can contain non-<var>OCCURS</var> field value pairs, whose physical structure is described below, for each storage data type. | A record or a field group can contain non-<var>OCCURS</var> field value pairs, whose physical structure is described below, for each storage data type. | ||
Line 16: | Line 17: | ||
</ul> | </ul> | ||
<p>For example, a NAME field containing 'SMITH' | <p>For example, a <code>NAME</code> field containing <code>'SMITH'</code> occupies 8 or 9 bytes (depending on the <var>FILEORG</var> value), while a <code>NAME</code> of <code>'FRANKENSTEIN'</code> occupies 15 or 16 bytes.</p> | ||
==BINARY or CODED fields== | ==BINARY or CODED fields== | ||
<p> | <p> | ||
The storage of <var>[[Field design | The storage of <var>[[Field design#BINARY attribute|BINARY]]</var> and <var>[[Field design#CODED attribute|CODED]]</var> fields depends on whether the file has the Optimized Field Extraction (<var>FILEORG</var> X'80') bit set. </p> | ||
<p class="note"><b>Note:</b> <var>FILEORG</var> X'100' files automatically also turn on x'80'. </p> | |||
<p>For files that are <i>not</i> Optimized Field Extraction | <p>For files that are <i>not</i> Optimized Field Extraction files (X'80), the field value pair contains two parts:</p> | ||
<ul> | <ul> | ||
<li>The field code from | <li>The field code from Table A: 2 bytes. | ||
<li>The value: | <li>The value: ''always'' held as 4 bytes. | ||
</ul> | </ul> | ||
<p>For Optimized Field Extraction | <p>For Optimized Field Extraction files, the field value pair contains three parts:</p> | ||
<ul> | <ul> | ||
<li>The field code from | <li>The field code from Table A: 3 bytes for <var>FILEORG</var> X'100' files, or 2 bytes for all others. | ||
<li>The length of the value for this pair (1 to 4): 1 byte. | <li>The length of the value for this pair (1 to 4): 1 byte. | ||
Line 37: | Line 39: | ||
</ul> | </ul> | ||
<p> | <p> | ||
By storing a length with <b>all</b> field occurrences, data in records can be read much faster. The possible trade-off on performance versus space is discussed in [[File design | By storing a length with <b>all</b> field occurrences, data in records can be read much faster. The possible trade-off on performance versus space is discussed in [[File design#X'80' - Optimized Field Extraction files|X'80' - Optimized Field Extraction files]]. </p> | ||
==FLOAT fields== | ==FLOAT fields== | ||
<p> | <p> | ||
The storage of <var>[[Field design | The storage of <var>[[Field design#FLOAT attribute|FLOAT]]</var> fields depends on whether the file has the Optimized Field Extraction (<var>FILEORG</var> x'80') bit set. </p> | ||
<p class="note"><b>Note:</b> <var>FILEORG</var> X'100' files automatically also turn on x'80'. </p> | <p class="note"><b>Note:</b> <var>FILEORG</var> X'100' files automatically also turn on x'80'. </p> | ||
<p>For files that are <i>not</i> Optimized Field Extraction files, the field value pair contains two parts:</p> | <p>For files that are <i>not</i> Optimized Field Extraction files, the field value pair contains two parts:</p> | ||
<ul> | <ul> | ||
<li>The field code from | <li>The field code from Table A: 2 bytes. | ||
<li>The value: | <li>The value: ''always'' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute. | ||
</ul> | </ul> | ||
Line 56: | Line 58: | ||
<li>The length of the value for this pair (1 to 4): 1 byte. | <li>The length of the value for this pair (1 to 4): 1 byte. | ||
<li>The value: | <li>The value: ''always'' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute. | ||
</ul> | </ul> | ||
<p> | <p> | ||
By storing a length with < | By storing a length with <i>all</i> field occurrences, data in records can be read much faster. The possible trade-off on performance versus space is discussed in [[File design#X'80' - Optimized Field Extraction files|X'80' - Optimized Field Extraction files]].</p> | ||
[[Category:File architecture]] | [[Category:File architecture]] |
Latest revision as of 04:35, 10 May 2014
Overview
The basic unit of storage inside a Model 204 record is the field value pair (or, more literally, "field name = value pair," specifying the field's name and value). A record or a field group contains a series of field groups and field value pairs.
A record can contain multiple field value pairs for fields with the OCCURS attribute.
A record or a field group can contain non-OCCURS field value pairs, whose physical structure is described below, for each storage data type.
STRING fields
The field value pair for STRING fields contains three parts:
- The field code from Table A: 3 bytes for FILEORG X'100' files, or 2 bytes for all others.
- The length of the value for this pair (0 to 255): 1 byte.
- The value: variable length, 0-255 bytes.
For example, a NAME
field containing 'SMITH'
occupies 8 or 9 bytes (depending on the FILEORG value), while a NAME
of 'FRANKENSTEIN'
occupies 15 or 16 bytes.
BINARY or CODED fields
The storage of BINARY and CODED fields depends on whether the file has the Optimized Field Extraction (FILEORG X'80') bit set.
Note: FILEORG X'100' files automatically also turn on x'80'.
For files that are not Optimized Field Extraction files (X'80), the field value pair contains two parts:
- The field code from Table A: 2 bytes.
- The value: always held as 4 bytes.
For Optimized Field Extraction files, the field value pair contains three parts:
- The field code from Table A: 3 bytes for FILEORG X'100' files, or 2 bytes for all others.
- The length of the value for this pair (1 to 4): 1 byte.
- The value: variable length, 1-4 bytes.
By storing a length with all field occurrences, data in records can be read much faster. The possible trade-off on performance versus space is discussed in X'80' - Optimized Field Extraction files.
FLOAT fields
The storage of FLOAT fields depends on whether the file has the Optimized Field Extraction (FILEORG x'80') bit set.
Note: FILEORG X'100' files automatically also turn on x'80'.
For files that are not Optimized Field Extraction files, the field value pair contains two parts:
- The field code from Table A: 2 bytes.
- The value: always held as 4, 8, or 16 bytes, depending on the LENGTH attribute.
For Optimized Field Extraction files, the field value pair contains three parts:
- The field code from Table A: 3 bytes for FILEORG X'100' files, or 2 bytes for all others.
- The length of the value for this pair (1 to 4): 1 byte.
- The value: always held as 4, 8, or 16 bytes, depending on the LENGTH attribute.
By storing a length with all field occurrences, data in records can be read much faster. The possible trade-off on performance versus space is discussed in X'80' - Optimized Field Extraction files.