× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.