Field value pairs (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 22: Line 22:
== BINARY or CODED fields ==
== BINARY or CODED fields ==


<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.  Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. </p>
<p><var>[[Field Design (File Management)#BINARY attribute|BINARY]]</var> and <var>[[Field Design (File Management)#CODED attribute|CODED]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set.  Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. </p>


<p>For non Optimized Field Extraction Files the field value pair contains two parts:</p>
<p>For non Optimized Field Extraction Files the field value pair contains two parts:</p>
Line 35: Line 35:
* the value (variable length, 1-4 bytes).
* the value (variable length, 1-4 bytes).


<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>
<p>By storing a length will <b>all</b> field occurrences, data in records can be read muc faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].</p>


== Float Fields ==
== 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).


<p><var>[[Field Design (File Management)#FLOAT attribute|FLOAT]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set.  Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. </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]]; 2 bytes.
* the value which is '''always''' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.


<p>For Optimized Field Extraction Files the field value pair contains three parts:</p>


* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the length of the value for this pair (1 to 4); 2 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 1 byte for all others.
* the value (variable length, 1-4 bytes).


<p>By storing a length will <b>all</b> field occurrences, data in records can be read muc faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].</p>


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

Revision as of 17:36, 16 May 2013


Overview

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.

A record can contain field value pairs for fields with the OCCURS attribute, which are described ??.

A record or a fieldgroup 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; 2 bytes.
  • the length of the value for this pair (0 to 255); 2 bytes for FILEORG X'100' files or 1 byte for all others.
  • the value; variable length 0-255 bytes.

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.


BINARY or CODED fields

BINARY and CODED fields are stored differently depending on whether the file has the Optimized Field Extraction (FILEORG x'80') bit set. Note that FILEORG X'100' files automatically also turn on x'80'.

For non Optimized Field Extraction Files the field value pair contains two parts:

  • the field code from Table A; 2 bytes.
  • the value which is always held as 4 bytes.

For Optimized Field Extraction Files the field value pair contains three parts:

  • the field code from Table A; 2 bytes.
  • the length of the value for this pair (1 to 4); 2 bytes for FILEORG X'100' files or 1 byte for all others.
  • the value (variable length, 1-4 bytes).

By storing a length will all field occurrences, data in records can be read muc faster. The possible tradeoff on performance versus space is discussed in File Design.

FLOAT fields

FLOAT fields are stored differently depending on whether the file has the Optimized Field Extraction (FILEORG x'80') bit set. Note that FILEORG X'100' files automatically also turn on x'80'.

For non Optimized Field Extraction Files the field value pair contains two parts:

  • the field code from Table A; 2 bytes.
  • the value which is 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; 2 bytes.
  • the length of the value for this pair (1 to 4); 2 bytes for FILEORG X'100' files or 1 byte for all others.
  • the value (variable length, 1-4 bytes).

By storing a length will all field occurrences, data in records can be read muc faster. The possible tradeoff on performance versus space is discussed in File Design.