MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » May 2008

Re: CPYFRMIMPF/STMF adding x'00's



fixed

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









Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact