Ok,
 
Just off the cuff, here is my suggested implementation for Multiple
Job Queues in MPE/iX (and it's easy to implement I think)...
 
First of all, I don't think that QUEUE's should be any big deal. In
fact, since about all they need to do is to be a name with an
associated limit value, I see no reason to configure them before use.
If there is a job that has been streamed, or if a limit has been
assigned, then the 'queue' exists, otherwise it does not.  So here's
some ramblings as to how this could be done...
 
Add an 8 byte field to the JMAT called JOBQ.
 
Create a new MPE 'system table' datastructure called 'LIMITTABLE'.
 
Enhance the !JOB command to support a keyword ';QUEUE='.
 
Enhance the :STREAM command to support the keyword ';QUEUE='
 
Enhance the :LIMIT command to have an optional keyword ';QUEUE='
 
Enhance :ALTJOB to support the ';QUEUE=' keyword.
 
Enhance :SHOWJOB as per HP's proposal to have an option to display
the JOBQ field. Optionally add ;SELEQ= to :SHOWJOB and allow selecting
based on the QUEUE name.
 
Optionally, add a DEFAULTJOBQ field to the USER directory entry and
enhance ALTUSER/NEWUSER/LISTUSER to maintain it.  This value would
be used if a user streams a job and neither the :STREAM command nor
the !JOB card specifies a queue name.
 
Now we can do things...
 
Assume we have some files with JCL in them:
 
IMPJOB.PUB.PROD
!JOB JOB.PROD,DATA
!RUN A.VERYGOOD.PROGRAM
!EOJ
 
EXPJOB.PUB.PROD
!JOB JOB.PROD,DATA;QUEUE=LONGJOB
!RUN A.VERYSLOW.PROGRAM
!EOJ
 
COMJOB.PUB.PROD
!JOB COMPILE,DEV.PROD;QUEUE=COMPILE
!COBOL OLDSRC
!EOJ
 
And assume that in SYSSTART we executed the commands:
 
:LIMIT 1,64        << Allow one job at a time if no QUEUE specified >>
:LIMIT 2;QUEUE=LONGJOB   << Allow two jobs at a time from 'LONGJOB' >>
:LIMIT 1;QUEUE=QUICK     << Allow one job at a time from 'QUICK' >>
 
Let's see what happens if we execute some commands:
 
:STREAM IMPJOB
:STREAM IMPJOB
 
We get two jobs that do not have a QUEUE specified, so they go into
the system default queue (the same one all our jobs have been going
into for years), and because the system default job limit is '1',
these job will run one after the other. This is how things work today.
 
:STREAM IMPJOB;QUEUE=LONGJOB
:STREAM IMPJOB;QUEUE=LONGJOB
:STREAM EXPJOB
:STREAM EXPJOB;QUEUE=FOO
 
All these jobs are submitted into the 'LONGJOB' queue.  The first
two explicitly by using the ;QUEUE= option on :STREAM, the third one
because it is explicitly put there by the ;QUEUE= option on the !JOB
card, and the forth one for the same reason as the third one (the
;QUEUE= on the !JOB card would override the :STREAM command.  I'm
open to arguments for doing it the other way round too).
 
Because we set the limit to '2' for the queue named 'LONGJOB' in
SYSSTART, the first two of these jobs will log on and run, and the
others will wait until one of the first two logs off, etc.
 
Ok, so where did we configure 'LONGJOB' into the system?  We didn't!
It came into existence when we assigned a 'limit' value to it in
the :LIMIT command we did in SYSSTART.  What happens if we try to
:STREAM a job into a QUEUE that does not exist, such as:
 
:STREAM COMJOB
 
which tries to use ;QUEUE=COMPILE (in the !JOB record), but we haven't
assigned a 'limit' to 'COMPILE'?  My first thought is that the job
should be accepted, but since no limit has been assigned, it should
behave as though the limit for the queue was zero.  The other option
would be to return an error to the :STREAM command, which would require
that a limit be assigned (thus creating the 'QUEUE') before jobs can
be submitted.  This would help eliminate typing errors, but you could
just as easily mistype the name of the QUEUE in the :LIMIT command thus
creating a 'QUEUE' that no jobs will be submitted to (in actuality
the QUEUE names are probably going to be hardcoded in JCL and UDCs,
so it might not be a big deal.
 
The way this all works is very simple.  A 'QUEUE' is really nothing
more than an association between a 'limit' and a JOB.
 
A QUEUE comes into existence 'logically' when a job is submitted with
the  ;QUEUE= option that specifies a value that does not exist in the
LIMITTABLE. A QUEUE that exists 'logically' has a 'limit' value of
zero from the point of view of the job dispatcher (JOB.PUB.SYS?).
 
A QUEUE comes into existence 'physically' when someone executes a
:LIMIT command with the ;QUEUE= keyword specifying the name of a
QUEUE that does not exist in the LIMITTABLE, and a JOBLIMIT value
>0 is specified (sessionlimit should be ignored, leaving open the
possibility of supporting multiple SESSION queues as well. This
might actually be worth implementing because it would let you allow
different 'groups' of users onto the system as their applications
became available).  A QUEUE ceases to exist 'physically' when its
limit is changed to zero, at which time it can be deleted from the
LIMITTABLE.
 
When the JOB dispatcher gets an event that causes it to evaluate the
entries in the JMAT to see if a new job should be streamed, it
uses the 'limit' value associated with the 'QUEUE' that is associated
with the job (which it gets from the LIMITTABLE).  If there is no
LIMITTABLE entry for that QUEUE, the job will not launch as the limit
is effectively zero for that QUEUE.  It compares the limit value for
the jobs logical 'QUEUE' to the number of jobs currently executing
with the same 'QUEUE' value [to do this efficiently more data
structures might be required such that we physically create a new
QUEUE entry somewhere when a job is first streamed into the queue.
This structure might simply keep track of the number of jobs running
in each queue.  It could be the LIMITTABLE.] and launches the job
if the limit is big enough to have room for the job.
 
   :ALTJOB #Jnnn;QUEUE=OTHERQ
 
would simply change the JMAT record for the job and signal the JOB
dispatcher to look and see if this has any effect that would allow
a job to now be streamed (depending on whether the altered job is
actually running).  To change a job into the system default queue:
 
   :ALTJOB #nnn;QUEUE=
 
If people feel that security on queues is required (I really don't
think it is, and will be happy to discuss it with anyone who does),
then ACDs are the right way to do it (see my response to Jon's
message earlier).
 
:LIMIT is used to assign limits to queues.  One issue is that today
you can prevent all (non ;HIPRI) logins to the system by executing:
 
   :LIMIT 0,0
 
If the system default limit only applies to jobs with no specified
queue, then this command would no longer be sufficient to stop new
jobs from logging on.  One solution would be to have a separate
global maximum limit as in HP's proposal, another would be to allow
something like:
 
   :LIMIT 0,0;QUEUE=@
 
which would set the limit for all currently defined queues.
 
These suggested changes require no configuration facility, there is no
new permanent data structure created, no new MPE/iX commands are
created (though we are changing a number of them and the documentation
will have to be updated. Though the documentation change is almost
identical for many of the commands).  It gets (I believe) all the
functionality that is needed, and at a very modest cost I would think.
 
An interesting idea would be to extend the same features to work for
SESSION limits as well as job limits.  The user could have a DEFAULT
SESSIONQ attribute which would be used when he logged on.  There
could be a ;QUEUE= option on :HELLO, but this probably would not be
needed for anything (at least I can't think of a good reason).  You
would then be able to let users onto a system a group at a time as
their particular applicaitons became available.
 
Comments?
 
G.