On Fri, 12 Jan 1996 13:34:36 -0800 Jeff Vance said:
>> 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.
>
>We will wait for more feedback here.  Also at some point, Mohan will be
>soliciting a team of you to help us work out the details of this proposal,
>without involving everyone on 3000-L.  This team will ultimately be our
>customer beta team, will review documentation and evaluate the early
>prototype.
 
You guys should try a university environment full of CS students :-)  If
they want their job to run, they will find any possible means to do so; not
to mention certain development staff who consider their test run to be of
higher priority than the fee audit.  While most of our "end users" on the
admin side are really pretty benign, and don't stream jobs themselves, we
have more than our share of "literate" people out there.
 
If I define a queue SHORT that get's preferred treatment, they'll use it
with inpri=13, outclass=,13 and pri=cs if they can get away with it.  So if
I define a queue SHORT, I really mean "SHORT" and I want a CPULIM on it.  If
instead I wanted a short production job queue, I'd create another one that
didn't really have a CPULIM on it and I'd deal with exceptions.  If I want
to force development staff to run tests in DS class, I want to limit their
maxpri to DS (whether by queue assignment or altacct/user MAXJOBPRI=).
And if they can change it at runtime, they'll submit it in SHORT, let it run
a few minutes, then shuffle it somewhere else and possibly back again (would
that reset their CPULIM?).
 
If you want to shuffle EXEC jobs, go for it; just don't let ordinary users
do it.  If you want a Un*x example, how many people do you know that will use
"nice" voluntarily?  :-)  Given the choice and the knowledge, people will not
electively opt for less than first-class service (by and large).
 
I actually liked Mike P's analogy to IBM MVS job initiators; but then you had
to specify how much CPU, storage, tape mounts and forms you wanted ahead of
time.  But I most definitely don't want to revert to 30-year-old technology.
The suggestions seem to imply a "friendly" environment, and while that may be
the norm, it isn't the whole population.
 
In closing, I'd like to thank HP for asking for our input (and tolerating our
bickering!).  A whole lot of ideas have come out of this discussion and it
should be to our mutual benefit brainstorming openly like this before writing
a line of code with the wrong assumptions.  Of course we're only a subset of
the user community but it's a pretty representative sample set.  Besides, you
can't beat the speed, diversity, and cost of conducting a user survey over
the net!  (This wasn't the first, and we certainly hope not the last either!)
 
Thanks for the opportunity!
 
Jeff Kell <[log in to unmask]>
>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.
>
>Yet another good point!
>
>>
>> (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?? :> )
>
>At some point soon we will need to decide what version of MPE to implement
>this feature.  Choices are probably: 5.0, 5.0 Express 3, 5.5.
>
>Thanks for helping me to better understand your points,
>Jeff Vance
>
>
>--