From CBF at MIT-MC  Sat Nov 28 00:00:00 1981
From: CBF at MIT-MC (CBF at MIT-MC)
Date: 28 Nov 1981 00:00
Subject: System console
Message-ID: <mailman.484.1479821112.4695.its@nocrew.org>

With the rate of activity on MC nowadays (actually for a couple of years)
now, I've noticed that spying on the system console (or using :SYSMSG) has
less and less often given me the information I was looking for.
Frequently all one can see is the last 20 seconds of activity.  Anyway,
this is a suggestion that the system console's buffer be made substantially
larger.  If things work the way I guess they do, the only substantial
disadvantage I can think of this having is that output resets on that
terminal when it is being used an an ordinary terminal will take a long
time.


From CHRISatMIT-AI  Sun Nov 22 00:00:00 1981
From: CHRISatMIT-AI (Chris Stacy)
Date: 22 November 1981, 00:00
Subject: last message
Message-ID: <mailman.485.1479821112.4695.its@nocrew.org>

Foo. I just found out what UNAME is.

From CHRISatMIT-AI  Sun Nov 22 00:00:00 1981
From: CHRISatMIT-AI (Chris Stacy)
Date: 22 November 1981, 00:00
Subject: No subject
Message-ID: <mailman.486.1479821112.4695.its@nocrew.org>


ITS crashed in ZUSER2. The UNAME was SYS (USER=0).
Examined some stuff on the TTY and reloaded ITS.

From GSB at MIT-ML  Fri Nov 20 00:00:00 1981
From: GSB at MIT-ML (GSB at MIT-ML)
Date: 20 Nov 1981 00:00
Subject: No subject
Message-ID: <mailman.487.1479821112.4695.its@nocrew.org>

the second value returned by RQDATE sez the system was brought up in
1983 (or should i interpret that as 1883?).  The time program claims
in the source to not handle uptimes greater than a year, so that
explains why it says 287 days rather than 98 years.


From MOON at MIT-MC  Thu Nov 19 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 19 Nov 1981 00:00
Subject: :REATTA broken
Message-ID: <mailman.488.1479821112.4695.its@nocrew.org>

I changed the ATTACH system call to call ATTYCI rather than ATTYC2.
A new system ought to get installed on MC soon.

RMS, is this the correct fix?

From DCP at MIT-MC  Wed Nov 18 00:00:00 1981
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 18 Nov 1981 00:00
Subject: No subject
Message-ID: <mailman.489.1479821112.4695.its@nocrew.org>

Has the REATTA symbolic system call been changed (since may or
so)?  Has anybody else not been able to use the :REATTA program?
:REATTA hasn't changed since December 1978, yet I have not been
able to sucessfully use this program for a month (at least).

Specifics: (from a space cadet keyboard over the chaos net)

<CALL>
dcp0u
:detach
<CALL>
dcp0u
--Attach your detached tree--<RUBOUT>
:reatta dcp/k
	;;; at this point, nothing happens, but if I hit <CALL>
<CALL>
	;;; I get another PWORD, so I got detached again!!
dcp0u
--You have several detached trees--
--Attach a detached tree--<SPACE>
ERROR: ATTACH: BAD CHANNEL NUMBER
375>>.CALL 1046 (ATTACH)
	;;; This is :REATTA bombing
:calprt
Arg 1:  3		;;; JOB channel
Arg 2:  400042		;;; TTY to attach it to
Control bits: 400000

:ichan 3
USR: DCP HACTRO (uai\10)
			;;; looks valid to me.
:vv
DCP    HACTRO	  2  DCP;   Det +15:11		;;; the disowned tree
DCP    HACTRN	...  DCP;
  ...


I did a little poking:
I can understand why (SYSTEM;ITS)NATTAC calls
(SYSTEM;TS3TTY)ATTYC2 to decode the tty number, but why does
ATTYC2 JRST to ATTYC7 instead of to ATTYC8.  ATTYC7 does not
allow 400000+ttynum but ATTYC8 does (that is the only difference
between the routines).


From DCP at MIT-MC  Thu Nov 12 00:00:00 1981
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 12 Nov 1981 00:00
Subject: No subject
Message-ID: <mailman.490.1479821112.4695.its@nocrew.org>

I did a little poking around and found the following:

There is a mojor difference between TS3TTY 301 and TS#TTY 305.
The majority of the difference seems to be in the ATTY** routines
(the ones that determine if you have the TTY and whether you
should wait for it). 

I tried the the following:
	a^K
	factor(ratsimp((x+y)^12));
	^Z ^P
now I typed RETURN several times (say 20). After the 10th I got
the message  JOB A WANTS THE TTY.  Macsyma wanted to SIOT.  I
looked at the siot string and it contained %TDMV1 codes among
other things.  When you <alt>P the macsyma you will see that the
cursor goes to just above the JOB A WANTS THE TTY message, NOT
where you left off and NOT where you happened to be.

The culprit:
	RCPOS (Read cursor pos).  In the rearrangement of the
ATTY** routines it appears RCPOS has been changed to allow you to
read the cursor even when you don't have the tty (it used to wait
for the TTY).  Unfortunately, MACSYMA uses this information to
compute %TD codes.


From JPG at MIT-MC  Thu Nov 12 00:00:00 1981
From: JPG at MIT-MC (JPG at MIT-MC)
Date: 12 Nov 1981 00:00
Subject: No subject
Message-ID: <mailman.491.1479821112.4695.its@nocrew.org>

On about 10/29/81 I noticed that MACSYMA was misbehaving when it was 
$Ped after having been ^Zed and ^Ped.  Namely the cursorpos calculation 
was off and it displayed the next expression one or two rows too high.
Just now I showed it to RWK, and as we suspected it was an ITS (TS3TTY) 
problem, we transferred the MACSYMA over to ML which is running an older
ITS (#1230 as opposed to #1244) and tried the same experiment there where 
it ran fine.  The difference was that you get the interrupt for 
"Job wants the TTY" at an earlier point on ML than on MC, namely at 
CRSRP1+4>>.CALL RCPOS (which presumably does the necessary cursorpos 
recalculation) rather than at IFORCE+11>>.CALL SIOT  .  If it is 
relevant, I am on a VT52.  Also, the thing I ask MACSYMA to do is 
FACTOR(RATSIMP((X+Y)^20));  which just uses up some time, so while 
it is computing, I ^Z ^P , and $P when it says "Job wants the TTY".
(Sorry I am so verbose, but I wanted to make sure I included whatever 
info may be necessary.)


From GJC at MIT-MC  Mon Nov  9 00:00:00 1981
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 09 Nov 1981 00:00
Subject: No subject
Message-ID: <mailman.492.1479821112.4695.its@nocrew.org>

Right now there are about 20 NETRFC jobs from MIT-XX, all in the FINISH
state and not doing anything else, but taking up net ports.
I've gunned them down.


From DCP at MIT-MC  Sat Nov  7 00:00:00 1981
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 07 Nov 1981 00:00
Subject: SCML system call
Message-ID: <mailman.493.1479821112.4695.its@nocrew.org>

Why does SCML cause an error when it tries to set the echo area
and it does not have the TTY?  :CALL SCML does not say there are
any errors for this system call.  In fact, the routine ASCML in
SYSTEM;TS3TTY puts the echo area in a magic field with
	DPB B,[$TBECL,,TTYTBL(U)]
Which I guess will get put in the right place when
the job gets .DTTY'd.  But after the DBP it does a POPJ P,
causing an error instead of
	AOS (P)
	POPJ P,
which would appear to be the right thing.


From DICKatMIT-AI  Fri Nov  6 00:00:00 1981
From: DICKatMIT-AI (Richard C. Waters)
Date: 6 November 1981, 00:00
Subject: No subject
Message-ID: <mailman.494.1479821112.4695.its@nocrew.org>

dump is broken in a weird way.  if you try to list the files on a tape
on dsk it gives you the error message that the file dsk:wall 1
doesn't exist, and just won't do anything.  

		Dick