Re: Replacing records in a large file (1M+ records)

On 09 Sep 2013 14:09, Jeff Young wrote:

Will I get the same (fast copy) results if I use the FromRcd(1)
keyword in the CPYF?

If the file has a keyed access path, then the FROMRCD(1) is a requirement for fast-copy, yet for a file with Arrival AccPth, FROMRCD(*START) has the same meaning as the explicitly requested RRN=1; explicitly specifying FROMRCD(1) is best if fast-copy is desirable. As I recall, the specifications ERRLVL(0) FMTOPT(*NONE) and COMPRESS(*NO) [where IIRC the latter is implied, regardless that the default value is *YES, if the entire member is copied PF to PF] are also required for fast-copy. Preceding such a CPYF request with ALCOBJ to exclusively allocate the data of the member to be copied-from would ensure the additional requirement of exclusive access to enable fast-copy.

p.s. Because this is a /recovery/ action for the FROMFILE, such that the TOFILE() previously created from source [and eventually triggers added] will become the new\recovered version of the old file, consider clearing the member of the old file and moving that old file to an alternate library rather than deleting the file; probably also ending journaling. That will allow for possible future review for how the problem arose... if it happens again, or even if the [IMO] appropriate level of concern for such an anomalous condition arose exists. After DLTF there would be nothing left to review, except what could be restored, if even the file could be restored successfully, with the alluded problem.