12-Jan-90 15:46:33-MST,16977;000000000000 Return-Path: <@Score.Stanford.EDU:SHAFIE@UCBEH.SAN.UC.EDU> Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 12 Jan 90 15:44:27 MST Received: from UCBEH.SAN.UC.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Jan 90 12:00:31-PST Date: Thu, 11 Jan 90 14:13 EST From: Amin Shafie - Univ of Cincinnati Comp Ctr Subject: SIGUCCS CALL for PARTICIPATION To: 386USERS@TWG.COM, 9370-L%HEARN.BITNET@MITVMA.MIT.EDU, AAI@ST-LOUIS-EMH2.ARMY.MIL, ADA-SW@WSMR-SIMTEL20.ARMY.MIL, ADVISE-L%CANADA01.BITNET@CUNYVM.CUNY.EDU, ADVSYS@EDDIE.MIT.EDU, AG-EXP-L%NDSUVM1.BITNET@CUNYVM.CUNY.EDU, AI-ED@SUMEX-AIM.STANFORD.EDU, AIDSNEWS%RUTVM1.BITNET@CUNYVM.CUNY.EDU, AIList@AI.AI.MIT.EDU, AIX-L%BUACCA.BITNET@MITVMA.MIT.EDU, ALLIN1-L@CCVM.SUNYSB.EDU, AMETHYST-USERS@WSMR-SIMTEL20.ARMY.MIL, AMIGA-RELAY@UDEL.EDU, ANDREW-DEMOS@ANDREW.CMU.EDU, ANTHRO-L%UBVM.BITNET@CUNYVM.CUNY.EDU, apollo@UMIX.CC.UMICH.EDU, ARMS-D@XX.LCS.MIT.EDU, ARPANET-BBOARDS@MC.LCS.MIT.EDU, ASM370%UCF1VM.BITNET@CUNYVM.CUNY.EDU, AVIATION@MC.LCS.MIT.EDU, AVIATION-THEORY@MC.LCS.MIT.EDU, bicycles@BBN.COM, BIG-LAN@SUVM.ACS.SYR.EDU, BIG-LAN@SUVM.BITNET, BIOTECH%UMDC.BITNET@CUNYVM.CUNY.EDU, BIOTECH@UMDC.UMD.EDU, BITNEWS%BITNIC.BITNET@CUNYVM.CUNY.EDU, BMDP-L%MCGILL1.BITNET@CORNELLC.CCS.CORNELL.EDU, bug-1100@SUMEX-AIM.STANFORD.EDU, CA@THINK.COM, CADinterest^.es@XEROX.COM, CAN-INET@MC.LCS.MIT.EDU, cisco@SPOT.COLORADO.EDU Message-id: X-Envelope-to: TOPS-20@SCORE.STANFORD.EDU, NA@SCORE.STANFORD.EDU, EDITOR-PEOPLE@SCORE.STANFORD.EDU X-VMS-To: @LISTS.DIS X-VMS-Cc: SHAFIE <-------------------------------------------------------------------- < < SIGUCCS User Services Conference XVIII < Call For Participation < < New Centerings in Computing Services < < September 30 through October 3, 1990 < < Westin Hotel < Cincinnati, Ohio < < <<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << < Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 13 Jan 90 14:18:21 MST Date: Sat 13 Jan 90 15:17:47-CST From: Clive Dawson Subject: ILMNRF BUGHLT's in TCPTCP To: tops20@wsmr-simtel20.army.mil cc: tyson@ai.sri.com, cohen@MCC.COM, loeffler@MCC.COM Message-ID: <12557978789.11.AI.CLIVE@MCC.COM> Problem: ILMNRF BUGHLTs at MERGE3: in module TCPTCP. About two weeks ago, we began having these crashes about once a day. Diagnosis: Examination of the crash dumps revealed that in each case the relevant network TCB was from a connection to a Symbolics Lisp Machine beta testing their new Genera 8 release. (I haven't checked the Lisp Machine software yet, so this is only circumstantial finger-pointing for the moment.) Further digging revealed that the MERGE routine which tries to merge user TCP options with the received TCP options was finding garbage in the options field. When an option length of 0 is ILDB'd at MERGE3+17, the subsequent ADJBP at MERGED screws up the byte pointer, and this results in an ILMNRF when we loop back up to MERGE3. Cure: At MERGE3+20, after ILDB OPT,RP ;Get length insert CAIGE OPT,2 ;If length is less than 2 MOVEI OPT,2 ;it's junk, so make it 2. Note that this patch is quite similar to one posted by Mark Lottor a couple of years ago, which tested for the same problem in the TCPXXO routine. There may be other places where similar bullet-proofing against junk option bytes needs to be done. Clive ------- 13-Feb-90 08:34:31-MST,969;000000000000 Return-Path: Received: from NIC.DDN.MIL by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 13 Feb 90 08:34:28 MST Date: Tue, 13 Feb 90 07:32:47 PST From: Michael J. Konopik Subject: default tape density To: tops20@wsmr-simtel20.army.mil Message-ID: <12566042448.20.ZZZ@NIC.DDN.MIL> I've been asked to look into making 6250 be our system default tape density. Everything I see in the manuals and all the source code I've found that has any mention about the system default density seems to imply that it's quite well-fixed at 1600. I see no commands in any program (exec, opr, dumper, etc) that offer an easy way to change this. Anybody out there know how to change this value? Anybody know of a compelling reason why it would be a good or bad idea to change this? With it looking so strongly fixed at 1600, I wouldn't be at all surprised if there were things that just assume a 1600 default... Thanks. -Mike ------- 13-Feb-90 15:58:53-MST,922;000000000000 Return-Path: Received: from BU.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 13 Feb 90 15:58:34 MST Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 13 Feb 90 17:58:10 EST Received: by bu-it.bu.edu (12/20/89); Tue, 13 Feb 90 17:58:09 EST Date: Tue, 13 Feb 90 17:58:09 EST From: tower@bu-it.bu.edu (Leonard H. Tower Jr.) Message-Id: <9002132258.AA02362@bu-it.bu.edu> To: tops-20@wsmr-simtel20.army.mil Subject: KL10 turned off at Tufts University The student paper at Tufts University in Medford, MA reported that the University's dual processor (KL10s) TOP-10 system was turned off last week. One of the CPUs has to be returned to DEC (the contract so requires (DEC really wants it? ;-)). The other CPU et al will probably be junked. Paul Morris, the manager of their computer center, was mentioned. If any of you want the machine, I suggest you contact him. enjoy -len 17-Feb-90 03:42:26-MST,1046;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 17 Feb 90 03:42:22 MST Date: Sat 17 Feb 90 04:38:23-CST From: Clive Dawson Subject: Re: default tape density To: ZZZ@NIC.DDN.MIL cc: tops20@wsmr-simtel20.army.mil In-Reply-To: <12566042448.20.ZZZ@NIC.DDN.MIL> Message-ID: <12567037431.30.AI.CLIVE@MCC.COM> Mike- The likely way to change your system default tape density is to change the value of MTDFDN in STG.MAC from 4 to 5. I haven't tried this, so I don't know if it will do the trick or whether there are any pitfalls. And yes, there is most definitely something which assumes 1600 BPI default and which can really screw you if you forget it: MTBOOT. ALWAYS MAKE SURE YOUR CRASH TAPES ARE WRITTEN AT 1600 BPI!! It's no fun at all to attempt to rebuild your PS after a disk crash/HDA replacement and find that the only tape copies of MONITR.EXE are written at 6250 BPI. (Hmmm, now where did I hide that distribution tape...) Clive ------- 20-Feb-90 16:13:15-MST,1373;000000000000 Return-Path: Received: from NIC.DDN.MIL by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Feb 90 16:13:09 MST Date: Tue, 20 Feb 90 15:08:24 PST From: Michael J. Konopik Subject: Re: default tape density To: AI.CLIVE@MCC.COM cc: tops20@wsmr-simtel20.army.mil In-Reply-To: <12567037431.30.AI.CLIVE@MCC.COM> Message-ID: <12567960398.57.ZZZ@NIC.DDN.MIL> > From: Clive Dawson > Subject: Re: default tape density > And yes, there is most definitely something which assumes 1600 BPI default > and which can really screw you if you forget it: MTBOOT. > ALWAYS MAKE SURE YOUR CRASH TAPES ARE WRITTEN AT 1600 BPI!! It's no > fun at all to attempt to rebuild your PS after a disk crash/HDA > replacement and find that the only tape copies of MONITR.EXE are > written at 6250 BPI. (Hmmm, now where did I hide that distribution > tape...) Funny you should mention this, Clive. It just so happens we had the HDA for PS drive 0 replaced last week, and we rebuilt PS using a 6250 crash tape without any insurmountable problems. Maybe we owe this stroke of luck to the fact that our TU78's came up preset to the right density? Thanks for all the responses I received for my density question. I'll let y'all know whether I'm able to get it to work. -Mike ------- 20-Feb-90 18:39:03-MST,720;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Feb 90 18:38:55 MST Date: Tue 20 Feb 90 19:11:49-CST From: Clive Dawson Subject: Re: default tape density To: ZZZ@NIC.DDN.MIL cc: tops20@wsmr-simtel20.army.mil In-Reply-To: <12567960398.57.ZZZ@NIC.DDN.MIL> Message-ID: <12567982865.30.AI.CLIVE@MCC.COM> Hmmmm....So maybe 6250 BPI crash tapes work after all. I guess this is how folklore gets started--somebody gets burned by something like his sometime in the past, and (at least some) people believe the story. After all, it's not often you hear: Ow! That candle flame burned my finger! Really? Let me try... Clive ------- 21-Feb-90 09:00:21-MST,1331;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 21 Feb 90 09:00:06 MST Received: from pixar.UUCP by ucbvax.Berkeley.EDU (5.61/1.41) id AA27676; Wed, 21 Feb 90 07:46:27 -0800 Date: Wed, 21 Feb 90 07:46:27 -0800 Message-Id: <9002211546.AA27676@ucbvax.Berkeley.EDU> Received: by pixar; 21 FEB 90 07:05:39 PST From: pixar!rta@ucbvax.Berkeley.EDU (Rick Ace) To: tops20@wsmr-simtel20.army.mil Subject: 6250 BPI crash tapes Mike: > Funny you should mention this, Clive. It just so happens we had the HDA > for PS drive 0 replaced last week, and we rebuilt PS using a 6250 crash > tape without any insurmountable problems. Maybe we owe this stroke of luck > to the fact that our TU78's came up preset to the right density? Clive: > Hmmmm....So maybe 6250 BPI crash tapes work after all. I'd suspect you have to consider the type of tape drive before deciding whether non-1600 BPI crash tapes will work. The TU78 has the smarts to identify the recording density automatically without having to be pre-told what it is; indeed, it probably ignores the programmed density when reading. The TU45, on the other hand, had to be told explicitly what density to read at. But then TU45s could never read 6250 BPI, either! Rick Ace 21-Feb-90 18:56:53-MST,562;000000000000 Return-Path: Received: from venera.isi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 21 Feb 90 18:56:37 MST Posted-Date: Wed, 21 Feb 1990 14:46:29 PST Received: by venera.isi.edu (5.61/5.61+local) id ; Wed, 21 Feb 90 14:46:30 -0800 Date: Wed, 21 Feb 1990 14:46:29 PST From: Benjamin Britt To: tops20@wsmr-simtel20.army.mil Subject: TU78's on a KS-10. Message-Id: Can I hook a TU78 (6250 bpi tape drive) onto a 2020 or is it incompatible? Thanks, Ben 22-Feb-90 09:47:32-MST,3122;000000000000 Return-Path: Received: from NSFnet-Relay.AC.UK by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 22 Feb 90 09:47:19 MST Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa24233; 22 Feb 90 16:19 GMT Date: 22-FEB-1990 16:24:48 From: CCDARG%vaxb.cc.dundee-tech.ac.uk@NSFnet-Relay.AC.UK To: tops20 <@NSFnet-Relay.AC.UK:tops20@wsmr-simtel20.army.mil> Subject: Tape drives and a belated obituary (Try again) From: Memo Service (mmdfII #32) 22-FEB-1990 14:44 To: CCDARG Subj: Failed mail Date: Thu, 22 Feb 90 14:42:05 WET From: Memo Service (mmdfII #32) Subject: Failed mail To: CCDARG@uk.ac.dundee-tech.cc.vaxb Your message was not delivered to the following addresses: (NAUTH) Bad authorization: Sender 'ccdarg@vaxb.cc.dundee-tech.ac.uk' not authorized. Mail authorisation@UK.AC.UCL.CS (with an empty message) for help. Your message begins as follows: Date: 22-FEB-1990 14:11:28 From: CCDARG@UK.AC.DCT.CC.VAXB To: tops20%mil.army.wsmr-simtel20@UK.AC.UCL.CS Subject: Dump tapes Back about 1980, we had the first TU78 (and for that matter RP07) in the U.K. together with a cobbled together operating system to support them. There were several problems that I can remember with Dump tapes. 1) The system would only read a dump tape from the first tape drive it found which in our case was a TU45. 2) Even if you could get round this problem it always tried to read at 1600BPI 3) If you tried to be clever by changing blocking factors to get more data on a tape then it wouldn't read that either. All these problems only occurred with the initial get of MONITR.EXE from the tape. As such it was the bootstrap code on the floppies causing the problem. At one stage we got into a terrible mess with incompatible microcode on floppy and a corrupted RP06 front end file system so we couldn't even go back to an older 1600BPI dump tape - I tried but the system just crashed as it didn't like the new microcode, nor for that matter the rather large amount of MOS memory which it didn't understand. In the end only some rather creative use of an F-S KLAD diagnostic pack saved me from spending a rather intense front end debugging session at the system console. At least one of these problems persisted right through all version 5 flavours of the monitor so we stuck to 1600 TU45 dump tapes after that. I never installed version 6 as the machine was nearing the end of its life and finally gave up about two years ago after running about 6 months permanent up time outside of a service contract. Only persistent air flow cpu trips caused by the air conditioning not being able to cope with the growing number of VAXen filling the machine room finally killed it. Sigh. I never posted an obituary at the time because of lack of outgoing ARPA mail access. I believe its now used for spares for the few remaining KL10s in the UK. KL10-B serial 2172 1976 - 1988 RIP $^ECEASE Alan Greig 26-Feb-90 12:22:11-MST,1191;000000000000 Return-Path: Received: from lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 26 Feb 90 12:21:46 MST From: John Wroclawski Sender: jtw@lcs.mit.edu To: britt@isi.edu CC: tops20@wsmr-simtel20.army.mil In-reply-to: Benjamin Britt's message of Wed, 21 Feb 1990 14:46:29 PST Subject: TU78's on a KS-10. Date: Mon, 26 Feb 90 14:06:59 EST Message-ID: <9002261407.aa11289@mintaka.lcs.mit.edu> Date: Wed, 21 Feb 1990 14:46:29 PST From: Benjamin Britt Can I hook a TU78 (6250 bpi tape drive) onto a 2020 or is it incompatible? DEC did not support putting a TU78 on a 2020. We have recently determined that the hardware is quite capable of working together, so it is plausible that someone with sources could make this work. We're running a different operating system, ourselves. (Further detail for KS types: so far we've only tried it with the unibus adapter in "fast mode", which is probably only useful if you can guarantee that the tape data record size is divisible by 4. Not a problem for us, might be for others. No idea if slow mode works or not.) 8-Mar-90 09:47:34-MST,577;000000000000 Return-Path: <@Score.Stanford.EDU:PHCHEHUN%TWNAS886.BITNET@Forsythe.Stanford.EDU> Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 8 Mar 90 09:47:19 MST Received: from Forsythe.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Mar 90 08:46:53-PST Received: by Forsythe.Stanford.EDU; Thu, 8 Mar 90 08:46:14 PST Date: Fri, 9 Mar 90 00:43 U From: Subject: SUB To: TOPS-20@SCORE.STANFORD.EDU X-Original-To: TOPS-20@SCORE.STANFORD.EDU, PHCHEHUNG SUB HED WEI HELP INDEX LIST 13-Mar-90 12:42:49-MST,1960;000000000000 Return-Path: Received: from NIC.DDN.MIL by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 13 Mar 90 12:42:37 MST Date: Tue, 13 Mar 90 11:40:40 PST From: Ken Harrenstien Subject: KCC: ANSI C for TOPS-10/20 To: tops20@WSMR-SIMTEL20.ARMY.MIL cc: klh@NIC.DDN.MIL Message-ID: <12573427607.27.KLH@NIC.DDN.MIL> I imagine that most of the people interested in this are already on the INFO-KCC mailing list, but just in case... The latest version of KCC (v.653) is now ready for distribution. This is a full implementation of ANSI standard C for TOPS-20 (and, modulo a few unsupportable functions, for TOPS-10 as well). Included are all sources and documentation for both the compiler and the C library; although not public domain, there are no license charges. Some points: - ANSI has accepted the final X3J11 draft as a standard, so the moving target is no longer moving. - KCC has been run through the Plum Hall validation suite. - The library includes simulations of the most useful UNIX system calls; porting programs between UNIX and TOPS-20 is not difficult. - Virtually all of the software developed by the NIC for our TOPS-20 system is written in C using KCC, with portability in mind. As far as I know, there is no other equivalent C compiler for PDP-10s. The major attraction of C, of course, is the portability issue; with KCC we can port existing C software into a PDP-10 environment, or develop PDP-10 programs that can later be migrated to a new hardware base. If you have more questions, or are interested in getting a copy, just send me a message or FTP the file KCCDIST:OBTAIN.DOC from NIC.DDN.MIL. --Ken [P.S. Although not included with the KCC distribution, we also have available a variant of Columbia's CCMD package that allows the same COMND-interface code to run on either TOPS-20 or UNIX without change. Very handy for user interface programs.] ------- 14-Mar-90 08:22:51-MST,694;000000000000 Return-Path: Received: from munnari.oz.au by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 14 Mar 90 08:21:19 MST Received: from sol.cc.deakin.oz (via charlie) by munnari.oz.au with SunIII (5.61+IDA+MU) id AA28409; Wed, 14 Mar 1990 17:01:37 +1100 (from ccw@sol.deakin.OZ.AU for tops20@wsmr-simtel20.army.mil) Received: from kokab.cc.deakin.OZ.AU by sol.deakin.OZ.AU with SMTP (5.61) id AA03424; Wed, 14 Mar 1990 14:11:35 +1100 Message-Id: <9003140311.AA03424@sol.deakin.OZ.AU> To: tops20@wsmr-simtel20.army.mil Subject: Wanted: Dumper that runs on Unix Date: Wed, 14 Mar 90 14:11:31 +1100 From: Craig Warren Subject says it all. I can FTP... 16-Mar-90 07:16:13-MST,2713;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 16 Mar 90 07:15:56 MST Date: Fri 16 Mar 90 06:59:34-CST From: Clive Dawson Subject: The ARPAnet (1969-1990) To: tops-20@wsmr-simtel20.army.mil cc: Friends: ; Message-ID: <12574141019.47.AI.CLIVE@MCC.COM> For "The Record" as they say, (given that this list is part of it): ------------------------------------------------------------------------- From: postel@venera.isi.edu (Jon Postel) Received: by venera.isi.edu (5.61/5.61+local) id ; Thu, 15 Mar 90 14:53:53 -0800 Received-Date: Thu, 15 Mar 90 14:53:51 -0800 Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 15 Mar 90 14:53:51 -0800 Date: Thu, 15 Mar 90 14:54:30 PST Posted-Date: Thu, 15 Mar 90 14:54:30 PST Message-Id: <9003152254.AA16981@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Thu, 15 Mar 90 14:54:30 PST To: ietf@venera.isi.edu Subject: The ARPAnet (1969-1990) From: Danny Cohen Subject: The ARPAnet (1969-1990) Cc: lk@CS.UCLA.EDU The ARPAnet (1969-1990) ----------------------- The ARPANET died at midnight on Wednesday, February 28, 1990, when the plug was pulled at her request since she could no longer sustain the life style to which she had become accustomed. A legend in her own time, she had been the most powerful network at the center of the Internet. In recent years she became too weak for that role. Her net-number, 10, which was retired at her death, is now on display in the Smithsonian. She was survived by a sister network, thousands of other networks, hundreds of thousands hosts, and an uncountable number of users. Her memory will live with us for ever. As of March 1st, 1990, no more brain activity can be detected on the ARPAnet, even though some small parts of her body are still artificially keft alive. [Danny+Lenny] ------------------------------------------------------------------------- I guess we may never know at what exact point The End will really come, or even how to define it in this case. At 6am CST, 16-Mar-90, I pinged 47 10.x.x.x addresses which still appear in the NIC host tables. Six of them still respond, including 10.0.0.51, the NIC. I'm guessing that the IMP's (oops, sorry, PSN's) are all dead by now, and that what I'm seeing is an artifact caused by residual info in the routing tables. As a well-spent day brings happy sleep, so life well used brings happy death. Leonardo Da Vinci, 1452-1519 Notebooks [c. 1500] Clive ------- 2-Apr-90 14:57:27-MDT,867;000000000000 Return-Path: Received: from GSB-How.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 2 Apr 90 14:57:14 MDT Date: Mon 2 Apr 90 13:55:31-PDT From: Eric M. Berg Subject: Program to copy TOPS-20 dump tapes To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-ID: <12578684113.9.A.ERIC@GSB-How.Stanford.EDU> I'm looking for a program which will allow us to copy TOPS-20 DUMPER tapes, including ARCHIVE/MIGRATION tapes. This could be a TOPS-20 program, or a Unix program. (I'd even settle for a VMS program, if it allowed you to copy the tape to disk, and then copy that back to tape.) Thanks in advance for any suggestions. Eric M. Berg previously employed by, now a consultant to: Computing Services Graduate School of Business Stanford University ------- 6-Apr-90 04:58:28-MDT,1088;000000000000 Return-Path: Received: from ntt-20.NTT.JP by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Apr 90 04:56:55 MDT Return-Path: Received: from mecl.ntt.jp (nuesun.NTT.JP) by ntt-20.NTT.JP with TCP; Fri, 6 Apr 90 18:42:26 I Received: by mecl.ntt.jp (3.2/NTT-INET03) with TCP; Fri, 6 Apr 90 18:41:05 JST Received: by nttlab.ntt.jp (3.2/6.2NTT.j) with TCP; Fri, 6 Apr 90 18:43:07 JST Received: from ICOT20.ICOT.JP by icot32.icot.jp (3.2/6.4J.6-icotv3) id AA28481; Fri, 6 Apr 90 15:43:31 JST Return-Path: Date: Fri 6 Apr 90 15:41:47 From: T.Chikayama Subject: The Last Mail from ICOT20 To: softlab@ntt-20.NTT.JP Message-Id: <12579566349.14.CHIKAYAMA@ICOT20.ICOT.JP> ReSent-Date: Fri, 6 Apr 90 19:00:32 I ReSent-From: Hiroshi "Gitchang" Okuno ReSent-To: tops-20@wsmr-simtel20.army.mil ReSent-Message-ID: <12579602528.13.OKUNO@NTT-20.NTT.JP> This is the last mail from ICOT20, one of the rarest of the computerkind. It will be shut down soon..... ------- 6-Apr-90 09:56:11-MDT,2842;000000000000 Return-Path: Received: from gidney.tops20.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Apr 90 09:55:48 MDT Date: 6 Apr 1990 1132-EDT From: "Gregory A. Scott" To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Subject: Recent changes in the TOPS-20 monitor Message-ID: <"MS11(6050)+GLXLIB6(0)" 12579673880.135.27.208839 at gidney.tops20.dec.com> For those of you still on DIGITAL software maintenance, I thought some changes in the TOPS-20 monitor may be of interest. The following changes are to the TCP/IP monitor only. * Implementation of the Karn and Jacobson algorithms for retransmission timeout calculation, slow start, and congestion avoidance, as specified by RFC1122. These changes increase network throughput, particularly for distant hosts. * Fixes to the LOGICAL-HOST-MASK keyword in SYSTEM:INTERNET.ADDRESS so that IP subnetting now works. LOGICAL-HOST-MASK now works in the same manner as the Ultrix "netmask". * Implementation of a new software in SYSTEM:INTERNET.ADDRESS called "IPNIA". The IPNIA device allows multiple IP addresses to be assigned to one physical NIA20 Ethernet Channel. * Support of the TOPS-20 Limited Domain Resolver, which privides access to Domain Name System (DNS) data residing on a host willing to be a DNS name server. A list of name server hosts is specified in the optional configuration file SYSTEM:INTERNET.NAMESERVERS. The SYSTEM:HOSTS.TXT file is still supported to read host name-to-address translation into the monitor's host tables. Host name-to-address translation transmitted to the TOPS-20 system (by a user requesting the information) is cached in the monitor's host tables for further use. This support extends the GTHST% JSYS to include most of the function supplied by MIT's CHIVES software through the GTDOM% JSYS. * Bug fixes to several TCP/IP modules supplied by the folks at NIC.DDN.MIL and WSMR-SIMTEL20.ARMY.MIL. For all TOPS-20 monitors: * Various bug fixes related to system security, terminal I/O, and TOPS-20 CFS clusters. * Last year's TOPS-20 security project which included the DEC supported ACJ, password expiration, password dictionary, login failures display, and secure files. * The autopatch system is retired, and in its place is a new system called TSU (TOPS-10/20 Software Update). The first set of software update tapes should have arrived most at sites already. The new system is a source and binary replacement system and the tapes look much like TOPS-20 distribution tapes. If anyone has any questions about these features, in particular the domain resolver and security changes which were fairly major changes, please send mail to gscott@gidney.tops20.dec.com. Greg Scott TOPS-20 Software Engineering -------- 6-Apr-90 17:56:20-MDT,517;000000000000 Return-Path: Received: from A.ISI.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Apr 90 17:56:14 MDT Date: Fri 6 Apr 90 19:55:27-EDT From: CHASE@A.ISI.EDU Subject: Ping for Tops-20 To: tops-20@wsmr-simtel20.army.mil Message-ID: <12579765443.30.CHASE@A.ISI.EDU> Anybody got a ping that works under 6.1? We used to have one that worked under 5.x, so if nobody has one I plan to go find it on the old source packs and hack on it. Just thought I'd check first. Thanks. <>Dale ------- 11-Apr-90 07:21:06-MDT,2032;000000000000 Return-Path: <076RONAN%vax.liverpool-poly.ac.uk@NSFnet-Relay.AC.UK> Received: from NSFnet-Relay.AC.UK by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 11 Apr 90 07:21:01 MDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa16661; 11 Apr 90 14:12 BST Date: Wed, 11 APR 90 14:18:29 GMT From: 076RONAN%vax.liverpool-poly.ac.uk@NSFnet-Relay.AC.UK To: TOPS-20 <@NSFnet-Relay.AC.UK,@nss.cs.ucl.ac.uk:TOPS-20@wsmr-simtel20.army.mil> Subject: Reading DUMPER tapes under VMS. Sender: "JANET 076RONAN@UK.AC.LIVPOL.VAX" <076RONAN%vax.liverpool-poly.ac.uk@NSFnet-Relay.AC.UK> Originally-to: IN%"TOPS-20@MIL.ARMY.WSMR-SIMTEL20" Mailer: Janet_Mailshr V3.4 (23-May-1989) Name: Ronan P. Flood, Systems Manager, Address: Liverpool Polytechnic Computer Services, Mountford Building, Byrom Street, Liverpool, L3 3AF, U.K. Telephone: 051 207 3581 x2101 People, we are rapidly approaching the time when we must say goodbye to our DEC-20; we are therefore looking at programs for reading DUMPER tapes under VMS. We have several from DEC Integration tapes, (remember those?), and the one with the most extensive facilities seems to be SI_DUMPER, from Stevens Institute of Technology, (or do you know of a better one?). However this does exhibit some problems, (can't deal with multi-reel savesets; gives Access Violation reading saveset header; etc.), so we are wondering if there is a more recent version available. The one we are looking at comes on VMS Integration tape 10, and the latest edit is [DUMPER_DUMPER_TAPE.BLI] ! 1.0.004 By: David L. Stevens On: 12-September-1986 Is there a later/better version available, and if so where can we get hold of it? (It may be that this version needs re-linked for VMS 5.x, but we do not have Bliss...) Regards, Ronan Flood, Liverpool Polytechnic 076RONAN@VAX.LIVPOL.AC.UK 13-Apr-90 06:07:17-MDT,925;000000000000 Return-Path: <@Score.Stanford.EDU:WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU> Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 13 Apr 90 06:07:11 MDT Received: from tut.cis.ohio-state.edu by SCORE.STANFORD.EDU with TCP; Fri 13 Apr 90 05:05:41-PDT Received: from osu-20.ircc.ohio-state.edu by tut.cis.ohio-state.edu (5.61-kk/5.900402) id AA13046; Fri, 13 Apr 90 08:06:53 -0400 Message-Id: <9004131206.AA13046@tut.cis.ohio-state.edu> Date: Fri 13 Apr 90 08:07:17-EDT From: Sandy Wambold Subject: Version of DUMPER for UNIX To: tops-20@OSU-20.IRCC.OHIO-STATE.EDU Is there a version of DUMPER that runs under UNIX? If there is, how can I get a copy? Sandy Wambold ----------------------------------------------------------------------- WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU Part of the student staff at The Ohio State University's DECSYSTEM-2060 ------- 14-Apr-90 01:53:29-MDT,1001;000000000000 Mail-From: WANCHO created at 14-Apr-90 01:53:22 Date: Sat, 14 Apr 1990 01:53 MDT Message-ID: From: "Frank J. Wancho" To: Sandy Wambold Cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL, TOPS20@WSMR-SIMTEL20.ARMY.MIL Subject: Version of DUMPER for UNIX In-reply-to: Msg of 13 Apr 1990 06:07-MDT from Sandy Wambold Is there a version of DUMPER that runs under UNIX? If there is, how can I get a copy? See the file PD2:READ20.TAR-Z, available by ANONYMOUS FTP from here. According to the man page, it is limited to retrieving ASCII text files and doesn't handle files that span tapes well (you need to do a two-step retrieve and cat the results). If there is a better version, or you whip this version into better shape, please let me know so that we can make it available here for others to use. --Frank 16-Apr-90 00:15:11-MDT,3627;000000000000 Return-Path: Received: from lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 16 Apr 90 00:15:00 MDT From: Rob Austein Sender: sra@lcs.mit.edu To: TOPS-20@wsmr-simtel20.army.mil Subject: The third regeneration's a bitch and then you die Date: Mon, 16 Apr 90 2:11:23 EDT Message-ID: <9004160211.aa04226@mintaka.lcs.mit.edu> [I don't know how much overlap there is between this list and INFO-ITS@AI.AI.MIT.EDU, so, for those who've missed it, an update. We are currently down to two running ITS machines (AI and MC), MD ("Mostly Down") having become a parts machine and ML having outlived our entire stock of spare RP06s (no, we don't want any more). Apart from the ITS machines we have one KS-10 ("Brave Little Toaster") running Chaosnet-only Twenex. It now appears that BLT will be the last running PDP-10 at MIT, if its disks manage to hold out. --sra] Date: Sat, 14 Apr 90 02:40:47 EDT From: Alan Bawden Subject: A sad day To: INFO-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu Reply-to: Alan@Reagan.ai.mit.edu I'm sorry to announce that we're going to shut down the ITS machines at MIT. As we plan for the final shutdown, the file AI:SYS;GOOD BYE will be constantly updated to contain the current plans. What follows is the current contents of that file, and it pretty much explain the situation: ------- Well, the time has finally arrived to shut down the ITS machines for the last time. The hardware is getting old, and the amount of maintenance required to keep things running is getting out of hand. We've been losing ground at an accelerating rate for the last year. The current plan is to turn AI and MC off for good sometime around the end of May. We plan to take a snapshot of AI and MC's filesystem sometime before the final shutdown and to keep this snapshot available on some other file server for a couple of months. People who have a large number of files to evacuate, but who lack efficient network access to AI and MC, are encouraged to simply wait until after this snapshot becomes available. AI's second RP06 (SECOND:) will be fixed soon to make it easier for people to evacuate themselves. Files on ITS backup tapes will be unavailable until someone writes the program to read them. Before the shutdown, modest file retrieval requests (mail to FILE-R@AI) will be considered. Extensive or complicated retrieval requests will have to wait until after the dust settles after the shutdown. Our judgment on these matters will be final. Sorry. All mailing lists will have to be moved elsewhere. If you maintain a mailing list on AI or MC, you can save us some trouble by moving your mailing list yourself as soon as possible. We'll try and do something responsible about those important lists that don't have obvious owners, but don't count on us to save your mailing list for you -- we might decide to just let it perish. Please try not to pester us about the personal inconvenience this causes you. We don't have any suggestions about where you should read your mail now, where you can keep your files, or where you can move your mailing list, and we wish we knew of another PDP-10 that you could use. (If you -must- pester someone, send mail to DOOMSDAY@AI.) We do appreciate your loyalty to ITS during its lifetime at MIT. Stop by sometime and we can talk about the good old days when dinosaurs ruled the machine room. As we continue to plan for doomsday, this file will be updated with the latest news. - Alan ------- 16-Apr-90 12:57:10-MDT,857;000000000000 Return-Path: Received: from science.utah.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 16 Apr 90 12:56:59 MDT Date: Sun 15 Apr 90 08:30:43-MDT From: "Nelson H. F. Beebe" Subject: How to get DUMPER for UNIX To: tops20@WSMR-SIMTEL20.ARMY.MIL cc: Beebe@science.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12582021932.29.BEEBE@SCIENCE.utah.edu> The folks at cs.utah.edu wrote a DUMPER for UNIX a couple of years ago when they switched from TOPS-20 to UNIX on their main machine. Here is what Grant Weiler reports: >> also, the programs for reading dec20 archive and filesave tapes >> resides on the new cs:/usr/spool/uucppublic/read20.{shar,tar} ------- 16-Apr-90 14:28:45-MDT,4172;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 16 Apr 90 14:28:31 MDT Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.61/UW-NDC Revision: 2.12 ) id AA28680; Mon, 16 Apr 90 13:28:09 -0700 Date: Mon, 16 Apr 1990 13:05:56 PDT From: Mark Crispin Sender: Mark Crispin Subject: good night, sweet prince To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Cc: Ron Aley , Terry Gray Message-Id: A sad day for PDP-10 lovers indeed. The earliest ITS software dates from the days of the PDP-6 (1964) when it replaced the PDP-1 (1959). The MIT-AI ITS machines -- a PDP-6, a PDP-10/KA10, and finally a PDP-10/KS10, were distinguished in having the first examples ever of hardware and software technology that we now consider routine. This is also approximately the same time in which SAIL, the primary example of the WAITS timesharing system, is scheduled for shutdown. At the height of its glory (1976-1979), SAIL was the only triple processor KL10, KA10, and PDP-6 ever, a hardware and software engineering feat that remains mind-boggling. A final example of WAITS lives on in the Computer Music group at Stanford, running on a Foonly PDP-10 clone. ** Begin Forwarded Message ** Date: Sat, 14 Apr 90 02:40:47 EDT From: Alan Bawden Subject: A sad day To: INFO-ITS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu Reply-To: Alan@Reagan.ai.mit.edu I'm sorry to announce that we're going to shut down the ITS machines at MIT. As we plan for the final shutdown, the file AI:SYS;GOOD BYE will be constantly updated to contain the current plans. What follows is the current contents of that file, and it pretty much explain the situation: ------- Well, the time has finally arrived to shut down the ITS machines for the last time. The hardware is getting old, and the amount of maintenance required to keep things running is getting out of hand. We've been losing ground at an accelerating rate for the last year. The current plan is to turn AI and MC off for good sometime around the end of May. We plan to take a snapshot of AI and MC's filesystem sometime before the final shutdown and to keep this snapshot available on some other file server for a couple of months. People who have a large number of files to evacuate, but who lack efficient network access to AI and MC, are encouraged to simply wait until after this snapshot becomes available. AI's second RP06 (SECOND:) will be fixed soon to make it easier for people to evacuate themselves. Files on ITS backup tapes will be unavailable until someone writes the program to read them. Before the shutdown, modest file retrieval requests (mail to FILE-R@AI) will be considered. Extensive or complicated retrieval requests will have to wait until after the dust settles after the shutdown. Our judgment on these matters will be final. Sorry. All mailing lists will have to be moved elsewhere. If you maintain a mailing list on AI or MC, you can save us some trouble by moving your mailing list yourself as soon as possible. We'll try and do something responsible about those important lists that don't have obvious owners, but don't count on us to save your mailing list for you -- we might decide to just let it perish. Please try not to pester us about the personal inconvenience this causes you. We don't have any suggestions about where you should read your mail now, where you can keep your files, or where you can move your mailing list, and we wish we knew of another PDP-10 that you could use. (If you -must- pester someone, send mail to DOOMSDAY@AI.) We do appreciate your loyalty to ITS during its lifetime at MIT. Stop by sometime and we can talk about the good old days when dinosaurs ruled the machine room. As we continue to plan for doomsday, this file will be updated with the latest news. - Alan ------- 22-Apr-90 21:08:25-MDT,1530;000000000000 Mail-From: WANCHO created at 22-Apr-90 21:08:21 Date: Sun, 22 Apr 1990 21:08 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL Subject: Statistics in Stanford FTP When statistics reporting is turned on in the Stanford FTP, the transfer rate is reported in kilobaud. This is an awkward value to associate with other systems that report in bytes per second. The following replacement of the tail end of the TIMOUT routine in FTP.MAC computes the bytes per second using the number of 8-bit bytes actually transferred, even in PAGED mode. --Frank -------------------- TYPE cain a,7 ; Is it 7-bit bytes? movei a,8 ; Make it 8 for arithmetic IMUL A,C ; Get total number of bytes imuli a,^D125 ; Convert for dividing by millisecs/8-bits move c,filprp+p.type ; Get type caie c,tt.pag ; Is it paged? cain c,tt.mei ; or MEIS paged? caia ; yes - skip and use full 36-bit byte pages jrst timou1 ; no imuli b,^d2304 ; (pages * 512 * 36)/8 imuli b,^d1000 ; adjust for millisec divide move a,b ; replace timou1: PUSH P,A ; and save it on the stack. CALL SHOTIM ; Say how much time was used. POP P,A ; Get time back IDIV A,STTCON ; Divide by console time to get bps. TYPE <%/for a total transfer rate of %1D bytes per second.%/> MOVE A,STTJFN ; Get the JFN back for caller. RET ==================== 23-Apr-90 23:59:34-MDT,805;000000000000 Return-Path: Received: from EDDIE.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 23 Apr 90 23:59:24 MDT Received: by EDDIE.MIT.EDU (5.61/25-eef) id AA28006; Tue, 24 Apr 90 00:59:05 EST Date: Tue, 24 Apr 90 00:59:05 EST From: Robert E. Seastrom Message-Id: <9004240559.AA28006@EDDIE.MIT.EDU> To: tops-20@wsmr-simtel20.army.mil Subject: Tops-10 I think that the Tops-20 mailing list is probably about as close as it comes to being an appropriate forum to ask for this: I'm looking for a Tops-10 manual set for Tops-10 version 7.02, 7.03, or 7.04. This is approximately 20 binders, occupying about 2 meters of shelf space. Does anyone out there at a former Tops-10 site still have a set of these that they would be willing to part with? 22-May-90 14:06:37-MDT,1169;000000000000 Return-Path: Received: from tymix.Tymnet.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 22 May 90 14:06:22 MDT Received: from tardis.Tymnet.COM by tymix.Tymnet.COM (5.61/1.34) id AA14597; Tue, 22 May 90 13:06:02 -0700 Received: by tardis.tymnet.com (4.0/SMI-4.0) id AA21071; Tue, 22 May 90 13:06:16 PDT Date: Tue, 22 May 90 13:06:16 PDT From: jms@tardis.Tymnet.COM (Joe Smith) Message-Id: <9005222006.AA21071@tardis.tymnet.com> To: tops20@wsmr-simtel20.army.mil Subject: Wanted: Unix program to read TOPS-10 BACKUP and TOPS-20 DUMPER tapes. Who's got the latest and greatest version of the program to read ASCII files off of PDP-10 tapes? I have some BACKUP and DUMPER tapes I need to have read in to a Unix system, a Sun running SunOS-4.0.3. Please send email as I am not currently receiving this list. Thanks. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me." 23-May-90 10:35:27-MDT,3171;000000000000 Return-Path: Received: from TEAM-1.MDC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 23 May 90 10:34:54 MDT Date: 23 May 90 09:33 PDT From: RDP.MDC@TEAM-1.MDC.COM Subject: Re: Wanted: Unix program to read TOPS-10 BACKUP and TOPS-20 DUMPER tapes. To: jms@tardis.Tymnet.COM (Joe Smith) Cc: tops20@wsmr-simtel20.army.mil Message-ID: In-reply-to: <9005222006.AA21071@tardis.tymnet.com> Message: Hi... Here is what I picked up off this mailing list about a month ago. Hope it helps. EXT-WAMBOLD-I054L 13-Apr-90 Version of DUMPER for UNIX From: {Sandy Wambold }DDN To: tops-20@OSU-20.IRCC.OHIO-STATE.EDU Identifier: EXT-WAMBOLD-I054L / <9004131206.AA13046@tut.cis.ohio-state.edu> Posted: 13-Apr-90 05:07-PDT Received: 16-Apr-90 08:36-PDT Message: Is there a version of DUMPER that runs under UNIX? If there is, how can I get a copy? Sandy Wambold ----------------------------------------------------------------------- WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU Part of the student staff at The Ohio State University's DECSYSTEM-2060 ------- EXT-WANCHO-I09SH 14-Apr-90 Version of DUMPER for UNIX From: {}DDN To: {Sandy Wambold }DDN Cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL, TOPS20@WSMR-SIMTEL20.ARMY.MIL Identifier: EXT-WANCHO-I09SH / In-reply-to: Msg of 13 Apr 1990 06:07-MDT from Sandy Wambold Posted: 14-Apr-90 00:53-PDT Received: 16-Apr-90 08:36-PDT Message: Is there a version of DUMPER that runs under UNIX? If there is, how can I get a copy? See the file PD2:READ20.TAR-Z, available by ANONYMOUS FTP from here. According to the man page, it is limited to retrieving ASCII text files and doesn't handle files that span tapes well (you need to do a two-step retrieve and cat the results). If there is a better version, or you whip this version into better shape, please let me know so that we can make it available here for others to use. --Frank EXT-Beebe-I11SN 15-Apr-90 How to get DUMPER for UNIX From: {}DDN To: tops20@WSMR-SIMTEL20.ARMY.MIL Cc: Beebe@science.utah.edu Identifier: EXT-Beebe-I11SN / <12582021932.29.BEEBE@SCIENCE.utah.edu> Posted: 15-Apr-90 07:30-PDT Received: 17-Apr-90 08:54-PDT X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message: The folks at cs.utah.edu wrote a DUMPER for UNIX a couple of years ago when they switched from TOPS-20 to UNIX on their main machine. Here is what Grant Weiler reports: >> also, the programs for reading dec20 archive and filesave tapes >> resides on the new cs:/usr/spool/uucppublic/read20.{shar,tar} ------- Raylene Pak McDonnell Douglas Corp. 1-Jun-90 06:34:01-MDT,1773;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 1 Jun 90 06:33:42 MDT Date: Fri 1 Jun 90 07:33:02-CDT From: Clive Dawson Subject: For the record... To: tops-20@wsmr-simtel20.army.mil Message-ID: <12594321279.50.AI.CLIVE@MCC.COM> From cent@silver.lcs.mit.edu Thu May 31 22:35:54 1990 Date: Thu, 31 May 90 22:34:07 EDT From: Pandora Berman To: info-its@mc.lcs.mit.edu Subject: requiescat in pacem we're not the only ones. ---------- From: Randall Davis Date: Thu, 31 May 90 20:48:01 edt To: tk@ai.mit.edu, cent@ai.mit.edu Subject: long-lived operating systems; RIP From davis Thu May 31 10:00:17 1990 To: LES@SAIL.Stanford.EDU Subject: SAILing into the sunset From: Les Earnest Requiem: the SAIL computer, which would have reached the grand old age of 25 next week, is slated to retire tonight and die in the near future. It has provided an intellectual home for a very productive generation of researchers and will be remembered fondly. When I asked around at the ITS wake, they said that the only older continuously running operating system anyone could think of was SAIL. What irony they should expire within a week of each other. What were its dates? Date: 31 May 90 1724 PDT From: Les Earnest Subject: re: SAILing into the sunset To: davis@ai.mit.edu Yes, that is a curious coincidence. Just after I sent that message I realized that I was off-by-1 in both the year and the day. SAIL was born on or about June 6, 1966 and is actually slated to retire tonight (30 days hath September, April, June . . .). -Les ------- 1-Jun-90 23:26:02-MDT,1154;000000000000 Return-Path: <@Score.Stanford.EDU:OPERATOR@GSB-OldHow.Stanford.EDU> Received: from Score.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 1 Jun 90 23:25:57 MDT Received: from GSB-OldHow.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 1 Jun 90 22:26:09-PDT Date: Fri 1 Jun 90 22:25:26-PDT From: Kay L. Tenne Subject: Another one bytes the dust.... To: tops-20@Score.Stanford.EDU Message-ID: <12594505579.11.OPERATOR@GSB-OldHow.Stanford.EDU> The Stanford Graduate School of Business is sad to report the demise of DEC-20 serial # 2332, formerly GSB-How.Stanford.EDU (36.67.0.210), in service at Stanford since the early 1980s. It was pre-deceased by DEC-20 serial # 2254 (formerly GSB-Why.Stanford.EDU), shut down 6 months ago. Survivors include Hamlet.Stanford.EDU (which now also answers to the name "GSB-How") and a collection of 32-bit machines running DEC's finest operating system. :-} The system's passing was witnessed by a few members of the operations staff. Most friends had left before the final moments, and were last seen heading in the direction of cisco System. ------- 2-Jun-90 21:32:02-MDT,716;000000000000 Return-Path: Received: from BU.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 2 Jun 90 21:31:28 MDT Received: from BU-IT.BU.EDU by BU.EDU (1.98) Sat, 2 Jun 90 23:30:28 EDT Received: by bu-it.bu.edu (12/20/89); Sat, 2 Jun 90 23:30:25 EDT Date: Sat, 2 Jun 90 23:30:25 EDT From: budd@bu-it.BU.EDU (Phil Budne) Message-Id: <9006030330.AA03785@bu-it.bu.edu> To: tops-20@wsmr-simtel20.army.mil Subject: Still in the news... Did anyone else notice that the Saturday Night with Connie Chung section with Clifford Stoll showed a TOPS-20 welcome banner? I wasn't wearing glasses so I missed the details... They also showed a Un*x /etc/hosts file and (GASP!) telnet in operation! -Phil 5-Jun-90 02:13:27-MDT,713;000000000000 Return-Path: <@fernwood.mpk.ca.us:mkl@nw.UUCP> Received: from fernwood.mpk.ca.us by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 5 Jun 90 02:13:16 MDT Received: from nw.UUCP by fernwood.mpk.ca.us at Mon, 4 Jun 90 23:21:45 -0700. (5.61.14/XIDA-1.2.8.34) id AA01623 for tops-20@wsmr-simtel20.army.mil via UUCP Message-Id: <266ad9ce@nw.com> Date: Mon, 04 Jun 90 17:59:42 PDT From: Mark Lottor To: tops-20@wsmr-simtel20.army.mil Subject: Sat Night with Connie Chung Yeah they showed the NIC banner and a log of someone running WHOIS. Later on they cut to a telnet session. Looked like this: >telnet sri-nic.arpa trying 10.0.0.51...timeout Looks like Cliff is way outa touch with reality. 21-Jun-90 13:08:20-MDT,476;000000000000 Mail-From: WANCHO created at 21-Jun-90 13:08:16 Date: Thu, 21 Jun 1990 13:08 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: NEWS sources Does anyone know where I can grab via FTP the current sources for NEWS, DLE's usenet newsgroup reader package? I specifically need T20LIB.R36 and TOPS20.R36. --Frank 22-Jun-90 19:14:40-MDT,921;000000000000 Return-Path: <@mailgw.liu.se:PELL@Elinor.LYSATOR.LiU.SE> Received: from mailgw.liu.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 22 Jun 90 19:14:08 MDT Received: from ELINOR.LYSATOR.LIU.SE by mailgw.liu.se with SMTP (5.61-bind 1.2+ida/IDA-1.2.8.2/LTH) id AA06415; Sat, 23 Jun 90 03:09:33 +0200 Date: Sat, 23 Jun 90 03:08:55 N From: P{r Emanuelsson Subject: Disk <-> disk dump To: tops20@wsmr-simtel20.army.mil Message-Id: <12599985751.9.PELL@ELINOR> I got some more packs the other day and started thinking about doing backups to disk instead of tape. Any suggestions for how to accomplish this? A simple COPY could be satisfactory, provided that the version numbers were preserved. Cheers, /Pell -- Lysator Computer Club pell@lysator.liu.se University of Linkoping, Sweden ...!uunet!lysator.liu.se!pell ------- 25-Jun-90 14:50:33-MDT,1307;000000000000 Return-Path: Received: from wolf.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 25 Jun 90 14:49:44 MDT Received: from dustbin.cisco.com by wolf.cisco.com with TCP; Mon, 25 Jun 90 13:45:36 -0700 To: "Frank J. Wancho" Cc: tops20@wsmr-simtel20.army.mil Subject: NEWS sources Date: Mon, 25 Jun 90 13:48:07 MST From: David Edwards Frank, The final version of NEWS, 6(1251), was never distributed to any archives to my knowledge. I have placed the source with the necessary lib source on dustbin.cisco.com for anonymous ftp. They are in unix tar format. This version was in use at SRI until KL's demise. I believe that the only thing this version needs is to have number of groups bumped (no surprise there :-() I would be most appreciative if you could make binaries of this version available for interested parties. For security reasons, you cannot perform a directory listing on dustbin. The files are called: b36lib.tar - Assorted B36 lib files incl T20LIB and TOPS20 t20news.tar - The current snapshot of sources to NEWS If you have any problems or I missed any files, please let me know. Let me know if and when these are installed in an archive so I can remove these tars. Thanks. -dle 26-Jun-90 02:10:59-MDT,745;000000000000 Return-Path: Received: from mathom.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 26 Jun 90 02:10:51 MDT Date: Tue 26 Jun 90 01:10:14-PDT From: Jim Lewinson Subject: Re: NEWS sources To: dle@cisco.com cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL, tops20@WSMR-SIMTEL20.ARMY.MIL In-Reply-To: Message from "David Edwards " of Tue 26 Jun 90 00:14:19-PDT Message-ID: <12600827037.10.JIML@mathom.cisco.com> I un-tar'ed the files and transfered them all to: [GSB-How.Stanford.EDU] 2779:*.*.* I think someone should find a better final resting place for them, however, this should make them somewhat more accessible for the time being. Jim ------- 2-Jul-90 21:45:17-MDT,2345;000000000000 Return-Path: Received: from BU.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 2 Jul 90 21:45:04 MDT Received: from BUIT2.BU.EDU by BU.EDU (1.98) Mon, 2 Jul 90 23:44:30 EDT Received: by buit2.bu.edu (12/20/89); Mon, 2 Jul 90 23:44:26 EDT Date: Mon, 2 Jul 90 23:44:26 EDT From: budd@bu-it.BU.EDU Message-Id: <9007030344.AA16850@buit2.bu.edu> To: tops-20@wsmr-simtel20.army.mil, info-its@mc.lcs.mit.edu Subject: Found in CACM v7 n5, p322. Phase-Of-Moon: FQ+2D,8H,0M,35S I found this cleaning out my office; CACM v7 n5 (may 1964) p322 shows a picture of a PDP-6 (and a chair), with the caption: Programmed Data Processor-6, introduced at the Annual Meeting of the Americs Research and Development Corporation in Boston Below the text reads: DIGITAL EQUIPMENT OFFERS NEW COMPUTER. The Programmed Data Processor-6 (PDP-6) has recently been introduced by Digital Equipment Corporation, Maynard Mass. To increase the data processing capacity of the PDP-6, Digital built into it all the system components needed for time-shared operation, that is, simultaneous use of the computer by several persons. Time-sharing is exected to enable the system to outperform in speed, volume and versatility other computers costing considerably more then the PDP-6. Significant savings in operating costs, in the time spent preparing programs, and the system turn-around time are also expected. The new system is larger and faster than Digital's other general-purpose computers, the PDP-1, PDP-4 and PDP-5. It uses a longer word length (36 bits) and adds in 2.7 to 4.3usec. Its programming system incluses the MONITOR, FORTRAN II, MACRO-6 Assembler, debugging, utility and library. The basic arithmetic processor for the PDP-6 system, the Type 166, uses the first 16 words of memory as accumulators, index registers or temporary storage. It performs 363 instructions, including fixed- and floating-point arithmetic, Boolean operations, program flag testing and modification, half-word moves, byte handling, block transmission and input-output instructions, all instructions use the same format. To increase the usefulness if the PDP-6, Digital offers a wide variety of auxiliary devices including cathode rat tube displays and magnetic tape, and mass memory devices. 3-Jul-90 13:06:19-MDT,812;000000000000 Return-Path: Received: from mimsy.UMD.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 3 Jul 90 13:06:00 MDT Received: from tumtum.cs.umd.edu by mimsy.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA22272; Tue, 3 Jul 90 13:50:11 -0400 Received: by tumtum.cs.umd.edu (4.0/3.14) id AA11293; Tue, 3 Jul 90 13:44:38 EDT Date: Tue, 3 Jul 90 13:44:38 EDT From: digex@tumtum.cs.umd.edu (Doug Humphrey) Return-Path: Message-Id: <9007031744.AA11293@tumtum.cs.umd.edu> To: budd@bu-it.BU.EDU Cc: tops-20@wsmr-simtel20.army.mil Subject: Found in CACM v7 n5, p322. Well, if you ever decide to get rid of that publication, let me know. I have a 2020 in my basement (actually 3 of them) and am always looking for interesting lore on them or their kin... Doug 5-Jul-90 18:48:41-MDT,3205;000000000000 Return-Path: Received: from DOC.DSS.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 5 Jul 90 18:47:31 MDT Date: 5 Jul 1990 20:46:26 EST From: Joe.Dempster@DOC.DSS.COM To: tops20@wsmr-simtel20.army.mil Subject: PDP-10 Open Hardware and Software Hacking Foundation. X-VMS-Original-To: INET%"tops20@wsmr-simtel20.army.mil" Fornax Computer Corporation is pleased to announce that 10 KS10 processors were recently saved from the scrapper in Ann Arbor (1 was still in its original shipping container...), along with an almost equal number of spare CPU kits. Thanks go out to Bill Oakes at ADP. Also saved were 5 Kennedy/ADP ONSITE tape drives, which work much better than the TU45, and also run on 110 volts. There will be more of this gear becoming available soon. Although the KS currently suffers from several "shortcomings": 1. No Ethernet 2. Small disks 3. The TU45 really isn't a tape drive 4. No extended addressing 5. No TCP-IP networking 6. Slow speed 7. Poor I/O, among others. It also has many strengths: 1. It is a real PDP-10 2. Uses very little electricity 3. It's small 4. Simple to repair 5. Very reliable 6. Any part of the machine can be hacked. We therefore propose the formation of the "PDP-10 Open Hardware and Software Hacking Foundation" (both "open" and "foundation" seem to be in vogue these days...). Fornax will give away as many KS10's as ADP can give us to members of the Foundation. To become a member all you have to do is sign on to assist in completing one of the following, or propose/ coordinate a project of your own: 1. Hack the PANDA 5.5 monitor and the RM03 DCL to support a new SMD-0 disk drive (300MB +). 2. Extend the Kennedy/TOPS20 tape interface to full functionality (currently you cannot boot the system from tape). 3. MASSbus SCSI interface. 4. Eliminating DECnet and adding TCP-IP support to the PANDA 5.5 monitor. The ultimate conclusion of this project will probably be when a gate array PDP-10 is running as an attached processor in a RISC workstation. Until then, many old KS10's can live out their lives as Internet mail routers or living, network accessible, "dinosaurs" who are available to anyone wishing to probe the depths of what one PDP-10 hacker dubbed "the clippership of timesharing systems". If the climate out there hasn't turned too cool yet, and the sun hasn't been blocked out for too long from the great meteor impact of 1983, don't hesitate to step forward. The new KS10 will be given to the most ambitious or dedicated proposal team. It is suggested that if you want one of the other KS10's you arrange to travel to New Jersey to do the final check out and packing yourself, as the ADP systems are a bit "used". But I am sure we have enough spare parts to fix anything. As long as this project doesn't get too out of control (as PDP-10 projects sometimes do...) Fornax will be glad to act as coordinator for the Foundation. Joe Dempster Fornax AT&T 201.874.7122 dempster@doc.dss.com 6-Jul-90 03:19:43-MDT,968;000000000000 Return-Path: Received: from cs.utah.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Jul 90 03:19:38 MDT Received: by cs.utah.edu (5.64/utah-2.12-cs) id AA01574; Fri, 6 Jul 90 03:18:59 -0600 Date: Fri, 6 Jul 90 03:18:59 -0600 From: lepreau@cs.utah.edu (Jay Lepreau) Message-Id: <9007060918.AA01574@cs.utah.edu> To: tops20@wsmr-simtel20.army.mil Subject: Unix DUMPER programs - corrected info Cc: A.Eric@Hamlet.Stanford.EDU, WAMBOLD@OSU-20.IRCC.OHIO-STATE.EDU, WANCHO@WSMR-SIMTEL20.ARMY.MIL, jms@tardis.Tymnet.COM, weiler@cs.utah.edu You don't have to have a uucp connection to us to get the good one: get dist/read20.shar or dist/read20.tar from cs.utah.edu via anonymous ftp. It is much evolved from Jim Guyton's original read20 which is the one on simtel20 (PD2:READ20.TAR-Z). Frank, that version should be replaced with ours. It's upward compatible, with many added features and bugs fixed. 6-Jul-90 07:55:07-MDT,3256;000000000000 Return-Path: Received: from DOC.DSS.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Jul 90 07:54:04 MDT Date: 6 Jul 1990 09:53:38 EST From: Joe.Dempster@DOC.DSS.COM To: tops-20@wsmr-simtel20.army.mil, info-its@mc.lcs.mit.edu Subject: DPD-10 Open Hardware and Software Hacking Foundation X-VMS-Original-To: INET%"tops-20@wsmr-simtel20.army.mil, info-its@mc.lcs.mit.edu" Fornax Computer Corporation is pleased to announce that 10 KS10 processors were recently saved from the scrapper in Ann Arbor (1 was still in its original shipping container...), along with an almost equal number of spare CPU kits. Thanks go out to Bill Oakes at ADP. Also saved were 5 Kennedy/ADP ONSITE tape drives, which work much better than the TU45, and also run on 110 volts. There will be more of this gear becoming available soon. Although the KS currently suffers from several "shortcomings": 1. No Ethernet 2. Small disks 3. The TU45 really isn't a tape drive 4. No extended addressing 5. No TCP-IP networking 6. Slow speed 7. Poor I/O, among others. It also has many strengths: 1. It is a real PDP-10 2. Uses very little electricity 3. It's small 4. Simple to repair 5. Very reliable 6. Any part of the machine can be hacked. We therefore propose the formation of the "PDP-10 Open Hardware and Software Hacking Foundation" (both "open" and "foundation" seem to be in vogue these days...). Fornax will give away as many KS10's as ADP can give us to members of the Foundation. To become a member all you have to do is sign on to assist in completing one of the following, or propose/ coordinate a project of your own: 1. Hack the PANDA 5.5 monitor and the RM03 DCL to support a new SMD-0 disk drive (300MB +). 2. Extend the Kennedy/TOPS20 tape interface to full functionality (currently you cannot boot the system from tape). 3. MASSbus SCSI interface. 4. Eliminating DECnet and adding TCP-IP support to the PANDA 5.5 monitor. The ultimate conclusion of this project will probably be when a gate array PDP-10 is running as an attached processor in a RISC workstation. Until then, many old KS10's can live out their lives as Internet mail routers or living, network accessible, "dinosaurs" who are available to anyone wishing to probe the depths of what one PDP-10 hacker dubbed "the clippership of timesharing systems". If the climate out there hasn't turned too cool yet, and the sun hasn't been blocked out for too long from the great meteor impact of 1983, don't hesitate to step forward. The new KS10 will be given to the most ambitious or dedicated proposal team. It is suggested that if you want one of the other KS10's you arrange to travel to New Jersey to do the final check out and packing yourself, as the ADP systems are a bit "used". But I am sure we have enough spare parts to fix anything. As long as this project doesn't get too out of control (as PDP-10 projects sometimes do...) Fornax will be glad to act as coordinator for the Foundation. Joe Dempster Fornax AT&T 201.874.7122 dempster@doc.dss.com 6-Jul-90 08:00:22-MDT,3206;000000000000 Return-Path: Received: from DOC.DSS.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Jul 90 07:59:53 MDT Date: 6 Jul 1990 09:59:39 EST From: Joe.Dempster@DOC.DSS.COM To: tops-20@wsmr-simtel20.army.mil Subject: PDP-10 Open Hardware and Software Hacking Foundation X-VMS-Original-To: INET%"tops-20@wsmr-simtel20.army.mil" Fornax Computer Corporation is pleased to announce that 10 KS10 processors were recently saved from the scrapper in Ann Arbor (1 was still in its original shipping container...), along with an almost equal number of spare CPU kits. Thanks go out to Bill Oakes at ADP. Also saved were 5 Kennedy/ADP ONSITE tape drives, which work much better than the TU45, and also run on 110 volts. There will be more of this gear becoming available soon. Although the KS currently suffers from several "shortcomings": 1. No Ethernet 2. Small disks 3. The TU45 really isn't a tape drive 4. No extended addressing 5. No TCP-IP networking 6. Slow speed 7. Poor I/O, among others. It also has many strengths: 1. It is a real PDP-10 2. Uses very little electricity 3. It's small 4. Simple to repair 5. Very reliable 6. Any part of the machine can be hacked. We therefore propose the formation of the "PDP-10 Open Hardware and Software Hacking Foundation" (both "open" and "foundation" seem to be in vogue these days...). Fornax will give away as many KS10's as ADP can give us to members of the Foundation. To become a member all you have to do is sign on to assist in completing one of the following, or propose/ coordinate a project of your own: 1. Hack the PANDA 5.5 monitor and the RM03 DCL to support a new SMD-0 disk drive (300MB +). 2. Extend the Kennedy/TOPS20 tape interface to full functionality (currently you cannot boot the system from tape). 3. MASSbus SCSI interface. 4. Eliminating DECnet and adding TCP-IP support to the PANDA 5.5 monitor. The ultimate conclusion of this project will probably be when a gate array PDP-10 is running as an attached processor in a RISC workstation. Until then, many old KS10's can live out their lives as Internet mail routers or living, network accessible, "dinosaurs" who are available to anyone wishing to probe the depths of what one PDP-10 hacker dubbed "the clippership of timesharing systems". If the climate out there hasn't turned too cool yet, and the sun hasn't been blocked out for too long from the great meteor impact of 1983, don't hesitate to step forward. The new KS10 will be given to the most ambitious or dedicated proposal team. It is suggested that if you want one of the other KS10's you arrange to travel to New Jersey to do the final check out and packing yourself, as the ADP systems are a bit "used". But I am sure we have enough spare parts to fix anything. As long as this project doesn't get too out of control (as PDP-10 projects sometimes do...) Fornax will be glad to act as coordinator for the Foundation. Joe Dempster Fornax AT&T 201.874.7122 dempster@doc.dss.com 7-Jul-90 22:00:58-MDT,1434;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 7 Jul 90 22:00:18 MDT Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.61/UW-NDC Revision: 2.13 ) id AA26297; Sat, 7 Jul 90 20:59:31 -0700 Date: Sat, 7 Jul 1990 20:53:39 PDT From: Mark Crispin Subject: KS10, Kennedy tape drives To: Joe.Dempster@DOC.DSS.COM Cc: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-Id: I don't see what the big deal is in implementing a large disk if the RM03 DCL is used. Although it would be nice to modify it to return a different device type (so real RM03's can still be supported), it's just a matter of making a few entries in a few tables. It is somewhat nice to have such a device ready before attempting the project, so that you can run some exercising tests. As for the Kennedy tape drives, the source code for my KS10 driver for it is on SIMTEL20 as PD3:MTPSRV.MAC. There is also an MTPSRV.DOC file. It implements an MTP: device suitable for use with DUMPER. I elected not to use PHYSIO because (1) I was in a hurry and (2) I would have had to implement a new driver at the channel level. MTP: works perfectly well for making tape backups, which is all you should use a magtape drive for. ------- 17-Jul-90 09:21:57-MDT,836;000000000000 Return-Path: Received: from DOC.DSS.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 17 Jul 90 09:21:33 MDT Date: 17 Jul 1990 10:51:30 EST From: Joe.Dempster@DOC.DSS.COM To: tops-20@wsmr-simtel20.army.mil Subject: PDP-10 hacker in the news again... X-VMS-Original-To: INET%"tops-20@wsmr-simtel20.army.mil" The Tuesday, July 17, 1990 issue of The New York Times, page A18 reports the awarding of 36 grants to "distinguished and gifted" by the MacArthur Foundation of Chicago. The grants range in size from $150,000. to $375,000. and are distributed over 5 years. Text from the 3rd column reports: Richard Stallman, 37 (this is as it was reported, ed.), a computer programmer. He is the founder of the Free Software Foundation, which advocates making software available to everyone. 27-Aug-90 08:48:10-MDT,1190;000000000000 Return-Path: <@isy.liu.se:pell@isy.liu.se> Received: from isy.liu.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 27 Aug 90 08:47:52 MDT Received: by isy.liu.se (5.61-bind 1.2+ida/IDA-1.2.8.2/LTH/LiTH) id AA29526; Sun, 26 Aug 90 19:05:57 +0200 Date: Sun, 26 Aug 90 19:05:57 +0200 From: pell@isy.liu.se Message-Id: <9008261705.AA29526@isy.liu.se> To: tops20@wsmr-simtel20.army.mil Subject: Boot problems Hi all! We have a KS10 which was damaged during a sudden thuderstorm last week. It fails to boot with a ?BT004xxx error, which means that the microcode didn't start properly. A BC (Boot path Check) gives ?BC04xxxx as error message, which means that something is wrong with the MOS memory. The xxxx is usually slightly larger than 1000 (BC starts the checking on address 1000) but varies. Manual deposit and examine in the MOS memory works fine with no problems, regardless of parity detection, cache on/off, etc. ZM (Zero Memory) also works fine. Strange problem. Any clues or hints? Cheers, /Pell -- Dept. of Electrical Engineering pell@isy.liu.se University of Linkoping, Sweden ...!uunet!isy.liu.se!pell 5-Sep-90 10:55:57-MDT,1488;000000000000 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 5 Sep 90 10:55:31 MDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id aa04485; Wed, 5 Sep 90 16:48:32 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa03348; 5 Sep 90 17:07 BST Date: Wed, 5 SEP 90 17:45:50 BST From: CSDRFLOOD@vax.liverpool-poly.ac.uk To: tops20 <@nsfnet-relay.ac.uk:tops20@wsmr-simtel20.army.mil> Subject: Obituary Sender: "JANET CSDRFLOOD@UK.AC.LIVPOL.VAX" Originally-to: IN%"tops20@mil.army.wsmr-simtel20" Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Name: Ronan P. Flood, Systems Manager, Address: Liverpool Polytechnic Computer Services, Mountford Building, Byrom Street, Liverpool, L3 3AF, U.K. Telephone: 051 207 3581 x2101 Liverpool Polytechnic announce the final shutdown of our DECSYSTEM-20 2065 system, KL2742, after 7 years of sterling service. It has been re-acquired by Digital for their own purposes, (probably as a spare-parts bank). A champagne wake was held in its honour. %%%%%%%%%%% OPCOM 5-SEP-1990 17:01:23.88 %%%%%%%%%%% Message from user DECNET on VAX DECnet event 4.18, adjacency down From node 1.5 (VAX), 5-SEP-1990 17:01:23.70 Circuit UNA-0, Adjacent node listener receive timeout Adjacent node = 1.2 (DEC20) 19-Sep-90 22:53:55-MDT,527;000000000000 Mail-From: WANCHO created at 19-Sep-90 22:53:39 Date: Wed, 19 Sep 1990 22:53 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: Sources for WORDS I rediscovered a very old ('80) program here called WORDS. Seems we don't have the sources for it and its WORDS.BIN file. If you have a copy online, please let me know where I can get it via FTP. Thanks, Frank 1-Oct-90 19:31:28-MDT,1315;000000000000 Return-Path: Received: from science.utah.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 1 Oct 90 19:31:11 MDT Date: Mon 1 Oct 90 19:29:34-MDT From: Pieter Subject: Home for a couple of good old 20s To: tops20@wsmr-simtel20.army.mil cc: Bowman@science.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics" X-US-Mail: "224 South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: 801-581-5252 Message-ID: <12626444208.11.OP.BOWMAN@SCIENCE.utah.edu> I've stopped reading my mail on the 20, but thought I should send this message out from it. In a short two months we have to move two DECSYSTEM-20/60s out the door, one is running and the other has been spares for a couple of years (though DEC should replace any missing pieces). They are (and were) science.utah.edu and utah-20.utah.edu (or utah-20.arpa). The rules around here on retiring equipment are mostly unknown to me, however, I suspect anybody with a semi could come along and take them for a ride (no money down, no money owed). If you need more information send me email. If we don't hear anything soon, two good friends will probably end up being recycled. Pieter bowman@science.utah.edu ------- 3-Oct-90 12:24:22-MDT,1028;000000000000 Return-Path: Received: from mimsy.UMD.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 3 Oct 90 12:24:05 MDT Received: from tumtum.cs.umd.edu by mimsy.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA13817; Wed, 3 Oct 90 14:22:54 -0400 Received: by tumtum.cs.umd.edu (4.0/3.14) id AA21578; Wed, 3 Oct 90 14:15:38 EDT Date: Wed, 3 Oct 90 14:15:38 EDT From: digex@tumtum.cs.umd.edu (Doug Humphrey) Return-Path: Message-Id: <9010031815.AA21578@tumtum.cs.umd.edu> To: OP.BOWMAN@science.utah.edu Cc: tops20@wsmr-simtel20.army.mil, Bowman@science.utah.edu In-Reply-To: Pieter's message of Mon 1 Oct 90 19:29:34-MDT <12626444208.11.OP.BOWMAN@SCIENCE.utah.edu> Subject: Home for a couple of good old 20s no question about it, I have a home for both of your machines. Please send me the configs, but in any case, I know someone that will show up and cart them off to a good home where they (or at least the one that runs) will actually be used for real computing! Doug 13-Oct-90 21:45:49-MDT,7931;000000000000 Mail-From: WANCHO created at 13-Oct-90 21:45:19 Date: Sat, 13 Oct 1990 21:45 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: Fixing up FTPSRT's LIST output Those of you running VAF's FTPSRT may wish to make the following changes to your code. These changes produce fancy one-liners in response to the LIST command (usually sent from Unix hosts when the user types the "dir" command). These changes do not interfere with the output produced by the STAT command with args. The output is similar to the Unix-style "ls" output, but without the protection, owner, and group info: PS: 1683(07) 7-Sep-89 19:18:11 00-README.TXT.1 1298(07) 30-Jun-90 20:18:15 ACCOUNTS.INFO.5 10823(07) 24-Oct-87 17:05:57 BINTNXVMS.C.1 804(07) 12-Jan-88 23:30:31 BINTNXVMS.README.2 4347(07) 23-Dec-89 21:11:25 BOOTSTRAP.HELP.5 2075(07) 20-Jul-88 16:32:19 IBMCMS-FTP.HELP.1 14479(07) 12-Sep-90 07:29:04 SIMTEL-ARCHIVES.INFO.40 64554(07) 26-May-89 05:21:21 SIMTEL20-ADA.INFO.5 2083(07) 28-Oct-89 14:04:12 SIMTEL20-CPM.DIRLIST.8 13914(07) 30-Jul-90 10:56:58 SIMTEL20-MACINTOSH.INFO.6 575(07) 28-Oct-89 13:51:12 SIMTEL20-MISC.DIRLIST.10 2365(07) 4-Oct-90 21:57:46 SIMTEL20-MSDOS.DIRLIST.48 9331(07) 27-Mar-89 11:52:58 SIMTEL20-UNIX-C.INFO.3 24599(07) 19-Apr-88 15:17:00 SIMTEL20-VHDL.INFO.1 777(07) 8-Dec-88 13:11:54 VAXVMS-FTP.HELP.2 --Frank -------------------- REDIT 1(104) COMPARE by user WANCHO, 13-Oct-90 21:32:51 File 1: PD3:FTPSRT.MAC.74 File 2: PD3:FTPSRT.MAC.102 ***** CHANGE #1; PAGE 1, LINE 1; PAGE 1, LINE 1 --------------------------------- ;PD3:FTPSRT.MAC.102, 13-Oct-90 16:58:41, Edit by WANCHO ; Move guts of one-liner DOLI03 to new DOLI99 and also call it from DOLINS ;PD3:FTPSRT.MAC.101, 13-Oct-90 12:49:39, Edit by WANCHO ; Another change in DOLI03 ;PD3:FTPSRT.MAC.100, 13-Oct-90 11:41:53, Edit by WANCHO ; Rewrote DOLI03, fixed up LIST output ;PD3:FTPSRT.MAC.77, 12-Oct-90 21:01:21, Edit by WANCHO ; Move stuff for LIST ;PD3:FTPSRT.MAC.75, 12-Oct-90 12:25:34, Edit by WANCHO ; Adjusted LIST flags at DOLI03 ;FTPSER:FTPSRT.MAC.75, 12-Oct-90 11:52:22, Edit by WANCHO ; Fixed LIST (wildcard) to send extra info at DOLI03 ***** CHANGE #2; PAGE 2, LINE 26; PAGE 2, LINE 26 VWHO==7 ; Last edited by VAF VMAJOR==5 ; Major Version # VMINOR==^D26 ; Make "Z" to be higher than "T" in standard ;version... VEDIT==74 ; Edit Number --------------------------------- VWHO==7 ; Last edited by VAF VMAJOR==5 ; Major Version # VMINOR==^D26 ; Make "Z" to be higher than "T" in standard ;version... VEDIT==102 ; Edit Number ***** CHANGE #3; PAGE 95, LINE 3; PAGE 95, LINE 3 JRST DOLIL1 ; Back for first file name SUBTTL Subroutines - DOLIST - Multiple files, append filespec DOLI03: MOVX C,<..NAMA+..TYPA+..GENA+JS%TMP+JS%PAF> TXZE F,F.T2 ; Just a new version? MOVX C,<..GENA> ; Yes. Just print that. TXNE F,F.NLST ; But if NLST, send different format. MOVX C,<..DEVD+..DIRD+..NAMA+..TYPA+..GENA+JS%TMP+JS%PAF> TXNE F,F.STAT ;CS129 Doing STAT? JFNS% ;CS129 Just do normally... TXNN F,F.STAT ;CS129 Else... CALL XJFNS ;CS129 Do special JFNS MOVEM A,T2 ; Save string pointer --------------------------------- JRST DOLIL1 ; Back for first file name SUBTTL Subroutines - DOLIST - Multiple files, append filespec DOLI03: IFXN. F,F.STAT ; If STAT, do this... MOVX C,<..NAMA+..TYPA+..GENA+JS%TMP+JS%PAF> TXZE F,F.T2 ; Just a new version? MOVX C,<..GENA> ; Yes. Just print that. JFNS% ;CS129 Just do normally... ELSE. IFXN. F,F.NLST ; If NLST MOVX C,<..DEVD+..DIRD+..NAMA+..TYPA+..GENA+JS%TMP+JS%PAF> ELSE. ; Otherwise, LIST or RLST CALL DOLI99 ENDIF. CALL XJFNS ENDIF. MOVEM A,T2 ; Save string pointer ***** CHANGE #4; PAGE 95, LINE 37; PAGE 95, LINE 40 MOVE A,C ;CS129X Get back flags,,jfn ENDIF. ;CS129X TXNE F,F.NLST ; NLIST command? JRST DOLIN2 ; Yes. Always separate lines. TXNN A,GN%DIR+GN%NAM+GN%EXT ; Just version change? JRST DOLI02 ; Yes. TXNE A,GN%DIR ; New directory? TXO F,F.PDIR ; Yes. Want to mention it. --------------------------------- MOVE A,C ;CS129X Get back flags,,jfn ENDIF. ;CS129X TXNE F,F.NLST ; NLIST command? JRST DOLIN2 ; Yes. Always separate lines. TXNN F,F.STAT ; If not STAT, JRST DOLI04 ; must be LIST or RLST - skip TXNN A,GN%DIR+GN%NAM+GN%EXT ; Just version change? JRST DOLI02 ; Yes. DOLI04: TXNE A,GN%DIR ; New directory? TXO F,F.PDIR ; Yes. Want to mention it. ***** CHANGE #5; PAGE 95, LINE 59; PAGE 95, LINE 64 MOVE A,LSTJFN ; Output this file HRROI B,STRTMP $SOUT JRST DOLIL0 ; Loop to next line & file. ; Only version changed, pointer is on top of stack --------------------------------- MOVE A,LSTJFN ; Output this file HRROI B,STRTMP $SOUT JRST DOLIL0 ; Loop to next line & file. ; Fancy one-liner... DOLI99: MOVEM A,T2 ; Save pointer HRRZ A,LCLJFN ; Get the JFN MOVE B,[4,,.FBBYV] ; Get all the info MOVEI C,PAGCNT ; to here GTFDB% ERJMP .+1 ; Ignore errors MOVE D,PAGCNT ; Extract page count HRRZ C,D MOVEM C,PAGCNT LDB C,[POINTR D,FB%BSZ] ; Extract byte size MOVEM C,BYTSIZ MOVE A,T2 ; Restore output pointer MOVE B,BYTCNT MOVX C,NO%LFL!FLD(8,NO%COL)!FLD(5+5,NO%RDX) NOUT% ; right-just, blank-fill, 8-col, decimal ERJMP .+1 MOVEI B,"(" ; separater IDPB B,A MOVE B,BYTSIZ ; byte size MOVX C,NO%ZRO!NO%LFL!FLD(2,NO%COL)!FLD(5+5,NO%RDX) NOUT% ; right-just, zero-fill, 2-col, decimal ERJMP .+1 HRROI B,[ASCIZ /) /] SETZ C, SOUT% HRRZ B,LCLJFN ; The file name to be listed MOVX C,JS%LWR ; last write JFNS% MOVEI B," " IDPB B,A HRRZ B,LCLJFN ; The file name to be listed MOVX C,<..NAMA+..TYPA+..GENA+JS%PSD+JS%PAF> RET ; Only version changed, pointer is on top of stack ***** CHANGE #6; PAGE 96, LINE 136; PAGE 96, LINE 136 HRROI B,[ASCIZS (150,213,< >)] SETZ C, TXNE F,F.STAT ; Cue needed? SOUT ; Yes ;CS129 *** Start *** LSTFMT=<..DEVD+..DIRA+..NAMA+..TYPA+..GENA+..PROA+..ACTA+JS%TMP+JS%SIZ+JS%CDR+JS%LWR+JS%LRD+JS%PSD+JS%PAF> ; flags for LIST command IFE PANDASW,< --------------------------------- HRROI B,[ASCIZS (150,213,< >)] SETZ C, TXNE F,F.STAT ; Cue needed? SOUT ; Yes ;CS129 *** Start *** IFE PANDASW,< ***** CHANGE #7; PAGE 96, LINE 146; PAGE 96, LINE 145 IFN PANDASW,< NLSFMT=<..DEVD+..DIRD+..NAMA+..TYPA+..GENA+JS%PAF> ;For NLST >; IFN PANDASW HRRZ B,LCLJFN ;Get file jfn IFXE. F,F.STAT ;Not doing stat? MOVX C,LSTFMT ;Assume LIST TXNE F,F.NLST ; But if NLST, send different format. MOVX C,NLSFMT ;... CALL XJFNS ;Do special JFNS --------------------------------- IFN PANDASW,< NLSFMT=<..DEVD+..DIRD+..NAMA+..TYPA+..GENA+JS%PAF> ;For NLST >; IFN PANDASW HRRZ B,LCLJFN ;Get file jfn IFXE. F,F.STAT ;Not doing stat? MOVX C,NLSFMT ;Assume NLST TXNN F,F.NLST ; But if LIST/RLST, send different format. CALL DOLI99 CALL XJFNS ;Do special JFNS ***** CHANGE #8; PAGE 142, LINE 54; PAGE 142, LINE 54 FDBBKE==.-1 ; End for BLT to clear PAGCNT: BLOCK 1 ;[SIZE] Page Count from GTFDB% BYTCNT: BLOCK 1 ;[SIZE] Byte Count BYTSIZ: BLOCK 1 ;[SIZE] Bytesize --------------------------------- FDBBKE==.-1 ; End for BLT to clear PAGCNT: BLOCK 1 ;[SIZE] Page Count from GTFDB% BYTCNT: BLOCK 1 ;[SIZE] Byte Count BYTSIZ: BLOCK 1 ;[SIZE] Bytesize FILCRV: BLOCK 1 ; Creation date FILWRT: BLOCK 1 ; Write date ==================== 16-Nov-90 09:49:20-MST,846;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 16 Nov 90 09:48:52 MST Received: by sandpiper.wesleyan.edu (5.57/Ultrix3.0-C) id AA00254; Fri, 16 Nov 90 11:48:06 -0500 Date: Fri, 16 Nov 90 11:48:06 -0500 Message-Id: <9011161648.AA00254@sandpiper.wesleyan.edu> From: Douglas Bigelow To: tops20@wsmr-simtel20.army.mil Subject: Trivia question Does anyone have a rough idea, offhand, of how many DEC-20s were manufactured? It would be a useful piece of information for an internal report we're writing which discusses Wesleyan's DEC-20 migration plans. (Dec '93 shutdown date tentative.) Of that number, how many are currently operative? (I've heard an estimate of 200.) Thanks! Doug Bigelow Wesleyan Univ. 17-Nov-90 17:43:54-MST,9244;000000000000 Return-Path: Received: from [128.110.192.2] by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 17 Nov 90 17:42:39 MST Date: Sat 17 Nov 90 17:39:04-MST From: "Nelson H. F. Beebe" Subject: Farewell to science.utah.edu -- perhaps a eulogy To: tops20@WSMR-SIMTEL20.ARMY.MIL cc: Beebe@[128.110.192.2], rodgers@[128.110.192.2], debar@[128.110.192.2] X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12638755784.17.BEEBE@SCIENCE.utah.edu> At 23:59:59 on October 31, 1990, our venerable DEC-20/60, science.utah.edu officially retired from service. It will continue to run with only staff access during the month of November, at the end of which, it will be powered off and deinstalled. The machine has given 12.5 years of wonderful service, with a maximum of 1000 user accounts at one time, though in the last 3 years, this number was usually under 600. The last classes taught using it were held during the summer quarter of 1990. Effective with the fall quarter, all Department of Mathematics classes moved to Sun workstations, with a few on the VAX 8600 (which will retire in the spring of 1991). Except for the last 3 years, CPU utilization has been at 90% or more, 24 hours a day. Statistics collected a couple of years ago showed that it bettered the San Diego Supercomputer Center's Cray X-MP/48 in user availability. A DEC-20/40 was originally purchased in March 1978 to provide half of its cycles for research (mostly, quantum chemistry) and half for teaching; cs.utah.edu got a second one at the same time (theirs retired four or five years ago). Ours was upgraded to a 20/60, perhaps about 1982 (my memory fails me). It served the entire College of Science at this University until the fall of 1986, when a major funding initiative provided expansions that gave Chemistry and Mathematics their own machines (an FPS-164 and a VAX 8600, respectively); Physics and Biology independently acquired their own smaller VAX facilities. At that time, the College of Science Computer, as the facility was known, ceased to report directly to the Dean of the College of Science, and became the Center for Scientific Computing under the Department of Mathematics. At that time, my faculty appointment moved from Chemistry to Mathematics. The College of Science now has hundreds of Macintoshes and IBM PCs, at least 50 Sun workstations (3, 4, 386i), several VAXes, a Multiflow (retired 2 weeks ago), a Stardent 1520, a few DECstations and VAXstations, and just starting to arrive how, IBM RS/6000s. This represents a substantial increase in computer power; more details are given below. Interestingly, during these last weeks, no power disturbances have hit Salt Lake City (a rare occurrence), and the DEC-20/60 ran about 2100 consecutive hours, far longer than it has ever run before. Until earlier this year, it had biweekly maintenance, so it was normally taken down at least every 336 hours. On Monday, 12-Nov-1990, a major power failure occurred that left parts of downtown Salt Lake City and some parts of the University of Utah campus without power for several hours; that of course brought our entire facility (DEC-20, VAXes, Stardent, and Suns) to a complete halt. With restoration of power, the DEC-20 booted normally, and I'm writing this last mail message on it. For those of you accustomed to reaching us at the address science.utah.edu, you will find that a UNIX file server, math.utah.edu, now answers to that name as well. Thus, e-mail will continue to arrive, but ftp accesses will put you on a UNIX machine. The major collections on science.utah.edu have been moved to subdirectories of the anonymous ftp login on math.utah.edu, and the entire collection is now also accessible via e-mail; send a message with the text "help" to tuglib@math.utah.edu to get started. Of course, if you have FTP access, you should use that instead, since you won't have to bother with unbundling e-mail parcels. Although UNIX has many wondrous features too, there are lots of things I miss that TOPS-20 has, including Undelete (number one on anybody's list, I guess). Real generation numbers in files. Use counts in the file system. Attributes in file names, particularly last writer. Real invisible files (instead of UNIX's hokey dot files) File archiving and migration. FTPs that preserve file time stamps. Command completion in the EXEC and almost all utilities (the UNIX csh's Ctl-D for filename completion is useful, but doesn't go far enough) An MM that keeps an editor fork alive, and lets you see the message in one window while you reply in the other (many of us are using Columbia's UNIX MM, which works very nicely, except for the editor problem). UNIX now has an enormous momentum, and has become the de facto operating system in science and engineering. I nevertheless hope that some of us with DEC-20 backgrounds someday will be able to carry some of these good ideas into a descendant of UNIX, which at least is conducive to user modifications of the shells and O/S. It has been interesting to see how relatively well the DEC-20/60 did at supporting large numbers of users. We usually had 20 to 30 people logged in, and near the end of each academic quarter, often had 50 to 70 (and things did get pretty slow then). However, a Sun SPARCstation SLC seems to get about as sluggish with 5 to 15 people logged in, and the Suns have about 3 times the memory of the DEC-20, and faster disks. For floating-point work, the DEC-20 is pretty slow; here are a few lines from my matrix multiply benchmarks (available in ~ftp/pub/benchmarks on math.utah.edu); these numbers are for 100 x 100 double precision multiplication with an inner loop that looks like "SUM = SUM + B(I,K)*C(K,J)": Normal inner loop (by rank) Test, Machine, Optimization Level Rank CPU Time MFlops matmr8.lst-f-ibm-3090-600vf-O2V 1.0000 0.023 sec 86.957 matmr8.lst-f-stardent-3040-O3 0.3538 0.065 sec 30.769 matmr8.lst-c-ibm-rs6000-530-opt 0.2035 0.113 sec 17.699 matmr8.lst-f-sgi-240gtx-pfa-O3 0.1484 0.155 sec 12.903 matmr8.lst-c-ibm-rs6000-320-opt 0.1369 0.168 sec 11.905 matmr8.lst-f-multiflow-14-300-O5 0.1139 0.202 sec 9.901 matmr8.lst-f-ibm-3090-600vf-O3 0.1111 0.207 sec 9.662 matmr8.lst-f-mips-rc3260-o2 0.0602 0.382 sec 5.236 matmr8.lst-f-sun-4-490-O4 0.0535 0.430 sec 4.651 matmr8.lst-f-decstation-5000-opt 0.0529 0.435 sec 4.598 matmr8.lst-f-apollo-dn10000-opt 0.0395 0.583 sec 3.431 matmr8.lst-f-decstation-3100-O3 0.0224 1.027 sec 1.947 matmr8.lst-c-sun-sparcstation-plus-O2 0.0217 1.062 sec 1.883 matmr8.lst-c-sun-sparcstation-opt 0.0192 1.196 sec 1.672 matmr8.lst-c-decstation-3100-opt 0.0189 1.217 sec 1.643 matmr8.lst-c-dg-aviion-ghcc-opt 0.0125 1.838 sec 1.088 matmr8.lst-c-NeXTstation-opt 0.0101 2.287 sec 0.875 matmr8.lst-f-dec-vax8600-opt 0.0075 3.080 sec 0.649 matmr8.lst-c-NeXT-opt 0.0030 7.796 sec 0.257 matmr8.lst-c-ibm-rt-opt 0.0024 9.400 sec 0.213 matmr8.lst-f-dec2060-opt 0.0011 20.391 sec 0.098 matmr8.lst-c-sun-3-50-opt 0.0007 34.812 sec 0.057 The 3090-600vf-O3 figure of 9.7 Mflops is in scalar mode; the -O2V result of 87 Mflops is in vector mode on one processor (automatic parallelization is not supported under AIX, which is the only O/S on that machine I care to use). The ratio of the IBM RS/6000-320 (list price, $13K) to the DEC-20/60 is 121:1, and with 4 x 4 unrolling of the inner loops, the 320 jumps from 11.9 MFlops to 29.5 Mflops, for a ratio of 300:1. The floating-point performance of these newer machines is fundamentally changing what we can do; however, it is not easy in real programs to achieve such performance. If you fall out of the cache, or don't re-use data in registers, or don't make use of all of the registers, your 30 Mflops falls to 1.5 Mflops. Indeed, for TeX typesetting, the RS/6000-320 is about 10% slower than the Sun SPARCstation. I conclude then that such newer machines are probably architecturally imbalanced (but of course, I'm prepared to work on them to get the higher performance when I can). The DEC-20/60 was, I feel, in very good balance. Our VAX 8600, with 6 times the DEC-20's floating-point performance, and 3 to 4 times its integer performance, handles only about 1/3 to 1/2 as many users as the DEC-20 before the load becomes unbearable. I hope that within a few years, we see a new generation of machines that provide the -20's balance, with performance reaching 100 MFlops or better; maybe then we can retire all of our old machines, including 100 million or so IBM PCs. ------- 23-Nov-90 01:21:48-MST,9403;000000000000 Mail-From: WANCHO created at 23-Nov-90 01:21:02 Date: Sat 17 Nov 90 17:39:04-MST Sender: "Nelson H. F. Beebe" Received: from [128.110.192.2] by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 17 Nov 90 17:42:39 MST From: "Nelson H. F. Beebe" Subject: Farewell to science.utah.edu -- perhaps a eulogy To: tops20@WSMR-SIMTEL20.ARMY.MIL cc: Beebe@[128.110.192.2], rodgers@[128.110.192.2], debar@[128.110.192.2] X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12638755784.17.BEEBE@SCIENCE.utah.edu> ReSent-From: WANCHO@WSMR-SIMTEL20.ARMY.MIL ReSent-To: TOPS20 ReSent-Date: Fri 23 Nov 1990 01:21-MST At 23:59:59 on October 31, 1990, our venerable DEC-20/60, science.utah.edu officially retired from service. It will continue to run with only staff access during the month of November, at the end of which, it will be powered off and deinstalled. The machine has given 12.5 years of wonderful service, with a maximum of 1000 user accounts at one time, though in the last 3 years, this number was usually under 600. The last classes taught using it were held during the summer quarter of 1990. Effective with the fall quarter, all Department of Mathematics classes moved to Sun workstations, with a few on the VAX 8600 (which will retire in the spring of 1991). Except for the last 3 years, CPU utilization has been at 90% or more, 24 hours a day. Statistics collected a couple of years ago showed that it bettered the San Diego Supercomputer Center's Cray X-MP/48 in user availability. A DEC-20/40 was originally purchased in March 1978 to provide half of its cycles for research (mostly, quantum chemistry) and half for teaching; cs.utah.edu got a second one at the same time (theirs retired four or five years ago). Ours was upgraded to a 20/60, perhaps about 1982 (my memory fails me). It served the entire College of Science at this University until the fall of 1986, when a major funding initiative provided expansions that gave Chemistry and Mathematics their own machines (an FPS-164 and a VAX 8600, respectively); Physics and Biology independently acquired their own smaller VAX facilities. At that time, the College of Science Computer, as the facility was known, ceased to report directly to the Dean of the College of Science, and became the Center for Scientific Computing under the Department of Mathematics. At that time, my faculty appointment moved from Chemistry to Mathematics. The College of Science now has hundreds of Macintoshes and IBM PCs, at least 50 Sun workstations (3, 4, 386i), several VAXes, a Multiflow (retired 2 weeks ago), a Stardent 1520, a few DECstations and VAXstations, and just starting to arrive how, IBM RS/6000s. This represents a substantial increase in computer power; more details are given below. Interestingly, during these last weeks, no power disturbances have hit Salt Lake City (a rare occurrence), and the DEC-20/60 ran about 2100 consecutive hours, far longer than it has ever run before. Until earlier this year, it had biweekly maintenance, so it was normally taken down at least every 336 hours. On Monday, 12-Nov-1990, a major power failure occurred that left parts of downtown Salt Lake City and some parts of the University of Utah campus without power for several hours; that of course brought our entire facility (DEC-20, VAXes, Stardent, and Suns) to a complete halt. With restoration of power, the DEC-20 booted normally, and I'm writing this last mail message on it. For those of you accustomed to reaching us at the address science.utah.edu, you will find that a UNIX file server, math.utah.edu, now answers to that name as well. Thus, e-mail will continue to arrive, but ftp accesses will put you on a UNIX machine. The major collections on science.utah.edu have been moved to subdirectories of the anonymous ftp login on math.utah.edu, and the entire collection is now also accessible via e-mail; send a message with the text "help" to tuglib@math.utah.edu to get started. Of course, if you have FTP access, you should use that instead, since you won't have to bother with unbundling e-mail parcels. Although UNIX has many wondrous features too, there are lots of things I miss that TOPS-20 has, including Undelete (number one on anybody's list, I guess). Real generation numbers in files. Use counts in the file system. Attributes in file names, particularly last writer. Real invisible files (instead of UNIX's hokey dot files) File archiving and migration. FTPs that preserve file time stamps. Command completion in the EXEC and almost all utilities (the UNIX csh's Ctl-D for filename completion is useful, but doesn't go far enough) An MM that keeps an editor fork alive, and lets you see the message in one window while you reply in the other (many of us are using Columbia's UNIX MM, which works very nicely, except for the editor problem). UNIX now has an enormous momentum, and has become the de facto operating system in science and engineering. I nevertheless hope that some of us with DEC-20 backgrounds someday will be able to carry some of these good ideas into a descendant of UNIX, which at least is conducive to user modifications of the shells and O/S. It has been interesting to see how relatively well the DEC-20/60 did at supporting large numbers of users. We usually had 20 to 30 people logged in, and near the end of each academic quarter, often had 50 to 70 (and things did get pretty slow then). However, a Sun SPARCstation SLC seems to get about as sluggish with 5 to 15 people logged in, and the Suns have about 3 times the memory of the DEC-20, and faster disks. For floating-point work, the DEC-20 is pretty slow; here are a few lines from my matrix multiply benchmarks (available in ~ftp/pub/benchmarks on math.utah.edu); these numbers are for 100 x 100 double precision multiplication with an inner loop that looks like "SUM = SUM + B(I,K)*C(K,J)": Normal inner loop (by rank) Test, Machine, Optimization Level Rank CPU Time MFlops matmr8.lst-f-ibm-3090-600vf-O2V 1.0000 0.023 sec 86.957 matmr8.lst-f-stardent-3040-O3 0.3538 0.065 sec 30.769 matmr8.lst-c-ibm-rs6000-530-opt 0.2035 0.113 sec 17.699 matmr8.lst-f-sgi-240gtx-pfa-O3 0.1484 0.155 sec 12.903 matmr8.lst-c-ibm-rs6000-320-opt 0.1369 0.168 sec 11.905 matmr8.lst-f-multiflow-14-300-O5 0.1139 0.202 sec 9.901 matmr8.lst-f-ibm-3090-600vf-O3 0.1111 0.207 sec 9.662 matmr8.lst-f-mips-rc3260-o2 0.0602 0.382 sec 5.236 matmr8.lst-f-sun-4-490-O4 0.0535 0.430 sec 4.651 matmr8.lst-f-decstation-5000-opt 0.0529 0.435 sec 4.598 matmr8.lst-f-apollo-dn10000-opt 0.0395 0.583 sec 3.431 matmr8.lst-f-decstation-3100-O3 0.0224 1.027 sec 1.947 matmr8.lst-c-sun-sparcstation-plus-O2 0.0217 1.062 sec 1.883 matmr8.lst-c-sun-sparcstation-opt 0.0192 1.196 sec 1.672 matmr8.lst-c-decstation-3100-opt 0.0189 1.217 sec 1.643 matmr8.lst-c-dg-aviion-ghcc-opt 0.0125 1.838 sec 1.088 matmr8.lst-c-NeXTstation-opt 0.0101 2.287 sec 0.875 matmr8.lst-f-dec-vax8600-opt 0.0075 3.080 sec 0.649 matmr8.lst-c-NeXT-opt 0.0030 7.796 sec 0.257 matmr8.lst-c-ibm-rt-opt 0.0024 9.400 sec 0.213 matmr8.lst-f-dec2060-opt 0.0011 20.391 sec 0.098 matmr8.lst-c-sun-3-50-opt 0.0007 34.812 sec 0.057 The 3090-600vf-O3 figure of 9.7 Mflops is in scalar mode; the -O2V result of 87 Mflops is in vector mode on one processor (automatic parallelization is not supported under AIX, which is the only O/S on that machine I care to use). The ratio of the IBM RS/6000-320 (list price, $13K) to the DEC-20/60 is 121:1, and with 4 x 4 unrolling of the inner loops, the 320 jumps from 11.9 MFlops to 29.5 Mflops, for a ratio of 300:1. The floating-point performance of these newer machines is fundamentally changing what we can do; however, it is not easy in real programs to achieve such performance. If you fall out of the cache, or don't re-use data in registers, or don't make use of all of the registers, your 30 Mflops falls to 1.5 Mflops. Indeed, for TeX typesetting, the RS/6000-320 is about 10% slower than the Sun SPARCstation. I conclude then that such newer machines are probably architecturally imbalanced (but of course, I'm prepared to work on them to get the higher performance when I can). The DEC-20/60 was, I feel, in very good balance. Our VAX 8600, with 6 times the DEC-20's floating-point performance, and 3 to 4 times its integer performance, handles only about 1/3 to 1/2 as many users as the DEC-20 before the load becomes unbearable. I hope that within a few years, we see a new generation of machines that provide the -20's balance, with performance reaching 100 MFlops or better; maybe then we can retire all of our old machines, including 100 million or so IBM PCs. 23-Nov-90 06:26:54-MST,670;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 23 Nov 90 06:26:50 MST Date: Fri 23 Nov 90 07:26:36-CST From: Clive Dawson Subject: Re: Farewell to science.utah.edu -- perhaps a eulogy To: Beebe@[128.110.192.2] cc: tops20@WSMR-SIMTEL20.ARMY.MIL, rodgers@[128.110.192.2], debar@[128.110.192.2] In-Reply-To: <12638755784.17.BEEBE@SCIENCE.utah.edu> Message-ID: <12640206229.25.AI.CLIVE@MCC.COM> Nelson-- Of all the similar farewell messages we've seen on this list over the last few years, I think yours is one of the best. Thanks for taking the time to write it. Clive ------- 16-Nov-90 09:49:20-MST,846;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 16 Nov 90 09:48:52 MST Received: by sandpiper.wesleyan.edu (5.57/Ultrix3.0-C) id AA00254; Fri, 16 Nov 90 11:48:06 -0500 Date: Fri, 16 Nov 90 11:48:06 -0500 Message-Id: <9011161648.AA00254@sandpiper.wesleyan.edu> From: Douglas Bigelow To: tops20@wsmr-simtel20.army.mil Subject: Trivia question Does anyone have a rough idea, offhand, of how many DEC-20s were manufactured? It would be a useful piece of information for an internal report we're writing which discusses Wesleyan's DEC-20 migration plans. (Dec '93 shutdown date tentative.) Of that number, how many are currently operative? (I've heard an estimate of 200.) Thanks! Doug Bigelow Wesleyan Univ. 17-Nov-90 17:43:54-MST,9244;000000000000 Return-Path: Received: from [128.110.192.2] by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 17 Nov 90 17:42:39 MST Date: Sat 17 Nov 90 17:39:04-MST From: "Nelson H. F. Beebe" Subject: Farewell to science.utah.edu -- perhaps a eulogy To: tops20@WSMR-SIMTEL20.ARMY.MIL cc: Beebe@[128.110.192.2], rodgers@[128.110.192.2], debar@[128.110.192.2] X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12638755784.17.BEEBE@SCIENCE.utah.edu> At 23:59:59 on October 31, 1990, our venerable DEC-20/60, science.utah.edu officially retired from service. It will continue to run with only staff access during the month of November, at the end of which, it will be powered off and deinstalled. The machine has given 12.5 years of wonderful service, with a maximum of 1000 user accounts at one time, though in the last 3 years, this number was usually under 600. The last classes taught using it were held during the summer quarter of 1990. Effective with the fall quarter, all Department of Mathematics classes moved to Sun workstations, with a few on the VAX 8600 (which will retire in the spring of 1991). Except for the last 3 years, CPU utilization has been at 90% or more, 24 hours a day. Statistics collected a couple of years ago showed that it bettered the San Diego Supercomputer Center's Cray X-MP/48 in user availability. A DEC-20/40 was originally purchased in March 1978 to provide half of its cycles for research (mostly, quantum chemistry) and half for teaching; cs.utah.edu got a second one at the same time (theirs retired four or five years ago). Ours was upgraded to a 20/60, perhaps about 1982 (my memory fails me). It served the entire College of Science at this University until the fall of 1986, when a major funding initiative provided expansions that gave Chemistry and Mathematics their own machines (an FPS-164 and a VAX 8600, respectively); Physics and Biology independently acquired their own smaller VAX facilities. At that time, the College of Science Computer, as the facility was known, ceased to report directly to the Dean of the College of Science, and became the Center for Scientific Computing under the Department of Mathematics. At that time, my faculty appointment moved from Chemistry to Mathematics. The College of Science now has hundreds of Macintoshes and IBM PCs, at least 50 Sun workstations (3, 4, 386i), several VAXes, a Multiflow (retired 2 weeks ago), a Stardent 1520, a few DECstations and VAXstations, and just starting to arrive how, IBM RS/6000s. This represents a substantial increase in computer power; more details are given below. Interestingly, during these last weeks, no power disturbances have hit Salt Lake City (a rare occurrence), and the DEC-20/60 ran about 2100 consecutive hours, far longer than it has ever run before. Until earlier this year, it had biweekly maintenance, so it was normally taken down at least every 336 hours. On Monday, 12-Nov-1990, a major power failure occurred that left parts of downtown Salt Lake City and some parts of the University of Utah campus without power for several hours; that of course brought our entire facility (DEC-20, VAXes, Stardent, and Suns) to a complete halt. With restoration of power, the DEC-20 booted normally, and I'm writing this last mail message on it. For those of you accustomed to reaching us at the address science.utah.edu, you will find that a UNIX file server, math.utah.edu, now answers to that name as well. Thus, e-mail will continue to arrive, but ftp accesses will put you on a UNIX machine. The major collections on science.utah.edu have been moved to subdirectories of the anonymous ftp login on math.utah.edu, and the entire collection is now also accessible via e-mail; send a message with the text "help" to tuglib@math.utah.edu to get started. Of course, if you have FTP access, you should use that instead, since you won't have to bother with unbundling e-mail parcels. Although UNIX has many wondrous features too, there are lots of things I miss that TOPS-20 has, including Undelete (number one on anybody's list, I guess). Real generation numbers in files. Use counts in the file system. Attributes in file names, particularly last writer. Real invisible files (instead of UNIX's hokey dot files) File archiving and migration. FTPs that preserve file time stamps. Command completion in the EXEC and almost all utilities (the UNIX csh's Ctl-D for filename completion is useful, but doesn't go far enough) An MM that keeps an editor fork alive, and lets you see the message in one window while you reply in the other (many of us are using Columbia's UNIX MM, which works very nicely, except for the editor problem). UNIX now has an enormous momentum, and has become the de facto operating system in science and engineering. I nevertheless hope that some of us with DEC-20 backgrounds someday will be able to carry some of these good ideas into a descendant of UNIX, which at least is conducive to user modifications of the shells and O/S. It has been interesting to see how relatively well the DEC-20/60 did at supporting large numbers of users. We usually had 20 to 30 people logged in, and near the end of each academic quarter, often had 50 to 70 (and things did get pretty slow then). However, a Sun SPARCstation SLC seems to get about as sluggish with 5 to 15 people logged in, and the Suns have about 3 times the memory of the DEC-20, and faster disks. For floating-point work, the DEC-20 is pretty slow; here are a few lines from my matrix multiply benchmarks (available in ~ftp/pub/benchmarks on math.utah.edu); these numbers are for 100 x 100 double precision multiplication with an inner loop that looks like "SUM = SUM + B(I,K)*C(K,J)": Normal inner loop (by rank) Test, Machine, Optimization Level Rank CPU Time MFlops matmr8.lst-f-ibm-3090-600vf-O2V 1.0000 0.023 sec 86.957 matmr8.lst-f-stardent-3040-O3 0.3538 0.065 sec 30.769 matmr8.lst-c-ibm-rs6000-530-opt 0.2035 0.113 sec 17.699 matmr8.lst-f-sgi-240gtx-pfa-O3 0.1484 0.155 sec 12.903 matmr8.lst-c-ibm-rs6000-320-opt 0.1369 0.168 sec 11.905 matmr8.lst-f-multiflow-14-300-O5 0.1139 0.202 sec 9.901 matmr8.lst-f-ibm-3090-600vf-O3 0.1111 0.207 sec 9.662 matmr8.lst-f-mips-rc3260-o2 0.0602 0.382 sec 5.236 matmr8.lst-f-sun-4-490-O4 0.0535 0.430 sec 4.651 matmr8.lst-f-decstation-5000-opt 0.0529 0.435 sec 4.598 matmr8.lst-f-apollo-dn10000-opt 0.0395 0.583 sec 3.431 matmr8.lst-f-decstation-3100-O3 0.0224 1.027 sec 1.947 matmr8.lst-c-sun-sparcstation-plus-O2 0.0217 1.062 sec 1.883 matmr8.lst-c-sun-sparcstation-opt 0.0192 1.196 sec 1.672 matmr8.lst-c-decstation-3100-opt 0.0189 1.217 sec 1.643 matmr8.lst-c-dg-aviion-ghcc-opt 0.0125 1.838 sec 1.088 matmr8.lst-c-NeXTstation-opt 0.0101 2.287 sec 0.875 matmr8.lst-f-dec-vax8600-opt 0.0075 3.080 sec 0.649 matmr8.lst-c-NeXT-opt 0.0030 7.796 sec 0.257 matmr8.lst-c-ibm-rt-opt 0.0024 9.400 sec 0.213 matmr8.lst-f-dec2060-opt 0.0011 20.391 sec 0.098 matmr8.lst-c-sun-3-50-opt 0.0007 34.812 sec 0.057 The 3090-600vf-O3 figure of 9.7 Mflops is in scalar mode; the -O2V result of 87 Mflops is in vector mode on one processor (automatic parallelization is not supported under AIX, which is the only O/S on that machine I care to use). The ratio of the IBM RS/6000-320 (list price, $13K) to the DEC-20/60 is 121:1, and with 4 x 4 unrolling of the inner loops, the 320 jumps from 11.9 MFlops to 29.5 Mflops, for a ratio of 300:1. The floating-point performance of these newer machines is fundamentally changing what we can do; however, it is not easy in real programs to achieve such performance. If you fall out of the cache, or don't re-use data in registers, or don't make use of all of the registers, your 30 Mflops falls to 1.5 Mflops. Indeed, for TeX typesetting, the RS/6000-320 is about 10% slower than the Sun SPARCstation. I conclude then that such newer machines are probably architecturally imbalanced (but of course, I'm prepared to work on them to get the higher performance when I can). The DEC-20/60 was, I feel, in very good balance. Our VAX 8600, with 6 times the DEC-20's floating-point performance, and 3 to 4 times its integer performance, handles only about 1/3 to 1/2 as many users as the DEC-20 before the load becomes unbearable. I hope that within a few years, we see a new generation of machines that provide the -20's balance, with performance reaching 100 MFlops or better; maybe then we can retire all of our old machines, including 100 million or so IBM PCs. ------- 23-Nov-90 01:21:48-MST,9403;000000000000 Mail-From: WANCHO created at 23-Nov-90 01:21:02 Date: Sat 17 Nov 90 17:39:04-MST Sender: "Nelson H. F. Beebe" Received: from [128.110.192.2] by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 17 Nov 90 17:42:39 MST From: "Nelson H. F. Beebe" Subject: Farewell to science.utah.edu -- perhaps a eulogy To: tops20@WSMR-SIMTEL20.ARMY.MIL cc: Beebe@[128.110.192.2], rodgers@[128.110.192.2], debar@[128.110.192.2] X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12638755784.17.BEEBE@SCIENCE.utah.edu> ReSent-From: WANCHO@WSMR-SIMTEL20.ARMY.MIL ReSent-To: TOPS20 ReSent-Date: Fri 23 Nov 1990 01:21-MST At 23:59:59 on October 31, 1990, our venerable DEC-20/60, science.utah.edu officially retired from service. It will continue to run with only staff access during the month of November, at the end of which, it will be powered off and deinstalled. The machine has given 12.5 years of wonderful service, with a maximum of 1000 user accounts at one time, though in the last 3 years, this number was usually under 600. The last classes taught using it were held during the summer quarter of 1990. Effective with the fall quarter, all Department of Mathematics classes moved to Sun workstations, with a few on the VAX 8600 (which will retire in the spring of 1991). Except for the last 3 years, CPU utilization has been at 90% or more, 24 hours a day. Statistics collected a couple of years ago showed that it bettered the San Diego Supercomputer Center's Cray X-MP/48 in user availability. A DEC-20/40 was originally purchased in March 1978 to provide half of its cycles for research (mostly, quantum chemistry) and half for teaching; cs.utah.edu got a second one at the same time (theirs retired four or five years ago). Ours was upgraded to a 20/60, perhaps about 1982 (my memory fails me). It served the entire College of Science at this University until the fall of 1986, when a major funding initiative provided expansions that gave Chemistry and Mathematics their own machines (an FPS-164 and a VAX 8600, respectively); Physics and Biology independently acquired their own smaller VAX facilities. At that time, the College of Science Computer, as the facility was known, ceased to report directly to the Dean of the College of Science, and became the Center for Scientific Computing under the Department of Mathematics. At that time, my faculty appointment moved from Chemistry to Mathematics. The College of Science now has hundreds of Macintoshes and IBM PCs, at least 50 Sun workstations (3, 4, 386i), several VAXes, a Multiflow (retired 2 weeks ago), a Stardent 1520, a few DECstations and VAXstations, and just starting to arrive how, IBM RS/6000s. This represents a substantial increase in computer power; more details are given below. Interestingly, during these last weeks, no power disturbances have hit Salt Lake City (a rare occurrence), and the DEC-20/60 ran about 2100 consecutive hours, far longer than it has ever run before. Until earlier this year, it had biweekly maintenance, so it was normally taken down at least every 336 hours. On Monday, 12-Nov-1990, a major power failure occurred that left parts of downtown Salt Lake City and some parts of the University of Utah campus without power for several hours; that of course brought our entire facility (DEC-20, VAXes, Stardent, and Suns) to a complete halt. With restoration of power, the DEC-20 booted normally, and I'm writing this last mail message on it. For those of you accustomed to reaching us at the address science.utah.edu, you will find that a UNIX file server, math.utah.edu, now answers to that name as well. Thus, e-mail will continue to arrive, but ftp accesses will put you on a UNIX machine. The major collections on science.utah.edu have been moved to subdirectories of the anonymous ftp login on math.utah.edu, and the entire collection is now also accessible via e-mail; send a message with the text "help" to tuglib@math.utah.edu to get started. Of course, if you have FTP access, you should use that instead, since you won't have to bother with unbundling e-mail parcels. Although UNIX has many wondrous features too, there are lots of things I miss that TOPS-20 has, including Undelete (number one on anybody's list, I guess). Real generation numbers in files. Use counts in the file system. Attributes in file names, particularly last writer. Real invisible files (instead of UNIX's hokey dot files) File archiving and migration. FTPs that preserve file time stamps. Command completion in the EXEC and almost all utilities (the UNIX csh's Ctl-D for filename completion is useful, but doesn't go far enough) An MM that keeps an editor fork alive, and lets you see the message in one window while you reply in the other (many of us are using Columbia's UNIX MM, which works very nicely, except for the editor problem). UNIX now has an enormous momentum, and has become the de facto operating system in science and engineering. I nevertheless hope that some of us with DEC-20 backgrounds someday will be able to carry some of these good ideas into a descendant of UNIX, which at least is conducive to user modifications of the shells and O/S. It has been interesting to see how relatively well the DEC-20/60 did at supporting large numbers of users. We usually had 20 to 30 people logged in, and near the end of each academic quarter, often had 50 to 70 (and things did get pretty slow then). However, a Sun SPARCstation SLC seems to get about as sluggish with 5 to 15 people logged in, and the Suns have about 3 times the memory of the DEC-20, and faster disks. For floating-point work, the DEC-20 is pretty slow; here are a few lines from my matrix multiply benchmarks (available in ~ftp/pub/benchmarks on math.utah.edu); these numbers are for 100 x 100 double precision multiplication with an inner loop that looks like "SUM = SUM + B(I,K)*C(K,J)": Normal inner loop (by rank) Test, Machine, Optimization Level Rank CPU Time MFlops matmr8.lst-f-ibm-3090-600vf-O2V 1.0000 0.023 sec 86.957 matmr8.lst-f-stardent-3040-O3 0.3538 0.065 sec 30.769 matmr8.lst-c-ibm-rs6000-530-opt 0.2035 0.113 sec 17.699 matmr8.lst-f-sgi-240gtx-pfa-O3 0.1484 0.155 sec 12.903 matmr8.lst-c-ibm-rs6000-320-opt 0.1369 0.168 sec 11.905 matmr8.lst-f-multiflow-14-300-O5 0.1139 0.202 sec 9.901 matmr8.lst-f-ibm-3090-600vf-O3 0.1111 0.207 sec 9.662 matmr8.lst-f-mips-rc3260-o2 0.0602 0.382 sec 5.236 matmr8.lst-f-sun-4-490-O4 0.0535 0.430 sec 4.651 matmr8.lst-f-decstation-5000-opt 0.0529 0.435 sec 4.598 matmr8.lst-f-apollo-dn10000-opt 0.0395 0.583 sec 3.431 matmr8.lst-f-decstation-3100-O3 0.0224 1.027 sec 1.947 matmr8.lst-c-sun-sparcstation-plus-O2 0.0217 1.062 sec 1.883 matmr8.lst-c-sun-sparcstation-opt 0.0192 1.196 sec 1.672 matmr8.lst-c-decstation-3100-opt 0.0189 1.217 sec 1.643 matmr8.lst-c-dg-aviion-ghcc-opt 0.0125 1.838 sec 1.088 matmr8.lst-c-NeXTstation-opt 0.0101 2.287 sec 0.875 matmr8.lst-f-dec-vax8600-opt 0.0075 3.080 sec 0.649 matmr8.lst-c-NeXT-opt 0.0030 7.796 sec 0.257 matmr8.lst-c-ibm-rt-opt 0.0024 9.400 sec 0.213 matmr8.lst-f-dec2060-opt 0.0011 20.391 sec 0.098 matmr8.lst-c-sun-3-50-opt 0.0007 34.812 sec 0.057 The 3090-600vf-O3 figure of 9.7 Mflops is in scalar mode; the -O2V result of 87 Mflops is in vector mode on one processor (automatic parallelization is not supported under AIX, which is the only O/S on that machine I care to use). The ratio of the IBM RS/6000-320 (list price, $13K) to the DEC-20/60 is 121:1, and with 4 x 4 unrolling of the inner loops, the 320 jumps from 11.9 MFlops to 29.5 Mflops, for a ratio of 300:1. The floating-point performance of these newer machines is fundamentally changing what we can do; however, it is not easy in real programs to achieve such performance. If you fall out of the cache, or don't re-use data in registers, or don't make use of all of the registers, your 30 Mflops falls to 1.5 Mflops. Indeed, for TeX typesetting, the RS/6000-320 is about 10% slower than the Sun SPARCstation. I conclude then that such newer machines are probably architecturally imbalanced (but of course, I'm prepared to work on them to get the higher performance when I can). The DEC-20/60 was, I feel, in very good balance. Our VAX 8600, with 6 times the DEC-20's floating-point performance, and 3 to 4 times its integer performance, handles only about 1/3 to 1/2 as many users as the DEC-20 before the load becomes unbearable. I hope that within a few years, we see a new generation of machines that provide the -20's balance, with performance reaching 100 MFlops or better; maybe then we can retire all of our old machines, including 100 million or so IBM PCs. 23-Nov-90 06:26:54-MST,670;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 23 Nov 90 06:26:50 MST Date: Fri 23 Nov 90 07:26:36-CST From: Clive Dawson Subject: Re: Farewell to science.utah.edu -- perhaps a eulogy To: Beebe@[128.110.192.2] cc: tops20@WSMR-SIMTEL20.ARMY.MIL, rodgers@[128.110.192.2], debar@[128.110.192.2] In-Reply-To: <12638755784.17.BEEBE@SCIENCE.utah.edu> Message-ID: <12640206229.25.AI.CLIVE@MCC.COM> Nelson-- Of all the similar farewell messages we've seen on this list over the last few years, I think yours is one of the best. Thanks for taking the time to write it. Clive ------- 4-Dec-90 17:23:15-MST,872;000000000000 Return-Path: Received: from math.utah.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 4 Dec 90 17:22:59 MST Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA21645; Mon, 3 Dec 90 10:50:34 MST Date: Mon 3 Dec 90 10:46:02-MST From: Pieter Subject: That's all folks... To: tops20%wsmr-simtel20.army.mil@math.utah.edu Cc: Bowman@[128.110.192.2] X-Us-Mail: "Center for Scientific Computing, Department of Mathematics" X-Us-Mail: "224 South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: 801-581-5252 Message-Id: <12642874898.9.OP.BOWMAN@SCIENCE.utah.edu> This is the final message to be sent from science.utah.edu a DEC-20/60 which has been a good machine for about 11 of my years. Pieter bowman@science.utah.edu bowman@math.utah.edu ------- 13-Dec-90 05:52:41-MST,1374;000000000000 Return-Path: Received: from Hamlet.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 13 Dec 90 05:52:26 MST Date: Thu 13 Dec 90 04:52:08-PST From: Jim Lewinson Subject: Bay Area DEC-20 day event To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-ID: <12645442836.79.A.JIML@Hamlet.Stanford.EDU> I suspect that this list isn't flooding anyone, so I won't even attempt to limit the distribution. Besides, anyone still on it is probably happy to hear about DEC-20 hackers still getting together even if it is far away. At least this isn't another obituary! We are planning another DEC-20 Day get-together for those who still remember how many bits there are in a full DECk. If anyone is interested in joining us for lunch on Thursday, December 20, 1990 at noon. We'll be meeting at either China Lion (Palo Alto, California) or Su Hong (Menlo Park, California), depending on what people prefer. Please RSVP by Tuesday, Dec 18 (A halfword?) so I can make a reservation for us. Let me know if you have a dining preference. There won't be any items such as bumper stickers unless someone becomes inspired to do something about them. (Hint, Hint.) Jim P.S. If you want to organize a local (to you) event, I'll try to point the organizers at the other interested parties. ------- 20-Dec-90 08:38:38-MST,1851;000000000000 Return-Path: <@Sunburn.Stanford.EDU:Operator@OSU-20.IRCC.OHIO-STATE.EDU> Received: from Sunburn.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 20 Dec 90 08:38:21 MST Received: from tut.cis.ohio-state.edu by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA00151; Thu, 20 Dec 90 07:38:02 -0800 Received: from osu-20.ircc.ohio-state.edu by tut.cis.ohio-state.edu (5.61-kk/5.901120) id AA16119; Thu, 20 Dec 90 10:36:18 -0500 Message-Id: <9012201536.AA16119@tut.cis.ohio-state.edu> Date: Thu 20 Dec 90 10:35:51-EST From: System Opr Subject: speaking from the mound To: tops-20@OSU-20.IRCC.OHIO-STATE.EDU Cc: Operator@OSU-20.IRCC.OHIO-STATE.EDU Today, Dec 20, 1990, at 10:30 AM EST, osu-20.ircc.ohio-state.edu, aka mike.cis.ohio-state.edu, will be powered off permanently. Mike is a DECsystem 2060, and has been so since spring of 1982 when he was upgraded from a 2020. The site started out with a DECsystem 1050, KA serial number 76 in the early 1970s, or perhaps late 60s; the origins are lost in the mists of time, as with all great mythic figures. The KA was named Max, the 2020 was called Minnie. Mike gained his name when he gained Ethernet access, and was also known as Michelle and occasionally Adam Selene, all after the computer revolutionary in Heinlein's _The Moon is a Harsh Mistress_. The KA was primarily for AI research, and with the upgrade to a 2020 users from all of Ohio State started to use it for editing, mail and bboard access, along with Scribe, Macsyma, simulations, LISP, and other useful things. In the end, AI moved to specialized machines, and Mike ended up doing news, mail and network access for the rest of campus. He is being replaced in this by 2 DEC 5400s. He will be genuinely missed. Lum Johnson Bryan Dunlap ------- 30-Dec-90 15:55:49-MST,578;000000000000 Mail-From: WANCHO created at 30-Dec-90 15:55:45 Date: Sun, 30 Dec 1990 15:55 MST Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: TOPS20 Mail archives moved The TOPS20 Mailing List Archives have been reassembled into yearly mail files named MAIL-yyyy.TXT. Those which would have been too large for MM to read were split into A and B parts. All the files have been moved to PD3:. --Frank