Re: Looking for a faster CPYF

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.