At 06:09 PM 1/12/96 +0500, Mohan Das wrote:
>   The hierarchy will be:
>
>   1. ;JOBQ= specified in :STREAM command, if any
>   2. else ;JOBQ= specified in !JOB command, if any
>   3. else a default job Q based on some membership criteria, if any specified
>   4. else the system default Q, $SYSJOBQ.
>
>   Queue to which a job should belong to is decided by applying the above 4
>   criteria,  in that order.  (Some  people might argue for swapping 1 & 2,
>   though.  We need to decide on that).
 
The order you list (1,2,3,4) makes the most sense to me.
 
>2. There are two opinions on the mechanism for  determining the default job
>   queue (in cases when no job queue is specified in either !JOB or :STREAM
>   command).
>
>   1. Default job queue based on user.acct
...
>   2. Some respondents  feel they need more  granularity in determining the
>      default  queue and they are of the opinion that it should be based on
>      "jobname,user.acct,group".
...
>   We need to  decide if the extra  control  gained  by  option 2 is really
>   needed,  even  when  there is an option  of  explicitly  specifying  the
>   queuename in the job cards itself.
 
This will only be critical if there are users who have no way of modifying
their third-party job cards or stream commands.  This is not a problem for
us, so I would place some of the other components of this proposal at a
higher priority.  Among them, if we go with the ":altuser ;jobq=" model, I
would also like to see either ":altacct ;jobq=" or wildcard capability on
:altuser (or both!).
 
>3. Some people have asked for  properties  like jobfence and input priority
>   (default and  maximum) to be different  for each queue  instead of being
>   same across all the queues.  We would really appreciate feedback on this
>   matter.
 
Multiple jobfence/defpri/maxpri settings are not essential for us.
 
>4. Should  there be any  relative  priority  across  the queues in terms of
>   selecting the next job to run ?
...
>   1. Should  it be based on some  pre-defined  priority  between  queues ?
...
>   2. Should it be based on INPRI and temporal  order across all the queues?
 
#2 is acceptable, and I suspect the easiest to implement.  How does the
output spooler handle this scenario?  If more than one device class points
to the same physical printer, what determines which spoofle prints first?
 
Just to make sure I understand - are we proposing that :LIMIT without a
;JOBQ specification will still set the 'global' limit which is enforced
across all queues, and that :LIMIT ;JOBQ=$SYSJOBQ would affect a separate
limit which applies only to jobs not streamed to a specific user-defined
queue?  I think this is what we would want.
 
>6. Do the majority of system  administrators  on this list want the ability
>   to *restrict* users to a queue or set of queues ?  That is, now that the
>   users  have the  option of  specifying  any  queue  they want in the job
>   command, do you want to have the ability to say, "No, you're not allowed
>   in this Queue"  through ACD or any other  mechanism  ?  I haven't  heard
>   anybody saying so far, that they really need this security feature.
 
I don't think we'll desperately *need* this, but I just thought of another
possible mechanism to implement it.  If a new system-defined CI variable
named HPJOBQ were introduced which holds the name of the queue to which the
currently executing job was :STREAMed, then a logon UDC could do things like
this:
 
  IF HPJOBQ = "SPECIALQ" and HPUSER <> "MGR" THEN
    ECHO Job was :STREAMed to a restricted Queue - aborting...
    EOJ
  ENDIF
 
I still think ACDs are the 'right' way to do it, but if the above is easier
it might be adequate.  In fact, I would recommend creation of an HPJOBQ
variable even if ACDs are implemented also, and probably another one called
HPDEFJOBQ which would hold the name of the default jobq for jobs streamed by
the current user.  You can never have too many CIVARs, right? :>
 
>7. Is the ability to transfer jobs from one queue to another while the
>   job is waiting needed ? Like,
>
>   :ALTJOB #J12;QUEUE=JOBQ1
>
>   Some of you have mentioned it, but I just want to know if it is
>   really essential.
 
Right now, if I want to allow a job to 'cut' in line, I have to raise its
priority and temporarily alter the :LIMIT to let it through.  It would be
nice to have this feature in one command, i.e. :ALTJOB
#J12;INPRI=HIPRI;JOBQ=NOW.  Furthermore, it would be nice if this worked on
currently executing jobs as well.  If I stream a job to FASTQ and later
realize that it is running longer than I expected, I could :ALTJOB it to the
SLOWQ to be courteous to other incoming FASTQ jobs.
 
Another item to add to the list of somewhat unresolved questions is what
changes to make to :SHOWJOB related to queues.  I vote for a ;format=jobq
option to show all jobs (or selected job(s) according to existing :showjob
syntax) including which jobq they are in, and a ;jobq= option to select only
jobs in a certain queue.  If ;jobq=xxx is used in conjunction with STATUS
then totals for that queue only should be shown.  If ;jobq=@ is used in
conjonction with STATUS then a breakdown of totals by queue should be
included in the STATUS listing, in addition to the global status totals.
 
Thanks again, Mohan, for your diligence in soliciting and processing our
suggestions.
 
  -----------------------------------------------------------------------
               Jon Diercks -------- mail: [log in to unmask]
        Programmer/Analyst   /||  | chat: powwow:[log in to unmask]
        Computing Services  /_||  | WWW : http://rowlf.csv.anderson.edu/
       Anderson University /  ||__| tel : (317)641-4305
        Anderson, IN 46012 -------- fax : (317)641-3851
    o________________________________________________________  ___
    _\_,                                                     \=`==^==>
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^