25-Jan-91 09:43:23-MST,1537;000000000000
Return-Path: <@Sunburn.Stanford.EDU:[email protected]>
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: <[email protected]>
Date: Fri 25 Jan 91 11:46:12-EST
From: "Richard DeJordy, x4029" <[email protected]>
Subject: ["Richard DeJordy, x4029" <[email protected]>: TOPS20 Tapes]
To: [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>


Return-Path: <[email protected]>
Date: Thu 24 Jan 91 09:27:51-EST
From: "Richard DeJordy, x4029" <[email protected]>
Subject: TOPS20 Tapes
To: [email protected]
Cc: [email protected]

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

[email protected]

-------
-------
12-Feb-91 21:13:42-MST,2030;000000000000
Return-Path: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: [[email protected]: Re: PDP-10's in the Soviet Union]
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>

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: [email protected]
Subject: Re: PDP-10's in the Soviet Union
To: [email protected]

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: <[email protected]>
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: [email protected]
To: [email protected]
CC: [email protected]
Message-ID: <[email protected]>
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: <[email protected]>
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 <[email protected]>
Subject: a big hello...
To: [email protected]
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

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: <[email protected]>
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: <[email protected]>
From: Steve Faiwiszewski <[email protected]>
Subject: Anyone interested in DECsystem 20s?
To: [email protected]
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: [email protected]  |          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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
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: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: without comment
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>

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: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: the birth of a new system
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>

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: <[email protected]>
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 [email protected])
Message-Id: <[email protected]>
Date: Thu, 25 Apr 91 09:23:03 -0400
From: [email protected] (Mark Hittinger)
To: [email protected]
Subject: please add me to the list
Reply-To: [email protected]


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: <[email protected]>
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" <[email protected]>
Message-Id: <[email protected]>
Organization: Dept of Redundancy Dept
Reply-To: Al Dykes <[email protected]>
To: "Tops-20 List"                      <[email protected]>
Cc: "Al Dykes @ jpr"            <[email protected]>



Please add me to the Tops-20 mail list.

Thanks


--


Al Dykes
--------------
Chief Assistant to the Assistant Chief,
Dept of Redundancy Dept.
[email protected]                   [email protected]



1-May-91 22:47:58-MDT,727;000000000000
Return-Path: <[email protected]>
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 <[email protected]>; Wed, 1 May 91 21:46 PDT
Message-Id: <[email protected]>
From: [email protected] (Richard Shoup)
Subject: PDP10 dectapes
To: [email protected]
Date: Wed, 1 May 91 21:46:49 PDT
Cc: [email protected] (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: <[email protected]>
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: [email protected]
From: [email protected]
Message-Id: <23557020501991/1816967@OAX>
App-Message-Id: <32947020501991/1057347@KSV>
To: [email protected], [email protected]
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:


       [email protected]



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: <[email protected]>
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 <[email protected]>; Tue, 7 May 91 09:45 PDT
Message-Id: <[email protected]>
From: [email protected] (Richard Shoup)
Subject: PDP10/20s & dectape
To: [email protected]
Date: Tue, 7 May 91 9:44:59 PDT
Cc: [email protected] (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
[email protected]

21-May-91 01:54:09-MDT,2888;000000000000
Return-Path: <@Sunburn.Stanford.EDU:[email protected]>
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 <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
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 [email protected].

RSVP:   (By June 5, if you are coming, or if you would like to contribute
       a message to attendees.)
       Internet:  [email protected]
       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: <[email protected]>
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 <[email protected]>
Subject: [SAIL Timesharing System <[email protected]>: life as a computer for a quarter of a century]
To: [email protected]
Message-ID: <[email protected]>

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: <[email protected]>
Received: from SAIL.Stanford.EDU by MCC.COM with TCP; Sat 8 Jun 91 00:24:21-CDT
Message-ID: <[email protected]>
Date: 07 Jun 91  2056 PDT
From: SAIL Timesharing System <[email protected]>
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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
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: <[email protected]>
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 <[email protected]>
Subject: Re: DEC-20 Telnet performance advice wanted
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

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:[email protected]>
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 <[email protected]>
Subject: Don't let these -20s be trashed!
To: [email protected]
Message-id: <[email protected]>
X-Envelope-to: [email protected]
X-VMS-To: IN%"[email protected]"


The following is from alt.folklore.computers.  If you're interested, send
a message to Rick Penza ([email protected]).

----------------------------------------------------------------------------

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: [email protected] (David Rochberg)
Newsgroups: alt.folklore.computers
Subject: DEC20's -- Save them from the graveyard
Message-ID: <[email protected]>
Date: 14 Jun 91 16:51:34 GMT
Sender: [email protected] (Usenet News)
Reply-To: [email protected]
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:[email protected]>
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 <[email protected]>
Subject: Another DEC-20 that needs a home
To: [email protected]
Message-id: <[email protected]>
X-Envelope-to: [email protected]
X-VMS-To: IN%"[email protected]"


Here is another offer of a DEC-20, also re-posted from alt.folklore.computers.
Reply to D. Gubbins ([email protected]) if interested.

-------------------------------------------------------------------------------

Date:    Thu, 6 Jun 1991 10:30:14 EDT
From: [email protected] (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:    [email protected] (The Gern)
To:      [email protected], [email protected]
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: <[email protected]>
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: [email protected] (Joe Smith)
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: Where is "Systems Concepts" now?

Stephane Tsacas <[email protected]> wrote:
>Where can I reach System Concepts ?  Do thsy still build pdp10
>compatible machines ?

Rich Alderson <[email protected]> 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: [email protected] or [email protected]
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C51    | PDP-10: [email protected] 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: <[email protected]>
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 <[email protected]>
Subject: TOPS-20 jokes in print
To: [email protected]
Reply-To: [email protected]
Message-ID: <[email protected]>

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: <[email protected]>
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 <[email protected]>
Subject: The end of an era at Stanford....
To: "Hamlet shutdown message distribution": ;
Message-ID: <[email protected]>

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: <[email protected]>
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 <[email protected]>
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: <[email protected]>
To: [email protected], [email protected]
Subject: Re:  TOPS-20 jokes in print

       Date: Sun 30 Jun 91 14:48:32-PDT
       From: Eric M. Berg <[email protected]>
       To: [email protected]

       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: <[email protected]>
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 <[email protected]>
Subject: Re:  TOPS-20 jokes in print
To: [email protected]
In-Reply-To: <[email protected]>
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

   From: Phil Budne <[email protected]>
               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: <[email protected]>
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 <[email protected]>
To: [email protected]
Subject: Re: TOPS-20 jokes in print
In-Reply-To: Your message of Thu, 4 Jul 91 12:06:36 PDT
Message-Id: <[email protected]>



Mark Crispin <[email protected]> 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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
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: <[email protected]>
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: [email protected] (Shawn Mckay)
Reply-To: [email protected]
Message-Id: <[email protected]>
To: [email protected]
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: [email protected]
Uucp: mit-eddie!shawn
21-Jul-91 11:26:46-MDT,902;000000000000
Return-Path: <[email protected]>
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: [email protected]
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB25);
       id AA21360; Sun, 21 Jul 91 13:21:39 EDT for [email protected]
Date: Sun, 21 Jul 91 13:22:08 EDT
From: [email protected]
To: [email protected]
Message-Id: <[email protected]>
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: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Time zone confusion in 7.0
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>

       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: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: bug in TCOPR% .TCSTP function
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>

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: <[email protected]>
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: [email protected] (Joe Smith)
Message-Id: <[email protected]>
To: [email protected]
Subject: Another TOPS20 site going down
Newsgroups: ddn.mgt-bulletin
In-Reply-To: <[email protected]>

I found this while reading news:

>DDN MGT Bulletin 84              DCA DDN Defense Communications System
>4 Sept 91                        Published by: DDN Network Info Center
>                                     ([email protected])  (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: [email protected]  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: <[email protected]>
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 <[email protected]>
To: [email protected]
Subject: Bug Check on 2020
Message-Id: <[email protected]>


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: <[email protected]>
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 <[email protected]>
Subject: re: Bug Check on 2020
To: Benjamin Britt <[email protected]>
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>

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: <[email protected]>
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: <[email protected]>
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 <[email protected]>
To: [email protected], [email protected]
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: <[email protected]>
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 <[email protected]>
To: [email protected]
Subject: BUGCHK P11PAR
Message-Id: <[email protected]>


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: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
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: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: SKDPF1 bughlts
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>

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: <[email protected]>
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: [email protected]
Date: Tue, 24 Sep 91 13:41:34 EDT
From: "Shawn F. Mckay" <[email protected]>
To: [email protected]
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: <[email protected]>
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 <[email protected]>
Subject: Ring Buffers
To: [email protected]
Message-ID: <[email protected]>

       Date: Thu, 26 Sep 91 22:20:14 EDT
       From: [email protected] (Dave Goldblatt)
       Subject: Help Requested in Defeating Ring Buffer Software Patent
       Reply-To: [email protected]


               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: <[email protected]>
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: [email protected] (Stu Grossman)
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Clive Dawson's message of Fri 27 Sep 91 17:26:28-CDT <[email protected]>
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: <[email protected]>
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: [email protected] (Joe Smith)
Message-Id: <[email protected]>
To: [email protected], [email protected]
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: [email protected] or [email protected]
BTNA Tech Services TYMNET| UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C51     | PDP-10: [email protected] 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: <[email protected]>
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 <[email protected]>
To: Clive Dawson <[email protected]>
Cc: [email protected],
       [email protected] (Dave Goldblatt)
Subject: Re: Ring Buffers
In-Reply-To: Your message of Fri 27 Sep 91 17:26:28-CDT
Message-Id: <[email protected]>

>       Date: Thu, 26 Sep 91 22:20:14 EDT
>       From: [email protected] (Dave Goldblatt)
>       Subject: Help Requested in Defeating Ring Buffer Software Patent
>       Reply-To: [email protected]
>
>
>               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: <[email protected]>
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: [email protected] (Rob Gingell)
Message-Id: <[email protected]>
To: [email protected], [email protected]
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: <[email protected]>
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 <[email protected]>
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: Ring Buffers
Cc: [email protected], [email protected],
       [email protected]

       Date: Sun, 29 Sep 1991 7:52:45 MET
       From: Johnny Eriksson <[email protected]>

       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: <[email protected]>
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: [email protected] (Joe Smith)
Message-Id: <[email protected]>
To: [email protected], [email protected]
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: [email protected]  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:[email protected]>
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 <[email protected]>
Subject: Re: Ring Buffers
To: [email protected], [email protected]
Message-id: <[email protected]>
X-Envelope-to: [email protected], [email protected]
X-VMS-To: IN%"[email protected]"
X-VMS-Cc: IN%"[email protected]"

>       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
                               [email protected]
2-Oct-91 04:06:29-MDT,1538;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:[email protected]>
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 <[email protected]>
Subject: Re: Ring Buffers
To: [email protected]
Message-id: <[email protected]>
X-Envelope-to: [email protected]
X-VMS-To: IN%"[email protected]"

> 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: [email protected]  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
                               [email protected]
3-Oct-91 17:18:20-MDT,1481;000000000000
Return-Path: <[email protected]>
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: [email protected] (Joe Smith)
Message-Id: <[email protected]>
To: [email protected]
Subject: Time to drop the Ring Buffers?

Dave Goldblatt <[email protected]> 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: [email protected]  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:[email protected]>
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 <[email protected]>
Subject: Re: Ring Buffers
To: [email protected]
Message-id: <[email protected]>
X-Envelope-to: [email protected]
X-VMS-To: IN%"[email protected]"

> 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
                               [email protected]
4-Oct-91 13:24:03-MDT,1474;000000000000
Return-Path: <[email protected]>
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: [email protected]
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

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:[email protected]>
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: [email protected] (Stu Grossman)
Message-Id: <[email protected]>
To: [email protected]
Subject: [[email protected]: TOPS-10 experience?]

Return-Path: <[email protected]>
Date: Tue, 8 Oct 91 11:20:45 -0700
From: [email protected] (Andrew Purshottam)
To: [email protected]

From: [email protected] (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        [email protected]

7-Nov-91 14:56:01-MST,1707;000000000000
Return-Path: <[email protected]>
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 <[email protected]>
Subject: System 1022 and Disk Bit table Lossage
To: [email protected]
Message-ID: <[email protected]>

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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
Cc: [email protected]
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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
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: <[email protected]>
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 <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Telnet DATA MARK
To: Douglas Bigelow <[email protected]>
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
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: <[email protected]>
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: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
Cc: [email protected]
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 <[email protected]>

>> 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: <[email protected]>
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: <[email protected]>
From: Rob Austein <[email protected]>
Sender: [email protected]
To: [email protected]
Cc: [email protected]
In-Reply-To: Douglas Bigelow's message of Tue, 17 Dec 91 16:18:33 -0500 <[email protected]>
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: <[email protected]>
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 <[email protected]>
Subject: Happy DEC-20 Day
To: [email protected]
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

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

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.