HP3000-L Archives

January 1996, Week 3

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:
Jon Diercks <[log in to unmask]>
Reply To:
Jon Diercks <[log in to unmask]>
Date:
Fri, 19 Jan 1996 09:02:18 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
At 08:55 PM 1/18/96 GMT, Larry Byler wrote:
>  I tend to agree with Gavin that moving an executing job to a
>different (hopefully more appropriate) queue is more intuitively obvious to
>an operator and simpler conceptually than all the other workarounds various
>people have suggested.
 
Me too.
 
>  But what do you do if the target queue is already
>at limit?  Does the move fail?  Do you ignore the target queue limit (except
>to hold off newly introduced jobs from executing until enough jobs log off)?
>Does the job whose queue you are changing suspend until it is within queue
>limit?  Does an existing job in the target queue suspend instead?  Which one?
 
Well, let's look at current system behavior.  It *is* possible now to have
more jobs EXECuting than the LIMIT specifies.  This can happen if a job is
HIPRI, or the limit is temporarily raised and then lowered.  In this
situation, all jobs continue to execute until the enough jobs finish to let
the next one on.  So, from the options you listed I vote for:
 
>...ignore the target queue limit (except
>to hold off newly introduced jobs from executing
>until enough jobs log off)
________________________________________________________
Jon Diercks * Programmer/Analyst      Computing Services
[log in to unmask] (PGP available)     Anderson University
http://rowlf.csv.anderson.edu/        1100 East Fifth St
(317)641-4305 * FAX (317)641-3851     Anderson, IN 46012

ATOM RSS1 RSS2