[log in to unmask] wrote:
>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)...
>
[snipped for brevity]
 
 
>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).
 
Well.. how about a compromise: The !JOB card rules unless the STREAM command
was issued by a user with OP or SM caps ?
 
>
>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.
>
 
I would go for the latter option. I am not so sure I like the idea of
a queue being dynamically created by the STREAM command, esp. if it has
an initial LIMIT of 0.
I would prefer to see the stream command fail if the queue doesn't exist.
Or possibly allow the dynamic q creation, but default the limit to 1. This
follows the premise that if you STREAM something, you want it to run.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
Generally speaking, I think Mohan & Co are on to a winner here. I can envisage
shops using 'clever' jcl to stream jobs & create/delete queue's using criteria
such as: How many jobs are left in queue 'X'?, Does queue 'Y' currently exist?,
etc. Couple this with the time/date delays inbuilt into the STREAM command, and
you're getting close to a full blown job scheduling/management system!
 
:EOD
Martin.
--
+---------------___---------------------------------------------------------+
|Nettiquet:    /   \  All my views/comments are personal, and nothing to do |
|4-line sig!  | @ @ | with my employer's organisation.    - Martin O'Murphy |
+---------oooo---U---oooo---------------------------------------------------+