MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 1998

RE: QDBSRVxx Job Hogging the CPU


  • Subject: RE: QDBSRVxx Job Hogging the CPU
  • From: "Walden Leverich" <walden@xxxxxxxxxxxxxxx>
  • Date: Mon, 2 Feb 1998 08:48:30 -0500
  • Importance: Normal
  • In-Reply-To: <199801310533.AAA000.74@unicorn.flybynight.com.au>

fixed

Simon,

Sorry, but his won't help. The offending job is the job that determines if
there is a saved access path and if so, if it is still valid. This job is
the job that put the logicals on the EDTRBDAP screen. The actual rebuilds,
if needed, occur at priority 52 so there is no (little) performance hit from
the rebuild.

However, without regard to this problem, I agree that all saves (unless you
have a REALLY good reason not to) should be done with save access paths
(*yes).

-Walden

> -----Original Message-----
> From: mcsnet!midrange.com!midrange-l-owner@Mcs.Net
> [mailto:mcsnet!midrange.com!midrange-l-owner@Mcs.Net]On Behalf Of Simon
> Coulter
> Sent: Friday, January 30, 1998 8:14 AM
> To: MIDRANGE-L@midrange.com
> Subject: Re: QDBSRVxx Job Hogging the CPU
>
>
>
>
> Have you considered saving the access paths to reduce the CPU used
> during the restore?
> If you save the access paths the indices will generally not need to
> be rebuilt.  There are certain
> situations where the access paths will be rebuilt even if they were
> saved e.g.,the logical has
> MAINT(*REBLD) specified, or when the logical files are in different
> libraries from the based-on
> physical files.  The Backup and Recovery Guide has more information
> on the specifics.
>
> You can also use the EDTRBDAP (Edit Rebuild Access Path) command to
> manage access path builds.
>
> Regards,
> Simon Coulter.
>
> //----------------------------------------------------------
> // FlyByNight Software
> // AS/400 Technical Specialists
> // Phone: +61 3 9419 0175
> // Fax:   +61 3 9419 0175
> // Mob:   +61 3 0411 091 400
> // Email: shc@flybynight.com.au
> //--- forwarded
letter -------------------------------------------------------
> > X-Mailer: Internet Mail Service (5.0.1458.49)
> > Date: Thu, 29 Jan 98 08:30:27 -0700
> > From: "Sannan Solberg" <SSolberg@Washcorp.com>
> > To: "'MIDRANGE-L@Midrange.com'" <MIDRANGE-L@Midrange.com>
> > Reply-To: MIDRANGE-L@Midrange.com
> > Subject: QDBSRVxx Job Hogging the CPU
>
> >
> > We have the occasion to clear and restore fairly large data libaries
> > with lots of
> > logical files as well.  We often have to do during the day so as not to
> > interrupt more important things at night.  Once things restore, a CPU
> > hogging job
> > kicks off, likely rebuilding indexes and such.  At one time, I knew a
> > command that
> > allowed you to changed the job running priority from 9 (that it kicks
> > off at) to
> > something else, say 50 like batch jobs.  I'm quite sure you can't do it
> > with the
> > regular CHGSYSJOB command.  Anybody got any ideas??
> > We are running mostly model 500's on V3R7 if that matters.
> >
> >
> > **************************************************
> > Sannan Solberg                               (406)523-1392
> > Business/Programmer Analyst        (406)523-1636  fax
> > Washington Corporations               ssolberg@washcorp.com
> >
>
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
> uucp
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact