Re: CPYF

Simon Coulter wrote:

On 26/03/2010, at 1:39 AM, David FOXWELL wrote:

<ed: CLRPFM+CPYF MBROPT(*ADD) vs CPYF MBROPT(*REPLACE)>
in a standard test procedure. Has the programmer found a
subtle difference that I have missed or could results be
different?

Possibly due to the subtle (read wrong-headed) behaviour of
CPYF when *REPLACE is specified but the target file is empty.

I always hated that error, but never considered changing it since it was presumably functioning that way since the S/38. I kind of wish that I had investigated that :-( I think possibly that the origin of that implementation was to somehow limit [CPF2869 seems to imply "eliminate" vs just "limit"] the cases where copy to tape or diskette would create a label for which the copied file would then have no data. Thus probably only to have consistency across those devices and the database file members, was the target as physical database file member also coded to result in the CPF2869.

It is interesting to note, that when the FROMMBR(*ALL) is specified, given at least one member has data, the CPF2869 for any empty member does not result in the CPF2817; for either TOMBR(named) or TOMBR(*FROMMBR). I am not sure about CPYTODKT or CPYTOTAP, but they may fail on the first empty member.?

Regards, Chuck