Table B (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 43: Line 43:
=== Space Management ===
=== Space Management ===


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


<p>When [[Adding Records (File Architecture)|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 parameter|BRESERVE bytes available on the page. In each of these cases, the 'next' page is used (see [[Adding Records (File Architecture)|adding records]]).</p>


== Space Management Across Pages ==
<p>Similarly, when adding fields to existing records, when it reaches a point where the new field (or fieldgroup) will not fit on the current page. When that happens, 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.</p>




=== Extension Records ===


=== Further information on Records ===
=== Further information on Records ===
Line 54: Line 55:
Refer to [[Record (File Architecture)|Records]] and [[Adding Records (File Architecture)|Adding Records]] for a full discussion of record architecture.
Refer to [[Record (File Architecture)|Records]] and [[Adding Records (File Architecture)|Adding Records]] for a full discussion of record architecture.


Refer also to [[Record Design (File management)|Record design]] for the use of Model 204 Records.
Refer also to [[Record Design (File management)|Record design]] for the best use of Model 204 Records.


=== <div id="Table B (File Architecture) Segments">Table B Segments</div> ===   
=== <div id="Table B (File Architecture) Segments">Table B Segments</div> ===   
Line 60: Line 61:
==== Definition ====
==== Definition ====


<p>As discussed below, [[Bit Maps (File Architecture)|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</p>
<p>As discussed below, [[Bit Maps (File Architecture)|bit maps]] are used in a number of ways in Model 204's processing. As bit maps can contain bits covering 49152 records (usable space of 6144 * 8) records, this number of records is called a segment</p>


==== Importance of and Use ====
==== Importance of and Use ====


<p>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). </p>
<p>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 via bit maps). </p>


==== [[INCREASE command]] boundaries ====
==== [[INCREASE command]] boundaries ====

Revision as of 00:08, 13 May 2013

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

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 parameter|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, when it reaches a point where the new field (or fieldgroup) will not fit on the current page. When that happens, 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, bit maps are used in a number of ways in Model 204's processing. 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 (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 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:

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.