Re: WRKDBF & V5R4 - CPYF request changed, to fix UNDEL2 for an 'unrecovered data' scenario

Chuck,

Thanks for the insights about 'fast copy'. That explains it.

--Dave

CRPence wrote:

Comments inserted after inline snippets.

One case I've seen that causes the problem is when the original file
has a unique index. The old UNDEL2 copied the records to a file in
QTEMP using CPYF CRTFILE(*YES), which creates an indexed file. In
that case, CPYF sets fields in the deleted records in the QTEMP file
to default values (blanks/zeros). Don't ask me why :-)

The difference is what is described as 'fast copy' versus 'row copy'
code paths in CPYF processing. I checked the old UNDEL2 source which
does not specify any ERRLVL() parm on CPYF. Much like most coded
command requests, the request is neither library qualified nor are all
the necessary parameters specified to ensure all assumptions are met, to
avoid being broken due to changed command defaults. The assumption
here, is going to be that fast-copy is required, because if row-copy is
used, the data from the delete row becomes defaults. To ensure fast
copy code path is even possible, ERRLVL(0) is required. I believe the
FMTOPT(*NONE) is also mandatory. Additionally for fast copy, the
FROMFILE() must not be in use; i.e. before the copy, issue:
ALCOBJ ((fromlib/fromfile *file *excl frommbr))

The row copy is the same as all other DB I/O, regardless that it is
being done in the CPYF utility. That is, a deleted record does not
appear to exist, except as a direct/RRN read. And when a read of a
relative record number of a deleted record is done, the buffer is just
the defaults.
The fast copy on the other hand will copy a /chunk/ of dataspace data
into the other dataspace. So just like save does not access row.data,
nor does the fast copy. In both cases, whatever data was there in the
original file, is copied to the target location; of course in CPYF, the
selected rows.
I know off hand, just one unattractive manner to verify that
fast-copy was used. I have used a breakpoint program for instruction
'/1' for QDBFFCPY, to set an indicator to be tested after the CPYF
completes.

> The new version uses CRTPF to create the file in QTEMP first, without
> an index, then CPYF's into it, which somehow induces the system not
> to set the fields to defaults.

A unique index causes the copy request to drop into the row copy
mode, to enable the index on the tofile to diagnose any duplicates;
irrespective of any apparent or perceived logic seeming to make that
unnecessary. In so doing, ensures the copied data is valid in the new
file according, to the unique index of the new file.

> Chuck Pence inferred that the problem might be because date, time, &
> timestamp fields are stored in the file in a different format from
> how they appear in a program's buffer (or in DSPPFM). UNDEL2 already
> handles that -- you can see the code in the source for UNDELM2,
> subroutine "reformat".

He-heh. Not so much my inference as it was a redirection, back to
the "Speculation" that alluded the missing data occurred "whenever the
file includes a data, time, or timestamp field but I'm not sure". It
seemed important to redirect to anything other than the implication that
"it appears the OS fails to copy the original raw data to the SAVF in
some cases". Alluding the save may not be saving the exact image of the
data on disk, would imply also, that a restored copy was not the same
data as the original. I was quick to redirect anywhere but there,
offering only how an issue with the date/time/timestamp might be a more
likely origin for difficulties. :-) Of course in learning of the CPYF
usage, it is now clear that the code path CPYF uses, determines if the
undelete request functions as expected.

Regards, Chuck