Re: CPYTOIMPF question - feature or bug?

["sjl" <sjl_abc@xxxxxxxxxxx>]

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".