UFEOHASH parameter - Revision history

JAL: misc formatting

2017-10-16T17:08:19Z

misc formatting

← Older revision		Revision as of 17:08, 16 October 2017
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 ([[FD,~~_FDWOL~~,~~_or_FDR_~~-~~_Find_to_recordset~~\|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~~, which was the behavior of <var class="product">Model 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 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>

	===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]]

DCameron: /* Description */

2017-10-12T14:45:05Z

Description

← Older revision		Revision as of 14:45, 12 October 2017
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>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 ([[FD,_FDWOL,_or_FDR_-_Find_to_recordset\|FDWOL]]). </p>
	<p>The UFEOHASH parameter can be set to a value between 0 and 65535, inclusive. </p>		<p>The UFEOHASH parameter can be set to a value between 0 and 65535, inclusive. </p>
	<ul>		<ul>

DCameron: /* Description */

2017-10-12T14:42:41Z

Description

← Older revision		Revision as of 14:42, 12 October 2017
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 FOR EACH OCCURRENCE (FEO) loops that are run against unlocked records (FDWOL). </p>		<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>The UFEOHASH parameter can be set to a value between 0 and 65535, inclusive. </p>		<p>The UFEOHASH parameter can be set to a value between 0 and 65535, inclusive. </p>
	<ul>		<ul>

DCameron: /* Summary */

2017-10-12T14:33:38Z

Summary

← Older revision		Revision as of 14:33, 12 October 2017
Line 11:		Line 11:
	<dd>All		<dd>All
	<dt>Introduced		<dt>Introduced
	<dd><var class="product">Model 204 V6.1</var> ~~or earlier~~		<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>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>

ELowell: adding Usage section and text that seems to have been missed during wiki conversion

2017-03-30T22:53:51Z

adding Usage section and text that seems to have been missed during wiki conversion

← Older revision		Revision as of 22:53, 30 March 2017
Line 22:		Line 22:
	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>		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>
	====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>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>This optimization is disabled in single-user jobs.</p>		<p>This optimization is disabled in single-user jobs.</p>

			==Usage==
			<p>Setting the value of UFEOHASH 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 <var class="term">hash collisions</var>.</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>

	[[Category:System parameters]]		[[Category:System parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

DmeWiccan: Automatically generated page update

2013-08-27T16:49:12Z

Automatically generated page update

← Older revision		Revision as of 16:49, 27 August 2013
Line 1:		Line 1:
			{{Template:UFEOHASH parameter subtitle}}
	==Summary==		==Summary==
	<dl>		<dl>

DmeWiccan: Automatically generated page update

2013-04-23T01:51:38Z

Automatically generated page update

← Older revision		Revision as of 01:51, 23 April 2013
Line 25:		Line 25:
	<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>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>This optimization is disabled in single-user jobs.</p>		<p>This optimization is disabled in single-user jobs.</p>
	[[Category:System ~~Parameters~~]]		[[Category:System parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

Dme: Undo revision 56980 by DmeWiccan (talk)

2013-04-19T14:53:14Z

Undo revision 56980 by DmeWiccan (talk)

← Older revision		Revision as of 14:53, 19 April 2013
Line 25:		Line 25:
	<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>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>This optimization is disabled in single-user jobs.</p>		<p>This optimization is disabled in single-user jobs.</p>
	[[Category:System ~~parameters~~]]		[[Category:System Parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

DmeWiccan: Automatically generated page update

2013-04-19T14:39:17Z

Automatically generated page update

← Older revision		Revision as of 14:39, 19 April 2013
Line 25:		Line 25:
	<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>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>This optimization is disabled in single-user jobs.</p>		<p>This optimization is disabled in single-user jobs.</p>
	[[Category:System ~~Parameters~~]]		[[Category:System parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

Alex: Automatically generated page update

2013-02-28T00:57:11Z

Automatically generated page update

New page

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>On User 0's parameter line
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204 V6.1</var> or earlier
</dl>
==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. 
<ul>
<li>
When the UFEOHASH parameter is set to zero, <var class="product">Model 204</var> does not optimize unlocked FEO loops, which was the behavior of <var class="product">Model 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>
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>
====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.
[[Category:System Parameters]]
[[Category:Parameters]]