From MoonatSCRC-TENEX  Tue Jan 24 00:00:00 1984
From: MoonatSCRC-TENEX (David A. Moon)
Date: Tuesday, 24 January 1984, 00:00
Subject: The MC chaosnet ARPA server
Message-ID: <mailman.1201.1479821129.4695.its@nocrew.org>

    Date: Tue 24 Jan 84 04:43-EST
    From: Gail Zacharias <GZ%MIT-OZ at MIT-MC.ARPA>
    Subject: The MC chaosnet ARPA server
    To: moon at MIT-MC, cstacy at MIT-MC
    CC: gz%MIT-OZ at MIT-MC.ARPA
    
    Connecting to this nowadays closes the connection with the close text of:
    ? Internal error - NO SUCH DEVICE
    
    I think the gateway used to (sort of) work in the past.

Well, it works for me, for both FTP and FINGER.  Ah, but wait a minute,
I'm using the TCP server and you're using the ARPA server.  They're the
same program, but the contact name controls the order of trying networks.
I just looked at the source (MC:MMCM;ARPA) and if you use it as the ARPA
server it first tries TCP then if that fails tries NCP.  But NCP ain't
implemented anymore which is why you get "no such device" rather than
"destination host dead" or something of the sort.  I guess a little
restructuring of this code is called for.

From CSTACY at MIT-MC  Tue Jan 31 04:52:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: January 30 1984 22:52 EST
Subject: Chaosnet connections
Message-ID: <mailman.1241.1479821130.4695.its@nocrew.org>

In ITS 1362 on MIT-MC:

Lately MC frequently gets into a state where all CHAOSO calls fail
with DEVICE FULL.  I increased the number of Chaosnet indices from 32.
to 50., because there were 16/32 buffers free, and lots of pending
RFCs and confused users.  I hope this is the correct fix, and that
GCing of something or other is not broken.

From KLOTZ at MIT-MC  Sun Jan 29 15:09:00 1984
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: January 29 1984 09:09 EST
Subject: EMACS echo area
In-Reply-To: Msg of 01/22/84 17:17:46 from DEVON at MIT-ML
Message-ID: <mailman.1242.1479821130.4695.its@nocrew.org>

If you use the EMACS variable Echo Area Height instead of the raw flag
FS Echo Lines your problems will be over.



From ALAN at MIT-MC  Sun Jan 29 01:53:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: January 28 1984 19:53 EST
Subject: _LSPM_ OUTPUT
In-Reply-To: Msg of 28 Jan 1984 19:30 EST from William G. Dubuque <WGD>
Message-ID: <mailman.1243.1479821130.4695.its@nocrew.org>

    Date: 28 January 1984 19:30 EST
    From: William G. Dubuque <WGD>
        Date: 27 January 1984 17:03 EST
        From: Alan Bawden <ALAN>
            Date: 27 January 1984 08:06 EST
            From: Bill Gosper <RWG>
            BIL at mc and rwg at Russian tried to write out gz;grob > at about the
            same time....
	What program was BIL using on MC?  One possible theory is that he
	was using a program that did something incompetent.  Better
	possibility (says Moon standing right behind me) is that RWG's file
	server got and error that he somehow never saw.
    I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file.
    As GZ mentioned, there was a _LSPM_ OUTPUT file laying around for
    awhile after my version was written.

OK, so now we know that it was the file being written by the file server
that never made it.  Sounds like RWG was screwed by his Lisp machine not
telling him about an error.  Since we are now certain that this is not an
ITS problem, or a problem with some non-lispmachine software, the next
person to send mail on this subject should please delete BUG-ITS from the
header.

From WGD at MIT-MC  Sun Jan 29 01:30:00 1984
From: WGD at MIT-MC (William G. Dubuque)
Date: January 28 1984 19:30 EST
Subject: No subject
In-Reply-To: Msg of 27 Jan 1984 17:03 EST from Alan Bawden <ALAN>
Message-ID: <mailman.1244.1479821130.4695.its@nocrew.org>

    Date: 27 January 1984 17:03 EST
    From: Alan Bawden <ALAN>
    To:   RWG
    cc:   BIL, BUG-ITS, GZ, bug-lispm at SCRC-TENEX

        Date: 27 January 1984 08:06 EST
        From: Bill Gosper <RWG>
        BIL at mc and rwg at Russian tried to write out gz;grob > at about the
        same time....

    What program was BIL using on MC?  One possible theory is that he was using
    a program that did something incompetent.  Better possibility (says Moon
    standing right behind me) is that RWG's file server got and error that he
    somehow never saw.
I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file. As GZ
mentioned, there was a _LSPM_ OUTPUT file laying around for awhile
after my version was written. I take it there are no known (a)synchronization
problems that could be at the heart of this?
Whatever the error someone should be responsible for making it know to the
writer who loses since, of course, a lot could be lost this way.

From ALAN at MIT-MC  Fri Jan 27 23:03:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: January 27 1984 17:03 EST
Subject: No subject
In-Reply-To: Msg of 27 Jan 1984 08:06 EST from Bill Gosper <RWG>
Message-ID: <mailman.1245.1479821130.4695.its@nocrew.org>

    Date: 27 January 1984 08:06 EST
    From: Bill Gosper <RWG>
    BIL at mc and rwg at Russian tried to write out gz;grob > at about the
    same time....

What program was BIL using on MC?  One possible theory is that he was using
a program that did something incompetent.  Better possibility (says Moon
standing right behind me) is that RWG's file server got and error that he
somehow never saw.

From RWG at MIT-MC  Fri Jan 27 14:06:00 1984
From: RWG at MIT-MC (Bill Gosper)
Date: January 27 1984 08:06 EST
Subject: No subject
Message-ID: <mailman.1246.1479821130.4695.its@nocrew.org>

BIL at mc and rwg at Russian tried to write out gz;grob > at about the
same time.  Russian paused about a minute in File Finish, but seemed to
return from the m-X Copy File normally (RWG had typed ahead
a c-and a few chars, but no aborts or anysuch.)  Only BIL's version
made it into gz;.  GZ herself reported seeing an open file linger
there for a few minutes and then disappear.

From CHRIS at MIT-MC  Mon Jan 23 20:30:00 1984
From: CHRIS at MIT-MC (Christopher C. Stacy)
Date: January 23 1984 14:30 EST
Subject: No subject
Message-ID: <mailman.1247.1479821130.4695.its@nocrew.org>

I had to reload the password database again; apparently there is
a reproducible way to crash ITS and corrupt this file.
Changes to the database made before 1/20 have been lost.{

From Gumby at MIT-MC.ARPA  Mon Jan 23 08:28:00 1984
From: Gumby at MIT-MC.ARPA (David Vinayak Wallace)
Date: Jan 23 84 02:28 EST
Subject: I may be a loser, but...
In-Reply-To: The message of 22 Jan 84 23:58-EST from David A. Moon <MOON at MIT-MC>
Message-ID: <mailman.1248.1479821130.4695.its@nocrew.org>

    Date: 22 January 1984 23:58 EST
    From: David A. Moon <MOON @ MIT-MC>
	Date: Sunday, 22 January 1984, 07:39-EST
	From: David Vinayak Wallace <Gumby at MIT-MC>
	MC died very strangely tonight.  The IO bay and processor were frozen,
	but the memory and the ampex were happily flashing their lights as if
	nothing was wrong.  There was a red NXM light illuminated on the
	processor bay (I didn't know there was such a light!).

    There isn't.  You must have mistaken something else for the processor;
    perhaps the DL10...
I'm a loser.  It was the DL10.

    I wasn't able to figure out from that dump file how the system crashed.
    I suspect the answer is that it didn't!  I also wasn't able to figure
    out how you stopped it or what command you used to dump it out (there
    weren't any symbols for some reason).

I halted it with break, then used Y in ddt to make the dump.

I assumed MC had died because:
Neither the decscribbler nor the vt52 would respond to ^Z.
You could not open a connection over arpa or chaos (I tried status,
file, and supdup).
Existing arpa, chaos, and dialup connections hung.

Since you couldn't talk to it, I assumed it had crashed.  The front-end
was running fine, as I could wake it up with break.

Perhaps this can help.

david

From MOON at MIT-MC  Mon Jan 23 05:58:00 1984
From: MOON at MIT-MC (David A. Moon)
Date: January 22 1984 23:58 EST
Subject: mc spills her cookies?
Message-ID: <mailman.1249.1479821130.4695.its@nocrew.org>

    Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST
    Date: Sunday, 22 January 1984, 07:39-EST
    From: David Vinayak Wallace <Gumby at MIT-MC>
    Subject: mc spills her cookies
    To: bug-its at MIT-MC

    MC died very strangely tonight.  The IO bay and processor were frozen,
    but the memory and the ampex were happily flashing their lights as if
    nothing was wrong.  There was a red NXM light illuminated on the
    processor bay (I didn't know there was such a light!).

There isn't.  You must have mistaken something else for the processor;
perhaps the DL10, which is the wide bay over near the T-300 disk drives
(between them and the tape drive).  It's a pdp11-to-memory interface.
Or it could have been the DF10, on the left-hand end of the row of 8
memory bays; it's a disk-to-memory interface.  As I recall, both have
red NXM lights.

    I put a crash dump in CRASH MEMPAR (since MC had been getting parity
    errors just before the crash), but since I cleverly neglected to record
    the state of the processor lights, it's probably useless.

I wasn't able to figure out from that dump file how the system crashed.
I suspect the answer is that it didn't!  I also wasn't able to figure
out how you stopped it or what command you used to dump it out (there
weren't any symbols for some reason).

It has been getting parity errors; I think the Ampex memory is turning
to shit (or has been shit all along).

From MOON at MIT-MC  Mon Jan 23 05:42:00 1984
From: MOON at MIT-MC (David A. Moon)
Date: January 22 1984 23:42 EST
Subject: MC crash at 5pm today, dumped to crash;pagfau 1/22/8
Message-ID: <mailman.1250.1479821130.4695.its@nocrew.org>

Fixed in the source and patched in both the running system and the
dump.  When copying a Chaosnet packet into an Internet packet buffer,
it was erroneously using the length of the destination rather than
the length of the source as the length of the transfer; since the
source was shorter it ran off the end of wired memory and took an
exec page fault.

From DEVON at MIT-ML  Sun Jan 22 00:00:00 1984
From: DEVON at MIT-ML (DEVON at MIT-ML)
Date: 22 Jan 1984 00:00
Subject: No subject
Message-ID: <mailman.1251.1479821130.4695.its@nocrew.org>

This is a longstanding "feature" which is probably actually a bug.
When I detach my tree, the info about the echo area is lost, so
that if I reattach and continue an EMACS, it has forgotten about
the echo area on the screen.  Apparently this only happens if I
was actually in EMACS when I was detached (by call waiting) so
I tried the following experiment:

:tctyp printing nosupdup
emacs$j
^Z
:tctyp software

will clobber EMACS' echo area, even though the only thing typed at it
while TCTYP was zero was a ^Z, but

:tctyp printing nosupdup
:tctyp software

has no ill effect.  I can always fix the echo area with the TECO command
FS ECHO LINES$FS ECHO LINES$$ (restarting from DDT with $G clobbers the
line saving info) but it really looks like an ITS bug to me..

From GumbyatMIT-MC  Sun Jan 22 00:00:00 1984
From: GumbyatMIT-MC (David Vinayak Wallace)
Date: Sunday, 22 January 1984, 00:00
Subject: mc spills her cookies
Message-ID: <mailman.1252.1479821130.4695.its@nocrew.org>

MC died very strangely tonight.  The IO bay and processor were frozen,
but the memory and the ampex were happily flashing their lights as if
nothing was wrong.  There was a red NXM light illuminated on the
processor bay (I didn't know there was such a light!).

I put a crash dump in CRASH MEMPAR (since MC had been getting parity
errors just before the crash), but since I cleverly neglected to record
the state of the processor lights, it's probably useless.

david

From CSTACY at MIT-MC  Thu Jan 19 22:20:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: January 19 1984 16:20 EST
Subject: No subject
Message-ID: <mailman.1253.1479821130.4695.its@nocrew.org>

Sometimes you are running some program and type ahead something you
didn't really want.  Perhaps when that typeahead is read it will flush
valuable typeout on your screen, and perhaps also ^Z would have
similar unwanted effects.  Suppose you just wanted flush whatever
pending typein there is.

There is now a new BACKNEXT command: ^_^U is CLEAR INPUT.
This flushes your TTY input buffer, very similar to if 
a .RESET had been done at it.  

It's in the source and patched in the running ITS.  Minor bug: I am
not entirely sure how to get the ^U to echo, will look at this with
MOON later on this week or something.

So, you can do things like this:

:LISP
*
(SLEEP 6.)FOOBAR ^_^U         ;typein cancelled before finished nap
T                             ;the "foobar " was thrown away.



Stay tuned for more exciting news...

From KLOTZ at MIT-MC  Mon Jan 16 04:10:00 1984
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: January 15 1984 22:10 EST
Subject: No subject
Message-ID: <mailman.1254.1479821131.4695.its@nocrew.org>

I was using ITS at the time KMP noted the crash.  I don't know if this
was referring to my tty buffer or if this happened to others, but I was using
EMACS at the time and all of a sudden got a logout message at the
cursor position.  Thereafter after each keystroke I got three more characters.
I also got the following BYE message, but unfortunately the nick-name of
the person ran off the edge of the screen.  I kept pressing keys and
getting more characters until I eventually got nothing, and then it
hung up.

From KMP at MIT-MC  Mon Jan 16 00:38:00 1984
From: KMP at MIT-MC (Kent M Pitman)
Date: January 15 1984 18:38 EST
Subject: MC crashed in tty code (TYOOU1+5; buffer ptr past eob)
Message-ID: <mailman.1255.1479821131.4695.its@nocrew.org>

In ITS in NEX 342, Emacs 162, Teco 1171, ITS 1359 on MIT-MC:

ITS stopped with he following message:
 TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER
The PC was TYOOU1+5.
I dumped this to CRASH;TYOOU1 +5
and reloaded.

From KLH at MIT-MC  Thu Jan 12 11:24:00 1984
From: KLH at MIT-MC (Ken Harrenstien)
Date: January 12 1984 05:24 EST
Subject: No subject
Message-ID: <mailman.1256.1479821131.4695.its@nocrew.org>

I suspect REM's problems have more to do with the TAC than with MC.
I use MC every day via the net, from SRI-NIC, and response seems
pretty good to me.  I wonder if other TAC users have the same problems
(whatever they are).

From DCP at MIT-MC  Thu Jan 12 07:44:00 1984
From: DCP at MIT-MC (David C. Plummer)
Date: January 12 1984 01:44 EST
Subject: No subject
Message-ID: <mailman.1257.1479821131.4695.its@nocrew.org>

    Date: 11 January 1984 22:58 EST
    From: Bill Gosper <RWG @ MIT-MC>

    Although DCP's patch has cured the monster hangups in MC net service,
    echoing and typing are still pathologically slow these past weeks.
    REM is similarly mistreated via the arpanet.
Gosper is a 9600 baud land line and a microwave away from MC.
Just about any traffic on the land line will cause realtime
delays.  When only a microwave link away I notice very few
hangups, and they are only for less than 1 second (I would guess
they are about .7 seconds but I can't really tell).

From RWG at MIT-MC  Thu Jan 12 04:58:00 1984
From: RWG at MIT-MC (Bill Gosper)
Date: January 11 1984 22:58 EST
Subject: No subject
Message-ID: <mailman.1258.1479821131.4695.its@nocrew.org>

Although DCP's patch has cured the monster hangups in MC net service,
echoing and typing are still pathologically slow these past weeks.
REM is similarly mistreated via the arpanet.

From KLH at MIT-MC  Tue Jan 10 10:45:00 1984
From: KLH at MIT-MC (Ken Harrenstien)
Date: January 10 1984 04:45 EST
Subject: No subject
Message-ID: <mailman.1259.1479821131.4695.its@nocrew.org>

    Date: 9 January 1984 22:59 EST
    From: Kent M Pitman <KMP @ MIT-MC>

    Hmm. I just sent mail to BUG-FINGER asking :NAME KMP at OZ
    was replying right away with

     Could not connect to foreign host with TCP.

    but in fact, :OZ is doing this, too, so something must
    be confused with the network.

Either a host table got written out which had OZ's arpanet
address in it, or OZ was down and the NETWRK error analysis code
doesn't know how to handle it properly (maybe because it doesn't
know whether the connection attempt was using CHAOS or TCP).
I re-did the NETWRK package to report TCP errors properly, but
I don't know whether this will help or not.  I doubt many programs
have been recompiled with the new NETWRK yet.

From KMP at MIT-MC  Tue Jan 10 04:59:00 1984
From: KMP at MIT-MC (Kent M Pitman)
Date: January 9 1984 22:59 EST
Subject: No subject
Message-ID: <mailman.1260.1479821131.4695.its@nocrew.org>

Hmm. I just sent mail to BUG-FINGER asking :NAME KMP at OZ
was replying right away with

 Could not connect to foreign host with TCP.

but in fact, :OZ is doing this, too, so something must
be confused with the network.

From KMP at MIT-MC  Sat Jan  7 21:00:00 1984
From: KMP at MIT-MC (Kent M Pitman)
Date: January 7 1984 15:00 EST
Subject: No subject
Message-ID: <mailman.1261.1479821131.4695.its@nocrew.org>

MC has been getting parity errors (three in the last hour)...

 14:16:12	#5   PC = 310000,,017213, JOB# 26, USR: TORBEN L
		     ERR ADDR = 602005433716
		     PARITY ERRORS:
			5,,433717	512500,,400

 14:41:18	#6   PC = 710000,,107117, JOB# 66, USR: GIF HACTRN
		     ERR ADDR = 602004377116
		     PARITY ERRORS:
			4,,377117	211102,,403

 14:41:33	#7   PC = 710000,,107117, JOB# 66, USR: GIF HACTRN
		     ERR ADDR = 602004377116
		     PARITY ERRORS:
			4,377117	211102,403

In case it matters, the machine room seems quite cool and dry
(unlike last week).

From CSTACY at MIT-MC  Fri Jan  6 08:30:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: January 6 1984 02:30 EST
Subject: your patch is on disk now
In-Reply-To: Msg of 6 Jan 1984 02:14 EST from David C. Plummer <DCP>
Message-ID: <mailman.1262.1479821131.4695.its@nocrew.org>


You were trying to dump out a patched ITS BIN file instead of a world
load.  I don't know offhand know why this doesn't work, but I patched
the NITS world load and dumped it out as XITS.  I'll reassemble the
system tomorrow probably anyway...


From DCP at MIT-MC  Fri Jan  6 08:14:00 1984
From: DCP at MIT-MC (David C. Plummer)
Date: January 6 1984 02:14 EST
Subject: No subject
Message-ID: <mailman.1263.1479821131.4695.its@nocrew.org>

I have patched MC so that it only retransmits the first packet on
the transmit queue instead of the entire queue.  There are a few
theories that say this is a reasonable thing to do.  Its greatest
impact is on the slow links which do packet filtering to avoid
complete congestion.  

I would update the on disk version, but the
	<alt>L
	make patch
	<alt>Y
method doesn't seem to work.  (Actually, the resulting file was 7
or so blocks shorter.)  So, if somebody could update the disk
version, or make the patch each time ITS is booted, it would be
appreciated.  The patch is
	CHART2-1/ JFCL  (was JUMPN A,CHART1)
I have updated the source.

Bug-Twenex people: the equivalent source change (if the Dec 10,
1983 code on EE:LIB:<5.MONITOR>CHAOS.MAC is anywhere near correct
(OZ and SPEECH won't talk to me and I couldn't find it on XX) is
to remove the
	JRST CHART1 at CHARTD-1
and replace it with the comment
	;; fall through, since we only retransmit one packet of the list.
This can also be patched to a JFCL if you want to test it.

Other people: You may want to do (or at least try) similar things.

From CSTACY at MIT-MC  Wed Jan  4 06:46:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: January 4 1984 00:46 EST
Subject: No subject
In-Reply-To: Msg of 3 Jan 1984 23:35 EST from Alan Bawden <ALAN>
Message-ID: <mailman.1264.1479821131.4695.its@nocrew.org>

    Date: 3 January 1984 23:35 EST
    From: Alan Bawden <ALAN>
    To:   BUG-ITS

    What happened to the source of SYS:ATSIGN DEVICE?

The source does not seem to be online anywhere, and is not on MC's
backup tape.  I'll go looking for it on AI backup tape later on.

From ALAN at MIT-MC  Wed Jan  4 05:35:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: January 3 1984 23:35 EST
Subject: No subject
Message-ID: <mailman.1265.1479821131.4695.its@nocrew.org>

What happened to the source of SYS:ATSIGN DEVICE?