Bruce writes:
> Why not have LIMIT 0 work as it does today? The major concern seems to be
> the loss of the ability to say "No more jobs, except HIPRI." Let :LIMIT
> with no parameters control the default queue, except LIMIT 0 means what it
> does today: no jobs from any queue. This will make command files, etc.,
> work the way they do today. If you really want to change the limit on the
> default queue and no other, use LIMIT 0;QUEUE=DEFAULT (or whatever).
>
> This seems inelegant, but it breaks no scripts and requires no operator
> retraining, even when the system manager has elected to create multiple
> queues. LIMIT 0 stops jobs, and LIMIT n restores normal job scheduling (in
> addition to setting the limit on the default queue).
 
I like this.  There could be a global 'User Job Queues Enabled'
flag.  When this flag is 'TRUE', jobs are alowed to log on from non-default
queues.  When this is 'FALSE', user queues behave as though their limits
were all zero (though they actually retain their last set limit value).
 
The :LIMIT command without a ;JOBQ= option would have the following special
case logic added to it:
 
IF new-system-limit <= 1, THEN
  UserJobQueuesEnabled := FALSE
ELSE
  UserJobQueuesEnabled := TRUE
 
Now a :LIMIT 0 means what it always has, that no new jobs should log on,
and also :LIMIT 1 means what it always has, that only one job may run at
a time and only from the system default queue. A subsequent :LIMIT 3
command (or any number >1) would re-enable all the other queues to their
previous limit value.
 
To avoid confusion about why jobs are not logging on from user queues, the
STATUS part of the :SHOWJOB command should indicate the state of the
UserJobQueuesEnabled flag.
 
Complicating factors: It would probably be advantageous to provide a way of
turning this flag on and off at will (perhaps even instead of the rather
kludgy special case logic for :LIMIT 0 and :LIMIT 1).  There will be caases
where people would like to see the same behavior for :LIMIT 2 (or 3, etc.),
so perhaps the only special case should be :LIMIT 0, and anything else
would require manually twiddling the UserJobQueuesEnabled flag.
 
What do you think?
 
G.