9-Jan-89 15:42:02-PST,1267;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet>
Received: from CORNELLC.ccs.cornell.edu by SCORE.STANFORD.EDU with TCP; Mon 9 Jan 89 15:39:27-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 1193; Mon, 09 Jan 89 18:39:59 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
Mon, 9 Jan 89 16:35:12 MST
Date: Mon, 9 Jan 89 16:33:48 MST
From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster)
Message-Id: <890109163348.01j@Janus.MRC.AdhocNet.CA>
Subject: Bliss-36 help
To: tops-20@score.stanford.edu
I'm trying to allocate a table of a size of %o5000 in size.
It appears the BLISS's default size(stacksize) is 1000. I've
search through the books and can't seem to find a way to increase
the size of the stack.
Any of you BLISSophites still out there?
/Russ
-----
Russell M. Forster, Systems Programmer II.
Mount Royal College DECnet: RMF @ Janus
Computer Operations BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W
Calgary, Alberta Phone: (403) 240-6052
T3E 6K6
11-Jan-89 09:20:55-PST,11507;000000000000
Return-Path: <DEMPSTER@TOPS20.DEC.COM>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Wed 11 Jan 89 09:19:22-PST
Date: 11 Jan 1989 1220-EST
From: "Joe Dempster, DTN 336.2023, AT&T 609.273.2023" <DEMPSTER@TOPS20.DEC.COM>
To: tops20@score.stanford.edu
Subject: PDP-10 hacker featured in today's NYT's
Message-ID: <"MS11(6044)+GLXLIB6(0)" 12461728668.215.30.2128 at TOPS20.DEC.COM>
The New York Times
January 11, 1989
Section: Business Day, page D1
One Man's Fight for Free Software
By John Markoff
Richard M. Stallman is a computer programmer obsessed with
a mission. He wants to bring back the good old days when programming
was a communal activity and those toiling at the craft freely shared
their ideas - and their source code, the internal instructions that
tell the computer what to do.
Mr. Stallman, known among his coleagues as "The Last Hacker"
has spent the last decade battling a computer software industry that
increasing builds ownership walls around intellectual property. He
believes that computer software should be freely shared and devotes
himself to creating sophisticated programs that he gives away.
He spends his days and nights in a cramped office at the
Massachussets Institute of Technology's Artificial Intelligence
Laboratory working to spread his philosophy that software is different
from other physical commodities since it can be copied at virtually no cost.
He believes there should be no restrictions on freely copying and
distributing it.
Mr. Stallman's ideas have gained increasing importance of
late because the computer industry has been moving toward "open"
software that will run on may different brands of computers. Consortiums
of computer companies have formed to champion their version of the open
software, based on the popular Unix computer software operating system.
But Mr. Stallman carries the idea on step further. Not only should
the software run on different computers, but it should also be free.
Mr. Stallman is doing nothing illegal, but his is an argument that
raises bitter objections from many programmers and companies. They counter
that protecting intellectual property is vital to encouraging innovation.
During the last two decades intellectual property protection has
become the foundation of the moderm software industry. However,
Mr. Stallman asserts that what he calls "the use of human knowledge for
personal gain" has had a negative impact because information is no longer
widely shared.
"It's impossible to do anything without copying something that has
come before," he said. "People talk about the bad effects of government
secrecy in Russia. The U.S. is heading for the same place in terms of
commercial software."
In a manifesto that outlines his philosophy, Mr. Stallman says that
software sellers want to divide the users and conquer them by making each
agree not to share with others.
"I have decided to put together a sufficient body of free software so
that I will be able to get along without any software that is not "free."
he writes.
Perhaps Mr. Stallman's concept of free software would be easier to
dismiss if he was not universally considered - even by his enemies - to be
one of the nation's most outstanding programmers. And his body of software
is considered distinguished by industry experts.
The computer industry is now evenly split between two giant
consortiums that each claim to champion open software systems based on
the Unix System. They contend that the open systems will emancipate the
computer user from a single company's private standards. One has allied
I.B.M., The Digital Equipment Corporation and others opposite American
Telephone and Telegraph and Sun Microsystems. Mr. Stallman is somewhere
in the middle and his alterative of truly free software is gaining
attention - and credibility.
For example, Steve Jobs's Next computer comes bundled with Mr.
Stallman's free software, and a number of other computer companies,
including the Sony Corporation, Sun, the Hewelett-Packard Company, the
Intel Corporation and the Data General Corporation, are now giving support
to aid Mr. Stallman's develoment work.
From his outpost on the M.I.T. Campus Mr. Stallman operates
the Free Software Foundation, a loosely run organization of part-time
staff members and volunteers that is now well on its way to creating a
complete software system called GNU. The name is a Mobius strip-like
acronym that stands for "GNU's not Unix."
When complete, GNU will include a computer operating system and all
the tools needed by programmers to design and write the most sophisticated
applications for a wide variety of computers. It will also include
word processors, spreadsheets, data base managers and communication software,
making it just as useful to non-programmers.
It is a Herculean undertaking, comparable to those that corporations
like I.B.M., D.E.C. and A.T.&T. each devote millions of dollars and hundreds
of programmers to annually.
But unlike commercial software ventures, GNU programs are
distributed with source code, the original programmer's instructions.
This permits any user to modify the program or improve it. While most
software companies jealously guard their source code, Mr. Stallman argues
that by freely sharing it he has created a software community in which each
programmer contributes improvements, thereby bettering the program for all.
Mr. Stallman, who likes to be called by his initials, R.M.S.,
forged his values as a member of an elite group of M.I.T. computer
hackers who, during the 1960's and 70's, conducted pioneering research
in developing the world's first minicomputers and the first time-sharing
computers. M.I.T., which is where the term hacker was born, also served as
the incubator for many early computer hardware and software companies.
In that community, software was freely shared among the hackers,
who would build their work on the earlier programming efforts of their
friends.
While the press has come to identify the term hacker with
malicious individuals who break into computers over telephone lines, the
hackers themselves have an earlier and different definition. A hacker,
Mr. Stallman said, is one who "acts in the spirit of creative playfulness."
But while hacking began as intellecutal sport and became a way of
life in the Mid-1970's, many of the hackers who had participated in the
tightly knit community of computer researchers left to take advantage of
lucrative employment opportunities at the new companies. Only Mr. Stallman
remained behind, intent on carrying on the traditions.
The breakup of the hacker community embittered him and for several
years he labored in solitude intent on the incredible task of matching
the world's best programmers, writing for free the same programs they were
developing on a for-profit basis at their new companies.
In his book "Hackers," Steven Levy describes how during 1982 and
1983 Mr. Stallman matched the work of more than a "dozen world-class hackers"
at Symbolics Inc., rewriting their programs and then placing them in the
public domain.
"He believes that information should be free and he interprets it in
the most literal fashion," Mr. Levy said in an interview. "Most hackers make
accommodations with the way the world works. Stallman doesn't want to make
those concessions. He's a total idealist."
Some computer scientists believe there is a place for Mr. Stallman's
free software. "There is room in the world for free stuff and commercial
stuff," said Brian Harvey, a computer science lecturer at the University
of California at Berkeley. "We don't have to take over the world. Its
good enough that I can run his software on my computer."
The most popular GNU program is an extremely flexible editing
program known as Emacs. The software package, originally written by
Mr. Stallman at M.I.T. in the early 1970's, has become one of the most
widely used - and imitated - programming editors. Another widely used
GNU program is a compiler, a program that translates text into a form that
can be executed by a computer.
For a programmer, a compiler and editor are equivalent to a
Carpenter's hammer and saw, the two most important tools of the craft.
Emacs's popularity is due to its flexibility, programmers say. An entire
computer language is embedded in the program, giving it the utility
equivalent to that of a Swiss Army Knife. For tens of thousands of
programmers Emacs has become virtually the only program they use because
they can fashion it into a data base, word processor, appointment calendar or
whatever else they need.
"You start up Emacs and you never leave it," said Russell Brand, a
computer scientist at Lawrence Livermore Laboratories in Livermore, Calif.
GNU software is freely distributed, but in a different manner
from public domain and "freeware" software among personal computer users.
While public domain software can be freely copied, freeware authors ask
users to contribute a fee if they find a program useful. In contrast,
GNU programs are not placed in the public domain. Instead they are
distributed with a public license that Mr. Stallman calls a "copyleft."
This license insures that the software will stay freely copyable and not
be incorporated into a for-profit program.
While Mr Stallman's software is widely used at universities and
research centers and by professional programmers, his zealous commitment to
the idea of free software has angered others.
Several years ago the idea led to a bitter dispute when executives
at Unipress Software Inc., an Edison, N.J., company that sells a commercial
version of Emacs, pointed out that some of their code appeared in a version
of Mr. Stallman's Emacs.
The problem stemmed from the fact that Mr. Stallman had decided
that because the original idea of Emacs was his, he could freely borrow
parts of a version written by another programmer, James Gosling, who now works
at Sun. While a student at Carnegie Mellon University in Pittsburgh,
Mr. Gosling had written his own version of Emacs and distributed it to friends
before giving it to Unipress to sell commercially.
Mr. Stallman said he had been told by a friend of Mr. Gosling's that
he could use parts of the program. Angry messages passed back and forth
over computer networks before Mr. Stallman decided that the way to end the
dispute was simply to rewrite the offending passages.
"We thought it was a little ironic," said Mark Krieger, president
of Unipress. "He says he plans on taking on the giants and then the first
company he goes after is little Unipress."
Despite the remaining betterness over the quarrel, Mr. Krieger said
he had great respect for Mr. Stallman's programming prowess. "I would
give him negative credit for his ideas on free software," he said, "but give
him a lot of positive credit as a brilliant design engineer and the creator of
the first Emacs."
Today although he uses an office at the M.I.T. Artificial Intelligence
Laboratory, he is no longer a staff member. He resigned a number of years ago
when he set out to create the GNU software system. He makes a living as a
part-time software consultant.
--------
12-Jan-89 15:02:36-PST,799;000000000000
Mail-From: VAF created at 12-Jan-89 15:00:25
Date: Thu 12 Jan 89 15:00:25-PST
From: Vince Fuller <VAF@Score.Stanford.EDU>
Subject: Re: Bliss-36 help
To: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.CIT.CORNELL.EDU
cc: tops-20@Score.Stanford.EDU
In-Reply-To: <890109163348.01j@Janus.MRC.AdhocNet.CA>
Office: Pine Hall 167
Phone: 415-723-6860
Message-ID: <12462052769.19.VAF@Score.Stanford.EDU>
There is an ENVIRONMENT option in the module header that specifies the
"segment-name" (the name of some chunk of OWN or GLOBAL storage) to be used
as the PDL. The syntax is:
MODULE FOO(ENVIRONMENT(STACK=MYSTACK)) =
...
This is covered in the BLISS language guide in chapter 19.
Vince Fuller, Stanford University
(former TOPS-20 and BLISS hacker from CMU)
-------
30-Jan-89 09:40:12-PST,1417;000000000000
Return-Path: <ADMIN@RADC-TOPS20.ARPA>
Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 09:37:41-PST
Date: Mon 30 Jan 89 12:36:46-EST
From: ADMIN@RADC-TOPS20.ARPA
Subject: domains and such
To: tops20@SCORE.STANFORD.EDU
cc: admin@RADC-TOPS20.ARPA
Message-ID: <12466712444.8.ADMIN@RADC-TOPS20.ARPA>
We are considering getting rid of RADC-TOPS20.ARPA. The decision may
very well depend upon the answers to the following questions
1) Can the Dec20 be used as a domain server and a host (primarily for
network mail, FTP and TN)? There would not be much other processing
going on. Is the software readily available, what is the cost?
2) In any case, if the DEC20 stays around we need to to use domains
instead of a host table. Is there software available? Where? At
what cost? For what version of the operating system?
3) If the 20 stays around it would move from the Arpanet to a Milnet
port which we have available. The Arpanet port is 1822. The
Milnet is X.25. Will this transition require different hardware or
software? From what source? At what cost?
Thank you for your answers in advance. The person who currently owns
the machine wanted to get rid of it yesterday. The division who might
want to keep it needs these answers ASAP. And thus I zip a message to
you and get wonderful information in no time at all.
Thanks,
Donna
-------
30-Jan-89 12:22:57-PST,2088;000000000000
Return-Path: <BILLW@MATHOM.CISCO.COM>
Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 12:21:58-PST
Date: Mon 30 Jan 89 11:33:18-PST
From: William Westfield <BILLW@MATHOM.CISCO.COM>
Subject: Re: domains and such
To: ADMIN@RADC-TOPS20.ARPA
cc: tops20@SCORE.STANFORD.EDU
In-Reply-To: <12466712444.8.ADMIN@RADC-TOPS20.ARPA>
Message-ID: <12466733658.34.BILLW@MATHOM.CISCO.COM>
1) Can the Dec20 be used as a domain server and a host (primarily for
network mail, FTP and TN)? There would not be much other processing
going on. Is the software readily available, what is the cost?
2) In any case, if the DEC20 stays around we need to to use domains
instead of a host table. Is there software available? Where? At
what cost? For what version of the operating system?
There are two domain systems available for the 20. One is called Jeeves,
and is available from ISI. The other is called Chives, and is from MIT.
Chives is a resolver only, Jeeves includes both a server and a resolver.
Most of the popular network utilities have been rewritten to use domains,
and most are free (available from Stanford, etc). Both Chives and Jeeves
really require monitor modifications (so you have to have sources around
someplace), but I have been successful in making Jeeves run in user mode.
Chives is supposed to have hooks for this too.
3) If the 20 stays around it would move from the Arpanet to a Milnet
port which we have available. The Arpanet port is 1822. The
Milnet is X.25. Will this transition require different hardware or
software? From what source? At what cost?
There are no DDN X.25 interfaces for the dec20 that I know of. Your best
bet would be to get an ethernet for the 20, and an ethernet-x.25 router.
The total cost would probably be around 20K, but of course other hosts
could use the router too. DEC sells ethernet interfaces (NIA-20), several
vendors sell the routers (The best one comes from cisco Systems :-)
Bill Westield
cisco Systems.
-------
30-Jan-89 12:46:44-PST,1454;000000000000
Return-Path: <MRC@WSMR-SIMTEL20.Army.MIL>
Received: from june.cs.washington.edu by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 12:46:23-PST
Received: from tomobiki-cho.acs.washington.edu by june.cs.washington.edu (5.59/6.13+)
id AA11955; Mon, 30 Jan 89 12:46:21 PST
Return-Path: <MRC@WSMR-SIMTEL20.Army.MIL>
Date: Mon, 30 Jan 1989 12:42:34 PST
From: Mark Crispin <MRC@WSMR-SIMTEL20.Army.MIL>
Subject: re: domains and such
To: ADMIN@RADC-TOPS20.ARPA
Cc: TOPS-20@Score.Stanford.EDU
In-Reply-To: <12466712444.8.ADMIN@RADC-TOPS20.ARPA>
Message-Id: <MS-C.602196154.2035015474.MRC@WSMR-SIMTEL20.Army.MIL>
Donna -
There is DEC-20 domain resolver (client) and server software available.
It can be run under TOPS-20 versions 5.3, 5.4, 6.1, and 7.0. This software
is available from MIT at no cost; contact SRA@XX.LCS.MIT.EDU.
I regret to inform you that your only networking options for a DEC-20 are
1822 (via an AN20), Ethernet (via an NIA-20), or serial DECnet (via a DN20).
I am not aware of any TCP/IP options using a DN20 and would strongly
discourage even thinking about using a DN20. Consequently, if you were to
move the machine to Milnet, you would probably need to move the 1822 port from
the ARPANET IMP to the Milnet IMP.
The DEC-20 domain software is excellent, so you may have an argument to
justify keeping the DEC-20 and even putting an 1822 IMPterface on your Milnet
IMP.
-- Mark --
-------
30-Jan-89 13:19:52-PST,1303;000000000000
Return-Path: <jeff@uhccux.uhcc.Hawaii.Edu>
Received: from ames.arc.nasa.gov by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 13:19:26-PST
Received: Mon, 30 Jan 89 12:59:54 PST from uhccux.uhcc.Hawaii.Edu by ames.arc.nasa.gov (5.59/1.2)
Received: by uhccux.uhcc.Hawaii.Edu (1.2/Ultrix2.2)
id AA19622; Mon, 30 Jan 89 11:14:26-1000
Date: Mon, 30 Jan 89 11:14:26-1000
From: Jeff Blomberg <jeff@uhccux.uhcc.Hawaii.Edu>
To: tops-20@SCORE.STANFORD.EDU
Subject: TOPS-20 TCP/IP Subnetting......
Cc: jeff@uhccux.uhcc.Hawaii.Edu
Message-Id: <CMM.0.88.602198063.jeff@uhccux.uhcc.hawaii.edu>
Aloha!
This question may have been asked before, I don't recall the answer....
For the last few months of the life of our 2065 we are going to have to
place it behind a Proteon P4200 gateway. Both 'sides' of the gateway
have the same Class B address, but a different subnet allocation.
Question: Can TOPS-20 be easily taught to do subnet masking? I recall
a rumor that system:internet.address migh actually have a
net mask field, but don't have sources to confirm.
Our Class B address: 128.171.xx.yy
Desired mask: 255.255.255.0
If not possible, we'll simply use a Class C address allocation until the -20
goes away.
-Jeff Blomberg
U of Hawaii
30-Jan-89 16:01:12-PST,749;000000000000
Mail-From: VAF created at 30-Jan-89 16:00:35
Date: Mon 30 Jan 89 16:00:35-PST
From: Vince Fuller <VAF@Score.Stanford.EDU>
Subject: re: domains and such
To: ADMIN@RADC-TOPS20.ARPA
cc: TOPS-20@Score.Stanford.EDU
In-Reply-To: <MS-C.602196154.2035015474.MRC@WSMR-SIMTEL20.Army.MIL>
Office: Pine Hall 167
Phone: 415-723-6860
Message-ID: <12466782314.34.VAF@Score.Stanford.EDU>
There is an implementation of TOPS-20 TCP/IP via a DN20 that works fairly well
(I know, I worked on it). The code, however, has never been tested with 6.1
and probably won't work with it without modification. Also, special software is
necesssary for the DN20 to work (and DECNET cannot coexist in the same DN20
with the TCP/IP software).
--Vince
-------
31-Jan-89 00:40:59-PST,673;000000000000
Return-Path: <JTW@AI.AI.MIT.EDU>
Received: from AI.AI.MIT.EDU by SCORE.STANFORD.EDU with TCP; Tue 31 Jan 89 00:40:29-PST
Date: Tue, 31 Jan 89 03:41:58 EST
From: John Wroclawski <JTW@AI.AI.MIT.EDU>
Subject: Anyone want a 2065?
To: tops-20@SCORE.STANFORD.EDU
Message-ID: <528972.890131.JTW@AI.AI.MIT.EDU>
2065 for sale to good home, or maybe we'll give it to you if nothing
better comes up...
KL10, 2MW MG20 memory, NI10 ethernet, 3 RH20's, TM02/TU45's, DN20,
AN20, pretty orange cabinets, an RP06 or two. Currently on service,
well maintained, frequent oil changes, no rust or dents.
Available April. Contact JTW@LCS.MIT.EDU if interested.
-john
31-Jan-89 11:32:29-PST,1378;000000000000
Return-Path: <A.ERIC@GSB-How.Stanford.EDU>
Received: from GSB-How.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 31 Jan 89 11:31:28-PST
Date: Tue 31 Jan 89 11:33:06-PST
From: Eric M. Berg <A.Eric@GSB-How.Stanford.EDU>
Subject: Meaning of "level 0" and "level 1" messages
To: tops-20@Score.Stanford.EDU
Message-ID: <12466995765.26.A.ERIC@GSB-How.Stanford.EDU>
Some time ago, I was interested in finding out what the "system level
zero" and "system level one" messages referred to in the output from the
"INFORMATION SYSTEM-STATUS" command were. David Lomartire was kind enough
to indulge my curiousity; an (edited) copy of his response follows. /Eric
---------------
Date: 26 Jan 1989 0926-EST
From: "David Lomartire" <LOMARTIRE@TOPS20.DEC.COM>
Basically, level 0 messages are:
o [Caution -- Swapping space low]
o [Caution -- SPT space low]
o [Caution -- Disk space low on system structure]
Level 1 messages (on by default) are:
o [System name going down in ....]
o [Shutdown canceled]
o [Deleted files will be expunged from system structure in 30
seconds]
o [System structure expunge completed]
David Lomartire
LSBU Software Engineering
TOPS-20 Group
--------
-------
31-Jan-89 12:21:07-PST,1806;000000000000
Return-Path: <SRA@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Tue 31 Jan 89 12:20:50-PST
Date: Tue, 31 Jan 1989 15:22 EST
Message-ID: <SRA.12467004691.BABYL@LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: tops20@SCORE.STANFORD.EDU
Subject: domains and such
In-reply-to: Msg of 30 Jan 1989 14:33-EST from William Westfield <BILLW@MATHOM.CISCO.COM>
Date: Monday, 30 January 1989 14:33-EST
From: William Westfield <BILLW@MATHOM.CISCO.COM>
... Both Chives and Jeeves
really require monitor modifications (so you have to have sources around
someplace), but I have been successful in making Jeeves run in user mode.
Chives is supposed to have hooks for this too.
At one point last summer I was working with DEC to try to get the
monitor hooks for CHIVES's GTDOM module onto a 7.0 autopatch tape; I
believe we agreed that we had finished working out what the necessary
patches were, but after that I lost track of the project, so I don't
know if DEC had the time or staff to actually get it out the door.
But anyway, if/when this stuff is available from DEC, it should be
possible for a site without a TOPS-20 source license to install CHIVES
in a 7.0 monitor.
Both the JEEVES and CHIVES versions of GTDOM% can be run in user mode
but in both cases it's hard to do quite right. Both packages make use
of specialized scheduler test routines to block process execution
pending one of several possible wakeup conditions, and in user mode
this is hard to emulate, since the raw IP packet interface used by the
UDP code doesn't provide any way to set up interrupts, so things get a
little weird. But, as Bill says, the basic code will run; both were
designed to be debugged in user mode.
--Rob
31-Jan-89 23:05:05-PST,836;000000000000
Return-Path: <MKL@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Tue 31 Jan 89 23:03:06-PST
Date: Tue, 31 Jan 89 23:03:00 PST
From: Mark Lottor <MKL@SRI-NIC.ARPA>
Subject: FE floppy errors
To: tops-20@score.stanford.edu
Message-ID: <12467121356.28.MKL@SRI-NIC.ARPA>
Whenever I play with front-end floppies, like trying to update stuff
or make copies, there seems to always be a few files which when you
try to do a directory listing come up with the file name followed by
something like "...ILLEGAL ATTRIBUTE...". (I could find the exact
error if it helped). Then I find I can't even delete the files. This
seems to happen often. Sometimes I'll make a copy of a perfectly good
floppy and it'll come out with 2 or 3 files having that error.
Can someone explain what's going on?
-------
1-Feb-89 08:55:20-PST,739;000000000000
Return-Path: <DEBRA@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Wed 1 Feb 89 08:53:53-PST
Date: Wed, 1 Feb 89 08:53:39 PST
From: HOSTMASTER@SRI-NIC.ARPA
Subject: INTERNET.GATEWAYS file usage
Sender: DEBRA@SRI-NIC.ARPA
To: tops20@score.stanford.edu
cc: hostmaster@SRI-NIC.ARPA
Reply-To: HOSTMASTER@SRI-NIC.ARPA
Message-ID: <12467228880.41.DEBRA@SRI-NIC.ARPA>
The Network Information Center is considering discontinuing the
maintenance of the file <NETINFO>INTERNET.GATEWAYS. Before doing so,
we would like to know if that file is being utilized. Please let us
know if you are currently using this file by sending a message to
HOSTMASTER@SRI-NIC.ARPA.
-- NIC Hostmaster Staff
-------
1-Feb-89 09:54:05-PST,1121;000000000000
Return-Path: <almquist@jessica.Stanford.EDU>
Received: from jessica.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 1 Feb 89 09:53:17-PST
Received: by jessica.Stanford.EDU; Wed, 1 Feb 89 09:53:11 PST
Date: 1 Feb 1989 0953-PST (Wednesday)
From: Philip Almquist <almquist@jessica.Stanford.EDU>
To: Mark Lottor <MKL@sri-nic.arpa>
Cc: tops-20@score.Stanford.EDU
Subject: Re: FE floppy errors
In-Reply-To: Mark Lottor <MKL@SRI-NIC.ARPA> / Tue, 31 Jan 89 23:03:00 PST.
<12467121356.28.MKL@SRI-NIC.ARPA>
Mark,
I always found that FE floppies were one of the most unreliable
parts of a DEC-20...
Do you see the problem on the drive that the floppy was written
on, or only when you move it to another drive? Can you read a known
good floppy in both drives?
It sounds like you need to get your friendly DEC repairperson
to look at the problem (one of the fortunate things about having an
"obsolete" system is that the field engineers who work on such systems
seem to be much more knowledgeable than those who work on the more
modern, supposedly self-diagnosing systems).
Philip
9-Feb-89 13:50:36-PST,2015;000000000000
Return-Path: <LUM@osu-20.ircc.ohio-state.edu>
Received: from osu-20.ircc.ohio-state.edu by SCORE.STANFORD.EDU with TCP; Thu 9 Feb 89 13:48:05-PST
Date: Thu 9 Feb 89 16:46:50-EST
From: Lum Johnson <Lum@osu-20.ircc.ohio-state.edu>
Subject: Is there still a TOPS => UNIX mailing list?
To: TOPS-20@osu-20.ircc.ohio-state.edu
Message-ID: <12469379407.13.LUM@osu-20.ircc.ohio-state.edu>
From the documentation for Columbia University's port of MM for UNIX (TM):
> CCMD was announced to the public on some Internet mailing lists as well as
> at Usenix... A mailing list to discuss TOPS-20 to UNIX migration issues was
> set up (INFO-TOPSUX@CU20B.CC.COLUMBIA.EDU). (Send requests to INFO-TOPSUX-
> REQUEST@CU20B.CC.COLUMBIA.EDU.) We began using CCMD internally for various
> programs. Our operations interface, group management program etc. were all
> written using CCMD as the user interface.
Unfortunately, CU20B.CC.COLUMBIA.EDU is no longer with us, but is the mailing
list? (There is no listing in the [NIC.DDN.MIL]NETINFO:INTEREST-GROUPS*.TXT.)
If not, has anyone kept an archive of the former traffic?
(By the way, if anyone else is thinking about going that direction, let me say
that CCMD and MM-UX are _good_ stuff. I have only the pickiest complaints to
make about them. (E.g., username completion doesn't work with the Sun yellow
pages /etc/passwd stuff, at least not in our copy, ... yet. MM-UX even knows
three mailbox formats (Unix mbox, TOPS mtxt, ITS babyl) and does conversions.)
If anyone is interested, send me a reply, and I'll get and post the directions
for picking these up from tut.cis.ohio-state.edu by ftp or osu-cis by uucp.
Of course, they're probably also available at Columbia, if that's closer. :-)
[UNIX is a trademark of AT&T; TOPS-20 is a trademark of DEC; yada yada ....]
--
Lum Johnson lum@cis.ohio-state.edu lum@osu-20.ircc.ohio-state.edu
"You got it kid -- the large print giveth and the small print taketh away."
-------
16-Feb-89 15:14:26-PST,1024;000000000000
Return-Path: <munnari!charlie.cc.deakin.oz.au!ccw@uunet.UU.NET>
Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Thu 16 Feb 89 15:11:53-PST
Received: from munnari.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA04724; Thu, 16 Feb 89 18:11:41 -0500
Message-Id: <8902162311.AA04724@uunet.UU.NET>
Received: from charlie.cc.deakin.oz (via murtoa) by munnari.oz with SunIII (5.5)
id AA15923; Fri, 17 Feb 89 08:54:58 EST
(from ccw@charlie.cc.deakin.oz for uunet!tops20@score.stanford.edu)
Received: by charlie.oz (5.52)
id AA00519; Fri, 17 Feb 89 08:40:11 EST
To: tops20@score.Stanford.edu
Subject: System Wide Groups
Date: Fri, 17 Feb 89 08:41:32 +1100
From: Craig Warren <munnari!charlie.oz.au!ccw@uunet.UU.NET>
We are running a Mark Crispin version of Tops20 6.2 (4007)-4
which makes groups system wide rather than on a structure
wide basis. Has anyone modified Gidget (or have another
tool) to manipulate Groups under such an arrangement?
Craig Warren ccw%charlie.oz.au@uunet.uu.net
16-Feb-89 16:41:50-PST,813;000000000000
Return-Path: <MRC@WSMR-SIMTEL20.Army.MIL>
Received: from june.cs.washington.edu by SCORE.STANFORD.EDU with TCP; Thu 16 Feb 89 16:40:48-PST
Received: from tomobiki-cho.cac.washington.edu by june.cs.washington.edu (5.59/6.13+)
id AA24987; Thu, 16 Feb 89 16:38:48 PST
Return-Path: <MRC@WSMR-SIMTEL20.Army.MIL>
Date: Thu, 16 Feb 1989 16:39:13 PST
From: Mark Crispin <MRC@WSMR-SIMTEL20.Army.MIL>
Subject: re: System Wide Groups
To: Craig Warren <munnari!charlie.oz.au!ccw@uunet.UU.NET>
Cc: tops20@score.Stanford.edu
In-Reply-To: <8902162311.AA04724@uunet.UU.NET>
Message-Id: <MS-C.603679153.1103527590.MRC@WSMR-SIMTEL20.Army.MIL>
What Craig is talking about is the Stanford patch to make all domestic
structures have PS: user groups. Does the old Stanford GROUPE program know
about this?
-------
18-Feb-89 14:05:15-PST,623;000000000000
Return-Path: <MRC@WSMR-SIMTEL20.ARMY.MIL>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Sat 18 Feb 89 14:04:23-PST
Date: Sat, 18 Feb 89 15:04:38 MST
From: Mark Crispin <MRC@WSMR-SIMTEL20.ARMY.MIL>
Subject: 1 JAN 89 Software Dispatch fiche
To: TOPS-20@SCORE.STANFORD.EDU
Address: P.O. Box 2652; Seattle, WA 98111-2652
Message-ID: <12471741943.15.MRC@WSMR-SIMTEL20.ARMY.MIL>
Did anyone other than me notice that the so-called 1 JAN 89 DECSYSTEM-20
Software Dispatch fiche is really for the 10? I wonder if the 10 folks
got our fiche...anybody in 10 land out there wanna trade?
-------
19-Feb-89 14:33:54-PST,1779;000000000000
Return-Path: <MRC@WSMR-SIMTEL20.ARMY.MIL>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Sun 19 Feb 89 14:33:00-PST
Date: Sun, 19 Feb 89 15:33:15 MST
From: Mark Crispin <MRC@WSMR-SIMTEL20.ARMY.MIL>
Subject: 25 years of 36-bit computing
To: TOPS-20@SCORE.STANFORD.EDU
Address: P.O. Box 2652; Seattle, WA 98111-2652
Message-ID: <12472009295.10.MRC@WSMR-SIMTEL20.ARMY.MIL>
I had just recently unpacked my 3/4" videotapes of the 36-Bit Trivia
Bowl and the 36-Bit Pioneer's Roundtable that were held at Disneyland
DECUS in the fall of 1984. After playing these tapes and going through
some nostalgia, I was reminded that this year is the 25th year of 36-bit
computing.
Amazingly, some of us are still around. There is reason to hope that
PANDA will arise from the dead sometime this spring. By that time it will
have been a year since LCG was declared dead & buried. Although KL systems
are dropping off like flies, some KL's are still going strong and hacker-
owned KS systems like PANDA are springing up like mushrooms. There's even
talk of building an SCSI controller for the 2020 so we can use modern
peripherals...
I would therefore like to call for a Penultimate, 25th Anniversary of
36-Bit Computing celebration, to be held at Disneyland DECUS this fall.
This will probably be the last such get-together ever; who knows if any of
us will be around for the 50th?
What do you think?
-- Mark --
PS: As for memorabilia, I have a bag full of KA-10 adder boards (a truly
amazing circuit, as memorable as the 6502 on the PDP-6) to trade, and I
would *kill* for a KI-10 front panel. It'd also be great if someone could
find a machine-readable copy of the first PDP-6 system sources!!
-------
20-Feb-89 12:42:01-PST,2705;000000000000
Return-Path: <DBigelow@EAGLE.WESLEYAN.EDU>
Received: from EAGLE.WESLEYAN.EDU by SCORE.STANFORD.EDU with TCP; Mon 20 Feb 89 12:35:55-PST
Date: 20-FEB-1989 14:51:31.97
From: Douglas Bigelow <DBigelow@EAGLE.WESLEYAN.EDU>
Subject: Tops20 Version 7.0
To: TOPS20@Score.Stanford.EDU
Well, four years after I froze the software on our DEC-2060s, I'm
considering a hardware and software upgrade... I never thought I'd see the
day.
Our remaining 20 is running a 5.4 monitor and is running TCP/IP via an NI.
It's an administrative machine and has probably five years of life ahead as
large data processing applications (mostly 1022) are converted one by one to
VAX/VMS architecture and System 1032.
In order to improve the networking environment necessary to transport ever-
larger applications from this system to a VAXcluster, I'm considering
upgrading 5.4 to 7.0, adding DECnet, converting serial port connections to
LAT connections, and generally improving the TCP/IP environment. (Our
current TCP/IP software seems to have trouble dealing with some of the
broadcast packet types on our Ethernet, mainly those types which didn't
exist several years back.) In order to support the monitor change, I'd
also purchase a cache upgrade.
What I need from this group is some information. I'm long out of date in
software and need to know what tapes and floppies I'd need to have to pull
this off. The ones I've figured out are:
BB-H137F-BM Installation (16MT9)
BB-H138F-BM Distribution 1/2
BB-LW55A-BM " 2/2
BB-M836D-BM Tools
BB-KL11F-BM Autopatch 1-19
BB-L014T-BM " 20
However, as a source site (with unfortunately *many* monitor and exec
patches) I'd also need the monitor and exec and tcp/ip source tapes, and
the TCP/IP binary tape. Also front end floppies, microcode, etc...
We've got an NI-20, no AN-20, no CI-20, no RP20...
Can someone fill me in about what I would need, preferably with the tape
numbers?
No guarantees that I'll do it, because it may turn out to be too much
work. My days as a systems programmer are long behind me, but I'd have
no choice but to do most of the work myself. The systems team here is
almost all VAX oriented. Any comments on the difficulties in moving from
5.4 to 7.0 would be appreciated!
Doug Bigelow
Director of Academic Computing @ Wesleyan
PS --
Are there others out there who expect to keep 20s around for five
years or more? I'm talking about a heavy production environment, not
just casual use. If so, what are your field service plans? Our field
service people have been telling us (unofficially) not to expect DEC
service to be available after 1992.
21-Feb-89 07:36:03-PST,759;000000000000
Return-Path: <MRC@WSMR-SIMTEL20.ARMY.MIL>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 07:33:01-PST
Date: Mon, 20 Feb 89 19:16:00 MST
From: Mark Crispin <MRC@WSMR-SIMTEL20.ARMY.MIL>
Subject: setting MAXTCB higher than 50
To: TOPS-20@SCORE.STANFORD.EDU
Address: P.O. Box 2652; Seattle, WA 98111-2652
Message-ID: <12472311990.8.MRC@WSMR-SIMTEL20.ARMY.MIL>
If you set MAXTCB higher than 50 (not unreasonable in this day and age)
then the calculation of NTWBTS generates a warning. Apparently each TCB
can grab 10 wait bits, but the total number must fit in a 9 bit field.
Is this an excessively conservative calculation? Has anyone expanded
the fields in question so there can be more wait bits?
-------
21-Feb-89 10:24:47-PST,981;000000000000
Return-Path: <HFRIEDMAN@VX1.GBA.NYU.EDU>
Received: from VX1.GBA.NYU.EDU ([128.122.130.83].#Internet) by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 10:23:06-PST
Date: Tue 21 Feb 89 13:21:42-EST
From: Howie Friedman <HFRIEDMAN@VX1.GBA.NYU.EDU>
Subject: TOPS-20 Core Dump mode
To: tops-20@score.stanford.edu
Message-ID: <604088502.0.HFRIEDMAN@VX1.GBA.NYU.EDU>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(132)+PONY(228)@VX1.GBA.NYU.EDU>
I have a tape utility that I have written for the Vax environment and
am trying to add support for tapes writtten using the DEC20 Core
Dump tape mode.
I have followed the record layout described in the TOPS-20 Tape
Processing Manual but have need been successful.
If you could provide me with a description of how to map each set
of 5 bytes (8 bit) that represent 5 (7 bit) bytes into ascii, I
would be most greatful.
Thank you, in advance, for your time. Have a pleasant day.
===> Howard <===
-------
21-Feb-89 12:29:49-PST,1343;000000000000
Return-Path: <BILLW@MATHOM.CISCO.COM>
Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 12:28:35-PST
Date: Tue 21 Feb 89 12:28:57-PST
From: William Westfield <BILLW@MATHOM.CISCO.COM>
Subject: Re: setting MAXTCB higher than 50
To: MRC@SIMTEL20.ARPA
cc: TOPS-20@SCORE.STANFORD.EDU
In-Reply-To: <12472311990.8.MRC@WSMR-SIMTEL20.ARMY.MIL>
Message-ID: <12472510956.37.BILLW@MATHOM.CISCO.COM>
If you set MAXTCB higher than 50 (not unreasonable in this day and age)
then the calculation of NTWBTS generates a warning. Apparently each TCB
can grab 10 wait bits, but the total number must fit in a 9 bit field.
Is this an excessively conservative calculation? Has anyone expanded
the fields in question so there can be more wait bits?
The calculation is excessively conservative. TVTs, for example, use far
fewer wait bits (3, I think). In a large system, you can expect a lot
of your connections to be TVTs. Both cisco and Stanford have monitors
with MAXTCB > 50. The code seems to do the right thing if there are no
wait bits available (ie, you wait for wait bits...), though I have never
seen this happen. Expanding the fields in question would be a bitch - they
are used as arguments to scheduler tests, and they want to get two in 18 bits.
Bill Westfield
-------
22-Feb-89 19:55:01-PST,1330;000000000000
Return-Path: <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 19:54:12-PST
Date: Wed, 22 Feb 1989 20:51 MST
Message-ID: <WANCHO.12472853731.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@SCORE.STANFORD.EDU
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: Bug fix for FTPSRT
Problem: Wrong error message displayed for File not found case.
Diagnosis: In Edit 42, RETX1/RETX5 was modified to display the
filename in the error message using JFNS%. However, on a GTJFN%
error, there is no valid JFN for JFNS% to use and the JFNS% itself
will fail. The JFNS% error message (DESX4) is then displayed instead
of the original GTJFN%, normally GJFX4.
Cure:
1. At RET02B+13d, i.e., just below the GTFDB%, replace the ERJMP RETX1
with ERJMP RETX5.
2. At RETX1:, insert:
JSP X,ERRMSG ; GTJFN failed
ASCIZS (450,550,< File not accessable. >)
Comment: This problem was not previously detected because testing
a GET of a non-existent file from another TOPS20 system causes a STAT
filename to be sent first. STAT will properly return "? Not found."
However, other user ftp programs, such as found on Unix systems, will
directly issue the RETR filename without a prior STAT.
--Frank
23-Feb-89 13:33:51-PST,516;000000000000
Return-Path: <MKL@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 13:31:50-PST
Date: Thu, 23 Feb 89 13:19:54 PST
From: Mark Lottor <MKL@SRI-NIC.ARPA>
Subject: multiple internet address on same interface
To: tops-20@score.stanford.edu
Message-ID: <12473044520.32.MKL@SRI-NIC.ARPA>
Has anyone tried running and ethernet interface with more than
one internet address assigned to it? Is this possible or are
mods needed? Any idea how difficult it would be?
-------
27-Feb-89 12:49:43-PST,1206;000000000000
Return-Path: <A.ALDERSON@MACBETH.STANFORD.EDU>
Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 12:45:16-PST
Date: Mon 27 Feb 89 12:42:28-PST
From: Rich Alderson <A.ALDERSON@MACBETH.STANFORD.EDU>
Subject: Spring DECUS and 36-bit systems
To: tops-20@SCORE.STANFORD.EDU
Message-ID: <12474086281.22.A.ALDERSON@MACBETH.STANFORD.EDU>
Those who are looking for the Tops-10/Tops-20 Update session in Atlanta should
note that it is being sponsored by the Site Management and Training SIG. It is
scheduled to take place Monday evening from 5:00 till 6:30. Dave Braithwaite
asked for a single 90-minute session to cover both product lines since most
people who still have 36-bit systems won't mind a little cross-over.
With the demise of the Large Systems SIG (which became a SIC last spring in
Cleveland and disbanded in December), it was thought that Site Management &
Training was the appropriate place for a 36-bit Working Group. The folks there
agreed to take us on.
Furthers details will be published here as they become available.
I hope to see all of you in Atlanta.
Rich Alderson
Academic Information Resources
Stanford University
-------
2-Mar-89 09:12:56-PST,1711;000000000000
Return-Path: <076RONAN%VAX.LIVPOL.AC.UK@Forsythe.Stanford.EDU>
Received: from Forsythe.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 2 Mar 89 09:11:32-PST
Received: by Forsythe.Stanford.EDU; Thu, 2 Mar 89 09:10:30 PST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 6532; Thu,
02 Mar 89 16:59:51 GMT
Received:
Via: UK.AC.LIVPOL.VAX; 2 MAR 89 16:59:47 GMT
Date: 2-MAR-1989 17:01:13
From: 076RONAN%VAX.LIVERPOOL-POLY.AC.UK@Forsythe.Stanford.EDU
To: TOPS-20@SCORE.STANFORD.EDU
Subject: Can TCP/IP-20 run together with LAT/DECnet over the NIA20?
Sender: JANET "076RONAN@UK.AC.LIVPOL.VAX" <076RONAN%VAX.LIVPOL.AC.UK@Forsythe.Stanford.EDU>
Originally-to: EARN%"tops-20@edu.stanford.score",076RONAN
Mailer: Janet_Mailshr V3.1 (19-Aug-1988)
Name: Ronan P. Flood, Senior Computing Officer (systems)
Address: Liverpool Polytechnic, Computer Services Department,
Byrom Street, Liverpool, L3 3AF, U.K
Telephone: (051) 207-3581 extension 2101
We are considering running DEC's TCP/IP-20 4.0 on an NIA20 for incoming
TELNET terminal connection. The incoming TELNET connections would come
from a terminal server, but we may later have a requirement for
both-way TELNET/FTP/etc. to Unix machines. However, we must also be able
to support DECnet and LAT, (DECSERVER-100/200s), on the NI. We want to
know if anyone out there has tried simultaneous TELNET/DECnet/LAT on an
NI, and if it works, or has been proven not to work.
Thanks,
Ronan Flood.
Internet: 076RONAN@VAX.LIVPOL.AC.UK
or 076RONAN%VAX.LIVPOL.AC.UK@MITVMA.MIT.EDU
2-Mar-89 10:23:44-PST,889;000000000000
Return-Path: <RASPUZZI@TOPS20.DEC.COM>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Thu 2 Mar 89 10:22:21-PST
Date: 2 Mar 1989 1320-EST
From: "Michael Raspuzzi" <RASPUZZI@THEP.MRNET>
To: 076RONAN%VAX.LIVERPOOL-POLY.AC.UK@Forsythe.Stanford.EDU
cc: TOPS-20@SCORE.STANFORD.EDU
Loc/MS: "MRO1-2/L14 (Pole KL21)"
Phone: "DTN 297-2346 (508-467-2346)"
Subject: Re: Can TCP/IP-20 run together with LAT/DECnet over the NIA20?
Message-ID: <"MS11(6044)+GLXLIB6(0)" 12474846888.210.61.187806 at THEP.MRNET>
References: Message from 076RONAN%VAX.LIVERPOOL-POLY.AC.UK@Forsythe.Stanford.EDU
of 2-Mar-89 1234-EST
Ronan,
You can run DECnet/LAT/TCP all through the NIA20 at the same time
and it is supported. We run machines in house that have all 3 going
at the same time.
Mike Raspuzzi
TOPS-20 Monitor Group
Marlboro, MA
--------
2-Mar-89 11:36:43-PST,569;000000000000
Mail-From: GROSSMAN created at 2-Mar-89 11:34:41
Date: Thu 2 Mar 89 11:34:41-PST
From: Stu Grossman <GROSSMAN@Score.Stanford.EDU>
Subject: Re: Can TCP/IP-20 run together with LAT/DECnet over the NIA20?
To: 076RONAN%VAX.LIVERPOOL-POLY.AC.UK@forsythe.Stanford.EDU
cc: TOPS-20@Score.Stanford.EDU
In-Reply-To: Message from "076RONAN%VAX.LIVERPOOL-POLY.AC.UK@Forsythe.Stanford.EDU" of Thu 2 Mar 89 17:01:13-PST
Message-ID: <12474860374.14.GROSSMAN@Score.Stanford.EDU>
We ran just such a configuration at DEC, and it worked quite well.
Stu Grossman
-------
3-Mar-89 08:27:21-PST,487;000000000000
Return-Path: <RAD@VAX01.AMS.COM>
Received: from VAX01.AMS.COM by SCORE.STANFORD.EDU with TCP; Fri 3 Mar 89 08:26:34-PST
Date: Fri 3 Mar 89 11:03:55-EST
From: "Rich DeJordy, x295" <RAD@VAX01.AMS.COM>
Subject: RE: Can TOPS/IP-20 run together with LAT/DECnet over the
NIA20?
To: tops-20@SCORE.STANFORD.EDU
Yes, we too are running all these protocols over our NIs on the two 20s that
we have here. It works quite well.
Rich DeJordy
American Mathematical Society
-------
3-Mar-89 16:27:29-PST,1303;000000000000
Return-Path: <SRA@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Mar 89 16:25:14-PST
Date: Fri, 3 Mar 1989 19:22 EST
Message-ID: <SRA.12475174961.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Bug-CHIVES@XX.LCS.MIT.EDU, TOPS-20@SCORE.STANFORD.EDU
Subject: Updates to CHIVES (domain resolver) software
Reply-To: Bug-CHIVES@LCS.MIT.EDU
Some recent work turned up several memory leaks, which have been
plugged. There are a few new source modules in XX:<CHIVES.V1.SOURCE>.
Sites running CHIVES should update their sources and recompile.
No monitor changes are necessary, these are just fixes to the user
context resolver daemon. If you have trouble FTPing to XX, make sure
you're not trying to use XX's ARPANET address (the AN20 is dead),
instead use [18.26.0.36].
For those who are interested, XX has been running without any IP host
tables for a week or so now, without any known problems. We removed
the boot-time HSTINI call and made the GTHST% JSYS into an alias for
GTDOM%. A few programs (notably SYSDPY) needed a little work to cope
with the change, but all in all it went quite smoothly, even programs
like TECO/EMACS/BABYL are happy.
Comments, bug reports, etc to BUG-CHIVES@LCS.MIT.EDU, as usual.
--Rob
17-Mar-89 05:46:53-PST,2120;000000000000
Return-Path: <@po3.andrew.cmu.edu:cy13+@andrew.cmu.edu>
Received: from po3.andrew.cmu.edu by SCORE.STANFORD.EDU with TCP; Fri 17 Mar 89 05:44:48-PST
Received: by po3.andrew.cmu.edu (5.54/3.15) id <AA02452> for tops-20@score.stanford.edu; Fri, 17 Mar 89 08:44:39 EST
Received: via switchmail; Fri, 17 Mar 89 08:44:35 -0500 (EST)
Received: from unix9.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q005/QF.kY8EhSy00WB:E0QGJc>;
Fri, 17 Mar 89 08:42:55 -0500 (EST)
Received: from unix9.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr9/cy13/.Outgoing/QF.0Y8EhKy00WB:R45Ehi>;
Fri, 17 Mar 89 08:42:46 -0500 (EST)
Received: from VUI.Andrew.3.20.CUILIB.3.45.SNAP.NOT.LINKED.unix9.andrew.cmu.edu.vax.22
via MS.5.6.unix9.andrew.cmu.edu.vax_22;
Fri, 17 Mar 89 08:42:46 -0500 (EST)
Message-Id: <cY8EhKy00WB-F45EYp@andrew.cmu.edu>
Date: Fri, 17 Mar 89 08:42:46 -0500 (EST)
From: "Curtis P. Yeske" <cy13+@andrew.cmu.edu>
To: tops-20@score.stanford.edu
Subject: T20 Cycles
Cc: Farhat Lakhavani <fl08+@andrew.cmu.edu>,
GSIA-BBs <gsiabb+computing.group.staff@andrew.cmu.edu>
The Graduate School of Industrial Administration here at Carnegie Mellon
needs some Tops-20 cycles to run a fortran program. This program contains
the Management Game for the school. We need one account and 60 userid's.
This program would start in the fall of 89 semester and probably would
not continue. The preferred (but not critical) method of communication would
be telnet for up to 10 users at a time. If you know of any good commercial
places to go for these cycles, please let me know. If you know of any
nonprofit organizations who would be interested in hard currency, also let me
know.
As I no longer get this list, please reply directly to me.
Thank you for your time and consideration,
Curt Yeske
Hardware Software Coordinator
GSIA Computing
Carnegie Mellon
cy13@andrew.cmu.edu
(412) 268-3091
P.S. Sorry about the line wrap but Andrew is really brain damaged.
(Not the opinion of any other than myself [ha!])
17-Mar-89 11:45:26-PST,830;000000000000
Return-Path: <WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU>
Received: from tut.cis.ohio-state.edu by SCORE.STANFORD.EDU with TCP; Fri 17 Mar 89 11:43:59-PST
Received: from osu-20.ircc.ohio-state.edu by tut.cis.ohio-state.edu (5.61/3.890314)
id AA23347; Fri, 17 Mar 89 14:43:53 -0500
Message-Id: <8903171943.AA23347@tut.cis.ohio-state.edu>
Date: Fri 17 Mar 89 14:42:29-EST
From: Sandra Wambold <WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU>
Subject: LaTeX -> PostScript
To: tops-20@OSU-20.IRCC.OHIO-STATE.EDU
Does anyone have a program to convert LaTeX DVI files to PostScript format?
------------------------------------------------------------------------------
Sandra Wambold, Student Operator P.O. BOX 3056, Columbus, OH 43210
WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU The Ohio State University's DEC-SYSTEM 2060
-------
22-Mar-89 16:42:24-PST,1668;000000000000
Return-Path: <DBigelow@EAGLE.WESLEYAN.EDU>
Received: from EAGLE.WESLEYAN.EDU by SCORE.STANFORD.EDU with TCP; Wed 22 Mar 89 16:40:25-PST
Date: 22-MAR-1989 19:39:34.07
From: Douglas Bigelow <DBigelow@EAGLE.WESLEYAN.EDU>
Subject: Help!
To: Tops20@Score.Stanford.EDU
Due to an unfortunate combination of accident and carelessness, we've
managed to damage the floppies containing both our working and original
copies of RSX20F version 15-15. Since we're running a 5.4 monitor with an
old front end and microcode, two sites I asked directly have long since
upgraded and trashed their old front end floppies. Hence, a widespread
appeal:
Does anyone have the following floppies that they would be willing to copy
for me?
AS-M329D-BM TOPS-20 RSX20F V15-15 FLP A
AS-M330D-BM TOPS-20 RSX20F V15-15 FLP B
Our "A" floppy is the damaged one, specifically. We're also running
microcode version 357, which if I recall correctly was the default version
supplied with that release.
If any good samaritan would be willing to dig up and copy those floppies
for me, I will be happy to mail you blank floppies and a stamped,
self-addressed mailer. Or I can just provide the account number for a
"collect" Federal Express mailing. I also promise eternal gratitude.
I will much appreciate help -- not only do I not have the floppies, but I
don't have a spare RP06 with a front-end file system installed. If we have
any sort of disk disaster, I dread to think of how long we'll be down
before sorting out the problems.
Thanks!
Doug Bigelow
Director of Academic Computing @ Wesleyan, and former systems programmer
in the good ol' days.
24-Mar-89 12:15:29-PST,690;000000000000
Return-Path: <DBigelow@EAGLE.WESLEYAN.EDU>
Received: from EAGLE.WESLEYAN.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Mar 89 12:13:07-PST
Date: 24-MAR-1989 15:12:18.52
From: Douglas Bigelow <DBigelow@EAGLE.WESLEYAN.EDU>
Subject: Help received
To: tops20@score.stanford.EDU
All,
I got an immediate response from several people offering to send me the
RSX 15-15 floppies, two of them coming in in ten minutes (in the evening
yet.) I took up the first offerer, Joe Dempster, and the floppies are now
sitting on my desk in front of me. Now I can sleep again at night.
The flood of responses was much appreciated! I guess the TOPS20 spirit
still lives on strong...
Doug
28-Mar-89 09:20:06-PST,1839;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 28 Mar 89 09:17:20-PST
Date: Tue 28 Mar 89 11:11:12-CST
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: Network Questions
To: tops20@score.stanford.edu
Message-ID: <12481649995.26.AI.CLIVE@MCC.COM>
MCC.COM is in the middle of switching from the ARPANET to NSFNET, and
I have several questions about things which might be done to smooth
this transition. I've requested that our 10.3.0.62 address be removed
from the root domain servers, the NIC host tables, etc. (The address
has been listed second after our 128.62.11.10 address for several
months now, but this doesn't mean much.) My plan is to keep the PSN
connection up for at least several more days to give this change a
chance to propagate as much as possible. What I would like to have
happen is for the 20 never to send anything out on the PSN interface,
but be able to receive stuff from it. Outgoing packets for such
connections would go out via our ethernet interface and NSFNET.
Questions:
1. Even though our 128.62.11.10 address is DEFAULT,PREFERED
in the <SYSTEM>INTERNET.ADDRESS file, and even though
I've modified INTERNET.GATEWAYS to force most everything out
through our NSFNET gateway, I believe it is the case that
outgoing packets with a destination on net 10 will still
go out via the PSN. If I remove the AN20 line completely
from the <SYSTEM>INTERNET.ADDRESS file, will this have the
effect I want, i.e. making the AN20 an input-only interface?
Or would this disable it completely?
2. Can anybody suggest a reasonable method for tracing the
incoming stuff on the AN20 interface so that I can get
an idea of the hosts that still don't know about the change?
Thanks,
Clive
-------
28-Mar-89 09:56:01-PST,642;000000000000
Return-Path: <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Tue 28 Mar 89 09:54:29-PST
Date: Tue, 28 Mar 1989 10:53 MST
Message-ID: <WANCHO.12481657681.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@SCORE.STANFORD.EDU
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: Functional Descriptions wanted
If you have a copy of the functional/technical descriptions for an
NIA20-AA/FP and/or an RP07-C, please contact me. Both the local DEC
office and Digital's Electronic Store don't seem to have them any
more.
Thanks,
Frank
30-Mar-89 10:03:11-PST,735;000000000000
Return-Path: <A.ALDERSON@MACBETH.STANFORD.EDU>
Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 30 Mar 89 10:00:29-PST
Date: Thu 30 Mar 89 09:59:51-PST
From: Rich Alderson <A.ALDERSON@MACBETH.STANFORD.EDU>
Subject: Public-domain TCP/IP code
To: tops-20@SCORE.STANFORD.EDU
Message-ID: <12482183141.144.A.ALDERSON@MACBETH.STANFORD.EDU>
An acquaintance has asked me about Tops-20 TCP/IP implementations in the public
domain. The reason for the question is that she has heard (as have I) that the
DEC-supported code has problems with Class-B networks. Can anyone refute this?
Or provide a pointer to code that doesn't have the problem? Or both?
Rich Alderson
Alderson@Score.Stanford.EDU
-------
30-Mar-89 10:15:30-PST,746;000000000000
Mail-From: VAF created at 30-Mar-89 10:15:16
Date: Thu 30 Mar 89 10:15:16-PST
From: Vince Fuller <VAF@Score.Stanford.EDU>
Subject: Re: Public-domain TCP/IP code
To: A.ALDERSON@Macbeth.Stanford.EDU
cc: tops-20@Score.Stanford.EDU
In-Reply-To: <12482183141.144.A.ALDERSON@MACBETH.STANFORD.EDU>
Office: Pine Hall 167
Phone: 415-723-6860
Message-ID: <12482185946.34.VAF@Score.Stanford.EDU>
That's a little surprising to me. We ran a TOPS-20 at CMU on a class-B network
for quite a while without any sort of "Class-B problems". We ran the DEC TCP
release for a while (about a year) and then switched to the BBN TOPS-20 TCP
(which I would recommend using, if you can get it and can afford the time to
install it).
--Vince
-------
31-Mar-89 06:26:45-PST,628;000000000000
Return-Path: <RAD@MATH.AMS.COM>
Received: from MATH.AMS.COM by SCORE.STANFORD.EDU with TCP; Fri 31 Mar 89 06:25:50-PST
Date: Fri 31 Mar 89 09:23:44-EST
From: "Rich DeJordy, x295" <RAD@math.ams.com>
Subject: TOPS-20 and Class B addresses.
To: tops-20@SCORE.STANFORD.EDU
We are running the DEC TCP/IP Monitor our both of our 20 with a Class B
address. The 20s are able to communicate over TCP/IP with no problems,
though we don't do much in the way of subnetting. (I do remember some
question with the @0s being able to handle subnetting, though.)
Rich DeJordy
American Math Society
RAD@MATH.AMS.COM
-------
4-Apr-89 20:09:52-PDT,1827;000000000000
Return-Path: <MKL@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Tue 4 Apr 89 20:07:53-PDT
Date: Tue, 4 Apr 89 20:07:47 PDT
From: Mark Lottor <MKL@SRI-NIC.ARPA>
Subject: more ipfree space problems
To: tops-20@score.stanford.edu
Message-ID: <12483593609.21.MKL@SRI-NIC.ARPA>
A while back I posted a bugchk fix that tested to see if a full-size
packet being returned to RETPKT in IPIPIP was the length a full-size
packet was supposed to be. It tested the length against the word
MAXWPM. That fix got rid of almost all our IPFREE space bugs, up until
a few weeks ago when they started appearing again.
I noticed buffers being trashed by packets that were just a bit too
long. I then noticed my bugchk fix wasn't quite checking the right
value. Its should be testing against INTXPW instead of MAXWPM.
MAXWPM is slightly lower than INTXPW and a few bogus buffers were
slipping thru. After fixing it I found the source of the bogus
buffers. In the Stanford IPFREE space module, routine GETNIB gets a
buffer of size MAXWPM instead of INTXPW. Fixing that seems to have
gotten rid of that source of bogons. (I think there is still one
problem left somewhere, in the ICMP routines, but it's very infrequent
and the BUGCHK catches them).
This bug wouldn't have normally appeared unless full-size Ethernet
packets were being used. Most systems don't use the whole packet.
Until SunOS 4.0 arrived. NFS was changed to use all 1500 bytes
instead of just 1024 as in SunOS 3.x. While going thru a crash
dump I found an NFS 'write to file' packet, from a Sun workstation
to its file server. Why was it on the 20??? I have no idea. I
doubt it was a broadcast. My only guess is that the NI gets
confused sometimes and read packets that aren't addressed to it.
-------
6-Apr-89 14:13:46-PDT,1145;000000000000
Return-Path: <DLynch.SysAdmin@MULTICS.RADC.AF.MIL>
Received: from MULTICS.RADC.AF.MIL by SCORE.STANFORD.EDU with TCP; Thu 6 Apr 89 14:10:47-PDT
Date: Thu, 6 Apr 89 17:00 EDT
From: DLynch@MULTICS.RADC.AF.MIL
Subject: domain server
To: tops20@SCORE.STANFORD.EDU
cc: DLynch@MULTICS.RADC.AF.MIL, admin@TOPS20.RADC.AF.MIL
Message-ID: <890406210053.789755@MULTICS.RADC.AF.MIL>
As you might know we are running a domain server RADC.AF.MIL under 5.4.
The server seems to be answering requests, except it wont talk to our
secondary server to let them do a dump. Seems the secondary servers
try to talk on port 53. They get a 'connection refused' error. We
apparently are not listening on that port at all.
Can anyone tell me what I am doing wrong? Unless DSVCTL is listening,
I am not doing anything in sysjob or to netsrv or anything.
Please help.
--Donna
P.S. Please respond to both
admin -at tops20.radc.af.mil and to
DLynch -at multics.radc.af.mil
I could not reach score.stanford.edu from the DEC20, so I am sending this
from multics. The DEC20 will be down from 1700-2000 EST besides.
6-Apr-89 14:46:31-PDT,856;000000000000
Return-Path: <SRA@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 6 Apr 89 14:46:07-PDT
Date: Thu, 6 Apr 1989 17:46 EDT
Message-ID: <SRA.12484059355.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: admin@TOPS20.RADC.AF.MIL, DLynch@MULTICS.RADC.AF.MIL
Cc: tops20@SCORE.STANFORD.EDU
Subject: domain server
In-reply-to: Msg of 6 Apr 1989 17:00-EDT from DLynch@MULTICS.RADC.AF.MIL
The JEEVES name server doens't support TCP, only UDP. Nothing you can
do about it unless you want to write the code.
Everybody who's using this code uses FTP to ship the files between the
servers. This is usually more reliable anyway, since it insures a
disk copy of the master files at each server, so that the secondary
servers can boot when the primary is down, which is sort of the point.
--Rob
20-Apr-89 06:30:07-PDT,1655;000000000000
Return-Path: <ADMIN@TOPS20.RADC.AF.MIL>
Received: from TOPS20.RADC.AF.MIL by SCORE.STANFORD.EDU with TCP; Thu 20 Apr 89 06:25:50-PDT
Date: Thu 20 Apr 89 09:26:20-EST
From: Donna Lynch <ADMIN@TOPS20.RADC.AF.MIL>
Subject: PS: question, bad .ENC files
To: tops20@SCORE.STANFORD.EDU
Message-ID: <12487649296.12.ADMIN@TOPS20.RADC.AF.MIL>
The TCP source files (*.ENC) that came with version 7 autopatch 20 and 21
are garbage. DEC encrypted the files so well they cant be decrypted. They
are sending me new tapes. I dont know when they will be sending out replacement
tapes. You might want to request it if you will be needing them soon.
A question. I have a PS: structure from version 5.4. I now want to go to
version 7 which requires me to build a new pack (PUBLIC:), since the front end
files are different.
I dont want to destroy PS: in case we have to go back to 5.4. I dont want to
copy all the files to PUBLIC: for the same reason. Files would be lost.
I want to boot from PUBLIC: but have the users use PS:. The questions:
- Is it possible to boot from PUBLIC with PS: online?
- Or can I change the name of PS: (to PS1:) without destroying the pack?
- Or can I mount PS: with an alias of PS1: just like any other disk pack
when the system is coming up?
- Is there a reason why I wouldnt want to do this?
I was able to boot V7 on PUBLIC: with PS offline. Then mounted PS: afterwards.
But what happens if the system crashes?
I am kind of leery of trying things, I never know when TOPS20 will want to
write to PS:. I dont want to destroy PS: while I am 'playing' around.
--Donna
-------
20-Apr-89 10:07:28-PDT,2091;000000000000
Return-Path: <PAUL@ELINOR.LYSATOR.LIU.SE>
Received: from KICKI.STACKEN.KTH.SE by SCORE.STANFORD.EDU with TCP; Thu 20 Apr 89 10:05:52-PDT
Return-Path: <PAUL@ELINOR.LYSATOR.LIU.SE>
Received: from ELINOR.LYSATOR.LIU.SE by KICKI.STACKEN.KTH.SE; Thu, 20 Apr 89 19:05:15 +0200
Date: Thu, 20 Apr 89 19:03:40 O
From: Paul Svensson <PAUL@ELINOR.LYSATOR.LIU.SE>
To: KS-owner@kicki.stacken.kth.se, Tops20@score.stanford.edu
cc: sysop@ELINOR.LYSATOR.LIU.SE
Subject: BUGHLT KPALVH when doing ^ESEND *
Message-ID: <12487710705.12.PAUL@ELINOR>
Help!
We're running the PANDA 4.2 monitor with decnet phase IV on a DUP11,
and we're dying with BUGHLT KPALVH at address 4232 almost every time we
try to broadcast a message with ^Esend *. The broadcast gets delivered
alright, but after that we're zapped.
It's a mess to boot, too, we get the same BUGHLT when doing a manual
boot, sometimes just before asking for date and time, sometimes just
after. It then continues with autoboot, saying ?FIL NOT FND directly
after USR MOD. As I read the docs, this should mean that boot cannot
find <system>monitr.exe, but I must be mistaken, the machine boots just
fine after that. (Well, after we removed the [System in operation]
broadcast...)
Although we can keep the machine up, and it seems to bee running fine,
it's a bit painful; we cannot even shutdown nicely if we need to, since
we get hanged broadcasting the [System going down ...] message.
It also seems as we're sometimes dropping messages sent to explicit
ttys (only decnet ttys ??). There might be some connection there, we
have no problem running 4.1, without decnet.
Any help, suggestions or pointers to what may be the problem or how to
fix it (without the source, which we have not) are welcome. Please
don't hesitate to tell me I'm beeing silly and there is no problem, or
to point me at a rediculously simple solution. None of us around here
are very familiar with Tops20/KS10, we haven't been running it for more
than three weeks, so we might just be overlooking something.
/Paul
-------
20-Apr-89 14:26:57-PDT,860;000000000000
Return-Path: <praetorius%warlok.DEC@decwrl.dec.com>
Received: from decwrl.dec.com by SCORE.STANFORD.EDU with TCP; Thu 20 Apr 89 14:26:28-PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15848; Thu, 20 Apr 89 14:27:56 PDT
Date: Thu, 20 Apr 89 14:27:56 PDT
Message-Id: <8904202127.AA15848@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for tops20@score.stanford.edu; id AA15848; Thu, 20 Apr 89 14:27:56 PDT
From: praetorius%warlok.DEC@decwrl.dec.com
To: tops20@score.stanford.edu
Subject: Hope
========
Date: 20 Apr 1989 1523-MDT
From: PRAETORIUS@WARLOK
To: "tops20@SCORE.STANFORD.EDU"@DECWRL
Subject: Hope
Message-ID: <"MS11(6046)+GLXLIB6(0)" 12487725255.83.204.5826 at WARLOK>
Does anybody out there still have a copy of Edinburgh U.'s Hope
interpreter for the PDP-10?
RP
--------
24-Apr-89 18:31:26-PDT,1075;000000000000
Return-Path: <ADMIN@TOPS20.RADC.AF.MIL>
Received: from TOPS20.RADC.AF.MIL by SCORE.STANFORD.EDU with TCP; Mon 24 Apr 89 18:29:45-PDT
Date: Mon 24 Apr 89 21:30:27-EST
From: Donna Lynch <ADMIN@TOPS20.RADC.AF.MIL>
Subject: Version 7 and FTP
To: tops20@SCORE.STANFORD.EDU
cc: admin@TOPS20.RADC.AF.MIL
Message-ID: <12488829693.10.ADMIN@TOPS20.RADC.AF.MIL>
I finally have version 7 running with no monitor changes. However, I cant
FTP to the DEC20. I get the following error:
< Fatal system error at at 5350 Invalid structure name.
% Garbage at end of TELNET connection
?Connection closed by remote host
If I DDT and look at location 5350 it shows:
5350/ ther
h.eol#+107/ machine This is a currently useful only for Pup ...
This is the same FTP.EXE.299, the same I ran under version 5.4,
FTP Version 3(302).
And another question, how can you load new hosts tables with the system
up. I tried using IPHOST, but it tells me the table is full, which I
know isnt true, I dont get an error when I boot.
Thanks for your help,
Donna
-------
25-Apr-89 07:09:12-PDT,667;000000000000
Return-Path: <ADMIN@TOPS20.RADC.AF.MIL>
Received: from TOPS20.RADC.AF.MIL by SCORE.STANFORD.EDU with TCP; Tue 25 Apr 89 07:07:28-PDT
Date: Tue 25 Apr 89 10:08:02-EST
From: Donna Lynch <ADMIN@TOPS20.RADC.AF.MIL>
Subject: FTP is okay
To: tops20@SCORE.STANFORD.EDU
cc: admin@TOPS20.RADC.AF.MIL
Message-ID: <12488967606.9.ADMIN@TOPS20.RADC.AF.MIL>
I dont know what it was but FTP is fine now. I know when I was restructuring
everything I forgot to put FTPSER where it was supposed to be. But after I
realized it I restarted NETSRV, which didnt help. I even rebooted.
But this morning everything is fine.
Sorry to have bothered you.
Donna
-------
25-Apr-89 10:10:52-PDT,652;000000000000
Return-Path: <A.ALDERSON@Hamlet.Stanford.EDU>
Received: from Hamlet.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 25 Apr 89 10:10:07-PDT
Date: Tue 25 Apr 89 10:07:44-PDT
From: Rich Alderson <A.ALDERSON@Hamlet.Stanford.EDU>
Subject: Re: Version 7 and FTP
To: ADMIN@TOPS20.RADC.AF.MIL
cc: tops20@SCORE.STANFORD.EDU
In-Reply-To: <12488829693.10.ADMIN@TOPS20.RADC.AF.MIL>
Message-ID: <12488989397.13.A.ALDERSON@Hamlet.Stanford.EDU>
Instead of IPHOST, use the EXEC commands
^Eset internet host
^Eset internet gateway
to load a new host table and insure that everything is set up right.
Rich Alderson
Stanford University
-------
27-Apr-89 11:20:48-PDT,576;000000000000
Return-Path: <A.ALDERSON@Hamlet.Stanford.EDU>
Received: from Hamlet.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Apr 89 11:17:48-PDT
Date: Thu 27 Apr 89 11:15:24-PDT
From: Rich Alderson <A.ALDERSON@Hamlet.Stanford.EDU>
Subject: Re: Version 7 and FTP
To: ADMIN@TOPS20.RADC.AF.MIL
cc: tops20@SCORE.STANFORD.EDU
In-Reply-To: <12488829693.10.ADMIN@TOPS20.RADC.AF.MIL>
Message-ID: <12489526003.19.A.ALDERSON@Hamlet.Stanford.EDU>
Apologies to all. I spaced on the fact that the "^Eset internet" command group
is a Stanford-local hack.
Rich Alderson
-------
28-Apr-89 09:12:47-PDT,2739;000000000000
Return-Path: <geirp@ifi.uio.no>
Received: from ifi.uio.no by SCORE.STANFORD.EDU with TCP; Fri 28 Apr 89 09:11:11-PDT
Received: from svarte.uio.no by ifi.uio.no (5.59++/1.15) with SMTP
id AA06429; Fri, 28 Apr 89 18:11:14 +0200
Date: Fri, 28 Apr 89 18:11:14 +0200
From: geirp@ifi.uio.no
Message-Id: <8904281611.AA01985@svarte.uio.no>
To: TOPS-20@Score.Stanford.Edu
Subject: TOPS20AN source license
Cc: presteskapet%tone@ifi.uio.no
Hi,
Does any of you know how to get permission from DEC to use TOPS20
software (binary and source) without paying for it?
Why would we like to know that? Well, in December last year OD
(Oslostudentenes Dataforening), a student computer society took over
two DEC2065 machines from the Computer Science department here at the
University of Oslo.
Right now we are running TOPS20 v6.1. with DECnet, but without
monitor source code or tcp/ip support. This is the same configuration
the Computer Science department used. While this is pretty neat for a
student computer society, what we would really like to do is to run
tops20 v6.1 or v7?? with tcp/ip support and have source code for the
monitor. This would ordinarily be simple - right? Just pick up the
phone and call the DEC salesperson and order the stuff? Unfortunately
we can't do that. We have all these beautiful machines, but we can
hardly afford the several thousand dollars DEC asks for an ordinary
software license.
This is why we write this message to the info-tops20 list. The
local DEC people are not unwilling to grant us a kind of source
license for free, the trouble is that they don't really know how to do
it, or to be more precise: They probably could find out what to do,
but they would rather see us doing it and then just check if what we
found out is right. In a way this is understandable, they don't want
to spend their time and money to figure out how we can get something
for free :-)
So what we would like to know is:
o Do you yourself, or anyone you know about have a formal (or not so
formal) agreement with dec about the use of TOPS20AN software in
binary and source form more or less for free?
o Do you know about anyone inside DEC who might know something about
such an agreement?
Even if you don't know the answer to any of those questions, can
you think of anything else that might help us in our attempts to get
the source code?
With Best Regards,
Geir Pedersen and Bj|rn Remseth
----------------------------------------------------------------------
Geir Pedersen Bj|rn Remseth
geirp@ifi.uio.no "Use the source, Luke, the source" rmz@ifi.uio.no
Chairman OD Secretary OD
3-May-89 18:19:19-PDT,1231;000000000000
Return-Path: <A.ALDERSON@Goneril.Stanford.EDU>
Received: from Goneril.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 3 May 89 18:17:51-PDT
Date: Wed 3 May 89 16:34:38-PDT
From: Rich Alderson <A.ALDERSON@Goneril.Stanford.EDU>
Subject: DECUS 36-bit working group
To: tops-20@score.Stanford.EDU
Message-ID: <12491156983.129.A.ALDERSON@Goneril.Stanford.EDU>
We will be holding an organizational meeting on Tuesday, 9 May, in the Working
Group suite of the Site Management and Training SIG. I don't know the exact
time yet, but it will be published in Monday's UPDATE.DAILY.
This working group is intended to provide a presence within DECUS for 36-bit
systems, now that the Large Systems SIG has disbanded. We expect that most of
the issues that will arise for those of us who will keep Tops-20 and Tops-10
boxes around a few more years will have that kind of orientation: How do I
keep this thing running now that DEC has dropped it? What kind of problems are
others seeing with aging hardware? Etc.
If you will be in Atlanta, please try to attend this meeting. We'd like to
show Dave Braithwaite that his people will still have someone to support in the
years ahead.
Rich Alderson
-------
12-May-89 09:36:34-PDT,761;000000000000
Return-Path: <DEBRA@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Fri 12 May 89 09:33:21-PDT
Date: Fri, 12 May 89 09:29:25 PDT
From: HOSTMASTER@SRI-NIC.ARPA
Subject: INTERNET.GATEWAYS
Sender: DEBRA@SRI-NIC.ARPA
To: tops20@score.stanford.edu
cc: hostmaster@SRI-NIC.ARPA
Reply-To: HOSTMASTER@SRI-NIC.ARPA
Message-ID: <12493438870.51.DEBRA@SRI-NIC.ARPA>
This is to inform you that the DDN Network Information Center will
discontinue maintenance of the online file NETINFO:INTERNET.GATEWAYS
on 15 June 1989. The final version of the file will be available
online only until 15 July 1989.
Please contact HOSTMASTER@SRI-NIC.ARPA if you have any questions
regarding this matter.
-- NIC Hostmaster Staff
-------
16-May-89 20:40:44-PDT,752;000000000000
Return-Path: <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Tue 16 May 89 20:39:44-PDT
Date: Tue, 16 May 1989 21:39 MDT
Message-ID: <WANCHO.12494609505.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@SCORE.STANFORD.EDU
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: DUMPER mods
Has anyone carefully examined the latest releases of DUMPER (since
6.1) to determine if all the optimization modifications from Columbia,
Rutgers, Stanford, and others for the 5.x version have actually found
their way into the official version? Because the new version appears
to be a major rewrite, a simple source comparison is hopeless...
--Frank
17-May-89 09:36:10-PDT,2154;000000000000
Mail-From: VAF created at 17-May-89 09:35:20
Date: Wed 17 May 89 09:35:20-PDT
From: Vince Fuller <VAF@Score.Stanford.EDU>
Subject: The end of an era
To: TOPS-20@Score.Stanford.EDU
Office: Pine Hall 167
Phone: 415-723-6860
Message-ID: <12494750667.19.VAF@Score.Stanford.EDU>
Ask not for whom the bell tolls...
---------------
Date: Tue 16 May 89 12:15:27-PDT
From: Stu Grossman <GROSSMAN@Score.Stanford.EDU>
Subject: The demise of Score
To: system@Score.Stanford.EDU
Message-ID: <12494517670.20.GROSSMAN@Score.Stanford.EDU>
************IMPORTANT NOTICE******************
SCORE USERS
Notice to users of SCORE (TOPS 20)
The computer system known as SCORE will be decommissioned on August
31, 1989, and on that date SCORE will no longer be available for
use.
It is important that you make arrangements to off-load any programs
and data stored on Score before the August 31st deadline. After
that date there may be no available mechanism to recover files.
This action is being taken in the normal course of upgrading and
replacing computer science department equipment. The replacement
machines will use a different operating system (UNIX), so users who
want to continue to use machines with the TOPS 20 operating system
should make arrangements with other university departments (IR,
GSB, etc) or other computer resource suppliers that may offer
compatible services.
In the future, we may have to limit the number of non-CSD users of
CSD-CF equipment. Therefore, we ask those outside users who wish
to continue using CSD computers to contact CSD-CF to discuss their
expected needs. We do not want the change to leave anyone without
computing resources, and we will work with you to develop
alternatives.
Please send questions and inquiries to Action@Score or
Admin@Score.
James E. Ball
Director, CSD-CF
-------
-------
17-May-89 14:42:19-PDT,587;000000000000
Return-Path: <PUCHRIK@TOPS20.DEC.COM>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Wed 17 May 89 14:41:46-PDT
Date: 17 May 1989 1737-EDT
From: "Andy Puchrik" <PUCHRIK@TOPS20.DEC.COM>
To: Tops-20@score.stanford.edu
ATT: 508-467-7157
DTN: 297-7157
Subject: RE: End of an era : SCORE
Message-ID: <"MS11(6044)+GLXLIB6(0)" 12494805697.16.321.99388 at TOPS20.DEC.COM>
It's hard to believe that SCORE is shutting down. I see about 50 sites
running Tops-20 on HOSTS.TXT. I wonder how many Tops-20 systems will be
on the Internet this Summer?
asp
--------
13-Jun-89 23:37:55-MDT,541;000000000000
Mail-From: WANCHO created at 13-Jun-89 23:37:52
Date: Tue, 13 Jun 1989 23:37 MDT
Message-ID: <WANCHO.12501971010.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: SYSDPY Output Byte Count
I don't believe I've ever seen the Output Byte Count in the SYSDPY
ANCnn display have a "reasonable" value. Has anybody tried to fix it,
or is it simply not possible to display a reasonable value in that
slot?
--Frank
14-Jun-89 14:11:22-MDT,797;000000000000
Return-Path: <BILLW@MATHOM.CISCO.COM>
Received: from MATHOM.CISCO.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 14 Jun 89 14:10:58 MDT
Date: Wed 14 Jun 89 13:04:51-PDT
From: William Westfield <BILLW@MATHOM.CISCO.COM>
Subject: Re: SYSDPY Output Byte Count
To: WANCHO@WSMR-SIMTEL20.ARMY.MIL
cc: TOPS20@WSMR-SIMTEL20.ARMY.MIL
In-Reply-To: <WANCHO.12501971010.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Message-ID: <12502128840.18.BILLW@MATHOM.CISCO.COM>
I have tried to fix it, and it is simply not possible (well, not without
changing the monitor). The byte counts are calculated as differences
between the current sequence numbers and the initial sequence numbers.
Unfortunately, the tops20 TCP only keeps track of ONE of the initial
sequence numbers.
Bill Westfield
cisco Systems.
-------
16-Jun-89 01:09:27-MDT,516;000000000000
Mail-From: WANCHO created at 16-Jun-89 01:09:24
Date: Fri, 16 Jun 1989 01:09 MDT
Message-ID: <WANCHO.12502511961.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: FTPSRT NLST bug
Problem: NLST returns the directory name when there's only one file in
the currently connected directory.
Cure: In FTPSRT.MAC, change the NLSFMT definition to contain ..DIRD
instead of ..DIRA.
--Frank
17-Jun-89 23:39:29-MDT,1559;000000000000
Return-Path: <mrc@blake.acs.washington.edu>
Received: from hanna.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 17 Jun 89 23:39:22 MDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
(5.61/UW-NDC Revision: 1.99 ) id AA04529; Sat, 17 Jun 89 22:38:04 -0700
Date: Sat, 17 Jun 1989 22:30:07 PDT
From: Mark Crispin <mrc@blake.acs.washington.edu>
Subject: KS10 boot errors
To: Roll@Kicki.Stacken.KTH.SE
Cc: TOPS-20@WSMR-SIMTEL20.Army.Mil
Message-Id: <MS-C.614151008.1103527590.mrc@blake.acs.washington.edu>
Hi. I am in the process of bringing PANDA back up. Before bringing up the
disks I am trying to boot from tape. However, when I try an MT to the KS10>
prompt on any of my bootable tapes (monitor bootstrap, KSFORM, RED#3) the
tape moves forward a tiny bit, backspaces to the loadpoint (and the Phase
Encoded light goes on on the TM03) and then it doesn't do anything. After a
period of time I get ?BT 154721.
My listing of the KS10 console program has long since disappeared. Can anyone
tell me what this error means, or how I can try to figure out what's going on?
I don't think it could have possibly moved the tape far enough to load
microcode.
I tried the obvious thing of trying a different Massbus cable. Same results.
It is getting as far as moving the tape and getting the controller to
recognize it as a 1600 BPI tape.
I'd really rather run diagnostics before playing with the disks, since all I
have to work with are my real filesystem disks!
-- Mark --
-------
19-Jun-89 15:39:47-MDT,1356;000000000000
Return-Path: <LIEN@KICKI.STACKEN.KTH.SE>
Received: from KICKI.STACKEN.KTH.SE by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 19 Jun 89 15:39:34 MDT
Return-Path: <LIEN@KICKI.STACKEN.KTH.SE>
Date: 19-Jun-89 23:40:39 +0200
From: Jan Lien <LIEN@KICKI.STACKEN.KTH.SE>
To: tops20@wsmr-simtel20.army.mil, ksowner@KICKI.STACKEN.KTH.SE
cc: lien@xerxes.stacken.kth.se
Subject: KS-10 <=> RM03 boot problems
Message-ID: <12503478845.22.1052.116460@KICKI.STACKEN.KTH.SE>
Does anybody know the correct parameters for ONCE when booting
from tape with a RM03 connected ? I am trying to boot a KS-10
with TOPS-10, ver 7.02 or 7.03, from a TU-77, with one RM03.
(THe system boots fine when I connect a RP 06 disk).
I have tried booting with a lot of different values, but I never
get thru. The system always hangs with one or two CPU Stopcodes.
The stopcodes depend upon the values I feed ONCE with, and this
also determines at which point the system hangs. I have been
able to get as far as to see the prompt
".To automatically login as 1,2 type LOGIN" after specifying
structure to refresh. Any body who has an idea of the correct
values, or do I have to try all combinations :-) ?
Or if you know any installation who runs KS-10 with RM 03 disk,
please give me telephone number to that installation !
Thanks - Jan Lien
--------
23-Jun-89 15:09:18-MDT,1196;000000000000
Return-Path: <VAF@Score.Stanford.EDU>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 23 Jun 89 15:09:15 MDT
Date: Fri 23 Jun 89 14:06:59-PDT
From: Vince Fuller <VAF@Score.Stanford.EDU>
Subject: [Lawrence.Butcher@g.gp.cs.cmu.edu: 20]
To: TOPS-20@Score.Stanford.EDU
Office: Pine Hall 167
Phone: 415-723-6860
Message-ID: <12504499446.18.VAF@Score.Stanford.EDU>
Does anyone have an interest in this? I tend to doubt that Stanford does, given
the rate at which they are shutting-off DEC-20's...
--Vince
---------------
Return-Path: <@cs.cmu.edu:Lawrence.Butcher@G.GP.CS.CMU.EDU>
Received: from CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Fri 23 Jun 89 10:26:46-PDT
Received: from G.GP.CS.CMU.EDU by CS.CMU.EDU; 23 Jun 89 13:26:20 EDT
Date: Friday, 23 June 1989 13:25:31 EDT
From: Lawrence.Butcher@g.gp.cs.cmu.edu
To: fuller@cs.cmu.edu
Subject: 20
Message-ID: <1989.6.23.17.24.18.Lawrence.Butcher@G.GP.CS.CMU.EDU>
We have a 20 which is not plugged in. Does Stanford want it???
We would entertain ANY reasonable offer, if it were for a site which
will USE it, not scrap it. Anyone you can talk to??
Lawrence
-------
25-Jun-89 18:31:17-MDT,579;000000000000
Return-Path: <LIEN@kicki.stacken.kth.se>
Received: from lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 25 Jun 89 18:30:10 MDT
Received: from kicki.stacken.kth.se by mintaka.lcs.mit.edu id aa01948;
25 Jun 89 15:56 EDT
Return-Path: <LIEN@KICKI.STACKEN.KTH.SE>
Date: 25-Jun-89 21:55:43 +0200
From: Jan Lien <LIEN@kicki.stacken.kth.se>
To: tops20@wsmr-simtel20.army.mil
Subject: Meeting in Anaheim
Message-ID: <12505032606.26.1052.33060@KICKI.STACKEN.KTH.SE>
When is the 36-bit meeting scheduled for ?
In Anaheim, is that in California ?
--------
27-Jun-89 05:29:27-MDT,1162;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 27 Jun 89 05:29:24 MDT
Date: Tue 27 Jun 89 05:07:05-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: Re: Meeting in Anaheim
To: LIEN@kicki.stacken.kth.se
cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: <12505032606.26.1052.33060@KICKI.STACKEN.KTH.SE>
Message-ID: <12505427893.14.AI.CLIVE@MCC.COM>
Yes, we are planning a 36-Bit 25th Anniversary Celebration for
the Fall Decus Symposium, November 6-10, in Anaheim, California.
Anybody who has any ideas for this event, or would like to help in
the planning, should contact me (Clive@MCC.COM) or Betsy Ramsey
(ramsey%cuavax.dnet@netcon.cua.edu).
It's hard to tell how many 36-bit'ers will show up, considering that
our numbers at DECUS have been steadily shrinking over the last couple
of years. As most of you know, the Large Systems SIG was disolved
a while back, and (as they say in diplomatic circles) "our interests"
(e.g. session scheduling, etc.) are now being handled by a committee
of the Site Management SIG.
At the very least, we will all go out to dinner!
Clive
-------
28-Jun-89 21:55:38-MDT,1430;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from hanna.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 28 Jun 89 21:55:02 MDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
(5.61/UW-NDC Revision: 1.99 ) id AA23118; Wed, 28 Jun 89 17:02:52 -0700
Date: Wed, 28 Jun 1989 16:49:35 PDT
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: mrc@Tomobiki-Cho.CAC.Washington.EDU
Subject: Re: Meeting in Anaheim
To: Clive Dawson <AI.CLIVE@mcc.com>
Cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: <12505427893.14.AI.CLIVE@MCC.COM>
Message-Id: <MailManager.615080975.1308.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Clive -
I am, of course, *very* interested in the 36-Bit 25th Anniversary
Celebration. I suggest that we have many of the same activities we had at the
20th Anniversary Celebration, albeit on a smaller scale, maybe :-). I have in
mind a Trivia Bowl, a Pioneer's Roundtable, a Memorabilia Swap, and a console
panel auction. I am determined to get a KI-10 front panel *this* time. :-)
We should also have some panels on keeping your PDP-10 healthy and happy
in its Golden Years. It would be very nice if we could have a panel involving
all those people who have home PDP-10's. Peter Lothberg should be invited as a
guest and asked to give a talk about his computer farm.
And, definitely, there should be a banquet.
-- Mark --
-------
1-Jul-89 16:59:24-MDT,1083;000000000000
Return-Path: <@Score.Stanford.EDU:MRC@wsmr-simtel20.army.mil>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 1 Jul 89 16:59:18 MDT
Received: from hanna.cac.washington.edu by SCORE.STANFORD.EDU with TCP; Sat 1 Jul 89 15:58:54-PDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
(5.61/UW-NDC Revision: 1.108 ) id AA09982; Sat, 1 Jul 89 15:58:54 -0700
Date: Sat, 1 Jul 1989 15:53:37 PDT
From: Mark Crispin <MRC@wsmr-simtel20.army.mil>
Subject: PANDA arises from the dead, still a bit drowsy...
To: TOPS-20@Score.Stanford.EDU
Message-Id: <MS-C.615336817.377401575.MRC@wsmr-simtel20.army.mil>
On July 1, 1989, PANDA.PANDA.COM executed its first TOPS-20 cycles since
the end of September 1988. One 64K memory board definitely went bad and has
been replaced. The tape drive and lineprinter are still down.
E-mail service to PANDA.PANDA.COM is still down, but should resume
shortly. Don't send any important mail to me there, since without a tape
drive there are no backups...
-- Mark --
-------
2-Jul-89 00:13:26-MDT,1298;000000000000
Return-Path: <@Score.Stanford.EDU:jeff@uhccux.uhcc.Hawaii.Edu>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 2 Jul 89 00:13:23 MDT
Received: from uhics.ics.hawaii.edu by SCORE.STANFORD.EDU with TCP; Sat 1 Jul 89 23:13:16-PDT
Received: from uhccux.uhcc.Hawaii.Edu by uhics.ics.hawaii.edu (4.0/UHICS-MX-1.4)
id AA12725; Sat, 1 Jul 89 20:13:48 HST
Received: by uhccux.uhcc.Hawaii.Edu (5.57/Ultrix2.2)
id AA13611; Sat, 1 Jul 89 20:13:37-1000
Date: Sat, 1 Jul 89 20:13:37-1000
From: Jeff Blomberg <jeff@uhccux.uhcc.Hawaii.Edu>
To: tops-20@SCORE.STANFORD.EDU
Subject: Obituary
Message-Id: <CMM.0.88.615363214.jeff@uhccux.uhcc.hawaii.edu>
Today, July 1st 00:00-HST, the Universiy of Hawaii's DECSYSTEM-2065 went off
the air permanently after a terminal illness. It is survived by an 8650
(Ultrix), an 8550 (VMS), and a bevy of workstations. A private funeral will
be held in 2 weeks. We are grateful for the service it provided, and wish it
well in the great computer room in the sky. Please observe a moment of silence.
-------------------------------------------------------------------------
Jeffrey Blomberg -- University of Hawaii Computing Center -- 808/948-7351
Internet: jeff@uhccux.uhcc.Hawaii.Edu BITNET: jeff@uhccux.BITNET
2-Jul-89 12:51:29-MDT,876;000000000000
Return-Path: <@Score.Stanford.EDU:mrc@wsmr-simtel20.army.mil>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 2 Jul 89 12:51:27 MDT
Received: from hanna.cac.washington.edu by SCORE.STANFORD.EDU with TCP; Sun 2 Jul 89 11:51:17-PDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
(5.61/UW-NDC Revision: 1.108 ) id AA02612; Sun, 2 Jul 89 11:51:06 -0700
Date: Sun, 2 Jul 1989 11:47:15 PDT
From: Mark Crispin <mrc@wsmr-simtel20.army.mil>
Subject: re: Obituary
To: Jeff Blomberg <jeff@uhccux.uhcc.Hawaii.Edu>
Cc: tops-20@SCORE.STANFORD.EDU
In-Reply-To: <CMM.0.88.615363214.jeff@uhccux.uhcc.hawaii.edu>
Message-Id: <MS-C.615408435.377401575.mrc@wsmr-simtel20.army.mil>
Jeff -
So, the same day that PANDA is reborn your machine died. Maybe a form of
reincarnation is happening?
-- Mark --
-------
2-Jul-89 20:55:21-MDT,981;000000000000
Mail-From: PANDA created at 2-Jul-89 20:54:49
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Sun, 2 Jul 89 20:54:49 MDT
Date: Sun, 2 Jul 89 19:11:09 PDT
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: Hello, world!
To: TOPS-20@WSMR-SIMTEL20.Army.MIL
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2020
Phone: +1 (206) 842-2385
Message-ID: <12506914116.8.MRC@PANDA.PANDA.COM>
If you got this message, it is because PANDA.PANDA.COM's mail link has
become functional. PANDA's tape drive and lineprinter are still down, and
two memory boards did not make it. Otherwise, PANDA seems to be back and
happily crunching TOPS-20 cycles, eating power that only costs half as much
as in California.
I hope that PANDA's resurgence from the ashes, like that of the
proverbial phoenix, will inspire other 36-bit lovers to continue keeping our
beloved dinosaurs alive.
-- Mark --
-------
4-Jul-89 07:31:30-MDT,706;000000000000
Return-Path: <ROLL@KICKI.STACKEN.KTH.SE>
Received: from KICKI.STACKEN.KTH.SE by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 4 Jul 89 07:31:20 MDT
Return-Path: <ROLL@KICKI.STACKEN.KTH.SE>
Address: "PoBox:36041, SE-100 71 Stockholm, SWEDEN"
Organization: Stacken Computer Club
Telephone: +46-8-669 9720
Date: 4-Jul-89 15:31:02 +0200
From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
To: tops20@wsmr-simtel20.army.mil
Subject: Dumper program for non Tops-20 system
Message-ID: <12507321873.25.411.11680@KICKI.STACKEN.KTH.SE>
I'm out to find a program that can read and write 9-trk magtapes in
Tops20 (interchange) format.
I need the sources in any high-level language.
-Peter
--------
5-Jul-89 09:45:43-MDT,1900;000000000000
Return-Path: <@Score.Stanford.EDU:ADMIN@TOPS20.RADC.AF.MIL>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 5 Jul 89 09:44:45 MDT
Received: from TOPS20.RADC.AF.MIL by SCORE.STANFORD.EDU with TCP; Wed 5 Jul 89 07:18:08-PDT
Date: Wed 5 Jul 89 10:17:45-EST
From: Donna Lynch <ADMIN@TOPS20.RADC.AF.MIL>
Subject: net tools
To: tops-20@SCORE.STANFORD.EDU
cc: admin@TOPS20.RADC.AF.MIL
Message-ID: <12507581599.9.ADMIN@TOPS20.RADC.AF.MIL>
Again, I need help. I am sure there are some programs written for what
I need, but I dont know what they are or how to use them.
I am running JEEVES and CHIVES. People complain about my server but
I seem to have no way of testing it. They tell me I am not returning
a name given an address. I dont know if they are right or wrong. I
thought I was doing it properly. I tried GTDTST but it returns some
names but not others. It seems to get only the names that are in
the host table. I have to names that are listed one after the other
in my IN-ADDR file, it gets one name but not the other. So I dont think
GTDTST is the right tool. I have tried QUERY as well but I cant get
any useful information from it. If QUERY is the right tool I need
information on how to use it. If there are other tools with JEEVES, then
the same holds true.
My secondary server can not dump my server to do automatic updates. What
are other people doing to solve this problem?
Can I ping a host? I dont know how.
Can I tell what path (gateways) we are using or trying to use to get to
a host? Or when I cant get to a host, where is the path failing? We
are on NYSERNET and are forever having problems.
I feel I am running the network software in the dark and I dont like it
much. Especially when all the hosts around me say, "You cant do that,
we can."
Any help will be much appreciated,
Donna
-------
5-Jul-89 12:21:34-MDT,1054;000000000000
Return-Path: <W.WELSH@Macbeth.Stanford.EDU>
Received: from Macbeth.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 5 Jul 89 12:21:28 MDT
Date: Wed 5 Jul 89 11:21:15-PDT
From: Sean L. Welsh <W.Welsh@Macbeth.Stanford.EDU>
Subject: Re: Meeting in Anaheim
To: MRC@CAC.Washington.EDU
cc: AI.CLIVE@mcc.com, tops20@wsmr-simtel20.army.mil
In-Reply-To: <MailManager.615080975.1308.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <12507615004.11.W.WELSH@Macbeth.Stanford.EDU>
Mark,
While I would also like to see some of the things you suggest, you should
be aware that the CFP deadline has come and gone for Anaheim. Also, we
have very limited slots on the symposium schedule; remember, we do not
have the resources of a whole SIG or SIC with which to work here. Any
"session" we would like to have along the lines of your suggestions would
have to be scheduled informally on-site. We would welcome any assistance
you can provide in gathering support for some 36-bit Birds-Of-a-Feather
sessions in Anaheim.
Sean
-------
5-Jul-89 12:21:38-MDT,748;000000000000
Return-Path: <G.EGK@Score.Stanford.EDU>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 5 Jul 89 12:21:33 MDT
Date: Wed 5 Jul 89 11:21:06-PDT
From: Edjik <G.EGK@Score.Stanford.EDU>
Subject: Re: Dumper program for non Tops-20 system
To: ROLL@kicki.stacken.kth.se
cc: tops20@WSMR-SIMTEL20.ARMY.MIL
In-Reply-To: <12507321873.25.411.11680@KICKI.STACKEN.KTH.SE>
Message-ID: <12507614977.44.G.EGK@Score.Stanford.EDU>
this is not a joke.
Seeing peters message reminded me of my need to find a dumper reading
program that runs on an ibm-pc. if one doenst exist, ill take any
dumper reading program written in a HLL, (the same one peter is looking
for), and convert it to the PC.
Thanks much.
--E+
-------
5-Jul-89 14:04:50-MDT,1246;000000000000
Return-Path: <ROLL@kicki.stacken.kth.se>
Received: from lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 5 Jul 89 14:04:44 MDT
Received: from kicki.stacken.kth.se by mintaka.lcs.mit.edu id aa21662;
5 Jul 89 16:02 EDT
Return-Path: <ROLL@KICKI.STACKEN.KTH.SE>
Address: "PoBox:36041, SE-100 71 Stockholm, SWEDEN"
Organization: Stacken Computer Club
Telephone: +46-8-669 9720
References: Message from Edjik <G.EGK@Score.Stanford.EDU>
of 5-Jul-89 20:22:40
In-reply-to: <12507614977.44.G.EGK@Score.Stanford.EDU>
Date: 5-Jul-89 22:00:25 +0200
From: Peter Lothberg <ROLL@kicki.stacken.kth.se>
To: Edjik <G.EGK@score.stanford.edu>
cc: tops20@wsmr-simtel20.army.mil
Subject: Re: Dumper program for non Tops-20 system
Message-ID: <12507654902.24.411.13360@KICKI.STACKEN.KTH.SE>
This is exactly what i want to do. I have a 1/2" tape streamer that I
plan to hook to a PC.
But, uncommon to those who only wants to read old tapes, from their
retired DEC20, i want to be able to write tapes for the -20 from
the PC.
(And do backup of the PC winchester in T20 tape format, so i can read
the backup if the PC stops working or gets outdatet by some new
exotic hardware.)
-Peter
--------
5-Jul-89 15:11:25-MDT,1223;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from hanna.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 5 Jul 89 15:11:06 MDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
(5.61/UW-NDC Revision: 2.1 ) id AA02888; Wed, 5 Jul 89 14:10:40 -0700
Date: Wed, 5 Jul 1989 13:35:11 PDT
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: mrc@Tomobiki-Cho.CAC.Washington.EDU
Subject: Re: Meeting in Anaheim
To: Sean L. Welsh <W.Welsh@Macbeth.Stanford.EDU>
Cc: AI.CLIVE@mcc.com, tops20@wsmr-simtel20.army.mil
In-Reply-To: <12507615004.11.W.WELSH@Macbeth.Stanford.EDU>
Message-Id: <MailManager.615674111.1575.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Sean -
I realize the problem and regret not having done something about it before,
but as you know I've been "offline" from the TOPS-20 world since last September.
Since it's too late to get things done completely in the context of DECUS, how
much *can* we do "informally"?
Perhaps we can get a head count of the number of people interested in doing
something? The only reason I would go to DECUS is to attend a 36-bit get-
together, so it would have to be enough to justify going.
-- Mark --
-------
6-Jul-89 08:59:00-MDT,3941;000000000000
Return-Path: <@Score.Stanford.EDU:sra@bigboote.LCS.MIT.EDU>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 6 Jul 89 08:58:47 MDT
Received: from bigboote.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 6 Jul 89 07:58:17-PDT
Received: by bigboote.LCS.MIT.EDU
id AA08680; Thu, 6 Jul 89 10:58:06 EDT
Date: Thu, 6 Jul 89 10:58:06 EDT
Message-Id: <8907061458.AA08680@bigboote.LCS.MIT.EDU>
From: Rob Austein <sra@lcs.mit.edu>
Sender: sra@bigboote.LCS.MIT.EDU
To: ADMIN@tops20.radc.af.mil
Cc: tops-20@score.stanford.edu
In-Reply-To: Donna Lynch's message of Wed 5 Jul 89 10:17:45-EST <12507581599.9.ADMIN@TOPS20.RADC.AF.MIL>
Subject: net tools
Donna,
I am running JEEVES and CHIVES. People complain about my server but
I seem to have no way of testing it. They tell me I am not returning
a name given an address. I dont know if they are right or wrong. I
thought I was doing it properly.
You want a copy of the QDOMAIN program, a completely unsupported hack
written by Gail Zacharias back when there was an OZ.AI.MIT.EDU. It
has a nice COMND% interface and allows you to send arbitrary questions
to a user specified domain name server. In this case you'd want to
use it to query your own host. We (MIT) no longer have any PDP-10s
with Internet connections, so it would be challenging for me to get
you a copy of this. Perhaps Mark Crispin or somebody at Stanford or
SRI still has a copy. If not, there should be a copy on the tape I
sent to Frank Wancho for the TOPS-20 archiving project.
If you have a unix machine handy, you might want to get a copy of the
ISI "DiG" program, which has approximately the same functionality.
I tried GTDTST but it returns some
names but not others. It seems to get only the names that are in
the host table. I have to names that are listed one after the other
in my IN-ADDR file, it gets one name but not the other. So I dont think
GTDTST is the right tool.
Keep in mind that GTDTST queries the resolver, not the name server,
and that the CHIVES resolver and the JEEVES nameserver are completely
separate programs that (in your case) happen to reside on the same
machine. That said, I don't know what these results mean.
I have tried QUERY as well but I cant get
any useful information from it. If QUERY is the right tool I need
information on how to use it. If there are other tools with JEEVES, then
the same holds true.
You should talk to Paul Mockapetris <pvm@isi.edu>, the author of
JEEVES, to see if you an get a copy of the JEEVES manual, which should
at least tell you what's part of the JEEVES package and how it all
hangs together. Don't expect too much. JEEVES was never really
finished and its development was heavily oriented towards providing a
stable root nameserver with a lot of telemetry for protocol designers,
rather than a straightforward TOPS-20 system daemon.
My secondary server can not dump my server to do automatic updates. What
are other people doing to solve this problem?
JEEVEVS can't provide this, period. The code was never written. We
(MIT-LCS) use FTP even between unix hosts because it gives us better
control over the installation process on the secondary servers and
thus allows us to check that everything made it across the net ok
before committing to new zone versions on the secondary servers.
Can I ping a host? I dont know how.
Can I tell what path (gateways) we are using or trying to use to get to
a host? Or when I cant get to a host, where is the path failing? We
are on NYSERNET and are forever having problems.
The TOPS-20 IP/ICMP code doesn't have the hooks that one would need to
provide these utilities in any straightforward way. Perhaps something
could be cobbled together but I'm not aware of anyone having done so.
Good luck.
--Rob
7-Jul-89 06:29:36-MDT,725;000000000000
Return-Path: <@Score.Stanford.EDU:ADMIN@TOPS20.RADC.AF.MIL>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 7 Jul 89 06:29:32 MDT
Received: from TOPS20.RADC.AF.MIL by SCORE.STANFORD.EDU with TCP; Fri 7 Jul 89 05:28:53-PDT
Date: Fri 7 Jul 89 08:28:34-EST
From: Donna Lynch <ADMIN@TOPS20.RADC.AF.MIL>
Subject: RE: net tools
To: tops-20@score.stanford.edu
cc: admin@TOPS20.RADC.AF.MIL
Message-ID: <12508086012.11.ADMIN@TOPS20.RADC.AF.MIL>
It seems that QUERY does provide the necessary information. As I suspected,
I just didnt know how to use it. Thanks to Alan Larson for the information.
I got only negatives on the PING and routing information though.
Thanks,
Donna
-------
10-Jul-89 12:24:55-MDT,389;000000000000
Return-Path: <JWEINER@ccr1.bbn.com>
Received: from ccr1.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 10 Jul 89 12:24:50 MDT
Date: Mon, 10 Jul 89 14:23 EDT
From: JERRY WEINER X3242 <JWEINER@ccr1.bbn.com>
Subject: AMPEX ARM20S Memory spares/repair
To: TOPS-20@WSMR-SIMTEL20.ARMY.mil
Anyone know of a source for repair or spares for AMPEX ARM-20S MOS
memory.
Thanx,
Jerry
11-Jul-89 10:36:03-MDT,1660;000000000000
Return-Path: <@Score.Stanford.EDU:jzj@MSR.EPM.ORNL.GOV>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 11 Jul 89 10:35:56 MDT
Received: from MSR.EPM.ORNL.GOV by SCORE.STANFORD.EDU with TCP; Tue 11 Jul 89 09:35:23-PDT
Received: by MSR.EPM.ORNL.GOV (5.51/4.9)
id AA23498; Tue, 11 Jul 89 12:35:11 EDT
Date: Tue, 11 Jul 89 12:35:11 EDT
From: jzj@MSR.EPM.ORNL.GOV (Jeff Jones)
Message-Id: <8907111635.AA23498@MSR.EPM.ORNL.GOV>
To: tops-20@score.stanford.edu
Subject: TOPS-20/VMS NFT/FAL problem
We just upgraded one of our VAXclusters from VMS V4.7 to V5.0-2. After the
upgrade, we started experiencing file transfer failures between the DEC-20 and
the VAX when they originated
on the VMS side. After further investigation, file transfers only failed
when they are accessing a structure other than PS:. All of the failing
transfers originate on the VAX and are copying a file from the DEC-20 to
the VAX.
File transfers originating on the DEC-20 work fine. File transfers
originating on the VAX and copying a file to the DEC-20 work fine. Taking
a directory originating on the VAX always fail.
The error message on the failing transfers is "file not found".
We are running TOPS-20 V6.1 autopatched through tape #18.
I've looked through the TOPS-20 V7.0 Autopatch tapes (19, 20, 21) and have not
found any patches dealing with this.
It looks like FAL is not handling the file specification correctly as passed
by the new version of VMS. Before I dig into FAL, I thought I would see if
anyone has seen this before.
Thanks,
Jeff Jones
Martin Marietta Energy Systems, Inc.
(615)576-2335
22-Jul-89 19:06:25-MDT,12897;000000000000
Mail-From: PANDA created at 22-Jul-89 18:57:14
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Sat, 22 Jul 89 18:57:14 MDT
Date: Sat, 22 Jul 89 17:29:10 PDT
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: a useful program
To: TOPS-20@WSMR-SIMTEL20.Army.MIL
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2020
Phone: +1 (206) 842-2385
Message-ID: <12512138430.3.MRC@PANDA.PANDA.COM>
Here's a program to set your system's time from the National
Bureau of Standard's time server. It is based on an ancient hack
written for PANDA a few years ago. It assumes a DEC DF112 modem
for dialing at the TTY lines listed in DILTAB:. Feel free to
hack or improve it for your own use!
TITLE TIMCHK dial-up style
SEARCH MACSYM,MONSYM
.TEXT "TIMCHK/SAVE"
.REQUIRE SYS:MACREL
STDAC.
COMMENT %
DESCRIPTION OF THE
AUTOMATED COMPUTER TELEPHONE SERVICE (ACTS)
(303) 494-4774
The following is transmitted (at 1200 baud) following completion of the
telephone connection.
? = HELP
National Bureau of Standards
Telephone Time Service
D L D
MJD YR MO DA H M S ST S UT1 msADV OTM
47222 88-03-02 21:39:15 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:16 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:17 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:18 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:19 83 0 +.3 037.6 UTC(NBS) #
47222 88-03-02 21:39:20 83 0 +.3 037.6 UTC(NBS) #
etc..etc...etc.......
UTC = Universal Time Coordinated, the official world time referred to the
zero meridian.
_________________________________________________________________________
DST = Daylight savings time characters, valid for the continental U.S., are
set as follows:
00 = We are on standard time (ST). 50 = We are on DST.
99 to 51 = Now on ST, go to DST when your local time is 2:00 am and the
count is 51. The count is decremented daily at 00 (UTC).
49 to 01 = Now on DST, go to ST when your local time is 2:00 am and the
count is 01. The count is decremented daily at 00 (UTC).
The two DST characters provide up to 48 days advance notice of a change in
time. The count remains at 00 or 50 at other times.
_________________________________________________________________________
LS = Leap second flag is set to "1" to indicate that a leap second is to be
added as 23:59:60 (UTC) on the last day of the current UTC month. The LS
flag will be reset to "0" starting with 23:59:60 (UTC). The flag will
remain on for the entire month before the second is added. Leap seconds
are added as needed at the end of any month. Usually June and/or December
are chosen.
The leap second flag will be set to a "2" to indicate that a leap second
is to be deleted at 23:59:58--00:00:00 on the last day of the current
month. (This latter provision is included per international recommendation
however it is not likely to be required in the near future.)
__________________________________________________________________________
DUT1 = Approximate difference between earth rotation time (UT1) and UTC, in
steps of 0.1 second. DUT1 = UT1 - UTC
___________________________________________________________________________
MJD = Modified Julian Date, often used to tag certain scientific data.
___________________________________________________________________________
The full time format is sent at 1200 baud, 8 bit, 1 stop, no parity.
The HH:MM:SS msADV time format at 300 baud is also 8 bit, 1 stop, no parity.
___________________________________________________________________________
Maximum on line time will be 55 seconds. If all lines are busy at any time,
the oldest call will be terminated if it has been on line more than 15
seconds, otherwise, the call that first reaches 15 seconds will be
terminated.
___________________________________________________________________________
Current time is valid at the "on-time" marker (OTM), either "*" or "#".
The nominal on-time marker (*) will be transmitted 45 ms early to account
for the 8 ms required to send 1 character at 1200 baud, plus an additional
7 ms for delay from NBS to the user, and approximately 30 ms "scrambler"
delay inherent in 1200 baud modems. If the caller echoes all characters,
NBS will measure the round trip delay and advance the on-time marker so
that the midpoint of the stop bit arrives at the user on time. The amount
of msADV will reflect the actual required advance in milliseconds and the
OTM will be a "#". The NBS system requires 4 consecutive delay
measurements which are consistent before switching from "*" to "#".
If the user has a 1200 baud modem with the same internal delay as that used
by NBS, then the "#" OTM should arrive at the user within +-2 ms of the
correct time. However, NBS has studied different brands of 1200 baud
modems and found internal delays from 24 ms to 40 ms and offsets of the
"#" OTM of +-10 ms. For many computer users, +-10 ms accuracy should be
more than adequate since many computer internal clocks can only be set with
granularity of 20 to 50 ms. In any case, the repeatability of the offset
for the "#" OTM should be within +-2 ms, if the dial-up path is reciprocal
and the user doesn't change the brand or model of modem used. This should
be true even if the dial-up path on one day is a land-line of less than
40 ms (one way) and on the next day is a satellite link of 260 to 300 ms.
In the rare event that the path is one way by satellite and the other way
by land line with a round trip measurement in the range of 90 to 260 ms,
the OTM will remain a "*" indicating 45 ms advance. For the user who wants
the best possible accuracy at the OTM, NBS offers an alternate 300 baud
service with only HH:MM:SS MSADV and OTM. To use the alternate service,
simply call at 300 baud. Because of the simple FSK modulation scheme used
at 300 baud, all modems tested had the same delay within about 1 ms.
___________________________________________________________________________
The full time format will be sent at 1200 baud, 8 bit, 1 stop, no parity. The
HH:MM:SS MSADV time format at 300 baud will also be 8b, 1s, np.
For user comments write:
NBS-ACTS
Time and Frequency Division
Mail Stop 524
325 Broadway
Boulder, CO 80303
Software for setting DOS compatable machines is available on a
360-kbyte diskette for $35.00 from:
NBS Office of Standard Reference Materials
B311-Chemistry Bldg, NBS, Gaithersburg, MD, 20899, (301) 975-6776
%
EVEC: JRST TIMCHK
JRST TIMCHK
EVECL==.-EVEC
TIMCHK: RESET%
MOVE P,[IOWD PDLLEN,PDL]
MOVX T1,.DBUGSW ; check state of debugging
GETAB%
EJSHLT
CAILE T1,2 ; ignore if DBUGSW .GT. 2
HALTF% ; no, stop now then
MOVX T1,.FHSLF
SETOB T2,T3
EPCAP%
MOVSI P1,DILTBL ; init dialer list
DO.
MOVX T1,GJ%SHT ; grab the dialer
HRRO T2,DILTAB(P1)
GTJFN%
IFNJE.
MOVEM T1,DIALER ; note dialer JFN
MOVX T2,<<FLD 8,OF%BSZ>!OF%WR!OF%RD> ; now open it
OPENF%
IFNJE. <EXIT.> ; we got it
ENDIF.
AOBJN P1,TOP. ; try next dialer
JSHLT
ENDDO.
MOVSI P1,-SRVTBL ; init server list
DO.
MOVX T2,.MOHUP ; make sure DTR is down
MTOPR%
EJSHLT
MOVX T1,^D1000 ; wait a while to let the phone stabilize
DISMS%
MOVE T1,DIALER ; now bring DTR up
MOVX T2,.MOUHU
MTOPR%
EJSHLT
CFIBF% ; flush whatever may have been there before
MOVX T2,.CHCNB ; init the modem
BOUT%
BOUT% ; send two to be sure
MOVE T1,[5,,[ASCIZ/Ready/]] ; get expected Ready response
CALL GETRSP
LOOP.
MOVE T1,DIALER ; tone dialing...
MOVEI T2,"T"
BOUT%
MOVE T1,[2,,[ASCIZ/T/]] ; be sure it is echoed
CALL GETRSP
LOOP.
HRLI T3,<(POINT 7,)> ; make pointer to dial string
HRR T3,SRVTAB(P1)
DO.
ILDB T2,T3 ; get character for dialer
JUMPE T2,ENDLP.
MOVE T1,DIALER
BOUT%
MOVX T1,^D100 ; dally just a little bit
DISMS%
LOOP.
ENDDO.
MOVSI T1,3 ; check for this echo too
HRR T1,SRVTAB(P1)
CALL GETRSP
LOOP.
MOVE T1,DIALER ; now start it dialing...
MOVEI T2,"#"
BOUT%
MOVE T1,[30,,[ASCIZ/Attached/]]
CALL GETRSP
IFSKP.
MOVE T1,[30,,[ASCIZ/Time/]] ; wait for "Time"
CALL GETRSP
ANSKP.
MOVE T1,[10,,[ASCIZ/*/]] ; wait for first time to pass
CALL GETRSP
ANSKP.
MOVSI T3,100 ; timeout this way
DO.
MOVE T1,DIALER
SIBE%
IFSKP.
SOJG T3,TOP. ; zzz...
ELSE.
CALL GETCHR
CAIE T2,.CHSPC ; saw the first space?
LOOP. ; keep looking
ENDIF.
ENDDO.
ANDG. T3 ; timeout better not have expired
TIME% ; get current uptime
MOVEM T1,BASE ; save as base
MOVE Q1,[POINT 7,STRING] ; read in daytime string into buffer
MOVX Q2,<STRBSZ*5>-1 ; limit
MOVSI T3,100 ; timeout
DO.
MOVE T1,DIALER
SIBE%
IFSKP.
SOJG T3,TOP. ; zzz...
ELSE.
CALL GETCHR
CAIN T2,"*" ; at the end?
EXIT. ; done
IDPB T2,Q1 ; store this byte
SOJG Q2,TOP. ; keep looking
ENDIF.
ENDDO.
ANDG. Q2 ; check for overflow
ANDG. T3 ; timeout better not have expired...
LDB T1,[POINT 14,STRING,13] ; get year
LDB T2,[POINT 14,STRING+1,20] ; get day
DPB T2,[POINT 14,STRING,13] ; set year
DPB T1,[POINT 14,STRING+1,20] ; set day
MOVE T1,[POINT 22,STRING+3,35]
MOVX T2,ASCII/ -GM/ ; terminate with "-GMT"
DPB T2,T1
MOVX T1,ASCIZ/T/
MOVEM T1,STRING+4
HRROI T1,STRING ; parse the date returned
MOVX T2,IT%SNM!IT%ERR!IT%AIS!IT%AAC!IT%NTM
IDTIM%
..TAGF (ERJMP,) ; I sure wish ANNJE. existed!
MOVEM T2,NETIME
TMSG <
The time from >
HLRO T1,SRVTAB(P1)
PSOUT%
TMSG < is >
MOVX T1,.PRIOU
MOVE T2,NETIME
SETZ T3,
ODTIM%
TMSG <.
>
GTAD% ; see if time now is set
MOVEM T1,OLDTIM
IFG. T1 ; well?
DO.
TMSG <Is this correct? (Y,N) >
PBIN% ; get answer
MOVEI T2,(T1)
ANDX T2,177
TXZ T2,"a"-"A" ; force uppercase
CAIE T2,"Y"
CAIN T2,"N"
EXIT.
TMSG < ??? Please answer Y or N
>
LOOP.
ENDDO.
TMSG <
>
CAIE T2,"Y" ; user said "Y"?
EXIT. ; no, don't set time
ENDIF.
TIME%
SUB T1,BASE ; get time spent doing this
LSH T1,^D18
IDIV T1,[^D<1000*24*60*60>] ; convert to GTAD% format
ADD T1,NETIME
STAD%
EJSHLT
SKIPG OLDTIM ; report iff there was an old time
IFSKP.
MOVE T2,T1
TMSG <Time set to >
MOVX T1,.PRIOU
SETZ T3,
ODTIM%
ENDIF.
ELSE.
AOBJN P1,TOP. ; try next server
ENDIF.
ENDDO.
MOVE T1,DIALER ; flush the dialer's JFN
MOVX T2,.MOHUP ; make sure DTR is down
MTOPR%
EJSHLT
CLOSF%
ERJMP .+1
HALTF%
JRST TIMCHK
GETRSP: STKVAR <RSPPTR,RSPSAV,WATCNT>
HLRZM T1,WATCNT ; set maximum wait time
HRLI T1,<(POINT 7,)> ; make byte pointer
MOVEM T1,RSPPTR
MOVEM T1,RSPSAV
SETO T2, ; init "last character seen"
DO.
ILDB T4,RSPPTR ; get character we're expecting
JUMPE T4,RSKP ; if null then done!
CAME T2,T4 ; did it match the "last character"
IFSKP.
SETO T2, ; yes, then move to next character
LOOP.
ENDIF.
DO.
MOVE T1,DIALER ; anything in input stream?
SIBE%
IFSKP.
SOSGE WATCNT ; has timeout expired yet?
RET ; yes, give up
MOVX T1,^D1000 ; else wait a second
DISMS%
LOOP. ; and try again
ENDIF.
ENDDO.
CALL GETCHR
CAME T2,T4 ; does it match?
IFSKP.
SETO T2,
ELSE.
MOVE T1,RSPSAV ; reset pointer
MOVEM T1,RSPPTR
ENDIF.
LOOP.
ENDDO.
ENDSV.
GETCHR: BIN% ; get character from line
ANDX T2,177
SKIPN DEBUGP
IFSKP.
MOVX T1,.PRIOU
BOUT%
ENDIF.
RET
DILTAB: [ASCIZ/TTY3:/]
[ASCIZ/TTY4:/]
DILTBL==.-DILTAB
DEFINE SRV (NAME,NUMBER) <[ASCIZ/NAME/],,[ASCIZ/NUMBER/]>
SRVTAB: SRV NBS-ACTS,13034944774
SRV NBS-ACTS-Retry,13034944774
SRVTBL==.-SRVTAB
LIT
DEBUGP: BLOCK 1 ; non-zero if debugging
DIALER: BLOCK 1 ; JFN of dialer
BASE: BLOCK 1 ; uptime base
NETIME: BLOCK 1 ; time from the "net"
OLDTIM: BLOCK 1 ; old time
STRBSZ==100
STRING: BLOCK STRBSZ ; string readin area
PDLLEN==100
PDL: BLOCK PDLLEN+1
END <EVECL,,EVEC>
-------
31-Jul-89 01:20:24-MDT,4983;000000000000
Return-Path: <@Score.Stanford.EDU:satz@cisco.com>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 31 Jul 89 01:20:04 MDT
Received: from clash.cisco.com by SCORE.STANFORD.EDU with TCP; Mon 31 Jul 89 00:18:50-PDT
Received: from dustbin.cisco.com by clash.cisco.com with TCP; Mon, 31 Jul 89 00:18:59 -0700
To: tops20@score.stanford.edu
Subject: [clements@bbn.com (Bob Clements): Re: DECSYSTEM 20]
Date: Mon, 31 Jul 89 00:18:55 PDT
From: Greg Satz <satz@cisco.com>
Usenet comp.arch has discovered DEC-20s.
------- Forwarded Message
Return-Path:
From: clements@bbn.com (Bob Clements)
Newsgroups: comp.arch
Subject: Re: DECSYSTEM 20
Message-ID: <42962@bbn.COM>
Date: 19 Jul 89 17:08:03 GMT
References: <10907@xenna.Encore.COM>
Reply-To: clements@BBN.COM (Bob Clements)
Distribution: na
Organization: BBN Advanced Computers Inc., Cambridge MA
Lines: 80
I've been resisting posting on this thread, but I guess I will break down
and comment on this one. As an introduction, I was the project engineer
for the KA10. This means I was the junior of the two engineers (Alan
Kotok was the senior) who designed the logic. Being the junior, I had
to do more paperwork, so I was Project Engineer.
The true story behind JFFO:
The European sales force came to us and said they need a bit-search
instruction. A potential customer wanted to build a digital
phone exchange and needed to poll bits representing phone lines.
We were reluctant to add another incompatibility with the PDP-6.
We said "How many machines will we sell if we add this instruction?"
Answer: "Guaranteed five for a test bed, and hundreds if they go
with the project." So we added the instruction. The customer
didn't buy any.
In article <10907@xenna.Encore.COM> cook@encore.com writes:
>mmm@cup.portal.com (Mark Robert Thorson) recently posted that:
>|I heard a story that DEC had real problems getting one particular pdp-6 to
>|function (not surprising, it's made out of something called "delay-line
>|logic"), and that they pushed this lemon into the lake behind the converted
>|textile mill which was DEC's main plant in those days. Anyone care to
>|confirm that?
No way. Those babies cost a lot of money. Only 23 were built.
Major surgery might have been done, but never junking one. And if
one were junked, the parts would have been used.
>One last story. This one is about Alan Kotok (whose initials backwards
>gave the KA it's model designation)
Sorry, not so. Just a coincidence. All assemblies in those days
were assigned a two-letter/two-digit name. The trailing "10" is
obvious. The first letter named the general type of equipment.
"A" for Analog interfaces, "D" for Data communications, "M" for memories,
"R" for Rotating memories, etc. "K" was all processors and their internal
options. "KA" meant the main processor. The first PDP-11 processor was
a KA-11.
>and a certain PDP-6 that was sold
>to a major New York City firm and installed in a curtained fishbowl.
I can't think which machine this might be. I don't recall any -6's
in NYC.
>In those days each machine was a one-of-a-kind job complete with its
>own set of prints annotated with added capacitors "for noise suppression"
>and so forth. If an engineer's machine failed in the field, the
>engineer got on the plane and fixed it!
Well, there was a pretty good field service organization. Us engineers
got called out, but rarely. And usually I went out to nearby sites.
Alan got to go to the more exotic ones (U of Western Australia, etc.)
due to his two more years of seniority.
>So it was that Alan was dispatched to NYC to fix the machine in the
>fishbowl. After some consideration he had them close the curtains
>and everyone but a security guard leave the room. The guard and
>Alan then proceeded to pick up one end of the 6 and drop it! And
>sure enough, the little bit of wire that had fallen into the backplane
>came loose and timesharing was restored.
First, two guys couldn't lift the end of a PDP-6. Second, Alan
wouldn't have volunteered to do it if it could be done. Third,
that wasn't his debugging style. Sorry, I just don't believe
this story a-tall.
There were a lot of good stories, though. Pick up the DECUS tape
of the 20th anniversary 36-bit session in Anaheim (1984?) to hear
some of them. Like Alan filling for time at a live demo at FJCC
while I snuck around the back and replaced a card in a PDP-10
while the machine was running, without crashing the machine.
[Gee, this IS getting to be an old fart reminiscence thread. Well,
the JFFO story is "computer.architecture in the real world".]
> - Dale (N1US) Encore Computer Corporation, Marlborough, Mass.
>INTERNET: cook@encore.com
>UUCP: {buita || talcott || husc6 || bellcore} !encore!cook
/Rcc
Bob Clements, K1BC, clements@bbn.com (Making TC2000's these days.)
------- End of Forwarded Message
3-Aug-89 11:31:57-MDT,1118;000000000000
Return-Path: <@Score.Stanford.EDU:ittai@shemesh.gba.nyu.edu>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 3 Aug 89 11:31:45 MDT
Received: from shemesh.gba.nyu.edu by SCORE.STANFORD.EDU with TCP; Thu 3 Aug 89 10:24:41-PDT
Received: by shemesh.gba.nyu.edu (4.1/1.34)
id AA04476; Thu, 3 Aug 89 13:25:39 EDT
Date: Thu, 3 Aug 1989 13:25:35 EDT
From: Ittai Hershman <ittai@shemesh.gba.nyu.edu>
To: tops-20@score.stanford.edu
Cc: ccnet-managers@cunixc.cc.columbia.edu, bboard@vx1.gba.nyu.edu,
bboard@acfcluster.nyu.edu
Office-Phone: 212-285-6080
Subject: NYU20 bites the dust
Message-Id: <CMM.0.88.618168335.ittai@shemesh.gba.nyu.edu>
In case anyone is still counting, NYU20 was shutdown forever this
morning. DEC is currently ripping it out.
NYU20 was installed in 1978 as a DECSYSTEM-2050 with 256KW of memory,
two RP06 disk drives, and two TU45 tape-drives. In its halcyon days,
before it was marked for removal, it grew into a 2060 with 2MW of memory,
two RP07 disk drives, four RPO6 disk drives, and two TU-78 tape drives.
And so it goes...
-Ittai
30-Aug-89 11:56:29-MDT,6424;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 30 Aug 89 11:55:43 MDT
Date: Wed 30 Aug 89 12:55:17-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: [Werner Uhrig <werner@rascal.ics.UTEXAS.EDU>: [Anonymous: How DEC Works (Australian Perspective)] ] ]
To: tops20@wsmr-simtel20.army.mil
Message-ID: <12522290342.19.AI.CLIVE@MCC.COM>
Here is something which elegantly explains the business environment
that sold you your beloved dinosaur (to borrow a term from MRC)...
Enjoy!
Clive
------- Forwarded Message
Date: Tue, 29 Aug 89 16:02:41 -0700
From: <anonymous person at DEC>
Subject: How DEC Works (Australian Perspective)
Probably typical of most large companies; still, it seems
accurate.
[Headers deleted to protect the guilty. Make sure you remove mine
if you forward!]
Someone put the question to me the other day: What are the
relationships between Enterprise Services, System Integration, Large
Projects, Account Management, Prime Contracting and all the variants
of these.
Since this is a common question, I've taken the trouble to get it all
down in writing for you.
To answer your question, we really have to understand how Digital
operates. Visualize a whole series of playing fields spread out on a
vast plain, stretching out to the horizon in all directions. On each
field, there are several teams, of different sizes and types, but
there are only about a dozen different coloured uniforms, and teams of
each colour seem to have a bond with each other that spans the many
playing fields.
Some fields are large, and have all the colours represented, smaller
ones have only a few. There is one called SPR that is unique in having
all the colours, yet is only a very small field, and is so crowded the
players can hardly move.
On each field the teams jostle and push each other around, sometimes
they kick a ball around, other times they throw rocks at each other,
and for long periods will huddle in small groups mumbling in low
voices so the other teams can't hear. At random intervals, some
members of a team will gather on the sideline and yell insults at
members of the same coloured team in a neighbouring field. We do not
yet understand why they do this, but both parties seem to find it most
enjoyable.
Occasionaly, all the other teams in a field will gang up on another
one, and succeed in destroying it; the members of the victim team
either become members of other teams, or are driven off the playing
field. No-one has ever figured out the rules that apply to these games
on the playing fields, although it is fairly certain that the players
themselves do know.
Every now and again, play stops, and the parade begins. We do know
that whoever leads the parade wins, and the extraordinary thing is
that the teams from each field always form up in the almost the same
colour sequence. The parades are a lot of fun, with bands and drums
all competing with each other, and much cheerfull banter between the
teams.
The right to lead the parade seems to be associated with various
banners, standards and flags that the teams occasionaly fight over
during play. The banners change from time to time, and have letters or
words such as OSF, Enterprise Services, Customer Services, LCG, 36 is
better than 32, Level of Service, Network is the System, Own the
Database, B$ST, Follow the Marketing Plan, UNIX, Sell Solutions,
FMD's, Large Projects, DPM, Solution Selling, and so on. When play
stops and the parade begins, whoever owns certain flags gets a better
position in the parade.
In the centre are some extra large playing fields, and we know these
are called 'Corporate'; confusingly, all the others around this centre
are called the 'Field'.
The teams on the coporate fields have the ability to create flags and
banners, which they do so in great secrecy; if another team suspects a
flag is being made, they will try and tear it up. When a new flag is
ready, it is taken out to as many of the other fields as possible, and
the teams on each field will fight over it, or ignore it, or even
share it, although this is rare. We have never been able to predict
how the 'Field' teams will react to a new flag.
Well, those are the rules. Lets see what's been going on with the
banners 'Account Management', 'Enterprise Services', 'Large Projects',
and 'System Integration'.
Account Management has always been owned by a team called Sales; from
time to time other teams get a hand on it, but the most they ever
acheive is to share it for a while. Mostly the other teams seem to
thinks Sales should have it, and concentrate on arguing that it is not
as large and important a banner as Sales says it is. 'Large Projects'
is a new banner, and we're not sure where it came from. It is only a
flag really, but there has been a lot of squabbling around it, mostly
over how to share it. Sales seem to be very determined to own it
exclusively, perhaps to shore up the 'Account Management' banner. The
other teams are are not sure they want to own this flag, but don't
want Sales to own it.
Enterprise Services is a biggie. It was made by a Corporate team, one
of the marketing ones, who showed it to a few of the playing fields
near Corporate. A team called 'Field Service' saw it first, and ran
off with it, and gave it to every Field Service team on the plain.
Only then did all the other teams see what a useful banner it was, and
start to fight for it. Here in SPR, a team called SWS, with help from
other teams, has managed to get a hand to it, and so now it is a
shared banner.
Meanwhile, on one of the corporate fields, the head of the SWS team
has grabbed a new banner called 'System Integration' and is trying to
establish it as a more important banner than 'Enterprise Services'.
This is still in play, so I can't actually answer your question right
now, but I think you'll have a better feel for how the game is played,
and this should increase its entertainment value for you.
I can tell you there is a big game scheduled for Monday, March the
13th, in Chatswood and I've all got a ticket to the main stand. I'll
give you all a ball-by-ball account on my return.
------- End of Forwarded Message
-------
30-Aug-89 12:05:06-MDT,993;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 30 Aug 89 12:05:03 MDT
Date: Wed 30 Aug 89 13:04:51-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: DEC to make MAINFRAMES!
To: tops20@wsmr-simtel20.army.mil
Message-ID: <12522292082.19.AI.CLIVE@MCC.COM>
And in other news, this item was sent to me by Mabry Tyson at SRI:
San Jose Mercury News: August 30, 1989 Page 3F:
DEC TO MAKE MAINFRAMES:
Digital Equipment Corp. of Maynard, Mass. plans to introduce a line of
computers this fall that Digital executives hope will give the company
an entry into the mainframe class. Analysts said the line, called Vax
9000 and code-named Aquarius, will compete with computers made by
International Business Machines Corp., Unisys Corp., Amdahl Corp.,
Tandem Computers Inc. and others. Digital relies heavily on sales of
minicomputers, but that market is slumping.
How quickly they forget...
Clive
-------
5-Sep-89 10:20:11-MDT,3457;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 5 Sep 89 10:19:07 MDT
Date: Tue 5 Sep 89 11:17:28-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: 36-Bit Anniversary Celebration
To: tops20@wsmr-simtel20.army.mil
Message-ID: <12523845397.19.AI.CLIVE@MCC.COM>
A special event will take place at the Fall DECUS Symposium in Anaheim,
California, November 6-10, 1989: The 25th Anniversary of 36-bit systems
will be celebrated. In 1964, Digital announced the PDP-6. Twenty-five
years later, the 36-bit architecture is still here serving a loyal
customer base.
The celebration will take place on the evening of Monday, November 6,
1989. The usual DEC 10/20 Update Session will be held from 3-5 PM.
Last-minute announcements regarding Anniversary events will be made at
this session, as well as in the Monday edition of Update.Daily (the
Symposium newspaper). A meeting room in one of the Symposium hotels
(Hilton or Marriott) will be made available for the anniversary
events, which include:
-- 36-Bit JEOPARDY!
In the tradition of the 36-bit Trivia Bowl held at the
20th Anniversary celebration, experts on the history
and folklore of 36-bit systems will compete against
each other. Come and match wits with them!
-- Memorabilia Exhibit and Swap
You are encouraged to bring old manuals, listings,
pieces of hardware (e.g. KA and/or KI consoles!),
posters, buttons, tapes, and any other items related
to 36-bit systems for exhibiting and/or swapping.
Table space will be made available.
-- Anniversary Dinner
Dinner plans are not yet firm. It will either be
catered by the hotel or we will adjourn to a nearby
restaurant.
-- 36-Bit Magic & War Stories
Following dinner we will swap war stories and other
legends of 36-bit lore. One of the most popular
events of the 1984 celebration will be repeated: a
reading of several infamous SPR's (and their equally
infamous replies.) Come prepared to share share your
favorite stories. Prizes for the best will be
awarded.
Note that these four events will NOT appear in the DECUS schedule
since they are not official DECUS functions (and therefore do not
require conference registration.) If you are planning to attend any
of the 25th Anniversary events, please notify me as soon as possible,
since we need to get a reasonable estimate on the number of people to
expect. (Dinner plans depend on this, so please try not to delay.)
E-mail: Clive@MCC.COM
U.S. mail: MCC, 3500 West Balcones Center, Austin, TX 78759
Phone: (512) 338-3430
This will also enable us to create a mailing list for any last minute
announcements regarding the events. If you would like table space for
exhibits, please mention this. Suggestions regarding dinner plans are
also welcome. It may be difficult to find a reasonable restaurant
nearby that could handle this. The 20th anniversary dinner was done
by the hotel at a cost of $36/person (what else?!). Is this a
reasonable fee? If not, let me know how much you would be willing to
pay.
This message is being sent to the TOPS-20 mailing list and the comp.arch
news group. Please redistribute as you see fit and pass the word to
other 36-bitters who may not otherwise find out about this.
See you in Anaheim!
Clive
-------
8-Sep-89 16:53:44-MDT,1617;000000000000
Mail-From: PANDA created at 8-Sep-89 16:51:19
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Fri, 8 Sep 89 16:51:22 MDT
Date: Fri, 8 Sep 89 12:51:20 PDT
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: fun in the madhouse
To: KS-OWNERS@KICKI.STACKEN.KTH.SE, TOPS-20@WSMR-SIMTEL20.Army.MIL
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2020
Phone: +1 (206) 842-2385
Message-ID: <12524670763.7.MRC@PANDA.PANDA.COM>
I returned from a long trip to find that my source disk drive, previously
known to be flakey, had given up entirely. The READY light was flashing and
the FAULT light was lit. I tried pressing the FAULT button but that did not
clear it. Since I wanted to open it up to take a look, I hit the START button
to shut it off, but it wouldn't go off.
Eventually I powered it down by hitting the breaker. I found out why it
wouldn't go off -- the heads hadn't retracted!! So, I'm almost certain that
I have lost both drive and pack. Fortunately, my most critical sources were
on my PS:, which is presently my only (out of 4 RM03's) working disk drive.
Since I don't have my tape drive working yet either, I'm a bit concerned.
I can't seem to find RM03's available any more. I've heard a rumor that RP06's
(which still are available) can be run single-phase; purportedly you need to
give them a 220V circuit and you can tie the third leg to one of the other legs.
Is this true, and if so can anyone supply the details?
Peter, is there any hope on the SCSI interface front?
-------
12-Sep-89 17:01:19-MDT,1160;000000000000
Return-Path: <CCDARG%vaxb.cc.dundee-tech.ac.uk@NSFnet-Relay.AC.UK>
Received: from NSFnet-Relay.AC.UK by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 12 Sep 89 17:01:10 MDT
Received: from vaxb.cc.dundee-tech.ac.uk by NSFnet-Relay.AC.UK
via Janet with NIFTP id aa06869; 12 Sep 89 14:01 BST
Date: 12-SEP-1989 13:50:15
From: CCDARG%vaxb.cc.dundee-tech.ac.uk@NSFnet-Relay.AC.UK
To: tops-20 <@NSFnet-Relay.AC.UK:tops-20@wsmr-simtel20.army.mil>
Subject: Re: Mark's Disk problems
Mark,
Compared with the cost of an RPO6 (even an obsolete one) I'd have thought
the cost of installing 3 phase in your home would be trivial ! Certainly
in the UK its fairly easy for domestic customers to get 3 phase. After all
in a well balanced supply the other 2 phases shouldn't be very far away
from you. How well do u get on with your neighbours ? Chances are the
2 nearest could come in handy. I've managed to rig up temporary three
phase supplies before by plugging into 3 single phase supplies so its
not too hard.
Taking into account though the reliability, noise and size of an RP06
I don't think I'd want one in my living room.
Alan Greig
13-Sep-89 16:09:00-MDT,2012;000000000000
Return-Path: <JWEINER@ccr1.bbn.com>
Received: from ccr1.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 13 Sep 89 16:08:42 MDT
Date: Wed, 13 Sep 89 18:01 EDT
From: JERRY WEINER X3242 <JWEINER@ccr1.bbn.com>
Subject: Need soem help w/ TCP Mail
To: TOPS-20@WSMR-SIMTEL20.ARMY.mil
Folks,
I need a bit of help to get TCP MAIL going.
SYSTEM is running TOPS-20 V7 (DEC unpatched) w/ DEC TCP/IP. I am using
the MAIL stuff DEC supplies (MMAILR,MMAILBOX,MX,MAISER,SMTJFN).
I have set NETFLG in MX to -1 .
We can send mail from the TOPS-20 system to any where.
Any MAIL send to the TOPS-20 system is rejected. Two different
reject messages are pasted below.
If I am missing some "data files", I needto know how to
create them.
Thanx,
Jerry
From: IN%"Mailer@BBNG.bbn.com" "The Mailer Daemon" 13-SEP-1989 17:17
To: JWEINER@ccr1.bbn.com
Subj: Message of 13-Sep-89 17:24:32
Return-path: Mailer@BBNG.bbn.com
Received: from BBNG.BBN.COM by ccr1.bbn.com via TCP; Wed Sep 13 17:16 EDT
Date: Wed 13 Sep 89 17:24:34-EDT
From: The Mailer Daemon <Mailer@BBNG.bbn.com>
Subject: Message of 13-Sep-89 17:24:32
To: JWEINER@ccr1.bbn.com
Message failed for the following:
jweiner@BBNG.BBN.COM.#Internet: File not found
------------
Received: from ccr1.bbn.com by BBNG.BBN.COM with TCP; Wed 13 Sep 89 17:24:33-EDT
Date: Wed, 13 Sep 89 17:14 EDT
From: JERRY WEINER X3242 <JWEINER@ccr1.bbn.com>
To: jweiner@g.bbn.com
-------
From: IN%"Postmaster@ccr1.bbn.com" "PMDF Mail Server" 13-SEP-1989 16:44
To: JWEINER@ccr1.bbn.com
Subj: Undeliverable mail
Date: Wed, 13 Sep 89 16:43 EDT
From: PMDF Mail Server <Postmaster@ccr1.bbn.com>
Subject: Undeliverable mail
To: JWEINER@ccr1.bbn.com
The message could not be delivered to:
Addressee: JWEINER@BBNF.bbn.com
Reason: Illegal host/domain name found.
----------------------------------------
Date: Wed, 13 Sep 89 16:42 EDT
From: JERRY WEINER X3242 <JWEINER@ccr1.bbn.com>
To: JWEINER@BBNF.bbn.com
13-Sep-89 16:38:12-MDT,1485;000000000000
Mail-From: PANDA created at 13-Sep-89 16:37:02
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Wed, 13 Sep 89 16:37:04 MDT
Date: Wed, 13 Sep 89 11:44:36 PDT
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: Re: Mark's Disk problems
To: CCDARG%vaxb.cc.dundee-tech.ac.uk@NSFnet-Relay.AC.UK
cc: TOPS-20@WSMR-SIMTEL20.Army.MIL
In-Reply-To: Message from "CCDARG%vaxb.cc.dundee-tech.ac.uk@NSFnet-Relay.AC.UK" of Wed, 13 Sep 89 03:20:37 PDT
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2020
Phone: +1 (206) 842-2385
Message-ID: <12525969336.7.MRC@PANDA.PANDA.COM>
Alan -
RP06's "can be had for a song" these days -- in other words their
cost is near $0 and some companies have surplus RP06's that they'll give
away if you'll pay for the shipping. Although I've avoided RP06's, I
don't see much choice until/unless the SCSI interface becomes available.
Around here, they use an entirely different transformer configuration
if they are going to provide 3 phase. I live in a rural area of 1-acre
lots; the transformer for our neighborhood (single phase) is on the opposite
side of the block across the street. Power to my house goes underground
about 1/3 mile from that transformer.
The nearest 3 phase transformer is miles away.
In other words, we're talking *big* dollars to get 3 phase in my
house. This is true of most other US residences.
-- Mark --
-------
14-Sep-89 17:49:57-MDT,1389;000000000000
Mail-From: PANDA created at 14-Sep-89 17:48:13
Return-Path: <MRC@PANDA.PANDA.COM>
Received: from PANDA.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Thu, 14 Sep 89 17:48:16 MDT
Date: Thu, 14 Sep 89 11:02:53 PDT
From: Mark Crispin <MRC@PANDA.PANDA.COM>
Subject: Re: Need soem help w/ TCP Mail
To: JWEINER@ccr1.bbn.com
cc: TOPS-20@WSMR-SIMTEL20.Army.MIL
In-Reply-To: Message from "JERRY WEINER X3242 <JWEINER@ccr1.bbn.com>" of Thu, 14 Sep 89 04:13:20 PDT
Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2020
Phone: +1 (206) 842-2385
Message-ID: <12526223884.7.MRC@PANDA.PANDA.COM>
Jerry -
As a first step, you should throw out the mail stuff DEC supplies (it
is just something to get you started) and get the modern mailsystem from
WSMR-SIMTEL20's PS:<MM> tree (or perhaps it's SS:<MM>). MM is the standard
mailsystem for the DEC-20, and also includes the most modern versions of
MMAILR, MMAILBOX, MAISER, etc.
I am the author of the TOPS-20 mail software so I know of what I speak.
You should also get a copy of the TOPS-20 domain resolver; contact
SRA@LCS.MIT.EDU for the latest information of how to retrieve it.
Now, as far as your particular problem goes, it sounds to me as if
the destination MAIL.TXT.1 file does not exist. It should exist, and have
the FB%PRM (permanent) bit set in the FDB.
-- Mark --
-------
15-Sep-89 18:15:55-MDT,1418;000000000000
Return-Path: <sra@lcs.mit.edu>
Received: from lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 15 Sep 89 18:15:45 MDT
From: Rob Austein <sra@lcs.mit.edu>
Sender: sra@lcs.mit.edu
To: TOPS-20@wsmr-simtel20.army.mil
CC: JWEINER@ccr1.bbn.com
In-reply-to: Mark Crispin's message of Thu, 14 Sep 89 11:02:53 PDT <12526223884.7.MRC@PANDA.PANDA.COM>
Subject: Need soem help w/ TCP Mail
Date: Fri, 15 Sep 89 19:58:22 EDT
Message-ID: <8909151958.aa06150@mintaka.lcs.mit.edu>
Since I've already had a query from someone other than Jerry about
this:
The distribution sources of the CHIVES domain resolver code live on
WSMR-SIMTEL20.ARMY.MIL in the directory PS:<CHIVES> and its children.
Thanks to Frank Wancho for giving them a home when XX.LCS.MIT.EDU went
away. So you can do all your mailer code shopping in one place.
There are -READ-.-THIS- files in the directory tree that should
explain everything you need to know to install CHIVES.
One change since the last time I sent a message about CHIVES to this
list: thanks to the efforts of some people at DEC, the hooks needed by
CHIVES in the IPCF and IPIPIP modules are present in DEC monitors as
of TOPS-20 7.0 autopatch 20. So sites without monitor sources should
be able to build a monitor with the GTDOM% JSYS without any particular
problems.
Queries, bug reports, etcetera, should still be sent to
BUG-CHIVES@LCS.MIT.EDU.
--Rob
15-Sep-89 20:09:29-MDT,970;000000000000
Return-Path: <wuts%altair.usc.edu@usc.edu>
Received: from usc.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 15 Sep 89 20:09:26 MDT
Received: from altair.usc.edu by usc.edu (5.59/SMI-3.0DEV3) id AA01126;
Fri, 15 Sep 89 18:33:45 PDT
Received: by altair.usc.edu (4.0/SMI-3.0DEV3) id AA12444;
Fri, 15 Sep 89 18:33:42 PDT
Date: Fri, 15 Sep 1989 18:33:40 PDT
From: Maurice J. Wuts <wuts%altair.usc.edu@usc.edu>
To: tops20@wsmr-simtel20.army.mil
Subject: The last one at USC.
Message-Id: <CMM.0.88.621912820.wuts@altair.usc.edu>
Well another one bites the dust. The last of our 6 20's was turned
off today. Its uptime is significant compared to our VAX-6320 which
crashes daily.
ECLA!ld
Load 2.33 2.32 1.95 -- 1L+7D+17S jobs
Uptime: 924:26:20!!!!!!!!! Fri 9/15/89 15:54:02
Jb TTY User
26 57 Wuts 2:19:21,LD
ECLA!
I guess I'll be seeing some of you at usenix instead of decus.
Maurice
17-Sep-89 14:30:29-MDT,933;000000000000
Mail-From: WANCHO created at 17-Sep-89 14:30:23
Date: Sun, 17 Sep 1989 14:30 MDT
Message-ID: <WANCHO.12527037166.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: DUMPER problem
Before I go off and submit an SPR, would someone tell me if there's
some obscure (or other) reason why DUMPER doesn't save files which are
deleted, but permanent?
I have many alternate mail files, all set permanent, some of which
happen to be empty and deleted at the time of a full backup. But,
because they have not been saved, do not exist after a restore. I get
reminded about that fact the next time the mailer wants to write to
them. We don't have to do restores all that often, but the problem is
very annoying when it happens.
Anybody happen to have already fixed this problem in DUMPER 560?
--Frank
18-Sep-89 18:35:22-MDT,842;000000000000
Return-Path: <GROSSMAN@Score.Stanford.EDU>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 18 Sep 89 18:35:17 MDT
Date: Mon 18 Sep 89 17:32:57-PDT
From: Stu Grossman <GROSSMAN@Score.Stanford.EDU>
Subject: Re: DUMPER problem
To: WANCHO@WSMR-SIMTEL20.ARMY.MIL
cc: TOPS20@WSMR-SIMTEL20.ARMY.MIL
In-Reply-To: <WANCHO.12527037166.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Message-ID: <12527343469.13.GROSSMAN@Score.Stanford.EDU>
Frank,
Why not set the files to be INVISIBLE instead of DELETED? Then,
at least DUMPER would always back up your files.
Arguments about whether DUMPER should save deleted files could
reasonably go either way. I'm inclined to say that you shouldn't delete
anything that you really want to keep around (regardless of the fact that
it may have the perm bit on).
Stu
-------
18-Sep-89 20:22:31-MDT,1180;000000000000
Mail-From: WANCHO created at 18-Sep-89 20:22:28
Date: Mon, 18 Sep 1989 20:22 MDT
Message-ID: <WANCHO.12527363404.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: Stu Grossman <GROSSMAN@SCORE.STANFORD.EDU>
Cc: TOPS20@WSMR-SIMTEL20.ARMY.MIL, WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: DUMPER problem
In-reply-to: Msg of 18 Sep 1989 18:32-MDT from Stu Grossman <GROSSMAN at Score.Stanford.EDU>
Stu,
The problem is that when a mail file becomes empty, MM deletes it.
There's no choice in the matter. Other programs, such as BBSPLIT and
BBTRIM do likewise. The behavior of these programs is both reasonable
and expected, provided one understands that these files are permanent
and that MMAILR will resurrect them when needed.
My point is that DUMPER is shortsighted because it knows that a
regular user directory will contain a deleted, permanent MAIL.TXT file
when the directory is CREATEd on a DUMPER RESTORE, and so those files
are ignored during a SAVE. What it ignores are the other deleted,
permanent mail files which aren't automatically created by a CREATE,
nor by MMAILR for security reasons.
--Frank
19-Sep-89 12:01:32-MDT,448;000000000000
Mail-From: WANCHO created at 19-Sep-89 12:01:28
Date: Tue, 19 Sep 1989 12:01 MDT
Message-ID: <WANCHO.12527534345.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: Missing LGOUT% in FTPSRT
In versions of FTPSER based on FTPSRT.MAC.47, at DETINT+7, insert
LGOUT% between the SKIPN DBUGSW and the ERJMP LGOFAI.
--Frank
20-Sep-89 08:48:09-MDT,1540;000000000000
Return-Path: <sra@lcs.mit.edu>
Received: from lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 20 Sep 89 08:47:57 MDT
From: Rob Austein <sra@lcs.mit.edu>
Sender: sra@lcs.mit.edu
To: WANCHO@wsmr-simtel20.army.mil
CC: TOPS20@wsmr-simtel20.army.mil
In-reply-to: "Frank J. Wancho"'s message of Mon, 18 Sep 1989 20:22 MDT <WANCHO.12527363404.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Subject: DUMPER problem
Date: Wed, 20 Sep 89 2:12:43 EDT
Message-ID: <8909200212.aa26075@mintaka.lcs.mit.edu>
Frank,
We eventually gave up on permanent bits on mail files as a bad job,
and changed MMAILR so that it could create new mail files if
necessary. If you require that the world-can-create-new-files bit
(000004) in the directory protection be on for this to happen, and
have MMAILR turn on the world-append (000004) bit in the file
protection of files it creates, it works tolerably well. As part of
this hack, we allowed a generation number of -1 on *FILE addresses,
causing each message to be delivered to a separate generation of the
same filename. This was useful for programs like INQUIR that took
incoming mail messages and did something with them, since it allowed
these programs to rename the request on which they were currently
working and thus avoid having to play locking games with MMAILR.
Another approach would be to change MM so that instead of deleting and
expunging an empty mail file, it just used PMAP% and CHFDB% to throw
away the file's contents. I suppose this could be a SET option in MM.
--Rob
7-Oct-89 17:41:32-MDT,846;000000000000
Return-Path: <LIEN@KICKI.STACKEN.KTH.SE>
Received: from KICKI.STACKEN.KTH.SE by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 7 Oct 89 17:40:58 MDT
Return-Path: <LIEN@KICKI.STACKEN.KTH.SE>
Date: 8-Oct-89 0:38:50 +0100
From: Jan Lien <LIEN@KICKI.STACKEN.KTH.SE>
To: tops20@wsmr-simtel20.army.mil, ai.clive@mcc.com
Subject: Decus Anaheim
Message-ID: <12532325280.21.1052.145600@KICKI.STACKEN.KTH.SE>
I am considering going to Anaheim, but have not decided yet. My main
objection is that it is only a one-day trip, as I am not interested in
paying for the decus meeting. I am only intereted in T-10/20, and
definetly not paying to listen to VAX talks. Is there anything else
to see (near or at other ends) while in the US (about computing) ?
Does anyone know how many people there will be for the 36-bit evening ?
--------
8-Oct-89 23:12:55-MDT,734;000000000000
Mail-From: WANCHO created at 8-Oct-89 23:12:51
Date: Sun, 8 Oct 1989 23:12 MDT
Message-ID: <WANCHO.12532637305.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject: MSS bug
Only for DEC TCP Monitors:
PROBLEM: In TCPTCP.MAC, the code at MSLXCT extracts the MSS option
value from the SYN packet and then calls TCPMXP to set the TSMXP value
in the TCB for the connection. But, the TSMXP value is defined to be
the MSS value PLUS the minimum values of 20 each for the TCP and IP
headers.
SOLUTION: At MSLXC4+4 in TCPTCP.MAC, insert:
ADDI T1,MINIHS+MINTHS
just before the CALL TCPMXP.
--Frank
9-Oct-89 11:34:08-MDT,1253;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 9 Oct 89 11:34:05 MDT
Date: Mon 9 Oct 89 12:33:37-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: Re: Decus Anaheim
To: LIEN@KICKI.STACKEN.KTH.SE
cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: <12532325280.21.1052.145600@KICKI.STACKEN.KTH.SE>
Message-ID: <12532772156.32.AI.CLIVE@MCC.COM>
From: Jan Lien <LIEN@KICKI.STACKEN.KTH.SE>
To: tops20@wsmr-simtel20.army.mil, ai.clive@mcc.com
Subject: Decus Anaheim
[...]
Does anyone know how many people there will be for the 36-bit
evening?
My last message to the TOPS20 mailing list has yielded about 25
RSVP's. When the October Software Dispatches hit the streets (has
anybody received the hardcopy version yet?) I will get at least that
many more. My current guess is that we'll have between 50-100 people
there, including those who won't find out about it until they get to
DECUS.
If you're planning on coming, and haven't RSVP'd to me, please do so!
Dinner plans depend on this. Also, if you know the whereabouts of
any ex 36-bit folks who are no longer on this list (e.g. Randy Frank,
Norm Samuelson, etc.) please send me pointers to them.
Clive
-------
25-Oct-89 15:19:29-MDT,1185;000000000000
Mail-From: WANCHO created at 25-Oct-89 15:18:45
Date: Wed, 25 Oct 1989 15:18 MDT
Message-ID: <WANCHO.12537007443.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: TOPS20@WSMR-SIMTEL20.ARMY.MIL
cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL, MRC@WSMR-SIMTEL20.ARMY.MIL
Subject: More on MTU values
In TCPTCP.MAC, the code at TCPMXP is designed to take a zero value in
T1 as a special case, and, depending on the value of the foreign host
address, set the TSMXP. However, TCPMXP is called from only one place
with a zero value in T1: at the end of RSTADR, and the foreign host is
typically wild, resulting in TSMXP being set to 576. RSTADR, in turn,
is called from two other locations to reset the TCB values for reuse,
such as in the case of an failed or expired SYN.SYN. The restored
value for TSMXP should be the same as for a newly created TCB (as in
NEWTCB), and the value set the same way.
Thus, at RSTADR+14, (just before the RET) replace:
SETZ T1,
CALL TCPMXP ; Undo max packet size
with:
MOVX T1,<<1B<35-WID(PIPL)>>-1> ; Max possible packet 2**16-1 octets
STOR T1,TSMXP,(TCB) ; including headers
--Frank
26-Oct-89 10:11:34-MDT,741;000000000000
Return-Path: <PELL@ELINOR.LYSATOR.LIU.SE>
Received: from KICKI.STACKEN.KTH.SE by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 26 Oct 89 10:11:15 MDT
Return-Path: <PELL@ELINOR.LYSATOR.LIU.SE>
Received: from ELINOR.LYSATOR.LIU.SE by KICKI.STACKEN.KTH.SE; Thu, 26 Oct 89 17:11:23 +0100
Date: Thu, 26 Oct 89 17:14:22 O
From: P{r Emanuelsson <Pell@ELINOR.LYSATOR.LIU.SE>
To: tops20@wsmr-simtel20.army.mil
Subject: tar
Message-ID: <12537236022.13.PELL@ELINOR>
Hi! Anyone got a good "tar" program? You know, from that strange
little "OS" with the funny name...
/Pell
--
Dept. of Electrical Engineering pell@isy.liu.se
University of Linkoping, Sweden ...!uunet!isy.liu.se!pell
-------
27-Oct-89 17:48:37-MDT,1464;000000000000
Return-Path: <munnari!charlie.cc.deakin.OZ.AU!ccw@uunet.UU.NET>
Received: from uunet.uu.net by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 27 Oct 89 17:48:00 MDT
Received: from munnari.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14846; Fri, 27 Oct 89 19:47:20 -0400
Received: from munnari.oz.au (munnari.oz) by murtoa.cs.mu.oz (5.5)
id AA19971; Sat, 28 Oct 89 09:44:28 EST
(from ccw@charlie.cc.deakin.OZ.AU for uunet!tops20@wsmr-simtel20.army.mil)
Received: from charlie.cc.deakin.oz by munnari.oz.au with SunIII (5.61+IDA+MU)
id AA23225; Sat, 28 Oct 89 09:44:23 +1000
(from ccw@charlie.cc.deakin.OZ.AU for tops20@wsmr-simtel20.army.mil@murtoa.cs.mu.OZ.AU)
Message-Id: <8910272344.23225@munnari.oz.au>
Received: by charlie.cc.deakin.oz (5.54)
id AA03894; Sat, 28 Oct 89 09:43:44 EST
To: P{r Emanuelsson <Pell%ELINOR.LYSATOR.LIU.SE@murtoa.cs.mu.OZ.AU>
Cc: tops20@wsmr-simtel20.army.mil
Subject: Re: tar
In-Reply-To: Your message of Thu, 26 Oct 89 17:14:22 +0200.
<12537236022.13.PELL@ELINOR>
Date: Sat, 28 Oct 89 09:43:34 +1000
From: Craig Warren <munnari!charlie.cc.deakin.OZ.AU!ccw@uunet.UU.NET>
Date: Thu, 26 Oct 89 17:14:22 O
From: P{r Emanuelsson <Pell%ELINOR.LYSATOR.LIU.SE@murtoa.cs.mu.oz>
Hi! Anyone got a good "tar" program? You know, from that strange
little "OS" with the funny name...
I have a version of Tar I got off Mark Crispin. Let me know if
you would like a copy.
14-Nov-89 13:31:40-MST,3289;000000000000
Return-Path: <budd@bu-it.BU.EDU>
Received: from bu-it.BU.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Nov 89 13:31:20 MST
Received: from BUIT2.BU.EDU by bu-it.BU.EDU (5.58/4.7)
id AA03332; Tue, 14 Nov 89 15:30:36 EST
Return-Path: <budd@bu-it.bu.edu>
Received: by buit2.bu.edu (3.2/4.7)
id AA02309; Tue, 14 Nov 89 15:30:31 EST
Date: Tue, 14 Nov 1989 15:30:27 EST
From: Phil Budne <budd@bu-it.BU.EDU>
To: tops-20@wsmr-simtel20.army.mil
Subject: DECUS SNOBOL/FASBOL
Cc: budd@bu-it.bu.edu
Message-Id: <CMM.0.88.627078627.budd@buit2.bu.edu>
Anyone out there have copies of DECUS SNOBOL4 (10-104 aka 20-28) or
FASBOL II (10-179A aka 20-57)? I always used SITBOL when we had our
'20, but I'm interested in perusing the source!
Those who still have machines with those precious extra 4 bits I have
some files squirled away from the good old days available for ftp;
On BU.EDU in ~ftp/users/budd/bucs20 (an incomplete listing);
-rw-r--r-- 1 budd 14116 Apr 14 1988 ALL.DIR
A full ls before things were tar'ed and feather'ed (compressed)
-rw-r--r-- 1 budd 12367 Mar 4 1988 decapr.new.16.Z
-rw-r--r-- 1 budd 12001 Mar 4 1988 decapr.old.1.Z
-rw-r--r-- 1 budd 11924 Mar 4 1988 decapr.txt.4.Z
The list of CPU APR ID's I kept from reading s/w dispatches!
-rw-r--r-- 1 budd 339691 Jun 13 1988 games.tar.Z
haunted house, VTTREK(!!), adventure, Dr. Sluggo
-rw-r--r-- 1 budd 724801 Jun 13 1988 hacks.tar.Z
Many small CUSPS I wrote over the years;
SYSDPY "AN" for TOPS-20 5.4
arpdmp -- Arp table dump
bigben -- console time stamp
creep/crawl -- DECnet topology creeper (talks to NML!)
ctyspy -- keeps console log in a ringbuffer (via a TLINK)
cz -- a cd replacement for the rutgers exec (needs "install")
events -- what happened today in history
lims -- ITS limerick program
ITS srccom with comnd interface!!
du -- display usage for a directory tree
biorhythms
local hacks to mmailer and nddt
drwxr-sr-x 2 budd 512 Oct 4 1988 newvttrek/
Just the vttrek sources.
-rw-r--r-- 1 budd 1666 Mar 4 1988 pcap.emacs.1.Z
-rw-r--r-- 1 budd 583 Mar 4 1988 pcap.mac.1.Z
Commands to "ENABLE" and "DISABLE" your EMACS fork!!
-rw-r--r-- 1 budd 28177 Jun 13 1988 pcl.tar.Z
Various PCL routines
-rw-r--r-- 1 budd 86093 Jun 13 1988 phone.tar.Z
My Phone-20 program (speaker to VMS)
-rw-r--r-- 1 budd 131 Mar 4 1988 prime.bas.1.Z
-rw-r--r-- 1 budd 49597 Jun 13 1988 rsh.tar.Z
An attempt at a BSD style RSH daemon (using Utah C)
-rw-r--r-- 1 budd 5824 Jun 13 1988 snobol.tar.Z
A few snobol favorites
-rw-r--r-- 1 budd 69249 Jun 13 1988 socket.tar.Z
An start at a BSD socket() library (using Utah C)
-rw-r--r-- 1 budd 175116 Jun 13 1988 stuff.tar.Z
Some CUSPS: canal -- a dump analyzer, etc...
-rw-r--r-- 1 budd 51380 Jun 13 1988 udp.tar.Z
My UDP: device (for 5.4)
-rw-r--r-- 1 budd 416380 Jun 13 1988 zl-emacs.tar.Z
Emacs modifications to do Ziv-Lempel (compress) compression for
display output, and C code to run on the "other end" (before
high-speed modems!)
15-Nov-89 14:48:55-MST,2147;000000000000
Return-Path: <AI.CLIVE@MCC.COM>
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Nov 89 14:48:45 MST
Date: Wed 15 Nov 89 15:48:19-CST
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: 36-Bit 25th Anniversary Report
To: tops-20@wsmr-simtel20.army.mil
Message-ID: <12542517851.61.AI.CLIVE@MCC.COM>
For those of you who didn't make it to Anaheim, I thought I'd
send out a brief report on the events of Monday, Nov. 6.
Activities got underway shortly after 5PM with an exciting game of
36-Bit Jeopardy, put together by Reed Powell from DEC plus folks from
his group. The three contestants were Mark Crispin from Univ. of
Washington, John Edgecombe from the Canadian Center for Remote
Sensing, and Greg Scott from DEC. After a round of Double Jeopardy
and a couple of rounds of Final Jeopardy, MRC came away as the winner
and claimed the prize, which was a 25th Anniversary T-Shirt.
Following the tradition established by the 20th anniversary VAX
BUSTERS T-Shirt, this shirt said "VAX BUSTERS II" above a picture of
Albert, the VAX Cheshire cat. Around the picture were the words "I
ain't afraid to take RISCS" and below, "DECSYSTEMS Continued". On the
back:
PDP-6 Systems
DECSystem-10's
DECSYSTEM-20's
The FIRST DEC Mainframes
25th Anniversary
After Jeopardy, we launched into the 36-Bit Magic and War Stories
session, which included the story of MIT-XX's trip across the country
and one about how a KA-10 console was mistaken for a synthesizer! MRC
even convinced me to read the full text of "Alice's PDP-10" (thanks,
SRA!). Between stories I read from my collection of outrageous and
humorous SPR's.
The evening was concluded with a subdued but pleasant dinner at the
Cattleman's Wharf restaurant, attended by about 50 people, one of whom
observed that perhaps we should start plans for the 36th anniversary
in the year 2000...!
Clive
P.S. There are few T-shirts left over, available at cost. If you're
interested, let me know.
-------
15-Nov-89 15:01:40-MST,1009;000000000000
Return-Path: <MKL@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Nov 89 15:01:36 MST
Date: Wed, 15 Nov 89 14:00:42 PST
From: Mark Lottor <MKL@NIC.DDN.MIL>
Subject: if only pdp-10's had been cheaper
To: tops20@wsmr-simtel20.army.mil
Message-ID: <12542520105.42.MKL@NIC.DDN.MIL>
From Unix Review: a quote from Ken Thompson in a speech after
receiving the ACM A.M. Turing Award for work in developing Unix (1984):
...
I am receiving this honor for timing and serendipity as much as
for technical merit. Unix swept into popularity with an industry
wide change from central mainframes to autonomous minis. I suspect
that Daniel Bobrow [1] would be here instead of me if he had not
been able to afford a PDP-10 and had to "settle" for a PDP-11.
...
[1] D.G. Bobrow, J.D. Burchfiel, D.L. Murphy and R.S. Tomlinson,
"TENEX, a paged timesharing system for the PDP-10",
Communications of the ACM, Vol 15, No 3. March 1972.
-------
22-Nov-89 04:31:12-MST,1213;000000000000
Return-Path: <JP@ELINOR.LYSATOR.LIU.SE>
Received: from KICKI.STACKEN.KTH.SE by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 22 Nov 89 04:30:58 MST
Return-Path: <JP@ELINOR.LYSATOR.LIU.SE>
Received: from ELINOR.LYSATOR.LIU.SE by KICKI.STACKEN.KTH.SE; Wed, 22 Nov 89 12:30:36 +0100
Date: Wed, 22 Nov 89 12:32:50 O
From: Johan Persson <JP@ELINOR.LYSATOR.LIU.SE>
To: tops20@wsmr-simtel20.army.mil
cc: JP@ELINOR.LYSATOR.LIU.SE
Subject: Is there a way not to log certain events
Message-ID: <12544273582.11.JP@ELINOR>
in the <SPOOL>OPERATOR-SYSTEM.LOG-file ? I've tried "DISABLE OUTPUT BATCH"
but that only disables the output on the console, not the logging-file.
We're running TOPS20, Monitor version 4.2(15757), command processor (EXEC)
version 5.1 (5707), version of OPR is 5(1040), version of ORION is 5(2507).
Our problem is that a program that is run in a batchjob sends a lot of
usermessages to both the batch-log AND to our system-logfile, which has
increased in size quite rapidly (more than it should anyway) and we
would like to prevent logging of this (and maybe other topics also) if
possible. Does anybody know how to do this?
/Johan Persson, sysop, jp@elinor.lysator.liu.se
-------
27-Nov-89 20:05:39-MST,1465;000000000000
Return-Path: <@Score.Stanford.EDU:DBigelow@EAGLE.WESLEYAN.EDU>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 27 Nov 89 20:05:25 MST
Received: from EAGLE.WESLEYAN.EDU by SCORE.STANFORD.EDU with TCP; Mon 27 Nov 89 19:05:05-PST
Date: 27-NOV-1989 22:08:03.36
From: Douglas Bigelow <DBigelow@EAGLE.WESLEYAN.EDU>
Subject: Experiences with CI20?
To: TOPS20@Score.Stanford.EDU
I'd like to hear from people who are using RA81 disk drives in a CI20 and
HSC environment.
I'm considering the purchase of a used CI and some RA81's to stick onto an
HSC50 that is likely to be "recycled" from a VAXcluster which will be
upgraded. This would serve one DECSYSTEM-2060.
In particular, I've been told that it's perfectly feasible to use one star
coupler to support both this one-node TOPS20 cluster AND a multi-node
VAXcluster. Is this true? If so, I could save a few pennies on the
purchase of another star coupler. Are there any disadvantages in terms of
traffic, bugs, contention, maintainability, whatever? Is this a good idea
or a bad one?
This would mean a sizable change in both hardware and software for a system
which is now running a non-CI 5.4 monitor, so any general warnings about a CI
environment would be appreciated.
Oh yes, this is probably a silly question but the last I knew only RA81s
were supported in this configuration. I don't suppose anyone ever added
RA82 support?...
Thanks -- Doug
28-Nov-89 11:26:37-MST,1391;000000000000
Return-Path: <@Score.Stanford.EDU:cmcl2!dasys1!adykes@rutgers.edu>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 28 Nov 89 11:26:34 MST
Received: from rutgers.edu by SCORE.STANFORD.EDU with TCP; Tue 28 Nov 89 10:25:56-PST
Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP
id AA00973; Tue, 28 Nov 89 13:25:20 EST
Received: by cmcl2.NYU.EDU (5.61/1.34)
id AA22147; Tue, 28 Nov 89 13:11:24 -0500
Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86)
id AA26312; Tue, 28 Nov 89 08:30:25 EST
Date: Tue, 28 Nov 89 08:30:25 EST
From: cmcl2!dasys1!adykes@rutgers.edu (Al Dykes)
Message-Id: <8911281330.AA26312@dasys1.UUCP>
To: DBigelow@eagle.wesleyan.edu, TOPS20@score.stanford.edu
Subject: Re: Experiences with CI20?
We ran CI-based DEC-20s and were very happy. Two comments;
You need "36 bit" HDA's in your RA81's. You can't reuse 32 bit formated
drives. DEC, and nobody else I could locate would reformat HDA modules
to allow us to reuse our DEC-20 drives on our VAX systems.
I have never heard of anyone sharing 36 bit and 32 bit systems on a
single CI. You can (and we have) split a SC008 in half. You can
then run two isolated clusters, without the redundancy of
the dual cabling.
We have some genuine 36 bit RA81s that we are about to dispose
of. make us an offer. I think we have 4.
3-Dec-89 18:49:07-MST,955;000000000000
Return-Path: <@Score.Stanford.EDU:A.JIML@GSB-How.Stanford.EDU>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 3 Dec 89 18:48:58 MST
Received: from GSB-How.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 3 Dec 89 17:48:20-PST
Date: Sun 3 Dec 89 17:48:57-PST
From: Jim Lewinson <a.Jiml@GSB-How.Stanford.EDU>
Subject: Yet Another Obituary
To: Tops-20@Score.Stanford.EDU
Message-ID: <12547280251.14.A.JIML@GSB-How.Stanford.EDU>
On Saturday, December 2, 1989 at about 9AM, GSB-Why.Stanford.EDU,
formerly SU-GSB-WHY.ARPA and SU-GSB-WHY, perceived that all 36 bits in
their true being were empty, was saved from all scheduling. It is
survived by its cluster sibling GSB-How.Stanford.EDU and three machines
that are missing 4 bits and not playing with a full DECk. Its long-term
memory organs and names were transplanted to its cluster sibling.
A memorial service is being planned.
Jim Lewinson
-------
5-Dec-89 11:43:48-MST,1111;000000000000
Return-Path: <A.ALDERSON@Macbeth.Stanford.EDU>
Received: from Macbeth.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 5 Dec 89 11:43:41 MST
Date: Tue 5 Dec 89 10:39:41-PST
From: Rich Alderson <A.ALDERSON@Macbeth.Stanford.EDU>
Subject: Re: Experiences with CI20?
To: DBigelow@EAGLE.WESLEYAN.EDU
cc: tops20@wsmr-simtel20.army.mil
In-Reply-To: Message from "Douglas Bigelow <DBigelow@EAGLE.WESLEYAN.EDU>" of Mon 27 Nov 89 22:08:03-PST
Message-ID: <12547726391.27.A.ALDERSON@Macbeth.Stanford.EDU>
I can't speak to your main question, because we have never run a Vaxcluster.
(We did have an experimental hookup in which a couple of 4.3bsd 780's were
taught MSCP using the same star coupler as our 20's, and never saw them as
problems...)
The main thing I wanted to warn you about is the version of HSC-50 code you
run: Version 3.9, the current release, doesn't support the 18-bit HDA. You
therefore want to get 3.7 or earlier. Talk to your FE (pardon me, your
"Customer Service Representative) about getting hold of older versions if the
HSC doesn't have it.
Rich Alderson
-------
6-Dec-89 09:01:39-MST,1564;000000000000
Return-Path: <@Score.Stanford.EDU:MKL@NIC.DDN.MIL>
Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 6 Dec 89 09:01:34 MST
Received: from NIC.DDN.MIL by SCORE.STANFORD.EDU with TCP; Tue 5 Dec 89 21:28:52-PST
Date: Tue, 5 Dec 89 21:29:01 PST
From: Mark Lottor <MKL@NIC.DDN.MIL>
Subject: MAISER bugs
To: tops20@score.stanford.edu
cc: mrc@wsmr-simtel20.army.mil
Message-ID: <12547844600.19.MKL@NIC.DDN.MIL>
There are a few bugs in the last version of MAISER I got (which
I think was the last released version). We noticed that incoming
SMTP connections were getting auto-logged-out for inactivity
less than 5 minutes (and many times as soon as the connection
was opened).
To fix this:
Get rid of the call to SETPSI in the .RSET routine. This starts
a second timer going that decrements the inactivity counter
twice as fast.
At the beginning of the HANGUP routine, add the following lines:
MOVE A,[.FHSLF,,.TIMAL] ;remove all pending timers
TIMER%
ERJMP .+1
Without this, a timer is still active when the MAISER fork HALTs.
The timer goes off (while the fork is halted!), and when the
next incoming connection restarts the fork, the interrupt takes
place before the RESET%, which causes another sequence of timers
to be activated. (there may be some bug with RESET% not killing
pending timers here).
The timers also occur at 5 second intervals, which seems a bit
much for a loaded system. I changed TIMOCT to be 20., and the
SETTIM routine to make them occur at 15 second intervals.
-------
6-Dec-89 10:20:49-MST,1071;000000000000
Return-Path: <jzj@msr.EPM.ORNL.GOV>
Received: from msr.EPM.ORNL.GOV (MILNETH.ORNL.GOV) by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 6 Dec 89 10:20:32 MST
Received: by msr.EPM.ORNL.GOV (5.61/1.34)
id AA17424; Wed, 6 Dec 89 12:19:54 -0500
Date: Wed, 6 Dec 89 12:19:54 -0500
From: jzj@msr.EPM.ORNL.GOV (Jeff Jones)
Message-Id: <8912061719.AA17424@msr.EPM.ORNL.GOV>
To: tops-20@wsmr-simtel20.army.mil
Subject: Tape question
Currently on our DECSYSTEM-2060, we have 2 TU78 tape drives. One is the master
drive (i.e. has a controller) and the other is a slave. We now have the
opportunity to upgrade the slave to a master and have two master drives. Both
drives will be connected to the same RH20.
The drives aren't used that much, but are used at the same time when disk
backups are performed at night.
I would like to get some information and opinions from people if this change is
worth the trouble and if some performance gains could be expected.
Thank you,
Jeff Jones
Martin Marietta Energy Systems, Inc.
(615)576-2335
jzj@msr.epm.ornl.gov
6-Dec-89 19:35:22-MST,641;000000000000
Return-Path: <lear@NET.BIO.NET>
Received: from net.bio.net by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 6 Dec 89 19:35:16 MST
Received: by net.bio.net (5.61/1.15)
id AA00700; Wed, 6 Dec 89 17:41:46 -0800
Date: Wed, 6 Dec 1989 17:41:45 PST
From: Eliot Lear <lear@NET.BIO.NET>
To: tops20@wsmr-simtel20.army.mil
Cc: lear@NET.BIO.NET
Usmail: 700 East El Camino Real, Mtn View, California 94040
Phone: (415) 962-7323
Subject: For sale...
Message-Id: <CMM.0.88.628998105.lear@NET.BIO.NET>
DECSYSTEM 2065 for sale. 3 RP07s, 1 RP06, 1 TX78U, NI, 3 Mw of MF memory,
and a ton of DH11s (well over 100 ports).
Best offer.
Eliot
8-Dec-89 20:55:16-MST,610;000000000000
Return-Path: <egk@lll-crg.llnl.gov>
Received: from lll-crg.llnl.gov by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 8 Dec 89 20:55:03 MST
Received: by lll-crg.llnl.gov (5.61/1.14)
id AA03850; Fri, 8 Dec 89 19:54:31 -0800
Date: Fri, 8 Dec 89 19:54:31 -0800
From: egk@lll-crg.llnl.gov (Edjik)
Message-Id: <8912090354.AA03850@lll-crg.llnl.gov>
To: lear@NET.BIO.NET
Cc: tops20@wsmr-simtel20.army.mil, lear@NET.BIO.NET
In-Reply-To: Eliot Lear's message of Wed, 6 Dec 1989 17:41:45 PST <CMM.0.88.628998105.lear@NET.BIO.NET>
Subject: For sale...
Which 20 is this? I will offer One Hundred $ for it!
--E+
15-Dec-89 18:04:43-MST,628;000000000000
Return-Path: <LARSON@KL.SRI.COM>
Received: from KL.SRI.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 15 Dec 89 18:04:32 MST
Date: Fri, 15 Dec 89 17:04:19 PST
From: Alan Larson <LARSON@KL.SRI.COM>
Subject: another goodbye
To: tops-20@wsmr-simtel20.army.mil
Reply-To: larson@crvax.sri.com
Message-ID: <12550417854.10.LARSON@KL.SRI.COM>
Another TOPS-20 system is leaving us. KL.SRI.COM, formerly SRI-KL and
SRI-KL.ARPA, will be turned off in a few minutes. Hopefully in about a
month it will be sent to a new home where it will run again, but probably
not on the internet.
We shall miss it.
Alan
-------
19-Dec-89 18:50:38-MST,621;000000000000
Return-Path: <A.ALDERSON@Macbeth.Stanford.EDU>
Received: from Macbeth.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 19 Dec 89 18:50:35 MST
Date: Tue 19 Dec 89 17:43:55-PST
From: Rich Alderson <A.ALDERSON@Macbeth.Stanford.EDU>
Subject: Re: another goodbye
To: larson@crvax.sri.com
cc: tops-20@wsmr-simtel20.army.mil
In-Reply-To: <12550417854.10.LARSON@KL.SRI.COM>
Message-ID: <12551473637.77.A.ALDERSON@Macbeth.Stanford.EDU>
You couldn't wait another day, for sentimental (or ritualistic) reasons?
Ah, well, the end of an era. Where do we get our host tables and RFCs now?
Rich
-------
20-Dec-89 12:08:26-MST,911;000000000000
Return-Path: <A.ALDERSON@Macbeth.Stanford.EDU>
Received: from Macbeth.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 20 Dec 89 12:08:15 MST
Date: Wed 20 Dec 89 11:02:05-PST
From: Rich Alderson <A.ALDERSON@Macbeth.Stanford.EDU>
Subject: Re: another goodbye
To: ZZZ@NIC.DDN.MIL
cc: tops-20@wsmr-simtel20.army.mil
In-Reply-To: <12551648663.48.ZZZ@NIC.DDN.MIL>
Message-ID: <12551662631.81.A.ALDERSON@Macbeth.Stanford.EDU>
Where do we get our host tables and RFCs now?
You mean you weren't getting them from the NIC? (nic.ddn.mil, nee
sri-nic.arpa, is still alive and kicking!)
That's the problem with associative memory technologies: Not perfected yet.
The brain is a great example.
Of course we get RFCs and host tables from the NIC. I saw "SRI" and then the
intelligence portion of my software was swapped out for a word processing
program!
Rich
-------
20-Dec-89 15:21:51-MST,1116;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 20 Dec 89 15:21:06 MST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
(5.61/UW-NDC Revision: 2.6 ) id AA19772; Wed, 20 Dec 89 14:18:38 -0800
Date: Wed, 20 Dec 1989 14:12:51 PST
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: mrc@Tomobiki-Cho.CAC.Washington.EDU
Subject: Happy DEC-20 day
To: KS-Owners@Kicki.Stacken.KTH.SE, TOPS-20@WSMR-SIMTEL20.ARMY.MIL
Message-Id: <MailManager.630195171.7590.mrc@Tomobiki-Cho.CAC.Washington.EDU>
I celebrated DEC-20 day by taking delivery of my third DEC-20 (the fourth PDP-
10 I have owned). This machine, nicknamed KUJIRA (the Japanese word for
"whale"), will serve as a hot backup for PANDA. It will be pressed into
service in the next few days, as PANDA presently is down with a dead power
supply and who knows what else.
Anybody got some extra (working) RM03 disk drives?
It tenatively appears that I will not be able to use the RP06 disk drive that
came with the system, but we'll see.
-------