"Tony Harminc" <email@example.com> wrote:
> Just a few very minor comments. In general my comments are not meant
> to be inserted as text - they're for your information. I've left
> headings in to help identify the places.
I appreciate them, many thanks!
> > This document represents a survey of the following terminals:
> > IBM 3164 and 3270 [15,16,27]
> Really, "3270" is not a terminal, i.e. there has never been a device
> made by IBM with that model number. Rather, 3270 is an architecture...
Right -- sloppy wording again.
> with a large number of IBM terminals having been made that conform in
> varying degrees to its specifications. Typical 3270 model numbers
> are 3277 (the earliest implementation c. 1971), 3278 (the thing that
> most people think of when they think of a "real" 3270, c. 1977)
The one that weighs about 700 pounds :-) (318 Kg)
(Actually it's not so heavy compared to the 2741...)
> > 5.3. EBCDIC Control Pictures
> > EBCDIC name. There are no known "2X" forms in use.
> I don't understand what this means. Are you saying that none of the
> EBCDIC control characters in the range X'20'-X'2F' are in use ? This
> is certainly not true. It probably means something else, but it's
> not obvious to me.
Sorry, sequential reading required again :-) You probably skipped directly
to the EBCDIC sections. "2X" was my shorthand for 2-character abbreviations
for 3-character mnemonics, such as used in the Display Controls font of
Wyse and Televideo terminals (see Section 5.1).
> > Table 5.5: 3270 Terminal Operator Status Indicators
> > Code Description
> > E080 Human stick figure
> > E081 Human stick figure in box
> > E082 Clock at 6:10 (or 1:30)
> Oops - I think I meant 2:30. :-)
> As for the double vs single width issue, I did look at some "real"
> 3270s today, unfortunately made by Memorex/Telex (who were never
> known for great faithfulness to the IBM model). They have a very
> tall, thin, squished looking clock that is clearly a single cell.
> One PC-based terminal emulator I have is TCP3270 from McGill
> University (since sold to Hummingbird Communications), and it ships a
> font with the two clock halves in separate characters in order to get
> a satisfactorily round clock face of legible size. It winds up being
> a 1 1/2 width character.
Do you think this is worth worrying about? We certainly have a lot of
glyphs in Unicode that are more complex than this but, presumably, fit
in a single cell.
> > E083 White rectangle with stroke (1)
> > E084 Black rectangle with stroke (2)
> > E085 Lighting with stroke (3)
> > E086 Security key (4)
> > E087 Black and White Right-Pointing Triangles (5)
> Elsewhere it was suggested that the 4 and 6 in boxes were just
> inverse video characters; I think they are different. In particular,
> if we have a "white" numeral, then the surrounding box is also
> "white", and the background inside the box is "black".
Do you think it matters? We need to conserve code points whenever possible;
in this case it would seem to me that no information is lost by displaying
full-cell inverse video digits. I should probably have a look at a real
> > (4) A picture of a key (indicating the keyboard is locked).
> This should not be unified with other lock or key-like symbols, in
> particular with the locked padlock commonly used to indicate shift
> lock. (This isn't in Unicode, I believe, but I think is part of Alan
> LaBonte's keyboard standards, and so might get in via that route.)
> This one is a key (rather than a lock) to show that a (physical) key
> is needed to use the terminal.
Noted. And I do remember seeing a padlock on an IBM 327x terminal screen,
don't I? It was a long time ago, maybe I dreamed it. Anyway, I can't find
any reference to it now.
> >  IBM System/360 Principles of Operation, GA22-6821-8, Poughkeepsie,
> > NY, 1970.
> I would ditch the reference to the S/360 POO - it's been pretty much
> obsolete since 1970 or so. Fine for a historic reference, but I think
>  (as updated) is the better ref.
This is my reference for Table 5.3A. Thanks for the other updated
> Thanks for doing all this work. I hope the views of the likes of
> Michael Everson ("Unicode will be in use for centuries" with the
> implication that all these silly terminal emulations are just
> dinosaurs) will not prevail.
Michael's views are mainstream. In any case, Michael is a passionate
advocate of some of my favorite scripts :-) I certainly would not want
to see (say) hex bytes squeezing out (say) Nordic or Irish runes.
Terminals (or emulators -- including xterms and the like), protocol
analyzers, escape sequences, termcaps, timesharing systems, mainframes, etc,
are approximately as widespread now as they ever were, but around them has
grown an entirely new world of Windows and GUIs and Web browsers, and this
is all we hear about in the mass market.
Younger people are not even aware of this older world, quietly doing its job
in its unglamorous "machine rooms", just as passengers on an ocean liner
could be unaware of what went on below decks. I have seen Columbia students
drop their jaws in amazement upon first seeing a terminal emulation screen
-- let alone an actual terminal -- "What's THAT???? It's so UGLY!". But
that world is there; we all depend on it, and it's not going anywhere.
(Really. Nothing ever quite disappears. I have heard of a payroll system
that was originally written in the early 1960s for an IBM ... OK, I forget
the exact model number -- 1104 or something like that. When that machine
was replaced by a 7094 (?), the same payroll system ran under an 1104
emulator. When the 7094 was replaced by a 360, it still ran on the 1104
emulator, which itself ran on a 7094 emulator. And so on and so on, legend
has it, to this day.)
P.S. This is coming to you from the original IBM Thomas J Watson Research
Laboratory, where IBM developed much of its 1940s and 50s technology before
turning the building over to Columbia University in 1955 and moving to
Yorktown Heights (no, I wasn't here then). "THIMK" :-)
P.P.S. A slightly updated draft (2.5), based on today's discussion, is in
the usual place (get out your clickers):
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT