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