Field group (File architecture)

Field groups and Table B storage considerations

Every record in a FILEORG=X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.

As is true of all FILEORG=X'100' files, the field name representation (as held in Table A and thus in the record), are three bytes in length. Depending on the definitions of the fields within the group, this may be offset by the physical absence of fields defined as part of the group.

DV and space savings

Performance

Improved record scan:
long records are read much faster, as, rather than using the length byte in the field value pair to skip to the next record, a length is held for the entire field group and so the entire group may be skipped.

Adds / inserts and deletes are a single operation:

Take the following blocks of code:

INSERT ADDRESS_TYPE(%LOC) = %ADDR:TYPE INSERT HOUSE_NUMBER(%LOC) = %ADDR:NUM INSERT STREET(%LOC) = %ADDR:STREET INSERT CITY(%LOC) = %ADDR:CITY INSERT STATE(%LOC) = %ADDR:STATE INSERT ZIP(%LOC) = %ADDR:ZIP

each of those statements are separate operations. For each one the correct position in the record must be found, and then the field inserted. This is repeated six times.

instead, with an RFG:

INSERT FIELDGROUP ADDRESS(%LOC) ADDRESS_TYPE = %ADDR:TYPE HOUSE_NUMBER = %ADDR:NUM STREET = %ADDR:STREET CITY = %ADDR:CITY STATE = %ADDR:STATE ZIP = %ADDR:ZIP END INSERT

This syntax does the entire insert as a single operation, so, only one insert position only needs to be found, and then the entire set of fields is inserted.