From wkt at henry.cs.adfa.oz.au Thu Nov 12 12:57:45 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Thu, 12 Nov 1998 13:57:45 +1100 (EST) Subject: Upgrade of PUPS List server Message-ID: <199811120257.NAA04829@henry.cs.adfa.oz.au> All, I have just upgraded the server where the PUPS mailing list resides, to a newer operating system version. This email is just to test that the MajorDomo software is still working. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA04919 for pups-liszt; Thu, 12 Nov 1998 14:28:57 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Thu Nov 12 14:55:23 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 11 Nov 1998 23:55:23 -0500 Subject: 4.3BSD-Tahoe and 4.3BSD-Reno Message-ID: <199811120455.XAA09098@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have converted the 4.3BSD-Tahoe and 4.3BSD-Reno tape images Rick has recently uploaded into a more convenient format. I haven't changed anything in the images themselves, I have simply repacked them from a single .zip into a collection of .gz's, one per tape file. I have also prepared a listing for every tarball. This stuff is in: /usr/home/msokolov/43tahoe.cci (4.3BSD-Tahoe with CCI binaries) /usr/home/msokolov/43reno.vax (4.3BSD-Reno with VAX binaries) That's on minnie.cs.adfa.oz.au. The permissions are set up so that pupsarc group members (UNIX source license holders) can read them, but no one else can. With Warren's permission, I would like to keep this stuff there until I set up my own FTP site, at which time I'll announce its location. The Reno images are perfect, but for Tahoe usr.tar.gz and src.tar.gz are bad (everything else is fine). Apparently Rick wasn't able to read past a tape defect (we are handling this in private E-mail). Have fun with this stuff! Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA04992 for pups-liszt; Thu, 12 Nov 1998 14:37:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Thu Nov 12 14:51:32 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Thu, 12 Nov 1998 15:51:32 +1100 (EST) Subject: 4.3BSD-Tahoe and 4.3BSD-Reno In-Reply-To: <199811120455.XAA09098@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 11, 98 11:55:23 pm" Message-ID: <199811120451.PAA05125@henry.cs.adfa.oz.au> In article by Michael Sokolov: >I have converted the 4.3BSD-Tahoe and 4.3BSD-Reno tape images Rick has recently > uploaded into a more convenient format. I haven't changed anything in the > images themselves, I have simply repacked them from a single .zip into a > collection of .gz's, one per tape file. I have also prepared a listing for > every tarball. This stuff is in: > > /usr/home/msokolov/43tahoe.cci (4.3BSD-Tahoe with CCI binaries) > /usr/home/msokolov/43reno.vax (4.3BSD-Reno with VAX binaries) I'll move copies of Michael's 43tahoe.cci and 43reno.vax directories into the main PUPS archive area, in the Distributions/4bsd area. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id WAA01355 for pups-liszt; Fri, 13 Nov 1998 22:58:33 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Fri Nov 13 22:05:43 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Fri, 13 Nov 1998 07:05:43 -0500 Subject: 4.2BSD and 4.3BSD Message-ID: <199811131205.HAA09705@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have just uploaded the images from the 4.3BSD tapes I had read on CWRU's MVS mainframe back in June. They are perfect (the 1600 BPI tapes were read without any errors and the format is absolutely correct). Note, though, that this is the June 1986 4.3BSD release, and I remember Kirk saying that among the tapes Rick is reading there is one with 4.3BSD revision 2, which is presumably 4.3BSD with some bugs fixed. I have also put an honest effort into reconstructing the 4.2BSD tape images from the files in Distributions/4bsd/Per_Andersson_4.2. The latter have the boot/standalone system file (1st on the tape) broken, the tarball with /usr/src also broken, and the tarball with /usr/lib/vfont simply missing. I have manually repaired the boot/standalone system file (using my brain and a hex editor), but unfortunately /usr/src is broken beyond repair (so I didn't include it in my repackaging). I see no reason for the Varian/Versatec fonts to change between BSD releases, so /usr/lib/vfont from 4.3BSD will probably do fine. It would still be nice if Rick could read Kirk's 4.2BSD tapes, though. For practical use 4.3BSD completely supersedes it, but for historical purposes we should preserve 4.2BSD as well. This stuff is in: /usr/home/msokolov/42.vax (4.2BSD) /usr/home/msokolov/43.vax (4.3BSD) on minnie.cs.adfa.oz.au. (Warren, if you want to put this in the main PUPS archive, go ahead and do it for 43.vax, as it should be ready to be frozen, but I would hold on with 42.vax. Hopefully Rick will have some luck reading Kirk's tapes, and then I'll update the 42.vax directory by filling the missing pieces.) Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA15543 for pups-liszt; Tue, 17 Nov 1998 06:04:29 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 17 05:14:44 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 16 Nov 1998 11:14:44 -0800 Subject: 4.3BSD-Tahoe and 4.3BSD-Reno Message-ID: <3.0.32.19981116111440.00922460@pop.calweb.com> Warren, I am unable to login to minnie, I keep getting back "user rickgc access denied!". Why? Thanks, Rick Copeland Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA05416 for pups-liszt; Fri, 20 Nov 1998 12:57:22 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Fri Nov 20 12:09:52 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Thu, 19 Nov 1998 21:09:52 -0500 Subject: KA650 problem Message-ID: <199811200209.VAA15512@skybridge.scl.cwru.edu> Dear Ladies and Gentlemen, I'm trying to build my first release (4.3BSD-Quasijarus1), and I have the following problem. I'm currently away from my main VAX farm, and so I have rounded up a new VAX for this task from an independent source. It's a KA650-based MicroVAX specially made for Xerox. The outer cabinet is made by Xerox, but it has a BA23 mounted inside. There is no video, just a serial terminal. My first problem was that the beast refused to power up. I turn on the power, but there is nothing on the console and the hex LED display on the back says 9. I power-cycled it several times with zero effect, and then I took the CPU board out to look at it. It looked perfectly normal, and I put it back in. Then imagine my joy when I power up the VAX and this time it works! After that I worked with it for a while, and in the process I turned it on and off a couple of times and it didn't have any problem powering up. My next step was installing Ultrix, which is the platform I have chosen to use for putting together the initial Quasijarus SCCS tree and cross- compiling the very first Quasijarus build. However, when I tried to boot from the Ultrix tape, I got a "?4B CTRLERR" (after an _extremely_ long wait with a lot of retries), which according to my docs means some hardware error. I reasoned that it has to be either the TK50 drive or the TQK50 controller. I don't have any spare TK50s at this location, but I do have one spare controller, and so I tried swapping it. I turned the machine off, swapped the board, and turned it back on. And guess what, that ugly 9 came back! I haven't been able to power up the VAX since then. I started investigating. I don't have any docs for KA650, but I do have some for KA655. According to these docs, the KA650 series CPUs have very elaborate ROM diagnostics organized in the form of scripts, some of which are executed at power-up. The manual lists all scripts, indicating the order of the tests and the hex LED display codes. According to this manual, the only tests which display a 9 are fairly late in the sequence and are fairly benign (shouldn't stall the power-up even if failed). The problem I'm seeing, OTOH, appears to be very early. For example, the console line loopback test appears to be one of the very first, and yet my VAX always stalls on the 9, even if I put the switch in the T-in-the-circle position. I have also watched the hex LED display very carefully right as I flip the power switch, and as far as I can tell it goes directly from F (waiting for DCOK) to 9. Finally, disconnecting the bulkhead and the memory interconnect produces absolutely no effect, suggesting that the culprit is the CPU board and nothing else. Also pushing the RESTART button on the front panel produces absolutely no effect, if the 9 was there it just stays there, there is no F appearing for a short time or anything like that. What does the RESTART button do, anyway? Does anyone here have a clue as to what's going on? Does anyone have a KA650 manual? Can anyone tell what the hell does the 9 stand for? Any ideas on how this can be fixed (other than replacing the CPU board)? TIA. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA06383 for pups-liszt; Fri, 20 Nov 1998 19:08:01 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From bdc at world.std.com Fri Nov 20 18:07:44 1998 From: bdc at world.std.com (Brian D Chase) Date: Fri, 20 Nov 1998 00:07:44 -0800 (PDT) Subject: Loads of PDP-11 docs on Ebay. Message-ID: Just an FYI for all you PDP-11 collectors out there. A search for "DEC" under the Computers section of Ebay yields an impressive number of PDP-11 docs. -brian. --- Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!! Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA09000 for pups-liszt; Sat, 21 Nov 1998 09:58:30 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From grog at lemis.com Sat Nov 21 08:57:40 1998 From: grog at lemis.com (Greg Lehey) Date: Sat, 21 Nov 1998 09:27:40 +1030 Subject: Loads of PDP-11 docs on Ebay. In-Reply-To: ; from Brian D Chase on Fri, Nov 20, 1998 at 12:07:44AM -0800 References: Message-ID: <19981121092740.F1005@freebie.lemis.com> On Friday, 20 November 1998 at 0:07:44 -0800, Brian D Chase wrote: > Just an FYI for all you PDP-11 collectors out there. A search for "DEC" > under the Computers section of Ebay yields an impressive number of PDP-11 > docs. What's Ebay? Greg -- See complete headers for address, home page and phone numbers finger grog at lemis.com for PGP public key Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA09072 for pups-liszt; Sat, 21 Nov 1998 10:32:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From bdc at world.std.com Sat Nov 21 09:31:51 1998 From: bdc at world.std.com (Brian D Chase) Date: Fri, 20 Nov 1998 15:31:51 -0800 (PDT) Subject: Loads of PDP-11 docs on Ebay. In-Reply-To: <19981121092740.F1005@freebie.lemis.com> Message-ID: On Sat, 21 Nov 1998, Greg Lehey wrote: > On Friday, 20 November 1998 at 0:07:44 -0800, Brian D Chase wrote: > > Just an FYI for all you PDP-11 collectors out there. A search for "DEC" > > under the Computers section of Ebay yields an impressive number of PDP-11 > > docs. > > What's Ebay? Sorry about that... I'd thought everybody knew by now. It's the world's largest and most popular on-line auction service. http://www.ebay.com/ -brian. --- Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!! Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA12024 for pups-liszt; Sun, 22 Nov 1998 04:51:52 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 03:49:46 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 12:49:46 -0500 Subject: 4.3BSD Installation (probably off-topic) Message-ID: <981121124946.2a2000ed@trailing-edge.com> I've been looking over the recent 4.3-ish BSD distributions now available from the PUPS archive. Thought I'd spin off a copy for booting on one of my spare uVax II's, but I'm stuck at (literally) before step one, and don't know where to go from here. If there's a more appropriate forum for these questions, I'd appreciate being redirected to them! OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is: YOU MUST ALREADY HAVE A WORKING VAX! These instructions are useless on a cold machine. You must have a 4.3 machine and a working uVax (probably Ultrix!) with a tk50 drive. Apparently, this is because the distributions don't boot on a Microvax, and the KA630 Microvax/MSCP/TMSCP patches must be installed and many things rebuilt on a 4.3 machine before a distribution tape can be built to put on a VAX. Is this an actual limitation on the 43reno.vax distribution currently in the archive, or not? If it is a real limitation, what non- microvax machines will the 43reno.vax distribution boot on? 11/750? 11/730? Tim. (shoppa at trailing-edge.com) Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA12354 for pups-liszt; Sun, 22 Nov 1998 06:15:56 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 05:28:28 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sat, 21 Nov 1998 14:28:28 -0500 Subject: 4.3BSD Installation (probably off-topic) Message-ID: <199811211928.OAA15984@skybridge.scl.cwru.edu> SHOPPA at trailing-edge.com writes: > I've been looking over the recent 4.3-ish BSD distributions > now available from the PUPS archive. Thought I'd spin off > a copy for booting on one of my spare uVax II's [...] The most important thing here is to choose the right version of BSD. Plain 4.3 CANNOT boot on a MicroVAX II. Later versions, starting with Tahoe, can. The patches provided in 4.3_on_uVax_instructions are nothing more than pieces taken out of Tahoe. If you are going to use those, you might want to use the whole Tahoe system just as well, it has some very nice improvements, such as disk labels, better man mechanism, and MX record support in sendmail. The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe tape with VAX binaries. I'm not sure if CSRG ever bothered to even make one, although it's as simple as executing one script on a running system (which they obviously had). Thus in order to run Tahoe, one would have to cross-compile it first. It's a pain and takes a lot of expertise, so I would strongly advise you to avoid effort duplication and wait until I do it and put the product up in my home directory on minnie.cs.adfa.edu.au. Actually since KA650 is all I have right now and Tahoe doesn't support it (but the support code appears later in the SCCS tree), I'll go directly from Ultrix (my cross-compilation base) to Quasijarus1, my first release, and won't bother with Tahoe. But for all practical purposes Quasijarus1 will be Tahoe plus KA650 support, shadow passwords, and bugfixes. Hmm, maybe your have never heard of Quasijarus Project, so I'll explain briefly what it is. I'm taking over UCB CSRG in terms of shepherding and maintaining pure Berkeley UNIX(R). I will first re-create it by taking their final SCCS tree and building my initial one, deciding piece by piece what belongs to pure Berkeley UNIX(R) and should be kept, and what is POSIX evil spirit or bloat and should be tossed. In general I draw the line right around the Tahoe release (summer of 1988), but I'll include anything from Reno and later code that's worth having, such as KA650 support and Reno's DBM-based shadow password model. Basically, I want to create a system with a classical (pre-Reno) look and feel which at the same time has all the quality improvements and bugfixes ever made by Berkeley, even if they are as late as 4.4BSD. The last classical release is Tahoe, so that's my base. I will be using Tahoe to decide what should be included and what should the look and feel be. Once I know from Tahoe that a given piece should be included, I'll go to the SCCS file(s) for that piece and decide which post- Tahoe deltas should be kept (because they are bugfixes or quality improvements) and which deltas should be tossed (because they introduce the evil spirit of POSIX or bloat). How soon will this happen? I'm all ready to go, but unfortunately hardware problems are holding me back. I have solved the KA650 problem I was having, but now I'm stuck because neither of the two TQK50 boards I have works. (The drive SEEMS to work, though.) Thus the sooner I find a working TQK50 board (or, alternatively, a working TK70/TQK70 pair), the sooner will I make 4.3BSD-Quasijarus1. > If there's a more appropriate forum for these questions, I'd > appreciate being redirected to them! Right now there isn't, because my main VAX farm is currently off the net. When I get it back on the net (no time estimate, at least several more months), I'll set up a set of mailing lists for Quasijarus Project and Berkeley VAX UNIX in general. > OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is: Totally disregard these instructions, they are for plain 4.3 ONLY. If you are using Tahoe or Quasijarus1, the distribution already supports MicroVAXen as shipped. If you don't want to use Tahoe or Quasijarus1 and want to use plain 4.3, you are on your own. > Is this an actual limitation on the 43reno.vax distribution currently > in the archive, or not? Reno doesn't have any limitations, it already supports KA630 and KA650, just like Quasijarus1. I personally don't use it, though, because it is not really True UNIX any more. With the evil spirit of POSIX and a bloat by a factor of 2 in both binaries and sources, Reno is the beginning of the destructive process that eventually (and necessarily) culminated with the disbanding of CSRG. > what non- > microvax machines will the 43reno.vax distribution boot on? 11/750? > 11/730? Of the big VAXen, plain 4.3 supports 11/780, 11/750, 11/730, and Venus (should have been called 11/790, but was unfortunately named 8600). Tahoe adds, and Quasijarus1 and Reno retain, the support for 8200. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA12654 for pups-liszt; Sun, 22 Nov 1998 07:42:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 06:40:02 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 15:40:02 -0500 Subject: 4.3BSD Tahoe binaries for uVax Message-ID: <981121154002.2a2000ed@trailing-edge.com> > The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe >tape with VAX binaries. I think I *might* be able to provide part of the solution to this. I have in my posession here a TK50 tape hand-labeled "4.3 Tahoe BSD". Let me upload it to my directory on Minnie, and maybe with some help from you guys we'll figure out what's in it. It has been at least a year since I've looked at the contents of this tape, but I was under the impression that it consisted mainly of binaries, and had very little in the way of sources on it. I'll put images of the tape files on Minnie (hmm - a full TK50 will probably be an overnight job) and with a little luck we'll figure out how to make the next step. (I didn't know that this was a sought-after tape in the first place!) I honestly don't know if this is a VAX Tahoe distribution or for something else (MIPS, maybe?). It did fail to boot on my KA650 when I tried it, but your notes indicate that this was to be expected because it wasn't a KA630. And browsing through the contents of the tape does seem to indicate that it might be for the VAX. The tape has 4 files on it, about 50 Megabytes uncompressed, organized as follows: File 1: 1 record, 512 bytes. File 2: 205 records, 10240 bytes each. File 3: 320 records, 10240 bytes each. File 4: 2135 records, 20480 bytes each. The first block has no obvious text in it. Obvious guess is a boot block :-) The second file appears to be an executable of some sort. Running "strings" against it turns up evidence that this is some sort of standalone utility that knows how to write to devices with names like "ra1", "hp3", etc. The third file is, I would guess, the dump of a root file system. The string "/dev/ra1a" and machine name "kerberos.berkeley.edu" turn up near the beginning, and the dump of what appears to be the "/dev" directory has names such as tu0, tu1, hp0a-hp0g, rhp0a-rhp0g, etc. The fourth file is a tar archive, and appears to contain mainly binaries, with little in the way of sources. The are links in the tar archive to things like "/sys/vaxuba", "/sys/vax", etc., but the /sys directory itself isn't in the tar archive. (Would this possibly be in the third file, which I guessed is a dump of the root filesystem? The other BSD- derived distributions that I'm familiar with do not have "/sys" or "/usr/src/sys" in the root filesystem!) -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA12866 for pups-liszt; Sun, 22 Nov 1998 08:41:48 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 07:39:31 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 16:39:31 -0500 Subject: 4.3BSD Tahoe binaries for uVax Message-ID: <981121163931.2a2001df@trailing-edge.com> Some further clues, for anyone who's following this bit or archeology: The second file on the tape has the following string in it: 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990 trent at kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot The third file has this string in it: 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990 trent at kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax. Additionally, in the third file, there appears to be some printf-type strigns for configuring in the different possible CPU's supported: VAX 8600, serial# %d(%d), hardware level %d(%d) VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d) VAX 11/750, hardware rev %d, ucode rev %d VAX 11/730, ucode rev %d MicroVAX-II-MicroVAX 3000, ucode rev %d So the tape sticker says "Tahoe", the miniroot and Generic root claim to be Reno, and the fourth file (the tar archive) has the following mentions of Tahoe and Reno: $ sear file4.tar_list tahoe 755 0 Jul 29 06:26:47 1990 share/man/cat4/tahoe/ 444 2488 Jul 29 06:26:43 1990 share/man/cat4/tahoe/ace.0 444 3563 Jul 29 06:26:44 1990 share/man/cat4/tahoe/autoconf.0 444 1321 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cons.0 444 6446 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cy.0 444 4074 Jul 29 06:26:44 1990 share/man/cat4/tahoe/dr.0 444 2331 Jul 29 06:26:44 1990 share/man/cat4/tahoe/enp.0 444 4121 Jul 29 06:26:44 1990 share/man/cat4/tahoe/ik.0 444 2498 Jul 29 06:26:45 1990 share/man/cat4/tahoe/intro.0 444 386 Jul 29 06:26:45 1990 share/man/cat4/tahoe/lp.0 444 4427 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mtio.0 444 9321 Jul 29 06:26:45 1990 share/man/cat4/tahoe/vd.0 444 3816 Jul 29 06:26:46 1990 share/man/cat4/tahoe/vx.0 444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mem.0 444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/kmem.0 ---> share/man/cat4/tahoe/mem.0 755 0 Jul 4 18:49:29 1990 share/man/cat6/tahoe/ $ sear file4.tar_list reno %SEARCH-I-NOMATCHES, no strings matched If someone who is more aware of the 4.3BSD histories than I am (and I'm certain that I'm one of the least-aware folks around!) can pinpoint where in the hierarchy this tape belongs, it'd help settle a lot of my confusion! In the meantime, the FTP connection to minnie seems to be holding up admirably, and folks will be able to inspect the files for themselves sometime around 7 PM EST tonight (Saturday here - that's either tomorrow or yesterday in Australia, I can never remember which) in the directory /usr/home/shoppa/43bsd_tahoe on minnie. -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13145 for pups-liszt; Sun, 22 Nov 1998 10:13:57 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 09:26:26 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sat, 21 Nov 1998 18:26:26 -0500 Subject: 4.3BSD Tahoe binaries for uVax Message-ID: <199811212326.SAA16073@skybridge.scl.cwru.edu> Tim Shoppa writes: > Some further clues, for anyone who's following this bit or > archeology: This is clearly a 4.3BSD-Reno tape (for VAX). I'll look at it when it's fully uploaded (you're saying it won't be until 19:00 EST, so it'll be after the X-Files I guess), but I can bet that it's identical to the one in /usr/home/msokolov/43reno.vax on minnie (read by Rick Copeland from the CSRG master provided by Marshall Kirk McKusick). > The second file on the tape has the following string in it: > > 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990 > trent at kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot The second file is the dd image of the miniroot filesystem. This string appears in the /vmunix file inside (the kernel). kerberos.berkeley.edu was a VAX. The tape in /usr/home/msokolov/43reno.vax has also been pressed from kerberos.berkeley.edu. > The third file has this string in it: > > 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990 > trent at kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax. The third file is the dump of the full root filesystem. Again, this string appears in the /vmunix file inside. > Additionally, in the third file, there appears to be some printf-type > strigns for configuring in the different possible CPU's supported: > > VAX 8600, serial# %d(%d), hardware level %d(%d) > VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d > VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d) > VAX 11/750, hardware rev %d, ucode rev %d > VAX 11/730, ucode rev %d > MicroVAX-II-MicroVAX 3000, ucode rev %d This is also obviously inside /vmunix. The set of supported CPUs is the one for Reno. > So the tape sticker says "Tahoe", the miniroot and Generic root claim > to be Reno, and the fourth file (the tar archive) has the following > mentions of Tahoe and Reno: > > [names on manpage directories mentioning tahoe] It is Reno. Trust me. "tahoe" appears in the names of some manpage directories because some manpages are architecture-specific (tahoe is the name of a computer architecture, just like vax, hp300, i386, etc.). The tape is mislabeled, that's all. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA13713 for pups-liszt; Sun, 22 Nov 1998 12:47:28 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 11:55:01 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sat, 21 Nov 1998 20:55:01 -0500 Subject: The files Tim Shoppa has just uploaded Message-ID: <199811220155.UAA16138@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have just logged into minnie and diffed the files Tim Shoppa has just uploaded against the 43reno.vax distribution in my home directory. They are identical byte for byte, except that Tim's first file is severely truncated. The first file contains the bootstraps and the standalone programs, and for Reno it's about 140 KB. Tim's first file is only 512 bytes, although these bytes exactly match the first 512 bytes in the correct first file. Resolution: the files Tim has uploaded are completely superseded by the authentic 4.3BSD-Reno/VAX distribution in /usr/home/msokolov/43reno.vax and /usr/PUPS/Distributions/4bsd/43reno.vax. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA13933 for pups-liszt; Sun, 22 Nov 1998 14:04:29 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 12:27:48 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 21:27:48 -0500 Subject: 4.3-VAX distributions (was Re: The files Tim Shoppa has just uploaded) Message-ID: <981121212748.2a2001f3@trailing-edge.com> > I have just logged into minnie and diffed the files Tim Shoppa has just >uploaded against the 43reno.vax distribution in my home directory. They are >identical byte for byte, Darn. And the label said it was a Tahoe distribution :-). You'll also remember that I'm the one who found the V6 RL02 packs at UBC which, despite all indications, are actually some sort of V7 system that has all the internal labels reading "V6"! > except that Tim's first file is severely >truncated. That would explain why I couldn't boot it, yep. In any event, I am now very happy to now have a bootable copy of 4.3-Reno. (Installing as I type, AAMAF.) We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? It's the most reasonable approach I can think of at the moment. And what stands in the way of reading around the bad blocks on Kirk McKusick's 43tahoe_cci distribution? Even though I know that Rick Copeland doesn't have all the fancy tape recovery equipment I have in my lab, is there some fundamental problem preventing the use of "mt fsr" commands to skip the bad block(s) and recover the rest of the "src" and "usr" tree? -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA14239 for pups-liszt; Sun, 22 Nov 1998 15:57:23 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 15:09:52 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 00:09:52 -0500 Subject: 4.3-VAX distributions Message-ID: <199811220509.AAA16197@skybridge.scl.cwru.edu> Tim Shoppa writes: > That would explain why I couldn't boot it, yep. Partially. You wouldn't be able to boot it on a MicroVAX by typing "B MUA0" even if it were complete. The reason is that the standard tape-making script writes the VAX-11 bootstraps on the tape, not the MicroVAX ones. The two are completely different. The big VAXen with front-end processors, microcode consoles and such can't boot from a tape by themselves. The bootstraps that appear on standard BSD distributions are designed to be loaded by manually typing in a little program from the console in hex and manually transferring control to it. The hex codes for 4 such programs (for different tape drives and controllers) appear in the installation docs. They cannot be ported to MicroVAXen, however, because they use some features that exist only on big VAXen. MicroVAXen, however, have tape boot capabilities built right into their ROMs. Much easier for the installer, needless to say. Also needless to say, the protocol the ROM tape boot code uses is completely different from the one the BSD developers have crafted for their very special purpose. Therefore, a tape needs a completely different bootstrap in order to be directly bootable on a MicroVAX. One was written for 4.3BSD-Tahoe, and it appears in the distributed /usr/mdec. There are two problems, however. First, the standard tape-making scripts don't put it on the tape. Second, it only supports KA630. When KA650 support was added, everything else was updated accordingly, but this one was apparently forgotten. In theory, the code looks generic enough to run on KA650 out of the box, but in practice it has a check for SID and refuses to run if it's not 08 (MicroVAX ii). Right now I don't know enough VAX assembly language to remove this check or extend to accept 0A (CVAX) as well. > In any event, I am now very happy to now have a bootable copy of > 4.3-Reno. (Installing as I type, AAMAF.) Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball and make a MicroVAX boot tape? > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > It's the most reasonable approach I can think of at the moment. That's close to what I'm doing. There are two differences, though. First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than between Tahoe and Reno. The latter is really huge, it's a gap between True UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus KA650 support and shadow passwords from Reno and other improvements from both later CSRG code and my own brain. SCCS will be the #1 tool in the process. > And what stands in the way of reading around the bad blocks on Kirk > McKusick's 43tahoe_cci distribution? Even though I know that Rick > Copeland doesn't have all the fancy tape recovery equipment I have in my > lab, is there some fundamental problem preventing the use of "mt fsr" > commands to skip the bad block(s) and recover the rest of the "src" and > "usr" tree? If you do this you will still miss something. OTOH, if you go to the 4.3tahoe directory on Kirk's 2nd CD-ROM, you won't miss anything, since all of /usr and /usr/src is there. I can bet that the files on that CD-ROM match the ones on the tape byte for byte. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA14402 for pups-liszt; Sun, 22 Nov 1998 17:04:17 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 15:32:06 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sun, 22 Nov 1998 0:32:06 -0500 Subject: 4.3-VAX distributions Message-ID: <981122003206.2a2001f3@trailing-edge.com> >> In any event, I am now very happy to now have a bootable copy of >> 4.3-Reno. (Installing as I type, AAMAF.) > Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it >to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball >and make a MicroVAX boot tape? Exactly. The details are all in tmscpboot.c. Prepend this to the "tape directory", write it to TK50, B MUA0, and you're at the "=" prompt, from which you can execute the standalone images. "format" seems to crash badly, but one probably doesn't need that on a Q-bus machine :-). There are other ways to start it up. For example, using an already- running OS (some other Unix or VMS) and copying the miniroot from tape to the swap area of an unused disk. The compiled-in partition tables used during an install are a real pain compared to, say, a 2.11BSD installation, where disklabel is a standalone utility! (That's a real win, Steven!) >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than >between Tahoe and Reno. The latter is really huge, it's a gap between True >UNIX(R) and a bloated and POSIXized fallen one.) Gees, looking at the install docs there are some very real improvements in Reno, especially in the filesystem and the speed of recompiled code. I'm willing to live with a bit more disk space usage, especially for the promised speed benefits. It's not like KA630's or KA650's are speed demons, and big cheap disks are readily available these days. -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14819 for pups-liszt; Sun, 22 Nov 1998 20:10:10 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From sms at moe.2bsd.com Sun Nov 22 19:00:06 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 22 Nov 1998 01:00:06 -0800 (PST) Subject: 4.3-VAX distributions Message-ID: <199811220900.BAA06484@moe.2bsd.com> Hi - > From: SHOPPA at trailing-edge.com > To: PUPS at MINNIE.CS.ADFA.EDU.AU All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't know there were any left :-) :-) > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" Since PUPS is on a uVax kick at the moment I'll chime in with my (not so fond) memories of trying to jack 4.3-Reno onto a uVax-II. It was a perverse sort of fun but not something I'd willingly do again. Burnout? Perhaps. the base 4.3 system up to and including Tahoe couldn't be cold started on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel had uVax support in it but the boot stuff did not. With 4.3-Reno that changed but... As others have noticed the cold start kit didn't create tapes suitable for a uVax. > prompt, from which you can execute the standalone images. "format" > seems to crash badly, but one probably doesn't need that on a Q-bus > machine :-). What I ended up doing was using my 2.11BSD 11/73 to create a bootable 4.3-Reno tape for the uVax - all the pieces are there, just need a system to 'dd' the files out with the right blocking factors, usw. Then the fun really began. The SPL "probing" logic in the kernel had a small problem when probing for MSCP controllers. As I recall (and this is going back quite a few years) some 3rd party adaptors ran at a different (lower) SPL than the probing logic expected - thus the autoconfig routines raised the SPL higher than the interrupt of the (Dilog I think) controller and the whole system hung. So, to install the system you HAD to use DEC controllers - ok, I had a RQDX3 and a couple RD53 drives present (the Dilog had a 319mb Miniscribe disk). BUT 4.3-Reno had a bug in the MSCP driver and would not recognize an honest to DEC RD53 drive! This was rapidly getting to be unfun. I think the workaround (it's been a __long__ time so memory is fuzzy) was to lie and call the drive an RA60 and then correct the problem later. But to get the lie thru to the kernel I had to use the standalone 'copy' program to copy a file (created on a PDP-11) to the first couple sectors of the uVax's RD53. Sheesh! > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) You're quite welcome. Actually 4.3-Reno served as inspiration and reminder of pain to avoid when it came time to implement 2.11BSD's disklabel capabilities. I swore I'd never go thru the pain of the kernel having labels but the standalone utilities lacking them 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the standalone programs still had compiled in partitions. > >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > >between Tahoe and Reno. The latter is really huge, it's a gap between True Can't be any version of Ultrix I ever used. At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD that DEC had corrupted with System V(anilla) bolted on contamination. Affectionately known as Buglix ;-) That was the same era that DEC had Ultrix-11 and that was a mucked up 2.9BSD. Of course you have to realize DEC had "Mr. Ken (Unix is Snake Oil) Olsen" around at the time 8-) UNIX is still around - but DEC? No, I don't like Compaq confusers thank you ;) 4.3-Reno was a transitional experiment that happened just as the CSRG and DEC had a serious falling out - and DEC support (Vaxen) vanished at that point. Any further work (4.4BSD) totally and completely ignored all DEC machines. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled Yep - you get NFS (which no 4BSD had prior to Reno). NFS doubles the size of the kernel though (at least) so there's a memory penalty to pay. It also brought many of the POSIX features (termios for example). > code. I'm willing to live with a bit more disk space usage, especially > for the promised speed benefits. It's not like KA630's or KA650's are speed > demons, and big cheap disks are readily available these days. Disk is cheap. Especially for older drives (but you run the risk that an old drive will die soon ;-(). Best to invest in a modern SCSI<->MSCP adaptor and use current drives (that's what I did for my 11/73 - adaptor is $$$ but the drives are cheap). Boy, you're not just whistling Dixie (apologies to those outside the US for which the reference is obscure). "Not a speed demon" doesn't begin to describe it. I went, believe it or not, thru the work of getting a newer GCC-2 (at the time I think 2.3.x was "new") to build and run on a uVax-II under 4.3-Reno. The biggest problem was that 4.3-Reno was neither "old" (V7ish) Unix or "POSIX" (just getting off the standard's writers desks). Getting GCC to build was a stop/go effort for several days but in the end the build would work: about 23 hours (or so)!! Sheesh - a 11/73 can *completely* regenerate itself from sources (all programs, manpages, etc) in about 28 hours. It was an interesting experiment but the uVax-II has sat here for 2+ years without being powered up. At one time the thought was to port 4.4BSD over but everyone that _could_ do the work lost interest - I've my PDP-11s and PPro systems to keep me busy so I haven't the time or inclination to do much with a KA630 system. For "slow" I have a PDP-11 (lots of fun, keeps you humble with the address space limits ;)). For 'fast' I have a couple dual cpu PPro systems (running BSD/OS) that can give a quad processor SUN Enterprise Server-4500 a run for their money. I have no need of a "slow" computer that attempts to run current day (bloated) software. I've toyed with the idea of swapping the innards of the 11/93 and the uVax. The KDJ11E would be a lot happier in a BA-123 than a BA-23;) But that's as far as it's gone (thinking about it). So - if anyone out there wants a uVax-II (9mb of memory but lots of disks and a 9-track tape drive to go with) drop by my place (shipping's out of the question). If you're more hardware capable than I perhaps we could swap the stuff into a BA23 (smaller enclosure to drive home, ...). Yikes and gadzooks - I was a bit verbose tonight (but my typing skills are much improved! ;-)). Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14865 for pups-liszt; Sun, 22 Nov 1998 20:31:53 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From m at mbsks.franken.de Sun Nov 22 19:28:43 1998 From: m at mbsks.franken.de (Matthias Bruestle) Date: Sun, 22 Nov 1998 10:28:43 +0100 (MET) Subject: 4.3-VAX distributions In-Reply-To: <199811220509.AAA16197@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 22, 98 00:09:52 am" Message-ID: Mahlzeit According to Michael Sokolov: > MicroVAXen, however, have tape boot capabilities built right into their > ROMs. Much easier for the installer, needless to say. Also needless to say, Does somebody know, where I can get a cheap TK50 (only the drive, the controller is still there) for my MicroVAXII? Mahlzeit endergone Zwiebeltuete -- insanity inside Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00215 for pups-liszt; Mon, 23 Nov 1998 09:30:32 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 03:42:32 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 12:42:32 -0500 Subject: 4.3-VAX distributions Message-ID: <199811221742.MAA16309@skybridge.scl.cwru.edu> Steven M. Schultz writes: > All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't > know there were any left :-) :-) I'm sure you know that domain names are case-insensitive. Also note that in the InterNIC records everything is all uppercase. As far as the mail user names go, they CAN be case-sensitive, but most OSes, even UNIX (Sendmail), try to be on the safe side and ignore the case in this context. > the base 4.3 system up to and including Tahoe couldn't be cold started > on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ > to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel > had uVax support in it but the boot stuff did not. > > With 4.3-Reno that changed but... As others have noticed the > cold start kit didn't create tapes suitable for a uVax. This change occurred in Tahoe, NOT in Reno. Trust me. If you don't, look at /usr/home/msokolov/43tahoe.cci/srcsys.tar.gz and see for yourself. > 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the > standalone programs still had compiled in partitions. The disk label support first appears in Tahoe. Again, if you don't believe me, look at /usr/home/msokolov/43tahoe.cci. > At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD [...] Ultrix v4.00, which I used to run on my main production VAX when my farm was on the net, has _ALL_ enhancements from 4.3BSD (including DNS and DBM passwd files) and most enhancements from Tahoe (including MX record support in Sendmail). Its disk label mechanism is rumored to be incompatible with Tahoe's, though (haven't had a chance to test this for myself). > [...] that DEC had corrupted > with System V(anilla) bolted on contamination. Here I agree wholeheartedly! But hey, just ignore all SysVile and DEC additions and pretend it's 4.3BSD! That's what I did. > 4.3-Reno was a transitional experiment that happened just as the CSRG > and DEC had a serious falling out - and DEC support (Vaxen) vanished > at that point. Any further work (4.4BSD) totally and completely > ignored all DEC machines. This pulled the thread that was holding everything together. Reno was the beginning of the destructive process that eventually and inevitably led to the disbanding of CSRG. Reno is the beginning of the end. One of the main reasons I don't do Reno. > Yep - you get NFS (which no 4BSD had prior to Reno). True. I will have to hack NFS into Quasijarus somehow at some point. This is not for Quasijarus1, though. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00216 for pups-liszt; Mon, 23 Nov 1998 09:30:34 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 03:42:03 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 12:42:03 -0500 Subject: 4.3-VAX distributions Message-ID: <199811221742.MAA16307@skybridge.scl.cwru.edu> Tim Shoppa writes: > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" > prompt, from which you can execute the standalone images. I know this. > "format" seems to crash badly [...] Of course! The documentation says clearly that it's for hp (780/750/8600 MASSBUS and clones) and up (RH-11 and clones) disks. > [...] but one probably doesn't need that on a Q-bus > machine :-). Has nothing to do with Q-bus, it's the distinction between SMDish disks and MSCP. But yes, for MSCP you are supposed to use the controller-specific diagnostics for formatting. For DEC ones it's a pain, but most (all?) third-party MSCP controllers have formatting utilities in their ROMs. > There are other ways to start it up. For example, using an already- > running OS (some other Unix or VMS) and copying the miniroot from tape > to the swap area of an unused disk. Here is my preferred way. It requires at least two disks. First boot from an Ultrix tape. That's the easiest thing in the world probably (assuming working hardware, of course, which I don't have right now). When you get a choice between quick installation, custom installation, and maintenance, choose the last one. This will drop you into the shell. Now you have Ultrix running in a RAM disk, you can do anything you want with your disks, and you can pull the Ultrix tape out and do anything you want with the tape drive. Then you put the BSD tape in, advance to the second file (the miniroot) with mt fsf, and dd it to partition c on one of the disks. Why partition c and not partition b? Why need two disks in the first place? Because I can bet that Ultrix and BSD will have different ideas about the default location of partition b. Then extract mdec/rdboot and mdec/bootra from the /usr tar image on the tape, cat them together, and dd them to the beginning of partition c (the miniroot as shipped doesn't have a bootblock). Then reboot from that disk. Now you have BSD running! Disklabel the other disk the way you want. This will put the bootblocks on it automatically. Then create the root and /usr filesystems on it and restore them from the tape. You are all set! True, this method imposes additional requirements (two disks and an Ultrix tape). It's also a little cumbersome (the part about the miniroot bootblocks). However, it has two advantages over the method with the tmscpboot tape. First, you can use the stock BSD tape, not a hacked one. Second, even in Reno tmscpboot supports only KA630 and not KA650. If you know VAX assembly language (I don't yet) and have a machine where you can rebuild it, you can fix this, but again you have extra requirements. Of course, the proper solution is to significantly redesign BSD's installation mechanism and make it a little more like Ultrix's. That's my plan for Quasijarus2, although Quasijarus1 will still be like Tahoe/Reno. > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) I agree wholeheartedly! A standalone disklabel program is part of my plan for Quasijarus2. Again, Quasijarus1 will still be like Tahoe/Reno. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled > code. The lifting of the filesystem limits is in Tahoe, not in Reno. When you talk about the speed of Reno's binaries, what are you comparing it to? I know for sure that there are no significant changes in the C compiler between plain 4.3, Tahoe, and Reno. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00292 for pups-liszt; Mon, 23 Nov 1998 09:40:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Mon Nov 23 08:41:31 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Mon, 23 Nov 1998 09:41:31 +1100 (EST) Subject: Minnie's new domain name In-Reply-To: <199811220300.WAA16161@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 21, 98 10:00:59 pm" Message-ID: <199811222241.JAA29811@henry.cs.adfa.oz.au> In article by Michael Sokolov: > Dear Warren, > > I see you started changing *.adfa.oz.au to *.adfa.edu.au. Should we all > start changing this in our notes, aliases, links, etc? And just out of > curiosity, what's changing? What did OZ.AU mean? Did it mean Australian > universities or what? Are you changing to EDU because that's what everyone > else uses? > > And while we are at it, what's ADFA? I thought the school's name is > UNSW, isn't it? Hi Michael, yes I should put some email out. History lesson following.... Before the Internet reached Australia, the universities had a UUCP-based mail/news system called ACSnet, where addresses were not bang-paths but @-based. The ACSnet software did the route lookups. Anyway, all ACSnet computers had a `domain' name ending in .oz, e.g kre at munnari.oz was a valid email address. When we finally got Internet-connected, our country suffix was .au. To make the transition easier, we just tacked it on to the end of the existing domain names, thus kre at munnari.oz became kre at munnari.oz.au More recently, to bring Australia in line with Internet conventions, .oz.au became .edu.au. Unfortunately, ADFA never bothered to do this switch until mid-way through this year. Over the summer break, I'll add some smarts to minnie's web server and other services to remind people to make the switch in their bookmarks, hotlinks etc. I'll keep it running indefinitely. ADFA is the Australian Defense Force Academy: it has military cadets as undergrads and civilians as postgrads. One half is run by the University of New South Wales and teaches normal civilian university stuff. I belong to this half. The other half is run by Defence, and teaches military history, how to shoot with guns etc. I'm not involved with that side at all :-) Cheers all, Warren P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00331 for pups-liszt; Mon, 23 Nov 1998 09:49:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Mon Nov 23 08:15:50 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sun, 22 Nov 1998 17:15:50 -0500 Subject: booting 4.3-reno without a tape drive Message-ID: <981122171550.2a200243@trailing-edge.com> Michael Sokolov wrote: > How soon will this happen? I'm all ready to go, but unfortunately >hardware problems are holding me back. I have solved the KA650 problem I >was having, but now I'm stuck because neither of the two TQK50 boards I >have works. (The drive SEEMS to work, though.) Thus the sooner I find a >working TQK50 board (or, alternatively, a working TK70/TQK70 pair), the >sooner will I make 4.3BSD-Quasijarus1. For a quick work-around to make a bootable 4.3 miniroot without a tape drive, Michael, you might consider the following (similar tricks will work on NetBSD distributions too): Ingredients: Microvax II Honest-to-goodness DEC disk or *fully* compatible 3rd-party disk. *Fully* compatible means that it must have the same MSCP media ID code and same number of tracks, sectors, and cylinders as a drive already hardwired into vaxuba/uda.c. These are the ones hardwired in: { MSCP_MKDRIVE2('R', 'A', 60), "ra60", ra60_sizes, 42, 4, 2382 }, { MSCP_MKDRIVE2('R', 'A', 70), "ra70", ra70_sizes, 33, 11, 1507 }, { MSCP_MKDRIVE2('R', 'A', 80), "ra80", ra80_sizes, 31, 14, 559 }, { MSCP_MKDRIVE2('R', 'A', 81), "ra81", ra81_sizes, 51, 14, 1248 }, { MSCP_MKDRIVE2('R', 'A', 82), "ra82", ra82_sizes, 57, 14, 1423 }, { MSCP_MKDRIVE2('R', 'C', 25), "rc25-removable", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE3('R', 'C', 'F', 25), "rc25-fixed", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE2('R', 'D', 52), "rd52", rd52_sizes, 18, 7, 480 }, { MSCP_MKDRIVE2('R', 'D', 53), "rd53", rd53_sizes, 18, 8, 963 }, { MSCP_MKDRIVE2('R', 'X', 50), "rx50", rx50_sizes, 10, 1, 80 }, Note that "rd54" is conspicuously missing, and I think the tabulated rd52/53 sizes are as appropriate on a RQDX2, *not* a RQDX3. Some other operating system to write the disk from (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, RT-11 and any PDP-11 CPU, etc.) The tape distribution of 43reno_vax from the PUPS archive. Specifically, you need these files: miniroot mdec/rdboot, from usr.tar mdec/bootra, from usr.tar etc/etc.tahoe/disktab, from src.tar Cooking directions: The miniroot wants to live in the swap ("b") partition of the drive. So your first task is to find the starting block number of the swap partition from the extracted "disktab". For example, for an RA81, the offset ("ob=") for an RA81 is 16422 blocks. So copy the miniroot onto the target drive starting at block 16422 (i.e. if you're under 2.11 BSD and you've partitioned the target drive, ra0, so that partition a covers the entire disk, do a "dd if=miniroot of=/dev/rra0a seek=16422 bs=512") In the "a" partition of the output drive you need a copy of "boot". The miniroot already has a filesystem with this in it, so the lazy thing to do is to just plop another copy of the miniroot, starting at block 0 on the output disk (i.e. "dd if=miniroot of=/dev/rra0a") You need the secondary bootstrap in blocks 1-15 of the target disk. Put this down with "dd if=bootra of=/dev/rra0a seek=1 bs=512" You need a block-0 boot block on the output disk. For a Microvax, this is rdboot. (I believe raboot is appropriate on a Unibus or BI-bus VAX). Lay this down with "dd if=rdboot of=/dev/rra0a" Now move the output disk to your Microvax II configuration, and boot: >>> b dua0/r5:1 2..1..0.. loading boot ra0: unlabeled Boot : ra(0,0,1)vmunix ra0: unlabeled 338756+108644+131004 start 0x238c 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 1998 PDT trent at kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot REAL MEM=16773120 und so weiter. Now, one obvious improvement to this would be to lay down a fake 4.3-ish disk label at the start of the output disk as well. This way the reliance on a fully-geometry-compatible disk might be avoided. I'll work on this in my Copious Free Time (TM). -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00512 for pups-liszt; Mon, 23 Nov 1998 10:14:17 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From norman at nose.cita.utoronto.ca Mon Nov 23 09:13:26 1998 From: norman at nose.cita.utoronto.ca (norman at nose.cita.utoronto.ca) Date: Sun, 22 Nov 1998 18:13:26 -0500 Subject: Minnie's new domain name Message-ID: <199811222314.SAA21900@chipmunk.cita.utoronto.ca> Re Warren's postscript: P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Perhaps it's time to dig up an old PDP-11? Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00626 for pups-liszt; Mon, 23 Nov 1998 10:31:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 09:43:37 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 18:43:37 -0500 Subject: booting 4.3-reno without a tape drive Message-ID: <199811222343.SAA16467@skybridge.scl.cwru.edu> Tim Shoppa writes: > For a quick work-around to make a bootable 4.3 miniroot without a > tape drive, Michael, you might consider the following (similar > tricks will work on NetBSD distributions too): > > Ingredients: > [...] > Some other operating system to write the disk from > (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, > RT-11 and any PDP-11 CPU, etc.) The last part is the problem. At this location I have only one DEC machine, and that's the KA650 I'm trying to get Ultrix on. The guy with the MV3400 (and the TK70/TQK70 pair inside it) is still out for the weekend, should hear something later this evening. If that falls through and no one helps me with a spare TQK50, I'll have to come up with another disk for this PC I'm typing this on, install FreeBSD on it, netboot NetBSD/vax, and use that to load Reno over the net onto another disk (the VAX has 5 of them). Much more painful, but still better than nothing. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00612 for pups-liszt; Mon, 23 Nov 1998 10:30:19 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 09:42:53 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 18:42:53 -0500 Subject: Minnie's new domain name Message-ID: <199811222342.SAA16465@skybridge.scl.cwru.edu> Warren Toomey writes: > Over the summer break [...] I was first thrown off by this (yesterday was officially the first snow day here in Cleveland), but then I remembered that Australia is in the southern hemisphere, so your summer is our winter, right? > I'll add some smarts to > minnie's web server and other services to remind people to make the > switch in their bookmarks, hotlinks etc. OK, will change the HostName line in my .ssh/config. I'm already using the new domain name when posting. > P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's > back now. I hate PC hardware. Then why do you use it? Why not run the PUPS/TUHS server on a VAX running 4.3BSD-Quasijarus (or 4.3BSD or 4.3BSD-Reno if you can't wait), or maybe a PDP-11 running 2.11BSD? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu P.S. Your Sendmail is still putting .oz.au in the outgoing mail headers. Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00720 for pups-liszt; Mon, 23 Nov 1998 10:40:08 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From sms at moe.2bsd.com Mon Nov 23 09:31:04 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 22 Nov 1998 15:31:04 -0800 (PST) Subject: 4.3-VAX distributions Message-ID: <199811222331.PAA18529@moe.2bsd.com> Hi - > The lifting of the filesystem limits is in Tahoe, not in Reno. When you > talk about the speed of Reno's binaries, what are you comparing it to? I > know for sure that there are no significant changes in the C compiler > between plain 4.3, Tahoe, and Reno. UH, not quite so. Unless 4.3 and Tahoe used GCC (which they did not). I'd say that there is a big difference between the 4.3 C compiler (pcc or whatever it started out as) and GCC. Tahoe, while adding support for the CCI line of computers (tried to get folks to buy one but they wouldn't go for it) did NOT use GCC (which wasn't out yet or if it was had just started making an appearance). Reno came with GCC though. The older pre-Reno compilers (being straight K&R) didn't handle prototypes - that's what you had "lint" for. Steven Schultz sms at Moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00729 for pups-liszt; Mon, 23 Nov 1998 10:41:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Mon Nov 23 02:32:07 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sun, 22 Nov 1998 11:32:07 -0500 Subject: What *was* the Tahoe? Message-ID: <981122113207.2a2001df@trailing-edge.com> I've been looking over the 4.3BSD Tahoe and Reno distributions available in the PUPS archive, and have (what I hope) is a rather simple question: What is the "Tahoe"? It seems - based on the documentation supplied in the Tahoe-specific installation docs - that "Tahoe" generically refers to any of several VERSAbus machines in the Berkeley EECS department. The CCI (Computer Consoles Inc.) Power 6/32 is frequently mentioned as the CPU, but the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 are also mentioned. Are these all the same architecture and instruction set, or are they different? How was the CPU implemented - on a chip? On a chipset? On a board? On multiple boards? The information regarding peripherals is a bit clearer. There appear to be many different supported VERSABus SMD-drive controllers and at least one supported VERSABus 9-track controller. Are any of the Berkeley EECS Tahoe machines still up and running? How many were there? How many were outside Berkeley? Tim. (shoppa at trailing-edge.com) Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA01013 for pups-liszt; Mon, 23 Nov 1998 12:01:32 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 11:14:04 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 20:14:04 -0500 Subject: What *was* the Tahoe? Message-ID: <199811230114.UAA16563@skybridge.scl.cwru.edu> Tim Shoppa writes: > I've been looking over the 4.3BSD Tahoe and Reno distributions > available in the PUPS archive, and have (what I hope) is a rather > simple question: > > What is the "Tahoe"? I have been pondering over the same question for a LONG time, and I would love to know the answer to it, as would Rick Copeland. The ex-CSRG folks are probably the only people on the planet who know the answer, and it looks like Marshall Kirk McKusick is the only one of them on this list. Kirk, do you have any insight? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA01021 for pups-liszt; Mon, 23 Nov 1998 12:01:58 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 11:14:33 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 20:14:33 -0500 Subject: 4.3-VAX distributions Message-ID: <199811230114.UAA16565@skybridge.scl.cwru.edu> Steven M. Schultz writes: > Reno came with GCC though. Wrong. Reno uses pcc for both VAX and Tahoe architectures, just like 4.2, 4.3, 4.3-Tahoe, and all other True UNIX(R) releases. gcc is included in the Reno distribution _as a compressed tarball_, and it's used only for the experimental and unsupported hp300 port, and that's only because there is no pcc support for it. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA01241 for pups-liszt; Mon, 23 Nov 1998 13:40:15 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From sms at moe.2bsd.com Mon Nov 23 12:26:14 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 22 Nov 1998 18:26:14 -0800 (PST) Subject: 4.3-VAX distributions Message-ID: <199811230226.SAA20820@moe.2bsd.com> Hi - > From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) > Wrong. Reno uses pcc for both VAX and Tahoe architectures, just like > 4.2, 4.3, 4.3-Tahoe, and all other True UNIX(R) releases. gcc is included Oops - I actually fired up the uVax-II (first time in almost 3 years) and typed 'gcc' and it told me 2.5.8 But as it turns out that was something I'd added later (with much work). GCC2 on a 9mb machine isn't a pretty sight so pcc is actually a "good thing" ;) Steven Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA02007 for pups-liszt; Mon, 23 Nov 1998 18:05:00 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mckusick at mckusick.com Mon Nov 23 16:05:13 1998 From: mckusick at mckusick.com (Kirk McKusick) Date: Sun, 22 Nov 1998 22:05:13 -0800 Subject: What *was* the Tahoe? In-Reply-To: Your message of "Sun, 22 Nov 1998 20:14:04 EST." <199811230114.UAA16563@skybridge.scl.cwru.edu> Message-ID: <199811230605.WAA03948@flamingo.McKusick.COM> Date: Sun, 22 Nov 1998 20:14:04 -0500 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) To: pups at minnie.cs.adfa.edu.au Subject: Re: What *was* the Tahoe? Sender: owner-pups at minnie.cs.adfa.oz.au Tim Shoppa writes: > I've been looking over the 4.3BSD Tahoe and Reno distributions > available in the PUPS archive, and have (what I hope) is a rather > simple question: > > What is the "Tahoe"? I have been pondering over the same question for a LONG time, and I would love to know the answer to it, as would Rick Copeland. The ex-CSRG folks are probably the only people on the planet who know the answer, and it looks like Marshall Kirk McKusick is the only one of them on this list. Kirk, do you have any insight? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Tahoe was the internal "code" name that Computer Consoles Inc used for their Power 6/32 processor. Many of their early changes to BSD were labelled: #ifdef tahoe to identify the 6/32 specific code. So, when we did the port we just called it Tahoe because its prime purpose was to add support for the CCI 6/32 machine. Kirk McKusick Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA02069 for pups-liszt; Mon, 23 Nov 1998 18:19:19 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From dave at fgh.geac.com.au Mon Nov 23 17:16:50 1998 From: dave at fgh.geac.com.au (Dave Horsfall) Date: Mon, 23 Nov 1998 18:16:50 +1100 (EST) Subject: What *was* the Tahoe? In-Reply-To: <199811230605.WAA03948@flamingo.McKusick.COM> Message-ID: On Sun, 22 Nov 1998, Kirk McKusick wrote: > Tahoe was the internal "code" name that Computer Consoles Inc used > for their Power 6/32 processor. Many of their early changes to BSD > were labelled: > #ifdef tahoe > to identify the 6/32 specific code. So, when we did the port we > just called it Tahoe because its prime purpose was to add support > for the CCI 6/32 machine. And, as I recall (I used to work for STC Australia who sold 'em) it had the instruction set of a Vax, but backwards, if you know what I mean... The CPU was five boards, something like integer card plus FPU card plus priority arbitrator card etc. -- Dave Horsfall VK2KFU dave at geac.com.au Ph: +61 2 9978-7493 Fx: +61 2 9978-7422 Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA03974 for pups-liszt; Tue, 24 Nov 1998 03:38:04 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Tue Nov 24 02:05:52 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Mon, 23 Nov 1998 11:05:52 -0500 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <981123110552.2a200243@trailing-edge.com> >Tahoe was the internal "code" name that Computer Consoles Inc used >for their Power 6/32 processor. That's useful. The Tahoe-specific documentation also mentions the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were these in any way compatible with the Tahoe, or just "other" ports? And where does "Reno" come from, while we're at it? Tim. (shoppa at trailing-edge.com) Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA04103 for pups-liszt; Tue, 24 Nov 1998 04:15:51 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rdkeys at seedlab1.cropsci.ncsu.edu Tue Nov 24 03:09:28 1998 From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys) Date: Mon, 23 Nov 1998 12:09:28 -0500 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811220509.AAA16197@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 22, 98 00:09:52 am" Message-ID: <199811231709.MAA09886@seedlab1.cropsci.ncsu.edu> > > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > > It's the most reasonable approach I can think of at the moment. > > That's close to what I'm doing. There are two differences, though. > First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > between Tahoe and Reno. The latter is really huge, it's a gap between True > UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be > building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus > KA650 support and shadow passwords from Reno and other improvements from > both later CSRG code and my own brain. SCCS will be the #1 tool in the > process. Speaking of crusades.....(:+}}.... I sometimes feel like the orphan child running BSD on the old IBM RT (I know, not a biggie vaxen iron, but that is what I have and the cap that I don). It is not too bad running 16M ram and a 20'' megapel color monitor, but the RISC processor is running around 12mhz on an ISA bus which is not very fast. I am curious, though, about the releases of BSD for the old RT. Few on the net know anything about them anymore, and docs are nil. I asked around IBM, and sort of drew dumb quizzled looks, as if it had vaporized long ago. I have uncovered three discrete distributions, one labelled IBM, and two non-labelled, but which were apparently out of IBM or related to IBM in some way, maybe after IBM dropped AOS, but I am not sure. The background of it all is a mystery. The first is a ``build 0'' thing called AOS or AOS/4.3, and it appears to be a somewhat vanilla 4.3BSD, or possibly might be as late as Tahoe. It has pcc and a Metaware C compiler, and is not very strange. Other than the compilers being somewhat broken and the time never correct, it runs well, and feels like 4.3. The second is a ``build 16'' and labelled Reno, but is running gcc and related things. My suspicion is that it is a 4.4, but I am not sure. It seems fairly plain and following the 4.4 docs pretty well. I don't think it is really Reno, but was named that by someone back in time for some developmental reason maybe having been started from a Reno tree, although I am not sure. The third is a ``build 433'' and labelled Lite, and seems to be somewhat straight 4.4 and somethat Lite (has two intermixed source trees), and is gigabyte in size, and rather strangely laid out. It may have been the last build for the RT. Unfortunately, original tapes and documents for these are long gone, and I have only been able to pick up bits and pieces here and there. I don't find mention of these ports anywhere in the usual docs, other than a slight hint that they existed at one time. Supposedly, bits are on a mystical CD that is reputed to exist, and I have heard of two actual CD's that may have survived. I have spent the last 6 months resurrecting the ports, and basically have a reliable 4.3 running, a running but somewhat broken ``Reno'' or whatever it is (of all things vi is only 99% operational because of terminal driver problems), and a broken but somewhat running ``4.4/4.4Lite'' or whatever that really is (it boots and barely stays up, but I have been working on making it stay up). Does anyone on the PUPS list remember what these things actually are, and what level they are actually at? My historical curiosity is getting the better of me, and like Michael, I tend to like the plain model-T spartan simplicity of a 4.3 style machine. There really is a large bloat between the 4.3 and 4.4 levels in my stuff, too. What is responsible for the differences in the bloat? I get binaries about half the size in 4.3 compared to the 4.4whatevers I have. Is that just a function of gcc and how it codes things or libraries? Anyway, it has been a most refreshing learning experience getting these things up and running again. Is there any interest on the list to archive the ports that I have? Warren? Out of curiosity, again, anyone else on the PUPS list running RT iron or am I the last holdout? The few RT folks that I am familiar with are all running AIX still, although they remember the BSDs. So much seems to have been lost, already, or most of the machines have become dumpster fodder. Any insights, history, or horror stories about the old RT BSD ports are most welcome. Thanks Bob Keys Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA04175 for pups-liszt; Tue, 24 Nov 1998 04:35:28 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 03:47:58 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 12:47:58 -0500 Subject: 4.3/4.4 IBM distributions (need history) Message-ID: <199811231747.MAA16896@skybridge.scl.cwru.edu> "User Rdkeys Robert D. Keys" writes: > I am curious, though, about the releases of BSD for the old RT. The University of California at Berkeley has never made any releases for IBM RT and nor will I, so there are no BSD releases for IBM RT. > There really is > a large bloat between the 4.3 and 4.4 levels in my stuff, too. What > is responsible for the differences in the bloat? I have heard jokes that CSRG got Microsoft to rewrite 90% of the code for them. Seriously, though, the bloat starts in Reno and really gets out of hand in 4.4. The sources are bloated just as much as the binaries, so I wouldn't blame it just on the compiler or the libraries. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04299 for pups-liszt; Tue, 24 Nov 1998 05:06:39 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From pat at transarc.com Tue Nov 24 04:05:13 1998 From: pat at transarc.com (Pat Barron) Date: Mon, 23 Nov 1998 13:05:13 -0500 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811231709.MAA09886@seedlab1.cropsci.ncsu.edu> Message-ID: I think there were some additional licensing restrictions on AOS (e.g., only available to educational institutions), so it might not be includable in the archive. I can probably track down folks in Palo Alto who worked AOS, and find out. As far as I know, there was never an "official" ACIS release beyond the 1988 4.3BSD release. I have actual distribution tapes around somewhere, and could probably make tape images available if it's determined that that's OK. --Pat. P.S. We just dumpster-ized about 6 or 8 RTs from our storage facility in the last couple of weeks - I had tried to give them away, but the person who was lined up to take them didn't move quite fast enough, and the person assigned to storage clean-up got tired of having them around ... :-( Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04329 for pups-liszt; Tue, 24 Nov 1998 05:08:33 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 04:20:43 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 13:20:43 -0500 Subject: What *was* the Tahoe? Message-ID: <199811231820.NAA16912@skybridge.scl.cwru.edu> Dave Horsfall writes: > And, as I recall (I used to work for STC Australia who sold 'em) it > had the instruction set of a Vax [...] Aha! I always suspected that the Tahoe architecture was somehow related to VAXen, I just didn't know how. Now we all know... > [...] but backwards, if you know what I > mean... I have noticed that the Tahoe architecture is big-endian (I use this to easily tell between VAX and Tahoe binaries and filesystem dumps). Is this what you mean? Or is there any more backwardness? > The CPU was five boards, something like integer card plus > FPU card plus priority arbitrator card etc. At least the FPU card was optional, since the Tahoe code in BSD has a emulator for it. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04317 for pups-liszt; Tue, 24 Nov 1998 05:07:56 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 04:20:15 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 13:20:15 -0500 Subject: 4.3-VAX distributions Message-ID: <199811231820.NAA16910@skybridge.scl.cwru.edu> Steven M. Schultz writes: > GCC2 on a 9mb machine isn't a pretty sight so pcc is actually a "good > thing" ;) It's _ALWAYS_ a good thing, because it's DIVINE (written by Bell Labs Gods themselves), while gcc and others are mere mortals. Actually, gcc is even worse than a mere mortal, since it's GNU. It comes directly from the Inferno. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04343 for pups-liszt; Tue, 24 Nov 1998 05:09:07 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 04:21:18 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 13:21:18 -0500 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <199811231821.NAA16914@skybridge.scl.cwru.edu> Tim Shoppa writes: > That's useful. The Tahoe-specific documentation also mentions > the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were > these in any way compatible with the Tahoe, or just "other" > ports? Well, they have to be compatible somehow, since the same BSD tape was used for all of them. Actually, there is much more to it. The Tahoe architecture was specifically designed for BSD. CCI first made a vendor release for their machines, kinda like SunOS and Ultrix, based on 4.2BSD. Then some time after the 4.3BSD release CSRG designed to integrate CCI's changes into the mainstream BSD tree. The result was named 4.3BSD-Tahoe. What's interesting is that 4.3BSD-Tahoe does not have any bootblocks for the Tahoe architecture, and the documentation often refers to the BSD kernels being loaded by the system ROM on Tahoe. As you can imagine, having the system ROM load your OS's kernels is one hell of a requirement, and the Harris and Unisys machines would have to REALLY compatible with the CCI for this to work. My guess would be that they were identical clones, just like the PC clones that run unmodified PC-DOS. > And where does "Reno" come from, while we're at it? If I'm not mistaken, there is a city somewhere on the west side of the U.S. called Tahoe/Reno. The BSD developers probably thought "OK, we already have Tahoe, let's have Reno too." Reno also probably stands for "renovation", although IMHO sawing the branch you are sitting on is pretty damn stupid and certainly doesn't qualify as "renovation". Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04486 for pups-liszt; Tue, 24 Nov 1998 05:49:13 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rdkeys at seedlab1.cropsci.ncsu.edu Tue Nov 24 04:42:50 1998 From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys) Date: Mon, 23 Nov 1998 13:42:50 -0500 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: from Pat Barron at "Nov 23, 98 01:05:13 pm" Message-ID: <199811231842.NAA10244@seedlab1.cropsci.ncsu.edu> > I think there were some additional licensing restrictions on AOS (e.g., > only available to educational institutions), so it might not be > includable in the archive. I can probably track down folks in Palo Alto > who worked AOS, and find out. It might be good to find out any info or history or whatever, if anyone still knows anything. If IBM does not particularly want it, it might be nice to add to the archives, as an educational one-up on Gates. > As far as I know, there was never an "official" ACIS release beyond the > 1988 4.3BSD release. I have actual distribution tapes around somewhere, > and could probably make tape images available if it's determined that > that's OK. Then what are the `Reno' and `Lite' builds that I have. I was assuming they were all related, or were there other ports done outside IBM? Now I am less clear on what it is I actually have...... > P.S. We just dumpster-ized about 6 or 8 RTs from our storage facility > in the last couple of weeks - I had tried to give them away, but > the person who was lined up to take them didn't move quite fast > enough, and the person assigned to storage clean-up got tired of > having them around ... :-( Darn! Always one step behind and two weeks late..... If there are any leftover AOS docs, or any leftover boards, particularly the external ESDI, SCSI, TAPE, or ethernet boards, or any leftover mice, that would be nice to locate. Also, a spare tape drive would not hurt. Dupster fodder......(:+{{..... Bob Keys Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA04591 for pups-liszt; Tue, 24 Nov 1998 06:17:42 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 24 05:27:21 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 23 Nov 1998 11:27:21 -0800 Subject: BSD Network Version 2 upload Message-ID: <3.0.32.19981123112715.0092ed20@pop.calweb.com> PUPS List, I have just put BSD Network Version 2 up on Minnie in the incoming directory. This is from a tape passed to me from Mr. Kirk McKusick. The file includes a readme and is zipped with WinZip version 6.22. Sincerely, Rick Copeland Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA04712 for pups-liszt; Tue, 24 Nov 1998 06:37:33 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From allisonp at world.std.com Tue Nov 24 05:37:17 1998 From: allisonp at world.std.com (Allison J Parent) Date: Mon, 23 Nov 1998 14:37:17 -0500 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <199811231937.AA08069@world.std.com> < U.S. called Tahoe/Reno. The BSD developers probably thought "OK, we alre < have Tahoe, let's have Reno too." Reno also probably stands for < "renovation", although IMHO sawing the branch you are sitting on is pret < damn stupid and certainly doesn't qualify as "renovation". Tahoe is Lake Tahoe California, Reno is in Nevada. The connection is the two of the cities are connected by I80, The same road you'd take to get from Boston to Berkeley. Lake Tahoe is a resort area in the mountains about 50miles (or so) west of Reno. In those cities sawing the branch your sitting on may well be a paying bet or a reason to party. Allison Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA04837 for pups-liszt; Tue, 24 Nov 1998 07:25:36 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 24 06:34:05 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 23 Nov 1998 12:34:05 -0800 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <3.0.32.19981123123403.0091b220@pop.calweb.com> At 02:37 PM 11/23/98 -0500, Allison J Parent wrote: >< U.S. called Tahoe/Reno. The BSD developers probably thought "OK, we alre >< have Tahoe, let's have Reno too." Reno also probably stands for >< "renovation", although IMHO sawing the branch you are sitting on is pret >< damn stupid and certainly doesn't qualify as "renovation". > >Tahoe is Lake Tahoe California, Reno is in Nevada. The connection is >the two of the cities are connected by I80, The same road you'd take to >get from Boston to Berkeley. Lake Tahoe is a resort area in the mountains >about 50miles (or so) west of Reno. > >In those cities sawing the branch your sitting on may well be a paying >bet or a reason to party. > >Allison Well since I live so close to Lake Tahoe and Reno (Sacramento is half way between Tahoe and Berkeley) I have got to get my two cents in here. My guess is that Berkeley is well known as a pro party University and Reno and Tahoe are the main party spots on the west cost! Sounds right to me! Rick Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA04939 for pups-liszt; Tue, 24 Nov 1998 08:04:14 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 07:16:41 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 16:16:41 -0500 Subject: BSD Network Version 2 upload Message-ID: <199811232116.QAA17086@skybridge.scl.cwru.edu> Rick Copeland writes: > I have just put BSD Network Version 2 up on Minnie in the incoming > directory. Warren, I think this one should go into minnie's anonymous FTP area, since it does not require a UNIX license and was specifically designed to be publicly distributable. I didn't do any repacking on it in my home directory, since it's just one big tarball. I've done a tar tvf on the tarball, though, and the listing produced is in /usr/home/msokolov/NET2.lst on minnie. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA05240 for pups-liszt; Tue, 24 Nov 1998 09:16:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 08:17:39 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 09:17:39 +1100 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811231709.MAA09886@seedlab1.cropsci.ncsu.edu> from "User Rdkeys Robert D. Keys" at "Nov 23, 98 12:09:28 pm" Message-ID: <199811232217.JAA03246@henry.cs.adfa.oz.au> In article by User Rdkeys Robert D. Keys: > I am curious, though, about the releases of BSD for the old RT. > I have uncovered three discrete distributions, one labelled IBM, > and two non-labelled, but which were apparently out of IBM or related > to IBM in some way, maybe after IBM dropped AOS, but I am not sure. > The background of it all is a mystery. > > Is there any interest on the list to archive the ports that I have? > Warren? I tell you what, Bob. I'll mirror whatever you've got :-) But you'll have to organise it and write the READMEs! Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA05265 for pups-liszt; Tue, 24 Nov 1998 09:18:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 08:19:29 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 09:19:29 +1100 (EST) Subject: 4BSD bloat In-Reply-To: <199811231747.MAA16896@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 23, 98 12:47:58 pm" Message-ID: <199811232219.JAA03263@henry.cs.adfa.oz.au> In article by Michael Sokolov: >I have heard jokes that CSRG got Microsoft to rewrite 90% of the code for them. >Seriously, though, the bloat starts in Reno and really gets out of hand in 4.4. >The sources are bloated just as much as the binaries, so I wouldn't blame it >just on the compiler or the libraries. I can hear Steven Schultz say that the address space limitations of a 16-bit architecture help to minimise software bloat :-) Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA05725 for pups-liszt; Tue, 24 Nov 1998 10:44:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 24 09:53:48 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 23 Nov 1998 15:53:48 -0800 Subject: Upload BSD4.3 Rev. 2, Foreign Master Message-ID: <3.0.32.19981123155338.00935c40@pop.calweb.com> Dear PUPS list, I have up loaded to Minnie the "BSD4.3 Revision 2 for VAX, Foreign Master" passed to me by Mr. Kirk McKusick. This tape image is zipped with WinZip 6.22 and includes a readme file. Sincerely, Rick Copeland Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA06184 for pups-liszt; Tue, 24 Nov 1998 12:03:08 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 11:04:26 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 12:04:26 +1100 (EST) Subject: Upload BSD4.3 Rev. 2, Foreign Master In-Reply-To: <3.0.32.19981123155338.00935c40@pop.calweb.com> from Rick Copeland at "Nov 23, 98 03:53:48 pm" Message-ID: <199811240104.MAA03819@henry.cs.adfa.oz.au> In article by Rick Copeland: > Dear PUPS list, > > I have up loaded to Minnie the "BSD4.3 Revision 2 for VAX, Foreign Master" > passed to me by Kirk McKusick. > Rick Copeland It's now available in Distributions/4bsd/43rev2 in the PUPS Archive. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA06315 for pups-liszt; Tue, 24 Nov 1998 12:21:31 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From simul8 at simul8.demon.co.uk Tue Nov 24 11:15:24 1998 From: simul8 at simul8.demon.co.uk (James Lothian) Date: Tue, 24 Nov 1998 01:15:24 -0000 Subject: 4.3-VAX distributions Message-ID: <01BE1748.F7E9EE60@SONAR> Just thought I'd throw my oar in: my 11/750 is currently running a version of 4.3 taken off a set of tapes I saved from being thrown out by a Uni department I used to work for. The labels on the tapes say: Ultrix 4.3+NFS Wisconsin UNIX 1/15/87 And another label says: * The contents of this tape are distributed to UNIX/32V, System 3 or System 5, and SUN 3.0 NFS licencees only, subject to your software agreement with AT&T (Western Electric), your license agreement with the Regents of the University of California, and your license agreement with SUN Microsystems. * The University of Wisconsin - Madison Computer System Laboratory assumes no responsibility for unauthorized use of these contents by non-licensed entities. RCS strings seem to indicate that the code was maintained by someone called Tad Lebeck. As far as I can tell, it's mainly a fairly stock early 4.3 with no disk-labels, with all the sun rpc/yp/nfs stuff grafted on and a whole lot of bugs that I've had no end of fun fixing. Does anybody know anything about the history of this version? In particular, does it bear any real relation to Ultrix, or is the tape just mis-labelled? If anybody else out there is running this thing and wonders why ptrace(2) causes such mayhem, or why portmap crashes when they try to run YP, I'd be happy to supply patches.... James Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA06440 for pups-liszt; Tue, 24 Nov 1998 12:49:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From eekg at ix.netcom.com Tue Nov 24 11:40:51 1998 From: eekg at ix.netcom.com (Eric Edwards) Date: Mon, 23 Nov 1998 20:40:51 -0500 Subject: What *was* the Tahoe? Message-ID: <002e01be174b$8a9ec6c0$2dd1b7c7@#eekg.ix.netcom.com> The Power 6/32 Tahoe was a product of Computer Consoles Inc. (CCI). The internal codename was "Tahoe", as all the CCI processors were named after lakes in the US (others I can remember were Erie and Huron). It was originally intended to compete with the VAX-11/780 - depending on the benchmark it was 5 to 10 times faster than the VAX and much smaller and cheaper. The base processor consisted of 5 boards - implemented with AMD 2900 series bit slice processors, PLAs and 74F series parts. Surprisingly the bit-slice processors were used in the MMU - the actual ALU was 74F181s. It was a big endian machine that was sort of a cross between a VAX and a Motorola 68K. As mentioned elsewhere, it is rumored that if you swap the nibbles in the instruction bytes they end up the same as the VAX... I think it also had some odd features: the cache was on the processor side of the mmu -- so it was indexed by virtual address and instructions were cached in microcode form. As guessed from the lack of boot blocks, there was another board in the system -- the Console Processor (CP). It was a 68000 based Versabus single board computer. The boot monitor understood BSD filesystems on both tape and disk. It basically loaded the microcode into the CPU, loaded the boot image (/boot?) into memory, and then started the main CPU. CCI ported 4.2BSD to run on the Tahoe and the changes were rolled into the 4.3-Tahoe version. They also ran System V (including a dual processor version) and CCI's own fault-tolerant Unix - Perpos. I think the last of the Berkeley Tahoe machines ended up at Rochester Institute of Technology's Computer Science House (http://www.csh.rit.edu). Some guys up there were attempting to do some work with 4.4BSD and the Tahoe. I can probably dig up more information if anyone needs it... -----Original Message----- From: SHOPPA at trailing-edge.com To: PUPS at MINNIE.CS.ADFA.EDU.AU Date: Sunday, November 22, 1998 6:47 PM Subject: What *was* the Tahoe? > What is the "Tahoe"? >Tim. (shoppa at trailing-edge.com) > Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06491 for pups-liszt; Tue, 24 Nov 1998 13:04:41 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 12:17:16 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 21:17:16 -0500 Subject: BSD Network Version 2 upload Message-ID: <199811240217.VAA17227@skybridge.scl.cwru.edu> J. Joseph Max Katz writes: > Does Net/2 produce a completely working binary system? No. It contains only the sources, and if you try to build it, you'll get stuck immediately because about half of the source files were simply deleted. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06512 for pups-liszt; Tue, 24 Nov 1998 13:05:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 12:18:03 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 21:18:03 -0500 Subject: BSD Network Version 2 upload Message-ID: <199811240218.VAA17230@skybridge.scl.cwru.edu> Warren Toomey writes: > I'll check with SCO That's a good idea. Please let us know what they say. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06533 for pups-liszt; Tue, 24 Nov 1998 13:07:12 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 12:19:49 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 21:19:49 -0500 Subject: 4.3-VAX distributions Message-ID: <199811240219.VAA17236@skybridge.scl.cwru.edu> When I wrote in a previous message: > Actually, gcc is even worse than a mere mortal, > since it's GNU. It comes directly from the Inferno. I didn't know that Lucent has a product named Inferno, as some people have pointed out to me. In any case, I meant the actual Inferno, also known as Hell, i.e., the fifth dimension of the Universe inhabited and ruled by Satan, not the Lucent product. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA06745 for pups-liszt; Tue, 24 Nov 1998 14:27:45 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 13:27:57 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 14:27:57 +1100 (EST) Subject: BSD Network Version 2 upload In-Reply-To: <199811240218.VAA17230@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 23, 98 09:18:03 pm" Message-ID: <199811240327.OAA04039@henry.cs.adfa.oz.au> In article by Michael Sokolov: > Warren Toomey writes: > > I'll check with SCO [what their stance is on the Net/2 tape] > > That's a good idea. Please let us know what they say. Dion at SCO doesn't even know what Net/2 is. I've sent him some details. He wants to know exactly what the settlement was between USL and UCB in regards to the Net/2 tape. I don't have the exact particulars here (just a News article from Keith Bostic), so I've asked Kirk if he could give me the exact ruling. I'll pass on any words from SCO to the mailing list as I receive them. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA06960 for pups-liszt; Tue, 24 Nov 1998 14:50:10 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From dave at fgh.geac.com.au Tue Nov 24 13:47:41 1998 From: dave at fgh.geac.com.au (Dave Horsfall) Date: Tue, 24 Nov 1998 14:47:41 +1100 (EST) Subject: What *was* the Tahoe? In-Reply-To: <199811231820.NAA16912@skybridge.scl.cwru.edu> Message-ID: On Mon, 23 Nov 1998, Michael Sokolov wrote: > I have noticed that the Tahoe architecture is big-endian (I use this to > easily tell between VAX and Tahoe binaries and filesystem dumps). Is this > what you mean? Or is there any more backwardness? It's basically a big-endian Vax. When disassembling code, I never knew whether to wear my Vax hat or my Motorola hat :-) I believe that the Harris 7, the ICL Clan etc were just badge-engineered. Nice machine, and no relation to the CCI 5/32 and the 5/32X (680x0) other than the manufacturer. > At least the FPU card was optional, since the Tahoe code in BSD has a > emulator for it. And the Ethernet card cost AU$10,000 (ca. 80s). It had a STUPID ribbon cable connector to the D15 socket; misalign it by one pin (easy to do), since there was no key; you had to count 13 pins down) and you blew the card. I did, once... -- Dave Horsfall VK2KFU dave at geac.com.au Ph: +61 2 9978-7493 Fx: +61 2 9978-7422 Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA09053 for pups-liszt; Tue, 24 Nov 1998 17:50:38 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 17:03:05 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Tue, 24 Nov 1998 02:03:05 -0500 Subject: 4.3BSD Rev 2 Foreign Message-ID: <199811240703.CAA17330@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have analyzed Rick's 4.3BSD Rev 2 Foreign images in Distributions/4bsd/43rev2 and converted them into the standard BSD release format used by me as the maintainer of 4.3BSD. I didn't change the contents of any files, I just gave the directory and all files their systematic names (being systematic and punctual in packaging and naming is essential to maintaining an archive of many different versions of software). I also uncompressed and recompressed all files so that the names stored inside the gzip headers are correct. Finally, I have created a tar tvf listing for every tarball. The result is in /usr/home/msokolov/43rev2_f. Warren, please put this into the main PUPS archive. Note, though, that usr.tar (file 4) is cut short. I have indicated this in the BROKEN.TXT file. Also this is a "foreign" tape, meaning that it has a slightly crippled crypt(3) and missing crypt(1). Given that this tape is both a little broken and "foreign", CWRU's 4.3BSD tape images in /usr/home/msokolov/43.vax may be a better choice for some people. They have normal crypt(3) and crypt(1) and have absolutely no defects. (That's the advantage of 1600 BPI over 6250 BPI. Rick seems to be having a really hard time reading 6250 BPI 4.3 and 4.3-Tahoe tapes, while CWRU's 1600 BPI 4.3BSD tapes read fine on the first attempt.) Rick's ones are Rev 2, though, and CWRU's are not. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA10697 for pups-liszt; Tue, 24 Nov 1998 21:46:42 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From A.F.R.Bain at dpmms.cam.ac.uk Tue Nov 24 20:46:15 1998 From: A.F.R.Bain at dpmms.cam.ac.uk (Alan F R Bain) Date: Tue, 24 Nov 1998 10:46:15 +0000 Subject: Version 7 for the PERQ Message-ID: A question which I have been meaning to ask for a while and which I was reminded of by the discussion of the AMD 2900 bit slice processors was a version of AT&T V7 unix for the ICL PERQ computer. This was so similar to the original that the manual was an original AT&T one with instructions on which pages to pull out and throw away and some new ones to insert. [basically all PDP11 hardware specific ones go; and there are some new bits such as chatter as simple serial comms program]. I have several binary only distributions of this -- it was called PNX. What I'd be really interested to know is how it evolved from V7; in particular the new version of `m40.s'. In particular it seems to run on top of a rather weird instruction set which isn't very like that of the PDP11 (which would have seemed like an obvious choice at first sight for a soft-microcodeable machine). The use of as and cc with options to write out assembler is considered as `not a user option' in the manual; although it still works. I have to say that in general the port seems quite bad and in need of lots of work to make it correctly functional. However it's nice to have V7 readily available on a graphics workstation with 1Mb RAM and 768x1024 display :-) I'd be very interested to find out more of the source to PNX or especially the microcode Alan Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA12215 for pups-liszt; Wed, 25 Nov 1998 04:53:20 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mckusick at mckusick.com Wed Nov 25 02:19:01 1998 From: mckusick at mckusick.com (Kirk McKusick) Date: Tue, 24 Nov 1998 08:19:01 -0800 Subject: Reno (was Re: What *was* the Tahoe?) In-Reply-To: Your message of "Mon, 23 Nov 1998 11:05:52 EST." <981123110552.2a200243@trailing-edge.com> Message-ID: <199811241619.IAA07519@flamingo.McKusick.COM> From: SHOPPA at trailing-edge.com Date: Mon, 23 Nov 1998 11:05:52 -0500 To: PUPS at minnie.cs.adfa.oz.au Subject: Reno (was Re: What *was* the Tahoe?) Sender: owner-pups at minnie.cs.adfa.oz.au >Tahoe was the internal "code" name that Computer Consoles Inc used >for their Power 6/32 processor. That's useful. The Tahoe-specific documentation also mentions the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were these in any way compatible with the Tahoe, or just "other" ports? And where does "Reno" come from, while we're at it? Tim. (shoppa at trailing-edge.com) The 4.3-Reno distribution was named after the city of that name in Nevada. We picked that name because the 4.3-Reno distribution was an interim release on the way to 4.4BSD and hence was not as fully polished or tested as our production releases. The idea was to remind recipients that it was more of a "gamble" to run Reno than our production releases. Kirk McKusick Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13346 for pups-liszt; Wed, 25 Nov 1998 10:03:30 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 09:05:02 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 10:05:02 +1100 (EST) Subject: Net2 Status: likely outcome Message-ID: <199811242305.KAA05334@henry.cs.adfa.oz.au> I haven't heard back from SCO re the Net/2 status, but given that USL was sold to Novell & then to SCO, and they have copies of all the legal documents, I'm sure that SCO will quickly find out the details of the USL vs UCB settlement. Kirk has told me that the settlement explicitly stated that a set of files from Net/2 was not to be distributed, and that this set of files was not to be revealed: this was done to prevent a subset of Net/2 from being freely redistributed. CSRG made changes to about 70 files and deleted three files outright. Kirk is legally unable to reveal the list of affected files in Net/2. I've just had a poke around the SCCS files on CD#4 on the CSRG CD set. Several of the SCCS comments for the kernel files have the word USL in them: add USL's copyright notice changes for 4.4BSD-Lite requested by USL There's also a list of binary-only files in BSD/386 1.1 at http://www.bsdi.com/info/lawsuit/940208.update I assume, therefore, that it wouldn't be too hard to find out the set of files in Net/2 affected by the settlement. Therefore, once SCO reads through the legal documents (which they now own), I'd be pretty sure that they will still treat Net/2 as contaminated, and people will need a 32V license in some form in order to legally acquire a copy of the Net/2 tape. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13502 for pups-liszt; Wed, 25 Nov 1998 10:54:36 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 09:56:09 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 10:56:09 +1100 (EST) Subject: Also: PUPS digest mail list Message-ID: <199811242356.KAA05513@henry.cs.adfa.oz.au> I should also say that there's a digest form of the PUPS/TUHS mail list which comes out twice weekly. If you'd rather be on that list, please send me some email. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA13797 for pups-liszt; Wed, 25 Nov 1998 11:58:43 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 11:00:17 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 12:00:17 +1100 (EST) Subject: Net/2: still at ftp.uu.net Message-ID: <199811250100.MAA05738@henry.cs.adfa.oz.au> Just FYI, net/2 afficionados might care to look around in ftp://ftp.uu.net/systems/unix/bsd-sources I assume that they are in a legally dubious situation. Warren From wkt at henry.cs.adfa.oz.au Wed Nov 25 11:23:26 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 12:23:26 +1100 (EST) Subject: Net/2: still at ftp.uu.net In-Reply-To: from "J. Joseph Max Katz" at "Nov 24, 98 05:17:48 pm" Message-ID: <199811250123.MAA06173@henry.cs.adfa.oz.au> In article by J. Joseph Max Katz: > They may have the sources rm'd that aren't supposed to be there. As far as I can tell (at a quick glance), the distribution is intact. I'm just comparing cksums between the Net/2 on the CSRG CD#2 and from the ftp site. I'm only doing sys/kern and sys/ufs. Absolutely no difference. diff on all file pairs gives no output. cksum gives the same checksums for each file pair (CD vs ftp). Hmm..... Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA14564 for pups-liszt; Wed, 25 Nov 1998 13:24:57 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 12:20:41 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 13:20:41 +1100 (EST) Subject: Net/2: still at ftp.uu.net In-Reply-To: <01BE1817.1E6F2EF0@SONAR> from James Lothian at "Nov 25, 98 01:58:33 am" Message-ID: <199811250220.NAA06820@henry.cs.adfa.oz.au> In article by James Lothian: > In the UK, sunsite.doc.ic.ac.uk has a directory > /computing/systems/unix/4.3bsd-net2, which > seems to be all the unencumbered bits of net/2. > James It appears that several files from sys/kern and sys/ufs have been removed. All files still in these directories are intact. I haven't examined any other directories. They're in a safer legal position. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA15323 for pups-liszt; Wed, 25 Nov 1998 17:22:44 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) From mxs46 at k2.scl.cwru.edu Wed Nov 25 16:35:15 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 25 Nov 1998 01:35:15 -0500 Subject: Net2 Status: likely outcome Message-ID: <199811250635.BAA17893@skybridge.scl.cwru.edu> Warren Toomey writes: > Therefore, once SCO reads through the legal documents (which they now > own), I'd be pretty sure that they will still treat Net/2 as > contaminated, and people will need a 32V license in some form in order to > legally acquire a copy of the Net/2 tape. Then until/unless Warren tells me otherwise, I'll keep Net/2 together with the real 4BSD distributions in Distributions/4bsd/net2, readable by the members of the pupsarc group only. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA15311 for pups-liszt; Wed, 25 Nov 1998 17:22:17 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) From mxs46 at k2.scl.cwru.edu Wed Nov 25 16:34:48 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 25 Nov 1998 01:34:48 -0500 Subject: 4BSD distributions Message-ID: <199811250634.BAA17891@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, All 4BSD distributions formerly in my home directory on minnie are now in the Distributions/4bsd directory. This directory is now owned by me, and from now on I will be maintaining PUPS's 4BSD collection. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA17141 for pups-liszt; Thu, 26 Nov 1998 04:48:09 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) From mxs46 at k2.scl.cwru.edu Thu Nov 26 04:00:30 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 25 Nov 1998 13:00:30 -0500 Subject: What *was* the Tahoe? Message-ID: <199811251800.NAA18075@skybridge.scl.cwru.edu> Wortner, Frank (RSCH) writes to me: > P.S. You might want to forward this to the PUPS list, since I'm no longer > an active member (emal address changes, etc.) Doing so. Forwarded message: >From Frank_Wortner at ml.com Wed Nov 25 11:31 EST 1998 Return-Path: From Frank_Wortner at ml.com Thu Nov 26 02:27:07 1998 From: Frank_Wortner at ml.com (Wortner, Frank (RSCH)) Date: Wed, 25 Nov 1998 11:27:07 -0500 Subject: What *was* the Tahoe? Message-ID: This one I know the answer to. "Tahoe" was the internal name for a computer called the "Compter Consoles Inc. 632." (At least that's what I recall." The machine itself was a light grey cube about the size of a VAX 750 CPU. The cube housed the CPU, the disk drives (Fujitsu "Super Eagles" I think) and an auto-loading tape drive. If I recall correctly, the manufacturer was located in Rochester, New York, USA. I used to sys admin one of these beasts -- a *long* time ago. They were pretty durable: mine not only survived an air condioner failure during which the temperature rose to more than 100 degrees Fahrenheit, it actually kept on working without a break for several hours! It was a good box, an attempt at a "VAX-killer," but it never really managed to grab a substantial base from DEC's boxes. Frank P.S. You might want to forward this to the PUPS list, since I'm no longer an active member (emal address changes, etc.) From wkt at henry.cs.adfa.oz.au Thu Nov 26 11:54:34 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Thu, 26 Nov 1998 12:54:34 +1100 (EST) Subject: Over 100 Ancient UNIX Licenses Message-ID: <199811260154.MAA08304@henry.cs.adfa.oz.au> All, I've just received another 5 SCO Ancient UNIX license details in the mail, bringing the total purchased from SCO to 101. I think that's pretty impressive. Just thought you'd like to know. Cheers all, Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA22073 for pups-liszt; Fri, 27 Nov 1998 03:52:43 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From SHOPPA at trailing-edge.com Fri Nov 27 02:50:34 1998 From: SHOPPA at trailing-edge.com (Tim Shoppa) Date: Thu, 26 Nov 1998 11:50:34 -0500 Subject: Pro/Venix and Y2K Message-ID: <981126115034.2a2004dc@trailing-edge.com> The following exchange recently took place on comp.sys.dec.micro/ vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix is based on 2.9BSD - does anyone know more details about its heritage? Donato B. Masaoy III wrote: > > Came into a Pro 380 and loaded Venix as a means of tyring out Unix. > Noticed that at 2000 it sets itself back to 1970. Is there fix for this? > Should I bother? The PRO 380 Time-Of-Year clock has two modes: 1. BCD mode, where the year is stored in two decimal digits. 2. Binary mode, where the year is stored as at least 7 bits (more likely 8 bits - it's been a couple of months since the changes were implemented the fix in RT-11's PI.SYS, PIX.SYS, and SETUP.SAV to make it Y2K compliant.) When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the clock keeps accurately ticking. Venix evidently chokes on this and doesn't interpret "00" as "2000". As Unix is incapable of representing times internally outside the range 1970-2038, the obvious fix is to interpret BCD years in the range 70-99 as being in the 1900's, and the BCD years in the range 00-38 as in the 2000's. This is, for example, how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. Of course, finding the sources to Pro 380 Venix to implement the changes may be difficult. The PUPS archive has a version of 2.9BSD patches for the Pro, and if you're lucky Venix may be close enough that you can use the Pro-specific clock sources to patch your kernel binary. In the 2.9BSD Pro patches, the clock code is in "/sys-dev/prostuff.c", and begins: /* These two fuctions handle the pro 300's clock * This code is defunct at the end of the century. * Will Unix still be here then?? */ -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA22435 for pups-liszt; Fri, 27 Nov 1998 05:49:47 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From djenner at halcyon.com Fri Nov 27 04:48:45 1998 From: djenner at halcyon.com (David C. Jenner) Date: Thu, 26 Nov 1998 10:48:45 -0800 Subject: Pro/Venix and Y2K References: <981126115034.2a2004dc@trailing-edge.com> Message-ID: <365DA28D.5C541C8C@halcyon.com> There probably isn't much BSD lineage in Version 1 of Venix, but there is some in Version 2. Probably mostly in the form of the usual add-ons like VI. There's some confusion about this (at least in my mind), so any authoritative info would be interesting. First of all there's: "Venix/Pro" from Venturecom, which is definitely of AT&T lineage, probably V7/SysIII for V1 of Venix/Pro, and perhaps a bit of BSD stuff mixed in for V2 of Venix/Pro. This is what you find at Internet archives. Then there's: "Pro/Venix" from DEC, which is a repackaging of Venix/Pro. Again, there are Versions 1 and 2 of this. I have V1 and docs for V2, but no disks for V2. I'd really like to find a copy of the distribution of DEC Pro/Venix V2, if it's legal (and having the Ancient Unix license would seem to make it OK for at least the AT&T side). For Pro/Venix, V2, the manual entry for "clock(7) - time-of-day clock" is: /dev/clock refers to a time-of-day, battery-backed-up clock. This device node is provided primarily for the benefit of the date com- mand, which will read from it given the -l flag (usually done on system start-up), and write to it if a new date is set. ... struct clkbuf { int clk_sec; /* second (0-59) */ int clk_min; /* minute (0-59) */ int clk_hour; /* hour (0-23) */ int clk_mday; /* day of month (1-31) */ int clk_mon; /* month (0-11) */ int clk_year; /* year (00-99) */ int clk_wday; /* day of the week (Sunday = 0) */ int clk_yday; /* day of the year (0-365) */ int clk_dst; /* non-zero if daylight savings applies */ }; So, it looks bad at least from the internal representation of the year. Since I don't have this version, I can't comment on exactly what happens. Dave Tim Shoppa wrote: > > The following exchange recently took place on comp.sys.dec.micro/ > vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix > is based on 2.9BSD - does anyone know more details about its heritage? > > Donato B. Masaoy III wrote: > > > > Came into a Pro 380 and loaded Venix as a means of tyring out Unix. > > Noticed that at 2000 it sets itself back to 1970. Is there fix for this? > > Should I bother? > > The PRO 380 Time-Of-Year clock has two modes: > > 1. BCD mode, where the year is stored in two decimal digits. > 2. Binary mode, where the year is stored as at least 7 bits (more > likely 8 bits - it's been a couple of months since the changes > were implemented the fix in RT-11's PI.SYS, PIX.SYS, and > SETUP.SAV to make it Y2K compliant.) > > When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the > clock keeps accurately ticking. Venix evidently chokes on this > and doesn't interpret "00" as "2000". > > As Unix is incapable of representing times internally outside > the range 1970-2038, the obvious fix is to interpret BCD years > in the range 70-99 as being in the 1900's, and the BCD years > in the range 00-38 as in the 2000's. This is, for example, > how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. > > Of course, finding the sources to Pro 380 Venix to implement > the changes may be difficult. The PUPS archive has a version of 2.9BSD > patches for the Pro, and if you're lucky Venix may be close > enough that you can use the Pro-specific clock sources to patch > your kernel binary. In the 2.9BSD Pro patches, the clock > code is in "/sys-dev/prostuff.c", and begins: > > /* These two fuctions handle the pro 300's clock > * This code is defunct at the end of the century. > * Will Unix still be here then?? > */ > > -- > Tim Shoppa Email: shoppa at trailing-edge.com > Trailing Edge Technology WWW: http://www.trailing-edge.com/ > 7328 Bradley Blvd Voice: 301-767-5917 > Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22497 for pups-liszt; Fri, 27 Nov 1998 06:05:10 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From kcwellsc at math.uwaterloo.ca Fri Nov 27 05:04:36 1998 From: kcwellsc at math.uwaterloo.ca (Ken Wellsch) Date: Thu, 26 Nov 1998 14:04:36 -0500 (EST) Subject: Pro/Venix and Y2K In-Reply-To: <981126115034.2a2004dc@trailing-edge.com> from "Tim Shoppa" at Nov 26, 98 11:50:34 am Message-ID: <199811261904.OAA22036@math.uwaterloo.ca> Hi Tim, | The following exchange recently took place on comp.sys.dec.micro/ | vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix | is based on 2.9BSD - does anyone know more details about its heritage? There are several folks with vastly better knowledge on this than I, but should they not speak up, I'll mumble on what little I know. Venix is an outgrowth of V6 UNIX I believe - from my fadding memory of the little I played with it, the file system is definitely V6 based (with the notion of "huge" files, i.e. the index pointers would switch from direct to indirect, while I believe V7 took a much better approach). The 2BSD branch I believe took a much later fork, V7 or later? It also played a more central role than Venix I expect, contributing a goodly amount of later PDP-11/UNIX based things that others borrowed (e.g. Ultrix 3 from DEC took csh and vi among other goodies). | As Unix is incapable of representing times internally outside | the range 1970-2038, the obvious fix is to interpret BCD years | in the range 70-99 as being in the 1900's, and the BCD years | in the range 00-38 as in the 2000's. This is, for example, | how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. Gee, I didn't think there was one "UNIX" in the world 8-) How big are your integers? Do you use signed or unsigned values for the epoch since Jan 1 1970? It seems hard to believe anything in the UNIX world of today has this limitation. I'll agree there is likely just the one "RT-11" though 8-) -- Ken Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22536 for pups-liszt; Fri, 27 Nov 1998 06:17:19 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From SHOPPA at trailing-edge.com Fri Nov 27 05:15:17 1998 From: SHOPPA at trailing-edge.com (Tim Shoppa) Date: Thu, 26 Nov 1998 14:15:17 -0500 Subject: Pro/Venix and Y2K Message-ID: <981126141517.2a2003cb@trailing-edge.com> >There's some confusion about this (at least in my mind), so any >authoritative info would be interesting. I agree - and would love more definitive information (Or, even better, the sources to Pro/Venix.) I've learned an amazing amount about segments of the Unix lineage just from the comments in the past week, but the gaps in my knowledge still loom large! It's entirely possible that Pro/Venix uses the Pro clock in BCD mode - it looked to me that the 2.9BSD version does it in binary mode. >struct clkbuf { > int clk_sec; /* second (0-59) */ > int clk_min; /* minute (0-59) */ > int clk_hour; /* hour (0-23) */ > int clk_mday; /* day of month (1-31) */ > int clk_mon; /* month (0-11) */ > int clk_year; /* year (00-99) */ > int clk_wday; /* day of the week (Sunday = 0) */ > int clk_yday; /* day of the year (0-365) */ > int clk_dst; /* non-zero if daylight savings applies */ >}; > >So, it looks bad at least from the internal representation of the >year. It depends on what you want to call "bad". It's quite possible to build a Y2K compliant system out of non-Y2K compliant components! 2.11BSD's date(1) was patched for Y2K in such a way that "00" in the two-digit year would be interpreted as the year 2000. (See patch #327 for the details.) Would similar fixes for more historic Unices be useful to the general folk here? -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22638 for pups-liszt; Fri, 27 Nov 1998 06:50:39 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From djenner at halcyon.com Fri Nov 27 05:49:47 1998 From: djenner at halcyon.com (David C. Jenner) Date: Thu, 26 Nov 1998 11:49:47 -0800 Subject: Pro/Venix and Y2K References: <981126141517.2a2003cb@trailing-edge.com> Message-ID: <365DB0DB.CD18A664@halcyon.com> It's "bad" in the sense that the evidence available (empirical, and sparse code) suggests that the software (and probably the hardware) is working with only two-digit years. You could, of course, try to remedy the Y2K problem by properly handling the clock. But the evidence suggests that the problem may be spread over lots of code. As you say, it would be nice to have the Pro/Venix code (as opposed to the Venix/Pro code). DEC's Pro/Venix is more flexible than Venturecom's Venix/Pro. You can write and link custom device drivers with the kernel in Pro/Venix. There is some hope you could actually "fix" /dev/clock, but this probably isn't enough to solve the whole Y2K problem. Again, any knowledge about the whereabouts of even the binary distribution disks of DEC's V2 Pro/Venix would be great. Dave Tim Shoppa wrote: > > >There's some confusion about this (at least in my mind), so any > >authoritative info would be interesting. > > I agree - and would love more definitive information (Or, even > better, the sources to Pro/Venix.) I've > learned an amazing amount about segments of the Unix lineage > just from the comments in the past week, but the gaps in > my knowledge still loom large! > > It's entirely possible that Pro/Venix uses the Pro > clock in BCD mode - it looked to me that the 2.9BSD version > does it in binary mode. > > >struct clkbuf { > > int clk_sec; /* second (0-59) */ > > int clk_min; /* minute (0-59) */ > > int clk_hour; /* hour (0-23) */ > > int clk_mday; /* day of month (1-31) */ > > int clk_mon; /* month (0-11) */ > > int clk_year; /* year (00-99) */ > > int clk_wday; /* day of the week (Sunday = 0) */ > > int clk_yday; /* day of the year (0-365) */ > > int clk_dst; /* non-zero if daylight savings applies */ > >}; > > > >So, it looks bad at least from the internal representation of the > >year. > > It depends on what you want to call "bad". It's quite possible > to build a Y2K compliant system out of non-Y2K compliant > components! > > 2.11BSD's date(1) was patched for Y2K in such a way that "00" in > the two-digit year would be interpreted as the year 2000. (See > patch #327 for the details.) > > Would similar fixes for more historic Unices be useful to the general > folk here? > > -- > Tim Shoppa Email: shoppa at trailing-edge.com > Trailing Edge Technology WWW: http://www.trailing-edge.com/ > 7328 Bradley Blvd Voice: 301-767-5917 > Bethesda, MD, USA 20817 Fax: 301-767-5927 From wkt at henry.cs.adfa.oz.au Fri Nov 27 08:26:17 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 09:26:17 +1100 (EST) Subject: List of licensees In-Reply-To: <199811261637.DAA13285@henry.cs.adfa.oz.au> from Kelwin Wylie at "Nov 26, 98 11:34:23 am" Message-ID: <199811262226.JAA13586@henry.cs.adfa.oz.au> In article by Kelwin Wylie: > I am curious to see who else has a source code license. > I imagine there might be privacy concerns, but if there isn't, > I would like to see the list. > Kelwin I can't see any harm, and it's good to know who you can share stuff with. Here are the names I have. There are obviously more people/organisations with licenses. Warren James A. Capp Greg Lehey Ali Bahrami Oleg Levanidov Pat Barron Yi Li Harald Barth Andrew Lynch Craig Bevans Douglas M. Wells Joseph Bickel James MacKeivitch Stefan Bieschewski Keizo Maeda Robin Birch Masahiro Matsumoto Hartmut Brandt Doug McIntyre Matthias Bruestle Kristen McIntyre W. C. Bulte Kirk McKusick Jozc Capkyn Giegrich Michael Brian Chase Shuji Mochida Atindra Chaturvedi Andreas Muller Peter Chubb Dieter Muller Efton Collins Joseph Myers Peter Collinson Gregory Neil Shapiro Rick Copeland Lyndon Nerenberg Matthew Crosby Peter Nikolaev Zhivkov Donald Cruikshank Ray Nouell Mrian Crzig Lennox Kevin Ogden J. D. Knaebel Joergen Pehrson Carlo Dapor Carl Phillips Eric Delgado Paul Pierce Erick Delios James R. Willing Barry Dobyns Charles Retter John Dodson Bruce Robertson Anthony Duell Chang Sang-Thong Alexander Duerrschnabel Michael Schmitz Kevin Dunlap Steven Schultz Hendrik Dykstra Daniel Seagraves Charles E Owen Michael Shalayeff Eric Fischer Gregg Sigfried Gregor Fismer Barry Silverman Robert G. Van Herick Michael Sokolov David Galloway Chris Steinke Glenn Geers Jason Stevens Edmund Goppelt Mark Thompson Brent Graveland Warren Toomey Arno Griffioen Jennine Townsend John Harvard Pete Turnbull Martin Heller Christopher Vance Michael Homsey Paul Vixie Michael J. Haertel Jason Wells Jay Jaeger Ken Wellsch Martin James Crehan Jim Williams David Jenner John Wilson Neil Johnson Norman Wilson Soren Jorvang Kelwin Wylie Moto Kawasaki Thomas Yanuklis Eugene Kim Thomas Zenker Kern Koh Leendert van Doorn Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA23319 for pups-liszt; Fri, 27 Nov 1998 09:26:59 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From wkt at henry.cs.adfa.oz.au Fri Nov 27 08:28:31 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 09:28:31 +1100 (EST) Subject: Pro/Venix and Y2K In-Reply-To: <981126115034.2a2004dc@trailing-edge.com> from Tim Shoppa at "Nov 26, 98 11:50:34 am" Message-ID: <199811262228.JAA13602@henry.cs.adfa.oz.au> In article by Tim Shoppa: > The following exchange recently took place on comp.sys.dec.micro/ > vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix > is based on 2.9BSD - does anyone know more details about its heritage? I understand that Venix is a cut-down SysIII in binary-only format. We have SysIII in the archive in source form, if that's of any help. I doubt it will have the device handler for the PRO 380 Time-Of-Year clock. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA23443 for pups-liszt; Fri, 27 Nov 1998 09:56:13 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From wkt at henry.cs.adfa.oz.au Fri Nov 27 08:57:56 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 09:57:56 +1100 (EST) Subject: Pro/Venix and Y2K In-Reply-To: <19981127092329.U67961@freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:23:29 am" Message-ID: <199811262257.JAA13789@henry.cs.adfa.oz.au> In article by Greg Lehey: > On Friday, 27 November 1998 at 9:28:31 +1100, Warren Toomey wrote: > > I understand that Venix is a cut-down SysIII in binary-only format. We have > > SysIII in the archive in source form, if that's of any help. > > Interesting. How did we get that? Or is it a 16 bit version? > Greg It's a PDP-11 version donated by Kirk. We also have SysV for the PDP-11, donated by John Holden, but I can't put it in the archive because the SCO license specifically doesn't cover SysV. Cheers, Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA23485 for pups-liszt; Fri, 27 Nov 1998 10:02:15 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From wkt at henry.cs.adfa.oz.au Fri Nov 27 09:03:50 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 10:03:50 +1100 (EST) Subject: List of licensees In-Reply-To: <19981127092818.V67961@freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:28:18 am" Message-ID: <199811262303.KAA13818@henry.cs.adfa.oz.au> In article by Greg Lehey: > There seem to be some obvious omissions, such as Dennis and Tim > Shoppa. I also have the feeling that a number of others should be > there, but I can't put a name to them. I can only give the details of the people for whom I actually have license numbers (both SCO, AT&T and Western Electric). If you _are_ covered by a UNIX source license, and would like access to the archive, then please fax your license to me at +61 6268 8581. I only require the pages with the signatures, the license numbers, and the list of UNIX versions covered. Thanks, Warren From DSEAGRAV at toad.xkl.com Sat Nov 28 06:06:59 1998 From: DSEAGRAV at toad.xkl.com (Daniel A. Seagraves) Date: Fri, 27 Nov 1998 12:06:59 -0800 Subject: 2.9BSD/DZ-11 clone screw Message-ID: <13407312462.14.DSEAGRAV@toad.xkl.com> I got my hands on a Aviv DZ-11 clone. 16-line MUX. So, I go about shoving it in the 83. It boots 2.9BSD off a RL02. Shove device in, set CSR and interrupt vector, and fire up BSD. I screwed with the dtab line - With it using dzdma in place of dzou, I can't make the MUX go. The kernel attaches it, but I can't seem to be able to talk to it. So, I switched to dzou. Now, upon boot, I get the message: dz 0 csr 160100 vector 320 no address found for dzou SERIOUS CONFIGURATION ERROR^G^G^G I've tried other vectors and other bus slots, and get no improvements with either method (dzdma or dzou). Any ideas? (Oh, and if you've got another SDZV11, the DIP switches are BACKWARDS of their labels! 1=0 and 0=1. Cute, eh?) I also have a DHV11, but no idea how to tell BSD it's there. All I ever get from it is dh ? csr 160020 vector 370 didn't interrupt I think I need to set the DM address, but have no idea what to set it to. ------- Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA28694 for pups-liszt; Sat, 28 Nov 1998 12:11:23 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From sms at moe.2bsd.com Sat Nov 28 10:56:52 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Fri, 27 Nov 1998 16:56:52 -0800 (PST) Subject: 2.9BSD/DZ-11 clone screw Message-ID: <199811280056.QAA23331@moe.2bsd.com> > From: "Daniel A. Seagraves" > > I got my hands on a Aviv DZ-11 clone. 16-line MUX. So, I go about... > shoving it in the 83. It boots 2.9BSD off a RL02. Shove device in, > I screwed with the dtab line - With it using dzdma in place of dzou, I can't > make the MUX go. The kernel attaches it, but I can't seem to be able to talk > to it. So, I switched to dzou. Now, upon boot, I get the message: How are you trying to talk to it? If the line is marked as "modem controlled" you will see/hear nothing until there is 'CD' (carrier detect) present. Typically the /dev nodes are "modem controlled" unless you add 0200 (128 dec) to the minor device number. For 2.9 the major device number of the DZ is 21 so /dev/tty00 would be "mknod /dev/tty00 c 21 0" and expect modemcontrol while "mknod /dev/tty00 c 21 128" would be a "hardwired" line w/o modem control. > dz 0 csr 160100 vector 320 no address found for dzou > SERIOUS CONFIGURATION ERROR^G^G^G That's not surprising since there is no such symbol in the DZ driver ;) 'dzdma' is a replacement for the transmit interrupt routine - the xmit interrupt goes to 'dzdma' (IF 'DZ_DMA' is enabled in the kernel config file). 'dzdma' calls 'dzxint' at the end of dzdma's processing. Thus if you change 'dzdma' to anything it should be to 1) a symbol which exists and 2) 'dzxint'. I think something bad happens if DZ_DMA is enabled but dzxint is called directly - it probably won't work since there are two different 'dzxint' routines (one for use with dzdma and one without and the args are different). So if the symbol 'dzdma' is present in the kernel you probably want to least the "xmit field" in /etc/dtab as 'dzdma'. If 'dzdma' is not present in the kernel then use 'dzxint'. > I've tried other vectors and other bus slots, and get no improvements > with either method (dzdma or dzou). Any ideas? Try remaking the device nodes to indicate no modem control. Or perhaps create a cable that asserts the necessary signals. > I also have a DHV11, but no idea how to tell BSD it's there. > All I ever get from it is > dh ? csr 160020 vector 370 didn't interrupt Quite so. The original 2.9BSD didn't support the DHV or DHU devices. Later on there were drivers created but the original distributions lack (according to the CSRG archive CDs) 'dhv' and 'dhu' support. The closest 2.9 came was the venerable DH/DM. 2.11BSD does have DHV support but the silo handling of those devices is *terrible*. If you have any choice in the matter at all get a DHQ-11 and set it for 'DHU' mode. The DHQ can run in DHV or DHU modes with the latter being far preferable (its behaviour is that of the older DH-11 with regard to silo alarm level selectability). > I think I need to set the DM address, but have no idea what to set it to. Not for a DHV. An older DH/DM you would have needed to but that is one of the differences (and why the DHV isn't compatible with the DH driver) is how modem signals are handled. On a 2.11BSD system there is a single line: dhv ? 160440 310 5 dhvrint dhvxint # dhv terminal mux for the DHV-11. Where the CSR/Vector were set to whatever didn't conflict with something else. Good Luck. Steven Schultz sms at moe.2bsd.com From wkt at henry.cs.adfa.oz.au Thu Nov 12 12:57:45 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Thu, 12 Nov 1998 13:57:45 +1100 (EST) Subject: Upgrade of PUPS List server Message-ID: <199811120257.NAA04829@henry.cs.adfa.oz.au> All, I have just upgraded the server where the PUPS mailing list resides, to a newer operating system version. This email is just to test that the MajorDomo software is still working. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA04919 for pups-liszt; Thu, 12 Nov 1998 14:28:57 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Thu Nov 12 14:55:23 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 11 Nov 1998 23:55:23 -0500 Subject: 4.3BSD-Tahoe and 4.3BSD-Reno Message-ID: <199811120455.XAA09098@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have converted the 4.3BSD-Tahoe and 4.3BSD-Reno tape images Rick has recently uploaded into a more convenient format. I haven't changed anything in the images themselves, I have simply repacked them from a single .zip into a collection of .gz's, one per tape file. I have also prepared a listing for every tarball. This stuff is in: /usr/home/msokolov/43tahoe.cci (4.3BSD-Tahoe with CCI binaries) /usr/home/msokolov/43reno.vax (4.3BSD-Reno with VAX binaries) That's on minnie.cs.adfa.oz.au. The permissions are set up so that pupsarc group members (UNIX source license holders) can read them, but no one else can. With Warren's permission, I would like to keep this stuff there until I set up my own FTP site, at which time I'll announce its location. The Reno images are perfect, but for Tahoe usr.tar.gz and src.tar.gz are bad (everything else is fine). Apparently Rick wasn't able to read past a tape defect (we are handling this in private E-mail). Have fun with this stuff! Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA04992 for pups-liszt; Thu, 12 Nov 1998 14:37:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Thu Nov 12 14:51:32 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Thu, 12 Nov 1998 15:51:32 +1100 (EST) Subject: 4.3BSD-Tahoe and 4.3BSD-Reno In-Reply-To: <199811120455.XAA09098@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 11, 98 11:55:23 pm" Message-ID: <199811120451.PAA05125@henry.cs.adfa.oz.au> In article by Michael Sokolov: >I have converted the 4.3BSD-Tahoe and 4.3BSD-Reno tape images Rick has recently > uploaded into a more convenient format. I haven't changed anything in the > images themselves, I have simply repacked them from a single .zip into a > collection of .gz's, one per tape file. I have also prepared a listing for > every tarball. This stuff is in: > > /usr/home/msokolov/43tahoe.cci (4.3BSD-Tahoe with CCI binaries) > /usr/home/msokolov/43reno.vax (4.3BSD-Reno with VAX binaries) I'll move copies of Michael's 43tahoe.cci and 43reno.vax directories into the main PUPS archive area, in the Distributions/4bsd area. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id WAA01355 for pups-liszt; Fri, 13 Nov 1998 22:58:33 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Fri Nov 13 22:05:43 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Fri, 13 Nov 1998 07:05:43 -0500 Subject: 4.2BSD and 4.3BSD Message-ID: <199811131205.HAA09705@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have just uploaded the images from the 4.3BSD tapes I had read on CWRU's MVS mainframe back in June. They are perfect (the 1600 BPI tapes were read without any errors and the format is absolutely correct). Note, though, that this is the June 1986 4.3BSD release, and I remember Kirk saying that among the tapes Rick is reading there is one with 4.3BSD revision 2, which is presumably 4.3BSD with some bugs fixed. I have also put an honest effort into reconstructing the 4.2BSD tape images from the files in Distributions/4bsd/Per_Andersson_4.2. The latter have the boot/standalone system file (1st on the tape) broken, the tarball with /usr/src also broken, and the tarball with /usr/lib/vfont simply missing. I have manually repaired the boot/standalone system file (using my brain and a hex editor), but unfortunately /usr/src is broken beyond repair (so I didn't include it in my repackaging). I see no reason for the Varian/Versatec fonts to change between BSD releases, so /usr/lib/vfont from 4.3BSD will probably do fine. It would still be nice if Rick could read Kirk's 4.2BSD tapes, though. For practical use 4.3BSD completely supersedes it, but for historical purposes we should preserve 4.2BSD as well. This stuff is in: /usr/home/msokolov/42.vax (4.2BSD) /usr/home/msokolov/43.vax (4.3BSD) on minnie.cs.adfa.oz.au. (Warren, if you want to put this in the main PUPS archive, go ahead and do it for 43.vax, as it should be ready to be frozen, but I would hold on with 42.vax. Hopefully Rick will have some luck reading Kirk's tapes, and then I'll update the 42.vax directory by filling the missing pieces.) Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA15543 for pups-liszt; Tue, 17 Nov 1998 06:04:29 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 17 05:14:44 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 16 Nov 1998 11:14:44 -0800 Subject: 4.3BSD-Tahoe and 4.3BSD-Reno Message-ID: <3.0.32.19981116111440.00922460@pop.calweb.com> Warren, I am unable to login to minnie, I keep getting back "user rickgc access denied!". Why? Thanks, Rick Copeland Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA05416 for pups-liszt; Fri, 20 Nov 1998 12:57:22 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Fri Nov 20 12:09:52 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Thu, 19 Nov 1998 21:09:52 -0500 Subject: KA650 problem Message-ID: <199811200209.VAA15512@skybridge.scl.cwru.edu> Dear Ladies and Gentlemen, I'm trying to build my first release (4.3BSD-Quasijarus1), and I have the following problem. I'm currently away from my main VAX farm, and so I have rounded up a new VAX for this task from an independent source. It's a KA650-based MicroVAX specially made for Xerox. The outer cabinet is made by Xerox, but it has a BA23 mounted inside. There is no video, just a serial terminal. My first problem was that the beast refused to power up. I turn on the power, but there is nothing on the console and the hex LED display on the back says 9. I power-cycled it several times with zero effect, and then I took the CPU board out to look at it. It looked perfectly normal, and I put it back in. Then imagine my joy when I power up the VAX and this time it works! After that I worked with it for a while, and in the process I turned it on and off a couple of times and it didn't have any problem powering up. My next step was installing Ultrix, which is the platform I have chosen to use for putting together the initial Quasijarus SCCS tree and cross- compiling the very first Quasijarus build. However, when I tried to boot from the Ultrix tape, I got a "?4B CTRLERR" (after an _extremely_ long wait with a lot of retries), which according to my docs means some hardware error. I reasoned that it has to be either the TK50 drive or the TQK50 controller. I don't have any spare TK50s at this location, but I do have one spare controller, and so I tried swapping it. I turned the machine off, swapped the board, and turned it back on. And guess what, that ugly 9 came back! I haven't been able to power up the VAX since then. I started investigating. I don't have any docs for KA650, but I do have some for KA655. According to these docs, the KA650 series CPUs have very elaborate ROM diagnostics organized in the form of scripts, some of which are executed at power-up. The manual lists all scripts, indicating the order of the tests and the hex LED display codes. According to this manual, the only tests which display a 9 are fairly late in the sequence and are fairly benign (shouldn't stall the power-up even if failed). The problem I'm seeing, OTOH, appears to be very early. For example, the console line loopback test appears to be one of the very first, and yet my VAX always stalls on the 9, even if I put the switch in the T-in-the-circle position. I have also watched the hex LED display very carefully right as I flip the power switch, and as far as I can tell it goes directly from F (waiting for DCOK) to 9. Finally, disconnecting the bulkhead and the memory interconnect produces absolutely no effect, suggesting that the culprit is the CPU board and nothing else. Also pushing the RESTART button on the front panel produces absolutely no effect, if the 9 was there it just stays there, there is no F appearing for a short time or anything like that. What does the RESTART button do, anyway? Does anyone here have a clue as to what's going on? Does anyone have a KA650 manual? Can anyone tell what the hell does the 9 stand for? Any ideas on how this can be fixed (other than replacing the CPU board)? TIA. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA06383 for pups-liszt; Fri, 20 Nov 1998 19:08:01 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From bdc at world.std.com Fri Nov 20 18:07:44 1998 From: bdc at world.std.com (Brian D Chase) Date: Fri, 20 Nov 1998 00:07:44 -0800 (PDT) Subject: Loads of PDP-11 docs on Ebay. Message-ID: Just an FYI for all you PDP-11 collectors out there. A search for "DEC" under the Computers section of Ebay yields an impressive number of PDP-11 docs. -brian. --- Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!! Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA09000 for pups-liszt; Sat, 21 Nov 1998 09:58:30 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From grog at lemis.com Sat Nov 21 08:57:40 1998 From: grog at lemis.com (Greg Lehey) Date: Sat, 21 Nov 1998 09:27:40 +1030 Subject: Loads of PDP-11 docs on Ebay. In-Reply-To: ; from Brian D Chase on Fri, Nov 20, 1998 at 12:07:44AM -0800 References: Message-ID: <19981121092740.F1005@freebie.lemis.com> On Friday, 20 November 1998 at 0:07:44 -0800, Brian D Chase wrote: > Just an FYI for all you PDP-11 collectors out there. A search for "DEC" > under the Computers section of Ebay yields an impressive number of PDP-11 > docs. What's Ebay? Greg -- See complete headers for address, home page and phone numbers finger grog at lemis.com for PGP public key Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA09072 for pups-liszt; Sat, 21 Nov 1998 10:32:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From bdc at world.std.com Sat Nov 21 09:31:51 1998 From: bdc at world.std.com (Brian D Chase) Date: Fri, 20 Nov 1998 15:31:51 -0800 (PDT) Subject: Loads of PDP-11 docs on Ebay. In-Reply-To: <19981121092740.F1005@freebie.lemis.com> Message-ID: On Sat, 21 Nov 1998, Greg Lehey wrote: > On Friday, 20 November 1998 at 0:07:44 -0800, Brian D Chase wrote: > > Just an FYI for all you PDP-11 collectors out there. A search for "DEC" > > under the Computers section of Ebay yields an impressive number of PDP-11 > > docs. > > What's Ebay? Sorry about that... I'd thought everybody knew by now. It's the world's largest and most popular on-line auction service. http://www.ebay.com/ -brian. --- Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!! Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA12024 for pups-liszt; Sun, 22 Nov 1998 04:51:52 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 03:49:46 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 12:49:46 -0500 Subject: 4.3BSD Installation (probably off-topic) Message-ID: <981121124946.2a2000ed@trailing-edge.com> I've been looking over the recent 4.3-ish BSD distributions now available from the PUPS archive. Thought I'd spin off a copy for booting on one of my spare uVax II's, but I'm stuck at (literally) before step one, and don't know where to go from here. If there's a more appropriate forum for these questions, I'd appreciate being redirected to them! OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is: YOU MUST ALREADY HAVE A WORKING VAX! These instructions are useless on a cold machine. You must have a 4.3 machine and a working uVax (probably Ultrix!) with a tk50 drive. Apparently, this is because the distributions don't boot on a Microvax, and the KA630 Microvax/MSCP/TMSCP patches must be installed and many things rebuilt on a 4.3 machine before a distribution tape can be built to put on a VAX. Is this an actual limitation on the 43reno.vax distribution currently in the archive, or not? If it is a real limitation, what non- microvax machines will the 43reno.vax distribution boot on? 11/750? 11/730? Tim. (shoppa at trailing-edge.com) Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA12354 for pups-liszt; Sun, 22 Nov 1998 06:15:56 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 05:28:28 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sat, 21 Nov 1998 14:28:28 -0500 Subject: 4.3BSD Installation (probably off-topic) Message-ID: <199811211928.OAA15984@skybridge.scl.cwru.edu> SHOPPA at trailing-edge.com writes: > I've been looking over the recent 4.3-ish BSD distributions > now available from the PUPS archive. Thought I'd spin off > a copy for booting on one of my spare uVax II's [...] The most important thing here is to choose the right version of BSD. Plain 4.3 CANNOT boot on a MicroVAX II. Later versions, starting with Tahoe, can. The patches provided in 4.3_on_uVax_instructions are nothing more than pieces taken out of Tahoe. If you are going to use those, you might want to use the whole Tahoe system just as well, it has some very nice improvements, such as disk labels, better man mechanism, and MX record support in sendmail. The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe tape with VAX binaries. I'm not sure if CSRG ever bothered to even make one, although it's as simple as executing one script on a running system (which they obviously had). Thus in order to run Tahoe, one would have to cross-compile it first. It's a pain and takes a lot of expertise, so I would strongly advise you to avoid effort duplication and wait until I do it and put the product up in my home directory on minnie.cs.adfa.edu.au. Actually since KA650 is all I have right now and Tahoe doesn't support it (but the support code appears later in the SCCS tree), I'll go directly from Ultrix (my cross-compilation base) to Quasijarus1, my first release, and won't bother with Tahoe. But for all practical purposes Quasijarus1 will be Tahoe plus KA650 support, shadow passwords, and bugfixes. Hmm, maybe your have never heard of Quasijarus Project, so I'll explain briefly what it is. I'm taking over UCB CSRG in terms of shepherding and maintaining pure Berkeley UNIX(R). I will first re-create it by taking their final SCCS tree and building my initial one, deciding piece by piece what belongs to pure Berkeley UNIX(R) and should be kept, and what is POSIX evil spirit or bloat and should be tossed. In general I draw the line right around the Tahoe release (summer of 1988), but I'll include anything from Reno and later code that's worth having, such as KA650 support and Reno's DBM-based shadow password model. Basically, I want to create a system with a classical (pre-Reno) look and feel which at the same time has all the quality improvements and bugfixes ever made by Berkeley, even if they are as late as 4.4BSD. The last classical release is Tahoe, so that's my base. I will be using Tahoe to decide what should be included and what should the look and feel be. Once I know from Tahoe that a given piece should be included, I'll go to the SCCS file(s) for that piece and decide which post- Tahoe deltas should be kept (because they are bugfixes or quality improvements) and which deltas should be tossed (because they introduce the evil spirit of POSIX or bloat). How soon will this happen? I'm all ready to go, but unfortunately hardware problems are holding me back. I have solved the KA650 problem I was having, but now I'm stuck because neither of the two TQK50 boards I have works. (The drive SEEMS to work, though.) Thus the sooner I find a working TQK50 board (or, alternatively, a working TK70/TQK70 pair), the sooner will I make 4.3BSD-Quasijarus1. > If there's a more appropriate forum for these questions, I'd > appreciate being redirected to them! Right now there isn't, because my main VAX farm is currently off the net. When I get it back on the net (no time estimate, at least several more months), I'll set up a set of mailing lists for Quasijarus Project and Berkeley VAX UNIX in general. > OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is: Totally disregard these instructions, they are for plain 4.3 ONLY. If you are using Tahoe or Quasijarus1, the distribution already supports MicroVAXen as shipped. If you don't want to use Tahoe or Quasijarus1 and want to use plain 4.3, you are on your own. > Is this an actual limitation on the 43reno.vax distribution currently > in the archive, or not? Reno doesn't have any limitations, it already supports KA630 and KA650, just like Quasijarus1. I personally don't use it, though, because it is not really True UNIX any more. With the evil spirit of POSIX and a bloat by a factor of 2 in both binaries and sources, Reno is the beginning of the destructive process that eventually (and necessarily) culminated with the disbanding of CSRG. > what non- > microvax machines will the 43reno.vax distribution boot on? 11/750? > 11/730? Of the big VAXen, plain 4.3 supports 11/780, 11/750, 11/730, and Venus (should have been called 11/790, but was unfortunately named 8600). Tahoe adds, and Quasijarus1 and Reno retain, the support for 8200. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA12654 for pups-liszt; Sun, 22 Nov 1998 07:42:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 06:40:02 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 15:40:02 -0500 Subject: 4.3BSD Tahoe binaries for uVax Message-ID: <981121154002.2a2000ed@trailing-edge.com> > The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe >tape with VAX binaries. I think I *might* be able to provide part of the solution to this. I have in my posession here a TK50 tape hand-labeled "4.3 Tahoe BSD". Let me upload it to my directory on Minnie, and maybe with some help from you guys we'll figure out what's in it. It has been at least a year since I've looked at the contents of this tape, but I was under the impression that it consisted mainly of binaries, and had very little in the way of sources on it. I'll put images of the tape files on Minnie (hmm - a full TK50 will probably be an overnight job) and with a little luck we'll figure out how to make the next step. (I didn't know that this was a sought-after tape in the first place!) I honestly don't know if this is a VAX Tahoe distribution or for something else (MIPS, maybe?). It did fail to boot on my KA650 when I tried it, but your notes indicate that this was to be expected because it wasn't a KA630. And browsing through the contents of the tape does seem to indicate that it might be for the VAX. The tape has 4 files on it, about 50 Megabytes uncompressed, organized as follows: File 1: 1 record, 512 bytes. File 2: 205 records, 10240 bytes each. File 3: 320 records, 10240 bytes each. File 4: 2135 records, 20480 bytes each. The first block has no obvious text in it. Obvious guess is a boot block :-) The second file appears to be an executable of some sort. Running "strings" against it turns up evidence that this is some sort of standalone utility that knows how to write to devices with names like "ra1", "hp3", etc. The third file is, I would guess, the dump of a root file system. The string "/dev/ra1a" and machine name "kerberos.berkeley.edu" turn up near the beginning, and the dump of what appears to be the "/dev" directory has names such as tu0, tu1, hp0a-hp0g, rhp0a-rhp0g, etc. The fourth file is a tar archive, and appears to contain mainly binaries, with little in the way of sources. The are links in the tar archive to things like "/sys/vaxuba", "/sys/vax", etc., but the /sys directory itself isn't in the tar archive. (Would this possibly be in the third file, which I guessed is a dump of the root filesystem? The other BSD- derived distributions that I'm familiar with do not have "/sys" or "/usr/src/sys" in the root filesystem!) -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA12866 for pups-liszt; Sun, 22 Nov 1998 08:41:48 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 07:39:31 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 16:39:31 -0500 Subject: 4.3BSD Tahoe binaries for uVax Message-ID: <981121163931.2a2001df@trailing-edge.com> Some further clues, for anyone who's following this bit or archeology: The second file on the tape has the following string in it: 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990 trent at kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot The third file has this string in it: 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990 trent at kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax. Additionally, in the third file, there appears to be some printf-type strigns for configuring in the different possible CPU's supported: VAX 8600, serial# %d(%d), hardware level %d(%d) VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d) VAX 11/750, hardware rev %d, ucode rev %d VAX 11/730, ucode rev %d MicroVAX-II-MicroVAX 3000, ucode rev %d So the tape sticker says "Tahoe", the miniroot and Generic root claim to be Reno, and the fourth file (the tar archive) has the following mentions of Tahoe and Reno: $ sear file4.tar_list tahoe 755 0 Jul 29 06:26:47 1990 share/man/cat4/tahoe/ 444 2488 Jul 29 06:26:43 1990 share/man/cat4/tahoe/ace.0 444 3563 Jul 29 06:26:44 1990 share/man/cat4/tahoe/autoconf.0 444 1321 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cons.0 444 6446 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cy.0 444 4074 Jul 29 06:26:44 1990 share/man/cat4/tahoe/dr.0 444 2331 Jul 29 06:26:44 1990 share/man/cat4/tahoe/enp.0 444 4121 Jul 29 06:26:44 1990 share/man/cat4/tahoe/ik.0 444 2498 Jul 29 06:26:45 1990 share/man/cat4/tahoe/intro.0 444 386 Jul 29 06:26:45 1990 share/man/cat4/tahoe/lp.0 444 4427 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mtio.0 444 9321 Jul 29 06:26:45 1990 share/man/cat4/tahoe/vd.0 444 3816 Jul 29 06:26:46 1990 share/man/cat4/tahoe/vx.0 444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mem.0 444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/kmem.0 ---> share/man/cat4/tahoe/mem.0 755 0 Jul 4 18:49:29 1990 share/man/cat6/tahoe/ $ sear file4.tar_list reno %SEARCH-I-NOMATCHES, no strings matched If someone who is more aware of the 4.3BSD histories than I am (and I'm certain that I'm one of the least-aware folks around!) can pinpoint where in the hierarchy this tape belongs, it'd help settle a lot of my confusion! In the meantime, the FTP connection to minnie seems to be holding up admirably, and folks will be able to inspect the files for themselves sometime around 7 PM EST tonight (Saturday here - that's either tomorrow or yesterday in Australia, I can never remember which) in the directory /usr/home/shoppa/43bsd_tahoe on minnie. -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13145 for pups-liszt; Sun, 22 Nov 1998 10:13:57 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 09:26:26 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sat, 21 Nov 1998 18:26:26 -0500 Subject: 4.3BSD Tahoe binaries for uVax Message-ID: <199811212326.SAA16073@skybridge.scl.cwru.edu> Tim Shoppa writes: > Some further clues, for anyone who's following this bit or > archeology: This is clearly a 4.3BSD-Reno tape (for VAX). I'll look at it when it's fully uploaded (you're saying it won't be until 19:00 EST, so it'll be after the X-Files I guess), but I can bet that it's identical to the one in /usr/home/msokolov/43reno.vax on minnie (read by Rick Copeland from the CSRG master provided by Marshall Kirk McKusick). > The second file on the tape has the following string in it: > > 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990 > trent at kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot The second file is the dd image of the miniroot filesystem. This string appears in the /vmunix file inside (the kernel). kerberos.berkeley.edu was a VAX. The tape in /usr/home/msokolov/43reno.vax has also been pressed from kerberos.berkeley.edu. > The third file has this string in it: > > 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990 > trent at kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax. The third file is the dump of the full root filesystem. Again, this string appears in the /vmunix file inside. > Additionally, in the third file, there appears to be some printf-type > strigns for configuring in the different possible CPU's supported: > > VAX 8600, serial# %d(%d), hardware level %d(%d) > VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d > VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d) > VAX 11/750, hardware rev %d, ucode rev %d > VAX 11/730, ucode rev %d > MicroVAX-II-MicroVAX 3000, ucode rev %d This is also obviously inside /vmunix. The set of supported CPUs is the one for Reno. > So the tape sticker says "Tahoe", the miniroot and Generic root claim > to be Reno, and the fourth file (the tar archive) has the following > mentions of Tahoe and Reno: > > [names on manpage directories mentioning tahoe] It is Reno. Trust me. "tahoe" appears in the names of some manpage directories because some manpages are architecture-specific (tahoe is the name of a computer architecture, just like vax, hp300, i386, etc.). The tape is mislabeled, that's all. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA13713 for pups-liszt; Sun, 22 Nov 1998 12:47:28 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 11:55:01 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sat, 21 Nov 1998 20:55:01 -0500 Subject: The files Tim Shoppa has just uploaded Message-ID: <199811220155.UAA16138@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have just logged into minnie and diffed the files Tim Shoppa has just uploaded against the 43reno.vax distribution in my home directory. They are identical byte for byte, except that Tim's first file is severely truncated. The first file contains the bootstraps and the standalone programs, and for Reno it's about 140 KB. Tim's first file is only 512 bytes, although these bytes exactly match the first 512 bytes in the correct first file. Resolution: the files Tim has uploaded are completely superseded by the authentic 4.3BSD-Reno/VAX distribution in /usr/home/msokolov/43reno.vax and /usr/PUPS/Distributions/4bsd/43reno.vax. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA13933 for pups-liszt; Sun, 22 Nov 1998 14:04:29 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 12:27:48 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sat, 21 Nov 1998 21:27:48 -0500 Subject: 4.3-VAX distributions (was Re: The files Tim Shoppa has just uploaded) Message-ID: <981121212748.2a2001f3@trailing-edge.com> > I have just logged into minnie and diffed the files Tim Shoppa has just >uploaded against the 43reno.vax distribution in my home directory. They are >identical byte for byte, Darn. And the label said it was a Tahoe distribution :-). You'll also remember that I'm the one who found the V6 RL02 packs at UBC which, despite all indications, are actually some sort of V7 system that has all the internal labels reading "V6"! > except that Tim's first file is severely >truncated. That would explain why I couldn't boot it, yep. In any event, I am now very happy to now have a bootable copy of 4.3-Reno. (Installing as I type, AAMAF.) We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? It's the most reasonable approach I can think of at the moment. And what stands in the way of reading around the bad blocks on Kirk McKusick's 43tahoe_cci distribution? Even though I know that Rick Copeland doesn't have all the fancy tape recovery equipment I have in my lab, is there some fundamental problem preventing the use of "mt fsr" commands to skip the bad block(s) and recover the rest of the "src" and "usr" tree? -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA14239 for pups-liszt; Sun, 22 Nov 1998 15:57:23 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Sun Nov 22 15:09:52 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 00:09:52 -0500 Subject: 4.3-VAX distributions Message-ID: <199811220509.AAA16197@skybridge.scl.cwru.edu> Tim Shoppa writes: > That would explain why I couldn't boot it, yep. Partially. You wouldn't be able to boot it on a MicroVAX by typing "B MUA0" even if it were complete. The reason is that the standard tape-making script writes the VAX-11 bootstraps on the tape, not the MicroVAX ones. The two are completely different. The big VAXen with front-end processors, microcode consoles and such can't boot from a tape by themselves. The bootstraps that appear on standard BSD distributions are designed to be loaded by manually typing in a little program from the console in hex and manually transferring control to it. The hex codes for 4 such programs (for different tape drives and controllers) appear in the installation docs. They cannot be ported to MicroVAXen, however, because they use some features that exist only on big VAXen. MicroVAXen, however, have tape boot capabilities built right into their ROMs. Much easier for the installer, needless to say. Also needless to say, the protocol the ROM tape boot code uses is completely different from the one the BSD developers have crafted for their very special purpose. Therefore, a tape needs a completely different bootstrap in order to be directly bootable on a MicroVAX. One was written for 4.3BSD-Tahoe, and it appears in the distributed /usr/mdec. There are two problems, however. First, the standard tape-making scripts don't put it on the tape. Second, it only supports KA630. When KA650 support was added, everything else was updated accordingly, but this one was apparently forgotten. In theory, the code looks generic enough to run on KA650 out of the box, but in practice it has a check for SID and refuses to run if it's not 08 (MicroVAX ii). Right now I don't know enough VAX assembly language to remove this check or extend to accept 0A (CVAX) as well. > In any event, I am now very happy to now have a bootable copy of > 4.3-Reno. (Installing as I type, AAMAF.) Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball and make a MicroVAX boot tape? > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > It's the most reasonable approach I can think of at the moment. That's close to what I'm doing. There are two differences, though. First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than between Tahoe and Reno. The latter is really huge, it's a gap between True UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus KA650 support and shadow passwords from Reno and other improvements from both later CSRG code and my own brain. SCCS will be the #1 tool in the process. > And what stands in the way of reading around the bad blocks on Kirk > McKusick's 43tahoe_cci distribution? Even though I know that Rick > Copeland doesn't have all the fancy tape recovery equipment I have in my > lab, is there some fundamental problem preventing the use of "mt fsr" > commands to skip the bad block(s) and recover the rest of the "src" and > "usr" tree? If you do this you will still miss something. OTOH, if you go to the 4.3tahoe directory on Kirk's 2nd CD-ROM, you won't miss anything, since all of /usr and /usr/src is there. I can bet that the files on that CD-ROM match the ones on the tape byte for byte. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA14402 for pups-liszt; Sun, 22 Nov 1998 17:04:17 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Sun Nov 22 15:32:06 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sun, 22 Nov 1998 0:32:06 -0500 Subject: 4.3-VAX distributions Message-ID: <981122003206.2a2001f3@trailing-edge.com> >> In any event, I am now very happy to now have a bootable copy of >> 4.3-Reno. (Installing as I type, AAMAF.) > Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it >to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball >and make a MicroVAX boot tape? Exactly. The details are all in tmscpboot.c. Prepend this to the "tape directory", write it to TK50, B MUA0, and you're at the "=" prompt, from which you can execute the standalone images. "format" seems to crash badly, but one probably doesn't need that on a Q-bus machine :-). There are other ways to start it up. For example, using an already- running OS (some other Unix or VMS) and copying the miniroot from tape to the swap area of an unused disk. The compiled-in partition tables used during an install are a real pain compared to, say, a 2.11BSD installation, where disklabel is a standalone utility! (That's a real win, Steven!) >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than >between Tahoe and Reno. The latter is really huge, it's a gap between True >UNIX(R) and a bloated and POSIXized fallen one.) Gees, looking at the install docs there are some very real improvements in Reno, especially in the filesystem and the speed of recompiled code. I'm willing to live with a bit more disk space usage, especially for the promised speed benefits. It's not like KA630's or KA650's are speed demons, and big cheap disks are readily available these days. -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14819 for pups-liszt; Sun, 22 Nov 1998 20:10:10 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From sms at moe.2bsd.com Sun Nov 22 19:00:06 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 22 Nov 1998 01:00:06 -0800 (PST) Subject: 4.3-VAX distributions Message-ID: <199811220900.BAA06484@moe.2bsd.com> Hi - > From: SHOPPA at trailing-edge.com > To: PUPS at MINNIE.CS.ADFA.EDU.AU All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't know there were any left :-) :-) > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" Since PUPS is on a uVax kick at the moment I'll chime in with my (not so fond) memories of trying to jack 4.3-Reno onto a uVax-II. It was a perverse sort of fun but not something I'd willingly do again. Burnout? Perhaps. the base 4.3 system up to and including Tahoe couldn't be cold started on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel had uVax support in it but the boot stuff did not. With 4.3-Reno that changed but... As others have noticed the cold start kit didn't create tapes suitable for a uVax. > prompt, from which you can execute the standalone images. "format" > seems to crash badly, but one probably doesn't need that on a Q-bus > machine :-). What I ended up doing was using my 2.11BSD 11/73 to create a bootable 4.3-Reno tape for the uVax - all the pieces are there, just need a system to 'dd' the files out with the right blocking factors, usw. Then the fun really began. The SPL "probing" logic in the kernel had a small problem when probing for MSCP controllers. As I recall (and this is going back quite a few years) some 3rd party adaptors ran at a different (lower) SPL than the probing logic expected - thus the autoconfig routines raised the SPL higher than the interrupt of the (Dilog I think) controller and the whole system hung. So, to install the system you HAD to use DEC controllers - ok, I had a RQDX3 and a couple RD53 drives present (the Dilog had a 319mb Miniscribe disk). BUT 4.3-Reno had a bug in the MSCP driver and would not recognize an honest to DEC RD53 drive! This was rapidly getting to be unfun. I think the workaround (it's been a __long__ time so memory is fuzzy) was to lie and call the drive an RA60 and then correct the problem later. But to get the lie thru to the kernel I had to use the standalone 'copy' program to copy a file (created on a PDP-11) to the first couple sectors of the uVax's RD53. Sheesh! > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) You're quite welcome. Actually 4.3-Reno served as inspiration and reminder of pain to avoid when it came time to implement 2.11BSD's disklabel capabilities. I swore I'd never go thru the pain of the kernel having labels but the standalone utilities lacking them 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the standalone programs still had compiled in partitions. > >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > >between Tahoe and Reno. The latter is really huge, it's a gap between True Can't be any version of Ultrix I ever used. At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD that DEC had corrupted with System V(anilla) bolted on contamination. Affectionately known as Buglix ;-) That was the same era that DEC had Ultrix-11 and that was a mucked up 2.9BSD. Of course you have to realize DEC had "Mr. Ken (Unix is Snake Oil) Olsen" around at the time 8-) UNIX is still around - but DEC? No, I don't like Compaq confusers thank you ;) 4.3-Reno was a transitional experiment that happened just as the CSRG and DEC had a serious falling out - and DEC support (Vaxen) vanished at that point. Any further work (4.4BSD) totally and completely ignored all DEC machines. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled Yep - you get NFS (which no 4BSD had prior to Reno). NFS doubles the size of the kernel though (at least) so there's a memory penalty to pay. It also brought many of the POSIX features (termios for example). > code. I'm willing to live with a bit more disk space usage, especially > for the promised speed benefits. It's not like KA630's or KA650's are speed > demons, and big cheap disks are readily available these days. Disk is cheap. Especially for older drives (but you run the risk that an old drive will die soon ;-(). Best to invest in a modern SCSI<->MSCP adaptor and use current drives (that's what I did for my 11/73 - adaptor is $$$ but the drives are cheap). Boy, you're not just whistling Dixie (apologies to those outside the US for which the reference is obscure). "Not a speed demon" doesn't begin to describe it. I went, believe it or not, thru the work of getting a newer GCC-2 (at the time I think 2.3.x was "new") to build and run on a uVax-II under 4.3-Reno. The biggest problem was that 4.3-Reno was neither "old" (V7ish) Unix or "POSIX" (just getting off the standard's writers desks). Getting GCC to build was a stop/go effort for several days but in the end the build would work: about 23 hours (or so)!! Sheesh - a 11/73 can *completely* regenerate itself from sources (all programs, manpages, etc) in about 28 hours. It was an interesting experiment but the uVax-II has sat here for 2+ years without being powered up. At one time the thought was to port 4.4BSD over but everyone that _could_ do the work lost interest - I've my PDP-11s and PPro systems to keep me busy so I haven't the time or inclination to do much with a KA630 system. For "slow" I have a PDP-11 (lots of fun, keeps you humble with the address space limits ;)). For 'fast' I have a couple dual cpu PPro systems (running BSD/OS) that can give a quad processor SUN Enterprise Server-4500 a run for their money. I have no need of a "slow" computer that attempts to run current day (bloated) software. I've toyed with the idea of swapping the innards of the 11/93 and the uVax. The KDJ11E would be a lot happier in a BA-123 than a BA-23;) But that's as far as it's gone (thinking about it). So - if anyone out there wants a uVax-II (9mb of memory but lots of disks and a 9-track tape drive to go with) drop by my place (shipping's out of the question). If you're more hardware capable than I perhaps we could swap the stuff into a BA23 (smaller enclosure to drive home, ...). Yikes and gadzooks - I was a bit verbose tonight (but my typing skills are much improved! ;-)). Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14865 for pups-liszt; Sun, 22 Nov 1998 20:31:53 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From m at mbsks.franken.de Sun Nov 22 19:28:43 1998 From: m at mbsks.franken.de (Matthias Bruestle) Date: Sun, 22 Nov 1998 10:28:43 +0100 (MET) Subject: 4.3-VAX distributions In-Reply-To: <199811220509.AAA16197@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 22, 98 00:09:52 am" Message-ID: Mahlzeit According to Michael Sokolov: > MicroVAXen, however, have tape boot capabilities built right into their > ROMs. Much easier for the installer, needless to say. Also needless to say, Does somebody know, where I can get a cheap TK50 (only the drive, the controller is still there) for my MicroVAXII? Mahlzeit endergone Zwiebeltuete -- insanity inside Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00215 for pups-liszt; Mon, 23 Nov 1998 09:30:32 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 03:42:32 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 12:42:32 -0500 Subject: 4.3-VAX distributions Message-ID: <199811221742.MAA16309@skybridge.scl.cwru.edu> Steven M. Schultz writes: > All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't > know there were any left :-) :-) I'm sure you know that domain names are case-insensitive. Also note that in the InterNIC records everything is all uppercase. As far as the mail user names go, they CAN be case-sensitive, but most OSes, even UNIX (Sendmail), try to be on the safe side and ignore the case in this context. > the base 4.3 system up to and including Tahoe couldn't be cold started > on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ > to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel > had uVax support in it but the boot stuff did not. > > With 4.3-Reno that changed but... As others have noticed the > cold start kit didn't create tapes suitable for a uVax. This change occurred in Tahoe, NOT in Reno. Trust me. If you don't, look at /usr/home/msokolov/43tahoe.cci/srcsys.tar.gz and see for yourself. > 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the > standalone programs still had compiled in partitions. The disk label support first appears in Tahoe. Again, if you don't believe me, look at /usr/home/msokolov/43tahoe.cci. > At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD [...] Ultrix v4.00, which I used to run on my main production VAX when my farm was on the net, has _ALL_ enhancements from 4.3BSD (including DNS and DBM passwd files) and most enhancements from Tahoe (including MX record support in Sendmail). Its disk label mechanism is rumored to be incompatible with Tahoe's, though (haven't had a chance to test this for myself). > [...] that DEC had corrupted > with System V(anilla) bolted on contamination. Here I agree wholeheartedly! But hey, just ignore all SysVile and DEC additions and pretend it's 4.3BSD! That's what I did. > 4.3-Reno was a transitional experiment that happened just as the CSRG > and DEC had a serious falling out - and DEC support (Vaxen) vanished > at that point. Any further work (4.4BSD) totally and completely > ignored all DEC machines. This pulled the thread that was holding everything together. Reno was the beginning of the destructive process that eventually and inevitably led to the disbanding of CSRG. Reno is the beginning of the end. One of the main reasons I don't do Reno. > Yep - you get NFS (which no 4BSD had prior to Reno). True. I will have to hack NFS into Quasijarus somehow at some point. This is not for Quasijarus1, though. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00216 for pups-liszt; Mon, 23 Nov 1998 09:30:34 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 03:42:03 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 12:42:03 -0500 Subject: 4.3-VAX distributions Message-ID: <199811221742.MAA16307@skybridge.scl.cwru.edu> Tim Shoppa writes: > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" > prompt, from which you can execute the standalone images. I know this. > "format" seems to crash badly [...] Of course! The documentation says clearly that it's for hp (780/750/8600 MASSBUS and clones) and up (RH-11 and clones) disks. > [...] but one probably doesn't need that on a Q-bus > machine :-). Has nothing to do with Q-bus, it's the distinction between SMDish disks and MSCP. But yes, for MSCP you are supposed to use the controller-specific diagnostics for formatting. For DEC ones it's a pain, but most (all?) third-party MSCP controllers have formatting utilities in their ROMs. > There are other ways to start it up. For example, using an already- > running OS (some other Unix or VMS) and copying the miniroot from tape > to the swap area of an unused disk. Here is my preferred way. It requires at least two disks. First boot from an Ultrix tape. That's the easiest thing in the world probably (assuming working hardware, of course, which I don't have right now). When you get a choice between quick installation, custom installation, and maintenance, choose the last one. This will drop you into the shell. Now you have Ultrix running in a RAM disk, you can do anything you want with your disks, and you can pull the Ultrix tape out and do anything you want with the tape drive. Then you put the BSD tape in, advance to the second file (the miniroot) with mt fsf, and dd it to partition c on one of the disks. Why partition c and not partition b? Why need two disks in the first place? Because I can bet that Ultrix and BSD will have different ideas about the default location of partition b. Then extract mdec/rdboot and mdec/bootra from the /usr tar image on the tape, cat them together, and dd them to the beginning of partition c (the miniroot as shipped doesn't have a bootblock). Then reboot from that disk. Now you have BSD running! Disklabel the other disk the way you want. This will put the bootblocks on it automatically. Then create the root and /usr filesystems on it and restore them from the tape. You are all set! True, this method imposes additional requirements (two disks and an Ultrix tape). It's also a little cumbersome (the part about the miniroot bootblocks). However, it has two advantages over the method with the tmscpboot tape. First, you can use the stock BSD tape, not a hacked one. Second, even in Reno tmscpboot supports only KA630 and not KA650. If you know VAX assembly language (I don't yet) and have a machine where you can rebuild it, you can fix this, but again you have extra requirements. Of course, the proper solution is to significantly redesign BSD's installation mechanism and make it a little more like Ultrix's. That's my plan for Quasijarus2, although Quasijarus1 will still be like Tahoe/Reno. > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) I agree wholeheartedly! A standalone disklabel program is part of my plan for Quasijarus2. Again, Quasijarus1 will still be like Tahoe/Reno. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled > code. The lifting of the filesystem limits is in Tahoe, not in Reno. When you talk about the speed of Reno's binaries, what are you comparing it to? I know for sure that there are no significant changes in the C compiler between plain 4.3, Tahoe, and Reno. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00292 for pups-liszt; Mon, 23 Nov 1998 09:40:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Mon Nov 23 08:41:31 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Mon, 23 Nov 1998 09:41:31 +1100 (EST) Subject: Minnie's new domain name In-Reply-To: <199811220300.WAA16161@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 21, 98 10:00:59 pm" Message-ID: <199811222241.JAA29811@henry.cs.adfa.oz.au> In article by Michael Sokolov: > Dear Warren, > > I see you started changing *.adfa.oz.au to *.adfa.edu.au. Should we all > start changing this in our notes, aliases, links, etc? And just out of > curiosity, what's changing? What did OZ.AU mean? Did it mean Australian > universities or what? Are you changing to EDU because that's what everyone > else uses? > > And while we are at it, what's ADFA? I thought the school's name is > UNSW, isn't it? Hi Michael, yes I should put some email out. History lesson following.... Before the Internet reached Australia, the universities had a UUCP-based mail/news system called ACSnet, where addresses were not bang-paths but @-based. The ACSnet software did the route lookups. Anyway, all ACSnet computers had a `domain' name ending in .oz, e.g kre at munnari.oz was a valid email address. When we finally got Internet-connected, our country suffix was .au. To make the transition easier, we just tacked it on to the end of the existing domain names, thus kre at munnari.oz became kre at munnari.oz.au More recently, to bring Australia in line with Internet conventions, .oz.au became .edu.au. Unfortunately, ADFA never bothered to do this switch until mid-way through this year. Over the summer break, I'll add some smarts to minnie's web server and other services to remind people to make the switch in their bookmarks, hotlinks etc. I'll keep it running indefinitely. ADFA is the Australian Defense Force Academy: it has military cadets as undergrads and civilians as postgrads. One half is run by the University of New South Wales and teaches normal civilian university stuff. I belong to this half. The other half is run by Defence, and teaches military history, how to shoot with guns etc. I'm not involved with that side at all :-) Cheers all, Warren P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00331 for pups-liszt; Mon, 23 Nov 1998 09:49:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Mon Nov 23 08:15:50 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sun, 22 Nov 1998 17:15:50 -0500 Subject: booting 4.3-reno without a tape drive Message-ID: <981122171550.2a200243@trailing-edge.com> Michael Sokolov wrote: > How soon will this happen? I'm all ready to go, but unfortunately >hardware problems are holding me back. I have solved the KA650 problem I >was having, but now I'm stuck because neither of the two TQK50 boards I >have works. (The drive SEEMS to work, though.) Thus the sooner I find a >working TQK50 board (or, alternatively, a working TK70/TQK70 pair), the >sooner will I make 4.3BSD-Quasijarus1. For a quick work-around to make a bootable 4.3 miniroot without a tape drive, Michael, you might consider the following (similar tricks will work on NetBSD distributions too): Ingredients: Microvax II Honest-to-goodness DEC disk or *fully* compatible 3rd-party disk. *Fully* compatible means that it must have the same MSCP media ID code and same number of tracks, sectors, and cylinders as a drive already hardwired into vaxuba/uda.c. These are the ones hardwired in: { MSCP_MKDRIVE2('R', 'A', 60), "ra60", ra60_sizes, 42, 4, 2382 }, { MSCP_MKDRIVE2('R', 'A', 70), "ra70", ra70_sizes, 33, 11, 1507 }, { MSCP_MKDRIVE2('R', 'A', 80), "ra80", ra80_sizes, 31, 14, 559 }, { MSCP_MKDRIVE2('R', 'A', 81), "ra81", ra81_sizes, 51, 14, 1248 }, { MSCP_MKDRIVE2('R', 'A', 82), "ra82", ra82_sizes, 57, 14, 1423 }, { MSCP_MKDRIVE2('R', 'C', 25), "rc25-removable", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE3('R', 'C', 'F', 25), "rc25-fixed", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE2('R', 'D', 52), "rd52", rd52_sizes, 18, 7, 480 }, { MSCP_MKDRIVE2('R', 'D', 53), "rd53", rd53_sizes, 18, 8, 963 }, { MSCP_MKDRIVE2('R', 'X', 50), "rx50", rx50_sizes, 10, 1, 80 }, Note that "rd54" is conspicuously missing, and I think the tabulated rd52/53 sizes are as appropriate on a RQDX2, *not* a RQDX3. Some other operating system to write the disk from (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, RT-11 and any PDP-11 CPU, etc.) The tape distribution of 43reno_vax from the PUPS archive. Specifically, you need these files: miniroot mdec/rdboot, from usr.tar mdec/bootra, from usr.tar etc/etc.tahoe/disktab, from src.tar Cooking directions: The miniroot wants to live in the swap ("b") partition of the drive. So your first task is to find the starting block number of the swap partition from the extracted "disktab". For example, for an RA81, the offset ("ob=") for an RA81 is 16422 blocks. So copy the miniroot onto the target drive starting at block 16422 (i.e. if you're under 2.11 BSD and you've partitioned the target drive, ra0, so that partition a covers the entire disk, do a "dd if=miniroot of=/dev/rra0a seek=16422 bs=512") In the "a" partition of the output drive you need a copy of "boot". The miniroot already has a filesystem with this in it, so the lazy thing to do is to just plop another copy of the miniroot, starting at block 0 on the output disk (i.e. "dd if=miniroot of=/dev/rra0a") You need the secondary bootstrap in blocks 1-15 of the target disk. Put this down with "dd if=bootra of=/dev/rra0a seek=1 bs=512" You need a block-0 boot block on the output disk. For a Microvax, this is rdboot. (I believe raboot is appropriate on a Unibus or BI-bus VAX). Lay this down with "dd if=rdboot of=/dev/rra0a" Now move the output disk to your Microvax II configuration, and boot: >>> b dua0/r5:1 2..1..0.. loading boot ra0: unlabeled Boot : ra(0,0,1)vmunix ra0: unlabeled 338756+108644+131004 start 0x238c 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 1998 PDT trent at kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot REAL MEM=16773120 und so weiter. Now, one obvious improvement to this would be to lay down a fake 4.3-ish disk label at the start of the output disk as well. This way the reliance on a fully-geometry-compatible disk might be avoided. I'll work on this in my Copious Free Time (TM). -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00512 for pups-liszt; Mon, 23 Nov 1998 10:14:17 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From norman at nose.cita.utoronto.ca Mon Nov 23 09:13:26 1998 From: norman at nose.cita.utoronto.ca (norman at nose.cita.utoronto.ca) Date: Sun, 22 Nov 1998 18:13:26 -0500 Subject: Minnie's new domain name Message-ID: <199811222314.SAA21900@chipmunk.cita.utoronto.ca> Re Warren's postscript: P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Perhaps it's time to dig up an old PDP-11? Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00626 for pups-liszt; Mon, 23 Nov 1998 10:31:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 09:43:37 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 18:43:37 -0500 Subject: booting 4.3-reno without a tape drive Message-ID: <199811222343.SAA16467@skybridge.scl.cwru.edu> Tim Shoppa writes: > For a quick work-around to make a bootable 4.3 miniroot without a > tape drive, Michael, you might consider the following (similar > tricks will work on NetBSD distributions too): > > Ingredients: > [...] > Some other operating system to write the disk from > (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, > RT-11 and any PDP-11 CPU, etc.) The last part is the problem. At this location I have only one DEC machine, and that's the KA650 I'm trying to get Ultrix on. The guy with the MV3400 (and the TK70/TQK70 pair inside it) is still out for the weekend, should hear something later this evening. If that falls through and no one helps me with a spare TQK50, I'll have to come up with another disk for this PC I'm typing this on, install FreeBSD on it, netboot NetBSD/vax, and use that to load Reno over the net onto another disk (the VAX has 5 of them). Much more painful, but still better than nothing. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00612 for pups-liszt; Mon, 23 Nov 1998 10:30:19 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 09:42:53 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 18:42:53 -0500 Subject: Minnie's new domain name Message-ID: <199811222342.SAA16465@skybridge.scl.cwru.edu> Warren Toomey writes: > Over the summer break [...] I was first thrown off by this (yesterday was officially the first snow day here in Cleveland), but then I remembered that Australia is in the southern hemisphere, so your summer is our winter, right? > I'll add some smarts to > minnie's web server and other services to remind people to make the > switch in their bookmarks, hotlinks etc. OK, will change the HostName line in my .ssh/config. I'm already using the new domain name when posting. > P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's > back now. I hate PC hardware. Then why do you use it? Why not run the PUPS/TUHS server on a VAX running 4.3BSD-Quasijarus (or 4.3BSD or 4.3BSD-Reno if you can't wait), or maybe a PDP-11 running 2.11BSD? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu P.S. Your Sendmail is still putting .oz.au in the outgoing mail headers. Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00720 for pups-liszt; Mon, 23 Nov 1998 10:40:08 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From sms at moe.2bsd.com Mon Nov 23 09:31:04 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 22 Nov 1998 15:31:04 -0800 (PST) Subject: 4.3-VAX distributions Message-ID: <199811222331.PAA18529@moe.2bsd.com> Hi - > The lifting of the filesystem limits is in Tahoe, not in Reno. When you > talk about the speed of Reno's binaries, what are you comparing it to? I > know for sure that there are no significant changes in the C compiler > between plain 4.3, Tahoe, and Reno. UH, not quite so. Unless 4.3 and Tahoe used GCC (which they did not). I'd say that there is a big difference between the 4.3 C compiler (pcc or whatever it started out as) and GCC. Tahoe, while adding support for the CCI line of computers (tried to get folks to buy one but they wouldn't go for it) did NOT use GCC (which wasn't out yet or if it was had just started making an appearance). Reno came with GCC though. The older pre-Reno compilers (being straight K&R) didn't handle prototypes - that's what you had "lint" for. Steven Schultz sms at Moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00729 for pups-liszt; Mon, 23 Nov 1998 10:41:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Mon Nov 23 02:32:07 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Sun, 22 Nov 1998 11:32:07 -0500 Subject: What *was* the Tahoe? Message-ID: <981122113207.2a2001df@trailing-edge.com> I've been looking over the 4.3BSD Tahoe and Reno distributions available in the PUPS archive, and have (what I hope) is a rather simple question: What is the "Tahoe"? It seems - based on the documentation supplied in the Tahoe-specific installation docs - that "Tahoe" generically refers to any of several VERSAbus machines in the Berkeley EECS department. The CCI (Computer Consoles Inc.) Power 6/32 is frequently mentioned as the CPU, but the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 are also mentioned. Are these all the same architecture and instruction set, or are they different? How was the CPU implemented - on a chip? On a chipset? On a board? On multiple boards? The information regarding peripherals is a bit clearer. There appear to be many different supported VERSABus SMD-drive controllers and at least one supported VERSABus 9-track controller. Are any of the Berkeley EECS Tahoe machines still up and running? How many were there? How many were outside Berkeley? Tim. (shoppa at trailing-edge.com) Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA01013 for pups-liszt; Mon, 23 Nov 1998 12:01:32 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 11:14:04 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 20:14:04 -0500 Subject: What *was* the Tahoe? Message-ID: <199811230114.UAA16563@skybridge.scl.cwru.edu> Tim Shoppa writes: > I've been looking over the 4.3BSD Tahoe and Reno distributions > available in the PUPS archive, and have (what I hope) is a rather > simple question: > > What is the "Tahoe"? I have been pondering over the same question for a LONG time, and I would love to know the answer to it, as would Rick Copeland. The ex-CSRG folks are probably the only people on the planet who know the answer, and it looks like Marshall Kirk McKusick is the only one of them on this list. Kirk, do you have any insight? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA01021 for pups-liszt; Mon, 23 Nov 1998 12:01:58 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Mon Nov 23 11:14:33 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Sun, 22 Nov 1998 20:14:33 -0500 Subject: 4.3-VAX distributions Message-ID: <199811230114.UAA16565@skybridge.scl.cwru.edu> Steven M. Schultz writes: > Reno came with GCC though. Wrong. Reno uses pcc for both VAX and Tahoe architectures, just like 4.2, 4.3, 4.3-Tahoe, and all other True UNIX(R) releases. gcc is included in the Reno distribution _as a compressed tarball_, and it's used only for the experimental and unsupported hp300 port, and that's only because there is no pcc support for it. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA01241 for pups-liszt; Mon, 23 Nov 1998 13:40:15 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From sms at moe.2bsd.com Mon Nov 23 12:26:14 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 22 Nov 1998 18:26:14 -0800 (PST) Subject: 4.3-VAX distributions Message-ID: <199811230226.SAA20820@moe.2bsd.com> Hi - > From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) > Wrong. Reno uses pcc for both VAX and Tahoe architectures, just like > 4.2, 4.3, 4.3-Tahoe, and all other True UNIX(R) releases. gcc is included Oops - I actually fired up the uVax-II (first time in almost 3 years) and typed 'gcc' and it told me 2.5.8 But as it turns out that was something I'd added later (with much work). GCC2 on a 9mb machine isn't a pretty sight so pcc is actually a "good thing" ;) Steven Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA02007 for pups-liszt; Mon, 23 Nov 1998 18:05:00 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mckusick at mckusick.com Mon Nov 23 16:05:13 1998 From: mckusick at mckusick.com (Kirk McKusick) Date: Sun, 22 Nov 1998 22:05:13 -0800 Subject: What *was* the Tahoe? In-Reply-To: Your message of "Sun, 22 Nov 1998 20:14:04 EST." <199811230114.UAA16563@skybridge.scl.cwru.edu> Message-ID: <199811230605.WAA03948@flamingo.McKusick.COM> Date: Sun, 22 Nov 1998 20:14:04 -0500 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) To: pups at minnie.cs.adfa.edu.au Subject: Re: What *was* the Tahoe? Sender: owner-pups at minnie.cs.adfa.oz.au Tim Shoppa writes: > I've been looking over the 4.3BSD Tahoe and Reno distributions > available in the PUPS archive, and have (what I hope) is a rather > simple question: > > What is the "Tahoe"? I have been pondering over the same question for a LONG time, and I would love to know the answer to it, as would Rick Copeland. The ex-CSRG folks are probably the only people on the planet who know the answer, and it looks like Marshall Kirk McKusick is the only one of them on this list. Kirk, do you have any insight? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Tahoe was the internal "code" name that Computer Consoles Inc used for their Power 6/32 processor. Many of their early changes to BSD were labelled: #ifdef tahoe to identify the 6/32 specific code. So, when we did the port we just called it Tahoe because its prime purpose was to add support for the CCI 6/32 machine. Kirk McKusick Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA02069 for pups-liszt; Mon, 23 Nov 1998 18:19:19 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From dave at fgh.geac.com.au Mon Nov 23 17:16:50 1998 From: dave at fgh.geac.com.au (Dave Horsfall) Date: Mon, 23 Nov 1998 18:16:50 +1100 (EST) Subject: What *was* the Tahoe? In-Reply-To: <199811230605.WAA03948@flamingo.McKusick.COM> Message-ID: On Sun, 22 Nov 1998, Kirk McKusick wrote: > Tahoe was the internal "code" name that Computer Consoles Inc used > for their Power 6/32 processor. Many of their early changes to BSD > were labelled: > #ifdef tahoe > to identify the 6/32 specific code. So, when we did the port we > just called it Tahoe because its prime purpose was to add support > for the CCI 6/32 machine. And, as I recall (I used to work for STC Australia who sold 'em) it had the instruction set of a Vax, but backwards, if you know what I mean... The CPU was five boards, something like integer card plus FPU card plus priority arbitrator card etc. -- Dave Horsfall VK2KFU dave at geac.com.au Ph: +61 2 9978-7493 Fx: +61 2 9978-7422 Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA03974 for pups-liszt; Tue, 24 Nov 1998 03:38:04 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From SHOPPA at trailing-edge.com Tue Nov 24 02:05:52 1998 From: SHOPPA at trailing-edge.com (SHOPPA at trailing-edge.com) Date: Mon, 23 Nov 1998 11:05:52 -0500 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <981123110552.2a200243@trailing-edge.com> >Tahoe was the internal "code" name that Computer Consoles Inc used >for their Power 6/32 processor. That's useful. The Tahoe-specific documentation also mentions the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were these in any way compatible with the Tahoe, or just "other" ports? And where does "Reno" come from, while we're at it? Tim. (shoppa at trailing-edge.com) Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA04103 for pups-liszt; Tue, 24 Nov 1998 04:15:51 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rdkeys at seedlab1.cropsci.ncsu.edu Tue Nov 24 03:09:28 1998 From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys) Date: Mon, 23 Nov 1998 12:09:28 -0500 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811220509.AAA16197@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 22, 98 00:09:52 am" Message-ID: <199811231709.MAA09886@seedlab1.cropsci.ncsu.edu> > > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > > It's the most reasonable approach I can think of at the moment. > > That's close to what I'm doing. There are two differences, though. > First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > between Tahoe and Reno. The latter is really huge, it's a gap between True > UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be > building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus > KA650 support and shadow passwords from Reno and other improvements from > both later CSRG code and my own brain. SCCS will be the #1 tool in the > process. Speaking of crusades.....(:+}}.... I sometimes feel like the orphan child running BSD on the old IBM RT (I know, not a biggie vaxen iron, but that is what I have and the cap that I don). It is not too bad running 16M ram and a 20'' megapel color monitor, but the RISC processor is running around 12mhz on an ISA bus which is not very fast. I am curious, though, about the releases of BSD for the old RT. Few on the net know anything about them anymore, and docs are nil. I asked around IBM, and sort of drew dumb quizzled looks, as if it had vaporized long ago. I have uncovered three discrete distributions, one labelled IBM, and two non-labelled, but which were apparently out of IBM or related to IBM in some way, maybe after IBM dropped AOS, but I am not sure. The background of it all is a mystery. The first is a ``build 0'' thing called AOS or AOS/4.3, and it appears to be a somewhat vanilla 4.3BSD, or possibly might be as late as Tahoe. It has pcc and a Metaware C compiler, and is not very strange. Other than the compilers being somewhat broken and the time never correct, it runs well, and feels like 4.3. The second is a ``build 16'' and labelled Reno, but is running gcc and related things. My suspicion is that it is a 4.4, but I am not sure. It seems fairly plain and following the 4.4 docs pretty well. I don't think it is really Reno, but was named that by someone back in time for some developmental reason maybe having been started from a Reno tree, although I am not sure. The third is a ``build 433'' and labelled Lite, and seems to be somewhat straight 4.4 and somethat Lite (has two intermixed source trees), and is gigabyte in size, and rather strangely laid out. It may have been the last build for the RT. Unfortunately, original tapes and documents for these are long gone, and I have only been able to pick up bits and pieces here and there. I don't find mention of these ports anywhere in the usual docs, other than a slight hint that they existed at one time. Supposedly, bits are on a mystical CD that is reputed to exist, and I have heard of two actual CD's that may have survived. I have spent the last 6 months resurrecting the ports, and basically have a reliable 4.3 running, a running but somewhat broken ``Reno'' or whatever it is (of all things vi is only 99% operational because of terminal driver problems), and a broken but somewhat running ``4.4/4.4Lite'' or whatever that really is (it boots and barely stays up, but I have been working on making it stay up). Does anyone on the PUPS list remember what these things actually are, and what level they are actually at? My historical curiosity is getting the better of me, and like Michael, I tend to like the plain model-T spartan simplicity of a 4.3 style machine. There really is a large bloat between the 4.3 and 4.4 levels in my stuff, too. What is responsible for the differences in the bloat? I get binaries about half the size in 4.3 compared to the 4.4whatevers I have. Is that just a function of gcc and how it codes things or libraries? Anyway, it has been a most refreshing learning experience getting these things up and running again. Is there any interest on the list to archive the ports that I have? Warren? Out of curiosity, again, anyone else on the PUPS list running RT iron or am I the last holdout? The few RT folks that I am familiar with are all running AIX still, although they remember the BSDs. So much seems to have been lost, already, or most of the machines have become dumpster fodder. Any insights, history, or horror stories about the old RT BSD ports are most welcome. Thanks Bob Keys Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA04175 for pups-liszt; Tue, 24 Nov 1998 04:35:28 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 03:47:58 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 12:47:58 -0500 Subject: 4.3/4.4 IBM distributions (need history) Message-ID: <199811231747.MAA16896@skybridge.scl.cwru.edu> "User Rdkeys Robert D. Keys" writes: > I am curious, though, about the releases of BSD for the old RT. The University of California at Berkeley has never made any releases for IBM RT and nor will I, so there are no BSD releases for IBM RT. > There really is > a large bloat between the 4.3 and 4.4 levels in my stuff, too. What > is responsible for the differences in the bloat? I have heard jokes that CSRG got Microsoft to rewrite 90% of the code for them. Seriously, though, the bloat starts in Reno and really gets out of hand in 4.4. The sources are bloated just as much as the binaries, so I wouldn't blame it just on the compiler or the libraries. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04299 for pups-liszt; Tue, 24 Nov 1998 05:06:39 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From pat at transarc.com Tue Nov 24 04:05:13 1998 From: pat at transarc.com (Pat Barron) Date: Mon, 23 Nov 1998 13:05:13 -0500 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811231709.MAA09886@seedlab1.cropsci.ncsu.edu> Message-ID: I think there were some additional licensing restrictions on AOS (e.g., only available to educational institutions), so it might not be includable in the archive. I can probably track down folks in Palo Alto who worked AOS, and find out. As far as I know, there was never an "official" ACIS release beyond the 1988 4.3BSD release. I have actual distribution tapes around somewhere, and could probably make tape images available if it's determined that that's OK. --Pat. P.S. We just dumpster-ized about 6 or 8 RTs from our storage facility in the last couple of weeks - I had tried to give them away, but the person who was lined up to take them didn't move quite fast enough, and the person assigned to storage clean-up got tired of having them around ... :-( Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04329 for pups-liszt; Tue, 24 Nov 1998 05:08:33 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 04:20:43 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 13:20:43 -0500 Subject: What *was* the Tahoe? Message-ID: <199811231820.NAA16912@skybridge.scl.cwru.edu> Dave Horsfall writes: > And, as I recall (I used to work for STC Australia who sold 'em) it > had the instruction set of a Vax [...] Aha! I always suspected that the Tahoe architecture was somehow related to VAXen, I just didn't know how. Now we all know... > [...] but backwards, if you know what I > mean... I have noticed that the Tahoe architecture is big-endian (I use this to easily tell between VAX and Tahoe binaries and filesystem dumps). Is this what you mean? Or is there any more backwardness? > The CPU was five boards, something like integer card plus > FPU card plus priority arbitrator card etc. At least the FPU card was optional, since the Tahoe code in BSD has a emulator for it. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04317 for pups-liszt; Tue, 24 Nov 1998 05:07:56 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 04:20:15 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 13:20:15 -0500 Subject: 4.3-VAX distributions Message-ID: <199811231820.NAA16910@skybridge.scl.cwru.edu> Steven M. Schultz writes: > GCC2 on a 9mb machine isn't a pretty sight so pcc is actually a "good > thing" ;) It's _ALWAYS_ a good thing, because it's DIVINE (written by Bell Labs Gods themselves), while gcc and others are mere mortals. Actually, gcc is even worse than a mere mortal, since it's GNU. It comes directly from the Inferno. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04343 for pups-liszt; Tue, 24 Nov 1998 05:09:07 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 04:21:18 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 13:21:18 -0500 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <199811231821.NAA16914@skybridge.scl.cwru.edu> Tim Shoppa writes: > That's useful. The Tahoe-specific documentation also mentions > the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were > these in any way compatible with the Tahoe, or just "other" > ports? Well, they have to be compatible somehow, since the same BSD tape was used for all of them. Actually, there is much more to it. The Tahoe architecture was specifically designed for BSD. CCI first made a vendor release for their machines, kinda like SunOS and Ultrix, based on 4.2BSD. Then some time after the 4.3BSD release CSRG designed to integrate CCI's changes into the mainstream BSD tree. The result was named 4.3BSD-Tahoe. What's interesting is that 4.3BSD-Tahoe does not have any bootblocks for the Tahoe architecture, and the documentation often refers to the BSD kernels being loaded by the system ROM on Tahoe. As you can imagine, having the system ROM load your OS's kernels is one hell of a requirement, and the Harris and Unisys machines would have to REALLY compatible with the CCI for this to work. My guess would be that they were identical clones, just like the PC clones that run unmodified PC-DOS. > And where does "Reno" come from, while we're at it? If I'm not mistaken, there is a city somewhere on the west side of the U.S. called Tahoe/Reno. The BSD developers probably thought "OK, we already have Tahoe, let's have Reno too." Reno also probably stands for "renovation", although IMHO sawing the branch you are sitting on is pretty damn stupid and certainly doesn't qualify as "renovation". Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA04486 for pups-liszt; Tue, 24 Nov 1998 05:49:13 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rdkeys at seedlab1.cropsci.ncsu.edu Tue Nov 24 04:42:50 1998 From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys) Date: Mon, 23 Nov 1998 13:42:50 -0500 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: from Pat Barron at "Nov 23, 98 01:05:13 pm" Message-ID: <199811231842.NAA10244@seedlab1.cropsci.ncsu.edu> > I think there were some additional licensing restrictions on AOS (e.g., > only available to educational institutions), so it might not be > includable in the archive. I can probably track down folks in Palo Alto > who worked AOS, and find out. It might be good to find out any info or history or whatever, if anyone still knows anything. If IBM does not particularly want it, it might be nice to add to the archives, as an educational one-up on Gates. > As far as I know, there was never an "official" ACIS release beyond the > 1988 4.3BSD release. I have actual distribution tapes around somewhere, > and could probably make tape images available if it's determined that > that's OK. Then what are the `Reno' and `Lite' builds that I have. I was assuming they were all related, or were there other ports done outside IBM? Now I am less clear on what it is I actually have...... > P.S. We just dumpster-ized about 6 or 8 RTs from our storage facility > in the last couple of weeks - I had tried to give them away, but > the person who was lined up to take them didn't move quite fast > enough, and the person assigned to storage clean-up got tired of > having them around ... :-( Darn! Always one step behind and two weeks late..... If there are any leftover AOS docs, or any leftover boards, particularly the external ESDI, SCSI, TAPE, or ethernet boards, or any leftover mice, that would be nice to locate. Also, a spare tape drive would not hurt. Dupster fodder......(:+{{..... Bob Keys Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA04591 for pups-liszt; Tue, 24 Nov 1998 06:17:42 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 24 05:27:21 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 23 Nov 1998 11:27:21 -0800 Subject: BSD Network Version 2 upload Message-ID: <3.0.32.19981123112715.0092ed20@pop.calweb.com> PUPS List, I have just put BSD Network Version 2 up on Minnie in the incoming directory. This is from a tape passed to me from Mr. Kirk McKusick. The file includes a readme and is zipped with WinZip version 6.22. Sincerely, Rick Copeland Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA04712 for pups-liszt; Tue, 24 Nov 1998 06:37:33 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From allisonp at world.std.com Tue Nov 24 05:37:17 1998 From: allisonp at world.std.com (Allison J Parent) Date: Mon, 23 Nov 1998 14:37:17 -0500 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <199811231937.AA08069@world.std.com> < U.S. called Tahoe/Reno. The BSD developers probably thought "OK, we alre < have Tahoe, let's have Reno too." Reno also probably stands for < "renovation", although IMHO sawing the branch you are sitting on is pret < damn stupid and certainly doesn't qualify as "renovation". Tahoe is Lake Tahoe California, Reno is in Nevada. The connection is the two of the cities are connected by I80, The same road you'd take to get from Boston to Berkeley. Lake Tahoe is a resort area in the mountains about 50miles (or so) west of Reno. In those cities sawing the branch your sitting on may well be a paying bet or a reason to party. Allison Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA04837 for pups-liszt; Tue, 24 Nov 1998 07:25:36 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 24 06:34:05 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 23 Nov 1998 12:34:05 -0800 Subject: Reno (was Re: What *was* the Tahoe?) Message-ID: <3.0.32.19981123123403.0091b220@pop.calweb.com> At 02:37 PM 11/23/98 -0500, Allison J Parent wrote: >< U.S. called Tahoe/Reno. The BSD developers probably thought "OK, we alre >< have Tahoe, let's have Reno too." Reno also probably stands for >< "renovation", although IMHO sawing the branch you are sitting on is pret >< damn stupid and certainly doesn't qualify as "renovation". > >Tahoe is Lake Tahoe California, Reno is in Nevada. The connection is >the two of the cities are connected by I80, The same road you'd take to >get from Boston to Berkeley. Lake Tahoe is a resort area in the mountains >about 50miles (or so) west of Reno. > >In those cities sawing the branch your sitting on may well be a paying >bet or a reason to party. > >Allison Well since I live so close to Lake Tahoe and Reno (Sacramento is half way between Tahoe and Berkeley) I have got to get my two cents in here. My guess is that Berkeley is well known as a pro party University and Reno and Tahoe are the main party spots on the west cost! Sounds right to me! Rick Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA04939 for pups-liszt; Tue, 24 Nov 1998 08:04:14 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 07:16:41 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 16:16:41 -0500 Subject: BSD Network Version 2 upload Message-ID: <199811232116.QAA17086@skybridge.scl.cwru.edu> Rick Copeland writes: > I have just put BSD Network Version 2 up on Minnie in the incoming > directory. Warren, I think this one should go into minnie's anonymous FTP area, since it does not require a UNIX license and was specifically designed to be publicly distributable. I didn't do any repacking on it in my home directory, since it's just one big tarball. I've done a tar tvf on the tarball, though, and the listing produced is in /usr/home/msokolov/NET2.lst on minnie. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA05240 for pups-liszt; Tue, 24 Nov 1998 09:16:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 08:17:39 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 09:17:39 +1100 (EST) Subject: 4.3/4.4 IBM distributions (need history) In-Reply-To: <199811231709.MAA09886@seedlab1.cropsci.ncsu.edu> from "User Rdkeys Robert D. Keys" at "Nov 23, 98 12:09:28 pm" Message-ID: <199811232217.JAA03246@henry.cs.adfa.oz.au> In article by User Rdkeys Robert D. Keys: > I am curious, though, about the releases of BSD for the old RT. > I have uncovered three discrete distributions, one labelled IBM, > and two non-labelled, but which were apparently out of IBM or related > to IBM in some way, maybe after IBM dropped AOS, but I am not sure. > The background of it all is a mystery. > > Is there any interest on the list to archive the ports that I have? > Warren? I tell you what, Bob. I'll mirror whatever you've got :-) But you'll have to organise it and write the READMEs! Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA05265 for pups-liszt; Tue, 24 Nov 1998 09:18:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 08:19:29 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 09:19:29 +1100 (EST) Subject: 4BSD bloat In-Reply-To: <199811231747.MAA16896@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 23, 98 12:47:58 pm" Message-ID: <199811232219.JAA03263@henry.cs.adfa.oz.au> In article by Michael Sokolov: >I have heard jokes that CSRG got Microsoft to rewrite 90% of the code for them. >Seriously, though, the bloat starts in Reno and really gets out of hand in 4.4. >The sources are bloated just as much as the binaries, so I wouldn't blame it >just on the compiler or the libraries. I can hear Steven Schultz say that the address space limitations of a 16-bit architecture help to minimise software bloat :-) Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA05725 for pups-liszt; Tue, 24 Nov 1998 10:44:18 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From rickgc at calweb.com Tue Nov 24 09:53:48 1998 From: rickgc at calweb.com (Rick Copeland) Date: Mon, 23 Nov 1998 15:53:48 -0800 Subject: Upload BSD4.3 Rev. 2, Foreign Master Message-ID: <3.0.32.19981123155338.00935c40@pop.calweb.com> Dear PUPS list, I have up loaded to Minnie the "BSD4.3 Revision 2 for VAX, Foreign Master" passed to me by Mr. Kirk McKusick. This tape image is zipped with WinZip 6.22 and includes a readme file. Sincerely, Rick Copeland Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA06184 for pups-liszt; Tue, 24 Nov 1998 12:03:08 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 11:04:26 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 12:04:26 +1100 (EST) Subject: Upload BSD4.3 Rev. 2, Foreign Master In-Reply-To: <3.0.32.19981123155338.00935c40@pop.calweb.com> from Rick Copeland at "Nov 23, 98 03:53:48 pm" Message-ID: <199811240104.MAA03819@henry.cs.adfa.oz.au> In article by Rick Copeland: > Dear PUPS list, > > I have up loaded to Minnie the "BSD4.3 Revision 2 for VAX, Foreign Master" > passed to me by Kirk McKusick. > Rick Copeland It's now available in Distributions/4bsd/43rev2 in the PUPS Archive. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA06315 for pups-liszt; Tue, 24 Nov 1998 12:21:31 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From simul8 at simul8.demon.co.uk Tue Nov 24 11:15:24 1998 From: simul8 at simul8.demon.co.uk (James Lothian) Date: Tue, 24 Nov 1998 01:15:24 -0000 Subject: 4.3-VAX distributions Message-ID: <01BE1748.F7E9EE60@SONAR> Just thought I'd throw my oar in: my 11/750 is currently running a version of 4.3 taken off a set of tapes I saved from being thrown out by a Uni department I used to work for. The labels on the tapes say: Ultrix 4.3+NFS Wisconsin UNIX 1/15/87 And another label says: * The contents of this tape are distributed to UNIX/32V, System 3 or System 5, and SUN 3.0 NFS licencees only, subject to your software agreement with AT&T (Western Electric), your license agreement with the Regents of the University of California, and your license agreement with SUN Microsystems. * The University of Wisconsin - Madison Computer System Laboratory assumes no responsibility for unauthorized use of these contents by non-licensed entities. RCS strings seem to indicate that the code was maintained by someone called Tad Lebeck. As far as I can tell, it's mainly a fairly stock early 4.3 with no disk-labels, with all the sun rpc/yp/nfs stuff grafted on and a whole lot of bugs that I've had no end of fun fixing. Does anybody know anything about the history of this version? In particular, does it bear any real relation to Ultrix, or is the tape just mis-labelled? If anybody else out there is running this thing and wonders why ptrace(2) causes such mayhem, or why portmap crashes when they try to run YP, I'd be happy to supply patches.... James Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA06440 for pups-liszt; Tue, 24 Nov 1998 12:49:02 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From eekg at ix.netcom.com Tue Nov 24 11:40:51 1998 From: eekg at ix.netcom.com (Eric Edwards) Date: Mon, 23 Nov 1998 20:40:51 -0500 Subject: What *was* the Tahoe? Message-ID: <002e01be174b$8a9ec6c0$2dd1b7c7@#eekg.ix.netcom.com> The Power 6/32 Tahoe was a product of Computer Consoles Inc. (CCI). The internal codename was "Tahoe", as all the CCI processors were named after lakes in the US (others I can remember were Erie and Huron). It was originally intended to compete with the VAX-11/780 - depending on the benchmark it was 5 to 10 times faster than the VAX and much smaller and cheaper. The base processor consisted of 5 boards - implemented with AMD 2900 series bit slice processors, PLAs and 74F series parts. Surprisingly the bit-slice processors were used in the MMU - the actual ALU was 74F181s. It was a big endian machine that was sort of a cross between a VAX and a Motorola 68K. As mentioned elsewhere, it is rumored that if you swap the nibbles in the instruction bytes they end up the same as the VAX... I think it also had some odd features: the cache was on the processor side of the mmu -- so it was indexed by virtual address and instructions were cached in microcode form. As guessed from the lack of boot blocks, there was another board in the system -- the Console Processor (CP). It was a 68000 based Versabus single board computer. The boot monitor understood BSD filesystems on both tape and disk. It basically loaded the microcode into the CPU, loaded the boot image (/boot?) into memory, and then started the main CPU. CCI ported 4.2BSD to run on the Tahoe and the changes were rolled into the 4.3-Tahoe version. They also ran System V (including a dual processor version) and CCI's own fault-tolerant Unix - Perpos. I think the last of the Berkeley Tahoe machines ended up at Rochester Institute of Technology's Computer Science House (http://www.csh.rit.edu). Some guys up there were attempting to do some work with 4.4BSD and the Tahoe. I can probably dig up more information if anyone needs it... -----Original Message----- From: SHOPPA at trailing-edge.com To: PUPS at MINNIE.CS.ADFA.EDU.AU Date: Sunday, November 22, 1998 6:47 PM Subject: What *was* the Tahoe? > What is the "Tahoe"? >Tim. (shoppa at trailing-edge.com) > Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06491 for pups-liszt; Tue, 24 Nov 1998 13:04:41 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 12:17:16 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 21:17:16 -0500 Subject: BSD Network Version 2 upload Message-ID: <199811240217.VAA17227@skybridge.scl.cwru.edu> J. Joseph Max Katz writes: > Does Net/2 produce a completely working binary system? No. It contains only the sources, and if you try to build it, you'll get stuck immediately because about half of the source files were simply deleted. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06512 for pups-liszt; Tue, 24 Nov 1998 13:05:26 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 12:18:03 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 21:18:03 -0500 Subject: BSD Network Version 2 upload Message-ID: <199811240218.VAA17230@skybridge.scl.cwru.edu> Warren Toomey writes: > I'll check with SCO That's a good idea. Please let us know what they say. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06533 for pups-liszt; Tue, 24 Nov 1998 13:07:12 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 12:19:49 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 21:19:49 -0500 Subject: 4.3-VAX distributions Message-ID: <199811240219.VAA17236@skybridge.scl.cwru.edu> When I wrote in a previous message: > Actually, gcc is even worse than a mere mortal, > since it's GNU. It comes directly from the Inferno. I didn't know that Lucent has a product named Inferno, as some people have pointed out to me. In any case, I meant the actual Inferno, also known as Hell, i.e., the fifth dimension of the Universe inhabited and ruled by Satan, not the Lucent product. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA06745 for pups-liszt; Tue, 24 Nov 1998 14:27:45 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Tue Nov 24 13:27:57 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Tue, 24 Nov 1998 14:27:57 +1100 (EST) Subject: BSD Network Version 2 upload In-Reply-To: <199811240218.VAA17230@skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 23, 98 09:18:03 pm" Message-ID: <199811240327.OAA04039@henry.cs.adfa.oz.au> In article by Michael Sokolov: > Warren Toomey writes: > > I'll check with SCO [what their stance is on the Net/2 tape] > > That's a good idea. Please let us know what they say. Dion at SCO doesn't even know what Net/2 is. I've sent him some details. He wants to know exactly what the settlement was between USL and UCB in regards to the Net/2 tape. I don't have the exact particulars here (just a News article from Keith Bostic), so I've asked Kirk if he could give me the exact ruling. I'll pass on any words from SCO to the mailing list as I receive them. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA06960 for pups-liszt; Tue, 24 Nov 1998 14:50:10 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From dave at fgh.geac.com.au Tue Nov 24 13:47:41 1998 From: dave at fgh.geac.com.au (Dave Horsfall) Date: Tue, 24 Nov 1998 14:47:41 +1100 (EST) Subject: What *was* the Tahoe? In-Reply-To: <199811231820.NAA16912@skybridge.scl.cwru.edu> Message-ID: On Mon, 23 Nov 1998, Michael Sokolov wrote: > I have noticed that the Tahoe architecture is big-endian (I use this to > easily tell between VAX and Tahoe binaries and filesystem dumps). Is this > what you mean? Or is there any more backwardness? It's basically a big-endian Vax. When disassembling code, I never knew whether to wear my Vax hat or my Motorola hat :-) I believe that the Harris 7, the ICL Clan etc were just badge-engineered. Nice machine, and no relation to the CCI 5/32 and the 5/32X (680x0) other than the manufacturer. > At least the FPU card was optional, since the Tahoe code in BSD has a > emulator for it. And the Ethernet card cost AU$10,000 (ca. 80s). It had a STUPID ribbon cable connector to the D15 socket; misalign it by one pin (easy to do), since there was no key; you had to count 13 pins down) and you blew the card. I did, once... -- Dave Horsfall VK2KFU dave at geac.com.au Ph: +61 2 9978-7493 Fx: +61 2 9978-7422 Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA09053 for pups-liszt; Tue, 24 Nov 1998 17:50:38 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mxs46 at k2.scl.cwru.edu Tue Nov 24 17:03:05 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Tue, 24 Nov 1998 02:03:05 -0500 Subject: 4.3BSD Rev 2 Foreign Message-ID: <199811240703.CAA17330@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, I have analyzed Rick's 4.3BSD Rev 2 Foreign images in Distributions/4bsd/43rev2 and converted them into the standard BSD release format used by me as the maintainer of 4.3BSD. I didn't change the contents of any files, I just gave the directory and all files their systematic names (being systematic and punctual in packaging and naming is essential to maintaining an archive of many different versions of software). I also uncompressed and recompressed all files so that the names stored inside the gzip headers are correct. Finally, I have created a tar tvf listing for every tarball. The result is in /usr/home/msokolov/43rev2_f. Warren, please put this into the main PUPS archive. Note, though, that usr.tar (file 4) is cut short. I have indicated this in the BROKEN.TXT file. Also this is a "foreign" tape, meaning that it has a slightly crippled crypt(3) and missing crypt(1). Given that this tape is both a little broken and "foreign", CWRU's 4.3BSD tape images in /usr/home/msokolov/43.vax may be a better choice for some people. They have normal crypt(3) and crypt(1) and have absolutely no defects. (That's the advantage of 1600 BPI over 6250 BPI. Rick seems to be having a really hard time reading 6250 BPI 4.3 and 4.3-Tahoe tapes, while CWRU's 1600 BPI 4.3BSD tapes read fine on the first attempt.) Rick's ones are Rev 2, though, and CWRU's are not. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA10697 for pups-liszt; Tue, 24 Nov 1998 21:46:42 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From A.F.R.Bain at dpmms.cam.ac.uk Tue Nov 24 20:46:15 1998 From: A.F.R.Bain at dpmms.cam.ac.uk (Alan F R Bain) Date: Tue, 24 Nov 1998 10:46:15 +0000 Subject: Version 7 for the PERQ Message-ID: A question which I have been meaning to ask for a while and which I was reminded of by the discussion of the AMD 2900 bit slice processors was a version of AT&T V7 unix for the ICL PERQ computer. This was so similar to the original that the manual was an original AT&T one with instructions on which pages to pull out and throw away and some new ones to insert. [basically all PDP11 hardware specific ones go; and there are some new bits such as chatter as simple serial comms program]. I have several binary only distributions of this -- it was called PNX. What I'd be really interested to know is how it evolved from V7; in particular the new version of `m40.s'. In particular it seems to run on top of a rather weird instruction set which isn't very like that of the PDP11 (which would have seemed like an obvious choice at first sight for a soft-microcodeable machine). The use of as and cc with options to write out assembler is considered as `not a user option' in the manual; although it still works. I have to say that in general the port seems quite bad and in need of lots of work to make it correctly functional. However it's nice to have V7 readily available on a graphics workstation with 1Mb RAM and 768x1024 display :-) I'd be very interested to find out more of the source to PNX or especially the microcode Alan Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA12215 for pups-liszt; Wed, 25 Nov 1998 04:53:20 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From mckusick at mckusick.com Wed Nov 25 02:19:01 1998 From: mckusick at mckusick.com (Kirk McKusick) Date: Tue, 24 Nov 1998 08:19:01 -0800 Subject: Reno (was Re: What *was* the Tahoe?) In-Reply-To: Your message of "Mon, 23 Nov 1998 11:05:52 EST." <981123110552.2a200243@trailing-edge.com> Message-ID: <199811241619.IAA07519@flamingo.McKusick.COM> From: SHOPPA at trailing-edge.com Date: Mon, 23 Nov 1998 11:05:52 -0500 To: PUPS at minnie.cs.adfa.oz.au Subject: Reno (was Re: What *was* the Tahoe?) Sender: owner-pups at minnie.cs.adfa.oz.au >Tahoe was the internal "code" name that Computer Consoles Inc used >for their Power 6/32 processor. That's useful. The Tahoe-specific documentation also mentions the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 - were these in any way compatible with the Tahoe, or just "other" ports? And where does "Reno" come from, while we're at it? Tim. (shoppa at trailing-edge.com) The 4.3-Reno distribution was named after the city of that name in Nevada. We picked that name because the 4.3-Reno distribution was an interim release on the way to 4.4BSD and hence was not as fully polished or tested as our production releases. The idea was to remind recipients that it was more of a "gamble" to run Reno than our production releases. Kirk McKusick Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13346 for pups-liszt; Wed, 25 Nov 1998 10:03:30 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 09:05:02 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 10:05:02 +1100 (EST) Subject: Net2 Status: likely outcome Message-ID: <199811242305.KAA05334@henry.cs.adfa.oz.au> I haven't heard back from SCO re the Net/2 status, but given that USL was sold to Novell & then to SCO, and they have copies of all the legal documents, I'm sure that SCO will quickly find out the details of the USL vs UCB settlement. Kirk has told me that the settlement explicitly stated that a set of files from Net/2 was not to be distributed, and that this set of files was not to be revealed: this was done to prevent a subset of Net/2 from being freely redistributed. CSRG made changes to about 70 files and deleted three files outright. Kirk is legally unable to reveal the list of affected files in Net/2. I've just had a poke around the SCCS files on CD#4 on the CSRG CD set. Several of the SCCS comments for the kernel files have the word USL in them: add USL's copyright notice changes for 4.4BSD-Lite requested by USL There's also a list of binary-only files in BSD/386 1.1 at http://www.bsdi.com/info/lawsuit/940208.update I assume, therefore, that it wouldn't be too hard to find out the set of files in Net/2 affected by the settlement. Therefore, once SCO reads through the legal documents (which they now own), I'd be pretty sure that they will still treat Net/2 as contaminated, and people will need a 32V license in some form in order to legally acquire a copy of the Net/2 tape. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13502 for pups-liszt; Wed, 25 Nov 1998 10:54:36 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 09:56:09 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 10:56:09 +1100 (EST) Subject: Also: PUPS digest mail list Message-ID: <199811242356.KAA05513@henry.cs.adfa.oz.au> I should also say that there's a digest form of the PUPS/TUHS mail list which comes out twice weekly. If you'd rather be on that list, please send me some email. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA13797 for pups-liszt; Wed, 25 Nov 1998 11:58:43 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 11:00:17 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 12:00:17 +1100 (EST) Subject: Net/2: still at ftp.uu.net Message-ID: <199811250100.MAA05738@henry.cs.adfa.oz.au> Just FYI, net/2 afficionados might care to look around in ftp://ftp.uu.net/systems/unix/bsd-sources I assume that they are in a legally dubious situation. Warren From wkt at henry.cs.adfa.oz.au Wed Nov 25 11:23:26 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 12:23:26 +1100 (EST) Subject: Net/2: still at ftp.uu.net In-Reply-To: from "J. Joseph Max Katz" at "Nov 24, 98 05:17:48 pm" Message-ID: <199811250123.MAA06173@henry.cs.adfa.oz.au> In article by J. Joseph Max Katz: > They may have the sources rm'd that aren't supposed to be there. As far as I can tell (at a quick glance), the distribution is intact. I'm just comparing cksums between the Net/2 on the CSRG CD#2 and from the ftp site. I'm only doing sys/kern and sys/ufs. Absolutely no difference. diff on all file pairs gives no output. cksum gives the same checksums for each file pair (CD vs ftp). Hmm..... Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA14564 for pups-liszt; Wed, 25 Nov 1998 13:24:57 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups at minnie.cs.adfa.oz.au using -f From wkt at henry.cs.adfa.oz.au Wed Nov 25 12:20:41 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Wed, 25 Nov 1998 13:20:41 +1100 (EST) Subject: Net/2: still at ftp.uu.net In-Reply-To: <01BE1817.1E6F2EF0@SONAR> from James Lothian at "Nov 25, 98 01:58:33 am" Message-ID: <199811250220.NAA06820@henry.cs.adfa.oz.au> In article by James Lothian: > In the UK, sunsite.doc.ic.ac.uk has a directory > /computing/systems/unix/4.3bsd-net2, which > seems to be all the unencumbered bits of net/2. > James It appears that several files from sys/kern and sys/ufs have been removed. All files still in these directories are intact. I haven't examined any other directories. They're in a safer legal position. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA15323 for pups-liszt; Wed, 25 Nov 1998 17:22:44 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) From mxs46 at k2.scl.cwru.edu Wed Nov 25 16:35:15 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 25 Nov 1998 01:35:15 -0500 Subject: Net2 Status: likely outcome Message-ID: <199811250635.BAA17893@skybridge.scl.cwru.edu> Warren Toomey writes: > Therefore, once SCO reads through the legal documents (which they now > own), I'd be pretty sure that they will still treat Net/2 as > contaminated, and people will need a 32V license in some form in order to > legally acquire a copy of the Net/2 tape. Then until/unless Warren tells me otherwise, I'll keep Net/2 together with the real 4BSD distributions in Distributions/4bsd/net2, readable by the members of the pupsarc group only. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA15311 for pups-liszt; Wed, 25 Nov 1998 17:22:17 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) From mxs46 at k2.scl.cwru.edu Wed Nov 25 16:34:48 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 25 Nov 1998 01:34:48 -0500 Subject: 4BSD distributions Message-ID: <199811250634.BAA17891@skybridge.scl.cwru.edu> Dear PUPS/TUHS members, All 4BSD distributions formerly in my home directory on minnie are now in the Distributions/4bsd directory. This directory is now owned by me, and from now on I will be maintaining PUPS's 4BSD collection. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id EAA17141 for pups-liszt; Thu, 26 Nov 1998 04:48:09 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.oz.au) From mxs46 at k2.scl.cwru.edu Thu Nov 26 04:00:30 1998 From: mxs46 at k2.scl.cwru.edu (Michael Sokolov) Date: Wed, 25 Nov 1998 13:00:30 -0500 Subject: What *was* the Tahoe? Message-ID: <199811251800.NAA18075@skybridge.scl.cwru.edu> Wortner, Frank (RSCH) writes to me: > P.S. You might want to forward this to the PUPS list, since I'm no longer > an active member (emal address changes, etc.) Doing so. Forwarded message: >From Frank_Wortner at ml.com Wed Nov 25 11:31 EST 1998 Return-Path: From Frank_Wortner at ml.com Thu Nov 26 02:27:07 1998 From: Frank_Wortner at ml.com (Wortner, Frank (RSCH)) Date: Wed, 25 Nov 1998 11:27:07 -0500 Subject: What *was* the Tahoe? Message-ID: This one I know the answer to. "Tahoe" was the internal name for a computer called the "Compter Consoles Inc. 632." (At least that's what I recall." The machine itself was a light grey cube about the size of a VAX 750 CPU. The cube housed the CPU, the disk drives (Fujitsu "Super Eagles" I think) and an auto-loading tape drive. If I recall correctly, the manufacturer was located in Rochester, New York, USA. I used to sys admin one of these beasts -- a *long* time ago. They were pretty durable: mine not only survived an air condioner failure during which the temperature rose to more than 100 degrees Fahrenheit, it actually kept on working without a break for several hours! It was a good box, an attempt at a "VAX-killer," but it never really managed to grab a substantial base from DEC's boxes. Frank P.S. You might want to forward this to the PUPS list, since I'm no longer an active member (emal address changes, etc.) From wkt at henry.cs.adfa.oz.au Thu Nov 26 11:54:34 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Thu, 26 Nov 1998 12:54:34 +1100 (EST) Subject: Over 100 Ancient UNIX Licenses Message-ID: <199811260154.MAA08304@henry.cs.adfa.oz.au> All, I've just received another 5 SCO Ancient UNIX license details in the mail, bringing the total purchased from SCO to 101. I think that's pretty impressive. Just thought you'd like to know. Cheers all, Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA22073 for pups-liszt; Fri, 27 Nov 1998 03:52:43 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From SHOPPA at trailing-edge.com Fri Nov 27 02:50:34 1998 From: SHOPPA at trailing-edge.com (Tim Shoppa) Date: Thu, 26 Nov 1998 11:50:34 -0500 Subject: Pro/Venix and Y2K Message-ID: <981126115034.2a2004dc@trailing-edge.com> The following exchange recently took place on comp.sys.dec.micro/ vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix is based on 2.9BSD - does anyone know more details about its heritage? Donato B. Masaoy III wrote: > > Came into a Pro 380 and loaded Venix as a means of tyring out Unix. > Noticed that at 2000 it sets itself back to 1970. Is there fix for this? > Should I bother? The PRO 380 Time-Of-Year clock has two modes: 1. BCD mode, where the year is stored in two decimal digits. 2. Binary mode, where the year is stored as at least 7 bits (more likely 8 bits - it's been a couple of months since the changes were implemented the fix in RT-11's PI.SYS, PIX.SYS, and SETUP.SAV to make it Y2K compliant.) When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the clock keeps accurately ticking. Venix evidently chokes on this and doesn't interpret "00" as "2000". As Unix is incapable of representing times internally outside the range 1970-2038, the obvious fix is to interpret BCD years in the range 70-99 as being in the 1900's, and the BCD years in the range 00-38 as in the 2000's. This is, for example, how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. Of course, finding the sources to Pro 380 Venix to implement the changes may be difficult. The PUPS archive has a version of 2.9BSD patches for the Pro, and if you're lucky Venix may be close enough that you can use the Pro-specific clock sources to patch your kernel binary. In the 2.9BSD Pro patches, the clock code is in "/sys-dev/prostuff.c", and begins: /* These two fuctions handle the pro 300's clock * This code is defunct at the end of the century. * Will Unix still be here then?? */ -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA22435 for pups-liszt; Fri, 27 Nov 1998 05:49:47 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From djenner at halcyon.com Fri Nov 27 04:48:45 1998 From: djenner at halcyon.com (David C. Jenner) Date: Thu, 26 Nov 1998 10:48:45 -0800 Subject: Pro/Venix and Y2K References: <981126115034.2a2004dc@trailing-edge.com> Message-ID: <365DA28D.5C541C8C@halcyon.com> There probably isn't much BSD lineage in Version 1 of Venix, but there is some in Version 2. Probably mostly in the form of the usual add-ons like VI. There's some confusion about this (at least in my mind), so any authoritative info would be interesting. First of all there's: "Venix/Pro" from Venturecom, which is definitely of AT&T lineage, probably V7/SysIII for V1 of Venix/Pro, and perhaps a bit of BSD stuff mixed in for V2 of Venix/Pro. This is what you find at Internet archives. Then there's: "Pro/Venix" from DEC, which is a repackaging of Venix/Pro. Again, there are Versions 1 and 2 of this. I have V1 and docs for V2, but no disks for V2. I'd really like to find a copy of the distribution of DEC Pro/Venix V2, if it's legal (and having the Ancient Unix license would seem to make it OK for at least the AT&T side). For Pro/Venix, V2, the manual entry for "clock(7) - time-of-day clock" is: /dev/clock refers to a time-of-day, battery-backed-up clock. This device node is provided primarily for the benefit of the date com- mand, which will read from it given the -l flag (usually done on system start-up), and write to it if a new date is set. ... struct clkbuf { int clk_sec; /* second (0-59) */ int clk_min; /* minute (0-59) */ int clk_hour; /* hour (0-23) */ int clk_mday; /* day of month (1-31) */ int clk_mon; /* month (0-11) */ int clk_year; /* year (00-99) */ int clk_wday; /* day of the week (Sunday = 0) */ int clk_yday; /* day of the year (0-365) */ int clk_dst; /* non-zero if daylight savings applies */ }; So, it looks bad at least from the internal representation of the year. Since I don't have this version, I can't comment on exactly what happens. Dave Tim Shoppa wrote: > > The following exchange recently took place on comp.sys.dec.micro/ > vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix > is based on 2.9BSD - does anyone know more details about its heritage? > > Donato B. Masaoy III wrote: > > > > Came into a Pro 380 and loaded Venix as a means of tyring out Unix. > > Noticed that at 2000 it sets itself back to 1970. Is there fix for this? > > Should I bother? > > The PRO 380 Time-Of-Year clock has two modes: > > 1. BCD mode, where the year is stored in two decimal digits. > 2. Binary mode, where the year is stored as at least 7 bits (more > likely 8 bits - it's been a couple of months since the changes > were implemented the fix in RT-11's PI.SYS, PIX.SYS, and > SETUP.SAV to make it Y2K compliant.) > > When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the > clock keeps accurately ticking. Venix evidently chokes on this > and doesn't interpret "00" as "2000". > > As Unix is incapable of representing times internally outside > the range 1970-2038, the obvious fix is to interpret BCD years > in the range 70-99 as being in the 1900's, and the BCD years > in the range 00-38 as in the 2000's. This is, for example, > how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. > > Of course, finding the sources to Pro 380 Venix to implement > the changes may be difficult. The PUPS archive has a version of 2.9BSD > patches for the Pro, and if you're lucky Venix may be close > enough that you can use the Pro-specific clock sources to patch > your kernel binary. In the 2.9BSD Pro patches, the clock > code is in "/sys-dev/prostuff.c", and begins: > > /* These two fuctions handle the pro 300's clock > * This code is defunct at the end of the century. > * Will Unix still be here then?? > */ > > -- > Tim Shoppa Email: shoppa at trailing-edge.com > Trailing Edge Technology WWW: http://www.trailing-edge.com/ > 7328 Bradley Blvd Voice: 301-767-5917 > Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22497 for pups-liszt; Fri, 27 Nov 1998 06:05:10 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From kcwellsc at math.uwaterloo.ca Fri Nov 27 05:04:36 1998 From: kcwellsc at math.uwaterloo.ca (Ken Wellsch) Date: Thu, 26 Nov 1998 14:04:36 -0500 (EST) Subject: Pro/Venix and Y2K In-Reply-To: <981126115034.2a2004dc@trailing-edge.com> from "Tim Shoppa" at Nov 26, 98 11:50:34 am Message-ID: <199811261904.OAA22036@math.uwaterloo.ca> Hi Tim, | The following exchange recently took place on comp.sys.dec.micro/ | vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix | is based on 2.9BSD - does anyone know more details about its heritage? There are several folks with vastly better knowledge on this than I, but should they not speak up, I'll mumble on what little I know. Venix is an outgrowth of V6 UNIX I believe - from my fadding memory of the little I played with it, the file system is definitely V6 based (with the notion of "huge" files, i.e. the index pointers would switch from direct to indirect, while I believe V7 took a much better approach). The 2BSD branch I believe took a much later fork, V7 or later? It also played a more central role than Venix I expect, contributing a goodly amount of later PDP-11/UNIX based things that others borrowed (e.g. Ultrix 3 from DEC took csh and vi among other goodies). | As Unix is incapable of representing times internally outside | the range 1970-2038, the obvious fix is to interpret BCD years | in the range 70-99 as being in the 1900's, and the BCD years | in the range 00-38 as in the 2000's. This is, for example, | how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. Gee, I didn't think there was one "UNIX" in the world 8-) How big are your integers? Do you use signed or unsigned values for the epoch since Jan 1 1970? It seems hard to believe anything in the UNIX world of today has this limitation. I'll agree there is likely just the one "RT-11" though 8-) -- Ken Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22536 for pups-liszt; Fri, 27 Nov 1998 06:17:19 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From SHOPPA at trailing-edge.com Fri Nov 27 05:15:17 1998 From: SHOPPA at trailing-edge.com (Tim Shoppa) Date: Thu, 26 Nov 1998 14:15:17 -0500 Subject: Pro/Venix and Y2K Message-ID: <981126141517.2a2003cb@trailing-edge.com> >There's some confusion about this (at least in my mind), so any >authoritative info would be interesting. I agree - and would love more definitive information (Or, even better, the sources to Pro/Venix.) I've learned an amazing amount about segments of the Unix lineage just from the comments in the past week, but the gaps in my knowledge still loom large! It's entirely possible that Pro/Venix uses the Pro clock in BCD mode - it looked to me that the 2.9BSD version does it in binary mode. >struct clkbuf { > int clk_sec; /* second (0-59) */ > int clk_min; /* minute (0-59) */ > int clk_hour; /* hour (0-23) */ > int clk_mday; /* day of month (1-31) */ > int clk_mon; /* month (0-11) */ > int clk_year; /* year (00-99) */ > int clk_wday; /* day of the week (Sunday = 0) */ > int clk_yday; /* day of the year (0-365) */ > int clk_dst; /* non-zero if daylight savings applies */ >}; > >So, it looks bad at least from the internal representation of the >year. It depends on what you want to call "bad". It's quite possible to build a Y2K compliant system out of non-Y2K compliant components! 2.11BSD's date(1) was patched for Y2K in such a way that "00" in the two-digit year would be interpreted as the year 2000. (See patch #327 for the details.) Would similar fixes for more historic Unices be useful to the general folk here? -- Tim Shoppa Email: shoppa at trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22638 for pups-liszt; Fri, 27 Nov 1998 06:50:39 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From djenner at halcyon.com Fri Nov 27 05:49:47 1998 From: djenner at halcyon.com (David C. Jenner) Date: Thu, 26 Nov 1998 11:49:47 -0800 Subject: Pro/Venix and Y2K References: <981126141517.2a2003cb@trailing-edge.com> Message-ID: <365DB0DB.CD18A664@halcyon.com> It's "bad" in the sense that the evidence available (empirical, and sparse code) suggests that the software (and probably the hardware) is working with only two-digit years. You could, of course, try to remedy the Y2K problem by properly handling the clock. But the evidence suggests that the problem may be spread over lots of code. As you say, it would be nice to have the Pro/Venix code (as opposed to the Venix/Pro code). DEC's Pro/Venix is more flexible than Venturecom's Venix/Pro. You can write and link custom device drivers with the kernel in Pro/Venix. There is some hope you could actually "fix" /dev/clock, but this probably isn't enough to solve the whole Y2K problem. Again, any knowledge about the whereabouts of even the binary distribution disks of DEC's V2 Pro/Venix would be great. Dave Tim Shoppa wrote: > > >There's some confusion about this (at least in my mind), so any > >authoritative info would be interesting. > > I agree - and would love more definitive information (Or, even > better, the sources to Pro/Venix.) I've > learned an amazing amount about segments of the Unix lineage > just from the comments in the past week, but the gaps in > my knowledge still loom large! > > It's entirely possible that Pro/Venix uses the Pro > clock in BCD mode - it looked to me that the 2.9BSD version > does it in binary mode. > > >struct clkbuf { > > int clk_sec; /* second (0-59) */ > > int clk_min; /* minute (0-59) */ > > int clk_hour; /* hour (0-23) */ > > int clk_mday; /* day of month (1-31) */ > > int clk_mon; /* month (0-11) */ > > int clk_year; /* year (00-99) */ > > int clk_wday; /* day of the week (Sunday = 0) */ > > int clk_yday; /* day of the year (0-365) */ > > int clk_dst; /* non-zero if daylight savings applies */ > >}; > > > >So, it looks bad at least from the internal representation of the > >year. > > It depends on what you want to call "bad". It's quite possible > to build a Y2K compliant system out of non-Y2K compliant > components! > > 2.11BSD's date(1) was patched for Y2K in such a way that "00" in > the two-digit year would be interpreted as the year 2000. (See > patch #327 for the details.) > > Would similar fixes for more historic Unices be useful to the general > folk here? > > -- > Tim Shoppa Email: shoppa at trailing-edge.com > Trailing Edge Technology WWW: http://www.trailing-edge.com/ > 7328 Bradley Blvd Voice: 301-767-5917 > Bethesda, MD, USA 20817 Fax: 301-767-5927 From wkt at henry.cs.adfa.oz.au Fri Nov 27 08:26:17 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 09:26:17 +1100 (EST) Subject: List of licensees In-Reply-To: <199811261637.DAA13285@henry.cs.adfa.oz.au> from Kelwin Wylie at "Nov 26, 98 11:34:23 am" Message-ID: <199811262226.JAA13586@henry.cs.adfa.oz.au> In article by Kelwin Wylie: > I am curious to see who else has a source code license. > I imagine there might be privacy concerns, but if there isn't, > I would like to see the list. > Kelwin I can't see any harm, and it's good to know who you can share stuff with. Here are the names I have. There are obviously more people/organisations with licenses. Warren James A. Capp Greg Lehey Ali Bahrami Oleg Levanidov Pat Barron Yi Li Harald Barth Andrew Lynch Craig Bevans Douglas M. Wells Joseph Bickel James MacKeivitch Stefan Bieschewski Keizo Maeda Robin Birch Masahiro Matsumoto Hartmut Brandt Doug McIntyre Matthias Bruestle Kristen McIntyre W. C. Bulte Kirk McKusick Jozc Capkyn Giegrich Michael Brian Chase Shuji Mochida Atindra Chaturvedi Andreas Muller Peter Chubb Dieter Muller Efton Collins Joseph Myers Peter Collinson Gregory Neil Shapiro Rick Copeland Lyndon Nerenberg Matthew Crosby Peter Nikolaev Zhivkov Donald Cruikshank Ray Nouell Mrian Crzig Lennox Kevin Ogden J. D. Knaebel Joergen Pehrson Carlo Dapor Carl Phillips Eric Delgado Paul Pierce Erick Delios James R. Willing Barry Dobyns Charles Retter John Dodson Bruce Robertson Anthony Duell Chang Sang-Thong Alexander Duerrschnabel Michael Schmitz Kevin Dunlap Steven Schultz Hendrik Dykstra Daniel Seagraves Charles E Owen Michael Shalayeff Eric Fischer Gregg Sigfried Gregor Fismer Barry Silverman Robert G. Van Herick Michael Sokolov David Galloway Chris Steinke Glenn Geers Jason Stevens Edmund Goppelt Mark Thompson Brent Graveland Warren Toomey Arno Griffioen Jennine Townsend John Harvard Pete Turnbull Martin Heller Christopher Vance Michael Homsey Paul Vixie Michael J. Haertel Jason Wells Jay Jaeger Ken Wellsch Martin James Crehan Jim Williams David Jenner John Wilson Neil Johnson Norman Wilson Soren Jorvang Kelwin Wylie Moto Kawasaki Thomas Yanuklis Eugene Kim Thomas Zenker Kern Koh Leendert van Doorn Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA23319 for pups-liszt; Fri, 27 Nov 1998 09:26:59 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From wkt at henry.cs.adfa.oz.au Fri Nov 27 08:28:31 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 09:28:31 +1100 (EST) Subject: Pro/Venix and Y2K In-Reply-To: <981126115034.2a2004dc@trailing-edge.com> from Tim Shoppa at "Nov 26, 98 11:50:34 am" Message-ID: <199811262228.JAA13602@henry.cs.adfa.oz.au> In article by Tim Shoppa: > The following exchange recently took place on comp.sys.dec.micro/ > vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix > is based on 2.9BSD - does anyone know more details about its heritage? I understand that Venix is a cut-down SysIII in binary-only format. We have SysIII in the archive in source form, if that's of any help. I doubt it will have the device handler for the PRO 380 Time-Of-Year clock. Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA23443 for pups-liszt; Fri, 27 Nov 1998 09:56:13 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From wkt at henry.cs.adfa.oz.au Fri Nov 27 08:57:56 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 09:57:56 +1100 (EST) Subject: Pro/Venix and Y2K In-Reply-To: <19981127092329.U67961@freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:23:29 am" Message-ID: <199811262257.JAA13789@henry.cs.adfa.oz.au> In article by Greg Lehey: > On Friday, 27 November 1998 at 9:28:31 +1100, Warren Toomey wrote: > > I understand that Venix is a cut-down SysIII in binary-only format. We have > > SysIII in the archive in source form, if that's of any help. > > Interesting. How did we get that? Or is it a 16 bit version? > Greg It's a PDP-11 version donated by Kirk. We also have SysV for the PDP-11, donated by John Holden, but I can't put it in the archive because the SCO license specifically doesn't cover SysV. Cheers, Warren Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA23485 for pups-liszt; Fri, 27 Nov 1998 10:02:15 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From wkt at henry.cs.adfa.oz.au Fri Nov 27 09:03:50 1998 From: wkt at henry.cs.adfa.oz.au (Warren Toomey) Date: Fri, 27 Nov 1998 10:03:50 +1100 (EST) Subject: List of licensees In-Reply-To: <19981127092818.V67961@freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:28:18 am" Message-ID: <199811262303.KAA13818@henry.cs.adfa.oz.au> In article by Greg Lehey: > There seem to be some obvious omissions, such as Dennis and Tim > Shoppa. I also have the feeling that a number of others should be > there, but I can't put a name to them. I can only give the details of the people for whom I actually have license numbers (both SCO, AT&T and Western Electric). If you _are_ covered by a UNIX source license, and would like access to the archive, then please fax your license to me at +61 6268 8581. I only require the pages with the signatures, the license numbers, and the list of UNIX versions covered. Thanks, Warren From DSEAGRAV at toad.xkl.com Sat Nov 28 06:06:59 1998 From: DSEAGRAV at toad.xkl.com (Daniel A. Seagraves) Date: Fri, 27 Nov 1998 12:06:59 -0800 Subject: 2.9BSD/DZ-11 clone screw Message-ID: <13407312462.14.DSEAGRAV@toad.xkl.com> I got my hands on a Aviv DZ-11 clone. 16-line MUX. So, I go about shoving it in the 83. It boots 2.9BSD off a RL02. Shove device in, set CSR and interrupt vector, and fire up BSD. I screwed with the dtab line - With it using dzdma in place of dzou, I can't make the MUX go. The kernel attaches it, but I can't seem to be able to talk to it. So, I switched to dzou. Now, upon boot, I get the message: dz 0 csr 160100 vector 320 no address found for dzou SERIOUS CONFIGURATION ERROR^G^G^G I've tried other vectors and other bus slots, and get no improvements with either method (dzdma or dzou). Any ideas? (Oh, and if you've got another SDZV11, the DIP switches are BACKWARDS of their labels! 1=0 and 0=1. Cute, eh?) I also have a DHV11, but no idea how to tell BSD it's there. All I ever get from it is dh ? csr 160020 vector 370 didn't interrupt I think I need to set the DM address, but have no idea what to set it to. ------- Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA28694 for pups-liszt; Sat, 28 Nov 1998 12:11:23 +1100 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From sms at moe.2bsd.com Sat Nov 28 10:56:52 1998 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Fri, 27 Nov 1998 16:56:52 -0800 (PST) Subject: 2.9BSD/DZ-11 clone screw Message-ID: <199811280056.QAA23331@moe.2bsd.com> > From: "Daniel A. Seagraves" > > I got my hands on a Aviv DZ-11 clone. 16-line MUX. So, I go about... > shoving it in the 83. It boots 2.9BSD off a RL02. Shove device in, > I screwed with the dtab line - With it using dzdma in place of dzou, I can't > make the MUX go. The kernel attaches it, but I can't seem to be able to talk > to it. So, I switched to dzou. Now, upon boot, I get the message: How are you trying to talk to it? If the line is marked as "modem controlled" you will see/hear nothing until there is 'CD' (carrier detect) present. Typically the /dev nodes are "modem controlled" unless you add 0200 (128 dec) to the minor device number. For 2.9 the major device number of the DZ is 21 so /dev/tty00 would be "mknod /dev/tty00 c 21 0" and expect modemcontrol while "mknod /dev/tty00 c 21 128" would be a "hardwired" line w/o modem control. > dz 0 csr 160100 vector 320 no address found for dzou > SERIOUS CONFIGURATION ERROR^G^G^G That's not surprising since there is no such symbol in the DZ driver ;) 'dzdma' is a replacement for the transmit interrupt routine - the xmit interrupt goes to 'dzdma' (IF 'DZ_DMA' is enabled in the kernel config file). 'dzdma' calls 'dzxint' at the end of dzdma's processing. Thus if you change 'dzdma' to anything it should be to 1) a symbol which exists and 2) 'dzxint'. I think something bad happens if DZ_DMA is enabled but dzxint is called directly - it probably won't work since there are two different 'dzxint' routines (one for use with dzdma and one without and the args are different). So if the symbol 'dzdma' is present in the kernel you probably want to least the "xmit field" in /etc/dtab as 'dzdma'. If 'dzdma' is not present in the kernel then use 'dzxint'. > I've tried other vectors and other bus slots, and get no improvements > with either method (dzdma or dzou). Any ideas? Try remaking the device nodes to indicate no modem control. Or perhaps create a cable that asserts the necessary signals. > I also have a DHV11, but no idea how to tell BSD it's there. > All I ever get from it is > dh ? csr 160020 vector 370 didn't interrupt Quite so. The original 2.9BSD didn't support the DHV or DHU devices. Later on there were drivers created but the original distributions lack (according to the CSRG archive CDs) 'dhv' and 'dhu' support. The closest 2.9 came was the venerable DH/DM. 2.11BSD does have DHV support but the silo handling of those devices is *terrible*. If you have any choice in the matter at all get a DHQ-11 and set it for 'DHU' mode. The DHQ can run in DHV or DHU modes with the latter being far preferable (its behaviour is that of the older DH-11 with regard to silo alarm level selectability). > I think I need to set the DM address, but have no idea what to set it to. Not for a DHV. An older DH/DM you would have needed to but that is one of the differences (and why the DHV isn't compatible with the DH driver) is how modem signals are handled. On a 2.11BSD system there is a single line: dhv ? 160440 310 5 dhvrint dhvxint # dhv terminal mux for the DHV-11. Where the CSR/Vector were set to whatever didn't conflict with something else. Good Luck. Steven Schultz sms at moe.2bsd.com