From GJC at MIT-MC  Mon Oct 31 02:35:00 1983
From: GJC at MIT-MC (George J. Carrette)
Date: October 30 1983 21:35 EDT
Subject: No subject
Message-ID: <mailman.1287.1479821131.4695.its@nocrew.org>

:FIND SYSENG;HOSTS
HOSTS 666 written by CSR, beware.

From MOON at MIT-MC  Mon Oct 31 02:18:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: October 30 1983 21:18 EDT
Subject: That ITS out-of-low-core bug
Message-ID: <mailman.1288.1479821131.4695.its@nocrew.org>

Fixed in the source.  I will come over probably some time this
week and find the subtle bugs I no doubt introduced into the system;
I wouldn't recommend trying to install the changes I made without me.
Happy Hallowe'en.

From KMP at MIT-MC  Sun Oct 30 23:59:00 1983
From: KMP at MIT-MC (Kent M. Pitman)
Date: October 30 1983 18:59 EDT
Subject: ITS wedgeding
In-Reply-To: Msg of 29 Oct 1983  15:59-EDT from MOON at SCRC-TENEX
Message-ID: <mailman.1289.1479821131.4695.its@nocrew.org>

    Date: Saturday, 29 October 1983  15:59-EDT
    From: MOON at SCRC-TENEX

    ... Lack of low core could not affect echoing on local terminals, and would
    only affect echoing on network terminals if there wasn't enough core to
    make network packet buffers.  Of course maybe the users were confused
    and what they really meant was that their programs were busted.

I was on just before it died. Echo time might not be the right phrase.
The slowness was of the following sort... I typed :SRCCOM ...<return>
and waited a long time but gotten no output. Echo time for that time was 
normal. I finally typed ^G and V. The V did not echo. I typed some
^G's and maybe some other frustration chars (^D?) after a while and and 
found myself in a mode where I felt like what might be happening was that
for every character I typed, a character would echo but it was out of
phase by several characters with my input. The output from the V, by the
way, indicated that the SRCCOM job had not loaded. Finally, though, 
no more input of any sort would echo, so I gave up and closed my connection.
-kmp

From CSTACY at MIT-MC  Sun Oct 30 14:20:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 30 1983 09:20 EDT
Subject: RAT;
In-Reply-To: Msg of 30 Oct 1983 09:16 EDT from Jeffrey P. Golden <JPG>
Message-ID: <mailman.1290.1479821131.4695.its@nocrew.org>


No, this is all long before a HACTRN has been created.

From JPG at MIT-MC  Sun Oct 30 14:16:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: October 30 1983 09:16 EDT
Subject: RAT;
Message-ID: <mailman.1291.1479821131.4695.its@nocrew.org>

   Date: Saturday, 29 October 1983  16:02-EDT
   From: MOON at SCRC-TENEX
   To:   Christopher C. Stacy <CStacy at MIT-MC>
   Cc:   BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
         KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC
   Subject: ITS wedgeding
   In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
   
   Oh by the way, I forgot to mention about the job that had two disk
   channels open, where one was to "RAT;".  The mode printed by Peek C
   mode for that channel was "RU", meaning that it was reading a
   directory ("UFD").  Probably this channel really belonged to some
   other job and peek was confused.
Is the question: Why RAT; ?
If so, isn't PWORD the answer?

From JPG at MIT-MC  Sun Oct 30 14:08:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: October 30 1983 09:08 EDT
Subject: MC:BACKUP;
Message-ID: <mailman.1292.1479821132.4695.its@nocrew.org>

   Date: Saturday, 29 October 1983, 22:54-EDT
   From: David A. Moon <Moon at SCRC-TENEX>
   To: Jeffrey P. Golden <JPG at MIT-MC>
   Cc: GSB at MIT-MC, BUG-ITS at MIT-MC
   The idea is to have a system there that works well enough that you
   can bring it up and run DUMP to load backup tapes.  It doesn't have
   to support networks, terminals, etc.
I agree with the idea.  But if it is to work:
[1] There should be a -READ- -THIS- file there which lists the key 
files that should be present on the BACKUP; direc.
[2] Someone should look over that directory and delete useless or 
harmful files and replace them by the necessary files so that the idea 
Dave mentions can be carried out if it should ever be necessary.

From Moon at SCRC-TENEX  Sat Oct 29 00:00:00 1983
From: Moon at SCRC-TENEX (David A. Moon)
Date: Saturday, 29 October 1983, 00:00
Subject: No subject
In-Reply-To: The message of 14 Oct 83 04:46-EDT from Jeffrey P. Golden <JPG at MIT-MC>
Message-ID: <mailman.1293.1479821132.4695.its@nocrew.org>

    Date: 14 October 1983 04:46 EDT
    From: Jeffrey P. Golden <JPG @ MIT-MC>
       GSB at MIT-MC 10/13/83 17:44:25 Re: MC directory slot
Subject: MC directory slot
       BACKUP; is for backup copies of things on .; and occasionally other things.
    Why can't .; itself be used for this?  For the couple of true backup @ files, 
    which have the same names as files on .; , e.g. CRASH; would work fine.
    Or better, SYS; ?

       It should be preserved, and it does get updated occasionally.
    The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe 
    almost everything there is garbage.  If BACKUP; were trully for backup 
    then leaving non-working stuff on that directory as is now the case 
    may be hazardous for MC's health if ever invoked.

       I believe that it has proven itself useful on ML at least.
    I see no recent proof of this for MC:BACKUP; .

The idea is to have a system there that works well enough that you
can bring it up and run DUMP to load backup tapes.  It doesn't have
to support networks, terminals, etc.

From ALAN at MIT-MC  Sat Oct 29 06:13:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: October 29 1983 01:13 EDT
Subject: No subject
Message-ID: <mailman.1296.1479821132.4695.its@nocrew.org>

Perhaps someone could write a demon that ran at system startup time that
would look for files whose authors were set to non-existent directories and
set them to be unknown.  That way we would avoid recycled directories
claiming that they authored files that were written by people now gone.

I think about this now because I just noticed that MC:SYS1;TS STINK was
authored by the newly created directory VASL...

From CStacyatMIT-MC  Sat Oct 29 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Saturday, 29 October 1983, 00:00
Subject: ITS wedgeding
Message-ID: <mailman.1297.1479821132.4695.its@nocrew.org>

   TAFT at MIT-MC 10/28/83 14:31:11 Re:  Crash of 10/28 14:27
Subject:  Crash of 10/28 14:27
   MC was catatonic, but running.  Though jobs could be logged in, no
   response to anything other than ^G could be obtained.  I checked
   around that this was really the case and then stopped it.


MC was also merrily printing lots of my little "Warning: <out of this
or that>" messages every chance it got.

In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24,
IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC:

There is definitely something weird going on here.
Of the 50 disk channels, none are free.  
There is no more free low core (for making file or network buffers.)

There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot.
They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP,
respectively. They all have read 0% of their file.

  We can look at a representative wedged server job: user idx 101.
___101 TCP, is blocked inside a LOAD call:  NLOADD+6/ SKIPG QSFBS(A)  A/ 40
I don't entirely grok this disk code yet, but from the channel state
(%QALBK) and mode (READ/USER DATA), and the comment where he blocks,
it looks like he is waiting for the file channel to receive a buffer
with the first page of the TCPSER file.

Also, there may also be something weird file-wise with this particular job.
Unlike the others, I think it has two (QUSR idx) channels:  17 and 40.
According to PEEK, he is also opened RAT; (no file name), which I
guess accounts for channel 17.   But, huh? What? Why?

  Now, the TCP situation shows that there can be up to 180. packet
buffers, of which zero are free out of a total zero allocated.

I checked in XBUSER and friends.
There is only one TCP frob around, and he's not doing a whole lot:
TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL.  
Has received FIN for input, State is "Last ACK".
User channel state:  (input) Foreign host RESET, retransmit timeout (output).
The close reason is:  Closed by user, Closed by foreign host.

This is (I think) reasonable, but does not account for all those other TCP servers!


1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY 
   NETWORK CONNECTIONS?  Is it that the connections went away 
   before the jobs had a chance to get started, or what?
   What are all these jobs for, anyway?

2. WHERE DID ALL THE LOW CORE GO?  
   This seems to be the reason those server jobs can't get going.

3. I heard that typein was echoing very slowly for users during this
   wedged period.  I wonder if this was true, it was it true for local
   consoles as well as STYs?  I don't really understand why this should
   be, in either case.  When the system is running out of core, I have
   usually been able to do SYS$J (provided there was a channel for me
   to .OPEN on USR:) and look around.


Does anybody recognize these symptoms?  
(I have never tried to debug an ITS when it had not crashed at some
definite place; I am relatively new at all this.)
I have not yet looked to try to find what all the core is allocated
to.  I'll do that next sitting.  I'd like people's thoughts on whether
they think this is a bug, or what.  I vaugely remember KLH saying
something about this; maybe he has some idea what is going on.

Chris


From KFL at MIT-MC  Thu Oct 27 05:54:00 1983
From: KFL at MIT-MC (Keith F. Lynch)
Date: October 26 1983 23:54 EST
Subject: Uptime
Message-ID: <mailman.1298.1479821132.4695.its@nocrew.org>

  MC is claiming to have been up for 334 days.
								...Keith

From CSTACY at MIT-MC  Tue Oct 25 17:14:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 25 1983 12:14 EDT
Subject: ZUSER crash of 10/25/83
Message-ID: <mailman.1299.1479821132.4695.its@nocrew.org>

In crashed ITS 1353, CRASH;ITS LZUSUE, on MIT-MC:

The system crashed because it was trying to finish logging out
___071, who had a current inferior job with one page still in core.
It was a NAME (jname "F"), and it looks like it had just started
loading - it had an open file channel which had read 0 wds in.

Another weird thing is that his USYSN1 was 'SUPDUP', not the same as
his reasonable USYSNM.

That's about as far as I think I am going go with this: this info
might be useful if a similar thing ever happens again.  I wonder
if it could be some kind of timing screw.

From GJC at MIT-MC  Sat Oct 22 22:14:00 1983
From: GJC at MIT-MC (George J. Carrette)
Date: October 22 1983 17:14 EDT
Subject: No subject
Message-ID: <mailman.1300.1479821132.4695.its@nocrew.org>

this isn't an its bug, just something I have noticed about TCP,
both on XX and MC. Well, I can never seem to get more than about
7kbps transfer rate now, and usually get only about 3 or 4kbps
on FTP. The net used to be much faster under NCP. The price
of progress?

From KMP at MIT-MC  Fri Oct 21 20:18:00 1983
From: KMP at MIT-MC (Kent M. Pitman)
Date: October 21 1983 15:18 EDT
Subject: No subject
Message-ID: <mailman.1301.1479821132.4695.its@nocrew.org>

ITS crashed at 2:30. It was a BUGHALT, BUGPC/ 8  CAI LZUSUE R2+12
					$Q-1/ PUSHJ P, BUGNIL
I dumped this to CRASH;LZUSUE and reloaded the system.

From CSTACY at MIT-MC  Mon Oct 17 21:42:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 17 1983 16:42 EDT
Subject: ARPANET<->MILNET
In-Reply-To: Msg of 16 Oct 1983 15:39 EDT from David C. Plummer <DCP>
Message-ID: <mailman.1302.1479821132.4695.its@nocrew.org>

    Date: 16 October 1983 15:39 EDT
    From: David C. Plummer <DCP>
    To:   JSOL
    cc:   BUG-ITS

        Date: 16 October 1983 15:12 EDT
        From: Jon Solomon <JSOL @ MIT-MC>

        I don't know where to send this, but when you telnet from a chaos host
        using either MC's or ML's gateway, it doesn't seem to allow you to
        gateway to hosts which are not on Net-10. This includes LCS hosts,
        MILNET hosts, and BBN-NET hosts for starters.

    This is either a host table lossage (BBNC appears to be
    registered on MILNET), which I doubt, or this is the result of
    the MILNET split, in which case you aren't ALLOWED to telnet from
    ARPANET to MILNET.  Fun, eh?

No, TELNET and FTP are not yet administratively prohibited services
between ARPANET and MILNET.


From CSTACY at MIT-MC  Mon Oct 17 21:38:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 17 1983 16:38 EDT
Subject: TCP server doesnt work off net 10.
In-Reply-To: Msg of 16 Oct 1983 15:12 EDT from Jon Solomon <JSOL>
Message-ID: <mailman.1303.1479821132.4695.its@nocrew.org>


You didn't say what system you were using the TCP server from, or what
makes you think it is not working, and I suspect it might be on the
other end. I am not near a Lisp machine to really test this right now,
but when I halfway test it using only MC I can get a TCP connection to
ISIA (a MILNET host.)  I notice the TOPS-20 TELNET program on OZ does
not let you connect to non-ARPANET hosts because its host table claims
not to know about them.  I'll make more test later. 

From MARTY%MIT-OZ at MIT-MC.ARPA  Mon Oct 17 02:40:00 1983
From: MARTY%MIT-OZ at MIT-MC.ARPA (Martin David Connor)
Date: Oct 16 1983  21:40 EDT (Sun)
Subject: bad host table
In-Reply-To: Msg of 16 Oct 1983  20:29-EDT from Jon Solomon <JSOL>
Message-ID: <[MIT-OZ].MARTY.16-Oct-83 21:40:41>

    Date: Sunday, 16 October 1983  20:29-EDT
    From: Jon Solomon <JSOL>
    To:   BUG-SYSTEM, Staff at MIT-EECS

    [EECS people: I don't know who to send this to on EE]

    Your host tables don't have the necessary changes for the MILNET
    split, hence no milnet hosts can be connected to.

Yes, in fact *any* non-arpa internet site will appear unreachable.
So I wrote a little PCL hack.
Basically, our TELNET (chaos gateway version) doesn't know how to
connect to non-internet sites unless you fool it.
So try:

   DECLARE PCL SS:<MARTY.PCL>ITN.PCL.
   ITN <your favorite internet/milnet site>

It would be nice if we could change TELNET to forget about HOSTS2.BIN
which is what it is using, and why we are losing.
This will all be less important when we are directly connected to the
Arpanet.  

From JSOL%MIT-OZ at MIT-MC.ARPA  Mon Oct 17 01:27:00 1983
From: JSOL%MIT-OZ at MIT-MC.ARPA (Jon Solomon)
Date: Oct 16 1983  20:27 EDT
Subject: No subject
In-Reply-To: Msg of 16 Oct 1983  20:00-EDT from David C. Plummer <DCP at MIT-MC>
Message-ID: <[MIT-OZ].JSOL.16-Oct-83 20:27:58>

I see, you're right. why didn't I think to check and see what was
actually being fed to MC! Now I know who to send my gripe to.

From DCP at MIT-MC  Mon Oct 17 01:00:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: October 16 1983 20:00 EDT
Subject: No subject
Message-ID: <mailman.1304.1479821132.4695.its@nocrew.org>

    Date: Sun, 16 Oct 1983  16:21 EDT
    From: Jon Solomon <JSOL%MIT-OZ at MIT-MC.ARPA>

    Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can
    telnet to them directly but OZ can't. Similarly you can telnet from
    ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage
    is in the gateway program.

Works for me.  From MC:
	:CHTN MC<alt>TCP BBNC 27
connects me to BBNC.

From JSOL%MIT-OZ at MIT-MC.ARPA  Sun Oct 16 21:21:00 1983
From: JSOL%MIT-OZ at MIT-MC.ARPA (Jon Solomon)
Date: Oct 16 1983  16:21 EDT
Subject: No subject
In-Reply-To: Msg of 16 Oct 1983  15:39-EDT from David C. Plummer <DCP at MIT-MC>
Message-ID: <[MIT-OZ].JSOL.16-Oct-83 16:21:59>

Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can
telnet to them directly but OZ can't. Similarly you can telnet from
ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage
is in the gateway program.

From DCP at MIT-MC  Sun Oct 16 20:39:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: October 16 1983 15:39 EDT
Subject: No subject
Message-ID: <mailman.1305.1479821132.4695.its@nocrew.org>

    Date: 16 October 1983 15:12 EDT
    From: Jon Solomon <JSOL @ MIT-MC>

    I don't know where to send this, but when you telnet from a chaos host
    using either MC's or ML's gateway, it doesn't seem to allow you to
    gateway to hosts which are not on Net-10. This includes LCS hosts,
    MILNET hosts, and BBN-NET hosts for starters.

This is either a host table lossage (BBNC appears to be
registered on MILNET), which I doubt, or this is the result of
the MILNET split, in which case you aren't ALLOWED to telnet from
ARPANET to MILNET.  Fun, eh?

From JSOL at MIT-MC  Sun Oct 16 20:12:00 1983
From: JSOL at MIT-MC (Jon Solomon)
Date: October 16 1983 15:12 EDT
Subject: No subject
Message-ID: <mailman.1306.1479821132.4695.its@nocrew.org>

I don't know where to send this, but when you telnet from a chaos host
using either MC's or ML's gateway, it doesn't seem to allow you to
gateway to hosts which are not on Net-10. This includes LCS hosts,
MILNET hosts, and BBN-NET hosts for starters.

--JSol

From JPG at MIT-MC  Fri Oct 14 09:46:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: October 14 1983 04:46 EDT
Subject: No subject
Message-ID: <mailman.1307.1479821132.4695.its@nocrew.org>

   GSB at MIT-MC 10/13/83 17:44:25 Re: MC directory slot
Subject: MC directory slot
   To: JPG at MIT-MC
   CC: (BUG ITS) at MIT-MC
   BACKUP; is for backup copies of things on .; and occasionally other things.
Why can't .; itself be used for this?  For the couple of true backup @ files, 
which have the same names as files on .; , e.g. CRASH; would work fine.
Or better, SYS; ?

   It should be preserved, and it does get updated occasionally.
The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe 
almost everything there is garbage.  If BACKUP; were trully for backup 
then leaving non-working stuff on that directory as is now the case 
may be hazardous for MC's health if ever invoked.

   I believe that it has proven itself useful on ML at least.
I see no recent proof of this for MC:BACKUP; .

From GSB at MIT-MC  Thu Oct 13 22:44:00 1983
From: GSB at MIT-MC (Glenn S. Burke)
Date: October 13 1983 17:44 EDT
Subject: MC directory slot
Message-ID: <mailman.1308.1479821132.4695.its@nocrew.org>

BACKUP; is for backup copies of things on .; and occasionally other things.
It should be preserved, and it does get updated occasionally.  I believe
that it has proven itself useful on ML at least.

From JPG at MIT-MC  Thu Oct 13 21:35:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: October 13 1983 16:35 EDT
Subject: MC directory slot
Message-ID: <mailman.1309.1479821132.4695.its@nocrew.org>

Are all of you familiar with the MC:BACKUP; directory?  I wonder how useful 
that directory is, or has its function been largely usurped by MC:.; et al?

From CSTACY at MIT-MC  Thu Oct 13 08:57:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 13 1983 03:57 EDT
Subject: No subject
Message-ID: <mailman.1310.1479821132.4695.its@nocrew.org>

I made the MLDEV/MLSLV use HOSTS3, and also fixed a minor bug
where MLDEV was comparing 36 bit network numbers as CAIN A,NW%ARP.
I bother mentioning the bug fix, because it seems to be everyone's
favorite sleepytime bug for ITS network hacking.


From KLH at MIT-MC  Thu Oct 13 01:29:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: October 12 1983 20:29 EDT
Subject: [ron: ML Routing]
Message-ID: <mailman.1311.1479821132.4695.its@nocrew.org>

I doubt there is a real problem.  ML was probably down at the
time he tried, or the MILNET split cnfused things, or Ron was
confused.  MC and ML have the same "routing" code.

From MARTY%MIT-OZ at MIT-ML.ARPA  Wed Oct 12 20:23:00 1983
From: MARTY%MIT-OZ at MIT-ML.ARPA (Martin David Connor)
Date: Oct 12 1983  15:23 EDT (Wed)
Subject: [ron: ML Routing]
Message-ID: <[MIT-OZ].MARTY.12-Oct-83 15:23:24>


Does anyone understand why this is happening 

Date: October 12 1983  14:58-EDT
From: Ron Natalie <ron at brl-vgr>
To:   bug-tcp
Re:   ML Routing

I can talk to MIT-MC from our local nets but not MIT-ML.

The nets in question are:
	BRLNET	128.20
	BRLNET1	192.5.21
	BRLNET2 192.5.22
they should be routed to your MILNET/ARPANET gateway.

-Ron

From CSTACY at MIT-MC  Wed Oct 12 06:48:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 12 1983 01:48 EDT
Subject: normal host tables!
Message-ID: <mailman.1312.1479821132.4695.its@nocrew.org>

I snarfed the latest host table from the NIC, and
installed it on ITS.

From CSTACY at MIT-MC  Wed Oct 12 06:37:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 12 1983 01:37 EDT
Subject: new host table
Message-ID: <mailman.1313.1479821132.4695.its@nocrew.org>


The latest NIC:<NETINFO>SPLIT-HOSTS.TXT file, dated 11 October 83, has
MIT-MC back on the ARPAnet ("HOST : 10.3.0.44 : MIT-MC,MC :").
I think this means things have finally been set aright.


From CSTACY at MIT-MC  Sat Oct  8 10:28:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 8 1983 05:28 EDT
Subject: source write lock removed
Message-ID: <mailman.1314.1479821132.4695.its@nocrew.org>



From CSTACY at MIT-MC  Sat Oct  8 01:34:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 7 1983 20:34 EDT
Subject: No subject
Message-ID: <mailman.1315.1479821132.4695.its@nocrew.org>


I JFCLd out the only-ARPANET patch I made a little while ago
in the running system on MC.  For one thing, no hosts know
we are here on the ARPAnet, so we arent likely to get much
unwanted traffic except from TAC users.

From CSTACY at MIT-MC  Sat Oct  8 00:05:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 7 1983 19:05 EDT
Subject: No subject
Message-ID: <mailman.1316.1479821132.4695.its@nocrew.org>


At this moment, MC has the split host table which has itself on
net 10.  I just typed in a patch to make it refuse to connect
to/from nets other than the ARPANET, though, to prevent lots
of MILNET packets from being generated by unauthorized users.
This isn't optimal; I'll frob it some more later tonite.

From CStacyatMIT-MC  Fri Oct  7 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Friday, 7 October 1983, 00:00
Subject: INQUIR
Message-ID: <mailman.1317.1479821132.4695.its@nocrew.org>


I changed over all the INQUIR groups tonite, and installed new INQUIR
and LSRPRT versions.  I put up a messsage urging people to check to
make sure their entry looks right.  I used an editied version of
ELLEN;PLASMA to find the PFC people, who have a new special group.

I tried to make it preserve directory assignments, but it may have
slightly confused people who are in the USERSi dirs on ML, since I
forgot to make then specify the machine.  I don't expect this to be a
problem in most cases though.

Chris

From Ian at MIT-OZ  Thu Oct  6 13:13:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: Oct 6 1983  08:13 EDT (Thu)
Subject: No subject
Message-ID: <[MIT-OZ].IAN. 6-Oct-83 08:13:06>


[PHOTO:  Recording initiated  Thu 6-Oct-83 8:11AM]

 TOPS-20 Command Processor 5(742)-2
 [Commands]
!f @nic
[SRI-NIC via MIT-MC]
%No response
[SRI-NIC via MIT-ML]
? Internal error - DEVICE NOT ASSIGNABLE TO THIS PROCESSOR

%No path to site
!pop

[PHOTO:  Recording terminated  Thu 6-Oct-83 8:12AM]

From CStacyatMIT-MC  Thu Oct  6 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Thursday, 6 October 1983, 00:00
Subject: inconsistant sources available
Message-ID: <mailman.1318.1479821132.4695.its@nocrew.org>


ITS is being hacked.  If you arent KLH or myself, don't bother trying
to assemble and run it.


From CSTACY at MIT-ML  Wed Oct  5 07:24:00 1983
From: CSTACY at MIT-ML (Christopher C. Stacy)
Date: October 5 1983 02:24 EDT
Subject: No subject
Message-ID: <mailman.1319.1479821132.4695.its@nocrew.org>

ML has a version of ITS which does routing to the MILNET.
The HOSTS3 bin file there is speciall hacked up.
People should not install ITS host tables until further notice.

MC is off the Internet, since it is connected to MILNET
and it cannot deal with this.  (I consulted KLH about one
of us fixing this, so that MC could be on the MILNET, but
he agrees it is too much dangerous trouble for what should
be a very temporary situation.)

MC and ML can talk to each other over the Chaosnet, of course.

From CSTACY at MIT-MC  Wed Oct  5 04:50:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 4 1983 23:50 EDT
Subject: No subject
Message-ID: <mailman.1320.1479821133.4695.its@nocrew.org>


ML needs a new special host table, and a new ITS version.
I'll take care of this tomorrow.

From CENT at MIT-ML  Tue Oct  4 10:40:00 1983
From: CENT at MIT-ML (Pandora B. Berman)
Date: October 4 1983 05:40 EDT
Subject: Batch processing
Message-ID: <mailman.1321.1479821133.4695.its@nocrew.org>

    Date: 4 Oct 1983  02:32 EDT (Tue)
    From: Ian Macky <Ian at MIT-OZ>
    To:   Alan Bawden <ALAN at MIT-MC>
    Cc:   BUG-ITS at MIT-MC, MAGIC-DRAGON-KEEPER at MIT-MC, Magic-Dragon-Keeper at MIT-ML
    Subject: Batch processing
    In-reply-to: Msg of 4 Oct 1983  02:22-EDT from Alan Bawden <ALAN at MIT-MC>
    In case noone noticed, OZ has been sending Happy Birthday messages
    for months...

oh, we noticed (could hardly miss doing so). but that's only for OZ
users. there are other people in the world..

From Ian at MIT-OZ  Tue Oct  4 07:32:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: Oct 4 1983  02:32 EDT (Tue)
Subject: Batch processing
In-Reply-To: Msg of 4 Oct 1983  02:22-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <[MIT-OZ].IAN. 4-Oct-83 02:32:38>

In case noone noticed, OZ has been sending Happy Birthday messages
for months...

From ALAN at MIT-MC  Tue Oct  4 07:22:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: October 4 1983 02:22 EDT
Subject: Batch processing
Message-ID: <mailman.1322.1479821133.4695.its@nocrew.org>

In the latest version of Puff the Magic Dragon (installed on MC, not ML
yet) I have generalized the feature where once an hour Puff would look for
the files DRAGON;HOURLY RAYGUN and HOURLY TMPKIL and load and run them.
Puff now will load ANY file on DRAGON; whose first file name is HOURLY and
try to load it into a job and run it.  While I was at it I made it check
for files named DAILY, MNTHLY and YEARLY as well.  (They are run at the end
of the day, month and year, when Puff is cleaning his own house.)

I nominate CStacy to write DRAGON;DAILY BTHDAY to replace poor DM's
cheerful birthday greetings.

There seems to have been some misimpression that Puff was ALREADY doing
this.

From CSTACY at MIT-MC  Mon Oct  3 13:10:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 3 1983 08:10 EDT
Subject: No subject
Message-ID: <mailman.1323.1479821133.4695.its@nocrew.org>


What finaly wound up sending out happy birthday announcements on ITS?

From CSTACY at MIT-MC  Sun Oct  2 03:07:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: October 1 1983 22:07 EDT
Subject: No subject
Message-ID: <mailman.1324.1479821133.4695.its@nocrew.org>

Latest ITS (installed on MC) has the MILNET gateway in it
so that forwarding will happen after the split.  I will
install this on ML later tonite or tomorrow.

From KFL at MIT-MC  Sat Oct  1 03:57:00 1983
From: KFL at MIT-MC (Keith F. Lynch)
Date: September 30 1983 22:57 EDT
Subject: No subject
Message-ID: <mailman.1325.1479821133.4695.its@nocrew.org>

  9 users, fair share = 109% ?
								...Keith