× 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.



On 15 Jun 2012 14:42, John Allen wrote:
Sorry, I just am not getting this,
What I am trying to get to is - what do I need to change to get these
turkey characters into an ASCII file (and display using Notepad)

IIRC Notepad can deal with Unicode. Perhaps use that instead?

I need to write the turkey characters out to a ASCII file from an RPG
program, so I started with Scott's sample program CH5ASCII).


I have no idea what the variation on the program CH5ASCII is\does; presumably the open() [with O_CCSID + O_TEXTDATA + O_TEXT_CREAT] with implicit iconv() or perhaps explicitly iconv() is used to convert data from one CCSID to another.?

Regardless, whatever glyphs display from whatever software, may be irrelevant in verification of proper translation\conversion of the data; i.e. always examine the code points of the data, viewed as binary data versus text data, rather than examining the visual representation [AKA "glyphs"] to draw conclusions about the effects of conversions. Opening the file in Notepad on a Turkish MS-WIN OS will presumably display either the code points x'A6' and x'98' [CP857; e.g. CCSID 9049] or the code points x'D0' and x'DD' [CP1254; e.g. CCSID 1254], as the expected glyphs, irrespective of the CCSID assigned to the STMF. Thus the two EBCDIC code points x'5A5B' should presumably convert to either x'A698' or x'D0DD'. The latter seems to have been the effect [I made corrections to the observations in my prior quoted message; see "<ed:"] when using the ASCII CCSID 1252, even though the code points x'D0' and x'DD' in CP1252 do not represent the desired\expected characters in that target CCSID. Interestingly, that makes me wonder if perhaps the WIN PC is configured [to expect] that its data is in the ASCII CCSID 9049; i.e. perhaps the code points x'A698' as presented with Notepad will present the glyphs 'Ğİ'.?

I have a file in the IFS that was generated from some other
software, it has code page 1252 assigned to it (using WRKLNK to
view the attributes) and it displays these characters fine


So presumably "it", for "displays" is Notepad, as alluded earlier? So what are the hex values, the code points, for which the expected glyphs are presented? And that PC has a Turkish language\locale installation and setup?

What is it that I need to change?

As I had already noted, the chosen ASCII CCSID 1252 "MS-WIN LATIN-1" as a conversion-to CCSID does not support either of the named characters "G Breve Capital" and "I Overdot Capital". I had alluded possibly that using the ASCII CCSID 1254 "MS-WIN TURKEY" for the conversion-to CCSID might be more appropriate [than the ASCII CCSID 1252 "MS-WIN LATIN-1"], because the CCSID 1254 actually defines\supports both of those characters. Presumably a MS-WIN OS with a "Turkish" language setup\installation will be able to present the proper glyphs in Notepad when those equivalent EBCDIC CCSID 1026 "TURKEY LATIN-5 EB" [or 1155, with Euro support] characters have been converted to the ASCII CCSID 1254 [or maybe instead ASCII CCSID 9049].?

Are you saying I cannot use Scott's program example CH5ASCII to
write these characters into the IFS file as an ASCII file then
open the file with notepad and see them?

I was only attempting to imply that the choice [of CCSID 1252] as target CCSID seemed suspect [for lack of support in CP1252 for the two characters expressed as being desirable to be seen; i.e. LG240000 and LI300000], and thus that there should be no surprise that using the chosen CCSID brings no joy.

Or do I need to change the CCSID values (1026 and/or 1026) to
something else?


FWiW the EBCDIC CCSID 1155 replaces EBCDIC CCSID 1026, ASCII CCSID 5350 replaces ASCII CCSID 1254, and ASCII CCSID 9049 replaces ASCII CCSID 857, where each replacement includes the Euro symbol.

Regards, Chuck

On Wednesday, June 13, 2012 5:11 PM CRPence wrote:

On 13 Jun 2012 11:56, John Allen wrote:
<<SNIP>> there are a few characters not converting correctly
Couple of examples:
Hex 5A Latin Capital letter G with Breve above Ğ displays as a Ð
Hex 5B Latin Capital letter I with dot above İ displays as a Ý

Most of the characters are fine but want to make sure I have done
it correctly.

I want to create an ASCII file with Turkey characters in it from
code page 1026 I want the file to have code page 1252 assigned to
it in the IFS (I think)

<<SNIP>>

CP1252 does not have the character identifiers LG240000 and
LI300000 whereas CP1254 and CP1026 both do. The effect of [what I
infer is] <ed: correction:> x'D0' and x'DD' are presumably chosen
for /round tripping/ the data; i.e. those target code points as
conversions-to can be safely changed to the inverse on the
reverse translation [conversion-from], because neither LD640000
nor <ed: correction:> LY120000 exist in CP1026.



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.