> I'm working on EBCDIC support for Perl 5. I'm not familiar with EBCDIC > terminals, but apparently there are asynchronous ones.
Very, VERY rare -- to the point of almost non-existent. The 3270 is the primary terminal type, and it's half-duplex, page-oriented. The older line-mode terminal (the 3215) is emulated, and pretty much behaves as a dumb TTY. > How can one enter a control character from such a terminal? On ASCII > terminals, pressing the Ctrl key and another at the same time generates > a control sequence. Since H is the eighth letter of the alphabet, > CTRL-H sends 8, which is a backspace on ASCII platforms. Is there > something similar that happens on EBCDIC? The convention to enter a control character is to use the digraph '^<letter>' (EBCDIC not or cent sign (depending on code page) + character) and have apps translate that to the appropriate code point. The issue is that control characters in a 3270 world don't work the way they do on byte-oriented terminals, so they're rare (if not almost non-existent) in the 3270 environment. In the rare event a control character is used, it's almost always represented as a hex value in a string (for example to enable color or highlighting), and those don't occur as control characters. > The few EBCDIC code pages that I'm familiar with have 65 controls: 0 to > 0x1F plus 0xFF. Are all 65 enterable from the keyboard? See above. > I see from the archives that there are some problems between the ASCII > LF (or NL) and the EBCDIC NEL. Is there a rule of thumb for which of > these, or both, should mean a new-line, matching, say, '\n' in the C > language? On a page-oriented terminal, the concept is somewhat difficult to represent. Writing a newline doesn't actually update the screen until you rewrite the page. On the older terminals (3215), the equivalent would be processing a CR/LF pair. In fact, you pretty much need to assume that all line-oriented I/O has exactly the function of a TTY. No cursor positioning, nothing smarter than a TTY. > Also, in looking at the Perl 5 source code, it is clear to me that no > one is running modern Perl versions on EBCDIC platforms, because it > wouldn't work. But I can't imagine a Linux system without Perl. Could > someone explain? Linux on z is an ASCII system. Perl works just like it does elsewhere. Ditto with OpenSolaris for Z. There isn't anything in the Z hardware that dictates the use of particular character sets; it's just what you program it to recognize as character graph 'A'. IBM has included machine instructions to help process EBCDIC data, but that's for the convenience of OSes who choose to code data that way. I guess I would ask "what kind of EBCDIC support are you creating"? Other than providing a string translation function (to_ascii, or to_ebcdic), I'm not sure what EBCDIC support for Perl would mean. Perl already has a codepage mapping toolset, and there are a number of EBCDIC variations, so the question of "which EBCDIC?" comes up. Are you porting Perl to a specific IBM OS? If so, that might be a very different set of questions. -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
