David Boyes wrote:
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.
I don't understand the above. On ASCII terminals, often a control is
printed as '^<letter.', but entering requires pressing two keys at the
same time. It seems like you are saying that the terminal will send a
control character whenever a not or cent or maybe caret is typed
whenever followed by a letter. If so, how then does one enter these
three characters literally? And where could I find a mapping to look
at, a sample for one of the code pages?
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
----------------------------------------------------------------------
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
