[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: CRLF (was: Re: A modest proposal)
From:       John C Klensin <john-ietf () jck ! com>
Date:       2013-01-24 0:08:38
Message-ID: 57B220AA9F11881BDF0A7F66 () JcK-HP8200 ! jck ! com
[Download RAW message or body]



--On Wednesday, January 23, 2013 18:05 -0500 John Day
<jeanjour@comcast.net> wrote:

> Then what am I mis-remembering? ;-)  Was it that Multics
> didn't use CRLF and only NL?  I remember this as quite a point
> of discussion when we were defining Telnet and FTP.
> 
>> On Wed, 23 Jan 2013, John Day wrote:
>> 
>>>  > 
>>>  > IIR, Multics from several years earlier.  I'd have to dig
>>>  > through old manuals to remember what CTSS did, but that
>>>  > system (and the IBM Model 1050 and 2741 devices often
>>>  > used as terminals with it) were somewhat pre-ASCII (and
>>>  > long before ECMA-48/ ANSI X3.64 and the VT100 and
>>>  > friends)  and, IIR, sent and received shift and rotate
>>>  > codes rather than what we would normally consider
>>>  > character codes today.  The character codes were just
>>>  > input to device drivers that dealt with device
>>>  > characteristics
>>> 
>>>  Multics was based on EBCDIC which had a New Line (NL)
>>>  character but no CR or LF.  The ARPANET went with the ASCII
>>>  standard.  But I never forgave the ANSI committee for
>>>  taking left arrow out of the character set (as a replacement
>>>  operator).

Interesting theory, but Multics was definitely not EBCDIC-based.
The various IBM mainframes, including most importantly the UCLA
one, presumably were but Multics used a GE 645 base with (7 bit)
ASCII right justified in a 9-bit byte, four characters per 36
bit word.  That contrasted with Tenex and later TOPS-20, which
also used ASCII but as five characters in the 36 bit word with
the sign bit ignored for character purposes.

>> EBCDIC has NL (new line), LF and CR characters (hex 0x15,
>> 0x25 and 0x0d respectively). EBCDIC was an 8 bit code easy to
>> translate in hardware logic from punch card codes to the 8
>> bit code. Earlier IBM systems used BCD (sometimes called
>> BCDIC) which was a 6 bit code which did not have CR or LF but
>> had a subset of the EBCDIC style mapping from punched cards
>> to computer code. IBM systems all implemented a record based
>> file organization rather than the character stream of UNIX.
>> So the BCD generation systems had a record mark charcter (and
>> word mark) in the pre-S/360 days with BCD and file system
>> level record tracking in S/360.

IIR, parts of this aren't quite right either because the
CP/67-CMS architecture (which evolved into VM/CMS) was partially
based on CTSS and didn't follow a number of "traditional" IBM
conventions.  The S/360 mainframes also supported ASCII, but in
an odd encoding in which the spare bit was in the middle of the
byte and used, again IIR, for parity rather than being always
zero.

>...
>> VDTs with long lines might have been inspired by line
>> printers or just the idea that long lines were better. No
>> experience there, but I'm pretty certain there were no 132
>> column punch cards in common use which would have influnced
>> comody VDT designers. 80 and I believe 96 in S/3 days.

That is correct.  80, 96 (with an oddly-shaped card), and the
Univac round-holed one (don't remember how many columns it ended
up with).  The bigger VDT issue was that they tended to use
character cell architectures and made a non-destructive
backspace and composed/overstruck characters (not just simulated
boldface) impossible.

    john


[prev in list] [next in list] [prev in thread] [next in thread]