All,
I've just spent the week tidying up my Apout program. This runs
PDP-11 user-mode programs (specifically 7th Edition binaries), and
translates V7 syscalls to native syscalls.
I've tidied the program up and optimised it a bit too. Over the summer
break (it's summer down here) I want to add floating-point and start
work on emulating 2.11BSD user-mode binaries.
The program runs on FreeBSD 2.2.x and 3.0 systems: porting to other 32-bit
little-endian Unix systems should be relatively easy. Porting to big-endian
systems might be harder :-) I'll have a look at that too.
Anyway, an alpha of the new 2.2 version is at:
ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/Apout
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA24007
for pups-liszt; Thu, 3 Dec 1998 15:51:17 +1100 (EST)
>From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Thu Dec 3 14:48:30 1998
Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id PAA23997
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 3 Dec 1998 15:50:45 +1100 (EST)
Received: from dosdev (pm8-114.dial.qual.net [205.212.2.114])
by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id JAA06898
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 3 Dec 1998 09:48:58 +0500
Message-Id: <199812030448.JAA06898(a)harrier.Uznet.NET>
From: Michael Sokolov <msokolov(a)harrier.Uznet.NET>
Date: 3 Dec 1998 04:48:30 GMT
To: pups(a)minnie.cs.adfa.edu.au
Subject: Re: System Industries MSCP disk controller problem
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Tim Shoppa <SHOPPA(a)trailing-edge.com> wrote:
> This sounds a lot like the Webster WQESD, which was repackaged
> and sold by many different folks (Sigma, DSD, Qualogy, American
> Digital, etc.)
Quite possible, since this funny Xerox system has a lot of Sigma
components. The outer box in which the BA23 is mounted is made by Sigma,
the funny way the ESDI drives are mechanically mounted is clearly a Sigma
invention, the card connecting the BA23 backplane to the expansion
backplane in the outer Sigma box is made by Sigma, and so is another
totally unmarked card of unknown purpose (its presence or absence appears
to have absolutely no effect on anything). The system is not 100% Sigma,
though. There also another 2-drive ESDI controller (that's the one that was
at 172150 from the beginning) and a 9-track tape controller, both made by
Emulex (QD21 and QT13, respectively) and both appear toast (I want to get
rid of both).
> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
> on, with SW10 and SW5-8 off, to put the CSR at 160334.
> To set it to be 172150, you put SW10 on, and SW5-9 off.
Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF
(don't remember if it was the original position). I also tried SW10 ON and
the rest OFF. In both cases the effect is exactly the same. At power-up the
CPU screams, but then gives the ">>>" prompt. Trying to read different
locations with the E/P/W command (the Q-bus I/O page is mapped at
0x20000000 in the VAX address space), I see that the card responds somehow
to 160334 and to 160400, but not to 172150. (I know that it's this card and
not something else, since when I pull it out the CPU is happy and no one
responds to these addresses.)
> Then again, it might not be a repackaged WQESD, but instead a Dilog
> or Emulex.
I'm 99% sure that it's neither Dilog nor Emulex. I have seen quite a few
Dilog and Emulex cards, and I think I should be able to detect them easily.
> Is there a 10-pin header on the card edge? Can you describe the
> positions and types of "big chips" on the board?
This is a quad-height board. All components are thru-hole and all chips
are in DIP packages. There are no 4-sided chips or surface-mounted
components. Hold it with the component side up, the fingers to the right
and the handles to the left. On the left (handle) side there is a row of
shrouded header connectors. From top to bottom, they are: 10-pin (connected
to something, but purpose unknown), 34-pin (ESDI control and status), 20-
pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly
behind the bottom 20-pin header there is another 20-pin header for drive 3
data. The biggest chip is a 48-pin DIP labeled DP8466AN (National
Semiconductor as far as I can tell), and it's right behind the drive 3 data
connector. There are two AM2901CPCs behind the 34-pin connector. There is
one 28-pin EPROM right about in the center, shifted downward a little. The
ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A".
There is a stack of narrow 24-pin DIP chips going from the top of the board
to right above the EPROM. All have stickers, suggesting that they are
programmable. The stickers have different 6-character codes on them, all
starting with "1583". Directly to the right from the last one there is one
more such chip labeled "SYS IND 1583W3".
Actually, I was wrong about there being 2 switch packs. There are 3 of
them, one of 10 and two of 4. The 10-switch one is right above the chip
labeled "SYS IND 1583W3". In the top right corner (right next to row A
fingers) there is a 4-switch pack. All switches are ON. Directly behind it
there is a 16-pin DIP chip labeled "1583I1" (the only chip with a sticker
not mentioned before). At the top of the board directly to the left from
the 10-chip stack there is a 10 MHz oscillator, the only clock on the
board. Directly to the left from it there is the last 4-switch pack. All
switches are ON. Finally, there are 3 LEDs between the top handle and the
10-pin header. The top one is red and the other two are green.
> Some
> other switches also set the interrupt priority, and this being
> off can also confuse some tests and OS's.
What's the correct priority for disk MSCP? Should it be different
between primary and secondary?
> As to your power-on self-test woes, you're going to have to tell
> us what's in the system and what slot it lives in, as well as what
> sort of backplane it's all in.
The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an
expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the
CPU, the memory, and all peripherals except the controller in question.
First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA,
DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus
into the expansion backplane, where the controller in question is the only
device. It's in the expansion backplane instead of the BA23 because that's
where the actual drives are. I have tried pulling the Sigma Q-bus extender
card out and putting the ESDI controller right in the BA23 backplane, but
this didn't change anything, so there is nothing wrong with the Q-bus
expansion.
You know what, I just looked a little closer and noticed that in this
configuration (both 4-switch packs all ON, SW1-9 on the 10-switch pack OFF,
and SW10 ON) the controller responds not only to 160334 and 160400, but to
just about any address in the Q-bus I/O page (except 172150)! No wonder the
CPU screams about it! What the hell is going on? How can it possibly do
this? Is someone trying to port Plug-n-Pray to Q-bus? Is it something like
KFQSA with a separate address for each drive and everything soft-
configured?
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA25817
for pups-liszt; Fri, 4 Dec 1998 01:27:17 +1100 (EST)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Fri Dec 4 00:25:04 1998
Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id BAA25812
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 4 Dec 1998 01:27:04 +1100 (EST)
Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU;
Thu, 3 Dec 1998 9:25:04 -0500
Date: Thu, 3 Dec 1998 9:25:04 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)MINNIE.CS.ADFA.OZ.AU
CC: SHOPPA(a)trailing-edge.com
Message-Id: <981203092504.2de002c1(a)trailing-edge.com>
Subject: Re: System Industries MSCP disk controller problem
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
>> This sounds a lot like the Webster WQESD, which was repackaged
>> and sold by many different folks (Sigma, DSD, Qualogy, American
>> Digital, etc.)
> Quite possible, since this funny Xerox system has a lot of Sigma
>components.
I regularly work with "PDP-11 systems" now that don't have a single
DEC component in them. CPU by Mentec ( http://www.mentec.com/ ),
disk controller by Andromeda ( http://www.andromedasystems.com/ ),
async and parallel I/O by the Logical Company ( http://www.logical-co.com ),
etc. What else are commercial developers left to do now that
DEC (after over a decade of trying to) has finally abandoned their
PDP-11 product line? At least the other companies named are still
doing active support and (at least in Mentec's case) development!
> The outer box in which the BA23 is mounted is made by Sigma,
>...
>though. There also another 2-drive ESDI controller (that's the one that was
>at 172150 from the beginning) and a 9-track tape controller, both made by
>Emulex (QD21 and QT13, respectively) and both appear toast (I want to get
>rid of both).
You might be a bit hasty in casting these off, as you aren't having
the best of luck with the rest of the peripherals, either!
>> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
>> on, with SW10 and SW5-8 off, to put the CSR at 160334.
>> To set it to be 172150, you put SW10 on, and SW5-9 off.
> Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF
>(don't remember if it was the original position). I also tried SW10 ON and
>the rest OFF. In both cases the effect is exactly the same. At power-up the
>CPU screams, but then gives the ">>>" prompt. Trying to read different
>locations with the E/P/W command (the Q-bus I/O page is mapped at
>0x20000000 in the VAX address space), I see that the card responds somehow
>to 160334 and to 160400, but not to 172150. (I know that it's this card and
>not something else, since when I pull it out the CPU is happy and no one
>responds to these addresses.)
>> Is there a 10-pin header on the card edge? Can you describe the
>> positions and types of "big chips" on the board?
> This is a quad-height board. All components are thru-hole and all chips
>are in DIP packages. There are no 4-sided chips or surface-mounted
>components. Hold it with the component side up, the fingers to the right
>and the handles to the left. On the left (handle) side there is a row of
>shrouded header connectors. From top to bottom, they are: 10-pin (connected
>to something, but purpose unknown), 34-pin (ESDI control and status), 20-
>pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly
>behind the bottom 20-pin header there is another 20-pin header for drive 3
>data. The biggest chip is a 48-pin DIP labeled DP8466AN (National
>Semiconductor as far as I can tell), and it's right behind the drive 3 data
>connector. There are two AM2901CPCs behind the 34-pin connector. There is
>one 28-pin EPROM right about in the center, shifted downward a little. The
>ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A".
That clinches it - it's a Webster WQESD, running Wombat V2.41.
9901-8918 is evidently the SI part number for the complete system.
It's a bit confusing to go from the SI part number because they all
begin with "9900" or "9901"!
> What's the correct priority for disk MSCP? Should it be different
>between primary and secondary?
A summary of the WQESD switch settings, and the various ways in which
you can invoke Wombat, lives at:
ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-11/hardware
as the file "WQESD.txt".
>> As to your power-on self-test woes, you're going to have to tell
>> us what's in the system and what slot it lives in, as well as what
>> sort of backplane it's all in.
> The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an
>expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the
>CPU, the memory, and all peripherals except the controller in question.
>First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA,
>DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus
>into the expansion backplane, where the controller in question is the only
>device. It's in the expansion backplane instead of the BA23 because that's
>where the actual drives are. I have tried pulling the Sigma Q-bus extender
>card out and putting the ESDI controller right in the BA23 backplane, but
>this didn't change anything, so there is nothing wrong with the Q-bus
>expansion.
I'm willing to bet that you have severe Q-bus continuity problems,
especially now that you've told us that you have an expansion Q-bus
cabinet and that you've been randomly moving Q-bus cards around.
You have to tell us exactly which slot each card is in, and preferably
the original configuration as well (the Sigma backplanes have different
wirings than the common DEC ones.)
Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"?
The sigma 5.25" 9-slot backplanes have very different backplane
wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
it will very likely cause damage.)
As a start, work just with the BA23. Put the CPU in slot 1, with
the two memory boards in slots 2 and 3. Put the WQESD in slot 4.
Have nothing else plugged in at all - especially not the boards
that jumper the two backplanes together.
Set the DIPswitches on the WQESD as follows:
10-switch pack: Switches 1-2 off, 3 on, 4-9 off, 10 on.
4-switch pack near the edge connector: 1-3 on, 4 off.
4-switch pack near the handles: 1-4 on.
Then try to start up wombat with the following sequence of console commands:
Microvax II:
Halt the processor
U
I
D/P/W 20001F40 20
D/L 20088008 80000002
D/W 20001468 AC
S 400
If this doesn't start Wombat, tell us *exactly* what the error message
produced is.
--
Tim Shoppa Email: shoppa(a)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
Dear Ladies and Gentlemen,
I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP
controllers for ESDI disks? The VAX I'm working has one. It's quad-height
board with connectors for 4 ESDI drives. I couldn't find a model number or
anything like that, but there is a sticker on one of the chips that says
"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having
is that I have no idea how to configure it. It has two DIP switch packs,
one with 4 switches and one with 10. Originally it was configured to be the
secondary disk MSCP controller at 160334. I want it to be the primary one
at 172150. I tried every reasonable switch combination I could think of,
but no luck.
What's even worse is that I can't leave it as secondary either. For some
reason its configuration makes the CPU (KA650) unhappy. When I pull it out,
the CPU passes all power-up tests beautifully. When I put it in, I still
get to the ">>>" prompt eventually, but first I get a load of error
messages from the self-tests. Then when I try to boot from DUB0, it tells
me "DEVASSIGN", suggesting that it doesn't recognize the second disk MSCP
controller at all. All docs I have suggest that 160334 is the correct
address for secondary disk MSCP. It's in the floating address range,
though, so I suspected that it's the side effect of adding or removing
other cards. I tried making the configuration as close to the original as I
could. No luck still. The only card I had to pull out is the secondary
TMSCP (Emulex QT13 9-track tape controller), because it appears totally
toast (the CPU refuses to power up with that infamous 9 when this card is
present). But then secondary TMSCP should be AFTER secondary disk MSCP in
the floating address space, right? I tried some more investigation and by
pure accident I discovered that the SI controller also responds somehow to
160400. What the hell is that address for? Could this be what makes the CPU
unhappy?
Does anyone have any clues? Is anyone here familiar with SI MSCP disk
controllers? TIA for any help.
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA12137
for pups-liszt; Tue, 1 Dec 1998 14:27:04 +1100 (EST)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Tue Dec 1 13:24:21 1998
Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id OAA12127
for <PUPS(a)MINNIE.CS.adfa.edu.AU>; Tue, 1 Dec 1998 14:26:35 +1100 (EST)
Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.adfa.edu.AU;
Mon, 30 Nov 1998 22:24:21 -0500
Date: Mon, 30 Nov 1998 22:24:21 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)minnie.cs.adfa.edu.au
Message-Id: <981130222421.2de00129(a)trailing-edge.com>
Subject: Re: System Industries MSCP disk controller problem
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP
>controllers for ESDI disks? The VAX I'm working has one. It's quad-height
>board with connectors for 4 ESDI drives. I couldn't find a model number or
>anything like that, but there is a sticker on one of the chips that says
>"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having
>is that I have no idea how to configure it. It has two DIP switch packs,
>one with 4 switches and one with 10. Originally it was configured to be the
>secondary disk MSCP controller at 160334. I want it to be the primary one
>at 172150. I tried every reasonable switch combination I could think of,
>but no luck.
This sounds a lot like the Webster WQESD, which was repackaged
and sold by many different folks (Sigma, DSD, Qualogy, American
Digital, etc.)
If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
on, with SW10 and SW5-8 off, to put the CSR at 160334.
To set it to be 172150, you put SW10 on, and SW5-9 off.
Then again, it might not be a repackaged WQESD, but instead a Dilog
or Emulex.
Is there a 10-pin header on the card edge? Can you describe the positions
and types of "big chips" on the board?
>pure accident I discovered that the SI controller also responds somehow to
>160400. What the hell is that address for? Could this be what makes the CPU
>unhappy?
It might be because you've enabled the on-board PDP-11 bootstrap,
a very big no-no when used in a Microax system. (This
bootstrap effectively tries to jam code by DMA into main memory,
and can wreak all sorts of havoc on a Microvax.) Some
other switches also set the interrupt priority, and this being
off can also confuse some tests and OS's.
As to your power-on self-test woes, you're going to have to tell
us what's in the system and what slot it lives in, as well as what
sort of backplane it's all in.
Incidentally, I happen to use a Webster WQESD in my 4.3BSD-Reno
machine, and am very happy with it there.
--
Tim Shoppa Email: shoppa(a)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
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@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(a)minnie.cs.adfa.edu.au)
>From "Steven M. Schultz" <sms(a)moe.2bsd.com> Sat Nov 28 10:56:52 1998
Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id MAA28689
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 28 Nov 1998 12:11:09 +1100 (EST)
(envelope-from sms(a)moe.2bsd.com)
Received: (from sms@localhost)
by moe.2bsd.com (8.9.0/8.9.0) id QAA23331
for pups(a)minnie.cs.adfa.oz.au; Fri, 27 Nov 1998 16:56:52 -0800 (PST)
Date: Fri, 27 Nov 1998 16:56:52 -0800 (PST)
From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Message-Id: <199811280056.QAA23331(a)moe.2bsd.com>
To: pups(a)minnie.cs.adfa.oz.au
Subject: Re: 2.9BSD/DZ-11 clone screw
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> From: "Daniel A. Seagraves" <DSEAGRAV(a)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(a)moe.2bsd.com
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@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(a)minnie.cs.adfa.edu.au)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Nov 27 08:28:31 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id JAA23313
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 27 Nov 1998 09:26:51 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA13602; Fri, 27 Nov 1998 09:28:31 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811262228.JAA13602(a)henry.cs.adfa.oz.au>
Subject: Re: Pro/Venix and Y2K
To: SHOPPA(a)trailing-edge.com (Tim Shoppa)
Date: Fri, 27 Nov 1998 09:28:31 +1100 (EST)
Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
In-Reply-To: <981126115034.2a2004dc(a)trailing-edge.com> from Tim Shoppa at "Nov 26, 98 11:50:34 am"
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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@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(a)minnie.cs.adfa.edu.au)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Nov 27 08:57:56 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id JAA23438
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 27 Nov 1998 09:56:07 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA13789; Fri, 27 Nov 1998 09:57:57 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811262257.JAA13789(a)henry.cs.adfa.oz.au>
Subject: Re: Pro/Venix and Y2K
To: grog(a)lemis.com (Greg Lehey)
Date: Fri, 27 Nov 1998 09:57:56 +1100 (EST)
Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
In-Reply-To: <19981127092329.U67961(a)freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:23:29 am"
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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@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(a)minnie.cs.adfa.edu.au)
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Nov 27 09:03:50 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id KAA23480
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 27 Nov 1998 10:02:08 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id KAA13818; Fri, 27 Nov 1998 10:03:50 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811262303.KAA13818(a)henry.cs.adfa.oz.au>
Subject: Re: List of licensees
To: grog(a)lemis.com (Greg Lehey)
Date: Fri, 27 Nov 1998 10:03:50 +1100 (EST)
Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
In-Reply-To: <19981127092818.V67961(a)freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:28:18 am"
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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
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@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(a)minnie.cs.adfa.edu.au)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Fri Nov 27 02:50:34 1998
Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id DAA22068
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 03:52:29 +1100 (EST)
(envelope-from SHOPPA(a)trailing-edge.com)
Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU;
Thu, 26 Nov 1998 11:50:34 -0500
Date: Thu, 26 Nov 1998 11:50:34 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)MINNIE.CS.ADFA.OZ.AU
Message-Id: <981126115034.2a2004dc(a)trailing-edge.com>
Subject: Pro/Venix and Y2K
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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(a)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@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(a)minnie.cs.adfa.edu.au)
>From "David C. Jenner" <djenner(a)halcyon.com> Fri Nov 27 04:48:45 1998
Received: from mgate.nwnexus.com (mgate.nwnexus.com [206.63.63.200])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id FAA22430
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 05:49:37 +1100 (EST)
(envelope-from djenner(a)halcyon.com)
Received: from halcyon.com (66-a-usw.rb1.blv.nwnexus.net [206.63.251.66])
by mgate.nwnexus.com (8.8.8/8.8.8) with ESMTP id KAA03033;
Thu, 26 Nov 1998 10:48:52 -0800
Message-ID: <365DA28D.5C541C8C(a)halcyon.com>
Date: Thu, 26 Nov 1998 10:48:45 -0800
From: "David C. Jenner" <djenner(a)halcyon.com>
Reply-To: djenner(a)halcyon.com
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Shoppa <SHOPPA(a)trailing-edge.com>
CC: PUPS(a)MINNIE.CS.ADFA.OZ.AU
Subject: Re: Pro/Venix and Y2K
References: <981126115034.2a2004dc(a)trailing-edge.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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(a)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@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(a)minnie.cs.adfa.edu.au)
>From Ken Wellsch <kcwellsc(a)math.uwaterloo.ca> Fri Nov 27 05:04:36 1998
Received: from math.uwaterloo.ca (kcwellsc(a)math.uwaterloo.ca [129.97.140.144])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA22489
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 06:05:00 +1100 (EST)
(envelope-from kcwellsc(a)math.uwaterloo.ca)
Received: (from kcwellsc@localhost)
by math.uwaterloo.ca (8.8.8/8.8.8) id OAA22036;
Thu, 26 Nov 1998 14:04:36 -0500 (EST)
From: Ken Wellsch <kcwellsc(a)math.uwaterloo.ca>
Message-Id: <199811261904.OAA22036(a)math.uwaterloo.ca>
Subject: Re: Pro/Venix and Y2K
To: SHOPPA(a)trailing-edge.com (Tim Shoppa)
Date: Thu, 26 Nov 1998 14:04:36 -0500 (EST)
Cc: PUPS(a)MINNIE.CS.ADFA.OZ.AU
In-Reply-To: <981126115034.2a2004dc(a)trailing-edge.com> from "Tim Shoppa" at Nov 26, 98 11:50:34 am
Organization: University of Waterloo, Math Faculty Computing Facility (Alumni)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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@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(a)minnie.cs.adfa.edu.au)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Fri Nov 27 05:15:17 1998
Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id GAA22531
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 06:17:10 +1100 (EST)
(envelope-from SHOPPA(a)trailing-edge.com)
Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU;
Thu, 26 Nov 1998 14:15:17 -0500
Date: Thu, 26 Nov 1998 14:15:17 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)MINNIE.CS.ADFA.OZ.AU
Message-Id: <981126141517.2a2003cb(a)trailing-edge.com>
Subject: Re: Pro/Venix and Y2K
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
>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(a)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@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(a)minnie.cs.adfa.edu.au)
>From "David C. Jenner" <djenner(a)halcyon.com> Fri Nov 27 05:49:47 1998
Received: from mgate.nwnexus.com (mgate.nwnexus.com [206.63.63.200])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA22633
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 06:50:31 +1100 (EST)
(envelope-from djenner(a)halcyon.com)
Received: from halcyon.com (66-a-usw.rb1.blv.nwnexus.net [206.63.251.66])
by mgate.nwnexus.com (8.8.8/8.8.8) with ESMTP id LAA03155;
Thu, 26 Nov 1998 11:49:55 -0800
Message-ID: <365DB0DB.CD18A664(a)halcyon.com>
Date: Thu, 26 Nov 1998 11:49:47 -0800
From: "David C. Jenner" <djenner(a)halcyon.com>
Reply-To: djenner(a)halcyon.com
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Shoppa <SHOPPA(a)trailing-edge.com>
CC: PUPS(a)MINNIE.CS.ADFA.OZ.AU
Subject: Re: Pro/Venix and Y2K
References: <981126141517.2a2003cb(a)trailing-edge.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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(a)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
Wortner, Frank (RSCH) <Frank_Wortner(a)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(a)ml.com Wed Nov 25 11:31 EST 1998
Return-Path: <Frank_Wortner(a)ml.com>
>From "Wortner, Frank Thu Nov 26 02:27:07 1998
Received: from hudutilgw.ml.com by k2.cwru.edu (8.6.12/SMI-SVR4)
id LAA16359; Wed, 25 Nov 1998 11:31:34 -0500
Received: from mail1.ml.com ([199.201.57.137])
by hudutilgw.ml.com (8.9.1/8.9.1/MLgwo-4.02) with ESMTP id LAA25304
for <mxs46(a)k2.scl.cwru.edu>; Wed, 25 Nov 1998 11:27:52 -0500 (EST)
Received: from ewfd12.exchange.ml.com (ewfd12.exchange.ml.com [146.125.111.6])
by mail1.ml.com (8.9.1/8.9.1/MLml5-4.03b) with ESMTP id LAA00612
for <mxs46(a)k2.scl.cwru.edu>; Wed, 25 Nov 1998 11:27:12 -0500 (EST)
Received: by EWFD12 with Internet Mail Service (5.5.2232.9)
id <XJFJ99ZK>; Wed, 25 Nov 1998 11:27:13 -0500
Message-ID: <B27EB33BAB29D2119ABF0001FA7EF28911B0D4@EWFD04>
From: "Wortner, Frank (RSCH)" <Frank_Wortner(a)ml.com>
To: "'mxs46(a)k2.scl.cwru.edu'" <mxs46(a)k2.scl.cwru.edu>
Subject: Re: What *was* the Tahoe?
Date: Wed, 25 Nov 1998 11:27:07 -0500
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.)
Warren Toomey <wkt(a)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(a)k2.scl.cwru.edu
Received: (from major@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(a)minnie.cs.adfa.oz.au)
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(a)k2.scl.cwru.edu
Received: (from major@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(a)minnie.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@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(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Wed Nov 25 12:20:41 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id NAA14559
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 25 Nov 1998 13:24:49 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id NAA06820; Wed, 25 Nov 1998 13:20:41 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811250220.NAA06820(a)henry.cs.adfa.oz.au>
Subject: Re: Net/2: still at ftp.uu.net
To: simul8(a)simul8.demon.co.uk (James Lothian)
Date: Wed, 25 Nov 1998 13:20:41 +1100 (EST)
Cc: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
In-Reply-To: <01BE1817.1E6F2EF0@SONAR> from James Lothian at "Nov 25, 98 01:58:33 am"
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
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@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(a)minnie.cs.adfa.oz.au)
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(a)k2.scl.cwru.edu
Received: (from major@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(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Alan F R Bain <A.F.R.Bain(a)dpmms.cam.ac.uk> Tue Nov 24 20:46:15 1998
Received: from moose.dpmms.cam.ac.uk (exim(a)moose.dpmms.cam.ac.uk [131.111.24.35])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id VAA10692
for <pups(a)minnie.cs.adfa.edu.au>; Tue, 24 Nov 1998 21:46:27 +1100 (EST)
(envelope-from a.f.r.bain(a)dpmms.cam.ac.uk)
Received: from localhost.cam.ac.uk
([127.0.0.1] helo=moose.dpmms.cam.ac.uk ident=afrb2)
by moose.dpmms.cam.ac.uk with esmtp (Exim 2.03 #1)
id 0ziFz6-0001EI-00
for pups(a)minnie.cs.adfa.edu.au; Tue, 24 Nov 1998 10:46:16 +0000
To: pups(a)minnie.cs.adfa.edu.au
Subject: Version 7 for the PERQ
Date: Tue, 24 Nov 1998 10:46:15 +0000
From: Alan F R Bain <A.F.R.Bain(a)dpmms.cam.ac.uk>
Message-Id: <E0ziFz6-0001EI-00(a)moose.dpmms.cam.ac.uk>
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
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@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(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Kirk McKusick <mckusick(a)mckusick.com> Wed Nov 25 02:19:01 1998
Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.160])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id EAA12210
for <PUPS(a)minnie.cs.adfa.oz.au>; Wed, 25 Nov 1998 04:53:10 +1100 (EST)
(envelope-from mckusick(a)flamingo.McKusick.COM)
Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178])
by knecht.Sendmail.ORG (8.9.2.Alpha2/8.9.2.Alpha2) with ESMTP id JAA08533;
Tue, 24 Nov 1998 09:53:07 -0800 (PST)
Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1])
by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id IAA07519;
Tue, 24 Nov 1998 08:19:01 -0800 (PST)
Message-Id: <199811241619.IAA07519(a)flamingo.McKusick.COM>
To: SHOPPA(a)trailing-edge.com
Subject: Re: Reno (was Re: What *was* the Tahoe?)
cc: PUPS(a)minnie.cs.adfa.oz.au
In-reply-to: Your message of "Mon, 23 Nov 1998 11:05:52 EST."
<981123110552.2a200243(a)trailing-edge.com>
Date: Tue, 24 Nov 1998 08:19:01 -0800
From: Kirk McKusick <mckusick(a)mckusick.com>
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
From: SHOPPA(a)trailing-edge.com
Date: Mon, 23 Nov 1998 11:05:52 -0500
To: PUPS(a)minnie.cs.adfa.oz.au
Subject: Reno (was Re: What *was* the Tahoe?)
Sender: owner-pups(a)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(a)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@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(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Wed Nov 25 09:05:02 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id KAA13341
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 25 Nov 1998 10:03:22 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id KAA05334 for pups(a)minnie.cs.adfa.oz.au; Wed, 25 Nov 1998 10:05:03 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811242305.KAA05334(a)henry.cs.adfa.oz.au>
Subject: Net2 Status: likely outcome
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Wed, 25 Nov 1998 10:05:02 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
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@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(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Wed Nov 25 09:56:09 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id KAA13497
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 25 Nov 1998 10:54:29 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id KAA05513 for pups(a)minnie.cs.adfa.oz.au; Wed, 25 Nov 1998 10:56:10 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811242356.KAA05513(a)henry.cs.adfa.oz.au>
Subject: Also: PUPS digest mail list
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Wed, 25 Nov 1998 10:56:09 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
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@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(a)minnie.cs.adfa.oz.au)
X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Wed Nov 25 11:00:17 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id LAA13790
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 25 Nov 1998 11:58:36 +1100 (EST)
(envelope-from wkt(a)henry.cs.adfa.oz.au)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id MAA05738 for pups(a)minnie.cs.adfa.oz.au; Wed, 25 Nov 1998 12:00:17 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199811250100.MAA05738(a)henry.cs.adfa.oz.au>
Subject: Net/2: still at ftp.uu.net
To: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation)
Date: Wed, 25 Nov 1998 12:00:17 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
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
