From CSTACY  Wed Jul 28 00:00:00 1982
From: CSTACY (Christopher C. Stacy)
Date: 28 Jul 1982, 00:00
Subject: No subject
Message-ID: <[MIT-DMS].238845>

This system seems to be printing bogus LOGIN and LOGOUT messages.
God knows what else it mightbe doing.



From SWG  Sat Jul 31 00:00:00 1982
From: SWG (S. W. Galley)
Date: 31 Jul 1982, 00:00
Subject: bogus LOGIN & LOGOUT messages
In-Reply-To: <[MIT-DMS].238845>
Message-ID: <[MIT-DMS].239379>

No doubt it's because TAA patched ITS to record them
for non-TTY trees as well as TTY-controlled ones.


From TK at MIT-MC  Sat Jul 31 00:00:00 1982
From: TK at MIT-MC (TK at MIT-MC)
Date: 31 Jul 1982 00:00
Subject: No subject
Message-ID: <mailman.298.1479821108.4695.its@nocrew.org>

Just so other people who look at AI don't spin wheels unnecessarily.
AI is currently dropping dead during the instruction following LPMR's
(and possibly other pager related instructions).  There also appears
to be a bad file in the acount directory (cdata or something) which
prevents the system from coming up, but which the salvager seems
incapable of fixing trivially.  I haven't looked at this second problem
very hard.  The following loop will hang the processor:

LMPR
JFCL
JFCL
AOJA .-3

PC stops at lpmr + 2, having fetched and done the fetch cycle (including
PC increment) of the instruction at lmpr + 1.
I probably won't get a chance to look at this further for a few days.
I'd suggest a debugging strategy of using the logic analyzer to locate the
place where the pulse train drops dead.  This might be caused by additional
pulses coming back from the pager.  A likely failure is the TTL-DEC converters
going to the pager.


From ALANatMIT-MC  Wed Jul 28 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 28 July 1982, 00:00
Subject: MC emacs stuck in Kansas
Message-ID: <mailman.300.1479821108.4695.its@nocrew.org>

    TFT at MIT-MC 07/27/82 08:31:40 Re: MC emacs stuck in Kansas
Subject: MC emacs stuck in Kansas
    To: (BUG MC) at MIT-MC
    I think this should go to bug-mc, not bug-emacs:

    When I try to use either M-x find file, or C-x-C-f, to get a file from
    Oz, the defaulter gets very confused.  I think it doesn't even know that
    Oz exists! ...

Huh?  Are you complaining that C-X C-F OZ:<DIR>FOO.BAR doesn't work?  (While
you CAN reference files on AI f'rinstance?)  While it IS possible that this
could be made to work it isn't exactly trivial.  Maybe someday someone will
have a hack attack and do it.  This is one of the prices we pay for running
an incompatible timesharing system on OZ rather than an Incompatible
Timesharing System.

From TKatMIT-AI  Sat Jul 31 00:00:00 1982
From: TKatMIT-AI (Tom Knight)
Date: 31 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.302.1479821109.4695.its@nocrew.org>

AI has decided to "work" for the time being.  I.e., Moon and I intimidated it
with scope probes, and it stopped failing.  This is the second unrelated marginal
failure in as many weeks, neither of which has been properly fixed.  Don't count
on it continuing to work.

From MOON at MIT-MC  Mon Jul 26 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 26 Jul 1982 00:00
Subject: AI's problems--TEN-11 software
Message-ID: <mailman.303.1479821109.4695.its@nocrew.org>

For what's worth, I fixed these in the source.  Someone who wanted to be
useful might assemble and install a new system on AI.  I made the Chaosnet
respect TEN11F, which it hadn't heard of, and I made the pointer in the
TV-11 memory get ranged checked in the 2 places it seemed to be used,
causing a bug-halt with an appropriate message if it was wrong.

From RWKatSCRC-TENEXatMIT-MC  Sat Jul 24 00:00:00 1982
From: RWKatSCRC-TENEXatMIT-MC (Robert W. Kerns)
Date: 24 Jul 1982, 00:00
Subject: .TEMP.
In-Reply-To: Your message of 24-Jul-82 0243-EDT
Message-ID: <mailman.304.1479821109.4695.its@nocrew.org>

TMPKIL is supposed to run, of course, and there is supposed to be a .TEMP.
directory, and there should be a -READ- -THIS- file in the directory that
explains what the directory is for, and it should be reap-protected.  I
believe that TMPKIL explicitly does not delete -READ- -THIS-; the do-not-reap
bit is to discourage people, not programs.
-------


From CSTACYatMIT-AI  Fri Jul 23 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 23 July 1982, 00:00
Subject: .TEMP.
Message-ID: <mailman.305.1479821109.4695.its@nocrew.org>


When the system came up after being broken the other day,
I noticed TMPKIL running.  I wasnt sure who/what started it,
so I left it be.

From RWKatSCRC-TENEXatMIT-MC  Fri Jul 23 00:00:00 1982
From: RWKatSCRC-TENEXatMIT-MC (Robert W. Kerns)
Date: Friday, 23 July 1982, 00:00
Subject: AI:.TEMP.;
In-Reply-To: The message of 23 Jul 82 09:54-EDT from Rodney A. Brooks <BROOKS at MIT-AI>
Message-ID: <mailman.306.1479821109.4695.its@nocrew.org>

    Date: 23 July 1982 09:54-EDT
    From: Rodney A. Brooks <BROOKS at MIT-AI>
    on lispm Terminal-Q complains of the non-existnece of directory AI: .TEMP.;LMSCN >.
    I assume this is either the reslt of recent vandalism or overzealous directory
    reclamation?

Perhaps someone deleted the -READ- -THIS- file, and the program that
reaps that directory (deleting files more than a day old that don't have
the do-not-reap bit and are not -READ- -THIS-) ran, leaving no files
in the directory?

Does AI run that program?  I seem to recall that it's run by PFTHMG
DRAGON on MC.  I think it's called TMPKIL.


From TKatMIT-AI  Thu Jul 22 00:00:00 1982
From: TKatMIT-AI (Tom Knight)
Date: 22 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.307.1479821109.4695.its@nocrew.org>

AI's problems, after 2 nights of hacking, turned out to be software [sort-of].
The system was getting page faults referencing NXM exec pages, while PI in progress
on channel 7.  The problem had to do with a location in the TV-11 being the exactly
wrong value to cause the LDB and ADD at SSLCK8+4 or so to produce an address of
one more than the page boundary.  This was compounded and made more difficult to find
by a second bug in which turning off the 10-11 code makes the chaonet clock routine
reference exec NXM, again at clock level, without checking the TEN11F flag.
This happens on calls to T11CHK, which should just popj if TEN11F is disabled.
This problem was eventually debugged with clipleads halting the machine on exec
memory protect failures.
The bugs have not been patched, but the system will presumably "never" get into
that state again.  I'll edit the sources after breakfast.

From MOON at MIT-MC  Fri Jul 16 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 16 Jul 1982 00:00
Subject: disk constipation
Message-ID: <mailman.308.1479821109.4695.its@nocrew.org>

	205056	Attempting to send messages queued to host MIT-OZ
	205056	  ICP->MIT-OZ...
	205057	QID=<[MIT-MC].317543>
	205057		TO->MARTY
	205059	  CMSG  ID=<[MIT-MC].317655> EXP->DCP at 354
	211553		TO->DCP

    Notice the 25 minute delay.  The constipation did coincide with
    my typing G inside EMACS RMAIL.  Then again, it could be
    unrelated.  During the constipation, ANYBODY doing an OPEN on a
    disk file would hang, but could be PCLSR'd.

This is usually due to running out of disk channels, and deadlocking
where you have several programs each of which wants a lot of disk channels,
has some, and is waiting for more.  COMPLR and PUB are prime offenders
in this respect since they open many channels and keep them open for
many minutes.  You can look at the variable in the system whose name
is (I think) QFCHN, the number of free disk channels.

From DCP at MIT-MC  Fri Jul 16 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 16 Jul 1982 00:00
Subject: No subject
Message-ID: <mailman.309.1479821109.4695.its@nocrew.org>

Is there something wrong with the disk code?  MC constipated for
quite a while just now, and here is comsat's stats for the time:

    205056	Attempting to send messages queued to host MIT-OZ
    205056	  ICP->MIT-OZ...
    205057	QID=<[MIT-MC].317543>
    205057		TO->MARTY
    205059	  CMSG  ID=<[MIT-MC].317655> EXP->DCP at 354
    211553		TO->DCP

Notice the 25 minute delay.  The constipation did coincide with
my typing G inside EMACS RMAIL.  Then again, it could be
unrelated.  During the constipation, ANYBODY doing an OPEN on a
disk file would hang, but could be PCLSR'd.


From MOONatMIT-MC  Wed Jul 14 00:00:00 1982
From: MOONatMIT-MC (David A. Moon)
Date: 14 July 1982, 00:00
Subject: [MP: ITS question]
Message-ID: <mailman.310.1479821109.4695.its@nocrew.org>

    Date: Wednesday, 14 July 1982  00:45-EDT
    Sender: GREN at MIT-OZ
    From: GREN at MIT-AI
    To: BUG-ITS at AI
    Subject: [MP: ITS question]

    Date: Saturday, 10 July 1982  21:37-EDT
    From: Mark Plotnick <MP at MIT-XX>
    To:   gren at MIT-MC
    Re:   ITS question

    I hear you're an ITS expert.  Could you tell me what this piece
    of code attempts to do?  My intuition tell me that it's trying
    to figure out what tty number your console tty is at, but there
    must be easier ways to do this.
	      .OPEN CH,[SIXBIT /  #TTY/]
	       .VALUE
	      .SUSET [<.RIOC+CH>,,T]
	      LDB N,[220600,,T]

	    Mark

    I thought that bits 3.1-3.6 were the error code, set on non-skip
    .CALLs.
That's .IOS.
             What is N getting?
The TTY number.   .SUSET .RCNSL would be a better way.

From MOONatMIT-MC  Sun Jul 11 00:00:00 1982
From: MOONatMIT-MC (David A. Moon)
Date: 11 July 1982, 00:00
Subject: .IOC
Message-ID: <mailman.313.1479821109.4695.its@nocrew.org>

It's the same as IOCHNM inside ITS.  You can look at the comments on that.
The right half is an index into internal device tables, and the left half
contains device-dependent bits and fields.  However, the reason it is not
documented is probably that it is not generally useful and only exists for
completeness.


From CSTACYatMIT-AI  Sun Jul 11 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 11 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.314.1479821109.4695.its@nocrew.org>


In ITS 1273, DDT 1388, on AI:

PWORD, MAIL, FINGER, and WHO, were all broken last night for
some reason.  Now they all work.

Did someone fix this stuff, or did it (ummm) fix itself.

From GRENatMIT-MC  Sun Jul 11 00:00:00 1982
From: GRENatMIT-MC (Ian G. Macky)
Date: 11 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.315.1479821109.4695.its@nocrew.org>


The World According to >INFO.;ITS USETS:


.IOC +<n>	+- +-	input/output channel

	The variable .IOC+<n> is the input/output channel
	word for channel <n>, for n between 0 and 17 octal.
	Normally zero for a closed channel.



[This is not horribly informative.  Can anyone tell me what
 exactly is in thess words?  I'll fix the USETS doc once the
 stuff is known... --gren]

From KFLatMIT-AI  Sun Jul 11 00:00:00 1982
From: KFLatMIT-AI (Keith F. Lynch)
Date: 11 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.316.1479821109.4695.its@nocrew.org>

:F  and :FINGER and :WHOIS  all die, with or without jcl. :F gives me
the header line, then XGP, then, immediately on a new line, 
ILOPR; 17770>>0   0/   10400,,500000   0/    10400,,500000
:FINGER and :WHOIS gives similar results. There is no problem with
:U or :UJ or :WHO or :WHOJ.
 :F worked fine about two hours ago.
						...Keith

From DIGEXatMIT-AI  Sun Jul 11 00:00:00 1982
From: DIGEXatMIT-AI (Doug Humphrey)
Date: 11 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.317.1479821109.4695.its@nocrew.org>

:f and :who are blowing up on me. nothing special I am doing.

:f blows with

ILOPR; 17770>>0


From CSTACYatMIT-AI  Sat Jul 10 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 10 July 1982, 00:00
Subject: I answered Guby's FINGER bug report (there was no bug)
Message-ID: <mailman.318.1479821109.4695.its@nocrew.org>



From GUMBYatMIT-AI  Sat Jul 10 00:00:00 1982
From: GUMBYatMIT-AI (David Vinayak Wallace)
Date: 10 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.319.1479821109.4695.its@nocrew.org>

:f %bbnu
hangs forever. Do all sites have finger servers? ITS should time out
intelligently (it certainly does if another ITS is down).

From zvonaatMIT-AI  Mon Jul  5 00:00:00 1982
From: zvonaatMIT-AI (David Chapman)
Date: 5 July 1982, 00:00
Subject: No subject
Message-ID: <mailman.320.1479821109.4695.its@nocrew.org>

sys3;ts k is linked to sys3;ts logout which ain't they'.

From KLHatMIT-AI  Thu Jul  1 00:00:00 1982
From: KLHatMIT-AI (Ken Harrenstien)
Date: 1 July 1982, 00:00
Subject: AI not accepting ARPAnet connections
Message-ID: <mailman.321.1479821109.4695.its@nocrew.org>

Hey, what's with this server telnet lossage?  Any attempt to
connect gets me a "ITS being deubbgged, go away" message,
but after two days of this crap I find that I can get in
via CHaos from MC.  I'm pretty pissed, since I've been
trying to get at my mail to process ATSIGN, HOSTS3, and
HEADER-PEOPLE stuff; also, unless I can get in you're
going to lose the disk space that all the digests take
up in my mail.

Would whoever slammed the door please consider that 99% of
network people are okay guys, and deserve a little notice.

While this is being put to rights, how about flushing PWORD
for connections from SRI-NIC?  That used to be set up OK
but someone apparently reset things.  Again I'm irked; I
used to think that friendships counted for something more
than being treated like a total random.