RE: Implicit Access Path Sharing

Brad,

Usually, when you want to update field B and you don't want nasty
surprises. However, that is also situation when you don't want sharing to
happen :)))


Vanja Jovic,
Canada

On Wed, 28 Apr 1999, Stone, Brad V (TC) wrote:

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

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