[My participation in this discussion is as an interested party, not
one of the developers, which I'm not.]
 
Some comments:
 
1)  My first reaction to the proposal was that restricting users to
    the use of certain queues is extra development work that will be of little
    value.  [I didn't notice that a user could be a member of only one
    queue at a time...which, I agree, wouldn't solve most problems.]
    Would those of you who feel otherwise, about restricting users to a set
    of job queues, give us some examples of how you would use this feature?
 
2)  To me, :STREAM <file>;QUEUE=<queue> should mean that the STREAM command
    overrides the :JOB card.  [This comes from Gavin's subsequent post
    with a different subject line.]  Why else would the user be putting the
    QUEUE name on the STREAM command?  The QUEUE name on the :JOB card(s) [note
    that a STREAM file can have multiple jobs within it...also, should we
    still be calling it a JOB "card"] was put there in the past.  The STREAM
    command is the most recent action being performed by the user.  Also,
    this is the only way for the user to have a choice of which queue to place
    the job into without editing the STREAM file [a stronger argument I
    suspect.]
 
3)  I agree with Gavin; let's be careful not to overload the Multiple Job
    Queues project with tasks that more correctly belong in the Workload
    Manager.  All we're really discussing here is how to manage the
    WAIT queue for the job "dispatcher".  It probably makes sense for the Job
    Queue to be one of the attributes of a workgroup.
 
4)  Now to the meat of what I wanted to say.  Picking between Mohan's
    proposal and Gavin's proposal really comes down to future flexibility
    vs. minimizing change.  [I think it's up to you as users to decide
    which way we go on this one.]  Gavin's proposal integrates a basic
    job queue facility into the existing MPE command set in a straightforward
    way.  But, it doesn't allow for much flexibility for defining other
    attributes of queues in the future.  I offer the following example:
 
       While I was in college [at U-M, that's University of Michigan for those
       who thought otherwise], our Amdahl's ran MTS, the Michigan Terminal
       System.  [An OS that was written because IBM was too slow in
       releasing OS/360...or was that TS/360.]  The job queues were based on
       the amount of CPU time you said your job would take.  In MPE terms,
       if you put TIME=5 on the :JOB command, then you went into the fast
       queue.  If you put TIME=600, then you went into the slow queue.  Jobs
       were selected for introduction into the system based on which queue
       you were in.  [I don't remember the algorithm anymore.]  You couldn't
       lie about the time your job took since, like MPE, it was aborted after
       it used that amount of CPU time.
 
    Gavin's proposal wouldn't allow for this kind of extension within it's
    framework.  With Mohan's proposal, it would simply be a matter of adding
    extra syntax to the contents of the queue definition file (and of course
    adding the OS code.)
 
    So, I'd like to see some discussion, and opinions, about the trade-off
    between a basic facility, as Gavin proposes, vs. an extensible facility,
    as Mohan initially proposed.
 
5)  Finally, the other thing to remember in this discussion is that SIGMPE was
    promised an investigation into a *basic* facility for managing multiple
    job queues.  Both Gavin's and Mohan's proposals qualify, at this point.
    As others propose additional features, we should ask and attempt to answer
    whether the feature is required for the system manager/operator/user to
    perform the tasks required to manage & use multiple job queues.
 
Mike P.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Paivinen
[log in to unmask]
 
Hewlett-Packard
CSY - Mailstop 47UP
19447 Pruneridge Avenue
Cupertino, CA   95014