Hi Juan --
TN3270 is an EBCDIC protocol.
When a TN3270 client program connects to a z/OS or z/VM or z/VSE or
z/TPF host (typically on TCP port 23) and negotiates for TN3270,
everything is EBCDIC after that. (Well ... everything except the
signalling, of course. But the textual content is all EBCDIC.)
When you use a 3270 emulator, what happens depends on the emulator. Best
I can tell, most graphical 3270 emulators use an EBCDIC font, so the
characters don't have to be translated.
Even so, yes, there are code pages. You can tell your emulator which
code page to use (e.g., CP500). I confess, I don't know with certainty
that the EBCDIC fonts do not require A/E mapping, but it's obviously
silly if they do.
Ideally there's no translation for a graphical 3270 emulator.
C3270 is a text mode 3270 emulator for Unix and Linux. It talks to an
ASCII (or ASCII-like) pseudo terminal (which in turn usually involves
emulation).
C3270 must convert the EBCDIC 0xC1 to ASCII 0x41, and same for the rest
of the printable characters.
There must be A/E translation for textual 3270 emulators like C3270.
Over the years, the most common translations developed around CP500 and
CP37. Sadly, these are not completely compatible. Most characters map
nicely, but square brackets and one or two other characters are a
continual pain.
The ASCII side is ISO-8859-1 in most cases, so for emulators like C3270,
there must be a mapping between CP1047 (for example) and ISO-8859-1.
Many people lost many hours grasping for the ideal translation table.
BUT NOW the world has gone Unicode. Most of your "ASCII" systems
actually speak UTF-8. That definitely belongs in a separate reply.
Does this help?
-- R; <><
On 10/10/23 12:18, [email protected] wrote:
Hi!
I want to understand how TN3270 emulation works regarding convertion of
characters (between EBCDIC and ASCII, and viceversa).
This is how I think it works (more or less), but I am not sure at all. So
please let me know about any mistakes.
Let suppose that you use a TN3270 emulator program to access the ISPF browser to display a dataset.
Let also assume, to simplify, that it contains just a single character, an "A".In DASD,
what is indeed stored is X'C1' or, to be more accurate, BINARY'1100 0001'. When you BROWSE the
dataset, then the Mainframe sends to the TN3270 PC client exactly X'C1' (BIN'1100 0001'). No
convertion is done at the Mainframe side. Then, when the TN3270 client receives X'C1', because it
knows that this is a TN3270 session and that its configured CODEPAGE is say 500, it realizes that
X'C1' corresponds to an "A" displayable character. And, before sending the instruction to
display it on the PC screen, it converts X'C1' to X'41'.
Is this more or less how this works?
Thanks in advnace for your help,
Juan Mautalen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
