Mike writes:
> I think Steve makes a good case (as someone said ealier, as well) that
> the LIMIT command should NOT set a limit on the total number of jobs
> allowed on the system.  That is, "LIMIT 20" would set the LIMIT for the
 
Actually, I think there *should* be the ability to have a system-wide
limit, in addition to a per-queue limit.  I'm willing to have queues
that ignore (and don't count against!) the system-wide limit (per Steve)...
but I do want to see a system-wide limit such that:
 
   1) excluding Steve's "daemon" queue, JOB will never start a job from
      any queue if the # jobs running is >= system-wide-limit
      (unless HIPRI is used, of course)
 
   2) only when the system-wide limit allows would JOB say "ok, which
      ready-to-run job should I pick to start"?  At that point some kind
      of priority criteria (queuer ordering) is used to govern the
      order in which the queues are scanned OR chronology is used:
 
      2a) (priority)
          Queues have a priority (either an explicit value, or the
          order in which defined/created ... if two queues have the
          same explicit value, then the order of creation is used).
 
          The queue with the highest priority that has less jobs than
          the limit (for *that* queue) and has a job ready to start is
          chosen.
 
          The highest INPRI set of read-to-run jobs in that queue is chosen.
          Of those, the "oldest" is started.
 
      2b) (INPRI and then age)
 
          The queues who are below their limits are chosen.
          Of those, the highest INPRI jobs are chosen.  The highest INPRI
          wins.  In case of a tie, the "oldest" wins.
 
 
Why do I want a system limit?  Let's say the system has begun to bog
down...if I have  9 jobs running, and 20 different queues, it would be silly,
and perhaps incorrect, for me to simply reduce the limit of each queue by 1.
Instead, if my system limit is 9, then I'd simply decrease the system limit
to 8.  When one of the existing 9 finishes, a new one *won't* be started.
If the system is still bogged down, I'll reduce the limit again.
 
Of course, this asumes that I didn't notice that one of the 9 is
a high-priority compilation job running under GAVIN.SCOTT ... I could always
do a BREAKJOB to let the other's get some CPU time :)
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html