× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Implicit Access Path Sharing
  • From: Larry Bolhuis <lbolhui@xxxxxxx>
  • Date: Wed, 28 Apr 1999 09:54:20 -0400
  • Organization: Arbor Solutions, Inc

Pete is correct about the sequencing.  Always build access paths with
the most key fields first to maximize opportunities to share access
paths.  One thing that I have not tested (but suspect to be true) is
library restores.  If the files were saved ACCPTH(*YES) you should get
back exactly what you saved. However if you use the default
ACCPTH(*NO) the system will probably build 'em as it restores 'em,
which will be in alphabetical order I believe, which means that you
may lose sharing that you had before the save/restore.

 - Larry

Pete Massiello wrote:
> 
> Adding to what Larry said,
> 
>     If LF1 is created with keys A,B followed by LF2 which is created with key 
>A.
> LF2 would share the access path of LF1.  This has the effect of saving 
>storage,
> but more importantly improving performance.  Now the important item with the
> above example of LF1 & LF2, if you create LF2 before you create LF1, then the
> files would NOT be implicitly shared by OS/400.  You need to create the LF 
>which
> has the longer key first, and then create the subset key for OS/400 to 
>implicitly
> share an access path.  Using select/Omits as Larry said, would negate any
> sharing.
> 
>     Pete Massiello
> 
> Larry Bolhuis wrote:
> 
> > Mark,
> >
> >    When LFs are created with CRTLF (as opposed to via SQL) access
> > paths are shared when the key fields of the file being created match
> > those in an existing access path. For example an LF being created for
> > key fields 'A' and 'B' would share an existing access path for LF with
> > keys 'A' 'B'(obvious case) but it would also share with LF that has
> > keys 'A' 'B' 'C'.  It would NOT share an access path with LF keyed 'D'
> > 'A' 'B'.  Additionally other attributes must match.  These include
> > sequence (ascending/descending), Select/Omit and Dynamic Select.  In
> > some cases certain attributes may be overriden.  I have seen Dynamic
> > Select ignored when the existing access path does not use it.
> >
> >    I don't believe the format name has any effect. For example it you
> > have a PF with fields 'A' through 'F'.  LF 1 has keys 'A' and 'B' and
> > includes fields 'A' 'B' 'C' and 'D'.  LF 2 with keys 'A' and 'B' but
> > selecting fields 'A' 'B' 'E' and 'F' would still share the access
> > path.  Remember that the access paths select and sequence ROWS.
> > Column selection is independant of the access path.  We RPG types tend
> > to equate access paths with LF and this is not the case.
> >
> >  - Larry
> >
> > Mark Lazarus wrote:
> > >
> > >  Can anyone explain when Implicit Access Path Sharing is not used?  Would
> > > it be used when creating the identical *LF, but the fields are specified 
>in
> > > the DDS?  How about if the format name is different?  According to my
> > > observations the latter would not share the AP.  Why not?
-- 
Larry Bolhuis         | What do you want to reload today?
Arbor Solutions, Inc  | 
(616) 451-2500        | Two rules to success in life:
lbolhui@ibm.net       | 1. Never tell people everything you know.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.