Hi Jack,
I'm guessing (and this is just a guess, as I'm still rather unclear as
to everything that's going on) that the file *WAS* Unicode. But,
somewhere along the line, someone tried to translate the Unicode file
from ASCII to EBCDIC. Keeping in mind that the file was never ASCII to
begin with (it was Unicode) you can see why an ASCII/EBCDIC translation
would cause a big problem.
Why do I think this? Well... your original message provided the
following hex values:
* 5 * / * 2 * 1 * / * 2 * 0 * 0 * 8 * *
00F5006100F200F1006100F200F000F000F8004000
x'00F5' isn't the Unicode value for 5. The Unicode value is x'0035'.
Also, x'35' is the ASCII value for 5. If you translated your file
(Correctly) from Unicode to EBCDIC, the first two bytes (x'0035') would
be replaced with one byte x'F5'. However, if you told it that the file
was ASCII instead of unicode, the x'00' would be translated to x'00'
(since x'00' is the same in both ASCII and EBCDIC). and the x'35' would
be replaced with x'F5', so you'd end up with a file starting with
x'00F5' which is what you describe.
To solve the problem for this file:
CHGATR OBJ(DepositDetailAll.csv) ATR(*CCSID) VALUE(37)
CPY OBJ(DepositDetailAll.csv) TOOBJ(TempDeposit.csv)
DTAFMT(*TEXT) TOCCSID(819)
CHGATR OBJ(TempDeposit.csv) ATR(*CCSID) VALUE(1200)
The above changes the file to an EBCDIC CCSID. Then translates it from
EBCDIC back to ASCII (reversing the earlier process). Then changes the
CCSID to the CORRECT 1200, since the data should now (if my guess is
correct) be back to valid Unicode. Note that the translation part of it
works by copying the file to another file, and doing translation as part
of the process. So you still have the old one (in case I'm
misunderstanding and messing things up worse!)
Anyway, at this point, if you view the file in hex, it should start with
x'0035' instead of x'00F5' as you described earlier, thus showing that
it's genuine Unicode.
At this point, the open() statement from your last message should work
properly.
The next question is: How is it getting into this "corrupted" format to
begin with? If I had to guess (and, at this point, I do) I'd guess that
you're trying to copy the file using FTP in ASCII mode, or some similar
method. Since these "blind copy and translate" type functions like
ASCII mode will translate the file from ASCII to EBCDIC (despite that
the original file wasn't ASCII) you'll have a mess on your hands.
Consider switching to a binary-safe transport. FTP in binary mode, or a
similar tool.
Once translated, you should be able to set the CCSID with CHGATR to
force it to be Unicode instead of ASCII from the i5/OS perspective.
HTH
Jack Prucha wrote:
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.
midrange.com
