From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17591 invoked from network); 17 Dec 2022 19:27:38 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 17 Dec 2022 19:27:38 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id F007A41C80; Sun, 18 Dec 2022 05:27:31 +1000 (AEST) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by minnie.tuhs.org (Postfix) with ESMTPS id 86EA341C7C for ; Sun, 18 Dec 2022 05:27:26 +1000 (AEST) Received: by mail-pf1-f179.google.com with SMTP id c7so3790709pfc.12 for ; Sat, 17 Dec 2022 11:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IWxs3fOZ5xuWXXxoAQLOS2ygW7a4eLGBY9VXS0wh1fQ=; b=l0gcZUX8XyA4b++8sgV4FSPyStqc8Bcmj6rZIfn8v0pf7zClLAlEhGAvw4bx8HfvRa GiA7gRd87/rBkgjrDbz+UhyerD2rqMkQuV9ccoXSVdfyDXPJVmIdJzqTcmZdsrjTimfC 7zKkDkLz4nAAyEZgvtllJa12APKJdaGTvqdHydau6EgUonKzPUxyEyMdS7Nz6RRfUdf8 GV78zSU9iSSrcuF4lu3VK3fkKZQr38znTiOCgduUkh2Nbf1cjADKz4JxRLRNFqHRwsr2 sg3LyPZy/NEcCLDJYLP85JfrllmFV0vR6sfEZOzCRRw9e0aVBEmPX6uk55nEJDcKma01 dH0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IWxs3fOZ5xuWXXxoAQLOS2ygW7a4eLGBY9VXS0wh1fQ=; b=RFLQzS2wRm5vMQsM0WMoANRe9Wq4+zzLRMPI1TdPw5eIOLqPcoJokVY/I7v3DvGQeN hwCBzidKu5fZXfERMj5hu0Y2sKNbTWj594HamXa6S9tkmMFXLYu3bX5xPg9G6eI4RwGJ TNjKsjOrCwoHobKmyByq3TlGGRZFm2YyqSeZB1ROWdLNag1kvlSAZdUAnsU7r72xGv32 CPvADQPgDBl7my00p66oSvLOZsQGhQqwJZWnsV5rZefKLmtLt2FtVkd3bfmVI7z3GHwW GHcBHjlWXTXA1KlkvtKXHzYNx3rZ4vvmujUu9WfiBmlSi+4g9s8RN88oOhOuMiCdSkpX t0nw== X-Gm-Message-State: ANoB5pnzuysnavJax/7x4wd6uWCivCUBQebT+YFQ2DIXhtCcu5vvkbR2 H9nuiGjYV4N3nwzBB6xC07PEWnw7Zv6oyGFFn2k= X-Google-Smtp-Source: AMrXdXuqsQfCuSrAJimoQXmFD46q1SPSMPYYJBjG8KYOggOHkpknpUbKaL+n2TimvRttyB/bDXrAL9FDl9YyNl+KSnE= X-Received: by 2002:a63:dc12:0:b0:480:595b:276c with SMTP id s18-20020a63dc12000000b00480595b276cmr755526pgg.265.1671305185407; Sat, 17 Dec 2022 11:26:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Perrine Date: Sat, 17 Dec 2022 11:26:14 -0800 Message-ID: To: Tom Lyon Content-Type: multipart/alternative; boundary="000000000000e3382b05f00b0f00" Message-ID-Hash: HLT6V7YDD657PEMV7GCFOSPYEEQEY4GI X-Message-ID-Hash: HLT6V7YDD657PEMV7GCFOSPYEEQEY4GI X-MailFrom: tom.perrine@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Douglas McIlroy , TUHS main list X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: origin of null-terminated strings List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e3382b05f00b0f00 Content-Type: text/plain; charset="UTF-8" I can offer at least one perspective on Multics, although from a limited viewpoint. I was an Explorer Scout at post 414, sponsored by Honeywell, in Phoenix, from about 1972 onwards. This was a "high tech" special interest Post, and our interest was computers - no surprise. Weekly meetings included time using Teletypes (and later nicer terminals) to connect to a GCOS system in Phoenix. Programming in Basic, FORTRAN, COBOL and other arcane languages ensued. As did "an incident". Pretty minor, but yeah, some high school kids "popped" (for some value of "popped") the local GCOS system and got access to some files they shouldn't have. I'm not sure if this was dumpster diving, or a real bug, or just exploiting some employee carelessly setting file permissions to "read and write for the entire system". I strongly suspect the latter. As a result, all our GCOS accounts were cancelled and we were moved to System M, one of the primary development systems for Multics. As was new and not all common at the time, the entire source code for the entire system was available online - and not just because this was a dev system, this was the norm for all Multics owners. In this way, Multics followed the UNIX model, or maybe they came from a common theme. The Post took to PL/1 in a big way and delivered some interesting changes to (mostly) the games on the system - vbg (Video BackGammon), chess, yet another space wars clone, and a huge expanded ADVENTURE. There was also some interesting new programming, including finding a way to exploit IPC channels, and another way to crash the front end processor, that led to some emergency bugfixes being rolled out (I later learned) overnight to the Pentagon and "the Fort" customers. Speaking of which, there was a bit of a kerfluffle when someone who shall remain nameless, innocently asked "I identified all the Multics systems in the site documents, except System N. Where is System N?" in a public forum on System M. I was warned Never To Speak of System "N" Ever Again Or Else. Over the next 10 years, a lot of my technical life was around Multic. As a Boy Scout, and eventually as a student intern at Honeywell. Throughout college all my engineering programming was done on Multics, mostly in pl1, instead of fortran. As an intern I worked on projects across the GCOS (GCOS-8), Multics and even a little CP-6 spaces. I got to see and hear how different parts of the company saw the GCOS vs Multics conflict, admittedly filtered through the eyes of a still naive intern. Here are some recollections and talking points. 1. Multics hardware is too expensive! 1. GCOS 8 HW, which would have run Multics, GCOS classic and the someday GCOS 8 was even more expensive) 2. Multics HW was expensive because they built and burned-in an entire GCOS system, and then partially took it apart, re-wired the CPU boards and other parts, and then put it back together!A Multics CPU had some boards in common with a GCOS CPU, some were modified boards, and some were completely separate, if I recall correctly. Wirewrap CPU boards in addition to the wirewrapped backplane, which was also (I think) a built-and-then-rewired GCOS backplane. 2. Our customers want more batch and less timesharing! - Multics doesn't have a real batch mode! 1. which could have easily been addressed with a "dusty deck translator" from GCOS JCL to Multics "absentee" scripts. 3. Timesharing is a fad and too expensive - look at how few people our GCOS customers put on TSS! 1. yeah, because GCOS TSS was an afterthought - a big pasted-on batch job that remained primitive compared to Multics and other competitors - looking at you TOPS-20, which was also up and coming 4. Our profit margins on GCOS SW and HW are better - so we should sell more GCOS! 5. Spending money on Multics will take away resources from our bread and butter GCOS, which is where we make money! 6. No one cares about PL/1 - all our customers want COBOL and FORTRAN 1. which Multics had, and a better COBOL compiler than GCOS - I learned COBOL68 and COBOL74 on both - and along the way found a bug that would crash THE ENTIRE GCOS OPERATING SYSTEM (not just the compiler!) if you mis-spelled "ENVIRONMENT DIVISION" in a COBOL74 program. 7. GCOS (formerly GECOS, thankyouverymuch) is the real legacy of GE, not that research project from MIT!!! - Multics is a toy we were paid to make, that will never make a dime! 8. There was some rivalry between Phoenix and Billerica(?) that was mostly kept away from "the kids", so we didn't see that in detail but it was there. 9. This rivalry seemed to be (in retrospect) two orgs fighting over ever-scarcer resources as the mini/super-mini revolution came on strong. A Multics CPU was pretty much a synchronous 1 MIP machine (per CPU). Of course you could have up to 8(?) CPUs and the I/O bandwidth was light years ahead of the super-minis, but DEC said that the VaX-11/780 was a "1 MIP machine" and it was cheaper than a mainframe, so there!! Anything else would probably be off topic for TUHS, but with the inter-twined DNA of Multics and UNIX, perhaps this is actually on-topic? I would point out that I don't think Multics was a victim of UNIX adoption, as that (from my dim recollection) took place years after Multics dev had been mostly capped. After Multics, my first UNIX system was PWB on a PDP-11. It was quite the change, but led to the rest of my career - BSD, KSOS, SysV, IRIX, Ultrix, SunOS, Solaris, UNICOS, others and eventually Linux. You never forget your first :-) Regards, --tep On Sat, Dec 17, 2022 at 10:17 AM Tom Lyon wrote: > Clem doesn't mention CP-67/CMS, which IBM kept trying to kill in favor of > CMS. > From Melinda Varian's amazing history of VM, I gleaned these factoids: > CP-67 - 8 sites by May '68 > Feb of 68 - IBM decommits from TSS > Apr 69 - IBM rescinds decommit of TSS > CP-67 - 44 sites by 1970, ~10 internal to IBM > May 71 - TSS finally decommitted > > So TSS was a rocky road, while CP&VM were simple and just worked. > > > > On Sat, Dec 17, 2022 at 9:13 AM Clem Cole wrote: > >> Given the number of ex-MTS (Bill Joy and Ted Kowalski, to name two) and >> TSS hackers that were also later to be UNIX hackers after their original >> introduction to system programming as undergrads. I will keep this reply >> in TUHS, although it could be argued that it belongs in COFF. >> >> Note good sources for even more of the background of the history politics >> at both IBM & GE can be found in Haigh and Ceruzzi's book: "A New >> History of Modern Computing >> " - >> which I have previously mentioned as it is a beautiful read. >> >> On Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy < >> douglas.mcilroy@dartmouth.edu> wrote: >> >>> IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, >>> but by then the die had been cast. Michigan bought one and built a >>> nice time-sharing system that was running well before Multics. >>> >> All true, but a few details are glossed over, and thus, this could be >> misinterpreted - so I'm going to add those as one of the people. >> >> TSS and the /67 was IBM's answer to Multics, as Doug mentions. Note that >> the /67 could run as a model /65, which as I understand it, most of the >> ones IBM sold did. >> >> At the time, IBM offered the /67 to Universities at a >> substantial discount (I believe even less than the /65). Thus, several >> schools bought them with Michigan, CMU, Cornell, and Princeton that I am >> aware of; but I suspect there were others. >> >> TSS was late, and the first releases could have been more stable. >> Cornell and Princeton chose to run their systems as /65 using the original >> IBM OS. CMU and Michigan both received copies of TSS with their systems. >> Michigan would do a substantial rewrite, which was different enough that >> became the new system MTS. CMU did a great deal of bug fixing, which went >> back to IBM, and they chose to run TSS. [I believe that CMU runs OS/360 by >> data and TSS at night until they felt they could trust it to not crash]. >> Nominally, TSS and MTS should share programs, and with some work, both >> could import source programs from OS/360 [My first paid programming job was >> helping to rewrite York/APL from OS/360 to run on TSS]. So the compilers >> and many tools for all three were common. >> >> MTS and TSS used the same file system structure, or it was close enough >> that tools were shared. I don't know if OS/360 could read TSS disk packs - >> I would have suspected, although the common media of the day was 1/2" mag >> tape. >> >> This leads to a UNIX legacy that ... Ted's fsck(8) - which purists know >> as a different name in the first version - was modeled after the disk >> scavenger program from TSS and MTS. icheck/ncheck et al. seem pretty >> primitive if you had used to see the other as a system programmer first. >> Also, a big reason why all the errors were originally in uppercase was the >> IBM program had done it. In many ways, neither Ted nor I knew any better >> at the time. >> >> Clem >> >> >> >> --000000000000e3382b05f00b0f00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can offer at least one perspective on Multics, although = from a limited=C2=A0viewpoint.

I was an Explorer Scout a= t post 414, sponsored by Honeywell, in Phoenix, from about 1972 onwards. Th= is was a "high tech" special interest Post, and our interest was = computers - no surprise.

Weekly meetings included = time using Teletypes (and later nicer terminals) to connect to a GCOS syste= m in Phoenix. Programming in Basic, FORTRAN, COBOL and other arcane languag= es ensued. As did "an incident". Pretty minor, but yeah, some hig= h school=C2=A0kids "popped" (for some value of "popped"= ) the local GCOS system and got access to some files they shouldn't hav= e. I'm not sure if this was dumpster diving, or a real bug, or just exp= loiting some employee carelessly setting file permissions to "read and= write for the entire system". I strongly suspect the latter.

As a result, all our GCOS accounts were cancelled and we w= ere moved to System M, one of the primary development systems for Multics. = As was new and not all common at the time, the entire source code for the e= ntire system was available online - and not just because this was a dev sys= tem, this was the norm for all Multics owners. In this way, Multics followe= d the UNIX model, or maybe they came from a common theme.

The Post took to PL/1 in a big way and delivered some interesting c= hanges to (mostly) the games on the system - vbg (Video BackGammon), chess,= yet another space wars clone, and a huge expanded ADVENTURE. There was als= o some interesting new programming, including finding a way to exploit IPC = channels, and another way to crash the front end processor, that led to som= e emergency bugfixes being rolled out (I later learned) overnight to the Pe= ntagon and "the Fort" customers.

Speakin= g of which, there was a bit of a kerfluffle when someone who shall remain n= ameless, innocently asked "I identified all the Multics systems in the= site documents, except System N. Where is System N?" in a public foru= m on System M. I was warned Never To Speak of System "N" Ever Aga= in Or Else.

Over the next 10 years, a lot of my te= chnical life was around Multic. As a Boy Scout, and eventually as a student= intern at Honeywell. Throughout college all my engineering programming was= done on Multics, mostly in pl1, instead of fortran. As an intern I worked = on projects across the GCOS (GCOS-8), Multics and even a little CP-6 spaces= . I got to see and hear how different parts of the company saw the GCOS vs = Multics conflict, admittedly filtered through the eyes of a still naive int= ern. Here are some recollections and talking points.

  1. Multics hardware is too expensive!
    1. GCOS 8 HW, which = would have run Multics, GCOS classic and the someday GCOS 8 was even more e= xpensive)
    2. Multics HW was expensive because they built and burned-in= an entire GCOS system, and then partially took it apart, re-wired the CPU = boards and other parts, and then put it back=C2=A0together!A Multics CPU ha= d some boards in common with a GCOS CPU, some were modified boards, and som= e were completely separate, if I recall correctly. Wirewrap=C2=A0CPU boards= in addition to the wirewrapped=C2=A0backplane, which was also (I think) a = built-and-then-rewired GCOS backplane.
  2. Our customers want more= batch and less timesharing! - Multics doesn't have a real batch mode!<= /li>
    1. which could have easily been addressed with a "dusty deck = translator" from GCOS JCL to Multics "absentee" scripts.
  3. Timesharing is a fad and too expensive - look at how few people = =C2=A0our GCOS customers put on TSS!
    1. yeah, because GCOS TSS was= an afterthought - a big pasted-on batch job that remained primitive compar= ed to Multics and other competitors - looking at you TOPS-20, which was als= o up and coming
  4. =C2=A0Our profit margins on GCOS SW and HW are= better - so we should sell more GCOS!
  5. Spending money on Multics wi= ll take away resources from our bread and butter GCOS, which is where we ma= ke money!
  6. No one cares about PL/1 - all our customers want COBOL an= d FORTRAN
    1. which Multics had, and a better COBOL compiler than G= COS - I learned COBOL68 and COBOL74 on both - and along the way found a bug= that would crash THE ENTIRE GCOS=C2=A0OPERATING SYSTEM (not just the compi= ler!) if you mis-spelled "ENVIRONMENT DIVISION" in a COBOL74 prog= ram.
  7. GCOS (formerly GECOS, thankyouverymuch) is the real legac= y of GE, not that research project from MIT!!! - Multics is a toy we were p= aid to make, that will never make a dime!
  8. There was some rivalry be= tween Phoenix and Billerica(?) that was mostly kept away from "the kid= s", so we didn't see that in detail but it was there.
  9. This= rivalry seemed to be (in retrospect) two orgs fighting over ever-scarcer r= esources as the mini/super-mini revolution came on strong. A Multics CPU wa= s pretty much a synchronous=C2=A01 MIP machine (per CPU). Of course you cou= ld have up to 8(?) CPUs and the I/O bandwidth was light years ahead of the = super-minis, but DEC said that the VaX-11/780 was a "1 MIP machine&quo= t; and it was cheaper than a mainframe, so there!!
Anything e= lse would probably be off topic for TUHS, but with the inter-twined DNA of = Multics and UNIX, perhaps this is actually on-topic?

I would point out that I don't think Multics was a victim of U= NIX adoption, as that (from my dim recollection) took place years after Mul= tics dev had been mostly capped.

After Multics, my= first UNIX system was PWB on a PDP-11. It was quite the change, but led to= the rest of my career - BSD, KSOS, SysV, IRIX, Ultrix, SunOS, Solaris, UNI= COS, others and eventually Linux.

You never forget= your first :-)

Regards,
--tep




On Sat, Dec 17, 2022 at= 10:17 AM Tom Lyon <pugs78@gmail.com> wrote:
Clem doesn't mention CP-67/CMS, whic= h IBM kept trying to kill in favor of CMS.
From Melinda Varian's am= azing history of VM, I gleaned these factoids:
CP-67 - 8 sites by= May '68
Feb of 68 - IBM decommits from TSS
Apr 69 = - IBM rescinds decommit of TSS
CP-67 - 44 sites by 1970, ~10 inte= rnal to IBM
May 71 - TSS finally decommitted

=
So TSS was a rocky road, while CP&VM=C2=A0were simple and just wor= ked.



On Sat, Dec 17, 2022 at 9:13 AM Cle= m Cole <clemc@ccc.com= > wrote:
=
Given the number of ex-MTS (Bill Joy a= nd Ted Kowalski, to name two) and TSS hackers that were also later to be UN= IX hackers after their original introduction to system programming as under= grads.=C2=A0 I will keep this reply in TUHS, although it could be argued th= at it belongs in COFF.

Note good sources for even more= of the background of the history politics at both IBM & GE can be foun= d in Haigh and Ceruzzi's book: "A New History of Modern Computing" - which I have prev= iously mentioned as it is a beautiful read.

On= Fri, Dec 16, 2022 at 5:27 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu= > wrote:
IBM revealed Gerrit Blaauw's skunk-works pro= ject, the 360/67,
but by then the die had been cast. Michigan bought one and built a
nice time-sharing system that was running well before Multics.
All true, but a few details are glossed=C2=A0over, and = thus, this could be misinterpreted - so I'm going to add those as one o= f the people.

TSS and the /6= 7 was IBM's answer to Multics, as Doug mentions.=C2=A0 Note that the /67 could run a= s a model /65, which as I understand it, most of the ones IB= M sold did.=C2=A0

At the time, IBM = offered the /67 to Universities at a substantial=C2=A0discount (I believe e= ven less than the /65).=C2=A0 Thus, several schools bought them with Michig= an, CMU, Cornell, and Princeton that I am aware of; but I suspect there wer= e others.

TSS was late, and the first releases could h= ave been more stable.=C2=A0 =C2=A0Cornell and Princeton chose to run their= =C2=A0systems as /65 using the original IBM OS.=C2=A0 CMU and Michigan both= received copies of TSS with their systems.=C2=A0 =C2=A0Michigan would do a= substantial rewrite, which was different enough that became=C2=A0the new s= ystem MTS.=C2=A0 =C2=A0CMU did a great deal of bug fixing, which went back = to IBM, and they chose to run TSS.=C2=A0 [I believe that CMU runs=C2=A0OS/3= 60 by data and TSS at night until they felt they=C2=A0could trust it to not= crash].=C2=A0 Nominally, TSS and MTS should share programs, and with some = work, both could import source programs from OS/360 [My first paid programm= ing job was helping to rewrite York/APL from OS/360 to run on TSS].=C2=A0 S= o the compilers and many tools for all three were common.

MTS and TSS used the same file system structure, or it was close enou= gh that tools were shared.=C2=A0 I don't know if OS/360 could read TSS = disk packs - I would have suspected, although the common media of the day w= as 1/2" mag tape.

This leads to a UNIX legacy tha= t ...=C2=A0 Ted's fsck(8) - which purists know as a different name in t= he first version -=C2=A0 was modeled after the disk scavenger=C2=A0program = from TSS and MTS.=C2=A0 =C2=A0icheck/ncheck et al. seem pretty primitive if= you had used to see=C2=A0the other as a system programmer first.=C2=A0 =C2= =A0Also, a big reason why all the errors were originally in uppercase was t= he IBM program had done it.=C2=A0 In many ways, neither Ted nor I knew any = better at the time.

Clem


<= /span>

--000000000000e3382b05f00b0f00--