Table D (File architecture) - Revision history

JDamon: Changed PPDSTRPPG to PDSTRPPG

2018-07-18T23:39:49Z

Changed PPDSTRPPG to PDSTRPPG

← Older revision		Revision as of 23:39, 18 July 2018
Line 314:		Line 314:
	====PDSTRPPG parameter====		====PDSTRPPG parameter====
	<p>		<p>
	<var>[[PDSTRPPG parameter\|~~PPDSTRPPG~~]]</var> specifies the maximum number of procedure entries per procedure dictionary page.</P>		<var>[[PDSTRPPG parameter\|PDSTRPPG]]</var> specifies the maximum number of procedure entries per procedure dictionary page.</P>

	<p>It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File sizing introduction]] for details).</p>		<p>It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File sizing introduction]] for details).</p>

JAL: /* Node structure */ minor formatting

2018-04-23T20:03:50Z

Node structure: minor formatting

← Older revision		Revision as of 20:03, 23 April 2018
Line 140:		Line 140:

	<tr>		<tr>
	<td>Node Version Number </td>		<td nowrap>Node Version Number </td>
	<td>Used during FRV and FR IN ORDER retrievals.<br>		<td>Used during FRV and FR IN ORDER retrievals.<br>
	Determines if the revisited node is the same as the original</td>		Determines if the revisited node is the same as the original</td>
Line 162:		Line 162:
	<tr>		<tr>
	<td>Offset End of Page</td>		<td>Offset End of Page</td>
	<td>~~X’1800’~~ for 6184 byte page (only valid page size)</td>		<td>X'1800' for 6184 byte page (only valid page size)</td>
	</tr>		</tr>

	<tr>		<tr>
	<td>Prefix Key Pointer		<td>Prefix Key Pointer
	<td>Pointer to the prefix key ( longest value string, including the field code, ~~<br>~~that every field value held on a particular node has in common. At worst ~~<br>~~case this will just be the field code, as values for different ordered fields ~~<br>~~are not held on the same leaf node)</td>		<td>Pointer to the prefix key (longest value string, including the field code, that every field value held on a particular node has in common. At worst case, this will just be the field code, as values for different ordered fields are not held on the same leaf node)</td>
	</tr>		</tr>

JAL: /* Node structure */ typo

2018-04-23T20:00:55Z

Node structure: typo

← Older revision		Revision as of 20:00, 23 April 2018
Line 140:		Line 140:

	<tr>		<tr>
	<td>Node Version Number. </td>		<td>Node Version Number </td>
	<td>Used during FRV and FR IN ORDER retrievals.<br>		<td>Used during FRV and FR IN ORDER retrievals.<br>
	Determines if the revisited node is the same as the original</td>		Determines if the revisited node is the same as the original</td>

JAL: /* Understanding the Ordered Index */ link repair

2018-04-23T19:42:44Z

Understanding the Ordered Index: link repair

← Older revision		Revision as of 19:42, 23 April 2018
Line 108:		Line 108:
	<tr>		<tr>
	<td>Leaf</td>		<td>Leaf</td>
	<td>Lowest level node, which contains a key field-name-equals-value pair, plus a record access pointer to each Table B record containing the pair, or to a Table D record list, or bit pattern that points to the Table B record. (Record lists and bit patterns are described in ~~<b></b>~~.) A small Ordered Index tree can fit on a single node, in which case the root is also a leaf node. </td>		<td>Lowest level node, which contains a key field-name-equals-value pair, plus a record access pointer to each Table B record containing the pair, or to a Table D record list, or bit pattern that points to the Table B record. (Record lists and bit patterns are described in [[File size calculation in detail#Sizing Table D\|Sizing Table D]].) A small Ordered Index tree can fit on a single node, in which case the root is also a leaf node. </td>
	</tr>		</tr>
	</table>		</table>
	<p>In general, each node that has pointers to a lower level node has a large number of such pointers, which are referred to as a large ~~fanout~~ in searching down the tree.</p>		<p>
			In general, each node that has pointers to a lower level node has a large number of such pointers, which are referred to as a large fan-out in searching down the tree.</p>

	====Node structure====		====Node structure====

Admin: /* Approaches to setting PDSIZE */ add noteN

2016-10-25T17:57:05Z

Approaches to setting PDSIZE: add noteN

← Older revision		Revision as of 17:57, 25 October 2016
Line 302:		Line 302:
	====Approaches to setting PDSIZE====		====Approaches to setting PDSIZE====
	<p>		<p>
	There are two possible paths you can take in choosing a PDSIZE:</p>		There are two possible paths you can take in choosing a <var>PDSIZE</var>:</p>
	<ul>		<ul>
	<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, Model 204 might allocate a new block when space still exists on the old block.		<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, Model 204 might allocate a new block when space still exists on the old block.

	<li>Have a number of smaller blocks with fewer pages. Although it might take Model 204 longer to find the procedure name, there is less impact on Table D when a new block is allocated.		<li>Have a number of smaller blocks with fewer pages. Although it might take Model 204 longer to find the procedure name, there is less impact on Table D when a new block is allocated.
	</ul>		</ul>

	<p>Rocket Software generally favors the first approach, particularly as the number of procedures you have grows.</p>		<p class="noteN"> Rocket Software generally favors the first approach, particularly as the number of procedures you have grows.</p>

	====PDSTRPPG parameter====		====PDSTRPPG parameter====

ELowell: /* Manipulating the Ordered Index */

2015-04-13T21:54:25Z

Manipulating the Ordered Index

← Older revision		Revision as of 21:54, 13 April 2015
Line 59:		Line 59:
	===Manipulating the Ordered Index===		===Manipulating the Ordered Index===
	<p>		<p>
	The Ordered Index is created the first time an <var>ORDERED</var> field is defined and physically resides in Table D. Some of its characteristics can be modified through the <var>[[REDEFINE command\|REDEFINE]]</var> command. If multiple deletions and updates reduce the page density and access efficiency, you can rebuild the Ordered Index using the <var>REORGANIZE OI</var> command ~~(see [[File size calculation]])~~.</p>		The Ordered Index is created the first time an <var>ORDERED</var> field is defined and physically resides in Table D. Some of its characteristics can be modified through the <var>[[REDEFINE command\|REDEFINE]]</var> command. If multiple deletions and updates reduce the page density and access efficiency, you can rebuild the Ordered Index using the <var>[[REORGANIZE command\|REORGANIZE]] </var>OI command.</p>

	===Benefits of the ORDERED attribute===		===Benefits of the ORDERED attribute===

ELowell: /* PDSTRPPG parameter */

2015-04-13T21:07:16Z

PDSTRPPG parameter

← Older revision		Revision as of 21:07, 13 April 2015
Line 315:		Line 315:
	<var>[[PDSTRPPG parameter\|PPDSTRPPG]]</var> specifies the maximum number of procedure entries per procedure dictionary page.</P>		<var>[[PDSTRPPG parameter\|PPDSTRPPG]]</var> specifies the maximum number of procedure entries per procedure dictionary page.</P>

	<p>It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File ~~size calculation~~]] for details).</p>		<p>It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File sizing introduction]] for details).</p>


	[[Category:File architecture]]		[[Category:File architecture]]

JAL: typo

2014-11-17T21:33:08Z

typo

← Older revision		Revision as of 21:33, 17 November 2014
Line 259:		Line 259:
	<li>Descending order, set SPLITPCT lower than 50.</li>		<li>Descending order, set SPLITPCT lower than 50.</li>

	<li>If you load records either via the File Load ~~Utility~~ (FLOD) or as deferred updates applied with the Z command, and the ordered field is heavily updated in Online mode, set LRESERVE and NRESERVE higher: up to 50. This causes more splits in the FLOD Z step (see <b></b>: <b></b>), but, by not packing the tree as tightly during the Z step, it should decrease the number of Online splits. Of these two parameters, LRESERVE is more important for tuning. If the field is not heavily updated Online, use the defaults for LRESERVE and NRESERVE. </li>		<li>If you load records either via the File Load utility (FLOD) or as deferred updates applied with the Z command, and the ordered field is heavily updated in Online mode, set LRESERVE and NRESERVE higher: up to 50. This causes more splits in the FLOD Z step (see <b></b>: <b></b>), but, by not packing the tree as tightly during the Z step, it should decrease the number of Online splits. Of these two parameters, LRESERVE is more important for tuning. If the field is not heavily updated Online, use the defaults for LRESERVE and NRESERVE. </li>

	<li>If the field is updated Online with information that is generally not in order, <var class="product">Model 204</var> customer support suggests that you experiment with the IMMED parameter. This parameter is less important if most updates are entered during the FLOD Z step. With the IMMED parameter, there might be a trade-off between Table D LIST I/O and B-Tree I/O. </li>		<li>If the field is updated Online with information that is generally not in order, <var class="product">Model 204</var> customer support suggests that you experiment with the IMMED parameter. This parameter is less important if most updates are entered during the FLOD Z step. With the IMMED parameter, there might be a trade-off between Table D LIST I/O and B-Tree I/O. </li>

ELowell: /* PDSTRPPG parameter */

2014-07-01T20:48:44Z

PDSTRPPG parameter

← Older revision		Revision as of 20:48, 1 July 2014
Line 315:		Line 315:
	<var>[[PDSTRPPG parameter\|PPDSTRPPG]]</var> specifies the maximum number of procedure entries per procedure dictionary page.</P>		<var>[[PDSTRPPG parameter\|PPDSTRPPG]]</var> specifies the maximum number of procedure entries per procedure dictionary page.</P>

	<p>It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File size calculation]] for details.</p>		<p>It is, of course, tied very tightly to the length of procedure names and alias. As such, knowledge of your installations naming standards is critical in setting this parameter (see [[File size calculation]] for details).</p>


	[[Category:File architecture]]		[[Category:File architecture]]

JAL: /* Procedures */

2014-01-27T18:06:26Z

Procedures

← Older revision		Revision as of 18:06, 27 January 2014
Line 292:		Line 292:
	Most sites keep their procedures in different files than their data, but, regardless, the files have identical structures whether they contain only procedures, only data, or both.</p>		Most sites keep their procedures in different files than their data, but, regardless, the files have identical structures whether they contain only procedures, only data, or both.</p>

	<p>The procedure dictionary is defined using the [[PDSIZE ~~parameter\|PDSIZE]]~~ and [[PDSTRPPG ~~parameter]]s~~.</p>		<p>The procedure dictionary is defined using the <var>PDSIZE</var> and <var>PDSTRPPG</var> parameters, as described next.</p>

	===The procedure dictionary===		===The procedure dictionary===