|
This was a rhetorical question, but now that you have responded, I don't see what you statement about nasty surprises is. 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. 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. 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.