Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 10 Mar 87 00:44:05 EST Received: by eneevax.umd.edu (5.9/4.7) id AA13924; Tue, 10 Mar 87 00:41:36 EST Date: Tue, 10 Mar 87 00:41:36 EST From: Douglas Humphrey Message-Id: <8703100541.AA13924@eneevax.umd.edu> To: BUG-ITS@AI.AI.MIT.EDU, BUG-KS@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Subject: Re: MD has internal troubles RP06 Disk drives are selling for less than the $500 that you state it will take to fix the existing drive. Has someone contacted used hardware places in the Boston area (to save shipping charges) to see if they will either sell or donate an RP06 or two ? I will note that a place in Atlanta just had several Hundred RP06 drives sent to a scrapper for cents per pound because there is no market for them any longer. Doug  Date: Mon, 9 Mar 87 00:36:27 EST From: "Pandora B. Berman" Subject: MD has internal troubles To: BUG-KS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <165407.870309.CENT@AI.AI.MIT.EDU> (remailed for the record) Date: Fri, 6 Mar 87 16:00 EST From: Alan Bawden Subject: MD Well, head 7 on MD's RP06 is deteriorating fast. JTW just tried cleaning the heads, but it doesn't look like that helped the problem. I'm considering taking ITS down so as to not risk damage to the filesystem. This drive is not on service contract, and neither AI nor presumably LCS has any real interest in paying to get it fixed. It cost about 500 bucks to get this fixed when it happened to one of AI's drives. [ CStacy broke the UNLOCK routine in the Salvager, by the way... ]  Date: Tue, 3 Feb 87 02:51:19 EST From: "David A. Moon" Subject: microcode 262 To: BUG-KS@AI.AI.MIT.EDU Message-ID: <148442.870203.MOON@AI.AI.MIT.EDU> I installed microcode 262 on all 4 KS machines at MIT and rebooted AI and MC. Alan asked me not to reboot ML, since it was going for an uptime record, so it's still running microcode 261, but has microcode 262 on its disk for the next time it boots. I arranged for the next microcode assembly to produce 263 and for the next boot tape to get 262. Change history is in AI: KSHACK; KS10 >.  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JAN 87 15:01:45 EST Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19480; Mon 26-Jan-87 15:03:06 EST Date: Mon, 26 Jan 87 15:03 EST From: Alan Bawden Subject: IAP To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870126150304.6.ALAN@KAREN.AI.MIT.EDU> Despite the fact that in the IAP guide I promised four sessions of the ITS course, there will -not- be a fourth session this week. See you all again next year!  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 16 Jan 87 04:17:47 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715239312833556@MIT-MULTICS.ARPA>; 16 Jan 1987 04:08:32 est Message-ID: <227734@QZCOM> In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Date: 16 Jan 87 01:07 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: IAP If someone has a home-video-tape-recorder-and-camera-set at MIT availible, it wold be nice to have a vide tape of the lecture, for us that can't show up.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JAN 87 15:29:36 EST Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 15 Jan 87 15:21-EST Date: Thu, 15 Jan 87 15:23 EST From: Alan Bawden Subject: IAP To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Those of you who missed the second session of the ITS course last night should be aware that next week we will once again meet on -Wednesday-. It seems I screwed up when I thought we couldn't have the playroom this Tuesday, and it is actually -next- Tuesday than has the conflict. Next Wednesday we'll do something about Job Devices. How to write one, or how they are implemented, or something like that...  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 13 Jan 87 19:30:47 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715034469904800@MIT-MULTICS.ARPA>; 13 Jan 1987 19:14:29 est Message-ID: <226852@QZCOM> In-Reply-To: <8701110440.AA09182@eneevax.umd.edu> Date: 13 Jan 87 17:46 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Alan Bawden" , "John Wroclawski" , KS-ITS@AI.AI.MIT.EDU Subject: Re: 2020 spare parts The RM0X "DEC-adaptor" talks SMD in one end, and Masbus in the other. On a 2020 the RH11-c talks 18 bits to the disk, so a emulex board is no good, becouse you only get 16 bits of data. If you replaces the rm0x drive with an eagle drive (keeping the masbus-smd controler) you have to make the controler count 63 sectors/revolution. That is not easy, and the data rate is 23MHz instead of 10Mhz, so some might run and others not. Whats needed is a controler talking XMD/Eagle bus in one end and emulates the RH11-c in 18 bit mode. I don't knew of any pirate device that can do that.  Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 10 Jan 87 23:43:49 EST Received: by eneevax.umd.edu (5.9/4.7) id AA09182; Sat, 10 Jan 87 23:40:33 EST Date: Sat, 10 Jan 87 23:40:33 EST From: Douglas Humphrey Message-Id: <8701110440.AA09182@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, JTW%MIT-SPEECH@XX.LCS.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: Re: 2020 spare parts In most cases swapping RP06s for RP04s is easy to do, and then you can throw the RP04s away (if you think RP06s are worthless, you should see whats little RP04s are worth). They will give you a lot more disk space for the same footprint, heat, etc. All of these are Massbus devices, so there should be no trouble. I will talk to the guy who owns the company that I deal with on these things, and see what they might think about 'donating' somce RP06s to MIT. Transportation is the only real problem. Shipping them costs around 250-300 dollars each I think (thats what it costs for big heavy tape drives from Atlanta to Washington.) but it could be more. You can do what I am doing with my 2020, which is declare a 'road-trip' and fly down to Atlanta, rent a truck and drive them back to save some bucks. If you just wanted to have them 'donate' the hardware and then scrap them out for parts in Atlanta, and ship up the resulting spares kits, that would cost relativly little. Concerning disks on 2020's I have been wondering for a while if there would not be a way to use more compact disks on the systems without a lot of hacking to do it. We just picked up a bunch of Fuji 2284 and Eagle drives at work for some vaxen and the remaining PDP-11s that are around. The 2284 has 160megs (emulates 2 RM03 drives) and uses the SMD interface. Does the RH11 Massbus controller that DEC uses have a special 18/36 bit mode that it uses on the 2020, or would there be a way to use an Emulex SC21-B1 SMD controller and a Fuji drive on a 2020, rather than the big, bulks, balky RH11/RM03 combination ? Since the 2284 takes up 10.5 inches of rack space vs. 2 RM03s, it would be a very big win. In this same like of thought, there are some unibus SCSI adapters around. Why not put some 5.25 inch hard disks on it, and mount them in the bottom of the 2020 itself. Then it would really be Kloset Sized - 10! Doug  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JAN 87 21:05:06 EST Date: Sat 10 Jan 87 21:02:48-EST From: "John Wroclawski" Subject: Re: 2020 spare parts To: ALAN@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <136701.870105.ALAN@AI.AI.MIT.EDU> Message-ID: <12269934420.35.JTW@MIT-SPEECH> If I had a spare RP06 or two I'd put it on the 9th floor in place of some MX drives that have been declared dead. I might connect it to MX instead of the RP04's, too, but then again I might not know what I'm talking about. In the absence of serious inspiration on someone's part, we are stuck with the damn RP06's. It is also clear that with the exception of AI noone really wants to pay to fix em. I think that if almost-free spares are available we should at least get a couple and strip them for boards and heads and such. There are a lot of things that we can fix trivially if we have the parts (MC last month, for instance.) -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JAN 87 16:52:54 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 17414; Wed 7-Jan-87 16:50:47 EST Date: Wed, 7 Jan 87 16:50 EST From: Alan Bawden Subject: IAP To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU> Those of you who missed the first session of the ITS course last night should be aware that next week we will meet on -Wednesday- instead of Tuesday. The following week we will go back to meeting on Tuesdays. (All meetings are in the 7th floor playroom at 7:30). Next Wednesday we will hear a bit about the ITS filesystem (not all that much to tell) and then Ed Schwalenberg will tell us about "CAMEXEC: An ITS-style Operating System for PDP11's".  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 6 Jan 87 22:29:28 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MX.LCS.MIT.EDU 6 Jan 87 22:27:35 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2714430220690014@MIT-MULTICS.ARPA>; 06 Jan 1987 19:23:40 est Message-ID: <225447@QZCOM> In-Reply-To: <8701040604.AA06541@eneevax.umd.edu> Date: 06 Jan 87 11:53 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Leigh L. Klotz" , KS-ITS@MX.LCS.MIT.EDU Subject: 2020 spare parts We want RP06, cards, ie the memorex board, the interface board, the cables, and the dcl boards. A 60Hz rp06 is to expensive to ship to us, bu we have got our hands on a cupple of rp06 drives, that was part of a IBM-comaptible Memorex disk subsystem. And with scrapped rp04 DCL boxes and power supply, and the DEC specific board for the rp06 we will make working DEC-talking Rp06. (.Anyone realized that an rp06 is running in maint mode, with dcl attached where the maintenence borads usally fit.) The old KI is running KI*3 Bottoms 10, symetrical. Dug, we have run out of 5Ft memory bus cable, adding the next two processors will fail without more cables. Need is approx 32 pcs..  Date: Mon, 5 Jan 87 14:20:52 EST From: Alan Bawden Subject: 2020 spare parts To: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sun 4 Jan 87 01:04:16 EST from Douglas Humphrey Message-ID: <136701.870105.ALAN@AI.AI.MIT.EDU> Date: Sun, 4 Jan 87 01:04:16 EST From: Douglas Humphrey ... I keep hearing that the RP06's on the MIT KS machines have problems. This company is swimming in RP06's, and routinely sends them off to the scrappers at cents to the pound. Might it e a good idea to have spare drives arounf tech square, or are the ITS machines of such priority that this would not be worth it? Considerations: 1. Where can we put them? The AI Lab isn't exactly swimming in dead storage space these days. 2. If OZ is flushed, that would free up more RP06's than we could possibly keep as spares, so this would be wasted effort. 3. MD has always been thought of as an organ doner, so perhaps we already has a spare RP06. 4. Who, exactly is going to invest the time and expense (perhaps minimal) in arranging to ship these here? I, for example, don't plan to do anything about this myself. 5. Any effort spent on this might be better spent on a number of other related projects. I'm sure JTW would be happy to explain to anyone just what other options we have thought about for improving the RP06 situation. 6. If we had a spare RP06 in the basement, would it really be more convenient to drag it up to the 9th floor and install it than to wait a couple of days for DEC to fix the broken one? Points 1 and 6 do not apply to LCS, who might feel separate responsibility for the maintenence of the MC KS10.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 5 Jan 87 13:15:56 EST Received: from MC.LCS.MIT.EDU (CHAOS 3131) by MX.LCS.MIT.EDU 5 Jan 87 13:14:26 EST Received: from eneevax.umd.edu (TCP 20002102401) by MC.LCS.MIT.EDU 5 Jan 87 13:12:27 EST Received: by eneevax.umd.edu (5.9/4.7) id AA06541; Sun, 4 Jan 87 01:04:16 EST Date: Sun, 4 Jan 87 01:04:16 EST From: Douglas Humphrey Message-Id: <8701040604.AA06541@eneevax.umd.edu> To: KLOTZ%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Subject: 2020 spare parts The company that is providing my 2020 has at least one other that they are not using, and they have 2020 spares kits around too. If anyone needs 2020 parts, or parts for any DEC machine for that matter, you might send me a message on what you need before you buy it elsewhere. They have been very reasonable in parts prices for the DEC machines that I have at work. I keep hearing that the RP06's on the MIT KS machines have problems. This company is swimming in RP06's, and routinely sends them off to the scrappers at cents to the pound. Might it e a good idea to have spare drives arounf tech square, or are the ITS machines of such priority that this would not be worth it? Doug  Date: Sun, 4 Jan 87 05:03:53 EST From: Alan Bawden Subject: IAP To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <136289.870104.ALAN@AI.AI.MIT.EDU> Yes, there will be an IAP course this January about ITS. The first meeting will take place in the 7th floor playroom this Tuesday (the 6th) at 7:30 PM. On Tuesday we will talk about a number of things, including what topics people might want to hear about in future sessions. As a main event, I am preparing an explanation of everyone's favorite ITS feature: PCLSRing: What it is, how it's implemented, and why Lisp Machines should have it. I'll try and satisfy both the people who want to hear about low-level, bits-between-the-toes issues, and those who want to learn universal, cosmic principles. I'll even relate PCLSRing to quantum mechanics.  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 31 Dec 86 22:59:50 EST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Wed 31 Dec 86 19:56:21-PST Date: Wed 31 Dec 86 18:49:51-PST From: Mark Crispin Subject: Re: Eli's 2020 To: KLOTZ@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <8612312338.AA14456@eneevax.umd.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12267321543.6.MRC@PANDA> I suggest that all private owners of 2020's get on to DECmailer service. It's free (until you use it) and it is about the best "last resort" for spares. The more of us who are in their database, the less likely they'll drop supporting spares for us (they are still supporting PDP-4 spares!). The DECmailer price for a swap bad-for-good for the 2020 power supply is $880. When my 2020's power supply bit it last August, I bought Eli's 2020's power supply for $600 plus $80 to Fed Ex it here. I later found out that LH Research (the maker of the power supply) will fix my busted one for $400. Sometime I'm going to send them my busted supply so I will have a spare. Beware. 2020 power supplies are *hairy*. It isn't like the cretinous DEC power supplies that are trivial to fix. With a DEC power supply, you just find the fried picofuse, replace it with a *real* fuse, and change the fan (which failed, which caused the supply to overheat, which caused the silly fuse to blow). A $16 repair. It isn't that simple with a 2020 power supply. They're a bear to take apart and once you do you find an inpenetrable maze of wires and VAC all over the place. Without schematics there is no hope of fixing one unless there is something obviously burnt. Eli's 2020's power supply was not the latest rev. That suggests that Eli's 2020 may not be the latest rev either. I don't know how good it would be as a source of spare boards. -------  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 31 Dec 86 22:16:45 EST Date: Wed, 31 Dec 86 22:15:50 EST From: "Leigh L. Klotz" To: KS-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <963799.861231.KLOTZ@MX.LCS.MIT.EDU> Maybe we should let Eli's cool off a bit before asking again. They might raise the price of this 2020 they don't have because of the interest. They did have a big box of decimal thumbwheel switches I was looking at...  Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 31 Dec 86 18:40:03 EST Received: by eneevax.umd.edu (5.9/4.7) id AA14456; Wed, 31 Dec 86 18:38:08 EST Date: Wed, 31 Dec 86 18:38:08 EST From: Douglas Humphrey Message-Id: <8612312338.AA14456@eneevax.umd.edu> To: KLOTZ@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.Stanford.EDU Subject: Eli's 2020 Cc: KS-ITS@AI.AI.MIT.EDU If MRC has it's power supply, then the KS-10 would be a very nice source of spare boards for the numerous 2020's that around. If anyone can find out what happened to the rest of the system it might be a good thing. Doug  Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 31 Dec 86 18:10:19 EST Received: by eneevax.umd.edu (5.9/4.7) id AA14101; Wed, 31 Dec 86 18:08:26 EST Date: Wed, 31 Dec 86 18:08:26 EST From: Douglas Humphrey Message-Id: <8612312308.AA14101@eneevax.umd.edu> To: KLOTZ@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: 2020's and other things that go whir in the night I have a TU45 in my basement now, and after the holidays they will hopefully get around to checking out the 2020 and sending it up here. I haven't seen a lot of traffic lately on KS-ITS. Are folks still doing things to it, or has everyone shifted over to more recent technological advances (spark gaps, relays) ? Did the ITS for PM ever get patched to the point that it ran OK ? Thanks, Doug  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 30 Dec 86 22:35:14 EST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Tue 30 Dec 86 19:32:28-PST Date: Tue 30 Dec 86 18:27:10-PST From: Mark Crispin To: KLOTZ@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <135103.861230.KLOTZ@AI.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12267055270.7.MRC@PANDA> It wouldn't be useful if you bought Eli's 2020, since I have its power supply... -------  Received: from Godot.Think.COM (TCP 30001264307) by AI.AI.MIT.EDU 30 Dec 86 21:33:13 EST Received: by Godot.Think.COM; Tue, 30 Dec 86 21:31:38 EST Date: Tue, 30 Dec 86 21:31:38 EST From: bruce@Think.COM (Bruce J. Nemnich) Message-Id: <8612310231.AA08348@Godot.Think.COM> To: KLOTZ@AI.AI.MIT.EDU Cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: "Leigh L. Klotz"'s message of Tue, 30 Dec 86 20:42:38 EST I stopped by Eli's a couple of weeks ago for some chips, but asked the same thing. Me: Do you happen to have a KS-10 system around? Him: A what? Me: A 2020. Him: Oh, no. They're old. Me: That's why I thought you might have one. --bruce  Date: Tue, 30 Dec 86 20:42:38 EST From: "Leigh L. Klotz" To: KS-ITS@AI.AI.MIT.EDU Message-ID: <135103.861230.KLOTZ@AI.AI.MIT.EDU> I stopped by Eli's today and asked if they still had their 2020 for sale. They didn't understand. Then I asked for a KS-10 and they didn't understand that either. They said a guy came by and wanted to buy a PDP-1, and they couldn't help him either. They gave me a vinyl plastic numeral 1 with a calendar on it.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 DEC 86 14:18:48 EST Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 2 Dec 86 14:16:44 EST Received: from CUCKOO.SCRC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 78289; Tue 2-Dec-86 14:14:24 EST Date: Tue, 2 Dec 86 14:13 EST From: Tom Knight Subject: Putting today in the past tomorrow... To: ks-its@MIT-MC.ARPA Message-ID: <861202141340.1.TK@CUCKOO.SCRC.Symbolics.COM> Well, the stories in the Globe must be true. You know Symbolics is in trouble when it sells the bedrock of its computational resources... Your chance to bring ITS up on an even more obsolete machine than the KS! (It's probably a lot faster, if this is any consolation...) Date: Tue, 2 Dec 86 11:42 EST From: Richard Lawhorn Jr. Symbolics is selling The Foonly to the highest bidder. The Foonly consists of the following: One working Model F-2 Serial Number 6 CPU with prints. The console line line works. The tape interface works. The disk interface works. The serial lines (16 of them) need to be repaired. The parallel interface has a stuck bit. 2 working T-302 Disk drives with Cables and prints. 1 working Kennedy Tape Drive with formatter and cables and rack. 1 working LA120 system console. 1 completely dead PDP-11/40. Shipping weight is 1100 pounds. Buyer pays shipping costs FOB Cambridge The Foonly will be sold AS IS. Installation and disk packs are negotiable. Maintainence is NOT available from Symbolics, but may be from another company. Bids must be received by December 31, 1986 and should be sent to Richard Lawhorn at: Symbolics Inc. 11 Cambridge Center Cambridge, MA 02142 Please don't call, but please do send mail. Purchasers do not have to be affiliated with Symbolics. -Rick  Date: Mon, 1 Dec 86 11:22:46 EST From: Alan Bawden Subject: ITS Update for SI To: KLH@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 1 Dec 86 03:42:38 EST from Ken Harrenstien Message-ID: <124816.861201.ALAN@AI.AI.MIT.EDU> Date: Mon, 1 Dec 86 03:42:38 EST From: Ken Harrenstien 454 Technology Square?? Where's that? OOps. I guess he found my office anyway since the tape disappeared the next day.  Date: Mon, 1 Dec 86 03:42:38 EST From: Ken Harrenstien Subject: ITS Update for SI To: ALAN@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <124754.861201.KLH@AI.AI.MIT.EDU> 454 Technology Square?? Where's that?  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 NOV 86 20:02:12 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 11557; Sun 16-Nov-86 19:56:40 EST Date: Sun, 16 Nov 86 19:56 EST From: Alan Bawden Subject: ITS Update for SI To: ROLL@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].118987.861116.ROLL> Message-ID: <861116195630.4.ALAN@PIGPEN.AI.MIT.EDU> Date: Sun, 16 Nov 86 10:19:46 EST From: Peter Lothberg A friend of us Jan-Erik Gustafsson is in the Boston area. I asked him to visit you and bring an incremental dump of ai from may. So we got the latest (and greatest version).... I have generated a tape containing all files written (on the relevant set of directories) between the day I made your distribution tape and today. It is sitting on top of the file cabinet in my office at MIT labeled "ITS Update for SI". I'm CC'ing this message to KS-ITS so that if your friend comes looking for it, it will be more likely that someone around here will be able to help him. When you get this tape, I'm not sure what the best way to load it will be. If you tell DUMP LOAD MERGE NOASK then no file in your filesystem will be overwritten. But you probably -do- want to overwrite most (but not all!) of the files with the newer ones from the tape. So if you tell DUMP just LOAD MERGE then DUMP will ask you a question for each possible overwrite, and you can decide on a case-by-case basis what you want to do. It will -almost- be the right thing to always overwrite with the file from the tape, but not always... One file you want to be a little careful about is SYSBIN;DUMP BIN. You -don't- want the version of SYSBIN;DUMP BIN from the tape since that has been assembled for AI. Of course you always can create a new DUMP BIN for your system by assembling SYSENG;DUMP > and telling it that you want to make a DUMP for SI. Another file you must -not- overwrite is SYSENG;MACRO TAPES. This is the file that contains your local tape database. The tape I'm sending has a copy of AI's tape database, which you certainly don't want. I have appended a listing of the tape to the end of this message so that you can see in advance what it contains. When you get the tape, you will want to install a new microcode and assemble a new ITS. The new microcode has some bug fixes and supports single stepping (mostly, there are still some bugs). You will want to use the :KSFEDR program to replace the RAM file in your front-end filesystem with KSHACK;RAM 261. (If you screw up the microcode file in the front-end filesystem, you can always use the DSKDMP KS10 boot tape that came with your original distribution kit to get ITS started and fix the damage. Recall that a KS10 boot tape has a microcode image on it.) The old ITS will run with the new microcode (right Dave?), so get the microcode running first, before booting an ITS assembled from the latest sources. The new binary for timesharing DDT (SYS;ATSIGN DDT) also contains modifications for single stepping (I think), but unless you actually try and use the single-stepping command (^N) it should work fine with any combination of microcode and ITS. For help in finding me or my office, the following information may be useful: Alan Bawden MIT AI Lab Room NE43-723 454 Technology Square Cambridge, MA 02139 Phone at MIT: (617) 253-8843 Phone at home (also cent and Moon): (617) 492-7274 Network mail: ALAN@AI.AI.MIT.EDU Here is the listing of the tape I have prepared: TAPE NO = 62 CREATION DATE 861116 DUMPED BY ALAN 1 .INFO. DUMP INFO 0 10/24/86 05:03:57.5 2 .INFO. ITS UUOSIX 0 8/30/86 03:02:00.5 3 .INFO. STINK DOC 0 11/8/86 12:41:39 4 .TECO. DISSOC IATE 0 9/18/86 20:09:44.5 5 .TECO. DISSOC PEOPLE 0 9/19/86 01:01:17.5 6 C [CLIB] 16 0 6/22/86 02:53:35 7 COMMON EPROP8 LISP 0 8/18/86 21:47:07 8 COMMON EPROP8 TEXT 0 8/18/86 21:46:13 9 COMMON INDEX .BYE. 0 11/12/86 05:01:18.5 10 COMMON LINS 412 1 10/28/86 16:05:47.5 11 COMMON LINS 413 0 11/8/86 17:29:42.5 12 COMMON LINS 414 0 11/12/86 05:01:18.5 13 COMMON MAZE DOC 1 7/24/86 18:51:46 14 COMMON R STAT 0 6/22/86 03:05:23 15 DEVICE ATSIGN MLDEV 0 6/6/86 13:27:09 16 DEVICE CHAOS SEND 0 10/30/86 02:55:33.5 17 DEVICE JOBDEV DQ 0 8/14/86 16:18:46.5 18 DEVICE JOBDEV LP 0 10/9/86 04:10:36.5 19 EMACS AUX :EJ 0 6/12/86 14:28:15.5 20 EMACS BIBLIO :EJ 0 9/30/86 15:47:26.5 21 EMACS BIBLIO DEFNS 0 9/30/86 15:45:09.5 22 EMACS BIBLIO EMACS 0 9/30/86 15:45:45.5 23 EMACS1 AUX 55 0 6/12/86 14:27:36 24 EMACS1 BABYL 774 0 6/17/86 16:30:18 25 EMACS1 BABYLM 165 0 6/17/86 16:31:04.5 26 EMACS1 BUG EMACS 0 11/16/86 11:15:07 27 HUMOR ASK NOT 1 9/30/86 02:57:28.5 28 HUMOR PDP-* LIST 1 8/20/86 04:17:20.5 29 HUMOR SCRTCH MONKEY 1 9/10/86 09:48:17 30 INQUIR INQUPD 126 0 8/29/86 00:48:12 31 INQUIR INQUPD BIN 0 9/30/86 00:56:45.5 32 INQUIR INQUPD ORECOR 1 10/23/86 01:38:01.5 33 INQUIR INQUPD RECORD 0 11/16/86 08:03:51 34 INQUIR LSR1 1 0 11/16/86 08:04:02.5 35 INQUIR LSR1 LOCK 0 11/16/86 08:03:51 36 INQUIR LSR1 OLD 0 11/16/86 07:56:14 37 INQUIR LSR1 OLDOLD 0 11/16/86 00:09:06 38 KSC BUGTCP MAIL 0 11/14/86 10:45:22.5 39 KSC CRTSTY BUGS 0 6/18/86 04:03:52 40 KSC FTP BUGS 0 9/25/86 15:21:05 41 KSC HEADER MINS 0 11/15/86 17:47:49.5 42 KSC HEADER PEOPLE 0 11/10/86 00:00:40.5 43 KSC MAIL BUGS 0 11/12/86 16:50:58.5 44 KSC NAME BUGS 0 11/6/86 03:55:37 45 KSHACK 1PROC BUGS 0 6/1/86 00:54:25 46 KSHACK AINOTE 8 0 10/24/86 05:02:35 47 KSHACK BUILD DOC 0 11/8/86 02:30:19 48 KSHACK DSKDMP ORDER 0 6/12/86 16:24:13 49 KSHACK INOUT 49 0 6/1/86 00:02:31.5 50 KSHACK ITS 14 0 6/1/86 00:52:40 51 KSHACK ITS 15 0 6/12/86 15:29:13.5 52 KSHACK ITSPAG 94 0 6/1/86 00:50:05 53 KSHACK ITSPAG 97 0 6/7/86 23:28:09 54 KSHACK KS-ITS MAIL 0 11/13/86 00:33:10 55 KSHACK KS10 41 0 6/8/86 20:48:58.5 56 KSHACK KS10 42 0 6/11/86 21:03:13 57 KSHACK KS10 45 0 8/1/86 12:22:07.5 58 KSHACK KS10 TAGS 0 6/8/86 20:08:40 59 KSHACK MCR 261 1 6/8/86 22:30:15 60 KSHACK MINSYS DUMP 0 11/8/86 02:20:44.5 61 KSHACK MINSYS HOARD 0 10/24/86 04:40:47.5 62 KSHACK NSALV 217 0 6/12/86 15:51:24 63 KSHACK NSALV 218 0 7/13/86 20:32:11 64 KSHACK NSALV 223 1 10/23/86 05:41:49 65 KSHACK NSALV 226 0 10/24/86 04:23:06 66 KSHACK RAM 261 0 6/8/86 22:36:59.5 67 KSHACK SIMPLE 37 0 6/1/86 00:49:45.5 68 KSHACK SIMPLE 38 0 6/8/86 22:27:41.5 69 LIBDOC MACITS ALAN13 0 8/31/86 06:27:20 70 LIBLSP MACITS FASL 0 8/31/86 06:27:23 71 LSB1 LOOP BUGS 0 11/14/86 13:33:29 72 MOON COMSAT BIN 0 11/6/86 23:22:00.5 73 MOON LUNAR 220 0 7/3/86 12:18:57 74 MOON LUNAR :EJ 0 7/3/86 12:19:40.5 75 MOON PIECES 8 0 9/16/86 19:12:51.5 76 MOON SYMCON DVI 0 11/5/86 00:35:15 77 MOON SYMFUN DVI 0 11/5/86 00:33:04.5 78 RWK TS F 0 10/31/86 21:29:52.5 79 SYS :MSGS TIMES 0 11/16/86 16:34:59 80 SYS ATSIGN DDT 0 6/18/86 03:55:06.5 81 SYS ATSIGN ODDT 0 6/7/86 17:20:20.5 82 SYS SYSTEM MAIL 0 10/24/86 22:07:13.5 83 SYS TS NAME 0 10/31/86 16:33:27.5 84 SYS TS PEEK 0 10/31/86 16:34:44 85 SYS TS PROBE 0 11/1/86 20:04:35 86 SYS1 TS DIR 0 10/22/86 18:43:15 87 SYS1 TS METER 0 11/6/86 19:54:16.5 88 SYS1 TS STINK 0 11/7/86 20:22:14 89 SYS1 TS SYSMSG 0 11/9/86 20:12:14.5 90 SYS1 TS TALK 0 7/6/86 05:56:23 91 SYS2 TS WHAT 0 11/14/86 14:02:04.5 92 SYS2 TS XXFILE 0 11/13/86 23:39:37 93 SYS3 TS DOVER 0 10/22/86 18:50:11.5 94 SYS3 TS DQ 0 8/21/86 23:58:29 95 SYS3 TS EXPN 0 6/8/86 01:31:40.5 96 SYSBIN BIG 0DAT 0 11/16/86 16:43:25.5 97 SYSBIN CHTN BIN 0 10/22/86 22:02:55.5 98 SYSBIN DDT 513BIN 1 6/7/86 17:01:31.5 99 SYSBIN DDT BIN 0 6/18/86 03:38:43 100 SYSBIN DUMP BIN 0 11/8/86 02:31:36 101 SYSBIN FIDO BIN 0 7/22/86 16:24:42 102 SYSBIN FTPS BIN 0 10/29/86 01:27:26 103 SYSBIN HOSTS3 821 0 11/15/86 04:49:47 104 SYSBIN PEEK 618BIN 1 6/8/86 16:03:14 105 SYSBIN PEEK 619BIN 0 6/19/86 23:20:51.5 106 SYSBIN PROBE BIN 0 6/5/86 16:42:30.5 107 SYSDOC DDT BUGS 0 10/30/86 06:23:06 108 SYSDOC DUMP FORMAT 0 6/12/86 18:07:07.5 109 SYSDOC ITS BUGS 0 11/13/86 19:53:23 110 SYSDOC POOR MC 0 10/25/86 08:40:31.5 111 SYSDOC UUOS 106 0 8/30/86 03:02:00.5 112 SYSEN1 DDT 1513 0 6/7/86 17:01:22 113 SYSEN1 DDT 1516 0 6/18/86 03:38:35 114 SYSEN1 DOVER 137 0 10/22/86 18:50:05.5 115 SYSEN1 LPDEV 193 0 8/7/86 20:43:53.5 116 SYSEN1 LPDEV 195 0 10/7/86 01:59:24.5 117 SYSEN1 LPDEV 198 0 10/9/86 04:10:33 118 SYSEN1 NETIME 114 0 6/19/86 17:16:16.5 119 SYSEN1 PWORD 2655 0 7/13/86 00:17:49.5 120 SYSEN2 MLDEV 103 0 6/6/86 13:27:05.5 121 SYSEN2 PEEK 618 0 6/8/86 16:03:04.5 122 SYSEN2 PEEK 619 0 6/19/86 23:20:33.5 123 SYSEN2 SRCCOM 126 0 7/30/86 23:23:44 124 SYSENG DUMP 400 0 6/16/86 15:51:15.5 125 SYSENG DUMP 401 0 11/8/86 02:10:02 126 SYSENG MACRO TAPES 0 11/16/86 16:46:45 127 SYSENG MODEMS 6 0 6/30/86 21:12:47.5 128 SYSENG PFT 145 0 7/12/86 02:28:40 129 SYSENG WHAT 197 0 11/14/86 14:02:00.5 130 SYSHST -READ- -THIS- 0 10/7/86 16:14:02 131 SYSHST -THIS- -TOO- 0 6/17/86 15:57:03 132 SYSHST -WHAT- -FILE- 0 9/5/86 16:31:48 133 SYSHST AR2 HSTSRC 0 6/17/86 16:01:05.5 134 SYSHST HOSTS3 README 0 11/12/86 18:39:23.5 135 SYSHST HSTAI 485 0 11/14/86 10:25:38.5 136 SYSHST HSTAI 486 0 11/14/86 14:21:42.5 137 SYSHST HSTAI 487 0 11/14/86 15:01:26 138 SYSHST HSTATH 23 0 10/13/86 22:50:14 139 SYSHST HSTATH 24 0 10/26/86 23:38:32.5 140 SYSHST HSTEE 8 0 8/28/86 22:07:32 141 SYSHST HSTEE 9 0 8/28/86 22:12:20 142 SYSHST HSTG 49 0 10/27/86 00:58:01 143 SYSHST HSTG 50 0 10/27/86 01:40:31.5 144 SYSHST HSTINF RECENT 0 10/27/86 11:43:06 145 SYSHST HSTLCS 378 0 11/14/86 14:28:25.5 146 SYSHST HSTLCS 379 0 11/14/86 14:34:08 147 SYSHST HSTLCS 380 0 11/14/86 20:14:38.5 148 SYSHST HSTMDA 2 0 10/27/86 01:36:21.5 149 SYSHST HSTMDA 3 0 10/27/86 01:40:49 150 SYSHST HSTMDA 4 0 11/12/86 14:31:04 151 SYSHST HSTMIT 318 0 11/15/86 04:50:21 152 SYSHST HSTNET 27 0 10/20/86 16:40:51 153 SYSHST HSTNET 28 0 10/26/86 21:14:07 154 SYSHST HSTUID 2 0 10/15/86 20:42:13.5 155 SYSHST HSTUID 3 0 10/29/86 21:11:58.5 156 SYSHST HSTXXX 15 0 10/26/86 01:19:37 157 SYSHST HSTXXX 16 0 10/26/86 19:39:01 158 SYSHST MITGWS 823 0 11/15/86 04:50:41.5 159 SYSHST ZRCPT INFHST 0 11/10/86 18:29:41 160 SYSHST ZRCPT UPDHST 0 10/8/86 18:50:52 161 SYSNET CHTN 15 0 10/22/86 22:04:26.5 162 SYSNET COMSAT 520 0 11/6/86 23:20:28.5 163 SYSNET COMSAT 521 0 11/7/86 22:14:08 164 SYSNET FTPS 324 0 7/13/86 02:10:48.5 165 SYSNET FTPS 325 0 10/29/86 01:26:56.5 166 SYSNET NETWRK 260 0 6/2/86 19:38:29.5 167 SYSNET SENVER 45 0 10/30/86 02:54:43.5 168 SYSTEM CONFIG 168 1 6/12/86 15:45:47 169 SYSTEM CONFIG 169 0 7/14/86 15:51:10.5 170 SYSTEM CONFIG 171 0 10/23/86 05:50:11 171 SYSTEM CONFIG 172 0 10/31/86 15:29:17.5 172 SYSTEM DISK 1214 0 10/23/86 05:29:02.5 173 SYSTEM DSKDMP 213 0 10/23/86 04:38:04 174 SYSTEM IOELEV 430 0 10/23/86 01:19:57.5 175 SYSTEM ITS 1584 0 6/1/86 14:35:43.5 176 SYSTEM ITS 1586 0 6/12/86 15:43:08 177 SYSTEM ITS 1587 0 10/23/86 05:22:38 178 SYSTEM ITS NOTAGS 0 10/23/86 04:48:10.5 179 SYSTEM ITS TAGS 0 10/23/86 04:48:28.5 180 SYSTEM RH11 DEFS35 0 10/22/86 22:59:42 181 SYSTEM RM03 DEFS5 0 10/23/86 04:13:45 182 SYSTEM RP06 DEFS1 0 10/22/86 20:56:31 183 SYSTEM TTYTYP 299 1 6/12/86 15:49:34 184 SYSTEM TTYTYP 300 1 6/30/86 17:24:15.5 185 SYSTEM TTYTYP 302 0 10/24/86 19:36:29  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 13 Nov 86 00:31:23 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 12 Nov 86 21:24:45-PST Date: Wed 12 Nov 86 20:58:15-PST From: Mark Crispin Subject: Re: lessons from PM ITS installation To: sra@XX.LCS.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <861112172143.8.SRA@WHORFIN.LCS.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12254499864.7.MRC@PANDA> Hi Rob - No, I haven't developed a patch to make COMSAT run without a network but I didn't even try. I'm not all that sure I know how to start COMSAT; there are some *dim* memories from 10 years ago... I have sent the sum of my experiences to KS-ITS. I hope they are useful and not just random flamage. I still claim that it isn't all that unreasonable to require that a net be turned on. Am I correct in believing that some of the ITSes are Chaos-only systems and that all the system software (Telnet, COMSAT in particular) runs fine on them? If so, then maybe turning on Chaos should just be a requirement. After all, that does give you interprocess communication (via local Chaos links). By the way, you guys might want to look at Cafard, the protocol I use for TTY-based mail on TOPS-20. You should be able to use the CAFPRO module without modification. Then at the very least you would have TTY mailing. Which reminds me; if ITS does not have any form of DTR control from user programs it should have it. Also, my dialups don't seem to work under ITS; it apparently never raises DTR in response to RI. -- Mark -- -------  Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 12 Nov 86 20:45:58 EST Received: by eneevax.umd.edu (5.9/4.7) id AA13532; Wed, 12 Nov 86 20:41:00 EST Date: Wed, 12 Nov 86 20:41:00 EST From: Douglas Humphrey Message-Id: <8611130141.AA13532@eneevax.umd.edu> To: MRC%PANDA@SUMEX-AIM.Stanford.EDU, sra@XX.LCS.MIT.EDU Subject: Re: lessons from PM ITS installation Cc: KS-ITS@AI.AI.MIT.EDU Too bad about the EST/EDT hard code in ITS. I guess it is fortunate that I live on the east coast.... Is there a rundown somewhere on what the network capabilities of ITS are ? Once I have the 2020 in the basement along with the rest of the zoo, it might be nice to get a local net established. A short description of what it knows how to do now, anyone ? Thanks, Doug  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 NOV 86 17:26:49 EST Received: from WHORFIN.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 NOV 86 17:23:59 EST Date: Wed, 12 Nov 86 17:21 EST From: Rob Austein Subject: lessons from PM ITS installation To: Mark Crispin cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12253674875.7.MRC@PANDA> Message-ID: <861112172143.8.SRA@WHORFIN.LCS.MIT.EDU> Gack. Sorry about the state of COMSAT and about that nonsense with system source code living on SRA;. I promised the guys in Sweden that I'd give them a patch to run COMSAT without a network some time ago, but I never finished it. Have you actually managed to patch things together so that COMSAT runs without a network or are you lost too (I couldn't tell from your message)? If you have it kludged into a working state, please send your patch to KS-ITS so that the people on further shores will know how to do it. Oh, BTW, things are worse than you think. Almost all network code still assumes that you are in timezone -0500 (EST or EDT). Another item on the wish list.... [If you got two copies of this message it's because ZMAIL spazzed....] --Rob  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 10 Nov 86 18:53:17 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 155124; Mon 10-Nov-86 18:46:17 EST Date: Mon, 10 Nov 86 18:45 EST From: David A. Moon Subject: Re: ITS runs with patch To: Mark Crispin cc: Alan@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12253755174.7.MRC@PANDA> Message-ID: <861110184531.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon 10 Nov 86 00:47:33-PST From: Mark Crispin I guess what confused me was that the bughalt message included a POPJ P, in its output. I didn't think carefully as to what $Q-2 meant. I assume that is nominally expected to be the instruction before the bughalt, presumably a skip-class instruction that states the bug condition? That was the idea. It didn't work in this case because the code was skip false popj p, bughlt instead of skip true bughlt popj p, The poor user interface is a result of implementing the user interface by just valreting commands to EDDT. I looked the other night at fixing the bughlt mechanism so you can't $P after a fatal one, but it looked a little too difficult for me since all the bughlt cases quickly join into common code, and the $P goes directly back to the program, not into the bughlt routine (i.e. it calls EDDT with tail recursion removal).  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 10 Nov 86 04:16:30 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 10 Nov 86 01:10:12-PST Date: Mon 10 Nov 86 00:47:33-PST From: Mark Crispin Subject: Re: ITS runs with patch To: Alan@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <861110004107.3.ALAN@PIGPEN.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253755174.7.MRC@PANDA> Ah, silly me. The ITS bughalt mechanism looks so much like WAITS' (obviously Moon was influenced during his stint on the west coast) that I allowed myself to believe it followed WAITS' semantics that the correct response after fixing the problem was always to type $P. Instead, an ITS bughalt is like a TOPS-20 bughlt, non- continuable unless you send the system to a specific place. $P in this case on TOPS-20 will cause a crash dump and reload. I guess what confused me was that the bughalt message included a POPJ P, in its output. I didn't think carefully as to what $Q-2 meant. I assume that is nominally expected to be the instruction before the bughalt, presumably a skip-class instruction that states the bug condition? There is a possibility that I have fixed the crowbar problem once and for all; in any case it hasn't hit in a few days. The problem seemed to be that the power supply was delivering much higher than +5V. I cranked the voltage adjustement several turns(!) before I finally got the two +5 voltages to a reasonable approximation of +5V. It's possible that the power supply is really sick, since I had adjusted it down to +5 just a few days before and only succeeded in scaring the crowbar problem away for a day or so. I discovered from talking to DEC field service types that drive control logic crowbar is a well-known way for RM03's to bite it (the other being a slightly higher-than average fondness for head crashing). Most DECies won't adjust the power supply; they simply replace it. This is a reason why RM03's cost more to maintain than they are worth, and why DEC is actively trying to kill Massbus peripherals as products. My conclusion about RM03's is that you should consider them as being disposable storage media. At $400 in the used market they're cheaper than most floppy disks, so use 'em until they break and don't spend too much time trying to fix 'em. Is there a database being kept on the ways in which KS-based systems lose? If not, perhaps with all the hacker KS systems appearing in the world one should be set up. AI seems like a good central place to maintain it. I'll contribute a few more notes: Problem: TU45 cannot be seen from the KS. TOPS-20 (I don't know what ITS does) thinks there are no tape drives, an MT console command just gives a ?BT error. Turning the id thumbwheel to 7 causes the 1600 BPI light to come on, otherwise it stays off (abnormal). Diagnosis: TM03 controller is not talking to the KS or to the drive. Check TM03 LED's; probably it isn't powered on. Solution: Remove TM03 power supply, mounted on the lower left side of the rack when facing the drive from the front). Open it up and check all the picofuses. Replace the blown picofuse, perhaps with a *real* fuse. While you're at it, check the power supply fan; often the reason the fuse bought it is that the fan is sick and the supply got too hot. Problem: System failure. When you walk into the machine room the KS power light is "sizzling" and the console is going crazy, or the KS power light is off and everything is dead. Diagnosis: Main KS power supply is dead (in my case the +12 output died...memory doesn't work too well without +12). Solution: Replace/repair the supply. Field repair is quite difficult in this supply; 120VAC runs all through it and it is a major effort to get the boards out. You can try looking for a blown picofuse but it's unlikely the fix will be this simple. If you have DEC field service come and fix your system on time and materials the cost is a few grand, easily. DECmailer service (*all* KS owners should be on DECmailer; it's free and is worth having as a last resort) will cost $880 to swap your bad supply for a good one. However, unlike most DEC equipment the KS uses a power supply from a real vendor instead of a DEC power supply. The vendor, LH Research, will not sell you a new KS power supply but they will fix it for a flat fee of $400. I bought a replacement power supply from Eli Heffron's (the last one, alas) for $600. Someday I will get my bad one fixed so I have a spare. Oh well, I hope I haven't bored everybody with all of this. I wouldn't waste much effort trying to make ITS handle RM03 crowbar gracefully. TOPS-20's "graceful recovery" requires a wizard to quickly force the system into EDDT and fix the problem before the software timeouts hit and the system bughlts irrecoverably. I'm sure someone who knows the ITS disk code better than I do can perform similar feats. But making the hardware reliable is a much better idea. -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 NOV 86 00:45:22 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 10703; Mon 10-Nov-86 00:41:08 EST Date: Mon, 10 Nov 86 00:41 EST From: Alan Bawden Subject: Re: ITS runs with patch To: MRC%PANDA@SUMEX-AIM.Stanford.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12253362428.7.MRC@PANDA> Message-ID: <861110004107.3.ALAN@PIGPEN.AI.MIT.EDU> Date: Sat 8 Nov 86 12:50:08-PST From: Mark Crispin I don't know why, but your mailer insists upon replying to MRC@PANDA.MIT.EDU instead of MRC%PANDA@SUMEX-AIM.Stanford.EDU. Is Babyl being too "smart"? This could be COMSAT's fault, as others have noted, or it could be a problem I have with a personal TECO macro. I suspect COMSAT myself. It's very unlikely that Babyl is at fault. The error which occured when the drive control logic (not the drive, which was perfectly happy the whole time) crowbarred was "DSK: MASSBUS ERROR, CS1= 140300". It then did a bughalt (this is something new to me; didn't ITS used to just do a JRST 4,.? Yeah. There are still a few JRST 4,.'s, but a few years ago Moon replaced most of them with a BUG macrology. There is a large comment in the front of SYSTEM;ITS that explains how it works. Its present behavior is a definite improvement!). The BUGPC was CAI DSKBRK, $Q-2 was a POPJ P,. I didn't poke at ITS at all on this, since it was painfully obvious what happened. So, I reset the power supply, and when the hardware was all happy again, I just did an $P to DDT. I got an ITS REVIVED message.... Well the bughalt in question was a BUG HALT rather than a BUG PAUSE, so in fact ITS didn't expect you to type $P. I looked at the source, and proceeding this particular bughalt drops into a random place in the disk code. I'm suprised the system ran long enough to type anything at all. The error message in a BUG PAUSE would have advised you that an $P was a possibility. The message in a BUG HALT gives you no such permission, although sometimes, after understanding the problem more throughly, you can sometimes decide to $P anyway. (This may strike you as weird, but remember that the message isn't designed to be read by hackers like you and I, but by some random graduate student who just came in and found ITS was down.) I certainly agree that it would be a nice idea (especially for you) to put a little code after that bughalt that resets the disk system and starts things up again.  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 9 Nov 86 21:37:44 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 9 Nov 86 18:32:26-PST Date: Sun 9 Nov 86 17:26:27-PST From: Mark Crispin Subject: lessons from PM ITS installation To: KS-ITS@AI.AI.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253674875.7.MRC@PANDA> Friends - Here are the main observations I have as a result of installing ITS on PandaMonium: 1) The RM03 version of ITS needs to have the current cylinder code removed. 2) It would be preferable if the code used the information from the Massbus to determine what sort of disk drive is used instead of assembling it in ITS. TOPS-20 does this. I believe that you can't mix RM03's, RP04's, and RP06's on a single system in the curren ITS. 3) ITS EDDT is rather, uh, difficult to use. I wasn't able to single- step in it, for example. I guess this isn't terribly important. 4) Procedures need to be established to automatically create directories when loading a system from dump tape, and also to suppress the SYSxxx; directory warning. One way to do this is to have people load the filesystem using the Salvager instead of DUMP. 5) I don't know if it makes sense to build systems without a network, considering how much software (including the mailer) fails to work on non-network systems. It would probably be alright if Chaos was always turned on, if that's the critical point (if I'm correct, MD and ML are Chaos but not Internet, right?). I think the lost space is more than made up by having a working mailer. 6) Software that knows about the names of all the systems presents a problem. I don't have a pat answer for this. 7) Running NAME or WHOIS with an argument doesn't work. F^K works, but :F MRC just outputs a blank line. I suspect it's confused by PM not being a known MIT name. 8) All of the software WILL fit on a single RM03 if you delete all the extraneous versions of lots of stuff. You will have to rebuild EMACS and a few other things if you do this though. 9) Entirely too much system software and sources live on private user directories and are lunk to in the SYSxxx; directories. For example, a resolver source file is on SRA; with a link on SYSNET;. Scratch one source file that would have been useful. It would be nice if this was cleaned up. In summary, though, I think you guys have done an excellent job. Congratulations. -- Mark -- -------  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 9 Nov 86 15:45:16 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 9 Nov 86 12:39:36-PST Date: Sat 8 Nov 86 21:35:38-PST From: Mark Crispin Subject: Re: ITS runs with patch To: SRA@XX.LCS.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253458093.7.MRC@PANDA> Rob - Touche. In fact, there are two bugs: 1) MMailr builds an SMTP return path of the form @SUMEX-AIM.ARPA:MRC@PANDA, even though DoD policy expressly forbids names that are not in the Internet domain from appearing in an address. 2) MMailr trusts the DoD policy, and so ignores the @SUMEX-AIM.ARPA: part and parses MRC@PANDA. Unfortunately, MRC@PANDA means something else in the MIT domain (and, for that matter, in the Stanford domain with the exception of SUMEX-AIM!). Someday I plan on fixing these bugs. Note that either bug by itself is no big deal (Unix sendmail has bug #1), it's the combination that is nasty. Why is COMSAT or whatever using the return path? -- Mark -- -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 NOV 86 00:18:17 EST Date: Sun, 9 Nov 1986 00:14 EST Message-ID: From: Rob Austein To: Mark Crispin Cc: KS-ITS@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Subject: ITS runs with patch In-reply-to: Msg of 8 Nov 1986 15:50-EST from Mark Crispin Date: Saturday, 8 November 1986 15:50-EST From: Mark Crispin I don't know why, but your mailer insists upon replying to MRC@PANDA.MIT.EDU instead of MRC%PANDA@SUMEX-AIM.Stanford.EDU. Is Babyl being too "smart"? Maybe. And maybe MMAILR is being too "stupid". When I get mail from you directly on XX (with the latest and greatest MMAILR, via TCP/SMTP) it still claims that I have mail from "MRC@PANDA.MIT.EDU.#Chaos". More likely it is the old COMSAT "feature" which has been screwing people for years when it thinks it recognizes the BAR in FOO%BAR@BAZ. That code should be dyked out if anybody has the ambition to figure out where it is.  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 8 Nov 86 16:38:27 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 8 Nov 86 13:33:30-PST Date: Sat 8 Nov 86 12:50:08-PST From: Mark Crispin Subject: Re: ITS runs with patch To: ALAN@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].116174.861108.ALAN> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253362428.7.MRC@PANDA> I don't know why, but your mailer insists upon replying to MRC@PANDA.MIT.EDU instead of MRC%PANDA@SUMEX-AIM.Stanford.EDU. Is Babyl being too "smart"? The error which occured when the drive control logic (not the drive, which was perfectly happy the whole time) crowbarred was "DSK: MASSBUS ERROR, CS1= 140300". It then did a bughalt (this is something new to me; didn't ITS used to just do a JRST 4,.? Its present behavior is a definite improvement!). The BUGPC was CAI DSKBRK, $Q-2 was a POPJ P,. I didn't poke at ITS at all on this, since it was painfully obvious what happened. So, I reset the power supply, and when the hardware was all happy again, I just did an $P to DDT. I got an ITS REVIVED message. Then, I got a message of the form DSK: ERR UNIT #0 ER1=40200 ER2=17777 ER3=4000 STARTING DISK ADDR= 31,,30 It repeated many times with different disk addresses. I also got a few messages of the form: DSK: IRREC DATA ERR #2 UNIT=0 BLK= 16321 DSK: ERR UNIT #0 ER1=402 I regularly got "DSK: TOO MANY ERRORS" and the system bugpaused with a BUGPC of UNSAFE+2 and $Q-2 of SKIPE USFHLT. Finally, I gave up and reloaded. As far as I could tell from the salvager, absolutely no disk I/O actually happened from the instant the power supply first crowbarred, in spite of the fact that it claimed that it had written a few files to system directories. I know that TOPS-20 can get out of this. As I remember from studying PHYP4.MAC when I was porting TOPS-20 to the SC-30M, TOPS-20 is quite willing to do a complete hard reset and recalibrate of the drive at the slightest sign of trouble beyond a piddling ECC error. -------  Date: Sat, 8 Nov 86 15:20:35 EST From: Alan Bawden Subject: ITS runs with patch To: MRC@PANDA.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Fri 7 Nov 86 18:15:23-PST from Mark Crispin Message-ID: <[AI.AI.MIT.EDU].116174.861108.ALAN> Date: Fri 7 Nov 86 18:15:23-PST From: Mark Crispin ... I have a disk drive whose power supply periodically crowbars. It happened to me while running ITS. Normally, I can force TOPS-20 into EDDT, fix the drive, and proceed TOPS-20 without problems. So I thought when it happened to ITS I could do the same thing since ITS stopped in EDDT. It was not to be; it just continually reported disk errors. I think you should be able to reproduce this problem by powering off the DCL on a drive while ITS is running, let it bughlt, then power it back up and try to proceed ITS.... Well, there is code that tries to deal with things like this. I have tested it by shutting drives off while timesharing was running and after they spun back up, ITS continued merrily on its way. So sometimes it works. That doesn't mean it will work in all circumstances, of course... Where did ITS actually BUG HALT, and what did it say? What were the disk errors it reported after you proceeded it?  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 7 Nov 86 23:46:10 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 153665; Fri 7-Nov-86 23:40:52 EST Date: Fri, 7 Nov 86 23:40 EST From: David A. Moon Subject: Re: ITS runs with patch To: Mark Crispin cc: Alan@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12253159495.7.MRC@PANDA> Message-ID: <861107234029.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri 7 Nov 86 18:15:23-PST From: Mark Crispin Is there any way to sabotage the system logging writes onto SYSxxx; directories when loading a filesystem from tape? I wasted quite a bit of console paper... Patch MNGDIR to always skip return. Or, hook up a display terminal temporarily.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 NOV 86 23:31:26 EST Date: Fri, 7 Nov 1986 23:27 EST Message-ID: From: Rob Austein To: Mark Crispin Cc: KS-ITS@AI.AI.MIT.EDU Subject: ITS runs with patch In-reply-to: Msg of 7 Nov 1986 21:15-EST from Mark Crispin The init file you want is EMACS; EMACS TECO. Doing :TECO $ER EMACS; EMACS TECO$ @Y M(HFX*) W MMRUN$PURIFY$DUMP$TS NEMACS$$ should work. You might want to use some other version of TECO (NTECO, whatever), look around first. Once you have an editor you can look for the SYSxxx; thingie yourself, your guess is as good as mine where to look for it. --Rob  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 7 Nov 86 22:52:32 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 7 Nov 86 19:46:36-PST Date: Fri 7 Nov 86 18:15:23-PST From: Mark Crispin Subject: Re: ITS runs with patch To: Alan@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <861106182047.1.ALAN@PIGPEN.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253159495.7.MRC@PANDA> Thanks for all your help. I loaded all the tapes onto a single RM03 by judicious deleting of excessive versions of various files. There was a lot of completely unnecessary junk! However, I broke EMACS, of course, because it used an old TECPUR. I was able to use dump environment to get an interim TS EMACS, but what is the correct way to make a TS EMACS on ITS? By the way, ITS' disk error recovery code may need some help. I have a disk drive whose power supply periodically crowbars. It happened to me while running ITS. Normally, I can force TOPS-20 into EDDT, fix the drive, and proceed TOPS-20 without problems. So I thought when it happened to ITS I could do the same thing since ITS stopped in EDDT. It was not to be; it just continually reported disk errors. I think you should be able to reproduce this problem by powering off the DCL on a drive while ITS is running, let it bughlt, then power it back up and try to proceed ITS. I think the difference is that TOPS-20 decides under certain circumstances that the drive needs to be completely reset before trying again and ITS doesn't have this code. It shouldn't be hard to do. Of course, there is something to say for having more reliable hardware! Is there any way to sabotage the system logging writes onto SYSxxx; directories when loading a filesystem from tape? I wasted quite a bit of console paper... -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86 18:24:26 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 10392; Thu 6-Nov-86 18:20:43 EST Date: Thu, 6 Nov 86 18:20 EST From: Alan Bawden Subject: ITS runs with patch To: MRC%PANDA@SUMEX-AIM.Stanford.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12252832615.7.MRC@PANDA> Message-ID: <861106182047.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Thu 6 Nov 86 12:19:47-PST From: Mark Crispin I took a long shot and patched the instructions at QINTAT+23 from IORDQ A,mumble to MOVE A,QPOSGL(Q). The system works like a champ with that patch! If I'm not mistaken (remember, I'm hacking blindly from EDDT), what I've pretty much done is sabotage seek error detection, right? Well, that's what I would have thought... However, a close look at some documentation I thought I had read before reveals that the RM03, unlike the RP0n's, doesn't have a Current Cylinder register at all. Instead there is some kind of maintenance register at that address. I guess that little consistency check should just be removed for RM03 systems. The drive is supposed to signal an error if it has a problem seeking anyway. The second bring up of the system after running the Salvager to note the address of the front end filesystem deletes the .TEMP. and CRASH directories. Is this expected? I created a silly -DONT- DELETE link to make those directories non-empty. Not necessary. There is a little table of directories that ITS will make automatically whenever anyone references them. This table includes .TEMP. and CRASH. I started loading the filesystem, but DUMP fails in a OPEN right away complaining that .INFO. doesn't exist. If there is an option to DUMP to instruct it to create directories, I couldn't find it. Oops. We goofed. We intended to fix that before sending out the next distribution kit, but forgot all about it. There certainly should be an option to DUMP to make it do that, and I can't imagine how we got this far without it... For the moment, you can just create the directories yourself by hand whenever DUMP complains and then just proceed it. I hope that my information about the QINTAT+23 patch gives you guys enough information to develop a more suitable patch. Your current patch is just about as good as any we could have given you. Super!  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 6 Nov 86 16:17:45 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 6 Nov 86 12:28:17-PST Date: Thu 6 Nov 86 11:42:25-PST From: Mark Crispin Subject: RM03 disk code To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KS-ITS@AI.AI.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12252825812.7.MRC@PANDA> Okay, here's what I've done so far. Whenever testing ITS, I yanked the id plugs out of the other drives so ITS can't possibly see them. I tried the various breakpoints that you've suggested, and here's what I observed. The system is getting periodic attention interrupts, perhaps at the 1/2 second rate you referred to. It gets to QINTAT+25 where it compares A with QPOSGL. At this point A holds 10700 and QPOSGL holds 631. My impression from DDT is that the drive got a seek done attention interrupt, it wants cylinder 631, and it got 10700 as the position instead. It reacted by doing a recalibrate, and got another one of these attention interrupts and... The system CAN be shutdown by the SH console command. It takes a couple of seconds after the CRLF from the Salvager finishing before it gets into this state. I could not hear any obvious seeking noises from the drive when the system was in this state. -- Mark -- -------  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 6 Nov 86 15:34:06 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 6 Nov 86 12:28:57-PST Date: Thu 6 Nov 86 12:19:47-PST From: Mark Crispin Subject: ITS runs with patch To: KS-ITS@AI.AI.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12252832615.7.MRC@PANDA> I took a long shot and patched the instructions at QINTAT+23 from IORDQ A,mumble to MOVE A,QPOSGL(Q). The system works like a champ with that patch! If I'm not mistaken (remember, I'm hacking blindly from EDDT), what I've pretty much done is sabotage seek error detection, right? The second bring up of the system after running the Salvager to note the address of the front end filesystem deletes the .TEMP. and CRASH directories. Is this expected? I created a silly -DONT- DELETE link to make those directories non-empty. I started loading the filesystem, but DUMP fails in a OPEN right away complaining that .INFO. doesn't exist. If there is an option to DUMP to instruct it to create directories, I couldn't find it. I hope that my information about the QINTAT+23 patch gives you guys enough information to develop a more suitable patch. -------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 6 Nov 86 04:33:45 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 151607; Thu 6-Nov-86 04:28:36 EST Date: Thu, 6 Nov 86 04:28 EST From: David A. Moon Subject: Re: not so sad news To: Mark Crispin cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12252683444.7.MRC@PANDA> Message-ID: <861106042821.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed 5 Nov 86 22:40:22-PST From: Mark Crispin I tried it again. Each time QCST contained 104204. NQSATN, NQEATN, and NQOFFL all contained 0. I suspected as much, since the disks I am using have no errors, ECC or otherwise. I rather doubt that it is disks interrupting endlessly. From what I was able to trace, it looked like the code was looping at interrupt level and never dismissing. More things to look at: QSDU/ unit actually transferring or -1 if controller idle QSEEK/ per-unit, -1 if seeking QRCAL/ per-unit, -1 if recalibrating That's the first line of figuring out what the software thinks it's doing. Also put a breakpoint at QINT3X before starting the system and see how many times it gets there. QINTE is a good place to put a breakpoint, too (most disk errors go there). Put a breakpoint at RHCHEK if you want to see every command it sends to the disk. Breakpoint at QINTAT+2 to intercept attention handling (Q is drive number). My guess is it initiated the first seek and then lost when the attention came back, since %HXSC and %HMSEK are in QCST. I don't have very high confidence in this guess, though. It's quite a mystery.  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 6 Nov 86 04:02:46 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 5 Nov 86 23:00:00-PST Date: Wed 5 Nov 86 22:40:22-PST From: Mark Crispin Subject: Re: not so sad news To: ALAN@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].114842.861105.ALAN> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12252683444.7.MRC@PANDA> Hi - I tried it again. Each time QCST contained 104204. NQSATN, NQEATN, and NQOFFL all contained 0. I suspected as much, since the disks I am using have no errors, ECC or otherwise. I rather doubt that it is disks interrupting endlessly. From what I was able to trace, it looked like the code was looping at interrupt level and never dismissing. -- Mark -- -------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 6 Nov 86 02:22:58 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 151579; Thu 6-Nov-86 02:17:18 EST Date: Thu, 6 Nov 86 02:17 EST From: David A. Moon Subject: sad news: RM03 disk code fails to work on first try To: Mark Crispin cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <12252483811.7.MRC@PANDA> Message-ID: <861106021703.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed 5 Nov 86 04:23:45-PST From: Mark Crispin Presently I halted it and poked around. I found that the system was looping in the code at QINT2C. It would eventually get to the SKIPGE D,QSRAC(C) at QINT2L+2; QSRAC+36 contained 0 so it jumped back to QINT2C, go to the SETO C, at QINT2D+1, and began the cycle again. This doesn't make complete sense, because if the SKIPGE D,QSRAC(C) skipped (having a 0 operand), it would have skipped -over- the JRST QINT2C. More likely the instruction before it, SKIPL QUSR(C), skipped (i.e. this disk channel was not in use). My question would be, did it get to QINT3X or was it looping inside the disk scheduler proper? I would expect it to find nothing to do on the disk and come out to QINT3X. I guess that's the root of Alan's continuous interrupt theory too. Note the comment there that the RH11 doesn't seem to need to reset pending interrupt requests. If it is getting to QINT3X, but just interrupting again, the best way to proceed would be to see what the hardware thinks it's doing. Note: the software causes a disk interrupt every 1/2 second, for the benefit of broken disk controllers, so it might look to you like it's interrupting continuously when its problem is really something else. The SH (is that right?) command to the front-end to get to DDT should work if it's not in continuous disk interrupts; it's implemented by PI7, the lowest priority interrupt level. Don't blame me, I didn't write this disk code. It's actually very straightforward, but that fact is obscured because almost all of the labels are remarkably poorly chosen. I'm told it started life as microtape code and gradually evolved. Another guess I have is that you have extra RM03s that you didn't tell ITS about. I don't think we've tried having extra disk drives attached to an RH11 before. Were they on-line? Powered-up? Of course extra drives shouldn't screw things up, but there might be a bug. I initially thought it was looping in the salvager, but after running the standalone salvager and poking around a bit I realized it was looping in ITS. I tried starting ITS at GO without running the salvager; this time it got stuck in the code including QDW3/QPOSR+11, etc. My guess is that this is simply another point in the same loop, not a different symptom. please consider replacing the cretinous ITS EDDT with DEC EDDT or KDDT. I imagine you have already considered this, since there really is no good reason for yet another DDT. Thanks for the suggestion, but I don't think we're interested. "Cretinous" and "yet another" are relative terms. From our point of view the DEC EDDTs are "yet another". Turning to more important matters, if you want to debug this you are quite welcome to. I don't think MIT has a lot of resources for software support, and I really shouldn't be spending a great deal of time on this either. ITS comes to you on an as-is basis, as they say. I'm sure this would be a helluva lot faster than trying to second-guess the problem remotely and sending another set of tapes only to find that they fail too... Sure, but I imagine if the bug is diagnosed at this end, we would send you a patch to type in rather than fussing around with tapes. If you're familiar with the RH11 hardware it would probably be quickest for you to diagnose it yourself, unless the problem is really something intricate in the software rather than a straightforward hardware-related problem. That would be the thing to look for first, in my experience.  Date: Wed, 5 Nov 86 19:41:41 EST From: Alan Bawden Subject: not so sad news To: MRC@PANDA.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 5 Nov 86 04:23:45-PST from Mark Crispin Message-ID: <[AI.AI.MIT.EDU].114842.861105.ALAN> Date: Wed 5 Nov 86 04:23:45-PST From: Mark Crispin ... I regret to inform you that the installation was unsuccessful. Well I understand that you are disappointed, but I'm actually impressed that it worked as smoothly as it did. Specifically, I'm happy to hear that the salvager apparently works. I got as far as building @ ITS and running it. It typed "Salvager 226" and pawed over the disks for a while. It then typed a CRLF and went silent. I waited several minutes and nothing happened. Presently I halted it and poked around. I found that the system was looping in the code at QINT2C. It would eventually get to the SKIPGE D,QSRAC(C) at QINT2L+2; QSRAC+36 contained 0 so it jumped back to QINT2C, go to the SETO C, at QINT2D+1, and began the cycle again. I initially thought it was looping in the salvager, but after running the standalone salvager and poking around a bit I realized it was looping in ITS. I tried starting ITS at GO without running the salvager; this time it got stuck in the code including QDW3/QPOSR+11, etc. Well, it looks like the RM03 is continuously interrupting, since all of this is interrupt level disk code. It would be interesting to know what was in: QCST ; Contents of CS1 register of disk controller when it last ; interrupted. NQSATN ; Count of spurious attention interrupts NQEATN ; Count of attention interrupts reporting errors in mid-transfer NQOFFL ; Count of times drive dropped offline There are a bunch of other disk variables you might check, but I'm initially betting this has something to do with some of the disk error randomness we have observed here, and something the RM03 does makes the bug worse. It would be nice if there was a way to take a crash dump so that we could look at it... I have two immediate suggestions. First is that ITS should note various "landmarks" in what it is doing, such as outputting ITS.nnnn when it takes over from the salvager.... Actually, that's what the CRLF the salvager types is for. We don't seem to be great fans of verbosity here in ITS land. Second, please consider replacing the cretinous ITS EDDT with DEC EDDT or KDDT. I imagine you have already considered this, since there really is no good reason for yet another DDT.... I don't think we ever considered this seriously. It took about 100 keystrokes to successfully convert Exec DDT to the KS10, and once it was working we never though about it again.  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 5 Nov 86 07:53:52 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 5 Nov 86 04:38:24-PST Date: Wed 5 Nov 86 04:23:45-PST From: Mark Crispin Subject: sad news To: KS-ITS@AI.AI.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12252483811.7.MRC@PANDA> Friends - I received my ITS distribution set on Tuesday, and attempted to install it early this morning after some DECnet(ugh!) hacking. I regret to inform you that the installation was unsuccessful. I got as far as building @ ITS and running it. It typed "Salvager 226" and pawed over the disks for a while. It then typed a CRLF and went silent. I waited several minutes and nothing happened. Presently I halted it and poked around. I found that the system was looping in the code at QINT2C. It would eventually get to the SKIPGE D,QSRAC(C) at QINT2L+2; QSRAC+36 contained 0 so it jumped back to QINT2C, go to the SETO C, at QINT2D+1, and began the cycle again. I initially thought it was looping in the salvager, but after running the standalone salvager and poking around a bit I realized it was looping in ITS. I tried starting ITS at GO without running the salvager; this time it got stuck in the code including QDW3/QPOSR+11, etc. I have two immediate suggestions. First is that ITS should note various "landmarks" in what it is doing, such as outputting ITS.nnnn when it takes over from the salvager. The salvager should do something like type a dot every n whatevers so the user knows that it is doing something useful. Second, please consider replacing the cretinous ITS EDDT with DEC EDDT or KDDT. I imagine you have already considered this, since there really is no good reason for yet another DDT. Is DEC EDDT too big? Poking at the hangs would have been a lot easier had some very basic things such as single-stepping worked (I tried both $X and CTRL/N). Turning to more important matters, if you want to debug this you are quite welcome to. I have an active KLINIK on my 2020; just give me a call before I leave at around noonish (3PM your time) and I'll be happy to give you KLINIK access and standalone time on my system for the rest of the afternoon. I think my wife will be home so she could assist (e.g. mounting tapes) if you need. I'm sure this would be a helluva lot faster than trying to second-guess the problem remotely and sending another set of tapes only to find that they fail too... -- Mark -- -------  Received: from DIAMOND.S4CC.Symbolics.COM (TCP 20024231403) by AI.AI.MIT.EDU 4 Nov 86 16:33:11 EST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24769; Tue 4-Nov-86 16:27:49 EST Date: Tue, 4 Nov 86 16:27 EST From: David C. Plummer Subject: For those of you around MIT this January To: Alan Bawden , KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN> Message-ID: <861104162735.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sat, 25 Oct 86 01:38:44 EDT From: Alan Bawden Hackers, It has been suggested that it might be a good idea to teach an ITS course during IAP this year. We have done this twice before with somewhat mixed results. A few sessions were quite memorable, and a few were dogs. Before I decide if I want to front for this again this year, I would like to hear from some other people. Specifically I want to hear: Things people want to learn about. Opinions about what has worked in the past. Volunteers who would enjoy teaching about something. Ways of using this to burn excess machine cycles on our many (!) ITS machines. (Student project ideas?) I don't think I have any of my notes from IAP'83. Do you (Alan) have any from IAP'84? I seemed to remember talking about some of the following: UUOs/.CALL, their skip-on-success feature, their argument passing/returning syntax TTY management Devices, MLDEV:, CLU/I/O/A:, etc Jobs (and BOJs) File system, links, etc. Greenblat's History lecture Moon's hardware description of (the original) AI With the general proliferation of PCs and high level languages, some of the more gutsy things, which are the interesting things, may require a (refresher) course on the assembly language concepts.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 27 Oct 86 06:51:15 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708249629097960@MIT-MULTICS.ARPA>; 27 Oct 1986 06:33:49 est Date: 26 Oct 86 23:36 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, "Alan Bawden" Subject: For those of you around MIT this January Message-ID: <212189@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN> We are interseted from Stockholm, two persons, major interest: ITS Internals, what is doing what, and what is speaking to what internaly.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 27 Oct 86 06:51:03 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708249573622794@MIT-MULTICS.ARPA>; 27 Oct 1986 06:32:53 est Date: 26 Oct 86 23:38 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Mark Crispin" , "Douglas Humphrey" Cc: "John Wroclawski" , Moon@SCRC-STONY-BROOK.ARPA, "Alan Bawden" , KS-ITS@AI.AI.MIT.EDU Subject: Re: ITS RM03 support, etc. Message-ID: <212190@QZCOM> In-Reply-To: <8610250132.AA15004@eneevax.umd.edu> 1 MW memory for 2020, it is in my input queue of things to look over and decide to do or not. But nothing will se dayligt this year.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 26 Oct 86 19:15:06 EST Received: by eneevax.umd.edu (5.9/4.7) id AA21259; Sun, 26 Oct 86 19:13:17 EST Date: Sun, 26 Oct 86 19:13:17 EST From: Douglas Humphrey Message-Id: <8610270013.AA21259@eneevax.umd.edu> To: Gumby@AI.AI.MIT.EDU, deh@ENEEVAX.UMD.EDU Subject: Re: TOPS-20 TCP/IP Cc: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, MRC%PANDA@SUMEX-AIM.Stanford.EDU, ks-its@AI.AI.MIT.EDU Sorry for the tops-20 discussions. I am just trying to figure a way to have TCP/IP support on my 2020. I would like to have it under ITS, but that that looks doubtful. Any suggestions or ideas on TCP/IP ITS would be great. We will keep the tops stuff short. Thanks, Doug  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 26 Oct 86 12:38:22 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 26 Oct 86 09:31:43-PST Date: Sun 26 Oct 86 08:20:51-PST From: Mark Crispin Subject: Re: RM03 support To: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <8610261436.AA10176@geneva> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249905534.7.MRC@PANDA> Guillermo Rozas makes a good point, but I think time will eventually invalidate it. The general trend in the industry is to move away from lots and lots of funky terminal protocols towards a ANSI. By far the biggest market is the VTxxx and compatible market. The one thing that is vendor-dependent are the timing considerations (although some vendors are careful to emulate DEC's timings to the point of adding delay loops since some applications have cared!). That is why most of us have thrown up our hands in despair of ever getting padding to work and settled on XON/XOFF, with all of its problems. It *would* be nice to flush CRTSTY for all the ANSI terminals, wouldn't it? I don't see how that can be done without XON/XOFF. I wish this was not the case; I admit it, it took me a *long* while to unlearn CTRL/S for search. -------  Received: from geneva by AI.AI.MIT.EDU 26 Oct 86 09:43:38 EST Received: by GENEVA.AI.MIT.EDU; Sun, 26 Oct 86 09:36:37 est Date: Sun, 26 Oct 86 09:36:37 est From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-Id: <8610261436.AA10176@geneva> To: MRC%PANDA@SUMEX-AIM.Stanford.EDU Cc: Alan@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.Stanford.EDU, ks-its@AI.AI.MIT.EDU In-Reply-To: Mark Crispin's message of Sat 25 Oct 86 13:17:31-PDT Subject: RM03 support Neither of these are really hard, and it would be nice to be able to flush CRTSTY, wouldn't it? I don't think flushing CRTSTY is reasonable. I think it is perfectly reasonable for the operating system to support intrinsically only a small set of terminals (the most common terminals), and to have a program like CRTSTY which can be used when you don't use a standard terminal. Manufacturers are likely to come up with completely random terminals, and if there were nothing like CRTSTY the support would have to be added to the operating system every time a new one appeared. What the set of intrinsically supported terminals should be is debatable, and "installation" dependent, and it is perfectly reasonable to add common terminals of the VTxxx flavor, but CRTSTY is too convenient to give up.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Oct 86 21:45:44 EDT Date: Sat, 25 Oct 1986 21:44 EDT Message-ID: From: Rob Austein To: Mark Crispin Cc: ks-its@AI.AI.MIT.EDU Subject: ANSI ttys In-reply-to: Msg of 25 Oct 1986 19:22-EDT from Mark Crispin Date: Saturday, 25 October 1986 19:22-EDT From: Mark Crispin Has anyone actually tried the AAA stuff on a VT100? You need to turn off insert/delete for some of them, but if the AAA is a real ANSI terminal it should work alright. Yes, I have. :TCTYP AAA HEIGHT 24 -%TOLID -%TOCID (to be safe) still doesn't work quite right. It loses on cursor addressing (I think). Telnet in, do this TCTYP, and run SRA;TS ALICE and you'll see what's wrong in a jiffy (it does get the reverse video mode line right, I'll give it that).  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 25 Oct 86 19:41:03 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 25 Oct 86 16:38:50-PDT Date: Sat 25 Oct 86 16:22:23-PDT From: Mark Crispin Subject: Re: RM03 support To: JTW%MIT-SPEECH@XX.LCS.MIT.EDU cc: ks-its@AI.AI.MIT.EDU In-Reply-To: <12249702614.27.JTW@MIT-SPEECH> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249720129.7.MRC@PANDA> Once you (reluctantly I admit) resign yourself to XON/XOFF flow control, you don't have to worry about issues like what happens over a network. You do the flow control at the local end (e.g. at the TAC). In fact, that's how most commercial networks work and you have to go to extremes to prevent them from intercepting the flow control characters. I'm not arguing against padding VT100 support; by all means VT100 support should be added with padding! What I'm asking for is for XON/XOFF support as well, as a separate issue. TCTYP can be taught that VT125 is simply VT100+XON/XOFF, etc. Has anyone actually tried the AAA stuff on a VT100? You need to turn off insert/delete for some of them, but if the AAA is a real ANSI terminal it should work alright. -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Oct 86 17:54:28 EDT Date: Sat, 25 Oct 1986 17:53 EDT Message-ID: From: Rob Austein To: Mark Crispin Cc: Alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU Subject: RM03 support In-reply-to: Msg of 25 Oct 1986 16:17-EDT from Mark Crispin ITS supports AAAs, and they're ANSI ttys.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 OCT 86 17:48:17 EDT Date: Sat 25 Oct 86 17:46:11-EDT From: "John Wroclawski" Subject: Re: RM03 support To: mrc%panda@SUMEX-AIM.ARPA cc: ks-its@AI.AI.MIT.EDU In-Reply-To: <12249686475.7.MRC@PANDA> Message-ID: <12249702614.27.JTW@MIT-SPEECH> Adding interrupt-level ^S/^Q processing wouldn't be all that hard, specially for machines like the KS where I-level TTY code runs entirely on the -10 rather than half in an 11. However this approach is useless for terminals connected by a network. I think it might be worth doing padding-based support for the VT100 because almost all of the third-party VT100 clones are faster than the DEC version, and padding to the DEC numbers makes them all work. ITS already knows about Ambassadors, which i believe are close to ANSI. -------  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 25 Oct 86 17:22:48 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 25 Oct 86 14:13:43-PDT Date: Sat 25 Oct 86 13:17:31-PDT From: Mark Crispin Subject: Re: RM03 support To: Alan@AI.AI.MIT.EDU cc: MRC%PANDA@SUMEX-AIM.Stanford.EDU, ks-its@AI.AI.MIT.EDU In-Reply-To: <861024070131.1.ALAN@PIGPEN.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249686475.7.MRC@PANDA> Speaking about VTxxx terminals, I might be interested in doing something about ITS support for them. Does ITS support ANY ANSI terminals? I see two issues that would need to be addressed and discussed. First is the entire question of XON/XOFF. There are simply too many VTxxx sorts of terminals from different vendors, each with different timings, to make padding practical. It might be worth a try for the basic DEC VT100 (since DEC publishes those timings), but after that forget it. Among other things, you have terminals in which you can NOT disable automatic XON/XOFF. I'm directly aware of the printer port option and the VT125 (graphics) terminal as ones in which you must use XON/XOFF. My suggestion is that there be a terminal bit that says "use XON/XOFF", and that some convenient means be set up to send CTRL/Q and CTRL/S to the application. Perhaps CTRL/\ could be a "system controllifier", so CTRL/\ S would be a logical CTRL/S, etc. Don't flame about how this is being cretinous. Instead, take this as an exercise. Suppose some worldwide glitch fried all non-XON/XOFF terminals and you *had* to use an XON/XOFF terminal. How would you change the software so you can win? Internally, the XON/XOFF bit should disable ALL padding (it is now completely unnecessary) and an XOFF should be responded to immediately. So at some interrupt level a CTRL/S should freeze the output driver. I'm sure other people on the list have a better idea of how to do this than I do. The second issue is on a VT200 series terminal. There, the wonderful people at DEC decided that ESCAPE was an internal terminal/host protocol character and not a user character. I remember Tom Porcher telling me what a great idea this was (cough). What most of us do to work around this lossage is to map backquote (`) to be ESCAPE since the backquote key is where ESCAPE should be. TOPS-10 has a "SET TTY ESCAPE n" to set the ESCAPE key to be ASCII n (octal). Neither of these are really hard, and it would be nice to be able to flush CRTSTY, wouldn't it? -------  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 25 Oct 86 17:15:58 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 25 Oct 86 14:08:56-PDT Date: Sat 25 Oct 86 13:04:06-PDT From: Mark Crispin Subject: Re: TOPS-20 TCP/IP To: Gumby@AI.AI.MIT.EDU cc: ks-its@AI.AI.MIT.EDU In-Reply-To: <861025140407.3.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249684031.7.MRC@PANDA> Much more time is wasted on the endless stream of whiney "Subject X is not appropriate to this list, use list Y instead" that the whiners feel must be sent to the entire list instead of merely to the offender. There is a wonderful function called "DELETE" or "KILL" in most mail reading programs which allows the fast excision of uninteresting messages from a mail file. Personally, I happen to be interested in the issue of TCP/IP on KS's in general and of the various networking options available. Not everybody is going to be conveniently located to an IMP. It might be worthwhile to have a unified ITS/TOPS-20 KS TCP/IP project to avoid needless wheel reinvention. I know that the TOPS-20 TCP/IP is badly out of tune in most systems; Stanford has been able to performance improvements that at times are an order of magnitude. I haven't yet seen a good assessment of the ITS TCP/IP. My impression from the west coast is that ITS' TCP is mediocre. It doesn't seem to handle hosts coming in through gateways well. Of course, KLH didn't have much time to work on it, and the overall quality of the hardware interfaces is questionable. We PDP-10 fans need to work together on common software projects. There are entirely too few of us left to be fighting these OS holy wars. I WOULD like to see some talk about what we can do to have a KS TCP that supports various funky networking environments (like TOPS-20 multinet but better) and that can be fit in to any of the current PDP-10 OS's. -------  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 25 Oct 86 16:49:07 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708109285377369@MIT-MULTICS.ARPA>; 25 Oct 1986 16:34:45 edt Date: 25 Oct 86 17:33 +0100 From: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Mark Crispin" , Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: KS-ITS@AI.AI.MIT.EDU, "Douglas Humphrey" Subject: RM03 support Message-ID: <211994@QZCOM> In-Reply-To: <211801@QZCOM> NUMCYL should be ^D821, as far as I can remember, not to try to overwrite the maintainance cylinder, which TOPS-10 woun't allow you to do (that's why I never bothered to correct that bug).  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Oct 86 15:47:35 EDT Date: Sat, 25 Oct 1986 15:46 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: For those of you around MIT this January In-reply-to: Msg of 25 Oct 1986 01:38-EDT from Alan Bawden Gee, I haven't taught a short course since I left Wesleyan. Sounds like fun. TECO, theory and practice?  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 OCT 86 14:07:01 EDT Received: from MOSCOW-CENTRE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 8191; Sat 25-Oct-86 14:04:03 EDT Date: Sat, 25 Oct 86 14:04 EDT From: David Vinayak Wallace Subject: TOPS-20 TCP/IP To: Douglas Humphrey cc: MRC%PANDA@SUMEX-AIM.Stanford.EDU, JTW%MIT-SPEECH@XX.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU, Gumby@AI.AI.MIT.EDU In-Reply-To: <8610250132.AA15004@eneevax.umd.edu> Message-ID: <861025140407.3.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU> I am not interested in tops-20. Please do not discuss it on ks-ITS! Start ks-TOPS-20 instead!  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Oct 86 02:21:54 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA23785; Sat, 25 Oct 86 02:20:02 EDT Date: Sat, 25 Oct 86 02:20:02 EDT From: Douglas Humphrey Message-Id: <8610250620.AA23785@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: Re: For those of you around MIT this January Let me know when these courses would be and such and count me in. If I'm going to have one, these might be real helpful and certainly a Lot of fun. Doug  Date: Sat, 25 Oct 86 01:38:44 EDT From: Alan Bawden Subject: For those of you around MIT this January To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].110499.861025.ALAN> Hackers, It has been suggested that it might be a good idea to teach an ITS course during IAP this year. We have done this twice before with somewhat mixed results. A few sessions were quite memorable, and a few were dogs. Before I decide if I want to front for this again this year, I would like to hear from some other people. Specifically I want to hear: Things people want to learn about. Opinions about what has worked in the past. Volunteers who would enjoy teaching about something. Ways of using this to burn excess machine cycles on our many (!) ITS machines. (Student project ideas?)  Date: Sat, 25 Oct 86 01:10:36 EDT From: Alan Bawden Subject: PM tapes are on their way! To: deh@ENEEVAX.UMD.EDU, KS-ITS@AI.AI.MIT.EDU, MRC@PANDA.MIT.EDU In-reply-to: Msg of Fri 24 Oct 86 07:01 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].110493.861025.ALAN> OK, I made a set of tapes for MRC. Sure enough, -after- making the tapes I got Peter's message, and that code is -inconsistent- with everything else I have seen about formatting RM03's! Well, I'm not about to hack any more on this now, so we will just mail off the tapes as they are now. If MRC has some trouble formatting his ITS pack, it should be a simple matter to mail him a little patch to let him try it the way Peter's code does it.  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 24 Oct 86 23:42:27 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 24 Oct 86 20:38:54-PDT Date: Fri 24 Oct 86 19:50:17-PDT From: Mark Crispin Subject: Re: ITS RM03 support, etc. To: deh@ENEEVAX.UMD.EDU cc: MRC%PANDA@SUMEX-AIM.Stanford.EDU, JTW%MIT-SPEECH@XX.LCS.MIT.EDU, alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA In-Reply-To: <8610250132.AA15004@eneevax.umd.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249495831.7.MRC@PANDA> TOPS-20 TCP/IP in the DEC and PANDA monitors support the AN20, NIA20, and CI20 interfaces. Stanford has support for the MEIS, CMU has support for TTY lines, but I wouldn't use TTY lines on a 2020. I suspect that if anyone does TOPS-20 TCP/IP for a 2020 it will be me, and I'm presently not motivated to do it. -------  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 24 Oct 86 21:34:48 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA15004; Fri, 24 Oct 86 21:32:14 EDT Date: Fri, 24 Oct 86 21:32:14 EDT From: Douglas Humphrey Message-Id: <8610250132.AA15004@eneevax.umd.edu> To: MRC%PANDA@SUMEX-AIM.Stanford.EDU, deh@ENEEVAX.UMD.EDU Subject: Re: ITS RM03 support, etc. Cc: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU I guess the real question is, how Small a Matter of Programming is it to get the TCP/IP code running on the 2020 ? Is this something that is on anyones list of things to do anytime soon? How big is it really and would it fit on the machine easily ? Would it hog the machine so badly that nobody would be able to use it ? What types of communications devices does tops-20 tcp/ip know how to use ? Doug P.S. Maybe running it would be better with the memory on the 2020 taken up to 1024K ? Peter, what i the status of that effort ? Thanks.  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 24 Oct 86 21:18:40 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 24 Oct 86 18:13:31-PDT Date: Fri 24 Oct 86 17:10:02-PDT From: Mark Crispin Subject: Re: ITS RM03 support, etc. To: deh@ENEEVAX.UMD.EDU cc: MRC%PANDA@SUMEX-AIM.Stanford.EDU, JTW%MIT-SPEECH@XX.LCS.MIT.EDU, alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA In-Reply-To: <8610241706.AA02701@eneevax.umd.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249466657.7.MRC@PANDA> Yes, TOPS-20 has TCP/IP, but not for 2020's. It's a Small Matter of Programming to port the 2060 TCP/IP to a 2020 (mostly getting it all to fit in an 18 bit address space). -------  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 24 Oct 86 20:50:12 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708035674217159@MIT-MULTICS.ARPA>; 24 Oct 1986 20:07:54 edt Date: 24 Oct 86 20:20 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Mark Crispin" Cc: KS-ITS@AI.AI.MIT.EDU, "Douglas Humphrey" Subject: RM03 support Message-ID: <211801@QZCOM> In-Reply-To: <861024070131.1.ALAN@PIGPEN.AI.MIT.EDU> A Program that formats RM02/RM03 under timecharing on a T10 system:: TITLE RM02 SEARCH UUOSYM,MACTEN NUMSEC==^D30 NUMTRK==^D5 NUMCYL==^D822 SEC==1 TRK==2 CYL==3 ADR==4 NUM==5;NUM+1==6 START: RESET OPEN[ EXP IO.WHD+.IODMP SIXBIT "RM02" XWD 0,0] JRST[ OUTSTR[ ASCIZ "Please assign the logical name RM02:"] MONRT. JRST START] MOVSI CYL,-NUMCYL NXTCYL: MOVSI TRK,-NUMTRK OUTSTR[ ASCIZ "Formatting cylinder "] MOVEI NUM,(CYL) IDIVI NUM,^D100 MOVEI NUM,"0"(NUM) OUTCHR NUM MOVE NUM,NUM+1 IDIVI NUM,^D10 MOVEI NUM,"0"(NUM) OUTCHR NUM MOVEI NUM,"0"(NUM+1) OUTCHR NUM NXTTRK: SETZM BUFFER MOVE[ XWD BUFFER,BUFFER+1] BLT BUFEND MOVSI SEC,-NUMSEC MOVEI ADR,BUFFER NXTSEC: MOVSI 140000 MOVEM (ADR) DPB CYL,[POINT 10,(ADR),17] DPB TRK,[POINT 5,(ADR),27] DPB SEC,[POINT 5,(ADR),35] ADDI ADR,202 AOBJN SEC,NXTSEC MOVEI ADR,(CYL) IMULI ADR,(TRK) IMULI ADR,NUMSEC TXO ADR,SU.SOT SUSET. ADR, HALT OUT[ IOWD BUFEND+1-BUFFER,BUFFER EXP 0] SKIPA HALT AOBJN TRK,NXTTRK OUTCHR[ EXP .CHCRT] AOBJN CYL,NXTCYL MONRT. JRST START BUFFER: BLOCK 202*NUMSEC BUFEND==.-1 END START  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 24 Oct 86 15:03:07 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA02701; Fri, 24 Oct 86 13:06:51 EDT Date: Fri, 24 Oct 86 13:06:51 EDT From: Douglas Humphrey Message-Id: <8610241706.AA02701@eneevax.umd.edu> To: MRC%PANDA@SUMEX-AIM.Stanford.EDU, deh@ENEEVAX.UMD.EDU Subject: Re: ITS RM03 support, etc. Cc: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU We are looking at a number of options for medium speed comm from my 2020 to a local friendly arpanet site. This site has mentioned that they may be able to hang me on their local ethernet if I can arrange to get there from my place. What I need to figure out is : 1. How best to get a medium to high speed link there. 2. How to connect it to the 2020 such that I have TCP/IP support for mail, telnet (in and out), etc. The comm link is not that hard. I can run a leased line with modems on both end. Commercialy available, hardware is cheap, monthly costs expensive. I can run a microwave link in two hops using 27Ghz short haul gear. Commercialy available, hardware more expensive (but not a lot), monthly costs cheap (almost nil). Hard rain or heavy fog will cut my bandwidth way down at those frequencys, but I can run a 56kbps link easily. The big problem is the 2020 end. I don't know a lot about the TOPS-20 TCP/IP facilities (do they exist ?). I think I have at least one KMC/DUP set here so that might be a good thing. That gives me a DDCMP based link. Now how do I get that into an ethernet and become part of their local net ? Doug  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 OCT 86 07:04:22 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 7983; Fri 24-Oct-86 07:01:55 EDT Date: Fri, 24 Oct 86 07:01 EDT From: Alan Bawden Subject: RM03 support To: MRC%PANDA@SUMEX-AIM.Stanford.EDU cc: ks-its@AI.AI.MIT.EDU, deh@eneevax.umd.edu In-Reply-To: <12249005953.7.MRC@PANDA>, <8610212307.AA29158@eneevax.umd.edu>, <12227518754.6.MRC@PANDA>, <12194376505.9.MRC@PANDA>, <[MIT-MC.ARPA].737808.851201.MRC> Message-ID: <861024070131.1.ALAN@PIGPEN.AI.MIT.EDU> OK, I have possibly finished the RM03 support. I am not 100% confident that this will work the first time since I have -never- seen adequate RM03 documentation. Let me give you an example: I only yesterday learned by examing a disk formatting program that you supplied me with, that the RM03 has only a -single- word of header attached to each sector. If I hadn't discovered this, the formatting code in the Salvager would certainly have failed to work. Some minor reorganization in the Salvager was required to deal with this. I have no reason to believe that there aren't other problems lurking here for the first RM03 ITS system to trip over. In any case I have now assembled all of the relevant binaries and printed a set of documentation for your system. I can write the tapes any time I want, but I thought I would just double-check the configuration once before I do: System name: PM (for PandaMonium) Memory: 512K (a full house) Disks: RH11 with -one- RM03 (Your system has two more, but they are none of ITS's business) Tape: RH11/TM03 (The drive is a TU45, which we have never tried with the ITS magtape code, but we believe this will work fine anyway.) Terminals: T00: Console TTY (driven by 8080 front-end) (ITS does not have code to drive the KLINIK line) One DZ11 with five lines in use: T01: 4800 baud T02: 9600 baud, H19 T03: 1200 baud, Dialup T04: 1200 baud, Dialup T05: 9600 baud (Two of these are known to be a VT100 and a VT125, but ITS doesn't support those directly (amazingly enough).) T06: - T11: Pseudo-TTY's Say this is correct, and I will cut some tapes and mail the whole mess to: Mark Crispin 1802 Hackett Ave. Mountain View, CA 94043-4431  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 OCT 86 23:48:23 EDT Date: Wed 22 Oct 86 23:46:42-EDT From: "John Wroclawski" Subject: Re: ITS RM03 support, etc. To: MRC%PANDA@SUMEX-AIM.ARPA, deh@ENEEVAX.UMD.EDU cc: KS-its@AI.AI.MIT.EDU In-Reply-To: <12248952763.10.MRC@PANDA> Message-ID: <12248981814.5.JTW@MIT-SPEECH> From: Mark Crispin Subject: Re: ITS RM03 support, etc. My guess is that AI is using an AN22, DEC's impterface (I couldn't resist that one!) for the 2020. AI and MC use ACC LH/DH Unibus 1822 interfaces. I think the best way for a 2020 to get on Internet is to get a DN20-BA (also known as a KDP or KMC11/DUP11) and talk IP on that. Unless you want to hack KMC11 microcode you'll be using DDCMP for the low level protocol. This is a pretty reasonable approach, if you can find someone at the other end that can speak DDCMP and knows how to be a gateway. KMC/DUP11s are nice and cheap in the used market these days. I'd imagine someone out there is using these things to connect 4.xBSD vaxes with IP; I'd figure out their encapsulation and use it. Seems to me DEC also makes a similar but newer frob that runs at much higher speeds, if you can get a 56Kb line. If the best you can do is a TTY line at 1200b, I'd agree with mark about doing something else instead. Maybe even at 9600, if you want remote login to work well. Another way of going IP is to buy a DEUNA from DEC and hook up to an Ethernet. I would think an Interlan ethernet card would be a better bet. But now you -really- have to have someone to talk to. There's also the question of ITS code. I don't know whether or not ITS has a Multinet facility, but I sort of doubt it. It doesn't. It's beginning to need it. There are some hassles but it's not horribly hard. I hope we can do a little better than Multinet. MIT will most likely do a driver for Interlan NI1010 ethernet cards, and some possibility of a Proteon 10Mb ring driver. The other things which have been mentioned but we aren't at all likely to do are DEUNAs, KDPs and some kind of TTY-line driver. -------  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 22 Oct 86 21:16:57 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 22 Oct 86 18:11:41-PDT Date: Wed 22 Oct 86 18:07:07-PDT From: Mark Crispin Subject: Re: ITS RM03 support, etc. To: deh@ENEEVAX.UMD.EDU cc: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA In-Reply-To: <8610222158.AA20389@eneevax.umd.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12248952763.10.MRC@PANDA> DCA is indeed requiring X.25 connections to PSNs (what IMPs are called these days), replacing the old 1822 connection. Internally, it all becomes 1822, making the exercise somewhat silly, but it's all part of the "international standardization" time-waste going on. My guess is that AI is using an AN22, DEC's impterface (I couldn't resist that one!) for the 2020. There probably aren't many AN22's in the world, and I'll bet that MIT has most or all of 'em! This was an 1822 device, and actually wasn't all that bad (it would have used on the late lamented KC10 a.k.a. Jupiter). The AN10 and AN20 (I/O bus for KA, KI, and KL) were funky and their demise is no loss! I think the best way for a 2020 to get on Internet is to get a DN20-BA (also known as a KDP or KMC11/DUP11) and talk IP on that. Unless you want to hack KMC11 microcode you'll be using DDCMP for the low level protocol. A KDP supports between 2K and 20K baud and is synchronous, so you'd have no problem with a 9600 baud modem. I've thought about hacking TOPS-20 so TCP/IP runs on 2020's again and talk IP on my KDP instead of DECnet, but not until I get a faster modem than the 1200 baud modem I'm using now. DECnet is painful at 1200 baud, IP is unusable. There's also the small matter of having somebody to talk to... The other thing to consider is whether or not IP is worth the cost of running it. Consider that: . for remote login, just dialing the host (or your friendly local PAD or TAC) will give you much better throughput than IP Telnet. You can tolerate line noise (else nobody would use terminals with modems) . for file transfer, Kermit is probably faster than IP FTP . for electronic mail, Cafard works quite well and with a 1-hour call interval (which PANDA uses) there isn't that much of an impact on real time communications. In the absence of a *fast* (at least 9.6K) line to PANDA, I have not felt that motivated to go to IP. PANDA does a lot of mail, since it's at the hub of a USENET-like network with 5 members (and growing; the latest member is NTT in Japan!), and it seems to have no problem handling the workload at 1200 baud. This is mostly because Cafard runs in the background with a semi-dedicated modem. Another way of going IP is to buy a DEUNA from DEC and hook up to an Ethernet. There has been talk of packet radio around here and a little Ethernet between the packet radio station and the 2020 might be the thing. There's also the question of ITS code. I don't know whether or not ITS has a Multinet facility, but I sort of doubt it. The interface to the IMP driver may be fairly modular and well defined, but I suspect that ITS is very much 1822-oriented and it would be a fair amount of work to fix it to use some other encapulation. This isn't a problem on TOPS-20; you just have the problem of writing the driver and making it all fit. Sorry for the length of this message. By the way, I too am interested in hearing about RM03 support. -- Mark -- -------  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 22 Oct 86 18:00:24 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA20389; Wed, 22 Oct 86 17:58:23 EDT Date: Wed, 22 Oct 86 17:58:23 EDT From: Douglas Humphrey Message-Id: <8610222158.AA20389@eneevax.umd.edu> To: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, deh@ENEEVAX.UMD.EDU Subject: Re: ITS RM03 support, etc. Cc: alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU If they want X.25, I do have an X.25 PAD hardware system here that takes 16 erial lines and does all of the X.25 PAD and routing functions for things like Telenet, Tymnet, etc. That might help things. What do you think ? Doug  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 22 Oct 86 17:58:19 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA20376; Wed, 22 Oct 86 17:56:43 EDT Date: Wed, 22 Oct 86 17:56:43 EDT From: Douglas Humphrey Message-Id: <8610222156.AA20376@eneevax.umd.edu> To: Moon@STONY-BROOK.SCRC.Symbolics.COM, deh@eneevax.umd.edu Subject: Re: ITS RM03 support, etc. Cc: alan@MIT-AI.ARPA, ks-its@MIT-AI.ARPA Networking over them phones might be vary easy if I can work out some way to impliment SLIP (Serial Line IP) as Chris Torak at Maryland and other unix folks have. I would still prefer to run on a leased line with it because of the line speed limitations on the phones. Anyone know a lot about SLIP and such ? I assume that hooking into an IMP is not a serial process ? Doug  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 OCT 86 16:20:09 EDT Date: Wed 22 Oct 86 16:13:35-EDT From: "John Wroclawski" Subject: Re: ITS RM03 support, etc. To: Moon@SCRC-STONY-BROOK.ARPA, deh@ENEEVAX.UMD.EDU cc: alan@AI.AI.MIT.EDU, ks-its@AI.AI.MIT.EDU In-Reply-To: <861022145623.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12248899325.20.JTW@MIT-SPEECH> From: David A. Moon Subject: ITS RM03 support, etc. Date: Tue, 21 Oct 86 19:07:32 EDT From: Douglas Humphrey .... The way AI is connected requires an IMP on the premises. Perhaps you and MRC can get together and implement a facility for networking over phone lines. It's worse than that; I think DoD requires you to use the new X.25 host-IMP protocol for any new installations, so all of the current IMP driver stuff is worthless for new sites, even if you were able to get the IMP slot and the wires. -------  Received: from STONY-BROOK.SCRC.Symbolics.COM by AI.AI.MIT.EDU 22 Oct 86 14:58:52 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140198; Wed 22-Oct-86 14:56:41 EDT Date: Wed, 22 Oct 86 14:56 EDT From: David A. Moon Subject: ITS RM03 support, etc. To: Douglas Humphrey cc: alan@MIT-AI.ARPA, ks-its@MIT-AI.ARPA In-Reply-To: <8610212307.AA29158@eneevax.umd.edu> Message-ID: <861022145623.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 21 Oct 86 19:07:32 EDT From: Douglas Humphrey Also, how is AI connected to the arpanet and what hardware is it using, etc.? I am looking for information on how to connect the machine to the net running either the ITS or tops-20. Anyone out there have any information ? I am pretty sure that I have a site down here that help out, leased lines and stuff like that are not a problem, and I may even be able to get the strange hardware required, but I'll never know if someone doesn't let me know what is required. The way AI is connected requires an IMP on the premises. Perhaps you and MRC can get together and implement a facility for networking over phone lines.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 21 Oct 86 20:52:08 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA29158; Tue, 21 Oct 86 19:07:32 EDT Date: Tue, 21 Oct 86 19:07:32 EDT From: Douglas Humphrey Message-Id: <8610212307.AA29158@eneevax.umd.edu> To: alan@ai.ai.mit.edu, ks-its@ai.ai.mit.edu Subject: ITS RM03 support, etc. Now that I have cleared out the basement of all the junk that collects when moving houses, I have room for the 2020 system. I am going to have them ship it up here next week sometime. Given the delays for power and such to be hooked up, it will be at least 30 days until it comes up. Do you have any kind of word on ITS support of RM03 disks ? Initialy I will run tops-20 to let the system burn in, but I really can't wait to bring up ITS. Also, how is AI connected to the arpanet and what hardware is it using, etc.? I am looking for information on how to connect the machine to the net running either the ITS or tops-20. Anyone out there have any information ? I am pretty sure that I have a site down here that help out, leased lines and stuff like that are not a problem, and I may even be able to get the strange hardware required, but I'll never know if someone doesn't let me know what is required. Many Thanks, Doug deh@eneevax digex@mit-ai  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU 11 Sep 86 17:51:46 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 2582; Thu 11-Sep-86 17:49:02 EDT Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 9 Sep 86 19:58:24 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2704144710480925@MIT-MULTICS.ARPA>; 09 Sep 1986 19:18:30 edt Date: 09 Sep 86 23:43 +0200 From: jan_lien_bhg%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: jan_lien_bhg%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Alan Bawden" Subject: [rende: DEC's for sale ? Message-ID: <201053@QZCOM> Resent-To: ks-its@AI.AI.MIT.EDU Resent-From: Alan@AI.AI.MIT.EDU Resent-Date: Thu, 11 Sep 86 17:48 EDT Resent-Message-ID: <860911174853.2.ALAN@PIGPEN.AI.MIT.EDU> I am researching the market for old DEC-2020's, so to speak on behalf of the Stockholm School board. Would you happen to know anything about such machines for sale ? Or anybody else selling ?  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 AUG 86 11:55:42 EDT Date: Wed, 13 Aug 86 11:54:27 EDT From: "Devon S. McCullough" Subject: bean bag chairs to match your ITS box To: DIGEX@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 13 Aug 86 00:06:03 EDT from Doug Humphrey Message-ID: <[MX.LCS.MIT.EDU].940589.860813.DEVON> I am making some large foam bag chairs (squishier than beans) which sleep two comfortably. Place your order now! The first one will be roughly spherical (actually cylindrical but who's counting) with a diameter of five or six feet, with a tie-dyed denim outer cover. --Devon  Date: Wed, 13 Aug 86 00:06:03 EDT From: Doug Humphrey Subject: slowly it all starts To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].82849.860813.DIGEX> Well, a TU45 tape drive wandered in today. Not that I have a lot of useful things to do with just the tape drive, but I will assume that the rest of the system will follow. All my friends want me to paint the system Blue, like DEC-10's should be, rather than DEC-20 Orange, but those are the breaks. I wonder if anyone sells bean bag chairs in that same orange color ? I wonder if anyone sells them at all anymore... Doug  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 8 Aug 86 18:01:34 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2701374332756492@MIT-MULTICS.ARPA>; 08 Aug 1986 17:45:32 edt Date: 08 Aug 86 11:05 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "David A. Moon" , "Douglas Humphrey" Cc: KS-ITS@AI.AI.MIT.EDU Subject: Re: You'll never know how hard it is to distribute software until Message-ID: <193469@QZCOM> In-Reply-To: <8608071908.AA20038@eneevax.umd.edu> we are trying to write kmc11/dup11 syncrounus tcp/ip.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 7 Aug 86 15:11:52 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA20038; Thu, 7 Aug 86 15:08:18 EDT Date: Thu, 7 Aug 86 15:08:18 EDT From: Douglas Humphrey Message-Id: <8608071908.AA20038@eneevax.umd.edu> To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: You'll never know how hard it is to distribute software until Cc: KS-ITS@AI.AI.MIT.EDU Ref to Ethernet TCP/IP on ITS. Is there support for this now ? If so, the easiest (?) thing for me to do to put the machine on the arpanet would be to get a high speed link to the university of maryland, say a 27 gig microwave, and bingo, no problems. If no support now, when do you expect that you might work on this ? By the way, are there any places other than MIT, Stupi (sweden) and soon Washington DC (me) that are or will be running ITS ? Anyone else out there want to bring up a city ? Doug PS Opppss..can't forget MRC's panda on that list.  Date: Tue, 5 Aug 86 02:37:11 EDT From: "Pandora B. Berman" Subject: let's try that again To: BUG-KS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].79542.860805.CENT> so much for remembering to check the NAMED ERR file first... ---------- Date: Tue, 5 Aug 86 02:27:25 EDT From: "Pandora B. Berman" Subject: KS and ITS questions ad nauseum To: BUG-KS@AI.AI.MIT.EDU Date: Mon, 4 Aug 86 15:35:10 EDT From: Douglas Humphrey To: Alan@AI.AI.MIT.EDU, deh@eneevax.umd.edu Subject: Re: ks and ITS questions Cc: CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.ARPA, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU I assume... ok, i'm tired of seeing excessive headers. there is now BUG-KS@AI, for these nit-picking detailed discussions, comprised of all of us (even me too for a while); it includes the KSITS mail archive and is forwarded to from KS-ITS, which in the usual fashion is now reserved for issues of wider interest on the general subject. i have, i think, managed to save and dump into the archive file all msgs from the discussion of the past couple days.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 4 Aug 86 19:01:47 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA10089; Mon, 4 Aug 86 15:35:10 EDT Date: Mon, 4 Aug 86 15:35:10 EDT From: Douglas Humphrey Message-Id: <8608041935.AA10089@eneevax.umd.edu> To: Alan@AI.AI.MIT.EDU, deh@eneevax.umd.edu Subject: Re: ks and ITS questions Cc: CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.ARPA, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU I assume that the sleeze of piggybacking chips has been considered and rejected. Do the KS10 memory boards that are in it decode the entire address or are they one bit short ? Since we are only talking about 1 bit, there should be a pretty simple way to add that that. If we can make that happen, I may be able to get more KS10 memory boards (though at a price, no doubt) and bring a machine up to >512kw for experimentation. Doug  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 4 Aug 86 01:20:49 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 3 Aug 86 22:16:20-PDT Date: Sun 3 Aug 86 21:24:53-PDT From: Mark Crispin Subject: Re: ks and ITS questions To: Alan@AI.AI.MIT.EDU, deh@ENEEVAX.UMD.EDU cc: MRC%PANDA@SUMEX-AIM.ARPA, CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU In-Reply-To: <860803165944.6.ALAN@PIGPEN.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12228017246.6.MRC@PANDA> To elaborate on Alan's remarks a bit, the significant factor is not when users use more virtual memory than physical memory, but rather when the total amount of virtual memory used by all the active processes in their working sets exceeds physical memory. In other words, you want the sum of the private pages in the working sets of all the active processes plus all the shared pages that are in the working set of some active process. You also need some number of free pages or at least readily freeable pages so you can slurp stuff off the disk reasonably quickly. In general, TOPS-20 runs more users doing larger tasks better than ITS, but this is an artifact of the TOPS-20 paging system and the fact that most large TOPS-20 programs are carefully written to take advantage of the way paging works. On the other hand, ITS terminal I/O is probably quite a bit more efficient, especially terminal input. More significantly, MACLISP and all MACLISP-based tools run much better on ITS than on TOPS-20. The TOPS-20 conversion was poorly done and many of the things MACLISP does to take advantage of the ITS pager were never converted to the TOPS-20 equivalents. MACSYMA is a good example of a tool that loses big on TOPS-20. A good summary: . ITS: faster, more efficient, better support of MACLISP, good canonical terminal support. . TOPS-20: larger and slower, but with better virtual memory. None of this should be terribly surprising, since ITS is one of the very first paged operating systems, and the designers of Tenex and TOPS-20 were able to learn from ITS' strong and weak points. Unfortunately, they did not adopt ITS' terminal handling... -- Mark -- -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 AUG 86 17:01:40 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 41475; Sun 3-Aug-86 17:01:46-EDT Date: Sun, 3 Aug 86 16:59 EDT From: Alan Bawden Subject: Re: ks and ITS questions To: deh@eneevax.umd.edu cc: MRC%PANDA@SUMEX-AIM.ARPA, CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU In-Reply-To: <8608030136.AA00452@eneevax.umd.edu> Message-ID: <860803165944.6.ALAN@PIGPEN.AI.MIT.EDU> Date: Sat, 2 Aug 86 21:36:55 EDT From: Douglas Humphrey Is there enough info on Red Tape #1 to confirm that there is/is not a microcode limit on memory size ? Well, I had to modify the microcode for ITS paging, so I've certainly had a pretty good look at it! The microcode and the micromachine believe in a 1024K address space everywhere we know of. I have been told that ITS suffers from thrashing as it dies on heavy loads. If so, then the 1024kw hack would win. Certainly memory is cheap enough these days ! maybe an MS10 memory board with 256k chips on it would do it. Well, any machine thrashes when people try to use more virtual memory than physical memory. ITS does pretty good under a heavy load. Certainly no worse that 20X does. (Pardon me, I just have to defend ITS from causual slander!) (Well, there was this microcode bug I fixed that caused a fair amount of thrashing until a couple months ago...) I believe the hardware people have determined that larger chips on the same board won't do the job, there needs to be a new board manufactured. But it is believed that that is the -only- limitation.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 3 Aug 86 06:13:07 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700900051097511@MIT-MULTICS.ARPA>; 03 Aug 1986 06:00:51 edt Date: 02 Aug 86 23:18 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Alan Bawden" , "Mark Crispin" Cc: "Douglas E. Humphrey" , DEVON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, "Pandora B. Berman" , MOON@AI.AI.MIT.EDU, "John T. Wroclawski" , "Rob Austein" , JNC@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Subject: Re: ks and ITS questions Message-ID: <192126@QZCOM> In-Reply-To: <12227518754.6.MRC@PANDA> You dont KILL a god, working KA-10 for the console as a trofee, its like killing animals for putting their heads on the wall in your apprtment. Dugs KA is in working condition.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 3 Aug 86 06:12:57 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700899905748031@MIT-MULTICS.ARPA>; 03 Aug 1986 05:58:25 edt Date: 02 Aug 86 23:06 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Douglas E. Humphrey" , "Alan Bawden" Cc: DEVON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, "Pandora B. Berman" , MOON@AI.AI.MIT.EDU, "John T. Wroclawski" , "Rob Austein" , MRC@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Subject: ks and ITS questions Message-ID: <192123@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].78091.860731.ALAN> TU45: Our 2020 has a TU-45 / Tm03 and it works with the tu77 code, without any problem.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 3 Aug 86 00:58:42 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA00452; Sat, 2 Aug 86 21:36:55 EDT Date: Sat, 2 Aug 86 21:36:55 EDT From: Douglas Humphrey Message-Id: <8608030136.AA00452@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.ARPA Subject: Re: ks and ITS questions Cc: CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Is there enough info on Red Tape #1 to confirm that there is/is not a microcode limit on memory size ? I have been told that ITS suffers from thrashing as it dies on heavy loads. If so, then the 1024kw hack would win. Certainly memory is cheap enough these days ! maybe an MS10 memory board with 256k chips on it would do it. Doug P.S. If ITS starts supporting RM03 drives, it might be a good idea to put them on some of the MIT machines. Though they are only 80 megs (vs. 176 for RP06 drives) they are ultimately reliable and are available on the used market now for $400.00 Real Cheap Disk.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 3 Aug 86 00:57:40 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA00380; Sat, 2 Aug 86 21:24:11 EDT Date: Sat, 2 Aug 86 21:24:11 EDT From: Douglas Humphrey Message-Id: <8608030124.AA00380@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, MRC%PANDA@SUMEX-AIM.ARPA Subject: Re: ks and ITS questions Cc: CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Seems that everyone wants the console off of my KA, but I think I will keep it. Let me check with the folks I am working with on the 2020 and see if they have any around. They used to have a number of KA systems. The hardware involved with running the serial link should not be too bad. I have a number of KMC11 sets around here somewhere, and maybe some DMC too. It is the code to handle the serial that I wonder about. What does ITS know about in the way of comm devices for TCP/IP ? Since the vax has a unibus it should be pretty easy (assuming that the powers that be don't flip out) to put the same comm on eneevax that DX has and then either get a leased line or put up antennas and run packet radio. Doug  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 2 Aug 86 03:53:48 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 2 Aug 86 00:49:07-PDT Date: Fri 1 Aug 86 23:46:36-PDT From: Mark Crispin Subject: Re: ks and ITS questions To: ALAN@AI.AI.MIT.EDU cc: DIGEX@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].78091.860731.ALAN> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12227518754.6.MRC@PANDA> So, when are we going to see an RM03/TU45 version of ITS? There are some TU77-only hacks in TOPS-20 that don't apply for TU45's; I don't know if ITS depends on any of these. There are very few 2020's which have less than a full house of 512K. Alan is right about the address lines going to 1024K, but I'm not sure denser boards alone are enough; perhaps some additional microcode hacks are needed. I think that the best way to do serial TCP/IP on a 2020 is to get a synchronous interface (called a KDP, or also a DN20-BA; it's a KMC11A plus a DUP11-DA). You absolutely do *not* want to use a DZ11 port. You will have no cycles left on your machine to do anything else. A KDP is advertised as being 2 to 19.2 KB, but I've used it with DECnet at as slow as 1200 baud. Can I have PM (for "Pandamonium") as the name for my machine? Actually, it's full TOPS-20 name is "4664 Pandamonium Reigns!"... -- Mark -- PS: Doug, if you don't want your KA10 any more I will pay a few hundred dollars for the console panel if it's in good condition. -------  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 1 Aug 86 12:38:03 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA02995; Fri, 1 Aug 86 12:35:55 EDT Date: Fri, 1 Aug 86 12:35:55 EDT From: Douglas Humphrey Message-Id: <8608011635.AA02995@eneevax.umd.edu> To: MRC%PANDA@SUMEX-AIM.ARPA, deh@ENEEVAX.UMD.EDU Subject: Re: ks and ITS questions Cc: ALAN@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU In digging through a bunch of tapes from the 'old days' of 10 and 20 hacking, I find the following tapes around: Red Tape #1 version 405 Red Tape #3 version 405 Red Tape #1 version 404 also exists Sounds like we are in business. I just spoke with the folks there, and they agree that a 2020/512kw/DZ11E/dual RM03's/dual TU45's is a pretty fair trade, so until it is on paper, that is what the config should be. I sure hope no big wig decides to blow this deal.....sounds like fun ! Doug  Received: from SUMEX-AIM.ARPA by AI.AI.MIT.EDU 1 Aug 86 00:45:31 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 31 Jul 86 21:41:47-PDT Date: Thu 31 Jul 86 21:23:59-PDT From: Mark Crispin Subject: Re: ks and ITS questions To: deh@ENEEVAX.UMD.EDU cc: ALAN@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU In-Reply-To: <8608010114.AA10916@eneevax.umd.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12227230649.7.MRC@PANDA> Doug - The Red Pack is built from a Red Tape #1. A Red Tape #3 (bootable diagnostic tape) can be made from a Red Pack. Most of the DECies don't bother with Red Packs, they just use Red Tape #3's. It is generally possible to get ahold of one or the other, at least underground. Isn't there a Red Tape #3 in the DEC supply cabinet by the machine? -- Mark -- -------  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 31 Jul 86 22:15:33 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA10916; Thu, 31 Jul 86 21:14:18 EDT Date: Thu, 31 Jul 86 21:14:18 EDT From: Douglas Humphrey Message-Id: <8608010114.AA10916@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, DIGEX@AI.AI.MIT.EDU Subject: Re: ks and ITS questions Cc: CENT@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, MRC@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU Alan, Thanks for the answers. I will be calling these people tomorrow to get the configuration and shipping and such settled. Will advise when I know when it will be installed. Should be a good party, and of course all are invited if they are in the DC area. Lets hope all goes well. I'm glad to hear that the RM03's will be supported; it may not go toward your phd, but it's good for a free dinner next time you are in Washington or I'm in Boston ! Does anyone have the Red Pack or Red Tape diagnostice for the KS10 ? Thanks again, Doug  Date: Thu, 31 Jul 86 15:32:47 EDT From: Alan Bawden Subject: ks and ITS questions To: DIGEX@AI.AI.MIT.EDU cc: DEVON@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, MRC@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, TAFT@AI.AI.MIT.EDU In-reply-to: Msg of Wed 30 Jul 86 22:43:08 EDT from Doug Humphrey Message-ID: <[AI.AI.MIT.EDU].78091.860731.ALAN> Date: Wed, 30 Jul 86 22:43:08 EDT From: Doug Humphrey Well, it looks like there is a good chance that I will get a 2020 soon, aince I have found a friend who owns a company who has one, and they owe me a lot of favors. I need to ask some random questions to see if I can get ITS up on it here in Washington. 1. How much memory do I have to have on it to run ITS ? Do I need a full 512kw, or can it run on less. Alternativly, once I have the memory, how hard is it to make the machine address more than 512kw ? Our machines all have 512K, but you can certainly run with 256K (at some loss in performance). You can't have more than 512K worth of memory physically stuffed into the machine, although if denser boards were manufactured the machine can address 1024K. 2. Since I do not know the ITS internals at all, and have little time right now to learn them, are there any souls that would be willing to help me get it running down here ? I can provide the machine, the home for it ( my basement) and the power and cooling and such, and as much time as I can squeak out. We can provide the software and directions that anyone can follow for getting the machine initially running. Beyond that, I don't know where you can find additional hacker power. Perhaps you can advertize somehow. 3. Since I do not have a chaos net etc. here, will the sweden modifications to ITS be available to allow me to connect it to normal DZ11 ports and such like that ? That way I could put dialups on it so that DC area folk could use it. We already support DZ11s. I dial up to our 2020's all the time. 4. What are the chances of having ITS support RM03 disks in addition to RP06's ? The RM03's use single phase power and are thus much nicer to have in my basement than the RP06's. Also, the generate a lot less heat and noise. RM03 support is a small modification to the existing RP06 support. MRC also has RM03's so I'm already comitted to doing this. I haven't done it yet though. (Hey, I'm supposed to be working on a Phd, not hacking ITS.) 5. The University of Maryland has said that I can put the machine on the internet through them if I can figure out some way to get some good communications from the house to the university. A serial line might be doable, or maybe even packet radio, but there would have to be some sort of serial line TCP/IP support to do this. Something like SLIP. Does anyone know of that type of thing for ITS ? It would be nice to be on the arpanet... Dunno about this. Maybe one of the people I Cc'd will have an opinion. 6. How much disk space does an ITS take up ? A full set of sources for ITS and associated system programs (including Emacs and MacLisp) will, I think, completely fill an RM03. But there is no reason for you to have all of those files in your filesystem as long as you can get them from tape. When you load up your filesystem, you will just need to make some informed choices about what directories to tell DUMP to skip. 7. Does it support the TU45 tape drive ? That is what I would be getting. We have never tried a TU45, but I have been lead to believe that the existing TU77 support will simply work. (MRC also has a TU45.) 8. I know that I like ITS, and want to see it stay alive, but I have (unfortunately) very little time to hack with it anymore. What other folks in the DC area would like to have accounts on a local ITS ? Is this project (pardon my asking; I'm the guy with the KA 10 in the living room for heavens sake !!!) worth doing ? Are there enough people there to make this a winning event, or do I just tell these guys to send me the cash rather than the machine ? ...? I should state that I am in great favor of the idea of ITS sites spreading all over the world, bringing their wacky and wonderful message of free computrons to the massas, etc. It's just that if I bring the machine up and there is nobody to use it it will be a sad thing... By the way, has a naming convention for these missionary ITS machines been developed ? Do we keep the current MIT-__ to recall that MIT is the true source of the holy ITS ? If so, Devon has suggested that I get MIT-DX reserved, since it is close to the name of the company that will actualy own the machine (Digital Express Inc.) and since DX implies the remote nature of the machine from MIT. If there is going to be a new naming structure started, please let me know. ITS machines have two letter names, so "DX" is now reserved in your name. Many ITS programs will prefix that with "MIT-" and assume that that is also an official name of the machine. What you do about such programs are your own business. Banzai ! Doug  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 22 Jul 86 20:08:12 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699913074158839@MIT-MULTICS.ARPA>; 22 Jul 1986 19:51:14 edt Date: 22 Jul 86 20:50 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU Subject: You'll never know how hard it is to distribute software until you try. Message-ID: <189354@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].69828.860714.ALAN> suggestions.... I started loading the tapes to a new discpack, now with a ITS monitor that handled the tm03. Using Dump to load the filesystem is slower than using the TRAN routine in the salvager. Why, 1, the comand LOAD MERGE NOASK does not create directorys, so for each new directory i had to create that. 2, logging writes to sysstem directorys on a 300 baud console terminal is SLOW. What did i do wrong?.. Sporadical bughalts, KS->8080 flag 24 ..  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 18 Jul 86 05:48:54 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699516037468944@MIT-MULTICS.ARPA>; 18 Jul 1986 05:33:57 edt Date: 18 Jul 86 01:09 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "David A. Moon" Cc: KS-ITS@AI.AI.MIT.EDU Subject: You'll never know how hard it is to distribute software until Message-ID: <188670@QZCOM> In-Reply-To: <860717001411.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Ethernet tcp-ip for KS, After the work with the ki/imp code/32016 mikro/ethernet for t10, i think we have learned how.. But we have to learn about ITS first....... Produced a lot of crashes yesterday on the KS, but after running DEC diagnosis we found a hardware problem. I have started to add modem control/autobaud for the DZ lines so we can hook it to the terminal switch. (We are still waiting for OUR KS from Per Hjerppe, we are currently using a KS that belongs to the stockholm University Computing center.) -peter  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 17 Jul 86 16:42:21 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699462380650215@MIT-MULTICS.ARPA>; 17 Jul 1986 14:39:40 edt Date: 17 Jul 86 17:24 +0200 From: KPJ_Jaakkola_QZ-DEC%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ-DEC%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KS-ITS@AI.AI.MIT.EDU Subject: Hackers? Message-ID: <188610@QZCOM> In-Reply-To: <188591@QZCOM> Fascism never help stamp out terrorism, it creates it.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 17 Jul 86 16:42:13 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699462342342295@MIT-MULTICS.ARPA>; 17 Jul 1986 14:39:02 edt Date: 17 Jul 86 14:04 +0200 From: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KS-ITS@AI.AI.MIT.EDU Subject: Hackers? Message-ID: <188591@QZCOM> In-Reply-To: <188390@QZCOM> There is a lot of people here who call themselves "hackers", but aren't. They are usually referred to as "snackers" (i.e. "talkers"-the Swedish word "snack" means "(nonsense) talk"). They only use computers for writing a lot of nonsense in KOM (a teleconferencing/electronic mail system). They copy other people's program, and boast about how clever they are. If we give them full privileges, and a program to change the job's PPN to [1,2] (the TOPS-10 way of bypassing file protections) they will use it to change system files without knowing what they are doing-trying to play "clever system programmer"-but if we remove the program, or hack the monitor so the program doesn't work (which is what we did, since most of them waste disk space by making copies of everything they can find, and especially the privilege program) they complain, but they do not bother to find out another way to do what they want. Do we need to protect ourselves against them? No. If there's no teleconferencing system where they can talk, they woun't use the machine. What do we need protection for? First, because some crackers can't think of anything better than causing damage. The most disgusting cracker I know of goes around asking people if he may use their terminals for a second, and then he erases all their files, or something similar. Second, because we woun't have our own modems, and we don't want to have Mr. Anonymous blocking QZ's modems during office hours.  Received: from QUABBIN.SCRC.Symbolics.COM by AI.AI.MIT.EDU 17 Jul 86 00:33:02 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 20530; Thu 17-Jul-86 00:12:35 EDT Date: Thu, 17 Jul 86 00:14 EDT From: David A. Moon Subject: You'll never know how hard it is to distribute software until To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <188434@QZCOM> Message-ID: <860717001411.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 16 Jul 86 21:25 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA We have no network to the KS, the only network we have around is a local ethernet, shared by tcp/ip, DECnet and xerox xns talking devices. I thought you were going to bring up Ethernet TCP-IP on your KS. MIT will be doing that eventually (right now they are using Chaosnet hardware instead of Ethernet hardware, because it was easier to program and there were a lot of Chaosnet interfaces lying around).  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 16 Jul 86 22:31:38 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699397348518336@MIT-MULTICS.ARPA>; 16 Jul 1986 20:35:48 edt Date: 16 Jul 86 21:25 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: KS-ITS@AI.AI.MIT.EDU Subject: You'll never know how hard it is to distribute software until Message-ID: <188434@QZCOM> In-Reply-To: Comsat: our comsat version is 518 5/16/86. And patch for running without network wold be nice. We have no network to the KS, the only network we have around is a local ethernet, shared by tcp/ip, DECnet and xerox xns talking devices.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 16 Jul 86 18:08:04 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699386249454263@MIT-MULTICS.ARPA>; 16 Jul 1986 17:30:49 edt Date: 16 Jul 86 17:53 +0200 From: KPJ_Jaakkola_QZ-DEC%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ-DEC%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU Subject: You'll never know how hard it is to distribute software until you try. Message-ID: <188390@QZCOM> In-Reply-To: <188047@QZCOM> Heh heh... In Stockholm all turists are considered terrorists. That way there wont be any nice hackers growing, if they are always considered to be dangerous terrorists. Foo!  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 16 Jul 86 14:08:28 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41118; Mon 14-Jul-86 18:21:21 EDT Date: Mon, 14 Jul 86 18:19 EDT From: David A. Moon Subject: You'll never know how hard it is to distribute software until you try. To: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].69828.860714.ALAN> Message-ID: <860714181959.8.MOON@EUPHRATES.SCRC.Symbolics.COM> By the way, it's customary to store the ITS BIN and ITS ERR files on the . directory, in case you need to refer to them later. If for some reason the @ ITS file gets bashed, you can go through the DSKDMP procedure of loading the ITS BIN file again and recover. It's customary to name these files ITS nnnBIN and ITS nnnERR, where nnn is the low three digits of the version number, and link .;ITS BIN to .;ITS nnnBIN where nnn is the latest version that is known to work. Thus you could :MIDAS .;ITS 580BIN,,.;ITS 580ERR_SYSTEM;ITS 1580/E For the same reason, I like to keep a known working .;@ ITS and SYS:ATSIGN HACTRN on the BACKUP; directory, to ease recovery if for some reason the . or SYS directory should go away (I think in all my years with ITS I only got to use those files twice). If these fine points of system administration are confusing to you new ITS sites, don't worry about them for now, but save this message for later.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 15 Jul 86 17:24:04 EDT Date: Tue, 15 Jul 1986 15:01 EDT Message-ID: From: Rob Austein To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MULTICS.MIT.EDU, ITS_bugs_mailing_list%QZCOM.MAILNET@MULTICS.MIT.EDU Cc: KS-ITS@AI.AI.MIT.EDU Subject: You'll never know how hard it is to distribute software until In-reply-to: Msg of 15 Jul 86 14:56 +0200 from Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Date: 15 Jul 86 14:56 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Comsat: What hapens if all network is down, but network code is generated correct? Is you machine actually on a network? There's some ancient code to cope with non-network machines, but it is undoubtably broken. The easiest thing to do in this case would be to build a fake host table with on entry in it and bash the routine that looks up the local host address to just return a constant number. If you need this, let me know, it's a two line COMSAT patch and a few lines of text to construct the fake host table. Tell me which version of COMSAT you have though. Once you get onto a network you can revert to the normal code, maybe. The code that gets your IP address inside COMSAT assumes you're on the Arpanet (net 10.0.0.0) because up until now all ITS machines were if they were TCP/IP live at all. --Rob  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 15 Jul 86 15:29:09 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41863; Tue 15-Jul-86 15:10:54 EDT Date: Tue, 15 Jul 86 15:09 EDT From: David A. Moon Subject: Warning to ITS hackers To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <188049@QZCOM> Message-ID: <860715150916.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 15 Jul 86 15:21 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA This fix from Dave, If you assemble the current source it won't run unless you use the new microcode I'm debugging. I think it will run if you patch OVHCLK/ POPJ P, which will keep it from executing the instructions that aren't implemented. OIPBIT is non-zero now, but it should still be a no-op with the released microcode. It's unlikely that I will finish this before next week, since I will be out of town.. does it work? It's easier for you to test it than for me to test it. We'll send you a new microcode and system in a while; there are still some bugs in one-proceed that it would be nice to iron out. I guess there is lots of fun you can have in the meantime with the system you have.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 15 Jul 86 14:23:59 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699287555952730@MIT-MULTICS.ARPA>; 15 Jul 1986 14:05:55 edt Date: 15 Jul 86 15:21 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU Subject: Warning to ITS hackers Message-ID: <188049@QZCOM> In-Reply-To: <188047@QZCOM> This fix from Dave, If you assemble the current source it won't run unless you use the new microcode I'm debugging. I think it will run if you patch OVHCLK/ POPJ P, which will keep it from executing the instructions that aren't implemented. OIPBIT is non-zero now, but it should still be a no-op with the released microcode. It's unlikely that I will finish this before next week, since I will be out of town.. does it work?  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 15 Jul 86 14:23:51 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699287516618792@MIT-MULTICS.ARPA>; 15 Jul 1986 14:05:16 edt Date: 15 Jul 86 14:56 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU Subject: You'll never know how hard it is to distribute software until you try. Message-ID: <188047@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].69828.860714.ALAN> Microcode update: Can i get the latest microcode source as mail? We all knew how hard it is to send a new tape.... General update: We have to solve the problem of distribute updates, one way is that we get an incremental dump tape from the date where the orginal tape was written. Comsat: What hapens if all network is down, but network code is generated correct? Network: Have someone tryed to use a DEC DEUNA ethernet interface to talk to ethernet. ------- Thanks to all (cent, alan, dave, jtw, and all others) for the work they have put in giving ITS the push to be the new world-wide operating system for pdp10:s. the mission that failed in the beginning of 1970:s to have other use ITS, instead of b10, tenex,....... -peter Ps: for a system living in stockholm, with a lot of bad lusers i need a hint how to instal and use pword.  Date: Mon, 14 Jul 86 17:53:16 EDT From: Alan Bawden Subject: You'll never know how hard it is to distribute software until you try. To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].69828.860714.ALAN> The good news is that the Swedish KS10 ITS is up and running. The bad news is that both of the ITS distribution kits I sent out have this (non-fatal) problem: The system binary doesn't have the tape drive support assembled in. This isn't fatal, because the Salvager has tape drive support, and the kit includes a complete set of sources, but it does mean that the directions I gave to use DUMP running under timesharing to load most system files won't work... To those of you with distribution kits (does this list reach any of the relevant people in Australia?) here is what to do about it: The immediate solution is to use the TRAN routine in the Salvager to load -all- the dump tapes. That is, after using TRAN to load the MINSYS tape, mount the first dump tape and do TRAN$G again. TRAN will not clobber any file it finds already on disk, so the vital files loaded from the MINSYS tape will not be touched. Repeat this for all dump tapes. This isn't the most pleasant way to load the filesystem, but it will work. Someday, after you have played with ITS for a while, you will probably want to use your tape drive. Like perhap you might want to backup your filesystem. In order to get a new version of ITS assembled that has tape drive support you should first edit the configuration file kept in SYSTEM;CONFIG >. Find the section of the configuration file that describes your system. (It's a page that starts "IFE MCOND ZZ,[", where ZZ is the name of your machine.) Insert the two lines: DEFOPT NMTCS==1 ;Number of magtape units DEFOPT TM03S==1 ;TM03/RH11 Unibus tape controller somewhere on the page (I put them after the line that begins "DEFOPT RH11P"). Now you need to assemble a new ITS. The tape for SI includes two newer versions of ITS that if assembled, won't run with the microcode they have. (I told Peter over the phone that this wasn't the case, but I was wrong.) So they will need to first delete the files SYSTEM;ITS 1580 and SYSTEM;ITS 1581 from their filesystem. The tape for FU does not have this problem. Next you need to increment the system version number. The system version number is simply the version number of the file SYSTEM;ITS. Since you have not changed this file, you need to change the version number manually. Simply rename the file. (For example, on SI rename SYSTEM;ITS 1579 to SYSTEM;ITS 1580.) Now assemble a new system. Type (to timesharing DDT): :MIDAS SYSTEM;ITS/E when MIDAS (the assembler) asks: MACHINE NAME = answer by typing the name of your machine ("SI" or "FU" or whatever) followed by a carriage return. When MIDAS is done it leaves two files in -your- directory: ITS BIN and ITS ERR. The ERR file is just a record of what MIDAS typed to the terminal during assembly. The BIN file is the new binary. To dump out a system as .;@ NITS, repeat the procedure you used to create .;@ ITS. In brief, the steps are: Take the system down and get into DSKDMP. L$.;DDT to get a fresh DDT into memory. T$ME;ITS BIN loads the ITS binary you just made from directory ME. This also starts DDT in case you want to patch anything. $U returns you to DSKDMP, since you have no patches. M$.;SALV BIN merges in a copy of the Salvager. D$.;NITS dumps the whole mess on disk as .;@ NITS. Now when you boot ITS, use NITS instaed of ITS and you can use your tape drive.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 10 Jul 86 20:13:52 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA16357; Thu, 10 Jul 86 20:12:28 EDT Date: Thu, 10 Jul 86 20:12:28 EDT From: Douglas Humphrey Message-Id: <8607110012.AA16357@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: Re: [bzs%bu-cs.bu.edu: 2060 for sale] Sure, why not ? I need somthing to keep the basement warm.... To Barry : 1. Can you be specific as to the MF20-xx part numbers for the memory. 2. Can you contact DEC or someone and verify that the TOPS 20 licence is indeed transferable. 3. Can you keep me informed as to its availability ? I may need it in 60 - 90 days, if it is still available. Thanks Doug Humphrey Digital Express Inc.  Date: Thu, 10 Jul 86 16:41:53 EDT From: Alan Bawden Subject: [bzs%bu-cs.bu.edu: 2060 for sale] To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].67986.860710.ALAN> Any takers? Date: Wed, 9 Jul 86 15:54:15 EDT From: Barry Shein To: alan at AI.AI.MIT.EDU Re: 2060 for sale I don't know if you're the appropriate person, but maybe you know someone who is... We're trying to get rid of our 2060, I believe we have bid it out to random used equipment folks and are waiting for responses. The price would be $25K (that would be free and clear, eg. you pay shipping and insurance and de-installation etc.) If you think there is anyone around MIT who would be interested get them in touch with me. It's so cheap because that's what we've been quoted. We're getting rid of it because the maintenance is so high and it was never much used here at BU. It is all late model stuff. Timing is open, we need some notice to move people off of it and get in replacement equipment. Thanks. -Barry Shein, Boston University BZS@BU-CS.BU.EDU 2060-PH, S/N 3047 KL10E, 1536KW MF20, 2 RP06, 2 RP07, TU78, DN20 + 2 DMR11-AC, 32 Async lines (DH11-AD), KLNI (ethernet), LP20 (600LPM/96), TOPS-20. This machine has always been under full service by DEC/LCG since its installation as new equipment in June 1983. The original list (w/o the KLNI) was $840,364.00.  Date: Thu, 26 Jun 86 12:12:43 EDT From: Rob Austein Subject: Tune in next week for the Top Ten report To: mdc@HT.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU, ddc@BORAX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].61945.860626.SRA> That's ok, Marty, I have a better way to generate load than moving KIN to MC (and without the administrative problems that would entail). I just dropped three weeks worth of Arpanet-BBoards messages into the queue at once. This week's top ten report should be amusing. Hope none of you chaos-only machines wanted to send any mail today.... --Rob  Received: from HT.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 JUN 86 17:02:02 EDT Received: by ht.ai.mit.edu; 25 Jun 86 16:55:24 edt Date: 25 Jun 86 16:55:24 edt From: Martin David Connor To: ALAN@AI.AI.MIT.EDU Cc: KS-ITS@AI In-Reply-To: Alan Bawden's message of Wed, 25 Jun 86 12:00:37 EDT Subject: [WESTINE: Top Ten Traffic Hosts] Date: Wed, 25 Jun 86 12:00:37 EDT From: Alan Bawden So, a KS10 really can handle 2% of the Arpanet traffic. ... Chuckle, I think I know where I can get you a few more tenths of a percent of the load, if you're interested...  Date: Wed, 25 Jun 86 12:00:37 EDT From: Alan Bawden Subject: [WESTINE: Top Ten Traffic Hosts] To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].61320.860625.ALAN> So, a KS10 really can handle 2% of the Arpanet traffic. Date: 9 Jun 1986 09:43:40 PDT From: WESTINE at USC-ISIB.ARPA, ddc at lcs.mit.edu (Dave Clark) To: ; at Traffic-Graph-List Re: Top Ten Traffic Hosts Resent-From: WESTINE@USC-ISIB.ARPA (Dave Clark) Resent-To: jtw@mc, alan@mc, jnc@mc Folks, The "new" MC made the top ten.... I thought you might like to see what it can do for itself. ARPANET Busy Host Report For the week ending JUN05 Host Packets per cent Name (millions) of total --------- ---------- -------- 1. COLUMBIA 13.10 9.16 2. UCLA-LOCUS 11.60 8.11 3. ISI-GATEWAY 7.14 4.99 4. WISC-GATEWAY 5.07 3.54 5. ISI-MILNET-GW 4.74 3.32 6. PURDUE-CS-GW 3.97 2.78 7. DCEC-MILNET-GW 3.61 2.53 8. BBN-MILNET-GW 3.44 2.41 9. SAC-MILNET-GW 3.25 2.27 10. MC.LCS.MIT.EDU 2.77 1.94 --------- ------ ----- top 10 58.68 41.05 ========= ====== ===== net total 142.95 100.00  Date: Wed, 25 Jun 86 01:11:18 EDT From: "Jonathan D. Taft" To: KS-ITS-CONFUSION@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].61266.860625.TAFT> AI was unresponsive but running printing repeatedly on its console: "Warning: No free qsk channels" "System full no job slots." I dumped it to CRASH;FULL FORCED and reloaded.  Date: Tue, 10 Jun 86 11:00:14 EDT From: Ed Schwalenberg Subject: The unexpected demise of the end of an era To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].54405.860610.ED> From AI:COMMON;LINS >: I just removed the instructions in MC:COMMON;LINS > which specify that it should be installed on AI. We'll certainly miss that machine, and probably spend the rest of our lives fixing programs that mention it.  Date: Sat, 7 Jun 86 02:53:46 EDT From: Alan Bawden Subject: microfun To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].52887.860607.ALAN> I guess nobody inside DEC is interested in hearing about bugs in their KS10 microcode by now. That's a pity, because I just found a pretty funny one. The microcode for BLT treats BLTting a block from foo to foo+1 as a special case that it can do quickly. This is, of course, very important given that 95% of all the BLTs in the world are used precisely for this purpose. Well, it isn't careful about the case where BLT is being used by XCTR (or PXCT for you 20X hackers) to move a block of data from address foo in the system's address space, to address foo+1 in the user's address space! The poor user's block gets a bunch of copies of the first word of the system's block. Of course I found this the hard way. The .RCHST call screws up if you ask for the results starting in accumulator 2 (but in no other case!). And of course there is a place in DDT that does exactly this. I wonder how many other subtle bugs have been caused by this. The ITS KL10 microcode doesn't seem to have this problem, I presume that means that the DEC KL10 microcode doesn't have it either.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 1 Jun 86 12:11:12 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA11339; Sun, 1 Jun 86 12:11:00 EDT Date: Sun, 1 Jun 86 12:11:00 EDT From: Douglas Humphrey Message-Id: <8606011611.AA11339@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, ROLL@AI.AI.MIT.EDU Subject: Re: The TAPE! Cc: KS-ITS@AI.AI.MIT.EDU The possibility that there will be 'off-site' ITS machines brings up the question of how to get them connected together. I would think it would be a very good thing to have all of the ITS machines able to talk. The only problem is how ? Is there any easy way to get one to run Serial Line IP (SLIP) ? Doug  Date: Sun, 1 Jun 86 09:30:40 EDT From: Alan Bawden Subject: The TAPE! To: ROLL@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of 26 May 86 21:52 +0200 from Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA Message-ID: <[AI.AI.MIT.EDU].49556.860601.ALAN> I'm pleased to say that I have a set of tapes and some documents that I -think- are everything you need to boot up a Swedish ITS. They are sitting right here in a pile on the corner of my desk. We'll try and put them in some kind of container and get them in the mail real soon. [ MRC: I had intended to send you a tape set first, but since for your machine I have to actually write some code... this turned out to be easier. I haven't forgotten you. ]  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86 09:42:31 EDT Date: Sat, 31 May 1986 09:41 EDT Message-ID: From: Jerry Roylance To: Alan Bawden Cc: JTW%SPEECH.MIT.EDU@XX.LCS.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU Subject: ML head crash In-reply-to: Msg of 30 May 1986 23:12-EDT from Alan Bawden Date: Friday, 30 May 1986 23:12-EDT From: Alan Bawden To: SRA at XX.LCS.MIT.EDU cc: sollins at XX.LCS.MIT.EDU, KS-ITS at AI.AI.MIT.EDU, JTW at SPEECH.MIT.EDU Re: ML head crash Date: Fri, 30 May 1986 21:47 EDT From: Rob Austein Date: Friday, 30 May 1986 21:15-EDT From: "John Wroclawski" ML's RP06 has head-crashed; ML will be down till monday or tuesday or whenever DEC gets around to fixing it.... FMH. Did Field Circus have any comments on the close proximity between the XX <-> ML double swap and this head crash? Considering that that whole episode was their idea and that they did the actual move both times, can we get them to pay for the repair? Its highly likely the events are related. I found a scrap of paper stuck to the head assembly inside the drive that was probably left there due to swapping packs around many times. (It looks like the corner of an adhesive label of some kind. My guess it was torn off of a pack cover when a pack was being removed or inserted.) John: Where did you finally spot damage? Do we need a new pack? Are the heads damaged? It would be nice if we can get DEC to replace the pack if it is damaged. Of course the crash is related to the swap (goddamnit JTW). If the drive hadn't been moved to XX it would never have had an LCS pack put in it. LCS puts gummed labels two deep on the sides of the pack cover and never removes the old ones completely. For grins go look at the cover for XX's drive 5.  Date: Sat, 31 May 86 03:23:01 EDT From: "Pandora B. Berman" Subject: mailing lists redux To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49152.860531.CENT> Date: Wed, 28 May 86 17:01:04 EDT From: Alan Bawden Subject: KS-ITS mailing list To: GUMBY@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU Date: Wed, 28 May 86 04:47:53 EDT From: David Vinayak Wallace Can't we fold this into INFO-ITS? INFO-ITS is an extremely low-volume mailing list. It is for spreading information that ordinary ITS users and programmers might want to know. Like when a new device is installed (like LP7:), or a new Midas library is written, or a new machine is installed, or a new system call is installed or improved. KS-ITS is for people who are interested in the project of getting 2020s installed at MIT running ITS. When I got the KS10 microcode to do ITS-style paging, I sent mail to KS-ITS. The people on INFO-ITS I didn't bother until they could log in. A lot of mail that has gone to KS-ITS in the last few months should have been sent to BUG-ITS. Like if AI crashes in some novel way, people send mail to KS-ITS "because AI is a KS", even though BUG-ITS is the proper recipient. The people on KS-ITS were interested in keeping in touch with a "good hack", which is distinct from both BUG-ITS and INFO-ITS. gumby, the next time you ask 4 people's opinion about making the sort of major change you suggested, why not wait until more than 1 replies before deciding what to do? i have just spent 2 hours undoing the confusion you created by going ahead with this merger after only one response. among other things, you completely omitted the BUG-ITS archive. fortunately i discovered a BUG-ITS list member who hasn't logged in for the past few days, and so was able to recover the lost msgs. i have also unmerged the INFO-ITS and KS-ITS archives. also, it's considered courteous, when you insist on rashly forging ahead in this fashion, to inform -all- the list members involved; you only told those people on KS-ITS who were not on INFO-ITS: Date: Wed, 28 May 86 05:49:01 EDT From: David Vinayak Wallace Subject: KS-ITS mailing list To: KS-ITS-ONLY-PEOPLE@AI.AI.MIT.EDU The KS's have arrived and ITS runs on them, so we're folding the KS-ITS list into INFO-ITS. You're not on INFO-ITS nor BUG-ITS. Unless I hear from you in the next few days I'll put you on INFO-ITS. david i agree with alan -- the INFO-, BUG-, and KS-ITS have distinct purposes and should be kept that way. now that the KSs run ITS, a lot of the discussion previously carried on on KS-ITS should move to BUG-ITS or other more appropriate lists, but that's another story.  Date: Fri, 30 May 86 23:12:42 EDT From: Alan Bawden Subject: ML head crash To: SRA@XX.LCS.MIT.EDU cc: sollins@XX.LCS.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Fri 30 May 1986 21:47 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].49089.860530.ALAN> Date: Fri, 30 May 1986 21:47 EDT From: Rob Austein Date: Friday, 30 May 1986 21:15-EDT From: "John Wroclawski" ML's RP06 has head-crashed; ML will be down till monday or tuesday or whenever DEC gets around to fixing it.... FMH. Did Field Circus have any comments on the close proximity between the XX <-> ML double swap and this head crash? Considering that that whole episode was their idea and that they did the actual move both times, can we get them to pay for the repair? Its highly likely the events are related. I found a scrap of paper stuck to the head assembly inside the drive that was probably left there due to swapping packs around many times. (It looks like the corner of an adhesive label of some kind. My guess it was torn off of a pack cover when a pack was being removed or inserted.) John: Where did you finally spot damage? Do we need a new pack? Are the heads damaged? It would be nice if we can get DEC to replace the pack if it is damaged.  Date: Fri, 30 May 86 22:58:08 EDT From: Alan Bawden Subject: EMACS accessible NLI on KS? To: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of 30 May 1986 17:05 EDT (Fri) from Leonard N. Foner Message-ID: <[AI.AI.MIT.EDU].49081.860530.ALAN> Date: 30 May 1986 17:05 EDT (Fri) From: Leonard N. Foner To: KS-ITS at AI ... Comments? Criticisms? Sneers/jeers/abuses? I would like to suggest that KS-ITS isn't the proper mailing list for this discussion of the administration of MC. I presume that people put themselves on this mailing list because they were interested in following the progress of getting KS10's up and running ITS. Much of the recent discussion surrounding the MC/MX name swap strained this definition a bit, and this discussion of access to MC's NAMES file strikes me as beyond the boundary. There -is- a mailing list of people who are interested in this issue: User-A@MC. I would request the the rest of this discussion take place there.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 30 May 86 21:47:54 EDT Date: Fri, 30 May 1986 21:47 EDT Message-ID: From: Rob Austein To: "John Wroclawski" Cc: ks-its@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: ML head crash In-reply-to: Msg of 30 May 1986 21:15-EDT from "John Wroclawski" Date: Friday, 30 May 1986 21:15-EDT From: "John Wroclawski" ML's RP06 has head-crashed; ML will be down till monday or tuesday or whenever DEC gets around to fixing it. Since the machine is not on service, it is not a super-high priority item, but they still think monday or tuesday or so. FMH. Did Field Circus have any comments on the close proximity between the XX <-> ML double swap and this head crash? Considering that that whole episode was their idea and that they did the actual move both times, can we get them to pay for the repair?  Received: from PREP.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 MAY 86 21:37:41 EDT Received: by PREP.AI.MIT.EDU; Fri, 30 May 86 21:38:22 EDT Date: Fri, 30 May 86 21:38:22 EDT From: rms@PREP.AI.MIT.EDU (Richard M. Stallman) To: ED@AI.AI.MIT.EDU Cc: Margolin@MULTICS.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU In-Reply-To: Ed Schwalenberg's message of Fri, 30 May 86 21:13:45 EDT Subject: EMACS accessible NLI on KS? Anyone who can FTP, can do anything anyway.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 MAY 86 21:16:30 EDT Date: Fri 30 May 86 21:15:40-EDT From: "John Wroclawski" Subject: ML To: ks-its@AI.AI.MIT.EDU Message-ID: <12210943439.31.JTW@SPEECH.MIT.EDU> ML's RP06 has head-crashed; ML will be down till monday or tuesday or whenever DEC gets around to fixing it. Since the machine is not on service, it is not a super-high priority item, but they still think monday or tuesday or so. -------  Date: Fri, 30 May 86 21:13:45 EDT From: Ed Schwalenberg Subject: Re: EMACS accessible NLI on KS? To: Margolin@MULTICS.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU, FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49008.860530.ED> Date: Fri, 30 May 86 18:32 EDT From: Barry Margolin If you make EMACS available then you might as well not be using PWORD. Once in EMACS one can do almost anything. Barry is almost right; once in EMACS one can do ANYthing. If you doubt, see the documentation for FS REAL ADDRESS.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 30 May 86 18:45:17 EDT Date: Fri, 30 May 86 18:32 EDT From: Barry Margolin Subject: Re: EMACS accessible NLI on KS? To: "Leonard N. Foner" cc: KS-ITS@AI.AI.MIT.EDU, Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU In-Reply-To: Message of 30 May 86 17:05 EDT from "Leonard N. Foner" Message-ID: <860530223205.457277@MIT-MULTICS.ARPA> If you make EMACS available then you might as well not be using PWORD. Once in EMACS one can do almost anything. barmar  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 MAY 86 17:05:32 EDT Date: 30 May 1986 17:05 EDT (Fri) Message-ID: From: "Leonard N. Foner" To: KS-ITS@AI.AI.MIT.EDU Subject: EMACS accessible NLI on KS? cc: Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU I was just talking to someone who maintains a moderate-sized list elsewhere that has local redistribution to MIT via MC. Now that MC alias KS is not easy to log in to, he cannot fix problems which result from expansions here, yet not everyone at the MIT side even knows that they are on a local redistribution, much less can fix their entries without accidentally bashing something. In addition, with the exception of the people with KS PWORD entries, no one can update .MAIL.;NAMES > without doing a rather lengthy transfer over the net. Over MLDEV from AI, this take only a few seconds and doesn't both me much, but this guy in California certainly doesn't want to FTP the entire file back and forth... (He didn't even mention timing screws, but such a lengthy update cycle makes them more likely, too.) Would it make sense to make EMACS runnable on KS when not-logged-in? I realize that this opens up another whole can of worms, namely that it then becomes difficult to know who last changed a file. Furthermore, EMACS can do things like delete files (I must assume that malicious people are still around). Thus it's not entirely clear to me that this is a great idea. On the other hand, it would save a good deal of traffic, hence load, for quick occasional modifications, and would allow people far away to update NAMES > without taking all afternoon. Presumably, we wouldn't wind up with a user community on KS, since no one would be logged in, and I would guess that the load of an occasional EMACS would be lower than that of shipping NAMES > back and forth for each mod. Comments? Criticisms? Sneers/jeers/abuses?  Date: Wed, 28 May 86 04:03:33 EDT From: "Pandora B. Berman" Subject: Hopping tourists, etc To: JNC@AI.AI.MIT.EDU cc: USER-ACCOUNTS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47094.860528.CENT> Date: Wed, 28 May 86 00:35:45 EDT From: "J. Noel Chiappa" Subject: Hopping tourists, etc To: USER-ACCOUNTS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU As I was saying before I lost completely due to connections spazzing, I have found tourists hopping to OZ through AI, in spite of the message that tells them not to. One claimed that his tourist advisor (who shall be nameless) told him to do so. i think this was a fellow i gave an account to (see my msg of a few minutes ago to USER-A -- interested KS-ITS folks can look in the USER-A archive). i do not believe in that fictive creature the "tourist advisor". some tourists figure out that i granted their accounts, and therefore direct their questions to me before asking lab members at random. i am reasonably sure i have not told any tourists that nethopping through AI is an approved activity. ...Maybe it's time to set some definite standard as to what can be done where. We also need to start making more use of the other two KS's; this would be greatly easier if they had TCP/IP. Do we have any volunteers to write the Ethernet driver code? WE apparently have the boards. i think JTW was kinda sorta considering thinking about contemplating working on this. or something like that. but i could be wrong. I would suggest putting mail forwarding and the CHAOS/TCP protocol gateway on the two ARPANet connected machines (I assume there's no easy way to tell what percentage of these service requests go to machiens outside MIT, in which case these are the right machines; internal MIT conversion should go through the other two). All users (Lab and tourist) on the other two machines; nethopping should probably also be down through the other two machines. i would find it exceedingly inconvenient to use a machine other than AI. it might help to have ML and MD both up (gumby just brought ML back up after its use by lcs&dec for a week or so) so that people -can- move to them. a lot of people are quite willing to move to ML now, as long as they can use AI when a direct arpa connection is necessary, but are wary of moving to MD because we keep saying that it will be the first to go when we need parts.  Date: Wed, 28 May 86 00:57:40 EDT From: "J. Noel Chiappa" Subject: As I was saying To: USER-ACCOUNTS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU cc: JNC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47001.860528.JNC> As I was saying before I lost completely due to connections spazzing, I have found tourists hopping to OZ through AI, in spite of the message that tells them not to. One claimed that his tourist advisor (who shall be nameless) told him to do so. I don't think these poor KS's have the horsepower to support mail distribution, a user community, tourist users, and nethopping. In fact, the logon message for AI tells people not to nethop. Maybe it's time to set some definite standard as to what can be done where. We also need to start making more use of the other two KS's; this would be greatly easier if they had TCP/IP. Do we have any volunteers to write the Ethernet driver code? WE apparently have the boards. I would suggest putting mail forwarding and the CHAOS/TCP protocol gateway on the two ARPANet connected machines (I assume there's no easy way to tell what percentage of these service requests go to machiens outside MIT, in which case these are the right machines; internal MIT conversion should go through the other two). All users (Lab and tourist) on the other two machines; nethopping should probably also be down through the other two machines. Comments? Noel  Date: Wed, 28 May 86 00:35:45 EDT From: "J. Noel Chiappa" Subject: Hopping tourists, etc To: USER-ACCOUNTS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU cc: JNC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].46979.860528.JNC> I have found tourists hopping to OZ through AI, in spite of the message that tells them not to. One claimed that hist\  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 22 May 86 01:44:53 EDT Date: Thu, 22 May 1986 01:44 EDT Message-ID: From: Rob Austein To: Peter Szolovits Cc: bug-doversend@XX.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Subject: wrong MC? In-reply-to: Msg of 22 May 1986 00:18-EDT from Peter Szolovits Date: Thursday, 22 May 1986 00:18-EDT From: Peter Szolovits To: bug-doversend@XX.LCS.MIT.EDU Re: wrong MC? Just now, I tried doversend-ing something, and it complained that it could not reach MC, which was down. Finger, however, reports one user on MC and tells me that it timed out waiting for MX. I wonder if doversend is looking for the old MC instead of the new one. No, it really was trying for the KL. The problem is that there are a whole slew of programs (and PROMs, god save us all) which just -know- that chaos 1440 is the address of the ITS running the Dover spooler. So we didn't move that service yet. KL really is down right now. So the only out and out bug is that DOVERSEND has all this hardwired knowledge of names and addresses (so much for software engineering). I guess we are going to be running a dover spooler on KS, at which point all the people with the burned PROMs will lose. But they are losing anyway, since KL is down and may never come back up again.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 20 May 86 21:36:39 EDT Date: Tue 20 May 86 21:37:20-EDT From: Rob Austein Subject: No pword on MC KS To: Moon@SCRC-STONY-BROOK.ARPA cc: ks-its@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU In-Reply-To: <860520201344.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12208325942.43.SRA@XX.LCS.MIT.EDU> I deleted the link for TCP TELNET (left the one for TCP SUPDUP). That will keep out the vast majority of the randoms without bothering us much. -------  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 20 May 86 21:17:00 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4700; Tue 20-May-86 20:16:23 EDT Date: Tue, 20 May 86 20:13 EDT From: David A. Moon Subject: No pword on MC KS To: ks-its@MIT-AI.ARPA cc: David Chapman In-Reply-To: <[MX.LCS.MIT.EDU].679.860520.ZVONA> Message-ID: <860520201344.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 20 May 86 18:57:59 EDT From: David Chapman OK, ks:.mail.;names > is in good enough shape to bring up ks as mc. It still needs more work (Goddess help me), but that can be postponed. Sure would be nice if we could bring up PWORD before tomorrow morning, bitch complain. I suggest deleting the IP-TCP telnet server (delete 3 or 4 links to SYSBIN;TELSER BIN on the DEVICE; directory) if you don't get pword up. That will keepnon-ingenious randoms out while a better solution is developed.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 MAY 86 18:57:01 EDT Date: Tue, 20 May 86 18:57:59 EDT From: David Chapman To: ks-its@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].679.860520.ZVONA> OK, ks:.mail.;names > is in good enough shape to bring up ks as mc. It still needs more work (Goddess help me), but that can be postponed. Sure would be nice if we could bring up PWORD before tomorrow morning, bitch complain.  Date: Tue, 20 May 86 14:15:41 EDT From: "J. Noel Chiappa" Subject: ITS brain transplant To: KS-ITS@AI.AI.MIT.EDU, mit-ip-people@MX.LCS.MIT.EDU, chaos-net-people@MX.LCS.MIT.EDU cc: JNC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].43059.860520.JNC> Ok, at 8AM tomorrow Joe Ricchio and I will power down the IMPs and switch the interface adapters. Alan is thinking about what needs to happen on the ITS front, and SRA will be present to lend a hand with COMSAT and HOSTS/Domain Name work. When we come back up, the KS will think it is MC and will be on the KL's old IMP port; it will not have the KL's CHAOS address since the KL's CHAOS address is on a virtual subnet. This is unfortunate but unavoidable; people on CHAOS sites should get a new HOSTS file ASAP after things come back up. The KS will be up first; once the bombs stop falling we will work on bringing the KL up as MX on DM's old IMP port.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 MAY 86 12:58:04 EDT Date: Mon 19 May 86 13:00:03-EDT From: "John Wroclawski" Subject: Re: KL-10 (MC) To: digex@AI.AI.MIT.EDU cc: ks-its@AI.AI.MIT.EDU Message-ID: <12207969631.29.JTW@MIT-SPEECH> This particular time, what we seem to need most of all is an M8530 Memory Controller board. If parts really aren't a problem for you guys, maybe we're in business. Knowing the whereabouts of a KL wizard is bound to be a great help, either to get things fixed, or just to ask questions. However, there is essentially -no- money available to keep this machine running, so it would be good if he was in it for fun.. -john -------  Date: Mon, 19 May 86 12:39:21 EDT From: Doug Humphrey Sender: ___017@AI.AI.MIT.EDU Subject: KL-10 (MC) To: ALAN@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42616.860519.___017> In case it is of use, we have a guy here on staff who knows KL's like the back of his hand. He worked for DEC for many years keeping most of the D.C. area KL's running and he really does know what is going on. I mentioned to him last week that your KL was coming off of maintenance, and that we might want to take a trip up there some time to fix it, and he sounded like it might be fun. Certainly spare parts for it should not be a problem. So if this sounds interesting, and you would like us to come up and take a shot at it, let me know. I am sure that it would take MIT months to arange things formaly, so maybe it would be best if we just sliped in quietly, fixed it, and then disapeared into the night..... Doug  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 18 May 86 01:32:31 EDT Date: Sun 18 May 86 01:34:55-EDT From: "J. Noel Chiappa" Subject: MX moved to DEBUGOZ port To: ks-its@AI.AI.MIT.EDU cc: mit-ip-people@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU Message-ID: <12207582761.38.JNC@XX.LCS.MIT.EDU> I needed the MIT-TSTGW port back (cabling issues) so I moved MX to the DEBUGOZ port, which is unused and turned on. I couldn't find anyone around to patch MX to know which port it's on, though. -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAY 86 02:02:38 EDT Received: from MIT-MORRISON.ARPA by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 32244; Thu 15-May-86 02:00:17-EDT Date: Thu, 15 May 86 02:00 EDT From: JCMA@MIT-AI.ARPA Subject: Mailing List Pointers To: pubs@OZ.AI.MIT.EDU cc: ks-its@MIT-AI.ARPA Message-ID: <860515020014.9.JCMA@MIT-MORRISON.ARPA> I added pointers to PUBLICATIONS@OZ from MIT-AI and MIT-REAGAN, both of which are on the internet. I suppose the best address for people requesting AI publications is PUBLICATIONS@MIT-AI. Some of the other KSs might want to point to the right place too.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAY 86 00:55:13 EDT Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 15 May 86 00:53:38 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 488224; Thu 15-May-86 00:50:38-EDT Date: Thu, 15 May 86 00:48 EDT From: David A. Moon Subject: Mail files on new MC? To: Pandora B. Berman cc: PSZ@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].41154.860514.CENT> Message-ID: <860515004824.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I think the load of snarfing a mail file off a KS via Chaosnet and reading it with Zmail is sufficiently low, and the amount of disk space involved is sufficiently small, that Pete's best bet is to keep his mail file on MX after it is in solid service and renamed to MC.  Date: Wed, 14 May 86 23:16:06 EDT From: "Pandora B. Berman" Subject: Mail files on new MC? To: PSZ@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].41154.860514.CENT> Date: Tue, 13 May 86 23:51 EDT From: Peter Szolovits Subject: Mail files on new MC To: cent@MIT-MC.ARPA When MC becomes the KS, I don't quite grok how it's going to work. Will users still be allowed/encouraged to have some place to receive their mail files on that machine, or will it simply be used to forward mail in all cases to other hosts? I.e., can I have some equivalent of MC:PSZ;PSZ MAIL collect on new MC? I am willing to keep my BABYL file and mail archives, etc., elsewhere, but it seems silly to have mail come to MC just to be sent on again, and running ZMAIL seems like the right time to snarf the MAIL file off MC. Do you know what the regimen will be? If not, who should I ask? Thanks. --Pete you have a couple options. you can continue to let your mail collect on the KL (where it is currently going). see your inquir entry -- all ITS inquir entries claiming MC as a net-address have been changed to KL. after the switch the KL/MX will only be on the chaosnet, so mail to PSZ@MC would then take one more hop to land in your mail file on the KL. the KL is no longer on contract, though, so the next time it breaks severely, it's gone; also dumps to tape are not to be expected (though TY may find some spare time to do one occasionally), so there's no guarantee of file back ups. you could, i suppose, let your mail live on the KS (which after the switch will be MC). this is not encouraged because we're going to make the KS fascist for an ITS. e.g., PWORD from everywhere. use of the KS will be discouraged because its principal job will be shoving mail around the network. active use of it will cut into the efficiency of this. snarfing your mail file off it onto a lispm would not be as bad as logging into the ITS and reading your mail there, but... you could make your local mail address be ML or MD. these will not be on the arpanet directly (just the chaosnet), so your mail will make the extra hop mentioned above. on the other hand, these ITSs will be the standard friendly type, so you are welcome to store your various archives etc there. please note that dumping these doesn't quite work yet, but moon thinks he understands the problem and will hack the code more in a day or two, so it will work soon. there is the additional consideration that MD is our source of spare parts, if/when the other three start to disintegrate. you could make AI your mail address. it's on the arpanet. it's like the KA used to be for system load/computron shortage. right now it's a bit tight on space (i need to get around to running a GFR).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 MAY 86 16:38:40 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 13 May 86 16:37:12 EDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18463; Tue 13-May-86 09:44:08 EDT Date: Tue, 13 May 86 09:42 EDT From: David C. Plummer To: David Chapman , BUG-DOVER@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].911005.860512.ZVONA> Message-ID: <860513094220.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 12 May 86 20:11:37 EDT From: David Chapman What should I do with the dover-related mailing lists? Is the new MC hardware going to run the dover spooler? Are some of these obsolete so they can be flushed? The lists are: BUG-DOVER, BUG-DOVER-FONTS, BUG-DOVARD, BUG-DPRESS, DOVER-FONT-CHANGES, DVRSPL, INFO-DPRESS I'd be a bit surprised if DOVARD is still used. DPRESS doesn't need the dover, it just needs a .press file and some fonts (and a graphics display (it uses SUPDUP graphics, so LispMs qualify)).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 MAY 86 22:10:51 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 12 May 86 22:09:20 EDT Date: Mon, 12 May 1986 21:18 EDT Message-ID: From: Rob Austein To: David Chapman Cc: BUG-DOVER@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of 12 May 1986 20:11-EDT from David Chapman There will be a doverspooler on KS, I guess. Sigh.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 MAY 86 20:17:05 EDT Date: Mon, 12 May 86 20:15:40 EDT From: David Chapman To: BUG-PEEK@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU cc: ZVONA@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].911011.860512.ZVONA> BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;? Some other directory on AI? Some altogether different place?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 MAY 86 20:12:49 EDT Date: Mon, 12 May 86 20:11:37 EDT From: David Chapman To: BUG-DOVER@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU cc: ZVONA@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].911005.860512.ZVONA> What should I do with the dover-related mailing lists? Is the new MC hardware going to run the dover spooler? Are some of these obsolete so they can be flushed? The lists are: BUG-DOVER, BUG-DOVER-FONTS, BUG-DOVARD, BUG-DPRESS, DOVER-FONT-CHANGES, DVRSPL, INFO-DPRESS  Date: Mon, 12 May 86 15:27:25 EDT From: Alan Bawden Subject: inquir progress To: CENT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 12 May 86 02:47:45 EDT from Pandora B. Berman Message-ID: <[AI.AI.MIT.EDU].37768.860512.ALAN> Date: Mon, 12 May 86 02:47:45 EDT From: Pandora B. Berman Date: Sun, 11 May 86 22:17:05 EDT From: "Christopher C. Stacy" When Lisp 4145 is installed on MD, I think all the pieces of INQUIR are here now. thanks. someone please move maclisp... Grumble. It isn't hard to move things yourself guys. In general, you just copy files until things work. So OK, I copied MacLisp to ML and MD myself. It seems to work. Now can we please have an INQUIR?  Received: from SAPSUCKER.SCRC.Symbolics.COM by AI.AI.MIT.EDU 12 May 86 15:00:48 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18066; Mon 12-May-86 14:27:36 EDT Date: Mon, 12 May 86 14:26 EDT From: David A. Moon Subject: Poor DCP is still getting mail on AI To: David C. Plummer cc: KS-ITS@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].37322.860511.DCP> Message-ID: <860512142645.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 11 May 86 12:58:28 EDT From: "David C. Plummer" I seem to be getting a message a day or so, including yesterday, on AI instead of having it get forwarded. Maybe there is a bug in COMSAT that lets it start frobbing mail before it has finished gobbling the inquir database? I believe this is the bug where it sees DCP@SCRC, sends SCRC to the domain resolver, the latter blows out because it's broken and only works half the time, so Comsat decides to ignore the host and do local delivery. Obviously this is a high priority bug, I understand SRA is working on it.  Date: Mon, 12 May 86 04:45:31 EDT From: "Pandora B. Berman" Subject: we got problems To: BUG-DUMP@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37609.860512.CENT> ML has caught MX's lassitude. this morning i dumped both of them incrementally. neither of them twiddled any backed-up bits after the .TAPE0; dir. dave, please work on this.  Date: Mon, 12 May 86 02:47:45 EDT From: "Pandora B. Berman" Subject: inquir progress To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37580.860512.CENT> Date: Sun, 11 May 86 22:17:05 EDT From: "Christopher C. Stacy" To: CENT%MD.LCS.MIT.EDU@MX.LCS.MIT.EDU When Lisp 4145 is installed on MD, I think all the pieces of INQUIR are here now. thanks. someone please move maclisp...  Date: Sun, 11 May 86 12:58:28 EDT From: "David C. Plummer" Subject: Poor DCP is still getting mail on AI To: KS-ITS@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37322.860511.DCP> I seem to be getting a message a day or so, including yesterday, on AI instead of having it get forwarded. Maybe there is a bug in COMSAT that lets it start frobbing mail before it has finished gobbling the inquir database?  Date: Sat, 10 May 86 05:37:09 EDT From: "Pandora B. Berman" Subject: dump status and like that To: KS-ITS@AI.AI.MIT.EDU, BUG-DUMP@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37043.860510.CENT> AI has a tu77 and is dumped regularly. it will probably need a GFR sometime in the pretty near future. MX has been dumped for a week. tonight some lossage turned up during the incremental, so moon's code probably needs more massaging. as far as i can tell, all the unbackedup files -were- dumped. however, somewhere between OAF; and SRA;, DUMP (actually MOON;ND) stopped diddling backed-up bits. the tape (204) is readable -- see AI:CENT;.OAF LIST (MX:OAF;ENERGY DSNLST) second-to-last marked AI:CENT;.SRA LOGIN (MX:SRA;SRA LOGIN) next-to-first unmarked AI:CENT;.ZVONA LOGIN (MX:ZVONA;ZVONA LOGIN) next-to-last file dumped (next-to files used for readability). this should be worked on. note that this dump was on GUT's drive with bpi forced to 1600. ML had its first full and incremental today (both via GUT), and apparently came through with flying colors. i got faked out by the tininess of the file system, and thought ND had spazzed at EOT and i needed to CDUMP onto a second tape, but it was just the (current) lack of files. MD does not yet have a working version of ND, so it can't yet be dumped. this should be fixed. for that matter, MD doesn't have EMACS yet -- someone please move it. for that matter, whoever has moved EMACS onto the newer KSs must have a dumped version or something, because i had to make the general links in SYS2; -- ya gotta remember these things. i can't say anything about the KL -- i think ty might be dumping it kind of occasionally in his spare time. people who care about their files should move them off (current) MC.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 8 May 86 07:46:48 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2693388755368144@MIT-MULTICS.ARPA>; 08 May 1986 07:32:35 edt Date: 08 May 86 00:44 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU, "Alan Bawden" Subject: State of the world Message-ID: <172046@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].35019.860506.ALAN> We are looking forward, to the moment when we can load the tape in the tape drive and have the system flying.  Date: Thu, 8 May 86 07:12:04 EDT From: "Pandora B. Berman" Subject: dumps To: MOON@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU, BUG-DUMP@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36101.860508.CENT> Date: Sat, 3 May 86 02:58:15 EDT From: "David A. Moon" Subject: dumps To: CENT@AI.AI.MIT.EDU I claim remote-tape DUMP is completely working now. it works fine, on MX. i will have to fix the MX greeting to stop lying. but it doesn't work on ML or MD; both claim that they can't connect to hermes.  Date: Tue, 6 May 86 00:40:15 EDT From: Alan Bawden Subject: State of the world To: KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].35019.860506.ALAN> There are now -five- machines running ITS at MIT, more than have ever existed simultaneously before. There is the MC KL10, and four KS10's named AI, MX, ML, and MD. The MC KL10 is off maintenance contract as of the first of this month, so I suppose its days are numbered. At some point before the KL10 passes on to that great machine room in the sky, the MC KL10 and the MX KS10 will swap their names, and we will plug the new MC KS10 into the old MC's Arpanet port. This assures that as far as the outside world is concerned, there will always be an ITS named MC at that Arpanet address, performing mail service functions for MIT. (Let's not get into the hair we will be going through to make all the mailing lists in the world continue to work.) The KL10 will remain available for all those who wish to continue to use it, under the name MX. When the KL10 retires, the name MX will be retired with it. Various other owners of KS10's around the world will be receiving KS10 ITS distribution tapes in the mail soon. The last machine we booted (MD) was built by a volunteer using the printed instructions we plan to include with our ITS distribution kits.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 2 May 86 20:10:45 EDT Date: Fri 2 May 86 20:10:44-EDT From: Karen R. Sollins Subject: MC imp port To: ks-its@AI.AI.MIT.EDU Message-ID: <12203591585.28.SOLLINS@XX.LCS.MIT.EDU> Well, we've been trying for a month and a half to get DCA, DARPA, BBN, and co. to turn the MC imp port into a distant host port, so that the DH-11 that ACC donated to us for the KS-10 can be put on it. When we started this in mid-March we were told that it was a 2-3 week task to get the paper work through and the change done. Well, they are still saying another 2-3 wks. We will escalate further next week, but I hope you are all patient. -------  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 MAY 86 03:59:20 EDT Date: 2 May 1986 03:58 EDT (Fri) Message-ID: From: "Leonard N. Foner" To: John Wroclawski Cc: deh@ENEEVAX.UMD.EDU, Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Subject: Computer Archeology In-reply-to: Msg of 2 May 1986 02:56-EDT from John Wroclawski Wow. That's really amazing. I'm at Eli's fairly frequently; the next time I go, I'll check it out... probably a couple of weeks. P.S. I wonder if, in its day, it was as "warm" as the 11/750 I saw them selling a while ago...  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 MAY 86 02:57:00 EDT Date: Fri 2 May 86 02:56:06-EDT From: John Wroclawski Subject: Re: Computer Archeology To: deh@ENEEVAX.ARPA cc: ks-its@AI.AI.MIT.EDU In-Reply-To: Message from "Douglas Humphrey " of Fri 25 Apr 86 04:43:59-EST Eli Heffron & Sons, at 1-somethingorother Hampshire St, Cambridge MA, had for the longest time a KS10 sitting in the back room. If they still have it, they might be willing to let it go real cheep. They are a combination surplus computer dealer, semiconductor parts place, and microcomputer store. If you can't get a number for foo&sons from information, try getting the number for "Solid State Sales" or "ELI Computers", then give 'em a call and ask for the number of the surplus equipment side of things. -------  Date: Wed, 30 Apr 86 18:35:52 EDT From: Rob Austein Subject: this is a test, please ignore it To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33195.860430.SRA> (weird comsat bug that shows up with this mailing list).  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 30 Apr 86 03:01:44 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA13614; Wed, 30 Apr 86 03:00:59 EDT Date: Wed, 30 Apr 86 03:00:59 EDT From: Douglas Humphrey Message-Id: <8604300700.AA13614@eneevax.umd.edu> To: ks-its@ai.ai.mit.edu Subject: alternate to 2020 ? Most likely this has already been covered, but did anyone check to see if a Foonly or Systems Concepts DEC-10 look alike was available to take over the work of MC ? Certainly it would have a lot more power than the KS10, but then there are also a host of reasons not to do this. Doug  Received: from SCRC-STONY-BROOK.ARPA by AI.AI.MIT.EDU 27 Apr 86 18:16:07 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 473355; Sun 27-Apr-86 18:13:49-EDT Date: Sun, 27 Apr 86 18:13 EDT From: David A. Moon Subject: LNS stuff To: Gumby@MIT-MC.ARPA cc: J. J. Tyrone Sealy , poor-mc@MIT-MC.ARPA, ks-its@MIT-AI.ARPA In-Reply-To: Message-ID: <860427181311.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 26 Apr 1986 10:17 EST (Sat) From: David Vinayak Wallace Date: Friday, 25 April 1986 13:09-EST From: J. J. Tyrone Sealy PS: I was told that LNS have some 7/9 track drives that can run with the tape controler that is now on MC. Can the ITS software hack it?? They are suppose to have about eight drives (working), that are gathering dust and space.. I believe we could also hook one of these up to a KS. There are no tape drives that are capable of hooking -both- to MC and to a KS.  Date: Tue, 29 Apr 86 10:09:16 EDT From: Alan Bawden Subject: Second LHDH working To: JNC@AI.AI.MIT.EDU cc: JTW@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU In-reply-to: Msg of Tue 29 Apr 86 09:52:01 EDT from J. Noel Chiappa Message-ID: <[AI.AI.MIT.EDU].32501.860429.ALAN> Date: Tue, 29 Apr 86 09:52:01 EDT From: J. Noel Chiappa I see that MX's LHDH is now working. What was wrong? There were some jumpers that needed to be changed to set the interrupt level. (I only set the dip switches initially.) JTW figured out what the problem was. DPH wielded the soldering iron.  Date: Mon, 28 Apr 86 17:16:02 EDT From: Rob Austein Subject: MX vs TSTGW To: KS-ITS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].32149.860428.SRA> I stole TSTGW's Arpanet address and gave it to MX. This should fix the mailer weirdness. I'm -not- going to (officially) tell the NIC; people outside MIT shouldn't know or care about the change. Since I don't feel particularly masochistic, the change won't go into effect until snarfed by the 4am XX batch job.  Received: from SCRC-STONY-BROOK.ARPA by AI.AI.MIT.EDU 27 Apr 86 18:16:07 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 473355; Sun 27-Apr-86 18:13:49-EDT Date: Sun, 27 Apr 86 18:13 EDT From: David A. Moon Subject: LNS stuff To: Gumby@MIT-MC.ARPA cc: J. J. Tyrone Sealy , poor-mc@MIT-MC.ARPA, ks-its@MIT-AI.ARPA In-Reply-To: Message-ID: <860427181311.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 26 Apr 1986 10:17 EST (Sat) From: David Vinayak Wallace Date: Friday, 25 April 1986 13:09-EST From: J. J. Tyrone Sealy PS: I was told that LNS have some 7/9 track drives that can run with the tape controler that is now on MC. Can the ITS software hack it?? They are suppose to have about eight drives (working), that are gathering dust and space.. I believe we could also hook one of these up to a KS. There are no tape drives that are capable of hooking -both- to MC and to a KS.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 26 Apr 86 10:18:52 EST Date: 26 Apr 1986 10:17 EST (Sat) Message-ID: From: David Vinayak Wallace To: "J. J. Tyrone Sealy" Cc: poor-mc@MC.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Reply-to: Gumby@mc Subject: LNS stuff In-reply-to: Msg of 25 Apr 1986 13:09-EST from J. J. Tyrone Sealy Date: Friday, 25 April 1986 13:09-EST From: J. J. Tyrone Sealy PS: I was told that LNS have some 7/9 track drives that can run with the tape controler that is now on MC. Can the ITS software hack it?? They are suppose to have about eight drives (working), that are gathering dust and space.. I believe we could also hook one of these up to a KS. They apparently also have a brace of KA's.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Apr 86 19:45:22 EST Received: by eneevax.umd.edu (5.9/4.7) id AA15613; Fri, 25 Apr 86 17:56:16 EST Date: Fri, 25 Apr 86 17:56:16 EST From: Douglas Humphrey Message-Id: <8604252256.AA15613@eneevax.umd.edu> To: RDZ@AI.AI.MIT.EDU, deh@ENEEVAX.UMD.EDU Subject: Re: Computer Archeology Cc: ALAN@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, RUMORS@AI.AI.MIT.EDU I will check on the Honeywell gear, but being a Large Company, who knows what they will do ?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 APR 86 16:37:52 EST Date: Fri, 25 Apr 86 16:37:36 EST From: Rob Austein To: BUG-MAIL@MC.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].895287.860425.SRA> COMSAT IV has achived stable orbit somewhere near MC.  Date: Fri, 25 Apr 86 12:52:44 EST From: Ramin Zabih Subject: Computer Archeology To: deh@ENEEVAX.UMD.EDU cc: ALAN@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, RUMORS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-reply-to: Msg of Fri 25 Apr 86 03:30:59 EST from Douglas Humphrey Message-ID: <[AI.AI.MIT.EDU].30876.860425.RDZ> MIT-Multics currently runs with DPS-8/60's. Do you know what flavor of DPS-8's these are? By the way, if we really want to preserve Multics perhaps we should ask MIT to give us its Multics when it goes away...  Date: Fri, 25 Apr 86 10:15:06 EST From: "Pandora B. Berman" Subject: moving day To: KS-ITS@AI.AI.MIT.EDU, LAUREL@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].30845.860425.CENT> MX and ML have undergone a mutual brain transplant. MX is now the KS between the LHDH bay and the 8N-HUBs, while ML is now the KS over beside MD, near the dover. MX is (still) running ITS; its LHDH doesn't work for some reason, but JTW et al are planning to work on this. ML and MD are still running Twenex, but that won't last. Oh, yeah, moon has the RTAPE software almost working (i think), although not yet explained to me. which means the not-AI KSs will soon be dumpable despite lack of personal tape drives. These advances have been brought to you as a public service by Cable Cannibalizers A division of Fly-By-Night Enteprises, Unltd.  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Apr 86 04:40:37 EST Received: by eneevax.umd.edu (5.9/4.7) id AA29374; Fri, 25 Apr 86 03:30:59 EST Date: Fri, 25 Apr 86 03:30:59 EST From: Douglas Humphrey Message-Id: <8604250830.AA29374@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU, RUMORS@AI.AI.MIT.EDU, deh@ENEEVAX.UMD.EDU Subject: Re: Computer Archeology Cc: KS-ITS@AI.AI.MIT.EDU I have never actualy looked at them, since I have not been in their computer room (typical large company security paranoia). I could ask them what they are like and what they plan to do with them. They are flushing them because they both went down one week, and the entire companies data base was down. The CE's took 3 weeks to get them running, in which time IBM had taken an order on, shipped, installed, and tested 2 4361 based systems. IBM was in, and Honeywell out. I will check. By the way, I am looking to get rid of my KA10 system and upgrade to something a little smaller and easier to play with. Unfortunately I can not come up with the $5,000 that is required for a 2020 system on which I would run ITS here in Washington D.C. which is certainly what I would like to do. Anyone want to buy a complete KA10 system ??? (snicker...) A question that has slightly better chances of being answered, does anyone know where I can get a 2020 Real Cheep ??? Doug Humphrey DEH @ ENEEVAX  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Apr 86 00:34:29 EST Date: Fri 25 Apr 86 00:28:27-EST From: "J. Noel Chiappa" Subject: Re: Computer Archeology To: deh@ENEEVAX.UMD.EDU, ALAN@AI.AI.MIT.EDU, RUMORS@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <8604250523.AA26880@eneevax.umd.edu> Message-ID: <12201552274.12.JNC@XX.LCS.MIT.EDU> How big are they? Standard small warehouse type Multics things or are these the new smaller machines. If they're the latter we'd probably be interested. Multics forever! -------  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Apr 86 00:23:48 EST Received: by eneevax.umd.edu (5.9/4.7) id AA26880; Fri, 25 Apr 86 00:23:12 EST Date: Fri, 25 Apr 86 00:23:12 EST From: Douglas Humphrey Message-Id: <8604250523.AA26880@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, RUMORS@AI.AI.MIT.EDU Subject: Re: Computer Archeology Cc: KS-ITS@AI.AI.MIT.EDU You shouldn't say that randomly. A friend of mine down here in an insurance company who read your message almost had two of them show up on your doorstep ! DPS-8's are not loved by a lot of people... Doug  Date: Thu, 24 Apr 86 18:50:25 EST From: Alan Bawden Subject: Computer Archeology To: RUMORS@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].30605.860424.ALAN> Given our luck with ITS, we are going to convince Honeywell to give us four DPS-8's to sit on the 9th floor next to our 2020's and run Multics.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 15 Apr 86 12:01:52 EST Date: Tue 15 Apr 86 11:59:06-EST From: "J. Noel Chiappa" Subject: C'mon, guys! To: ks-its@AI.AI.MIT.EDU cc: sollins@XX.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU Message-ID: <12199056561.19.JNC@XX.LCS.MIT.EDU> Has anyone made any attempts along the lines of unpacking the LHDH and plugging it in? Time is getting short, and ACC would also like to know if it is working OK. The cable we have is too short for permanent installation, but there is an 1822 extension cable in my office. Also, Karen Sollins is going to order a cable of the right length for permanent installation. Noel -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 APR 86 16:15:49 EST Date: Tue, 8 Apr 86 16:15:14 EST From: Alan Bawden Subject: movements, bay and other To: CENT@AI.AI.MIT.EDU cc: LAUREL@MC.LCS.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Tue 8 Apr 86 02:00:08 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].877844.860408.ALAN> Date: Tue, 8 Apr 86 02:00:08 EST From: Pandora B. Berman TU77 AI LHDHbay ML MINITS boxes MD--> VT52 AI sys little ML sys console table console MX--> ... AI's sysconsole can be pushed back some so that the output drops onto the bottom of the LHDH bay (the ROLM modems now there would have to be moved somewhere), which would give a little more space between the bays and the disks. But not, unfortunately, ML's sysconsole. Unless I mis-remember, there isn't any room in the bottom of the bays full of MINITS boxes. then later, when we get the right cables and ML comes up, perform brain surgery to provide the following situation: TU77 AI LHDHbay MX MINITS boxes MD--> VT52 AI sys little MX sys console table console ML--> this will have the feature that both LHDHs can fit in the bay, with minimal UNIBUS cable length to each CPU (there is no good place to put MX's LHDH, for the current value of MX).... Looks good to me. I -hate- moving stuff around, but this even has the advantage that we don't shuffle anything very far.  Date: Tue, 8 Apr 86 02:00:08 EST From: "Pandora B. Berman" Subject: movements, bay and other To: KS-ITS@AI.AI.MIT.EDU, LAUREL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].24990.860408.CENT> a proposal; i think other people have discussed it, but it needs to get into mail: at some point, relatively soon, switch the AI tape drive and the LHDH bay, thus giving the arrangement: TU77 AI LHDHbay ML MINITS boxes MD--> VT52 AI sys little ML sys console table console MX--> this provides, among other features, better access to the tape drive. AI's sysconsole can be pushed back some so that the output drops onto the bottom of the LHDH bay (the ROLM modems now there would have to be moved somewhere), which would give a little more space between the bays and the disks. then later, when we get the right cables and ML comes up, perform brain surgery to provide the following situation: TU77 AI LHDHbay MX MINITS boxes MD--> VT52 AI sys little MX sys console table console ML--> this will have the feature that both LHDHs can fit in the bay, with minimal UNIBUS cable length to each CPU (there is no good place to put MX's LHDH, for the current value of MX). brain surgery will involve switching 2 RP06 packs and changing the chaosnet addresses on the 2 machines involved; in other words, it would be trivial. comments?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 APR 86 01:47:12 EST Date: Wed, 2 Apr 86 01:47:47 EST From: David Vinayak Wallace Subject: LSRTNS and DMUNCH have to be updated for the new machines, To: BUG-INQUIR@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].869661.860402.GUMBY> which is a kluge. At the very least there should be some default behaviour for unknown machines.  Date: Tue, 1 Apr 86 21:02:30 EST From: David Chapman To: KS-ITS@AI.AI.MIT.EDU cc: AGRE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].23178.860401.ZVONA> I've updated AI:LMDOC; appropriately.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 19:22:30 EST Date: Fri, 28 Mar 86 19:23:48 EST From: "J. Noel Chiappa" Sender: ___034@MC.LCS.MIT.EDU Subject: ACC comes through To: KS-ITS@MC.LCS.MIT.EDU cc: sollins@XX.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].865057.860328.___034> For those of you who don't poke around on the 9th floor all the time, and haven't yet noticed it, the LHDH for MX is here. Now all we have to do is get the bureaucrats moving. (PS to hackers; we got a *manual*, *WITH PRINTS*, as well. We will be getting more, but if you can't wait, and want to Xerox it, that's plausible.) Noel  Date: Fri, 28 Mar 86 09:02:47 EST From: Alan Bawden Subject: A new ITS is born To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].22057.860328.ALAN> MIT-MX came up for the first time this morning. (You can supdup there right now, but you won't find much when you get there...) There are still some problems with the technology for creating new ITS systems from scratch, but it mostly works. Hopefully after doing the next two (ML and MD) things will be pretty smooth. All kind of worms are crawling out of the woodwork because of various programs that -know- that all ITS machines are named "AI", "MC", "ML", or "DM". It should take another days hacking to stomp them all...  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 27 Mar 86 12:25:30 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2689753507655122@MIT-MULTICS.ARPA>; 27 Mar 1986 04:45:07 est Date: 27 Mar 86 02:16 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU, "Pandora B. Berman" Cc: "Karen R. Sollins" Subject: look, george, here comes another one! Message-ID: <161042@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].21347.860325.CENT> Our KS-10 boot tape ??? cent?, alan? jtw?  Date: Thu, 27 Mar 86 05:12:27 EST From: "Pandora B. Berman" Subject: every day, in every way, we're getting better and better... To: KS-ITS@AI.AI.MIT.EDU cc: CJL@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].21760.860327.CENT> OZ kindly donated a drive to AI to help deal with the ITS space crunch. AI now has a SECOND:, because GLR and DPH and Our Man Lester helped move the drive and Alan writes good code. Also, CJL gets another round of applause for finding another ChaosNet transceiver cable; MD.LCS.foo.bar is now at 3132. ML.AI.foo.bar is still waiting for the right kind of disk cables, or something like that; it will be at 3133 when it comes up.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 MAR 86 14:01:15 EST Date: Wed, 26 Mar 1986 13:37 EST Message-ID: From: David Chapman To: "Pandora B. Berman" Cc: KS-ITS@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: look, george, here comes another one! In-reply-to: Msg of 25 Mar 1986 23:09-EST from Pandora B. Berman What do the names MD and MX mean, just out of curiosity?  Date: Tue, 25 Mar 86 23:09:44 EST From: "Pandora B. Berman" Subject: look, george, here comes another one! To: KS-ITS@AI.AI.MIT.EDU cc: sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].21347.860325.CENT> MX.LCS.foo.bar is now at chaos address 3131, thanks to help from CJL. this is the KS nearest the dover, with sysconsole nearest the KSs. as soon as alan makes a pack, we'll have another ITS. MD.LCS.foo.bar (the KS next to MX) is forced to wait until we get more cable and connectors in. this should not take long.  Date: Tue, 25 Mar 86 05:16:37 EST From: "Pandora B. Berman" Subject: we need another disk To: GLR@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].21135.860325.CENT> what with MC going off contract and lots of vital things needing to move to AI, causing a massive drain on free space. so i believe the plan is to take the VISION disk drive on wed. when you have OZ down for DEC to work it over. what do i need to do to facilitate this procedure? reap KANSAS: and VISION:?  Date: Sun, 23 Mar 86 21:27:35 EST From: Alan Bawden Subject: Grand migration begins To: BUG-ITS@AI.AI.MIT.EDU, BUG-DDT@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].20774.860323.ALAN> OK this is it. The migration of ITS system files from MC to AI is beginning. I have already moved a few directories and mailing lists and having just moved Bug-ITS and Bug-DDT to AI, I thought I would test them by informing you all of how this migration will work. I expect to have most of the SYS*** directories moved to AI by tomorrow. If you have some question about the status of a particular directory, look for a file on that directory named " MOVED TO AI ". If that file exists, then the file you are looking for now lives on AI, edits on MC are likely to be lost. If that file doesn't exist, then MC still has the master copy. In any case, if I am logged in, be cautious about timing screws.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 MAR 86 18:37:43 EST Date: Sun, 2 Mar 86 18:34:05 EST From: Rob Austein Subject: COMSAT To: BUG-MAIL@MC.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].835955.860302.SRA> I am claiming write locks on all network related files used by COMSAT. These include (but are not restricted to): CSTACY;RESOLV, CSTACY;DQDEV, KSC;OUT, SYSENG;NETWRK, SYSNET;NETRTS and of course COMSAT itself.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 FEB 86 14:42:59 EST Date: Thu, 27 Feb 86 14:39:32 EST From: David Vinayak Wallace Subject: resolvers and tables and mail, oh my To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-MAIL@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU In-reply-to: Msg of Wed 26 Feb 86 22:19 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].832771.860227.GUMBY> Date: Wed, 26 Feb 86 22:19 EST From: David A. Moon The problem with doing it this way (using a device) is that you have to pay device startup overhead every time you invoke the device. That might be a couple of seconds. What about JOBREU? Or we could have a call like CHAOSO which gives you a pair of channels to a jobdev.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 FEB 86 22:27:05 EST Received: from ALLEGHENY.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 26 Feb 86 22:23:45 EST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1142; Wed 26-Feb-86 22:23:11-EST Date: Wed, 26 Feb 86 22:19 EST From: David A. Moon Subject: resolvers and tables and mail, oh my To: Rob Austein cc: ks-its@AI.AI.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <860226221958.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 26 Feb 1986 13:28 EST From: Rob Austein There are several distinct problems that need to be solved. In decreasing order of priority: 1) COMSAT needs its address space back, so the moby HOSTS3 table has to get out of COMSAT's address space. 2) COMSAT needs to be able to do name<->address stuff for domains. 3) COMSAT needs to be taught to do sophisticated things with all this new mail related stuff that is part of the domain spec. It also has to preserve the string-format host name until actually sending the message, as opposed to the current practice of immediately converting to a HOSTS3 address. New timeouts have to be installed (since some formerly trivial operations can now take minutes), some amount of parallelism has to take place with the resolver (ie, COMSAT should go do something else while resolver is grinding away), scads of other things that I haven't thought of yet. Considerations: Task (1) needs to be done ASAP**2, if not sooner. Task (2) needs to be done ASAP but COMSAT will at least be a functional mailer again while this is under development. Task (3) will take a while, nobody has really done much of this anywhere yet and the ideas themselves are still being debugged. Separating out task 3 seems like a good idea to me. Proposed sollution: Step one is to take CSTACY's NETWRK clone routines I'm not sure what you mean by this but my best guess is "CSTACY" was a typo for "COMSAT" here. and adapt them for whatever high-speed comunication channel COMSAT is going to use to talk to its resolver (note that I do not say -the- resolver; if necessary I am willing to put up with having COMSAT have its own private resolver and cache until we can work out and code the details of a high bandwidth method of sharing the cache with the DQ: device or whatever incarnation the non-COMSAT resolver takes). Current top of the list of things to try is a core link, if that doesn't work out there are other things we can try. For a core link to work we need some way of making sure there is something on the other end of the core link; ideas here are normal USR: frobbing, a special system call to set up a core link and boot the other end of it if not already present, or maybe the old DM .DEMON stuff. In any case, once there is some communiction channel, COMSAT uses it instead of mapping in HOSTS3. As a first step, the thing on the other end will not be a resolver at all, just a job that grovels through HOSTS3 and returns an appropriate answer. This should be a two hour hack, modulo the core link (or whatever) code. CStacy already wrote a version of the DQ device that uses HOSTS3 instead of resolving and commented-out code in Comsat that talks to that version of the DQ device. The first thing to try is probably to turn this on and see what has to be done to make it work. I looked at it a little a month or two ago and didn't see any gross travesties, but I couldn't spend the time to turn it on and watch what happened to make sure it was working reliably. The problem with doing it this way (using a device) is that you have to pay device startup overhead every time you invoke the device. That might be a couple of seconds. A small cache of host name/address pairs inside Comsat might alleviate that for the time being (we're talking here just about the quickest way to get Comsat back on its feet). Probably a job inferior to Comsat communicating through shared memory, like the way XMAILR works (or used to work when I knew about it), would be the best way to give Comsat a resolver that is always in existence and doesn't have to wait for locks held by some user. This probably implies that this resolver doesn't use the same cache as the resolver that users use, or else the locking is done carefully so that things don't get hung up. Once it's an inferior job you don't gain anything by using a core link. The small cache of host name/address pairs might still be worthwhile, since it's so easy to do. If the DQ-device code is not totally bankrupt, and I have no judgement about that one way or the other, it's probably quite easy to make it work both as a JOB device handler and as an inferior job taking requests from its superior Comsat. Second step will be to replace the fake resolver with a real resolver. Part of the reason for doing the fake resolver is to have an easy way of backing out of losing resolver code; just punt the resolver and put the fake resolver back up (something a non-hacker can do, so that you aren't dependent on me being present 24 hours per day to get the mail through). In fact, the cannonical resolver boot file should just be a link to the resolver of the week (or day or minute...). Agreed. At this point COMSAT will be doing the same things it used to do with host tables but be doing them with domains. Experimental evidence from XX (who's MMAILR is currently at this stage) shows that this isn't that all horrible. It could be a lot better, but it works and the mail does get through. Once we get this far we'll be happy for a while.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU.ARPA; 26 Feb 86 13:30:34 EST Date: Wed, 26 Feb 1986 13:28 EST Message-ID: From: Rob Austein To: ks-its@AI.AI.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU cc: sra@XX.LCS.MIT.EDU Subject: resolvers and tables and mail, oh my [Forgive the wide distribution and length, I want to make sure nobody comes up to me later and flames about being left out.] As some of you know, I now have the twenex domain code basicly done, or at least in a state where I can leave it alone for a few months. So now I can start working on COMSAT. Premise: There are several distinct problems that need to be solved. In decreasing order of priority: 1) COMSAT needs its address space back, so the moby HOSTS3 table has to get out of COMSAT's address space. 2) COMSAT needs to be able to do name<->address stuff for domains. 3) COMSAT needs to be taught to do sophisticated things with all this new mail related stuff that is part of the domain spec. It also has to preserve the string-format host name until actually sending the message, as opposed to the current practice of immediately converting to a HOSTS3 address. New timeouts have to be installed (since some formerly trivial operations can now take minutes), some amount of parallelism has to take place with the resolver (ie, COMSAT should go do something else while resolver is grinding away), scads of other things that I haven't thought of yet. Considerations: Task (1) needs to be done ASAP**2, if not sooner. Task (2) needs to be done ASAP but COMSAT will at least be a functional mailer again while this is under development. Task (3) will take a while, nobody has really done much of this anywhere yet and the ideas themselves are still being debugged. Proposed sollution: Step one is to take CSTACY's NETWRK clone routines and adapt them for whatever high-speed comunication channel COMSAT is going to use to talk to its resolver (note that I do not say -the- resolver; if necessary I am willing to put up with having COMSAT have its own private resolver and cache until we can work out and code the details of a high bandwidth method of sharing the cache with the DQ: device or whatever incarnation the non-COMSAT resolver takes). Current top of the list of things to try is a core link, if that doesn't work out there are other things we can try. For a core link to work we need some way of making sure there is something on the other end of the core link; ideas here are normal USR: frobbing, a special system call to set up a core link and boot the other end of it if not already present, or maybe the old DM .DEMON stuff. In any case, once there is some communiction channel, COMSAT uses it instead of mapping in HOSTS3. As a first step, the thing on the other end will not be a resolver at all, just a job that grovels through HOSTS3 and returns an appropriate answer. This should be a two hour hack, modulo the core link (or whatever) code. Second step will be to replace the fake resolver with a real resolver. Part of the reason for doing the fake resolver is to have an easy way of backing out of losing resolver code; just punt the resolver and put the fake resolver back up (something a non-hacker can do, so that you aren't dependent on me being present 24 hours per day to get the mail through). In fact, the cannonical resolver boot file should just be a link to the resolver of the week (or day or minute...). At this point COMSAT will be doing the same things it used to do with host tables but be doing them with domains. Experimental evidence from XX (who's MMAILR is currently at this stage) shows that this isn't that all horrible. It could be a lot better, but it works and the mail does get through. Third step will be ad lib'd when I get that far. Comments?  Date: Wed, 12 Feb 86 10:42:54 EST From: David Chapman Subject: new procedure To: FILE-R@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].13601.860212.ZVONA> I have posted a new operations procedure on the AI CPU. It's explicitly intended for dealing with incrementals, but may be useful next time AI needs to be raised from the dead.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 FEB 86 23:07:36 EST Received: from BUDDY.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 10 Feb 86 23:07-EST Date: Mon, 10 Feb 86 23:05 EST From: Henry Lieberman Subject: New ITS To: David A. Moon , KS-ITS@MIT-AI.ARPA In-Reply-To: <860210122824.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860210230527.2.HENRY@BUDDY.AI.MIT.EDU> Reply-To: HENRY@MIT-MC.ARPA Indeed, but we could call it MIT-PDP-SIX, with nickname SX.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 FEB 86 12:48:08 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 10 Feb 86 12:48:33 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 413780; Mon 10-Feb-86 12:28:47-EST Date: Mon, 10 Feb 86 12:28 EST From: David A. Moon Subject: New ITS To: Henry Lieberman cc: KS-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].13101.860209.HENRY> Message-ID: <860210122824.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 9 Feb 86 19:39:05 EST From: Henry Lieberman Since one of the new ITS's is named AI after the old KA-10, why don't we name another ITS after the old PDP-6? Did the old pdp-6 have a name? I was under the impression that in its day there were so few computers in the lab that they didn't need names. I could be wrong, it's before my time.  Date: Sun, 9 Feb 86 19:39:05 EST From: Henry Lieberman Subject: New ITS To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].13101.860209.HENRY> Since one of the new ITS's is named AI after the old KA-10, why don't we name another ITS after the old PDP-6?  Date: Sat, 8 Feb 86 03:15:22 EST From: "Pandora B. Berman" Subject: Reports of ITS death have been highly exaggerated To: macrakis@HARVARD.HARVARD.EDU, sollins@XX.LCS.MIT.EDU cc: KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].12905.860208.CENT> Date: Sat, 4 Jan 1986 09:00 EST From: "Karen R. Sollins" To: KS-ITS@MC.LCS.MIT.EDU Subject: [macrakis: Death of MC] For all of you who have the time to spare, here's an interesting suggestion for one way to use up your spare time and more... Date: Monday, 3 February 1986 17:48-EST From: macrakis at harvard.HARVARD.EDU (Stavros Macrakis) To: sollins at mit-xx.arpa Re: Death of MC Given that MC and AI may die at any moment.... stavros, thank you for your concern and kind suggestion, but you are confused. the semi-original AI (that is, the KA-10 rather than the PDP-6) was flushed 3 years ago. the hardware was given to a bunch of hackers from Concourse (an MIT alternative undergrad program) -- after it walked across the street to Bldg. 20, the KA still ran, but had no memory, since its latest memory incarnation was all modified LispM Mem boards, which were given to needy Lispms when the Lab flushed the machine. i think the Concourse hackers have since had access to more of these Mem boards, but they have not (alas!) managed to bring the KA up in full-fledged fashion. the other KAs, ML and DM, were flushed about a year and a half ago. their hardware is probably down in the basement somewhere, but not likely in reconstitutable shape. MC, which i'm sure you're aware was the first KL DEC shipped and got running, is close to its last legs hardwarily. however, NONE OF THE ABOVE comprise sufficient reason to think ITS is dying. we have begged 4 KS-10s (2020s) from DEC, and with a fair amount of microcode and device-driver hacking have ported ITS to this new form of PDP10-family machine. one of them has succeeded to the name MIT-AI, and was just after long labor put onto the Arpanet last night. another is in the process of being brought up; with luck it will also sit on the Arpanet, bear the name MIT-MC, and do a lot of mail work. the other two still require power wiring, but that will happen. they will sit on the ChaosNet/Internet. we have not completely decided their names yet. there are too many people here who care about ITS for it to die.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 FEB 86 14:09:52 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 7 Feb 86 14:10:18 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 412491; Fri 7-Feb-86 14:01:08-EST Date: Fri, 7 Feb 86 14:00 EST From: David A. Moon Subject: AI To: John T. Wroclawski cc: KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].12767.860207.JTW> Message-ID: <860207140046.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 7 Feb 86 05:45:40 EST From: "John T. Wroclawski" Arpanet city, kids. HOT SHIIIIIIIT! Let's go!  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU.ARPA; 7 Feb 86 09:32:55 EST Date: Fri, 7 Feb 1986 09:33 EST Message-ID: From: Rob Austein To: ks-its@AI.AI.MIT.EDU, cr-people@COMET.LCS.MIT.EDU Subject: When we say reliable, we MEAN reliable And it came to pass that on the seventh day of February 1986, AI the KS10, godchild of AI the KA10 and child of much sweat, fast talking, and cussing, did come up upon the ARPANET as host 10.2.0.6. And there was much rejoicing and jumping up and down and comments of "Yow, verily, we are winning". And as we sat there, SUPDUPed in from various KL10s, running PEEK and marveling at the "(TCP)" indicators in the A display, we did see a small flurry of connections to the SMTP port. And we were somewhat bemused by this, since as far as the rest of the ARPANET could tell it had been 3 years since MIT-AI had last been up. And after a short time the flurry died down, and the entire net breathed a (quiet) sigh of relief that the two issues of SF-LOVERS and three Bandykin messages that had been caught in transit back when the KA was turned off had finally made it home to 10.2.0.6. ARPANET. When it absolutely, positively MUST get there, even if we have to build a new CPU to deliver it to.  Date: Fri, 7 Feb 86 05:45:40 EST From: "John T. Wroclawski" Subject: AI To: KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].12767.860207.JTW> Arpanet city, kids.  Date: Thu, 6 Feb 86 21:37:12 EST From: "Pandora B. Berman" Subject: dump lossage To: JTW%AI.AI.MIT.EDU@MC.LCS.MIT.EDU cc: KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].12729.860206.CENT> AI died again while trying to be dumped. this time it died partway into the checking phase. john, alan suggested it might be because you plugged the imp in again.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 FEB 86 09:01:22 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 4 Feb 86 09:01:49 EST Date: Sat, 4 Jan 1986 09:00 EST Message-ID: From: "Karen R. Sollins" To: KS-ITS@MC.LCS.MIT.EDU Subject: [macrakis: Death of MC] For all of you who have the time to spare, here's an interesting suggestion for one way to use up your spare time and more... Date: Monday, 3 February 1986 17:48-EST From: macrakis at harvard.HARVARD.EDU (Stavros Macrakis) To: sollins at mit-xx.arpa cc: macrakis at harvard.HARVARD.EDU Re: Death of MC Given that MC and AI may die at any moment, it would be nice if a demo of ITS could be run before MC goes away, and put on videotape. A lot of effort has gone into the ITS system, and some sort of record of it would be satisfying. And of course with the recent notoriety (`Hackers') of ITS and Tech Square, the future audience might be more than Tech Square people. Something along the lines of a home movie is what I have in mind. Maybe something about the system itself -- a `guided tour' showing all the little hacks. Ideally, the old hackers would be brought in and talk about their favorite hacks -- Gosper, Beeler, Schroeppel, Knight, Greenblatt, Jonl White, Stallman, ... And then maybe something about research. Of course, it would be hard to get many of the systems running, but Macsyma certainly works. It is ... how shall we put it ... hardly likely that Shrdlu could be put through its paces, but Microplanner and Conniver and so on have some hope. -s Stavros Macrakis (MIT '77; Macsyma Group '71-'77)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 JAN 86 18:36:31 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JAN 86 18:36:49 EST Date: Mon, 27 Jan 1986 18:34 EST Message-ID: From: PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "J. Noel Chiappa" Cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Subject: matters of taste In-reply-to: Msg of 27 Jan 1986 12:02-EST from J. Noel Chiappa I'd like to apologize to you, and to everyone else on this list, for having threatened you with physical violence. Your message telling me to fuck myself had a violence of its own, and it was because I was so surprised, angered, and distressed at this violent and childish reaction to my original message that I flew off the handle that way. As to your being deeply insulted by my message, I think I was rather gently and humorously pointing out that there was something inappropriate in the way you phrased your original message. Four or five people on this list sent me mail saying they appreciated the humor of my message, but that they saw nothing in it to explain why you reacted the way you did. If you feel aggrieved because you saw my message as publicly insulting you, you can console yourself with the thought that you are probably the only person who saw it that way.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 JAN 86 12:07:43 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 27 Jan 86 12:08:03 EST Date: Mon 27 Jan 86 12:02:46-EST From: "J. Noel Chiappa" Subject: Re: matters of taste To: PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12178609996.63.JNC@XX.LCS.MIT.EDU> I'd like to apologize to everyone on this list (although not to PGS, since I make a policy of not apologizing to people who threaten physical violence) for blowing up in an exceeding intemperate fashion; he touched a raw nerve of long standing. I was (and remain) deeply insulted at his characterization of my request, but that doesn't excuse my overreaction. It is my request that you *not* name the machines after the 'Silent Running' robots; I'm very unhappy at the way this all turned out. Noel -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 JAN 86 17:30:45 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86 17:30:00 EST Date: Fri, 24 Jan 1986 17:28 EST Message-ID: From: PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "J. Noel Chiappa" Cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Subject: matters of taste In-reply-to: Msg of 24 Jan 1986 15:20-EST from J. Noel Chiappa Date: Friday, 24 January 1986 15:20-EST From: J. Noel Chiappa To: PGS%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU cc: CENT%AI.AI.MIT.EDU at MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU at MC.LCS.MIT.EDU, sollins at XX.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU at MC.LCS.MIT.EDU, JNC at XX.LCS.MIT.EDU Re: matters of taste Go fuck yourself. I'll be back in a week. I suggest you hide.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 JAN 86 15:26:49 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 24 Jan 86 15:28:00 EST Date: Fri 24 Jan 86 15:20:08-EST From: "J. Noel Chiappa" Subject: Re: matters of taste To: PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12177859496.47.JNC@XX.LCS.MIT.EDU> Go fuck yourself. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 JAN 86 15:04:01 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86 14:53:45 EST Date: Fri, 24 Jan 1986 14:52 EST Message-ID: From: PGS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "J. Noel Chiappa" Cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Subject: matters of taste In-reply-to: Msg of 22 Jan 1986 15:50-EST from J. Noel Chiappa Date: Wednesday, 22 January 1986 15:50-EST From: J. Noel Chiappa ...As the person at MIT most responsible for the aquisition of the three machines, I'd like to see them named that. I protest this shoddy power play. Look, it's just too weird. The reasons for running ITS are mostly emotional, nostalgic, stuff like that. Huey, Dewie and Louie are the sorts of names you see in uucp headers from Usenet sites: decvax!huey!ucbvax!dewey!toronto!louie!hoboken-u!shmoe@udel-relay.csnet. See? They fit right in. Now check this out: decvax!ML!ucbvax!MC!toronto!DM!hoboken-u!shmoe@udel-relay.csnet. Not too believable, is it? And that's how we should keep it.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 JAN 86 18:46:14 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 23 Jan 86 18:47:27 EST Date: Thu, 23 Jan 1986 18:45 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: End of the rumor mill. In-reply-to: Msg of 23 Jan 1986 08:37-EST from Ken Harrenstien Date: Thursday, 23 January 1986 08:37-EST From: Ken Harrenstien About COMSAT. Unless something really bizarre has been done to it, there shouldn't be much trouble here. The problems I see mentioned are all things that can be readily fixed by someone who has the time to concentrate on it for a week or so. (I don't have it, but I and all the other past COMSAT hackers are of course available for questioning). For example, the address space gronkage can be fixed by moving either or both of the system-map or hosts3-map area into an inferior and using a shared page for Q&A interaction. That's sort of what I figured, although it will probably take me longer since I'm not an ITS wizard (that's ok, that's how one becomes an ITS wizard). I don't think anything particularly weird has happened, just the domain support needed and the address space crunch. CSTACY actually has done most of the hard work, he just hasn't *finished* it. I suspect that just finishing his NETWRK clone routines to talk to the resolver will be most of it, and the rest will just be using a smaller host table with just the MIT authoritative data (probably just Chaos+LCS+AI+RLE, no Athena stuff). The inferior job hack is a cute idea, which I will keep in mind if it proves necessary. Thanks for the comments, you may find a lot of silly questions from me in your mailbox one of these days.... --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 JAN 86 17:26:24 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 23 Jan 86 16:06:54 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 399844; Thu 23-Jan-86 15:57:43-EST Date: Thu, 23 Jan 86 15:58 EST From: David A. Moon Subject: End of the rumor mill. To: John Wroclawski cc: ks-its@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU In-Reply-To: The message of 22 Jan 86 19:05-EST from John Wroclawski Message-ID: <860123155804.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed 22 Jan 86 19:05:07-EST From: John Wroclawski 5) We need a way to reliably back up the KS, which doesn't have a tape drive at the moment. We either need someone to write a fast network backup system, or an RH11 Massbus controller so we can dual-port AI's TU77 or something and use that. I still plan to make remote-tape backup work. I now plan to temporarily abandon the remote-tape server for ITS and concentrate on the user end. Remote-tape servers already exist for TOPS-20, Unix, and the 3600. I did some quick estimating and I don't think the slow Chaosnet support on the KS will make a big difference to the speed compared to local tape, provided the load on the machine is light. We'll see. Of course this is a spare-time project and I can't promise any results.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 JAN 86 17:18:19 EST Date: Thu, 23 Jan 86 08:37:36 EST From: Ken Harrenstien Subject: End of the rumor mill. To: JTW@SPEECH.MIT.EDU cc: sollins@XX.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].793198.860123.KLH> Curiousity aroused by the MC broadcast, I wandered over to check my mail and patiently d'ed my way through the pile of ks-its stuff. Here are a few comments: You should be able to get away with swapping the KS for the KL on the IMP port without paperwork, considering that this is something on the order of doing board-replacement maintenance. The NIC would want to change the processor type in its database, but that is about it. Adding a new host on a new port would definitely involve DCA paperwork. There is not that much difference between a local-host and a distant-host IMP interface. BBN can change this easily enough, although time and paperwork would be involved. Note that you could simply build your own little LH/DH converter box, which is basically a lump of line drivers. We have one here at SRI which was used to hook a LH interface up with a DH IMP port. As a matter of fact, we also have a perfectly healthy IMP-11A interface here that no one wants (it belongs to an 11/40 that no one wants either). This isn't very different from an ACC to my knowledge; I've written driver code for a few of those things and it's pretty simple. I'm not sure why people seem to think the ACC is the only choice. If you want this one, I could check it out. About COMSAT. Unless something really bizarre has been done to it, there shouldn't be much trouble here. The problems I see mentioned are all things that can be readily fixed by someone who has the time to concentrate on it for a week or so. (I don't have it, but I and all the other past COMSAT hackers are of course available for questioning). For example, the address space gronkage can be fixed by moving either or both of the system-map or hosts3-map area into an inferior and using a shared page for Q&A interaction. Finally, the TCP/IP code itself can be improved. There are some simple things that can be done which should improve throughput and reduce load. I would not worry about the network traffic (although JNC is right that it should be hooked into an IMP; a gateway would collapse). I might have time to fiddle with this, especially if a MX test machine will be available for crash-testing. Good luck; the plan sounds good to me. --Ken  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 19:05:30 EST Date: Wed 22 Jan 86 19:05:07-EST From: John Wroclawski Subject: End of the rumor mill. To: ks-its@AI.AI.MIT.EDU cc: sollins@XX.LCS.MIT.EDU Well, we seem to have arrived at a plan. This is based on the recent KS-ITS explosion and a discussion with Karen Sollins, who has contributed a strong commitment to maintaining the network-wide services that MC has been providing, and a useful sense of practicality. The Goal: 1) Privide a replacement for the MC-KL which will handle mailing lists, archiving, and so on in a reliable manner. 2) Provide a way for the MC-KL to continue operation for a while after it is officially decommissioned, without it being in anybody's critical path. The Plan: Basically what Bill Rozas suggested. We're going to try using a KS to handle the mail. This machine will initially be called MIT-MX. It will be connected directly to the ARPAnet, and eventually to MIT ethernets as well. During the period from now to March 31 this machine will be used to test things that must work if the machine is to replace MC. If everything works OK, shortly after March 31 this machine will be renamed MC and connected to the ARPAnet at MC's address. The KL will be renamed MX, and will continue to be available until it isn't. If by sometime in March it is clear that the KS isn't going to be able to handle being MC, we will go to an alternate plan in which the new MC will be a Unix of some kind. The current NAMES > from MC will be automagically converted to sendmail format, and a way will be provided for lists to be editted without having an account on the machine. In this case the MC KL will still be renamed MX, and will continue to run for a while. The Booby Traps: The following things need to happen before we can do this. 1) We need an ACC LH/DH IMP interface, either for the KS or the vax, depending. People are looking into either buying this or getting ACC to help save MC. 2) We need a COMSAT repairperson. There is a volunteer. 3) We need some LH/DH code. Stay tuned. 4) We eventually need some ethernet code, both for this and the other two KS10s. A volunteer is urgently needed in this area. 5) We need a way to reliably back up the KS, which doesn't have a tape drive at the moment. We either need someone to write a fast network backup system, or an RH11 Massbus controller so we can dual-port AI's TU77 or something and use that. If you have an RH11 in your basement, please identify yourself to an usher. Thank you for your cooperation. 6) So what did I forget this time? -john -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 17:38:11 EST Date: Wed, 22 Jan 86 17:38:31 EST From: David Vinayak Wallace Subject: Machine names To: ED@MC.LCS.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 22 Jan 86 15:50:00 EST from Ed Schwalenberg Message-ID: <[MC.LCS.MIT.EDU].792467.860122.GUMBY> Date: Wed, 22 Jan 86 15:50:00 EST From: Ed Schwalenberg ...On the other hand, having the Fab Four back again would be wonderful, especially if we made Macsyma run only on DM, and Zork only on ML, and the index-off-the-PC hack only on MC... What's this about running COMSYS only on AI???  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 16:08:58 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 16:09:01 EST Date: Wed 22 Jan 86 15:58:30-EST From: "J. Noel Chiappa" Subject: Re: Machine names To: ED@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].792295.860122.ED> Message-ID: <12177342192.27.JNC@XX.LCS.MIT.EDU> I think the Jupiter was KC; (name removed to protect the guilty, insert our primo indutrial espionage agent) had some Jupiter prints at one point, and they had the model number on them. I could have dropped a bit, though. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 16:08:53 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 16:08:29 EST Date: Wed 22 Jan 86 15:55:36-EST From: "J. Noel Chiappa" Subject: Re: Enter the rumor mill To: ALAN@MC.LCS.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, JTW@SPEECH.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].791949.860122.ALAN> Message-ID: <12177341663.27.JNC@XX.LCS.MIT.EDU> Hey, I'm in favor, I just want people to watch the ground instead of the stars (and trip over their own feet). I agree with you that we should be talking about, and acting on, the practical tasks we need to do (e.g. COMSAT, ARPA suuport, etc). Once we have the pieces I can possibly work around the difficulties, but we need to have those precursors. JTW and Karen are discussing things, so something may happen. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 15:56:37 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 15:55:23 EST Date: Wed 22 Jan 86 15:50:16-EST From: "J. Noel Chiappa" Subject: Re: two of me To: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].11499.860122.CENT> Message-ID: <12177340693.27.JNC@XX.LCS.MIT.EDU> I think Karen Sollins is going to be sending a message about this, explaining exactly what is going to happen and dispelling the rumors, fairly shortly. She is going to attempt to get it to all the corners of he known universe. Also, the names were chosen because of the movie 'Silent Running', where they are the names of the three identical little droids. They Walt Disney correlation is accidental (although I am a great fan of old Disney animation). As the person at MIT most responsible for the aquisition of the three machines, I'd like to see them named that. Noel -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 15:49:39 EST Date: Wed, 22 Jan 86 15:50:00 EST From: Ed Schwalenberg Subject: Machine names To: KS-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].792295.860122.ED> We could name the four machines KA, KI, KL, and KS... And if we were to need more machines, I'll bet our contacts inside the Digital Widget Corp. could provide us with more-or-less real two-letter abbreviations for Jupiter and the like. On the other hand, having the Fab Four back again would be wonderful, especially if we made Macsyma run only on DM, and Zork only on ML, and the index-off-the-PC hack only on MC...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 11:28:52 EST Date: Wed, 22 Jan 86 11:28:57 EST From: Alan Bawden Subject: Enter the rumor mill To: JNC@XX.LCS.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Tue 21 Jan 86 23:02:02-EST from J. Noel Chiappa Message-ID: <[MC.LCS.MIT.EDU].791949.860122.ALAN> Date: Tue 21 Jan 86 23:02:02-EST From: J. Noel Chiappa I think I need to point out a few facts and probabilities here, guys, before you all go haring off and decide to glork the snazputt. This applies to all sorts of different camps, not just *you*. A) MC uses a different brand of IMP port from ALL the other machines in the building; it uses what is called a 'Local Host' interface while all the rest are 'Distant Host'. This means that you can't plug any other machine into MC's port without some hardware work, which will involve making a new non-standard cable. Also, the LH port uses coax for wires (it's TTL) and won't run more than about 30 feet. I don't want to go into all the details, but while it is possible to convert ports from one flavor to the other, it's not going to happen in this case. What this means is that you can forget plugging anything else into MC's port. Well, you have told us why it is hard, but you haven't told us why you assert "it's not going to happen". I guess I can assume there is some bureaucratic pinheadedness involved. So OK, let us assume for the moment that when MC turns into a pumpkin, its IMP port turns into a white mouse. B) Switching around which machine is plugged in where (namewise) and getting the NIC to update the HOSTS.TXT file that a lot of places still use requires the intervention of DCA. They absolutely, under no circumstances whatsoever, will do this until the have the piece of paper from DCA telling them they can do it. Needless to say, the DCA is a semi-infinite delay line. Scratch all solutions that require renaming MC and giving the name MC to something else. OK, so it can't be done -instantaneously-. Suppose for a while some people thought MC was at one address and some people thought it was at another. If they are using it to deliver mail, and we get our act together, they don't even have to lose. How hard is it to get that piece of paper through? (No need to begin your answer by telling me a long story about how fucked up they are, I already know that. Seriously, I understand. No, I don't want you to tell me a saga in five part harmony, I just want to know what we have to do, how long it will take, whose ass we have to kiss along the way.) I note, BTW, that you are excluding a whole class of solutions that don't invole frobbing the host tables at all. Ignoring the issue of local vs. distant host interfaces for the moment, realize that we can swap where a pair of cables go locally without anybodies permission and effectively swap the hardware. Are the DCA going to send the Turing police around to be sure that that is -really- a KL-10 plugged into that port? (Don't bother composing a reply to this paragraph pointing out the bugs, I'm not making a proposal here, I just want to add this particular device to the bag of ideas knocking around that we are trying to bang into a solution.) C) The labs are about to lose a large chunk of funding due to pending budget cuts; and I doubt there will be any money left over for buying any more LHDH-11's, (which are outrageously expensive). So, scsratch ideas that involve a new LHDH. Well, since we suspect that the -old- LHDH (the one connected to AI) might be fucked, there is a chance that this means scrap any idea involving any KS ever being connected directly to Arpanetland. D) The current traffic volume through MC is about 2.7 Mpkt/week, and that through the MIT-GW is about 3.3 Mpkt/week. They are both in the Top 10; the only machines with traffic rates near their combined sum are the MILNET<->ARPANET gateways, which are croaking under the load. If you were to try to use a machine that was on the MIT local nets as an MC replacement, the packet volume would croak the MIT-GW. Scratch using any machine on the internal MIT nets. And thus if the AI LHDH is fucked, scratch using an ITS for mail gateway service. Hello Unix. Pass me the barf bag. The conclusion that I reach from looking at these technical points is that the it would have to be a XX, a stripped MC, or AI (since I don't think OZ is ever going to make it onto the ARPANET). XX is too heavily loaded, and doesn't have a great TCP anyway. MC would be OK as long as it lasts but the CPU will probably fuse next big power glitch, and that will be that. AI is the best bet; people from the AI Lab actually wanting to use an ITS could use on of the other machines. More reasonable, assuming the AI LHDH works, would be to unplug it from AI and plug it into one of the other new KS machines. AI already has a small user-community, and it is more important that the machine that the users use has the tape drive directly connected to it. COMSAT is also the best mailer, I think, but I could be wrong about that. (Does anyone who knows care to comment?) The only bug in this scenario is that COMSAT is currently in a poor state of health. Some competent and reliable needs to become responsible for it before it is a serious contender. CSTACY is not a serious contender on the reliability front; someone who is expected to be around for a while would have to come forward. Unless this happens any hope of using an ITS for the job is idle chatter. Well, I -thought- I heard SRA hint that -perhaps- he would -consider- -possibly- thinking about this. I'm quite willing to toss the whole thing out the window and declare that ITS does not support any form of mail service any more. This morning my opinion is that the most important thing we could be doing for ITS is working on Interlan support so that we can get all of these machines on the Internet. Notice that we don't seem to be talking about that at all at the moment. Jesus Christ, Noel, don't you have anything positive to suggest?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 05:04:04 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 05:04:09 EST Date: Tue 21 Jan 86 23:02:02-EST From: "J. Noel Chiappa" Subject: Re: Enter the rumor mill To: JTW%MIT-SPEECH@MC.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: Message from "John Wroclawski " of Mon 20 Jan 86 18:16:54-EST Message-ID: <12177157150.21.JNC@XX.LCS.MIT.EDU> I think I need to point out a few facts and probabilities here, guys, before you all go haring off and decide to glork the snazputt. This applies to all sorts of different camps, not just *you*. A) MC uses a different brand of IMP port from ALL the other machines in the building; it uses what is called a 'Local Host' interface while all the rest are 'Distant Host'. This means that you can't plug any other machine into MC's port without some hardware work, which will involve making a new non-standard cable. Also, the LH port uses coax for wires (it's TTL) and won't run more than about 30 feet. I don't want to go into all the details, but while it is possible to convert ports from one flavor to the other, it's not going to happen in this case. What this means is that you can forget plugging anything else into MC's port. B) Switching around which machine is plugged in where (namewise) and getting the NIC to update the HOSTS.TXT file that a lot of places still use requires the intervention of DCA. They absolutely, under no circumstances whatsoever, will do this until the have the piece of paper from DCA telling them they can do it. Needless to say, the DCA is a semi-infinite delay line. Scratch all solutions that require renaming MC and giving the name MC to something else. C) The labs are about to lose a large chunk of funding due to pending budget cuts; and I doubt there will be any money left over for buying any more LHDH-11's, (which are outrageously expensive). So, scsratch ideas that involve a new LHDH. D) The current traffic volume through MC is about 2.7 Mpkt/week, and that through the MIT-GW is about 3.3 Mpkt/week. They are both in the Top 10; the only machines with traffic rates near their combined sum are the MILNET<->ARPANET gateways, which are croaking under the load. If you were to try to use a machine that was on the MIT local nets as an MC replacement, the packet volume would croak the MIT-GW. Scratch using any machine on the internal MIT nets. The conclusion that I reach from looking at these technical points is that the it would have to be a XX, a stripped MC, or AI (since I don't think OZ is ever going to make it onto the ARPANET). XX is too heavily loaded, and doesn't have a great TCP anyway. MC would be OK as long as it lasts but the CPU will probably fuse next big power glitch, and that will be that. AI is the best bet; people from the AI Lab actually wanting to use an ITS could use on of the other machines. COMSAT is also the best mailer, I think, but I could be wrong about that. (Does anyone who knows care to comment?) The only bug in this scenario is that COMSAT is currently in a poor state of health. Some competent and reliable needs to become responsible for it before it is a serious contender. CSTACY is not a serious contender on the reliability front; someone who is expected to be around for a while would have to come forward. Unless this happens any hope of using an ITS for the job is idle chatter. Noel -------  Date: Wed, 22 Jan 86 04:07:23 EST From: "Pandora B. Berman" Subject: two of me To: SRA%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11499.860122.CENT> Date: Mon, 20 Jan 1986 17:19 EST From: Rob Austein To: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the rumor mill Well, the cat is out of the bag now about the retirement of the current incarnation of MC.... in a rather large way. rumors are flying pretty rampantly over most of the large mailing lists, many of them badly informed. for instance, some propound that OZ will have no other way of reaching the arpanet. ...I will send a message to ARPANET-BBOARDS explaining that the hardware is dying but that we intend to continue to provide mail service (somehow) on a machine called MIT-MC, including the big mailing lists like ARPANET-BBOARDS. rob, you're the point man here. meaning you get to send the msg. and i think it should go out soon. which means we have to settle things. ---------- Date: Mon, 20 Jan 1986 21:35 EST From: Rob Austein Subject: Enter the rumor mill Date: Monday, 20 January 1986 20:04-EST From: David A. Moon To hell with them. Why should we have any more consideration for people's old habits than the people who imposed domains on the world? I think that in fairness to the rest of the known universe we ought to either maintain some kind of decent service or announce that we are opting out of this game. I am somewhat reluctant to do this (opt out) both for emotional reasons and because I don't want some cretin with a vax who hasn't even bothered to read the sendmail documentation taking on the job of ARPANET-BBOARDS.... btw, who -is- going to take over running ARPANET-BBOARDS from GSB? Can we push the Dover out the window? As soon as we are sure the other printers we have will work ok. a digressive side issue, dave. rob is right: nothing yet duplicates the dover's speed, and the new printers, while well-adapted to the more popular justifiers, do not yet allow me to print j random file with a font specified. (yeah, they say i can do that from a Lispm, but i don't think i should have to log into a lispm specifically to get this sort of service). they don't even hack R, not to mention TJ6 (i would like TJ6, although i realize it might be a little far-fetched to expect it). as Gumby later mentioned, the dover -can- sort of run TJ6. ---------- Date: 20 Jan 1986 22:40 EST (Mon) From: Bill Rozas Subject: Enter the rumor mill For what it is worth, here is my vote: 4) Something I didn't think of. I don't know whether this is possible or hard, but I am nostalgic and would like to have MC around in a different incarnation. Thus... I would suggest that we get an LH/DH and bring up the KS as MIT-DINOSUAR at whatever address the KL will eventually have.... At some point in the future, once the KL has been debugged and is ready, swap the KL and KS... ---------- Date: Tue, 21 Jan 86 00:30:36 EST From: Alan Bawden Subject: Enter the rumor mill Date: 20 Jan 1986 22:40 EST (Mon) From: Bill Rozas I would suggest... This actually strikes me as quite a reasonable plan as well. (Possibly the people in LCS who are still -using- MC might be made a little uncomfortable if we start discouraging logins, etc. right away, but the discouragement could be pretty mild, like a couple of obnoxious lines of text added to the login greeting.) Instead of MIT-DINOSAUR, might I suggest the name MIT-MX? Note that it has to be some name that is two letters long, or can easily be abbreviated to two letters, and "MX" seems like it might be a good hack.... frankly, i was under the impression that jinx's plan, with alan's name scheme, was proposed to general agreement some months ago, i've forgotten by whom. possibly i'm hallucinating. i thought those were ordinary button mushrooms in the hot&sour tonight... the local and other official users of the current MC can move to other local machines: AI, XX, the other KSs as they come up, various vaxen, etc. the non-lab tourists (all those macsyma users, random net hackers, high school students from mountain view CA & vienna VA, ad nauseum) should be treated differently. some of them are people we might be willing to grant similar guest accounts on AI; many of them we want to flush (all those macsyma users from the net!). we need to set up a clearinghouse for rumor control and account review, and soon. perhaps USER-A@MC should do this; Alan has suggested that instead, a special-purpose list be set up. the name of this list (yes, i volunteer to be on it) should be in the broadcast msg about MC's state. (We still need to decide what to call the other two of the three KS's. There is a strong faction that wants the three to have the names HUEY, DEWEY and LOUIE. There are machines with these names at UDEL, but -theoretically- that isn't a problem in the domain-style future. I really want one of them to be ML. Unfortunately the name DM went to some LCS Vax.) ---------- Date: 21 Jan 1986 14:41 EST (Tue) From: Bill Rozas Subject: Enter the rumor mill I think MX is a great name. I also think one of the new ones should be named ML, and, if possible, get DM back (maybe on the AI rather than LCS domain?) for the other. Might the people who own the fake DM be convinced that they want the name for their machine changed? ---------- Date: Tue, 21 Jan 86 15:39:55 EST From: Rob Austein Subject: Enter the rumor mill MX sounds kind of cute. The people currently owning the name DM are LCS HQ people, who probably don't care except that it will confused them if we try to take it away. I am the right person to talk to them about this, I guess. No, we can't have DM.AI.MIT.EDU because of this agreement that we won't have any name conflicts among the MIT community, or at least not between the parts that cooperate with each other (AI and LCS and RLE and maybe EECS). I don't particularlly like the duck names, would rather get back the old ITS names if we can. i don't like the duck names either. given the state of domains on the net, i do not trust -theoretical- non-problems like this. i gather we can snarf the name ML immediately? rob, could you ask LCS HQ to change their name (surely they would prefer something more officious)? if they won't, maybe we should use MD (note reference to MedGroup, which is an active LCS research group that uses MC). one issue not yet mentioned: all those 7track ITS dump tapes. once MC goes, -nothing- we have can read them until we get a surplus 7track drive somewhere, and somehow hook it up to a current machine. this has been discussed orally and various methods for the acquisition and the attachment proposed. the old ITS tapes should of course not be trashed, considering the valuable bits they contain, but there will be a period, possibly of a couple years, during which those bits will not be accessible. in the meantime, MC users must be urged to move their files elsewhere -including- all the reaped files that they used to have and still want. i suppose i should add myself to FILE-R@MC too.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 18:23:03 EST Date: Tue, 21 Jan 86 18:22:05 EST From: David Vinayak Wallace Subject: Enter the printer mill To: Moon@SCRC-STONY-BROOK.ARPA cc: KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU In-reply-to: Msg of Mon 20 Jan 86 22:59 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].791312.860121.GUMBY> Date: Mon, 20 Jan 86 22:59 EST From: David A. Moon Date: Mon, 20 Jan 86 22:02:13 EST From: David Vinayak Wallace Date: Mon, 20 Jan 86 20:04 EST From: David A. Moon Can we push the Dover out the window? This is not the list to discuss this on, but there are several programs which depend on the dover. How do I get my TJ6 output without it? As far as I know the only printer actually supported by TJ6 is the XGP. The dover has this crufy "XGP-emulation mode" though. More to the point, the dover is the only "high quality" (when the moon is full) and high-volume printer we have. Printing 150-page listings on a laserwriter or qms is not only time-consuming and antisocial, but doesn't give the tiny printer time to rest.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 17:13:39 EST Date: Tue, 21 Jan 86 17:14:05 EST From: Alan Bawden Subject: ai crash To: JTW@SPEECH.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, CENT@AI.AI.MIT.EDU In-reply-to: Msg of Tue 21 Jan 86 14:49:58-EST from John Wroclawski Message-ID: <[MC.LCS.MIT.EDU].791171.860121.ALAN> Date: Tue 21 Jan 86 14:49:58-EST From: John Wroclawski Does anyone know how long the NXM timeout on a KS10 unibus is? The Chaos board can be slower to respond (3 or 4 microseconds?) when you read it twice in a row, as I recall. I think I remember it being 20 us. Should be about 3600. micro clock ticks if I am reading the microcode correctly. Of course I can't recall how long such a tick is at the moment...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 15:39:36 EST Date: Tue, 21 Jan 86 15:39:55 EST From: Rob Austein Subject: Enter the rumor mill To: JINX@OZ.AI.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU, sollins@COMET.LCS.MIT.EDU In-reply-to: Msg of 21 Jan 1986 14:41 EST (Tue) from Bill Rozas Message-ID: <[MC.LCS.MIT.EDU].790969.860121.SRA> MX sounds kind of cute. The people currently owning the name DM are LCS HQ people, who probably don't care except that it will confused them if we try to take it away. I am the right person to talk to them about this, I guess. No, we can't have DM.AI.MIT.EDU because of this agreement that we won't have any name conflicts among the MIT community, or at least not between the parts that cooperate with each other (AI and LCS and RLE and maybe EECS). I don't particularlly like the duck names, would rather get back the old ITS names if we can.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 15:13:30 EST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JAN 86 14:50:57 EST Date: Tue 21 Jan 86 14:49:58-EST From: John Wroclawski Subject: Re: ai crash To: Moon@SCRC-STONY-BROOK.ARPA cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU In-Reply-To: Message from "David A. Moon " of Tue 21 Jan 86 14:15:38-EST Does anyone know how long the NXM timeout on a KS10 unibus is? The Chaos board can be slower to respond (3 or 4 microseconds?) when you read it twice in a row, as I recall. I think I remember it being 20 us. Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each other? If not, connecting a Unibus cable between them might cause electrical problems. That's a thought; they're not. I'm inclined to write this off to cosmic rays, and worry about it if it ever happens again after the hardware configuration of that unibus settles down. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 14:47:10 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JAN 86 14:47:02 EST Date: 21 Jan 1986 14:41 EST (Tue) Message-ID: From: Bill Rozas To: Alan Bawden Cc: JTW%SPEECH.MIT.EDU@XX.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU Subject: Enter the rumor mill In-reply-to: Msg of 21 Jan 1986 00:30-EST from Alan Bawden I think MX is a great name. I also think one of the new ones should be named ML, and, if possible, get DM back (maybe on the AI rather than LCS domain?) for the other. Might the people who own the fake DM be convinced thath they want the name for their machine changed?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 14:12:01 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 21 Jan 86 14:05:53 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397698; Tue 21-Jan-86 13:51:23-EST Date: Tue, 21 Jan 86 13:51 EST From: David A. Moon Subject: ai crash To: JTW@MIT-MC.ARPA cc: Alan Bawden , BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].790256.860120.ALAN> Message-ID: <860121135123.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 Jan 86 23:00:11 EST From: Alan Bawden Date: Mon, 20 Jan 86 22:32:34 EST From: Pandora B. Berman dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt complained about. see log for numbers. it was checking the incr. dump when this happened. after AI came up, the first time i tried to run ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE IN DEV. HUNG or something -- see sys log for details. the second time i tried ICHECK, it worked. The immediate cause of the crash was here in the interrupt level Chaos net code: CHSRC5: IORDI B,CAIRBF ;Read out the data, halfwords IORDI C,CAIRBF The second read from CAIRBF got a Non-Existent I/O Register error; just like someone had suddenly unplugged the Chaos board. I have a vague memory that Chaos boards do this sometimes. I hope I'm wrong. Alan and I discussed kludges for making the software resilient to this, but I hope we don't have to resort to them. It would be in the grand tradition of the previous two MIT-AI machines, though. If there were system messages from the magtape code indicating that it was unhappy as well, then perhaps we can conclude that the fault happened somewhere in the "I" Unibus itself. (It would be nice if :SYSMSG worked on a crash dump!) I used to have a program to do this, I think. Better would be to stick SYSMSG inside PEEK and then take advantage of PEEK's existing crash-dump-analysis feature. Perhaps someone who knows more Unibusology than I do can offer an opinion about what might cause this? Remember that this is the Unibus that supports the magtape drive, the DZ11's and the Chaosnet interface. The magtape code was shooting bits back and forth like crazy at the time, presumably that contributed somehow? JTW: Is the LH/DH plugged into this bus right now? Perhaps it did something nasty? JTW: Can you look at the crash dump and figure out whether the magtape RH-11 was supposed to be doing DMA at the time this crash happened? Maybe it and the Chaos board interfere with each other somehow? Does anyone know how long the NXM timeout on a KS10 unibus is? The Chaos board can be slower to respond (3 or 4 microseconds?) when you read it twice in a row, as I recall. Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each other? If not, connecting a Unibus cable between them might cause electrical problems.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JAN 86 00:30:39 EST Date: Tue, 21 Jan 86 00:30:36 EST From: Alan Bawden Subject: Enter the rumor mill To: KS-ITS@MC.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, JINX@OZ.AI.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Mon 20 Jan 86 23:02 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].790329.860121.ALAN> Date: Mon, 20 Jan 86 23:02 EST From: David A. Moon Date: 20 Jan 1986 22:40 EST (Mon) From: Bill Rozas I would suggest that we get an LH/DH and bring up the KS as MIT-DINOSUAR at whatever address the KL will eventually have. As soon as possible (now) start discouraging logins, etc. on MC (KL) and advertise that all service execept mail will disappear in the near future. At some point in the future, once the KL has been debugged and is ready, swap the KL and KS and eliminate logins or whatever. Having thought about it more, my opinion is now that this is the best plan. For some reason I don't like the name Dinosaur; that might be simple prejudice, because we at Symbolics reserve that name for machines with IBM 360 (and descendents) architecture. This actually strikes me as quite a reasonable plan as well. (Possibly the people in LCS who are still -using- MC might be made a little uncomfortable if we start discouraging logins, etc. right away, but the discouragement could be pretty mild, like a couple of obnoxious lines of text added to the login greeting.) Instead of MIT-DINOSAUR, might I suggest the name MIT-MX? Note that it has to be some name that is two letters long, or can easily be abbreviated to two letters, and "MX" seems like it might be a good hack. Before the exchange of names we can explain that the "X" stands for "Experimental" and afterwards it could stand for "Ex-MC". (We still need to decide what to call the other two of the three KS's. There is a strong faction that wants the three to have the names HUEY, DEWEY and LOUIE. There are machines with these names at UDEL, but -theoretically- that isn't a problem in the domain-style future. I really want one of them to be ML. Unfortunately the name DM went to some LCS Vax.)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 23:07:21 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 20 Jan 86 23:04:06 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397243; Mon 20-Jan-86 23:03:01-EST Date: Mon, 20 Jan 86 23:02 EST From: David A. Moon Subject: Enter the rumor mill To: Bill Rozas cc: John Wroclawski , ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <860120230251.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 20 Jan 1986 22:40 EST (Mon) From: Bill Rozas I would suggest that we get an LH/DH and bring up the KS as MIT-DINOSUAR at whatever address the KL will eventually have. As soon as possible (now) start discouraging logins, etc. on MC (KL) and advertise that all service execept mail will disappear in the near future. At some point in the future, once the KL has been debugged and is ready, swap the KL and KS and eliminate logins or whatever. Having thought about it more, my opinion is now that this is the best plan. For some reason I don't like the name Dinosaur; that might be simple prejudice, because we at Symbolics reserve that name for machines with IBM 360 (and descendents) architecture.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 23:03:11 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 20 Jan 86 23:01:56 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397240; Mon 20-Jan-86 22:59:24-EST Date: Mon, 20 Jan 86 22:59 EST From: David A. Moon Subject: Enter the printer mill To: David Vinayak Wallace cc: KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, FONER@OZ.AI.MIT.EDU, JTW@SPEECH.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].790169.860120.GUMBY> Message-ID: <860120225915.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 Jan 86 22:02:13 EST From: David Vinayak Wallace Date: Mon, 20 Jan 86 20:04 EST From: David A. Moon Can we push the Dover out the window? This is not the list to discuss this on, but there are several programs which depend on the dover. How do I get my TJ6 output without it? As far as I know the only printer actually supported by TJ6 is the XGP.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 23:02:08 EST Date: Mon, 20 Jan 86 23:00:11 EST From: Alan Bawden Subject: ai crash To: BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU cc: CENT@AI.AI.MIT.EDU In-reply-to: Msg of Mon 20 Jan 86 22:32:34 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].790256.860120.ALAN> Date: Mon, 20 Jan 86 22:32:34 EST From: Pandora B. Berman dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt complained about. see log for numbers. it was checking the incr. dump when this happened. after AI came up, the first time i tried to run ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE IN DEV. HUNG or something -- see sys log for details. the second time i tried ICHECK, it worked. The immediate cause of the crash was here in the interrupt level Chaos net code: CHSRC5: IORDI B,CAIRBF ;Read out the data, halfwords IORDI C,CAIRBF The second read from CAIRBF got a Non-Existent I/O Register error; just like someone had suddenly unplugged the Chaos board. If there were system messages from the magtape code indicating that it was unhappy as well, then perhaps we can conclude that the fault happened somewhere in the "I" Unibus itself. (It would be nice if :SYSMSG worked on a crash dump!) Perhaps someone who knows more Unibusology than I do can offer an opinion about what might cause this? Remember that this is the Unibus that supports the magtape drive, the DZ11's and the Chaosnet interface. The magtape code was shooting bits back and forth like crazy at the time, presumably that contributed somehow? JTW: Is the LH/DH plugged into this bus right now? Perhaps it did something nasty?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 22:42:17 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 22:40:08 EST Date: 20 Jan 1986 22:40 EST (Mon) Message-ID: From: Bill Rozas To: John Wroclawski Cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU Subject: Enter the rumor mill In-reply-to: Msg of 20 Jan 1986 18:14-EST from John Wroclawski For what it is worth, here is my vote: 4) Something I didn't think of. I don't know whether this is possible or hard, but I am nostalgic and would like to have MC around in a different incarnation. Thus... I would suggest that we get an LH/DH and bring up the KS as MIT-DINOSUAR at whatever address the KL will eventually have. As soon as possible (now) start discouraging logins, etc. on MC (KL) and advertise that all service execept mail will disappear in the near future. At some point in the future, once the KL has been debugged and is ready, swap the KL and KS and eliminate logins or whatever.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 22:37:10 EST Date: Mon, 20 Jan 86 22:02:13 EST From: David Vinayak Wallace Subject: Enter the printer mill To: Moon@SCRC-STONY-BROOK.ARPA cc: KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, FONER@OZ.AI.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Mon 20 Jan 86 20:04 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].790169.860120.GUMBY> Date: Mon, 20 Jan 86 20:04 EST From: David A. Moon Can we push the Dover out the window? This is not the list to discuss this on, but there are several programs which depend on the dover. How do I get my TJ6 output without it?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 22:26:27 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Jan 86 22:26:26 EST Date: Mon, 20 Jan 1986 22:26 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: FONER@OZ.AI.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the printer mill In-reply-to: Msg of 20 Jan 1986 22:02-EST from David Vinayak Wallace You write a TJ6 -> DVI converter, of course. We all gotta die sometime....  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 21:35:42 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Jan 86 21:35:40 EST Date: Mon, 20 Jan 1986 21:35 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the rumor mill In-reply-to: Msg of 20 Jan 1986 20:04-EST from David A. Moon [Nested quoting punted before I have to put my tty in 132 char mode] Date: Monday, 20 January 1986 20:04-EST From: David A. Moon To hell with them. Why should we have any more consideration for people's old habits than the people who imposed domains on the world? I think that in fairness to the rest of the known universe we ought to either maintain some kind of decent service or announce that we are opting out of this game. I am somewhat reluctant to do this (opt out) both for emotional reasons and because I don't want some cretin with a vax who hasn't even bothered to read the sendmail documentation taking on the job of ARPANET-BBOARDS. Some depths I am not willing to sink to.... I'm inclined towards #3 but I don't feel strongly and I'm not sure I rate a vote. Sure you get a vote. This whole thing is being done by selfless hackers for the Good of All (oh, you didn't know that sending mail to KS-ITS put you on the DoGooder's mailing list for all time?). Note that if the KL hardware remains named MC and remains attached to 44/3, but becomes an unreliable machine for private hacks, you can always turn off its mail server, or install one that rejects mail with a message somewhat more explanatory than "No children yet." That will certainly stop anybody who is still sending mail to it. Not a reasonable answer if you buy my fairness argument as above. This is the major reason I want to make the KS-MC the 10.3.0.44 address. We might as well get this all over with now if we can (ie, I don't want to have to turn the world upside down again next year when MC's CPU goes to the land where KL10-As are eternally blessed). Anything would be better than sendmail, even nothing at all! Just mentioning that it was a solved problem. Never let it be said that this list is content with the easy sollution. I do agree however that sendmail is just above dogsled as a mail delivery mechanism and should be avoided if possible. The machine where you put files that you want anyone in the world to be able to read without a password might as well be the same as the mail machine; it's not a heavy load, and this removes the need to tell the world about more than one of your machines. Good point. I like it. Although if all you care about is *reading* files, you can do that from XX too (none of this "anonymous login restrictions apply nonsense"). But an ITS is more useful since there are things that we want to be global write access too. Symbolics' mailer works quite well except for not having a domain resolver yet. It's been the only mailer we trust in-house for a couple of years now. Ok, fine. I'm still not going to touch it, but other people are welcome to do so. XX's MMAILR does have a resolver hookup, which works (most of the time and unless it decides to crash the machine instead). I'm not really wildly enthused about XX taking the load, but it's available if we need it. Can we push the Dover out the window? As soon as we are sure the other printers we have will work ok. But the old Doverspooler network protocol is probably bound for the dust heap anyway. JTW and I have been talking about implementing a 4.2bsd style LPD listener for ITS, since that seems to be the emerging standard for network print spooling (not a bad one either, barring some idiocies that we don't have to implement). But in any case it's a minor issue.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 20:57:15 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Jan 86 20:57:12 EST Date: Mon, 20 Jan 1986 20:30 EST Message-ID: From: Rob Austein To: "Leonard N. Foner" Cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the rumor mill Same thing as Gail said goes for all other MIT software (like the Dover spooler). Nobody said this would be easy, the question is just how to keep from having to update things (and people's minds) all over the whole Internet. Thanks for bringing it up, but it is relatively unimportant in the global scheme of things.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 20:09:43 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 20 Jan 86 20:08:58 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397145; Mon 20-Jan-86 20:04:38-EST Date: Mon, 20 Jan 86 20:04 EST From: David A. Moon Subject: Re: Enter the rumor mill To: John Wroclawski , Rob Austein , Leonard N. Foner cc: John Wroclawski , ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, John Wroclawski In-Reply-To: The message of 20 Jan 86 18:14-EST from John Wroclawski , , Message-ID: <860120200430.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon 20 Jan 86 18:14:17-EST From: John Wroclawski Although I like the idea, giving the MC name to a KS has a couple of problems. 1) I imagine there are a lot of people that have MC == IMP 44, HOST 3 wired into their tiny little minds, and moving its IP address is going to be a pain. To hell with them. Why should we have any more consideration for people's old habits than the people who imposed domains on the world? 2) There is general agreement that a KS devoted to mail will be pretty busy, so we have to find some polite way of discouraging other types of heavy non-MIT use from people who are used to MC being there. I agree. Naming the machine MIT-PO (post office) or something might help solve these problems. It would also give us a chance to get this working before MC totally dies. Balanced against that is that it would create an awful lot of confusion. If we are going to name a KS MC, I think we should acquire another LHDH IMP interface and put it on the Arpanet at 3/44. Then we should make up something to tell people who have been using it for other things. Also (Oh boy I hate to bring this up) there is the question of what exactly is going to be done with the KL hardware when. Based on past history and the desires of many people I pretty much expect to see a somewhat shrunken MC-KL running for some time after it is un-DECified, until the processor fuses itself into a glob some day. We can't have two MCs, and I don't think I want to count on an unmaintained KL for mail service, even if we do trash the T300s and the Ampex. I agree with both parts of the preceding paragraph. JTW's unscientific opinion pole. Please vote. 1) Name the KS MC, rename the KL MIT-DINOSAUR, get an LH/DH, and pertend nothing happened. 2) As above, but forget the LH/DH. (leaving floating for the moment the question of how, exactly, the KS is supposed to speak IP). 3) Name the KS MIT-PO (Oh, all right, PO.LCS.MIT.EDU, or maybe even PO.MIT.EDU), and move all the mailing lists. Keep the KL as MC till it dies. We still could use an LH/DH. 4) Something I didn't think of. I'm inclined towards #3 but I don't feel strongly and I'm not sure I rate a vote. Note that if the KL hardware remains named MC and remains attached to 44/3, but becomes an unreliable machine for private hacks, you can always turn off its mail server, or install one that rejects mail with a message somewhat more explanatory than "No children yet." That will certainly stop anybody who is still sending mail to it. Finally, I'm not sure 4.2 sendmail is a reasonable fallback position unless someone is going to really work on it. There are just too many things it does badly or not at all. Either MMAILR/Twenex or the Symbolics mailer might be a better choice. Anything would be better than sendmail, even nothing at all! Date: Mon, 20 Jan 1986 18:33 EST From: Rob Austein Well, my zero-real-data guess is that the vast majority of the references to "MIT-MC" around the world are mailing list stuff. While I there are other things and they will be a pain, this can be solved on a practical level by running PWORD, not having user accounts on the KS-MC except for wizards, and leaving up a sysmsg telling people that they really want to telnet to MIT-DINOSAUR. Maybe something more polite/elegant can be worked out (like that will also cover FTP) but this will be enough to get by. The machine where you put files that you want anyone in the world to be able to read without a password might as well be the same as the mail machine; it's not a heavy load, and this removes the need to tell the world about more than one of your machines. I think that the most reasonable thing to do for net connection is to put an LH/DH on 10.3.0.44 and the hell with the users if they can't take a joke. Of course this presumes that the device driver will be finished. I think this comes out as a vote for option (1). As for mailers. The sendmail stuff is already done (against my wimpy objections, which were wimpy indeed because at that point I wasn't even considering taking over maintainance of COMAST). I agree that sendmail is a real loser (this is a technical opinion which I will back up to anybody who is offended by it). I would volunteer XX's MMAILR as an interim sollution except for the IP address problem, and I am obviously not going to change XX's IP address. Symbolics mailer I don't know from and don't really have time to learn at this point. If somebody else wants to watch over it, fine, but I am not going to touch it. Symbolics' mailer works quite well except for not having a domain resolver yet. It's been the only mailer we trust in-house for a couple of years now. Date: 20 Jan 1986 19:32 EST (Mon) From: "Leonard N. Foner" Seems to me that there are other things that depend on either MC's name or (more probably) its network address besides mail. They won't break the world, since they're local to MIT, but it'd be nice if they continued to work. What things? Well, the Dover spooler, for one. For another, OZ's internet FTP "knows" to use MC as a bridge; I don't know how wired-in that is. Can we push the Dover out the window? I assume OZ will be switched to use AI as a gateway the day AI has Internet support installed. In any case, anything inside MIT is thousands of times easier to change than references to MIT-MC outside MIT, so it shouldn't be much of a concern.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 20:01:38 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 20:01:33 EST Date: Mon 20 Jan 86 20:01:27-EST From: "Gail Zacharias" Subject: Re: Enter the rumor mill To: foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12176862131.34.GZ@OZ.AI.MIT.EDU> Any explicit references to MC in local OZ software can and will be fixed. It's a non-issue. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 19:32:47 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 19:32:46 EST Date: 20 Jan 1986 19:32 EST (Mon) Message-ID: From: "Leonard N. Foner" To: Rob Austein Cc: Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, John Wroclawski , ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the rumor mill In-reply-to: Msg of 20 Jan 1986 18:33-EST from Rob Austein I don't want to butt in here, but I've got a question. Seems to me that there are other things that depend on either MC's name or (more probably) its network address besides mail. They won't break the world, since they're local to MIT, but it'd be nice if they continued to work. What things? Well, the Dover spooler, for one. For another, OZ's internet FTP "knows" to use MC as a bridge; I don't know how wired-in that is. Can anyone think of other non-mail services that depend on MC's address? Is any of them important enough to *really* shoot down the sendmail solution? (I'm biased; I've seen enough sendmail disasters that I don't trust it as a replacement for COMSAT.)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 18:33:51 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Jan 86 18:33:50 EST Date: Mon, 20 Jan 1986 18:33 EST Message-ID: From: Rob Austein To: John Wroclawski Cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the rumor mill In-reply-to: Msg of 20 Jan 1986 18:14-EST from John Wroclawski Well, my zero-real-data guess is that the vast majority of the references to "MIT-MC" around the world are mailing list stuff. While I there are other things and they will be a pain, this can be solved on a practical level by running PWORD, not having user accounts on the KS-MC except for wizards, and leaving up a sysmsg telling people that they really want to telnet to MIT-DINOSAUR. Maybe something more polite/elegant can be worked out (like that will also cover FTP) but this will be enough to get by. I think that the most reasonable thing to do for net connection is to put an LH/DH on 10.3.0.44 and the hell with the users if they can't take a joke. Of course this presumes that the device driver will be finished. I think this comes out as a vote for option (1). As for mailers. The sendmail stuff is already done (against my wimpy objections, which were wimpy indeed because at that point I wasn't even considering taking over maintainance of COMAST). I agree that sendmail is a real loser (this is a technical opinion which I will back up to anybody who is offended by it). I would volunteer XX's MMAILR as an interim sollution except for the IP address problem, and I am obviously not going to change XX's IP address. Symbolics mailer I don't know from and don't really have time to learn at this point. If somebody else wants to watch over it, fine, but I am not going to touch it.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 18:15:41 EST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 18:15:04 EST Date: Mon 20 Jan 86 18:14:17-EST From: John Wroclawski Subject: Re: Enter the rumor mill To: SRA@XX.LCS.MIT.EDU cc: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU In-Reply-To: Message from "Rob Austein " of Mon 20 Jan 86 17:24:01-EST Although I like the idea, giving the MC name to a KS has a couple of problems. 1) I imagine there are a lot of people that have MC == IMP 44, HOST 3 wired into their tiny little minds, and moving its IP address is going to be a pain. 2) There is general agreement that a KS devoted to mail will be pretty busy, so we have to find some polite way of discouraging other types of heavy non-MIT use from people who are used to MC being there. Naming the machine MIT-PO (post office) or something might help solve these problems. It would also give us a chance to get this working before MC totally dies. Balanced against that is that it would create an awful lot of confusion. If we are going to name a KS MC, I think we should acquire another LHDH IMP interface and put it on the Arpanet at 3/44. Then we should make up something to tell people who have been using it for other things. Also (Oh boy I hate to bring this up) there is the question of what exactly is going to be done with the KL hardware when. Based on past history and the desires of many people I pretty much expect to see a somewhat shrunken MC-KL running for some time after it is un-DECified, until the processor fuses itself into a glob some day. We can't have two MCs, and I don't think I want to count on an unmaintained KL for mail service, even if we do trash the T300s and the Ampex. JTW's unscientific opinion pole. Please vote. 1) Name the KS MC, rename the KL MIT-DINOSAUR, get an LH/DH, and pertend nothing happened. 2) As above, but forget the LH/DH. (leaving floating for the moment the question of how, exactly, the KS is supposed to speak IP). 3) Name the KS MIT-PO (Oh, all right, PO.LCS.MIT.EDU, or maybe even PO.MIT.EDU), and move all the mailing lists. Keep the KL as MC till it dies. We still could use an LH/DH. 4) Something I didn't think of. Finally, I'm not sure 4.2 sendmail is a reasonable fallback position unless someone is going to really work on it. There are just too many things it does badly or not at all. Either MMAILR/Twenex or the Symbolics mailer might be a better choice. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 17:19:48 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Jan 86 17:19:34 EST Date: Mon, 20 Jan 1986 17:19 EST Message-ID: From: Rob Austein To: ks-its@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU Subject: Enter the rumor mill Well, the cat is out of the bag now about the retirement of the current incarnation of MC. Unless somebody else wants to do it or thinks it is a bad idea, I will send a message to ARPANET-BBOARDS explaining that the hardware is dying but that we intend to continue to provide mail service (somehow) on a machine called MIT-MC, including the big mailing lists like ARPANET-BBOARDS. In case people haven't heard, we (LCS Computational Resources Group) have cobbled together a setup that will allow us to do this with a 4.2 unix if this is absolutely necessary. For many reasons, some technical and some religious, it is obviously preferable to continue to use an ITS for this stuff, but doing it with a 4.2 sendmail is better than not at all. If I don't hear any serious objections from anybody in the next day or two I'll send off a message. --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 JAN 86 14:42:59 EST Date: Mon, 20 Jan 86 14:42:57 EST From: David Vinayak Wallace Subject: [Forwarded: Steiner at RED, Re: WorkS Digest] To: ALAN@MC.LCS.MIT.EDU cc: CBF@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Sun 19 Jan 86 22:51:08 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].789664.860120.GUMBY> Date: Sun, 19 Jan 86 22:51:08 EST From: Alan Bawden What kinds of currency are you interested in? Fast cars? Fast women? Fast drugs? Fast food? If we give him multiple KS's to run MACLISP on he can have CONS-currency!  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JAN 86 22:51:41 EST Date: Sun, 19 Jan 86 22:51:08 EST From: Alan Bawden Subject: [Forwarded: Steiner at RED, Re: WorkS Digest] To: SRA@XX.LCS.MIT.EDU cc: CBF@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Sun 19 Jan 1986 16:52 EST from Rob Austein Message-ID: <[MC.LCS.MIT.EDU].789116.860119.ALAN> Date: Sun, 19 Jan 1986 16:52 EST From: Rob Austein Well, I've been talking about how nice it would be to have a KS-ITS as a single user machine (which is probably all the users it could support if there's also a loaded COMSAT anyway, yes?). If I had such a beastie I would want to have a working mailer. (Not quite. COMSAT spends a lot of time twiddling its thumbs waiting for replies from network-land. COMSAT running on a KA-10 wasn't as much worse as COMSAT running on a KL-10 as you might think if you compared raw processor power. There will be some crunch left over, but yeah, not all -that- much...) Given that we will have to tell the world that -some- machine is a replacement mailing address for MIT-MC, and given that if we move the name MC somewhere it should probably be that same machine, and given that everybody thinks it is reasonable to designate one of the 3 new machines as a "Mail Machine", then I have no objection to putting SRA in charge of its operations... There is a problem, of course, in that we currently have no -immediate- prospects of putting any KS-10 other than AI onto the Internet. That problem could be overcome by getting another LH/DH and finishing the driver for that, or starting and finishing an Interlan driver. Make me an offer.... What kinds of currency are you interested in? Fast cars? Fast women? Fast drugs? Fast food?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JAN 86 16:53:23 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Jan 86 16:52:38 EST Date: Sun, 19 Jan 1986 16:52 EST Message-ID: From: Rob Austein To: John Wroclawski Cc: CBF@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU Subject: [Forwarded: Steiner@RED.RUTGERS.EDU, Re: WorkS Digest] In-reply-to: Msg of 19 Jan 1986 16:40-EST from John Wroclawski Well, I've been talking about how nice it would be to have a KS-ITS as a single user machine (which is probably all the users it could support if there's also a loaded COMSAT anyway, yes?). If I had such a beastie I would want to have a working mailer. Make me an offer....  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JAN 86 16:41:48 EST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 JAN 86 16:41:14 EST Date: Sun 19 Jan 86 16:40:27-EST From: John Wroclawski Subject: Re: [Forwarded: Steiner@RED.RUTGERS.EDU, Re: WorkS Digest] To: SRA@XX.LCS.MIT.EDU, CBF@MC.LCS.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU In-Reply-To: Message from "Rob Austein " of Sun 19 Jan 86 16:25:36-EST There seems to be general agreement that we devote one of the KSi to being a mail server. Apparently we are in some need of a COMSAT hacker, though, if this is to work. Anybody out there? -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JAN 86 16:23:09 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Jan 86 16:22:26 EST Date: Sun, 19 Jan 1986 16:22 EST Message-ID: From: Rob Austein To: Charles Frankston Cc: KS-ITS@MC.LCS.MIT.EDU Subject: [Forwarded: Steiner@RED.RUTGERS.EDU, Re: WorkS Digest] In-reply-to: Msg of 19 Jan 1986 16:15-EST from Charles Frankston We hope. Depends on a lot of things, but we still have a few months to set up, we have the hardware, we have the hackers, we just need to toss it all in a pot and turn up the heat....  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 JAN 86 16:16:00 EST Date: Sun, 19 Jan 86 16:15:30 EST From: Charles Frankston Subject: [Forwarded: Steiner@RED.RUTGERS.EDU, Re: WorkS Digest] To: KS-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].788815.860119.CBF> Is the right response to tell these guys not to worry, that there will be a replacement machine with the MC name soon enough? ------------------- Date: 17 Jan 86 01:24:16 EST From: Dave Subject: WorkS Digest To: "MIT-MC People": ; Reply-To: WorkS-Request@Rutgers Message-ID: <12175872323.4.STEINER@RED.RUTGERS.EDU> Hi, I've heard news that MC will be going away soon. If you are receiving this message, you are getting the WorkS Digest sent to (or through) MIT-MC. Please send me a change of address. thanks, ds ------- Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 JAN 86 19:41:28 EST Date: Sat 18 Jan 86 19:38:26-EST From: "Anita M. Flynn" Subject: Re: Basketball To: CBF@MC.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].788360.860118.CBF> Message-ID: <12176333652.26.ANITA@OZ.AI.MIT.EDU> Sure. Send mail to buckley, he's the subcaptain. -Anita -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 JAN 86 04:49:37 EST Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jan 86 04:47:57 EST Received: from bostonu by csnet-relay.csnet id ac02199; 6 Jan 86 4:39 EST Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7) id AA14297; Sun, 5 Jan 86 17:08:56 est Date: Sun, 5 Jan 1986 17:09 EST Message-Id: <[BUCS20].JSOL. 5-Jan-86 17:09:02> From: Jon Solomon To: Alan Bawden Cc: BUG-ITS@mit-mc.arpa, BUG-MAIL@mit-mc.arpa, BUG-RANDOM-PROGRAM@mit-mc.arpa, KS-ITS@mit-mc.arpa Subject: [JSOL: TELECOM] Consider this a warning. Phase-Of-The-Moon: LQ+2D.21H.36M.2S. In-Reply-To: Msg of 5 Jan 1986 15:26-EST from Alan Bawden Okay, now I know the intended audience for my message. One fact that I forgot to mention in the other message was that this JUST started happening about a week ago. Whoever is hacking COMSAT, please take note. Thanks, --JSol  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JAN 86 15:28:45 EST Date: Sun, 5 Jan 86 15:26:51 EST From: Alan Bawden Subject: [JSOL: TELECOM] Consider this a warning. To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].773515.860105.ALAN> MSG: *MSG 4866 Date: 01/05/86 13:22:00 From: JSOL at XX.LCS.MIT.EDU To: *BBOARD at XX.LCS.MIT.EDU Re: TELECOM Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 13:21:49 EST Date: Sun 5 Jan 86 13:24:23-EST From: Jon Solomon Subject: TELECOM To: BBOARD@MC.LCS.MIT.EDU Message-ID: <12172857686.19.JSOL@XX.LCS.MIT.EDU> Due to the installation of a new mail system, I can no longer ship off TELECOM to MC. Since there are quite a large number of MC users on TELECOM, and considering the fact that this restriction might affect other digests, I am sending this message to your bulletin board rather than individually to MC users. I -believe- what he is refering to is the fact that digests tend to be large enough that they exceed COMSAT's pitifully small size limitation. I note that CSTACY claimed the lock for hacking COMSAT two weeks ago, hacked on it for an evening, and hasn't logged in since then. There are now about 130 BADREQ files on .MAIL2, many of them 2 weeks old. (I'm going to have to create .MAIL3 soon...) Warning: If the day ever comes that I feel that it is Up-To-Me- To-Do-Something about COMSAT (because of address space problems, lack of proper domain support, or whatever) I will simply advise everybody that ITS no longer supports mail for users or mail forwarding for the network and I will shut it off. I feel this day -rapidly- approaching. I don't see any competent programmers making the kind of necessary effort it is going to take to straighten out this mess. I am forwarding this message to a large audience in the hopes that somebody will get inspired, but I realize this is grasping at straws.  Date: Fri, 3 Jan 86 23:43:32 EST From: "Pandora B. Berman" Subject: tape code To: KS-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].9858.860103.CENT5> reloading files works.  Date: Mon, 30 Dec 85 17:13:20 EST From: Alan Bawden Subject: MC:KSHACK;* * ==> AI:KSHACK;* * To: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].9575.851230.ALAN> As part of the gradual move from MC to AI as the canonical home for all ITS sources, I just copied everything that lived on the KSHACK directory on MC to the KSHACK directory on AI. In the future all edits etc. should be done on AI. Duplicate copies remain on MC, but from now on they should be treated as just that: duplicates. Sources for ITS itself and the contents of the MC SYSENG directories will follow during the next few days. (Alas, this does mean that the day has arrived when we will have to start getting used to using MIDAS on a slower KS10...)  Received: from MIT-SPEECH by MIT-AI.ARPA via Chaosnet; 14 DEC 85 01:10:51 EST Date: Sat 14 Dec 85 01:09:37-EST From: John Wroclawski Subject: NSALV 191 To: alan@MIT-MC.ARPA cc: ks-its@MIT-AI.ARPA I wrote the magtape system boot code for the salvager (KSHACK;NSALV 191). -------  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 11 DEC 85 15:41:06 EST Received: from MIT-XX.ARPA by MIT-MC.ARPA 11 Dec 85 15:42:55 EST Date: Wed, 11 Dec 1985 15:40 EST Message-ID: From: Rob Austein To: "J. Noel Chiappa" Cc: ks-its@MIT-MC.ARPA Subject: 3 more of the little critters on the way In-reply-to: Msg of 11 Dec 1985 09:59-EST from "J. Noel Chiappa" We could also give them each a HAKMEM, except that then we'd have to explain it and I'm not sure that I want to inflict SFTWAR WARS on innocent normal humans....  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 11 DEC 85 14:47:20 EST Received: from MIT-XX.ARPA by MIT-MC.ARPA 11 Dec 85 14:38:51 EST Mail-From: JNC created at 11-Dec-85 09:59:41 Date: Wed 11 Dec 85 09:59:40-EST From: "J. Noel Chiappa" Subject: 3 more of the little critters on the way To: ks-its@MIT-AI.ARPA cc: JNC@MIT-XX.ARPA Message-ID: <12166266820.10.JNC@MIT-XX.ARPA> ReSent-Date: Wed 11 Dec 85 12:56:13-EST ReSent-From: "J. Noel Chiappa" ReSent-To: ks-its@MIT-MC.ARPA ReSent-Message-ID: <12166298960.10.JNC@MIT-XX.ARPA> For those of you that haven't heard, it's official: there are three of the critters on a loading dock at DEC with 'MIT' stamped on them. We are making arrangements to have them picked up. An unofficial list of what is on them is: 512K mem (although it might be 384K), 1 RP06 and 16 lines of DZ. Not great, but not terrible. Thanks are due to Dave Clark for blowing brownie points and writing a letter, our DEC salesman, Arnie Cohen, for launching this inside DEC, and especially Connie Davis in Large Systems Marketing at DEC, who bailed this thing out when it got stuck. I propose that we think up some offical gesture of thanks for these individuals; my idea was a suitably bogus looking scroll signed by collected ITS fanciers, along with a dinner or something. Any other ideas? Noel -------  Received: from MIT-SPEECH by MIT-AI.ARPA via Chaosnet; 26 NOV 85 16:45:57 EST Date: Tue 26 Nov 85 16:44:44-EST From: John Wroclawski Subject: more obsolete hardware To: ks-its@MIT-AI.ARPA cc: sollins@MIT-XX.ARPA One of the folks who helped with the first KS10 claims that the three new ones are packed and sitting on a shipping dock at DEC. -------  Received: from MIT-OZ by MIT-AI.ARPA via Chaosnet; 19 NOV 85 14:48:51 EST Date: 19 Nov 1985 14:47 EST (Tue) Message-ID: From: Bill Rozas Subject: dialups on AAI To: PGS@MIT-OZ Cc: ks-its@MIT-OZ In-reply-to: Msg of 19 Nov 1985 13:27-EST from PGS Hardware is not the only problem with AI dialups. AI does not currently support dialups, since the DZ driver does not detect hangup and does not do autobauding. I hope to have the code written relatively soon, so it is probably a good idea to start looking for hardware anyway.  Received: from MIT-OZ by MIT-AI.ARPA via Chaosnet; 19 NOV 85 13:29:04 EST Date: Tue, 19 Nov 1985 13:27 EST Message-ID: From: PGS@MIT-OZ To: ks-its@MIT-OZ I'd like to receive my mail on AI now that it's possible (it seems likely to be at least as reliable as any of the KLs), but the inconvenience of getting to it over a phone is too great. Maybe it's time to hit Winston for, say, 4 dialups for AI.  Date: Tue, 19 Nov 85 04:10:30 EST From: "Pandora B. Berman" Subject: backup To: KS-ITS%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].6832.851119.CENT> it is now safe to receive mail on MIT-AI.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 18 NOV 85 00:10:27 EST Date: Mon, 18 Nov 85 00:12:50 EST From: Alan Bawden Subject: Hey, its not that bad. To: KS-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].721938.851118.ALAN> True story: I was doing a Tags Search through the entire ITS sources looking for something. As my Emacs sucked in file after file and searched through them I had a moment to pause and reflect about the impending demise of MC. "Gee whiz," I thought to myself, "we sure are going to miss the amazing speed of the KL processor when MC goes away. Lord knows how long a big multi-file tags operation like this would take if I was using AI." Imagine my suprise when I discovered that I -was- using AI! (I was supduping from MC and forgot which Emacs I was using.) Granted I was all alone at the time, and the operation is probably I/O-bound anyway.  Received: from MIT-OZ by MIT-AI.ARPA via Chaosnet; 16 NOV 85 12:59:52 EST Date: 16 Nov 1985 12:59 EST (Sat) Message-ID: From: Bill Rozas To: John Wroclawski Cc: ks-its@MIT-AI.ARPA Subject: gosh In-reply-to: Msg of 16 Nov 1985 03:52-EST from John Wroclawski Hooray!  Received: from MIT-SPEECH by MIT-AI.ARPA via Chaosnet; 16 NOV 85 03:52:47 EST Date: Sat 16 Nov 85 03:52:54-EST From: John Wroclawski Subject: gosh To: ks-its@MIT-AI.ARPA AI has been backed up to tape. -------  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 16 NOV 85 02:40:00 EST Date: Sat, 16 Nov 85 02:42:26 EST From: "Pandora B. Berman" Subject: full dump logs To: TY@MIT-MC.ARPA cc: JPG@MIT-MC.ARPA, CENT@MIT-MC.ARPA, JTW@MIT-MC.ARPA, ALAN@MIT-MC.ARPA, "(FILE [kshack;ks-its mail])"@MIT-AI.ARPA Message-ID: <[MIT-MC.ARPA].720232.851116.CENT> there's something i don't know about how to deal with ITS full dumps. the dump log (in the wall file) appears to start a new full page for each tape, and add subsidiary pages as needed; e.g., if tape 2570 is the third tape listed in that wall file, and needs 5 pages off the dover to list all the files it contains, these pages are numbered 3, 3.1, 3.2, 3.3, and 3.4. so far, so good. however, you seem to have some way of breaking up enormous wall files (caused by doing large chunks of the full dump in a single day) into files that contain only about 5 tapes' worth of information. how do you do this -- do you run some teco command over the large files? when i did the last full dump of the old AI machine, i did it all in one day (a very long day) and the wall file was absolutely enormous; alan had to figure out a kludge to help me break it into chunks small enough for the dover to print. also, it looks like JTW will have the tape code up on the new AI machine kind of soon, so i will start dumping it kind of soon. i may have forgotten some of this stuff -- do you perchance have a file somewhere of instructions and hints on how to dump an ITS, that i could refresh my memory with? thx.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 10 NOV 85 14:08:14 EST Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 10 Nov 85 14:08:39 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2677950038311913@MIT-MULTICS.ARPA>; 10 Nov 1985 14:00:38 est Date: 10 Nov 85 07:02 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, ks-its@MIT-MC.ARPA, "Leigh L. Klotz" Subject: - Message-ID: <133658@QZCOM> In-Reply-To: <[MIT-MC.ARPA].711333.851108.KLOTZ> Twenex v4.2 wold run on the KS10 cpu. Do'nt be afraid that we will steal your (by dec promised) processors someone vispered that DEC has abt 50 of them somewhere. I actually only wanted to get one cpu, 3 was mentioned as a number big enough to have a system running for ever.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 8 NOV 85 14:22:37 EST Date: Fri, 8 Nov 85 14:23:11 EST From: "Leigh L. Klotz" To: KS-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].711333.851108.KLOTZ> Well, if they did give them our 2020's then they'll just have to run Twenex V3 on them, won't they?  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 8 NOV 85 06:55:10 EST Date: Fri, 8 Nov 85 06:55:47 EST From: "Pandora B. Berman" Subject: ks acquisition To: ks-its@MIT-AI.ARPA Message-ID: <[MIT-MC.ARPA].710938.851108.CENT> well, peter lothberg went out to DEC on wed. and sweet-talked them out of 3 KSs. lucky STACKEN -- i wish we could get machines that easily. which brought JNC to a horrible thought tonight, when i mentioned this had happened. noel is of the opinion that DEC physically trashed most of the KSs it used to have. suppose, he said, that peter's high mucky-muck friend gave him -our- promised KSs? that would be pretty awful....  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 7 NOV 85 19:29:47 EST Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 7 Nov 85 19:26:48 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 350315; Thu 7-Nov-85 19:26:50-EST Date: Thu, 7 Nov 85 19:25 EST From: David A. Moon Subject: Random hardware available To: John Wroclawski cc: ks-its-confusion%MIT-AI@MIT-MC.ARPA In-Reply-To: The message of 7 Nov 85 15:37-EST from John Wroclawski Message-ID: <851107192544.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu 7 Nov 85 15:37:38-EST From: John Wroclawski Anybody think we want any of this junk? TME11-BA: TE10W 45IPS 7-track tape, TMB11 controller, cabinet $2495 TMB11: $250 new, $175 used Random tape controller which can run a TU10W/TE10W/ whatever other old 7-track clunker we can find in the basement. I'd like to have a way to read MC backup tapes without having to send them to Sweden to be copied onto 9-track tape. Do you think somebody might spring for the $3000? It seems worth it (of course a 7-track tape drive that is software compatible with the existing 9-track drive would be better.) RP06-AA: disk. $895 RM03-AA: disk, which is rumoured to contain a massbus SMD $695 controller so we could throw out the drive and hook up some kind of large CDC winchester or a bunch of fuji 160Mb's or something and win. No comment.  Received: from MIT-SPEECH by MIT-AI.ARPA via Chaosnet; 7 NOV 85 15:39:56 EST Date: Thu 7 Nov 85 15:37:38-EST From: John Wroclawski Subject: Random hardware available To: ks-its-confusion@MIT-AI.ARPA Anybody think we want any of this junk? TME11-BA: TE10W 45IPS 7-track tape, TMB11 controller, cabinet $2495 TMB11: $250 new, $175 used Random tape controller which can run a TU10W/TE10W/ whatever other old 7-track clunker we can find in the basement. RP06-AA: disk. $895 RM03-AA: disk, which is rumoured to contain a massbus SMD $695 controller so we could throw out the drive and hook up some kind of large CDC winchester or a bunch of fuji 160Mb's or something and win. -------  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 6 NOV 85 05:48:44 EST Received: from eneevax.umd.edu by MIT-MC.ARPA 6 Nov 85 05:45:32 EST Received: by eneevax.umd.edu (5.9/4.7) id AA00903; Mon, 4 Nov 85 08:59:08 EST Date: Mon, 4 Nov 85 08:59:08 EST From: Douglas Humphrey Message-Id: <8511041359.AA00903@eneevax.umd.edu> To: Moon@SCRC-STONY-BROOK.ARPA, digex@MIT-MC.ARPA Subject: Re: Peter Lothberg Cc: ALAN@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA Wonderful ! I do hope that our favorite Chinese food joint here is back up by then (down for Kitchen work I think) but in any case I am sure that there are a number of people who would love to meet him here ! I may even have some parts that he needs for one of his systems I think. If he is there and there is anything that he needs in the way of parts for one of his KA10 systems, please have him send me mail warning me so that I can find it (not an easy task always) before he comes down here. Also, if he really is interested in coming down here, he should tell me when and where to meet him, and if there are any arrangements that I can help him with..... Doug Humphrey DEH @ ENEEVAX  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 3 NOV 85 16:23:08 EST Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 3 Nov 85 16:17:20 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 346889; Sun 3-Nov-85 16:18:00-EST Date: Sun, 3 Nov 85 16:17 EST From: David A. Moon Subject: Peter Lothberg To: Douglas Humphrey cc: ALAN@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA In-Reply-To: <8511031859.AA10769@eneevax.umd.edu> Message-ID: <851103161714.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 3 Nov 85 13:59:41 est From: Douglas Humphrey Too bad that I can not get up there to Boston to meet him. Anyone that is dragging a KI system from california to europe is someone that I want to meet ! Someone say hi to him for Doug Humphrey (DIGEX) in Washington D.C. I believe that he plans to drop by Washington to see you and your private computer museum in a few days.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 3 NOV 85 14:01:47 EST Received: from eneevax.umd.edu by MIT-MC.ARPA 3 Nov 85 13:59:08 EST Received: by eneevax.umd.edu (4.12/4.7) id AA10769; Sun, 3 Nov 85 13:59:41 est Date: Sun, 3 Nov 85 13:59:41 est From: Douglas Humphrey Message-Id: <8511031859.AA10769@eneevax.umd.edu> To: ALAN@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA Subject: Re: ML pager prints redux Too bad that I can not get up there to Boston to meet him. Anyone that is dragging a KI system from california to europe is someone that I want to meet ! Someone say hi to him for Doug Humphrey (DIGEX) in Washington D.C. !!!!! Thanks DOug  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 2 NOV 85 17:16:54 EST Date: Sat, 2 Nov 85 17:14:57 EST From: Alan Bawden Subject: ML pager prints redux To: KS-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 26 Oct 85 02:39:38 EDT from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].702665.851102.ALAN> Date: Sat, 26 Oct 85 02:39:38 EDT From: Pandora B. Berman Date: 24 Oct 85 18:07 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA I will come to US on friday 25, to UCI where we has got an KI system, wich i shall put in a container and send to Sweden. Is there a possibility to visit you and look over the prints for the ML pager? ... sure. we'd be delighted. of course, UCI is on the other coast, but boston is as good a place as any other to touch down on your way back... maybe we can narrow down the pager prints to the bits you really need (which for all i know may be anywhere from all of it to three tiny sections on separate pages which we might manage to crank out of the local office-sized copier). while you're here you can admire the PDP6 in the basement (no longer functional, alas) and other items of hysterical importance, get to flame with ITS hackers, eat hot chinese food and really good ice cream... please give us more info about exactly when you'll be here, how long, and so forth. will you need a place to stay? we can probably find you a bed if you want one. if you let us know when your flight will come in, someone will meet you at the airport. This fellow will be arriving in Boston tonight (Saturday), and will probably be around the Lab tonight for a couple of hours. (His flight gets to Logan at 9:41 pm.) When we talked to him on the phone we didn't find out how long he will be in this area, but I would guess that he certainly will be around Sunday.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 26 OCT 85 02:41:23 EDT Date: Sat, 26 Oct 85 02:39:38 EDT From: "Pandora B. Berman" Subject: ML pager prints redux To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: KS-ITS@MIT-MC.ARPA, Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, iglesias@UCI-ICSA.ARPA Message-ID: <[MIT-MC.ARPA].693500.851026.CENT> Date: 24 Oct 85 18:07 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Pandora B. Berman" Cc: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: FILE SYSTEM FUKT I will come to US on friday 25, to UCI where we has got an KI system, wich i shall put in a container and send to Sweden. Is there a possibility to visit you and look over the prints for the ML pager? If you answer this letter, pls send a copy to Mike Iglesias UCI-EDU, becouse i'm not sure if i will be able to read my mail in Sweden from the US. (Iglesias @ UCI-EDU) is the right adres. sure. we'd be delighted. of course, UCI is on the other coast, but boston is as good a place as any other to touch down on your way back... maybe we can narrow down the pager prints to the bits you really need (which for all i know may be anywhere from all of it to three tiny sections on separate pages which we might manage to crank out of the local office-sized copier). while you're here you can admire the PDP6 in the basement (no longer functional, alas) and other items of hysterical importance, get to flame with ITS hackers, eat hot chinese food and really good ice cream... please give us more info about exactly when you'll be here, how long, and so forth. will you need a place to stay? we can probably find you a bed if you want one. if you let us know when your flight will come in, someone will meet you at the airport. good phone #s for further contact: 617-492-7274 (my house, talk to anyone) 617-253-8843 (alan bawden's office) 617-577-7541 (dave moon's office)  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 4 OCT 85 16:02:42 EDT Received: from eneevax.umd.edu by MIT-MC.ARPA 4 Oct 85 15:44:07 EDT Received: by eneevax.umd.edu (4.12/4.7) id AA27268; Fri, 4 Oct 85 13:24:03 edt Date: Fri, 4 Oct 85 13:24:03 edt From: Douglas Humphrey Message-Id: <8510041724.AA27268@eneevax.umd.edu> To: ALAN@MIT-MC.ARPA, Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: KS for STACKEN? Cc: CENT@MIT-MC.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@MIT-MC.ARPA Would it be possible to receive a list of the devices that Tiny ITS will support/Does support ? As you mentioned to Peter Lothberg that there would be some changes needed for support of booting off of an RM03, the RM03 would be a lot nicer for me since I am running my machine in my apartment where there is a lot of single phase power (included in the rent) but there might be problems in getting 208/3Phase power, which the RP series of drives requires. Since I do not yet have a KS machine, it would be good to know what tapes and such I should spec. Thanks ! Doug DEH @ ENEEVAX P.S. Does anyone have any idea as to the memory that ITS needs, and the number of jobs (say, EMACS ) it can run at once ? Crazy question of the week: Has anyone actualy tried to run MACSYMA on it yet ?!?  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 4 OCT 85 16:02:42 EDT Received: from eneevax.umd.edu by MIT-MC.ARPA 4 Oct 85 15:44:07 EDT Received: by eneevax.umd.edu (4.12/4.7) id AA27268; Fri, 4 Oct 85 13:24:03 edt Date: Fri, 4 Oct 85 13:24:03 edt From: Douglas Humphrey Message-Id: <8510041724.AA27268@eneevax.umd.edu> To: ALAN@MIT-MC.ARPA, Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: KS for STACKEN? Cc: CENT@MIT-MC.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@MIT-MC.ARPA Would it be possible to receive a list of the devices that Tiny ITS will support/Does support ? As you mentioned to Peter Lothberg that there would be some changes needed for support of booting off of an RM03, the RM03 would be a lot nicer for me since I am running my machine in my apartment where there is a lot of single phase power (included in the rent) but there might be problems in getting 208/3Phase power, which the RP series of drives requires. Since I do not yet have a KS machine, it would be good to know what tapes and such I should spec. Thanks ! Doug DEH @ ENEEVAX P.S. Does anyone have any idea as to the memory that ITS needs, and the number of jobs (say, EMACS ) it can run at once ? Crazy question of the week: Has anyone actualy tried to run MACSYMA on it yet ?!?  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 3 OCT 85 23:19:53 EDT Date: Thu, 3 Oct 85 23:20:45 EDT From: Alan Bawden Subject: KS for STACKEN? To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: KS-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Message-ID: <[MIT-MC.ARPA].668186.851003.ALAN> Date: 27 Sep 85 02:31 +0100 From: Peter_Lothberg_STUPI at QZCOM Subject: copying the ML pager prints for STACKEN ... At DECUS europe i met some DEC oficials who asked if we was interested in a KS machine, as i understand they have a bunch somewhere. Whats the state of the KS-ITS project ? If I were you I would take it. The status is that our first KS has been running for months now and seems completely solid. We aren't exactly "done", since we have been lazy about getting around to supporting the tape drive so that we can do backups, but we anticipate that will be finished real soon now (right John?). There are some other things that we are working on that may or may not be relevant to whatever KS configuration you might get from DEC. Oh yeah, I still haven't done a couple of the microcode changes I promised, like support for 1-proceed and the JPC. There are apparently 3 more KS's coming to MIT sometime soon for us to play with, or so I have been led to believe. Making you something that you could use to boot up a running ITS on a KS would be totally easy. (Well, pretty easy. Like if you get RM03's rather than RP06's it might take an extra edit or two, but nothing major.) [ You know, the other day I was looking at some code in ITS that -knows- that no ITS machine could possibly be anywhere other than in the EDT/EST time-zone. I suppose if you get an ITS to run we will probably have to deal with that somehow... ]  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 2 OCT 85 16:54:36 EDT Received: from eneevax.umd.edu by MIT-MC.ARPA 2 Oct 85 15:33:22 EDT Received: by eneevax.umd.edu (4.12/4.7) id AA06451; Wed, 2 Oct 85 08:50:52 edt Date: Wed, 2 Oct 85 08:50:52 edt From: Douglas Humphrey Message-Id: <8510021250.AA06451@eneevax.umd.edu> To: Moon@SCRC-STONY-BROOK.ARPA, deh@ENEEVAX.ARPA Subject: Re: copying the ML pager prints for STACKEN Cc: CENT@MIT-MC.ARPA, GLR%MIT-OZ@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA Yow ! Stardust is big, huh? OK. I know where I can get a box that looks like an MH but has 4megwords in it, but they seem to want about $100K for it. Too much for me. I know where there are 2 KS10 systems available for $6K each. Each system has the following: KS10 CPU 256KW MOS MEMORY DZ11A 8 LINE EIA 2) RH11 MASSBUSS CONTROLLERS (one disk and one tape) I know its not as good a deal as DEC donating some to the cause, but if people are interested, contact me. I'd buy one my self, but I haven't the spare change.... Doug Humphrey DEH @ ENEEVAX DIGEX @ MIT-MC  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 2 OCT 85 02:03:56 EDT Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 2 Oct 85 01:54:33 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 324745; Tue 1-Oct-85 22:13:53-EDT Date: Tue, 1 Oct 85 22:12 EDT From: David A. Moon Subject: Re: copying the ML pager prints for STACKEN To: Douglas Humphrey cc: CENT@MIT-MC.ARPA, GLR%MIT-OZ@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA In-Reply-To: <8509241849.AA03687@eneevax.ARPA> Message-ID: <851001221220.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 24 Sep 85 14:49:28 edt From: Douglas Humphrey If the price is reasonable, I would be interested in a copy of the prints and any notes that might be available on implimenting the ITS paging system for my KA10. Also of great interest would be the stardust memory prints and such so that I could get rid of my old klunky MF10 core memory boxes. If you thought the MF10 was clunky...wait until you see the Stardust. I really don't think you would want to try to build one.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 28 SEP 85 15:33:30 EDT Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 28 Sep 85 13:47:52 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2674229776405104@MIT-MULTICS.ARPA>; 28 Sep 1985 13:36:16 edt Date: 27 Sep 85 02:31 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, ks-its@MIT-MC.ARPA, "Pandora B. Berman" Subject: copying the ML pager prints for STACKEN Message-ID: <124838@QZCOM> In-Reply-To: <[MIT-MC.ARPA].657097.850923.CENT> Wow, that was a lot of money, better be in the xerox business.. We have to think it ower, our intention is to have an 1985 design of a pager, housed in the cpu. But it wold have been nice to have the ML pager prints as a reference. Will come back with a definite answer as soon as possible. At DECUS europe i met some DEC oficials who asked if we was interested in a KS machine, as i understand they have a bunch somewhere. Whats the state of the KS-ITS project ?  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 24 SEP 85 14:49:32 EDT Received: from eneevax.ARPA by MIT-MC.ARPA 24 Sep 85 14:49:23 EDT Received: by eneevax.ARPA (4.12/4.7) id AA03687; Tue, 24 Sep 85 14:49:28 edt Date: Tue, 24 Sep 85 14:49:28 edt From: Douglas Humphrey Message-Id: <8509241849.AA03687@eneevax.ARPA> To: CENT@MIT-MC.ARPA, GLR%MIT-OZ@MIT-MC.ARPA Subject: Re: copying the ML pager prints for STACKEN Cc: KS-ITS@MIT-MC.ARPA If the price is reasonable, I would be interested in a copy of the prints and any notes that might be available on implimenting the ITS paging system for my KA10. Also of great interest would be the stardust memory prints and such so that I could get rid of my old klunky MF10 core memory boxes. Thanks Doug Humphrey DEH @ ENEEVAX DIGEX@MIT-MC  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 24 SEP 85 11:53:13 EDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 24 SEP 85 11:53:04 EDT Date: Tue, 24 Sep 1985 11:52 EDT Message-ID: From: Jerry Roylance To: "Pandora B. Berman" Cc: KS-ITS@MIT-MC.ARPA Subject: copying the ML pager prints for STACKEN In-reply-to: Msg of 23 Sep 1985 23:00-EDT from Pandora B. Berman That sounds completely crazy. You don't have 640 originals. Run the prints through the ozalid machine we have or pay to have Stones do it. Last I knew, the price was .50 a sheet.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 23 SEP 85 23:01:00 EDT Date: Mon, 23 Sep 85 23:00:40 EDT From: Pandora B. Berman Subject: copying the ML pager prints for STACKEN To: KS-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].657097.850923.CENT> i asked blythe (AI publications) to look into how to get the ML pager prints copied. they are somewhat grungy 17"x22" blueprints. this is her answer: Date: Fri, 20 Sep 1985 09:29 EDT To: CENT%MIT-OZ@MIT-MC.ARPA From: Blythe%MIT-OZ@MIT-MC.ARPA Subject: copies of drawings It looks like the cheapest place to have your set of drawings copied is EAGLE Graphics, 1 Broadway, Cambridge. They have a xerox machine that can take 17 X 22 size originals. (They will probably have to do the large drawing in two pieces) The estimated cost is $320.00 and they will take a purchase order. Let me know if you want me to take care of this. i must admit, $320 is a hunk of money. Swedish hackers, do you want these prints? if so, can you cough up all or part of this price? local hackers, if our friends in sweden would like these but can't put together that much money, are we willing to take up a collection to help fund this enterprise? STACKEN again, if you think the price for the whole collection is excessive but need copies of some of the prints, please let us know, so we can attempt to work out which ones you want.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 28 AUG 85 12:58:58 EDT Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 28 Aug 85 12:49:04 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 302671; Wed 28-Aug-85 12:48:39-EDT Date: Wed, 28 Aug 85 12:49 EDT From: David A. Moon Subject: ITS kit arrives To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: ks-its@MIT-MC.ARPA, Pandora B. Berman In-Reply-To: <120147@QZCOM> Message-ID: <850828124911.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 27 Aug 85 01:11 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA People from UPMAIL (Uppsala Univerity AI lab) who have a 2060 (kl10d/e) and 2 (or 3) LMI Lisp machines on Chaosnet asked me for a copy of the code, are there enough files on the tapes we received ?What file goes into the PDP11 and microcode? I think we left out most of the KL10 stuff to decrease the number of tapes. In any case, if they have a KL10 Model B (all machines sold in the last N years are Model B's, and I don't think current releases of Tops-20 run on Model A's), they would not be able to run ITS without doing substantial microcode work. MIT-MC is a Model A. That model has different microcode.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 28 AUG 85 09:20:14 EDT Received: from eneevax.ARPA by MIT-MC.ARPA 28 Aug 85 09:11:44 EDT Received: by eneevax.ARPA (4.12/4.7) id AA27525; Wed, 28 Aug 85 09:13:53 edt Date: Wed, 28 Aug 85 09:13:53 edt From: Douglas Humphrey Message-Id: <8508281313.AA27525@eneevax.ARPA> To: CENT@MIT-MC.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: ITS kit arrives Cc: KS-ITS@MIT-MC.ARPA Re : the swedish 10 system, if they are having some problems with parts for a KA or KI 10 system, they should send me a list of the parts they need. I am SWIMMING in flip chips, drawings, etc. for these systems. I might have what they need. Please try to make sure that they get this message. I have no idea what (if any) of the lists they are on. Doug Humphrey DEH @ ENEEVAX  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 28 AUG 85 02:29:29 EDT Date: Wed, 28 Aug 85 02:21:22 EDT From: Pandora B. Berman Subject: ITS kit arrives To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: KS-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].626137.850828.CENT> Date: 27 Aug 85 01:11 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, ks-its@MIT-MC.ARPA, "Pandora B. Berman" Subject: ITS kit arrives Status report from Sweden, The 7 trac TU10 is now working on the T10 KI system, we have read the documentation, and some pices of the monitor code. One tape (no6) contains some hard read errors, but it can be misaligment of our tape drive. if it turns out to be hopeless, let us know. one tape won't be a real hassle to redo. We have decided to make a new paging hardware design, it will probably be less work th trying to find all needed old flip-chips. a couple weeks ago, moon went over the old faded ML pager prints to darken the pencilled in bits. i should investigate getting these copied so we can ship you a set, at least for comparison. ....Have our letter arrived ? while i was on vacation last week, an MIT internal mail envelope arrived containing a letter to me and PHW, a couple of pamphlets in swedish, a check, a picture of a KA or something very like one... i'm not sure if PHW (Pat Winston) actually saw this packet, as it only has a date stamp from his secretary, but i was pretty impressed. what kind of terminal is on the table in the picture? i plan to wave the things in swedish in my father's direction; he's learned a fair amount to translate stuff on XC skiing and orienteering, so he might be able to read some of it.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 27 AUG 85 20:24:55 EDT Received: from eneevax.ARPA by MIT-MC.ARPA 27 Aug 85 20:17:10 EDT Received: by eneevax.ARPA (4.12/4.7) id AA21559; Tue, 27 Aug 85 20:18:55 edt Date: Tue, 27 Aug 85 20:18:55 edt From: Douglas Humphrey Message-Id: <8508280018.AA21559@eneevax.ARPA> To: JNC@MIT-XX.ARPA, ks-its@MIT-MC.ARPA Subject: Re: More of the little critters Cc: DClark@MIT-MULTICS.ARPA Not being closely associated with the MIT folks that have brought ITS up on the ks processor, I had not heard that there was an effort to get DEC to give the group more ks machines (I suppose that it should have been assumes that this would happen !). It would be a good thing. If DEC has unsold ks systems around that they are going to scrap, and someone has some problem with donating them, then how about someone who might be interested in buying one, but for a lower price than the normal commercial one ? I have a KA10 system down here that I run occaisionaly as a hobby, and I will upgrade to a KI as soon as I can figure out how to transport it to my apartment where all this madness takes place. I would MUCH rather get a KS10 based ITS running here, and then stick some dialups on it and make it available to the rather large Washington DC hacking community. There are a lot of ITS folks down here, and a local ITS would be a good thing. Who in DEC would I talk with to purchase 1 (only one ! I'm not interested in any more than that !) of the KS processors ? If this would get in the way of the donation process, forget I mentioned it. If it will save one more potential ITS system from getting scrapped for the gold, then count me in. Thanks Doug Humphrey DEH @ ENEEVAX  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 27 AUG 85 15:35:19 EDT Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 27 Aug 85 15:27:27 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2671471049831086@MIT-MULTICS.ARPA>; 27 Aug 1985 15:17:29 edt Date: 27 Aug 85 01:11 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, ks-its@MIT-MC.ARPA, "Pandora B. Berman" Subject: ITS kit arrives Message-ID: <120147@QZCOM> In-Reply-To: <[MIT-MC.ARPA].597631.850801.CENT> Status report from Sweden, The 7 trac TU10 is now working on the T10 KI system, we have read the documentation, and some pices of the monitor code. One tape (no6) contains some hard read errors, but it can be misaligment of our tape drive. We have decided to make a new paging hardware design, it will probably be less work th trying to find all needed old flip-chips. People from UPMAIL (Uppsala Univerity AI lab) who have a 2060 (kl10d/e) and 2 (or 3) LMI Lisp machines on Chaosnet asked me for a copy of the code, are there enough files on the tapes we received ?What file goes into the PDP11 and microcode? Have our letter arrived ?  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 27 AUG 85 13:59:22 EDT Received: from MIT-XX.ARPA by MIT-MC.ARPA 27 Aug 85 13:51:46 EDT Date: Tue 27 Aug 85 13:51:54-EDT From: "J. Noel Chiappa" Subject: More of the little critters To: ks-its@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA, DClark@MIT-MULTICS.ARPA I'm sending out this note at the request to Alan to let you all know the status of things on this front. For those of you who haven't heard, I have organised a campaign to get DEC to give MIT several more of the little critters. A letter was written asking for a donation of several of the machines to MIT (i.e. both LCS and AI); due to the time pressures involved (all of the remaining unsold KS's were about to be scrapped) I couldn't get a lot of big wheels to sign, but Dave Clark did agree to sign the letter and lend his name to the campaign. DEC did set aside and earmark several of the machines; more recently there has been activity inside DEC to justify giving the machines to MIT. The DEC salesman for MIT, Arnie Cohen (who has been a big help in all this) reported recently that things were looking very positive, although not yet definite; I'll let you know more as I hear it. If this comes through as I hope it will, it should mean the continued existence of working examples of ITS for a good while to come. Thanks are due to Arnie, Dave, and everyone who helped. Noel -------  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 1 AUG 85 22:18:27 EDT Date: Thu, 1 Aug 85 22:17:22 EDT From: Pandora B. Berman Subject: ITS kit arrives To: KS-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].597631.850801.CENT> Date: 31 Jul 85 13:32 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Pandora B. Berman" , "Priscilla Cobb" Cc: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Package to Sweden The package arrived today, 1k tnx! (Addressed to Per Lindberg et al.) Tommy  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 28 JUN 85 08:33:09 EDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 28 JUN 85 08:31:10 EDT Date: 28 Jun 1985 08:30 EDT (Fri) Message-ID: From: Priscilla Cobb To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: "Pandora B. Berman" , ks-its@MIT-MC.ARPA Subject: Package to Sweden In-reply-to: Msg of 28 Jun 85 00:26 +0100 from Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA Please send the check made payable to MIT to the following address: Artificial Intelligence Laboratory Fiscal Office - NE43-821 545 Technology Square Cambridge, Massachusetts 02139 USA Thank you.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 27 JUN 85 23:51:48 EDT Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 27 Jun 85 23:43:36 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2666220663734481@MIT-MULTICS.ARPA>; 27 Jun 1985 20:51:03 edt Date: 28 Jun 85 00:26 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Priscilla Cobb" Cc: "Pandora B. Berman" , ks-its@MIT-MC.ARPA, ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Package to Sweden Message-ID: <111023@QZCOM> In-Reply-To: <[MIT-MC.ARPA].557096.850626.CENT> Air fright charge of $89.47, Just inform me where to send the money, i will send a cheque with air mail to cover your costs.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 27 JUN 85 14:11:31 EDT Received: from MIT-HTVAX.ARPA by MIT-MC.ARPA 27 Jun 85 14:08:51 EST Received: from MIT-OZ by MIT-HTVAX (4.12/4.7) with CHAOS id AA19061; Thu, 27 Jun 85 12:18:06 edt Date: 27 Jun 1985 12:18 EDT (Thu) Message-Id: From: Priscilla Cobb To: "Pandora B. Berman" Cc: KS-ITS@MIT-MC.ARPA Subject: Package to Sweden Right after I sent the original message to you, Chick got back to me and said that the package consisted of tapes. I told him to send it immediately by air freight and charge 95333. So the package should have gone out on 06-25-85 and should be in Sweden by now. I'm sorry for the aggravation this may have caused. Thanks for getting back to me on it. Priscilla  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 26 JUN 85 21:57:15 EDT Date: Wed, 26 Jun 85 21:57:49 EDT From: Pandora B. Berman Subject: Package to Sweden To: Cobb@MIT-OZ cc: CENT@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].557096.850626.CENT> Date: 25 Jun 1985 14:08 EDT (Tue) To: Cent%MIT-OZ@MIT-MC.ARPA from: Cobb%MIT-OZ@MIT-MC.ARPA Subject: Package to Sweden Gerry Brown contacted Charles about the package you want shipped to Sweden. The air freight charge will be $89.47; the boat charge is something under $15.00, but it takes 6 weeks. Charles needs to know what you are sending. If it's business we can send it asap for you; if it's personal you may wish to reconsider the method of shipment to reduce your cost. I'm sorry that the AIL cannot assume the cost for a personal shipment. Please let me know how to proceed. Many thanks. It certainly isn't personal. The package contains a basic ITS kit; some people at Stockholm University decided that ITS would be the best system to run on some PDP-10s they have acquired, and we are the only place they can get it. They may be able to reimburse us for the tapes and the postage; I included instructions for how to do this. I would appreciate its being sent by air freight; they have had to wait for some time while we figured out exactly which files to send them and rooted around for various obscure but necessary pieces of documentation. If there are any further problems with this, please let me know.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 25 JUN 85 01:53:48 EDT Date: Tue, 25 Jun 85 01:50:24 EDT From: David A. Moon Sender: CENT@MIT-MC.ARPA Subject: Addition to mailing list To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: BUG-ITS@MIT-MC.ARPA, ks-its@MIT-AI.ARPA Message-ID: <[MIT-MC.ARPA].554803.850625.CENT> Date: 23 Jun 85 20:11 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Everybody here is waiting for the system to run, all of the hackers in Stockholm that have heard of ITS is lyric. I have started the work on planing howto actualy change the KA hardware, i want to have the posibility to run as much of the DEC diagnostics as possible. So some type of switch-selectable aproach is prefered, but it is no simple. In a month or so we shall try to have the two KI-10 Cpu:s running SMP with T10 7.02. We plan to use this system to assemble the ITS code. ( Are you sure you can deal with that volume of mail? I don't think anyone will mind your being on them if you don't mind. ) Pls try to add: ITS_bugs%QZCOM.MAILNET@MIT-MULTICS.ARPA in both ITS bugs and ITS on ks20. I have done so. Will report as soon there is any sucsess. We eagerly await your report. The box of tapes, processor prints, and documentation is sitting right next to me, thanks to a lot of work by Penny Berman.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 21 JUN 85 22:47:55 EDT Date: Fri, 21 Jun 85 22:46:31 EDT From: Pandora B. Berman Subject: gentlemen, start your engines... To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: KS-ITS@MIT-MC.ARPA, Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA Message-ID: <[MIT-MC.ARPA].552290.850621.CENT> sorry for the extensive and continual delays. after some negotiation we came up with a set of directories that you really need for ITS, and i dumped them to tape. as soon as Moon writes or otherwise digs up a halfpage document on the ITS tape format, and i gather some other hardcopy doc, we will send you the box. this should happen by next week sometime. is the address you mentioned a while back (QZ, Stockholm U. Comp. Center) still correct? you may need a second care package later, but these should get you started. if you have questions, ask.  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 14 JUN 85 03:50:50 EDT Date: Fri, 14 Jun 85 03:51:20 EDT From: David Vinayak Wallace Subject: Does AI need a friend, or what? To: ALAN@MIT-MC.ARPA cc: KS-ITS@MIT-MC.ARPA, JTW@MIT-SPEECH In-reply-to: Msg of Wed 12 Jun 85 01:29:51 EDT from Alan Bawden Message-ID: <[MIT-MC.ARPA].542262.850614.GUMBY> Physically, there is room, what with ML, etc gone and the time-honoured rule about once you've put a computer there nobody will bother to move it... But I don't know about bucks. Perhaps we can promise to pay them at some future date? I find it HIGHLY unlikely that dec would try to repossess them! And anyway, if we ran short of room, I doubt anyone would notice were we to surreptitiously drop 10 or 15 of the unused paperweights (oops..I mean vaxes) off the tenth floor...  Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 12 JUN 85 01:29:50 EDT Date: Wed, 12 Jun 85 01:29:51 EDT From: Alan Bawden Subject: Does AI need a friend, or what? To: JTW@MIT-SPEECH cc: KS-ITS@MIT-MC.ARPA In-reply-to: Msg of Mon 10 Jun 85 18:30:38-EDT from John Wroclawski Message-ID: <[MIT-MC.ARPA].539599.850612.ALAN> Well, here is how I see things. If somebody else had the spare enthusiasm to figure out how to arrange things physically and financially for more of these toys to walk in the door, I wouldn't object. But the enthusiasm has to come from someone else. There is no point in having more of them if the energy has to come out of me. I'm spread thin enough as it is. I confess that I find the picture of a corral of happy little 2020's all running ITS somewhat heart-warming, but I fear it just isn't to be. Unless someone -else- has a bright idea. ( "I know! We can put on a show!" "Yeah! We can use my dad's barn!" )  Received: from MIT-SPEECH by MIT-AI via Chaosnet; 10 JUN 85 18:31:29 EDT Date: Mon 10 Jun 85 18:30:38-EDT From: John Wroclawski Subject: Does AI need a friend, or what? To: ks-its@MIT-AI DEC has decided to scrap all of their remaining KS10's by the end of this month. After that, it will be damn near impossible for us to get another one in any reasonable way. The current situation is that we can probably get reasonable machines (new condition, OK configuration) for about $10K per machine. It does not look like we can get another free one. Getting them for $10K is going to take a little effort, as it is. If anybody thinks they want one (or more) of these things we had better figure out how to do it extraordinarily fast. Far as I can tell early next week is about the latest we could decide we want one and still win. This doesn't mean we have to write a PO by then, but we probably have to say we'll do it soon. So what does everybody think? -john -------  Received: from MIT-OZ by MIT-AI via Chaosnet; 27 MAY 85 03:56:19 EDT Received: from MIT-XX by MIT-OZ via Chaosnet; 27 May 85 03:46-EDT Date: Mon 27 May 85 03:47:37-EDT From: Gordon Strong Subject: [Tom Blinn : DEC-10 hardware for free to a good home..] To: ks-its@MIT-OZ I don't know if this message has been forwarded to y'all yet, so.... --------------- Return-Path: <@SU-SCORE.ARPA:BLINN@DEC-MARLBORO.ARPA> Received: from SU-SCORE.ARPA by MIT-XX.ARPA with TCP; Thu 23 May 85 09:42:04-EDT Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 23 May 85 05:24:20-PDT Date: 23 May 1985 0818-EDT From: Tom Blinn To: tops-20 at SU-SCORE Subject: DEC-10 hardware for free to a good home.. Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12113284321.15.275.22947 at DEC-MARLBORO> Received from INFO-CPM, seems more likely someone on this list might know someone who might be interested.. Tom - - - - - - - Begin message from: "Webb Mike"@LLL-MFE.ARPA Return-Path: Received: from AMSAA by DEC-MARLBORO.ARPA with TCP; Tue 21 May 85 14:15:14-EDT Received: from lll-mfe.arpa by AMSAA.ARPA id a025728; 21 May 85 13:06 EDT Date: Tue, 21 May 85 09:52 PDT From: "Webb Mike"@LLL-MFE.ARPA Subject: dec-10 equipment To: info-cpm@AMSAA.ARPA one of my ex-customers(they just un-plugged it!) has some DECSystem-10 hardware they would like to get rid of. This is OLD stuff and it can be had for the cost of shipping. the following is a list of the stuff that is available: 2ea DF10C 22-bit data channel 3ea RH10 Massbuss Interface(use with above) 4ea MG10 128 k-36 bit core memory boxes 10-12 rp04 Disk drives. these have NO PORT MODULES. All of this equipment was on contract with DEC untill it was turned off and was in good working order. if there is a site out there,or if you know of someone who would like this equipment,please mail me your address and phone number, and i will put you in touch with the proper people. hope this doesn't violate some un-spoken rule on advertising on the net,but then it is "FREE TO A GOOD HOME"! Mike Webb, WEBB@LLL-MFE.ARPA - - - - - - - End forwarded message -------- -------  Received: from MIT-MC by MIT-AI via Chaosnet; 25 MAY 85 21:32:50 EDT Date: Fri, 24 May 85 23:35:37 EST From: Pandora B. Berman Subject: forwarding...KL for sale To: KS-ITS@MIT-MC, ITS-LOVERS@MIT-MC Message-ID: <[MIT-MC].517858.850524.CENT> Date: Thu 23 May 85 09:04:21-EDT From: Richard Lai Subject: Thought this might amuse you To: cent@MIT-MC Path: mit-vax!mit-eddie!genrad!panda!talcott!harvard!seismo!cmcl2!philabs!linus!utzoo!lsuc!utcs!corot From: corot@utcs.UUCP (Corot Reason) Newsgroups: na.forsale Subject: DEC-10 for sale Date: 13 May 85 18:05:31 GMT Organization: University of Toronto - General Purpose UNIX We have a complete DECsystem-1090 (TOPS-10 only) system for sale. Buy part or all of it. CPU is KL10 model "B" suitable as an additional processor in an SMP configuration. For details please contact Eugene Siciunas, Associate Director, University of Toronto Computing Services. (416)-978-5058. Availability: Late July, 1985. System components include: (This is not the complete list) KL10D cpu 3xRH20 internal channels 5xRP06 disk drives 4xMF10 multiport memory (4x64kw) 1xMH10 multiport memory (256kw) 2xTU45 tape drive 800/1600 1xTM02 tape controller 2xDN87 front ends (PDP-11/45) 1xDL10 unibus to memory bus multiplexor Some of this hardware would make a nice addition to a Computer Museum.  Received: from MIT-MC by MIT-AI via Chaosnet; 20 MAY 85 09:36:11 EDT Date: Mon, 20 May 85 09:32:04 EST From: Alan Bawden Subject: Now Playing In A Theater Near You! To: KS-ITS@MIT-MC Message-ID: <[MIT-MC].511014.850520.ALAN> There are now moderately detailed instructions taped to the side of AI explaining just how to recover from the most common crashes.  Received: from MIT-MC by MIT-AI via Chaosnet; 19 MAY 85 00:59:53 EDT Date: Sun, 19 May 85 00:58:43 EST From: David Vinayak Wallace Subject: [phr%ucbernie: forwarded] To: KS-ITS@MIT-MC Message-ID: <[MIT-MC].509961.850519.GUMBY> Date: Sat, 18 May 85 20:48:18 pdt From: phr%ucbernie at Berkeley (Paul Rubin) To: devon, gumby, marty at mit-htvax Somebody in Toronto is trying to sell an old 1090, no price was given. System includes KL10D cpu, 3 RH20 channels, 5 RP06's, 4 MF10 and 1 MH10 memory (512kw total), 2 TU45's 2 DN87 (pdp-11/45 front ends), etc. Call 416-978-5058 for more info if interested. paul  Received: from MIT-MC by MIT-AI via Chaosnet; 14 MAY 85 22:54:11 EDT Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 14 May 85 22:45:06 EST Received: from TENEX.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 236788; Tue 14-May-85 22:38:43-EDT Date: Tuesday, 14 May 1985 22:45-EDT From: MOON at SCRC-TENEX To: ITS_on_KATIA%QZCOM.MAILNET%MIT-MULTICS at Stony-Brook Cc: ks-its%MIT-MC at Stony-Brook Subject: Questions about KA10 pager In-reply-to: The message of 08 May 85 22:51 +0100 from Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA One more point. This 1970 paging box was a separate bay, standing next to bay 1 of the KA (except on the AI machine where it stood next to bay 3 for some reason), containing about half a dozen wire wrap boards of TTL plus two DEC flip-chip racks full of Systems Concepts DEC<->TTL level converters and cable connectors. From the 1985 standpoint, that seems like a real waste. If I were doing it today, I would try to design something using today's TTL parts, packaged on double-height flip-chip modules, that would fit in the space where the relocate/protect logic goes that would do the whole job and wouldn't require level convertors. I'd probably try to use that TI 512-entry cache-directory chip, since with 256 system pages plus 256 user pages it would fit nicely. That would be easier and more elegant since you wouldn't need to change the cabling at all. Of course there are still the various internal changes to the processor logic, which would be done by re-wire-wrapping the backplane and adding standard B-series flip-chip modules where necessary (there is probably enough spare space since that is how it was done at MIT). If your 1985-technology paging box didn't turn out 100% software compatible with the 1970-technology one, there is no harm done since ITS is already software compatible with three paging boxes and a fourth can be added as long as it only differs in detail and not in function (the bit layout of page table words, the exact way page faults are reported, the instructions to control the paging box, the size and organization of the associative memory could all be changed).  Received: from MIT-MC by MIT-AI via Chaosnet; 14 MAY 85 22:40:33 EDT Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 14 May 85 22:30:55 EST Received: from TENEX.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 236781; Tue 14-May-85 22:23:44-EDT Date: Tuesday, 14 May 1985 22:28-EDT From: MOON at SCRC-TENEX To: ITS_on_KATIA%QZCOM.MAILNET%MIT-MULTICS at Stony-Brook Cc: ks-its%MIT-MC at Stony-Brook Subject: Questions about KA10 pager In-reply-to: The message of 08 May 85 22:51 +0100 from Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Date: 08 May 85 22:51 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Message-ID: <103760@QZCOM> I'm the hardware projekt.... How wide is the adress bus output from the paging box? I think it varied on each KA10. In the original design, it was 19 bits (i.e. just one extra bit was added). Later a second extra bit was added to some copies. And I think that some sections(!) of the memory bus on some machines were later diddled to have 22-bit addressing compatible with the KI10 and KL10, but bits 14 and 15 were hard-wired to zero rather than coming out of the paging box associative memories. For further complexity, on one machine there was a pdp6 involved, which had its own idea of the meanings of some of the memory bus lines that DEC later recycled to be the extra address bits. I'd have to check the prints to be sure of the details, but the overall story is that there is no simple answer. If you build something, you can make it do whatever you want, rather than be exactly compatible with any one of the three copies of the KA10 paging box. The software really doesn't care; even the format of page-table entries is parameterized, since it has been different on every machine ITS has run on. Is the data chanel (DF10) a 18 or 22 adress bit device? Again, there isn't a simple answer. MIT-AI (the old one: the KA) didn't have any DF10's. It had a one-of-a-kind combined disk and serial-line controller, which was the only DMA device. If I remember correctly it was originally an 18-bit address device but was later expanded to 20 bits of address. The other devices that you would expect to be DMA (mag tape, dec tape, ARPA network, 340 display, maybe analog I/O) all worked by using the KA10's single-instruction interrupt handler feature. All our KA10's were modified to have an extra I/O bus cable which added seven additional interrupt levels, each with its own pair of interrupt instructions in locations 62-77. These were all at the same priority level as channel 1 in the standard interrupt levels (highest priority), hence this was called the "channel 1 multiplex feature." If I remember correctly the hardware for this was a single flip chip module (a custom module designed at MIT, not a standard DEC module) containing only a few parts. You might want to do this too, if you have a lot of I/O devices. MIT-AI also had a device, which was heavily used for many years although it never worked reliably, that mapped portions of the pdp10's address space into eight pdp-11 Unibuses. The pdp-11's in question (they weren't all real pdp-11's; one was a Lisp machine and one was a Chess machine) were scattered around the lab; some were I/O controllers for the pdp-10, while others were independent machines that just used this device as a high-speed link to the timesharing system. The effect of this hardware was to make pdp-11 memory look like extremely slow pdp-10 memory with the right-hand 4 bits of each word missing. A user program in the timesharing system could issue a system call to map an arbitrary portion of an arbitrary pdp-11's memory into its virtual address space and could then do whatever it wanted to it. These references were mapped through the usual virtual-to-physical page map and then again through a pdp-10-physical to pdp-11-physical page map located inside the 10/11 interface device. MIT-ML and MIT-DM (also KA's) had 18-bit DF10's with a special kludge modification (disabled with a toggle switch for running DEC diagnostics) to take extra address bits from the complement of some high-order bits of the count. The complementation is so that with a small count (which is negative) you address the low-order memory, for compatibility. I fear that idiots may have thrown away the documentation of this modification. MIT-MC (a KL) has 22-bit DF10's. MIT-AI (a KS) uses RH-11's in place of DF-10's! The software really doesn't care what kind of data channel you use as long as it can address all of memory somehow. If it isn't the same as any of the channels it already knows about a few instructions in several places would have to be changed. The existing page relocating and protection logic circuit is it used for any purpose, or is it just "shorted out" ? It's not used. If I remember correctly, it is actually removed and the space in the machine is used for something else. It's valuable space because it already has power wiring for TTL logic (I suppose you've discovered that here and there in the KA10 there is early TTL logic, with its power and ground offset from the DEC power and ground to make the logic levels compatible, since they are both voltage logics with the levels separated by approximately 3 volts). I'd have to check the prints to see what was put there. Incidentally, the way the interface between the processor and the paging box works is approximately as follows. The data portion of the memory bus simply connects to both of them. Data transfers between the two always go through memory (there is an instruction that reads eight words from memory and loads them into all the registers in the paging box, and another instruction that stores eight words into memory). The address portion of the memory bus leaves the processor with a virtual address on it and is received by the paging box. It maps the address and drives a second set of cables with the physical address; the processor doesn't know that it isn't talking directly to the memories. I forget who drives the control portion of the memory bus; I think the processor does, but the paging box controls what it drives? In addition to the memory bus, a large number of control and timing signals pass between the two boxes on several cables. A lot of the memory-subroutine pulses go back and forth, also instruction timing signals for the paging-box-manipulating instructions, and signals associated with page-fault reporting. The paging box does not connect to the I/O bus. Is the paging box use the existing "memory protection violation" interupt/status logic ? Sort of. If I remember correctly, there is a big mess of hand changes on the prints here. What it amounts to is that it uses the existing logic, but it has to fix a lot of bugs in it because DEC never intended for it to be possible to restart an instruction after a memory protection violation. Things I remember: the store-cycle timing pulses are rearranged to check for write access to the memory operand before modifying the accumulator; if a page fault is pending the check for interrupts is done earlier so there won't be a 1-instruction delay before the page-fault interrupt goes off; if a page fault is about to go off the store-cycle is inhibited from changing anything; the PC and PC flags are captured at the beginning of each instruction by a register in the paging box, so changes to them are allowed to go through; some bugs with MPV in BLT are fixed. I hope we can find an accurate KA10 print set with all the ITS modifications. There really was accurate documentation for each KA10 when we had the KA10s, but they're all gone now. I'm not in the right place to look, and I'm also not in the same place as my personal copy (which is not at all accurate). By the way, I wasn't present when all these modifications were designed and implemented. I know a good deal about them though, since I had to maintain them for several years.  Received: from MIT-MC by MIT-AI via Chaosnet; 13 MAY 85 01:44:45 EDT Date: Mon, 13 May 85 01:37:16 EST From: Alan Bawden Subject: For those you that remember. To: KS-ITS@MIT-MC Message-ID: <[MIT-MC].499959.850513.ALAN> TTY UNAME JNAME CORE TOTAL IDX T07 CENT MC 4 31 2 -> D17 XGP XGPSPL 48 56 14 FREE CORE 300 OUT 22 I don't know which of you clowns did this, but I got a chuckle out of it...  Received: from MIT-MC by MIT-AI via Chaosnet; 12 MAY 85 22:33:37 EDT Date: Sun, 12 May 85 22:27:36 EST From: David Vinayak Wallace Subject: [GJC: Vax/pdp-11 items for sale:] To: JTW@MIT-SPEECH cc: ALAN@MIT-MC, KS-ITS@MIT-MC In-reply-to: Msg of Sun 12 May 85 22:24:19-EDT from John Wroclawski Message-ID: <[MIT-MC].499605.850512.GUMBY> Perhaps we could use the DZ's?  Received: from MIT-MC by MIT-AI via Chaosnet; 12 MAY 85 22:29:18 EDT Received: from MIT-SPEECH by MIT-MC via Chaosnet; 12 MAY 85 22:23:29 EDT Date: Sun 12 May 85 22:24:19-EDT From: John Wroclawski Subject: Re: [GJC: Vax/pdp-11 items for sale:] To: ALAN@MIT-MC, KS-ITS@MIT-MC In-Reply-To: Message from "Alan Bawden " of Sun 12 May 85 22:07:46-EDT Really the only reason to buy an RM03 would be if it turned out to be much easier/cheaper to get a(nother) KS with no disk at all than with an RP06 or RM03 from DEC (since we have to have one DEC disk of some kind for field circus). I'll check, but I think not... -------  Received: from MIT-MC by MIT-AI via Chaosnet; 12 MAY 85 22:10:35 EDT Date: Sun, 12 May 85 22:04:17 EST From: Alan Bawden Subject: [GJC: Vax/pdp-11 items for sale:] To: KS-ITS@MIT-MC Message-ID: <[MIT-MC].499583.850512.ALAN> Date: 05/12/85 14:49:29 From: GJC To: *BBOARD Re: Vax/pdp-11 items for sale: Machine-Room Space-Crunch, must sell: * RM03 70MB removable disk drive. * 5 RM03 disk packs ... I suppose we could plug the RM03 into our MASSBUS... It would take a little programming effort to support it since it isn't quite the same as the RP06. I guess my opinion is that we are better off spending our time making some Eagles work.  Received: from MIT-MC by MIT-AI via Chaosnet; 11 MAY 85 17:55:00 EDT Date: Sat, 11 May 85 17:28:38 EST From: David Vinayak Wallace Subject: Nordic computing To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS cc: KS-ITS@MIT-MC In-reply-to: Msg of 08 May 85 13:19 +0100 from Per_Lindberg_QZ%QZCOM.MAILNET at MIT-MULTICS.ARPA Message-ID: <[MIT-MC].498167.850511.GUMBY> Date: 08 May 85 13:19 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET at MULTICS (At this moment we have 1 KI10, 1 KA10, 2 PDP11/35, 1 PDP12, and another KI10 and a PDP15 coming in (we hope)... It would be interesting to have ITS up on a dual-processor KI... Isn't the PDP-15 the weird frob with an analog line on the buss and analog i/o instructions?  Received: from MIT-MC by MIT-AI via Chaosnet; 11 MAY 85 14:17:45 EDT Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 11 May 85 14:13:26 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2662135592820494@MIT-MULTICS.ARPA>; 11 May 1985 14:06:32 edt Date: 08 May 85 22:51 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA, "David A. Moon" Cc: ks-its@MIT-MC.ARPA Subject: Subject: ITS tapes query Message-ID: <103760@QZCOM> In-Reply-To: <850507162231.1.MOON@EUPHRATES.SCRC.Symbolics.COM> I'm the hardware projekt.... How wide is the adress bus output from the paging box? Is the data chanel (DF10) a 18 or 22 adress bit device? The existing page relocating and protection logic circuit is it used for any purpose, or is it just "shorted out" ? Is the paging box use the existing "memory protection violation" interupt/status logic ?  Received: from MIT-MC by MIT-AI via Chaosnet; 11 MAY 85 14:17:40 EDT Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 11 May 85 14:13:10 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2662135551517557@MIT-MULTICS.ARPA>; 11 May 1985 14:05:51 edt Date: 08 May 85 13:19 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA, "David A. Moon" Cc: ks-its@MIT-MC.ARPA Subject: Subject: ITS tapes query Message-ID: <103713@QZCOM> In-Reply-To: <850507162231.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Thanks for the answer! OK, we can manage without the schematics for the paging box. We have a few very good hardware hackers who can build one from scratch. What we *can't* do is to write a new ITS (although some of our hackers might disagree...) so if we could get copies of your ITS tapes we'd be most grateful! Of course we'll cover the costs for tapes, postage and such. (At this moment we have 1 KI10, 1 KA10, 2 PDP11/35, 1 PDP12, and another KI10 and a PDP15 coming in (we hope) to "CCCC", (Colossal Cave Computing Center, our hobbyist/hackers machine room). Now all we need is a PDP6 to make our collection complete. If Anyone Out There... etc) Cheers, Per Lindberg  Received: from MIT-OZ by MIT-AI via Chaosnet; 10 MAY 85 03:23:24 EDT Date: Fri, 10 May 1985 03:20 EDT Message-ID: From: CENT.GGP@MIT-OZ To: "Pandora B. Berman" Cc: HUFF@MIT-AI, KS-ITS@MIT-AI, PETREW@MIT-AI Subject: about my terminal... In-reply-to: Msg of 10 May 1985 04:03-EDT from Pandora B. Berman such given gladly on demand.  Date: Fri, 10 May 85 03:03:29 EST From: Pandora B. Berman Subject: about my terminal... To: KS-ITS@MIT-AI cc: HUFF@MIT-AI, PETREW@MIT-AI Message-ID: <[MIT-AI].599.850510.CENT> thx, btw, to JNC for wiring advice, and to PETREW and my friend HUFF for actual labor.  Date: Fri, 10 May 85 02:55:05 EST From: Pandora B. Berman Subject: hardwired To: KS-ITS@MIT-AI Message-ID: <[MIT-AI].598.850510.CENT> make that -two- terminals on the DZ whatchamacallit. alan, could you convince it mine is a vt52? also, what do i edit to lock in my ttyloc?  Received: from MIT-MC by MIT-AI via Chaosnet; 9 MAY 85 21:03:23 EDT Date: Thu, 9 May 85 21:00:50 EST From: Alan Bawden Subject: unlocked To: JTW@MIT-SPEECH cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC In-reply-to: Msg of Thu 9 May 85 18:24:42-EDT from John Wroclawski Message-ID: <[MIT-MC].494266.850509.ALAN> Date: Thu 9 May 85 18:24:42-EDT From: John Wroclawski From: Alan Bawden Subject: Everything is locked I guess it is unlikely, but it would be foolish of anyone else to try to assemble and try anything that uses KS-10 I/O instructions.... Uh huh. Well, let me know when you think they work OK - I do hope to deal with the tape code sometime now that I'm back in town.. The I/O instructions work just fine. Last night we installed Jinx's DZ-11 code and it works too, so the path is clear for you.  Date: Tue, 7 May 85 17:10:52 EST From: Alan Bawden Subject: DAMN IT! To: KS-ITS@MIT-AI Message-ID: <[MIT-AI].497.850507.ALAN> Our losing DECWriter system console can get wedged in some kind of losing ^S/^Q lossage! Every time I type a character it sends a ^S immediately afterwards. May the designers of ASCII suffer eternally for their sins.  Received: from MIT-MC by MIT-AI via Chaosnet; 7 MAY 85 16:38:56 EDT Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 16:25:51 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232096; Tue 7-May-85 16:19:01-EDT Date: Tue, 7 May 85 16:22 EDT From: David A. Moon Subject: Subject: ITS tapes query To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: ks-its@MIT-MC.ARPA In-Reply-To: <103536@QZCOM> Message-ID: <850507162231.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 07 May 85 13:52 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Hello, is anybody listening? I am trying to reach David A. Moon with this mail (or anyone else who can help me with a set of tapes with ITS)! My name is Per Lindberg, and I'm writing this instead of Bjorn Danielsson, who has been communication with Moon on this subject. BD is busy doing other things right now. Well, you reached me, but I can't help you right away. We've really fallen down on the job of getting back to you. We heard that it is possible to get ITS on 7-track tapes on DEC core dump format. We can get access to a 7-track tape drive, so it's OK to send ITS dump tapes. We can read most formats given some hints on what's what. We'll take what you have. (If TECO and EMACS is on the tapes we'll be very happy!) If you want a couple of blank tapes in advance, just let me know how many and where to send them. Also, if anyone has the schematics for the KA10 paging box we'll be happy to get a copy of that. We have some hardware hackers that can build one. Last I heard what was holding things up is that somebody needs to go through these schematics and ink over the pencilled changes so that they can be copied. Then we need to find a place that can copy "D" size drawings. Do you want tapes in advance of this stuff? The tapes are relatively easy to send. Last time I wrote, we had a KI10 up and running, and a KA10 coming up. Now it's running, and the bottle of champagne is opened. Yay! (If anyone wants to get rid of a PDP-6, we'll be *very* grateful to get it!) We already got rid of ours I believe. You can send the tapes to my address at QZ: QZ, Stockholm U. Computing Center Box 27322 S-10254 Stockholm Sweden +-----------------------------------------------------------------------+ . '"""""` Per Lindberg, QZ, Box 27322, S-10254 Stockholm, SWEDEN ! . ! q p ! Phone: + 46 8 679280 ! .(! U !) JANet:Per_Lindberg_QZ%QZCOM@YORK ! . ! `-' ! MAILNET,BITNET:Per_Lindberg_QZ@QZCOM.MAILNET ! . `-----' CSnet,ARPAnet:Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA ! . usenet: ..mcvax!seismo!Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA ! . usenet: ..mcvax!enea!suadb!lindberg ! +-----------------------------------------------------------------------+ YOW!!  Received: from MIT-MC by MIT-AI via Chaosnet; 30 APR 85 01:25:56 EDT Date: Tue, 30 Apr 85 01:16:24 EDT From: Alan Bawden Subject: Oh yeah, right... To: GREN@MIT-MC cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC, BUG-DDT@MIT-MC Message-ID: <[MIT-MC].476201.850430.ALAN> [Message from GREN at MIT-AI 1:05pm] hey, single-stepping isn't working right! Oh yeah. Until I get back into microcode hacking again, hackers who debug programs using DDT on AI will find that features related to single stepping don't work right. I'll fix it eventually, I just haven't put in the support for it yet. I won't be fixing the fact that AI doesn't have a MAR, so somebody should be fixing DDT to know that some ITS machines lack the feature.  Date: Sat, 27 Apr 85 01:33:18 EST From: Pandora B. Berman Subject: test To: KS-ITS@MIT-AI Message-ID: <[MIT-AI].118.850427.CENT> ignore.  Received: from MIT-HTVAX.ARPA by MIT-MC.ARPA; 24 APR 85 16:46:29 EST Received: by MIT-HTVAX.ARPA (4.12/4.7) id AA08984; Wed, 24 Apr 85 16:26:18 est Message-Id: <8504242126.AA08984@MIT-HTVAX.ARPA> To: KS-ITS@mit-mc.ARPA Subject: Current Unibus settings of LH/DH-11 Date: 24 Apr 85 16:26:14 EST (Wed) From: Martin David Connor To make things easier, the current address and vector of the Arpanet Interface should be: acc0 at uba0 csr 167600 vec 250, ipl 15 This can of course be easily adjusted via the zippy-dip-switches on the board with the unibus interface. The picture in the documentation may seem to show the sense of the switches reversed.  Received: from MIT-OZ by MIT-MC via Chaosnet; 23 APR 85 11:04:04 EST Date: 23 Apr 1985 11:05 EST (Tue) Message-ID: From: Martin David Connor To: KS-ITS@MIT-MC Subject: Potentially interesting developements near AI There has appeared beside AI a rack containing on ACC LH/DH-11, (Arpanet Interface to you). Even more interesting, it has 3 cables routed from the back of it. One to power, One to just inside the processor cabinet, and one connected to port 2 of IMP 6 from whence MIT-AI once graced the network. Rumor has it that someone (possible known as CJL) has the technical documentation for this device. Judging from the sign on the front that reads "Hack me Please!" I would suspect that someone somewhere would like unibus code to interface with this device, which might have the interesting side-effect of putting MIT-AI on the Internet (ARPANET to you), once more. I leave it your conscience what happens next. Evidentally the poor device has grown wear of talking to Unix 4.2 vaxen, and longs for "the real thing". I will only say (and you may quote me) "Stranger things have happened!"  Received: from MIT-AI by MIT-MC via Chaosnet; 19 APR 85 22:39:59 EST Date: Fri,19 Apr 85 22:40:37 EST From: Alan Bawden Subject: Progress Report! To: KS-ITS@MIT-AI, INFO-ITS@MIT-AI Message-ID: <[MIT-AI].71.850419.ALAN> The MIT-AI KS10 has now been up and running timesharing for almost two days without incident. We are on the Chaosnet, we have COMSAT, EMACS, LISP, etc. all running just fine. We do not have tape drive support for backing up out filesystem yet, and our current filesystem is built on a scratch pack, so you can't put any files here that you care about, but basically we are winning completely. Interesting aside: It appears that for the last three years the Dover spooler on MC has been trying in vain to write the file AI:TEXLIB;TODAYS DATE. I'll bet it had a heart attack when it finally succeeded!  Date: Wed,17 Apr 85 17:19:39 EST From: Alan Bawden Subject: AI ITS 1514 To: KS-ITS@MIT-MC Message-ID: <[MIT-MC].458514.850417.ALAN> So today I typed ^Z on AI's system console and ITS started a job, loaded SYS:ATSIGN HACTRN which contained a program that opened the TTY: and did trivial terminal IO. Wow. Multi-processing and everything...  Date: Mon,15 Apr 85 20:15:26 EST From: Alan Bawden Subject: The DSKDMP operating system To: KS-ITS@MIT-MC Message-ID: <[MIT-MC].455959.850415.ALAN> This morning I formatted a disk pack as an ITS filesystem, created a magic file containing the bits the 8080 front-end needs to boot the machine, created a couple of other vital files like .;@ DDT and .;@ NSALV, endowed the pack with a copy of DSKDMP, and kissed the tape drive goodbye. Thats right, we have reached the point where it is no longer necessary to use magnetic tape to load code into the machine. Now when the machine is booted from scratch (like when you power cycle the machine, or give the BT command to the console program), it comes up in DSKDMP. From DSKDMP you can read in DDT and the salvager from disk and use the salvager to suck files over the Chaos net and write them on disk. Then if you pop back to DSKDMP you can load them up and start them. What fun!  Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Apr 85 17:49-EST Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 4 APR 85 17:48:40 EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209045; Thu 4-Apr-85 13:56:59-EST Return-path: <@MULTICS.MIT.EDU,@MULTICS.MIT.EDU:Per_Lindberg_QZ@QZCOM.MAILNET> Received: from MULTICS.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 208688; 4 Apr 85 05:13:42-EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2658910430111180@MIT-MULTICS.ARPA>; 04 Apr 1985 05:13:50 est Date: 03 Apr 85 23:28 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_on_KATIA%QZCOM.MAILNET@MIT-MULTICS.ARPA, "David A. Moon" Subject: ITS tapes Message-ID: <98804@QZCOM> Resent-To: ks-its@MIT-MC.ARPA Resent-From: Moon@SCRC-STONY-BROOK.ARPA Resent-Date: Thu, 4 Apr 85 13:58 EST Resent-Message-ID: <850404135824.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Resent-Comments: Should we create a KA-ITS mailing list? I guess we should get together a package of tapes and documentation for these guys. FOO.ITS -*- Text Fill -*- Hello, David! My name is Per Lindberg, and I'm writing this reply instead of Bjorn Danielsson, who is busy doing other things right now. Sure, we can find a 7-track tape drive, and read most formats given some hints on what's what. Just send the tapes! We'll take what you have. (I hope TECO and EMACS is on the tapes!) Also, if you have a copy of the schematics for the KA10 paging box we'll be happy to get a copy of that. We have some hardware hackers that can build one. As of this writing, the KA10 is running, and we're trying to load a small TOPS-10 system from tape or disk. (the disk was written on the KI10, which is also used for debugging the KA10 hardware.) A bottle of champagne is in the fridge... You can send the tapes to my address at QZ: QZ, Stockholm U. Comp. Center Box 27322 S-10254 Stockholm Sweden Received: from MIT-MC by MIT-OZ via Chaosnet; 16 Mar 85 18:18-EST Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 16 MAR 85 18:16:12 EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 198505; Sat 16-Mar-85 18:15:15-EST Date: Sat, 16 Mar 85 18:18 EST From: David A. Moon Subject: Joke of the day. To: Alan Bawden cc: KS-ITS@MIT-MC.ARPA In-Reply-To: The message of 15 Mar 85 02:48-EST from Alan Bawden Message-ID: <850316181826.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 15 March 1985 02:48-EST From: Alan Bawden Today I learned the hard way that it doesn't work to set a breakpoint (using exec DDT) on a location containing one of the kludgey KS10 IO instructions. If anybody would like to take a crack at fixing this I wouldn't mind. IXCT5: ... HRLZI 17,AC0 BLT 17,17 MOVEI T,@TEM DPB T,[(2700)TEM] If the goddamned I/O instructions would compute their effective address in the same way as all the other instructions, they would work. In the above code, TEM contains the instruction breakpointed, which needs to be executed in a special way when you proceed from the breakpoint. Received: from MIT-MC by MIT-OZ via Chaosnet; 15 Mar 85 02:48-EST Date: 15 March 1985 02:48-EST From: Alan Bawden Subject: Joke of the day. To: KS-ITS @ MIT-MC Today I learned the hard way that it doesn't work to set a breakpoint (using exec DDT) on a location containing one of the kludgey KS10 IO instructions. If anybody would like to take a crack at fixing this I wouldn't mind. (Current status: We have an empty filesystem sitting on a disk pack. We need to plunk a few vital files down into it and finish the disk driver code and then we can try typing our first ^Z.) Received: from MIT-SPEECH by MIT-OZ via Chaosnet; 15 Feb 85 16:51-EST Date: Fri 15 Feb 85 16:55:02-EST From: John Wroclawski Subject: Re: randomness To: PGS@MIT-OZ, ks-its@MIT-OZ In-Reply-To: Message from "Patrick G. Sobalvarro " of Fri 15 Feb 85 16:39:51-EST Gees, I haven't been there in ages. I should wander by and see what's up. I hear they're selling LM-2's at the state surplus place in Taunton. As a point of interest, DEC's current philosophy involves us giving them about $10K (well, they said $15K, but ...) for any further KS's from them. I don't know whether that will stick or not. ------- Mail-From: PGS created at 15-Feb-85 16:21:25 Date: Fri 15 Feb 85 16:21-EST From: Patrick G. Sobalvarro Subject: randomness To: ks-its@MIT-OZ I was just at Eli's. They have a KS-2020 there. I always feel bad when I go into Eli's and see them selling something we have one of. It makes me feel old. It makes me feel we're all old, and all our machines are old. When Eli's starts selling 3600s, I'm going to get out of this business. P.S. They wouldn't tell me how much they wanted for it. "Make us an offer," they said. Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 26 Jan 85 17:52-EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 166847; Sat 26-Jan-85 17:51:55-EST Date: Saturday, 26 January 1985, 17:51-EST From: David A. Moon Subject: meeting To: KS-ITS at MIT-OZ, "Spacy, when MC comes back up" cc: Alan at MIT-MC, AI-KS at MIT-MC In-Reply-To: Message-ID: <850126175114.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 25 Jan 1985 06:40 EST From: CCS@MIT-XX ....I tried running it in standalone on MC and it looks like I broke it a little bit, sigh. CHKR immediatly crashes in the INIT code. I didn't really change any of the KL-specific code, so it's probably some simple screw-up. I think someone else (Moon?) should take a quick look at it: it's probably a trivial bug or typo that I am familiarly reading past. This turned out to be bogus cache-handling code copied from the old salvager. Chris and I were able to demonstrate the old salvager crashing in exactly the same way. Fixed in the source by copying the right cache-handling code from ITS; I forget whether we tested the fix. Things on my mind for the meeting are: How do we get file system on the KS? We decided to copy the key files over the Chaosnet using a new program in the salvager, then after timesharing runs get other files over the network under timesharing using FTP or CFTP. I wrote and debugged the Chaosnet driver part of the salvager for this (it needs a little more work on error handling I guess, but basically seems to work). Is there an 8080 file system? What is it? I think we figured this out last night. Chris, you're going to write the routine in the salvager that allocates space for this, fills in the physical disk addresses in the home blocks and table-of-pointers block, and makes an ITS file on the . directory that owns the space occupied by the 8080 file system, right? DSKDMP? 8080 changes? SHUT command and sw0? (BTW, what about KLINK?) Good questions. I think the only thing we decided is the part of ITS that looks at the switch register and goes to DDT would instead look at location 30 (set by the 8080 SH command). DSKDMP should be trivial to get running on the KS, taking just the tty and disk routines from the salvager. Control your urge to barf when you see the code in DSKDMP, we don't care as long as it works. Strategy for ITS I/O programming, UNIBUS management, etc. Get Confuser info and protocol from Taft. Ethernet off confuser, Chaosnet off UBA#3? An ACC UNIBUS IMP interface? Need to hack tape code. I'd like to share as much code as possible between ITS and random programs. Disk, Tape? (Net?) Good questions. Received: from MIT-MC by MIT-OZ via Chaosnet; 26 Jan 85 02:47-EST Date: 26 January 1985 02:44-EST From: Christopher C. Stacy To: KS-ITS @ MIT-OZ Moon is writing a program to suck files from MC over the Chaosnet to the currently empty file system on the 2020. MC ITS 1487 Peek 586 1/26/85 02:41:22 Up time = 4:20:35 Idx Usr Uname Jname State Ibf Pbf Nos Ack R Win T Foreign Addr Flag 53 11 45TLNT TELSER OPEN 0 0 1 0 5 1 NE437B 152402 T 25 53 53TLNT TELSER OPEN 0 0 13 0 5 13 JIMI 2366 T 7 26 ___026 CHAOS OPEN 0 0 1 0 1 1 MIT-AI 6 16 buffers, 13 of which are free. Received: from MIT-MC by MIT-OZ via Chaosnet; 26 Jan 85 01:49-EST Date: 26 January 1985 01:43-EST From: Christopher C. Stacy Subject: KS10 AI To: KS-ITS @ MIT-OZ cc: BUDD @ MIT-MC In-reply-to: Msg of 26 Jan 1985 01:25-EST from Philip Budne Date: 26 January 1985 01:25-EST From: Philip Budne To: ALAN, CSTACY Re: KS10 AI Anything new and exciting with the KS? I've been watching the KSHACK; directory noticed recent activity on the RH11 driver. Is the uCode stable? Does NTSDDT run? Could you post a report to the AI-KL list ? Thanks!! The microcode and DDT have been running for a long time, and recently the Salvager started working. We are working on putting a file system on the machine, and writing ITS device drivers in preperation for initial debugging of ITS itself. Received: from MIT-MC by MIT-OZ via Chaosnet; 27 Nov 84 01:14-EST Date: 27 November 1984 01:09-EST From: Alan Bawden Subject: Progress report To: BUDD @ MIT-MC, KS-ITS @ MIT-MC cc: INFO-ITS @ MIT-MC In-reply-to: Msg of 21 Nov 1984 20:24-EST from Philip Budne Date: 21 November 1984 20:24-EST From: Philip Budne Re: AI (the KS10) What is the current state of thew new AI? I have been watching [OZ]ARC:AI-KL, but the has been no news for a month! Yeah, I guess I haven't said anything recently. My last message was to announce that I got the microcode support working? Since then I have been working on conditionalizing all those places that are sensitive to the specifics of the processor. I guess this task is somewhat easier than it was when ITS was conditionalized for the KL, because most of the processor dependencies are already known; a string search for "KL10P" sufficed to find most of them. I guess I could declare this task complete now (modulo debugging), all that really remains is to write TTY routines for talking to the system console through the 8080. (They are trivial, I almost finished them tonight.) Next I get to learn how to interface to a bunch of random devices: the DZ11 terminals, the disk, and the tape drive. All that stands between us and a first try at bringing ITS up are disk routines in ITS, disk routines in the salvager, and a trivial tape reading routine in the salvager so that we can put a couple of things in the initial filesystem. I guess I made a bunch of decisions along the way that ITS hackers might be interested in, but not really much that the typical machine language programmer will need to know about. The protocol for one-proceed will be different, but that remains unimplemented. There will be a JPC, but that hasn't been done either. There will never be a MAR. There is a new user interrupt (%PINXI) that will be given to jobs in .IOTLSR mode that touch Unibus locations with nothing in them. The protocol for setting the time is new, so someone need to modify PDSET or supply a new equivalent program. Oh yeah, I also fixed a couple of problems with "Exec DDT" and the magtape bootstrap program in the course of experimenting with the machine. There still remains a bunch of things to do to make the machine ultimately useable. Things like network code. Code to interface to Taft's "Format Confuser". The Format Confuser itself. Code for booting the machine from the disk. Code for frobbing the 8080 filesystem. Etc. Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Oct 84 18:39-EDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 113864; Tue 23-Oct-84 20:30:36-EDT Date: Tue, 23 Oct 84 20:30 EDT From: "David A. Moon" Subject: RDIO 2,100000 To: Alan Bawden cc: CSTACY@MIT-MC.ARPA, KS-ITS@MIT-MC.ARPA, BUG-DDT@MIT-MC.ARPA In-Reply-To: The message of 23 Oct 84 00:28-EDT from Alan Bawden Message-ID: <841023203030.9.MOON@EUPHRATES.SCRC.Symbolics> Date: 23 October 1984 00:28-EDT From: Alan Bawden Barf. I was faked out today by DDT not understanding how to assemble typed in KS IO instructions properly. The random kludges necessary to get the traditional IO instructions to type in correctly (like "CONI 4," which does not put the 4 in the same place as "MOVE 4," does) manage to screw the new RDIO/WRIO instructions. Apparently DDT just checks for ones in the top three bits of the opcode to determine that it should do the kludge. The effect is really confusing if you don't know whats going on: you type "RDIO 2,100000" and the answer appears in AC 4. Perhaps somebody else on KS-ITS who wants to help us out would be willing to stomp out this buglet? Timesharing DDT has the same bug almost. It masks out the low two bits of the AC field before putting it in the wrong place. MIDAS does the right thing by making the kludge a property of the symbol rather than a property of its value. I believe that the right way to fix this is to check whether bits 0-8 of the word are equal to 700 when storing the AC field. If they are, it's an old-type I/O instruction and the AC number is really a device number and needs to be shifted. If they aren't, it's a normal instruction and the AC field is an AC field. Probably DDT currently checks bits 0-2 instead, but that's wrong. Received: from MIT-MC by MIT-OZ via Chaosnet; 23 Oct 84 00:27-EDT Date: 23 October 1984 00:28-EDT From: Alan Bawden Subject: RDIO 2,100000 To: CSTACY @ MIT-MC cc: KS-ITS @ MIT-MC, BUG-DDT @ MIT-MC Barf. I was faked out today by DDT not understanding how to assemble typed in KS IO instructions properly. The random kludges necessary to get the traditional IO instructions to type in correctly (like "CONI 4," which does not put the 4 in the same place as "MOVE 4," does) manage to screw the new RDIO/WRIO instructions. Apparently DDT just checks for ones in the top three bits of the opcode to determine that it should do the kludge. The effect is really confusing if you don't know whats going on: you type "RDIO 2,100000" and the answer appears in AC 4. Perhaps somebody else on KS-ITS who wants to help us out would be willing to stomp out this buglet? Timesharing DDT has the same bug almost. It masks out the low two bits of the AC field before putting it in the wrong place. MIDAS does the right thing by making the kludge a property of the symbol rather than a property of its value. Received: from MIT-MC by MIT-OZ via Chaosnet; 9 Oct 84 16:47-EDT Date: 9 October 1984 16:47-EDT From: Alan Bawden To: KS-ITS @ MIT-MC Actually, using MC:SYSTEM;EPT is a bad idea because it contains about 75% KL-only definitions. I moved the relevant stuff into KSDEFS. Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Oct 84 19:31-EDT Date: 8 October 1984 19:29-EDT From: Alan Bawden Subject: We'll get there soon. To: KS-ITS @ MIT-MC OK, MC:KSHACK;KSDEFS and MC:SYSTEM;EPT now document the behavior of the ITS microcode for the KS as it will remain for the indefinite future. Things like the JPC, one proceed, and some of the IO instruction and interrupt ideas in MC:MOON;KSJOBS can wait until we have ITS itself more together. A couple macros should make any later switch to new IO instructions painless. (I'll add such macros to KSDEFS.) Tomorrow I will make sure my last twiddles to the microcode really were harmless and install it in the canonical place. (Which is MC:KSHACK;GOOD RAM.) Speaking of features like the JPC and one proceed, here is some bad news for all you machine language hackers. This machine is unlikely to ever have a working MAR. Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Oct 84 19:15-EDT Date: 7 October 1984 19:14-EDT From: Alan Bawden To: KS-ITS @ MIT-OZ Hey guys, this paging microcode seems to work! I have a few trivial tweeks to make to it before it is 100% finished, but its time for me to start thinking about what to do next on this project. Received: from MIT-MC by MIT-OZ via Chaosnet; 27 Jun 84 22:31-EDT Date: 27 June 1984 22:31-EDT From: Alan Bawden Subject: Arrival. To: AI-ITS @ MIT-OZ Date: 27 June 1984 09:52-EDT From: J. Noel Chiappa Re: MIT-AI (sub 2) arrives! Wooooooo Shit! On the very loading dock at 545TS there is a monster moving van unloading a large collection of large boxes manifested to one M. Roylance, Esq. The THING seems to be here... They are sticking it inside Receiving since there doesn't seem to be a space ready for it on 9. Mail-From: DROGERS created at 6-Jun-84 23:33:39 Date: Wed 6 Jun 84 23:33:39-EDT From: David Rogers Subject: Rah rah 36 bits! To: AI-KL@MIT-OZ Date: Fri 1 Jun 84 15:17:06-PDT From: Mark Crispin Subject: Stanford University News Service press release [Forwarded from the Stanford bboard by CC.Clive@UTEXAS-20.] [Forwarded from the UTexas-20 bboard by CMP.Werner@UTEXAS-20.] STANFORD UNIVERSITY NEWS SERVICE STANFORD, CALIFORNIA 94305 (415) 497-2558 FOR INFORMATION CONTACT: Joel Shurkin FOR IMMEDIATE RELEASE STANFORD COMMISSIONS COMPUTER TO REPLACE LARGE DEC-20'S. STANFORD-- Stanford University is negotiating with a small Silicon Valley company to build large computers to replace the ubiquitous DECSYSTEM-20s now ``orphaned'' by their manufacturer, Digital Equipment Corp. (DEC). The proposed contract, which would total around $1.4 million, would commision two machines from Foonly Inc. of Mountain View for delivery early in 1986. Foonly is owned by former Stanford student David Poole. According to Len Bosack, director of the Computer Science Department's Computer Facilities, the Foonly F1B computer system is about four times faster than the DEC model 2060 and 10 times faster when doing floating-point computations (where the decimal point need not be in the same place in each of the numbers calculated) that are characteristic of large-scale engineering and scientific problems. Ralph Gorin, director of Stanford's Low Overhead Time Sharing (LOTS) Facility -- the academic computer center -- said the Foonly F1B system, which is totally compatible with the DEC-20, is an outgrowth of design work done by Poole and others while at the Stanford Artificial Intelligence Laboratory. Since 1977, Foonly has built one large system, the F1, and several dozen smaller systems. The Foonly F1B is a descendant of the original F1, with changes reflecting advances in integrated circuit technology and the architectural refinements (internal design) of the latest DEC-20s. A spokesman for DEC said the company announced last year it had discontinued work on a successor to the DEC-20, code named ``Jupiter,'' and would continue to sell enhanced versions of the large mainframe. Service on the machines was promised for the next ten years. However, said Sandra Lerner, director of the Computing Facilities at the Graduate School of Business, the discontinuation of DEC-20 development left approximately 1,000 customers world-wide without a practicable ``growth path.'' Ten DECSYSTEM-20 computers on campus make that machine the most numerous large system at Stanford. The Graduate School of Business uses its two DEC-20s for administration, coursework, and research. The Computer Science Department uses two systems for research and administration. LOTS, the academic computer facility, supports instruction and unsponsored research on three systems and hopes to add one more in the time before the F1B is available. Other DEC-20s are at the Department of Electrical Engineering, the artifical intelligence project at the Medical Center (SUMEX), and the recently formed Center for the Study of Language and Information (CSLI). The Stanford University Network (SUNet), the main university computer communications network, links together the 10 DEC-20s, approximately 30 mid-size computers, about 100 high-performance workstations, and nearly 400 terminals and personal computers. The DEC-20 has been a cornerstone of research in artificial intelligence (AI). Most of the large AI systems evolved on the DEC-20 and its predecessors. For this reason, Stanford and other computer science centers depend on these systems for their on-going research. Lerner said the alternative to the new systems would entail prohibitive expense to change all programs accumulated over nearly twenty years at Stanford and to retrain several thousand student, faculty, and staff users of these systems. The acquisition of the Foonly systems would be a deliberate effort to preserve these university investments. 6-1-84 -30- JNS3A EDITORS: Lerner may be reached at (415) 497-9717, Gorin at 497-3236, and Bosack at 497-0445. ------------------------------ ------- Received: from MIT-MC by MIT-OZ via Chaosnet; 2 Jun 84 15:29-EDT Date: 2 June 1984 15:28-EDT From: Ken Harrenstien To: mly @ MIT-OZ, ai-kl @ MIT-OZ Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 41670; Wed 30-May-84 16:16:20-EDT Date: Wed, 30 May 84 16:16 EDT From: "David A. Moon" In-reply-to: The message of 30 May 84 07:05-EDT from Ken Harrenstien Date: 30 May 1984 07:05-EDT From: Ken Harrenstien Nope, no one has said anything (although I have had one request to forward whatever the response turns out to be!) Briefly, DEC is donating a KS10 with 512KW memory and an RP06 disk and a TU77 tapedrive, and two MH10 memories for MC, to MIT. MIT will have to pay for maintenance, though. The AI lab is going to call the KS10 "MIT-AI" and run ITS on it. They're also going to put on reasonable disks, ethernet, and maybe 1822 interface to Arpanet. Reasonable disks probably means Fujitsu M2351 (Eagle) via a pdp11 SMD interface and a special format-converting hardware device on the Unibus. I'm helping a little but I think people at the AI Lab are going to do most of the work. I guess if it works out MIT might get another KS10 when they get rid of MC, or another to replace ML, or something like that, but I don't know if there are any real plans or any money. The KS10 is pretty slow (roughly KA10 speed) but they take a lot less power, floor space, and maintenance than a KL and if we're lucky they are reliable and the price will continue to be right. (Certainly at list price they're a joke.) I'd expect the KS10 to be somewhat faster than an F2 (F3) but don't have any real bits on that. Additional info, updates, etc would be appreciated. Received: from MIT-MC by MIT-OZ via Chaosnet; 22 May 84 04:31-EDT Date: 22 May 1984 04:30-EDT From: Ken Harrenstien Subject: Advancing rapidly into the past. To: JTW @ MIT-SPEECH cc: TAFT @ MIT-MC, TK @ MIT-MC, ai-kl @ MIT-OZ, dph @ MIT-OZ, glr @ MIT-OZ, jinx @ MIT-OZ Not being local, I'd appreciate a little more background gossip than just "I am the slightly surprised recipient". How did this come about and what does it mean? Received: from MIT-MC by MIT-OZ via Chaosnet; 21 May 84 02:09-EDT Date: 21 May 1984 02:09-EDT From: Leigh L. Klotz Subject: Datapoint by Laurel To: ai-its @ MIT-OZ cc: HQM @ MIT-MC I have an old datapoint terminal that HQM has now, if you wanna hook that to AI. Received: from MIT-MC by MIT-OZ via Chaosnet; 17 May 84 18:35-EDT Date: 17 May 1984 18:09-EDT From: Christopher C. Stacy Subject: MIT-AI To: DPH @ MIT-MC cc: INFO-HOSTS @ MIT-MC, TAFT @ MIT-MC, TK @ MIT-MC, AI-KL @ MIT-OZ, GLR @ MIT-OZ In-reply-to: Msg of 16 May 1984 19:52-EDT from Daniel Huttenlocher I have sent in the update which renames MIT-AI-RESERVED (on IMP 6) to MIT-AI, and removes the "AI" nicknames from MIT-OZ (on IMP 77, but this entry is commented out.) Received: from MIT-MC by MIT-OZ via Chaosnet; 17 May 84 17:11-EDT Date: 17 May 1984 17:01-EDT From: David C. Plummer Subject: Advancing rapidly into the past To: TAFT @ MIT-MC cc: MARTY @ MIT-OZ, AI-ITS @ MIT-OZ, MARTY-CC @ MIT-OZ If we put it where the XGP used to be and hook up a solenoid we could have plast-from-the-past parties. Might need a datapoint... Mail-From: MARTY created at 16-May-84 22:36:20 Date: 16 May 1984 22:36 EDT (Wed) Message-ID: From: Martin David Connor To: "Jonathan D. Taft" Cc: AI-ITS@MIT-OZ, MARTY-CC@MIT-OZ Subject: Advancing rapidly into the past In-reply-to: Msg of 16 May 1984 19:52-EDT from Jonathan D. Taft Date: Wednesday, 16 May 1984 19:52-EDT From: Jonathan D. Taft It should go on the 9th floor. Call it AI and put it where AI used to be; I think there's even a hole that it can be shuffled into there. The place where AI used to be is now filled with Vaxen and 3600s. Putting it there would leave little room for expansion, and the power situation is tight. Another possiblity is the 7th floor machine room, although here again expansion would be hard. All things considered, I suggest putting the new AI in the CADR corral where it will have more room for expansion. There is a lot of room near the FileComputer, and along the wall adjacent CADR6. There is already a lot of power under the floor. In some ways it would be nice to put the new AI where the old one was, but it just may not be the best place. Mail-From: PGS created at 16-May-84 22:25:43 Date: Wed, 16 May 1984 22:25 EDT Message-ID: From: PGS@MIT-OZ To: John Wroclawski Cc: ai-kl@MIT-OZ, dph@MIT-OZ, glr@MIT-OZ, jinx@MIT-OZ, taft@MIT-MC, tk@MIT-MC, pgs@MIT-MC Subject: Advancing rapidly into the past. In-reply-to: Msg of 16 May 1984 17:34-EDT from John Wroclawski Holy tv:mouse-no-select-mixins, Batman!! Received: from MIT-MC by MIT-OZ via Chaosnet; 16 May 84 19:59-EDT Date: 16 May 1984 19:52-EDT From: Jonathan D. Taft Subject: Advancing rapidly into the past. To: JTW @ MIT-SPEECH cc: TK @ MIT-MC, ai-kl @ MIT-OZ, dph @ MIT-OZ, glr @ MIT-OZ, jinx @ MIT-OZ In-reply-to: Msg of Wed 16 May 84 17:34:47-EDT from John Wroclawski It should go on the 9th floor. Call it AI and put it where AI used to be; I think there's even a hole that it can be shuffled into there. Now about the 7030... Mail-From: DPH created at 16-May-84 19:56:20 Date: Wed, 16 May 1984 19:56 EDT Message-ID: From: Daniel Huttenlocher To: John Wroclawski Cc: ai-kl@MIT-OZ, glr@MIT-OZ, jinx@MIT-OZ, taft@MIT-MC, tk@MIT-MC Subject: Advancing rapidly into the past. In-reply-to: Msg of 16 May 1984 17:34-EDT from John Wroclawski Date: Wednesday, 16 May 1984 17:34-EDT From: John Wroclawski To: ai-kl, dph, glr, jinx, taft at MIT-MC, tk at MIT-MC Re: Advancing rapidly into the past. Currently relevant questions are 1) Where to put it, and 2) What to call it. This thing is pretty small, right? Can we make enough room where AI used to be to put it there (by flushing, er moving, htvax's lpt for example). Do you know the power requirements of the beast so we can make sure that is done... I agree with Moon about the name; MIT-OZ just lost its nicknames AI and MIT-AI. Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 16 May 84 19:41-EDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 33818; Wed 16-May-84 19:43:00-EDT Date: Wednesday, 16 May 1984, 19:37-EDT From: David A. Moon Subject: Advancing rapidly into the past. To: John Wroclawski Cc: ai-kl at MIT-OZ, dph at MIT-OZ, glr at MIT-OZ, jinx at MIT-OZ, taft at MIT-MC, tk at MIT-MC In-reply-to: The message of 16 May 84 17:34-EDT from John Wroclawski Date: Wed 16 May 84 17:34:47-EDT From: John Wroclawski Currently relevant questions are 1) Where to put it, and 2) What to call it. Terrific. It seems clear to me that it should be called MIT-AI. Mail-From: JINX created at 16-May-84 17:47:38 Date: Wed, 16 May 1984 17:47 EDT Message-ID: From: JINX@MIT-OZ To: John Wroclawski Cc: ai-kl@MIT-OZ, dph@MIT-OZ, glr@MIT-OZ, taft@MIT-MC, tk@MIT-MC Subject: Advancing rapidly into the past. In-reply-to: Msg of 16 May 1984 17:34-EDT from John Wroclawski Great! Hot shit! (this is from Taft) Received: from MIT-SPEECH by MIT-OZ via Chaosnet; 16 May 84 17:32-EDT Date: Wed 16 May 84 17:34:47-EDT From: John Wroclawski Subject: Advancing rapidly into the past. To: ai-kl@MIT-OZ, dph@MIT-OZ, glr@MIT-OZ, jinx@MIT-OZ, taft@MIT-MC, tk@MIT-MC It would appear that I am the slightly surprised recipient of one KS10-AA PDP10 CPU, with 512K MOS memory, 32 TTY lines, and a small DEC disk of some flavor. This object will be arriving in late May or early June. Currently relevant questions are 1) Where to put it, and 2) What to call it. -john ------- Received: from MIT-SPEECH by MIT-OZ via Chaosnet; 14 Mar 84 17:36-EST Date: Wed 14 Mar 84 17:37:32-EST From: John Wroclawski To: ai-kl@MIT-OZ, taft@MIT-OZ Newman Computer Exchange offers for sale the following: 1 KL10A CPU (only) $24,995 (Tricky, cause it used to be a 2040. Comments on possible missing external busses?) The above KL, + 2 RH20 massbus controllers and 16 lines worth of DC20 $47,000 MB-20 128K core memory $2495 (really) I had a nice long talk with a woman there who actually knows what she's doing... If anyone wants to follow this up, the obvious first step is to see if the money can be found. I should probably call this person back in a few days either way, so if by some miracle somebody finds some money, let me know, yes? ------- Received: from MIT-MC by MIT-OZ via Chaosnet; 14 Mar 84 02:57-EST Date: Tue 13 Mar 84 23:58:47-PST From: Ken Harrenstien Subject: ITS on a Foonly? To: ai-kl%oz@MIT-MC cc: klh@SRI-NIC In light of the recent discussion about buying a $99K 2020, I decided not enough was known about the Foonly alternative and sent some questions to Tymshare. I am distributing the responses I received, with some editing of extraneous material; I have also included my original questions in brackets where it seems necessary for clarity. --KLH ---------- Date: 29-Feb-84 01:41 PST From: Robert N. Lieberman Subject: Re: Foonly machine & code availability To: Ken Harrenstien Ken, I guess I the right person to ask most of those questions. let me try ... [KLH: Are F2s or F3s still available? What about the newer machines?] The F2 (or F3 as we call it) is no longer made. We have 8 but they are all used at TYM. Some clients some internal users. There are two models of interest relating to F4. System 26 is based on the F4 CPU and runs TENEX. It has ucode that supports the KA instruction set and emulates the KA TENEX map (pager). We have several of these, one is at SRI and one at CECOM in New Jersey (both of these are owned by customer). This model is no longer being made although one might be obtainable in the future. System 26KL is the latest model. It is also based on the F4 CPU but is modified to support the full extended addressing (actually 32 bits hardware-wise but that is not used since TOPS-20 does not use all those bits either). The 26KL has totally different ucode and emulates the KL instruction set including ALL the extended business instruction set. it emulates the KL style map. It runs the TYMCOM-20 operating System which is user identical to the TOPS-20 system. The 26Kl is spec-ed at 2.5 times the KA at the machine instruction level. This seems to be proved out but we are undergoing a big performance push right now and hope to have formal data by spring showing this to be at true. System 26KL is MOST definitely available for leasing or buying. We are gearing up for production of these beasts. There is a strong backing internally to use these machines for internal use in addition to external sales/leases. This provides a built in demand. the cost of a nicely configured system (1 meg memory, a few disks (660 MB), etc.) is about $300,000. You could probably push on that for universities but not sure how much. Yes, we are willing to provide access to ucode but this has yet to be made a firm committment from upper management. The front end (if used in the KL sense) does NOT exists. There is a Console computer that is used for booting and diagnostic work but has no relationship with I/O functions of the mainframe. We have TYMNET but no MILNET yet since we do NOT have the TCP/IP sources for TOPS-20 (can we get that from someone?? we do have a source license for TOPS-20 so I think we are entitled to it). We are anxiously seeking out programmers for both the monitor level work and for ucoding. I have two opening right now. We have hired a few enginerring types to help with manufacturing and for enhancements. I personally would love to have cooperative ventures with universities. Let me know if there is more interest from any quarters. Robert ------------------- Date: 2-Mar-84 23:47 PST From: Robert N. Lieberman Subject: Re: Foonly machine & code availability To: Ken Harrenstien [KLH: I asked for more details on the speed differences...] The 26KL has NO cache and although it is on the list of possible items to do, we currently have NO plans to implement it. You first have to understand why a cache on the 2060 is worth it. The memory cycle time is something like 800 ns so a cache can have a very dramatic effect. The 26KL has a memory cycle time of 350 to 425 depending on how we set some parameters. Right now we can run with no problems at 375 ns. Thus, we feel the cache will NOT provide a significant enhancement of performance as compared to some other ideas. The 26KL instruction speed (running the KL set) varies from lower than the KL (I won't say figures) to higher than the KL. On the average (what ever that means) it seems to come out to about 60% of the KL. Remember this is an instruction set speed comparison. I think the 2060 wins bigger in the I/O due to multiple controllers. Currently two is the max for the 26KL. We have a very nice list of wonderful things we can do with the 26kl to make it much better (VERY likely better than the 2060) but one OVERRIDING factor MUST happen. WE MUST SEE IF THE MARKETPLACE WILL ACCEPT THE 26KL. (basically as is). If not it does not make sense for us to develop it. We are rounding it out now and cleaning it up. It really is there and works. Several are at TYM now. We are very anxious to see the marketplace show interest. It did at the show but that seems to have died off. Very disappointing. (of course you may find fault with the lack of heavy advertising on our part, regretably that is a fact but not sure if that would have changed the situation). Whatever the marketplace says, TYM is very committed to produce these machines for internal use if for not other reason. However, future effort will key off of marketplace acceptance. The complete instruction set is there, full addressing is there. A wonderful implementation of the KL map is there. Power, size and cost seem to heavily favor the 26KL. With TYM maint., we can provide the whole thing. [KLH: I asked whether the price could be cut by leaving off the suede leather trim, racing stripes, etc.] Now for costs. certainly a barebones CPU (with 1/2 meg memory) can go for much less than the 300k figure. I will leave that up to the marketing types. Yes, i heard the 250k rumor but when you add everything else, it is easily 600k or more. So we are still 50% of their [KLH: DEC-2060] cost. Hope this helps. Robert --------------------- Date: 4-Mar-84 23:36 PST From: Robert N. Lieberman Subject: Re: Foonly machine & code availability To: Ken Harrenstien I would contact Cal Peterson for marketing info. I don't have his number here at home but will send it to you later. [KLH: I asked about the status of unbundling TOPS-20 -- not relevant to ITS, but interesting.] As for software on the 26KL, it is a matter of legalese on what TYMCOM-20 is. Certainly TOPS-20 cannot run on the 26KL and TYMCOM-20 cannot run on the DEC equipment. We have very different architecture which means parts of the monitor must be VERy different. however, from the user view, we are as identical as one can be. So what is it?? We claim, with some legal opinion, that TYMCOM-20 is NOT TOPS-20 and hence no licensing is needed by us or our customers. We certain do realize this might not completely dispell the fear of some legal action by DEC so we are trying hard to talk to DEC to clarify all this. TO date they are VERY hardnose. I think everyone agrees they are trying to delay things with the hope we just go away or die. My point of view says this is very short sighted for DEC, bad for their customers, and extremely sad for all those fans of the DEC 36 bit line. I sincerely wish to join forces with DEC and have mutual software develoment for the 36 bit line. DEC can do somethings and TYM can do others. Clearly the DEC 36 bit machines are now in the end of the line phase. If DEC wants to keep its base and hopes to move them onto the DEC 32 bit line, they need to do more. Joining with TYM will be a GIANT step forward. DEC has NO hope to convert those 36 bit sites to VAXen in the next 2 years. Why not hold onto them by letting them use a TYM 26KL. Eventually (if we are to believe DEC) the VAX will be bigger and better and more convenient for a 36 bit to VAX move. As I view it, we are really saving DEC!!!! Robert ----------------------- KLH: Well, it doesn't look as if a Foonly will be vastly cheaper than a DEC machine, but it does seem to have more potential than a 2020. The microcode differences may or may not make it harder to modify the paging; again, I can't judge this. If anyone wanted to pursue the cooperative angle, it may be possible to get a much better deal, although it's not clear whether Tymshare would expect improvements to TYMCOM-20 rather than to the machine, interfacing, or microcode. If for some reason anyone wanted to bundle together an ITS for export outside MIT, a 26KL would be an attractive direction to go in. I just wish they were faster about getting the installed base in place. If anyone does contact Rob for more info, I would appreciate being CC'd on it... ------- Mail-From: MARTY created at 9-Mar-84 23:16:10 Date: 9 Mar 1984 23:16 EST (Fri) Message-ID: From: Martin David Connor To: AI-ITS@MIT-OZ Subject: State I talked to PHW Thursday, and his view is that 99k for a machine that DEC cannot sell is unreasonable. We will apparently be waiting until they become more reasonable before doing anything more on this issue. Just thought folks would like to know where things stand. %= Received: from MIT-MC by MIT-OZ via Chaosnet; 25 Feb 84 08:26-EST Date: 25 February 1984 08:27-EST From: Pandora B. Berman Subject: ITS? To: DMS @ MIT-OZ cc: ai-its @ MIT-OZ Date: 24 Feb 1984 10:25 EST (Fri) From: David Siegel To: Martin David Connor Cc: AI-ITS%MIT-OZ@MIT-MC.ARPA Subject: KS-10 Is LCS planning on phasing out MC and ML? Since I assume they are, is there any chance they can be talked into maintaining ITS machines too? The more ITS machines around, the more likely ITS will stay around, and the easier it will be keep the systems in good shape. i think you are confused; ML and MC ARE ITS machines, and many of the people who maintain them are AI people. LCS is theorectically getting rid of ML as soon as there are enough lines (terminal concentrator or direct) into MC to adequately serve the ML users, since ML is hardwarily dying. LCS is also theorectically getting rid of MC in a couple of years; it is not clear whether this time schedule will be adhered to. the continued life of ITS depends on AI getting some machinery which runs ITS. Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 24 Feb 84 23:35-EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Fri 24-Feb-84 23:37:23-EST Date: Friday, 24 February 1984, 23:35-EST From: David A. Moon Subject: On 2020's To: Ken Harrenstien Cc: ai-its at MIT-OZ In-reply-to: The message of 24 Feb 84 20:51-EST from Ken Harrenstien Date: 24 February 1984 20:51-EST From: Ken Harrenstien I too am reluctant to recommend that a 2020 be procured. Their main virtue is the claim that they can be obtained for free, because they are useless for running Tops-20, and will be maintained by DEC. At $99K they are no bargain. Especially if 2060's are down to $250K now. How does its speed compare with the MC KL-10? It looks like a factor of 4 slower but I haven't seen any detailed numbers. You certainly couldn't load it up heavily; but as a network mail server it could be worthwhile. Think of it as a replacement for AI or ML, not as a replacement for MC. Or OZ. There is this theory, which has not been carefully evaluated but does make a lot of sense, that the reason Tops-20 is so slow on the 2020 is because Tops-20 simply does not fit in 512K. ITS, with its non-paged executive, tenser code, and much fewer features, would do better on a small machine. That's the theory. The 2020/2060 differences are not trivial, but someone who knows more about it than I do would have to comment on how these differences affect their ability to run ITS. I just have the gut feeling that getting a 2020 is practically equivalent to resurrecting the AI KA-10 (and a lot more expensive). I've looked at the KS-10 microcode enough to figure out what needs to be done to make it into an ITS machine. It's not too bad. It would be a lot less expensive than resurrecting the AI KA-10, since an entire industry would have to be recreated from scratch to do the latter. At $99K it's no bargain though, but at a nominal price plus the addition of AI-lab-supplied disks and ethernet interface it would be worthwhile. I don't believe it is possible to buy a F-2 any more; Tymshare is getting all of Foonly's output (F-4?s) for their new TYMCOM-20 systems (which are supposed to run TOPS-20 like a 2060). I don't know how much work would be required to modify the microcode of this latest Foonly to run ITS. Probably more than a DEC 20, but Moon is likely the only person who can evaluate that (the F4 ucode is not greatly different from the F2 I believe, although the F4 is a much better machine). The F-2 and KS-10 are comparable as far as microcoding goes. That is, the internal organizations of the machines are completely different, and the microcode looks quite different, but what you have to do for page-mapping is conceptually the same. Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Feb 84 20:51-EST Date: 24 February 1984 20:51-EST From: Ken Harrenstien Subject: On 2020's To: ai-its @ MIT-OZ I too am reluctant to recommend that a 2020 be procured. If you are going to the trouble of buying a 20 you might as well get something reasonable. It would be easier to justify, perhaps, if you pointed out that the machine could always be switched over to TOPS-20 if all ITS people suddenly died off; and a 2020 does NOT have the capacity to run the latest versions (including TCP/IP) of TOPS-20!!! How does its speed compare with the MC KL-10? I haven't been able to find a network 2020 to run timing tests on... probably a significant datum by itself. The 2020/2060 differences are not trivial, but someone who knows more about it than I do would have to comment on how these differences affect their ability to run ITS. I just have the gut feeling that getting a 2020 is practically equivalent to resurrecting the AI KA-10 (and a lot more expensive). I don't believe it is possible to buy a F-2 any more; Tymshare is getting all of Foonly's output (F-4?s) for their new TYMCOM-20 systems (which are supposed to run TOPS-20 like a 2060). I don't know how much work would be required to modify the microcode of this latest Foonly to run ITS. Probably more than a DEC 20, but Moon is likely the only person who can evaluate that (the F4 ucode is not greatly different from the F2 I believe, although the F4 is a much better machine). Mail-From: HENRY created at 24-Feb-84 14:17:16 Date: Fri, 24 Feb 1984 14:17 EST Message-ID: From: HENRY@MIT-OZ To: Martin David Connor cc: AI-ITS@MIT-OZ Subject: KS-10 In-reply-to: Msg of 23 Feb 1984 17:57-EST from Martin David Connor My experience is that the 2020 is a VERY slow machine, by comparison with the 2060 we're used to. As such, given the computron-hunger of AI lab users, I think it is completely impractical as a time-sharing machine. It still might be worth getting the 2020 if it had a specialized use such as running ITS for an Arpanet connection and mail server. The money would probably be better spent buying a 3600, lambda, or extras like disks, memory, color displays, [I'd vote for the latter] for the machines we already have. Or how about another printer? [Well, I guess we don't really need one, the Dover is so reliable]. I'd suggest you ask to try before you buy. Mail-From: DMS created at 24-Feb-84 10:25:10 Date: 24 Feb 1984 10:25 EST (Fri) Message-ID: From: David Siegel To: Martin David Connor Cc: AI-ITS@MIT-OZ Subject: KS-10 In-reply-to: Msg of 23 Feb 1984 17:57-EST from Martin David Connor Is LCS planning on phasing out MC and ML? Since I assume they are, is there any chance they can be talked into maintaining ITS machines too? The more ITS machines around, the more likely ITS will stay around, and the easier it will be keep the systems in good shape. Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 24 Feb 84 01:07-EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Fri 24-Feb-84 01:08:27-EST Date: Friday, 24 February 1984, 01:07-EST From: David A. Moon Subject: KS-10 prices To: Marty at MIT-OZ Cc: AI-ITS at MIT-OZ For a point of comparison, that price ($99K) is slightly higher than the price for a comparably-configured Foonly F-2, a machine of comparable performance and physical dimensions. You expect to pay a premium for a DEC machine, but it still seems pretty high for a used computer. Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 23 Feb 84 23:37-EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Thu 23-Feb-84 23:39:09-EST Date: Thursday, 23 February 1984, 23:38-EST From: David A. Moon Subject: KS-10 To: Martin David Connor Cc: AI-ITS at MIT-OZ, MARTY-CC at MIT-OZ In-reply-to: Date: 23 Feb 1984 17:57 EST (Thu) From: Martin David Connor 1 KS-10 (2020) with 512kw 1 TU77 tape drive (800/1600 bpi, 9trk) 1 RP06 disk drive 16 DZ lines $99,400 What's the price without the (presumably overpriced) DEC tape drive and disk? Is one or both of these required in order to have a maintenance contract? Note that in any case it will be necessary to put additional disks on it, so the RP06 is useless unless DEC requires it. It is understood how to put additional disks on, cost-effectively, using hardware available at the AI lab. What's the story on the free KS-10? JTW, have you heard lately? Did Linda offer this $99K as a special, good-deal price, or is this the normal price? If the latter, what happens if you say "well we think we can one for free, and $99K seems kind of high, can we deal?" I mentioned in passing that we would likely need access to the microcode, and she said she would check on that too, but did not seem overly worried at this point. The machine will be unusable without the ability to change the microcode. It won't take enormous changes, but it will take some. Received: from MIT-MC by MIT-OZ via Chaosnet; 23 Feb 84 19:01-EST Date: 23 February 1984 19:03-EST From: David C. Plummer Subject: KS-10 To: MARTY @ MIT-OZ cc: AI-ITS @ MIT-OZ, MARTY-CC @ MIT-OZ Date: 23 Feb 1984 17:57 EST (Thu) From: Martin David Connor I talked to Linda today and got a price on the KS-10. The configuration in question: 1 KS-10 (2020) with 512kw 1 TU77 tape drive (800/1600 bpi, 9trk) 1 RP06 disk drive 16 DZ lines These (the DZ lines) are mostly useless, but it should be (better be) less than $2K of the cost. The price: $99,400 I assume this is competitive? I guess what I need now is opinions on how to proceed. If we decide that the AI Lab should buy this machine we will have to convince PHW (and possibly others) that it is a good idea (as opposed to buying a 3600 or something). A 3600 won't time share. People with ideas (even if you don't want to do them), please speak up so I know what to tell Linda. Right now I have told her that we are interested (don't let anyone else have it right now), and that I hope to have an answer for her next week. Don't forget to get more disk drives and worry about all the other paraphenalia. If this thing is really going to have a Unibus, we could probably put an Interlan Ethernet card on it. I'm willing to do all the work for the driver and address resolution. I mentioned in passing that we would likely need access to the microcode, and she said she would check on that too, but did not seem overly worried at this point. "Likely" is an understatement. Mail-From: MARTY created at 23-Feb-84 17:57:06 Date: 23 Feb 1984 17:57 EST (Thu) Message-ID: From: Martin David Connor To: AI-ITS@MIT-OZ Subject: KS-10 cc: MARTY-CC@MIT-OZ I talked to Linda today and got a price on the KS-10. The configuration in question: 1 KS-10 (2020) with 512kw 1 TU77 tape drive (800/1600 bpi, 9trk) 1 RP06 disk drive 16 DZ lines The price: $99,400 I guess what I need now is opinions on how to proceed. If we decide that the AI Lab should buy this machine we will have to convince PHW (and possibly others) that it is a good idea (as opposed to buying a 3600 or something). People with ideas (even if you don't want to do them), please speak up so I know what to tell Linda. Right now I have told her that we are interested (don't let anyone else have it right now), and that I hope to have an answer for her next week. I mentioned in passing that we would likely need access to the microcode, and she said she would check on that too, but did not seem overly worried at this point. So, that's the state right now. If I am not being clear about something or you need more information, please ask, and I will try to do better (what are bureaucrats for?). %= Received: from MIT-MC by MIT-OZ via Chaosnet; 15 Feb 84 21:27-EST Date: 15 February 1984 21:14 EST From: David Vinayak Wallace Subject: what happens ... To: EE.GDS @ MIT-OZ cc: ai-its @ MIT-OZ In-reply-to: Msg of Wed 15 Feb 84 00:27:50-EST from Greg Skinner Date: Wed 15 Feb 84 00:27:50-EST From: Greg Skinner ... to OZ if the AI Lab actually purchases a KL and runs ITS on it. Will the 20 remain, go away, ...? It's to be installed in Paul Grey's office and used to heat building 10. They can use it most efficiently since they are used to brain-damage and hot air. Mail-From: EE.GDS created at 15-Feb-84 00:27:50 Date: Wed 15 Feb 84 00:27:50-EST From: Greg Skinner Subject: what happens ... To: ai-its@MIT-OZ ... to OZ if the AI Lab actually purchases a KL and runs ITS on it. Will the 20 remain, go away, ...? ------- Received: from SCRC-QUABBIN by MIT-OZ via Chaosnet; 31 Jan 84 19:13-EST Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Tue 31-Jan-84 19:12:25-EST Date: Tuesday, 31 January 1984, 19:11-EST From: David A. Moon Subject: still pushing (don't get your hopes to high, but...) To: Martin David Connor Cc: AI-ITS at MIT-OZ In-reply-to: Date: 31 Jan 1984 18:45 EST (Tue) From: Martin David Connor Linda thinks that it is a KS, with 384k, and is running with some small disks (RM03s are small I think, don't have my catalog with me). It would likely have to be expanded to 512K. I think we'd like to put non-DEC disks on it, e.g. Eagles on a Unibus SMD controller. This requires a fairly simple custom Unibus device, which JTW, Taft, and I discussed once, to make it possible to use efficiently an SMD controller that transfers 16-bit words. What is going need writing is something about all the useful functions that this machine could serve. When the time comes I'll probably need some help with this (proofreading and suggestions mainly). I can probably provide some suggestions but can't put an enormous amount of time into it. Mail-From: MARTY created at 31-Jan-84 18:45:14 Date: 31 Jan 1984 18:45 EST (Tue) Message-ID: From: Martin David Connor To: AI-ITS@MIT-OZ Subject: still pushing (don't get your hopes to high, but...) I just talked to Linda again. She talked to the Field Service people with the KS. It looks like they are still trying to find a buyer for it. I made it clear that we are VERY interested in it (at the right price of course). Linda thinks that it is a KS, with 384k, and is running with some small disks (RM03s are small I think, don't have my catalog with me). But anyway, she says she will talk to the guy again this week, and she will get back to me next Monday (I told her I would call her Tuesday if I didn't hear from her on Monday). I told Linda that we would almost certainly be getting a service contract on this machine if we got it (I can see Lester and D'Avolio smiling now). She will try to get a price by next week on this for us. I think PHW would be receptive to getting this machine if we could get it for less than 100k (the close to 50k the better). If we got it, and got it running reliably, maybe LCS (I've heard Dave Clark has an open mind on this), might be willing to get one too to replace ML. KS processors are about the size of two 3600's side by side. I don't want to get hopes up too high on this, but all the signs are there for some "guarded optimism". What is going need writing is something about all the useful functions that this machine could serve. When the time comes I'll probably need some help with this (proofreading and suggestions mainly). I'll let you know about this later. %= Mail-From: MARTY created at 30-Jan-84 19:17:53 Date: 30 Jan 1984 19:17 EST (Mon) Message-ID: From: Martin David Connor To: AI-KL@MIT-OZ Subject: more state My last message left people wondering what 750s have to do with this business of getting machines to run ITS. Basically they have nothing to do with running ITS, or with the current project. It was diversionary to mention them, and I am sorry for the confusion I caused. I was attempting to explain how I spent the hour I talked to Linda. I am also interested in getting a 750, more out of the belief that it would be good to know how to hack them, and that they can do useful things (relatively speaking). I would rather have an ITS, but this is not a one-or-the-other deal as far as I can tell. And yes, I believe that COMSAT is the best mailer for the job of moving mail. And I think that I would much rather work on a machine where there are ITS hackers who, even if sometimes they flame too much for my taste, are bright, informed, and can fix the bugs that they find. I ran into PHW this afternoon, and told him that I have met with Linda, and that she says that she is trying to find a KS (2020) or a KL (2060) for us. She said that she had heard that Field Service was looking for a buyer for one, and that she was going to try to get in touch with them on this. Well, anyway, here's what we're talking about for a NEW one: 110,000 for the processor, 384k, and 1 RP06 drive 20,000 for the other 128k memory so we can have 512k 36,000 for a TAU77 (unibus, 9trk, TU77, 800/1600bpi, autoload) 34,000 for an extra RP06 (apparently one comes with it) ------- 200,000 Now, here's some improvements to this deal. 50,000 for the processor, memory (512k) 36,000 for a TAU77 ------- 86,000 I'm guestimating what a second-hand processor might cost. The disk theory is that we could take a couple of the RP06s from OZ and get an RP07 or two to replace them. DEC is giving 7k for RP06s these days so it can stop making them and put them on the 20s it is still selling. We could likely justify replacing some of the RP06's on OZ with RP07's in light of the perpetual space crunch. (an RP07 is about 3 RP06s). So that's the story so far. Hints, comments, constructive criticism, are all welcome. I haven't heard back Linda on the KS-10 yet, and yes, she is also looking for a KL still. I will call her tomorrow (and tomorrow and tomorrow...). Received: from MIT-MC by MIT-OZ via Chaosnet; 27 Jan 84 20:15-EST Date: 27 January 1984 20:17 EST From: David C. Plummer Subject: Meeting with Linda To: CENT @ MIT-MC cc: MARTY @ MIT-MC, AI-KL @ MIT-OZ Date: 26 January 1984 01:00 EST From: Pandora B. Berman i don't quite understand why you want a vax. you were saying you would want to run unix on it, and i gather you intend to make it the AI machine on the arpanet. but from what i understand, the unix mail system is incredibly horrible; it appears to trash headers with great regularity and cause other problems. Indeed, the mail system in 4.1bsd is complete shit. If you thought Symbolics screwed the world with a release that insisted MIT-MC was named DM and OZ was named AI, you ain't seen nothing until Unix rapes the mail headers. I have been told that 4.2 fixes all of this. I won't believe this until I see it; not enough SCRC Vaxes are running 4.2 to get enough mail traffic to tell. Received: from MIT-MC by MIT-OZ via Chaosnet; 26 Jan 84 00:57-EST Date: 26 January 1984 01:00 EST From: Pandora B. Berman Subject: Meeting with Linda To: MARTY @ MIT-MC cc: AI-KL @ MIT-OZ Date: 26 Jan 1984 00:14 EST (Thu) From: Martin David Connor To: AI-KL%MIT-OZ@MIT-MC.ARPA Subject: Meeting with Linda I finally met with Linda Crawford, our DEC hardware salesperson..... I basically got a list of prices for new equipment which is very expensive, and also a quote on a 750. i don't quite understand why you want a vax. you were saying you would want to run unix on it, and i gather you intend to make it the AI machine on the arpanet. but from what i understand, the unix mail system is incredibly horrible; it appears to trash headers with great regularity and cause other problems. Mail-From: MARTY created at 26-Jan-84 00:14:45 Date: 26 Jan 1984 00:14 EST (Thu) Message-ID: From: Martin David Connor To: AI-KL@MIT-OZ Subject: Meeting with Linda cc: MARTY-CC@MIT-OZ I finally met with Linda Crawford, our DEC hardware salesperson. She basically didn't have much exciting to say. She says there are not that many KL model A's in circulation anymore, since Field Service doesn't want to service them, people have mostly upgraded rather than trading them in. She is going to look for a refurbished KL model B next. She mentioned that she may have a lead on a KS (2020) which F-S is trying find a buyer for. I basically got a list of prices for new equipment which is very expensive, and also a quote on a 750. She gave me promises of calling back with more info. I will try to give her a call tomorrow afternoon to let her know we are very interested, especially in the KL type hardware. Mail-From: MARTY created at 19-Jan-84 14:59:54 Date: 19 Jan 1984 14:59 EST (Thu) Message-ID: From: Martin David Connor To: ai-kl@MIT-OZ Subject: Tune in tomorrow cc: MARTY-CC@MIT-OZ Linda Crawford got snowed out/in for today. We rescheduled for tomorrow afternoon. Same place... Mail-From: MARTY created at 17-Jan-84 03:48:12 Date: 17 Jan 1984 03:48 EST (Tue) Message-ID: From: Martin David Connor To: ai-kl@MIT-OZ Subject: current state I am still trying to find us a KL of some flavor. I have a meeting this Thursday with Linda Crawford, the person at DEC that handles hardware sales to MIT to discuss this (among other things). I have already told her what sort of machine and peripherals we are looking for, and she claims to be looking. As for selling this machine to PHW, if Indeed Linda comes up with a machine with a reasonable price where price is a little vague right now, people should start letting PHW know that there is interest. I will report back what goes on Thursday at the meeting. Mail-From: MARTY created at 29-Sep-83 15:47:25 Date: Thursday, September 29, 1983 3:47PM-EDT From: Martin David Connor Subject: Still Looking... To: ai-kl I talked to Linda Crawford again today, and she claims to be still looking for the KL. The timing issues involved here is that space is sort of first-come first served around the ninth floor on the AI side, so we have to get it before 3600's fill up the space, else we'll have to find somewhere else to put it. Wanted you to know that I am still pushing on this end. Return-path: Mail-From: MARTY created at 13-Sep-83 23:59:02 Date: 13 Sep 1983 23:59 EDT (Tue) Message-ID: <[MIT-OZ].MARTY.13-Sep-83 23:59:01> From: Martin David Connor To: AI-KL@MIT-OZ Subject: State I talked to Linda Crawford from DEC today, and also to Lester "The Molester" Saucer, about their efforts to find a machine. Linda (who is is hardware sales), is trying to find a "refurb" 20 which we can get at a real low price. Les is also looking. The refurbished 20's are warrantied like new ones, and we of course would get a service contract. Not much to do now but to wait for a price. From what they are saying, it looks like we might get: a 2060 (model "B" processor), 1 meg memory 2 or 3 RP04's, a 9trk tape drive, 2 11/34s, 2 DH11's (32 ports), 1 decrotter (probably 1220baud). I'll let you know when I get a quote. Just wanted the pass some state. Return-path: Date: 16 August 1983 22:29 EDT From: David C. Plummer Subject: small update To: MARTY @ MIT-OZ cc: AI-KL @ MIT-OZ, MOON @ SCRC-TENEX If you get any DHs, for whatever reason, by all means do NOT get a DH from DEC. These suckers require a dedicated backplane and are probably infinite headaches. Symbolics has been using Able DHs, which are software compatible, fit in 1 standard hex slot, have smarter DMA, have modem control to boot (I think its an extra with the DEC DHs) and are probably cheaper.Return-path: Date: Tuesday, 16 August 1983 16:14-EDT From: MOON at SCRC-TENEX To: Martin David Connor Cc: AI-KL at MIT-OZ Subject: small update In-reply-to: The message of 16 Aug 1983 14:29 EDT (Tue) from Martin David Connor Date: 16 Aug 1983 14:29 EDT (Tue) From: Martin David Connor Question: What model number (TU-??) is MC's tape drive? Right now I am thinking for starters we need: 2 RP04's 1 KL Model A CPU 1 7 track tape drive Memory 1 or 2 11's for network interface. Get a 9-track tape drive. In the long run it will be more useful than a 7-track tape drive. In the short run, AI backup tapes can be read on ML or MC and sent through the network, then either put on-line or dumped onto 9-track tape. The reasons for wanting a 9-track tape drive are higher speed (1600 bpi vs. 800 bpi for 7-track), better maintainability, and compatibility with other machines such as OZ and VAXes. Of course if you can find a free 7-track drive that can go on the same controller, get one of them, too. Depending on the kind of machine it might have a controller compatible with ML's drive or one of AI's old drives, which could be brought over temporarily. 2 RP04's are much better than 1, but if they're expensive it could be worth considering one. The only issue here is how long it takes DEC to fix you only RP04 when it breaks. They are guaranteed to break. I don't think it matters a whole lot whether the CPU is model A or B. The microcode for model A is already done, but as I recall it would be trivial to make it work for model B. Model A might be a win because of having a lower resale value (being slower and cruftier), thus costing less. The big issues in KL10 configuration that you haven't mentioned are whether it uses internal (20-type) or external (KA/KI-compatible) memory, and whether or not it has an external (KA/KI-compatible) I/O bus. "1080" machines like MC have external memory and I/O bus. Takes up a lot of floor space but gives you a little more flexibility and a higher performance pdp11 interface if you have a DL10 (it's unclear to me that you want a DL10). Adding device drivers for the RH20 (internal memory and I/O) tape and disk controllers to ITS would not bve very hard, so that shouldn't be a consideration. Considerations are price, maintainability, and whether you have any old-type things you want to connect up (I wouldn't recommend ARM10s, but maybe they're better than no memory). If the ML and/or DM machines are going to go away, is there any issue of attaching some of their more reliable memory or peripherals to this new machine? Questions: How much memory do we need? As we've seen you can operate with 512KW, or even somewhat less. 1MW would be better. 256KW would be a joke. How many and what flavor 11's? I guess DCP answered this. The one that comes with the machine is enough, barely. The absolute need for a second one with TOPS-20 is due to software. If it's not expensive a second DTE-20 interface and a second 11 running MINITS (maybe this second 11 could be one you already have) might help with performance and with Internet support). What sort of hardware do we need for ARPAnet support? JNC's claim that you want no hardware, and instead use ethernet as a way to get to the existing gateway onto the Arpanet is probably the right thing. With an external I/O bus you could go find AI's Arpanet interface, but it will have considerably lower performance on a KL than on a KA (interrupt system brain damage) and might well become a maintenance headache. You could replicate MC's interface, again requiring an external I/O bus. It could turn into a maintenance headache eventually since some of the parts it's made out of haven't been manufactured for several years. What other hardware do we need? Controllers for disk and tape. Whether these are freestanding cabinets or just boards inside the KL depends on whether you have internal or external interfaces. In the free-standing cabinet version you need at least one DF10C data channel (two if you have a TM10C DMA tape controller and want extra performance, but you can share a DF10 between disk and tape controllers (DM does--I think it's the reason their disk used to get clobbered, but that was only superstition). DEC operating systems only support DMA tape controllers, but our microcode (bugs fixed for the Arpanet interface) should support either.) Front-console decwriter. Do you want any hardwired line controllers in the pdp11, or do you want to have all network terminals? MC uses DH11s, other interfaces could be programmed easily enough. Did you check on whether anything from the WPI machine remains in the basement, whether LCS (presumably DDC rather than AV now) will let you use it, and whether it's useful? I will be talking to the salesman again soon, so if we could agree on a minumal starting configuration, that would help me to get an initial price. It would probably be best to research prices for both external-memory-and-I/O configurations ("1080") and internal-memory-and-I/O configurations ("2060"). "1090" is some kind of hybrid, maybe it's internal busses but painted blue? People should be more willing to get rid of the external kind, but maybe it costs more because it has so much more iron and steel in it. The external kind is easier on the software and would allow connecting up old stuff that's lying around the lab, but those may not be compelling arguments. Also you should seriously consider my suggestion of using SMD disks on pdp11s for expansion after the initial one or two RP04s. This pdp11 can be shared with the network-interfacing pdp11 if it has enough memory. Date: 16 August 1983 15:14 EDT From: Glenn S. Burke Seeing the problem MC has with volume of tape, it may be worth considering 1600 bpi, even though that would not be able to be read elsewhere. If it could deal with 800 also then it could at least read tapes from the other machines, and backups made by paranoid individuals could be made at 800. ITS can deal with this, can't it? I seem to remember a bit or field somewhere which gave this information. You can set the density on tape drives to one of four values. The default could easily be changed from 800 to 1600 in the software if the hardware supported it. A 9-track 800/1600 drive could not read 7-track 800 bpi tapes from other machines, but see the argument above as to why that's not important. Return-path: Date: Tuesday, 16 August 1983 15:39-EDT From: MOON at SCRC-TENEX To: David C. Plummer Cc: AI-KL at MIT-OZ, MARTY at MIT-OZ Subject: small machines In-reply-to: The message of 16 Aug 1983 15:08 EDT from David C. Plummer Date: 16 August 1983 15:08 EDT From: David C. Plummer 11/34s are probably the easiest off the shelf items to get. I would suggest 11/34s unless Moon has some reason to prefer an 11/40 or 11/45. Bleagh! 11/40s break all the time, and 11/45s are kind of big. 11/34s it is. Return-path: Date: 16 August 1983 15:14 EDT From: Glenn S. Burke Subject: tape drives To: ai-kl @ MIT-OZ Seeing the problem MC has with volume of tape, it may be worth considering 1600 bpi, even though that would not be able to be read elsewhere. If it could deal with 800 also then it could at least read tapes from the other machines, and backups made by paranoid individuals could be made at 800. ITS can deal with this, can't it? I seem to remember a bit or field somewhere which gave this information. Return-path: Date: 16 August 1983 15:08 EDT From: David C. Plummer Subject: small update To: MARTY @ MIT-OZ cc: AI-KL @ MIT-OZ How many and what flavor 11's? Number may depend on network configuration. Type is definitely Unibus. 11/34s are probably the easiest off the shelf items to get. I would suggest 11/34s unless Moon has some reason to prefer an 11/40 or 11/45. Return-path: Date: 16 August 1983 14:41 EDT From: J. Noel Chiappa Subject: Future of MC To: ai-kl @ MIT-OZ I talked to Dave Clark today about MC. He really hasn't picked up on what's going on in detail yet, but he was generally very receptive to keeping ITS around in the long term, subject to the proviso that the maintainence doesn't turn into an impossibility or a drain. The fact that ITS now has good InterNet software was THE key point, and the fact that the hardware was almost all over the shelf (although things like the ARM and disk controller could be a problem) and was vendor-maintained was also essential. He's also very interested in coordinating with the AI Lab on ITS maintainence, and is planning on going to talk to PHW. So, what's the word from American Used? Do they have (or can they find) a KL? Return-path: Mail-From: MARTY created at 16-Aug-83 14:29:22 Date: 16 Aug 1983 14:29 EDT (Tue) Message-ID: <[MIT-OZ].MARTY.16-Aug-83 14:29:21> From: Martin David Connor To: AI-KL@MIT-OZ Subject: small update I called American Used Computer, and talked to their salesman. He will call me back tomorrow. I told him basically what we need. He was neither positive or negative, so we'll have to wait to see what he says. Question: What model number (TU-??) is MC's tape drive? Right now I am thinking for starters we need: 2 RP04's 1 KL Model A CPU 1 7 track tape drive Memory 1 or 2 11's for network interface. Questions: How much memory do we need? How many and what flavor 11's? What sort of hardware do we need for ARPAnet support? What other hardware do we need? I will be talking to the salesman again soon, so if we could agree on a minumal starting configuration, that would help me to get an initial price. Return-path: Date: 15 Aug 1983 1859-EDT From: J. Noel Chiappa Subject: Re: Disks To: MOON@SCRC-POINTER, ai-kl@MIT-OZ cc: JNC@MIT-XX In-Reply-To: Your message of 14-Aug-83 2203-EDT Also, SI (at least) makes controllers for SMD disks that interface to the 11 with full block buffers in the controller. ------- Return-path: Date: 15 Aug 1983 1856-EDT From: J. Noel Chiappa Subject: Re: Disks To: MOON@SCRC-POINTER, ai-kl@MIT-OZ cc: JNC@MIT-XX In-Reply-To: Your message of 14-Aug-83 2203-EDT I would think two RP0X's, in case one croaks; the system could still be booted. Also, in the normal (i.e. 2 disks up) case I would think that that would obviate paging off the UNIBUS disks. Also, I don't know if ITS does overlapped seeks, but if so that would also increase the paging throughput. I assume that the import of that last cryptic paragraph is that you would pack 4 PDP10 words into 9 PDP11 words exactly? Too bad the DL10 can't do that... ------- Return-path: Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 14-Aug-83 21:53:00-EDT Date: Sunday, 14 August 1983, 21:50-EDT From: MOON@SCRC-POINTER Subject: Disks To: ai-kl@MIT-OZ It occurs to me that it might make sense to use Fujitsu M2351s ("Eagles") for disks. In any case it is necessary to have one RP04 or RP06, dual-ported on the 10 and the 11, in order to have DEC maintenance. And DEC maintenance, as much of a circus as it is, is essential. But for disks after the first, you want to use something cost-effective. I get the impression that at the AI lab Eagles cost nothing and are available in infinite supply, if you know who to filch them from. MC manages satisfactorily with disks running through a pdp11, although there is a significant penalty both in performance and in disk capacity (it takes 48 bits of disk to store each 36-bit word, thus 25% of the disk capacity is wasted). If a new machine doesn't have a DL10 and has to use a DTE20 to talk to the pdp11 with the disks, as seems very likely, there is an additional performance penalty of 5 or 10 milliseconds of pdp10 cpu time blown away for each 1K word transfer to or from disk. But it's better than nothing, and you can try to page off the RP04 as much as possible, or have a large enough ratio of memory to load that you don't page too much, or just be glad the machine isn't as slow as a KA. This would all be contingent on having a Unibus SMD controller with enough buffering that it can succeed in interfacing such a high speed disk to such a slow machine (pdp11). The software issues, in both pdp10 and pdp11, are not insurmountable at all. Actually I think I know how to eliminate the disk capacity problem, with suitable KL10 microprogramming (to allow bytes that span word boundaries in DTE20 transfers, so you can transfer 16-bit bytes instead of 12-bit bytes). Return-path: Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Sun 14-Aug-83 03:04:10-EDT Date: Sunday, 14 August 1983, 02:57-EDT From: David A. Moon Subject: Re: working.... To: J. Noel Chiappa Cc: DCP@MIT-MC, CENT@MIT-ML, ai-kl@MIT-OZ In-reply-to: The message of 14 Aug 83 01:37-EDT from J. Noel Chiappa Date: 14 Aug 1983 0137-EDT From: J. Noel Chiappa Well, I wouldn't mind lending a hand if it's desired. I've pored over the IOELEV code a lot (for a variety of strange reasons, like looking at the PUP code, etc), and I know 11's inside out, so if you want a hand with the Internet code I could find the time to hack that. The code to talk to the 10 is unknown to me, so I'd not be much use there. Well that's the main hard part, always. Still, lets not count chickens, etc. But the point about another 11 is well taken. Speaking of which, does anyone have any idea of the % load that the 2 11's on MC are under now? (The IOELEV main loop doesn't WAIT so the easy hack of having the clock in check the PC is nogo.) A second 11 might also be a good idea if the will of the wisp KL10 has MOS memory, thus requiring more of the DEC brain damage to reside in the 11. I presume we don't have (ahem) access to up to date sources for this. I'm sure it would be trivial to make ITS talk to MINITS. Looking at the lights on the DL10 suggests that except for running the disks that 11 is lightly loaded. Presumably one would not have to put disks on the 11 on any new machine, since DL10s are much more expensive than disk drives these days and the company that made MC's Unibus disk controller is dead if I remember correctly. Also, how much memory is unused in those machines? None. On the main one, the memory is full of DEC brain damage (probably there is really a couple of K of space free, since it has 28K of memory). On the auxiliary one there is only 16K, and between disk buffers, network buffers for three interfaces, terminal buffers, DDT and a symbol table there isn't any memory left. If desperate one could remove the symbol table of course. You can get 11STNK to print a map of memory (but you have to know how much physical memory is in the machine and what is taken up by KLDCP on the main 11). Return-path: Date: 14 Aug 1983 0137-EDT From: J. Noel Chiappa Subject: Re: working.... To: DCP@MIT-MC, CENT@MIT-ML cc: ai-kl@MIT-OZ, Moon@SCRC-TENEX, JNC@MIT-XX In-Reply-To: Your message of 13-Aug-83 1855-EDT Well, I wouldn't mind lending a hand if it's desired. I've pored over the IOELEV code a lot (for a variety of strange reasons, like looking at the PUP code, etc), and I know 11's inside out, so if you want a hand with the Internet code I could find the time to hack that. The code to talk to the 10 is unknown to me, so I'd not be much use there. Still, lets not count chickens, etc. But the point about another 11 is well taken. Speaking of which, does anyone have any idea of the % load that the 2 11's on MC are under now? (The IOELEV main loop doesn't WAIT so the easy hack of having the clock in check the PC is nogo.) Also, how much memory is unused in those machines? ------- Return-path: Date: 13 Aug 1983 1857-EDT From: J. Noel Chiappa Subject: Re: Gateways and ITS To: KLH@MIT-MC cc: CENT@MIT-MC, MOON@MIT-MC, DCP@MIT-MC, baldwin@MIT-XX, dclark@MIT-XX, ai-kl@MIT-OZ, JNC@MIT-XX I agree with your analysis of the importance of this; finding the machine is the hardest step. I do think that not having a specialized hand-built frob in the machine is a major advantage to not connecting to the ARPANet, although other considerations (e.g. bandwidth (to IP machines at MIT, etc)) do come in. Two quick points about network related stuff (if you aren't interested in networks, skip the rest of this). All hosts are supposed to get their routing info from ICMP Redirects and only from Redirects; they use these to maintain a cache of routes to gateways for machines not on their local net that they are currently talking to. This should be true whether you're connected to the ARPANet or some local net. The whole point of splitting ICMP off from GGP/EGP/SGP was that the hosts are insulated from changes in the routing algorithms. The cache thing is pretty simple to implement too. Packets on a new connection to a host not in the table get sent to any random gateway in the table; he'll tell you where to send them. I agree that flow control in the InterNet over multi-hop paths of wildly varying delay and bandwidth is an unsolved problem of some magnitude. This has been showing up since the earliest days of SatNet (ca 1978), and while we don't have a solution, we have a much better understanding of the problem now and I would suspect that considerable progress will soon be made. [ For instance, we used to think that the hosts should do 'traffic control' (we use this term to distinguish flow control for network wide reasons from flow control at the two hosts on the connection) using measured round-trip delay and setting the TCP window. Much experimentation with this has convinced us that this is incorrect (the traffic window should depend on the bandwidth of the link as well as the delay, and it's impossible to measure that directly from the host; the only way to do it is to step up the data rate until you start to experience greater delays, or some equally indirect kludge which often has loop stability problems), and that to do so overloads the TCP window mechanism in any case. So we're back to the drawing boards, but I think this time we understand enough to do it right. It will probably involve the gateways (which really do know the state of their links and buffer pools, etc) and Source Quenches, but the algorithm in the gateways will be a little more complicated, so that it can do real traffic control (i.e. slow things down as you near the useful limit) instead of 'congestion control' (which is what you do when you go into overload). Also, the whole interface between TCP and IP needs to be revamped to allow this sort of flow control info to flow between the two layers; this is the point of Dave Clark's 'UpCall' programming style for network protocols. I forget the IEN no, but it's a must to read. The newer IP/TCP implemetations at MIT (e.g. for SWIFT) use this model. ] Actually, MC almost certainly has traffic control problems now, if you're talking to machines on a fast (e.g. ProNet) or slow (e.g. SatNet) net, but since most of you aren't you don't see it. In the first case, packets get thrown away now on the gateway into the ARPANet; in the second, they get thrown away in the gateway off the ARPANet. 'Large network systems are unfortunately never very simple.' Anyway, enough flaming about networks. Noel Return-path: Date: 13 August 1983 18:55 EDT From: David C. Plummer Subject: working.... To: CENT @ MIT-ML cc: JNC @ MIT-ML, DCP @ MIT-ML, ai-kl @ MIT-OZ, Moon @ SCRC-TENEX Date: Saturday, 13 August 1983, 16:52-EDT From: David A. Moon Date: 12 August 1983 02:46 EDT From: Pandora B. Berman also, noel was wondering who besides you and DCP can competently hack code in the front-end 11. I don't know of anyone. I'd be willing to help, time permitting. I'm willing as well, but I don't claim competency with IOELEV. I've looked at it and XNETWK (the originaly 20X chaos NFE, which in theory is based on parts of IOELEV). Making it understand an Interlan (which I assume would be the plan) probably isn't impossible. The harder questions are more like: Will it be supporting disks like MC's IO-11? Will it talk over a DL-10 or will it use a DTE? If putting Ethernet and minimal IP in IOELEV poses a problem, perhaps you should budget for another 11. Return-path: Date: 13 August 1983 18:20 EDT From: Ken Harrenstien Subject: Gateways and ITS To: JNC @ MIT-XX cc: KLH @ MIT-MC, CENT @ MIT-MC, MOON @ MIT-MC, DCP @ MIT-MC, baldwin @ MIT-XX, dclark @ MIT-XX, ai-kl @ MIT-OZ I am curious to know what is going on with this hypothetical AI KL project, but this message is really about gateways. One other advantage of using a gateway to access the Arpanet is that you can let the gateway worry about routing, i.e. the gateway serves as an intelligent interface to the network and takes on the burden of deciding where packets should optimally be sent. The code to do this sort of thing tends to be rather hairy and unpleasant to work with, and a situation where a machine has only one gateway to worry about can actually be considered a boon in this respect. Of course, the gateway had better be as reliable as possible, and it should ideally be a "prime" gateway itself which participates in the Internet gateway gossip protocol. Or you will have a lot of frustrated ICMP redirects. On the other hand, using a high speed local link to the gateway means that flow control is apt to be a problem; packets can pile up at the gateway much faster than they can be sent through the arpanet. ITS IP does not implement the source quench feature. Since the Arpanet tends to be slower (due to bandwidth and RFNM wait blocking; ITS does count RFNMs) than most local nets, and the Arpanet is the first step outward from MC or ML, this has not really been a problem up to now. But when it is possible to zap out packets as fast as they are created, I won't be surprised to see a very high rate of packet lossage at the gateway unless it and ITS agree on some way to throttle the flow. ICMP should work, it just needs to be further implemented. Anyway, I suspect it is much easier to deal with stuff hung off the IO-11 unibus than with a custom KL-UDGE circuit. Certainly if it is possible to get another KL ITS for AI, the question of whether to try hooking it to an IMP or a local IP net is an extremely minor point compared with all the other issues involved. Do whatever is easiest (politically and financially). Return-path: Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Sat 13-Aug-83 16:54:27-EDT Date: Saturday, 13 August 1983, 16:52-EDT From: David A. Moon Subject: working.... To: Pandora B. Berman Cc: ai-kl@MIT-OZ, JNC@MIT-ML, DCP@MIT-ML In-reply-to: The message of 12 Aug 83 02:46-EDT from Pandora B. Berman Date: 12 August 1983 02:46 EDT From: Pandora B. Berman dave, how much trouble would it be to bring up ITS on a KL that doesn't have RP04s? would it be easier to drag one of MC's disks over for a while to start things up than to arrange for dealing with some other variety of disk? would it be easier to hack with tapes? Dragging one of MC's disks anywhere is not a good idea. The best approach is probably to use tapes to bring the salvager over, then use the salvager's facility for building a file system from dump tapes. The salvager, ddt, and ITS would all need modifications to handle different disks, but they aren't difficult. There are a number of strange oddities in the KL file system, having to do with the front-end 11. I would be willing to help out. also, noel was wondering who besides you and DCP can competently hack code in the front-end 11. I don't know of anyone. I'd be willing to help, time permitting. Return-path: Date: 8 Aug 1983 1820-EDT From: J. Noel Chiappa Subject: Re: working.... To: CENT@MIT-ML, MOON@MIT-ML, ai-kl@MIT-OZ cc: DCP@MIT-ML, JNC@MIT-XX In-Reply-To: Your message of 12-Aug-83 1748-EDT A slight typo in the last message. The number for bytes through the gateway are off by 10 (in case you wondered why the average message size was 6 bytes!) They are 332.9 MBytes in and 297.1 MBytes out. ------- Return-path: Date: 12 Aug 1983 1748-EDT From: J. Noel Chiappa Subject: Re: working.... To: CENT@MIT-ML, MOON@MIT-ML, ai-kl@MIT-OZ cc: DCP@MIT-ML, JNC@MIT-XX In-Reply-To: Your message of 12-Aug-83 0246-EDT BTW, I took a look into the gateway to check its traffic figures. Since the last reload (23 days ago) it has received 4.5 million packets (33.3 Mbytes) and sent 5.2 million (29.7 Mbytes). That's about 200K packets a day. By constrast, MC (in 51 hours) has received 821 thousand packets and sent 784 thousand, or about 400K packets a day. ML (in 79 hours) has received 270 thousand and sent 343 thousand, or about 100K packets a day. So the gateway can definitely handle quite a good load, and in addition is seen to be quite robust. ------- Return-path: Date: 12 Aug 1983 0400-EDT From: J. Noel Chiappa Subject: Re: working.... To: CENT@MIT-ML, MOON@MIT-ML, ai-kl@MIT-OZ cc: DCP@MIT-ML, JNC@MIT-XX, dclark@MIT-XX, baldwin@MIT-XX, klh@MIT-MC In-Reply-To: Your message of 12-Aug-83 0246-EDT The problem is not the gateway, but the ARPANet. The identical C-GateWay (CGW) software and hardware configuration (albeit an 11/23 in place of the 11/03) with DMA interfaces to the ProNet (LCSNet ring) and EtherNet has almost 1MBit/Sec bandwidth, so the machine itself can really zap those little bits out. The real bottleneck is the ARPANet port. To some degree the limiting factor here is in the IMP software; the DMA 1822 (IMP<->Host) interface on the machine has more than enough bandwidth to absorb both phone lines out of MIT (56KBit/sec on each of them) by itself. The whole problem of getting sufficient bandwidth through the ARPANet stems from the ancient design on the IMP-Host protocol, which is a hangover from the days of NCP. (The problems MC has been having recently with IMP blocking are an example of this. Each host is only allowed to have so many packets outstanding to another host, at which point the IMP will refuse to take any more at all; the problem is that the number which will trigger this is not a constant, but depends on the network load and the load on the IMPs at each end, and there's no way for the host software to find out at any instant what it is.) It includes many features that get in the way of an efficient TCP, but were necessary for NCP, e.g. reliable sequenced packet streams, etc. The problem is that the network wide congestion and traffic flow algorithms were designed to work with this type of traffic, and so changing the interface means more than just reprogramming the host interface; the resource control algorithms in the network must be redone. As you might expect, this is a complicated task. The 'Non Blocking Host Interface' (see your 1822 spec) has been in design for a while now, but there's still no sign in sight. On the short term, there are several things we can do, including some incredible hacks, to increase the bandwidth through that machine to the ARPANet. First off, we need to finish off the final bell in the ARPANet software, which is to count RFNM's (ignore the rest of this if the jargon threw you) and hang on to packets which are guaranteed to cause the interface to block. We left this out at the start, in the rush to get something running, but I think this is starting to hit us now. It certainly needs to be completed before the ARPANet driver for the CGW is done. I have just implemented a cache manager which should make it very easy to do this. Past that, we get into a bunch of gorgeous hacks that are impossible to pull with a machine directly connected to the ARPANet, but which are possible for a gateway. Basically, you just plug in more IMP ports to the same machine. The current ARPANet software for the CGW will handle multiple ARPANet interfaces (this feature was originally to interface between the ARPANet and one of its clones; BRL uses this); only a small intermediate layer between IP and the network layer needs to be written to spread the packets out. You can split your transmit traffic between them trivially, since the hosts or gateways at the far end don't care what the ARPANet address of the sender is. Splitting receive traffic is a little more complicated, but fairly easy. (It's also impossible with a directly connected host.) Basically, machines on the ARPANet that aren't gateways are redirected to the secondary IMP interface with an ICMP Redirect, which everyone is supposed to implement now. (You can't do this to gateways because the use a second protocol to find out where the all are, and this would confuse them, but it works just fine with hosts, since the gateway they are talking to is allowed to send them Redirects; it would take no software changes to any hosts at all.) You can just add interfaces until we can soak up the entire 112 KBit/sec out of MIT with one machine. This brings me to a final point; MIT is scheduled to get a 3MBit/sec satellite link 'soon'. Needless to say, its direct connection will be to some local net here, not the ARPANet. The only way to get anything like that bandwidth out of it would be to talk through local nets exclusively. So I guess the answer is basically 'yes'. If anything I said was confusingly detailed (or glossed over) let me know and I'll go over it in more detail. ------- Return-path: Date: 12 August 1983 02:46 EDT From: Pandora B. Berman Subject: working.... To: MOON @ MIT-ML, ai-kl @ MIT-OZ cc: JNC @ MIT-ML, DCP @ MIT-ML noel suggested a place for marty to look for KL price quotes. dave, how much trouble would it be to bring up ITS on a KL that doesn't have RP04s? would it be easier to drag one of MC's disks over for a while to start things up than to arrange for dealing with some other variety of disk? would it be easier to hack with tapes? also, noel was wondering who besides you and DCP can competently hack code in the front-end 11. noel, about your idea of hanging things together: arpa--gateway11--ethernet--newAI's11--newAI(--newAI's11--chaos) <----------TCP/IP---------------------/ \----chaos protocol---> how much load is that gateway going to be able to take? will it REALLY take everything an ITS KL (with lots of ai people furiously sending mail and connecting to arpa sites all over) can dish out?