Table B (File architecture)

This topic covers the internal architecture of a Model 204 Table B page.

For a discussion of the ways a File Manager may organize these pages in a file, please refer to File Design (File Management).

At a minimum, Table B contains all of the base records in a Model 204 file. If Table X is not enabled it also contains all extension records. If Table E is not enabled, then any data whose contents is greater than 255 bytes must be held as a series of repeating fields.

The structure of a Table B page

Not shown is a 4 byte 'Reuse Queue Page Number' for Unordered Files. If it is present, it is in the lower left hand corner ('before' (working backwards) the first record on the page).

Each of the items in the chart are described, below:

Pointers

Free Space Pointer

The free space pointer contains the location of the first byte of free space on the page (as shown in the diagram, where the last record on the page ends). On pages with no records yet stored, it points to the last byte on the page (either the very end, of just before the Reuse Queue Page Number described above).

Record Pointer Array

There are up to BRECPPG record pointers. These are not physically put onto the page until the record is being added to the file.

Up to because, (except as noted below) it is possible that, as large records are stored, there will not be room for the full number of BRECPPG on the page, and so they would not be stored.

For Enhanced Data Handling (FILEORG x'100') files, with RECRDOPT set to x'01', you will always have space for the full number of BRECPPG record pointers, as their length is included in the calculation of the BRLIMSZ parameter. They still are not present on the page until the record is stored.

Internal Record Number

The record pointer is a useful identifier of a record, and is referred to as the 'Internal Record Number' (IRN).

If, for example, BRECPPG is set to 10, the first Table B page will, at most) contain records 0 to 9 (the first record in a Model 204 file is IRN 0); the second page contains IRNs 10 to 19, and so on.

Eben if all the record slots are not used, they are treated as if they were, meaning that, in the exmple above, the second page in the file will still contain IRNs 10 to 19 even if only one record is physically present on the first page.

See $CURREC for a handy way to retrieve the IRN.

Note that the IRN is not a permanent record identifier. If the file is reorganized it is highly likely that almost all records will have a different IRN afterward.

Space Management Across Pages

Further information on Records

Refer to Records and Adding Records for a full discussion of record architecture.

Refer also to Record design for the use of Model 204 Records.

Table B Segments

Definition

As discussed below, bit maps are used in indexing. As bit maps can contain bits covering 49152 records (usable space of 6144 * 8) records, this number of records is called a segment

Importance of and Use

In addition to indexing, segments are used, when a procedure is compiled, to track the maximum number of Table B segments that the code needs to be able to handle (remember that sets of records are tracked via bit maps).

INCREASE command boundaries

When Model 204 code is compiled, one of the critical things notes is the number of segments in the file. This is necessary so that space can be reserved for found sets and other record tracking methodology.

Because of this, if you want to increase Table B, you can only do so to the next segment boundary (i.e.: the next multiple of 49152).

For flexibility, Rocket Software recommends that you consider the use of the MAXINCBP parameter. This parameter (expressed as a percentage) is the additional number of segements reserved in compilation for growth.

See the MAXINCBP parameter for a full explanation of how it works.

Use in Indexing

The segment concept is inherent to Model 204 indexing in a number of ways. Specifically:

• See Table C Segment Entries for the effect of segments in the hash index.

• See B-Tree index structure for the effect of segments in the ordered index.

• See bit maps used in indexing for how segments relate to the detailed level of both types of indexes.

The Reuse Queue

For Reuse Record Number (RRN) files (FILEORG x'04' bit set) pages with sufficient space (see the BREUSE parameter) and one or more available record slots are kept in a reuse queue.

This may happen due to records (or large numbers of fields) are deleted.

These use the 4 byte reuse queue page number to track the pages's availability.

RRN files add records to the pages from the queue before adding records to BHIGHPG.

The following Parameters relate to the Use of Table B

This table excludes the parameters used for Hash Key and Sorted Files. Please see those topics for a full discussion of their special parameters (and distinction in meanings for some of these).

Also not shown are the parameters which control the automatic increase in table size, which see.

BHIGHPG parameter	Table B highest active page. Normally the high water mark of pages used (except for Hash Key and Sorted files). Viewable only.
BQLEN parameter	The number of pages in the reuse queue. Viewable only.
BRECPPG parameter	The maximum number of record slots on a Table B page.
BRESERVE parameter	Table B Reserved space.
BREUSE parameter	The minimum amount of space necessary to add a page to the reuse queue.
BREUSED parameter	The numberof record slots reused.
BRLIMSZ parameter	Base record size maximum. Viewable only.
BSIZE parameter	The number of pages in Table B.
RECRDOPT parameter	Record storage options.