Re: CPYFRMIMPF/STMF adding x'00's

Thanks Scott, Wilt, and Rob for your suggestions.

Using DSPF I can see that the file is unicode. However, I'm still not
doing something right.

CPYFRMSTF .... STMFCODPAG(1200) DBFCCSID(37) returns CPDA09B "CCSID
conversion could not be performed."

Changing the attribute of the input file with
CHGATR OBJ(DepositDetailAll.csv) ATR(*CCSID) VALUE(1200)
and then changing the RPG open to
fdin = open( %trimr(inputfile):O_RDONLY+O_CCSID+O_TEXTDATA:0:0 );
causes translation problems. With debug I can see that the entire input
buffer is x'3F'. DSPF on the input shows the same.

Changing the CCSID of the input file back to it's orignal 1252 returns to
the original problem of the x'00's. The os is recent (5.4).

Any other suggestions?

Thanks
Jack

midrange-l-bounces@xxxxxxxxxxxx wrote on 05/27/2008 02:23:10 PM:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.