Gil wrote:

>How does it handle characters absent from IBM-037?

 

I expect it will throw an error. This is, as you (Gil) know, one of the 
problems with OP’s query: you can’t stuff thousands of pounds of potatoes into 
a 256-pound sack. (OK, characters, not potatoes.) For those who don’t 
understand, consider these two characters:

зέ

The first one is Cyrillic, the second Greek. In EBCDIC (assuming the most 
common code pages of 1025 for Cyrillic and 825 for Greek), both are x’B2’. So 
while you can have a Unicode string encoded with any of the UTF family that 
contains both characters, you can’t have “an EBCDIC string” that does so 
without some metadata that says “Byte 1 is 1025 and byte 2 is 825”, which is 
(fairly) unlikely.

 

Thus you can take з and tell ICONV or equivalent to convert FROM 1025 TO 
UTF-whatever, or take έ and tell ICONV or equivalent to convert FROM 825 TO 
UTF-whatever. You’ll get two different UTF-encoded values for two different 
U+nnnn values, as you’d expect. And you can convert back, as long as your input 
string fits entirely within the target 256-byte EBCDIC code page.

 

This stuff gets pretty complex, with terms like “code point”, “Character”, 
“glyph”, and “grapheme” used somewhat interchangeably (but all are subtly 
different in specific contexts). So tread carefully.

 

>I wonder what was the motivation to require preallocated data set

>names rather than the more flexible alternative of DDNAMEs?

 

I believe it’s using ICONV on the USS side under the covers, which takes a data 
set name.

 

…phsiii


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to