[ih] Impact of history on today's technology [was: why did CC happen at all?]

[John Klensin]

Wow.  Time to adjust a few small misconceptions since subsequent
postings seem to have not caught them...

On Thu, Sep 4, 2014 at 11:23 PM, John Day <jeanjour at comcast.net> wrote:
> All Multics terminals were half duplex IBM Selectrix

As others have noted, you are probably referring to the IBM 2741 and
maybe the earlier 1050, which I think we also used on Multics.  But
"all Multics terminals" is a bit of a stretch: In my shop alone, we
had, over time, an assortment of TTY 37s, VT100s and their
descendants, assorted "glass TTYs", some Imlac PDS-1Ds (primarily
programmed to imitate an ARDS but sometimes other things), a DEC GT40,
some TI "Silent 700s", some sort of Xerox device with a daisywheel ,
and probably some others that I've forgotten.   IIR, all of those were
ASCII devices, many of them conforming to the post-VT100 ANSI control
sequence standard.

Some of those devices were "full duplex", some "half" and line at a
time, some half but still character at a time.   IIR, someone even had
IBM TN5250-class devices hooks up to it.

The 2741 natively took input in shift and rotate codes (for the
typeball).  I don't recall it knowing anything about EBCDIC internally
but may not have known or have forgotten.   Incidentally, coming back
to lessons from history, the 2741 had no way to know which typeball
was installed, much less how to tell a remote print driver about it,
and, since some of them had character repertoires that were very
different from undecorated Latin characters (think APL and national
language forms among many others), a lot of us got our first
significant lessons in the importance of labeling character codings,
lessons that are still being discussed today (in spite of Unicode).

> and it was programmed in PL/1 that used EBCDIC.

First, since I'm a little sensitive on the subject, while the Multics
command that invoked the compiler was "pl1" (note case-sensitivity,
another important historical issue), the name of that programming
language was PL/I (capital P, capital L, slash, Roman numeral
(capital) one), not pl/i, pli, pl/1, or anything else.  Second and
more important to this discussion, the Multics PL/I compiler never
"used EBCDIC" nor did the ANSI and ISO standards for PL/I that were
influenced by it and to which the later generations of that compiler
confirmed.  The basic language character set specified in the
standards is ASCII compatible but the standards go to some length to
stress that the character set used in the standards are an abstraction
and that no mapping to specific graphics or coding is specified (see,
e.g., ISO/IEC 6522:1992 Sections 1.5.1.5 and 2.6 for details).

One of Multics's very important features in this area --one of many we
seem to have forgotten as we make "progress"-- was the use of a single
canonical form internally coupled with very powerful and selective
device drivers adapted to particular i/o devices and their
idiosyncrasies, rather than an implicit assumption that all terminal
devices were basically the same modulo what could be specified in a
table with lots of options.  That canonical form was enforced (or
converted to) almost everywhere and included canonical string ordering
and ways to handle overlaid characters and strings.

> But I will defer to Pogran on this one.

He will certainly know more about the terminal device drivers than I do.

>   ASCII was 7- bits.   In fact, there was a "crisis" one morning when BBN
> deployed new ASCII/EBCDIC tables in the TIPs and the guys logging into
> Multics from a TIP couldn't generate the line delete or character delete
> characters.

I vaguely remember that, but the problem wasn't that Multics was using
EBCDIC because it wasn't.  In any event, the "normal" Multics
character and line delete characters were, respectively, "#" and "@".
They caused other problems, but, fwiw, both are in the EBCIDIC
repertoire.

I remember three other issues that I believe were more significant:

-- When TENEX (and several other systems) represented ASCII on 36-bit
word hardware, they did so with five 7bit characters per word (and one
bit left over).   Multics used four ASCII characters in a 36 bit word,
with each one occupying 9 bits with the leading two set to zero.   If
one did a binary transfer (e.g., with FTP) of a file containing ASCII
strings, one could get fully as much of a problem as with binary
transfer of EBCDIC.  It was not an accident that FTP ended up with a
"TYPE" command that could differentiate between network-standard
("NVT") ASCII, EBCDIC, and image (binary) forms for transfer with the
sending system responsible for getting things into the right form.

-- The "new line" problem that continues to plague us had it origins
at that time with Multics (conforming to the original version of
ASCII, btw) using LF only internally, a number of DEC systems using CR
only, and so on.

-- IBM's original System/360 spec specified ASCII as an alternative to
EBCDIC, but their coding of ASCII put the seven bit code into an eight
bit byte, not with a leading zero but with a parity bit in the middle.
I don't have firsthand experience with an installation that turned
that coding on, but imagine it would have made other things worse.



>
> At 11:16 PM -0400 9/4/14, Michael Greenwald wrote:
>>
>> On 2014-09-04 22:31, John Day wrote:
>>>
>>> In all areas, the IBM influence was minimal if any.  In the ARPANET,
>>> EBCDIC was tolerated because of Multics

EBCDIC "was tolerated" because there were a number of important IBM
mainframes that used it, IIR UCLA included.  As discussed in more
detail above, it had nothing to do with Multics.

>...
>> Multics had (library?) routines to write and
>> read  EBCDIC if needed

Fancy device drivers.  One certainly could have figured out how to
process and use EBCDIC internally on Multics if necessary but, in
general, the character codings used by external devices were invisible
to a Multics applicaiton.

>>> IBM's primary strategy was not so much to contribute to the standards
>>> but ensure that they moved as slowly as possible.

Probably not good as a blanket statement either.  With PL/I, IBM's
representatives actually came to the standards committees and said
things equivalent to "our language design got the following features
wrong, please fix".

    best,
     john