Record (File architecture)

Overview

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the Internal File Dictionary in Table A) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique internal record number that is used by the system to build index entries for the record.

For example, the following code:

IN filename STORE RECORD END STORE

Does, in fact, physically store a record. It has been assigned an Internal Record Number and would contain the pre-allocated field structure (if any), but no data.

Records. Base Records and Extension Records

The term 'record' is actually used three ways:

• the record as a full collection of all of the data about a 'thing'
• base records: the initial portion of that data
• extension records: a (possible) string of additional portions of the data

These are discussed below:

The Internal Record Number (IRN)

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the FOR RECORD NUMBER statement) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before.

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See Bit Maps for more information.

The Structure of a Model 204 Record

As shown in Table B, Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

Extension Pointer

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with a 3 byte extension record pointer.

This chains this part of the record to the next. Where that location is, is dependent on whether Table X is enabled.

Data

If there are any preallocated fields in a file (see the OCCURS attribute) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in the Record Map in Table D.

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were ADDed (which always adds the entity at the end of the record); or positioned by an INSERT statement. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

Field Value Pairs

Field Value Pairs, or, perhaps more precisely, Field Name 'Equals' Value Pairs are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

Large Objects

Large Objects Without Table E

If Table E is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code.

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes. The