On Tue, 16 Jan 1996, Jim Wowchuk wrote:
> At 04:12 PM 15/1/96 -0800, Stan Sieler wrote:
> [example deleted....]
> >In summary, this is *important* : You need to be able to change the queue
> >of an existing job!
>
> I respectfully disagree.  A similar situation could be described for output
> print queues, that is, a need to be able to change the queue of a printing
> spoolfile.  But the fact of the matter is that when the spoolfile is
> printing IT IS NO LONGER IN THE QUEUE!  I believe the same view to be true
> about the job queues:  when a job is executing it is not in the queue - it
> is simply denying the resource for the others in the queue.
>
> Besides there must have been a reason in your example to put the big job in
> the SINGLETHREAD QUEUE, such as that nothing else is to run - in particular
> the 237 other jobs that came after it!  Otherwise, why not run the big job
> from another queue?
 
Maybe there is a reason, and maybe some faulty logic was applied.  Or,
maybe someone just made a big mistake!
 
> Perhas the best solution then is to have a command to allow you to easily
> move the waiting jobs to another queue.
 
That still doesn't address the jobs that continue to be streamed after
"easy" movement procedure.  And then, once the hog logs off, we have
jobs that should be single threaded and in one queue, sitting in two
queues and potentially running parallel.
 
From an operational standpoint, the altering of jobs in EXEC makes
life easier for the Operator.  The penalty is ...
 
  1)  Cost and complexity of implementation
  2)  Smoething else that I'm not seeing?
 
Regards,
 
--- John Joerger  ([log in to unmask])  ---  Press-Telegram (Long Beach)