RE: Implicit Access Path Sharing

On Thu, 29 Apr 1999, Stone, Brad V (TC) wrote:

> You're never going to chain to
> the file with just A as the key and update the B field unless you are
> READEing (is that a word?) and updating the field B for every instance of  a
> particular A field.

Exactly, you answered your own question.

> 
> Think of the file as an order detail file.  Keys are invoice number and
> sequence number.  When are you ever going to chain once with invoice number
> 10056 and update a sequence number?  I would guess never.  That would really
> mess stuff up.


This is level of elementary school reasoning (and I would never insult
you, offering to you that level of logical abstraction). Think of a file
as an AS/400 object. I would NEVER guess what some other people might use
it for, based solely on my experience in my small shop. In your own
example, in READE loop based on field A, just adding 2 to the sequence
number and updating a record would create an infinite loop (providing that
sequence numbers increase by 1, and that key is A,B asc.))


Cheers,

Vanja





> 
> Bradley V. Stone
> Taylor Corporation - OASIS Programmer/Analyst 
> bvstone@taylorcorp.com
> 
> 
> > -----Original Message-----
> > From:       Vanya Jovic [SMTP:jovic@calcna.ab.ca]
> > Sent:       Wednesday, April 28, 1999 11:08 PM
> > To: 'MIDRANGE-L@midrange.com'
> > Subject:    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
> > +---
> +---
> | 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
+---