File size calculation in detail: Difference between revisions

From m204wiki
Jump to navigation Jump to search
 
(123 intermediate revisions by 7 users not shown)
Line 1: Line 1:
<div class="toclimit-3">
==Overview==
==Overview==
<p>Trying to do a precise file size for a Model 204 file is difficult because:</p>
<p>
 
Trying to do a precise file size for a Model 204 file is difficult because:</p>
* The flexibility of Model 204 makes the knowledge of the detail needed unlikely
<ul>
<li>The flexibility of Model 204 makes the knowledge of the detail needed unlikely
<li>During the application design process, it is highly likely that the data structures and field attributes will change
<li>Model 204 performs so well that there is no advantage to having such precise sizes
</ul>


* During the application design process, it is highly likely that the data structures and field attributes will change, thus making
<p>
Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File sizing introduction]].</p>
<p>
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.</p>


* Model 204 performs so well that there is no advantage to having such precise sizes
==The detailed design process==
 
<p>
<p>Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File Size Calculation]].</p>
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:</p>
 
<p>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.</p>
 
 
==The Detailed Design Process==  
<p>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:</p>
<ul>
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
Line 21: Line 24:
<li>Number of records you expect to be in file</li>
<li>Number of records you expect to be in file</li>
</ul>
</ul>
<p>Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space.    </p>
<p>
<p>This chapter contains:</p>
Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space.    </p>
<p>
This topic contains:</p>
<ul>
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<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>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>Complete space estimation example using the steps shown in the first section of this topic </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
</ul>
<p>This chapter shows you how to find the total number of <var class="product">Model&nbsp;204</var> pages you need for a file, that is, to resolve the following equation:</p>
<p>
<p class="code">Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
This topic shows you how to find the total number of <var class="product">Model&nbsp;204</var> pages you need for a file, that is, to resolve the following equation:</p>
                  ESIZE + XSIZE + 8
<p class="code">Number of pages = ASIZE + BSIZE + CSIZE + DSIZE + ESIZE + XSIZE + 8
</p>
</p>
<p class="note"><b>Note:</b> The <var class="product">Model&nbsp;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]] .</p>
<p class="note"><b>Note:</b> The <var class="product">Model&nbsp;204</var> Dictionary/204 FILEMGMT subsystem facility can automatically calculate file spacing allocations, as described in [[ Managing file and table size with FILEMGMT#File sizing overview|File sizing overview]].</p>
===Testing your file design===
===Testing your file design===
<p>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. </p>
<p>
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. </p>
===Using constants===
===Using constants===
<p>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).</p>
<p>
<b>Model 204 usable page size constant</b>
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).</p>
<p>The standard <var class="product">Model&nbsp;204</var> page size is 6184 bytes. Although <var class="product">Model&nbsp;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:</p>
====Model 204 usable page size constant====
<p>
The standard <var class="product">Model&nbsp;204</var> page size is 6184 bytes. Although <var class="product">Model&nbsp;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:</p>
<p class="code">6184 - 40 = 6144
<p class="code">6184 - 40 = 6144
</p>
</p>
==Sizing Table A==
==Sizing Table A==
<p>Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:</p>
<p>
Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 49: Line 62:
<th>Contains...  </th>
<th>Contains...  </th>
</tr>
</tr>
<tr>
<tr>
<td>Attribute</td>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
<td>Field names of all fields in the file.</td>
</tr>
</tr>
<tr>
<tr>
<td>FEW-VALUED</td>
<td nowrap>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>
<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>
<tr>
<tr>
<td>MANY-VALUED</td>
<td nowrap>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>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute.    </td>
</tr>
</tr>
</table>
</table>
<p>The Table A parameters you need as part of the total <var class="product">Model&nbsp;204</var> number of pages are: </p>
<p>
The Table A parameters you need as part of the total <var class="product">Model&nbsp;204</var> number of pages are as follows: </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 68: Line 85:
<th>Specifies the number of Table A...</th>
<th>Specifies the number of Table A...</th>
</tr>
</tr>
<tr>
<tr>
<td>ATRPG</td>
<td>ATRPG</td>
<td>Attribute pages </td>
<td>Attribute pages </td>
</tr>
</tr>
<tr>
<tr>
<td>FVFPG</td>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
<td>FEW-VALUED pages</td>
</tr>
</tr>
<tr>
<tr>
<td>MVFPG</td>
<td>MVFPG</td>
Line 81: Line 101:
</tr>
</tr>
</table>
</table>
<p>ASIZE, the total size of Table A, is calculated by <var class="product">Model&nbsp;204</var>.</p>
<p>
<p>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.</p>
ASIZE, the total size of Table A, is calculated by <var class="product">Model&nbsp;204</var>.</p>
<p>
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.</p>
===Computing ASTRPPG (character strings per Table A page)===
===Computing ASTRPPG (character strings per Table A page)===
<p>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.</p>
<p>
<b>Computing L (the length of each string)</b>
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.</p>
<p>In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: </p>
====Computing L (the length of each string)====
<p>
In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: </p>
<ol>
<ol>
<li>For each CODED or FRV value, add 3 bytes.  </li>
<li>For each CODED or FRV value, add 3 bytes.  </li>
Line 97: Line 123:
<li>If the field is ORDERED, add 4 more bytes.</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 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:  
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
<p class="code">((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
<p class="code">((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</p></li>
</p></li>
Line 107: Line 133:
<th>Represents...</th>
<th>Represents...</th>
</tr>
</tr>
<tr>
<tr>
<td>A</td>
<td>A</td>
<td>Number of field names</td>
<td>Number of field names</td>
</tr>
</tr>
<tr>
<tr>
<td>B </td>
<td>B</td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
</tr>
<tr>
<tr>
<td>C  </td>
<td>C  </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
</tr>
<tr>
<tr>
<td>D </td>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
</tr>
<tr>
<tr>
<td>S  </td>
<td>S  </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
</tr>
<tr>
<tr>
<td>T </td>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
<td>Total number of strings: A + B + S + C</td>
</tr>
</tr>
<tr>
<tr>
<td>V </td>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
</tr>
<tr>
<tr>
<td>W</td>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
</tr>
<tr>
<tr>
<td>N</td>
<td>N</td>
Line 145: Line 180:
</table>
</table>
</li>
</li>
<li>Then, compute L, where:
<li>Then, compute L, where:
<p class="code">L = (V + N + W) / T
<p class="code">L = (V + N + W) / T
</p></li>
</p></li>
</ol>
</ol>
<b>Computing ASTRPPG (character strings per Table A page)</b>
<p>After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:</p>
====Computing ASTRPPG (character strings per Table A page)====
<p>
After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:</p>
<p class="code">ASTRPPG = 6144 / L
<p class="code">ASTRPPG = 6144 / L
</p>
</p>
<p>The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.</p>
<p>
The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.</p>
===Computing ATRPG (the number of attribute pages)===
===Computing ATRPG (the number of attribute pages)===
<p>ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:</p>
<p>
ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>N </td>
<td>N </td>
<td>Total amount of space consumed by field names</td>
<td>Total amount of space consumed by field names</td>
</tr>
</tr>
<tr>
<tr>
<td>A </td>
<td>A </td>
<td>Number of field names</td>
<td>Number of field names</td>
</tr>
</tr>
<tr>
<tr>
<td>S </td>
<td>S </td>
Line 174: Line 218:
</tr>
</tr>
</table>
</table>
<p>Next, compute the following equations:</p>
<p>
Next, compute the following equations:</p>
<p class="code">ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )
<p class="code">ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )
 
ATRPG = 1.1 * (A + S) / ASTRPPG
ATRPG = 1.1 * (A + S) / ASTRPPG
</p>
</p>
<p>Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.</p>
<p>
<p>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. </p>
Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.</p>
<b>ATRPG multiplier</b>
<p>
<p>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. </p>
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. </p>
<p>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. </p>
<b>Note</b>
====ATRPG multiplier====
<p>The product of ATRPG and ASTRPPG must not exceed 4000.</p>
<p>
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. </p>
<p>
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 [[Media:M204 HLIReference V75.pdf|Host Language Interface]] call that refers to many fields. </p>
<p class="note"><b>Note:</b>
The product of ATRPG and ASTRPPG must not exceed 4000.</p>
===Computing FVFPG (the number of FEW-VALUED pages)===
===Computing FVFPG (the number of FEW-VALUED pages)===
<p>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. </p>
<p>
<p>Examine your data to estimate the following:</p>
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. </p>
<p>
Examine your data to estimate the following:</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>V </td>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
</tr>
<tr>
<tr>
<td>B </td>
<td>B </td>
Line 204: Line 259:
</table>
</table>
<p class="code">FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
<p class="code">FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
 
FVFPG = 1.2 * B / ASTRPPG
FVFPG = 1.2 * B / ASTRPPG
</p>
</p>
<p>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.</p>
<p>
<p>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. </p>
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.</p>
<b>Keeping FVFPG small</b>
<p>
<p>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. </p>
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. </p>
====Keeping FVFPG small====
<p>
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. </p>
===Computing MVFPG (the number of MANY-VALUED pages)===
===Computing MVFPG (the number of MANY-VALUED pages)===
<p>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.    </p>
<p>
<p>Examine your data to estimate the following:</p>
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.    </p>
<p>
Examine your data to estimate the following:</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>W</td>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
</tr>
<tr>
<tr>
<td>C</td>
<td>C</td>
Line 229: Line 293:
</table>
</table>
<p class="code">MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
<p class="code">MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
 
MVFPG = 1.2 * B / ASTRPPG
MVFPG = 1.2 * B / ASTRPPG
</p>
</p>
<p>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.</p>
<p>
<p>As discussed in the preceding description of FVFPG, <var class="product">Model&nbsp;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.</p>
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.</p>
<p>
As discussed in the preceding description of FVFPG, <var class="product">Model&nbsp;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.</p>
===ASIZE (Table A size)===
===ASIZE (Table A size)===
<p>ASIZE is calculated by <var class="product">Model&nbsp;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.  </p>
<p>
ASIZE is calculated by <var class="product">Model&nbsp;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.  </p>
==Sizing Table B==
==Sizing Table B==
<p>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>:</p>
<p>
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.</p>
<p>
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>:</p>
<ul>
<ul>
<li>Number of fields in the average record</li>
<li>Number of fields in the average record</li>
<li>Number of records </li>
<li>Number of records </li>
</ul>
</ul>
<p>When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. </p>
<p>
<p>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:</p>
When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. </p>
<p>
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:</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>R</td>
<td>R</td>
<td>Average record size</td>
<td>Average record size</td>
</tr>
</tr>
<tr>
<tr>
<td>BRECPPG</td>
<td>BRECPPG</td>
Line 258: Line 334:
</tr>
</tr>
</table>
</table>
<p>Instructions for calculating these parameters are discussed in this section.</p>
<p>
<b>Estimating space for hash key files</b>
Instructions for calculating these parameters are discussed in this section.</p>
<p>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.</p>
<b>Achieving the best performance</b>
====Estimating space for hash key files====
<p><var class="product">Model&nbsp;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.</p>
<p>
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 pages on sorted and hash key files, [[Sorted files]] and [[Hash key files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.</p>
====Achieving the best performance====
<p>
<var class="product">Model&nbsp;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.</p>  
===Storing records on Table B pages===
===Storing records on Table B pages===
<p>The following conditions must be met before a new record is stored on a Table B page:</p>
<p>
The following conditions must be met before a new record is stored on a Table B page:</p>
<ul>
<ul>
<li>Record number must be available. </li>
<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>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>
<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>
</ul>
===Computing R (the average record size)===
===Computing R (the average record size)===
<p>Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:</p>
<p>
Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:</p>
<ol>
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<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>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>
 
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:
<ul>
<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 compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
Line 281: Line 370:
<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 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>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field.    </li>
</ul>
</ul></li>
<li>Compute the space needed for preallocated fields as follows:</li>
 
<li>Compute the space needed for preallocated fields as follows:
<ul>
<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 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>
<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>
</ul></li>
 
<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>
<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>
</ol>
<p>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.</p>
<p>
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.</p>
===Computing BRECPPG (the number of records per Table B page)===
===Computing BRECPPG (the number of records per Table B page)===
<p>BRECPPG specifies the maximum number of logical records that <var class="product">Model&nbsp;204</var> will store on one Table B page. Compute BRECPPG as follows:</p>
<p>
BRECPPG specifies the maximum number of logical records that <var class="product">Model&nbsp;204</var> will store on one Table B page. Compute BRECPPG as follows:</p>
<p class="code">BRECPPG = 1.1 * (6144 - 4) / R
<p class="code">BRECPPG = 1.1 * (6144 - 4) / R
</p>
</p>
<p>BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.</p>
<p>
<p>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&nbsp;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).  </p>
BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.</p>
<p>By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:</p>
<p>
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&nbsp;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).  </p>
<p>
By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:</p>
<ul>
<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>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.  
 
<p>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. </p>
<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.
<p>
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 in [[#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. </p>
</li>
</li>
</ul>
</ul>  
===Computing BSIZE (Table B size)===
===Computing BSIZE (Table B size)===
<p>BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: </p>
<p>
BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: </p>
<p class="code">BSIZE = 1.2 * Total-Number-of-Records / BRECPPG
<p class="code">BSIZE = 1.2 * Total-Number-of-Records / BRECPPG
</p>
</p>
<p>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.</p>
<p>
<p>BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.</p>
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.</p>
<p>BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. </p>
<p>
BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.</p>
<p>
BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. </p>
===Computing BRESERVE (reserved Table B space)===
===Computing BRESERVE (reserved Table B space)===
<p>BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model&nbsp;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). </p>
<p>
<p>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&nbsp;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.</p>
BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model&nbsp;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). </p>
<p>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:</p>
<p>
<p class="code">BRESERVE = <var>R</var>  
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&nbsp;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.</p>
<p>
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:</p>
<p class="code">BRESERVE = <var>R</var>
</p>
</p>
<p>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.</p>
<p>
<b>Sizing BRESERVE to avoid extension records</b>
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.</p>
<p>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&nbsp;204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. </p>
<p>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.</p>
====Sizing BRESERVE to avoid extension records====
<p>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.</p>
<p>
<p>The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user.  </p>
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&nbsp;204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. </p>
<p>
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.</p>
<p>
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.</p>
<p>
The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user.  </p>
==Sizing Tables B and X==
==Sizing Tables B and X==
===Creating a file with a Table X===
<p>
A file has Table X allocated when XSIZE greater than zero is designated at file create.</p>
<p>
In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. </p>
<p class="code">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 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
</p>
===Considerations for Table X===
<p>
If you want to add a Table X to a <var class="product">Model&nbsp;204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.</p>
<p>
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. </p>
<p>
When you issue a VIEW TABLES command against a file that does not have a Table X, the [[Table X (File architecture)#Parameters related to the use of Table_X|Table X parameters]] are displayed with zero values.</p>
<p>
If XAUTOINC is set to a non zero value, <var class="product">Model&nbsp;204</var> will automatically increase Table X as needed, when the file is opened by the first user. </p>
===Preallocated fields===
===Preallocated fields===
<p>Preallocated fields may reside only in Table B records. <var class="product">Model&nbsp;204</var> will never store them in Table X. </p>
<p>
<p><var class="product">Model&nbsp;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.</p>
Preallocated fields can reside only in Table B records. <var class="product">Model&nbsp;204</var> will never store them in Table X. </p>
===Table B overhead===
<p>
<p>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.</p>
<var class="product">Model&nbsp;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.</p>
===Dividing data between Tables B and X===
<p>
The requirement is simply to have enough data storage using either Table B alone or Table B and Table X:</p>
<ul>
<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 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>
<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>
</ul>
<p>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. </p>
<p>
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 can take. </p>
<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>
<p>
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 <var>[[RECRDOPT parameter|RECRDOPT]]</var> is set to one, then sizing of Table B is trivial &mdash; how many records do you expect to have?)</p>
 
===Table X overhead===
===Table X overhead===
<p>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.</p>
<p>
The purpose of Table X is to free page slots in Table B that might have been used for extension records. There could be a performance side effect with using Table X. By experimenting with different values of <var>[[XRECPPG_parameter|XRECPPG]]</var>, it might be possible to reduce the size of record extension chains: that is, have fewer but larger extension records instead of many smaller extension records. Having fewer extension records would potentially reduce I/O normally required to read in very large records, such as those with many extensions.</p>
 
===Sizing tables with XSIZE greater than zero===
===Sizing tables with XSIZE greater than zero===
<p>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.</p>
<p>
<p>If XSIZE is greater than 0, the following formula can be used to size Table B:</p>
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.</p>
<p>
If XSIZE is greater than 0, the following formula can be used to size Table B:</p>
<p class="code">BSIZE=1.2 *(total number of base records) / BRECPPG
<p class="code">BSIZE=1.2 *(total number of base records) / BRECPPG
</p>
</p>
<p>And the following formula can be used to size Table X:</p>
<p>
And the following formula can be used to size Table X:</p>
<p class="code">XSIZE=1.2 *(total number of extension records) / XRECPPG
<p class="code">XSIZE=1.2 *(total number of extension records) / XRECPPG
</p>
</p>
<p class="note"><b>Note:</b> Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.</p>
<p class="note"><b>Note:</b> Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.</p>
==Tables C and D indexing structure==
==Tables C and D indexing structure==
<p>Tables C and D comprise the indexing structure of a <var class="product">Model&nbsp;204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:</p>
<p>
Tables C and D comprise the indexing structure of a <var class="product">Model&nbsp;204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 351: Line 521:
<th>Are made for each distinct value of...    </th>
<th>Are made for each distinct value of...    </th>
</tr>
</tr>
<tr>
<tr>
<td>Table C</td>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
</tr>
<tr>
<tr>
<td>Table D</td>
<td>Table D</td>
Line 360: Line 532:
</tr>
</tr>
</table>
</table>
<p>The two indexes are:</p>
<p>
The two indexes are:</p>
<table>
<table>
<tr class="head">
<th>Hashed Index</th>
<tr>
<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>
<td>Hashed Index</td>
<td>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.</td>
</tr>
</tr>
<tr>
<tr>
<td>Ordered Index</td>
<td nowrap>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>
<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>
</tr>
</table>
</table>
<b>FRV attribute entries</b>
<p>
<p>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.  </p>
In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</p>
====FRV attribute entries====
<p>
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.  </p>
 
===Computing the file size multiplier (N)===
===Computing the file size multiplier (N)===
<p>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).  </p>
<p>
<p>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>:</p>
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 6144).  </p>
<p>
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>:</p>
<p class="code">N = Number-of-Records-in-the-File / 8 * Page-size
<p class="code">N = Number-of-Records-in-the-File / 8 * Page-size
</p>
</p>
<p>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.</p>
<p>
<p>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.</p>
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.</p>
<p>
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.</p>
 
==Sizing Table C==
==Sizing Table C==
===Table C organization===
===Table C organization===
<p>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&nbsp;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.    </p>
<p>
<b>Table C property entries</b>
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&nbsp;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.    </p>
<p>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&nbsp;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.    </p>
<p>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.</p>
====Table C property entries====
<p>Therefore, in Table C of the PROJECT file, there is a chain of three entries:</p>
<p>
The head of each chain is called the <b>property entry</b>. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model&nbsp;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.    </p>
<p>
For example, <code>PROJECT</code>, a 4-segment file, contains a field named <code>STAGE</code>. <code>STAGE</code> is defined with the <var>KEY</var> attribute. One of the values stored in the field <code>STAGE</code> is <code>PLANNING</code>. In the first and second segments of the <code>PROJECT</code> file, there are records containing the field name = value pair, <code>STAGE = PLANNING</code>.</p>
<p>
Therefore, in Table C of the <code>PROJECT</code> file, there is a chain of three entries:</p>
<ul>
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Property entry for <code>STAGE = PLANNING</code></li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the first segment of the <code>PROJECT</code> file</li>
<li>Entry for the second segment of the PROJECT file </li>
<li>Entry for the second segment of the <code>PROJECT</code> file </li>
</ul>
</ul>
<b>Storing segment and property entries</b>
 
<p><var class="product">Model&nbsp;204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model&nbsp;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.</p>
====Storing segment and property entries====
<p>
<var class="product">Model&nbsp;204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model&nbsp;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.</p>
 
===Computing CSIZE===
===Computing CSIZE===
<p>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. </p>
<p>
<p>Compute CSIZE as follows:</p>
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. </p>
<p>
Compute CSIZE as follows:</p>
<ol>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:
<ul>
<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">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>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>.  
</ul></li>
<p>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:</p>
 
</li>
<li>Then let <var>V</var><sub><i>u</i></sub> = total number of pairs in category <var class="term">u</var> and <var>V</var><sub><i>n</i></sub>= total number of pairs in category <var class="term">n</var>.
<p>
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:</p>
<ul>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<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>Multiply by 10.</li>
<li>Add 2. </li>
<li>Add 2. </li>
</ul>
</ul></li>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.  
 
<p>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>. </p>
<li>Let <var>V<sub><i>r</i></sub></var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
<p>Compute:</p>
<p>
When calculated this way, <var>V<sub><i>r</i></sub> </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>V<sub><i>r</i></sub></var> is usually unimportant because <var>V<sub><i>r</i></sub></var> is usually outweighed by <var>V<sub><i>n</i></sub></var>. </p>
<p>
Compute:</p>
<p class="code">CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)
<p class="code">CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)
</p>
</p>
<p>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.    </p>
<p>
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.    </p>
</li>
</li>
</ul>
</ol>
==Sizing Table D==
==Sizing Table D==
===Table D data===
===Table D data===
<p>Table D contains a number of different types of data. The principal types:</p>
<p>
Table D contains a number of different types of data. The principal types are:</p>
<ul>
<ul>
<li>Ordered Index B-tree pages</li>
<li>Ordered Index B-tree pages</li>
Line 431: Line 635:
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file             </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>
<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>
</ul>
<p>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.</p>
<p>
<b>Data storage in Table D</b>
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.</p>
<p>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. </p>
<p>Record list pages contain <var class="product">Model&nbsp;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&nbsp;204</var> pages where each bit on the usable page represents a single record number for a given file segment.</p>
====Data storage in Table D====
<b>Computing DSIZE</b>
<p>
<p>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:</p>
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. </p>
<p>
Record list pages contain <var class="product">Model&nbsp;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&nbsp;204</var> pages where each bit on the usable page represents a single record number for a given file segment.</p>
=====Computing DSIZE=====
<p>
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:</p>
<p class="code">DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES
<p class="code">DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES
</p>
</p>
<p>where:</p>
<p>
Where:</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>OIT </td>
<td>OIT </td>
<td>Size of the Ordered Index</td>
<td>Size of the Ordered Index</td>
</tr>
</tr>
<tr>
<tr>
<td>IT </td>
<td>IT </td>
<td>Size of index list space</td>
<td>Size of index list space</td>
</tr>
</tr>
<tr>
<tr>
<td>F </td>
<td>F </td>
<td>Number of preallocated fields</td>
<td>Number of preallocated fields</td>
</tr>
</tr>
<tr>
<tr>
<td>P </td>
<td>P </td>
<td>Number of procedures</td>
<td>Number of procedures</td>
</tr>
</tr>
<tr>
<tr>
<td>K </td>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
</tr>
<tr>
<tr>
<td>PDSIZE </td>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
<td>Size of the procedure dictionary</td>
</tr>
</tr>
<tr>
<tr>
<td>Q </td>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
</tr>
<tr>
<tr>
<td>DPGSRES </td>
<td>DPGSRES </td>
Line 481: Line 700:
</tr>
</tr>
</table>
</table>
<p>The space requirements of the principal components of Table D are discussed in the following sections.</p>
<p>
The space requirements of the principal components of Table D are discussed in the following sections.</p>
 
===Calculating the size of the Ordered Index (OIT)===
===Calculating the size of the Ordered Index (OIT)===
<b>About Ordered Index space</b>
<p>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.      </p>
====About Ordered Index space====
<p>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.</p>
<p>
<b>Estimating Ordered Index space (OI) for each ORDERED field</b>
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.      </p>
<p>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. </p>
<p>
<b>Estimate the following numbers:</b>
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.</p>
=====Estimating Ordered Index space (OI) for each ORDERED field=====
<p>
For each field in the file that has the <var>ORDERED</var> 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. </p>
<ol>
<li>Estimate the following numbers:
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>NE  </td>
<td>NE  </td>
<td>Number of distinct values (or elements) in the field</td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
</tr>
<tr>
<tr>
<td>N </td>
<td>N </td>
<td>Number of segments in the file</td>
<td>Number of segments in the file</td>
</tr>
</tr>
</table>
</table></li>
<ol>
 
<li>Estimate the average length (<var>AV</var>)
<li>Estimate the average length (<code>AV</code>).
<p>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:</p>
<p>
<p class="code"><var>AV</var> = estimated av.length of ORDERED values + 1
First estimate the average length of the distinct values stored in the <var>ORDERED</var> field. For numeric values of <var>ORDERED NUMERIC</var> fields, the average length of the numeric values is 8. Compute the following:</p>
<p class="code">AV = estimated av. length of ORDERED values + 1
</p></li>
</p></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:
 
<li>Divide the <var>ORDERED</var> values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<table>
<tr>
<tr class="head">
<td>This category</td>
<th>This category</th>
<td>Equals values that occurs in...</td>
<th>Equals values that occur in...</th>
</tr>
</tr>
<tr>
<tr>
<td>A</td>
<td>A</td>
<td>
<td>
<p>One and only one record in the file.</p>
<p>
<p>ValA  =  the number of values in category A</p>
One and only one record in the file.</p>
<p>
ValA  =  the number of values in category A</p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td>B</td>
<td>B</td>
<td>
<td>
<p>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. </p>
<p>
<p>ValB = the number of values in category B</p>
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 <var>IMMED</var> parameter. </p>
<p>
ValB = the number of values in category B</p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td>C</td>
<td>C</td>
<td>
<td>
<p>A greater number of records per segment than the setting of the field's IMMED parameter. </p>
<p>
<p>ValC = the number of values in category C</p>
A greater number of records per segment than the setting of the field's <var>IMMED</var> parameter. </p>
<p>
ValC = the number of values in category C</p>
</td>
</td>
</tr>
</tr>
</table>
</table>
</li>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
 
<li>For each category of distinct values, use the following appropriate formula:
<ul>
<ul>
<li>Calculate category A</li>
<li>Calculate category A.
</ul>
<p>
</ol>
Total length of the Ordered Index entries placed in category A is:</p>
<p>Total length of the Ordered Index entries placed in category A is:</p>
<p class="code">ENa = ValA * (AV + 3)
<p class="code"><var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)
</p>
</p>
<ul>
</li>
<li>Calculate category B</li>
 
</ul>
<li>Calculate category B.
<p>For the values in category B, first estimate the average number of records per segment that has one of the values in category B. </p>
<p>
<p>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.</p>
For the values in category B, first estimate the average number of records per segment that has one of the values in category B. </p>
<p>The total length of the Ordered Index entries placed in category B is:</p>
<p>
<p class="code"><var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))
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 <var>IMMED</var> parameter for that field.</p>
<p>
The total length of the Ordered Index entries placed in category B is:</p>
<p class="code">ENb = ValB * (AV + (2 * AB) + (2 * N))
</p>
</p>
<p>If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.</p>
<p>
<ul>
If <code>(AV + (2 + AB) + (2 * N))</code> is greater than 3000, substitute 3000.</p></li>
<li>Calculate category C</li>
 
</ul>
<li>Calculate category C.</li>
<p>The total length of the Ordered Index entries placed in category C is:</p>
<p>
<p class="code"><var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))
The total length of the Ordered Index entries placed in category C is:</p>
<p class="code">ENc = ValC * (AV + (5 * N))
</p>
</p>
<ol>
</li>
<li>Calculate OIB
</ul></li>
<p>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:</p>
 
<p class="code">OIB = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>
<li>Calculate OIB.
<p>
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:</p>
<p class="code">OIB = ENa + ENb + ENc
</p>
</p>
<p>If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.</p>
<p>
</li>
If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.</p>
<p class="note"><b>Note:</b>
The value calculated as OIB should roughly correspond to the value of the <var>[[OINBYTES parameter|OINBYTES]]</var> parameter after the file is fully loaded. <var>OINBYTES</var> is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. </p></li>
</ol>
</ol>
<b>Note</b>
 
<p>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. </p>
===Estimating leaf page overhead (LOa)===
===Estimating leaf page overhead (LOa)===
<p>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. </p>
<p>
<b>Calculate the expected leaf page overhead (LOe)</b>
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. </p>
<p>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:</p>
<ol>
<li>Calculate the expected leaf page overhead (LOe)
<p>
The amount of overhead expected on each leaf page, <code>LOe</code>, depends on the usual mode of updating used when updating the ORDERED field:</p>
<ul>
<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>:
<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>:
<p class="code">LOe = 6144 * (LRESERVE / 100)
<p class="code">LOe = 6144 * (LRESERVE / 100)</p>
</p></li>
</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>
<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>
<p class="code">LOe = 6144 *( (100 - SPLITPCT) / 100)
<p class="code">LOe = 6144 *( (100 - SPLITPCT) / 100)</p>
</p></li>
</li>
</ul>
</ul></li>
<ol>
 
<li>Calculate the minimum leaf page overhead
<li>Calculate the minimum leaf page overhead
<p>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:</p>
<p>
<p class="code">AE = DIB / NE
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:</p>
</p>
<p class="code">AE = DIB / NE</p>
<p>Then calculate <var>LOmin</var> using the following formula:</p>
<p>
<p class="code">LOmin = 2 * (6144 / AE)
Then calculate <var>LOmin</var> using the following formula:</p>
</p></li>
<p class="code">LOmin = 2 * (6144 / AE)</p>
</li>
 
<li>Estimate leaf page overhead (<var>LOa</var>)
<li>Estimate leaf page overhead (<var>LOa</var>)
<p>The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var></p>
<p>
<p class="code"><var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var></p>
<p class="code">LOa = <var class="term">max</var>(LOe, LOmin)
</p></li>
</p></li>
</ol>
</ol>
===Estimating the number of required leaf pages (LP)===
===Estimating the number of required leaf pages (LP)===
<p>The number of leaf pages required for the ORDERED field is:</p>
<p>
The number of leaf pages required for the ORDERED field is:</p>
<p class="code">LP = OIB / (6144 - 24 - LOa)
<p class="code">LP = OIB / (6144 - 24 - LOa)
</p>
</p>
<p>Round up to the nearest integer. </p>
<p>
Round up to the nearest integer. </p>
 
===Calculating the size of the index for each ORDERED field===
===Calculating the size of the index for each ORDERED field===
<p>The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:</p>
<p>
<p class="code">OI = (<var>LP</var> * 1.01) rounded up to the nearest integer  
The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:</p>
<p class="code">OI = (LP * 1.01) rounded up to the nearest integer
</p>
</p>
<p>This formula assumes conservatively that the number of intermediate pages is 1% of LP. </p>
<p>
This formula assumes conservatively that the number of intermediate pages is 1% of <code>LP</code>. </p>
 
===Calculating the total size of the Ordered Index (OIT)===
===Calculating the total size of the Ordered Index (OIT)===
<p>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.</p>
<p>
<p class="code">OIT = OI1 + OI2 + ... + OIn   
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.</p>
<p class="code">OIT = OI<sub>1</sub> + OI<sub>2</sub> + ... + OI<sub><i>n</i></sub>
</p>
</p>
===Computing the total index list space (IT)===
===Computing the total index list space (IT)===
<p>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.  </p>
<p>
<p><var class="product">Model&nbsp;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&nbsp;204</var> makes the empty page available for reuse.</p>
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.  </p>
<p>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.  </p>
<p>
<b>Calculating DRESERVE</b>
<var class="product">Model&nbsp;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&nbsp;204</var> makes the empty page available for reuse.</p>
<p>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. </p>
<p>
<p>The default value of DRESERVE is 15%. </p>
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.  </p>
<b>Calculating I (the index list space)</b>
<p>Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: </p>
====Calculating DRESERVE====
<p>
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. </p>
<p>
The default value of DRESERVE is 15%. </p>
====Calculating I (the index list space)====
<p>
Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: </p>
<ol>
<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>If <code>N</code>, 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:  
 
<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>
<table>
<tr>
<tr class="head">
<td>This category</td>
<th>This category</th>
<td>Equals. field name = value pairs that occur in...</td>
<th>Equals field name = value pairs that occur in...</th>
</tr>
</tr>
<tr>
<tr>
<td><var>A </var></td>
<td>A</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>
<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>
<tr>
<tr>
<td><var> B </var></td>
<td>B</td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</tr>
</table>
</table>
<p>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.    </p>
<p>
<p>Each pair placed in category <var>A</var> requires the following number of bytes:</p>
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. </p>
<p class="code"><var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
<p>
</p></li>
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.    </p>
</ol>
<p>
Each pair placed in category <var>A</var> requires the following number of bytes:</p>
<p class="code">T = 2 + (2 * (Number of Records Containing the Pair))
</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td><var> X</var> </td>
<td>X </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>
<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:
<p class="codeTable">X = 6144 * (1 - (DRESERVE / 100) )</p>
</td>
</tr>
</tr>
</table>
</table>
<p class="code">X = 6144 * (1 - (DRESERVE / 100) )
</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td><var>A</var> </td>
<td>A </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
<td>Total number of pages required by the category A pairs for the segment, where:
<p class="codeTable">A = T / X</p></td>
</tr>
</tr>
</table>
</table>
<p class="code">A = T / X
</p>
<table>
<table>
<tr>
<tr class="head">
<td>This value</td>
<th>This value</th>
<td>Equals...</td>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td><var>B</var> </td>
<td>B </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>
<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>
</tr>
</table>
</table>
<ol>
</li>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
 
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:
<ul>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<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>Multiply by 10.</li>
<li>Add 2. </li>
<li>Add 2. </li>
</ul>
</ul></li>
</ol>
</ol>
<p>If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:</p>
<p>
<p class="code"><var>T</var>' = 2 + (2 * (Number of Records Containing the Field))  
If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:</p>
<p class="code">T' = 2 + (2 * (Number of Records Containing the Field))
</p>
</p>
<p>If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:</p>
<p>
<p class="code"><var>B</var>' = number of extra values  
If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:</p>
<p class="code">B' = number of extra values
</p>
</p>
<p>The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:</p>
<p>
<p class="code"><var>T</var>" = sum of all the values of <var>T</var>'
The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:</p>
<var>B</var>" = sum of all the values of <var>B</var>'
<p class="code">T" = sum of all the values of <var>T</var>'
B" = sum of all the values of B'
</p>
</p>
<p>Then, the total number of pages required is:</p>
<p>
Then, the total number of pages required is:</p>
<p class="code">C = (T" / X) + B"
<p class="code">C = (T" / X) + B"
</p>
</p>
<p>Thus, the amount of index list space, <var>I</var>, for each segment is:</p>
<p>
<p class="code"><var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>
Thus, the amount of index list space, <var>I</var>, for each segment is:</p>
<p class="code">I = A + B + C
</p>
</p>
<p>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:</p>
<p>
<p class="code"><var>IT</var> = <var>A1</var> + <var>B1</var> + <var>C1</var> + ... + <var>AN</var> + <var>BN</var> + <var>CN</var> + <var>N</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:</p>
<p class="code">IT = A1 + B1 + C1 + ... + AN< + BN + CN + N
</p>
</p>
===Calculating F (the number of pages for preallocated fields)===
===Calculating F (the number of pages for preallocated fields)===
<p>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.  </p>
<p>
<p>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.</p>
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.  </p>
<p>
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.</p>
 
===Calculating P (the number of procedures)===
===Calculating P (the number of procedures)===
<p>Procedures, described in the Rocket <var class="product">Model&nbsp;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:</p>
<p>
<p class="code"><var>P</var> = total number of procedures
[[Procedures]] 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:</p>
<p class="code">P = total number of procedures
</p>
</p>
===Sizing the procedure dictionary===
===Sizing the procedure dictionary===
<p>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. </p>
<p>
<p>The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model&nbsp;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&nbsp;204</var> searches the pages in the second block, and so on. </p>
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. </p>
<b>Storing new procedure names</b>
<p>
<p>If <var class="product">Model&nbsp;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&nbsp;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. </p>
The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model&nbsp;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&nbsp;204</var> searches the pages in the second block, and so on. </p>
<b>Choosing a PDSIZE</b>
<p>There are two possible paths you can take in choosing a PDSIZE:</p>
====Storing new procedure names====
<p>
If <var class="product">Model&nbsp;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&nbsp;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. </p>
=====Choosing a PDSIZE=====
<p>
There are two possible paths you can take in choosing a PDSIZE:</p>
<ul>
<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&nbsp;204</var> might allocate a new block when space still exists on the old block.</li>
<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&nbsp;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&nbsp;204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model&nbsp;204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>
</ul>
<p>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. </p>
<p>
<b>Computing PDSTRPPG</b>
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. </p>
<p>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:</p>
<p class="code"><var>L</var> + 34  for a procedure
=====Computing PDSTRPPG=====
<var>L</var> + 7  for an alias  
<p>
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:</p>
<p class="code">L + 34  for a procedure
L + 7  for an alias
</p>
</p>
<p>where: </p>
<p>
<p><var>L</var> is the length of the procedure or alias name. </p>
Where: </p>
<p>First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:</p>
<p>
<code>L</code> is the length of the procedure or alias name. </p>
<p>
First, estimate <code>S</code>, the average entry size. Then compute <var>PDSTRPPG</var> as follows:</p>
<p class="code">PDSTRPPG = 6144 / S
<p class="code">PDSTRPPG = 6144 / S
</p>
</p>
<p>The default value of PDSTRPPG is 128. Its maximum is 256.</p>
<p>
<b>Computing PDSIZE (the size of the procedure dictionary)</b>
The default value of <var>PDSTRPPG</var> is 128. Its maximum is 256.</p>
<p>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:</p>
 
=====Computing PDSIZE (the size of the procedure dictionary)=====
<p>
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:</p>
<p class="code">PDSIZE = 1.4 * P / PDSTRPPG
<p class="code">PDSIZE = 1.4 * P / PDSTRPPG
</p>
</p>
<p>PDSIZE has a default value of 3.</p>
<p>
<p>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.</p>
PDSIZE has a default value of 3.</p>
<p>
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.</p>
===Sizing the access control table (ACT)===
===Sizing the access control table (ACT)===
<p>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&nbsp;204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five.    </p>
<p>
<b>Determining LET (the total length of procedure class entries)</b>
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&nbsp;204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five.    </p>
<p>The ACT is organized by user class in ascending order. For each user class, you need to determine:</p>
====Determining LET (the total length of procedure class entries)====
<p>
The ACT is organized by user class in ascending order. For each user class, you need to determine:</p>
<p class="code">NPCLASS = number of procedure class subentries
<p class="code">NPCLASS = number of procedure class subentries
</p>
</p>
<p>Then, compute <var>LE</var>, the length of the entries for each user class as follows:</p>
<p>
<p class="code"><var>LE</var> = 4 + (2 * NPCLASS)  
Then, compute <code>LE</code>, the length of the entries for each user class as follows:</p>
<p class="code">LE = 4 + (2 * NPCLASS)
</p>
</p>
<p>Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. </p>
<p>
<p>Then, the total length of the user class entries is:</p>
Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. </p>
<p class="code"><var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>
<p>
Then, the total length of the user class entries is:</p>
<p class="code">LET = LE<sub>1</sub> + LE<sub>2</sub> + ... + LE<sub><i>n</i></sub>
</p>
</p>
<p>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.  </p>
<p>
<b>Determining Q (the number of pages required for the ACT)</b>
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.  </p>
<p><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&nbsp;204</var>. To determine how many pages <var class="product">Model&nbsp;204</var> will probably use for the ACT: </p>
 
====Determining Q (the number of pages required for the ACT)====
<p>
<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&nbsp;204</var>. To determine how many pages <var class="product">Model&nbsp;204</var> will probably use for the ACT: </p>
<p class="code">Q = LET / 6144
<p class="code">Q = LET / 6144
</p>
</p>
<b>Reorganizing the ACT</b>
<p>If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model&nbsp;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.</p>
====Reorganizing the ACT====
<b>Note</b>
<p>
<p>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.</p>
If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model&nbsp;204</var> reorganizes the entire ACT. During this automatic reorganization, N + 1 pages are allocated from Table D, where <code>N</code> 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 <code>N</code> pages are released.</p>
<p class="note"><b>Note:</b>
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.</p>
 
===Sizing the reserved area===
===Sizing the reserved area===
<b>Using reserved Table D pages</b>
<p><var class="product">Model&nbsp;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:</p>
====Using reserved Table D pages====
<p>
<var class="product">Model&nbsp;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:</p>
<p class="code">M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA
<p class="code">M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA
</p>
</p>
<p>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.)    </p>
<p>
<p>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. </p>
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.)    </p>
<p>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.    </p>
<p>
<p>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.</p>
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. </p>
<p>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.</p>
<p>
<b>Calculating DEST (estimated Table D size)</b>
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.    </p>
<p><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:</p>
<p>
<p class="code"><var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>  
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.</p>
<p>
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.</p>
====Calculating DEST (estimated Table D size)====
<p>
<code>DEST</code> 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:</p>
<p class="code">DEST = OIT + IT + F + P + (K * PDSIZE) + Q</p>
 
====Setting DPGSRES (the size of the reserved area)====
<p>
You can reset the <var>[[DPGSRES_parameter|DPGSRES]]</var> parameter and <var>[[VIEW command|VIEW]]</var> it as one of the <var>TABLES</var> parameters. It can be set to 0, or any other value up to 32767. </p>
<p>
For files containing only procedures, set <var>DPGRES</var> to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set <var>DPGRES</var> low to avoid wasting Table D space. </p>
 
====Calculating DPGSRES====
<p>
Unless you specify some other value, the <var>[[CREATE command: File|CREATE FILE]]</var> command sets <var>DPGSRES</var> to:</p>
<p class="code">DPGSRES = <var class="term">min</var>(DEST/50 + 2, 40)
</p>
</p>
<b>Setting DPGSRES (the size of the reserved area)</b>
<p>
<p>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. </p>
That is, <var>DPGSRES</var> is either <code>(DEST/50 + 2)</code> or 40, whichever is smaller. Since
<p>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.      </p>
<code>DEST/50 + 2 = 40</code> when <code>DEST = 1900</code>:</p>
<b>Calculating DPGSRES</b>
<p class="code">If DEST &lt; 1900, DPGSRES = DEST/50 + 2
<p>Unless you specify some other value, the CREATE FILE command sets DPGSRES to:</p>
<p class="code">DPGSRES = <var class="term">min</var>(<var>DEST</var>/50 + 2, 40)
</p>
</p>
<p>That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<p>
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:</p>
and:</p>
<p class="code">If <var>DEST</var> &lt; 1900, DPGSRES = <var>DEST</var>/50 + 2
<p class="code">If DEST >= 1900, DPGSRES = 40
</p>
<p>and:</p>
<p class="code">If <var>DEST</var> >= 1900, DPGSRES = 40  
</p>
</p>
===Computing DSIZE===
===Computing DSIZE===
<p>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.</p>
<p>
<p class="code">DSIZE = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES  
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.</p>
<p class="code">DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES
</p>
</p>
<p>or:</p>
<p>
<p class="code">DSIZE = <var>DEST</var> + DPGSRES  
or:</p>
<p class="code">DSIZE = DEST + DPGSRES
</p>
</p>
<p>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.   </p>
<p>
==Sizing and managing Table E==
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. </p>
<p>The following parameters pertain to Table E sizing:</p>
 
==Sizing Table E==
<p>
The following parameters pertain to Table E sizing:</p>
<ul>
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li><var>[[ESIZE parameter|ESIZE]]</var> &mdash; 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>
<li><var>[[EHIGHPG parameter|EHIGHPG]]</var> &mdash; The highest active Table E page. The first page in Table E is page zero.</li>
 
<li><var>[[EPGSUSED_parameter|EPGSUSED]]</var> &mdash; The number of Table E pages currently in use.</li>
</ul>
</ul>
===Storing Large Object Data===
<p>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. </p>
===Storing Large Object data===
<p>
Each instance of a Large Object field occupies an integral number of Table E pages.</p>
<p>
The rules of use, and sizing, are quite different depending on whether the <var>[[FILEORG parameter|FILEORG]]</var> X'100' bit is set. For these differences, see:</p>
<p>
[[Table E (File architecture)|Table E]]</p>
<p>
[[Table E and FILEORG X'100' files (File architecture)|Table E FILEORG X'100']]</p>
<p>
[[Table E and non-FILEORG X'100' files (File architecture)|Table E non X'100']]</p>
====ESIZE for FILEORG X'100' files====
<p>
Set ESIZE as the number of Data pages.</p>
<p>
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).</p>
<p>
Additional considerations:</p>
<ul>
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>
<li>If you have <var>[[Field design#BLOB.2C CLOB.2C and MINLOBE attributes|MINLOBE]]</var> set, ignore large objects smaller than this number.</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>
<li>Be sure to take that (along with the large object header) into account when sizing Tables B and X.</li>
</ul>
</ul>
<p>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.</p>
<p>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. </p>
<p>
<p class="note"><b>Note:</b> 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. </p>
For more detail on the large object architecture, see [[Table E and FILEORG X'100' files (File architecture)|Table E for FILEORG X'100']] files.</p>
===Computing Table E size - ESIZE===
<b>Formula for sizing the ESIZE parameter</b>
====ESIZE for non FILEORG X'100' files====
<p>Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.</p>
<p>
<b>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.</b>
'''Characteristics:'''</p>
<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>
<p>
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.</p>  
<p>
If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG &mdash; 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.</p>
<p class="note"><b>Note:</b>
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. </p>  
<p>
'''Sizing:'''</p>  
<p>
Set ESIZE as the number of Data pages, plus the number of Bitmap pages plus two.</p>
<ol>
<li>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.
<p class="code">First calculation: (Avg.-BLOB-len + 6144) / 6144 = result
<p class="code">First calculation: (Avg.-BLOB-len + 6144) / 6144 = result
 
Second calculation: 1st Round up result
Second calculation: 1st Round up result
Data pages = round-up-result * No.-of-BLOBs
</p></li>


Data pages = round-up-result * No.-of-BLOBs
</p>
<ol>
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
<p class="code">17 + (Data-pages / 49152) + 1 = 2nd result
<p class="code">17 + (Data-pages / 49152) + 1 = 2nd result
 
Bitmap pages = 2nd round up result
Bitmap pages = 2nd round up result
</p></li>
</p></li>
<li>Calculate ESIZE
 
<li>Calculate ESIZE.
<p class="code">ESIZE = Data pages + bitmap pages
<p class="code">ESIZE = Data pages + bitmap pages
</p></li>
</p></li>
</ol>
</ol>
<p>
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.</p>
<p>
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.</p>
<p>
For more detail on the large object architecture, see [[Table E and non-FILEORG X'100' files (File architecture)|Table E for non FILEORG X'100' files]].</p>
===Managing Large Object data===
===Managing Large Object data===
<p>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.</p>
<p>
<p>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.</p>
If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an <code>INCREASE TABLEE</code> or <code>DECREASE TABLEE</code> command to change the size of Table E &mdash; subject to the standard restrictions that apply to the INCREASE and DECREASE commands.</p>
<p>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.</p>
 
==Compacting Table E==
===Table E compactor and TABLEE command===
<p><var class="product">Model&nbsp;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. </p>
<p>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. </p>
===Introducing the Large Object header===
<p>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.</p>
<p>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. </p>
<p class="note"><b>Note:</b> Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.</p>
<p>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.</p>
<p>The large object header has the following 4-byte entries:</p>
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
<p>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.</p>
</li>
</ul>
===Considerations for compacting Table E===
<p>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. </p>
<p>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.  </p>
<p>For files with large Table E and really large objects (thousands of pages) you must take care to prevent unnecessary page movements. </p>
<p>The compactor analyzes Table E on a segment by segment basis, where each segment represents 49,152 pages of Table E.</p>
<p>Table E contains not only object pages but bitmap pages also. The current compactor's implementation has the following limitations:</p>
<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===
<p>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.</p>
===COMPACTE back out and recovery===
<p>No back out capabilities are provided for Table E compaction. </p>
<p>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. </p>
<p>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. </p>
<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>
<p>If the problem persists, you must regenerate the file.</p>
===COMPACTE performance===
<p>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.</p>
===COMPACTE and checkpoint===
<p>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.</p>
==Data set allocation==
==Data set allocation==
<p>After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model&nbsp;204</var> file. </p>
<p>
After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model&nbsp;204</var> file. </p>
===Minimum number of pages required===
===Minimum number of pages required===
<p>The minimum number of pages required for the file is equal to:</p>
<p>
The minimum number of pages required for the file is equal to:</p>
<p class="code">8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE
<p class="code">8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE
</p>
</p>
<p>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.     </p>
<p>
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. </p>
===Allocating disk space===
===Allocating disk space===
<p>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&nbsp;204</var> stores on each track for your device type. The page size for all devices is 6184 bytes.  </p>
<p>
Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. The "Disk space requirements" table can help you to determine how many pages <var class="product">Model&nbsp;204</var> stores on each track for your device type. The page size for all devices is 6184 bytes.  </p>
<div id="Disk space requirements"></div>
<table>
<table>
<caption>Disk space requirements</caption>
<caption>Disk space requirements</caption>
Line 894: Line 1,255:
<th>Tracks/cylinder</th>
<th>Tracks/cylinder</th>
</tr>
</tr>
<tr>
<tr>
<td align="right">3330</td>
<td align="right">3330</td>
Line 899: Line 1,261:
<td align="right">19</td>
<td align="right">19</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">3340</td>
<td align="right">3340</td>
Line 904: Line 1,267:
<td align="right">12</td>
<td align="right">12</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">3350</td>
<td align="right">3350</td>
Line 909: Line 1,273:
<td align="right">30</td>
<td align="right">30</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">3375</td>
<td align="right">3375</td>
Line 914: Line 1,279:
<td align="right">12</td>
<td align="right">12</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">3380</td>
<td align="right">3380</td>
Line 919: Line 1,285:
<td align="right">15</td>
<td align="right">15</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">3390</td>
<td align="right">3390</td>
Line 924: Line 1,291:
<td align="right">15</td>
<td align="right">15</td>
</tr>
</tr>
<tr>
<tr>
<td>FACOM 6421</td>
<td>FACOM 6421</td>
Line 930: Line 1,298:
</tr>
</tr>
</table>
</table>
<p>For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.</p>
<p>
<b>Support for FBA devices</b>
For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.</p>
<p><var class="product">Model&nbsp;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.</p>
<b>Guidelines for allocating data sets</b>
====Support for FBA devices====
<p>The space can be allocated in one or more data sets on one or more disk packs as you see fit. </p>
<p>
<p>Keep the number of data sets small, if core is a problem. </p>
<var class="product">Model&nbsp;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.</p>
<p>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.</p>
====Guidelines for allocating data sets====
<p>
The space can be allocated in one or more data sets on one or more disk packs as you see fit. </p>
<p>
Keep the number of data sets small, if core is a problem. </p>
<p>
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.</p>
 
===Allocating data sets===
===Allocating data sets===
<b>z/OS example</b>
<p>To allocate z/OS data sets, use the IBM utility IEFBR14. For example:</p>
====z/OS example====
<p>
To allocate z/OS data sets, use the IBM utility IEFBR14. For example:</p>
<p class="code">//JOB IEFBR14 DELETE AND CREATE
<p class="code">//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
// SPACE=(TRK,183),UNIT=3380
//  
//
</p>
</p>
<p>The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.</p>
<p>
<p>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:</p>
The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.</p>
<p class="code">SPACE=(TRK,183,,CONTIG)  
<p>
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:</p>
<p class="code">SPACE=(TRK,183,,CONTIG)
</p>
</p>
<b>z/VSE example</b>
<p>The ALLOCATE utility provided with <var class="product">Model&nbsp;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.</p>
====z/VSE example====
<b>z/VM example</b>
<p>
<p>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:</p>
The ALLOCATE utility provided with <var class="product">Model&nbsp;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.</p>
====z/VM example====
<p>
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:</p>
<p class="code">ACCESS 201 M
<p class="code">ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK  
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK
</p>
</p>
<p>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&nbsp;204</var> System Manager's Guide.     </p>
<p>
<b>ALLOCATE control statement</b>
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.
<p>The ALLOCATE control statement format is as follows:</p>
For further description of M204UTIL, see [[Defining the runtime environment (CCAIN)]].</p>
<b>Syntax</b>
 
<p class="code">ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)  
====ALLOCATE control statement====
<p>
The ALLOCATE control statement format is as follows:</p>
<p class="syntax">ALLOCATE FILE(<span class="term">filename1</span> <span class="term">filename2</span> ... <span class="term">filenameN</span>)
</p>
</p>
<p>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.</p>
<p>
<p>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.</p>
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.</p>
<p>Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.</p>
<p>
<p>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.</p>
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.</p>
<p>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:</p>
<p>
Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.</p>
<p>
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.</p>
<p>
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:</p>
<p class="code"> // JOB ALLOCATE MODEL 204 FILE
<p class="code"> // JOB ALLOCATE MODEL 204 FILE
  // DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
  // DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
Line 977: Line 1,369:
  ALLOCATE FILE(PEOPLE)
  ALLOCATE FILE(PEOPLE)
  /*
  /*
  /&amp;  
  /&amp;
</p>
</p>
==Space estimation example==
==Space estimation example==
<p>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]].  </p>
<p>
<p>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.</p>
To perform a simple space calculation, assume that a simple personnel file of 90,000 records has the characteristics listed in the [[#Personnel file characteristics sample data|Personnel file characteristics sample data]] table.  </p>
<table>
<p>
<caption>Personnel file characteristics example</caption>
All fields are <var>UPDATE IN PLACE</var>. <code>SSN</code> is given the <var>CODED</var> attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other <code>SSN</code> values are stored as 4-byte binary. Because only a small number of values start with a zero, <code>SSN</code> does not have any effect on Table A space estimates.</p>
<div id="Personnel file characteristics sample data"></div>
<table style="width:80%">
<caption>Personnel file characteristics sample data</caption>
<tr class="head">
<tr class="head">
<th>
<th>
Line 989: Line 1,385:
<th>
<th>
Options</th>
Options</th>
<th>Average value length</th>
<th>Average <br>value <br>length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
<th>Comments on distribution of KEY and <br />NUMERIC RANGE values</th>
</tr>
</tr>
<tr>
<tr>
<td>FULL_NAME</td>
<td>FULL_NAME</td>
<td>NON-KEY
<td>NON-KEY <br />
NON-CODED</td>
NON-CODED</td>
<td align="right">20</td>
<td>20</td>
<td align="right">-</td>
<td>-</td>
</tr>
</tr>
<tr>
<tr>
<td>LAST_NAME</td>
<td>LAST_NAME</td>
<td>ORDERED CHAR
<td nowrap>ORDERED CHAR <br />
IMMED 2 LRES 15
IMMED 2 LRES 15 <br />
INVISIBLE
INVISIBLE<br />
NON-KEY</td>
NON-KEY</td>
<td align="right">11</td>
<td>11</td>
<td align="right">-</td>
<td>-</td>
</tr>
</tr>
<tr>
<tr>
<td>SSN</td>
<td>SSN</td>
<td>KEY
<td>KEY
NON-FRV
NON-FRV<br />
BINARY
BINARY<br />
CODED
CODED<br />
FEW-VALUED
FEW-VALUED
OCCURS 1</td>
OCCURS 1</td>
<td align="right">9</td>
<td>9</td>
<td>Unique to each record.</td>
<td>Unique to each record.</td>
</tr>
</tr>
<tr>
<tr>
<td>AGE</td>
<td>AGE</td>
<td>KEY
<td>KEY<br />
NUM RANGE
NUM RANGE<br />
FRV
FRV<br />
FEW-VALUED
FEW-VALUED<br />
NON-CODED
NON-CODED<br />
OCCURS 1
OCCURS 1<br />
LENGTH 2</td>
LENGTH 2</td>
<td align="right">2</td>
<td>2</td>
<td>55 possible values, evenly distributed (18-72).</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
</tr>
<tr>
<tr>
<td>SALARY</td>
<td>SALARY</td>
<td>NON-KEY
<td>NON-KEY<br />
NUM RANGE
NUM RANGE<br />
NON-CODED</td>
NON-CODED</td>
<td align="right">5</td>
<td>5</td>
<td>20,000 possible values, evenly distributed.</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
</tr>
<tr>
<tr>
<td>DEPT</td>
<td>DEPT</td>
<td>KEY
<td>KEY<br />
CODED
CODED<br />
FRV
FRV<br />
FEW-VALUED</td>
FEW-VALUED</td>
<td align="right">10</td>
<td>10</td>
<td>
<td>
<p>10 values.</p>
<p>
<p>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.</p>
10 values.</p>
<p>
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.</p>
</td>
</td>
</tr>
</tr>
</table>
</table>
==Sample Table A calculations==
==Sample Table A calculations==
===Calculating ASTRPPG===
===Calculating ASTRPPG===
<b>FRV or CODED values</b>
<table>
<p class="code"> Field # of Values Space       Overhead   Total
<caption>FRV or CODED values</caption>
AGE  55            2*55=110    3*55=1651  10+165=275
<tr class="head">
DEPT  10            10*10=100    3*10=3010  0+ 30=130
<th>Field</th>
<th># of Values</th>
<th>Space</th>
<th>Overhead</th>
<th>Total</th>
</tr>


  B = 65                                         V=405
<tr><td>AGE</td><td>55</td><td>2*55=110</td><td>3*55=165</td><td>110+165=275</td></tr>
</p>
 
<b>Field Names</b>
<tr><td>DEPT</td><td>10</td><td>10*10=100</td><td>3*10=30</td><td>100+ 30=130</td></tr>
<tr class="head"><td></td><th>B=65</th><td colspan=2></td><th>V=405</th></tr>
</table>
<br>
<table>
<table>
<caption>Field names</caption>
<tr class="head">
<tr class="head">
<th>Field</th>
<th>Field</th>
<th>LEN
<th>LEN + 2[[#fldnames-fn1|<sup>[1]</sup>]]</th>
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY + UP[[#fldnames-fn2|<sup>[2]</sup>]]</th>
<th>ANY
<th>COD/FRV</th>
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>OCC</th>
<th>LVL</th>
<th>LVL</th>
Line 1,079: Line 1,491:
<th>Total</th>
<th>Total</th>
</tr>
</tr>
<tr>
<tr>
<td>
<td>FULL_NAME</td>
<b>FULL_NAME</b>
</td>
<td align="right">9</td>
<td align="right">9</td>
<td align="right">3</td>
<td align="right">3</td>
Line 1,094: Line 1,505:
<td align="right">12</td>
<td align="right">12</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td>LAST_NAME</td>
<b>LAST_NAME</b>
</td>
<td align="right">9</td>
<td align="right">9</td>
<td align="right">3</td>
<td align="right">3</td>
Line 1,109: Line 1,519:
<td align="right">16</td>
<td align="right">16</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td>SSN</td>
<b>SSN</b>
</td>
<td align="right">5</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3[[#fldnames-fn3|<sup>[3]</sup>]]</td>
<td align="right">3</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
Line 1,124: Line 1,533:
<td align="right">11</td>
<td align="right">11</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td>AGE</td>
<b>AGE</b>
</td>
<td align="right">5</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
Line 1,139: Line 1,547:
<td align="right">49</td>
<td align="right">49</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td>SALARY</td>
<b>SALARY</b>
</td>
<td align="right">8</td>
<td align="right">8</td>
<td align="right">3</td>
<td align="right">3</td>
Line 1,154: Line 1,561:
<td align="right">91</td>
<td align="right">91</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td>DEPT</td>
<b>DEPT</b>
</td>
<td align="right">6</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
Line 1,169: Line 1,575:
<td align="right">12</td>
<td align="right">12</td>
</tr>
</tr>
<tr>
<td colspan="11">N = 191</td>
<tr class="head">
<td colspan="10"></td><th>N = 191</th>
</tr>
</tr>
</table>
</table>
<ol>
<li>LEN is the length of the field name</li>
<div id="fldnames-fn1"></div>
<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>
:<b>1</b>&nbsp;&nbsp; LEN is the length of the field name.
<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>
<p class="code"><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 =
<div id="fldnames-fn2"></div>
:<b>2</b>&nbsp;&nbsp; ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.


(V + N)/T = (405 + 191)/84 = 7.0 = 7
<div id="fldnames-fn3"></div>
:<b>3</b>&nbsp;&nbsp; Because only a small number of values in SSN start with a zero, this field does not have any effect on Table A space estimates.


<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)
<p><b>Calculations</b></p>
<p class="output"><b>A</b> <span class="squareb">=</span> <b>6</b>
<b>D(AGE)</b> <span class="squareb">=</span> 2 + 3 <span class="squareb">=</span> <b>5</b>
<b>D(SALARY)</b> <span class="squareb">=</span> 5 + 3 <span class="squareb">=</span> <b>8</b>
<b>S</b> <span class="squareb">=</span> 5 + 8 <span class="squareb">=</span> <b>13</b>
<b>T</b> <span class="squareb">=</span> A + B + S <span class="squareb">=</span> 6 + 65 + 13 <span class="squareb">=</span> <b>84</b>
<b>L</b> <span class="squareb">=</span> average length of character strings <span class="squareb">=</span> (V + N)/T <span class="squareb">=</span> (405 + 191)/84 <span class="squareb">=</span> 7.0 <span class="squareb">=</span> <b>7</b>
<b>ASTRPPG</b> <span class="squareb">=</span> 6144/L <span class="squareb">=</span> 6144/7 <span class="squareb">=</span> 877.7 <span class="squareb">=</span> <b>877</b> (rounded down)
</p>
</p>
===Calculating ATRPG===
===Calculating ATRPG===
<p>The following numbers are estimated as part of ASTRPPG:</p>
<p>
The following numbers are estimated as part of ASTRPPG:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 1,197: Line 1,609:
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>N</td>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
</tr>
<tr>
<tr>
<td>A</td>
<td>A</td>
<td>Number of field names.</td>
<td>Number of field names.</td>
</tr>
</tr>
<tr>
<tr>
<td>S</td>
<td>S</td>
Line 1,210: Line 1,625:
</tr>
</tr>
</table>
</table>
<p class="code"><var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)


= 1.1 * 191/(6144 - (877 * 2) -2)  
<p class="output"><b>ASTRPG</b> <span class="squareb">=</span> 1.1 * N/(6144 - (ASTRPPG * 2) -2)
 
      <span class="squareb">=</span> 1.1 * 191/(6144 - (877 * 2) -2)
= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)
      <span class="squareb">=</span> 1.1 * 191/4388 <span class="squareb">=</span> 0.04 <span class="squareb">=</span> <b>1</b> (rounded up)
</p>
</p>
<p>or</p>
<p>
<p class="code"><var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG
Or:</p>
 
<p class="output"><b>ASTRPG</b> <span class="squareb">=</span> 1.1 * (A + S)/ASTRPG  
= 1.1 * (6+ 13)/877
      <span class="squareb">=</span> 1.1 * (6+ 13)/877  
 
      <span class="squareb">=</span> 0.02 <span class="squareb">=</span> <b>1</b> (rounded up)
= 0.02 = <var>1</var> (rounded up)
</p>
</p>
===Calculating FVFPG===
===Calculating FVFPG===
<p>The following numbers are estimated as part of ASTRPPG:</p>
<p>
The following numbers are estimated as part of ASTRPPG:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 1,230: Line 1,645:
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>V</td>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
</tr>
<tr>
<tr>
<td>B</td>
<td>B</td>
Line 1,239: Line 1,656:
</tr>
</tr>
</table>
</table>
<p class="code"><var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)
<p class="output"><b>FVFPG</b> <span class="squareb">=</span> 1.2 * V/(6144 - (ASTRPPG * 2) -2)
 
      <span class="squareb">=</span> 1.2 * 405/(6144 - (877 * 2) -2)  
= 1.2 * 405/(6144 - (877 * 2) -2)
      <span class="squareb">=</span> 1.2 * 405/4388 <span class="squareb">=</span> 0.11 <span class="squareb">=</span> <b>1</b> (rounded up)
 
= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)
</p>
</p>
<p>or</p>
<p>
<p class="code"><var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)
Or:</p>
<p class="output"><b>FVFPG</b> <span class="squareb">=</span> 1.2 * B/ASTRPPG <span class="squareb">=</span> 1.2 * 65/877 <span class="squareb">=</span> 0.08 <span class="squareb">=</span> <b>1</b> (rounded up)
</p>
</p>
===Calculating MVFPG===
===Calculating MVFPG===
<p>There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:</p>
<p>
<p class="code"> MVFPG = 1  
There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:</p>
<p class="output"> <b>MVFPG</b> <span class="squareb">=</span> <b>1</b>
</p>
</p>
==Sample Table B calculations==
==Sample Table B calculations==
<table>
<table>
<tr class="head">
<tr class="head">
<th>Field</th>
<th>Field</th>
<th>Total bytes required per record</th>
<th>Bytes required per record</th>
</tr>
</tr>
<tr>
<tr>
<td>FULL NAME</td>
<td>FULL NAME</td>
<td align="right">23</td>
<td>23</td>
</tr>
</tr>
<tr>
<tr>
<td>SSN</td>
<td>SSN</td>
<td align="right"> 4</td>
<td> 4</td>
</tr>
</tr>
<tr>
<tr>
<td>AGE </td>
<td>AGE </td>
<td align="right"> 2</td>
<td> 2</td>
</tr>
</tr>
<tr>
<tr>
<td>SALARY</td>
<td>SALARY</td>
<td align="right"> 8</td>
<td> 8</td>
</tr>
</tr>
<tr>
<tr>
<td>DEPT</td>
<td>DEPT</td>
<td align="right"> 6</td>
<td> 6</td>
</tr>
</tr>
<tr>
<tr>
<td>Overhead</td>
<td>Overhead</td>
<td align="right"> 5</td>
<td> 5</td>
</tr>
</tr>
<tr>
<td><var>R</var> =</td>
<tr class="head">
<td align="right">48</td>
<td></td>
<th>R = 48</th>
</tr>
</tr>
</table>
</table>
===Calculating BRECPPG===
===Calculating BRECPPG===
<p class="code"><var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48
<p class="output"><b>BRECPPG</b> <span class="squareb">=</span> 1.1 * (6144 - 4)/R <span class="squareb">=</span> 1.1 * 6140/48 <span class="squareb">=</span> 140.7 <span class="squareb">=</span> <b>141</b> (rounded up)
 
= 140.7 = <var>141</var> (rounded up)
</p>
</p>
===Calculating BRESERVE===
===Calculating BRESERVE===
<p>BRESERVE is equal to <var>R</var>, above. Therefore:</p>
<p>
<p class="code">BRESERVE = <var>R</var> = 48
<var>BRESERVE</var> is equal to <code>R</code>, above. Therefore:</p>
<p class="output"><b>BRESERVE</b> <span class="squareb">=</span> R <span class="squareb">=</span> <b>48</b>
</p>
</p>
===Calculating BSIZE===
===Calculating BSIZE===
<p class="code"><var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG  
<p class="output"><b>BSIZE</b> <span class="squareb">=</span> 1.2 * (Total # of Records)/BRECPPG  
      <span class="squareb">=</span> 1.2 * 90000/141 <span class="squareb">=</span> 765.9 <span class="squareb">=</span> <b>766</b> (rounded up)
</p>


  = 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)
==Calculating the file size multiplier example==
<p class="output"><b>N</b> <span class="squareb">=</span> (# of Records in the file)/(8 * 6144)
  <span class="squareb">=</span> 90000/49152 <span class="squareb">=</span> 1.83 <span class="squareb">=</span> <b>2</b> (rounded up)
</p>
</p>
==Calculating the file size multiplier example==
<p class="code">N = (# of Records in the file)/(8 * 6144) =


90000/49152 = 1.83 = 2 (rounded up)
</p>
==Sample Table C calculations==
==Sample Table C calculations==
<table>
<table>
Line 1,314: Line 1,742:
<th>Vr entries</th>
<th>Vr entries</th>
</tr>
</tr>
<tr>
<tr>
<td>SSN</td>
<td>SSN</td>
Line 1,320: Line 1,749:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>AGE (KEY)</td>
<td>AGE (KEY)</td>
Line 1,326: Line 1,756:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td>AGE (NUM RANGE)</td>
Line 1,332: Line 1,763:
<td align="right">22</td>
<td align="right">22</td>
</tr>
</tr>
<tr>
<tr>
<td>SALARY</td>
<td>SALARY</td>
Line 1,338: Line 1,770:
<td align="right">52</td>
<td align="right">52</td>
</tr>
</tr>
<tr>
<tr>
<td>DEPT</td>
<td>DEPT</td>
Line 1,344: Line 1,777:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>TOTAL</td>
<td>TOTAL</td>
Line 1,351: Line 1,785:
</tr>
</tr>
</table>
</table>
<p>&nbsp;</p>
===Calculating CSIZE===
===Calculating CSIZE===
<p class="code">CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)
<p class="output"><b>CSIZE</b> <span class="squareb">=</span> 1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)
      <span class="squareb">=</span> 1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 <span class="squareb">=</span> <b>330</b> (rounded up)
</p>
</p>
<p>which calculates out and rounds up to:</p>
 
<p class="code">1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330
</p>
<p>&nbsp;</p>
==Sample Table D calculations==
==Sample Table D calculations==
===Calculating Ordered Index space===
===Calculating Ordered Index space===
<p>The calculations in this section use the following variables:</p>
<p>
The calculations in this section use the following variables:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 1,367: Line 1,801:
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>NE </td>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
<td>Number of distinct values stored in the field.</td>
</tr>
</tr>
<tr>
<tr>
<td>AB </td>
<td>AB </td>
<td>Average number of records per value per segment..</td>
<td>Average number of records per value per segment..</td>
</tr>
</tr>
<tr>
<tr>
<td>OIB </td>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
</tr>
<tr>
<tr>
<td>LOa </td>
<td>LOa </td>
<td>Leaf page overhead.</td>
<td>Leaf page overhead.</td>
</tr>
</tr>
<tr>
<tr>
<td>LP</td>
<td>LP</td>
<td>Leaf node pages.</td>
<td>Leaf node pages.</td>
</tr>
</tr>
<tr>
<tr>
<td>OI </td>
<td>OI </td>
Line 1,392: Line 1,832:
</tr>
</tr>
</table>
</table>
<p>&nbsp;</p>
<p>
&nbsp;</p>
<table>
<table>
<tr class="head">
<tr class="head">
<th rowspan="2">Field name</th>
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
<th colspan="3">Values in: </th>
</tr>
</tr>
<tr>
<tr>
<th>Category A</th>
<th>Category A</th>
Line 1,403: Line 1,845:
<th>Category C</th>
<th>Category C</th>
</tr>
</tr>
<tr>
<tr>
<td>LAST NAME</td>
<td>LAST NAME</td>
Line 1,410: Line 1,853:
</tr>
</tr>
</table>
</table>
<b>Calculating total Ordered Index B-tree entry lengths</b>
[[File:_File_Size_Calculation_2.gif]]
====Calculating total Ordered Index B-tree entry lengths====
<b>Calculating Ordered Index B-tree overhead</b>
<p class="output">
<p>The final values for LOe, LP, and OI are rounded up.</p>
<b>AV</b>  <span class="squareb">=</span> Average Value Length + 1 <span class="squareb">=</span> 11 + 1 <span class="squareb">=</span> <b>12</b>
<p class="code">LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922
 
<b>NE</b>  <span class="squareb">=</span> <b>65500</b>
AE = OIB / NE = 1011000 / 65500 = 15
 
<b>ENa</b> <span class="squareb">=</span> Category A * (AV + 3) <span class="squareb">=</span> 60000 * (12 + 3) <span class="squareb">=</span> <b>900000</b>
LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819
 
<b>AB</b>  <span class="squareb">=</span> <b>2</b>
LOa = max(LOe, LOmin) = max(922, 819) = 922
 
<b>ENb</b> <span class="squareb">=</span> Category B * (AV + (2 * AB) + (2 * N))  
LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195
    <span class="squareb">=</span> 5000 * (12 + (2 * 2) + (2 * 2)) <span class="squareb">=</span> <b>100000</b>
 
OI = LP * 1.01 = 195 * 1.91 = 197
<b>ENc</b> <span class="squareb">=</span> Category C * (AV + (5 * N)) <span class="squareb">=</span> 500 * (12 + (5 * 2)) <span class="squareb">=</span> <b>11000</b>
</p>
</p>
====Calculating Ordered Index B-tree overhead====
<p>
The final values for LOe, LP, and OI are rounded up:</p>
<p class="output"><b>LOe</b>  <span class="squareb">=</span> 6144 * (LRESERVE/100) <span class="squareb">=</span> 6144 * (15/100) <span class="squareb">=</span> <b>922</b>
<b>AE</b>    <span class="squareb">=</span> OIB / NE <span class="squareb">=</span> 1011000 / 65500 <span class="squareb">=</span> <b>15</b>
<b>LOmin</b> <span class="squareb">=</span> 2 * (6144 / AE) <span class="squareb">=</span> 2 * (6144 / 15) <span class="squareb">=</span> <b>819</b>
<b>LOa</b>  <span class="squareb">=</span> max(LOe, LOmin) <span class="squareb">=</span> max(922, 819) <span class="squareb">=</span> <b>922</b>
<b>LP</b>    <span class="squareb">=</span> OIB / (6144 - 24 - LOa) <span class="squareb">=</span> 1011000 / (6144 - 24 - 922) <span class="squareb">=</span> <b>195</b>
<b>OI</b>    <span class="squareb">=</span> LP * 1.01 <span class="squareb">=</span> 195 * 1.91 <span class="squareb">=</span> <b>197</b>
</p>
===Calculating index list space===
===Calculating index list space===
<p>For this example, assume that there are 2 segments containing 45,000 records each. </p>
<p>
This example assumes 2 segments containing 45,000 records each. </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 1,433: Line 1,894:
<th> It falls into category... </th>
<th> It falls into category... </th>
</tr>
</tr>
<tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
<td>A</td>
</tr>
</tr>
<tr>
<tr>
<td>More than 900 records</td>
<td>More than 900 records</td>
Line 1,442: Line 1,905:
</tr>
</tr>
</table>
</table>
<p>For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:</p>
<p>
<p class="code"><var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))  
For each value, the number of category A bytes required (<code>T'</code>) is calculated using the following equation:</p>
<p class="code"><b>T</b>'= 2 + (2 * (Number of Records Containing the Pair))
</p>
</p>
<p>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.</p>
<p>
<p>The following calculations use these variables:</p>
The number of category B pages required for each field is equal to the number of distinct values of that field. For each <var>NUMERIC RANGE</var> value, the extra number of pages required equals ten times the number of significant digits, plus two.</p>
<p>
The following calculations use these variables:</p>
<table>
<table>
<tr class="head">
<tr class="head">
<th>This value</th>
<th>Value</th>
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>T  </td>
<td>T  </td>
<td>Category A bytes.</td>
<td>Category A bytes</td>
</tr>
</tr>
<tr>
<tr>
<td>A  </td>
<td>A  </td>
<td>Total number of pages in Category A.</td>
<td>Total number of pages in Category A</td>
</tr>
</tr>
<tr>
<tr>
<td>B </td>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
<td>Total number of pages (or values) in Category B</td>
</tr>
</tr>
<tr>
<tr>
<td>C </td>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
<td>Total number of extra numeric range pages</td>
</tr>
</tr>
</table>
</table>
<b>Values for segment 1</b>
 
<table>
<table>
<caption>Values for segment 1</caption>
<tr class="head">
<tr class="head">
<th>
<th>Field name</th>
 
<th>Number <br>of distinct <br>values</th>
Field name</th>
<th>Records per <br>value</th>
<th>Number  
<th>Category A <br>bytes</th>
of distinct values</th>
<th>Category B <br>bytes</th>
<th>
<th>Extra <br>NUM RANGE<br>pages</th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
</tr>
<tr>
<tr>
<td>AGE (KEY)</td>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>55</td>
<td>818.2</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>55(2+2(818.2))</td>
Line 1,493: Line 1,959:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>AGE (NR)</td>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>55</td>
<td>818.2</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>55(2+2(818.2))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">22</td>
<td>22</td>
</tr>
</tr>
<tr>
<tr>
<td>SALARY (NR)</td>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>20000</td>
<td>2.25</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td>20000(2+2(2.25))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">52</td>
<td>52</td>
</tr>
</tr>
<tr>
<tr>
<td>LAST NAME</td>
<td>LAST NAME</td>
<td align="right">498</td>
<td>498</td>
<td>5.</td>
<td>5</td>
<td>498(2+(2*5))</td>
<td>498(2+(2*5))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>   (ORD CHAR)</td>
<td>(ORD CHAR)</td>
<td align="right">2</td>
<td>2</td>
<td>1500.</td>
<td>1500</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">2</td>
<td>2</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>DEPT</td>
<td>DEPT</td>
Line 1,533: Line 2,004:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>   PERS</td>
<td>PERS</td>
<td align="right">1</td>
<td>1</td>
<td>40000.</td>
<td>40000</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">1</td>
<td>1</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>   ACCT</td>
<td>ACCT</td>
<td align="right">0</td>
<td>0</td>
<td>0.</td>
<td>0</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>Other values</td>
<td>Other values</td>
<td align="right">8</td>
<td>8</td>
<td>625.</td>
<td>625</td>
<td>8(2+2(625))</td>
<td>8(2+2(625))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<td>&nbsp;</td>
<tr class="head">
<td>&nbsp;</td>
<td colspan=3>&nbsp;</td>
<td>&nbsp;</td>
<th><b>T1 = 326216</b></th>
<td><var>T1 = 326216</var></td>
<th><b>B1 = 3</b></th>
<td><var>B1 = 3</var></td>
<th><b>C1 = 74</b></th>
<td><var>C1 = 74</var></td>
</tr>
</tr>
</table>
</table>
<b>Calculations for segment 1</b>
<p class="code">X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B
====Calculations for segment 1====
 
<p class="output"><b>X</b> <span class="squareb">=</span> 6144 * (1-(DRESERVE / 100)) <span class="squareb">=</span> 6144 * 0.85 <span class="squareb">=</span> <b>5222</b>
A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)
<b>A<sub>1</sub></b> <span class="squareb">=</span> T<sub>1</sub> / X <span class="squareb">=</span> 326216 / 5222 <span class="squareb">=</span> <b>63</b> (Rounded up)
</p>
</p>
<b>Values for segment 2</b>
<table>
<table>
<caption>Values for segment 2</caption>
<tr class="head">
<tr class="head">
<th>
<th>Field name</th>
 
<th>Number <br>
Field name</th>
of distinct <br>values</th>
<th>Number  
<th>Records per <br>value</th>
of distinct values</th>
<th>Category A <br>bytes</th>
<th>
<th>Category B <br>bytes</th>
Records per value</th>
<th>Extra <br>NUM RANGE<br>pages</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
</tr>
<tr>
<tr>
<td>AGE (KEY)</td>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>55</td>
<td>818.2</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>55(2+2(818.2))</td>
Line 1,595: Line 2,066:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>AGE (NR)</td>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>55</td>
<td>818.2</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>55(2+2(818.2))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">22</td>
<td>22</td>
</tr>
</tr>
<tr>
<tr>
<td>SALARY</td>
<td>SALARY</td>
<td align="right">20000</td>
<td>20000</td>
<td>2.25</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td>20000(2+2(2.25))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">52</td>
<td>52</td>
</tr>
</tr>
<tr>
<tr>
<td>LAST NAME</td>
<td>LAST NAME</td>
<td align="right">498</td>
<td>498</td>
<td>5.</td>
<td>5</td>
<td>498(2+(2*5))</td>
<td>498(2+(2*5))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>   (ORD CHAR)</td>
<td>(ORD CHAR)</td>
<td align="right">2</td>
<td>2</td>
<td>1500.</td>
<td>1500</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">2</td>
<td>2</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>DEPT</td>
<td>DEPT</td>
Line 1,635: Line 2,111:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>   PERS</td>
<td>PERS</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">0</td>
<td>0</td>
<td align="right">0</td>
<td>0</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>   ACCT</td>
<td>ACCT</td>
<td align="right">1</td>
<td>1</td>
<td>10000.</td>
<td>10000</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">1</td>
<td>1</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>Other values</td>
<td>Other values</td>
<td align="right">8</td>
<td>8</td>
<td>4375.</td>
<td>4375</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">8</td>
<td>8</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<td>&nbsp;</td>
<tr class="head">
<td>&nbsp;</td>
<td colspan=3></td>
<td>&nbsp;</td>
<th>T2 = 316200</th>
<td><var>T2 = 316200</var></td>
<th>B2 = 11</th>
<td><var>B2 = 11</var></td>
<th>C2 = 74</th>
<td><var>C2 = 74</var></td>
</tr>
</tr>
</table>
</table>
<b>Calculations for segment 2</b>
<p class="code">A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)
====Calculations for segment 2====
<p class="output"><b>A<sub>2</sub></b> <span class="squareb">=</span> T<sub>1</sub> / X <span class="squareb">=</span> 316200 / 5222 <span class="squareb">=</span> 60.5 <span class="squareb">=</span> <b>61</b> (Rounded up)
</p>
</p>
===Total index list space===
===Total index list space===
<p class="code">IT = A<var>1</var> + B<var>1</var> + C1 + A<var>2</var> + B<var>2</var> + C<var>2</var> + 2 =
<p class="output"><b>IT</b> <span class="squareb">=</span> A1 + B1 + C1 + A2 + B2 + C2 + 2  
 
  <span class="squareb">=</span> 63 + 3 + 74 + 61 + 11 + 74 + 2 <span class="squareb">=</span> <b>288</b>
    63 + 3 + 74 + 61 + 11 + 74 + 2 = 288
</p>
</p>
===Determining F (space required for preallocated fields)===
===Determining F (space required for preallocated fields)===
<p>If you have defined any preallocated fields in a file, <var class="product">Model&nbsp;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):</p>
<p>
If you have defined any preallocated fields in a file, <var class="product">Model&nbsp;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):</p>
<p class="code">F = 1
<p class="code">F = 1
</p>
</p>
===Calculating space required for procedures===
===Calculating space required for procedures===
<p>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:</p>
<p>
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:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 1,687: Line 2,170:
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>P </td>
<td>P </td>
<td>Number of procedures.</td>
<td>Number of procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td>S </td>
<td>S </td>
<td>Average size of procedure entry.</td>
<td>Average size of procedure entry.</td>
</tr>
</tr>
<tr>
<tr>
<td>K </td>
<td>K </td>
<td>Number of blocks of pages.</td>
<td>Number of blocks of pages.</td>
</tr>
</tr>
<tr>
<tr>
<td>Q </td>
<td>Q </td>
Line 1,704: Line 2,191:
</tr>
</tr>
</table>
</table>
<p class="code">P = 50


S = Name length + Overhead = 20 + 34 = 54
<p class="output"><b>P</b> <span class="squareb">=</span> <b>50</b>
 
PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)
<b>S</b> <span class="squareb">=</span> Name length + Overhead <span class="squareb">=</span> 20 + 34 <span class="squareb">=</span> <b>54</b>
 
PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)
<b>PDSTRPPG</b> <span class="squareb">=</span> 6144 / s <span class="squareb">=</span> 6144 / 54 <span class="squareb">=</span> 113.7 <span class="squareb">=</span> <b>113</b> (Rounded down)
 
K = 1
<b>PDSIZE</b>  <span class="squareb">=</span> 1.4 (P/PDSTRPPG) <span class="squareb">=</span> 1.4 * (50/113) <span class="squareb">=</span> 0.61 <span class="squareb">=</span> <b>1</b> (Rounded up)
 
Q = 0
<b>K</b> <span class="squareb">=</span> <b>1</b>
<b>Q</b> <span class="squareb">=</span> <b>0</b>
</p>
</p>
===Calculating space required for reserved area===
===Calculating space required for reserved area===
<p class="code">DEST    = OIT + IT + F + P + (K * PDSIZE) + Q =  
<p class="output"><b>DEST</b>   <span class="squareb">=</span> OIT + IT + F + P + (K * PDSIZE) + Q
 
        <span class="squareb">=</span> 197 + 288 + 1 + 50 + 1 + 0 <span class="squareb">=</span> <b>537</b>
          197 + 288 + 1 + 50 + 1 + 0 = 537
 
<b>DPGSRES</b> <span class="squareb">=</span> min(DEST/50 + 2, 40) <span class="squareb">=</span> min(537/50 + 2, 40)
DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)
         <span class="squareb">=</span> <b>13</b> (rounded up)
 
         = 13 (rounded up)
</p>
</p>
===Calculating DSIZE===
===Calculating DSIZE===
<p class="code">DSIZE  =  DEST + DPGSRES = 537 + 13 = 550  
<p class="output"><b>DSIZE</b>   <span class="squareb">=</span> DEST + DPGSRES <span class="squareb">=</span> 537 + 13 <span class="squareb">=</span> <b>550</b>
</p>
</p>
==Sample Table E calculations==
==Sample Table E calculations==
<p>Sizing Table E</p>
<p>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. </p>
===Sizing Table E===
<p>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.</p>
<p>
<p>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.</p>
You can set the <var>ESIZE</var> 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. </p>
<p>
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: <code>EHIGHPG=16</code> and <code>EPGSUSED=17</code>.</p>
<p>
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.</p>
===Calculating Table E size===
===Calculating Table E size===
<ul>
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<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 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>
<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>
</ul>
<p>Use the following steps and formulas to determine how many Table E pages you need:</p>
<p>
<b>Calculate the pages-to-hold-data as:</b>
Use the following steps and formulas to determine how many Table E pages you need:</p>
<p>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</p>
<p>Example: 5,000 Large Object fields with a length of 7000:</p>
<p class="code">7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data
</p>
<ol>
<ol>
<li>Calculate the pages-to-hold-bitmaps as:
<li>
<p class="code">17 + (pages-to-hold-data /49152) + 1
Calculate the <i>pages-to-hold-data</i> as:
</p></li>
<p>
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 <i>pages-to-hold-data</i>.</p>
<p>
Example: 5,000 Large Object fields with a length of 7000:</p>
<p class="code">7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data</p>
</li>
 
<li>Calculate the <i>pages-to-hold-bitmaps</i> as:
<p class="code">17 + (pages-to-hold-data /49152) + 1</p>
</li>
 
<li>Calculate the ESIZE setting you need as:
<li>Calculate the ESIZE setting you need as:
<p class="code">pages-to-hold-data + pages-to-hold-bitmaps + 2
<p class="code">pages-to-hold-data + pages-to-hold-bitmaps + 2
</p></li>
</p></li>
</ol>
</ol>
==Calculating sample total file size==
==Calculating sample total file size==
<p>The total file size for this example is:</p>
<p>
<p class="code">8 + ASIZE + BSIZE + CSIZE + DSIZE =
The total file size for this example is:</p>
 
<p class="code"><b>File-size</b> <span class="squareb">=</span> 8 + ASIZE + BSIZE + CSIZE + DSIZE  
8 + 3 + 766 + 330 + 550 =
          <span class="squareb">=</span> 8 + 3 + 766 + 330 + 550
          <span class="squareb">=</span> <b>1657 pages</b> (237 tracks on a 3380)
</p>


<var>1657 pages, or 237 tracks on a 3380</var>
</p>
==Space calculation worksheet==
==Space calculation worksheet==
<p>This worksheet lists all the equations used in this chapter to calculate the number of pages needed for a <var class="product">Model&nbsp;204</var> file. </p>
<p>
<p class="code">1. Model 204 Usable Page Size constant = 6144
This worksheet lists all the equations used in this topic to calculate the number of pages needed for a <var class="product">Model&nbsp;204</var> file. </p>
<p class="code"><b>1.</b>  Model 204 Usable Page Size constant = 6144
</p>
</p>
===Calculate Table A size===
===Calculate Table A size===
<p>Use the following variables in Equations 2 through 6:</p>
<p>
Use the following variables in Equations 2 through 6:</p>
<table>
<table>
<tr class="head">
<tr class="head">
<th>This value</th>
<th>Value</th>
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>A</td>
<td>A</td>
<td>Number of field names. </td>
<td>Number of field names. </td>
</tr>
</tr>
<tr>
<tr>
<td>B </td>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
</tr>
<tr>
<tr>
<td>C </td>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
</tr>
<tr>
<tr>
<td>D </td>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
</tr>
<tr>
<tr>
<td>S</td>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
</tr>
<tr>
<tr>
<td>T </td>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
</tr>
<tr>
<tr>
<td>V </td>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
</tr>
<tr>
<tr>
<td>W</td>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
</tr>
<tr>
<tr>
<td>N </td>
<td>N </td>
Line 1,809: Line 2,324:
</tr>
</tr>
</table>
</table>
<p>L represents the length of each string</p>
 
<p class="code">2. L = (V + N + W) / T
<ul>
<li>L represents the length of each string:
<p class="code"><b>2.</b>  L = (V + N + W) / T
</p></li>
 
<li>The ASTRPPG parameter represents the character strings per Table A page:
<p class="code"><b>3.</b>  ASTRPPG = 6144 / L </p>
</li>
 
<li>The ATRPG parameter represents the number of attribute pages:
<p class="code"><b>4.</b>  ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)
</p>
</p>
<p>The ASTRPPG parameter represents the character strings per Table A page</p>
<p>
<p class="code">3. ASTRPPG = 6144 / L
or</p>
</p>
<p>The ATRPG parameter represents the number of attribute pages</p>
<p class="code">4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)
</p>
<p>or</p>
<p class="code">ATRPG = 1.1 * (A + S) / ASTRPPG
<p class="code">ATRPG = 1.1 * (A + S) / ASTRPPG
</p></li>
<li>The FVFPG parameter represents the number of FEW-VALUED pages:
<p class="code"><b>5.</b>  FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
</p>
</p>
<p>The FVFPG parameter represents the number of FEW-VALUED pages</p>
<p>
<p class="code">5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
or</p>
</p>
<p>or</p>
<p class="code">FVFPG= 1.2 * (B / ASTRPPG)
<p class="code">FVFPG= 1.2 * (B / ASTRPPG)
</p></li>
<li>The MVFPG parameter represents the number of MANY-VALUED pages:
<p class="code"><b>6.</b>  MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )
</p>
</p>
<p>The MVFPG parameter represents the number of MANY-VALUED pages</p>
<p>
<p class="code">6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )
or</p>
</p>
<p>or</p>
<p class="code">MVFPG = 1.2 * (B / ASTRPPG)
<p class="code">MVFPG = 1.2 * (B / ASTRPPG)
</p>
</p></li>
<p>The ASIZE parameter represents the size of Table A</p>
 
<p class="code">7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)
<li>The ASIZE parameter represents the size of Table A:
</p>
<p class="code"><b>7.</b>  ASIZE = ATRPG + FVFPG + MVFPG (calculated by Model 204)
<p>&nbsp;</p>
</p></li>
<p>&nbsp;</p>
</ul>  
===Calculate Table B size===
===Calculate Table B size===
<p>Use the following variable in Equations 8 through 10:</p>
<p>
Use the following variable in Equations 8 through 10:</p>
<table>
<table>
<tr class="head">
<tr class="head">
<th>This value</th>
<th>Value</th>
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>R</td>
<td>R</td>
Line 1,850: Line 2,377:
</tr>
</tr>
</table>
</table>
<p>The BRECPPG parameter represents table records per page</p>
<p class="code">8. BRECPPG = 1.1 * 6140 / R
</p>
<p>The BSIZE parameter represent the size of Table B</p>
<p class="code">9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)


10. BRESERVE = Reserved Table B space
<ul>
</p>
<li>The BRECPPG parameter represents table records per page:
<p>&nbsp;</p>
<p class="code"><b>8.</b>  BRECPPG = 1.1 * 6140 / R
</p></li>
 
<li>The BSIZE parameter represents the size of Table B:
<p class="code"><b>9.</b>  BSIZE = 1.2 * (Total-number-of-records / BRECPPG)
<b>10.</b> BRESERVE = Reserved Table B space
</p></li>
</ul>
===Calculate Table C size===
===Calculate Table C size===
<p>The N variable represents the file size multiplier</p>
<ul>
<p class="code">11. N = Number-of-records-in-the-file  
<li>The N variable represents the file size multiplier:
        / (8 * Page-size)
<p class="code"><b>11.</b> N = Number-of-records-in-the-file / (8 * Page-size)
<b>12.</b> V<sub>U</sub> = total number of pairs in category U
<b>13.</b> V<sub>N</sub> = total number of pairs in category N
<b>14.</b> V<sub>R</sub> = total number of extra entries for all NUM RANGE retrieval fields
</p></li>


12. VU = total number of pairs in category U
<li>The CSIZE parameter represents the size of Table C:
 
<p class="code"><b>15.</b> CSIZE = 1.2 * ((14 * V<sub>U</sub>) + 7 * (N+1)(V<sub>N</sub> + V<sub>R</sub>)) / 6140
13. VN = total number of pairs in category N
</p></li>
 
</ul>
14. VR = total number of extra entries for all NUM
        RANGE retrieval fields
</p>
<p>The CSIZE parameter represents the size of Table C</p>
<p class="code">15. CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)
    (VN + VR)) / 6140
</p>
<p>&nbsp;</p>
===Calculate Table D size===
===Calculate Table D size===
<b>Estimate the size of the Ordered Index</b>
<p>Use the following variables in Equations 16 through 24:</p>
====Estimate the size of the Ordered Index====
<ul>
<li>Use the following variables in Equations 16 through 24:  
<table>
<table>
<tr class="head">
<tr class="head">
<th>This value</th>
<th>Value</th>
<th>Equals...</th>
<th>Equals...</th>
</tr>
</tr>
<tr>
<tr>
<td>NE</td>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
</tr>
<tr>
<tr>
<td>N</td>
<td>N</td>
Line 1,893: Line 2,428:
</tr>
</tr>
</table>
</table>
<p class="code">16.  AV = the estimated av. length of ORDERED values + 1


17.  ValA = number of values in Category A
<p class="code"><b>16.</b>  AV = the estimated av. length of ORDERED values + 1
<b>17.</b> ValA = number of values in Category A
<b>18.</b>  ValB = number of values in Category B
<b>19.</b>  ValC = number of values in Category C
</p></li>
 
<li>ENa = The total length of the Ordered Index entries placed in category A:
<p class="code"><b>20.</b>  ENa = ValA * (AV + 3)
</p></li>


18.  ValB = number of values in Category B
<li>ENb = The total length of the Ordered Index entries placed in category B:
<p class="code"><b>21.</b>  ENb = ValB * (AV + (2 * AB) + (2 * N)
</p></li>


19.  ValC = number of values in Category C
<li>ENc = The total length of the Ordered Index entries placed in category C:
</p>
<p class="code"><b>22.</b> ENc = ValC * (AV + (5 * N))
<p>ENa = The total length of the Ordered Index entries placed in category A</p>
</p></li>
<p class="code">20ENa = ValA * (AV + 3)
 
</p>
<li>The OIB parameter represents the total length of all Ordered Index entries:
<p>ENb = The total length of the Ordered Index entries placed in category B</p>
<p class="code"><b>23.</b> IB = ENa + ENb + ENc =
<p class="code">21ENb = ValB * (AV + (2 * AB) + (2 * N)
</p></li>
</p>
 
<p>ENc = The total length of the Ordered Index entries placed in category C</p>
<li>The value of LOe represents the expected leaf page overhead:
<p class="code">22. ENc = ValC * (AV + (5 * N))
<p class="code"><b>24.</b> LOe = 6144 * (LRESERVE / 100)
</p>
</p>
<p>The OIB parameter represents the total length of all Ordered Index entries</p>
<p>
<p class="code">23.  IB = ENa + ENb + ENc =
Or:</p>
</p>
<p>The value of LOe represents the expected leaf page overhead </p>
<p class="code">24. LOe = 6144 * (LRESERVE / 100)
</p>
<p>or</p>
<p class="code">LOe = 6144 * ((100 - SPLITPCT) / 100)
<p class="code">LOe = 6144 * ((100 - SPLITPCT) / 100)
</p>
</p></li>
<p>The value of AE represents the average number of bytes per Ordered Index entry</p>
 
<p class="code">25. AE = OIB / EN
<li>The value of AE represents the average number of bytes per Ordered Index entry:
</p>
<p class="code"><b>25.</b> AE = OIB / EN
<p>The value of LOmin represents the minimum leaf page overhead</p>
</p></li>
<p class="code">26. LOmin = 2 * 6144 / AE
</p>
<p>The value of LOa represents the leaf page overhead</p>
<p class="code">27.  LOa = max(LOe, LOmin)
</p>
<p>The value of LP represents the number of leaf pages required</p>
<p class="code">28. LP = OIB / (6120 - LOa)
</p>
<p>&nbsp;</p>
<p>The value of OI represents the size of the Ordered Index for each field</p>
<p class="code">29.  OI = (LP * 1.01)
</p>
<p>OIT = Total size of the Ordered Index</p>
<p class="code">30.  OIT = OI<var>1</var> + OI<var>2</var> + ... + OI<var class="term">n </var>
</p>
<b>Calculate index list space</b>
<p class="code">31.  DRESERVE = % of space reserved for Table D expansion
</p>
<p>The value of T represents the number of bytes required for category A fieldname = value pairs.</p>
<p class="code">32. T = 2 + (2 * (no. of records with fieldname=value pair))
</p>
<p>The value of X represents the total number of bytes available per Table D page</p>
<p class="code">33. X = 6144 * (1 - (DRESERVE / 100))
</p>
<p>The value of A represents the total number of pages required by the category A pairs for the segment</p>
<p class="code">34. A = T / X


35. B = total number of pages required by pairs in category B
<li>The value of LOmin represents the minimum leaf page overhead:
</p>
<p class="code"><b>26.</b> LOmin = 2 * 6144 / AE
<p>The value of T' represents the extra bytes required for NUMERIC RANGE fields</p>
</p></li>
<p class="code">36. T' = 2 + (2 * (Number of Records Containing the Field))


37. B' = number of extra values
<li>The value of LOa represents the leaf page overhead:
<p class="code"><b>27.</b> LOa = max(LOe, LOmin)
</p></li>


38. T" = sum of all values of T'
<li>The value of LP represents the number of leaf pages required:
<p class="code"><b>28.</b> LP = OIB / (6120 - LOa)
</p></li>


39.  B" = sum of all values of B'
<li>The value of OI represents the size of the Ordered Index for each field:
</p>
<p class="code"><b>29.</b> OI = (LP * 1.01)
<p>The value of C represents the total extra pages required</p>
</p></li>
<p class="code">40. C = (T" / X) + B
</p>
<p>The value of I represents the index list space for each segment</p>
<p class="code">41.  I = A + B + C
</p>
<p>The value of IT represents the total index list space required</p>
<p class="code">42.  IT = A1 + B1 + C1 + ... + An + Bn + Cn + N
</p>
<b>Calculate space for preallocated fields</b>
<p class="code">43. F = number of Table D pages for preallocated fields
</p>
<b>Calculate the size of the procedure dictionary</b>
<p class="code">44.  P = total number of procedures


45.  S = average size of procedure entry
<li>OIT = Total size of the Ordered Index:
</p>
<p class="code"><b>30.</b> OIT = OI<sub>1</sub> + OI<sub>2</sub> + ... + OI<var class="term"><sub>n</sub> </var>
<p>PDSTRPPG = the maximum number of procedure entries per procedure dictionary page</p>
</p></li>
<p class="code">46. PDSTRPPG = 6144 / S
</ul>


47. PDSIZE = 1.4 * P / PDSTRPPG
====Calculate index list space====
:<p class="code"><b>31.</b> DRESERVE = % of space reserved for Table D expansion
</p>
</p>
<b>Calculate the size of the ACT</b>
<ul>
<p>The value of LE represents the length of entries for each user class</p>
<li>The value of T represents the number of bytes required for category A fieldname = value pairs:
<p class="code">48. LE = 4 + (2 * NPCLASS)
<p class="code"><b>32.</b> T = 2 + (2 * (no. of records with fieldname=value pair))
</p>
</p></li>
<p>The value of LET represents the total length of the user class entries</p>
 
<p class="code">49. LET = LE<var>1</var> + LE<var>2</var> + ... + LE<var class="term">n</var>
<li>The value of X represents the total number of bytes available per Table D page:
</p>
<p class="code"><b>33.</b> X = 6144 * (1 - (DRESERVE / 100))
<p>The value of Q represents the number of pages required for the ACT</p>
</p></li>
<p class="code">50. Q = LET / 6144
 
</p>
<li>The value of A represents the total number of pages required by the category A pairs for the segment:
<b>Calculate the final size of Table D</b>
<p class="code"><b>34.</b> A = T / X
<p class="code">51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q
 
<b>35.</b> B = total number of pages required by pairs in category B
52. If DEST &lt; 1900, DPGSRES = DEST/50 + 2
</p></li>
</p>
 
<p>or:</p>
<li>The value of T' represents the extra bytes required for NUMERIC RANGE fields:
<p class="code">     If DEST >= 1900, DPGSRES = 40
<p class="code"><b>36.</b> T' = 2 + (2 * (Number of Records Containing the Field))
 
53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES  
<b>37.</b> B' = number of extra values
</p>
<p>or:</p>
<b>38.</b> T" = sum of all values of T'
<p class="code">DSIZE = DEST + DPGSRES
</p>
<b>39.</b> B" = sum of all values of B'
===Calculate the final size for Table E===
</p></li>
<p>Calculate ESIZE, EHIGHPG, and EPGSUSED as described in [[#Sizing and managing Table E|Sizing and managing Table E]].</p>
 
<p>[!!!NEED SPECIFICS, AS FOR OTHER TABLES!!!]</p>
<li>The value of C represents the total extra pages required:
===Calculate the total pages required===
<p class="code"><b>40.</b> C = (T" / X) + B
<p class="code">Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE  
</p></li>
</p>
 
==File description worksheet==
<li>The value of I represents the index list space for each segment:
<p>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&nbsp;204</var> Parameter and Command Reference.</p>
<p class="code"><b>41.</b> I = A + B + C
<b>File Description Sheet</b>
</p></li>
<p class="code">  
 
 
<li>The value of IT represents the total index list space required:
File Name  ___________________________________________
<p class="code"><b>42.</b> IT = A1 + B1 + C1 + ... + An + Bn + Cn + N
 
</p></li>
Record Security Field Name____________________________
</ul>
 
Sort/Hash Key Field Name _____________________________
====Calculate space for preallocated fields====
 
:<p class="code"><b>43.</b> F = number of Table D pages for preallocated fields
   
</p>
 
Parameter    Value            Parameter    Value
====Calculate the size of the procedure dictionary====
 
:<p class="code"><b>44.</b> P = total number of procedures
FILEORG      ____________    CSIZE        ____________
</p>
FOPT        ____________    DRESERVE    ____________
FRCVOPT      ____________    DPGSRES      ____________
:<p class="code"><b>45.</b> S = average size of procedure entry
ASTRPPG      ____________    PDSIZE      ____________
</p>
ATRPG        ____________    PDSTRPPG    ____________
 
FVFPG        ____________    DSIZE        ____________
<ul>
MVFPG        ____________    DAUTOINC    ____________
<li>PDSTRPPG = the maximum number of procedure entries per procedure dictionary page:
<p class="code"><b>46.</b> PDSTRPPG = 6144 / S
<b>47.</b> PDSIZE = 1.4 * P / PDSTRPPG
</p></li>
</ul>
====Calculate the size of the ACT====
<ul>
<li>The value of LE represents the length of entries for each user class:
<p class="code"><b>48.</b> LE = 4 + (2 * NPCLASS)
</p></li>
 
<li>The value of LET represents the total length of the user class entries:
<p class="code"><b>49.</b> LET = LE<sub>1</sub> + LE<sub>2</sub> + ... + LE<var class="term"><sub>n</sub></var>
</p></li>
 
<li>The value of Q represents the number of pages required for the ACT:
<p class="code"><b>50.</b> Q = LET / 6144
</p></li>
</ul>
====Calculate the final size of Table D====
:<p class="code"><b>51.</b> DEST = OIT + IT + F + P + (K * PDSIZE) + Q
</p>
:<p class="code"><b>52.</b> If DEST &lt; 1900, DPGSRES = DEST/50 + 2
</p>
 
:Or, if <code>DEST >= 1900</code> and <code>DPGSRES = 40</code>:
:<p class="code"><b>53.</b> DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES
</p>
:or:
:<p class="code">DSIZE = DEST + DPGSRES
</p>
===Calculate the final size for Table E===
<p>
Calculate <var>ESIZE</var>, <var>EHIGHPG</var>, and <var>EPGSUSED</var> as described above in [[#Sizing Table E|Sizing Table E]].</p>
===Calculate the total pages required===
<p class="code">Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE
</p>
 
==File description worksheet==
<p>
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 topic.
Other parameters are discussed in their [[List of Model 204 parameters#List of parameters|individual M204wiki pages]].</p>
<p class="caption" style="text-align:left; margin-left:12em">File Description Sheet</p>
<p class="code" style="width:60%">
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      ____________
OPENCTL      ____________
BRECPPG      ____________    PRIVDEF      ____________
BRECPPG      ____________    PRIVDEF      ____________
Line 2,045: Line 2,620:
BRLIMSZ      ____________    XSIZE        ____________
BRLIMSZ      ____________    XSIZE        ____________
RECROPT      ____________    XAUTOINC    ____________
RECROPT      ____________    XAUTOINC    ____________
</p>
</p>
<p>1.</p>
<p>2.</p>
</div> <!-- end of toclimit div -->
<p>3.</p>
 
[[Category:File manager]]
[[Category:Model 204 files]]
[[Category:File management]]

Latest revision as of 22:06, 11 June 2024

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
  • 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 sizing introduction.

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:

  • Types of fields in the input data for the file (such as ORDERED or FRV)
  • Number of fields that the average record contains
  • Number of records you expect to be in file

Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space.

This topic contains:

  • Detailed instructions to help you calculate the file parameters and disk space
  • Information about allocating disk space for your operating system
  • Complete space estimation example using the steps shown in the first section of this topic
  • Space calculation and file parameter worksheets to help you calculate file sizes for your data.

This topic shows you how to find the total number of Model 204 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 Model 204 Dictionary/204 FILEMGMT subsystem facility can automatically calculate file spacing allocations, as described in 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 Model 204 page size is 6184 bytes. Although Model 204 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:

This section Contains...
Attribute Field names of all fields in the file.
FEW-VALUED 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.
MANY-VALUED Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute.

The Table A parameters you need as part of the total Model 204 number of pages are as follows:

This attribute Specifies the number of Table A...
ATRPG Attribute pages
FVFPG FEW-VALUED pages
MVFPG MANY-VALUED pages

ASIZE, the total size of Table A, is calculated by Model 204.

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:

  1. For each CODED or FRV value, add 3 bytes.
  2. For each field name, regardless of attributes, add 2 bytes. In addition:
    • If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED.
    • If the field is OCCURS, add 2 more bytes.
    • If the field is LEVEL, add 1 more byte.
    • If the field is FLOAT, add 1 more byte.
    • If the field is ORDERED, add 4 more bytes.
    • If the field is UNIQUE, add 1 more byte.
    • 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

  3. Next, examine the data to estimate the following:
    This value Represents...
    A Number of field names
    B Number of FEW-VALUED FRV or FEW-VALUED CODED values
    C Number of MANY-VALUED FRV or MANY-VALUED CODED values
    D Maximum number of digits in a NUM RANGE field + 3
    S Sum of all D's for all NUMERIC RANGE fields
    T Total number of strings: A + B + S + C
    V Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead
    W Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead
    N Space needed by field names and names overhead
  4. Then, compute L, where:

    L = (V + N + W) / T

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:

This value Equals...
N Total amount of space consumed by field names
A Number of field names
S Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)

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 larger 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:

This value Equals...
V Total amount of space consumed by FEW-VALUED fields.
B Number of FEW-VALUED values (as computed for ASTRPPG).

FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2) FVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the larger 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:

This value Equals...
W Total amount of space consumed by MANY-VALUED fields
C Number of MANY-VALUED values (as computed for ASTRPPG)

MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2) MVFPG = 1.2 * B / ASTRPPG

Round up to the nearest integer and use the larger 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, Model 204 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 Model 204 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, for each record type in the file:

  • Number of fields in the average record
  • Number of records

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:

This value Equals...
R Average record size
BRECPPG Number of records per Table B page

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 pages on sorted and hash key files, Sorted files and Hash key files, respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.

Achieving the best performance

Model 204 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:

  • Record number must be available.
  • 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.
  • If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space.

Computing R (the average record size)

Before calculating BSIZE, you need to compute R, the Table B space required for the average record, according to these rules:

  1. Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).
  2. Ignore any field that has the INVISIBLE attribute.
  3. Compute the space needed for non-preallocated fields (fields that do not have an OCCURS clause) as follows:
    • For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.
    • For each occurrence of each CODED field, add six bytes.
    • For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field.
    • For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field.
  4. Compute the space needed for preallocated fields as follows:
    • For each CODED or BINARY field, add (4 * n) bytes, where n is the number of occurrences.
    • For each field defined with the LENGTH option (including FLOAT fields), add (m * n) bytes, where m is the length and n is the number of occurrences.
  5. 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.

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 Model 204 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 Model 204 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:

  • One or more extension records per page might be created. Extension records are described on Computing BRESERVE (reserved Table B space), the other parameter that affects their creation.
  • 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 in Tables C and D indexing structure. For small files (under 50,000 records), wasted record numbers have no effect.

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. Model 204 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 Model 204 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 (R). That is:

BRESERVE = R

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), Model 204 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 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 Model 204 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.

If XAUTOINC is set to a non zero value, Model 204 will automatically increase Table X as needed, when the file is opened by the first user.

Preallocated fields

Preallocated fields can reside only in Table B records. Model 204 will never store them in Table X.

Model 204 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 Tables B and X

The requirement is simply to have enough data storage using either Table B alone or Table B and Table X:

  • When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records.
  • 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.

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 can take.

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

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 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 could be a performance side effect with using Table X. By experimenting with different values of XRECPPG, it might be possible to reduce the size of record extension chains: that is, have fewer but larger extension records instead of many smaller extension records. Having fewer extension records would potentially reduce I/O normally 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 Model 204 file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:

Entries in... Are made for each distinct value of...
Table C KEY or NUMERIC RANGE field.
Table D 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.

The two indexes are:

Hashed Index 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.
Ordered Index 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.

In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.

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

Both Table C and Table D space estimation formulas depend upon the file size multiplier N, which represents the number of internal file segments. Use the following equation to calculate N:

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 N 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. Model 204 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 property entry. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. Model 204 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:

  • Property entry for STAGE = PLANNING
  • Entry for the first segment of the PROJECT file
  • Entry for the second segment of the PROJECT file

Storing segment and property entries

Model 204 attempts to store segment entries on the same page as the property entry. When this is not possible, Model 204 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:

  1. Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:
    • Category u contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.
    • Category n 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.
  2. Then let Vu = total number of pairs in category u and Vn= total number of pairs in category n.

    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:

    • Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.
    • Multiply by 10.
    • Add 2.
  3. Let Vr = total number of extra entries required for all NUMERIC RANGE retrieval fields.

    When calculated this way, Vr 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 Vr is usually unimportant because Vr is usually outweighed by Vn.

    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.

Sizing Table D

Table D data

Table D contains a number of different types of data. The principal types are:

  • Ordered Index B-tree pages
  • Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records
  • Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment
  • Preallocated field record descriptions
  • Text of stored procedures
  • Procedure names and aliases (procedure dictionary)
  • Access Control Table (ACT) pages
  • Sorted file group index pages, if the file is a sorted file
  • 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.

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 Model 204 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 Model 204 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:

This value Equals...
OIT Size of the Ordered Index
IT Size of index list space
F Number of preallocated fields
P Number of procedures
K Number of blocks of pages required for the procedure dictionary
PDSIZE Size of the procedure dictionary
Q Number of pages required for the Access Control Table (ACT)
DPGSRES Size of the Table D reserved area

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

  1. Estimate the following numbers:
    This value Equals...
    NE Number of distinct values (or elements) in the field
    N Number of segments in the file
  2. Estimate the average length (AV).

    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:

    AV = estimated av. length of ORDERED values + 1

  3. 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:
    This category Equals values that occur in...
    A

    One and only one record in the file.

    ValA = the number of values in category A

    B

    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

    C

    A greater number of records per segment than the setting of the field's IMMED parameter.

    ValC = the number of values in category C

  4. For each category of distinct values, use the following appropriate formula:
    • Calculate category A.

      Total length of the Ordered Index entries placed in category A is:

      ENa = ValA * (AV + 3)

    • Calculate category B.

      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 AB represent the average number of records per segment with one of the values in category B. AB 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:

      ENb = ValB * (AV + (2 * AB) + (2 * N))

      If (AV + (2 + AB) + (2 * N)) is greater than 3000, substitute 3000.

    • Calculate category C.
    • The total length of the Ordered Index entries placed in category C is:

      ENc = ValC * (AV + (5 * N))

  5. 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 = ENa + ENb + ENc

    If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.

    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.

  1. Calculate the expected leaf page overhead (LOe)

    The amount of overhead expected on each leaf page, LOe, depends on the usual mode of updating used when updating the ORDERED field:

    • 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 LOe:

      LOe = 6144 * (LRESERVE / 100)

    • If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate LOe:

      LOe = 6144 *( (100 - SPLITPCT) / 100)

  2. Calculate the minimum leaf page overhead

    To determine the minimum amount of overhead for each leaf page, LOmin, first calculate the average number of bytes per Ordered Index entry:

    AE = DIB / NE

    Then calculate LOmin using the following formula:

    LOmin = 2 * (6144 / AE)

  3. Estimate leaf page overhead (LOa)

    The estimate of the overhead for each leaf page, LOa, is the larger of LOe and LOmin:

    LOa = max(LOe, LOmin)

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 = (LP * 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.

Model 204 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, Model 204 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 I, the amount of space required for index lists for each segment, according to the following rules:

  1. If N, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.
  2. 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:
    This category Equals field name = value pairs that occur in...
    A 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.
    B Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages.

    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 A. 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 A requires the following number of bytes:

    T = 2 + (2 * (Number of Records Containing the Pair))

    This value Equals...
    X Total number of bytes available on a Table D page. X depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of X is 5222, calculated as follows:

    X = 6144 * (1 - (DRESERVE / 100) )

    This value Equals...
    A Total number of pages required by the category A pairs for the segment, where:

    A = T / X

    This value Equals...
    B Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. B is equal to the number of pairs in the category.
  3. Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:
    • Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.
    • Multiply by 10.
    • Add 2.

If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:

T' = 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:

B' = number of extra values

The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:

T" = sum of all the values of T' B" = sum of all the values of B'

Then, the total number of pages required is:

C = (T" / X) + B"

Thus, the amount of index list space, I, for each segment is:

I = A + B + C

The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (IT) 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 N, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:

IT = A1 + B1 + C1 + ... + AN< + BN + CN + N

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 F be the number of Table D pages required for the record description. F is always either 0 or 1.

Calculating P (the number of procedures)

Procedures 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:

P = 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 Model 204 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, Model 204 searches the pages in the second block, and so on.

Storing new procedure names

If Model 204 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. Model 204 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:

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

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:

L + 34 for a procedure L + 7 for an alias

Where:

L is the length of the procedure or alias name.

First, estimate S, 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 K is the number of blocks of pages, then (K * 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 Model 204 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 LE, the length of the entries for each user class as follows:

LE = 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:

LET = LE1 + LE2 + ... + LEn

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)

Q, the number of pages required for the ACT is always between 0 and 5 and is calculated by Model 204. To determine how many pages Model 204 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, Model 204 reorganizes the entire ACT. During this automatic reorganization, N + 1 pages are allocated from Table D, where N 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 N 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

Model 204 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 DEST, 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)

DEST 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:

DEST = OIT + IT + F + P + (K * PDSIZE) + Q

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 = min(DEST/50 + 2, 40)

That is, DPGSRES is either (DEST/50 + 2) or 40, whichever is smaller. Since DEST/50 + 2 = 40 when DEST = 1900:

If DEST < 1900, DPGSRES = DEST/50 + 2

and:

If DEST >= 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 = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

or:

DSIZE = DEST + 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:

  • ESIZE — The number of file pages in Table E.
  • EHIGHPG — The highest active Table E page. The first page in Table E is page zero.
  • EPGSUSED — The number of Table E pages currently in use.

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 X'100' bit is set. For these differences, see:

Table E

Table E FILEORG X'100'

Table E non X'100'

ESIZE for 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:

  • If you have MINLOBE set, ignore large objects smaller than this number.
  • Be sure to take that (along with the large object header) into account when sizing Tables B and X.

For more detail on the large object architecture, see Table E for FILEORG X'100' files.

ESIZE for non FILEORG X'100' files

Characteristics:

  • 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 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.
  • Large Object data of 6145 bytes requires two Table E pages.

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 of Bitmap pages plus two.

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

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

  3. Calculate ESIZE.

    ESIZE = Data pages + bitmap pages

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 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 Model 204 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. The "Disk space requirements" table can help you to determine how many pages Model 204 stores on each track for your device type. The page size for all devices is 6184 bytes.

Disk space requirements
Device type Pages/tracks Tracks/cylinder
3330 2 19
3340 1 12
3350 3 30
3375 5 12
3380 7 15
3390 8 15
FACOM 6421 4 20

For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.

Support for FBA devices

Model 204 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 Model 204 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 Defining the runtime environment (CCAIN).

ALLOCATE control statement

The ALLOCATE control statement format is as follows:

ALLOCATE FILE(filename1 filename2 ... filenameN)

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 filename1 through filenameN 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 the characteristics listed in the Personnel file characteristics sample data table.

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.

Personnel file characteristics sample data
Field name Options Average
value
length
Comments on distribution of KEY and
NUMERIC RANGE values
FULL_NAME NON-KEY
NON-CODED
20 -
LAST_NAME ORDERED CHAR

IMMED 2 LRES 15
INVISIBLE

NON-KEY
11 -
SSN KEY

NON-FRV
BINARY
CODED
FEW-VALUED

OCCURS 1
9 Unique to each record.
AGE KEY

NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1

LENGTH 2
2 55 possible values, evenly distributed (18-72).
SALARY NON-KEY

NUM RANGE

NON-CODED
5 20,000 possible values, evenly distributed.
DEPT KEY

CODED
FRV

FEW-VALUED
10

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.

Sample Table A calculations

Calculating ASTRPPG

FRV or CODED values
Field # of Values Space Overhead Total
AGE552*55=1103*55=165110+165=275
DEPT1010*10=1003*10=30100+ 30=130
B=65V=405


Field names
Field LEN + 2[1] ANY + UP[2] COD/FRV OCC LVL FLOAT ORD UNIQ NR Total
FULL_NAME 9 3               12
LAST_NAME 9 3         4     16
SSN 5 3 3[3] 3           11
AGE 5 3 3 3         35 49
SALARY 8 3             80 91
DEPT 6 3 3             12
N = 191
1   LEN is the length of the field name.
2   ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.
3   Because only a small number of values in SSN start with a zero, this field does not have any effect on Table A space estimates.

Calculations

A = 6 D(AGE) = 2 + 3 = 5 D(SALARY) = 5 + 3 = 8 S = 5 + 8 = 13 T = A + B + S = 6 + 65 + 13 = 84 L = average length of character strings = (V + N)/T = (405 + 191)/84 = 7.0 = 7 ASTRPPG = 6144/L = 6144/7 = 877.7 = 877 (rounded down)

Calculating ATRPG

The following numbers are estimated as part of ASTRPPG:

This value Equals...
N Total space consumed by field names including overhead.
A Number of field names.
S Number of extra NUMERIC RANGE fields.

ASTRPG = 1.1 * N/(6144 - (ASTRPPG * 2) -2) = 1.1 * 191/(6144 - (877 * 2) -2) = 1.1 * 191/4388 = 0.04 = 1 (rounded up)

Or:

ASTRPG = 1.1 * (A + S)/ASTRPG = 1.1 * (6+ 13)/877 = 0.02 = 1 (rounded up)

Calculating FVFPG

The following numbers are estimated as part of ASTRPPG:

This value Equals...
V Total space consumed by FEW-VALUED fields including overhead
B Number of FEW-VALUED fields

FVFPG = 1.2 * V/(6144 - (ASTRPPG * 2) -2) = 1.2 * 405/(6144 - (877 * 2) -2) = 1.2 * 405/4388 = 0.11 = 1 (rounded up)

Or:

FVFPG = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = 1 (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

Field Bytes required per record
FULL NAME 23
SSN 4
AGE 2
SALARY 8
DEPT 6
Overhead 5
R = 48

Calculating BRECPPG

BRECPPG = 1.1 * (6144 - 4)/R = 1.1 * 6140/48 = 140.7 = 141 (rounded up)

Calculating BRESERVE

BRESERVE is equal to R, above. Therefore:

BRESERVE = R = 48

Calculating BSIZE

BSIZE = 1.2 * (Total # of Records)/BRECPPG = 1.2 * 90000/141 = 765.9 = 766 (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

Field name Vu pairs Vn pairs Vr entries
SSN 90000    
AGE (KEY)   55  
AGE (NUM RANGE)   55 22
SALARY   20000 52
DEPT   10  
TOTAL 90000 20120 74

Calculating CSIZE

CSIZE = 1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4) = 1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330 (rounded up)

Sample Table D calculations

Calculating Ordered Index space

The calculations in this section use the following variables:

This value Equals...
NE Number of distinct values stored in the field.
AB Average number of records per value per segment..
OIB Total Ordered Index B-tree entry lengths.
LOa Leaf page overhead.
LP Leaf node pages.
OI Ordered entry B-tree pages for the field.

 

Field name Values in:
Category A Category B Category C
LAST NAME 60000 5000 500

Calculating total Ordered Index B-tree entry lengths

AV = Average Value Length + 1 = 11 + 1 = 12 NE = 65500 ENa = Category A * (AV + 3) = 60000 * (12 + 3) = 900000 AB = 2 ENb = Category B * (AV + (2 * AB) + (2 * N)) = 5000 * (12 + (2 * 2) + (2 * 2)) = 100000 ENc = Category C * (AV + (5 * N)) = 500 * (12 + (5 * 2)) = 11000

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

This example assumes 2 segments containing 45,000 records each.

If a field name = value pair appears in... It falls into category...
Fewer than 900 (0.02 * 45000) records A
More than 900 records B

For each value, the number of category A bytes required (T') is calculated using the following equation:

T'= 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:

Value Equals...
T Category A bytes
A Total number of pages in Category A
B Total number of pages (or values) in Category B
C Total number of extra numeric range pages
Values for segment 1
Field name Number
of distinct
values
Records per
value
Category A
bytes
Category B
bytes
Extra
NUM RANGE
pages
AGE (KEY) 55 818.2 55(2+2(818.2))    
AGE (NR) 55 818.2 55(2+2(818.2))   22
SALARY (NR) 20000 2.25 20000(2+2(2.25))   52
LAST NAME 498 5 498(2+(2*5))    
(ORD CHAR) 2 1500   2  
DEPT          
PERS 1 40000   1  
ACCT 0 0      
Other values 8 625 8(2+2(625))    
  T1 = 326216 B1 = 3 C1 = 74

Calculations for segment 1

X = 6144 * (1-(DRESERVE / 100)) = 6144 * 0.85 = 5222 A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)

Values for segment 2
Field name Number
of distinct
values
Records per
value
Category A
bytes
Category B
bytes
Extra
NUM RANGE
pages
AGE (KEY) 55 818.2 55(2+2(818.2))    
AGE (NR) 55 818.2 55(2+2(818.2))   22
SALARY 20000 2.25 20000(2+2(2.25))   52
LAST NAME 498 5 498(2+(2*5))    
(ORD CHAR) 2 1500   2  
DEPT          
PERS   0 0    
ACCT 1 10000   1  
Other values 8 4375   8  
T2 = 316200 B2 = 11 C2 = 74

Calculations for segment 2

A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)

Total index list space

IT = A1 + B1 + C1 + A2 + B2 + C2 + 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, Model 204 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:

This value Equals...
P Number of procedures.
S Average size of procedure entry.
K Number of blocks of pages.
Q Number of pages required for ACT.

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

  • The first page of Table E is reserved for the existence bitmap of page map page numbers.
  • The next fifteen pages of Table E are reserved for the page map pages.
  • 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.

Use the following steps and formulas to determine how many Table E pages you need:

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

  2. Calculate the pages-to-hold-bitmaps as:

    17 + (pages-to-hold-data /49152) + 1

  3. Calculate the ESIZE setting you need as:

    pages-to-hold-data + pages-to-hold-bitmaps + 2

Calculating sample total file size

The total file size for this example is:

File-size = 8 + ASIZE + BSIZE + CSIZE + DSIZE = 8 + 3 + 766 + 330 + 550 = 1657 pages (237 tracks on a 3380)

Space calculation worksheet

This worksheet lists all the equations used in this topic to calculate the number of pages needed for a Model 204 file.

1. Model 204 Usable Page Size constant = 6144

Calculate Table A size

Use the following variables in Equations 2 through 6:

Value Equals...
A Number of field names.
B Number of FEW-VALUED FRV or CODED values.
C Number of MANY-VALUED FRV or CODED values.
D Maximum number of digits in a NUMERIC RANGE field + 3.
S Sum of all D's for all NUMERIC RANGE fields.
T Total number of strings: A + B + S + C.
V Space needed by FEW-VALUED FRV or CODED values and value overhead.
W Space needed by MANY-VALUED FRV or CODED values and value overhead.
N Space needed by field names and names overhead.
  • 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:

Value Equals...
R Average record size.
  • The BRECPPG parameter represents table records per page:

    8. BRECPPG = 1.1 * 6140 / R

  • The BSIZE parameter represents 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:
    Value Equals...
    NE Total number of distinct values in the ORDERED field
    N Number of segments in the file

    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 = OI1 + OI2 + ... + OIn

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 = LE1 + LE2 + ... + LEn

  • 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 and 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 above in Sizing Table E.

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 topic. Other parameters are discussed in their individual M204wiki pages.

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 ____________