On Fri, 12 Jan 1996, Mohan Das wrote:
> 1. We seem to have almost a consensus on one thing. A default job queue
> based on some membership mechanism (it is not yet clear what it should
> be; I'll come to that later) AND the ability to override this default
> through job initiation commands, both are needed.
>
> The heirarchy will be:
>
> 1. ;JOBQ= specified in :STREAM command, if any
> 2. else ;JOBQ= specified in !JOB command, if any
> 3. else a default job Q based on some membership criteria, if any specified
> 4. else the system default Q, $SYSJOBQ.
>
> Queue to which a job should belong to is decided by applying the above 4
> criteria, in that order. (Some people might argue for swapping 1 & 2,
> though. We need to decide on that).
I think this acurately reflects my desires. I like the listed priorities
of 1 & 2 but could easily adapt to switching these two items.
> 2. There are two opinions on the mechanism for determining the default job
> queue (in cases when no job queue is specified in either !JOB or :STREAM
> command).
>
> 1. Default job queue based on user.acct
>
> Not sure whether it should be user.acct specified in !JOB or
> that of the user who :STREAMed the job.
>
> 2. Some respondents feel they need more granularity in determining the
> default queue and they are of the opinion that it should be based on
> "jobname,user.acct,group".
>
> While option 1 can be achieved by adding a new parameter ;QUEUE= to
> :NEWUSER and :ALTUSER commands, if we choose option 2, we need to
> either have a file to decide membership or it should be part of
> commands which create and alter job queues. Like,
>
> :NEWJOBQ queuename;members="payroll,mohan.admin",@.sys
> :ALTJOBQ usersq;members=+newbie.users,-oldie.users
> etc.
>
> We need to decide if the extra control gained by option 2 is really
> needed, even when there is an option of explicitly specifying the
> queuename in the job cards itself.
ABSOLUTELY! There are many shops that run 3rd party software. There is
no way that these vendors can assume queue management configuration for
all their customers. Many shops don't have the resources to make the
!JOB card changes each time we get a new release. In the case of our
apps, the :STREAM command is buried in an online driver program. That
means that jobs are streamed via the application without presenting the
:STREAM command to the user.
> 3. Some people have asked for properties like jobfence and input priority
> (default and maximum) to be different for each queue instead of being
> same across all the queues. We would really appreciate feedback on this
> matter. Please note that our objective is to meet basic needs without
> incurring too much cost, so we wouldn't want to try to provide anything
> which is not really essential.
Please refer to a previous post for my example. Jobfence carries the
highest priority in my book. The other properties may have value, but
seem to be more of a convenience. But that's just from my chair.
> 4. Should there be any relative priority across the queues in terms of
> selcting the next job to run ? Consider this scenario:
>
> JOBFENCE=8, JLIMIT=10; 10 EXEC; 2 WAIT
>
> JOBQ1: LIMIT = 5, 1 WAIT (#J11, INPRI=12)
> JOBQ2: LIMIT = 3, 1 WAIT (#J12, INPRI=13)
>
> Assume that #J12 was streamed before #J11.
>
> Now one of the running jobs gets over and one slot is open.
>
> Which job should be picked to run ?
>
> 1. Should it be based on some pre-defined priority between queues ?
> Say, jobs waiting in JOBQ1 have a higher priority over jobs waiting
> in JOBQ2, irrespective of INPRI and order of streaming.
>
> In that case, #J11 will be picked to run.
>
> 2. Should it be based on INPRI and temporal order across all the queues?
> (Within a queue, the jobs will be picked based on INPRI and order
> of streaming, of course)
>
> In that case, #J12 will be picked to run.
I like option 2. It looks less complicated than introducing queue
priorities and the extra management control that is inferred. Queue
priorities and priorities of workgroups inside queues is more on the
side of full featured operations center application (IMHO).
> 5. We need feedback from customers who are using Workload Manager as to
> what kind of integration, if any, would they want between Workload
> Manager and Multiple Queues ?
Sorry, can't help here.
> 6. Do the majority of system administrators on this list want the ability
> to *restrict* users to a queue or set of queues ? That is, now that the
> users have the option of specifying any queue they want in the job
> command, do you want to have the ability to say, "No, you're not allowed
> in this Queue" through ACD or any other mechanism ? I haven't heard
> anybody saying so far, that they really need this security feature.
I can certainly see how this would be very useful. However, with the
inclusion of job/session name and logon group, our environment would
receive little benefit.
> 7. Is the ability to transfer jobs from one queue to another while the
> job is waiting needed ? Like,
>
> :ALTJOB #J12;QUEUE=JOBQ1
>
> Some of you have mentioned it, but I just want to know if it is
> really essential.
Yes! The Computer Operator MUST be able to keep control of the
operating environment. Some may argue that moving jobs in the
EXEC state isn't of value. I disagree. It allows the Operator
to easily "free up" a queue so the waiting jobs can continue.
The only other alternative would require each waiting job in the
blocked queue to be moved.
Regards,
--- John Joerger ([log in to unmask]) --- Press-Telegram (Long Beach)
|
