At 11:09 AM 1/12/96 -0800, Jeff Vance wrote:
>If :altuser supported wildcarding in both user name and account name (of course
>AM-only user would be confined to his/her own account) would this be more
>beneficial than a defaultjobq= parm to:new/altacct (if you could only have
one)?
If I could have only one, I think I'd opt for new/altacct;jobq, so I could
have acct-level defaults that would be inherited by new users automatically.
Otherwise, if I do a :altuser @.acct;jobq=jq1 and then later do a :newuser I
have to remember to add the same ;jobq as the others. I can always write
scripts to do multiple :altuser's if needed.
>> >4. Should there be any relative priority across the queues in terms of
>> > selecting the next job to run ?
>> ...
>snip...
>
>Is this input pri scheme across all jobQs acceptable? (I'm talking about a job
>moving from a WAIT state to an EXEC state)
> 1) job with highest INPRI across all jobQs goes next.
> 2) if tie, job with earliest INTRO time across all jobQs goes next.
> 3) if tie, job in a user-defined jobQ goes next.
> 4) if tie, "random" selection (probably the first entry in the JMAT).
>I'm not sure there is value in rule 3.
That sounds fine. And yes, #3 is probably of limited value.
>The original proposal specified a global job limit set by the :limit command
>and a jobQ specific limit defined for each jobQ. Question: does the system
>defined jobQ ($sysjobq) have its own limit or does it fill up to the global
>limit?
I would definitely want $sysjobq to have its own limit. The whole reason I
want user-defined queues is to guarantee that 'normal' jobs don't prevent
'special' jobs from running. If $sysjobq can always fill to the global
limit then the user queues are all but worthless.
>An alternative approach (thanks Gavin) is the limit command (without a jobQ
>parm) controls the limit of the default system queue ($sysjobq) and the global
>limit is the summation of the individual jobQ limits.
...but of course this would cause the behavior of :LIMIT 0 to change. I
vote for the former model.
>Most of the feedback I've read is that the system managers on this list do not
>need the ability to control which jobs go into which jobQ (since the jobQ=
>parm on the :job command can be overridden by :stream). Is this perspective
>representative? I know of large companies that want their system admins
>to have greater control, but are jobQs a resource that don't need this level
>of control? BTW, lack of system admin control is less work for us which is
>good.
lack of control = less work? I'm not sure about that. If I was in a shop
where the MIS<->users relationship was not as healthy as ours, I would much
rather have an enforcement mechanism than to waste my time tracking down and
'educating' users who abuse the queues. But if I were you I would wait to
hear from some admins who do live in that scenario before investing the work
on queue restrictions.
(I still want the CIVARs, though, because there are possible applications
which are job management-related rather than security-related.)
>> Furthermore, it would be nice if this worked on
>> currently executing jobs as well. If I stream a job to FASTQ and later
>> realize that it is running longer than I expected, I could :ALTJOB it to the
>> SLOWQ to be courteous to other incoming FASTQ jobs.
>
>What value would this have? The job is already executing and thus falls into
>the Workload Mgr domain or the process priority queues (CS, DS, ES).
>Wouldn't :altproc job=xxx;pri=yy be acceptable?
(and a related comment to Gavin...)
>Unless a jobQ has runtime properties, like PRI, there would be no impact on
>moving an EXEC job from one jobQ to another. Right??
No No No! There is a relevant issue here in that EXEC jobs still have a
queue assignment and that can affect the dispatching of other jobs. Yes,
the job is EXECuting, but it is still filling a jobq slot which may be
preventing another WAITing job from starting in that queue. I want to be
able to move the executing job 'out of the way' of the other WAITing jobs in
the same queue. Granted, I should have put the slow job into the SLOWQ in
the first place, but the (hypothetical) point is that I didn't *know* at
stream time that it was going to run long.
(side note: I just did a :showjob status...
117 JOBS:
0 INTRO; 11 SCHEDULED
36 WAIT; INCL 0 DEFERRED <<==== yikes!
70 EXEC; INCL 60 SESSIONS
0 SUSP
JOBFENCE= 0; JLIMIT= 9; SLIMIT= 100
How soon do you guys think this will be ready?? :> )
-----------------------------------------------------------------------
Jon Diercks -------- mail: [log in to unmask]
Programmer/Analyst /|| | chat: powwow:[log in to unmask]
Computing Services /_|| | WWW : http://rowlf.csv.anderson.edu/
Anderson University / ||__| tel : (317)641-4305
Anderson, IN 46012 -------- fax : (317)641-3851
o________________________________________________________ ___
_\_, \=`==^==>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
