The problem has been handed off to whoever is responsible for CPYTOIMPF and
we don't have a definitive answer yet, but it appears highly likely that IBM
is going to indicate that CPYTOIMPF is "working as designed".
After analyzing the trace that I sent, Kent indicated that when I perform
the second CPYTOIMPF command to append data to an existing Windows file that
the system is translating the data to 1252 because that is the CCSID that
the Windows file is tagged with under QNTC, thus trashing the appended
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 characters.
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 for
This thread ...
Re: CPYTOIMPF question - feature or bug?, (continued)
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact