Copyright (c) 1999 Massachusetts Institute of Technology This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ------------------------------ Date: Fri, 16 Sep 88 00:16:04 EDT From: Peter Lothberg Subject: The "crack team", is dissasembling MX, for it's trip to Sweden To: INFO-ITS@AI.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU Message-ID: <444460.880916.ROLL@AI.AI.MIT.EDU> The crack team has begun to work; A lot of the documentation for MX (KL-10) must be spread out, i can't find it around the machine. So all of you that has bits and pices, bring it to the 9:th floor before sunday, please. (As the system will not fill the container more than 40% or so, we vold like donations of other stuff, like Lisp-machines, AAA terminals, a IMP, Conection machines, retired 2060's etc, (I'm not joking...)) -Peter  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 11 Sep 88 22:29:39 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 11 Sep 88 22:25:00 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 457530; 11 Sep 88 22:24:20 EDT Date: Sun, 11 Sep 88 22:22 EDT From: David A. Moon Subject: Synchronicity To: poor-mx@mc.lcs.mit.edu Message-ID: <19880912022232.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> In T.I. land, MX means microExplorer. Enough said.  Date: Fri, 9 Sep 88 17:47:53 EDT From: "Pandora B. Berman" Subject: in case you missed it To: POOOR-MX@AI.AI.MIT.EDU Message-ID: <440424.880909.CENT@AI.AI.MIT.EDU> MSG: MX ADIEU DISTRIB: *MD, *ML, *MC, *AI EXPIRES: 09/23/88 21:39:25 CENT@AI.AI.MIT.EDU 09/08/88 21:39:25 Re: The end of the world as we used to know it "The time has come," said LCS, "MX at last must go. Its day has gone. We need that space Most urgently." And so Before we crate it, let us give A final cheerio. Once there was a KL-10 called MIT-MC which belonged to the Macsyma Consortium. It provided Macsyma, the symbolic algebra system, to researchers all over the world, and mail gatewaying and mailing list support to a large fraction of the Arpanet. Things continued in this fashion from 1975 to 1983. When the Macsyma Consortium dissolved in 1983, MC turned to providing cycles for MIT's Laboratory for Computer Science, and continued supporting much of the Arpanet's mail service. But the machine itself was growing old and cranky. In 1986, the mail services were moved to a smaller, more maintainable machine (a KS-10), and the name "MC" was moved with them. But the KL-10 continued to run under the new name "MX". Now the end has come. MX was down cold for several months, and has only been revived recently to copy some old 7-track tapes. LCS can't keep MX any longer -- it needs the space for other purposes. So the KL is being sent to the Home for Aged But Beloved PDP-10s; a crack team of hardware hackers will arrive next week to dismantle it and take it back with them to Sweden. In celebration of this momentous event, we are holding a small farewell gathering: Friday, 16 September 1988 16:00 NE43-8th floor playroom (545 Technology Square, Cambridge, MA) Reservations are strenuously requested (though not strictly necessary) -- we need a head count so we can figure out how many trays of institutional brownies to order. Send yours to: CENT@AI.AI.MIT.EDU Offers of refreshement are also very welcome -- do you think we have any budget for this kind of thing? Send all such offers also to CENT as above. ^_  Received: from XN.LL.MIT.EDU (TCP 1200400012) by AI.AI.MIT.EDU 8 Aug 88 12:00:30 EDT Received: by XN.LL.MIT.EDU; Mon, 8 Aug 88 11:57:23 EDT Date: Mon, 8 Aug 88 11:57:23 EDT From: rp@XN.LL.MIT.EDU (Richard Pavelle) Posted-Date: Mon, 8 Aug 88 11:57:23 EDT Message-Id: <8808081557.AA09526@XN.LL.MIT.EDU> To: poor-mx@AI.AI.MIT.EDU Subject: Removal date for KL from MIT Posted-Date: Fri 5 Aug 88 18:49:28-EDT Date: Fri 5 Aug 88 18:49:28-EDT From: Rob Austein Moon pointed out that I should have sent copies to a couple other people, so here's a copy for the official fan club. I would like to propose that those on this mailing list (and others who care) get together before the permanent demise of mx=mc and wish it farewell. Many years of work went into that machine and many careers came out. I was connected to mx for more than 20,000 hrs, and it changed my life. I am sure others have similar feelings. What do you MXers say about this?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 5 Aug 88 18:53:37 EDT Date: Fri 5 Aug 88 18:49:28-EDT From: Rob Austein Subject: [Rob Austein : Removal date for KL from MIT] To: poor-mx@AI.AI.MIT.EDU Message-ID: <12420107736.29.SRA@XX.LCS.MIT.EDU> Moon pointed out that I should have sent copies to a couple other people, so here's a copy for the official fan club. --------------- Mail-From: SRA created at 5-Aug-88 17:18:09 Date: Fri 5 Aug 88 17:18:09-EDT From: Rob Austein Subject: Removal date for KL from MIT To: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU, ROLL@KICKI.STACKEN.KTH.SE cc: sra@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU Message-ID: <12420091113.29.SRA@XX.LCS.MIT.EDU> I just got out of a meeting where we were discussing plans for various renovations at LCS. You should know that we have a big-name researcher moving into LCS from another part of MIT. This has top priority with our front office people, and the deadlines for it are tight. To make a long story short, we have the following situation. As you know, we need the KL for long enough to finish copying the Macsyma tapes from 7-track to 9-track tape. The official estimate of when that will finish is sometime between 31 August and 15 September. The actual date is unknown, since the project depends heavily on hardware that is known to be flakey; Penny is doing a heroic job but it may simply not be possible to finish the job on schedule. The renovation plans are going to require that the KL be gone by the end of September. The need for the floorspace is bad enough that it is my estimation that if the tape copying isn't done in time, it will be left incomplete rather than extend the deadline. I could be wrong about this. Enough other things are depending on having the KL gone that, if you guys can't come over here and handle the disassembly, the machine will be removed anyway and shipped to a warehouse somewhere. Management is aware that disassembly by people who don't understand the machine may well mean that it will never run again; they don't care about this enough to offset their need for the floorspace. None of the MIT ITS people are going to have time to handle the disassembly (I know that JTW and I won't and I'm virtually certain that Moon and Bawden won't either). MIT is not willing to pay what it would cost to have DEC do the de-installation (we estimate this as being in the thousands of US dollars). Tom Greene tells me that you would prefer to do the job in November. Hence this letter, to tell you that if you wait that long you will probably not get a working machine out of the deal. I realize that this puts you in a bad position, since we can't even tell you when the tape work will be done with any degree of certainty. Our best guess of when we need you guys over here starting the deinstallation is 19 September. We can't put it off much after that. How likely is it that you can do this? --Rob ------- -------  Date: Mon, 28 Sep 87 00:20:04 EDT From: David Vinayak Wallace Subject: OLD magtape heads To: ME@SAIL.STANFORD.EDU cc: ALAN@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, BERLIN@XX.LCS.MIT.EDU, TY@XX.LCS.MIT.EDU In-reply-to: Msg of 25 Sep 87 1540 PDT from Martin Frost Message-ID: <261147.870928.GUMBY@AI.AI.MIT.EDU> Date: 25 Sep 87 1540 PDT From: Martin Frost Our drives, by the way, date from about 1966. This year's freshmen were born in 69 and 70.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 SEP 87 06:19:11 EDT Date: Sun, 27 Sep 1987 06:10 EDT Message-ID: From: RP%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: POOR-MX@AI.AI.MIT.EDU Subject: Tomorrows news In-reply-to: Msg of 1 Sep 1987 07:27-EDT from Alan Bawden Date: Tuesday, 1 September 1987 07:27-EDT From: Alan Bawden To: POOR-MX at AI.AI.MIT.EDU Re: Todays news Yesterday MX ate part of the DRAGON directory and -all- of the .MAIL. directory. Presumably this is caused by more of the blocks-of-zeros lossage. I didn't bother to bring ITS back up, since I didn't see any reason to destroy more of the filesystem without fixing the hardware problem. ... It has almost been a month since Alan's message. Have there been any further attempts to fix the hardware problem. I have nothing to contribute to the effort, but I certainly would like to see my favorite machine alive and useful again.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Sep 87 19:51:03 EDT Date: 25 Sep 87 1540 PDT From: Martin Frost Subject: re: old magtape heads To: Alan@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA, TY@XX.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU, BERLIN@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU CC: ME@SAIL.STANFORD.EDU I appreciate your searching for magtape heads that we might be able to use. Sorry I haven't responded earlier to the recent flurry of messages about your search, but I went on vacation last week on the day before the first of these messages and just got back. No, we haven't found any heads to use in our drives. We had a couple of close calls, but the heads that were located were for different tape speeds, and our experience indicates that such heads don't work (we had one such spare ourselves and were disappointed to discover the incompatibility). We have, however, now sent out one set of heads to be remanufactured. They say that the result will be heads better than new (harder heads), and I'm hoping they're right (and that they can reconstruct the heads precisely enough). So, feel free to discontinue your search, but on the other hand, if you did turn up a set of heads in reasonable shape that would work, I think we would still be interested in them. If you find a potential set of such heads, just check the part number on the heads -- if it is Datamec 10400-9S, then it's a winner. I have to assume that heads made by anyone else wouldn't work, unless they were definitely for 7-track 45-ips drives. Our drives, by the way, date from about 1966.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 25 Sep 87 17:59:09 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 59630; Fri 25-Sep-87 11:29:05 EDT Date: Fri, 25 Sep 87 11:29 EDT From: Alan Bawden Subject: [Martin Frost : old magtape heads ] To: Moon@STONY-BROOK.SCRC.Symbolics.COM, me@SAIL.STANFORD.EDU cc: CENT@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU, BERLIN@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU In-Reply-To: <870921152108.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870925112905.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 21 Sep 87 15:21 EDT From: David A. Moon Date: Fri, 18 Sep 87 14:10:21 EDT From: Alan Bawden Date: Thu, 17 Sep 87 20:45:06 EDT From: Pandora B. Berman the old mc, now mx, retains its drive (not a tu20, nor a 45, perhaps JTW can cons up the variety) as long as we have any hope of reviving it. good luck with hunting elsewhere or remanufacture. I don't know what this drive is called by DEC (there is nothing inscribed on the cabinet), but I think that it was actually manufactured by IBM. It's the 7-track version of the TU40, possibly called TU41, and it was manufactured by Mohawk Data Sciences. We have, if we haven't lost them, a set of MDS manuals for it (fat blue ring-bound notebooks). It needs both a TM10B and a DF10 for interfacing. Yeah, I found this documentation in the cabinet (since your description let me to know what to look for). Apparently it is just called a TU40, although it is of the 7-track variety. I don't seem to be able to find anything that tells me anything about the heads though. (It -must- be there somewhere...) I notice that we haven't heard a peep out of SAIL since we started this conversation. Perhaps they already found a set of heads?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Sep 87 16:51:23 EDT Date: Mon 21 Sep 87 16:42:40-EDT From: J. J. Tyrone Sealy Subject: Re: [Martin Frost : old magtape heads ] To: Moon@SCRC-STONY-BROOK.ARPA cc: ALAN@AI.AI.MIT.EDU, me@SAIL.STANFORD.EDU, CENT@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU, BERLIN@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU In-Reply-To: <870921152108.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12336460717.23.TY@XX.LCS.MIT.EDU> We still have one of the TU20's in the basement. I don't know what the specs are for the thing. It is a 7-track drive and yes the controller is still attached. It was to be kept around in case anyone wanted to read the old ITS tapes. What plans LCS have for it now ??? ( TJG could answer) I will try to find the specs on the head and see if they match yours.. -------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 21 Sep 87 15:28:27 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 237764; Mon 21-Sep-87 15:21:53 EDT Date: Mon, 21 Sep 87 15:21 EDT From: David A. Moon Subject: [Martin Frost : old magtape heads ] To: Alan Bawden , me@SAIL.STANFORD.EDU cc: CENT@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU, BERLIN@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU In-Reply-To: <256807.870918.ALAN@AI.AI.MIT.EDU> Message-ID: <870921152108.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 18 Sep 87 14:10:21 EDT From: Alan Bawden Date: Thu, 17 Sep 87 20:45:06 EDT From: Pandora B. Berman the old mc, now mx, retains its drive (not a tu20, nor a 45, perhaps JTW can cons up the variety) as long as we have any hope of reviving it. good luck with hunting elsewhere or remanufacture. I don't know what this drive is called by DEC (there is nothing inscribed on the cabinet), but I think that it was actually manufactured by IBM. It's the 7-track version of the TU40, possibly called TU41, and it was manufactured by Mohawk Data Sciences. We have, if we haven't lost them, a set of MDS manuals for it (fat blue ring-bound notebooks). It needs both a TM10B and a DF10 for interfacing.  Date: Fri, 18 Sep 87 14:10:21 EDT From: Alan Bawden Subject: [Martin Frost : old magtape heads ] To: CENT@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU, me@SAIL.STANFORD.EDU, BERLIN@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU In-reply-to: Msg of Thu 17 Sep 87 20:45:06 EDT from Pandora B. Berman Message-ID: <256807.870918.ALAN@AI.AI.MIT.EDU> Date: Thu, 17 Sep 87 20:45:06 EDT From: Pandora B. Berman Date: 07 Aug 87 1743 PDT From: Martin Frost ... sorry marty -- as you've noticed, the heads are what go. DM and the old AI and ML machines had tu20s, and there were a few extra tu20s in the basement, principally for cannibalizing heads from. the old AI's and ML's heads were in pretty bad shape when those machines went down the tubes (i should know, i was dumping them), and DM probably had the same problems -- perhaps to a lesser extent because it was actually on maint. contract for much of its life, but it disappeared into the depths around 3 years ago. Actually, DM had a 9-track drive. perhaps someone could talk gerry brown (the lcs stockroom guru and boss of the storage areas) into letting him poke around in the lcs basement rooms to see whether dm's drive is still around -- but it's pretty chancy. most of the old ai lab junk was trashed, or at least went into very deep storage (a warehouse somewhere) when the lab was gifted with marc raibert last year, because raibert needed the ai basement storage for his hopping robots lab, so there's no hope on our side. the old mc, now mx, retains its drive (not a tu20, nor a 45, perhaps JTW can cons up the variety) as long as we have any hope of reviving it. good luck with hunting elsewhere or remanufacture. I don't know what this drive is called by DEC (there is nothing inscribed on the cabinet), but I think that it was actually manufactured by IBM.  Date: Thu, 17 Sep 87 20:45:06 EDT From: "Pandora B. Berman" Subject: [Martin Frost : old magtape heads ] To: me@SAIL.STANFORD.EDU cc: POOR-MC@AI.AI.MIT.EDU, BERLIN@XX.LCS.MIT.EDU, tjg@XX.LCS.MIT.EDU Message-ID: <256437.870917.CENT@AI.AI.MIT.EDU> Date: Sat 8 Aug 87 19:12:30-EDT From: Steve Berlin Subject: [Martin Frost : old magtape heads ] To: tjg@XX.LCS.MIT.EDU, sra@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU, cent@OZ.AI.MIT.EDU cc: me@SAIL.STANFORD.EDU I don't know who might have an answer to this question - but I don't know what hardware we have sitting around... --------------- Date: 07 Aug 87 1743 PDT From: Martin Frost Subject: old magtape heads To: berlin@XX.LCS.MIT.EDU Hi, Steve. We're looking for some replacement magtape heads for our old 7-track tape drives, and someone here said there were some old tape drives (and other computer stuff) in the basement of the MIT AI lab building. I wonder if you could check for us, or maybe ask someone else there to check this out. What we have are DEC 545 7-track 45 ips drives, which are really Datamec D2020 drives, and the heads are Datamec catalog number 10400-9S (stamped on the head assembly). All we need is the head assembly. Our heads are pretty worn and now we want to read some 2700 old tapes to convert them to 9-track tapes. So if there are the same heads sitting there no longer being used (or better, unused spares sitting around), then we could certainly make good use of them. If there are the same heads there but they are well worn (noticeable groove cut into the head by the tape), then they're probably not useful to us. The heads would have to be for a 45-ips drive to work for us. If we can't find any spare heads, we'll have our heads remanufactured. But if you can find out anything for us, I'd certainly appreciate it. Thanks. sorry marty -- as you've noticed, the heads are what go. DM and the old AI and ML machines had tu20s, and there were a few extra tu20s in the basement, principally for cannibalizing heads from. the old AI's and ML's heads were in pretty bad shape when those machines went down the tubes (i should know, i was dumping them), and DM probably had the same problems -- perhaps to a lesser extent because it was actually on maint. contract for much of its life, but it disappeared into the depths around 3 years ago. perhaps someone could talk gerry brown (the lcs stockroom guru and boss of the storage areas) into letting him poke around in the lcs basement rooms to see whether dm's drive is still around -- but it's pretty chancy. most of the old ai lab junk was trashed, or at least went into very deep storage (a warehouse somewhere) when the lab was gifted with marc raibert last year, because raibert needed the ai basement storage for his hopping robots lab, so there's no hope on our side. the old mc, now mx, retains its drive (not a tu20, nor a 45, perhaps JTW can cons up the variety) as long as we have any hope of reviving it. good luck with hunting elsewhere or remanufacture.  Date: Tue, 1 Sep 87 07:27:11 EDT From: Alan Bawden Subject: Todays news To: POOR-MX@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <248911.870901.ALAN@AI.AI.MIT.EDU> Yesterday MX ate part of the DRAGON directory and -all- of the .MAIL. directory. Presumably this is caused by more of the blocks-of-zeros lossage. I didn't bother to bring ITS back up, since I didn't see any reason to destroy more of the filesystem without fixing the hardware problem. (.MAIL. really is totally gone. It looks like the part of the directory containing all of the file blocks got zeroed, and then ITS ran for a wrile while mail servers created new MAIL > files. There is also a STATS 1 file, although I can't imagine how COMSAT could have continued to run for long with an empty directory.)  Date: Mon, 31 Aug 87 01:00:54 EDT From: Alan Bawden Subject: the last 32 words in a block To: POOR-MX@AI.AI.MIT.EDU cc: MAGIC-DRAGON-KEEPER@MX.LCS.MIT.EDU In-reply-to: Msg of Mon 31 Aug 87 00:14:15 EDT from Puff the Magic Dragon Message-ID: <248464.870831.ALAN@AI.AI.MIT.EDU> Date: Mon, 31 Aug 87 00:14:15 EDT From: Puff the Magic Dragon To: MAGIC-DRAGON-KEEPER at MX The file DSK:CHANNA;LOGOUT TIMES seems to be clobbered. Please check it. The offensive material follows: The "offensive material" consisted of exactly 32 words containing 0 that had replaced the last 32 words in a disk block.  Date: Mon, 24 Aug 87 17:46:27 EDT From: "Michael A. Patton" Subject: Follow up to Wroclawski's message To: POOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Sun 23 Aug 87 00:38:54 EDT from John T. Wroclawski Message-ID: <245828.870824.MAP@AI.AI.MIT.EDU> We looked at, but didn't actually get around to fixing the DH lines. Now that the power supply is back up, we should organize a DH fixing party. It shouldn't take to much effort to arrange to have one working (and one doubly broken) DH and get the dialups active again. -Mike  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 23 Aug 87 00:40:19 EDT Date: Sun, 23 Aug 87 00:38:54 EDT From: "John T. Wroclawski" To: poor-mx@AI.AI.MIT.EDU Message-ID: <981373.870823.JTW@MX.LCS.MIT.EDU> Well. Once again the KL is running. In the last month various people have repaired: The console PDP-11 The RP04s The DH11 modem TTY lines The main CPU power supplies. Maybe that will keep it going for a little while longer.  Date: Thu, 6 Aug 87 08:31:17 EDT From: Ray Hirschfeld Subject: mail to MX To: POSTMASTER@AI.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU Message-ID: <238592.870806.RAY@AI.AI.MIT.EDU> I took MX out of the *ITS and *BBOARD lists because I'm sick of seeing duplicate messages. People seem to assume that their whole message failed when they get a failure message about MX, and resend it. Because of the way it was defined, I removed *MX as well. I made the change on AI, MC, and ML. MD seems to be down at the moment. Ray  Date: Thu, 30 Jul 87 15:26:11 EDT From: "Michael A. Patton" Subject: The losing console To: JTW%MIT-SPEECH@XX.LCS.MIT.EDU cc: POOOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Wed 29 Jul 87 01:32:25-EDT from John Wroclawski Message-ID: <235289.870730.MAP@AI.AI.MIT.EDU> I noticed several LA36s over near where the dover used to be. Does anybody know who belongs to these or what there condition is? It would be a shame to lose because of a busted terminal.  Date: Wed, 29 Jul 87 11:09:08 EDT From: "John T. Wroclawski" To: POOOR-MX@AI.AI.MIT.EDU Message-ID: <234614.870729.JTW@AI.AI.MIT.EDU> From: "John Wroclawski" Subject: Re: The origin of this message I rewired the machine some to move things from the power supply fed by CB9 to an unused one fed by CB10. ITS is running; if either CB9 or CB10 blows, i guess it would make sense to leave it down till we can try something else. Oh well, I should have disconnected it completely. The power supply in question, apparently pissed off by its unceremonious removal from service after all these years, has retaliated in dramatic fashion. Those of you who remember Guttag's VAX... I think things can be fixed, but it will take an evening. In the meantime, the machine is off.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 87 01:36:35 EDT Date: Wed 29 Jul 87 01:32:25-EDT From: "John Wroclawski" Subject: Re: The origin of this message To: alan@AI.AI.MIT.EDU, pooor-mx@AI.AI.MIT.EDU In-Reply-To: <233018.870726.ALAN@AI.AI.MIT.EDU> Message-ID: <12322139234.8.JTW@MIT-SPEECH> From: Alan Bawden Subject: The origin of this message ... I left it down because I figured that we should make an attempt to discover just -why- that breaker keeps tripping before further shocking the machine by cycling its power. I rewired the machine some to move things from the power supply fed by CB9 to an unused one fed by CB10. ITS is running; if either CB9 or CB10 blows, i guess it would make sense to leave it down till we can try something else. It will come as no surprise to anyone that the CPU doesn't quite match the prints... If someone who has a handy can of WD40 would spray it all over the console head motion mechanism, it would be a Good Thing. -------  Date: Sun, 26 Jul 87 14:57:02 EDT From: Alan Bawden Subject: The origin of this message To: POOOR-MX@AI.AI.MIT.EDU, JBVB@AI.AI.MIT.EDU In-reply-to: Msg of Sat 25 Jul 87 22:56:10 EDT from James B. VanBokkelen Message-ID: <233018.870726.ALAN@AI.AI.MIT.EDU> Date: Sat, 25 Jul 87 22:56:10 EDT From: James B. VanBokkelen Fondling the console 11 has restored function to most of it, but not the dialup lines on the DH.... Much thanks for your assistance! The bad news, folks, is that this problem with Circuit Breaker 9 on the power supply blowing out continues to happen. MX managed to run from about 11 last night until about 5 this morning, before that breaker tripped. I left it down because I figured that we should make an attempt to discover just -why- that breaker keeps tripping before further shocking the machine by cycling its power.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 25 Jul 87 22:59:05 EDT Date: Sat, 25 Jul 87 22:56:10 EDT From: "James B. VanBokkelen" Subject: The origin of this message To: POOOR-MX%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <981282.870725.JBVB@MX.LCS.MIT.EDU> Fondling the console 11 has restored function to most of it, but not the dialup lines on the DH. We did manage to find appropriate 11-based diagnostics for the DH, and they report both of them to be bad, the first (dialup & ??) worse than the 2nd. See the console printout for details. MAP and Alan are planning to rearrange lines & hardware addresses on the DHs to get dialup working sometime next week. It is hoped that the problem on the 2nd DH11 is so minor that IOELEV won't ever notice it..... jbvb  Date: Fri, 24 Jul 87 16:20:03 EDT From: "Michael A. Patton" Subject: A laying on of hands for the PDP-11 To: POOOR-MX@AI.AI.MIT.EDU Message-ID: <232199.870724.MAP@AI.AI.MIT.EDU> JBVB and I are planning on applying a laying on of hands to the MX front end PDP-11 bright and early Saturday Afternoon (probably around 1?). If we get the PDP-11 running it might be useful to have a more experienced ITS/PDP-10 person around when we try to bring it up. We will be collecting are spells (prints) and magic wands (tools) this evening (at TMRC and elsewhere), and will be in tomorrow to perform rituals around the dead machine in an attempt to resurrect it. Anyone who wishes to help (or to offer sacrifices) is encouraged to attend. -Mike Patton  Date: Sat, 11 Jul 87 19:37:50 EDT From: Alan Bawden Subject: Front End PDP11 Kaput To: POOOR-MX@AI.AI.MIT.EDU, JBVB@AI.AI.MIT.EDU Message-ID: <226404.870711.ALAN@AI.AI.MIT.EDU> The KL's front end PDP11 (the "console 11") is broken. When we powered up the machine last night, it was unable to boot from disk. It was able to boot from DECtape, so Moon poked around (using KLDCP) to try and figure out if something was wrong with its RH11. Halfway through this process, the 11 stoped working completely. You can deposit stuff in memory from the switches and read it back, and you can get the boot-from-DECtape program (stored in some kind of read-only memory) to run. But as soon as you try to execute any instructions from real memory, you generally discover that the real memory contains gubbish. Moon and JTW pulled the 11 out of the cabinet and poked around with a volt meter to see if there were any obvious problems, but found nothing. At this point the meeting was adjourned. Recall that the dialups haven't been functioning for some time now, and that they are also attached to the console 11. Also the console LA36 has occasionally been uncooperative, although reloading the 11 generally fixed that immediately. I personally suspect some kind of slow Unibus rot. I wonder if there is any signifigance to the fact that the dialup interface is at the far end of the Unibus (in the extension cage on the other side of the processor bays)? Perhaps its time for some PDP11 hackers to emerge to save the day?  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 27 Jun 87 20:52:27 EDT Date: Sat, 27 Jun 87 20:48:21 EDT From: Alan Bawden Subject: Guess what! To: Pooor-MX@AI.AI.MIT.EDU Message-ID: <980457.870627.ALAN@MX.LCS.MIT.EDU> That's right, the KL is running again. (JTW cleaned some contacts in the RP06.)  Date: Sun, 21 Jun 87 14:20:57 EDT From: Alan Bawden Subject: Unit #2 cranky To: POOOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Sat 20 Jun 87 18:24:01 EDT from Communications Satellite Message-ID: <217648.870621.ALAN@AI.AI.MIT.EDU> Date: Wed, 17 Jun 87 17:01:22 EDT From: Alan Bawden ... With two of three RP04's offline it becomes difficult, although probably not impossible to bring ITS back up again. Before anyone tries that, it might be a good idea to see if any diagnostics can find the problem. I made a half-hearted attempt to bring MX up again the other night, but quickly became discouraged. Any given file has a 50% chance of being unavailable, which makes the undertaking quite an interesting game of chance. Luckily the most recent version of ITS itself is sitting on pack #0, and luckily there is a version of Exec DDT on Pack #0 as well, and there is even a file in the front-end-filesystem that knows how to load it up (its not a regular .CMD file though, so you have to type in a few commands by hand...) The salvager dumped out with ITS won't let you bring the system up without pack #1, and .;@ SALV is on pack #1. But @ OSALV is on pack #0, so you can use it to check out the filesystem before starting ITS by hand at GO. SYS;ATSIGN HACTRN is a link to SYS;ATSIGN PWORD which is on pack #1. ATSIGN DDT is also on pack #1, but there is an ATSIGN ODDT on pack #0, so one way to proceed is to rename this to be ATSIGN HACTRN. (Or patch ITS to use the name ODDT rather than HACTRN...) Another possibility is to install a new HACTRN over the network. (Using the network is necessary eventually anyway, because to get other missing stuff back from tape, we need SYSBIN;DUMP BIN which is on pack #1.) SYS;ATSIGN CHAOS is on pack #1, but ATSIGN TCP is on pack #0 and so is SYSBIN;FTPS BIN, so this is a viable path as well. At this point I stopped, because it became clear that in order for the machine to be useful to anyone, I would have to pull a -lot- of stuff back from tape onto a pack that was already mostly full. There was clearly a lot of work ahead, and it would be wasted effort if it turns out that the drive can be fixed by swapping power supplies with unit #1, or something equally trivial.  Date: Wed, 17 Jun 87 17:01:22 EDT From: Alan Bawden Subject: Unit #2 cranky To: POOOR-MX@AI.AI.MIT.EDU Message-ID: <215786.870617.ALAN@AI.AI.MIT.EDU> Unit #2 has taken to unloading its heads and spinning itself down. I only got MX to run for about 10 minutes this afternoon. With two of three RP04's offline it becomes difficult, although probably not impossible to bring ITS back up again. Before anyone tries that, it might be a good idea to see if any diagnostics can find the problem.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 11 May 87 01:13:52 EDT Date: Mon, 11 May 87 01:11:18 EDT From: Alan Bawden Subject: Unit #0 / Pack #0 To: poor-mc@AI.AI.MIT.EDU Message-ID: <977411.870511.ALAN@MX.LCS.MIT.EDU> Unit #0 on the KL has been getting a lot of errors in the last few days. Hard ECC errors, header compare errors and header CRC errors. The lossage seems to be intermittent. (Like I'll find a network server that died with an irrecoverable data error on some file, but I have no trouble reading the file myself.) I've also found a few network servers dead signaling parity errors (%PIPAR set), but the system hasn't done an ordinary parity sweap since the system came up. Moon thinks that this is what ITS does when an irrecoverable disk error happens while swapping. If we are about to lose another RP04, this could be the end. Of course if -someone- wants to try and collect all of the important system files on to pack #0, we could split the two-pack primary disk system into parts. I'll be happy to offer advice to any takers. Of course perhaps we should try DUPing pack #0 first, in case the problem is with with the pack and not the drive.  Date: Fri, 8 May 87 23:46:04 EDT From: "Pandora B. Berman" Subject: dialups to MX are not working To: SWF@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU, JBVB@AI.AI.MIT.EDU Message-ID: <197568.870508.CENT@AI.AI.MIT.EDU> Date: Thu, 7 May 87 20:12:00 EDT From: "Scott W. Frazier" Subject: dialups to MX are not working To: POOR-MX%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU cc: BUG-HARDWARE%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU With all the things that are wrong with MX already, I almost feel stupid submitting a bug report. Oh well. The dialups to MX are not working. They answer but they do not send anything after they connect. I hope this is the correct list to send this to. we know about this. since MX is not maintained, this sort of thing gets fixed on an ad hoc basis. a couple of folks have offered to take a look at them, but i don't know when they will get around to doing so. until then, you get to suffer along with the rest of us.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 7 May 87 20:14:12 EDT Date: Thu, 7 May 87 20:12:00 EDT From: "Scott W. Frazier" Subject: dialups to MX are not working To: POOR-MX%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU cc: BUG-HARDWARE%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <977187.870507.SWF@MX.LCS.MIT.EDU> Hello, With all the things that are wrong with MX already, I almost feel stupid submitting a bug report. Oh well. The dialups to MX are not working. They answer but they do not send anything after they connect. I hope this is the correct list to send this to. - Swf  Date: Fri, 24 Apr 87 08:50:56 EDT From: "Pandora B. Berman" Subject: MX Dialup lossage To: JBVB@AI.AI.MIT.EDU cc: POOR-MX@AI.AI.MIT.EDU Message-ID: <190306.870424.CENT@AI.AI.MIT.EDU> Date: Wed, 22 Apr 87 20:14:45 EDT From: "James B. VanBokkelen" Subject: MX Dialup lossage To: CENT@AI.AI.MIT.EDU I am interested in fixing the MX dialup lossage. Information I have from SRA and Bede indicates the problem is probably in the DH11 terminal interface. I know 11s fairly well, and I think that give a DH11 manual, I can at least isolate the problem better. Rob has told me that he doesn't mind if I shut the machine down to hack on it when it is idle, so I'm warning you (and solicting comments) about this project. I probably won't do anything before early next week in any case (no DH manual, not much time). i think it's a dandy idea. but i'm not the only one with a vested interest in the blue monster. this list should catch most of them. assuming that you go ahead, please be careful about bringing ITS down and up, and if necessary powercycling the 10, during your experiments; as you know, we can't call in DEC to fix anything that gets fried.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 9 Apr 87 14:00:53 EDT Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 13:56-EDT Date: Thu, 9 Apr 87 14:01 EDT From: Rob Austein Subject: [TY: status of modems] To: Alan Bawden cc: Poor-MX@AI.AI.MIT.EDU In-Reply-To: <174984.870328.ALAN@AI.AI.MIT.EDU> Message-ID: <870409140115.3.SRA@WHORFIN.LCS.MIT.EDU> Date: Sat, 28 Mar 87 00:04:14 EST From: Alan Bawden Date: Fri 27 Mar 87 14:46:11-EST From: J. J. Tyrone Sealy Does anyone know why the modems on MX don't answer ? The Modems are ok !!!The software ? Could this be a result of some change to the console version of IOELEV? (Or perhaps it (the 11) has just crashed... Unfortunately I'm at home where I can't check that now...) The current theory is that one of the DH-11s might be out (just one of the four-line blocks, actually). Anybody with data to confirm or deny this theory is encouraged to speak up; I don't even know where the tty line configuration info lives on ITS, although I suppose I could figure it out. Some TMRC people have mentioned that they might wander by with a scope at some point and look at the 11 to see what's wrong.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 27 Mar 87 14:48:43 EST Date: Fri 27 Mar 87 14:46:11-EST From: J. J. Tyrone Sealy Subject: status of modems To: poor-mc@AI.AI.MIT.EDU Message-ID: <12289788801.14.TY@XX.LCS.MIT.EDU> Does anyone know why the modems on MX don't answer ? The Modems are ok !!!The software ? -------  Received: from YUKON.SCRC.Symbolics.COM (TCP 30002424403) by AI.AI.MIT.EDU 24 Mar 87 20:45:02 EST Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 183570; Tue 24-Mar-87 20:40:38 EST Date: Tue, 24 Mar 87 20:40 EST From: David A. Moon Subject: Longer life @ MIT for Poor-mc To: Thomas J. Greene cc: poor-mc@AI.AI.MIT.EDU In-Reply-To: <12289025411.52.TJG@XX.LCS.MIT.EDU> Message-ID: <870324204013.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue 24 Mar 87 16:52:45-EST From: Thomas J. Greene Alan Wu at ECS has space for old-MC(MX). He does not have the people to keep it alive. Would the people who have volunteered there time and energy to keep it going for the last 12 months here in LCS, walk across the street to continue the effort in building 38 ? Note that some of the most relevant people are on vacation right now, so if you don't hear anything for a couple of weeks, it's not because nobody cares. I don't think the machine would survive the trip across the street. I might be proved wrong, but my prognostication is that it would break in an expensive way while being moved.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 Mar 87 16:56:47 EST Date: Tue 24 Mar 87 16:52:45-EST From: Thomas J. Greene Subject: Longer life @ MIT for Poor-mc To: poor-mc@AI.AI.MIT.EDU cc: tjg@XX.LCS.MIT.EDU Message-ID: <12289025411.52.TJG@XX.LCS.MIT.EDU> Alan Wu at ECS has space for old-MC(MX). He does not have the people to keep it alive. Would the people who have volunteered there time and energy to keep it going for the last 12 months here in LCS, walk across the street to continue the effort in building 38 ? Your thoughts please. .... tjg@xx -------  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 21 Mar 87 14:07:15 EST Date: Sat, 21 Mar 87 14:07:33 EST From: "David A. Moon" Subject: Status of MX DF10 To: poor-mc@AI.AI.MIT.EDU Message-ID: <972367.870321.MOON@MX.LCS.MIT.EDU> There is no sign any directories having been destroyed with zeros at their ends, in the way that was happening before, during the week that MX has been up now. Congratulations John and Alan, I think you really fixed the DF10..  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 17 Mar 87 13:54:30 EST Date: Tue, 17 Mar 1987 13:48 EST Message-ID: From: PSZ@XX.LCS.MIT.EDU To: "Pandora B. Berman" Cc: gjs@OZ.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU, psz@XX.LCS.MIT.EDU Subject: Future of the KL In-reply-to: Msg of 16 Mar 1987 03:51-EST from Pandora B. Berman Sorry to get in on this so late, but I am a bit confused about all the arguments. It seems that all the issue of office space and where CR should be is independent of the KL issue, and can probably be resolved satisfactorily. So the real question is do we want to and can we afford to keep MX? In its current state of unreliability, I see no advantage at all to keeping it. In fact, I have had to move all the people in my group who use it off MX 'cause it was just too ill to provide any useful service. The real problem, I think, is just that it's too expensive to maintain the beast and we don't have the talent lying around to maintain it on the cheap. This is not an unusual fate for 11 or 12 year old machines, and I'm not sure I see what reason there is to shed big tears over it. I'm open for argument, but my current impression is that MX is a great big white elephant and I don't see why we should be fighting against its demise. --Pete  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 16 Mar 87 22:49:11 EST Date: Mon 16 Mar 87 22:43:19-EST From: "J. Noel Chiappa" Subject: Re: Future of the KL To: SRA@XX.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU cc: gjs@OZ.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU, psz@XX.LCS.MIT.EDU, psz@ZERMATT.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12286992079.71.JNC@XX.LCS.MIT.EDU> When IMP 6 (the Mil Spec one) was decomissioned I tried to get the MIT Museum interested and they weren't, on the grounds that MIT hadn't built the machine. The Computer Museum might have a more enlightened attitude to a machine which was novel for software reasons, not necessarily hardware, but who knows? Noel -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 16 Mar 87 16:31:55 EST Date: Mon, 16 Mar 1987 16:26 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: gjs@OZ.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU, psz@XX.LCS.MIT.EDU, psz@ZERMATT.LCS.MIT.EDU Subject: Future of the KL In-reply-to: Msg of 16 Mar 1987 03:51-EST from "Pandora B. Berman" Penny, you are missing the point. The excuse doesn't need to be valid, just sound good enough to shut people up. We're talking about politics, and MX doesn't have much of a constituency left (not people with voting rights, anyway). After talking with JTW and with Tom Green about this, my attitude is that I'd like to keep the machine alive, but I don't intend to spend my next N years worth of brownie points doing so. If PSZ and GJS (and those others of their rank that Big Mike will listen to) don't think it's worth the effort, I'm not going to fight it. Has anybody sounded out the Computer Museum about the beast? It is a pretty big piece of history, and Tom really does want to find it a good home rather than just pushing it off the roof. I'm not committed to this idea, but it does sound like a more reasonable end than having the CPU finally melt down into a pile of slag.  Date: Mon, 16 Mar 87 03:51:59 EST From: "Pandora B. Berman" Subject: Future of the KL To: SRA@XX.LCS.MIT.EDU cc: POOR-MX@AI.AI.MIT.EDU, psz@XX.LCS.MIT.EDU, gjs@OZ.AI.MIT.EDU, psz@ZERMATT.LCS.MIT.EDU Message-ID: <169036.870316.CENT@AI.AI.MIT.EDU> Date: Fri, 13 Mar 1987 18:14 EST From: Rob Austein To: gjs@OZ.AI.MIT.EDU, psz@XX.LCS.MIT.EDU, psz@ZERMATT.LCS.MIT.EDU cc: Poor-MX@AI.AI.MIT.EDU Subject: Future of the KL .... FYI, the current theory seems to be that we suddenly need the floor space; somebody (I think Al Vezza but it might be Big Mike) wants CR group (me, Ty, Bede, etc) out of the fifth floor and onto the ninth, which (1) gets us janitorial types out of space that could be used by researchers, (2) gives a "good" reason to flush the KL for floorspace. From their point of view this solves several thorny problems at once. Darth Vezza and Grand Moff D. do not have a leg (collectively) to stand on. if they're just so desperate to strand you & your friends on the ninth floor, they can 1. move some of the remaining VAXen in the VAX farm around to create a nice roomy office next to 936, and 2. lean on AI a bit to remove the remains of Gutenburg, the Twenex doc boxes, etc., and have a nice roomy office by the dover. in both cases they would be recreating office space that used to be there. before the vax farm, LCS had a row of offices against the 9th south wall, and of course there used to be 926 on the east wall. they -do not- need to sacrifice the KL to get space, yet.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 MAR 87 20:36:17 EST Date: Sat 14 Mar 87 20:31:59-EST From: "John Wroclawski" Subject: Re: disks, future, etc. To: Moon@SCRC-STONY-BROOK.ARPA cc: pooor-mx@AI.AI.MIT.EDU In-Reply-To: <870314013805.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12286443881.12.JTW@MIT-SPEECH> Me: .... a much smaller KL (maybe the CPU, 2 memory boxes, and the DEC disk system)... Moon: But I don't think you can make the machine quite that small... I mentioned this particular configuration because it is the largest that will fit in one row along the wall, and thus not take up very much space. No question it'd be throwing away too much stuff, but that's politics for you. -------  Date: Sat, 14 Mar 87 06:17:33 EST From: "Glenn S. Burke" Subject: Re: Future of the KL To: SRA@XX.LCS.MIT.EDU cc: POOR-MX@AI.AI.MIT.EDU, psz@XX.LCS.MIT.EDU, gjs@OZ.AI.MIT.EDU, psz@ZERMATT.LCS.MIT.EDU In-reply-to: Msg of Fri 13 Mar 1987 18:14 EST from Rob Austein Message-ID: <168296.870314.GSB@AI.AI.MIT.EDU> As I fondly remember Darth, he was of the opinion that anything running VMS or ITS was better off in the basement, if not the trash heap. The right people have to get the ear of Grand Moff Dertouzoss, directly.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 14 Mar 87 01:42:22 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93296; Sat 14-Mar-87 01:38:05 EST Date: Sat, 14 Mar 87 01:38 EST From: David A. Moon Subject: disks, future, etc. To: John Wroclawski cc: pooor-mx@AI.AI.MIT.EDU In-Reply-To: <12286186516.8.JTW@MIT-SPEECH> Message-ID: <870314013805.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri 13 Mar 87 20:58:14-EST From: "John Wroclawski" I found some diags that triggered the problem seen under ITS (random parts of a disk block read as zeros). Went through and gave all the flip-chips and cable connectors in the DF10 a good rattle. Things seem to be working OK now. Wonderful! Thanks a million, including for not making me follow through on my rash remark of the other evening. One possible future for this dinosaur is that we negotiate some kind of a compromise where a much smaller KL (maybe the CPU, 2 memory boxes, and the DEC disk system) remains in a corner of the 9th floor. I am curious as to whether anybody cares enough to be willing to help move stuff around at some point if things work out that way. I'd be happy to help move stuff around. But I don't think you can make the machine quite that small. "Maybe the CPU"? The machine isn't too much use without its 7-track tape drive; think about what happens if there's some sort of disk trouble. I also don't think we want to lose the Chaosnet. Maybe we can move the Chaosnet to the other 11; it'll be slow, but not as slow as the Chaosnet interfaces we're using now on the KS's. Then we could junk the second 11, the DL10, and the T-300s. That's cool, but somebody's gotta write a little software. If the CPU moves more than a few feet, the Arpanet connection will be lost -- maybe that's considered okay. On the other hand, maybe the cpu can't move because moving the 10-ton outlet it plugs into would be too expensive. I'd say keep 3 memory boxes, one for spares. So I say the machine can plausibly be decreased from 16 refrigerators plus 6 disk drives to 12 refrigerators plus 2 disk drives. Maybe 11 refrigerators if we take advantage of the fact that there's a lot of air inside a DF10.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 MAR 87 21:01:47 EST Date: Fri 13 Mar 87 20:58:14-EST From: "John Wroclawski" Subject: disks, future, etc. To: pooor-mx@AI.AI.MIT.EDU Message-ID: <12286186516.8.JTW@MIT-SPEECH> I found some diags that triggered the problem seen under ITS (random parts of a disk block read as zeros). Went through and gave all the flip-chips and cable connectors in the DF10 a good rattle. Things seem to be working OK now. One possible future for this dinosaur is that we negotiate some kind of a compromise where a much smaller KL (maybe the CPU, 2 memory boxes, and the DEC disk system) remains in a corner of the 9th floor. I am curious as to whether anybody cares enough to be willing to help move stuff around at some point if things work out that way. -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Mar 87 18:19:08 EST Date: Fri, 13 Mar 1987 18:14 EST Message-ID: From: Rob Austein To: gjs@OZ.AI.MIT.EDU, psz@XX.LCS.MIT.EDU, psz@ZERMATT.LCS.MIT.EDU cc: Poor-MX@AI.AI.MIT.EDU Subject: Future of the KL [PSZ, sorry about the multiple copies, but I can't figure out where you read mail these days. Talk to me about this?] Esteemed ITS lovers. A move seems to be underway in LCS-HQ to declare the KL dead. This is not definite (I can't get a straight answer out of the people who really know what HQ is doing, but it's my reading of what they tell me). I have been asked to find a good home for the thing where it can be kept as an honored museum piece. If anybody knows of such a place, let me know and I'll pass it along, but that's not really the issue. The issue is whether or not we are going to let HQ do this. GJS, PSZ, you guys have a lot of weight with Big Mike, could you be persuaded to sit on his desk till he gives up this silly idea? I got into this because my new boss, Tom Greene, has been put in the position of ping-pong ball; HQ tells him to flush the machine, and he's new enough here that he can't really tell them to go away. I think. It is just barely possible that he himself wants the KL flushed, but it's unlikely. In either case, the easiest way to handle this would be to convince Mike that this is not a good idea, and let Tom get the news from above. FYI, the current theory seems to be that we suddenly need the floor space; somebody (I think Al Vezza but it might be Big Mike) wants CR group (me, Ty, Bede, etc) out of the fifth floor and onto the ninth, which (1) gets us janitorial types out of space that could be used by researchers, (2) gives a "good" reason to flush the KL for floorspace. From their point of view this solves several thorny problems at once. If I sound annoyed it's because I don't like AV and friends using a new and confused person to do their dirty work. And of course I don't want the KL flushed. I wouldn't mind a decent office on the 9th floor, but I'm not a canible  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 MAR 87 19:36:22 EST Date: Thu 12 Mar 87 19:32:50-EST From: "John Wroclawski" Subject: Re: Life is complicated, here in the future To: poor-MX@AI.AI.MIT.EDU In-Reply-To: <870308232501.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12285908824.18.JTW@MIT-SPEECH> I ran some disk diagnostics on the KL. The DF10/RH10/RP04 setup does all the simple things fine, but flakes in various ways while trying to do anything that smacks of a reliability test. Barf. -------  Date: Sun, 8 Mar 87 23:58:57 EST From: "Pandora B. Berman" Subject: poor-mc arc To: MOON@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Message-ID: <165388.870308.CENT@AI.AI.MIT.EDU> Date: Sun, 8 Mar 87 23:07:53 EST From: Communications Satellite Subject: Msg of Sunday, 8 March 1987 23:02-EST To: MOON@AI.AI.MIT.EDU Resent-To: poor-mc@ai.ai.mit.edu Resent-From: David A. Moon Resent-Date: Sun, 8 Mar 87 23:22 EST Resent-Comments: This is perhaps a poor choice of place for the archive for the poor-mc mailing list!! Queued: (FILE [SYSDOC;POOR MC]) at MX.LCS.MIT.EDU fear not. there is a (superior if not identical) archive on AI.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Mar 87 23:27:35 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87928; Sun 8-Mar-87 23:25:07 EST Date: Sun, 8 Mar 87 23:25 EST From: David A. Moon Subject: Life is complicated, here in the future To: pooor-mx@AI.AI.MIT.EDU In-Reply-To: <870308172805.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870308232501.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 8 Mar 87 17:28 EST From: David A. Moon The problem, I suspect, is that something is clobbering data written to disk by bashing words N through the end of the block (where N varies) to zero. This happened to the MFD and to several UFD's. Originally I thought this happened as a side-effect of power going off, but if several directories were clobbered in one incident, that can't be the cause. Unfortunately my most likely candidate for doing this would be the DF10, a virtually unmaintainable piece of hardware. We had some code in the system, developed when the (old) ML machine was dying, for doing software read-compares on all disk writes. Looks like it better be revived if we're going to bring MX back up. That's easier than getting the system to run with no RP04s (all T-300s). I'll look into this eventually if no one else does it first. Probably the system needs to be reassembled to turn on that code. I turned on that code (see the log book) and it sort of works, but seems to crash a lot with the DF10 executing complete garbage control words. I gave up for the night. Maybe I screwed up the cache stuff, maybe it screws up when it gets a correctable ecc error, or maybe the hardware is broken. Anyway the Comsat database seems to be clobbered; there are some nulls and things in LIST MASTER, and MAKMST didn't seem to work either. The new code in the system can be turned off by patching QRCSW/0  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Mar 87 23:24:53 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87926; Sun 8-Mar-87 23:22:30 EST Received: from AI.AI.MIT.EDU (MIT-AI.ARPA) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 87917; 8 Mar 87 23:06:05 EST Date: Sun, 8 Mar 87 23:07:53 EST From: Communications Satellite Subject: Msg of Sunday, 8 March 1987 23:02-EST To: MOON@AI.AI.MIT.EDU Message-ID: <165362.870308@AI.AI.MIT.EDU> Resent-To: poor-mc@ai.ai.mit.edu Resent-From: David A. Moon Resent-Date: Sun, 8 Mar 87 23:22 EST Resent-Message-ID: <870308232225.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Resent-Comments: This is perhaps a poor choice of place for the archive for the poor-mc mailing list!! Queued: (FILE [SYSDOC;POOR MC]) at MX.LCS.MIT.EDU  Date: Sun, 8 Mar 87 23:02:18 EST From: "David A. Moon" To: POOR-MC@AI.AI.MIT.EDU Message-ID: <165361.870308.MOON@AI.AI.MIT.EDU> In summary, it's still broken. I'm giving up for the day.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Mar 87 17:38:31 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87816; Sun 8-Mar-87 17:28:20 EST Date: Sun, 8 Mar 87 17:28 EST From: David A. Moon Subject: Life is complicated, here in the future To: David Vinayak Wallace cc: pooor-mx@AI.AI.MIT.EDU In-Reply-To: <870308031911.3.GUMBY@MARLEY.AI.MIT.EDU> Message-ID: <870308172805.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 8 Mar 87 03:19 EST From: David Vinayak Wallace Well, MX is not in quite as good a shape as it had initially appeared. Several directories (among them DEVICE, SYSTEM, and INQUIR) vanished in the recent surgery. After pondering whether or not to reload them over the network I decided to reconstruct the MFD's from drive 2 (presuming that something might be wrong with the pack on drive 0). Then I UCOP'ed drive 2's MFD to the other packs. Oh, so that's why there were so many 0<-1's when I salvaged it! Damn, I should have suspected the MFD was screwed up if I had had my brain turned on. You did good. The problem, I suspect, is that something is clobbering data written to disk by bashing words N through the end of the block (where N varies) to zero. This happened to the MFD and to several UFD's. Originally I thought this happened as a side-effect of power going off, but if several directories were clobbered in one incident, that can't be the cause. Unfortunately my most likely candidate for doing this would be the DF10, a virtually unmaintainable piece of hardware. We had some code in the system, developed when the (old) ML machine was dying, for doing software read-compares on all disk writes. Looks like it better be revived if we're going to bring MX back up. That's easier than getting the system to run with no RP04s (all T-300s). I'll look into this eventually if no one else does it first. Probably the system needs to be reassembled to turn on that code. The system is now in approximately the same shape it was before surgery (tah-dah!). Hopefully somebody else will decide to fix it before we do. They might know what they're doing.  Date: Sun, 8 Mar 87 17:13:53 EST From: Alan Bawden Subject: Life is complicated, here in the future To: GUMBY@AI.AI.MIT.EDU cc: POOOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Sun 8 Mar 87 03:19 EST from David Vinayak Wallace Message-ID: <165231.870308.ALAN@AI.AI.MIT.EDU> Date: Sun, 8 Mar 87 03:19 EST From: David Vinayak Wallace ... Several directories (among them DEVICE, SYSTEM, and INQUIR) vanished in the recent surgery. After pondering whether or not to reload them over the network I decided to reconstruct the MFD's from drive 2 (presuming that something might be wrong with the pack on drive 0). Then I UCOP'ed drive 2's MFD to the other packs. The system is now in approximately the same shape it was before surgery (tah-dah!). Hopefully somebody else will decide to fix it before we do. They might know what they're doing. Huh? So what's still broken? Do you mean that the the MFD on unit #2 didn't have the directories either? Then perhaps you should try running the MFDR routine in the salvager to try to reconstruct the MFD from the directory blocks. (I've never done that myself, so I can't tell you what that will be like. You might want to glance though a salvager listing first to see what it thinks it does. Recall that this is the pre-CStacy salvager, so you can have some confidence that it might work.)  Received: from MARLEY.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 MAR 87 03:19:59 EST Date: Sun, 8 Mar 87 03:19 EST From: David Vinayak Wallace Subject: Life is complicated, here in the future To: pooor-mx@AI.AI.MIT.EDU Message-ID: <870308031911.3.GUMBY@MARLEY.AI.MIT.EDU> Well, MX is not in quite as good a shape as it had initially appeared. Several directories (among them DEVICE, SYSTEM, and INQUIR) vanished in the recent surgery. After pondering whether or not to reload them over the network I decided to reconstruct the MFD's from drive 2 (presuming that something might be wrong with the pack on drive 0). Then I UCOP'ed drive 2's MFD to the other packs. The system is now in approximately the same shape it was before surgery (tah-dah!). Hopefully somebody else will decide to fix it before we do. They might know what they're doing.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 MAR 87 23:47:34 EST Date: Sat 7 Mar 87 23:46:40-EST From: "John Wroclawski" Subject: Re: fan To: poor-mc@AI.AI.MIT.EDU In-Reply-To: <164090.870306.CENT@AI.AI.MIT.EDU> Message-ID: <12284644315.24.JTW@MIT-SPEECH> I have installed a new fan in the KL, leaving the machine at least willing to stay on. It even appears to work almost. There is something broken such that most jobs (net logins, daemons) won't start. Logging in from a hardwired line works fine. Someone who knows something might look at this. The spindle bearing on RP04 unit 2 is discontent. While we could theoretically use the bearing from #1 to fix this, we never will, so someone (that same mythical someone) might want to make sure that the machine can be booted with a single RP04 present. -------  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 MAR 87 03:16:30 EST Date: Fri 6 Mar 87 03:15:57-EST From: "John Wroclawski" Subject: Re: fan To: TY@XX.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU In-Reply-To: <12284143727.29.TY@XX.LCS.MIT.EDU> Message-ID: <12284158124.31.JTW@MIT-SPEECH> No, the fan is bad. It appears to work now because I bashed it on the floor a few times to get it to work long enough so that Dave could fix up the filesystem. The supply is fine. I've been too busy to worry about this. I should have the required few minutes this weekend though. I would however prefer that we get a new fan from Lester so that I don't have to raid speech's spares. They are hard to get from anywhere else because they are 208v, not 125. So if someone sees Lester please ask him to bring a couple by (we should have a spare). If he can just do it, great, but if not we will have to take up a collection to pay for them I guess. -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 6 Mar 87 01:59:32 EST Date: Fri 6 Mar 87 01:56:52-EST From: J. J. Tyrone Sealy Subject: Re: fan To: CENT@AI.AI.MIT.EDU cc: JTW@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU In-Reply-To: <164090.870306.CENT@AI.AI.MIT.EDU> Message-ID: <12284143727.29.TY@XX.LCS.MIT.EDU> I saw Lester today and He is checking to see what a power supply will cost. It appears that the fans are ok the Supply is not.. -------  Date: Fri, 6 Mar 87 01:28:07 EST From: "Pandora B. Berman" Subject: fan To: JTW@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Message-ID: <164090.870306.CENT@AI.AI.MIT.EDU> hey, john, are you going to replace the dead fan in the KL, or are you giving up on it?  Received: from DEEP-THOUGHT.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 FEB 87 22:14:01 EST Date: Tue, 24 Feb 1987 22:07 EST Message-ID: From: PGS@DEEP-THOUGHT.MIT.EDU To: poor-mx@AI.AI.MIT.EDU Plese igore my last messag to poor-mx. It seems I hadn't sufficiently tested my theory that MC's front end was to blame, because, well, here I am on this here other PDP-10, and something very damned fnny does seem to be gong on wit this modem.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 24 Feb 87 22:04:59 EST Date: Tue, 24 Feb 87 22:02:44 EST From: "Patrick G. Sobalvarro" To: POOR-MX%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <971329.870224.PGS@MX.LCS.MIT.EDU> Has anyone bsides me ntied that the dialups on MC sem t be dopping charactes? I thought it was my shiny new Apollo tht was doin it, so I connected ths here Ann Arbor up to my odem, an, well, it looks like it's either MC o the modem. But the modem woks fine when talking to other machines. Thus, e conclude, it is xtremey likel that MX's front end is dropping characts. Wildly.  Date: Tue, 24 Feb 87 15:05:39 EST From: kltoz@AI.AI.MIT.EDU Sender: ___016@AI.AI.MIT.EDU Subject: Rudy.Nedved and the end of TOPS-10 To: POOR-MX@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <159022.870224.___016@AI.AI.MIT.EDU> Rudy Nedved is the person who caused the demise of info-cobol.  Date: Tue, 24 Feb 87 01:21:56 EST From: "Pandora B. Berman" Subject: small request To: Rudy.Nedved@H.CS.CMU.EDU cc: POSTMASTER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU Message-ID: <158772.870224.CENT@AI.AI.MIT.EDU> Date: Monday, 23 February 1987 19:28:36 EST From: Rudy.Nedved@h.cs.cmu.edu To: postmaster@mc.lcs.mit.edu Subject: small request Hi, Could some kind person take the time out to remove MIT-MESSAGES@A.CS.CMU.EDU from the mit bboard distribution list? done, mostly by Gumby (i cleaned up a few things he missed). It has been eons since I made a change to a mailing list on MIT ITC you mean ITS, right? machines. Thanks much, -Rudy CMU CS/RI Postmaster P.S. The last TOPS-10 machine on the ARPANET, A.CS.CMU.EDU is going away in a week or so. The official shutoff time for users is this Monday, March 2nd. alas, poor PDP-10s -- yet another casualty. it deserves recording (wherefore the CCs to the other lists) and public mourning. probably if you send a mildly clever farewell msg to arpanet-bboards it will get broadcast...  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 10 Feb 87 12:59:04 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67087; Tue 10-Feb-87 12:57:08 EST Date: Tue, 10 Feb 87 12:57 EST From: David A. Moon Subject: [PFTHMG-DRAGON@MX.LCS.MIT.EDU: Forwarded] To: Alan Bawden cc: Poor-MC@AI.AI.MIT.EDU In-Reply-To: <870209203852.8.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870210125709.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 9 Feb 87 20:38 EST From: Alan Bawden Date: Mon, 9 Feb 87 20:20:28 EST From: Puff the Magic Dragon To: MAGIC-DRAGON-KEEPER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <968893.870209.PFTHMG-DRAGON@MX.LCS.MIT.EDU> The file DSK:CHANNA;LOGOUT TIMES seems to be clobbered. Please check it. The offensive material follows: ZB 12/06+81 23:08:19 This is a single bit change in the file. (I corrected it.) Perhaps the RP04's or the disk DF10 have started inserting subtle changes in the data they handle? Could this have been caused by powering-on the broken MH10?  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 FEB 87 20:38:01 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 21708; Mon 9-Feb-87 20:38:51 EST Date: Mon, 9 Feb 87 20:38 EST From: Alan Bawden Subject: [PFTHMG-DRAGON@MX.LCS.MIT.EDU: Forwarded] To: Poor-MC@AI.AI.MIT.EDU Message-ID: <870209203852.8.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 9 Feb 87 20:20:28 EST From: Puff the Magic Dragon To: MAGIC-DRAGON-KEEPER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <968893.870209.PFTHMG-DRAGON@MX.LCS.MIT.EDU> The file DSK:CHANNA;LOGOUT TIMES seems to be clobbered. Please check it. The offensive material follows: ZB 12/06+81 23:08:19 This is a single bit change in the file. (I corrected it.) Perhaps the RP04's or the disk DF10 have started inserting subtle changes in the data they handle?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 7 Feb 87 17:33:03 EST Date: Sat, 7 Feb 1987 17:33 EST Message-ID: From: Rob Austein To: Poor-MX@AI.AI.MIT.EDU Subject: Crippled by a lowly fan The KL is down, none of the fans in the CPU will spin. Details in log. Anybody know what circut controls this? I didn't want to just start flipping breakers and pulling fuses at random.  Date: Mon, 2 Feb 87 03:28:08 EST From: "Pandora B. Berman" Subject: read me To: POOR-MC@AI.AI.MIT.EDU Message-ID: <147776.870202.CENT@AI.AI.MIT.EDU> Date: Sat, 31 Jan 87 23:05 EST From: David A. Moon Subject: kl down in flames To: Alan Bawden cc: POOR-MC@AI.AI.MIT.EDU Is the type-ball (cylinder actually?) actually worn out? Wow! Usually the way to fix them is to clean the type cylinder and adjust the various cams and pneumatic dashpots in the mechanism. I don't know too much about it, but Howard Cannon used to do it for a living. i tried cleaning the cylinder and general surrounding mechanism. which was quite filthy and covered with stray hair (how much have you torn out in that area over the years, dave?). it now prints somewhat clearer but not perfectly. someone who knows how to adjust the mechanism should take a look at it. it is probably somewhat worn -- after all, just how old is that terminal?  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 31 Jan 87 23:36:46 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 59259; Sat 31-Jan-87 23:05:08 EST Date: Sat, 31 Jan 87 23:05 EST From: David A. Moon Subject: kl down in flames To: Alan Bawden cc: POOR-MC@AI.AI.MIT.EDU In-Reply-To: <147304.870131.ALAN@AI.AI.MIT.EDU> Message-ID: <870131230507.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 31 Jan 87 17:22:29 EST From: Alan Bawden Anyone have any idea where we could get a new type-ball for a TTY33? Is the type-ball (cylinder actually?) actually worn out? Wow! Usually the way to fix them is to clean the type cylinder and adjust the various cams and pneumatic dashpots in the mechanism. I don't know too much about it, but Howard Cannon used to do it for a living. More seriously, if anybody knows where we can get a decent terminal with a current loop interface we could plug it in there when necessary. Or we could get a pdp-11 programmer to tell 11DDT about DH-11 lines, maybe that would be the best solution. We could debug at 9600 baud on the existing VT52.  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 JAN 87 22:51:12 EST Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19973; Sat 31-Jan-87 22:51:35 EST Date: Sat, 31 Jan 87 22:51 EST From: David Vinayak Wallace Subject: TTY33 To: Alan Bawden cc: POOR-MC@AI.AI.MIT.EDU In-Reply-To: <147304.870131.ALAN@AI.AI.MIT.EDU> Message-ID: <870131225132.2.GUMBY@NULLSTELLENSATZ.AI.MIT.EDU> I'll stop by Heffron's this week.  Date: Sat, 31 Jan 87 17:22:29 EST From: Alan Bawden Subject: kl down in flames To: POOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Fri 30 Jan 87 08:04:39 EST from Pandora B. Berman Message-ID: <147304.870131.ALAN@AI.AI.MIT.EDU> Yesterday, I fondled the T-300 cables and the KL has been running fine ever since. I don't think that could possibly have addressed all of the problems that Moon experienced the night before. Anyone have any idea where we could get a new type-ball for a TTY33?  Date: Fri, 30 Jan 87 08:04:39 EST From: "Pandora B. Berman" Subject: kl down in flames To: POOR-MC@AI.AI.MIT.EDU Message-ID: <146747.870130.CENT@AI.AI.MIT.EDU> And it came to pass, oh Best Beloved, that MX died around 10:30 last night, and i noticed around 11:30, and i tried to revive it. it proclaimed UCODE HUNG, but it couldn't work its way through KLINIT on the route back up without getting a 10 ERR,ADR=0 error. so i called Alan, and he suggested this and that, none of which, alas, helped. so i called Moon (mightiest of the mighty, oh Best Beloved) and he mentioned some of the suggestions of Alan, and a few others also, none of which, alas, helped. then did Moon swear a mighty oath that he would swing by on his way home and see what could be seen. Nor did Moon break his oath, for soon he appeared, saying "What is all this lossage?" And Moon called for a voltmeter, with which to check the power supplies on memory C, and he found them deficient, and Moon called for paper for the Shitty33, that he might converse with the 11. And Moon also called for the KL to perform various highly unlikely and improbable acts, for its behavior was not to his liking. And Moon, who is the mightiest of the mighty, swore many another mighty oath at that time, cursing the decrepitude of the KL and its LA120. Then did Moon find that, despite his might, in his current state of weariness he had not the power to raise the KL from its trance by the laying on of hands. So Moon slunk off in disgust and exhaustion, oh Best Beloved, leaving the KL to wait for future salvation. Details in the log.  Date: Tue, 13 Jan 87 22:42:48 EST From: "Pandora B. Berman" Subject: The most embarrassing lossage yet To: SRA@AI.AI.MIT.EDU cc: POOR-MX@AI.AI.MIT.EDU Message-ID: <140003.870113.CENT@AI.AI.MIT.EDU> Date: Tue, 13 Jan 87 22:11:44 EST From: Rob Austein Subject: The most embarrassing lossage yet To: Poor-MX@AI.AI.MIT.EDU Anybody have a new ribbon for the poor fossilized console? The old one is awfully pale, transparent I'd say. rob, you forgot to pull back the adjustment lever. it's now readable, though far from good. the stock room is supposed to carry these, although half the times i ask for them they are out. i will try again the next time i'm down there. at worst, i suppose we could arrange for a requisition to main-campus Lab Supply, which does have them.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 13 Jan 87 22:14:28 EST Date: Tue, 13 Jan 87 22:11:44 EST From: Rob Austein Subject: The most embarrassing lossage yet To: Poor-MX@AI.AI.MIT.EDU Message-ID: <965272.870113.SRA@MX.LCS.MIT.EDU> Anybody have a new ribbon for the poor fossilized console? The old one is awfully pale, transparent I'd say. Just $0.05 apiece and we can have a nice new ribbon....  Date: Thu, 1 Jan 87 22:50:46 EST From: Alan Bawden Subject: MX unit #5 To: POOR-MC@AI.AI.MIT.EDU Message-ID: <135786.870101.ALAN@AI.AI.MIT.EDU> I took unit #5, the leftmost T-300, offline. The pack that was in that drive appears to be perfectly readable, unit #4 has no trouble with it. This means that the KL no longer has a FOURTH:.  Date: Thu, 1 Jan 87 15:43:25 EST From: Alan Bawden Subject: MX unit #5 To: KLOTZ@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Wed 31 Dec 86 22:12:10 EST from Leigh L. Klotz Message-ID: <135733.870101.ALAN@AI.AI.MIT.EDU> Date: Wed, 31 Dec 86 22:12:10 EST From: Leigh L. Klotz I just got a non-recoverable disk data error on klotz;emacs :ej, which is on 14. When you log in, SYS:SYSTEM MAIL warned you that unit #5 was sinking fast. Yeah, many files on that pack/drive have suffered. Perhaps I'll try swapping that pack with the one on unit #4 and see what happens. If we are really lucky, that will destroy both of them! Date: Wed, 31 Dec 86 22:28:06 EST From: Leigh L. Klotz I renamed the bad file to klotz;.bad. :EJ, but the error went away. It had been repeatable. Is anyone interested in this? Should I be sending mail to POOR-MC? POOR-MC is probably the right place, although perhaps there is a POOR-MX list that I don't know about. (POOR-KL?)  Date: Wed, 31 Dec 86 17:06:56 EST From: "Pandora B. Berman" Subject: KS resurrection To: TY@XX.LCS.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Message-ID: <135367.861231.CENT@AI.AI.MIT.EDU> Date: Wed 31 Dec 86 13:26:29-EST From: J. J. Tyrone Sealy Subject: Re: KS To: Alan@AI.AI.MIT.EDU cc: SRA@XX.LCS.MIT.EDU, Poor-MC@AI.AI.MIT.EDU Dec came and align all the heads..the drive seemed ok after.. I reloaded MC at 1:00 pm. let's hope it lives... happy new year --TY thanks a million for keeping after this.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 31 Dec 86 13:26:08 EST Date: Wed 31 Dec 86 13:26:29-EST From: J. J. Tyrone Sealy Subject: Re: KS To: Alan@AI.AI.MIT.EDU cc: SRA@XX.LCS.MIT.EDU, Poor-MC@AI.AI.MIT.EDU In-Reply-To: <861230170318.2.ALAN@GAYE.AI.MIT.EDU> Message-ID: <12267229908.11.TY@XX.LCS.MIT.EDU> Dec came and align all the heads..the drive seemed ok after.. I reloaded MC at 1:00 pm. let's hope it lives... happy new year --TY -------  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 DEC 86 17:03:49 EST Received: from GAYE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16797; Tue 30-Dec-86 17:02:42 EST Date: Tue, 30 Dec 86 17:03 EST From: Alan Bawden Subject: KS To: SRA@XX.LCS.MIT.EDU cc: Poor-MC@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861230170318.2.ALAN@GAYE.AI.MIT.EDU> Well, it appears that the board that DEC replaced this morning may have solved the problem. The diagnostics seem to be running without getting any disk errors. If nothing bad happens for a day, perhaps I will bring MC back up tomorrow (probably using the duplicated pack). TY is going to try and get DEC to do a head alignment when they come in tomorrow as well.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 23 Dec 86 17:29:56 EST Date: Tue, 23 Dec 1986 17:27 EST Message-ID: From: Rob Austein To: Log-Service-Call@XX.LCS.MIT.EDU, Poor-MC@AI.AI.MIT.EDU Subject: KS This is just to let you know that I am effectively gone as of now. I might log in and read my mail tomorow (or might not), but other than that I am not here until 2 January 1987. So don't expect me to do anything about fixing MC. Lester is already working on the disk drive. I don't know how much money he's going to ask for but whatever it is, we should give it to him (I wonder if he gives a cash discount? 8-). I don't think we have much choice about this; Karen, if Mike complains about it too much, just tell him about how badly all the Lisp Machines will break if they can't use MC. Good luck, folks. I'll say hello to Florida for you all....  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 DEC 86 07:01:19 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16469; Tue 23-Dec-86 07:00:58 EST Date: Tue, 23 Dec 86 07:00 EST From: Alan Bawden Subject: KS and disk To: SRA@XX.LCS.MIT.EDU cc: Sollins@XX.LCS.MIT.EDU, Poor-MC@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861223070049.3.ALAN@PIGPEN.AI.MIT.EDU> [ I removed Log-Service-Call@XX from the Recipients of this message, because I wasn't sure of the protocol for using it. ] OK, it is possible that all of the bits in MC's filesystem were recovered from today's disaster. It appears that many of the blocks written on that pack by MC's drive this weekend are marginal, but they are readable by the salvager if it tries hard enough. There is some slight question as to the integrity of the data in those blocks, since we did have to reconstruct a couple of blocks in the filesystem itself. It may be that when MC comes back up, we will find that COMSAT's queue files are damaged. I estimate the probability of this to be rather low actually. I have made a duplicate of MC's pack onto a fresh pack. (The old pack was named "MX001", I christened the new pack "MX002".) Both packs are on the same shelf in the disk pack cabinet next to the window behind AI and OZ. The new pack will probably function better than the old because even though you get exactly the same data (be it good or bad) when you read it, you don't have to work as hard to get it since its blocks are all written properly. If there is any question as to the ancestry of this new pack, we can always reformat the old pack and copy the data back... As to the problems with MC's drive itself, it looks to me like the problem should be easy for anyone with a knowledge of RP06's to fix. When ITS was running this weekend, -all- of the disk errors signaled the same error bit (the "phase-locked ossillator (sic) unsafe" bit, says my crufty DEC documentation), and it sounds to me like the diagnostics that JTW and SRA got running were also reporting a consistent failure. I have my doubts about the competence of whoever it was who showed up from DEC this weekend, it seems a shame you had to use up all your MC maintenence money that way. (By the way: The drive -is- correctly grounded to the processor, and I find it highly unlikey that the ITS disk pack or the ITS operating system could be the cause of something with a name like "phase-locked oscillator unsafe"!) If I were you, I would not mount either of those ITS packs in that drive again unless you are very certain that the problem is fixed.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 22 Dec 86 20:39:45 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29850; Mon 22-Dec-86 20:36:56 EST Date: Mon, 22 Dec 86 20:36 EST From: David A. Moon Subject: Kludging around the KS's flakey disk To: Rob Austein cc: Bug-ITS@MIT-AI.ARPA, Poor-MC@MIT-AI.ARPA In-Reply-To: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU> Supersedes: <861222150854.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <861222203625.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 22 Dec 86 02:02 EST From: Rob Austein I just spent five minutes looking at the DISK code. Based on that wealth of experience, it appears to me that if I were to bring up the KS with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or so. Somebody tell me why I shouldn't do this, before I wear out the $P keys on the KS's console.... The idea was that if the disk goes unsafe, is reset, and goes unsafe again within one second, it is probably about to explode and the fire department should be called. It looks like the code jumps to UNSAFE for a lot of different reasons, not all of which are the drive going unsafe. The drive also goes unsafe for a lot of different reasons, some of more consequence than others. I agree that if you JFCL out the BUGPAUSE it won't do it any more, so if you think this won't do irreparable harm to the disk, go ahead.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Dec 86 09:31:09 EST Date: Mon 22 Dec 86 09:31:30-EST From: J. J. Tyrone Sealy Subject: Re: KS and disk To: SRA@XX.LCS.MIT.EDU cc: Poor-MC@AI.AI.MIT.EDU, Log-Service-Call@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12264827835.9.TY@XX.LCS.MIT.EDU> Found the drive unsafe this morning..tried to continue system after spinning drive down/up. System tried then hung, had to reload..will check on it often.. -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Dec 86 02:04:20 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Dec 86 02:04-EST Date: Mon, 22 Dec 86 02:02 EST From: Rob Austein Subject: Kludging around the KS's flakey disk To: Bug-ITS@AI.AI.MIT.EDU, Poor-MC@AI.AI.MIT.EDU Message-ID: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU> I just spent five minutes looking at the DISK code. Based on that wealth of experience, it appears to me that if I were to bring up the KS with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or so. Somebody tell me why I shouldn't do this, before I wear out the $P keys on the KS's console....  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Dec 86 16:36:38 EST Date: Sun, 21 Dec 1986 16:37 EST Message-ID: From: Rob Austein To: Poor-MC@AI.AI.MIT.EDU, Log-Service-Call@XX.LCS.MIT.EDU Subject: KS and disk Ok, so we finally got somebody from DEC in, he stayed for three hours, we owe them $411. I have the customer's copy of the bill, the other copy will be delivered through the usual mechanism (hand carry by Lester) so that the appropriate PO can get filled out by somebody who knows what to put in all the little boxes. The problem is not fixed. MC does not crash as a direct result of the disk errors anymore. Instead, it crashes after it gets enough non-fatal disk errors. I suppose we could increment the threshold value for "too many disk errors" as a stopgap. Interestingly enough, AI started having similar errors today (except that the PLO bit isn't on for AI's errors). The F-S guy suggested we check that all those disks are grounded to the correct processors (AI's disks to AI, MC's to MC, etc). When I mentioned that the PLO Unsafe bit that comes up occasionally (and is now coming up consistantly in the nonfatal errors on MC), our F-S guy immediately dove into the guts and found a cable that wasn't seated properly. He fixed that, which is (I think) what changed the errors from fatal to nonfatal. The problem appears to be somewhat interrmittant; I saw him run this diagnostic that causes the drive to break dance across the floor. Sometimes it failed, sometimes it didn't. For a while we thought the MC pack might be bad, but the evidence wasn't conclusive. We were somewhat hampered by the fact that the worst of these errors only seem to come up on the ITS pack where the normal DEC diagnositic tools aren't available. Some ITS wizard should take a look at the new set of error bits and disk addresses (in particuar the latter, our F-S guy wasn't able to spot any pattern in the addresses because he's used to surface-cylinder numbers). One theory he came up with is that there's a head on that drive that's gone slightly out of alignment. He theorizes that the ITS code might be less tolerant of these errors than Twenex, which is why ITS crashes when Twenex just types obnoxious messages on the console. At the end of three hours we decided that we needed more information and that we'd be wasting our money having him stay around any longer. Current status is that MC is up except when it isnt'; it needs rebooting a lot. We have a bunch of options. One is to pay a head reallignment job and see if that fixes it. Another is to format up a new MC pack with the current (possibly misaligned) head configuration and run off that for a while if it works. This might be the best option, since the Twenex code seems to be able to cope with the current head alignment. This also covers the possiblility of the MC pack being bad. Another option would be to bring up JTW's MIT rel5 Twenex pack (as opposed to the vanilla DEC rel4 Alan and I were running before) and see if SPEAR's ANALYZE functions can spot any patterns that us humans missed. I'd do this right now except that I want to let the mail queues drain for a while (which was why I decided to pay the surcharge for weekend service). We haven't run twenex since he reseated those cables for the PLO problem, so it is possible that twenex would be happy now. I doubt it, though, since the PLO bit is still coming up on MC and is not coming up on AI. Another option is to swap drives with MD so that we can put off spending any more money on MC for a while. This might be worth keeping in mind, since we don't want Mike Dertuzos to withdraw his blessing (such as it is) from this project. Suggestions? I'm not going to be around much for the next week or so, somebody else might want to take over nursing our ailing puppy along.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Dec 86 20:34:03 EST Date: Fri, 19 Dec 1986 20:35 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: POOR-MC@AI.AI.MIT.EDU, Sollins@XX.LCS.MIT.EDU Subject: The KS lost again In-reply-to: Msg of 19 Dec 1986 17:41-EST from David A. Moon Well, here's what's happened so far. Alan extracted the error bits from the crash dumps, and looked them up. One is a generic unsafe bit, one is a "missed transfer" bit, and one (which is only on in one of the two dumps) is this hairy thing involving "loss of sync in the read/write phase locked oscillator". This last one rang a bell in the mind of DPH, who said he thought we had had problems like that when the KS was first delivered, but that the problem had gone away of its own accord so nobody had ever done anything about it. Then the F-S guy called and seemed somewhat reluctant to come out here anytime soon (he has contract customers in the queue, and they get priority). I described the bits to him and he suggested we try another pack in the drive. So we dug out one of our two KS RED packs and spun that up. We brought that pack up running twenex, I broke into OPERATOR, and started doing simple disk I/O (running a batch job that submitted itself, typed out a file, then exited). We got "problem on device" errors out the wazzoo, so it's not the MC pack. I managed to get a long form listing of the massbus error reports (from the syserr log) typed out on the console. Don't mean squat to me but should be helpful to the F-S creature if s/he ever shows up. The reporting tool is the old SYSERR program, which is missing the analysis capabilities of the later SPEAR program. So all I could get was the raw data. At this point I'm waiting to hear from F-S, who claimed they'd call back sometime tonight when they knew if they'd be here anytime soon. If there's anybody who can read Massbus error bits, we've got oodles and oodles of them for you....  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 19 Dec 86 17:44:19 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28498; Fri 19-Dec-86 17:42:01 EST Date: Fri, 19 Dec 86 17:41 EST From: David A. Moon Subject: The KS lost again To: Rob Austein cc: Sollins@MIT-XX.ARPA, POOR-MC@MIT-AI.ARPA In-Reply-To: <132708.861219.SRA@AI.AI.MIT.EDU> Message-ID: <861219174142.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 19 Dec 86 13:36:54 EST From: Rob Austein I walked away from the console too soon. It only stayed up for ten minutes. I am leaving it down so as not to munch the filesystem too much by multiple crashes. ITS doesn't munch the file system when it crashes. If you meant that you were worried about the drive destroying the pack, I hope you spun it down. (Actually, there is a slight risk of munching the file system in 1-drive systems, such as MC, since there is no backup copy of the directories in 1-drive systems. You only lose if the disk aborts a directory write while it's half-written, and then the system crashes before it can complete the write, and it wasn't the MFD (which is reconstructable). Then you might lose all the files in that user directory. The only time I've ever seen anything like this was when the disk controller was destroying data that passed through it without any error indication; that actually creamed a multi-drive system since it often destroyed the backup copies the same way. The software should have been smarter (and slower).) Ideas, other than calling DEC and paying for a visit? I see you called DEC. But the first thing to do would to be get the values of the error registers in the drive and look them up in the incredibly lousy drive documentation to find out what caused the unsafe light to light; there are a dozen or so different things that can do it.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Dec 86 17:05:00 EST Date: Fri, 19 Dec 1986 17:06 EST Message-ID: From: Rob Austein To: Log-Service-Call@XX.LCS.MIT.EDU, Poor-MC@AI.AI.MIT.EDU Subject: KS's RP06 Logged call BC1820 @ 16:57.  Date: Fri, 19 Dec 86 13:36:54 EST From: Rob Austein Subject: The KS lost again To: Sollins@XX.LCS.MIT.EDU, POOR-MC@AI.AI.MIT.EDU Message-ID: <132708.861219.SRA@AI.AI.MIT.EDU> I walked away from the console too soon. It only stayed up for ten minutes. I am leaving it down so as not to munch the filesystem too much by multiple crashes. Ideas, other than calling DEC and paying for a visit?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Dec 86 12:25:10 EST Date: Fri, 19 Dec 1986 12:26 EST Message-ID: From: Rob Austein To: Poor-MC@AI.AI.MIT.EDU cc: Sollins@XX.LCS.MIT.EDU Subject: Really MC, that is, the KS this time I came in, found the KS's RP06 still spinning with its UNSAFE light on (ITS had BUGHLT'd, of course). Saw no obvious gouges in pack, no powdered medium in drive. Did find lint on the foam rubber strip around the top of the pack well. Figuring we had nothing to lose, I powercycled the drive, spun it back up, rebooted. Seems to be running ok. Tyrone theorizes that some seek went too far or something like that. Perhaps we should have somebody check this drive out? Keep in mind that it's not on contract. I'm not sure which is cheaper, PM or CM, under the circumstances.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 17 Dec 86 14:24:39 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25843; Wed 17-Dec-86 13:33:29 EST Date: Wed, 17 Dec 86 13:33 EST From: David A. Moon Subject: palx To: SRA@MIT-XX.ARPA cc: POOR-MC@MIT-AI.ARPA In-Reply-To: <962445.861217.MOON@MX.LCS.MIT.EDU> Message-ID: <861217133335.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 17 Dec 86 01:09:31 EST From: "David A. Moon" Gee, I dunno. I see PALX loading 375 bytes at 11332, and the first 3 words of that data are correct. After remembering that in the stupid pdp11 format the byte counts are off by 6, I realize that this ends at the end of IBOMSG, which is an odd-length thing. The PALX binary hasn't been changed in almost four years. On the other hand, the only PALX source is two years and three versions newer. I tried assembling and using that PALX but it doesn't make any difference. Barf. Here's a procedure that seems to work: pdp11^K :load sra;ioelev bin :adump sra;ioelev nbin ^Z :pcnvrt sra;ioelev nbin I don't remember if we used to have to go through this song and dance. As far as I remember, which is hardly at all, the output from PALX used to work.. The above is all nonsense. Sorry about that. I remembered the correct procedure, which is to use 11STNK to load IOELEV and 11DDT together, then send the output to the front-end file system. I think you use 11DDT 8K on the MX-DL machine and 11DDT 16K on the MX-FE machine. There is probably documentation or command files in the MX:KLDCP; directory, but I can't get to that machine right now.  Date: Wed, 17 Dec 86 06:56:39 EST From: David Vinayak Wallace Subject: New IOELEV on MX's console 11 To: SRA@XX.LCS.MIT.EDU cc: POOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Wed 17 Dec 1986 05:41 EST from Rob Austein Message-ID: <131708.861217.GUMBY@AI.AI.MIT.EDU> I assume all this archeology appears in a file so that when you get run over by a car driven by a drunken iranian suicide-bomber we won't have to repeat it all?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 17 Dec 86 05:39:31 EST Date: Wed, 17 Dec 1986 05:41 EST Message-ID: From: Rob Austein To: Poor-MX@AI.AI.MIT.EDU Subject: New IOELEV on MX's console 11 It seems to work. This one was produced using Moon's suggestion (running the PALX output through TS PDP11 to keep PCNVRT from barfing). The A11 file is much shorter than either of the previous ones I found in the FE's filesystem. Since the code is running on the 11 as I type this, that extra space pretty much has to be the symbol table (but if the dialups don't work anymore, you know why...). I also figured out how to produce a new @ BOOT11, so the last vestiges of the name swap (MX-MC) should disappear soon. So much for archeology.  Received: from MX.LCS.MIT.EDU (CHAOS 1440) by AI.AI.MIT.EDU 17 Dec 86 01:08:42 EST Date: Wed, 17 Dec 86 01:09:31 EST From: "David A. Moon" Subject: palx To: POOR-MC%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <962445.861217.MOON@MX.LCS.MIT.EDU> Gee, I dunno. I see PALX loading 375 bytes at 11332, and the first 3 words of that data are correct. After remembering that in the stupid pdp11 format the byte counts are off by 6, I realize that this ends at the end of IBOMSG, which is an odd-length thing. The PALX binary hasn't been changed in almost four years. On the other hand, the only PALX source is two years and three versions newer. I tried assembling and using that PALX but it doesn't make any difference. Barf. Here's a procedure that seems to work: pdp11^K :load sra;ioelev bin :adump sra;ioelev nbin ^Z :pcnvrt sra;ioelev nbin I don't remember if we used to have to go through this song and dance. As far as I remember, which is hardly at all, the output from PALX used to work..  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 DEC 86 14:27:56 EST Received: from MARLEY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 15852; Tue 16-Dec-86 14:28:30 EST Date: Tue, 16 Dec 86 14:28 EST From: Alan Bawden Subject: Bad file? To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Gumby@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU In-Reply-To: <861216122715.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <861216142826.2.ALAN@MARLEY.AI.MIT.EDU> Date: Tue, 16 Dec 86 12:27 EST From: David A. Moon Date: Tue, 16 Dec 86 06:43:19 EST From: David Vinayak Wallace try reading armte;steveh omail. Might running the salvager help? Running the salvager under timesharing (SALV^K then CHKRG) will find out. The TS salvager never writes into the file system, but it's useful for examining things. ARMTE is allocated to the pack mounted on unit #5 which accumulates locked blocks like crazy. I'll fix this the next time I am near MX... (What a coincidence, it just crashed...)  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 16 Dec 86 12:54:22 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24435; Tue 16-Dec-86 12:26:59 EST Date: Tue, 16 Dec 86 12:27 EST From: David A. Moon Subject: Bad file? To: David Vinayak Wallace cc: POOOR-MC@AI.AI.MIT.EDU In-Reply-To: <131141.861216.___007@AI.AI.MIT.EDU> Message-ID: <861216122715.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 16 Dec 86 06:43:19 EST From: David Vinayak Wallace try reading armte;steveh omail. Might running the salvager help? Running the salvager under timesharing (SALV^K then CHKRG) will find out. The TS salvager never writes into the file system, but it's useful for examining things.  Date: Tue, 16 Dec 86 06:43:19 EST From: David Vinayak Wallace Sender: ___007@AI.AI.MIT.EDU Subject: Bad file? To: POOOR-MC@AI.AI.MIT.EDU Message-ID: <131141.861216.___007@AI.AI.MIT.EDU> try reading armte;steveh omail. Might running the salvager help?  Date: Mon, 15 Dec 86 15:42:53 EST From: Alan Bawden Subject: Making the the Dover Spooler more reliable. To: POOR-MC@AI.AI.MIT.EDU cc: DJB@AI.AI.MIT.EDU Message-ID: <130884.861215.ALAN@AI.AI.MIT.EDU> Because I could never remember that you had to launch the Dover spooler on MC (the KS) by hand every time you brought the machine up, I wrote a demon that will do the launching automatically. (You will recall the problem is that the demon cannot be launched directly, because it uses the PK1: device, which doesn't exist on the new MC. Thus it needs a translation added (PK1: => DSK:) before it can run.)  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 NOV 86 21:37:17 EST Date: Sun, 16 Nov 86 21:31:19 EST From: Rob Austein Subject: KL: .; IOELEV * To: BUG-its@AI.AI.MIT.EDU, poor-mx@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].958244.861116.SRA> I assembled and installed a new version of IOELEV for the KL. The only change is that it now knows that its name has changed (no longer tells you you are connected to MC). I'll change the namespace sometime soon if there aren't any problems with this. While I was installing this silliness, I reorganized the IOELEV binaries. KL Console-11 binaries are (as before) in IOELEV nnnBIN with IOELEV BIN as a link to the latest version (now IOELEV 431BIN). The AI-Chaos-11 binaries are now in IOELEV nnnAI with a link from IOELEV AIBIN to the latest version (IOELEV 430AI, the one where I made subnet six the "primary" address of AI-11 so dover spooling would work better). I don't expect any problems. Next person who cold boots the KL please tell me what happens (if no problems, tell me that). --Rob  Date: Sat, 25 Oct 86 08:39:43 EDT From: "Pandora B. Berman" Subject: Subtle hint To: SRA@XX.LCS.MIT.EDU cc: POOR-MX@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU, ty@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].110598.861025.CENT> Date: Thu 22 May 86 10:28:06-EDT From: Rob Austein Subject: Subtle hint To: poor-mx@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, ty@XX.LCS.MIT.EDU, cent@XX.LCS.MIT.EDU Might I reiterate (obnoxiously loudly) my request that work begin IMMEDIATELY to make a 9-track backup of MX... done. 23 tapes at 1600bpi.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 OCT 86 14:04:46 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 OCT 86 14:03:03 EDT Date: Sat, 4 Oct 86 14:02:23 EDT From: David Vinayak Wallace Subject: latest flakeyness To: poor-mx@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].951054.861004.GUMBY> If anyone cares MX crashed: TTY buffer empty at TYIREM. Dumped to CRASH TYIREM. Then when reloaded the system couldn't talk to the IO 11 and hung. This was probably the csause of the lossage; I dunno; I dumped that to CRASH TYIRE1 just for the hell of it and cold-booted.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 SEP 86 10:56:22 EDT Date: Wed, 24 Sep 86 10:56:08 EDT From: David Vinayak Wallace Subject: unit 1 still busted To: ALAN@AI.AI.MIT.EDU cc: POOOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Tue 23 Sep 86 19:55:00 EDT from Alan Bawden Message-ID: <[MX.LCS.MIT.EDU].948811.860924.GUMBY> Date: Tue, 23 Sep 86 19:55:00 EDT From: Alan Bawden Date: Tue, 23 Sep 86 08:24:26 EDT From: David Vinayak Wallace After the nasty power-glitch this morning MX's unit 1 consented to load its heads and load DDT. However attempting to L any file caused the error "?UN1" which I took to mean that the drive was still gronked. Huh? Unit #1 has been busted for months! What made you think it might have gotten better after a power-glitch? I just switched everything on and attempted to bring the system up. The last time I looked at it unit 1 wouldn't even load its heads; that's why I mentioned it.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 24 Sep 86 00:18:55 EDT Date: Tue, 23 Sep 1986 23:25 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: POOOR-MX@AI.AI.MIT.EDU Subject: unit 1 still busted In-reply-to: Msg of 23 Sep 1986 19:55-EDT from Alan Bawden Date: Tuesday, 23 September 1986 19:55-EDT From: Alan Bawden ... I assume when I get in tomorrow I will be able to read the full story in the system log, right?... Right. With circles and arrows and scroll bars on the sides.  Date: Tue, 23 Sep 86 19:55:00 EDT From: Alan Bawden Subject: unit 1 still busted To: GUMBY@AI.AI.MIT.EDU, POOOR-MX@AI.AI.MIT.EDU In-reply-to: Msg of Tue 23 Sep 86 08:24:26 EDT from David Vinayak Wallace Message-ID: <[AI.AI.MIT.EDU].97741.860923.ALAN> Date: Tue, 23 Sep 86 08:24:26 EDT From: David Vinayak Wallace After the nasty power-glitch this morning MX's unit 1 consented to load its heads and load DDT. However attempting to L any file caused the error "?UN1" which I took to mean that the drive was still gronked. Huh? Unit #1 has been busted for months! What made you think it might have gotten better after a power-glitch? I'm even more confused to come back from vacation to find two pieces of mail in my mailbox telling me how broken the KL is (after apparently two separate power glitches?), yet the machine seems to be up and running right now. I assume when I get in tomorrow I will be able to read the full story in the system log, right?...  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 SEP 86 08:24:29 EDT Date: Tue, 23 Sep 86 08:24:26 EDT From: David Vinayak Wallace Subject: unit 1 still busted To: pooor-mx@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].948471.860923.GUMBY> After the nasty power-glitch this morning MX's unit 1 consented to load its heads and load DDT. However attempting to L any file caused the error "?UN1" which I took to mean that the drive was still gronked.  Date: Sun, 21 Sep 86 04:49:11 EDT From: Rob Austein Subject: Halucinating Power Glitches To: POOR-MX@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].96524.860921.SRA> The Peacekeeper reentered and burned along with the rest of Tech Square (power glitch, sometime between 22:00 and midnight). Unfortunately, when I tried to relaunch, the poor thing started halucinating more power glitches (keeps throwing on its FAULT light). There were other minor annoyances, see log book. Left down. This may need a Real Expert.  Date: Tue, 26 Aug 86 09:20:39 EDT From: "Pandora B. Berman" Subject: further senility To: GUMBY@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].87806.860826.CENT> Date: Tue, 26 Aug 86 05:34:54 EDT From: David Vinayak Wallace Subject: further senility To: CENT@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Date: Tue, 26 Aug 86 02:45:09 EDT From: Pandora B. Berman memory B was getting repeated severe par errs, so with alan providing the remote control knowledge, i deselected it.... That bank is temperature-sensitive. Was it hot up there? it didn't seem to be hot. but it might have been a marginal temperature situation without my noticing. i suppose it's worth our while to try re-enabling B sometime when we're reasonably sure it's not hot near there.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 AUG 86 05:37:09 EDT Date: Tue, 26 Aug 86 05:34:54 EDT From: David Vinayak Wallace Subject: further senility To: CENT@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Tue 26 Aug 86 02:45:09 EDT from Pandora B. Berman Message-ID: <[MX.LCS.MIT.EDU].943466.860826.GUMBY> Date: Tue, 26 Aug 86 02:45:09 EDT From: Pandora B. Berman memory B was getting repeated severe par errs, so with alan providing the remote control knowledge, i deselected it. so now we have mem off 300-777, if anyone is asked. we should think about trying to fix mem B. That bank is temperature-sensitive. Was it hot up there?  Date: Tue, 26 Aug 86 02:45:09 EDT From: "Pandora B. Berman" Subject: further senility To: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].87727.860826.CENT> memory B was getting repeated severe par errs, so with alan providing the remote control knowledge, i deselected it. so now we have mem off 300-777, if anyone is asked. we should think about trying to fix mem B.  Date: Mon, 28 Jul 86 15:48:58 EDT From: Alan Bawden Subject: KL's Tape's Belt To: KARENS@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU, TY@AI.AI.MIT.EDU, DEC@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].76637.860728.ALAN> Is there any progress on finding a replacement rubber belt for the KL's tape drive? It isn't going to get any easier to deal with this as time passes...  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 10 Jul 86 20:53:41 EDT Date: Thu 10 Jul 86 20:51:23-EDT From: J. J. Tyrone Sealy Subject: Re: MX tape drive losing To: CENT@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU, DEC@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].68126.860710.CENT> Message-ID: <12221686922.38.TY@XX.LCS.MIT.EDU> T'was I the guilty one.. I forgot to send ye mail..Lester is trying to remember where he last saw some of the belts.. lets ope he finds one/some soon.. -------  Date: Thu, 10 Jul 86 20:33:18 EDT From: "Pandora B. Berman" Subject: MX tape drive losing To: POOR-MC@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU cc: DEC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].68126.860710.CENT> moon came by this evening to help alan zero MX's memory, and while he was here he looked at its tape drive, which for the record is a TU40. someone (JTW?) had already dived into the drive's innards and removed a rubber belt which was in very bad shape. replacing the belt made loading tapes almost work -- until the belt popped off its wheels due to its advanced decrepitude. so moon's diagnosis is that we need a new Vacuum Pump Belt -- that was the only designation we found in the manual, no part number (though perhaps by now DEC has assigned part numbers to pieces of TU40s; our manual is after all 10 years old). we can install it ourselves, so all we need is to get our hands on the part. is there one of these around somewhere? if not, can we arrange to order one -- it should be quite cheap (alan is threatening to pay for it himself if LCS won't, and he's a semi-starving grad student...).  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 7 Jul 86 14:06:37 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 36687; Mon 7-Jul-86 13:29:13 EDT Date: Mon, 7 Jul 86 13:28 EDT From: David A. Moon Subject: MX tape drive losing To: Pandora B. Berman cc: POOR-MC@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].66233.860707.CENT> Message-ID: <860707132827.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Sounds like a mechanical problem. I can't remember if these symptoms are what happens when the two little rubber belts inside break or pop off. I think we have a maintenance manual for this tape drive, unless it's been lost, so maybe someone could take a look. I might do it, but probably won't have time for a week or so. Having DEC fix it sounds like a good investment in preserving all that information on backup tape, presuming they won't "fix" it the way they "fixed" MX's RP04 #1 (taking it away and bringing in a broken one to replace it).  Date: Mon, 7 Jul 86 01:41:48 EDT From: "Pandora B. Berman" Subject: MX tape drive losing To: POOR-MC@AI.AI.MIT.EDU cc: KARENS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].66233.860707.CENT> this evening i discovered that MX's tape drive is broken. syndrome: when trying to load a tape, it does wind it onto the take-up reel, but does not suck it down into the vacuum columns. i tried cleaning the beast, which can't have hurt (it was FILTHY), but didn't help. now what? does anyone understand enough about TU-whatever-it-is-s to fiddle with its innards? can we (beg, plead) pay to have dec frob it? some progress has been made in the old-MC-tapes preservation movement -- Alan has copied the most recent several GFR tapes onto 9track 1600bpi -- but there are still large amounts of stuff only on 7track which we could greatly profit from having available (having the opportunity to copy to the more readable format).  Date: Sun, 6 Jul 86 22:52:26 EDT From: Alan Bawden Subject: .... To: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].66158.860706.ALAN> The KL's RP04 unit #1 may have bitten the dust. It can no longer read its TUT without hard ECC errors. Perhaps we shouldn't have let DEC give us a "new" RP04 a month before the machine went off contract. Say, what ever happened about amateur maintenance for the KL? (People to check the fans once a week, etc.)  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 30 May 86 11:29:55 EDT Date: Fri 30 May 86 11:29:25-EDT From: Karen R. Sollins Subject: Re: KL COMSAT reconfigured To: JNC@XX.LCS.MIT.EDU cc: SRA@MC.LCS.MIT.EDU, pooor-mx@AI.AI.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: <12210711153.11.JNC@XX.LCS.MIT.EDU> Message-ID: <12210836715.25.SOLLINS@XX.LCS.MIT.EDU> I assumed that the lcs.mit.edu subdomain did the right thing by MX. I think it should. -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 30 May 86 00:00:43 EDT Date: Thu 29 May 86 23:59:41-EDT From: "J. Noel Chiappa" Subject: Re: KL COMSAT reconfigured To: SRA@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, pooor-mx@AI.AI.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].5519.860529.SRA> Message-ID: <12210711153.11.JNC@XX.LCS.MIT.EDU> IMP port 1/6 is perfectly legal to use; it's enabled and our sponsor is paying for it. I don't think that's an issue. The name might be. Any reason not to just have the LCS.MIT.EDU namespace do the right thing for MX, and if the NIC won't put it in their table, tough noogies? People should be using domains anyway. -------  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 29 May 86 16:14:27 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11091; Thu 29-May-86 14:49:08 EDT Date: Thu, 29 May 86 14:48 EDT From: David A. Moon Subject: Re: hardware status To: John Wroclawski cc: poor-mc@AI.AI.MIT.EDU In-Reply-To: <12210470941.7.JTW@SPEECH.MIT.EDU> Message-ID: <860529144826.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu 29 May 86 02:00:10-EDT From: "John Wroclawski" I deconfigured the ampex the other day, basically because I was screwing around. In particular, I wanted to try out running with 4-way interleaving, which at that time I thought the ampex couldn't do because some of the processor's ports were broken (JNC later said he thinks this is not true. Experiments to follow, maybe.) The Ampex has only 2 banks, so it certainly can't give higher performance with 4-way interleave than with 2-way. Where the other two banks should be is just air, because Joel didn't want to spend that much money. I don't know about the ports being broken, but it wouldn't surprise me one bit. The port transceivers on the Ampex are excrement. Also, I was running memory tests the other day when I was frobbing with the kludge. The ampex seems to get the occasional parity error during hard use - nothing horrible. On the other hand the MH10 that is marked as being bad ran OK at that point. Perhaps the problem was the tape DF10 port all along. Could be. Anyway, it seems we have a meg of good MH10 memory, at least from the processor's point of view. One could even run 4-way interleaved and speed things up a bit, if one remembered to type J KLINI4 instead of J KLINIT, which runs 2-way. If the ampex can indeed do 4-way OK I will probably turn it back on and change the default. Does anyone think the machine -needs- more than 1M of memory with the use it is getting these days? Well, it needs more than 1M less than AI needs more than 0.5M. But why not use it if it's there? I measured the performance difference between 2-way and 4-way interleave once (running Macsyma I guess) and it was tiny.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAY 86 02:01:00 EDT Date: Thu 29 May 86 02:00:10-EDT From: "John Wroclawski" Subject: Re: hardware status To: poor-mc@AI.AI.MIT.EDU In-Reply-To: <[MX.LCS.MIT.EDU].922260.860528.GUMBY> Message-ID: <12210470941.7.JTW@SPEECH.MIT.EDU> I deconfigured the ampex the other day, basically because I was screwing around. In particular, I wanted to try out running with 4-way interleaving, which at that time I thought the ampex couldn't do because some of the processor's ports were broken (JNC later said he thinks this is not true. Experiments to follow, maybe.) Also, I was running memory tests the other day when I was frobbing with the kludge. The ampex seems to get the occasional parity error during hard use - nothing horrible. On the other hand the MH10 that is marked as being bad ran OK at that point. Perhaps the problem was the tape DF10 port all along. Anyway, it seems we have a meg of good MH10 memory, at least from the processor's point of view. One could even run 4-way interleaved and speed things up a bit, if one remembered to type J KLINI4 instead of J KLINIT, which runs 2-way. If the ampex can indeed do 4-way OK I will probably turn it back on and change the default. Does anyone think the machine -needs- more than 1M of memory with the use it is getting these days? -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAY 86 00:58:30 EDT Date: Thu, 29 May 86 00:58:10 EDT From: Rob Austein Subject: KL COMSAT reconfigured To: sollins@XX.LCS.MIT.EDU, pooor-mx@AI.AI.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].5519.860529.SRA> The KL is now running a COMSAT configured as if it were a chaos-only machine. It uses MC (Chaos 3131) as its gateway. This will load the KS a little more for outgoing net traffic, but will do the right thing for headers (we are -not- going to get the NIC to put MX in the tables before the poor thing melts down) and is probably the right thing politically anyway, since it cuts down on the amount of (unapproved) traffic through IMP port 1/6. I haven't messed with FTPS or anything like that, so anybody who knows enough to talk to 10.1.0.6 will still win. --Rob  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 23:57:33 EDT Date: Wed, 28 May 86 23:58:32 EDT From: David Vinayak Wallace Subject: hardware status To: pooor-mc@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].922260.860528.GUMBY> After much abuse I was able to coerce the KL into booting, but I can't get it to talk to the upper half of memory (400-777). If anyone knows something I wish they'd tell me. It looks to me like someone has frobbed the ampex such that it has all been disabled, but since I don't know how those switches are normally set I don't want to frob them.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 MAY 86 23:48:45 EDT Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 25 May 86 23:48:36 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7851; Sun 25-May-86 23:46:32 EDT Date: Sun, 25 May 86 23:46 EDT From: David A. Moon Subject: Tape copying To: Poor-MX@MIT-MC.ARPA Message-ID: <860525234602.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I hereby declare the 7-track to 9-track tape copying software finished and debugged. To use it, run DUMP on MX, use the REMOTE command to select the host whose tape drive you are going to use to write 9-track tapes, then when it says REMOTE TAPE REWOUND and prompts with _, press c-Z, type TCOPYG, and answer the questions. You can copy two 7-track reels onto each 9-track reel.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 MAY 86 16:33:36 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 MAY 86 16:30:55 EDT Date: Sun, 25 May 86 01:55:03 EDT From: "David A. Moon" Subject: MC tape copying To: sollins@XX.LCS.MIT.EDU, poor-mx@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].921327.860525.MOON> I copied what I thought were the last 2 MC-KL GFR tapes (but later I found four newer ones out of order on the tape rack) onto 9-track tape, using the TCOPY routine in MX:MOON;TS ND. I had the good luck to encounter a tape with an irrecoverable error in it, so I know the error recovery routine works. We should proceed copying gradually older tapes as time permits. I used a tape kindly donated by the AI Lab. LCS should come up with the tapes for this. After the copy is finished, they can do whatever they want with the old 7-track tapes (I would save them for a while). I'm putting the newly copied GFR tapes onto the tape rack near MC-KL, on the opposite side from the old GFR tapes. This way anyone who wants to copy tapes can tell which tapes someone else has copied. I am copying two 7-track tapes onto each 9-track tape to economize on tapes and floor space for storing them.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 MAY 86 03:14:46 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 MAY 86 03:14:27 EDT Date: Sun, 25 May 86 03:14:22 EDT From: "David A. Moon" Sender: ALAN@AI.AI.MIT.EDU To: poor-mx@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].45826.860525.ALAN> Whoever brings the KL up next should take drive 1 offline!  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 MAY 86 02:48:12 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 MAY 86 02:35:15 EDT Date: Sun, 25 May 86 02:34:39 EDT From: "David A. Moon" Subject: tape copying (p.s. to previous message) To: poor-mx@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].921342.860525.MOON> Well, the routine for copying two tapes onto one still has a bug in it (it writes a logical eot at the end of the first tape, so you can't get to the copy of the second tape). I'll fix that when I have time to test it, in the meantime copy one tape per 9-track tape or fix the bug yourself.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 MAY 86 02:28:25 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 MAY 86 02:12:52 EDT Date: Sun, 25 May 86 01:55:03 EDT From: "David A. Moon" Subject: MC tape copying To: sollins@XX.LCS.MIT.EDU, poor-mx@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].921327.860525.MOON> I copied what I thought were the last 2 MC-KL GFR tapes (but later I found four newer ones out of order on the tape rack) onto 9-track tape, using the TCOPY routine in MX:MOON;TS ND. I had the good luck to encounter a tape with an irrecoverable error in it, so I know the error recovery routine works. We should proceed copying gradually older tapes as time permits. I used a tape kindly donated by the AI Lab. LCS should come up with the tapes for this. After the copy is finished, they can do whatever they want with the old 7-track tapes (I would save them for a while). I'm putting the newly copied GFR tapes onto the tape rack near MC-KL, on the opposite side from the old GFR tapes. This way anyone who wants to copy tapes can tell which tapes someone else has copied. I am copying two 7-track tapes onto each 9-track tape to economize on tapes and floor space for storing them.  Date: Sat, 24 May 86 21:14:21 EDT From: "John T. Wroclawski" Subject: KL revived To: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].45601.860524.JTW> Moon found a bad power supply in the Kludge. I installed a new one, and things seem OK for now. Leaving us with: KL running OK with 1Meg of MH memory, ampex off. RH10 seems OK, survived an hour of reliability diags fine. RP04 #1 can be made to reliably screw up trying to write and read back worst-case data patterns... Not really sure if you can use the tape without causing parity errors..  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 MAY 86 10:28:59 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 May 86 10:29:19 EDT Date: Thu 22 May 86 10:28:06-EDT From: Rob Austein Subject: Subtle hint To: poor-mx@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, ty@XX.LCS.MIT.EDU, cent@XX.LCS.MIT.EDU Message-ID: <12208728402.10.SRA@XX.LCS.MIT.EDU> Might I reiterate (obnoxiously loudly) my request that work begin IMMEDIATELY to make a 9-track backup of MX and 9-track copies of the old KL GFR tapes? We've gotten more reprieves than we deserve already. -------  Date: Thu, 22 May 86 07:43:30 EDT From: "Pandora B. Berman" Subject: more lossage To: POOR-KL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44592.860522.CENT> 7am: mx went down claiming MASSBUS ERR i dumped it to MASBUS ERR and brought it up. it crashed again as soon as it came up. leaving it down until someone more wizardly than me arrives to reset the massbus.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 MAY 86 04:42:52 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 04:43:16 EDT Date: Thu, 22 May 86 04:42:25 EDT From: "Pandora B. Berman" Subject: more progress To: MOON@AI.AI.MIT.EDU cc: KARENS@AI.AI.MIT.EDU, POOR-MX@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44495.860522.CENT> Date: Thu, 22 May 86 04:11:24 EDT From: "David A. Moon" To: POOR-MX@MC.LCS.MIT.EDU The tape DF10 wasn't really broken, it was actually MH10 C screwing up the DF10's memory bus. That old reliable flip chip hardware doesn't break when heated to a mere 100 degrees. Not having any spare M8594s, I moved the DF10 bus to a spare port. I'll leave the system up, but in debug mode and with the network turned off. The tape drive works. he forgot to add that, after consultation with JTW and alan, he brought it up in normal mode.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 MAY 86 04:29:31 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 04:29:57 EDT Date: Thu, 22 May 86 04:29:44 EDT From: "David A. Moon" Subject: Daemon joke of the day To: poor-mx@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].920450.860522.MOON> mx:channa;rakash glpspl crashes when the system comes up because mx is not in its assembled in list of known hosts.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 MAY 86 04:10:56 EDT Date: Thu, 22 May 86 04:11:24 EDT From: "David A. Moon" To: POOR-MX@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].1561.860522.MOON> The tape DF10 wasn't really broken, it was actually MH10 C screwing up the DF10's memory bus. That old reliable flip chip hardware doesn't break when heated to a mere 100 degrees. Not having any spare M8594s, I moved the DF10 bus to a spare port. I'll leave the system up, but in debug mode and with the network turned off. The tape drive works.  Date: Wed, 21 May 86 23:55:16 EDT From: "Pandora B. Berman" Subject: logbook location To: SRA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44369.860521.CENT> Date: Wed, 21 May 1986 23:18 EDT From: Rob Austein To: "Pandora B. Berman" Cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Subject: At the tone, your name will be It would probably help if the ML and MD system logs were in some intuitively obvious place. Now that you have reminded me of their existance I suspect they are sitting on top of the CPUs or disks or something. If they were sitting by the consoles some of us space cadets might have remembered their existance and scrawled something in them. if i could have put them safely any closer to the consoles, i would have. i agree that on top of the CPUs is not the best location for visibility and memory-jogging, but it appeared to be the best i could do. if we could get some kind of little table beside MD's console (shoving the IMPLOD cabinet over), that would be better.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 23:17:32 EDT Date: Wed, 21 May 1986 23:18 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Subject: At the tone, your name will be In-reply-to: Msg of 21 May 1986 22:57-EDT from "Pandora B. Berman" It would probably help if the ML and MD system logs were in some intuitively obvious place. Now that you have reminded me of their existance I suspect they are sitting on top of the CPUs or disks or something. If they were sitting by the consoles some of us space cadets might have remembered their existance and scrawled something in them.  Date: Wed, 21 May 86 22:57:57 EDT From: "Pandora B. Berman" Subject: At the tone, your name will be To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44335.860521.CENT> I have relabelled everything in sight except the KS's tapes; i'll get to those later this evening. i rediscovered the winning sort of labels, so the binder labels should no longer be quite so eager to come off. NOTHING has been written in the ML and MD system logs for at least a week. nothing about bringing them down for DEC to borrow or loaning disks to XX or any such matters. will someone who knows what's been going on (SRA? JTW?) please insert a few notes so the rest of us can remain mildly informed?  Date: Wed, 21 May 86 00:35:26 EDT From: Alan Bawden Subject: 6 5 4 3 2 1 ... To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU, "(FILE [JNC:POOR MC])"@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].43668.860521.ALAN> OK folks, I switched the names MC and MX in the ITS sources and created new binaries for the two machines. I also edited AI:SYSHST;HSTLCS to reflect the swap. So the first symptom of this name swap that anyone will notice will appear early this morning when new host tables start circulating with the Chaosnet addresses switched. (Because we are switching both ArpaNet addresses and physical connections, the change manifests itself in the host tables as exchanged Chaosnet addresses.)  Date: Tue, 20 May 86 19:02:57 EDT From: David Chapman Subject: pword follies To: ALAN@AI.AI.MIT.EDU cc: BUG-PWORD@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Tue 20 May 86 16:17:05 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].43388.860520.ZVONA> Maybe we should try copying over the AI database and then deleting from that (unless Cstacy tells us how to win). I started to do this until I realized that I needed your edits for it to be even faintly plausible.  Date: Tue, 20 May 86 16:17:05 EDT From: Alan Bawden Subject: pword follies To: BUG-PWORD@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].43173.860520.ALAN> I made some minor edits to the PWORD sources with the intent that we would bring PWORD up on the KS since it becomes MC tomorrow morning. Unfortunately I couldn't figure out how to make an empty PWORD database. I guess we'll just run DDT on both the KL and the KS until someone figures this out. I changed the source to look for the database in the same place on both the KL and the KS. This means that you have to -move- the database on the KL before installing a new PWORD there. The database wants to live in the same place so that you don't need a complicated algorithm based on cpu type to figure out where the database is. You Grok?  Date: Tue, 20 May 86 16:10:03 EDT From: Alan Bawden Subject: MC up To: KARENS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Tue 20 May 86 01:38:49 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].43165.860520.ALAN> Given that JTW fixed the problem with unit #2, I spent the afternoon filling the holes in MC's filesystem. MC is now up and running about as well as it was a week ago. Some mail was lost (not much), and some mail is still trapped in a busted comsat database. We're going to try to do the name swap tomorrow morning. Oh boy.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 MAY 86 02:33:04 EDT Date: Tue 20 May 86 02:34:50-EDT From: "John Wroclawski" Subject: Re: I have good news, and bad news To: ALAN@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU Message-ID: <12208117956.19.JTW@MIT-SPEECH> From: Alan Bawden The single -new- problem is that unit #2 is now exhibiting one of the canonical RP04 lossages: it is unable to fully retract its cleaning brushes. This can be fixed by someone who I fixed this. It isn't going to last forever; there's a pretty sick bearing in there. -------  Date: Tue, 20 May 86 01:38:49 EDT From: Alan Bawden Subject: I have good news, and bad news To: POOOR-MC@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42865.860520.ALAN> Well, there wasn't anything wrong with MC's processor after all. No irreplaceable processor boards were lost. The single -new- problem is that unit #2 is now exhibiting one of the canonical RP04 lossages: it is unable to fully retract its cleaning brushes. This can be fixed by someone who knows what they are doing in about 5 minutes. All we have to do is find someone like that. Until unit #2 gets fixed, Moon and I figured we would simply move pack 1 from unit #2 to unit #1, and take pack 13 (SECOND) off-line. You may recall that unit #1 is the one DEC replaced last month because they couldn't fix the old unit #1. Since then I have been warning people not to create new files on pack 13 because I was under the impression that it had been mis-formatted by the old drive. Well, I was wrong, and tonight we learned just how wrong in a slightly painful way. After ITS had run for an hour or so, it filled pack 0 up to a point where it thought it might be a good idea to switch to creating files on pack 1 for a while. At this point Alan learns that what DEC had convinced him of last month was in fact not true. Unit #1 really -is- still broken. It can read files just fine, but something like one out of every hundred blocks it writes are unreadable. So now we have a few files on pack 1 that contain locked and unreadable blocks, and probably a few more that are unreadable that ITS hasn't discovered yet. The most important known casualty is .MAIL.; LISTS MSGS (COMSAT's database of queued mail). This is a familiar story these days. DEC can't fix it, so your filesystem gets gubble written in it. Fortunately, the ITS filesystem is built from pretty stern stuff, so although we might lose a file or two, the whole thing is much less likely to crumble around our ears. So here is where we stand: MC's filesystem contains a couple of bruises, but nothing severe. However we can't really run MC untill one of the drives gets fixed (unit #2 should be easy, as I said before) without risking further damage to the filesystem. A few cycles from a COMSAT wizard will be required to either fix its database and get COMSAT running again, or to at least rescue the mail currently trapped in its queue (I can explain the nature of the lossage further in person). The most important thing we can get from MC right now is to empty the last valuable stuff from its filesystem, and to use it to copy 7 track tapes. I know how we can safely accomplish both of these tasks using the 1.5 RP04's we have left, but I would rather not get into that here, and I hope we won't need to. I would recommend that the IMP reconfiguration take place as soon as possible so that we can bring the MC KS online. We can't really make the KS be MC until Zvona finishes with the great mailing list migration. He estimated to me today that he had about 8 hours work to go, but he was handicapped by not having access to the mailing lists file on MC. Fortunately while MC was up Penny grabbed a copy, so now AI:.MAIL.;.MCNEW NAMES contains a copy of the NAMES file currently on the KL. (We should give Zvona a medal when he finishes this job. (Zvona: if you need any more files from the KL, I'll be happy to get them back for you!)) Question: We are going to need a mess of tapes for copying MC's GFR tapes to 9-track tapes and also for doing a last full dump to 9-track (and perhaps copying a couple more older full dumps to 9-track). How does one go about obtaining such large numbers of tapes? Who's going to pay for it? If I truck on down to the stock room and ask for 100 reels of tape, I presume they will want some kind of coherent story about who should be charged for it...  Date: Mon, 19 May 86 02:59:35 EDT From: "John T. Wroclawski" Subject: A stunning example of murphy in action... To: POOOR-MC@AI.AI.MIT.EDU cc: sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42542.860519.JTW> Further study shows that the MC CPU board which has failed is a) One of only two types of board (out of about 20) of which there is only one instance in the machine, preventing swapping. b) One of a handful of types of board not shared with model B processors such as the TOPS20 machines, preventing swapping...  Date: Sun, 18 May 86 21:26:53 EDT From: "John T. Wroclawski" To: POOOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42471.860518.JTW> Well kids, according to the DEC diagnostics MC's CPU has had it...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 MAY 86 07:29:45 EDT Date: Sat, 17 May 86 07:28:06 EDT From: David Vinayak Wallace Subject: heat problems To: POOOR-MC@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].918143.860517.GUMBY> MC crashed this morning when the overtemp sensor in MH10-B tripped. The bay wouldn't cool with the door shut so I opened it up and put a sign on it. If anyone knows where we can get another of the big grey "cake" fans that would be great -- one of them in that bay is a bit wimpy. The muffin fans on the memory seem to work OK. david  Date: Thu, 15 May 86 02:21:16 EDT From: "Pandora B. Berman" Subject: mc flag day To: JNC@XX.LCS.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].41251.860515.CENT> Date: Wed 14 May 86 20:07:06-EDT From: "J. Noel Chiappa" Subject: Re: mc flag day To: ALAN@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, ricchio@XX.LCS.MIT.EDU The latest theory of the port swap is that we will do the hardware change.... I think the technical description of the situation, Noel, is Shit For Brains.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 14 May 86 20:09:56 EDT Date: Wed 14 May 86 20:07:06-EDT From: "J. Noel Chiappa" Subject: Re: mc flag day To: ALAN@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, ricchio@XX.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].40905.860514.ALAN> Message-ID: <12206736652.69.JNC@XX.LCS.MIT.EDU> The latest theory of the port swap is that we will do the hardware change. That's right, after filing 42 forms, each of which had at least 193 questions in gobbledygook military industrial complex quasi-lingual acronymese, no less than 69% of which were completely irrelevant to the task at hand, but which had to be filled out anyway, in quintuplicate, in the office of the under sub assistant paper frobber for the maintainence of network well being, they have decided that the *right thing* is for us to power down the two IMP's in question and move the adaptors ourselves; i.e. something we could have done several months ago without saying a goddam word to the bozos who run this insane asymlum of an excuse for an organized and responsive support and maintainence organization. I don't know if they scare the Russians, but they sure as hell scare me. Noel -------  Date: Wed, 14 May 86 13:19:12 EDT From: Alan Bawden Subject: mc flag day To: ZVONA@AI.AI.MIT.EDU cc: POOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Wed 14 May 86 09:43:17 EDT from David Chapman Message-ID: <[AI.AI.MIT.EDU].40905.860514.ALAN> Date: Wed, 14 May 86 09:43:17 EDT From: David Chapman Date: Tue, 13 May 86 12:50:10 EDT From: Alan Bawden ... In the case of $^A, of course, I decided not to do anything about it. I don't understand why ``of course,'' but presumably you have the situation under control. ``of course'' because I thought we had talked about that particular case in person the other day. Perhap that was someone else I had that conversation with. We should make up a list of what needs to be done before the flag day, if there is more than a couple things. I should be done with mailing lists and INQUIR by Tuesday. Maybe it would be better to phase it? Stage one changes the primary name of KL to KL, retaining the secondary name MC. That lets anything break that depends on all KLs having a primary name MC. Stage two moves the name MC to KS, which keeps KS as primary name. That lets things break that depend on MC being a KL. Stage three makes MC the primary name for KS and possibly moves the name MX to KL.... I have always imagined that the swap happens as follows: One day we come in and find that MC/KL no longer has a network connection because the coolies from BBN have finally converted the IMP port. At this moment we go and make the final edits to the ITS sources that officially swap the names and assemble the first MC/KS and KL/MX systems. Then we take down both the KL and the KS. Now it would be nice if it this point we can get the host tables to change to reflect the new names and Chaosnet addresses while both machines are down. Dream on. We leave KL/MX down until we get everything else working since the important goal is to keep "MC" working. We bring up MC/KS, and we spend the rest of the day putting out the minor fires that this sets. Initially the only mail going through MC/KS is coming in from the Internet, but gradually as more people pick up the new Chaosnet address the mail load picks up. When we are happy that MC/KS works, then at our leisure we can bring up KL/MX.  Date: Fri, 9 May 86 02:23:17 EDT From: "David A. Moon" Subject: Tape copying To: POOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36591.860509.MOON> MC:MOON;TS ND was able to copy a couple of MC GFR tapes onto a 9-track, 1600 bpi tape on Gutenberg's drive. Beware: that's another hardware/Unix combination that likes to go into 6250 bpi when you're not looking. ITS dump tapes don't work at 6250 bpi. The tape copying is pretty fast. To use it, start up ND and use the REMOTE command to specify your tape server. Then hit c-G and type TCOPYG and answer the questions. You can copy two 800 bpi tapes onto each 1600 bpi tape. I fixed a couple of things in the program and reassembled after I was done testing it, and didn't retest, but I don't think I broke anything. The only thing I haven't tested is recovery from tape errors, because I wasn't able to find any unreadable tapes to copy from. It's supposed to print an error message and copy whatever bad data it gets onto the output tape where it will masquerade as good data, but I don't know whether it works.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 MAY 86 05:06:41 EDT Date: Thu, 8 May 86 05:06:34 EDT From: Rob Austein Subject: supplement to MC: CRASH; CRASH DRGFKT To: pooor-mc@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].906917.860508.SRA> [The following was made a minute or so before MC gave up the ghost] MC ITS 1573 Peek 615 5/8/86 04:36:30 Up time = 8:11:52:58 ERRS: CORPAR =! 4 Memory: Free=979 Runnable Total=201 Out=3 Users: High=62 Runnable=2 Index Uname Jname Sname Status TTY Core Out %Time Time PIs 0 SYS SYS SYS HANG ? 89 0 0% 26:49 1 CORE JOB CORE UUO ? 0 0 0% 32:40 2 ___002 TCP ___002 OPEN ? 0 0 0% 4 46TLNT TELSER MIT-XX SLEEP ? 1 0 0% 5 ___005 TELSER TELNET CHAOSO ? 81 18 0% 7 354C07 FILE MEDG PKTIOT ? 7 0 0% 9 10 PFTHMG DRAGON DRAGON *10!0 ? DSN 9 1 0% 52:39 REALTM PDLOV SCLOCK 11 V80 SPOOLR DCP HANG ? 11 0 0% 12 ___002 JOB.05 SYS 3!7777777777 ? 1 0 0% 4:31 13 COMSAT IV IV WALK<21 ? 190 1 2% 41:42 REALTM PURPG 16 GIF HACTRO GUEST1 TTYI ? DSN 30 3 0% 2 31 GIF MAIL GUEST1 *10!0 < DSN 93 18 0% 1 17 CENT5 HACTRN ARM HANG > 30 3 0% 5 6 CENT5 DUMP FIRST MTAPE T43 B 17 0 0% 1 20 52TLNT TELSER MIT-AI SLEEP ? 1 0 0% 3 21 COMSAT JOB.07 SYS *LOGOUT>13 ? 103 16 0% 1:12:18 22 A2DEH HACTRO SYS2 TTYSO ? DSN 30 3 0% 4 34 A2DEH FR GUEST0 TTYI ? DSN 86 17 0% 23 A2DEH ARGUS GUEST0 HANG ? DSN 2 0 0% 24 SRA HACTRN SRA HANG > 30 3 0% 1 14 SRA P SRA MULTIX T46 C 11 2 0% 30 JNC HACTRN JNC TTYI T35 30 3 0% 1 33 CENT HACTRN .MAIL. TTYI T52 30 3 0% 7 25 CENT E ARM 10!0 < 90 5 0% 6 40 CENT P CENT 10!0 < 89 19 0% 9 41 51TLNT TELSER 424527 SLEEP ? 1 0 0% 3 43 54TLNT TELSER 7B-HUB SLEEP ? 1 0 0% 1 44 GUMBY HACTRN BMT1 TTYI T54 35 3 0% 7 50 GUMBY E GUMBY 10!0 < 124 6 0% 6:24 REALTM 45 TARAKA DVRSPL CENT *10!0 ? DSN 30 2 0% 27:06 MPV 20 46 GUMBY ARGUS GUMBY HANG ? DSN 2 0 0% 51 BIL HACTRN JOEK TTYI T51 30 3 0% 9 54 LARRY HACTRO LARRY HANG > DSN 35 3 0% 6 3 LARRY FTP LARRY TTYI ? DSN 91 18 0% 52 LARRY LISP LARRY 10!0 < DSN 147 0 0% 31 61 LARRY NE LARRY 10!0 < DSN 79 10 0% 31 Fair Share 44% Totals: 1636 3% 4:26:38 Logout time = 1:00:01:08 Lost 0% Idle 0% Null time = 5:21:52:40  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 APR 86 18:27:31 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 27 Apr 86 18:27:42 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11111; Fri 25-Apr-86 17:45:39 EST Date: Fri, 25 Apr 86 17:46 EST From: David A. Moon Subject: Re: down on Thursday To: J. J. Tyrone Sealy cc: poor-mc@MIT-MC.ARPA In-Reply-To: <12201690823.41.TY@XX.LCS.MIT.EDU> Message-ID: <860425174601.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri 25 Apr 86 13:09:32-EST From: J. J. Tyrone Sealy The dump was completed..the drive survived.. 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?? The ITS software can certainly handle 9-track drives on TM10 controllers, since that's what DM had. That would let us dump MC onto 9-track tape. It wouldn't give us a way to recover the contents of all those 7-track dumps lying around after MC dies, which is the goal that would really be good to achieve. They are suppose to have about eight drives (working), that are gathering dust and space.. I guess this should be investigated.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 APR 86 18:16:37 EDT Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 27 Apr 86 18:16:42 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 MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 APR 86 10:18:58 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 26 Apr 86 10:18:44 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 MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 APR 86 13:13:25 EST Received: from MC.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 APR 86 13:13:13 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 25 Apr 86 13:10:31 EST Date: Fri 25 Apr 86 13:09:32-EST From: J. J. Tyrone Sealy Subject: Re: down on Thursday To: Moon@SCRC-STONY-BROOK.ARPA cc: poor-mc@MC.LCS.MIT.EDU In-Reply-To: <860423222547.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12201690823.41.TY@XX.LCS.MIT.EDU> The dump was completed..the drive survived.. 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.. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 APR 86 23:21:55 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 23 Apr 86 22:41:43 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 470754; Wed 23-Apr-86 22:26:37-EST Date: Wed, 23 Apr 86 22:25 EST From: David A. Moon Subject: down on Thursday To: J. J. Tyrone Sealy cc: poor-mc@MIT-MC.ARPA In-Reply-To: <12201146871.25.TY@XX.LCS.MIT.EDU> Message-ID: <860423222547.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed 23 Apr 86 11:21:31-EST From: J. J. Tyrone Sealy I will have the machine in standalone mode most of the day, to do last official full dump..The tape drive is not expected to survive the 50+ tapes that it takes (Sez DEC...).We shall see..Its still on service...any other problems WE should let DEC know/fix???? If the RP04 that has the SECOND: pack on it is still broken such that it gets a lot of read errors, and DEC is not going to fix it, you are probably better off taking it offline before doing the dump, so as not to be hassled by lots of disk errors. We're going to try to get a full dump onto 9-track tape soon, but you should go ahead and do the 7-track full dump anyway.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 APR 86 18:56:32 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 23 Apr 86 18:35:27 EST Date: Wed 23 Apr 86 11:21:31-EST From: J. J. Tyrone Sealy Subject: down on Thursday To: poor-mc@MC.LCS.MIT.EDU Message-ID: <12201146871.25.TY@XX.LCS.MIT.EDU> I will have the machine in standalone mode most of the day, to do last official full dump..The tape drive is not expected to survive the 50+ tapes that it takes (Sez DEC...).We shall see..Its still on service...any other problems WE should let DEC know/fix???? --TY -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 APR 86 17:33:43 EST Date: Thu, 10 Apr 86 17:32:46 EST From: Alan Bawden Subject: The PARERR that broke the KL's back To: GUMBY@MC.LCS.MIT.EDU cc: POOR-MC@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 10 Apr 86 14:00:04 EST from David Vinayak Wallace Message-ID: <[MC.LCS.MIT.EDU].880598.860410.ALAN> Date: Thu, 10 Apr 86 14:00:04 EST From: David Vinayak Wallace At least I think that's what it is; MC had been getting them for the past 8 hours or so. Dumped to CRASH URET2 if anyone cares (bugpc/ caia uret2+2 $Q-1/ pushj p,bugnil) Has nothing to do with parity errors. This is one of the three or four canonical software bugs. Something in the RENAME system call fails to unlock all of its locks. The process of launching a comsat seems to tickle it every few months. Also, the GW tables are filling up every five or ten minutes rather than every hour or so. Isn't that a bug, or am I just confused? No real problem. Ignore it.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 APR 86 17:11:02 EST Date: Thu, 10 Apr 86 17:10:01 EST From: Alan Bawden Subject: The PARERR that broke the KL's back To: JNC@XX.LCS.MIT.EDU cc: GUMBY@MC.LCS.MIT.EDU, POOR-MC@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 10 Apr 86 14:57:33-EST from J. Noel Chiappa Message-ID: <[MC.LCS.MIT.EDU].880572.860410.ALAN> Date: Thu 10 Apr 86 14:57:33-EST From: J. Noel Chiappa There was some discussion of the 'GW TBL FULL' message on the BUG-TCP mailing list on MC a while ago, but some vandal seems to have deleted the old archives (maybe they just rename them, I didn't check). They renamed them: MC:KSC;BUGTCP MAIL -> MC:KSC;BUGTCP OMAIL See if you can find them; if not, I'll forward you a set. I fixed the problem that caused these to com out so damned often, MC may not get the fix ever, since we might not ever assemble another ITS for MC.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 APR 86 16:02:26 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 10 Apr 86 14:54:38 EST Date: Thu 10 Apr 86 14:57:33-EST From: "J. Noel Chiappa" Subject: Re: The PARERR that broke the KL's back To: GUMBY@MC.LCS.MIT.EDU, POOR-MC@MC.LCS.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].880303.860410.GUMBY> Message-ID: <12197778328.25.JNC@XX.LCS.MIT.EDU> There was some discussion of the 'GW TBL FULL' message on the BUG-TCP mailing list on MC a while ago, but some vandal seems to have deleted the old archives (maybe they just rename them, I didn't check). See if you can find them; if not, I'll forward you a set. NOel -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 APR 86 14:00:59 EST Date: Thu, 10 Apr 86 14:00:04 EST From: David Vinayak Wallace Subject: The PARERR that broke the KL's back To: POOR-MC@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].880303.860410.GUMBY> At least I think that's what it is; MC had been getting them for the past 8 hours or so. Dumped to CRASH URET2 if anyone cares (bugpc/ caia uret2+2 $Q-1/ pushj p,bugnil) Also, the GW tables are filling up every five or ten minutes rather than every hour or so. Isn't that a bug, or am I just confused?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 APR 86 21:18:14 EST Date: Tue, 8 Apr 86 21:17:35 EST From: Alan Bawden Subject: MC unit #1 To: KARENS@MC.LCS.MIT.EDU, F-S@OZ.AI.MIT.EDU cc: POOR-MC@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].878120.860408.ALAN> Well, the new RP04 on MC only seems to be half of an RP04. It seems perfectly capable of reading the files off of our old pack, but new files we create there usually get hard ECC errors when you read them back. Tonight I tried formatting a fresh pack on that drive, hoping that this was just some kind of head alignment prroblem. No such luck. The newly formatted pack gets hard errors on every cylinder. I have left the old pack on line because it lets users get at their old files (and it is hard for a user to accidentally create a file there), not because I think this drive is fixed.  Date: Sat, 11 Jan 86 22:18:31 EST From: Alan Bawden Subject: Losing Dialup To: POOR-MC@MC.LCS.MIT.EDU cc: CPH@MC.LCS.MIT.EDU In-reply-to: Msg of Sat 11 Jan 86 18:25:45 EST from Chris Hanson Message-ID: <[MC.LCS.MIT.EDU].780980.860111.ALAN> Date: Sat, 11 Jan 86 18:25:45 EST From: Chris Hanson To: BUG-SYSTEM at MC When I dial x6985, I am getting a connection which responds to my carriage return with the standard "Connected to MC.", but then it fails to give me a HACTRN. C-Z has no effect. I notice that *nobody* is logged in from a dialup. This seems like it might be related. No, its only T10. I'm using T11 right now now problem. Probably nobody is using a dialup because they all dial the number CPH did, which is the base of the hunt group, and when it doesn't work they hang up again so that the broken line will shaft the next user. Doesn't occur to many people to try dialing 6986... SYSMSG shows that ITS timed out waiting for the 11 to acknowledge a character it sent to T10. (I guess somebody dropped an interrupt.) This leaves ITS confused about the state of that TTY. Setting the right variable in ITS (TTYOAC+10/ -1) unwedged it. (I finished sending this mail from T10.)  Date: Sat, 28 Dec 85 19:00:48 EST From: Alan Bawden Subject: page fault in system To: GUMBY@MC.LCS.MIT.EDU cc: HIC@MC.LCS.MIT.EDU, POOR-MC@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 22 Dec 85 15:21:29 EST from David Vinayak Wallace Message-ID: <[MC.LCS.MIT.EDU].767454.851228.ALAN> [ Why are we Cc'ing this message to HIC? ] Date: Sun, 22 Dec 85 15:21:29 EST From: David Vinayak Wallace ITS took a page fault. Look in CRASS PAGFLT if you care. Specifically, ITS took a page fault running in the scheduler. It thought it was looking at somebody's USTP bits, but U contains gubbish, and it looks like the hardware pagetable must have contained some kind of a joke as well. I am tempted to agree with you that this was the result of glitch. (That must be what you think since you mailed this to Poor-MC, right?) PS: Someone seems to have deleted the pooor-mc alias. I don't think it ever really had that name, at least not for long. I suggested it, but I think somebody corrected my joke thinking it was a typo almost instantly.  Date: Sun, 22 Dec 85 15:22:54 EST From: "Christopher C. Stacy" To: BUG-COMSAT@MC.LCS.MIT.EDU cc: POOR-MC@MC.LCS.MIT.EDU In-reply-to: Msg of Sat 21 Dec 85 18:12:59 EST from Gail Zacharias Message-ID: <[MC.LCS.MIT.EDU].763994.851222.CSTACY> Okay folks, here I am hooking up domains to COMSAT today. The SYSNET directory is now locked.  Date: Sun, 22 Dec 85 15:21:29 EST From: David Vinayak Wallace Subject: page fault in system To: POOR-MC@MC.LCS.MIT.EDU cc: HIC@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].763991.851222.GUMBY> ITS took a page fault. Look in CRASS PAGFLT if you care. david PS: Someone seems to have deleted the pooor-mc alias.  Date: Sun, 8 Dec 85 12:15:59 EST From: Alan Bawden Subject: Crash To: RDZ@MIT-MC.ARPA cc: POOR-MC@MIT-MC.ARPA In-reply-to: Msg of Sun 8 Dec 85 00:27:15 EST from Ramin Zabih Message-ID: <[MIT-MC.ARPA].746247.851208.ALAN> Date: Sun, 8 Dec 85 00:27:15 EST From: Ramin Zabih MC died again. It printed the error "TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER". I saved it to CRASH;CRASH TTYOU1. When I reloaded XITS and g'd it, the memory bay lights flashed for a while and nothing else happened. I waited a minute or so, raised switch zero and reloaded it; it then seemed happy. By the way, is this mailing list the place to send these reports or should I just write them in the log? I think the idea behind Poor-MC was for hardware related problems. If you think a crash was clearly caused by hardware, Poor-MC is the place. If you can't tell, send mail to Bug-ITS. In either case write something in the log. In this case I happen to know that this is one of the known software bugs in ITS, perhaps someday somebody will figure out how this happens. (If you see it again, don't bother to take a crash dump of it, we have plenty of this one!) The other wierd thing that happend to you, where ITS comes up but nothing gets printed on the system console, is something I have seen before, but I haven't the slightest idea what causes it. The console 11 must get confused or something given that the salvager manages to run without error, yet it types nothing out!  Date: Sun, 8 Dec 85 00:27:15 EST From: Ramin Zabih Subject: Crash To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].745940.851208.RDZ> MC died again. It printed the error "TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER". I saved it to CRASH;CRASH TTYOU1. When I reloaded XITS and g'd it, the memory bay lights flashed for a while and nothing else happened. I waited a minute or so, raised switch zero and reloaded it; it then seemed happy. By the way, is this mailing list the place to send these reports or should I just write them in the log? Ramin  Date: Mon, 25 Nov 85 20:54:01 EST From: Ramin Zabih Subject: Guess what? MC crashed... To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].732690.851125.RDZ> It complained about too many parity errors. I warm booted it and it was happy. Crash dump in crash;crash parerr.  Date: Mon, 11 Nov 85 21:08:40 EST From: Alan Bawden Subject: Hangup To: ALAN@MIT-MC.ARPA cc: POOR-MC@MIT-MC.ARPA In-reply-to: Msg of Sun 10 Nov 85 16:14:18 EST from Alan Bawden Message-ID: <[MIT-MC.ARPA].714898.851111.ALAN> Looks like reloading the console 11 fixed the hangup detection problem. I guess we can stop worrying about broken hardware.  Date: Sun, 10 Nov 85 16:14:18 EST From: Alan Bawden Subject: Hangup To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].713564.851110.ALAN> Sometime in the last couple of days the console 11 (the one that acts as a front end for the vadic lines) has stopped detecting hangups. The symptoms are that when you dial up to MC and type CR you do -not- get the "Connected to MC" message, instead you have to type ^Z, because you are already connected to MC. You thus lose your chance to do autospeeding if want to talk something other than 1200 baud. Furthermore, ITS has not cleared the terminal type for the line you are using (the 11 never told it the last guy hung up the phone), so it will be sending inappropriate display codes to your terminal. The next person to reload the system should be sure to reload the console 11 on the theory that it is running corrupted software. If this doesn't work, then we will have to assume it is busted hardware.  Date: Thu, 7 Nov 85 12:06:19 EST From: Ramin Zabih Subject: @#$%!*& To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].709588.851107.RDZ> Pinheads of the World, Unite! You have nothing to lose but your Brains! (M-X Exit Flame Mode) When I came upstairs to reboot MC I discovered that the system console had been cunningly set up so that it printed its messages on paper that had been previously typed on. Note on the blank side of such paper, mind you, but on the pre-written on side. I therefore have no idea at all why the machine crashed. I went and found some clean paper which the console is now using. The salvager also deleted the empty directories MBR and LND. Ramin  Date: Wed, 16 Oct 85 17:14:43 EDT From: Christopher C. Stacy Subject: There is no hope for this place To: ALAN@MIT-MC.ARPA cc: POOR-MC@MIT-MC.ARPA In-reply-to: Msg of Wed 16 Oct 85 13:50:13 EDT from Alan Bawden Message-ID: <[MIT-MC.ARPA].681637.851016.CSTACY> I was around early Wednsday morning, and the indicated AMPEX memory was offline then. I went home when DEC took the system down for PM. I guess we just have to assume that pinheads come in in the middle of the night and randomly play with the switches on our machines. Probably at least every other week.  Date: Wed, 16 Oct 85 13:50:13 EDT From: Alan Bawden Subject: There is no hope for this place To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].681361.851016.ALAN> Being in a mood that makes me easy to annoy, I was very annoyed to find that: despite the fact that there was a system message on MC saying that 1/2 of the ampex was off-line, and despite the fact that there was a note the MC's Very Small Bulletin Board about memory being offline, and despite the fact that I sent mail to this mailing list, nevertheless all of the ampex memory is currently online. How long has this been true I wonder? Did whoever do this have a good reason for not turning interleaving in the Ampex back on when the re-enabled that memory? Why didn't they remove the now-erroneous note from the VSBB? Why didn't they take down the system message? I guess we just have to assume that pinheads come in in the middle of the night and randomly play with the switches on our machines.  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 9 Oct 85 19:15:57 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 330516; Wed 9-Oct-85 19:13:07-EDT Date: Wed, 9 Oct 85 19:12 EDT From: David A. Moon Subject: Ampex To: Alan Bawden cc: POOR-MC@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].674370.851009.ALAN> Message-ID: <851009191216.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 9 Oct 85 19:07:10 EDT From: Alan Bawden I took sector 0 of the Ampex offline as the parity errors got to bad to put up with. I take it that since the errors had moved from sector 1 to sector 0 thaat someone (TY?) has been swapping boards in there? None of the module parity error lights were lit, perhaps this means that the light on the module in question is burned out. Maybe the modules are fine and the problem is with getting the data between the core modules and the cpu, thus fingering the memory bus interface in the cpu (which I have never known to break), the memory bus cables (which don't break very often), the memory bus transceiver cards in the ampex (which are pieces of shit that always break), and the controller in the ampex (also a piece of shit, but as far as I know has never broken). The errors might be concentrated in a particular sector if the processor and the ampex are both interleaved; in that case the even addresses would all be on a particular pair of the 4 processor-memory busses, would go through a particular set of transceivers, and would all end up in sector 0. The odd addresses would go through different transceivers and end up in sector 1. Besides being pieces of garbage in their own right, the transceiver cards have a manual adjustment with (as I recall) conflicting documentation about what you're supposed to adjust it to, plus sensitivity to power supply problems.  Date: Wed, 9 Oct 85 19:07:10 EDT From: Alan Bawden Subject: Ampex To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].674370.851009.ALAN> I took sector 0 of the Ampex offline as the parity errors got to bad to put up with. I take it that since the errors had moved from sector 1 to sector 0 thaat someone (TY?) has been swapping boards in there? None of the module parity error lights were lit, perhaps this means that the light on the module in question is burned out.  Date: Fri, 4 Oct 85 20:52:20 EDT From: Ken Harrenstien Subject: CRASH;CRASH PKQGF To: ALAN@MIT-MC.ARPA cc: KLH@MIT-MC.ARPA, RDZ@MIT-MC.ARPA, POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].669032.851004.KLH> Of course, just about ANYTHING could happen as the result of a single changed bit. The fact that this happened twice makes me mildly suspicious, but I really have no clue. This is a pretty basic routine that gets invoked continuously, and has never barfed before to my knowledge. Most likely something clobbered some portion of the memory. If you had both dumps available, I would suggest looking at the network connections with PEEK's autopsy mode to see if there is anything in common.  Date: Fri, 4 Oct 85 15:37:20 EDT From: Christopher C. Stacy Subject: delete and ignore this message To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].668643.851004.CSTACY> Testing, 1,2,3,...  Date: Fri, 4 Oct 85 15:25:17 EDT From: Christopher C. Stacy Subject: archival To: GSB@MIT-MC.ARPA cc: POOR-MC@MIT-MC.ARPA In-reply-to: Msg of Fri 4 Oct 85 02:50:34 EDT from Glenn S. Burke Message-ID: <[MIT-MC.ARPA].668630.851004.CSTACY> Date: Fri, 4 Oct 85 02:50:34 EDT From: Glenn S. Burke To: POOR-MC at MIT-MC.ARPA Re: archival I made poor-mc archive in [sysdoc;poor mc]. I suppose optimally it should archive on some other machine. What's a good place on ai? I just created AI:SYSDOC; and will update the mailing list. (I moved a copy of .CALLS there and a -READ- -THIS- too...)  Date: Fri, 4 Oct 85 02:50:34 EDT From: Glenn S. Burke Subject: archival To: POOR-MC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].668396.851004.GSB> I made poor-mc archive in [sysdoc;poor mc]. I suppose optimally it should archive on some other machine. What's a good place on ai?  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 3 Oct 85 16:59:49 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 326337; Thu 3-Oct-85 17:00:27-EDT Date: Thu, 3 Oct 85 16:59 EDT From: David A. Moon Subject: Poor-MC@MC To: Christopher C. Stacy cc: POOR-MC@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].667595.851003.CSTACY> Message-ID: <851003165943.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 3 Oct 85 15:12:17 EDT From: Christopher C. Stacy MC started crashing with parity errors in MH10-D (bank 0) today, and TY thinks that the problem is related to the tape channel, since whenever DUMP gets round to touching the tape, the system dies. So, he's calling in DEC to run diagnostics on the memories and DF10. DDQCB on our disk is pretty good for checking for this problem. Don't forget to write-protect the disks when running it, otherwise it may write on them! You can get it to write and read a tape and tell you what bad data were written into memory by the tape controller.  Date: Wed, 2 Oct 85 17:22:38 EDT From: Alan Bawden Subject: Poor-MC@MC To: TY@MIT-MC.ARPA, GSB@MIT-MC.ARPA, ALAN@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA, CENT@MIT-MC.ARPA, DPH@MIT-MC.ARPA, JNC@MIT-MC.ARPA, TAFT@MIT-MC.ARPA, GUMBY@MIT-MC.ARPA, JTW@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].666412.851002.ALAN> (Who else would ever bring MC up after it crashes? I get tired of sending these notes to all of Bug-ITS... Perhaps we should make a Pooor-MC mailing list?) I reconfigured MC's memory as follows: 0 - 777777 MH10-D 1,,0 - 4,,777777 Ampex (both sectors) 5,,0 - 5,,777777 MH10-C 6,,0 - 6,,777777 MH10-B 7,,0 - 7,,777777 MH10-A This puts the system itself running in MH10-D which hasn't seen parity errors in quite some time. Also if I understand the way ITS allocates memory this will tend to keep users out of the Ampex, so perhaps its parity errors will be less fatal. Finally, if the DL10 is really writing bad parity, this should make them move to a different place so we can see. (Probably I should have put the boxes A,B,C in the other order since for a while we thought A might have been broken, but its too late now.)