FUNMAXT parameter: Difference between revisions
m (→Description) |
m (minor wordsmithing) |
||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{Template:FUNMAXT parameter subtitle}} | |||
==Summary== | ==Summary== | ||
<dl> | <dl> | ||
| Line 8: | Line 9: | ||
<dd>System manager resettable | <dd>System manager resettable | ||
<dt>Related products | <dt>Related products | ||
<dd>[[Fast/Unload | <dd>[[Fast/Unload SOUL Interface]] | ||
<dt>Introduced | <dt>Introduced | ||
<dd><var class="product">Sirius Mods</var> 6.7 | <dd><var class="product">[[Sirius Mods]]</var> 6.7 | ||
</dl> | </dl> | ||
==Description== | ==Description== | ||
<var>FUNMAXT</var> specifies the maximum amount of time, in seconds, a <var class="product">[[Fast/Unload SOUL Interface]]</var> (FUSI) request is to be given to complete. | |||
the maximum amount of time, in seconds, a [[Fast/Unload | The timer begins when the FUSI is requested, by <var>[[$Funload]]</var> or by the <var>[[FastUnload (Recordset function)|FastUnload]]</var> and <var>[[FastUnloadTask (Recordset function)|FastUnloadTask]]</var> methods in the <var>Recordset</var> class. | ||
complete. | |||
The timer | |||
or | |||
in the | |||
<var>FUNMAXT</var> is a numeric parameter with valid values from 0 to 36000. | |||
The default value, 0, means that no time limit is | |||
placed on <var class="product">FUSI</var> requests. | |||
FUNMAXT can be overridden for specific requests by using either of these: | The purpose of <var>FUNMAXT</var> is to prevent user requests being "hung up" | ||
indefinitely while queuing for busy <var class="product">[[Fast/Unload]]</var> tasks or for unintentionally long-running requests. | |||
<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 | ||
<var>Recordset</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 (larger value for the <var>[[FUNTSKN parameter|FUNTSKN]]</var> parameter), 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 SOUL Interface]] | |||
Latest revision as of 18:07, 29 March 2016
Default Fast/Unload request timeout (seconds)
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- System manager resettable
- Related products
- Fast/Unload SOUL Interface
- Introduced
- Sirius Mods 6.7
Description
FUNMAXT specifies the maximum amount of time, in seconds, a Fast/Unload SOUL Interface (FUSI) request is to be given to complete. The timer begins when the FUSI is requested, by $Funload or by the FastUnload and FastUnloadTask methods in the Recordset class.
FUNMAXT is a numeric parameter with valid values from 0 to 36000. The default value, 0, means that no time limit is placed on FUSI 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 (larger value for the FUNTSKN parameter), 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.