From CENT at AI.AI.MIT.EDU  Thu Feb 27 05:35:16 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Feb 26 86 23:35:16 EST
Subject: ai crashed again
Message-ID: <[AI.AI.MIT.EDU].16595.860226.CENT>

not just with the NXM during DUMP lossage. it got that (during the CHECK
phase) and proceeded immediately to an MTAPE:RH11 error, IMP:I NXM...
dumped to CRASH;IMP NXM. so i reloaded and tried to run ICHECK on the
tape. it got a DSK ERR UNTI#0... BUGPC/CAI QHE+3  $Q-2/SKIPGE Q,,QSDU
dumped to CRASH;DISK ERR.
the second time, ICHECK worked.

From GUMBY at MC.LCS.MIT.EDU  Tue Feb 25 20:02:21 1986
From: GUMBY at MC.LCS.MIT.EDU (David Vinayak Wallace)
Date: Feb 25 86 14:02:21 EST
Subject: Disk error
Message-ID: <[MC.LCS.MIT.EDU].830224.860225.GUMBY>

MC crashed, it looks like because it thought one of the tridents had
been powered off.  I doubt anybody cares, but I dumped it to CRASH
QINTE0 just in case.

From ALAN at AI.AI.MIT.EDU  Mon Feb 24 19:38:49 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Feb 24 86 13:38:49 EST
Subject: No subject
Message-ID: <[AI.AI.MIT.EDU].16000.860224.ALAN>

Well, basically I don't seem to ever be able to get the space to end of
tape operation to work for me.  Symptom:  Mount a scratch tape and copy
some files onto it (using :COPY for example).  Rewind the tape (using the
REWIND command in DUMP).  Open MT0: in .BIO mode and issue a 
.MTAPE [ch,,[10]], while watching the drive.  Observe that it clearly
doesn't go to the end of the tape.  Do the same UUO again without closing
the channel and get an IRRECOVERABLE DATA ERROR.

We are certainly going to need space-to-end-of-tape to work before we can
start doing GFRs on a regular basis, since I understand GFR tapes are
just appended together.

Another oddity:  Suppose you wrote three files on the tape.  Rewind the
tape and try reading them (using :PRINT).  Observe that it looks like there
is an extra, fourth, empty file after the files you wrote (before you start
getting DEVICE FULL, which I presume is what you expect to get at the end
of the tape).

From ALAN at MC.LCS.MIT.EDU  Mon Feb 24 19:14:44 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Feb 24 86 13:14:44 EST
Subject: This tape misery never ends.
Message-ID: <[MC.LCS.MIT.EDU].828798.860224.ALAN>

A fellow just tried to read a 7-track tape (from ML) on AI's tape drive.
The results were pretty interesting.  He certainly didn't get any bits back
and he caused DUMP and the magtape code to get pretty upset.  The real fun
started when he tried to kill the DUMP job.  His DDT got hung up in .UCLOSE
at MTICL+12 waiting for outstanding tape commands to go away.

I took a crash dump in AI:CRASH;MTAPE CLOSE.  Note that some interesting
error messages from the tape driver were printed on the system console
before this happened.

I'll bet lots of pinheads try this in the future.  Perhaps we sould license
people before they can run DUMP?

From CSTACY at AI.AI.MIT.EDU  Wed Feb 19 06:32:01 1986
From: CSTACY at AI.AI.MIT.EDU (Christopher C. Stacy)
Date: Feb 19 86 00:32:01 EST
Subject: KS10 crash
Message-ID: <[AI.AI.MIT.EDU].14598.860219.CSTACY>

AI crashed in the IMP code (at IMPIOS+4).  I dumped it to CRASH;CSTACY IMPOS.