From rminnich at gmail.com Sun Dec 3 16:01:54 2023 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Dec 2023 22:01:54 -0800 Subject: [TUHS] XID register Message-ID: SunRPC, among other protocols, needs transaction IDs (XIDs) to distinguish RPCs.For SunRPC, it's important that XIDs not be reused (not for all protocols; 9p has no such requirement). Stateless protocols like NFS and reused XIDs can get messy. There is a vague, 30 year old memory, I have, that at some point SPARC got a time register, or some other register, that always provided a different answer each time it was read, even if read back to back, in part to enable creation of non-reused XIDs. Note that things like the TSC or RISC-V MTIME register make no such guarantee. I am pretty sure someone here can fill me in, or tell me I'm wrong, about my SPARC memory. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Dec 5 07:12:24 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 04 Dec 2023 21:12:24 +0000 Subject: [TUHS] Apologies, I Owe Someone On List a V7 Manual Binder Set Message-ID: Something seems to have slipped through my recordkeeping, someone on list had spoken up with an interest in a free set of vintage V7 manual binders I got in a set of stuff from MIT Lincoln Labs. If you originally spoke up I'm sorry I've misplaced the email in which you sent me your shipping address. I've still got the binders and am finally in a place I can focus on putting my next post-office trip together. I'm a non-vehiculite so I tend to hold until I've got a few things to mail before packing a bag to carry down to the post-office. I do intend to make good on sending this to the first person that had spoken up last time (and I think you're the only person that bit) but if it gets to be several weeks out and I haven't heard from you (but have heard from anyone else) it may find a different destination. I'll give a few weeks though, not trying to rescind this and hand it to someone else instead. By the by just a reminder that this isn't a completely stock V7 manual, the Volume 1 manpages have a few additions such as the RAND editor and some other odds and ends. IIRC the only base page that has been replaced (as opposed to added pages) should be od(1). - Matt G. P.S. Just to raise the awareness for the more collector-y types, it looks like there is a relatively thorough SVR4 (blue books) manual set bumping around on eBay right now. The catch, it's going for $1,500, which as an owner of a comparable subset and some they're missing, I feel that is overkill and then some...but I don't understand nor want to understand the collector market. Anywho, if this is something your library is burning to include and you're looking to make a donation to that person's retirement fund...then they're up and ripe for the taking. In any case, this set is not complete, not that they're implying that, but I could only really see selling a truly, verifiably complete collection for that sort of asking price. These are a mismash of 3B and 386 versions and the set is missing some odds and ends like the master index, SVID, and any ABI documents. https://www.ebay.com/itm/204564417674 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Dec 10 03:25:10 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 09 Dec 2023 17:25:10 +0000 Subject: [TUHS] Interesting 3B2 Manual on eBay Message-ID: Spotted this this morning: [https://www.ebay.com/itm/186172178090](https://www.ebay.com/itm/186172178090?hash=item2b58b9feaa:g:C8EAAOSwx8RlWkeJ&amdata=enc%3AAQAIAAAAwI9u5Q4YV0drDW0ZDakivbHqP%2F23s1n435t3sOiBnJYsnszpSsjh4y4blvGh78FVv82LMD%2BqO0mXAwNfb8mJyhPtHERIbWQvZVZjwU6eKv17AfwcDj3O4J0rojaOaRekGAkJiblX%2BcFsRRFYmfhC2k9AWhgz24OJvajk0RBALOFKzQq%2BwYkH01HkSTjmg4zCJHqZor1cFBpXTrDQsh1vsha3SgnU4oXxyGdx5XKdYDYguslA%2FnVWmlOAxHQMdxXm0Q%3D%3D%7Ctkp%3ABk9SR6CWkvmJYw) After the link is a "Western Electric 3B2 Model 300 C Programming Language Manual". The manual is from Februrary of 1984 and is of the same visual motif as the System V manuals for the 3B5 as well as DWB documentation released at the time, this motif being a small grey binder with a large orange square in the middle (as opposed to small grey binders with the AT&T death star motif that were contemporary to this time as well.) After these two cover styles, which follow the grid patterns System V original documentation, ATTIS then switches to the red covers that are seen throughout the rest of the 80s until the blue SVR4 books and the kinda criss-crossy grid pattern found on their late 80s stuff (not just UNIX, I've seen a similar motif on documentation shipped with AT&T telephones of the period, but in grey) Interestingly, despite the date, it is still labeled Western Electric, which is strange because the 3B5 manual I have is from 1983 I'm fairly certain but doesn't have "Western Electric" on the cover. Maybe there were mixed stocks of the professionally printed binder covers from the 1982-1984 timeframe with and without WECo branding at the same time. In any case, this one is still in the plastic and even has the 5 1/2 floppies with the SGS and other C support bits (and AT&T death star logos.) I don't plan on getting this as it's just a pinch later than where my focus is right now, but figured I'd mention it on list in case someone is looking for something like this. I got everything I needed from the pictures. - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sun Dec 10 06:30:14 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 9 Dec 2023 15:30:14 -0500 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. Message-ID: I'm sure this is already known, but Nokia is relocating Bell Labs to New Brunswick. Goodbye, Unix Room! https://www.roi-nj.com/2023/12/08/real_estate/nokia-bell-labs-is-moving-to-helix-in-new-brunswick/ - Dan C. From tuhs at tuhs.org Sun Dec 10 06:37:41 2023 From: tuhs at tuhs.org (John Floren via TUHS) Date: Sat, 9 Dec 2023 12:37:41 -0800 (PST) Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: I can't believe they'd give up the building, it's a beautiful structure. Maybe they'll use it for other groups. john From douglas.mcilroy at dartmouth.edu Sun Dec 10 07:36:25 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 9 Dec 2023 16:36:25 -0500 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. Message-ID: Really sobering is the estimate that it will bring 1000 jobs to New Brunswick. That's a small fraction of the capacity of Murray Hill. On the upside is proximity to Rutgers. Contrary to what the article said, Murray Hill does not date from the Labs' foundation in 1925. The Labs was in the meat-packing district on West Street in New York in a building now called Westbeth, said to be the world's largest artist community. The High Line runs right through it. I worked there one summer in the penthouse with a fine view of ship traffic on the Hudson. Murray Hill opened in 1941 and West Street closed in about 1967. > Goodbye, Unix Room! The Unix Room was dismantled some time ago, but its quirky contents were grabbed by the Labs archivist, who had them on display at the Unix50 celebration--pink flamingo, G. R. Emlin, CCW clock and all. I wonder whether these relics will make the move. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sun Dec 10 08:45:24 2023 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 9 Dec 2023 17:45:24 -0500 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: Some years ago I tracked down the location of the original Labs and walked by. The space where the trains used to be able to go is very odd looking. On Sat, Dec 9, 2023 at 4:45 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > Really sobering is the estimate that it will bring 1000 jobs to New > Brunswick. That's a small fraction of the capacity of Murray Hill. On the > upside is proximity to Rutgers. > > Contrary to what the article said, Murray Hill does not date from the > Labs' foundation in 1925. The Labs was in the meat-packing district on West > Street in New York in a building now called Westbeth, said to be the > world's largest artist community. The High Line runs right through it. I > worked there one summer in the penthouse with a fine view of ship traffic > on the Hudson. Murray Hill opened in 1941 and West Street closed in about > 1967. > > > Goodbye, Unix Room! > > The Unix Room was dismantled some time ago, but its quirky contents were > grabbed by the Labs archivist, who had them on display at the Unix50 > celebration--pink flamingo, G. R. Emlin, CCW clock and all. I wonder > whether these relics will make the move. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Dec 10 13:33:47 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 10 Dec 2023 03:33:47 +0000 Subject: [TUHS] Some Wiki Documentation of...Documentation Message-ID: After much saying I would and never getting around to it, I've finally started filling out a bit of documentation on the various UNIX manuals I've been tracking down, fleshing out history around, tracing bibliographic references though, etc etc. https://wiki.tuhs.org/doku.php?id=publications:manuals Thus far I've got the research and CB pages filled out from available information, and PWB/commercial up through about '85-'86, give or take some things. I apologize in advance if I've omitted your favorite piece of trivia or got something wrong, please suggest corrections in any areas needing them, or even better, a Wiki is a communal resource so with Warren's OK, I'm sure you can also make contributions. Most of the pictures are from my own library, although I've added a few others from thing around the net. There are links to various documents covered, TUHS content where most appropriate, a few archive.org and bitsavers links here and there. I don't intend to include links to any documents after System V's initial 1983 run, just pictures of covers for ease of identification. I've already mentioned a few times but I highly encourage contributions. I intend to do another round at this sometime soon and round out at least the BSD stuff and later System V. If anyone else has photographs or documents they think should be in these articles and you don't want to do the Wiki part yourself, feel free to send me stuff and I'll make sure it gets put up there. Finally, some reflection on the path here. "What was UNIX System IV" was one of those questions that plagued my mind for a long time, much before I knew much else about the history of UNIX. Not a crucial question by any means, but it was one of those little mysteries I always wanted to know more about, which is what then lead me to trying to find Release 4.0 documents and all that. Of course, that then lead to the rabbit hole of continuing to turn stuff up, I never imagined I'd actually be successful in trying to turn up more info on that version, let alone then continuing to find little pieces of history and slot in missing parts of stories. Along the way I've learned more about this darn operating system than I ever intended on learning and now feel net gain in several areas of my study. Plus, all this Bell System proximity is largely responsible for my interests in telephony as of late, and may come full circle in the gear I got for telephone experiments helping me resurrect this poor UNIX PC I've got sitting on the floor right now. I don't know what I would've been doing with so much of my free time the past few years otherwise, especially these colder months. Hope folks enjoy the commentary! - Matt G. P.S. Combing over things for this, I've found a few more pieces of the UNIX/TS puzzle. The details are in the Release 3.0 section of the PWB/Commerial page linked above. Short of it is there are some interesting "leaks" of the name "UNIX/TS" into Release 3.0 documentation, inconsistently between the sources on the UNIX tree and the physical document I recently obtained. From clemc at ccc.com Mon Dec 11 07:45:32 2023 From: clemc at ccc.com (Clem Cole) Date: Sun, 10 Dec 2023 16:45:32 -0500 Subject: [TUHS] Some Wiki Documentation of...Documentation In-Reply-To: References: Message-ID: Matt - this is wonderful work. Thank you. Clem ᐧ On Sat, Dec 9, 2023 at 10:34 PM segaloco via TUHS wrote: > After much saying I would and never getting around to it, I've finally > started filling out a bit of documentation on the various UNIX manuals I've > been tracking down, fleshing out history around, tracing bibliographic > references though, etc etc. > > https://wiki.tuhs.org/doku.php?id=publications:manuals > > Thus far I've got the research and CB pages filled out from available > information, and PWB/commercial up through about '85-'86, give or take some > things. I apologize in advance if I've omitted your favorite piece of > trivia or got something wrong, please suggest corrections in any areas > needing them, or even better, a Wiki is a communal resource so with > Warren's OK, I'm sure you can also make contributions. > > Most of the pictures are from my own library, although I've added a few > others from thing around the net. There are links to various documents > covered, TUHS content where most appropriate, a few archive.org and > bitsavers links here and there. I don't intend to include links to any > documents after System V's initial 1983 run, just pictures of covers for > ease of identification. > > I've already mentioned a few times but I highly encourage contributions. > I intend to do another round at this sometime soon and round out at least > the BSD stuff and later System V. If anyone else has photographs or > documents they think should be in these articles and you don't want to do > the Wiki part yourself, feel free to send me stuff and I'll make sure it > gets put up there. > > Finally, some reflection on the path here. "What was UNIX System IV" was > one of those questions that plagued my mind for a long time, much before I > knew much else about the history of UNIX. Not a crucial question by any > means, but it was one of those little mysteries I always wanted to know > more about, which is what then lead me to trying to find Release 4.0 > documents and all that. Of course, that then lead to the rabbit hole of > continuing to turn stuff up, I never imagined I'd actually be successful in > trying to turn up more info on that version, let alone then continuing to > find little pieces of history and slot in missing parts of stories. Along > the way I've learned more about this darn operating system than I ever > intended on learning and now feel net gain in several areas of my study. > Plus, all this Bell System proximity is largely responsible for my > interests in telephony as of late, and may come full circle in the gear I > got for telephone experiments helping me resurrect this poor UNIX PC I've > got sitting on the floor right now. I don't know what I would've been > doing with so much of my free time the past few years otherwise, especially > these colder months. > > Hope folks enjoy the commentary! > > - Matt G. > > P.S. Combing over things for this, I've found a few more pieces of the > UNIX/TS puzzle. The details are in the Release 3.0 section of the > PWB/Commerial page linked above. Short of it is there are some interesting > "leaks" of the name "UNIX/TS" into Release 3.0 documentation, > inconsistently between the sources on the UNIX tree and the physical > document I recently obtained. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martymcg at fastmail.com Tue Dec 12 05:46:29 2023 From: martymcg at fastmail.com (Marty McGowan, MIT Club of Princeton) Date: Mon, 11 Dec 2023 14:46:29 -0500 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: Thus following the Holmdel facility into the Halls of Oblivion. my current location, just E of the NJ Tpke, now splits the distance between them. I was in HO in the late '80s, at MH in the mid '90s, there to divide the corporate directory. Anecdote on the latter: The "company to be named" - i.e. Lucent had to shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley for rights to the name -- the internet was young enough that the Name Search committee didn't have "Dot Com" in it's dictionary as yet. =*+[]* Marty McGowan +1 908 230-3739 VP of Membership, MIT Club of Princeton On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: > I can't believe they'd give up the building, it's a beautiful structure. Maybe they'll use it for other groups. > > > john > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Dec 12 07:21:10 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Dec 2023 13:21:10 -0800 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: April 16, 2014, from the Unix room: "I'm about to turn this terminal off, the last one in the Unix Room. It's the same 400MHz Pentium II I've had since before left." On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < martymcg at fastmail.com> wrote: > Thus following the Holmdel facility into the Halls of Oblivion. > > my current location, just E of the NJ Tpke, now splits the distance > between them. > > I was in HO in the late '80s, at MH in the mid '90s, there to divide the > corporate directory. > > Anecdote on the latter: The "company to be named" - i.e. Lucent had to > shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley > for rights to the name -- the internet was young enough that the Name > Search committee didn't have "Dot Com" in it's dictionary as yet. > > =*+[]* Marty McGowan +1 908 230-3739 > VP of Membership, MIT Club of Princeton > > > > > > > > > On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: > > I can't believe they'd give up the building, it's a beautiful structure. > Maybe they'll use it for other groups. > > > john > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Dec 12 10:58:55 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 12 Dec 2023 00:58:55 +0000 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: While my gut says not likely, I'm holding out hope that Nokia is keen on ensuring someone does a historical sweep of the premises before all is said and done. You never know what might be sitting forgotten in a closet somewhere...a lot of history has gone down in those illustrious halls, formative moments in our quest for better technology for which a modern equivalent fails to come to mind. For me it's not just about innovations though, but a culture of curiosity, openness, and what feels like genuine interest in bettering the human condition that seeps from so much of the work accomplished by MH and other Bell Labs sites over the decades. A video I watched recently about the breakup of the Bell System echoed what I see in countless recollections of Bell Labs alumni, a sense that their work was contributing to something greater for everyone, not just the bottom line of the telephone company. Hopefully the lessons Bell Labs has taught many an engineer, scientist, and businessperson over the years outlive these facilities by orders of magnitude, but in either case, sad to see the physical artifacts of such important times passing too into the sands of time. - Matt G. On Monday, December 11th, 2023 at 1:21 PM, ron minnich wrote: > April 16, 2014, from the Unix room: > > "I'm about to turn this terminal off, > the last one in the Unix Room. It's the > same 400MHz Pentium II I've had since > before left." > > On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton wrote: > >> Thus following the Holmdel facility into the Halls of Oblivion. >> >> my current location, just E of the NJ Tpke, now splits the distance between them. >> >> I was in HO in the late '80s, at MH in the mid '90s, there to divide the corporate directory. >> >> Anecdote on the latter: The "company to be named" - i.e. Lucent had to shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley for rights to the name -- the internet was young enough that the Name Search committee didn't have "Dot Com" in it's dictionary as yet. >> >> =*+[]* Marty McGowan +1 908 230-3739 >> [VP of Membership, MIT Club of Princeton](https://alumcommunity.mit.edu/topics/23427/memberships)https://alumcommunity.mit.edu/topics/23427/memberships >> >> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >> >>> I can't believe they'd give up the building, it's a beautiful structure. Maybe they'll use it for other groups. >>> >>> john -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Tue Dec 12 11:22:24 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Mon, 11 Dec 2023 20:22:24 -0500 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: A company I used to work for was vacating a building. I asked, has anyone checked under the raised floor tiles? The answer was no. Well I did and found a lot of history down there. From component parts from long forgotten systems to water cooling lines for long gone IBM heavy metal and a ground window. -Ken On Mon, Dec 11, 2023 at 7:59 PM segaloco via TUHS wrote: > While my gut says not likely, I'm holding out hope that Nokia is keen on > ensuring someone does a historical sweep of the premises before all is said > and done. You never know what might be sitting forgotten in a closet > somewhere...a lot of history has gone down in those illustrious halls, > formative moments in our quest for better technology for which a modern > equivalent fails to come to mind. > > For me it's not just about innovations though, but a culture of curiosity, > openness, and what feels like genuine interest in bettering the human > condition that seeps from so much of the work accomplished by MH and other > Bell Labs sites over the decades. A video I watched recently about the > breakup of the Bell System echoed what I see in countless recollections of > Bell Labs alumni, a sense that their work was contributing to something > greater for everyone, not just the bottom line of the telephone company. > Hopefully the lessons Bell Labs has taught many an engineer, scientist, and > businessperson over the years outlive these facilities by orders of > magnitude, but in either case, sad to see the physical artifacts of such > important times passing too into the sands of time. > > - Matt G. > On Monday, December 11th, 2023 at 1:21 PM, ron minnich > wrote: > > April 16, 2014, from the Unix room: > > "I'm about to turn this terminal off, > the last one in the Unix Room. It's the > same 400MHz Pentium II I've had since > before left." > > On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < > martymcg at fastmail.com> wrote: > >> Thus following the Holmdel facility into the Halls of Oblivion. >> >> my current location, just E of the NJ Tpke, now splits the distance >> between them. >> >> I was in HO in the late '80s, at MH in the mid '90s, there to divide the >> corporate directory. >> >> Anecdote on the latter: The "company to be named" - i.e. Lucent had to >> shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley >> for rights to the name -- the internet was young enough that the Name >> Search committee didn't have "Dot Com" in it's dictionary as yet. >> >> =*+[]* Marty McGowan +1 908 230-3739 >> VP of Membership, MIT Club of Princeton >> >> >> >> >> >> >> >> >> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >> >> I can't believe they'd give up the building, it's a beautiful structure. >> Maybe they'll use it for other groups. >> >> >> john >> >> >> > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Dec 12 11:25:01 2023 From: norman at oclsc.org (Norman Wilson) Date: Mon, 11 Dec 2023 20:25:01 -0500 (EST) Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. Message-ID: <884763A746125BA153CA56E5E19F3225.for-standards-violators@oclsc.org> ken.unix.guy at gmail.com: A company I used to work for was vacating a building. I asked, has anyone checked under the raised floor tiles? The answer was no. Well I did and found a lot of history down there. From component parts from long forgotten systems to water cooling lines for long gone IBM heavy metal and a ground window. === I bet you didn't find a bowling ball. Norman Wilson Toronto ON From rminnich at gmail.com Tue Dec 12 11:25:18 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Dec 2023 17:25:18 -0800 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: is "PJW in magnets" still there, I wonder. On Mon, Dec 11, 2023 at 5:06 PM segaloco via TUHS wrote: > While my gut says not likely, I'm holding out hope that Nokia is keen on > ensuring someone does a historical sweep of the premises before all is said > and done. You never know what might be sitting forgotten in a closet > somewhere...a lot of history has gone down in those illustrious halls, > formative moments in our quest for better technology for which a modern > equivalent fails to come to mind. > > For me it's not just about innovations though, but a culture of curiosity, > openness, and what feels like genuine interest in bettering the human > condition that seeps from so much of the work accomplished by MH and other > Bell Labs sites over the decades. A video I watched recently about the > breakup of the Bell System echoed what I see in countless recollections of > Bell Labs alumni, a sense that their work was contributing to something > greater for everyone, not just the bottom line of the telephone company. > Hopefully the lessons Bell Labs has taught many an engineer, scientist, and > businessperson over the years outlive these facilities by orders of > magnitude, but in either case, sad to see the physical artifacts of such > important times passing too into the sands of time. > > - Matt G. > On Monday, December 11th, 2023 at 1:21 PM, ron minnich > wrote: > > April 16, 2014, from the Unix room: > > "I'm about to turn this terminal off, > the last one in the Unix Room. It's the > same 400MHz Pentium II I've had since > before left." > > On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < > martymcg at fastmail.com> wrote: > >> Thus following the Holmdel facility into the Halls of Oblivion. >> >> my current location, just E of the NJ Tpke, now splits the distance >> between them. >> >> I was in HO in the late '80s, at MH in the mid '90s, there to divide the >> corporate directory. >> >> Anecdote on the latter: The "company to be named" - i.e. Lucent had to >> shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley >> for rights to the name -- the internet was young enough that the Name >> Search committee didn't have "Dot Com" in it's dictionary as yet. >> >> =*+[]* Marty McGowan +1 908 230-3739 >> VP of Membership, MIT Club of Princeton >> >> >> >> >> >> >> >> >> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >> >> I can't believe they'd give up the building, it's a beautiful structure. >> Maybe they'll use it for other groups. >> >> >> john >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Dec 12 12:36:26 2023 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Mon, 11 Dec 2023 21:36:26 -0500 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: The protons must have decayed by now. On Mon, Dec 11, 2023 at 8:25 PM ron minnich wrote: > is "PJW in magnets" still there, I wonder. > > On Mon, Dec 11, 2023 at 5:06 PM segaloco via TUHS wrote: > >> While my gut says not likely, I'm holding out hope that Nokia is keen on >> ensuring someone does a historical sweep of the premises before all is said >> and done. You never know what might be sitting forgotten in a closet >> somewhere...a lot of history has gone down in those illustrious halls, >> formative moments in our quest for better technology for which a modern >> equivalent fails to come to mind. >> >> For me it's not just about innovations though, but a culture of >> curiosity, openness, and what feels like genuine interest in bettering the >> human condition that seeps from so much of the work accomplished by MH and >> other Bell Labs sites over the decades. A video I watched recently about >> the breakup of the Bell System echoed what I see in countless recollections >> of Bell Labs alumni, a sense that their work was contributing to something >> greater for everyone, not just the bottom line of the telephone company. >> Hopefully the lessons Bell Labs has taught many an engineer, scientist, and >> businessperson over the years outlive these facilities by orders of >> magnitude, but in either case, sad to see the physical artifacts of such >> important times passing too into the sands of time. >> >> - Matt G. >> On Monday, December 11th, 2023 at 1:21 PM, ron minnich < >> rminnich at gmail.com> wrote: >> >> April 16, 2014, from the Unix room: >> >> "I'm about to turn this terminal off, >> the last one in the Unix Room. It's the >> same 400MHz Pentium II I've had since >> before left." >> >> On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < >> martymcg at fastmail.com> wrote: >> >>> Thus following the Holmdel facility into the Halls of Oblivion. >>> >>> my current location, just E of the NJ Tpke, now splits the distance >>> between them. >>> >>> I was in HO in the late '80s, at MH in the mid '90s, there to divide the >>> corporate directory. >>> >>> Anecdote on the latter: The "company to be named" - i.e. Lucent had to >>> shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley >>> for rights to the name -- the internet was young enough that the Name >>> Search committee didn't have "Dot Com" in it's dictionary as yet. >>> >>> =*+[]* Marty McGowan +1 908 230-3739 <(908)%20230-3739> >>> VP of Membership, MIT Club of Princeton >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >>> >>> I can't believe they'd give up the building, it's a beautiful structure. >>> Maybe they'll use it for other groups. >>> >>> >>> john >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenbob at gmail.com Tue Dec 12 15:54:41 2023 From: kenbob at gmail.com (Ken Thompson) Date: Mon, 11 Dec 2023 21:54:41 -0800 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: there was a room with left-hand screw 100 watt light bulbs and sockets. On Mon, Dec 11, 2023 at 6:36 PM Peter Weinberger (温博格) via TUHS < tuhs at tuhs.org> wrote: > The protons must have decayed by now. > > On Mon, Dec 11, 2023 at 8:25 PM ron minnich wrote: > >> is "PJW in magnets" still there, I wonder. >> >> On Mon, Dec 11, 2023 at 5:06 PM segaloco via TUHS wrote: >> >>> While my gut says not likely, I'm holding out hope that Nokia is keen on >>> ensuring someone does a historical sweep of the premises before all is said >>> and done. You never know what might be sitting forgotten in a closet >>> somewhere...a lot of history has gone down in those illustrious halls, >>> formative moments in our quest for better technology for which a modern >>> equivalent fails to come to mind. >>> >>> For me it's not just about innovations though, but a culture of >>> curiosity, openness, and what feels like genuine interest in bettering the >>> human condition that seeps from so much of the work accomplished by MH and >>> other Bell Labs sites over the decades. A video I watched recently about >>> the breakup of the Bell System echoed what I see in countless recollections >>> of Bell Labs alumni, a sense that their work was contributing to something >>> greater for everyone, not just the bottom line of the telephone company. >>> Hopefully the lessons Bell Labs has taught many an engineer, scientist, and >>> businessperson over the years outlive these facilities by orders of >>> magnitude, but in either case, sad to see the physical artifacts of such >>> important times passing too into the sands of time. >>> >>> - Matt G. >>> On Monday, December 11th, 2023 at 1:21 PM, ron minnich < >>> rminnich at gmail.com> wrote: >>> >>> April 16, 2014, from the Unix room: >>> >>> "I'm about to turn this terminal off, >>> the last one in the Unix Room. It's the >>> same 400MHz Pentium II I've had since >>> before left." >>> >>> On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < >>> martymcg at fastmail.com> wrote: >>> >>>> Thus following the Holmdel facility into the Halls of Oblivion. >>>> >>>> my current location, just E of the NJ Tpke, now splits the distance >>>> between them. >>>> >>>> I was in HO in the late '80s, at MH in the mid '90s, there to divide >>>> the corporate directory. >>>> >>>> Anecdote on the latter: The "company to be named" - i.e. Lucent had to >>>> shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley >>>> for rights to the name -- the internet was young enough that the Name >>>> Search committee didn't have "Dot Com" in it's dictionary as yet. >>>> >>>> =*+[]* Marty McGowan +1 908 230-3739 <(908)%20230-3739> >>>> VP of Membership, MIT Club of Princeton >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >>>> >>>> I can't believe they'd give up the building, it's a beautiful >>>> structure. Maybe they'll use it for other groups. >>>> >>>> >>>> john >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Dec 12 15:58:37 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 11 Dec 2023 22:58:37 -0700 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: Why ? Pranksters or is there some application that benefits from left hand screwed light bulbs? Warner On Mon, Dec 11, 2023, 10:55 PM Ken Thompson wrote: > there was a room with left-hand screw > 100 watt light bulbs and sockets. > > > On Mon, Dec 11, 2023 at 6:36 PM Peter Weinberger (温博格) via TUHS < > tuhs at tuhs.org> wrote: > >> The protons must have decayed by now. >> >> On Mon, Dec 11, 2023 at 8:25 PM ron minnich wrote: >> >>> is "PJW in magnets" still there, I wonder. >>> >>> On Mon, Dec 11, 2023 at 5:06 PM segaloco via TUHS wrote: >>> >>>> While my gut says not likely, I'm holding out hope that Nokia is keen >>>> on ensuring someone does a historical sweep of the premises before all is >>>> said and done. You never know what might be sitting forgotten in a closet >>>> somewhere...a lot of history has gone down in those illustrious halls, >>>> formative moments in our quest for better technology for which a modern >>>> equivalent fails to come to mind. >>>> >>>> For me it's not just about innovations though, but a culture of >>>> curiosity, openness, and what feels like genuine interest in bettering the >>>> human condition that seeps from so much of the work accomplished by MH and >>>> other Bell Labs sites over the decades. A video I watched recently about >>>> the breakup of the Bell System echoed what I see in countless recollections >>>> of Bell Labs alumni, a sense that their work was contributing to something >>>> greater for everyone, not just the bottom line of the telephone company. >>>> Hopefully the lessons Bell Labs has taught many an engineer, scientist, and >>>> businessperson over the years outlive these facilities by orders of >>>> magnitude, but in either case, sad to see the physical artifacts of such >>>> important times passing too into the sands of time. >>>> >>>> - Matt G. >>>> On Monday, December 11th, 2023 at 1:21 PM, ron minnich < >>>> rminnich at gmail.com> wrote: >>>> >>>> April 16, 2014, from the Unix room: >>>> >>>> "I'm about to turn this terminal off, >>>> the last one in the Unix Room. It's the >>>> same 400MHz Pentium II I've had since >>>> before left." >>>> >>>> On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < >>>> martymcg at fastmail.com> wrote: >>>> >>>>> Thus following the Holmdel facility into the Halls of Oblivion. >>>>> >>>>> my current location, just E of the NJ Tpke, now splits the distance >>>>> between them. >>>>> >>>>> I was in HO in the late '80s, at MH in the mid '90s, there to divide >>>>> the corporate directory. >>>>> >>>>> Anecdote on the latter: The "company to be named" - i.e. Lucent had to >>>>> shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon Valley >>>>> for rights to the name -- the internet was young enough that the Name >>>>> Search committee didn't have "Dot Com" in it's dictionary as yet. >>>>> >>>>> =*+[]* Marty McGowan +1 908 230-3739 <(908)%20230-3739> >>>>> VP of Membership, MIT Club of Princeton >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >>>>> >>>>> I can't believe they'd give up the building, it's a beautiful >>>>> structure. Maybe they'll use it for other groups. >>>>> >>>>> >>>>> john >>>>> >>>>> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenbob at gmail.com Tue Dec 12 16:03:10 2023 From: kenbob at gmail.com (Ken Thompson) Date: Mon, 11 Dec 2023 22:03:10 -0800 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: they were regular in the ny subway to stop theft. some companies in ny also got them for the same reason. my guess is that bell labs (in ny) did and brought them out to mh. someone rewired someones desk lamp. i dont know how that worked out. On Mon, Dec 11, 2023 at 9:58 PM Warner Losh wrote: > Why ? Pranksters or is there some application that benefits from left hand > screwed light bulbs? > > Warner > > On Mon, Dec 11, 2023, 10:55 PM Ken Thompson wrote: > >> there was a room with left-hand screw >> 100 watt light bulbs and sockets. >> >> >> On Mon, Dec 11, 2023 at 6:36 PM Peter Weinberger (温博格) via TUHS < >> tuhs at tuhs.org> wrote: >> >>> The protons must have decayed by now. >>> >>> On Mon, Dec 11, 2023 at 8:25 PM ron minnich wrote: >>> >>>> is "PJW in magnets" still there, I wonder. >>>> >>>> On Mon, Dec 11, 2023 at 5:06 PM segaloco via TUHS >>>> wrote: >>>> >>>>> While my gut says not likely, I'm holding out hope that Nokia is keen >>>>> on ensuring someone does a historical sweep of the premises before all is >>>>> said and done. You never know what might be sitting forgotten in a closet >>>>> somewhere...a lot of history has gone down in those illustrious halls, >>>>> formative moments in our quest for better technology for which a modern >>>>> equivalent fails to come to mind. >>>>> >>>>> For me it's not just about innovations though, but a culture of >>>>> curiosity, openness, and what feels like genuine interest in bettering the >>>>> human condition that seeps from so much of the work accomplished by MH and >>>>> other Bell Labs sites over the decades. A video I watched recently about >>>>> the breakup of the Bell System echoed what I see in countless recollections >>>>> of Bell Labs alumni, a sense that their work was contributing to something >>>>> greater for everyone, not just the bottom line of the telephone company. >>>>> Hopefully the lessons Bell Labs has taught many an engineer, scientist, and >>>>> businessperson over the years outlive these facilities by orders of >>>>> magnitude, but in either case, sad to see the physical artifacts of such >>>>> important times passing too into the sands of time. >>>>> >>>>> - Matt G. >>>>> On Monday, December 11th, 2023 at 1:21 PM, ron minnich < >>>>> rminnich at gmail.com> wrote: >>>>> >>>>> April 16, 2014, from the Unix room: >>>>> >>>>> "I'm about to turn this terminal off, >>>>> the last one in the Unix Room. It's the >>>>> same 400MHz Pentium II I've had since >>>>> before left." >>>>> >>>>> On Mon, Dec 11, 2023 at 11:46 AM Marty McGowan, MIT Club of Princeton < >>>>> martymcg at fastmail.com> wrote: >>>>> >>>>>> Thus following the Holmdel facility into the Halls of Oblivion. >>>>>> >>>>>> my current location, just E of the NJ Tpke, now splits the distance >>>>>> between them. >>>>>> >>>>>> I was in HO in the late '80s, at MH in the mid '90s, there to divide >>>>>> the corporate directory. >>>>>> >>>>>> Anecdote on the latter: The "company to be named" - i.e. Lucent had >>>>>> to shell out Hundreds of 1000s to Yet Another Garage Tronics in Silicon >>>>>> Valley for rights to the name -- the internet was young enough that the >>>>>> Name Search committee didn't have "Dot Com" in it's dictionary as yet. >>>>>> >>>>>> =*+[]* Marty McGowan +1 908 230-3739 <(908)%20230-3739> >>>>>> VP of Membership, MIT Club of Princeton >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Dec 9, 2023, at 15:37, John Floren via TUHS wrote: >>>>>> >>>>>> I can't believe they'd give up the building, it's a beautiful >>>>>> structure. Maybe they'll use it for other groups. >>>>>> >>>>>> >>>>>> john >>>>>> >>>>>> >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Dec 12 17:50:00 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 12 Dec 2023 00:50:00 -0700 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: <884763A746125BA153CA56E5E19F3225.for-standards-violators@oclsc.org> References: <884763A746125BA153CA56E5E19F3225.for-standards-violators@oclsc.org> Message-ID: <202312120750.3BC7o0GI004435@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > I bet you didn't find a bowling ball. > > Norman Wilson > Toronto ON OK, I'll bite. What's the story / reference behind this? Thanks, Arnold From jnc at mercury.lcs.mit.edu Tue Dec 12 22:19:26 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 12 Dec 2023 07:19:26 -0500 (EST) Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. Message-ID: <20231212121926.3293918C082@mercury.lcs.mit.edu> > From: Ken Thompson > someone rewired someones desk lamp. i dont know how that worked out. Sometimes electrical 'jokes' don't pan out - in a big way. I was hacking the light switch in Jerry Saltzer's office (I don't recall exactly what I was planning; IIRC, something mundane and lame like flipping it upside down), and as I took it out of the box, the hot terminal touched the side of the box (which was, properly, well grounded). The entire 5th floor powered down. What had happened was that the breaker for Jerry's office probably hadn't been tripped in decades (maybe since it was put in), and it was apparently a little sticky. Also, the floor had originally been wired back when all that most people had in their offices, in the way of electrical load, was an incandescent desk lamp or so. Now, most offices had, not just a couple of terminals, most also had an Alto - greatly increased overall load. The total draw for the whole floor was now very close to the rating of the main breaker for the whole floor - and my slip of the hand had put it over. And that one _wasn't_ sticky. The worst part was that when we looked in the 5th floor electrical closet, we couldn't find anything wrong. An electrician was summoned (luckily, or unluckily, it was daytime; not having access to a 5th floor master, we'd gone in while everything was unlocked - daytime), and he finally located the breaker responsible - in an electrical closet on the 9th floor. I got carpeted by Jerry, when he got back; I escaped without major punishment,in part, IIRC, because I pointed out that I'd exposed a previously-unsuspected issue. (I have this vague memory that the wiring on the 5th floor was upgraded not long after.) That wasn't the only historic CS building that has been abandoned. 545 Technology Square, one-time home of the Multics project, the MIT AI Lab, and much else (including the above story) was exited by MIT some years ago. There, too, some history was abandoned - including the hack that allowed people to call the elevators to their floor from their terminals. (Some hackers had run some carefully disguised wires up into the elevator controller - ran them along the back of structural members, carefully hidden - and thence to the TV-11 that ran all the Knight TV bit-mapped displays attached to the AI ITS time-sharing machine. So from a Knight TV console, if you typed 'Escape E', it called the elevator to your floor - the code: https://github.com/PDP-10/its/blob/master/src/system/tv.147 even has a table - at ELETAB: - giving which floor each console was on, so it got called to the correct floor. I wonder what happened to that when the Knight TV system was ditched? Did it get moved to another machine? Actually, I have a dim memory that the elevator people found it, and it was removed.) Noel From lars at nocrew.org Wed Dec 13 01:46:06 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 12 Dec 2023 15:46:06 +0000 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: <20231212121926.3293918C082@mercury.lcs.mit.edu> (Noel Chiappa's message of "Tue, 12 Dec 2023 07:19:26 -0500 (EST)") References: <20231212121926.3293918C082@mercury.lcs.mit.edu> Message-ID: <7wy1dz5sqp.fsf@junk.nocrew.org> Noel Chiappa writes: > That wasn't the only historic CS building that has been abandoned. 545 > Technology Square, one-time home of the Multics project, the MIT AI > Lab, and much else (including the above story) was exited by MIT some > years ago. The Stanford AI lab met a similar fate when its home, the D.C. Power building was abandoned. I think it was torn down. Here's a video from after the AI lab moved out. From the looks of it, right after some zombie apocalypse. https://www.youtube.com/watch?v=lrg_R3VYnEU From aek at bitsavers.org Wed Dec 13 03:43:10 2023 From: aek at bitsavers.org (Al Kossow) Date: Tue, 12 Dec 2023 09:43:10 -0800 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: <7wy1dz5sqp.fsf@junk.nocrew.org> References: <20231212121926.3293918C082@mercury.lcs.mit.edu> <7wy1dz5sqp.fsf@junk.nocrew.org> Message-ID: <9e368158-1989-3cdc-6603-62d1c6c5e885@bitsavers.org> On 12/12/23 7:46 AM, Lars Brinkhoff wrote: > I think it was torn down. Completely gone, now part of the open space preserve. From tuhs at tuhs.org Thu Dec 14 11:37:42 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 14 Dec 2023 01:37:42 +0000 Subject: [TUHS] BSTJ DMERT "Programs From Other Processors" Comment Message-ID: In a BSTJ article[1] it is said "The availability of a simulated UNIX operating system in DMERT allows UNIX programs from other processors to execute on the 3B20D Processor." Does this just mean C programs which are rebuilt or is there some implication DMERT's particular UNIX environment featured some sort of emulation facilities? I may be reading too much into it... - Matt G. [1] - https://archive.org/details/bstj62-1-303/page/n11/mode/2up P.S. I learned I may walk past DMERT and a 3B20D most days, there's a long-operational telephone CO on my usual walk that through referencing public records I've discovered has a WECo 5ESS up in it somewhere. That's all the listing said, dunno if WECo is given as meaning an early model or just a generic name. Either way...so close yet so far, makes me ever so curious what dusty old bookshelves in that building might hold. From tuhs at tuhs.org Thu Dec 14 12:10:09 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 14 Dec 2023 02:10:09 +0000 Subject: [TUHS] Possible Moment of u_man/a_man Split Message-ID: Somewhere between UNIX Release 3.0 and Release 4.1, a portion of the User's Manual was split off into a separate Administrator's Manual, leading to a reordering of the sections among other things.  In the directories, these pieces would be placed in u_man and a_man respectively. There may be some evidence of the manual being intact as of 4.0 or at least not completely separated. I've found consistently that references to manpages in the Documents for UNIX Release 4.0 collection follow their pre-split numbering and all refer to the User's Manual. The catch is that all references are to the UNIX User's Manual Release 3.0, so this may not point conclusively to the state of /usr/man on disk at the time. The Release 4.1 Administrator's Manual hasn't turned up yet but the User's Manual reflects the renumbering and is less the a_man pages. To complete the circle, the various Release 5.0 revisions of the documents do refer to the Administrator's Manual where appropriate. Was the manual getting split up of any great shock or was it to be expected as the software grew? It would come to happen again between SysV and SVR2 with p_man. Out of curiosity I checked how my own manpage set is organized, it seems to be of the research order, with special files in section 4 rather than section 7 for instance. I've never studied how far reaching the different orders are. - Matt G. From arnold at skeeve.com Thu Dec 14 23:23:08 2023 From: arnold at skeeve.com (Aharon Robbins) Date: Thu, 14 Dec 2023 05:23:08 -0800 Subject: [TUHS] Off topic: BSD timezone function vs. POSIX timezone variable Message-ID: Hi All. This is a bit off-topic, but people here are likely to know the answer. V7 had a timzone function: char *timezone(int zone, int dst); that returned a timezone name. POSIX has a timezone variable which is the offset in seconds from UTC. The man pages for all of {Net,Free,Open}BSD seem to indicate that both are available on those systems. My question is, how? The declarations for both are given as being in . But don't the symbols in libc.a conflict with each other? How does a programmer on *BSD choose which version of timezone they will get? Feel free to reply privately. Thanks, Arnold From leah at vuxu.org Fri Dec 15 01:14:16 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Thu, 14 Dec 2023 16:14:16 +0100 Subject: [TUHS] Off topic: BSD timezone function vs. POSIX timezone variable In-Reply-To: (Aharon Robbins's message of "Thu, 14 Dec 2023 05:23:08 -0800") References: Message-ID: <874jgk7r5j.fsf@vuxu.org> Aharon Robbins writes: > Hi All. > > This is a bit off-topic, but people here are likely to know the answer. > > V7 had a timzone function: > > char *timezone(int zone, int dst); > > that returned a timezone name. POSIX has a timezone variable which is > the offset in seconds from UTC. > > The man pages for all of {Net,Free,Open}BSD seem to indicate that both > are available on those systems. > > My question is, how? The declarations for both are given as being in . > But don't the symbols in libc.a conflict with each other? How does a programmer > on *BSD choose which version of timezone they will get? OpenBSD 7.3 only has "extern long timezone" and no timezone(3) function. FreeBSD 14.0 only has the timezone(3) function (under _BSD_VISIBLE), and doesn't set any variables. -- Leah Neukirchen https://leahneukirchen.org/ From chet.ramey at case.edu Fri Dec 15 01:49:20 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 14 Dec 2023 10:49:20 -0500 Subject: [TUHS] Off topic: BSD timezone function vs. POSIX timezone variable In-Reply-To: <874jgk7r5j.fsf@vuxu.org> References: <874jgk7r5j.fsf@vuxu.org> Message-ID: On 12/14/23 10:14 AM, Leah Neukirchen wrote: > Aharon Robbins writes: > >> Hi All. >> >> This is a bit off-topic, but people here are likely to know the answer. >> >> V7 had a timzone function: >> >> char *timezone(int zone, int dst); >> >> that returned a timezone name. POSIX has a timezone variable which is >> the offset in seconds from UTC. >> >> The man pages for all of {Net,Free,Open}BSD seem to indicate that both >> are available on those systems. >> >> My question is, how? The declarations for both are given as being in . >> But don't the symbols in libc.a conflict with each other? How does a programmer >> on *BSD choose which version of timezone they will get? > > OpenBSD 7.3 only has "extern long timezone" and no timezone(3) function. > > FreeBSD 14.0 only has the timezone(3) function (under _BSD_VISIBLE), > and doesn't set any variables. Darwin (macOS) conditionally defines them. If you want POSIX 2003 compatibility, define __DARWIN_UNIX03 and get extern long timezone __DARWIN_ALIAS(timezone); If you don't define that, you get char *timezone(int, int); -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From imp at bsdimp.com Fri Dec 15 03:28:56 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 14 Dec 2023 10:28:56 -0700 Subject: [TUHS] Off topic: BSD timezone function vs. POSIX timezone variable In-Reply-To: References: Message-ID: On Thu, Dec 14, 2023 at 6:23 AM Aharon Robbins wrote: > Hi All. > > This is a bit off-topic, but people here are likely to know the answer. > tl;dr: FreeBSD retains the old timezone() function because the 4BSD series of releases had it. Other, more modern interfaces are available, but it can be a PITA. It's an XSI-only variable, but one of the few that FreeBSD does not provide. > V7 had a timezone function: > > char *timezone(int zone, int dst); > > that returned a timezone name. Yes. These were compile-time constants of some kind 4*60, "AST", "ADT", /* Atlantic */ 5*60, "EST", "EDT", /* Eastern */ 6*60, "CST", "CDT", /* Central */ 7*60, "MST", "MDT", /* Mountain */ 8*60, "PST", "PDT", /* Pacific */ 0, "GMT", 0, /* Greenwich */ with the comment * Sorry, I don't know all the names. which is (a) not helpful and (b) wrong in the case of GMT (even at the time V7 was released, the official name was UTC for the non-shifting version). This function is only slightly changed to include a couple of more timezones and has the warning in the man page: This interface is for compatibility only; it is impossible to reliably map timezone's arguments to a time zone abbreviation. See ctime(3). This function should never be used. BSD has had a timezone argument to gettimeofday for a long time. It used to return the compiled-in offset from GMT(sic), but that option has been eliminated. The more reliable tzset() function has replaced all of that. It describes how the TZ variable, if set, is used and where to find information about the timezone files. To get the local offset, you need to compare gmtime() to localtime(), though most of the time you want to use asctime to format times, or better, strftime(3). There's extern char *tzname[2] that exports the timezone name(s) from the tzcode that's the companion to what's now the IANA TZ database (aka the olson database). > POSIX has a timezone variable which is > the offset in seconds from UTC. > It' is an optional part of POSIX, though, it's part of XSI_C_LANG_SUPPORT: XSI General C Library a64l( ), daylight, drand48( ), erand48( ), ffs( ), ffsl( ), ffsll( ), getdate( ), hcreate( ), hdestroy( ), hsearch( ), initstate( ), insque( ), jrand48( ), l64a( ), lcong48( ), lfind( ), lrand48( ), lsearch( ), memccpy( ), mrand48( ), nrand48( ), random( ), remque( ), seed48( ), setstate( ), signgam, srand48( ), srandom( ), strptime( ), swab( ), tdelete( ), tfind( ), timezone, tsearch( ), twalk( ) So properly, should only be visible when XSI has been requested (or when everything has been requested). The man pages for all of {Net,Free,Open}BSD seem to indicate that both > are available on those systems. > timezone, the variable, isn't available on FreeBSD. It's not declared anywhere. Only timezone, the massively obsolete compatibility function is defined in time.h. I believe neither is the 'daylight' variable. > My question is, how? The declarations for both are given as being in > . > But don't the symbols in libc.a conflict with each other? How does a > programmer > on *BSD choose which version of timezone they will get? > Generally, the programmer should choose to use other, more modern interfaces. :) timezone, the function, is about useless. To get the offset, you need to get the current time (or the time you are interested in) as a time_t. You'd then call localtime with that time_t to get a struct tm and them timegm with that tm to get localtime as a time_t. Subtract the original time from the result to get seconds west of UTC. Arguably BSDs should just support the timezone variable, but that's hard when there's also a function. You'd likely want it more often than the function, but you also want old code that's referenced it to work too. The code is there, butdisabled in tzconfig.h due to the conflict. > Feel free to reply privately. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Fri Dec 15 05:46:58 2023 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 14 Dec 2023 11:46:58 -0800 Subject: [TUHS] Sad news: Bell Labs leaving Murray Hill. In-Reply-To: References: Message-ID: <504DA640-1BC8-45EF-9A53-CE8B180D70EE@humeweb.com> my wife, karen montgomery, who used to work for kernighan and others at MH, sent me a local posting: “the entire facility from the ground to the floor cabinets and vents are contaminated. they can’t knock anything down or even dig because there are already chemicals flowing downhill in NP (new providence). hence the cancer cluster in the woodbine circle area.” karen grew up on woodbine circle. there is also the NRC decommissioning plan: https://www.nrc.gov/docs/ML0819/ML081910076.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Sun Dec 17 12:01:27 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sat, 16 Dec 2023 21:01:27 -0500 Subject: [TUHS] Compatibility question Message-ID: I have been working with a VAX780 sim running Unix System V r2 VAX780 and am having strange issues. TERM is defined at vt100 When firing up vi at times the cursor is positioned in the wrong place or when inserting text it over writes areas on the screen. I have tried vt100, vt100-am, vt100-nam and none work as expected. Any ideas? Thanks -Ken Happy holidays -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Sun Dec 17 15:55:37 2023 From: davida at pobox.com (David Arnold) Date: Sun, 17 Dec 2023 16:55:37 +1100 Subject: [TUHS] Compatibility question Message-ID: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com>  > On 17 Dec 2023, at 13:02, KenUnix wrote: -8<— > I have tried vt100, vt100-am, vt100-nam and none > work as expected. I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine. Maybe worth a shot? d From tuhs at tuhs.org Sun Dec 17 18:08:59 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 17 Dec 2023 08:08:59 +0000 Subject: [TUHS] Compatibility question In-Reply-To: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> Message-ID: > > I have tried vt100, vt100-am, vt100-nam and none > > work as expected. > > > > -Ken > > > I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine. Maybe worth a shot? > > > > d I'll hopefully be able to offer up hardware confirmation in a week...secured a VT100 for a reasonable price due to missing keyboard...and I happen to have one such keyboard. Ken your images run fine on my install of SimH VAX-11/780 so I'll try and serial that machine straight out to the VT100 once I've got it setup. Fwiw I hopped in vi a few times to build a few sample programs and didn't run into any issues, this is with TERM=vt100, and the enclosing xterm is not 80x24 currently, half a screen in dwm (although naturally the vi window in SimH is the right size.) - Matt G. From brad at anduin.eldar.org Mon Dec 18 00:07:54 2023 From: brad at anduin.eldar.org (Brad Spencer) Date: Sun, 17 Dec 2023 09:07:54 -0500 Subject: [TUHS] Compatibility question In-Reply-To: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> (message from David Arnold on Sun, 17 Dec 2023 16:55:37 +1100) Message-ID: David Arnold writes: >  >> On 17 Dec 2023, at 13:02, KenUnix wrote: > > -8<— > >> I have tried vt100, vt100-am, vt100-nam and none >> work as expected. > > I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine. Maybe worth a shot? > > > > d Unless you are actually using a real VT100 physical serial terminal there is very much a non-zero chance that the terminal emulator that you are using is not really vt100, vt102, or any such thing, but some subset, superset or variant that isn't quite like a real physical VT100, close but not exact. You may try 'ansi' or 'xterm', if either of those are available in the Unix you are using. If not, try a different terminal emulator. Example.. a long time ago in a university far away, there was Data General systems mostly and lots of DG211 terminals. The DG211 have a ansi mode that is very close to vt100, but not quite. Along comes various Unix systems, in particular, a RS6000. Wanting to play Moria (successor to rogue), I found that the ansi mode didn't quite cut it and ended up hacking up a TERMCAP / TERMINFO entry to deal with the issue as best as it was possible. I could never come up with a native DG211 entry that worked any better than my hacks. If I recall, the terminal *MAY* have supported VT52 as well (or that might have been the MV10000 that did some sort of DG211 to VT52 translation) I know I ended up writing a VT52 terminal emulator (for some reason or other... it was a long time ago) and I know I used it on the Unix systems that started to appear around the university as time went on. VT52 was pretty simple and it tended to work pretty well. -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Mon Dec 18 00:47:34 2023 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sun, 17 Dec 2023 15:47:34 +0100 Subject: [TUHS] Compatibility question In-Reply-To: References: Message-ID: <0D871039-FAB8-4E74-B831-32EE4FBDE795@alchemistowl.org> On 17 Dec 2023, at 15:08, Brad Spencer wrote: > ansi mode that is very close to vt100, but not quite. Along comes > various Unix systems, in particular, a RS6000. Wanting to play Moria > (successor to rogue), I found that the ansi mode didn't quite cut it and > ended up hacking up a TERMCAP / TERMINFO entry to deal with the issue as > best as it was possible. The number of times I have heard “I couldn’t run {nethack, rogue, Moria} so I tweaked the termcap / terminfo for the terminal”… I had a similar issue with a WY-180 fixed by the local termcap wizard (not me, I abandoned all hope quite rapidly). Definitely agree that trying “close” terminals is a viable route. Arrigo From frew at ucsb.edu Mon Dec 18 04:04:09 2023 From: frew at ucsb.edu (James Frew) Date: Sun, 17 Dec 2023 10:04:09 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> Message-ID: <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")? AFAIK none of the emulators (or "VT100-compatible" iron, for that matter) ever bothered to replicate this (for which hackers prone to motion sickness remain grateful 🤢) /Frew P.S.: Fond memories of the USENIX where Rob Pike, in a talk describing the Blit, announced "and [pause] it is NOT VT-100 compatible", to thunderous applause. A lot of termcap tweakers in that audience... On 2023-12-17 00:08, segaloco via TUHS wrote: > secured a VT100 for a reasonable price -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Mon Dec 18 04:13:26 2023 From: web at loomcom.com (Seth Morabito) Date: Sun, 17 Dec 2023 10:13:26 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: Message-ID: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> On 12/16/23 6:01 PM, KenUnix wrote: > I have been working with a VAX780 sim running > Unix System V r2 VAX780 and am having strange > issues. > > TERM is defined at vt100 > > When firing up vi at times the cursor is positioned > in the wrong place or when inserting text it over > writes areas on the screen. I have most often encountered this when my terminal window size was larger than exactly 80x24. If you're using Xterm or Gnome-terminal or a Windows terminal, for example, make sure that the window is exactly 80 columns wide by 24 lines tall, or the VT100 termcap inside the emulator will be very confused. -Seth From lars at nocrew.org Mon Dec 18 04:18:01 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 17 Dec 2023 18:18:01 +0000 Subject: [TUHS] Compatibility question In-Reply-To: <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> (James Frew's message of "Sun, 17 Dec 2023 10:04:09 -0800") References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Message-ID: <7wv88w3d7q.fsf@junk.nocrew.org> James Frew wrote: > Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")? > AFAIK none of the emulators (or "VT100-compatible" iron, for that matter) > ever bothered to replicate this (for which hackers prone to motion sickness > remain grateful 🤢) I made one which simulates the VT100 hardware and runs the original ROM. There are two more emulators like that. From tuhs at tuhs.org Mon Dec 18 04:23:10 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 17 Dec 2023 18:23:10 +0000 Subject: [TUHS] Compatibility question In-Reply-To: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> Message-ID: > On 12/16/23 6:01 PM, KenUnix wrote: > > > I have been working with a VAX780 sim running > > Unix System V r2 VAX780 and am having strange > > issues. > > > > TERM is defined at vt100 > > > > When firing up vi at times the cursor is positioned > > in the wrong place or when inserting text it over > > writes areas on the screen. > > > I have most often encountered this when my terminal window size was > larger than exactly 80x24. > > If you're using Xterm or Gnome-terminal or a Windows terminal, for > example, make sure that the window is exactly 80 columns wide by 24 > lines tall, or the VT100 termcap inside the emulator will be very confused. > > -Seth I'm not so sure on that one, I ran this on an arbitrarily sized xterm (I use a tiling WM) and it sized the vi session correctly and didn't seem to exhibit cursor anomalies. This encapsulating terminal is a recent (past year) build of xterm using I believe the xterm256 or whatever its named TERM, in which I then launched your script using my local copy of vax780. Tried just now in Linux fbcon with a TERM of "linux" and likewise the vi session still seems to size to 80x24 appropriately and doesn't have any cursor positioning issues. Note in both cases the TERM variable I describe is the *host* terminal, TERM in the emulated session is vt100. - Matt G. From paul.winalski at gmail.com Mon Dec 18 04:48:09 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 17 Dec 2023 13:48:09 -0500 Subject: [TUHS] Compatibility question In-Reply-To: <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Message-ID: One problem that the VT100 emulators may have is that they behave according to the published VT100 specifications rather than the actual hardware behavior. The VT100 had notoriously buggy firmware. Alan Kotok, one of DEC's early engineers, encountered some of these and was annoyed enough about it that he wrote a program to generate a complete list of escape sequences--legal and illegal--which he fed to his VT100 terminal. The results were highly entertaining. Some perfectly valid escape sequences were mishandled by the firmware and had behavior that didn't match the documentation. Even worse, some illegal escape sequences caused catastrophic behavior, such as the terminal freezing with the alarm continuously on--the only way out was to power-cycle the terminal. One particularly nasty escape sequence caused corruption of the EPROM such that the terminal crashed on power-up or restart, resulting in an infinite crash-and-restart loop that could only be fixed by sending the terminal in for a factory reset. Kotok published his results within DEC engineering and shortly thereafter "email bombs" containing escape sequences that triggered some of the milder of the bugs started circulating. The VAX/VMS mail utility had to be changed to filter out escape sequences by default. -Paul W. From imp at bsdimp.com Mon Dec 18 04:59:52 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 17 Dec 2023 11:59:52 -0700 Subject: [TUHS] Compatibility question In-Reply-To: References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Message-ID: On Sun, Dec 17, 2023 at 11:48 AM Paul Winalski wrote: > One problem that the VT100 emulators may have is that they behave > according to the published VT100 specifications rather than the actual > hardware behavior. > They behave like the author of the emulator thinks the documentation describes. But often, ambiguity in descriptions lead to bad decisions here, especially when you go to the far right of the screen, the bottom right corner, etc. There's several quirks of VT100 behavior that just aren't clearly documented. They aren't bugs, per se, but people depend on that behavior. > The VT100 had notoriously buggy firmware. Alan Kotok, one of DEC's > early engineers, encountered some of these and was annoyed enough > about it that he wrote a program to generate a complete list of escape > sequences--legal and illegal--which he fed to his VT100 terminal. The > results were highly entertaining. Some perfectly valid escape > sequences were mishandled by the firmware and had behavior that didn't > match the documentation. Even worse, some illegal escape sequences > caused catastrophic behavior, such as the terminal freezing with the > alarm continuously on--the only way out was to power-cycle the > terminal. One particularly nasty escape sequence caused corruption of > the EPROM such that the terminal crashed on power-up or restart, > resulting in an infinite crash-and-restart loop that could only be > fixed by sending the terminal in for a factory reset. > > Kotok published his results within DEC engineering and shortly > thereafter "email bombs" containing escape sequences that triggered > some of the milder of the bugs started circulating. The VAX/VMS mail > utility had to be changed to filter out escape sequences by default. > Yea... Those are fun... I wonder how many got fixed in later versions? I'd also read somewhere that VT220 development was slowed by having to behave exactly the same way as the VT100s (the above example was one given)... But at least they had the benefit of being able to look at the old firmware code... At least I'd suppose that was a benefit... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Mon Dec 18 05:14:43 2023 From: brad at anduin.eldar.org (Brad Spencer) Date: Sun, 17 Dec 2023 14:14:43 -0500 Subject: [TUHS] Compatibility question In-Reply-To: <7wv88w3d7q.fsf@junk.nocrew.org> (message from Lars Brinkhoff on Sun, 17 Dec 2023 18:18:01 +0000) Message-ID: Lars Brinkhoff writes: > James Frew wrote: >> Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")? >> AFAIK none of the emulators (or "VT100-compatible" iron, for that matter) >> ever bothered to replicate this (for which hackers prone to motion sickness >> remain grateful 🤢) > > I made one which simulates the VT100 hardware and runs the original ROM. > There are two more emulators like that. That is really very neat and honestly not something I would have thought of. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From crossd at gmail.com Mon Dec 18 05:26:01 2023 From: crossd at gmail.com (Dan Cross) Date: Sun, 17 Dec 2023 14:26:01 -0500 Subject: [TUHS] Compatibility question In-Reply-To: <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Message-ID: On Sun, Dec 17, 2023 at 1:13 PM James Frew wrote: > Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")? AFAIK none of the emulators (or "VT100-compatible" iron, for that matter) ever bothered to replicate this (for which hackers prone to motion sickness remain grateful 🤢) HDS terminals could do that. I rather liked it, honestly. I don't recall it ever making me feel sick, but it definitely led to character overruns. :-/ - Dan C. > > /Frew > > P.S.: Fond memories of the USENIX where Rob Pike, in a talk describing the Blit, announced "and [pause] it is NOT VT-100 compatible", to thunderous applause. A lot of termcap tweakers in that audience... > > On 2023-12-17 00:08, segaloco via TUHS wrote: > > secured a VT100 for a reasonable price From imp at bsdimp.com Mon Dec 18 06:08:27 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 17 Dec 2023 13:08:27 -0700 Subject: [TUHS] Compatibility question In-Reply-To: References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Message-ID: On Sun, Dec 17, 2023, 12:26 PM Dan Cross wrote: > On Sun, Dec 17, 2023 at 1:13 PM James Frew wrote: > > Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf > mode")? AFAIK none of the emulators (or "VT100-compatible" iron, for that > matter) ever bothered to replicate this (for which hackers prone to motion > sickness remain grateful 🤢) > > HDS terminals could do that. I rather liked it, honestly. I don't > recall it ever making me feel sick, but it definitely led to character > overruns. :-/ > Smooth scroll was good for 1 application I had. There was a 30 line message with instructions and info about a group. You then hit a hit to fill out a form for more info. The smooth scroll prevented burnin... though the terminal was only active a few months... Every other time, though, I disabled it post haste. Warner - Dan C. > > > > > /Frew > > > > P.S.: Fond memories of the USENIX where Rob Pike, in a talk describing > the Blit, announced "and [pause] it is NOT VT-100 compatible", to > thunderous applause. A lot of termcap tweakers in that audience... > > > > On 2023-12-17 00:08, segaloco via TUHS wrote: > > > > secured a VT100 for a reasonable price > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Dec 18 06:24:33 2023 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 18 Dec 2023 07:24:33 +1100 (EST) Subject: [TUHS] Compatibility question In-Reply-To: References: <7AD36632-2B2F-43E2-999D-4F6373C3C64C@pobox.com> <17d9946c-6f41-4c56-9cb0-3218a2550299@ucsb.edu> Message-ID: On Sun, 17 Dec 2023, Paul Winalski wrote: > One problem that the VT100 emulators may have is that they behave > according to the published VT100 specifications rather than the actual > hardware behavior. DEC did pretty much the same thing with the Unibus to keep out 3rd-party boards; the published specs didn't match the implementation, so your non-DEC board would have subtle timing issues. DEC of course just shrugged and said "Our boards work just fine, so yours must be faulty"... -- Dave From mah at mhorton.net Mon Dec 18 08:51:00 2023 From: mah at mhorton.net (Mary Ann Horton) Date: Sun, 17 Dec 2023 14:51:00 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> Message-ID: <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> The concept of a resizable window didn't appear until GUI interfaces. Originally the hardware terminal had one specific size and vi depended on the screen being that exact size. I suspect that SVr2 was in that category, as the Sun merger of SVr4 would have been the reason to incorporate it. So try a 24x80 window and see if it behaves. Try "stty -a" and see if it mentions rows and columns. If not, what terminfo says (try "infocmp") is what vi will believe. It might also matter how you option your vt100 emulator, and even the native vt100 had setup options, such as wraparound (terminfo calls this auto_right_margin or just am). Vi depends on knowing what the cursor does when it types in the rightmost column. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com On 12/17/23 10:23, segaloco via TUHS wrote: >> On 12/16/23 6:01 PM, KenUnix wrote: >> >>> I have been working with a VAX780 sim running >>> Unix System V r2 VAX780 and am having strange >>> issues. >>> >>> TERM is defined at vt100 >>> >>> When firing up vi at times the cursor is positioned >>> in the wrong place or when inserting text it over >>> writes areas on the screen. >> >> I have most often encountered this when my terminal window size was >> larger than exactly 80x24. >> >> If you're using Xterm or Gnome-terminal or a Windows terminal, for >> example, make sure that the window is exactly 80 columns wide by 24 >> lines tall, or the VT100 termcap inside the emulator will be very confused. >> >> -Seth > I'm not so sure on that one, I ran this on an arbitrarily sized xterm (I use a tiling WM) and it sized the vi session correctly and didn't seem to exhibit cursor anomalies. This encapsulating terminal is a recent (past year) build of xterm using I believe the xterm256 or whatever its named TERM, in which I then launched your script using my local copy of vax780. Tried just now in Linux fbcon with a TERM of "linux" and likewise the vi session still seems to size to 80x24 appropriately and doesn't have any cursor positioning issues. Note in both cases the TERM variable I describe is the *host* terminal, TERM in the emulated session is vt100. > > - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Dec 18 08:59:55 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 17 Dec 2023 22:59:55 +0000 Subject: [TUHS] Compatibility question In-Reply-To: <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: That’s not entirely true. The VT100 could switch modes from 80x24 to 132x14 (the latter was pretty ugly) or with the AVO 132x24. ------ Original Message ------ >From "Mary Ann Horton" To tuhs at tuhs.org Date 12/17/23, 5:51:00 PM Subject [TUHS] Re: Compatibility question >The concept of a resizable window didn't appear until GUI interfaces. >Originally the hardware terminal had one specific size and vi depended >on the screen being that exact size. I suspect that SVr2 was in that >category, as the Sun merger of SVr4 would have been the reason to >incorporate it. So try a 24x80 window and see if it behaves. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Dec 18 09:08:27 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 17 Dec 2023 16:08:27 -0700 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: On Sun, Dec 17, 2023, 4:00 PM Ron Natalie wrote: > That’s not entirely true. The VT100 could switch modes from 80x24 to > 132x14 (the latter was pretty ugly) or with the AVO 132x24. > I recall some VMS programs in v3.2 misbehaving when run in 132x24 mode... Warner ------ Original Message ------ > From "Mary Ann Horton" > To tuhs at tuhs.org > Date 12/17/23, 5:51:00 PM > Subject [TUHS] Re: Compatibility question > > The concept of a resizable window didn't appear until GUI interfaces. > Originally the hardware terminal had one specific size and vi depended on > the screen being that exact size. I suspect that SVr2 was in that category, > as the Sun merger of SVr4 would have been the reason to incorporate it. So > try a 24x80 window and see if it behaves. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Mon Dec 18 10:35:38 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sun, 17 Dec 2023 19:35:38 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: Here is what I ended up doing. Creating a putty session with locked size. Aso using the vi as designed it works well. I have included the putty.defs, putty.notes and vi.notes. Now everything is fine. Thanks for your help. See attachments Getting System-V-r2-VAX780: For those running Arch the tar file is here. Simply download, untar cd to it , type in ./unix https://drive.google.com/file/d/1XToKXIxZvs9LKNerkVbTNspMik7OnLrs/view?usp=drive_link For other 64 bit Unix's use this image https://drive.google.com/file/d/1L-M8dGXogDpKutR0fpSkOkaEfNNH-1SZ/view?usp=drive_link Getting System-V-r3-3b2-700 64bit: https://drive.google.com/file/d/16zJrq3USLFAVnoGtbh4GCIj685o_UQER/view?usp=drive_link The above packages do not require any special software. It is all self contained. -ken On Sun, Dec 17, 2023 at 6:08 PM Warner Losh wrote: > > > On Sun, Dec 17, 2023, 4:00 PM Ron Natalie wrote: > >> That’s not entirely true. The VT100 could switch modes from 80x24 to >> 132x14 (the latter was pretty ugly) or with the AVO 132x24. >> > > I recall some VMS programs in v3.2 misbehaving when run in 132x24 mode... > > Warner > > ------ Original Message ------ >> From "Mary Ann Horton" >> To tuhs at tuhs.org >> Date 12/17/23, 5:51:00 PM >> Subject [TUHS] Re: Compatibility question >> >> The concept of a resizable window didn't appear until GUI interfaces. >> Originally the hardware terminal had one specific size and vi depended on >> the screen being that exact size. I suspect that SVr2 was in that category, >> as the Sun merger of SVr4 would have been the reason to incorporate it. So >> try a 24x80 window and see if it behaves. >> >> >> -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vi.notes Type: application/octet-stream Size: 616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: putty.notes Type: application/octet-stream Size: 507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: putty.defs Type: application/octet-stream Size: 4779 bytes Desc: not available URL: From tuhs at tuhs.org Mon Dec 18 13:24:07 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 18 Dec 2023 03:24:07 +0000 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: For the record Ken's scripting appears to work with my copy of SimH vax780 albeit with some non-fatal errors, probably different configure flags vs. the static copy in this archive. I'm on aarch64 so can't use the vax780 binary in there but after boot the images seem to run fine for me. Dunno what distros do, my copy is upstream. Typing "unix" at the double "$" prompt starts the bootstrap. Running uname(1) returns the expected properties for SVR2 for the VAX-11/780. - Matt G. P.S. SVR2 is post-1983 so a little touchier, so just some caution on distribution. Not sure if there's any IP ownership differences concerning materials that said "Western Electric" and/or "Bell Laboratories" in their licenses vs materials that said "AT&T". Some clarity from the interested parties would be helpful but I have no clue what the likelihood of a second round of free-to-study licensing of later SysV codebases looks like. I would have to wonder if the licensing of illumos has some technicality where all code SVR4 and back (that being the split point) is technically covered under their license. I'm no lawyer so *shrug* On Sunday, December 17th, 2023 at 4:35 PM, KenUnix wrote: > Here is what I ended up doing. Creating a putty session with locked size. Aso > using the vi as designed it works well. I have included the putty.defs, putty.notes > and vi.notes. > > Now everything is fine. Thanks for your help. > > See attachments > > Getting System-V-r2-VAX780: > > For those running Arch the tar file is here. Simply download, untar > cd to it , type in ./unix > > https://drive.google.com/file/d/1XToKXIxZvs9LKNerkVbTNspMik7OnLrs/view?usp=drive_link > > For other 64 bit Unix's use this image > > https://drive.google.com/file/d/1L-M8dGXogDpKutR0fpSkOkaEfNNH-1SZ/view?usp=drive_link > > Getting System-V-r3-3b2-700 64bit: > > https://drive.google.com/file/d/16zJrq3USLFAVnoGtbh4GCIj685o_UQER/view?usp=drive_link > > The above packages do not require any special software. It is all self contained. > > -ken > > On Sun, Dec 17, 2023 at 6:08 PM Warner Losh wrote: > >> On Sun, Dec 17, 2023, 4:00 PM Ron Natalie wrote: >> >>> That’s not entirely true. The VT100 could switch modes from 80x24 to 132x14 (the latter was pretty ugly) or with the AVO 132x24. >> >> I recall some VMS programs in v3.2 misbehaving when run in 132x24 mode... >> >> Warner >> >>> ------ Original Message ------ >>> From "Mary Ann Horton" >>> To tuhs at tuhs.org >>> Date 12/17/23, 5:51:00 PM >>> Subject [TUHS] Re: Compatibility question >>> >>>> The concept of a resizable window didn't appear until GUI interfaces. Originally the hardware terminal had one specific size and vi depended on the screen being that exact size. I suspect that SVr2 was in that category, as the Sun merger of SVr4 would have been the reason to incorporate it. So try a 24x80 window and see if it behaves. > > -- > > End of line > JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Dec 19 03:05:16 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 18 Dec 2023 12:05:16 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: On 12/17/23, Ron Natalie wrote: > That’s not entirely true. The VT100 could switch modes from 80x24 to > 132x14 (the latter was pretty ugly) or with the AVO 132x24. The 132-character screen width was for displaying files originally formatted to be printed on a line printer. Compiler listings and linker maps, for example. -Paul W. From nobozo at gmail.com Tue Dec 19 08:29:05 2023 From: nobozo at gmail.com (Jon Forrest) Date: Mon, 18 Dec 2023 14:29:05 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: Speaking of how VMS handled escape sequences, in the 1980s I swung both ways (e.g. VMS and Unix). When DEC announced TERMTABLE, a termcap-like library for VMS, I thought it would be fun to write a termcap to TERMTABLE conversion program, so I did. I thought this would let me run VMS TUI programs on non-DEC compatible terminals. This turned out to be a bad idea because none (?) of the DEC-written programs actually used TERMTABLE. They were all hard-wired to use VT100 (and VT52?) escape sequences. As I recall, I couldn't find any programs that used TERMTABLE in non-trivial ways so I gave up. Jon Forrest UCB (ret.) From tuhs at tuhs.org Tue Dec 19 11:44:50 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 19 Dec 2023 01:44:50 +0000 Subject: [TUHS] PDP-7 and Interdata 8/32 Bell System UNIX Installations? Message-ID: Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point? My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX. Thanks for any info! - Matt G. From dave at horsfall.org Tue Dec 19 11:46:46 2023 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 19 Dec 2023 12:46:46 +1100 (EST) Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: On Mon, 18 Dec 2023, Paul Winalski wrote: > The 132-character screen width was for displaying files originally > formatted to be printed on a line printer. Compiler listings and linker > maps, for example. Such as the mighty 1403 :-) Hint: never leave your cup of coffee on top of it, as the lid will open automatically when it runs out of paper... -- Dave From tuhs at tuhs.org Tue Dec 19 12:49:57 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 19 Dec 2023 02:49:57 +0000 Subject: [TUHS] PDP-7 and Interdata 8/32 Bell System UNIX Installations? In-Reply-To: References: Message-ID: Thanks Ken! I hadn't, even considered the PDP-15. Looks like SimH supports it, that could make for an interesting project... - Matt G. On Monday, December 18th, 2023 at 6:12 PM, Ken Thompson wrote: > the pdp-7 was run on the almost compatible > pdp-9 and pdp-15 computers. > i dont think that version of unix ever made > it out of the research department. > > On Mon, Dec 18, 2023 at 5:54 PM segaloco via TUHS wrote: > >> Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point? >> >> My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX. >> >> Thanks for any info! >> >> - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Dec 19 13:09:03 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 18 Dec 2023 20:09:03 -0700 Subject: [TUHS] PDP-7 and Interdata 8/32 Bell System UNIX Installations? In-Reply-To: References: Message-ID: On Mon, Dec 18, 2023, 6:45 PM segaloco via TUHS wrote: > Are there any documented or remembered instances PDP-7 or Interdata 8/32 > UNIX being installed on any such machines for use in the Bell System aside > from their original hosts? Along similar lines, was the mention of PDP-7 > UNIX also supporting the PDP-9 based solely on consistencies in the > architecture or did this early version of UNIX actually get bootstrapped on > a real PDP-9 at some point? > I've been told it ran on a couple of pdp-9s at bell labs with the right disk controllers. The original one was a pdp-9 controller retofitted to work in the pdp-7. There was only ever 1 pdp-7 installation back in the day. My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System > is predominantly PDP-11 systems, but there was also work in the late 70s > regarding 8086 hosts as evidenced in some BSTJ and other publications, and > there is the System/370 work (Holmdel?) which I don't know enough about to > say whether it technically starts before or after UNIX touches the VAX. > The pdp11 was the only machine to run unix until the ports began after the 5th edition came out. They began in earnest after the 6th Edition came out they began in earnest ar Bell Labs with the interdata 8/32 and IBM 370/VM. After that v7 was ported to the vax in what would become the 32V. Outside of Bell Labs was the internal 7/32 at Wollongong that beat the lab's effort. And another port to IBM 370/VM. I'm not sure when the 8086 with custom MMU was in all this. Late I believe: either just before V7 or just after. Warner Thanks for any info! > > - Matt G. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Tue Dec 19 17:35:45 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 19 Dec 2023 07:35:45 +0000 Subject: [TUHS] PDP-7 and Interdata 8/32 Bell System UNIX Installations? In-Reply-To: (Warner Losh's message of "Mon, 18 Dec 2023 20:09:03 -0700") References: Message-ID: <7w34vy3ar2.fsf@junk.nocrew.org> Warner Losh wrote: > Matt G wrote: > > Are there any documented or remembered instances PDP-7 or Interdata > > 8/32 UNIX being installed on any such machines for use in the Bell > > System aside from their original hosts? > > I've been told it ran on a couple of pdp-9s at bell labs with the > right disk controllers. The original one was a pdp-9 controller > retofitted to work in the pdp-7. There was only ever 1 pdp-7 > installation back in the day. The back story here is approximately something like the PDP-7 being left over from development of William Ninke's Graphic II display systen done in cooperation with DEC. There was previously a Graphic I built around a PDP-5. DEC later made the GT40 (aka Graphic-11) based on a PDP-11/10, and the Graphic-15 for the PDP-15. From skogtun at gmail.com Tue Dec 19 17:56:53 2023 From: skogtun at gmail.com (Harald Arnesen) Date: Tue, 19 Dec 2023 08:56:53 +0100 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: <87fded41-95a4-4f49-bc63-9eed87e6d96c@gmail.com> Dave Horsfall [19/12/2023 02.46]: > Such as the mighty 1403 :-) Hint: never leave your cup of coffee on top > of it, as the lid will open automatically when it runs out of paper... Haven't heard of anyone doing that, but a stack of punched cards, though, before the diagonal line was drawn along the edge of the stack. -- Hilsen Harald From paul.winalski at gmail.com Wed Dec 20 03:40:14 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 19 Dec 2023 12:40:14 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: On 12/18/23, Dave Horsfall wrote: > On Mon, 18 Dec 2023, Paul Winalski wrote: > >> The 132-character screen width was for displaying files originally >> formatted to be printed on a line printer. Compiler listings and linker >> maps, for example. > > Such as the mighty 1403 :-) > > Hint: never leave your cup of coffee on top of it, as the lid will open > automatically when it runs out of paper... The 1403 was the best line printer ever made. It was originally the printer for the IBM 1400 second-generation (discrete transistor-based) computer. It continued to be the line printer for S/360. The deluxe model, the IBM 1403 N1, had a power cover that could be operated under computer control. The OS/360 operating system would raise the printer's cover if an error condition occurred, such as out of paper or a paper jam. This was a very useful feature in large data centers where there were several line printers, to indicate which printer had a problem. The cover of a 1403 N1 also provided a convenient and attractive flat surface on which to place things. But a dangerous one. Many a card deck magtape reel, coffee cup, or pizza box has been unceremoniously dumped on the floor. When our shop upgraded from a S/360 model 25 to a S/370 model 125, our 1403 was replaced by a 3203 line printer. It was not as good as the 1401 had been. There was a business in Massachusetts in the 1980s that bought and sold old IBM computer gear. A company asked them for a quote on their IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer). They were offered $18,000 for the whole system, or $15,000 for the 1403 printer alone. That's how valued those printers were. To bring this closer on-topic, was there Unix support for the IBM 1403? -Paul W. From pugs78 at gmail.com Wed Dec 20 04:07:10 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Tue, 19 Dec 2023 10:07:10 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: Yes, Amdahl UTS supported the 1403 from earliest days. There even seem to be some mods to 'tbl' to support it. On Tue, Dec 19, 2023 at 9:40 AM Paul Winalski wrote: > On 12/18/23, Dave Horsfall wrote: > > On Mon, 18 Dec 2023, Paul Winalski wrote: > > > >> The 132-character screen width was for displaying files originally > >> formatted to be printed on a line printer. Compiler listings and linker > >> maps, for example. > > > > Such as the mighty 1403 :-) > > > > Hint: never leave your cup of coffee on top of it, as the lid will open > > automatically when it runs out of paper... > > The 1403 was the best line printer ever made. It was originally the > printer for the IBM 1400 second-generation (discrete transistor-based) > computer. It continued to be the line printer for S/360. The deluxe > model, the IBM 1403 N1, had a power cover that could be operated under > computer control. The OS/360 operating system would raise the > printer's cover if an error condition occurred, such as out of paper > or a paper jam. This was a very useful feature in large data centers > where there were several line printers, to indicate which printer had > a problem. > > The cover of a 1403 N1 also provided a convenient and attractive flat > surface on which to place things. But a dangerous one. Many a card > deck magtape reel, coffee cup, or pizza box has been unceremoniously > dumped on the floor. > > When our shop upgraded from a S/360 model 25 to a S/370 model 125, our > 1403 was replaced by a 3203 line printer. It was not as good as the > 1401 had been. > > There was a business in Massachusetts in the 1980s that bought and > sold old IBM computer gear. A company asked them for a quote on their > IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer). > They were offered $18,000 for the whole system, or $15,000 for the > 1403 printer alone. That's how valued those printers were. > > To bring this closer on-topic, was there Unix support for the IBM 1403? > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2023-12-19 09-57-38.png Type: image/png Size: 12565 bytes Desc: not available URL: From clemc at ccc.com Wed Dec 20 06:23:57 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 19 Dec 2023 15:23:57 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: Tom smiled while reading that man page: "It is assumed that the TN print train is being used." I have to wonder how many younger programmers know what a print train is, much less what it looked like (or how heavy they were when you changed them). Also, with the loss of the use of real lineprinters, you have to wonder if those same folks understand why the asa(1) program that POSIX.2 requires is there (although IIRC later *.2 revisions moved it to the "FORTRAN Runtime Utilities" as an option POSX2_FORT_RUN - but we had it there in the original draft). Paul -- you left out the other "feature" -- the noise, which was still deafening even with a model N1 and its cover. I equate four sounds to my early computing days: the ASR33 printing, a 1403 printing, a 1402 reading card, and finally, the constant fan noise in the machine room, plus the smell of light machine oil [definitely in a terminal room of ASR33s]. ᐧ ᐧ On Tue, Dec 19, 2023 at 1:07 PM Tom Lyon wrote: > Yes, Amdahl UTS supported the 1403 from earliest days. > There even seem to be some mods to 'tbl' to support it. > > On Tue, Dec 19, 2023 at 9:40 AM Paul Winalski > wrote: > >> On 12/18/23, Dave Horsfall wrote: >> > On Mon, 18 Dec 2023, Paul Winalski wrote: >> > >> >> The 132-character screen width was for displaying files originally >> >> formatted to be printed on a line printer. Compiler listings and >> linker >> >> maps, for example. >> > >> > Such as the mighty 1403 :-) >> > >> > Hint: never leave your cup of coffee on top of it, as the lid will open >> > automatically when it runs out of paper... >> >> The 1403 was the best line printer ever made. It was originally the >> printer for the IBM 1400 second-generation (discrete transistor-based) >> computer. It continued to be the line printer for S/360. The deluxe >> model, the IBM 1403 N1, had a power cover that could be operated under >> computer control. The OS/360 operating system would raise the >> printer's cover if an error condition occurred, such as out of paper >> or a paper jam. This was a very useful feature in large data centers >> where there were several line printers, to indicate which printer had >> a problem. >> >> The cover of a 1403 N1 also provided a convenient and attractive flat >> surface on which to place things. But a dangerous one. Many a card >> deck magtape reel, coffee cup, or pizza box has been unceremoniously >> dumped on the floor. >> >> When our shop upgraded from a S/360 model 25 to a S/370 model 125, our >> 1403 was replaced by a 3203 line printer. It was not as good as the >> 1401 had been. >> >> There was a business in Massachusetts in the 1980s that bought and >> sold old IBM computer gear. A company asked them for a quote on their >> IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer). >> They were offered $18,000 for the whole system, or $15,000 for the >> 1403 printer alone. That's how valued those printers were. >> >> To bring this closer on-topic, was there Unix support for the IBM 1403? >> >> -Paul W. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Dec 20 07:31:43 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 19 Dec 2023 16:31:43 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: On 12/19/23, Clem Cole wrote: > Tom smiled while reading that man page: "It is assumed that the TN print > train is being used." > I have to wonder how many younger programmers know what a print train is, For the edification of those who don't know, the 1403 line printer and its brothers worked like this. There was a (removable and switchable) horizontal cartridge that sat midway in the printer, laid out horizontally across the paper, behind an ink-soaked cloth band located between the print train and the paper. Behind the paper was a series of 132 hammers (one per column of print). The cartridge contained a single chain of type that was spun at high speed. Whenever the position of a desired character passed in front of its desired colu, that column's hammer struck the back of the paper and thus printed the character. There were several print trains available, just as there were several typeballs for the IBM Selectric typewriter. One of these used a space character ' ' both for the space and for the underscore '_'. This was the origin of using underscores to represent spaces in program identifiers. The other way to do line printing is to have a rotating drum with the full character set for each column. This is the way the DEC line printers worked. Of course there were minor inaccuracies in the timing of the hammers, and with the drum-based printers this resulted in wavy lines. There were inaccuracies in the print train-style printers, too, but waviness in the columns is not as noticeable to the eye as waviness in the lines. Coming from the IBM world, I considered the DEC printers total junk. > Paul -- you left out the other "feature" -- the noise, which was still > deafening even with a model N1 and its cover. Yes, the 1403 was very loud. The pitch of the noise varied with the sequence of characters being printed. Some IBM hacker (yes, they existed) came up with a deck of cards that, when printed, played "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on this hack because it put a lot of wear-and-tear on the print train. -Paul W. From robpike at gmail.com Wed Dec 20 07:34:12 2023 From: robpike at gmail.com (Rob Pike) Date: Wed, 20 Dec 2023 08:34:12 +1100 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: The night operator for the High Speed Job Stream at the University of Toronto would nap on top of the 1401. He would be woken by the lid lifting him up when the printer ran out of paper, an effective alarm clock set to the computer's cycle. -rob On Wed, Dec 20, 2023 at 7:34 AM Clem Cole wrote: > Tom smiled while reading that man page: "It is assumed that the TN print > train is being used." > I have to wonder how many younger programmers know what a print train is, > much less what it looked like (or how heavy they were when you > changed them). Also, with the loss of the use of real lineprinters, you > have to wonder if those same folks understand why the asa(1) program that > POSIX.2 requires is there (although IIRC later *.2 revisions moved it to > the "FORTRAN Runtime Utilities" as an option POSX2_FORT_RUN - but we had > it there in the original draft). > > Paul -- you left out the other "feature" -- the noise, which was still > deafening even with a model N1 and its cover. > > I equate four sounds to my early computing days: the ASR33 printing, a > 1403 printing, a 1402 reading card, and finally, the constant fan noise in > the machine room, plus the smell of light machine oil [definitely in a > terminal room of ASR33s]. > ᐧ > ᐧ > > On Tue, Dec 19, 2023 at 1:07 PM Tom Lyon wrote: > >> Yes, Amdahl UTS supported the 1403 from earliest days. >> There even seem to be some mods to 'tbl' to support it. >> >> On Tue, Dec 19, 2023 at 9:40 AM Paul Winalski >> wrote: >> >>> On 12/18/23, Dave Horsfall wrote: >>> > On Mon, 18 Dec 2023, Paul Winalski wrote: >>> > >>> >> The 132-character screen width was for displaying files originally >>> >> formatted to be printed on a line printer. Compiler listings and >>> linker >>> >> maps, for example. >>> > >>> > Such as the mighty 1403 :-) >>> > >>> > Hint: never leave your cup of coffee on top of it, as the lid will open >>> > automatically when it runs out of paper... >>> >>> The 1403 was the best line printer ever made. It was originally the >>> printer for the IBM 1400 second-generation (discrete transistor-based) >>> computer. It continued to be the line printer for S/360. The deluxe >>> model, the IBM 1403 N1, had a power cover that could be operated under >>> computer control. The OS/360 operating system would raise the >>> printer's cover if an error condition occurred, such as out of paper >>> or a paper jam. This was a very useful feature in large data centers >>> where there were several line printers, to indicate which printer had >>> a problem. >>> >>> The cover of a 1403 N1 also provided a convenient and attractive flat >>> surface on which to place things. But a dangerous one. Many a card >>> deck magtape reel, coffee cup, or pizza box has been unceremoniously >>> dumped on the floor. >>> >>> When our shop upgraded from a S/360 model 25 to a S/370 model 125, our >>> 1403 was replaced by a 3203 line printer. It was not as good as the >>> 1401 had been. >>> >>> There was a business in Massachusetts in the 1980s that bought and >>> sold old IBM computer gear. A company asked them for a quote on their >>> IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer). >>> They were offered $18,000 for the whole system, or $15,000 for the >>> 1403 printer alone. That's how valued those printers were. >>> >>> To bring this closer on-topic, was there Unix support for the IBM 1403? >>> >>> -Paul W. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Dec 20 09:52:39 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 19 Dec 2023 15:52:39 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> On Dec 19, 2023, at 1:31 PM, Paul Winalski wrote: > > Yes, the 1403 was very loud. The pitch of the noise varied with the > sequence of characters being printed. Some IBM hacker (yes, they > existed) came up with a deck of cards that, when printed, played > "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on > this hack because it put a lot of wear-and-tear on the print train. I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": https://www.youtube.com/watch?v=Oe0MGO17K10 [For the curious & easily distracted among us....] From grog at lemis.com Wed Dec 20 10:05:40 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 20 Dec 2023 11:05:40 +1100 Subject: [TUHS] Compatibility question In-Reply-To: <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> References: <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> Message-ID: On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote: > On Dec 19, 2023, at 1:31 PM, Paul Winalski wrote: >> >> Yes, the 1403 was very loud. The pitch of the noise varied with the >> sequence of characters being printed. Some IBM hacker (yes, they >> existed) came up with a deck of cards that, when printed, played >> "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on >> this hack because it put a lot of wear-and-tear on the print train. > > I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": > > https://www.youtube.com/watch?v=Oe0MGO17K10 "This video isn't available anymore" Does anybody have a copy? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From mah at mhorton.net Wed Dec 20 10:15:59 2023 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 19 Dec 2023 16:15:59 -0800 Subject: [TUHS] Compatibility question In-Reply-To: <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> Message-ID: <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> Thank you for this, I never knew how this worked. My experience as an IBM 360 (USC-ECL) operator was brief and I never got into the nuts and bolts. I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about 1970 in Portland. Their printer played "Anchors Aweigh" and I never knew how. But now I wonder - does this mean they had an IBM 1403 connected to a DEC 10 somehow? Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com On 12/19/23 15:52, Bakul Shah wrote: > On Dec 19, 2023, at 1:31 PM, Paul Winalski wrote: >> Yes, the 1403 was very loud. The pitch of the noise varied with the >> sequence of characters being printed. Some IBM hacker (yes, they >> existed) came up with a deck of cards that, when printed, played >> "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on >> this hack because it put a lot of wear-and-tear on the print train. > I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": > > https://www.youtube.com/watch?v=Oe0MGO17K10 > > [For the curious & easily distracted among us....] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Dec 20 11:03:03 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 19 Dec 2023 17:03:03 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> Message-ID: On Dec 19, 2023, at 4:05 PM, Greg 'groggy' Lehey wrote: > > On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote: >> On Dec 19, 2023, at 1:31 PM, Paul Winalski wrote: >>> >>> Yes, the 1403 was very loud. The pitch of the noise varied with the >>> sequence of characters being printed. Some IBM hacker (yes, they >>> existed) came up with a deck of cards that, when printed, played >>> "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on >>> this hack because it put a lot of wear-and-tear on the print train. >> >> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": >> >> https://www.youtube.com/watch?v=Oe0MGO17K10 > > "This video isn't available anymore" > > Does anybody have a copy? The above link does work for me... I thought I'd direct you to archive.org but there it says attempts to archive this video failed. Strange! May be try another browser? From steffen at sdaoden.eu Wed Dec 20 11:11:01 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 20 Dec 2023 02:11:01 +0100 Subject: [TUHS] Compatibility question In-Reply-To: <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> Message-ID: <20231220011101.kywGUM7B@steffen%sdaoden.eu> Bakul Shah wrote in <7DEABFE1-9015-461E-82EF-FF8E00516DBD at iitbombay.org>: |On Dec 19, 2023, at 1:31 PM, Paul Winalski wrote: |> |> Yes, the 1403 was very loud. The pitch of the noise varied with the |> sequence of characters being printed. Some IBM hacker (yes, they |> existed) came up with a deck of cards that, when printed, played |> "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on |> this hack because it put a lot of wear-and-tear on the print train. | |I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": | |https://www.youtube.com/watch?v=Oe0MGO17K10 My aunt, who once was married with a --Transi-- Pennsylvanian for decades (and lived there), would surely proclaim "OH, [BIG] BOOOY". |[For the curious & easily distracted among us....] As i am not french i does not matter that it seems not super right. Thought: if by that time AI would have been a thing, would it have recomposed it to the Beatles' "Help!", and played it as the boss went passing along? (Or, rather, the more empathic "a hard day's night".) --End of <7DEABFE1-9015-461E-82EF-FF8E00516DBD at iitbombay.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world. | [Christians might think of Revelation 11:18 | The nations were angry, and your wrath has come[.] | [.]for destroying those who destroy the earth. | But i find the above more kind, and much friendlier] From pugs78 at gmail.com Wed Dec 20 11:23:31 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Tue, 19 Dec 2023 17:23:31 -0800 Subject: [TUHS] Compatibility question In-Reply-To: <20231220011101.kywGUM7B@steffen%sdaoden.eu> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> <20231220011101.kywGUM7B@steffen%sdaoden.eu> Message-ID: I guess the 1403 was the original multimedia output device. See also Sam Harbison's line printer art: http://q7.neurotica.com/Oldtech/ASCII/ On Tue, Dec 19, 2023 at 5:11 PM Steffen Nurpmeso wrote: > Bakul Shah wrote in > <7DEABFE1-9015-461E-82EF-FF8E00516DBD at iitbombay.org>: > |On Dec 19, 2023, at 1:31 PM, Paul Winalski > wrote: > |> > |> Yes, the 1403 was very loud. The pitch of the noise varied with the > |> sequence of characters being printed. Some IBM hacker (yes, they > |> existed) came up with a deck of cards that, when printed, played > |> "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on > |> this hack because it put a lot of wear-and-tear on the print train. > | > |I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": > | > |https://www.youtube.com/watch?v=Oe0MGO17K10 > > My aunt, who once was married with a --Transi-- Pennsylvanian for > decades (and lived there), would surely proclaim "OH, [BIG] BOOOY". > > |[For the curious & easily distracted among us....] > > As i am not french i does not matter that it seems not super right. > > Thought: if by that time AI would have been a thing, would it have > recomposed it to the Beatles' "Help!", and played it as the boss > went passing along? (Or, rather, the more empathic "a hard day's > night".) > > --End of <7DEABFE1-9015-461E-82EF-FF8E00516DBD at iitbombay.org> > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > | > | Only in December: lightful Dubai COP28 Narendra Modi quote: > | A small part of humanity has ruthlessly exploited nature. > | But the entire humanity is bearing the cost of it, > | especially the inhabitants of the Global South. > | The selfishness of a few will lead the world into darkness, > | not just for themselves but for the entire world. > | [Christians might think of Revelation 11:18 > | The nations were angry, and your wrath has come[.] > | [.]for destroying those who destroy the earth. > | But i find the above more kind, and much friendlier] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Dec 20 11:32:02 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 20 Dec 2023 12:32:02 +1100 Subject: [TUHS] Compatibility question In-Reply-To: References: <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> Message-ID: On Tuesday, 19 December 2023 at 17:03:03 -0800, Bakul Shah wrote: > On Dec 19, 2023, at 4:05 PM, Greg 'groggy' Lehey wrote: >> >> On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote: >>> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": >>> >>> https://www.youtube.com/watch?v=Oe0MGO17K10 >> >> "This video isn't available anymore" >> >> Does anybody have a copy? > > The above link does work for me... I thought I'd direct you to > archive.org but there it says attempts to archive this video failed. > Strange! May be try another browser? Yes, thanks. "Another browser" seems to have helped. A hollow voice croaks "interoperability". Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Wed Dec 20 14:11:39 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 19 Dec 2023 23:11:39 -0500 Subject: [TUHS] Loud machines (was Compatibility Question) Message-ID: > Paul -- you left out the other "feature" -- the noise, which was still deafening even with a model N1 and its cover. It was indeed loud, but GE out-roared them with a blindingly fast card reader. The machine had a supposedly gentle touch; it grabbed cards with vacuum rather than tongs. But the make-and-break pneumatic explosions sounded like a machine gun. A noise meter I borrowed from the Labs' tool crib read 90db 6 feet away. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Wed Dec 20 16:05:59 2023 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 20 Dec 2023 19:05:59 +1300 Subject: [TUHS] Compatibility question In-Reply-To: References: <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> Message-ID: <6703a29b-4e4c-4eb1-b54e-33245b9c1a52@gmail.com> I've just heard it on Firefox, on Fedora. Wesley Parish On 20/12/23 14:32, Greg 'groggy' Lehey wrote: > On Tuesday, 19 December 2023 at 17:03:03 -0800, Bakul Shah wrote: >> On Dec 19, 2023, at 4:05 PM, Greg 'groggy' Lehey wrote: >>> On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote: >>>> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise": >>>> >>>> https://www.youtube.com/watch?v=Oe0MGO17K10 >>> "This video isn't available anymore" >>> >>> Does anybody have a copy? >> The above link does work for me... I thought I'd direct you to >> archive.org but there it says attempts to archive this video failed. >> Strange! May be try another browser? > Yes, thanks. "Another browser" seems to have helped. > > A hollow voice croaks "interoperability". > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php From arnold at skeeve.com Wed Dec 20 17:12:47 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 20 Dec 2023 00:12:47 -0700 Subject: [TUHS] Loud machines (was Compatibility Question) In-Reply-To: References: Message-ID: <202312200712.3BK7ClJX024798@freefriends.org> As late as 1981, the university I attended had an IBM 1130. Mainly it was programmed in Fortran IV (but only 5 letters allowed in an identifier, not 6) but it also had a Cobol compiler. The Cobol compiler read cards about 1 every 3/4 second. By contrast, when the Fortran compiler was reading cards, it sounded like a machine gun firing. I wrote a program similar to banner(1) but that made the big letters up out of the actual letters in Fortran. Although the cards are long gone, I still have the code. :-) Arnold Douglas McIlroy wrote: > > Paul -- you left out the other "feature" -- the noise, which was still > deafening even with a model N1 and its cover. > > It was indeed loud, but GE out-roared them with a blindingly fast card > reader. The machine had a supposedly gentle touch; it grabbed cards with > vacuum rather than tongs. But the make-and-break pneumatic explosions > sounded like a machine gun. A noise meter I borrowed from the Labs' tool > crib read 90db 6 feet away. > > Doug From athornton at gmail.com Thu Dec 21 02:07:38 2023 From: athornton at gmail.com (Adam Thornton) Date: Wed, 20 Dec 2023 09:07:38 -0700 Subject: [TUHS] Compatibility question In-Reply-To: <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> Message-ID: On Tue, Dec 19, 2023 at 11:14 PM Mary Ann Horton wrote: > I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about 1970 > in Portland. Their printer played "Anchors Aweigh" and I never knew how. > But now I wonder - does this mean they had an IBM 1403 connected to a DEC > 10 somehow? > It certainly means they had some kind of chain or train printer, but any place big enough to have a PDP-10 would probably have had the budget for a serious printer as well. I don't know if DEC made a competing printer (I think they were very early with dot matrix printing?) or not (or who other than IBM made big lineprinters), but once you know the trick is possible, the rest is a relatively simple matter of having someone with a good ear to tune the printer output so it sounds right. For a modern and delightful analogue to this, have a look at the Floppotron. https://www.youtube.com/@PaweZadrozniak -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 21 02:22:57 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 20 Dec 2023 11:22:57 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> Message-ID: Until the DECwriter series and the VT04, DEC sold OEM printers and terminals were made by other manufacturers. Paul is speaking of the traditional LP01, which Centronix made (I think) IIRC [Datapoint maybe -- I forget], and it was ordered with either an upper case only drum [faster - as it had two copies of the A-Z set] or an upper and lower case drum - which included some special characters. The 8-bit parallel interface was defined by Centronix, which was the standard printer interface for Minis and later PCs. The difference with the latter is that IBM used a common ground wire so they could put it in a DB25S connector. With the PC, IBM designed the interface using a bi-directional Intel parallel I/O chip so you could read it - which was not true of the earlier interfaces for PDP-8/10/11. As for the LP01 drum, it was possible to replace in the field but a PITA [we did when we got a used one from Tektronix's Finance shop that was running RSTS Cobol and moved it to the Teklab's 11/70 - V7++ UNIX system]. FWIW: when the Printronix was released in the late 1970s, it became the standard lineprinter for UNIX sites until the rise of laser printers. As for putting a 1403 on a PDP-10, I suspect it was possible, but it probably took some custom interfacing. ᐧ ᐧ ᐧ ᐧ On Wed, Dec 20, 2023 at 11:08 AM Adam Thornton wrote: > On Tue, Dec 19, 2023 at 11:14 PM Mary Ann Horton wrote: > >> I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about 1970 >> in Portland. Their printer played "Anchors Aweigh" and I never knew how. >> But now I wonder - does this mean they had an IBM 1403 connected to a DEC >> 10 somehow? >> > > It certainly means they had some kind of chain or train printer, but any > place big enough to have a PDP-10 would probably have had the budget for a > serious printer as well. I don't know if DEC made a competing printer (I > think they were very early with dot matrix printing?) or not (or who other > than IBM made big lineprinters), but once you know the trick is possible, > the rest is a relatively simple matter of having someone with a good ear to > tune the printer output so it sounds right. > > For a modern and delightful analogue to this, have a look at the > Floppotron. https://www.youtube.com/@PaweZadrozniak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Dec 21 02:34:32 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 20 Dec 2023 11:34:32 -0500 Subject: [TUHS] Compatibility question In-Reply-To: <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> Message-ID: On 12/19/23, Mary Ann Horton wrote: > > I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about > 1970 in Portland. Their printer played "Anchors Aweigh" and I never knew > how. But now I wonder - does this mean they had an IBM 1403 connected to > a DEC 10 somehow? They very well might have had an IBM 1403 printer on their PDP-10 system. DEC marketed the PDP-10 as their commercial raised-floor data center computing solution. They OEMed a lot of the high-end peripheral gear for the DEC-10/20 from third-party vendors in the IBM world. The high-end disk of the time was an OEM version of the IBM 3330 with an IBM block multiplexer channel-to-DEC MASSBUS adapter. DEC was notoriously bad at producing 9-track magtape drives. But they were smart enough to OEM high-end tape drives from Storage Technology Corporation, which made the gold standard of tape drives in the IBM data center world. So DEC did have the capability to attach IBM gear to the PDP-10. They would certainly have an incentive to use 1403 printers in this market. Nobody familiar with IBM line printers would consider the standard DEC line printers acceptable. The 1403 was typically connected to the S/360/370's byte multiplexer channel (transmits one byte at a time to each device; intended for slow peripherals such as card readers, line printers, card punches). I know DEC had IBM channel adapters for disks and tapes usually attached by selector or block multiplexer channels. They may have had a byte multiplexer channel adapter, too. -Paul W. From ads at salewski.email Thu Dec 21 04:11:19 2023 From: ads at salewski.email (Alan D. Salewski) Date: Wed, 20 Dec 2023 13:11:19 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> Message-ID: On Wed, Dec 20, 2023, at 11:07, Adam Thornton wrote: > For a modern and delightful analogue to this, have a look at the > Floppotron. https://www.youtube.com/@PaweZadrozniak Wow, the Floppotron takes things to a whole other level -- thanks for sharing! -- 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 nobozo at gmail.com Thu Dec 21 04:15:17 2023 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 20 Dec 2023 10:15:17 -0800 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org> <1a126b3d-412e-4b54-89c7-2d643b47a0cf@mhorton.net> Message-ID: <37d08fa7-031f-4a9e-95a5-f078f2e6ec98@gmail.com> On 12/20/2023 8:34 AM, Paul Winalski wrote: > DEC was notoriously bad at producing 9-track magtape drives. Sad but true. Does anybody remember the redoubted TS-11, aka "Tape Stretcher 11"? Jon Forrest UCB (ret.) From tuhs at tuhs.org Thu Dec 21 13:53:21 2023 From: tuhs at tuhs.org (Rod Bartlett via TUHS) Date: Wed, 20 Dec 2023 22:53:21 -0500 Subject: [TUHS] Compatibility question In-Reply-To: References: <93ef58b9-b058-4463-b0e6-d2f2f2bf5a55@loomcom.com> <76f6ae7e-20e1-41fa-9fe4-cc22015411bf@mhorton.net> Message-ID: > On Dec 19, 2023, at 4:31 PM, Paul Winalski wrote: > > > Yes, the 1403 was very loud. The pitch of the noise varied with the > sequence of characters being printed. Some IBM hacker (yes, they > existed) came up with a deck of cards that, when printed, played > "Anchors Aweigh" on the 1403. IBM field service wasn't very keen on > this hack because it put a lot of wear-and-tear on the print train. The holidays always seemed to feature people running programs which played festive songs by punching fully laced cards or printing patterns on the line printers. Whenever I noticed something, I'd ask the operators to kill those programs because they could cause equipment failures. A fully laced punch card is much more flexible and likely to jam. Printing all columns on a printer, especially doing so without a line feed, tends to moisten the paper which tended to gum up the print trains. Those line printers were definitely noisy. I've got tinnitus thanks to working around them. - Rod From tuhs at tuhs.org Thu Dec 21 13:56:32 2023 From: tuhs at tuhs.org (Rod Bartlett via TUHS) Date: Wed, 20 Dec 2023 22:56:32 -0500 Subject: [TUHS] Loud machines (was Compatibility Question) In-Reply-To: References: Message-ID: <5DAD2EB4-DC7C-49B4-A703-FF8AF25A54ED@mac.com> Those old GE card readers were wicked fast. The occasional card jams took a while to recover from since they would jam so many cards into a tiny space meant to hold a single card. To tell the truth, I never noticed the sound level much because the line printers were so much louder. - Rod > On Dec 19, 2023, at 11:11 PM, Douglas McIlroy wrote: > > > Paul -- you left out the other "feature" -- the noise, which was still deafening even with a model N1 and its cover. > > It was indeed loud, but GE out-roared them with a blindingly fast card reader. The machine had a supposedly gentle touch; it grabbed cards with vacuum rather than tongs. But the make-and-break pneumatic explosions sounded like a machine gun. A noise meter I borrowed from the Labs' tool crib read 90db 6 feet away. > > Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Dec 21 22:12:06 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 21 Dec 2023 05:12:06 -0700 Subject: [TUHS] Off topic: BSD timezone function vs. POSIX timezone variable In-Reply-To: References: <874jgk7r5j.fsf@vuxu.org> Message-ID: <202312211212.3BLCC69X005473@freefriends.org> Thanks to everyone who responded to my question. The answers were helpful. Arnold Chet Ramey wrote: > On 12/14/23 10:14 AM, Leah Neukirchen wrote: > > Aharon Robbins writes: > > > >> Hi All. > >> > >> This is a bit off-topic, but people here are likely to know the answer. > >> > >> V7 had a timzone function: > >> > >> char *timezone(int zone, int dst); > >> > >> that returned a timezone name. POSIX has a timezone variable which is > >> the offset in seconds from UTC. > >> > >> The man pages for all of {Net,Free,Open}BSD seem to indicate that both > >> are available on those systems. > >> > >> My question is, how? The declarations for both are given as being in . > >> But don't the symbols in libc.a conflict with each other? How does a programmer > >> on *BSD choose which version of timezone they will get? > > > > OpenBSD 7.3 only has "extern long timezone" and no timezone(3) function. > > > > FreeBSD 14.0 only has the timezone(3) function (under _BSD_VISIBLE), > > and doesn't set any variables. > > Darwin (macOS) conditionally defines them. If you want POSIX 2003 > compatibility, define __DARWIN_UNIX03 and get > > extern long timezone __DARWIN_ALIAS(timezone); > > If you don't define that, you get > > char *timezone(int, int); > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From arnold at skeeve.com Thu Dec 21 22:45:56 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 21 Dec 2023 05:45:56 -0700 Subject: [TUHS] DMD 5620 mouse available Message-ID: <202312211245.3BLCju9l010561@freefriends.org> ... at a rather high price: https://www.ebay.com/itm/265518759380?hash=item3dd226bdd4:g:8gUAAOSwW21h8N7e&amdata=enc%3AAQAIAAAA4HG36wMdUgdY7m9K1ejutY1DWpznCY8ntlWy%2Bj%2FJmTNN2tuDT0U7%2BC0eS943tevGdnKmJLJVtMOyWltPq0RZThhCbIDKZI%2F19zUUhI5ClfyCgaDxb7DjVe7HUDhBuIBihtNjctTxgAnc2ZuVUkNpPcONPXa3KkkOHPPt2S59rh5WOJ8Lep60%2B8kVuNoQvbuzeVx28Leu0jad%2BF4tdoidPT4hcXxjF6UmO89%2FF5Jpln44gZlBdC9Jd3qXzRLR6h%2Bwll%2BiGBqDiIXTFaUCrHKTDxmoJDmIkZPa9I8xHGmA6sVk%7Ctkp%3ABk9SR_jBvMKQYw :-) Arnold From phil at ultimate.com Fri Dec 22 03:48:09 2023 From: phil at ultimate.com (Phil Budne) Date: Thu, 21 Dec 2023 12:48:09 -0500 Subject: [TUHS] PDP-7 and Interdata 8/32 Bell System UNIX Installations? In-Reply-To: <7w34vy3ar2.fsf@junk.nocrew.org> References: <7w34vy3ar2.fsf@junk.nocrew.org> Message-ID: <202312211748.3BLHm9MC017980@ultimate.com> Lars Brinkhoff wrote: > The back story here is approximately something like the PDP-7 being left > over from development of William Ninke's Graphic II display systen done > in cooperation with DEC. The fast fixed-head disk on the UNIX PDP-7 seems to have been the RB09 for the upcomming PDP-9, and it's been my surmise that the PDP-7 was likely used until PDP-9s were available for "production" Graphic II workstations. I seem to recall the DEC Field Service list for 18-bit systems only showed the one PDP-7, but multiple PDP-9's equipped with an RB09. While working on the PDP-7 UNIX resuscitation (I wrote a stand-in for the shell, which served until the listings for utilities from the second half of the alphabet were found and scanned) I once booted UNIX on under SimH PDP-9 simulation. I believe the same (Burroughs?) disk was used as the RD10 on PDP-10 systems as a swap device. https://archive.org/details/TNM_PDP-10_computer_price_list_1967_20180205_0300/page/n1/mode/2up shows the RD10 subsystem was $32,500 in 1967. https://gunkies.org/wiki/PDP-9 says an 8K system was $30K and that a PDP-7 was $72K. I don't doubt the custom Graphic II hardware was costly as well. The Graphic II project seems to have been well funded, and the demo videos I've seen show the Graphic systems were meant for doing "real" (telephone network) related work (I remember seeing one on filter design), so I imagine the PDP-9 Graphic II systems were in use during regular work hours. The Graphic II systems had modem links to a (GE635?) mainframe, so it's _possible_ the disk was only used for fast/temporary storage, and it wouldn't matter if someone booted UNIX after hours... Ah... I found the simh .ini file I used: phil at phil-nb9:~$ ls -l /home/phil/pdp7-unix/build/pdp9.simh -rw-rw-r-- 1 phil phil 613 Mar 27 2016 /home/phil/pdp7-unix/build/pdp9.simh phil at phil-nb9:~$ cat !$ cat /home/phil/pdp7-unix/build/pdp9.simh set cpu 8k set cpu eae #set cpu history=100 show cpu # set up SIMH devices: # UNIX character translations (CR to NL, ESC to ALTMODE): set tti unix # RB09 fixed head disk: set rb ena att rb image.fs # uncomment to TELNET in GRAPHICS-2 keyboard/display(!!) # (requires github.com/philbudne/simh) #set g2in ena #att -U g2in 12345 # disable hardware UNIX-7 doesn't know about: set lpt disa set drm disa set dt disa # PDP-9 hardware set ttix disa set ttox disa set mt disa set rf disa # show device settings: show dev # load and run the paper tape bootstrap # (loads system from disk) load boot.rim 010000 From kennethgoodwin56 at gmail.com Fri Dec 22 08:25:12 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Thu, 21 Dec 2023 17:25:12 -0500 Subject: [TUHS] DMD 5620 mouse available In-Reply-To: <202312211245.3BLCju9l010561@freefriends.org> References: <202312211245.3BLCju9l010561@freefriends.org> Message-ID: It says best offer. Offer them $10.00... On Thu, Dec 21, 2023, 7:54 AM wrote: > ... at a rather high price: > > > https://www.ebay.com/itm/265518759380?hash=item3dd226bdd4:g:8gUAAOSwW21h8N7e&amdata=enc%3AAQAIAAAA4HG36wMdUgdY7m9K1ejutY1DWpznCY8ntlWy%2Bj%2FJmTNN2tuDT0U7%2BC0eS943tevGdnKmJLJVtMOyWltPq0RZThhCbIDKZI%2F19zUUhI5ClfyCgaDxb7DjVe7HUDhBuIBihtNjctTxgAnc2ZuVUkNpPcONPXa3KkkOHPPt2S59rh5WOJ8Lep60%2B8kVuNoQvbuzeVx28Leu0jad%2BF4tdoidPT4hcXxjF6UmO89%2FF5Jpln44gZlBdC9Jd3qXzRLR6h%2Bwll%2BiGBqDiIXTFaUCrHKTDxmoJDmIkZPa9I8xHGmA6sVk%7Ctkp%3ABk9SR_jBvMKQYw > > :-) > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Dec 22 08:46:54 2023 From: rminnich at gmail.com (ron minnich) Date: Thu, 21 Dec 2023 14:46:54 -0800 Subject: [TUHS] DMD 5620 mouse available In-Reply-To: References: <202312211245.3BLCju9l010561@freefriends.org> Message-ID: John Floren, get Stefan R. to make you up the kind of box he makes for Amiga hardware, to match that box; then start a production run of your mice; then sell them in boxed set at 90% off the price of that $31K mouse. Hey! 90% off! and you can actually plug it into something, what's not to like. You can offer, for another $1K, to put flattened lead weights from Champagne bottles in them! (but you'll have to find some way to dispose of the extra champagne -- I'm here to help.) On Thu, Dec 21, 2023 at 2:25 PM Kenneth Goodwin wrote: > It says best offer. > > Offer them $10.00... > > On Thu, Dec 21, 2023, 7:54 AM wrote: > >> ... at a rather high price: >> >> >> https://www.ebay.com/itm/265518759380?hash=item3dd226bdd4:g:8gUAAOSwW21h8N7e&amdata=enc%3AAQAIAAAA4HG36wMdUgdY7m9K1ejutY1DWpznCY8ntlWy%2Bj%2FJmTNN2tuDT0U7%2BC0eS943tevGdnKmJLJVtMOyWltPq0RZThhCbIDKZI%2F19zUUhI5ClfyCgaDxb7DjVe7HUDhBuIBihtNjctTxgAnc2ZuVUkNpPcONPXa3KkkOHPPt2S59rh5WOJ8Lep60%2B8kVuNoQvbuzeVx28Leu0jad%2BF4tdoidPT4hcXxjF6UmO89%2FF5Jpln44gZlBdC9Jd3qXzRLR6h%2Bwll%2BiGBqDiIXTFaUCrHKTDxmoJDmIkZPa9I8xHGmA6sVk%7Ctkp%3ABk9SR_jBvMKQYw >> >> :-) >> >> Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Dec 22 08:49:20 2023 From: rminnich at gmail.com (ron minnich) Date: Thu, 21 Dec 2023 14:49:20 -0800 Subject: [TUHS] DMD 5620 mouse available In-Reply-To: References: <202312211245.3BLCju9l010561@freefriends.org> Message-ID: "100%Positive Feedback" - whoa. Not so sure after this price. On Thu, Dec 21, 2023 at 2:46 PM ron minnich wrote: > John Floren, get Stefan R. to make you up the kind of box he makes for > Amiga hardware, to match that box; then start a production run of your > mice; then sell them in boxed set at 90% off the price of that $31K mouse. > Hey! 90% off! and you can actually plug it into something, what's not to > like. > > You can offer, for another $1K, to put flattened lead weights from > Champagne bottles in them! (but you'll have to find some way to dispose of > the extra champagne -- I'm here to help.) > > On Thu, Dec 21, 2023 at 2:25 PM Kenneth Goodwin < > kennethgoodwin56 at gmail.com> wrote: > >> It says best offer. >> >> Offer them $10.00... >> >> On Thu, Dec 21, 2023, 7:54 AM wrote: >> >>> ... at a rather high price: >>> >>> >>> https://www.ebay.com/itm/265518759380?hash=item3dd226bdd4:g:8gUAAOSwW21h8N7e&amdata=enc%3AAQAIAAAA4HG36wMdUgdY7m9K1ejutY1DWpznCY8ntlWy%2Bj%2FJmTNN2tuDT0U7%2BC0eS943tevGdnKmJLJVtMOyWltPq0RZThhCbIDKZI%2F19zUUhI5ClfyCgaDxb7DjVe7HUDhBuIBihtNjctTxgAnc2ZuVUkNpPcONPXa3KkkOHPPt2S59rh5WOJ8Lep60%2B8kVuNoQvbuzeVx28Leu0jad%2BF4tdoidPT4hcXxjF6UmO89%2FF5Jpln44gZlBdC9Jd3qXzRLR6h%2Bwll%2BiGBqDiIXTFaUCrHKTDxmoJDmIkZPa9I8xHGmA6sVk%7Ctkp%3ABk9SR_jBvMKQYw >>> >>> :-) >>> >>> Arnold >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Dec 22 09:25:18 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 22 Dec 2023 10:25:18 +1100 Subject: [TUHS] DMD 5620 mouse available In-Reply-To: References: <202312211245.3BLCju9l010561@freefriends.org> Message-ID: On Thursday, 21 December 2023 at 14:49:20 -0800, ron minnich wrote: > "100%Positive Feedback" - whoa. Not so sure after this price. That wasn't the price for which he got feedback. The two for which I found prices were $140 (down from asking $530) and $28.24 (down from asking $84.50). So yes, "best offer" clearly works. Who knows? Maybe you can get the mouse for, say, $11,500. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri Dec 22 11:13:23 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 22 Dec 2023 01:13:23 +0000 Subject: [TUHS] DMD 5620 mouse available In-Reply-To: References: <202312211245.3BLCju9l010561@freefriends.org> Message-ID: I see this mouse from time to time when combing for old AT&T computing things, it's been up for quite some time at that price. I don't think I'd even pony that up for a pristine WECo 3B20S... That said, a DMD is one of the two CRT computer displays I would still be very much interested in digging around in someday, the other being a Dataspeed 40/2. Doubtful either will ever be in front of me but a guy can dream. Hopefully someone reasonable makes them a reasonable offer and nobody "loses" on this one, but I don't see it going that way. - Matt G. On Thursday, December 21st, 2023 at 3:25 PM, Greg 'groggy' Lehey wrote: > On Thursday, 21 December 2023 at 14:49:20 -0800, ron minnich wrote: > > > "100%Positive Feedback" - whoa. Not so sure after this price. > > > That wasn't the price for which he got feedback. The two for which I > found prices were $140 (down from asking $530) and $28.24 (down from > asking $84.50). So yes, "best offer" clearly works. Who knows? > Maybe you can get the mouse for, say, $11,500. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php From tuhs at tuhs.org Fri Dec 22 11:31:25 2023 From: tuhs at tuhs.org (John Floren via TUHS) Date: Thu, 21 Dec 2023 17:31:25 -0800 (PST) Subject: [TUHS] DMD 5620 mouse available In-Reply-To: References: <202312211245.3BLCju9l010561@freefriends.org> Message-ID: <24a2ced6-3fa7-4b05-a328-a09c37dcc517@jfloren.net> Yeah, a DMD is #1 on my wishlist. I already have the mouse and keyboard but finding the terminal itself is a challenge. John From tuhs at tuhs.org Sun Dec 24 02:56:28 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 23 Dec 2023 16:56:28 +0000 Subject: [TUHS] Historic "Communications Etiquette" Practices? Message-ID: Good time of day folks, I often ponder on people's attachments to pixels on the screen that come about by clicking *this* icon and typing in a box surrounded by blue and with an icon in position vs pixels on the screen that come about instead by opening that application that is a black border with a little paper airplane button in the bottom right vs....etc. To make it more clear, I find myself often confused at people treating email different from SMS different from social media DMs different from forum posts different from some other mechanism that like literally all the others is pixels arranged into glyphs on a screen conveying an approximation of human speech. This difference among these different ways to send said pixels to people has eluded me all my life despite working with technology since I was a tot. What this has me curious on is if in the early days of UNIX there were attempts at suggesting which provided communication mechanisms were appropriate for what. For instance something that smells of: It is appropriate to use mail(1) to send a review of a piece of work vs it is appropriate to use write(1) to ask Jim if he wants to take a lunch break before the big meeting. Did this matter to people back then like it seems to now? To me it's just pixels on a screen that are there when I look at them and aren't when I don't. Truth be told I am hoping to learn something from this because I only do a couple email lists and web forums, my social life generally does not involve SMS, phone calls, nor social media. Where it has become tedious is someone I meet who seems to want to communicate over pixels on screens is then put off when I provide them an email address, usually asking instead if I have a Facebook or whatever the kids are calling Twitters today. The few times I've tried to explain email will be me transmitting you communication as pixel glyphs on a screen just like anything else would be me transmitting you communication as pixel glyphs on the screen, this doesn't diffuse their concerns any, they then just think there is something wrong with me for comparing words as pixels on a screen to words as pixels on a screen. Granted, I've probably avoided plenty of vapid people this way, but it feels like it's becoming more and more expected that "these pixels on the screen in *this* program are only for this and those pixels on the screen in *that* program are only for that". Is this a recent phenomenon? Has communication over electronic means always had these arbitrary limitations hoisted on it by the humans that use it? Or did people not give a hoot what you sent over what program and actually cared more about the words you're saying than the word you typed at a terminal to then be able to transmit words? I doubt what I learn is going to royally change my approach to allowing technology in my irl social life, but it would be nice to at least have more mental ammo when someone asks to be friends online and then gives me mad sideeye when I go "sure here's my email address!" - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sun Dec 24 05:46:34 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 23 Dec 2023 14:46:34 -0500 Subject: [TUHS] Historic "Communications Etiquette" Practices? In-Reply-To: References: Message-ID: On 12/23/23, segaloco via TUHS wrote: > > What this has me curious on is if in the early days of UNIX there were > attempts at suggesting which provided communication mechanisms were > appropriate for what. In the early days of Unix and Usenet terminal speeds were very slow--10 characters/second if you were on an acoustic modem dial-up line. Slow line speeds dictated two major communications etiquette rules: o Be terse and to the point. Don't waste your readers' time by being excessively verbal or by unnecessarily quoting previous posts in the discussion stream. And sending an email just to say "thank you" was considered being rude, not courteous, because you were wasting your correspondents' time. Similarly avoid "me too" messages. This caused quite the culture clash when AOL users were let loose on Usenet. AOL charged their customers based on their connect time, and so they encouraged a culture of excessive (by Unix standards) verbosity. o Don't top-post when replying to emails. You can't scroll down to see the context of the reply when working on a printing terminal. -Paul W. From ken.unix.guy at gmail.com Fri Dec 29 07:21:27 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 28 Dec 2023 16:21:27 -0500 Subject: [TUHS] Trying to compile cron Message-ID: Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 and am apparently missing required libraries. The reason is on the 3b2-400 after boot up it complains there is corruption in the crontab for every user lp, sysadm, root and so on. # make cron cc -O cron.c -o cron undefined first referenced symbol in file el_add cron.o el_delete cron.o el_empty cron.o el_first cron.o el_init cron.o xmalloc cron.o el_remove cron.o num cron.o days_in_mon cron.o days_btwn cron.o ld fatal: Symbol referencing errors. No output written to cron *** Error code 13 Stop. Does anyone have these libraries? Thanks. -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Fri Dec 29 07:55:08 2023 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 28 Dec 2023 21:55:08 +0000 (UTC) Subject: [TUHS] Trying to compile cron In-Reply-To: References: Message-ID: On Thu, 28 Dec 2023, KenUnix wrote: > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > and am apparently missing required libraries. The reason is > on the 3b2-400 after boot up it complains there is corruption > in the crontab for every user lp, sysadm, root and so on. > > # make cron >         cc -O  cron.c -o cron > undefined                       first referenced >  symbol                             in file > el_add                              cron.o > el_delete                           cron.o > el_empty                            cron.o > el_first                            cron.o > el_init                             cron.o > xmalloc                             cron.o > el_remove                           cron.o > num                                 cron.o > days_in_mon                         cron.o > days_btwn                           cron.o > ld fatal: Symbol referencing errors. No output written to cron > *** Error code 13 > > Stop. > > Does anyone have these libraries? Thanks. At first I thought the el_ code was editline code but that doesn't make sense in cron, but then I found the General-Purpose Event List Manager. See https://www.tuhs.org/cgi-bin/utree.pl?file=SysVR4/cmd/cron/elm.c and https://www.tuhs.org/cgi-bin/utree.pl?file=SysVR4/cmd/cron/funcs.c Does your cron source come with this other code? By the way, how to browse the SysVR4 code at TUHS? From imp at bsdimp.com Fri Dec 29 07:57:59 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 28 Dec 2023 14:57:59 -0700 Subject: [TUHS] Trying to compile cron In-Reply-To: References: Message-ID: On Thu, Dec 28, 2023, 2:55 PM Jeremy C. Reed wrote: > On Thu, 28 Dec 2023, KenUnix wrote: > > > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > > and am apparently missing required libraries. The reason is > > on the 3b2-400 after boot up it complains there is corruption > > in the crontab for every user lp, sysadm, root and so on. > > > > # make cron > > cc -O cron.c -o cron > Try just cc *.c -o cron > undefined first referenced > > symbol in file > > el_add cron.o > > el_delete cron.o > > el_empty cron.o > > el_first cron.o > > el_init cron.o > > xmalloc cron.o > > el_remove cron.o > > num cron.o > > days_in_mon cron.o > > days_btwn cron.o > > ld fatal: Symbol referencing errors. No output written to cron > > *** Error code 13 > > > > Stop. > > > > Does anyone have these libraries? Thanks. > > At first I thought the el_ code was editline code but that doesn't make > sense in cron, but then I found the General-Purpose Event List Manager. > > See > https://www.tuhs.org/cgi-bin/utree.pl?file=SysVR4/cmd/cron/elm.c > and > https://www.tuhs.org/cgi-bin/utree.pl?file=SysVR4/cmd/cron/funcs.c > > Does your cron source come with this other code? > > By the way, how to browse the SysVR4 code at TUHS? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Fri Dec 29 08:13:53 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 28 Dec 2023 17:13:53 -0500 Subject: [TUHS] Trying to compile cron In-Reply-To: References: Message-ID: I forgot to mention it is running System-5 r3 not r4.. On Thu, Dec 28, 2023 at 4:55 PM Jeremy C. Reed wrote: > On Thu, 28 Dec 2023, KenUnix wrote: > > > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > > and am apparently missing required libraries. The reason is > > on the 3b2-400 after boot up it complains there is corruption > > in the crontab for every user lp, sysadm, root and so on. > > > > # make cron > > cc -O cron.c -o cron > > undefined first referenced > > symbol in file > > el_add cron.o > > el_delete cron.o > > el_empty cron.o > > el_first cron.o > > el_init cron.o > > xmalloc cron.o > > el_remove cron.o > > num cron.o > > days_in_mon cron.o > > days_btwn cron.o > > ld fatal: Symbol referencing errors. No output written to cron > > *** Error code 13 > > > > Stop. > > > > Does anyone have these libraries? Thanks. > > At first I thought the el_ code was editline code but that doesn't make > sense in cron, but then I found the General-Purpose Event List Manager. > > See > https://www.tuhs.org/cgi-bin/utree.pl?file=SysVR4/cmd/cron/elm.c > and > https://www.tuhs.org/cgi-bin/utree.pl?file=SysVR4/cmd/cron/funcs.c > > Does your cron source come with this other code? > > By the way, how to browse the SysVR4 code at TUHS? > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Fri Dec 29 08:23:02 2023 From: tuhs at cuzuco.com (Brian Walden) Date: Thu, 28 Dec 2023 17:23:02 -0500 (EST) Subject: [TUHS] Trying to compile cron Message-ID: <202312282223.3BSMN2W8004242@cuzuco.com> As I messed with making a custom cron in the late 80s, remembered the the el_ functions are for event list processing. But you didn't specify the source of your source, by the hardware it needs to be of System V heritage. And a lot of that source is hard to offically come by due to licensing. Good way to view old SVR4 is to look at OpenIndiana, Illumos, or OpenSolaris code bases that you can find. You're in luck, as TUHS has a copy, see -- https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/cron/elm.c Look at the Makefile for the other files you need to compile into it too. -Brian KenUnix wrote: > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > and am apparently missing required libraries. The reason is > on the 3b2-400 after boot up it complains there is corruption > in the crontab for every user lp, sysadm, root and so on. > > # make cron > cc -O cron.c -o cron > undefined first referenced > symbol in file > el_add cron.o > el_delete cron.o > el_empty cron.o > el_first cron.o > el_init cron.o > xmalloc cron.o > el_remove cron.o > num cron.o > days_in_mon cron.o > days_btwn cron.o > ld fatal: Symbol referencing errors. No output written to cron > *** Error code 13 > > Stop. From rich.salz at gmail.com Fri Dec 29 08:44:58 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 28 Dec 2023 17:44:58 -0500 Subject: [TUHS] Trying to compile cron In-Reply-To: References: Message-ID: One thing that would INCREDIBLY help people trying to help you is find where the symbol is used, look up the variable types in the function call, and create a prototype. For example, both of these are valid xmalloc instances: char *xmalloc(int size); char *xmalloc(int size, unsigned char fillvalue) Seeing the use in the code you are trying to compile will help avoid wrong answers. People already likely gave you the answers, but a little leg work on your own before posting will help. On Thu, Dec 28, 2023 at 4:22 PM KenUnix wrote: > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > and am apparently missing required libraries. The reason is > on the 3b2-400 after boot up it complains there is corruption > in the crontab for every user lp, sysadm, root and so on. > > # make cron > cc -O cron.c -o cron > undefined first referenced > symbol in file > el_add cron.o > el_delete cron.o > el_empty cron.o > el_first cron.o > el_init cron.o > xmalloc cron.o > el_remove cron.o > num cron.o > days_in_mon cron.o > days_btwn cron.o > ld fatal: Symbol referencing errors. No output written to cron > *** Error code 13 > > Stop. > > Does anyone have these libraries? Thanks. > -- > WWL 📚 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Dec 29 12:27:12 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 29 Dec 2023 02:27:12 +0000 Subject: [TUHS] Trying to compile cron In-Reply-To: References: Message-ID: If you're building on SVR3, cd /usr/src/cmd/cron && make -f cron.mk should suffice, all four variations on SVR3 sources I have have a cron.mk included. Curiously, my SVR3.2 for 3B2 sources are missing elm.c and some other bits, and actually wouldn't build, if you've specifically snagged SVR3.2, you might try sources from another revision, if we pulled from the same source you're probably also missing elm.c in that specific revision. There's also an M68k version of SVR3.1 floating around out there somewhere that appears to have the necessary bits, I can't imagine there's anything platform specific in cron. Finally, there's always good old "grep -r 'el_add' /usr/src" and "find /usr/src -name elm.c" Best of luck! - Matt G. On Thursday, December 28th, 2023 at 1:21 PM, KenUnix wrote: > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > and am apparently missing required libraries. The reason is > on the 3b2-400 after boot up it complains there is corruption > in the crontab for every user lp, sysadm, root and so on. > > # make cron > cc -O cron.c -o cron > undefined first referenced > symbol in file > el_add cron.o > el_delete cron.o > el_empty cron.o > el_first cron.o > el_init cron.o > xmalloc cron.o > el_remove cron.o > num cron.o > days_in_mon cron.o > days_btwn cron.o > ld fatal: Symbol referencing errors. No output written to cron > *** Error code 13 > > Stop. > > Does anyone have these libraries? Thanks. > -- > > WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Dec 29 16:30:28 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 29 Dec 2023 06:30:28 +0000 Subject: [TUHS] Early 70's WECo "Turnkey Systems"? Re: S.S. Pirzada UNIX Paper Message-ID: In S.S. Pirzada's 1988 paper[1], page 35, section 3.3.2, he writes: "Some operating telephone companies and the switching control center system (SCCS) group in Holmdel, NJ decided to use UNIX to collect maintenance data from their switches and for administration purposes. Other departments also started building applications on top of UNIX, some part of turnkey systems licensed by Western Electric (WECo)." This is describing the situation before the establishment of USG in September 1973. I'm curious, does anyone recall what some of these pre-USG WECo "turnkey systems" were? The things that come to mind when I think of that phrase don't come about for several years, such as the 5ESS and other work surrounding Bellmac stuff. The SCCS UNIX connection describes what becomes CB-UNIX if I understand the situation correctly, but that stays a bit afield from the more conventional pool that is dipped into for WECo needs. Switching and UNIX all kinda come back together with DMERT on 1A/3B-API and 5ESS, but again that's late 70s R&D, early 80s deployment, not this time period, leaving me terribly curious what WECo would've been bundling UNIX with and shipping out to telcos. The famous early use of UNIX in the Bell System is typography, and WECo did have involvement with Teletype equipment, so perhaps something along those lines? If it helps set the scene, a binder I recently picked up from ~1972 describing Western Electric test sets distributed to telcos describes the following additional classes of such documents: Shop Services - Special non-standard products Public Telephones - System standard public telephone equipment Data Communications - Teletypewriter and Data Sets Subscriber Products - System standard PBX's, station equipment and special services Non-Subscriber Products - Microwave, cable, power equipment, etc. Non-Bell Equipment Index - Non-Bell System manufactured communication equipment Unfortunately haven't seen any of the other binders yet but I've been keeping an eye out, one or another might describe something WECo was shipping around that had some UNIX up in it. Nothing in this binder seems computer-y enough to run an operating system, just lots of gauges, dials, and probes. Luckily it is quite clear what data test sets are designed for 103-data set maintenance so I have fodder for seeking Dataphone tools... Anywho, happy soon to be new year folks, I'm excited to see what turns up next year! - Matt G. [1] - https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf From jsg at jsg.id.au Fri Dec 29 17:28:49 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 29 Dec 2023 18:28:49 +1100 Subject: [TUHS] Early 70's WECo "Turnkey Systems"? Re: S.S. Pirzada UNIX Paper In-Reply-To: References: Message-ID: On Fri, Dec 29, 2023 at 06:30:28AM +0000, segaloco via TUHS wrote: > In S.S. Pirzada's 1988 paper[1], page 35, section 3.3.2, he writes: > > "Some operating telephone companies and the switching control center > system (SCCS) group in Holmdel, NJ decided to use UNIX to collect > maintenance data from their switches and for administration purposes. > Other departments also started building applications on top of UNIX, > some part of turnkey systems licensed by Western Electric (WECo)." > > This is describing the situation before the establishment of USG > in September 1973. I'm curious, does anyone recall what some of > these pre-USG WECo "turnkey systems" were? Perhaps a reference to COSNIX/COSMOS? described by Henry Spencer in https://www.tuhs.org/Usenet/comp.unix.wizards/1985-May/002932.html and by Alan E. Kaplan in "A History of the COSNIX Operating System: Assembly Language Unix 1971 to July, 1991." USENIX Winter 1992 Technical Conference, pp. 429-437 https://archive.org/details/winter92_usenix_technical_conf/page/428/mode/2up From imp at bsdimp.com Sat Dec 30 05:44:50 2023 From: imp at bsdimp.com (Warner Losh) Date: Fri, 29 Dec 2023 12:44:50 -0700 Subject: [TUHS] Early 70's WECo "Turnkey Systems"? Re: S.S. Pirzada UNIX Paper In-Reply-To: References: Message-ID: On Fri, Dec 29, 2023, 12:29 AM Jonathan Gray wrote: > On Fri, Dec 29, 2023 at 06:30:28AM +0000, segaloco via TUHS wrote: > > In S.S. Pirzada's 1988 paper[1], page 35, section 3.3.2, he writes: > > > > "Some operating telephone companies and the switching control center > > system (SCCS) group in Holmdel, NJ decided to use UNIX to collect > > maintenance data from their switches and for administration purposes. > > Other departments also started building applications on top of UNIX, > > some part of turnkey systems licensed by Western Electric (WECo)." > > > > This is describing the situation before the establishment of USG > > in September 1973. I'm curious, does anyone recall what some of > > these pre-USG WECo "turnkey systems" were? > > Perhaps a reference to COSNIX/COSMOS? > > described by Henry Spencer in > https://www.tuhs.org/Usenet/comp.unix.wizards/1985-May/002932.html > > and by Alan E. Kaplan in > "A History of the COSNIX Operating System: Assembly Language Unix 1971 > to July, 1991." USENIX Winter 1992 Technical Conference, pp. 429-437 > > https://archive.org/details/winter92_usenix_technical_conf/page/428/mode/2up Nice finds. I thought I'd found all the papers on early unix... and i had no idea of this one. Thanks. Warner Warner > > -------------- next part -------------- An HTML attachment was scrubbed... URL: