From CSTACYatMIT-AI  Tue Nov 30 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 30 November 1982, 00:00
Subject: AI KA Inquire database
Message-ID: <mailman.185.1479821106.4695.its@nocrew.org>

The Inquire database on AI was apparently smashed by a hardware
failure, and has been restored from about a week ago.  If you made
any modifications in the past week or two, you might want to check
to see if they were lost.  You can check by doing :WHOIS you at AI
from an ARPAnet ITS.



From CSTACYatMIT-MC  Sun Nov 28 00:00:00 1982
From: CSTACYatMIT-MC (Christopher C. Stacy)
Date: 28 November 1982, 00:00
Subject: SYSMSG illoping - whats this all about
Message-ID: <mailman.186.1479821106.4695.its@nocrew.org>


It needed to be repurified, which I just did.  I guess I will make it
figure that out itself in the future.

From FJWatMIT-MC  Sat Nov 27 00:00:00 1982
From: FJWatMIT-MC (Frank J. Wancho)
Date: 27 November 1982, 00:00
Subject: ARnn Structure
Message-ID: <mailman.187.1479821106.4695.its@nocrew.org>

The obvious answer to this query below would be to ignore the question
and simply tell him to use the ARnn:CPM;fn1 fn2 construct in FTP.
However, he is the first "outsider" to ask an intelligent question
about the actual structure of ARChive files.  Is there online
documentation or can someone create such info that I can send him?  I
believe such info would be valuable to other sites wishing to FTP an
entire ARChive file and *then* break it into its component files...

--Frank
--------------------

Date: 25 Nov 1982, 00:00
From: Jorge Phillips <JP at SU-AI>
Re:   cpm; directory 

Hi,

I hadn't accessed the CPM; directory at [MC] for a LOOONG time and
just found out that the directory's format has changed completely. I
tried ftp'ng one of the ARnn files (ARnn NSTAR) and found out that it
consists of sections of text and sections of control and non-printing
characters (apparently code, or file structure info). Do I need a
special program to access the contents of these files? Could you give
me some hints of the format and contents of the ARxx files?

Thanks for any help you can give.

-jp

From EDatMIT-MC  Wed Nov 24 00:00:00 1982
From: EDatMIT-MC (Ed Schwalenberg)
Date: 24 November 1982, 00:00
Subject: Great idea for program
Message-ID: <mailman.188.1479821106.4695.its@nocrew.org>

What I wanted is a program that would do the calls in itself, assuming that
this was to be used for simple stuff like my example.  However, it would
be useful to be able to do it in another arbitrary inferior, so I applaud
your proposed extension.

From ALANatMIT-MC  Wed Nov 24 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 24 November 1982, 00:00
Subject: Great idea for program
Message-ID: <mailman.189.1479821106.4695.its@nocrew.org>

One way to write this tool would be to use the SYSCALL function in MacLisp.

Actually there is a problem that a lot of system calls have side effects on
specific jobs.  (Like the :IOPEN kludge opens a channel \in the current
job/.)  What you REALLY want then is a DDT command that does what you said,
but in the current job.  [The idea is to replace the sequence of commands
that usually starts by typing "J<alt>J 100/.CALL 200<tab>" with something
like "J<alt>J :DOCALL" right?]

From DCPatMIT-MC  Wed Nov 24 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 24 November 1982, 00:00
Subject: Great idea for program
Message-ID: <mailman.190.1479821106.4695.its@nocrew.org>

Interesting idea, but I don't think I'd say great.

    (This idea comes from having spent a ridiculous amount of time trying to
    find out the TTYSMT variable of a tty.)

That's easy: SYS^K TTYSMT+<ttynum>/

It's also in CNSGET, and I think it may be in TTYVAR (even though
:CALL doesn'tdocument it).

From edatMIT-MC  Wed Nov 24 00:00:00 1982
From: edatMIT-MC (Ed Schwalenberg)
Date: 24 November 1982, 00:00
Subject: Great idea for program
Message-ID: <mailman.191.1479821106.4695.its@nocrew.org>

:DOCALL prompts for a system call name, prints the relevant documentation
from ITS .CALLS, and prompts the user for the arguments to the call, with
special magical abilities to cons up <TTY>, <JOB>, etc. type args, or open
channels in the fashion of :IOPEN.  It then executes the call, and types
out the values for you, or types out the error code if it failed to work.
(This idea comes from having spent a ridiculous amount of time trying to
find out the TTYSMT variable of a tty.)

From KLHatMIT-MC  Tue Nov 23 00:00:00 1982
From: KLHatMIT-MC (Ken Harrenstien)
Date: 23 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.192.1479821106.4695.its@nocrew.org>

I installed a new KSC;HOSTS2 BIN compiler.  If problems ae experienced
with the current SYSBIN;HOSTS2 >, then use KSC;HOSTS2 OBIN.

From RMSatMIT-OZ  Mon Nov 22 00:00:00 1982
From: RMSatMIT-OZ (Richard M. Stallman)
Date: Monday, 22 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.193.1479821106.4695.its@nocrew.org>

I used to keep the source for any one program on only one machine.
It used to cause continual lossage to have any file in two places.
It's up to the people working on ITS, and maybe you can make it work out,
but don't assume things will work with multiple copies of sources
unless you are very careful.

From KLOTZ  Sun Nov 21 00:00:00 1982
From: KLOTZ (KLOTZ)
Date: 21 Nov 1982, 00:00
Subject: dover
Message-ID: <mailman.194.1479821106.4695.its@nocrew.org>

Maybe there should be a program to hack the dover status
so people don't have to go read .dovr.;%dover broken which
tells them to create a file called .dovr.;.dovr. notice,
which is different from .dovr.;.dovr.;broken, which they
need to create too, but then have to gun the server (if
they can figure out what the user name is)...

ELLEN told me that when the dover goes down people still
queue things on MC and gobble up disk space.  Few people
know how (or take the trouble to) stop the server on MC,
possibly because it's so complicated.

Leigh.
-------



From EDatMIT-MC  Sun Nov 21 00:00:00 1982
From: EDatMIT-MC (Ed Schwalenberg)
Date: 21 November 1982, 00:00
Subject: MASTER mode screwing up TTY handling, but good!
Message-ID: <mailman.195.1479821106.4695.its@nocrew.org>

While I guess I can see that the superior would get no cycles at all,
that still doesn't explain the wedgitude of the STY's.  DCP and I had
fun for hours, trying to figure out how to unscrew things without being
able to log in.  I finally got it unwedged by halting and continuing
AI, but had to walk over to Tech Sq. to do it, which is cheating...

From RWKatSCRC-TENEX  Sat Nov 20 00:00:00 1982
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: 20 Nov 1982, 00:00
Subject: MASTER mode screwing up TTY handling, but good!
In-Reply-To: Your message of 20-Nov-82 1855-EST
Message-ID: <mailman.196.1479821106.4695.its@nocrew.org>

PGS is right.  Other jobs in the same tree receive no CPU time while the
master-mode job is running.  If it waits for I/O or pages, then they may
get a quantum now and then.  I noticed this years ago and learned to be
careful.  Play with antisocial toys, and you'll get your fingers burnt!
-------

From RWKatSCRC-TENEX  Sat Nov 20 00:00:00 1982
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: 20 Nov 1982, 00:00
Subject: Feature
In-Reply-To: Your message of 20-Nov-82 1253-EST
Message-ID: <mailman.198.1479821106.4695.its@nocrew.org>

Sounds like an excellent idea.  Terminal 0 and/or whatever terminal
is the system console should probably be left alone, hardwired, though.

Perhaps this can be done by a demon loaded at startup, which simply
uses a special system call to copy the info?  Perhaps this call should
only work once, and then enable non-system-console terminals, and cause
the ITS IN OPERATION message to be printed when it is done.  This would
prevent clobbering terminals already in use.  Alternatively, it could
be careful and ignore terminals which are in use.  This would minimize
the amount of EXEC code and debugging.
-------

From KLHatMIT-MC  Sat Nov 20 00:00:00 1982
From: KLHatMIT-MC (Ken Harrenstien)
Date: 20 November 1982, 00:00
Subject: Feature
Message-ID: <mailman.199.1479821106.4695.its@nocrew.org>

ITS should probably read a binary parameter file on startup to
initialize its TTY tables rather than having them built in.
This table can be maintained by a simple utility program that
grovels over a source file, like HOSTSn does for HOSTS >.
The network code will need to do something similar in order to
initialize its gateway tables.
If no objections, I may go ahead and do this.

From EDatMIT-MC  Sat Nov 20 00:00:00 1982
From: EDatMIT-MC (Ed Schwalenberg)
Date: 20 November 1982, 00:00
Subject: MASTER mode screwing up TTY handling, but good!
Message-ID: <mailman.200.1479821106.4695.its@nocrew.org>

I should know better than to frivolously show people MASTER mode, but anyway...
Proceeding a job in Master mode without the TTY causes output on that
TTY to be wedged, in that the <crlf>* that DDT echoes after ^P never happens.
Output from comm links continues to work, however.  Now for the real
killer:  if that tree is then detached, the poor sucker who reowns it gets
wedged, just by reowning it (his HACTRN says :$ Reowned $, then nothing more.)
Stealing MASTER mode away, by grabbing it in another process, results in the
wedged jobs continuing as if nothing had happened.

This was all on MC, just now, version 1283.  I tried to do the same thing on
AI, to determine whether it was KL-specific, and discovered to my horror that
not only does the same bug exist, but it apparantly wedges ALL sty's, since
I was unable to log in again to clean up, being told that All network ports were
in use!  (The original hackery was also via a STY, by the way; from the SIPB
plasma tv, to be specific.)

From ASBatMIT-MC  Fri Nov 19 00:00:00 1982
From: ASBatMIT-MC (Richard Brenner)
Date: 19 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.201.1479821106.4695.its@nocrew.org>

When trying to :move a file into an archive that (unknown to me) was
full (no free files), I encountered the error
-CHANNEL NOT OPEN
This message was a little too obscure to be helpful to me, and it took
KLH a few minutes to figure out what was happening.  I clearer error
message would have helped quite a lot.

From KLHatMIT-MC  Wed Nov 17 00:00:00 1982
From: KLHatMIT-MC (Ken Harrenstien)
Date: 17 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.202.1479821106.4695.its@nocrew.org>

    Date: 17 November 1982 21:00-EST
    From: Earl A. Killian <EAK at MIT-MC>

    I thought that sources were only supposedly to exist on one
    machine so that you never get copies out of sync and need to do
    merging.  Thus, if you copied things from AI to MC, you should
    delete them from AI.

Not necessarily, the main thing is to make it clear where the
canonical source actually lives, normally in a comment at the
start of the source file.  I don't think it would be a good
idea to have any machine (esp AI) totally without sources.

From EAKatMIT-MC  Wed Nov 17 00:00:00 1982
From: EAKatMIT-MC (Earl A. Killian)
Date: 17 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.203.1479821106.4695.its@nocrew.org>

I thought that sources were only supposedly to exist on one
machine so that you never get copies out of sync and need to do
merging.  Thus, if you copied things from AI to MC, you should
delete them from AI.

From KLHatMIT-MC  Wed Nov 17 00:00:00 1982
From: KLHatMIT-MC (Ken Harrenstien)
Date: 17 November 1982, 00:00
Subject: Can't get there from here.
Message-ID: <mailman.204.1479821106.4695.its@nocrew.org>

I rebooted the front-end 11 per MOON's instructions about 2 hours ago.
Local terminals were badly wedged, although Chaosnet connections seemd
to be going through okay; it was however complaining periodically that
no more chaosnet buffers were available.  A typical example of wedgedness
is that echo on the VT52 next to the console was at least 20 chars behind
typein, and some typein seemed to be getting lost or at least processed
in random spurts (only when one had pumped enough chars at it would anything
happen).
The rebooting seems to have fixed everything for now.  Moon apparently
thinks that the Dover spooler might have had something to do with
the overall problem, but you'd have to ask him for any details.  Something
was very obviously clobbered in the 11.  Perhaps when the Chaosnet goes
wild, something overflows into the TTY buffers/pointers or otherwise
throws a big wrench into the works?  Pure speculation, I'm not familiar
with it.  It might even be the other way around, that some glitch in
TTY handling (owing to the preponderance of "loose lines" blasting noise
at the front-end) is screwing up not only the TTYs but the Chaosnet.

From DCPatSCRC-TENEX  Wed Nov 17 00:00:00 1982
From: DCPatSCRC-TENEX (David C. Plummer)
Date: Wednesday, 17 November 1982, 00:00
Subject: Can't get there from here.
Message-ID: <mailman.205.1479821107.4695.its@nocrew.org>

I had a chaos connection to MC die on me tonight.  (RP has complained
that he gets about two per day.)  When it happened to me I did some
quick poking and the MC-IO-11 was not responding to STATUS but other
hosts on subnet one were.  MC is now up (and has been for 14 hours) so
it looks like the 11 crapped.  A couple nights ago TAFT called me for
instructions on how to reload the 11.  Is this flaking out becoming
regular?  Does the person(s) reloading it remember anything special
about the circumstances (11 halted or running, ampex parity, dl10
parity, etc).

From CStacyatMIT-MC  Sat Nov 13 00:00:00 1982
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: 13 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.206.1479821107.4695.its@nocrew.org>

PEEK automagically purifies and dumps out itself if necessary now.



From EDatMIT-MC  Sat Nov 13 00:00:00 1982
From: EDatMIT-MC (Ed Schwalenberg)
Date: 13 November 1982, 00:00
Subject: T21 as well...
Message-ID: <mailman.207.1479821107.4695.its@nocrew.org>

has been silenced.


From EDatMIT-MC  Sat Nov 13 00:00:00 1982
From: EDatMIT-MC (Ed Schwalenberg)
Date: 13 November 1982, 00:00
Subject: MC T32 emitting continuous garbage.
Message-ID: <mailman.208.1479821107.4695.its@nocrew.org>

I set the linespeed to 0 to disable T32, which was typing garbage at the
system.  Is there any documentation for LSPEED?  I went blithely ahead
and assumed that it worked like a reasonable program, but it would be
nice to know.  It would be similarly nice if the same programs worked for
all known TTY types, but this is rapidly becoming a dead issue.


From CStacyatMIT-MC  Sat Nov 13 00:00:00 1982
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: 13 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.209.1479821107.4695.its@nocrew.org>

There were a number of program sources which did not exist or
were out of date on MC.  I brought them up to date from the ones
on AI, putting the overflow in the new SYSEN2; directory.  MC
should now be reagrded as the home of the most recent system
program sources.

I moved the BUG-ITS mailing list to MC, and updated pointers to
it on AI, ML, and DM.  The other bug-random-programs are still
on AI.  A copy of the AI NAMES file is in MC:KSC;AI NAMES.

Chris

From KLH at MIT-MC  Sat Nov 13 00:00:00 1982
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 13 Nov 1982 00:00
Subject: another SRCCOM feature
Message-ID: <mailman.210.1479821107.4695.its@nocrew.org>

I hope this isn't bothering BUG-ITS people, but since I developed
this feature to help hack ITS I figure I might as well continue
with the SRCCOM announcements.  I added the /$ switch which
does a binary compare like /# but with the difference that the
files must be executable programs; SRCCOM will create two
inferior processes and load the files into them in order to compare
the two address spaces.  This completely flushes any spurious
diffs due to symbols, MIDAS info, blocking size, or SBLK/PDUMP
format.  Doesn't handle holey processes though; maybe later.

I updated INFO;SRCCOM > on MC.  I'm going to move the canonical
location of SRCCOM to MC, I think.


From CStacyatMIT-MC  Fri Nov 12 00:00:00 1982
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: 12 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.211.1479821107.4695.its@nocrew.org>

I am adding some features to PEEK which will be useful for
TCP/IP debugging.  I added the trivial "+" mode today, sort of
as practice.  Installed on MC.


From KLH at MIT-MC  Fri Nov 12 00:00:00 1982
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 12 Nov 1982 00:00
Subject: Binary compare feature
Message-ID: <mailman.212.1479821107.4695.its@nocrew.org>

I have installed a new SRCCOM on MC with a crude binary compare
feature.  Use switcch /# to compare two files word by word.
Interaction with other switches is likely to kill things.
If nobody (mostly me, I guess) finds problems with it over the
next few days, I'll install it in other places.
Note that two different assemblies of the same sources will not
produce identical binaries, because of the extra info that MIDAS
puts in about who assembled it when.  I'm not sure yet how to
bypass this.


From CSTACYatMIT-MC  Thu Nov 11 00:00:00 1982
From: CSTACYatMIT-MC (Christopher C. Stacy)
Date: 11 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.213.1479821107.4695.its@nocrew.org>


I made a mailing list for discussing some of the random ideas inspired
by DCP's message about ITS on a VAX.  It doesnt have to be just about
VAX ITS, but it prevents message duplication and gets it off BUG-ITS.
Here's what the mailing list looks like now:

(VAX-ITS (EQV-LIST (FILE [DSK:CSTACY;VAXITS ARCHIV])
			 CSTACY DCP PGS ALAN KMP GUMBY DANNY KLH KLOTZ
			 HAL GREGOR CENT ZVONA RMS DEVON))


Feel free to add yourself...

Chris


From DCPatMIT-MC  Thu Nov 11 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 11 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.214.1479821107.4695.its@nocrew.org>

[[Sorry for the message duplications...]]

    KMP at MIT-MC 11/11/82 17:46:24
    better than teach ITS, you should get a crew together and bring one up.

Unfortuantely that would require the cooperation of the owner(s)
of a machine up on which (garp) to bring it.  Here are the
options I know of:

There are rumors of the AI lab looking for a used -10 (KL
probably) to appease the people who can't stand 20X and would
prefer ITS.  This would be an idea machine.

Bring up ITS on an existing PDP-20.  The only machine this is
feasible on is OZ, and the feasibility of that seems to be
asymptotically approaching zero (unless you want to pull of a
coop some night).  This would also require some microcode
expertise.  Moon obviously comes to mind.  His commitment at
symbolics also comes to mind.

Bring it up on a non-10 architecture.  This would be a lot of
fun.  The obvious choice is a vax.  OK, who has the vax, who has
the time, and who has the money to sponser such a moderate
project?  (Be prepared to be able to answer "What's wrong with
Unix?"  I'm sure each one of us can give some very good answers,
but just be prepared.)

TK actually suggested writing a report on ITS which described its
winnages (.HANG for example) and its lossages (6 character,
non-hierarchical filenames).

From KLH at MIT-MC  Thu Nov 11 00:00:00 1982
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 11 Nov 1982 00:00
Subject: Comsat address & NAMES >
Message-ID: <mailman.215.1479821107.4695.its@nocrew.org>

If I have some spare time during this TCP hacking, I can look into
this.  The problem is not really that NAMES is so big, but that COMSAT
is so stupid about how it handles the compiled result.  There are at
least three things I can think of right away that would help eliminate
this problem (this does not mean they are easy to do).  For the time
being, keeping NAMES small ought to buy enough time.


From JPG at MIT-MC  Thu Nov 11 00:00:00 1982
From: JPG at MIT-MC (JPG at MIT-MC)
Date: 11 Nov 1982 00:00
Subject: Comsat address & NAMES >
Message-ID: <mailman.216.1479821107.4695.its@nocrew.org>

I have no objection to this, but I wish to point out that at least recently 
people have been cleaning out the NAMES file to the point where it is now 
just(?) 19 blocks, and COMSAT has been crashing much less frequently. 
Ah, but will this state last?


From KLH at MIT-MC  Wed Nov 10 00:00:00 1982
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 10 Nov 1982 00:00
Subject: prev msg
Message-ID: <mailman.217.1479821107.4695.its@nocrew.org>

Hmm, there is no longer a MIT-NET-CONNECT list.  I forwarded the
note to MIT-IN-GROUP and MIT-NETWORK-GROUP instead.  Just in case
anyone tries to reply to all recipients...


From KLH at MIT-MC  Wed Nov 10 00:00:00 1982
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 10 Nov 1982 00:00
Subject: ITS TCP is coming...
Message-ID: <mailman.218.1479821107.4695.its@nocrew.org>

I am now officially working on the installation of TCP/IP in ITS.
The ITS sources in MC:SYSTEM; should be considered write-locked
as of today; if you need to make some changes, see me to fold them
in.  Likewise, if you know that these sources are for some reason
NOT the latest stuff, tell me immediately.  Ditto any patches
that haven't yet been put in the source.  If more than a couple of
people are interested in following the progress of this stuff, I
will create a mailing list to keep them posted and possibly to
solicit opinions on certain design issues.
Here we go, folks!


From DCPatMIT-MC  Tue Nov  9 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 9 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.219.1479821107.4695.its@nocrew.org>

    Date: 9 November 1982 17:40-EST
    From: Christopher C. Stacy <CSTACY at MIT-MC>



    The system ran out of ARPAnet sockets (I think) and would not accept
    incoming TELNET connections. Other sites seemed to think MC had died.
    I looked, and there were about a dozen 054Jnn NETRFC jobs hung in
    CLFSH->XX/RDCLS<-XX. They were all doing a FINISH call at 12527.  I
    gunned most of them down.  I dont know what this frob is for, but ALAN
    looked at the job and thinks it some sort of BOJ handler for something
    to do with the DOVER, like RFC133.

    What was this job, and I wonder why there were all these hung ones?

Yes.  These are wedged XX jobs.  When I frequented MC I would
typically find several in one day.  Either ITS has a bug closing
connections, or XX has the bug (perhaps both).  I don't know NCP
so I don't know if the above state is reasonable.

From CSTACYatMIT-MC  Tue Nov  9 00:00:00 1982
From: CSTACYatMIT-MC (Christopher C. Stacy)
Date: 9 November 1982, 00:00
Subject: No subject
Message-ID: <mailman.220.1479821107.4695.its@nocrew.org>



The system ran out of ARPAnet sockets (I think) and would not accept
incoming TELNET connections. Other sites seemed to think MC had died.
I looked, and there were about a dozen 054Jnn NETRFC jobs hung in
CLFSH->XX/RDCLS<-XX. They were all doing a FINISH call at 12527.  I
gunned most of them down.  I dont know what this frob is for, but ALAN
looked at the job and thinks it some sort of BOJ handler for something
to do with the DOVER, like RFC133.

What was this job, and I wonder why there were all these hung ones?

From CBF at MIT-MC  Sun Nov  7 00:00:00 1982
From: CBF at MIT-MC (CBF at MIT-MC)
Date: 07 Nov 1982 00:00
Subject: Comsat address & NAMES >
Message-ID: <mailman.221.1479821107.4695.its@nocrew.org>

It seems that the only solution to the address space problem that avoids
removing mailing lists right and left is to move the bulk of their
contents into separate files and put entries in that are only (@FILE ...).
I presume an @FILE takes up much less space than several name in a mailing
list.

Anyway, the problem with just going through NAMES > and arbitrarily
moving mailing lists into files is figuring out where to scatter all these
lists to.  They presumably each do have individual sponsers, but it is
quite an effort to encourage each person to remove a mailing list to his own
directory.  Considering what a bad idea it is to have COMSAT crashing all
the time, I would therefore suggest that a precious MFD slot be given over
to this purpose.  The names LISTS seems approriate, and it can store lists
and collect log files for otherwise homeless mailing lists.  This would
also provide a nice central place to look at when some disk storage is
needed (ie. by trimming old log files), which could actually result in
less disk storage being used by log files.

I'm not volunteering to do this quite yet, but if I don't hear any
objections I may create the dir and  start to do this at idle moments when
I'm bored.


From CSTACY at MIT-MC  Thu Nov  4 00:00:00 1982
From: CSTACY at MIT-MC (CSTACY at MIT-MC)
Date: 04 Nov 1982 00:00
Subject: No subject
Message-ID: <mailman.222.1479821107.4695.its@nocrew.org>

The pile-driving every few minutes at all hours  outside
Tech Square is apparently the cause of a very gross number
of T-300 failures and problems on the CADRs.  It seems to
be shaking them to death, crashing heads and doing other bad
things.

I noticed that there were quite a few disk errors happenning
on MC tonite. Is it likely that any of these are being caused
by the vibrations from outside?


From KLH at MIT-MC  Wed Nov  3 00:00:00 1982
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 03 Nov 1982 00:00
Subject: No subject
Message-ID: <mailman.223.1479821107.4695.its@nocrew.org>

I think AI holds the record, something like 80 days.  The max uptime
is stored in the creation date of SYS:RECORD TIME on each machine,
starting from 0/0/00.


From PGS at MIT-ML  Wed Nov  3 00:00:00 1982
From: PGS at MIT-ML (PGS at MIT-ML)
Date: 03 Nov 1982 00:00
Subject: No subject
Message-ID: <mailman.224.1479821107.4695.its@nocrew.org>

ML ITS 1278 has been running for 33 days now.  Is this a record?
(It certainly is on ML).


From MP at MIT-MC  Tue Nov  2 00:00:00 1982
From: MP at MIT-MC (MP at MIT-MC)
Date: 02 Nov 1982 00:00
Subject: size of MC's mailing list file
Message-ID: <mailman.225.1479821107.4695.its@nocrew.org>

I sent some messages to a few lists that have been dormant for a few
years.  At the very least I hope to cut out some invalid addresses,
and with luck maybe a few lists can be flushed.

There are several lists that don't seem to have a clear maintainer,
(for instance, the chaosnet, bikes, c100-fans, calculators, and
multics-emacs lists); if they were to be moved into some indirect file
in someone's directory, it isn't obvious who that someone should be.
It would be nice to have a nice, non-volatile directory (USERS* and
GUEST* I consider volatile) to put assorted indirect files in.