Re: IFS CCSID 1025

We need some additional background information before we can say for sure what is going on.

For your physical file, what is the CCSID? Use DSPFD and look for CCSID. I'm hoping it says 1025 (as your earlier results indicate the data is actually encoded using 1025) but with your jobs running in a combination of various job default CCSIDs one can't be sure which job actually created the file way back when... And with job CCSIDs of 65535 you could inadvertently being populating 37 tagged files with 1025 encoded data -- which would certainly throw off any system provided CCSID conversions.

For your text file, what is the CCSID? Use WRKLNK '/filename.txt' and option 8 to see the CCSID. I'm hoping it's along the lines of either 1025 (EBCDIC Cyrillic), one of the many flavors of "ASCII" Cyrillic (1251, 1131, 866, 849, 808, 872, 855, etc -- I just love how people think "ASCII" says it all :) ). To answer one of your questions, if the IFS file is processed in text mode by your application, then pre-creating the file with a given CCSID (like a Unicode CCSID) can generally force the file contents to that CCSID. The CCSIDs for Unicode would be 13488 or 1200. What command (or API) do you use when copying the data from the physical file to the IFS stream file? What parameters?

What steps do you use when FTPing the file?

Wim_Vandepoel@xxxxxxx wrote:

Since your job CCSID is 65535 database data management will always leave
the character data as-is.
In the case of the 1025 user it appears that you have Cyrillic encoded
data in the file, it's read by your application as is, and displayed on
the device as is (1025). All is well. In the case of the 37 user you are
reading 1025 data as is into the application and then displaying the 1025
data on a 37 display. Unfortunately the 37 code page and character set is
wildly different than 1025, so you're getting the basic Latin characters
OK but anything that was stored using the Cyrillic alphabet is being
displayed as if it was Latin -- you end up with rubbish. So long as
you're using a 37 based display you will always get either rubbish or
large amounts of substitution characters being generated (depending on how
the job and display file is configured).


OK, In the case of the 37 user, we just need to switch the display CCSID
to 1025 to show the Cyrillic encoded data.

But I still have a problem when moving the data off the box (ftp, ifs,
...). This is, when the translation is done on the box, it always looks
like rubbish.


How is the PC configured? If it's seeing a 1025 file in one case, and a
Unicode file in another, that might explain why it sometimes works and
sometimes doesn't. Unicode encompasses Cyrillic and Windows would be able
to handle the data in that case.


If I use CCSID 1025 to create/translate a text file in the IFS, the
encoding is always ANSI (not unicode).

We have a VB program that extracts the data, does the translation using
CCSID=1025 and creates a text file in readable format. The text file
encoding is unicode, I assume this is why I don't have to configure the
Cyrillic font on my pc.

Is there a way to force the IFS .txt file to be unicode?
And would this solve my translation/display problem?

Thanks

Have a Nice Day
Wim