× 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: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Wed, 28 Apr 1999 08:47:59 -0500

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.