From EAKatMIT-MC  Mon Oct 27 00:00:00 1980
From: EAKatMIT-MC (Earl A. Killian)
Date: 27 October 1980, 00:00
Subject: Temporary files
Message-ID: <mailman.750.1479821118.4695.its@nocrew.org>

Couldn't you also open the file, and then delete it.  When you
close the file, or when it is closed for you by killing the job,
then it will be deleted by the system.


From ___011 at MIT-MC  Sun Oct 26 00:00:00 1980
From: ___011 at MIT-MC (___011 at MIT-MC)
Date: 26 Oct 1980 00:00
Subject: I replied to CSTACY
Message-ID: <mailman.751.1479821118.4695.its@nocrew.org>

[Translating all devices to AI: including USR: and ERR:]


From CSTACY at MIT-MC  Sun Oct 26 00:00:00 1980
From: CSTACY at MIT-MC (CSTACY at MIT-MC)
Date: 26 Oct 1980 00:00
Subject: No subject
Message-ID: <mailman.752.1479821118.4695.its@nocrew.org>

On MC,  do:    $^T foo,ai:foo;
               foo^F FILE.DIR. etc -- CANT READ SYSTEM'S ERROR MESSAGE
               bar^K
               INFERIOR-CREATION FAILED

Chris
------


From MOON at MIT-MC  Fri Oct 24 00:00:00 1980
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 24 Oct 1980 00:00
Subject: Temporary files
Message-ID: <mailman.753.1479821118.4695.its@nocrew.org>

If you read the file .INFO.; ITS LOCKS it will tell you about features
for creating unique IDs and having locks that get unlocked when a job
is killed.  Of course there is no way to run arbitrary code when a job
is killed; that could easily make it impossible to kill.

It's easy to tell whether a given job "points to" a file, if you include
that job's job-number in the name of the file.  You simply have
one file per job-number, recreated when a job starts up.  If you
want to delete "left over" files in some cleanup procedure, simply
check to see if the job has the name of that file in a fixed place
in its memory (or we could allocate a new .OPTION bit or use the
dragon's way of telling whether a job is a Macsyma).


From GJCatMIT-MC  Fri Oct 24 00:00:00 1980
From: GJCatMIT-MC (George J. Carrette)
Date: 24 October 1980, 00:00
Subject: new error message system
Message-ID: <mailman.754.1479821118.4695.its@nocrew.org>


    Date: 24 October 1980 11:36-EDT
    From: Robert W. Kerns <RWK at MIT-MC>
    To:   GJC
    Re:   new error message system

    Files that want to be sure to go away when a process is killed can be written
    to .TEMP.;


I've seen files on the so-called .TEMP. directory end up on
back-up tape! Look, theres one now on MC:.TEMP.;LPH .PLOT.

Each and every macsyma which starts up will probably create
a new file on the .TEMP. directory, and these will have
to be garbage collected better than they are now.
The problem is, how can a clean-up program tell if any existing
macsyma jobs point to one of the files? Well, I guess AGE greater than
8 hours is a reasonable heuristic. Does ITS have any thing which could
give a UNIQUE process ID over the time between crashes?

Is there any provision in ITS for letting a process take an
interrupt when something tries to KILL it? It could then
delete the file(s) and kill itself.



From EFH  Wed Oct 22 00:00:00 1980
From: EFH (Edward F. Hardebeck)
Date: 22 OCT 1980, 00:00
Subject: No subject
Message-ID: <mailman.755.1479821118.4695.its@nocrew.org>

the name dragon got a PURPG
(PURPG;) 1371>>MOVEM 2,(3)    2/   MOVEI 20100(4)   63336/   0
it is dumped on crash;namdrg >

From RWKatMIT-MC  Mon Oct 20 00:00:00 1980
From: RWKatMIT-MC (Robert W. Kerns)
Date: 20 October 1980, 00:00
Subject: FOOO$U doing a :MASSACRE
Message-ID: <mailman.756.1479821118.4695.its@nocrew.org>

    Date: 17 October 1980 02:20-EDT
    From: J. Noel Chiappa <JNC at MIT-AI>
    To:   RWK
    cc:   JNC at MIT-AI
    Re:   FOOO$U doing a :MASSACRE

    	Barf! This has actively wedged me. What's the ratyionale, can it
    be changed, and if not, how do I avoid lossage (other than detaching
    all my jobs?)
    		Noel
The reason is that logging in on ITS is not permitted (by ITS) if a job has
inferiors.  One way to avoid lossage is to log in before doing anything.
Of course, I think a better thing to do would be to allow logging in with
inferior jobs.  Since this is already done when a job is reowned, I wouldn't
think this would be very hard to do...
l

From MOON at MIT-MC  Sun Oct 19 00:00:00 1980
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 19 Oct 1980 00:00
Subject: SPURIOUS CHARACTERS
Message-ID: <mailman.757.1479821118.4695.its@nocrew.org>

    THE DATAPOINT IN LAUREL'S OFFICE (917) SEEMS TO OCCASIONALLY
    SEND SPURIOUS AND UNCALLED-FOR  ^H'S. I HAVE SEEN THIS HAPPEN
    A FEW TIMES AFTER RUNNING :F; THE OUTPUT FROM :F WOULD PRINT
    OUT FOLLOWED BY A ^H AND GOING BACK INTO WHATEVER JOB IS
    CURRENT. I HAVE NOT SEEN THIS BEHAVIOR CONNECTED WITH ANYTHING
    ELSE. I DON'T KNOW WHETHER THIS IS A HARDWARE OR SOFTWARE BUG.
    CAN SOMEONE LOOK INTO IT?
It's a hardware bug, fixable by throwing the datapoint in the trash.
They have really crappy keyboards.

From CENT  Sun Oct 19 00:00:00 1980
From: CENT (Pandora B. Berman)
Date: 19 OCT 1980, 00:00
Subject: SPURIOUS CHARACTERS
Message-ID: <mailman.758.1479821118.4695.its@nocrew.org>

THE DATAPOINT IN LAUREL'S OFFICE (917) SEEMS TO OCCASIONALLY
SEND SPURIOUS AND UNCALLED-FOR  ^H'S. I HAVE SEEN THIS HAPPEN
A FEW TIMES AFTER RUNNING :F; THE OUTPUT FROM :F WOULD PRINT
OUT FOLLOWED BY A ^H AND GOING BACK INTO WHATEVER JOB IS
CURRENT. I HAVE NOT SEEN THIS BEHAVIOR CONNECTED WITH ANYTHING
ELSE. I DON'T KNOW WHETHER THIS IS A HARDWARE OR SOFTWARE BUG.
CAN SOMEONE LOOK INTO IT?

From MOON at MIT-MC  Fri Oct 17 00:00:00 1980
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 17 Oct 1980 00:00
Subject: No subject
Message-ID: <mailman.759.1479821118.4695.its@nocrew.org>

It does XOR the control bits.  Where the documentation says the LH of the
first argument (the channel number) is also XOR'ed in it is lying.  Use
5000,,%tjdis+%tjsio and your program will work (this is an immediate control
bits arg.)

From DCP at MIT-MC  Fri Oct 17 00:00:00 1980
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 17 Oct 1980 00:00
Subject: No subject
Message-ID: <mailman.760.1479821118.4695.its@nocrew.org>

Symbolic IOT is documented to XOR the control bits of the call with the
appropriate channel variable in the system. I am trying to use this
with the TTY to change from %TJDIS mode to %TJSIO mode, and I am losing.
There is a short program in MC:DCP;TEST > which I think should work from 
the specs in the documentation. Why am I losing??


From GSB at MIT-ML  Wed Oct 15 00:00:00 1980
From: GSB at MIT-ML (GSB at MIT-ML)
Date: 15 Oct 1980 00:00
Subject: No subject
Message-ID: <mailman.761.1479821118.4695.its@nocrew.org>

The mailer lost again tonight because the system crashed renaming LISTS MSGS
to LISTS MSGT.  Either comsat should recognize this condition or ITS
shouldn't increment the name unless its necessary.


From GJC at MIT-MC  Sat Oct  4 00:00:00 1980
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 04 Oct 1980 00:00
Subject: No subject
Message-ID: <mailman.762.1479821118.4695.its@nocrew.org>

3-6985 rang but didn't answer, I'm on 3-6986 now
and am experiencing incredible line lossage and garbling,
(am on a VT52 with a 1200 baud vadic), when recieving at
high speed. Probably unrelated, but I thought you at might want
to know.