FUNMAXT parameter: Difference between revisions
(Automatically generated page update) |
mNo edit summary |
||
| Line 13: | Line 13: | ||
<dd><var class="product">[[Sirius Mods]]</var> 6.7 | <dd><var class="product">[[Sirius Mods]]</var> 6.7 | ||
</dl> | </dl> | ||
==Description== | ==Description== | ||
This is a numeric parameter (with valid values from 0 to 36000) that indicates | This is a numeric parameter (with valid values from 0 to 36000) that indicates | ||
| Line 18: | Line 19: | ||
complete. | complete. | ||
The timer starts from the initiation of the request, either via $Funload, | The timer starts from the initiation of the request, either via $Funload, | ||
or via the | or via the <var>FastUnload</var> and <var>FastUnloadTask</var> methods | ||
in the RecordSet class. | in the <var>RecordSet</var> class. | ||
The default value of FUNMAXT, 0, means that there will be no time limit | The default value of <var>FUNMAXT</var>, 0, means that there will be no time limit | ||
placed on | placed on <var class="product">Fast/Unload User Language Interface</var> requests. | ||
The purpose of FUNMAXT is to prevent user requests being “hung up” | The purpose of <var>FUNMAXT</var> is to prevent user requests being “hung up” | ||
indefinitely while queuing for busy [[Fast/Unload]] tasks or for unintentionally | indefinitely while queuing for busy [[Fast/Unload]] tasks or for unintentionally | ||
long-running requests. | long-running requests. | ||
FUNMAXT can be overridden for specific requests by using either of these: | <var>FUNMAXT</var> can be overridden for specific requests by using either of these: | ||
<ul> | <ul> | ||
<li>The | <li>The <var>MaxTime</var> | ||
named parameter on the FastUnload and FastUnloadTask methods in the | named parameter on the <var>FastUnload</var> and <var>FastUnloadTask</var> methods in the | ||
R<var>ecordSet</var> class | |||
<p class="code">* Make sure request completes in one minute | <p class="code">* Make sure request completes in one minute | ||
%rc = %recset:funload(%inList, %outList, %reportList, 'NEBUFF=10', maxtime=60) | %rc = %recset:funload(%inList, %outList, %reportList, 'NEBUFF=10', maxtime=60) | ||
</p> | </p></li> | ||
<li>The | |||
<li>The sixth parameter on <var>$Funload</var>: | |||
<p class="code">* Make sure request completes in one minute | <p class="code">* Make sure request completes in one minute | ||
%rc = $funload('LABEL', %inList, %outList, %reportList, 'NEBUFF=10', 60) | %rc = $funload('LABEL', %inList, %outList, %reportList, 'NEBUFF=10', 60) | ||
</p> | </p></li> | ||
</ul> | </ul> | ||
A reasonable strategy would be to set FUNMAXT to a fairly low value, then | A reasonable strategy would be to set <var>FUNMAXT</var> to a fairly low value, then | ||
selectively set it higher for requests that need more time. | selectively set it higher for requests that need more time. | ||
Of course, it can be very difficult to ensure that short-running requests | Of course, it can be very difficult to ensure that short-running requests | ||
complete quickly, if the Online also has long-running requests that | complete quickly, if the Online also has long-running requests that | ||
might tie up all the | might tie up all the <var class="product">Fast/Unload</var> tasks. | ||
The odds are better if there are more | The odds are better if there are more <var class="product">Fast/Unload</var> tasks (<var>FUNTSKN</var> bigger), but even with more tasks, these potential problems remain: | ||
but even with more tasks, these potential problems remain: | |||
<ul> | <ul> | ||
<li>If there are enough long running requests, all tasks might be | <li>If there are enough long running requests, all tasks might be | ||
tied up, anyway. | tied up, anyway. </li> | ||
<li>Some of the | |||
dispatched because there are more of them than CPUs to run them. | <li>Some of the <var class="product">Fast/Unload</var> tasks might have trouble getting | ||
dispatched because there are more of them than CPUs to run them. </li> | |||
</ul> | </ul> | ||
[[Category:System parameters]] | [[Category:System parameters]] | ||
[[Category:Parameters]] | [[Category:Parameters]] | ||
[[Category:Fast/Unload User Language Interface]] | [[Category:Fast/Unload User Language Interface]] | ||
Revision as of 18:35, 11 November 2014
Default Fast/Unload request timeout (seconds)
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- System manager resettable
- Related products
- Fast/Unload User Language Interface
- Introduced
- Sirius Mods 6.7
Description
This is a numeric parameter (with valid values from 0 to 36000) that indicates the maximum amount of time, in seconds, a Fast/Unload User Language Interface request is to be given to complete. The timer starts from the initiation of the request, either via $Funload, or via the FastUnload and FastUnloadTask methods in the RecordSet class. The default value of FUNMAXT, 0, means that there will be no time limit placed on Fast/Unload User Language Interface requests.
The purpose of FUNMAXT is to prevent user requests being “hung up” indefinitely while queuing for busy Fast/Unload tasks or for unintentionally long-running requests.
FUNMAXT can be overridden for specific requests by using either of these:
- The MaxTime
named parameter on the FastUnload and FastUnloadTask methods in the
RecordSet class
* Make sure request completes in one minute %rc = %recset:funload(%inList, %outList, %reportList, 'NEBUFF=10', maxtime=60)
- The sixth parameter on $Funload:
* Make sure request completes in one minute %rc = $funload('LABEL', %inList, %outList, %reportList, 'NEBUFF=10', 60)
A reasonable strategy would be to set FUNMAXT to a fairly low value, then selectively set it higher for requests that need more time. Of course, it can be very difficult to ensure that short-running requests complete quickly, if the Online also has long-running requests that might tie up all the Fast/Unload tasks. The odds are better if there are more Fast/Unload tasks (FUNTSKN bigger), but even with more tasks, these potential problems remain:
- If there are enough long running requests, all tasks might be tied up, anyway.
- Some of the Fast/Unload tasks might have trouble getting dispatched because there are more of them than CPUs to run them.