Jim Wowchuk writes:
 
[snip]
 
 > >Job Queue Properties:
 > >--------------------
 > >1. Queue name - A name to identify the queue.  The naming  convention  will
 > >   be same as  existing  rules for MPE file  names.  The Queue  name can be
 > >   given by the system  administrator  when  creating the Queue and will be
 > >   used to refer to the queue in all other commands.
 >
 > So a name the same format as a printer queue name, right?  MPE Namespace name?
 
Yes.
 
 > >   By default, one job queue will exist (similar to the currently  existing
 > >   job queue).  This queue is called  SYSJOBQ.  This queue cannot be purged
 > >   or renamed.
 >
 > Theoretically I can rename my LP print queue, so why not this one?  If so
 > then give it a simpler name - JOBQ.  Let people will rename it if they don't
 > like it ('specially good for non-English speaking folks!)
 
Because we didn't see any great value in being able to rename the
default queue. But, if there is some benefit, then probably we will
consider providing that ability.
 
 > >2.  User class - Set of users who can stream jobs in this queue.
 >
 > Again, I think it is possible to restrict print queues to specific users
 > and/or accounts, but I don't think it is common.  I can see merit that some
 > job queues may be restricted to an account. So the default should be that
 > all queues are open, but they may be altered to restrict them to certain
 > users and groups of users.
 
Having a set of users as members of a particular queue is to provide
the system a way to map jobs to queues. Please see my other mail on
this thread for a detailed explanation of our assumptions.
 
 > >
 > >   The membership can be specified in one of the following ways (we need to
 > >   decide which of these approaches to adopt) :
 >
 > Is there not already a method in place for print queues.  If so then use that.
 > [snip...]
 
As you mentioned below, we wanted to avoid rebooting the system for
every change in membership, hence this mechanism.
 
 > >
 > >   2. This could be part of NEWJOBQ and ALTJOBQ commands with a parameter
 > >      ;USERS=<User list>.
 >
 > The use of a NEWJOBQ and ALTJOBQ command by sysop or sysmgr would be much
 > appreciated over the current print queue methods of sysgen & re-boot! :)
 
 > >
 > >   Each  user can be a  memeber  of only one Q at any point of time.  Users
 > >   without any specified Q membership will belong to the general SYSJOBQ by
 > >   default. If any Q is deleted,  all the  members of that queue lose their
 > >   membership and will belong to the general job queue.
 >
 > NO, NO, NO!!!  Just as a user can use multiple printer queues, they should
 > have access to multiple job queues.  Alter the :STREAM and !JOB commands
 > accordingly to accept optional INPUTQ parameters.  If not INPUTQ is
 > specified, then use the system default.
 
As I mentioned in my other mail (in reply to Gavin Scott), we thought
users may not want to change all the job files in their system to be
able to take advantage of this new feature. Hence, this way of
specifying membership in a file and restricting users to a single
queue. If our assumption is wrong, then certainly specifying the queue
name in :STREAM and/or !JOB will be a possible approach.
 
 > >Operation:
 > >---------
 > >
 > >   The max.  number of jobs  specified  by  :LIMIT  command  indicates  the
 > >   system  wide  limit.  At any  point  of time the  number  of jobs in the
 > >   system cannot exceed this limit.
 >
 > Again, just as the JOBFENCE command alters particular limits, the behaviour
 > for the LIMIT should be enhanced the same way.
 
I will take it that you are suggesting :LIMIT should have an
additional parameter ;QUEUE=. If so, I agree with your suggestion. If
I have misunderstood you, please let me know.
 
 > >
 > >   The  limit on  number  of jobs for each  job  queue  can be set by using
 > >   ALTJOBQ command.
 > >
 > >   Other  properties  of job  queues,  like Job  Fence,  Default  Execution
 > >   Priority,  Maximum  execution  Priority and Job security are same across
 > >   all job queues and these are set by :JOBFENCE,  :JOBPRI and :JOBSECURITY
 > >   commands respectively.
 >
 > Why could they not be adjustable per QUEUE, especially Max Execution
 > priority? That way, the Oracle jobs could be streamed in a job queue ORACLE
 > with a max priority of CS, while COBOL compilation jobs could go into a
 > queue PROGDEV with a max prioirty of DS.  Giving the grunt Oracle needs and
 > controlling the desires of eager young programmers. :)  (Please no flames on
 > comparitive merits of ORACLE vs Programmers! :)
 
This could be an additional feature of the Queue. We need to consider
the cost of implementing it vs. the benefit.
 
 > [single user/queue stuff trashed....]
 > >
 > >SHOWJOB output:
 > >--------------
 > [snip...]
 > >:showjob ;format=jobq
 > >                               New field
 > >                               ~~~~~~~~~
 > >JOBNUM  STATE IPRI JIN  JLIST  JOBQ      INTRODUCED  JOB NAME
 > >
 > >#J3     EXEC        10S LP     SYSJOBQ   WED 11:46A  FTPMON,FTP.SYS
 > >#J7     EXEC        10S LP     SYSMGRQ   WED  5:47P  EMG,MGR.SYSMGR
 > >#S81    EXEC        34  34     SESSION   THU 12:17P  MGR.GOPI
 >                      ^^^
 > Why not change JIN to show the QUEUE name for JOBS?  Cost is probably only 4
 > extra characters, and no special formats needed.
 
That could lead to compatibility problems with UDC's which might
assume the current output format of :SHOWJOB.
 
 >
 > Thanks for the opportunity to provide some feedback.
 
Thanks for your feedback.
 
Best regards,
mohan