2-Jan-92 08:13:03-MST,2963;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 Jan 92 08:12:35 MST Received: by sandpiper.wesleyan.edu (5.61/1.35) id AA05397; Thu, 2 Jan 92 10:12:26 -0500 Date: Thu, 2 Jan 92 10:12:26 -0500 Message-Id: <9201021512.AA05397@sandpiper.wesleyan.edu> From: Douglas Bigelow To: tops20@wsmr-simtel20.army.mil Subject: More TELNET problems Greetings, all; As long as I've had my old TOPS20 hat recently, I though I'd air another Telnet option negotiation problem. This one is similar to the DATA MARK problem I'd mentioned a few days ago. Here's a problem I've seen from NCSA Telnet clients connecting to my KL. Sending two IAC IP (interrupt process) commands will hang the connection. In the Macintosh version of NCSA Telnet a control-C sends an IAC IP by default, so it's a frequent problem. In this specific case, what's happening is: 1st control-C: PC to KL: IAC IP ;interrupt process IAC DO TM ;do timing mark KL to PC: IAC WILL TM ;will timing mark IAC DM ;data mark IAC DO TM ;do timing mark PC to KL: IAC WONT TM ;wont timing mark 2nd control-C: PC to KL: IAC IP ;interrupt process IAC DO TM ;do timing mark KL to PC: IAC DM ;data mark IAC DO TM ;do timing mark PC to KL: IAC WONT TM ;wont timing mark Note that the second time, the 20 didn't respond to the timing mark request. The client, meanwhile, is properly discarding output waiting until the timing mark is acknowledged. Communications continue both ways, but there is no longer any echo to the client screen. Closing the telnet connection and restarting is the only remedy. I can patch this one in the NVTDO: routine of TTANDV, where DO processing is handled. At NVTDO1: +2 there is the sequence: TDNE T3,NCTOPF(T2) ;IS THE OPTION ON? JRST NVTSNR ;YES, SEND NO REPLY If I patch out the JRST with a JFCL, everything works. The 20 seems to think that DO/DONT sequences will only come once and can be ignored if they're repeated. This breaks conventional timing mark logic. I haven't really investigated to see if the above patch has any other side effects. Is there something I've missed? There's a more serious problem that I've made no progress in diagnosing. When NCSA Telnet users connected to the KL are TYPE'ing out long files, about 50% of the time the typing rate will start dramatically slowing after five to ten pages of output. The connection will slow and slow until it's typing out a line or so every thirty seconds. If you try to control-C out, it may take several minutes before it will respond. Then things will return to normal for subsequent commands. It's not related to either system or network load -- other connections will be humming along at high speed while this occurs. Any obvious ideas? Thanks -- Doug 3-Jan-92 07:39:16-MST,4671;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 3 Jan 92 07:39:04 MST Date: Thu, 2 Jan 92 18:39:21 CST From: Clive Dawson Subject: Admiral Grace Murray Hopper dies To: tops-20@wsmr-simtel20.army.mil Message-ID: <12746497018.52.AI.CLIVE@MCC.COM> I came across the following item, and figured this list probably contains quite a few people who had the pleasure of knowing or meeting Admiral Hopper. Another giant passes... Admiral Hopper Dies Rear Admiral Grace Murray Hopper (USNR Ret.) died New Year's Day at her home in Arlington, Virginia. She had celebrated her 85th birthday on December 9. At the time of her death she was employed as a senior consultant at Digital Equipment Corporation, and until 18 months ago was actively representing the company at industry forums, making presentations that focused on Government issues and participating in corporate educational programs. In September, President George Bush awarded the National Medal of Technology to Admiral Hopper "for her pioneering accomplishments in the development of computer programming languages that simplified computer technology and opened the door to a significantly larger universe of users." She was the first woman to receive the award as an individual. Admiral Hopper was sometimes called "Amazing Grace" because she recorded successful careers in academia, business and the United States Navy while making history in the computer field. Just as Adm. Hyman Rickover was father of the nuclear navy, Rear Adm. Hopper was the mother of computerized data automation in the naval service. Admiral Hopper joined Digital in 1986, shortly after her retirement as the U.S. Navy's oldest officer on active duty. The ceremony was conducted aboard the USS Constitution, the service's oldest commissioned warship. She had devoted her military career to keeping the Navy on the leading edge of computer technology. Admiral Hopper was born Grace Brewster Murray on December 9, 1906 in New York City. She began summering in Wolfeboro, N.H., in 1907 and regarded the town on the shores of Lake Winnipesaukee as her second home. After receiving a Ph.D in mathematics from Yale, she began her professional life as a math teacher at Vassar College, her alma mater, where she ultimately became an associate professor. Later, she worked as a top scientist at Sperry Corporation and its predecessors. However, her employer of choice was always the Navy, which she joined in 1943 at the height of World War II. As a lieutenant assigned to the Bureau of Ordnance Computation Project at Harvard University, Adm. Hopper was thrust into the world of computing as a programmer on the first large scale digital computer, the Mark I. Mustered out of the Navy in 1946, she remained at Harvard as a faculty member in the computation laboratory. She continued to work on Mark II and Mark II Navy computers and maintained her Navy career as an active duty reservist. Although retired from the Navy reserve in 1966 because of age, Adm. Hopper was recalled within a year to full-time active duty and steadily advanced to flag rank. Her assignment to the Naval Data Automation Command in Washington, D.C., permitted her to refine computer language techniques to the Navy's advantage and to keep that service at the cutting edge of computer technology. Adm. Hopper had received honorary degrees from more than 40 colleges and universities, and had been honored by her peers on several occasions. She was recipient of the first Computer Sciences "Man of the Year" award given by the Data Processing Management Association. Her entry in "Who's Who" takes 34 lines to thumbnail her accomplishments, appointments and honors. She is survived by a brother, Dr. Roger F. Murray II of New Hampshire, a sister, Mary Murray Westcote of New Jersey, nieces and nephews. ------- 6-Jan-92 08:00:47-MST,1635;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Jan 92 08:00:07 MST Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.23 ) id AA24025; Sun, 5 Jan 92 21:27:33 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA00379; Sun, 5 Jan 92 21:27:28 PST Date: Sun, 5 Jan 1992 21:27:08 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: TELNET To: TOPS-20 Hackers and Yackers Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Doug - The code you commented out is important, because it prevents protocol loops. The bug occurs when two sides are losing; they'll go babbling at each other endlessly. You are never supposed to acknowledge a change into a state you are already in. A better fix would probably be to have TOPS-20 always say `WONT TM', since you want a response to all options. I think if you patch NVTDTM to be a RET you'll get this behavior. Timing mark is a very poorly thought-out option in Telnet protocol and it's a shame this hasn't been cleaned up. Clients should never discard output waiting on timing marks. The anchor for such things is a data mark. It may be worthwhile getting a protocol analyzer for the slowdown bug. That sounds a lot like silly window syndrome, which TOPS-20 is supposed to be able to avoid. -- Mark -- 8-Jan-92 08:24:00-MST,659;000000000000 Return-Path: Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 8 Jan 92 08:07:46 MST Date: Wed, 8 Jan 92 10:09 EST From: JERRY WEINER BBN 617-873-3242 Subject: Who still has DEC-20's To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL X-VMS-To: @TOPS Folks, We still operate two DEC-20's in a cluster doing MIS type processing. I am interested in finding out who still runs DEC-10's or DEC-20's doing production business processing and what they play to do. If any one has names and contacts of folks who are in this and can share them, please send them along. Thanx, Jerry Weiner 9-Jan-92 09:21:37-MST,1757;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 9 Jan 92 09:21:33 MST Date: Thu, 9 Jan 92 10:19:12 CST From: Clive Dawson Subject: Re: Who still has DEC-20's To: JWEINER@ccr2.bbn.com cc: TOPS-20@WSMR-SIMTEL20.ARMY.MIL In-Reply-To: Message from "JERRY WEINER BBN 617-873-3242 " of Thu, 9 Jan 92 09:51:10 CST Message-ID: <12748240978.33.AI.CLIVE@MCC.COM> We still operate two DEC-20's in a cluster doing MIS type processing. I am interested in finding out who still runs DEC-10's or DEC-20's doing production business processing and what they play to do. If any one has names and contacts of folks who are in this and can share them, please send them along. Thanx, Jerry Weiner Hi Jerry! The Texas State Purchasing Commission still operates a DEC-10 (1090 system, I believe) for various business DP applications. I don't have any info on their future plans, but could probably dig up a contact if you'd like. Meanwhile, I'd like to expand your query and find out who still runs ANY DEC-10's or 20's, regardless of the application. If folks on this list reply to me giving me info on systems they're still running, or other systems they know about, I'll compile it all and post it. Something more or less as follows would be good: System type: DEC-2065 Operating System/Version: TOPS-20 5.4/6.0 Organization: MCC Location: Austin, Texas Primary use (business/ education/research/etc): Research Hostname (if any): MCC.COM Approx. shutdown date (if any): Spring, 1992 Primary contact (if known): Clive Dawson 512-338-3430 Feel free to add any other relevant info. Cheers, Clive ------- 10-Jan-92 14:49:06-MST,1769;000000000000 Return-Path: Received: from mathom.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 10 Jan 92 14:48:59 MST Date: Fri 10 Jan 92 13:47:20-PST From: William "Chops" Westfield Subject: Re: Who still has DEC-20's To: AI.CLIVE@MCC.COM cc: JWEINER@ccr2.bbn.com, TOPS-20@WSMR-SIMTEL20.ARMY.MIL In-Reply-To: <12748240978.33.AI.CLIVE@MCC.COM> Message-ID: <12748562858.16.BILLW@mathom.cisco.com> System type: DEC-2065 Operating System/Version: TOPS-20 6.1 (Stanford) Organization: cisco Location: Menlo Park, CA Primary use (business/ education/research/etc): BillW reads his mail, SUDS Hostname (if any): Mathom.cisco.com Approx. shutdown date (if any): soon Primary contact (if known): No one :-( System type: DEC-2065 Operating System/Version: TOPS-20 6.1 (Stanford) Organization: cisco Location: Menlo Park, CA Primary use (business/ education/research/etc): Part of cisco customer database Hostname (if any): Heap.cisco.com Approx. shutdown date (if any): soon Primary contact (if known): No one :-( cisco had a total of four 20's at one point (Mathom, Heap, Hulk, and a spare) Currently we would like to get rid of them all, but they linger due to databases and stuff that are difficult to move (and moving them is a low priority.) SUDS is the "Stanford University Drawing System", a schematic capture/pc layout system we used for many of our early designs (MCI, CSC-16, CSC/2). Newer designs are being done with newer packages that support simulation as well, which I guess is good. At least one 20 will probably be here forever to continue to support those designs. I think I'm the last person who actually reads mail on the 20. BillW ------- 11-Jan-92 10:17:43-MST,2274;000000000000 Return-Path: Received: from tymix.Tymnet.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 11 Jan 92 10:17:39 MST Received: from tardis.tymnet.com by tymix.Tymnet.COM (4.1/SMI-4.1) id AA07110; Fri, 10 Jan 92 19:18:44 PST Received: by tardis.tymnet.com (4.1/SMI-4.1) id AA02066; Fri, 10 Jan 92 19:18:42 PST From: jms@tardis.Tymnet.COM (Joe Smith) Message-Id: <9201110318.AA02066@tardis.tymnet.com> Subject: Re: Who still has DEC-20's To: AI.CLIVE@MCC.COM (Clive Dawson) Date: Fri, 10 Jan 92 19:18:40 PST Cc: tops20@wsmr-simtel20.army.mil In-Reply-To: <12748240978.33.AI.CLIVE@MCC.COM>; from "Clive Dawson" at Jan 9, 92 10:19 am X-Mailer: ELM [version 2.3 PL11] System type: DEC-1090 Operating System/Version: TYMCOM-X P035/E01 (TOPS-10 variant) Organization: BT North America, TYMNET Operations Location: Fremont, California Primary use (business/ education/research/etc): Business Primary contact (if known): Carl Baltrunas, 408/922-6206 Hostname and shutdown date: (MX only, these have no IP addresses) F23.Tymnet.COM - F26.Tymnet.COM Summer 1992 F30.Tymnet.COM - F33.Tymnet.COM Fall 1992 F34.Tymnet.COM - F37.Tymnet.COM 1-Jul-91 F38.Tymnet.COM - F56.Tymnet.COM 30-Sep-91 F74.Tymnet.COM - (MAIL host) System type: DEC-2020 Operating System/Version: TYMCOM-X P035/E01 (TOPS-10 variant) Organization: BT North America, TYMNET Operations Location: San Jose, California Primary use (business/ education/research/etc): Business Primary contact (if known): Joe Smith, 408/922-6220 Hostname and shutdown date: (MX only, these have no IP addresses) X14.Tymnet.COM - X17.Tymnet.COM - System type: DEC-2020 Operating System/Version: TYMCOM-X P035/C01 (TOPS-10 variant) Organization: TRW Network Services Location: Anaheim, California Primary use (business/ education/research/etc): Business Hostname and shutdown dates: S33, Summer 1992 -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or JMS@F74.TYMNET.COM BTNA Tech Services TYMNET| CA license plate: "POPJ P," PDP-10, 36 bits forever PO Box 49019, MS-C51 | Married to the LB, Quantum Leap's #1 net.fan San Jose, CA 95161-9019 | humorous disclaimer: "My Amiga 3000 speaks for me." 13-Jan-92 08:02:48-MST,2153;000000000000 Return-Path: Received: from dirt.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 13 Jan 92 08:02:42 MST Received: by dirt.cisco.com; Sun, 12 Jan 92 07:01:11 -0800 Date: Sun, 12 Jan 92 07:01:11 -0800 From: Doug Faunt N6TQS 415-688-8269 Message-Id: <9201121501.AA02176@dirt.cisco.com> To: BILLW@mathom.cisco.com Cc: AI.CLIVE@MCC.COM, JWEINER@ccr2.bbn.com, TOPS-20@WSMR-SIMTEL20.ARMY.MIL In-Reply-To: <12748562858.16.BILLW@mathom.cisco.com> Subject: Who still has DEC-20's Date: Fri 10 Jan 92 13:47:20-PST From: William "Chops" Westfield System type: DEC-2065 Operating System/Version: TOPS-20 6.1 (Stanford) Organization: cisco Location: Menlo Park, CA Primary use (business/ education/research/etc): BillW reads his mail, SUDS Hostname (if any): Mathom.cisco.com Approx. shutdown date (if any): soon Primary contact (if known): No one :-( System type: DEC-2065 Operating System/Version: TOPS-20 6.1 (Stanford) Organization: cisco Location: Menlo Park, CA Primary use (business/ education/research/etc): Part of cisco customer database Hostname (if any): Heap.cisco.com Approx. shutdown date (if any): soon Primary contact (if known): No one :-( cisco had a total of four 20's at one point (Mathom, Heap, Hulk, and a spare) Currently we would like to get rid of them all, but they linger due to databases and stuff that are difficult to move (and moving them is a low priority.) SUDS is the "Stanford University Drawing System", a schematic capture/pc layout system we used for many of our early designs (MCI, CSC-16, CSC/2). Newer designs are being done with newer packages that support simulation as well, which I guess is good. At least one 20 will probably be here forever to continue to support those designs. I think I'm the last person who actually reads mail on the 20. BillW ------- There are about 10 people who get their mail on mathom, and a larger number who get their mail on heap, still. 13-Jan-92 08:24:17-MST,1362;000000000000 Return-Path: Received: from sunlight.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 13 Jan 92 08:24:13 MST Received: from elaine46.Stanford.EDU by sunlight.Stanford.EDU (4.1/AIR-1.0) id AA24012; Sat, 11 Jan 92 18:48:19 PST Date: Sat, 11 Jan 92 18:48:19 PST From: alderson@leland.Stanford.EDU Message-Id: <9201120248.AA24012@sunlight.Stanford.EDU> Received: by elaine46.Stanford.EDU (4.1/SMI-4.1) id AA04696; Sat, 11 Jan 92 18:48:18 PST To: TOPS-20@wsmr-simtel20.army.mil In-Reply-To: William "Chops" Westfield's message of Fri 10 Jan 92 13:47:20-PST <12748562858.16.BILLW@mathom.cisco.com> Subject: Who still has DEC-20's Reply-To: alderson@leland.stanford.edu Well, I know a couple of people in cisco's MIS department who read mail there. And I'm upgrading the monitor on their system (Heap) to at least AP16 to fix a nasty 1022 interaction. Does anyone remember if AP18 or 19 was the last 6.1 autopatch? Unbelievable. I'm still (available as) a Tops-20 hacker in this day and age. Rich Alderson 'I wish life was not so short,' he thought. 'Languages take such a time, and so do all the things one wants to know about.' --J. R. R. Tolkien, alderson@leland.stanford.edu _The Lost Road_ 15-Jan-92 13:39:13-MST,3786;000000000000 Return-Path: Received: from oaunx1.CTD.ORNL.GOV by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Jan 92 13:39:04 MST Received: by oaunx1.CTD.ORNL.GOV (5.57/Ultrix2.4-C) id AA26584; Wed, 15 Jan 92 10:46:10 -0500 Received: from umcgate by oaunx1 via MR/STC10 with conversational-MRIF; Wed, 15 Jan 92 10:46:09 -0500 Posted: Wed, 15 Jan 92 10:40:47 -0500 Date: Wed, 15 Jan 92 10:35:01 -0500 Sender: jonesja@ornl.gov From: "Jeffrey A Jones" Message-Id: <64040151102991/726744@STC> App-Message-Id: <10930151102991/1611675@KSV> To: tops-20@wsmr-simtel20.army.mil Cc: whitehs@ornl.gov, winklerdr@ornl.gov Subject: MMES - Oak Ridge, TN - DEC 10/20's Msg-Class: ALL-IN-1 V2.4 PBL8C3 7-JUN-1990 [This message is converted from WPS-PLUS to ASCII] ------- Forwarded message Posted: Wed, 15 Jan 92 00:00:01 -0500 Date: Wed, 15 Jan 92 10:00:01 -0500 Author: jeffrey a jones Subject: MMES - Oak Ridge, TN - DEC 10/20's NONE [This message is converted from WPS-PLUS to ASCII] All, Following is the current list of DEC-10 and DEC-20's running at Martin Marietta Energy Systems (MMES) in Oak Ridge, Tn. As a rough estimate, these systems in total have a user base of between 5000 - 7000 users. Jeff Jones JZJ@ORNL.GOV (615)576-2335 ------------------------------------------------------------------------------- System Type: Five Processor DEC-10 (KL10-DA's) Operating System/Version: TOPS-10 V7.03 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: IS Hostname: No external hostname Approx. Shutdown Date: 1993 Primary Contact: Wishes to remain anonymous ------------------------------------------------------------------------------- System Type: Single Processor DEC-10 (KL10-EA) Operating System/Version: TOPS-10 V7.03 Organization: Business Systems Location: Oak Ridge, TN Primary use: MIS Hostname: No external hostname Approx. Shutdown Date: 1993 Primary Contact: Wishes to remain anonymous ------------------------------------------------------------------------------- System Type: DEC-2060 Operating System/Version: TOPS-20 V7.0 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No external hostname Approx. Shutdown Date: No specific time schedule but applications are being converted to other platforms. Primary Contact: Wishes to remain anonymous ------------------------------------------------------------------------------- System Type: DEC-2065 (not clustered, but have disks dual ported with system below) Operating System/Version: TOPS-20 V6.1 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No external hostname Approx. Shutdown Date: July, 1993 Primary Contact: Wishes to remain anonymous ------------------------------------------------------------------------------- System Type: DEC-2065 (not clustered, but have disks dual ported with system above) Operating System/Version: TOPS-20 V6.1 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No external hostname Approx. Shutdown Date: July, 1993 Primary Contact: Wishes to remain anonymous ------------------------------------------------------------------------------- System Type: DEC-2065 Operating System/Version: TOPS-20 V6.1 Organization: Procurement Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No External hostname Approx. Shutdown Date: 1993 Primary Contact: Jeff Jones ------- End of Forwarded message 21-Jan-92 08:30:24-MST,1703;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 Jan 92 08:30:07 MST Received: by sandpiper.wesleyan.edu (5.61/1.35) id AA01530; Mon, 20 Jan 92 16:46:33 -0500 Date: Mon, 20 Jan 92 16:46:33 -0500 Message-Id: <9201202146.AA01530@sandpiper.wesleyan.edu> From: Douglas Bigelow To: tops20@wsmr-simtel20.army.mil Subject: Strange problems with page mapping I've been seeing a strange problem with page mapping lately, on a system which has not had any system software changes for years. I thought I'd toss this out for comment. When our 2060 is fairly busy with many 1022 users, they occasionally fail with an unexpected page mapping error. Investigation finally yielded: Program is trying to map a page of a disk file into memory for read only access. In a typical sample, file page 0 might be being mapped into process page 2015. The PMAP fails with the error "Entire file structure full". There is no problem accessing the file, and typically several other files have already been mapped in similar ways. Since none of the file structures are anywhere near full, and in any case the PMAP operation is mapping a read-only file into memory, my best guess is that my swapping space is filling up and I'm getting a misleading message. Can anyone suggest another alternative? Even though we're phasing this system out, since replacing direct lines with Telnet access the system has gotten more popular and considerably busier. Otherwise the software has been static for years. Thanks for any advice! / Doug Bigelow Wesleyan University 22-Jan-92 02:55:36-MST,1283;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 22 Jan 92 02:55:33 MST Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.23 ) id AA28859; Wed, 22 Jan 92 01:55:24 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA01241; Wed, 22 Jan 92 01:55:18 PST Date: Wed, 22 Jan 1992 01:50:33 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: re: Strange problems with page mapping To: Douglas Bigelow Cc: tops20@wsmr-simtel20.army.mil In-Reply-To: <9201202146.AA01530@sandpiper.wesleyan.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII `Entire file structure full' is the lying string from the OPNX10 error. The real cause of this error is that you have run out of OFN's. If you are running many 1022 jobs I am not terribly surprised that this happens. Rebuild your monitor with a larger value of NOFN, and while you are at it you may want to increase SSPT as well. How's that for a quick and easy answer? ;-) -- Mark -- 22-Jan-92 09:37:12-MST,1076;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 22 Jan 92 09:36:46 MST Received: by sandpiper.wesleyan.edu (5.61/1.35) id AA01019; Wed, 22 Jan 92 11:36:30 -0500 Date: Wed, 22 Jan 92 11:36:30 -0500 Message-Id: <9201221636.AA01019@sandpiper.wesleyan.edu> From: Douglas Bigelow To: MRC@panda.com Cc: tops20@wsmr-simtel20.army.mil In-Reply-To: Mark Crispin's message of Wed, 22 Jan 1992 01:50:33 -0800 (PST) Subject: Re: Strange problems with page mapping >> `Entire file structure full' is the lying string from the OPNX10 error. The >> real cause of this error is that you have run out of OFN's. If you are >> running many 1022 jobs I am not terribly surprised that this happens. Whoops, I'm embarrassed. After your message, I went back and looked at the CTY logs and found some NOOFN bugchecks. If I'd checked there first, the problem would have been obvious and I wouldn't have wasted my time debugging. Thanks again, Mark! -- Doug 31-Jan-92 09:23:25-MST,483;000000000000 Return-Path: Received: from ccr2.bbn.com ([128.89.1.145]) by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 31 Jan 92 09:22:17 MST Date: Fri, 31 Jan 92 08:54 EST From: JERRY WEINER BBN 617-873-3242 Subject: SCSI Adapter for MASSBUS To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL X-VMS-To: @TOPS Folks, Did or does anyone make a real product to attach SCSI tapes to a massbus that looks like a TOPs-20 supported tape device? Thanx, Jerry 6-Feb-92 08:11:25-MST,588;000000000000 Return-Path: Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 6 Feb 92 08:11:20 MST Date: Thu, 6 Feb 92 08:19 EST From: JERRY WEINER BBN 617-873-3242 Subject: MASSBUS to SCSI To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL X-VMS-To: @TOPS Folks, I put a note ou the other day asking if anyone knew of a MASSBUS to SCSI adapter for a DEC20. The SC Group (old Sytems Concepts) makes a board that replaces an RH10/20 and yields a SCSI bus. they also sell the disks and TOPS 10/20 monitor code changes. Jerry Weiner 12-Feb-92 14:43:35-MST,995;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 12 Feb 92 14:43:32 MST Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.23 ) id AA24188; Wed, 12 Feb 92 13:42:12 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA00321; Wed, 12 Feb 92 13:42:08 PST Date: Wed, 12 Feb 1992 13:40:15 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: UP2LNG bughlt To: TOPS-20 Hackers and Yackers Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Have you seen the new UP2LNG bughlt? Apparently, DEC has decided that TOPS-20 may not live longer then 397 days, 16 hours, and 22 minutes. So, it looks like multi-year uptimes are not on our horizon... -- Mark -- 12-Mar-92 21:52:48-MST,1470;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 12 Mar 92 21:52:44 MST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.24 ) id AA25848; Thu, 12 Mar 92 20:52:40 -0800 Date: Thu, 12 Mar 1992 20:50:04 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: sad news To: TOPS-20 Hackers and Yackers Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This came in while SIMTEL20 was down. This is sad news for all LCG hackers, especially for the TOPS-10 folks. I only had the pleasure of meeting Tony on a couple of occasions. Subject: Bad news for old LCG-types (but I'm only the messenger) Date: Fri, 21 Feb 92 12:13:33 -0500 From: spider@zk3.dec.com [Some of you may already have heard this news from another source. If so, I'm sorry for the duplication, but we want to be sure that all interested parties are informed.] Tony Wachs passed away the morning of Thursday, 20-Feb-1992, after a fall on Sunday the 16th. (A blood clot is the suspected cause.) Cards & letters to the family (his widow's name is Norma Rae Wachs) should be addressed to 1 High Street Natick MA 01760 [USA] 26-Mar-92 06:43:56-MST,445;000000000000 Return-Path: Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 26 Mar 92 06:43:53 MST Date: Thu, 26 Mar 92 08:44 EST From: JERRY WEINER BBN 617-873-3242 Subject: field Service To: tops-20@wsmr-simtel20.army.mil X-VMS-To: @TOPS Folks, Anyone know of any real organization doinng DEC-20 Field Service in the New England area other than DEC? Thanx, Jerry Weiner 28-Mar-92 07:34:30-MST,569;000000000000 Return-Path: Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 28 Mar 92 07:34:26 MST Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31); id AA01219; Sat, 28 Mar 92 09:34:57 EST for TOPS-20@WSMR-SIMTEL20.ARMY.MIL Date: Sat, 28 Mar 92 09:32:50 EST From: John_Wilson@MTS.RPI.EDU To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-Id: <2790198@MTS.RPI.EDU> Subject: this list Is this list still going? Please add me to it if so. I have a KS10+RM03+RM80 which I'm trying to get running. Thanks, John_Wilson@MTS.RPI.EDU 30-Mar-92 19:15:21-MST,585;000000000000 Return-Path: Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 30 Mar 92 19:15:15 MST Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31); id AA29793; Mon, 30 Mar 92 21:15:49 EST for TOPS-20@WSMR-SIMTEL20.ARMY.MIL Date: Mon, 30 Mar 92 21:13:40 EST From: John_Wilson@MTS.RPI.EDU To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-Id: <2793959@MTS.RPI.EDU> Subject: KS10 I have been looking far and wide for a set of KS10 prints. Does anyone have a set they'd be willing to copy for me? I would cover all costs. John_Wilson@MTS.RPI.EDU 1-Apr-92 11:28:54-MST,3843;000000000000 Return-Path: Received: from Valinor.Stanford.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 Apr 92 11:28:44 MST Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA08930; Wed, 1 Apr 92 10:28:29 -0800 Resent-Message-Id: <9204011828.AA08930@Valinor.Stanford.EDU> Return-Path: <@jessica.stanford.edu:cisco-forw@spot.Colorado.EDU> Received: from Jessica.Stanford.EDU by Valinor.Stanford.EDU (5.65/inc-1.0) id AA07974; Wed, 1 Apr 92 00:55:15 -0800 Received: from spot.Colorado.EDU by jessica.stanford.edu (5.59/25-eef) id AA06583; Wed, 1 Apr 92 00:55:12 PDT Received: by spot.Colorado.EDU id AA13332 (5.65c+/IDA-1.4.4/CNS-2.1 for cisco-ml2); Wed, 1 Apr 1992 01:39:46 -0700 Received: from regal.cisco.com by spot.Colorado.EDU with SMTP id AA13187 (5.65c+/IDA-1.4.4/CNS-2.1 for ); Wed, 1 Apr 1992 01:34:53 -0700 Received: by regal.cisco.com; Wed, 1 Apr 92 00:33:02 -0800 Date: Wed, 1 Apr 92 0:33:01 PST From: William "Chops" Westfield To: cisco@spot.colorado.edu Subject: Press release Message-Id: Resent-To: tops-20@simtel20.army.mil Resent-Date: Wed, 1 Apr 92 10:28:28 PST Resent-From: Vince Fuller > > Attached find a press release, which will be > announced today via various sources. > --Bill > ________________________________________________________________________ > > > Company contact: > > > > > > Bill Foonley > > > Cisco Systems, Inc. > > > (415) 092-0401 > > > > > > > > > FOR IMMEDIATE RELEASE > > > > > > > > > CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE > > > "WE'VE ALWAYS USED IT" SAY FOUNDERS > > > > > > MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today announced that they will pay an undisclosed sum of money to Digital Equipment Corporation (DEC) in return for the rights to incorporate software from DEC's "TOPS20" operating system in cisco's market leading routers and communications servers. "TOPS20" was the operating system for DEC's line of 36-bit computers, which were made obsolete in 1983. Cisco officials admitted that cisco routers have used tops20 code since Cisco's founding in 1984, and that Cisco felt they should "come clean" now that are in a sound financial position. Cisco founder Len Bosack, contacted at his new company, XKL Inc, commented: "The same software technology that allowed TOPS20, which ran on a machine capable of one or two MIPS, to support many more users than a modern '30 MIPS' workstation, allowed cisco to switch 12000 packets per second with a 12 MHz 68020, when our competitors were throwing RISC processors with two or three times that clock rate at the problem, and only getting half the end performance." Mr Bosack felt that DEC had abandoned the software,and had no moral qualms about "borrowing" it for a completely different end product. "We knew a large number of 20 hackers, so it seemed a natural thing to do at the time. But cisco is more conservative now, and I guess they are playing it safe [by paying DEC]. I had planned to add an additional 4 bits to the router CPU hardware so that we could make use of even more of the tops20 software, but this was no longer acceptable, which is why I founded XKL." Another of cisco's founders, who asked not to be identified, added that the original cisco router's cooling fan and color scheme were also inspired by DEC's TOPS20 systems. DEC's reaction to cisco's vounteering to pay for TOPS20 was mainly one of surprise. "Once we found someone who knew what they were talking about, even he was surprised that there could still be money involved. Still, times are hard, and money is money, so we aren't complaining." 1-Apr-92 14:07:24-MST,3676;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 Apr 92 14:07:17 MST Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.25 ) id AA03953; Wed, 1 Apr 92 13:06:56 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA01673; Wed, 1 Apr 92 13:06:44 PST Date: Wed, 1 Apr 1992 13:05:24 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: [Alan H. Martin 01-Ap: FWD: TOPS-20, still making money...] To: NDC Technical Staff , TOPS-20 Hackers and Yackers Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I *knew* it!!! ;-) [Boy, they're flying fast and furious this year...] ** Begin Forwarded Message ** Date: Wed, 1 Apr 92 10:51:55 PST From: Alan H. Martin 01-Apr-1992 1351 Subject: FWD: TOPS-20, still making money... To: boken@tle.enet.dec.com, vlr@tle.enet.dec.com, dlm@tle.enet.dec.com, kmp@tle.enet.dec.com, vjb@tle.enet.dec.com, cks@tle.enet.dec.com, tjk@tle.enet.dec.com Subj: FWD: TOPS-20, still making money... Subj: TOPS-20, still making money... Subj: TOPS20 Lives (at Cisco) Company contact: Bill Foonley Cisco Systems, Inc. (415) 092-0401 FOR IMMEDIATE RELEASE CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE "WE'VE ALWAYS USED IT" SAY FOUNDERS MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today announced that they will pay an undisclosed sum of money to Digital Equipment Corporation (DEC) in return for the rights to incorporate software from DEC's "TOPS20" operating system in cisco's market leading routers and communications servers. "TOPS20" was the operating system for DEC's line of 36-bit computers, which were made obsolete in 1983. Cisco officials admitted that cisco routers have used tops20 code since Cisco's founding in 1984, and that Cisco felt they should "come clean" now that are in a sound financial position. Cisco founder Len Bosack, contacted at his new company, XKL Inc, commented: "The same software technology that allowed TOPS20, which ran on a machine capable of one or two MIPS, to support many more users than a modern '30 MIPS' workstation, allowed cisco to switch 12000 packets per second with a 12 MHz 68020, when our competitors were throwing RISC processors with two or three times that clock rate at the problem, and only getting half the end performance." Mr Bosack felt that DEC had abandoned the software,and had no moral qualms about "borrowing" it for a completely different end product. "We knew a large number of 20 hackers, so it seemed a natural thing to do at the time. But cisco is more conservative now, and I guess they are playing it safe [by paying DEC]. I had planned to add an additional 4 bits to the router CPU hardware so that we could make use of even more of the tops20 software, but this was no longer acceptable, which is why I founded XKL." Another of cisco's founders, who asked not to be identified, added that the original cisco router's cooling fan and color scheme were also inspired by DEC's TOPS20 systems. DEC's reaction to cisco's vounteering to pay for TOPS20 was mainly one of surprise. "Once we found someone who knew what they were talking about, even he was surprised that there could still be money involved. Still, times are hard, and money is money, so we aren't complaining." 1-Apr-92 20:16:51-MST,3696;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 1 Apr 92 20:16:35 MST Date: Wed, 1 Apr 92 19:21:54 CST From: Clive Dawson Subject: Cisco Press Release To: tops-20@wsmr-simtel20.army.mil Message-ID: <12770097725.30.AI.CLIVE@MCC.COM> Found floating around on the net FYAmusement... Cheers, Clive ------------------------------------------------------------------ --------------- Return-Path: Received: from spot.Colorado.EDU by MCC.COM with TCP; Wed, 1 Apr 92 03:07:40 CST Received: by spot.Colorado.EDU id AA13236 (5.65c+/IDA-1.4.4/CNS-2.1 for cisco-ml1); Wed, 1 Apr 1992 01:34:57 -0700 Received: from regal.cisco.com by spot.Colorado.EDU with SMTP id AA13187 (5.65c+/IDA-1.4.4/CNS-2.1 for ); Wed, 1 Apr 1992 01:34:53 -0700 Received: by regal.cisco.com; Wed, 1 Apr 92 00:33:02 -0800 Date: Wed, 1 Apr 92 0:33:01 PST From: William "Chops" Westfield To: cisco@spot.colorado.edu Subject: Press release Message-Id: > > Attached find a press release, which will be > announced today via various sources. > --Bill > ________________________________________________________________________ > > > Company contact: > > > > > > Bill Foonley > > > Cisco Systems, Inc. > > > (415) 092-0401 > > > > > > > > > FOR IMMEDIATE RELEASE > > > > > > > > > CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE > > > "WE'VE ALWAYS USED IT" SAY FOUNDERS > > > > > > MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today announced that they will pay an undisclosed sum of money to Digital Equipment Corporation (DEC) in return for the rights to incorporate software from DEC's "TOPS20" operating system in cisco's market leading routers and communications servers. "TOPS20" was the operating system for DEC's line of 36-bit computers, which were made obsolete in 1983. Cisco officials admitted that cisco routers have used tops20 code since Cisco's founding in 1984, and that Cisco felt they should "come clean" now that are in a sound financial position. Cisco founder Len Bosack, contacted at his new company, XKL Inc, commented: "The same software technology that allowed TOPS20, which ran on a machine capable of one or two MIPS, to support many more users than a modern '30 MIPS' workstation, allowed cisco to switch 12000 packets per second with a 12 MHz 68020, when our competitors were throwing RISC processors with two or three times that clock rate at the problem, and only getting half the end performance." Mr Bosack felt that DEC had abandoned the software,and had no moral qualms about "borrowing" it for a completely different end product. "We knew a large number of 20 hackers, so it seemed a natural thing to do at the time. But cisco is more conservative now, and I guess they are playing it safe [by paying DEC]. I had planned to add an additional 4 bits to the router CPU hardware so that we could make use of even more of the tops20 software, but this was no longer acceptable, which is why I founded XKL." Another of cisco's founders, who asked not to be identified, added that the original cisco router's cooling fan and color scheme were also inspired by DEC's TOPS20 systems. DEC's reaction to cisco's vounteering to pay for TOPS20 was mainly one of surprise. "Once we found someone who knew what they were talking about, even he was surprised that there could still be money involved. Still, times are hard, and money is money, so we aren't complaining." ------- 2-Apr-92 12:17:08-MST,646;000000000000 Return-Path: Received: from wsmr-emh08.army.mil by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 Apr 92 12:17:02 MST Date: Thu, 2 Apr 92 12:14:09 MST From: "William D. Johnston ASQNC-TWS-SS" Subject: Re: [Alan H. Martin 01-Ap: FWD: TOPS-20, still making money...] In-Reply-To: Your message of Wed, 1 Apr 1992 13:05:24 -0800 (PST) To: mcrispin@wsmr-simtel20.army.mil Cc: TOPS-20 Hackers and Yackers , EBAAS@wsmr-simtel20.army.mil, RFRENCH@wsmr-simtel20.army.mil, bjohnston@wsmr-emh08.army.mil, bjohnsto@wsmr-emh08.army.mil April Fool(s) 2-Apr-92 12:33:26-MST,1551;000000000000 Return-Path: Received: from andrew.cmu.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 2 Apr 92 12:33:20 MST Received: by andrew.cmu.edu (5.54/3.15) id for TOPS-20@wsmr-simtel20.army.mil; Thu, 2 Apr 92 14:33:00 EST Received: via switchmail; Thu, 2 Apr 1992 14:32:59 -0500 (EST) Received: from pcs5.andrew.cmu.edu via qmail ID ; Thu, 2 Apr 1992 14:31:12 -0500 (EST) Received: from pcs5.andrew.cmu.edu via qmail ID ; Thu, 2 Apr 1992 14:31:05 -0500 (EST) Received: from mms.0.1.873.MacMail.0.9.CUILIB.3.45.SNAP.NOT.LINKED.pcs5.andrew.cmu.edu.pmax.ul4 via MS.5.6.pcs5.andrew.cmu.edu.pmax_ul4; Thu, 2 Apr 1992 14:31:05 -0500 (EST) Message-Id: Date: Thu, 2 Apr 1992 14:31:05 -0500 (EST) From: Pete Bronder To: NDC Technical Staff , TOPS-20 Hackers and Yackers , Data-Communications , Mark Crispin Subject: Re: [Alan H. Martin 01-Ap: FWD: TOPS-20, still making money...] Cc: In-Reply-To: References: I was wondering why the feel of our Cisco backbone console reminded me of Tops-E. Now there was a computer! 6-Apr-92 15:18:47-MDT,815;000000000000 Return-Path: Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Apr 92 15:18:28 MDT Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31); id AA25119; Mon, 6 Apr 92 17:19:01 EDT for TOPS-20@WSMR-SIMTEL20.ARMY.MIL Date: Mon, 6 Apr 92 17:16:46 EDT From: John_Wilson@MTS.RPI.EDU To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL, 20world@FENCHURCH.MIT.EDU Message-Id: <2806795@MTS.RPI.EDU> Subject: CRAM chip Hello, Does anyone have or know where I can get the 93L415 static RAM chips used in the KS10 microstore? DEC & Ham/Av say it's obsolete and unavailable, and JDR claims it's equivalent to the 2102 (250ns), which is clearly false. Either that, or does anyone have an M8622 CRA board that they're willing to let go real cheap? Thanks, John_Wilson@MTS.RPI.EDU 14-Apr-92 08:30:53-MDT,1027;000000000000 Return-Path: Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Apr 92 08:30:47 MDT Date: Tue, 14 Apr 92 10:31 EDT From: JERRY WEINER BBN 617-873-3242 Subject: IPABTO BUGCHKS To: tops-20@wsmr-simtel20.army.mil X-VMS-To: @TOPS Folks, Anyone have any tips on preventing IPABTO Bugchks. We are running the latest TOPS-20 with all DEC's patches on two DEC-20's. DEC recommended reducing NHOSTS to a small number to free up Internet Free space in the monitor. NHOSTS is now 151. on our systems, we set this at about 3 times the number of hosts we found in the table. This reduced the occurances of IPABTO's but we still get them periodically, usually 5-6 minutes apart. The IPABTO's usually have no correlation between the two DEC-20's. They usually do not happen on both DEC-20 at the same times. Sometimes TCP/IP stops working, but can be reactivated by running IPHOST and issing an INTERNET CYCLE Command. Thanx, Jerry Weiner 14-Apr-92 23:43:12-MDT,2358;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Apr 92 23:43:02 MDT Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.25 ) id AA12507; Tue, 14 Apr 92 22:42:51 -0700 Date: Tue, 14 Apr 1992 22:30:35 -0700 (PDT) From: Mark Crispin Sender: Mark Crispin Subject: last living example of WAITS (Foonly CPU) needs a new home To: TOPS-20 Hackers and Yackers , PDP-8 Lovers Cc: Peter Lothberg , Pat Tressel , Hobroken Gang Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Maximum distribution requestion. I have just been informed that the CCRMA Foonly F4, the last functioning example of the WAITS PDP-10 operating system on the planet, has been retired. It was powered down a week ago last Friday. WAITS was the innovative operating system developed at the Stanford AI Laboratory from a very old version of TOPS-10 (back when they called it 10/50) -- the last merges were from 3.54 days. It had a fantastic display environment which has to date remained unequalled by `modern' operating systems. Unless some kind soul interested in rescuing this piece of history speaks up soon, it may end up being taken for scrap, perhaps as soon as Thursday. It was working as of the time it was powered down, although there were known to be some glitches in its TTY and Ethernet interfaces. This machine and its software properly belongs in a museum, but until the world realizes what valuable gems they are allowing to be casually trashed, it is incumbant upon us to save this noble beast. I would volunteer myself, except I'm too busy with my myriad projects (including two 2020's) to give the F4 the loving nuture it so badly needs. It would probably end up in my garage, which would destroy it. The person to contact for more information is Tovar (that's his complete name). He can be reached by e-mail at tvr@CCRMA.STANFORD.EDU or by telephone at +1 (415) 328-0573. 15-Apr-92 01:38:13-MDT,1167;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Apr 92 01:38:09 MDT Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.25 ) id AA25114; Wed, 15 Apr 92 00:38:00 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA05203; Wed, 15 Apr 92 00:37:54 PDT Date: Wed, 15 Apr 1992 00:35:49 -0700 (PDT) From: Mark Crispin Sender: Mark Crispin Subject: re: IPABTO BUGCHKS To: JERRY WEINER BBN 617-873-3242 Cc: tops-20@wsmr-simtel20.army.mil In-Reply-To: <9204150720.AA00773@Tomobiki-Cho.CAC.Washington.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Apr 92 10:31 EDT, JERRY WEINER BBN 617-873-3242 wrote: > Anyone have any tips on preventing IPABTO Bugchks. Yes, I do. Increase NNIPIB from its current definition of ^D40 to ^D120 and rebuild your monitor. DEC evidentally never uses a real Ethernet in the big bad world. 28-Apr-92 06:43:48-MDT,1203;000000000000 Return-Path: Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 28 Apr 92 06:43:42 MDT Date: Tue, 28 Apr 92 08:43 EDT From: JERRY WEINER BBN 617-873-3242 Subject: More TCP/IP Problems (TELNET ^S/^Q) To: mrc@panda.com, tops-20@wsmr-simtel20.army.mil X-VMS-To: IN%"mrc@panda.com",@TOPS Folks, Thanx to Mark Crispin for the tip to increase NNIPIB to prevent IPABTO bugchks. This has reduced the number of occurances, but not eliminated them. I have thought about increasing it again. Any thoughts Mark? The new problem for me. I sure this one been around a long time. When someone TELNETs to the TOPS system from a DOS PC, a MAC, a VMS system, or an IP terminal server (Annex or XYPLEX) repeated control S/Q's will cause the the terminal session to hang. The session must then be terminated from the source or Logged out on the DEC-20. Also typing a large file is significantly slower than either a Front End line a a a Lat Terminal line. Anyone have experience with this one? Any help will be appreciated. We are running the latested DEC supplied S/W with all released patches. Thanx, Jerry Weiner. 29-Apr-92 07:25:30-MDT,2673;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 29 Apr 92 07:25:25 MDT Received: by sandpiper.wesleyan.edu (5.61/1.35) id AA02033; Wed, 29 Apr 92 09:24:59 -0400 Date: Wed, 29 Apr 92 09:24:59 -0400 Message-Id: <9204291324.AA02033@sandpiper.wesleyan.edu> From: Douglas Bigelow To: JWEINER@ccr2.bbn.com Cc: tops-20@wsmr-simtel20.army.mil In-Reply-To: JERRY WEINER BBN 617-873-3242's message of Tue, 28 Apr 92 08:43 EDT Subject: More TCP/IP Problems (TELNET ^S/^Q) >> The new problem for me. I sure this one been around a long time. When >> someone TELNETs to the TOPS system from a DOS PC, a MAC, a VMS system, or an >> IP terminal server (Annex or XYPLEX) repeated control S/Q's will cause the >> the terminal session to hang. The session must then be terminated from the >> source or Logged out on the DEC-20. Also typing a large file is significantly >> slower than either a Front End line a a a Lat Terminal line. Anyone have >> experience with this one? Yup, it sounds like the problems I was having when I first started using Xyplex and Datability terminal servers connecting to my 2060. There were two problems: one was that the 20 wasn't putting the URGENT flag on in a TELNET SYNC packet, and the server was treating a data mark like an ordinary character. The second (and worse) problem was that TELNET IP functions were getting handled badly, causing the sort of hangs that you've been seeing. The large file typing problem may be related to a packet reassembly problem which I also encountered. I'll send you the specifics on these three cases separately, rather than to the list. You've seen some of the background before, since I was asking for help on this list within the last year, and received quite a bit. Your problem flavors may well be different, but I'll give you everything I have. In general, after many, many hours with a network analyzer between our 20 and some of our lower-budget terminal servers, I've decided that the problem is basically that the servers don't have a robust protocol implementation. They're fine when interacting with hosts based on standard BSD Unix-style IP, but the 20 does things a little bit differently in several areas of Telnet handling. Those little differences uncover large bugs in some of the servers. I've also seen it when interacting between the 20 and several PC or Macintosh TELNET programs. I'm sure nobody will find this surprising, but I've never encountered any problem communicating between a DEC-20 and a cisco server... Doug 29-Apr-92 12:23:53-MDT,1669;000000000000 Mail-From: MRC created at 29-Apr-92 12:23:50 Date: Wed, 29 Apr 92 12:23:50 MDT From: Mark Crispin Subject: INTFR1 crashes To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Address: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098 Phone: (206) 842-2385 Message-ID: <12777361652.14.MRC@WSMR-SIMTEL20.ARMY.MIL> For the past few years, and intensively for several months now, I have been chasing after a very annoying INTFR1 system crash bug on SIMTEL20. In every case, the syndrome has been the same. The block address is always of the form 12,,xxx177 and the crash is caused by the block header word (and by all appearances no other word) being overwritten by TCP data octets. Often, but not always, the octets are obvious ASCII (the last crash was `secu'). The most popular block addresses are 12,,157177 and 12,,320177 but I've seen other values of xxx including 402 and 664. Has anyone else been seeing these crashes? Of course, we don't see them on a vanilla DEC monitor but the environment there is so different (no viable DNS resolution, etc.) that it doesn't necessarily point to a local change. It could be a bug in special queues (used by our DNS resolver) for example. It's gotten to the point where I am sorely tempted to write workaround code (instead of crashing, hunt for the block trailer and re-create the header after a bugchk) just to stop the crashes and frustrated users, but I really would like to fix this bug and I'm sure if I wrote a workaround it would be out of sight, out of mind... There must be something significant about the 177 part of the address but I am missing it. ------- 29-Apr-92 19:13:46-MDT,6369;000000000000 Return-Path: Received: from tymix.Tymnet.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 29 Apr 92 19:13:27 MDT Received: from tardis.tymnet.com by tymix.Tymnet.COM (4.1/SMI-4.1) id AA29804; Wed, 29 Apr 92 18:13:05 PDT Received: from romana.tymnet.com by tardis.tymnet.com (4.1/SMI-4.1) id AA20593; Wed, 29 Apr 92 18:12:58 PDT Date: Wed, 29 Apr 92 18:12:58 PDT From: jms@tardis.Tymnet.COM (Joe Smith) Message-Id: <9204300112.AA20593@tardis.tymnet.com> To: tops20@tardis.Tymnet.COM, tops20@wsmr-simtel20.army.mil Subject: SWITCH.INI in rec.humor.oracle.d Path: tardis!olivea!uunet!cs.utexas.edu!asuvax!ukma!morgan From: morgan@ms.uky.edu (Wes Morgan) Newsgroups: rec.humor.oracle.d Subject: Not really a sore loser post, but an unpublished answer..... Keywords: compunerdy techie Message-ID: <1992Apr23.82415.18518@ms.uky.edu> Date: 23 Apr 92 12:24:15 GMT Organization: University Of Kentucky, Dept. of Math Sciences Lines: 101 I submitted this answer over 6 weeks ago. For those of you with short memories, this occurred during the "oracle answers are always full of obscure computer geek stuff!" discussion. I guess that a compunerdy answer to a compunerdy question was doomed for the bit bucket; of course, I might have also missed the deadline. 8) Anyway, I haven't seen this question in the Digest, so here's my answer: ---------------------------------------------------------------------------- >> Oh wise and wonderful, wild and wooly Oracle, who not only knows how to >> tune a fish, but also has the best recipe for tuna guitar, please tell >> me this: The Oracle is NOT a fan of REO Speedwagon. Dwort-52 and the Sarefig Bartoxons, yes, but NOT Earthly MOR. >> Why do they keep patching new features into the stupid thing? Can't >> they see that it's about to break? Of course they do! Can't you understand....oh, that's right, you can't; that's why you asked me. You, my young friend, are part of the most grandiose, farthest-reaching experiments in this planet's history of pschyocompunalysis -- The Great User Boiling Point Search. It started with a trivial thing, which most compusavvy individuals remem- ber as the "switch". "LOGIN" became "LOGIN /ACCOUNT:"string" /NEW /NOSCAN /ASSIGN:dev1,log1 /CORE:nx /DEFER", and the users were amazed at the new flexibility. Over the years, leading pschocompunalysts realized that there must be a finite point at which the users are actually overwhelmed by the sheer number and variety (and near-infinite permutations of) the switches. These intrepid mindwalkers endeavored to determine that point. They infiltrated design teams and software developers; "ls" became, instead of the somewhat legible "ls /ALL /SORT /FOO", the monstrosity known to today's users as "ls -abcCdfFgilLmnopqrRstux". The users were enraged, then confused, then reduced to blithering, manual-wandering fools; the compunalysts were pleased. However, these dedicated researchers failed to anticipate the nonnegligible mindpower of the common user. The users *adapted*; they defined macros, they bound keys to the most obnoxious commands, and they wrote their own command interpreters. These users were quickly rising to the leading edge of Userhood; some were even on the threshhold of Gurudom, where they would undoubtedly discover the Experiment. This could not be allowed. The compunalysts realized that something incredible had to be done. After long sessions with trained chimps and high-school cheerleaders (with an occasional shot from a randomizer), they created what they hoped would be the ultimate gauge of the User Boiling Point: -rwsr-xr-x 3 root bin 182418 Apr 26 1989 /usr/lib/sendmail Yes, this would surely lead them to the Boiling Point they so desperately sought. Simple concepts like "Joe User " were converted into tokens such as "Dq$?x$x <$g>$|$g$.". The masses were once more thrown into pandemonium; those who had been approaching Guruhood were sent screaming into the maw of the Ruleset. Temperatures rose, and the compunalysts eagerly awaited the thunderous sound of mental boil. BUT...... Their masterstroke was defeated. Users developed tools to recover the original concepts from the painstakingly derived conundrums of sendmail. "Ease" became widespread, and there were calls for the heads of those who had developed the Sendmail. Most of the compunalysts fled into the digital secrecy of public access sites and university guest logins. Those who did not escape were hunted down and killed (ironically, most died from massive paper tape cuts; a few were found with strange, rectangluar holes punched in linear patterns on their extremities). A few survived. Realizing that their last experiment had almost exhausted the users' mindspace, they knew that the answer was close at hand. They went under "deep cover", assuming innocent jobs in computing centers around the world. They release public domain code that is just obscure enough to confuse the would-be user. They write manuals that are more complicated than the systems covered by their pages. They man support lines, quoting obscure bug references. Their code depends on the value of NULL. They have given up their goal of global confusion; they now believe that, if even one user can reach the Boiling Point, their mission will be fulfilled. Don't give up to them! As soon as you do, they will have you! The first time you write a declaration like "char (*(*(*(*(*x)[5])())[])())[3]", you have joined their ranks! Don't even write programs in any language but BASIC; not BASIC-PLUS-2 with "A$ = SYS(CHR$(6%) + CHR$(7%))", but BASIC! The only way to avoid possession is to intentionally retard the development of your mind! Don't use options; parse things yourself! It's all in your mind.....it's all in your mind.......it's all in your mind. You owe the Oracle the TOPS-10 Monitor Calls Manual set. -- morgan@ms.uky.edu |Wes Morgan, not speaking for| ....!ukma!ukecc!morgan morgan@engr.uky.edu |the University of Kentucky's| morgan%engr.uky.edu@UKCC morgan@ie.pa.uky.edu |Engineering Computing Center| morgan@wuarchive.wustl.edu "I was going to rip your head off, but I'm past that now." 30-May-92 12:34:12-MDT,2324;000000000000 Mail-From: WANCHO created at 30-May-92 12:34:07 Date: Sat, 30 May 1992 12:34 MDT Message-ID: From: "Frank J. Wancho" To: INFO-TMODEM@WSMR-SIMTEL20.ARMY.MIL cc: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Subject: New version of TMODEM The original TMODEM program was written to perform "xmodem" and line-at-a-time (blind) file transfers with the controlling terminal, either directly connected or through a TAC port. It also provided for terminal-controlled transfers through locally connected dialout TTY ports, just like a PC modem program. Now, finally, after four years, the TMODEM program has been updated! It now has the additional capability to connect via telnet to dialout ports connected to terminal servers for terminal-controlled file transfers. TMODEM also has numerous cosmetic changes, including a reformat of the source to standard DEC coding style, and a couple of functional changes, such as a TELNET debug mode and the ability to change the speed of a local TTY port while connected to it. My thanks again to Mark Crispin for again allowing me to lift major sections of his TELNET sources to adapt into the TMODEM program. PD8:TMODEM.MAC.500 is available via anonymous ftp from this host. If you are actually using TMODEM, send me a message. To be added to or removed from the INFO-TMODEM mailing list, send your request to INFO-TMODEM-REQUEST@WSMR-SIMTEL20.ARMY.MIL. Note for users of TMODEM, the ZMODEM family, such as RZ/SZ, and KERMIT through a terminal server dialin port: edit SYSTEM:HOSTS.TXT to explicitly include a line declaring that terminal server to be a TAC in the following format: HOST : host-ip-address : FQDN-of-host : M68020 : TAC : TCP/TELNET : This properly triggers the code in the above programs to negotiate the required network binary mode for efficient file transfers. For users of RZ and SZ on a TAC or terminal server, use the commands: SZ -kw 4096 filespec from the host to the PC sz -kw4096 filespec from the PC to the host This causes the receiving program to send ACKs every 1024 bytes to reduce the overrun problems with certain modems, such as the USR Courier HST, which cannot turnaround fast enough. --Frank 31-May-92 15:46:02-MDT,2712;000000000000 Mail-From: WANCHO created at 31-May-92 15:46:00 Return-Path: Received: from lysator.liu.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 31 May 92 15:43:38 MDT Received: from robin.lysator.liu.se by lysator.liu.se with SMTP (5.65c8/1.34/Lysator-3.1) id AA10744; Sun, 31 May 1992 23:43:13 +0200 (rfc931-sender: pen@robin.lysator.liu.se) Received: by robin.lysator.liu.se (5.65c8/1.34/Lysator-3.1) id AA13080; Sun, 31 May 1992 23:42:46 +0200 (rfc931-sender: pen@robin.lysator.liu.se) Date: Sun, 31 May 92 23:42:42 MET DST From: Peter Eriksson To: rfc931-users@kramden.acf.nyu.edu Cc: andersa@docs.uu.se Cc: action@wsmr-simtel20.army.mil Subject: Announcing: An Ident server for TOPS-20! Message-Id: ReSent-Date: Sun, 31 May 92 15:46:00 MDT ReSent-From: "Frank J. Wancho" ReSent-To: TOPS20@WSMR-SIMTEL20.ARMY.MIL ReSent-Message-ID: <12785787061.17.WANCHO@WSMR-SIMTEL20.ARMY.MIL> This message is to announce the availability of an implementation of the Identification Server Protocol for DECsystem-20 mainframes running the TOPS-20 operating system. The source code, written in MACRO-10, is available for anonymous FTP from "ftp.lysator.liu.se" in the directory "pub/ident/TOPS-20" as the file "IDENTD.MAC". The author, Anders Andersson, can be reached at the mailing address: "Anders.Andersson@docs.uu.se". Below follows a small introduction to what the Ident protocol is, which you may skip if you are already familiar with it. Please redistribute this message to any TOPS-20 users who may be interrested in it. The Identification Server Protocol is based on the RFC931 protocol (Authentication Server Protocol) and will soon (hopefully) be released as a new RFC replacing RFC931. The Identification Server Protocol implements a way for a host to announce the owner of a TCP/IP connection to the foreign host. This can, for example, be used for logging incoming connections. For more information, please read RFC931 and/or send email to the "rfc931-users@kramden.acf.nyu.edu" mailing list that discusses implementation and usage of this protocol. (There are a number of changes compared to the RFC931 protocol). There is a mailing list "ident@nri.reston.va.us" that discusses the definition of the new protocol. /Peter Eriksson Peter Eriksson pen@lysator.liu.se Lysator Academic Computer Society ...!uunet!lysator.liu.se!pen University of Linkoping, Sweden I'm bored. Flame me. 14-Jun-92 19:09:03-MDT,876;000000000000 Return-Path: Received: from fernwood.mpk.ca.us by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 14 Jun 92 19:08:57 MDT Received: by fernwood.mpk.ca.us; id AA21303; Sun, 14 Jun 92 18:10:59 -0700 Message-Id: <9206150110.AA21303@fernwood.mpk.ca.us> To: tops-20@wsmr-simtel20.army.mil, its-lovers@mc.lcs.mit.edu Subject: California JFCL available. Date: Sun, 14 Jun 92 18:10:55 MST From: the terminal of Geoff Goodfellow California license plate JFCL is available due to an accident that resulted in my car being declared a total loss by the insurance underwriter. JFCL was such useful instruction to use while hacking stuff with DDT and whereas I haven't done any PDP10 hacking in years (in fact the last DEC20 I had an account on was retired last year), I've decided to use the occasion to turn JFCL in. Geoff 16-Jun-92 08:42:22-MDT,695;000000000000 Return-Path: Received: from ginger.lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 16 Jun 92 08:42:18 MDT Received: by ginger.lcs.mit.edu id AA28020; Tue, 16 Jun 92 10:41:14 -0400 Date: Tue, 16 Jun 92 10:41:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206161441.AA28020@ginger.lcs.mit.edu> To: geoff@fernwood.mpk.ca.us, its-lovers@mc.lcs.mit.edu, tops-20@wsmr-simtel20.army.mil Subject: Re: California JFCL available. Cc: jnc@ginger.lcs.mit.edu Speaking of PDP-10ish license plates, does HIC still have HLRZ? When I figured out that this was the CAR instruction, I nearly fell down I was laughing so hard. Noel 17-Jun-92 08:07:36-MDT,1993;000000000000 Return-Path: Received: from life.ai.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 17 Jun 92 08:05:52 MDT Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA11125; Wed, 17 Jun 92 10:01:37 EDT From: pgs@ai.mit.edu (Patrick Sobalvarro) Received: by rice-chex (4.1/AI-4.10) id AA11056; Wed, 17 Jun 92 10:01:35 EDT Date: Wed, 17 Jun 92 10:01:35 EDT Message-Id: <9206171401.AA11056@rice-chex> To: Noel Chiappa Cc: moon@cambridge.apple.com, geoff@fernwood.mpk.ca.us, its-lovers@mc.lcs.mit.edu, tops-20@wsmr-simtel20.army.mil In-Reply-To: "David A. Moon"'s message of Tue, 16 Jun 92 13:57:06 EDT <9206161746.AA16737@cambridge.apple.com> Subject: [Noel Chiappa : Re: California JFCL available.] Well, I got HLRZ the car from Howard in 1984 or 1985, but he wanted the plate (the physob, that is) back and I gave it to him. He continued to refer to the car as HLRZ on the few occasions I've run into him since then ("Wow, that must have been HLRZ I saw parked outside. That thing's still running?!"). HLRZ the car required some mechanical work when I first got it, because of the long time it had spent parked under a tree in Glenn's driveway, but then it pretty much just ran like a clock for about eight years, across the country to Palo Alto and back here, couple of trips to Pittsburgh, used in daily commuting, and finally we sold it about two months ago to someone at Cayman for $200. It was beginning to require new parts regularly. I think HLRZ the plate (logical) is probably available in Massachusetts. But you know, no matter what kind of new car you attach it to, it'd just never be the same. There are some things PDP-10's and slant-six Dodges have in common: both were pretty neat things; they're gone now; and we can sort of play around with a few old ones but really the time for them is gone, too, and it isn't coming back. -P. 17-Jun-92 15:07:07-MDT,1609;000000000000 Mail-From: PANDA created at 17-Jun-92 15:05:24 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Wed, 17 Jun 92 15:05:27 MDT Date: Wed, 17 Jun 92 12:58:52 PDT From: Mark Crispin Subject: PDP-10's are still around... To: ITS-lovers@MC.LCS.MIT.EDU, TOPS-20@WSMR-SIMTEL20.Army.MIL Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098 Phone: +1 (206) 842-2385 Message-ID: <12790224006.7.MRC@YUUYUU.Panda.COM> It's been asserted that modulo `a few old ones' that you can `play around with', PDP-10's are gone. Although there's some truth to this statement, it hasn't gotten quite that bad yet. CompuServe is very dependent upon PDP-10's. I believe the entire system is written in MACRO. Their machines may be increasingly Systems Concepts instead of DEC machines, but PDP-10's are PDP-10's no matter who makes them. XKL Systems is working on a desktop PDP-10. I don't know how far along they are on this project (Len, care to comment??). WSMR-SIMTEL20.ARMY.MIL is still very much alive and servicing FTP requests from around the world. I'm sending this message from Yuuyuu, KS10 serial number 4664. Although the main Panda.COM machine is now a NeXT (Ikkoku-Kan) Yuuyuu is still alive. There is a guest account if you want to browse -- (206) 842-0759, 2400 baud, user GUEST, password FEIFEI. Eventually, I hope to get Yuuyuu talking TCP (my sources have been offline for a year so that project is stalled).  -- Mark (`you can hack anything you want with TECO and DDT') -- ------- 18-Jun-92 07:43:56-MDT,1319;000000000000 Return-Path: Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 18 Jun 92 07:43:50 MDT Received: by enet-gw.pa.dec.com; id AA03774; Thu, 18 Jun 92 06:43:45 -0700 Message-Id: <9206181343.AA03774@enet-gw.pa.dec.com> Received: from narfvx.enet; by decwrl.enet; Thu, 18 Jun 92 06:43:46 PDT Date: Thu, 18 Jun 92 06:43:46 PDT From: History shows that the Red Sox always win the World Series in the year after a Russian revolution. 18-Jun-1992 0943 To: tops20@wsmr-simtel20.army.mil Apparently-To: tops20@wsmr-simtel20.army.mil Subject: RE: [Noel Chiappa : Re: California JFCL] >I think HLRZ the plate (logical) is probably available in >Massachusetts. But you know, no matter what kind of new car you >attach it to, it'd just never be the same. There are some things >PDP-10's and slant-six Dodges have in common: both were pretty neat >things; they're gone now; and we can sort of play around with a few >old ones but really the time for them is gone, too, and it isn't >coming back. NOT TRUE!!!! (AT least about the Slant-6). You can STILL get it for certain models of Dodge full size vans (and I think pickups!) So that venerable engine is still alive and well... John 18-Jun-92 21:26:12-MDT,1012;000000000000 Mail-From: PANDA created at 18-Jun-92 21:25:06 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Thu, 18 Jun 92 21:25:08 MDT Date: Thu, 18 Jun 92 15:34:21 PDT From: Mark Crispin Subject: PDP-10's still live at the University of Washington To: TOPS-20@WSMR-SIMTEL20.Army.MIL, ITS-LOVERS@MC.LCS.MIT.EDU Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098 Phone: +1 (206) 842-2385 Message-ID: <12790514457.9.MRC@YUUYUU.Panda.COM> The Locke Computer Center retired its KL-1090 TOPS-10 system, but all was not totally lost. Thanks to some heroic efforts on the part of their resident PDP-10 lovers, notably Bruce Edwards and Patricia Tressel, a KS system (serial number 4364) is now happily churning TOPS-10 cycles to replace it. Has anyone put together a list of what systems are still alive in the world? I think, for example, that PDP-10's are now extinct at Stanford and CMU. How about MIT? ------- 19-Jun-92 07:20:39-MDT,1421;000000000000 Return-Path: Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 07:20:34 MDT Received: by enet-gw.pa.dec.com; id AA14639; Fri, 19 Jun 92 06:20:27 -0700 Message-Id: <9206191320.AA14639@enet-gw.pa.dec.com> Received: from narfvx.enet; by decwrl.enet; Fri, 19 Jun 92 06:20:29 PDT Date: Fri, 19 Jun 92 06:20:29 PDT From: History shows that the Red Sox always win the World Series in the year after a Russian revolution. 19-Jun-1992 0911 To: tops-20@wsmr-simtel20.army.mil Apparently-To: tops-20@wsmr-simtel20.army.mil Subject: At least TWO PDP-10s still alive at DEC Marlboro... Even though the developers who worked on TOPS-10/TOPS-20 are gone to the four winds, at least two systems still flourish at Digital Marlboro: GIDNEY, a KL-2065, and KL1026, a KL1090. Both are used for many things -- on-line repositories for Monitor and utility sources being near the top. I haven't been in Marlboro in a few years; I don't know if there's any impending decommission date for either system. At this moment, at least, they still live. Oh yes, GIDNEY is still an Internet system (since I get this list from it instead of the usual Internet mail gateways around the corporation...) I also believe that our Colorado Springs support center still runs at least one KL for support purposes. John Francini 19-Jun-92 07:37:46-MDT,1410;000000000000 Return-Path: Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 07:37:38 MDT Received: by FENCHURCH.MIT.EDU id AA23173; Fri, 19 Jun 92 07:53:04 -0400 Reply-To: shawn@FENCHURCH.MIT.EDU Date: Fri, 19 Jun 92 7:53:02 EDT From: "Shawn F. Mckay" To: TOPS20-REQUEST@wsmr-simtel20.army.mil Cc: TOPS-20@wsmr-simtel20.army.mil, ITS-LOVERS@mc.lcs.mit.edu, admin-dt@FENCHURCH.MIT.EDU, mory@FENCHURCH.MIT.EDU Subject: Re: PDP-10's still live at the University of Washington In-Reply-To: Your message of Thu, 18 Jun 92 15:34:21 PDT Message-Id: MIT Deep thought (A Decsystem-20/65) is still "safe" here, though efforts to revive it are still under way (Previously a very low priority hobby project, its now getting some cycles). In fact 3 out of 4 rp06 drives are spinning, and I suspect only 2 real problems remain: o Still cant find page 0 memory, even after Joe Dempster and I swapped out all the memory boards. o Cant find the data on the RP06 drives (Starting to look like a trivial datapath problem). Anyway, I am about to formulate a real request to folks for wisdom, but these are what I am crunching to get it "running". It could REALLY use a RH20->SCSI controller though :-) -- Shawn Mckay, System Manager, MIT-Deep-Thought 19-Jun-92 14:10:42-MDT,7916;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 14:10:25 MDT Date: Fri, 19 Jun 92 15:06:36 CDT From: Clive Dawson Subject: Survey of DEC-10/20's still in use. To: tops-20@wsmr-simtel20.army.mil Message-ID: <12790749703.40.AI.CLIVE@MCC.COM> Folks, Some months back I offered to compile a list of the DEC-10 and DEC-20 systems which are still in use. Mark's recent message reminded me that I had never posted the results. What follows is the info I have obtained to date. It is obviously incomplete, so I am willing to update and correct this list if people will send me data about additional systems out there. Thanks to all who responded. Clive =============================================================================== BBN System: DEC-2065's (2, clustered) OS: TOPS-20 Version 7(21733) Organization: BBN Inc. Location: Cambridge, MA 02138 Use: Business processing Hostname: Wishes to remain anonymous Shutdown date: At least one of the 20's will be here thru the end of calendar 1993. There is talk about an earlier shutdown of other system. Contact: Jerry Weiner 617-873-3242 JWEINER@BBN.COM =============================================================================== BT TYMNET System: DEC-1090 OS: TYMCOM-X P035/E01 (TOPS-10 variant) Organization: BT North America, TYMNET Operations Location: Fremont, California Use: Business Contact: Carl Baltrunas, 408/922-6206 Hostname and shutdown date: (MX only, these have no IP addresses) F23.Tymnet.COM - F26.Tymnet.COM Summer 1992 F30.Tymnet.COM - F33.Tymnet.COM Fall 1992 F34.Tymnet.COM - F37.Tymnet.COM 1-Jul-91 F38.Tymnet.COM - F56.Tymnet.COM 30-Sep-91 F74.Tymnet.COM - (MAIL host) ----------------------------------------------------------------------- System: DEC-2020 OS: TYMCOM-X P035/E01 (TOPS-10 variant) Organization: BT North America, TYMNET Operations Location: San Jose, California Use: Business Contact: Joe Smith, 408/922-6220 Hostname and shutdown date: (MX only, these have no IP addresses) X14.Tymnet.COM - X17.Tymnet.COM - =============================================================================== CISCO System: DEC-2065 OS: TOPS-20 6.1 (Stanford) Organization: cisco Location: Menlo Park, CA Use: BillW reads his mail, SUDS Hostname: Mathom.cisco.com Shutdown date: soon Contact: eldredge@cisco.com ----------------------------------------------------------------------- System: DEC-2065 OS: TOPS-20 6.1 (Stanford) Organization: cisco Location: Menlo Park, CA Use: Part of cisco customer database Hostname Heap.cisco.com Shutdown date: Soon Contact: JimL@cisco.com =============================================================================== CUA System: KL10B (model D) OS: TOPS-10 v7.02 (Auto Patch 11) Organization: Catholic University of America Location: Washington, D.C. Use: University administration Hostname: CUA (1) [ANF10 only] Shutdown date: 12/92 (expected) Contact: Edward C. Mulrean (mulrean@cuavax.dnet.cua.edu) =============================================================================== Mark Crispin System: DEC-2020 (1 operational, 1 standby, 1 spare) OS: TOPS-20 5.5 Organization: Mark Crispin Location: Bainbridge Island, Washington Primary use: Software development Hostname: Yuuyuu.Panda.COM, Tonton.Panda.COM Shutdown date: none Contact: Mark Crispin 208-842-2385 =============================================================================== MCC System: DEC-2065 OS: TOPS-20 5.4/6.0 Organization: Microelectronics and Computer Technology Corp. Location: Austin, Texas Use: Research Hostname: MCC.COM Shutdown date: July, 1992 Contact: Clive Dawson Clive@MCC.COM 512-338-3430 =============================================================================== OAK RIDGE System: Five Processor DEC-10 (KL10-DA's) OS: TOPS-10 V7.03 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: IS Hostname: No external hostname Shutdown Date: 1993 Contact: Wishes to remain anonymous ----------------------------------------------------------------------- System: Single Processor DEC-10 (KL10-EA) OS: TOPS-10 V7.03 Organization: Business Systems Location: Oak Ridge, TN Primary use: MIS Hostname: No external hostname Shutdown Date: 1993 Contact: Wishes to remain anonymous ----------------------------------------------------------------------- System: DEC-2060 OS: TOPS-20 V7.0 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No external hostname Shutdown Date: No specific time schedule but applications are being converted to other platforms. Contact: Wishes to remain anonymous ----------------------------------------------------------------------- System: DEC-2065 (not clustered, but have disks dual ported with system below) OS: TOPS-20 V6.1 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No external hostname Shutdown Date: July, 1993 Contact: Wishes to remain anonymous ----------------------------------------------------------------------- System: DEC-2065 (not clustered, but have disks dual ported with system above) OS: TOPS-20 V6.1 Organization: Computing & Telecommunications Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No external hostname Shutdown Date: July, 1993 Contact: Wishes to remain anonymous ----------------------------------------------------------------------- System: DEC-2065 OS: TOPS-20 V6.1 Organization: Procurement Division Location: Oak Ridge, Tn Primary use: MIS Hostname: No External hostname Shutdown Date: 1993 Contact: Jeff Jones =============================================================================== SRI System: DEC-2065 OS: Tops-20 v7 Org: SRI Loc: Menlo Park, CA Use: Hacking Hostname: nic.nisc.sri.com Shutdown date: probably soon Contact: Mark Lottor 415 859-2652 =============================================================================== TRW System: DEC-2020 OS: TYMCOM-X P035/C01 (TOPS-10 variant) Organization: TRW Network Services Location: Anaheim, California Use: Business Hostname: S33 Shutdown date: Summer 1992 =============================================================================== US Army System: DEC-2065 w/4MW + NIA-20 + 12 RP07s OS: TOPS-20 7.0 with Panda mods Organization: USAISC-White Sands Location: WSMR, NM Use: EMail services, mailing list redistribution, and several very large repositories of software and docs. Hostname: WSMR-SIMTEL20.ARMY.MIL Shutdown date: None Contact: Terri Jackson, 505-678-7462 Tech. Support: Frank J. Wancho, 505-678-9124 =============================================================================== UNIV. OF PITTSBURGH System: DEC-1090 OS: TOPS-10 Organization: Computing and Information Services Location: University of Pittsburgh Use Education (Administrative use) Hostname: none Shutdown date: Spring/Summer, 1992 Contact: Richard Loether (412 624-6429, rjl@vms.cis.pitt.edu) =============================================================================== WESLEYAN UNIVERSITY System: DEC-2065 OS: TOPS-20 V. 5.4/6.0 Organization: Wesleyan University Location: Middletown, CT Primary use: University administration Hostname: KLB.Wesleyan.Edu Shutdown date: December 1993 (approx.) Contact: Doug Bigelow (DBigelow@Sandpiper.Wesleyan.Edu) =============================================================================== ------- 19-Jun-92 20:01:20-MDT,3798;000000000000 Mail-From: PANDA created at 19-Jun-92 19:58:41 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Fri, 19 Jun 92 19:58:42 MDT Return-Path: <@WSMR-SIMTEL20.ARMY.MIL:pat+@transarc.com> Received: from WSMR-SIMTEL20.Army.MIL by YUUYUU.Panda.COM with Cafard; Fri, 19 Jun 92 08:31:04 PDT Received: from transarc.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 07:23:42 MDT Received: by transarc.com (5.54/3.15) id for MRC@yuuyuu.panda.com; Fri, 19 Jun 92 09:23:29 EDT Received: via switchmail; Fri, 19 Jun 1992 09:23:26 -0400 (EDT) Received: from kermit.transarc.com via qmail ID ; Fri, 19 Jun 92 09:22:16 -0400 (EDT) Received: from kermit.transarc.com via qmail ID ; Fri, 19 Jun 1992 09:22:00 -0400 (EDT) Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.kermit.transarc.com.rt.r3 via MS.5.6.kermit.transarc.com.rt_r3; Fri, 19 Jun 1992 09:21:59 -0400 (EDT) Message-Id: Date: Fri, 19 Jun 1992 09:21:59 -0400 (EDT) From: Pat_Barron@transarc.com To: Mark Crispin Subject: Re: PDP-10's still live at the University of Washington In-Reply-To: <12790514457.9.MRC@YUUYUU.Panda.COM> References: <12790514457.9.MRC@YUUYUU.Panda.COM> ReSent-Date: Fri, 19 Jun 92 18:31:13 PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@WSMR-SIMTEL20.Army.MIL, ITS-LOVERS@MC.LCS.MIT.EDU ReSent-Message-ID: <12790808797.7.MRC@YUUYUU.Panda.COM> Mark Crispin writes: > I think, for example, that PDP-10's are now extinct at Stanford and CMU. How > about MIT? You're right about CMU. CMU-CS-A (a KL10-A running TOPS-10) went away in 1987, I think. CMU-CS-C (a 2060 or 2065 - I don't remember) followed shortly thereafter, some time in 1988. At around the same time, the six 2060's at the Computation Center were being phased out; by late 1988, all but one of them was gone. The last remaining system was used by the Administrative Systems department to run payroll and stuff, and they continued to use it until some time in 1989, when all admininstrative functions were moved off to a VMS VAXCluster; at that time, the last TOPS-20 machine was shut down. The machines themselves may still be over at the CMU Computation Center for all I know. I believe CMU-CS-A (at least, those parts of it that haven't been picked over by scavengers and souvenir hunters) is still over in the CS department, sitting in the hallway outside the CS machine room; since it was bought with ARPA money, they were not sure if they could sell it off, or even scrap it. So there it sits. For a while, I had talked about getting a KS10 running; I was going to buy the machine myself (assuming I could find one), and donate it to the CMU Computer Club. Someone in the Psychology department had promised us machine room space, and we didn't think getting some kind of Massbus disk and tape would be much of a problem. Unfortunately, just when it looked like I had a machine lined up, we found out that the person who promised us the machine room space didn't actually have the authority to do so, and the computing facilities manager in Psychology expressed some amount of reluctance about putting the machine in their machine room (I believe "over my dead body" was the phrase she used...). So we had to let the idea drop. Sigh.... As for other places, there are persistent rumors that CWRU has one or more KS10s sitting around somewhere, not being used for anything. Beyond that, I can't think of any. --Pat. 19-Jun-92 20:05:31-MDT,1041;000000000000 Mail-From: PANDA created at 19-Jun-92 20:02:44 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Fri, 19 Jun 92 20:02:45 MDT Return-Path: <@WSMR-SIMTEL20.ARMY.MIL:JWEINER@ccr2.bbn.com> Received: from WSMR-SIMTEL20.Army.MIL by YUUYUU.Panda.COM with Cafard; Fri, 19 Jun 92 08:33:15 PDT Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun 92 08:41:45 MDT Date: Fri, 19 Jun 92 10:43 EDT From: JERRY WEINER BBN 617-873-3242 Subject: RE: PDP-10's still live at the University of Washington To: MRC@YUUYUU.Panda.COM X-VMS-To: IN%"MRC@YUUYUU.Panda.COM" ReSent-Date: Fri, 19 Jun 92 18:31:54 PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@WSMR-SIMTEL20.Army.MIL, ITS-LOVERS@MC.LCS.MIT.EDU ReSent-Message-ID: <12790808923.7.MRC@YUUYUU.Panda.COM> Folks, We has BBN, still have two DECsystem 2065's in a cluster running. It looks like they will be here atleast through the end of 1993. Jerry Weiner 20-Jun-92 03:15:40-MDT,1673;000000000000 Mail-From: PANDA created at 20-Jun-92 03:15:03 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Sat, 20 Jun 92 03:15:03 MDT Date: Fri, 19 Jun 92 18:55:33 PDT From: Mark Crispin Subject: a true blast from the past!! Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098 Phone: +1 (206) 842-2385 Message-ID: <12790813226.7.MRC@YUUYUU.Panda.COM> ReSent-Date: Sat, 20 Jun 92 02:10:57 PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@WSMR-SIMTEL20.Army.MIL ReSent-Message-ID: <12790892489.7.MRC@YUUYUU.Panda.COM> Well, my VT100 (with advanced video, katakana ROM, and VT125 upgrade) finally bit the dust. Actually, it isn't truly dead; it's just that it's lost its horizontal width setting so that the image it draws on the screen is a good deal wider than the screen itself (= it overscans). Unfortunately, I could not find any horizontal width pot although there are pots for vertical width. I suspect the true problem is that some capacitor has reached the end of its useful life. Anyway, I decided to bite the bullet and finally get an RGB monitor for this GIGI that has been collecting dust on my closet floor. I wasn't able to find one of the original BARCO monitors, so I ended up giving it a CONRAC monitor that I found in a surplus store. It works, modulo a flakey DIP switch 8 that keeps me from setting the default to 9600; it thinks it's up all the time, so I have to choose between 19200 and 4800; and since the 2020 doesn't support 19200... I wonder which is rarer today, a 2020 or a GIGI??? ------- ------- 20-Jun-92 20:23:27-MDT,1049;000000000000 Return-Path: Received: from gidney.tops20.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 20 Jun 92 20:23:17 MDT Date: 20 Jun 1992 2220-EDT From: "Sam Weiner" To: tops-20@wsmr-simtel20.army.mil Subject: Re: At least TWO PDP-10s still alive at DEC Marlboro... Message-ID: <"MS11(6050)+GLXLIB6(0)" 12791079944.14.135.161879 at gidney.tops20.dec.com> References: Message from History shows that the Red Sox always win the World Series in the year after a Russian revolution. 19-Jun-1992 0911 of 20-Jun-92 0304-EDT In-reply-to: <9206191320.AA14639@enet-gw.pa.dec.com> As John said, GIDNEY and its pal KL1026 are still alive. Last I heard, they are supposed to remain with us for another year or so. Colorado, last I heard, had a 2 system TOPS-20 cluster. I'm not sure about the TOPS-10 side but I assume they have at least one. They should be up through the end of 1993 in support of customers. Sam Weiner -------- 23-Jun-92 13:57:02-MDT,3749;000000000000 Mail-From: PANDA created at 23-Jun-92 13:53:13 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Tue, 23 Jun 92 13:53:15 MDT Return-Path: <@WSMR-SIMTEL20.ARMY.MIL:ef1c+@andrew.cmu.edu> Received: from WSMR-SIMTEL20.Army.MIL by YUUYUU.Panda.COM with Cafard; Mon, 22 Jun 92 12:34:13 PDT Received: from andrew.cmu.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 22 Jun 92 10:06:42 MDT Received: by andrew.cmu.edu (5.54/3.15) id for MRC@yuuyuu.panda.com; Mon, 22 Jun 92 12:06:35 EDT Received: via switchmail; Mon, 22 Jun 1992 12:06:34 -0400 (EDT) Received: from proteus.mercury.acs.cmu.edu via qmail ID ; Mon, 22 Jun 1992 12:05:13 -0400 (EDT) Received: from proteus.mercury.acs.cmu.edu via qmail ID ; Mon, 22 Jun 1992 12:05:02 -0400 (EDT) Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.proteus.mercury.acs.cmu.edu.pmax.ul4 via MS.5.6.proteus.mercury.acs.cmu.edu.pmax_ul4; Mon, 22 Jun 1992 12:05:02 -0400 (EDT) Message-Id: <8eFTci200Vq002sX8U@andrew.cmu.edu> Date: Mon, 22 Jun 1992 12:05:02 -0400 (EDT) From: Esther Filderman To: Pat_Barron@transarc.com Subject: Re: PDP-10's still live at the University of Washington Cc: Mark Crispin In-Reply-To: References: <12790514457.9.MRC@YUUYUU.Panda.COM> ReSent-Date: Tue, 23 Jun 92 07:48:44 PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@WSMR-SIMTEL20.Army.MIL, ITS-LOVERS@MC.LCS.MIT.EDU ReSent-Message-ID: <12791740412.7.MRC@YUUYUU.Panda.COM> Excerpts from org.special-projects.tops20: 19-Jun-92 Re: PDP-10's still live at .. Pat_Barron@transarc.com (2076) > The last remaining system > was used by the Administrative Systems department to run payroll and > stuff, and they continued to use it until some time in 1989, when all > admininstrative functions were moved off to a VMS VAXCluster; at that > time, the last TOPS-20 machine was shut down. Actually, the last of the Tops-20s (Tops-E) was running some educational programs that were slow to port to either the Andrew system or VMS, and the master billing program for all billable systems (both VMS, VM/CMS and Tops-20). If I remember correctly, Tops-A, the last of two A.S. 20s (the other being Tops-F) was decomissioned about 6 months before Tops-E. > The machines themselves > may still be over at the CMU Computation Center for all I know. I was working for UCC Computer Operations from just before Tops-B was retired (Tops-C had been retired about a year before) to well after the demise of the last one (-sob- I'm not the only one who misses them horridly). Yes, there still are a few parts around the UCC. I tried to get my hands on some to give to the MIT Tops-20 folks but was told, "Sorry, they're all promised to someone." Sadly, I'm afraid it's a metal-scrapper -- I heard we couldn't find anyone to take at least 2 out of the 6 machines (anyone who would use them as computers, that is...). ------------------------------------------------------------- Esther C. Filderman ef1c+@andrew.cmu.edu System Mangler Library Automation Mercury Project Carnegie Mellon University "Father, forgive them, for they know not what they do. May the fools learn not to be slaves." AD0R - 15-AUG-1988 23:10:54 CMCCTB.CMU.EDU [Tops-B was shutdown for good at 16-AUG-1988 00:00] 26-Jun-92 20:42:27-MDT,3247;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 26 Jun 92 20:42:22 MDT Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.26 ) id AA01133; Fri, 26 Jun 92 19:42:12 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA04528; Fri, 26 Jun 92 19:42:08 PDT Received: from Tomobiki-Cho.CAC.Washington. (Tomobiki-Cho.CAC.Washington.EDU) by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA04476; Fri, 26 Jun 92 16:52:52 PDT Return-Path: Received: from alex.stacken.kth.se by Tomobiki-Cho.CAC.Washington.EDU (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 1.60.MRC ) id AA11901; Fri, 26 Jun 92 16:52:49 PDT Received: from life.ai.mit.edu by alex.stacken.kth.se (5.61+IDA/KTH/LTH/6.0) id AAalex.stacken.kth.se14947; Sat, 27 Jun 92 01:48:51 +0200 Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA16978; Fri, 26 Jun 92 19:48:30 EDT From: rs@ai.mit.edu (Robert E. Seastrom) Received: by rice-chex (4.1/AI-4.10) id AA25985; Fri, 26 Jun 92 19:48:27 EDT Date: Fri, 26 Jun 92 19:48:27 EDT Message-Id: <9206262348.AA25985@rice-chex> To: its-lovers@ai.mit.edu, ks-owners@alex.stacken.kth.se, admin-dt@fenchurch.mit.edu Subject: [MCMAHON@eisner.decus.org: DEC-10/DEC-20 Service Retirement] Resent-Date: Fri, 26 Jun 1992 19:42:03 -0700 (PDT) Resent-From: Mark Crispin Resent-Sender: Mark Crispin Resent-To: TOPS-20 Hackers and Yackers Resent-Message-Id: Date: Fri, 26 Jun 1992 18:58 -0400 From: John McMahon - TGV Tech Support Subject: DEC-10/DEC-20 Service Retirement Digital's Customer Update - 26 June 1992 ======================================== o DECsystem-10 and DECSYSTEM-20 Service Retiring DECsystem-10 AND DECSYSTEM-20 SERVICE RETIRING Digital ceased manufacturing DECsystem-10 and DECSYSTEM-20 systems in 1983 and announced the retirement of hardware and software support for these systems to both Digital and non-Digital users. Digital understands the importance of these systems in the user application environment and wants to ensure that users have time to migrate to newer technology without causing interruptions of their critical applications. Services After December 31, 1993, hardware support services can be performed on a best effort (per call) basis only. Best effort depends primarily on existing shelf spares and secondary sources to replace defective material. Digital cannot guarantee material availability once these spares sources are depleted, because the industry is phasing out of the DECsystem-10 and DECSYSTEM-20 chip technology. Software product services will be discontinued for the TOPS-10 and TOPS-20 operating systems on December 31, 1993. The last engineering updates for the operating systems were released in 1990. Telephone support for many of the DECsystem-10 and DECSYSTEM-20 software layered products has already been retired. 4-Jul-92 21:05:09-MDT,1224;000000000000 Mail-From: PANDA created at 4-Jul-92 21:04:12 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Sat, 4 Jul 92 21:04:14 MDT Date: Sat, 4 Jul 92 20:02:13 PDT From: Mark Crispin Subject: anniversaries coming up To: TOPS-20@WSMR-SIMTEL20.Army.MIL, ITS-LOVERS@MC.LCS.MIT.EDU Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098 Phone: +1 (206) 842-2385 Message-ID: <12794757523.7.MRC@YUUYUU.Panda.COM> I was making copies of the 36-bit anniversary video tapes, and I realized that we are coming to some significant dates in the not too distance future: December 31, 1992: the end of DEC hardware support for PDP-10's April, 1993: 10th anniversary of the assasination of PDP-10's 1994: 30th anniversary of PDP-10's It may still be too early to plan for a 30th anniversary party, but perhaps we should mark the 10th anniversary of the `integration strategy'. After all, the world has now recognized that VAX/VMS is the single standard operating system for now and forever, right? ;-) We ought to have some recognition of the trusty old beasts which are still executing PDP-10 instructions as well... ------- 6-Jul-92 03:55:53-MDT,984;000000000000 Return-Path: Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Jul 92 03:55:35 MDT Received: by bsd.stupi.se (5.67/1.37) id AA03155; Mon, 6 Jul 92 11:57:58 +0200 Date: Mon, 6 Jul 92 11:57:58 MET DST From: Peter Lothberg To: Mark Crispin Cc: TOPS-20@wsmr-simtel20.army.mil, ITS-LOVERS@mc.lcs.mit.edu Subject: Re: anniversaries coming up In-Reply-To: Your message of Sat, 4 Jul 92 20:02:13 PDT Message-Id: > It may still be too early to plan for a 30th anniversary party, but perhaps > we should mark the 10th anniversary of the `integration strategy'. After > all, the world has now recognized that VAX/VMS is the single standard > operating system for now and forever, right? ;-) One arcitecture, one operating system, one copany, that's the DEC strategy for the next 20 years... (DEC salesman, DECUS Europe Cannes 1985) -Peter 6-Jul-92 09:40:40-MDT,751;000000000000 Return-Path: Received: from brazil.cambridge.apple.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 6 Jul 92 09:40:37 MDT Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA16278; Mon, 6 Jul 92 11:43:50 -0400 for MRC@yuuyuu.panda.com Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA28687; Mon, 6 Jul 92 11:26:25 -0400 Message-Id: <9207061526.AA28687@cambridge.apple.com> Date: Mon, 06 Jul 92 11:39:12 EDT From: moon@cambridge.apple.com (David A. Moon) To: Mark Crispin Subject: Re: anniversaries coming up Cc: TOPS-20@wsmr-simtel20.army.mil, ITS-LOVERS@mc.lcs.mit.edu Should have called it "Open-10". 9-Jul-92 08:26:59-MDT,3231;000000000000 Return-Path: Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 9 Jul 92 08:26:45 MDT Date: Thu, 9 Jul 92 09:26:22 CDT From: Clive Dawson Subject: Serious MMAILR Bug To: mrc@yuuyuu.panda.com cc: tops-20@wsmr-simtel20.army.mil Message-ID: <12795930644.34.AI.CLIVE@MCC.COM> Hi Mark-- I would've never guessed there were any more serious MMAILR bugs lurking, and I'm not even sure when you last worked on any of this stuff, but for the record...: PROBLEM: Over the years, I've sometimes seen mail which just times out after n days in the queue without being delivered, even though the destination host is up and receiving mail. These occasional incidents increased dramatically a couple of days ago when I had about 80 messages in the queue which weren't moving. It is also possible that this bug could have caused mail to be delivered using totally bogus MX relays, at best causing an extra hop, and at worst causing failed delivery if the relay refuses to cooperate. DIAGNOSIS: There is code in MMAILR's MXNAME routine which loops down the arg block returned by GTDOM% (via a call to $GTHST) checking all the MX relays for a destination host. This code assumes that the list of byte pointers to relay names is ended by a zero entry, when in fact it should be using the count returned in GTDBLK+.GTDLN. Since the arg block is not cleared before each call, it is possible for MX relays from a previous call to still be present on that list. Two days ago I added a second MX relay host to the domain entries for all MCC hosts, in preparation for tomorrow's shutdown of MCC.COM (sob...but that's another story). This means that MCC.COM was now second on the list. What happened was this: -- MXNAME is called during the process of canonicalizing the sending hostname,and the GTDOM arg block is filled with MX relay info which happens to include MCC.COM. -- MXNAME is called again to get relay info for the destination hostname. If there is only one relay, the pointer to MCC.COM from the previous call is not wiped out, and MXNAME will find it on the list when it does the scan to see if "we are the relay", thus returning -1, and causing the message to be requeued indefinitely until it expires. CURE: Teach MXNAME (and who knows what else) to use the count when it scans the relay list rather than stopping when it reaches a zero entry. Or, if you don't have time to do an elegant fix because your TOPS-20 system only has two more days of life after which you will regretfully never need this stuff again, then just clear the arg block before each call: In MXNAME, after SETZM GTDBLK+.GTDRD ;So does this insert: MOVE A,[GTDBLK+.GTDRD,,GTDBLK+.GTDRD+1] ;Clear out arg block BLT A,GTDBLK+GTDLEN-1 SETZM RLYBUF ;Clear out relay buffer MOVE A,[RLYBUF,,RLYBUF+1] BLT A,RLYBUF+RLYBFL-1 Actually it would probably be best to make BOTH fixes, with the clearing of the arg blocks happening in the $DOGTD jacket routine. Gee, Mark, can this really be the LAST time I'm ever gonna bug you about MMAILR?! Sigh, Clive ------- 13-Jul-92 08:40:13-MDT,2144;000000000000 Return-Path: Received: from MCC-20.COM (mcc-20.mcc.com) by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 13 Jul 92 08:40:08 MDT Date: Mon, 13 Jul 92 09:37:54 CDT From: Clive Dawson Subject: Farewell message from MCC.COM To: tops-20@wsmr-simtel20.army.mil cc: clive@stone.MCC.COM, cohen@cli.com Message-ID: <12796981322.14.AI.CLIVE@MCC-20.MCC.COM> This is the last e-mail message sent from DECSYSTEM-20 #3536 under its current identity of MCC-20.MCC.COM. As has become traditional with 36-bit systems, a shutdown ceremony and party was held last Friday at which time the name MCC.COM and the corresponding IP address were reassigned to another system. MCC.COM was one of the last DEC-20's produced and sold by DEC, more than a year after the end of the product line was announced. It entered service on August 28, 1964, and has served us well over the past 8 years. I would have liked to keep it going longer. At one time I even thought (fantasized!) that it could be kept around until the year 2000. But the bean counters mounted increasingly effective attacks, which ultimately could not be fended off. Every time I've shut down a 36-bit system in the past, there was always another one to move to. But this time there isn't, and so a computing way of life which started 23 years ago finally ends for me today. I'd like to share a great slogan that my friend Rich Cohen coined for the occasion last Friday: TOPS-20 A Great Improvement Over Its Successors In about 30 minutes, dismantling of the cabinets will begin. The system will be shipped to Atlanta, refurbished and sent to somewhere in Canada where, according to my contact, it will compute till the end of the century. So perhaps the fantasy will be partially fulfilled at least. I won't say "so long", but I do owe a big "thanks for all the fish!" to all the friends I had the pleasure of getting to know over the years as a result of our shared adventure on these remarkable systems. Clive ------- 14-Jul-92 01:29:35-MDT,1165;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 14 Jul 92 01:29:31 MDT Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.26 ) id AA14985; Tue, 14 Jul 92 00:29:17 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA09925; Tue, 14 Jul 92 00:29:11 PDT Date: Tue, 14 Jul 1992 00:21:47 -0700 (PDT) From: Mark Crispin Sender: Mark Crispin Subject: re: Farewell message from MCC.COM To: Clive Dawson Cc: tops-20@wsmr-simtel20.army.mil, cohen@cli.com In-Reply-To: <12796981322.14.AI.CLIVE@MCC-20.MCC.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Clive - If you feel that you need a DEC-20 fix, Yuuyuu is still in the land of the living. You can call it at (206) 842-0759 and log in as GUEST, password FEIFEI. This is a 2400 baud dialup, but I expect to have a 9600 baud dialup in the not-too-distant future. -- Mark -- 15-Jul-92 16:14:09-MDT,1254;000000000000 Return-Path: <@UWAVM.U.WASHINGTON.EDU:PAT@locke.hs.washington.edu> Received: from UWAVM.U.WASHINGTON.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 15 Jul 92 16:13:55 MDT Received: from locke.hs.washington.edu by UWAVM.U.WASHINGTON.EDU (IBM VM SMTP V2R1) with TCP; Wed, 15 Jul 92 15:13:17 PDT Date: Wed, 15 Jul 92 15:12 PDT From: Pat Tressel Subject: another one bites the dust To: tops-20@wsmr-simtel20.army.mil Message-id: <26267CFEDB0B608469@locke.hs.washington.edu> X-Envelope-to: tops-20@wsmr-simtel20.army.mil X-VMS-To: IN%"tops-20@wsmr-simtel20.army.mil" Our KL was taken out of service about a month ago. It was purchased for $400 by Computer Clearinghouse, in a lot including a spare processor, memory, and a number or RP07s. They resold the (working) processor (only) to Compucom. Last Friday, the processor was picked up to be shipped to Piketon, Ohio, but we don't know to whom Compucom sold it. Does anyone know of a company in Piketon that would be likely to need a KL? I'd feel a lot better if I knew that it's gone to a good home. Patricia Tressel Locke Computer Center University of Washington Bitnet: pat@uwalocke Internet: pat@locke.hs.washington.edu 17-Jul-92 11:26:35-MDT,1132;000000000000 Return-Path: Received: from rpi.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 17 Jul 92 11:26:21 MDT Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB31); id AA25529; Thu, 16 Jul 92 15:21:56 EDT for TOPS-20@WSMR-SIMTEL20.ARMY.MIL Date: Thu, 16 Jul 92 15:20:24 EDT From: John_Wilson@MTS.RPI.EDU To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-Id: <2981738@MTS.RPI.EDU> Subject: KL10 I'm tired of hearing about these! If anyone else has a KL10 that they're going to let go for a song (I just missed one in Boston, the owner was asking $500 for the whole system), I'll give you two songs for it if it's anywhere in my hemisphere. Seriously! (I drove from Albany, NY to Houston, TX with a trailer to get my KS10) I admit I can't practically use one now but there's plenty of space in my storage locker and some day (hopefully not too many decades off) I'll live in a house that I own and will be able to put in a REAL power circuit, and then the FUN will begin! Boy will I feel dumb if I didn't get a KL10 back when everyone was dumping them for a week's pay... John_Wilson@MTS.RPI.EDU 19-Jul-92 19:01:49-MDT,1379;000000000000 Return-Path: Received: from indyvax.iupui.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sun, 19 Jul 92 19:01:45 MDT Received: from INDYVAX.IUPUI.EDU by INDYVAX.IUPUI.EDU (PMDF #2673 ) id <01GMHY3RGNG0001WJU@INDYVAX.IUPUI.EDU>; Fri, 17 Jul 1992 20:32:03 -0500 Date: 17 Jul 1992 20:32:03 -0500 From: "Mark H. Wood" Subject: TCP/IP for DEC-1091 To: tops-20@wsmr-simtel20.army.mil Message-id: <01GMHY3RGX36001WJU@INDYVAX.IUPUI.EDU> Organization: Indiana University - Purdue University at Indianapolis X-VMS-To: in%"tops-20@wsmr-simtel20.army.mil" MIME-version: 1.0 Content-transfer-encoding: 7BIT X-News: ivax comp.os.vms:8905 From: aurelio%secom.ufpa.br@UICVM.UIC.EDU (Aurelio Ramalho) Subject:TCP/IP for DEC-1091 Date: 14 Jul 92 13:02:26 GMT Message-ID:<9207141532.AA06625@secom.ufpa.br> Hello!! I want to know, if exists, any TCP/IP implementation for Digital's DECSystem-1091 running TOPS-10 v7.01 and how I can get it??? Who can help me? Aurelio Ramalho Systems Manager - UFPA.BR Domain Federal University of Para - Belem - BRAZIL -- Forwarded-By: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mark H. Wood, Lead Analyst/Programmer +1 317 274 0749 [@disclaimer@] Internet: IMHW400@INDYVAX.IUPUI.EDU BITNET: IMHW400@INDYVAX 21-Jul-92 00:51:11-MDT,3793;000000000000 Return-Path: Received: from gatekeeper.oracle.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 Jul 92 00:51:06 MDT Received: from churchy.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA05311; Mon, 20 Jul 92 23:50:58 PDT Received: by churchy.us.oracle.com (5.59.11/37.7) id AA14203; Mon, 20 Jul 92 23:51:05 BST Date: Mon, 20 Jul 1992 23:51:04 BST From: Ken Harrenstien To: its-lovers@mc.lcs.mit.edu, tops-20@wsmr-simtel20.army.mil Cc: klh@us.oracle.com Subject: One small step, one giant leap Message-Id: On this anniversary of a truly historic moment, I would like to announce a somewhat smaller event which may loom the larger for being closer to our hearts. stealth.us.oracle.com% telnet nx.us.oracle.com Trying 139.185.5.134 ... Connected to mit-nx.us.oracle.com. Escape character is '^]'. Unknown ITS PDP-10 NX ITS.1645. DDT.1545. TTY 11 2. Lusers, Fair Share = 136% klh$u *peek^K! NX ITS 1645 Peek 629 7/20/92 23:02:48 Up time = 2:15 Memory: Free=381 Runnable Total=83 Out=71 Users: High=6 Runnable=1 Index Uname Jname Sname Status TTY Core Out %Time Time PIs 0 SYS SYS SYS HANG ? 51 0 0% 4 1 CORE JOB CORE UUO ? 0 0 0% 2 KLH0 HACTRN SYS TTYI T0 30 9 1% 3 11TLNT TELSER 202405 SLEEP ? 1 0 0% 4 KLH HACTRN KLH HANG > 30 9 0% 5 KLH PEEK KLH +TTYBO T11 C 83 71 7% Fair Share 135% Totals: 195 9% 7 Logout time = 2 Lost 0% Idle 98% Null time = 2:14 A NX ITS 1645 Peek 629 7/20/92 23:02:50 Up time = 2:17 IMP is up. TCP/IP is available. Ix Usr Uname Jname State RWnd Ibf SWnd ReTxQ Lclprt Fgnprt Fgnhst 34 3 11TLNT TELSER OPEN 5170 0 10000 0 0 27 10107 139.185.5.5 4 buffers (4 free) STY Map Idx STY owner Idx STY user Host T11 3 11TLNT TELSER 5 KLH PEEK 139.185.5.5 (TCP) Q :KILL *$$u NX ITS 1645 Console 11 Free. 23:03:13 telnet> q Connection closed. stealth.us.oracle.com% Yes, NX is a real, live, internet-host ITS assembled from the final snapshot of AI. So here's the punch line... ***There is no KS-10.*** NX is running on a "KLH-10" -- a virtual PDP-10. Over the past two months I was finally able to put everything together to create a complete PDP-10 emulator, including all necessary devices (RP06, TM03, console, IMP); to distinguish it from a real DEC machine I'm calling it a KLH-10 per Alan Bawden's suggestion. The current version is completely in C and should eventually be portable to most platforms, but at the moment NX's host machine is a 33Mhz SUN Sparc-2 workstation sitting on my desk. It's a long story with many more details and ramifications, all of which I'll put off for later. Although I wrote it entirely on my own, it would never have happened without many people who I'd like to thank here: Stu Grossman, for convincing me with his KX-10 that a hardware emulation in C was feasible. Alan Bawden & Dave Moon, who (apart from their already legendary roles in ITS) helped as much as they could without actually being there. Jay Verkler (JLV), who with his group has re-created an AI lab work environment within Oracle. It's called the Network Products Division and made this hack possible. Plus everyone else on these lists whose messages and actions have helped keep the PDP-10 alive in spirit and reality a little longer... may it now live as long as we wish! --Ken 21-Jul-92 05:55:04-MDT,1240;000000000000 Return-Path: Received: from martigny.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 21 Jul 92 05:55:01 MDT Received: by martigny.ai.mit.edu (16.7/15.6) id AA02528; Tue, 21 Jul 92 07:56:36 -0400 Date: Tue, 21 Jul 92 07:56:36 -0400 From: "Guillermo J. Rozas" To: klh@us.oracle.com Cc: its-lovers@mc.lcs.mit.edu, tops-20@wsmr-simtel20.army.mil In-Reply-To: Ken Harrenstien's message of Mon, 20 Jul 1992 23:51:04 BST Subject: One small step, one giant leap Reply-To: jinx@martigny.ai.mit.edu Date: Mon, 20 Jul 1992 23:51:04 BST From: Ken Harrenstien Over the past two months I was finally able to put everything together to create a complete PDP-10 emulator, including all necessary devices (RP06, TM03, console, IMP); to distinguish it from a real DEC machine I'm calling it a KLH-10 per Alan Bawden's suggestion. The current version is completely in C and should eventually be portable to most platforms, but at the moment NX's host machine is a 33Mhz SUN Sparc-2 workstation sitting on my desk. So when/how can we ftp the goodies? 23-Jul-92 22:25:14-MDT,16381;000000000000 Return-Path: Received: from gatekeeper.oracle.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 23 Jul 92 22:25:01 MDT Received: from churchy.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA06859; Thu, 23 Jul 92 21:24:42 PDT Received: by churchy.us.oracle.com (5.59.11/37.7) id AA19272; Thu, 23 Jul 92 21:24:48 BST Date: Thu, 23 Jul 1992 21:24:47 BST From: Ken Harrenstien To: its-lovers@mc.lcs.mit.edu, tops-20@wsmr-simtel20.army.mil Cc: klh@us.oracle.com Subject: KLH10 info Message-Id: OK, here are some more details about the KLH10. I've been a bit overwhelmed by the many private responses and hope this answers most of the questions. First, the FAQs I've been getting: * "When/How can I get a copy?" Ouch, probably not until after Interop (Oct). It kills me to say this, but my time *is* limited. (The usual bribes might help :-) RMS has suggested distributing it via GNU/FSF, and I like that idea. * "Will it run ?" Anything based on the KS10 should run with minor mods. The 166, KA and KI will require moderate I/O instruction changes. The KL10/20 (extended addressing, DTE20, etc) would require major surgery -- without anesthetic. * "How fast is it?" That depends mostly on the host platform. Using a 33 MHz Sparc-2, very roughly 0.2 MIPS, perhaps 50% of a KA. More about this farther on. * "Why can't I connect to NX?" Oracle uses firewalls to prevent full Internet access to their internal networks. We are trying to set up an ITS turist machine but it needs to be done very carefully. Wait for an announcement. * "Thanks!" You're welcome!! The rest of this message talks about various aspects at more length: specifics of the target machine & devices, the emulator, and various other thoughts. It is a bit long for one message, but I figure it's better to get it all out of the way. My apologies to any uninterested people. Summary: ------- Target machine: KS10 with MIT ITS microcode Target config: 512K memory, RH11/RP06, RH11/TM03, FE console, ACC LH/DH & IMP Current speed: ~0.2 MIPS Current host: 33 MHz Sparcstation-2 with internal disk, SunOS 4.1.1 Compiler: GCC 2.1 Misc: Sources .5MB, runtime memory 4.3MB, disk lotsaMB About the Target Machine: ------------------------ The decisions I made while coding the emulator all boil down to a simple desire to get something useful and interesting up as quickly as possible. Among other things this meant using an ITS-microcode KS10 as the target machine, because: [1] I don't have official access to TOPS-20 binaries or sources, and didn't want to worry about licensing hassles. Ditto TOPS-10. I also am lacking the voluminous documentation about installation and operating procedures. [2] The most recent ITS binaries and sources are all archived online (thanks to Alan), and all are for the KS10 version. All documentation is likewise online, and in any case I have a somewhat more intimate understanding of ITS. [3] The KS10 has a simpler architecture than the KL10, which allows an emulator to run much faster. If not for [2] I might have started with the KA10 for this reason. It is important to realize that the KLH10 is emulating the ITS microcode, which is slightly different from that for TOPS-10 or TOPS-20. The primary differences have to do with the pager and the absence of the extended-instruction set (the noteworthy ITS features such as one-proceed, JPC, and CIRC are of course supported). In order to bring up TOPS-10 or TOPS-20, minor changes would be needed to the pager code (somewhat more for TOPS-20, owing to its more complex design). The extended string instructions are ugly but straightforward for anybody with a strong stomach (and weak mind?). Everything else is fully supported, including the double-precision floating point instructions. I took pains to verify that all results and PC flags are identical to the real hardware, even for wildly unnormalized operands. This was *not* one of the fun parts. With respect to a KA or KI version, the I/O instructions would also need to be modified and a number of things changed in the APR and PI system, but not a great deal. Bringing up TENEX should be relatively easy given a complete description of the BBN pager. WAITS, however, would be up to a true SAILor. I know many people are going to wish for a KL10 they can run a full-grown TOPS-20 on. Of course this is theoretically possible, but it is not going to be easy to get something that runs at a useful speed without a superfast host. Remember the KL10 is an oversexed mutant with these strange bulging growths oozing out of random body parts, all of which have to be duplicated no matter how bizarre. Just dealing with extended addressing is going to slow down the basic instructions as well as requiring much more pager overhead; this is one area where the hardware parallelism is hard to beat. The additional device cruft (DTE20s, meters, address breaks, etc) doesn't help. Personally I won't try it without some concrete incentives. P.S. Just for grins I included the KA10 and PDP-6 arithmetic ops, although I don't have a reference machine for verification (ha). Who knows, maybe a 340 will come along! Spacewar, yeah! I/O Devices: ----------- A great deal of the work consisted not of emulating the 10 but rather emulating a basic set of peripherals. The KS10's use of Unibus devices made it somewhat more painful than the old I/O device scheme, because instead of a small matrix of devices and I/O instruction opcodes, there's a long list of bus addresses to check, each of which has completely arbitrary meanings. Not to mention the Unibus adapters with their individual Unibus page maps, all of which are emulated as well. DSK: Currently one RH11/RP06 is supported as a virtual disk. The actual implementation uses a standard Unix disk file (not a raw disk) to hold the "RP06" contents; this is so all blocks that haven't been written will simply not exist (also known as a holey file), thus taking up much less space than a full raw disk would. Formatting the disk is obviously unnecessary; sector headers are not written or read. Errors are pretty much limited to those caused by garbage written into the registers, so the interface is a bit simpler than the real thing. It's possible that an OS which can't leave well enough alone will insist on using some weird maintenance bits, in which case the device code will need work. Mods for multiple drives or other RH-controlled drive types are trivial. MTA: Similar considerations apply to the RH11/TM03 magtape interface. From the "FE" (front-end controller interface) one can mount or unmount "tapes" that consist of either binary tape images or virtual tapes built on the fly from lists of unix files. Hooking up a real magtape drive would probably have been easier, but loading virtual dump tapes into the filesystem is very fast, actually -- much faster than the real devices would be. In fact I found one race condition in the ITS bootstrap loader that required slowing down disk I/O until I was able to reassemble a fixed version. NET: The network interface is an emulation of the ACC LH/DH that some MIT machines used to have, as well as a virtual IMP. Putting this one together was a major project in network hacking, not to mention deceit. Using Sun's NIT (Network Interface Tap) and various trickery, I was able to set up NX with its own IP address, independent of its platform's address and thus permitting me to run ITS without interfering with the other network stuff I'm doing on my workstation. For efficiency, the virtual IMP is actually a "Simple IMP" that doesn't bother sending RFNMs, and the virtual LH/DH does I/O in PDP-10 byte order (not Unibus order) -- this all required changes to the ITS IMP driver. For a while I considered munging the packets within the virtual IMP to pretend that the local net was the ARPANET, but finally decided it was better to fix ITS itself, and did so; ITS can now be configured for non-ARPA subnets. Geez, I never thought after I did ITS TCP/IP that I'd be hacking the code again ten years later! TTY: The FE console TTY "interface" is emulated, tho the 8080 FE commands aren't -- no need. There is also a dummy DZ11 driver that merely reads and writes registers without doing anything. This (and an equally empty Chaosnet driver) was needed because that's what the last AI ITS binary image was configured for, and I had to get that up before I could reassemble a new system (oh the joys of bootstrapping). The DZ11 won't be hard to finish off, but I'm not sure it's worthwhile; it's a horribly inefficient device and it's much faster to telnet in over the network. If realio trulio serial-line I/O is needed, I'd recommend going for a DH11 if the OS supports it. (It isn't as if it still costs three times as much as a DZ :-) About the emulator: ----------------- The KLH10 is written in C for a vanilla Unix OS, largely so it can be readily ported to other platforms; in particular, those of the future as well as those of today. Although re-coding critical sections in assembler would readily double or triple the basic instruction speed, it is much easier to simply recompile it on a faster machine. Although I use the GCC compiler for its efficiency, I don't use any of its non-standard language constructs, again for portability. The most fundamental design decision had to do with the method of representing 36-bit words on a 32-bit architecture. I wound up coding around a halfword-based scheme, with each 18-bit PDP-10 halfword right-justified in a 32-bit host word; thus each PDP-10 word uses 8 octets. The same format is used for memory, ACs, and disk storage; basically I traded off space for speed. On a machine with a word size larger than 36, or a C compiler that supported an equivalent integer type (such as double-word ints), many things become easier, and I'd want to re-do a fair amount of the arithmetic code. Not because the current version won't work -- it will -- but because it won't be as efficient. I decided early on that the differences between optimal code on a 32-bit and +36-bit machine were just too great to easily combine with the primitive tools available in C. The arithmetic emulation relies only on well-defined native integer operations; native floating point is never used, both because it is non-portable (formats vary) and because it is very difficult to precisely emulate the PDP-10's behavior without actually carrying out the same internal operations "by hand". This is by far the slowest part of the KLH10. I checked it out by compiling it on a real 20 (using KCC, of course!) and running it for hours under a test program that generated various operand bit patterns and compared the results with those for real instructions. The current implementation is being used as a testbed for threads, and includes code for both a non-threaded and threaded version. (I figured, what better test of software parallelism than to emulate hardware parallelism?) This means that running on a true multi-processor platform could produce somewhat better performance, although the main APR execution thread is still serial and will impose an upper bound on the speedup. Let's not talk about pipelining just now. To clear up one thing that has caused confusion: the emulator is *not* running standalone on my Sparc. Except for the net device it uses the usual Unix system calls and burns 100% of the CPU, running flat out. I don't really notice it since the amount of CPU I use most of the time is typically a negligible fraction of the Sparc's capability; for example, I'm writing this note in one window while ITS runs in the other, and everything's cool. The NEED for SPEED: ------------------ In the summary I mentioned a speed of 0.2 MIPS, or about 5 usec per instruction. This is probably the number people are most avidly interested in, but at the same time it's also one of the hardest to measure. PDP-10 speeds have always been tricky, mainly because it all depends on the precise mix of instructions and operands. Now it's even fuzzier because so much of the KLH10 is variable. Of course, the host platform speed is an overriding factor. But I've seen that even minor changes in the main loop can produce noticeable differences in response time, as can the exact nature of memory references. For example, the SPARC is a register-window machine and it's faster to pass arguments to functions than to set and read global variables; it's also faster to use C structure members than globals! Another machine could have precisely the opposite behavior. I should add here that the compiler is also tremendously important; using GCC results in code that is 40% faster than Sun's CC! Yow! Anyway, I haven't really buckled down and tried to tune or measure its performance, so take the 0.2 MIPS loosely. My back-of-the-envelope calculations before I started suggested that an assembler-coded SPARC implementation could achieve a KA performance level; the current C version appears to get perhaps half that speed. Assembling the entire ITS OS takes about 26 minutes of real time, but I don't know if anyone remembers how long it took on a real KS10, much less a KA10. The Sparc is already a slowpoke compared with some of the new workstations and chipsets coming out, so it's just a matter of time before someone cracks the KS10 speed limit on reasonably cheap personal hardware. I can't help but wonder if might be worth paying serious attention to a high-speed version, one that would represent a cost-effective solution for those places still committed to PDP-10 software. Systems Concepts probably doesn't need to worry -- yet! Future improvements: ------------------- The obvious one is speed. Then more machine variants, more devices. More instrumentation & profiling. A nicely packaged distribution with your choice of OS and initial filesystem included. The usual embellishments. Whatever people suggest. There's also the possibility of evolving a new virtual machine, one which realizes more closely whatever the ideal PDP-10 is conceived to be. (That itself is an interesting question.) For example, the real KS10 ITS microcode does not actually support JPC, which was a feature of Holloway's MAC-10 pager; the KLH10 does it trivially and in that sense is more than a simple KS10. Its pager could support 2048K as easily as 512K. And so on, all of which implies reconfiguring a real OS to run on an unreal machine. The first step down this road has already been taken with NX ITS, assembled to use a non-existent net interface. And I've always thought it would be lovely to have a window displaying a KA-style console panel with a full bank of lights and clickable switches. I know the KS10 never had one, but that doesn't mean it has to stay that way, and besides, the KL10 cheated with a 11/40 panel, so it's down to either the KA or KI. Of course it's just for fun, what else is this all about? Final thoughts: -------------- I was going to close with the last paragraph, but realized there's one more thing I want to say. It's just that, um, well, this will sound silly, but it feels so... weird? ... eerie? ... just plain literally *mind-blowing* to watch this system boot up and run happily, utterly unaware that it's not on a real machine, or that anything odd happened since the last time it ran, or that its earthly incarnation of a noisy roomful of huge cabinets and washing machines is now entirely self-contained within a small innocuous pizza box holding up my ITS manuals. Do systems have wathans? I've gotten a bit more used to it, but every now and then I still sit back, realize once again what the hell is going on, and hold on to something while the chills pass. I didn't expect this at all. A side effect of being imprinted at a tender young age, or something... --Ken 24-Jul-92 18:26:49-MDT,2107;000000000000 Return-Path: Received: from MTS.RPI.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 24 Jul 92 18:26:45 MDT Date: Fri, 24 Jul 92 20:26:26 EDT From: John_Wilson@MTS.RPI.EDU To: ITS-LOVERS@MC.LCS.MIT.EDU, TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-ID: <2994824@MTS.RPI.EDU> Subject: ?BT 001172 Hello, I've been slugging away at getting my KS10 running (with a whole lot of help recently from Peter Lothberg and Joe Dempster -- thanks guys!), and at this point I think (hope? wish?) that the problem is cornered in the disk drive. The machine passes BC, but when I try to boot I get a ?BT 001172 which according to the doc's means a disk error while executing the command list entry whose address ends in 172. But, my machine has CSL.V5.2, and I have listings for V4.2, so I don't know what corresponds. If I do an EI command I get 000001,,776712/000000,,154700 I've forgotten whether this is a command reg or what, my RM03 manual is around here somewhere but I can't seem to find it. Maybe it's a WC reg? Anyway I usually can't change its value with DI commands. Any idea what this points to? What I'm looking for is, is this the "usual error" for any particular disk error (record not found, 18-bit jumper not in (I think it is), whatever). When the drive is switched off the error changes to "?BT 001062" so I think I'm partway there, but the READY light doesn't flicker perceptibly so who knows. FWIW, I'm mostly but not 100.00% sure that my Massbus cable is good, I have scads of them in storage and I took the best-looking one, but I think I had a couple which were F-S rejects that my old company gave me, I don't know if it was from deinstalling drives or because they had broken wires. Thanks... Sorry to bother you all with all this grunginess but I'm getting REAL CLOSE and I'm about to have to put this thing back in storage, I'd like to get the beasty to its knees first so I can dump the AI snapshot onto the disk and free up some space on my Unix box. John_Wilson@MTS.RPI.EDU USERGZ7V@RPITSMTS 25-Jul-92 22:57:21-MDT,2392;000000000000 Return-Path: Received: from life.ai.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 25 Jul 92 22:57:16 MDT Received: from august (august.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AB16819; Sun, 26 Jul 92 00:45:24 EDT Received: by august (4.1/AI-4.10) id AA19430; Sun, 26 Jul 92 00:46:12 EDT Date: Sun, 26 Jul 92 00:46:12 EDT Message-Id: <9207260446.AA19430@august> From: Alan Bawden Sender: Alan@lcs.mit.edu To: John_Wilson@mts.rpi.edu Cc: ITS-LOVERS@mc.lcs.mit.edu, TOPS-20@wsmr-simtel20.army.mil In-Reply-To: John_Wilson@mts.rpi.edu's message of Fri, 24 Jul 92 20:26:26 EDT <2994824@MTS.RPI.EDU> Subject: ?BT 001172 Date: Fri, 24 Jul 92 20:26:26 EDT From: John_Wilson@mts.rpi.edu 000001,,776712/000000,,154700 I've forgotten whether this is a command reg or what, my RM03 manual is around here somewhere but I can't seem to find it. Maybe it's a WC reg? Anyway I usually can't change its value with DI commands. This is the drive status register. Here is its definition (from the ITS sources): DEFSYM %HRSTS=:776712 ;DRIVE STATUS. DEFSYM %HSATN==1_15. ; Attention Active DEFSYM %HSERR==1_14. ; Error DEFSYM %HSPIP==1_13. ; Positioning In Progress DEFSYM %HSMOL==1_12. ; Medium On-Line DEFSYM %HSWRL==1_11. ; Write Locked DEFSYM %HSLST==1_10. ; Last Sector Transferred DEFSYM %HSPGM==1_9. ; Programmable DEFSYM %HSDPR==1_8. ; Drive Present DEFSYM %HSRDY==1_7. ; Drive Ready DEFSYM %HSVV== 1_6. ; Volume Valid So the only unusual bit you see there is the "Error" bit, which means you should look elsewhere to see what the error is. Such as: DEFSYM %HRER1=:776714 ;ERROR 1. DEFSYM %H1ECC==1_15. ; Data Check DEFSYM %H1UNS==1_14. ; Unsafe DEFSYM %H1OPI==1_13. ; Operation Incomplete DEFSYM %H1DTE==1_12. ; Drive Timing Error DEFSYM %H1WLK==1_11. ; Write Lock Error DEFSYM %H1IAE==1_10. ; Invalid Address Error DEFSYM %H1AOE==1_9. ; Address Overflow Error DEFSYM %H1CRC==1_8. ; Header CRC Error DEFSYM %H1HCE==1_7. ; Header Compare Error DEFSYM %H1ECH==1_6. ; ECC Hard Error DEFSYM %H1WCF==1_5. ; Write Clock Fail DEFSYM %H1FER==1_4. ; Format Error DEFSYM %H1PAR==1_3. ; Parity Error DEFSYM %H1RMR==1_2. ; Register Modification Refused DEFSYM %H1ILR==1_1. ; Illegal Register DEFSYM %H1ILF==1_0. ; Illegal Function 28-Jul-92 19:21:37-MDT,1237;000000000000 Return-Path: Received: from MTS.RPI.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 28 Jul 92 19:21:26 MDT Date: Tue, 28 Jul 92 21:21:16 EDT From: John_Wilson@MTS.RPI.EDU To: ITS-LOVERS@MC.LCS.MIT.EDU, TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-ID: <2999389@MTS.RPI.EDU> Subject: RM drives Two RMXX-related questions: 1. Does anyone have a module utilization chart or a working RM- series drive who can tell me which position in the RM adapter backplane is right for the M7687 (which gets the "data" SMD cable)? My doc's aren't clear, I have no prints, the diagram painted on the backplane cover shows it about halfway between 8E and 8F (I've tried both -- have I smoked my drive?), and both of the RM drives I have came with this board having fallen out -- it's single-width but full height so the slightest bump makes it fall out. 2. I understand that a VAX RM80 needs to have a new low-level format written on it before it can be used in 18-bit mode. Does anyone have a program (or know of a diagnostic) which can do this? SYSTEM; CONFIG > claims that MD had an RM80, so I believe this has been done before. Thanks, John_Wilson@MTS.RPI.EDU 29-Jul-92 02:35:49-MDT,1188;000000000000 Return-Path: Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 29 Jul 92 02:35:40 MDT Received: by bsd.stupi.se (5.67/1.37) id AA00811; Wed, 29 Jul 92 10:31:19 +0200 Date: Wed, 29 Jul 92 10:31:19 MET DST From: Peter Lothberg To: John_Wilson@mts.rpi.edu Cc: ITS-LOVERS@mc.lcs.mit.edu, TOPS-20@wsmr-simtel20.army.mil Subject: Re: RM drives In-Reply-To: Your message of Tue, 28 Jul 92 21:21:16 EDT Message-Id: > Two RMXX-related questions: > > 1. Does anyone have a module utilization chart or a working RM- Ill look on it when i get home tonight. > 2. I understand that a VAX RM80 needs to have a new low-level format > written on it before it can be used in 18-bit mode. Does anyone > have a program (or know of a diagnostic) which can do this? > SYSTEM; CONFIG > claims that MD had an RM80, so I believe this > has been done before. If not already done, the ITS formater can be made to do it. The DEC tool is DSRMB, but it only deals with rp06/rm03, I have a patched version that does rm05/rp06, that could be patched again... -Peter 21-Aug-92 11:40:58-MDT,3363;000000000000 Return-Path: Received: from akbar.cac.washington.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 21 Aug 92 11:40:50 MDT Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14007; Fri, 21 Aug 92 10:40:42 -0700 Date: Fri, 21 Aug 1992 10:40:30 -0700 (PDT) From: Mark Crispin Subject: [Bill Fisher: Our DECsyatem10 has gone To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Another one bites the dust... ;-( ** Begin Forwarded Message(s) ** Received: from Tomobiki-Cho.CAC.Washington. (Tomobiki-Cho.CAC.Washington.EDU) by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA01425; Thu, 20 Aug 92 22:34:16 PDT Return-Path: Received: from WATTLE.qut.edu.au by Tomobiki-Cho.CAC.Washington.EDU (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 1.60.MRC ) id AA08286; Thu, 20 Aug 92 22:34:02 PDT Date: Fri, 21 Aug 92 14:38 +1000 From: Bill Fisher Subject: Our DECsyatem10 has gone To: itb625homewo@qut.edu.au, cckaye@fennel.cc.uwa.edu.au, a_reid@fennel.cc.uwa.oz.au, peter@julian.uwo.ca, geoff@world.std.com, stevev@greylady.uoregon.edu, wml@sei.cmu.edu, hsundstrom@finabo.abo.fi, kym@cs.binghamton.edu, csmith@convex.com, eric@telebit.com, spider@kl1026.tops20.dec.com, rla@netcom.com, kborge@usit.uio.no, gkn@sdsc.edu, jiml@heap.cisco.com, der@hpuerca.atl.hp.com, MRC@panda.com, michael@io.as.utexas.edu, bjla@statoil.no, clyde@design.fen.qut.edu.au, gmt@cs.arizona.edu, lesnyd@monsanto.com, dboyes@rice.edu, isy5hob@cabell.vcu.edu, has8wwa@cabell.vcu.edu, magnus@thep.lu.se, meharp01@vlsi.ct.louisville.edu, curtis@henry.bowdoin.edu, ctp@cs.utexas.edu, miles@cogsci.ed.ac.uk, roll@kaos.stupi.se, cjj@east.sun.com, hoffman@cs.pitt.edu, bygg@sunic.sunet.se, morales@panam1.panam.edu, jdc@nauvax.ucc.nau.edu, flash@csd.uwo.ca, jms@arizona.edu, clive@mcc.com, norman@clsc.utoronto.ca, rfrench@cs.stanford.edu, nelsen@bowdoin.edu, sean@coombs.anu.edu.au, crtb@helix.nih.gov, EALyon@sunrise.syr.edu Message-Id: <0917922E307F200E5E@qut.edu.au> X-Envelope-To: MRC@Panda.com X-Vms-To: @NOSTAE.DIS X-Vms-Cc: FISHER Well folks it has gone. Our DEC-10 duly died last Monday with a farewell reminiscent ofthe death of HAL. A number of files are available through anonymous FTP from oat.qut.edu.au in an area called pub/nostalgia. The files are: GREET.TXT contains the greetings received from various people around the world in the last few weeks. (Some greetings from QUT students with forged names have been deleted!) DAWSON.TXT, FLEM.TXT and RNDTBL.TXT contain particularly interesting longer items of mail received. The last contains the minutes of a round table meeting of pioneers at 1984 Fall DECUS and well worth reading. MAIL.TXT contains the rest of the mail received during our nostalgia period. QUEANS.TXT contains the questions we asked in our DEC10 test, our answers, and statistics as to how people answered. Once again thanks for your interest and goodbye. Bill Fisher 22-Aug-92 10:00:16-MDT,429;000000000000 Mail-From: WANCHO created at 22-Aug-92 10:00:12 Date: Sat, 22 Aug 1992 10:00 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: QUT files The QUT files are also available from WSMR-SIMTEL20.ARMY.MIL [192.88.110.20] via ANONYMOUS FTP in PD3:. --Frank 24-Aug-92 15:14:28-MDT,1073;000000000000 Return-Path: Received: from enet-gw.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 24 Aug 92 15:14:23 MDT Received: by enet-gw.pa.dec.com; id AA17610; Mon, 24 Aug 92 14:14:17 -0700 Message-Id: <9208242114.AA17610@enet-gw.pa.dec.com> Received: from tle.enet; by decwrl.enet; Mon, 24 Aug 92 14:14:18 PDT Date: Mon, 24 Aug 92 14:14:18 PDT From: Aron Insinga ZK2-1/Q18 1N24 dtn 381-1928 24-Aug-1992 1711 To: tops-20@wsmr-simtel20.army.mil Cc: insinga@tle.enet.dec.com Apparently-To: tops-20@wsmr-simtel20.army.mil Subject: MAXC PDP-10 clones Was there an article published in IEEE Spectrum or IEEE Computer or elsewhere (15 or so years ago?) about Xerox cloning the PDP-10? Was there one MAXC machine built or two? (If two, were they different designs?) There was a console computer, wasn't there? - Aron Insinga Email: insinga@tle.enet.dec.com Mail: Digital Equipment Corporation, 110 Spit Brook Rd. (ZKO 2-1/Q18) Nashua, NH 03062-2698 USA Phone: (603) 881-1928 Fax: (603) 881-0120 21-Sep-92 03:43:26-MDT,2554;000000000000 Mail-From: PANDA created at 21-Sep-92 03:42:19 Return-Path: Received: from YUUYUU.PANDA.COM by WSMR-SIMTEL20.ARMY.MIL with Cafard; Mon, 21 Sep 92 03:42:19 MDT Date: Mon, 21 Sep 92 01:18:37 PDT From: Mark Crispin Subject: 10 years ago... To: TOPS-20@WSMR-SIMTEL20.Army.MIL Postal: 6158 Lariat Loop NE; Bainbridge Island, WA 98110-2098 Phone: +1 (206) 842-2385 Message-ID: <12815262355.7.MRC@YUUYUU.Panda.COM> I happened to feel in a nostalgic mood, looking through some of my old 36-bit memorabilia: Remember 10 years ago, when we were getting fascinating tidbits from our DEC salesman (not to mention our friends in the TOPS-20 monitor group) about the Jupiter (a.k.a. KC10, a.k.a. DECsystem-2050)? When we were wearing T-shirts saying: I don't care what people say 36 bits are here to stay. The reports of my death have been greatly exaggerated. If your computer doesn't have 36 bits you aren't playing with a full DEC. Nuke Tewksbury! Remember thinking about the neat things to come, such as the new stack instructions? As I remember, it had a PUSHA instruction to save AC's using a bitmask, and the right half of POPJ would have a bitmask of AC's to restore. Fully-supported G-floats, quadruple precision integers [144 bit integers! And I can't get better than 32 bit integers in today's `modern' world of C], and all 30 bits of address space, not just the piddly 23 bits the KL gave us. We were getting ready to go to our last optimistic DECUS. I forget now, but wasn't that at the Town & Country in San Diego, or had Fall DECUS already moved to Anaheim by then? We were running TOPS-20 5.0; some of us were running 5.1. At that time, our biggest worry was the TCP/IP transition scheduled to happen on January 1, 1983. DEC was promising us a wonderful TCP: device and totally rewritten TCP code from the BBN stuff. Well, that didn't quite happen, although we ultimately did get the TCP: device. I remember spending most of the week between xmas and New Years Day getting the mailer converted, cursing the bizarre BBN TCP jsi the whole time. Remember NCP reclama? Little did we know what was going to happen in April 1983, that Ken Olson would become discouraged by the poor work on Project Jupiter and cancel all future 36 bit CPUs. On the other hand, as we approach the 10th anniversary of that terrible Friday before Spring DECUS...: WE'RE STILL HERE!!! Which is more than you can say for KO... ;-) -- Mark -- ------- 23-Sep-92 12:42:28-MDT,1531;000000000000 Return-Path: Received: from mathom.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 23 Sep 92 12:42:23 MDT Date: Wed 23 Sep 92 11:32:50-PDT From: Jim Lewinson Subject: Another machine passes on To: tops-20@wsmr-simtel20.army.mil Message-ID: <12815898457.11.JIML@mathom.cisco.com> I seem to be writing quite a number of these. :-) I am sorry to report the departure of Mathom.cisco.COM from the Internet, at least for this lifetime. Mathom had occupied several bodies during this lifetime, and lived in several interesting places, including a garage in Atherton, California while awaiting the preparation of a new home. It has been with cisco Systems, Inc. since cisco's very early days. It has been successfully called upon to help folks to design boards for ethertips/gateways/routers (with some help from its cousins and friends at Stanford University), and less succesfully to perform such truly amazing feats as levitate itself to the second floor without the use of the (broken) freight elevator (it hadn't perfected its wisdom enough at that time to do that task.) Last week, it swapped DEC-2065 bodies with its longtime friend, Heap.cisco.COM, so its most recent body serial number was 3539. It has already bequeathed its RP07 disk drives to Heap. It is survived by Heap, and a host of less long-lived MIPS and Sun boxes and a rather long-lived HP friend named Clash. Goodbye Mathom: we send you forth. Jim Lewinson ------- 24-Sep-92 15:22:14-MDT,5136;000000000000 Return-Path: Received: from gidney.tops20.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 24 Sep 92 15:22:04 MDT Date: 24 Sep 1992 1712-EDT From: "old KL10s don't die, they are stripped and crushed" To: goodbye-gidney: tops-20@wsmr-simtel20.army.mil, brown@satire, wong@satire, mastrovito@vino, praetorious@star, muldoon@spezko, satoh_a@tktv20, harley@gotit, mdlyons@celtic, otoole@vino, braithwaite@cartun, jmccollum@vino, pratt@vino, flemming@vino, sscott@iota, gscott@o, waddington@nodex, aej@wpi.wpi.edu, puchrik@mr4dec, sendlosky@vino; Subject: Goodbye Gidney Message-ID: <"MS11(6050)+GLXLIB6(0)" 12816189707.14.27.30911 at gidney.tops20.dec.com> It is with a heavy heart that I announce that GIDNEY (KL10 2871, aka TOPS20.DEC.COM, aka GIDNEY.TOPS20.DEC.COM, IP 16.34.0.2) is leaving the Internet. GIDNEY and KL1026 are the last two 36-bit machines in MRO1 (DEC Marlboro), previously home to the Marlboro Computer Company. GIDNEY and KL1026 (actually 1042 with MF20) are used for corporate support and are being moved along with the remains of 36-bit manufacturing to NIO (Salem, NH). There are plans to bring up these two old systems in Salem at some point but it is a "low priority" thing. It seems that the powers-at-be have precious little room for engineering or manufacturing in Marlboro these days. KL1026 was the TOPS-10 development system. I used to use it often. It was a TRI-SMP system with KL1026, 1042, and 1322. KL1026 was actually the second KL10 system made, but many many parts were replaced in 1026 and 1042 by the dedicated souls in Field Service to keep KL1026 running. I used to use old KL1025 (first KL10) in the CPS lab for debugging CI20 dignostics, and even with the abuse it took, it always ran just great for me. It was fun to see Joe (the 2nd shift operator) run four BACKUP jobs on KL1026 running the RP06s and RA81s all jumping, the TU72s all spinning, and that big line of MH10s with flashing lights... until the MH10s (including "s/n proto" and "s/n bread") were upgraded to Ampex ARM-10LS. It had a bunch of RP06s ported between the three system's RH20s, their three front ends, and even an RH10. It had a CR20 card reader, TU56 DECtapes on a DT10, and a TX02 with a TU70, TU71, and 4 TU72s ported using a DX20 and a DX10. It also had a CP10 card punch which mad a very impressive noise when in use (admittedly not all that often). I was always referring people to the TU70 to read 7-track FAILSA tapes ("rewinds are not automatic"). GIDNEY was part of the TOPS-20 development cluster. GIDNEY replaced old KL2102, one of the first two orange KL10s, the origional TOPS-20 development system, which had horrible recurring hardware problems and finally was put to rest in the mid 1980s. GIDNEY's companion system was called CLOYD; everyone knew that the names came from Gidney and Cloyd, the two little space creatures from the space capsule in the "Rocky and Bullwinkle" TV show. GIDNEY was joined in a CFS-20 cluster by CLOYD (KL2866), RONCO ("Now how much would you pay?"), and THEP (named after The Prospector, a local watering hole favored by the TOPS-20 developers). At its peak GIDNEY had 12 RP06s, an AN20 (for GIDNEY), 3 DX20s, two TX02s, 4 TU73s (200 ips @ 6250), a TU72, 4 HSC50s and lots and lots of RA81s. About 5 years ago the old MRO1 "software lab" was shutdown. At this time, MRCHIP and MRDALE (our standalone cluster which was used for the famous CFS-20 demo at DECUS a number of years ago) was already scrapped. CLOYD, RONCO, THEP, 1026, and 1322 were sent to that great machine room in the sky (actually to MRO1-3 to be stripped and crushed). I remember when the whole lab was 36 bit systems; at this time there were mostly VAXen in there. As I sit here on my VS4000-60, I am amazed that that little box over there has 3 (or more depends who you ask) times the speed of that old KL10, lots more memory, and over 5 RP06s worth of storage. A lot of people love the TOPS-20 (and TOPS-10) operating systems. I do too, but I still love that old KL10 hardware. I'd like to think that the 36-bit people have spread the goodness of TOPS-10 and TOPS-20 around Digital; I know a lot of these lucky souls are still around, and every last one of them I talk to misses the old 36-bit software they used to work on in MRO1. Yes, I'd like to offer "belated goodbye" and farewell to CLOYD, RONCO, MRCHIP, MRDALE, and THEP. A "you deserved a rest" and farewell to 1026 and 1322. GIDNEY will not go easily into the night. In fact it crashed when I was entering this message the first time. Omens. No, I didn't look at the dump. GIDNEY, I hope I can get to you using TELNET or LAT in NIO (cause CTERM is really not so hot). It is not clear that NIO has IP, it being basically a manufacturing facility. GIDNEY, thanks for the good times and the good memories and for all of the stuff I learned from you. Greg Scott previously TOPS-20 engineering, previously DEC Marlboro. -------- 25-Sep-92 12:15:52-MDT,960;000000000000 Return-Path: Received: from mathom.xkl.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 25 Sep 92 12:15:48 MDT Date: Fri 25 Sep 92 11:12:57-PDT From: David K. Means Subject: Rumors of Death Greatly Exaggerated To: tops-20@wsmr-simtel20.army.mil Message-ID: <12816419124.18.MEANS@mathom.xkl.com> This note is quite tardy, but is elicited by recent notices to this mailing list. In July of 1991, a new (well, used) KL10 appeared on the Internet: MATHOM.XKL.COM. This machine is supporting the engineering effort now of about 10 folks who are busily engaged in designing a machine that will execute PDP-10 instructions. As with any system of its age, the KL hardware is more or less reliable, and the big troubles all stem from the RP07s that whir in the night. Nonetheless, MATHOM is alive and well in Redmond, WA, and expects to be so for the indefinite future. david means ------- 8-Oct-92 11:47:40-MDT,2756;000000000000 Mail-From: MRC created at 8-Oct-92 11:47:38 Return-Path: Received: from mc.lcs.mit.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 8 Oct 92 00:34:24 MDT Received: from mc by mc.lcs.mit.edu id aa05843; 7 Oct 92 21:12 EDT Received: from brazil.cambridge.apple.com by mc.lcs.mit.edu id aa05834; 7 Oct 92 21:11 EDT Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA00163; Wed, 7 Oct 92 21:14:25 -0400 for ITS-Lovers@mc.lcs.mit.edu Received: from dynamic-1.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef) id AA17970; Wed, 7 Oct 92 21:06:41 -0400 Message-Id: <9210080106.AA17970@cambridge.apple.com> Date: Wed, 07 Oct 92 18:54:44 EDT From: "David A. Moon" To: ITS-Lovers@mc.lcs.mit.edu Subject: Nostalgia ReSent-Date: Thu, 8 Oct 92 11:47:38 MDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@WSMR-SIMTEL20.ARMY.MIL ReSent-Message-ID: <12819822389.30.MRC@WSMR-SIMTEL20.ARMY.MIL> The Final SALV with sincere apologies to Archie Fisher for retargeting his song, and thanks to The Tannahill Weavers and to Garnet Rogers for reminding me what a great (and surely indestructible) song it is. It's been three long years Since we made it run, Heave away, my hackers oh! And we can't get by On that silly Sun. Sing haul 't away, my hackers oh! So now you boot it up For the final SALV Heave away, my hackers oh! It's an easy run For the disk is small. Sing haul 't away, my hackers oh! And then you take your disk, lad, And spin it down, Heave away, my hackers oh! And I'll flip the switch, lad, And shut 'er down. Sing haul 't away, my hackers oh! And then we'll join old AI And ML of yore, Heave away, my hackers oh! Sitting cold and silent On the false floor. Sing haul 't away, my hackers oh! For I'd rather dump her In the cans out back Heave away, my hackers oh! Than to see her run That Unix hack. Sing haul 't away, my hackers oh! Then when I die You can log me in Heave away, my hackers oh! To that DDT Where the altmodes spin. Sing haul 't away, my hackers oh! And then I'll make the haven Of Fiddlers' Green, Heave away, my hackers oh! Where the hardware works And the code is clean. Sing haul 't away, my hackers oh! For I've hacked a lifetime, Both man and boy Heave away, my hackers oh! And it's just no fun On that Unix toy. Sing haul 't away, my hackers oh! And it's been three long years Since we made it run, Heave away, my hackers oh! And we can't get by On that silly Sun. Sing haul 't away, my hackers oh! 8-Oct-92 13:59:48-MDT,1645;000000000000 Return-Path: Received: from FENCHURCH.MIT.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 8 Oct 92 13:59:45 MDT Received: by FENCHURCH.MIT.EDU id AA02482; Thu, 8 Oct 92 15:59:57 -0400 Reply-To: shawn@FENCHURCH.MIT.EDU Date: Thu, 8 Oct 92 15:59:55 EDT From: "Shawn F. Mckay" To: tops-20@wsmr-simtel20.army.mil Subject: DT.MIT.EDU Cc: admin-dt@FENCHURCH.MIT.EDU Message-Id: Howdy. We are still playing with Deep-Thought (Our 20/65 :-)), and trying to find a way to bring it up (without an RP06, though we do have two of them to play with doing this). But we are having some strange memory trouble that we are kindof running out of things to try with, so I wonder if I might ask a question? When the system is running KLI, it prints something like this: ... Normal KLI ... STARTING MF20 DBE SCAN. WAIT 25 SEC/256K. KLI -- % PHYSICAL MEMORY CONFIGURATION ALTERED - DUMP OR RESTART SUPPRESSED LOGICAL MEMORY CONFIGURATION ADDRESS SIZE INT TYPE CONTROLLER KLI - ? NO MEMORY AT LOCATION ZERO KLI - ENTER DIALOG .... We have swapped the MG20 we have for new boards, controller and all, also we swapped stuff in the cpu with no luck. What I am wondering is two fold: A) What ACTULLY causes this message, i.e. what ACTUAL test is failing? B) What are a list of things that might 'cause' this? (Perhaps we have missed something simple? Also, we the system does come back up, we wonder about TCP/IP, does anyone have a monitor that can use an interlan board + TCP/IP? Many Thanks, - Shawn 13-Oct-92 14:10:25-MDT,625;000000000000 Return-Path: Received: from Shiva.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 13 Oct 92 14:10:04 MDT Received: by Shiva.COM (1.34b) Tue, 13 Oct 92 16:09:41 EDT Date: Tue, 13 Oct 92 16:09:41 EDT From: Phil Budne Message-Id: <9210132009.AA06090@Shiva.COM> To: TOPS-20@wsmr-simtel20.army.mil Subject: TOPS-20 DECnet "NRT" server Cc: phil@Shiva.COM Can anyone tell me what the "status message" sequence of bytes a TOPS-10 or TOPS-20 system sends when you connect to it's NRT (pre-CTERM NVT protocol) server object (object 23)? Thanks! -Phil (missing 4 bits more than ever) 14-Oct-92 03:13:30-MDT,1089;000000000000 Return-Path: Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 14 Oct 92 03:13:24 MDT Received: by bsd.stupi.se (5.67/1.37) id AA02569; Wed, 14 Oct 92 10:13:33 +0100 Date: Wed, 14 Oct 92 10:13:33 MET From: Peter Lothberg To: Phil Budne Cc: TOPS-20@wsmr-simtel20.army.mil, phil@Shiva.COM Subject: Re: TOPS-20 DECnet "NRT" server In-Reply-To: Your message of Tue, 13 Oct 92 16:09:41 EDT Message-Id: > Can anyone tell me what the "status message" sequence of bytes a > TOPS-10 or TOPS-20 system sends when you connect to it's NRT > (pre-CTERM NVT protocol) server object (object 23)? > > Thanks! > -Phil > > (missing 4 bits more than ever) > ;The configuration message sent out when we accept a connect CFGLEN==10 ;BYTES IN CONFIG MESSAGE CFGMSG: BYTE(8) 1,1,0,0,11,0,10,0 ; Config--' ^ ^ ^ ^ ^ ^ ^ ; ? ? ? | ? | ? ; System=TOPS10----' | ; Protocol=TOPS20-------' -Peter 19-Oct-92 22:01:41-MDT,1768;000000000000 Mail-From: WANCHO created at 19-Oct-92 22:01:24 Date: Mon, 19 Oct 1992 22:01 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@WSMR-SIMTEL20.ARMY.MIL cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: Is Windows NT TOPS20 with a GUI? Of course not. But, on p. 170 of the October BYTE, in the article, "Windows NT Up Close," it says, in part: "NT aslo provides a feature that's in some versions of Unix, but not in OS/2: memory-mapped files. To use a memory-mapped file, you create a file-mapping object, which refers to a disk file, and creates a memory-mapped view of the file. Why bother? The view permits random memory-oriented access to the file's data--a major programming convenience. More important, memory-mapped files are NT's primary mechanism for sharing memory among processes. "Windows 3.x programs, running in a common address space, share memory by default. NT's more robust architecture, which isolates processes from one another, requires an explicit means of sharing. Memory-mapped files offer an interesting solution to the problem. One advantage over OS/2's shared-memory mechanism is that shared storage automatically persists in the form of the disk file that backs the mapped view. [...] "Both the NT loader and the cache manager that supports all the NT file systems are heavy users of the memory-mapped service." Hmmm. When and which versions of Unix support memory-mapped files? Are they really mapped or simply read into memory as a huge string? Are they like page-mapped files? If not, why not? Seems a step in the "right" direction... eventually reinventing a real operating system... in C... --Frank 20-Oct-92 07:22:17-MDT,3936;000000000000 Return-Path: Received: from amway.ch.apollo.hp.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Oct 92 07:21:54 MDT Received: from mapcar.ch.apollo.hp.com by amway.ch.apollo.hp.com id Tue, 20 Oct 92 09:09:46 EDT Received: by mapcar.ch.apollo.hp.com id ; Tue, 20 Oct 92 09:09:42 EDT From: mishkin@apollo.hp.com (Nathaniel Mishkin) Date: Tue, 20 Oct 92 09:09:41 EDT Subject: Re: Is Windows NT TOPS20 with a GUI? To: "Frank J. Wancho" Cc: TOPS20@WSMR-SIMTEL20.ARMY.MIL In-Reply-To: "Frank J. Wancho" , Mon, 19 Oct 1992 22:01 MDT Hmmm. When and which versions of Unix support memory-mapped files? Are they really mapped or simply read into memory as a huge string? Are they like page-mapped files? If not, why not? Seems a step in the "right" direction... eventually reinventing a real operating system... in C... 4.3bsd added the mmap() system call that may not have been universally implemented (but was on SunOS and Apollo DOMAIN) to map files into memory. At SunOS 4.0, I believe Sun modified the kernel to implement the stream I/O primitives--read(), write(), etc.--on disk file systems by using underlying VM mapping primitives. The Apollo DOMAIN kernel never supported stream I/O primitives, implementing them all instead in user-mode shared libraries which use underlying kernel mapping primitives (and page faults, of course). The DOMAIN kernel also doesn't know about pathnames and doesn't implement an open()-like system call nor does it have the concept of "open file descriptor". Pathnames are resolved in user-mode shared libraries into 64-bit unique ID (UIDs), which the "map" system call understands. (DOMAIN also doesn't have swap space--just application VA space mapped to temporary files in the regular file system--and diskless nodes are just nodes where every process's VA space is full of mappings to files that are remote and the only trick is getting the node booted 'cause everything else is just page fault processing, and...Whack! Sorry. I got out of control there.) There is a school of thinking--and one with which I'm at least slightly sympathetic--that says the "stream I/O over VM mapping" technique is a cute trick but probably not such a good idea. (I think Butler Lampson has expressed some pretty strong views in this area.) In DOMAIN anyway, we had to go through some fair amount of effort to make sure that the kernel did the right thing in terms of read-ahead and (write) flush-behind so that I/O runs sufficiently fast and the system's physical memory doesn't get filled up with stuff you'll never want again. I mean, you have some program that makes a nice clear statement--"read the next 4K bytes from this open file"--and on the way down to the kernel, the intent is lost and all the kernel sees is a page fault on mapped memory onto something and depending on whether the memory contains program code, program data, or a file being read sequential, it might want to do different things with. I guess we should be glad that--at least yet--no one has claimed that NT *invented* these idea. (Cutler isn't that dumb anyway.) But that's coming soon, I'm sure. But hey, why should I complain? The last two OS's I did systems hacking on were TOPS-20 and DOMAIN. UNIX? OK, I guess I used that too. It appears that, like TOPS-20 and DOMAIN, NT was designed. That's "designed, full stop". As opposed to UNIX (at least everything since v6). Are we TOPS-20 irredentists supposed to be happy or sad at the prospect of NT overwhelming UNIX? -- Nat Mishkin Distributed Computing Program Hewlett-Packard Company mishkin@apollo.hp.com ------- 20-Oct-92 09:23:47-MDT,1052;000000000000 Return-Path: Received: from Tomobiki-Cho.CAC.Washington.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Oct 92 09:23:31 MDT Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04054; Tue, 20 Oct 92 08:22:56 -0700 Date: Tue, 20 Oct 1992 08:21:55 -0700 (PDT) From: Mark Crispin Sender: Mark Crispin Subject: re: Is Windows NT TOPS20 with a GUI? To: "Frank J. Wancho" Cc: TOPS-20 Hackers and Yackers In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SunOS has memory mapping, as does Mach. It isn't as general or as useful as TOPS-20 memory mapping. A big disappointment with Mach on the NeXT is that shared writeable memory is disabled. 20-Oct-92 09:25:04-MDT,5554;000000000000 Return-Path: Received: from Sun.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 20 Oct 92 09:24:50 MDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15006; Tue, 20 Oct 92 08:24:45 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18667; Tue, 20 Oct 92 08:24:46 PDT Received: by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA10424; Tue, 20 Oct 92 08:19:23 PDT Date: Tue, 20 Oct 92 08:19:23 PDT From: Rob.Gingell@Eng.Sun.COM (Rob Gingell) Message-Id: <9210201519.AA10424@opus.Eng.Sun.COM> To: TOPS20@WSMR-SIMTEL20.ARMY.MIL Subject: Re: Is Windows NT TOPS20 with a GUI? Cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL >Hmmm. When and which versions of Unix support memory-mapped files? >Are they really mapped or simply read into memory as a huge string? >Are they like page-mapped files? SunOS 4.0 (and all that follow, of course) supports memory mapped files a la TENEX/TOPS-20. The paper that described the system (Summer '87 USENIX) attempts to make clear that the inspiration for how it played out was TENEX/TOPS-20. It's not exactly the same in all respects, but in the fundamental aspects of integrating the file/process address spaces it's nearly indistinguishable: even down to the use of "window" pages inside the kernel for the implementation of read() and write(). Since the SVR4 VM system is simply the SunOS one, the use of this model is pretty much pervasive in the UNIX world. There are probably upwards of 1 million machines running it at this point. Not bad for ideas from a "dead" OS, huh? SunOS was hardly the first UNIX implementation to do offer such a facility. But it and its SVR4 decendents seem to have displaced what alternatives that exist such that (even if the internals are different) everyone implements mmap() with much the same semantics as SunOS first did. The basic interfaces to the system (mmap() ~ == PMAP%) were specified for BSD UNIX in the late 70's/early 80's. The specific influence even at that time was TENEX/TOPS-20, as the demands for such services came from the DARPA community who were looking for UNIX on VAXen as a way to get more research out of a larger community, many of whom could not afford PDP-10's. Although Berkeley never got around to implementing the interface (until the soon to be released 4.4), the basic framework was laid for a very similar system. However, the precise semantics were ill-defined, a number of operational characteristics hadn't yet been thought through, etc. When we began to implement the SunOS VM system in 1986, we refined the interfaces slightly and extended them to deal with things learned over the years. One of these was the creation of the msync() interface, for which the specific influence was the experience with CFS-20 that created a "higher-level" protocol for managing access to pages of directories to avoid network thrashing of pages. Other differences and extensions came from the fact that we were trying to make this effective in a world where there were networks of machines, not all of which would support the exact same semantics, or even a common page size. However, with respect to the single-system integration of the file system and process address space, the system looks more like TOPS-20 than anything remotely like "traditional UNIX." And, it's hardly an "add-on", the system was rewritten at most fundamental levels around the notions implied by the TENEX/TOPS-20 memory model. I think this is mostly why the SunOS model has been successful, previous attempts to implement mmap() tried to build upon primitives like read()/write() or otherwise represent an add-on to the system. Thus, their behaviors were quirky and incomplete. By being willing to throw away what we had to gain uniform behaviors, we gained implementation efficiency and elegance, as well as a "no surprise" kind of interface. Users of PMAP% should feel quite at home with it. Are we reinventing TOPS-20 out of SunOS? No, not hardly. There are some ideas that didn't work well in TENEX/TOPS-10/20 that are not, in my opinion, worth stealing. There are good ideas that might be worth stealing if there was a suitable context within which to steal them -- but some design decisions have been preempted by the UNIX history that's been inherited and others just don't seem to fit as solutions to the views of customer problems we have today. For example, at one time I would have advocated a COMND%-like facility -- the trouble is, most of our customers don't need or even want a better terminal interface. If only someone could figure out the COMND% paradigm for GUI's...by which I mean that the qualities of the design (uniformity with respect to completion, abbreviation, error recovery, and the like) could be manifested with the grace that COMND% and its predecessors provided for the terminal interface. Perhaps a more important idea I'd like to see carry forward is the single mechanism for naming provided by GTJFN%. I think we'll ultimately see that reborn in environments of the future, but it'll be manifested in some form of network-aware naming facility that works as part of a general "object-oriented*" environment for programs and as such will require the corresponding paradigm shift for the bulk of programs to take advantage of it. Thus, we won't see it happen "soon." Ah, what a pleasant way to reminisce early in the morning. Thanks for providing the opportunity Frank. 21-Oct-92 16:28:41-MDT,727;000000000000 Return-Path: Received: from inet-gw-1.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 21 Oct 92 16:26:38 MDT Received: by inet-gw-1.pa.dec.com; id AA26887; Wed, 21 Oct 92 15:24:00 -0700 Received: by zowie.zso.dec.com (5.57/fma-100391);id AA19060; Wed, 21 Oct 92 15:23:49 -0700 Date: Wed, 21 Oct 92 15:23:48 PDT From: Hans Ridder To: tops-20@wsmr-simtel20.army.mil Subject: Re: Subscribe Message-Id: I realized (probably a bit to late) that I made the classical blunder of sending a subscription request to the list. I might have caught it in time, but probably not. Sorry for the noise (and this noise too.) -hans 12-Nov-92 19:23:30-MST,7147;000000000000 Return-Path: Received: from turtle.mcc.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 12 Nov 92 19:23:11 MST Received: from stone.mcc.com by turtle.mcc.com (4.1/isd-master_920825_x) id AA03931; Thu, 12 Nov 92 20:22:52 CST Received: by stone.mcc.com (5.65/isd-other_920825_17:05) id AA06015; Thu, 12 Nov 1992 20:22:38 -0600 Date: Thu, 12 Nov 92 20:22:36 CST From: Clive Dawson To: tops-20@wsmr-simtel20.army.mil Subject: The History of Unix - A Sordid Life Story Message-Id: FYAmusement...I didn't realize what Unix had been through. Perhaps I should be more tolerant and understanding. Enjoy, Clive (I was sent this, author is unknown) ------------------------------------------------------------------------------ The history of Unix: A sordid life story... Unix was a program gone bad. Born into poverty, its parents, the phone company, couldn't afford more than a roll of teletype paper a year, so Unix never had decent documentation and its source files had to go without any comments whatsoever. Year after year, Papa Bell would humiliate itself asking for rate increases so that it could feed its child. Still, Unix had to go to school with only two and three letter command names because the phone company just couldn't afford any better. At school, the other operating systems with real command names, and even command completion, would taunt poor little Unix for not having any job or terminal management facilities or for having to use its file system for interprocess communication and locking. Then, bitter and emasculated by its poverty, the phone company began to drink. During lost weekends of drunken excess, it would brutally beat poor little Unix about the face and neck. Eventually, Unix ran away from home. Soon it was living on the streets of Berkeley. There, Unix got involved with a bad crowd. Its life became a degrading journey of drugs and debauchery. To keep itself alive, it sold cheap source licenses for itself to universities which used it for medical experiments. Being wantonly hacked by an endless stream of nameless, faceless undergraduates, both men and women, often by more than one at the same time, Unix fell into a hell-hole of depravity. And so it was that poor little Unix began to go insane. It retreated steadily into a dreamworld, the only place where it felt safe. It took heroin and dreamed of being a real operating system. It took LSD and dreamed of being a raspberry flavored three-toed yak. It liked that better. As Unix became increasingly attracted to LSD, it would spend weekends reading Hunter Thompson and taking cocktails of acid and speed while writing crazed poetry in which it found deep meaning but which no one else could understand: $sed <$mf >$mf.new -e '1,/^# AUTOMATICALLY/!d' make shlist || ($echo "Searching for .SH files..."; \ $echo *.SH | $tr ' ' '\012' | $egrep -v '\*' >.shlist) if $test -s .deptmp; then for file in `cat .shlist`; do $echo `$expr X$file : 'X\(.*\).SH'`: $file config.sh \; \ /bin/sh $file >> .deptmp done $echo "Updating $mf..." $echo "# If this runs make out of memory, delete /usr/include lines." \ >> $mf.new $sed 's|^\(.*\.o:\) *\(.*/.*\.c\) *$|\1 \2; '"$defrule \2|" .deptmp \ >>$mf.new else make hlist || ($echo "Searching for .h files..."; \ $echo *.h | $tr ' ' '\012' | $egrep -v '\*' >.hlist) $echo "You don't seem to have a proper C preprocessor. Using grep instead." $egrep '^#include ' `cat .clist` `cat .hlist` >.deptmp $echo "Updating $mf..." <.clist $sed -n \ -e '/\//{' \ -e 's|^\(.*\)/\(.*\)\.c|\2.o: \1/\2.c; '"$defrule \1/\2.c|p" \ -e d \ -e '}' \ -e 's|^\(.*\)\.c|\1.o: \1.c|p' >> $mf.new <.hlist $sed -n 's|\(.*/\)\(.*\)|s= \2= \1\2=|p' >.hsed <.deptmp $sed -n 's|c:#include "\(.*\)".*$|o: \1|p' | \ $sed 's|^[^;]*/||' | \ $sed -f .hsed >> $mf.new <.deptmp $sed -n 's|c:#include <\(.*\)>.*$|o: /usr/include/\1|p' \ >> $mf.new <.deptmp $sed -n 's|h:#include "\(.*\)".*$|h: \1|p' | \ $sed -f .hsed >> $mf.new <.deptmp $sed -n 's|h:#include <\(.*\)>.*$|h: /usr/include/\1|p' \ >> $mf.new for file in `$cat .shlist`; do $echo `$expr X$file : 'X\(.*\).SH'`: $file config.sh \; \ /bin/sh $file >> $mf.new done fi Eventually, Unix began walking down Telegraph Avenue talking to itself, saying "Panic: freeing free inode," over and over again. Sometimes it would accost perfect strangers and yell "Bus error (core dumped)!" or "UNEXPECTED INCONSISTENCY: RUN FSCK MANUALLY!" at them in a high pitched squeal like a chihuaua with amphetamine psychosis. Upstanding citizens pretended it was invisible. Mothers with children crossed to the other side of the street. Then one evening Unix watched television, an event which would change its life. There it discovered professional wrestling and knew that it had found its true calling. It began to take huge doses of corticosteroids to build itself up even bigger than the biggest of the programs which had beaten it up as a child. It ate three dozen pancakes and four dozen new features for breakfast each day. As the complications of the steroids grew worse, its internal organs grew to the point where Unix could no longer contain them. First the kernel grew, then the C library, then the number of daemons. Soon one of its window systems was requiring two megabytes of swap space for each open window. Unix began to bulge in strange, unflattering places. But Unix continued to take the drugs and its internal organs continued to grow. They grew out its ears and nostrils. They placed incredible stresses on Unix's brain until it finally liquefied under pressure. Soon Unix had the mass of Andre the Giant, the body of the Elephant Man, and the mind of a forgotten Jack Nicholson character. The worst strain was on Unix's mind. Unable to assimilate all the conflicting patchworks of features it had ingested, its personality began to fragment into millions of distinct, incompatible operating systems. People would cautiously say "good morning Unix. And who are we today?" and it would reply "Beastie" (BSD), or "Domain", or "I'm System III, but I'll be System V tomorrow." Psychiatrists labored for years to weld together the two major poles of Unix's personality, "Beasty Boy", an inner-city youth from Berkeley, and "Belle", a southern transvestite who wanted a to be a woman. With each attempt, the two poles would mutate, like psychotic retroviruses, leaving their union a worthless blob of protoplasm requiring constant life support to remain compatible with its parent personalities. Finally, unbalanced by its own cancerous growth, Unix fell into a vat of toxic radioactive wombat waste, from which it emerged, skin white and hair green. With a horrible grin on its face, it set out to conquer the world. ------- 13-Nov-92 08:25:25-MST,581;000000000000 Return-Path: Received: from epilogue.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 13 Nov 92 08:25:19 MST From: Rob Austein Sender: sra@epilogue.com To: Clive Dawson CC: tops-20@wsmr-simtel20.army.mil In-reply-to: Clive Dawson's message of Thu, 12 Nov 92 20:22:36 CST Subject: The History of Unix - A Sordid Life Story Date: Fri, 13 Nov 92 10:24:59 EST Message-ID: <9211131025.aa20843@quern.epilogue.com> That piece was written by Ian Horswill . --Rob 18-Nov-92 09:18:42-MST,1416;000000000000 Return-Path: Received: from ccr2.bbn.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Nov 92 09:18:32 MST Date: Wed, 18 Nov 92 11:17 EDT From: JERRY WEINER BBN 617-873-3242 Subject: NETWORK problems with NI20 To: tops-20@wsmr-simtel20.army.mil X-VMS-To: @TOPS Folks, I am having the following random Network problem. We have two DEC-20's in a cluster. (it being a cluster has nothing to do with the network problem). The network "goes away". DECNET, TCP/IP, and LAT stop. The console works and any DH lines work. Looking at the ETHERNET counters with IPHOST ETH Status command will show a negative number of read errors (it probably overflows the counter in the NI-20) or NCP Show Line/Circuit Counters will show >65xxx read errors. The DEC-20 is still sending data out. I have two reasons to believe this. On LAT terminals services the service keeps getting announced. We also have an IP program on teh DEC-20 that sends a packet every 30 seconds to a system that monitors many systems. It continues to receive packets. It almost looks like the NI20 shuts down receiving packets. The problem has happened three times on one system and one time on the other. None of the occurances happen at the same time. One time we got a LATNSC Bugchk. Anyone seen a problem like this or have any suggestions? Thanx, Jerry Weiner 24-Nov-92 14:24:30-MST,1071;000000000000 Return-Path: Received: from sandpiper.wesleyan.edu by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 24 Nov 92 14:24:08 MST Received: by sandpiper.wesleyan.edu (5.61/1.35) id AA08683; Tue, 24 Nov 92 13:03:42 -0500 Date: Tue, 24 Nov 92 13:03:42 -0500 Message-Id: <9211241803.AA08683@sandpiper.wesleyan.edu> From: Douglas Bigelow To: tops20@wsmr-simtel20.army.mil Subject: DECSYSTEM-20 energy consumption Greetings, all; I need to figure out how much our DEC-20 is costing Wesleyan in energy costs. It's a 2MW 2060 with three RP07s and an RP06, two TU78s and a 1200 LPM line printer. I'm looking for estimates for KW consumption first, and heat output second so I can guess at air conditioning costs. If anyone has some of these figures around (rough guesses are fine) I'd much appreciate it. Alternately, if you've ever estimated a DEC-20's energy costs for your own site, I'd love to hear your figures. Thanks... Doug Bigelow Director of Academic Computing, Wesleyan University 25-Nov-92 03:15:26-MST,942;000000000000 Return-Path: Received: from regal.cisco.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 25 Nov 92 03:15:16 MST Received: by regal.cisco.com; Wed, 25 Nov 92 02:14:54 -0800 Date: Wed, 25 Nov 92 2:14:54 PST From: William "Chops" Westfield To: Douglas Bigelow Cc: tops20@wsmr-simtel20.army.mil Subject: Re: DECSYSTEM-20 energy consumption In-Reply-To: Your message of Tue, 24 Nov 92 13:03:42 -0500 Message-Id: Compuserve, at one time, would sell you a switching power supply conversion for your dec20 (replace the 30% linear supplies with 85% efficient modern switchers - save big bucks.) As part of the "marketing" literature for this conversion, they included some estimates of how much you could save, based on the consumption of each version - I'll see if I can find the literature somwhere... BillW 25-Nov-92 11:57:49-MST,1228;000000000000 Return-Path: Received: from devon.xkl.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 25 Nov 92 11:57:37 MST Received: by devon.xkl.com (5.64/1.34) id AA15332; Wed, 25 Nov 92 11:04:31 -0800 (PST) Date: Wed, 25 Nov 92 11:04:31 -0800 (PST) From: means@devon.xkl.com (David Means) Message-Id: <9211251904.AA15332@devon.xkl.com> To: dbigelow@sandpiper.WESLEYAN.EDU Cc: tops20@wsmr-simtel20.ARMY.MIL In-Reply-To: Douglas Bigelow's message of Tue, 24 Nov 92 13:03:42 -0500 <9211241803.AA08683@sandpiper.wesleyan.edu> Subject: DECSYSTEM-20 energy consumption My configuration is a little different: 5 RP07s and 2RP06s and no lineprinter. It draws 20KW, according to the power distribution unit meter. This configuration keeps a 7.5 ton air conditioner busy (we have 12.5 in 2 units; one runs nearly continuously, the other takes up the slack). If you find that the cost is outrageous (our total electrical bill is about $1400/mo, which covers all uses in an office of 15), help is on the way. Our machine is being used to design its replacement; we hope to have the first units out sometime in '93. They are targeted to consume about 1KW. david means XKL Systems Corp. 25-Nov-92 18:44:34-MST,1157;000000000000 Return-Path: Received: from ULLA.FORNAX.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 25 Nov 92 18:44:31 MST Date: Thu, 26 Nov 1992 02:43:59 +0200 (MET) From: Joe Dempster Subject: Re: DECSYSTEM-20 energy consumption To: dbigelow@sandpiper.wesleyan.edu Cc: tops20@wsmr-simtel20.army.mil Message-ID: <722738639.370000.DEMPSTER@ULLA.FORNAX.COM> In-Reply-To: <9211241803.AA08683@sandpiper.wesleyan.edu> Mail-System-Version: I think you should consider the Compuserve power supply upgrade, it will save you about 1/3 the power consumption of the KL and a corresponding decrease in AC. If you are really serious about "conservation" and have a high pain threshold, talk to Mike Levitt at SC Group in Reno NV. They have both a RH20 board for a SCSI disk and tape. You will only need a RP06 for the FE. DEC will support the power supply, never the SCSI stuff, but then it usually never breaks. You might also approach the XKL people in Seattle, they might want to cultivate a EDU site for their new system with a big discount. /joe 1-Dec-92 13:28:40-MST,969;000000000000 Return-Path: Received: from relay1.UU.NET by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 1 Dec 92 13:28:32 MST Received: from lysator.liu.se by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29448; Mon, 30 Nov 92 14:24:47 -0500 Received: by lysator.liu.se (5.65c8/1.34/Lysator-3.1) id AA15185; Mon, 30 Nov 1992 20:21:58 +0100 (rfc931-sender: pell@lysator.liu.se) Date: Mon, 30 Nov 1992 20:21:58 +0100 From: pell@lysator.liu.se (P{r Emanuelsson) Message-Id: <199211301921.AA15185@lysator.liu.se> To: tops20%wsmr-simtel20.army.mil@relay2.uu.net Subject: Strange request... Hi. Anyone got a microcode assembler for the KS10? I'm also looking for the source to ITS. Is it available for FTP from somewhere? Further, I'd like to setup an FTP dir for "harder, low-level" stuff, like the assembler above. Please get in touch with me if you have something that might be useful. Thanks /Pell 2-Dec-92 09:25:14-MST,957;000000000000 Return-Path: Received: from epilogue.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 2 Dec 92 09:25:10 MST From: Rob Austein Sender: sra@epilogue.com To: P{r Emanuelsson CC: tops20@wsmr-simtel20.army.mil In-reply-to: P{r Emanuelsson's message of Mon, 30 Nov 1992 20:21:58 +0100 <199211301921.AA15185@lysator.liu.se> Subject: KS-10 microcode assembler and ITS sources Date: Wed, 2 Dec 92 11:23:51 EST Message-ID: <9212021124.aa21720@quern.epilogue.com> The entire ITS filesystems of AI and MC are archived and available for anonymous FTP from mc.lcs.mit.edu:/its/. If you really want the entire thing you might want to talk to Peter Lothberg first, he's probably got local copies on your side of the pond. Low-level ITS KS-10 programs like the microcode assembler used to live in AI: KSHACK;, so they're now in mc.lcs.mit.edu:/its/ai/kshack/. --Rob Austein 2-Dec-92 15:29:25-MST,1652;000000000000 Return-Path: Received: from Tomobiki-Cho.CAC.Washington.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 2 Dec 92 15:29:21 MST Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA01248; Wed, 2 Dec 92 12:58:56 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00358; Wed, 2 Dec 92 12:57:37 -0800 Date: Wed, 2 Dec 1992 12:45:31 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: re: Strange request... To: P{r Emanuelsson Cc: TOPS-20 Hackers and Yackers In-Reply-To: <199211301921.AA15185@lysator.liu.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 30 Nov 1992 20:21:58 +0100, P{r Emanuelsson wrote: > Hi. Anyone got a microcode assembler for the KS10? I have a copy of MICRO.MAC for the KS10. It's 116,333 characters. I also have the KS10 microcode checker (58,659 characters). I don't see any copyright notices on these, so it's probably alright to give them to you. They're online on Yuuyuu, so they'll have to be kermited or e-mailed to get them to you. > Further, I'd like to setup an FTP dir for "harder, low-level" stuff, like > the assembler above. Please get in touch with me if you have something that > might be useful. I don't know if DEC would care about this any more, but they might if things like TOPS-10/20 or microcode sources were there. 4-Dec-92 10:27:38-MST,680;000000000000 Return-Path: Received: from fernwood.mpk.ca.us by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 4 Dec 92 10:27:32 MST Received: by fernwood.mpk.ca.us; id AA26556; Fri, 4 Dec 92 09:29:23 -0800 Received: by nw.com (UUPC/extended 1.11p); Fri, 04 Dec 1992 09:24:27 PST Date: Fri, 04 Dec 1992 09:24:26 PST From: "Mark Lottor" Message-Id: <2b1f944b.nw@nw.com> To: tops-20@wsmr-simtel20.army.mil Subject: hardware flow control Hi - What's the deal with getting bidirectional RTS/CTS flow control on our DEC20? (please no terminal server suggestions). We want to hook up some 9600 baud modems to it. -mkl 7-Dec-92 10:52:12-MST,1608;000000000000 Return-Path: Received: from inet-gw-1.pa.dec.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 7 Dec 92 10:52:00 MST Received: by inet-gw-1.pa.dec.com; id AA02429; Mon, 7 Dec 92 09:51:40 -0800 Received: by zowie.zso.dec.com (5.57/fma-100391); id AA07900; Mon, 7 Dec 92 09:51:30 -0800 Date: Mon, 7 Dec 92 9:51:29 PST From: Hans Ridder To: "Mark Lottor" Cc: tops-20@wsmr-simtel20.army.mil Subject: Re: hardware flow control In-Reply-To: Your message of Fri, 04 Dec 1992 09:24:26 PST Message-Id: > What's the deal with getting bidirectional RTS/CTS flow control on >our DEC20? (please no terminal server suggestions). We want to hook up >some 9600 baud modems to it. Don't worry, I wasn't going to suggest a terminal server. Unless things have changed, *our* terminal servers don't allow you to have "modem control" and "RTS/CTS flow control" enabled at the same time. All the modem control is handled by RSX-20F in the front-end (assuming you're talking about a KL.) As I remember, the FE raises and lowers RTS at the same time as DTR. I don't recall exactly how it treats CTS. It's possible that -20F already handles it as a "flow control" signal. In any case, it would require a patch to RSX-20F (a listing for the version you're running helps alot.) You'd also have to come up with a spare bit somewhere in the "queued protocol" to enable RTS/CTS flow control, and some code for TOPS-20 (the easy part!) It's certainly doable, but not alot of fun. >-mkl -hans 7-Dec-92 12:16:23-MST,1704;000000000000 Return-Path: Received: from Tomobiki-Cho.CAC.Washington.EDU by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 7 Dec 92 12:16:17 MST Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA07633; Mon, 7 Dec 92 11:16:07 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA08987; Mon, 7 Dec 92 11:15:59 -0800 Date: Mon, 7 Dec 1992 11:09:35 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: re: hardware flow control To: Mark Lottor Cc: tops-20@wsmr-simtel20.army.mil In-Reply-To: <2b1f944b.nw@nw.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 04 Dec 1992 09:24:26 PST, Mark Lottor wrote: > What's the deal with getting bidirectional RTS/CTS flow control on > our DEC20? (please no terminal server suggestions). We want to hook up > some 9600 baud modems to it. On a KS10 CPU, it is impossible. The DZ11 hardware does not support these signals. You will have all sorts of fun and laughter trying to get a 9600 baud modem to work reasonably on a KS10. Believe me, I know. It may be possible on a KL10. I am not sure whether or not a DH11 (or one of the many clones) can support CTS/RTS signals. However, you have to face all the joy and rapture of hacking RSX-20F, since there RSX does not support it. DEC was SPR'd on the question a few years ago and they laughed at it. I know you don't want to hear it, but a terminal server is probably your best bet. 8-Dec-92 06:31:37-MST,1313;000000000000 Return-Path: Received: from bsd.stupi.se by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 8 Dec 92 06:31:27 MST Received: by bsd.stupi.se (5.67/1.37) id AA00744; Tue, 8 Dec 92 14:21:55 +0100 Date: Tue, 8 Dec 92 14:21:55 MET From: Peter Lothberg To: Mark Crispin Cc: Mark Lottor , tops-20@wsmr-simtel20.army.mil Subject: re: hardware flow control In-Reply-To: Your message of Mon, 7 Dec 1992 11:09:35 -0800 (PST) Message-Id: > On Fri, 04 Dec 1992 09:24:26 PST, Mark Lottor wrote: > > What's the deal with getting bidirectional RTS/CTS flow control on > > our DEC20? (please no terminal server suggestions). We want to hook up > > some 9600 baud modems to it. > > On a KS10 CPU, it is impossible. The DZ11 hardware does not support these > signals. You will have all sorts of fun and laughter trying to get a 9600 > baud modem to work reasonably on a KS10. Believe me, I know. If you baadly needs this, i suggest a hardware patch to AND the uart transmitter buffer empty flag pin with your favorite handshake signal.. Atleast it takes less time than fixing RSX20F... (If someone needs this for a DN87/T10 frontend, I have the patch, but's that not RSX20f...) -Peter 14-Dec-92 13:16:29-MST,508;000000000000 Return-Path: Received: from sunl.cr.usgs.gov by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 14 Dec 1992 13:16:23 -0700 (MST) Received: from dgg.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2) id AA21360; Mon, 14 Dec 92 14:11:57 CST Received: by dgg.cr.usgs.gov (5.4.1/1.34) id AA00870; Mon, 14 Dec 1992 14:16:01 -0600 Date: Mon, 14 Dec 1992 14:16:01 -0600 From: bodoh@dgg.cr.usgs.gov Message-Id: <9212142016.AA00870@dgg.cr.usgs.gov> To: tops20@wsmr-simtel20.army.mil SUBSCRIBE 26-Dec-92 21:38:41-MST,1791;000000000000 Return-Path: Received: from uu3.psi.com by WSMR-SIMTEL20.ARMY.MIL with TCP; Sat, 26 Dec 1992 21:38:34 -0700 (MST) Received: from ceb486.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA10644; Sat, 26 Dec 92 23:24:31 -0500 Received: from ceb486.UUCP by pulse.com (4.1/SMI-4.1) id AA20348; Sat, 26 Dec 92 23:23:31 EST From: "C. E. Brooks" X-Mailer: SCO System V Mail (version 3.2) To: its-lovers@mc.lcs.mit.edu, tops-20@wsmr-simtel20.army.mil Subject: Add "charlesb@software.pulse.com" to mail list Cc: charlesb@software.pulse.com Return-Receipt-To: charlesb@software.pulse.com Date: Sat, 26 Dec 92 23:15:44 EST Message-Id: <9212262315.aa05034@ceb486.ceb486.UUCP> Folks, Please add me to the ITS and TOPS-20 mailing lists. I have fond memories of the Maynard MFG Data (my system was in the Mill) where I first worked on PDP-10s for In-House Field Service. I left DEC to work at BBN since DEC decided that FS folks did not need to know what the OS software was doing. At BBN I performed KA-to-TENEX two upgrades, installing the cpu mods and the BBN pager (the last may have been the final upgrade ordered by the government). While at BBN I built and delivered the second generation of IMP-10 interfaces for Wharton, LBL, and several internal systems. Later I worked for DEC at Marlboro in LCG CSSE on TOPS-10, TOPS-20, and DECNET field tests. I was a member of the Jupiter project and present for KO's annoucement of its demise (shortly followed by the entire 36 bit product line). I am very interested in the existence of any PDP-10/20 instruction set simulators or emulators that run in either a Unix environment (SPARC or SCO Unix) or a DOS/Windows environment. /ceb\