In <H00000660008774a@MHS> [log in to unmask] writes:
 
> Jeff wrote:
> > >:ALTJOB on an EXECuting job only requires evaluating whether a different jo
> ob
> > >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.
 
(I know from experience in setting up Spoolmate definitions for spoolfiles
that it took us years to catch all the reports, and even then new reports
would keep popping up as programs were added/modified.)
 
                 -Chris Bartram