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:
Wed, 10 Jan 1996 11:53:48 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (24 lines)
Marise wrote:
>      I'm coming in a little late on this discussion, so if someone has already
> suggested this, I apologize: I'd like to see a way to stream a job so that it
> would use the first available queue, something like
>
> :STREAM HUSKYJOB;QUEUE=IDLEQ
 
This doesn't really mesh well with the problems that multiple job queues are
trying to solve.  If you want the job to log on next, put ;INPRI=13 on it to
move it to the front of it's queue.  If you want it to run NOW put ;HIPRI on
it.  If you want to have more control over how many system resources it uses
once it starts running, use the Workload Manager to do it.
 
In HP's proposal, they did not specify how multiple job queues with a system
wide global maximum limit would interact with different INPRIs.  I assume that
if there were two queues that each had waiting jobs and available 'limit'
slots but the system wide max-limit was preventing them from starting, that
when a slot freed up it would pick the job with the highest INPRI to launch
first.  If the jobs have the same INPRI, I see no way in HP's design to
know which job would be selected to be launched (unless they introduce yet
another concept of relative-priority between different job queues.
 
G.

ATOM RSS1 RSS2