From MOON at MIT-MC  Sun Oct 31 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 31 Oct 1982 00:00
Subject: No subject
Message-ID: <mailman.226.1479821107.4695.its@nocrew.org>

I need to repeat my message saying that there will be no mail service on MC
if the NAMES file is not made smaller.  It is completely filling Comsat's
address space.

From PGSatMIT-OZ  Tue Oct 26 00:00:00 1982
From: PGSatMIT-OZ (Patrick Sobalvarro)
Date: Tuesday, 26 October 1982, 00:00
Subject: ai down?
Message-ID: <mailman.227.1479821107.4695.its@nocrew.org>

    CENT at MIT-ML 10/26/82 04:47:18 Re: ai down?
Subject: ai down?
    To: (BUG ITS) at MIT-ML
    i tried to supdup from ml to ai, by saying ai^H. after giving me
    the fallacious run-around about using the arpanet twice (because
    i was using ml from a chaos tip), it reported Host Dead. just to
    check, i tried :supdup ai /a. same result.
    however, ai was up durign this time. i was able to use it from
    its console. someone check this please?

AI wasn't down; in fact, it was running perfectly.  At 4:11 yesterday
afternoon, JNC took AI off the Arpanet to screw with the tips or the tacs or
whatever, and, well, he forgot to plug the boards back in.  When I couldn't get
to it this morning, TY said, "Oh, shit, that must have been Chiappa," and
called him up and got him to fix it.  The AI-10 is the AI Lab's only Arpanet
socket, and lots of people indirect through it to get their net mail to OZ.
Lots of important mailing lists are on AI (including BUG-ITS).  AI's Arpa port
is important to this lab, and I wish there were a less casual attitude about
fucking with it.


From SHAWN at MIT-ML  Tue Oct 26 00:00:00 1982
From: SHAWN at MIT-ML (SHAWN at MIT-ML)
Date: 26 Oct 1982 00:00
Subject: ":alarm"
Message-ID: <mailman.228.1479821107.4695.its@nocrew.org>

Does the ":alarm" command REALLY work? it seems it does
the "wrong" thing for me all the time, (i.e. ":alarm .+00:"
works, and it takes it, not only that, but ":alarm .+01:"
sets for ".+17:23:55" when its 06:36:10am?), anyone
care to explain what I am doing wrong? if anything?

		Thanks
		  -shawn


From CENT at MIT-ML  Tue Oct 26 00:00:00 1982
From: CENT at MIT-ML (CENT at MIT-ML)
Date: 26 Oct 1982 00:00
Subject: ai down?
Message-ID: <mailman.229.1479821107.4695.its@nocrew.org>

i tried to supdup from ml to ai, by saying ai^H. after giving me
the fallacious run-around about using the arpanet twice (because
i was using ml from a chaos tip), it reported Host Dead. just to
check, i tried :supdup ai /a. same result.
however, ai was up durign this time. i was able to use it from
its console. someone check this please?

From DCPatMIT-MC  Fri Oct 22 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 22 October 1982, 00:00
Subject: [Forwarded: COMSAT, Re: ]
Message-ID: <mailman.230.1479821107.4695.its@nocrew.org>

Sorry, I can't spel...
                 ------------------------------
Date: 21 Oct 1982 00:00
From: COMSAT at MIT-MC
Subject: Msg of Thursday, 21 October 1982 23:27-EDT
To: DCP at MIT-MC
A copy of your message is being returned, because:
"BUT-ITS" at MIT-MC is an unknown recipient.
	Message not sent.
 Failed message follows:
-------
Date: 21 October 1982, 00:00
From: David C. Plummer <DCP at MIT-MC>
To: BUG-OZ at MIT-MC
cc: BUT-ITS at MIT-MC, MT at MIT-MC, ERIC at MIT-MC

There is a theory that part of the OZ wait-30-seconds problem is
that the AI-Chaos-11 does not always have the power to bridge
between subnets 6 and 1.  If chaos sites think that ai-chaos-11
is the best route, when indeed it cannot route, then there will
be a stalling effect until either ai-chaos-11 unwedges or
mc-io-11 becomes the best route.  This could take 15 to
30 seconds depending on how wedged ai-chaos-11 is.

If this is the problem, then I may have improved the situation.
I have modified the program that runs in ai-chaos-11 to give a
higher cost for the cable subnets than mc-io-11.  This should
cause subnet 6 sites to always use mc-io-11 to get to subnet 1
and vice-versa (except of course when mc-io-11 is down, in which
case the routing mechanism will figure out ai-chaos-11 can get
there).  This will take effect at the next reload of ai-chaos-11
(which happens to be down right now meaning no dover service to
chaos sites).

The correct solution, of course, is to put the oz-network-11 on
subnet 6 as well as subnet 1.  This is not happening due to a
lack of hardware (unibus chaos interfaces).


From DCP at MIT-MC  Thu Oct 21 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 21 Oct 1982 00:00
Subject: No subject
Message-ID: <mailman.231.1479821107.4695.its@nocrew.org>

I modified :HOST so that it now accepts multiple host as
arguments, separated by commas.  E.g.,
	:HOST MC,AI,ML,DM


From MOON at MIT-MC  Tue Oct 19 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 19 Oct 1982 00:00
Subject: No subject
Message-ID: <mailman.232.1479821107.4695.its@nocrew.org>

.;crash chaos is a crash where the system ran out of chaos buffers and
got slow (so I'm told).  All the buffers but one I could find were UNC's from
BAK DOVER to socket 21 (octal) on the Dover Alto.  Perhaps the IO-11 had really
crashed, and that's why it wasn't swallowing the packets.  Perhaps ITS should
notice when the number of packets on DLCXMQ gets large and start throwing them
away.

From JNCatMIT-XX  Mon Oct 18 00:00:00 1982
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 18 Oct 1982, 00:00
Subject: [Ben Littauer <littauer at BBN-UNIX>: Re: TAC/ITS telnet bug?]
Message-ID: <mailman.233.1479821107.4695.its@nocrew.org>

Mail-from: ARPANET site MIT-MC rcvd at 18-Oct-82 1844-EDT
Date: Oct 18 1982 18:38:41 EDT (Monday)
From: Ben Littauer <littauer at BBN-UNIX>
Subject: Re: TAC/ITS telnet bug?
In-Reply-to: Your message of 14 Oct 1982 17:23:47 EDT (Thursday)
To: Ben Littauer <littauer at BBN-UNIX>
Cc: moon  at  SCRC-Tenex  at  MIT-MC, EAK @ mit-mc, REM @mit-mc,
    frye at BBN-UNIX, ditmars at BBN-UNIX, herman at BBN-UNIX,
    JNC at mit-mc

Good News! (again)

Well, the last patch wasn't QUITE enough, but we were on the right trail.
REM apparently had his hopes dashed this weekend when SU-TAC continued
displaying THE BUG.

Further testing and reading of spagetti code proved beyond a shadow of
a doubt that the "wedging" occurred when ITS sent the TELNET IAC character
in one message, and followed with the DataMark in the next.  Thumbing
through the coroutines eventually showed that we were returning wrong
in this case.

I have a patch, already in SU-TAC, which will be released to the rest of
the net tomorrow morning.  It still is possible that there is some other
case which causes wedging, so I won't claim that it can't happen again,
but I don't think that it will.  

Sorry for the first false hopes, hope this one works...

				-ben-


-------

From JNCatMIT-XX  Sat Oct 16 00:00:00 1982
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 16 Oct 1982, 00:00
Subject: [Ben Littauer <littauer at BBN-UNIX>: Re: TAC/ITS telnet bug?]
Message-ID: <mailman.234.1479821107.4695.its@nocrew.org>

Mail-from: ARPANET site MIT-MC rcvd at 14-Oct-82 1818-EDT
Date: Oct 14 1982 17:23:47 EDT (Thursday)
From: Ben Littauer <littauer at BBN-UNIX>
Subject: Re: TAC/ITS telnet bug?
In-Reply-to: Your message of 14 Oct 1982 11:26:31 EDT (Thursday)
To: Ben Littauer <littauer at BBN-UNIX>
Cc: moon  at  SCRC-Tenex @ MIT-MC, EAK @ mit-mc, REM @mit-mc, frye at BBN-UNIX,
    ditmars at BBN-UNIX, herman at BBN-UNIX, JNC at mit-mc

Good news!

I found a local ITS afficionado, and with his help I was able 
to get the bug to happen.  I discovered that what was happening
was that the TAC would receive an NCP INS, which TELNET needs
as a signal to start discarding terminal output, but it was
not finding a matching TELNET DataMark in the data stream, 
the signal to STOP discarding terminal output.  The funny thing
was that the symptoms were so intermittent.

Reading the TAC code, I found that if we receive a message 
containing the TELNET intercept character, IAC, in one message,
and the DataMark was the first character of the next message,
then the TAC would fail to see the DataMark.  I have patched
my test TAC and have since been unable to re-create the bug.
I therefore hypothesize that ITS will occasionally send the IAC
in one message and the DataMark in another: can any ITS network
hackers verify or refute this?

ARPANET TACs should have received the patch by tomorrow morning,
so I would greatly appreciate hearing whether there is indeed a
difference.  It is possible that this fix will also cure the
flakiness seen in negotiating TELNET binary mode with the TAC;
anybody who has experienced those difficulties, PLEASE tell me
if there is any change.

I'm sorry this bug has been hanging (no pun intended) around so
long, but I thank you for your patience and perseverence; we
do want to hear about bugs, and we try to fix them as soon as
possible, but the ones that people are finding now are getting
to be the more subtle ones, so they do take longer...

Your friendly neighborhood TAC "wizard".
		    -ben-

-------

From CSTACY at MIT-MC  Fri Oct 15 00:00:00 1982
From: CSTACY at MIT-MC (CSTACY at MIT-MC)
Date: 15 Oct 1982 00:00
Subject: for future reference
Message-ID: <mailman.235.1479821107.4695.its@nocrew.org>

MC would not come up this afternoon due to some sort of
lossage in the T300 subsystem.  Running CHKR showed
that it couldnt frob the T300s; power cycling unit 3
de-confused it and the system came up ok.


From MOONatMIT-MC  Sun Oct 10 00:00:00 1982
From: MOONatMIT-MC (David A. Moon)
Date: 10 October 1982, 00:00
Subject: No subject
Message-ID: <mailman.237.1479821107.4695.its@nocrew.org>

    Date: Sunday, 3 October 1982, 03:10-EDT
    From: Patrick Sobalvarro <PGS at MIT-OZ at MIT-MC>
    To: bug-its at MIT-OZ at MIT-MC
    Cc: akr at MIT-OZ at MIT-MC

    Alex Krymm (our new hardware person) has agreed to take a look at the prints
    for ML's Chaosnet interface and consider building one for AI.

    Questions:
    Is it really worth it?  That is, will this just be a lot of thankless work for
    him?  Or is it comparatively simple?  Is someone who understands the hardware
    well around to answer the occasional question?
I'll be happy to answer questions within the limited amount of time I have
available.

    Would he have to do
    wirewrapping, or do we have wirelists that we can send to Augat?
Of course not.  It would be machine-wrapped.

The only issue is finding documentation on the AI TTL I/O bus plus figuring
out whether it is still there.  It is unlikely to be 100% compatible with
the ML/DM TTL I/O bus, hence the Chaosnet interface would need some small
changes.  If it's not still there it would need to be retrieved from wherever
it went and hooked up again.  I imagine Knight could help with this.

From DCP at MIT-MC  Sun Oct 10 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 10 Oct 1982 00:00
Subject: No subject
Message-ID: <mailman.238.1479821107.4695.its@nocrew.org>

How willing are we to trust AI for mail?  Specifically, should
BUG-<unknown-list-on-MC> go to AI and probably end up in 
BUG-RANDOM-PROGRAM.  Doing the conversion is not a trivial
matter, since there are probably several lists which depend on
this happening and winding up on AI.  Alternatively, AI isn't
doing that much as it is, so maybe that is a good place for the
COMSAT computrons???


From GJC0 at MIT-MC  Fri Oct  8 00:00:00 1982
From: GJC0 at MIT-MC (GJC0 at MIT-MC)
Date: 08 Oct 1982 00:00
Subject: The second most popular PDP-11 operating system on the NET?
Message-ID: <mailman.239.1479821107.4695.its@nocrew.org>

According to the FAX I gathered for SYSENG;HOSTS >, using NUMER;HOSTP,
the most popular pdp-11 operating system on the "net" is UNIX, with 64 sites.
The second most popular is MINITS with 27 sites.


From ALANatMIT-MC  Fri Oct  8 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 8 October 1982, 00:00
Subject: GENSYM servers???????
Message-ID: <mailman.240.1479821107.4695.its@nocrew.org>

    Date: 7 October 1982 21:01-EDT
    From: George J. Carrette <GJC>
    Re:   GENSYM servers???????

    yow

You know about the YOW server on CCC?  Give it a try.


From GJC at MIT-MC  Thu Oct  7 00:00:00 1982
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 07 Oct 1982 00:00
Subject: GENSYM servers???????
Message-ID: <mailman.241.1479821107.4695.its@nocrew.org>

yow

From ALANatMIT-MC  Thu Oct  7 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 7 October 1982, 00:00
Subject: ON MC
Message-ID: <mailman.242.1479821107.4695.its@nocrew.org>

    Date: 10/07/82 11:57:18
    From: GJC

    We seem to have a lot of jobs like
    ___*** CHAOS GENSYM  ...... MPV and ILOPR
    since people from Plasma have to lot in I'm going to gun these now.
    Maybe it is intermittent?

I fixed the problem.  When they rejected connections these GENSYM servers were
POPJing off the bottom of the stack which generally caused them to jump into the
accumulators...


From GJC at MIT-MC  Thu Oct  7 00:00:00 1982
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 07 Oct 1982 00:00
Subject: ON MC
Message-ID: <mailman.243.1479821107.4695.its@nocrew.org>

We seem to have a lot of jobs like
___*** CHAOS GENSYM  ...... MPV and ILOPR
since people from Plasma have to lot in I'm going to gun these now.
Maybe it is intermittent?



From DCPatMIT-MC  Thu Oct  7 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 7 October 1982, 00:00
Subject: CPI numbers
Message-ID: <mailman.244.1479821107.4695.its@nocrew.org>

CHAOS EOF packets:

There are two things going on here.  First is that ITS will allow
an EOF packet to be sent that has a non-zero bytelength for the
data field.  I don't think this is right.  Second is that doing a
TWENEX SIN JSYS on a chaos channel which has received an EOF will
give you the bogus data in the EOF before signalling the end of
file.

Case in point: The gensym server on MC originally didn't set the
byte length of the EOF, so twenex would print whatever happened
to be in the packet at the time.  For example,
	@type cha:mc.gensym_foobar
	19EGSNMYF OOAB
instead of just
	19


To Alan and cm-i: The GENSYM server has been fixed to no tickle
either bug.


From RWKatSCRC-TENEX  Wed Oct  6 00:00:00 1982
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: Wednesday, 6 October 1982, 00:00
Subject: archive device overload
In-Reply-To: The message of 2 Oct 82 16:58-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <mailman.245.1479821107.4695.its@nocrew.org>

    Date: 2 October 1982 16:58-EDT
    From: Alan Bawden <ALAN at MIT-MC>
    1) Is it really the case that there can't be more than about 8 jobdevices at
    any one time?  I guess this is reasonable since there usually isn't any more
    than about 4 active at any one time.
Yes.
    2) I hope that the LMODEM program is taking the proper precautions to prevent
    the user from using up infinite channels.  The maintainers should spend a
    minute or two thinking about correctly unwind-protecting their program so that
    this can't happen if they haven't already (in which case they should think
    about possible bugs).

In this case, it isn't LMODEM's problem.  They're staying around after
LMODEM's channels have been closed.

    3) What are archive devices waiting for when they go to sleep?  Normally they
    seem to hang.  These behaved as if they were waiting for a lock to free up.
    (The fact that they all disappeared after I gunned a couple presumably
    indicates that archive devices take the correct actions to insure that locks
    will be unlocked when jobs get killed.)  Is there some sort of deadly embrace
    that is known to happen?

Usually they're waiting for the lock to be freed that is held by
whichever one of them that got the error.  Generally, the error is a
clobbered archive.  It used to be true, may still be true, that having
the archive too large to map would cause it to be permanently broken
in this way.

    4) Since the job on the user end of the job channel had gone away, shouldn't
    the job devices have been told about it?  I don't find anything specific in the
    job device documentation about what happens when the user goes away, but I
    thought that the system simulated a .CLOSE on any channels associated with
    any terminated jobs, but this would have cleaned things up wouldn't it?
    (I just tried this myself, and that seems to be the case...)
Yes, but the ARCHIVE device doesn't allow any of this until it's
gotten the lock.
    5) Perhaps the .SLEEP that the archive device is using (where?) shouldn't be
    forever, but instead it should wake up every five minutes and be sure it still
    has a reason to live.
Something like that.

From PGSatMIT-OZatMIT-MC  Sun Oct  3 00:00:00 1982
From: PGSatMIT-OZatMIT-MC (Patrick Sobalvarro)
Date: Sunday, 3 October 1982, 00:00
Subject: No subject
Message-ID: <mailman.246.1479821107.4695.its@nocrew.org>

Alex Krymm (our new hardware person) has agreed to take a look at the prints
for ML's Chaosnet interface and consider building one for AI.

Questions:
Is it really worth it?  That is, will this just be a lot of thankless work for
him?  Or is it comparatively simple?  Is someone who understands the hardware
well around to answer the occasional question?  Would he have to do
wirewrapping, or do we have wirelists that we can send to Augat?


From CENTatMIT-AI  Sun Oct  3 00:00:00 1982
From: CENTatMIT-AI (Pandora B. Berman)
Date: 3 October 1982, 00:00
Subject: Lord of Light reincarnated
Message-ID: <mailman.247.1479821107.4695.its@nocrew.org>

with advice from moon and much assistance from alan (who did most of
the actual work), Puff-The-Magic namedragon has been copied over from
ML to do namedragonish things like keeping track of logout times.
apparently the LOGOUT TIMES file has not been written to since the
knight tvs were last patched out (presumably Taraka Namdrg wants to
display on them before modifying the file?).

we first considered patching Taraka Namdrg to not try to write out to
the knight tvs, but that proved much too hairy.

From ALANatMIT-MC  Sat Oct  2 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 2 October 1982, 00:00
Subject: archive device overload
Message-ID: <mailman.248.1479821107.4695.its@nocrew.org>

I noticed that my attempts to use the DIR device were reporting DEVICE FULL
errors, and since the system was far from full I deduced that we had run out of
some resource specific to jobdevices.  Sure enough, there were eight or so
sleeping archive devices.  They were all associated with a nonexistant job that
had presumably once been named <uname> LMODEM.  (Although PEEK could have been
mistaken about this if the job number had been recycled, the fact that they
were all using an archive on the CPM directory backs this up.)  I gunned a
couple of them and suddenly the rest disappeared.  I have several questions:

1) Is it really the case that there can't be more than about 8 jobdevices at
any one time?  I guess this is reasonable since there usually isn't any more
than about 4 active at any one time.

2) I hope that the LMODEM program is taking the proper precautions to prevent
the user from using up infinite channels.  The maintainers should spend a
minute or two thinking about correctly unwind-protecting their program so that
this can't happen if they haven't already (in which case they should think
about possible bugs).

3) What are archive devices waiting for when they go to sleep?  Normally they
seem to hang.  These behaved as if they were waiting for a lock to free up.
(The fact that they all disappeared after I gunned a couple presumably
indicates that archive devices take the correct actions to insure that locks
will be unlocked when jobs get killed.)  Is there some sort of deadly embrace
that is known to happen?

4) Since the job on the user end of the job channel had gone away, shouldn't
the job devices have been told about it?  I don't find anything specific in the
job device documentation about what happens when the user goes away, but I
thought that the system simulated a .CLOSE on any channels associated with
any terminated jobs, but this would have cleaned things up wouldn't it?
(I just tried this myself, and that seems to be the case...)

5) Perhaps the .SLEEP that the archive device is using (where?) shouldn't be
forever, but instead it should wake up every five minutes and be sure it still
has a reason to live.

From RWKatSCRC-TENEX  Sat Oct  2 00:00:00 1982
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: Saturday, 2 October 1982, 00:00
Subject: [MINSKY at MIT-OZ: clucftp]
In-Reply-To: The message of 2 Oct 82 04:26-EDT from Christopher C. Stacy <CStacy at MIT-MC>
Message-ID: <mailman.249.1479821107.4695.its@nocrew.org>

    Date: Saturday, 2 October 1982, 04:26-EDT
    From: Christopher C. Stacy <CStacy at MIT-MC>
    This is reproducable.  Anyone have any ideas why?


    Date: 30 Sep 1982 0032-EDT
    From: MINSKY at MIT-OZ
    Subject: clucftp
    To: cstacy at MIT-OZ
    cc: minsky at MIT-OZ

    When I use "get" to MC, it complains "bad format packet recieived".
    It used to work.  Has anything changed?
Possibly because of the addition of the AUTHOR to the OPEN response?


From CStacyatMIT-MC  Sat Oct  2 00:00:00 1982
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Saturday, 2 October 1982, 00:00
Subject: [MINSKY at MIT-OZ: clucftp]
Message-ID: <mailman.250.1479821107.4695.its@nocrew.org>

This is reproducable.  Anyone have any ideas why?


Date: 30 Sep 1982, 00:00
From: MINSKY at MIT-OZ
Subject: clucftp
To: cstacy at MIT-OZ
cc: minsky at MIT-OZ

When I use "get" to MC, it complains "bad format packet recieived".
It used to work.  Has anything changed?
-------