From RSG at MIT-ML  Wed Sep 30 00:00:00 1981
From: RSG at MIT-ML (RSG at MIT-ML)
Date: 30 Sep 1981 00:00
Subject: No subject
Message-ID: <mailman.509.1479821112.4695.its@nocrew.org>

I tried to copy a file from ML to MC.  What got created on the MC directory
is a locked file (multiple copies with the same name and a * in leftmost
column of the directory listing).  The file in question is MC: EF; RSG LISPIN .

... rsg


From ZvonaatMIT-AI  Mon Sep 28 00:00:00 1981
From: ZvonaatMIT-AI (David Chapman)
Date: 28 September 1981, 00:00
Subject: No subject
Message-ID: <mailman.510.1479821112.4695.its@nocrew.org>

I did a pdset on ai since the system seemed to think it was 11/11/81.
Probably some files will have this creation data so maybe users should
be warned in system msg.

From EAKatMIT-MC  Sun Sep 27 00:00:00 1981
From: EAKatMIT-MC (Earl A. Killian)
Date: 27 September 1981, 00:00
Subject: [DCP: forwarded]
Message-ID: <mailman.511.1479821112.4695.its@nocrew.org>

Date: 25 September 1981, 00:00
From: David C. Plummer <DCP>
To:   BUG-CRTSTY

I think this is your fault:

I am on a HEATH19 running under a CRTSTY. It looks like I got the
TTYSMT variable of the last person to use this sty. It would be a
good idea for CRTSTY to set that value to zero (or whatever is
the right thing for the various terminal types) before shoving
the ^Z down it. You should probably do this even if you think it
is ITS's responsibility to set it to zero when the sty gets
opened for the first time.


From RMSatMIT-AI  Sun Sep 27 00:00:00 1981
From: RMSatMIT-AI (Richard M. Stallman)
Date: 27 September 1981, 00:00
Subject: No subject
Message-ID: <mailman.512.1479821112.4695.its@nocrew.org>

My XX job became hung permanently in CHAOSO because its CHSNOS was 0.
The net appeared to be working; I was able to make new connections
to XX and MC.  The connection state was still OPEN, according to PEEK.
The "flag" was 20003.  Ibf, Pbf and Ack were 0; both window sizes were 5.

At the time the problem began, the fair share moved up to 120% and stayed
there for several updates of the who line.  Then it came back to a
legitimate value.

The problem was worse because this happened with SUPDUP at interrupt level
and it would not recognize Break.

Can Moon say what other info to look for if this happens again?

From GRENatMIT-MC  Tue Sep 22 00:00:00 1981
From: GRENatMIT-MC (Ian G. Macky)
Date: 22 September 1981, 00:00
Subject: [RLB: jobdev / ITS bug, I guess]
Message-ID: <mailman.513.1479821112.4695.its@nocrew.org>

Ancient mail from my jobdev munging days, never had any more problems
once I got my act together... probably should have just thrown this away,
but dunno, maybe someone loves bug mail.
-----
Date: 06/17/81 01:11:15
From: RLB
Re:   jobdev / ITS bug, I guess

As best as I can determine, the system crashed doing a JOBRET for your JOB.07
returning whatever to your job FOO. At the point of the crash, the system
is hacking FOO on behalf of JOB.07, and hence requires that FOO be (internally)
stopped.  But FOO was not stopped, which is ostensibly an impossible condition,
do it halted.  I randomly tried continuing at the location after the check,
guessing that only FOO or JOB.07 would be screwed, but I didn't understand
the clock interrupt level logic the system was up to, so it couldn't continue.
I suggest that you try to recover as best you can the circumstances of what
you were doing and the state of the code, and ship it off along with your
munging of this note to BUG-ITS.


From DEFBOB at MIT-MC  Thu Sep 17 00:00:00 1981
From: DEFBOB at MIT-MC (DEFBOB at MIT-MC)
Date: 17 Sep 1981 00:00
Subject: No subject
Message-ID: <mailman.514.1479821112.4695.its@nocrew.org>

I don't know where to send this message so I'll send it here.
    
If a user detaches his tree at 4:00 p.m. with the intention of attaching it a few hours
later, say 8:00, is the tree nevertheless destroyed (?chopped down?) automatically by 
someone between those particular hours or between any other particular hours?


From DEFBOB at MIT-MC  Thu Sep 17 00:00:00 1981
From: DEFBOB at MIT-MC (DEFBOB at MIT-MC)
Date: 17 Sep 1981 00:00
Subject: No subject
Message-ID: <mailman.515.1479821112.4695.its@nocrew.org>


From DCP at MIT-MC  Tue Sep 15 00:00:00 1981
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 15 Sep 1981 00:00
Subject: CNSGET symbolic system call extension
Message-ID: <mailman.516.1479821112.4695.its@nocrew.org>

Now that there are a few places that use SUPDUP Graphics, might
it be the right thing to include the SMARTS (or TTYSMT) variable
in the CNSGET and CNSSET symbolic system calls. It is much easier
to do
	(syscall 7 'cnsget tyo)
and get all the necessary info than to do
	(syscall 1 'ttyvar tyo (car (pnget 'TTYSMT 6)))
to recover the SMARTS variable.


From GJC at MIT-MC  Sun Sep 13 00:00:00 1981
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 13 Sep 1981 00:00
Subject: No subject
Message-ID: <mailman.517.1479821112.4695.its@nocrew.org>

For something really impressive, try :XFILE out of an archive!
Incredibly SLOW, even on MC with fair-share=50%
Almost as impressive is running LMODEM out of an archive.


From BARKANatMIT-AI  Tue Sep  8 00:00:00 1981
From: BARKANatMIT-AI (Jeremy Barkan)
Date: 8 September 1981, 00:00
Subject: No subject
Message-ID: <mailman.518.1479821112.4695.its@nocrew.org>


When using :dover, the its can't differeniate between the underscore
in file name and underscore that is the antecedent in the font name
specifier. Does it not quote underscore