RE: Looking for a faster CPYF

Several years ago I was working at a company that had a multi-member file containing historical data. I was responsible each year for creating a new member for the current year, and relinking the logicals to point to the correct member. Each logical pointed to the member by the number of years in the past the program was suppose to look. Each member had several million records. The first time I relinked it, it took several hours to complete all of the logicals. I just submitted a job for each logical.

Then we had inventory and the programming staff was responsible for entering the data from the count. So we got there on a Saturday and waited until the count started and the first inventory sheets came up from the warehouse. During that time, I was curious and since no one else was on the machine, I sat down and allocated almost all the memory in the machine to the proper pool and submitted the same jobs as before. Less than 10 minutes later all were completed. I figured all that memory allowed the build process to take bigger bites of the records in the members and sped the process up. I was amazed that such a simple change could have such a large impact.

If managing memory this way is possible, you might consider finding command or APIs that will allow you to manipulate memory for the copy. It might speed things up like you want.

Thanks,

Marvin


----------------------------------------------------------------------

message: 1
date: Thu, 5 Feb 2009 10:46:04 -0600
from: "Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx>
subject: RE: Looking for a faster CPYF

Good question.
In most cases, eliminating keyed access path maintenance and doing it after
the fact is (much) faster. Where it isn't is when you are just adding
records to the existing file and don't really need to rebuild the access
path for the entire file (original records are already in the access path).
This is one case where CHGLF *DLY may hold an advantage to RMVM or CHGLF
*REBLD.
And yes, LFs are unusable until they're fully rebuilt, but the overall time
for the CPYF processing drops down.

BTW Charles, don't forget that constraints are implemented as a binary radix
index as well (primary key, unique constraint, foreign key constraint). And
DDS PF can have a non-unique key. All of these access paths are maintained
in real-time so you may want to eliminate their maintenance as well.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com

-----Original Message-----
Subject: Re: Looking for a faster CPYF

<snip>
automatically removing LF members for the copy and readding afterwards.
</snip>
Is this truly faster? So, sure, the CPYF command may be done but are the
logicals unusable for a long period afterwards because there are system
tasks like QDBSRV.. at the bottom of the WRKACTJOB rebuilding the indexes?


Rob Berendt