Jeff writes:
> 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.
 
I kind of like the idea of not being able to submit a job into a queue until
that queue is brought into existence by a :LIMIT command, but then there is
the question of when a queue gets deleted.  With my original proposal, the
queue can be deleted when the limit is set to zero.  If the queue has to
exist before a job can be submitted, then we have to keep info about the
queue around even if the limit gets set to zero.  Since we probably don't
want the system filling up with unused queues, there would have to be a
way of explicitly deleting them, and overloading the :LIMIT command to do
this sounds like it would be ugly:
 
   :LIMIT 0;QUEUE=MYJOBS;DELETE
or :LIMIT -1;QUEUE=MYJOBS
 
By the way, I like ;QUEUE= rather than ;JOBQ= because the syntax can be
specified as ;Q[UEUE]= so I can abbreviate :STREAM foo;Q=MYJOBS.  Yes,
there is possible confustion as to what kind of queue we are talking about,
but from context I think it is pretty clear what we are doing.  It's not
a priority queue, since that is specified with ;PRI=.  We are submitting
a *job* so what kind of queue would we be talking about?  Why a 'job' queue
of course.  I could certainly live with ;JOBQ= but I much prefer ;QUEUE=.
 
If we look again at what I proposed first, that a job streamed into a
queue that does not exist creates the queue with a limit of zero, then
the queue datastructures can be automagically deleted whenever the limit
goes to zero (if we start assigning other attributes to a queue this gets
messy) and there are no jobs in the queue.  What are the downsides to this?
If the user fails to setup the queue in advance by setting a limit on it,
then the job submissions don't fail, they jsut sit in wait state because
their queue has a limit of zero.  The same thing happens if someone mis-types
a queue name in a job file or in a :STREAM command.  I don't think this is
really a hard problem to recover from.  When the user wonders why the job
hasn't run, it will be see that the limit was zero for that queue and
either :ALTJOB it into another queue, or change the limit.  This is possibly
an *easier* problem for the customer to solve than having the user call up
because his menu system gave him a funny error when he asked for a job to
be streamed (because it rejected the job becasue it's queue did not 'exist').
 
> 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.
 
I brought up the issue of addressing the :LIMIT 1 or :LIMIT 0,0 issue.  Within
my proposal, a solution such as:
 
   :LIMIT 0,0;QUEUE=@
 
for :LIMIT 0,0 or:
 
   :LIMIT 0;QUEUE=@   <<Change all limits for existing queues to zero>>
   :LIMIT 1;QUEUE=    <<Change the system queue limit to 1>>
 
for :LIMIT 1 would get you something equivalent.  If you do it this way
then the system default queue is just treated the same as a user defined
queue, and no 'global' limit is required.  I'm not against the idea of
a global super limit, but it complicates the situation (although in most
cases users may think it more intuitive) and introduces things like the
priority issue of which job to launch when a 'global' job slot opens up
and there are multiple jobs that could be launched (my proposal does not
have this problem).  I feel my way is cleaner, but I suspect that people
will not like it very much.
 
Please consider making the system default queue name simply tha absence
of any name or just blank.  I really think $SYSJOBQ is uuuuugly.
 
> That said, I would like to keep open the possibility of a jobQ having
> additional properties, like: jobfence, jobpri, jobsecurity, etc.
 
I would too, and I don't think my way limits this possibility, but if
you want to have these options at first release I would suggest that
a set of explicit :NEWJOBQ :ALTJOBQ and :PURGEJOBQ (or should :PURGELINK
do it :-) commands would be the best way to handle it.  This also answers
the need for a way to explicitly create and delete the queues too.  I
still think that the queue's should be transient, rather than permanent
entities on the system because that way you don't have to worry about
SYSGEN, INSTALL, :RESTORE, BULDACCT, etc.
 
Another advantage of my 'the queue exists if there is a job in it' philosophy
is that on system reboot, you are going to have jobs in the JMAT that
need to be RECOVERYed, and they will be in queues that don't exist yet if
the user has to do a :NEWJOBQ first in SYSSTART.  Permanent job queues fix
this problem too, but introduce the maintenance issues above. With my way,
the JMAT gets recovered, and all the jobs are in queues that have devault
limits of zero, and then when the user's SYSSTART sets the limits up, the
jobs will just naturally log on.  Without an overriding system global limit
value, there are no race conditions about which :NEWJOBQ (or LIMIT;Q=) gets
executed first in SYSSTART either.
 
> Unless a jobQ has runtime properties, like PRI, there would be no impact on
> moving an EXEC job from one jobQ to another.  Right??
 
Someone else pointed this out but briefly:
 
:ALTJOB on a WAITing job requires only evaluating whether you can now launch
that job (it got moved to a queue with available limit slots).
 
:ALTJOB on an EXECuting job only requires evaluating whether a different job
can now launch because we just freed up a slot in the queue we were in.
 
Should :ALTJOB prevent exceeding the limit on a queue if the user tries to
:ALTJOB a job into a queue that already has 'limit' number of executing jobs?
I would think not, off the top of my head.  It gets tricky though to swap
the queue names of two executing jobs though without this.
 
Queue attributes like ;PRI= may be bad because it's easy to have the job
have a default execution priority that takes effect at job launch time as
though the !JOB card had ;PTI=, but if you :ALTJOB an *executing* job what
should happen?  Users are going to ask that it go change the priority of
all the processes, but this is the *wrong* thing to do!  This is the job
ot the Workload Manager, *not* multiple job queues.
 
> 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?
 
I think the usage of HPSPOOL certainly seems to make a lot of sense,
and if there are ACDs to be placed this is probably the place to do it.
I think it complicates the implementation for you, because it probably
means you have to change a *lot* more code though. If instead of just
IN.HPSPOOL you had a set of groups named queuename.HPSPOOL, then this
could be the way to implement both permanent queues and ACDs.  So, perhaps
it's worth talking about more.
 
G.