OK, an advance prelude to a possible followup :-)
 
On Fri, 12 Jan 1996 22:47:01 -0400 Chris Bartram said:
> In <H00000660008774a@MHS> [log in to unmask] writes:
>>Jeff wrote:
>>>>:ALTJOB on an EXEC job only requires evaluating whether a different job
>>>>can now launch because we just freed up a slot in the queue we were in.
>>>
>>> Yuck... I see no need to alter the queue after the job reaches INTRO/EXEC.
>>> No, no, no; overly complicating things.
>>
>> Hmmm. Ok, maybe.  The desire to move a job from the SHORT queue to the LONG
>> queue once it is determined that it's really going to take three hours
>> instead of three minutes seems pretty basic though. The alternative is to
>> increase the LIMIT on the SHORT queue by one, but then you have the problem
>> that when the job finishes, the limit on SHORT is one too high.  This is
>> exactly the kind of problem this enhancement is trying to address.  I think
>> at least as many changes will be made with :ALTJOB to running jobs as to
>> waiting jobs.
>
>There's going to be a period of time (maybe years...?) when there will be
>jobs found hiding somewhere that weren't properly defined in the new queue
>structure. As fast as some systems are, it's likely that some/most of these
>jobs are actually going to go "EXEC" before you notice they're not in the
>appropriate queue.
 
OK, in Gavin's case, moving the job from SHORT to LONG is just semantics;
why did you bother to define a SHORT queue if you had no intention of somehow
enforcing the fact that it was indeed intended for SHORT jobs?  The idea is
to get the SHORT queue jobs lauched ahead of other things.
 
What do you do when you change an executing job's queue and the target queue
is full?  If the maxpri is less than the original?  If the user.acct doesn't
have access to that queue (well, OP/SM is what I guess we're talking about).
 
In all cases, it still sounds like it boils down to you want a job to run
RIGHT NOW.  If you play with limits, or queue shuffling, other jobs can stop
and/or start and it might not produce the desired result.  My suggestion was
that if you wanted a job to run RIGHT NOW, then define a queue that has by
default a ;HIPRI associated with it.  No limit changes, the job just goes.
You can't :ALTJOB a job now unless it's in WAIT state, why start now?  The
purpose of multiple queues is to manage job scheduling.  A job that is
already running is no longer a scheduled job.
 
With that said, I'm not necessarily *opposed* to altering an EXEC job, I was
trying to make things easier on the lab.  It would seem that by proper queue
definitions you could accomplish your goals.  Both approaches are to bypass
a "temporary" limit problem.  What about :LIMIT +1;QUEUE=FAST;WHILE=#Jnnn ?
(Increase limit by 1 until #Jnnn terminates?)  I know, that's probably even
more difficult, but it's more like what we really want (I think).
 
Jeff Kell <[log in to unmask]>