2-Jan-92 08:13:03-MST,2963;000000000000
Return-Path: <[email protected]>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 Jan 92 08:12:35 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
       id AA05397; Thu, 2 Jan 92 10:12:26 -0500
Date: Thu, 2 Jan 92 10:12:26 -0500
Message-Id: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
Subject: More TELNET problems

Greetings, all;

As long as I've had my old TOPS20 hat recently, I though I'd air
another Telnet option negotiation problem.  This one is similar to the
DATA MARK problem I'd mentioned a few days ago.

Here's a problem I've seen from NCSA Telnet clients connecting to my KL.
Sending two IAC IP (interrupt process) commands will hang the connection.
In the Macintosh version of NCSA Telnet a control-C sends an IAC IP by
default, so it's a frequent problem.  In this specific case, what's
happening is:

1st control-C:

       PC  to KL:              IAC IP          ;interrupt process
                               IAC DO TM       ;do timing mark

       KL to PC:               IAC WILL TM     ;will timing mark
                               IAC DM          ;data mark
                               IAC DO TM       ;do timing mark

       PC  to KL:              IAC WONT TM     ;wont timing mark

2nd control-C:

       PC  to KL:              IAC IP          ;interrupt process
                               IAC DO TM       ;do timing mark

       KL to PC:               IAC DM          ;data mark
                               IAC DO TM       ;do timing mark

       PC  to KL:              IAC WONT TM     ;wont timing mark

Note that the second time, the 20 didn't respond to the timing mark request.
The client, meanwhile, is properly discarding output waiting until the
timing mark is acknowledged.  Communications continue both ways, but there
is no longer any echo to the client screen.  Closing the telnet connection
and restarting is the only remedy.

I can patch this one in the NVTDO: routine of TTANDV, where DO processing
is handled.  At NVTDO1: +2 there is the sequence:

       TDNE T3,NCTOPF(T2)      ;IS THE OPTION ON?
        JRST NVTSNR            ;YES, SEND NO REPLY

If I patch out the JRST with a JFCL, everything works.  The 20 seems to
think that DO/DONT sequences will only come once and can be ignored if
they're repeated.  This breaks conventional timing mark logic.

I haven't really investigated to see if the above patch has any other side
effects.  Is there something I've missed?


There's a more serious problem that I've made no progress in diagnosing.
When NCSA Telnet users connected to the KL are TYPE'ing out long files,
about 50% of the time the typing rate will start dramatically slowing
after five to ten pages of output.  The connection will slow and slow
until it's typing out a line or so every thirty seconds.  If you try to
control-C out, it may take several minutes before it will respond.  Then
things will return to normal for subsequent commands.

It's not related to either system or network load -- other connections
will be humming along at high speed while this occurs.  Any obvious ideas?

Thanks --

Doug

3-Jan-92 07:39:16-MST,4671;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 3 Jan 92 07:39:04 MST
Date: Thu, 2 Jan 92 18:39:21 CST
From: Clive Dawson <[email protected]>
Subject: Admiral Grace Murray Hopper dies
To: [email protected]
Message-ID: <[email protected]>

I came across the following item, and figured this list probably contains
quite a few people who had the pleasure of knowing or meeting Admiral Hopper.
Another giant passes...

                             Admiral Hopper Dies

             Rear Admiral Grace Murray Hopper (USNR Ret.) died New
        Year's Day at her home in Arlington, Virginia. She had
        celebrated her 85th birthday on December 9.
             At the time of her death she was employed as a senior
        consultant at Digital Equipment Corporation, and until 18
        months ago was actively representing the company at industry
        forums, making presentations that focused on Government
        issues and participating in corporate educational programs.
             In September, President George Bush awarded the National
        Medal of Technology to Admiral Hopper "for her pioneering
        accomplishments in the development of computer programming
        languages that simplified computer technology and opened the
        door to a significantly larger universe of users." She was
        the first woman to receive the award as an individual.
             Admiral Hopper was sometimes called "Amazing Grace"
        because she recorded successful careers in academia, business
        and the United States Navy while making history in the
        computer field. Just as Adm. Hyman Rickover was father of the
        nuclear navy, Rear Adm. Hopper was the mother of computerized
        data automation in the naval service.
             Admiral Hopper joined Digital in 1986, shortly after her
        retirement as the U.S. Navy's oldest officer on active duty.
        The ceremony was conducted aboard the USS Constitution, the
        service's oldest commissioned warship. She had devoted her
        military career to keeping the Navy on the leading edge of
        computer technology.
             Admiral Hopper was born Grace Brewster Murray on
        December 9, 1906 in New York City. She began summering in
        Wolfeboro, N.H., in 1907 and regarded the town on the shores
        of Lake Winnipesaukee as her second home.
             After receiving a Ph.D in mathematics from Yale, she
        began her professional life as a math teacher at Vassar
        College, her alma mater, where she ultimately became an
        associate professor. Later, she worked as a top scientist at
        Sperry Corporation and its predecessors.
             However, her employer of choice was always the Navy,
        which she joined in 1943 at the height of World War II. As a
        lieutenant assigned to the Bureau of Ordnance Computation
        Project at Harvard University, Adm. Hopper was thrust into
        the world of computing as a programmer on the first large
        scale digital computer, the Mark I.
             Mustered out of the Navy in 1946, she remained at
        Harvard as a faculty member in the computation laboratory.
        She continued to work on Mark II and Mark II Navy computers
        and maintained her Navy career as an active duty reservist.
             Although retired from the Navy reserve in 1966 because
        of age, Adm. Hopper was recalled within a year to full-time
        active duty and steadily advanced to flag rank. Her
        assignment to the Naval Data Automation Command in
        Washington, D.C., permitted her to refine computer language
        techniques to the Navy's advantage and to keep that service
        at the cutting edge of computer technology.
             Adm. Hopper had received honorary degrees from more than
        40 colleges and universities, and had been honored by her
        peers on several occasions. She was recipient of the first
        Computer Sciences "Man of the Year" award given by the Data
        Processing Management Association. Her entry in "Who's Who"
        takes 34 lines to thumbnail her accomplishments, appointments
        and honors.
             She is survived by a brother, Dr. Roger F. Murray II of
        New Hampshire, a sister, Mary Murray Westcote of New Jersey,
        nieces and nephews.

-------
6-Jan-92 08:00:47-MST,1635;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Jan 92 08:00:07 MST
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.23 ) id AA24025; Sun, 5 Jan 92 21:27:33 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA00379; Sun, 5 Jan 92 21:27:28 PST
Date: Sun, 5 Jan 1992 21:27:08 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: TELNET
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Doug -

    The code you commented out is important, because it prevents protocol
loops.  The bug occurs when two sides are losing; they'll go babbling at each
other endlessly.  You are never supposed to acknowledge a change into a state
you are already in.

    A better fix would probably be to have TOPS-20 always say `WONT TM',
since you want a response to all options.  I think if you patch NVTDTM to be a
RET you'll get this behavior.  Timing mark is a very poorly thought-out option
in Telnet protocol and it's a shame this hasn't been cleaned up.

    Clients should never discard output waiting on timing marks.  The anchor
for such things is a data mark.

    It may be worthwhile getting a protocol analyzer for the slowdown bug.
That sounds a lot like silly window syndrome, which TOPS-20 is supposed to be
able to avoid.

-- Mark --


8-Jan-92 08:24:00-MST,659;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 8 Jan 92 08:07:46 MST
Date: Wed, 8 Jan 92 10:09 EST
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: Who still has DEC-20's
To: [email protected]
X-VMS-To: @TOPS

Folks,

       We still operate two DEC-20's in a cluster doing MIS type processing.

       I am interested in finding out who still runs DEC-10's or DEC-20's
doing production business processing and what they play to do. If any one
has names and contacts of folks who are in this and can share them, please
send them along.


Thanx,
Jerry Weiner
9-Jan-92 09:21:37-MST,1757;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 9 Jan 92 09:21:33 MST
Date: Thu, 9 Jan 92 10:19:12 CST
From: Clive Dawson <[email protected]>
Subject: Re: Who still has DEC-20's
To: [email protected]
cc: [email protected]
In-Reply-To: Message from "JERRY WEINER BBN 617-873-3242 <[email protected]>" of Thu, 9 Jan 92 09:51:10 CST
Message-ID: <[email protected]>

       We still operate two DEC-20's in a cluster doing MIS type processing.

       I am interested in finding out who still runs DEC-10's or DEC-20's
       doing production business processing and what they play to do. If any
       one has names and contacts of folks who are in this and can share
       them, please send them along.


       Thanx,
       Jerry Weiner

Hi Jerry!

  The Texas State Purchasing Commission still operates a DEC-10 (1090
system, I believe) for various business DP applications.  I don't
have any info on their future plans, but could probably dig up a
contact if you'd like.

Meanwhile, I'd like to expand your query and find out who still runs
ANY DEC-10's or 20's, regardless of the application.  If folks on this
list reply to me giving me info on systems they're still running, or
other systems they know about, I'll compile it all and post it.
Something more or less as follows would be good:

System type:                    DEC-2065
Operating System/Version:       TOPS-20  5.4/6.0
Organization:                   MCC
Location:                       Austin, Texas
Primary use (business/
   education/research/etc):    Research
Hostname (if any):              MCC.COM
Approx. shutdown date (if any): Spring, 1992
Primary contact (if known):     Clive Dawson  512-338-3430

Feel free to add any other relevant info.

Cheers,

Clive
-------
10-Jan-92 14:49:06-MST,1769;000000000000
Return-Path: <[email protected]>
Received: from mathom.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 10 Jan 92 14:48:59 MST
Date: Fri 10 Jan 92 13:47:20-PST
From: William "Chops" Westfield <[email protected]>
Subject: Re: Who still has DEC-20's
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

System type:                    DEC-2065
Operating System/Version:       TOPS-20  6.1 (Stanford)
Organization:                   cisco
Location:                       Menlo Park, CA
Primary use (business/
   education/research/etc):    BillW reads his mail, SUDS
Hostname (if any):              Mathom.cisco.com
Approx. shutdown date (if any): soon
Primary contact (if known):     No one :-(

System type:                    DEC-2065
Operating System/Version:       TOPS-20  6.1 (Stanford)
Organization:                   cisco
Location:                       Menlo Park, CA
Primary use (business/
   education/research/etc):    Part of cisco customer database
Hostname (if any):              Heap.cisco.com
Approx. shutdown date (if any): soon
Primary contact (if known):     No one :-(

cisco had a total of four 20's at one point (Mathom, Heap, Hulk,
and a spare)  Currently we would like to get rid of them all, but
they linger due to databases and stuff that are difficult to move
(and moving them is a low priority.)

SUDS is the "Stanford University Drawing System", a schematic capture/pc
layout system we used for many of our early designs (MCI, CSC-16, CSC/2).
Newer designs are being done with newer packages that support simulation
as well, which I guess is good.  At least one 20 will probably be here
forever to continue to support those designs.

I think I'm the last person who actually reads mail on the 20.

BillW
-------
11-Jan-92 10:17:43-MST,2274;000000000000
Return-Path: <[email protected]>
Received: from tymix.Tymnet.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 11 Jan 92 10:17:39 MST
Received: from tardis.tymnet.com by tymix.Tymnet.COM (4.1/SMI-4.1)
       id AA07110; Fri, 10 Jan 92 19:18:44 PST
Received: by tardis.tymnet.com (4.1/SMI-4.1)
       id AA02066; Fri, 10 Jan 92 19:18:42 PST
From: [email protected] (Joe Smith)
Message-Id: <[email protected]>
Subject: Re: Who still has DEC-20's
To: [email protected] (Clive Dawson)
Date: Fri, 10 Jan 92 19:18:40 PST
Cc: [email protected]
In-Reply-To: <[email protected]>; from "Clive Dawson" at Jan 9, 92 10:19 am
X-Mailer: ELM [version 2.3 PL11]

System type:                    DEC-1090
Operating System/Version:       TYMCOM-X P035/E01 (TOPS-10 variant)
Organization:                   BT North America, TYMNET Operations
Location:                       Fremont, California
Primary use (business/
   education/research/etc):    Business
Primary contact (if known):     Carl Baltrunas, 408/922-6206
Hostname and shutdown date:     (MX only, these have no IP addresses)
       F23.Tymnet.COM          -
       F26.Tymnet.COM          Summer 1992
       F30.Tymnet.COM          -
       F33.Tymnet.COM          Fall 1992
       F34.Tymnet.COM          -
       F37.Tymnet.COM          1-Jul-91
       F38.Tymnet.COM          -
       F56.Tymnet.COM          30-Sep-91
       F74.Tymnet.COM          -               (MAIL host)

System type:                    DEC-2020
Operating System/Version:       TYMCOM-X P035/E01 (TOPS-10 variant)
Organization:                   BT North America, TYMNET Operations
Location:                       San Jose, California
Primary use (business/
   education/research/etc):    Business
Primary contact (if known):     Joe Smith, 408/922-6220
Hostname and shutdown date:     (MX only, these have no IP addresses)
       X14.Tymnet.COM          -
       X17.Tymnet.COM          -

System type:                    DEC-2020
Operating System/Version:       TYMCOM-X P035/C01 (TOPS-10 variant)
Organization:                   TRW Network Services
Location:                       Anaheim, California
Primary use (business/
   education/research/etc):    Business
Hostname and shutdown dates:    S33, Summer 1992

--
Joe Smith (408)922-6220  | SMTP: [email protected] or [email protected]
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."
13-Jan-92 08:02:48-MST,2153;000000000000
Return-Path: <[email protected]>
Received: from dirt.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 13 Jan 92 08:02:42 MST
Received: by dirt.cisco.com; Sun, 12 Jan 92 07:01:11 -0800
Date: Sun, 12 Jan 92 07:01:11 -0800
From: Doug Faunt N6TQS 415-688-8269 <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Subject: Who still has DEC-20's

  Date: Fri 10 Jan 92 13:47:20-PST
  From: William "Chops" Westfield <[email protected]>

  System type:                 DEC-2065
  Operating System/Version:    TOPS-20  6.1 (Stanford)
  Organization:                        cisco
  Location:                    Menlo Park, CA
  Primary use (business/
      education/research/etc): BillW reads his mail, SUDS
  Hostname (if any):           Mathom.cisco.com
  Approx. shutdown date (if any):      soon
  Primary contact (if known):  No one :-(

  System type:                 DEC-2065
  Operating System/Version:    TOPS-20  6.1 (Stanford)
  Organization:                        cisco
  Location:                    Menlo Park, CA
  Primary use (business/
      education/research/etc): Part of cisco customer database
  Hostname (if any):           Heap.cisco.com
  Approx. shutdown date (if any):      soon
  Primary contact (if known):  No one :-(

  cisco had a total of four 20's at one point (Mathom, Heap, Hulk,
  and a spare)  Currently we would like to get rid of them all, but
  they linger due to databases and stuff that are difficult to move
  (and moving them is a low priority.)

  SUDS is the "Stanford University Drawing System", a schematic capture/pc
  layout system we used for many of our early designs (MCI, CSC-16, CSC/2).
  Newer designs are being done with newer packages that support simulation
  as well, which I guess is good.  At least one 20 will probably be here
  forever to continue to support those designs.

  I think I'm the last person who actually reads mail on the 20.

  BillW
  -------

There are about 10 people who get their mail on mathom, and a larger
number who get their mail on heap, still.



13-Jan-92 08:24:17-MST,1362;000000000000
Return-Path: <[email protected]>
Received: from sunlight.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 13 Jan 92 08:24:13 MST
Received: from elaine46.Stanford.EDU by sunlight.Stanford.EDU (4.1/AIR-1.0)
       id AA24012; Sat, 11 Jan 92 18:48:19 PST
Date: Sat, 11 Jan 92 18:48:19 PST
From: [email protected]
Message-Id: <[email protected]>
Received: by elaine46.Stanford.EDU (4.1/SMI-4.1)
       id AA04696; Sat, 11 Jan 92 18:48:18 PST
To: [email protected]
In-Reply-To: William "Chops" Westfield's message of Fri 10 Jan 92 13:47:20-PST <[email protected]>
Subject: Who still has DEC-20's
Reply-To: [email protected]

Well, I know a couple of people in cisco's MIS department who read mail there.

And I'm upgrading the monitor on their system (Heap) to at least AP16 to fix a
nasty 1022 interaction.  Does anyone remember if AP18 or 19 was the last 6.1
autopatch?

Unbelievable.  I'm still (available as) a Tops-20 hacker in this day and age.

Rich Alderson   'I wish life was not so short,' he thought.  'Languages take
               such a time, and so do all the things one wants to know about.'
                                                       --J. R. R. Tolkien,
[email protected]                              _The Lost Road_
15-Jan-92 13:39:13-MST,3786;000000000000
Return-Path: <[email protected]>
Received: from oaunx1.CTD.ORNL.GOV by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Jan 92 13:39:04 MST
Received: by oaunx1.CTD.ORNL.GOV (5.57/Ultrix2.4-C)
       id AA26584; Wed, 15 Jan 92 10:46:10 -0500
Received: from umcgate by oaunx1 via MR/STC10 with conversational-MRIF;
       Wed, 15 Jan 92 10:46:09 -0500
Posted: Wed, 15 Jan 92 10:40:47 -0500
Date: Wed, 15 Jan 92 10:35:01 -0500
Sender: [email protected]
From: "Jeffrey A Jones" <[email protected]>
Message-Id: <64040151102991/726744@STC>
App-Message-Id: <10930151102991/1611675@KSV>
To: [email protected]
Cc: [email protected], [email protected]
Subject: MMES - Oak Ridge, TN - DEC 10/20's
Msg-Class: ALL-IN-1 V2.4 PBL8C3  7-JUN-1990

[This message is converted from WPS-PLUS to ASCII]




------- Forwarded message

Posted: Wed, 15 Jan 92 00:00:01 -0500
Date: Wed, 15 Jan 92 10:00:01 -0500
Author: jeffrey a jones
Subject: MMES - Oak Ridge, TN - DEC 10/20's                                              NONE

[This message is converted from WPS-PLUS to ASCII]


All,

Following is the current list of DEC-10 and DEC-20's running at Martin Marietta
Energy Systems (MMES) in Oak Ridge, Tn.  As a rough estimate, these systems in
total have a user base of between 5000 - 7000 users.

Jeff Jones
[email protected]
(615)576-2335

-------------------------------------------------------------------------------
System Type:                    Five Processor DEC-10 (KL10-DA's)
Operating System/Version:       TOPS-10 V7.03
Organization:                   Computing & Telecommunications Division
Location:                       Oak Ridge, Tn
Primary use:                    IS
Hostname:                       No external hostname
Approx. Shutdown Date:          1993
Primary Contact:                Wishes to remain anonymous

-------------------------------------------------------------------------------
System Type:                    Single Processor DEC-10 (KL10-EA)
Operating System/Version:       TOPS-10 V7.03
Organization:                   Business Systems
Location:                       Oak Ridge, TN
Primary use:                    MIS
Hostname:                       No external hostname
Approx. Shutdown Date:          1993
Primary Contact:                Wishes to remain anonymous

-------------------------------------------------------------------------------
System Type:                    DEC-2060
Operating System/Version:       TOPS-20 V7.0
Organization:                   Computing & Telecommunications Division
Location:                       Oak Ridge, Tn
Primary use:                    MIS
Hostname:                       No external hostname
Approx. Shutdown Date:          No specific time schedule but applications are
                                       being converted to other platforms.
Primary Contact:                Wishes to remain anonymous

-------------------------------------------------------------------------------
System Type:                    DEC-2065 (not clustered, but have disks dual
                                       ported with system below)
Operating System/Version:       TOPS-20 V6.1
Organization:                   Computing & Telecommunications Division
Location:                       Oak Ridge, Tn
Primary use:                    MIS
Hostname:                       No external hostname
Approx. Shutdown Date:          July, 1993
Primary Contact:                Wishes to remain anonymous

-------------------------------------------------------------------------------
System Type:                    DEC-2065 (not clustered, but have disks dual
                                       ported with system above)
Operating System/Version:       TOPS-20 V6.1
Organization:                   Computing & Telecommunications Division
Location:                       Oak Ridge, Tn
Primary use:                    MIS
Hostname:                       No external hostname
Approx. Shutdown Date:          July, 1993
Primary Contact:                Wishes to remain anonymous

-------------------------------------------------------------------------------
System Type:                    DEC-2065
Operating System/Version:       TOPS-20 V6.1
Organization:                   Procurement Division
Location:                       Oak Ridge, Tn
Primary use:                    MIS
Hostname:                       No External hostname
Approx. Shutdown Date:          1993
Primary Contact:                Jeff Jones


------- End of Forwarded message

21-Jan-92 08:30:24-MST,1703;000000000000
Return-Path: <[email protected]>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 Jan 92 08:30:07 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
       id AA01530; Mon, 20 Jan 92 16:46:33 -0500
Date: Mon, 20 Jan 92 16:46:33 -0500
Message-Id: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
Subject: Strange problems with page mapping

I've been seeing a strange problem with page mapping lately, on a system
which has not had any system software changes for years.  I thought I'd
toss this out for comment.

When our 2060 is fairly busy with many 1022 users, they occasionally fail
with an unexpected page mapping error.  Investigation finally yielded:

       Program is trying to map a page of a disk file into memory
       for read only access.  In a typical sample, file page 0 might be
       being mapped into process page 2015.

       The PMAP fails with the error "Entire file structure full".

       There is no problem accessing the file, and typically several
       other files have already been mapped in similar ways.

Since none of the file structures are anywhere near full, and in any case
the PMAP operation is mapping a read-only file into memory, my best guess
is that my swapping space is filling up and I'm getting a misleading
message.  Can anyone suggest another alternative?

Even though we're phasing this system out, since replacing direct lines
with Telnet access the system has gotten more popular and considerably
busier.  Otherwise the software has been static for years.

Thanks for any advice!

/ Doug Bigelow
 Wesleyan University
22-Jan-92 02:55:36-MST,1283;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 22 Jan 92 02:55:33 MST
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.23 ) id AA28859; Wed, 22 Jan 92 01:55:24 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA01241; Wed, 22 Jan 92 01:55:18 PST
Date: Wed, 22 Jan 1992 01:50:33 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Strange problems with page mapping
To: Douglas Bigelow <[email protected]>
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

`Entire file structure full' is the lying string from the OPNX10 error.  The
real cause of this error is that you have run out of OFN's.  If you are
running many 1022 jobs I am not terribly surprised that this happens.

Rebuild your monitor with a larger value of NOFN, and while you are at it you
may want to increase SSPT as well.

How's that for a quick and easy answer?  ;-)

-- Mark --

22-Jan-92 09:37:12-MST,1076;000000000000
Return-Path: <[email protected]>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 22 Jan 92 09:36:46 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
       id AA01019; Wed, 22 Jan 92 11:36:30 -0500
Date: Wed, 22 Jan 92 11:36:30 -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, 22 Jan 1992 01:50:33 -0800 (PST)
Subject: Re: Strange problems with page mapping

>> `Entire file structure full' is the lying string from the OPNX10 error.  The
>> real cause of this error is that you have run out of OFN's.  If you are
>> running many 1022 jobs I am not terribly surprised that this happens.

Whoops, I'm embarrassed.  After your message, I went back and looked at the
CTY logs and found some NOOFN bugchecks.  If I'd checked there first, the
problem would have been obvious and I wouldn't have wasted my time debugging.

Thanks again, Mark!

-- Doug
31-Jan-92 09:23:25-MST,483;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com ([128.89.1.145]) by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 31 Jan 92 09:22:17 MST
Date: Fri, 31 Jan 92 08:54 EST
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: SCSI Adapter for MASSBUS
To: [email protected]
X-VMS-To: @TOPS

Folks,

       Did or does anyone make a real product to attach SCSI tapes to
a massbus that looks like a TOPs-20 supported tape device?


Thanx,
Jerry
6-Feb-92 08:11:25-MST,588;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 6 Feb 92 08:11:20 MST
Date: Thu, 6 Feb 92 08:19 EST
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: MASSBUS to SCSI
To: [email protected]
X-VMS-To: @TOPS

Folks,

       I put a note ou the other day asking if anyone knew of a MASSBUS
to SCSI adapter for a DEC20. The SC Group (old Sytems Concepts) makes a board
that replaces an RH10/20 and yields a SCSI bus. they also sell the disks and
TOPS 10/20 monitor code changes.


Jerry Weiner
12-Feb-92 14:43:35-MST,995;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 12 Feb 92 14:43:32 MST
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.23 ) id AA24188; Wed, 12 Feb 92 13:42:12 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA00321; Wed, 12 Feb 92 13:42:08 PST
Date: Wed, 12 Feb 1992 13:40:15 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: UP2LNG bughlt
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Have you seen the new UP2LNG bughlt?  Apparently, DEC has decided that TOPS-20
may not live longer then 397 days, 16 hours, and 22 minutes.  So, it looks
like multi-year uptimes are not on our horizon...

-- Mark --

12-Mar-92 21:52:48-MST,1470;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 12 Mar 92 21:52:44 MST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.24 ) id AA25848; Thu, 12 Mar 92 20:52:40 -0800
Date: Thu, 12 Mar 1992 20:50:04 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: sad news
To: TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This came in while SIMTEL20 was down.  This is sad news for all LCG hackers,
especially for the TOPS-10 folks.  I only had the pleasure of meeting Tony on
a couple of occasions.

 Subject: Bad news for old LCG-types (but I'm only the messenger)
 Date: Fri, 21 Feb 92 12:13:33 -0500
 From: [email protected]

 [Some of you may already have heard this news from another source.  If so,
 I'm sorry for the duplication, but we want to be sure that all interested
 parties are informed.]

 Tony Wachs passed away the morning of Thursday, 20-Feb-1992, after a fall on
 Sunday the 16th.  (A blood clot is the suspected cause.)


 Cards & letters to the family (his widow's name is Norma Rae Wachs) should
be
 addressed to

         1 High Street
         Natick MA 01760 [USA]

26-Mar-92 06:43:56-MST,445;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 26 Mar 92 06:43:53 MST
Date: Thu, 26 Mar 92 08:44 EST
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: field Service
To: [email protected]
X-VMS-To: @TOPS

Folks,

       Anyone know of any real organization doinng DEC-20 Field Service in the
New England area other than DEC?

Thanx,
Jerry Weiner

28-Mar-92 07:34:30-MST,569;000000000000
Return-Path: <[email protected]>
Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 28 Mar 92 07:34:26 MST
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31);
       id AA01219; Sat, 28 Mar 92 09:34:57 EST for [email protected]
Date: Sat, 28 Mar 92 09:32:50 EST
From: [email protected]
To: [email protected]
Message-Id: <[email protected]>
Subject: this list

Is this list still going?  Please add me to it if so.
I have a KS10+RM03+RM80 which I'm trying to get running.

Thanks,   [email protected]
30-Mar-92 19:15:21-MST,585;000000000000
Return-Path: <[email protected]>
Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 30 Mar 92 19:15:15 MST
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31);
       id AA29793; Mon, 30 Mar 92 21:15:49 EST for [email protected]
Date: Mon, 30 Mar 92 21:13:40 EST
From: [email protected]
To: [email protected]
Message-Id: <[email protected]>
Subject: KS10

I have been looking far and wide for a set of KS10 prints.
Does anyone have a set they'd be willing to copy for me?
I would cover all costs.

[email protected]
1-Apr-92 11:28:54-MST,3843;000000000000
Return-Path: <[email protected]>
Received: from Valinor.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 Apr 92 11:28:44 MST
Received: by Valinor.Stanford.EDU (5.65/inc-1.0)
       id AA08930; Wed, 1 Apr 92 10:28:29 -0800
Resent-Message-Id: <[email protected]>
Return-Path: <@jessica.stanford.edu:[email protected]>
Received: from Jessica.Stanford.EDU by Valinor.Stanford.EDU (5.65/inc-1.0) id
       AA07974; Wed, 1 Apr 92 00:55:15 -0800
Received: from spot.Colorado.EDU by jessica.stanford.edu (5.59/25-eef) id
       AA06583; Wed, 1 Apr 92 00:55:12 PDT
Received: by spot.Colorado.EDU id AA13332 (5.65c+/IDA-1.4.4/CNS-2.1 for
       cisco-ml2); Wed, 1 Apr 1992 01:39:46 -0700
Received: from regal.cisco.com by spot.Colorado.EDU with SMTP id AA13187
       (5.65c+/IDA-1.4.4/CNS-2.1 for <[email protected]>); Wed, 1 Apr
       1992 01:34:53 -0700
Received: by regal.cisco.com; Wed, 1 Apr 92 00:33:02 -0800
Date: Wed, 1 Apr 92 0:33:01 PST
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Subject: Press release
Message-Id: <[email protected]>
Resent-To: [email protected]
Resent-Date: Wed, 1 Apr 92 10:28:28 PST
Resent-From: Vince Fuller <[email protected]>

>
> Attached find a  press release, which will be
> announced today via various sources.
> --Bill
> ________________________________________________________________________
> > > Company contact:
> > >
> > > Bill Foonley
> > > Cisco Systems, Inc.
> > > (415) 092-0401
> > >
> > >
> > > FOR IMMEDIATE RELEASE
> > >
> > >
> > >          CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE
> > >           "WE'VE ALWAYS USED IT" SAY FOUNDERS
> > >
> > >

MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today announced
that they will pay an undisclosed sum of money to Digital Equipment
Corporation (DEC) in return for the rights to incorporate software
from DEC's "TOPS20" operating system in cisco's market leading routers
and communications servers.  "TOPS20" was the operating system for
DEC's line of 36-bit computers, which were made obsolete in 1983.
Cisco officials admitted that cisco routers have used tops20 code
since Cisco's founding in 1984, and that Cisco felt they should
"come clean" now that are in a sound financial position.

Cisco founder Len Bosack, contacted at his new company, XKL Inc,
commented: "The same software technology that allowed TOPS20, which
ran on a machine capable of one or two MIPS, to support many more
users than a modern '30 MIPS' workstation, allowed cisco to switch
12000 packets per second with a 12 MHz 68020, when our competitors
were throwing RISC processors with two or three times that clock rate
at the problem, and only getting half the end performance."  Mr Bosack
felt that DEC had abandoned the software,and had no moral qualms about
"borrowing" it for a completely different end product.  "We knew a
large number of 20 hackers, so it seemed a natural thing to do at the
time.  But cisco is more conservative now, and I guess they are
playing it safe [by paying DEC].  I had planned to add an additional 4
bits to the router CPU hardware so that we could make use of even more
of the tops20 software, but this was no longer acceptable, which is
why I founded XKL."  Another of cisco's founders, who asked not to be
identified, added that the original cisco router's cooling fan and
color scheme were also inspired by DEC's TOPS20 systems.

DEC's reaction to cisco's vounteering to pay for TOPS20 was mainly one
of surprise.  "Once we found someone who knew what they were talking
about, even he was surprised that there could still be money involved.
Still, times are hard, and money is money, so we aren't complaining."


1-Apr-92 14:07:24-MST,3676;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 Apr 92 14:07:17 MST
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.25 ) id AA03953; Wed, 1 Apr 92 13:06:56 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA01673; Wed, 1 Apr 92 13:06:44 PST
Date: Wed, 1 Apr 1992 13:05:24 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: [Alan H. Martin 01-Ap: FWD: TOPS-20, still making money...]
To: NDC Technical Staff <[email protected]>,
       TOPS-20 Hackers and Yackers <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I *knew* it!!!  ;-)

[Boy, they're flying fast and furious this year...]

** Begin Forwarded Message **

Date: Wed, 1 Apr 92 10:51:55 PST
From: Alan H. Martin 01-Apr-1992 1351 <[email protected]>
Subject: FWD: TOPS-20, still making money...
To: [email protected], [email protected], [email protected],
 [email protected], [email protected], [email protected],
 [email protected]

Subj:   FWD: TOPS-20, still making money...
Subj:   TOPS-20, still making money...
Subj:   TOPS20 Lives (at Cisco)

Company contact:

Bill Foonley
Cisco Systems, Inc.
(415) 092-0401


FOR IMMEDIATE RELEASE


         CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE
               "WE'VE ALWAYS USED IT" SAY FOUNDERS



MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today announced
that they will pay an undisclosed sum of money to Digital Equipment
Corporation (DEC) in return for the rights to incorporate software
from DEC's "TOPS20" operating system in cisco's market leading routers
and communications servers.  "TOPS20" was the operating system for
DEC's line of 36-bit computers, which were made obsolete in 1983.
Cisco officials admitted that cisco routers have used tops20 code
since Cisco's founding in 1984, and that Cisco felt they should
"come clean" now that are in a sound financial position.

Cisco founder Len Bosack, contacted at his new company, XKL Inc,
commented: "The same software technology that allowed TOPS20, which
ran on a machine capable of one or two MIPS, to support many more
users than a modern '30 MIPS' workstation, allowed cisco to switch
12000 packets per second with a 12 MHz 68020, when our competitors
were throwing RISC processors with two or three times that clock rate
at the problem, and only getting half the end performance."  Mr Bosack
felt that DEC had abandoned the software,and had no moral qualms about
"borrowing" it for a completely different end product.  "We knew a
large number of 20 hackers, so it seemed a natural thing to do at the
time.  But cisco is more conservative now, and I guess they are
playing it safe [by paying DEC].  I had planned to add an additional 4
bits to the router CPU hardware so that we could make use of even more
of the tops20 software, but this was no longer acceptable, which is
why I founded XKL."  Another of cisco's founders, who asked not to be
identified, added that the original cisco router's cooling fan and
color scheme were also inspired by DEC's TOPS20 systems.

DEC's reaction to cisco's vounteering to pay for TOPS20 was mainly one
of surprise.  "Once we found someone who knew what they were talking
about, even he was surprised that there could still be money involved.
Still, times are hard, and money is money, so we aren't complaining."

1-Apr-92 20:16:51-MST,3696;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 Apr 92 20:16:35 MST
Date: Wed, 1 Apr 92 19:21:54 CST
From: Clive Dawson <[email protected]>
Subject: Cisco Press Release
To: [email protected]
Message-ID: <[email protected]>

Found floating around on the net FYAmusement...

Cheers,

Clive

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

Return-Path: <[email protected]>
Received: from spot.Colorado.EDU by MCC.COM with TCP; Wed, 1 Apr 92 03:07:40 CST
Received: by spot.Colorado.EDU id AA13236
 (5.65c+/IDA-1.4.4/CNS-2.1 for cisco-ml1); Wed, 1 Apr 1992 01:34:57 -0700
Received: from regal.cisco.com by spot.Colorado.EDU with SMTP id AA13187
 (5.65c+/IDA-1.4.4/CNS-2.1 for <[email protected]>); Wed, 1 Apr 1992 01:34:53 -0700
Received: by regal.cisco.com; Wed, 1 Apr 92 00:33:02 -0800
Date: Wed, 1 Apr 92 0:33:01 PST
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Subject: Press release
Message-Id: <[email protected]>

>
> Attached find a  press release, which will be
> announced today via various sources.
> --Bill
> ________________________________________________________________________
> > > Company contact:
> > >
> > > Bill Foonley
> > > Cisco Systems, Inc.
> > > (415) 092-0401
> > >
> > >
> > > FOR IMMEDIATE RELEASE
> > >
> > >
> > >          CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE
> > >           "WE'VE ALWAYS USED IT" SAY FOUNDERS
> > >
> > >

MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today announced
that they will pay an undisclosed sum of money to Digital Equipment
Corporation (DEC) in return for the rights to incorporate software
from DEC's "TOPS20" operating system in cisco's market leading routers
and communications servers.  "TOPS20" was the operating system for
DEC's line of 36-bit computers, which were made obsolete in 1983.
Cisco officials admitted that cisco routers have used tops20 code
since Cisco's founding in 1984, and that Cisco felt they should
"come clean" now that are in a sound financial position.

Cisco founder Len Bosack, contacted at his new company, XKL Inc,
commented: "The same software technology that allowed TOPS20, which
ran on a machine capable of one or two MIPS, to support many more
users than a modern '30 MIPS' workstation, allowed cisco to switch
12000 packets per second with a 12 MHz 68020, when our competitors
were throwing RISC processors with two or three times that clock rate
at the problem, and only getting half the end performance."  Mr Bosack
felt that DEC had abandoned the software,and had no moral qualms about
"borrowing" it for a completely different end product.  "We knew a
large number of 20 hackers, so it seemed a natural thing to do at the
time.  But cisco is more conservative now, and I guess they are
playing it safe [by paying DEC].  I had planned to add an additional 4
bits to the router CPU hardware so that we could make use of even more
of the tops20 software, but this was no longer acceptable, which is
why I founded XKL."  Another of cisco's founders, who asked not to be
identified, added that the original cisco router's cooling fan and
color scheme were also inspired by DEC's TOPS20 systems.

DEC's reaction to cisco's vounteering to pay for TOPS20 was mainly one
of surprise.  "Once we found someone who knew what they were talking
about, even he was surprised that there could still be money involved.
Still, times are hard, and money is money, so we aren't complaining."

-------
2-Apr-92 12:17:08-MST,646;000000000000
Return-Path: <[email protected]>
Received: from wsmr-emh08.army.mil by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 Apr 92 12:17:02 MST
Date: Thu, 2 Apr 92 12:14:09 MST
From: "William D. Johnston  ASQNC-TWS-SS" <[email protected]>
Subject: Re: [Alan H. Martin 01-Ap: FWD: TOPS-20, still making money...]
In-Reply-To: Your message of Wed, 1 Apr 1992 13:05:24 -0800 (PST)
To: [email protected]
Cc: TOPS-20 Hackers and Yackers <[email protected]>,
   [email protected], [email protected],
   [email protected], [email protected]

April Fool(s)
2-Apr-92 12:33:26-MST,1551;000000000000
Return-Path: <[email protected]>
Received: from andrew.cmu.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 Apr 92 12:33:20 MST
Received: by andrew.cmu.edu (5.54/3.15) id <AA15936> for [email protected]; Thu, 2 Apr 92 14:33:00 EST
Received: via switchmail; Thu,  2 Apr 1992 14:32:59 -0500 (EST)
Received: from pcs5.andrew.cmu.edu via qmail
         ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.gdqq3zu00UhWQ0fYJI>;
         Thu,  2 Apr 1992 14:31:12 -0500 (EST)
Received: from pcs5.andrew.cmu.edu via qmail
         ID </afs/andrew.cmu.edu/usr1/pb0q/.Outgoing/QF.Idqq3tO00UhWQ53ow1>;
         Thu,  2 Apr 1992 14:31:05 -0500 (EST)
Received: from mms.0.1.873.MacMail.0.9.CUILIB.3.45.SNAP.NOT.LINKED.pcs5.andrew.cmu.edu.pmax.ul4
         via MS.5.6.pcs5.andrew.cmu.edu.pmax_ul4;
         Thu,  2 Apr 1992 14:31:05 -0500 (EST)
Message-Id: <[email protected]>
Date: Thu,  2 Apr 1992 14:31:05 -0500 (EST)
From: Pete Bronder <[email protected]>
To: NDC Technical Staff <[email protected]>,
       TOPS-20 Hackers and Yackers <[email protected]>,
       Data-Communications <[email protected]>,
       Mark Crispin <[email protected]>
Subject: Re: [Alan H. Martin 01-Ap: FWD: TOPS-20, still making money...]
Cc:
In-Reply-To: <[email protected]>
References: <[email protected]>

I was wondering why the feel of our Cisco backbone console reminded me
of Tops-E.  Now there was a computer!
6-Apr-92 15:18:47-MDT,815;000000000000
Return-Path: <[email protected]>
Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Apr 92 15:18:28 MDT
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31);
       id AA25119; Mon, 6 Apr 92 17:19:01 EDT for [email protected]
Date: Mon, 6 Apr 92 17:16:46 EDT
From: [email protected]
To: [email protected], [email protected]
Message-Id: <[email protected]>
Subject: CRAM chip

Hello,
Does anyone have or know where I can get the 93L415 static RAM chips
used in the KS10 microstore?  DEC & Ham/Av say it's obsolete and
unavailable, and JDR claims it's equivalent to the 2102 (250ns), which
is clearly false.

Either that, or does anyone have an M8622 CRA board that they're willing
to let go real cheap?

Thanks,   [email protected]
14-Apr-92 08:30:53-MDT,1027;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Apr 92 08:30:47 MDT
Date: Tue, 14 Apr 92 10:31 EDT
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: IPABTO BUGCHKS
To: [email protected]
X-VMS-To: @TOPS

Folks,

       Anyone have any tips on preventing IPABTO Bugchks. We are running
the latest TOPS-20 with all DEC's patches on two DEC-20's. DEC recommended
reducing NHOSTS to a small number to free up Internet Free space in the
monitor. NHOSTS is now 151. on our systems, we set this at about 3 times the
number of hosts we found in the table. This reduced the occurances of
IPABTO's but we still get them periodically, usually 5-6 minutes apart.
The IPABTO's usually have no correlation between the two DEC-20's. They
usually do not happen on both DEC-20 at the same times. Sometimes TCP/IP
stops working, but can be reactivated by running IPHOST and issing an INTERNET
CYCLE Command.

Thanx,
Jerry Weiner
14-Apr-92 23:43:12-MDT,2358;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Apr 92 23:43:02 MDT
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.25 ) id AA12507; Tue, 14 Apr 92 22:42:51 -0700
Date: Tue, 14 Apr 1992 22:30:35 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: last living example of WAITS (Foonly CPU) needs a new home
To: TOPS-20 Hackers and Yackers <[email protected]>,
       PDP-8 Lovers <[email protected]>
Cc: Peter Lothberg <[email protected]>,
       Pat Tressel <[email protected]>,
       Hobroken Gang <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Maximum distribution requestion.

    I have just been informed that the CCRMA Foonly F4, the last functioning
example of the WAITS PDP-10 operating system on the planet, has been retired.
It was powered down a week ago last Friday.  WAITS was the innovative
operating system developed at the Stanford AI Laboratory from a very old
version of TOPS-10 (back when they called it 10/50) -- the last merges were
from 3.54 days.  It had a fantastic display environment which has to date
remained unequalled by `modern' operating systems.

    Unless some kind soul interested in rescuing this piece of history speaks
up soon, it may end up being taken for scrap, perhaps as soon as Thursday.  It
was working as of the time it was powered down, although there were known to
be some glitches in its TTY and Ethernet interfaces.

    This machine and its software properly belongs in a museum, but until the
world realizes what valuable gems they are allowing to be casually trashed, it
is incumbant upon us to save this noble beast.  I would volunteer myself,
except I'm too busy with my myriad projects (including two 2020's) to give the
F4 the loving nuture it so badly needs.  It would probably end up in my
garage, which would destroy it.

    The person to contact for more information is Tovar (that's his complete
name).  He can be reached by e-mail at [email protected] or by telephone
at +1 (415) 328-0573.

15-Apr-92 01:38:13-MDT,1167;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Apr 92 01:38:09 MDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.25 ) id AA25114; Wed, 15 Apr 92 00:38:00 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA05203; Wed, 15 Apr 92 00:37:54 PDT
Date: Wed, 15 Apr 1992 00:35:49 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: IPABTO BUGCHKS
To: JERRY WEINER BBN 617-873-3242 <[email protected]>
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 14 Apr 92 10:31 EDT, JERRY WEINER BBN 617-873-3242 wrote:
>       Anyone have any tips on preventing IPABTO Bugchks.

Yes, I do.  Increase NNIPIB from its current definition of ^D40 to ^D120 and
rebuild your monitor.  DEC evidentally never uses a real Ethernet in the big
bad world.

28-Apr-92 06:43:48-MDT,1203;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 28 Apr 92 06:43:42 MDT
Date: Tue, 28 Apr 92 08:43 EDT
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: More TCP/IP Problems (TELNET ^S/^Q)
To: [email protected], [email protected]
X-VMS-To: IN%"[email protected]",@TOPS

Folks,

       Thanx to Mark Crispin for the tip to increase NNIPIB to prevent
IPABTO bugchks. This has reduced the number of occurances, but not eliminated
them. I have thought about increasing it again. Any thoughts Mark?


       The new problem for me. I sure this one been around a long time. When
someone TELNETs to the TOPS system from a DOS PC, a MAC, a VMS system, or an
IP terminal server (Annex or XYPLEX) repeated control S/Q's will cause the
the terminal session to hang. The session must then be terminated from the
source or Logged out on the DEC-20. Also typing a large file is significantly
slower than either a Front End line a a a Lat Terminal line. Anyone have
experience with this one?

       Any help will be appreciated. We are running the latested DEC supplied
S/W with all released patches.

Thanx,
Jerry Weiner.

29-Apr-92 07:25:30-MDT,2673;000000000000
Return-Path: <[email protected]>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 29 Apr 92 07:25:25 MDT
Received: by sandpiper.wesleyan.edu (5.61/1.35)
       id AA02033; Wed, 29 Apr 92 09:24:59 -0400
Date: Wed, 29 Apr 92 09:24:59 -0400
Message-Id: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: JERRY WEINER BBN 617-873-3242's message of Tue, 28 Apr 92 08:43 EDT
Subject: More TCP/IP Problems (TELNET ^S/^Q)

>> The new problem for me. I sure this one been around a long time. When
>> someone TELNETs to the TOPS system from a DOS PC, a MAC, a VMS system, or an
>> IP terminal server (Annex or XYPLEX) repeated control S/Q's will cause the
>> the terminal session to hang. The session must then be terminated from the
>> source or Logged out on the DEC-20. Also typing a large file is significantly
>> slower than either a Front End line a a a Lat Terminal line. Anyone have
>> experience with this one?

Yup, it sounds like the problems I was having when I first started using
Xyplex and Datability terminal servers connecting to my 2060.  There were
two problems: one was that the 20 wasn't putting the URGENT flag on in a
TELNET SYNC packet, and the server was treating a data mark like an
ordinary character.  The second (and worse) problem was that TELNET IP
functions were getting handled badly, causing the sort of hangs that
you've been seeing.

The large file typing problem may be related to a packet reassembly
problem which I also encountered.  I'll send you the specifics on these
three cases separately, rather than to the list.  You've seen some of the
background before, since I was asking for help on this list within the
last year, and received quite a bit.  Your problem flavors may well be
different, but I'll give you everything I have.

In general, after many, many hours with a network analyzer between our 20
and some of our lower-budget terminal servers, I've decided that the
problem is basically that the servers don't have a robust protocol
implementation.  They're fine when interacting with hosts based on
standard BSD Unix-style IP, but the 20 does things a little bit
differently in several areas of Telnet handling.  Those little differences
uncover large bugs in some of the servers.  I've also seen it when
interacting between the 20 and several PC or Macintosh TELNET programs.

I'm sure nobody will find this surprising, but I've never encountered any
problem communicating between a DEC-20 and a cisco server...

Doug
29-Apr-92 12:23:53-MDT,1669;000000000000
Mail-From: MRC created at 29-Apr-92 12:23:50
Date: Wed, 29 Apr 92 12:23:50 MDT
From: Mark Crispin <[email protected]>
Subject: INTFR1 crashes
To: [email protected]
Address: 6158 Lariat Loop NE; Bainbridge Island, WA  98110-2098
Phone: (206) 842-2385
Message-ID: <[email protected]>

For the past few years, and intensively for several months now, I have been
chasing after a very annoying INTFR1 system crash bug on SIMTEL20.  In every
case, the syndrome has been the same.  The block address is always of the
form 12,,xxx177 and the crash is caused by the block header word (and by all
appearances no other word) being overwritten by TCP data octets.  Often, but
not always, the octets are obvious ASCII (the last crash was `secu').  The
most popular block addresses are 12,,157177 and 12,,320177 but I've seen other
values of xxx including 402 and 664.

Has anyone else been seeing these crashes?  Of course, we don't see them on a
vanilla DEC monitor but the environment there is so different (no viable DNS
resolution, etc.) that it doesn't necessarily point to a local change.  It
could be a bug in special queues (used by our DNS resolver) for example.

It's gotten to the point where I am sorely tempted to write workaround code
(instead of crashing, hunt for the block trailer and re-create the header after
a bugchk) just to stop the crashes and frustrated users, but I really would
like to fix this bug and I'm sure if I wrote a workaround it would be out of
sight, out of mind...

There must be something significant about the 177 part of the address but I am
missing it.
-------
29-Apr-92 19:13:46-MDT,6369;000000000000
Return-Path: <[email protected]>
Received: from tymix.Tymnet.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 29 Apr 92 19:13:27 MDT
Received: from tardis.tymnet.com by tymix.Tymnet.COM (4.1/SMI-4.1)
       id AA29804; Wed, 29 Apr 92 18:13:05 PDT
Received: from romana.tymnet.com by tardis.tymnet.com (4.1/SMI-4.1)
       id AA20593; Wed, 29 Apr 92 18:12:58 PDT
Date: Wed, 29 Apr 92 18:12:58 PDT
From: [email protected] (Joe Smith)
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: SWITCH.INI in rec.humor.oracle.d

Path: tardis!olivea!uunet!cs.utexas.edu!asuvax!ukma!morgan
From: [email protected] (Wes Morgan)
Newsgroups: rec.humor.oracle.d
Subject: Not really a sore loser post, but an unpublished answer.....
Keywords: compunerdy   techie
Message-ID: <[email protected]>
Date: 23 Apr 92 12:24:15 GMT
Organization: University Of Kentucky, Dept. of Math Sciences
Lines: 101

I submitted this answer over 6 weeks ago.  For those of you with short
memories, this occurred during the "oracle answers are always full of
obscure computer geek stuff!" discussion.  I guess that a compunerdy
answer to a compunerdy question was doomed for the bit bucket; of course,
I might have also missed the deadline.  8)

Anyway, I haven't seen this question in the Digest, so here's my answer:


----------------------------------------------------------------------------
>> Oh wise and wonderful, wild and wooly Oracle, who not only knows how to
>> tune a fish, but also has the best recipe for tuna guitar, please tell
>> me this:

The Oracle is NOT a fan of REO Speedwagon.  Dwort-52 and the Sarefig
Bartoxons, yes, but NOT Earthly MOR.

>> Why do they keep patching new features into the stupid thing?  Can't
>> they see that it's about to break?

Of course they do!  Can't you understand....oh, that's right, you can't;
that's why you asked me.

You, my young friend, are part of the most grandiose, farthest-reaching
experiments in this planet's history of pschyocompunalysis -- The Great
User Boiling Point Search.

It started with a trivial thing, which most compusavvy individuals remem-
ber as the "switch".  "LOGIN" became "LOGIN /ACCOUNT:"string" /NEW /NOSCAN
/ASSIGN:dev1,log1 /CORE:nx /DEFER", and the users were amazed at the new
flexibility.

Over the years, leading pschocompunalysts realized that there must be a
finite point at which the users are actually overwhelmed by the sheer
number and variety (and near-infinite permutations of) the switches.  These
intrepid mindwalkers endeavored to determine that point.  They infiltrated
design teams and software developers; "ls" became, instead of the somewhat
legible "ls /ALL /SORT /FOO", the monstrosity known to today's users as
"ls -abcCdfFgilLmnopqrRstux".  The users were enraged, then confused, then
reduced to blithering, manual-wandering fools; the compunalysts were pleased.

However, these dedicated researchers failed to anticipate the nonnegligible
mindpower of the common user.  The users *adapted*; they defined macros,
they bound keys to the most obnoxious commands, and they wrote their own
command interpreters.  These users were quickly rising to the leading edge
of Userhood; some were even on the threshhold of Gurudom, where they would
undoubtedly discover the Experiment.

This could not be allowed.

The compunalysts realized that something incredible had to be done.  After
long sessions with trained chimps and high-school cheerleaders (with an
occasional shot from a randomizer), they created what they hoped would be
the ultimate gauge of the User Boiling Point:

-rwsr-xr-x   3 root     bin       182418 Apr 26  1989 /usr/lib/sendmail

Yes, this would surely lead them to the Boiling Point they so desperately
sought.  Simple concepts like "Joe User <[email protected]>" were converted
into tokens such as "Dq$?x$x <$g>$|$g$.".  The masses were once more thrown
into pandemonium; those who had been approaching Guruhood were sent screaming
into the maw of the Ruleset.  Temperatures rose, and the compunalysts eagerly
awaited the thunderous sound of mental boil.

BUT......

Their masterstroke was defeated.  Users developed tools to recover the
original concepts from the painstakingly derived conundrums of sendmail.
"Ease" became widespread, and there were calls for the heads of those
who had developed the Sendmail.  Most of the compunalysts fled into the
digital secrecy of public access sites and university guest logins. Those
who did not escape were hunted down and killed (ironically, most died from
massive paper tape cuts; a few were found with strange, rectangluar holes
punched in linear patterns on their extremities).

A few survived.  Realizing that their last experiment had almost exhausted
the users' mindspace, they knew that the answer was close at hand.  They
went under "deep cover", assuming innocent jobs in computing centers around
the world.  They release public domain code that is just obscure enough to
confuse the would-be user.  They write manuals that are more complicated than
the systems covered by their pages.  They man support lines, quoting obscure
bug references.  Their code depends on the value of NULL.  They have given
up their goal of global confusion; they now believe that, if even one user
can reach the Boiling Point, their mission will be fulfilled.

Don't give up to them!  As soon as you do, they will have you!  The first
time you write a declaration like "char (*(*(*(*(*x)[5])())[])())[3]", you
have joined their ranks!  Don't even write programs in any language but
BASIC; not BASIC-PLUS-2 with "A$ = SYS(CHR$(6%) + CHR$(7%))", but BASIC!
The only way to avoid possession is to intentionally retard the development
of your mind!  Don't use options; parse things yourself!  It's all in your
mind.....it's all in your mind.......it's all in your mind.

You owe the Oracle the TOPS-10 Monitor Calls Manual set.

--
[email protected]    |Wes Morgan, not speaking for|     ....!ukma!ukecc!morgan
[email protected]  |the University of Kentucky's|   morgan%engr.uky.edu@UKCC
[email protected] |Engineering Computing Center| [email protected]
       "I was going to rip your head off, but I'm past that now."
30-May-92 12:34:12-MDT,2324;000000000000
Mail-From: WANCHO created at 30-May-92 12:34:07
Date: Sat, 30 May 1992  12:34 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: New version of TMODEM

The original TMODEM program was written to perform "xmodem" and
line-at-a-time (blind) file transfers with the controlling terminal,
either directly connected or through a TAC port.  It also provided for
terminal-controlled transfers through locally connected dialout TTY
ports, just like a PC modem program.

Now, finally, after four years, the TMODEM program has been updated!
It now has the additional capability to connect via telnet to dialout
ports connected to terminal servers for terminal-controlled file
transfers.

TMODEM also has numerous cosmetic changes, including a reformat of the
source to standard DEC coding style, and a couple of functional
changes, such as a TELNET debug mode and the ability to change the
speed of a local TTY port while connected to it.

My thanks again to Mark Crispin for again allowing me to lift major
sections of his TELNET sources to adapt into the TMODEM program.

PD8:<MISC.TOPS-20>TMODEM.MAC.500 is available via anonymous ftp
from this host.  If you are actually using TMODEM, send me a message.

To be added to or removed from the INFO-TMODEM mailing list, send your
request to [email protected].

Note for users of TMODEM, the ZMODEM family, such as RZ/SZ, and KERMIT
through a terminal server dialin port: edit SYSTEM:HOSTS.TXT to
explicitly include a line declaring that terminal server to be a TAC
in the following format:

HOST : host-ip-address : FQDN-of-host : M68020 : TAC : TCP/TELNET :

This properly triggers the code in the above programs to negotiate
the required network binary mode for efficient file transfers.

For users of RZ and SZ on a TAC or terminal server, use the commands:

SZ -kw 4096 filespec   from the host to the PC
sz -kw4096 filespec    from the PC to the host

This causes the receiving program to send ACKs every 1024 bytes to
reduce the overrun problems with certain modems, such as the USR
Courier HST, which cannot turnaround fast enough.

--Frank
31-May-92 15:46:02-MDT,2712;000000000000
Mail-From: WANCHO created at 31-May-92 15:46:00
Return-Path: <[email protected]>
Received: from lysator.liu.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 31 May 92 15:43:38 MDT
Received: from robin.lysator.liu.se by lysator.liu.se  with SMTP
         (5.65c8/1.34/Lysator-3.1) id AA10744; Sun, 31 May 1992 23:43:13 +0200
         (rfc931-sender: [email protected])
Received: by robin.lysator.liu.se
         (5.65c8/1.34/Lysator-3.1) id AA13080; Sun, 31 May 1992 23:42:46 +0200
         (rfc931-sender: [email protected])
Date: Sun, 31 May 92 23:42:42 MET DST
From: Peter Eriksson <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Announcing: An Ident server for TOPS-20!
Message-Id: <[email protected]>
ReSent-Date: Sun, 31 May 92 15:46:00 MDT
ReSent-From: "Frank J. Wancho" <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

This message is to announce the availability of an implementation of the
Identification Server Protocol for DECsystem-20 mainframes running the
TOPS-20 operating system.

The source code, written in MACRO-10, is available for anonymous FTP
from "ftp.lysator.liu.se" in the directory "pub/ident/TOPS-20" as the
file "IDENTD.MAC". The author, Anders Andersson, can be reached at
the mailing address: "[email protected]".

Below follows a small introduction to what the Ident protocol is, which
you may skip if you are already familiar with it. Please redistribute this
message to any TOPS-20 users who may be interrested in it.

The Identification Server Protocol is based on the RFC931 protocol
(Authentication Server Protocol) and will soon (hopefully) be released
as a new RFC replacing RFC931.

The Identification Server Protocol implements a way for a host to announce
the owner of a TCP/IP connection to the foreign host. This can, for example,
be used for logging incoming connections.

For more information, please read RFC931 and/or send email to
the "[email protected]" mailing list that discusses
implementation and usage of this protocol. (There are a number of
changes compared to the RFC931 protocol). There is a mailing list
"[email protected]" that discusses the definition of the new
protocol.

/Peter Eriksson <[email protected]>



Peter Eriksson                                              [email protected]
Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                           I'm bored. Flame me.
14-Jun-92 19:09:03-MDT,876;000000000000
Return-Path: <[email protected]>
Received: from fernwood.mpk.ca.us by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 14 Jun 92 19:08:57 MDT
Received: by fernwood.mpk.ca.us; id AA21303; Sun, 14 Jun 92 18:10:59 -0700
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: California JFCL available.
Date: Sun, 14 Jun 92 18:10:55 MST
From: the terminal of Geoff Goodfellow <[email protected]>

California license plate JFCL is available due to an accident that resulted
in my car being declared a total loss by the insurance underwriter.  JFCL
was such useful instruction to use while hacking stuff with DDT and whereas
I haven't done any PDP10 hacking in years (in fact the last DEC20 I had an
account on was retired last year), I've decided to use the occasion to turn
JFCL in.

Geoff

16-Jun-92 08:42:22-MDT,695;000000000000
Return-Path: <[email protected]>
Received: from ginger.lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 16 Jun 92 08:42:18 MDT
Received: by ginger.lcs.mit.edu
       id AA28020; Tue, 16 Jun 92 10:41:14 -0400
Date: Tue, 16 Jun 92 10:41:14 -0400
From: [email protected] (Noel Chiappa)
Message-Id: <[email protected]>
To: [email protected], [email protected],
       [email protected]
Subject: Re:  California JFCL available.
Cc: [email protected]

       Speaking of PDP-10ish license plates, does HIC still have HLRZ?
When I figured out that this was the CAR instruction, I nearly fell down
I was laughing so hard.

       Noel
17-Jun-92 08:07:36-MDT,1993;000000000000
Return-Path: <[email protected]>
Received: from life.ai.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 17 Jun 92 08:05:52 MDT
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA11125; Wed, 17 Jun 92 10:01:37 EDT
From: [email protected] (Patrick Sobalvarro)
Received: by rice-chex (4.1/AI-4.10) id AA11056; Wed, 17 Jun 92 10:01:35 EDT
Date: Wed, 17 Jun 92 10:01:35 EDT
Message-Id: <9206171401.AA11056@rice-chex>
To: Noel Chiappa <[email protected]>
Cc: [email protected], [email protected],
       [email protected], [email protected]
In-Reply-To: "David A. Moon"'s message of Tue, 16 Jun 92 13:57:06 EDT <[email protected]>
Subject: [Noel Chiappa <[email protected]>: Re:  California JFCL
available.]

Well, I got HLRZ the car from Howard in 1984 or 1985, but he wanted
the plate (the physob, that is) back and I gave it to him.

He continued to refer to the car as HLRZ on the few occasions I've run
into him since then ("Wow, that must have been HLRZ I saw parked
outside.  That thing's still running?!").  HLRZ the car required some
mechanical work when I first got it, because of the long time it had
spent parked under a tree in Glenn's driveway, but then it pretty much
just ran like a clock for about eight years, across the country to
Palo Alto and back here, couple of trips to Pittsburgh, used in daily
commuting, and finally we sold it about two months ago to someone at
Cayman for $200.  It was beginning to require new parts regularly.

I think HLRZ the plate (logical) is probably available in
Massachusetts.  But you know, no matter what kind of new car you
attach it to, it'd just never be the same.  There are some things
PDP-10's and slant-six Dodges have in common: both were pretty neat
things; they're gone now; and we can sort of play around with a few
old ones but really the time for them is gone, too, and it isn't
coming back.

-P.
17-Jun-92 15:07:07-MDT,1609;000000000000
Mail-From: PANDA created at 17-Jun-92 15:05:24
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Wed, 17 Jun 92 15:05:27 MDT
Date: Wed, 17 Jun 92 12:58:52 PDT
From: Mark Crispin <[email protected]>
Subject: PDP-10's are still around...
To: [email protected], [email protected]
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

It's been asserted that modulo `a few old ones' that you can `play around with',
PDP-10's are gone.  Although there's some truth to this statement, it hasn't
gotten quite that bad yet.

CompuServe is very dependent upon PDP-10's.  I believe the entire system is
written in MACRO.  Their machines may be increasingly Systems Concepts instead
of DEC machines, but PDP-10's are PDP-10's no matter who makes them.

XKL Systems is working on a desktop PDP-10.  I don't know how far along they
are on this project (Len, care to comment??).

WSMR-SIMTEL20.ARMY.MIL is still very much alive and servicing FTP requests from
around the world.

I'm sending this message from Yuuyuu, KS10 serial number 4664.  Although the
main Panda.COM machine is now a NeXT (Ikkoku-Kan) Yuuyuu is still alive.  There
is a guest account if you want to browse -- (206) 842-0759, 2400 baud, user GUEST,
password FEIFEI.  Eventually, I hope to get Yuuyuu talking TCP (my sources have
been offline for a year so that project is stalled).

-- Mark (`you can hack anything you want with TECO and DDT') --
-------
18-Jun-92 07:43:56-MDT,1319;000000000000
Return-Path: <[email protected]>
Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 18 Jun 92 07:43:50 MDT
Received: by enet-gw.pa.dec.com; id AA03774; Thu, 18 Jun 92 06:43:45 -0700
Message-Id: <[email protected]>
Received: from narfvx.enet; by decwrl.enet; Thu, 18 Jun 92 06:43:46 PDT
Date: Thu, 18 Jun 92 06:43:46 PDT
From: History shows that the Red Sox always win the World Series in the year after a Russian revolution.  18-Jun-1992 0943 <[email protected]>
To: [email protected]
Apparently-To: [email protected]
Subject: RE: [Noel Chiappa <[email protected]>: Re:  California JFCL]



>I think HLRZ the plate (logical) is probably available in
>Massachusetts.  But you know, no matter what kind of new car you
>attach it to, it'd just never be the same.  There are some things
>PDP-10's and slant-six Dodges have in common: both were pretty neat
>things; they're gone now; and we can sort of play around with a few
>old ones but really the time for them is gone, too, and it isn't
>coming back.

NOT TRUE!!!! (AT least about the Slant-6).  You can STILL get it for certain
models of Dodge full size vans (and I think pickups!)

So that venerable engine is still alive and well...

John


18-Jun-92 21:26:12-MDT,1012;000000000000
Mail-From: PANDA created at 18-Jun-92 21:25:06
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Thu, 18 Jun 92 21:25:08 MDT
Date: Thu, 18 Jun 92 15:34:21 PDT
From: Mark Crispin <[email protected]>
Subject: PDP-10's still live at the University of Washington
To: [email protected], [email protected]
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

The Locke Computer Center retired its KL-1090 TOPS-10 system, but all was not
totally lost.  Thanks to some heroic efforts on the part of their resident
PDP-10 lovers, notably Bruce Edwards and Patricia Tressel, a KS system (serial
number 4364) is now happily churning TOPS-10 cycles to replace it.

Has anyone put together a list of what systems are still alive in the world?
I think, for example, that PDP-10's are now extinct at Stanford and CMU.  How
about MIT?
-------
19-Jun-92 07:20:39-MDT,1421;000000000000
Return-Path: <[email protected]>
Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 07:20:34 MDT
Received: by enet-gw.pa.dec.com; id AA14639; Fri, 19 Jun 92 06:20:27 -0700
Message-Id: <[email protected]>
Received: from narfvx.enet; by decwrl.enet; Fri, 19 Jun 92 06:20:29 PDT
Date: Fri, 19 Jun 92 06:20:29 PDT
From: History shows that the Red Sox always win the World Series in the year after a Russian revolution.  19-Jun-1992 0911 <[email protected]>
To: [email protected]
Apparently-To: [email protected]
Subject: At least TWO PDP-10s still alive at DEC Marlboro...


Even though the developers who worked on TOPS-10/TOPS-20 are gone to the four winds, at least two systems still flourish at Digital Marlboro:  GIDNEY, a
KL-2065, and KL1026, a KL1090.  Both are used for many things -- on-line
repositories for Monitor and utility sources being near the top.

I haven't been in Marlboro in a few years; I don't know if there's any
impending decommission date for either system.  At this moment, at least,
they still live.

Oh yes, GIDNEY is still an Internet system (since I get this list from
it instead of the usual Internet mail gateways around the corporation...)

I also believe that our Colorado Springs support center still runs at least
one KL for support purposes.

John Francini
19-Jun-92 07:37:46-MDT,1410;000000000000
Return-Path: <[email protected]>
Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 07:37:38 MDT
Received: by FENCHURCH.MIT.EDU
       id AA23173; Fri, 19 Jun 92 07:53:04 -0400
Reply-To: [email protected]
Date: Fri, 19 Jun 92 7:53:02 EDT
From: "Shawn F. Mckay" <[email protected]>
To: [email protected]
Cc: [email protected], [email protected],
       [email protected], [email protected]
Subject: Re: PDP-10's still live at the University of Washington
In-Reply-To: Your message of Thu, 18 Jun 92 15:34:21 PDT
Message-Id: <CMM.0.90.0.708954782.shawn@fenchurch>


MIT Deep thought (A Decsystem-20/65) is still "safe" here, though
efforts to revive it are still under way (Previously a very low
priority hobby project, its now getting some cycles).

In fact 3 out of 4 rp06 drives are spinning, and I suspect only
2 real problems remain:

               o Still cant find page 0 memory, even after Joe
                 Dempster and I swapped out all the memory boards.
               o Cant find the data on the RP06 drives (Starting to
                 look like a trivial datapath problem).

Anyway, I am about to formulate a real request to folks for wisdom,
but these are what I am crunching to get it "running". It could REALLY
use a RH20->SCSI controller though :-)

                       -- Shawn Mckay,
                       System Manager, MIT-Deep-Thought
19-Jun-92 14:10:42-MDT,7916;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 14:10:25 MDT
Date: Fri, 19 Jun 92 15:06:36 CDT
From: Clive Dawson <[email protected]>
Subject: Survey of DEC-10/20's still in use.
To: [email protected]
Message-ID: <[email protected]>

Folks,

Some months back I offered to compile a list of the DEC-10 and DEC-20
systems which are still in use.  Mark's recent message reminded me
that I had never posted the results.  What follows is the info I have
obtained to date.  It is obviously incomplete, so I am willing to
update and correct this list if people will send me data about
additional systems out there.

Thanks to all who responded.

Clive

===============================================================================
BBN
       System:         DEC-2065's (2, clustered)
       OS:             TOPS-20 Version 7(21733)
       Organization:   BBN Inc.
       Location:       Cambridge, MA 02138
       Use:            Business processing
       Hostname:       Wishes to remain anonymous
       Shutdown date:  At least one of the 20's will be here thru
                       the end of calendar 1993. There is talk about
                       an earlier shutdown of other system.
       Contact:        Jerry Weiner 617-873-3242 [email protected]
===============================================================================
BT TYMNET
       System:         DEC-1090
       OS:             TYMCOM-X P035/E01 (TOPS-10 variant)
       Organization:   BT North America, TYMNET Operations
       Location:       Fremont, California
       Use:            Business
       Contact:        Carl Baltrunas, 408/922-6206
       Hostname and shutdown date:     (MX only, these have no IP addresses)
                       F23.Tymnet.COM          -
                       F26.Tymnet.COM          Summer 1992
                       F30.Tymnet.COM          -
                       F33.Tymnet.COM          Fall 1992
                       F34.Tymnet.COM          -
                       F37.Tymnet.COM          1-Jul-91
                       F38.Tymnet.COM          -
                       F56.Tymnet.COM          30-Sep-91
                       F74.Tymnet.COM          -               (MAIL host)
       -----------------------------------------------------------------------
       System:         DEC-2020
       OS:             TYMCOM-X P035/E01 (TOPS-10 variant)
       Organization:   BT North America, TYMNET Operations
       Location:       San Jose, California
       Use:            Business
       Contact:        Joe Smith, 408/922-6220
       Hostname and shutdown date:     (MX only, these have no IP addresses)
                       X14.Tymnet.COM          -
                       X17.Tymnet.COM          -
===============================================================================
CISCO
       System:         DEC-2065
       OS:             TOPS-20  6.1 (Stanford)
       Organization:   cisco
       Location:       Menlo Park, CA
       Use:            BillW reads his mail, SUDS
       Hostname:       Mathom.cisco.com
       Shutdown date:  soon
       Contact:        [email protected]
       -----------------------------------------------------------------------
       System:         DEC-2065
       OS:             TOPS-20  6.1 (Stanford)
       Organization:   cisco
       Location:       Menlo Park, CA
       Use:            Part of cisco customer database
       Hostname        Heap.cisco.com
       Shutdown date:  Soon
       Contact:        [email protected]
===============================================================================
CUA
       System:         KL10B (model D)
       OS:             TOPS-10 v7.02 (Auto Patch 11)
       Organization:   Catholic University of America
       Location:       Washington, D.C.
       Use:            University administration
       Hostname:       CUA (1) [ANF10 only]
       Shutdown date:  12/92 (expected)
       Contact:        Edward C. Mulrean ([email protected])
===============================================================================
Mark Crispin
       System:         DEC-2020 (1 operational, 1 standby, 1 spare)
       OS:             TOPS-20  5.5
       Organization:   Mark Crispin
       Location:       Bainbridge Island, Washington
       Primary use:    Software development
       Hostname:       Yuuyuu.Panda.COM, Tonton.Panda.COM
       Shutdown date:  none
       Contact:        Mark Crispin  208-842-2385
===============================================================================
MCC
       System:         DEC-2065
       OS:             TOPS-20  5.4/6.0
       Organization:   Microelectronics and Computer Technology Corp.
       Location:       Austin, Texas
       Use:            Research
       Hostname:       MCC.COM
       Shutdown date:  July, 1992
       Contact:        Clive Dawson  [email protected] 512-338-3430
===============================================================================
OAK RIDGE
       System:         Five Processor DEC-10 (KL10-DA's)
       OS:             TOPS-10 V7.03
       Organization:   Computing & Telecommunications Division
       Location:       Oak Ridge, Tn
       Primary use:    IS
       Hostname:       No external hostname
       Shutdown Date:  1993
       Contact:        Wishes to remain anonymous
       -----------------------------------------------------------------------
       System:         Single Processor DEC-10 (KL10-EA)
       OS:             TOPS-10 V7.03
       Organization:   Business Systems
       Location:       Oak Ridge, TN
       Primary use:    MIS
       Hostname:       No external hostname
       Shutdown Date:  1993
       Contact:        Wishes to remain anonymous
       -----------------------------------------------------------------------
       System:         DEC-2060
       OS:             TOPS-20 V7.0
       Organization:   Computing & Telecommunications Division
       Location:       Oak Ridge, Tn
       Primary use:    MIS
       Hostname:       No external hostname
       Shutdown Date:  No specific time schedule but applications are
                       being converted to other platforms.
       Contact:        Wishes to remain anonymous
       -----------------------------------------------------------------------
       System:         DEC-2065 (not clustered, but have disks dual
                               ported with system below)
       OS:             TOPS-20 V6.1
       Organization:   Computing & Telecommunications Division
       Location:       Oak Ridge, Tn
       Primary use:    MIS
       Hostname:       No external hostname
       Shutdown Date:  July, 1993
       Contact:        Wishes to remain anonymous
       -----------------------------------------------------------------------
       System:         DEC-2065 (not clustered, but have disks dual
                                       ported with system above)
       OS:             TOPS-20 V6.1
       Organization:   Computing & Telecommunications Division
       Location:       Oak Ridge, Tn
       Primary use:    MIS
       Hostname:       No external hostname
       Shutdown Date:  July, 1993
       Contact:        Wishes to remain anonymous
       -----------------------------------------------------------------------
       System:         DEC-2065
       OS:             TOPS-20 V6.1
       Organization:   Procurement Division
       Location:       Oak Ridge, Tn
       Primary use:    MIS
       Hostname:       No External hostname
       Shutdown Date:  1993
       Contact:        Jeff Jones
===============================================================================
SRI
       System:         DEC-2065
       OS:             Tops-20 v7
       Org:            SRI
       Loc:            Menlo Park, CA
       Use:            Hacking
       Hostname:       nic.nisc.sri.com
       Shutdown date:  probably soon
       Contact:        Mark Lottor 415 859-2652
===============================================================================
TRW
       System:         DEC-2020
       OS:             TYMCOM-X P035/C01 (TOPS-10 variant)
       Organization:   TRW Network Services
       Location:       Anaheim, California
       Use:            Business
       Hostname:       S33
       Shutdown date:  Summer 1992
===============================================================================
US Army
       System:         DEC-2065 w/4MW + NIA-20 + 12 RP07s
       OS:             TOPS-20 7.0 with Panda mods
       Organization:   USAISC-White Sands
       Location:       WSMR, NM
       Use:            EMail services, mailing list redistribution, and
                       several very large repositories of software and docs.
       Hostname:       WSMR-SIMTEL20.ARMY.MIL
       Shutdown date:  None
       Contact:        Terri Jackson, 505-678-7462
       Tech. Support:  Frank J. Wancho, 505-678-9124
===============================================================================
UNIV. OF PITTSBURGH
       System:         DEC-1090
       OS:             TOPS-10
       Organization:   Computing and Information Services
       Location:       University of Pittsburgh
       Use             Education (Administrative use)
       Hostname:       none
       Shutdown date:  Spring/Summer, 1992
       Contact:        Richard Loether (412 624-6429, [email protected])
===============================================================================
WESLEYAN UNIVERSITY
       System:         DEC-2065
       OS:             TOPS-20 V. 5.4/6.0
       Organization:   Wesleyan University
       Location:       Middletown, CT
       Primary use:    University administration
       Hostname:       KLB.Wesleyan.Edu
       Shutdown date:  December 1993 (approx.)
       Contact:        Doug Bigelow  ([email protected])
===============================================================================
-------
19-Jun-92 20:01:20-MDT,3798;000000000000
Mail-From: PANDA created at 19-Jun-92 19:58:41
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Fri, 19 Jun 92 19:58:42 MDT
Return-Path: <@WSMR-SIMTEL20.ARMY.MIL:[email protected]>
Received: from WSMR-SIMTEL20.Army.MIL by YUUYUU.Panda.COM with Cafard; Fri, 19 Jun 92 08:31:04 PDT
Received: from transarc.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 07:23:42 MDT
Received: by transarc.com (5.54/3.15) id <AA01787> for [email protected]; Fri, 19 Jun 92 09:23:29 EDT
Received: via switchmail; Fri, 19 Jun 1992 09:23:26 -0400 (EDT)
Received: from kermit.transarc.com via qmail
         ID </afs/transarc.com/service/mailqs/q1/QF.0eERy7KSMUA8M0vGAq>;
         Fri, 19 Jun 92 09:22:16 -0400 (EDT)
Received: from kermit.transarc.com via qmail
         ID </afs/transarc.com/usr/pat/.Outgoing/QF.ceERxraSMUA8IAEI4b>;
         Fri, 19 Jun 1992 09:22:00 -0400 (EDT)
Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.kermit.transarc.com.rt.r3
         via MS.5.6.kermit.transarc.com.rt_r3;
         Fri, 19 Jun 1992 09:21:59 -0400 (EDT)
Message-Id: <[email protected]>
Date: Fri, 19 Jun 1992 09:21:59 -0400 (EDT)
From: [email protected]
To: Mark Crispin <[email protected]>
Subject: Re: PDP-10's still live at the University of Washington
In-Reply-To: <[email protected]>
References: <[email protected]>
ReSent-Date: Fri, 19 Jun 92 18:31:13 PDT
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: [email protected], [email protected]
ReSent-Message-ID: <[email protected]>

Mark Crispin <[email protected]> writes:
> I think, for example, that PDP-10's are now extinct at Stanford and CMU.  How
> about MIT?

You're right about CMU.  CMU-CS-A (a KL10-A running TOPS-10) went away
in 1987, I think.  CMU-CS-C (a 2060 or 2065 - I don't remember)
followed shortly thereafter, some time in 1988.  At around the same
time, the six 2060's at the Computation Center were being phased out;
by late 1988, all but one of them was gone.  The last remaining system
was used by the Administrative Systems department to run payroll and
stuff, and they continued to use it until some time in 1989, when all
admininstrative functions were moved off to a VMS VAXCluster; at that
time, the last TOPS-20 machine was shut down.  The machines themselves
may still be over at the CMU Computation Center for all I know.  I
believe CMU-CS-A (at least, those parts of it that haven't been picked
over by scavengers and souvenir hunters) is still over in the CS
department, sitting in the hallway outside the CS machine room; since
it was bought with ARPA money, they were not sure if they could sell
it off, or even scrap it.  So there it sits.

For a while, I had talked about getting a KS10 running; I was going to
buy the machine myself (assuming I could find one), and donate it to
the CMU Computer Club.  Someone in the Psychology department had
promised us machine room space, and we didn't think getting some kind
of Massbus disk and tape would be much of a problem.  Unfortunately,
just when it looked like I had a machine lined up, we found out that
the person who promised us the machine room space didn't actually have
the authority to do so, and the computing facilities manager in
Psychology expressed some amount of reluctance about putting the
machine in their machine room (I believe "over my dead body" was the
phrase she used...).  So we had to let the idea drop.  Sigh....

As for other places, there are persistent rumors that CWRU has one or
more KS10s sitting around somewhere, not being used for anything.
Beyond that, I can't think of any.

--Pat.
19-Jun-92 20:05:31-MDT,1041;000000000000
Mail-From: PANDA created at 19-Jun-92 20:02:44
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Fri, 19 Jun 92 20:02:45 MDT
Return-Path: <@WSMR-SIMTEL20.ARMY.MIL:[email protected]>
Received: from WSMR-SIMTEL20.Army.MIL by YUUYUU.Panda.COM with Cafard; Fri, 19 Jun 92 08:33:15 PDT
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 08:41:45 MDT
Date: Fri, 19 Jun 92 10:43 EDT
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: RE: PDP-10's still live at the University of Washington
To: [email protected]
X-VMS-To: IN%"[email protected]"
ReSent-Date: Fri, 19 Jun 92 18:31:54 PDT
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: [email protected], [email protected]
ReSent-Message-ID: <[email protected]>

Folks,

       We has BBN, still have two DECsystem 2065's in a cluster running. It
looks like they will be here atleast through the end of 1993.

Jerry Weiner
20-Jun-92 03:15:40-MDT,1673;000000000000
Mail-From: PANDA created at 20-Jun-92 03:15:03
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Sat, 20 Jun 92 03:15:03 MDT
Date: Fri, 19 Jun 92 18:55:33 PDT
From: Mark Crispin <[email protected]>
Subject: a true blast from the past!!
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>
ReSent-Date: Sat, 20 Jun 92 02:10:57 PDT
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

Well, my VT100 (with advanced video, katakana ROM, and VT125
upgrade) finally bit the dust.  Actually, it isn't truly dead;
it's just that it's lost its horizontal width setting so that the
image it draws on the screen is a good deal wider than the screen
itself (= it overscans).  Unfortunately, I could not find any
horizontal width pot although there are pots for vertical width.
I suspect the true problem is that some capacitor has reached the
end of its useful life.

Anyway, I decided to bite the bullet and finally get an RGB
monitor for this GIGI that has been collecting dust on my closet
floor.  I wasn't able to find one of the original BARCO monitors,
so I ended up giving it a CONRAC monitor that I found in a surplus
store.

It works, modulo a flakey DIP switch 8 that keeps me from setting
the default to 9600; it thinks it's up all the time, so I have to
choose between 19200 and 4800; and since the 2020 doesn't support
19200...

I wonder which is rarer today, a 2020 or a GIGI???
-------
-------
20-Jun-92 20:23:27-MDT,1049;000000000000
Return-Path: <[email protected]>
Received: from gidney.tops20.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 20 Jun 92 20:23:17 MDT
Date: 20 Jun 1992 2220-EDT
From: "Sam Weiner" <[email protected]>
To: [email protected]
Subject: Re: At least TWO PDP-10s still alive at DEC Marlboro...
Message-ID: <"MS11(6050)+GLXLIB6(0)" 12791079944.14.135.161879 at gidney.tops20.dec.com>
References: Message from History shows that the Red Sox always win the World Series in the year after a Russian revolution.  19-Jun-1992 0911 <[email protected]>
             of 20-Jun-92 0304-EDT
In-reply-to: <[email protected]>

As John said, GIDNEY and its pal KL1026 are still alive.  Last I heard,
they are supposed to remain with us for another year or so.

Colorado, last I heard, had a 2 system TOPS-20 cluster.  I'm not sure
about the TOPS-10 side but I assume they have at least one.  They should
be up through the end of 1993 in support of customers.

Sam Weiner
  --------
23-Jun-92 13:57:02-MDT,3749;000000000000
Mail-From: PANDA created at 23-Jun-92 13:53:13
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Tue, 23 Jun 92 13:53:15 MDT
Return-Path: <@WSMR-SIMTEL20.ARMY.MIL:[email protected]>
Received: from WSMR-SIMTEL20.Army.MIL by YUUYUU.Panda.COM with Cafard; Mon, 22 Jun 92 12:34:13 PDT
Received: from andrew.cmu.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 22 Jun 92 10:06:42 MDT
Received: by andrew.cmu.edu (5.54/3.15) id <AA07403> for [email protected]; Mon, 22 Jun 92 12:06:35 EDT
Received: via switchmail; Mon, 22 Jun 1992 12:06:34 -0400 (EDT)
Received: from proteus.mercury.acs.cmu.edu via qmail
         ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.YeFTctK00Vq080bEBe>;
         Mon, 22 Jun 1992 12:05:13 -0400 (EDT)
Received: from proteus.mercury.acs.cmu.edu via qmail
         ID </afs/andrew.cmu.edu/usr22/ef1c/.Outgoing/QF.geFTci600Vq0E2sXF6>;
         Mon, 22 Jun 1992 12:05:02 -0400 (EDT)
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.proteus.mercury.acs.cmu.edu.pmax.ul4
         via MS.5.6.proteus.mercury.acs.cmu.edu.pmax_ul4;
         Mon, 22 Jun 1992 12:05:02 -0400 (EDT)
Message-Id: <[email protected]>
Date: Mon, 22 Jun 1992 12:05:02 -0400 (EDT)
From: Esther Filderman <[email protected]>
To: [email protected]
Subject: Re: PDP-10's still live at the University of Washington
Cc: Mark Crispin <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
       <[email protected]>
ReSent-Date: Tue, 23 Jun 92 07:48:44 PDT
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: [email protected], [email protected]
ReSent-Message-ID: <[email protected]>

Excerpts from org.special-projects.tops20: 19-Jun-92 Re: PDP-10's still
live at .. [email protected] (2076)

> The last remaining system
> was used by the Administrative Systems department to run payroll and
> stuff, and they continued to use it until some time in 1989, when all
> admininstrative functions were moved off to a VMS VAXCluster; at that
> time, the last TOPS-20 machine was shut down.

Actually, the last of the Tops-20s (Tops-E) was running some educational
programs that were slow to port to either the Andrew system or VMS, and
the master billing program for all billable systems (both VMS, VM/CMS
and Tops-20).   If I remember correctly, Tops-A, the last of two A.S.
20s (the other being Tops-F) was decomissioned about 6 months  before
Tops-E.

> The machines themselves
> may still be over at the CMU Computation Center for all I know.

I was working for UCC Computer Operations from just before Tops-B was
retired (Tops-C had been retired about a year before) to well after the
demise of the last one (-sob- I'm not the only one who misses them
horridly).  Yes, there still are a few parts around the UCC.  I tried to
get my hands on some to give to the MIT Tops-20 folks but was told,
"Sorry, they're all promised to someone."  Sadly, I'm afraid it's a
metal-scrapper -- I heard we couldn't find anyone to take at least 2 out
of the 6 machines (anyone who would use them as computers, that is...).


-------------------------------------------------------------
 Esther C. Filderman      [email protected]
 System Mangler           Library Automation
 Mercury Project          Carnegie Mellon University

"Father, forgive them, for they know not what they do.  May the fools learn
not to be slaves."
                       AD0R - 15-AUG-1988 23:10:54
                       CMCCTB.CMU.EDU

      [Tops-B was shutdown for good at 16-AUG-1988 00:00]

26-Jun-92 20:42:27-MDT,3247;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 26 Jun 92 20:42:22 MDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.26 ) id AA01133; Fri, 26 Jun 92 19:42:12 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA04528; Fri, 26 Jun 92 19:42:08 PDT
Received: from Tomobiki-Cho.CAC.Washington. (Tomobiki-Cho.CAC.Washington.EDU) by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA04476; Fri, 26 Jun 92 16:52:52 PDT
Return-Path: <[email protected]>
Received: from alex.stacken.kth.se by Tomobiki-Cho.CAC.Washington.EDU
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 1.60.MRC ) id AA11901; Fri, 26 Jun 92 16:52:49 PDT
Received: from life.ai.mit.edu by alex.stacken.kth.se (5.61+IDA/KTH/LTH/6.0)
       id AAalex.stacken.kth.se14947; Sat, 27 Jun 92 01:48:51 +0200
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA16978; Fri, 26 Jun 92 19:48:30 EDT
From: [email protected] (Robert E. Seastrom)
Received: by rice-chex (4.1/AI-4.10) id AA25985; Fri, 26 Jun 92 19:48:27 EDT
Date: Fri, 26 Jun 92 19:48:27 EDT
Message-Id: <9206262348.AA25985@rice-chex>
To: [email protected], [email protected],
       [email protected]
Subject: [[email protected]: DEC-10/DEC-20 Service Retirement]
Resent-Date: Fri, 26 Jun 1992 19:42:03 -0700 (PDT)
Resent-From: Mark Crispin <[email protected]>
Resent-Sender: Mark Crispin <[email protected]>
Resent-To: TOPS-20 Hackers and Yackers <[email protected]>
Resent-Message-Id: <[email protected]>

Date: Fri, 26 Jun 1992 18:58 -0400
From: John McMahon - TGV Tech Support <[email protected]>
Subject: DEC-10/DEC-20 Service Retirement

Digital's Customer Update - 26 June 1992
========================================

o  DECsystem-10 and DECSYSTEM-20 Service Retiring

DECsystem-10 AND DECSYSTEM-20 SERVICE RETIRING

Digital ceased manufacturing DECsystem-10 and DECSYSTEM-20 systems in 1983
and announced the retirement of hardware and software support for these
systems to both Digital and non-Digital users.

Digital understands the importance of these systems in the user application
environment and wants to ensure that users have time to migrate to newer
technology without causing interruptions of their critical applications.

Services

After December 31, 1993, hardware support services can be performed on a
best effort (per call) basis only.  Best effort depends primarily on
existing shelf spares and secondary sources to replace defective material.
Digital cannot guarantee material availability once these spares sources are
depleted, because the industry is phasing out of the DECsystem-10 and
DECSYSTEM-20 chip technology.

Software product services will be discontinued for the TOPS-10 and TOPS-20
operating systems on December 31, 1993.  The last engineering updates for
the operating systems were released in 1990.  Telephone support for many of
the DECsystem-10 and DECSYSTEM-20 software layered products has already been
retired.


4-Jul-92 21:05:09-MDT,1224;000000000000
Mail-From: PANDA created at  4-Jul-92 21:04:12
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Sat, 4 Jul 92 21:04:14 MDT
Date: Sat, 4 Jul 92 20:02:13 PDT
From: Mark Crispin <[email protected]>
Subject: anniversaries coming up
To: [email protected], [email protected]
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

I was making copies of the 36-bit anniversary video tapes, and I realized that
we are coming to some significant dates in the not too distance future:
December 31, 1992: the end of DEC hardware support for PDP-10's
April, 1993: 10th anniversary of the assasination of PDP-10's
1994: 30th anniversary of PDP-10's

It may still be too early to plan for a 30th anniversary party, but perhaps
we should mark the 10th anniversary of the `integration strategy'.  After
all, the world has now recognized that VAX/VMS is the single standard
operating system for now and forever, right?  ;-)

We ought to have some recognition of the trusty old beasts which are still
executing PDP-10 instructions as well...
-------
6-Jul-92 03:55:53-MDT,984;000000000000
Return-Path: <[email protected]>
Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Jul 92 03:55:35 MDT
Received: by bsd.stupi.se (5.67/1.37)
       id AA03155; Mon, 6 Jul 92 11:57:58 +0200
Date: Mon, 6 Jul 92 11:57:58 MET DST
From: Peter Lothberg <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: anniversaries coming up
In-Reply-To: Your message of Sat, 4 Jul 92 20:02:13 PDT
Message-Id: <[email protected]>

> It may still be too early to plan for a 30th anniversary party, but perhaps
> we should mark the 10th anniversary of the `integration strategy'.  After
> all, the world has now recognized that VAX/VMS is the single standard
> operating system for now and forever, right?  ;-)

One arcitecture, one operating system, one copany, that's the DEC
strategy for the next 20 years...  (DEC salesman, DECUS Europe Cannes
1985)

-Peter

6-Jul-92 09:40:40-MDT,751;000000000000
Return-Path: <[email protected]>
Received: from brazil.cambridge.apple.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Jul 92 09:40:37 MDT
Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
       id AA16278; Mon, 6 Jul 92 11:43:50 -0400
       for [email protected]
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
       id AA28687; Mon, 6 Jul 92 11:26:25 -0400
Message-Id: <[email protected]>
Date: Mon, 06 Jul 92 11:39:12 EDT
From: [email protected] (David A. Moon)
To: Mark Crispin <[email protected]>
Subject: Re: anniversaries coming up
Cc: [email protected], [email protected]

Should have called it "Open-10".
9-Jul-92 08:26:59-MDT,3231;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 9 Jul 92 08:26:45 MDT
Date: Thu, 9 Jul 92 09:26:22 CDT
From: Clive Dawson <[email protected]>
Subject: Serious MMAILR Bug
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

Hi Mark--
 I would've never guessed there were any more serious MMAILR bugs
lurking, and I'm not even sure when you last worked on any of
this stuff, but for the record...:

PROBLEM:
   Over the years, I've sometimes seen mail which just times out
after n days in the queue without being delivered, even though
the destination host is up and receiving mail.  These occasional
incidents increased dramatically a couple of days ago when I had
about 80 messages in the queue which weren't moving.  It is also
possible that this bug could have caused mail to be delivered
using totally bogus MX relays, at best causing an extra hop,
and at worst causing failed delivery if the relay refuses to
cooperate.

DIAGNOSIS:
  There is code in MMAILR's MXNAME routine which loops down
the arg block returned by GTDOM% (via a call to $GTHST) checking
all the MX relays for a destination host.  This code assumes
that the list of byte pointers to relay names is ended by a
zero entry, when in fact it should be using the count returned
in GTDBLK+.GTDLN.  Since the arg block is not cleared before each
call, it is possible for MX relays from a previous call to still
be present on that list.

  Two days ago I added a second MX relay host to the domain entries
for all MCC hosts, in preparation for tomorrow's shutdown of
MCC.COM  (sob...but that's another story).  This means that MCC.COM
was now second on the list.  What happened was this:

  --   MXNAME is called during the process of canonicalizing
       the sending hostname,and the GTDOM arg block is filled
       with MX relay info which happens to include MCC.COM.
  --   MXNAME is called again to get relay info for the destination
       hostname.  If there is only one relay, the pointer to
       MCC.COM from the previous call is not wiped out, and MXNAME
       will find it on the list when it does the scan to see
       if "we are the relay", thus returning -1, and causing the
       message to be requeued indefinitely until it expires.

CURE:
       Teach MXNAME (and who knows what else) to use the count
       when it scans the relay list rather than stopping when it
       reaches a zero entry.

       Or, if you don't have time to do an elegant fix because
       your TOPS-20 system only has two more days of life
       after which you will regretfully never need this stuff again,
       then just clear the arg block before each call:

       In MXNAME, after

               SETZM GTDBLK+.GTDRD     ;So does this
       insert:
               MOVE A,[GTDBLK+.GTDRD,,GTDBLK+.GTDRD+1] ;Clear out arg block
               BLT A,GTDBLK+GTDLEN-1
               SETZM RLYBUF                            ;Clear out relay buffer
               MOVE A,[RLYBUF,,RLYBUF+1]
               BLT A,RLYBUF+RLYBFL-1

       Actually it would probably be best to make BOTH fixes, with
       the clearing of the arg blocks happening in the $DOGTD jacket
       routine.

Gee, Mark, can this really be the LAST time I'm ever gonna bug you about
MMAILR?!

Sigh,

Clive
-------
13-Jul-92 08:40:13-MDT,2144;000000000000
Return-Path: <[email protected]>
Received: from MCC-20.COM (mcc-20.mcc.com) by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 13 Jul 92 08:40:08 MDT
Date: Mon, 13 Jul 92 09:37:54 CDT
From: Clive Dawson <[email protected]>
Subject: Farewell message from MCC.COM
To: [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>

This is the last e-mail message sent from DECSYSTEM-20 #3536 under its
current identity of MCC-20.MCC.COM.  As has become traditional with
36-bit systems, a shutdown ceremony and party was held last Friday at
which time the name MCC.COM and the corresponding IP address were
reassigned to another system.

MCC.COM was one of the last DEC-20's produced and sold by DEC, more
than a year after the end of the product line was announced.  It
entered service on August 28, 1964, and has served us well over the
past 8 years.  I would have liked to keep it going longer.  At one
time I even thought (fantasized!) that it could be kept around until
the year 2000.  But the bean counters mounted increasingly effective
attacks, which ultimately could not be fended off.

Every time I've shut down a 36-bit system in the past, there was
always another one to move to.  But this time there isn't, and so a
computing way of life which started 23 years ago finally ends for me
today.  I'd like to share a great slogan that my friend Rich Cohen
coined for the occasion last Friday:

                              TOPS-20
                        A Great Improvement
                        Over Its Successors


In about 30 minutes, dismantling of the cabinets will begin.  The
system will be shipped to Atlanta, refurbished and sent to somewhere
in Canada where, according to my contact, it will compute till the end
of the century.  So perhaps the fantasy will be partially fulfilled at
least.

I won't say "so long", but I do owe a big "thanks for all the fish!"
to all the friends I had the pleasure of getting to know over the
years as a result of our shared adventure on these remarkable systems.

Clive
-------
14-Jul-92 01:29:35-MDT,1165;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Jul 92 01:29:31 MDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.26 ) id AA14985; Tue, 14 Jul 92 00:29:17 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA09925; Tue, 14 Jul 92 00:29:11 PDT
Date: Tue, 14 Jul 1992 00:21:47 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Farewell message from MCC.COM
To: Clive Dawson <[email protected]>
Cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Clive -

    If you feel that you need a DEC-20 fix, Yuuyuu is still in the land of
the living.  You can call it at (206) 842-0759 and log in as GUEST, password
FEIFEI.  This is a 2400 baud dialup, but I expect to have a 9600 baud dialup
in the not-too-distant future.

-- Mark --

15-Jul-92 16:14:09-MDT,1254;000000000000
Return-Path: <@UWAVM.U.WASHINGTON.EDU:[email protected]>
Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Jul 92 16:13:55 MDT
Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU
  (IBM VM SMTP V2R1) with TCP; Wed, 15 Jul 92 15:13:17 PDT
Date: Wed, 15 Jul 92 15:12 PDT
From: Pat Tressel <[email protected]>
Subject: another one bites the dust
To: [email protected]
Message-id: <[email protected]>
X-Envelope-to: [email protected]
X-VMS-To: IN%"[email protected]"

Our KL was taken out of service about a month ago.  It was purchased for $400
by Computer Clearinghouse, in a lot including a spare processor, memory, and
a number or RP07s.  They resold the (working) processor (only) to Compucom.
Last Friday, the processor was picked up to be shipped to Piketon, Ohio, but
we don't know to whom Compucom sold it.  Does anyone know of a company in
Piketon that would be likely to need a KL?  I'd feel a lot better if I knew
that it's gone to a good home.

                               Patricia Tressel
                               Locke Computer Center
                               University of Washington
                               Bitnet:   pat@uwalocke
                               Internet: [email protected]
17-Jul-92 11:26:35-MDT,1132;000000000000
Return-Path: <[email protected]>
Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 17 Jul 92 11:26:21 MDT
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31);
       id AA25529; Thu, 16 Jul 92 15:21:56 EDT for [email protected]
Date: Thu, 16 Jul 92 15:20:24 EDT
From: [email protected]
To: [email protected]
Message-Id: <[email protected]>
Subject: KL10

I'm tired of hearing about these!  If anyone else has a KL10 that they're
going to let go for a song (I just missed one in Boston, the owner was
asking $500 for the whole system), I'll give you two songs for it if it's
anywhere in my hemisphere.  Seriously!  (I drove from Albany, NY to
Houston, TX with a trailer to get my KS10)  I admit I can't practically
use one now but there's plenty of space in my storage locker and some
day (hopefully not too many decades off) I'll live in a house that I own
and will be able to put in a REAL power circuit, and then the FUN will
begin!  Boy will I feel dumb if I didn't get a KL10 back when everyone
was dumping them for a week's pay...

[email protected]
19-Jul-92 19:01:49-MDT,1379;000000000000
Return-Path: <[email protected]>
Received: from indyvax.iupui.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 19 Jul 92 19:01:45 MDT
Received: from INDYVAX.IUPUI.EDU by INDYVAX.IUPUI.EDU (PMDF #2673 ) id
<[email protected]>; Fri, 17 Jul 1992 20:32:03 -0500
Date: 17 Jul 1992 20:32:03 -0500
From: "Mark H. Wood" <[email protected]>
Subject: TCP/IP for DEC-1091
To: [email protected]
Message-id: <[email protected]>
Organization: Indiana University - Purdue University at Indianapolis
X-VMS-To: in%"[email protected]"
MIME-version: 1.0
Content-transfer-encoding: 7BIT

X-News: ivax comp.os.vms:8905
From: aurelio%[email protected] (Aurelio Ramalho)
Subject:TCP/IP for DEC-1091
Date: 14 Jul 92 13:02:26 GMT
Message-ID:<[email protected]>

Hello!!

       I want to know, if exists, any TCP/IP implementation for Digital's
DECSystem-1091 running TOPS-10 v7.01 and how I can get it???
       Who can help me?

Aurelio Ramalho
Systems Manager - UFPA.BR Domain
Federal University of Para - Belem - BRAZIL

--
Forwarded-By:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  [email protected]     BITNET:  IMHW400@INDYVAX
21-Jul-92 00:51:11-MDT,3793;000000000000
Return-Path: <[email protected]>
Received: from gatekeeper.oracle.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 Jul 92 00:51:06 MDT
Received:  from churchy.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7)
       id AA05311; Mon, 20 Jul 92 23:50:58 PDT
Received:  by churchy.us.oracle.com (5.59.11/37.7)
       id AA14203; Mon, 20 Jul 92 23:51:05 BST
Date: Mon, 20 Jul 1992 23:51:04 BST
From: Ken Harrenstien <[email protected]>
To: [email protected], [email protected]
Cc: [email protected]
Subject: One small step, one giant leap
Message-Id: <[email protected]>

On this anniversary of a truly historic moment, I would like to announce
a somewhat smaller event which may loom the larger for being closer to
our hearts.

       stealth.us.oracle.com% telnet nx.us.oracle.com
       Trying 139.185.5.134 ...
       Connected to mit-nx.us.oracle.com.
       Escape character is '^]'.
       Unknown ITS PDP-10

       NX ITS.1645. DDT.1545.
       TTY 11
       2. Lusers, Fair Share = 136%
       klh$u
       *peek^K!

       NX ITS 1645  Peek 629   7/20/92 23:02:48  Up time = 2:15
       Memory: Free=381   Runnable Total=83 Out=71    Users: High=6 Runnable=1
       Index Uname Jname Sname     Status   TTY    Core Out %Time    Time PIs
         0 SYS    SYS    SYS        HANG    ?        51   0   0%        4
         1 CORE   JOB    CORE       UUO     ?         0   0   0%
         2 KLH0   HACTRN SYS        TTYI    T0       30   9   1%
         3 11TLNT TELSER 202405     SLEEP   ?         1   0   0%
         4 KLH    HACTRN KLH        HANG    >        30   9   0%
         5  KLH    PEEK   KLH       +TTYBO  T11 C    83  71   7%
       Fair Share 135%     Totals:                  195       9%        7
       Logout time = 2       Lost 0%  Idle 98%  Null time = 2:14


       A
       NX ITS 1645  Peek 629   7/20/92 23:02:50  Up time = 2:17
       IMP is up.   TCP/IP is available.
       Ix Usr Uname  Jname  State   RWnd Ibf SWnd ReTxQ Lclprt Fgnprt Fgnhst
       34   3 11TLNT TELSER OPEN    5170  0 10000 0   0     27  10107 139.185.5.5
       4 buffers (4 free)

       STY Map
           Idx    STY owner   Idx    STY user    Host
       T11   3 11TLNT TELSER    5 KLH    PEEK    139.185.5.5 (TCP)

       Q
       :KILL
       *$$u
       NX ITS 1645  Console 11 Free. 23:03:13

       telnet> q
       Connection closed.
       stealth.us.oracle.com%


Yes, NX is a real, live, internet-host ITS assembled from the final
snapshot of AI.  So here's the punch line...

***There is no KS-10.***  NX is running on a "KLH-10" -- a virtual PDP-10.

Over the past two months I was finally able to put everything together
to create a complete PDP-10 emulator, including all necessary devices
(RP06, TM03, console, IMP); to distinguish it from a real DEC machine
I'm calling it a KLH-10 per Alan Bawden's suggestion.  The current
version is completely in C and should eventually be portable to most
platforms, but at the moment NX's host machine is a 33Mhz SUN Sparc-2
workstation sitting on my desk.

It's a long story with many more details and ramifications, all of which
I'll put off for later.  Although I wrote it entirely on my own, it would
never have happened without many people who I'd like to thank here:

       Stu Grossman, for convincing me with his KX-10 that a hardware
emulation in C was feasible.
       Alan Bawden & Dave Moon, who (apart from their already legendary
roles in ITS) helped as much as they could without actually being there.
       Jay Verkler (JLV), who with his group has re-created an AI lab
work environment within Oracle.  It's called the Network Products Division
and made this hack possible.
       Plus everyone else on these lists whose messages and actions
have helped keep the PDP-10 alive in spirit and reality a little
longer... may it now live as long as we wish!

--Ken
21-Jul-92 05:55:04-MDT,1240;000000000000
Return-Path: <[email protected]>
Received: from martigny.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 Jul 92 05:55:01 MDT
Received: by martigny.ai.mit.edu
       (16.7/15.6) id AA02528; Tue, 21 Jul 92 07:56:36 -0400
Date: Tue, 21 Jul 92 07:56:36 -0400
From: "Guillermo J. Rozas" <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
In-Reply-To: Ken Harrenstien's message of Mon, 20 Jul 1992 23:51:04 BST <[email protected]>
Subject: One small step, one giant leap
Reply-To: [email protected]

  Date: Mon, 20 Jul 1992 23:51:04 BST
  From: Ken Harrenstien <[email protected]>

  Over the past two months I was finally able to put everything together
  to create a complete PDP-10 emulator, including all necessary devices
  (RP06, TM03, console, IMP); to distinguish it from a real DEC machine
  I'm calling it a KLH-10 per Alan Bawden's suggestion.  The current
  version is completely in C and should eventually be portable to most
  platforms, but at the moment NX's host machine is a 33Mhz SUN Sparc-2
  workstation sitting on my desk.

So when/how can we ftp the goodies?


23-Jul-92 22:25:14-MDT,16381;000000000000
Return-Path: <[email protected]>
Received: from gatekeeper.oracle.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 23 Jul 92 22:25:01 MDT
Received:  from churchy.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7)
       id AA06859; Thu, 23 Jul 92 21:24:42 PDT
Received:  by churchy.us.oracle.com (5.59.11/37.7)
       id AA19272; Thu, 23 Jul 92 21:24:48 BST
Date: Thu, 23 Jul 1992 21:24:47 BST
From: Ken Harrenstien <[email protected]>
To: [email protected], [email protected]
Cc: [email protected]
Subject: KLH10 info
Message-Id: <[email protected]>

OK, here are some more details about the KLH10.  I've been a bit
overwhelmed by the many private responses and hope this answers most of
the questions.

First, the FAQs I've been getting:

   * "When/How can I get a copy?"
       Ouch, probably not until after Interop (Oct).  It kills me to say
       this, but my time *is* limited.  (The usual bribes might help :-)
       RMS has suggested distributing it via GNU/FSF, and I like that idea.

   * "Will it run <my favorite PDP-10 OS>?"
       Anything based on the KS10 should run with minor mods.
       The 166, KA and KI will require moderate I/O instruction changes.
       The KL10/20 (extended addressing, DTE20, etc) would require
       major surgery -- without anesthetic.

   * "How fast is it?"
       That depends mostly on the host platform.  Using a 33 MHz Sparc-2,
       very roughly 0.2 MIPS, perhaps 50% of a KA.
       More about this farther on.

   * "Why can't I connect to NX?"
       Oracle uses firewalls to prevent full Internet access to their
       internal networks.  We are trying to set up an ITS turist machine
       but it needs to be done very carefully.  Wait for an announcement.

   * "Thanks!"
       You're welcome!!

The rest of this message talks about various aspects at more length:
specifics of the target machine & devices, the emulator, and various
other thoughts.  It is a bit long for one message, but I figure it's
better to get it all out of the way.  My apologies to any uninterested
people.

Summary:
-------
       Target machine: KS10 with MIT ITS microcode
       Target config: 512K memory, RH11/RP06, RH11/TM03, FE console,
                       ACC LH/DH & IMP
       Current speed:  ~0.2 MIPS
       Current host: 33 MHz Sparcstation-2 with internal disk, SunOS 4.1.1
       Compiler: GCC 2.1
       Misc: Sources .5MB, runtime memory 4.3MB, disk lotsaMB

About the Target Machine:
------------------------

       The decisions I made while coding the emulator all boil down to
a simple desire to get something useful and interesting up as quickly
as possible.  Among other things this meant using an ITS-microcode
KS10 as the target machine, because:

       [1] I don't have official access to TOPS-20 binaries or sources,
       and didn't want to worry about licensing hassles.  Ditto TOPS-10.
       I also am lacking the voluminous documentation about installation
       and operating procedures.

       [2] The most recent ITS binaries and sources are all archived
       online (thanks to Alan), and all are for the KS10 version.  All
       documentation is likewise online, and in any case I have a
       somewhat more intimate understanding of ITS.

       [3] The KS10 has a simpler architecture than the KL10, which
       allows an emulator to run much faster.  If not for [2] I might
       have started with the KA10 for this reason.

It is important to realize that the KLH10 is emulating the ITS
microcode, which is slightly different from that for TOPS-10 or
TOPS-20.  The primary differences have to do with the pager and the
absence of the extended-instruction set (the noteworthy ITS features
such as one-proceed, JPC, and CIRC are of course supported).

In order to bring up TOPS-10 or TOPS-20, minor changes would be needed
to the pager code (somewhat more for TOPS-20, owing to its more complex
design).  The extended string instructions are ugly but straightforward
for anybody with a strong stomach (and weak mind?).

Everything else is fully supported, including the double-precision
floating point instructions.  I took pains to verify that all results
and PC flags are identical to the real hardware, even for wildly
unnormalized operands.  This was *not* one of the fun parts.

With respect to a KA or KI version, the I/O instructions would also
need to be modified and a number of things changed in the APR and PI
system, but not a great deal.  Bringing up TENEX should be relatively
easy given a complete description of the BBN pager.  WAITS, however,
would be up to a true SAILor.

I know many people are going to wish for a KL10 they can run a
full-grown TOPS-20 on.  Of course this is theoretically possible, but
it is not going to be easy to get something that runs at a useful speed
without a superfast host.  Remember the KL10 is an oversexed mutant
with these strange bulging growths oozing out of random body parts, all
of which have to be duplicated no matter how bizarre.  Just dealing
with extended addressing is going to slow down the basic instructions
as well as requiring much more pager overhead; this is one area where
the hardware parallelism is hard to beat.  The additional device cruft
(DTE20s, meters, address breaks, etc) doesn't help.  Personally I won't
try it without some concrete incentives.

P.S.  Just for grins I included the KA10 and PDP-6 arithmetic ops,
although I don't have a reference machine for verification (ha).  Who
knows, maybe a 340 will come along!  Spacewar, yeah!


I/O Devices:
-----------

       A great deal of the work consisted not of emulating the 10 but
rather emulating a basic set of peripherals.  The KS10's use of Unibus
devices made it somewhat more painful than the old I/O device scheme,
because instead of a small matrix of devices and I/O instruction
opcodes, there's a long list of bus addresses to check, each of which
has completely arbitrary meanings.  Not to mention the Unibus adapters
with their individual Unibus page maps, all of which are emulated as
well.

DSK: Currently one RH11/RP06 is supported as a virtual disk.  The
actual implementation uses a standard Unix disk file (not a raw disk)
to hold the "RP06" contents; this is so all blocks that haven't been
written will simply not exist (also known as a holey file), thus taking
up much less space than a full raw disk would.  Formatting the disk is
obviously unnecessary; sector headers are not written or read.  Errors
are pretty much limited to those caused by garbage written into the
registers, so the interface is a bit simpler than the real thing.  It's
possible that an OS which can't leave well enough alone will insist on
using some weird maintenance bits, in which case the device code will
need work.  Mods for multiple drives or other RH-controlled drive types
are trivial.

MTA: Similar considerations apply to the RH11/TM03 magtape interface.
From the "FE" (front-end controller interface) one can mount or unmount
"tapes" that consist of either binary tape images or virtual tapes
built on the fly from lists of unix files.  Hooking up a real magtape
drive would probably have been easier, but loading virtual dump tapes
into the filesystem is very fast, actually -- much faster than the real
devices would be.  In fact I found one race condition in the ITS
bootstrap loader that required slowing down disk I/O until I was able
to reassemble a fixed version.

NET: The network interface is an emulation of the ACC LH/DH that some
MIT machines used to have, as well as a virtual IMP.  Putting this one
together was a major project in network hacking, not to mention deceit.
Using Sun's NIT (Network Interface Tap) and various trickery, I was
able to set up NX with its own IP address, independent of its
platform's address and thus permitting me to run ITS without
interfering with the other network stuff I'm doing on my workstation.
For efficiency, the virtual IMP is actually a "Simple IMP" that doesn't
bother sending RFNMs, and the virtual LH/DH does I/O in PDP-10 byte
order (not Unibus order) -- this all required changes to the ITS IMP
driver.  For a while I considered munging the packets within the
virtual IMP to pretend that the local net was the ARPANET, but finally
decided it was better to fix ITS itself, and did so; ITS can now be
configured for non-ARPA subnets.  Geez, I never thought after I did ITS
TCP/IP that I'd be hacking the code again ten years later!

TTY: The FE console TTY "interface" is emulated, tho the 8080 FE
commands aren't -- no need.  There is also a dummy DZ11 driver that
merely reads and writes registers without doing anything.  This (and an
equally empty Chaosnet driver) was needed because that's what the last
AI ITS binary image was configured for, and I had to get that up before
I could reassemble a new system (oh the joys of bootstrapping).  The
DZ11 won't be hard to finish off, but I'm not sure it's worthwhile;
it's a horribly inefficient device and it's much faster to telnet in
over the network.  If realio trulio serial-line I/O is needed, I'd
recommend going for a DH11 if the OS supports it.  (It isn't as if
it still costs three times as much as a DZ :-)


About the emulator:
-----------------

       The KLH10 is written in C for a vanilla Unix OS, largely so it
can be readily ported to other platforms; in particular, those of the
future as well as those of today.  Although re-coding critical sections
in assembler would readily double or triple the basic instruction
speed, it is much easier to simply recompile it on a faster machine.
Although I use the GCC compiler for its efficiency, I don't use any
of its non-standard language constructs, again for portability.

The most fundamental design decision had to do with the method of
representing 36-bit words on a 32-bit architecture.  I wound up coding
around a halfword-based scheme, with each 18-bit PDP-10 halfword
right-justified in a 32-bit host word; thus each PDP-10 word uses 8
octets.  The same format is used for memory, ACs, and disk storage;
basically I traded off space for speed.

On a machine with a word size larger than 36, or a C compiler that
supported an equivalent integer type (such as double-word ints), many
things become easier, and I'd want to re-do a fair amount of the
arithmetic code.  Not because the current version won't work -- it will
-- but because it won't be as efficient.  I decided early on that the
differences between optimal code on a 32-bit and +36-bit machine were
just too great to easily combine with the primitive tools available in
C.

The arithmetic emulation relies only on well-defined native integer
operations; native floating point is never used, both because it is
non-portable (formats vary) and because it is very difficult to
precisely emulate the PDP-10's behavior without actually carrying out
the same internal operations "by hand".  This is by far the slowest
part of the KLH10.  I checked it out by compiling it on a real 20
(using KCC, of course!) and running it for hours under a test program
that generated various operand bit patterns and compared the results
with those for real instructions.

The current implementation is being used as a testbed for threads, and
includes code for both a non-threaded and threaded version.  (I
figured, what better test of software parallelism than to emulate
hardware parallelism?) This means that running on a true
multi-processor platform could produce somewhat better performance,
although the main APR execution thread is still serial and will impose
an upper bound on the speedup.  Let's not talk about pipelining just
now.

To clear up one thing that has caused confusion: the emulator is *not*
running standalone on my Sparc.  Except for the net device it uses the
usual Unix system calls and burns 100% of the CPU, running flat out.  I
don't really notice it since the amount of CPU I use most of the time
is typically a negligible fraction of the Sparc's capability; for
example, I'm writing this note in one window while ITS runs in the
other, and everything's cool.


The NEED for SPEED:
------------------

       In the summary I mentioned a speed of 0.2 MIPS, or about 5 usec
per instruction.  This is probably the number people are most avidly
interested in, but at the same time it's also one of the hardest to
measure.  PDP-10 speeds have always been tricky, mainly because it all
depends on the precise mix of instructions and operands.  Now it's even
fuzzier because so much of the KLH10 is variable.

Of course, the host platform speed is an overriding factor.  But I've
seen that even minor changes in the main loop can produce noticeable
differences in response time, as can the exact nature of memory
references.  For example, the SPARC is a register-window machine and
it's faster to pass arguments to functions than to set and read global
variables; it's also faster to use C structure members than globals!
Another machine could have precisely the opposite behavior.  I should
add here that the compiler is also tremendously important; using
GCC results in code that is 40% faster than Sun's CC!  Yow!

Anyway, I haven't really buckled down and tried to tune or measure its
performance, so take the 0.2 MIPS loosely.  My back-of-the-envelope
calculations before I started suggested that an assembler-coded SPARC
implementation could achieve a KA performance level; the current C
version appears to get perhaps half that speed.  Assembling the entire
ITS OS takes about 26 minutes of real time, but I don't know if anyone
remembers how long it took on a real KS10, much less a KA10.

The Sparc is already a slowpoke compared with some of the new
workstations and chipsets coming out, so it's just a matter of time
before someone cracks the KS10 speed limit on reasonably cheap
personal hardware.  I can't help but wonder if might be worth paying
serious attention to a high-speed version, one that would represent a
cost-effective solution for those places still committed to PDP-10
software.  Systems Concepts probably doesn't need to worry -- yet!


Future improvements:
-------------------

       The obvious one is speed.  Then more machine variants, more
devices.  More instrumentation & profiling.  A nicely packaged
distribution with your choice of OS and initial filesystem included.
The usual embellishments.  Whatever people suggest.

There's also the possibility of evolving a new virtual machine, one
which realizes more closely whatever the ideal PDP-10 is conceived to
be.  (That itself is an interesting question.) For example, the real
KS10 ITS microcode does not actually support JPC, which was a feature
of Holloway's MAC-10 pager; the KLH10 does it trivially and in that
sense is more than a simple KS10.  Its pager could support 2048K as
easily as 512K.  And so on, all of which implies reconfiguring a real OS
to run on an unreal machine.  The first step down this road has already
been taken with NX ITS, assembled to use a non-existent net interface.

And I've always thought it would be lovely to have a window displaying
a KA-style console panel with a full bank of lights and clickable
switches.  I know the KS10 never had one, but that doesn't mean it has
to stay that way, and besides, the KL10 cheated with a 11/40 panel, so
it's down to either the KA or KI.  Of course it's just for fun, what
else is this all about?


Final thoughts:
--------------

       I was going to close with the last paragraph, but realized
there's one more thing I want to say.  It's just that, um, well,
this will sound silly, but it feels so... weird? ... eerie?
.. just plain literally *mind-blowing* to watch this system boot up
and run happily, utterly unaware that it's not on a real machine, or
that anything odd happened since the last time it ran, or that its
earthly incarnation of a noisy roomful of huge cabinets and washing
machines is now entirely self-contained within a small innocuous pizza
box holding up my ITS manuals.  Do systems have wathans?  I've gotten a
bit more used to it, but every now and then I still sit back, realize
once again what the hell is going on, and hold on to something while
the chills pass.  I didn't expect this at all.  A side effect of being
imprinted at a tender young age, or something...

--Ken
24-Jul-92 18:26:49-MDT,2107;000000000000
Return-Path: <[email protected]>
Received: from MTS.RPI.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 24 Jul 92 18:26:45 MDT
Date: Fri, 24 Jul 92 20:26:26 EDT
From: [email protected]
To: [email protected],
   [email protected]
Message-ID: <[email protected]>
Subject: ?BT 001172

Hello,

I've been slugging away at getting my KS10 running (with a whole
lot of help recently from Peter Lothberg and Joe Dempster -- thanks guys!),
and at this point I think (hope?  wish?) that the problem is cornered
in the disk drive.  The machine passes BC, but when I try to boot I
get a

?BT 001172

which according to the doc's means a disk error while executing the
command list entry whose address ends in 172.  But, my machine has
CSL.V5.2, and I have listings for V4.2, so I don't know what corresponds.
If I do an EI command I get

000001,,776712/000000,,154700

I've forgotten whether this is a command reg or what, my RM03 manual
is around here somewhere but I can't seem to find it.  Maybe it's a
WC reg?  Anyway I usually can't change its value with DI commands.

Any idea what this points to?  What I'm looking for is, is this the
"usual error" for any particular disk error (record not found, 18-bit
jumper not in (I think it is), whatever).  When the drive is switched
off the error changes to "?BT 001062" so I think I'm partway there,
but the READY light doesn't flicker perceptibly so who knows.

FWIW, I'm mostly but not 100.00% sure that my Massbus cable is good,
I have scads of them in storage and I took the best-looking one,
but I think I had a couple which were F-S rejects that my old company
gave me, I don't know if it was from deinstalling drives or because
they had broken wires.

Thanks...  Sorry to bother you all with all this grunginess but I'm
getting REAL CLOSE and I'm about to have to put this thing back in
storage, I'd like to get the beasty to its knees first so I can dump
the AI snapshot onto the disk and free up some space on my Unix box.

 [email protected]   USERGZ7V@RPITSMTS
25-Jul-92 22:57:21-MDT,2392;000000000000
Return-Path: <[email protected]>
Received: from life.ai.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 25 Jul 92 22:57:16 MDT
Received: from august (august.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AB16819; Sun, 26 Jul 92 00:45:24 EDT
Received: by august (4.1/AI-4.10) id AA19430; Sun, 26 Jul 92 00:46:12 EDT
Date: Sun, 26 Jul 92 00:46:12 EDT
Message-Id: <9207260446.AA19430@august>
From: Alan Bawden <[email protected]>
Sender: [email protected]
To: [email protected]
Cc: [email protected], [email protected]
In-Reply-To: [email protected]'s message of Fri, 24 Jul 92 20:26:26 EDT <[email protected]>
Subject: ?BT 001172

  Date: Fri, 24 Jul 92 20:26:26 EDT
  From: [email protected]
  000001,,776712/000000,,154700

  I've forgotten whether this is a command reg or what, my RM03 manual
  is around here somewhere but I can't seem to find it.  Maybe it's a
  WC reg?  Anyway I usually can't change its value with DI commands.

This is the drive status register.  Here is its definition (from the ITS
sources):

DEFSYM  %HRSTS=:776712          ;DRIVE STATUS.
DEFSYM %HSATN==1_15.           ; Attention Active
DEFSYM %HSERR==1_14.           ; Error
DEFSYM %HSPIP==1_13.           ; Positioning In Progress
DEFSYM %HSMOL==1_12.           ; Medium On-Line
DEFSYM %HSWRL==1_11.           ; Write Locked
DEFSYM %HSLST==1_10.           ; Last Sector Transferred
DEFSYM %HSPGM==1_9.            ; Programmable
DEFSYM %HSDPR==1_8.            ; Drive Present
DEFSYM %HSRDY==1_7.            ; Drive Ready
DEFSYM %HSVV== 1_6.            ; Volume Valid

So the only unusual bit you see there is the "Error" bit, which means you
should look elsewhere to see what the error is.  Such as:

DEFSYM  %HRER1=:776714          ;ERROR 1.
DEFSYM %H1ECC==1_15.           ; Data Check
DEFSYM %H1UNS==1_14.           ; Unsafe
DEFSYM %H1OPI==1_13.           ; Operation Incomplete
DEFSYM %H1DTE==1_12.           ; Drive Timing Error
DEFSYM %H1WLK==1_11.           ; Write Lock Error
DEFSYM %H1IAE==1_10.           ; Invalid Address Error
DEFSYM %H1AOE==1_9.            ; Address Overflow Error
DEFSYM %H1CRC==1_8.            ; Header CRC Error
DEFSYM %H1HCE==1_7.            ; Header Compare Error
DEFSYM %H1ECH==1_6.            ; ECC Hard Error
DEFSYM %H1WCF==1_5.            ; Write Clock Fail
DEFSYM %H1FER==1_4.            ; Format Error
DEFSYM %H1PAR==1_3.            ; Parity Error
DEFSYM %H1RMR==1_2.            ; Register Modification Refused
DEFSYM %H1ILR==1_1.            ; Illegal Register
DEFSYM %H1ILF==1_0.            ; Illegal Function
28-Jul-92 19:21:37-MDT,1237;000000000000
Return-Path: <[email protected]>
Received: from MTS.RPI.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 28 Jul 92 19:21:26 MDT
Date: Tue, 28 Jul 92 21:21:16 EDT
From: [email protected]
To: [email protected],
   [email protected]
Message-ID: <[email protected]>
Subject: RM drives

Two RMXX-related questions:

1. Does anyone have a module utilization chart or a working RM-
  series drive who can tell me which position in the RM adapter
  backplane is right for the M7687 (which gets the "data" SMD cable)?
  My doc's aren't clear, I have no prints, the diagram painted on the
  backplane cover shows it about halfway between 8E and 8F (I've tried
  both -- have I smoked my drive?), and both of the RM drives I have
  came with this board having fallen out -- it's single-width but full
  height so the slightest bump makes it fall out.

2. I understand that a VAX RM80 needs to have a new low-level format
  written on it before it can be used in 18-bit mode.  Does anyone
  have a program (or know of a diagnostic) which can do this?
  SYSTEM; CONFIG > claims that MD had an RM80, so I believe this
  has been done before.

Thanks,    [email protected]
29-Jul-92 02:35:49-MDT,1188;000000000000
Return-Path: <[email protected]>
Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 29 Jul 92 02:35:40 MDT
Received: by bsd.stupi.se (5.67/1.37)
       id AA00811; Wed, 29 Jul 92 10:31:19 +0200
Date: Wed, 29 Jul 92 10:31:19 MET DST
From: Peter Lothberg <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: RM drives
In-Reply-To: Your message of Tue, 28 Jul 92 21:21:16 EDT
Message-Id: <[email protected]>

> Two RMXX-related questions:
>
> 1. Does anyone have a module utilization chart or a working RM-

Ill look on it when i get home tonight.

> 2. I understand that a VAX RM80 needs to have a new low-level format
>    written on it before it can be used in 18-bit mode.  Does anyone
>    have a program (or know of a diagnostic) which can do this?
>    SYSTEM; CONFIG > claims that MD had an RM80, so I believe this
>    has been done before.

If not already done, the ITS formater can be made to do it.

The DEC tool is DSRMB, but it only deals with rp06/rm03, I have a
patched version that does rm05/rp06, that could be patched again...

-Peter
21-Aug-92 11:40:58-MDT,3363;000000000000
Return-Path: <[email protected]>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 21 Aug 92 11:40:50 MDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
       (5.65/UW-NDC Revision: 2.27 ) id AA14007; Fri, 21 Aug 92 10:40:42 -0700
Date: Fri, 21 Aug 1992 10:40:30 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: [Bill Fisher: Our DECsyatem10 has gone
To: [email protected]
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Another one bites the dust...  ;-(

** Begin Forwarded Message(s) **

Received: from Tomobiki-Cho.CAC.Washington. (Tomobiki-Cho.CAC.Washington.EDU) by Ikkoku-Kan.Panda.COM
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA01425; Thu, 20 Aug 92 22:34:16 PDT
Return-Path: <[email protected]>
Received: from WATTLE.qut.edu.au by Tomobiki-Cho.CAC.Washington.EDU
       (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 1.60.MRC ) id AA08286; Thu, 20 Aug 92 22:34:02 PDT
Date: Fri, 21 Aug 92 14:38 +1000
From: Bill Fisher <[email protected]>
Subject: Our DECsyatem10 has gone
To: [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected],
       [email protected], [email protected], [email protected]
Message-Id: <[email protected]>
X-Envelope-To: [email protected]
X-Vms-To: @NOSTAE.DIS
X-Vms-Cc: FISHER

Well folks it has gone.

Our DEC-10 duly died last Monday with a farewell reminiscent ofthe death
of HAL.

A number of files are available through anonymous FTP from
oat.qut.edu.au in an area called pub/nostalgia.

The files are:

GREET.TXT contains the greetings received from various people around the
world in the last few weeks. (Some greetings from QUT students with
forged names have been deleted!)

DAWSON.TXT, FLEM.TXT and RNDTBL.TXT contain particularly interesting
longer items of mail received. The last contains the minutes of a round
table meeting of pioneers at 1984 Fall DECUS and well worth reading.

MAIL.TXT contains the rest of the mail received during our nostalgia
period.

QUEANS.TXT contains the questions we asked in our DEC10 test, our
answers, and statistics as to how people answered.

Once again thanks for your interest and goodbye.

Bill Fisher

22-Aug-92 10:00:16-MDT,429;000000000000
Mail-From: WANCHO created at 22-Aug-92 10:00:12
Date: Sat, 22 Aug 1992  10:00 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: QUT files

The QUT files are also available from WSMR-SIMTEL20.ARMY.MIL
[192.88.110.20] via ANONYMOUS FTP in PD3:<TOPS20.QUT>.

--Frank
24-Aug-92 15:14:28-MDT,1073;000000000000
Return-Path: <[email protected]>
Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 24 Aug 92 15:14:23 MDT
Received: by enet-gw.pa.dec.com; id AA17610; Mon, 24 Aug 92 14:14:17 -0700
Message-Id: <[email protected]>
Received: from tle.enet; by decwrl.enet; Mon, 24 Aug 92 14:14:18 PDT
Date: Mon, 24 Aug 92 14:14:18 PDT
From: Aron Insinga ZK2-1/Q18 1N24 dtn 381-1928  24-Aug-1992 1711 <[email protected]>
To: [email protected]
Cc: [email protected]
Apparently-To: [email protected]
Subject: MAXC PDP-10 clones

Was there an article published in IEEE Spectrum or IEEE Computer or elsewhere
(15 or so years ago?) about Xerox cloning the PDP-10? Was there one MAXC machine
built or two? (If two, were they different designs?) There was a console
computer, wasn't there?

                                       - Aron Insinga

Email:  [email protected]
Mail:   Digital Equipment Corporation, 110 Spit Brook Rd. (ZKO 2-1/Q18)
       Nashua, NH 03062-2698  USA
Phone:  (603) 881-1928
Fax:    (603) 881-0120
21-Sep-92 03:43:26-MDT,2554;000000000000
Mail-From: PANDA created at 21-Sep-92 03:42:19
Return-Path: <[email protected]>
Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Mon, 21 Sep 92 03:42:19 MDT
Date: Mon, 21 Sep 92 01:18:37 PDT
From: Mark Crispin <[email protected]>
Subject: 10 years ago...
To: [email protected]
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098
Phone: +1 (206) 842-2385
Message-ID: <[email protected]>

I happened to feel in a nostalgic mood, looking through some of
my old 36-bit memorabilia:

Remember 10 years ago, when we were getting fascinating tidbits
from our DEC salesman (not to mention our friends in the TOPS-20
monitor group) about the Jupiter (a.k.a. KC10, a.k.a.
DECsystem-2050)?  When we were wearing T-shirts saying:
       I don't care what people say 36 bits are here to stay.
       The reports of my death have been greatly exaggerated.
       If your computer doesn't have 36 bits you aren't playing
        with a full DEC.
       Nuke Tewksbury!

Remember thinking about the neat things to come, such as the new
stack instructions?  As I remember, it had a PUSHA instruction to
save AC's using a bitmask, and the right half of POPJ would have
a bitmask of AC's to restore.  Fully-supported G-floats,
quadruple precision integers [144 bit integers!  And I can't get
better than 32 bit integers in today's `modern' world of C], and
all 30 bits of address space, not just the piddly 23 bits the KL
gave us.

We were getting ready to go to our last optimistic DECUS.  I
forget now, but wasn't that at the Town & Country in San Diego,
or had Fall DECUS already moved to Anaheim by then?  We were
running TOPS-20 5.0; some of us were running 5.1.

At that time, our biggest worry was the TCP/IP transition
scheduled to happen on January 1, 1983.  DEC was promising us a
wonderful TCP: device and totally rewritten TCP code from the BBN
stuff.  Well, that didn't quite happen, although we ultimately
did get the TCP: device.  I remember spending most of the week
between xmas and New Years Day getting the mailer converted,
cursing the bizarre BBN TCP jsi the whole time.  Remember NCP
reclama?

Little did we know what was going to happen in April 1983, that
Ken Olson would become discouraged by the poor work on Project
Jupiter and cancel all future 36 bit CPUs.  On the other hand, as
we approach the 10th anniversary of that terrible Friday before
Spring DECUS...:

WE'RE STILL HERE!!!  Which is more than you can say for KO...  ;-)

-- Mark --
-------
23-Sep-92 12:42:28-MDT,1531;000000000000
Return-Path: <[email protected]>
Received: from mathom.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 23 Sep 92 12:42:23 MDT
Date: Wed 23 Sep 92 11:32:50-PDT
From: Jim Lewinson <[email protected]>
Subject: Another machine passes on
To: [email protected]
Message-ID: <[email protected]>

I seem to be writing quite a number of these. :-)

I am sorry to report the departure of Mathom.cisco.COM from the Internet,
at least for this lifetime.

Mathom had occupied several bodies during this lifetime, and lived in
several interesting places, including a garage in Atherton, California
while awaiting the preparation of a new home.  It has been with cisco
Systems, Inc.  since cisco's very early days.  It has been successfully
called upon to help folks to design boards for
ethertips/gateways/routers (with some help from its cousins and friends
at Stanford University), and less succesfully to perform such truly
amazing feats as levitate itself to the second floor without the use of
the (broken) freight elevator (it hadn't perfected its wisdom enough at
that time to do that task.)

Last week, it swapped DEC-2065 bodies with its longtime friend,
Heap.cisco.COM, so its most recent body serial number was 3539.  It has
already bequeathed its RP07 disk drives to Heap.  It is survived by
Heap, and a host of less long-lived MIPS and Sun boxes and a rather
long-lived HP friend named Clash.

Goodbye Mathom: we send you forth.

                                       Jim Lewinson
-------
24-Sep-92 15:22:14-MDT,5136;000000000000
Return-Path: <[email protected]>
Received: from gidney.tops20.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 24 Sep 92 15:22:04 MDT
Date: 24 Sep 1992 1712-EDT
From: "old KL10s don't die, they are stripped and crushed" <[email protected]>
To: goodbye-gidney: [email protected], brown@satire,
   wong@satire, mastrovito@vino, praetorious@star, muldoon@spezko,
   satoh_a@tktv20, harley@gotit, mdlyons@celtic, otoole@vino,
   braithwaite@cartun, jmccollum@vino, pratt@vino, flemming@vino,
   sscott@iota, gscott@o, waddington@nodex, [email protected],
   puchrik@mr4dec, sendlosky@vino;
Subject: Goodbye Gidney
Message-ID: <"MS11(6050)+GLXLIB6(0)" 12816189707.14.27.30911 at gidney.tops20.dec.com>

It is with a heavy heart that I announce that GIDNEY (KL10 2871, aka
TOPS20.DEC.COM, aka GIDNEY.TOPS20.DEC.COM, IP 16.34.0.2) is leaving the
Internet.  GIDNEY and KL1026 are the last two 36-bit machines in MRO1 (DEC
Marlboro), previously home to the Marlboro Computer Company.

GIDNEY and KL1026 (actually 1042 with MF20) are used for corporate support and
are being moved along with the remains of 36-bit manufacturing to NIO (Salem,
NH).  There are plans to bring up these two old systems in Salem at some point
but it is a "low priority" thing. It seems that the powers-at-be have precious
little room for engineering or manufacturing in Marlboro these days.

KL1026 was the TOPS-10 development system.  I used to use it often.  It was a
TRI-SMP system with KL1026, 1042, and 1322.  KL1026 was actually the second
KL10 system made, but many many parts were replaced in 1026 and 1042 by the
dedicated souls in Field Service to keep KL1026 running.  I used to use old
KL1025 (first KL10) in the CPS lab for debugging CI20 dignostics, and even with
the abuse it took, it always ran just great for me.

It was fun to see Joe (the 2nd shift operator) run four BACKUP jobs on KL1026
running the RP06s and RA81s all jumping, the TU72s all spinning, and that big
line of MH10s with flashing lights... until the MH10s (including "s/n proto"
and "s/n bread") were upgraded to Ampex ARM-10LS.  It had a bunch of RP06s
ported between the three system's RH20s, their three front ends, and even an
RH10.  It had a CR20 card reader, TU56 DECtapes on a DT10, and a TX02 with a
TU70, TU71, and 4 TU72s ported using a DX20 and a DX10.  It also had a CP10
card punch which mad a very impressive noise when in use (admittedly not all
that often). I was always referring people to the TU70 to read 7-track FAILSA
tapes ("rewinds are not automatic").

GIDNEY was part of the TOPS-20 development cluster.   GIDNEY replaced old
KL2102, one of the first two orange KL10s, the origional TOPS-20 development
system, which had horrible recurring hardware problems and finally was put to
rest in the mid 1980s.  GIDNEY's companion system was called CLOYD; everyone
knew that the names came from Gidney and Cloyd, the two little space creatures
from the space capsule in the "Rocky and Bullwinkle" TV show.

GIDNEY was joined in a CFS-20 cluster by CLOYD (KL2866), RONCO ("Now how much
would you pay?"), and THEP (named after The Prospector, a local watering hole
favored by the TOPS-20 developers).  At its peak GIDNEY had 12 RP06s, an AN20
(for GIDNEY), 3 DX20s, two TX02s, 4 TU73s (200 ips @ 6250), a TU72, 4 HSC50s
and lots and lots of RA81s.

About 5 years ago the old MRO1 "software lab" was shutdown.  At this time,
MRCHIP and MRDALE (our standalone cluster which was used for the famous CFS-20
demo at DECUS a number of years ago) was already scrapped.  CLOYD, RONCO, THEP,
1026, and 1322 were sent to that great machine room in the sky (actually to
MRO1-3 to be stripped and crushed).  I remember when the whole lab was 36 bit
systems; at this time there were mostly VAXen in there.

As I sit here on my VS4000-60, I am amazed that that little box over there has
3 (or more depends who you ask) times the speed of that old KL10, lots more
memory, and over 5 RP06s worth of storage.  A lot of people love the TOPS-20
(and TOPS-10) operating systems.  I do too, but I still love that old KL10
hardware.

I'd like to think that the 36-bit people have spread the goodness of TOPS-10
and TOPS-20 around Digital; I know a lot of these lucky souls are still around,
and every last one of them I talk to misses the old 36-bit software they used
to work on in MRO1.

Yes, I'd like to offer "belated goodbye" and farewell to CLOYD, RONCO, MRCHIP,
MRDALE, and THEP.  A "you deserved a rest" and farewell to 1026 and 1322.

GIDNEY will not go easily into the night.  In fact it crashed when I was
entering this message the first time.  Omens.  No, I didn't look at the dump.

GIDNEY, I hope I can get to you using TELNET or LAT in NIO (cause CTERM is
really not so hot).  It is not clear that NIO has IP, it being basically a
manufacturing facility.

GIDNEY, thanks for the good times and the good memories and for all of the
stuff I learned from you.

Greg Scott
previously TOPS-20 engineering, previously DEC Marlboro.
  --------
25-Sep-92 12:15:52-MDT,960;000000000000
Return-Path: <[email protected]>
Received: from mathom.xkl.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 25 Sep 92 12:15:48 MDT
Date: Fri 25 Sep 92 11:12:57-PDT
From: David K. Means <[email protected]>
Subject: Rumors of Death Greatly Exaggerated
To: [email protected]
Message-ID: <[email protected]>

 This note is quite tardy, but is elicited by recent notices to this
mailing list.  In July of 1991, a new (well, used) KL10 appeared on the
Internet: MATHOM.XKL.COM.
 This machine is supporting the engineering effort now of about 10 folks
who are busily engaged in designing a machine that will execute PDP-10
instructions.  As with any system of its age, the KL hardware is more or
less reliable, and the big troubles all stem from the RP07s that whir in the
night.
 Nonetheless, MATHOM is alive and well in Redmond, WA, and expects to
be so for the indefinite future.

                                               david means
-------
8-Oct-92 11:47:40-MDT,2756;000000000000
Mail-From: MRC created at  8-Oct-92 11:47:38
Return-Path: <[email protected]>
Received: from mc.lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 8 Oct 92 00:34:24 MDT
Received: from mc by mc.lcs.mit.edu id aa05843; 7 Oct 92 21:12 EDT
Received: from brazil.cambridge.apple.com by mc.lcs.mit.edu id aa05834;
         7 Oct 92 21:11 EDT
Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
       id AA00163; Wed, 7 Oct 92 21:14:25 -0400
       for [email protected]
Received: from dynamic-1.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
       id AA17970; Wed, 7 Oct 92 21:06:41 -0400
Message-Id: <[email protected]>
Date: Wed, 07 Oct 92 18:54:44 EDT
From: "David A. Moon" <[email protected]>
To: [email protected]
Subject: Nostalgia
ReSent-Date: Thu, 8 Oct 92 11:47:38 MDT
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>



                           The Final SALV


with sincere apologies to Archie Fisher for retargeting his song, and
thanks to The Tannahill Weavers and to Garnet Rogers for reminding me
what a great (and surely indestructible) song it is.


It's been three long years
Since we made it run,
 Heave away, my hackers oh!
And we can't get by
On that silly Sun.
 Sing haul 't away, my hackers oh!

So now you boot it up
For the final SALV
 Heave away, my hackers oh!
It's an easy run
For the disk is small.
 Sing haul 't away, my hackers oh!

And then you take your disk, lad,
And spin it down,
 Heave away, my hackers oh!
And I'll flip the switch, lad,
And shut 'er down.
 Sing haul 't away, my hackers oh!

And then we'll join old AI
And ML of yore,
 Heave away, my hackers oh!
Sitting cold and silent
On the false floor.
 Sing haul 't away, my hackers oh!

For I'd rather dump her
In the cans out back
 Heave away, my hackers oh!
Than to see her run
That Unix hack.
 Sing haul 't away, my hackers oh!

Then when I die
You can log me in
 Heave away, my hackers oh!
To that DDT
Where the altmodes spin.
 Sing haul 't away, my hackers oh!

And then I'll make the haven
Of Fiddlers' Green,
 Heave away, my hackers oh!
Where the hardware works
And the code is clean.
 Sing haul 't away, my hackers oh!

For I've hacked a lifetime,
Both man and boy
 Heave away, my hackers oh!
And it's just no fun
On that Unix toy.
 Sing haul 't away, my hackers oh!

And it's been three long years
Since we made it run,
 Heave away, my hackers oh!
And we can't get by
On that silly Sun.
 Sing haul 't away, my hackers oh!
8-Oct-92 13:59:48-MDT,1645;000000000000
Return-Path: <[email protected]>
Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 8 Oct 92 13:59:45 MDT
Received: by FENCHURCH.MIT.EDU
       id AA02482; Thu, 8 Oct 92 15:59:57 -0400
Reply-To: [email protected]
Date: Thu, 8 Oct 92 15:59:55 EDT
From: "Shawn F. Mckay" <[email protected]>
To: [email protected]
Subject: DT.MIT.EDU
Cc: [email protected]
Message-Id: <CMM.0.90.0.718574395.shawn@fenchurch>


Howdy. We are still playing with Deep-Thought (Our 20/65 :-)),
and trying to find a way to bring it up (without an RP06, though
we do have two of them to play with doing this). But we are having
some strange memory trouble that we are kindof running out of things
to try with, so I wonder if I might ask a question?

When the system is running KLI, it prints something like this:

.. Normal KLI ...

STARTING MF20 DBE SCAN. WAIT 25 SEC/256K.
KLI -- % PHYSICAL MEMORY CONFIGURATION ALTERED - DUMP OR RESTART SUPPRESSED

LOGICAL MEMORY CONFIGURATION
 ADDRESS SIZE INT TYPE CONTROLLER

KLI - ? NO MEMORY AT LOCATION ZERO
KLI - ENTER DIALOG ....


We have swapped the MG20 we have for new boards, controller and all,
also we swapped stuff in the cpu with no luck. What I am wondering
is two fold:
       A) What ACTULLY causes this message, i.e. what ACTUAL test is failing?
       B) What are a list of things that might 'cause' this? (Perhaps we
          have missed something simple?


Also, we the system does come back up, we wonder about TCP/IP, does anyone
have a monitor that can use an interlan board + TCP/IP?

                               Many Thanks,
                                 - Shawn

13-Oct-92 14:10:25-MDT,625;000000000000
Return-Path: <[email protected]>
Received: from Shiva.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 13 Oct 92 14:10:04 MDT
Received: by Shiva.COM (1.34b) Tue, 13 Oct 92 16:09:41 EDT
Date: Tue, 13 Oct 92 16:09:41 EDT
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: TOPS-20 DECnet "NRT" server
Cc: [email protected]

Can anyone tell me what the "status message" sequence of bytes a
TOPS-10 or TOPS-20 system sends when you connect to it's NRT
(pre-CTERM NVT protocol) server object (object 23)?

Thanks!
-Phil

(missing 4 bits more than ever)
14-Oct-92 03:13:30-MDT,1089;000000000000
Return-Path: <[email protected]>
Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 14 Oct 92 03:13:24 MDT
Received: by bsd.stupi.se (5.67/1.37)
       id AA02569; Wed, 14 Oct 92 10:13:33 +0100
Date: Wed, 14 Oct 92 10:13:33 MET
From: Peter Lothberg <[email protected]>
To: Phil Budne <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: TOPS-20 DECnet "NRT" server
In-Reply-To: Your message of Tue, 13 Oct 92 16:09:41 EDT
Message-Id: <[email protected]>

> Can anyone tell me what the "status message" sequence of bytes a
> TOPS-10 or TOPS-20 system sends when you connect to it's NRT
> (pre-CTERM NVT protocol) server object (object 23)?
>
> Thanks!
> -Phil
>
> (missing 4 bits more than ever)
>


;The configuration message sent out when we accept a connect

CFGLEN==10                      ;BYTES IN CONFIG MESSAGE
CFGMSG: BYTE(8) 1,1,0,0,11,0,10,0
;       Config--' ^ ^ ^  ^ ^  ^ ^
;                 ? ? ?  | ?  | ?
;       System=TOPS10----'    |
;       Protocol=TOPS20-------'

-Peter
19-Oct-92 22:01:41-MDT,1768;000000000000
Mail-From: WANCHO created at 19-Oct-92 22:01:24
Date: Mon, 19 Oct 1992  22:01 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: Is Windows NT TOPS20 with a GUI?

Of course not.  But, on p. 170 of the October BYTE, in the article,
"Windows NT Up Close," it says, in part:

"NT aslo provides a feature that's in some versions of Unix, but not
in OS/2: memory-mapped files.  To use a memory-mapped file, you create
a file-mapping object, which refers to a disk file, and creates a
memory-mapped view of the file.  Why bother?  The view permits random
memory-oriented access to the file's data--a major programming
convenience.  More important, memory-mapped files are NT's primary
mechanism for sharing memory among processes.

"Windows 3.x programs, running in a common address space, share memory
by default.  NT's more robust architecture, which isolates processes
from one another, requires an explicit means of sharing.
Memory-mapped files offer an interesting solution to the problem.  One
advantage over OS/2's shared-memory mechanism is that shared storage
automatically persists in the form of the disk file that backs the
mapped view.  [...]

"Both the NT loader and the cache manager that supports all the NT
file systems are heavy users of the memory-mapped service."


Hmmm.  When and which versions of Unix support memory-mapped files?
Are they really mapped or simply read into memory as a huge string?
Are they like page-mapped files?  If not, why not?  Seems a step in
the "right" direction...  eventually reinventing a real operating
system...  in C...

--Frank
20-Oct-92 07:22:17-MDT,3936;000000000000
Return-Path: <[email protected]>
Received: from amway.ch.apollo.hp.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Oct 92 07:21:54 MDT
Received: from mapcar.ch.apollo.hp.com by amway.ch.apollo.hp.com id <[email protected]> Tue, 20 Oct 92 09:09:46 EDT
Received: by mapcar.ch.apollo.hp.com id <[email protected]>; Tue, 20 Oct 92 09:09:42 EDT
From: [email protected] (Nathaniel Mishkin)
Date: Tue, 20 Oct 92 09:09:41 EDT
Subject: Re: Is Windows NT TOPS20 with a GUI?
To: "Frank J. Wancho" <[email protected]>
Cc: [email protected]
In-Reply-To: "Frank J. Wancho" <[email protected]>, Mon, 19 Oct 1992  22:01 MDT

   Hmmm.  When and which versions of Unix support memory-mapped files?
   Are they really mapped or simply read into memory as a huge string?
   Are they like page-mapped files?  If not, why not?  Seems a step in
   the "right" direction...  eventually reinventing a real operating
   system...  in C...

4.3bsd added the mmap() system call that may not have been universally
implemented (but was on SunOS and Apollo DOMAIN) to map files into memory.
At SunOS 4.0, I believe Sun modified the kernel to implement the stream
I/O primitives--read(), write(), etc.--on disk file systems by using
underlying VM mapping primitives.

The Apollo DOMAIN kernel never supported stream I/O primitives,
implementing them all instead in user-mode shared libraries which use
underlying kernel mapping primitives (and page faults, of course).  The
DOMAIN kernel also doesn't know about pathnames and doesn't implement
an open()-like system call nor does it have the concept of "open file
descriptor".  Pathnames are resolved in user-mode shared libraries into
64-bit unique ID (UIDs), which the "map" system call understands.  (DOMAIN
also doesn't have swap space--just application VA space mapped to temporary
files in the regular file system--and diskless nodes are just nodes where
every process's VA space is full of mappings to files that are remote
and the only trick is getting the node booted 'cause everything else
is just page fault processing, and...Whack!  Sorry.  I got out of control
there.)

There is a school of thinking--and one with which I'm at least slightly
sympathetic--that says the "stream I/O over VM mapping" technique is
a cute trick but probably not such a good idea.  (I think Butler Lampson
has expressed some pretty strong views in this area.) In DOMAIN anyway,
we had to go through some fair amount of effort to make sure that the
kernel did the right thing in terms of read-ahead and (write) flush-behind
so that I/O runs sufficiently fast and the system's physical memory doesn't
get filled up with stuff you'll never want again.  I mean, you have some
program that makes a nice clear statement--"read the next 4K bytes from
this open file"--and on the way down to the kernel, the intent is lost
and all the kernel sees is a page fault on mapped memory onto something
and depending on whether the memory contains program code, program data,
or a file being read sequential, it might want to do different things
with.

I guess we should be glad that--at least yet--no one has claimed that
NT *invented* these idea.  (Cutler isn't that dumb anyway.)  But that's
coming soon, I'm sure.  But hey, why should I complain?  The last two
OS's I did systems hacking on were TOPS-20 and DOMAIN.  UNIX?  OK, I
guess I used that too.  It appears that, like TOPS-20 and DOMAIN, NT
was designed.  That's "designed, full stop".  As opposed to UNIX (at
least everything since v6).  Are we TOPS-20 irredentists supposed to
be happy or sad at the prospect of NT overwhelming UNIX?

                   -- Nat Mishkin
                      Distributed Computing Program
                      Hewlett-Packard Company
                      [email protected]
-------
20-Oct-92 09:23:47-MDT,1052;000000000000
Return-Path: <[email protected]>
Received: from Tomobiki-Cho.CAC.Washington.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Oct 92 09:23:31 MDT
Return-Path: <[email protected]>
Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU
       (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04054; Tue, 20 Oct 92 08:22:56 -0700
Date: Tue, 20 Oct 1992 08:21:55 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Is Windows NT TOPS20 with a GUI?
To: "Frank J. Wancho" <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

SunOS has memory mapping, as does Mach.  It isn't as general or as useful as
TOPS-20 memory mapping.  A big disappointment with Mach on the NeXT is that
shared writeable memory is disabled.

20-Oct-92 09:25:04-MDT,5554;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Oct 92 09:24:50 MDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
       id AA15006; Tue, 20 Oct 92 08:24:45 PDT
Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
       id AA18667; Tue, 20 Oct 92 08:24:46 PDT
Received: by opus.Eng.Sun.COM (4.1/SMI-4.1)
       id AA10424; Tue, 20 Oct 92 08:19:23 PDT
Date: Tue, 20 Oct 92 08:19:23 PDT
From: [email protected] (Rob Gingell)
Message-Id: <[email protected]>
To: [email protected]
Subject: Re:  Is Windows NT TOPS20 with a GUI?
Cc: [email protected]

>Hmmm.  When and which versions of Unix support memory-mapped files?
>Are they really mapped or simply read into memory as a huge string?
>Are they like page-mapped files?

SunOS 4.0 (and all that follow, of course) supports memory mapped files
a la TENEX/TOPS-20.  The paper that described the system (Summer '87
USENIX) attempts to make clear that the inspiration for how it played
out was TENEX/TOPS-20.  It's not exactly the same in all respects, but
in the fundamental aspects of integrating the file/process address
spaces it's nearly indistinguishable: even down to the use of "window"
pages inside the kernel for the implementation of read() and write().

Since the SVR4 VM system is simply the SunOS one, the use of this model
is pretty much pervasive in the UNIX world.  There are probably upwards of
1 million machines running it at this point.  Not bad for ideas from a
"dead" OS, huh?

SunOS was hardly the first UNIX implementation to do offer such a facility.
But it and its SVR4 decendents seem to have displaced what alternatives
that exist such that (even if the internals are different) everyone implements
mmap() with much the same semantics as SunOS first did.

The basic interfaces to the system (mmap() ~ == PMAP%) were specified for
BSD UNIX in the late 70's/early 80's.  The specific influence even at that
time was TENEX/TOPS-20, as the demands for such services came from the
DARPA community who were looking for UNIX on VAXen as a way to get more
research out of a larger community, many of whom could not afford PDP-10's.
Although Berkeley never got around to implementing the interface (until
the soon to be released 4.4), the basic framework was laid for a very
similar system.  However, the precise semantics were ill-defined, a number
of operational characteristics hadn't yet been thought through, etc.

When we began to implement the SunOS VM system in 1986, we refined the
interfaces slightly and extended them to deal with things learned over
the years.  One of these was the creation of the msync() interface, for
which the specific influence was the experience with CFS-20 that created
a "higher-level" protocol for managing access to pages of directories to
avoid network thrashing of pages.  Other differences and extensions came
from the fact that we were trying to make this effective in a world where
there were networks of machines, not all of which would support the exact
same semantics, or even a common page size.

However, with respect to the single-system integration of the file system
and process address space, the system looks more like TOPS-20 than anything
remotely like "traditional UNIX."  And, it's hardly an "add-on", the system
was rewritten at most fundamental levels around the notions implied by
the TENEX/TOPS-20 memory model.  I think this is mostly why the SunOS
model has been successful, previous attempts to implement mmap() tried
to build upon primitives like read()/write() or otherwise represent an
add-on to the system.  Thus, their behaviors were quirky and incomplete.
By being willing to throw away what we had to gain uniform behaviors, we
gained implementation efficiency and elegance, as well as a "no surprise"
kind of interface.  Users of PMAP% should feel quite at home with it.

Are we reinventing TOPS-20 out of SunOS?  No, not hardly.  There are some
ideas that didn't work well in TENEX/TOPS-10/20 that are not, in my opinion,
worth stealing.  There are good ideas that might be worth stealing if there
was a suitable context within which to steal them -- but some design
decisions have been preempted by the UNIX history that's been inherited
and others just don't seem to fit as solutions to the views of customer
problems we have today.  For example, at one time I would have advocated
a COMND%-like facility -- the trouble is, most of our customers don't
need or even want a better terminal interface.  If only someone could
figure out the COMND% paradigm for GUI's...by which I mean that the
qualities of the design (uniformity with respect to completion, abbreviation,
error recovery, and the like) could be manifested with the grace that
COMND% and its predecessors provided for the terminal interface.

Perhaps a more important idea I'd like to see carry forward is the single
mechanism for naming provided by GTJFN%.  I think we'll ultimately see
that reborn in environments of the future, but it'll be manifested in
some form of network-aware naming facility that works as part of a general
"object-oriented*" environment for programs and as such will require the
corresponding paradigm shift for the bulk of programs to take advantage
of it.  Thus, we won't see it happen "soon."

Ah, what a pleasant way to reminisce early in the morning.  Thanks for
providing the opportunity Frank.
21-Oct-92 16:28:41-MDT,727;000000000000
Return-Path: <[email protected]>
Received: from inet-gw-1.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 21 Oct 92 16:26:38 MDT
Received: by inet-gw-1.pa.dec.com; id AA26887; Wed, 21 Oct 92 15:24:00 -0700
Received: by zowie.zso.dec.com (5.57/fma-100391);id AA19060; Wed, 21 Oct 92 15:23:49 -0700
Date: Wed, 21 Oct 92 15:23:48 PDT
From: Hans Ridder <[email protected]>
To: [email protected]
Subject: Re: Subscribe
Message-Id: <[email protected]>

I realized (probably a bit to late) that I made the classical blunder
of sending a subscription request to the list.  I might have caught it
in time, but probably not.  Sorry for the noise (and this noise too.)

-hans
12-Nov-92 19:23:30-MST,7147;000000000000
Return-Path: <[email protected]>
Received: from turtle.mcc.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 12 Nov 92 19:23:11 MST
Received: from stone.mcc.com by turtle.mcc.com (4.1/isd-master_920825_x)
       id AA03931; Thu, 12 Nov 92 20:22:52 CST
Received: by stone.mcc.com (5.65/isd-other_920825_17:05)
       id AA06015; Thu, 12 Nov 1992 20:22:38 -0600
Date: Thu, 12 Nov 92 20:22:36 CST
From: Clive Dawson <[email protected]>
To: [email protected]
Subject: The History of Unix - A Sordid Life Story
Message-Id: <[email protected]>

FYAmusement...I didn't realize what Unix had been through.  Perhaps I
should be more tolerant and understanding.

Enjoy,

Clive

(I was sent this, author is unknown)

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

The history of Unix: A sordid life story...

Unix was a program gone bad.  Born into poverty, its parents, the
phone company, couldn't afford more than a roll of teletype paper a
year, so Unix never had decent documentation and its source files had
to go without any comments whatsoever.  Year after year, Papa Bell
would humiliate itself asking for rate increases so that it could feed
its child.  Still, Unix had to go to school with only two and three
letter command names because the phone company just couldn't afford
any better.  At school, the other operating systems with real command
names, and even command completion, would taunt poor little Unix for
not having any job or terminal management facilities or for having to
use its file system for interprocess communication and locking.

Then, bitter and emasculated by its poverty, the phone company began
to drink.  During lost weekends of drunken excess, it would brutally
beat poor little Unix about the face and neck.  Eventually, Unix ran
away from home.  Soon it was living on the streets of Berkeley.
There, Unix got involved with a bad crowd.  Its life became a
degrading journey of drugs and debauchery.  To keep itself alive, it
sold cheap source licenses for itself to universities which used it
for medical experiments.  Being wantonly hacked by an endless stream
of nameless, faceless undergraduates, both men and women, often by
more than one at the same time, Unix fell into a hell-hole of
depravity.

And so it was that poor little Unix began to go insane.  It retreated
steadily into a dreamworld, the only place where it felt safe.  It
took heroin and dreamed of being a real operating system.  It took LSD
and dreamed of being a raspberry flavored three-toed yak.  It liked
that better.  As Unix became increasingly attracted to LSD, it would
spend weekends reading Hunter Thompson and taking cocktails of acid
and speed while writing crazed poetry in which it found deep meaning
but which no one else could understand:


    $sed <$mf >$mf.new -e '1,/^# AUTOMATICALLY/!d'

    make shlist || ($echo "Searching for .SH files..."; \
           $echo *.SH | $tr ' ' '\012' | $egrep -v '\*' >.shlist)
    if $test -s .deptmp; then
       for file in `cat .shlist`; do
           $echo `$expr X$file : 'X\(.*\).SH'`: $file config.sh \; \
               /bin/sh $file >> .deptmp
       done
       $echo "Updating $mf..."
       $echo "# If this runs make out of memory, delete /usr/include lines." \
           >> $mf.new
       $sed 's|^\(.*\.o:\) *\(.*/.*\.c\) *$|\1 \2; '"$defrule \2|" .deptmp \
          >>$mf.new
    else
       make hlist || ($echo "Searching for .h files..."; \
           $echo *.h | $tr ' ' '\012' | $egrep -v '\*' >.hlist)
       $echo "You don't seem to have a proper C preprocessor.  Using grep instead."
       $egrep '^#include ' `cat .clist` `cat .hlist`  >.deptmp
       $echo "Updating $mf..."
       <.clist $sed -n                                                 \
           -e '/\//{'                                                  \
           -e   's|^\(.*\)/\(.*\)\.c|\2.o: \1/\2.c; '"$defrule \1/\2.c|p"
       \
           -e   d
       \
           -e '}'
       \
           -e 's|^\(.*\)\.c|\1.o: \1.c|p' >> $mf.new
       <.hlist $sed -n 's|\(.*/\)\(.*\)|s= \2= \1\2=|p' >.hsed
       <.deptmp $sed -n 's|c:#include "\(.*\)".*$|o: \1|p' | \
          $sed 's|^[^;]*/||' | \
          $sed -f .hsed >> $mf.new
       <.deptmp $sed -n 's|c:#include <\(.*\)>.*$|o: /usr/include/\1|p' \
          >> $mf.new
       <.deptmp $sed -n 's|h:#include "\(.*\)".*$|h: \1|p' | \
          $sed -f .hsed >> $mf.new
       <.deptmp $sed -n 's|h:#include <\(.*\)>.*$|h: /usr/include/\1|p' \
          >> $mf.new
       for file in `$cat .shlist`; do
           $echo `$expr X$file : 'X\(.*\).SH'`: $file config.sh \; \
               /bin/sh $file >> $mf.new
       done
    fi

Eventually, Unix began walking down Telegraph Avenue talking to
itself, saying "Panic: freeing free inode," over and over again.
Sometimes it would accost perfect strangers and yell "Bus error (core
dumped)!" or "UNEXPECTED INCONSISTENCY: RUN FSCK MANUALLY!"  at them
in a high pitched squeal like a chihuaua with amphetamine psychosis.
Upstanding citizens pretended it was invisible.  Mothers with children
crossed to the other side of the street.

Then one evening Unix watched television, an event which would change
its life.  There it discovered professional wrestling and knew that it
had found its true calling.  It began to take huge doses of
corticosteroids to build itself up even bigger than the biggest of the
programs which had beaten it up as a child.  It ate three dozen
pancakes and four dozen new features for breakfast each day.  As the
complications of the steroids grew worse, its internal organs grew to
the point where Unix could no longer contain them.  First the kernel
grew, then the C library, then the number of daemons.  Soon one of its
window systems was requiring two megabytes of swap space for each open
window.  Unix began to bulge in strange, unflattering places.  But
Unix continued to take the drugs and its internal organs continued to
grow.  They grew out its ears and nostrils.  They placed incredible
stresses on Unix's brain until it finally liquefied under pressure.
Soon Unix had the mass of Andre the Giant, the body of the Elephant
Man, and the mind of a forgotten Jack Nicholson character.

The worst strain was on Unix's mind.  Unable to assimilate all the
conflicting patchworks of features it had ingested, its personality
began to fragment into millions of distinct, incompatible operating
systems.  People would cautiously say "good morning Unix.  And who are
we today?" and it would reply "Beastie" (BSD), or "Domain", or "I'm
System III, but I'll be System V tomorrow."  Psychiatrists labored for
years to weld together the two major poles of Unix's personality,
"Beasty Boy", an inner-city youth from Berkeley, and "Belle", a
southern transvestite who wanted a to be a woman.  With each attempt,
the two poles would mutate, like psychotic retroviruses, leaving their
union a worthless blob of protoplasm requiring constant life support
to remain compatible with its parent personalities.

Finally, unbalanced by its own cancerous growth, Unix fell into a vat
of toxic radioactive wombat waste, from which it emerged, skin white
and hair green.  With a horrible grin on its face, it set out to
conquer the world.
-------



13-Nov-92 08:25:25-MST,581;000000000000
Return-Path: <[email protected]>
Received: from epilogue.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 13 Nov 92 08:25:19 MST
From: Rob Austein <[email protected]>
Sender: [email protected]
To: Clive Dawson <[email protected]>
CC: [email protected]
In-reply-to: Clive Dawson's message of Thu, 12 Nov 92 20:22:36 CST <[email protected]>
Subject: The History of Unix - A Sordid Life Story
Date: Fri, 13 Nov 92 10:24:59 EST
Message-ID:  <[email protected]>

That piece was written by Ian Horswill <[email protected]>.

--Rob
18-Nov-92 09:18:42-MST,1416;000000000000
Return-Path: <[email protected]>
Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Nov 92 09:18:32 MST
Date: Wed, 18 Nov 92 11:17 EDT
From: JERRY WEINER BBN 617-873-3242 <[email protected]>
Subject: NETWORK problems with NI20
To: [email protected]
X-VMS-To: @TOPS

Folks,

       I am having the following random Network problem. We have two DEC-20's
in a cluster. (it being a cluster has nothing to do with the network problem).

       The network "goes away". DECNET, TCP/IP, and LAT stop. The console
works and any DH lines work. Looking at the ETHERNET counters with IPHOST ETH
Status command will show a negative number of read errors (it probably
overflows the counter in the NI-20) or NCP Show Line/Circuit Counters will
show >65xxx read errors. The DEC-20 is still sending data out. I have two
reasons to believe this. On LAT terminals services the service keeps getting
announced. We also have an IP program on teh DEC-20 that sends a packet every
30 seconds to a system that monitors many systems. It continues to receive
packets.

       It almost looks like the NI20 shuts down receiving packets.

       The problem has happened three times on one system and one time on the
other. None of the occurances happen at the  same time. One time we got a LATNSC
Bugchk.

       Anyone seen a problem like this or have any suggestions?

Thanx,
Jerry Weiner
24-Nov-92 14:24:30-MST,1071;000000000000
Return-Path: <[email protected]>
Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 24 Nov 92 14:24:08 MST
Received: by sandpiper.wesleyan.edu (5.61/1.35)
       id AA08683; Tue, 24 Nov 92 13:03:42 -0500
Date: Tue, 24 Nov 92 13:03:42 -0500
Message-Id: <[email protected]>
From: Douglas Bigelow <[email protected]>
To: [email protected]
Subject: DECSYSTEM-20 energy consumption

Greetings, all;

I need to figure out how much our DEC-20 is costing Wesleyan in energy
costs.  It's a 2MW 2060 with three RP07s and an RP06, two TU78s and a 1200
LPM line printer.  I'm looking for estimates for KW consumption first,
and heat output second so I can guess at air conditioning costs.

If anyone has some of these figures around (rough guesses are fine) I'd
much appreciate it.  Alternately, if you've ever estimated a DEC-20's
energy costs for your own site, I'd love to hear your figures.

Thanks...

Doug Bigelow
Director of Academic Computing, Wesleyan University
25-Nov-92 03:15:26-MST,942;000000000000
Return-Path: <[email protected]>
Received: from regal.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 25 Nov 92 03:15:16 MST
Received: by regal.cisco.com; Wed, 25 Nov 92 02:14:54 -0800
Date: Wed, 25 Nov 92 2:14:54 PST
From: William "Chops" Westfield <[email protected]>
To: Douglas Bigelow <[email protected]>
Cc: [email protected]
Subject: Re: DECSYSTEM-20 energy consumption
In-Reply-To: Your message of Tue, 24 Nov 92 13:03:42 -0500
Message-Id: <[email protected]>

Compuserve, at one time, would sell you a switching power supply conversion
for your dec20 (replace the 30% linear supplies with 85% efficient modern
switchers - save big bucks.)

As part of the "marketing" literature for this conversion, they included
some estimates of how much you could save, based on the consumption of
each version - I'll see if I can find the literature somwhere...

BillW
25-Nov-92 11:57:49-MST,1228;000000000000
Return-Path: <[email protected]>
Received: from devon.xkl.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 25 Nov 92 11:57:37 MST
Received: by devon.xkl.com (5.64/1.34)
       id AA15332; Wed, 25 Nov 92 11:04:31 -0800 (PST)
Date: Wed, 25 Nov 92 11:04:31 -0800 (PST)
From: [email protected] (David Means)
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Douglas Bigelow's message of Tue, 24 Nov 92 13:03:42 -0500 <[email protected]>
Subject: DECSYSTEM-20 energy consumption

 My configuration is a little different: 5 RP07s and 2RP06s and no
lineprinter.  It draws 20KW, according to the power distribution unit meter.
 This configuration keeps a 7.5 ton air conditioner busy (we have 12.5 in
2 units; one runs nearly continuously, the other takes up the slack).

 If you find that the cost is outrageous (our total electrical bill is
about $1400/mo, which covers all uses in an office of 15), help is on the
way.  Our machine is being used to design its replacement; we hope to have
the first units out sometime in '93.  They are targeted to consume about 1KW.

                                       david means
                                       XKL Systems Corp.
25-Nov-92 18:44:34-MST,1157;000000000000
Return-Path: <[email protected]>
Received: from ULLA.FORNAX.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 25 Nov 92 18:44:31 MST
Date: Thu, 26 Nov 1992 02:43:59 +0200 (MET)
From: Joe Dempster <[email protected]>
Subject: Re:  DECSYSTEM-20 energy consumption
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
In-Reply-To:  <[email protected]>
Mail-System-Version: <VAX-MM(284)+TOPSLIB(151)@ULLA.FORNAX.COM>

I think you should consider the Compuserve power supply upgrade,
it will save you about 1/3 the power consumption of the KL and a
corresponding decrease in AC.

If you are really serious about "conservation" and have a high pain
threshold, talk to Mike Levitt at SC Group in Reno NV.  They have both
a RH20 board for a SCSI disk and tape.  You will only need a RP06
for the FE.

DEC will support the power supply, never the SCSI stuff, but then it
usually never breaks.

You might also approach the XKL people in Seattle, they might want to
cultivate a EDU site for their new system with a big discount.

/joe
1-Dec-92 13:28:40-MST,969;000000000000
Return-Path: <[email protected]>
Received: from relay1.UU.NET by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 1 Dec 92 13:28:32 MST
Received: from lysator.liu.se by relay1.UU.NET with SMTP
       (5.61/UUNET-internet-primary) id AA29448; Mon, 30 Nov 92 14:24:47 -0500
Received: by lysator.liu.se
         (5.65c8/1.34/Lysator-3.1) id AA15185; Mon, 30 Nov 1992 20:21:58 +0100
         (rfc931-sender: [email protected])
Date: Mon, 30 Nov 1992 20:21:58 +0100
From: [email protected] (P{r Emanuelsson)
Message-Id: <[email protected]>
To: tops20%[email protected]
Subject: Strange request...


Hi. Anyone got a microcode assembler for the KS10?
I'm also looking for the source to ITS. Is it available for FTP from
somewhere?

Further, I'd like to setup an FTP dir for "harder, low-level" stuff, like
the assembler above. Please get in touch with me if you have something that
might be useful.

Thanks

   /Pell
2-Dec-92 09:25:14-MST,957;000000000000
Return-Path: <[email protected]>
Received: from epilogue.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 2 Dec 92 09:25:10 MST
From: Rob Austein <[email protected]>
Sender: [email protected]
To: P{r Emanuelsson <[email protected]>
CC: [email protected]
In-reply-to: P{r Emanuelsson's message of Mon, 30 Nov 1992 20:21:58 +0100 <[email protected]>
Subject: KS-10 microcode assembler and ITS sources
Date: Wed, 2 Dec 92 11:23:51 EST
Message-ID:  <[email protected]>

The entire ITS filesystems of AI and MC are archived and available for
anonymous FTP from mc.lcs.mit.edu:/its/.  If you really want the
entire thing you might want to talk to Peter Lothberg first, he's
probably got local copies on your side of the pond.

Low-level ITS KS-10 programs like the microcode assembler used to live
in AI: KSHACK;, so they're now in mc.lcs.mit.edu:/its/ai/kshack/.

--Rob Austein <[email protected]>
2-Dec-92 15:29:25-MST,1652;000000000000
Return-Path: <[email protected]>
Received: from Tomobiki-Cho.CAC.Washington.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 2 Dec 92 15:29:21 MST
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
       (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA01248; Wed, 2 Dec 92 12:58:56 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00358; Wed, 2 Dec 92 12:57:37 -0800
Date: Wed, 2 Dec 1992 12:45:31 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Strange request...
To: P{r Emanuelsson <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 30 Nov 1992 20:21:58 +0100, P{r Emanuelsson wrote:
> Hi. Anyone got a microcode assembler for the KS10?

I have a copy of MICRO.MAC for the KS10.  It's 116,333 characters.  I also
have the KS10 microcode checker (58,659 characters).  I don't see any
copyright notices on these, so it's probably alright to give them to you.
They're online on Yuuyuu, so they'll have to be kermited or e-mailed to get
them to you.

> Further, I'd like to setup an FTP dir for "harder, low-level" stuff, like
> the assembler above. Please get in touch with me if you have something that
> might be useful.

I don't know if DEC would care about this any more, but they might if things
like TOPS-10/20 or microcode sources were there.

4-Dec-92 10:27:38-MST,680;000000000000
Return-Path: <[email protected]>
Received: from fernwood.mpk.ca.us by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 4 Dec 92 10:27:32 MST
Received: by fernwood.mpk.ca.us; id AA26556; Fri, 4 Dec 92 09:29:23 -0800
Received:  by nw.com (UUPC/extended 1.11p);
          Fri, 04 Dec 1992 09:24:27 PST
Date:      Fri, 04 Dec 1992 09:24:26 PST
From: "Mark Lottor" <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject:   hardware flow control

Hi -

 What's the deal with getting bidirectional RTS/CTS flow control on
our DEC20? (please no terminal server suggestions).  We want to hook up
some 9600 baud modems to it.

-mkl
7-Dec-92 10:52:12-MST,1608;000000000000
Return-Path: <[email protected]>
Received: from inet-gw-1.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 7 Dec 92 10:52:00 MST
Received: by inet-gw-1.pa.dec.com; id AA02429; Mon, 7 Dec 92 09:51:40 -0800
Received: by zowie.zso.dec.com (5.57/fma-100391);
       id AA07900; Mon, 7 Dec 92 09:51:30 -0800
Date: Mon, 7 Dec 92 9:51:29 PST
From: Hans Ridder <[email protected]>
To: "Mark Lottor" <[email protected]>
Cc: [email protected]
Subject: Re: hardware flow control
In-Reply-To: Your message of Fri, 04 Dec 1992 09:24:26 PST
Message-Id: <[email protected]>

>  What's the deal with getting bidirectional RTS/CTS flow control on
>our DEC20? (please no terminal server suggestions).  We want to hook up
>some 9600 baud modems to it.

Don't worry, I wasn't going to suggest a terminal server.  Unless things
have changed, *our* terminal servers don't allow you to have "modem
control" and "RTS/CTS flow control" enabled at the same time.

All the modem control is handled by RSX-20F in the front-end (assuming
you're talking about a KL.)  As I remember, the FE raises and lowers RTS
at the same time as DTR.  I don't recall exactly how it treats CTS.
It's possible that -20F already handles it as a "flow control" signal.

In any case, it would require a patch to RSX-20F (a listing for the
version you're running helps alot.)  You'd also have to come up with a
spare bit somewhere in the "queued protocol" to enable RTS/CTS flow
control, and some code for TOPS-20 (the easy part!)  It's certainly
doable, but not alot of fun.

>-mkl

-hans
7-Dec-92 12:16:23-MST,1704;000000000000
Return-Path: <[email protected]>
Received: from Tomobiki-Cho.CAC.Washington.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 7 Dec 92 12:16:17 MST
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
       (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA07633; Mon, 7 Dec 92 11:16:07 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
       (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA08987; Mon, 7 Dec 92 11:15:59 -0800
Date: Mon, 7 Dec 1992 11:09:35 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: hardware flow control
To: Mark Lottor <[email protected]>
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 04 Dec 1992 09:24:26 PST, Mark Lottor wrote:
>   What's the deal with getting bidirectional RTS/CTS flow control on
> our DEC20? (please no terminal server suggestions).  We want to hook up
> some 9600 baud modems to it.

On a KS10 CPU, it is impossible.  The DZ11 hardware does not support these
signals.  You will have all sorts of fun and laughter trying to get a 9600
baud modem to work reasonably on a KS10.  Believe me, I know.

It may be possible on a KL10.  I am not sure whether or not a DH11 (or one of
the many clones) can support CTS/RTS signals.  However, you have to face all
the joy and rapture of hacking RSX-20F, since there RSX does not support it.
DEC was SPR'd on the question a few years ago and they laughed at it.

I know you don't want to hear it, but a terminal server is probably your best
bet.

8-Dec-92 06:31:37-MST,1313;000000000000
Return-Path: <[email protected]>
Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 8 Dec 92 06:31:27 MST
Received: by bsd.stupi.se (5.67/1.37)
       id AA00744; Tue, 8 Dec 92 14:21:55 +0100
Date: Tue, 8 Dec 92 14:21:55 MET
From: Peter Lothberg <[email protected]>
To: Mark Crispin <[email protected]>
Cc: Mark Lottor <[email protected]>, [email protected]
Subject: re: hardware flow control
In-Reply-To: Your message of Mon, 7 Dec 1992 11:09:35 -0800 (PST)
Message-Id: <[email protected]>

> On Fri, 04 Dec 1992 09:24:26 PST, Mark Lottor wrote:
> >   What's the deal with getting bidirectional RTS/CTS flow control on
> > our DEC20? (please no terminal server suggestions).  We want to hook up
> > some 9600 baud modems to it.
>
> On a KS10 CPU, it is impossible.  The DZ11 hardware does not support these
> signals.  You will have all sorts of fun and laughter trying to get a 9600
> baud modem to work reasonably on a KS10.  Believe me, I know.

If you baadly needs this, i suggest a hardware patch to AND the uart
transmitter buffer empty flag pin with your favorite handshake
signal..

Atleast it takes less time than fixing RSX20F...


(If someone needs this for a DN87/T10 frontend, I have the patch,
but's  that not RSX20f...)

-Peter
14-Dec-92 13:16:29-MST,508;000000000000
Return-Path: <[email protected]>
Received: from sunl.cr.usgs.gov by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 14 Dec 1992 13:16:23 -0700 (MST)
Received: from dgg.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
       id AA21360; Mon, 14 Dec 92 14:11:57 CST
Received: by dgg.cr.usgs.gov (5.4.1/1.34)
       id AA00870; Mon, 14 Dec 1992 14:16:01 -0600
Date: Mon, 14 Dec 1992 14:16:01 -0600
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]

SUBSCRIBE
26-Dec-92 21:38:41-MST,1791;000000000000
Return-Path: <[email protected]>
Received: from uu3.psi.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 26 Dec 1992 21:38:34 -0700 (MST)
Received: from ceb486.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
       id AA10644; Sat, 26 Dec 92 23:24:31 -0500
Received: from ceb486.UUCP by pulse.com (4.1/SMI-4.1)
       id AA20348; Sat, 26 Dec 92 23:23:31 EST
From: "C. E. Brooks" <[email protected]>
X-Mailer: SCO System V Mail (version 3.2)
To: [email protected], [email protected]
Subject: Add "[email protected]" to mail list
Cc: [email protected]
Return-Receipt-To: [email protected]
Date: Sat, 26 Dec 92 23:15:44 EST
Message-Id:  <[email protected]>

Folks,

Please add me to the ITS and TOPS-20 mailing lists.

I have fond memories of the Maynard MFG Data (my system was in the Mill)
where I first worked on PDP-10s for In-House Field Service.  I left DEC to
work at BBN since DEC decided that FS folks did not need to know what the OS
software was doing.  At BBN I performed KA-to-TENEX two upgrades, installing
the cpu mods and the BBN pager (the last may have been the final upgrade
ordered by the government).  While at BBN I built and delivered the second
generation of IMP-10 interfaces for Wharton, LBL, and several internal systems.
Later I worked for DEC at Marlboro in LCG CSSE on TOPS-10, TOPS-20, and
DECNET field tests.  I was a member of the Jupiter project and present for
KO's annoucement of its demise (shortly followed by the entire 36 bit
product line).

I am very interested in the existence of any PDP-10/20 instruction set
simulators or emulators that run in either a Unix environment (SPARC or
SCO Unix) or a DOS/Windows environment.

                       /ceb\

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.