RE: QDBSRVxx Job Hogging the CPU

Simon,

Thanks for the clarification. But I still have a concern, and perhaps your
friend in Rochester can help.

We did perform the save with ACCPTH(*YES) and we did meet all of the listed
conditions in the Backup and Recovery guide, and yet the indices were
rebuilt. The save was done with a SAVLIB and all the logicals are in the
library along with the based on physical. However, we restored with a RSTLIB
to a different library. Is it possible that the indices are not restored if
the restore is to a library other than the save lib?

Also, if this is just an event handler, why can't it run at a lower
(higher?) priority, like 52? Priority 9 is a killer.

-Walden

PS. The best solution to this problem is to have my vendor rewrite that part
of the software that has 50,000 access paths. :-)

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Simon Coulter
Sent: Friday, April 03, 1998 10:53 PM
To: MIDRANGE-L@midrange.com
Subject: RE: QDBSRVxx Job Hogging the CPU


Walden,

I have been investigating this problem and have some further information.
Your comments are
not accurate.  Here is the truth:

The QDBSRV01 job does not determine the state of the access paths.  It is
just an event handler
and receives events indicating that an access path is invalid.  These events
are sent from
other processes.

You are correct when you state that QDBSRV01 builds the EDTRDBAP panel
information and that it
passes the rebuild of the access path to one of the other QDBSRVnn jobs.

The events indicating an invalid access path come from a number of sources
but in the example
case are raised by the restore code (well actually lower-level LIC database
code).  It is this
code which checks for valid access paths and if it finds an invalid access
path it sends an
event to QDBSRV01 for each invalid access path.

What you see when QDBSRV01 sucks the life from the CPU is really the event
handler code having
a hard time because there are too many invalid indices.  (Your earlier
comment about 50,000
indices being a case in point.)

There are two solutions to this problem:
        1)  IBM rewrite the event handler code so it works better
        2)  Save the access paths and therefore reduce the number of events 
sent to
QDBSRV01.

There is a caveat however.  The Backup and Recovery Guide describes some
convoluted cases where
an access path will be marked as invalid even if it was saved.  In these
cases the QDBSRV01
event handler will still get invoked although it may not get invoked as
often as if you had not
saved access paths.

Thanks for explaining the event handler problem should go to a friend of
mine in Rochester.

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 3 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
//
// Windoze should not be open at Warp speed.

//--- forwarded
letter -------------------------------------------------------
> Date: Mon, 02 Feb 98 08:48:30 -0500
> From: "Walden Leverich" <walden@techsoftinc.com>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: RE: QDBSRVxx Job Hogging the CPU
> Importance: Normal

>
> 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
>
>



+---
| 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
+---

+---
| 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
+---