Field value pairs (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
 
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==Overview==
<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#OCCURS_attribute|OCCURS attribute]].


== Overview ==
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.


<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 fieldgroup contains a series of fieldgroups and field value pairs.</p>
==STRING fields==
<p>The field value pair for <var>STRING</var> fields contains three parts: </p>
<ul>
<li>The field code from [[Table A (File architecture)|Table A]]: 3 bytes for <var>[[FILEORG parameter|FILEORG]]</var> X'100' files, or 2 bytes for all others. </li>


A record can contain field value pairs for fields with the <var>OCCURS</var> attribute, which are described [[??]].
<li>The length of the value for this pair (0 to 255): 1 byte.</li>


A record or a fieldgroup can contain non-<var>OCCURS</var> field value pairs, whose physical structure is described below, for each storage data type.
<li>The value: variable length, 0-255 bytes.</li>
</ul>


== String Fields ==
<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>


<p>The field value pair for string fields contains three parts: </p>  
==BINARY or CODED fields==
<p>
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>


* the field code from [[Table A (File Architecture)|Table A]]. This is 3 bytes for Enhanced Data Handling Files ([[FILEORG parameter|FILEORG]] x'100' files) and 2 bytes for all others.  
<p>For files that are <i>not</i> Optimized Field Extraction files (X'80), the field value pair contains two parts:</p>
* 1 byte containing the length of the value for this pair (0 to 255).
<ul>
* the value. Held in the number of bytes above.
<li>The field code from Table A: 2 bytes.
<li>The value: ''always'' held as 4 bytes.  
</ul>


<p>So, if you have a NAME field containing 'SMITH' it will be held in either 8 or 9 bytes (depending on the FILEORG), while a NAME of 'FRANKENSTEIN' will be held as either 15 or 16.</p> 
<p>For Optimized Field Extraction files, the field value pair contains three parts:</p>
<ul>
<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.


== Binary Fields ==
<li>The value: variable length, 1-4 bytes.
 
</ul>
<p>[[#Field Design (File Management)#BINARY attribute|Binary]] fields are stored (and work) differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set.</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#X'80' - Optimized Field Extraction files|X'80' - Optimized Field Extraction files]]. </p>
<p>For non Optimized Field Extraction Files the field value pair contains two parts:</p>
 
* the field code from [[Table A (File Architecture)|Table A]]. This is 2 bytes. (Enhanced Data Handling Files ([[FILEORG parameter|FILEORG]] x'100' files automatically also turn on x'80'.)
* the value which is '''always''' held as 4 bytes.  
 
 
<p>For Optimized Field Extraction Files the field value pair contains three parts:</p>
 
* the field code from [[Table A (File Architecture)|Table A]]. This is 3 bytes for Optimized Field Extraction Files ([[FILEORG parameter|FILEORG]] x'100' files) and 2 bytes for all others.
* one byte containing the length of the value (1 to 4 bytes).
* the value. Its length is as above.
 
<p>This effectively makes the BINARY field storage similar to string fields, and improves the speed with which the data in the record can be read. The possible tradeoff on performance versus space is discussed in [[#File Design (File Management) Optimized Field Extraction Files|File Design]].</p>
 
== Float Fields ==
 
<p>[[#Field Design (File Management)#FLOAT attribute|Float]] fields consist of two parts:</p>
 
* the field code from [[Table A (File Architecture)|Table A]]. This is 3 bytes for Enhanced Data Handling Files ([[FILEORG parameter|FILEORG]] x'100' files) and 2 bytes for all others. 
* the value which is '''always''' the [[#Field Design (File Management)#LENGTH attribute|LENgth]] from the field definition (4, 8 or 16 bytes).
 


==FLOAT fields==
<p>
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>For files that are <i>not</i> Optimized Field Extraction files, the field value pair contains two parts:</p>
<ul>
<li>The field code from Table A: 2 bytes.
<li>The value: ''always'' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.
</ul>


<p>For Optimized Field Extraction files, the field value pair contains three parts:</p>
<ul>
<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 value: ''always'' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.
</ul>
<p>
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.

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=Field_value_pairs_(File_architecture)&oldid=69347"