🚀 go-pugleaf

On Thu, 20 Feb 1992 20:43:30 EST Kent Fiala said:
>We observe that when jobs are being submitted to VMBATCH very rapidly,
>completion of worker initialization is suppressed.  In an example case I
>followed today, a user ran an exec that submitted 76 jobs within 15
>minutes.  Jobs that were begun on workers during that time, and even for
>a while after, got as far as having the worker autologged and the
>SERVICE macro entered, but the SERVICE macro did not complete for a very
>long time -- as much as 30 minutes.  During this time the jobs were
>simply shown as being in initialization status.  It eventually got to
>the point where there were no workers actually running jobs.
>
>We see this as a serious problem.  Systems Center's response is that
>it's just the way it's designed, and they aren't particularly inclined
>to change the design.  Does anyone else see it as a problem?
>
>------------------------------------------------------------------------
>Kent Fiala <snoklf@vm.sas.com>
>SAS Institute Inc., Cary NC 27513 USA                 919-677-8000 x6646

We didn't observe this, but there are at least two ways for a
VMBATCH-macro to give control to other VMBATCH-processes:

'TEST PROCESS SWITCH'
 places the calling macro at the end of the "ready queue"
 and gives control to another process.
'TEST PROCESS WAIT n'
 waits n seconds to give other processes a chance.

One of these should help to speed down the SUBMIT- or SUBXX-activity,
so other activities like initializing get a chance to continue working
between SUBMITs or during one SUBMIT (if you find and break up the
timeconsuming sequence of primitives).

                                 J. Hattenbach