UFEOHASH parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (misc formatting)
 
(One intermediate revision by one other user not shown)
Line 15: Line 15:


==Description==
==Description==
<p>The UFEOHASH 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 (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&nbsp;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&nbsp;204</var> does not optimize unlocked FEO loops, which was the behavior of <var class="product">Model&nbsp;204</var> prior to Version 5.1. 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>
 
<li>
<li>A nonzero <var>UFEOHASH</var> value causes <var class="product">Model&nbsp;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&nbsp;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>
===Understanding the FEO hash table===
===Understanding the FEO hash table===
<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>
 
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 UFEOMISS statistic is increased by one.</p>
<p>
<p>This optimization is disabled in single-user jobs.</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==
==Usage==
<p>Setting the value of UFEOHASH should take into account the number of concurrent updates that happen in the Online.</p>
<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 <var class="term">hash collisions</var>.</p>
Setting the value of <var>UFEOHASH</var> should take into account the number of concurrent updates that happen in the Online.</p>
<p>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 <var class="term">unlocked FEO misses</var>. See the <var>[[UFEOMISS parameter|UFEOMISS]]</var> parameter for more information.</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.