From CENT at AI.AI.MIT.EDU  Sat May 31 10:13:37 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 31 86 04:13:37 EDT
Subject: MC TCP loss
Message-ID: <[AI.AI.MIT.EDU].49182.860531.CENT>

while on MC and trying to finger out at other hosts, i kept getting an
"all sockets in use" msg. alan poked around and said the system was
out of TCP buffers and COMSAT was acting strangely, so i should raise
switch 0 and take a crash dump. CRASH;TCP LOSS.

From CENT at AI.AI.MIT.EDU  Sat May 31 09:23:01 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 31 86 03:23:01 EDT
Subject: mailing lists redux
Message-ID: <[AI.AI.MIT.EDU].49152.860531.CENT>

    Date: Wed, 28 May 86 17:01:04 EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    Subject:  KS-ITS mailing list
    To: GUMBY at AI.AI.MIT.EDU
    cc: CENT at AI.AI.MIT.EDU, JNC at AI.AI.MIT.EDU, JTW at AI.AI.MIT.EDU
	Date: Wed, 28 May 86 04:47:53 EDT
	From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
	Can't we fold this into INFO-ITS?
    INFO-ITS is an extremely low-volume mailing list.  It is for spreading
    information that ordinary ITS users and programmers might want to know.
    Like when a new device is installed (like LP7:), or a new Midas library
    is written, or a new machine is installed, or a new system call is
    installed or improved.
    KS-ITS is for people who are interested in the project of getting 2020s
    installed at MIT running ITS.  When I got the KS10 microcode to do
    ITS-style paging, I sent mail to KS-ITS.  The people on INFO-ITS I
    didn't bother until they could log in.
    A lot of mail that has gone to KS-ITS in the last few months should
    have been sent to BUG-ITS.  Like if AI crashes in some novel way,
    people send mail to KS-ITS "because AI is a KS", even though BUG-ITS is
    the proper recipient.
    The people on KS-ITS were interested in keeping in touch with a "good
    hack", which is distinct from both BUG-ITS and INFO-ITS.

gumby, the next time you ask 4 people's opinion about making the sort of
major change you suggested, why not wait until more than 1 replies before
deciding what to do? i have just spent 2 hours undoing the confusion you
created by going ahead with this merger after only one response. among
other things, you completely omitted the BUG-ITS archive.  fortunately i
discovered a BUG-ITS list member who hasn't logged in for the past few
days, and so was able to recover the lost msgs. i have also unmerged the
INFO-ITS and KS-ITS archives. also, it's considered courteous, when you
insist on rashly forging ahead in this fashion, to inform -all- the list
members involved; you only told those people on KS-ITS who were not on
INFO-ITS:
	Date: Wed, 28 May 86 05:49:01 EDT
	From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
	Subject:  KS-ITS mailing list
	To: KS-ITS-ONLY-PEOPLE at AI.AI.MIT.EDU
	The KS's have arrived and ITS runs on them, so we're folding the
	KS-ITS list into INFO-ITS.
	You're not on INFO-ITS nor BUG-ITS.  Unless I hear from you in the
	next few days I'll put you on INFO-ITS.
	david

i agree with alan -- the INFO-, BUG-, and KS-ITS have distinct purposes and
should be kept that way. now that the KSs run ITS, a lot of the discussion
previously carried on on KS-ITS should move to BUG-ITS or other more
appropriate lists, but that's another story.

From ALAN at AI.AI.MIT.EDU  Wed May 28 23:21:32 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 28 86 17:21:32 EDT
Subject: No subject
In-Reply-To: Msg of Wed 28 May 86 11:39:49 EDT from David Chapman <ZVONA at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].47458.860528.ALAN>

    Date: Wed, 28 May 86 11:39:49 EDT
    From: David Chapman <ZVONA at AI.AI.MIT.EDU>
    Is there a reason ML is running ITS when everyone else is running NITS?

Heck, you should have looked yesterday!  AI was running NITS, MC was
running XITS, MD was running ITS...  The various names have no relation to
eachother.

    When MD came up, it deleted .temp.; because it was empty.  Does anything
    depend on that dir existing?   Just in case,  i recreated it.

Many things want there to be a .TEMP. directory.  However .TEMP. is on a
(very) short list of directories that are automatically created whenever
anyone tries to use them, so you needn't have gone to the trouble.  In
fact, you could have created it simply by typing .TEMP.^F!

From ALAN at AI.AI.MIT.EDU  Wed May 28 22:48:18 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 28 86 16:48:18 EDT
Subject: ML up...
In-Reply-To: Msg of Wed 28 May 86 04:12:21 EDT from David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].47443.860528.ALAN>

    Date: Wed, 28 May 86 04:12:21 EDT
    From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
    I brough ML up, and copied over LSR1, everything on SYS: created since
    the 15th, and .;@ NITS (which I then booted on ML).
    We should have a better way of doing this. 

Aiiiiiiieeee!!!!!

    Date: Wed, 28 May 86 04:15:43 EDT
    From: David Vinayak Wallace <GUMBY%ML.AI.MIT.EDU at MX.LCS.MIT.EDU>
    I lost moving @ NITS to ML:.;.  So ML's running ITS
    until someone competent wishes to do it.

Since each machine has different devices, addresses, terminals, names, etc.
The various ITS binaries are -totally- incompatible.  I shudder to think
what made you realize that you had lost...

From ZVONA at AI.AI.MIT.EDU  Wed May 28 17:39:49 1986
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: May 28 86 11:39:49 EDT
Subject: No subject
Message-ID: <[AI.AI.MIT.EDU].47247.860528.ZVONA>

Is there a reason ML is running ITS when everyone else is running NITS?
When MD came up, it deleted .temp.; because it was empty.  Does anything
depend on that dir existing?   Just in case,  i recreated it.

From CENT at AI.AI.MIT.EDU  Wed May 28 14:25:34 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 28 86 08:25:34 EDT
Subject: Our Man Lester
Message-ID: <[AI.AI.MIT.EDU].47197.860528.CENT>

appeared this morning after a significant absence. i asked him about
PM on AI and he said not next Tues. he has a meeting, so maybe Mon.,
or maybe even Fri. i mentioned that AI's disk filters needed changing,
and he agreed. he promised he'd send laurel and alan mail giving the
exact day.

From CENT at AI.AI.MIT.EDU  Wed May 28 12:52:36 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 28 86 06:52:36 EDT
Subject: it's probably not a good idea to GFR bug files
Message-ID: <[AI.AI.MIT.EDU].47156.860528.CENT>

    Date: Wed, 28 May 86 06:37:38 EDT
    From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
    Subject:  it's probably not a good idea to GFR bug files:
    To: CENT at AI.AI.MIT.EDU
	Date: Wed, 28 May 86 06:26:48 EDT
	From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
	    Date: Tue, 27 May 86 07:20:15 EDT
	    From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
            FAILED: (FILE [LSPMAI;COMPLR BUGS]) at AI.AI.MIT.EDU; Couldn't
            write message to file;
		"DSK:LSPMAI;COMPLR BUGS" - LINK TO NON-EXISTENT FILE
	    ...
	look again. the link is to an MX GFR tape. the file was gfr'd, by
	JPG or GSB, quite some time ago. are you requesting that it be
	retrieved or something?
    Yes, I think it should be.  
well, you're quite capable of hacking ITS tapes. if you don't, i'll get
around to it sometime.
				Also, LSPMAI should be immune to GFR, 
talk Alan or whoever into adding it to the magic list...
								      or
    at least, should be protected from having most-current bug files
    deleted.
i don't think ITS can do this.

From GUMBY%ML.AI.MIT.EDU at MX.LCS.MIT.EDU  Wed May 28 10:15:43 1986
From: GUMBY%ML.AI.MIT.EDU at MX.LCS.MIT.EDU (David Vinayak Wallace)
Date: May 28 86 04:15:43 EDT
Subject: belay that
Message-ID: <[ML.AI.MIT.EDU].65.860528.GUMBY>

I lost moving @ NITS to ML:.;.  So ML's running ITS
until someone competent wishes to do it.

From GUMBY at AI.AI.MIT.EDU  Wed May 28 10:12:21 1986
From: GUMBY at AI.AI.MIT.EDU (David Vinayak Wallace)
Date: May 28 86 04:12:21 EDT
Subject: ML up...
Message-ID: <[AI.AI.MIT.EDU].47096.860528.GUMBY0>

I brough ML up, and copied over LSR1, everything on SYS: created since
the 15th, and .;@ NITS (which I then booted on ML).
We should have a better way of doing this. 

From GUMBY at MX.LCS.MIT.EDU  Wed May 28 08:23:09 1986
From: GUMBY at MX.LCS.MIT.EDU (David Vinayak Wallace)
Date: May 28 86 02:23:09 EDT
Subject: ARPA contact name
In-Reply-To: Msg of 27 May 1986  21:46 EDT (Tue) from Bill Rozas <JINX%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].922144.860528.GUMBY>

    Date: 27 May 1986  21:46 EDT (Tue)
    From: Bill Rozas <JINX at OZ>

    Shouldn't something which is more likely to stick around be used
    instead?  Using MX is hardly worth the effort, given its expected
    lifetime.

There has been more mail on this subject than it warrants.
1> Fix it to use the KL while it runs; patch it later.
2> Fix the chaos-only hosts (of which there aren't really too many left)
   to understand IP. 

From CENT at AI.AI.MIT.EDU  Wed May 28 04:51:56 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 27 86 22:51:56 EDT
Subject: ks lossage messages
Message-ID: <[AI.AI.MIT.EDU].46889.860527.CENT>

    Date: Mon, 26 May 86 02:02 EDT
    From: David Vinayak Wallace <Gumby at AI.AI.MIT.EDU>
    Subject: ks lossage messages
    To: David Chapman <ZVONA at MX.LCS.MIT.EDU>
    cc: poor-ai at AI.AI.MIT.EDU
	Date: Mon, 19 May 86 11:12:12 EDT
	From: David Chapman <ZVONA at MX.LCS.MIT.EDU>
	Do we need a poor-ks?  
	At 6 this morning, MX started complaining often about being out of
	jobslots on the console.
    Messages like this used to go to BUG-ITS.  I figure they should anyway
    (and the poor-<xx> lists should be flushed, except for the special case
    of the KL).
i have flushed the POOR-AI list and folded the four msgs it had accumulated
in its archive file into the BUG-ITS archive.

From JINX%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU  Wed May 28 03:46:00 1986
From: JINX%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU (Bill Rozas)
Date: May 27 1986  21:46 EDT (Tue)
Subject: [COLE: Telnet-ing through MC to live hosts...]
In-Reply-To: Msg of 27 May 1986  16:11-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <JINX.12210162593.BABYL@MIT-OZ>


Why don't you just fix TELNET on OZ to use MX as a gateway?

Shouldn't something which is more likely to stick around be used
instead?  Using MX is hardly worth the effort, given its expected
lifetime.

From ALAN at AI.AI.MIT.EDU  Tue May 27 22:11:20 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 27 86 16:11:20 EDT
Subject: [COLE: Telnet-ing through MC to live hosts...]
In-Reply-To: Msg of Tue 27 May 1986  15:13 EDT from Jerry Roylance <GLR%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].46638.860527.ALAN>

    Date: Tue, 27 May 1986  15:13 EDT
    From: Jerry Roylance <GLR at OZ>

    Date: Sunday, 25 May 1986  22:48-EDT
    From: COLE at OZ
    To:   David D. Story <FTD at OZ>
    cc:   bug-oz at OZ
    MC is rejecting OZ's request to telnet to arpanet hosts.
    But I was able to telnet from oz by typing:

    telnet
    TELNET> host-name telnet tcp mx

    I don't know what host computer OZ is now supposed to be using for its
    telnet connections.

Somebody seems to have decided that the MC KS will not supply TCP gateway
service.  I personally think this is silly.  I would not object if someone
else wants to take the heat for putting it back.

Why don't you just fix TELNET on OZ to use MX as a gateway?

From GLR%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU  Tue May 27 21:13:00 1986
From: GLR%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU (Jerry Roylance)
Date: May 27 1986  15:13 EDT
Subject: [COLE: Telnet-ing through MC to live hosts...]
Message-ID: <GLR.12210090990.BABYL@MIT-OZ>

Date: May 25 1986  22:48-EDT
From: COLE at OZ.AI.MIT.EDU
To:   David D. Story <FTD%MIT-OZ at MC.LCS.MIT.EDU>
cc:   bug-oz at OZ.AI.MIT.EDU
Re:   Telnet-ing through MC to live hosts...

MC is rejecting OZ's request to telnet to arpanet hosts.
But I was able to telnet from oz by typing:

telnet
TELNET> host-name telnet tcp mx

I don't know what host computer OZ is now supposed to be using for its telnet
connections.

From CPH at MX.LCS.MIT.EDU  Tue May 27 20:30:45 1986
From: CPH at MX.LCS.MIT.EDU (Chris Hanson)
Date: May 27 86 14:30:45 EDT
Subject: Just nitpicking...
Message-ID: <[MX.LCS.MIT.EDU].921807.860527.CPH>

MX still says "Connected to MC." when you dial it up.
I guess there is no single variable controlling the machine name.

From Gumby at AI.AI.MIT.EDU  Mon May 26 08:02:00 1986
From: Gumby at AI.AI.MIT.EDU (David Vinayak Wallace)
Date: May 26 86 02:02 EDT
Subject: ks lossage messages
In-Reply-To: <[MX.LCS.MIT.EDU].587.860519.ZVONA>
Message-ID: <860526020227.5.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU>

    Date: Mon, 19 May 86 11:12:12 EDT
    From: David Chapman <ZVONA at MX.LCS.MIT.EDU>

    Do we need a poor-ks?  

    At 6 this morning, MX started complaining often about being out of
    jobslots on the console.

Messages like this used to go to BUG-ITS.  I figure they should anyway
(and the poor-<xx> lists should be flushed, except for the special case
of the KL).

From ALAN at AI.AI.MIT.EDU  Thu May 22 07:20:17 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 22 86 01:20:17 EDT
Subject: Someday when things calm down we might have time to look into things like this again
Message-ID: <[AI.AI.MIT.EDU].44418.860522.ALAN>

Outputting to a BOJ: channel after the device user no longer has his
JOB: channel open seems to simply hang.  (In the case I'm seeing it
is SIOT to a channel open in .UAO mode.)  I would have expected
this to signal an error, perhaps %ENAPP?

From CENT at AI.AI.MIT.EDU  Thu May 22 05:55:16 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 21 86 23:55:16 EDT
Subject: logbook location
Message-ID: <[AI.AI.MIT.EDU].44369.860521.CENT>

    Date: Wed, 21 May 1986  23:18 EDT
    From: Rob Austein <SRA at XX.LCS.MIT.EDU>
    To:   "Pandora B. Berman" <CENT at AI.AI.MIT.EDU>
    Cc:   BUG-ITS at AI.AI.MIT.EDU, POOOR-MC at 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.

From SRA at XX.LCS.MIT.EDU  Thu May 22 05:18:00 1986
From: SRA at XX.LCS.MIT.EDU (Rob Austein)
Date: May 21 1986  23:18 EDT
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>
Message-ID: <SRA.12208606423.BABYL@XX.LCS.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.

From CENT at AI.AI.MIT.EDU  Thu May 22 04:57:57 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 21 86 22:57:57 EDT
Subject: At the tone, your name will be
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?

From JTW%MIT-SPEECH at XX.LCS.MIT.EDU  Wed May 21 00:00:00 1986
From: JTW%MIT-SPEECH at XX.LCS.MIT.EDU (John Wroclawski)
Date: Wed 21 May 86, 00:00
Subject: ks lossage
In-Reply-To: <12208384120.19.JNC@XX.LCS.MIT.EDU>
Message-ID: <12208388143.21.JTW@MIT-SPEECH>

    From: "J. Noel Chiappa" <JNC at XX.LCS.MIT.EDU>
    Subject: Re: ks lossage

    I think the funny messages from the IMP have to do with some

The RFC that describes 1822L tells all, claiming that the IMP will
send the usual 3-NOP-and-a-reset sequence twice, once in 1822 format
and once in 1822L format, interleaving the messages. You are supposed
to tell it what you want by answering in your choice of format. If you
do this before it has sent the full sequence it will stop sending in
the protocol you don't want.

Which is all well and good, except that this RFC is dated in 1983.  So
it only took them three years to implement...?
-------

From JNC at XX.LCS.MIT.EDU  Wed May 21 00:00:00 1986
From: JNC at XX.LCS.MIT.EDU (J. Noel Chiappa)
Date: Wed 21 May 86, 00:00
Subject: ks lossage
In-Reply-To: <[AI.AI.MIT.EDU].42635.860519.ALAN>
Message-ID: <12208384120.19.JNC@XX.LCS.MIT.EDU>

	I think the funny messages from the IMP have to do with some
new leader format that BBN is introducing. They flag the new style
ones with what looks to old unmodified software with an illegal initial
code. We've just run acrosss this bringing up the 68000 GW IMP code.
-------

From JNC at XX.LCS.MIT.EDU  Wed May 21 00:00:00 1986
From: JNC at XX.LCS.MIT.EDU (J. Noel Chiappa)
Date: Wed 21 May 86, 00:00
Subject: flaky ML
In-Reply-To: <[AI.AI.MIT.EDU].42474.860518.ALAN>
Message-ID: <12208380952.19.JNC@XX.LCS.MIT.EDU>

	Maybe it's not an accident that the 3 machines had bum memory
boards in them?
-------

From ALAN at AI.AI.MIT.EDU  Wed May 21 06:35:26 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 21 86 00:35:26 EDT
Subject: 6 5 4 3 2 1 ...
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.)

From KLOTZ at AI.AI.MIT.EDU  Tue May 20 20:26:00 1986
From: KLOTZ at AI.AI.MIT.EDU (Leigh L. Klotz)
Date: May 20 86 14:26:00 EDT
Subject: No subject
Message-ID: <[AI.AI.MIT.EDU].43062.860520.KLOTZ>

Just now I typed
PH
to get a histogram, and it started up a job called HP, which
said

File can't be OPENed - DSK:FORT;HP SAV
^V  VALRETS OR XFILES NESTED TOO DEEP?INPDL OVERFLOW - PDL RESET?  

but I guess that's another story.

The fair share is 74%, btw.

From CENT at AI.AI.MIT.EDU  Tue May 20 10:39:07 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 20 86 04:39:07 EDT
Subject: AI's first GFR
Message-ID: <[AI.AI.MIT.EDU].42900.860520.CENT>

sort of like its first date, or something -- it's just not the same
thereafter.

anyway, the GFR did run over AI SECOND:, taking 5K blocks off to tape.  Due
to cruftiness not yet worked around in the code (something to do with EOT),
we can't yet run incremental GFRs -- successive small GFRs onto the same
tape.  so i had to go for maximum usage of single tape instead. given the
amount of tape left, i think i could have gone for 6K blocks and won; that
we'll try next time.

the tape is in the rack with the other ITS tapes. as usual, this is a
Sacred GFR Tape -- be careful with it.

All and Sundry are reminded that all 4 KSs (when they're running ITS) are
regularly backed up -- help relieve AI's load by moving your files
elsewhere.

From ALAN at AI.AI.MIT.EDU  Mon May 19 20:11:13 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 19 86 14:11:13 EDT
Subject: ks lossage
In-Reply-To: Msg of Mon 19 May 86 11:12:12 EDT from David Chapman <ZVONA at MX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].42635.860519.ALAN>

    Date: Mon, 19 May 86 11:12:12 EDT
    From: David Chapman <ZVONA at MX.LCS.MIT.EDU>
    ...
    When the machine booted it printed a lot of stuff I couldn't follow
    about the imp. 

All ITS machines with IMPs do this when you boot them now.  I presume the
software in the IMP has changed incompatibly somehow.  We all have to learn
to ignore this until somebody gets around to fixing it.

    'Nother funny thing: LAST time it was booted, it complained that it
    couldn't set the time, because 15 out of the 13 times it got from the
    net did not agree.  Besides sounding damn funny, it seems that
    requiring 15 good times is a little stringent.

Well, its just phrased a little funny.  It -asked- 25 people, and it
insists on getting 15 answers that agree back.  If only 13 people respond,
then indeed 15 of the 13 answers failed to agree!

I don't want to insist on a majority of the -responders-, since then if
only 1 machine responds that happens to be mistaken, the mistake spreads.
Look at it this way, this demon is just a convenience to save you from
having to run PDSET 95% of the time, you have to expect to do it manually
every now and then.

From ZVONA at MX.LCS.MIT.EDU  Mon May 19 17:12:12 1986
From: ZVONA at MX.LCS.MIT.EDU (David Chapman)
Date: May 19 86 11:12:12 EDT
Subject: ks lossage
Message-ID: <[MX.LCS.MIT.EDU].587.860519.ZVONA>

Do we need a poor-ks?  

At 6 this morning, MX started complaining often about being out of
jobslots on the console.  About 10, I couldn't supdup in, so I came
up.  I couldn't log into the console either -- it ignored ^Z.  So I
hit boot, and it said BT SW and ?BT 001200 and wouldn't listen to me.
So I got the fep and started at 777700 and that didn't work either, so
I booted again and it worked that time.  

My guess is that comsat is unhappy about its imp connection and dying
without freeing up its slot.  

When the machine booted it printed a lot of stuff I couldn't follow
about the imp. 

'Nother funny thing: LAST time it was booted, it complained that it
couldn't set the time, because 15 out of the 13 times it got from the
net did not agree.  Besides sounding damn funny, it seems that
requiring 15 good times is a little stringent.

From ALAN at AI.AI.MIT.EDU  Mon May 19 03:39:55 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 18 86 21:39:55 EDT
Subject: flaky ML
In-Reply-To: Msg of Sat 17 May 86 07:26:57 EDT from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].42474.860518.ALAN>

    Date: Sat, 17 May 86 07:26:57 EDT
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
    ML was getting a gross and astonishing number of ECC errors this morning.

We are talking -memory- EEC corrected errors rather than -disk- ECC
corrected errors I believe.

    see console output around 3-4 am. what does this? what can we do about it?

It means that there are some bad bits in ML's memory.  Its funny, AI has
never had a single one of these errors, but all -three- of the new KS10's
have memory boards in them that get ECC errors.

    i was dumping it and shoving some files on during this time -- maybe this
    has something to do with the flaky chaosnet?

Unlikely to be related other than the fact that you were just exercising
the machine in general.  The real problem here is that when I wrote the
code for logging the ECC errors, I didn't fully understand what it would be
like when they started happening regularly.  (My code also has a bug that
causes MD to essentially loop in the scheduler because of a bad bit in a
particularly sensitive location.)  I plan to re-write this code to be less
noisy and more robust soon.

From CENT at AI.AI.MIT.EDU  Sat May 17 13:30:43 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 17 86 07:30:43 EDT
Subject: dumped state
Message-ID: <[AI.AI.MIT.EDU].42220.860517.CENT>

as of this morning, all ITSs here (with the possible exception of the KL)
are being regularly backed up to tape. it -is- safe to store your files on
any of the KSs.

From CENT at AI.AI.MIT.EDU  Sat May 17 13:26:57 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 17 86 07:26:57 EDT
Subject: flaky ML
Message-ID: <[AI.AI.MIT.EDU].42218.860517.CENT>

ML was getting a gross and astonishing number of ECC errors this morning.
see console output around 3-4 am. what does this? what can we do about it?
i was dumping it and shoving some files on during this time -- maybe this
has something to do with the flaky chaosnet?

From CENT at AI.AI.MIT.EDU  Mon May 12 09:47:03 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: May 12 86 03:47:03 EDT
Subject: another way to confuse the issue
Message-ID: <[AI.AI.MIT.EDU].37601.860512.CENT>

    Date: Sat, 10 May 86 01:11:28 EDT
    From: "Mark E. Becker" <MBECK at MC.LCS.MIT.EDU>
    Subject: MC <--> KS/MX mail switching
    To: CENT at MC.LCS.MIT.EDU
    After reading MC MAIL would it be a 'good thing' if I sent address
    update messages to those list maintainers saying that MBECK at MC should
    now be MBECK at KL ?

no. KL is a local-only nickname; on the general arpanet it's an alias for
SRI-KL, and sending your mail there would not help anyone. when the KS
(currently MX) and the KL (currently MC) switch names, they will retain
their model aliases -- the KL will be called MX or (locally) KL, while the
KS will be called MC or KS. this feature was arranged so we could do a
number of local transforms. for instance, the KS will have somewhat
restricted use, so it can concentrate on mail; thus, among other things, we
don't want all those people who get mail on the present MC to have that
mail land on the KS after the name switch. for this reason, someone has run
a program over the inquir database to change all net-addresses of MC to KL;
this will ensure that their mail will end up on the same physical machine
as it does now. all ITS machines share a common inquir database and forward
mail in accordance with the net-addresses people give therein, so all your
mail will end up where you currently get it now. since your mail goes to
OZ, it will continue to make one hop from MC (whichever hardware) to the
twenex; if you received it on MC-KL, you would find it would begin taking
an extra hop to reach your mailbox, because the KL will (probably) go off
the arpanet when the names are switched and all mail bound for it will have
to be forwarded through MC-KS or AI.

From ALAN at AI.AI.MIT.EDU  Mon May 12 03:28:30 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 11 86 21:28:30 EDT
Subject: Ask, and you shall recieve
In-Reply-To: Msg of Sun 11 May 1986  04:59 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].37394.860511.ALAN>

    Date: Sun, 11 May 1986  04:59 EDT
    From: Rob Austein <SRA at XX.LCS.MIT.EDU>
    ...  (although it would be nice if it had some reasonable way to
    deduce what ITSs exist, at run-time).

Because I was updating so many programs to know about the new plethora of
ITS machines, I added exactly this feature.  There is a new table you can
ask for from the .GETSYS uuo: ITSNMS is a table of the sixbit names of the
-current- local ITS machines.  I have already converted most of the
programs that used to have built-in tables of ITS machines (INSTAL, FINGER,
FIND, etc.) to use this.  Do
:UUO GETSYS
for details.

From ALAN at AI.AI.MIT.EDU  Sun May 11 00:26:28 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: May 10 86 18:26:28 EDT
Subject: No subject
In-Reply-To: Msg of Sat 10 May 86 16:56:50 EDT from Jon Solomon <JSOL at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].37156.860510.ALAN>

    Date: Sat, 10 May 86 16:56:50 EDT
    From: Jon Solomon <JSOL at MC>
    for some reason I keep geting "all sockets in use" when there is
    nobody on the system. I did a :p a, and abuot 2/3rds of the connections
    are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe
    way to flush them?

I reloaded the system to get rid of them since nobody could connect to MC
using TCP.  I left a crash dump in MC:CRASH;CRASH TIMWTS if some networking
wizard wants to figure out what YALE.ARPA and SRI-UNIX.ARPA are doing that
cause these connections to stay in TIMWT seemingly forever.

From JSOL at MC.LCS.MIT.EDU  Sat May 10 22:56:50 1986
From: JSOL at MC.LCS.MIT.EDU (Jon Solomon)
Date: May 10 86 16:56:50 EDT
Subject: No subject
Message-ID: <[MC.LCS.MIT.EDU].909418.860510.JSOL>

for some reason I keep geting "all sockets in use" when there is
nobody on the system. I did a :p a, and abuot 2/3rds of the connections
are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe
way to flush them?

From ALAN at AI.AI.MIT.EDU  Sat May 10 05:43:36 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Fri,  9 May 86 23:43:36 EDT
Subject: another mysterious lossage
In-Reply-To: Msg of Fri  9 May 86 22:38:16 EDT from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].37001.860509.ALAN>

    Date: Fri,  9 May 86 22:38:16 EDT
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
    around 22:15 or so, AI stopped listening.... dumped it to CRASH;ITS
    HUNG, then reloaded. 

Looks like the same disk lossage again.  This time ITS had actually run out
of disk clannels.  Perhaps there is something wrong with one of the drives.
I'll try to figure this out after I get finished with this paper.  (I don't
grok the disk code well enough to do this immediately.)  I hope AI
continues to work for that long...  I renamed the crash to be
AI:CRASH;CRASH QLOSS"

BTW, penny, I figured out why MX's system console wouldn't talk to you.
The 8080 front end sometimes gets confused about the state of the system
console and stops forwarding characters through to the 10 (running out of
paper sometimes causes this to happen).  If you simply power-cycle the
LA120 this resets the 8080's opinion of things and you can use the system
console for input again.

From CENT at AI.AI.MIT.EDU  Sat May 10 04:38:16 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Fri,  9 May 86 22:38:16 EDT
Subject: another mysterious lossage
Message-ID: <[AI.AI.MIT.EDU].36993.860509.CENT>

around 22:15 or so, AI stopped listening. it was willing to echo typein but
would not act on it. also it echoed chaos packets, or heard them, or
something low-level like that. DPH and i figured out how to raise switch0
and dumped it to CRASH;ITS HUNG, then reloaded.

From ALAN at AI.AI.MIT.EDU  Fri May  9 04:24:56 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Thu,  8 May 86 22:24:56 EDT
Subject: Recent software crashes.
Message-ID: <[AI.AI.MIT.EDU].36473.860508.ALAN>

Two recent crashes (in MC:CRASH;CRASH DRGFKT and AI:CRASH;CRASH BJUIS)
suggest that there is some problem with job device locking strategy.  I
guess we should have expected that having COMSAT using a job device 24
hours a day would expose some bugs.  The crash on MC is completely crazed
in the number of jobs that are confused.

AI just crashed again with the same lossage I complained about a couple
weeks ago.  The one where the system hangs up just like it does on MC when
the T-300 controller gets fucked.  (See AI:CRASH;CRASH QLOSS and
AI:CRASH;CRASH QLOSS'.)

From Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA  Thu May  8 00:44:00 1986
From: Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA (Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA)
Date: 08 May 86 00:44 +0200
Subject: State of the world
In-Reply-To: <[AI.AI.MIT.EDU].35019.860506.ALAN>
Message-ID: <172046@QZCOM>

We are looking forward, to the moment when we can load the tape
in the tape drive and have the system flying.




From ALAN at AI.AI.MIT.EDU  Tue May  6 06:40:15 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Tue,  6 May 86 00:40:15 EDT
Subject: State of the world
Message-ID: <[AI.AI.MIT.EDU].35019.860506.ALAN>

There are now -five- machines running ITS at MIT, more than have ever
existed simultaneously before.  There is the MC KL10, and four KS10's named
AI, MX, ML, and MD.  

The MC KL10 is off maintenance contract as of the first of this month, so I
suppose its days are numbered.  At some point before the KL10 passes on to
that great machine room in the sky, the MC KL10 and the MX KS10 will swap
their names, and we will plug the new MC KS10 into the old MC's Arpanet
port.  This assures that as far as the outside world is concerned, there
will always be an ITS named MC at that Arpanet address, performing mail
service functions for MIT.  (Let's not get into the hair we will be going
through to make all the mailing lists in the world continue to work.)

The KL10 will remain available for all those who wish to continue to use
it, under the name MX.  When the KL10 retires, the name MX will be retired
with it.

Various other owners of KS10's around the world will be receiving KS10 ITS
distribution tapes in the mail soon.  The last machine we booted (MD) was
built by a volunteer using the printed instructions we plan to include with
our ITS distribution kits.

From CENT at AI.AI.MIT.EDU  Thu May  1 11:28:04 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Thu,  1 May 86 05:28:04 EDT
Subject: imp lossage
Message-ID: <[AI.AI.MIT.EDU].33406.860501.CENT>

AI crashed around 3 or so. complained about IMP lossage of some sort.
dumped to CRASH;IMPOS LOSS.