× 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 12:07:50 -0400
  • Organization: Arbor Solutions, Inc

Brad,
  Good question.  Often you would not create LF2 since you may not
neccesarily need it.  If you need two views in the same program it
makes it easier.

  However as I commented earlier we must remember that access paths do
ROW sequencing and selection.  It is very possible that the two LFs
have very different record formats but share the access path
requirements.

 - Larry

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

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

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.