Re: Looking for a faster CPYF

[CRPence <CRPbottle@xxxxxxxxx>]

  The CPYF code already contains some *limited* logic in an attempt at 
optimizing whether, with the presumed amount of data copy and with the 
specified parameters, it will be best to invalidate & then rebuild or to 
let the database maintain the access paths over the target dataspace. 
Most significant /performance/ issues are not the target for data, but 
the source of the data, by failure to copy using sequential access 
versus random [via index; keyed FROMFILE] access; i.e. leaving the 
default FROMRCD(*START) versus explicitly asking for FROMRCD(1), as 
someone else noted.

  The old style RGZPFM rebuilds access paths serially, and most always 
even better than that, is to run them in parallel [with sufficient 
memory]; i.e. there are multiple runpty-52 QDBSRV## jobs for just this 
reason.

  The access path build for creating a keyed logical member [CRTLF 
MBR(named) or ADDLFM] occurs inline to the process of the requester.

Regards, Chuck

Larry Bolhuis wrote:
> At least in the 'old days' copying files with all the LFs active
> was MUCH slower as all the paths had to be dynamically updated
> with each record. 
> Without them there CPYF gets the data over as fast as I/O allows
> and building each access path one at a time is also much faster
> than dynamically maintaining a whole bunch of them.
> As to where the work runs, I believe that when you do the ADDLFM
> to cause the system to build the AP it runs in your job. I don't
> believe the QDBSRV guys handle the builds when you do CRTLF or
> ADDLFM.