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".
On Wed 05-May-2011 08:26 , sjl wrote:
We want to export this Unicode file via QNTC to a folder on the
Windows XP system as Unicode data, so I executed the following
FROMCCSID(*FILE) STMFCODPAG(*STMF) RCDDLM(*CRLF) RMVBLANK(*NONE)
DTAFMT(*DLM) FLDDLM(X'05') /* tab-delimited */
Here is the problem:
This works fine the first time around, when the stream file on the
Windows machine does NOT exist - after running the CPYTOIMPF command,
I can open the Windows file with notepad and I can see the kanji
HOWEVER, if I execute this command again (copying the same data again
from the System i side) WITHOUT first deleting the file on the
Windows machine in order to append data to the existing Windows file,
the newly added records are NOT correct - if I use notepad to view
the file the original records appear fine, but the Kanji characters
in the appended data on the Windows file look like garbage.
When the file already exists on the Windows system, if I use WRKLNK
'/QNTC/ServerName/sharedfiles' and use option 8 to view the
attributes of the Windows file, it is CCSID(1252).
I already know that CCSID(1208) is not supported via QNTC on Windows
files, but is CPYTOIMPF working as designed? See the help text below