HP3000-L Archives

February 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:
Tom Madigan <[log in to unmask]>
Reply To:
Tom Madigan <[log in to unmask]>
Date:
Tue, 13 Feb 1996 10:03:57 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
Greetings from the Land of Pleasant Living!!  While we're on the subject
of multiple job queues, I'd like to vote for retaining BOTH limits:  one
limit configurable for each JOBQ and a global system limit.  My reasoning
is based upon what each limit is trying to accomplish:
 
* The job limit for each queue can be set to minimize the impact that
  each queue has on the system.  For example, if you have a set of jobs
  that serially read a large TurboIMAGE data set, you may want to assign
  those jobs to a JOBQ with a limit of 1 so that you don't have these
  jobs essentially locking each other out of the same data sets all day.
  That's one of the problems we face each day on our system.  If a user
  :STREAMs several of these jobs simultaneously (or within a few minutes
  of each other), then the entire batch queue comes to a screeching halt
  while these jobs continually lock/unlock the same data sets.
 
  On the other hand, if you have a collection of jobs that run fairly
  quickly, then you may want to assign them to a JOBQ that allows several
  to run simultaneously knowing that they will finish long before anyone
  notices any system degradation.
 
* The global job/session needs to be retained to control the overall
  impact that batch processing has on the system.  Your system has a
  finite amount of memory, a portion of which each executing batch job
  will be glad to eat.  Once the number of batch jobs exceeds a certain
  threshold, system performance will degrade to the point that the
  on-line transaction processing users will notice ("I hit the ENTER key
  THREE SECONDS AGO and nothing has happened!!").  You might be able to
  squeeze out one or two more batch jobs with careful tweaking of the
  :TUNE command, but you'll eventually cross the performance line again.
 
Hang in there, folks!!  Stick with good ol' MPE.  Oh no!!  ANOTHER
General Protection Fault again??
 
 =======================================================================
Tom Madigan                        | Phone......804.594.7180
Administrative System Manager      |
Christopher Newport University     | Urgent.....804.594.7220
Computer Center                    |
50 Shoe Lane                       | Fax........804.594.7500
Newport News, VA  23606-2988       |
USA                                | [log in to unmask]
                                   |            [log in to unmask]
 =======================================================================

ATOM RSS1 RSS2