RE: Indexed PF vs. LF performance

We all remember different reasons. I do not remember there ever being a problem with changing a key value (like a last name change if the key was on last name). What required a unload-recreate-reload process was if you wanted to change the key from last name to first name. If you had an LF you could just delete and recreate. If you had a keyed PF you had to save the data, delete the PF, create the PF, copy the data back. Now I think you can just to a CHGPF.

The reason I remember was that doing a CPYF of an unkeyed PF was much, much faster than doing a CPYF of a keyed PF. I have no idea of that is still true or not but we still follow that rule and never key a PF

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Tuesday, July 31, 2012 10:48 AM
To: Midrange Systems Technical Discussion
Subject: Re: Indexed PF vs. LF performance

I always thought the source of the practice was index corruption. If an index got corrupted on a LF, you could just delete and recreate but if you got a corrupted index in a PF, you had to delete the PF and all the logicals and rebuild.

It was something I remember happening on the System 38 and some in the
AS/400 days but has not been a problem for many, many years.

On Tue, Jul 31, 2012 at 7:30 AM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

Oh gosh, I wasn't trying to defend a practice. Only to explain the
source of it. I apologize if it came out in any other way.

I totally agree with what you say and have keyed nearly all files for
years.


On 7/31/2012 8:15 AM, rob@xxxxxxxxx wrote:

I realize you're just trying to come up with an example so I'll throw
out the argument that keying by a person's name is silly (for the
reason you gave).

Let's say I accept that you couldn't change a PF key (many decades ago).
Well, you should have stopped there. Because when you started on
about child files you lost me. It's not like people used Referential
Integrity constraints years ago. It was easy to delete a parent and
leave all those orphans. How did not keying the PF help? Actually
it's easier nowadays to do this. You can set up the foreign key
constraints to "cascade". So if Miss A becomes Miss B it would
cascade the key change down through all the child files. Back in
troglodyte times wouldn't you have had to write a program to cascade
that key change down through the children regardless of whether or not the key was on the PF or in a LF?


Rob Berendt

--
Booth Martin
802-461-5349
http://www.martinvt.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.