Re: Implicit Access Path Sharing

I don't know what happens physically, but I know if LF1 is deleted, then LF2 
will
own the access path.

Pete

"Ladutko, Bob" wrote:

> Also, what happens if LF1 is deleted?  Does LF2 access path automatically
> get rebuilt then, or when it's needed?
>
> > -----Original Message-----
> > From: Stone, Brad V (TC) [SMTP:bvstone@taylorcorp.com]
> > Sent: Wednesday, April 28, 1999 9:48 AM
> > To:   'MIDRANGE-L@midrange.com'
> > Subject:      RE: Implicit Access Path Sharing
> >
> > Then the question is, if you already had LF1 with A & B as keys (and no
> > selects, etc), why would you create LF2 with A as a key?  That's redundant
> > to begin with and does you no good assuming there are no other criteria
> > needed by either logical.
> >
> > Bradley V. Stone
> > Taylor Corporation - OASIS Programmer/Analyst
> > bvstone@taylorcorp.com
> >
> >
> > > -----Original Message-----
> > > From:       Pete Massiello [SMTP:pmassiello@os-solutions.com]
> > > Sent:       Wednesday, April 28, 1999 7:32 AM
> > > To: MIDRANGE-L@midrange.com
> > > Subject:    Re: Implicit Access Path Sharing
> > >
> > > 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
> > > > +---
> > >
> > > --
> > > Pete Massiello
> > > OS Solutions International
> > > Phone: (203)-744-7854  Ext 11.
> > > http://www.os-solutions.com
> > > mailto:pmassiello@os-solutions.com
> > >
> +---
> | 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
> +---

--
Pete Massiello
OS Solutions International
Phone: (203)-744-7854  Ext 11.
http://www.os-solutions.com
mailto:pmassiello@os-solutions.com


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