From ALAN at MIT-MC  Wed Jan 23 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 23 January 1985, 00:00
Subject: Tempest in a TELSER.
In-Reply-To: Msg of 23 Jan 1985 17:42-EST from Alan Bawden <ALAN>
Message-ID: <mailman.1000.1479821123.4695.its@nocrew.org>

    Date: 23 January 1985 17:42-EST
    From: Alan Bawden <ALAN>
    ...  I plan to fix the timeout algorithm to close the connection after
    it sees the STY idle twice in a row.  That, and a check every 15
    seconds, should assure you of at -least- 15 seconds (but not more than
    30) before closing the connection....

Ok I did this.  Actually I did it with a 20 second timeout.  Thus, you now
get at least 20 seconds, at most 40 seconds, and an average of 30 seconds.
A reason to want a longer timeout is to give the TELSER's single page a
chance to swap out and stay out.  This probably doesn't matter much on MC
but it might help a bit on AI.  

An alternative solution, that would take a few more lines of code, would be
for TELSERs to keep a USR: channel open to the toplevel job on the other
end of the STY.  Then they would get an interrupt when that job went away,
indicating some kind of interesting job manipulation was taking place on
the other side.  Unfortunately nothing would happen if the tree was just
detached, foo.

From ALAN at MIT-MC  Wed Jan 23 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 23 January 1985, 00:00
Subject: Tempest in a TELSER.
In-Reply-To: Msg of 22 Jan 1985 19:39-EST from Daniel Weise <DANIEL>
Message-ID: <mailman.1001.1479821123.4695.its@nocrew.org>

    Date: 22 January 1985 19:39-EST
    From: Daniel Weise <DANIEL>
    Why is MC suddenly breaking supdup connections when I 
    log out?  I prefer the behavior where I have to manually
    break the connection.

'Cause we are experimenting with adjusting the timeout to different values.
Currently it is patched to be 15 seconds.  For years it has been set at 5
minutes.  I think we are all agreed that the current setting is a loser.  I
plan to fix the timeout algorithm to close the connection after it sees the
STY idle twice in a row.  That, and a check every 15 seconds, should assure
you of at -least- 15 seconds (but not more than 30) before closing the
connection.

Unless anybody would like to object or propose anything else?

From DANIEL at MIT-MC  Tue Jan 22 00:00:00 1985
From: DANIEL at MIT-MC (Daniel Weise)
Date: 22 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1002.1479821123.4695.its@nocrew.org>

Why is MC suddenly breaking supdup connections when I 
log out?  I prefer the behavior where I have to manually
break the connection.

From ALAN at MIT-MC  Tue Jan 22 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 22 January 1985, 00:00
Subject: TELSER timeout
Message-ID: <mailman.1003.1479821123.4695.its@nocrew.org>

The current timeout is definitely too short.  MC has hung up on me
instantly a couple of times in the last few days.  Perhaps the code should
be fixed to log itself out only if it sees the STY idle twice in a row.

From ALAN at MIT-MC  Sun Jan 20 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 20 January 1985, 00:00
Subject: Page fault caused by .GETSYS
In-Reply-To: Msg of 19 Jan 1985 17:07-EST from Kent M Pitman <KMP>
Message-ID: <mailman.1004.1479821123.4695.its@nocrew.org>

    Date: 19 January 1985 17:07-EST
    From: Kent M Pitman <KMP>
    MC died claiming:
     Page fault in system at 304000,,130422

This has been happening on and off for quite some time.  .GETSYS would
sometimes cause a seemingly spurious page fault.  I introduced this bug
myself last summer and I just fixed it in the source.  Sure feels good to
delete some of those crash dumps knowing that you actually fixed the
problem!

From CSTACY at MIT-MC  Sun Jan 20 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 20 January 1985, 00:00
Subject: Closing net connections when your STY goes away 
In-Reply-To: Msg of 18 Jan 1985 22:42-EST from Charles Frankston <CBF>
Message-ID: <mailman.1005.1479821123.4695.its@nocrew.org>

Five minutes is admittedly a long time.  I think I would be happy if
it were one half minute, I think (15 seconds might be OK, but I want
to be more gracious).  If no one responds to CBF's query in a few days,
I'll change it in the source.


From CSTACY at MIT-MC  Sun Jan 20 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 20 January 1985, 00:00
Subject: HSNAME change
In-Reply-To: Msg of 19 Jan 1985 02:35-EST from Alan Bawden <ALAN>
Message-ID: <mailman.1006.1479821123.4695.its@nocrew.org>

I fixed this (right this time).

From KMP at MIT-MC  Sat Jan 19 00:00:00 1985
From: KMP at MIT-MC (Kent M Pitman)
Date: 19 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1007.1479821123.4695.its@nocrew.org>

MC died claiming:
 Page fault in system at 304000,,130422
 BugPC/ PFA3+2

I dumped this to CRASH;PFA3+2 19-JAN
and cold booted. -kmp

From ALAN at MIT-MC  Sat Jan 19 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 19 January 1985, 00:00
Subject: HSNAME change
In-Reply-To: Msg of 18 Jan 1985 23:48-EST from Robert E. Bruccoleri <BRUC>
Message-ID: <mailman.1008.1479821123.4695.its@nocrew.org>

    Date: 18 January 1985 23:48-EST
    From: Robert E. Bruccoleri <BRUC at MC>
    My home directory was changed from USERS0; to GUEST0; recently
    without the relocation of my files or the redirection of my mail....

    Date: 18 January 1985 23:59-EST
    From: Kent M Pitman <KMP at MC>
    INQUIR seems to give people with a "Z" designation (clinical decision
    making group) a GUESTn home dir if they don't have a home dir of their
    own.  This is arguably a bug....

Earlier the same day....

    Date: 18 January 1985 09:26-EST
    From: Christopher C. Stacy <CSTACY at MC>
    Subject: AI file directories
    To: BUG-INQUIR at MC
    cc: BUG-DDT at MC, BUG-ITS at MC, KMP at MC, TAFT at MC
    Enough occasional and small users from AI use MC now that I was
    getting tired of using INQUIR to manually force their home directory
    to be AI0.  This morning I taught INQUIR that if an "A" person comes
    along who does not have a directory, it will automatically stick them
    in AI0 (rather than USERSn).  Of course, if AI0 starts getting too
    full due to many people, we can make more dirs.   But I don't think
    that's too likely since most AI people with alot of files have their
    own directory and don't need to use AI0.

Well, more than just AI users seem to have their directories changed, so I
retracted the new version of LSRTNS, reassembled DDT (being careful to
increment the version number this time) and installed it.  The buggy 
ATSIGN DDT was renamed to be ATSIGN XDDT.

From CBF at MIT-MC  Fri Jan 18 00:00:00 1985
From: CBF at MIT-MC (Charles Frankston)
Date: 18 January 1985, 00:00
Subject: Closing net connections when your STY goes away 
Message-ID: <mailman.1009.1479821123.4695.its@nocrew.org>

Well, I think the current timeout is kind of long, so I have temporarily
patched it to 15 seconds instead of 5 minutes.  If anyone remembers why
it was 5 minutes, I'd be interested in knowing.

This will also help free up STYs faster for those times when the system
is heavily loaded.

From CSTACY at MIT-MC  Fri Jan 18 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 18 January 1985, 00:00
Subject: TAC binary mode
In-Reply-To: Msg of Fri 18 Jan 85 09:25:48-PST from Mark Crispin <MRC at SU-SCORE.ARPA>
Message-ID: <mailman.1010.1479821123.4695.its@nocrew.org>


Foo. We like it waiting for me to type "^Z", rather than gratitously
disconnecting.  As for decisions being cast in stone, I just happen to
think it is the right decision (and the users and other programmers
here concur.)  If you re-read my message, I did suggest that perhaps
there should be a way for users to ask to be disconnected upon logout.
By the way, when coming in over the net I myself turn on binary mode
in my login init file so that I can use the META key on my home
terminal.  Since I run a program (:TBMOFF) in my logout init file
which turns it back off, I never get wedged.


From MRC at SU-SCORE.ARPA  Fri Jan 18 00:00:00 1985
From: MRC at SU-SCORE.ARPA (Mark Crispin)
Date: Fri 18 Jan 85, 00:00
Subject: No subject
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Fri 18 Jan 85 03:06:00-PST
Message-ID: <mailman.1011.1479821123.4695.its@nocrew.org>

     Bullshit.  The connection was *not* in a wedged state.  It was
waiting for me to type CTRL/Z to start another ITS job.  I deliberately
typed @ B I S because I wanted a binary link without the TAC intercept
character interfering.  The last thing I want when I am logged in to a
host is to have the damn Tip (be it Internet, Chaos, Pup, DECnet, or
whatever) decide to grab one of my characters as an intercept character.
I know damned well how to change the intercept character, but with the
advent of certain display editors which use all 128 ASCII characters for
commands there is NO "safe" intercept character.

     One of the reasons why ITS in the old days was so great was that
the system programmers of that time didn't consider the decisions of the
past to be enshrined in stone and unchangable.
-------

From CSTACY at MIT-MC  Fri Jan 18 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 18 January 1985, 00:00
Subject: AI file directories
Message-ID: <mailman.1012.1479821123.4695.its@nocrew.org>

Enough occasional and small users from AI use MC now that I was
getting tired of using INQUIR to manually force their home directory
to be AI0.  This morning I taught INQUIR that if an "A" person comes
along who does not have a directory, it will automatically stick them
in AI0 (rather than USERSn).  Of course, if AI0 starts getting too
full due to many people, we can make more dirs.   But I don't think
that's too likely since most AI people with alot of files have their
own directory and don't need to use AI0.


From CSTACY at MIT-MC  Fri Jan 18 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 18 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 17 Jan 1985 21:58-EST from Mark Crispin <MRC>
Message-ID: <mailman.1013.1479821124.4695.its@nocrew.org>


Come on, the bug is clearly in your user host which stopped paying
attention to you.  Closing your connection is just one thing which it
prevented you from doing by putting you into a wedged state.
It is a feature that ITS does not close connections when you log out.
Maybe there should be a :LOGOUT option to force your connection closed
though, for people who want this.

From RMS at MIT-MC  Thu Jan 17 00:00:00 1985
From: RMS at MIT-MC (Richard M. Stallman)
Date: 17 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1014.1479821124.4695.its@nocrew.org>

I always find it unpleasant when OZ breaks connections with me
just because I log out.  

From MRC at MIT-MC  Thu Jan 17 00:00:00 1985
From: MRC at MIT-MC (Mark Crispin)
Date: 17 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1015.1479821124.4695.its@nocrew.org>

I wish ITS closed the connection when you logged out.  It is easier to
re-open the connection if you want it than it is to extract yourself
from a host which won't hang up when you log out.  I had to gun my TELSER
to get out of a @B I S connection from the TAC.

From KMP at MIT-MC  Thu Jan 17 00:00:00 1985
From: KMP at MIT-MC (Kent M Pitman)
Date: 17 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1016.1479821124.4695.its@nocrew.org>

MC's network terminals and the (AAA) next to the system console and
such stopped responding. The system console seemed to be happy, so I
ran :.;BOOT11 from there and things seem happy again.

From KLOTZ at MIT-MC  Fri Jan 11 00:00:00 1985
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: 11 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ <TAR>
Message-ID: <mailman.1017.1479821124.4695.its@nocrew.org>

    Date: 9 January 1985 15:48-EST
    From: Thomas A. Russ <TAR>
    Sender: TAR0
    To:   BUG-ITS

    :CHUNAME doesn't work.  It prints the "-- Massacre and Reset --"
    question, but when I type <space>, it responds with a single question
    mark ("?") and does nothing.

Probably you, in your incarnation as TAR0, were trying to :CHUNAM to
TAR, but there already was a TAR, possibly detached.  DDT was informing
you in its usual terse fashion, (which has saved us at last count over
2^23 character output calls since ITS was first booted).


From HDT at MIT-MC  Thu Jan 10 00:00:00 1985
From: HDT at MIT-MC (Howard D. Trachtman)
Date: 10 January 1985, 00:00
Subject: archives
Message-ID: <mailman.1018.1479821124.4695.its@nocrew.org>

It also seems to me that control-Zing out of writing a file in emacs and
proceeding consitently leaves a Jjob in my name, but which doesn't seem
to get restarted in a manner capable of finishing the write.

From CSTACY at MIT-MC  Wed Jan  9 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 9 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1019.1479821124.4695.its@nocrew.org>

When an archive device dies maybe it should return device not available
or if it was because of size limitations, device full.

From CSTACY at MIT-MC  Wed Jan  9 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 9 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ <TAR>
Message-ID: <mailman.1020.1479821124.4695.its@nocrew.org>

    Date: 9 January 1985 15:48-EST
    From: Thomas A. Russ <TAR>
    Sender: TAR0
    To:   BUG-ITS

    :CHUNAME doesn't work.  It prints the "-- Massacre and Reset --"
    question, but when I type <space>, it responds with a single question
    mark ("?") and does nothing.

This would probably be a DDT bug, not an ITS bug.
:CHUNAME works fine for me.  Please send a real bug report,
specifying the input you gave the function.

From TAR at MIT-MC  Wed Jan  9 00:00:00 1985
From: TAR at MIT-MC (Thomas A. Russ)
Date: 9 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1021.1479821124.4695.its@nocrew.org>

:CHUNAME doesn't work.  It prints the "-- Massacre and Reset --"
question, but when I type <space>, it responds with a single question
mark ("?") and does nothing.


From KLH at MIT-MC  Fri Jan  4 00:00:00 1985
From: KLH at MIT-MC (Ken Harrenstien)
Date: 4 January 1985, 00:00
Subject: Tape archives
Message-ID: <mailman.1022.1479821124.4695.its@nocrew.org>

How much tape are you actually talking about flushing?  I doubt you plan
to re-use the tapes; therefore it must just be the storage requirements
that you object to.  But tapes don't take up much room at all (depending
on how you chose to store them), and even if there is only one file on
each tape which is worth keeping, it is still much easier to simply keep
that tape than to try to achieve any kind of compaction.

I don't think any ITS tapes should be junked unless a large majority of
ITS users thinks it is reasonable.  There just is no way to predict
which files you will someday be interested in retrieving, and once they
are flushed, they are gone forever.  The ITS systems have vastly more
historic significance than MIT-XX, or in fact most other computer systems
on the network, and this should be a consideration.

Incidentally, the notion of taking a complete file system dump and locking
it away for backup, archival, or posterity is considered a good idea in
other places as well.  We do this on SRI-NIC, for example.  Perhaps
you are just doing it too often.

From CENT at MIT-MC  Fri Jan  4 00:00:00 1985
From: CENT at MIT-MC (Pandora B. Berman)
Date: 4 January 1985, 00:00
Subject: amazing brain damage
Message-ID: <mailman.1023.1479821124.4695.its@nocrew.org>

irene grief has apparently gotten the idea into her head that
flushing all old ITS tapes up to six months ago is not only
feasible but a good idea. see CENT;LCS TAPES for details.

From CSTACY at MIT-MC  Wed Jan  2 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 2 January 1985, 00:00
Subject: hangup
In-Reply-To: Msg of 2 Jan 1985 14:15-EST from Alan Bawden <ALAN>
Message-ID: <mailman.1024.1479821124.4695.its@nocrew.org>


    Date: 2 January 1985 14:15-EST
    From: Alan Bawden <ALAN>
    In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy <CSTACY>

    Ah!  So perhaps the hangup detection is busted on some line?  Did you
    experiment to see if it was a repeatable failure?  Which line did this
    happen on?

Unfortunately, I was running out the door at the time and didn't
remember to check which dialup line I was on until it was too late.
I suspect that it was T04.  I suppose we could check the console log.

Mostly I sent the message to make sure that other people thought that
hangup detection is really supposed to work on all the lines we have.
It doesn't work on the ROLM lines though, does it?

From ALAN at MIT-MC  Wed Jan  2 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 2 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1025.1479821124.4695.its@nocrew.org>

    Date: 2 January 1985 09:44-EST
    From: Christopher C. Stacy <CSTACY>
        Date: 1 January 1985 20:05-EST
        From: Alan Bawden <ALAN>
            Date: 1 January 1985 15:55-EST
            From: Sydney E. Atkinson <SGA>
            hanging up a dialup line does not log you out.
	It shouldn't.  People shouldn't lose the contents of their editor
	buffers just because they tripped over the phone cord.  Hanging up
	a dialup line detaches your job tree so that you can dial in again
	and reattach to it (or gun it down if it was wedged in some way).
	Have you observed some behavior other than this?
    The job was not detached either: it was left sitting there for at
    least five minutes, and when I dialup up the same line I was already
    logged in to SGA's session.

Ah!  So perhaps the hangup detection is busted on some line?  Did you
experiment to see if it was a repeatable failure?  Which line did this
happen on?

From CSTACY at MIT-MC  Wed Jan  2 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 2 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 1 Jan 1985 20:05-EST from Alan Bawden <ALAN>
Message-ID: <mailman.1026.1479821124.4695.its@nocrew.org>

    Date: 1 January 1985 20:05-EST
    From: Alan Bawden <ALAN>
    To:   SGA
    cc:   BUG-ITS
    In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson <SGA>

        Date: 1 January 1985 15:55-EST
        From: Sydney E. Atkinson <SGA>
        hanging up a dialup line does not log you out.

    It shouldn't.  People shouldn't lose the contents of their editor buffers
    just because they tripped over the phone cord.  Hanging up a dialup line
    detaches your job tree so that you can dial in again and reattach to it (or
    gun it down if it was wedged in some way).  Have you observed some behavior
    other than this?

The job was not detached either: it was left sitting there for at
least five minutes, and when I dialup up the same line I was already
logged in to SGA's session.

From ALAN at MIT-MC  Tue Jan  1 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 1 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson <SGA>
Message-ID: <mailman.1027.1479821124.4695.its@nocrew.org>

    Date: 1 January 1985 15:55-EST
    From: Sydney E. Atkinson <SGA>
    hanging up a dialup line does not log you out.

It shouldn't.  People shouldn't lose the contents of their editor buffers
just because they tripped over the phone cord.  Hanging up a dialup line
detaches your job tree so that you can dial in again and reattach to it (or
gun it down if it was wedged in some way).  Have you observed some behavior
other than this?

From SGA at MIT-MC  Tue Jan  1 00:00:00 1985
From: SGA at MIT-MC (Sydney E. Atkinson)
Date: 1 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1028.1479821124.4695.its@nocrew.org>

hanging up a dialup line does not log you out.

From CSTACY at MIT-MC  Tue Jan 29 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 29 January 1985, 00:00
Subject: MINITS HUBs making noise
Message-ID: <mailman.1451.1479821149.4695.its@nocrew.org>

NE438B, NE438C, and NE437A have terminal lines running open
or something.  They keep generating a lot of noise, some of
which is control-Zs, so they are connecting to MC and typing
the noise at us.  This eats up network resources and prevents
some people from logging in,etc.  I heard that the power company
is being flaking today, which may have something to do with it.

From CSTACY at MIT-MC  Mon Jan 28 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 28 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 27 Jan 1985 02:09-EST from Devon S. McCullough <DEVON>
Message-ID: <mailman.1452.1479821149.4695.its@nocrew.org>

You are probably getting memory parity errors.

From DEVON at MIT-MC  Sun Jan 27 00:00:00 1985
From: DEVON at MIT-MC (Devon S. McCullough)
Date: 27 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1453.1479821149.4695.its@nocrew.org>

Two or three times in the last day or so I've gotten

top level interrupt, tree detached

This usually happens when I have been typing ^Z's and ^G's because
the system is not responding.  Now I have a dead detached tree.
I can usually type ^_'s to prove that the system itself is alive
even though nothing is responding.

From CSTACY at MIT-MC  Sat Jan 26 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 26 January 1985, 00:00
Subject: not knowing the time
Message-ID: <mailman.1454.1479821149.4695.its@nocrew.org>

OK, FTP servers now die cleanly if they don't know the time.

From ALAN at MIT-MC  Fri Jan 25 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 25 January 1985, 00:00
Subject: no arpa?
In-Reply-To: Msg of 25 Jan 1985 21:00-EST from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1455.1479821149.4695.its@nocrew.org>

    Date: 25 January 1985 21:00-EST
    From: Christopher C. Stacy <CSTACY>
        Date: Fri 25 Jan 85 12:08:58-EST
        From: Glenn S. Burke <GSB at XX>
        is mc's arpa connection busted?  can't reach it from rutgers 
        or xx via internet.
    It does for me at the moment.

I guess you can tell from this that Chris reads his mail in reverse!

From CSTACY at MIT-MC  Fri Jan 25 00:00:00 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 25 January 1985, 00:00
Subject: no arpa?
In-Reply-To: Msg of Fri 25 Jan 85 12:08:58-EST from Glenn S. Burke <GSB at MIT-XX.ARPA>
Message-ID: <mailman.1456.1479821149.4695.its@nocrew.org>

    Date: Fri 25 Jan 85 12:08:58-EST
    From: Glenn S. Burke <GSB at MIT-XX.ARPA>
    To:   bug-its at MIT-MC.ARPA
    Re:   no arpa?

    is mc's arpa connection busted?  can't reach it from rutgers 
    or xx via internet.

It does for me at the moment.

From GSB at MIT-XX.ARPA  Fri Jan 25 00:00:00 1985
From: GSB at MIT-XX.ARPA (Glenn S. Burke)
Date: Fri 25 Jan 85, 00:00
Subject: no arpa?
Message-ID: <mailman.1457.1479821149.4695.its@nocrew.org>

is mc's arpa connection busted?  can't reach it from rutgers or xx via internet.
-------

From ALAN at MIT-MC  Fri Jan 25 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 25 January 1985, 00:00
Subject: No subject
In-Reply-To: Msg of 25 Jan 1985 10:15-EST from Kent M Pitman <KMP>
Message-ID: <mailman.1458.1479821149.4695.its@nocrew.org>

    Date: 25 January 1985 10:15-EST
    From: Kent M Pitman <KMP>
    System went down at 6:25am this morning. Whoever brought it back up
    forgot to set the time so mostly no one could log in.

And MC hasn't been talking TCP since then, because the tables were clogged
with a zillion dead FTP servers because of the silly .VALUE-when-ITS-
doesn't-know-the-time screw I reported a couple weeks ago.

From KMP at MIT-MC  Fri Jan 25 00:00:00 1985
From: KMP at MIT-MC (Kent M Pitman)
Date: 25 January 1985, 00:00
Subject: No subject
Message-ID: <mailman.1459.1479821149.4695.its@nocrew.org>

System went down at 6:25am this morning. Whoever brought it back up forgot
to set the time so mostly no one could log in.

From ALAN at MIT-MC  Thu Jan 24 00:00:00 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: 24 January 1985, 00:00
Subject: Novelty
Message-ID: <mailman.1460.1479821149.4695.its@nocrew.org>

Just a event to ponder.  The other day I supduped from MC back to MC
(presumably using Chaosnet, I didn't think to check), and I was greeted
with the following:

    S.1487. PWORD.2630.
    TTY 52
    12. Lusers, Fair Share = 6%

    MC IT*

Note that five characters ("MC IT") have been displaced.  Conceivably the
fact that the machine was so heavily loaded, and that the user and server
were both on the same machine, could have allowed some timing screw that
almost never happens normally.