Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!AC.UK!SYSMGR%UK.AC.KCL.PH.IPG
From: SYSMGR%UK.AC.KCL.PH.IPG@AC.UK.UUCP
Newsgroups: mod.computers.vax
Subject: I'd recommend low-priority batch jobs too
Message-ID: <8703210716.AA08167@ucbvax.Berkeley.EDU>
Date: Sat, 21-Mar-87 03:01:17 EST
Article-I.D.: ucbvax.8703210716.AA08167
Posted: Sat Mar 21 03:01:17 1987
Date-Received: Sun, 22-Mar-87 21:46:15 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 17
Approved: info-vax@sri-kl.arpa

I'd second John's comments about low priority batch jobs being a good
thing, provided you put a little effort into managing them.

Incidentally you don't need to write a program to suspend them when the
system gets busy; STOP/QUEUE will do that for you, so all you need is
a simple DCL procedure to detect an overloaded system (or to brief your
operators) (if you have operators).

If you enable working-set decrementing, you will find that many compute-
limited jobs will voluntarily decrement all the way down to 100 pages
or less; these can be left to soak up any spare time, leaving you with
a 100% utilised system, like ours at the moment...

Nigel Arnot (Dept. Physics, Kings college, Univ. of London;  U.K)

Bitnet/NetNorth/Earn:   sysmgr@ipg.ph.kcl.ac.uk (or) sysmgr%kcl.ph.vaxa@ac.uk
       Arpa         :   sysmgr%ipg.ph.kcl.ac.uk@ucl-cs.arpa