FUNMAXT parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
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 User Language Interface]]
<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==
This is a numeric parameter (with valid values from 0 to 36000) that indicates
<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 User Language Interface]] request is to be given to
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 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 &ldquo;hung up&rdquo;
<var>FUNMAXT</var> is a numeric parameter with valid values from 0 to 36000.
indefinitely while queuing for busy [[Fast/Unload]] tasks or for unintentionally
The default value, 0, means that no time limit is
long-running requests.
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 ''''MaxTime''''
<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
RecordSet class
<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 new sixth parameter on $Funload:
 
<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 ''Fast/Unload'' tasks.
might tie up all the <var class="product">Fast/Unload</var> tasks.
The odds are better if there are more ''Fast/Unload'' tasks (FUNTSKN bigger),
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 ''Fast/Unload'' tasks might have trouble getting
 
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.