> I notice, though, that the translations on the page you point out are > not symmetrical. In particular, the ascii->ebcdic translate table > converts ascii square brackets (x'5B', x'5D') to ebcdic x'AD' and > x'BD', but the ebcdic->ascii translation presumes square brackets are > at x'BA' and x'BB', and translates those characters to ascii x'5B' and > x'5D' respectively. x'AD' and x'BD' both translate to ascii x'07'.
The translation when talking to the HMC should match real hardware (though perhaps with a switch; the default should match the hardware). If that is CP 500, so be it. Both 500 and 037 are slightly wrong from the customer usage standpoint. This opens up old wounds. EBCDIC square brackets are AD and BD in practice, not 500 or 037. The translation when talking to VM, specifically the 3215, should be either CP 1047 or (better) "CP 37 version 2", which is a customer-defined animal (more like a protest). 1047 is the "open extensions" codepage and gets the brackets right. "CP 37 v2" goes further and gets the ASCII circumflex "hat" and EBCDIC "not" mapped properly. I haven't had time to create patches to fix this let alone maintain any such patches. :-( > Any idea why that is so? Shouldn't those tables be symmetrical? Even with the above recommended translations, it is fair that console kernel codepages be asymmetrical: The console is vital to system operation and not used much for things like code development, so you want to be able to issue commands, though their output might look funny. (Square brackets ... it's always the square brackets.) The idea is that what is typed-in gets mapped to the most likely useable subset. Here too, a switch after the fact would be reasonable. -- RMT
