From web at loomcom.com Sat Jul 1 01:28:07 2023 From: web at loomcom.com (Seth Morabito) Date: Fri, 30 Jun 2023 08:28:07 -0700 Subject: [TUHS] Jerq menuhit/mhit In-Reply-To: <88993DC3-99D0-4977-A410-2BCAED781245@humeweb.com> References: <88993DC3-99D0-4977-A410-2BCAED781245@humeweb.com> Message-ID: <121a673f-0282-4261-9e41-f324556c1832@app.fastmail.com> Speaking of the Jerq... Is there a definitive history anywhere of the progression from Jerq up through the AT&T 730MTG? When I wrote my DMD5620 emulator I tried to find a complete history, but wasn't able to. I just found various (possibly apocryphal) bits and pieces here and there about AT&T objecting to various names until "DMD" was settled on by marketing at some point, and forcing the use of a WE32K in the 5620 for make-corporate-happy reasons. -Seth -- Seth Morabito * Poulsbo, WA * https://loomcom.com/ From robpike at gmail.com Sat Jul 1 08:14:32 2023 From: robpike at gmail.com (Rob Pike) Date: Sat, 1 Jul 2023 08:14:32 +1000 Subject: [TUHS] Jerq menuhit/mhit In-Reply-To: <121a673f-0282-4261-9e41-f324556c1832@app.fastmail.com> References: <88993DC3-99D0-4977-A410-2BCAED781245@humeweb.com> <121a673f-0282-4261-9e41-f324556c1832@app.fastmail.com> Message-ID: The original name was Jerq, which was first the name given by friends at Lucasfilm to the Three Rivers PERQ workstations they had, for which the Pascal-written software and operating system were unsatisfactory. Bart Locanthi and I (with Greg Chesson and Dave Ditzel?) visited Lucasfilm in 1981 and we saw all the potential there with none of the realization. My personal aha was that, as on the Alto, only one thing could be running at a time and that was a profound limitation. When we began to design our answer to these problems a few weeks later, we called Lucasfilm to ask if they minded us borrowing their excellent rude name, and they readily agreed. Our slogan: A jerq at every desk. This was cool, we had good shirts, and Bart even made license plates that read JERQ. But when the thing started to get interesting, Sam Morgan, 127's director, got very nervous. He didn't want to talk to his colleagues about how good our jerqs were. So he proposed "RX" (research experimental) and Bart and I immediately huddled down and came up with blit, from bitblt, and that was accepted. So it was Sam who forced the issue. A shame really, but BTL management wasn't famous for its sense of humor. This is all with the 68000 original, which had been hand-built by us using wire wrap and then in larger but still modest numbers by a company on Long Island whose name was Northern Atlantic if I remember right. Wing Moy did most of the work there. Teletype came and measured and analyzed and proposed building some with metal cases and more mass producible board technology, and that became what people around the company, and later elsewhere, called the Blit. The DMD-5620 was the WE32000 version, which resulted from a decision by Scanlon to ram up WE32000 production by selling this product with the chip in it, at a loss because the chip alone cost something like $2000, compared to something like $25 for the 68000. Also, the WE32000 was far less suitable a chip, being buggy and also slower at the specific tasks like bit shifting that you needed for fast graphics. I still have the license plate. Here's a picture I made today. [image: IMG_4673.jpg] For those perhaps too young to understand what a revolution the merging of graphics and multitasking was back then, some testimonials from the time: >From dmr Tue Apr 7 02:01 EST 1981 remote from research Don't lose interest in the jerq terminal stuff, no matter what momentary problems you have with the device or the system. I think the approach and the progress so far are very exciting. >From wild!scj Sun Nov 21 09:52 EST 1982 Well, after an afternoon with the bilt, seeing asteroids, crabs, maxwell, etc. etc, I asked Sarah what she liked best. "I liked mpx best" "What did you like about it?" "I liked making all the different boxes, and making all the different things happen in them, and making them go away." I think "universal appeal" is not too strong a term... >From alice!vax135!tbl Sat May 14 12:07:42 1983 To: alice!rob Subject: you've spoiled me I can't believe it. I'm sitting here at home in front of my 2621, and I can't work. Damn it. I've got to get a blit at home. [Turner and I are really pleased with the software. Good job!] -rob On Sat, Jul 1, 2023 at 1:35 AM Seth Morabito wrote: > Speaking of the Jerq... > > Is there a definitive history anywhere of the progression from Jerq up > through the AT&T 730MTG? When I wrote my DMD5620 emulator I tried to find a > complete history, but wasn't able to. I just found various (possibly > apocryphal) bits and pieces here and there about AT&T objecting to various > names until "DMD" was settled on by marketing at some point, and forcing > the use of a WE32K in the 5620 for make-corporate-happy reasons. > > -Seth > -- > Seth Morabito * Poulsbo, WA * https://loomcom.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_4673.jpg Type: image/jpeg Size: 240604 bytes Desc: not available URL: From crossd at gmail.com Sun Jul 2 03:28:00 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Jul 2023 13:28:00 -0400 Subject: [TUHS] Bell Labs CSTRs In-Reply-To: References: <202306290714.35T7E4Qv016653@freefriends.org> Message-ID: On Thu, Jun 29, 2023 at 11:05 AM Will Senn wrote: > Clem's +1 caught my attention, so I looked into the referenced docs. I saw the rather simple (conceptually) m6 processor described in tech note 54. I like its understandable. > > Why is it called m6? Just curious. I'll take a stab at that; I presume it's due to the naming convention for macro processors from Bell Labs. Consider m4, which itself was written as, "an extension of a macro processor called M3 which was written by D. M. Ritchie for the AP-3 minicomputer; M3 was in turn based on a macro processor implemented for [1]." (from, "The M4 Macro Processor" by Brian Kernighan and Dennis Ritchie, as distributed with 4.3BSD; reference [1] is to "Software Tools" by Kernighan and Plauger). Anyway, once you've got M3 and M4, you've got a naming convention; I'd think it a safe bet that there was an M5 that was an internal experiment, and that M6 was simply the next in line and was interesting enough to be documented in a tech report. - Dan C. Aside: the AP-3 minicomputer came up on this list a few years ago, when Dag Spicer of the Computer History Museum was looking for information about it. Near as folks could figure, it was the computer portion of a Bendix "stereoplotter" for creating terrain maps and the like (Adam Sampson figured that part out; others derived Bendix from part numbers taken from a US Air Force spare parts requisition document I found). > On 6/29/23 09:40, Clem Cole wrote: > > +1 👍 > ᐧ > > On Thu, Jun 29, 2023 at 3:37 AM Noel Hunt wrote: >> >> Many thanks. >> >> On Thu, 29 Jun 2023 at 17:14, wrote: >> > >> > Available at https://www.skeeve.com/bell-labs-cstrs.tar.gz >> > >> > Warren and Brantley and anyone else, feel free to retrieve. >> > >> > I have two sets - both are in the tarball so there are undoubtedly >> > duplications. If someone else can curate them into single canonical >> > set that'd be helpful, I just don't have the time right now. >> > >> > Enjoy, >> > >> > Arnold > > From tuhs at tuhs.org Sun Jul 2 04:03:32 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 01 Jul 2023 18:03:32 +0000 Subject: [TUHS] Bell Labs CSTRs In-Reply-To: References: <202306290714.35T7E4Qv016653@freefriends.org> Message-ID: <9Lm966Be4OkPcrr0D_46OoESAtnWwi7DYjtwvIwKJsB81QIwMmSKIzz5F_JyalhwOXAMP2vdJQwpKuq4jGJryXOcKBAQY7S-r24_Aagb8ss=@protonmail.com> > Anyway, once you've got M3 and M4, you've got a naming convention; I'd > think it a safe bet that there was an M5 that was an internal > experiment, and that M6 was simply the next in line and was > interesting enough to be documented in a tech report. Only problem there is m6 predates m3 and m4. Th m6(I) page first appears in V2 and there is a published reference from 1972. Software Tools, from which m3 derives, was 1976, and m4 was then introduced in V7 (which is also the first research version since V2 without m6 somewhere in the manual.) Here's a rough history of the m6 manpage: https://gitlab.com/segaloco/mandiff/-/commits/v6/man6/m6.6 - Matt G. From douglas.mcilroy at dartmouth.edu Sun Jul 2 04:03:37 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 1 Jul 2023 14:03:37 -0400 Subject: [TUHS] Bell Labs CSTRs Message-ID: > once you've got M3 and M4, you've got a naming convention; I'd > think it a safe bet that there was an M5 that was an internal > experiment, and that M6 was simply the next in line M6 came first, created by Andy Hall as a portability tool for Altran. I always assumed the name echoed Ken Knowlton's L6 (BelL Labs low level list language, with a superscript 6). I seem to recall that M6 was endowed with a very labored acronym. Doug From crossd at gmail.com Sun Jul 2 04:42:07 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Jul 2023 14:42:07 -0400 Subject: [TUHS] Bell Labs CSTRs In-Reply-To: <9Lm966Be4OkPcrr0D_46OoESAtnWwi7DYjtwvIwKJsB81QIwMmSKIzz5F_JyalhwOXAMP2vdJQwpKuq4jGJryXOcKBAQY7S-r24_Aagb8ss=@protonmail.com> References: <202306290714.35T7E4Qv016653@freefriends.org> <9Lm966Be4OkPcrr0D_46OoESAtnWwi7DYjtwvIwKJsB81QIwMmSKIzz5F_JyalhwOXAMP2vdJQwpKuq4jGJryXOcKBAQY7S-r24_Aagb8ss=@protonmail.com> Message-ID: On Sat, Jul 1, 2023 at 2:03 PM segaloco wrote: > > Anyway, once you've got M3 and M4, you've got a naming convention; I'd > > think it a safe bet that there was an M5 that was an internal > > experiment, and that M6 was simply the next in line and was > > interesting enough to be documented in a tech report. > > Only problem there is m6 predates m3 and m4. Th m6(I) page first appears in V2 and there is a published reference from 1972. Software Tools, from which m3 derives, was 1976, and m4 was then introduced in V7 (which is also the first research version since V2 without m6 somewhere in the manual.) > > Here's a rough history of the m6 manpage: https://gitlab.com/segaloco/mandiff/-/commits/v6/man6/m6.6 Oops. Very well, then: stab my stab with a fork, for it is dead. - Dan C. From arnold at skeeve.com Sun Jul 2 17:10:51 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Jul 2023 01:10:51 -0600 Subject: [TUHS] Jerq menuhit/mhit In-Reply-To: References: <88993DC3-99D0-4977-A410-2BCAED781245@humeweb.com> <121a673f-0282-4261-9e41-f324556c1832@app.fastmail.com> Message-ID: <202307020710.3627ApF9024225@freefriends.org> I had a DMD 5620 for a few (too short) years at Georgia Tech; AT&T gifted a number of them as well as two 3B20s to us. We used the DMDs on a vax running 4.2 BSD. They were heavy suckers! I think close to 50 pounds! It was wonderful to use. Extremely productive as compared to a regular terminal with just one session. Unfortunately, there were enough of the things in use that it drove the poor vax to its knees. Nonetheless, I have fond memories of it to this day. Arnold Rob Pike wrote: > The original name was Jerq, which was first the name given by friends at > Lucasfilm to the Three Rivers PERQ workstations they had, for which the > Pascal-written software and operating system were unsatisfactory. Bart > Locanthi and I (with Greg Chesson and Dave Ditzel?) visited Lucasfilm in > 1981 and we saw all the potential there with none of the realization. My > personal aha was that, as on the Alto, only one thing could be running at a > time and that was a profound limitation. When we began to design our answer > to these problems a few weeks later, we called Lucasfilm to ask if they > minded us borrowing their excellent rude name, and they readily agreed. > > Our slogan: A jerq at every desk. > > This was cool, we had good shirts, and Bart even made license plates that > read JERQ. But when the thing started to get interesting, Sam Morgan, 127's > director, got very nervous. He didn't want to talk to his colleagues about > how good our jerqs were. So he proposed "RX" (research experimental) and > Bart and I immediately huddled down and came up with blit, from bitblt, and > that was accepted. So it was Sam who forced the issue. A shame really, but > BTL management wasn't famous for its sense of humor. > > This is all with the 68000 original, which had been hand-built by us using > wire wrap and then in larger but still modest numbers by a company on Long > Island whose name was Northern Atlantic if I remember right. Wing Moy did > most of the work there. > > Teletype came and measured and analyzed and proposed building some with > metal cases and more mass producible board technology, and that became what > people around the company, and later elsewhere, called the Blit. > > The DMD-5620 was the WE32000 version, which resulted from a decision by > Scanlon to ram up WE32000 production by selling this product with the chip > in it, at a loss because the chip alone cost something like $2000, compared > to something like $25 for the 68000. Also, the WE32000 was far less > suitable a chip, being buggy and also slower at the specific tasks like bit > shifting that you needed for fast graphics. > > I still have the license plate. Here's a picture I made today. > > [image: IMG_4673.jpg] > > For those perhaps too young to understand what a revolution the merging of > graphics and multitasking was back then, some testimonials from the time: > > From dmr Tue Apr 7 02:01 EST 1981 remote from research > > > Don't lose interest in the jerq terminal stuff, no matter what > > momentary problems you have with the device or the system. > > I think the approach and the progress so far are very exciting. > > > > From wild!scj Sun Nov 21 09:52 EST 1982 > > Well, after an afternoon with the bilt, seeing asteroids, crabs, maxwell, > > etc. etc, I asked Sarah what she liked best. > > > "I liked mpx best" > > > "What did you like about it?" > > > "I liked making all the different boxes, and making all the different things > > happen in them, and making them go away." > > > I think "universal appeal" is not too strong a term... > > > > From alice!vax135!tbl Sat May 14 12:07:42 1983 > > To: alice!rob > > Subject: you've spoiled me > > > I can't believe it. I'm sitting here at home in front of my > > 2621, and I can't work. > > > Damn it. I've got to get a blit at home. > > [Turner and I are really pleased with the software. Good job!] > > > > -rob > > > On Sat, Jul 1, 2023 at 1:35 AM Seth Morabito wrote: > > > Speaking of the Jerq... > > > > Is there a definitive history anywhere of the progression from Jerq up > > through the AT&T 730MTG? When I wrote my DMD5620 emulator I tried to find a > > complete history, but wasn't able to. I just found various (possibly > > apocryphal) bits and pieces here and there about AT&T objecting to various > > names until "DMD" was settled on by marketing at some point, and forcing > > the use of a WE32K in the 5620 for make-corporate-happy reasons. > > > > -Seth > > -- > > Seth Morabito * Poulsbo, WA * https://loomcom.com/ > > From dave at bagpuss.nu Mon Jul 3 00:13:51 2023 From: dave at bagpuss.nu (Dave Brown) Date: Sun, 2 Jul 2023 10:13:51 -0400 Subject: [TUHS] Jerq menuhit/mhit In-Reply-To: <202307020710.3627ApF9024225@freefriends.org> References: <202307020710.3627ApF9024225@freefriends.org> Message-ID: <12B5570C-9834-4081-A832-F89408B9C44B@bagpuss.nu> Was there a connection between MGR and Blit? Just from a programming standpoint there is similarities in that they both transport agnostic; using escape sequences for graphical/UI functions. I know MGR code does little more than provide a bitblit interface and it’s upto whoever ports it to implement the interface to the hardware. I took the MGR code, and extended the distribution for the Atari ST (added new demos, fonts and libraries); many years ago. Might be worth porting it to SDL for a giggle. Sent from my iPhone > On Jul 2, 2023, at 3:11 AM, arnold at skeeve.com wrote: > I had a DMD 5620 for a few (too short) years at Georgia Tech; AT&T > gifted a number of them as well as two 3B20s to us. We used the DMDs > on a vax running 4.2 BSD. They were heavy suckers! I think close to > 50 pounds! > > It was wonderful to use. Extremely productive as compared to a regular > terminal with just one session. > > Unfortunately, there were enough of the things in use that it drove > the poor vax to its knees. > > Nonetheless, I have fond memories of it to this day. > > Arnold > > Rob Pike wrote: > >> The original name was Jerq, which was first the name given by friends at >> Lucasfilm to the Three Rivers PERQ workstations they had, for which the >> Pascal-written software and operating system were unsatisfactory. Bart >> Locanthi and I (with Greg Chesson and Dave Ditzel?) visited Lucasfilm in >> 1981 and we saw all the potential there with none of the realization. My >> personal aha was that, as on the Alto, only one thing could be running at a >> time and that was a profound limitation. When we began to design our answer >> to these problems a few weeks later, we called Lucasfilm to ask if they >> minded us borrowing their excellent rude name, and they readily agreed. >> >> Our slogan: A jerq at every desk. >> >> This was cool, we had good shirts, and Bart even made license plates that >> read JERQ. But when the thing started to get interesting, Sam Morgan, 127's >> director, got very nervous. He didn't want to talk to his colleagues about >> how good our jerqs were. So he proposed "RX" (research experimental) and >> Bart and I immediately huddled down and came up with blit, from bitblt, and >> that was accepted. So it was Sam who forced the issue. A shame really, but >> BTL management wasn't famous for its sense of humor. >> >> This is all with the 68000 original, which had been hand-built by us using >> wire wrap and then in larger but still modest numbers by a company on Long >> Island whose name was Northern Atlantic if I remember right. Wing Moy did >> most of the work there. >> >> Teletype came and measured and analyzed and proposed building some with >> metal cases and more mass producible board technology, and that became what >> people around the company, and later elsewhere, called the Blit. >> >> The DMD-5620 was the WE32000 version, which resulted from a decision by >> Scanlon to ram up WE32000 production by selling this product with the chip >> in it, at a loss because the chip alone cost something like $2000, compared >> to something like $25 for the 68000. Also, the WE32000 was far less >> suitable a chip, being buggy and also slower at the specific tasks like bit >> shifting that you needed for fast graphics. >> >> I still have the license plate. Here's a picture I made today. >> >> [image: IMG_4673.jpg] >> >> For those perhaps too young to understand what a revolution the merging of >> graphics and multitasking was back then, some testimonials from the time: >> >> From dmr Tue Apr 7 02:01 EST 1981 remote from research >> >> >> Don't lose interest in the jerq terminal stuff, no matter what >> >> momentary problems you have with the device or the system. >> >> I think the approach and the progress so far are very exciting. >> >> >> >> From wild!scj Sun Nov 21 09:52 EST 1982 >> >> Well, after an afternoon with the bilt, seeing asteroids, crabs, maxwell, >> >> etc. etc, I asked Sarah what she liked best. >> >> >> "I liked mpx best" >> >> >> "What did you like about it?" >> >> >> "I liked making all the different boxes, and making all the different things >> >> happen in them, and making them go away." >> >> >> I think "universal appeal" is not too strong a term... >> >> >> >> From alice!vax135!tbl Sat May 14 12:07:42 1983 >> >> To: alice!rob >> >> Subject: you've spoiled me >> >> >> I can't believe it. I'm sitting here at home in front of my >> >> 2621, and I can't work. >> >> >> Damn it. I've got to get a blit at home. >> >> [Turner and I are really pleased with the software. Good job!] >> >> >> >> -rob >> >> >> On Sat, Jul 1, 2023 at 1:35 AM Seth Morabito wrote: >> >>> Speaking of the Jerq... >>> Is there a definitive history anywhere of the progression from Jerq up >>> through the AT&T 730MTG? When I wrote my DMD5620 emulator I tried to find a >>> complete history, but wasn't able to. I just found various (possibly >>> apocryphal) bits and pieces here and there about AT&T objecting to various >>> names until "DMD" was settled on by marketing at some point, and forcing >>> the use of a WE32K in the 5620 for make-corporate-happy reasons. >>> -Seth >>> -- >>> Seth Morabito * Poulsbo, WA * https://loomcom.com/ From arnold at skeeve.com Mon Jul 3 00:27:22 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Jul 2023 08:27:22 -0600 Subject: [TUHS] Jerq menuhit/mhit In-Reply-To: <12B5570C-9834-4081-A832-F89408B9C44B@bagpuss.nu> References: <202307020710.3627ApF9024225@freefriends.org> <12B5570C-9834-4081-A832-F89408B9C44B@bagpuss.nu> Message-ID: <202307021427.362ERMAk000615@freefriends.org> Good question. MGR was somewhat later. It was done by a guy at BellCore if I remember correctly. I used it some on a small sparcstation. On that hardware it was super fast, whereas X11 was much slower. This would have been in early-to-mid 90s. Arnold Dave Brown wrote: > Was there a connection between MGR and Blit? Just from a programming > standpoint there is similarities in that they both transport agnostic; > using escape sequences for graphical/UI functions. I know MGR code does > little more than provide a bitblit interface and it’s upto whoever > ports it to implement the interface to the hardware. > > I took the MGR code, and extended the distribution for the Atari ST > (added new demos, fonts and libraries); many years ago. > > Might be worth porting it to SDL for a giggle. > > > Sent from my iPhone > > > On Jul 2, 2023, at 3:11 AM, arnold at skeeve.com wrote: > > I had a DMD 5620 for a few (too short) years at Georgia Tech; AT&T > > gifted a number of them as well as two 3B20s to us. We used the DMDs > > on a vax running 4.2 BSD. They were heavy suckers! I think close to > > 50 pounds! > > > > It was wonderful to use. Extremely productive as compared to a regular > > terminal with just one session. > > > > Unfortunately, there were enough of the things in use that it drove > > the poor vax to its knees. > > > > Nonetheless, I have fond memories of it to this day. > > > > Arnold > > > > Rob Pike wrote: > > > >> The original name was Jerq, which was first the name given by friends at > >> Lucasfilm to the Three Rivers PERQ workstations they had, for which the > >> Pascal-written software and operating system were unsatisfactory. Bart > >> Locanthi and I (with Greg Chesson and Dave Ditzel?) visited Lucasfilm in > >> 1981 and we saw all the potential there with none of the realization. My > >> personal aha was that, as on the Alto, only one thing could be running at a > >> time and that was a profound limitation. When we began to design our answer > >> to these problems a few weeks later, we called Lucasfilm to ask if they > >> minded us borrowing their excellent rude name, and they readily agreed. > >> > >> Our slogan: A jerq at every desk. > >> > >> This was cool, we had good shirts, and Bart even made license plates that > >> read JERQ. But when the thing started to get interesting, Sam Morgan, 127's > >> director, got very nervous. He didn't want to talk to his colleagues about > >> how good our jerqs were. So he proposed "RX" (research experimental) and > >> Bart and I immediately huddled down and came up with blit, from bitblt, and > >> that was accepted. So it was Sam who forced the issue. A shame really, but > >> BTL management wasn't famous for its sense of humor. > >> > >> This is all with the 68000 original, which had been hand-built by us using > >> wire wrap and then in larger but still modest numbers by a company on Long > >> Island whose name was Northern Atlantic if I remember right. Wing Moy did > >> most of the work there. > >> > >> Teletype came and measured and analyzed and proposed building some with > >> metal cases and more mass producible board technology, and that became what > >> people around the company, and later elsewhere, called the Blit. > >> > >> The DMD-5620 was the WE32000 version, which resulted from a decision by > >> Scanlon to ram up WE32000 production by selling this product with the chip > >> in it, at a loss because the chip alone cost something like $2000, compared > >> to something like $25 for the 68000. Also, the WE32000 was far less > >> suitable a chip, being buggy and also slower at the specific tasks like bit > >> shifting that you needed for fast graphics. > >> > >> I still have the license plate. Here's a picture I made today. > >> > >> [image: IMG_4673.jpg] > >> > >> For those perhaps too young to understand what a revolution the merging of > >> graphics and multitasking was back then, some testimonials from the time: > >> > >> From dmr Tue Apr 7 02:01 EST 1981 remote from research > >> > >> > >> Don't lose interest in the jerq terminal stuff, no matter what > >> > >> momentary problems you have with the device or the system. > >> > >> I think the approach and the progress so far are very exciting. > >> > >> > >> > >> From wild!scj Sun Nov 21 09:52 EST 1982 > >> > >> Well, after an afternoon with the bilt, seeing asteroids, crabs, maxwell, > >> > >> etc. etc, I asked Sarah what she liked best. > >> > >> > >> "I liked mpx best" > >> > >> > >> "What did you like about it?" > >> > >> > >> "I liked making all the different boxes, and making all the different things > >> > >> happen in them, and making them go away." > >> > >> > >> I think "universal appeal" is not too strong a term... > >> > >> > >> > >> From alice!vax135!tbl Sat May 14 12:07:42 1983 > >> > >> To: alice!rob > >> > >> Subject: you've spoiled me > >> > >> > >> I can't believe it. I'm sitting here at home in front of my > >> > >> 2621, and I can't work. > >> > >> > >> Damn it. I've got to get a blit at home. > >> > >> [Turner and I are really pleased with the software. Good job!] > >> > >> > >> > >> -rob > >> > >> > >> On Sat, Jul 1, 2023 at 1:35 AM Seth Morabito wrote: > >> > >>> Speaking of the Jerq... > >>> Is there a definitive history anywhere of the progression from Jerq up > >>> through the AT&T 730MTG? When I wrote my DMD5620 emulator I tried to find a > >>> complete history, but wasn't able to. I just found various (possibly > >>> apocryphal) bits and pieces here and there about AT&T objecting to various > >>> names until "DMD" was settled on by marketing at some point, and forcing > >>> the use of a WE32K in the 5620 for make-corporate-happy reasons. > >>> -Seth > >>> -- > >>> Seth Morabito * Poulsbo, WA * https://loomcom.com/ From norman at oclsc.org Mon Jul 3 01:14:45 2023 From: norman at oclsc.org (Norman Wilson) Date: Sun, 2 Jul 2023 11:14:45 -0400 (EDT) Subject: [TUHS] Jerq menuhit/mhit Message-ID: <5E562516DD9AED7CEF9BE6FED02623BE.for-standards-violators@oclsc.org> I had an experience similar to Tom London's: To: alice!rob Subject: you've spoiled me I can't believe it. I'm sitting here at home in front of my 2621, and I can't work. Damn it. I've got to get a blit at home. When I left Bell Labs, I had an X11 workstation at work, but only a simple terminal at home. Having used a Jerqblit5620 for years at both work and home, I found it incredibly limiting. After a year or so I came across a reseller who had a lot of off-lease 5620s for sale cheap (like USD 150 or so each). I asked around the university I now worked at, found a handful of other people who wanted in, and then a local small company who did System V system-administration consulting who wanted some for themselves, and were willing to handle all the paperwork. All that allowed us to negotiate the price down even more. In the end I bought six, of which I think four are still working, though I haven't turned any of them on for years. None of the Unixes I used at the time came with 5620 support, but the protocol for the basic window system built into the ROM was well-documented and I managed to roll my own host support. I also managed to cobble up my own binary-loading tools sufficient to get sam working (I forget how I compiled the binary for the terminal); that was rather more work, but it was worth it to be able to have sam and multiple windows from home, even though it was the ROM OS and therefore mpx rather than mux. I remember porting my version of the host code to Ultrix, SunOS 4, and IRIX. My workplace at the time had a little bit of VAX/VMS around. I didn't use that much but wanted to try porting my host code to VMS as well. VMS had had a C compiler for some years and some sort of pseudo-terminal for a shorter time, so it ought to have been possible. I didn't get around to it before we finally left VMS behind in the dustbin of history. I wish I'd found time to do it, just to show that there really was nothing Unix-specific about the idea or the implementation. It's just a multiplexing protocol; it needs no kernel support except that needed to run a command-line session not attached to a physical terminal, and networking has long since made that available on any competent OS. Norman Wilson Toronto ON From douglas.mcilroy at dartmouth.edu Tue Jul 4 03:51:15 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 3 Jul 2023 13:51:15 -0400 Subject: [TUHS] symbols in eqnchar Message-ID: > What is the name of the mathematic symbols Here are some readings, not exactly names incl (used with partial orderings) is included in, or is less than |> is not greater than |< is not less than wig wig is approximately, or asymptotically approaches ~wig is approximately Doug From rich.salz at gmail.com Thu Jul 6 00:01:08 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 5 Jul 2023 10:01:08 -0400 Subject: [TUHS] Lions commentary Message-ID: I have a copy of Lions's "A Commentary on the UNIX Operating System" It is an n-th generation photocopy that I've had for some number of decades. It also has the source code, as I guess all of those copies did back in the day. I could just recycle the paper -- it's yellowed with age -- but I'd rather pay it forward and ship it to someone who promises to make copies for others who want it. This is also on bitsavers, so you're only doing this to preserve the sense of history in passing photocopies around. I'll take bids on how many copies you'll provide. I'll post the winning bid (without their address), so that the community can pressureXXXXXX ensure they meet their commitment. I'll send it out by the end of the week. I will give preference to US/Canada domestic addresses since that is easier for me. How much preference is left to my discretion. :) I hope this doesn't make me sound like a jerk; it's intended to be lighthearted community service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jul 6 02:10:43 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 05 Jul 2023 16:10:43 +0000 Subject: [TUHS] Lions commentary In-Reply-To: References: Message-ID: I think this is a great community engagement activity. That said, can't do the printing myself. I'll throw myself out there as a potential customer though, I have the print version they did many many years later but it'd be cool to have one of the samizdat copies. To whoever does speak for this and start producing volumes, you've got your first customer! - Matt G. P.S. Are the typesetter sources for the commentary preserved anywhere? The typesetting style is very, very much like a small Bell System Teletype 28 training course document that I want to see about recreating as sources, might be able to take some pointers from the commentary. ------- Original Message ------- On Wednesday, July 5th, 2023 at 7:01 AM, Rich Salz wrote: > I have a copy of Lions's "A Commentary on the UNIX Operating System" It is an n-th generation photocopy that I've had for some number of decades. It also has the source code, as I guess all of those copies did back in the day. I could just recycle the paper -- it's yellowed with age -- but I'd rather pay it forward and ship it to someone who promises to make copies for others who want it. This is also on bitsavers, so you're only doing this to preserve the sense of history in passing photocopies around. > > I'll take bids on how many copies you'll provide. I'll post the winning bid (without their address), so that the community can pressureXXXXXX ensure they meet their commitment. I'll send it out by the end of the week. > > I will give preference to US/Canada domestic addresses since that is easier for me. How much preference is left to my discretion. :) > > I hope this doesn't make me sound like a jerk; it's intended to be lighthearted community service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jul 6 03:59:57 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Jul 2023 13:59:57 -0400 Subject: [TUHS] Lions commentary In-Reply-To: References: Message-ID: A troff version does exist - as I recall it was Ian J that recovered that. I’ll go poking later when I have a real computer not my mobile. The actual nroff version that ‘typeset’ for Printronix 300 printer that John used may or may not be. It was done pre-make(1) so it was v6 script. While you can find a pdf of troffed version in the wild, I recommend getting the bound version from Amazon these days. I believe care was made to ensure it lined up exactly like the original - although T is bound as one volume not two. Like Rich, my nth generation copy of the original is quite faded and more difficult to read On Wed, Jul 5, 2023 at 12:11 PM segaloco via TUHS wrote: > I think this is a great community engagement activity. That said, can't > do the printing myself. I'll throw myself out there as a potential > customer though, I have the print version they did many many years later > but it'd be cool to have one of the samizdat copies. To whoever does speak > for this and start producing volumes, you've got your first customer! > > - Matt G. > > P.S. Are the typesetter sources for the commentary preserved anywhere? > The typesetting style is very, very much like a small Bell System Teletype > 28 training course document that I want to see about recreating as sources, > might be able to take some pointers from the commentary. > ------- Original Message ------- > On Wednesday, July 5th, 2023 at 7:01 AM, Rich Salz > wrote: > > I have a copy of Lions's "A Commentary on the UNIX Operating System" It is > an n-th generation photocopy that I've had for some number of decades. It > also has the source code, as I guess all of those copies did back in the > day. I could just recycle the paper -- it's yellowed with age -- but I'd > rather pay it forward and ship it to someone who promises to make copies > for others who want it. This is also on bitsavers, so you're only doing > this to preserve the sense of history in passing photocopies around. > > I'll take bids on how many copies you'll provide. I'll post the winning > bid (without their address), so that the community can pressureXXXXXX > ensure they meet their commitment. I'll send it out by the end of the week. > > I will give preference to US/Canada domestic addresses since that is > easier for me. How much preference is left to my discretion. :) > > I hope this doesn't make me sound like a jerk; it's intended to be > lighthearted community service. > > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jul 8 10:33:35 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 08 Jul 2023 00:33:35 +0000 Subject: [TUHS] PSA: Several 1983 SysV Documents on eBay Message-ID: Howdy folks, I just wanted to pass on word that there is currently a stack of 1983 System V documents on eBay, here's a link to the User's Manual: https://www.ebay.com/itm/225659365754 The same seller has these documents available in their shop (as well as a bunch of other old computing documents and magazines): - User's Manual - Administrator's Manual - Error Message Manual - Operator's Guide - Graphics Guide - Transition Aids - Release Description So not the whole lot, but a nice spread nonetheless. I've already got all of these and they're already all scanned in some fashion or another, or I'd have scooped em up already. Anywho, figured that might pique folks' curiosity. The pricing is very agreeable might I add, sometimes I see single volumes from this set going for over $100. - Matt G. From dds at aueb.gr Mon Jul 10 21:18:41 2023 From: dds at aueb.gr (Diomidis Spinellis) Date: Mon, 10 Jul 2023 14:18:41 +0300 Subject: [TUHS] Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases Message-ID: I seem to recall reading that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases. However, I cannot find where this is stated. I tried a Google web and a Google Scholar search using the terms "unix endless accumulation special cases", and I also asked ChatGPT for a publication associated with this phrase. I also searched for "special" in D.M.Ritchie's "The Evolution of the Unix Time-sharing System" and "The UNIX Time-sharing System A Retrospective". (Amazingly, both have several parts that still highly relevant.) Can anyone help? Am I misremembering something? From arnold at skeeve.com Mon Jul 10 21:40:08 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 10 Jul 2023 05:40:08 -0600 Subject: [TUHS] Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases In-Reply-To: References: Message-ID: <202307101140.36ABe8b2030572@freefriends.org> Try looking at the original 1974 CACM paper on Unix by Ken & DMR. I suspect you'll find something like that there. HTH, Arnold Diomidis Spinellis wrote: > I seem to recall reading that the power of Unix stems from the wise > choice of a few design principles rather than the endless accumulation > of special cases. However, I cannot find where this is stated. I tried > a Google web and a Google Scholar search using the terms "unix endless > accumulation special cases", and I also asked ChatGPT for a publication > associated with this phrase. I also searched for "special" in > D.M.Ritchie's "The Evolution of the Unix Time-sharing System" and "The > UNIX Time-sharing System␔ A Retrospective". (Amazingly, both have > several parts that still highly relevant.) > > Can anyone help? Am I misremembering something? From jnc at mercury.lcs.mit.edu Mon Jul 10 22:27:56 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Jul 2023 08:27:56 -0400 (EDT) Subject: [TUHS] Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases Message-ID: <20230710122756.0A76018C094@mercury.lcs.mit.edu> > From: Diomidis Spinellis > I seem to recall reading that the power of Unix stems from the wise > choice of a few design principles rather than the endless accumulation > of special cases. However, I cannot find where this is stated. I think you're thinking of something in the CACM paper: https://www.bell-labs.com/usr/dmr/www/cacm.html "The success of Unix lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas" Noel From tuhs at tuhs.org Tue Jul 11 10:44:33 2023 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 11 Jul 2023 10:44:33 +1000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie Message-ID: All, way back when, Dennis sent me some DECtape images to look after. I've put some of them in the Unix Archive (the s1 and s2 tapes) as they contained Unix source code or binaries. The others I kept aside as they didn't contain Unix code, or they were potentially sensitive. Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might contain fragments of B source code or B binaries. I passed the extra tapes on to him, and he has found some very interesting nuggets from the time period when B -> NB -> C. So, to help provide the context around Angelo's work, I've decided to put all the tapes that Dennis gave me here: https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ Cheers, Warren From lars at nocrew.org Tue Jul 11 16:24:30 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 11 Jul 2023 06:24:30 +0000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: (Warren Toomey via TUHS's message of "Tue, 11 Jul 2023 10:44:33 +1000") References: Message-ID: <7wlefnt17l.fsf@junk.nocrew.org> Warren Toomey wrote: > I passed the extra tapes on to him, and he has found some very > interesting nuggets from the time period when B -> NB -> C. Very exciting! I can't wait to read about what he found, and how. From f4grx at f4grx.net Tue Jul 11 18:39:25 2023 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Tue, 11 Jul 2023 10:39:25 +0200 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> Hi, Thank you for this. The letters in the DMR2 folder are extremely interesting. lett9 is to M. Carpenter (unknown to me) at the european CERN ! What can be shared about these on social media? Are these tapes considered private data, or public domain, or something else? Sebastien Le 11/07/2023 à 02:44, Warren Toomey via TUHS a écrit : > All, way back when, Dennis sent me some DECtape images to look after. I've > put some of them in the Unix Archive (the s1 and s2 tapes) as they contained > Unix source code or binaries. The others I kept aside as they didn't contain > Unix code, or they were potentially sensitive. > > Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might > contain fragments of B source code or B binaries. I passed the extra tapes > on to him, and he has found some very interesting nuggets from the time > period when B -> NB -> C. > > So, to help provide the context around Angelo's work, I've decided to put > all the tapes that Dennis gave me here: > > https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ > > Cheers, Warren From lars at nocrew.org Tue Jul 11 18:57:37 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 11 Jul 2023 08:57:37 +0000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> (Sebastien F4GRX's message of "Tue, 11 Jul 2023 10:39:25 +0200") References: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> Message-ID: <7w351uu8ou.fsf@junk.nocrew.org> Sebastien F4GRX wrote: > lett9 is to M. Carpenter (unknown to me) at the european CERN ! Seems to be Brian Carpenter. I'll let him know about this. From henry.r.bent at gmail.com Tue Jul 11 19:21:10 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 11 Jul 2023 05:21:10 -0400 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 at 20:44, Warren Toomey via TUHS wrote: > All, way back when, Dennis sent me some DECtape images to look after. I've > put some of them in the Unix Archive (the s1 and s2 tapes) as they > contained > Unix source code or binaries. The others I kept aside as they didn't > contain > Unix code, or they were potentially sensitive. > > I see that this archive contains code for pricing out 11/40 and 11/45 systems, plus options. This reminds me that I've found several references to the 11/45 that Research purchased (late 1972/early 1973?) but no specific details about its configuration. I presume that it had an RK05 of some sort but I'm curious about other peripherals and the amount of memory. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jul 12 00:56:29 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 11 Jul 2023 10:56:29 -0400 Subject: [TUHS] OSDI/ATC? Message-ID: Is anyone else at OSDI/ATC this year? Any interest in a BoF? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Wed Jul 12 02:52:51 2023 From: norman at oclsc.org (Norman Wilson) Date: Tue, 11 Jul 2023 12:52:51 -0400 Subject: [TUHS] OSDI/ATC? In-Reply-To: References: Message-ID: <70F4C08A6199F524E1CE2FF5757414BF.for-standards-violators@oclsc.org> Replying in public in case it's not just me and Dan who are here. 1. Yes 2. Maybe. Or feel free just to start a hallway chat. As it happens I am wearing a UNIX t-shirt today. Norman Wilson Temporarily Boston MA rather than Toronto ON From aap at papnet.eu Wed Jul 12 03:27:45 2023 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 11 Jul 2023 19:27:45 +0200 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: I have attached the extracted e-pi and dmr tapes. While calculating e and pi is certainly interesting (ken will be able to say something about that), what I found particularly cool are the unused block after the e-pi tape! They contain a bunch of binaries, some of which I was able to identify, see the e-pi_salvaged directory. While trying to restore these files I made some observations: - the programs written in B were compiled with a newer compiler than the files from the s2 tape. In particular they have the strings at the end of the respective object file and not inline where they appear (not in the .data section however) - the B shell script mentioned in the man page that runs bc and ba is in there - the man shell script is in there - su has a different password (^S^Y^S) - mail uses the file 'mbox' not 'mail', consistent with a change in the manual from v1 to v2 - some programs appeared to be written in a threaded code similar to B: echo, size, fc The last point was of course most fascinating to me. So I disassembled the echo binary and found something I would have never expected to find: a C-like language compiled to threaded code. My immediate guess was that this must be NB, mentioned in dmr's c history paper [1], however ken said that NB was always compiled and that dmr first developed it on the honeywell mainframe. Now dmr himself in that same paper said one main difference between NB and early C was the way that vectors/arrays were handled, but this is clearly not the case because the last1120c compiler treats arrays the same way as B does. My point is that what exactly NB was seems to be a bit uncertain. What we actually have is: B implemented in threaded code a C-like language with byte types implemented in threaded code C implemented in machine code My personal theory is that this intermediate step is exactly what NB is. Of course dmr also developed a machine code generator for B on the honeywell machine, even if it is lost. But how that relates to NB and the PDP-11 exactly I cannot say, so take all that with a grain of salt. I hope the people who were there and can say more will say something about this :) In any case we have this (to me) totally surprising intermediate step between B and C. I have put some (sloppily commented) disassembled and/or restored files here [2]. What's very cool is that the dmr tape has a file fc.b, which is clearly not written in B! My guess is that compiled it will match the fc binary more or less exactly (I haven't decompiled this one yet). Also of great interest in this context is the cgd directory on the dmr tape. I'm not sure how finished this program actually is (I suspect it is not), but it claims to be a fortran code generator and it has a structure quite similar to the second pass of the C compiler, with a difference: The C compiler builds a tree for every expression in the first pass and dumps that into a file to be picked up by the second pass. This program builds the tree in the second pass. Interestingly this is much like I think the B assembler (ba) would have worked. Cheers, Angelo [1] https://www.bell-labs.com/usr/dmr/www/chist.html [2] http://squoze.net/NB/ -------------- next part -------------- A non-text attachment was scrubbed... Name: dmr_tapes2.tgz Type: application/x-gtar-compressed Size: 118220 bytes Desc: not available URL: From aap at papnet.eu Wed Jul 12 03:29:34 2023 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 11 Jul 2023 19:29:34 +0200 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: On 11/07/23, Angelo Papenhoff wrote: > - some programs appeared to be written in a threaded code similar to B: > echo, size, fc What I forgot: size and fc on the s2 tape are written in the same language (in fact the size binary is the same, haven't checked fc). It was right under our eyes the whole time! From tuhs at tuhs.org Wed Jul 12 04:24:55 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 11 Jul 2023 18:24:55 +0000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: > > - some programs appeared to be written in a threaded code similar to B: > > echo, size, fc > > > What I forgot: size and fc on the s2 tape are written in the same > language (in fact the size binary is the same, haven't checked fc). > It was right under our eyes the whole time! This is all great stuff Angelo, glad to see more light being shed on this stuff. If you need any extra fingers on disassembly just let me know, it's one of my oldest hobbies! - Matt G. From ken.unix.guy at gmail.com Wed Jul 12 09:54:59 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Tue, 11 Jul 2023 19:54:59 -0400 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: If interested this fellow has for sale among other things DEC Tape canisters. https://forum.vcfed.org/index.php?threads/cleaning-house.1239509/ Ken On Tue, Jul 11, 2023 at 2:25 PM segaloco via TUHS wrote: > > > - some programs appeared to be written in a threaded code similar to B: > > > echo, size, fc > > > > > > What I forgot: size and fc on the s2 tape are written in the same > > language (in fact the size binary is the same, haven't checked fc). > > It was right under our eyes the whole time! > > This is all great stuff Angelo, glad to see more light being shed on this > stuff. If you need any extra fingers on disassembly just let me know, it's > one of my oldest hobbies! > > - Matt G. > -- End of line JOB TERMINATED -->> Okey Dokey, OK Boss -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Wed Jul 12 17:01:52 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 12 Jul 2023 17:01:52 +1000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> References: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> Message-ID: On Tue, Jul 11, 2023 at 10:39:25AM +0200, Sebastien F4GRX wrote: > Hi, > > Thank you for this. The letters in the DMR2 folder are extremely > interesting. > > lett9 is to M. Carpenter (unknown to me) at the european CERN ! The fed/form names in ken/tp/distr/form.m dated Jun 28 1975 mostly match the names and numbers used in https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/19750730-unix-news-n1.pdf "The integer part of the sequence number of the first line corresponds to a list of licenses that Ken Thompson keeps. The fractional part designates multiple installations under a single license." nmrc output from v6 fed on the name strings: name-1: Professor Cyrus Levinthal Department of Biological Sciences Schermerhorn Hall Columbia University New York, New York 10027 name-1a: Mr. Reidar Bornholdt Dept. of Biological Science 653 Scherm Ext. Columbia University New York, N. Y. 10027 name-2: Prof. T. A. Marsland Department of Computing Science The University of Alberta Edmonton, Canada name-3: Mr. Bill Mayhew The Children's Museum The Jamaicaway Boston, Massachusetts 02130 name-4: Prof. Bruce W. Arden Department of Electrical Engineering Brackett Hall, Engineering Quadrangle Princeton University Princeton, New Jersey 08540 name-5: Mr. E. J. Desautels The University of Wisconsin Computer Science Department 1210 West Dayton Street Madison, Wisconsin 53706 name-6: Mr. A. J. Lindstrom Sponsored Research Administrator California Institute of Technology Pasadena, California 91109 name-7: Mr. Gary M. Goins Department of Biometry Wearn Research Building Case Western University Cleveland, Ohio 44106 name-8: Prof. W. H. Huggins Department of Electrical Engineering The Johns Hopkins University Baltimore, Maryland 21218 name-9: Mr. Brent Byer Aiken Computation Lab Harvard University Cambridge, Massachusetts 02138 name-10: Dr. Vladimir Slamecka Computer Center School of Information and Computer Science Georgia Institute of Technology Atlanta, Georgia 30332 name-11: Dr. Kenneth King Office of the Dean for Computer Systems 535 East 80th Street New York, New York 10021 name-11a: Prof. Melvin Ferentz Physics Dept. Brooklyn College of CUNY Brooklyn, N.Y. 11210 name-12: James P. Lewis, Director Computer Center Columbia University College of Physicians and Surgeons 630 West 168th Street New York, N. Y. 10032 name-13: Mr. Rusty Whitney Director of Computing Oregon Museum of Science and Industry 4015 S.W. Canyon Road Portland, Oregon 97221 name-14: Mr. Gideon Yuval Computer Science Department The Hebrew University of Jerusalem Jerusalem, Israel name-15: Mr. Stanley C. Bateman University of California Contracts and Grants Office San Francisco, California 94143 name-16: Prof. D. A. Michalopoulos Department of Quantitative Methods The California State University Fullerton, California 92634 name-17: Prof. N. Marcuvitz Polytechnic Institute of New York Long Island Center Route 110 Farmingdale, New York 11735 name-18: Prof. R. W. Peebles Computer Communications Network Group University of Waterloo Waterloo, Ontario Canada N2L 3G1 name-19: Mr. Martin E. Newell The University of Utah College of Engineering Salt Lake City, Utah 84112 name-20: Prof. D. A. Jardine Dept. of Computing Science Queen's University at Kingston Kingston, Ontario Canada name-21: Prof. Ralph H. Bjork Science Building Saint Olaf College Northfield, Minnesota 55057 name-22: Prof C. Frank Starmer Duke University Durham, North Carolina 27710 name-23: Prof. R. S. Fabry Evans Hall University of California Berkeley, Calif 94720 name-24: Dr. M. S. Cole Queen Mary College University of London Mile End Road London E1 4NS, England name-25: Mr. John E. Ecklund Yale University 10 Hillhouse Avenue New Haven, Connecticut 06520 name-26: Dr. P. Weiner Information Sciences Dept. The Rand Corporation 1700 Main Street Santa Monica, California 90406 name-26a: Ms. Lois H. Heiser Information Sciences Dept. The Rand Corporation 1700 Main Street Santa Monica, California 90406 name-27: Prof. D. B. Gillies Dept. of Computer Science University of Illinois Urbana, Illinois 61801 name-27a: Greg Chesson Dept. of Computer Science University of Illinois Urbana, Illinois 61801 name-28: Mr John Vanderford Institute for Physical Sciences The University of Texas at Dallas PO Box 688 Richardson, Texas 75080 name-29: Prof. E. Milgrom Faculte des Sciences Appliquees Unite D'Informatique Universite Catholique de Louvain Chenin Du Cyclotron 2 1348 Louvain-La-Neuve, Belgique name-30: Prof C.J. Karzmark Dept of Radiology Stanford University School of Medicine 300 Pasteur Drive Stanford, California 94305 name-31: Mr. Travis Wood University of Alabama in Birmingham 522 Spain, UAB University Station Birmingham, Alabama 35294 name-32: Mr. William C. Ripperger Knox College Computer Center Knox College Galesburg, Ill 61401 name-33: Mr. J. Tansley Medical Computing Group Medical School University of Edinbourgh Teviot Place Edinburgh EH8 9A6, Scotland name-34: Mr. Belton E. Allen Instructor of Computer Science Naval Postgraduate School Monterey, California 93940 name-35: Prof. James D. Foley University of North Carolina at Chapel Hill New West Hall Chapel Hill, North Carolina name-36: Mr. Dustin H. Heuston The Spence School 22 E. 91st St. New York, New York 10028 name-37: Mr. T. C. Stevens Computer Research Dept University of Toronto Toronto, Canada M5S 1A1 name-38: R. M. Kavanaugh Dept of Computational Science University of Sakatchewan Saskatoon, S7N 0W0 Canada name-39: D. R. McNeil Statistical Computing Lab Princeton University Princeton, N.J. 08540 name-40: H. L. Counts, Jr. Purchasing Denison University P.O. Box 119 Granville, Ohio 43023 name-41: H. Bellmar Minuteman Regional Vocational High School District 758 Merrett Road Lexington, Mass 02173 name-42: James Curry IASSA 2361 Laxenburg Vienna, Austria name-43: Carl Henry Computer Center Carleton College Northfield, Minn 55057 name-44: D. W. de Bakker Dept. of Computer Science Foundation Mathematisch Centrum 2e Boerhaavestraar 49 Amsterdam 1005, The Netherlands name-45: S. Grodstein East Brunswick High School 22 Milltown Rd. East Brunswick, NJ 08816 name-46: C. W. Tan Division of Engineering The Cooper Union Cooper Square New York, NY 10003 name-47: H. S. Eisenstein University of South Carolina Columbia, SC 29208 name-48: R. Whitfeld University of New South Wales PO Box 1 Kensington, NSW Austrialia 2D33 name-49: J. van den Bas Katholieke Universiteit, Toernooiveld Nijmegen, The Netherlands name-50: P. L. De Souza Dept of Elictrical Engineering Heriot-Watt University 31-35 Grassmarket Edinburgh EH12H5 Scotland name-51: R. J. Collins Dept of Computer Science University of Manitoba Winnipeg, Manitoba, Canada R3T2N2 From aap at papnet.eu Thu Jul 13 04:09:46 2023 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 12 Jul 2023 20:09:46 +0200 Subject: [TUHS] B compiler restored Message-ID: So there's been quite a bit of talk about B recently (mostly from my side) and right now I feel that I've reach an interesting enough milestone to warrant a separate thread for this here. First of all, I want to stress that this is still WIP, but everything can be found here now: https://github.com/aap/b/tree/master/unix1_bdir In this repo you will find the following: - bc and ba that can build themselves (I've included .s files so everything can be bootstrapped easily). - libb and bilib in source form from object/library and binary files of the s2 tape - brt1 and brt2 restored from binary files of the s2 tape - olibb, obilib and obrt1, older versions of the above - a version of ba that does not generate threaded code but an interpreted code more like the pdp-7 code. ken told me such a thing existed at one point and indeed it is the only way to fit the compiler into 8kb/4kw - an implementation of this interpreted code. With this bc and ba fit into 8kb Note I have only tested this under apout so far. The version I used [1] needed two tweaks, but see my README. With this I was able to build the recently reversed B programs [2] and produce exact matches to the originals (modulo assembler differences). In that process I found a few mistakes I made, now the programs are exact. I want to thank everyone who was of help in this endeavour in one way or another: Ken Thompson, Phil Budne, Robert Swierczek, Steve Johnson, Warren Toomey What's left to do now is to actually run this under UNIX v1 proper, preferably even on a real machine. I've been too lazy for that so far. Also there are inaccuracies and unknowns in the compiler and assembler. Right now the intermediate code is a binary code that's easy to generate and to parse, but if I understood ken correctly the intermediate code was more like something the PDP-7 assembler could deal with. I'm also rather unsure how to handle the conditional ?: operator. The printf.o file shows that it produces labels that are in line with all the other labels. Now the C compiler uses labels starting at L10000 for the ones generated in the second pass. So it *feels* like the conditional should be generated by bc directly and not by ba but this leads to other problems, which I won't go into detail now. Finally the code should probably be a bit closer to the C compiler than it currently is. Cheers, Angelo [1] https://github.com/philbudne/pdp11-B/tree/pb/tools/apout [2] http://squoze.net/B/programs/ From lars at nocrew.org Thu Jul 13 14:42:44 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 13 Jul 2023 04:42:44 +0000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: <7w351uu8ou.fsf@junk.nocrew.org> (Lars Brinkhoff's message of "Tue, 11 Jul 2023 08:57:37 +0000") References: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> <7w351uu8ou.fsf@junk.nocrew.org> Message-ID: <7wr0pcqv5n.fsf@junk.nocrew.org> > Sebastien F4GRX wrote: >> lett9 is to M. Carpenter (unknown to me) at the european CERN ! > Seems to be Brian Carpenter. I'll let him know about this. He wrote back with a short essay about this: "A Letter from Ritchie" https://www.cs.auckland.ac.nz/~brian/LetterFromRitchie.pdf From f4grx at f4grx.net Thu Jul 13 20:00:49 2023 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Thu, 13 Jul 2023 12:00:49 +0200 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: <7wr0pcqv5n.fsf@junk.nocrew.org> References: <03163d32-5abe-58dd-79a4-f90244e3cea1@f4grx.net> <7w351uu8ou.fsf@junk.nocrew.org> <7wr0pcqv5n.fsf@junk.nocrew.org> Message-ID: Hi, Le 13/07/2023 à 06:42, Lars Brinkhoff a écrit : >> Sebastien F4GRX wrote: >>> lett9 is to M. Carpenter (unknown to me) at the european CERN ! >> Seems to be Brian Carpenter. I'll let him know about this. > He wrote back with a short essay about this: "A Letter from Ritchie" > > https://www.cs.auckland.ac.nz/~brian/LetterFromRitchie.pdf That was fascinating to read! Thank you for reporting! Sebastien From jsg at jsg.id.au Fri Jul 14 02:57:06 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 14 Jul 2023 02:57:06 +1000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: On Tue, Jul 11, 2023 at 10:44:33AM +1000, Warren Toomey via TUHS wrote: > All, way back when, Dennis sent me some DECtape images to look after. I've > put some of them in the Unix Archive (the s1 and s2 tapes) as they contained > Unix source code or binaries. The others I kept aside as they didn't contain > Unix code, or they were potentially sensitive. > > Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might > contain fragments of B source code or B binaries. I passed the extra tapes > on to him, and he has found some very interesting nuggets from the time > period when B -> NB -> C. > > So, to help provide the context around Angelo's work, I've decided to put > all the tapes that Dennis gave me here: > > https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ > > Cheers, Warren Thank-you to all involved. Interesting that this has a version of "The UNIX Time-Sharing System" paper with timestamps close to the SOSP presentation. UnixEditionZero-Threshold_OCR.pdf 1971 draft Symposium on Operating System Principles, October 15-17 1973 proceedings only have an abstract dmr_tapes/dmr2/tp/paper/p1 Nov 1973 "about 20 installations have been put into service" (same number given in fourth edition manual also dated Nov 1973) "Files are named by sequences of eight or fewer characters" tuhs/Documentation/Papers/unix_cacm74.pdf July 1974 "about 40 installations have been put into service" "Files are named by sequences of 14 or fewer characters" tuhs/Distributions/Research/Dennis_v6/v6doc.tar.gz unix/p1 Jun 1975 "about 100 installations have been put into service" From tuhs at tuhs.org Fri Jul 14 05:02:16 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 13 Jul 2023 19:02:16 +0000 Subject: [TUHS] Bell COBOL Environment? Message-ID: Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product. Are these the earliest AT&T endorsed COBOL solutions for UNIX or were there other efforts either promoted by Bell or even perhaps developed locally that were in any use before this version? Or otherwise is there any other family of ubiquitous UNIX COBOL tools that was in use in the 70s and early 80s, before the timeframe of this document? Additionally is anyone aware of any surviving code or binaries of either of these or other, earlier efforts at COBOL on UNIX? I have no goal for this information in mind yet, but just gathering details at this point. Thanks all! - Matt G. [1] - http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf From clemc at ccc.com Fri Jul 14 06:34:06 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 13 Jul 2023 16:34:06 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: Matt - I never had direct (user) experience with it. I saw a demo of LPI's product at a trade show. It might have run on Ultrix, but if it did, I have no memory of it being in the test suite we used for releases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not. In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it. But there were bundled applications for different markets (running a dentist's office, car dealership, store, restaurant, *etc*..) that ran on small UNIX boxes and used those DBs. What I remember was that only a few firms were offering Cobol for UNIX (I think that IBM, DEC, DG, and maybe NCR had them from previous OSses), but the new generation of UNIX boxes did not - although 3rd parties like LPI sometimes offered them. Since it looks like AT&T is naming it/offering it with their product, that is another example of AT&T management missing the market. AT&T's management (Charlie Brown) was interested in going after IBM and probably thought that Cobol was important if they sold to IBM shops. The problem was that except for some really large 'Big Blue' places that never bothered tossing out Cobol (like Wall Street and some insurance companies --* i.e.* early IBM computer users), I always thought that writing *new code in Cobol or trying to port old code *was not done that often because the firms that were switching from Mainframes to UNIX were generally tossing out their homegrown applications at the same time and replacing the entire suite with something like SAP, BAAN, or Oracle APS that were networked, well integrated into things like PCs, used ASCII, *etc*. - *i.e*. using the replacement as the time to really upgrade their entire back office and possibly moving away from Big Blue based - which was not cost-effective (particularly for smaller firms). Another point was the Big 8 accounting firms started offering services that used the minis and UNIX boxes with SAP/BAAN/Oracle APS). Finally, I may miss remembering WRT to LPR-Cobol, but it was similar to today's Java in that it compiled into an interpreter. Plus, the impression I always had was that it was not designed for practical large-scale use or performance. BTW: this is a different behavior from the scientific world. From mini to supercomputers, in most cases, scientific users could not toss out their scientific computing tools and replace them with COTS alternatives (*i.e*., no firm like SAP, BAAN or Oracle providing "packaged" solutions for a bank or business). But since most of the production apps being used came with sources or the few that were commercial (Cadum, CATIA, Ansys *etc*..), it was possible to recompile and move things - so people did or the IVSs did. Even today, as one of my former colleagues put it, any sr computer system manager that ignores Fortran will eventually get fired for incompetence as it is still #1. ᐧ ᐧ On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS wrote: > Reading through [1], there are documents offered by AT&T for the "Level II > COBOL" system, which some further research indicates is a product from > Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which > appears to be a Language Processor Inc. product. > > Are these the earliest AT&T endorsed COBOL solutions for UNIX or were > there other efforts either promoted by Bell or even perhaps developed > locally that were in any use before this version? Or otherwise is there > any other family of ubiquitous UNIX COBOL tools that was in use in the 70s > and early 80s, before the timeframe of this document? > > Additionally is anyone aware of any surviving code or binaries of either > of these or other, earlier efforts at COBOL on UNIX? I have no goal for > this information in mind yet, but just gathering details at this point. > Thanks all! > > - Matt G. > > [1] - > http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 14 06:50:43 2023 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Thu, 13 Jul 2023 22:50:43 +0200 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: I have a bizarre memory of running COBOL on Microsoft/SCO Xenix System V porting and translating an application for petrol pumps, of all things, from English to Italian. The license for the software was photocopied and not from either Microsoft nor SCO (not that those licenses were original either… Italy in the ‘80s…). Having said this I might have been using the Xenix box as a terminal into something else although I doubt it as my UUCP node and my terminal were not that PC. It was ages ago and I was traumatised by both COBOL and the application. From kennethgoodwin56 at gmail.com Fri Jul 14 07:41:36 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Thu, 13 Jul 2023 17:41:36 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: Would your S database perhaps be Sybase?? It is that era of time. On Thu, Jul 13, 2023, 4:35 PM Clem Cole wrote: > Matt - I never had direct (user) experience with it. I saw a demo of > LPI's product at a trade show. It might have run on Ultrix, but if it did, > I have no memory of it being in the test suite we used for releases. Also, > I do not remember if LPI-Colbol was attached to a specific DB > implementation or not. In those days, there were a number of them besides > Ingres - Informix, IBM's DB2, and one that started with an S - which later > was sold to Microsoft to become SQL-server to name a few, and that may have > been part of it. But there were bundled applications for different markets > (running a dentist's office, car dealership, store, restaurant, *etc*..) > that ran on small UNIX boxes and used those DBs. > > What I remember was that only a few firms were offering Cobol for UNIX (I > think that IBM, DEC, DG, and maybe NCR had them from previous OSses), but > the new generation of UNIX boxes did not - although 3rd parties like LPI > sometimes offered them. Since it looks like AT&T is naming it/offering it > with their product, that is another example of AT&T management missing the > market. AT&T's management (Charlie Brown) was interested in going after > IBM and probably thought that Cobol was important if they sold to IBM shops. > > The problem was that except for some really large 'Big Blue' places that > never bothered tossing out Cobol (like Wall Street and some insurance > companies --* i.e.* early IBM computer users), I always thought that > writing *new code in Cobol or trying to port old code *was not done that > often because the firms that were switching from Mainframes to UNIX were > generally tossing out their homegrown applications at the same time and > replacing the entire suite with something like SAP, BAAN, or Oracle > APS that were networked, well integrated into things like PCs, used ASCII, > *etc*. - *i.e*. using the replacement as the time to really upgrade their > entire back office and possibly moving away from Big Blue based - which was > not cost-effective (particularly for smaller firms). Another point was > the Big 8 accounting firms started offering services that used the minis > and UNIX boxes with SAP/BAAN/Oracle APS). Finally, I may miss remembering > WRT to LPR-Cobol, but it was similar to today's Java in that it compiled > into an interpreter. Plus, the impression I always had was that it was not > designed for practical large-scale use or performance. > > BTW: this is a different behavior from the scientific world. From mini to > supercomputers, in most cases, scientific users could not toss out their > scientific computing tools and replace them with COTS alternatives (*i.e*., > no firm like SAP, BAAN or Oracle providing "packaged" solutions for a bank > or business). But since most of the production apps being used came with > sources or the few that were commercial (Cadum, CATIA, Ansys *etc*..), it > was possible to recompile and move things - so people did or the IVSs did. > Even today, as one of my former colleagues put it, any sr computer system > manager that ignores Fortran will eventually get fired for incompetence as > it is still #1. > ᐧ > ᐧ > > On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS wrote: > >> Reading through [1], there are documents offered by AT&T for the "Level >> II COBOL" system, which some further research indicates is a product from >> Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which >> appears to be a Language Processor Inc. product. >> >> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were >> there other efforts either promoted by Bell or even perhaps developed >> locally that were in any use before this version? Or otherwise is there >> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s >> and early 80s, before the timeframe of this document? >> >> Additionally is anyone aware of any surviving code or binaries of either >> of these or other, earlier efforts at COBOL on UNIX? I have no goal for >> this information in mind yet, but just gathering details at this point. >> Thanks all! >> >> - Matt G. >> >> [1] - >> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Fri Jul 14 07:42:19 2023 From: nobozo at gmail.com (Jon Forrest) Date: Thu, 13 Jul 2023 14:42:19 -0700 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> You’re thinking of Sybase. That’s where the name “SqlServer” came from. Sybase sold a source code license to Microsoft that included the right to use the name. (I was a developer at Sybase in the VMS group in the late 1980s and early 1990s) Jon Sent from my iPhone > On Jul 13, 2023, at 1:35 PM, Clem Cole wrote: > >  > Matt - I never had direct (user) experience with it. Ireleases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not. In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 14 08:35:58 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 13 Jul 2023 22:35:58 +0000 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> References: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> Message-ID: The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL. Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN. Would that be a fair characterization? Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical. - Matt G. ------- Original Message ------- On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest wrote: > You’re thinking of Sybase. That’s where the name “SqlServer” came from. Sybase sold a source code license to Microsoft that included the right to use the name. > > (I was a developer at Sybase in the VMS group in the late 1980s and early 1990s) > > Jon > > Sent from my iPhone > >> On Jul 13, 2023, at 1:35 PM, Clem Cole wrote: > >>  >> Matt - I never had direct (user) experience with it. Ireleases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not. In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jul 14 09:02:33 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 13 Jul 2023 19:02:33 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: Yes. Thank you. On Thu, Jul 13, 2023 at 5:41 PM Kenneth Goodwin wrote: > Would your S database perhaps be Sybase?? > > It is that era of time. > > On Thu, Jul 13, 2023, 4:35 PM Clem Cole wrote: > >> Matt - I never had direct (user) experience with it. I saw a demo of >> LPI's product at a trade show. It might have run on Ultrix, but if it did, >> I have no memory of it being in the test suite we used for releases. Also, >> I do not remember if LPI-Colbol was attached to a specific DB >> implementation or not. In those days, there were a number of them besides >> Ingres - Informix, IBM's DB2, and one that started with an S - which later >> was sold to Microsoft to become SQL-server to name a few, and that may have >> been part of it. But there were bundled applications for different markets >> (running a dentist's office, car dealership, store, restaurant, *etc*..) >> that ran on small UNIX boxes and used those DBs. >> >> What I remember was that only a few firms were offering Cobol for UNIX (I >> think that IBM, DEC, DG, and maybe NCR had them from previous OSses), but >> the new generation of UNIX boxes did not - although 3rd parties like LPI >> sometimes offered them. Since it looks like AT&T is naming it/offering it >> with their product, that is another example of AT&T management missing the >> market. AT&T's management (Charlie Brown) was interested in going after >> IBM and probably thought that Cobol was important if they sold to IBM shops. >> >> The problem was that except for some really large 'Big Blue' places that >> never bothered tossing out Cobol (like Wall Street and some insurance >> companies --* i.e.* early IBM computer users), I always thought that >> writing *new code in Cobol or trying to port old code *was not done that >> often because the firms that were switching from Mainframes to UNIX were >> generally tossing out their homegrown applications at the same time and >> replacing the entire suite with something like SAP, BAAN, or Oracle >> APS that were networked, well integrated into things like PCs, used ASCII, >> *etc*. - *i.e*. using the replacement as the time to really upgrade >> their entire back office and possibly moving away from Big Blue based - >> which was not cost-effective (particularly for smaller firms). Another >> point was the Big 8 accounting firms started offering services that used >> the minis and UNIX boxes with SAP/BAAN/Oracle APS). Finally, I may miss >> remembering WRT to LPR-Cobol, but it was similar to today's Java in that it >> compiled into an interpreter. Plus, the impression I always had was that >> it was not designed for practical large-scale use or performance. >> >> BTW: this is a different behavior from the scientific world. From mini >> to supercomputers, in most cases, scientific users could not toss out their >> scientific computing tools and replace them with COTS alternatives (*i.e*., >> no firm like SAP, BAAN or Oracle providing "packaged" solutions for a bank >> or business). But since most of the production apps being used came with >> sources or the few that were commercial (Cadum, CATIA, Ansys *etc*..), >> it was possible to recompile and move things - so people did or the IVSs >> did. Even today, as one of my former colleagues put it, any sr computer >> system manager that ignores Fortran will eventually get fired for >> incompetence as it is still #1. >> ᐧ >> ᐧ >> >> On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS wrote: >> >>> Reading through [1], there are documents offered by AT&T for the "Level >>> II COBOL" system, which some further research indicates is a product from >>> Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which >>> appears to be a Language Processor Inc. product. >>> >>> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were >>> there other efforts either promoted by Bell or even perhaps developed >>> locally that were in any use before this version? Or otherwise is there >>> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s >>> and early 80s, before the timeframe of this document? >>> >>> Additionally is anyone aware of any surviving code or binaries of either >>> of these or other, earlier efforts at COBOL on UNIX? I have no goal for >>> this information in mind yet, but just gathering details at this point. >>> Thanks all! >>> >>> - Matt G. >>> >>> [1] - >>> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf >>> >> -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Fri Jul 14 09:19:52 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 13 Jul 2023 19:19:52 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: Well if you guys use Linux you can always download open source "gnucobol" to experiment with. Ken On Thu, Jul 13, 2023 at 7:02 PM Clem Cole wrote: > Yes. Thank you. > > On Thu, Jul 13, 2023 at 5:41 PM Kenneth Goodwin < > kennethgoodwin56 at gmail.com> wrote: > >> Would your S database perhaps be Sybase?? >> >> It is that era of time. >> >> On Thu, Jul 13, 2023, 4:35 PM Clem Cole wrote: >> >>> Matt - I never had direct (user) experience with it. I saw a demo of >>> LPI's product at a trade show. It might have run on Ultrix, but if it did, >>> I have no memory of it being in the test suite we used for releases. Also, >>> I do not remember if LPI-Colbol was attached to a specific DB >>> implementation or not. In those days, there were a number of them besides >>> Ingres - Informix, IBM's DB2, and one that started with an S - which later >>> was sold to Microsoft to become SQL-server to name a few, and that may have >>> been part of it. But there were bundled applications for different markets >>> (running a dentist's office, car dealership, store, restaurant, *etc*..) >>> that ran on small UNIX boxes and used those DBs. >>> >>> What I remember was that only a few firms were offering Cobol for UNIX >>> (I think that IBM, DEC, DG, and maybe NCR had them from previous OSses), >>> but the new generation of UNIX boxes did not - although 3rd parties like >>> LPI sometimes offered them. Since it looks like AT&T is naming it/offering >>> it with their product, that is another example of AT&T management missing >>> the market. AT&T's management (Charlie Brown) was interested in going >>> after IBM and probably thought that Cobol was important if they sold to IBM >>> shops. >>> >>> The problem was that except for some really large 'Big Blue' places that >>> never bothered tossing out Cobol (like Wall Street and some insurance >>> companies --* i.e.* early IBM computer users), I always thought that >>> writing *new code in Cobol or trying to port old code *was not done >>> that often because the firms that were switching from Mainframes to UNIX >>> were generally tossing out their homegrown applications at the same time >>> and replacing the entire suite with something like SAP, BAAN, or Oracle >>> APS that were networked, well integrated into things like PCs, used ASCII, >>> *etc*. - *i.e*. using the replacement as the time to really upgrade >>> their entire back office and possibly moving away from Big Blue based - >>> which was not cost-effective (particularly for smaller firms). Another >>> point was the Big 8 accounting firms started offering services that used >>> the minis and UNIX boxes with SAP/BAAN/Oracle APS). Finally, I may miss >>> remembering WRT to LPR-Cobol, but it was similar to today's Java in that it >>> compiled into an interpreter. Plus, the impression I always had was that >>> it was not designed for practical large-scale use or performance. >>> >>> BTW: this is a different behavior from the scientific world. From mini >>> to supercomputers, in most cases, scientific users could not toss out their >>> scientific computing tools and replace them with COTS alternatives ( >>> *i.e*., no firm like SAP, BAAN or Oracle providing "packaged" solutions >>> for a bank or business). But since most of the production apps being used >>> came with sources or the few that were commercial (Cadum, CATIA, Ansys >>> *etc*..), it was possible to recompile and move things - so people did >>> or the IVSs did. Even today, as one of my former colleagues put it, any sr >>> computer system manager that ignores Fortran will eventually get fired for >>> incompetence as it is still #1. >>> ᐧ >>> ᐧ >>> >>> On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS wrote: >>> >>>> Reading through [1], there are documents offered by AT&T for the "Level >>>> II COBOL" system, which some further research indicates is a product from >>>> Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which >>>> appears to be a Language Processor Inc. product. >>>> >>>> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were >>>> there other efforts either promoted by Bell or even perhaps developed >>>> locally that were in any use before this version? Or otherwise is there >>>> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s >>>> and early 80s, before the timeframe of this document? >>>> >>>> Additionally is anyone aware of any surviving code or binaries of >>>> either of these or other, earlier efforts at COBOL on UNIX? I have no goal >>>> for this information in mind yet, but just gathering details at this >>>> point. Thanks all! >>>> >>>> - Matt G. >>>> >>>> [1] - >>>> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf >>>> >>> -- > Sent from a handheld expect more typos than usual > -- End of line JOB TERMINATED -->> Okey Dokey, OK Boss -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Jul 14 09:20:01 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 13 Jul 2023 17:20:01 -0600 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> Message-ID: Yes. And the need for COBOL also was mirrored in the micro world of the time (at least the early 80s). Every micro with enough power seemed to have a COBOL, but all of the offerings dried up before long because although COBOL was a 'no brainer must have' for business, selling it into this new market proved to be too hard. At least that's the impression I was left with at the time, and also what the professors that taught my 'language survey' course said about it... You can take the raw code, but the underlying environment and services just weren't there, so the raw code turned out to be useless most of the time (I also got some $ re-writing a few hundred lines of COBOL business logic for a local business that found that easier for a company that had, as luck would have it, a PDP-11 database written in FORTRAN running on RT-11 or RSTS/E). Warner On Thu, Jul 13, 2023 at 4:36 PM segaloco via TUHS wrote: > The conclusion I'm coming to from what has been said thus far is that > people who were moving from COBOL and the mainframe world to UNIX didn't > have as much of a need for COBOL. Since that transition often involved > change in enough other aspects of an operation, moving to UNIX with the > same COBOL applications just wasn't the path to success for most folks, as > opposed to folks deeply invested in FORTRAN. Would that be a fair > characterization? > > Thanks for the feedback by the way, one of the matters I'm trying to suss > out is what a typical COBOL environment on UNIX would've looked like back > when, and what it sounds like is a COBOL environment on UNIX was anything > but typical. > > - Matt G. > ------- Original Message ------- > On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest > wrote: > > You’re thinking of Sybase. That’s where the name “SqlServer” came from. > Sybase sold a source code license to Microsoft that included the right to > use the name. > > (I was a developer at Sybase in the VMS group in the late 1980s and early > 1990s) > > Jon > > Sent from my iPhone > > On Jul 13, 2023, at 1:35 PM, Clem Cole wrote: > >  > Matt - I never had direct (user) experience with it. Ireleases. Also, I > do not remember if LPI-Colbol was attached to a specific DB implementation > or not. In those days, there were a number of them besides Ingres - > Informix, IBM's DB2, and one that started with an S - which later was sold > to Microsoft to become SQL-server to name a few, and that may have been > part of it. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Jul 14 10:20:05 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 13 Jul 2023 17:20:05 -0700 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> Message-ID: Fortune Systems sold COBOL-74 along with a bunch of business applications. Don't recall who we got it from. There was also SIBOL (from an Irish company) that could run thousands DIBOL programs under Unix (DIBOL was DEC's own business oriented language). Speaking of Fortune, I recently stumbled upon this short clip where Stanley Kubrick (in 1983) says he wants a Fortune Computer for Christmas because it runs the most advanced operating system: Unix! https://www.youtube.com/watch?v=54hrLTpsO5g > On Jul 13, 2023, at 4:20 PM, Warner Losh wrote: > > Yes. And the need for COBOL also was mirrored in the micro world of the time (at least the early 80s). Every micro with enough power seemed to have a COBOL, but all of the offerings dried up before long because although COBOL was a 'no brainer must have' for business, selling it into this new market proved to be too hard. At least that's the impression I was left with at the time, and also what the professors that taught my 'language survey' course said about it... You can take the raw code, but the underlying environment and services just weren't there, so the raw code turned out to be useless most of the time (I also got some $ re-writing a few hundred lines of COBOL business logic for a local business that found that easier for a company that had, as luck would have it, a PDP-11 database written in FORTRAN running on RT-11 or RSTS/E). > > Warner > > On Thu, Jul 13, 2023 at 4:36 PM segaloco via TUHS > wrote: >> The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL. Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN. Would that be a fair characterization? >> >> Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical. >> >> - Matt G. >> ------- Original Message ------- >> On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest > wrote: >> >>> You’re thinking of Sybase. That’s where the name “SqlServer” came from. Sybase sold a source code license to Microsoft that included the right to use the name. >>> >>> (I was a developer at Sybase in the VMS group in the late 1980s and early 1990s) >>> >>> Jon >>> >>> Sent from my iPhone >>> >>>> On Jul 13, 2023, at 1:35 PM, Clem Cole > wrote: >>>> >>>>  >>>> Matt - I never had direct (user) experience with it. Ireleases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not. In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Fri Jul 14 11:05:08 2023 From: davida at pobox.com (David Arnold) Date: Fri, 14 Jul 2023 11:05:08 +1000 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: Message-ID: > On 14 Jul 2023, at 08:36, segaloco via TUHS wrote: … > Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, I think that’s fair, and certainly true of the COBOL system I knew (late 80s). For us, a move to Unix would have been a complete re-architect, re-code, and replacement of basically all hardware. 3270 terminals, LU6.2 networking, CICS transaction monitor, ISAM datasets, all the batch jobs and their JCL, to say nothing of the two (redundant) 3090’s and the sea of DASD, monster printers, etc. The retraining or replacement of staff would have been overwhelming as well. The closest I could get was writing some CICS transactions in C, but it wasn’t worth the uphill battle. The only solution was to be acquired by a more modern company and throw the lot out! d From ads at salewski.email Fri Jul 14 11:16:46 2023 From: ads at salewski.email (Alan D. Salewski) Date: Thu, 13 Jul 2023 21:16:46 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> Message-ID: <65faa3e0-d3aa-4980-9175-5b3de1cdcf2f@app.fastmail.com> On Thu, Jul 13, 2023, at 20:20, Bakul Shah wrote: [...] > > Speaking of Fortune, I recently stumbled upon this short clip where > Stanley Kubrick (in 1983) says he wants a Fortune Computer for > Christmas because it runs the most advanced operating system: Unix! > > https://www.youtube.com/watch?v=54hrLTpsO5g That's a great clip, Bakul; thanks for sharing it. -Al -- a l a n d. s a l e w s k i ads at salewski.email salewski at att.net https://github.com/salewski From clemc at ccc.com Fri Jul 14 11:45:42 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 13 Jul 2023 21:45:42 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> Message-ID: Below On Thu, Jul 13, 2023 at 6:36 PM segaloco wrote: > The conclusion I'm coming to from what has been said thus far is that > people who were moving from COBOL and the mainframe world to UNIX didn't > have as much of a need for COBOL. Since that transition often involved > change in enough other aspects of an operation, moving to UNIX with the > same COBOL applications just wasn't the path to success for most folks, as > opposed to folks deeply invested in FORTRAN. Would that be a fair > characterization? > Yes. That was certainly my experience. > > Thanks for the feedback by the way, one of the matters I'm trying to suss > out is what a typical COBOL environment on UNIX would've looked like back > when, and what it sounds like is a COBOL environment on UNIX was anything > but typical. > I think that is fair. There were likely multiple reasons why that path started must likely because Unix was rooted in the CS research and the engineering communities which was pretty far from what traditional production Business/COBOL shops did at the time. By the time business folks started to notice Unix other economic changes had appeared also such as firms like SAP/BAAN/Oracle, plus Im not sure the big8 in those days could spell Unix so business folks didn’t have a reason to pay attention. Clem > > - Matt G. > ------- Original Message ------- > > On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest > wrote: > > You’re thinking of Sybase. That’s where the name “SqlServer” came from. > Sybase sold a source code license to Microsoft that included the right to > use the name. > > (I was a developer at Sybase in the VMS group in the late 1980s and early > 1990s) > > Jon > > Sent from my iPhone > > On Jul 13, 2023, at 1:35 PM, Clem Cole wrote: > >  > Matt - I never had direct (user) experience with it. Ireleases. Also, I > do not remember if LPI-Colbol was attached to a specific DB implementation > or not. In those days, there were a number of them besides Ingres - > Informix, IBM's DB2, and one that started with an S - which later was sold > to Microsoft to become SQL-server to name a few, and that may have been > part of it. > > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jul 14 12:14:36 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Jul 2023 22:14:36 -0400 Subject: [TUHS] Bell COBOL Environment? In-Reply-To: References: <0CCC47C3-950F-424B-AF6D-0F0DC08C53E5@gmail.com> Message-ID: On Thu, Jul 13, 2023 at 6:36 PM segaloco via TUHS wrote: > The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL. Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN. Would that be a fair characterization? Echoing what others have said, that seems reasonable to me. Don't tell the mainframe infosec folks about this; they get really touchy about defending COBOL's honor for some reason I don't quite understand. > Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical. A way to think about COBOL is that it's like a DSL for business transaction processing, but is itself a small part of the overall offering. In the mainframe world, it's often intimately tied to things like CICS, ISAM, VTAM and 3270 access methods, SNA, and so on, and in that sense the language itself is a rather small part of the ecosystem. Transferring everything into a new environment (e.g., on Unix) raises a lot of questions about the surrounding technologies and their non-availability, and ultimately just having the language by itself isn't terribly useful if you don't have all the other stuff as well. Also, COBOL is just a terrible language. - Dan C. From jsg at jsg.id.au Fri Jul 14 15:31:43 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 14 Jul 2023 15:31:43 +1000 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: On Fri, Jul 14, 2023 at 02:57:06AM +1000, Jonathan Gray wrote: > On Tue, Jul 11, 2023 at 10:44:33AM +1000, Warren Toomey via TUHS wrote: > > All, way back when, Dennis sent me some DECtape images to look after. I've > > put some of them in the Unix Archive (the s1 and s2 tapes) as they contained > > Unix source code or binaries. The others I kept aside as they didn't contain > > Unix code, or they were potentially sensitive. > > > > Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might > > contain fragments of B source code or B binaries. I passed the extra tapes > > on to him, and he has found some very interesting nuggets from the time > > period when B -> NB -> C. > > > > So, to help provide the context around Angelo's work, I've decided to put > > all the tapes that Dennis gave me here: > > > > https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ > > > > Cheers, Warren > > Thank-you to all involved. > > Interesting that this has a version of > "The UNIX Time-Sharing System" paper with timestamps close to the > SOSP presentation. > > UnixEditionZero-Threshold_OCR.pdf 1971 draft > > Symposium on Operating System Principles, October 15-17 1973 > proceedings only have an abstract The ACM online archive only has the abstract https://dl.acm.org/doi/10.1145/800009.808045 but google books shows fragments of more in searches https://books.google.com/books?id=TxNRAQAAIAAJ > > dmr_tapes/dmr2/tp/paper/p1 Nov 1973 > "about 20 installations have been put into service" > (same number given in fourth edition manual also dated Nov 1973) > "Files are named by sequences of eight or fewer characters" > > tuhs/Documentation/Papers/unix_cacm74.pdf July 1974 > "about 40 installations have been put into service" > "Files are named by sequences of 14 or fewer characters" > > tuhs/Distributions/Research/Dennis_v6/v6doc.tar.gz unix/p1 Jun 1975 > "about 100 installations have been put into service" DECUS: Proceedings of the Digital Equipment Computer Users Society 1977: Vol 3 Iss 5 https://archive.org/details/sim_digital-equipment-computer-users-society-transactions_1977_3_5 "about 250 installations have been put into service" tuhs/Documentation/Papers/BSTJ/bstj57-6-1905.pdf July/Aug 1978 "over 600 installations have been put into service" tuhs/Distributions/Research/Henry_Spencer_v7/v7.tar.gz usr/doc/cacm Jan 1979 "over 600 installations have been put into service" From tuhs at tuhs.org Fri Jul 14 18:46:51 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Fri, 14 Jul 2023 10:46:51 +0200 Subject: [TUHS] Bell COBOL Environment? Message-ID: <8D381C20-4C6F-47E5-AD54-04D9D639AB25@planet.nl> > Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product. Ryan-McFarland comes to mind: in my recollection they were the leading Cobol on small machines in the early 80’s. Ryan-McFarland’s predecessor company Digitek was contracted to do the PL/I compiler for Multics, but failed. It seems they later did Bell Labs PL/I (says https://en.wikipedia.org/wiki/Digitek). I think they did a Unix version of their Cobol in the mid/late 80’s as well. A few years ago I tried to find out more about RM-Cobol as it existed in the late 70’s and early 80’s, but with little success. As a product it survived till the present day under the ownership of Micro-Focus and most web mentions are for more recent versions. It would seem to me that compilers on machines with small memories and word sizes in the 60’s, 70’s and even 80’s tended to compile to a virtual machine / intermediate code -- sometimes with the option to compile to native from there. Think BCPL and o-code, Pascal and p-code, the Amsterdam Compiler Kit and m-code, the Microsoft “revenue bomb” p-code C compiler, etc. According to the above Wikipedia article RM-Cobol used the same approach. I did once see the source for another 80’s Cobol compiler and it compiled to a virtual machine with 60-bit words. By the way, I loved the recent posts on B and NB. THUS at its best! From will.senn at gmail.com Sun Jul 16 12:06:18 2023 From: will.senn at gmail.com (Will Senn) Date: Sat, 15 Jul 2023 21:06:18 -0500 Subject: [TUHS] Posted a video on installing and running v7 Message-ID: Hi All, I got some questions recently about getting v7 working, so I fired up OBS to create a video walkthrough of the install process and first steps (it's basically following my v7 note, but hey some folks dig video). The video is totally amateur hour, but it was fun. I never get tired of logging in as dmr, writing hello.c, running cc, running hello and watch the magic of hello, world appear on "screen". As a reminder - the note (and thus, the video) walks the user through installing OpenSIMH (including pdp11), building a tape image, installing to disk from tape, booting off the disk, building and using a DZ-11 as a telnet listener on 16 lines, adding a user, running learn, and piddly stuff like setting baud, delays, and such. Not a lot of hand-holding, but some. When I get around to it, I'll probably update the note to add additional test environments (I'm pretty sure it works anywhere OpenSIMH does, but some folks like to see there system or one kinda like it in the list of tested systems). I'm running LMDE5 and Debian 12 Bookworm these days, so I know they work there in addition to pretty much any Linux Mint, MX Linux, FreeBSD, Mac OS, etc. I'm still in awe of Hayle and Ritchie's Setting Up Unix - Seventh Edition as the basis of my note - 44 y.o. and counting... for holding up so well. The blog: https://decuser.github.io The blog post: https://decuser.github.io/unix/research-unix/v7/videos/2023/07/14/installing-and-using-research-unix-v7-in-open-simh-video.html The note blog post: https://decuser.github.io/unix/research-unix/v7/2022/10/28/installing-and-using-research-unix-v7-in-open-simh-pdp-11-45-and-70-emulators-rev-3.1.html Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Sun Jul 16 12:35:22 2023 From: phil at ultimate.com (Phil Budne) Date: Sat, 15 Jul 2023 22:35:22 -0400 Subject: [TUHS] Some old DECtapes from Dennis Ritchie In-Reply-To: References: Message-ID: <202307160235.36G2ZMcj040231@ultimate.com> On July 11th, Warren wrote: > All, way back when, Dennis sent me some DECtape images to look after. I've > put some of them in the Unix Archive (the s1 and s2 tapes) as they contained > Unix source code or binaries. The others I kept aside as they didn't contain > Unix code, or they were potentially sensitive. > > .... I've decided to put > all the tapes that Dennis gave me here: > > https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ In https://www.tuhs.org/Archive/Applications/Dennis_Tapes/README Are notes (apparently written by DMR): dmr Random stuff from my directory. Most probable dates: 1972. .... pig.b is an interesting artifact: it is a B program that echoes what you type in Pig latin. (Incidentally, there is a translation of this program into C, dated 1978, in a subdirectory that still spins on a disk attached to the Unix machine where I get my mail.) This jiggled a nerve in my brain, that FINALLY connected. The TMG manual in the Multics System-Programmer's Manual by Robert R. Fenichel and M. D. Mcilroy, pub. April 17, 1967 has a sample TMG program to translate english to Pig Latin. https://people.csail.mit.edu/saltzer/Multics/Multics-Documents/MSPM/bn-4-02.670417.tmgl-reference.pdf#page=31 It appears (in translation) as a test to a port of PDP-11 TMG: https://github.com/amakukha/tmg/blob/master/test/086_pig_latin/pig_latin.t I haven't yet compared pig.b to the program in the TMG manual. From henry.r.bent at gmail.com Tue Jul 18 05:43:51 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 17 Jul 2023 15:43:51 -0400 Subject: [TUHS] Research UNIX PDP 11/45 Message-ID: Hello all, I asked this question in a different thread but it may have been bogged down in other discussion so I figured it was worth asking again. What was the hardware configuration of the 11/45 that Research used to implement early UNIX? This would be circa late 1972/earlty 1973. I have found numerous references to it being an early production 11/45, and I assume that it had an RK05, but I cannot find any details about things like memory size and other peripherals. Since the only extant sources are for V1, which was as I understand only run on a singular 11/20, and V5 by which time UNIX had spread it doesn't seem possible to infer a hardware configuration from existing code. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 18 08:13:10 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 17 Jul 2023 18:13:10 -0400 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: References: Message-ID: Henry - the infamous Ken and Dennis picture: https://www.bell-labs.com/usr/dmr/www/ken-and-den.jpg show the 11/20's display. Their is a console display is hidden behind the right most ASR-33 [the console for the 11/20, I think], and Ken is typing to another processor - it's either an 11/40 or 11/45, given the parts of the bezel shown in the picture. The picture also shows 2 RK's, 2 DEC Tape and a Paper Tape read/punch, and the Tek display on the table. The Fifth Edition tape the low.s and conf.c list an 11/40 with drivers for the RK05, KL, DC serial, and the PPT unit. The Sixth edition is the first time we see mch40 and mch45. There is also a rkunix, rpunix and hpunix on the distribution tape. The l.s file shows KL, DEC Tape, 9-Track and RP04 drivers (but no DC-11s). We also see Ken's "sysfix" to deal with the separate I/D space. So ... I'm would have suspected that the first 11/45 had an RP04 as well as at least one RK05, a TM-11 with a 9-track, and the DEC Tape unit. The amount of memory is, of course, unknown. It was pretty expensive in those days, but I would have expected they would have pushed it to the max [256K]. ᐧ On Mon, Jul 17, 2023 at 3:44 PM Henry Bent wrote: > Hello all, > > I asked this question in a different thread but it may have been bogged > down in other discussion so I figured it was worth asking again. > > What was the hardware configuration of the 11/45 that Research used to > implement early UNIX? This would be circa late 1972/earlty 1973. I have > found numerous references to it being an early production 11/45, and I > assume that it had an RK05, but I cannot find any details about things like > memory size and other peripherals. > > Since the only extant sources are for V1, which was as I understand only > run on a singular 11/20, and V5 by which time UNIX had spread it doesn't > seem possible to infer a hardware configuration from existing code. > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jul 18 08:32:43 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 17 Jul 2023 18:32:43 -0400 (EDT) Subject: [TUHS] Research UNIX PDP 11/45 Message-ID: <20230717223243.794B018C09D@mercury.lcs.mit.edu> > From: Henry Bent > What was the hardware configuration of the 11/45 that Research used to > implement early UNIX? .. I have found numerous references to it being > an early production 11/45, and I assume that it had an RK05, but I > cannot find any details about things like memory size and other > peripherals. A good source is the Ken+Dennis picture: https://www.bell-labs.com/usr/dmr/www/picture.html and the caption which Dennis wrote for it. The image is not quite definitive, because there are two machines in that bank of racks: a PDP-11/20, and a PDP-11/45 (mostly hidden behind the right-hand Teletype), and it's not possible to say which of the two machines the various peripherals are attached to. But it seems to have had two RK03's (and an RK11 somewhere to drive them) and an RF11 (no idea how many RS11 drives it had at that point),; a TU56 (and a TC11 somewhere to drive that), and a PC05 (with PC11 controller boards). (There are pages for all these things here: https://gunkies.org/wiki/Category:UNIBUS_Peripherals which include links to the DEC documentation on them.) I'm doing more searching, through documents I recall having additional crumbs; let me go ahead and send this, and there will be a lengthy addendum shortly. Noel From tuhs at tuhs.org Tue Jul 18 08:51:35 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 17 Jul 2023 22:51:35 +0000 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: <20230717223243.794B018C09D@mercury.lcs.mit.edu> References: <20230717223243.794B018C09D@mercury.lcs.mit.edu> Message-ID: > A good source is the Ken+Dennis picture: > > https://www.bell-labs.com/usr/dmr/www/picture.html > > Noel There is actually another photo from the same session: https://computerhistory.org/wp-content/uploads/2019/10/102685442.03.01.jpg >From a higher angle too so you can see both the 20 and the 45 to its left there. Not very much more to be gleaned from it but it does feature the bezels of both PDP-11s. - Matt G. From henry.r.bent at gmail.com Tue Jul 18 09:05:03 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 17 Jul 2023 19:05:03 -0400 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: References: <20230717223243.794B018C09D@mercury.lcs.mit.edu> Message-ID: On Mon, 17 Jul 2023 at 18:52, segaloco via TUHS wrote: > > A good source is the Ken+Dennis picture: > > > > https://www.bell-labs.com/usr/dmr/www/picture.html > > > > Noel > > There is actually another photo from the same session: > > https://computerhistory.org/wp-content/uploads/2019/10/102685442.03.01.jpg > > From a higher angle too so you can see both the 20 and the 45 to its left > there. Not very much more to be gleaned from it but it does feature the > bezels of both PDP-11s. > > - Matt G. > Nice! I would assume that there would be no need to connect two TU56s to one machine, so that does solve one aspect of this. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jul 18 10:49:46 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 17 Jul 2023 20:49:46 -0400 (EDT) Subject: [TUHS] Research UNIX PDP 11/45 Message-ID: <20230718004946.4ACC518C09B@mercury.lcs.mit.edu> > From: Henry Bent > there will be a lengthy addendum shortly. The most useful thing is probably this: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/low.s which lists exactly what was there; not only the types, but how many of each there are. This is from 'nsys', which is slightly before the actual V4, so it's quite early. 'low.s' is inherently machine-specific; i.e. different machines would share most kernel files identically, but _not_ this one - unless they had _absolutely identical_ device sets. So this one is _probably_ the one from the /45 in picture. It shows: RK11 RF11 PC11 TC11 TM11 1xKL11 12xDC11 1xDP11 (synchronous serial) 1xDN11 (dial-out asynch control) 1xDR11C (parallel port to -11/20) 2xDC11 (Screw Works voice synthesizer) 1xDR11A (voice response unit) 1xDR11C (C/A/T typesetter) (Line printer, card reader and RP11 are commented out; more about the RP11 in a later message. There's also this: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/11-45 which is a bit hard to interpret, but I think might list what's in each rack: the TC11, RK11 (early ones), RF11 and TM11 (early ones) were large custom wire-wrapped backplanes which bolted into the front or back of a 19 inch rack; this: https://gunkies.org/wiki/RK11-C_disk_controller has an image of such an RK11. The "MOS 16-24" is probably a reference to an MS11: https://gunkies.org/wiki/MS11_Semiconductor_Memory_System which had to mount in the CPU backplane. The "MM" entries are likely core memory units; probably MM11-K's: https://gunkies.org/wiki/MM11-K_core_memory since they seem to be 4KW each. (Maybe MM11-E's or 'F's, though; those are also 4KW each.) I'm not sure what they "PL"s are - probably Plessey core? Anyway,it looks like the machine had 104KB total. This file: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/conf.c lists all the types of devices on the machine. One oddity is that it lists two RK11's; but if you look at the RK11 driver: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/rk.c it's only set up to handle one physical controller. But there is this: #define JRK 1 /* temp */ if (bp->b_dev.d_major==JRK) d = bp->b_dev.d_minor; else d = bp->b_blkno%3; so the two different major device entries appear to handle the same disks in different ways ("d = bp->b_blkno%3" will spread a virtual drive across three physical drives). Memory, it would have been hard to say (UNIX even then sized memory at start up) but then I found that '11-45' file. I also found a copy of the CACM version of the UNIX paper: https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf which says the machine had 144KB (so they had added 40KB more at that point). (I seem to recall someone had scanned the SOSP version; I didn't save the pointer, but if someone knows where it is, it would be interesting to look, and see what it says - they seemed to update this paper on a regular basis - the copy included with V6 talks about the -11/70.) The system at that point had "a 1M byte fixed-head disk .. four moving-head disk drives which each provide 2.5M bytes on removable disk cartridges, and a single moving-head disk drive which uses removable 40M byte disk packs" The RS11 disks for the RF11 were 512KB, so either they'd added a second one, or switched to an RS04 (but that's a MASSBUS device). The big disk was an RP03 so they had added an RP11, which wasn't present earlier. Noel From jsg at jsg.id.au Tue Jul 18 12:06:24 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 18 Jul 2023 12:06:24 +1000 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: <20230718004946.4ACC518C09B@mercury.lcs.mit.edu> References: <20230718004946.4ACC518C09B@mercury.lcs.mit.edu> Message-ID: On Mon, Jul 17, 2023 at 08:49:46PM -0400, Noel Chiappa wrote: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/rk.c > > it's only set up to handle one physical controller. But there is this: > > #define JRK 1 /* temp */ > > if (bp->b_dev.d_major==JRK) > d = bp->b_dev.d_minor; > else > d = bp->b_blkno%3; > > so the two different major device entries appear to handle the same disks in > different ways ("d = bp->b_blkno%3" will spread a virtual drive across three > physical drives). "Berkeley's 11/45 was among the first systems that Thompson had encountered that had two disks on the same controller!" Twenty Years of Berkeley Unix https://www.oreilly.com/openbook/opensources/book/kirkmck.html > Memory, it would have been hard to say (UNIX even then sized memory at start > up) but then I found that '11-45' file. I also found a copy of the CACM > version of the UNIX paper: > > https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf > > which says the machine had 144KB (so they had added 40KB more at that point). > (I seem to recall someone had scanned the SOSP version; I didn't save the > pointer, but if someone knows where it is, it would be interesting to look, > and see what it says - they seemed to update this paper on a regular basis - > the copy included with V6 talks about the -11/70.) tuhs/Applications/Dennis_Tapes/dmr_tapes.tgz dmr_tapes/dmr2/tp/paper/p1 Nov 1973 "The PDP-11/45 on which our UNIX installation is implemented is a 16-bit word (8-bit byte) computer with 104K bytes of core memory; UNIX occupies 42K bytes." tuhs/Documentation/Papers/unix_cacm74.pdf July 1974 "The PDP-11/45 on which our UNIX installation is implemented is a 16-bit word (8-bit byte) computer with 144K bytes of core memory; UNIX occupies 42K bytes." tuhs/Distributions/Research/Dennis_v6/v6doc.tar.gz unix/p1 Jun 1975 "The PDP-11/45 on which our UNIX installation is implemented is a 16-bit word (8-bit byte) computer with 112K bytes of core memory; UNIX occupies 53K bytes." version from the Australian DECUS symposium (August 1977) has the same line as as v6 tuhs/Documentation/Papers/BSTJ/bstj57-6-1905.pdf July/Aug 1978 "The PDP-11/70 on which the Research UNIX system is installed is a 16-bit word (8-bit byte) computer with 768K bytes of core memory; the system kernel occupies 90K bytes about equally divided between code and data tables." v7/usr/doc/cacm/p1 matches bstj From aap at papnet.eu Tue Jul 18 14:40:07 2023 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 18 Jul 2023 06:40:07 +0200 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: <20230717223243.794B018C09D@mercury.lcs.mit.edu> References: <20230717223243.794B018C09D@mercury.lcs.mit.edu> Message-ID: On 17/07/23, Noel Chiappa wrote: > A good source is the Ken+Dennis picture: > > https://www.bell-labs.com/usr/dmr/www/picture.html I asked ken about this once and he said it wasn't even their machines. Angelo From lars at nocrew.org Tue Jul 18 16:25:48 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 18 Jul 2023 06:25:48 +0000 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: (Clem Cole's message of "Mon, 17 Jul 2023 18:13:10 -0400") References: Message-ID: <7w5y6hpwgj.fsf@junk.nocrew.org> Clem Cole wrote: > The picture also shows 2 RK's, 2 DEC Tape and a Paper Tape read/punch, > and the Tek display on the table. As per Dennis' description Noel linked to, it's a DEC VT01A terminal with a Tektronix 611 tube. I found an old eBay photo online and copied it to gunkies. Bitsavers has a VT02 photo which is quite close. https://gunkies.org/w/images/5/5d/VT01A.jpeg https://bitsavers.org/pdf/dec/terminal/vt02/vt02_1.jpg Noel Chiappa wrote: > A good source is the Ken+Dennis picture: > https://www.bell-labs.com/usr/dmr/www/picture.html > and the caption which Dennis wrote for it. From henry.r.bent at gmail.com Tue Jul 18 23:10:34 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 18 Jul 2023 09:10:34 -0400 Subject: [TUHS] Research UNIX PDP 11/45 In-Reply-To: <20230718004946.4ACC518C09B@mercury.lcs.mit.edu> References: <20230718004946.4ACC518C09B@mercury.lcs.mit.edu> Message-ID: On Mon, 17 Jul 2023 at 20:49, Noel Chiappa wrote: > > From: Henry Bent > > > there will be a lengthy addendum shortly. > > The most useful thing is probably this: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/low.s > > which lists exactly what was there; not only the types, but how many of > each > there are. This is from 'nsys', which is slightly before the actual V4, so > it's quite early. 'low.s' is inherently machine-specific; i.e. different > machines would share most kernel files identically, but _not_ this one - > unless they had _absolutely identical_ device sets. So this one is > _probably_ > the one from the /45 in picture. > > It shows: > > RK11 > RF11 > PC11 > TC11 > TM11 > > 1xKL11 > 12xDC11 > 1xDP11 (synchronous serial) > 1xDN11 (dial-out asynch control) > > 1xDR11C (parallel port to -11/20) > 2xDC11 (Screw Works voice synthesizer) > 1xDR11A (voice response unit) > 1xDR11C (C/A/T typesetter) > > (Line printer, card reader and RP11 are commented out; more about the RP11 > in a later message. > > > There's also this: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/11-45 > > which is a bit hard to interpret, but I think might list what's in each > rack: > the TC11, RK11 (early ones), RF11 and TM11 (early ones) were large custom > wire-wrapped backplanes which bolted into the front or back of a 19 inch > rack; this: > > https://gunkies.org/wiki/RK11-C_disk_controller > > has an image of such an RK11. The "MOS 16-24" is probably a reference to an > MS11: > > https://gunkies.org/wiki/MS11_Semiconductor_Memory_System > > which had to mount in the CPU backplane. The "MM" entries are likely core > memory units; probably MM11-K's: > > https://gunkies.org/wiki/MM11-K_core_memory > > since they seem to be 4KW each. (Maybe MM11-E's or 'F's, though; those are > also 4KW each.) I'm not sure what they "PL"s are - probably Plessey core? > Anyway,it looks like the machine had 104KB total. > > > This file: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/conf.c > > lists all the types of devices on the machine. One oddity is that it lists > two RK11's; but if you look at the RK11 driver: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/rk.c > > it's only set up to handle one physical controller. But there is this: > > #define JRK 1 /* temp */ > > if (bp->b_dev.d_major==JRK) > d = bp->b_dev.d_minor; > else > d = bp->b_blkno%3; > > so the two different major device entries appear to handle the same disks > in > different ways ("d = bp->b_blkno%3" will spread a virtual drive across > three > physical drives). > > > Memory, it would have been hard to say (UNIX even then sized memory at > start > up) but then I found that '11-45' file. I also found a copy of the CACM > version of the UNIX paper: > > https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf > > which says the machine had 144KB (so they had added 40KB more at that > point). > (I seem to recall someone had scanned the SOSP version; I didn't save the > pointer, but if someone knows where it is, it would be interesting to look, > and see what it says - they seemed to update this paper on a regular basis > - > the copy included with V6 talks about the -11/70.) > > The system at that point had "a 1M byte fixed-head disk .. four moving-head > disk drives which each provide 2.5M bytes on removable disk cartridges, and > a single moving-head disk drive which uses removable 40M byte disk packs" > > The RS11 disks for the RF11 were 512KB, so either they'd added a second > one, > or switched to an RS04 (but that's a MASSBUS device). The big disk was an > RP03 so they had added an RP11, which wasn't present earlier. > > Noel > Noel, Thank you very much for this thoroughly researched and documented explanation. I hope that it will be of use to others as well. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Wed Jul 19 10:58:12 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Tue, 18 Jul 2023 17:58:12 -0700 Subject: [TUHS] "UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM) Message-ID: A friend found this doc which as far as I can tell is not online anywhere yet. Preliminary sketch for the UNIX/370 effort at Bell based on TSS/370. Apparently started at Holmdel, I had always thought Indian Hill. https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=sharing Please archive! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Wed Jul 19 11:08:11 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Tue, 18 Jul 2023 18:08:11 -0700 Subject: [TUHS] (Amdahl UNIX) "Notes on Au Performance - or How to get the Pb out of Au" Message-ID: This is perhaps the first significant document I wrote at Amdahl. Although undated, I believe this was written in August 1979, after I had attended a 2 week class at IBM Chicago about VM//370(CP) internals and performance. The paper makes reference to V7 UNIX being "on order", so this is when the V6 UNIX system was in use. IIRC, V7 UNIX was released in Nov. of 1979. https://drive.google.com/file/d/1cB2eqTwmicj1AQOiULDZjED5Rq-_V4N4/view?usp=sharing Huge thanks to my friend Karl D. for hanging on to this for 44 years. -------------- next part -------------- An HTML attachment was scrubbed... URL: From f4grx at f4grx.net Wed Jul 19 23:50:30 2023 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Wed, 19 Jul 2023 15:50:30 +0200 Subject: [TUHS] (Amdahl UNIX) "Notes on Au Performance - or How to get the Pb out of Au" In-Reply-To: References: Message-ID: <5baa2142-c350-679b-0660-8cc3f0e2104c@f4grx.net> Hi, Thank you, this is a very interesting read. I will share this with friends as soon as this is publicly available in the TUHS archives. We see premices of the Linux Copy-On-Write forking method! I also note that they decided to avoid a global kernel lock. Sebastien Le 19/07/2023 à 03:08, Tom Lyon a écrit : > This is perhaps the first significant document I wrote at Amdahl. > Although undated, I believe this was written in August 1979, after I > had attended a 2 week class at IBM Chicago about VM//370(CP) internals > and performance. > > The paper makes reference to V7 UNIX being "on order", so this is when > the V6 UNIX system was in use.  IIRC, V7 UNIX was released in Nov. of > 1979. > > https://drive.google.com/file/d/1cB2eqTwmicj1AQOiULDZjED5Rq-_V4N4/view?usp=sharing > > Huge thanks to my friend Karl D. for hanging on to this for 44 years. From f4grx at f4grx.net Thu Jul 20 00:23:27 2023 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Wed, 19 Jul 2023 16:23:27 +0200 Subject: [TUHS] (Amdahl UNIX) "Notes on Au Performance - or How to get the Pb out of Au" In-Reply-To: <5baa2142-c350-679b-0660-8cc3f0e2104c@f4grx.net> References: <5baa2142-c350-679b-0660-8cc3f0e2104c@f4grx.net> Message-ID: Hi again, this remark actually applies to the other document about unix370 feasability, oops! However, That one is also interesting. I read in it at 6.1.4 "Login procedure optimization" about "combining (..) (init, getty and login) into one [program]". We can see this as the premices for the modern systemd :-) Sebastien Le 19/07/2023 à 15:50, Sebastien F4GRX a écrit : > Hi, > > Thank you, this is a very interesting read. I will share this with > friends as soon as this is publicly available in the TUHS archives. > > We see premices of the Linux Copy-On-Write forking method! > > I also note that they decided to avoid a global kernel lock. > > Sebastien > > Le 19/07/2023 à 03:08, Tom Lyon a écrit : >> This is perhaps the first significant document I wrote at Amdahl. >> Although undated, I believe this was written in August 1979, after I >> had attended a 2 week class at IBM Chicago about VM//370(CP) >> internals and performance. >> >> The paper makes reference to V7 UNIX being "on order", so this is >> when the V6 UNIX system was in use.  IIRC, V7 UNIX was released in >> Nov. of 1979. >> >> https://drive.google.com/file/d/1cB2eqTwmicj1AQOiULDZjED5Rq-_V4N4/view?usp=sharing >> >> >> Huge thanks to my friend Karl D. for hanging on to this for 44 years. From clemc at ccc.com Thu Jul 20 02:08:52 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 19 Jul 2023 12:08:52 -0400 Subject: [TUHS] "UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM) In-Reply-To: References: Message-ID: Tom - do you know if any of the technical work for this survived? As an old TSS hacker, I'd love to see this run again on Hercules. Also, any idea if either of these documents in the references still exist: B. G. Prieve, "UNIX/370 - A Proposal,” MF 8224-780928.01 and S. L. Gaede, "High Capacity UNIX - Exploration of UNIX/370," MF 5521-780901.01. ᐧ On Tue, Jul 18, 2023 at 8:58 PM Tom Lyon wrote: > A friend found this doc which as far as I can tell is not online anywhere > yet. Preliminary sketch for the UNIX/370 effort at Bell based on TSS/370. > Apparently started at Holmdel, I had always thought Indian Hill. > > > https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=sharing > > Please archive! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jul 20 02:12:19 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 19 Jul 2023 10:12:19 -0600 Subject: [TUHS] "UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM) In-Reply-To: References: Message-ID: On Wed, Jul 19, 2023 at 10:09 AM Clem Cole wrote: > Tom - do you know if any of the technical work for this survived? As an > old TSS hacker, I'd love to see this run again on Hercules. > > Also, any idea if either of these documents in the references still > exist: B. G. Prieve, "UNIX/370 - A Proposal,” MF 8224-780928.01 and S. > L. Gaede, "High Capacity UNIX - Exploration of UNIX/370," MF 5521-780901.01. > ᐧ > I had the same thought :) Warner > On Tue, Jul 18, 2023 at 8:58 PM Tom Lyon wrote: > >> A friend found this doc which as far as I can tell is not online anywhere >> yet. Preliminary sketch for the UNIX/370 effort at Bell based on TSS/370. >> Apparently started at Holmdel, I had always thought Indian Hill. >> >> >> https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=sharing >> >> Please archive! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Thu Jul 20 02:12:24 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 19 Jul 2023 09:12:24 -0700 Subject: [TUHS] "UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM) In-Reply-To: References: Message-ID: I have no knowledge of any preserved UNIX/370 stuff from Bell. On Wed, Jul 19, 2023 at 9:09 AM Clem Cole wrote: > Tom - do you know if any of the technical work for this survived? As an > old TSS hacker, I'd love to see this run again on Hercules. > > Also, any idea if either of these documents in the references still > exist: B. G. Prieve, "UNIX/370 - A Proposal,” MF 8224-780928.01 and S. > L. Gaede, "High Capacity UNIX - Exploration of UNIX/370," MF 5521-780901.01. > ᐧ > > On Tue, Jul 18, 2023 at 8:58 PM Tom Lyon wrote: > >> A friend found this doc which as far as I can tell is not online anywhere >> yet. Preliminary sketch for the UNIX/370 effort at Bell based on TSS/370. >> Apparently started at Holmdel, I had always thought Indian Hill. >> >> >> https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=sharing >> >> Please archive! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jul 20 02:50:56 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 19 Jul 2023 12:50:56 -0400 Subject: [TUHS] "UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM) In-Reply-To: References: Message-ID: T'was afraid of that. Shame really. Tx Clem ᐧ On Wed, Jul 19, 2023 at 12:12 PM Tom Lyon wrote: > I have no knowledge of any preserved UNIX/370 stuff from Bell. > > On Wed, Jul 19, 2023 at 9:09 AM Clem Cole wrote: > >> Tom - do you know if any of the technical work for this survived? As an >> old TSS hacker, I'd love to see this run again on Hercules. >> >> Also, any idea if either of these documents in the references still >> exist: B. G. Prieve, "UNIX/370 - A Proposal,” MF 8224-780928.01 and S. >> L. Gaede, "High Capacity UNIX - Exploration of UNIX/370," MF 5521-780901.01. >> ᐧ >> >> On Tue, Jul 18, 2023 at 8:58 PM Tom Lyon wrote: >> >>> A friend found this doc which as far as I can tell is not online >>> anywhere yet. Preliminary sketch for the UNIX/370 effort at Bell based on >>> TSS/370. Apparently started at Holmdel, I had always thought Indian Hill. >>> >>> >>> https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=sharing >>> >>> Please archive! >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Thu Jul 20 07:52:32 2023 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 19 Jul 2023 17:52:32 -0400 Subject: [TUHS] "UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM) In-Reply-To: References: Message-ID: Peter Capek probably can dredge up details and contacts of the IBM efforts in that direction. I know Sig Handelman at IBM Research worked on some flavor of UNIX port to the S/370 back in the day, but I've lost touch with him. ===== nygeek.net mindthegapdialogs.com/home On Wed, Jul 19, 2023 at 12:51 PM Clem Cole wrote: > T'was afraid of that. Shame really. > Tx > Clem > ᐧ > > On Wed, Jul 19, 2023 at 12:12 PM Tom Lyon wrote: > >> I have no knowledge of any preserved UNIX/370 stuff from Bell. >> >> On Wed, Jul 19, 2023 at 9:09 AM Clem Cole wrote: >> >>> Tom - do you know if any of the technical work for this survived? As an >>> old TSS hacker, I'd love to see this run again on Hercules. >>> >>> Also, any idea if either of these documents in the references still >>> exist: B. G. Prieve, "UNIX/370 - A Proposal,” MF 8224-780928.01 and S. >>> L. Gaede, "High Capacity UNIX - Exploration of UNIX/370," MF 5521-780901.01. >>> ᐧ >>> >>> On Tue, Jul 18, 2023 at 8:58 PM Tom Lyon wrote: >>> >>>> A friend found this doc which as far as I can tell is not online >>>> anywhere yet. Preliminary sketch for the UNIX/370 effort at Bell based on >>>> TSS/370. Apparently started at Holmdel, I had always thought Indian Hill. >>>> >>>> >>>> https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=sharing >>>> >>>> Please archive! >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jul 20 09:18:30 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 19 Jul 2023 23:18:30 +0000 Subject: [TUHS] AT&T UNIX Support Activities Post-1983 Message-ID: <4OuMmV_pTkSEipR3fyVL7nQ__cfZlTtYr3zTdVJPvuHZIGRSyZLSG3z40Qp14Z1VlxAgro1OCo_QrkvBTSjRNo5ju3ZmxgZVnWtsOxjeQLw=@protonmail.com> Hello, I received in the mail today a USOC listing from the NY Bell division listing various standardized service codes in 1982. I wasn't particularly expecting to see anything relevant to UNIX in there, but flipping through the pages, it did have me curious on one point. Prior to divestiture, one of the conditions placed on Bell was that they could not support UNIX. Sure, tapes could find their way to individuals for service costs or under particular agreements, but this provision of "service" seemed to be right out and not allowed under their then-terms. This is presumably why there is nothing resembling UNIX in this manual, nor can I find anything implying 3B20(D/S) services. So after 1983 when the cat is out of the bag and AT&T begins aggressive marketing, what sorts of "services" were they then providing to UNIX customers that they couldn't before? One item I've got that further complicates my understanding, a class listing from Western Electric Corporate Education from July, 1983[1]. Did offering classes like this not constitute "support", or was there a little window between 1982 and 1984 where AT&T could start their true marketing and support in earnest while still not being absolutely complete with the divestiture of the Western Electric business? In any case, if WECo was out the door as part of the legal settlement, it does strike me as a bit odd they'd put any work into spinning up the WECo Corporate Education machine on this for the space of just part of a year in 1983, only to then rebrand it all for ATTIS when Jan 1st passes. An additional time-frame indicator is while this foldout does list WECo, it is devoid of Bell system logos, consistent with the date as that was one of the conditions that started to take effect that summer. Anywho, I'm sure some of the general information what services they provided in addition to licensing and distributing for UNIX license holders lives in documentation out there, so I'll be reading up too, but figured it'd be good to ask if nothing else to figure out what was going on in the early 80s, because that WECo training document certainly has me a bit curious on the timeframe vs what they could and couldn't do throughout the Bell System breakup years. - Matt G. [1] -https://imgur.com/a/xbEOGZn Note, I intend to do a proper scan on glass with this after I get through some IBM stuff I'm working on, so don't worry, I don't intend these photos to be historical record. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 21 09:18:11 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 20 Jul 2023 23:18:11 +0000 Subject: [TUHS] Offering Free Unbound System V Document Processing Guide (1983) Message-ID: Good day all, I'm emailing to offer a duplicate UNIX document I picked up free of charge to whoever speaks for it first, I'll even cover the shipping. What I've got is a second copy of the Document Processing Guide shipped with the initial System V version, code 341-920, from 1983. Now for the caveat: I ordered this second copy as it was in much rougher shape than the one I currently have. I intend to chop the spine off so I can get quality scans of the pages rather than having to deal with creasing the hell out of the binding on my other copy (unlike the manuals and some of the other guides, this one is a typical paperback glue binding.) Once I'm done with the scans I'm just going to put all of the pages in a binder (as they're already Bell-style 7-hole punched.) That to say, I'm not ready to ship it right now, just got it today, still need to do the scans. As for contents, this contains the System V-era versions of the following papers (titles paraphrased): - Advanced Editing on UNIX - Sed - NROFF/TROFF User's Manual - TROFF Tutorial - Tbl - Eqn - MM Macros Manual - View Graphs and Slide Macros Anywho, figured I'd see if anyone was interested in this after I'm done with it. Otherwise I'll just see if a library around here is interested. - Matt G. From tuhs at tuhs.org Fri Jul 21 10:44:16 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 21 Jul 2023 00:44:16 +0000 Subject: [TUHS] Offering Free Unbound System V Document Processing Guide (1983) In-Reply-To: References: Message-ID: And spoken for. - Matt G. From rdm at cfcl.com Sat Jul 22 04:53:29 2023 From: rdm at cfcl.com (Rich Morin) Date: Fri, 21 Jul 2023 11:53:29 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman Message-ID: Lessons Learned from Sendmail https://www.youtube.com/watch?v=Re1MAO6jOLE -r From tuhs at tuhs.org Sat Jul 22 08:14:57 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Fri, 21 Jul 2023 17:14:57 -0500 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: Message-ID: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> On 7/21/23 1:53 PM, Rich Morin wrote: > Lessons Learned from Sendmail > https://www.youtube.com/watch?v=Re1MAO6jOLE Thank you for sharing that video Rich. The credits are finishing now. A surprising amount of Eric's talk resonated with me. I find it entertaining that he and I are doing strikingly similar things with email, both MTA and MUA, for seemingly similar reasons. Thank you again. Grant. . . . From lm at mcvoy.com Sat Jul 22 08:30:17 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 21 Jul 2023 15:30:17 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> Message-ID: <20230721223017.GA25639@mcvoy.com> On Fri, Jul 21, 2023 at 05:14:57PM -0500, Grant Taylor via TUHS wrote: > On 7/21/23 1:53???PM, Rich Morin wrote: > >Lessons Learned from Sendmail > >https://www.youtube.com/watch?v=Re1MAO6jOLE > > Thank you for sharing that video Rich. > > The credits are finishing now. > > A surprising amount of Eric's talk resonated with me. I find it > entertaining that he and I are doing strikingly similar things with email, > both MTA and MUA, for seemingly similar reasons. > > Thank you again. I think it was pre-COVID but I had a gathering of systems people at my place in the Santa Cruz mountains and Kirk and Eric were there. I ended up talking to Eric for quite a while and what went through my mind was "This is so pleasant, I'd hire this guy or happily work for this guy. He gets C like I do and likes it like I do". It really was super pleasant to realize I'm not the last guy who wants to use C for serious work. I suspect we're dinosaurs but we're cut from the same clothe dinosaurs. A few pics here, not up to my usual level but whatever: http://mcvoy.com/lm/2019-bsd-bbq/ -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat Jul 22 08:33:11 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Fri, 21 Jul 2023 17:33:11 -0500 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <20230721223017.GA25639@mcvoy.com> References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> Message-ID: <79a7c0aa-2580-e77d-8b53-9cf9c5bf4a79@tnetconsulting.net> On 7/21/23 5:30 PM, Larry McVoy wrote: > It really was super pleasant to realize I'm not the last guy who > wants to use C for serious work. I thought the same thing about m4. I still like m4. I've used m4 for more than trivial things within the last few years. > I suspect we're dinosaurs but we're cut from the same clothe dinosaurs. :-) Grant. . . . From lm at mcvoy.com Sat Jul 22 08:39:22 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 21 Jul 2023 15:39:22 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <79a7c0aa-2580-e77d-8b53-9cf9c5bf4a79@tnetconsulting.net> References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> <79a7c0aa-2580-e77d-8b53-9cf9c5bf4a79@tnetconsulting.net> Message-ID: <20230721223922.GC25639@mcvoy.com> On Fri, Jul 21, 2023 at 05:33:11PM -0500, Grant Taylor via TUHS wrote: > > On 7/21/23 5:30???PM, Larry McVoy wrote: > >It really was super pleasant to realize I'm not the last guy who wants to > >use C for serious work. > > I thought the same thing about m4. > > I still like m4. > > I've used m4 for more than trivial things within the last few years. > > >I suspect we're dinosaurs but we're cut from the same clothe dinosaurs. I think you get good at using C, and/or m4, and at a certain point it is easier to write good code in that than start over in a different set of tools. My older son is learning CS and I told him that C is a lot like a sports car on a twisty mountain road that has no guard rails. If you are someone who wants to be on your phone in the car, you are gonna have a bad time. On the other hand, if you are an expert driver, it's a lot of fun. Kids these days, all they want is guard rails :) --lm From usotsuki at buric.co Sat Jul 22 09:39:56 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 21 Jul 2023 19:39:56 -0400 (EDT) Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <20230721223017.GA25639@mcvoy.com> References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> Message-ID: On Fri, 21 Jul 2023, Larry McVoy wrote: > I think it was pre-COVID but I had a gathering of systems people at my > place in the Santa Cruz mountains and Kirk and Eric were there. I ended > up talking to Eric for quite a while and what went through my mind was > "This is so pleasant, I'd hire this guy or happily work for this guy. > He gets C like I do and likes it like I do". It really was super > pleasant to realize I'm not the last guy who wants to use C for > serious work. > > I suspect we're dinosaurs but we're cut from the same clothe dinosaurs. > > A few pics here, not up to my usual level but whatever: > > http://mcvoy.com/lm/2019-bsd-bbq/ I feel like C is one of the only languages worth using for serious code. Most of my code is still C. -uso. From tuhs at tuhs.org Sat Jul 22 11:48:36 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 22 Jul 2023 01:48:36 +0000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <20230721223017.GA25639@mcvoy.com> References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> Message-ID: > A few pics here, not up to my usual level but whatever: > > http://mcvoy.com/lm/2019-bsd-bbq/ Hah, that reminds me of an implementation trip I was on once. They put our "classroom" back in an old warehouse full of all sorts of junk. Well, one particular week they were doing a bunch of loading/unloading and there was frequently a forklift, keys and all, parked there in this large, tempting warehouse, in the dead of winter in BFE Pennsylvania. Nothing was done that violated company policy, but then again, can't violate a company policy that doesn't exist in writing :) Can't say I've ever gotten any projects at work to bite on C, but I've had some moderate success reducing most of our boilerplate templates into m4 macros...just in time for a lull in new work. We've got a new project starting soon though that I'm excited to finally use it with, maybe I'll finally convert someone else at work to using some UNIX tools. - Matt G. From nobozo at gmail.com Sat Jul 22 11:55:31 2023 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 21 Jul 2023 18:55:31 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <20230721223017.GA25639@mcvoy.com> References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> Message-ID: <02da826d-d13a-0c3e-2da7-4ae72605e44f@gmail.com> On 7/21/2023 3:30 PM, Larry McVoy wrote: > I think it was pre-COVID but I had a gathering of systems people at my > place in the Santa Cruz mountains and Kirk and Eric were there. I ended > up talking to Eric for quite a while and what went through my mind was > "This is so pleasant, I'd hire this guy or happily work for this guy. I've had the pleasure and honor of working with and for Eric several times in my career. He's one of the best programmers I've ever seen. Jon From cowan at ccil.org Sat Jul 22 14:37:11 2023 From: cowan at ccil.org (John Cowan) Date: Sat, 22 Jul 2023 00:37:11 -0400 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> Message-ID: On Fri, Jul 21, 2023 at 7:39 PM Steve Nickolas wrote: > I feel like C is one of the only languages worth using for serious code. > Spinach! The only language suitable or serious code is Fortran 66, where A+I is a compiler error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Jul 22 16:45:39 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 22 Jul 2023 06:45:39 +0000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <20230721223017.GA25639@mcvoy.com> (Larry McVoy's message of "Fri, 21 Jul 2023 15:30:17 -0700") References: <9d5cd822-07aa-42e9-4b14-a1b86da0e6bf@tnetconsulting.net> <20230721223017.GA25639@mcvoy.com> Message-ID: <7wo7k4moks.fsf@junk.nocrew.org> Larry McVoy wrote: > I'm not the last guy who wants to use C for serious work. I'm using many diffent languages for many things. But when I write stuff that I'm humbly HOPING will be useful, say, 30 years from now, I pick C. It seems to me it's likely it will stick around, close to its current form, a long time from now. I don't think I could make that bet on other languages that are popular now, either due to the language itself being in flux, or its libraries, ecosystem, etc. From rich.salz at gmail.com Sun Jul 23 00:54:20 2023 From: rich.salz at gmail.com (Rich Salz) Date: Sat, 22 Jul 2023 07:54:20 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: Message-ID: He says he wraps everything he uses in the standard library; "this tends to make my code idiosyncratic." At some Usenix, someone once summed it up to me as "It is the most beautiful code that is completely unmodifiable." Seemed appropriate. (Compare to procmail, where the quote was "seen the source? Gaah, my eyes are melting.") I enjoyed watching this, thanks. I agree with the other comment "what, nothing about security?" Sendmail did enable the first Internet worm :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jul 23 01:24:55 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 22 Jul 2023 09:24:55 -0600 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: Message-ID: On Sat, Jul 22, 2023, 8:54 AM Rich Salz wrote: > He says he wraps everything he uses in the standard library; "this tends > to make my code idiosyncratic." At some Usenix, someone once summed it up > to me as "It is the most beautiful code that is completely unmodifiable." > Seemed appropriate. (Compare to procmail, where the quote was "seen the > source? Gaah, my eyes are melting.") > Back in the 80s I looked at sendmail.. lots of things like strcpy written inline. It was a mess in some ways, but ran more slowly if you cleaned all that stuff up. It was decently well done, but had also clearly grown well beyond its original framing... The thing is... you don't need wrappers for standard calls. You just need portable implementations of them for the times they are missing or broken. I enjoyed watching this, thanks. I agree with the other comment "what, > nothing about security?" Sendmail did enable the first Internet worm :) > Some of that was the times: almost nothing cared about security in a world full of active attackers... having already forgotten the lessons of the early v5 deployments exposing unix to lots of bored college students that needed to do something and quickly found holes in unix's protections.. though known at the time, the stack smash wasn't believed generally to be a severe threat. Even after the eorm, it was 10 years later openbsd started its wide spread effort to fix them... Gets() was the real problem that leD to the worm. The insecurity was baked into the APIs until the 90s... and many insecure APIs weren't removed until the last decade. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Jul 23 02:12:01 2023 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 22 Jul 2023 18:12:01 +0200 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: Message-ID: On 22 Jul 2023, at 17:25, Warner Losh wrote: > having already forgotten the lessons of the early v5 deployments exposing unix to lots of bored college students that needed to do something and quickly found holes in unix's protections.. As a curious young lad I was very pleased that the concept of a “secure” tty wasn’t around when I “bruteforced” my first root password over my father’s TYY. Arrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Jul 23 06:52:33 2023 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 23 Jul 2023 06:52:33 +1000 (EST) Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: Message-ID: On Sat, 22 Jul 2023, Rich Salz wrote: > (Compare to procmail, where the quote was "seen the source? Gaah, my > eyes are melting.") The Procmail source is so bad that even the author has abandoned it; it's likely to be riddled with security holes too, so you'd be nuts to use it. > I enjoyed watching this, thanks. I agree with the other comment "what, > nothing about security?" Sendmail did enable the first Internet worm :) Like C, Sendmail was not really designed with secure coding in mind. -- Dave From marcus.e.clark at outlook.com Sun Jul 23 20:15:02 2023 From: marcus.e.clark at outlook.com (Marcus Clark) Date: Sun, 23 Jul 2023 10:15:02 +0000 Subject: [TUHS] Posted a video on installing and running v7 In-Reply-To: References: Message-ID: Thanks Will, for an interesting video on setting up and using Unix v7 in OpenSIMH. I usually follow your blog post instructions, which are always clear and accurate, but it was nice to have a video version. You mention different systems you have tested it on, and I can confirm it all works fine on Slackware Linux 15.0 and -current with no problems. Marcus. ________________________________ From: Will Senn Sent: 16 July 2023 03:06 To: The Eunuchs Hysterical Society Subject: [TUHS] Posted a video on installing and running v7 Hi All, I got some questions recently about getting v7 working, so I fired up OBS to create a video walkthrough of the install process and first steps (it's basically following my v7 note, but hey some folks dig video). The video is totally amateur hour, but it was fun. I never get tired of logging in as dmr, writing hello.c, running cc, running hello and watch the magic of hello, world appear on "screen". As a reminder - the note (and thus, the video) walks the user through installing OpenSIMH (including pdp11), building a tape image, installing to disk from tape, booting off the disk, building and using a DZ-11 as a telnet listener on 16 lines, adding a user, running learn, and piddly stuff like setting baud, delays, and such. Not a lot of hand-holding, but some. When I get around to it, I'll probably update the note to add additional test environments (I'm pretty sure it works anywhere OpenSIMH does, but some folks like to see there system or one kinda like it in the list of tested systems). I'm running LMDE5 and Debian 12 Bookworm these days, so I know they work there in addition to pretty much any Linux Mint, MX Linux, FreeBSD, Mac OS, etc. I'm still in awe of Hayle and Ritchie's Setting Up Unix - Seventh Edition as the basis of my note - 44 y.o. and counting... for holding up so well. The blog: https://decuser.github.io The blog post: https://decuser.github.io/unix/research-unix/v7/videos/2023/07/14/installing-and-using-research-unix-v7-in-open-simh-video.html The note blog post: https://decuser.github.io/unix/research-unix/v7/2022/10/28/installing-and-using-research-unix-v7-in-open-simh-pdp-11-45-and-70-emulators-rev-3.1.html Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Jul 24 00:10:58 2023 From: will.senn at gmail.com (Will Senn) Date: Sun, 23 Jul 2023 09:10:58 -0500 Subject: [TUHS] Posted a video on installing and running v7 In-Reply-To: References: Message-ID: Thanks, Marcus. Glad to hear it works on Slackware too. My first distro was Slackware with SLS's X, if I remember correctly. I've installed 15, too, for X explorations last year. Very clean. Thanks, Will On 7/23/23 05:15, Marcus Clark wrote: > Thanks Will, for an interesting video on setting up and using Unix v7 > in OpenSIMH. > > I usually follow your blog post instructions, which are always clear > and accurate, but it was nice to have a video version. > > You mention different systems you have tested it on, and I can confirm > it all works fine on Slackware Linux 15.0 and -current with no problems. > > Marcus. > ------------------------------------------------------------------------ > *From:* Will Senn > *Sent:* 16 July 2023 03:06 > *To:* The Eunuchs Hysterical Society > *Subject:* [TUHS] Posted a video on installing and running v7 > Hi All, > > I got some questions recently about getting v7 working, so I fired up > OBS to create a video walkthrough of the install process and first > steps (it's basically following my v7 note, but hey some folks dig > video). The video is totally amateur hour, but it was fun. I never get > tired of logging in as dmr, writing hello.c, running cc, running hello > and watch the magic of > > hello, world > > appear on "screen". > > As a reminder - the note (and thus, the video) walks the user through > installing OpenSIMH (including pdp11), building a tape image, > installing to disk from tape, booting off the disk, building and using > a DZ-11 as a telnet listener on 16 lines, adding a user, running > learn, and piddly stuff like setting baud, delays, and such. Not a lot > of hand-holding, but some. > > When I get around to it, I'll probably update the note to add > additional test environments (I'm pretty sure it works anywhere > OpenSIMH does, but some folks like to see there system or one kinda > like it in the list of tested systems). I'm running LMDE5 and Debian > 12 Bookworm these days, so I know they work there in addition to > pretty much any Linux Mint, MX Linux, FreeBSD, Mac OS, etc. > > I'm still in awe of Hayle and Ritchie's Setting Up Unix - Seventh > Edition as the basis of my note - 44 y.o. and counting... for holding > up so well. > > The blog: > https://decuser.github.io > > The blog post: > https://decuser.github.io/unix/research-unix/v7/videos/2023/07/14/installing-and-using-research-unix-v7-in-open-simh-video.html > > > The note blog post: > https://decuser.github.io/unix/research-unix/v7/2022/10/28/installing-and-using-research-unix-v7-in-open-simh-pdp-11-45-and-70-emulators-rev-3.1.html > > > Later, > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Mon Jul 31 03:33:00 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 30 Jul 2023 13:33:00 -0400 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman Message-ID: "Lessons learned" overlooked the Morris worm, which exploited not only the unpardonable gets interface, but also the unpardonable back door that Allman built into sendmail. This reminds me of how I agonized over Mike Lesk's refusal to remove remote execution from uucp. (Like Eric, Mike created the feature to help fix the myriad trouble reports these communication facilities stimulated.) It seemed irresponsible to distribute v7 with the feature present, yet the rest of uucp provided an almost indispensable service. The fig leaf for allowing uucp in the distribution was that remote execution was described in the manual. If you didn't like it you could delete or fix uucp. (Sendmail's Trojan horse was undocumented, though visible in the code.) Doug From norman at oclsc.org Mon Jul 31 04:22:55 2023 From: norman at oclsc.org (Norman Wilson) Date: Sun, 30 Jul 2023 14:22:55 -0400 (EDT) Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman Message-ID: <1B96127522E338B678C2F77EB615BFFF.for-standards-violators@oclsc.org> Doug McIlroy: This reminds me of how I agonized over Mike Lesk's refusal to remove remote execution from uucp. ==== Uux, the remote-execution mechanism I remember from uucp, had rather better utility than the famous Sendmail back-door: it was how uucp carried mail, by sending a file to be handed to mailer on the remote system. It was clearly dangerous if the remote site accepted any command, but as shipped in V7 only a short list of remote commands was allowed: mail rmail lpr opr fsend fget. (As uucp was used to carry other things like netnews, the list was later extended by individual sites, and eventually moved to a file so reconfiguration needn't recapitulate compilation). Not the safest of mechanisms, but at least in V7 it had a use other than Mike fixing your system for you. Is there some additional history here? e.g. was the list of permitted commands added after arguments about safety, or some magic command that let Mike in removed? Or was there a different remote-execution back door I don't remember and don't see in a quick look at uuxqt.c? Norman Wilson Toronto ON From robpike at gmail.com Mon Jul 31 07:43:59 2023 From: robpike at gmail.com (Rob Pike) Date: Mon, 31 Jul 2023 07:43:59 +1000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <1B96127522E338B678C2F77EB615BFFF.for-standards-violators@oclsc.org> References: <1B96127522E338B678C2F77EB615BFFF.for-standards-violators@oclsc.org> Message-ID: There was also a feature Mike Lesk added that allowed a marked line, something like %! command to cause the command to be executed when the recipient read the mail, for example to demonstrate a feature of a program or teach the recipient something. He meant well. Dennis had the closest he ever had to a conniption, and it was taken out post haste. Meaning well is not enough. -rob On Mon, Jul 31, 2023 at 4:23 AM Norman Wilson wrote: > Doug McIlroy: > > This reminds me of how I agonized over Mike Lesk's refusal to remove > remote execution from uucp. > > ==== > > Uux, the remote-execution mechanism I remember from uucp, had > rather better utility than the famous Sendmail back-door: it > was how uucp carried mail, by sending a file to be handed to > mailer on the remote system. It was clearly dangerous if > the remote site accepted any command, but as shipped in V7 > only a short list of remote commands was allowed: mail rmail > lpr opr fsend fget. (As uucp was used to carry other things > like netnews, the list was later extended by individual sites, > and eventually moved to a file so reconfiguration needn't > recapitulate compilation). > > Not the safest of mechanisms, but at least in V7 it had a use > other than Mike fixing your system for you. > > Is there some additional history here? e.g. was the list of > permitted commands added after arguments about safety, or > some magic command that let Mike in removed? Or was there a > different remote-execution back door I don't remember and don't > see in a quick look at uuxqt.c? > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Mon Jul 31 09:34:56 2023 From: ggm at algebras.org (George Michaelson) Date: Mon, 31 Jul 2023 09:34:56 +1000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <1B96127522E338B678C2F77EB615BFFF.for-standards-violators@oclsc.org> Message-ID: It must be the fate of all UUCP-like protocols to recapitulate the life of UUCP. My memory is that ACSNet (quite UUCP like) had both an execute, and a *@dom.ain and even root@* handling, and that it caused some DOS consequences. There's nothing implicitly wrong with remote execution, remote job entry was a thing back in the coloured book protocols. I guess the problem inherent in "just do this thing" in UUCP was the permissions and runtime context. But a chroot() and permissions drop should have made it less risky. There is the "but anyone can inject it" problem. Execute on read is just awful. But, now we have HTML to track "they read it" through URL fetch. G From fair-tuhs at netbsd.org Mon Jul 31 09:59:00 2023 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Sun, 30 Jul 2023 16:59:00 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: Message-ID: <8246.1690761540@cesium.clock.org> Date: Mon, 31 Jul 2023 09:34:56 +1000 From: George Michaelson [...] Execute on read is just awful. But, now we have HTML to track "they read it" through URL fetch. And then the utterly disastrous: JavaScript. It should be *eliminated* from the WWW as the gross security violation it is. "don't run software from strangers", Erik Fair From imp at bsdimp.com Mon Jul 31 10:26:55 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 30 Jul 2023 18:26:55 -0600 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <8246.1690761540@cesium.clock.org> References: <8246.1690761540@cesium.clock.org> Message-ID: On Sun, Jul 30, 2023, 5:59 PM Erik E. Fair wrote: > > Date: Mon, 31 Jul 2023 09:34:56 +1000 > From: George Michaelson > > [...] > > Execute on read is just awful. But, now we have HTML to track "they > read it" through URL fetch. > > And then the utterly disastrous: JavaScript. It should be *eliminated* > from the WWW as the gross security violation it is. > > "don't run software from strangers", > Write once, run everywhere. Warner > Erik Fair > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Jul 31 10:41:39 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 31 Jul 2023 00:41:39 +0000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <8246.1690761540@cesium.clock.org> References: <8246.1690761540@cesium.clock.org> Message-ID: <3aovV7P4Yjs85KyyzhLEVWtypo0fXlszfLWmqxbC_UbuR2Ocu0l3BGLWG8YYcb_axehfCHG-kJNiYj6PXUKpfEvw8eELFonpv_OwSfj-sKI=@protonmail.com> > And then the utterly disastrous: JavaScript. It should be eliminated > from the WWW as the gross security violation it is. > > "don't run software from strangers", > > Erik Fair The browser is becoming more and more of an OS of its own, it just needs to act like it in the security realm. - Matt G.