Hi Jack,
It would appear that the data you're reading isn't in CCSID 1252
(Windows Latin-1 ASCII) but instead is either in the UCS-2 flavor of
unicode (CCSID 13488) or the UTF-16 flavor of Unicode (CCSID 1200).
In those versions of Unicode, data is stored at 2-bytes per character.
Basic ASCII characters have the same code points in Unicode that they do
in ASCII, so capital "A" character is x'41' in ASCII and x'0041' in
UCS-2. (UTF-16 is a superset of UCS-2... so for commonly used
characters, they're the same.)
That's why all of your characters have a leading x'00' character,
because the data is actually in UCS-2.
If you convert it via CPYFRMSTMF, the x'00' is the same in both ASCII
and EBCDIC, so you'll end up converting all of the non-x'00' bytes from
ASCII to EBCDIC, creating a bit of a mess where it looks like every
other character is a valid EBCDIC, and every other character is a x'00'.
You certainly CAN do this properly with the IFS APIs. Just make sure
the input file is marked with the correct CCSID (maybe 1200) before you
open the file. Then the O_TEXTDATA flag will cause the UTF-16 data to
be converted properly to EBCDIC. You may need to use O_CCSID as well,
since I don't think Unicode works in a codepage environment.
To force the CCSID to be 1200:
CHGATR OBJ('/path/to/whatever') ATR(*CCSID) VALUE(1200)
I'm unsure about whether CPYFRMSTMF understands CCSIDs or whether it
only works with code pages. But, after performing the preceding CHGATR,
you might try specifying STMFCODPAG(*STMF). This tells it to use the
code page that's already associated with the stream file (Which will be
1200 since you just set it with CHGATR).
CPYFRMSTMF FROMSTMF('/path/to/whatever') STMFCODPAG(*STMF)
If that doesn't work, you could use the CPY command to translate the
file before doing the copy.
CPY OBJ('/path/to/whatever) TOOBJ('/path/to/newfile')
FROMCCSID(1200) TOCCSID(37) DTAFMT(*TEXT)
.. then the data will already be EBCDIC, and you can go ahead
and use CPYFRMSTMF... CPY is really just a "plan B" if
CPYFRMSTMF doesnt support CCSIDs, since I don't know if it
does ..
Or, if you want to try it with the IFS APIs from an RPG program, you
should have no problem... those I know will handle CCSIDs properly...
fd = open( '/path/to/whatever'
: O_RDONLY + O_CCSID + O_TEXTDATA
: 0: 0);
Of course, if the data has already been improperly translated to EBCDIC
in the IFS file, you'll have bigger problems. In which case, you'll
have to look at your file transfer scenario, and make sure that it's not
mistranslating it.
HTH
Jack Prucha wrote:
I'm trying to move a .csv file from the IFS to a DB file. The output from
CPYFRMSTMF & CPYFRMIMPF has x'00's as the 1st character of each record and
other x'00's added after each character. This is an example of what I see
on the iSeries:
* 5 * / * 2 * 1 * / * 2 * 0 * 0 * 8 * *
00F5006100F200F1006100F200F000F000F8004000
The results are the same for all data types - dates, numbers, text.
This is one of the many CPYFRMSTMF statements I've tried:
CPYFRMSTMF FROMSTMF(DepositDetailAll.csv)
TOMBR('/QSYS.LIB/JJPDTA.LIB/UPDCFILE2.FILE/UPDCFILE2.MBR') MBROPT(*REPLACE)
STMFCODPAG(1252) DBFCCSID(37) ENDLINFMT(*LF)
The file is produced by a 3rd party windows package we use. A report
option in the package produces a list of records in .csv format onto a
mapped IFS drive. I've tried both CPYFRMSTMF and CPYFRMIMPF using every
codpag and ccsid mentioned in this forum. Notepad and Excel read the file
without any problem. Using one of Scott Klement's examples, I wrote an
RPG ILE program to read the IFS file and write it to the DB output file -
no difference either. Using debug I could see the x'00's in the input
file.
I'm sure I can write something to strip the hex zeroes out, but why can't I
just copy the file without them?
TIA
Jack
midrange.com
