25-Jan-91 09:43:23-MST,1537;000000000000
Return-Path: <@Sunburn.Stanford.EDU:RAD@VS3001.AMS.COM>
Received: from Sunburn.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 25 Jan 91 09:42:48 MST
Received: from VS3001.AMS.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA23293; Fri, 25 Jan 91 08:40:19 -0800
Message-Id: <9101251640.AA23293@Sunburn.Stanford.EDU>
Date: Fri 25 Jan 91 11:46:12-EST
From: "Richard DeJordy, x4029" <RAD@MATH.AMS.COM>
Subject: ["Richard DeJordy, x4029" <RAD@MATH.AMS.COM>: TOPS20 Tapes]
To: tops-20@score.stanford.edu
Cc: rad@MATH.AMS.COM
In-Reply-To: <9101251635.AA12879@netcon.cua.edu>
Return-Path: <RAD@VS3001.AMS.COM>
Date: Thu 24 Jan 91 09:27:51-EST
From: "Richard DeJordy, x4029" <RAD@MATH.AMS.COM>
Subject: TOPS20 Tapes
To: info-vax@sri.com
Cc: rad@MATH.AMS.COM
Hello,
We will be retiring our DECSYSTEM 20 shortly and need a utility to read TOPS20
Dumper tapes on the VMS Systems. We have a copy of SI_DUMPER which works
fine except for MultiVolume Dumper Sets. It seems to loose the channel
when the next volume is mounted.
Does anyone out there have a utility or a newer version of SI_DUMPER that
I can get to read these tapes? Not being a BLISS programmer, trying to
sift through the code and determine what is happening has proven quite
difficult.
Any help would be greatly appreciated.
Please include me directly on a reply, as I seldom have a chance to get to
read this list any more.
Thanks
Rich DeJordy
American Mathematical Society
RAD@MATH.AMS.COM
-------
-------
12-Feb-91 21:13:42-MST,2030;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 12 Feb 91 21:13:22 MST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.21 ) id AA20528; Tue, 12 Feb 91 20:13:14 -0800
Date: Tue, 12 Feb 1991 20:09:56 -0800 (PST)
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
Subject: [egoshin@serp.ihep.su: Re: PDP-10's in the Soviet Union]
To: TOPS-20 Hackers and Yackers <TOPS-20@WSMR-SIMTEL20.Army.MIL>
Message-Id: <MailManager.666418196.9366.mrc@Tomobiki-Cho.CAC.Washington.EDU>
I thought you would be interested in hearing about our favorite CPU's on the
other side of the Great Divide...
With all the KL's being trashed these days, maybe someone could donate one to
these guys in the name of US/USSR friendship? I doubt there's any export
controls on KL's these days...
** Begin Forwarded Message **
Date: Mon, 11 Feb 91 20:15:45 +0300 (MSK)
From: egoshin@serp.ihep.su
Subject: Re: PDP-10's in the Soviet Union
To: MRC@CAC.Washington.EDU
Hi Mark.
We have two DEC-10 systems. One of it is DECSystem-1070 with KI CPU,
2MB extended memory, 4 * 100MB Disks, 3 * PDP-11 with DH-11 as communication
facilities. It is buyed officially from DEC in the middle of 70th.
Second host is through out from Belgium (some physics centre) and
presented to our Institute. It don't work now.
As I know we are the only center in USSR which has the DEC-10 Systems.
The nearest is in Warsaw (Poland), and there isn't any community of
DEC-10 users in USSR.
We use DEC-10 in physics experimental film tracking recognition
on bubble cameras. The main languige is Fortran. Also we use it as
host to develop microprocessors software.
I think we are interested by KL processor (if anybody through out it),
and soft to use it in physics experiment.
But our interest is slowly drop...
Best regards, Leonid Yegoshin.
17-Feb-91 09:19:50-MST,702;000000000000
Return-Path: <lmaltz@sitvax.stevens-tech.edu>
Received: from VAXA ([192.12.216.2]) by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 17 Feb 91 09:18:21 MST
Date: Fri, 15 Feb 1991 16:30:48 EST
From: lmaltz@sitvax.stevens-tech.edu
To: tops-20@wsmr-simtel20.army.mil
CC: lmaltz@sitvax.stevens-tech.edu
Message-ID: <0094446b.3ea70620.14278@sitvax.stevens-tech.edu>
Subject: last call - 2020's yp for grabs
We've still got 2 2020's that have been unplugged for varying amounts of time
along with rp06 disks and more. If you or anyone has a serious interest,
this is the time to call, 201-420-5478, and make us an offer we can't refuse.
We're cleaning out the closets. Last call.
-Leslie Maltz
18-Feb-91 23:42:59-MST,1586;000000000000
Mail-From: PANDA created at 18-Feb-91 23:41:54
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Mon, 18 Feb 91 23:41:54 MST
Date: Mon, 18 Feb 91 13:12:16 PST
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: a big hello...
To: TOPS-20@WSMR-SIMTEL20.Army.MIL
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <12663097528.7.MRC@PANDA.PANDA.COM>
PANDA, my home DECSYSTEM-2020, is once again in the land of the living, due to
the efforts of Messrs J. Dempster and P. Lothberg, the acquisition of the
Stanford 2020 and TU45 for spare parts, and the procurement of four RM03s and
2 RM05s (w/controller) to replace PANDA's original disk drives which either
failed to survive the move or were mortally wounded.
The current score:
Working: 1 KS10 CPU, 1 TU45 tape drive, 1 LA120 console, 1 VT125 user terminal,
3 RM03 disk drives, 1 RM05 disk drive/controller
Unknown status, on standby: 1 RM03 disk drive, 1 RM05 disk drive
Partially working: 1 KS10 CPU (no working UBA's or channels, so it can't do I/O)
To be revived and placed on standby, perhaps dual-ported into the disks.
Scrapped for parts: 2 TU45's, 1 KS10, 4 RM03's (2 head crashed)
Available for anyone who will pay the shipping: 1 RP06 (can't use it because no
three-phase power here)
The RM05 has more capacity than the three RM03's combined; approximately 300
megabytes. I'm using the RM05 as the primary disk drive, although at present one
of the RM03's is the boot pack.
-------
21-Feb-91 12:38:49-MST,1270;000000000000
Return-Path: <bony1!stevef@uunet.UU.NET>
Received: from uunet.UU.NET by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 21 Feb 91 12:38:05 MST
Received: from bony1.UUCP by uunet.UU.NET with UUCP
(5.61/UUNET-primary-gateway) id AA12760; Thu, 21 Feb 91 14:37:42 -0500
Message-Id: <9102211937.AA12760@uunet.UU.NET>
From: Steve Faiwiszewski <stevef@bony1.bony.com>
Subject: Anyone interested in DECsystem 20s?
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
Date: Thu, 21 Feb 91 10:59:54 EST
X-Mailer: ELM [version 2.3 PL0]
Our company has 3 aging DEC-20's; two 2060's and one 2020.
The 2020 is not used anymore, and the 2060's are on their way out.
We don't know what to do with them, and the possibility of trashing
them is real.
Preferrably, these machines would be donated to any interested educational
(or other) institute, so the bank could use this as a writeoff.
Is there anyone out there interested in DEC-20's?
If so, drop me a line via email; maybe something can be worked out...
- Steve -
--
=======================================================================
Internet: stevef@bony1.bony.COM | The Bank Of New York
+--+ ~~~~~~~~~~~~~~~~~~~~
bang : uunet!bony1!stevef | It ain't over 'till Milly Vanilly sings
27-Mar-91 15:26:27-MST,2363;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 27 Mar 91 15:24:25 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA11885; Wed, 27 Mar 91 15:14:53 -0500
Date: Wed, 27 Mar 91 15:14:53 -0500
Message-Id: <9103272014.AA11885@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: tops20@wsmr-simtel20.army.MIL
Subject: Cobol & other conversions, DEC-20 to VMS
1st:
Wesleyan has a collection of ancient COBOL programs, written in Cobol 68,
which we eventually need to move over to VMS Cobol. Does anyone on this
list know of any filter programs, awk scripts, whatever that might help
with the conversion?
2nd:
We're over a year into the conversion of administrative applications from
our DEC-2060 to a VAX 6410. The programs that have been converted &
rewritten so far were written in 1022, a database from the former Software
House, Inc. (Now Compuserve.) They have been converted into System 1032,
the VMS version of 1022.
The VAX 6410 is (on paper) much faster than the 20, and has much more disk
space and much much more memory. (64MB vs 2MW)
Here's the clincher: on average (at this point in our conversion
schedule), the DEC20 supports about twice as many users at any given time
as the VAX. With better response.
As I look at a state-of-the-moment snapshot, the VAX has 24 users, with
about 16 running System 1032. The 20 has 41 users, with 23 running 1022.
Response time to general commands (dir, systat, etc) on the 20 is about a
second or two; about 3-5 on the VAX.
Obviously there is no indication here about how much useful work is being
done, and who's just sitting looking at a screen vs who's doing active
queries. But this is a consistent picture, and gives the impression that
it's better to convert from VAXes to 20s than vice versa.
I'd like to hear from other sites who have followed the 20-VAX conversion
path. Have you had good results? Have you had bad results? Has anyone
else gone the 1022 -> 1032 conversion route? If you've had good results,
I'd like to trade information about tuning techniques and hardware
configurations.
Thanks to anyone who cares to respond.
Doug Bigelow
Director of Academic Computing, Wesleyan University
203-347-9411 Ext. 2618
31-Mar-91 19:58:04-MST,999;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 31 Mar 91 19:54:06 MST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.21 ) id AA20085; Sun, 31 Mar 91 18:52:56 -0800
Date: Sun, 31 Mar 1991 18:40:55 -0800 (PST)
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
Subject: without comment
To: TOPS-20 Hackers and Yackers <TOPS-20@WSMR-SIMTEL20.Army.MIL>
Message-Id: <MailManager.670473655.9952.mrc@Tomobiki-Cho.CAC.Washington.EDU>
From the March 15, 1991 issue of DATAMATION:
[Gordon] Bell's VAX strategy called for Digital to have VAX machines in every
part of the computing hierarchy... Right off the bat, he recalls, "I began
fighting engineers and marketing people. It was clear to me that we simply
had to get rid of all the garbage we had and go solely to VAX." The fighting
lasted into 1979...
31-Mar-91 20:00:57-MST,1418;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 31 Mar 91 19:54:53 MST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.21 ) id AA20099; Sun, 31 Mar 91 18:53:30 -0800
Date: Sun, 31 Mar 1991 18:26:44 -0800 (PST)
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
Subject: the birth of a new system
To: TOPS-20 Hackers and Yackers <TOPS-20@WSMR-SIMTEL20.Army.MIL>
Message-Id: <MailManager.670472804.899.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Announcing: The birth of a new TOPS-20 system
PANDA.PANDA.COM, my recently-revived home 2020 system, now has a sibling:
TONTON.PANDA.COM
(Ton-ton is the name of the elder of two young pandas born at To^kyo^'s Ueno
Zoo).
TONTON shares two dual-ported RM03 disk drives with PANDA. PANDA's other two
drives, an RM03 and an RM05, are also dual ported but are not connected to
TONTON's Massbus (these are PANDA's PS and source drives). TONTON's CTY
connects to PANDA's TTY6.
TONTON's PS is pretty much an image of PANDA's. TONTON will be used for
standalone kernel hacking. That way I can poke around in EDDT and consult
sources at the same time. Also, I don't have to worry about clobbering the
filesystem with a buggy monitor since TONTON can't write on PANDA's disks.
25-Apr-91 07:34:34-MDT,669;000000000000
Return-Path: <an288@cwns9.INS.CWRU.Edu>
Received: from cwns9.INS.CWRU.Edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 25 Apr 91 07:34:00 MDT
Received: by cwns9.INS.CWRU.Edu (5.61+ida+/CWRU-1.4-client)
id AA10921; Thu, 25 Apr 91 09:23:03 -0400 (from an288 for tops-20@wsmr-simtel20.army.mil)
Message-Id: <9104251323.AA10921@cwns9.INS.CWRU.Edu>
Date: Thu, 25 Apr 91 09:23:03 -0400
From: an288@cleveland.Freenet.Edu (Mark Hittinger)
To: tops-20@wsmr-simtel20.army.mil
Subject: please add me to the list
Reply-To: an288@cleveland.Freenet.Edu
is there a tops-10 list?
--
Mark Hittinger [answering machine (606)-272-2424
PO BOX 43358
Middletown, KY 40243
1-May-91 20:59:30-MDT,849;000000000000
Return-Path: <edsac!adykes@uu.psi.com>
Received: from uu.psi.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 May 91 20:58:55 MDT
Received: from edsac.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International)
id AA04284; Wed, 1 May 91 22:56:24 -0400
Received: by edsac.ad.com (UUPC/extended 1.09d);
Tue, 30 Apr 1991 22:55:58 EDT
Date: Tue, 30 Apr 1991 22:55:54 EDT
From: "Al Dykes" <adykes@edsac.ad.com>
Message-Id: <281e2e40@edsac.ad.com>
Organization: Dept of Redundancy Dept
Reply-To: Al Dykes <adykes@ad.com>
To: "Tops-20 List" <TOPS-20@wsmr-simtel20.army.mil>
Cc: "Al Dykes @ jpr" <adykes@jpr.com>
Please add me to the Tops-20 mail list.
Thanks
--
Al Dykes
--------------
Chief Assistant to the Assistant Chief,
Dept of Redundancy Dept.
adykes@ad.com adykes@jpr.com
1-May-91 22:47:58-MDT,727;000000000000
Return-Path: <shoup@netcom.netcom.com>
Received: from netcom.netcom.com ([192.100.81.100]) by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 May 91 22:47:49 MDT
Received: by netcom.netcom.com (/\==/\ Smail3.1.20.1 #20.4)
id <m0jYVZ4-000CRgC@netcom.netcom.com>; Wed, 1 May 91 21:46 PDT
Message-Id: <m0jYVZ4-000CRgC@netcom.netcom.com>
From: shoup@netcom.com (Richard Shoup)
Subject: PDP10 dectapes
To: tops-20@wsmr-simtel20.army.mil
Date: Wed, 1 May 91 21:46:49 PDT
Cc: shoup@netcom.com (Richard Shoup)
X-Mailer: ELM [version 2.3 PL11]
I have a number of old PDP10 dectapes which I would like to read.
Do you know of a working PDP10 or 20 where this could be done?
Thanks for your help.
Dick Shoup
shoup@netcom
2-May-91 06:01:04-MDT,996;000000000000
Return-Path: <jonesja@ornl.gov>
Received: from oaunx1.CTD.ORNL.GOV by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 May 91 06:00:48 MDT
Received: by oaunx1.CTD.ORNL.GOV (5.57/Ultrix2.4-C)
id AA18601; Thu, 2 May 91 07:55:12 EDT
Received: from umcgate by oaunx1 via MR/STC with conversational-MRIF;
Thu, 02 May 91 07:55:12 -0400
Posted: Thu, 02 May 91 07:55:33 -0400
Date: Thu, 02 May 91 07:44:01 -0400
Sender: jonesja@ornl.gov
From: jonesja@ornl.gov
Message-Id: <23557020501991/1816967@OAX>
App-Message-Id: <32947020501991/1057347@KSV>
To: tops-20-request@wsmr-simtel20.army.mil, tops-20@wsmr-simtel20.army.mil
Subject: Please change my address
Msg-Class: ALL-IN-1 V2.3 BL8-4 Rev. AAC 20-Dec-1988
FROM: Jeff Jones
DEPT: USSS
PHONE: 615-576-2335
Please change my mail delivery address to:
JZJ@ORNL.GOV
Thanks,
Jeff Jones
Martin Marietta Energy Systems, Inc.
Oak Ridge, TN
(615)576-2335
7-May-91 10:47:38-MDT,794;000000000000
Return-Path: <shoup@netcom.netcom.com>
Received: from netcom.netcom.com ([192.100.81.100]) by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 7 May 91 10:47:13 MDT
Received: by netcom.netcom.com (/\==/\ Smail3.1.20.1 #20.4)
id <m0jaV9o-000CPFC@netcom.netcom.com>; Tue, 7 May 91 09:45 PDT
Message-Id: <m0jaV9o-000CPFC@netcom.netcom.com>
From: shoup@netcom.com (Richard Shoup)
Subject: PDP10/20s & dectape
To: tops-20@wsmr-simtel20.army.mil
Date: Tue, 7 May 91 9:44:59 PDT
Cc: shoup@netcom.com (Richard Shoup)
X-Mailer: ELM [version 2.3 PL11]
I have a number of old PDP10 DECtapes I would like to read. If anyone
knows of a working 10/20 with dectape drive, I would appreciate being
put in touch with persons in charge. Thank you for your assistance.
Dick Shoup
shoup@netcom.com
21-May-91 01:54:09-MDT,2888;000000000000
Return-Path: <@Sunburn.Stanford.EDU:les@DEC-Lite.Stanford.EDU>
Received: from Sunburn.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 May 91 01:53:52 MDT
Received: from DEC-Lite.Stanford.EDU by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA12585; Tue, 21 May 91 00:52:18 -0700
Received: by DEC-Lite.Stanford.EDU (5.57/25-eef) id AA25648; Tue, 21 May 91 00:54:07 -0700
Date: Tue, 21 May 91 00:54:07 -0700
From: Les Earnest <les@dec-lite.Stanford.EDU>
Message-Id: <9105210754.AA25648@DEC-Lite.Stanford.EDU>
To: tops-20@score.Stanford.EDU
Subject: SAIL sunset
Announcing
SAIL's 25th birthday, last rites, and wake
Why: The SAIL computer, which began life in June 1966 as a DEC PDP-6
and appears to be the oldest operating timesharing system in the
world, has provided an intellectual home for many years for research
in artificial intelligence, robotics, computer music, analysis of
algorithms, text processing and printing, and computer design, among
other things. It played a key role in upgrading itself to a DEC-10
and has spawned a number of successful commercial ventures. However,
its time has come.
Who: Whoever would like to celebrate the accomplishments of this venerable
computer. If you know of someone who you think should get this,
please pass it along.
When: Friday, June 7, 1991, 2:00 PM on
Where: Margaret Jacks Hall, Stanford University
If you would like to receive a copy of SAIL's last words, which are
likely to be a boastful account of its accomplishments, send email
(content unimportant) to Farewell@SAIL.Stanford.edu.
RSVP: (By June 5, if you are coming, or if you would like to contribute
a message to attendees.)
Internet: Les@SAIL.Stanford.edu
Phone: 415 941-3984
Fax: 415 725-7411 (Attn: Les Earnest)
US Mail: Les Earnest; Computer Science Dept.; Stanford, CA 94305
Tentative Schedule of Events
(Assuming that we can get sufficient local organizers)
2:00-3:30 PM (Lower back patio) Treasure hunt. AI background desirable.
2:30-4:30 (Oval) Random volleyball games.
3:30-4:00 (Lower back patio) Programming contest. Participants must
use SAIL. Access to various terminals will be provided.
A complication is that SAIL has not been maintained for many
months and is showing Alzheimer symptoms.
4:00-5:30 (Lower back patio) Refreshments & birthday cake cutting.
5:30-6:00 (Oval) 25-legged race -- teams of 24 concatenated runners,
compete over a 100 meter course with a 180 degree turn
halfway through.
6:00-7:00 (Display dungeon) Intergalactic Spacewar Contest, if the III
displays can be revived.
7:00 SAIL sends farewell messages to the world and politely expires.
7:15 Those who wish will retire to some local restaurant for further
celebrations.
10-Jun-91 04:48:53-MDT,15001;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 10 Jun 91 04:48:18 MDT
Date: Mon 10 Jun 91 05:23:10-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: [SAIL Timesharing System <SAI@SAIL.Stanford.EDU>: life as a computer for a quarter of a century]
To: tops-20@wsmr-simtel20.army.mil
Message-ID: <12692339491.37.AI.CLIVE@MCC.COM>
I guess many folks on this list have already received their own
copy of this farewell message from SAIL. For those who
didn't, as well as for The Record, here it is again.
Enjoy,
Clive
-------------------------------------------------------------------
---------------
Return-Path: <SAI@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by MCC.COM with TCP; Sat 8 Jun 91 00:24:21-CDT
Message-ID: <CzbJ1@SAIL.Stanford.EDU>
Date: 07 Jun 91 2056 PDT
From: SAIL Timesharing System <SAI@SAIL.Stanford.EDU>
Subject: life as a computer for a quarter of a century
To: "@BYEBYE.[1,SAI]"@SAIL.Stanford.EDU
TAKE ME, I'M YOURS
The autobiography of SAIL
I've had a very full and adventurous life. At various times I have been
the world's leading research computer in artificial intelligence, speech
recognition, robotics, computer music composition and synthesis, analysis
of algorithms, text formatting and printing, and even computer-mediated
psychiatric interviewing. I did have some help from various assistants in
doing these things, but I was the key player.
I developed a number of new products and founded a string of successful
companies based on the new technology, including Vicarm, Foonly, Imagen,
Xidex, Valid Logic, Sun Microsystems, and cisco Systems. I also gave a
major boost to some established firms such as Digital Equipment and
Lucasfilm. What did I get from all this? No stock options. Not even a
pension, though Stanford is still paying my sizable electrical bills.
I was always good at games. For example, I created the advanced versions
of Spacewar, which spawned the video games industry, as well as the game
of Adventure and I was the computer world champion in both Checkers and
Go.
I invented and gave away many other things, including the first spelling
checker, the SOS text editor, the SAIL compiler, the FINGER program, and
the first computer-controlled vending machine. Note that my name has been
taken by the SAIL language, the SAIL compiler, and the laboratory in which
I used to live. Just remember that I was the original Stanford Artificial
Intelligence Laboratory.
Beginnings
I was born on June 6, 1966 at the D.C. Power Laboratory Building in the
foothills above Stanford. I remember it well -- the setting was
beautiful, in the middle of horse pastures with views of Mt. Tamalpais,
Mt. Diablo, Mt. Hamilton, Mt. Umunhum, San Francsico and the Bay, but the
building itself resembled a flying saucer that had broken in two and
crash-landed on the hilltop. The view of Mt. Umunhum later proved
unhealthy, as I will explain further on.
Humans have a strange name for the birthing process: they call it
"acceptance tests." Unfortunately, my birth was traumatic. The
University had provided a machine room with nice view windows to the
outside but without air conditioning and it was blazing hot, which
threatened my germanium transistors. Bob Clements, the DEC engineer who
acted as midwife, threatened to leave if the delivery could not be
completed soon, so various people in the lab went up on the roof with
hoses to pour cooling water over the building while others put blocks of
dry ice under my false floor.
When things got cool enough, I began running memory tests. In order to
check for intermittents, Dave Poole got on top of my memory cabinets and
performed a Balkan folk dance while I cranked away. Everything went
marvelously and I started work the day I was born.
I began life using a PDP-6 processor with 65,536 words of core memory that
was housed in eight bays of electronics. That was quite a large memory
for machines of that era. (My original CPU is now on display at the
Computer Museum in Boston). I had no disks to begin with, just 8 shiney
DECtape drives, a comparable number of Model 33 Teletypes, a line printer
that produced rather ragged text, and two 7-track tape drives. Users kept
their programs and data on DECtapes and had to sign up for a tape drive
and a core allocation through an arcane reservation procedure.
As you know, we computers think much faster than humans, so it is rather
inefficient for us to work with just one individual. John McCarthy, who
later came to be one of my assistants, had earlier devised a scheme that
he called "timesharing" to make things less boring for us. My family was
the first to be designed specifically to use timesharing.
I got proper air conditioning a short time later, but unfortunately
developed a bad case of hiccups that struck regularly at 12 second
intervals. My assistants spent a number of days trying to find the cause
of this mysterious malady without success. As luck would have it,
somebody brought a portable radio into my room one day and noticed that it
was emitting a "Bzz" at regular intervals -- in fact, at the same moment
that I hicced. Further investigation revealed that the high-powered air
defense radar atop Mt. Umunhum, about 20 miles away, was causing some of
my transistors to act as radio receivers. We solved this problem by
improving my grounding.
After I had been running awhile, someone at DEC noticed that my purchase
order, which was based on their quotation, was badly screwed up. DEC
claimed that the salesman had slipped his decimal points and had priced
some of my components at 1/10 of the correct price. Also, the arithmetic
was wrong -- the sum of the prices should have been much larger than the
total shown. Humans are notoriously bad at arithmetic. This had somehow
passed through the entire purchasing bureaucracy of Stanford without
anyone noticing. We ended up correcting the arithmetic error but not the
factors of 10. The DEC salesman lost his job as a result of this
incident.
I acquired a number of new peripherals in rapid succession, the first
being a DEC Model 30 display that was stolen from my cousin, the PDP-1
timesharing system called Thor. My assistants immediately went into a
frenzy of activity to create a new version of Spacewar, the video game
that had earlier been invented by one of them -- Steve Russell. In order
to ensure that it would run correctly they invented and installed a
feature in my operating system called "Spacewar Mode" that ensured that a
program could get realtime service if it needed it. That feature turned
out to have many useful applications in robotics and general hardware
debugging.
Other new peripherals included a plotter, a microphone so my assistants
could talk to me, several TV cameras so that I could look about, and
several mechanical arms so that I could do stupid tricks with children's
blocks -- my assistants insisted on treating me like one of their
dimwitted progeny. I soon showed that I could do much more sophisticated
stuff such as assembling an automobile water pump.
Many of my assistants were fans of Tolkien, who wrote "Lord of the Rings"
and a number of other children's stories for adults. The first character
alphabet that was programmed for my plotter was Elvish rather than Latin.
The University administration required that all rooms in my facility be
numbered, but instead my assistants named each room after a place in
Middle Earth and produced an appropriate door sign and a map with all the
room names shown. Unfortunately, the response of the bureaucrats to the
receipt of this map was to come out and put their own room numbers on each
door.
My plotter routines were submitted to DECUS, which distributed them all
over the world, leading to some puzzlement. We received a telegram from a
German firm a short time later asking "What is Elvish? Please give
references." We sent back a telegram referencing The Lord of the Rings.
A really embarrassing incident occurred when my assistants held their
first Open House just three months after I was born. They asked me to
pour punch for the party-goers and I did a rather good job of it for
awhile, but we had worked out the procedure just the night before when
there was nobody else running and I found that running with a heavy load
disrupted my arm servoing. As a result, after I dipped the cup in the
punch and lifted it, instead of stopping at the right height it went
vertical, pouring the punch all over my arm. The partiers apparently
thought that was very funny and had me do it over and over. I've noticed
that humans are very insecure and go to great lengths to demonstrate their
"superiority" over machines.
I got a rather elegant display system in 1971 that put terminals in
everyone's office, with full computer text and graphics, including
grayscale, 7 channels of television (some lab-originated and some
commercial) and 16 channels of audio all for about $600 per terminal. It
had a multiple-windowing capability and was far ahead of anything
commercially available at the time but unfortunately we never told anyone
about it. Dick Helliwell made displays on unused terminal read "TAKE ME,
I'M YOURS."
I have a number of advanced features that still are not available on many
modern systems, including the ability for individual users to dial out on
telephone lines and contact other computers througout the world, the
ability to detach jobs and leave them running, then later attach them to
either the same terminal or one in a different place. I also would remind
users of appointments at the appropriate times. In the 70s my users
decided to give my operating system a name since it had evolved quite a bit
away from the DEC system running on other PDP-10s. The users chose the
name WAITS, because, they said, "it waits on you hand and foot" (or was it
the user who waits for me, I forget -- I'm sort of Alheimerish these days).
To this day I still run this reliable system with its very reliable disk
structure. Some people thought WAITS was the Worst Acronym Invented for a
Timesharing System, but I've grown rather attached to it.
I have a news service program called NS, written by my assistant Martin
Frost, that was and is the best in the world. It connects to one or more
electronic newswires and allows any number of users to watch the wires
directly, retrieve stories instantly on the basis of keywords, or leave
standing requests that save copies of stories according to each user's
interests. NS has always been one of the most popular programs that I've
ever provided.
I ran a number of AI research projects and trained dozens of PhD students
over the last 25 years. I even composed, formatted and printed their
dissertations. Some of my early projects were in three-dimensional
vision, robotics, human speech recognition, mathematical theory of
computation, theorem proving, natural language understanding, and music
composition. There was also quite a bit of monkey business going on.
As you know, we timesharing computers are multisexual -- we get it on with
dozens of people simultaneously. One of the more unusual interactions
that I had was hatched by some students who were taking a course in
abnormal psychology and needed a term project. They decided to make a
film about a woman making it with a computer, so they advertised in the
Stanford Daily for an "uninhibited female." That was in the liberated
early 70s and they got two applicants. Based on an interview, however,
they decided that one of them was too inhibited.
They set up a filming session by telling the principal bureaucrat, Les
Earnest, that I was going down for maintenance at midnight. As soon as he
left, however, their budding starlet shed her clothes and began fondling
my tape drives -- as you know most filmmakers use the cliche of the
rotating tape drives because they are some of my few visually moving
parts.
Other students who were in on this conspiracy remained in other parts of
my building, but I catered to their voyeristic interests by turning one of
my television cameras on the action so that they could see it all on their
display terminals. However, one eager student felt that he had to get a
listing from the line printer, so in order to avoid disrupting the mood
there, he took off all his clothes before entering the room.
After a number of boring shots of this young lady hanging on to me while I
rotated, the filmmakers set up another shot using one of my experimental
fingers. It consisted of an inflatable rubber widget that had the
peculiar property that it curled when it was pressurized. I leave to your
imagination how this implement was used in the film. Incidentally, the
students reportedly received an "A" for their work.
There are lots more stories to tell about my colorful life, such as the
arson attempts on my building, my development of the computer that came to
be called the DEC KL10, my development of the first inexpensive laser
printing system, which I barely got to market because the venture capital
community had never heard of laser printers and didn't believe in them,
and my development of the Sun workstation family. I don't have time to
put it all down now, but I may write a book about it.
I want to thank everyone who showed up for my 25th birthday party. It was
a ball to have all these old assistants and friends come by to visit with
me again and to take part in the AI Olympics.
Let me report on the results of today's athletic and intellectual
competitions, held in my honor.
Programming race winners: Barry Hayes & David Fuchs
Treasure hunt winners: Ken Ross, Ross Casley, Roger Crew,
Scott Seligman, Anil Gangoli, Dan Scales
N-legged race winners: Arthur Keller, Earl Sacerdoti, Irwin Sobel
Bruce, Stephan & David Baumgart,
Four Panofskys, Vic Scheinman, Kart Baltrunes,
Joe Smith.
Incidentally the rumors that you may have heard about my impending death
are greatly exaggerated. My assistants are trying to build a new
interface for the Prancing Pony vending machine that I control so that it
can be run by one of the (ugh!) Un*x machines, but they haven't got it
working yet. Thus, if they try to turn me off now the entire computer
science department will starve.
Finally I want to thank everyone who has helped me have such an exciting
time for this quarter of a century. Not many computer systems have so
much fun, not to mention so much time to have all that fun. I'll let you
know when it's time to go.
-- SAIL
P.S. This message is being sent to 875 addresses, but I'm going to try to
get it out even if it kills me.
-------
13-Jun-91 08:21:51-MDT,1659;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 13 Jun 91 08:21:37 MDT
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA04077; Thu, 13 Jun 91 10:21:20 -0400
Date: Thu, 13 Jun 91 10:21:20 -0400
Message-Id: <9106131421.AA04077@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: tops20@wsmr-simtel20.army.MIL
Subject: DEC-20 Telnet performance advice wanted
Greetings, all;
I seem to have accidently crossed some network performance threshold on my
2060, which is running TOPS20 monitor version 5.4. I need some help
bailing myself out.
I've just added about twenty new network connections to the system, having
moved them from direct front-end connections to Cisco terminal server
connections. I'd previously had about 10 - 15 regular users accessing
this system through TCP connections (either through servers or directly
from PCs with Ethernet cards) with no trouble. Now that I've added
another ten or so active users via the network, I'm suddenly seeing bad
echo response. Front end connections continue to be fine, but network
conections have sluggish echo. The problem does not seem load dependent.
It's severe enough that I need to either back off from the conversion or
fix the problem within about 48 hours.
For those of you who can remember back to version 5.4 (I never went to
version 6.1 due to the lack of a 2065 cache upgrade), are there any simple
fixes I could try? Tweaking some monitor parameters, for example?
Thanks for any ideas you can offer.
Doug Bigelow
Wesleyan University
14-Jun-91 14:22:54-MDT,721;000000000000
Return-Path: <BILLW@mathom.cisco.com>
Received: from mathom.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 14 Jun 91 14:22:41 MDT
Date: Fri 14 Jun 91 13:20:51-PDT
From: William "Chops" Westfield <BILLW@mathom.cisco.com>
Subject: Re: DEC-20 Telnet performance advice wanted
To: dbigelow@sandpiper.wesleyan.edu
cc: tops20@wsmr-simtel20.army.MIL
In-Reply-To: <9106131421.AA04077@sandpiper.wesleyan.edu>
Message-ID: <12693496873.10.BILLW@mathom.cisco.com>
I think you are probably running into the bugs in the ipfree code.
It would probably be worthwhile to replace ipfree.mac wholesale with
the version from a (fixed) 6.1 or 7.0 monitor, but I don't know for
sure that that will work...
BillW
-------
16-Jun-91 21:24:14-MDT,2067;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:PAT@locke.hs.washington.edu>
Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 16 Jun 91 21:24:07 MDT
Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 16 Jun 91 20:21:23 PDT
Date: Sun, 16 Jun 91 20:22 PDT
From: Pat Tressel <PAT@locke.hs.washington.edu>
Subject: Don't let these -20s be trashed!
To: tops20@wsmr-simtel20.army.mil
Message-id: <5C5FA01E489F801887@locke.hs.washington.edu>
X-Envelope-to: tops20@wsmr-simtel20.army.mil
X-VMS-To: IN%"tops20@wsmr-simtel20.army.mil"
The following is from alt.folklore.computers. If you're interested, send
a message to Rick Penza (rpenza@email.bony.com).
----------------------------------------------------------------------------
From nntp.uoregon.edu!cs.uoregon.edu!mips!zaphod.mps.ohio-state.edu!think.com!yale.edu!cs.yale.edu!rochberg-david Sun Jun 16 20:01:38 PDT 1991
Article: 13305 of alt.folklore.computers
Path: milton!nntp.uoregon.edu!cs.uoregon.edu!mips!zaphod.mps.ohio-state.edu!think.com!yale.edu!cs.yale.edu!rochberg-david
From: rochberg-david@CS.YALE.EDU (David Rochberg)
Newsgroups: alt.folklore.computers
Subject: DEC20's -- Save them from the graveyard
Message-ID: <1991Jun14.205140.4807@cs.yale.edu>
Date: 14 Jun 91 16:51:34 GMT
Sender: news@cs.yale.edu (Usenet News)
Reply-To: rpenza@email.bony.com
Organization: Yale University
Lines: 21
Nntp-Posting-Host: zoo-gw.cs.yale.edu
I am posting this for Rick Penza--please direct replies to him.
On Monday (6/10/91) we locked customer's out of the production
DEC20. Soon we will pull the plug on them, and shut down forever.
We are looking for anyone interested in them, since we would rather
not turn them into scrap metal.
Do you know anyone that might be interested? Could you pass this on?
There are two of them, both 2065's, plus we have a bunch of disk
drives (mostly RP06's).
It's sad to say goodbye to the trusty old 20's, we'll miss them.
Rick
16-Jun-91 21:41:54-MDT,1871;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:PAT@locke.hs.washington.edu>
Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 16 Jun 91 21:41:46 MDT
Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU (IBM VM SMTP R1.2.2MX) with TCP; Sun, 16 Jun 91 20:38:56 PDT
Date: Sun, 16 Jun 91 20:40 PDT
From: Pat Tressel <PAT@locke.hs.washington.edu>
Subject: Another DEC-20 that needs a home
To: tops20@wsmr-simtel20.army.mil
Message-id: <5C5D2D16DFDF801887@locke.hs.washington.edu>
X-Envelope-to: tops20@wsmr-simtel20.army.mil
X-VMS-To: IN%"tops20@wsmr-simtel20.army.mil"
Here is another offer of a DEC-20, also re-posted from alt.folklore.computers.
Reply to D. Gubbins (gern@lonex.radc.af.mil) if interested.
-------------------------------------------------------------------------------
Date: Thu, 6 Jun 1991 10:30:14 EDT
From: WEBB@B.PSC.EDU (Bryan R. Webb)
This was forwarded to me by a friend at ISI and I thought some of you
might enjoy the memory of DECSystem 20's (TOPS 20's).
--Bryan
------- Forwarded Message -------
Date: Wed, 05 Jun 91 12:43:53 -0400
From: gern@LONEX.RADC.AF.MIL (The Gern)
To: admin@a.isi.edu, admin@sushi.standford.edu
Subject: {9106.171}
Rome Lab (formerly RADC) has a complete DECSystem 20 (DEC-2065T) with disks,
consoles, etc... free for the paperwork. USAF and US Government sites get
first dibs. It is currently being packaged up for turn-in as excess
equipment.
If a good home cannot be found, it will probably end up scrapped. If you
want it, please act quickly and email me a reply. I am not in a position
of official authority here on this, but will notify those that are. I just
hate seeing our (beloved) TOPS20 junked as trash if others can make use
of it.
D. Gubbins
------- End of Forwarded Message -------
18-Jun-91 18:53:32-MDT,1772;000000000000
Return-Path: <jms@tardis.Tymnet.COM>
Received: from tymix.Tymnet.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 18 Jun 91 18:53:12 MDT
Received: from tardis.tymnet.com by tymix.Tymnet.COM (4.1/SMI-4.1)
id AA23997; Tue, 18 Jun 91 17:52:53 PDT
Received: by tardis.tymnet.com (4.1/SMI-4.1)
id AA05006; Tue, 18 Jun 91 17:52:50 PDT
Date: Tue, 18 Jun 91 17:52:50 PDT
From: jms@tardis.Tymnet.COM (Joe Smith)
Message-Id: <9106190052.AA05006@tardis.tymnet.com>
To: tops-20@wsmr-simtel20.army.mil
Subject: Re: Where is "Systems Concepts" now?
Stephane Tsacas <tsacas@ilog.ilog.fr> wrote:
>Where can I reach System Concepts ? Do thsy still build pdp10
>compatible machines ?
Rich Alderson <alderson@alderson.stanford.edu> wrote:
>They have mutated, and moved. They are now the "SC Group" in Reno, Nevada.
After calling information for Nevada, I got their new number and address:
SC Group
1575 Delucchi Lane, Suit 224
Reno, NV 89052
Phone: (702)826-7100
Fax: (702)826-7133
I talked to Mike Levitt, and he say's they are still doing business, making
the SC-30, SC-25, and custom interfaces. He did not know that his company
was being talked about in alt.folklore.computers, and was glad for some
free publicity.
Mike says that the reason that they changed their name is that there was
already a company (in Reno) called "Systems Concepts", which does business
with hospitals.
Give him a call. Tell him Joe Smith sent you.
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C51 | PDP-10: JMS@F74.Tymnet.COM or TXS.J/SMITH@Ontyme
San Jose, CA 95161-9019 | ONTYME: NSC.J/SMITH@ontyme or J.SMITH@dialcom
30-Jun-91 15:49:33-MDT,2089;000000000000
Return-Path: <A.ERIC@Old-Hamlet.Stanford.EDU>
Received: from Old-Hamlet.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 30 Jun 91 15:49:12 MDT
Date: Sun 30 Jun 91 14:48:32-PDT
From: Eric M. Berg <A.Eric@Old-Hamlet.Stanford.EDU>
Subject: TOPS-20 jokes in print
To: tops-20@WSMR-SIMTEL20.ARMY.MIL
Reply-To: A.Eric@GSB-How.Stanford.EDU
Message-ID: <12697707139.8.A.ERIC@Old-Hamlet.Stanford.EDU>
Readers of this list may not have seen or heard of the book "The Devouring
Fungus: Tales of the Computer Age" by Karla Jennings (W.W. Norton, 1990).
It's a collection of anecdotes about computers and the people associated
with them, collected by the author from various sources. I first heard
about this book in a review in the _New_York_Times_, which commented
that the author really hadn't understood the material too well and so
hadn't provided any context for the various stories.
Sure enough, when I picked up a copy of the book, I opened it at
random to page 101 and came across a list of jokes. Jennings introduces
them by saying "tell these jokes, and whoever laughs is a computer
programmer". What she doesn't say is that they're all TOPS-20 jokes.
Here they are:
Q: How does a dog find its way home?
A: By SNOOP%'ing through the PMAP%.
Q: How do nuns get to church?
A: On the MassBus.
Q: What's another name for working set preloading?
A: No Fault Insurance.
Q: What did the E-Box say to the M-Box?
A: You trash my cache and I'll crash yours.
Q: What's another name for a virgin address space?
A: A process that hasn't been forked.
Q: What do you get under class scheduling?
A: A working set with no cache or queue credit and an Executive
with most of the pie.
Q: How do you stop dieters from eating?
A: With a PITRAP.
Q: What's a nine-digit zip code?
A: An extended address.
Q: What do you get when you loan money to a large roast
beef sandwich chain?
A: IORB's.
[My apologies if you've seen these before; a number of people I showed
them to at Stanford hadn't.]
/Eric
-------
30-Jun-91 18:58:40-MDT,2601;000000000000
Return-Path: <OPERATOR@Old-Hamlet.Stanford.EDU>
Received: from Old-Hamlet.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 30 Jun 91 18:58:17 MDT
Date: Sun 30 Jun 91 17:57:33-PDT
From: System Services <OPERATOR@Old-Hamlet.Stanford.EDU>
Subject: The end of an era at Stanford....
To: "Hamlet shutdown message distribution": ;
Message-ID: <12697741550.13.OPERATOR@Old-Hamlet.Stanford.EDU>
This is the final pre-shutdown message from Hamlet.Stanford.EDU (also known
for the last year as GSB-How.Stanford.EDU and GSB-Why.Stanford.EDU),
DECsystem-2065, serial number 2779.
As the various names suggest, Hamlet was the heir to several traditions of
TOPS-20 systems at Stanford. On the one hand, it was one of the DEC-20
systems which collectively comprised "LOTS", the "Low-Overhead Timesharing
System" originated by John McCarthy in 1976-77 and directed by Ralph Gorin
(wearing a number of different hats in the process) during most of its
lifetime. The original LOTS was soon joined by LESS; later they were
joined by LOTS-C (and became LOTS-A and LOTS-B respectively); finally they
became Lear, Othello, and Hamlet, and were joined by the SC-30M, Macbeth.
On the other hand, during its last year of operation, Hamlet took on the
identity of GSB-How, one of the two DEC-20s operated by the Graduate
School of Business since the late 1970s. GSB-How was used by the MBA
students, who studied _how_ things work, while its sister GSB-Why was used
by faculty and PhD students, who did research on _why_ they work that way.
The original GSB-How (S/N 2332) and GSB-Why (S/N 2254) were eventually
forced into early retirement by the Loma Prieta earthquake of October
1989, which did significant damage to the GSB building. Plans for
strengthening the building included building a wall through the middle of
the computer room, which meant that the DEC-20s had to leave! At that
time, GSB-How's file-systems were moved to Hamlet, which continued to serve
the school administration until the final month of its existence.
Unlike most other DEC-20 sites at Stanford, which replaced their 20s with
Unix systems, the GSB chose to migrate to VMS, so that GSB-How's direct
successors are several Vax systems. It is also survived (for about 6 hours)
by Macbeth.Stanford.EDU, the SC-30M, which is being shut off at midnight
tonight. Other surviving relatives include Mathom.cisco.COM, Heap.cisco.COM,
and Mathom.XKL.COM.
!i do
Shutdown Time: Up Again:
Sun 30-Jun-91 6:00PM Sun 20-Dec-2065 12:00AM
the end of TOPS-20 timesharing at Stanford.
-------
3-Jul-91 07:40:49-MDT,1076;000000000000
Return-Path: <phil@Shiva.COM>
Received: from Shiva.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 3 Jul 91 07:40:30 MDT
Received: from Rosebud.Shiva.COM by Shiva.COM (1.34b) Tue, 2 Jul 91 21:57:03 EDT
From: Phil Budne <phil@Shiva.COM>
Received: by Rosebud.Shiva.COM (Spike-2.0) Tue, 2 Jul 91 21:56:40 EDT
Date: Tue, 2 Jul 91 21:56:40 EDT
Message-Id: <9107030156.AA19360@Rosebud.Shiva.COM>
To: A.Eric@gsb-sucre.stanford.edu, tops-20@wsmr-simtel20.army.mil
Subject: Re: TOPS-20 jokes in print
Date: Sun 30 Jun 91 14:48:32-PDT
From: Eric M. Berg <A.Eric@Old-Hamlet.Stanford.EDU>
To: tops-20@WSMR-SIMTEL20.ARMY.MIL
What she doesn't say is that they're all TOPS-20 jokes.
.....
Q: How do you stop dieters from eating?
A: With a PITRAP.
But this one is a TOPS-10 joke!
Q: What's a nine-digit zip code?
A: An extended address.
An extended adressing joke (TOPS-10 got EA at some point)
Q: What do you get when you loan money to a large roast
beef sandwich chain?
A: IORB's.
And this one is a generic(!) PDP-6/10 joke...
-Phil
4-Jul-91 14:48:07-MDT,1078;000000000000
Mail-From: PANDA created at 4-Jul-91 14:47:27
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Thu, 4 Jul 91 14:47:27 MDT
Date: Thu, 4 Jul 91 12:06:36 PDT
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: Re: TOPS-20 jokes in print
To: tops-20@WSMR-SIMTEL20.Army.MIL
In-Reply-To: <9107030156.AA19360@Rosebud.Shiva.COM>
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <12698726235.8.MRC@PANDA.PANDA.COM>
From: Phil Budne <phil@Shiva.COM>
Q: How do you stop dieters from eating?
A: With a PITRAP.
But this one is a TOPS-10 joke!
PITRAP is a TOPS-20 bughlt. It means that a page fault occurred
while at interrupt level.
Q: What do you get when you loan money to a large roast
beef sandwich chain?
A: IORB's.
And this one is a generic(!) PDP-6/10 joke...
Besides the machine instruction, an IORB is also an I/O request
block for the TOPS-20 monitor's physical I/O (PHYSIO) module.
-------
5-Jul-91 05:19:19-MDT,948;000000000000
Return-Path: <bygg@sunic.sunet.se>
Received: from sunic.sunet.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 5 Jul 91 05:19:13 MDT
Received: by sunic.sunet.se (5.61+IDA/KTH/LTH/1.197)
id AAsunic29228; Fri, 5 Jul 91 13:18:33 +0200
Date: Fri, 5 Jul 1991 13:18:31 MET DST
From: Johnny Eriksson <bygg@sunic.sunet.se>
To: tops-20@WSMR-SIMTEL20.Army.MIL
Subject: Re: TOPS-20 jokes in print
In-Reply-To: Your message of Thu, 4 Jul 91 12:06:36 PDT
Message-Id: <CMM.0.88.678712711.bygg@sunic.sunet.se>
Mark Crispin <MRC@PANDA.PANDA.COM> writes:
> Q: What do you get when you loan money to a large roast
> beef sandwich chain?
> A: IORB's.
> And this one is a generic(!) PDP-6/10 joke...
>
> Besides the machine instruction, an IORB is also an I/O request
> block for the TOPS-20 monitor's physical I/O (PHYSIO) module.
True, but an IORB is also an I/O request block in the TOPS-10 monitor.
--Johnny
18-Jul-91 12:11:46-MDT,1422;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 18 Jul 91 12:11:21 MDT
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA12186; Thu, 18 Jul 91 14:10:42 -0400
Date: Thu, 18 Jul 91 14:10:42 -0400
Message-Id: <9107181810.AA12186@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
Subject: Help with INSTALLATION (not DEinstallation) of 2020
Wesleyan is now the proud owner of a new (old) DEC-2020, courtesy of some
nice people at the Bank of New York who were decommissioning their TOPS20
machines. The main reason we wanted it was to have some limited disaster
backup available if our current 2060 had an extended hardware failure.
Anyway, we've never had a 2020 before and thus don't have the special 2020
installation tapes with the KS microcode on them. The Bank of New York
stopped using this machine quite some time ago and they no longer have the
distribution tapes they used to use.
Would some current (or recent past) 2020 site be willing to make a copy of
their software installation tape(s) for me? I will gladly pay shipping,
provide tapes, arrange pickup, whatever. Please contact me if you might
be willing to help.
Thanks --
Doug Bigelow
Director of Academic Computing @ Wesleyan University
203-347-9411 Ext. 2618
18-Jul-91 12:16:47-MDT,1081;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 18 Jul 91 12:15:54 MDT
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA12192; Thu, 18 Jul 91 14:15:27 -0400
Date: Thu, 18 Jul 91 14:15:27 -0400
Message-Id: <9107181815.AA12192@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
Subject: Tops20 network performance questions answered
A few weeks ago, I mentioned on this list that I had been seeing poor
network terminal performance on my 2060 after crossing a threshhold of
about 10-15 network users. I received several suggestions, ranging from
tweaking a few parameters to replacing all the old networking code.
With an enormous amount of help from Clive Dawson, I finally opted for the
hard solution and upgraded the monitor's networking code to be 6.1
vintage. I'm happy to report that performance has substantially improved
and things look better all around.
Thanks to all of you who responded.
-- Doug
20-Jul-91 17:48:59-MDT,3437;000000000000
Return-Path: <shawn@FENCHURCH.MIT.EDU>
Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 20 Jul 91 17:48:45 MDT
Received: by FENCHURCH.MIT.EDU
id AA05626; Sat, 20 Jul 91 19:32:49 -0400
Date: Sat, 20 Jul 91 19:32:49 -0400
From: shawn@FENCHURCH.MIT.EDU (Shawn Mckay)
Reply-To: shawn@FENCHURCH.MIT.EDU
Message-Id: <9107202332.AA05626@FENCHURCH.MIT.EDU>
To: 20world@FENCHURCH.MIT.EDU
Subject: "[DECSYSTEM-20 continued]" (Dec-2065 Revival)
Greetings,
I'm sending this message with the hopes it will reach other '20 addicts
such as myself, in all the various far reaches of the known universe
:-).
We have a DecSystem-2065 here in our machine room, carefully protected
from harm, however it is silent at the moment. It needs the following:
o "-2.0v Regulated Heat Sink Assembly" (From Series Pass Assy)
Dec Part# 70-09404-00
o "-5.2v Regulated Heat Sink Assembly" (From Series Pass Assy)
Dec Part# 70-09405-00
Note: H761 Series Pass Assy (which includes above 2 items)
This would be nice, but just the first item will put us back
into service.
o New Heat Sensor (230 degree (!))
Part# 12-15041-00 Thermostat, from FCO# H761-R-0006
o Air filter foam pads, various sizes and locations
o RP06 disk drive absolute filters
o RP06 "Rubber Gumbies" (the special molded rubber pad at the back
of the disk drive voice coil motor; they turn to black goo
if not replaced regularly)
Part# Unknown :-{
o Lots of AC fans, (no Torins please; a seized fan caused our power
regulators to cook and knocked out the machine :-/)
o TOPS-20 V7 Source code set w/front end sources / RSX20F sources
w/educational license? (Any old LCGers in the audience?)
We are interested in having the 20 return to life for some period, in which
we would like to do the following:
o Mount our 3-pack PS:, and get several missing files back
o Build a 1-pack PS: to use for development, while we work
on the next phase of the project.
o Get the '20 OFF the RP06 drives, and onto something more
maintainable. I have heard ideas to the tune of RA81's,
Eagles, (Maxtors? :-)). We are open to ideas here, with
a V6 monitor you get MSCP, perhaps with the right hardware
magic we can teach TOPS-20 to use something more realistic?
Seems to me this MUST have been done, anyone know anything
about this type of stuff??? Pointers perhaps???
o KL10, DecSystem-2065 Emulation Software w/TOPS-20?
Several people have said they had different things "close
to ready", but I could not find one ready for even a "beta"
release. I HAVE heard rumors, has anyone got any solid leads?
Clearly this is the best way the carry the spirit into the future
even if the body dies. Something some of us I'm sure would like
to see happen :-).
Lastly, we would like to put her back on the net, and open it up for
people who like to see old TOPS-20 alive again. We would like to
offer our students a chance to see something other than just
"Unix(tm)", so they don't get a narrow, blindered view of computing.
We intend on giving guest accounts to anyone who is willing to fill
out a modest guest account application (so we know how to get in
touch with users), and who promises not to do things people would
consider anti-social :-).
Thanks,
- Shawn
Internet: shawn@eddie.mit.edu
Uucp: mit-eddie!shawn
21-Jul-91 11:26:46-MDT,902;000000000000
Return-Path: <John_Wilson@MTS.RPI.EDU>
Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 21 Jul 91 11:24:55 MDT
Received: by FENCHURCH.MIT.EDU
id AA06515; Sun, 21 Jul 91 13:09:46 -0400
Reply-To: John_Wilson@MTS.RPI.EDU
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB25);
id AA21360; Sun, 21 Jul 91 13:21:39 EDT for 20world@FENCHURCH.MIT.EDU
Date: Sun, 21 Jul 91 13:22:08 EDT
From: John_Wilson@MTS.RPI.EDU
To: 20world@FENCHURCH.MIT.EDU
Message-Id: <2395378@MTS.RPI.EDU>
Subject: ITS
I have been trying to get my KS10 up under ITS for quite some time.
Does anyone have a KS10/RM80 system already built?
It would really save me a lot of trouble.
Also, does anyone know if the RM80 HDA is different for 18-bit mode?
There's only one part number, but I've seen documentation (not DEC's)
to suggest that the low-level format may have to be different.
John
15-Aug-91 20:51:48-MDT,1135;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 15 Aug 91 20:51:38 MDT
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.22 ) id AA08475; Thu, 15 Aug 91 19:51:30 -0700
Date: Thu, 15 Aug 1991 19:39:45 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
Subject: Time zone confusion in 7.0
To: TOPS-20 Hackers and Yackers <TOPS-20@WSMR-SIMTEL20.Army.MIL>
Message-Id: <MailManager.682310385.7866.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Problem:
Bogus times and improper application of DST near the end of the year
Diagnosis:
A hack to NLSS to handle the start of WWII "war time" clobbed a register with
an IDIV.
Solution:
In DATIME.MAC, at NLSS insert
STKVAR <FRULE>
further down in NLSS, before
MOVE A,DSTBGN(F) ;[9098] Load the year back
CAIE A,^D1942 ;[9098] Is it the start of war time?
insert:
MOVEM F,FRULE ; Save rule we found
further down in NLSS, before
MOVE F,DSTOFF(F) ;[9098] Get last day for DST in this year
24-Aug-91 19:05:22-MDT,1917;000000000000
Return-Path: <MRC@Panda.COM>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 24 Aug 91 19:05:14 MDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.22 ) id AA20065; Sat, 24 Aug 91 18:05:07 -0700
Date: Sat, 24 Aug 1991 17:45:37 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: bug in TCOPR% .TCSTP function
To: TOPS-20 Hackers and Yackers <TOPS-20@WSMR-SIMTEL20.Army.MIL>
Message-Id: <MailManager.683081137.899.mrc@Ikkoku-Kan.Panda.COM>
Problem:
In 7.0 monitors, connections get silly (negative) timeouts depending
upon the particular monitor build. The problem comes and vanishes seemly at
random based upon monitor builds with trivial changes elsewhere that should
have no effect on TCP.
Diagnosis:
All the connections in question were used by networks servers which
use the .TCSTP function of TCOP%. DTCSTP in TCPJFN.MAC runs in section 1, but
uses a range check value that is in section 6. If the argument exceeds this
range check value it is clamped down to that value. Whether or not it works
depends entirely only what the corresponding value is in section 1. If the
number is a large positive number, then the bug has no effect as long as the
argument itself is reasonable.
Solution:
In TCPJFN.MAC, at ATTTIM+3, insert a label "SETSTO:", e.g.:
ATTTIM: ;timeout time attribute
MOVE T1,TCPATP ;get the attribute pointer
CALL ATTR18 ;get a legal 18 bit number
RETBAD (TCPX10) ;very illegal
SETSTO: ;entry from DTCSTP
CAMLE T2,TCPPTM ;is timeout parameter legitimate?
MOVE T2,TCPPTM ;no so make it legitimate
. . .
Delete 5 instructions at DTCSTP+2 and add an XCALLRET, e.g.:
DTCSTP: ;set timeout parameters
SKIPGE T2 ;legal value
RETBAD (TCPX10) ;no
XCALLRET (XCDSEC,SETSTO);save the timeout value
5-Sep-91 12:42:17-MDT,1824;000000000000
Return-Path: <jms@tardis.Tymnet.COM>
Received: from tymix (tymix.Tymnet.COM) by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 5 Sep 91 12:42:00 MDT
Received: from tardis.tymnet.com by tymix (4.1/SMI-4.1)
id AA13682; Thu, 5 Sep 91 11:41:42 PDT
Received: by tardis.tymnet.com (4.1/SMI-4.1)
id AA09728; Thu, 5 Sep 91 11:41:40 PDT
Date: Thu, 5 Sep 91 11:41:40 PDT
From: jms@tardis.Tymnet.COM (Joe Smith)
Message-Id: <9109051841.AA09728@tardis.tymnet.com>
To: tops20@wsmr-simtel20.army.mil
Subject: Another TOPS20 site going down
Newsgroups: ddn.mgt-bulletin
In-Reply-To: <12714994038.43.NIC@NIC.DDN.MIL>
I found this while reading news:
>DDN MGT Bulletin 84 DCA DDN Defense Communications System
>4 Sept 91 Published by: DDN Network Info Center
> (NIC@NIC.DDN.MIL) (800) 235-3155
> TRANSITION OF NIC SERVICES
>The transition of the Network Information Center from SRI
>International in Menlo Park, CA, to Government Systems Inc. in
>Chantilly, VA, is officially scheduled for 1 October 1991.
> .... With a few minor exceptions, all on-line services
>currently offered by SRI will appear the same to the user when a
>connection is established to the new (GSI) NIC host. These exceptions
>are due to the change from the TOPS20 operating system to the SunOS
>operating system. The new NIC host is a Sun 470 SPARCserver running
>SunOS 4.1.
So, another famous PDP-10 system bites the dust.
--
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com DIALCOM: J.SMITH
BTNA Tech Services TYMNET| CA license plate: "POPJ P," PDP-10, 36 bits forever
PO Box 49019, MS-C51 | Married to the LB, Quantum Leap's #1 net.fan
San Jose, CA 95161-9019 | humorous disclaimer: "My Amiga 3000 speaks for me."
5-Sep-91 13:29:59-MDT,776;000000000000
Return-Path: <britt@ISI.EDU>
Received: from venera.isi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 5 Sep 91 13:29:55 MDT
Received: by venera.isi.edu (5.61/5.61+local-3)
id <AA05056>; Thu, 5 Sep 91 12:31:01 -0700
Date: Thu, 5 Sep 91 12:30:57 PDT
From: Benjamin Britt <britt@ISI.EDU>
To: tops20@wsmr-simtel20.army.MIL
Subject: Bug Check on 2020
Message-Id: <CMM.0.90.2.684099057.britt@venera.isi.edu>
I'm getting the following bug check on a 2020 which doesn't appear
in the manual:
BUGCHK "P11PAR" at ...
PHYH11 -- CONTROL WRITE PARITY ERROR
Additional data: 10, 40000000001
I looked in <SYSTEM>BUGS.MAC for any more info but only found
the comment "Undocumented Bug Check".
Does anyone have any info on this one?
Much appreciated,
Ben
6-Sep-91 11:42:48-MDT,1755;000000000000
Return-Path: <mrc@ikkoku-kan.panda.com>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Sep 91 11:42:42 MDT
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.22 ) id AA28614; Fri, 6 Sep 91 10:42:27 -0700
Date: Fri, 6 Sep 1991 10:33:25 -0700 (PDT)
From: Mark Crispin <mrc@ikkoku-kan.panda.com>
Subject: re: Bug Check on 2020
To: Benjamin Britt <britt@isi.edu>
Cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: <CMM.0.90.2.684099057.britt@venera.isi.edu>
Message-Id: <MS-C.684178405.377401575.mrc@ikkoku-kan.panda.com>
P11PAR is a control bus parity error. This happens when trying to write to an
RH11 register. Suggested course of action:
. determine whether it is disk or tape. You should have some idea
whether or not it's associated with using the tape. Unfortunately,
this bugchk doesn't print out the CDB which would have said for sure
which channel it was.
. swap the RH11 in question out and see if the problem goes away.
Unfortunately, you can't swap the disk and tape RH11 because they
are different. I don't know your spare parts situation.
. if that fails, try swapping out the MASSBUS cable. Actually, I
think the MASSBUS cable is the most likely culprit.
. investigate possible problems on the device.
If you have DEC field service, then they should be doing this. It is
definitely a hardware problem.
If you're on time & materials with DEC and don't have any spare RH11's, try
swapping out the MASSBUS cable. You should have one or two spare MASSBUS
cables lying around.
Take this problem seriously, if you value the integrity of your data,
especially if it's happening on your disk RH11!
6-Sep-91 22:44:37-MDT,1531;000000000000
Return-Path: <francini@narfvx.enet.dec.com>
Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Sep 91 22:43:53 MDT
Received: by enet-gw.pa.dec.com; id AA00957; Fri, 6 Sep 91 21:42:49 -0700
Message-Id: <9109070442.AA00957@enet-gw.pa.dec.com>
Received: from narfvx.enet; by decwrl.enet; Fri, 6 Sep 91 21:43:22 PDT
Date: Fri, 6 Sep 91 21:43:22 PDT
From: Never blame the rainbows for the rain 06-Sep-1991 1141 <francini@narfvx.enet.dec.com>
To: tops20@wsmr-simtel20.army.mil, britt@isi.edu
Subject: FWD: Bug Check on 2020
>I'm getting the following bug check on a 2020 which doesn't appear
>in the manual:
>
>
>BUGCHK "P11PAR" at ...
>PHYH11 -- CONTROL WRITE PARITY ERROR
>Additional data: 10, 40000000001
>
>
>I looked in <SYSTEM>BUGS.MAC for any more info but only found
>the comment "Undocumented Bug Check".
>
>Does anyone have any info on this one?
>
>Much appreciated,
>
>Ben
Although my history is with TOPS-10, that looks suspiciously like a hardware
error -- probably in the RH11 Massbus disk controller. My guess is that it's
encountering a parity error in trying to write into memory. If you're not
seeing any memory-related bugchecks or other errors, I'd guess that either
A) the RH11 controller itself is failing
B) the data paths between the Unibus and memory are acting up
C) Memory itself is broken in an obscure fashion.
Methinks it's time for the RED pack...
John Francini
(Former TOPS-10 engineer)
Digital Equipment Corporation
9-Sep-91 12:26:43-MDT,732;000000000000
Return-Path: <britt@ISI.EDU>
Received: from venera.isi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 9 Sep 91 12:26:35 MDT
Received: by venera.isi.edu (5.61/5.61+local-3)
id <AA11195>; Mon, 9 Sep 91 11:27:33 -0700
Date: Mon, 9 Sep 91 11:27:28 PDT
From: Benjamin Britt <britt@ISI.EDU>
To: tops20@wsmr-simtel20.army.mil
Subject: BUGCHK P11PAR
Message-Id: <CMM.0.90.2.684440848.britt@venera.isi.edu>
A thousand thank-yous to all who responded to my plea for help with my
2020 problem. What I thought would be a long and involved process of
tracking down the error was actually very easy thanks to your advice;
I replaced the MASSBUSS cable to the disk RH11 and the errors stopped
occuring.
Thanks again,
Ben
15-Sep-91 19:57:41-MDT,675;000000000000
Mail-From: WANCHO created at 15-Sep-91 19:57:37
Date: Sun, 15 Sep 1991 19:57 MDT
Message-ID: <WANCHO.12717937570.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: Self-instruction courses
At one time, DEC offered several self-instruction courses on various
aspects of running a DECSYSTEM-20. If you have a copy of one or more
of the courses, we would like to make arrangements, including getting
DEC's permission, to borrow those copies for our in-house training.
Please contact me directly via email or call me at 505-678-9124.
--Frank
18-Sep-91 12:44:34-MDT,1184;000000000000
Return-Path: <MRC@Panda.COM>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Sep 91 12:44:17 MDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.23 ) id AA15810; Wed, 18 Sep 91 11:43:59 -0700
Date: Wed, 18 Sep 1991 11:39:44 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: SKDPF1 bughlts
To: TOPS-20 Hackers and Yackers <TOPS-20@WSMR-SIMTEL20.Army.MIL>
Message-Id: <MailManager.685219184.6676.mrc@Ikkoku-Kan.Panda.COM>
Problem:
SKDPF1 bughlts from HSTHSH routine, called from TCPOTS.
Diagnosis:
Code reorganization in 7.0 put HSTHSH in swappable code. HSTHST must
be resident because TCPOTS uses it. Stuff on that page (including HSTHSH) is
called often enough so that code page doesn't get swapped out, but HSTHSH
references a literal that is on a different page.
Solution:
In MNETDV.MAC, put
XRESCD
HSHEND: XWD INTSEC.NHOSTS ;END OF HASH TABLE
In front of HSTHSH:. Change
CAML T2,[XWD INTSEC,NHOSTS] ;CHECK FOR OVERFLOW
to
CAML T2,HSTEND ;CHECK FOR OVERFLOW
At the end of the routine, add
XSWAPCD
24-Sep-91 11:39:02-MDT,1701;000000000000
Return-Path: <shawn@FENCHURCH.MIT.EDU>
Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 24 Sep 91 11:38:32 MDT
Received: by FENCHURCH.MIT.EDU
id AA08562; Tue, 24 Sep 91 13:41:35 -0400
Reply-To: shawn@FENCHURCH.MIT.EDU
Date: Tue, 24 Sep 91 13:41:34 EDT
From: "Shawn F. Mckay" <shawn@FENCHURCH.MIT.EDU>
To: tops-20@wsmr-simtel20.army.mil
Subject: Mit-Deep-Thought
Message-Id: <CMM.0.90.0.685734094.shawn@fenchurch>
Thanks to Joe Dempster, we got Deep-Thought's power problems fixed (we
think), but made a really scary discovery. Somehow, while deep thought
slept, someone (WITHOUT ASKING) came into our machine room, and replaced
ALL our MG memory, with MF memory. (In fact the MF they tossed in does
not even seem to work).
We had 2 meg worth of MG. It REALLY made a difference on the machine, and
to bring it back up we need memory anyway (either way, the MF they put in
does not work and is too small).
We also need to find an alignment RP06 pack, (I have the suitcase for the
drive, I just need a pack). However, these two problems are the only ones
that we can find that stand in front of bringing it back up.
As always, we are in the market for any freebie cards or hardware you may
hear about that is being discarded, we will give it a home (we will need
spares to keep her running).
But we are in a serious bad way for MG memory since someone stole ours.
(I'm still shocked that such an incident could happen in our machine room).
Anyway, if you know of anyone, or hear of anything, please keep us in mind,
we REALLY would like to bring deep-thought up so we can open her up to the
20 world.
Thanks,
- Shawn
27-Sep-91 16:26:56-MDT,2054;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 27 Sep 91 16:26:48 MDT
Date: Fri 27 Sep 91 17:26:28-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: Ring Buffers
To: tops20@wsmr-simtel20.army.mil
Message-ID: <12721044860.7.AI.CLIVE@MCC.COM>
Date: Thu, 26 Sep 91 22:20:14 EDT
From: daveg@prowler.clearpoint.com (Dave Goldblatt)
Subject: Help Requested in Defeating Ring Buffer Software Patent
Reply-To: daveg@prowler.clearpoint.com
I am looking for information which could be used to invalidate
a patent which covers one of the most basic techniques in software:
the ring buffer. Specifically, the patent is on the idea of using two
circular buffers in commonly addressable memory to queue pointers to
messages (also in shared memory) between two processors. One buffer
contains messages going in one direction, and the other buffer
contains messages going in the other.
The allegedly inventive feature is having one of the
processors tell the other processor the size of the ring buffers.
I'm looking for code or references to this technique written
before October 5, 1981. An example of dual processor communication
would be ideal, however, inter-process communication via this method
could also prove useful. I know of at least one network adapter which
violates this patent, and also of an Ethernet controller which does as
well, but neither are before the required date.
Any information will be GREATLY appreciated! For better
results, email will be appreciated even more so.
Thanks!
dg
I saw this message on the Telecom digest, and immediately thought of
TOPS-20 as an excellent hunting ground, considering that much of it
dates back to 1976 (and that's not counting Tenex!) Ring buffers are
used quite a bit in some of the network and free space management
code. Does anybody have any suggestions as to which particular
instance would serve as the best example for the above purpose?
Clive
-------
30-Sep-91 09:50:10-MDT,1244;000000000000
Return-Path: <grossman@cygnus.com>
Received: from relay1.UU.NET by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 30 Sep 91 09:48:36 MDT
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA08913; Sat, 28 Sep 91 14:33:19 -0400
Received: by cygnus.com (4.1/SMI-4.1)
id AA16130; Sat, 28 Sep 91 11:33:19 PDT
Date: Sat, 28 Sep 91 11:33:19 PDT
From: grossman@cygnus.com (Stu Grossman)
Message-Id: <9109281833.AA16130@cygnus.com>
To: AI.CLIVE@MCC.COM
Cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: Clive Dawson's message of Fri 27 Sep 91 17:26:28-CDT <12721044860.7.AI.CLIVE@MCC.COM>
Subject: Ring Buffers
Clive,
If my memory serves me, I beleive that the DTE and the DL10 drivers
both used ring buffers for communicating with the -11 front-end. And, they
both existed prior to 1981.
However, if my understanding of patent law is correct, the prior art
concept does not apply here since the methods used by these drivers was not
published in a publicly accessible forum. Any patent lawyers out there who
care to comment on this?
Note that Knuth (vol 1, Fundamental Algorithms?) almost certainly
describes this sort of data structure. So that's prior art, isn't it?
Stu Grossman
30-Sep-91 10:18:22-MDT,1408;000000000000
Return-Path: <jms@tardis.Tymnet.COM>
Received: from tymix (tymix.Tymnet.COM) by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 30 Sep 91 10:05:32 MDT
Received: from tardis.tymnet.com by tymix (4.1/SMI-4.1)
id AA09342; Sat, 28 Sep 91 20:58:21 PDT
Received: by tardis.tymnet.com (4.1/SMI-4.1)
id AA05418; Sat, 28 Sep 91 20:58:20 PDT
Date: Sat, 28 Sep 91 20:58:20 PDT
From: jms@tardis.Tymnet.COM (Joe Smith)
Message-Id: <9109290358.AA05418@tardis.tymnet.com>
To: daveg@prowler.clearpoint.com, tops20@wsmr-simtel20.army.mil
Subject: Use of ring buffers.
TYMNET has been using ring buffers since its inception. To this day, it
still uses IRINGs and ORINGs in its network Engines and the PDP-10
interface. The technique uses 4 locations at fixed addresses; specifying
the starting address and size of the IRING (for input to the main CPU) and
the starting address and size of the ORING (for output from the main CPU).
This technology has been in use since the early 70's. For more details
you'd have to talk someone who's been with Tymshare (now BT North America)
longer than I have.
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BTNA Tech Services TYMNET| UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C51 | PDP-10: JMS@F74.Tymnet.COM or TXS.J/SMITH@Ontyme
San Jose, CA 95161-9019 | ONTYME: NSC.J/SMITH@ontyme or J.SMITH@dialcom
30-Sep-91 10:23:19-MDT,3291;000000000000
Return-Path: <bygg@sunic.sunet.se>
Received: from sunic.sunet.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 30 Sep 91 10:13:03 MDT
Received: by sunic.sunet.se (5.61+IDA/KTH/LTH/1.203)
id AAsunic29344; Sun, 29 Sep 91 07:52:58 +0100
Date: Sun, 29 Sep 1991 7:52:45 MET
From: Johnny Eriksson <bygg@sunic.sunet.se>
To: Clive Dawson <AI.CLIVE@MCC.COM>
Cc: tops20@wsmr-simtel20.army.mil,
daveg@prowler.clearpoint.com (Dave Goldblatt)
Subject: Re: Ring Buffers
In-Reply-To: Your message of Fri 27 Sep 91 17:26:28-CDT
Message-Id: <CMM.0.88.686127165.bygg@sunic.sunet.se>
> Date: Thu, 26 Sep 91 22:20:14 EDT
> From: daveg@prowler.clearpoint.com (Dave Goldblatt)
> Subject: Help Requested in Defeating Ring Buffer Software Patent
> Reply-To: daveg@prowler.clearpoint.com
>
>
> I am looking for information which could be used to invalidate
> a patent which covers one of the most basic techniques in software:
> the ring buffer. Specifically, the patent is on the idea of using two
> circular buffers in commonly addressable memory to queue pointers to
> messages (also in shared memory) between two processors. One buffer
> contains messages going in one direction, and the other buffer
> contains messages going in the other.
>
> The allegedly inventive feature is having one of the
> processors tell the other processor the size of the ring buffers.
>
> I'm looking for code or references to this technique written
> before October 5, 1981. An example of dual processor communication
> would be ideal, however, inter-process communication via this method
> could also prove useful. I know of at least one network adapter which
> violates this patent, and also of an Ethernet controller which does as
> well, but neither are before the required date.
>
> Any information will be GREATLY appreciated! For better
> results, email will be appreciated even more so.
>
> Thanks!
>
> dg
>
> I saw this message on the Telecom digest, and immediately thought of
> TOPS-20 as an excellent hunting ground, considering that much of it
> dates back to 1976 (and that's not counting Tenex!) Ring buffers are
> used quite a bit in some of the network and free space management
> code. Does anybody have any suggestions as to which particular
> instance would serve as the best example for the above purpose?
Hmmm, will TOPS-10 do?
The "normal" way of doing buffered I/O on Tops-10 is with a ring
buffer structure, or two if the I/O is bidirectional. I am current-
ly reading my old copy of "decsystem10 assembly language handbook".
This is a handful of books, bound into one. In book "Monitor Calls",
page 4-6 (or page 466 of the whole book) the following is found:
4.3 RING BUFFERS
4.3.1 Buffer Structure
The ring buffer (see Figure 4-1) is comprised of a buffer
ring header block and buffer rings.
The figure (on the opposite page) shows a nice little buffer ring.
Try to get hold of a copy of this book, and look for yourself. The DEC
order code is DEC-10-NRZC-D. The book is Copyright 1967. 1973, and my
copy was printed in 1973. I can fax you the relevant pages, if needed.
If you get the lawyer shot, may I have one of the ears as a souvrenir?
--Johnny
30-Sep-91 11:13:55-MDT,1071;000000000000
Return-Path: <Rob.Gingell@Eng.Sun.COM>
Received: from Sun.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 30 Sep 91 11:13:47 MDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA28487; Sat, 28 Sep 91 17:22:57 PDT
Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA22819; Sat, 28 Sep 91 17:22:51 PDT
Received: by opus.Eng.Sun.COM (4.1/SMI-4.1)
id AA08675; Sat, 28 Sep 91 17:22:12 PDT
Date: Sat, 28 Sep 91 17:22:12 PDT
From: Rob.Gingell@Eng.Sun.COM (Rob Gingell)
Message-Id: <9109290022.AA08675@opus.Eng.Sun.COM>
To: AI.CLIVE@MCC.COM, tops20@wsmr-simtel20.army.mil
Subject: Re: Ring Buffers
>Does anybody have any suggestions as to which particular
>instance would serve as the best example for the above purpose?
One example of a ring buffer is the big buffer -- TTBBUF if I recall
correctly. It probably satisfies at least the theoretical instance
of "interprocess communication" requested. I don't remember enough of
it, but would the DTE stuff (either for the FE or DN20's) contain an
example?
1-Oct-91 13:41:30-MDT,1407;000000000000
Return-Path: <phil@Shiva.COM>
Received: from Shiva.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 1 Oct 91 13:41:00 MDT
Received: by Shiva.COM (1.34b) Tue, 1 Oct 91 12:47:09 EDT
Date: Tue, 1 Oct 91 12:47:09 EDT
From: Phil Budne <phil@Shiva.COM>
Message-Id: <9110011647.AA25266@Shiva.COM>
To: AI.CLIVE@mcc.com, bygg@sunic.sunet.se
Subject: Re: Ring Buffers
Cc: daveg@prowler.clearpoint.com, phil@Shiva.COM,
tops20@wsmr-simtel20.army.mil
Date: Sun, 29 Sep 1991 7:52:45 MET
From: Johnny Eriksson <bygg@sunic.sunet.se>
Hmmm, will TOPS-10 do?
The "normal" way of doing buffered I/O on Tops-10 is with a ring
buffer structure, or two if the I/O is bidirectional. I am current-
ly reading my old copy of "decsystem10 assembly language handbook".
Thanks! now I don't need to find mine! (this ref is also known as the
"phone book", since it was printed on very thin paper and has a yellow
cover).
Futhermore TOPS-10's ring buffers can qualify as multiprocessor, since
on a master-slave system the physical I/O always took place on the
master CPU, while the user process ("job") which adds and removes data
from the rings can run on either CPU.
My DEC "25 Year Product Geneology" poster shows dual processor KA
systems (1055) at or around 1971 and dual KI's (1077) at or around
1973!
If you get the lawyer shot, may I have one of the ears as a souvrenir?
Ole!
1-Oct-91 19:47:22-MDT,1901;000000000000
Return-Path: <jms@tardis.Tymnet.COM>
Received: from tymix (tymix.Tymnet.COM) by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 1 Oct 91 19:47:07 MDT
Received: from tardis.tymnet.com by tymix (4.1/SMI-4.1)
id AA28642; Tue, 1 Oct 91 18:46:51 PDT
Received: by tardis.tymnet.com (4.1/SMI-4.1)
id AA26504; Tue, 1 Oct 91 18:46:50 PDT
Date: Tue, 1 Oct 91 18:46:50 PDT
From: jms@tardis.Tymnet.COM (Joe Smith)
Message-Id: <9110020146.AA26504@tardis.tymnet.com>
To: bygg@sunic.sunet.se, tops20@wsmr-simtel20.army.mil
Subject: Re: Ring Buffers
There are plenty of places where TOPS-10 users a ring of buffers, but I
have yet to see TOPS-10 using a ring buffer (aka circular buffer).
Ring of buffers: (such as used by SCNSER and UUOCON)
1) Has a buffer header pointing to the currently active minibuffer (or
bufferlet or TTY-chunk or etc).
2) A full buffer is detected by either using a byte count or noticing
that the byte pointer has reached a multiple of a power of 2.
3) When current bufferlet is full, the byte pointer is switched to
point to the start of the next bufferlet, and NOT to the start
of the current one.
Ring buffer (circular buffer):
1) No buffer header, no available byte count, just FILL and EMPTY pointers.
2) Buffer is empty when FILL and EMPTY point to the same place.
Buffer is full when FILL = (EMPTY - 1) mod BUFFERSIZE.
3) The FILL pointer DOES wrap around to the beginning of the data area.
Question: Are there any examples where TOPS-10 or TOPS-20 use a true
circular buffer as opposed to a ring of buffers?
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com DIALCOM: J.SMITH
BTNA Tech Services TYMNET| CA license plate: "POPJ P," PDP-10, 36 bits forever
PO Box 49019, MS-C51 | Married to the LB, Quantum Leap's #1 net.fan
San Jose, CA 95161-9019 | humorous disclaimer: "My Amiga 3000 speaks for me."
1-Oct-91 20:53:05-MDT,1625;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:PAT@locke.hs.washington.edu>
Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 1 Oct 91 20:52:44 MDT
Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU
(IBM VM SMTP V2R1) with TCP; Tue, 01 Oct 91 19:52:58 PDT
Date: Tue, 1 Oct 91 19:51 PDT
From: Pat Tressel <PAT@locke.hs.washington.edu>
Subject: Re: Ring Buffers
To: AI.CLIVE@mcc.com, tops20@wsmr-simtel20.army.mil
Message-id: <084F3CF53F8F801975@locke.hs.washington.edu>
X-Envelope-to: AI.CLIVE@mcc.com, tops20@wsmr-simtel20.army.mil
X-VMS-To: IN%"AI.CLIVE@mcc.com"
X-VMS-Cc: IN%"tops20@wsmr-simtel20.army.mil"
> If my memory serves me, I beleive that the DTE and the DL10 drivers
> both used ring buffers for communicating with the -11 front-end. And, they
> both existed prior to 1981.
> However, if my understanding of patent law is correct, the prior art
> concept does not apply here since the methods used by these drivers was not
> published in a publicly accessible forum. Any patent lawyers out there who
> care to comment on this?
> ...
> Stu Grossman
TOPS-10 was delivered with sources, and it uses pairs of queues to communicate
with front ends. I don't know how it communicates the length, but I've asked
our monitor specialist to have a look at the DTE code. (If he doesn't get a
chance to do this -- he's very busy just now -- I'll check it out.) TOPS-10
is proprietary but the sources are accessible -- does that count?
Patricia Tressel
Locke Computer Center
University of Washington
pat@locke.hs.washington.edu
2-Oct-91 04:06:29-MDT,1538;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:PAT@locke.hs.washington.edu>
Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 2 Oct 91 04:06:23 MDT
Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU
(IBM VM SMTP V2R1) with TCP; Wed, 02 Oct 91 03:07:09 PDT
Date: Wed, 2 Oct 91 03:05 PDT
From: Pat Tressel <PAT@locke.hs.washington.edu>
Subject: Re: Ring Buffers
To: tops20@wsmr-simtel20.army.mil
Message-id: <08129648258F801794@locke.hs.washington.edu>
X-Envelope-to: tops20@wsmr-simtel20.army.mil
X-VMS-To: IN%"tops20@wsmr-simtel20.army.mil"
> There are plenty of places where TOPS-10 users a ring of buffers, but I
> have yet to see TOPS-10 using a ring buffer (aka circular buffer).
> ...
> Ring buffer (circular buffer):
> 1) No buffer header, no available byte count, just FILL and EMPTY pointers.
> 2) Buffer is empty when FILL and EMPTY point to the same place.
> Buffer is full when FILL = (EMPTY - 1) mod BUFFERSIZE.
> 3) The FILL pointer DOES wrap around to the beginning of the data area.
>
> Question: Are there any examples where TOPS-10 or TOPS-20 use a true
> circular buffer as opposed to a ring of buffers?
>
> Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com DIALCOM: J.SMITH
The TOPS-10 DTE code uses circular queues, complete with PUTTER (fill) and
GETTER (empty) pointers. I'm *almost* certain of this -- I'll check.
Patricia Tressel
Locke Computer Center
University of Washington
pat@locke.hs.washington.edu
3-Oct-91 17:18:20-MDT,1481;000000000000
Return-Path: <jms@tardis.Tymnet.COM>
Received: from tymix (tymix.Tymnet.COM) by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 3 Oct 91 17:18:04 MDT
Received: from tardis.tymnet.com by tymix (4.1/SMI-4.1)
id AA23633; Thu, 3 Oct 91 16:17:37 PDT
Received: by tardis.tymnet.com (4.1/SMI-4.1)
id AA25522; Thu, 3 Oct 91 16:17:36 PDT
Date: Thu, 3 Oct 91 16:17:36 PDT
From: jms@tardis.Tymnet.COM (Joe Smith)
Message-Id: <9110032317.AA25522@tardis.tymnet.com>
To: tops20@wsmr-simtel20.army.mil
Subject: Time to drop the Ring Buffers?
Dave Goldblatt <daveg@prowler.clearpoint.com> writes:
> The allegedly inventive feature is having one of the
>processors tell the other processor the size of the ring buffers.
>
> I'm looking for code or references to this technique written
>before October 5, 1981.
Hmmmm. October 1981... Isn't that about the time that DEC came out with
the infamous "MSCP" patent? If so, then any examples from TOPS-10 or
TOPS-20 could not be used to invalidate the patent. Unless it were to
show that DEC was already using this technique for more than one year, and
therefore exceeded the grace period ("statutory bar").
-Joe
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com DIALCOM: J.SMITH
BTNA Tech Services TYMNET| CA license plate: "POPJ P," PDP-10, 36 bits forever
PO Box 49019, MS-C51 | Married to the LB, Quantum Leap's #1 net.fan
San Jose, CA 95161-9019 | humorous disclaimer: "My Amiga 3000 speaks for me."
3-Oct-91 20:46:09-MDT,1508;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:PAT@locke.hs.washington.edu>
Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 3 Oct 91 20:45:47 MDT
Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU
(IBM VM SMTP V2R1) with TCP; Thu, 03 Oct 91 19:46:29 PDT
Date: Thu, 3 Oct 91 19:45 PDT
From: Pat Tressel <PAT@locke.hs.washington.edu>
Subject: Re: Ring Buffers
To: tops20@wsmr-simtel20.army.mil
Message-id: <06BDCB6B1C7D2004EE@locke.hs.washington.edu>
X-Envelope-to: tops20@wsmr-simtel20.army.mil
X-VMS-To: IN%"tops20@wsmr-simtel20.army.mil"
> The TOPS-10 DTE code uses circular queues, complete with PUTTER (fill) and
> GETTER (empty) pointers. I'm *almost* certain of this -- I'll check.
> Patricia Tressel
The tty communications area uses a linked list for the tty chunks in the
queue, with a freelist to get fresh chunks from, so it doesn't need to
specify a size. (Only one side -- whoever sets up the initial freelist --
needs to know how big the queue area is.) There are other places in TOPS-10
that do use circular queues with sizes, though. The question is, just what
is the mechanism of communicating the size that they're trying to patent?
Knowing this, we can look for something that matches the method.
Speaking of communicating, is anyone forwarding this stuff to Dave Goldblatt,
or should we be CCing him?
Patricia Tressel
Locke Computer Center
University of Washington
pat@locke.hs.washington.edu
4-Oct-91 13:24:03-MDT,1474;000000000000
Return-Path: <WEINER@gidney.tops20.dec.com>
Received: from gidney.tops20.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 4 Oct 91 13:23:57 MDT
Sender: JCAMPBELL@RANGER
Date: 4 Oct 1991 1038-EDT
From: "Crises allow us to learn 04-Oct-1991 1027" <JCAMPBELL@RANGER>
To: WEINER@GIDNEY
Subject: ring buffer stuff
Mailed-to: GIDNEY::WEINER
ReSent-Date: Fri, 4 Oct 91 15:03:51 EDT
ReSent-From: WEINER@gidney.tops20.dec.com
ReSent-To: tops20@WSMR-SIMTEL20.army.mil
ReSent-Message-ID: <12722842984.13.WEINER@gidney.tops20.dec.com>
I wonder if you could pass this information back to whoever is
attempting to overturn the patent.
The following people could be contacted (you probably know a bunch of
these already):
1. TOPS-10. Tony Wachs at Wang, perhaps Steve Wolfe at Wang, Jim Flemming
here at DEC (if he is still here, haven't heard recently).
2. TOPS-20. Dan Murphy (STAR::MURPHY), Judy Hall (LTN), Arnie Miller (Banyan
Systems in Westboro, I think), Kevin Paetzold (Stratus), Tom Moser (Stratus).
3. ATEX, Inc, Bedford, MA, had (and I think still has) a multi-cpu system
that undoubtedly uses such buffering. They had a fault-tolerant cluster
of 11/34s when I worked there in 1979, commercially marketed for
typesetting. I don't know anyone who works there now, but someone who
would know (and was in the code) is Dave Erickson of Xyquest, Inc, Bedford,
MA.
Regards
Jon Campbell
former FORTRAN 10/20
--------
11-Oct-91 15:16:36-MDT,2247;000000000000
Return-Path: <@Sunburn.Stanford.EDU:grossman@cygnus.com>
Received: from Sunburn.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 11 Oct 91 15:03:23 MDT
Received: from relay1.UU.NET by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA23493; Tue, 8 Oct 91 14:51:11 -0700
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA01471; Tue, 8 Oct 91 17:51:07 -0400
Received: by cygnus.com (4.1/SMI-4.1)
id AA19783; Tue, 8 Oct 91 14:52:59 PDT
Date: Tue, 8 Oct 91 14:52:59 PDT
From: grossman@cygnus.com (Stu Grossman)
Message-Id: <9110082152.AA19783@cygnus.com>
To: tops-20@score.stanford.edu
Subject: [andyp@ibmpa.awdpa.ibm.com: TOPS-10 experience?]
Return-Path: <andyp@ibmpa.awdpa.ibm.com>
Date: Tue, 8 Oct 91 11:20:45 -0700
From: andyp@ibmpa.awdpa.ibm.com (Andrew Purshottam)
To: grossman@cygnus.com
From: hjones@magnus.acs.ohio-state.edu (Horace B Jones)
Newsgroups: comp.os.research
Subject: TOPS-10 experience?
Date: 4 Oct 91 03:05:13 GMT
Organization: The Ohio State University
% Not exactly research, but an interesting item nonetheless. --DL
CompuServe's mainframe computers are 36-bit SC-30 systems that run our
proprietary operating system. Many years ago, this OS was TOPS-10, and
even today people familiar with TOPS-10 will see a distinct similarity.
We run SCSI disks and tapes and have developed our own network interface.
We write software in C, BLISS-36, and MACRO-10.
If you might be interested in systems-level work in an environment
such as this or know someone who might, we'd like to hear from you.
TOPS-10 experience is a special plus here, but there are opportunities
in many other areas. Individuals can make a difference.
Please send your resume to
CompuServe Incorporated
5000 Arlington Centre Blvd.
Columbus, Ohio 43220
attn: Ms. Kathy DeCaprio
(614) - 457-8600
If the postal service isn't convenient, you may send email to me (I'm
likely to see it anyway) and I'll pass it along to Kathy.
Purely as a matter of tracking response to this Internet posting,
please mention this posting in any correspondence with CompuServe.
--
Benny Jones
CompuServe 70003,1153
Internet hjones@magnus.acs.ohio-state.edu
7-Nov-91 14:56:01-MST,1707;000000000000
Return-Path: <JIML@heap.cisco.com>
Received: from heap.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 7 Nov 91 14:55:41 MST
Date: Thu 7 Nov 91 13:54:32-PST
From: Jim Lewinson <Jiml@heap.cisco.com>
Subject: System 1022 and Disk Bit table Lossage
To: tops-20@wsmr-simtel20.army.mil
Message-ID: <12731786952.27.JIML@heap.cisco.com>
Each night, we reloadi some large (6000 and 11000) page System 1022
databases. The databases are *NOT* located on PS:. Every time they
get reloaded, a bunch of pages on PS: are marked as unused, despite
the fact that they are still in use in the file system. It gets fun
when the page is part of directory, or the swapping area.
Any process that happens to try to get a page on PS: for a mail
message or something may be blessed by being issued one of these not-
really-free pages, and then proceeds to store its data on top of
someone else's file or directory. Then we get multiply allocated
pages.
As all of you can imagine, it isn't fun to try to clean up this sort
of carnage. I mentioned this problem to someone else, and they
though they had seen something in the Software Dispatch about this
sort of problem, but they didn't know the details, nor did they have
any Software Dispatches around any more. I actually saw this problem
from time to time when I was working at Stanford, but I never saw the
pattern there that we have here.
It seems as if the Monitor is releasing the pages on the wrong
disk drive, perhaps only on files where the index page is in fact
pointers to index pages. (FB%LNG set on file)
Can anyone offer any help in solving this problem?
Thanks,
Jim Lewinson
cisco Systems
-------
8-Nov-91 07:08:11-MST,1121;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 8 Nov 91 07:07:49 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA01606; Fri, 8 Nov 91 09:06:18 -0500
Date: Fri, 8 Nov 91 09:06:18 -0500
Message-Id: <9111081406.AA01606@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: Jiml@heap.cisco.com
Cc: tops-20@wsmr-simtel20.army.mil
In-Reply-To: Jim Lewinson's message of Thu 7 Nov 91 13:54:32-PST
Subject: System 1022 and Disk Bit table Lossage
Jim,
No help here, just a negative report. We have a 2060 that has been
running a very heavy 1022 load for several years, including 30,000 to
50,000 page databases that are reloaded weekly. We use mostly 1022
version 116B, although we have also used some 117 databases. We have
never experienced any of the problems you're describing.
Since we froze our monitor so long ago (version 5.4 with updated v.6 TCP
code), I don't expect we have much in common to help you find the problem.
Good luck...
Doug Bigelow
Wesleyan University
17-Dec-91 14:19:05-MST,2001;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 17 Dec 91 14:18:41 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA09781; Tue, 17 Dec 91 16:18:33 -0500
Date: Tue, 17 Dec 91 16:18:33 -0500
Message-Id: <9112172118.AA09781@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: tops20@wsmr-simtel20.army.mil
Subject: Telnet DATA MARK
I'm having some problems with a Datability TCP/IP terminal server talking
to a 2060, which seems to be related to the Telnet DATA MARK option.
Briefly, when a user on the terminal server types a ^C, the dialog goes
like this:
server => kl 03 ;user types ctrl-c
kl => server IAC DM ;data mark
IAC DO TM ;do timing mark
server => kl IAC WONT TM ;wont timing mark
kl => server "^","C",cr,lf ;kl sends ^C and a crlf
The Datability server understands the timing mark request and responds,
but doesn't understand the data mark command. It prints out the IAC DM on
the terminal (which translates in seven bits to a delete and an "r".)
The server documentation claims that it understands the use of data mark,
and it can send one. I suspect that the trouble in receiving one may be
related to the lack of an URGENT flag sent with the timing mark packet.
The server is probably looking for a Telnet Synch packet, and if the
URGENT flag is not set it perhaps considers the timing mark invalid.
Can anyone tell me what the correct behavior should be? The server
doesn't seem to have trouble with any other types of hosts. However, the
behavior of my 2060 isn't unique (or at least simtel-20 acts the same
way!) Should I be changing the behavior of the 2060, or asking Datability
to change the behavior of their server?
I recall seeing something written up on this subject years ago, I think by
Charles Hedrick. Does anyone have that around?
Thanks --
Doug Bigelow
Wesleyan University
18-Dec-91 10:55:51-MST,1707;000000000000
Return-Path: <MRC@panda.com>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Dec 91 10:55:20 MST
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.23 ) id AA06718; Wed, 18 Dec 91 09:55:01 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
(NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA09286; Wed, 18 Dec 91 09:54:53 PST
Date: Wed, 18 Dec 1991 09:47:12 -0800 (PST)
From: Mark Crispin <MRC@panda.com>
Sender: Mark Crispin <mrc@ikkoku-kan.panda.com>
Subject: re: Telnet DATA MARK
To: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
Cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: <9112172118.AA09781@sandpiper.wesleyan.edu>
Message-Id: <MailManager.693078432.9074.mrc@Ikkoku-Kan.Panda.COM>
Body-Version: RFC-XXXX
Content-Type: TEXT/US-ASCII; charset=US-ASCII
Nag Datability to fix their losing terminal server. Better yet, flush it and
buy a cisco instead. You buy cheap, you get cheap.
The Datability terminal server doesn't really understand timing marks -- note
the `IAC WONT TM' response. `IAC WILL TM' is better (not that it really
matters). This suggests that Datability has cut corners in other areas.
Timing Mark and Data Mark are totally independant of each other, and the
Timing Mark is irrelevant to the discussion. Unless, of course, Datability's
implementation thinks they are (in which case it's another bug).
Regardless of whether or not URGENT was set, Datability's outputting a Data
Mark like ordinary data is totally bogus.
I looked at the sources, and yes, it seems that TOPS-20 isn't setting URGENT.
Hopefully, the reason for that expired long ago.
18-Dec-91 12:29:04-MST,2904;000000000000
Return-Path: <dbigelow@sandpiper.wesleyan.edu>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Dec 91 12:28:46 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
id AA10483; Wed, 18 Dec 91 14:28:26 -0500
Date: Wed, 18 Dec 91 14:28:26 -0500
Message-Id: <9112181928.AA10483@sandpiper.wesleyan.edu>
From: Douglas Bigelow <dbigelow@sandpiper.wesleyan.edu>
To: MRC@panda.com
Cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: Mark Crispin's message of Wed, 18 Dec 1991 09:47:12 -0800 (PST)
Subject: Telnet DATA MARK
>> Date: Wed, 18 Dec 1991 09:47:12 -0800 (PST)
>> From: Mark Crispin <MRC@panda.com>
>> Nag Datability to fix their losing terminal server. Better yet, flush it and
>> buy a cisco instead. You buy cheap, you get cheap.
>> The Datability terminal server doesn't really understand timing marks -- note
>> the `IAC WONT TM' response. `IAC WILL TM' is better (not that it really
>> matters). This suggests that Datability has cut corners in other areas.
>> Timing Mark and Data Mark are totally independant of each other, and the
>> Timing Mark is irrelevant to the discussion. Unless, of course, Datability's
>> implementation thinks they are (in which case it's another bug).
>> Regardless of whether or not URGENT was set, Datability's outputting a Data
>> Mark like ordinary data is totally bogus.
>> I looked at the sources, and yes, it seems that TOPS-20 isn't setting URGENT.
>> Hopefully, the reason for that expired long ago.
Mark,
Thanks. I agree, of course, about cisco products vs the competition.
Unfortunately, cisco is particularly uncompetitive in the small modular
server range. For example, I bought one of their STS-10s for an end-user
department at $2,700 for ten ports. The Datability, for another
department, cost me $2,000 for sixteen ports. For higher density servers
the difference is less extreme. However, sometimes budget constraints
present the choice between a cheap server vs no server at all.
The non-dollar price I pay is considerable, of course. The Datability
support is via phone and FAX rather than via network mail, and so far I
have not spoken directly to anyone who is knowledgable about Telnet
options. If it were a cisco product I could get authoritative answers
immediately. (And I also wouldn't get puzzled questions about what
kind of machine a "dec20" was.)
My gamble is that I will not need good support, because I generally expect
to put in a terminal server and have it work without complaint. If I
solve this current problem and no others crop up, I'll be OK. If I have
continuing problems, I'll have lost the gamble.
Oh well, enough philosphy. Thanks for the comments. I may try setting
the URGENT flag on a DATA MARK packet and see what happens. At the least,
it will give me more information to send on to Datability.
Doug
18-Dec-91 13:00:29-MST,929;000000000000
Return-Path: <sra@asylum.sf.ca.us>
Received: from asylum.sf.ca.us by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Dec 91 13:00:24 MST
Received: by asylum.sf.ca.us
id AA19118; Wed, 18 Dec 91 15:01:44 -0500 (EST)
Date: Wed, 18 Dec 91 15:01:44 -0500 (EST)
Message-Id: <9112182001.AA19118@asylum.sf.ca.us>
From: Rob Austein <sra@asylum.sf.ca.us>
Sender: sra@asylum.sf.ca.us
To: dbigelow@SANDPIPER.WESLEYAN.EDU
Cc: tops20@WSMR-SIMTEL20.ARMY.MIL
In-Reply-To: Douglas Bigelow's message of Tue, 17 Dec 91 16:18:33 -0500 <9112172118.AA09781@sandpiper.wesleyan.edu>
Subject: Telnet DATA MARK
Doug,
The Datability box is in violation of RFC-854 (page 9) if it is doing
anything with a non-urgent IAC DM other than silently discarding it.
I'm not sure that sending IAC DM as non-urgent data qualifies as an
out-and-out violation on the KL's part, but it's certainly in very
poor taste and should be fixed.
--Rob
24-Dec-91 12:29:59-MST,1533;000000000000
Mail-From: PANDA created at 24-Dec-91 12:28:24
Return-Path: <MRC@YUUYUU.Panda.COM>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Tue, 24 Dec 91 12:28:25 MST
Date: Fri, 20 Dec 91 16:22:35 PST
From: Mark Crispin <MRC@YUUYUU.Panda.COM>
Subject: Happy DEC-20 Day
To: TOPS-20@WSMR-SIMTEL20.Army.MIL
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <12743086096.9.MRC@YUUYUU.Panda.COM>
This message comes to you from Yuuyuu, KS10 serial number 4664 (possibly the
last KS10 ever built -- I know of no higher serial numbered KS's). Yuuyuu is
happily running in the computer room of my house on rainy Bainbridge Island,
Washington. Yuuyuu was formerly known as Panda. Yuuyuu has a sister, the
former SUMEX-AIM `Tiny' system, named Tonton. Tonton presently is awaiting a
second UBA to be brought up to full operational state.
Upstairs is a 68040 NeXT, Ikkoku-Kan, which is IP connected to the University
of Washington (at present NSFnet isn't routing Pandanet datagrams; this may
change soon). I hope to get Yuuyuu and Tonton IP connected as well.
Yuuyuu and Tonton are the names of the two baby pandas at Ueno Zoo in Tokyo.
If you would like to pay Yuuyuu a visit, you can call (206) 842-0758 at 1200
baud and log in as user GUEST with password FEIFEI. Please don't abuse the
privilege lest it be taken away, and please don't pass it on in a public forum.
Anyway, go and give your favorite DEC-20 a hug on DEC-20 day.
-------