Brian Duncombe ([log in to unmask]) wrote:
: Bill Lancaster said some interesting things:
: When I originally evaluated the 3k, I foolishly asked if it had a spooler
: and then checked the box (IBM'res know what a spooler is and assume the rest
                            ^^^                                ^^^^^^^^^^^^^^^
: do also).  A year or so later, I joined the HP field team and submitted a
: lengthy enhancement request detailing how the IBM spooler handled multiple
: input queues and suggesting that this might be a good model.  No response
: since late 1970's.
 
: It seems to me that this would be the spooler's job, not the
: scheduler/dispatcher.  If I could stream a job and specify input-class=AP
: while at the same time, the operator could say streams
10;input-class=AP,max=1
: then when the input spooler went to get the next job to be activated, it
: could honor these specs.  Seemed a simple model to me and still does.
 
Bad assumption.  Although one can make blanket comments about spoolers in
general (such as "they isolate the actual device from the user for various
purposes"), beyond that spoolers are what their creators define them to be.
See the current threads on MPE spooling vs. U*ix lp, for example.  Assuming
that "spooler" == "IBM spooler" leads to the kinds of misunderstandings you
cite.
 
Your comment relates to input spooling (not a highly discussed topic these
days; most people are more interested in the output side).  In MPE's case,
the features of which you speak are *not* the spooler's job.  The input
spooler (or, in this case, the STREAM (note, not STREAMS) command, which
uses lots of input spooler code) is only responsible for copying the user's
input to a spooled $STDIN.  The decision of whether or not to launch the job
once it is streamed is made by job/session code, not the spooler.  It is
this code which would have to be made aware of job queues.
 
It seems to me there are (at least) three possible points of control of jobs
and queues:
o   On the STREAM command, as in your example, where you specify that this
    instance of this job should be subject to queue AP.
o   In the JOB record, for which each instance of the job would be subject
    to the specified queue.
o   In an external configuration, such as a workgroup, where certain
    attributes of the job (USER.ACCOUNT, JOBNAME, etc.) determine queue
    placement.
 
Semantics aside, I agree that some sort of multiple input queue mechanism
would be neat.  The subject has come up from time to time in the lab, and a
couple of engineers prototyped such a beast on their own time once, but for
various reasons (none of which I'm party to), the enhancement has never
survived the cut.
 
-Larry "been known to dabble in input spooling as well occasionally" Byler-