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.

--
Regards, Chuck
--
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.