|
|
|
The Record Schema consists of a schema map header, followed by a number of schema field blocks, which are in turn followed by a number of schema name details. The structure of this information is provided here for your information. You will not have to create this information directly. It is prepared automatically by PutDODA().
Schema Map
A schema map is stored in the form of a map header defined by the ConvMap typedef:
typedef struct convmap {
UTEXT flavor; /* 1-68000 2-8086 3-pdp */
UTEXT align; /* 1-byte 2-word 4-dbl word 8-quad word */
UTEXT flddelm; /* field delimiter byte */
UTEXT padding; /* field padding byte */
VRLEN maplen; /* total length of map including header */
VRLEN nbrflds; /* number of fields in map */
VRLEN nbrblks; /* number of field blocks (which may be
less than nbrflds due to repeat counts */
} ConvMap;
The map header is followed by a specified number of field blocks, nbrblks, defined by the ConvBlk typedef shown below:
typedef struct convblk {
UCOUNT len; /* field length / or maximum length */
UTEXT kind; /* c-tree field type (see later) */
UTEXT repcnt; /* repeat count */
} ConvBlk;
A repcnt zero means no repeat fields; a repeat count of 1 means one more field with the same definition, etc.
Schema Name Details
Each field can be assigned a symbolic name. The names (which are not counted in the maplen parameter) associated with each field are stored consecutively in the form:
Therefore, the symbolic name “FIRST” will be stored as:
7FIRST0
If no name is associated with a field, then a single byte of value 1 is stored. For example, if the first and third fields are named “FIRST” and “THIRD” respectively, and the second field has no name, the names will be stored as:
7FIRST017THIRD0
There is a single name for each field block. If there is a non-zero repeat count, only one name is stored. There is not a name stored for each repeated field.
Record Structure
While c-tree can support virtually any organization of data fields, there are some guidelines which promote maximum support by c-tree and FairCom’s other products. We strongly recommend following these guidelines unless there are compelling reasons not to do so.
The field types described in the next section can be grouped into fixed and varying length fields. For this grouping, the fixed refers to whether or not the space occupied by the field is fixed, not whether the contents are fixed.
When defining your record structure, the varying length fields will either have a known maximum length or be unlimited (within the bounds of the length count bytes if any). For example, you may have a varying length description field that is null terminated and guaranteed not to be longer than 1024 bytes. This is a varying length field with a known maximum. Conversely, you may have a 2-byte length count field that is varying in length, but there is no specified maximum length. This is a varying length field without a known maximum. Therefore, each field can be classified into one of three groups:
We recommend that fields be placed in the record in the order shown above.
Note: Both limited and unlimited variable-length fields require the application to properly pack and unpack the record structure. See the variable-length record discussion covered in Data and Index Files for additional information on building variable-length records.
