HP3000-L Archives

January 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Fri, 12 Jan 1996 17:07:26 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (47 lines)
Jeff wrote:
> On Fri, 12 Jan 1996 16:01:42 -0800 <[log in to unmask]> said:
> >Jeff wrote:
> >>>:ALTJOB on an EXECuting job only requires evaluating whether a different job
> >>>can now launch because we just freed up a slot in the queue we were in.
> >>
> >> Yuck... I see no need to alter the queue after the job reaches INTRO/EXEC.
> >> No, no, no; overly complicating things.
> >
> >Hmmm. Ok, maybe.  The desire to move a job from the SHORT queue to the LONG
> >queue once it is determined that it's really going to take three hours
> >instead of three minutes seems pretty basic though.
>
> If it's takes longer than SHORT's CPULIM= then it should be bombed; else
> users will abuse the facility.
>
> >The alternative is to
> >increase the LIMIT on the SHORT queue by one, but then you have the problem
> >that when the job finishes, the limit on SHORT is one too high.
>
> Go back to my post; you would ALTJOB the waiting job into the HOT queue and
> away it goes.
 
I'd be interested in other people's comments, becaue I *strongly* disagree
with Jeff's suggestion that once a job gets started, it's queue association
should not be changeable.
 
From a security point of view, I suspect that at >90% of customer sites, the
end users never execute their own :STREAM commands.  If they can do this (as
it sounds they can in Jeff's environemnt) then they can probably EDIT any
job before they stream it, and can specify any queue on the :STREAM command,
so they are already free to abuse the facility, subject to what (if any) ACD
like security is built ito it.
 
I see many advantages to changing the 'limit association' of a job once it
gets running.  I've never been at a customer site where the operations staff
didn't spend a significant amount of time shuffling jobs around.  In many
cases they could not predict how long a job was going to run before they
tried it.  The ability to move a job in the SHORT queue out of the way into
the LONG queue is at least as important to me as most of the other features
we are talking about.
 
If you can't :ALTJOB the queue on a running job, you drastically limit the
functionality, and I still fail to see how this even helps Jeff's environemnt.
 
G.

ATOM RSS1 RSS2