The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Phil Budne <phil@ultimate.com>
To: tuhs@tuhs.org
Subject: [TUHS] Re: "9 skills our grandkids won't have" - Is this a TUHS topic?
Date: Fri, 01 Jul 2022 15:22:24 -0400	[thread overview]
Message-ID: <202207011922.261JMOwq092697@ultimate.com> (raw)
In-Reply-To: <CAC20D2NXoD4gL5YVub=TH7sx8TYf4NsieXf4p_cF=PePQp52ZQ@mail.gmail.com>

Early use of ASCII control characters was ALL over the map.

I remember typing in a BASIC program to approximate PI during a
college tour in the late 70's, and whatever system they had (maybe
Univac?? there was an unplugged RCA Spectra in the hallway) required
typing Control C (ASCII ETX) instead of RETurn on the teletype.
*THAT* was a mind-f*ck!

Clem Cole wrote:
> Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS
> used ^Z as an EOF character in their text file format.  The key is that
> they stored a block count, not a byte count in the META.   Thus the last
> byte needs a marker to tell the OS to stop reading. [Early DEC OS's may
> have done that also, but I never looked at their FS formats].

I TEND to think of the DEC ASCII traditions as coming out of the PDP-6
Monitor (later TOPS-10), which probably dates to c. 1964, and modern
Unix/Linux systems are almost fully infected with DEC conventions
(DELETE, CTRL/U, CTRL/C vs @/#/DELETE for example), except for ^M and ^Z.

The earliest version I have on hand is version 3.19, which includes
PDP-10 (KA10) support (c.1968).  The scheduler (CLKCSS) has Tom
Hastings name on it, dated 6 SEP 67.  Tom wrote the MIT CTSS
(timesharing on IBM 709/7090) scheduler, and the DEC T/S system
mirrors CTSS in many ways (project/programmer numbers).  CTSS used
ASCII, and it would be interesting to know what conventions were used
there!!  On topic: Ken might know. @/# seem to have been used on
Multics.

The full duplex terminal code (SCNSRF) with Robert Clemmens name
on it, dated "27 NOV 68" has the following conventions:

Use of "^Q" as a convention for control characters.
CR	^M	return to column zero (used alone in files for overstrike)
LF	^J	line feed: line terminator
HT	^I	horizontal tab
VT	^K	vertical tab (n line feeds on a TTY)
FF	^L	form feed
XON	^Q	start TTY paper tape reader
XOFF	^S	sent by TTY PTR on end of tape?
	^U	clear input line
	^Z	EOF
0177	DEL	delete a character
033,0175,0176 "ALTMODE" -- used in DDT (& TECO), echoes as "$"

I don't have a set of Commonly Used System Programs (CUSPs) from that
era, so I can't see how they handle ^Z if they see it in a file.
I don't remember seeing ^Z in disk files on TOPS-10.

A quick look at the 3.19 code (I rescued it from six DECtapes while at
DEC; three each for full & half duplex versions of the code!)  and
didn't spot the on disk/DECtape metadata formats, but I suspect they
were just block counts.  There ARE files I've pulled off of tape with
embedded NULs, so I suspect code was written to ignore NULs whereever
they appeared.  "Dump Mode" I/O, where you passed IOWDs -COUNT and
WORD_POINTER in halfwords, rather than transferring character at a
time into a buffer, was a way to speed up disk I/O, which would easily
result in multiple embedded NULs.  My recall is that we thought of
disk files as made up of blocks, and not characters.

MIT AI's Incompatible Timesharing System (ITS), a dig at CTSS (and DEC
as well?) used ^C instead of ^Z for EOF, appearing (in triplicate?)
inside of (older) files. And ^Z stop a (sub)job and drop into DDT (the
debugger *AND* command interpreter), which could be examined,
continued, or killed (ALT CTRL/X).  I've always assumed BSD used ^Z as
the suspend character for this reason.

	TOPS-20 (and perhaps later day TOPS-10) had file metadata
	indicating file byte counts, and byte sizes (1-36 bits), but
	TOPS-20 ALSO only allocated file storage on a page basis (512
	36-bit words instead of the TOPS-10 256W block size).

The PDP-7 unix inode stores a word count, rather than a byte count,
and ISTR programs ignore NULs for the same reason.

> Unix, of course, never made any distinction to the core OS WRT to 'type'
> [other than Regular/Directory/Special]  and Ken stored a character count.
> So there was no need to signal EOF with a markered stored on disk..
>
> A pipe or the shell on the other hand does have a need to signal the end of
> a transaction, and 'End of Transmission,' as Nelson points out, is the
> ASCII character reserved for the same.

I don't know the rationale for DEC's use of ^Z for EOF, but as I
pointed out above, use of ASCII control characters wasn't widely
standardized in the 70's (is it today?)

To pull the thread back to the list topic

1. Remember which of @ and # deletes a single character.
2. Fix a filesystem without fsck.
3a. Buy a controller card to be able to use a disk
3b. Write a driver for a third party controller.
4. Edit a driver and recompile the kernel to change partition sizes.
5. Use dd to convert a mainframe tape to variable line length ASCII.
6. Wonder whether something with a serial port is a DTE or a DCE.
7. Figure out the serial port settings for a terminal/modem:
	data bits, parity, stop bits.
8. Adjust jumpers on a peripheral
9. Insert or remove wires for IRQ bus continuity

Non-UNIX related:
Punch job control cards.....
Burst fanfold paper by flicking their finger, to get your printout.
Spread out fanfold paper on the floor to get a "big view"
.......

  reply	other threads:[~2022-07-01 19:23 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 13:31 Nelson H. F. Beebe
2022-07-01 14:02 ` Steve Nickolas
2022-07-01 15:01   ` Clem Cole
2022-07-01 19:22     ` Phil Budne [this message]
2022-07-01 19:53       ` Clem Cole
2022-07-02 19:36     ` Leah Neukirchen
2022-07-02 19:50       ` Clem Cole
2022-07-03  0:22       ` John P. Linderman
2022-07-01 15:50   ` Lars Brinkhoff
2022-07-01 16:20     ` Warner Losh
2022-07-01 18:18       ` Clem Cole
2022-07-01 18:09     ` Clem Cole
2022-07-01 18:45     ` Steve Nickolas
  -- strict thread matches above, loose matches on Subject: below --
2022-06-30 13:14 [TUHS] " steve jenkin
2022-06-30 13:39 ` [TUHS] " Marc Donner
2022-06-30 13:54   ` Tom Teixeira
2022-06-30 14:08   ` Marshall Conover
2022-06-30 14:15     ` Larry McVoy
2022-06-30 14:32     ` Will Senn
2022-06-30 14:42     ` Pierre DAVID
2022-06-30 15:44       ` Larry McVoy
2022-06-30 15:23   ` Clem Cole
2022-06-30 15:35     ` Clem Cole
2022-06-30 14:23 ` Michael Kjörling
2022-06-30 15:12 ` Al Kossow
2022-06-30 15:55 ` Adam Thornton
2022-06-30 16:37 ` Paul Winalski
2022-07-01 13:05   ` Ori Idan
     [not found]     ` <Yr7zs59NtbXcRCu4@mbsks.franken.de>
2022-07-01 13:17       ` Matthias Bruestle
2022-07-01 13:36         ` Angus Robinson
2022-07-01 13:58           ` Marc Donner
2022-07-01 14:05             ` Henry Bent
2022-07-01 14:37               ` Marc Donner
2022-07-01 14:41           ` Blake McBride
2022-09-16 17:04         ` Michael Parson
2022-07-02 23:01     ` Mark Sutton
2022-07-03  0:08       ` John Cowan
2022-06-30 19:24 ` Michael Huff
2022-06-30 19:56   ` Jon Steinhart
2022-06-30 20:43   ` Robert Stanford via TUHS
2022-06-30 20:49     ` Chris Pinnock via TUHS
2022-06-30 21:11       ` ron minnich
2022-06-30 21:21       ` Larry McVoy
2022-06-30 21:24         ` Marc Donner
2022-06-30 21:41           ` James Johnston
2022-06-30 21:54             ` Larry McVoy
2022-06-30 22:05               ` Dr Iain Maoileoin
2022-06-30 22:18                 ` Rik Schneider
2022-06-30 22:51                   ` Marc Donner
2022-07-01 10:48                   ` Tom Ivar Helbekkmo via TUHS
2022-06-30 21:24         ` Chris Pinnock via TUHS
2022-07-01  0:41 ` Tomasz Rola
2022-07-01  0:46   ` Larry McVoy
2022-07-01  1:13     ` Larry Stewart
2022-07-01 18:12   ` Harald Arnesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202207011922.261JMOwq092697@ultimate.com \
    --to=phil@ultimate.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).