File sizing introduction: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
==Overview - Two approaches to File Sizing==
==Overview - Two approaches to File Sizing==
<p>After designing the data structures you are implementing (see [[Field Design (File Architecture)|field]] [[and Repeating Field Group Design (File Management|Repeating Field Group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>
<p>After designing the data structures you are implementing (see [[Field Design (File Management)|field]] and [[Repeating Field Group Design (File Management)|Repeating Field Group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>


<p>You can take the ad-hoc approach:</p>
<p>You can take the ad-hoc approach, by making sizing estimates and either:</p>


* make size estimates and then iteratively load a sampling of records to verify  
* iteratively load a sampling of records to verify
* use the development and testing process to make final sizing decisions


<p>or, of course, a combination of both.</p> 


<p>or, you can do a detailed analysis of the data you expect the file  
<p>Alternatively, you can do a detailed analysis of the data you expect the file to contain, and try and derive precise sizes for the Model 204 tables, a laborious process.</p>


==Choosing an Approach==


<p>Either way, there are certain decisions, notably the number of datasets, which need to be done based on the amount of data you will, eventually have to handle.</p>  
<p>Most Model 204 file managers use the ad-hoc design approach. Often there is already a production file with similar characteristics to the new file you are creating. Simply copying its parameters as a starting point, is a quick way to get a file ready for development and testing.</p>


[[File Size Calculation in Detail]]
<p>It is also true that most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.</p>
  (and feildgroup) choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:</p>
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>
<p>Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space.    </p>
<p>This chapter contains:</p>
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this chapter </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>
<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 class="code">Number of pages = ASIZE + BSIZE + CSIZE + DSIZE +
                  ESIZE + XSIZE + 8
</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>
===Testing your file design===
<p>When designing a file, consider starting out with a test file of only a few hundred records. This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. </p>
===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>
<b>Model 204 usable page size constant</b>
<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>
==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>
<table>
<tr class="head">
<th>This section</th>
<th>Contains...  </th>
</tr>
<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>
<tr>
<td>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field.    </td>
</tr>
<tr>
<td>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute.    </td>
</tr>
</table>
<p>The Table A parameters you need as part of the total <var class="product">Model&nbsp;204</var> number of pages are: </p>
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>
<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>
<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>
<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>
<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)===
<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>
<b>Computing L (the length of each string)</b>
<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>
<li>For each CODED or FRV value, add 3 bytes.  </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
<p class="code">((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</p></li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names</td>
</tr>
<tr>
<td>B  </td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>
<tr>
<td>C  </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>
<tr>
<td>S  </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>
<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>
<li>Then, compute L, where:
<p class="code">L = (V + N + W) / T
</p></li>
</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>
<p class="code">ASTRPPG = 6144 / L
</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)===
<p>ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:</p>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>
<tr>
<td>A </td>
<td>Number of field names</td>
</tr>
<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>
<p>Next, compute the following equations:</p>
<p class="code">ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )


ATRPG = 1.1 * (A + S) / ASTRPPG
<p>But it is also true that the detailed rules provide a level of knowledge that the file manager should be grounded in, so, to use, or just understand the sizing rules, see [[File Size Calculation in Detail]]. </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>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>
<b>ATRPG multiplier</b>
<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 Host Language Interface call that refers to many fields. </p>
<b>Note</b>
<p>The product of ATRPG and ASTRPPG must not exceed 4000.</p>
===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>Examine your data to estimate the following:</p>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG).  </td>
</tr>
</table>
<p class="code">FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)


FVFPG = 1.2 * B / ASTRPPG
==Critical, Up Front Decisions==
</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>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>
<b>Keeping FVFPG small</b>
<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)===
<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>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>
<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG)  </td>
</tr>
</table>
<p class="code">MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)


MVFPG = 1.2 * B / ASTRPPG
<p>There are, however, certain decisions which are more difficult to fix and so should be as 'correct' as possible, as early as possible:</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>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)===
<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==
<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>
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</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>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>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>R</td>
<td>Average record size</td>
</tr>
<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>
<p>Instructions for calculating these parameters are discussed in this section.</p>
<b>Estimating space for hash key files</b>
<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>
<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===
<p>The following conditions must be met before a new record is stored on a Table B page:</p>
<ul>
<li>Record number must be available. </li>
<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>
<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space.  </li>
</ul>
===Computing R (the average record size)===
<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>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>
<li>Ignore any field that has the INVISIBLE attribute.</li>
<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:</li>
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes.  </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field.    </li>
</ul>
<li>Compute the space needed for preallocated fields as follows:</li>
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>
<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul>
<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>
<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)===
<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>
<p>BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.</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>
<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>
</ul>
===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 class="code">BSIZE = 1.2 * Total-Number-of-Records / BRECPPG
</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>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)===
<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>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>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>
<b>Sizing BRESERVE to avoid extension records</b>
<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==
===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><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>
===Table B overhead===
<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>
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>
<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>
<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>
===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>
===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>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>
<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>
<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==
<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>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of...    </th>
</tr>
<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>
<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>
<p>The two indexes are:</p>
<table>
<tr class="head">
<th>Hashed Index</th>
<th>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</th>
</tr>
<tr>
<td>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
<tr>
<td colspan="2">In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.</td>
</tr>
</table>
<b>FRV attribute entries</b>
<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)===
<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>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>
<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==
===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>
<b>Table C property entries</b>
<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>
<p>Therefore, in Table C of the PROJECT file, there is a chain of three entries:</p>
<ul>
<li>Property entry for STAGE = PLANNING</li>
<li>Entry for the first segment of the PROJECT file</li>
<li>Entry for the second segment of the PROJECT file </li>
</ul>
<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>
===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>Compute CSIZE as follows:</p>
<ul>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:</li>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>
<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
<li>Then let <var>Vu</var> = total number of pairs in category <var class="term">u</var> and <var>Vn</var>= total number of pairs in category <var class="term">n</var>. 
<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>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.
<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>
<p>Compute:</p>
<p class="code">CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)
</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>
</ul>
==Sizing Table D==
===Table D data===
<p>Table D contains a number of different types of data. The principal types:</p>
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file            </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter.    </li>
</ul>
<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>
<b>Data storage in Table D</b>
<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>
<b>Computing DSIZE</b>
<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>
<p>where:</p>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>
<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>
<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>
<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>
<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>
<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>
<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)===
<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>
<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>
<b>Estimating Ordered Index space (OI) for each ORDERED field</b>
<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>
<b>Estimate the following numbers:</b>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td>NE  </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>
<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table>
<ol>
<li>Estimate the average length (<var>AV</var>)
<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 class="code"><var>AV</var> = estimated av.length of ORDERED values + 1
</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:
<table>
<tr>
<td>This category</td>
<td>Equals values that occurs in...</td>
</tr>
<tr>
<td>A</td>
<td>
<p>One and only one record in the file.</p>
<p>ValA  =  the number of values in category A</p>
</td>
</tr>
<tr>
<td>B</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>ValB = the number of values in category B</p>
</td>
</tr>
<tr>
<td>C</td>
<td>
<p>A greater number of records per segment than the setting of the field's IMMED parameter. </p>
<p>ValC = the number of values in category C</p>
</td>
</tr>
</table>
</li>
<li>For each category of distinct values, use the following appropriate formula:</li>
<ul>
<li>Calculate category A</li>
</ul>
</ol>
<p>Total length of the Ordered Index entries placed in category A is:</p>
<p class="code"><var>ENa</var> = <var>ValA</var> * (<var>AV</var> + 3)
</p>
<ul>
<li>Calculate category B</li>
</ul>
<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>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>
<p>The total length of the Ordered Index entries placed in category B is:</p>
<p class="code"><var>ENb</var> = <var>ValB</var> * (<var>AV</var> + (2 * <var>AB</var>) + (2 * <var>N</var>))
</p>
<p>If (<var>AV</var> + (2 + <var>AB</var>) + (2 * <var>N</var>)) is greater than 3000, substitute 3000.</p>
<ul>
<li>Calculate category C</li>
</ul>
<p>The total length of the Ordered Index entries placed in category C is:</p>
<p class="code"><var>ENc</var> = <var>ValC</var> * (<var>AV</var> + (5 * <var>N</var>))
</p>
<ol>
<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 = <var>ENa</var> + <var>ENb</var> + <var>ENc</var>
</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>
</li>
</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)===
<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>
<b>Calculate the expected leaf page overhead (LOe)</b>
<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>
<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>: 
<p class="code">LOe = 6144 * (LRESERVE / 100)
</p></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>
<p class="code">LOe = 6144 *( (100 - SPLITPCT) / 100)
</p></li>
</ul>
<ol>
<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 class="code">AE = DIB / NE
</p>
<p>Then calculate <var>LOmin</var> using the following formula:</p>
<p class="code">LOmin = 2 * (6144 / AE)
</p></li>
<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 class="code"><var>LOa</var> = <var class="term">max</var>(<var>LOe</var>, <var>LOmin</var>)
</p></li>
</ol>
===Estimating the number of required leaf pages (LP)===
<p>The number of leaf pages required for the ORDERED field is:</p>
<p class="code">LP = OIB / (6144 - 24 - LOa)
</p>
<p>Round up to the nearest integer. </p>
===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 class="code">OI = (<var>LP</var> * 1.01) rounded up to the nearest integer
</p>
<p>This formula assumes conservatively that the number of intermediate pages is 1% of LP. </p>
===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 class="code">OIT = OI1 + OI2 + ... + OIn   
</p>
===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><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>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 DRESERVE</b>
<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>
<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>
<ol>
<li>If <var>N</var>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>
<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories: 
<table>
<tr>
<td>This category</td>
<td>Equals. field name = value pairs that occur in...</td>
</tr>
<tr>
<td><var>A </var></td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>
<tr>
<td><var> B </var></td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>
<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>Each pair placed in category <var>A</var> requires the following number of bytes:</p>
<p class="code"><var>T</var> = 2 + (2 * (Number of Records Containing the Pair))
</p></li>
</ol>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var> X</var> </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows.</td>
</tr>
</table>
<p class="code">X = 6144 * (1 - (DRESERVE / 100) )
</p>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>A</var> </td>
<td>Total number of pages required by the category A pairs for the segment, where:</td>
</tr>
</table>
<p class="code">A = T / X
</p>
<table>
<tr>
<td>This value</td>
<td>Equals...</td>
</tr>
<tr>
<td><var>B</var> </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
<ol>
<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:</li>
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul>
</ol>
<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 class="code"><var>T</var>' = 2 + (2 * (Number of Records Containing the Field))
</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 class="code"><var>B</var>' = number of extra values
</p>
<p>The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:</p>
<p class="code"><var>T</var>" = sum of all the values of <var>T</var>'
<var>B</var>" = sum of all the values of <var>B</var>'
</p>
<p>Then, the total number of pages required is:</p>
<p class="code">C = (T" / X) + B"
</p>
<p>Thus, the amount of index list space, <var>I</var>, for each segment is:</p>
<p class="code"><var>I</var> = <var>A</var> + <var>B</var> + <var>C</var>
</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 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>
</p>
===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>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)===
<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 class="code"><var>P</var> = total number of procedures
</p>
===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>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>Storing new procedure names</b>
<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>
<b>Choosing a PDSIZE</b>
<p>There are two possible paths you can take in choosing a PDSIZE:</p>
<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 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>
<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>
<b>Computing PDSTRPPG</b>
<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
<var>L</var> + 7  for an alias
</p>
<p>where: </p>
<p><var>L</var> is the length of the procedure or alias name. </p>
<p>First, estimate <var>S</var>, the average entry size. Then compute PDSTRPPG as follows:</p>
<p class="code">PDSTRPPG = 6144 / S
</p>
<p>The default value of PDSTRPPG is 128. Its maximum is 256.</p>
<b>Computing PDSIZE (the size of the procedure dictionary)</b>
<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>
<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)===
<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>
<b>Determining LET (the total length of procedure class entries)</b>
<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>
<p>Then, compute <var>LE</var>, the length of the entries for each user class as follows:</p>
<p class="code"><var>LE</var> = 4 + (2 * NPCLASS)
</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>Then, the total length of the user class entries is:</p>
<p class="code"><var>LET</var> = <var>LE</var><var>1</var> + <var>LE</var><var>2</var> + ... + <var>LEn</var>
</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>
<b>Determining Q (the number of pages required for the ACT)</b>
<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>
<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>
<b>Note</b>
<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>
===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>
<p class="code">M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA
</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>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>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>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>
<b>Calculating DEST (estimated Table D size)</b>
<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 class="code"><var>DEST</var> = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var>
</p>
<b>Setting DPGSRES (the size of the reserved area)</b>
<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>
<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>
<b>Calculating DPGSRES</b>
<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>That is, DPGSRES is either (<var>DEST</var>/50 + 2) or 40, whichever is smaller. Since
<var>DEST</var>/50 + 2 = 40 when <var>DEST</var> = 1900:</p>
<p class="code">If <var>DEST</var> &lt; 1900, DPGSRES = <var>DEST</var>/50 + 2
</p>
<p>and:</p>
<p class="code">If <var>DEST</var> >= 1900, DPGSRES = 40
</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 = <var>OIT</var> + <var>IT</var> + <var>F</var> + <var>P</var> + (<var>K</var> * PDSIZE) + <var>Q</var> + DPGSRES
</p>
<p>or:</p>
<p class="code">DSIZE = <var>DEST</var> + DPGSRES
</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>
==Sizing and managing Table E==
<p>The following parameters pertain to Table E sizing:</p>
<ul>
<li>ESIZE - The number of file pages in Table E.</li>
<li>EHIGHPG - The highest active Table E page. The first page in Table E is page zero.</li>
<li>EPGSUSED - The number of Table E pages currently in use.</li>
</ul>
===Storing Large Object Data===
<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>
<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-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>
===Computing Table E size - ESIZE===
<b>Formula for sizing the ESIZE parameter</b>
<p>Set ESIZE as the number of Data pages, plus the number Bitmap pages plus two.</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>
<p class="code">First calculation: (Avg.-BLOB-len + 6144) / 6144 = result


Second calculation: 1st Round up result


Data pages = round-up-result * No.-of-BLOBs
<b>[[ATRPG parameter|ATRPG]] and [[ASTRPPG parameter]]s</b>  
</p>
<ol>
<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


Bitmap pages = 2nd round up result
<p>Because the [[#Table A (File Architecture)#Internal File Dictionary|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>  
</p></li>
<li>Calculate ESIZE
<p class="code">ESIZE = Data pages + bitmap pages
</p></li>
</ol>
===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>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>
<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>
==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/*
                          */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 parameters are displayed with zero values. See <var class="product">Model&nbsp;204</var> Parameter and Command Reference for a description of the Table X parameters.</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>
==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>
===Minimum number of pages required===
<p>The minimum number of pages required for the file is equal to:</p>
<p class="code">8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE
</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===
<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>
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>
<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>
<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>
<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>
<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>
<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>
<p>For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.</p>
<b>Support for FBA devices</b>
<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>
<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===
<b>z/OS example</b>
<p>To allocate z/OS data sets, use the IBM utility IEFBR14. For example:</p>
<p class="code">//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//
</p>
<p>The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.</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>
<p class="code">SPACE=(TRK,183,,CONTIG)
</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>
<b>z/VM example</b>
<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
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK
</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>
<b>ALLOCATE control statement</b>
<p>The ALLOCATE control statement format is as follows:</p>
<b>Syntax</b>
<p class="code">ALLOCATE FILE(<var class="term">filename1</var> <var class="term">filename2</var> ... <var class="term">filenameN</var>)
</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>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>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
// 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)
/*
/&amp;
</p>
==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>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>
<table>
<caption>Personnel file characteristics example</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>
<tr>
<td>FULL_NAME</td>
<td>NON-KEY
NON-CODED</td>
<td align="right">20</td>
<td align="right">-</td>
</tr>
<tr>
<td>LAST_NAME</td>
<td>ORDERED CHAR
IMMED 2 LRES 15
INVISIBLE
NON-KEY</td>
<td align="right">11</td>
<td align="right">-</td>
</tr>
<tr>
<td>SSN</td>
<td>KEY
NON-FRV
BINARY
CODED
FEW-VALUED
OCCURS 1</td>
<td align="right">9</td>
<td>Unique to each record.</td>
</tr>
<tr>
<td>AGE</td>
<td>KEY
NUM RANGE
FRV
FEW-VALUED
NON-CODED
OCCURS 1
LENGTH 2</td>
<td align="right">2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>
<tr>
<td>SALARY</td>
<td>NON-KEY
NUM RANGE
NON-CODED</td>
<td align="right">5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>
<tr>
<td>DEPT</td>
<td>KEY
CODED
FRV
FEW-VALUED</td>
<td align="right">10</td>
<td>
<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>
</tr>
</table>
==Sample Table A calculations==
===Calculating ASTRPPG===
<b>FRV or CODED values</b>
<p class="code">  Field  # of Values  Space        Overhead  Total
AGE  55            2*55=110    3*55=1651  10+165=275
DEPT  10            10*10=100    3*10=3010  0+ 30=130


  B = 65                                        V=405
<p>You can look at the detailed calculation rules at [[File Size Calculation in Detail#Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter|ASTRPPG]].</p>  
</p>
<b>Field Names</b>
<table>
<tr class="head">
<th>Field</th>
<th>LEN
+ 2[[#File Size Calculation|File Size Calculation]]</th>
<th>ANY
+ UP[[#File Size Calculation|File Size Calculation]]</th>
<th>COD/
FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>
<tr>
<td>
<b>FULL_NAME</b>
</td>
<td align="right">9</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">12</td>
</tr>
<tr>
<td>
<b>LAST_NAME</b>
</td>
<td align="right">9</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">4</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">16</td>
</tr>
<tr>
<td>
<b>SSN</b>
</td>
<td align="right">5</td>
<td align="right">3</td>
<td>(3)[[#File Size Calculation|File Size Calculation]]</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">11</td>
</tr>
<tr>
<td>
<b>AGE</b>
</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">35</td>
<td align="right">49</td>
</tr>
<tr>
<td>
<b>SALARY</b>
</td>
<td align="right">8</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">80</td>
<td align="right">91</td>
</tr>
<tr>
<td>
<b>DEPT</b>
</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align="right">12</td>
</tr>
<tr>
<td colspan="11">N = 191</td>
</tr>
</table>
<ol>
<li>LEN is the length of the field name</li>
<li>ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.</li>
<li>Because only a small number of value in SSN start with a zero, this field does not have any effect on Table A space estimates.</li>
</ol>
<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 =


(V + N)/T = (405 + 191)/84 = 7.0 = 7
<b>[[CSIZE parameter]]</b>


<var>ASTRPPG</var> = 6144/L = 6144/7 = 877.7 = <var>877</var> (rounded down)
<p>Like the internal file dictionary, Table C is hashed and so can not be dynamically changed.<p>
</p>
===Calculating ATRPG===
<p>The following numbers are estimated as part of ASTRPPG:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>
<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>
<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>
<p class="code"><var>ASTRPG</var> = 1.1 * N/(6144 - (ASTRPPG * 2) -2)


= 1.1 * 191/(6144 - (877 * 2) -2)
<p>The easiest way to make sure that this is an issue is not to define any KEY or NUMERIC RANGE fields: make them ordered instead. This has the associated advantage of, if you use [[FILEORG parameter|FILEORG]] x'100' files, of permitting up to 32000 field names in a file.</p> 


= 1.1 * 191/4388 = 0.04 = <var>1</var> (rounded up)
</p>
<p>or</p>
<p class="code"><var>ASTRPG</var> = 1.1 * (A + S)/ASTRPG


= 1.1 * (6+ 13)/877
<b>Number of Datasets</b>


= 0.02 = <var>1</var> (rounded up)
<p>You can dynamically [[INCREASE command|add datasets]] to a Model 204 file.</p>
</p>
===Calculating FVFPG===
<p>The following numbers are estimated as part of ASTRPPG:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>
<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
<p class="code"><var>FVFPG</var> = 1.2 * V/(6144 - (ASTRPPG * 2) -2)


= 1.2 * 405/(6144 - (877 * 2) -2)
<p>The reason that it is better not have to is that there may be JCL containing file references which would need to be updated at the same time.</p>


= 1.2 * 405/4388 = 0.11 = <var>1</var> (rounded up)
<p>Unless space is at a premium, it is a good idea to define dataset(s) larger than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.</p>     
</p>
<p>or</p>
<p class="code"><var>FVFPG</var> = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = <var>1</var> (rounded up)
</p>
===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 class="code"> MVFPG = 1    
</p>
==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Total bytes required per record</th>
</tr>
<tr>
<td>FULL NAME</td>
<td align="right">23</td>
</tr>
<tr>
<td>SSN</td>
<td align="right"> 4</td>
</tr>
<tr>
<td>AGE </td>
<td align="right"> 2</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right"> 8</td>
</tr>
<tr>
<td>DEPT</td>
<td align="right"> 6</td>
</tr>
<tr>
<td>Overhead</td>
<td align="right"> 5</td>
</tr>
<tr>
<td><var>R</var> =</td>
<td align="right">48</td>
</tr>
</table>
===Calculating BRECPPG===
<p class="code"><var>BRECPPG</var> = 1.1 * (6144 - 4)/R = 1.1 * 6140/48


= 140.7 = <var>141</var> (rounded up)
</p>
===Calculating BRESERVE===
<p>BRESERVE is equal to <var>R</var>, above. Therefore:</p>
<p class="code">BRESERVE = <var>R</var> = 48
</p>
===Calculating BSIZE===
<p class="code"><var>BSIZE</var> = 1.2 * (Total # of Records)/BRECPPG
  = 1.2 * 90000/141 = 765.9 = <var>766</var> (rounded up)
</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==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>
<tr>
<td>SSN</td>
<td align="right">90000</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>AGE (KEY)</td>
<td>&nbsp;</td>
<td align="right">55</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>AGE (NUM RANGE)</td>
<td>&nbsp;</td>
<td align="right">55</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td>&nbsp;</td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>
<tr>
<td>DEPT</td>
<td>&nbsp;</td>
<td align="right">10</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>
<p>&nbsp;</p>
===Calculating CSIZE===
<p class="code">CSIZE=1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)
</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==
===Calculating Ordered Index space===
<p>The calculations in this section use the following variables:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>
<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>
<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>
<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>
<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>
<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>
<p>&nbsp;</p>
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in </th>
</tr>
<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>
<b>Calculating total Ordered Index B-tree entry lengths</b>
[[File:_File_Size_Calculation_2.gif]]
<b>Calculating Ordered Index B-tree overhead</b>
<p>The final values for LOe, LP, and OI are rounded up.</p>
<p class="code">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
</p>
===Calculating index list space===
<p>For this example, assume that there are 2 segments containing 45,000 records each. </p>
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>
<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>
<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>
<p>For each value, the number of category A bytes required (<var>T</var>') is calculated using the following equation:</p>
<p class="code"><var>T</var>'= 2 + (2 * (Number of Records Containing the Pair))
</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>The following calculations use these variables:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>T  </td>
<td>Category A bytes.</td>
</tr>
<tr>
<td>A  </td>
<td>Total number of pages in Category A.</td>
</tr>
<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B.</td>
</tr>
<tr>
<td>C </td>
<td>Total number of extra numeric range pages.</td>
</tr>
</table>
<b>Values for segment 1</b>
<table>
<tr class="head">
<th>
Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>&nbsp;</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY (NR)</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td>&nbsp;</td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>  (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td>&nbsp;</td>
<td align="right">2</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>DEPT</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>    PERS</td>
<td align="right">1</td>
<td>40000.</td>
<td>&nbsp;</td>
<td align="right">1</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>    ACCT</td>
<td align="right">0</td>
<td>0.</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>625.</td>
<td>8(2+2(625))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td><var>T1 = 326216</var></td>
<td><var>B1 = 3</var></td>
<td><var>C1 = 74</var></td>
</tr>
</table>
<b>Calculations for segment 1</b>
<p class="code">X = 6166 * (1-(DRESERVE / 100)) = 6144 * 0.85 = B
A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)
</p>
<b>Values for segment 2</b>
<table>
<tr class="head">
<th>
Field name</th>
<th>Number
of distinct values</th>
<th>
Records per value</th>
<th>
Category A bytes</th>
<th>
Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>
<tr>
<td>AGE (KEY)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>AGE (NR)</td>
<td align="right">55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td>&nbsp;</td>
<td align="right">22</td>
</tr>
<tr>
<td>SALARY</td>
<td align="right">20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td>&nbsp;</td>
<td align="right">52</td>
</tr>
<tr>
<td>LAST NAME</td>
<td align="right">498</td>
<td>5.</td>
<td>498(2+(2*5))</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>  (ORD CHAR)</td>
<td align="right">2</td>
<td>1500.</td>
<td>&nbsp;</td>
<td align="right">2</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>DEPT</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>    PERS</td>
<td>&nbsp;</td>
<td align="right">0</td>
<td align="right">0</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>    ACCT</td>
<td align="right">1</td>
<td>10000.</td>
<td>&nbsp;</td>
<td align="right">1</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Other values</td>
<td align="right">8</td>
<td>4375.</td>
<td>&nbsp;</td>
<td align="right">8</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td><var>T2 = 316200</var></td>
<td><var>B2 = 11</var></td>
<td><var>C2 = 74</var></td>
</tr>
</table>
<b>Calculations for segment 2</b>
<p class="code">A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)
</p>
===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 =
    63 + 3 + 74 + 61 + 11 + 74 + 2 = 288
</p>
===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 class="code">F = 1
</p>
===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>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>
<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>
<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>
<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>
<p class="code">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
</p>
===Calculating space required for reserved area===
<p class="code">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)
</p>
===Calculating DSIZE===
<p class="code">DSIZE  =  DEST + DPGSRES = 537 + 13 = 550 
</p>
==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>
<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>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===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>
<li>The next fifteen pages of Table E are reserved for the page map pages.</li>
<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>
<p>Use the following steps and formulas to determine how many Table E pages you need:</p>
<b>Calculate the pages-to-hold-data as:</b>
<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>
<li>Calculate the pages-to-hold-bitmaps as:
<p class="code">17 + (pages-to-hold-data /49152) + 1
</p></li>
<li>Calculate the ESIZE setting you need as:
<p class="code">pages-to-hold-data + pages-to-hold-bitmaps + 2
</p></li>
</ol>
==Calculating sample total file size==
<p>The total file size for this example is:</p>
<p class="code">8 + ASIZE + BSIZE + CSIZE + DSIZE =
8 + 3 + 766 + 330 + 550 =
<var>1657 pages, or 237 tracks on a 3380</var>
</p>
==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 class="code">1. Model 204 Usable Page Size constant = 6144
</p>
===Calculate Table A size===
<p>Use the following variables in Equations 2 through 6:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>
<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>
<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>
<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>
<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>
<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>
<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>
<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>
<p>L represents the length of each string</p>
<p class="code">2. L = (V + N + W) / T
</p>
<p>The ASTRPPG parameter represents the character strings per Table A page</p>
<p class="code">3. ASTRPPG = 6144 / L
</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>
<p>The FVFPG parameter represents the number of FEW-VALUED pages</p>
<p class="code">5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)
</p>
<p>or</p>
<p class="code">FVFPG= 1.2 * (B / ASTRPPG)
</p>
<p>The MVFPG parameter represents the number of MANY-VALUED pages</p>
<p class="code">6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )
</p>
<p>or</p>
<p class="code">MVFPG = 1.2 * (B / ASTRPPG)
</p>
<p>The ASIZE parameter represents the size of Table A</p>
<p class="code">7. ASIZE=ATRPG+FVFPG+MVFPG (calculated by Model 204)
</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
===Calculate Table B size===
<p>Use the following variable in Equations 8 through 10:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</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
</p>
<p>&nbsp;</p>
===Calculate Table C size===
<p>The N variable represents the file size multiplier</p>
<p class="code">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
</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===
<b>Estimate the size of the Ordered Index</b>
<p>Use the following variables in Equations 16 through 24:</p>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>
<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>
<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>
<p class="code">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
</p>
<p>ENa = The total length of the Ordered Index entries placed in category A</p>
<p class="code">20.  ENa = ValA * (AV + 3)
</p>
<p>ENb = The total length of the Ordered Index entries placed in category B</p>
<p class="code">21.  ENb = ValB * (AV + (2 * AB) + (2 * N)
</p>
<p>ENc = The total length of the Ordered Index entries placed in category C</p>
<p class="code">22.  ENc = ValC * (AV + (5 * N))
</p>
<p>The OIB parameter represents the total length of all Ordered Index entries</p>
<p class="code">23.  IB = ENa + ENb + ENc =
</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>
<p>The value of AE represents the average number of bytes per Ordered Index entry</p>
<p class="code">25. AE = OIB / EN
</p>
<p>The value of LOmin represents the minimum leaf page overhead</p>
<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
</p>
<p>The value of T' represents the extra bytes required for NUMERIC RANGE fields</p>
<p class="code">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'
</p>
<p>The value of C represents the total extra pages required</p>
<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
</p>
<p>PDSTRPPG = the maximum number of procedure entries per procedure dictionary page</p>
<p class="code">46. PDSTRPPG = 6144 / S
47. PDSIZE = 1.4 * P / PDSTRPPG
</p>
<b>Calculate the size of the ACT</b>
<p>The value of LE represents the length of entries for each user class</p>
<p class="code">48.  LE = 4 + (2 * NPCLASS)
</p>
<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>
</p>
<p>The value of Q represents the number of pages required for the ACT</p>
<p class="code">50. Q = LET / 6144
</p>
<b>Calculate the final size of Table D</b>
<p class="code">51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q
52. If DEST &lt; 1900, DPGSRES = DEST/50 + 2
</p>
<p>or:</p>
<p class="code">    If DEST >= 1900, DPGSRES = 40
53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES
</p>
<p>or:</p>
<p class="code">DSIZE = DEST + DPGSRES
</p>
===Calculate the final size for Table E===
<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>
===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 chapter. Other parameters are discussed throughout this manual and in the <var class="product">Model&nbsp;204</var> Parameter and Command Reference.</p>
<b>File Description Sheet</b>
<p class="code">
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    ____________
</p>
<p>1.</p>
<p>2.</p>
<p>3.</p>
[[Category:File manager]]
[[Category:File manager]]
[[Category:File management]]
[[Category:File management]]

Revision as of 23:13, 7 May 2013

Overview - Two approaches to File Sizing

After designing the data structures you are implementing (see field and Repeating Field Group design) there are two ways for a file manager to approach the calculation of file sizes:

You can take the ad-hoc approach, by making sizing estimates and either:

  • iteratively load a sampling of records to verify
  • use the development and testing process to make final sizing decisions

or, of course, a combination of both.

Alternatively, you can do a detailed analysis of the data you expect the file to contain, and try and derive precise sizes for the Model 204 tables, a laborious process.

Choosing an Approach

Most Model 204 file managers use the ad-hoc design approach. Often there is already a production file with similar characteristics to the new file you are creating. Simply copying its parameters as a starting point, is a quick way to get a file ready for development and testing.

It is also true that most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.

But it is also true that the detailed rules provide a level of knowledge that the file manager should be grounded in, so, to use, or just understand the sizing rules, see File Size Calculation in Detail.

Critical, Up Front Decisions

There are, however, certain decisions which are more difficult to fix and so should be as 'correct' as possible, as early as possible:


ATRPG and ASTRPPG parameters

Because the Internal File Dictionary is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.

You can look at the detailed calculation rules at File Size Calculation in Detail#Sizing Table A or, given how small Table A is compared to the other tables, round up on your rough estimate for ATRPG and round down (to try and fit fewer field definitions on each Table A page) for ASTRPPG.


CSIZE parameter

Like the internal file dictionary, Table C is hashed and so can not be dynamically changed.

The easiest way to make sure that this is an issue is not to define any KEY or NUMERIC RANGE fields: make them ordered instead. This has the associated advantage of, if you use FILEORG x'100' files, of permitting up to 32000 field names in a file.


Number of Datasets

You can dynamically add datasets to a Model 204 file.

The reason that it is better not have to is that there may be JCL containing file references which would need to be updated at the same time.

Unless space is at a premium, it is a good idea to define dataset(s) larger than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=File_sizing_introduction&oldid=59425"