× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Regards, Chuck

On Wed 05-May-2011 08:26 , sjl wrote:

<<SNIP>>

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
command:

CPYTOIMPF FROMFILE(MYLIB/TDC4011)
TOSTMF('/QNTC/ServerName/sharedfiles/TDC4011.TXT') MBROPT(*ADD)
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
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 STMFCODPAG.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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 [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.