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



No, that was on V5R1. I think this stuff shows that IBM has actually worked out good stuff here. Making the PF the owner of a shared access path would seem to make restores happen correctly. of course, David's experience shows there is perhaps a problem in that arena. ;-)

Vern

At 09:56 AM 4/3/2005, you wrote:
yeah, was that V5R3?

I haven't jumped on any of my clients machines yet this morning... I was
gonna try it again on V5R2 and V4R5 as well as V5R3, but I don't have
anybody at V5R1 anymore...


On Sun, 2005-04-03 at 10:53, Vernon Hamberg wrote:
> Just tried that experiment with using the LF key as primary. Turned out
> that the PF became the owner of the access path, which surprised me a
> little. Before the ability to CHGPF based on a source member, it would not
> even have been possible to add keys to a PF without deleting the dependent
> LFs first.
>
> Later
> Vern
>
> At 09:40 AM 4/3/2005, you wrote:
> >That's what I thought - we on the S/38-i5 have often used "primary key",
> >if we've used the term at all, to mean the key of the PF. As we've been
> >saying, this is not the "official" meaning in relational discussions. BTW,
> >my apologies if this seems too theoretical - I'll be done soon.
> >
> >The question of shared access paths is not theoretical - the space and
> >performance implications are important. I saw the "consumption" process
> >when I added a primary key constraint on the PF with a key. Then I tried
> >taking it off. Other than the fact that it took forever for the system to
> >bring up the CPA32B1 message, I was intrigued that it gave me the choice
> >of removing the key completely or keeping (restoring) the original key.
> >
> >I'd not thought of the primary key coming from a logical with unique key.
> >Interesting. And, since sharing is dependent on the order of creating the
> >keys, a few experiments would be interesting. When I have some time. ;-)
> >
> >Thanks
> >Vern
> >
> >At 07:17 AM 4/3/2005, you wrote:
> >>True. I may not have been precise enough in my language there. My fault.
> >>
> >>Generally in dealing with iSeries shops, when they say primary key, they
> >>aren't usually refering to a "real" SQL DDL primary key constraint, but
> >>either a logical file's or the physical file's key specification that
> >>they consider to be primary.
--
"Bigamy is having one wife too many. Monogamy is the same."
-- Oscar Wilde


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.