Re: CPU usage for QZDASOINIT

Actually this may be better:

   Following each access path name in the list is a reason code which
 explains why the access path was not used.  A reason code of 0 indicates
 that the access path was used to implement the query.
   RUGR80DAT/RUGL020002 17, RUGR80DAT/RUGL020001 11, RUGR80DAT/PMSP02L0 17,
 RUGR80DAT/PMSL0207 11, RUGR80DAT/PMSL0206 11, RUGR80DAT/PMSL0201 11,
RUGR80DAT/PMSP0200.

So what is all this gunk?
I see that
11 - The access path contains static select/omit selection criteria which
is not compatible with the selection in the query.
and
   17 - The left-most key of the access path did not match any fields
 specified for the selection criteria. Therefore, key row positioning could
 not be performed, making the cost to use this access path higher than the
 cost associated with the chosen access method.

But what are all thsoe files?


Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Adam Lang" <aalang@rutgersinsurance.com>
To: <midrange-l@midrange.com>
Sent: Thursday, August 29, 2002 3:12 PM
Subject: Re: CPU usage for QZDASOINIT


> I got this (I cut out the beginning garbage ... assumed it was standard):
>
> included. When building the access path all primary key fields should be
> specified first followed by the secondary key fields which are prioritized
> by selectivity. The following list contains the suggested primary and
> secondary key fields:
>     POLICY0NUM.
>     If file PMSP0200 in library RUGR80DAT is a logical file then the
access
>   path should be built over member PMSP0200 of physical file PMSP0200 in
>   library RUGR80DAT.
> Recovery  . . . :   If this query is run frequently, you may want to
create
>   the suggested access path for performance reasons. It is possible that
the
>   query optimizer will choose not to use the access path just created.
>     For more information, refer to the DB2 for AS/400 SQL Programming
book,
>   SC41-5611, or the DB2 for AS/400 SQL Reference book, SC41-5612.
>
> So does it say this because policy0num is NOT indexed?  It can't be a
> primary key because it does not have unique values.
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> http://www.rutgersinsurance.com
> ----- Original Message -----
> From: "Buck Calabro" <Buck.Calabro@commsoft.net>
> To: <midrange-l@midrange.com>
> Sent: Thursday, August 29, 2002 2:59 PM
> Subject: RE: CPU usage for QZDASOINIT
>
>
> > >Ok, how would I do it with wrkqry?  Just start the debug, go
> > >into wrkqry and
> > >create the query, run it.  end debug and check the log?
> >
> > Exactly right.
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.