From MOON at MIT-MC  Mon Jun 25 00:00:00 1984
From: MOON at MIT-MC (David A. Moon)
Date: 25 June 1984, 00:00
Subject: No subject
Message-ID: <mailman.1164.1479821128.4695.its@nocrew.org>

T10 on MC is broken.  Twice I dialed up to it and my input
was thoroughly garbled.  I redialed to T12 and had no problems.

From CBF at MIT-MC  Wed Jun 20 00:00:00 1984
From: CBF at MIT-MC (Charles Frankston)
Date: 20 June 1984, 00:00
Subject: No subject
Message-ID: <mailman.1165.1479821128.4695.its@nocrew.org>

The dialup garbage is NOT Concept 100 control sequences.  It seems to
happen with me on triple modems, which seem to raise Carrier Detect before
they've quite settled, perhaps before they're synchornized.  If you wait
an extra two seconds after dialing up before typing return, it probably
won't happen.

From ALAN at MIT-MC  Wed Jun 20 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 20 June 1984, 00:00
Subject: Dialup Gubble
In-Reply-To: Msg of 20 Jun 1984 15:24-EDT from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1166.1479821128.4695.its@nocrew.org>

    Date: 20 June 1984 15:24-EDT
    From: Christopher C. Stacy <CSTACY>
    Sometimes when I dial in to the Vadics, ITS sends alot of
    unrecognizable garbage to my terminal when printing out the greeting
    message.  This goes away after a TCTYP command, and a friend of mine
    on a VT100 claims the garbage looks like Concept-100 terminal control
    sequences, although on my AAA it just prints blobs.

If this was true, then wouldn't everybody who uses Vadics see randomness
when they dial up?  (At least occasionally.)  I have never seen anything of
the sort.  

Perhaps its marsh gas?

From CSTACY at MIT-MC  Wed Jun 20 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 20 June 1984, 00:00
Subject: No subject
Message-ID: <mailman.1167.1479821128.4695.its@nocrew.org>

Sometimes when I dial in to the Vadics, ITS sends alot of
unrecognizable garbage to my terminal when printing out the greeting
message.  This goes away after a TCTYP command, and a friend of mine
on a VT100 claims the garbage looks like Concept-100 terminal control
sequences, although on my AAA it just prints blobs.

From JNC at MIT-XX.ARPA  Sun Jun 17 00:00:00 1984
From: JNC at MIT-XX.ARPA (J. Noel Chiappa)
Date: Sun 17 Jun 84, 00:00
Subject: Looping in the scheduler (with interrupts on, luckily)
In-Reply-To: Message from "David C. Plummer <DCP @ MIT-MC>" of Sat 16 Jun 84 20:14:00-EDT
Message-ID: <mailman.1168.1479821128.4695.its@nocrew.org>

	I think this was due to the console 11 dying. It seemed to
be completely frozted; i.e. trying "LOAD ADDR" didn't result in
whatever number you had in the switches showing up in the ADDR lights.
-------

From DCP at MIT-MC  Sat Jun 16 00:00:00 1984
From: DCP at MIT-MC (David C. Plummer)
Date: 16 June 1984, 00:00
Subject: Looping in the scheduler (with interrupts on, luckily)
Message-ID: <mailman.1169.1479821128.4695.its@nocrew.org>

This morning I dialed up MC and got on T12.  I was merrily doing
random things.  I didn't do anything for a while, but when I
tried I got no response.  I figured MC died.  I was wrong.

Just recently ALAN noticed I was around and informed me that not
only was my job still there, but it was taking up all the extra
computrons MC could offer.  It was looping in TYSTE1 waiting for
the -11 to set DTEOST to some negative value.  The -11 wasn't
doing this.  The job could not be logged out or easily examined
because it couldn't be PCLSRed.

The first thing I tried was to tell the job (by bashing the PC)
to try sending another doorbell to the -11.  That didn't work.
So, I set DTEOST to -1 by myself.  The job unfroze and we had
control again (for some value of control).  Sending a TTY message
to that console (causing output) now waits at TYOW4 waiting for
the output buffer to be sufficiently empty to output.  This will
never happen, but at least it is PCLSRable and doesn't take up
the entire machine.

As experiments, I tried using T13 and T14.  The first attempt to
output on these caused the same phenomena: Looping in TYSTE1.
Bashing DTEOST to -1 and outputing again caused waiting at TYOW4.
(Using :COPY to the TTY line was sufficient to cause this.)  This
unfortunately means T12, T13, and T14 are no longer usable for
experimentation unless you go in and reset the pointers and
counts...

This is probably just a hardware lossage and requires MC to be
rebooted to get the piece of dung -11 unwedged.

From DLW at SCRC-RIVERSIDE.ARPA  Mon Jun 11 14:02:00 1984
From: DLW at SCRC-RIVERSIDE.ARPA (Daniel L. Weinreb)
Date: Jun 11 84 08:02 EDT
Subject: TCP gatway
Message-ID: <840611080222.9.DLW@CHICOPEE.SCRC.Symbolics>

In Symbolics 3600 Experimental System 243.758,
Experimental Hardcopy 21.31, Experimental Zmail 84.157,
Experimental LMFS 38.91, Experimental Tape 22.17,
Experimental Basic Sage 2.26, Experimental New Documentation System 2.0,
Experimental Print 35.10, Experimental IP-TCP 9.1, Japanese 15.0,
Experimental TD80-Tape 1.22, cold load 114, microcode TMC5-MIC 290,
FEP 18, Big band, on Chicopee:

>>Error: 
         Unable to invoke FILE (TCP-FTP) -- CMU-CS-SPICE (via MC on CHAOS) by any path.
         TCP-GATEWAY (TCP-GATEWAY) -- MC on CHAOS: Cannot connect to 21 at CMU-CS-SPICE via MC:
         Request to MC for a TCP 128.2.254.139 25 connection was refused.
         Reason given was "TCP connection to foreign host failed"
While in the function NETI:GET-CONNECTION-FOR-SERVICE-1  NET:GET-CONNECTION-FOR-SERVICE  (:DEFUN-METHOD FS:TCP-FTP-VALIDATE-CONN)

It would be nice if the MC gateway would pass on some more info than
just "conection to foreign host failed".  If you try to FTP to
CMU-CS-SPICE right now, using FTPU on MC, it says that "Request for
Connection was refused by foreign host"; it would be nice it this info
had been passed through by the gateway.

From CSTACY at MIT-MC  Tue Jun 12 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 12 June 1984, 00:00
Subject: Reconnecting Spock's brain.
In-Reply-To: Msg of 12 Jun 1984 00:13-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1170.1479821128.4695.its@nocrew.org>

    Date: 12 June 1984 00:13-EDT
    From: Alan Bawden <ALAN>
    To:   BUG-TIMES
    Re:   Reconnecting Spock's brain.

    I am quite certain that the TIMES/CTIMES program is totally broken.  The
    other night when MC was mistaken about the correct time, Penny ran :TIMES
    to find out what other sites on the net thought the time was.  To our
    surprise the program reported that every machine it could reach
    more-or-less agreed with MC's bogus time.  When Penny ran PDSET to correct
    MC, every machine made the corresponding correction.  I also observe that
    the times the program reports are ALWAYS in ascending order!  I think it is
    quite obvious what is going on here...

I have fixed this, and spiffed the program up a little while at it.