Hi all,
 
Here are some of my thought to Gavin's great proposal.  I want to thank him
for taking the time to reply to our initial proposal and the extra time to
fix all of the problems!.. :)  And so no one feels left out, Mohan and I
have saved all of your replies and will be incorperating the feedback into
a 2nd pass proposal shortly.  So thanks all.
 
On Jan 9,  5:31pm, [log in to unmask] wrote:
> Subject: Multiple Job Queues (Gavin's alternative)
> 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...
 
So anyone can create a jobQ, jobQs exist as long as there are jobs in them,
when a jobQ is empty it is removed.  This implies no need for commands that
explicitly create/purge jobQs.  If I create a jobQ via :stream what is the
jobQ's limit? (from reading more carefully I see the limit would be 0).
Is there much value to be able to create on-the-fly and jobQ whose limit is 0?
Probably most of the jobQs would be created in the sysstart file via the :limit
command as shown below.
 
(the notion of jobQ= on :stream and :job, and having a default jobQ based on
 user.acct are part of the revised proposal and have been snipped):
 
>
> 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.
 
Kind of. Today if I do :limit 1,64 then (except for HIPRI) only 1 job at a time
can run.  This proposal allows more jobs to run than specified by :limit.
This isn't a compatibility problem since you are explicitly using new jobQs,
but is this the desired behavior?  The system manager or operator won't know
ahead of time all the jobQs that exist on their system so how can they
manage the workload?  Well, maybe if all the jobQs are created via :limit
and can be seen then the SM/OP do know ahead of time all existing jobQs and
their limits.
 
some examples snipped...
> 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.
 
If jobQ can be created before they are actually used via :limit is there also
value in being able to delete them (I'm thinking of MPE V JCWs that could be
created but not deleted until many releases later)?  Also, if we decide to add
another property to a jobQ, such as jobfence, would :jobfence x;jobQ=yyy also
create the jobQ if it hadn't already been created by a previous :limit command?
 
I guess right now I am still in favor of explicitly creating and purging jobQs.
 
snip...
> The way this all works is very simple.  A 'QUEUE' is really nothing
> more than an association between a 'limit' and a JOB.
 
I like the simplicity and definitely like the idea of us having less work
to do, because if we can meet your needs with less effort/cost there is a
much higher chance of being able to complete this project.
 
That said, I would like to keep open the possibility of a jobQ having
additional properties, like: jobfence, jobpri, jobsecurity, etc.
 
>
> 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?).
 
Yes, JOB.PUB.SYS is our job dispatcher.
 
>
> 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.
 
some job dispatching details snipped...
 
>
>    :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).
 
Unless a jobQ has runtime properties, like PRI, there would be no impact on
moving an EXEC job from one jobQ to another.  Right??
 
> 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).
 
I kind of like the idea of merging Gavin's and Chris' idea of ACDs under
the HPSPOOL account, but this is extra work and should only be considered if
there is a true business need.  Examples anyone?
 
>
> :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.
 
This is exactly the approach we are looking for: a solution that meets most
of your most important needs, is simple to understand, simple to document,
simple to implement, simple to support.
 
session qs snipped...
 
Thanks Gavin!
 
Jeff Vance
 
--