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:
John Joerger <[log in to unmask]>
Reply To:
John Joerger <[log in to unmask]>
Date:
Mon, 15 Jan 1996 09:40:03 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
On Fri, 12 Jan 1996, Jeff Kell wrote:
> OK, in Gavin's case, moving the job from SHORT to LONG is just semantics;
> why did you bother to define a SHORT queue if you had no intention of somehow
> enforcing the fact that it was indeed intended for SHORT jobs?  The idea is
> to get the SHORT queue jobs lauched ahead of other things.
>
> What do you do when you change an executing job's queue and the target queue
> is full?  If the maxpri is less than the original?  If the user.acct doesn't
> have access to that queue (well, OP/SM is what I guess we're talking about).
>
> In all cases, it still sounds like it boils down to you want a job to run
> RIGHT NOW.  If you play with limits, or queue shuffling, other jobs can stop
> and/or start and it might not produce the desired result.  My suggestion was
> that if you wanted a job to run RIGHT NOW, then define a queue that has by
> default a ;HIPRI associated with it.  No limit changes, the job just goes.
> You can't :ALTJOB a job now unless it's in WAIT state, why start now?  The
> purpose of multiple queues is to manage job scheduling.  A job that is
> already running is no longer a scheduled job.
 
Let me look at this from a different point of view.  A user has to
complete a particular task by lunch -- it is now 10 am.  The task
requires that they stream 20 - 30 jobs that post batches of transactions
and produce reports.  The jobs are streamed in a deferred status and
not run until the user verifies that all input is complete.
 
In the mean time, another user with deadlines of their own, stream a
job and (mistakenly) request the job queue used by the above schedule
rather than their proper queue.  If this is a 2 hour job, what should
the Operator do?
 
Rather than move the 20 - 30 jobs into an alternate queue, it seems
reasonable to move the problem job so that regularly schedule jobs
can proceed normally.
 
Of course, I'm ignoring a few issues that may impact the movement of
a job already in EXEC state.  And I'm certainly not taking the impact
of development into account.  From a strict usability standpoint,
moving EXEC jobs to different queues seems like a useful capability.
 
Regards,
 
--- John Joerger  ([log in to unmask])  ---  Press-Telegram (Long Beach)

ATOM RSS1 RSS2