m204wiki - User contributions [en]

FILEORG parameter

2015-02-16T00:40:48Z

Rob: /* Description */

{{Template:FILEORG parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>File
<dt>Where set
<dd>During file creation
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204 V6.1</var> or earlier
</dl>
==Description==
The file (<var>[[Table_B_(File_architecture)|Table B]]</var>) organization.
Valid settings of FILEORG are:
<table>
<tr class="head"><th>Setting</th><th>Meaning</th></tr>
<tr><th align="right"><var>X'200'</var></th>
<td>Large file support.

Allows files to hold up to 48 M (50,331,648) records.
May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.


Available from Model 204 V7.5.</td></tr>

<tr><th align="right"><var>X'100'</var></th>
<td>Enhanced data handling files.

Enables a number of enhancements to the file structure, including support for [[Field group (File architecture)| physical field groups]]; the definition of up to 32000 fields in a file; system maintained [[Field design#Automatic fields|automatic fields]]; [[Field design#Field constraints|field constraints]] providing content validation; and improved space management of fields containing [[Field design#BLOB.2C_CLOB.2C_and_MINLOBE_attributes|large objects]]. 

FILEORG=X'100' files have a fixed overhead of 4 bytes in <var>[[Table_B_(File_architecture)|table B]]</var> for each field occurrence as opposed to 3 bytes for FILEORG=X'80' files, 3 bytes for <var>[[Field_design#STRING_attribute|string]]</var> fields, and 2 bytes for other fields in other files. In addition, FILEORG=X'100' files have a 4-byte overhead per record for a field group ID counter. This overhead is in addition to the space required for the actual values. 

Some or all of this additional overhead space can be won back when certain FILEORG=X'100' features come into play, such as FLOAT/BINARY field value compression and the use of fieldgroups to eliminate placeholder fields. However, if a file is converted to a FILEORG=X'100' file without taking advantage of fieldgroups, and the file contains no compressible FLOAT/BINARY fields (because there are no such fields, or their values are large and thus uncompressible), then an increase in Table B space requirements is likely.

FILEORG=X'100' files cannot be loaded via <var>[[FLOD_command|FLOD]]</var> or <var>[[FILELOAD_command|FILELOAD]]</var> except with a <var class="product">Fast/Reload</var> <var>Load All Information</var> (<var>LAI</var>) FLOD/FILELOAD program.

If FILEORG=X'100' is selected, the X'80' option is automatically set.

Available in Model 204 V7.5.</td></tr>

<tr><th align="right"><var>X'80'</var></th><td>Optimized field extraction files.

All nonpreallocated (non-OCCURS) fields are preceded by a field-value length byte. With a length byte on every field, even <var>[[Field_design#FLOAT_attribute|FLOAT]]</var>, <var>[[Field_design#CODED_and_NON-CODED_attributes|CODED]]</var> or <var>[[Field_design#BINARY_attribute|BINARY]]</var> fields, several instructions and one IF test are eliminated from the internal field scan loop. Having a length byte also allows some simple compression of BINARY, CODED, and FLOAT values. Files created with FILEORG=X'80' cannot be opened in Model 204 version 6.1 or earlier.


This option is automatically set if FILEORG=X'100' is selected.</td></tr>

<tr><th align="right"><var>X'40'</var></th><td>File skewing enabled.
Note: This option is obsolete and no longer recommended. </td></tr>

<tr><th align="right"><var> X'20'</var></th><td><var>[[File_design#Unordered_files_.28X.2720.27.29|Unordered]]</var> file.</td></tr>

<tr><th align="right"><var> X'08'</var></th><td>[[Hash key files|Hash key file]].</td></tr>

<tr><th align="right"><var> X'04'</var></th><td><var>[[File_design#Reuse_Record_Number_.28X.2740.27.29|Reuse record number (RRN)]]</var>.
This option can be added to any other FILEORG option. If this option is set without the hash key (X'08') or sorted (X'01') options, the unordered option (X'20') is automatically set.</td></tr>

<tr><th align="right"><var> X'02'</var></th><td>Sort or hash key required in every record.

This option can be added to the X'08' and X'01' options.</td></tr>

<tr><th align="right"><var> X'01'</var></th><td>[[Sorted files|Sorted file]].</td></tr>

<tr><th align="right"><var> X'00'</var></th><td><var>[[File_design#Entry_order_files|Entry order]]</var> file. </td></tr>
</table>

[[Category:CREATE parameters]]
[[Category:File parameters]]
[[Category:Parameters]]

FILEORG parameter

2015-02-16T00:35:07Z

Rob:

{{Template:FILEORG parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>File
<dt>Where set
<dd>During file creation
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204 V6.1</var> or earlier
</dl>
==Description==
The file (<var>[[Table_B_(File_architecture)|Table B]]</var>) organization.
Valid settings of FILEORG are:
<table>
<tr class="head"><th>Setting</th><th>Meaning</th></tr>
<tr><th align="right"><var>X'200'</var></th>
<td>Large file support.

Allows files to hold up to 48 M (50331648) records.
May not be used in sorted (<code>FILEORG X'01'</code>) nor hashed (<code>FILEORG X'08'</code>) files.


Available from Model 204 V7.5.</td></tr>

<tr><th align="right"><var>X'100'</var></th>
<td>Enhanced data handling files.

Enables a number of enhancements to the file structure, including support for [[Field group (File architecture)| physical field groups]]; the definition of up to 32000 fields in a file; system maintained [[Field design#Automatic fields|automatic fields]]; [[Field design#Field constraints|field constraints]] providing content validation; and improved space management of fields containing [[Field design#BLOB.2C_CLOB.2C_and_MINLOBE_attributes|large objects]]. 

FILEORG=X'100' files have a fixed overhead of 4 bytes in <var>[[Table_B_(File_architecture)|table B]]</var> for each field occurrence as opposed to 3 bytes for FILEORG=X'80' files, 3 bytes for <var>[[Field_design#STRING_attribute|string]]</var> fields, and 2 bytes for other fields in other files. In addition, FILEORG=X'100' files have a 4-byte overhead per record for a field group ID counter. This overhead is in addition to the space required for the actual values. 

Some or all of this additional overhead space can be won back when certain FILEORG=X'100' features come into play, such as FLOAT/BINARY field value compression and the use of fieldgroups to eliminate placeholder fields. However, if a file is converted to a FILEORG=X'100' file without taking advantage of fieldgroups, and the file contains no compressible FLOAT/BINARY fields (because there are no such fields, or their values are large and thus uncompressible), then an increase in Table B space requirements is likely.

FILEORG=X'100' files cannot be loaded via <var>[[FLOD_command|FLOD]]</var> or <var>[[FILELOAD_command|FILELOAD]]</var> except with a <var class="product">Fast/Reload</var> <var>Load All Information</var> (<var>LAI</var>) FLOD/FILELOAD program.

If FILEORG=X'100' is selected, the X'80' option is automatically set.

Available in Model 204 V7.5.</td></tr>

<tr><th align="right"><var>X'80'</var></th><td>Optimized field extraction files.

All nonpreallocated (non-OCCURS) fields are preceded by a field-value length byte. With a length byte on every field, even <var>[[Field_design#FLOAT_attribute|FLOAT]]</var>, <var>[[Field_design#CODED_and_NON-CODED_attributes|CODED]]</var> or <var>[[Field_design#BINARY_attribute|BINARY]]</var> fields, several instructions and one IF test are eliminated from the internal field scan loop. Having a length byte also allows some simple compression of BINARY, CODED, and FLOAT values. Files created with FILEORG=X'80' cannot be opened in Model 204 version 6.1 or earlier.


This option is automatically set if FILEORG=X'100' is selected.</td></tr>

<tr><th align="right"><var>X'40'</var></th><td>File skewing enabled.
Note: This option is obsolete and no longer recommended. </td></tr>

<tr><th align="right"><var> X'20'</var></th><td><var>[[File_design#Unordered_files_.28X.2720.27.29|Unordered]]</var> file.</td></tr>

<tr><th align="right"><var> X'08'</var></th><td>[[Hash key files|Hash key file]].</td></tr>

<tr><th align="right"><var> X'04'</var></th><td><var>[[File_design#Reuse_Record_Number_.28X.2740.27.29|Reuse record number (RRN)]]</var>.
This option can be added to any other FILEORG option. If this option is set without the hash key (X'08') or sorted (X'01') options, the unordered option (X'20') is automatically set.</td></tr>

<tr><th align="right"><var> X'02'</var></th><td>Sort or hash key required in every record.

This option can be added to the X'08' and X'01' options.</td></tr>

<tr><th align="right"><var> X'01'</var></th><td>[[Sorted files|Sorted file]].</td></tr>

<tr><th align="right"><var> X'00'</var></th><td><var>[[File_design#Entry_order_files|Entry order]]</var> file. </td></tr>
</table>

[[Category:CREATE parameters]]
[[Category:File parameters]]
[[Category:Parameters]]

DELETE FIELDGROUP command

2014-11-13T01:00:03Z

Rob: /* Usage notes */

==Summary==
<dl>
<dt>Privileges
<dd>File manager
<dt>Function
<dd>Deletes a field group from a <var class="product">Model 204</var> file
</dl>
==Syntax==
DELETE FIELDGROUP <var class="term">FieldGroupName</var>


Where:
<var class="term">FieldGroupName</var> is the name of a field group in the currently open <var class="product">Model 204</var> file.

==Example==
DELETE FIELDGROUP DRIVER

==Usage notes==
DELETE FIELDGROUP is available as of Model 204 Version 7.5.
You must delete all the fields that comprise a field group (except 'FG *' fields) before Model 204 can
delete the specified field group. Otherwise, the folowing message is produced: 
M204.2900: CANNOT DELETE FIELDGROUP THAT HAS FIELDS/FIELDGROUPS IN IT
[[Category: File manager commands]]
[[Category:Commands]]

Table E and FILEORG X'100' files (File architecture)

2013-07-05T10:49:01Z

Rob: /* Summary */

Holds Large Object Data (BLOBs and CLOBs)

When FILEORG x'100'is set on a file, this is enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[ESIZE parameter|ESIZE]] greater than 0, and then [[DEFINE FIELD command|defining one or more fields]] with an attribute of CLOB or BLOB (the file must have an ESIZE for the latter to occur).

Available as of Model 204 V7.5

==Summary==

Storage and manipulation of Large Objects (LOBs):

The 'chained LOBs' in Table E under [[FILEORG parameter|FILEORG]] x'100' files has a number of advantages over the way LOBs are stored and accessed in non x'100' files.
*because the LOBs no longer need to be contiguous, space monitoring is simpler and Table E is less likely to fill up.
*fields may be defined so that 'small' LOBs may be stored 'locally' in the record (and so do not use an entire page in Table E). See [[Field Design (File Management)#Using the MINLOBE attribute|the MINLOBE attribute]].
*you no longer need to predict (the RESERVE clause) the size that a LOB field may grow to.

== Storing Large Objects ==

When a field is defined as a large object (LOB) ([[Field Design (File Management)#BLOB attribute|BLOB]] or [[Field Design (File Management) #CLOB attribute|CLOB attributes]]) a pointer is stored in the record (in Tables B or X), and, depending on the [[Field Design (File Management)#MINLOBE attribute|MINLOBE attribute]] and length of the value being stored, and the LOB value is stored in its proper place, as follows:

=== Pointer in the record ===

When you store a 'not null' Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, and a pointer to the Large Object data in the Table E page, and is 27 bytes long.

This is the same as in non x'100' files.

=== Storing a Large Object ===

When the length of the value being stored is 0 (i.e.: a null string) the action taken depends on the 'repeating' type ([[Field Design (File Management)#AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes|AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes]]). This is discussed in the next section.
Other than null strings, if the value being stored is less than or equal to the [[Field Design (File Management)#MINLOBE attribute|MINLOBE attribute]] for the field, then the value is stored directly in the record (Table B or X). Note that this is in addition to the pointer described above.
If the length of the value being stored is greater than the [[Field Design (File Management)#MINLOBE attribute|MINLOBE attribute]] for the field, the value is stored in a series of pages in Table E with the first (up to) 6140 bytes (4 bytes being reserved for the chain pointer) on the first page, the next (up to) 6140 bytes on the 'next' page, and so on. These pages are not, necessarily, contiguous. Any pages emptied by LOB deletes are first reused, before the pages at [[EHIGHPG parameter|EHIGHPG]] are used. 

==== Null Strings and Large Objects ====

Unlike other field types, the [[Field Design (File Management)#STORE-DEFAULT (SD) and STORE-NULL (SN) attributes|STORE-DEFAULT (SD) and STORE-NULL (SN) attributes]] may not be set on LOB fields. This results in such fields having the equivalent to the LITeral option. The following table illustrates the results when null strings are stored in Large Object fields:

{| class="wikitable";style="width="90%
|-
! align="center" scope="col" | Attribute
! align="center" scope="col" | Explicit Null ''fieldname'' = ' '
! align="center" scope="col" | Implicit Null ''fieldname'' = %X (where %X is null)
! align="center" scope="col" | No reference in code
|-
! scope="row"| EXACTLY-ONE
| (Note 1)
| (Note 1)
| (Note 1)
|-
! scope="row"| AT-MOST-ONE
| field stored with null value
| not present
| not present
|-
! scope="row"| REPEATABLE
| field stored with null value
| not present
| not present
|}

Note 1: the field will always act as if it is physically present (and return a null). However, exactly one fields react a bit differently depending on whether they are inside a Repeating Field Group (RFG) or not. Inside an RFG, all three operations will result in a field being present (as displayed in a PAI). Outside of RFGs, (and remembering that only the CHANGE statement may be used on exactly one fields) only the 'CHANGE ''fieldname'' TO %X' syntax will physically create an occurrence on the record.

==The following Parameters and Commands relate to the Use of Table E==

'''Note:''' Pages are either used or not in Table E, so there is no formula to determine whether a page is added to the reuse queue (unlike Tables B and X). Because of this, there are no EREUSE, EREUSED, or EQLEN parameters. The size of the reuse queue can always be determined by the difference between EHIGHPG and EPGSUSED.
{|
|[[EHIGHPG parameter]]
|The highest active Table E page. (The first page in Table E is page zero.)
|-
|[[EPGSUSED parameter]]
|The number of Table E pages currently in use.
|-
|[[ESIZE parameter]]
|The number of pages in Table E
|-
|[[FILEORG parameter]]
|The file organization
|}

[[Category:File architecture]]

Field design

2013-07-05T10:48:19Z

Rob: /* BLOB, CLOB and MINLOBE attributes */

==Overview==
The field structures in <var class="product">Model 204</var> are at the heart of providing applications which perform the functions that you require in the most efficient manner possible.

This page discusses exactly how the data structures should be defined.

==Designing records, fieldgroups and fields==
When setting up a <var class="product">Model 204</var> file, you must first decide what fields the records will contain. A record in a personnel file, for instance, might contain a social security number field, a last name field, a spouse's name field, and so on. 
===Variable record formats===
The record in <var class="product">Model 204</var> is a very loose concept. Physically, it is simply a collection of fields (data items).

Any field in the [[#Table A (File Architecture) Internal File Dictionary|Table A Dictionary]] may appear in any record in the file. It is quite possible that you create a file with many different logical record types with only a few (or even none) appearing in all of the records.

Thus, each record is not required to have a value for every field; so that record lengths are variable, and it can be argued that the entire concept of a record 'format' does not apply to Model 204 files. If an employee's address is unknown or doesn't exist in a particular logical record, for example, the address field will be left out of the record altogether. The exception to this is [[#Preallocated fields|Preallocated fields]]. If they are are defined for a file, space is reserved in each record for all such fields, even if they would never exist for that logical record. 

===Multiply occurring fields===
Most types of fields can be multiply occurring, that is, have more than one value per record. For example, the CHILD field can appear no times, once, or several times in one record. 

==Field descriptions and attributes==

When you describe a field in a <var class="product">Model 204</var> file with the [[DEFINE FIELD command|DEFINE FIELD]] or [[REDEFINE command|REDEFINE FIELD]] commands, you specify a field description that consists of the field name followed by a list of field attributes. These attributes determine how a field may be accessed and how it is stored internally. This section describes the attributes supported for <var class="product">Model 204</var> fields. 

Within a record, there is usually no restriction on the number of different fields that can have the same attribute (the exception being the key fields for Sorted and Hash Key files). For example, several fields within the same record can have ORD CHAR indices built for them.

Multiply occurring fields
For most field attributes there is almost no restriction on the number of times a particular field can occur within a record. This makes file / record design very flexible. If you have a record which has child details as repeating fields or groups, for example, any number may be supported. 

Singly occurring fields
There are a few attributes which require a field to have no more than one occurrence per record:

*NUMERIC RANGE
*Sort key fields
*Hash key fields

and others which require a field to have no more than one occurrence per record or fieldgroup (depending on the context in which they are defined):

*AT-MOST-ONE
*EXACTLY-ONE

== <div id="Field Design (File Management) Indexing Fields">Indexing Fields</div> ==

Model 204 files can become quite large, and so it is almost always preferable to directly access the record or records which have particular characteristics. As part of your design process, you should have identified which field(s) are likely to be used for direct retrieval of sets of records.

For example, if you have a personnel file, you are likely to have a unique identifier for each employee, and it is also likely that you will often want to process only the record or records with that ID.

Where retrievals are attempted against non indexed fields, a search of Table B must be done, and the danger of request cancellation because [[MBSCAN parameter|MBSCAN]] is exceeded exists.

Model 204 supports a few different ways to implement these direct searches, and the recommended default choice for indexing is the ORDERED attribute.

===ORDERED and NON-ORDERED attributes===
Fields used in retrieval specifications should normally be defined as ORDERED (unless one of the other indexing methods, described below) is chosen. NON-ORDERED, the default, means that all retrieval requests need to scan the records directly in Table B to find the selected records.

For the architectural approach to the implementation of the ordered index, refer to: [[Table D (File Architecture)#Understanding the Ordered Index|understanding the Ordered Index]].

====Choosing an order type====
An ORDERED field can have an index with either CHARACTER or NUMERIC ordering. This is called its order type. The field's order type and updating characteristics are declared with the DEFINE command. You can specify only one order type for a field. ORDERED NUMERIC fields contain numeric values stored as standardized floating-point numbers in one section of the index and non-numeric values in EBCDIC order in another section. 
ORDERED CHARACTER fields
ORDERED CHARACTER fields use the standard EBCDIC collating sequence. If a field is ORDERED CHARACTER, all values of the field are stored in the Ordered Index in EBCDIC collating sequence order.
ORDERED NUMERIC fields
A string field value is considered NUMERIC if it consists of digits, with one optional decimal point, and an optional plus or minus sign at the beginning of the string. The value of the number cannot be greater than 10 to the power 75 or less than 10 to the power -75. 
If an ORDERED NUMERIC field is also FLOAT, exponential format is allowed. Values for BINARY, FLOAT (8), and FLOAT (16) fields are rounded to 15 significant digits. Values for FLOAT (4) fields are rounded to 6 significant digits. 
An invalid value is stored as an unconverted string. 
In ORDERED NUMERIC fields, leading zeros are ignored. For example, 001 and 1 are considered equivalent and are maintained in the ORDERED NUMERIC portion of the B-Tree as the same value. For fields that require a meaningful leading zero (such as zip code), use ORDERED CHARACTER.
Values of an ORDERED NUMERIC field that do not satisfy the definition of NUMERIC are stored in a separate section of the Ordered Index and processed in EBCDIC order. During FOR EACH VALUE and FOR EACH RECORD IN ORDER BY FIELD processing of an ORDERED NUMERIC field, these values are processed after the valid NUMERIC values unless you restrict the range of values. 
Default order types
If a field is defined as ORDERED without specifying which type of ordering to create, a default order type is used. The default depends on whether the field is STRING, BINARY, or FLOAT:
<table>
<tr>
<th>For...</th>
<th>The default order type is...</th>
</tr>
<tr>
<td>STRING</td>
<td>ORDERED CHARACTER</td>
</tr>
<tr>
<td>BINARY or FLOAT</td>
<td>ORDERED NUMERIC </td>
</tr>
</table>

====ORDERED field definition====
The ORDERED attribute has options that allow you to determine the type of ordering the Ordered Index is to have, as well as some of the characteristics of the Ordered Index tree as it expands or is rebuilt. These options are described in the discussions of order type and Ordered Index tree structure that follow.
Defining ORDERED field attributes
The [[DEFINE command]] is used to specify a field's attributes. The format of the DEFINE command with the ORDERED attribute options is:
Syntax
DEFINE FIELD <var class="term">fieldname</var> WITH <var>ORD</var>ERED
[<var>CHAR</var>ACTER | <var>NUM</var>ERIC][<var>SPL</var>I<var>T</var>PCT <var class="term">s</var>] [IMMED <var class="term">i</var>]
[<var>LRES</var>ERVE <var class="term">r</var>] [<var>NRES</var>ERVE <var class="term">n</var>]

Note
The default designation for a field is NON-ORDERED. Ordered Index tree parameters do not apply for a NON-ORDERED field. 
<var>CHARACTER</var> and <var>NUMERIC</var> order types are described above.
<var>SPLITPCT</var>, <var>IMMED</var>, <var>LRESERVE</var>, and <var>NRESERVE</var> parameters are described in [[Table D (File Architecture)#Ordered Index spacing parameters|Ordered Index spacing parameters]]. 
Choosing between ORDERED or NUMERIC RANGE
The ORDERED attribute has several advantages over the NUMERIC RANGE attribute, and as such should be the normal choice. Specifically: 
<ul>
<li>Ordered Index allows for multiple occurrences of the same numeric field in a record. The NUMERIC RANGE attribute issues an error message whenever an attempt is made to store more than one occurrence of the same NUMERIC RANGE field in the same record.</li>
<li>Cost of updating an ORDERED field is lower than that of a NUMERIC RANGE field. The NUMERIC RANGE field requires multiple attributes to be maintained to describe the characteristic of a number. The cost of an update to the Ordered Index is always proportional to the depth of the tree.</li>
<li>In most cases, especially with large numbers, the Ordered Index uses less space to maintain the index information.</li>
<li>Ordered Index allows for more accurate range requests, with numbers representable by IBM double-word floating-point numbers.
Although range retrievals are usually faster for ORDERED fields than for NUMERIC RANGE fields, the size of the range interval and the density of the distribution of values over that range are the principal determining factors. NUMERIC RANGE retrievals are faster for very large ranges with densely distributed data values. 
</li>
</ul>

====Choosing between ORDERED or FRV====
The ORDERED attribute is usually a better alternative to the FRV attribute. Although FRV fields with small numbers of values may perform faster in value loop processing, they lose this advantage if the found values are required to be in order, and as the number of values increase. FRV ordered retrievals require additional sorting. For retrievals in ascending or descending order, ORDERED fields are more efficient. For (presumably rare) right-adjusted character strings in order, ORDERED fields require additional sorting.
Compatibility ORDERED with other field attributes
Use the following guidelines when specifying the ORDERED attribute:
<ul>
<li>A field cannot be both ORDERED and FRV.</li>
<li>A field cannot be both ORDERED NUMERIC and NUMERIC RANGE.</li>
<li>A field can be both KEY and ORDERED (but serves little or no purpose).</li>
<li>A field can be both INVISIBLE and ORDERED.</li>
<li>A field can be both DEFERRABLE and ORDERED. If the field is DEFERRABLE, the index updates can be written out to a (see [[#DEFERRABLE and NON-DEFERRABLE attributes|DEFERRABLE and NON-DEFERRABLE attributes]] for details). </li>
<li>UNIQUE field must be ORDERED. </li>
<li>Hash and sort key fields and record security fields can be ORDERED.</li>
<li>Fields which are defined as KEY may be converted to ORD with no code changes required (as direct retrievals will work with either type of ORD field).</li>
</ul>

For an architectural view of the ordered index, see [[#Table D (File Architecture) Ordered Index|the Ordered Index]]

===KEY and NON-KEY attributes===
The KEY and NON-KEY attributes govern whether to create a hash index for a field or not. If KEY is specified, an index is created for the field. Retrieval commands will access the index for that field. If NON-KEY is specified, every record in the table is examined. The NON-KEY attribute is a default field description. This section provides information about space and performance for each of these attributes.
KEY attribute
When storing fields that have the KEY attribute, <var class="product">Model 204</var> makes special entries in the hash index. During retrieval, <var class="product">Model 204</var> goes directly to the appropriate index entry to find which records satisfy the selection criteria, without searching through other records in the file. This makes retrieval based on KEY fields extremely fast. 
However, these index entries must be updated, when User Language statements or Host Language Interface functions add, change, or delete fields. Processing might take slightly longer for KEY fields than for NON-KEY fields. In addition, the space occupied by the index entries can be considerable, especially in large files and in fields that take on many values. 
NON-KEY attribute
No index entries are maintained in Tables C and D for NON-KEY fields. When a retrieval is performed based on the value of NON-KEY fields, the data in Table B must be searched directly. The direct search can have a significantly adverse effect on performance, if a large number of records must be searched. 
However, the cost of the direct search can be greatly reduced in some cases where both KEY and NON-KEY fields are specified in the retrieval conditions. <var class="product">Model 204</var> reduces the number of records to be searched directly by performing the indexed selection first. Records that are definitely eliminated, based on the KEY conditions, are not searched directly. 
Choosing between KEY or NON-KEY
Keep the following guidelines in mind when deciding to designate a field as KEY or NON-KEY:
<ul>
<li>If space is not an overriding consideration, designate fields that are used frequently for retrievals of equality as KEY.</li>
<li>If a field is updated frequently and only occasionally used for retrieval, define it as NON-KEY.</li>
<li>If a field is used frequently for retrievals and updated frequently, the choice is less obvious. If you reserve sufficient space in Tables C and D for adding inversion entries, the field initially can be defined as NON-KEY and changed later with the [[REDEFINE command]]. </li>
</ul>

===FOR EACH VALUE (FRV) and NON-FRV attributes===
The FRV attribute is useful when creating fields used in value loop processing. If the FRV attribute is not specified when a field is defined, the NON-FRV attribute is assumed. If this attribute is set, the field is usually assigned the KEY attribute as well. 

Table space for FRV fields
Every value of an FRV field is automatically encoded in Table A, whether or not the value is stored in Table B (that is, INVISIBLE). In addition to more Table A space, FRV fields require slightly more Table C and Table D space than ordinary key fields. Because of these additional space requirements, the FRV attribute is most frequently defined for fields in which the number of different values does not exceed approximately 200.
Using the FRV attribute
The FRV attribute behaves in a special way when combined with the BINARY attribute. This is discussed in [[#BINARY attribute|BINARY attribute]].
Fields cannot be defined with the FRV attribute in [[Field_Attributes#File_model_feature|First-Normal Form (1NF)]] files.
==== FRV attribute, FRV User Language Statement ====
Value loops
User Language provides a special construction called a value loop that executes a set of statements once for each different value of an indicated field. The loop is initiated by the FOR EACH VALUE statement; the field must have the FRV or ORDERED attribute. The FOR EACH VALUE statement has Host Language equivalents in IFFDV and IFGETV. A value loop is illustrated in the following example:
Example
EACH.STATE:
FOR EACH VALUE OF STATE
GET.RECS:
FIND ALL RECORDS FOR WHICH
STATE = VALUE IN EACH.STATE
END FIND
TOT.RECS:
COUNT RECORDS IN GET.RECS
PRINT.CT:
PRINT VALUE IN EACH.STATE -
WITH COUNT IN TOT.RECS AT COLUMN 20
END FOR

On the first pass through the loop, a value of STATE, such as DELAWARE, is selected. The last statement prints DELAWARE and the number of records with the field-name-equals-value pair: STATE = DELAWARE. On the next pass, another value is chosen, such as IOWA, and so on until all values of the STATE field have been processed exactly once.
Using the IN ORDER option
The IN ORDER option of the FOR EACH VALUE statement specifies that the values of an FRV KEY field be presented in an ordered sequence-ascending, descending, numerical, right adjusted. This option improves performance by avoiding Online sorts of a large number of records, because only the values are sorted instead of a large found set of records. 
Value loop processing for ORDERED fields
You can also use value loop processing on fields with the ORDERED attribute. When the FOR EACH VALUE statement with the IN ORDER option is used for NON-FRV, ORDERED fields, ORDERED retrievals can be significantly faster than FRV ordered retrievals. See [[#ORDERED and NON-ORDERED attributes|ORDERED and NON-ORDERED attributes]] for a description of the ORDERED attribute. 
Value loop processing can be made more flexible and efficient by using pattern matching, described in the <var class="product">Model 204</var> User Language Manual.

===NUMERIC RANGE and NON-RANGE attributes===
Prior to the introduction of ORDered NUMeric fields, Model 204 permitted range retrieval (a field value numerically equal to, less than, greater than, or between certain values) with the NUMERIC RANGE attribute. This attribute indexes the component parts of a numeric value and then joins them, to provide rapid numeric range retrievals without a direct search of the records.
If the NUMERIC RANGE attribute is not specified when a field is defined, the NON-RANGE attribute is assumed. 

It is recommended that, for any new fields being defined,the ORDERED NUMERIC attribute is used in preference to NUMERIC RANGE.

The NUMERIC RANGE attribute may not be set where the product of [[ASTRPPG parameter|ASTRPPG]] * [[ATRPG parameter|ATRPG]] is greater than 4000 (available in [[FILEORG parameter|FILEORG]] x'100' files).
====NUMERIC RANGE retrieval specifications====
The following retrieval specifications, with their symbolic operator equivalents in parentheses, can be used:
fieldname IS value
fieldname IS EQ (=) value
fieldname IS LESS THAN (LT or <) value
fieldname IS GREATER THAN (GT or >) value
fieldname IS BETWEEN (GT or >) value AND (LT or <) value
fieldname IS GREATER THAN (GT or >) value AND LESS THAN (LT or <) value
fieldname IS LESS THAN (LT or <) value AND GREATER THAN (GT or >) value

====Examples====
The following examples show numeric retrieval specifications:
ALL:
FIND ALL RECORDS FOR WHICH AMOUNT IS 53.00
DATE IS BETWEEN 050500 AND 050532
END FIND

These specifications retrieve records for which AMOUNT has a value of 53.00 (or 53 or 053, and so on) and DATE has a value in May 2005.
====NUMERIC RANGE retrieval fields====
The values of NUMERIC RANGE retrieval fields can be either positive or negative numbers that have as many as ten digits on either side of the decimal point (20 digits maximum). When such fields are stored, <var class="product">Model 204</var> makes many entries in Tables C and D as well as some special entries in the field name (attribute) section of [[Table A (File Architecture)|Table A]]. These entries are quite complex, and NUMERIC RANGE retrieval fields require both more storage space and more time to store and update than do KEY fields. 
In deciding whether to define a field as NUMERIC RANGE or NON-RANGE (and NON-ORDERED), use the same criteria used in [[#Choosing between KEY or NON-KEY|Choosing between KEY or NON-KEY]], keeping in mind the additional overhead caused by the extra index entries for RANGE fields.

====Interpreting nonnumeric values====
If a NUMERIC RANGE field is stored with a value that <var class="product">Model 204</var> cannot interpret as a number, the system stores a special index entry for the record. The field name of this special entry consists of the NUMERIC RANGE retrieval field name with ++ appended. The entry has a value of NON NUMERICAL. Thus, the following User Language retrieval retrieves all records with nonnumerical values of AGE:
ALL:
FIND ALL RECORDS FOR WHICH
AGE++ = NON NUMERICAL
END FIND

This can be useful in locating bad input data.
====Compatibility with other attributes====
You can specify as many NUMERIC RANGE retrieval fields in each record as you need. However, a particular NUMERIC RANGE retrieval field may not be multiply occurring within any one record.
You cannot specify the NUMERIC RANGE attribute in the following circumstances:
<ul>
<li>With any field defined as FLOAT</li>
<li>For any field in a 1NF file</li>
</ul>
For a chart showing valid and invalid attribute combinations, see [[ Field Attribute Combinations#Combining attributes|Combining attributes]]. If you are defining field attributes with FILEMGMT, you will not be allowed to specify incompatible attributes.

== Data Typing ==

The following attributes are described individually in the next sections. They represent the way the field is physically stored. Only one of these may be assigned to any field.
<ul>
<li>STRING</li>
<li>BINARY</li>
<li>BLOB, CLOB, MINLOBE</li>
<li>FLOAT</li>
<li>DATETIME</li>
<li>UTF-8 or UTF-16</li>
<li>VISIBLE, INVISIBLE</li>
</ul>

===STRING attribute===
STRING is the default attribute for all fields. If your data is character or alphanumeric, such as names and addresses, specify a data type of STRING. STRING fields are also useful if you plan to store mixed data types in an image. 
The length of a STRING field is limited to 255 bytes, because the first byte of a STRING data field is a count byte-that is, a byte that contains the length of the rest of the string. 

===BINARY attribute===
Fields whose values are numeric integers can alternatively be compressed and stored as 4-byte binary numbers with the BINARY attribute. Specifying BINARY saves Table B space if the average value of the field is from 4-9 digits long.
Acceptable BINARY values
To be compressed successfully, the value must be1-9 digits long and can contain a minus sign. It cannot contain a plus sign, a decimal point, or leading zeros. If the value cannot be compressed, <var class="product">Model 204</var> refers to the CODED/NON-CODED field attribute (which the BINARY attribute usually overrides) to decide how to store the value. 
BINARY and FRV fields
The BINARY attribute overrides the FRV attribute, except for values that cannot be compressed. If the field cannot be compressed, it will be stored in Table A in either the FEW-VALUED or MANY-VALUED pages depending on the field definition. For instance, AGE has been defined with the BINARY and FRV attributes and takes on the values:
23, 04, -34578, 935., 20,
+8754, and TWO

The statement FOR EACH VALUE OF AGE retrieves only the values:
04, 935., +8754 and TWO

If BINARY is not specified when a field is defined, the STRING attribute is assumed.
BINARY fields and NUMERIC VALIDATION files
If a BINARY field is defined in a NUMERIC VALIDATION file model file ( [[FILEMODL parameter|FILEMODL]] = x'01' ), <var class="product">Model 204</var> provides numeric data type validation. If you try to store non-numeric or other non-conforming (that is, non-compressible) data in a BINARY field in a NUMERIC VALIDATION file, <var class="product">Model 204</var> cancels the request with the following message:
M204.2123: VALUE SPECIFIED VIOLATES BINARY DATA TYPE VALIDATION IN RECORD <var class="term">recno</var>, FIELD IGNORED: <var class="term">fieldname</var> = <var class="term">value</var>

<div id="BLOB attribute"></div>
<div id="CLOB attribute"></div>
<div id="MINLOBE attribute"></div>

===BLOB, CLOB and MINLOBE attributes===
Note: The MINLOBE attribute is available as of Model 204 version 7.5.
The BLOB and CLOB attributes describe Large Object data that may be used to store long strings in the database, for example, long XML strings. This means that <var class="product">Model 204</var> User Language threads can exchange Large Object data with a partner process by way of the Universal Buffer and/or the MQ/204 Interface. 
<ul>
<li>With the Universal Buffer, Large Object data can be sent and received using User Language READ IMAGE and WRITE IMAGE statements, of $SOCKET READ and WRITE calls.</li>
<li>With the MQ/204 Interface, Large Object data can be sent and received by MQPUT and MQGET statements, stored and retrieved from the database with User Language STORE, ADD, and assignment statements using the BUFFER reserved area name.</li>
</ul>
Files created in V6R1.0 and later are not compatible with earlier versions of <var class="product">Model 204</var>, because of Large Object support and the concomitant changes to the FPL page.
Introducing Large Object field types
The Large Object field types includes the following Character Large Object (CLOB) and Binary Large Object (BLOB) attributes. 
<ul>
<li>CLOBs are character strings. </li>
<li>BLOBs are binary strings. No translation is performed when the object is sent or received.</li>
</ul>
Limitations of Large Object support
<ul>
<li>Currently there is a limit of 2,147,483,647 bytes (or two gigabytes) of data per Large Object.</li>
<li>For CLOBs the translation of ASCII to EBCDIC and back is handled by the design of your application.</li>
<li>For BLOBs no translation is performed.</li>
<li>The User Language INSERT statement is not supported.</li>
</ul>
Handling Large Object data
The BLOB and CLOB attributes are supported as follows:
<ul>
<li>You can create, open, and recover a file with a BLOB or CLOB attribute. The Large Object field can be multiply occurring. </li>
<li>The DELETE fieldname statement supports the Large Object data. This statement frees the Table B and Table E data.</li>
<li>You can store and add a Large Object data to the file you have created from the Universal Buffer, BUFFER. Using an assignment statement you can transfer Large Object data from a field into the Universal Buffer.</li>
<li>You can set the number of Table E pages during file creation with PARAMETER ESIZE= n.</li>
<li>You can view the EHIGHPG parameter to determine the highest number of Table E pages in use.</li>
<li>You can modify the size of Table E with an INCREASE or DECREASE command.</li>
<li>The DELETE FIELD fieldname command supports the Large Object field type, so you can delete a Large Object field name. However, the space in Table B and Table E is not automatically available for reuse. </li>
<li>[[$LOBLEN|$LOBLEN]](lob-field-name) function is available for your use.</li>
<li>Dictionary/204 and the Cross-Reference facility support Large Object field types.</li>
<li>NULL Large Object data is supported.</li>
<li>Transaction back out is supported for Large Object field types.</li>
<li>Field-level security is supported.</li>
</ul>
BLOB and CLOB compatibility with other attributes
Combining BLOB or CLOB with other field attributes, except OCCURS, AT-MOST-ONE, LEVEL, UPDATE IN PLACE, UPDATE AT END, MINLOBE, or UTF-8, is meaningless. Use of any other attributes produces the following message:
M204.0411: CONFLICTING ATTRIBUTES: ([BLOB | CLOB]) <var class="term">attribute2</var>

<div id="Using the MINLOBE attribute">Using the MINLOBE (MLBE) attribute</div>
You can use the MINLOBE attribute only with a BINARY LARGE OBJECT (BLOB) or a CHARACTER LARGE OBJECT (CLOB) field in a file with FILEORG X'100'. The MINLOBE attribute cannot be paired with the OCCURS attribute. You can redefine the MINLOBE attribute value.
Syntax
MINLOBE <var class="term">nnn</var>

The default and smallest value for MINLOBE is 0, which means that all values of the field are stored in TABLEE. The maximum value of MINLOBE is 200.
If a field has the MINLOBE attribute greater than 0:
<ul>
<li>And the value of the field is not longer than MINLOBE, then the value is stored in Table B or Table X, instead of Table E.</li>
<li>The User Language CHANGE statement is not allowed and the following error is displayed:
M204.2869 CHANGE NOT ALLOWED: MINLOBE > 0 FOR FIELD <var class="term">fieldname</var>

Any CHARACTER LARGE OBJECT or BINARY LARGE OBJECT field which does not use the CHANGE statement benefits from setting MINLOBE 200.
</li>
<li>The RESERVE clause is ignored on the User Language ADD statement.</li>
</ul>
Storing and updating LOBs
All large object data (LOBs) in a FILEORG=X'100' file are chained. There are four bytes per Table E page overhead for chained LOBs. The pages used by a chained LOB are not contiguous.
Handling LOBs in FILEORG=X'100' files also has the following effects:
<ul>
<li>The RESERVE clause is ignored in a LOB field ADD statement processing, as well as the STORE RECORD statement processing of fieldname=value pairs.
Consequently, the CHANGE statement does not fail because of insufficient reserved space. If the CHANGE statement requires that a LOB field be extended, it is.
</li>
<li>The value of the [[EHIGHPG parameter|EHIGHPG]] parameter is always one less than the high water mark of the number of pages used to hold LOBs. (Unless none were ever added, in which case it is zero, not -1).</li>
<li>The value of the [[EPGSUSED parameter|EPGSUSED]] parameter is always the number of pages currently being used to hold LOBs.</li>
<li>The [[COMPACTE command|COMPACTE]] command does not process FILEORG=X'100' files, just as it does not process a file created in V6R1 or earlier. Thus, issuing a COMPACTE command for a FILEORG X'100' file produces an error message.</li>
<li>The [[TABLEE command|TABLEE]] command effectively does a [[VIEW command|VIEW]] ESIZE EHIGHPG EPGSUSED for a FILEORG X'100' file. Consequently there are no TABLEE overhead pages in a FILEORG=x'100' file.</li>
</ul>

===FLOAT attribute===
Any field whose values are always, or almost always, numeric might be more efficiently stored in a floating-point representation than in character form. Using FLOAT can also reduce the time spent in data type conversions for fields used frequently in User Language or Host Language Interface computations. 
Very large or very small numbers, or numbers with many significant digits, occupy considerably less space in floating-point form. 
Floating-point fields are fully supported by User Language, the Host Language Interface, and the File Load utility. For more information about storing values in floating-point fields, such as conversion, rounding, and precision rules, see the <var class="book">Rocket Model 204 User Language Manual</var>.
Note
If FLOAT is not specified when a field is defined, the STRING attribute is assumed.
Defining floating point fields
Field values are stored in floating-point by specifying the FLOAT attribute in the DEFINE FIELD command and supplying a LENGTH of 4, 8, or 16. The length supplied determines the precision of the floating-point field being defined. For example, to define a long precision field, specify:
Syntax
DEFINE FIELD <var class="term">fieldname</var> WITH FLOAT LEN 8

You can define three types of floating point fields through the FLOAT and LENGTH attributes.:
<table>
<tr>
<th>
Type of floating-point field</th>
<th>

Occupies...</th>
<th>
Holds a maximum of...</th>
<th><var class="product">Model 204</var> maintains a maximum precision of...</th>
</tr>
<tr>
<td>Short precision</td>
<td>4 bytes</td>
<td> 6 significant digits</td>
<td> </td>
</tr>
<tr>
<td>Long precision</td>
<td>8 bytes</td>
<td>15 significant digits </td>
<td>15 significant digits</td>
</tr>
<tr>
<td>Extended precision</td>
<td>16 bytes </td>
<td>31 significant digits</td>
<td>15 significant digits </td>
</tr>
</table>
Acceptable values
The floating-point data type uses IBM hardware's floating-point representation.
A value of negative zero (X'800...0') cannot be stored in a preallocated FLOAT field. 
FLOAT with NUMERIC VALIDATION files
If you define a FLOAT field in a NUMERIC VALIDATION file model file ( [[FILEMODL parameter|FILEMODL]]=x'01' ), <var class="product">Model 204</var> provides numeric data type validation. Trying to store non-conforming data in a FLOAT field in a NUMERIC VALIDATION file causes <var class="product">Model 204</var> to cancel the request with the following message:
M204.2124: VALUE SPECIFIED VIOLATES FLOAT DATA TYPE VALIDATION IN RECORD <var class="term">recno</var>, FIELD IGNORED: <var class="term">fieldname</var> = <var class="term">value</var>

Compatibility with other attributes
STRING, BINARY, NUMERIC RANGE, and INVISIBLE cannot be specified for a FLOAT field. 

===Storing invalid numeric data: FLOAT or ORDERED NUMERIC===
The valid range of floating point numbers is:
1E-74 through 7.2370E+75

Model 204 enforces storage rules for floating point numbers outside the valid range:
<ul>
<li>If 7.2371E75 is stored in a FLOAT field, the value is treated as an invalid floating point number and is stored as a data string '7.2371E75'.</li>
<li>1E-75 is treated as an invalid floating point number and stored as a data string '1E-75'.</li>
</ul>
If an invalid value is stored for a field with the ORDERED NUMERIC attributes, the value stored in the Ordered Index is the data string. That data string is stored on the Invalid Numeric Data portion of the Ordered Index. This changes the output order of these values when the ordering is done against the Ordered Index, for example, when using the User Language IN ORDER BY or FOR EACH VALUE clauses.

===DATETIME (DT) attribute===
The DATETIME attributes specifies the format of the stored data in Table B, not its function. The other date/time attributes are automatically updated fields generated at the time of record or field group creation or update. A non-automatic field can have a DATETIME format, but all the automatic date/time fields are stored in DATETIME format. The DATETIME attribute requires at least eight significant digits. 
Once you define a DATETIME value for a field, you cannot redefine the DATETIME value.

===UTF-8 and UTF-16 attributes===
Note 
The UTF-8 and UTF-16 attributes are available as of Model 204 version 7.5.
The UTF-8 attribute indicates that data is stored in [http://en.wikipedia.org/wiki/UTF-8 UTF-8] format and is treated as [[Unicode|unicode]] data inside SOUL programs. A UTF-8 field can be defined as follows:
DEFINE FIELD UTFDATA WITH [UTF-8 | UTF8]

DEFINE FIELD UTFBLOB WITH BLOB [UTF-8 | UTF8]

The UTF-16 attribute indicates that data is stored in [http://en.wikipedia.org/wiki/UTF-16 UTF-16] format and is treated as [[Unicode|unicode]] data inside SOUL programs. A UTF-16 field can be defined as follows:
DEFINE FIELD UTFDATA WITH [UTF-16 | UTF16]

DEFINE FIELD UTFBLOB WITH BLOB [UTF-16 | UTF16]

Usage notes
<ul>
<li>Since UTF-8 or UTF-16 fields behave like unicode variables in SOUL requests printing fields with unicode characters that cannot be converted to displayable EBCDIC results in those characters being [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Character_reference_overview character-entity encoded], just as they are encoded when printing unicode variables. This is also true when printing is done via a [[Basic User Language Statements and Commands#PRINT_ALL_INFORMATION_.28or_PAI.29_statement|PAI]] statement. For example, a UTF-8 field containing the unicode value of "I like apple π" would be printed as "I like apple &#x03C0;". The & symbol is always encoded as &amp; when printed.</li>
<li>Just as with unicode variables, assigning an EBCDIC value to a unicode field results in the EBCDIC value being converted to unicode and then to UTF-8 or UTF-16 for storage. Simlarly, assigning a UTF-8 or UTF16 field to an EBCDIC variable results in the UTF-8 or UTF-16 value being converted to unicode and then translated to EBCDIC. In either EBCDIC to unicode or unicode to EBCDIC translation, errors result in request cancellation.
<li>Unless the preponderance of data stored in UTF-8 or UTF-16 fields has unicode values greater than U+07FF (most likely if most of the data contains Asian language characters), UTF-8 is a better choice for storing unicode data, since UTF-16 requires two bytes for every unicode character while UTF-8 only requires one byte for many common characters and only two bytes for unicode characters up to U+07FF.</li>
<li>UTF-8 and UTF-16 fields can be LOB fields or they can be STRING fields (stored in table B).</li>
<li>If a UTF-8 or UTF-16 field is defined as an OCCURS field, the length indicates the length in bytes, not the length in characters. Since UTF-8 encoding can use anywhere from one to three bytes to represent a single unicode character in the [http://en.wikipedia.org/wiki/Unicode_plane#Basic_Multilingual_Plane BMP], the only unicode characters supported by SOUL, it can be tricky using UTF-8 fields as OCCURS fields since setting the defined length requires an educated guess about the types of unicode characters that will be store in the field or (probably) oversizing a UTF-8 field to three bytes per character. In the latter case, it would make much more sense to define such a field as UTF-16 as that requires exactly two bytes for each character.</li>
</ul>


===VISIBLE and INVISIBLE attributes===
In general, you want to be able to retrieve, and then display or print fields, or use the field values in a report. These are fields that you want defined as VISIBLE.
If, however, you have a field that is used only to retrieve records, and space is a consideration, you may want to define the field as INVISIBLE.
Note
If the INVISIBLE attribute is not specified when the field is defined, the VISIBLE attribute is assumed. 
Using the VISIBLE attribute
Once an application retrieves a record with a User Language FIND statement or a Host Language IFFIND call, it generally processes one or more fields in User Language PRINT, NOTE, or SORT statements, arithmetic expressions, or Host Language IFGET calls. For example:
CHECK.SALARY:
IF SALARY GT 1000*AGE
THEN PRINT NAME
END IF

A field referred to by the PRINT statement must have the VISIBLE attribute in its field description. This means that the field-name-equals-value pair is actually stored in the logical record in Table B.
Using the INVISIBLE attribute
A field that has the INVISIBLE attribute, on the other hand, takes up no storage space in Table B and cannot be printed, noted, or sorted. These fields can be added, deleted, or changed in the logical record.
Choosing the INVISIBLE attribute: In a library catalog file, for example, each record can have an AUTHOR field that contains the author's full name. In addition, there can be a LAST NAME field that contains only the author's last name. This creates a convenient index to the catalog and relieves the user of the burden of knowing the entire name when making retrieval requests. Because the author's last name already is part of the (VISIBLE) AUTHOR field, some space can be saved in Table B by selecting the INVISIBLE attribute for LAST NAME.
Reorganizing INVISIBLE fields
Because INVISIBLE fields are not stored in Table B, they require special care if the file is ever reorganized. When designing a file, be sure to take reorganization requirements for these fields into consideration. See [[File_Reorganization_and_Table_Compaction#Reorganizing_INVISIBLE_fields|Reorganizing INVISIBLE fields]] for more information. 
Maintaining INVISIBLE fields
INVISIBLE fields must also have the KEY, NUMERIC RANGE, or ORDERED attribute, and they are normally used only to retrieve records. 
The User Language FILE RECORDS statement and the Host Language Interface IFFILE function can be used to rapidly add an INVISIBLE KEY field name = value pair to an entire set of records. For example:
ALL.RECS: FIND ALL RECORDS FOR WHICH
NAME = SMITH OR SMYTHE OR SMYTH
END FIND
FILE: FILE RECORDS IN ALL.RECS UNDER HOMONYM = SMYTH

<var class="product">Model 204</var> makes entries in Tables C and D to allow retrievals with the specification HOMONYM = SMYTH but does not change Table B. For further information about adding, changing, or deleting INVISIBLE fields, see the <var class="product">Model 204</var> User Language Manual.
Table B considerations
The values of VISIBLE fields can be stored in the logical record in Table B in one of four formats depending upon the selection of STRING/BINARY, CODED/NON-CODED, or FLOAT field attributes. The choice affects space requirements and, except for a slight increase in the time required for updates and some types of retrievals (see [[#CODED and NON-CODED attributes|CODED and NON-CODED attributes]]), is transparent to the user. 
The values of fields that have the INVISIBLE attribute are not stored in Table B, and physical storage attributes cannot be specified in their descriptions. 
Using INVISIBLE fields in 1NF files
The First-Normal form relational model cannot be enforced for INVISIBLE fields. However, INVISIBLE fields are useful within <var class="product">Model 204</var> for list processing and to support SQL multicolumn keys (see the <var class="product">Model 204</var> SQL Server User's Guide for more information). Therefore, the INVISIBLE field attribute is allowed, but INVISIBLE fields are not mapped to SQL-accessible columns. The following rules and restrictions apply to INVISIBLE fields in 1NF files:
<ul>
<li>Because the INVISIBLE and AT-MOST-ONE attribute are incompatible, INVISIBLE fields must be defined as REPEATABLE.</li>
<li>You cannot REDEFINE a field as INVISIBLE within a 1NF file; the INVISIBLE and REPEATABLE attributes can be specified only with a DEFINE command. In the case of a record security key field, use the INITIALIZE command to specify the field as INVISIBLE and REPEATABLE.</li>
<li>INVISIBLE fields in 1NF files must also be ORDERED or KEY (NUMERIC RANGE is not legal in a 1NF file and results in an error message). </li>
</ul>
Compatibility with other attributes
The INVISIBLE attribute cannot be specified for a field defined with the FLOAT or AT-MOST-ONE attributes.

== Data Content ==

In addition to the data type (above), there are additional attributes which further control how the data is stored and manipulated:
<ul>
<li>CODED, NON-CODED </li>
<li>OCCURS</li>
<li>LENGTH</li>
<li>PAD</li>
<li>FEW-VALUED, MANY-VALUED </li>
<li>UPDATE IN PLACE, UPDATE AT END</li>
<li>DEFAULT-VALUE</li>
<li>STORE-DEFAULT, STORE-NULL</li>
<li>AT-MOST-ONE, REPEATABLE and EXACTLY-ONE</li>
<li>DEFERRABLE/NON-DEFERRABLE</li>
</ul>

===CODED and NON-CODED attributes===
The CODED and NON-CODED attributes let you choose between saving disk space (with CODED) or speeding up update and retrieval time (with NON-CODED). This section discusses how these attributes work.
Note
If the CODED attribute is not specified when a field is defined, the NON-CODED attribute is assumed.
NON-CODED attribute
If a field is designated NON-CODED without an OCCURS clause (see the following discussion), its value is stored in Table B as a simple character string that has an additional byte to indicate its length. 
NON-CODED is the best choice for any field whose values have an average length of 1-3 bytes whether or not they are compressible numbers.
CODED attribute
Choose the CODED option to save Table B space where the values of the field are not suitable for BINARY compression and where their average length is four or more characters.
When a value that has the CODED attribute is defined, the character string is stored in Table A-the internal file dictionary-and a 4-byte value code pointing to that character string is stored in the logical record in Table B. Space is saved when there are several records that contain the same value. The string is stored only once in Table A, and only the 4-byte code is stored in each of the several records in Table B.
Choosing CODED vs. NON-CODED
The coding and decoding of these value codes takes time, which can slow down updates and retrievals. If speed is important and if disk space is relatively plentiful, do not choose the CODED attribute.
If disk space is somewhat tight, choose the CODED attribute for fields where the values are long and where there are a small number of values relative to the number of records in the file. A STATE field is a prime example.
A more precise rule governing the choice of the CODED attribute is difficult to arrive at since first it must be determined (based on the number and length of the field values, and on the number of records) if any disk space is actually saved by the CODED attribute. Then, any space saved must be weighed against the extra time taken by CODED retrievals. And the relative importance of disk space and time are likely to vary with the application as well as with the installation.
The formulas in [[File size calculation]] show more explicitly the effects of the CODED field attribute on Table A and B size.
Using the $CODE and $DECODE functions
Field value encoding is entirely transparent to the user. Data is returned exactly as it was entered. Codes are system-generated, internal codes that have no meaning to a user. If access to both user codes and their translations is needed, use the User Language $CODE and $DECODE functions in the <var class="book">Rocket Model 204 User Language Manual</var>. 

===Preallocated fields===
Any VISIBLE field can be a preallocated field. However, a VISIBLE field that appears a fixed number of times in most of the records in a file is most suited for preallocation in Table B. Preallocated fields, if selected appropriately, require less Table B space than other fields and can be updated and retrieved slightly faster. 
Preallocation means that space is reserved in each new record added to a file. As occurrences of preallocated fields are stored in a record, they are placed in the reserved space. Space is used even for occurrences that have not been stored, whereas non-preallocated fields use no space for missing occurrences. Preallocation also imposes restrictions on the number and length of values that can be stored in a record. A field is preallocated if its description includes an OCCURS clause. 
[[File size calculation]] provides specific rules for the amount of space used by preallocated and non-preallocated fields. Use these rules to determine whether or not to preallocate a particular field. 
Using an OCCURS clause
A field is preallocated if its description includes an OCCURS clause. The OCCURS clause indicates the number of occurrences of the field that are preallocated or reserved in each Table B record. From 1 to 255 occurrences can be specified. Any number of values, up to the specified limit, <var class="term">n</var>, can be stored in the record.
Only as many occurrences as have been stored can be retrieved. Space allocated for unstored values is wasted. 
If OCCURS is not included in a field description, the field still can occur more than once in a record. Space for the occurrences is not preallocated. There is no limit to the number of values that can be stored for a non-preallocated field.
Restrictions for preallocated fields
The OCCURS option can be specified only for fields that can be preallocated with a fixed length in Table B. This includes only fields that are defined as CODED, BINARY, or LENGTH <var class="term">m</var> (see [[#LENGTH and PAD clauses|LENGTH and PAD clauses]]). If a field is defined as BINARY but does not contain an OCCURS clause, values that cannot be compressed to a binary representation still can be stored in the field. If a field is defined as both BINARY and OCCURS, only compressible values can be stored in it. 
<var class="product">Model 204</var> does not allow incompressible values to be stored in such fields. To avoid such compression problems, include CODED with BINARY and OCCURS in the field description. 
Displaying the set of preallocated fields
The [[DISPLAY RECORD command]] will show all of the preallocated fields in a file. This information is stored on a page in [[Table D (File Architecture)|Table D]] where it is used to create the preallocated field space at the beginning of a record when it is initially stored. 
Note
Because <var class="product">Model 204</var> cannot distinguish values padded with X'00' from zero-length values explicitly stored in the file, <var class="product">Model 204</var> does not allow zero-length values to be explicitly stored in preallocated fields. 

===LENGTH and PAD clauses===
Using the LENGTH clause
Use the LENGTH clause to specify the length of FLOAT fields, as well as NON-CODED preallocated (OCCURS) string fields. 
LENGTH must be specified for NON-CODED preallocated string fields: the LENGTH must be included in the description of a NON-CODED preallocated string field to set the maximum length of the field. The length must be in the range 1 through 255. The specified length is preallocated for the number of occurrence specified by the OCCURS clause. 
LENGTH with FLOAT fields: LENGTH is required with FLOAT to indicate the precision of the floating-point field being defined. The LENGTH options in this instance are 4, 8, or 16. (See [[#FLOAT attribute|FLOAT attribute]].)
Specifying the LENGTH clause: The LENGTH clause limits the length of values that can be stored in the field. <var class="product">Model 204</var> does not store values that are longer than the specified length. The LENGTH clause does not impose any minimum length. Values that are shorter than the specified length are padded with the PAD character to the maximum length as they are stored in Table B and are returned to their original length as they are retrieved. See the description of padding in [[#LENGTH and PAD clauses|LENGTH and PAD clauses]]. 
Field occurrences that have been preallocated but not stored contain zero-length values. 
Using the PAD clause
You can include a PAD clause in a field description to select the character that is used to pad field values that are shorter than the length specified in the LENGTH clause (see [[#LENGTH and PAD clauses|LENGTH and PAD clauses]]) for the field. If no PAD character is specified in a field description, the default character, X'00', is used.
Padding characters are invisible to the user and are not included in a retrieved value. Make sure that the padding character does not appear as part of a field value. If it does, incorrect results can occur.

===FEW-VALUED and MANY-VALUED attributes===
If a field that has the CODED or FRV attribute is expected to take on fewer than about 50 different values, choose the FEW-VALUED attribute. Otherwise, define the field as MANY-VALUED. 
This option determines whether the value string is stored in the FEW-VALUED or MANY-VALUED section of Table A, and is invalid for fields that are neither CODED nor FRV. Keep the number of values stored in the FEW-VALUED section small to ensure that this section is kept in core during retrieval and update operations. This practice reduces the number of disk accesses and increases retrieval speed. 
Note
If the FEW-VALUED attribute is not specified when a field is defined, the MANY-VALUED attribute is assumed.
===UPDATE IN PLACE and UPDATE AT END attributes===
<var class="product">Model 204</var> provides the following field attributes that control the way that the value of a field occurrence is changed in Table B:
<table>
<tr>
<th>
If this attribute is specified...</th>
<th>Then a change in the value of a field
occurrence...</th>
</tr>
<tr>
<td>UPDATE IN PLACE </td>
<td>
Does not change its position relative to other occurrences of the same field in Table B.
This attribute is the default.
</td>
</tr>
<tr>
<td>UPDATE AT END</td>
<td>Is accomplished by deleting the existing occurrence and adding a new one following the others. </td>
</tr>
</table>
Choosing an update option
Specify either of these options as part of a field description. The UPDATE AT END approach can be useful in certain data aging applications: for example, in applications in which the first occurrence of a field represents the oldest update to the file, and the last occurrence is the most recent update. UPDATE IN PLACE generally is more efficient.
The choice of update option determines the position of a field occurrence within a record only in relation to other occurrences of the same field. The ordering of different fields within a record is determined by a variety of factors, of which the update method is only one. The order of fields within a record normally is not under the control of the file manager.
User Language update statements other than CHANGE are not affected by the choice of an update option. The ADD and STORE statements always cause values to be added as the last occurrences in a record. The DELETE statement always removes the deleted value while maintaining the relative ordering of the remaining occurrences. 
Compatibility with other attributes
The values of fields that have the INVISIBLE attribute are not stored in Table B, and UPDATE IN PLACE or UPDATE AT END cannot be specified in their descriptions. 
===DEFAULT-VALUE (DV) attribute===
The DEFAULT-VALUE attribute is available as of Model 204 version 7.5.
A field defined with a DEFAULT-VALUE (DV) attribute value must also be defined with the EXACTLY-ONE or the AT-MOST-ONE attribute. It specifies the value of the field if the value is not explicitly added in the STORE RECORD, ADD FIELDGROUP, or INSERT FIELDGROUP initial data block. 
The value of the STORE-DEFAULT setting determines whether the DEFAULT-VALUE is physically stored on the record or if it is just used as the default value when the field is missing.
The DEFAULT-VALUE attribute allows values up to 31 bytes. An attempt to use more results in:
M204.2851: DEFAULT-VALUE VALUE
'1234567890123456789012345678901234567890' TOO BIG, -
MUST BE <32 BYTES

The value of DEFAULT-VALUE is not constrained by attributes such as LEQ, LLE, and LGE.

For example, the entire default value is returned for a field that has been added, even if it exceeds the LEQ setting.


===STORE-DEFAULT (SD) and STORE-NULL (SN) attributes===
The STORE-DEFAULT and STORE-NULL attributes are available as of Model 204 version 7.5.
You can redefine the STORE-DEFAULT and/or STORE-NULL attribute values.
The STORE-DEFAULT and STORE-NULL attributes offer these options:
<ul>
<li>LITERAL (the default)</li>
<li>NONE</li>
<li>ALL</li>
</ul>
Consider the following example that shows how a DEFAULT-VALUE is handled when the field is defined with the different STORE-DEFAULT types of ALL, NONE, and LITERAL. 
Here we are defining field NAME_SD_NONE with the STORE-DEFAULT option of NONE, field NAME_SD_LIT with the STORE-DEFAULT option of LITERAL and field NAME_SD_ALL with the STORE-DEFAULT option of ALL. The DEFAULT-VALUE for all of the fields is 'NONAME'. 
In this example, the fields belong to a field group but the STORE-DEFAULT (and STORE-NULL) attribute can also be assigned to a field that is not part of a field group. The only requirement is that the field may not be defined as REPEATABLE, that is, it must be either AT-MOST-ONE or EXACTLY-ONE.
DEFINE FIELDGROUP X
DEFINE FIELD NAME_SD_NONE WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-DEFAULT NONE DEFAULT-VALUE 'NONAME'

DEFINE FIELD NAME_SD_LIT WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-DEFAULT LITERAL DEFAULT-VALUE 'NONAME'

DEFINE FIELD NAME_SD_ALL WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-DEFAULT ALL DEFAULT-VALUE 'NONAME'

There are basically two ways to store a field in a record. It can be stored: 
- using a literal:
STORE RECORD
FIELD.A = 'ABC'
END STORE

- or by using a variable:
%X = 'ABC'
STORE RECORD
FIELD.A = %X
END STORE

Additionally, a field may simply be missing (in the following example, the record has a FIELD.B but FIELD.A is missing):
STORE RECORD
FIELD.B = 'XXX'
END STORE

The STORE-DEFAULT options determines how the field will be physically stored if the DEFAULT-VALUE is stored in the field. 
This example shows what is physically stored in the record when the DEFAULT-VALUE is stored for each of these fields. The DEFAULT-VALUE in this case is 'NONAME'. First, we will add the actual DEFAULT-VALUE of 'NONAME' by using a variable, then by using the literal 'NONAME,' and finally we will add a field group occurrence where the field is missing. 
ADD.X: SUBROUTINE
IN FILEX FRN %CURREC
* add first field group occurrence using the -variable %NAME:
%NAME='NONAME'
ADD FIELDGROUP X
NAME_SD_NONE = %NAME
NAME_SD_LIT = %NAME
NAME_SD_ALL = %NAME
END ADD
* add second field group occurrence using the - literal 'NONAME':
ADD FIELDGROUP X
NAME_SD_NONE = 'NONAME'
NAME_SD_LIT = 'NONAME'
NAME_SD_ALL = 'NONAME'
END ADD
* add third occurrence of the field group with all -
values missing:
ADD FIELDGROUP X
* none of these fields added to this occurrence
END ADD
END FOR

Subsequent PAI of the field group shows what is physically stored on the record. 
<table>
<tr>
<th>The field defined with... </th>
<th>is...</th>
</tr>
<tr>
<td>STORE-DEFAULT NONE </td>
<td>Never stored on the record. </td>
</tr>
<tr>
<td>STORE-DEFAULT ALL </td>
<td>Always stored on the record. </td>
</tr>
<tr>
<td>STORE-DEFAULT LITERAL </td>
<td>Not stored in the first occurrence, because a %variable was used. It was stored in the second occurrence, because the field was added using a literal string.</td>
</tr>
</table>
\X = 1
NAME_SD_ALL = NONAME
/X = 1
\X = 2
NAME_SD_LIT = NONAME
NAME_SD_ALL = NONAME
/X = 2
\X = 3
/X = 3

Note that when the record above is printed the DEFAULT-VALUE is printed regardless of whether the field is physically stored on the record or not. 
FR
PRINT '# NAME_SD_NONE: NAME_SD_LIT: NAME_SD_ALL:'
FEO:
FEO FIELDGROUP X
PRINT OCCURRENCE IN FEO AND NAME_SD_NONE AND -
NAME_SD_LIT AT 16 AND NAME_SD_ALL AT 30
END FOR
END FOR

NAME_SD_NONE: NAME_SD_LIT: NAME_SD_ALL:
NONAME NONAME NONAME
NONAME NONAME NONAME
NONAME NONAME NONAME

Note: The same behavior occurs whether the field is AT-MOST-ONE or EXACTLY-ONE. However, a PAI of an EXACTLY-ONE field always shows a value. The actual physical storage on the record is the same. 
The options on the STORE-NULL attribute react similarly. When the fields are defined as follows:
DEFINE FIELDGROUP X
DEFINE FIELD NAME_SN_NONE WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-NULL NONE
DEFINE FIELD NAME_SN_LIT WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-NULL LITERAL
DEFINE FIELD NAME_SN_ALL WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-NULL ALL

And code used to store the field groups is:
 IN FILEX FRN %CURREC
* add first occurrence using the variable %NAME:
%NAME=''
ADD FIELDGROUP X
NAME_SN_NONE = %NAME
NAME_SN_LIT = %NAME
NAME_SN_ALL = %NAME
END ADD
* add second occurrence using the literal '':
ADD FIELDGROUP X
NAME_SN_NONE = ''
NAME_SN_LIT = ''
NAME_SN_ALL = ''
END ADD
* add third occurrence with missing values:
ADD FIELDGROUP X
END ADD
END FOR

The resulting PAI appears as follows:
\X = 1
NAME_SN_ALL =
/X = 1
\X = 2
NAME_SN_LIT =
NAME_SN_ALL =
/X = 2
\X = 3
/X = 3

BEGIN
FR
PRINT '# NAME_SN_NONE: NAME_SN_LIT: NAME_SN_ALL:'
FEO:
FEO FIELDGROUP X
PRINT OCCURRENCE IN FEO AND -
NAME_SN_NONE AND NAME_SN_LIT AT 16 -
AND NAME_SN_ALL AT 30
END FOR
END FOR
END

Results in the following: nulls are shown for each field.
# NAME_SN_NONE: NAME_SN_LIT: NAME_SN_ALL:
1
2
3


===AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes===
You can use the AT-MOST-ONE, REPEATABLE, and EXACTLY-ONE attributes, which are mutually exclusive, to define an individual field or a field that is part of a field group definition. 
Note: The EXACTLY-ONE attribute is available as of Model 204 version 7.5.
====Using the AT-MOST-ONE attribute====
The AT-MOST-ONE attribute allows you to ensure that there is only one occurrence of a field in any record, without preallocating space for the field. 
In addition, the AT-MOST-ONE attribute is required for fields in First-Normal Form (1NF) files. AT-MOST-ONE and REPEATABLE fields in 1NF files are discussed in this section.
Note
In non-1NF files, if the AT-MOST-ONE attribute is not specified when a field is defined, the REPEATABLE attribute is assumed. 
If a field is defined with the AT-MOST-ONE attribute, <var class="product">Model 204</var> prevents multiple occurrences of that field in any given record. The AT-MOST-ONE attribute is useful if, for example, you know that there will be one variable-length field per record, or if you have a field that is often left blank but does not have more than one value per record (such as SPOUSE NAME). 
Unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated. The AT-MOST-ONE attribute lets you store these kinds of records without wasting the space required by OCCURS.
Using the REPEATABLE attribute
If a field is not defined as AT-MOST-ONE, then it is REPEATABLE. Fields with the REPEATABLE attribute can accept multiple occurrences of the field in the record. Unlike the OCCURS attribute, REPEATABLE does not preallocate fields, nor does REPEATABLE let you specify the number of occurrences of the field.
====Using the EXACTLY-ONE (EXONE) attribute====
As the name suggests an EXACTLY-ONE attribute in a field definition means that the field always has exactly one occurrence in its record or field group context after the initial data block for the record or field group (STORE RECORD, ADD FIELDGROUP, or INSERT FIELDGROUP). If no explicit value is stored for the field, its value has either the DEFAULT-VALUE for the field or the null string (' '), if no DEFAULT-VALUE was specified for the field.
You cannot add, insert, or delete an EXACTLY-ONE field, although you can change an EXACTLY-ONE field. 
The EXACTLY-ONE attribute is not allowed when both the DEFAULT-VALUE and STORE-NULL NONE attributes are specified.
====EXACTLY-ONE fields with a field group====
The EXACTLY-ONE attribute for a field within a field group means that the field can occur only once inside a single field group occurrence. However, since field groups can occur multiple times in a field group record, an EXACTLY-ONE field inside a field group can occur multiple times inside a field group record. 
====Defaults for AT-MOST-ONE, REPEATABLE and EXACTLY- ONE fields====
REPEATABLE is the default except for 1NF files, where AT-MOST-ONE is required on all fields, except INVISIBLE. See [[#VISIBLE and INVISIBLE attributes|VISIBLE and INVISIBLE attributes]] for information. 
The AT-MOST-ONE attribute is required on all fields in a 1NF file because multiply occurring fields violate relational First-Normal Form. The one exception to this rule is for INVISIBLE/REPEATABLE fields in 1NF files. See [[Field_Design_(File_Management)#AT-MOST-ONE_in_First_Normal_Form_.281NF.29_files|AT-MOST-ONE in First Normal Form files]] for more information.
The EXACTLY-ONE attribute is the default frequency of occurrence for a field defined within a field group.

====Enforcing AT-MOST-ONE constraints====
<var class="product">Model 204</var> ensures that AT-MOST-ONE field constraints are not violated for the following User Language requests and the Host Language and FLOD counterparts: 
<ul>
<li>ADD</li>
<li>INSERT</li>
<li>STORE RECORD</li>
</ul>
Before the indexes are updated and a new field is added or inserted into the <var class="product">Model 204</var> record, all existing fields in the record are checked to ensure that the new field does not create a second occurrence: 
<ul>
<li>If a new field violates the AT-MOST-ONE rules, and there is no ON FCC unit, the request is canceled with the following error message:
M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD <var class="term">recordnumber</var>, FIELD IGNORED: <var class="term">fieldname</var>=<var class="term">value</var>
</li>
<li><var class="product">Model 204</var> validates a field if you REDEFINE it to be AT-MOST-ONE.</li>
<li>If a violation occurs and there is an ON FCC unit, <var class="product">Model 204</var> processes the ON unit. </li>
</ul>
In the Host Language Interface, the 202 return code is passed back to <var class="product">Model 204</var>; in FLOD, the file is marked logically inconsistent. However, <var class="product">Model 204</var> does not cancel the request in either case. 
====AT-MOST-ONE and transaction back out files====
Transaction back out must be active for files when defining AT-MOST-ONE fields. If you try to define an AT-MOST-ONE field in a non-TBO file, the DEFINE fails and you receive an error message. 
Once the field is defined, you can turn Transaction back out off in non-1NF files. However, <var class="product">Model 204</var> customer support strongly recommends that you keep Transaction back out set in files containing fields that can cause constraint conflicts (currently AT-MOST-ONE and UNIQUE). If you turn Transaction back out off in a file with an AT-MOST-ONE or UNIQUE field, <var class="product">Model 204</var> sends you a warning message and a "Do You Really Want To?" prompt.
====Using FLOD or FILELOAD with AT-MOST-ONE fields====
When you use FLOD or FILELOAD to load or modify records that have AT-MOST-ONE fields, <var class="product">Model 204</var> ensures that the new or modified records do not violate AT-MOST-ONE constraints. <var class="product">Model 204</var> detects and reports all violations of AT-MOST-ONE in one pass of the input data. If <var class="product">Model 204</var> finds any fields that violate the constraints, the following occurs:
<ol>
<li>The error is reported and the new or duplicate field is rejected.</li>
<li>FLOD continues processing the input data.</li>
<li>At the end of the run, the file is marked "logically inconsistent;" that is, the FISTAT parameter is set to X'40'. See See Logically inconsistent files for more information.</li>
<li>The following error message is issued for each violation:
M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD <var class="term">recordnumber</var>, FIELD IGNORED: <var class="term">fieldname</var>=<var class="term">value</var>
</li>
</ol>

====AT-MOST-ONE in First Normal Form (1NF) files====
Using OCCURS 1 in 1NF files: For 1NF files, where AT-MOST-ONE is required, use OCCURS 1 to save processing time if you are storing a large number of records in which the field is always exactly the same length (such as a Social Security Number). 
INVISIBLE fields in 1NF files: The First-Normal form relational model cannot be enforced for INVISIBLE fields. However, they are useful within <var class="product">Model 204</var> for list processing and to support SQL multicolumn keys. (See the <var class="product">Model 204</var> SQL Server User's Guide for more information.) Therefore, the INVISIBLE field attribute is allowed, but INVISIBLE fields are not mapped to SQL-accessible columns. The following rules and restrictions apply to INVISIBLE fields in 1NF files:
<ul>
<li>Because the INVISIBLE and AT-MOST-ONE attributes are incompatible, INVISIBLE fields must be defined as REPEATABLE.</li>
<li>You cannot REDEFINE a field as INVISIBLE within a 1NF file; you can specify the INVISIBLE and REPEATABLE attributes only with a DEFINE command. In the case of a record security key field, specify the field as INVISIBLE and REPEATABLE using the INITIALIZE command.</li>
<li>INVISIBLE fields in 1NF files must also be ORDERED or KEY. NUMERIC RANGE is not legal in a 1NF file and results in an error message)</li>
</ul>
====Defining AT-MOST-ONE and REPEATABLE fields in non-1NF files====
You can DEFINE or REDEFINE a field to be AT-MOST-ONE in any non-1NF <var class="product">Model 204</var> file created after Release 9.0. 
When redefining a field to AT-MOST-ONE that does not currently have the OCCCURS 1 attribute, <var class="product">Model 204</var> scans Table B to verify that no multiple occurrences of the field exist in any record. If any field violates the AT-MOST-ONE constraints, the REDEFINE fails and the following error message is displayed for each violation:
M204.2122: AT-MOST-ONE CONSTRAINT VIOLATION FOR FIELD <var class="term">fieldname</var> IN RECORD <var class="term">recordnumber</var>

====Using the AT-MOST-ONE or the OCCURS 1 attribute====
Although both the AT-MOST-ONE and OCCURS 1 attributes prevent more than one occurrence of a field in a record, they achieve their goal in different ways. For non-1NF files, use either the AT-MOST-ONE or the OCCURS 1 attribute. Using both causes redundant processing. Understanding the advantages of each may help you decide which attribute you want to use. 
AT-MOST-ONE attribute:
<ul>
<li>Does not preallocate the field. Therefore, if the field values between records are of very different lengths or if you do not know the length of the longest record, use AT-MOST-ONE.</li>
<li>Allows you to correct violations before the record is stored with the ON FCC unit. If you do not use an ON FCC unit, then a constraint violation cancels the request. Therefore, if it is important to allow users to correct violations, or it is important that the request not be canceled, use AT-MOST-ONE.</li>
</ul>
OCCURS 1 attribute:
<ul>
<li>Preallocates space for the field in every record. If you are storing a large number of records and the length of the value is generally the same, pre-allocating the field with OCCURS 1 can save you processing time. </li>
<li>Cancels the request when a violation occurs. With OCCURS 1, you cannot use an ON FCC unit to correct violations. </li>
</ul>
====Compatibility with other field attributes====
AT-MOST-ONE is not compatible with the following field attributes:
<ul>
<li>INVISIBLE</li>
<li>OCCURS greater than 1</li>
<li>REPEATABLE
REPEATABLE is compatible with all field attributes except AT-MOST-ONE.
</li>
</ul>

===Coordinating AT-MOST-ONE and UNIQUE attributes===
Both AT-MOST-ONE and UNIQUE are examples of field-level constraints. Although the function of the UNIQUE and AT-MOST-ONE attributes appear similar, their actual operations differ:
<table>
<tr>
<th>This attribute</th>
<th>Affects...</th>
</tr>
<tr>
<td>UNIQUE</td>
<td>Value of the field</td>
</tr>
<tr>
<td>AT-MOST-ONE</td>
<td>Number of fields per record</td>
</tr>
</table>
For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE:
<table>
<tr>
<th>This attribute</th>
<th>Ensures that...</th>
</tr>
<tr>
<td>UNIQUE</td>
<td>Social security number for every employee is different.</td>
</tr>
<tr>
<td>AT-MOST-ONE</td>
<td>Each employee has only one social security number. </td>
</tr>
</table>
Coordinating the use of the AT-MOST-ONE and the UNIQUE attributes increases the integrity and accuracy of your records.

===DEFERRABLE and NON-DEFERRABLE attributes===
The DEFERRABLE and NON-DEFERRABLE attributes let you specify whether the updates to the index (Tables C and D) for a KEY ORDERED field can be deferred; that is, stored or updated at a later time.
The DEFERRABLE attribute is recommended and is the default.
Note
If the NON-DEFERRABLE attribute is not specified when a field is defined, the DEFERRABLE attribute is assumed.
====Choosing between DEFERRABLE and NON-DEFERRABLE====
Under normal circumstances, the storing and updating of records in the <var class="product">Model 204</var> file is done all at once. That is, Tables B, C, D, E, and X are changed simultaneously. When there is a high volume of updates (for example, a Batch2 process adding large numbers of records), efficiency and space reductions can be gained by deferring the updates to Tables C and D.
Under some circumstances, it may be necessary to override this deferral of updates to the index for particular fields. For instance, consider a situation in which new records are added Online to a personnel file. You might be willing to wait a day for the ability to retrieve the new records. The updates to Tables C and D are deferred until a batch processing window (and the application of deferred updates does require exclusive access to the file), when they are done in a batch run. However, when adding new records, you want to ensure that a record containing a duplicate Social Security number (for example) is not added to the file. 
You can define the Social Security number field as NON-DEFFERABLE and write a procedure to retrieve any records already in the file that have the new Social Security number and display an error message if one is found. If updates to the index on this field have been deferred, you would not find a duplicate added earlier in the same day. By selecting the NON-DEFERRABLE attribute for the Social Security number field, you can ensure that Tables C and D are updated immediately. 
Note
To provide immediate updating in BATCH204 runs, special action must be taken. See "Overriding deferred updates" for more information.
You can also detect duplicate Social Security numbers by defining the field with the UNIQUE and ORDERED attributes. See [[#UNIQUE and NON-UNIQUE attributes|UNIQUE and NON-UNIQUE attributes]].

====Compatibility with other attributes====
The DEFERRABLE/NON-DEFERRABLE attribute is invalid for a field that has these attributes: BLOB, CLOB, NON-KEY, NON-ORDERED, and NON-RANGE. 
For a chart showing valid and invalid attribute combinations, see [[ Field Attribute Combinations#Combining attributes|Combining attributes]]. If you are defining field attributes with FILEMGMT, you will not be allowed to specify incompatible attributes. 

<div id="Field Constraints">
== Field and Content Constraints ==

You may set up constraints to prevent 'invalid' updates to the file. The updates may be invalid because to permit them would violate rules about the field (a second occurrence to an AT-MOST-ONE field, for example). Or you may set up 'content' constraints to prevent values outside of those permitted to be stored.

=== Field Constraints ===

==== ON FIELD CONSTRAINT CONFLICT (ON FCC) unit ====

(should probably be mentioned only as a link to UL page)

To help control processing with UNIQUE and AT-MOST-ONE fields, use the User Language ON FCC unit. ON FCC is invoked whenever a field-level constraint conflict, such as an attempt to add a second occurrence of an AT-MOST-ONE field.
An ON FCC unit is used with a number of $functions that can help you determine exactly where the field constraint conflict has occurred. The $UPDSTAT function is discussed below. All other $functions for ON FCC are discussed in the <var class="product">Model 204</var> User Language Manual.
$UPDSTAT function
The $UPDSTAT function is used in conjunction with the ON FIELD CONSTRAINT CONFLICT unit and field attributes which have field-level constraints of UNIQUE and AT-MOST-ONE. You <var class="term">must</var> use $UPDSTAT in the ON FCC unit when writing procedures for files that have (or might have in the future) more than one type of field-level constraint defined.
If $UPDSTAT is invoked from an ON FCC unit following the detection of a field-level constraint conflict, it returns a numeric value denoting the type of conflict that has occurred:
<table>
<tr>
<th>Value</th>
<th>Meaning </th>
</tr>
<tr>
<td align="right">0 </td>
<td>No violation occurred</td>
</tr>
<tr>
<td align="right">1 </td>
<td>Uniqueness violation occurred</td>
</tr>
<tr>
<td align="right">2 </td>
<td>AT-MOST-ONE violation occurred </td>
</tr>
</table>
The $UPDSTAT function takes no arguments. 
See information about the [[#AT-MOST-ONE and REPEATABLE attributes|AT-MOST-ONE and REPEATABLE attributes]].
UNIQUE and ORDERED fields
Because <var class="product">Model 204</var> uses the Ordered Index to process UNIQUE values, fields defined as UNIQUE must also be defined as ORDERED. For more information about the Ordered Index see [[#ORDERED and NON-ORDERED attributes|ORDERED and NON-ORDERED attributes]].

====UNIQUE and NON-UNIQUE attributes====
Defining a field with the UNIQUE attribute allows <var class="product">Model 204</var> to ensure that a given field name = value pair occurs only once in a file. A Social Security number field is one example that might benefit from having the UNIQUE attribute. The UNIQUE attribute specifies that there can be only one occurrence of a field in the file. Multiple occurrences are not allowed.
When storing a field specified as UNIQUE, <var class="product">Model 204</var> first queries the Ordered Index, looking for an identical field-name-equals-value pair. If it finds an identical value, <var class="product">Model 204</var> issues an error message and does not perform the update. This is true both within a record for multiply occurring fields and between records.
If there is not a uniqueness conflict, that is, if the field-name-equals-value pair being stored is unique, <var class="product">Model 204</var> completes the update.
Note
If the UNIQUE attribute is not specified when a field is defined, the NON-UNIQUE attribute is assumed. 

Unique values in multiply occurring fields
In a multiply-occurring field, <var class="product">Model 204</var> ensures that each occurrence of the field is unique. 
Deleting UNIQUE fields
Because UNIQUE values use the Ordered Index, do not use the DELETE ALL RECORDS statement for deleting records. Use DELETE RECORD instead.
Compatibility with other attributes
A field can only be specified as UNIQUE with the following restrictions:
<ul>
<li>UNIQUE fields must be specified as ORDERED.</li>
<li>UNIQUE fields cannot be specified as DEFERRABLE.</li>
<li>UNIQUE fields cannot be defined in non-TBO (Transaction back out) files. </li>
</ul>
If you attempt to define a UNIQUE key under any of these circumstances, you receive an error message and the field is not defined.

====Defining a LEVEL clause====
To secure a field against unauthorized access, include a LEVEL clause in the field's description. See discusses field-level security and describes the types of field access: SELECT, READ, UPDATE, and ADD. 
Field-level security has a negligible impact on both performance and storage usage.

=== Content Constraints ===

====Setting a pattern for a field value: the LIKE attribute====
The LIKE attribute is available as of Model 204 release 7.5.
Setting a field pattern lets you specify a pattern that a field value must conform to, otherwise it cannot be stored. The patterns you can specify are the <var class="product">Model 204</var> LIKE patterns. See the chapter on pattern matching in the <var class="book">Rocket Model 204 User Language Manual</var>. 
For example:
IN FILE PITCHERS DEFINE FIELD G WITH LIKE '@@@####'

This example specifies that field G must start with three alphabetic characters followed by four numeric characters. An attempt to store a field value that does not conform to the field's pattern results in request cancellation.
You can limit a field value to a list of values. For, example, if a field must have a value of 'M' or 'F' you could code:
IN FILE PITCHERS DEFINE FIELD SEX WITH LIKE 'M,F'

And if you want a BALL field to have a value 'SPLITTER', 'CURVE', 'KNUCKLE', or 'CHANGE UP' you could code:
IN FILE PITCHERS DEFINE FIELD BALL WITH LIKE -
'SPLITTER,CURVE,KNUCKLE,CHANGE UP'

The maximum pattern length is 47 characters. The maximum default value length is 31 characters.
As with the IS LIKE operator in User Language, the patterns are always applied to numbers after conversion to a string.

You cannot use the LIKE attribute to define an automatic field.

====Range constraints====
Range constraints are available as of Model 204 version 7.5.
You can set range constraints on fields using the range attributes. Each set of range attributes is comprised of three or four attributes that you can use to establish a range for field length values, integer values, float values, or date/time stamp values. The types of range attributes are mutually exclusive. For example, you cannot define a field with the LENGTH-GE and INTEGER-LE attributes. 
The range constraints are self-editing. If you define a field with LENGTH LE 6 and LENGTH GE 8, the definition is rejected and an error message is issued.
When a range constraint is redefined, it replaces the existing field constraint.
Note: The range constraints do not have to match the data type of the stored field. That is, you can have a date/time constraint for a STRING field or an integer constraint for a FLOAT field, and so on.

=====Defining fields with length constraints=====
<table>
<tr>
<th>Length constraint attributes </th>
<th>
Range</th>
</tr>
<tr>
<td>LENGTH-EQ </td>
<td>Number from 0 to 255 that indicates the required length of a field</td>
</tr>
<tr>
<td>LENGTH-GE </td>
<td>Number from 0 to 255 that indicates the minimum length of a field</td>
</tr>
<tr>
<td>LENGTH-LE </td>
<td>Number from 0 to 255 that indicates the maximum length of a field</td>
</tr>
</table>
The following field definitions illustrate using the length constraint attributes, LENGTH-EQ, LENGTH-GE, and LENGTH-LE, with each other and/or with other attributes.
IN FILE REDSOX DEFINE FIELD A WITH LENGTH-EQ 8 BINARY OCCURS 1

IN FILE REDSOX DEFINE FIELD B WITH LENGTH-GE 4 FLOAT LEN 8

IN FILE REDSOX DEFINE FIELD C WITH LENGTH-LE 10

IN FILE REDSOX DEFINE FIELD D WITH LENGTH-LE 10 LENGTH-GE 3

IN FILE REDSOX DEFINE FIELD E WITH LENGTH-LE 6 LENGTH-GE 6 BINARY

IN FILE REDSOX DEFINE FIELD F WITH LENGTH-LE 255 LENGTH-GE 0

IN FILE REDSOX DEFINE FIELD COLOR WITH EXACTLY-ONE

Note: The length constraints apply to the string representation of non-string types as they would be stored in the database. This means that the length of a FLOAT field with value 34.000 would be 2 because after being stored in the database it will return 34 on a retrieval.
=====LENGTH-EQ (LEQ) attribute=====
The LENGTH-EQ attribute is followed by a number from 0 to 255 that indicates the required length of a field.
The LENGTH-EQ attribute is not allowed for automatic fields.
=====LENGTH-GE (LGE) attribute=====
The LENGTH-GE attribute is followed by a number from 0 to 255 that indicates the minimum length of a field.
The LENGTH-GE attribute is not allowed for automatic fields. You can pair the LGE attribute with the LLE attribute, creating a length range. However, if the range is not valid or overlaps, an error message is invoked.
=====LENGTH-LE (LLE) attribute=====
The LENGTH-LE attribute is followed by a number from 0 to 255 that indicates the maximum length of a field.
The LENGTH-LE attribute is not allowed for automatic fields. You can pair the LLE attribute with the LGE attribute, creating a length range. However, if the range is not valid or overlaps, an error message is invoked.
=====Setting an integer value constraint=====
For Integer values you can define a field with:
<table>
<tr>
<th>Integer attribute </th>
<th>Specifies that the integer value must be...</th>
</tr>
<tr>
<td>INTEGER-GE </td>
<td>Greater than or equal to the value that follows</td>
</tr>
<tr>
<td>INTEGER-GT </td>
<td>Greater than the value that follows</td>
</tr>
<tr>
<td>INTEGER-LE </td>
<td>Less than or equal to the value that follows</td>
</tr>
<tr>
<td>INTEGER-LT</td>
<td>Less than the value that follows</td>
</tr>
</table>
The value stored for a field must be an integer with a value that satisfies the constraint. For example:
DEFINE FIELD NCHILDREN WITH INTEGER-LE 100

The NCHILDREN field can have an integer value of less than or equal to 100.
Note: An integer constraint will not accept a value that would be stored with a decimal place. If you have an integer constraint INTEGER-GE 10 and try to store value 10.0, it will fail because 10.0 is not an integer.
=====INTEGER-GE (INTGE), INTEGER-GT (INTGT), INTEGER-LE (INTLE) and INTEGER-LT (INTLT) attributes=====
The integer range attributes-INTGE, INTGT, INTLE, INTLT-can be defined singly or as a pair on a field. The integer range attributes establish a range of acceptable integer values for the field. If a record is added with an integer value that is not within the range, the record is rejected.
If you specify another type of range attribute on the same field, such as DATETIME-LE or FLOAT-GE, an error message is invoked. 
=====Setting a float value constraint=====
For float values you can define a field with:
<table>
<tr>
<th>Float attribute </th>
<th>Specifies that the float value must be...</th>
</tr>
<tr>
<td>FLOAT-GE </td>
<td>Greater than or equal to the value that follows</td>
</tr>
<tr>
<td>FLOAT-GT </td>
<td>Greater than the value that follows</td>
</tr>
<tr>
<td>FLOAT-LE </td>
<td>Less than or equal to the value that follows</td>
</tr>
<tr>
<td>FLOAT-LT</td>
<td>Less than the value that follows</td>
</tr>
</table>
The value stored for a field must be a floating point value that satisfies the constraint. For example:
DEFINE FIELD WEIGHT WITH FLOAT-GT 10.5

The WEIGHT field must have a float value greater than 10.5. 
=====FLOAT-GE (FLTGE), FLOAT-GT (FLTGT), FLOAT-LE (FLTLE) and FLOAT-LT (FLTLT) attributes=====
The float range attributes-FLTGE, FLTGT, FLTLE, FLTLT-can be defined singly or as a pair on a field. The float range attributes establish a range of acceptable float values for the field. If a record is added with a float value that is not within the range, the record is rejected.
If you specify another type of range attribute on the same field, such as DATETIME-LE or INTEGER-GE, an error message is invoked. 
=====Setting a date/time value constraint=====
For date/time values you can define a field with:
<table>
<tr>
<th>Date/time attribute </th>
<th>Specifies that the date/time value must be...</th>
</tr>
<tr>
<td>DATETIME-GE </td>
<td>Later than or the same as the date/time value that follows</td>
</tr>
<tr>
<td>DATETIME-GT </td>
<td>Later than the date/time value that follows</td>
</tr>
<tr>
<td>DATETIME-LE </td>
<td>Earlier or equal to the date/time value that follows</td>
</tr>
<tr>
<td>DATETIME-LT </td>
<td>Earlier than the value that follows</td>
</tr>
</table>
The value stored for field must be a date/time value that satisfies the constraint. For example:
DEFINE FIELD BIRTHDATE WITH DATETIME-GE 18900101 -
DATETIME-LT 20100101

The BIRTHEDATE field is required to have a date/time value greater than or equal to January 1, 1890 and less than January 1, 2010. As with any other date/time values, the values can be extended with HH, HHMM, HHMMSS, HHMMSSX, HHMMSSXX, and so on.
=====DATETIME-GE (DTGE), DATETIME-GT (DTGT), DATETIME-LE (DTLE), and DATETIME-LT (DTLT) attributes=====
The date/time range attributes-DTGE, DTGT, DTLE, DTLT-establish a range of acceptable dates for the value of the field. If a record is added with a date that is not within the range, the record is rejected. You can specify a single date/time range attribute or a pair of them on a field. 
If you specify another type of range attribute on the same field, such as FLOAT-LE or INTEGER-GE, an error message is invoked. 
The value stored for a field must be a date/time with a value that has the proper relationship to the following value. For example:
DEFINE FIELD BIRTHDATE WITH DATETIME-GE 18900101 -
DATETIME-LT 20100101

The BIRTHDATE field is required to have a date/time value greater than or equal to January 1, 1890 and less than January 1, 2010. As with any other date/time values, the values can be extended with HH, HHMM, HHMMSS, HHMMSSX, HHMMSSXX, and so on.

== Concatenated Fields ==
Note: General Availability of the concatenated fields feature is in Model 204 release 7.5.
Fields that make up concatenated field values must be either AT-MOST-ONE, EXACTLY-ONE, or OCCURS 1 and must all be in the same field group context (including no field group). FIELDGROUP * are not allowed.
Fields defined with range attributes cannot be used in concatenation processing. For more information on this, see "Range Constraints" on [[|]].
The following syntax is used to define a concatenated field with a separator and an escape character:
Syntax
DEFINE FIELD fieldname WITH CONCATENATION-OF -
field1 WITH field2 [WITH field3 [WITH field4 -
[AND . . .]]] -
[SEPARATOR (char | X'hex' | NONE)] -
[ESCAPE (char | X'hex' | CANCEL)]
[OtherAttributes . . .]

The SEPARATOR character appears between the field values that comprise the concatenated field. Up to eight fields may be defined for a concatenated field. 
Concatenated fields could be longer than 255 bytes after adding separator characters and escaping results in request cancellation.
Concatenated fields have the following field attribute support.
<table>
<tr>
<td>Concatenated field attributes </td>
<td>
Purpose</td>
</tr>
<tr>
<td>CONCATENATION-OF (CAT) </td>
<td>List the fields that make up that concatenated field</td>
</tr>
<tr>
<td>ESCAPE (ESC) </td>
<td>Specifies a character that is used to escape separator characters that occur in a field that requires a terminating separator character</td>
</tr>
<tr>
<td>SEPARATOR (SEP) </td>
<td>Specifies the character that terminates fields that do not have a fixed length and are not the last field in the concatenation</td>
</tr>
</table>
If a required attribute is not assigned a value, the default value is used. For example, if you define a CONCATENATEION-OF field, which requires the SEPARATOR attribute, and you do not enter the SEPARATOR attribute, the default value of X'00' is used as the SEPARATOR value.
===CONCATENATION-OF (CAT) attribute===
The CONCATENATION-OF (CAT) attribute is followed by a list of fields that make up that concatenated field. At least two are required and up to eight are allowed. The field names must be separated by the word WITH and subsequent field attributes must be separated from the list by the word AND. Each field specified in the list of concatenated fields must have the EXACTLY-ONE attribute specified.
===ESCAPE (ESC) attribute===
The ESC attribute is followed by one of the following:
<ul>
<li>A single character in C'<char>' or X'<hex>' format that specifies the character that is used to escape separator characters that occur in a field that requires a terminating separator character. In addition to escaping the separator character, the escape character can also escape itself.</li>
<li>CANCEL, which means that an attempt to store a separator character in a field that requires a terminating separator results in request cancellation.</li>
</ul>
The default ESCAPE character is X'01'. 
Once you define an ESCAPE value for a field, you cannot redefine the ESCAPE value.
The ESCAPE character cannot match the SEPARATOR character. The ESCAPE character is always displayed on DISPLAY FIELD output.
The ESCAPE attribute is not allowed on a field definition, if the SEPARATOR NONE attribute is specified.
Using the ESCAPE attribute
The ESC character is inserted into a concatenated field when the real data being added to the database contains the SEPARATOR or the ESCAPE character itself. When reading in stored values, programs use the ESC character to differentiate between the special characters and normal data that happens to include the special characters. When the processing encounters the ESCAPE character in a concatenated field, it knows that the next character is real data.
Note: The ESCAPE character applies to all fields except the last field in the concatenation. The programmer is expected to know how many components comprise the concatenation and therefore, special characters occurring in the last component must be real data.
Consider the following field definitions:
DEFINE FIELD A_CONCAT_TEST1 WITH AT-MOST-ONE
DEFINE FIELD A_CONCAT_TEST2 WITH AT-MOST-ONE
DEFINE FIELD A_CONCAT_TEST3 WITH CONCATENATION-OF -
A_CONCAT_TEST1 WITH -
A_CONCAT_TEST2 AND -
SEPARATOR C'+' -
ESCAPE C'/'

If we then do:
BEGIN
IN POLICIES STORE RECORD
A_CONCAT_TEST1 = 1ST+VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
END STORE
FRN $CURREC
NP
PAI
END FOR
END

We get:
A_CONCAT_TEST1 = 1ST+VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
A_CONCAT_TEST3 = 1ST/+VALUE/++2ND+VALUE+

The plus signs in the stored records are intentionally part of the data. For the concatenated field <var class="product">Model 204</var> stores the escape character preceding the plus signs in the data for all but the last field in the concatenation. This assumes that the programmer knows how many fields there are in the concatenation and therefore knows that any separator characters in the last field are data fields.
In storing the escape character immediately before any plus signs that are part of the data proper, <var class="product">Model 204</var> tells the programmer that they are to be read as data. If there were any escape characters in the data proper, <var class="product">Model 204</var> puts an escape character before the data proper version as in the following example:
BEGIN
IN POLICIES STORE RECORD
A_CONCAT_TEST1 = 1ST/VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
END STORE
FRN $CURREC
NP
PAI
END FOR
END

... giving the output ...
A_CONCAT_TEST1 = 1ST/VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
A_CONCAT_TEST3 = 1ST//VALUE/++2ND+VALUE+

If you do not want either the separator or the escape character in the concatenated field, you can enforce this by assigning the value 'CANCEL' as the escape character as follows:
DEFINE FIELD A_CONCAT_TEST1 WITH CONCATENATION-OF -
A_CONCAT_TEST1 WITH -
A_CONCAT_TEST2 AND -
SEPARATOR C'+' -
ESCAPE CANCEL

In which case, the concatenation will be ignored and our STORE record results in the following:
A_CONCAT_TEST1 = 1ST/VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+

Note: There are no error messages associated with this condition.
===SEPARATOR (SEP) attribute===
The SEP attribute is followed by one of the following options:
<ul>
<li>A single character in C'&lt;char>' or an X'&lt;hex>' format that specifies the character that terminates fields that do not have a fixed length and are not the last field in the concatenation. The separator character is always used between field values, regardless of any length constraints on the component fields.</li>
<li>The NONE option that means the fields in the concatenation are concatenated end to end with no separator character and regardless of their length.</li>
</ul>
If you define a field with the SEP attribute, you must supply a value. Otherwise, the following error is issued:
DEFINE MAKE_MODEL WITH CONCATENATION-OF MAKE WITH MODEL - AND ORD SEP ESC CANCEL
*** 1 M204.0405: INVALID DEFINE OPTION: SEP ESC

If you define a field without the SEP attribute, it defaults to X:00:, as shown in the following code:
DEFINE MAKE_MODEL WITH CONCATENATION-OF MAKE WITH MODEL -
AND ORD ESC CANCEL

D FIELD (ABBREV) MAKE_MODEL
MAKE_MODEL
(DEF NFRV NKEY NCOD STR NNR VIS UP ORD CHAR LRES 15 -
NRES 15 SPLT 50 IMM 1 NUNIQ ONE CAT MAKE WITH MODEL AND -
SEP X'00' EXC CANCEL)

Once you define a SEPARATOR value for a field, you cannot redefine the SEPARATOR value.
The SEPARATOR character cannot match the ESCAPE character. The SEPARATOR character is always displayed on DISPLAY FIELD output.
If the SEPARATOR NONE attribute is specified on a field definition, the ESCAPE attribute is not allowed.
===Defining concatenated fields===
Using the fields defined in [[|]] and the following fields, you can define concatenated fields.
IN FILE REDSOX DEFINE FIELD COLMOD WITH CONCATENATION-OF COLOR -
WITH MODEL AND SEP C'-' ESC C'+'

IN FILE REDSOX DEFINE FIELD MODCOL WITH CONCATENATION-OF MODEL -
WITH COLOR AND SEP C'$' ESC C'*'

IN FILE REDSOX DEFINE FIELD MODCOLI WITH CONCATENATION-OF MODEL -
WITH COLOR AND SEP X'40' ESC C'*' INVISIBLE ORDERED

IN FILE REDSOX DEFINE FIELD MCY WITH CONCATENATION-OF MODEL -
WITH COLOR WITH YEAR AND SEP X'40' ESC C'*' INVISIBLE ORDERED

IN FILE REDSOX DEFINE FIELD COLCNT WITH CONCATENATION-OF COLOR -
WITH COUNTRY AND SEP X'40' ESC C'*' INVISIBLE ORDERED

IN FILE REDSOX DEFINE FIELD CNTYR WITH CONCATENATION-OF YEAR -
WITH COUNTRY AND SEP X'40' ESC C'*' INVISIBLE ORDERED

===Defining concatenated fields in a field group context===
IN FILE REDSOX DEFINE FIELD BATTERS

IN FILE REDSOX DEFINE FIELDGROUP STARTERS

IN FILE REDSOX DEFINE FIELD NTRIP WITH CTO STARTERS AND EXACTLY-ONE

IN FILE REDSOX DEFINE FIELD A WITH AT-MOST-ONE FIELDGROUP STARTERS AND-
ORDERED CHARACTER

IN FILE REDSOX DEFINE FIELD B WITH AT-MOST-ONE FIELDGROUP STARTERS AND -
KEY

IN FILE REDSOX DEFINE FIELD C WITH AT-MOST-ONE FIELDGROUP STARTERS AND
ORDERED NUMERIC

IN FILE REDSOX DEFINE FIELD AB WITH FIELDGROUP STARTERS AND -
CONCATENATION-OF A WITH B AND SEP C'/'

IN FILE REDSOX DEFINE FIELD ABO WITH FIELDGROUP STARTERS AND -
CONCATENATION-OF B WITH A AND SEP C'+' ORDERED

IN FILE REDSOX DEFINE FIELD ABI WITH CONCATENATION-OF B WITH A AND -
SEP C'+' ORDERED INVISIBLE

Note: A field in a concatenated field value does not have a terminating separator set only if it is:
<ul>
<li>Last field in the concatenation, or</li>
<li>Fixed length (LENGTH-EQ set) and the default value has the same length as LENGTH-EQ.</li>
</ul>
If you specify the ESCAPE CANCEL attribute for a field and the SEPARATOR character for that field is in one of the field values for the concatenated string, the update is cancelled. 

<div id="Automatic Fields">

== Automatic Fields ==
Note: Automatic fields are available as of Model 204 version 7.5.
<var class="product">Model 204</var> lets you define a field whose value is automatically maintained. For example, a field may count occurrences of another field so that every store or delete of the field occurrence changes the count in the automatic field. The automatic fields are fields defined with the following attributes: 
<ul>
<li>COUNT-OCCURRENCES-OF</li>
<li>CREATE-TIME</li>
<li>CREATE-TIMEUTC</li>
<li>CREATE-USER</li>
<li>UPDATE-TIME</li>
<li>UPDATE-TIMEUTC</li>
<li>UPDATE-USER</li>
</ul>
The value of an automatic field is updated at the start of a transaction by <var class="product">Model 204</var> and you cannot set it explicitly by a program. Any valid update causes the appropriate time and user stamps to be updated. For example, DELETE FOO(8). when there are no occurrences of FOO in the record.
Once you define an automatic value for a field, you cannot redefine the automatic value.
===Automatic Field Context===
Automatic fields can operate in a record or field group context. For example, with the following set of fields:

...
DEFINE FIELDGROUP ADDRESS
...
DEFINE FIELD RECORD.UPDT.TIME (DATETIME UPDT-TIME)
DEFINE FIELD ADDRESS.LINE.1 (SN NONE FG ADDRESS)
...
DEFINE FIELD ADDRESS.UPDT.TIME (DATETIME FG ADDRESS AND UPDT-TIME)
...
<ul>
<li>Any update to any field in a record will automatically update RECORD.UPDT.TIME.</li>
<li>Any update to any field in an occurrence of the ADDRESS field group will cause the ADDRESS.UPDT.TIME for that occurrence to be updated. (And, of course, the record level RECORD.UPDT.TIME as well.) </li>
</ul>

===Rules for the definition of Automatic Fields===

'''COUNT-OCCURRENCES-OF (CTO) attribute'''
The COUNT-OCCURRENCES-OF (CTO) attribute is not allowed for fields defined as REPEATABLE.
Because one of the major advantages of CTO fields is to avoid unnecessary record scans, it is highly recommended that the field be preallocated. Otherwise the field is stored and updated in Table B in the normal way.

See [[Field Design (File Management)#Counting occurrences of a field|Counting occurrences of a field]] for details on its use.

'''Other automatic fields'''

All other automatic fields capture the add/update user/time as of the start of the transaction. Any of these attributes can be be added to empty or non-empty fields (via a [[REDEFINE command]]). The value is maintained by <var class="product">Model 204</var> processing, so you cannot change the value.
These automatic attributes cannot be defined as REPEATABLE (the default is AT-MOST-ONE).

See [[Field Design (File Management)#Tracking updates using automatic fields|Tracking updates using automatic fields]] for details on their use.

===Displaying automatic fields===
You can specify the AT-MOST-ONE or EXACTLY-ONE attribute for an automatic field. These attributes affect the order in which the fields are displayed on a PAI statement. EXACTLY-ONE fields are displayed in the order they were defined, whereas AT-MOST-ONE fields are displayed in the order they are stored in Table B. 
Currently Table B stores automatic fields in the following order:
<ol>
<li>UPDATE-TIME</li>
<li>UPDATE-USER</li>
<li>CREATE-TIME</li>
<li>CREATE-USER</li>
</ol>

===Counting occurrences of a field===
To create such a field you use the COUNT-OCCURRENCES-OF (CTO) keyword on a field definition followed by the name of the field that the field or field group for which the count is automatically maintained. For example, if you have field group DRUG you could define an automatic count field as follows:
DEFINE FIELDGROUP DRUG
DEFINE FIELD DRUGCT WITH COUNT-OCCURRENCES-OF DRUG

You cannot define a CTO field in a file that has had records already added to it.
You could also make the automatic count field a binary field:
DEFINE FIELD DRUGCT WITH CTO DRUG AND BINARY OCCURS 1
DEFINE FIELD DRUGCT WITH COUNT-OCCURRENCES-OF DRUG AND -
BINARY

Note: AND is a separator between a field or field group name and other field attributes.
An automatic count field can also be an OCCURS 1 field:
DEFINE FIELD DRUGCT WITH COUNT-OCCURRENCES-OF DRUG AND BINARY OCCURS 1

An automatic counter field could even be ORDERED, KEY or NUMERIC RANGE:
DEFINE FIELD DRUGCT WITH CTO DRUG AND BINARY OCCURS 1 ORDERED NUMERIC

You can find all records with N occurrences of field group DRUG. Or, you can find those that have more or less than some number of occurrences.
Limitations on COUNT-OCCURRENCES-OF (CTO) fields
Fields defined with the CTO attribute cannot also have the UPDATE AT END attribute. You cannot define a CTO field that counts occurrences of UPDATE AT END fields.
You cannot use a CTO field to count occurrences of OCCURS fields, even though the OCCURS count is greater than 1.
Also, you cannot define a CTO field in a file that has had records already added to it.
There is a maximum of one CTO field per field or field group.
Retrieving the value of a CTO field
You can retrieve values of CTO fields via the field name (as with any VISIBLE field), as in:
PRINT DRUGCT

or
%DRUGCT = DRUGCT

Automatic optimization with COUNT OCCURRENCES OF fields
The use of CTO fields automatically optimizes many of the record scan processes:
<ul>
<li>[[Operations on Multiply Occurring Fields#FOR EACH OCCURRENCE OF loops|FOR EACH OCCURRENCE OF]] loops.
If a CTO field exists for the field or field group that is being looped over via an FEO or FAO statement, the value of that field limits the number of times the loop is processed, which reduces the need to scan to the end of record for every FEO or FAO statement. Note that when a record is updated or might be updated mid-loop, <var class="product">Model 204</var> normal concerns about subscript handling in these statements need to be considered.
</li>
<li>FOR FIELDGROUP clause
Before processing a FOR FIELDGROUP loop, <var class="product">Model 204</var> checks whether the requested occurrence is in the record based on the CTO field. If the User Language request is for occurrence 3, but the CTO field indicates only two occurrences in the record, <var class="product">Model 204</var> stops processing the FOR loop.
</li>
<li>Field extraction
Before extracting a field <var class="product">Model 204</var> checks whether the requested occurrence is in the record based on the CTO field. If the User Language request is occurrence 3, but the CTO field indicates only two occurrences in the record, <var class="product">Model 204</var> sets the result to null (or NOT PRESENT). 
Note the in the case of the subscripted field optimization:
</li>
</ul>
 FOR %I FROM 1 TO %N
%FOO = FOOFIELD(%N)
END FOR

<var class="product">Model 204</var> checks only the number of occurrences on the first iteration of the loop.
In all cases, the greatest benefit from the CTO field optimization is when a record contains no occurrences of the requested field or field group. <var class="product">Model 204</var> immediately determines that no occurrence is on the record and stops scanning the record.
Defining an efficient CTO field
The counter fields are always physically present in the record. Using a DEFAULT-VALUE of zero for such a field defeats its purpose as you need to scan the entire record to determine whether to use the default value. When you issue a STORE RECORD statement, all CTO fields are stored as 0 in the record. For non-OCCURS, fields are always the first variable length fields in the record.
<var class="product">Model 204</var> customer support recommends that you define a CTO field as BINARY OCCURS 1, as these require only four bytes per record, whereas the minimum length of a variable length field is four bytes (for a compressed 0) and will be at least five for any non-zero value. A CTO field inside a field group cannot be an OCCURS field. 
The absolute maximum value for CTO fields is currently X'3FFFFFFF' or 1,073,741,823 since BINARY fields use the high order two bits to distinguish values from coded values. 
You cannot update CTO fields; attempts are caught at compile-time for explicit file-context references and at run-time for group-context and field-name variables. 
CTO fields can even be in field groups and zeros are stored for CTO fields when the ADD FIELDGROUP or INSERT FIELDGROUP statement is processed.
Displaying CTO fields
By default, the PRINT ALL INFORMATION (PAI), AUDIT ALL INFORMATION (AAI), PRINT ALL FIELD GROUP INFORMATION (PAFGI), and AUDIT ALL FIELDGROUP INFORMATION (AAFGI) statements do not display CTO (counter fields). When you are using PAI [INTO] to reorganize your files or to copy records, the automatic fields are likely to cause problems.
Under other circumstances you can use the argument to indicate that you do want automatic fields to be printed by these statements.

===Tracking updates using automatic fields===
<var class="product">Model 204</var> can now track the date/time when a record was created or updated and what user ID created or updated it.
This tracking can be accomplished by using one of the following field tracking attributes: 
<table>
<tr>
<td>Tracking attribute </td>
<td>Abbreviation</td>
<td>Tracks the...</td>
</tr>
<tr>
<td>CREATE-TIME </td>
<td>CRTM</td>
<td>Moment the record was created using machine time</td>
</tr>
<tr>
<td>CREATE-TIMEUTC </td>
<td>CRTMU</td>
<td>Moment the record was created using Coordinated Universal Time</td>
</tr>
<tr>
<td>CREATE-USER </td>
<td>CRUS</td>
<td>User ID that created the record</td>
</tr>
<tr>
<td>UPDATE-TIME </td>
<td>UPTM</td>
<td>Moment the record was updated using machine time</td>
</tr>
<tr>
<td>UPDATE-TIMEUTC </td>
<td>UPTMU</td>
<td>Moment the record was updated using Coordinated Universal Time</td>
</tr>
<tr>
<td>UPDATE-USER </td>
<td>UPUS</td>
<td>User ID that updated the record</td>
</tr>
</table>
All of the automatic fields that contain date/time information also have the DATETIME attribute. 
You cannot update tracking fields with User Language.
A record or field group can contain only a single field of each update tracing type (CREATE-USER, UPDATE-USER, CREATE-TIME, UPDATE-TIME). An attempt to create a second invokes an error message.
You can define update tracking fields (CREATE-TIME, UPDATE-TIME, CREATE-USER, UPDATE-USER) in an already populated file, even an update tracking field for the main records or a field group that already has occurrences. You can also define a DEFAULT-VALUE field, which defaults to a null string. This lets you define such fields with or without a reorganization.
Tracking fields for records
The file itself may have a single field defined for each of the tracking fields.
An attempt to define a second field of the same type on the file results in an error message, for example:
DEFINE FIELD RECORD.CREATE.TIME WITH CREATE-TIME
DEFINE FIELD RECORD.CREATE-TIME2 WITH CREATE-TIME

*** M204.2866: FILE ALREADY HAS A CREATE-TIME FIELD

The UPDATE tracking fields for the records are updated when any field in the record changes and the create tracking fields are added to the record when it is initially stored. 
Tracking fields for field groups
Automatic tracking fields can also provide a date/time and user stamp of the creator and last update of each occurrence of a field group.
If an UPDATE-TIME tracking field is defined as a part of the field group as shown below:
DEFINE FIELD MY_UPDATE_TIME WITH FIELDGROUP X AND -
ORD NUM UPDATE-TIME

then each occurrence of field group X will contain the field.
Setting a date/time field
The DATETIME attribute indicates the format of the data stored in Table B.
You can now define a field with a DATETIME attribute:
DEFINE FIELD WHEN WITH DATETIME

DATETIME fields use seven bytes to store the value (plus four bytes overhead, if the field is not preallocated). A binary representation is used to store the 20-character full date format so that it can be held in seven bytes. the DATETIME attribute may not be combined with KEY. You assign a string to it in <var>YYYYMMDDHHMMSSXXXXXX</var> format:
IN FILE FOO DEFINE FIELD WHEN WITH DATETIME
...
BEGIN
IN FILE FOO STORE RECORD
WHEN = '2010070413470643516378'
END STORE
END

If you attempt to store the field with invalid data such as, WHEN = '72', the request will be cancelled and you will receive an error:
*** 1 CANCELLING REQUEST: M204.2865: ATTEMPT TO ADD INVALID DATETIME VALUE: WHEN = 72

As most timestamps do not require microseconds, you can specify 10ths, 100ths, 1,000ths, 10,000ths and 100,000ths of a second. The value is simply padded on the right with zeros. For date/time field WHEN, the following are all equivalent:
ADD WHEN = '20090704134706000000'
ADD WHEN = '2009070413470600000'
ADD WHEN = '200907041347060000'
ADD WHEN = '20090704134706000'
ADD WHEN = '2009070413470600'
ADD WHEN = '200907041347060'
ADD WHEN = '20090704134706'


In addition, you can leave off seconds, minutes or hours so the following are all equivalent:
ADD WHEN = '20090704000000'
ADD WHEN = '200907040000'
ADD WHEN = '2009070400'
ADD WHEN = '20090704'

which are also, of course, equivalent to
ADD WHEN = '20090704000000000000'

Storing dates or date/times efficiently
The shortest valid format for a field with the DATETIME attribute contains YYYYMMDD. If the values you are storing are simple dates, they can be stored in four bytes as binary values, so requires three fewer bytes per value than a date/time field. However, for anything with a time in it (even just hours), a DATETIME field takes less space than the alternative field types (FLOAT or STRING).
Automatic validation of date/times
In addition to the compact storage of date/time stamps, DATETIME fields also provide automatic validation of the values stored into them. That is, you cannot store numbers into them that are not valid dates. For example, you cannot store '9999111' into a DATETIME field, nor can you store '20070931' (because September does not have 31 days), nor can you store '20070229' (because 2007 is not a leap year, so February only has 28 days).
DATETIME fields also provide for field content validation for DATETIME fields. 
Note: It is possible to set a DATETIME DEFAULT-VALUE to an invalid date/time value, such as '_', and to set a DATETIME field to that value. That value will not be stored in the database and the value returned for an EXACTLY-ONE field value that had not been set would be the default value in such a case.
The value returned for DATETIME fields is always in:
YYYYMMDDHHMMSSXXXXXX

If you are interested in only part of the time stamp, you can either use the $SUBSTR function to get the part you want or make the %variable that will hold the time stamp length you are interested in. So, if you want %WHEN to hold a date/time in YYYYMMDDHHMISS format, simply declare %WHEN as:
%WHEN IS STRING LEN 14

...

%WHEN = WHEN

DATETIME values can be indexed either as ORDERED CHARACTER or ORDERED NUMERIC. When indexed as ORDERED NUMERIC, only the first 15 digits (<var>YYYYMMDDHHMISSX</var>) are indexed. When a DATETIME field is indexed as ORDERED CHARACTER, it is indexed as the string representation of the date/time value in the full <var>YYYYMMDDHHMISSXXXXXX</var> format.
Note: Making DATETIME fields KEY fields is not allowed.
Update processing
Date/time values are the date/time of the start of the update processing, so all records, fields and field groups updated by a single update get the same time stamp. Furthermore, the code that starts an update unit ensures that the date/time stamp of each update unit is unique.
The M204.0173 and M204.0172 messages were expanded to include the date/time stamp.
M204.0173: START OF UPDATE 12 AT 10:11:00.51 (20090705101100511734)

and
M204.0172: END OF UPDATE 12 AT 10:11:00.56 (20090705101100511734)

Defining various UPDATE-USER fields
To indicate whether an update tracking field applies to a record or field group, specify or do not specify the containing field group on the field definition. For example:
DEFINE FIELD WHO WITH UPDATE-USER

The WHO field contains the user ID of the last user that updated anything in the record. The following example illustrates defining an UPDATE-USER field in a field group:
DEFINE FIELD DR.WHO WITH UPDATE-USER FIELDGROUP DR

The DR.WHO field contains the user ID of the last user that updated an occurrence of field group DR.
Defining various UPDATE-TIME fields
You can specify an update tracking field as FIELDGROUP *, which means that all field groups and the primary record all use the same update tracking field. For example:
DEFINE FIELD WHEN WITH UPDATE-TIME FIELDGROUP *

The WHEN field is placed in the primary record and each field group to track the last update time. If a file has a FIELDGROUP * update tracking field and a field group or record has a different comparable updating tracking field, the field group or the record specific tracking field applies to the field. For example:
DEFINE FIELD WHEN WITH UPDATE-TIME FIELDGROUP *

DEFINE FIELD MAIN.WHEN WITH UPDATE-TIME OCCURS 1

DEFINE FIELD FOO.WHEN WITH UPDATE-TIME FIELDGROUP FOO

<ul>
<li>The field WHEN would be updated for changes to any field group occurrences in field groups that do not have their own UPDATE-TIME field defined.</li>
<li>The Field MAIN.WHEN would be set for any update to any field in the record.</li>
<li>The field FOO.WHEN would be set in field group FOO for any update to a field group occurrence.</li>
</ul>
The UPDATE-TIME field in a field group that has a nested field group will be updated when the nested field group is updated, even though no fields in the containing field group were updated.

===An alternate approach to adding a date-time stamp field to your files===

There is a more general way you can include a date-time stamp field in your files. The date/time stamp feature lets you put a date-time stamp (DTS) on each record that was updated in a transaction. You can then use the data in the <var class="term">date/time stamp</var> field in an end-user written application to find and process all the rows of data that were changed.
An application that processes these records can track the <var class="term">date/time stamp</var> field values that have been processed to date, or it may take another action, including updating the date/time stamp field.
To install and use this functionality, see [[Setting Up the Date-Time Stamp Field]]. Once installed, the date-time stamp feature works only in files created in V6R1.0 or later. See [[Adding a Date-Time Stamp field]]

Note: There is no support in PQO/204 for the data/time stamp feature.

====Difference between the system wide date-time stamp field and an UPDATE-TIME field====

Besides the obvious difference that the date-time stamp field will (and must) have the same name in every file in which it is used, the following are the notable differences between the two approaches:

* The UPDATE-TIME attribute can be set to track updates to Repeating Field Groups, as well as at the record level.
* The UPDATE-TIME captures the time at the start of an update unit, the date-time stamp field captures the time at the commit point.
* The date-time stamp field updates may be [[#Suspending date-time stamp updates|temporarily suspended]].

== Assigning Fields to Repeating Field Groups (RFGs) ==

===FIELDGROUP attribute===

No default, can be abbreviated as 'FG'. FIELDGROUP is available as of Model 204 version 7.5.

The FIELDGROUP attribute specifies the name of the field group that the
defined field is associated with (contained in). Once you define a FIELDGROUP
value for a field, you cannot redefine the FIELDGROUP value.

The FIELDGROUP attribute can not refer to a fieldgroupname that has not yet been defined to the file (the [[DEFINE FIELDGROUP command]] must occur before the [[DEFINE FIELD command]].

===Syntax===
:FIELDGROUP [fieldgroupname|*]

The FIELDGROUP attribute does not allow:

* Record security
* Use for SORT or HASH file
* 1NF file model
The FIELDGROUP attribute can be used with the STORE-NULL LITERAL
attribute.

===Using FIELDGROUP * ===

The FIELDGROUP * attribute means that the field will be included into all
field groups. The EXACTLY-ONE attribute conflicts with the FIELDGROUP * attribute.

<div id="Field Naming">

== Field Naming ==

The rules for field and fieldgroup naming are contained in [[Field Names]].

[[Category:File management]]

Release notes for Model 204 version 7.5

2013-07-01T23:29:24Z

Rob: /* Increased Table B record number capacity */

These release notes list the enhancements and other changes contained in Model 204 version 7.5, which is still in development.
Until the commercial release of the software, Rocket reserves the right to add to, remove, or change anything described herein.

==Overview==
These release notes contain installation and features information for the Rocket Model 204 version 7.5.0 release.
Before beginning your installation, please read through this information about product installation and changes.

==New in this release==
This section summarizes the new features and enhancements for Model 204 version 7.5.0.

===SOUL (User Language)===
The significantly enhanced, object-oriented, version of User Language is now called SOUL. All existing User Language programs will continue to work under SOUL, so User Language can be considered to be a subset of SOUL, though the name User Language is now deprecated.
<table>
<tr><th>Feature</th><th>Operating System</th>
<tr><td>Sirius object-oriented language extensions integration</td><td>z/VM, z/OS, z/VSE</td>
<tr><td>ECF statements can pass up to 60 parameters</td><td>z/VM, z/OS, z/VSE</td>
</table>

===System Management===
<table>
<tr><th>Feature</th><th>Operating System</th>
<tr><td>Writing records to the SMF data set without an SVC installed</td><td>z/VM, z/OS, z/VSE</td>
</table>

===Performance===
<table>
<tr><th>Feature</th><th>Operating System</th>
<tr><td>GTBL can be stored above the bar</td><td>z/VM, z/OS, z/VSE</td>
</table>

==Operating system requirements==
Requirements for Model 204 version 7.5.0 are still being determined.

Model 204 version 7.4.0 required the following operating system support:
<ul>
<li>For IBM z/OS: Version 1 Release 7 is sufficient for all new functionality except for the following
features:
<ul>
<li>Large (1 MB) page support requires Version 1 Release 9.
<li>Extended address volumes (EAV) requires Version 1 Release 12.
</ul>
<li>For IBM z/VM: Version 5 Release 4.0 or later
<li>For IBM z/VSE:
<ul>
<li>Version 5 Release 1 or
<li>Version 4 Release 3 or
<li>Version 4 Release 2.1 or
<li>Version 4 Release 2.0, with these program temporary fixes (PTFs) installed:
<ul>
<li>UD53436
<li>UD53437
<li>UD53438
<li>UD53439
</ul>
</ul>
</ul>

=== Hardware requirements ===
Requirements for Model 204 version 7.5.0 are still being determined.

Model 204 version 7.4.0 required the IBM z/890 or above processor, except for the following feature:

The large (1 MB) page support feature requires the IBM z10 or above processor. 

===Model 204 compatibility with operating systems===
Content in this section is still to be determined.

===Model 204 compatibility with Connect*===
All supported versions of Connect* are compatible with Model 204 version 7.5.0.
However, CLOB/BLOB support requires Connect* version 7.4.0 or higher. Use of Connect* versions earlier than version 7.4.0 to SELECT, UPDATE, or INSERT CLOB/BLOB data will fail and might produce unexpected application behavior and/or return an error.
Connect* version 7.5.0 is compatible with versions of Model 204 that are earlier than version 7.5.0.

==SOUL (User Language) enhancements==
Much of the substantial new and enhanced functionality described in the following subsections is available as a result of the acquisition of Sirius Software. The functionality that is the subject of the initial subsection, "Object oriented programming," motivates the new name for User Language, SOUL, often thought of as Simple Objective User Language.

===Object oriented programming===
As of version 7.5 of Model 204 (and backward compatible with existing User Language applications), the SOUL language is equipped with [http://en.wikipedia.org/wiki/Object-oriented_programming Object-Oriented Programming] (sometimes abbreviated O-O) capabilities comparable or superior to other contemporary object oriented languages. Formerly contained in the [[Janus SOAP User Language Interface]], you can use [[Janus SOAP ULI essentials]] as a set of entry points to the extensive SOUL O-O documentation.

===Record capacity increase===
in this version of Model 204, the record limit is increased from sixteen million records to forty-eight million records per file.

===New SOUL statements===
{{Template:User Language statements}}

===Non O-O enhancements in SOUL===
{{Template:User Language syntax enhancements}}

===External Call Facility (ECF)===
EXTERNAL CALL statements can now pass more parameters.
The maximum number of parameters that can be passed in an EXTERNAL CALL statement has been increased from 40 to 60.
The maximum value setting for ECPSIZE is increased from 1310680 to 1966020 to accommodate the extra parameters.
===REPEAT statement UNTIL option===
The REPEAT statement now supports the UNTIL option. In previous releases, only REPEAT WHILE was supported.

A REPEAT UNTIL enters the loop body prior to checking the condition.

Example:

The following program results in output of '1':

BEGIN
REPEAT WHILE %I EQ 0
%I = %I + 1
PRINT %I
END


However, the following program results in an endless print loop:

BEGIN
REPEAT UNTIL %I EQ 0
%I = %I + 1
PRINT %I
END


===New and changed classes and methods===

====New HttpRequest TranslateTable property====
The [[TranslateTable (HttpRequest property)|TranslateTable HttpRequest property]] makes it possible to set the translate table to be used for EBCDIC to ASCII translation of data in an HttpRequest object.

====New InvalidTranslateTable class====
Objects of the [[InvalidTranslateTable class|InvalidTranslateTable exception class]] are thrown when a requested system translate table cannot be found. It is currently thrown only by the [[TranslateTable (HttpRequest property)|TranslateTable HttpRequest property]].

====New bit manipulation String functions====
New bit manipulation functions [[BitClearString (String function)|BitClearString]], [[BitCountString (String function)|BitCountString]], [[BitFlipString (String function)|BitFlipString]], [[BitSetString (String function)|BitSetString]], and [[BitValueString (String function)|BitValueString]] make it easier to manipulate the bits in a string.

====New InvalidBitNumber class====
Objects of the [[InvalidBitNumber class|InvalidBitNumber exception class]] are thrown when an invalid bit number is requested by a bit manipulation function. It is currently thrown only by the <var>[[BitClearString (String function)|BitClearString]]</var>, <var>[[BitFlipString (String function)|BitFlipString]]</var>, [[BitSetString (String function)|BitSetString]], and <var>[[BitValueString (String function)|BitValueString]]</var> functions.

====New option for AppendJournalData====
The <var>QT</var> option is added to the <var>[[AppendJournalData_(Stringlist_function)#Options_parameter|AppendJournalData]]</var> method, to include QT type audit entries.

====New parameter for AddField====
The <var>Strip</var> option is added to the <var>Screen</var> class method <var>[[AddField (Screen function)|AddField]]</var> to allow suppression of leading and trailing blank removal from input fields.

===New and changed $functions===

====Former Sirius $functions====
The $functions referred to by the link below are added to SOUL as a result of the acquisition of Sirius Software:
<ul>
<li>[[List of $functions|Sirius $functions]]
</ul>

====$SNDMAIL attachment ASCII translation====
The $SNDMAIL function can now translate an attachment to ASCII before sending it.
This translation is useful if the $SNDMAIL attachment is a CLOB (CHARACTER-LARGE-OBJECT) such as a text document.

The $SNDMAIL function now accepts an optional parameter after the name of the attached object. If this parameter is set to 'C' (or to a percent variable with the value 'C'), the object in the buffer is translated to ASCII before being attached to the email.

If this parameter is not specified, the object in the buffer is sent as a binary object.

In this example:

%RC = $SNDMAIL(%SUBJECT,,%BODY,%FROM,%TO,,,,'CLOB.TXT','C')

the CLOB.TXT attachment will be translated to ASCII before being attached to the email.

==New products==
[[Sirius Software product list|These products]] are now available to Model 204 customers as separately purchased items as a result of the acquisition of Sirius Software.

==File-related enhancements==

===Repeating field groups===
[placeholder for long section to come from 7.2 rel notes]
===Increased Table B record number capacity===
Table B can now contain up to 48M possible record numbers. (The previous limit was 16M.)

Set FILEORG=X'200' at file creation time to allow for the increased record numbers.
Notes 
<ul>
<li>The limit for BSIZE remains at 16M.
 
BSIZE * BRECPPG must be less than or equal to 48M (actually decimal 50,331,648 to be exact).
 
For example, if BSIZE = 16M, BRECPPG cannot be more than 3.
</li>
<li>
FILEORG=X'200' cannot be specified for files with hash key or sorted file organization.
</li>
</ul>


==System management enhancements==

===Writing records to the SMF data set===
Having Model 204 write records to the SMF data set no longer requires the installation of an SVC.

Therefore, the <var>[[SMFSVC parameter|SMFSVC]]</var> parameter is no longer required and, if present, will be ignored and flagged with the following informational message:
M204.0204: PARAMETER SMFSVC OBSOLETE AND NOT RESET
However, the <var>[[SMFLORN parameter|SMFLORN]]</var> and <var>[[SMFSLRN parameter|SMFSLRN]]</var> parameters must still be present in CCAIN if SMF records are required.

==Performance enhancements==

===GTBL in above the bar storage===
GTBL can now be placed into non-swappable server storage area above the bar.
In order to store GTBL in ATB storage:
<ul>
<li>Increase the <var>[[SERVNSSZ parameter|SERVNSSZ]]</var> parameter by the GTBL size.
<li>Set the second byte of the <var>[[SERVNSA parameter|SERVNSA]]</var> parameter to <code>X’80’</code>, so the value of <var>SERVNSA</var> is <code>X'00800000'</code>.
</ul>
'''Note:'''
The settings for each server table above the bar are independent of each other.
So if both FTBL and GTBL are placed above the bar, then <var>SERVNSA</var> should be set to <code>X'02800000'</code>.

==MQ/204 enhancements==
Freeing MQ/204 subtasks and associated storage

The new MQDELDTP PST (pseudo subtask) checks for MQ/204 subtasks that are in a delayed detach state. MQDELDTP detaches MQ/204 subtasks that have finished their work and releases their associated storage areas.
==Upward compatibility issues==
===INTERCOMM is no longer supported===
The INTERCOMM interface supports the use of Teletype and 3270 terminals in line-at-a-time mode, using the Model 204 IODEV=29 thread type.

INTERCOMM is not supported in Model 204 version 7.5.

See the <var class="book">Rocket Model 204 Terminal User's Guide</var> for a discussion of terminal interfaces.

==New and changed commands==


===DEFINE FIELD new COMMA option===
The <var>[[DEFINE FIELD command#comma|COMMA]]</var> option on the <var>DEFINE FIELD</var> command uses commas to separate displayed field attributes.


==New and changed parameters==
In addition to the following specific parameter changes, <var class="product">Model 204</var> parameter descriptions, for example as displayed by the <var>VIEW</var> command, are now in mixed case (unless translated to uppercase due to <var>[[#UPCASMSG new parameter|UPCASMSG]]</var>.)


===ECPSIZE max value increase===
The maximum value setting for ECPSIZE has been increased from 1310680 to 1966020 to accommodate more [[Release_notes_for_Model_204_version_7.5_(DRAFT)#External_Call_Facility_.28ECF.29|External Call Facility]] parameters.
===FILEORG change===
The [[FILEORG_parameter|FILEORG]] X'100' setting for enhanced data handling files is available as of Model 204 version 7.5.

X'100' enables a number of enhancements to the file structure, including support for [[Support_for_repeating_field_groups|physical field groups]]; the definition of up to 32000 fields in a file; system maintained [[Field_Design_(File_Management)#Automatic_Fields|Automatic fields]]; [[Field_Design_(File_Management)#Field_Constraints|Field Constraints]] providing content validation; and improved space management of fields containing [[Field_Design_(File_Management)#BLOB.2C_CLOB_and_MINLOBE_attributes|Large Objects]].

If X'100' is selected, the X'80' bit (optimized field extraction files) is automatically set.

===MODTIM parameter (new)===
The <var>[[MODTIM parameter|MODTIM]]</var> system parameter displays the most recent assembly date and time of the Model 204 load module.

===OUTPUT=DUMMY for IODEV=3 threads===
IODEV=3 threads definitions now allow OUTPUT=DUMMY.
When defining IODEV=3 threads, if output is not required, the OUTPUT parameter can be coded as OUTPUT=DUMMY.
For example:

IODEV=3,INPUT=IOD3IN1,OUTPUT=DUMMY


This means that no DD statement is required for the output data set, and in cases where many
IODEV=3 threads are defined to simulate a large number of users, this enhancement will reduce the number of DD statements required by one half.

===RETRVKEY parameter change===
New in this release, if you specify a non-zero setting of <var>[[RETRVKEY parameter|RETRVKEY]]</var>:
<ul>
<li>If you have set the <code>X'01'</code> or <code>X'10'</code> bits of the <var>[[RETRVOPT parameter|RETRVOPT]]</var> parameter, you can use a
forward retrieve PF key, in addition to the backward retrieve PF key specified by <var>RETRVKEY</var>.
'''Note:'''
If either of these bits is set, the <code>X'02'</code> bit is strongly recommended as well.
<li>The size of the allocated storage area, and hence the number and length of input lines available for retrieval, is specified
by the value of the <var>[[RETRVBUF parameter|RETRVBUF]]</var> parameter.
</ul>

===SESMAXTO parameter (new)===
The <var>[[SESMAXTO parameter|SESMAXTO]]</var> parameter can be used limit the maximum session timeout value or to cause all current closed sessions to be immediately discarded.

===UPCASMSG parameter (new)===
The <var>[[UPCASMSG parameter|UPCASMSG]]</var> parameter can be used to translate messages issued by <var class="product">Model 204</var> to uppercase; otherwise (depending on the message being issued) they are displayed in mixed (upper and lower) case.





==New and updated messages==
'''M204.0141:
 BUG .. DUPLICATE FILE NAME IN CP RECORD

Explanation: A duplicate file name was encountered while attempting to add a deferred update dataset to the file directory during recovery. This indicates a potential problem in the Model 204 software.

System Manager Response: Contact Customer Support with the following documentation:
<ul>
<li>Audit trail from the previous run</li>
<li>Journal from the previous run</li>
</ul>
Return Codes: E 0 4 AD OPR
----
'''M204.0204:
 
PARAMETER SMFSVC OBSOLETE AND NOT RESET'''
 
'''Explanation:''' Writing records to the SMF data set no longer requires the installation of an SVC. The
SMFSVC parameter is therefore obsolete and cannot be reset.
 '''System Manager Response:''' No response required.
 '''Return Codes:''' I 0 0 AUDITMS

----

Messages M204.0332 and M204.0336 indicate problems with the CRAM interface.
The visibility of these messages has been improved by:
<ul>
<li>writing the message to the operator and the JESLOG
<li>writing the message as an ER line in CCAAUDIT
<li>setting the return code to 80
</ul>

'''M204.0332:
 RC ''nn'' FROM CRFS OPEN'''
 '''Explanation:''' The run has failed to initialize due to problems with the CRAM interface.
The possible formats of this message are:

Format 1: RC nn FROM CRFS OPEN/PUT/GET

Format 2: ECB postcode FROM CRFS PUT/GET
<ul>
<li>
Format 1 indicates that Model 204 module CRFS attempted to open channel, send a message down the channel, or receive a message from a channel. CRAM was unable to satisfy the request. The message states the return code and the
operation attempted.</li>
<li>
Format 2 indicates that Model 204 module CRFS received an unexpected post code from CRAM while attempting an I/O operation on a channel. The message states the post code and the operation attempted.
</li>
</ul>
'''System Manager Response:''' Contact Technical Support and have the audit trail available.
 '''Return Codes:''' C 80 80 AUDITER NOTERM OPR

'''M204.0336:
 RC ''nn'' FROM CRIO OPEN'''
 '''Explanation:''' The run has failed to initialize due to problems with the CRAM interface.
The possible formats of this message are:

Format 1: RC nn FROM CRIO OPEN/PUT/GET

Format 2: ECB postcode FROM CRFS PUT/GET
<ul>
<li>
Format 1 indicates that Model 204 module CRIO attempted to open a channel,
send a message down a channel, or receive a message from a channel. CRAM
was unable to satisfy the request. The message states the return code and the
operation attempted. For example, the return code 16 indicates that the CRAM
channel is already open.</li>
<li>
Format 2 indicates that Model 204 module CRFS received an unexpected post
code from CRAM while attempting an I/O operation on a channel. The message
shows the post code and the operation attempted.</li>
</ul>
'''System Manager Response:''' Contact Technical Support and have the audit trail available.
 
'''Return Codes:''' C 80 80 AUDITER NOTERM OPR

----

'''M204.0434:
 
NJBUFF SET TO %C'''

'''Explanation:''' TBD

----

'''M204.0790:
 
FILE TOO BIG'''
 
'''Explanation:''' The total number of records possible in Table B exceeds 342 segments for files that do not have the FILEORG X'200' bit set and 1024 segments for files that have the FILEORG X'200' bit set.
The number of potential record numbers per segment is 49,152.
The number of possible segments in Table B is calculated by the following formula:

((BSIZE * BRECPPG) / 49,152)) + (1 if remainder not 0)

If the result exceeds 342 or 1024 respectively too many segments result and MODEL 204 rejects the CREATE command.
 '''File Manager Response:''' Make the file smaller (by specifying a smaller BSIZE or smaller BRECPPG), or divide the file into smaller pieces and use the file group feature to process them as a single logical file.
 '''Return Codes:''' C 0 4 AUDITER
----

'''M204.0797:
 
BSIZE*BRECPPG EXCEEDS MAXIMUM VALUE'''
 
'''Explanation:''' The product of BSIZE and BRECPPG must not exceed 16,777,216 for regular Model 204 files (which do not have the FILEORG X'200' bit set) and 50,331,648 for files that have the FILEORG X'200' bit set. These numbers specify the maximum number of records allowed in a single Model 204 file.

The CREATE or INCREASE command is rejected.
 '''File Manager Response:''' Retry the command, specifying values for BSIZE and BRECPPG so that BSIZE*BRECPPG does not exceed the limit. Refer to the <var class="book"> Rocket Model 204 File Manager's Guide</var> for more information on file sizes.
 '''Return Codes:''' C 0 4 AUDITER

----

'''M204.1052:
 
LOUTPB %C TO %C'''
 
'''Explanation:'''
LOUTPB has been increased or decreased, to the value given in the message.
With a full-screen terminal the value is 1.5 times the minimum for that model number, rounded
up to a multiple of 8.
A model 2 terminal results in a LOUTPB of 3200.
A model 5 terminal results in a LOUTPB of 5664.
If NBKPG is greater than 0, the largest allowable value for LOUTPB is PAGESZ
minus 40, so the value can be decreased for this reason.
'''User Response:''' No response is needed. This message is for information only.
 '''Return Codes:''' I 0 0 AUDITAD

----

'''M204.1131:
 
CAN'T <var class="term">action</var>'''
 
'''Explanation:''' The procedure action cannot be taken for one of the following reasons:
<ul>
<li>The procedure is in use by another user.</li>
<li>The procedure is not in the file.</li>
<li>The user does not have the correct privileges to change the procedure.</li>
<li>If a RENAME or ASSIGN has been attempted, the alias might already exist.</li>
</ul>
'''Response:''' Make sure that the procedure name is spelled correctly.
If the named procedure is in use, retry the command when the procedure is no longer in use. Otherwise, arrange to place the
procedure in the file or to obtain the privileges to change the procedure.
 '''Return Codes:''' C 0 4 SUFFIX AUDITER

----
'''M204.1260:
 
[FIELD | FIELDGROUP] WAS PREVIOUSLY DEFINED WITH DIFFERENT ATTRIBUTES, NEW [FIELD | FIELDGROUP] OPTIONS IGNORED

Explanation: A DEFINE [FIELD | FIELDGROUP] command has attempted to define an existing field with different attributes.
Response: If you wish to redefine the attributes of the field, you must issue the REDEFINE [FIELD | FIELDGROUP] command. Notify your file manager.
Return Codes: C 0 4 AUDITER
----

'''M204.1307:
 
%C LOGON REJECTED - <var class="term">reason text</var> (REASON CODE: %X)

Explanation: The MODEL 204 3270 terminal handler has rejected a logon request from a 3270 terminal for the reason stated. The following reason codes are defined:
<ol>
<li>There are no control blocks available for new logons. Increase the number of IODEV 7 terminal definitions. The reason text is: NOT ENOUGH 3270 TERMINALS.</li>
<li>The terminal has been defined with a non-3270 transmission services profile. The LU type must be 2.</li>
<li>The reason text is: LU TYPE NOT = 2.</li>
<li>The terminal has been defined to require definite responses to messages it sends inbound to the host. The transmission services profile must be 3. The reason text is: TS PROFILE NOT = 3.</li>
<li>There has been an error on this terminal. This is a retryable error. The reason text is: LOSTERM SET FOR THIS TERMINAL.</li>
<li>The terminal definition is in use. This error should not occur. The reason text is: TERMINAL ALREADY IN USE.</li>
</ol>
System Manager Response: Contact your VTAM systems programmer to correct the VTAM definition.
Return Codes: E 0 4 AD SAVE NOTERM OPR
----
'''M204.1346:
 
SERVER AREA GREATER THAN CYLINDER CAPACITY FOR THIS DEVICE. CYLINDER SIZE = <var class="term">nnn</var> BYTES.
Explanation:
The number of bytes specified for the largest server area (SERVSIZE)
is greater than <var class="term">nnn</var>, the number of bytes contained in a cylinder for
the type of disk device on which your CCASERVR (CCASRVR for DOS) data set resides.
System Manager Response: Do one of the following:
<ul>
<li>ensure that the largest SERVSIZE value does not exceed <var class="term">nnn</var></li>
<li>place your server data sets on a type of disk device that has a
larger cylinder capacity</li>
<li>place CCASERVR in storage (see the "CCASERVR in Storage feature" section in the <var class="book">Rocket Model 204 System Manager's Guide</var>).</li>
</ul>
'''Return Codes:''' C 96 96 AUDITER
----
'''M204.1393:
 
CHUNK clause not of format "CHUNK <var class="term">chunkSize</var> FOR <var class="term">chunkTarget</var>"'''
 
'''Explanation:''' On a DEFINE FIELD, the syntax of the CHUNK clause was not in the format shown in this message.
 '''File Manager Response:''' Correct the DEFINE FIELD command that has the incorrect CHUNK clause syntax.
 '''Return Codes:''' C 0 4 AUDITER
----

'''M204.1394:
 
CHUNK <var class="term">chunkSize</var> VALUE INVALID: <var class="term">reason</var>'''
 
'''Explanation:''' On a DEFINE FIELD, the value specified for the size of a CHUNK is invalid;
"reason" indicates why.
 '''File Manager Response:''' Correct the DEFINE FIELD command that has the invalid CHUNK size.
 '''Return Codes:''' C 0 4 AUDITER
----
'''M204.1395:
 
CHUNK target is not VISIBLE ORDERED NUMERIC'''
 
'''Explanation:''' On a DEFINE FIELD, the field specified as a CHUNK target is not VISIBLE ORDERED NUMERIC, which is a requirement of chunk fields.
 '''File Manager Response:''' Correct the DEFINE FIELD command that has the invalid CHUNK target type.
 '''Return Codes:''' C 0 4 AUDITER
----
'''M204.1396:
 
CHUNK fields must be INVISIBLE ORDERED NUMERIC'''
 
'''Explanation:''' On a DEFINE FIELD, an attempt was made to create a CHUNK field that was not INVISIBLE ORDERED NUMERIC, which is a requirement of chunk fields.
 '''File Manager Response:''' Correct the DEFINE FIELD command that has the invalid CHUNK target type.
 '''Return Codes:''' C 0 4 AUDITER
----
'''M204.1397:
 
A CHUNK field was defined, %F may no longer be opened with M204 releases prior to V7R5'''
 '''Response:''' This is an informational message. No action is required.
 '''Return Codes:''' I 0 0 AUDITMS

----
'''M204.1489:
 
NOT ENOUGH FILE SPACE TO CONTINUE PROCEDURE DEFINITION - %F
Explanation: There is no room in the file to store the procedure being entered with the PROCEDURE command.

<table>
<tr><td>If…</td><td>Then Model 204…</td></tr>
<tr><td>Error occurs after the first line of procedure text has been stored</td><td>Keeps the partial procedure</td></tr>
<tr><td>You are entering the text at your terminal</td><td>Ends procedure definition immediately</td></tr>
<tr><td>Procedure text is supplied by another procedure</td><td>Flushes the remainder of the input</td></tr>
<tr><td>Procedure text is supplied in a batch input stream (CCAIN)</td><td>Flushes the remainder of the procedure text and resumes processing after the END PROCEDURE command</td></tr>
</table>

Response: Create space in the file by deleting unwanted procedures or increasing Table D with the INCREASE command. Replace the partial procedure using the PROCEDURE command, or use the EDIT command to supply the missing text.

Return Codes: C 0 4 CANCEL AUDITER
----
'''M204.1938:
 
REQUEST FOR SPACE IN TABLE E EXTENDS BEYOND EHIGHPG, BIT MAP PAGES ARE SCANNED FOR FREESPACE
Explanation: A User Language request attempted to store a large object and all of the append pages in Table E have been allocated. Model 204 must scan the bit map pages for previously allocated Table E pages to look for free space to store the large object.
File manager response: The file should be reorganized to compact fragmented Table E space.
Return Codes: I 0 0
----
'''M204.2126:'''
 
'''USER'S PUSHDOWN LIST OVERFLOWED'''
 
'''Explanation:''' The user's pushdown list is an internal stack for maintaining state information for user threads across internal Model 204 subroutines. The user pushdown list lives in each user's server. Its size requirement depends on the complexity of the command or User Language request.

This message is issued whenever Model 204 detects that pushdown list data has spilled into adjacent control structures. Because of potential corruption the user is restarted.
 '''Response:''' Increase the size of the user pushdown list by using the LPDLST parameter of the UTABLE command. Notify your system manager.
 '''System Manager Response:''' If this becomes a frequent occurrence, consider more permanent changes to LPDLST and SERVSIZE, since the pushdown list is a server component.
 '''Return Codes:''' C 0 4 CANCEL
----
'''M204.2329:
 
subsystem <var class="term">name</var> AT <var class="term">location name</var> UNAVAILABLE
Explanation: The indicated subsystem at the specified node is not available for use due to one or more errors occurring at the specified node during start or login processing.
Response: Notify the system manager or try again later.
System manager response: If the subsystem is started, stop the subsystem and resolve communications errors or other errors which occurred at the specified node. After resolving error, use the START SUBSYSTEM command to make the subsystem available for general use. Check to make sure that the LOCATION parameter was set properly in the CCAIN input stream for the Online.
Return Codes: C 0 4
----
'''M204.2551:'''
 
''' {FPL|FCT PG1} IS INVALID FOR FILE: <var class="term">filename</var>'''
 
'''Explanation:''' If the message says FPL, then the FPL (file parameter list) for the associated file is invalid. This could be the result of an incorrect DD, FILEDEF or DLBL statement.

If the message says FCT PG1, then the existence page array page is invalid.

'''File Manager Response:''' If the DD, FILEDEF or DLBL statement is correct and points to the correct data set, then the file must be restored from a backup.
 '''Return Codes:''' C 0 4 AUDITER
----
'''M204.2651:
 NOT ALL THREADS PROCESSED FOR IODEV %C
Explanation: The run is terminated because either:
<ul>
<li>The number of threads specified by NUSERS has been initialized, but there are fewer users of the specified IODEV type than expected.</li>
<li>The DUPTERM number specified by the IODEV card could not be initialized because it exceeded the number of NUSERS.</li>
</ul>
Response: Check that NUSERS matches the total of the listed IODEVs, plus one extra for USER 0. Check also the NOTERM/DUPTERM parameter for the specified IODEV card.
Return Codes: E 80 80 ER
----
'''M204.2719:
 OPEN %C FAILED. UPDATE STATEMENTS ALREADY COMPILED, READ ONLY PRIVILEGES INSUFFICIENT
Explanation: The OPEN or OPENC User Language statement was issued from a request to reopen a file with read-only privileges. However, that request had already been compiled with update statements against the file.
Response: In a User Language request, you cannot use the User Language OPEN or OPENC statement to reopen a file with read-only privileges, if that request contains updates statements against the same file.
Descriptor code: C 0 4 CANCEL
----
'''M204.2739:
 
PARAMETER <var class="term">parm</var> CANNOT BE RESET ON USER 0’S PARAMETER LINE: VALUE IGNORED
Explanation: You reset parameter <var class="term">parm</var> on the User 0 parameter line, but the parameter cannot be set there. The value is ignored, the default value for this parameter remains in effect.
Response: Remove <var class="term">parm</var> from the User 0 parameters, since it will not change the value of the parameter.
Descriptor code: E 0 4 AD
----
'''M204.2746:
 
XSIZE*XRECPPG MAY NOT BE 1 NOR EXCEED 536870911
Explanation: The product of XSIZE and XRECPPG must not exceed 16777216 times 32 minus one, or 536870911. This specifies the maximum number of extension records allowed in a single Model 204 file when using Table X. Also, setting both XRECPPG and XSIZE to 1 is invalid.
The CREATE command is rejected.
Response: Retry the command specifying values for XSIZE and XRECPPG whose product does not exceed the 526870911 limit. Refer to the <var class="book">Rocket Model 204 File Manager’s Guide </var>for more information on file sizes.
Descriptor code: C 0 4
----
'''M204.2826:'''
 
'''%F VERSION IS PRE 6.3. COMPACTION NOT ALLOWED'''
 
'''Explanation:''' An attempt was made to compact a file created prior to Model 204 version 6.3.
 '''File Manager Response:''' Reorganize the file using Model 204 version 6.3.
 '''Return Codes:''' C 0 4 AUDITER

----
'''M204.2831:
 
UPDATES TO DTS FILES NOT SUPPORTED IN THIS ENVIRONMENT
Explanation: DTS files cannot be updated in IFAM, SQL, or PQO environments.
Response: Do not attempt to update DTS file.
Return Codes: C 0 4
----
'''M204.2833:
 
FIELDS CANNOT BE DEFINED IN A FILE WITH ATRPG*ASTRPPG>4000
Return Codes: C 0 4
----
'''M204.2836:'''
 
'''VALUE OF PARAMETER %C INVALID—RESET TO %C'''
 
'''Explanation:''' This is an informational message only.

A parameter was specified with an incorrect value. It has been reset to an internally calculated value that will accommodate other parameter settings. See the description of the parameter named to see what that calculation involves.
 '''System Manager Response:''' The parameter has been reset. No response required.
 '''Return Codes:''' I 0 0 AUDITMS
----
'''M204.2838:
 
%C ONLY VALID IN FILEORG X’100’ FILES
Return Codes: C 0 4
----
'''M204.2839:
 
%C IS A %C, NOT A %C
Return Codes: C 0 4 ECHO
----
'''M204.2841:
 
REMOTE FIELDGROUPS NOT SUPPORTED
Return Codes: C 0 4 ECHO
----
'''M204.2842:
 
INVALID CONTEXT FOR FIELDGROUP
Return Codes: C 0 4 ECHO
----
'''M204.2843:
 
MAXIMUM FIELDGROUP ID EXCEEDED IN RECORD %R IN %F
Return Codes: C 0 4 CANCEL
----
'''M204.2844:
 
MIX OF FIELDS AND FIELDGROUPS, NAME =
Return Codes: C 0 4 SUFFIX ECHO
----
'''M204.2845:
 
INVALID FIELDGROUP CONTEXT FOR %C
Explanation: The $function was used outside of field group context.
Descriptor code:C 0 4 SUFFIX ECHO
----
'''M204.2846:
 
INVALID FIELDGROUP CONTEXT FOR %C
Return Codes: C 0 4 CANCEL
----
'''M204.2847:
 
FIELDGROUP CONTEXT LOST IN RECORD %R IN %F
Return Codes: C 0 4 CANCEL
----
'''M204.2848: INVALID FIELDGROUP ID: %C
 
Return Codes: C 0 4 CANCEL
----
'''M204.2849: REQUIRED KEYWORD %C MISSING
 
Return Codes: X 0 4 ECHO
----
'''M204.2850:
 
%C VALUE MISSING
Return Codes: C 0 4
----
'''M204.2851:
 
%C VALUE "%C" TOO BIG, MUST BE <%C BYTES
Return Codes: C 0 4
----

2852: UPDATE TO MISSING FIELDGROUP OCCURRENCE IN RECORD %R IN %F
Return Codes: C 0 4 CANCEL
----

2853: %C NOT ALLOWED FOR EXACTLY-ONE FIELD
Return Codes: C 0 4
----

2854: ATTEMPT TO DO %C FOR EXACTLY-ONE FIELD: %C
Return Codes: C 0 4 CANCEL
----

2855: FIELD DEPTH+LENGTH UNREPRESENTABLE IN RECORD %R IN %F
Return Codes: C 0 4 CANCEL
----

2856: FIELDNAME VARIABLE %C: EXPECTED %C, GOT %C
Return Codes: C 0 4 CANCEL
----

2857: %C FIELD NOT ALLOWED FOR %C FIELD
Return Codes: C 0 4
----

2858: FIELDGROUP CONTEXT MISMATCH BETWEEN COUNTOCCURRENCES- OF FIELD AND COUNTED FIELD
Return Codes: C 0 4
----

2859: NEW AUTOMATIC FIELD NOT ALLOWED FOR NON-EMPTY FILE
Return Codes: C 0 4
----

2860: FIELD %C ALREADY HAS A COUNT-OCCURRENCES-OF FIELD
Return Codes: C 0 4
----

2861: OCCURRENCE COUNTER %C OVERFLOWED
Return Codes: C 0 4 CANCEL
----

2862: ATTEMPT TO UPDATE AUTOMATIC FIELD %C
Return Codes: C 0 4 SUFFIX ECHO
----

2863: ATTEMPT TO DO %C FOR AUTOMATIC FIELD: %C
Return Codes: C 0 4 CANCEL
----

2865:CANCELATTEMPT TO %C INVALID DATETIME VALUE: %C = %C' 
Return Codes: C 0 4 CANCEL
----

2866: FILE ALREADY HAS %C FIELD
Return Codes: C 0 4
----

2867: FIELDGROUP %C ALREADY HAS %C FIELD
Explanation: If you try to define a second update tracker field of the same type for the same field group, you will invoke message 2867, where %C represents:
<ul>
<li>A CREATE-TIME</li>
<li>A CREATE-TIMEUTC</li>
<li>A CREATE-USER</li>
<li>AN UPDATE-TIME</li>
<li>AN UPDATE-TIMEUTC</li>
<li>AN UPDATE-USER</li>
</ul>

Return Codes: C O 4
----

2868: MINLOBE MUST BE BETWEEN 0 AND %C'
Return Codes: C 0 4
----
'''M204.2869:'''
 
'''CHANGE REFUSED: MINLOBE > 0 FOR %F FIELD %C'''
 '''Return Codes:''' C 0 4 AUDITER
----
'''M204.2870:'''
 
'''CHANGE REFUSED: MINLOBE > 0 FOR %F FIELD %C'''
 '''Return Codes:''' C 0 4 CANCEL AUDITER
----
2871: FIELDGROUP CONTEXT MISMATCH BETWEEN CONCATENATION-OF FIELD AND COMPONENT FIELD'
Return Codes: C 0 4
----

2872: CONCATENATION VALUE TOO LONG FOR FIELD %C'
Return Codes: C 0 4 CANCEL
----

2873: CONCATENATION FIELD %C COMPONENT FIELD %C CONTAINS SEPARATOR CHARACTER'
Return Codes: C 0 4 CANCEL
----

2874: ATTEMPT TO %C A VALUE THAT'S %C: %C
Return Codes: C 0 4 CANCEL
----

2875: CONCATENATION LIST INVALID: %C'
Return Codes: C 0 4
----

2876: INVALID %C VALUE: %C'
Return Codes: C 0 4
----

2877: WITH CLAUSE INVALID: %C'
Return Codes: C 0 4 ECHO

----

 2878: WITH CLAUSE INVALID: FIELD %C IN %F %C
Return Codes: C 0 4 CANCEL
----

2879: REMOTE ID %C MODE %C'
Return Codes: I 0 0 SAVE NOTERM OPR

----

2880: MEMORY DATASETS CANNOT BE PART OF MULTI-DATASET FILE
Return Codes: C 0 4

----

2881: DATA CONVERSION ERROR
Return Codes: C 0 4 CANCEL

----

2882: RECOVERY JOURNAL VERSION %X IS NOT SUPPORTED

Return Codes:E 0 4 OPR

----

2884: [FIELD | FIELDGROUP] WAS PREVIOUSLY DEFINED AS A [FIELDGROUP | FIELD], NEW DEFINITION IGNORED

Return Codes: C 0 4

----

2885: INVALID FIELDGROUP ID: <var class="term">fieldgroup</var>

Return Codes: C 0 4 CANCEL

----

2886: FIELDGROUP ID %C ALREADY EXISTS IN RECORD %R IN %F'

Return Codes: C 0 4

----

2903: FILEORG=X'100' IS NOT SUPPORTED DURING FLOD/FILELOAD

Return Codes: E 0 8
----
'''M204.2933:'''
 
''''Module version mismatch, KOMM=%C, %C=% C''''
 '''Return Codes:''' E 0 4 SNAP

----
'''M204.2934:'''
 
'''FILEORG X<nowiki>''200''</nowiki> not supported for hashed or sorted file organizations'''
 
'''Explanation:''' Hashed or sorted files must be 16M files. The CREATE FILE command
is rejected.
 '''File Manager Response:''' Remove the conflicting FILEORG parameter and reissue CREATE FILE.
 '''Return Codes:''' E 0 4 AUDITMS

----

'''M204.2935:'''
 
'''{CHUNK|CHUNK target} FIELDS MAY NOT BE RENAMED OR DELETED'''
 
 '''File Manager Response:''' Do not attempt to RENAME or DELETE chunks or chunk targets.
 '''Return Codes:''' C 0 4 AUDITER

----

'''M204.2936:'''
 
'''A CHUNK FIELD OF SIZE <var class="term">nnn</var> ALREADY EXISTS FOR THIS FIELD'''
 
'''Explanation:''' For a given CHUNK target field, duplicate chunk sizes are not permitted.
 '''File Manager Response:''' Correct the DEFINE FIELD that caused the message.
 '''Return Codes:''' C 0 4 AUDITER

----

'''M204.2937:'''
 
'''CHUNK SIZE: <var class="term">nnn</var> IS NOT AN INTEGRAL MULTIPLE/DIVISOR OF THE EXISTING CHUNK SIZE: <var class="term">nnn</var>'''
 
'''Explanation:''' A CHUNK field's chunk size must be an integral multiple/divisor of all other chunk's sizes for a given chunk target.
 This message identifies the existing chunk size that conflicts with the new one.
 '''File Manager Response:''' Correct the DEFINE FIELD that caused the message.
 '''Return Codes:''' C 0 4 AUDITER

----

'''M204.2938:'''
 
'''YOU MAY NOT DEFINE MORE THAN 20 CHUNKS FOR A FIELD '''
 
'''Explanation:''' A given chunk target can have at most 20 chunks defined.
 '''File Manager Response:''' Do not try to define more than 20 CHUNK fields for any given CHUNK target field.
 '''Return Codes:''' C 0 4 AUDITER
----

[[Category:Model 204 release notes|Model 204 7.5]]
[[Category:Release notes|Model 204 7.5 ]]

Field value pairs (File architecture)

2013-06-21T04:15:13Z

Rob: /* FLOAT fields */

== Overview ==

The basic unit of storage inside a Model 204 record is the field value pair (or, more literally, "field = value pair"). A record or a fieldgroup contains a series of fieldgroups and field value pairs.

A record can contain field value pairs for fields with the <var>OCCURS</var> attribute, which are described [[??]].

A record or a fieldgroup can contain non-<var>OCCURS</var> field value pairs, whose physical structure is described below, for each storage data type.

== STRING fields ==

The field value pair for <var>STRING</var> fields contains three parts: 

* the field code from [[Table A (File Architecture)|Table A]]; 3 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 2 bytes for all others.
* the length of the value for this pair (0 to 255); 1 byte.
* the value; variable length 0-255 bytes.

So, if you have a NAME field containing 'SMITH' it will be held in either 8 or 9 bytes (depending on the FILEORG), while a NAME of 'FRANKENSTEIN' will be held as either 15 or 16.

== BINARY or CODED fields ==

<var>[[Field Design (File Management)#BINARY attribute|BINARY]]</var> and <var>[[Field Design (File Management)#CODED attribute|CODED]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set. Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. 

For non Optimized Field Extraction Files (x'80) the field value pair contains two parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the value which is '''always''' held as 4 bytes.

For Optimized Field Extraction Files the field value pair contains three parts:

* the field code from [[Table A (File Architecture)|Table A]]; 3 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 2 byte for all others.
* the length of the value for this pair (1 to 4); 1 byte.
* the value (variable length, 1-4 bytes).

By storing a length with all field occurrences, data in records can be read much faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].

== FLOAT fields ==

<var>[[Field Design (File Management)#FLOAT attribute|FLOAT]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set. Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. 

For non Optimized Field Extraction Files the field value pair contains two parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the value which is '''always''' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.

For Optimized Field Extraction Files the field value pair contains three parts:

* the field code from [[Table A (File Architecture)|Table A]]; 3 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 2 byte for all others.
* the length of the value for this pair (1 to 4); 1 byte.
* the value which is '''always''' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.

By storing a length with all field occurrences, data in records can be read much faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].

[[Category:File architecture]]

Field value pairs (File architecture)

2013-06-21T04:13:32Z

Rob: /* BINARY or CODED fields */

== Overview ==

The basic unit of storage inside a Model 204 record is the field value pair (or, more literally, "field = value pair"). A record or a fieldgroup contains a series of fieldgroups and field value pairs.

A record can contain field value pairs for fields with the <var>OCCURS</var> attribute, which are described [[??]].

A record or a fieldgroup can contain non-<var>OCCURS</var> field value pairs, whose physical structure is described below, for each storage data type.

== STRING fields ==

The field value pair for <var>STRING</var> fields contains three parts: 

* the field code from [[Table A (File Architecture)|Table A]]; 3 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 2 bytes for all others.
* the length of the value for this pair (0 to 255); 1 byte.
* the value; variable length 0-255 bytes.

So, if you have a NAME field containing 'SMITH' it will be held in either 8 or 9 bytes (depending on the FILEORG), while a NAME of 'FRANKENSTEIN' will be held as either 15 or 16.

== BINARY or CODED fields ==

<var>[[Field Design (File Management)#BINARY attribute|BINARY]]</var> and <var>[[Field Design (File Management)#CODED attribute|CODED]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set. Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. 

For non Optimized Field Extraction Files (x'80) the field value pair contains two parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the value which is '''always''' held as 4 bytes.

For Optimized Field Extraction Files the field value pair contains three parts:

* the field code from [[Table A (File Architecture)|Table A]]; 3 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 2 byte for all others.
* the length of the value for this pair (1 to 4); 1 byte.
* the value (variable length, 1-4 bytes).

By storing a length with all field occurrences, data in records can be read much faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].

== FLOAT fields ==

<var>[[Field Design (File Management)#FLOAT attribute|FLOAT]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set. Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. 

For non Optimized Field Extraction Files the field value pair contains two parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the value which is '''always''' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.

For Optimized Field Extraction Files the field value pair contains three parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the length of the value for this pair (1 to 4); 2 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 1 byte for all others.
* the value (variable length, 1-4 bytes).

By storing a length with all field occurrences, data in records can be read much faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].

[[Category:File architecture]]

Field value pairs (File architecture)

2013-06-21T03:55:39Z

Rob:

== Overview ==

The basic unit of storage inside a Model 204 record is the field value pair (or, more literally, "field = value pair"). A record or a fieldgroup contains a series of fieldgroups and field value pairs.

A record can contain field value pairs for fields with the <var>OCCURS</var> attribute, which are described [[??]].

A record or a fieldgroup can contain non-<var>OCCURS</var> field value pairs, whose physical structure is described below, for each storage data type.

== STRING fields ==

The field value pair for <var>STRING</var> fields contains three parts: 

* the field code from [[Table A (File Architecture)|Table A]]; 3 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 2 bytes for all others.
* the length of the value for this pair (0 to 255); 1 byte.
* the value; variable length 0-255 bytes.

So, if you have a NAME field containing 'SMITH' it will be held in either 8 or 9 bytes (depending on the FILEORG), while a NAME of 'FRANKENSTEIN' will be held as either 15 or 16.

== BINARY or CODED fields ==

<var>[[Field Design (File Management)#BINARY attribute|BINARY]]</var> and <var>[[Field Design (File Management)#CODED attribute|CODED]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set. Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. 

For non Optimized Field Extraction Files the field value pair contains two parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the value which is '''always''' held as 4 bytes.

For Optimized Field Extraction Files the field value pair contains three parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the length of the value for this pair (1 to 4); 2 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 1 byte for all others.
* the value (variable length, 1-4 bytes).

By storing a length with all field occurrences, data in records can be read much faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].

== FLOAT fields ==

<var>[[Field Design (File Management)#FLOAT attribute|FLOAT]]</var> fields are stored differently depending on whether the file has the Optimized Field Extraction ([[FILEORG parameter|FILEORG]] x'80') bit set. Note that [[FILEORG parameter|FILEORG]] X'100' files automatically also turn on x'80'. 

For non Optimized Field Extraction Files the field value pair contains two parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the value which is '''always''' held as 4, 8, or 16 bytes, depending on the <var>LENGTH</var> attribute.

For Optimized Field Extraction Files the field value pair contains three parts:

* the field code from [[Table A (File Architecture)|Table A]]; 2 bytes.
* the length of the value for this pair (1 to 4); 2 bytes for [[FILEORG parameter|FILEORG]] X'100' files or 1 byte for all others.
* the value (variable length, 1-4 bytes).

By storing a length with all field occurrences, data in records can be read much faster. The possible tradeoff on performance versus space is discussed in [[File Design (File Management) Optimized Field Extraction Files|File Design]].

[[Category:File architecture]]

Managing file groups

2013-05-14T23:21:47Z

Rob: /* Partitioning for performance */

== Overview ==
File groups are sets of files which process as if they were one.

There are three types:
* Permanent groups
* Temporary groups, and
* Ad-hoc groups

== Permanent, Temporary and Ad-hoc Groups ==

===CREATE GROUP command and the types of groups ===
Permanent and Temporary file groups are created using the CREATE GROUP command. Ad-hoc groups exist only for a particular 'ín' clause (and any label references which refer to the statement). The following chart explains how they are created: 
<table>
<tr class="head">
<th>Type of group</th>
<th>Created...</th>
</tr>
<tr>
<td>Permanent </td>
<td>
By the system manager using the CREATE command.
User access is determined by the privileges defined for the file group.
Use the following syntax to create a permanent group: 
CREATE PERM GROUP groupname

FROM {filename [AT location] [(OPTIONAL) | (MANDATORY)]} ,... [PARAMETER parameter[=value] [PARAMETER parameter[=value]]...

.

.

.

END

For information about creating permanent groups, see [[CREATE command: Permanent group|CREATE PERM GROUP]]
</td>
</tr>
<tr>
<td>Temporary</td>
<td>
By an individual user with the CREATE command and can be referenced only by that user. 
Temporary group names exist only during the current login session and are deleted automatically when you log out, unless you delete them during the session. 
Use the following syntax to create a temporary group:
CREATE [TEMP] GROUP groupname FROM filename
[,filename ...][PARAMETER parameter_list]
.
.
.
END

The parameters available for temporary file groups are detailed in [[CREATE command: Temporary group|CREATE TEMP GROUP]].
</td>
</tr>
<tr>
<td>Ad hoc</td>
<td>
Within a User Language request by prefacing a statement with the clause: 
IN <var class="term">file1</var>, <var class="term">file2</var> [,<var class="term">file3</var> ...]

Ad hoc groups have no name and exist only for the current request. They allow record retrieval from many files at once without defining a group in advance. As in any IN clause, all of the files in an ad hoc group must be opened before the group is mentioned. For more information, see the description of Ad hoc groups in the <var>Rocket Model 204 User Language Manual</var>.
</td>
</tr>
</table>

== Using Groups ==

There are a number of reasons why a file manager might set up file groups:

=== Files with large numbers of record ===
A single Model 204 file may only contain 16.7 million record slots. As applications grow, this limit may not be enough.

Define a permanent file group can support much larger sets of data: there can be up to 254 files in a file group.

Normally, if you take this approach, you would not randomly place the records anywhere in the group, but rather you would partition the files based on some attribute. For example, you may use the Social Security Number to decide which file in a group to place a particular record in. '''Hint:''' because some identifiers have hidden meanings (the high order digits of the Social Security Numbers used to identify the region where the application was made, for example), often the low order digits make a better randomizer.

=== Partitioning for performance ===
But even files where you do not expect to hit the record limit might benefit from partitioning. If you were, for example, to most commonly read data for a particular year, you would probably find that placing all the records for a year in different files would perform better than putting all of the records in a single file and indexing the year for easy access.

See [[Files, Groups, and Reference Context#IN GROUP MEMBER clause|IN GROUP MEMBER clause]] for more information.

=== Procedure groups in APSYs ===

When creating Application Subsystems (APSYs) you may (and are encouraged to) specify that the procedure file is actually a group.

You may, in your application design, have large amounts of code identical in multiple APSYs, but you may require different global setting between the APSYs. Because, at compile time, procedure files are searched in the order they appear in the group. you can put different 'first' procedure files, each followed by the same code base. 

See "Overview of the Subsystem Management facility" in [http://www.rocketsoftware.com/m204/products/index/documentation/v7r4/M204-System-Mgr/view The Model 204 System Managers Guide] for more information on APSYs.

=== Postponing reorganizations with Groups ===

Note: the following technique cannot be used if there are references in your code to Internal Record Numbers (IRNs). IRNs (without also specifying a group member, can not be used against group files)

* File X is almost full
* Define File Y, which looks like File X (same field names)
* File Y can be defined to have whatever table sizes it needs
* Group File X and Y together, with File Y as the specified UPDTFILE
* Run your application against grouped files X and Y
Example:
CREATE PERM GROUP X FROM X, Y
PARAMETER UPDTFILE = Y
END


[[Category:File management]]

Field design

2013-05-14T23:16:13Z

Rob: /* Counting occurrences of a field */

==Overview==
The field structures in <var class="product">Model 204</var> are at the heart of providing applications which perform the functions that you require in the most efficient manner possible.

This page discusses exactly how the data structures should be defined.

==Designing records, fieldgroups and fields==
When setting up a <var class="product">Model 204</var> file, you must first decide what fields the records will contain. A record in a personnel file, for instance, might contain a social security number field, a last name field, a spouse's name field, and so on. 
===Variable record formats===
The record in <var class="product">Model 204</var> is a very loose concept. Physically, it is simply a collection of fields (data items).

Any field in the [[#Table A (File Architecture) Internal File Dictionary|Table A Dictionary]] may appear in any record in the file. It is quite possible that you create a file with many different logical record types with only a few (or even none) appearing in all of the records.

Thus, each record is not required to have a value for every field; so that record lengths are variable, and it can be argued that the entire concept of a record 'format' does not apply to Model 204 files. If an employee's address is unknown or doesn't exist in a particular logical record, for example, the address field will be left out of the record altogether. The exception to this is [[#Preallocated fields|Preallocated fields]]. If they are are defined for a file, space is reserved in each record for all such fields, even if they would never exist for that logical record. 

===Multiply occurring fields===
Most types of fields can be multiply occurring, that is, have more than one value per record. For example, the CHILD field can appear no times, once, or several times in one record. 

==Field descriptions and attributes==

When you describe a field in a <var class="product">Model 204</var> file with the [[DEFINE FIELD command|DEFINE FIELD]] or [[REDEFINE command|REDEFINE FIELD]] commands, you specify a field description that consists of the field name followed by a list of field attributes. These attributes determine how a field may be accessed and how it is stored internally. This section describes the attributes supported for <var class="product">Model 204</var> fields. 

Within a record, there is usually no restriction on the number of different fields that can have the same attribute (the exception being the key fields for Sorted and Hash Key files). For example, several fields within the same record can have ORD CHAR indices built for them.

Multiply occurring fields
For most field attributes there is almost no restriction on the number of times a particular field can occur within a record. This makes file / record design very flexible. If you have a record which has child details as repeating fields or groups, for example, any number may be supported. 

Singly occurring fields
There are a few attributes which require a field to have no more than one occurrence per record:

*NUMERIC RANGE
*Sort key fields
*Hash key fields

and others which require a field to have no more than one occurrence per record or fieldgroup (depending on the context in which they are defined):

*AT-MOST-ONE
*EXACTLY-ONE

== <div id="Field Design (File Management) Indexing Fields">Indexing Fields</div> ==

Model 204 files can become quite large, and so it is almost always preferable to directly access the record or records which have particular characteristics. As part of your design process, you should have identified which field(s) are likely to be used for direct retrieval of sets of records.

For example, if you have a personnel file, you are likely to have a unique identifier for each employee, and it is also likely that you will often want to process only the record or records with that ID.

Where retrievals are attempted against non indexed fields, a search of Table B must be done, and the danger of request cancellation because [[MBSCAN parameter|MBSCAN]] is exceeded exists.

Model 204 supports a few different ways to implement these direct searches, and Rocket Software recommends that the default choice for indexing is the ORDERED attribute.

===ORDERED and NON-ORDERED attributes===
Fields used in retrieval specifications should normally be defined as ORDERED (unless one of the other indexing methods, described below) is chosen. NON-ORDERED, the default means that all retrieval requests need to scan the records directly in Table B to find the selected records.

For the architectural approach to the implementation of the ordered index, refer to: [[Table D (File Architecture)#Understanding the Ordered Index|understanding the Ordered Index]].

====Choosing an order type====
An ORDERED field can have an index with either CHARACTER or NUMERIC ordering. This is called its order type. The field's order type and updating characteristics are declared with the DEFINE command. You can specify only one order type for a field. ORDERED NUMERIC fields contain numeric values stored as standardized floating-point numbers in one section of the index and nonnumeric values in EBCDIC order in another section. 
ORDERED CHARACTER fields
ORDERED CHARACTER fields use the standard EBCDIC collating sequence. If a field is ORDERED CHARACTER, all values of the field are stored in the Ordered Index in EBCDIC collating sequence order.
ORDERED NUMERIC fields
A string field value is considered NUMERIC if it consists of digits, with one optional decimal point, and an optional plus or minus sign at the beginning of the string. The value of the number cannot be greater than 1075 or less than -1075. 
If an ORDERED NUMERIC field is also FLOAT, exponential format is allowed. Values for BINARY, FLOAT (8), and FLOAT (16) fields are rounded to 15 significant digits. Values for FLOAT (4) fields are rounded to 6 significant digits. 
An invalid value is stored as an unconverted string. 
In ORDERED NUMERIC fields, leading zeros are ignored. For example, 001 and 1 are considered equivalent and are maintained in the ORDERED NUMERIC portion of the B-Tree as the same value. For fields that require a meaningful leading zero (such as zip code), use ORDERED CHARACTER.
Values of an ORDERED NUMERIC field that do not satisfy the definition of NUMERIC are stored in a separate section of the Ordered Index and processed in EBCDIC order. During FOR EACH VALUE and FOR EACH RECORD IN ORDER BY FIELD processing of an ORDERED NUMERIC field, these values are processed after the valid NUMERIC values unless you restrict the range of values. 
Default order types
If a field is defined as ORDERED without specifying which type of ordering to create, a default order type is used. The default depends on whether the field is STRING, BINARY, or FLOAT:
<table>
<tr>
<th>For...</th>
<th>The default order type is...</th>
</tr>
<tr>
<td>STRING</td>
<td>ORDERED CHARACTER</td>
</tr>
<tr>
<td>BINARY or FLOAT</td>
<td>ORDERED NUMERIC </td>
</tr>
</table>
====ORDERED field definition====
The ORDERED attribute has options that allow you to determine the type of ordering the Ordered Index is to have, as well as some of the characteristics of the Ordered Index tree as it expands or is rebuilt. These options are described in the discussions of order type and Ordered Index tree structure that follow.
Defining ORDERED field attributes
The DEFINE command is used to specify a field's attributes. (See .) The format of the DEFINE command with the ORDERED attribute options is:
Syntax
DEFINE FIELD <var class="term">fieldname</var> WITH <var>ORD</var>ERED
[<var>CHAR</var>ACTER | <var>NUM</var>ERIC][<var>SPL</var>I<var>T</var>PCT <var class="term">s</var>] [IMMED <var class="term">i</var>]
[<var>LRES</var>ERVE <var class="term">r</var>] [<var>NRES</var>ERVE <var class="term">n</var>]

Note
The default designation for a field is NON-ORDERED. Ordered Index tree parameters do not apply for a NON-ORDERED field. 
<var>CHARACTER</var> and <var>NUMERIC</var> order types are described above.
<var>SPLITPCT</var>, <var>IMMED</var>, <var>LRESERVE</var>, and <var>NRESERVE</var> parameters are described in [[Table D (File Architecture)#Ordered Index spacing parameters|Ordered Index spacing parameters]]. 
Choosing between ORDERED or NUMERIC RANGE
The ORDERED attribute has several advantages over the NUMERIC RANGE attribute, and as such should be the normal choice. Specifically: 
<ul>
<li>Ordered Index allows for multiple occurrences of the same numeric field in a record. The NUMERIC RANGE attribute issues an error message whenever an attempt is made to store more than one occurrence of the same NUMERIC RANGE field in the same record.</li>
<li>Cost of updating an ORDERED field is lower than that of a NUMERIC RANGE field. The NUMERIC RANGE field requires multiple attributes to be maintained to describe the characteristic of a number. The cost of an update to the Ordered Index is always proportional to the depth of the tree.</li>
<li>In most cases, especially with large numbers, the Ordered Index uses less space to maintain the index information.</li>
<li>Ordered Index allows for more accurate range requests, with numbers representable by IBM double-word floating-point numbers.
Although range retrievals are usually faster for ORDERED fields than for NUMERIC RANGE fields, the size of the range interval and the density of the distribution of values over that range are the principal determining factors. NUMERIC RANGE retrievals are faster for very large ranges with densely distributed data values. 
</li>
</ul>

====Choosing between ORDERED or FRV====
The ORDERED attribute is usually a better alternative to the FRV attribute. Although FRV fields with small numbers of values may perform faster in value loop processing, they lose this advantage if the found values are required to be in order, and as the number of values increase. FRV ordered retrievals require additional sorting. For retrievals in ascending or descending order, ORDERED fields are more efficient. For (presumably rare) right-adjusted character strings in order, ORDERED fields require additional sorting.
Compatibility ORDERED with other field attributes
Use the following guidelines when specifying the ORDERED attribute:
<ul>
<li>Field cannot be both ORDERED and FRV.</li>
<li>Field cannot be both ORDERED NUMERIC and NUMERIC RANGE.</li>
<li>Field can be both KEY and ORDERED (but serves little or no purpose).</li>
<li>Field can be both INVISIBLE and ORDERED.</li>
<li>Field can be both DEFERRABLE and ORDERED. If the field is DEFERRABLE, the index updates can be written out to a (see [[#DEFERRABLE and NON-DEFERRABLE attributes|DEFERRABLE and NON-DEFERRABLE attributes]] for details). </li>
<li>UNIQUE field must be ORDERED. </li>
<li>Hash and sort key fields and record security fields can be ORDERED.</li>
<li>and... fields which are defined as KEY may be converted to ORD with no code changes required (as direct retrievals will work with either type of ORD field)</li>
</ul>

For an architectural view of the ordered index, see [[#Table D (File Architecture) Ordered Index|the Ordered Index]]

===KEY and NON-KEY attributes===
The KEY and NON-KEY attributes govern whether to create a hash index for a field or not. If KEY is specified, an index is created for the field. Retrieval commands will access the index for that field. If NON-KEY is specified, every record in the table is examined. The NON-KEY attribute is a default field description. This section provides information about space and performance for each of these attributes.
KEY attribute
When storing fields that have the KEY attribute, <var class="product">Model 204</var> makes special entries in the hash index. During retrieval, <var class="product">Model 204</var> goes directly to the appropriate index entry to find which records satisfy the selection criteria, without searching through other records in the file. This makes retrieval based on KEY fields extremely fast. 
However, these index entries must be updated, when User Language statements or Host Language Interface functions add, change, or delete fields. Processing might take slightly longer for KEY fields than for NON-KEY fields. In addition, the space occupied by the index entries can be considerable, especially in large files and in fields that take on many values. 
NON-KEY attribute
No index entries are maintained in Tables C and D for NON-KEY fields. When a retrieval is performed based on the value of NON-KEY fields, the data in Table B must be searched directly. The direct search can have a significantly adverse effect on performance, if a large number of records must be searched. 
However, the cost of the direct search can be greatly reduced in some cases where both KEY and NON-KEY fields are specified in the retrieval conditions. <var class="product">Model 204</var> reduces the number of records to be searched directly by performing the indexed selection first. Records that are definitely eliminated, based on the KEY conditions, are not searched directly. 
Choosing between KEY or NON-KEY
Keep the following guidelines in mind when deciding to designate a field as KEY or NON-KEY:
<ul>
<li>If space is not an overriding consideration, designate fields that are used frequently for retrievals of equality as KEY.</li>
<li>If a field is updated frequently and only occasionally used for retrieval, define it as NON-KEY.</li>
<li>If a field is used frequently for retrievals and updated frequently, the choice is less obvious. If you reserve sufficient space in Tables C and D for adding inversion entries, the field initially can be defined as NON-KEY and changed later with the REDEFINE command (see ). </li>
</ul>

===FOR EACH VALUE (FRV) and NON-FRV attributes===
The FRV attribute is useful when creating fields used in value loop processing. If the FRV attribute is not specified when a field is defined, the NON-FRV attribute is assumed. If this attribute is set, the field is usually assigned the KEY attribute as well. 

Table space for FRV fields
Every value of an FRV field is automatically encoded in Table A, whether or not the value is stored in Table B (that is, INVISIBLE). In addition to more Table A space, FRV fields require slightly more Table C and Table D space than ordinary key fields. Because of these additional space requirements, the FRV attribute is most frequently defined for fields in which the number of different values does not exceed approximately 200.
Using the FRV attribute
The FRV attribute behaves in a special way when combined with the BINARY attribute. This is discussed in [[#BINARY attribute|BINARY attribute]].
Fields cannot be defined with the FRV attribute in First-Normal Form (1NF) files. See See 1NF file model for more information about them. 

==== FRV attribute, FRV User Language Statement ====
Value loops
User Language provides a special construction called a value loop that executes a set of statements once for each different value of an indicated field. The loop is initiated by the FOR EACH VALUE statement; the field must have the FRV or ORDERED attribute. The FOR EACH VALUE statement has Host Language equivalents in IFFDV and IFGETV. A value loop is illustrated in the following example:
Example
EACH.STATE:
FOR EACH VALUE OF STATE
GET.RECS:
FIND ALL RECORDS FOR WHICH
STATE = VALUE IN EACH.STATE
END FIND
TOT.RECS:
COUNT RECORDS IN GET.RECS
PRINT.CT:
PRINT VALUE IN EACH.STATE -
WITH COUNT IN TOT.RECS AT COLUMN 20
END FOR

On the first pass through the loop, a value of STATE, such as DELAWARE, is selected. The last statement prints DELAWARE and the number of records with the field-name-equals-value pair: STATE = DELAWARE. On the next pass, another value is chosen, such as IOWA, and so on until all values of the STATE field have been processed exactly once.
Using the IN ORDER option
The IN ORDER option of the FOR EACH VALUE statement specifies that the values of an FRV KEY field be presented in an ordered sequence-ascending, descending, numerical, right adjusted. This option improves performance by avoiding Online sorts of a large number of records, because only the values are sorted instead of a large found set of records. 
Value loop processing for ORDERED fields
You can also use value loop processing on fields with the ORDERED attribute. When the FOR EACH VALUE statement with the IN ORDER option is used for NON-FRV, ORDERED fields, ORDERED retrievals can be significantly faster than FRV ordered retrievals. See [[#ORDERED and NON-ORDERED attributes|ORDERED and NON-ORDERED attributes]] for a description of the ORDERED attribute. 
Value loop processing can be made more flexible and efficient by using pattern matching, described in the <var class="product">Model 204</var> User Language Manual.

===NUMERIC RANGE and NON-RANGE attributes===
Prior to the introduction of ORDered NUMeric fields, Model 204 permitted range retrieval (a field value numerically equal to, less than, greater than, or between certain values) with the NUMERIC RANGE attribute. This attribute indexes the component parts of a numeric value and then joins them, to provide rapid numeric range retrievals without a direct search of the records.
If the NUMERIC RANGE attribute is not specified when a field is defined, the NON-RANGE attribute is assumed. 

Rocket Software recommends that, for any new fields being defined,the ORDERED NUMERIC attribute is used in preference to NUMERIC RANGE.

The NUMERIC RANGE attribute may not be set where the product of [[ASTRPPG parameter|ASTRPPG]] * [[ATRPG parameter|ATRPG]] is greater than 4000 (available in FILEORG parameter|FILEORG x'100' files).
====NUMERIC RANGE retrieval specifications====
The following retrieval specifications, with their symbolic operator equivalents in parentheses, can be used:
fieldname IS value
fieldname IS EQ (=) value
fieldname IS LESS THAN (LT or <) value
fieldname IS GREATER THAN (GT or >) value
fieldname IS BETWEEN (GT or >) value AND (LT or <) value
fieldname IS GREATER THAN (GT or >) value AND LESS THAN (LT or <) value
fieldname IS LESS THAN (LT or <) value AND GREATER THAN (GT or >) value

====Examples====
The following examples show numeric retrieval specifications:
ALL:
FIND ALL RECORDS FOR WHICH AMOUNT IS 53.00
DATE IS BETWEEN 050500 AND 050532
END FIND

These specifications retrieve records for which AMOUNT has a value of 53.00 (or 53 or 053, and so on) and DATE has a value in May 2005.
====NUMERIC RANGE retrieval fields====
The values of NUMERIC RANGE retrieval fields can be either positive or negative numbers that have as many as ten digits on either side of the decimal point (20 digits maximum). When such fields are stored, <var class="product">Model 204</var> makes many entries in Tables C and D as well as some special entries in the field name (attribute) section of Table A. These entries are quite complex, and NUMERIC RANGE retrieval fields require both more storage space and more time to store and update than do KEY fields. 
In deciding whether to define a field as NUMERIC RANGE or NON-RANGE (and NON-ORDERED), use the same criteria used in [[#Choosing between KEY or NON-KEY|Choosing between KEY or NON-KEY]], keeping in mind the additional overhead caused by the extra index entries for RANGE fields.
====Interpreting nonnumeric values====
If a NUMERIC RANGE field is stored with a value that <var class="product">Model 204</var> cannot interpret as a number, the system stores a special index entry for the record. The field name of this special entry consists of the NUMERIC RANGE retrieval field name with ++ appended. The entry has a value of NON NUMERICAL. Thus, the following User Language retrieval retrieves all records with nonnumerical values of AGE:
ALL:
FIND ALL RECORDS FOR WHICH
AGE++ = NON NUMERICAL
END FIND

This can be useful in locating bad input data.
====Compatibility with other attributes====
You can specify as many NUMERIC RANGE retrieval fields in each record as you need. However, a particular NUMERIC RANGE retrieval field might not be multiply occurring within any one record.
You cannot specify the NUMERIC RANGE attribute in the following circumstances:
<ul>
<li>With any field defined as FLOAT</li>
<li>For any field in a 1NF file</li>
</ul>
For a chart showing valid and invalid attribute combinations, see [[ Field Attribute Combinations#Combining attributes|Combining attributes]]. If you are defining field attributes with FILEMGMT, you will not be allowed to specify incompatible attributes.

== Data Typing ==

The following attributes are described individually in the next sections. They represent the way the field is physically stored. Only one of these may be assigned to any field.
<ul>
<li>STRING</li>
<li>BINARY</li>
<li>BLOB, CLOB, MINLOBE</li>
<li>FLOAT</li>
<li>DATETIME</li>
<li>UTF-8 or UTF-16</li>
<li>VISIBLE, INVISIBLE</li>
</ul>

===STRING attribute===
STRING is the default attribute for all fields. If your data is character or alphanumeric, such as names and addresses, specify a data type of STRING. STRING fields are also useful if you plan to store mixed data types in an image. 
The length of a STRING field is limited to 255 bytes, because the first byte of a STRING data field is a count byte-that is, a byte that contains the length of the rest of the string. 

===BINARY attribute===
Fields whose values are decimal integers can alternatively be compressed and stored as 4-byte binary numbers with the BINARY attribute. Specifying BINARY saves Table B space if the average value of the field is from 4-9 digits long.
Acceptable BINARY values
To be compressed successfully, the value must be1-9 digits long and can contain a minus sign. It cannot contain a plus sign, a decimal point, or leading zeros. If the value cannot be compressed, <var class="product">Model 204</var> refers to the CODED/NON-CODED field attribute (which the BINARY attribute usually overrides) to decide how to store the value. 
BINARY and FRV fields
The BINARY attribute overrides the FRV attribute, except for values that cannot be compressed. If the field cannot be compressed, it will be stored in Table A in either the FEW-VALUED or MANY-VALUED pages depending on the field definition. For instance, AGE has been defined with the BINARY and FRV attributes and takes on the values:
23, 04, -34578, 935., 20,
+8754, and TWO

The statement FOR EACH VALUE OF AGE retrieves only the values:
04, 935., +8754 and TWO

If BINARY is not specified when a field is defined, the STRING attribute is assumed.
BINARY fields and NUMERIC VALIDATION files
If a BINARY field is defined in a NUMERIC VALIDATION file model file, <var class="product">Model 204</var> provides numeric data type validation. If you try to store nonnumeric or other nonconforming (that is, noncompressible) data in a BINARY field in a NUMERIC VALIDATION file, <var class="product">Model 204</var> cancels the request with the following message:
M204.2123: VALUE SPECIFIED VIOLATES BINARY DATA TYPE VALIDATION IN RECORD <var class="term">recno</var>, FIELD IGNORED: <var class="term">fieldname</var> = <var class="term">value</var>

<div id="BLOB attribute"></div>
<div id="CLOB attribute"></div>
<div id="MINLOBE attribute"></div>

===BLOB, CLOB and MINLOBE attributes===
The BLOB and CLOB attributes describe Large Object data that may be used to store long strings in the database, for example, long XML strings. This means that <var class="product">Model 204</var> User Language threads can exchange Large Object data with a partner process via the Universal Buffer and/or the MQ/204 Interface. 
<ul>
<li>Via the Universal Buffer, Large Object data can be sent and received using User Language READ IMAGE and WRITE IMAGE statements.</li>
<li>Via the MQ/204 Interface, Large Object data can be sent and received by MQPUT and MQGET statements, stored and retrieved from the database with User Language STORE, ADD, and assignment statements using the BUFFER reserved area name.</li>
</ul>
Files created in V6R1.0 and later are not compatible with earlier versions of <var class="product">Model 204</var>, because of Large Object support and the concomitant changes to the FPL page.
Introducing Large Object field types
The Large Object field types includes the following Character Large Object (CLOB) and Binary Large Object (BLOB) attributes. 
<ul>
<li>CLOBs are character strings. </li>
<li>BLOBs are binary strings. No translation is performed when the object is sent or received.</li>
</ul>
Limitations of Large Object support
<ul>
<li>Currently there is a limit of 2,147,483,647 bytes (or two gigabytes) of data per Large Object.</li>
<li>For CLOBs the translation of ASCII to EBCDIC and back is handled by the design of your application.</li>
<li>For BLOBs no translation is performed.</li>
<li>The User Language INSERT statement is not supported.</li>
</ul>
Handling Large Object data
The BLOB and CLOB attributes are supported as follows:
<ul>
<li>You can create, open, and recover a file with a BLOB or CLOB attribute. The Large Object field can be multiply occurring. </li>
<li>The DELETE fieldname statement supports the Large Object data. This statement frees the Table B and Table E data.</li>
<li><var>You can store and add a Large Object data to the file you have created from the Universal Buffer, BUFFER. Using an assignment statement you can transfer Large Object data from a field into the Universal Buffer.</var></li>
<li>You can set the number of Table E pages during file creation with PARAMETER ESIZE= n.</li>
<li>You can view the EHIGHPG parameter to determine the highest number of Table E pages in use.</li>
<li>You can modify the size of Table E with an INCREASE or DECREASE command.</li>
<li>The DELETE FIELD fieldname command supports the Large Object field type, so you can delete a Large Object field name. However, the space in Table B and Table E is not automatically available for reuse. </li>
<li>$LOBLEN(lob-field-name) function is available for your use.</li>
<li>Dictionary/204 and the Cross-Reference facility support Large Object field types.</li>
<li>NULL Large Object data is supported.</li>
<li>Transaction back out is supported for Large Object field types.</li>
<li>Field-level security is supported.</li>
</ul>
BLOB and CLOB compatibility with other attributes
Combining BLOB or CLOB with other field attributes, except OCCURS, MINLOBE, or UTF-8, is meaningless. Use of any other attributes produces the following message:
M204.0411: CONFLICTING ATTRIBUTES: ([BLOB | CLOB]) attribute2

Using the MINLOBE (MLBE) attribute
You can use the MINLOBE attribute only with a BINARY LARGE OBJECT (BLOB) or a CHARACTER LARGE OBJECT (CLOB) field in a file with FILEORG X'100'. The MINLOBE attribute cannot be paired with the OCCURS attribute. You can redefine the MINLOBE attribute value.
Syntax
MINLOBE nnn

The default and smallest value for MINLOBE is 0, which means that all values of the field are stored in TABLEE. The maximum value of MINLOBE is 200.
If a field has the MINLOBE attribute greater than 0:
<ul>
<li>And the value of the field is not longer than MINLOBE, then the value is stored in Table B or Table X, instead of Table E.</li>
<li>The User Language CHANGE statement is not allowed and the following error is displayed:
M204.2869 CHANGE NOT ALLOWED: MINLOBE > 0 FOR FIELD fieldname

Any CHARACTER LARGE OBJECT or BINARY LARGE OBJECT field which does not use the CHANGE statement benefits from setting MINLOBE 200.
</li>
<li>The RESERVE clause is ignored on the User Language ADD statement.</li>
</ul>
Storing and updating LOBs
All large object data (LOBs) in a FILEORG=X'100' file are chained. There are four bytes per Table E page overhead for chained LOBs. The pages used by a chained LOB are not contiguous.
Handling LOBs in FILEORG=X'100' files also has the following effects:
<ul>
<li>The RESERVE clause is ignored in a LOB field ADD statement processing, as well as the STORE RECORD statement processing of fieldname=value pairs.
Consequently, the CHANGE statement does not fail because of insufficient reserved space. If the CHANGE statement requires that a LOB field be extended, it is.
</li>
<li>The value of the EHIGHPG parameter is always one less than the high water mark of the number of pages used to hold LOBs. (Unless none were ever added, in which case it is zero, not -1).</li>
<li>The value of the EPGSUSED parameter is always the number of pages currently being used to hold LOBs.</li>
<li>The COMPACTE command does not process FILEORG=X'100' files, just as it does not process a file created in V6R1 or earlier. Thus, issuing a COMPACTE command for a FILEORG X'100' file produces an error message.</li>
<li>The TABLEE command effectively does a VIEW ESIZE EHIGHPG EPGSUSED for a FILEORG X'100' file. Consequently there are no TABLEE overhead pages in a FILEORG=x'100' file.</li>
</ul>

===FLOAT attribute===
Any field whose values are always, or almost always, numeric might be more efficiently stored in a floating-point representation than in character form. Using FLOAT can also reduce the time spent in data type conversions for fields used frequently in User Language or Host Language Interface computations. 
Very large or very small numbers, or numbers with many significant digits, occupy considerably less space in floating-point form. 
Floating-point fields are fully supported by User Language, the Host Language Interface, and the File Load utility. For more information about storing values in floating-point fields, such as conversion, rounding, and precision rules, see the <var class="product">Model 204</var> User Language Manual.
Note
If FLOAT is not specified when a field is defined, the STRING attribute is assumed.
Defining floating point fields
Field values are stored in floating-point by specifying the FLOAT attribute in the DEFINE FIELD command and supplying a LENGTH of 4, 8, or 16. The length supplied determines the precision of the floating-point field being defined. For example, to define a long precision field, specify:
Syntax
DEFINE FIELD <var class="term">fieldname</var> WITH FLOAT LEN 8

You can define three types of floating point fields through the FLOAT and LENGTH attributes.:
<table>
<tr>
<th>
Type of floating-point field</th>
<th>

Occupies...</th>
<th>
Holds a maximum of...</th>
<th><var class="product">Model 204</var> maintains a maximum precision of...</th>
</tr>
<tr>
<td>Short precision</td>
<td>4 bytes</td>
<td> 6 significant digits</td>
<td> </td>
</tr>
<tr>
<td>Long precision</td>
<td>8 bytes</td>
<td>15 significant digits </td>
<td>15 significant digits</td>
</tr>
<tr>
<td>Extended precision</td>
<td>16 bytes </td>
<td>31 significant digits</td>
<td>15 significant digits </td>
</tr>
</table>
Acceptable values
The floating-point data type uses IBM hardware's floating-point representation.
A value of negative zero (X'800...0') cannot be stored in a preallocated FLOAT field. 
FLOAT with NUMERIC VALIDATION files
If you define a FLOAT field in a NUMERIC VALIDATION file model file, <var class="product">Model 204</var> provides numeric data type validation. Trying to store non-conforming data in a FLOAT field in a NUMERIC VALIDATION file causes <var class="product">Model 204</var> to cancel the request with the following message:
M204.2124: VALUE SPECIFIED VIOLATES FLOAT DATA TYPE VALIDATION IN RECORD <var class="term">recno</var>, FIELD IGNORED: <var class="term">fieldname</var> = <var class="term">value</var>

Compatibility with other attributes
STRING, BINARY, NUMERIC RANGE, and INVISIBLE cannot be specified for a FLOAT field. 
===Storing invalid numeric data: FLOAT or ORDERED NUMERIC===
Prior to Version 5.1, <var class="product">Model 204</var> did not enforce storage rules for floating point numbers outside the valid range and could incorrectly store invalid floating point data as small, but nonzero floating point numbers.
The valid range of floating point numbers is:
1E-74 through 7.2370E+75

<ul>
<li>7.2371E75 is outside the valid range for floating point numbers. Prior to Version 5.1, it was stored as a true floating point number of the order of E-78 following the error message:
M204.0563: ARITHMETIC OVERFLOW
</li>
<li>1E-75 is also out of the valid range; it was stored as a true floating point number 1E-75.</li>
</ul>
As of Version 5.1:
<ul>
<li>Storing the value 7.2371E75 in a FLOAT field does not result in error <var>M204.0563: ARITHMETIC OVERFLOW.</var> The value is treated as an invalid floating point number; it is stored as a data string '7.2371E75'.</li>
<li>1E-75 is treated as an invalid floating point number and stored as a data string '1E-75'.</li>
</ul>
If an invalid value is stored for a field with the ORDERED NUMERIC attributes, the value stored in the Ordered Index is the data string. That data string is stored on the Invalid Numeric Data portion of the Ordered Index. This changes the output order of these values when the ordering is done against the Ordered Index, for example, when using the User Language IN ORDER BY or FOR EACH VALUE clauses.
Identifying pre-Version 5.1 floating point values
The changed storage of invalid floating point values affects only new values you store in Version 5.1. Values already stored in the file are not corrected. You must find and correct these values, if necessary. The following procedure may help you, if the field is also defined as ORDERED NUMERIC or FRV.
Floating point ordered numeric values outside the valid range may be explicitly identified, removed, and replaced with valid values. This process can be done either before or after migrating to Version 5.1. Migrating itself, without rebuilding files, does not remove the bad values; nor does issuing a REORGANIZE ORDERED INDEX command against the file, regardless of the release version of the REORGANIZE command. 
It is safer to rebuild under Version 5.1, because invalid values are inserted into the Invalid Numeric section of the Ordered Index. If you rebuild under a prior version, the only safeguard against improper reinsertion of invalid values is their explicit identification and removal prior to the rebuild process. You can confirm the presence of invalid values by running a procedure such as the following. Note the following fields.
<ul>
<li>problem_field
For each occurrence of problem_field substitute a <var class="product">Model 204</var> field name, which you suspect stores invalid floating point values. problem_field must be an ORDERED NUMERIC or FRV field, which is already defined to the file.
</li>
<li>TEMP_FIELD
A <var class="product">Model 204</var> field name of an ORDERED CHARACTER field defined for use in only the following procedure.
</li>
</ul>
DEFINE TEMP_FIELD (ORD CHAR)
BEGIN
STORE RECORD
* MAKE SURE THAT THERE IS A TRUE FLOATING PT 0
* FOR THE SUSPECTED FIELD
problem_field = 0
TEMP_FIELD = X
END STORE
END

BEGIN
FDV: FIND ALL VALUES OF problem_field
FR: FOR EACH VALUE IN FDV
%X = VALUE IN FR
IF %X = 0 THEN
%COUNT_OF_ZEROS = %COUNT_OF_ZEROS + 1
END IF
END FOR
IF %COUNT_OF_ZEROS GT 1 THEN
PRINT ' FIELD CONTAINS VALUES OUT OF RANGE'
END IF
END
BEGIN
FD: FD
TEMP_FIELD = X
END FIND
FR IN FD
* REMOVE THE DUMMY RECORD YOU ADDED TO THE FILE
DELETE RECORD
END FOR
END
DELETE FIELD TEMP_FIELD

Note: The previous procedure can find floating point values out of range only if the field is FRV or ORDERED. <var class="product">Model 204</var> customer support recommends that you add the ORDERED attribute to use the previous procedure.
===DATETIME (DT) attribute===
The DATETIME attributes specifies the format of the stored data in Table B, not its function. The other date/time attributes are automatically updated fields generated at the time of record or field group creation or update. A non-automatic field can have a DATETIME format, but all the automatic date/time fields are stored in DATETIME format. The DATETIME attribute requires at least eight significant digits. 
Once you define a DATETIME value for a field, you cannot redefine the DATETIME value.

===UTF-8 and UTF-16 attributes===
Note
General availability of the UTF-8 and UTF-16 attributes is in Model 204 release 7.5.
The UTF-8 attribute indicates that data is stored in [http://en.wikipedia.org/wiki/UTF-8 UTF-8] format and is treated as [[Unicode|unicode]] data inside SOUL programs. A UTF-8 field can be defined as follows:
DEFINE FIELD UTFDATA WITH [UTF-8 | UTF8]

DEFINE FIELD UTFBLOB WITH BLOB [UTF-8 | UTF8]

The UTF-16 attribute indicates that data is stored in [http://en.wikipedia.org/wiki/UTF-16 UTF-16] format and is treated as [[Unicode|unicode]] data inside SOUL programs. A UTF-16 field can be defined as follows:
DEFINE FIELD UTFDATA WITH [UTF-16 | UTF16]

DEFINE FIELD UTFBLOB WITH BLOB [UTF-16 | UTF16]

Usage notes
<ul>
<li>Since UTF-8 or UTF-16 fields behave like unicode variables in SOUL requests printing fields with unicode characters that cannot be converted to displayable EBCDIC results in those characters being [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Character_reference_overview character-entity encoded], just as they are encoded when printing unicode variables. This is also true when printing is done via a [[Basic User Language Statements and Commands#PRINT_ALL_INFORMATION_.28or_PAI.29_statement|PAI]] statement. For example, a UTF-8 field containing the unicode value of "I like apple π" would be printed as "I like apple &#x03C0;". The & symbol is always encoded as &amp; when printed.</li>
<li>Just as with unicode variables, assigning an EBCDIC value to a unicode field results in the EBCDIC value being converted to unicode and then to UTF-8 or UTF-16 for storage. Simlarly, assigning a UTF-8 or UTF16 field to an EBCDIC variable results in the UTF-8 or UTF-16 value being converted to unicode and then translated to EBCDIC. In either EBCDIC to unicode or unicode to EBCDIC translation, errors result in request cancellation.
<li>Unless the preponderance of data stored in UTF-8 or UTF-16 fields has unicode values greater than U+07FF (most likely if most of the data contains Asian language characters), UTF-8 is a better choice for storing unicode data, since UTF-16 requires two bytes for every unicode character while UTF-8 only requires one byte for many common characters and only two bytes for unicode characters up to U+07FF.</li>
<li>UTF-8 and UTF-16 fields can be LOB fields or they can be STRING fields (stored in table B).</li>
<li>If a UTF-8 or UTF-16 field is defined as an OCCURS field, the length indicates the length in bytes, not the length in characters. Since UTF-8 encoding can use anywhere from one to three bytes to represent a single unicode character in the [http://en.wikipedia.org/wiki/Unicode_plane#Basic_Multilingual_Plane BMP], the only unicode characters supported by SOUL, it can be tricky using UTF-8 fields as OCCURS fields since setting the defined length requires an educated guess about the types of unicode characters that will be store in the field or (probably) oversizing a UTF-8 field to three bytes per character. In the latter case, it would make much more sense to define such a field as UTF-16 as that requires exactly two bytes for each character.</li>
</ul>

===VISIBLE and INVISIBLE attributes===
In general, you want to be able to retrieve, and then display or print fields, or use the field values in a report. These are fields that you want defined as VISIBLE.
If, however, you have a field that is used only to retrieve records, and space is a consideration, you may want to define the field as INVISIBLE.
Note
If the INVISIBLE attribute is not specified when the field is defined, the VISIBLE attribute is assumed. 
Using the VISIBLE attribute
Once an application retrieves a record with a User Language FIND statement or a Host Language IFFIND call, it generally processes one or more fields in User Language PRINT, NOTE, or SORT statements, arithmetic expressions, or Host Language IFGET calls. For example:
CHECK.SALARY:
IF SALARY GT 1000*AGE
THEN PRINT NAME
END IF

A field referred to by the PRINT statement must have the VISIBLE attribute in its field description. This means that the field-name-equals-value pair is actually stored in the logical record in Table B.
Using the INVISIBLE attribute
A field that has the INVISIBLE attribute, on the other hand, takes up no storage space in Table B and cannot be printed, noted, or sorted. These fields can be added, deleted, or changed in the logical record.
Choosing the INVISIBLE attribute: In a library catalog file, for example, each record can have an AUTHOR field that contains the author's full name. In addition, there can be a LAST NAME field that contains only the author's last name. This creates a convenient index to the catalog and relieves the user of the burden of knowing the entire name when making retrieval requests. Because the author's last name already is part of the (VISIBLE) AUTHOR field, some space can be saved in Table B by selecting the INVISIBLE attribute for LAST NAME.
Reorganizing INVISIBLE fields
Because INVISIBLE fields are not stored in Table B, they require special care if the file is ever reorganized. When designing a file, be sure to take reorganization requirements for these fields into consideration. See for a description of techniques that can be used to recreate INVISIBLE fields. 
Maintaining INVISIBLE fields
INVISIBLE fields must also have the KEY, NUMERIC RANGE, or ORDERED attribute, and they are normally used only to retrieve records. 
The User Language FILE RECORDS statement and the Host Language Interface IFFILE function can be used to rapidly add an INVISIBLE KEY field name = value pair to an entire set of records. For example:
ALL.RECS: FIND ALL RECORDS FOR WHICH
NAME = SMITH OR SMYTHE OR SMYTH
END FIND
FILE: FILE RECORDS IN ALL.RECS UNDER HOMONYM = SMYTH

<var class="product">Model 204</var> makes entries in Tables C and D to allow retrievals with the specification HOMONYM = SMYTH but does not change Table B. For further information about adding, changing, or deleting INVISIBLE fields, see the <var class="product">Model 204</var> User Language Manual.
Table B considerations
The values of VISIBLE fields can be stored in the logical record in Table B in one of four formats depending upon the selection of STRING/BINARY, CODED/NON-CODED, or FLOAT field attributes. The choice affects space requirements and, except for a slight increase in the time required for updates and some types of retrievals (see [[#CODED and NON-CODED attributes|CODED and NON-CODED attributes]]), is transparent to the user. 
The values of fields that have the INVISIBLE attribute are not stored in Table B, and physical storage attributes cannot be specified in their descriptions. 
Using INVISIBLE fields in 1NF files
The First-Normal form relational model cannot be enforced for INVISIBLE fields. However, INVISIBLE fields are useful within <var class="product">Model 204</var> for list processing and to support SQL multicolumn keys (see the <var class="product">Model 204</var> SQL Server User's Guide for more information). Therefore, the INVISIBLE field attribute is allowed, but INVISIBLE fields are not mapped to SQL-accessible columns. The following rules and restrictions apply to INVISIBLE fields in 1NF files:
<ul>
<li>Because the INVISIBLE and AT-MOST-ONE attribute are incompatible, INVISIBLE fields must be defined as REPEATABLE.</li>
<li>You cannot REDEFINE a field as INVISIBLE within a 1NF file; the INVISIBLE and REPEATABLE attributes can be specified only with a DEFINE command. In the case of a record security key field, use the INITIALIZE command to specify the field as INVISIBLE and REPEATABLE.</li>
<li>INVISIBLE fields in 1NF files must also be ORDERED or KEY (NUMERIC RANGE is not legal in a 1NF file and results in an error message). </li>
</ul>
Compatibility with other attributes
The INVISIBLE attribute cannot be specified for a field defined with the FLOAT or AT-MOST-ONE attributes.

== Data Content ==

In addition to the data type (above), there are additional attributes which further control how the data is stored and manipulated:
<ul>
<li>CODED, NON-CODED </li>
<li>OCCURS</li>
<li>LENGTH</li>
<li>PAD</li>
<li>FEW-VALUED, MANY-VALUED </li>
<li>UPDATE IN PLACE, UPDATE AT END</li>
<li>DEFAULT-VALUE</li>
<li>STORE-DEFAULT, STORE-NULL</li>
<li>AT-MOST-ONE, REPEATABLE and EXACTLY-ONE</li>
<li>DEFERRABLE/NON-DEFERRABLE</li>
</ul>

===CODED and NON-CODED attributes===
The CODED and NON-CODED attributes let you choose between saving disk space (with CODED) or speeding up update and retrieval time (with NON-CODED). This section discusses how these attributes work.
Note
If the CODED attribute is not specified when a field is defined, the NON-CODED attribute is assumed.
NON-CODED attribute
If a field is designated NON-CODED without an OCCURS clause (see the following discussion), its value is stored in Table B as a simple character string that has an additional byte to indicate its length. 
NON-CODED is the best choice for any field whose values have an average length of 1-3 bytes whether or not they are compressible numbers.
CODED attribute
Choose the CODED option to save Table B space where the values of the field are not suitable for BINARY compression and where their average length is four or more characters.
When a value that has the CODED attribute is defined, the character string is stored in Table A-the internal file dictionary-and a 4-byte value code pointing to that character string is stored in the logical record in Table B. Space is saved when there are several records that contain the same value. The string is stored only once in Table A, and only the 4-byte code is stored in each of the several records in Table B.
Choosing CODED vs. NON-CODED
The coding and decoding of these value codes takes time, which can slow down updates and retrievals. If speed is important and if disk space is relatively plentiful, do not choose the CODED attribute.
If disk space is somewhat tight, choose the CODED attribute for fields where the values are long and where there are a small number of values relative to the number of records in the file. A STATE field is a prime example.
A more precise rule governing the choice of the CODED attribute is difficult to arrive at since first it must be determined (based on the number and length of the field values, and on the number of records) if any disk space is actually saved by the CODED attribute. Then, any space saved must be weighed against the extra time taken by CODED retrievals. And the relative importance of disk space and time are likely to vary with the application as well as with the installation.
The formulas in , show more explicitly the effects of the CODED field attribute on Table A and B size.
Using the $CODE and $DECODE functions
Field value encoding is entirely transparent to the user. Data is returned exactly as it was entered. Codes are system-generated, internal codes that have no meaning to a user. If access to both user codes and their translations is needed, use the User Language $CODE and $DECODE functions in <var class="product">Model 204</var> User Language Manual. 
===Preallocated fields===
Any VISIBLE field can be a preallocated field. However, a VISIBLE field that appears a fixed number of times in most of the records in a file is most suited for preallocation in Table B. Preallocated fields, if selected appropriately, require less Table B space than other fields and can be updated and retrieved slightly faster. 
Preallocation means that space is reserved in each new record added to a file. As occurrences of preallocated fields are stored in a record, they are placed in the reserved space. Space is used even for occurrences that have not been stored, whereas non-preallocated fields use no space for missing occurrences. Preallocation also imposes restrictions on the number and length of values that can be stored in a record. A field is preallocated if its description includes an OCCURS clause. 
, provides specific rules for the amount of space used by preallocated and non-preallocated fields. Use these rules to determine whether or not to preallocate a particular field. 
Using an OCCURS clause
A field is preallocated if its description includes an OCCURS clause. The OCCURS clause indicates the number of occurrences of the field that are preallocated or reserved in each Table B record. From 1 to 255 occurrences can be specified. Any number of values, up to the specified limit, <var class="term">n</var>, can be stored in the record.
Only as many occurrences as have been stored can be retrieved. Space allocated for unstored values is wasted. 
If OCCURS is not included in a field description, the field still can occur more than once in a record. Space for the occurrences is not preallocated. There is no limit to the number of values that can be stored for a non-preallocated field.
Restrictions for preallocated fields
The OCCURS option can be specified only for fields that can be preallocated with a fixed length in Table B. This includes only fields that are defined as CODED, BINARY, or LENGTH <var class="term">m</var> (see [[#LENGTH and PAD clauses|LENGTH and PAD clauses]]). If a field is defined as BINARY but does not contain an OCCURS clause, values that cannot be compressed to a binary representation still can be stored in the field. If a field is defined as both BINARY and OCCURS, only compressible values can be stored in it. 
<var class="product">Model 204</var> does not allow incompressible values to be stored in such fields. To avoid such compression problems, include CODED with BINARY and OCCURS in the field description. 
Displaying the set of preallocated fields
The [[DISPLAY RECORD command]] will show all of the preallocated fields in a file. This information is stored on a page in [[Table D (File Architecture)|Table D]] where it is used to create the preallocated field space at the beginning of a record when it is initially stored. 
Note
Because <var class="product">Model 204</var> cannot distinguish values padded with X'00' from zero-length values explicitly stored in the file, <var class="product">Model 204</var> does not allow zero-length values to be explicitly stored in preallocated fields. 
===LENGTH and PAD clauses===
Using the LENGTH clause
Use the LENGTH clause to specify the length of FLOAT fields, as well as NON-CODED preallocated (OCCURS) string fields. 
the LENGTH must be specified for NON-CODED preallocated string fields: the LENGTH must be included in the description of a NON-CODED preallocated string field to set the maximum length of the field. The length must be in the range 1 through 255. The specified length is preallocated for the number of occurrence specified by the OCCURS clause. 
LENGTH with FLOAT fields: LENGTH is required with FLOAT to indicate the precision of the floating-point field being defined. The LENGTH options in this instance are 4, 8, or 16. (See [[#FLOAT attribute|FLOAT attribute]].)
Specifying the LENGTH clause: The LENGTH clause limits the length of values that can be stored in the field. <var class="product">Model 204</var> does not store values that are longer than the specified length. The LENGTH clause does not impose any minimum length. Values that are shorter than the specified length are padded with the PAD character to the maximum length as they are stored in Table B and are returned to their original length as they are retrieved. See the description of padding in [[#LENGTH and PAD clauses|LENGTH and PAD clauses]]. 
Field occurrences that have been preallocated but not stored contain zero-length values. 
Using the PAD clause
You can include a PAD clause in a field description to select the character that is used to pad field values that are shorter than the length specified in the LENGTH clause (see [[#LENGTH and PAD clauses|LENGTH and PAD clauses]]) for the field. If no PAD character is specified in a field description, the default character, X'00', is used.
Padding characters are invisible to the user and are not included in a retrieved value. Make sure that the padding character does not appear as part of a field value. If it does, incorrect results can occur.
===FEW-VALUED and MANY-VALUED attributes===
If a field that has the CODED or FRV attribute is expected to take on fewer than about 50 different values, choose the FEW-VALUED attribute. Otherwise, define the field as MANY-VALUED. 
This option determines whether the value string is stored in the FEW-VALUED or MANY-VALUED section of Table A, and is invalid for fields that are neither CODED nor FRV. Keep the number of values stored in the FEW-VALUED section small to ensure that this section is kept in core during retrieval and update operations. This practice reduces the number of disk accesses and increases retrieval speed. 
Note
If the FEW-VALUED attribute is not specified when a field is defined, the MANY-VALUED attribute is assumed.
===UPDATE IN PLACE and UPDATE AT END attributes===
<var class="product">Model 204</var> provides the following field attributes that control the way that the value of a field occurrence is changed in Table B:
<table>
<tr>
<th>
If this attribute is specified...</th>
<th>Then a change in the value of a field
occurrence...</th>
</tr>
<tr>
<td>UPDATE IN PLACE </td>
<td>
Does not change its position relative to other occurrences of the same field in Table B.
This attribute is the default.
</td>
</tr>
<tr>
<td>UPDATE AT END</td>
<td>Is accomplished by deleting the existing occurrence and adding a new one following the others. </td>
</tr>
</table>
Choosing an update option
Specify either of these options as part of a field description. The UPDATE AT END approach can be useful in certain data aging applications: for example, in applications in which the first occurrence of a field represents the oldest update to the file, and the last occurrence is the most recent update. UPDATE IN PLACE generally is more efficient.
The choice of update option determines the position of a field occurrence within a record only in relation to other occurrences of the same field. The ordering of different fields within a record is determined by a variety of factors, of which the update method is only one. The order of fields within a record normally is not under the control of the file manager.
User Language update statements other than CHANGE are not affected by the choice of an update option. The ADD and STORE statements always cause values to be added as the last occurrences in a record. The DELETE statement always removes the deleted value while maintaining the relative ordering of the remaining occurrences. 
Compatibility with other attributes
The values of fields that have the INVISIBLE attribute are not stored in Table B, and UPDATE IN PLACE or UPDATE AT END cannot be specified in their descriptions. 
===DEFAULT-VALUE (DV) attribute===
A field defined with a DEFAULT-VALUE (DV) attribute value must also be defined with the EXACTLY-ONE or the AT-MOST-ONE attribute. It specifies the value of the field if the value is not explicitly added in the STORE RECORD, ADD FIELDGROUP, or INSERT FIELDGROUP initial data block. 
The value of the STORE-DEFAULT setting determines whether the DEFAULT-VALUE is physically stored on the record or if it is just used as the default value when the field is missing.
The DEFAULT-VALUE attribute allows values up to 31 bytes. An attempt to use more results in:
M204.2851: DEFAULT-VALUE VALUE
'1234567890123456789012345678901234567890' TOO BIG, -
MUST BE <32 BYTES

The value of DEFAULT-VALUE is not constrained by attributes such as LEQ, LLE, and LGE.

For example, the entire default value is returned for a field that has been added, even if it exceeds the LEQ setting.


===STORE-DEFAULT (SD) and STORE-NULL (SN) attributes===
You can redefine the STORE-DEFAULT and/or STORE-NULL attribute values.
The STORE-DEFAULT and STORE-NULL attributes offer these options:
<ul>
<li>LITERAL (the default)</li>
<li>NONE</li>
<li>ALL</li>
</ul>
Consider the following example that shows how a DEFAULT-VALUE is handled when the field is defined with the different STORE-DEFAULT types of ALL, NONE, and LITERAL. 
Here we are defining field NAME_SD_NONE with the STORE-DEFAULT option of NONE, field NAME_SD_LIT with the STORE-DEFAULT option of LITERAL and field NAME_SD_ALL with the STORE-DEFAULT option of ALL. The DEFAULT-VALUE for all of the fields is 'NONAME'. 
In this example, the fields belong to a field group but the STORE-DEFAULT (and STORE-NULL) attribute can also be assigned to a field that is not part of a field group. The only requirement is that the field may not be defined as REPEATABLE, i.e., it must be either AT-MOST-ONE or EXACTLY-ONE.
DEFINE FIELDGROUP X
DEFINE FIELD NAME_SD_NONE WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-DEFAULT NONE DEFAULT-VALUE 'NONAME'

DEFINE FIELD NAME_SD_LIT WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-DEFAULT LITERAL DEFAULT-VALUE 'NONAME'

DEFINE FIELD NAME_SD_ALL WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-DEFAULT ALL DEFAULT-VALUE 'NONAME'

There are basically two ways to store a field in a record. It can be stored: 
- using a literal:
STORE RECORD
FIELD.A = 'ABC'
END STORE

- or by using a variable:
%X = 'ABC'
STORE RECORD
FIELD.A = %X
END STORE

Additionally, a field may simply be missing (in the following example, the record has a FIELD.B but FIELD.A is missing):
STORE RECORD
FIELD.B = 'XXX'
END STORE

The STORE-DEFAULT options determines how the field will be physically stored if the DEFAULT-VALUE is stored in the field. 
This example shows what is physically stored in the record when the DEFAULT-VALUE is stored for each of these fields. The DEFAULT-VALUE in this case is 'NONAME'. First, we will add the actual DEFAULT-VALUE of 'NONAME' by using a variable, then by using the literal 'NONAME' and finally we will add a field group occurrence where the field is missing. 
ADD.X: SUBROUTINE
IN FILEX FRN %CURREC
* add first field group occurrence using the -variable %NAME:
%NAME='NONAME'
ADD FIELDGROUP X
NAME_SD_NONE = %NAME
NAME_SD_LIT = %NAME
NAME_SD_ALL = %NAME
END ADD
* add second field group occurrence using the - literal 'NONAME':
ADD FIELDGROUP X
NAME_SD_NONE = 'NONAME'
NAME_SD_LIT = 'NONAME'
NAME_SD_ALL = 'NONAME'
END ADD
* add third occurrence of the field group with all -
values missing:
ADD FIELDGROUP X
* none of these fields added to this occurrence
END ADD
END FOR

Subsequent PAI of the field group shows what is physically stored on the record. 
<table>
<tr>
<th>The field defined with... </th>
<th>is...</th>
</tr>
<tr>
<td>STORE-DEFAULT NONE </td>
<td>Never stored on the record. </td>
</tr>
<tr>
<td>STORE-DEFAULT ALL </td>
<td>Always stored on the record. </td>
</tr>
<tr>
<td>STORE-DEFAULT LITERAL </td>
<td>Not stored in the first occurrence, because a %variable was used. It was stored in the second occurrence, because the field was added using a literal string.</td>
</tr>
</table>
\X = 1
NAME_SD_ALL = NONAME
/X = 1
\X = 2
NAME_SD_LIT = NONAME
NAME_SD_ALL = NONAME
/X = 2
\X = 3
/X = 3

Note that when the record above is printed the DEFAULT-VALUE is printed regardless of whether the field is physically stored on the record or not. 
FR
PRINT '# NAME_SD_NONE: NAME_SD_LIT: NAME_SD_ALL:'
FEO:
FEO FIELDGROUP X
PRINT OCCURRENCE IN FEO AND NAME_SD_NONE AND -
NAME_SD_LIT AT 16 AND NAME_SD_ALL AT 30
END FOR
END FOR

NAME_SD_NONE: NAME_SD_LIT: NAME_SD_ALL:
NONAME NONAME NONAME
NONAME NONAME NONAME
NONAME NONAME NONAME

Note: The same behavior occurs whether the field is AT-MOST-ONE or EXACTLY-ONE. However, a PAI of an EXACTLY-ONE field always shows a value. The actual physical storage on the record is the same. 
The options on the STORE-NULL attribute react similarly. When the fields are defined as follows:
DEFINE FIELDGROUP X
DEFINE FIELD NAME_SN_NONE WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-NULL NONE
DEFINE FIELD NAME_SN_LIT WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-NULL LITERAL
DEFINE FIELD NAME_SN_ALL WITH FIELDGROUP X AND -
ORD AT-MOST-ONE -
STORE-NULL ALL

And code used to store the field groups is:
 IN FILEX FRN %CURREC
* add first occurrence using the variable %NAME:
%NAME=''
ADD FIELDGROUP X
NAME_SN_NONE = %NAME
NAME_SN_LIT = %NAME
NAME_SN_ALL = %NAME
END ADD
* add second occurrence using the literal '':
ADD FIELDGROUP X
NAME_SN_NONE = ''
NAME_SN_LIT = ''
NAME_SN_ALL = ''
END ADD
* add third occurrence with missing values:
ADD FIELDGROUP X
END ADD
END FOR

The resulting PAI appears as follows:
\X = 1
NAME_SN_ALL =
/X = 1
\X = 2
NAME_SN_LIT =
NAME_SN_ALL =
/X = 2
\X = 3
/X = 3

BEGIN
FR
PRINT '# NAME_SN_NONE: NAME_SN_LIT: NAME_SN_ALL:'
FEO:
FEO FIELDGROUP X
PRINT OCCURRENCE IN FEO AND -
NAME_SN_NONE AND NAME_SN_LIT AT 16 -
AND NAME_SN_ALL AT 30
END FOR
END FOR
END

Results in the following: nulls are shown for each field.
# NAME_SN_NONE: NAME_SN_LIT: NAME_SN_ALL:
1
2
3


===AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes===
You can use the AT-MOST-ONE, REPEATABLE, and EXACTLY-ONE attributes, which are mutually exclusive, to define an individual field or a field that is part of a field group definition. 
Using the AT-MOST-ONE attribute
The AT-MOST-ONE attribute allows you to ensure that there is only one occurrence of a field in any record, without preallocating space for the field. 
In addition, the AT-MOST-ONE attribute is required for fields in First-Normal Form (1NF) files. AT-MOST-ONE and REPEATABLE fields in 1NF files are discussed in this section.
Note
In non-1NF files, if the AT-MOST-ONE attribute is not specified when a field is defined, the REPEATABLE attribute is assumed. 
If a field is defined with the AT-MOST-ONE attribute, <var class="product">Model 204</var> prevents multiple occurrences of that field in any given record. The AT-MOST-ONE attribute is useful if, for example, you know that there will be one variable-length field per record, or if you have a field that is often left blank but does not have more than one value per record (such as SPOUSE NAME). 
Unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated. The AT-MOST-ONE attribute lets you store these kinds of records without wasting the space required by OCCURS.
Using the REPEATABLE attribute
If a field is not defined as AT-MOST-ONE, then it is REPEATABLE. Fields with the REPEATABLE attribute can accept multiple occurrences of the field in the record. Unlike the OCCURS attribute, REPEATABLE does not preallocate fields, nor does REPEATABLE let you specify the number of occurrences of the field.
Using the EXACTLY-ONE (EXONE) attribute
As the name suggests an EXACTLY-ONE attribute in a field definition means that the field always has exactly one occurrence in its record or field group context after the initial data block for the record or field group (STORE RECORD, ADD FIELDGROUP, or INSERT FIELDGROUP). If no explicit value is stored for the field, its value has either the DEFAULT-VALUE for the field or the null string (' '), if no DEFAULT-VALUE was specified for the field.
You cannot add, insert, or delete an EXACTLY-ONE field, although you can change an EXACTLY-ONE field. 
The EXACTLY-ONE attribute is not allowed when both the DEFAULT-VALUE and STORE-NULL NONE attributes are specified.
EXACTLY-ONE fields with a field group
The EXACTLY-ONE attribute for a field within a field group means that the field can occur only once inside a single field group occurrence. However, since field groups can occur multiple times in a field group record, an EXACTLY-ONE field inside a field group can occur multiple times inside a field group record. 
Defaults for AT-MOST-ONE, REPEATABLE and EXACTLY- ONE fields
REPEATABLE is the default except for 1NF files, where AT-MOST-ONE is required on all fields, except INVISIBLE. See [[#VISIBLE and INVISIBLE attributes|VISIBLE and INVISIBLE attributes]] for informatIon. 
The AT-MOST-ONE attribute is required on all fields in a 1NF file because multiply occurring fields violate relational First-Normal Form. The one exception to this rule is for INVISIBLE/REPEATABLE fields in 1NF files. See See, See Using the File Model Feature for more information.
The EXACTLY-ONE attribute is the default frequency of occurrence for a field defined within a field group.
Enforcing AT-MOST-ONE constraints
<var class="product">Model 204</var> ensures that AT-MOST-ONE field constraints are not violated for the following User Language requests and the Host Language and FLOD counterparts: 
<ul>
<li>ADD</li>
<li>INSERT</li>
<li>STORE RECORD</li>
</ul>
Before the indexes are updated and a new field is added or inserted into the <var class="product">Model 204</var> record, all existing fields in the record are checked to ensure that the new field does not create a second occurrence: 
<ul>
<li>If a new field violates the AT-MOST-ONE rules, and there is no ON FCC unit, the request is canceled with the following error message:
M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD <var class="term">recordnumber</var>, FIELD IGNORED: <var class="term">fieldname</var>=<var class="term">value</var>
</li>
<li><var class="product">Model 204</var> validates a field if you REDEFINE it to be AT-MOST-ONE.</li>
<li>If a violation occurs and there is an ON FCC unit, <var class="product">Model 204</var> processes the ON unit. </li>
</ul>
In the Host Language Interface, the 202 return code is passed back to <var class="product">Model 204</var>; in FLOD, the file is marked logically inconsistent. However, <var class="product">Model 204</var> does not cancel the request in either case. 
AT-MOST-ONE and transaction back out files
Transaction back out must be active for files when defining AT-MOST-ONE fields. If you try to define an AT-MOST-ONE field in a non-TBO file, the DEFINE fails and you receive an error message. 
Once the field is defined, you can turn Transaction Back Out off in non-1NF files. However, <var class="product">Model 204</var> customer support strongly recommends that you keep Transaction Back Out set in files containing fields that can cause constraint conflicts (currently AT-MOST-ONE and UNIQUE). If you turn Transaction Back Out off in a file with an AT-MOST-ONE or UNIQUE field, <var class="product">Model 204</var> sends you a warning message and a "Do You Really Want To?" prompt.
Using FLOD or FILELOAD with AT-MOST-ONE fields
When you use FLOD or FILELOAD to load or modify records that have AT-MOST-ONE fields, <var class="product">Model 204</var> ensures that the new or modified records do not violate AT-MOST-ONE constraints. <var class="product">Model 204</var> detects and reports all violations of AT-MOST-ONE in one pass of the input data. If <var class="product">Model 204</var> finds any fields that violate the constraints, the following occurs:
Error is reported and the new or duplicate field is rejected.
<ol>
<li>FLOD continues processing the input data.</li>
<li>At the end of the run, the file is marked "logically inconsistent;" that is, the FISTAT parameter is set to X'40'. See See Logically inconsistent files for more information.</li>
<li>The following error message is issued for each violation:
M204.2119: AT-MOST-ONE CONSTRAINT VIOLATION IN RECORD <var class="term">recordnumber</var>, FIELD IGNORED: <var class="term">fieldname</var>=<var class="term">value</var>
</li>
</ol>
AT-MOST-ONE in First Normal Form (1NF) files
Using OCCURS 1 in 1NF files: For 1NF files, where AT-MOST-ONE is required, use OCCURS 1 to save processing time if you are storing a large number of records in which the field is always exactly the same length (such as a Social Security Number). 
INVISIBLE fields in 1NF files: The First-Normal form relational model cannot be enforced for INVISIBLE fields. However, they are useful within <var class="product">Model 204</var> for list processing and to support SQL multicolumn keys. (See the <var class="product">Model 204</var> SQL Server User's Guide for more information.) Therefore, the INVISIBLE field attribute is allowed, but INVISIBLE fields are not mapped to SQL-accessible columns. The following rules and restrictions apply to INVISIBLE fields in 1NF files:
<ul>
<li>Because the INVISIBLE and AT-MOST-ONE attributes are incompatible, INVISIBLE fields must be defined as REPEATABLE.</li>
<li>You cannot REDEFINE a field as INVISIBLE within a 1NF file; you can specify the INVISIBLE and REPEATABLE attributes only with a DEFINE command. In the case of a record security key field, specify the field as INVISIBLE and REPEATABLE using the INITIALIZE command.</li>
<li>INVISIBLE fields in 1NF files must also be ORDERED or KEY. NUMERIC RANGE is not legal in a 1NF file and results in an error message)</li>
</ul>
Defining AT-MOST-ONE and REPEATABLE fields in non-1NF files
You can DEFINE or REDEFINE a field to be AT-MOST-ONE in any non-1NF <var class="product">Model 204</var> file created after Release 9.0. 
When redefining a field to AT-MOST-ONE that does not currently have the OCCCURS 1 attribute, <var class="product">Model 204</var> scans Table B to verify that no multiple occurrences of the field exist in any record. If any field violates the AT-MOST-ONE constraints, the REDEFINE fails and the following error message is displayed for each violation:
M204.2122: AT-MOST-ONE CONSTRAINT VIOLATION FOR FIELD <var class="term">fieldname</var> IN RECORD <var class="term">recordnumber</var>

Using the AT-MOST-ONE or the OCCURS 1 attribute
Although both the AT-MOST-ONE and OCCURS 1 attributes prevent more than one occurrence of a field in a record, they achieve their goal in different ways. For non-1NF files, use either the AT-MOST-ONE or the OCCURS 1 attribute. Using both causes redundant processing. Understanding the advantages of each may help you decide which attribute you want to use. 
AT-MOST-ONE attribute:
<ul>
<li>Does not preallocate the field. Therefore, if the field values between records are of very different lengths or if you do not know the length of the longest record, use AT-MOST-ONE.</li>
<li>Allows you to correct violations before the record is stored with the ON FCC unit. If you do not use an ON FCC unit, then a constraint violation cancels the request. Therefore, if it is important to allow users to correct violations, or it is important that the request not be canceled, use AT-MOST-ONE.</li>
</ul>
OCCURS 1 attribute:
<ul>
<li>Preallocates space for the field in every record. If you are storing a large number of records and the length of the value is generally the same, pre-allocating the field with OCCURS 1 can save you processing time. </li>
<li>Cancels the request when a violation occurs. With OCCURS 1, you cannot use an ON FCC unit to correct violations. </li>
</ul>
Compatibility with other field attributes
AT-MOST-ONE is not compatible with the following field attributes:
<ul>
<li>INVISIBLE</li>
<li>OCCURS greater than 1</li>
<li>REPEATABLE
REPEATABLE is compatible with all field attributes except AT-MOST-ONE.
</li>
</ul>
===Coordinating AT-MOST-ONE and UNIQUE attributes===
Both AT-MOST-ONE and UNIQUE are examples of field-level constraints. Although the function of the UNIQUE and AT-MOST-ONE attributes appear similar, their actual operations differ.:
<table>
<tr>
<th>This attribute</th>
<th>Affects...</th>
</tr>
<tr>
<td>UNIQUE</td>
<td>Value of the field</td>
</tr>
<tr>
<td>AT-MOST-ONE</td>
<td>Number of fields per record</td>
</tr>
</table>
For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE:
<table>
<tr>
<th>This attribute</th>
<th>Ensures that...</th>
</tr>
<tr>
<td>UNIQUE</td>
<td>Social security number for every employee is different.</td>
</tr>
<tr>
<td>AT-MOST-ONE</td>
<td>Each employee has only one social security number. </td>
</tr>
</table>
Coordinating the use of the AT-MOST-ONE and the UNIQUE attributes increases the integrity and accuracy of your records.

===DEFERRABLE and NON-DEFERRABLE attributes===
The DEFERRABLE and NON-DEFERRABLE attributes let you specify whether the updates to the index (Tables C and D) for a KEY ORDERED field can be deferred; that is, stored or updated at a later time.
The DEFERRABLE attribute is recommended and is the default.
Note
If the NON-DEFERRABLE attribute is not specified when a field is defined, the DEFERRABLE attribute is assumed.
====Choosing between DEFERRABLE or NON-DEFERRABLE====
Under normal circumstances, the storing and updating of records in the <var class="product">Model 204</var> file is done all at once. That is, Tables B, C, D, E, and X are changed simultaneously. When there is a high volume of updates (for example, a Batch2 process adding large numbers of records), efficiency and space reductions can be gained by deferring the updates to Tables C and D.
Under some circumstances, it may be necessary to override this deferral of updates to the index for particular fields. For instance, consider a situation in which new records are added Online to a personnel file. You might be willing to wait a day for the ability to retrieve the new records. The updates to Tables C and D are deferred until a batch processing window (and the application of deferred updates does require exclusive access to the file), when they are done in a batch run. However, when adding new records, you want to ensure that a record containing a duplicate Social Security number (for example) is not added to the file. 
You can define the Social Security number field as NON-DEFFERABLE and write a procedure to retrieve any records already in the file that have the new Social Security number and display an error message if one is found. If updates to the index on this field have been deferred, you would not find a duplicate added earlier in the same day. By selecting the NON-DEFERRABLE attribute for the Social Security number field, you can ensure that Tables C and D are updated immediately. 
Note
To provide immediate updating in BATCH204 runs, special action must be taken. See "Overriding deferred updates" for more information.
You can also detect duplicate Social Security numbers by defining the field with the UNIQUE and ORDERED attributes. See [[#UNIQUE and NON-UNIQUE attributes|UNIQUE and NON-UNIQUE attributes]]
====Compatibility with other attributes====
The DEFERRABLE/NON-DEFERRABLE attribute is invalid for a field that has these attributes: BLOB, CLOB, NON-KEY, NON-ORDERED, and NON-RANGE. 
For a chart showing valid and invalid attribute combinations, see [[ Field Attribute Combinations#Combining attributes|Combining attributes]]. If you are defining field attributes with FILEMGMT, you will not be allowed to specify incompatible attributes. 

<div id="Field Constraints">
== Field and Content Constraints ==

You may set up constraints to prevent 'invalid' updates to the file. The updates may be invalid because to permit them would violate rules about the field (a second occurrence to an AT-MOST-ONE field, for example). Or you may set up 'content' constraints to prevent values outside of those permitted to be stored.

=== Field Constraints ===

==== ON FIELD CONSTRAINT CONFLICT (ON FCC) unit ====

(should probably be mentioned only as a link to UL page)

To help control processing with UNIQUE and AT-MOST-ONE fields, use the User Language ON FCC unit. ON FCC is invoked whenever a field-level constraint conflict, such as an attempt to add a second occurrence of an AT-MOST-ONE field.
An ON FCC unit is used with a number of $functions that can help you determine exactly where the field constraint conflict has occurred. The $UPDSTAT function is discussed below. All other $functions for ON FCC are discussed in the <var class="product">Model 204</var> User Language Manual.
$UPDSTAT function
The $UPDSTAT function is used in conjunction with the ON FIELD CONSTRAINT CONFLICT unit and field attributes which have field-level constraints of UNIQUE and AT-MOST-ONE. You <var class="term">must</var> use $UPDSTAT in the ON FCC unit when writing procedures for files that have (or might have in the future) more than one type of field-level constraint defined.
If $UPDSTAT is invoked from an ON FCC unit following the detection of a field-level constraint conflict, it returns a numeric value denoting the type of conflict that has occurred:
<table>
<tr>
<th>Value</th>
<th>Meaning </th>
</tr>
<tr>
<td align="right">0 </td>
<td>No violation occurred</td>
</tr>
<tr>
<td align="right">1 </td>
<td>Uniqueness violation occurred</td>
</tr>
<tr>
<td align="right">2 </td>
<td>AT-MOST-ONE violation occurred </td>
</tr>
</table>
The $UPDSTAT function takes no arguments. 
See information about the [[#AT-MOST-ONE and REPEATABLE attributes|AT-MOST-ONE and REPEATABLE attributes]].
UNIQUE and ORDERED fields
Because <var class="product">Model 204</var> uses the Ordered Index to process UNIQUE values, fields defined as UNIQUE must also be defined as ORDERED. For more information about the Ordered Index see [[#ORDERED and NON-ORDERED attributes|ORDERED and NON-ORDERED attributes]].

====UNIQUE and NON-UNIQUE attributes====
Defining a field with the UNIQUE attribute allows <var class="product">Model 204</var> to ensure that a given field name = value pair occurs only once in a file. A Social Security number field is one example that might benefit from having the UNIQUE attribute. The UNIQUE attribute specifies that there can be only one occurrence of a field in the file. Multiple occurrences are not allowed.
When storing a field specified as UNIQUE, <var class="product">Model 204</var> first queries the Ordered Index, looking for an identical field-name-equals-value pair. If it finds an identical value, <var class="product">Model 204</var> issues an error message and does not perform the update. This is true both within a record for multiply occurring fields and between records.
If there is not a uniqueness conflict, that is, if the field-name-equals-value pair being stored is unique, <var class="product">Model 204</var> completes the update.
Note
If the UNIQUE attribute is not specified when a field is defined, the NON-UNIQUE attribute is assumed. 

Unique values in multiply occurring fields
In a multiply-occurring field, <var class="product">Model 204</var> ensures that each occurrence of the field is unique. 
Deleting UNIQUE fields
Because UNIQUE values use the Ordered Index, do not use the DELETE ALL RECORDS statement for deleting records. Use DELETE RECORD instead.
Compatibility with other attributes
A field can only be specified as UNIQUE with the following restrictions:
<ul>
<li>UNIQUE fields must be specified as ORDERED.</li>
<li>UNIQUE fields cannot be specified as DEFERRABLE.</li>
<li>UNIQUE fields cannot be defined in non-TBO (Transaction Back Out) files. </li>
</ul>
If you attempt to define a UNIQUE key under any of these circumstances, you receive an error message and the field is not defined.

====Defining a LEVEL clause====
To secure a field against unauthorized access, include a LEVEL clause in the field's description. See discusses field-level security and describes the types of field access: SELECT, READ, UPDATE, and ADD. 
Field-level security has a negligible impact on both performance and storage usage.

=== Content Constraints ===

====Setting a pattern for a field value: the LIKE attribute====
Setting a field pattern lets you specify a pattern that a field value must conform to, otherwise it cannot be stored. The patterns you can specify are the <var class="product">Model 204</var> LIKE patterns. See the chapter on pattern matching in the <var class="product">Model 204</var> User Language Guide. For example:
IN FILE PITCHERS DEFINE FIELD G WITH LIKE '@@@####'

This specifies that field G must start with three alphabetic characters followed by four numeric characters. An attempt to store a field value that does not conform to the field's pattern results in request cancellation.
You can limit a field value to a list of values. For, example, if a field must have a value of 'M' or 'F' you could code:
IN FILE PITCHERS DEFINE FIELD SEX WITH LIKE 'M,F'

And if you want a BALL field to have a value 'SPLITTER', 'CURVE', 'KNUCKLE', or 'CHANGE UP' you could code:
IN FILE PITCHERS DEFINE FIELD BALL WITH LIKE -
'SPLITTER,CURVE,KNUCKLE,CHANGE UP'

The maximum pattern length is 47 characters. The maximum default value length is 31 characters.
As with the IS LIKE operator in User Language, the patterns are always applied to numbers after conversion to a string.

You cannot use the LIKE attribute to define an automatic field.

====Range constraints====
You can set range constraints on fields using the range attributes. Each set of range attributes is comprised of three or four attributes that you can use to establish a range for field length values, integer values, float values, or date/time stamp values. The types of range attributes are mutually exclusive. For example, you cannot define a field with the LENGTH-GE and INTEGER-LE attributes. 
The range constraints are self-editing. If you define a field with LENGTH LE 6 and LENGTH GE 8, the definition is rejected and an error message is issued.
When a range constraint is redefined, it replaces the existing field constraint.
Note:: The range constraints do not have to match the data type of the stored field. That is, you can have a date/time constraint for a STRING field or an integer constraint for a FLOAT field, and so on.

=====Defining fields with length constraints=====
<table>
<tr>
<th>Length constraint attributes </th>
<th>
Range</th>
</tr>
<tr>
<td>LENGTH-EQ </td>
<td>Number from 0 to 255 that indicates the required length of a field</td>
</tr>
<tr>
<td>LENGTH-GE </td>
<td>Number from 0 to 255 that indicates the minimum length of a field</td>
</tr>
<tr>
<td>LENGTH-LE </td>
<td>Number from 0 to 255 that indicates the maximum length of a field</td>
</tr>
</table>
The following field definitions illustrate using the length constraint attributes, LENGTH-EQ, LENGTH-GE, and LENGTH-LE, with each other and/or with other attributes.
IN FILE REDSOX DEFINE FIELD A WITH LENGTH-EQ 8 BINARY OCCURS 1

IN FILE REDSOX DEFINE FIELD B WITH LENGTH-GE 4 FLOAT LEN 8

IN FILE REDSOX DEFINE FIELD C WITH LENGTH-LE 10

IN FILE REDSOX DEFINE FIELD D WITH LENGTH-LE 10 LENGTH-GE 3

IN FILE REDSOX DEFINE FIELD E WITH LENGTH-LE 6 LENGTH-GE 6 BINARY

IN FILE REDSOX DEFINE FIELD F WITH LENGTH-LE 255 LENGTH-GE 0

IN FILE REDSOX DEFINE FIELD COLOR WITH EXACTLY-ONE

Note: The length constraints apply to the string representation of non-string types as they would be stored in the database. This means that the length of a FLOAT field with value 34.000 would be 2 because after being stored in the database it will return 34 on a retrieval.
=====LENGTH-EQ (LEQ) attribute=====
The LENGTH-EQ attribute is followed by a number from 0 to 255 that indicates the required length of a field.
The LENGTH-EQ attribute is not allowed for automatic fields.
=====LENGTH-GE (LGE) attribute=====
The LENGTH-GE attribute is followed by a number from 0 to 255 that indicates the minimum length of a field.
The LENGTH-GE attribute is not allowed for automatic fields. You can pair the LGE attribute with the LLE attribute, creating a length range. However, if the range is not valid or overlaps, an error message is invoked.
=====LENGTH-LE (LLE) attribute=====
The LENGTH-LE attribute is followed by a number from 0 to 255 that indicates the maximum length of a field.
The LENGTH-LE attribute is not allowed for automatic fields. You can pair the LLE attribute with the LGE attribute, creating a length range. However, if the range is not valid or overlaps, an error message is invoked.
=====Setting an integer value constraint=====
For Integer values you can define a field with:
<table>
<tr>
<td>Integer attribute </td>
<td>Specifies that the integer value must be...</td>
</tr>
<tr>
<td>INTEGER-GE </td>
<td>Greater than or equal to the value that follows</td>
</tr>
<tr>
<td>INTEGER-GT </td>
<td>Greater than the value that follows</td>
</tr>
<tr>
<td>INTEGER-LE </td>
<td>Less than or equal to the value that follows</td>
</tr>
<tr>
<td>INTEGER-LT</td>
<td>Less than the value that follows</td>
</tr>
</table>
The value stored for a field must be an integer with a value that satisfies the constraint. For example:
DEFINE FIELD NCHILDREN WITH INTEGER-LE 100

The NCHILDREN field can have an integer value of less than or equal to 100.
Note: An integer constraint will not accept a value that would be stored with a decimal place. If you have an integer constraint INTEGER-GE 10 and try to store value 10.0, it will fail because 10.0 is not an integer.
=====INTEGER-GE (INTGE), INTEGER-GT (INTGT), INTEGER-LE (INTLE) and INTEGER-LT (INTLT) attributes=====
The integer range attributes-INTGE, INTGT, INTLE, INTLT-can be defined singly or as a pair on a field. The integer range attributes establish a range of acceptable integer values for the field. If a record is added with an integer value that is not within the range, the record is rejected.
If you specify another type of range attribute on the same field, such as DATETIME-LE or FLOAT-GE, an error message is invoked. 
=====Setting a float value constraint=====
For float values you can define a field with:
<table>
<tr>
<td>Float attribute </td>
<td>Specifies that the float value must be...</td>
</tr>
<tr>
<td>FLOAT-GE </td>
<td>Greater than or equal to the value that follows</td>
</tr>
<tr>
<td>FLOAT-GT </td>
<td>Greater than the value that follows</td>
</tr>
<tr>
<td>FLOAT-LE </td>
<td>Less than or equal to the value that follows</td>
</tr>
<tr>
<td>FLOAT-LT</td>
<td>Less than the value that follows</td>
</tr>
</table>
The value stored for a field must be a floating point value that satisfies the constraint. For example:
DEFINE FIELD WEIGHT WITH FLOAT-GT 10.5

The WEIGHT field must have a float value greater than 10.5. 
=====FLOAT-GE (FLTGE), FLOAT-GT (FLTGT), FLOAT-LE (FLTLE) and FLOAT-LT (FLTLT) attributes=====
The float range attributes-FLTGE, FLTGT, FLTLE, FLTLT-can be defined singly or as a pair on a field. The float range attributes establish a range of acceptable float values for the field. If a record is added with a float value that is not within the range, the record is rejected.
If you specify another type of range attribute on the same field, such as DATETIME-LE or INTEGER-GE, an error message is invoked. 
=====Setting a date/time value constraint=====
For date/time values you can define a field with:
<table>
<tr>
<td>Date/time attribute </td>
<td>Specifies that the date/time value must be...</td>
</tr>
<tr>
<td>DATETIME-GE </td>
<td>Later than or the same as the date/time value that follows</td>
</tr>
<tr>
<td>DATETIME-GT </td>
<td>Later than the date/time value that follows</td>
</tr>
<tr>
<td>DATETIME-LE </td>
<td>Earlier or equal to the date/time value that follows</td>
</tr>
<tr>
<td>DATETIME-LT </td>
<td>Earlier than the value that follows</td>
</tr>
</table>
The value stored for field must be a date/time value that satisfies the constraint. For example:
DEFINE FIELD BIRTHDATE WITH DATETIME-GE 18900101 -
DATETIME-LT 20100101

The BIRTHEDATE field is required to have a date/time value greater than or equal to January 1, 1890 and less than January 1, 2010. As with any other date/time values, the values can be extended with HH, HHMM, HHMMSS, HHMMSSX, HHMMSSXX, and so on.
=====DATETIME-GE (DTGE), DATETIME-GT (DTGT), DATETIME-LE (DTLE), and DATETIME-LT (DTLT) attributes=====
The date/time range attributes-DTGE, DTGT, DTLE, DTLT-establish a range of acceptable dates for the value of the field. If a record is added with a date that is not within the range, the record is rejected. You can specify a single date/time range attribute or a pair of them on a field. 
If you specify another type of range attribute on the same field, such as FLOAT-LE or INTEGER-GE, an error message is invoked. 
The value stored for a field must be a date/time with a value that has the proper relationship to the following value. For example:
DEFINE FIELD BIRTHDATE WITH DATETIME-GE 18900101 -
DATETIME-LT 20100101

The BIRTHDATE field is required to have a date/time value greater than or equal to January 1, 1890 and less than January 1, 2010. As with any other date/time values, the values can be extended with HH, HHMM, HHMMSS, HHMMSSX, HHMMSSXX, and so on.

== Concatenated Fields ==
Fields that make up concatenated field values must be either AT-MOST-ONE, EXACTLY-ONE, or OCCURS 1 and must all be in the same field group context (including no field group). FIELDGROUP * are not allowed.
Fields defined with range attributes cannot be used in concatenation processing. For more information on this, see "Range Constraints" on [[|]].
The following syntax is used to define a concatenated field with a separator and an escape character:
Syntax
DEFINE FIELD fieldname WITH CONCATENATION-OF -
field1 WITH field2 [WITH field3 [WITH field4 -
[AND . . .]]] -
[SEPARATOR (char | X'hex' | NONE)] -
[ESCAPE (char | X'hex' | CANCEL)]
[OtherAttributes . . .]

The SEPARATOR character appears between the field values that comprise the concatenated field. Up to eight fields may be defined for a concatenated field. 
Concatenated fields could be longer than 255 bytes after adding separator characters and escaping results in request cancellation.
Concatenated fields have the following field attribute support.
<table>
<tr>
<td>Concatenated field attributes </td>
<td>
Purpose</td>
</tr>
<tr>
<td>CONCATENATION-OF (CAT) </td>
<td>List the fields that make up that concatenated field</td>
</tr>
<tr>
<td>ESCAPE (ESC) </td>
<td>Specifies a character that is used to escape separator characters that occur in a field that requires a terminating separator character</td>
</tr>
<tr>
<td>SEPARATOR (SEP) </td>
<td>Specifies the character that terminates fields that do not have a fixed length and are not the last field in the concatenation</td>
</tr>
</table>
If a required attribute is not assigned a value, the default value is used. For example, if you define a CONCATENATEION-OF field, which requires the SEPARATOR attribute, and you do not enter the SEPARATOR attribute, the default value of X'00' is used as the SEPARATOR value.
===CONCATENATION-OF (CAT) attribute===
The CONCATENATION-OF (CAT) attribute is followed by a list of fields that make up that concatenated field. At least two are required and up to eight are allowed. The field names must be separated by the word WITH and subsequent field attributes must be separated from the list by the word AND. Each field specified in the list of concatenated fields must have the EXACTLY-ONE attribute specified.
===ESCAPE (ESC) attribute===
The ESC attribute is followed by one of the following:
<ul>
<li>A single character in C'<char>' or X'<hex>' format that specifies the character that is used to escape separator characters that occur in a field that requires a terminating separator character. In addition to escaping the separator character, the escape character can also escape itself.</li>
<li>CANCEL, which means that an attempt to store a separator character in a field that requires a terminating separator results in request cancellation.</li>
</ul>
The default ESCAPE character is X'01'. 
Once you define an ESCAPE value for a field, you cannot redefine the ESCAPE value.
The ESCAPE character cannot match the SEPARATOR character. The ESCAPE character is always displayed on DISPLAY FIELD output.
The ESCAPE attribute is not allowed on a field definition, if the SEPARATOR NONE attribute is specified.
Using the ESCAPE attribute
The ESC character is inserted into a concatenated field when the real data being added to the database contains the SEPARATOR or the ESCAPE character itself. When reading in stored values, programs use the ESC character to differentiate between the special characters and normal data that happens to include the special characters. When the processing encounters the ESCAPE character in a concatenated field, it knows that the next character is real data.
Note: The ESCAPE character applies to all fields except the last field in the concatenation. The programmer is expected to know how many components comprise the concatenation and therefore, special characters occurring in the last component must be real data.
Consider the following field definitions:
DEFINE FIELD A_CONCAT_TEST1 WITH AT-MOST-ONE
DEFINE FIELD A_CONCAT_TEST2 WITH AT-MOST-ONE
DEFINE FIELD A_CONCAT_TEST3 WITH CONCATENATION-OF -
A_CONCAT_TEST1 WITH -
A_CONCAT_TEST2 AND -
SEPARATOR C'+' -
ESCAPE C'/'

If we then do:
BEGIN
IN POLICIES STORE RECORD
A_CONCAT_TEST1 = 1ST+VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
END STORE
FRN $CURREC
NP
PAI
END FOR
END

We get:
A_CONCAT_TEST1 = 1ST+VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
A_CONCAT_TEST3 = 1ST/+VALUE/++2ND+VALUE+

The plus signs in the stored records are intentionally part of the data. For the concatenated field <var class="product">Model 204</var> stores the escape character preceding the plus signs in the data for all but the last field in the concatenation. This assumes that the programmer knows how many fields there are in the concatenation and therefore knows that any separator characters in the last field are data fields.
In storing the escape character immediately before any plus signs that are part of the data proper, <var class="product">Model 204</var> tells the programmer that they are to be read as data. If there were any escape characters in the data proper, <var class="product">Model 204</var> puts an escape character before the data proper version as in the following example:
BEGIN
IN POLICIES STORE RECORD
A_CONCAT_TEST1 = 1ST/VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
END STORE
FRN $CURREC
NP
PAI
END FOR
END

... giving the output ...
A_CONCAT_TEST1 = 1ST/VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+
A_CONCAT_TEST3 = 1ST//VALUE/++2ND+VALUE+

If you do not want either the separator or the escape character in the concatenated field, you can enforce this by assigning the value 'CANCEL' as the escape character as follows:
DEFINE FIELD A_CONCAT_TEST1 WITH CONCATENATION-OF -
A_CONCAT_TEST1 WITH -
A_CONCAT_TEST2 AND -
SEPARATOR C'+' -
ESCAPE CANCEL

In which case, the concatenation will be ignored and our STORE record results in the following:
A_CONCAT_TEST1 = 1ST/VALUE+
A_CONCAT_TEST2 = 2ND+VALUE+

Note: There are no error messages associated with this condition.
===SEPARATOR (SEP) attribute===
The SEP attribute is followed by one of the following options:
<ul>
<li>A single character in C'&lt;char>' or an X'&lt;hex>' format that specifies the character that terminates fields that do not have a fixed length and are not the last field in the concatenation. The separator character is always used between field values, regardless of any length constraints on the component fields.</li>
<li>The NONE option that means the fields in the concatenation are concatenated end to end with no separator character and regardless of their length.</li>
</ul>
If you define a field with the SEP attribute, you must supply a value. Otherwise, the following error is issued:
DEFINE MAKE_MODEL WITH CONCATENATION-OF MAKE WITH MODEL - AND ORD SEP ESC CANCEL
*** 1 M204.0405: INVALID DEFINE OPTION: SEP ESC

If you define a field without the SEP attribute, it defaults to X:00:, as shown in the following code:
DEFINE MAKE_MODEL WITH CONCATENATION-OF MAKE WITH MODEL -
AND ORD ESC CANCEL

D FIELD (ABBREV) MAKE_MODEL
MAKE_MODEL
(DEF NFRV NKEY NCOD STR NNR VIS UP ORD CHAR LRES 15 -
NRES 15 SPLT 50 IMM 1 NUNIQ ONE CAT MAKE WITH MODEL AND -
SEP X'00' EXC CANCEL)

Once you define a SEPARATOR value for a field, you cannot redefine the SEPARATOR value.
The SEPARATOR character cannot match the ESCAPE character. The SEPARATOR character is always displayed on DISPLAY FIELD output.
If the SEPARATOR NONE attribute is specified on a field definition, the ESCAPE attribute is not allowed.
===Defining concatenated fields===
Using the fields defined in [[|]] and the following fields, you can define concatenated fields.
IN FILE REDSOX DEFINE FIELD COLMOD WITH CONCATENATION-OF COLOR -
WITH MODEL AND SEP C'-' ESC C'+'

IN FILE REDSOX DEFINE FIELD MODCOL WITH CONCATENATION-OF MODEL -
WITH COLOR AND SEP C'$' ESC C'*'

IN FILE REDSOX DEFINE FIELD MODCOLI WITH CONCATENATION-OF MODEL -
WITH COLOR AND SEP X'40' ESC C'*' INVISIBLE ORDERED

IN FILE REDSOX DEFINE FIELD MCY WITH CONCATENATION-OF MODEL -
WITH COLOR WITH YEAR AND SEP X'40' ESC C'*' INVISIBLE ORDERED

IN FILE REDSOX DEFINE FIELD COLCNT WITH CONCATENATION-OF COLOR -
WITH COUNTRY AND SEP X'40' ESC C'*' INVISIBLE ORDERED

IN FILE REDSOX DEFINE FIELD CNTYR WITH CONCATENATION-OF YEAR -
WITH COUNTRY AND SEP X'40' ESC C'*' INVISIBLE ORDERED

===Defining concatenated fields in a field group context===
IN FILE REDSOX DEFINE FIELD BATTERS

IN FILE REDSOX DEFINE FIELDGROUP STARTERS

IN FILE REDSOX DEFINE FIELD NTRIP WITH CTO STARTERS AND EXACTLY-ONE

IN FILE REDSOX DEFINE FIELD A WITH AT-MOST-ONE FIELDGROUP STARTERS AND-
ORDERED CHARACTER

IN FILE REDSOX DEFINE FIELD B WITH AT-MOST-ONE FIELDGROUP STARTERS AND -
KEY

IN FILE REDSOX DEFINE FIELD C WITH AT-MOST-ONE FIELDGROUP STARTERS AND
ORDERED NUMERIC

IN FILE REDSOX DEFINE FIELD AB WITH FIELDGROUP STARTERS AND -
CONCATENATION-OF A WITH B AND SEP C'/'

IN FILE REDSOX DEFINE FIELD ABO WITH FIELDGROUP STARTERS AND -
CONCATENATION-OF B WITH A AND SEP C'+' ORDERED

IN FILE REDSOX DEFINE FIELD ABI WITH CONCATENATION-OF B WITH A AND -
SEP C'+' ORDERED INVISIBLE

Note: A field in a concatenated field value does not have a terminating separator set only if it is:
Last field in the concatenation, or
<ol>
<li>Fixed length (LENGTH-EQ set) and the default value has the same length as LENGTH-EQ.</li>
</ol>
If you specify the ESCAPE CANCEL attribute for a field and the SEPARATOR character for that field is in one of the field values for the concatenated string, the update is cancelled. 

<div id="Automatic Fields">

== Automatic Fields ==

<var class="product">Model 204</var> now lets you define a field whose value is automatically maintained. For example, a field may count occurrences of another field so that every store or delete of the field occurrence changes the count in the automatic field. The automatic fields are fields defined with the following attributes: 
<ul>
<li>COUNT-OCCURRENCES-OF</li>
<li>CREATE-TIME</li>
<li>CREATE-TIMEUTC</li>
<li>CREATE-USER</li>
<li>UPDATE-TIME</li>
<li>UPDATE-TIMEUTC</li>
<li>UPDATE-USER</li>
</ul>
The value of an automatic field is updated at the start of a transaction by <var class="product">Model 204</var> and you cannot set it explicitly by a program. Any valid update causes the appropriate time and user stamps to be updated. For example, DELETE FOO(8). when there are no occurrences of FOO in the record.
Once you define an automatic value for a field, you cannot redefine the automatic value.
===Automatic Field Context===
Automatic fields may operate in a record or Repeating Field Group context. Take the following set of fields:

...
DEFINE FIELDGROUP ADDRESS
...
DEFINE FIELD RECORD.UPDT.TIME (DATETIME UPDT-TIME)
DEFINE FIELD ADDRESS.LINE.1 (SN NONE FG ADDRESS)
...
DEFINE FIELD ADDRESS.UPDT.TIME (DATETIME FG ADDRESS AND UPDT-TIME)
...
Any update to any field in a record will automatically update RECORD.UPDT.TIME
Any update to any field in an occurrence of the ADDRESS field group will cause the ADDRESS.UPDT.TIME for that occurrence to be updated. (And, of course, the record level RECORD.UPDT.TIME as well.) 

===Rules for the definition of Automatic Fields===

'''COUNT-OCCURRENCES-OF (CTO) attribute'''
The COUNT-OCCURRENCES-OF (CTO) attribute is not allowed for fields defined as REPEATABLE.
Because one of the major advantages of CTO fields is to avoid unnecessary record scans, it is highly recommended that the field be preallocated. Otherwise the field is stored and updated in Table B in the normal way.

See [[Field Design (File Management)#Counting occurrences of a field|Counting occurrences of a field]] for details on its use.

'''Other automatic fields'''

All other automatic fields, capture the add/update user/time as of the start of the transaction. Any of these attributes may be be added to empty or non-empty fields (via a [[REDEFINE command]]). The value is maintained by <var class="product">Model 204</var> processing, so you cannot change the value.
These automatic attributes may net be defined as REPEATABLE (the default is AT-MOST-ONE).

See [[Field Design (File Management)#Tracking updates using automatic fields|Tracking updates using automatic fields]] for details on their use.

===Displaying automatic fields===
You can specify the AT-MOST-ONE or EXACTLY-ONE attribute for an automatic field. These attributes affect the order in which the fields are displayed on a PAI statement. EXACTLY-ONE fields are displayed in the order they were defined, whereas AT-MOST-ONE fields are displayed in the order they are stored in Table B. 
Currently Table B stores automatic fields in the following order:
UPDATE-TIME
<ol>
<li>UPDATE-USER</li>
<li>CREATE-TIME</li>
<li>CREATE-USER</li>
</ol>

===Counting occurrences of a field===
To create such a field you use the COUNT-OCCURRENCES-OF (CTO) keyword on a field definition followed by the name of the field that the field or field group for which the count is automatically maintained. For example, if you have field group DRUG you could define an automatic count field as follows:
DEFINE FIELDGROUP DRUG
DEFINE FIELD DRUGCT WITH COUNT-OCCURRENCES-OF DRUG

You cannot define a CTO field in a file that has had records already added to it.
You could also make the automatic count field a binary field:
DEFINE FIELD DRUGCT WITH CTO DRUG AND BINARY OCCURS 1
DEFINE FIELD DRUGCT WITH COUNT-OCCURRENCES-OF DRUG AND -
BINARY

Note: AND is a separator between a field or field group name and other field attributes.
An automatic count field can also be an OCCURS 1 field:
DEFINE FIELD DRUGCT WITH COUNT-OCCURRENCES-OF DRUG AND BINARY OCCURS 1

An automatic counter field could even be ORDERED, KEY or NUMERIC RANGE:
DEFINE FIELD DRUGCT WITH CTO DRUG AND BINARY OCCURS 1 ORDERED NUMERIC

You can find all records with N occurrences of field group DRUG. Or, you can find those that have more or less than some number of occurrences.
Limitations on COUNT-OCCURRENCES-OF (CTO) fields
Fields defined with the CTO attribute cannot also have the UPDATE AT END attribute. You cannot define a CTO field that counts occurrences of UPDATE AT END fields.
You cannot use a CTO field to count occurrences of OCCURS fields, even though the OCCURS count is greater than 1.
Also, you cannot define a CTO field in a file that has had records already added to it.
There is a maximum of one CTO field per field or field group.
Retrieving the value of a CTO field
You can retrieve values of CTO fields via the field name (as with any VISIBLE field), as in:
PRINT DRUGCT

or
%DRUGCT = DRUGCT

Automatic optimization with COUNT OCCURRENCES OF fields
The use of CTO fields automatically optimizes many of the record scan processes:
<ul>
<li>[[Operations on Multiply Occurring Fields#FOR EACH OCCURRENCE OF loops|FOR EACH OCCURRENCE OF]] loops.
If a CTO field exists for the field or field group that is being looped over via an FEO or FAO statement, the value of that field limits the number of times the loop is processed, which reduces the need to scan to the end of record for every FEO or FAO statement. Note that when a record is updated or might be updated mid-loop, <var class="product">Model 204</var> normal concerns about subscript handling in these statements need to be considered.
</li>
<li>FOR FIELDGROUP clause
Before processing a FOR FIELDGROUP loop, <var class="product">Model 204</var> checks whether the requested occurrence is in the record based on the CTO field. If the User Language request is for occurrence 3, but the CTO field indicates only two occurrences in the record, <var class="product">Model 204</var> stops processing the FOR loop.
</li>
<li>Field extraction
Before extracting a field <var class="product">Model 204</var> checks whether the requested occurrence is in the record based on the CTO field. If the User Language request is occurrence 3, but the CTO field indicates only two occurrences in the record, <var class="product">Model 204</var> sets the result to null (or NOT PRESENT). 
Note the in the case of the subscripted field optimization:
</li>
</ul>
 FOR %I FROM 1 TO %N
%FOO = FOOFIELD(%N)
END FOR

<var class="product">Model 204</var> checks only the number of occurrences on the first iteration of the loop.
In all cases, the greatest benefit from the CTO field optimization is when a record contains no occurrences of the requested field or field group. <var class="product">Model 204</var> immediately determines that no occurrence is on the record and stops scanning the record.
Defining an efficient CTO field
The counter fields are always physically present in the record. Using a DEFAULT-VALUE of zero for such a field defeats its purpose as you need to scan the entire record to determine whether to use the default value. When you issue a STORE RECORD statement, all CTO fields are stored as 0 in the record. For non-OCCURS, fields are always the first variable length fields in the record.
<var class="product">Model 204</var> customer support recommends that you define a CTO field as BINARY OCCURS 1, as these require only four bytes per record, whereas the minimum length of a variable length field is four bytes (for a compressed 0) and will be at least five for any non-zero value. A CTO field inside a field group cannot be an OCCURS field. 
The absolute maximum value for CTO fields is currently X'3FFFFFFF' or 1,073,741,823 since BINARY fields use the high order two bits to distinguish values from coded values. 
You cannot update CTO fields; attempts are caught at compile-time for explicit file-context references and at run-time for group-context and field-name variables. 
CTO fields can even be in field groups and zeros are stored for CTO fields when the ADD FIELDGROUP or INSERT FIELDGROUP statement is processed.
Displaying CTO fields
By default, the PRINT ALL INFORMATION (PAI), AUDIT ALL INFORMATION (AAI), PRINT ALL FIELD GROUP INFORMATION (PAFGI), and AUDIT ALL FIELDGROUP INFORMATION (AAFGI) statements do not display CTO (counter fields). When you are using PAI [INTO] to reorganize your files or to copy records, the automatic fields are likely to cause problems.
Under other circumstances you can use the argument to indicate that you do want automatic fields to be printed by these statements.

===Tracking updates using automatic fields===
<var class="product">Model 204</var> can now track the date/time when a record was created or updated and what user ID created or updated it. This can be accomplished by using one of the following field tracking attributes: 
<table>
<tr>
<td>Tracking attribute </td>
<td>Tracks the...</td>
</tr>
<tr>
<td>CREATE-TIME </td>
<td>Moment the record was created using machine time</td>
</tr>
<tr>
<td>CREATE-TIMEUTC </td>
<td>Moment the record was created using Coordinated Universal Time</td>
</tr>
<tr>
<td>CREATE-USER </td>
<td>User ID that created the record</td>
</tr>
<tr>
<td>UPDATE-TIME </td>
<td>Moment the record was updated using machine time</td>
</tr>
<tr>
<td>UPDATE-TIMEUTC </td>
<td>Moment the record was updated using Coordinated Universal Time</td>
</tr>
<tr>
<td>UPDATE-USER </td>
<td>User ID that updated the record</td>
</tr>
</table>
All of the automatic fields that contain date/time information also have the DATETIME attribute. 
You cannot update tracking fields with User Language.
A record or field group can contain only a single field of each update tracing type (CREAT-USER, UPDATE-USER, CREATE-TIME, UPDATE-TIME). An attempt to create a second invokes an error message.
You can define update tracking fields (CREATE-TIME, UPDATE-TIME, CREATE-USER, UPDATE-USER) in an already populated file, even an update tracking field for the main records or a field group that already has occurrences. You can also define a DEFAULT-VALUE field, which defaults to a null string. This lets you define such fields with or without a reorganization.
Tracking fields for records
The file itself may have a single field defined for each of the tracking fields.
An attempt to define a second field of the same type on the file results in an error message, for example:
DEFINE FIELD RECORD.CREATE.TIME WITH CREATE-TIME
DEFINE FIELD RECORD.CREATE-TIME2 WITH CREATE-TIME

*** M204.2866: FILE ALREADY HAS A CREATE-TIME FIELD

The UPDATE tracking fields for the records are updated when any field in the record changes and the create tracking fields are added to the record when it is initially stored. 
Tracking fields for field groups
Automatic tracking fields can also provide a date/time and user stamp of the creator and last update of each occurrence of a field group.
If an UPDATE-TIME tracking field is defined as a part of the field group as shown below:
DEFINE FIELD MY_UPDATE_TIME WITH FIELDGROUP X AND -
ORD NUM UPDATE-TIME

then each occurrence of field group X will contain the field.
Setting a date/time field
The DATETIME attribute indicates the format of the data stored in Table B.
You can now define a field with a DATETIME attribute:
DEFINE FIELD WHEN WITH DATETIME

DATETIME fields use seven bytes to store the value (plus four bytes overhead, if the field is not preallocated). A binary representation is used to store the 20-character full date format so that it can be held in seven bytes. the DATETIME attribute may not be combined with KEY. You assign a string to it in <var>YYYYMMDDHHMMSSXXXXXX</var> format:
IN FILE FOO DEFINE FIELD WHEN WITH DATETIME
...
BEGIN
IN FILE FOO STORE RECORD
WHEN = '2010070413470643516378'
END STORE
END

If you attempt to store the field with invalid data such as, WHEN = '72', the request will be cancelled and you will receive an error:
*** 1 CANCELLING REQUEST: M204.2865: ATTEMPT TO ADD INVALID DATETIME VALUE: WHEN = 72

As most timestamps do not require microseconds, you can specify 10ths, 100ths, 1,000ths, 10,000ths and 100,000ths of a second. The value is simply padded on the right with zeros. For date/time field WHEN, the following are all equivalent:
ADD WHEN = '20090704134706000000'
ADD WHEN = '2009070413470600000'
ADD WHEN = '200907041347060000'
ADD WHEN = '20090704134706000'
ADD WHEN = '2009070413470600'
ADD WHEN = '200907041347060'
ADD WHEN = '20090704134706'


In addition, you can leave off seconds, minutes or hours so the following are all equivalent:
ADD WHEN = '20090704000000'
ADD WHEN = '200907040000'
ADD WHEN = '2009070400'
ADD WHEN = '20090704'

which are also, of course, equivalent to
ADD WHEN = '20090704000000000000'

Storing dates or date/times efficiently
The shortest valid format for a field with the DATETIME attribute contains YYYYMMDD. If the values you are storing are simple dates, they can be stored in four bytes as binary values, so requires three fewer bytes per value than a date/time field. However, for anything with a time in it (even just hours), a DATETIME field takes less space than the alternative field types (FLOAT or STRING).
Automatic validation of date/times
In addition to the compact storage of date/time stamps, DATETIME fields also provide automatic validation of the values stored into them. That is, you cannot store numbers into them that are not valid dates. For example, you cannot store '9999111' into a DATETIME field, nor can you store '20070931' (because September does not have 31 days), nor can you store '20070229' (because 2007 is not a leap year, so February only has 28 days).
DATETIME fields also provide for field content validation for DATETIME fields. 
Note: It is possible to set a DATETIME DEFAULT-VALUE to an invalid date/time value, such as '_', and to set a DATETIME field to that value. That value will not be stored in the database and the value returned for an EXACTLY-ONE field value that had not been set would be the default value in such a case.
The value returned for DATETIME fields is always in:
YYYYMMDDHHMMSSXXXXXX

If you are interested in only part of the time stamp, you can either use the $SUBSTR function to get the part you want or make the %variable that will hold the time stamp length you are interested in. So, if you want %WHEN to hold a date/time in YYYYMMDDHHMISS format, simply declare %WHEN as:
%WHEN IS STRING LEN 14

...

%WHEN = WHEN

DATETIME values can be indexed either as ORDERED CHARACTER or ORDERED NUMERIC. When indexed as ORDERED NUMERIC, only the first 15 digits (<var>YYYYMMDDHHMISSX</var>) are indexed. When a DATETIME field is indexed as ORDERED CHARACTER, it is indexed as the string representation of the date/time value in the full <var>YYYYMMDDHHMISSXXXXXX</var> format.
Note: Making DATETIME fields KEY fields is not allowed.
Update processing
Date/time values are the date/time of the start of the update processing, so all records, fields and field groups updated by a single update get the same time stamp. Furthermore, the code that starts an update unit ensures that the date/time stamp of each update unit is unique.
The M204.0173 and M204.0172 messages were expanded to include the date/time stamp.
M204.0173: START OF UPDATE 12 AT 10:11:00.51 (20090705101100511734)

and
M204.0172: END OF UPDATE 12 AT 10:11:00.56 (20090705101100511734)

Defining various UPDATE-USER fields
To indicate whether an update tracking field applies to a record or field group, specify or do not specify the containing field group on the field definition. For example:
DEFINE FIELD WHO WITH UPDATE-USER

The WHO field contains the user ID of the last user that updated anything in the record. The following example illustrates defining an UPDATE-USER field in a field group:
DEFINE FIELD DR.WHO WITH UPDATE-USER FIELDGROUP DR

The DR.WHO field contains the user ID of the last user that updated an occurrence of field group DR.
Defining various UPDATE-TIME fields
You can specify an update tracking field as FIELDGROUP *, which means that all field groups and the primary record all use the same update tracking field. For example:
DEFINE FIELD WHEN WITH UPDATE-TIME FIELDGROUP *

The WHEN field is placed in the primary record and each field group to track the last update time. If a file has a FIELDGROUP * update tracking field and a field group or record has a different comparable updating tracking field, the field group or the record specific tracking field applies to the field. For example:
DEFINE FIELD WHEN WITH UPDATE-TIME FIELDGROUP *

DEFINE FIELD MAIN.WHEN WITH UPDATE-TIME OCCURS 1

DEFINE FIELD FOO.WHEN WITH UPDATE-TIME FIELDGROUP FOO

<ul>
<li>The field WHEN would be updated for changes to any field group occurrences in field groups that do not have their own UPDATE-TIME field defined.</li>
<li>The Field MAIN.WHEN would be set for any update to any field in the record.</li>
<li>The field FOO.WHEN would be set in field group FOO for any update to a field group occurrence.</li>
</ul>
The UPDATE-TIME field in a field group that has a nested field group will be updated when the nested field group is updated, even though no fields in the containing field group were updated.

===An alternate approach to adding a date-time stamp field to your files===

There is a more general way you can include a date-time stamp field in your files. The date/time stamp feature lets you put a date-time stamp (DTS) on each record that was updated in a transaction. You can then use the data in the <var class="term">date/time stamp</var> field in an end-user written application to find and process all the rows of data that were changed.
An application that processes these records can track the <var class="term">date/time stamp</var> field values that have been processed to date, or it may take another action, including updating the date/time stamp field.
To install and use this functionality, see [[Setting Up the Date-Time Stamp Field]]. Once installed, the date-time stamp feature works only in files created in V6R1.0 or later. See [[Adding a Date-Time Stamp field]]

Note: There is no support in PQO/204 for the data/time stamp feature.

====Difference between the system wide date-time stamp field and an UPDATE-TIME field====

Besides the obvious difference that the date-time stamp field will (and must) have the same name in every file in which it is used, the following are the notable differences between the two approaches:

* The UPDATE-TIME attribute can be set to track updates to Repeating Field Groups, as well as at the record level.
* The UPDATE-TIME captures the time at the start of an update unit, the date-time stamp field captures the time at the commit point.
* The date-time stamp field updates may be [[#Suspending date-time stamp updates|temporarily suspended]].

== Assigning Fields to Repeating Field Groups (RFGs) ==

===FIELDGROUP attribute===

No default, can be abbreviated as 'FG'. Available in Model 204 V7R5

The FIELDGROUP attribute specifies the name of the field group that the
defined field is associated with (contained in). Once you define a FIELDGROUP
value for a field, you cannot redefine the FIELDGROUP value.

The FIELDGROUP attribute can not refer to a fieldgroupname that has not yet been defined to the file (the [[DEFINE FIELDGROUP command]] must occur before the [[DEFINE FIELD command]].

===Syntax===
:FIELDGROUP [fieldgroupname|*]

The FIELDGROUP attribute does not allow:

* Record security
* Use for SORT or HASH file
* 1NF file model
The FIELDGROUP attribute can be used with the STORE-NULL LITERAL
attribute.

===Using FIELDGROUP * ===

The FIELDGROUP * attribute means that the field will be included into all
field groups. The EXACTLY-ONE attribute conflicts with the FIELDGROUP * attribute.

<div id="Field Naming">

== Field Naming ==

The rules for field and fieldgroup naming are contained in [[Field Names]].

[[Category:File management]]

Adding a date-time stamp field

2013-05-14T23:05:34Z

Rob: /* Overview of the date-time stamp feature */

You can add a date-time stamp field to your files to keep track of when records in the file were last modified. The date-time stamp feature lets you put a date-time stamp (DTS) on each record that was updated in a transaction. You can then use the data in the <var class="term">date-time stamp</var> field in an end-user written application to find and process all the rows of data that were changed.
An application that processes these records can track the <var class="term">date-time stamp</var> field values that have been processed to date, or it may take another action, including updating the date-time stamp field.
To install and use this functionality, you must obtain the correct decrypt keys and install this release. After it is installed, the date-time stamp feature works only in files created in V6R1.0 or later.
Note: There is no support in PQO/204 for the date/time stamp feature.
==Overview of the date-time stamp feature==
The date-time stamp (DTS) feature in <var class="product">Model 204</var> can track when records are modified. The DTS feature is implemented on a file-by-file basis.
Except for DELETE RECORD(S) processing, all other updates are captured, including those made by BATCH204 and ONLINE jobs.

The default date-time stamp format uses the operating system timestamp value. If your site prefers a different field value or a different data format, consult your Rocket Model 204 installation guide to customize the date-time stamp field name and to activate the date-time stamp feature.

Also of note:

* The DTS feature is implemented on a file-by-file basis.
* Precision and accuracy of the date-time stamp is to the millisecond when you use the date-time stamp as delivered. Rocket Software recommends that the date-time stamp field be defined as ORDERED CHARACTER to support ordered index FIND processing. (The length of this field is 17 bytes.)
* While it should not be updated directly, you can read and display the date-time stamp as you can any other field. User Language and IFAM may both be used to find and display date-time stamp field data
* The date-time stamp field is updated at the beginning of commit processing when a new record is stored or an existing record is updated: changes, inserts, or deletes to fields or fieldgroups.
* You can exclude a user thread from date-time stamp field maintenance by resetting the DTS parameter to 0.
.

==Extracting date-time stamp field data==
Since the date-time stamp field is a normal <var class="product">Model 204</var> field, all methods of extraction may be used.
===Date-time stamp field in User Language===
The date-time stamp field may be:
<ul>
<li>Read and printed either as a field name reference or through a $function.</li>
<li>Searched in normal FIND statements.</li>
<li>Assigned to %variables or other fields.</li>
<li>Printed as supported for all <var class="product">Model 204</var> fields, including a PAI statement.</li>
</ul>
===Date-time stamp field and OPEN processing===
If the specified date-time stamp field name is not defined in a date-time stamp file, an OPEN command is rejected. If the date-time stamp field name is DATE.TIMESTAMP, for example, the following messages are issued:
> OPEN DTSFILE
*** 1 M204.1265: NO SUCH FIELD NAME. FIELD = DATE.TIMESTAMP
*** M204.2730: DATE/TIME STAMP FILE, BUT DTSFN NOT DEFINED IN FILE
*** M204.0608: FILE CLOSED: DTSFILE
*** 2 M204.0630: FILE OPEN COMMAND REJECTED

If you do not set the DTSFN system parameter, files with FOPT=X'10' cannot be opened. An OPEN command will not be processed and the following message is issued:
M204.2729: DATE/TIME STAMP FILE, BUT DTSFN UNSPECIFIED IN RUN

If you have reset DTS to 0, you must open DTS enabled files with file manager privileges. Otherwise, the open is rejected.
==Date-time stamp considerations==
===Backup and recovery===
If any errors occur during processing, the transaction is backed out.
Backup and recovery activity synchronize the date-time stamp with the data changes made. Date-time stamp field updates are part of your updating transaction and follow the normal <var class="product">Model 204</var> rules for BACKOUT, COMMIT, DUMP, RESTORE, ROLL BACK, and ROLL FORWARD.
===File load utilities===
FLOD and FASTLOAD do not update the date-time stamp values. However, you can manually update date-time stamp values as you might update another field name value pair.
===Procedures with more than one request===
If there are two requests in one procedure, for example, and neither COMMIT nor CLOSE is called between the two, then both requests are one transaction.
The following procedure has two requests. 
BEGIN
STORE a record in a DTS file
END
BEGIN
PAI the record
END

DTS updates are not displayed by the PAI output, since the transaction does not complete until the end of the procedure.
If there is no COMMIT in the first request or if the file is not closed after the first request, then the date-time stamp field is not updated.
If the same User Language requests are executed as separate procedures, the date-time stamp field is updated. 
==<div id="Suspending date-time stamp updates">Suspending date-time stamp updates</div>==
There are two ways to suspend date=time stamp updates:

===Suspending updates for all files on one thread's updates ===
A user with system manager privileges can exclude date-time stamp files from DTS processing, suspending DTS updates for that user's thread. The user's thread does no date-time stamp processing on any file.
To suspend DTS updates, reset the DTS parameter to 0. When DTS=0, the user can update any field, including the date-time stamp field, without automatically updating the date-time stamp field.
To reset the DTS parameter, the user must have system manager privileges. The user must also have file manager privileges for any DTS-enabled files opened, either before or after DTS is reset to 0.
Note: Automatic date-time stamp field updates are still performed for updates made to the files by other user threads with DTS set to 1.
===Suspending all updates for a file===
To disable all date-time stamp processing for a specific file, turn off the FOPT parameter X'10' bit on the command line or using the File Management Subsystem facility. Turning off this bit disables date-time stamp updates made by all users of that file.
For more information on the DTS and FOPT parameters, see the Rocket <var class="product">Model 204</var> Parameter and Command Reference.
[[Category:File manager]]
[[Category:File management]]

ZFIELD image

2013-05-14T23:03:56Z

Rob: /* Overview */

==Overview==

 This image is required by the [[:Category:SOUL $functions#$FDEF function|$FDEF]] and [[:Category:SOUL $functions#$LSTFLD function|$LSTFLD function]]s, but also provides a complete list of all the available attributes for a Model 204 field.

The ZFIELD image is provided as part of the Model 204 installation software.

'''Note:''' When using ZFIELD, be aware that $FDEF output maps to the location within the image (not the names) so do not change the order of the image items in ZFIELD.

==Image Definition==

The ZFIELD image definition has undergone significant additions in Model 204 V7R5.

Because all changes were additions, any code that you have from earlier version(s) will continue to work, but if you view the image details they are quite different.

See:

 [[ZFIELD Image detail up to V7R4]]

 [[ZFIELD Image detail V7R5 ]]

==Where to find the image definition==

The location of ZFIELD for your site is listed in this table:

<table>
<tr class="head">
<th>IF your site runs under...</th>
<th>THEN the ZFIELD image is stored in...</th>
</tr>
<tr>
<td>z/OS or z/VSE</td>
<td>The JCL library</td>
</tr>
<tr>
<td>z/VM</td>
<td>On the 193 MAINT204 disk</td>
</tr>
</table>

[[Category:File architecture]]

Table X (File architecture)

2013-05-14T23:01:59Z

Rob: /* Avoidance of 'Sick Record' Snaps */

Stores all [[Record (File Architecture)|Record]] Extensions in a separate table from the the base records (so that [[Table B (File Architecture)|Table B]] contains only the base records).

Enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[XSIZE parameter|XSIZE]] greater than 0.

Available as of Model 204 V7.1

==Summary==

The [[Table B (File Architecture)|Table B]] of a Model 204 file has a maximum number of 16.7 million record numbers (IRNs for Internal Record Numbers). By default ([[XSIZE parameter|XSIZE]] = 0), these 'slots' are used for both base records and extension records.

By implementing Table X ([[XSIZE parameter|XSIZE]] > 0) all defined IRNs (up to 16.7 million) in Table B are used for base records only, allowing the storage of the maximum possible number of records in a file regardless of the number of extensions.

Table X can be significantly larger than the 16.7 million limit of Table B; as the product of [[XSIZE parameter|XSIZE] * [[XRECPPG parameter|XRECPPG] may be up to 512 million extension slots.

When the defined capacity of Table B or Table X is exceeded the file is marked full or the updating transaction is backed out.

== Using Table X ==

While similar in concept to [[Table B (File Architecture)|Table B]], the actual 'extension record number' in Table X is far more straightforward.

* Because the number of slots in Table X is so large, and there is effectively no impact in wasting slots (until you approach that limit) [[XRECPPG parameter|XRECPPG]] can usually be set relatively high.

* Similarly, depending on how dynamic record growth is, you may wish to set [[XRESERVE parameter|XRESERVE]] higher than yopu would normally consider setting [[BRESERVE parameter|BRESERVE]]. This will enable records to grow without lengthening the extension chain.

* Table X slots are always reusable. There is no special setting (equivalent to [[FILEORG parameter|FILEORG]] x'04') necessary to enable the use of the reuse queue.

==[[RECRDOPT parameter]]==

Table X may be implemented in one of two ways depending on the setting of the [[RECRDOPT parameter]].

===The default setting of the [[RECRDOPT parameter|RECRDOPT]] (x'00')===

If the default setting of [[RECRDOPT parameter|RECRDOPT]] is used, while all extensions are stored in Table X, the record allocation in Table B is identical to what it is without Table X enabled.

[[BRECPPG parameter|BRECPPG]] remains the '''maximum number''' of records which may occur on a page, and so IRNs may still be wasted (never assigned to a record) as data fills up a page.

===Setting [[RECRDOPT parameter|RECRDOPT]] to x'01'===

This setting changes the base record allocation to ensure that all defined IRNs are available for use.

For all x'01' [[RECRDOPT parameter|RECRDOPT]] files, a base record size limit (the read only parameter [[BRLIMSZ parameter|BRLIMSZ]]) is calculated:

:For an entry order file:
::BRLIMSZ = (6140 / BRECPPG) - 2
: For an unordered file:
::BRLIMSZ = (6136 / BRECPPG) – 2

When a new record is stored, rather than using any and all space available on a page, only up to [[BRLIMSZ parameter|BRLIMSZ]] bytes will be stored in Table B. This ensures that the full [[BSIZE parameter|BSIZE]] * [[BRECPPG parameter|BRECPPG]] number of IRNs can actually be stored in the file.

[[BRLIMSZ parameter|BRLIMSZ]] must be large enough to hold all preallocated fields.

(Note that the [[BRESERVE parameter]] is ignored with x'01' [[RECRDOPT parameter|RECRDOPT]] files).

==Advantages of Using Table X==

===Scalability===

The obvious advantage of implementing Table X relates to the ability to store the full 16.7 million base records in a Model 204 file,

===Indexing Performance===

Even if a file has significantly fewer records than the limit, you should consider the performance of your indices in deciding whether to utilize Table X, notably where you expect to have fields with non unique values.

When Table X is enabled and [[RECRDOPT parameter|RECRDOPT]] = x'01', the fact there are no wasted slots means that the bit maps containing the bitmap and list pages (and, of course, the [[#Table D (File Architecture)#Existence Bit Map|Existence Bit Map]]) are as compressed as possible.

===Avoidance of 'Sick Record' Snaps===

When large sets of unlocked records (either via the use of [[Find Without Locks statement|Find Without Locks]] (FDWOL) or by referencing records on a Model 204 List) are processed it is very possible that the records will either have their contents changed, or even been deleted by the time the record is read. There are three problems which may be encountered when this happens:

: the record should no longer be selected , its contents no longer matching the selection criteria
: the record has been deleted (and so 'Nonexistent record'messages are produced)
: the record now (due to delete and update processing) contains an extension record.

The last of these causes a 'Sick Record' snap.

While Rocket encourages the use of coding techniques to prevent all of these issues, File Managers can protect themselves from the snaps (at least) by enabling Table X in files where such processing is expected.

==The following Parameters relate to the Use of Table X==

{|
|[[BRLIMSZ parameter]]
|Calculated maximum size of base records
|-
|[[RECRDOPT parameter]]
|Controls the method by which base records are stored
|-
|[[XQLEN parameter]]
|The number of Table X pages in the reuse queue.
|-
|[[XRECPPG parameter]]
|The maximum number of extension slots on a Table X page.
|-
|[[XRESERVE parameter]]
|Table X reserve space per page
|-
|[[XREUSE parameter]]
|Free space required to reuse a table X page
|-
|[[XREUSED parameter]]
|The number of extension slots reused in table X
|-
|[[XSIZE parameter]]
|The number of pages in Table X.
|}

whose use is discussed in [[#File Size Calculation#Sizing Tables B and X|Sizing Tables B and X]]

[[Category:File architecture]]

Table D (File architecture)

2013-05-14T22:44:42Z

Rob: /* The Existence Bit Map */

== Overview ==

Table D contains a variety of structures:

* Record Lists and Bit Maps used for indexing
* The existence Bit Map (a special case of the above)
* The Ordered Index B-Tree
* The Record Map of preallocated fields
* The Procedures (if any)

== <div id="Table D (File Architecture) List and Bit Map pages">List and [[Bit Maps (File Architecture)|Bit Map]] Pages</div>==

The list and [[Bit Maps (File Architecture)|bit map]] pages in Table D are the pointers to sets of records with particular [[Field Value Pairs (File Architecture)|field value pairs]]. Whether you navigate to these pages via the B-Tree or Hash indices, these lists an bit maps exist when there are more than [[Table D (File Architecture)#Ordered Index spacing parameters|IMMEDiate]] records (B-Tree) or one (Hash index) such records in a segment.

=== List Pages ===

List pages may contain lists for more than one field value pair.

The chart below the process that adds values to a List. The notable points are:

* When a list exceeds 30% of the usable page size (6144 bytes) it is converted to a bit map on a new page.
* When a page fills, the list being added to is moved to a new list page

[[File:List_to_Bit_Map_Transition_(File_Architecture).jpg‎]]

=== [[Bit Maps (File Architecture)|Bit Maps]] Used In Indexing ===

While [[Bit Maps (File Architecture)|Bit Maps]] are used in Model 204 in a number of ways, one of the most critical is their use in rapid identification and further processing of sets of records.

Whether using the hash or B-tree indices, a search returns some combination of direct pointers, lists, and bit maps.

Regardless of the mixture, the Model 204 evaluation always processes the resultant set of records as a bit map (ANDing and ORing bit maps being a strength of any IT system) and the result returned in the evaluation (associated with a label or list (see [[#PLACE RECORD and REMOVE RECORD statements|PLACE RECORD and REMOVE RECORD statements]] or [[AddRecordset (Recordset subroutine)|AddRecordset]]) also, internally is held as a bit map.

== <div id="Table D (File Architecture) Existence Bit Map">The Existence Bit Map</div>==

The Existence Bit Map tracks which record numbers in Table B hold base records.

The execution of any [[Basic User Language Statements and Commands#FIND statement|FIND statement]] includes an implied 'and exists' in its processing, and an unqualified find statement simply returns the existence bit map as its found set.

The existence bit map also supports the concept of logically deleted records, where the bit is turned off, but no space cleanup is done. See the [[Data Maintenance#DELETE ALL RECORDS statement|DELETE ALL RECORDS statement]] for further information on this technique.

== <div id="Table D (File Architecture) Ordered Index">Ordered Index</div> ==

===B-Tree index structure===
Fields defined with the ORDERED attribute are stored with their values in the Ordered Index, a B-Tree based index structure that maintains field values in an ordered sequence to facilitate range retrievals. A B-Tree is a tree structure residing in secondary storage (disk) whose elements of access and navigation are disk page size tables, or nodes (See [[#Ordered Index B-Tree diagram|Ordered Index B-Tree diagram]]). It provides a method of accessing record keys in order for a given file.

There is a single B-Tree structure in the file which contains all of the index entries for all of the ORDered fields in the file.

===Ordered Index processing===
Records are first identified in the Ordered Index, then retrieved from the stored data records. The caller can retrieve keys and associated access information with an exact match specification or with a range specification. Only one Ordered Index exists per <var class="product">Model 204</var> file, containing all field-name-equals-value pairs (in sorted sequence) and record access information (pointers to Tables B or D) for all ORDERED fields defined to the file. For more information see [[Table D (File Architecture)#Understanding the Ordered Index|Understanding the Ordered Index]] (below). 
Note
You can use ORDERED fields in value loop processing. See the discussion [[#Introducing value loops|Introducing value loops]].
===Manipulating the Ordered Index===
The Ordered Index is created the first time an ORDERED field is defined and physically resides in Table D. Some of its characteristics can be modified through the REDEFINE command. If multiple deletions and updates reduce the page density and access efficiency, you can rebuild the Ordered Index using the REORGANIZE OI command (see [[ File Size Calculation#File Size Calculation|File Size Calculation]] ). 
===Benefits of the ORDERED attribute===
Choosing the ORDERED attribute provides the following benefits:
<ul>
<li>Alphabetic, alphanumeric, and numeric range retrievals are typically resolved from the index and do not require a direct search of data records. The following examples show such range retrievals. An alphabetic range retrieval is followed by a numeric range retrieval:
NAME:
FIND ALL RECORDS FOR WHICH
NAME IS ALPHA LESS THAN SMITH
END FIND

SAL:
FIND ALL RECORDS FOR WHICH
SALARY IS GREATER THAN 30000
END FIND
</li>
<li>Range searches through the index are supported for fields containing character strings as well as numeric values, for INVISIBLE fields, and for multiply occurring fields.</li>
<li>Record-by-record processing in sequential order of a field value is simplified and made very efficient, because the Ordered Index maintains key values in order and highly clustered. Such processing is invoked by the User Language FOR EACH RECORD (FR) and FOR EACH VALUE (FRV) statements and by the Host Language Interface IFFDV, IFGET, and IFGETV functions.
IFGET supports ORDER SPECIFICATION only in a multicursor program. You can change your program to a multicursor program, if necessary.
</li>
<li>Retrieval of record keys whose values match a given character pattern is optimized. This capability is called pattern matching, and is described in the Rocket <var class="product">Model 204</var> User Language Manual. </li>
</ul>

===Understanding the Ordered Index===
====Types of nodes====
The Ordered Index can have the following types of tree nodes, which are shown in the diagram below and described in the following table: 
<table>
<tr>
<th>Node type</th>
<th>Description </th>
</tr>
<tr>
<td>Root</td>
<td>Highest level node, which normally contains on one page all the pointers to the next level down-either an intermediate node or leaf node, if no intermediate nodes exist. Ordered Index searches begin at the root node.</td>
</tr>
<tr>
<td>Intermediate(s)</td>
<td>Level(s) below the root and above the leaf, which act as directory nodes and contain only pointers to leaf nodes or to lower intermediate nodes.</td>
</tr>
<tr>
<td>Leaf</td>
<td>Lowest level node, which contains a key field-name-equals-value pair, plus a record access pointer to each Table B record containing the pair, or to a Table D record list, or bit pattern that points to the Table B record. (Record lists and bit patterns are described in .) A small Ordered Index tree can fit on a single node, in which case the root is also a leaf node. </td>
</tr>
</table>
In general, each node that has pointers to a lower level node has a large number of such pointers, which are referred to as a large fanout in searching down the tree.
====Node Structure====
Each of the node pages contain:

<table>
<caption>Ordered Index tree node content</caption>
<tr class="head">
<th>Item</th>
<th>Description </th>
</tr>
<tr>
<td>Flag</td>
<td>Indicates node type (root, intermediate, leaf)</td>
</tr>
<tr>
<td>Parent Node Pointer</td>
<td>Non-root node: pointer to parent node</td>
</tr>
<tr>
<td>Root node</td>
<td>General information about the tree</td>
</tr>
<tr>
<td>Node Version Number. </td>
<td>Used during FRV and FR IN ORDER retrievals. 
Determines if the revisited node is the same as the original</td>
</tr>
<tr>
<td>Prior Sibling Node Pointer</td>
<td>Pointer to the left sibling node (at leaf level only)</td>
</tr>
<tr>
<td>Next Sibling Node Pointer</td>
<td>Pointer to the right sibling node (at leaf level only)</td>
</tr>
<tr>
<td>Offset Last Entry</td>
<td>Pointer to free space on the page</td>
</tr>
<tr>
<td>Offset End of Page</td>
<td>X’1800’ for 6184 byte page (only valid page size)</td>
</tr>
<tr>
<td>Prefix Key Pointer
<td>Pointer to the prefix key (longest key which every record has in common)</td>
</tr>
<tr>
<td>Entry Pointers</td>
<td>Pointers to entries (data items) on the page</td>
</tr>
</table>

====Ordered Index B-Tree diagram====
This diagram represents a portion of a typical Ordered Index B-Tree, depicting the relationship of the tree nodes. The figure does not show leaf-node pointers to Table B records or to Table D record lists or bit patterns. It also does not represent the likely case in which the tree nodes contain a few hundred pointers per page. 
Logical Structure of Ordered Index B-Tree
[[File:File Architecture 2.gif]]
Processing
The Ordered Index B-Tree is processed as follows:
<ul>
<li>When new Ordered Index entries are inserted in a full leaf node, a split of the node into two new nodes occurs, and an additional pointer is added to the node at the next higher level. </li>
<li>If this node is also full, it is split into two new nodes, and a new pointer is added to an intermediate node at the next higher level.</li>
<li>If this process reaches back to a full root node, the root is split into two intermediate nodes that are pointed to by a new root, one level higher. </li>
</ul>
This newly created level represents an increase by one of the tree's depth. Only root node splits increase the tree's depth. All leaf node entries are at the same depth. 
An Ordered Index tree with a depth of three levels, with reasonable assumptions about entry sizes, can hold about 500 million entries. <var class="product">Model 204</var> automatically maintains the tree structure. 

<div id="Ordered Index spacing parameters">Ordered Index spacing parameters</div>
Certain characteristics of the Ordered Index tree structure are controlled by the attributes set when the ORDERED field is [[DEFINE FIELD command|defined]]. 

<table>
<caption>Ordered Index spacing parameters</caption>
<tr>
<th>Parameter</th>
<th>Default</th>
<th>Range</th>
<th>Specifies...</th>
</tr>
<tr>
<td>LRESERVE</td>
<td align="right">15</td>
<td>0 - 99</td>
<td>Percentage of left-hand leaf node space to leave free upon a node split during deferred update mode processing, including file loading or Ordered Index tree restructuring with the REORGANIZE OI command. Too low a setting can cause excessive splitting during subsequent minor modifications.</td>
</tr>
<tr>
<td>NRESERVE</td>
<td align="right">15</td>
<td>0 - 99</td>
<td>Percentage of left-hand intermediate node space to leave free upon a split during deferred update mode processing, including file loading or Ordered Index tree restructuring with the REORGANIZE OI command. Too low a setting can cause excessive splitting during subsequent minor modifications. </td>
</tr>
<tr>
<td>SPLITPCT
(or SPLT) </td>
<td align="right">50 </td>
<td>1 - 100 </td>
<td>
Percentage of node data placed on the left-hand node when a split occurs during non-deferred User Language or Host Language Interface requests. 
Note: Unlike the two previous parameters, SPLITPCT specifies data to go on the left node, rather than space. 
Too high or too low a setting can cause excessive splitting. 
Consider the characteristics of the data insetting this parameter. If, for example, you are indexing a processing date (or similar) it is likely that the data is always going to be increasing, and so a high SPLITPCT would be a good choice.
</td>
</tr>
<tr>
<td>IMMED </td>
<td align="right">1 </td>
<td>0 and 255 </td>
<td>Number of direct (immediate) pointers to Table B records per leaf page entry per segment in the Ordered Index tree. If the number of records to be pointed to in an entry is greater than the value of IMMED, all the record pointers are moved to a Table D list or bit map containing pointers to Table B. Storing information in Table D lists slows range retrieval but reduces Ordered Index tree depth. </td>
</tr>
</table>

Spacing parameter guidelines
The following guidelines, while not precise, might help you reduce the number of splits and increase update performance at your site. How these parameters function is closely dependent on the data and the application. <var class="product">Model 204</var> customer support strongly suggests that you try the default settings, as well as experiment with these parameter settings to see what works for your site. 
Because updates that cause page splits consume more resources than updates to less-than-full pages, set the spacing parameters to allow sufficient space for subsequent updating. Allowing too much space, however, might increase the B-Tree's depth and thereby impede performance. Knowing the likely updating characteristics of the ORDERED fields is the best guide for setting these parameters. 
The settings of LRESERVE, NRESERVE, SPLITPCT, and IMMED are recommended settings only. The actual movement of data during an update might not conform exactly to the value of the appropriate parameter. The spacing parameters can be changed by specifying the parameter and a new value with the REDEFINE command: 
<ul>
<li>Use the default setting for SPLITPCT (50), unless the field is updated Online and most values are added in strict ascending or descending order, such as dates or employee ID numbers. If field values are added in:</li>
<li>Ascending order, set SPLITPCT higher than 50.</li>
<li>Descending order, set SPLITPCT lower than 50.</li>
<li>If you load records either via the File Load Utility (FLOD) or as deferred updates applied with the Z command, and the ordered field is heavily updated in Online mode, set LRESERVE and NRESERVE higher: up to 50. This causes more splits in the FLOD Z step (see : ), but, by not packing the tree as tightly during the Z step, it should decrease the number of Online splits. Of these two parameters, LRESERVE is more important for tuning. If the field is not heavily updated Online, use the defaults for LRESERVE and NRESERVE. </li>
<li>If the field is updated Online with information that is generally not in order, <var class="product">Model 204</var> customer support suggests that you experiment with the IMMED parameter. This parameter is less important if most updates are entered during the FLOD Z step. With the IMMED parameter, there might be a trade-off between Table D LIST I/O and B-Tree I/O. </li>
</ul>

== <div id="Table D (File Architecture) Record Map">Record Map of Preallocated Fields</div> ==

Also in Table D (and no more than one page) is a map of the preallocated fields defined within the file. This is used when ever a new record is added to the file, as space is reserved for these fields just after the extension pointer at the beginning of the record.

The [[DISPLAY RECORD command]] against the file shows the map. The fields appear in the map in the same order they are defined to the file, so, if you execute the following [[DEFINE FIELD command]]s: 


DEFINE FIELD PRE.FIELD.2 (OCC 1 LEN 9)
DEFINE FIELD PRE.FIELD.1 (OCC 1 BIN)
DEFINE FIELD PRE.FIELD.3 (OCC 1 LEN 20)


The [[DISPLAY RECORD command]] produces:


LENGTH OCCURS PAD NAME
9 1 X'00' PRE.FIELD.2
BIN 1 X'00' PRE.FIELD.1
20 1 X'00' PRE.FIELD.3


== <div id="Table D (File Architecture) Procedures">Procedures</div> ==

There are two parts to the storage of procedures in a Model 204 file:
The actual procedure 'text' (stored sets of commands and program statements run against Model 204 files) are stored, with procedures taking a minimum of 1 page, regardless of how small the procedure is.
And, so as not to have to scan the entire procedure store whenever you need to access one, a procedure dictionary. This dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
Most sites keep their procedures in different files than their data, but, regardless, the files have identical structures whether they contain only procedures, only data, or both.

The procedure dictionary is defined using the [[PDSIZE parameter|PDSIZE]] and [[PDSTRPPG parameter]]s.

===The Procedure Dictionary===

The procedure dictionary is allocated in blocks of one or more contiguous pages (defined by the [[PDSIZE parameter]]). When Model 204 searches for a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, Model 204 searches the pages in the second block, and so on.

 When a new procedure is being stored, and Model 204 (as expected) does not find the name, it stores the new name in the first block in which it can find space. Model 204 allocates a new block of [[PDSIZE parameter]] pages when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused.

==== Approaches to setting [[PDSIZE parameter|PDSIZE]] ====

There are two possible paths you can take in choosing a PDSIZE:

* Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, Model 204 might allocate a new block when space still exists on the old block.
* Have a number of smaller blocks with fewer pages. Although it might take Model 204 longer to find the procedure name, there is less impact on Table D when a new block is allocated.

Rocket Software generally favors the first approach, particularly as the number of procedures you have grows.

====[[PDSTRPPG parameter]]====

PPDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page.

It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File Size Calculation]] for details.

[[Category:File architecture]]

Table D (File architecture)

2013-05-14T22:42:32Z

Rob: /* List and Bit Map Pages */

== Overview ==

Table D contains a variety of structures:

* Record Lists and Bit Maps used for indexing
* The existence Bit Map (a special case of the above)
* The Ordered Index B-Tree
* The Record Map of preallocated fields
* The Procedures (if any)

== <div id="Table D (File Architecture) List and Bit Map pages">List and [[Bit Maps (File Architecture)|Bit Map]] Pages</div>==

The list and [[Bit Maps (File Architecture)|bit map]] pages in Table D are the pointers to sets of records with particular [[Field Value Pairs (File Architecture)|field value pairs]]. Whether you navigate to these pages via the B-Tree or Hash indices, these lists an bit maps exist when there are more than [[Table D (File Architecture)#Ordered Index spacing parameters|IMMEDiate]] records (B-Tree) or one (Hash index) such records in a segment.

=== List Pages ===

List pages may contain lists for more than one field value pair.

The chart below the process that adds values to a List. The notable points are:

* When a list exceeds 30% of the usable page size (6144 bytes) it is converted to a bit map on a new page.
* When a page fills, the list being added to is moved to a new list page

[[File:List_to_Bit_Map_Transition_(File_Architecture).jpg‎]]

=== [[Bit Maps (File Architecture)|Bit Maps]] Used In Indexing ===

While [[Bit Maps (File Architecture)|Bit Maps]] are used in Model 204 in a number of ways, one of the most critical is their use in rapid identification and further processing of sets of records.

Whether using the hash or B-tree indices, a search returns some combination of direct pointers, lists, and bit maps.

Regardless of the mixture, the Model 204 evaluation always processes the resultant set of records as a bit map (ANDing and ORing bit maps being a strength of any IT system) and the result returned in the evaluation (associated with a label or list (see [[#PLACE RECORD and REMOVE RECORD statements|PLACE RECORD and REMOVE RECORD statements]] or [[AddRecordset (Recordset subroutine)|AddRecordset]]) also, internally is held as a bit map.

== <div id="Table D (File Architecture) Existence Bit Map">The Existence Bit Map</div>==

The Existence Bit Map tracks which record numbers in Table B hold base records.

The execution of any [[FIND statement]] includes an implied 'and exists' in its processing, and an unqualified find statement simply returns the existence bit map as its found set.

The existence bit map also supports the concept of logically deleted records, where the bit is turned off, but no space cleanup is done. See the [[DELETE ALL RECORDS statement]] for further information on this technique.

== <div id="Table D (File Architecture) Ordered Index">Ordered Index</div> ==

===B-Tree index structure===
Fields defined with the ORDERED attribute are stored with their values in the Ordered Index, a B-Tree based index structure that maintains field values in an ordered sequence to facilitate range retrievals. A B-Tree is a tree structure residing in secondary storage (disk) whose elements of access and navigation are disk page size tables, or nodes (See [[#Ordered Index B-Tree diagram|Ordered Index B-Tree diagram]]). It provides a method of accessing record keys in order for a given file.

There is a single B-Tree structure in the file which contains all of the index entries for all of the ORDered fields in the file.

===Ordered Index processing===
Records are first identified in the Ordered Index, then retrieved from the stored data records. The caller can retrieve keys and associated access information with an exact match specification or with a range specification. Only one Ordered Index exists per <var class="product">Model 204</var> file, containing all field-name-equals-value pairs (in sorted sequence) and record access information (pointers to Tables B or D) for all ORDERED fields defined to the file. For more information see [[Table D (File Architecture)#Understanding the Ordered Index|Understanding the Ordered Index]] (below). 
Note
You can use ORDERED fields in value loop processing. See the discussion [[#Introducing value loops|Introducing value loops]].
===Manipulating the Ordered Index===
The Ordered Index is created the first time an ORDERED field is defined and physically resides in Table D. Some of its characteristics can be modified through the REDEFINE command. If multiple deletions and updates reduce the page density and access efficiency, you can rebuild the Ordered Index using the REORGANIZE OI command (see [[ File Size Calculation#File Size Calculation|File Size Calculation]] ). 
===Benefits of the ORDERED attribute===
Choosing the ORDERED attribute provides the following benefits:
<ul>
<li>Alphabetic, alphanumeric, and numeric range retrievals are typically resolved from the index and do not require a direct search of data records. The following examples show such range retrievals. An alphabetic range retrieval is followed by a numeric range retrieval:
NAME:
FIND ALL RECORDS FOR WHICH
NAME IS ALPHA LESS THAN SMITH
END FIND

SAL:
FIND ALL RECORDS FOR WHICH
SALARY IS GREATER THAN 30000
END FIND
</li>
<li>Range searches through the index are supported for fields containing character strings as well as numeric values, for INVISIBLE fields, and for multiply occurring fields.</li>
<li>Record-by-record processing in sequential order of a field value is simplified and made very efficient, because the Ordered Index maintains key values in order and highly clustered. Such processing is invoked by the User Language FOR EACH RECORD (FR) and FOR EACH VALUE (FRV) statements and by the Host Language Interface IFFDV, IFGET, and IFGETV functions.
IFGET supports ORDER SPECIFICATION only in a multicursor program. You can change your program to a multicursor program, if necessary.
</li>
<li>Retrieval of record keys whose values match a given character pattern is optimized. This capability is called pattern matching, and is described in the Rocket <var class="product">Model 204</var> User Language Manual. </li>
</ul>

===Understanding the Ordered Index===
====Types of nodes====
The Ordered Index can have the following types of tree nodes, which are shown in the diagram below and described in the following table: 
<table>
<tr>
<th>Node type</th>
<th>Description </th>
</tr>
<tr>
<td>Root</td>
<td>Highest level node, which normally contains on one page all the pointers to the next level down-either an intermediate node or leaf node, if no intermediate nodes exist. Ordered Index searches begin at the root node.</td>
</tr>
<tr>
<td>Intermediate(s)</td>
<td>Level(s) below the root and above the leaf, which act as directory nodes and contain only pointers to leaf nodes or to lower intermediate nodes.</td>
</tr>
<tr>
<td>Leaf</td>
<td>Lowest level node, which contains a key field-name-equals-value pair, plus a record access pointer to each Table B record containing the pair, or to a Table D record list, or bit pattern that points to the Table B record. (Record lists and bit patterns are described in .) A small Ordered Index tree can fit on a single node, in which case the root is also a leaf node. </td>
</tr>
</table>
In general, each node that has pointers to a lower level node has a large number of such pointers, which are referred to as a large fanout in searching down the tree.
====Node Structure====
Each of the node pages contain:

<table>
<caption>Ordered Index tree node content</caption>
<tr class="head">
<th>Item</th>
<th>Description </th>
</tr>
<tr>
<td>Flag</td>
<td>Indicates node type (root, intermediate, leaf)</td>
</tr>
<tr>
<td>Parent Node Pointer</td>
<td>Non-root node: pointer to parent node</td>
</tr>
<tr>
<td>Root node</td>
<td>General information about the tree</td>
</tr>
<tr>
<td>Node Version Number. </td>
<td>Used during FRV and FR IN ORDER retrievals. 
Determines if the revisited node is the same as the original</td>
</tr>
<tr>
<td>Prior Sibling Node Pointer</td>
<td>Pointer to the left sibling node (at leaf level only)</td>
</tr>
<tr>
<td>Next Sibling Node Pointer</td>
<td>Pointer to the right sibling node (at leaf level only)</td>
</tr>
<tr>
<td>Offset Last Entry</td>
<td>Pointer to free space on the page</td>
</tr>
<tr>
<td>Offset End of Page</td>
<td>X’1800’ for 6184 byte page (only valid page size)</td>
</tr>
<tr>
<td>Prefix Key Pointer
<td>Pointer to the prefix key (longest key which every record has in common)</td>
</tr>
<tr>
<td>Entry Pointers</td>
<td>Pointers to entries (data items) on the page</td>
</tr>
</table>

====Ordered Index B-Tree diagram====
This diagram represents a portion of a typical Ordered Index B-Tree, depicting the relationship of the tree nodes. The figure does not show leaf-node pointers to Table B records or to Table D record lists or bit patterns. It also does not represent the likely case in which the tree nodes contain a few hundred pointers per page. 
Logical Structure of Ordered Index B-Tree
[[File:File Architecture 2.gif]]
Processing
The Ordered Index B-Tree is processed as follows:
<ul>
<li>When new Ordered Index entries are inserted in a full leaf node, a split of the node into two new nodes occurs, and an additional pointer is added to the node at the next higher level. </li>
<li>If this node is also full, it is split into two new nodes, and a new pointer is added to an intermediate node at the next higher level.</li>
<li>If this process reaches back to a full root node, the root is split into two intermediate nodes that are pointed to by a new root, one level higher. </li>
</ul>
This newly created level represents an increase by one of the tree's depth. Only root node splits increase the tree's depth. All leaf node entries are at the same depth. 
An Ordered Index tree with a depth of three levels, with reasonable assumptions about entry sizes, can hold about 500 million entries. <var class="product">Model 204</var> automatically maintains the tree structure. 

<div id="Ordered Index spacing parameters">Ordered Index spacing parameters</div>
Certain characteristics of the Ordered Index tree structure are controlled by the attributes set when the ORDERED field is [[DEFINE FIELD command|defined]]. 

<table>
<caption>Ordered Index spacing parameters</caption>
<tr>
<th>Parameter</th>
<th>Default</th>
<th>Range</th>
<th>Specifies...</th>
</tr>
<tr>
<td>LRESERVE</td>
<td align="right">15</td>
<td>0 - 99</td>
<td>Percentage of left-hand leaf node space to leave free upon a node split during deferred update mode processing, including file loading or Ordered Index tree restructuring with the REORGANIZE OI command. Too low a setting can cause excessive splitting during subsequent minor modifications.</td>
</tr>
<tr>
<td>NRESERVE</td>
<td align="right">15</td>
<td>0 - 99</td>
<td>Percentage of left-hand intermediate node space to leave free upon a split during deferred update mode processing, including file loading or Ordered Index tree restructuring with the REORGANIZE OI command. Too low a setting can cause excessive splitting during subsequent minor modifications. </td>
</tr>
<tr>
<td>SPLITPCT
(or SPLT) </td>
<td align="right">50 </td>
<td>1 - 100 </td>
<td>
Percentage of node data placed on the left-hand node when a split occurs during non-deferred User Language or Host Language Interface requests. 
Note: Unlike the two previous parameters, SPLITPCT specifies data to go on the left node, rather than space. 
Too high or too low a setting can cause excessive splitting. 
Consider the characteristics of the data insetting this parameter. If, for example, you are indexing a processing date (or similar) it is likely that the data is always going to be increasing, and so a high SPLITPCT would be a good choice.
</td>
</tr>
<tr>
<td>IMMED </td>
<td align="right">1 </td>
<td>0 and 255 </td>
<td>Number of direct (immediate) pointers to Table B records per leaf page entry per segment in the Ordered Index tree. If the number of records to be pointed to in an entry is greater than the value of IMMED, all the record pointers are moved to a Table D list or bit map containing pointers to Table B. Storing information in Table D lists slows range retrieval but reduces Ordered Index tree depth. </td>
</tr>
</table>

Spacing parameter guidelines
The following guidelines, while not precise, might help you reduce the number of splits and increase update performance at your site. How these parameters function is closely dependent on the data and the application. <var class="product">Model 204</var> customer support strongly suggests that you try the default settings, as well as experiment with these parameter settings to see what works for your site. 
Because updates that cause page splits consume more resources than updates to less-than-full pages, set the spacing parameters to allow sufficient space for subsequent updating. Allowing too much space, however, might increase the B-Tree's depth and thereby impede performance. Knowing the likely updating characteristics of the ORDERED fields is the best guide for setting these parameters. 
The settings of LRESERVE, NRESERVE, SPLITPCT, and IMMED are recommended settings only. The actual movement of data during an update might not conform exactly to the value of the appropriate parameter. The spacing parameters can be changed by specifying the parameter and a new value with the REDEFINE command: 
<ul>
<li>Use the default setting for SPLITPCT (50), unless the field is updated Online and most values are added in strict ascending or descending order, such as dates or employee ID numbers. If field values are added in:</li>
<li>Ascending order, set SPLITPCT higher than 50.</li>
<li>Descending order, set SPLITPCT lower than 50.</li>
<li>If you load records either via the File Load Utility (FLOD) or as deferred updates applied with the Z command, and the ordered field is heavily updated in Online mode, set LRESERVE and NRESERVE higher: up to 50. This causes more splits in the FLOD Z step (see : ), but, by not packing the tree as tightly during the Z step, it should decrease the number of Online splits. Of these two parameters, LRESERVE is more important for tuning. If the field is not heavily updated Online, use the defaults for LRESERVE and NRESERVE. </li>
<li>If the field is updated Online with information that is generally not in order, <var class="product">Model 204</var> customer support suggests that you experiment with the IMMED parameter. This parameter is less important if most updates are entered during the FLOD Z step. With the IMMED parameter, there might be a trade-off between Table D LIST I/O and B-Tree I/O. </li>
</ul>

== <div id="Table D (File Architecture) Record Map">Record Map of Preallocated Fields</div> ==

Also in Table D (and no more than one page) is a map of the preallocated fields defined within the file. This is used when ever a new record is added to the file, as space is reserved for these fields just after the extension pointer at the beginning of the record.

The [[DISPLAY RECORD command]] against the file shows the map. The fields appear in the map in the same order they are defined to the file, so, if you execute the following [[DEFINE FIELD command]]s: 


DEFINE FIELD PRE.FIELD.2 (OCC 1 LEN 9)
DEFINE FIELD PRE.FIELD.1 (OCC 1 BIN)
DEFINE FIELD PRE.FIELD.3 (OCC 1 LEN 20)


The [[DISPLAY RECORD command]] produces:


LENGTH OCCURS PAD NAME
9 1 X'00' PRE.FIELD.2
BIN 1 X'00' PRE.FIELD.1
20 1 X'00' PRE.FIELD.3


== <div id="Table D (File Architecture) Procedures">Procedures</div> ==

There are two parts to the storage of procedures in a Model 204 file:
The actual procedure 'text' (stored sets of commands and program statements run against Model 204 files) are stored, with procedures taking a minimum of 1 page, regardless of how small the procedure is.
And, so as not to have to scan the entire procedure store whenever you need to access one, a procedure dictionary. This dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
Most sites keep their procedures in different files than their data, but, regardless, the files have identical structures whether they contain only procedures, only data, or both.

The procedure dictionary is defined using the [[PDSIZE parameter|PDSIZE]] and [[PDSTRPPG parameter]]s.

===The Procedure Dictionary===

The procedure dictionary is allocated in blocks of one or more contiguous pages (defined by the [[PDSIZE parameter]]). When Model 204 searches for a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, Model 204 searches the pages in the second block, and so on.

 When a new procedure is being stored, and Model 204 (as expected) does not find the name, it stores the new name in the first block in which it can find space. Model 204 allocates a new block of [[PDSIZE parameter]] pages when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused.

==== Approaches to setting [[PDSIZE parameter|PDSIZE]] ====

There are two possible paths you can take in choosing a PDSIZE:

* Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, Model 204 might allocate a new block when space still exists on the old block.
* Have a number of smaller blocks with fewer pages. Although it might take Model 204 longer to find the procedure name, there is less impact on Table D when a new block is allocated.

Rocket Software generally favors the first approach, particularly as the number of procedures you have grows.

====[[PDSTRPPG parameter]]====

PPDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page.

It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File Size Calculation]] for details.

[[Category:File architecture]]

Obsolete features

2013-05-14T22:40:40Z

Rob:

===Statement numbers===
This appendix describes certain features of User Language which, while still supported, are generally considered obsolete. They have been superseded by other, more efficient features or techniques. Rocket Software does not recommend using these features in newly written requests and procedures.
Rocket Software strongly recommends that you use statement labels (see [[Request Composition Rules#Statement labels|Statement labels]]) rather than statement numbers. Although statement numbers are still supported, this section is included primarily as documentation for applications developed using earlier releases of <var class="product">Model 204</var>.
====FOPT parameter====
The setting of the FOPT (File Options) parameter determines whether procedures within a file must be labeled or numbered. For more information on the FOPT parameter, refer to the Rocket <var class="product">Model 204</var> Parameter and Command Reference Manual. 
====Rules for using statement numbers====
The rules for specifying statement numbers in User Language statements are summarized below.
<ul>
<li>A statement number is made up of the digits 0-9 and an optional period (.). The number must begin with a digit and cannot contain blanks, although blanks preceding or following it are optional. </li>
</li>
<li>A statement number can start in any column up to but not including column INCCC.</li>
</li>
<li>Any statement can be numbered, but some statements must be numbered. In particular, a statement must be numbered if:</li>
</li>
</ul>
It immediately follows a STORE RECORD or a FIND statement, in which case the statement number indicates the end of the preceding statement.
It is referred to by later statements. In most requests, COUNT RECORDS IN n, COUNT RECORD ON LIST m, NOTE, FIND, FOR EACH VALUE, and FOR EACH OCCURRENCE are referred to later and should therefore be numbered.
It is the first statement after a loop, in which case a number is needed to indicate the end of the loop. An END statement following a loop does not require a number.
It is the statement following a THEN or ELSE clause which is to be executed if the condition is false.
<ul>
<li>The retrieval conditions of a FIND statement, the subexpressions of an IF statement, and the fields of a STORE RECORD statement must not be numbered, even if they start new lines. </li>
</li>
<li>A statement number can have any number of parts, which are delimited by periods. Thus, 2.3 and 0.1 are two part numbers, and 0.05.4 is a three part number. </li>
</li>
<li>A period (.) following a statement number is optional, but the periods separating the parts are required. </li>
For example:
1.1

and
1.1.

are both legal and are interpreted as the same number. 
This rule also applies when referring to statements by number. Thus:
FOR EACH RECORD IN 1.

and
FOR EACH RECORD IN 1

refer to the same statement. 
</li>
<li>Any part of a statement number can be arbitrarily large. </li>
</li>
<li>The number of parts in a statement number must be the same as the level on which the statement is nested. For example, the following sequence is illegal because 2.1.1 has three parts but is nested at the second level:</li>
2. FOR EACH RECORD IN 1
2.1.1 PRINT ALL INFORMATION
</li>
<li>If a statement is not numbered, it is assigned a default level of nesting. The default level is the same as the level of the previous statement. If there is no previous statement, the default is the first level. If the previous statement starts a loop or a THEN, ELSE, or ELSEIF clause, or is a SUBROUTINE statement, the default level is one greater than the level of the previous statement. </li>
</li>
<li>Any part of a statement number can have leading zeros. However, a number with leading zeros is not equivalent to one without. Thus 01 and 1 are both legal but not equivalent; the same is true of 1.1 and 1.01. </li>
</li>
<li>Statements need not be numbered in sequential order. The statement number is just a label for the statement; its numerical value has no significance. </li>
The following, for instance, is a legal request:
BEGIN
3. FIND ALL RECORDS FOR WHICH
COMPANY = ROCKET
1. FOR EACH RECORD IN 3.
3.1 PRINT ALL INFORMATION
2.6. SKIP 1 LINE
END
</li>
<li>Within a request, statement numbers should be unique. If not, <var class="product">Model 204</var> prints the message:</li>
M204.0223: STATEMENT LABEL MULTIPLY DEFINED

This is a warning message; the request can still be run. 
</li>
<li>A statement number followed by a label is allowed with or without a space between the number and the label. If a statement number is followed by a label and there is no space between them, User Language separates them into statement number and label. Although a statement number can be followed by a label, it is strongly recommended that you avoid placing statement numbers and labels on the same line. </li>
</li>
</ul>
Examples
The following request addresses an automated library card catalogue. Each record in the file contains information that would normally appear on a single card in the catalogue, such as AUTHOR, TITLE, SUBJECT, and CATALOGUE NUMBER.
BEGIN
1. FIND ALL RECORDS FOR WHICH
AUTHOR = PAULING
2. FOR EACH RECORD IN 1
2.1 NOTE SUBJECT
2.2 FIND ALL RECORDS FOR WHICH
SUBJECT = VALUE IN 2.1
2.3 FOR EACH RECORD IN 2.2
2.3.1 PRINT TITLE
3. COUNT RECORDS IN 1
PRINT COUNT IN 3
END

The following request uses a subroutine to validate full-screen input entries. A screen named DATA is defined with input areas named ITEM6, ITEM7, etc. Values entered during the READ SCREEN statement are validated one at a time by subroutine 900. Each screen item is assigned to the argument variable %A before the subroutine is called. If the item fails the validation, the subroutine sets %TAG to a nonzero value before returning. The request sets a tag on the screen for each incorrect item. The REREAD statement is issued if a screen item fails the validity tests.
BEGIN
SCREEN DATA
.
.
.
END SCREEN
READ SCREEN DATA NO REREAD
*VALIDATE DATA ITEMS
1. %A = %DATA:ITEM6
CALL 900
IF %TAG THEN TAG %DATA:ITEM6
2. %A = DATA:ITEM7
CALL 900
.
.
.
50. IF $CHKTAG('DATA') THEN
REREAD SCREEN DATA
JUMP TO 1
51. *PROCESS DATA
.
.
.
*SUBROUTINE TO PERFORM VALIDATION BY TABLE LOOKUP
* IN: %A VALUE
* OUT: %TAG NONZERO IF INVALID
900. SUBROUTINE
.
.
.
END

===$DSCR function===
The $DSCR function interprets its character string argument as a field name. It returns a variable-length character string describing the specified field. New application development should incorporate [[$FDEF#$FDEF|$FDEF]] that supplanted the $DSCR function.
The following discussion is provided to maintain existing code. Each letter in the returned string represents a particular field attribute. Attributes are listed in [[#$DSCR function|$DSCR function]]. 
<table>
<caption>$DSCR field attribute codes (file context)</caption>
<tr class="head">
<th>Character</th>
<th>Attribute</th>
</tr>
<tr>
<td>A</td>
<td>ORDERED CHARACTER</td>
</tr>
<tr>
<td>C</td>
<td>CODED</td>
</tr>
<tr>
<td>D</td>
<td>DEFERRABLE</td>
</tr>
<tr>
<td>F</td>
<td>FRV</td>
</tr>
<tr>
<td>I</td>
<td>INVISIBLE</td>
</tr>
<tr>
<td>K</td>
<td>KEY</td>
</tr>
<tr>
<td>L</td>
<td>LEVEL</td>
</tr>
<tr>
<td>M</td>
<td>MANY-VALUED</td>
</tr>
<tr>
<td>N</td>
<td>ORDERED NUMERIC</td>
</tr>
<tr>
<td>O</td>
<td>OCCURS</td>
</tr>
<tr>
<td>P</td>
<td>UPDATE IN PLACE</td>
</tr>
<tr>
<td>Q</td>
<td>UNIQUE</td>
</tr>
<tr>
<td>R</td>
<td>NUMERIC RANGE</td>
</tr>
<tr>
<td>S</td>
<td>STRING</td>
</tr>
<tr>
<td>T</td>
<td>FLOAT</td>
</tr>
<tr>
<td><var>U</var></td>
<td><var>Undefined</var></td>
</tr>
<tr>
<td>W</td>
<td>AT-MOST-ONE</td>
</tr>
</table>
How $DSCR works
When $DSCR is invoked in file context, the returned string represents the description of the specified field in the current file. 
Each letter that appears in the return value corresponds to an attribute in the field description. For example, if K is one of the letters in the returned string, then the field is KEY. 
If a particular letter does not appear in the result of a $DSCR call, then either the corresponding attribute does not apply or the attribute's opposite is in effect. For example, if M (many-valued) does not appear, the field is NON-CODED and NON-FRV, in which case M does not apply, or it is FEW-VALUED. You can resolve this by looking for C and F in the returned string. 
When $DSCR is invoked in group context, the returned string represents a composite description of the field in all of the files of the current group. Some of the letters imply that the corresponding field attribute is present in all of the files in the group; others imply that the attribute is present in some (at least one) file in the group. If the field specified as the $DSCR argument is not defined in the current file or group, $DSCR returns the character string "U" (undefined). [[#$DSCR function|$DSCR function]] lists the individual letters and their meanings in group context. 
<table>
<caption>$DSCR field attribute codes (group context)</caption>
<tr class="head">
<th>Character</th>
<th>Attribute</th>
</tr>
<tr>
<td>A</td>
<td>ORDERED CHARACTER in some</td>
</tr>
<tr>
<td>C</td>
<td>CODED in all</td>
</tr>
<tr>
<td>D</td>
<td>DEFERRABLE in some</td>
</tr>
<tr>
<td>F</td>
<td>FRV in some</td>
</tr>
<tr>
<td>I</td>
<td>INVISIBLE in all</td>
</tr>
<tr>
<td>K</td>
<td>KEY in all</td>
</tr>
<tr>
<td>L</td>
<td>LEVEL in some</td>
</tr>
<tr>
<td>M</td>
<td>MANY-VALUED in all</td>
</tr>
<tr>
<td>N</td>
<td>ORDERED NUMERIC in some</td>
</tr>
<tr>
<td>O</td>
<td>OCCURS in some</td>
</tr>
<tr>
<td>P</td>
<td>UPDATE IN PLACE in some</td>
</tr>
<tr>
<td>Q</td>
<td>UNIQUE in some</td>
</tr>
<tr>
<td>R</td>
<td>NUMERIC RANGE in all</td>
</tr>
<tr>
<td>S</td>
<td>STRING in all</td>
</tr>
<tr>
<td>T</td>
<td>FLOAT in some</td>
</tr>
<tr>
<td>W</td>
<td>AT-MOST-ONE in all</td>
</tr>
<tr>
<td>U</td>
<td>Undefined</td>
</tr>
</table>
Example
This request determines the attributes of a field and performs one of three types of searches, depending on the results of $DSCR.
BEGIN
%A = $READ ('FIELD NAME')
%B = $READ ('FIELD VALUE')
%C = $DSCR (%A)
IF %C EQ 'U' THEN
PRINT 'ILLEGAL FIELD'
JUMP TO STOP
END IF
*CHECK FOR NON-KEY
IF $INDEX (%C, 'K') EQ 0 THEN
JUMP TO NUM.RNG.CHK
END IF
FIND AND PRINT COUNT
%%A = %B
END FIND
JUMP TO STOP

*CHECK FOR NUMERIC RANGE
NUM.RNG.CHK: IF $INDEX (%C, 'R') EQ 0 THEN
JUMP TO ALL.RECS
END IF
FIND AND PRINT COUNT
%%A IS %B
END FIND
JUMP TO STOP
*NEITHER KEY FOR NUMERIC RANGE
ALL.RECS: FIND ALL RECORDS
END FIND
FOR EACH RECORD IN ALL.RECS
IF %%A = %B THEN
PLACE RECORD ON LIST OK
END IF
END FOR
OKS: COUNT RECORDS ON LIST OK
PRINT COUNT IN OKS
STOP: END
END


[[Category:SOUL]]

Table A (File architecture)

2013-05-14T22:31:12Z

Rob: /* Internal File Dictionary */

Table A contains three structures:

A dictionary of the fieldgroup / field names and their attributes.

Some attributes (notably '[[#Field Design (File Management)#CODED and NON-CODED attributes|CODED]]') require lists of values to be maintained. These lists are stored either in the [[#Field Design (File Management)#FEW-VALUED and MANY-VALUED attributes|FEW-VALUED or MANY-VALUED attribute]]s structures.

Table A usually is small in relation to the rest of the file.

<div id="Internal File Dictionary">
== <div id="Table A (File Architecture) Internal File Dictionary">Internal File Dictionary</div> ==

Defined by the [[ATRPG parameter|ATRPG]].

The internal file dictionary is a hashed file where each page contains up to [[ASTRPPG parameter|ASTRPPG]] field or field group definitions.

Each entry contains the field code (the representation of the field as physically used in records); the field name; and the attributes as assigned by the [[DEFINE FIELD command]] (or by a redefinition).

To understand all the possible content of any entry, please refer to the [[ZFIELD image]] (the structure definition is provided with the Model 204 product). This image is populated by the [[Data Maintenance#$FDEF|$FDEF]] or [[Data Maintenance#$LSTFLD|$LSTFLD function]]s.

=== Non [[FILEORG parameter|FILEORG]] x'100' Files ===

The maximum number of fields (the sum of [[ASTRPPG parameter|ASTRPPG]] * [[ATRPG parameter|ATRPG]]) in any Model 204 file is 4000.

Even when the product of the above is 4000 or less, this number may not actually be reached because of wasted entries (where ASTRPPG is defined too large, you can not fit the full number on any page) or due to vagaries of the hashing algorithm.

=== Enhanced Data Handling Files ([[FILEORG parameter|FILEORG]] x'100' Files) ===

With the introduction of X'100'files (in Model 204 V7R5) the maximum number of fields ([[ASTRPPG parameter|ASTRPPG]] * [[ATRPG parameter|ATRPG]]) has been increased to 32000. In order to support this increase, as well as the additional attributes. the field code has been increased from 2 to three bytes.

Where the maximum number of fields exceeds 4000, no fields may be defined as [[#Field Design (File Management)#KEY and NON-KEY Attribute|KEY]] or [[#Field Design (File Management)#NUMERIC RANGE and NON-RANGE attributes|NUMERIC RANGE]].

== Many and Few Valued Pages ==

If a field has the [[#Field Design (File Management)#CODED and NON-CODED attribute|CODED]] or [[#Field Design (File Management)#FOR EACH VALUE (FRV) and NON-FRV attibute|FRV]] attribute, a complete list of the values that the field has ever had (since it was last created or reorganized) is held in either FEW-VALUED or MANY-VALUED pages in Table A (with the latter the default).

Both of these sets of pages should be kept very small. If large numbers of values exist, the File Manager should consider making the field Ordered.

==The following Parameters relate to the Use of Table A==

::{|
|[[ASIZE parameter]]
|A view only parameter containing the size of Table A 
the sum of ATRPG + FVFPG + MVFPG)
|-
|[[ASTRPPG parameter]]
|The maximum number of field / RFG definitions per page
|-
|[[ATRPG parameter]]
|The number of pages containing field / RFG definitions
|-
|[[FVFPG parameter]]
|The number of pages containing Few Valued Field values.
|-
|[[MVFPG parameter]]
|The number of pages containing Many Valued Field values.
|}

[[Category:File architecture]]

Field group (File architecture)

2013-05-14T22:29:02Z

Rob: /* Overview */

==Overview==
Data items do not normally exist on their own. If we take the case of addresses, for example, there are a series of fields that exist for each (house number, city, state , zip code) which clearly operate interdependently. 

The idea of a Repeating Field Group (RFG) is to take these related fields and package them as a single entity so they can be read and updated with a single operation.

Such packaging improves the readability and maintainability of Soul programs (see [[:Category:SOUL|Soul programming]] for the full detail of the statement changes) but also makes the Model 204 processing far more efficient.

==Performance==
Code accessing RFGs perform better in two main areas:

===Improved record scan:===

In general, much of the time spent in Model 204 processing is due to the need to scan across the record, and the fact that the scan reads a field at a time and, if it is not the one that is need, goes on to the next, and so forth. As records grow in length, this scan, obviously, takes longer.

With RFGs, the scan skips a group, rather than a field at a time, and so can find a specified data item faster.

But, in reality, the improvement is better than this. If you are looking for a number of related (but non-RFG) fields, each field requires a separate scan to find it (insert rules mean that the data can not be presumed to be contiguous), so, if you are looking for 6 individual fields, the record must be scanned, once each.

If the related fields are packaged as an RFG, a single scan of the record will find all the fields; in addition, all of the related data items are in a single location.

===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.

==Field groups and Table B storage considerations==

At first glance, the performance improvement comes at a cost of space (but this can usually be offset).

The costs:

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 (File Architecture)|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.

===Space saving and default and null values===

In fact, depending on the characteristics of the data you are storing, the use of RFGs may actually save space.

Take as an example, a financial application where you are tracking a number of types of income over time. So you have an RFG containing a date and a number of income types: salary; interest; dividends; and so forth. It is likely that the majority of people for which you are keeping data have only a few of the many types of interest, so your record may have mostly zeros.

If so, by adding a [[#Field Design (File Management)#DEFAULT-VALUE (DV) attribute|default value]] of 0 and a [[#Field Design (File Management)#STORE-DEFAULT (SD) and STORE-NULL (SN) attributes|store default]] of NONE (the default for [[#Field Design (File Management)#AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes|exactly one]] fields in RFGs) none of the 0s would be physically stored (but would be treated as if they were).

For many files, the implementation of RFGs will improve both perfromance and space utilization.

==Field Group Identifiers==
As mentioned above, every field group has unique ID.

This ID can be read with the [[$FIELDGROUPID function]] and is also displayed when a [[PRINT ALL INFORMATION statement|PRINT ALL INFORMATION]] is done.

While, by itself, the ID is just for uniqueness, there is an interesting use for it, in that you can tell the order that things happened to a file, which is invaluable in debugging.

[[Category:File architecture]]

Record (File architecture)

2013-05-14T22:26:48Z

Rob: /* Record Growth */

== Overview ==

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the [[#Table A (File Architecture) Internal File Dictionary|Internal File Dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique (but temporary... it will likely change when the file is reorganized) internal record number (IRN) that is used by the system to build index entries for the record.

For example, the following code:


IN ''filename'' STORE RECORD
END STORE


Does, in fact, physically store a record. It has been assigned an [[#Internal Record Number|Internal Record Number]] and would contain the pre-allocated field structure (if any), but no data.

== Records. Base Records and Extension Records ==

The term 'record' is actually used three ways: 

* the record as a full collection of all of the data about a 'thing'
* base records: the initial portion of that data
* extension records: a (possible) string of additional portions of the data

These are discussed below:

=== the Record as a container ===

Is just that: a way to describe all of the data held against the record key (presuming there is one)...

=== <div id="Base Records">Base Records</div> ===

The base record is the first (and, often, only) part of the record. It is assigned a slot in Table B, and its internal record number is how Model 204 identifies the record for indexing peuporses as well as in record sets and lists.

=== <div id="Extension Records">Extension Records</div> ===

When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record) one or more extension records are stored.

If [[Table X (File Architecture)|Table X]] is enables, all such extensions are stored there, otherwise the extension(s) are stored in Table B.

=== <div id="Record Growth">Record Growth</div> ===

The [[Data Maintenance#ADD statement|ADD statement]] (or the file load process) always places new data at the end of a record, and so, the record growth is straightforward: add a field at the end of the record, if it doesn't fit, start a new extension.

[[Data Maintenance#INSERT statement|INSERT]]s are more complicated. Whether updating fields or repeating field groups, the correct location must be found within a record, and the data inserted at that point.

It is, of course, quite possible, that there will not be enough space on the page to insert it, in which case space is made by moving data from this record (after the insert point) down the extension chain. So, with large extension records, it is conceivable that a single field added to the base record (for example) might cause all of the extensions to need to change.

=== <div id="Internal Record Number">The Internal Record Number (IRN)</div> ===

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[FOR RECORD NUMBER statement]]) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before. 

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bit Maps (File Architecture)|Bit Maps]] for more information.

== The Structure of a Model 204 Record ==

As shown in [[Table B (File Architecture)|Table B]], Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

::[[File:Record Structure (File Architecture).jpg]]

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

=== Extension Pointer ===

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with an extension record pointer.

For files without a Table X, this pointer is 3 bytes in length.

For files with [[Table X (File Architecture)|Table X]] enables, this pointer is 4 bytes in length (to handle the larger number of slots in Table X).

Regardless of the length, this pointer links this portion of the record to its next portion. Where that location is, of course, dependent on whether Table X is enabled.

=== Data ===

If there are any preallocated fields in a file (see the [[|Field Design (File Management)#Preallocated fields|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File Architecture) Record Map|the Record Map in Table D]].

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were [[ADD statement|ADD]]ed (which always adds the entity at the end of the record); or positioned by an [[INSERT statement]]. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

==== [[Field Design (File Management)#Preallocated Fields|Preallocated Fields]] ====

All records stored in a Model204 file will contain all of the preallocated fields (if any) for that file. These are stored based on the [[Table D (File Architecture)#Record Map of Preallocated Fields|Record Map of preallocated fields]] stored in Table D.

==== [[Field Value Pairs (File Architecture)|Field Value Pairs]] ====

Field Value Pairs, or, perhaps more precisely, ''Field Name 'Equals' Value Pairs'' are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

==== [[Repeating Field Group (File Architecture)|Repeating Field Groups]] (RFGs)====

Permits sets of data to be managed together. Inside of the RFG is a series of field value pairs (as above) but these fields are not independent of each other.

==== Large Objects ====

There are two ways that large objects (data longer than 255 bytes) may be handled in a Model 204 record.

===== [[Table E (File Architecture)|Native Large Objects in Table E]] =====

Large objects stored as part of a record, contain a pointer locally (within the record) to the starting point of the Large Object in Table E.

Starting in Model 204 V7R5, the handling and functionality of Large Objects can (by using the [[FILEORG parameter|FILEORG]] x'100' bit) be done rather differently. See [[Table E (File Architecture)|Table E]] for the full discussion.

===== Large Objects Without Table E =====

If [[Table E (File Architecture)|Table E]] is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code. 

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes.

The application would need to parse the input data into 255 byte chunks to store it, and then again, string it together to read it.

Rocket Software recommends that, where large objects need to be stored that, for efficiency reasons, Tabel E be enables.

[[Category:File architecture]]

Adding records (File architecture)

2013-05-14T22:24:43Z

Rob: /* Adding a record to a file */

==Adding a record to a file==
This section describes the process to add a record to a Model 204 file. It presumes that the fikle has already been [[CREATE command: File|CREATE]]d and [[INITIALIZE command|INITIALIZE]]d, and that all fields and Repeating Field Groups (RFGs) needed in this action are defined to the file. 
And a reminder: while fields and RFGs may, generally, be added to the file at any time, some field attributes (for example, the pre-allocation of fields with the OCCURS attribute), may only be added in a file to which no data has yet been added.

The addition of the record is driven by the User Language [[Data Maintenance#STORE RECORD statement|STORE RECORD statement]] with an (optional) list of ''fieldname'' value pairs, as in the following example. 

STREC: STORE RECORD
NAME=RASPUTIN
SEX=MALE
OCCUPATION=MONK
END STORE

Alternatively, you can use the Host Language Interface IFBREC, IFPUT, and IFSTORE functions, which also require a list of name = value pairs.
All referenced field names must previously have been defined, but not all field names need to have assigned values in every record. In fact, if you omit a field, the field is not stored in the record at all, thus saving space in the file.
For more information see the Rocket <var class="product">Model 204</var> User Language Manual or the Rocket <var class="product">Model 204</var> Host Language Interface Reference Manual.

==How Model 204 adds records to a file==
The process of adding a new record to a file, <var class="product">Model 204</var> is as follows:
#Like all User Language code, the process consists of two parts; first the code is compiled:
##all field names, the values of coded fields and some FRV fields are converted into fixed-length codes from Table A
##all other attributes of the referenced fields are noted for use during the execution
#Presuming the code compiles, in the evaluation process, when the STORE RECORD statement is executed:
##a physical internal record number (IRN) is assigned in Table B taking the [[BRESERVE parameter]] into account
##if there are any preallocated fields, the fields in the [[#Table D (File Architecture) Record Map|record map]] are added to the record
##then, for each field value pair in the STORE RECORD statement (none are required, an 'empty' record can be created if no fields are referenced):
###the field value pair is added to the record (or preallocated field updated)
###of course, normal extension record rules apply (as discussed in [[Table B (File Architecture)|Table B]])
###if the field is indexed, the necessary updates occur to Tables C and D.

==Considerations when adding many records to a file==
If you are adding a large number of records to a file, consider these alternatives for increased efficiency: 
<ul>
<li>Deferred updates. Defer changes or additions that update Tables C and D, instead specifying that step 3 above be performed in separate phases. [[ Deferred Update Feature#Deferred Update Feature|Deferred Update Feature]] describes how to use deferred updates.</li>
<li>File Load utility. If the raw data for the records to be stored in the <var class="product">Model 204</var> file already exists in a machine-readable format (magnetic tape, direct-access storage, cards), use the File Load utility to load that data directly into the <var class="product">Model 204</var> file quickly and economically. [[ File Load Utility#File Load Utility|File Load Utility]] describes the File Load utility.</li>
</ul>
 
[[Category:File architecture]]

Record design

2013-05-13T00:19:36Z

Rob:

==Overview==

Because of the unique nature of Model 204 Records (see [[Record (File Architecture)|Record architecture]]), the translation of a logical design into Model 204 records often includes a great deal of logically related data being included in a single physical record. 

For example, if you consider a billing system, where you might consider having separate records for an invoice, and then additional records for each of the invoice lines, for a Model 204 perspective it is more likely that you would have a single record where the invoice lines simply repeat (either as a set of individually managed fields, or as a formal [[Repeating Field Group (File Architecture)|Repeating Field Group]] (RFG).

There are a number of reasons why this approach suits Model 204:

* Because a single read of the record makes all of the information available (think of the data as being pre-joined) performance should be better
* the factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204.

The most important thing, regardless of whether you are implementing a design in Model 204 or any platform, is to understand the data relationships.

==The importance of a good logical design==

If you have a good logical design, the record structure should almost jump out at the file manager: tying data which is logically connected can be efficiently, physically, tied together.

Perhaps this should be thought of in reverse: if you do not have a good logical design, it is unlikely that you will be able to implement a system which performs well and achieves its objectives.

==A unique record key?==

Unlike many systems, Model 204 will support records without a unique record key.

But, while it supports it, it is often not a good idea. Perhaps you need to provide reports off of the data, or extract data to feed other systems. You are likely to find that such downstream processes '''will''' require uniqueness.

Consider, in such cases, of using an [[Field Design (File Management)|automatic field]] such as the CREATE-TIME to make sure that all records contain a unique key.

[[Category:File management]]

Table B (File architecture)

2013-05-13T00:08:19Z

Rob:

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 (File Architecture)|Table X]] is not enabled it also contains all extension records. If [[Table E (File Architecture)|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 ==

::[[File:Table B Basic Structure (File Architecture).jpg]]

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 parameter|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 parameter|FILEORG]] x'100') files, with [[RECRDOPT parameter|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.

<div id="Internal Record Number"></div>
'''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 parameter|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 (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]]).

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 [[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 best use of Model 204 Records.

=== <div id="Table B (File Architecture) Segments">Table B Segments</div> ===

==== Definition ====

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

==== 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 [[Managing File and Table Sizes#The MAXINCBP parameter|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 (File Architecture)#Segment Entries |Table C Segment Entries]] for the effect of segments in the hash index.

* See [[#Table D (File Architecture)#B-Tree index structure|B-Tree index structure]] for the effect of segments in the ordered index.

* See [[#Table D (File Architecture)#Bit Maps Used In Indexing|bit maps used in indexing]] for how segments relate to the detailed level of both types of indexes.

=== <div id="Table B (File Architecture) The Reuse Queue">The Reuse Queue</div>===

For Reuse Record Number (RRN) files ([[FILEORG parameter|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 parameter|BHIGHPG]].

==The following Parameters relate to the Use of Table B==

This table excludes the parameters used for [[Hash Key Files|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 [[#Resizing Tables (File Management) Automatic Increases|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.
|-

|}

[[Category:File architecture]]

File reorganization and table compaction

2013-05-12T23:03:14Z

Rob: /* Dynamic data compactor for Table E */

==Overview==
In the life of a database, certain conditions can arise that make reorganizing a <var class="product">Model 204</var> file either necessary or desirable. This chapter summarizes the criteria that normally make reorganization worthwhile and the techniques to accomplish the reorganization. 
But not every situation requires a reorganization.
Changes in data structures often can be handled by simply adding, deleting, or changing fields in a file, and you can thus avoid a complete file reorganization. Refer to the discussion of the DEFINE, REDEFINE, RENAME, and DELETE commands in [[ Defining Fields Manually#Defining Fields Manually|Defining Fields Manually]] for information about manipulating fields.
Resizing of Tables B, D E and X can often be done as discussed in [[Resizing Tables (File Management)|Resizing Tables]]

Beyond this, the available tools are:

=== Reorganization and Compaction Tools ===

<table>
<caption>File Reorganization Tools</caption>
<tr class="head">
<th>Tool</th>
<th>Description</th>
<th>For more information, see ...</th>
</tr>
<tr>
<td>Fast/Unload and Fast/Reload</td>
<td>Products available to speedily reorganize even the largest Model 204 files. In addition, some of the limitations in other reorganization methods (invisible fields, procedures and Large Objects for example) are handled seamlessly</td>
<td>
These describe the products in detail:
[http://www.sirius-software.com/maint/download/funr.pdf Fast/Unload]
[http://www.sirius-software.com/maint/download/frelr.pdf Fast/Reload]
<td>
</tr>
<tr>
<td>Fixed or variable unload and reload</td>
<td>Requires the data to be unloaded into a structure and then reloaded</td>
<td>
[[#Techniques for reorganization|Techniques]]
<td>
</tr>
<tr>
<td>[[REORGANIZE command|REORGANIZE OI]]:Reorganizing just the Ordered Index</td>
<td>Improve the file's performance by cleansing the ordered index</td>
<td>
[[#Reorganizing the Ordered Index|Reorganizing the Ordered Index]]
<td>
</tr>
<tr>
<td>[[COMPACTB command|Compact]]ing Tables B and X</td>
<td>Combines extension records to improve performance. Optionally cleans up logically deleted records</td>
<td>
[[#Dynamic data compactor for Table B|Dynamic data compactor for Table B]]
<td>
</tr>
<tr>
<td>[[COMPACTE command|Compact]]ing Table E</td>
<td>For files without the [[Table E non x'100' (File Architecture)|FILEORG x'100'bit]] set, defragments TABLEE to create larger contiguous areas of free pages</td>
<td>
[[#Dynamic data compactor for Table E|Dynamic data compactor for Table E]]
<td>
</tr>
</table>

=== Limitations ===

====Reorganizing Dictionary/204 files====
For information about reorganizing <var class="product">Model 204</var> Dictionary/204 files see the Rocket <var class="product">Model 204</var> installation guide for your operating system.
====CCA system files must not be reorganized====
With the exception of CCASYS (which internally is a standard Model 204 file), never reorganize or otherwise modify CCA proprietary (identified by their 'CCA' prefix) files or procedures unless specifically instructed to do so by Technical Support.

==Criteria for reorganization==
A number of different conditions call for file reorganization including:
<ul>
<li>Expanding the size of Table A and Table C for a file before the tables become full </li>
<li>Improving <var class="product">Model 204</var> performance by:</li>
<li>::rebuilding the indices</li>
<li>::moving records around so that records read together are likely on the same page</li>
<li>::resetting file parameters</li>
<li>::resucing extension chains</li>
<li>Recovering space that has been rendered unusable</li>
</ul>
To a very large extent, deciding on which (and when) files to reorganize are dependent upon how the files are updated: how often records are added and deleted; and how often data is added to (or deleted from) records. Or, changes are required which involve parameters that cannot be adjusted dynamically. Some of these conditions are described in the following sections.
===Avoiding table full conditions===
Normally, file growth most directly affects Table B, D, E and X, all of which can be modified dynamically with the [[INCREASE command]] without necessitating a reorganization; see [[Resizing Tables (File Management)]]. However, Table A and Table C cannot be adjusted dynamically. New distinct KEY field values that previously have not occurred in the file require, and data growth which start new segments in Table B, both will cause additional entries in Table C. New field definitions, FRV and/or CODED field values require Table A space. 
Additional requirements can often be anticipated and included in the Table A and Table C allocations (or, you can convert any KEY fields to ORDered to avoid Table C issues entirely). Table A usually is very small relative to the entire file, and Table C often is considerably smaller than either Tables B, D, E or X. But, in other situations, these tables might need to be expanded during file reorganization. 
Monitoring Table A and Table C
To avoid filling Table A or Table C, regularly monitor table page retries (ARETRIES and CRETRIES, respectively)-more often in highly volatile databases. If the number of page retries shows a noticeable increase from one run to another, the file might be approaching a table full condition and might require reorganization. The TABLEC command monitors the use of Table C.
Monitoring Hash Key files
The special <var class="product">Model 204</var> file organization that uses hashed access to Table B (see [[ Hash Key Files#Hash Key Files|Hash Key Files]]) does not allow dynamic expansion of Table B. Monitoring the SPILLADD, the number of spills, and BHIGHPG, the number of full pages, parameters helps to anticipate the need to reorganize hashed files. 
===Improving performance: Data===
When a file is created, certain file parameters are set, which affect the utilization of the tables. Some of these parameters cannot be reset and the file might need to be reorganized to reflect changes in file characteristics. If the file is not reorganized when file characteristics change, system performance might be affected.
Avoiding extension records
For example, if new fields are added to records in a file, <var class="product">Model 204</var> might create extension records. If the number of extension records increases (check the EXTNADD parameter), consider reorganizing the file to turn [[Table X (File Architecture)|Table X]] on or adjust parameters such as [[BRECPPG parameter|BRECPPG]] and [[BRESERVE parameter|BRESERVE]]. Use the [[TABLEB command]] (or its [[TABLEBX command|TABLEBX]] variation) to determine which parameters need adjusting.
Note
Increasing the amount of reserve space per page (BRESERVE) without reorganizing the file affects only new Table B pages. 
Combining extension records
Another way to reduce extension records and improve performance without a file reorganization is to run the data compactor, described in [[#Dynamic data compactor for Table B|Dynamic data compactor for Table B]]. 
Aggressive use of the [[COMPACTB command]] should mean that you rarely need to reorganize a file due to extension records. 
Reducing the number of extension records
Reorganizing a file will result in the lowest possible number of extension records (based on your parameter settings) as possible. For files which do not have Table X enabled, often you would adjust the [[BRECPPG parameter]] to decrease the number of extensions. Care must be taken that you do not decrease it too far as this can cause space wastage on pages that are mostly extensions and cause an increase of Table B usage. By enabling Table X, extension record management is far more straight forward./p>
Reorganizing sorted files
<var class="product">Model 204</var> sorted files also might need to be reorganized. File parameters, such as BPGPMSTR, BPGPOVFL, and BEXTOVFL, might not reflect current requirements. The result is added overflow records or spill between overflow areas. A discernible increase in OVLFADD or SPILLADD might indicate that a sorted file needs to be reorganized. In the extreme case, if you do not reorganize the file, new records cannot be stored. 
===Improving performance: Indexing===
The Model 204 file indexes all tie to the internal record number (IRN) of the record. If you have a file which has a high volume of additions and deletions, over time both the hash key index (Table C) and the B-Tree (in Table D) will grow. In both cases, a full reorganization of the file will rebuild the indexes and improve performance. See also [[#Reorganizing the Ordered Index|Reorganizing the Ordered Index]] for a way to rebuild the B-Tree.
===Recovering unusable space===
In an entry order file, deleted space in Table B is reused only for the expansion of existing records on that page. 
Avoiding unusable space problems
Highly volatile files might require reorganization to recover the record numbers from deleted records. Such files use space more efficiently if they are unordered with the reuse record number option.
==Techniques for reorganization==
To reorganize a <var class="product">Model 204</var> file, copy the records from Table B and the procedures from Table D onto sequential data sets and reload from those data sets. This section discusses techniques for copying records and procedures onto sequential data sets, and how to rebuild the access control table (ACT).
To reorganize a file, follow these steps:
<ol>
<li>Copy the records from Table B into one or more sequential data sets. (See [[#Copying records|Copying records]].)</li>
<li>Copy the procedures into a sequential data set. (See [[#Copying procedures|Copying procedures]] and [[#Reloading a small number of procedures|Reloading a small number of procedures]].)</li>
<li>Re-create and initialize the file, making the desired changes to space allocation, file parameters, and field definitions. If no space parameter changes are needed, initialize the file and define the fields.</li>
<li>Reload the file from the sequential data sets in step 1.</li>
<li>Re-enter the SECURE commands needed to rebuild the Access Control Table (ACT).</li>
<li>Re-create the procedures from the sequential data set in step 2. (See [[#Reloading a small number of procedures|Reloading a small number of procedures]].) </li>
</ol>
Note
You cannot use the file backup utility (DUMP and RESTORE) described in [[ File Dumping and Restoring#File Dumping and Restoring|File Dumping and Restoring]] to reorganize files. However, you can use RESTORE with the 128 option to defragment Table B and D space that was added with the INCREASE command.
===Copying records===
If the file was updated after its creation, you must retrieve all the records in Table B and copy their fields into a sequential data set. 
If the file was originally created from a sequential data set and not subsequently updated, you can rerun the file load with the same data set. This is, however, an unlikely circumstance, because static files rarely need reorganizing.
INVISIBLE fields
INVISIBLE fields are handled differently; see the description of recreating INVISIBLE fields on [[#Reorganizing INVISIBLE fields|Reorganizing INVISIBLE fields]]. 
===Copying and reloading examples===
The following examples demonstrate User Language techniques for copying and reloading records in a <var class="product">Model 204</var> file. These techniques use User Language, the directed output feature (USE command) and the File Load utility. The Host Language Interface can replace the User Language portions, if desired, although User Language is usually more efficient. 
===Copying into a fixed-format file===
The most efficient method for reorganizing most files is to create a fixed-format sequential file and a corresponding file load program based on that format. 
For example, assume that you have a PEOPLE file that contains records consisting of three fields:
Field Name Maximum Length Field Type

NAME 20 KEY
AGE 3 KEY,NR
SEX 6 KEY,COD,FV

The following z/OS request produces a sequential data set named COPY in which each fixed-length record contains the NAME, AGE, and SEX fields from one record in the PEOPLE file. 
Set the UDDLPP parameter to zero before running the request to suppress page headers. Set UDDCCC to zero or to at least one greater than the output record length. You might also need to reset the length of the LOBUFF parameter in the PARM field of the EXEC statement. 
Copying files
For step 1 of [[#Techniques for reorganization|Techniques for reorganization]], run these commands and this User Language request:
<var>OPEN PEOPLE
RESET UDDLPP = 0,UDDCCC = 0
USE OUTTAPE
</var>BEGIN
ALL: FIND ALL RECORDS
END FIND
PRINT.LOOP: FOR EACH RECORD IN ALL
PRINT NAME WITH AGE AT COLUMN 21 -
WITH SEX AT COLUMN 24
END FOR
END

DCB and FILEDEF information
OUTTAPE is the name of the following DD statement in the JCL of the batch or Online job in z/OS:
//OUTTAPE DD DSN=COPY,DISP=(KEEP),UNIT=TAPE,
// DCB=(RECFM=FB,LRECL=29,BLKSIZE=1450)

The same process in z/VM is as follows:
FILEDEF OUTTAPE TAP1 SL (BLOCK 1450 LRECL 29 RECFM FB
LABELDEF OUTTAPE VOLID 123456

Reloading files
For step 4 of [[#Techniques for reorganization|Techniques for reorganization]], reloading the file, COPY becomes input to the File Load run:
CREATE FILE PEOPLE
parameters File parameters that may reflect
. required changes
.
.
END
OPEN PEOPLE
INITIALIZE
DEFINE FIELD NAME WITH KEY
DEFINE FIELD AGE WITH KEY RANGE
DEFINE FIELD SEX WITH KEY CODED FEW-VALUED
FLOD -1,-1,0
NAME=1,20,X'8000'
AGE=21,3
SEX=24,6
END

===Using PAI FLOD for files with varying record formats===
If your files contain different record types and varying record formats, you might want to have a general utility program to reorganize a <var class="product">Model 204</var> file. 
Copying files
The PERSONEL file has many field names and several types of records. For step 1 of [[#Techniques for reorganization|Techniques for reorganization]], use the following commands and User Language request:
OPEN PERSONEL
RESET UDDLPP = 0,UDDCCC = 0
USE OUTTAPE
BEGIN
ALL: FIND ALL RECORDS
END FIND
PRINT.LOOP: FOR EACH RECORD IN ALL
PRINT '*'
PRINT ALL INFORMATION
END FOR
END

DCB information
OUTTAPE is the name of the DD statement in the JCL of the job:
//OUTTAPE DD DSN=COPY,DISP=(,KEEP),UNIT=TAPE,
// DCB=(RECFM=VB,LRECL=260,
// BLKSIZE=1000)

COPY sequential data set
The previous request produces a sequential data set named COPY in which each variable-length record is either an asterisk or one field of one record in the PERSONEL file. [[#Using PAI FLOD for files with varying record formats|Using PAI FLOD for files with varying record formats]] illustrates the format of these sequential records. 
<table>
<caption>Step 1 Sequential Record Layout</caption>
<tr class="head">
<th> Column </th>
<th align="right"> 1 </th>
<th align="right">2 </th>
<th align="right">3 </th>
<th align="right">4 </th>
<th align="right">5 </th>
<th align="right">6 </th>
<th align="right">7 </th>
<th align="right">8 </th>
<th>... </th>
</tr>
<tr>
<td> </td>
<td colspan="2">Length </td>
<td colspan="2">Reserved </td>
<td colspan="5">Field name=value</td>
</tr>
</table>
Parameter settings for the sequential data set
The field name begins in column 5 and spaces are required before and after the equal sign. If the field name=value portion of any line exceeds the value of the LOBUFF parameter, reset LOBUFF in the EXEC statement, and set LRECL in the OUTTAPE DD statement to LOBUFF plus 4. 
The default values of 1,000,000 for the MUDD, MOUT, and MDKRD parameters might need to be adjusted upward for PAI dumps on large files.
Reloading files using the File Load utility
For step 4 of [[#Techniques for reorganization|Techniques for reorganization]], the COPY data set is input to a file load program that uses the D statement; see the description of the File Load utility. The following sequence reloads the records from COPY.
CREATE FILE PERSONEL
parameters
.
.
.
END
OPEN PERSONEL
INITIALIZE
DEFINE fields Field definitions that may reflect
. required changes.
.
.
FLOD -1,-1,0
#21 Top of loop
G Get record from TAPEI

=24,5,* Asterisk; go to start new record
I 13,,,0 Initialize to zero
#22 Top of equal sign search loop
=23,6|13,= Equal sign; go to compute value length
I 13,,,1|13 Increment field name length
=22 Continue search for equal sign
#23 Equal sign found
I 14,1,2,-7,-1|13 Compute proper value length
=25,4|15*Y Flag set to Y; go to store first field
D 5,0|13=8|13,0|14 Store field (other than first) in record
=21 Go to top of loop
#24 New record starting
I 15,,,232 Set flag to decimal value of EBCDIC Y
=21 Go to top of loop
#25 Storing first field
D 5,0|13=8|13,0|14,X'8000' Set mode bit to begin a new record
I 15 Reset flag register
END
EOJ

The line after label 24 starts a new record. With minor modifications to this generalized file load program you can reorganize different <var class="product">Model 204</var> files.
===Reorganizing or loading a file that contains Large Objects===
A <var class="product">Model 204</var> file that contains Large Object data can be reorganized as described in [[#Using PAI FLOD for files with varying record formats|Using PAI FLOD for files with varying record formats]], which uses the User Language PAI (PRINT ALL INFORMATION) statement to unload the data from a file, and a standard FLOD program to reload the data. 
<table>
<tr class="head">
<th>PAI statement for... </th>
<th>Output is formatted as...</th>
</tr>
<tr>
<td>Non-LOB field </td>
<td>
FILELDNAME=FIELDVALUE
</td>
</tr>
<tr>
<td>LOB field </td>
<td>
FIELDNAME=DESCRIPTOR
LOB data line 1
LOB data line 2
...
LOB data line n
</td>
</tr>
</table>
For a LOB field, the data value is replaced by a LOB descriptor, which contains information such as the LOB length and RESERVE value. The LOB descriptor contains unprintable characters. The actual LOB value then follows on subsequent records; as many as are required to hold the LOB value-depending on the OUTMRL of the output data set to which the PAI output is directed.
When a FLOD runs a statement to load a field value, it checks whether the field is a LOB, and if so processing assumes that the data is formatted as illustrated in the previous table-namely, the FIELDVALUE is actually a descriptor-and loads it accordingly.
The descriptor format is normally of no concern to the file manager or FLOD programmer, as the descriptor is built by the PAI statement that unloaded the data. 
If you need to build the LOB descriptor yourself, for example, for an initial load of a file that contains Large Object data, see "Building a Large Object descriptor".
==Reorganizing sorted and hash key files==
For sorted or hash key files, you need to modify the generalized file load program shown in [[#Using PAI FLOD for files with varying record formats|Using PAI FLOD for files with varying record formats]]. Load the sort or hash key by the file load statement that starts a new record. Consider the following factors: 
<ul>
<li>Key may or may not be the first field printed by the PAI request.</li>
<li>Key may or may not appear in every record.</li>
<li>Length of the key value may or may not be the same in every record. </li>
</ul>
These factors are discussed in the following sections, followed by examples of the PAI FLOD reorganization method illustrating different combinations of sort or hash key characteristics.
Note
Reorganizing hash key files with the PAI FLOD method requires twice as much Table B I/O as for other types of files. Hash key files might require significantly more time if you do not use the M204HASH utility to presort the TAPEI input date to FLOD or FILELOAD. For more information on the M204HASH utility, see [[ Hash Key Files#Hash Key Files|Hash Key Files]]. 
===Modifying the PAI request for preallocated fields===
When the sort or hash key is a preallocated field, or when a file contains no preallocated fields, the key appears first in the PAI output. 
When preallocated fields are used but the sort or hash key is not one of the preallocated fields, you need to modify the PAI request to print the sort or hash key value first for each record. 
In addition, you need to modify the file load program to load the sort or hash key as the first field and skip the second occurrence that results from the PAI statement. 
Example
In the following example, the sort or hash key field position is unknown, the sort or hash key field is required in every record, the sort or hash key field value length is constant, and the sort or hash key field is not necessarily the first field printed by the PAI request. The following assumptions are made:
<ul>
<li>Sort or hash key is a field called FILEKEY.</li>
<li>FILEKEY appears in every record (FILEORG X'02' bit is on).</li>
<li>FILEKEY might not be the first field printed by the PAI request. (There are preallocated fields in the file, but FILEKEY is not one of them.)</li>
<li>Value of FILEKEY always has a length of 8.</li>
<li>No other fields in the file have names beginning with the character string "FILEKEY " (FILEKEY followed by a blank), which would be skipped by the CASE statement. </li>
</ul>
The data in the file is dumped to a sequential data set called OUTTAPE with the same DCB attributes as described on [[#Using PAI FLOD for files with varying record formats|Using PAI FLOD for files with varying record formats]]. The procedure used to dump the data is:
OPEN <var class="term">filename
</var>RESET UDDLPP=0,UDDCCC=0
USE OUTTAPE
BEGIN
ALL: FIND ALL RECORDS
END FIND
PRINT.LOOP: FOR EACH RECORD IN ALL
PRINT '*'
PRINT FILEKEY
PRINT ALL INFORMATION
END FOR
END

The following FILELOAD program loads the data from OUTTAPE:
FLOD -1,-1,0
#21
G
=24,5,* Asterisk; go to start new record.
CASE 5,8 Skip loading second occurrence of
FILEKEY=21 FILEKEY produced by
ENDCASE PRINT ALL INFORMATION statement.
I 13,,,0 Initialize counter to 0.
#22
=23,6|13,= Look for = starting in col. 6.
I 13,,,1|13 Increment field name length.
=22 Continue search for equal sign.
#23 Come here when equal sign found.
I 14,1,2,-7,-1|13 Compute length of value.
D 5,0|13=8|13,0|14 Store field in record.
=21
#24 Come here when asterisk found.
G Get next record - contains FILEKEY.
FILEKEY=5,8,X'8000' Begin new record.
END

===Modifying the PAI request for files in which the sort or hash key is not required===
For a sorted or hash key file in which the sort or hash key is not required in every record, modify the file load program to determine whether the sort or hash key exists. If it does not exist, load the first field with mode bits of X'A000'. In the following example, the sort or hash key might not be in every record.
For a sort or hash key file in which the key value is variable in length, compute the value length. The same statements that are used to compute the length of the values of other fields can be used to compute the length of the value of the sort or hash key. In the following example, the key value length is variable.
The following sort or hash key file reorganization examples use a slight modification of the PAI FLOD reorganization method described on [[#Using PAI FLOD for files with varying record formats|Using PAI FLOD for files with varying record formats]]. They apply to either sorted or hash key files.
Sort or hash key not required, PAI sample request
In the following example, the sort or hash key field position is known, the sort or hash key field is not required in every record, and the sort or hash key field value length is variable. Specifically, the following assumptions are made:
<ul>
<li>Sort or hash key is a field called FILEKEY.</li>
<li>FILEKEY might not appear in every record (FILEORG X'02' bit is off).</li>
<li>FILEKEY is always the first field printed by the PAI request.</li>
<li>Length of the value of FILEKEY is variable.</li>
<li>No other fields in the file have names beginning with the character string "FILEKEY " (FILEKEY followed by a blank). </li>
</ul>
The data in the file is dumped to a sequential data set (called OUTTAPE) with the same DCB attributes described on [[#Using PAI FLOD for files with varying record formats|Using PAI FLOD for files with varying record formats]]. The procedure used to dump the data is:
OPEN filename
RESET UDDLPP=0,UDDCCC=0
USE OUTTAPE
BEGIN
ALL: FIND ALL RECORDS
END FIND
PRINT.LOOP: FOR EACH RECORD IN ALL
PRINT '*'
PRINT ALL INFORMATION
END FOR
END

The following FILELOAD program loads the data from OUTTAPE:
FLOD -1,-1,0
I 2,,,1 Constant value 1 for comparison.
#21
G
=24,5,* Asterisk; turn on start-new-rec flag.
I 13,,,0 Initialize counter to 0.
#22
=23,6|13,= Look for = starting in col. 6.
I 13,,,1|13 Increment field name length.
=22 Continue search for equal sign.
#23 Come here when equal sign found.
I 14,1,2,-7,-1|13 Compute length of value.
T 25,1|1*4,1|2*8 Go to 25 if start-new-rec flag is on.
D 5,0|13=8|13,0|14 Else, load field into rec.
=21 Go get next field.
#25 Here when start-new-rec flag is on.
CASE 5,8 Use different mode bits when
FILEKEY =26 FILEKEY exists in
ENDCASE current record.
D 5,0|13=8|13,0|14,X'A000' No FILEKEY; use X'A000'
I 1,,,0 Turn off start-new-rec flag.
=21 Go get next field.
#26 Come here when FILEKEY exists in rec.
FILEKEY=15,0|14,X'8000' Load FILEKEY.
I 1,,,0 Turn off start-new-rec flag.
=21 Go get next field.
#24 Come here when asterisk found.
I 1,,,1 Turn on start-new-rec flag.
END

==Reorganizing INVISIBLE fields==
If your site has any records with INVISIBLE fields, you need to build provisions into step 1 (from [[#Techniques for reorganization|Techniques for reorganization]]) of either method to reorganize the files that have INVISIBLE fields. INVISIBLE fields do not occupy space in Table B and must be re-created by other means. 
===Reorganizing INVISIBLE FRV fields===
For example, if the PERSONEL file has an INVISIBLE FRV field called TYPE, which implies the record type, modify the PAI FLOD request as follows: 
BEGIN
TYPE: FOR EACH VALUE OF TYPE
TYPE.VAL: FIND ALL RECORDS FOR WHICH
TYPE = VALUE IN TYPE
END FIND
FOR EACH RECORD IN TYPE.VAL
PRINT '*'
PRINT 'TYPE = ' WITH VALUE IN TYPE
PRINT ALL INFORMATION
END FOR
END FOR
END

This request assumes that there is only one occurrence of TYPE for each record, and that each record has a TYPE value.
===Reorganizing INVISIBLE NON-FRV fields===
INVISIBLE fields that are NON-FRV must be derived by other means. Many INVISIBLE fields can be created from another VISIBLE field in the record. For example, an INVISIBLE KEY field LAST NAME can be carried in the same record as the VISIBLE field NAME. Use the $SUBSTR and $INDEX functions to extract the value for LAST NAME from NAME. This value can then be included in the fixed format record or the PAI reorganization. 
Fixed-format dump example
For example, for a fixed-format dump:
BEGIN
ALL: FIND ALL RECORDS
END FIND
PROCESS.LP: FOR EACH RECORD IN ALL
%LN = $SUBSTR(NAME,$INDEX(NAME,' ')+1)
PRINT NAME WITH AGE AT COLUMN 21 -
WITH SEX AT COLUMN 24 -
WITH %LN AT COLUMN 30
END FOR
END

PAI FLOD example
For a PAI FLOD:
BEGIN
ALL: FIND ALL RECORDS
END FIND
PROCESS.LP: FOR EACH RECORD IN ALL
%LN = $SUBSTR(NAME,$INDEX(NAME,' ')+1)
PRINT '*'
PRINT ALL INFORMATION
PRINT 'LAST NAME = ' WITH %LN
END FOR
END

Step 4 can load the field LAST NAME in the same manner in which the other fields are loaded. Although the value is part of the records in the sequential data set, it is not stored in Table B if the field description established in a DEFINE command indicates it is INVISIBLE.
Take care in the file design process to evaluate reorganization requirements and anticipate which technique, if necessary at all, is most suitable.
==Copying procedures==
Before reorganizing any file that contains procedures, dump the procedures from the file to a sequential data set as follows:
RESET UDDLPP=0,UDDCCC=80
USE OUTPROCS
OPEN FILEX
DISPLAY (ALIAS,LABEL) ALL

DCB information
OUTPROCS is the name of the following DD statement in the JCL of the <var class="product">Model 204</var> job:
//OUTPROCS DD DSN=PROCS,DISP=(,KEEP),
// DCB=(LRECL=80,BLKSIZE=80,RECFM=F,),...

or, an alternate:
//OUTPROCS DD DSN=PROCS,DISP=(,KEEP),
// DCB=(LRECL=80,BLKSIZE=n*80,RECFM=FB,),...

A data set concatenated to a DD* data set line //CAIN DD * must be compatible with the DCB of the DD* data set which is DCB=(LRECL=80,BLKSIZE=N*80, RECFM=F OR FB). A tape or disk data set can be used.
===Copying secured procedures===
If procedure security is in effect, make sure that the user issuing the DISPLAY command has the authority to display all procedures (DISPLAY ALL command) to avoid losing any secured procedures.
===Reloading procedures===
After the file has been reloaded, reload the procedures by running a batch job that has the PROCS data set as part of the concatenated input stream:
<ul>
<li>Be sure to include the *LOWER command after the OPEN if the procedures contain uppercase and lowercase characters.</li>
<li>If any procedure line exceeds 72 characters, include (in the EXEC statement) settings of INMRL and INCCC large enough to accommodate the longest line. </li>
</ul>
For example:
//CCAIN DD *
PAGESZ=6184
OPEN FILEX
password
/*
// DD DSN=PROCS,DISP=OLD,...
// DD *
EOJ
/*

===Reloading a small number of procedures===
If you are reloading a small number of procedures that do not have aliases, it may be easier to copy the procedures to another <var class="product">Model 204</var> file, and then copy them back. Using this method of copying procedures causes any aliases to be removed when the file is initialized (step 3 of [[#Techniques for reorganization|Techniques for reorganization]]).
For example, the PEOPLE file, which contains five procedures, needs to be reorganized. The JUNK file is a file with no procedures in it, created for this purpose. To perform step 2 of [[#Techniques for reorganization|Techniques for reorganization]], open the PEOPLE and JUNK files, and issue the command:
<var>IN PEOPLE COPY PROCEDURE ALL TO JUNK</var>

Step 6 is then the reverse command:
<var>IN JUNK COPY PROCEDURE ALL TO PEOPLE</var>

For more information on the COPY PROCEDURE command, refer to the <var class="product">Model 204</var> Parameter and Command Reference.
z/VSE example
z/VSE does not allow data set concatenation. However, with z/VSE/POWER using the * $$ PUN statement and the USE data set facility, you can create a job to reload procedures:
* $$ PUN DISP=I,CLASS=I
.
.
DEFINE DATASET OUTPROCS WITH SCOPE=SYSTEM -
FILENAME=SYSPCH LRECL=80 RECFM=F
RESET UDDLPP=0,UDDCCC=80
USE OUTPROCS
BEGIN
PRINT '// JOB LOAD PROCEDURES'
PRINT '// OPTION SYSPARM=''INCCC=80'''
. Print out JCL and user zero input
. to precede displayed procedures.
END
USE OUTPROCS
DISPLAY (ALIAS,LABEL) ALL
USE OUTPROCS
BEGIN
PRINT 'EOJ'
PRINT '/*'
PRINT '/&'
END
.
.

z/VM example
To dump procedures to a z/VM disk file, execute the following command:
<var>ONLINE BYPASS UNLDPROC</var>

where:
<var>UNLDPROC EXEC </var>defines the files to be used by the ONLINE command. 
The procedures are dumped to the CMS disk file, CARS PROCFILE A.
UNLDPROC EXEC
The UNLDPROC EXEC follows:
&CONTROL OFF
FILEDEF * CLEAR
FILEDEF CCAPRINT DISK UNLDPROC CCAPRINT A
FILEDEF CCAAUDIT DISK UNLDPROC CCAAUDIT A
FILEDEF CCATEMP N DSN WORK CCATEMP
FILEDEF CCASNAP PRINTER
FILEDEF CCASTAT N DSN WORK CCASTAT
FILEDEF CARS M DSN M204DB CARS
FILEDEF OUTPROC DISK CARS PROCFILE A (RECFM FB LRECL 80 -
BLKSIZE 800
FILEDEF CCAIN DISK UNLDPROC CCAIN *
&STACK SYSOPT 128 LIBUFF 600 LOBUFF 600 INCCC 80

UNLDPROC CCAIN file
The CCAIN file, UNLDPROC CCAIN, is:
PAGESZ=6184
R UDDCCC=80,UDDLPP=0
OPEN CARS
USE OUTPROC
DISPLAY PROC(ALIAS,LABEL) ALL
EOJ

To load the procedures back into a file, execute the following command:
<var>ONLINE BYPASS LOADPROC</var>

LOADPROC EXEC
The following LOADPROC EXEC defines the files to be used by the ONLINE command:
&CONTROL OFF
FILEDEF * CLEAR
FILEDEF CCAPRINT DISK LOADPROC CCAPRINT A
FILEDEF CCAAUDIT DISK LOADPROC CCAAUDIT A
FILEDEF CCATEMP N DSN WORK CCATEMP
FILEDEF CCASNAP PRINTER
FILEDEF CARS M DSN M204DB CARS
FILEDEF CCAIN DISK LOADPROC CCAIN A
M204APND CCAIN DISK CARS PROCFILE A
M204APND CCAIN DISK EOJ CCAIN A
&STACK SYSOPT 128 LIBUFF 600 LOBUFF 600 INCCC 80

CCAIN files
The CCAIN input consists of the following files, which are concatenated using M204APND:
<ul>
<li>LOADPROC CCAIN contains commands to open the database file.</li>
<li>CARS PROCFILE is the z/VM disk file that the procedures were dumped to using UNLDPROC.</li>
<li>EOJ CCAIN contains commands to close the file and end the job.</li>
</ul>
LOADPROC CCAIN is:
PAGESZ=6184
OPEN CARS

EOJ CCAIN is:
CLOSE CARS
EOJ

===Access control table===
For a file that uses procedure security, there is no automatic way to rebuild the access control table. Display the mapping of user classes to procedure classes with the command:
<var>DISPLAY (PRIVILEGES) ALL</var>

Then reenter the privilege mappings with a new series of SECURE commands. Refer to the discussion of other DISPLAY command capabilities in [[ Field Display and Message Broadcast#Overview|Overview]], and to the discussion of the SECURE command. 
==Reorganizing the Ordered Index==
The Ordered Index can be adjusted or reorganized in whole or in part to improve its performance or its spacing requirements or both. 
You can reorganize the Ordered Index to replenish space in an Ordered Index where the deletions of B-tree entries have left many tree nodes with excessive unused space. You can also maximize the efficiency of your site's range retrievals by taking advantage of the clustering of the segment lists stored on Table D pages that results from a reorganization. 
The REORGANIZE OI command is used along with the deferred update Z command (see "Z command") to reorganize the Ordered Index. 
===Changing spacing parameters with REDEFINE===
You might want to modify the spacing parameters of one or more of the ORDERED fields in the Ordered Index in response to or in anticipation of a change in the nature of the data being stored. (For example, you might anticipate a different pattern or frequency of the updates to the Ordered Index.) 
If you need to change the spacing parameters of one or more of the ORDERED fields for future updating, use the REDEFINE command with the field(s) involved. See the discussion of ORDERED fields in "ORDERED and NON-ORDERED attributes", and the REDEFINE command discussion in [[ Defining Fields Manually#Defining field retrieval attributes|Defining field retrieval attributes]], for more information about the Ordered Index B-tree structure and alteration. 
===REORGANIZE OI command===
You can issue the REORGANIZE OI command for either the entire Ordered Index or for one specified field that has the ORDERED attribute. When you issue REORGANIZE OI:
<ul>
<li>REORGANIZE OI writes out Ordered Index deferred update records to a variable-length deferred update data set. </li>
<li>These deferred updates are applied to the file using the Z command. </li>
<li>One deferred update record is written for each record indexed in the part of the Ordered Index being reorganized. The length of the update record varies according to the length of the value that is indexed. The deferred update data set created can be very large. </li>
</ul>
For more information about variable-length deferred update data sets and applying the deferred updates using the Z command, see the deferred updates chapter. 
REORGANIZE OI format
The format for the REORGANIZE OI command is:
Syntax
REORGANIZE OI [<var class="term">fieldname</var>]

where:
fieldname is an ORDERED field. 
Privileges required
This command requires file manager privileges and exclusive control of the file. It can be used only in single user runs. Before issuing REORGANIZE, open the file in deferred update mode with a variable-length deferred update data set. See the deferred updates chapter for a description of the special form of the OPEN command used for opening a file in deferred update mode.
The REORGANIZE command deletes all the entries from the part of the Ordered Index that is being reorganized, and writes the updates to rebuild the Ordered Index into the variable-length deferred update data set. 
===Rebuilding the Ordered Index with the Z command===
To rebuild the Ordered Index, issue the Z command. If the settings of the spacing parameters LRESERVE, NRESERVE, and IMMED are changed for any field before the Z command is issued, the Ordered Index is rebuilt using the new parameter values for that field. The new parameter values result in a different space utilization. 
The data sets used by the Z command with REORGANIZE are the same as in ordinary File Load or deferred update runs:
<ul>
<li>Data set containing the Ordered Index deferred update records must be named SORT5.</li>
<li>Data set produced by the Z command is TAPE5. </li>
</ul>
The Z command clusters the Ordered Index segment lists stored on Table D list pages so that, if possible, all the lists for one or more given field name = value pairs are on the same Table D list page. This clustering dramatically improves the performance of a FIND that includes a range condition. 
==Dynamic data compactor for Table B==
The data compactor for Table B dynamically reduces the chains of extension records for unordered files. You can use the data compactor Online or in Batch.
Frequently updated files may have records with long chains of extension records spanning several pages. When a record is updated and there is not enough space on the page to store a new or changed field, <var class="product">Model 204</var> allocates an extension record on a different page. Over time, records may acquire multiple extensions on different pages. Reducing the number of extension records may improve performance, especially for scanning long records, and free the record numbers used by extension records. 
===Understanding the constraints database===
The constraints database is a dynamic hashed database that resides in a few virtual storage pages with any extra space needed residing in CCATEMP. In this database there are primary pages and overflow pages, also called extension records. When a primary page fills up, additional records go on to overflow pages that are chained from the primary page. When a primary page become too full, a process is evoked which splits the page into two pages. This process continues to the maximum-allowed number of primary pages at which point the splitting process stops and the overflow page chain is allowed to grow as large as required. 
As the constraints database contracts, this process is reversed. Those pages with only a few records are merged together or compacted. This process continues until only one page remains.
===Combining extension records===
The data compactor reduces the number of extensions by combining several extension into one. The data compactor first tries to use a page from the reuse queue for a new extension record. If no page is suitable, the compactor uses an unused page in Table B increasing the BHIGHPG parameter. The logical order of extension in a record is preserved. After writing a new extension record old ones are deleted and the space on corresponding pages may be reused. 
Depending on the length of an extension record and the parameter settings for page reuse, the data compactor may increase or decrease the reuse queue. The COMPACTB command uses the reuse queue-adding eligible pages and deleting used pages, as would any updating program. 
For example, you might see the following message that indicates that all free (unused) pages allowed for compaction have been used.
M204.2677: ALL FREE PAGES ALLOWED FOR COMPACTION HAVE BEEN USED. COMMAND COMPACTB ENDS.

<ul>
<li>If the FREE parameter of the COMPACTB command was set at 100(%), then all unused pages are gone and the file manager must increase Table B size. </li>
<li>If there are some numbers of unused pages left in Table B (the difference between BSIZE and BHIGHPG), then the file manager must increase the FREE parameter.</li>
</ul>
This is the same approach <var class="product">Model 204</var> uses when allocating a new record or a new extension: to save time for the next user and speed up the allocation. The compactor makes this process very visible, because it scans many more pages on the reuse queue and may require much more free space on a pages. 
The data compactor does not change the order of the fields within a record. See the COMPACTB command in the <var class="product">Model 204</var> Parameter and Command Reference.
Implementation of the COMPACTB command led to the implementation of the BLDREUSE command, anticipating that you might want to assure that as many pages as possible were available on the reuse queue for COMPACTB processing to use.
===Recovery processing and the data compactor===
Recovery supports the addition and deletion of extension records as a part of a record update, as well a creating journal entries for moving extension records. Journal entries 6 track moved extension records. 
===[[COMPACTB command |COMPACTB]] data compaction===
The COMPACTB process provides compacting results and improves performance. The following features are included in COMPACTB processing:
<ul>
<li>Support for files with Table X</li>
<li>A DELETE option to physically delete logically deleted records</li>
</ul>
COMPACTB processing can be used to avoid frequent file reorganizations needed to reduce the number of extension records and can also be used to reclaim space occupied by logically deleted records-some times referred to as dirty data.
Recovery of the compaction process is fully supported. 
====Improved compaction for all files====
If a Table B base record has one and only one extension record and the base record page has sufficient free space, then the data compactor will combine the extension record with the base record and delete the extension. For a base record with multiple extensions, the compactor will try to combine the extension records into fewer extensions, but will not attempt to combine them with the base record.
====Compaction for files with Table X====
COMPACTB processing supports files defined with a Table X. Compaction for files defined with Table X have better performance, because compaction operates on a page basis instead of a record basis and locks fewer resources, especially the existence bit map.
====Physical delete of logically deleted records====
A logically deleted record remains physically stored in the file. The corresponding existence bit is zero-or off-in the Existence Bit Pattern (EBP), but otherwise all fields, data, and index entries are present and consume space. The record, however, cannot be accessed because the existence bit is zero.
The data compactor can physically delete logically deleted records in files. The compactor accomplishes this by checking all records on a Table B page to verify that the EBP indicates that the record exists. For records that are physically present, but the EBP indicates that the record has been logically deleted, the compactor will delete the physical records-if requested. 
The new DELETE option of the COMPACTB command specifies that the process must physically delete logically deleted records, whether the physical records are in Table B (base and extensions) or the physical records are in Table B with extensions in Table X.
Space and record numbers freed by physically deleting logically deleted records are reusable.
You can use the DELETE option with all other options. For example:
COMPACTB FROM 15 TO 23 FREE 20 DELETE

The data compactor finds logical records with a nonzero length within the indicated record number range (in the previous example, 15 to 23) that do not exist in the EBP and deletes the data and index entries for such records. This example also releases 20% of the unused or free pages to the data compactor, which can be used for new extension records. Files with lock pending updates (LPU) disabled are processed with the data compactor placing an exclusive enqueue on the entire file. In this case, a warning message is issued. 
For files with many logically deleted records, processing the DELETE option may be CPU and I/O intensive. The following new message is printed at the completion of data compactor processing that states the total number of deleted records.
M204.2754: NUMBER OF DELETED LOGICALLY DELETED RECORDS: count

All statistical information from compaction is presented as <var class="product">Model 204</var> messages, as shown in the following COMPACTB command outputs. 
COMPACTB using the FREE option
COMPACTB FREE 85
*** M204.2749: FILE ''filename'' NUMBER OF BASIC RECORDS PROCESSED: 36000
*** M204.2750: FILE ''filename'' NUMBER OF EXTENSION RECORDS BEFORE COMPACTION: 110001
*** M204.2751: FILE ''filename'' NUMBER OF EXTENSION RECORDS AFTER COMPACTION: 35991
*** M204.2752: FILE ''filename'' NUMBER OF NOT PROCESSED (LOCKED) RECORDS: 0
*** M204.2753: FILE ''filename'' NUMBER OF FREE PAGES USED: 1026

COMPACTB using the DELETE option
COMPACTB DELETE

*** M204.2749: FILE ''filename'' NUMBER OF BASIC RECORDS PROCESSED: 35000
*** M204.2750: FILE ''filename'' NUMBER OF EXTENSION RECORDS BEFORE COMPACTION: 106952
*** M204.2751: FILE ''filename'' NUMBER OF EXTENSION RECORDS AFTER COMPACTION: 34991
*** M204.2752: FILE ''filename'' NUMBER OF NOT PROCESSED (LOCKED) RECORDS: 0
*** M204.2753: FILE ''filename'' NUMBER OF FREE PAGES USED: 755
*** M204.2754: FILE ''filename'' NUMBER OF DELETED LOGICALLY DELETED RECORDS: 1000

==Dynamic data compactor for Table E==

=== Functionality ===

For Model 204 files where [[FILEORG parameter|FILEORG]] x'100' is not set large objects are stored as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The [[COMPACTE command]] lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed.
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects.

=== Considerations for use ===
Some compactions may be counter productive. For example, if a segment has
49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a
total size of 152 pages, then moving 49,000 pages to reclaim a modest 152
page gap is inefficient. On the other hand for objects with average size of 1-100
pages, compacting a hundred 1-page gaps is beneficial.
The TABLEE command, like the TABLEB command, reports Table E usage
statistics: the number of gaps and total gap size. Because compaction is
heavily I/O and CPU intensive, you should compact Table E only when you can
expect substantial results.
For files with large Table E and really large objects (thousands of pages) you
must take care to prevent unnecessary page movements.
The compactor analyzes Table E based driven by the bitmap pages, one Table E set of 49152 pages at a time.
Table E contains not only object pages but bitmap pages also. The compactor’s implementation has the following limitations:
::Bitmap pages (allocated one per segment) are not moved, so the worst result
of compaction is two gaps per segment.
::Objects residing in more than one segment are not moved.

=== Using the TABLEE comand|TABLEE and [[COMPACTE command]]s ===
To effectively compact Table E, Rocket Software recommends running a
TABLEE command with the SEG option, identifying segments with large
number of gaps, running COMPACTE command for segments of interest, and
then running another TABLEE command for compacted segments to check the
results.

=== COMPACTE back out and recovery ===
No back out capabilities are provided for Table E compaction. To facilitate recovery, the compactor writes preimages of all a large object’s pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages.
::For error messages generated while analyzing Table E (messages 2809,2810, 2818, 2819, 2821), a file must be regenerated.
::For error messages generated while moving an object (messages 2811,2823) a normal file recovery should be adequate.

=== COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.

=== COMPACTE and checkpoints ===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long—hundreds of pages—object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.

===COMPACTE results===
COMPACTE
*** M204.2811: FILE ''filename'' NUMBER OF MOVED OBJECTS: 180
*** M204.2812: FILE ''filename'' NUMBER OF MOVED PAGES: 12
*** M204.2813: FILE ''fielname'' NUMBER OF RECORD LOCKING CONFLICTS: 0
*** M204.2814: FILE ''filename'' NUMBER OF MULTISEGMENT OBJECTS: 5

 
[[Category:File manager]]
[[Category:File management]]

File size calculation in detail

2013-05-12T23:03:08Z

Rob: /* Compacting Table E */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of either the full logical records-a base record, plus extension(s) (that contain the values of all VISIBLE fields), or if Table X is enabled, the visible fields in the base record. This section discusses Table B by itself, and the Table X impact is discussed in the next section.

Either way, to size the data are correctly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 

==Sizing Tables B and X==
===Creating a file with a Table X===
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Dividing data between Table B and X===
Obviously:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you may take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>
<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>
<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward (and if [[RECRDOPT parameter|RECRDOPT]] is set to one, then sizing of Table B is trivial (how many records do you expect to have?).

===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages.

The rules of use, and sizing, are quite different depending on whether the [[FILEORG parameter|FILEORG]] x'100' bit is set. For these differences, see:

[[Table E (File Architecture)|Table E]]
[[Table E FILEORG x'100' (File Architecture)|Table E FILEORG x'100']]
[[Table E non x'100' (File Architecture)|Table E non x'100']]

==== ESIZE For [[FILEORG parameter|FILEORG]] x'100' files ====

Set ESIZE as the number of Data pages.

To calculate the number of Data pages: Average the BLOB/CLOB length, divide by 6140 (The usable page size of 6144 less the 4 byte chain pointer) and round up. Then, multiply by the total number of Large Object fields (and probably add a percentage for growth (based on your knowledge of the data and application).

Additional considerations:

<ul>
<li>If you have [[#Field Design (File Management)# BLOB, CLOB and MINLOBE attributes|MINLOBE]] set, ignore large objects smaller than this number.</li>
<li>Be sure to take that (along with the large object header) into account when sizing Tables B and X.</li>
</ul>

For more detail on the large object architecture, see [[Table E FILEORG x'100' (File Architecture)|Table E for FILEORG X'100']] files.

==== ESIZE for non [[FILEORG parameter|FILEORG]] x'100' files ====

'''Characteristics:'''
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 

'''Sizing:'''

Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>

Generally speaking, the cost of finding free space in Table E non x'100' files is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files (or make the file an x'100' file). This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.

For more detail on the large object architecture, see [[Table E non x'100' (File Architecture)|Table E for non FILEORG X'100' files]].

===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.

==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

Table E and non-FILEORG X'100' files (File architecture)

2013-05-12T23:01:29Z

Rob:

Holds Large Object Data (BLOBs and CLOBs)

<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size.

When FILEORG x'100'is not set on a file, this is enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[ESIZE parameter|ESIZE]] greater than 0, and then [[DEFINE FIELD command|defining one or more fields]] with an attribute of CLOB or BLOB (the file must have an ESIZE for the latter to occur).

Available as of Model 204 V7.1

==Summary==

Storage and manipulation of Large Objects (LOBs):

Table E under non [[FILEORG parameter|FILEORG]] x'100' files remain a reasonable choice for static stores of Large Objects (scanned forms, for example). If it is expected that there will be large numbers of adds, changes and deletes, strong consideration should be given to [[Table E FILEORG x'100' (File Architecture)|Table E with FILEORG x'100']].

== Bitmaps to track space availability ==

In Table E, in addition to the pages used to store the Large Object Data, there are bitmap pages which track the page use. For every 49152 pages of Table E defined, there will be one bitmap page.

The boundaries of these sets of records are a consideration in the execution of the [[COMPACTE command]], as the compactor process one of these sets at a time, and LOBs stored on pages that span a bitmap boundary do not participate in the compaction.

== Storing Large Objects ==

When a field is defined as a large object (LOB) (the attributes [[#Field Design (File Management) BLOB attribute|BLOB]] or [[#Field Design (File Management) CLOB attribute|CLOB]]) a pointer is stored in the record (in Tables B or X) and the LOB is stored in Table E.

=== Pointer in the record ===

When you store a Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, reserve, and a pointer to the Large Object data in the Table E page and is 27 bytes long.

=== Large Object Header ===
Every large object stored in Table E starts with a Large Object Header (this is used to make the [[COMPACTE command|Table E compact]]ion work better. The large object header contains a field for the Table B record number that points to the large object—thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required.
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>

So, the first 6110 bytes (non preallocated) of a large object are on the first Table E page (while later pages will fit 6144 bytes). If you plan on storing a large number of relatively small LOBs, this size differential needs to be taken into account when sizing Table E.

=== Table E Space Utilization ===

Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data (the first page only 6112 due to the header).
::A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages.
::Large Object field data from 1 to 6112 bytes occupies one Table E page. If the data is from 1 to 6111 bytes, the page is not completely filled. so the remainder of the page is unused.
::Large Object data of 6113 bytes requires two Table E pages, and LOB data of 12267 bytes will take three pages (6112 + 6144 + 1).

=== Storing a Large Object ===

The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored (and you must if you wish the object to expand in size after its initial store), then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.

If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG—even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages
in Table E. Unused pages are a result of deleting Large Object data.

Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large
Object data stored in the file show a wide variation in size.

If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you use [[FILEORG parameter|FILEORG]] x'100'files.

==The following Parameters and Commands relate to the Use of Table E==

{|
|[[COMPACTE command]]
|Defragment the contents of Table E
|-
|[[EHIGHPG parameter]]
|The highest active Table E page. (The first page in Table E is page zero.)
|-
|[[EPGSUSED parameter]]
|The number of Table E pages currently in use.
|-
|[[ESIZE parameter]]
|The number of pages in Table E
|-
|[[FILEORG parameter]]
|The file organisation
|}

[[Category:File architecture]]

Table E and non-FILEORG X'100' files (File architecture)

2013-05-12T22:58:07Z

Rob: /* Large Object Header */

Holds Large Object Data (BLOBs and CLOBs)

When FILEORG x'100'is set on a file, this is enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[ESIZE parameter|ESIZE]] greater than 0, and then [[DEFINE FIELD command|defining one or more fields]] with an attribute of CLOB or BLOB (the file must have an ESIZE for the latter to occur).

Available as of Model 204 V7.1

==Summary==

Storage and manipulation of Large Objects (LOBs):

Table E under non [[FILEORG parameter|FILEORG]] x'100' files remain a reasonable choice for static stores of Large Objects (scanned forms, for example). If it is expected that there will be large numbers of adds, changes and deletes, strong consideration should be given to [[Table E FILEORG x'100' (File Architecture)|Table E with FILEORG x'100']].

== Bitmaps to track space availability ==

In Table E, in addition to the pages used to store the Large Object Data, there are bitmap pages which track the page use. For every 49152 pages of Table E defined, there will be one bitmap page.

The boundaries of these sets of records are a consideration in the execution of the [[COMPACTE command]], as the compactor process one of these sets at a time, and LOBs stored on pages that span a bitmap boundary do not participate in the compaction.

== Storing Large Objects ==

When a field is defined as a large object (LOB) (the attributes [[#Field Design (File Management) BLOB attribute|BLOB]] or [[#Field Design (File Management) CLOB attribute|CLOB]]) a pointer is stored in the record (in Tables B or X) and the LOB is stored in Table E.

=== Pointer in the record ===

When you store a Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, reserve, and a pointer to the Large Object data in the Table E page and is 27 bytes long.

=== Large Object Header ===
Every large object stored in Table E starts with a Large Object Header (this is used to make the [[COMPACTE command|Table E compact]]ion work better. The large object header contains a field for the Table B record number that points to the large object—thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required.
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>

So, the first 6110 bytes (non preallocated) of a large object are on the first Table E page (while later pages will fit 6144 bytes). If you plan on storing a large number of relatively small LOBs, this size differential needs to be taken into account when sizing Table E.

=== Table E Space Utilization ===

Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data (the first page only 6112 due to the header).
::A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages.
::Large Object field data from 1 to 6112 bytes occupies one Table E page. If the data is from 1 to 6111 bytes, the page is not completely filled. so the remainder of the page is unused.
::Large Object data of 6113 bytes requires two Table E pages, and LOB data of 12267 bytes will take three pages (6112 + 6144 + 1).

=== Storing a Large Object ===

The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored (and you must if you wish the object to expand in size after its initial store), then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.

If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG—even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages
in Table E. Unused pages are a result of deleting Large Object data.

Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large
Object data stored in the file show a wide variation in size.

If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you use [[FILEORG parameter|FILEORG]] x'100'files.

==The following Parameters and Commands relate to the Use of Table E==

{|
|[[COMPACTE command]]
|Defragment the contents of Table E
|-
|[[EHIGHPG parameter]]
|The highest active Table E page. (The first page in Table E is page zero.)
|-
|[[EPGSUSED parameter]]
|The number of Table E pages currently in use.
|-
|[[ESIZE parameter]]
|The number of pages in Table E
|-
|[[FILEORG parameter]]
|The file organisation
|}

[[Category:File architecture]]

File size calculation in detail

2013-05-12T22:50:38Z

Rob: /* Sizing Table E */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of either the full logical records-a base record, plus extension(s) (that contain the values of all VISIBLE fields), or if Table X is enabled, the visible fields in the base record. This section discusses Table B by itself, and the Table X impact is discussed in the next section.

Either way, to size the data are correctly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 

==Sizing Tables B and X==
===Creating a file with a Table X===
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Dividing data between Table B and X===
Obviously:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you may take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>
<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>
<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward (and if [[RECRDOPT parameter|RECRDOPT]] is set to one, then sizing of Table B is trivial (how many records do you expect to have?).

===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages.

The rules of use, and sizing, are quite different depending on whether the [[FILEORG parameter|FILEORG]] x'100' bit is set. For these differences, see:

[[Table E (File Architecture)|Table E]]
[[Table E FILEORG x'100' (File Architecture)|Table E FILEORG x'100']]
[[Table E non x'100' (File Architecture)|Table E non x'100']]

==== ESIZE For [[FILEORG parameter|FILEORG]] x'100' files ====

Set ESIZE as the number of Data pages.

To calculate the number of Data pages: Average the BLOB/CLOB length, divide by 6140 (The usable page size of 6144 less the 4 byte chain pointer) and round up. Then, multiply by the total number of Large Object fields (and probably add a percentage for growth (based on your knowledge of the data and application).

Additional considerations:

<ul>
<li>If you have [[#Field Design (File Management)# BLOB, CLOB and MINLOBE attributes|MINLOBE]] set, ignore large objects smaller than this number.</li>
<li>Be sure to take that (along with the large object header) into account when sizing Tables B and X.</li>
</ul>

For more detail on the large object architecture, see [[Table E FILEORG x'100' (File Architecture)|Table E for FILEORG X'100']] files.

==== ESIZE for non [[FILEORG parameter|FILEORG]] x'100' files ====

'''Characteristics:'''
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 

'''Sizing:'''

Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>

Generally speaking, the cost of finding free space in Table E non x'100' files is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files (or make the file an x'100' file). This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.

For more detail on the large object architecture, see [[Table E non x'100' (File Architecture)|Table E for non FILEORG X'100' files]].

===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.

==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

File size calculation in detail

2013-05-12T22:48:41Z

Rob: /* Sizing and managing Table E */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of either the full logical records-a base record, plus extension(s) (that contain the values of all VISIBLE fields), or if Table X is enabled, the visible fields in the base record. This section discusses Table B by itself, and the Table X impact is discussed in the next section.

Either way, to size the data are correctly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 

==Sizing Tables B and X==
===Creating a file with a Table X===
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Dividing data between Table B and X===
Obviously:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you may take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>
<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>
<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward (and if [[RECRDOPT parameter|RECRDOPT]] is set to one, then sizing of Table B is trivial (how many records do you expect to have?).

===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages.

The rules of use, and sizing, are quite different depending on whether the [[FILEORG parameter|FILEORG]] x'100' bit is set. For these differences, see:

[[Table E (File Architecture)|Table E]]
[[Table E FILEORG x'100' (File Architecture)|Table E FILEORG x'100']]
[[Table E non x'100' (File Architecture)|Table E non x'100']]

==== ESIZE For [[FILEORG parameter|FILEORG]] x'100' files ====

Set ESIZE as the number of Data pages.

To calculate the number of Data pages: Average the BLOB/CLOB length, divide by 6140 (The usable page size of 6144 less the 4 byte chain pointer) and round up. Then, multiply by the total number of Large Object fields (and probably add a percentage for growth (based on your knowledge of the data and application).

Additional considerations:

<ul>
<li>If you have [[#Field Design (File Management)# BLOB, CLOB and MINLOBE attributes|MINLOBE]] set, ignore large objects smaller than this number.</li>
<li>Be sure to take that (along with the large object header) into account when sizing Tables B and X.</li>
</ul>

For more detail on the large object architecture, see [[Table E FILEORG x'100' (File Architecture)|Table E for FILEORG X'100']] files.

==== ESIZE for non [[FILEORG parameter|FILEORG]] x'100' files ====

'''Characteristics:'''
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 

'''Sizing:'''

Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>

Generally speaking, the cost of finding free space in Table E non x'100' files is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.

For more detail on the large object architecture, see [[Table E non x'100' (File Architecture)|Table E for non FILEORG X'100' files]].

===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.

==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

Record (File architecture)

2013-05-12T22:21:05Z

Rob: /* Record Growth */

== Overview ==

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the [[#Table A (File Architecture) Internal File Dictionary|Internal File Dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique (but temporary... it will likely change when the file is reorganized) internal record number (IRN) that is used by the system to build index entries for the record.

For example, the following code:


IN ''filename'' STORE RECORD
END STORE


Does, in fact, physically store a record. It has been assigned an [[#Internal Record Number|Internal Record Number]] and would contain the pre-allocated field structure (if any), but no data.

== Records. Base Records and Extension Records ==

The term 'record' is actually used three ways: 

* the record as a full collection of all of the data about a 'thing'
* base records: the initial portion of that data
* extension records: a (possible) string of additional portions of the data

These are discussed below:

=== the Record as a container ===

Is just that: a way to describe all of the data held against the record key (presuming there is one)...

=== <div id="Base Records">Base Records</div> ===

The base record is the first (and, often, only) part of the record. It is assigned a slot in Table B, and its internal record number is how Model 204 identifies the record for indexing peuporses as well as in record sets and lists.

=== <div id="Extension Records">Extension Records</div> ===

When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record) one or more extension records are stored.

If [[Table X (File Architecture)|Table X]] is enables, all such extensions are stored there, otherwise the extension(s) are stored in Table B.

=== <div id="Record Growth">Record Growth</div> ===

The [[ADD statement]] (or the file load process) always places new data at the end of a record, and so, the record growth is straightforward: add a fuield at the end of the record, if it doesn't fit, start a new extension.

[[INSERT statement|INSERT]]s are more complicated. Whether updating fields or repeating field groups, the correct location must be found within a record, and the data inserted at that point.

It is, of course, quite possible, that there will not be enough space on the page to insert it, in which case space is made by moving data from this record (after the insert point) down the extension chain. So, with large extension records, it is conceivable that a single field added to the base record (for example) might cause all of the extensions to need to change.

=== <div id="Internal Record Number">The Internal Record Number (IRN)</div> ===

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[FOR RECORD NUMBER statement]]) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before. 

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bit Maps (File Architecture)|Bit Maps]] for more information.

== The Structure of a Model 204 Record ==

As shown in [[Table B (File Architecture)|Table B]], Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

::[[File:Record Structure (File Architecture).jpg]]

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

=== Extension Pointer ===

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with an extension record pointer.

For files without a Table X, this pointer is 3 bytes in length.

For files with [[Table X (File Architecture)|Table X]] enables, this pointer is 4 bytes in length (to handle the larger number of slots in Table X).

Regardless of the length, this pointer links this portion of the record to its next portion. Where that location is, of course, dependent on whether Table X is enabled.

=== Data ===

If there are any preallocated fields in a file (see the [[|Field Design (File Management)#Preallocated fields|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File Architecture) Record Map|the Record Map in Table D]].

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were [[ADD statement|ADD]]ed (which always adds the entity at the end of the record); or positioned by an [[INSERT statement]]. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

==== [[Field Design (File Management)#Preallocated Fields|Preallocated Fields]] ====

All records stored in a Model204 file will contain all of the preallocated fields (if any) for that file. These are stored based on the [[Table D (File Architecture)#Record Map of Preallocated Fields|Record Map of preallocated fields]] stored in Table D.

==== [[Field Value Pairs (File Architecture)|Field Value Pairs]] ====

Field Value Pairs, or, perhaps more precisely, ''Field Name 'Equals' Value Pairs'' are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

==== [[Repeating Field Group (File Architecture)|Repeating Field Groups]] (RFGs)====

Permits sets of data to be managed together. Inside of the RFG is a series of field value pairs (as above) but these fields are not independent of each other.

==== Large Objects ====

There are two ways that large objects (data longer than 255 bytes) may be handled in a Model 204 record.

===== [[Table E (File Architecture)|Native Large Objects in Table E]] =====

Large objects stored as part of a record, contain a pointer locally (within the record) to the starting point of the Large Object in Table E.

Starting in Model 204 V7R5, the handling and functionality of Large Objects can (by using the [[FILEORG parameter|FILEORG]] x'100' bit) be done rather differently. See [[Table E (File Architecture)|Table E]] for the full discussion.

===== Large Objects Without Table E =====

If [[Table E (File Architecture)|Table E]] is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code. 

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes.

The application would need to parse the input data into 255 byte chunks to store it, and then again, string it together to read it.

Rocket Software recommends that, where large objects need to be stored that, for efficiency reasons, Tabel E be enables.

[[Category:File architecture]]

Table B (File architecture)

2013-05-10T04:43:55Z

Rob:

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 (File Architecture)|Table X]] is not enabled it also contains all extension records. If [[Table E (File Architecture)|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 ==

::[[File:Table B Basic Structure (File Architecture).jpg]]

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 parameter|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 parameter|FILEORG]] x'100') files, with [[RECRDOPT parameter|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.

<div id="Internal Record Number"></div>
'''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 parameter|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 ===

== Space Management Across Pages ==

=== Extension Records ===

=== Further information on Records ===

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.

=== <div id="Table B (File Architecture) Segments">Table B Segments</div> ===

==== Definition ====

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

==== 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 [[Managing File and Table Sizes#The MAXINCBP parameter|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 (File Architecture)#Segment Entries |Table C Segment Entries]] for the effect of segments in the hash index.

* See [[#Table D (File Architecture)#B-Tree index structure|B-Tree index structure]] for the effect of segments in the ordered index.

* See [[#Table D (File Architecture)#Bit Maps Used In Indexing|bit maps used in indexing]] for how segments relate to the detailed level of both types of indexes.

=== <div id="Table B (File Architecture) The Reuse Queue">The Reuse Queue</div>===

For Reuse Record Number (RRN) files ([[FILEORG parameter|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 parameter|BHIGHPG]].

==The following Parameters relate to the Use of Table B==

This table excludes the parameters used for [[Hash Key Files|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 [[#Resizing Tables (File Management) Automatic Increases|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.
|-

|}

[[Category:File architecture]]

Record (File architecture)

2013-05-09T23:32:46Z

Rob: /* Large Objects */

== Overview ==

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the [[#Table A (File Architecture) Internal File Dictionary|Internal File Dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique (but temporary... it will likely change when the file is reorganized) internal record number (IRN) that is used by the system to build index entries for the record.

For example, the following code:


IN ''filename'' STORE RECORD
END STORE


Does, in fact, physically store a record. It has been assigned an [[#Internal Record Number|Internal Record Number]] and would contain the pre-allocated field structure (if any), but no data.

== Records. Base Records and Extension Records ==

The term 'record' is actually used three ways: 

* the record as a full collection of all of the data about a 'thing'
* base records: the initial portion of that data
* extension records: a (possible) string of additional portions of the data

These are discussed below:

=== the Record as a container ===

Is just that: a way to describe all of the data held against the record key (presuming there is one)...

=== <div id="Base Records">Base Records</div> ===

The base record is the first (and, often, only) part of the record. It is assigned a slot in Table B, and its internal record number is how Model 204 identifies the record for indexing peuporses as well as in record sets and lists.

=== <div id="Extension Records">Extension Records</div> ===

When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record) one or more extension records are stored.

If [[Table X (File Architecture)|Table X]] is enables, all such extensions are stored there, otherwise the extension(s) are stored in Table B.

=== <div id="Record Growth">Record Growth</div> ===

The [[ADD statement]] (or the file load process) always places new data at the end of a record, and so, the record growth is straightforward: add a fuield at the end of the record, if it doesn't fit, start a new extension.

[[INSERT statement|INSERT]]s are more complicated. Whether updating fields or repeating field groups, the correct location must be found within a record, and the data inserted at that point.

It is, of course, quite possible, that there will not be enough space on the page to insert it, in which case space is made by moving data from this record (after the insert point) down the extension chain. So, with large extension records, it is conceivable that a single field added to the base record (for example) might cause all of the extensions to need to change.

=== <div id="Internal Record Number">The Internal Record Number (IRN)</div> ===

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[FOR RECORD NUMBER statement]]) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before. 

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bit Maps (File Architecture)|Bit Maps]] for more information.

== The Structure of a Model 204 Record ==

As shown in [[Table B (File Architecture)|Table B]], Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

::[[File:Record Structure (File Architecture).jpg]]

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

=== Extension Pointer ===

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with an extension record pointer.

For files without a Table X, this pointer is 3 bytes in length.

For files with [[Table X (File Architecture)|Table X]] enables, this pointer is 4 bytes in length (to handle the larger number of slots in Table X).

Regardless of the length, this pointer links this portion of the record to its next portion. Where that location is, of course, dependent on whether Table X is enabled.

=== Data ===

If there are any preallocated fields in a file (see the [[|Field Design (File Management)#Preallocated fields|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File Architecture) Record Map|the Record Map in Table D]].

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were [[ADD statement|ADD]]ed (which always adds the entity at the end of the record); or positioned by an [[INSERT statement]]. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

==== [[Field Design (File Management)#Preallocated Fields|Preallocated Fields]] ====

All records stored in a Model204 file will contain all of the preallocated fields (if any) for that file. These are stored based on the [[Table D (File Architecture)#Record Map of Preallocated Fields|Record Map of preallocated fields]] stored in Table D.

==== [[Field Value Pairs (File Architecture)|Field Value Pairs]] ====

Field Value Pairs, or, perhaps more precisely, ''Field Name 'Equals' Value Pairs'' are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

==== [[Repeating Field Group (File Architecture)|Repeating Field Groups]] (RFGs)====

Permits sets of data to be managed together. Inside of the RFG is a series of field value pairs (as above) but these fields are not independent of each other.

==== Large Objects ====

There are two ways that large objects (data longer than 255 bytes) may be handled in a Model 204 record.

===== [[Table E (File Architecture)|Native Large Objects in Table E]] =====

Large objects stored as part of a record, contain a pointer locally (within the record) to the starting point of the Large Object in Table E.

Starting in Model 204 V7R5, the handling and functionality of Large Objects can (by using the [[FILEORG parameter|FILEORG]] x'100' bit) be done rather differently. See [[Table E (File Architecture)|Table E]] for the full discussion.

===== Large Objects Without Table E =====

If [[Table E (File Architecture)|Table E]] is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code. 

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes.

The application would need to parse the input data into 255 byte chunks to store it, and then again, string it together to read it.

Rocket Software recommends that, where large objects need to be stored that, for efficiency reasons, Tabel E be enables.

[[Category:File architecture]]

Record (File architecture)

2013-05-09T23:26:17Z

Rob:

== Overview ==

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the [[#Table A (File Architecture) Internal File Dictionary|Internal File Dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique (but temporary... it will likely change when the file is reorganized) internal record number (IRN) that is used by the system to build index entries for the record.

For example, the following code:


IN ''filename'' STORE RECORD
END STORE


Does, in fact, physically store a record. It has been assigned an [[#Internal Record Number|Internal Record Number]] and would contain the pre-allocated field structure (if any), but no data.

== Records. Base Records and Extension Records ==

The term 'record' is actually used three ways: 

* the record as a full collection of all of the data about a 'thing'
* base records: the initial portion of that data
* extension records: a (possible) string of additional portions of the data

These are discussed below:

=== the Record as a container ===

Is just that: a way to describe all of the data held against the record key (presuming there is one)...

=== <div id="Base Records">Base Records</div> ===

The base record is the first (and, often, only) part of the record. It is assigned a slot in Table B, and its internal record number is how Model 204 identifies the record for indexing peuporses as well as in record sets and lists.

=== <div id="Extension Records">Extension Records</div> ===

When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record) one or more extension records are stored.

If [[Table X (File Architecture)|Table X]] is enables, all such extensions are stored there, otherwise the extension(s) are stored in Table B.

=== <div id="Record Growth">Record Growth</div> ===

The [[ADD statement]] (or the file load process) always places new data at the end of a record, and so, the record growth is straightforward: add a fuield at the end of the record, if it doesn't fit, start a new extension.

[[INSERT statement|INSERT]]s are more complicated. Whether updating fields or repeating field groups, the correct location must be found within a record, and the data inserted at that point.

It is, of course, quite possible, that there will not be enough space on the page to insert it, in which case space is made by moving data from this record (after the insert point) down the extension chain. So, with large extension records, it is conceivable that a single field added to the base record (for example) might cause all of the extensions to need to change.

=== <div id="Internal Record Number">The Internal Record Number (IRN)</div> ===

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[FOR RECORD NUMBER statement]]) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before. 

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bit Maps (File Architecture)|Bit Maps]] for more information.

== The Structure of a Model 204 Record ==

As shown in [[Table B (File Architecture)|Table B]], Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

::[[File:Record Structure (File Architecture).jpg]]

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

=== Extension Pointer ===

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with an extension record pointer.

For files without a Table X, this pointer is 3 bytes in length.

For files with [[Table X (File Architecture)|Table X]] enables, this pointer is 4 bytes in length (to handle the larger number of slots in Table X).

Regardless of the length, this pointer links this portion of the record to its next portion. Where that location is, of course, dependent on whether Table X is enabled.

=== Data ===

If there are any preallocated fields in a file (see the [[|Field Design (File Management)#Preallocated fields|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File Architecture) Record Map|the Record Map in Table D]].

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were [[ADD statement|ADD]]ed (which always adds the entity at the end of the record); or positioned by an [[INSERT statement]]. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

==== [[Field Design (File Management)#Preallocated Fields|Preallocated Fields]] ====

All records stored in a Model204 file will contain all of the preallocated fields (if any) for that file. These are stored based on the [[Table D (File Architecture)#Record Map of Preallocated Fields|Record Map of preallocated fields]] stored in Table D.

==== [[Field Value Pairs (File Architecture)|Field Value Pairs]] ====

Field Value Pairs, or, perhaps more precisely, ''Field Name 'Equals' Value Pairs'' are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

==== [[Repeating Field Group (File Architecture)|Repeating Field Groups]] (RFGs)====

Permits sets of data to be managed together. Inside of the RFG is a series of field value pairs (as above) but these fields are not independent of each other.

==== Large Objects ====

There are two ways that large objects (data longer than 255 bytes) may be handled in a Model 204 record.

===== [[Table E (File Architecture)|Native Large Objects in Table E]] =====

Large objects stored as part of a record, contain a pointer locally (within the record) to the starting point of the Large Object in Table E.

Starting in Model 204 V7R5, the handling and functionality of Large Objects can (by using the [[FILEORG parameter|FILEORG]] x'100' bit) be done rather differently. See [[Table E (File Architecture)|Table E]] for the full discussion.

===== Large Objects Without Table E =====

If [[Table E (File Architecture)|Table E]] is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code. 

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes.

The application would need to parse the input data into 255 byte chunks to store it, and then again, string it together to read it.

Rocket Software recommends that, where large objects need to be stored that, for efficiency reasons, Tabel E be enables.

[[Category:File architecture]]

Record (File architecture)

2013-05-09T23:15:38Z

Rob:

== Overview ==

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the [[#Table A (File Architecture) Internal File Dictionary|Internal File Dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique (but temporary... it will likely change when the file is reorganized) internal record number (IRN) that is used by the system to build index entries for the record.

For example, the following code:


IN ''filename'' STORE RECORD
END STORE


Does, in fact, physically store a record. It has been assigned an [[#Internal Record Number|Internal Record Number]] and would contain the pre-allocated field structure (if any), but no data.

== Records. Base Records and Extension Records ==

The term 'record' is actually used three ways: 

* the record as a full collection of all of the data about a 'thing'
* base records: the initial portion of that data
* extension records: a (possible) string of additional portions of the data

These are discussed below:

=== the Record as a container ===

=== <div id="Base Records">Base Records</div> ===

The base record is the first (and, often, only) part of the record. It is assigned a slot in Table B, and its internal record number is how Model 204 identifies the record for indexing peuporses as well as in record sets and lists.

=== <div id="Extension Records">Extension Records</div> ===

When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record) one or more extension records are stored.

If [[Table X (File Architecture)|Table X]] is enables, all such extensions are stored there, otherwise the extension(s) are stored in Table B.

=== <div id="Internal Record Number">The Internal Record Number (IRN)</div> ===

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[FOR RECORD NUMBER statement]]) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before. 

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bit Maps (File Architecture)|Bit Maps]] for more information.

== The Structure of a Model 204 Record ==

As shown in [[Table B (File Architecture)|Table B]], Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

::[[File:Record Structure (File Architecture).jpg]]

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

=== Extension Pointer ===

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with an extension record pointer.

For files without a Table X, this pointer is 3 bytes in length.

For files with [[Table X (File Architecture)|Table X]] enables, this pointer is 4 bytes in length (to handle the larger number of slots in Table X).

Regardless of the length, this pointer links this portion of the record to its next portion. Where that location is, of course, dependent on whether Table X is enabled.

=== Data ===

If there are any preallocated fields in a file (see the [[|Field Design (File Management)#Preallocated fields|OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File Architecture) Record Map|the Record Map in Table D]].

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were [[ADD statement|ADD]]ed (which always adds the entity at the end of the record); or positioned by an [[INSERT statement]]. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

==== [[Field Design (File Management)#Preallocated Fields|Preallocated Fields]] ====

All records stored in a Model204 file will contain all of the preallocated fields (if any) for that file. These are stored based on the [[Table D (File Architecture)#Record Map of Preallocated Fields|Record Map of preallocated fields]] stored in Table D.

==== [[Field Value Pairs (File Architecture)|Field Value Pairs]] ====

Field Value Pairs, or, perhaps more precisely, ''Field Name 'Equals' Value Pairs'' are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

==== [[Repeating Field Groups (File Architecture)|Repeating Field Groups]] (RFGs)====

Permits sets of data to be managed together. Inside of the RFG is a series of field value pairs (as above) but these fields are not independent of each other.

==== Large Objects ====

There are two ways that large objects (data longer than 255 bytes) may be handled in a Model 204 record.

===== [[Table E (File Architecture)|Native Large Objects in Table E]] =====

Large objects stored as part of a record, contain a pointer locally (within the record) to the starting point of the Large Object in Table E.

Starting in Model 204 V7R5, the handling and functionality of Large Objects can (by using the [[FILEORG parameter|FILEORG]] x'100' bit) be done rather differently. See [[Table E (File Architecture)|Table E]] for the full discussion.

===== Large Objects Without Table E =====

If [[Table E (File Architecture)|Table E]] is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code. 

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes.

The application would need to parse the input data into 255 byte chunks to store it, and then again, string it together to read it.

Rocket Software recommends that, where large objects need to be stored that, for efficiency reasons, Tabel E be enables.

[[Category:File architecture]]

Record (File architecture)

2013-05-09T23:01:32Z

Rob:

== Overview ==

A Model 204 Record is a collection of fields (either individually; in Repeating Field Groups (RFGs); or any mixture of these) containing a set of data about a thing. Admittedly, this is a very vague description, because the flexibility of Model 204 permits the File Manager to create files whose records are best suited to the required purpose, whatever it may be.

Each record is variable in length and need contain only the fields (some or all of those contained in the [[#Table A (File Architecture) Internal File Dictionary|Internal File Dictionary in Table A]]) that pertain to it. The limit of the number of field value pairs in a record is in the tens of millions.

There is only a limited fixed format for data within a record (pre-allocated fields). Almost any number of fields can appear almost any number of times in almost any order. Each record is automatically assigned a unique (but temporary... it will likely change when the file is reorganized) internal record number (IRN) that is used by the system to build index entries for the record.

For example, the following code:


IN ''filename'' STORE RECORD
END STORE


Does, in fact, physically store a record. It has been assigned an [[#Internal Record Number|Internal Record Number]] and would contain the pre-allocated field structure (if any), but no data.

== Records. Base Records and Extension Records ==

The term 'record' is actually used three ways: 

* the record as a full collection of all of the data about a 'thing'
* base records: the initial portion of that data
* extension records: a (possible) string of additional portions of the data

These are discussed below:

=== the Record as a container ===

=== <div id="Base Records">Base Records</div> ===

The base record is the first (and, often, only) part of the record. It is assigned a slot in Table B, and its internal record number is how Model 204 identifies the record for indexing peuporses as well as in record sets and lists.

=== <div id="Extension Records">Extension Records</div> ===

When a full record is not able to fit on a particular page (either, it itself may be more than 6140 bytes, or other records on the page do not leave sufficient space for the record) one or more extension records are stored.

If [[Table X (File Architecture)|Table X]] is enables, all such extensions are stored there, otherwise the extension(s) are stored in Table B.

=== <div id="Internal Record Number">The Internal Record Number (IRN)</div> ===

The internal record number (IRN) is the base record number (or slot) assigned when the record is first stored. While, once assigned, it can be passed around inside a program as an easy way to refer back to the set of data (see the [[FOR RECORD NUMBER statement]]) it is not a permanent identifier: when the file is reorganized the position where a record is reloaded may be quite different than where it was before. 

The IRN (represented by a single bit) is used as a target for Model 204 indexing (both hashed and B-tree indexing). See [[Bit Maps (File Architecture)|Bit Maps]] for more information.

== The Structure of a Model 204 Record ==

As shown in [[Table B (File Architecture)|Table B]], Model 204 records grow from the end toward the beginning of the page it is stored upon. So, a proper representation of the record shows it as:

::[[File:Record Structure (File Architecture).jpg]]

In any discussion of the record, the 'beginning' of the record is to the left, and the growth (represented by the blue arrow) is toward the right.

=== Extension Pointer ===

Every 'portion' of every Model 204 record (base or one of perhaps many extensions) begins with an extension record pointer.

For files without a Table X, this pointer is 3 bytes in length.

For files with [[Table X (File Architecture)|Table X]] enables, this pointer is 4 bytes in length (to handle the larger number of slots in Table X).

Regardless of the length, this pointer links this portion of the record to its next portion. Where that location is, of course, dependent on whether Table X is enabled.

=== Data ===

If there are any preallocated fields in a file (see the [[OCCURS attribute]]) every record in that file will begin with the set of such fields, immediately after the extension pointer. The structure of the fields is held in [[#Table D (File Architecture) Record Map|the Record Map in Table D]].

Note: For the Sort or Hash key (for such files), if it is preallocated (and it should be unless it is wildly variable in size) it will be the first field in the record map. If it is not preallocated, it will be the first 'field value pair' in the record.

After the preallocated fields, is the rest of the data; a series of: field value pairs; repeating field groups; and / or pointers to large objects. These will be physically positioned in: either the order they were [[ADD statement|ADD]]ed (which always adds the entity at the end of the record); or positioned by an [[INSERT statement]]. Hence, the application code controls the relative order of the data in the record, once past the preallocated fields.

Each of the four is briefly described below, but refer to the specific topic for each for further detail:

==== [[Preallocated Fields (File Architecture)|Preallocated Fields]] ====

All records stored in a Model204 file will contain all of the preallocated fields (if any) for that file. These are stored based on the [[Table D (File Architecture)#Record Map of Preallocated Fields|Record Map of preallocated fields]] stored in Table D.

==== [[Field Value Pairs (File Architecture)|Field Value Pairs]] ====

Field Value Pairs, or, perhaps more precisely, ''Field Name 'Equals' Value Pairs'' are the most common way data is held in a Model 204 Record. (Even the Repeating Field Group structure is a set of Field Value Pairs which occur in tandem).

==== [[Repeating Field Groups (File Architecture|Repeating Field Groups]] ====

==== Large Objects ====

There are two ways that large objects (data longer than 255 bytes) may be handled in a Model 204 record.

===== [[Table E (File Architecture)|Native Large Objects in Table E]] =====



===== Large Objects Without Table E =====

If [[Table E (File Architecture)|Table E]] is not enabled, and the File Manager still wishes to store data which is more than 255 bytes long, it must be done by the application code. 

The technique is to store the data as a series of repeating fields, each containing (up to) 255 bytes.

The application would need to parse the input data into 255 byte chunks to store it, and then again, string it together to read it.

Rocket Software recommends that, where large objects need to be stored that, for efficiency reasons, Tabel E be enables.

[[Category:File architecture]]

Record design

2013-05-08T21:48:08Z

Rob:

==Overview==

Because of the unique nature of Model 204 Records (see [[Record (File Architecture)|Record architecture]]), the translation of a logical design into Model 204 records often includes data. 

For example, if you consider a billing system, where you might consider having separate records for an invoice, and then additional records for each of the invoice lines, for a Model 204 perspective it is more likely that you would have a single record where the invoice lines simply repeat (either as a set of fields, or as a formal [[Repeating Field Group (File Architecture)|Repeating Field Group]] (RFG).

There are a number of reasons why this approach suits Model 204:

* Because a single read of the record makes all of the information available (think of the data as being pre-joined) performance should be better
* the factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204.

The most important thing, regardless of whether you are implementing a design in Model 204 or any platform, is to understand the data relationships.

==The importance of a good logical design==

If you have a good logical design, the record structure should almost jump out at the file manager: tying data which is logically connected can be efficiently, physically, tied together.

==A unique record key==

Unlike many systems, Model 204 will support records with duplicate record keys.

But, while it supports it, it is often not a good idea. Perhaps you need to provide reports off of the data, or extract data to feed other systems

==Fields and Fieldgroups==

[[Category:File management]]

File sizing introduction

2013-05-07T23:17:36Z

Rob: /* Critical, Up Front Decisions */

==Overview - Two approaches to File Sizing==
After designing the data structures you are implementing (see [[Field Design (File Management)|field]] and [[Repeating Field Group Design (File Management)|Repeating Field Group design]]) there are two ways for a file manager to approach the calculation of file sizes:

You can take the ad-hoc approach, by making sizing estimates and either:

* iteratively load a sampling of records to verify
* use the development and testing process to make final sizing decisions

or, of course, a combination of both.

Alternatively, you can do a detailed analysis of the data you expect the file to contain, and try and derive precise sizes for the Model 204 tables, a laborious process.

==Choosing an Approach==

Most Model 204 file managers use the ad-hoc design approach. Often there is already a production file with similar characteristics to the new file you are creating. Simply copying its parameters as a starting point, is a quick way to get a file ready for development and testing.

It is also true that most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.

But it is also true that the detailed rules provide a level of knowledge that the file manager should be grounded in, so, to use, or just understand the sizing rules, see [[File Size Calculation in Detail]]. 

==Critical, Up Front Decisions==

There are, however, certain decisions which are more difficult to fix and so should be as 'correct' as possible, as early as possible:

[[ATRPG parameter|ATRPG]] and [[ASTRPPG parameter]]s

Because the [[#Table A (File Architecture)#Internal File Dictionary|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.

You can look at the detailed calculation rules at [[File Size Calculation in Detail#Sizing Table A|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter|ASTRPPG]].

[[CSIZE parameter]]

Like the internal file dictionary, Table C is hashed and so can not be dynamically changed.

The easiest way to make sure that this is an issue is not to define any KEY or NUMERIC RANGE fields: make them ordered instead. This has the associated advantage of, if you use [[FILEORG parameter|FILEORG]] x'100' files, of permitting up to 32000 field names in a file.

Number of Datasets

You can dynamically [[INCREASE command|add datasets]] to a Model 204 file.

The reason that it is better not have to is that there may be JCL containing file references which would need to be updated at the same time.

Unless space is at a premium, it is a good idea to define dataset(s) larger than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.

[[Category:File manager]]
[[Category:File management]]

File sizing introduction

2013-05-07T23:13:57Z

Rob:

==Overview - Two approaches to File Sizing==
After designing the data structures you are implementing (see [[Field Design (File Management)|field]] and [[Repeating Field Group Design (File Management)|Repeating Field Group design]]) there are two ways for a file manager to approach the calculation of file sizes:

You can take the ad-hoc approach, by making sizing estimates and either:

* iteratively load a sampling of records to verify
* use the development and testing process to make final sizing decisions

or, of course, a combination of both.

Alternatively, you can do a detailed analysis of the data you expect the file to contain, and try and derive precise sizes for the Model 204 tables, a laborious process.

==Choosing an Approach==

Most Model 204 file managers use the ad-hoc design approach. Often there is already a production file with similar characteristics to the new file you are creating. Simply copying its parameters as a starting point, is a quick way to get a file ready for development and testing.

It is also true that most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.

But it is also true that the detailed rules provide a level of knowledge that the file manager should be grounded in, so, to use, or just understand the sizing rules, see [[File Size Calculation in Detail]]. 

==Critical, Up Front Decisions==

There are, however, certain decisions which are more difficult to fix and so should be as 'correct' as possible, as early as possible:

[[ATRPG parameter|ATRPG]] and [[ASTRPPG parameter]]s

Because the [[#Table A (File Architecture)#Internal File Dictionary|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.

You can look at the detailed calculation rules at [[File Size Calculation in Detail#Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter|ASTRPPG]].

[[CSIZE parameter]]

Like the internal file dictionary, Table C is hashed and so can not be dynamically changed.

The easiest way to make sure that this is an issue is not to define any KEY or NUMERIC RANGE fields: make them ordered instead. This has the associated advantage of, if you use [[FILEORG parameter|FILEORG]] x'100' files, of permitting up to 32000 field names in a file.

Number of Datasets

You can dynamically [[INCREASE command|add datasets]] to a Model 204 file.

The reason that it is better not have to is that there may be JCL containing file references which would need to be updated at the same time.

Unless space is at a premium, it is a good idea to define dataset(s) larger than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.

[[Category:File manager]]
[[Category:File management]]

Table E and FILEORG X'100' files (File architecture)

2013-05-07T22:47:34Z

Rob:

Holds Large Object Data (BLOBs and CLOBs)

When FILEORG x'100'is set on a file, this is enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[ESIZE parameter|ESIZE]] greater than 0, and then [[DEFINE FIELD command|defining one or more fields]] with an attribute of CLOB or BLOB (the file must have an ESIZE for the latter to occur).

Available as of Model 204 V7.5

==Summary==

Storage and manipulation of Large Objects (LOBs):

The 'chained LOBs' in Table E under [[FILEORG parameter|FILEORG]] x'100' files has a number of advantages over the way LOBs are stored and accessed in non x'100' files.
*because the LOBs no longer need to be contiguous, space monitoring is simpler and files are less likely to fill up.
*fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E)
*you no longer need to predict the fields may be defined so that 'small' entries may be stored 'locally' in the record (and so do not use an entire page in Table E)

== Storing Large Objects ==

When a field is defined as a large object (LOB) ([[#Field Design (File Management) BLOB attribute|BLOB]] or [[#Field Design (File Management) CLOB attribute|CLOB attributes]]) a pointer is stored in the record (in Tables B or X), and, depending on the [[#Field Design (File Management) MINLOBE attribute|MINLOBE attribute]] and length of the value being stored, and the LOB value is stored in its proper place, as follows:

=== Pointer in the record ===

When you store a 'not null' Large Object value in Table E, a Large Object descriptor is stored in Table B (or X depending on where the field is being ADDed). The descriptor contains the length, and a pointer to the Large Object data in the Table E page and is 27 bytes long.

This is the same as non x'100' files.

=== Storing a Large Object ===

When the length of the value being stored is 0 (i.e.: a null string) the action taken depends on the 'repeating' type ([[#Field Design (File Management)#AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes|AT-MOST-ONE, REPEATABLE and EXACTLY-ONE attributes]]). This is discussed in the next section.
Other than null strings, if the value being stored is less than or equal to the [[#Field Design (File Management) MINLOBE attribute|MINLOBE attribute]] for the field, then the value is stored directly in the record (Table B or X). Note that this is in addition to the pointer described above.
If the length of the value being stored is greater than the [[#Field Design (File Management) MINLOBE attribute|MINLOBE attribute]] for the field, the value is stored in a series of pages in Table E with the first (up to) 6140 bytes (4 bytes being reserved for the chain pointer) on the first page, the next (up to) 6140 bytes on the 'next' page, and so on. These pages are not, necessarily, contiguous. Any pages emptied by field or record deletes are first reused, before the pages at [[EHIGHPG parameter|EHIGHPG]] are used. 

==== Null Strings and Large Objects ====

Unlike other field types, the [[#Field Design (File Management)#STORE-DEFAULT (SD) and STORE-NULL (SN) attributes|STORE-DEFAULT (SD) and STORE-NULL (SN) attributes]] may not be set on LOB fields. This results in such fields having the equivalent to the LITeral option. The following table illustrates the results when null strings are stored in Large Object fields:

{| class="wikitable";style="width="90%
|-
! align="center" scope="col" | Attribute
! align="center" scope="col" | Explicit Null ''fieldname'' = ' '
! align="center" scope="col" | Implicit Null ''fieldname'' = %X (where %X is null)
! align="center" scope="col" | No reference in code
|-
! scope="row"| EXACTLY-ONE
| (Note 1)
| (Note 1)
| (Note 1)
|-
! scope="row"| AT-MOST-ONE
| field stored with null value
| not present
| not present
|-
! scope="row"| REPEATABLE
| field stored with null value
| not present
| not present
|}

Note 1: the field will always act as if it is physically present (and return a null). However, exactly one fields react a bit differently depending on whether they are inside a Repeating Field Group (RFG) or not. Inside an RFG, all three operations will result in a field being present (as displayed in a PAI). Outside of RFGs, (and remembering that only the CHANGE statement may be used on exactly one fields) only the 'CHANGE ''fieldname'' TO %X' syntax will physically create an occurrence on the record.

==The following Parameters and Commands relate to the Use of Table E==

'''Note:''' Pages are either used or not in Table E, so there is no formula to determine whether a page is added to the reuse queue (unlike Tables B and X). Because of this, there are no EREUSE, EREUSED, or EQLEN parameters. The size of the reuse queue can always be determined by the difference between EHIGHPG and EPGSUSED.
{|
|[[EHIGHPG parameter]]
|The highest active Table E page. (The first page in Table E is page zero.)
|-
|[[EPGSUSED parameter]]
|The number of Table E pages currently in use.
|-
|[[ESIZE parameter]]
|The number of pages in Table E
|-
|[[FILEORG parameter]]
|The file organisation
|}

[[Category:File architecture]]

File size calculation in detail

2013-05-07T22:15:47Z

Rob: /* Computing Table E size - ESIZE */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of either the full logical records-a base record, plus extension(s) (that contain the values of all VISIBLE fields), or if Table X is enabled, the visible fields in the base record. This section discusses Table B by itself, and the Table X impact is discussed in the next section.

Either way, to size the data are correctly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 

==Sizing Tables B and X==
===Creating a file with a Table X===
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Dividing data between Table B and X===
Obviously:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you may take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>
<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>
<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward (and if [[RECRDOPT parameter|RECRDOPT]] is set to one, then sizing of Table B is trivial (how many records do you expect to have?).

===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
The sizing of Table E varies depending on whether the FILEORG parameter|FILEORG x'100' bit is set:(</p)

==== For FILEORG parameter|FILEORG x'100' files ====
Set ESIZE as the number of Data pages.

To calculate the number of Data pages: Average the BLOB/CLOB length, divide by 6140 (The usable page size of 6144 less the 4 byte chain pointer) and round up. Then, multiply by the total number of Large Object fields (and probably add a percentage for growth (based on your knowledge of the data and application).

Additional considerations:

<ul>
<li>If you have [[#Field Design (File Management)# BLOB, CLOB and MINLOBE attributes|MINLOBE]] set, ignore large objects smaller than this number.</li>
<li>Be sure to take that (along with the large object header) into account when sizing Tables B and X.</li>
</ul>

For more detail on the large object architecture, see [[Table E FILEORG x'100' (File Architecture)|Table E for FILEORG X'100']] files.

==== For non FILEORG parameter|FILEORG x'100' files ====
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>

For more detail on the large object architecture, see [[Table E non x'100' (File Architecture)|Table E for non FILEORG X'100' files]].

===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

File size calculation in detail

2013-05-07T21:56:25Z

Rob: /* Sizing Table B */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of either the full logical records-a base record, plus extension(s) (that contain the values of all VISIBLE fields), or if Table X is enabled, the visible fields in the base record. This section discusses Table B by itself, and the Table X impact is discussed in the next section.

Either way, to size the data are correctly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 

==Sizing Tables B and X==
===Creating a file with a Table X===
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Dividing data between Table B and X===
Obviously:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you may take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>
<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>
<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward (and if [[RECRDOPT parameter|RECRDOPT]] is set to one, then sizing of Table B is trivial (how many records do you expect to have?).

===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
Formula for sizing the ESIZE parameter
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>
===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

File size calculation in detail

2013-05-07T21:51:44Z

Rob: /* Sizing Tables B and X */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of the logical records-a base record, plus extension(s) is a logical record-that contain the values of all VISIBLE fields. To set Table B parameters properly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 
==Sizing Tables B and X==
===Creating a file with a Table X===
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Dividing data between Table B and X===
Obviously:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you may take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>
<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>
<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward (and if [[RECRDOPT parameter|RECRDOPT]] is set to one, then sizing of Table B is trivial (how many records do you expect to have?).

===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
Formula for sizing the ESIZE parameter
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>
===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

Record (File architecture)

2013-05-07T21:38:47Z

Rob:

File size calculation in detail

2013-05-07T21:29:26Z

Rob: /* Creating a file with a Table X */

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of the logical records-a base record, plus extension(s) is a logical record-that contain the values of all VISIBLE fields. To set Table B parameters properly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 
==Sizing Tables B and X==
===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Table B overhead===
For files without a Table X each Table B record has five bytes of overhead made up of a 3-byte extension pointer and a 2-byte slot number. For files with XSIZE greater than 0, each Table B record has six bytes of overhead made up of a 4-byte extension number and a 2-byte slot number.
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no formula for determining a unique BSIZE or XSIZE. 
===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.
==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
Formula for sizing the ESIZE parameter
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>
===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

File sizing introduction

2013-05-07T01:30:18Z

Rob:

==Overview - Two approaches to File Sizing==
After designing the data structures you are implementing (see [[Field Design (File Architecture)|field]] [[and Repeating Field Group Design (File Management|Repeating Field Group design]]) there are two ways for a file manager to approach the calculation of file sizes:

You can take the ad-hoc approach:

* make size estimates and then iteratively load a sampling of records to verify

or, you can do a detailed analysis of the data you expect the file

Either way, there are certain decisions, notably the number of datasets, which need to be done based on the amount of data you will, eventually have to handle.

[[File Size Calculation in Detail]]
(and feildgroup) choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
When designing a file, consider starting out with a test file of only a few hundred records. This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of the logical records-a base record, plus extension(s) is a logical record-that contain the values of all VISIBLE fields. To set Table B parameters properly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 
==Sizing Tables B and X==
===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Table B overhead===
For files without a Table X each Table B record has five bytes of overhead made up of a 3-byte extension pointer and a 2-byte slot number. For files with XSIZE greater than 0, each Table B record has six bytes of overhead made up of a 4-byte extension number and a 2-byte slot number.
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no formula for determining a unique BSIZE or XSIZE. 
===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.
==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
Formula for sizing the ESIZE parameter
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>
===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Creating a file with a Table X==
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

File size calculation in detail

2013-05-07T01:26:42Z

Rob:

==Overview==
Trying to do a precise file size for a Model 204 file is difficult because:

* The flexibility of Model 204 makes the knowledge of the detail needed unlikely

* During the application design process, it is highly likely that the data structures and field attributes will change, thus making

* Model 204 performs so well that there is no advantage to having such precise sizes

Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The Detailed Design Process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of the logical records-a base record, plus extension(s) is a logical record-that contain the values of all VISIBLE fields. To set Table B parameters properly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 
==Sizing Tables B and X==
===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Table B overhead===
For files without a Table X each Table B record has five bytes of overhead made up of a 3-byte extension pointer and a 2-byte slot number. For files with XSIZE greater than 0, each Table B record has six bytes of overhead made up of a 4-byte extension number and a 2-byte slot number.
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no formula for determining a unique BSIZE or XSIZE. 
===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.
==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
Formula for sizing the ESIZE parameter
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>
===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Creating a file with a Table X==
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]

File size calculation in detail

2013-05-07T01:14:55Z

Rob: Created page with "you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is crea..."

you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 
This chapter contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
This chapter shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 File Management facility can automatically calculate file spacing allocations, as described in [[ Managing File and Table Size with FILEMGMT#File sizing overview|File sizing overview]] .
===Testing your file design===
When designing a file, consider starting out with a test file of only a few hundred records. This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 
===Using constants===
Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).
Model 204 usable page size constant
The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144

==Sizing Table A==
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>
The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.
After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.
===Computing ASTRPPG (character strings per Table A page)===
Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.
Computing L (the length of each string)
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>
Computing ASTRPPG (character strings per Table A page)
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L

The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.
===Computing ATRPG (the number of attribute pages)===
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.
ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 
ATRPG multiplier
The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 
If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or Host Language Interface call that refers to many fields. 
Note
The product of ATRPG and ASTRPPG must not exceed 4000.
===Computing FVFPG (the number of FEW-VALUED pages)===
FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.
Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 
Keeping FVFPG small
If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 
===Computing MVFPG (the number of MANY-VALUED pages)===
MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 
Examine your data to estimate the following:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.
As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.
===ASIZE (Table A size)===
ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 
==Sizing Table B==
Table B consists of the logical records-a base record, plus extension(s) is a logical record-that contain the values of all VISIBLE fields. To set Table B parameters properly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 
To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
Instructions for calculating these parameters are discussed in this section.
Estimating space for hash key files
The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the chapters on sorted and hash key files, [[ Sorted Files#Sorted Files|Sorted Files]] and [[ Hash Key Files#Hash Key Files|Hash Key Files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.
Achieving the best performance
<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.
===Storing records on Table B pages===
The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>
===Computing R (the average record size)===
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.
===Computing BRECPPG (the number of records per Table B page)===
BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R

BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.
Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>
<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.
Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described on [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>
===Computing BSIZE (Table B size)===
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG

Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 
===Computing BRESERVE (reserved Table B space)===
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 
For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.
While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>

If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.
Sizing BRESERVE to avoid extension records
If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 
For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.
Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 
==Sizing Tables B and X==
===Preallocated fields===
Preallocated fields may reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 
<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.
===Table B overhead===
For files without a Table X each Table B record has five bytes of overhead made up of a 3-byte extension pointer and a 2-byte slot number. For files with XSIZE greater than 0, each Table B record has six bytes of overhead made up of a 4-byte extension number and a 2-byte slot number.
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no formula for determining a unique BSIZE or XSIZE. 
===Table X overhead===
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There may be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it may be possible to reduce the size of record extension chains-that is, have fewer but larger extension records instead of many smaller extension records. This would potentially reduce I/O required to read in very large records, such as those with many extensions.
===Sizing tables with XSIZE greater than zero===
Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.
If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG

And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.
==Tables C and D indexing structure==
Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
The two indexes are:
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
FRV attribute entries
In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 
===Computing the file size multiplier (N)===
To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152-that is, eight times a page size of 6184). 
Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size

Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.
For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.
==Sizing Table C==
===Table C organization===
Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 
Table C property entries
The head of each chain is called the <var class="term">property entry</var>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 
For example, PROJECT, a 4-segment file, contains a field named STAGE. STAGE is defined with the KEY attribute. One of the values stored in the field STAGE is PLANNING. In the first and second segments of the PROJECT file, there are records containing the field name = value pair, STAGE = PLANNING.
Therefore, in Table C of the PROJECT file, there is a chain of three entries:
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
Storing segment and property entries
<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.
===Computing CSIZE===
The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 
Compute CSIZE as follows:
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>.
For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 
Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)

Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ul>
==Sizing Table D==
===Table D data===
Table D contains a number of different types of data. The principal types:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>
In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.
Data storage in Table D
Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 
Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.
Computing DSIZE
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

where:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
The space requirements of the principal components of Table D are discussed in the following sections.
===Calculating the size of the Ordered Index (OIT)===
About Ordered Index space
The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 
The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.
Estimating Ordered Index space (OI) for each ORDERED field
For each field in the file that has the ORDERED attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
Estimate the following numbers:
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
First estimate the average length of the distinct values stored in the ORDERED field. For numeric values of ORDERED NUMERIC fields, the average length of the numeric values is 8. Compute the following:
<var>AV</var> = estimated av.length of ORDERED values + 1
</li>
<li>Divide the ORDERED values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
One and only one record in the file.
ValA = the number of values in category A
</td>
</tr>
<tr>
<td>B</td>
<td>
More than one record in the file and in a number of records per segment less than or equal to the setting of the field's IMMED parameter. 
ValB = the number of values in category B
</td>
</tr>
<tr>
<td>C</td>
<td>
A greater number of records per segment than the setting of the field's IMMED parameter. 
ValC = the number of values in category C
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
Total length of the Ordered Index entries placed in category A is:
<var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)

<ul>
<li>Calculate category B</li>
</ul>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 
Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the IMMED parameter for that field.
The total length of the Ordered Index entries placed in category B is:
<var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))

If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.
<ul>
<li>Calculate category C</li>
</ul>
The total length of the Ordered Index entries placed in category C is:
<var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))

<ol>
<li>Calculate OIB
Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>

If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
</li>
</ol>
Note
The value calculated as OIB should roughly correspond to the value of the OINBYTES parameter after the file is fully loaded. OINBYTES is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. 
===Estimating leaf page overhead (LOa)===
To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
Calculate the expected leaf page overhead (LOe)
The amount of overhead expected on each leaf page, <var>LOe</var>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>
<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul>
<ol>
<li>Calculate the minimum leaf page overhead
To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>
<li>Estimate leaf page overhead (<var>LOa</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
<var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</li>
</ol>
===Estimating the number of required leaf pages (LP)===
The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)

Round up to the nearest integer. 
===Calculating the size of the index for each ORDERED field===
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (<var>LP</var> * 1.01) rounded up to the nearest integer

This formula assumes conservatively that the number of intermediate pages is 1% of LP. 
===Calculating the total size of the Ordered Index (OIT)===
If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn

===Computing the total index list space (IT)===
If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 
<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.
The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 
Calculating DRESERVE
Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 
The default value of DRESERVE is 15%. 
Calculating I (the index list space)
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 
Each pair placed in category <var>A</var> requires the following number of bytes:
<var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
X = 6144 * (1 - (DRESERVE / 100) )

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
A = T / X

<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
<var>T</var>' = 2 + (2 * (Number of Records Containing the Field))

If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
<var>B</var>' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
<var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'

Then, the total number of pages required is:
C = (T" / X) + B"

Thus, the amount of index list space, <var>I</var>, for each segment is:
<var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
<var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</var>

===Calculating F (the number of pages for preallocated fields)===
If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 
Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.
===Calculating P (the number of procedures)===
Procedures, described in the Rocket <var class="product">Model 204</var> User Language Manual, are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
<var>P</var> = total number of procedures

===Sizing the procedure dictionary===
Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 
Storing new procedure names
If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 
Choosing a PDSIZE
There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 
Computing PDSTRPPG
PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
<var>L</var> + 34 for a procedure
<var>L</var> + 7 for an alias

where: 
<var>L</var> is the length of the procedure or alias name. 
First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:
PDSTRPPG = 6144 / S

The default value of PDSTRPPG is 128. Its maximum is 256.
Computing PDSIZE (the size of the procedure dictionary)
The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG

PDSIZE has a default value of 3.
If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.
===Sizing the access control table (ACT)===
The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 
Determining LET (the total length of procedure class entries)
The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries

Then, compute <var>LE</var>, the length of the entries for each user class as follows:
<var>LE</var> = 4 + (2 * NPCLASS)

Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 
Then, the total length of the user class entries is:
<var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>

Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 
Determining Q (the number of pages required for the ACT)
<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144

Reorganizing the ACT
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, <var>N</var> + 1 pages are allocated from Table D, where <var>N</var> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <var>N</var> pages are released.
Note
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.
===Sizing the reserved area===
Using reserved Table D pages
<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA

Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 
In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 
For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 
When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.
The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.
Calculating DEST (estimated Table D size)
<var>DEST</var> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
<var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>

Setting DPGSRES (the size of the reserved area)
You can reset the DPGSRES parameter and VIEW it as one of the TABLES parameters. It can be set to 0, or any other value up to 32767. 
For files containing only procedures, set DPGRES to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set DPGRES low to avoid wasting Table D space. 
Calculating DPGSRES
Unless you specify some other value, the CREATE FILE command sets DPGSRES to:
DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)

That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:
If <var>DEST</var> < 1900, DPGSRES = <var>DEST</var>/50 + 2

and:
If <var>DEST</var> >= 1900, DPGSRES = 40

===Computing DSIZE===
The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES

or:
DSIZE = <var>DEST</var> + DPGSRES

You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 
==Sizing and managing Table E==
The following parameters pertain to Table E sizing:
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data. 
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>
<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG-even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data. 
Note: Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 
===Computing Table E size - ESIZE===
Formula for sizing the ESIZE parameter
Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.
To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs

<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>
<li>Calculate ESIZE
ESIZE = Data pages + bitmap pages
</li>
</ol>
===Managing Large Object data===
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an INCREASE TABLEE or DECREASE TABLEE command to change the size of Table E-subject to the standard restrictions that apply to the INCREASE and DECREASE commands.
Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files. This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.
==Compacting Table E==
===Table E compactor and TABLEE command===
<var class="product">Model 204</var> stores large objects as consecutive chunks of Table E pages. When large objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size. The COMPACTE command lets you compact Table E by grouping gaps together, thus reducing Table E fragmentation. To find usable gaps that may be compacted, the Table E map must be analyzed. 
The Table E compactor can combine orphan spaces in Table E without file reorganization and run without exclusive use of file. When processing finds a gap, the large object that follows the gap is switched with the gap. The large object moves left, concentrating objects at the beginning of Table E, while the gap moves right, concentrating free space at the end of Table E. Although a Large Object may be pointed to by one and only one record, different fields in the same record may point to different Large Objects. 
===Introducing the Large Object header===
To make the Table E compaction process work each large object starts with a header. (The object descriptor in the Table B record is not changed and the large object header length is not included in the large object descriptor length.) The large object header contains a field for the Table B record number that points to the large object-thus a backward pointer to the Table B record.
Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required. 
Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.
When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements.
The large object header has the following 4-byte entries:
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 27 bytes if preallocated, 30 bytes otherwise.
</li>
</ul>
===Considerations for compacting Table E===
Some compactions may be counter productive. For example, if a segment has 49 objects, each the size of 1000 pages, and 49 gaps of 1-2 bytes each for a total size of 152 pages, then moving 49,000 pages to reclaim a modest 152 page gap is inefficient. On the other hand for objects with average size of 1-100 pages, compacting a hundred 1-page gaps is beneficial. 
The TABLEE command, like the TABLEB command, reports Table E usage statistics: the number of gaps and total gap size. Because compaction is heavily I/O and CPU intensive, you should compact Table E only when you can expect substantial results. 
For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. 
The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.
Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:
<ul>
<li>Bitmap pages allocated one per segment are not moved, so the worst result of compaction is two gaps per segment.</li>
<li>Objects residing in more than one segment are not moved.</li>
</ul>
===Using the TABLEE and COMPACTE commands===
To effectively compact Table E, Rocket Software recommends running a TABLEE command with the SEG option, identifying segments with large number of gaps, running COMPACTE command for segments of interest, and then running another TABLEE command for compacted segments to check the results.
===COMPACTE back out and recovery===
No back out capabilities are provided for Table E compaction. 
To facilitate recovery, the compactor writes preimages of all a large object's pages that are subject to move. You may need to increase checkpoint data set size. In the worst case almost all pages in Table E may be preimaged. 
The journal data set size increase is much smaller. It writes 50 bytes per object moved. If a problem happens during compaction, base the recovery action on error messages. 
<ul>
<li>For error messages generated while analyzing Table E (messages 2809, 2810, 2818, 2819, 2821), a file must be regenerated. </li>
<li>For error messages generated while moving an object (messages 2811, 2823) a normal file recovery should be adequate. </li>
</ul>
If the problem persists, you must regenerate the file.
===COMPACTE performance===
Table E compactor processing is highly I/O and CPU intensive. When gaps combine and grow in size, it may be quite expensive to do page-by-page constraints checking. Use of EXCL option lets you avoid constraints checking, but the total file will be unavailable to other users for the duration of compaction.
===COMPACTE and checkpoint===
The COMPACTE command runs as one long transaction. After reading the MAXPR (number of pages), processing stops, the transaction ends, and a checkpoint is attempted. Also, at this time processing checks whether the user is being bumped or is exceeding limits, such as I/O or CPU slices or a higher priority user needs to run. These checks happen only after an object has been moved. If a very long-hundreds of pages-object is moved, the transaction or sub transaction checkpoint may be delayed or prevented.
==Creating a file with a Table X==
A file has Table X allocated when XSIZE greater than zero is designated at file create.
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store a/*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END

===Considerations for Table X===
If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.
You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 
When you issue a VIEW TABLES command against a file that does not have a Table X, the Table X parameters are displayed with zero values. See <var class="product">Model 204</var> Parameter and Command Reference for a description of the Table X parameters.
If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 
==Data set allocation==
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 
===Minimum number of pages required===
The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 
===Allocating disk space===
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. [[#Allocating disk space|Allocating disk space]] can help to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.
Support for FBA devices
<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.
Guidelines for allocating data sets
The space can be allocated in one or more data sets on one or more disk packs as you see fit. 
Keep the number of data sets small, if core is a problem. 
In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.
===Allocating data sets===
z/OS example
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//

The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.
If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)

z/VSE example
The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.
z/VM example
For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK

The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets. For further description of M204UTIL see the Rocket <var class="product">Model 204</var> System Manager's Guide. 
ALLOCATE control statement
The ALLOCATE control statement format is as follows:
Syntax
ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)

The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.
The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.
The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.
The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&

==Space estimation example==
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has characteristics listed in [[#Space estimation example|Space estimation example]]. 
All fields are UPDATE IN PLACE. SSN is given the CODED attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other SSN values are stored as 4-byte binary. Because only a small number of values start with a zero, SSN does not have any effect on Table A space estimates.
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
10 values.
Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
FRV or CODED values
 Field # of Values Space Overhead Total
AGE 55 2*55=110 3*55=1651 10+165=275
DEPT 10 10*10=100 3*10=3010 0+ 30=130

B = 65 V=405

Field Names
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
FULL_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td>
LAST_NAME
</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>
<tr>
<td>
SSN
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>
<tr>
<td>
AGE
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
SALARY
</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
DEPT
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<var>A = 6
D(AGE)</var> = 2 + 3 = <var>5
D(SALARY)</var> = 5 + 3 = <var>8
S</var> = 5 + 8 = <var>13
T</var> = A + B + S = 6 + 65 +13 = <var>84</var>

<var>L</var> = average length of character strings =

(V + N)/T = (405 + 191)/84 = 7.0 = 7

<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)

===Calculating ATRPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)

= 1.1 * 191/(6144 - (877 * 2) -2)

= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)

or
<var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG

= 1.1 * (6+ 13)/877

= 0.02 = <var>1</var> (rounded up)

===Calculating FVFPG===
The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)

= 1.2 * 405/(6144 - (877 * 2) -2)

= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)

or
<var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)

===Calculating MVFPG===
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1

==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48

= 140.7 = <var>141</var> (rounded up)

===Calculating BRESERVE===
BRESERVE is equal to <var>R</var>, above. Therefore:
BRESERVE = <var>R</var> = 48

===Calculating BSIZE===
<var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG

= 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)

==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144) =

90000/49152 = 1.83 = 2 (rounded up)

==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
 
===Calculating CSIZE===
CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)

which calculates out and rounds up to:
1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330

 
==Sample Table D calculations==
===Calculating Ordered Index space===
The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
Calculating total Ordered Index B-tree entry lengths
[[File:_File_Size_Calculation_2.gif]]
Calculating Ordered Index B-tree overhead
The final values for LOe, LP, and OI are rounded up.
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197

===Calculating index list space===
For this example, assume that there are 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:
<var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))

The number of category B pages required for each field is equal to the number of distinct values of that field. For each NUMERIC RANGE value, the extra number of pages required equals ten times the number of significant digits, plus two.
The following calculations use these variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
Values for segment 1
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
Calculations for segment 1
X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
<table>
<tr class="head">
<th>

Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td> </td>
<td align="right">2</td>
<td> </td>
</tr>
<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> PERS</td>
<td> </td>
<td align="right">0</td>
<td align="right">0</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td> </td>
<td align="right">1</td>
<td> </td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td> </td>
<td align="right">8</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
Calculations for segment 2
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

===Total index list space===
IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =

63 + 3 + 74 + 61 + 11 + 74 + 2 = 288

===Determining F (space required for preallocated fields)===
If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1

===Calculating space required for procedures===
The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0

===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q =

197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)

= 13 (rounded up)

===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550

==Sample Table E calculations==
Sizing Table E
You can set the ESIZE parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 
When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: EHIGHPG=16 and EPGSUSED=17.
Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.
===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
Use the following steps and formulas to determine how many Table E pages you need:
Calculate the pages-to-hold-data as:
For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data
Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data

<ol>
<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>
<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>
==Calculating sample total file size==
The total file size for this example is:
8 + ASIZE + BSIZE + CSIZE + DSIZE =

8 + 3 + 766 + 330 + 550 =

<var>1657 pages, or 237 tracks on a 3380</var>

==Space calculation worksheet==
This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144

===Calculate Table A size===
Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
L represents the length of each string
2. L = (V + N + W) / T

The ASTRPPG parameter represents the character strings per Table A page
3. ASTRPPG = 6144 / L

The ATRPG parameter represents the number of attribute pages
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)

or
ATRPG = 1.1 * (A + S) / ASTRPPG

The FVFPG parameter represents the number of FEW-VALUED pages
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

or
FVFPG= 1.2 * (B / ASTRPPG)

The MVFPG parameter represents the number of MANY-VALUED pages
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )

or
MVFPG = 1.2 * (B / ASTRPPG)

The ASIZE parameter represents the size of Table A
7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)

 
 
===Calculate Table B size===
Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>
The BRECPPG parameter represents table records per page
8. BRECPPG = 1.1 * 6140 / R

The BSIZE parameter represent the size of Table B
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space

 
===Calculate Table C size===
The N variable represents the file size multiplier
11. N = Number-of-records-in-the-file
/ (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM
RANGE retrieval fields

The CSIZE parameter represents the size of Table C
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
(VN + VR)) / 6140

 
===Calculate Table D size===
Estimate the size of the Ordered Index
Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C

ENa = The total length of the Ordered Index entries placed in category A
20. ENa = ValA * (AV + 3)

ENb = The total length of the Ordered Index entries placed in category B
21. ENb = ValB * (AV + (2 * AB) + (2 * N)

ENc = The total length of the Ordered Index entries placed in category C
22. ENc = ValC * (AV + (5 * N))

The OIB parameter represents the total length of all Ordered Index entries
23. IB = ENa + ENb + ENc =

The value of LOe represents the expected leaf page overhead 
24. LOe = 6144 * (LRESERVE / 100)

or
LOe = 6144 * ((100 - SPLITPCT) / 100)

The value of AE represents the average number of bytes per Ordered Index entry
25. AE = OIB / EN

The value of LOmin represents the minimum leaf page overhead
26. LOmin = 2 * 6144 / AE

The value of LOa represents the leaf page overhead
27. LOa = max(LOe, LOmin)

The value of LP represents the number of leaf pages required
28. LP = OIB / (6120 - LOa)

 
The value of OI represents the size of the Ordered Index for each field
29. OI = (LP * 1.01)

OIT = Total size of the Ordered Index
30. OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>

Calculate index list space
31. DRESERVE = % of space reserved for Table D expansion

The value of T represents the number of bytes required for category A fieldname = value pairs.
32. T = 2 + (2 * (no. of records with fieldname=value pair))

The value of X represents the total number of bytes available per Table D page
33. X = 6144 * (1 - (DRESERVE / 100))

The value of A represents the total number of pages required by the category A pairs for the segment
34. A = T / X

35. B = total number of pages required by pairs in category B

The value of T' represents the extra bytes required for NUMERIC RANGE fields
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'

The value of C represents the total extra pages required
40. C = (T" / X) + B

The value of I represents the index list space for each segment
41. I = A + B + C

The value of IT represents the total index list space required
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N

Calculate space for preallocated fields
43. F = number of Table D pages for preallocated fields

Calculate the size of the procedure dictionary
44. P = total number of procedures

45. S = average size of procedure entry

PDSTRPPG = the maximum number of procedure entries per procedure dictionary page
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG

Calculate the size of the ACT
The value of LE represents the length of entries for each user class
48. LE = 4 + (2 * NPCLASS)

The value of LET represents the total length of the user class entries
49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>

The value of Q represents the number of pages required for the ACT
50. Q = LET / 6144

Calculate the final size of Table D
51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q

52. If DEST < 1900, DPGSRES = DEST/50 + 2

or:
 If DEST >= 1900, DPGSRES = 40

53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:
DSIZE = DEST + DPGSRES

===Calculate the final size for Table E===
Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].
[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]
===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE

==File description worksheet==
Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model 204</var> Parameter and Command Reference.
File Description Sheet


File Name ___________________________________________

Record Security Field Name____________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________
MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________

1.
2.
3.
[[Category:File manager]]
[[Category:File management]]