From ALAN at MIT-MC  Tue Oct 30 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 30 October 1984, 00:00
Subject: No subject
In-Reply-To: Msg of 30 Oct 1984 11:46-EST from Kenneth Byrd Story <STORY>
Message-ID: <mailman.1055.1479821125.4695.its@nocrew.org>

    Date: 30 October 1984 11:46-EST
    From: Kenneth Byrd Story <STORY>
    To:   BUG-DDT
    I keep getting logged-out automatically by mc; what's the problem?

Well, as far as I know nothing on ITS ever causes you to be "logged-out
automatically".  What exactly were the symptoms?  Did you get a message
like: "Top level interrupt, tree detached"?  Did you just get "MC ITS 1382
Console XX Free. HH:MM:SS"?  When you reconnected did DDT offer to reattach
you to a detached tree or tell you that you had dead detached trees?  How
were you reaching MC?  (ROLM? Dialup? Chaosnet?)

From Moon at SCRC-QUABBIN.ARPA  Sun Oct 28 23:38:00 1984
From: Moon at SCRC-QUABBIN.ARPA (David A. Moon)
Date: Oct 28 84 17:38 EST
Subject: Getting Detached from MC
In-Reply-To: The message of 12 Oct 84 13:42-EDT from Thomas A. Russ <TAR at MIT-MC>
Message-ID: <841028173837.9.MOON@EUPHRATES.SCRC.Symbolics>

    Date: 12 October 1984 13:42-EDT
    From: Thomas A. Russ <TAR @ MIT-MC>

    I seem to be getting detached from MC regularly when I dial in over
    the ROLM switch from my office.  I wonder if this could be some problem
    related to the ROLM system.  I have DTI # 4303 connected to wall jack # 333
    in room 369.

    I don't know what line on MC is being called.  The symptom is that my job
    on MC gets a top level interrupt and is detached.  The connection to MC
    is left intact.

    Even as I write this message, it happens again.

There used to be a bug, which may still be around, where a disconnected dialup
line got the bogus message "top level interrupt job detached" printed on it.
The job was detached because the dialup line was disconnected, not because it
got a top-level interrupt, but the logout/detach-message printer didn't know
that.  Of course if the dialup line was really disconnected, no one sees the
erroneous message (except people spying on the dialup line, which is how this
was discovered originally).

I also believe that the Rolm switch has a bug where when you tell it to disconnect
it drops "carrier detect" several seconds before it stops passing bits through,
so you see some garbage bits.

What all this suggests is that maybe you are getting detached because the Rolm
switch is saying it's hanging up, or MC or its front-end pdp-11  incorrectly thinks
the Rolm is saying it's hanging up.

From ALAN at MIT-MC  Fri Oct 12 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 12 October 1984, 00:00
Subject: Getting Detached from MC
In-Reply-To: Msg of 12 Oct 1984 13:42-EDT from Thomas A. Russ <TAR>
Message-ID: <mailman.1056.1479821125.4695.its@nocrew.org>

    Date: 12 October 1984 13:42-EDT
    From: Thomas A. Russ <TAR>
    ...  The symptom is that my job on MC gets a top level interrupt and is
    detached....

Well, it would be nice to know what interrupt it is that you are getting.
If it happens sometime when you don't need to reattach the tree, you might
leave it detached so that an ITS hacker can take a look at it.

From TAR at MIT-MC  Fri Oct 12 00:00:00 1984
From: TAR at MIT-MC (Thomas A. Russ)
Date: 12 October 1984, 00:00
Subject: Getting Detached from MC
Message-ID: <mailman.1057.1479821125.4695.its@nocrew.org>

I seem to be getting detached from MC regularly when I dial in over
the ROLM switch from my office.  I wonder if this could be some problem
related to the ROLM system.  I have DTI # 4303 connected to wall jack # 333
in room 369.

I don't know what line on MC is being called.  The symptom is that my job
on MC gets a top level interrupt and is detached.  The connection to MC
is left intact.

Even as I write this message, it happens again.

	Tom.

From ALAN at MIT-MC  Thu Oct 11 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 11 October 1984, 00:00
Subject: Fair warning...
Message-ID: <mailman.1058.1479821125.4695.its@nocrew.org>

Until further notice everybody should be carefull about editing the sources
for ITS itself, as I am in the process of conditionalizing it for the KS
processor.

From MARTY%MIT-OZ at MIT-MC.ARPA  Sun Oct  7 00:00:00 1984
From: MARTY%MIT-OZ at MIT-MC.ARPA (Martin David Connor)
Date: Sun 7 Oct 84, 00:00
Subject: 28 page host table too big?
Message-ID: <mailman.1059.1479821125.4695.its@nocrew.org>


I fetched the latest NIC host table and installed it on MC,
and suddenly I couldn't get a DDT from OZ.  I backed out, renaming it
to SYSBIN;HOSTS3 TOOBG?, and was then able to SUPDUP in and get a DDT without
it barfing and saying there was a PWORD bug. I bet the bug is it couldn't
map the host table.

Anyway, someone should look at PWORD.


From ED at MIT-MC  Tue Oct  2 00:00:00 1984
From: ED at MIT-MC (Ed Schwalenberg)
Date: 2 October 1984, 00:00
Subject: Don't try this at home kids...
Message-ID: <mailman.1060.1479821125.4695.its@nocrew.org>

I was logged in from home as Alan did this, and got to see that my most-hated
ITS bug has been fixed:  when the system comes up from a crash, it no longer
resets the baud rate on dialed-up lines.  Thanks to whoever fixed this.

PS. to Alan:  Not coincidentally, I was doing :USET UPC when it crashed.

From ALAN at MIT-MC  Tue Oct  2 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 2 October 1984, 00:00
Subject: Don't try this at home kids...
Message-ID: <mailman.1061.1479821125.4695.its@nocrew.org>

Setting %PSPUB in your PC flags causes all kinds of havoc to break out on
MC.  The first time I did it tonight the system console printed:

PAGE FAIL ERROR #1,  PC = 772740,,301  JOB # 34, USR: ALAN   J     , PFW = 543000,,301

When the job returned to DDT, DDT claimed it was getting a PURINS
interrupt (which I didn't even think could happen on KLs!).  I guess you
can tell from this that I was actually setting all the flags...

Since I couldn't see the system console from my office where I was doing
this, I did it several times.  Eventually I seem to have hung the
microcode.  A few controlled experiments later I crashed MC again with an
error that contained the string "BAD PAGE FAIL WORD" (the decwriter was
dropping so many characters thats about all I could see, I wish that sucker
was more reliable).