FUNMAXT parameter

From m204wiki
Revision as of 18:07, 29 March 2016 by JAL (talk | contribs) (minor wordsmithing)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.