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



Does your EBCDIC CCSID support turkish characters ?

On Wed, Jun 20, 2012 at 10:09 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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.


--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.