UFEOHASH parameter: Difference between revisions
(Automatically generated page update) |
m (misc formatting) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Template:UFEOHASH parameter subtitle}} | |||
==Summary== | ==Summary== | ||
<dl> | <dl> | ||
| Line 10: | Line 11: | ||
<dd>All | <dd>All | ||
<dt>Introduced | <dt>Introduced | ||
<dd><var class="product">Model 204 | <dd><var class="product">Model 204 V5.1</var> | ||
</dl> | </dl> | ||
==Description== | ==Description== | ||
<p>The UFEOHASH value represents the number of hash cells that are allocated in the FEO hash table to optimize FOR EACH OCCURRENCE (FEO) loops that are run against unlocked records (FDWOL). </p> | <p> | ||
<p>The UFEOHASH parameter can be set to a value between 0 and 65535, inclusive. </p> | The <var>UFEOHASH</var> value represents the number of hash cells that are allocated in the FEO hash table to optimize [[Processing multiply occurring fields and field groups#FOR EACH OCCURRENCE OF loops|FOR EACH OCCURRENCE]] (FEO) loops that are run against unlocked records ([[FD, FDWOL, or FDR - Find to recordset|FDWOL]]). </p> | ||
<p> | |||
The <var>UFEOHASH</var> parameter can be set to a value between 0 and 65535, inclusive. </p> | |||
<ul> | <ul> | ||
<li> | <li>When the <var>UFEOHASH</var> parameter is set to zero, <var class="product">Model 204</var> does not optimize unlocked FEO loops. FEO loops that are non-optimized scan from the beginning of the record for each occurrence of the field. This can result in significant CPU overhead for FEO loops run against fields with a large number of occurrences. </li> | ||
When the UFEOHASH parameter is set to zero, <var class="product">Model 204</var> does not optimize unlocked FEO loops | |||
<li> | <li>A nonzero <var>UFEOHASH</var> value causes <var class="product">Model 204</var> to build an FEO hash table. As the value of <var>UFEOHASH</var> is used as a hash value divisor, Rocket Software recommends that you set <var>UFEOHASH</var> to a <em>prime number</em>. A number such as 1021 might virtually eliminate non-optimized FEO loops for unlocked records at the cost of only 8,184 bytes of virtual storage.</li> | ||
A nonzero UFEOHASH value causes <var class="product">Model 204</var> to build an FEO hash table. As the value of UFEOHASH is used as a hash value divisor, Rocket Software recommends that you set UFEOHASH to a prime number. A number such as 1021 might virtually eliminate non-optimized FEO loops for unlocked records at the cost of only 8,184 bytes of virtual storage.</li> | |||
</ul> | </ul> | ||
<p>An FEO table entry contains a file number and record number for a record. Every Table B record is tracked in the FEO table. Whenever a record is modified, the FEO table entry for that record is also updated. FEO processing remembers the FEO table value for the record it is processing. The current table information for a record is checked before each new scan for another field occurrence. If the table information is unchanged, the next scan starts on the record where the previous scan ended. If the table information changed, the next scan must begin at the start of the record.</p> | ===Understanding the FEO hash table=== | ||
<p>It is possible that more than one record can map to the same hash cell in the FEO table. Consequently, an update to another record | <p> | ||
<p>This optimization is disabled in single-user jobs.</p> | An FEO table entry contains a file number and record number for a record. Every Table B record is tracked in the FEO table. Whenever a record is modified, the FEO table entry for that record is also updated. FEO processing remembers the FEO table value for the record it is processing. The current table information for a record is checked before each new scan for another field occurrence. If the table information is unchanged, the next scan starts on the record where the previous scan ended. If the table information changed, the next scan must begin at the start of the record.</p> | ||
<p> | |||
It is possible that more than one record can map to the same hash cell in the FEO table. Consequently, an update to another record can cause scan from the beginning of the record. Each time a record is scanned from the beginning in response to a change in the value in the FEO table, the <code>UFEOMISS</code> statistic is increased by one.</p> | |||
<p> | |||
This optimization is disabled in single-user jobs.</p> | |||
==Usage== | |||
<p> | |||
Setting the value of <var>UFEOHASH</var> should take into account the number of concurrent updates that happen in the Online.</p> | |||
<p> | |||
Updates to records in different files may hash to the same FEO slot, as can updates to different records in the same file. These are called <b>hash collisions</b>.</p> | |||
<p> | |||
As the value of <var>UFEOHASH</var> is increased, the likelihood of these hash collisions is reduced. Up to a certain point, increasing the value of <var>UFEOHASH</var> tends to improve performance by reducing the number of FEO loops that are not optimized, which are also referred to as <b>unlocked FEO misses</b>. See the <var>[[UFEOMISS parameter|UFEOMISS]]</var> parameter for more information.</p> | |||
[[Category:System parameters]] | [[Category:System parameters]] | ||
[[Category:Parameters]] | [[Category:Parameters]] | ||
Latest revision as of 17:08, 16 October 2017
Unlocked FEO hash table size
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- On User 0's parameter line
- Related products
- All
- Introduced
- Model 204 V5.1
Description
The UFEOHASH value represents the number of hash cells that are allocated in the FEO hash table to optimize FOR EACH OCCURRENCE (FEO) loops that are run against unlocked records (FDWOL).
The UFEOHASH parameter can be set to a value between 0 and 65535, inclusive.
- When the UFEOHASH parameter is set to zero, Model 204 does not optimize unlocked FEO loops. FEO loops that are non-optimized scan from the beginning of the record for each occurrence of the field. This can result in significant CPU overhead for FEO loops run against fields with a large number of occurrences.
- A nonzero UFEOHASH value causes Model 204 to build an FEO hash table. As the value of UFEOHASH is used as a hash value divisor, Rocket Software recommends that you set UFEOHASH to a prime number. A number such as 1021 might virtually eliminate non-optimized FEO loops for unlocked records at the cost of only 8,184 bytes of virtual storage.
Understanding the FEO hash table
An FEO table entry contains a file number and record number for a record. Every Table B record is tracked in the FEO table. Whenever a record is modified, the FEO table entry for that record is also updated. FEO processing remembers the FEO table value for the record it is processing. The current table information for a record is checked before each new scan for another field occurrence. If the table information is unchanged, the next scan starts on the record where the previous scan ended. If the table information changed, the next scan must begin at the start of the record.
It is possible that more than one record can map to the same hash cell in the FEO table. Consequently, an update to another record can cause scan from the beginning of the record. Each time a record is scanned from the beginning in response to a change in the value in the FEO table, the UFEOMISS statistic is increased by one.
This optimization is disabled in single-user jobs.
Usage
Setting the value of UFEOHASH should take into account the number of concurrent updates that happen in the Online.
Updates to records in different files may hash to the same FEO slot, as can updates to different records in the same file. These are called hash collisions.
As the value of UFEOHASH is increased, the likelihood of these hash collisions is reduced. Up to a certain point, increasing the value of UFEOHASH tends to improve performance by reducing the number of FEO loops that are not optimized, which are also referred to as unlocked FEO misses. See the UFEOMISS parameter for more information.