Consolidate license copies

[its.git] / sysdoc / poor.mc

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 <ROLL@AI.AI.MIT.EDU>
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
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
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.

\1f
Date: Fri,  9 Sep 88 17:47:53 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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.
^_
\1f
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 <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.

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?
\1f
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 <SRA@XX.LCS.MIT.EDU>
Subject: [Rob Austein <SRA@XX.LCS.MIT.EDU>: 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 <SRA@XX.LCS.MIT.EDU>
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
-------
-------
\1f
Date: Mon, 28 Sep 87 00:20:04 EDT
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
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 <ME at SAIL.STANFORD.EDU>
Message-ID: <261147.870928.GUMBY@AI.AI.MIT.EDU>

    Date: 25 Sep 87  1540 PDT
    From: Martin Frost <ME at SAIL.STANFORD.EDU>

    Our drives, by the way, date from about 1966.

This year's freshmen were born in 69 and 70.
\1f
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: <RP.12337918540.BABYL@MIT-OZ>
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 <ALAN at AI.AI.MIT.EDU>

    Date: Tuesday, 1 September 1987  07:27-EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    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.
\1f
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 <ME@SAIL.STANFORD.EDU>
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.

\1f
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 <Alan@AI.AI.MIT.EDU>
Subject: [Martin Frost <ME@SAIL.STANFORD.EDU>: 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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
        Date: Fri, 18 Sep 87 14:10:21 EDT
        From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
            Date: Thu, 17 Sep 87 20:45:06 EDT
            From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
            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?

\1f
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 <TY@XX.LCS.MIT.EDU>
Subject: Re: [Martin Frost <ME@SAIL.STANFORD.EDU>: 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..
-------
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Martin Frost <ME@SAIL.STANFORD.EDU>: old magtape heads   ]
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>, 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 <ALAN@AI.AI.MIT.EDU>

        Date: Thu, 17 Sep 87 20:45:06 EDT
        From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>

        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.

\1f
Date: Fri, 18 Sep 87 14:10:21 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  [Martin Frost <ME@SAIL.STANFORD.EDU>: 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 <CENT at AI.AI.MIT.EDU>
Message-ID: <256807.870918.ALAN@AI.AI.MIT.EDU>

    Date: Thu, 17 Sep 87 20:45:06 EDT
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
        Date: 07 Aug 87  1743 PDT
        From: Martin Frost <ME@SAIL.STANFORD.EDU>
        ...
    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.
\1f
Date: Thu, 17 Sep 87 20:45:06 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: [Martin Frost <ME@SAIL.STANFORD.EDU>: 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 <BERLIN@XX.LCS.MIT.EDU>
    Subject: [Martin Frost <ME@SAIL.STANFORD.EDU>: 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 <ME@SAIL.STANFORD.EDU>
    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.
\1f
Date: Tue,  1 Sep 87 07:27:11 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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.)
\1f
Date: Mon, 31 Aug 87 01:00:54 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <PFTHMG-DRAGON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <248464.870831.ALAN@AI.AI.MIT.EDU>

    Date: Mon, 31 Aug 87 00:14:15 EDT
    From: Puff the Magic Dragon <PFTHMG-DRAGON at MX>
    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.
\1f
Date: Mon, 24 Aug 87 17:46:27 EDT
From: "Michael A.  Patton" <MAP@AI.AI.MIT.EDU>
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 <JTW%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
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
\1f
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" <JTW%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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.


\1f
Date: Thu,  6 Aug 87 08:31:17 EDT
From: Ray Hirschfeld <RAY@AI.AI.MIT.EDU>
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
\1f
Date: Thu, 30 Jul 87 15:26:11 EDT
From: "Michael A.  Patton" <MAP@AI.AI.MIT.EDU>
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 <JTW%MIT-SPEECH at XX.LCS.MIT.EDU>
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.
\1f
Date: Wed, 29 Jul 87 11:09:08 EDT
From: "John T. Wroclawski" <JTW@AI.AI.MIT.EDU>
To: POOOR-MX@AI.AI.MIT.EDU
Message-ID: <234614.870729.JTW@AI.AI.MIT.EDU>


    From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
    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.
\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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 <ALAN@AI.AI.MIT.EDU>
    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.

-------
\1f
Date: Sun, 26 Jul 87 14:57:02 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <JBVB%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <233018.870726.ALAN@AI.AI.MIT.EDU>

    Date: Sat, 25 Jul 87 22:56:10 EDT
    From: James B. VanBokkelen <JBVB at MX>
    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.
\1f
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" <JBVB%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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

\1f
Date: Fri, 24 Jul 87 16:20:03 EDT
From: "Michael A.  Patton" <MAP@AI.AI.MIT.EDU>
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
\1f
Date: Sat, 11 Jul 87 19:37:50 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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?
\1f
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 <ALAN%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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.)

\1f
Date: Sun, 21 Jun 87 14:20:57 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <COMSAT at AI.AI.MIT.EDU>
Message-ID: <217648.870621.ALAN@AI.AI.MIT.EDU>

    Date: Wed, 17 Jun 87 17:01:22 EDT
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
    ... 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.
\1f
Date: Wed, 17 Jun 87 17:01:22 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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.
\1f
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 <ALAN%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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.

\1f
Date: Fri,  8 May 87 23:46:04 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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" <SWF%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
    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.
\1f
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" <SWF%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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


\1f
Date: Fri, 24 Apr 87 08:50:56 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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" <JBVB@AI.AI.MIT.EDU>
    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.
\1f
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 <sra@XX.LCS.MIT.EDU>
Subject: [TY: status of modems]
To: Alan Bawden <Alan@AI.AI.MIT.EDU>
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 <ALAN@AI.AI.MIT.EDU>

        Date: Fri 27 Mar 87 14:46:11-EST
        From: J. J. Tyrone Sealy <TY at XX>
        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.
\1f
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 <TY@XX.LCS.MIT.EDU>
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 ?

-------
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Longer life @ MIT for Poor-mc
To: Thomas J. Greene <TJG@XX.LCS.MIT.EDU>
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 <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 ?

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.

\1f
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 <TJG@XX.LCS.MIT.EDU>
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
-------
\1f
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" <MOON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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..
\1f
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: <PSZ.12287156831.BABYL@XX.LCS.MIT.EDU>
From: PSZ@XX.LCS.MIT.EDU
To:   "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <CENT at AI.AI.MIT.EDU>

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
\1f
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" <JNC@XX.LCS.MIT.EDU>
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: <SRA.12286923469.BABYL@XX.LCS.MIT.EDU>
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
-------
\1f
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: <SRA.12286923469.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "Pandora B. Berman" <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
Subject: Future of the KL
In-reply-to: Msg of 16 Mar 1987  03:51-EST from "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>

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.
\1f
Date: Mon, 16 Mar 87 03:51:59 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <SRA@XX.LCS.MIT.EDU>
    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.
\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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.
-------
\1f
Date: Sat, 14 Mar 87 06:17:33 EST
From: "Glenn S. Burke" <GSB@AI.AI.MIT.EDU>
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 <SRA at XX.LCS.MIT.EDU>
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.
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: disks, future, etc.
To: John Wroclawski <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>

    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.

\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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.
-------
\1f
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: <SRA.12286156668.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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
\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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.
-------
\1f
Date: Sun,  8 Mar 87 23:58:57 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <COMSAT@AI.AI.MIT.EDU>
    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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    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.
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    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

\1f
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 <COMSAT@AI.AI.MIT.EDU>
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
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


\1f
Date: Sun,  8 Mar 87 23:02:18 EST
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
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.
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Life is complicated, here in the future
To: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
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 <Gumby@AI.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.

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.


\1f
Date: Sun,  8 Mar 87 17:13:53 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <Gumby at AI.AI.MIT.EDU>
Message-ID: <165231.870308.ALAN@AI.AI.MIT.EDU>

    Date: Sun, 8 Mar 87 03:19 EST
    From: David Vinayak Wallace <Gumby at AI.AI.MIT.EDU>
    ...
    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.)
\1f
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 <Gumby@AI.AI.MIT.EDU>
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.
\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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.
-------
\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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.
-------
\1f
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 <TY@XX.LCS.MIT.EDU>
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..
-------
\1f
Date: Fri,  6 Mar 87 01:28:07 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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?
\1f
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: <PGS.12281742639.BABYL@MIT-EECS>
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.
\1f
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" <PGS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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.

\1f
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.
\1f
Date: Tue, 24 Feb 87 01:21:56 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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...
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [PFTHMG-DRAGON@MX.LCS.MIT.EDU: Forwarded]
To: Alan Bawden <Alan@AI.AI.MIT.EDU>
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 <Alan@AI.AI.MIT.EDU>

        Date: Mon,  9 Feb 87 20:20:28 EST
        From: Puff the Magic Dragon <PFTHMG-DRAGON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
        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?

\1f
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 <Alan@AI.AI.MIT.EDU>
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 <PFTHMG-DRAGON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
    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?
\1f
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: <SRA.12277236363.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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.
\1f
Date: Mon,  2 Feb 87 03:28:08 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: kl down in flames
    To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
    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?
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: kl down in flames
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <ALAN@AI.AI.MIT.EDU>

    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.

\1f
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 <Gumby@AI.AI.MIT.EDU>
Subject: TTY33
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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.
\1f
Date: Sat, 31 Jan 87 17:22:29 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <CENT at AI.AI.MIT.EDU>
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?
\1f
Date: Fri, 30 Jan 87 08:04:39 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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.
\1f
Date: Tue, 13 Jan 87 22:42:48 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <SRA%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
    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.
\1f
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 <SRA%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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....

\1f
Date: Thu,  1 Jan 87 22:50:46 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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:.
\1f
Date: Thu,  1 Jan 87 15:43:25 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <135733.870101.ALAN@AI.AI.MIT.EDU>

    Date: Wed, 31 Dec 86 22:12:10 EST
    From: Leigh L. Klotz <KLOTZ at MX>
    I just got a non-recoverable disk data error on
    klotz;emacs \11: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 <KLOTZ at MX>
    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?)
\1f
Date: Wed, 31 Dec 86 17:06:56 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <TY@XX.LCS.MIT.EDU>
    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.
\1f
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 <TY@XX.LCS.MIT.EDU>
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
-------
\1f
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 <Alan@AI.AI.MIT.EDU>
Subject: KS
To: SRA@XX.LCS.MIT.EDU
cc: Poor-MC@AI.AI.MIT.EDU
In-Reply-To: <SRA.12265176573.BABYL@XX.LCS.MIT.EDU>
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.
\1f
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: <SRA.12265176573.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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....
\1f
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 <Alan@AI.AI.MIT.EDU>
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: <SRA.12264643177.BABYL@XX.LCS.MIT.EDU>
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.
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Kludging around the KS's flakey disk
To: Rob Austein <sra@MIT-AI.ARPA>
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 <sra@XX.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....

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.

\1f
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 <TY@XX.LCS.MIT.EDU>
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: <SRA.12264643177.BABYL@XX.LCS.MIT.EDU>
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..
-------
\1f
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 <sra@XX.LCS.MIT.EDU>
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....
\1f
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: <SRA.12264643177.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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.
\1f
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: <SRA.12264162228.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "David A. Moon" <Moon@STONY-BROOK.SCRC.SYMBOLICS.COM>
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>

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....
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The KS lost again
To: Rob Austein <SRA@MIT-AI.ARPA>
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 <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.

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.

\1f
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: <SRA.12264124224.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Log-Service-Call@XX.LCS.MIT.EDU, Poor-MC@AI.AI.MIT.EDU
Subject: KS's RP06

Logged call BC1820 @ 16:57.
\1f
Date: Fri, 19 Dec 86 13:36:54 EST
From: Rob Austein <SRA@AI.AI.MIT.EDU>
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?
\1f
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: <SRA.12264073312.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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.
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
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" <MOON%MX.LCS.MIT.EDU@MC.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..

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.

\1f
Date: Wed, 17 Dec 86 06:56:39 EST
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
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 <SRA at XX.LCS.MIT.EDU>
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?
\1f
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: <SRA.12263475300.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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.
\1f
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" <MOON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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..
\1f
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 <Alan@AI.AI.MIT.EDU>
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>

        Date: Tue, 16 Dec 86 06:43:19 EST
        From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>

        try reading armte;steveh omail.  Might running the salvager help?

    Running the salvager under timesharing (SALV\e^K then CHKR\eG) 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...)
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Bad file?
To: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
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 <Gumby@AI.AI.MIT.EDU>

    try reading armte;steveh omail.  Might running the salvager help?

Running the salvager under timesharing (SALV\e^K then CHKR\eG) will find out.
The TS salvager never writes into the file system, but it's useful for
examining things.

\1f
Date: Tue, 16 Dec 86 06:43:19 EST
From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
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?
\1f
Date: Mon, 15 Dec 86 15:42:53 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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.)
\1f
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 <SRA@MX.LCS.MIT.EDU>
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
\1f
Date: Sat, 25 Oct 86 08:39:43 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <SRA@XX.LCS.MIT.EDU>
    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.
\1f
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 <GUMBY%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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.
\1f
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 <GUMBY%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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 <ALAN at AI.AI.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].948811.860924.GUMBY>

    Date: Tue, 23 Sep 86 19:55:00 EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>

        Date: Tue, 23 Sep 86 08:24:26 EDT
        From: David Vinayak Wallace <GUMBY at MX>
        After the nasty power-glitch this morning MX's unit 1 consented to
        load its heads and load DDT.  However attempting to \eL 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.
\1f
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: <SRA.12241375700.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <ALAN@AI.AI.MIT.EDU>

    Date: Tuesday, 23 September 1986  19:55-EDT
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>

    ...  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.
\1f
Date: Tue, 23 Sep 86 19:55:00 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <GUMBY%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].97741.860923.ALAN>

    Date: Tue, 23 Sep 86 08:24:26 EDT
    From: David Vinayak Wallace <GUMBY at MX>
    After the nasty power-glitch this morning MX's unit 1 consented to
    load its heads and load DDT.  However attempting to \eL 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?...
\1f
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 <GUMBY%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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 \eL any file caused
the error "?UN1" which I took to mean that the drive was still
gronked.
\1f
Date: Sun, 21 Sep 86 04:49:11 EDT
From: Rob Austein <SRA@AI.AI.MIT.EDU>
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.
\1f
Date: Tue, 26 Aug 86 09:20:39 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <GUMBY%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
    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 <CENT at AI.AI.MIT.EDU>
        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.
\1f
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 <GUMBY%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
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 <CENT at AI.AI.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].943466.860826.GUMBY>

    Date: Tue, 26 Aug 86 02:45:09 EDT
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>

    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?
\1f
Date: Tue, 26 Aug 86 02:45:09 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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.
\1f
Date: Mon, 28 Jul 86 15:48:58 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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... 
\1f
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 <TY@XX.LCS.MIT.EDU>
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..
-------
\1f
Date: Thu, 10 Jul 86 20:33:18 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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...).
\1f
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 <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MX tape drive losing
To: Pandora B. Berman <CENT@AI.AI.MIT.EDU>
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).

\1f
Date: Mon,  7 Jul 86 01:41:48 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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).
\1f
Date: Sun,  6 Jul 86 22:52:26 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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.)
\1f
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 <SOLLINS@XX.LCS.MIT.EDU>
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.
-------
\1f
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" <JNC@XX.LCS.MIT.EDU>
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.
-------
\1f
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 <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: hardware status
To: John Wroclawski <JTW%SPEECH.MIT.EDU@XX.LCS.MIT.EDU>
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" <JTW%SPEECH.MIT.EDU@XX.LCS.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.)

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.

\1f
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" <JTW%SPEECH.MIT.EDU@XX.LCS.MIT.EDU>
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?
-------
\1f
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 <SRA@MC.LCS.MIT.EDU>
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
\1f
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 <GUMBY@MX.LCS.MIT.EDU>
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. 
\1f
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 <Moon@SCRC-STONY-BROOK.ARPA>
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 TCOPY\eG, and answer the questions.  You can copy two 7-track reels
onto each 9-track reel.

\1f
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" <MOON@MX.LCS.MIT.EDU>
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.
\1f
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" <moon@AI.AI.MIT.EDU>
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!
\1f
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" <MOON@MX.LCS.MIT.EDU>
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.
\1f
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" <MOON@MX.LCS.MIT.EDU>
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.
\1f
Date: Sat, 24 May 86 21:14:21 EDT
From: "John T. Wroclawski" <JTW@AI.AI.MIT.EDU>
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..
\1f
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 <SRA@XX.LCS.MIT.EDU>
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.
-------
\1f
Date: Thu, 22 May 86 07:43:30 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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.
\1f
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" <CENT@AI.AI.MIT.EDU>
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" <MOON@MC.LCS.MIT.EDU>
    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.
\1f
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" <MOON@MX.LCS.MIT.EDU>
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.
\1f
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" <MOON@MC.LCS.MIT.EDU>
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.
\1f
Date: Wed, 21 May 86 23:55:16 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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 <SRA@XX.LCS.MIT.EDU>
    To:   "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
    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.
\1f
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: <SRA.12208606423.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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" <CENT@AI.AI.MIT.EDU>

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.
\1f
Date: Wed, 21 May 86 22:57:57 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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?
\1f
Date: Wed, 21 May 86 00:35:26 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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.)
\1f
Date: Tue, 20 May 86 19:02:57 EDT
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
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 <ALAN at AI.AI.MIT.EDU>
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. 
\1f
Date: Tue, 20 May 86 16:17:05 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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?
\1f
Date: Tue, 20 May 86 16:10:03 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <ALAN at AI.AI.MIT.EDU>
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.
\1f
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" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
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 <ALAN@AI.AI.MIT.EDU>

    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.
-------
\1f
Date: Tue, 20 May 86 01:38:49 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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...
\1f
Date: Mon, 19 May 86 02:59:35 EDT
From: "John T. Wroclawski" <JTW@AI.AI.MIT.EDU>
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...
\1f
Date: Sun, 18 May 86 21:26:53 EDT
From: "John T. Wroclawski" <JTW@AI.AI.MIT.EDU>
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...

\1f
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 <GUMBY@MC.LCS.MIT.EDU>
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
\1f
Date: Thu, 15 May 86 02:21:16 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
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" <JNC@XX.LCS.MIT.EDU>
    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.
\1f
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" <JNC@XX.LCS.MIT.EDU>
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
-------
\1f
Date: Wed, 14 May 86 13:19:12 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
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 <ZVONA at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].40905.860514.ALAN>

    Date: Wed, 14 May 86 09:43:17 EDT
    From: David Chapman <ZVONA at AI.AI.MIT.EDU>
        Date: Tue, 13 May 86 12:50:10 EDT
        From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
        ...  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.
\1f
Date: Fri,  9 May 86 02:23:17 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
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
TCOPY\eG 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.
\1f
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 <SRA@MC.LCS.MIT.EDU>
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
\1f
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 <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: down on Thursday
To: J. J. Tyrone Sealy <TY@MIT-XX.ARPA>
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 <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??

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.

\1f
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 <Moon@SCRC-STONY-BROOK.ARPA>
Subject: LNS stuff
To: Gumby@MIT-MC.ARPA
cc: J. J. Tyrone Sealy <TY@MIT-XX.ARPA>, poor-mc@MIT-MC.ARPA,
    ks-its@MIT-AI.ARPA
In-Reply-To: <GUMBY.12201921726.BABYL@XX.LCS.MIT.EDU>
Message-ID: <860427181311.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 26 Apr 1986  10:17 EST (Sat)
    From: David Vinayak Wallace <GUMBY@XX.LCS.MIT.EDU>

        Date: Friday, 25 April 1986  13:09-EST
        From: J. J. Tyrone Sealy <TY>

        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.


\1f
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: <GUMBY.12201921726.BABYL@XX.LCS.MIT.EDU>
From: David Vinayak Wallace <GUMBY@XX.LCS.MIT.EDU>
To:   "J. J. Tyrone Sealy" <TY@XX.LCS.MIT.EDU>
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 <TY>

    Date: Friday, 25 April 1986  13:09-EST
    From: J. J. Tyrone Sealy <TY>

    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.
\1f
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 <TY@XX.LCS.MIT.EDU>
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..
-------
\1f
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 <Moon@SCRC-STONY-BROOK.ARPA>
Subject: down on Thursday
To: J. J. Tyrone Sealy <TY@MIT-XX.ARPA>
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 <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????

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.

\1f
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 <TY@XX.LCS.MIT.EDU>
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
-------
\1f
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 <ALAN@MC.LCS.MIT.EDU>
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 <GUMBY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].880598.860410.ALAN>

    Date: Thu, 10 Apr 86 14:00:04 EST
    From: David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
    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.
\1f
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 <ALAN@MC.LCS.MIT.EDU>
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 <JNC at XX.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].880572.860410.ALAN>

    Date: Thu 10 Apr 86 14:57:33-EST
    From: J. Noel Chiappa <JNC at 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).

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.
\1f
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" <JNC@XX.LCS.MIT.EDU>
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
-------
\1f
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 <GUMBY@MC.LCS.MIT.EDU>
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?
\1f
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 <ALAN@MC.LCS.MIT.EDU>
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.
\1f
Date: Sat, 11 Jan 86 22:18:31 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
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 <CPH at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].780980.860111.ALAN>

    Date: Sat, 11 Jan 86 18:25:45 EST
    From: Chris Hanson <CPH at MC>
    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.)
\1f
Date: Sat, 28 Dec 85 19:00:48 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
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 <GUMBY at MC.LCS.MIT.EDU>
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 <GUMBY at MC>
    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.
\1f
Date: Sun, 22 Dec 85 15:22:54 EST
From: "Christopher C. Stacy" <CSTACY@MC.LCS.MIT.EDU>
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 <GZ at MC.LCS.MIT.EDU>
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.
\1f
Date: Sun, 22 Dec 85 15:21:29 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
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.
\1f
Date: Sun,  8 Dec 85 12:15:59 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
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 <RDZ at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].746247.851208.ALAN>

    Date: Sun,  8 Dec 85 00:27:15 EST
    From: Ramin Zabih <RDZ at MC>
    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 \eg'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!
\1f
Date: Sun,  8 Dec 85 00:27:15 EST
From: Ramin Zabih <RDZ@MIT-MC.ARPA>
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 \eg'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
\1f
Date: Mon, 25 Nov 85 20:54:01 EST
From: Ramin Zabih <RDZ@MIT-MC.ARPA>
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.

\1f
Date: Mon, 11 Nov 85 21:08:40 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
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 <ALAN at MIT-MC.ARPA>
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.
\1f
Date: Sun, 10 Nov 85 16:14:18 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
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.
\1f
Date: Thu,  7 Nov 85 12:06:19 EST
From: Ramin Zabih <RDZ@MIT-MC.ARPA>
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
\1f
Date: Wed, 16 Oct 85 17:14:43 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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 <ALAN at MIT-MC.ARPA>
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.
\1f
Date: Wed, 16 Oct 85 13:50:13 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
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.
\1f
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 <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Ampex
To: Alan Bawden <ALAN@MIT-MC.ARPA>
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 <ALAN@MIT-MC.ARPA>

    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.

\1f
Date: Wed,  9 Oct 85 19:07:10 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
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.
\1f
Date: Fri,  4 Oct 85 20:52:20 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
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.
\1f
Date: Fri,  4 Oct 85 15:37:20 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: delete and ignore this message
To: POOR-MC@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].668643.851004.CSTACY>

Testing, 1,2,3,...
\1f
Date: Fri,  4 Oct 85 15:25:17 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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 <GSB at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].668630.851004.CSTACY>

    Date: Fri,  4 Oct 85 02:50:34 EDT
    From: Glenn S. Burke <GSB at MIT-MC.ARPA>
    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...)
\1f
Date: Fri,  4 Oct 85 02:50:34 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
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?
\1f

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 <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Poor-MC@MC
To: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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 <CSTACY@MIT-MC.ARPA>

    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.

\1f   
Date: Wed,  2 Oct 85 17:22:38 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
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.)
\1f