Jim writes:
> The situation today is not a mistake but a system administration problem -
> the alternatives are limited, but if we need a 'big job' to run, then it
> must run and we need to alter limits, priorities or whatever to get the
> others to run. I see this as far different from handling mistakes.
>
> What you propose sounds like an attempt to make the system (more)
> fool-proof. While this is admirable in thought, I fear the deed.  Remember
> the saying "Nothing is fool-proof, because fools are so ingenious!"?
> Mistakes such as streaming a big-job will happen, but the means to handle
> them are there already, e.g. abort the job, alter the limits, sack the
> programmer. :)  IMHO catering to all possible _mistakes_ will lead to bigger
> difficulties later on.
 
But moving the job from the wrong queue to the right queue is such an obvious
straight forward thing to want to do (and it really does not significantly
complicate the implementation), that I can't understand what the benefit is
to preventing people from doing something that they are going to want to do.
 
> >It's silly to try to
> >compare output and input spooling!
>
> Again I disagree.  These items are recognized by the more they share in
> common than by their differences.  Queues are just a form of simple linear
> lists.  As D.Knuth says "Too many people unfortunately still feel that List
> processing techniques are quite complicated... We will see that there is
> nothing magic, mysterious, or difficult about the methods for dealing with
> complex structures;...".
 
Fooey.  Changing the print queue of an ACTIVE spoolfile means stopping output
on one printer and starting over on another printer.  For the act of altering
the queue association of an executing job to be equivalent to this, it would
have to mean that you were aborting the job and re-streaming it from scratch
on another system!
 
G.