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 can organize these pages in a file, refer to File design (File management).

At a minimum, Table B contains all of the base records in a Model 204 file.

As of Model 204 release 7.4, Table B has a maximum number of 16.7 million record numbers (IRNs for Internal Record Numbers). As of Model 204 release 7.5, Table B has a maximum number of 48 million record numbers (if FILEORG=x'200' is set).

If Table X is not enabled, these 'slots' are used for both base records and extension records. If Table E is not enabled, then any data with contents greater than 255 bytes must be held as a series of repeating fields.

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 item in the graphic is described below.

Pointers

Free Space Pointer

The free space pointer points to the last cell in the currently allocated pointer array, which in turn points to the beginning of free space on a page, where the next record can begin. (See the above diagram.) On pages with no records yet stored, the free space pointer 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 contain, at most, records 0 to 9 (the first record in a Model 204 file is IRN 0); the second page will contain IRNs 10 to 19, and so on.

Even if all the record slots are not used, they are treated as if they were, meaning that, in the example 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

A Table B page grows from the top down (the pointers) and the bottom up (data area) simultaneously.

When adding records, there must be enough room to add all the preallocated fields on that page. Also, no new record will be added to the page if there are less than BRESERVE bytes available on the page. In each of these cases, the 'next' page is used (see adding records).

Similarly, when adding fields to existing records and the new field (or fieldgroup) will not fit on the current page, data is moved from the record into the extension record next in the chain, with, perhaps, a new extension being created at the end of the chain.

Further information on Records

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

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

Table B Segments

Definition

As discussed below, bitmaps are used in a number of ways in Model 204's processing. As bitmaps 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 (discussed below), 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 with bitmaps).

INCREASE command boundaries

When Model 204 code is compiled, one of the critical things noted 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, and other users or subsystems have the file open, you can only increase it to the next segment boundary (that is, the next multiple of 49152), and you must use the DYNAMIC option of the INCREASE command. Otherwise, you can use the INCREASE command to extend Table B beyond the current segment boundary, but this requires exclusive access to the file.

For flexibility, consider using the MAXINCBP parameter. This parameter (expressed as a percentage) is the additional number of segments reserved in compilation for growth.

See the MAXINCBP explanation in Managing file and table sizes for details.

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 bitmaps used in indexing for how segments relate to the detailed level of both types of indexes.

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) being 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.

Parameters related to the use of Table B

This table excludes the parameters used for Hash Key and Sorted files. See those topics for a full discussion of their special parameters (and distinction in meanings for some of the parameters below).

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 percentage of free space necessary to add a page to the reuse queue, over and above BRESERVE.
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.