TUHS

tuhs@tuhs.org

16 participants
6536 discussions

Were cron and at done at the same time? Or one before the other?

by M Douglas McIlroy

This pair of commands exemplifies a weakness in the way Unix evolved. Although it was the product of a shared vision, It was not a product-oriented project. Unix commands work well together, but they don't necessarily work alike. It would be nice if identifiable families of commands had similar user interfaces. However, cron and at were written by different individuals, apparently with somewhat different tastes. Unix folks were close colleagues, but had no organized design committee. Time specs in cron and at are markedly different. A more consequential example is data-field specs (or lack thereof) in sort, join, cut, comm and uniq. The various specs were recognized as "wildly incongruent" in a BUG remak. However there was no impetus for unification. To paraphrase John Cocke (speaking about Fortran): one must understand that Unix commands are not a logical language. They are a natural language--in the sense that they developed by organic evolution, not "intelligent design". Doug

4 years, 6 months

sh and goto

by srbourne

Message: 4 Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST) From:jason-tuhs@shalott.net To:tuhs@minnie.tuhs.org Subject: Re: [TUHS] The UNIX Command Language (1976) Message-ID: <alpine.LRH.2.23.453.2011301946410.14253(a)waffle.shalott.net> Content-Type: text/plain; charset="utf-8"; Format="flowed" > "The UNIX Command Language is the first-ever paper published on the Unix > shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl Thanks for that. This reminded me that the Thompson shell used goto for flow control, which I had forgotten. Bourne commented on the omission of goto from the Bourne shell, "I eliminated goto in favour of flow control primitives like if and for. This was also considered rather radical departure from the existing practice." Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell? Thanks. -Jason At the time it may have raised a few eyebrows but I don't recall much discussion about it then. My email tracks at the time don't mention it. Doug McIlroy or Steve Johnson (or Ken) on this forum might recall differently. At the time scripts were not that complicated and so error recovery to a far off place in the script was not common. As an aside I did persuade Dennis to add "setjmp" and "longjmp" so the shell code itself could recover from some kinds of script errors. So I did not have a "religious" aversion to "goto" at the time. Steve

4 years, 7 months

sh and goto

by M Douglas McIlroy

> Bourne commented on the omission of goto from the Bourne shell ... > Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell? I don't believe I ever used a shell goto, because I knew how it worked--maybe even spinning a tape drive, not too different from running a loop on the IBM CPC. There you stood in front of the program "read head" (a card reader), grabbed the "used" cards at the bottom and put them back in the top feed. Voila, a program loop. The shell goto differed in that it returned to the beginning by running the tape backward rather than going around a physically looped path. And you didn't have to spin the tape by hand. It also reminds me of George Stibitz's patent on the goto. The idea there was to stop reading this tape and read that one instead. The system library was a bank of tape readers with programs at the ready on tape loops . (This was in the late 1940s. I saw the machine but never used it. I did have hands-on experience with CPCcards.) Doug

4 years, 7 months

Knuth and Pascal (was "Were cron and at ...")

by M Douglas McIlroy

Off topic, but too much fun to pass up. >> You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). > Now why didn't Don Knuth think of that for TeX? I'm glad he didn't. He might have written it in Mix. Knuth once said he didn't believe in higher-level languages. Of course he knew more about them than anybody else and was CACM's associate editor for the subject--like a minister who doesn't believe in God. Doug

4 years, 7 months

Re: [TUHS] Were cron and at done at the same time? Or one before the other?

by jnc＠mercury.lcs.mit.edu

> From: "Theodore Y. Ts'o" > Having a clean architecture is useful in so far as it makes reduces > maintenance overhead and improves reliability. I would put it differently, hence my aphorism that: "the sign of great architecture is not how well it does the things it was designed to do, but how well it does things you never imagined it would be used for". I suppose you could say that reducing maintenance and improving reliability are examples of the natural consequences of that, but to me those are limited special cases of the more general statement. My sense is that systems decline over time because of what I call 'system cancer': as they are modified to do more and more (new) things, the changes are not usually very cleanly integrated, and eventually one winds up with a big pile. (Examples of this abound; I'm sure we can all think of several.) Noel

4 years, 7 months

Happy birthday, Ada Lovelace and JFO!

by Dave Horsfall

Sorta relevant to both groups... Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave

4 years, 7 months

Re: [TUHS] Were cron and at done at the same time? Or one before the other?

by jnc＠mercury.lcs.mit.edu

> From: Niklas Karlsson > Just consider Multics, or IBM's "Future System". Here's a nice irony for you: one of the key people in killing off FS was reported to me (by someone who should have known) to be Jerry Saltzer (of Multics fame). That wasn't the only time he did something like thst, either; when MIT leaned on him to take over Athena, the first thing he did was to take a lot of their ambitious system plans, and ditch them; they fell back to mostly 'off the shelf' stuff: pretty much vanilla 4.2, etc. Multics itself has an interesting story, quite different from the popular image among those who know little (or nothing) of it. The system, as it was when Honeywell pulled the plug on further generations of new hardware (in the mid-80's) was very different from the system as originally envisaged by MIT (in the mid-60's); it had undergone a massive amount 'experience-based evolution' during those 20 years. For instance, the original concept was to have a process per command (like Unix), but that was dropped early on (because Multics processes were too 'expensive'); they wound up going with doing commands with inter-segment procedure calls. (Which has the nice benefit that when a command faults, you can get dropped right into the debugger, with the failed instance there to look at.) If you read the Organick book on Multics, it describes a much different system: e.g. in Organick there's a 'linkage segment' (used for inter-segment pointers, in pure-code segments) per code segment, but in reality Multics, as distributed, used a single 'combined linkage segment' (which also contained the stack, also unlike the original design, where the stack was a separate segment). There were also numerous places where major sub-systems were re-implemeneted from scratch, with major changes (often great simplifications): one major re-do was the New Storage System, but that one had major new features (based on operationally-shown needs, like the 4.1/.2 Fast File System), so it's not a 'simplification' case. There's one I read about which was much simpler the second time it was implemented, I think it was IPC? Noel

4 years, 7 months

Re: [TUHS] Were cron and at done at the same time? Or one before the other?

by John Foust

At 09:40 AM 12/9/2020, Clem Cole wrote: >My own take on this is what I call "Cole's Law"Â Â Simple economics always beats sophisticated architecture. I thought that was finely sliced cabbage with a tart salad dressing. - John

4 years, 7 months

Were cron and at done at the same time? Or one before the other?

by ron minnich

When I got into Unix in 1976 cron and at were both there. I got to wondering for no particular reason which came first -- I had always assumed cron, but ...? Anyone know?

4 years, 7 months

The origin of Goto considered harmful?

by Bakul Shah

Last night I stumbled upon this speech by Doug McIlroy at Dijkstra's retirement banquet @ UT Austin where he tells the story of his first encounter with EWD and the origins of programming without goto.... Given that we recently had a discussion on "Goto considered harmful", you all may enjoy it. Make sure you watch the start of part 10 as well as that is where the story ends. https://youtu.be/5OUPBwrufKA?list=PL328C7EFFC1F41674&t=326

4 years, 7 months

Command name of the B compiler; One letter command names

by markus schnalke

Hoi, I'm wondering what the name of the B compiler was. Doug's ``Unix Reader'' lists: 1 2 3 4 5 6 7 8 9 + + + . . . . . . b compile b program . . . . . + + + + bc arbitrary-precision arithmetic language Via Wikipedia I found a scan of the ``Users' Reference to B'', a technical memorandum by Ken, dated 1972-01-07 (which is between the releases of the 1st and 2nd Edition). https://web.archive.org/web/20150317033259/https://www.bell-labs.com/usr/dm… There on page 25: 10.0 Usage Currently on UNIX, there is no B command. The B compiler phases must be executed piecemeal. The first phase turns a B source program into an intermediate language. /etc/bc source interm The next phase turns the intermediate language into assembler source, at which time the intermediate language can be removed. /etc/ba interm asource rm interm The next phase assembles the assembler source into the object tile a.out. After this the a.out file can be renamed and the assembler source file can be removed. as asource mv a.out object rm asource The last phase loads the various object files with the necessary libraries in the desired order. ld object /etc/brtl -lb /etc/bilib /etc/brt2 Now a.out contains the completely bound and loaded program and can be executed. a.out A canned sequence of shell commands exists invoked as follows: sh /usr/b/rc x It will compile, convert, assemble and load the file x.b into the executable file a.out. It lists /etc/bc, as a command to convert into the intermediate language, and /etc/ba, to convert the intermediate language into assembler source, but lists no `b' command. The wrapper script is /usr/b/rc. Can someone clarify? I came to this question because I was looking for one letter commands. I always thought them to be a reserved namespace for the user ... Any background on that topic is appreciated as well. ;-) meillo

4 years, 7 months

Re: [TUHS] The UNIX Command Language (1976)

by M Douglas McIlroy

There's a back story. The paper appears in the proceedings of a conference held in London in 1973, a few months after the advent of pipes. While preparing the presentation, Ken was inspired to invent and install the pipe operator. His talk wouldn't have been nearly as compelling had it been expressed in the original pipeline syntax (for which I take the blame). References to eqn (v5), bc (v6), and ratfor (v7) obviously postdate the London conference. Ken must have edited--or re-created--the transcript for the proceedings sometime after v6 (May, 1975). Bibliographic citations are missing. Can they be resurrected? Reference 137, about Unix itself, probably refers to a presentation by Ken and Dennis at SOSP in January1973. Alas, only an abstract of the talk appears in the conference proceedings. But the abstract does contain the potent and often-repeated sentence, "It offers a number of features seldom found even in larger operating systems, including ... inter-process IO ..." The talk--in Yorktown Heights--was memorable, and so was a ride to the same place in Ken's 'vette. (I can't recall whether the two happened on the same occasion.) Given that the talk at SOSP preceded the talk in London, and that the Unix manual was widely distributed by (1976) when the revised London talk was printed, the claim that "The Unix command language" was the first publication of Unix seems hyperbolic. In no way, though, does this detract from the inherent interest of the paper. Doug

4 years, 7 months

Apple IIe Unix?

by Will Senn

Hi All, So, I'm about to get my very own Apple IIe and while it's an incredibly versatile machine for assembly language and hardware hackery, I'm not aware of any Unices that run on the machine, natively. Does anybody know of any from back in the day? It's got a 65c02 processor and somewhere around 128k of RAM, but it's also pretty expandable w/7 slots and a huge amount of literature about how to do stuff w/those slots. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 7 months

Re: [TUHS] The UNIX Command Language (1976)

by norman＠oclsc.org

I'm also forwarding this message that arrived in my mailbox. Is this **THE** Ken Thompson? Yes, that's the real Ken. Those who have communicated with him in the past (and didn't get a direct note as some of us did) should notice the new e-mail address, kenbob(a)gmail.com. Norman Wilson Toronto ON

4 years, 7 months

Re: [TUHS] Apple IIe Unix?

by Jose R. Valverde

Somewhat late to the discussion, but GeckOS may be another curious contender. You can find more information in http://6502.org http://www.6502.org/users/andre/index.html j -- Scientific Computing Service Centro Nacional de Biotecnología, CSIC. c/Darwin, 3. 28049 Madrid +34 91 585 45 05 +34 659 978 577

4 years, 7 months

Re: [TUHS] The UNIX Command Language (1976)

by Joachim

I'm also forwarding this message that arrived in my mailbox. Is this **THE** Ken Thompson? Joachim -------- Forwarded Message -------- Subject: Re: [TUHS] The UNIX Command Language (1976) Date: Sun, 29 Nov 2020 21:47:16 -0800 From: Ken Thompson <kenbob(a)gmail.com> To: Joachim <j(a)tllds.com> yes. the unix manual was published before that, but i dont think it was released that early. it had a manual page on the shell. this paper might be the first paper ever released outside bell labs. On Sun, Nov 29, 2020 at 7:18 PM Joachim via TUHS <tuhs(a)minnie.tuhs.org <mailto:tuhs@minnie.tuhs.org>> wrote: Apologies if this has already been linked here. "The UNIX Command Languageis the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976." https://github.com/susam/tucl Joachim

4 years, 7 months

Re: [TUHS] Apple IIe Unix?

by jnc＠mercury.lcs.mit.edu

> From: Steve Nickolas > there's no easy way to do preemptive multitasking without extra > hardware. Perhaps you're using some idiosyncratic definition of "preemptive" and "multitasking", but to me that statement's not accurate. Let's take the "multitasking" part first: that just means 'two or more computations can run at the same time, sharing the machine' - and that's not hard to do, without special hardware, provided there's some way (in the organization of the software) to save the state of one when the other is running. Many simple systems do this; e.g. the MOS system that I used on LSI-11's, BITD. "Preemptive" is a bit trickier, because things have to be organized so that one 'task' can be temporarily stopped arbitrarily (i.e. without it explicitly giving up the processor, which is what e.g.MOS did) to let another run. There does need to be some asynchronous way of inciting the second 'task' to run, but interrupts (either clock, or device) do that, and pretty much every machine has those. MINI-UNIX, for example, has premptive multitasking. The thing that takes special hardware is _protecting_ one task from a bug in another - a bug which could trash the first tasks's (or the system's!) memory. One has to have memory management of some kind to do that. > From: Dave Horsfall > I would start with something like Mini-Unix MINI-UNIX would be a good place to start if one wanted to bring up a system on a machine without memory management; there's nothing in the kernel which is PDP-11 dependent that I can think of (unlike V6, which had a fairly heavy dependency on the PDP-11 memory management hardware - although one could of course rip that all out, as MINI-UNIX did). However, one's still looking at a fair amount of work, both to get rid of any traces of PDP-11isms (e.g. stack growth direction), and translate the assembler part (startup, and access to non-C operations). Something like FUZIX might be an easier option. Noel

4 years, 7 months

Why do compress(1) and pack(1) use the .Z / .z extension?

by Hans Wennborg

I'm trying to find out why compress(1) uses .Z as filename extension. My theory is that it was inspired by pack(1), which uses the .z extension. However, I haven't been able to find any info on why pack(1) uses that extension. Does anyone here know? Some searching led me to [1] which is a man page for pack from AUSAM. It's written by Steve Zucker in 1975, so perhaps the extension is z for Zucker? Was Zucker's pack(1) the first, though? This message [2] talks about a Bell version. Does anyone here have any information about this? Cheers, Hans 1. https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/doc/man/man1/pack.1 2. https://tech-insider.org/unix/research/1984/0319.html

4 years, 7 months

W. Richard Stevens wife's email?

by Larry McVoy

I was making coffee into the cup I've had for decades that talks about his networking books. I realized I might have something that would help his wife a bit. I had her email but long since lost it. Anyone have it? --lm

4 years, 7 months

Re: [TUHS] free dead trees, to the best possible home

by Rich Morin

Back in mid-January, I posted a note saying: > TL; DR. I'm trying to find the best possible home for some dead trees. ... A lot (far too much, IMNSHO!) has happened since then. In any case, I thought folks here might appreciate an update. In brief, Iain Maoileoin offered to pay for shipping a largely unknown amount of technical (mostly computer-related) books to his repurposed missile sile (!) near Inverness, Scotland. Early this Fall, I packed up 16 cardboard boxes (designated 0-F, of course :-) and the shippers hauled them off. Dunno when they'll arrive, let alone in what condition, but trying to save them from recycling seemed worth the effort. FYI, the total weight was a bit over a ton. Meanwhile, my spouse and I gave away and/or packed up the rest of our things and drove ourselves and five cats up to Seattle, WA, USA. Somewhere in a shipping container, there is still a cubic foot or so of historical Unix papers from Jim Joyce; when it surfaces, I'll post again about rehoming it. -r

4 years, 7 months

516-TSS documents

by Jon Steinhart

Well, it's a very rainy day and since COVID is keeping me home I just fed my 516-TSS notebooks into the scanner. It's about 17MB of stuff. Not sure what to do with it since I don't have a place to serve it and since they're scanned images they're too big to post. Here's the list of documents; email me if you're wanting something in a hurry while the archive stuff is figured out. Note that the smell of mildew wasn't preserved in the scanning process. 516-1-516-DOCUMENTATION.pdf 516-3-DDP-516-PRICE-LIST.pdf 516-4-Disk-Layout.pdf 516-5-System-Table-Formats.pdf 516-6-Segment-Format.pdf 516-8-Disk-Hole-Format.pdf 516-7-DMA-Mnemonics.pdf 516-9-Addresses.pdf 516-10-11-12-Ring-Formats.pdf 516-12-Specifications-For-The-Node-Modem-Interface.pdf 516-13-Trac-Character-Strings.pdf 516-14-GMAP-Assembler-for-the-Multi-Programmed-516.pdf 516-15-A-Suggested-Graphic-Display-with-Keyboard-for-Graphic-Terminals.pdf 516-16-516-Assembler-And-Post-Processor-For-Unsegmented-Programs.pdf 516-18-Format-For-Ring-Interrupt.pdf 516-19-Thread-Save-Blocks.pdf 516-20-Card-Reader-Bootstrap-and-Programs.pdf 516-21-Octal-Package.pdf 516-22-A-Repeater-For-The-Node-Modem.pdf 516-23-CLEAR-CORE-CARD.pdf 516-24-SOROBAN-CARD-READER-TEST-PROGRAM.pdf 516-25-IO-Table.pdf 516-26-Disk-DMA-Queue.pdf 516-27-GE-Disc-Files-For-516-Programming.pdf 516-27-Thread-Table.pdf 516-28-IO-Ring_Device-Codes.pdf 516-29-Five-Bit-Character-Codes.pdf 516-30-Text-Editor.pdf 516-31-Relocatable-Segment-Octal-Package.pdf 516-32-ASCII-Character-Mnemonics.pdf 516-34-Display-List-For-Glance.pdf 516-35-Internal-Megacycle-Clock.pdf 516-36-Node-Modem-Interface-For-Computer-Terminals.pdf 516-38-P8SYS.pdf 516-39-Resource-Monitor-Meters.pdf 516-40-SNAP-Time-Sharing-Calculator.pdf 516-41-516-Segment-Assembler.pdf 516-42-Memory-Service-Unit-Format.pdf 516-43-GEBKUP-and-FLOAD.pdf 516-44-FSNAP-Floating-Point-Time-Sharing-Calculator.pdf 516-45-516-316-Assembler-and-Binder.pdf 516-46-CALC-A-Desk-Calculator-Program.pdf 516-47-Remote-Data-Plotting.pdf 516-48-CODING-FOR-GLANCE-G-Graphics.pdf 516-49-516-Segment-Assembler.pdf 516-50-Use-Of-The-516-Segment-Assemblers-Macros-In-Application-Programs.pdf 516-51-FSNAP-Designers-Guide.pdf 516-51-FSNAP-Users-Guide.pdf 516-52-DESK-A-Desk-Calculator.pdf 516-53-FSEOF-Flag-End-Of-File.pdf 516-54-Context-Editing.pdf 516-55-One-Card-Core-Save-Program.pdf 516-56-PRIME-An-Integer-Factoring-Program.pdf 516-57-Format-For-The-516-Node-T-I-U-Spider-Interface.pdf 516-59-Calling-Procedures-For-Math-Routines.pdf 516-59-INITIALIZATION-OF-THE-516-TSS-SYSTEM.pdf 516-60-SORT-SUBR-FOR-SEGMENTED-PROGRAMS.pdf 516-61-516-TSS-SYSTEM-BOLTED-IN-CORE-SUBROUTINES.pdf 516-63-Display-Controller-Glance-G.pdf 516-65-SOME-DIGITAL-FILTER-APPLICATION-PROGRAMS.pdf 516-66-TSS-516-GE-Communication.pdf 516-67-Node-Format-For-PDP-11.pdf 516-68-DFILE-N-A-Program-for-TSS-516.pdf 516-69-GLANCE-G-COMMUNICATION-FORMAT-TSS-516-TO-SCOPE.pdf 516-70-Routines-to-Perform-Character-String-IO-in-a-FSNAP-Program.pdf 516-71-FSNAP-Debugging-Aids.pdf 516-72-Node-Test.pdf 516-73-Node-IO-Software.pdf 516-75-Display-Text-Editor-DTE.pdf 516-76-LOCAL-DATA-PLOTTING.pdf 516-77-GLANCE-PLOTTING-ROUTINES-GPLOT-GLANCE-CHRGEN.pdf 516-77-V2-GLANCE-PLOTTING-ROUTINES-GPLOT-GLANCE-CHRGEN.pdf 516-78-DUMP.pdf 516-79-New-File-Features-in-FSNAP.pdf 516-81-OPTION-CHANGING-IN-GPLOT.pdf 516-86-MODIFICATIONS-TO-201-DATAPHONE-SOFTWARE.pdf DDP-516-PROGRAMMERS-REFERENCE-CARD.pdf DDP-516-Instruction-Set-Summary.pdf Index.pdf README

4 years, 7 months

Re: [TUHS] Seeking wisdom from Unix Greybeards

by jnc＠mercury.lcs.mit.edu

> From: "Theodore Y. Ts'o" > was there anything that had similar functionality which pre-dated Bill > Joy and termcap in late 70's? Is your question purely in Unix, or more general? If the latter, there's the terminal-independent support of video terminals in ITS; that dates to the mid-1970's (i.e. circa V5 or so). User programs output device-independent display control codes (I have this memory that they were called P-Codes, but that could be my memory failing), and the OS translated them to the appropriate screen-control characters. One additional hack was that the number of terminal types supported in the OS was limited; there was however a protocol called SUPDUP which sent (basically) those device-independent codes over a remote login (originally over NCP) frm the server machine to the client. The User SUPDUP client supported a lot more terminal types; so people with odd-ball terminals used to log in, SUPDUP _back_ to their machine, and away they went. Noel

4 years, 7 months

Package Management

by Henry Bent

Hello All, I know I have asked this before, but I am curious about any new replies or insight. How did package management start? Were sites keeping track of packages installed in a flat file that you could grep (as god intended) somewhere, or were upgrades and additions simply done without significant announcement? At what point did someone decide, 'Hey, we need to have a central way to track additional software"? I know of DEC's setld and SGI's inst in the latter half of the '80s. What was the mechanism before that? -Henry

4 years, 7 months

Re: [TUHS] 516-TSS Documents

by jnc＠mercury.lcs.mit.edu

> On Mon, Nov 23, 2020 at 12:28 PM Erik E. Fair <fair-tuhs(a)netbsd.org> wrote: > The Honeywell DDP-516 was the computer (running specialized software > written by Bolt, Bernanek & Newman (BBN)) which was the initial model of > the ARPANET Interface Message Processors (IMP). The IMPs had a lot of custom interface hardware; sui generis serial interlocked host interfaces (so-called 1822), and also the high-speed modem interfaces. I think there was also a watchdog time, IIRC (this is all from memory, but the ARPANET papers from JCC cover it all). Noel

4 years, 7 months

516-TSS Documents

by Jon Steinhart

These are in Warren's hands now and he'll let us know where their permanent home ends up being. Since these are pretty much uncirculated unlike the UNIX documents I wrote a README to go along with them which Heinz reviewed so it's the best that two aging sets of memories can do. Here it is: - - - 516-TSS is a little-known but groundbreaking and influential operating system that was developed at Bell Telephone Laboratories. I came across this system because Carl Christensen and later Heinz Lycklama were major contributors to it, and they were also advisors for the Bell Labs Explorer Scout Post at Murray Hill. I was a member of that post which allowed us to play with computers on Monday evenings, and 516-TSS was what most of us used. Through a series of amazingly lucky events, I ended up working as a summer student for Carl and Heinz and got to contribute to the system. Long before the term "code spelunking" was coined Carl and Heinz taught us both code and spelunking. This is not a complete set of 516-TSS documents, it's a couple of notebooks that I found in a box in the basement. Probably my ancient work-at-home copy. I don't know enough history to know if it was the first, but 516-TSS was an early department-level time-sharing system. It was built around a Honeywell DDP-516. While other time-sharing systems predate 516-TSS, they weren't systems that one's department could afford. CTSS certainly came earlier, but it used a monster IBM 7090 mainframe. In round numbers, a 7090 cost $3,000,000 dollars, a DDP-516 cost $50,000. 516-TSS was also a virtual memory system; again not the first but a rarity in that era. My recollection is that it used the 516's index register as the base address register, and there was some complicated mucking around that a program had to do if it needed to use the index register including disabling interrupts and eventually restoring the register from .PRESB (present base address), one of those weird things stuck in my memory from long ago. I believe that the system's development predated UNIX although I remember our department getting a PDP-11/45 running UNIX Version 3 in the summer of 1973. This machine was acquired so that Doug Bayer and Heinz Lycklama could develop the MERT operating system. The 516 was a testbed for a lot of novel technologies. It had a local area network called the ring which was later made to work on PDP-11s including Ken and Dennis's machine up in the attic of building 2. It was also used to develop the GLANCE graphics terminals. My recollection is that one of the main drivers behind getting the ring to work on PDP-11s and UNIX was so that Ken could get a GLANCE-G terminal for playing chess. Sandy Fraser's Spider network was developed there. It supported a number of novel applications including Dick Hause's DTE graphics editor; way ahead of its time. I remember that one GLANCE terminal was fitted with an array of LEDs and photodiodes to make an early version of a touch screen. While it wasn't exactly work related, a number of the people in the department had purchased property up in Vermont for ski cabins. An important use of the 516-TSS system and GLANCE-G terminals was to figure out survey closures. The property surveys were ancient, of the "from the big rock to the left of the tree that's no longer there" sorts of things, so figuring out the actual property lines was an interesting problem. The 516 also had a wide area network which consisted of picking up the phone and calling the computer center. It had a monster GE-635 or maybe 645 left over from the Multics project. It may have been renamed to be a Honeywell 6070 with Honeywell's acquisition of GE's computer business. The computer center kept department costs down by hoarding all of the really expensive peripherals. For example, we didn't have a card punch; that was effectively done via remote job entry. We didn't have a graphics printer either, so when I was working on GPLOT I'd submit remote jobs to the computer center for printing. Matter of fact, I don't think that we even had a printer in our department; we sent stuff up to the computer center for printing. Although, in those days many terminals used paper. The 516 console was an ASR-33. There was also the ability to send jobs to the computer center and have it call back with results. This early approach to a WAN showed up as the tss command in UNIX. One of the missions of the department was the development of an all-digital telephone exchange which is why some of the documents describe programs that assist with digital filter design. Both Jim Kaiser and Hal Alles were in the department. One of the side-effects of all this was Hal figuring out how to use the filter hardware connected to a LSI-11/03 to make sound, followed by Dave Hagelbarger building a very interesting keyboard for it, culminating in a visit by Stevie Wonder trailed by a large number of screaming secretaries. No sexism intended, it was a different world back then. The LSI-11 was one of the motivations for Heinz to create the LSX operating system. My recollection is that on Dave's keyboard each key was an antenna, and that there was strip of ribbon cable underneath where each wire was driven by a different bit on a binary counter. This allowed the position of each key to be determined which I think was way ahead of its time. I don't think that any commercially available keyboards did this at the time, they were all just on/off. Dave also designed the GLANCE keyboard which spoiled me for life. I don't remember how he did it, but the keys had a really good feel where once they got pushed past a certain point they snapped down. I do recall that there was a small solenoid mounted on the circuit board so that the keys gave a satisfying click that you could feel in your fingers. Another of Dave's gizmos was the chess board that he made for Ken. My recollection is that there was a tuned circuit in the base of each chess piece and an antenna grid in the board so that the PDP-11 could read the position of each piece. Some of the success of the 516 system was that other departments used it. I spent some time working an a 516-based integrated circuit test system where the test equipment stations were on the ring. Seems really dumb now, it's hard to believe that there was a time in which a computer cost more than a wafer stepper. In addition to his work on 516-TSS, Carl Christensen was one of the people who interviewed Ken Thompson for a job at the labs and gave a thumbs up. The 516-TSS documents don't have author names, just initials. Here's who they are to the best of my recollection. ADH Dick Hause CC Carl Christensen DJB Doug Bayer DRW Dave Weller EPR ? HL Heinz Lycklama JCS John Schwartzwelder JES Jon Steinhart JFK Jim Kaiser JHC Joe Condon JVC John Camlet LIS ? MAS ? RFG Rudy Garcia There is one mysterious document in the collection about a "memory service unit". I had this filed under "zapper". To the best of my recollection it was the PROM programmer that we used to burn the microcode PROMs for the GLANCE terminals. Jon Steinhart, 11/20/2020

4 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS