Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!pesnta!hplabs!ucbvax!ARIZMIS.BITNET!JMS
From: JMS@ARIZMIS.BITNET.UUCP
Newsgroups: mod.computers.vax
Subject: RE: Job Queue Monitor
Message-ID: <8605261204.AA21609@ucbvax.Berkeley.EDU>
Date: Sat, 24-May-86 16:25:00 EDT
Article-I.D.: ucbvax.8605261204.AA21609
Posted: Sat May 24 16:25:00 1986
Date-Received: Mon, 26-May-86 18:52:00 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 37
Approved: info-vax@sri-kl.arpa

In re: the fellow that wanted to have two batch queues, with some sort
of adminstrative system where the system tells him who the hogs
are, and he can squash them.

It all depends on your system philosophy.  In order to provide a
minimum of friction and let the system 'run itself,' the University
of Arizona has a time limit on batch queues.  Thus, whatever image
is executing when the time limit expires aborts, and the whole
batch job goes down the drain.  There's a nice informative message
in the batch log for jobs that hit the wall time-limit-wise.

I believe that it will only take once for batch queue users to get
this message before they begin to use the slower queue for long
jobs.

The beauty of letting VMS do the work is that the system does the correction
and not the 'system manager.'  Our experience is that the less
a 'system manager' tells the people who own the VAX what to do with
their resources, the happier the people who own the VAX (often
called 'my users' by system managers) will be.

On a related note, it's good to put some reasonable time limit on
batch queues ANYWAY; in a University environment without heavy OR
people, 24 hours is as good a limit as any.  Then, someone who lets
loose a batch job with an infinite loop in it (and doesn't know
how to kill the job, or doesn't realize) is self-corrected.  Typically,
we have established a DEFAULT maximum CPU time of 24 hours, and an
ABSOLUTE MAXIMUM CPU time of 1 week.  Thus, unless you KNOW you're
job is going to run long, you don't pay attention to CPULIMIT switches,
and the system protects itself and you.

jms

Joel M Snyder
University of Arizona Department of MIS
Tucson, Arizona 85721  (602) 621-2748
JMS@ARIZMIS.BITNET