Re: CPYTOIMPF question - feature or bug?

Chuck -

When I run the same CPYTOIMPF command using as the destination a folder in
the IFS rather than a Windows folder via QNTC, it creates a stream file in
the IFS folder with CCSID(1208). When I run the command a second time in
order to append the same data to the existing stream file, the appended data
appears to be correct, which makes sense since both the PF and the STMF are
CCSID(1208).

- sjl


Chuck wrote:
FWiW the STMFCODPAG on that command is deprecated since v7r1. The
parameter existed originally, only to support the original "design"
which followed the work of the export to a database file [not sure if to
a program-described or a CCSID-tagged source PF] with a CPYTOSTMF; the
database export request having passed the token directly to that other
command for the _second copy_ of the data. At 7.1 the new parameter of
STMFCCSID is introduced to supersede STMFCODPAG.

I do not know the reason why there would not be a consistent
translation by the CPYTOIMPF processing from 1208->1252 on both
invocations [as inferred should be the case with WRKLNK "8=attributes"
showing 1252], though the special value *STMF leaves the export utility
to make a decision for the requests. However I would expect that the
issue [i.e. the inconsistency] may be resolved by explicitly specifying
the value 1252 versus specifying the special value *STMF on that
parameter.? If after a RMVLNK the two\repeated requests performed using
STMFCODPAG(1252) produce the expected result, then I guess that can be
considered a resolution [or circumvention] without actually knowing
whether neither, either, or both of the invocations with
STMFCODPAG(*STMF) are "working as designed".