On Fri, 12 Jan 1996 18:09:16 +0500 Mohan Das said:
>Judging from the responses so far, it is obvious that customer interest in
>this feature is considerable. We are really glad to note that.
I've been too busy to read EVERY reply to this, so I appreciate Mohan's
effort to summarize here. Before I comment on his observations, I'd like
to make a few "conceptual" points of exactly why I want multiple queues in
the first place. I think perhaps we are bickering on implementation before
we understand the problem, so perhaps "some" effort should be made to be
certain the needs are understood as I've not seen a couple of mine (or at
least not explicitly).
Need #1: A queue for "daemon" type jobs, for example OpenDesk supervisor
and trucks, httpd, Telamon's PBX engine, SQL listener, and other
background jobs that run all the time. I would like a queue that
doesn't impact my other jobs (notably limits - if I bring down one
of these services, I don't necessarily want another user job to
take it's place; similarly if I need to start one of these jobs I
don't want them to go in WAIT state. Not all are ;HIPRI-able).
Need #2: A single-threaded queue for dependent jobs which cannot execute
concurrently.
Need #3: A "hot" queue with an implied ";HIPRI" submission so that SM/OP
user could STREAM or ALTJOB any job to this queue and have it
logon immediately. Currently you have to play with jobpri and
limits in a 3-step process (and hope nothing interferes).
Need #4: A "short" queue to allow a certain number of "short" jobs to run
independent of other queues. To function correctly, this would
imply the queue could be associated with a configurable CPULIM.
Need #5: A "background" queue for compiles, batch queries, etc., which
should have a configurable limit and MAXPRI. This is the only
area where I can see a good association for user.acct defaults.
This begs the question of should we associate MAXPRI with the
queue, or the user/account (the MAXPRI in the latter case would
have to be independent of the existing MAXPRI since CS sessions
maybe OK, but not CS jobs).
Now on to the summary...
>1. We seem to have almost a consensus on one thing. A default job queue
> based on some membership mechanism...
>
> 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).
There should also be some mechanism to prevent arbitrary queue assignment by
arbitrary users (that has been mentioned, just restating it here).
>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.
That of user.acct in !JOB unless the :STREAMing user is OP/SM.
>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.
Jobfence/Inpri within queues, yes; plus maxpri, cpulim, and limit.
>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)
We're fighting a losing battle here, I suspect. I would suggest that the
current jobfence/inpri/limit rules apply within a queue, but you also need
some ordering of queue selection so that one queue is selected over another
if we are worried about a "system-wide" LIMIT. If the "default system
queue" *is* a defined queue with a definable limit, then :LIMIT without a
queue specification should imply a system-wide limit. It is then up to the
SM to decide how the available slots are divided across the queues. If there
are more candidates to run than available slots, the next slot goes to the
highest-priority first-streamed job within the highest-priority queue by the
current rules. For "ties" in queues, you can follow your rules of the job
with the highest priority (and first streamed) across the "ties".
>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.
Yes, otherwise users will abuse the queues. So you need to limit them from
certain queues (like my HOT example above) or default them to a lower queue
(whether we limit that at the queue level, or at the user.acct MAXJOBPRI
level, or whatever).
>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.
OP/SM definately need this. Users also, perhaps, if :jobsecurity low and
they have access to the new queue.
Jeff Kell <[log in to unmask]>
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Jeffrey R Kell, Dir Tech Services | Internet: [log in to unmask] |
| Admin Computing, 117 Hunter Hall | or [log in to unmask] |
| Univ of Tennessee at Chattanooga | Voice: 423-755-4551 *** NEW *** |
| Chattanooga, TN 37403-2598 | FAX: 423-755-4025 *AREA CODE* |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
