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: <Pine.SGI.3.95.981120000517.28198A-100000@world.std.com>

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: <Pine.SGI.3.95.981120000517.28198A-100000@world.std.com>; from Brian D Chase on Fri, Nov 20, 1998 at 12:07:44AM -0800
References: <Pine.SGI.3.95.981120000517.28198A-100000@world.std.com>
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: <Pine.SGI.3.95.981120153054.16667A-100000@world.std.com>

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 <SHOPPA at trailing-edge.com> 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 <SHOPPA at trailing-edge.com> 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: <m0zhVox-000IuTC@mbsks.franken.de>

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 <sms at moe.2bsd.com> 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 <SHOPPA at trailing-edge.com> 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 <SHOPPA at trailing-edge.com> 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 <wkt at henry.cs.adfa.oz.au> 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 <SHOPPA at trailing-edge.com> 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 <sms at moe.2bsd.com> 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 <SHOPPA at trailing-edge.com> 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: <Pine.GSO.4.03.9811231813070.22354-100000@fgh>

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" <rdkeys at seedlab1.cropsci.ncsu.edu> 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: <Pine.GSO.3.96.981123125810.17938D-100000@grant.transarc.com>

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 <dave at fgh.geac.com.au> 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 <sms at moe.2bsd.com> 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 <SHOPPA at trailing-edge.com> 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: <Pine.GSO.3.96.981123125810.17938D-100000@grant.transarc.com> 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 <rickgc at calweb.com> 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 <SHOPPA at trailing-edge.com>
To: PUPS at MINNIE.CS.ADFA.EDU.AU <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 <jkatz at cpio.net> 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 <wkt at henry.cs.adfa.oz.au> 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 <wkt at henry.cs.adfa.oz.au> 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: <Pine.GSO.4.03.9811241432560.399-100000@fgh>

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: <E0ziFz6-0001EI-00@moose.dpmms.cam.ac.uk>

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: <Pine.NEB.4.02.9811241717390.28321-100000@corinne> 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 <wkt at henry.cs.adfa.oz.au> 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) <Frank_Wortner at ml.com> 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: <Frank_Wortner at ml.com>

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: <B27EB33BAB29D2119ABF0001FA7EF28911B0D4@EWFD04>

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" <DSEAGRAV at 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,

> 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 <grin> 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: <Pine.SGI.3.95.981120000517.28198A-100000@world.std.com>

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: <Pine.SGI.3.95.981120000517.28198A-100000@world.std.com>; from Brian D Chase on Fri, Nov 20, 1998 at 12:07:44AM -0800
References: <Pine.SGI.3.95.981120000517.28198A-100000@world.std.com>
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: <Pine.SGI.3.95.981120153054.16667A-100000@world.std.com>

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 <SHOPPA at trailing-edge.com> 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 <SHOPPA at trailing-edge.com> 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: <m0zhVox-000IuTC@mbsks.franken.de>

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 <sms at moe.2bsd.com> 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 <SHOPPA at trailing-edge.com> 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 <SHOPPA at trailing-edge.com> 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 <wkt at henry.cs.adfa.oz.au> 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 <SHOPPA at trailing-edge.com> 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 <sms at moe.2bsd.com> 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 <SHOPPA at trailing-edge.com> 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: <Pine.GSO.4.03.9811231813070.22354-100000@fgh>

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" <rdkeys at seedlab1.cropsci.ncsu.edu> 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: <Pine.GSO.3.96.981123125810.17938D-100000@grant.transarc.com>

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 <dave at fgh.geac.com.au> 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 <sms at moe.2bsd.com> 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 <SHOPPA at trailing-edge.com> 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: <Pine.GSO.3.96.981123125810.17938D-100000@grant.transarc.com> 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 <rickgc at calweb.com> 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 <SHOPPA at trailing-edge.com>
To: PUPS at MINNIE.CS.ADFA.EDU.AU <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 <jkatz at cpio.net> 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 <wkt at henry.cs.adfa.oz.au> 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 <wkt at henry.cs.adfa.oz.au> 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: <Pine.GSO.4.03.9811241432560.399-100000@fgh>

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: <E0ziFz6-0001EI-00@moose.dpmms.cam.ac.uk>

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: <Pine.NEB.4.02.9811241717390.28321-100000@corinne> 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 <wkt at henry.cs.adfa.oz.au> 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) <Frank_Wortner at ml.com> 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: <Frank_Wortner at ml.com>

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: <B27EB33BAB29D2119ABF0001FA7EF28911B0D4@EWFD04>

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" <DSEAGRAV at 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,

> 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 <grin> 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


