Re: Indexed PF vs. LF performance

The "incorrect" way is the way they're coming off now.

I'll make sure everything else is A-OK first, then get with Betsy on
changing that.


On Tue, Jul 31, 2012 at 4:53 PM, Charles Wilt <charles.wilt@xxxxxxxxx>wrote:

Yes, assuming your CPYF default hasn't been changed from COMPRESS(*YES)...

The COMPRESS parm should probably be changed to (*NO) along with the
FROMRCD(1) if you want the absolute fastest...

Charles

On Tue, Jul 31, 2012 at 3:45 PM, <rob@xxxxxxxxx> wrote:

So, without the fromrcd, it's like a CPYF and a reorg at the same time?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx
,
Date: 07/31/2012 02:42 PM
Subject: Re: Indexed PF vs. LF performance
Sent by: midrange-l-bounces@xxxxxxxxxxxx



CPYF runs slower on an index PF if you neglect to use
FROMRCD(1) TORCD(*END)

With FROMRCD(1) the file is copied in RRN order and not in keyed

order...

HTH,
Charles


On Tue, Jul 31, 2012 at 11:11 AM, Mike Cunningham
<mike.cunningham@xxxxxxx> wrote:

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

.

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


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

--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.