From ZVONA at AI.AI.MIT.EDU  Mon Mar 30 21:54:07 1987
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: Mar 30 87 14:54:07 EST
Subject: [KLOTZ%OZ.AI.MIT.EDU: sys;system mail]
Message-ID: <176082.870330.ZVONA@AI.AI.MIT.EDU>

Well, this is really random.

Date: Mon 30 Mar 87, 00:00
From: Leigh L. Klotz <KLOTZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
To:   zvona%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU
Re:   sys;system mail

Actually I wanted to put a * in the file but it turns out that ddt
prints out a crlf after the file if there wasn't one...

From ZVONA at AI.AI.MIT.EDU  Sun Mar 29 21:41:13 1987
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: Mar 29 87 14:41:13 EST
Subject: No subject
Message-ID: <175557.870329.ZVONA@AI.AI.MIT.EDU>

I deleted ai:sys;system mail a few days ago, and then someone
wrote one that has just a crlf in it.  I agree with him (Klotz
actually) that this looks better.  Seems like a kludge this way;
maybe it would be better to patch ddt/pword to print the crlf
there instead.

From ED at AI.AI.MIT.EDU  Tue Mar 24 15:48:33 1987
From: ED at AI.AI.MIT.EDU (Ed Schwalenberg)
Date: Mar 24 87 09:48:33 EST
Subject: CAMEXEC
Message-ID: <173000.870324.ED@AI.AI.MIT.EDU>

    Date: Tue, 24 Mar 87 03:40:44 EST
    From: "Pandora B. Berman" <CENT at AI.AI.MIT.EDU>

        Date: Sat, 21 Mar 87 05:59:20 EST
        From: "Anthony A. Datri" <AAD at AI.AI.MIT.EDU>
        Subject: is this a mailing list?
	...
        IBM.  Also, I saw something somewhere about something called CAMEXEC,
        which called it an its-like operating system for the pdp-11.  Since
	...
    ...
    as to CAMEXEC, yes, it is an ITS-emulating system, written by ED at AI.
    ...
Before this gets out of hand, CAMEXEC was written by Mike Speciner, who was
MS at AI a very long time ago (so long ago that the "@AI" part was seldom used,
since the ARPAnet didn't really work very well yet).

From CENT at AI.AI.MIT.EDU  Tue Mar 24 09:40:44 1987
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Mar 24 87 03:40:44 EST
Subject: is this a mailing list?
Message-ID: <172875.870324.CENT@AI.AI.MIT.EDU>

    Date: Sat, 21 Mar 87 05:59:20 EST
    From: "Anthony A. Datri" <AAD at AI.AI.MIT.EDU>
    Subject: is this a mailing list?
    To: INFO-ITS at AI.AI.MIT.EDU, INFO-ITS-REQUEST at AI.AI.MIT.EDU
    Is this an ITS mailing list (duh!)?  If so, could I be added to it?
    I'm relatively new to ITS (turist account), and I'd love to find out
    more.  I have great respect for an os that was named to make fun of
    IBM.  Also, I saw something somewhere about something called CAMEXEC,
    which called it an its-like operating system for the pdp-11.  Since
    I've got an 11/34 with nothing better to run than 2.9.1 BSD or RT11,
    I'm interested.  Does anyone know anything about this? (hmm.  that
    sounds like a stupid question, doesn't it?)  If I seem confused, it's
    because I largely am.  I'm learning about ITS by trial and error.

    I bet this will seem the strangest to you.  IS ITS public domain at
    this point?  If it is, what would it take to get a distribution?  This
    is a very silly question, but I seriously intend to have a 2020 of my
    own someday.  If Mr. Crispin can do it, so can I 8^)

    Thanks for any time you spend putting up with and/or answering this
    mail.

INFO-ITS is, of course, a mailing list, but it is not used for regular
mail.  it follows the original fashion of lists named INFO-x, being a very
large list used only for announcements of general interest and importance
to the ITS community -- for instance, major changes in the system.  you
should not send mail to it. i will add you to it (if no one else has yet),
but don't expect more than one or two msgs a year to be sent.  BUG-ITS or
one of the more specific ITS-related lists is probably the right list for
your various questions.

as to CAMEXEC, yes, it is an ITS-emulating system, written by ED at AI. he
can give you lots of information about it.

ITS is more or less public domain. however, there is no regular
distribution system; each ITS kit is custom-made. for one thing, in the
current scheme of things, each ITS in the world needs a unique two-letter
ID, assigned here so it can be included in some of the deep internals.  so
we are not inclined to scatter ITS kits at random. if you get a KS, and
want such a kit, the correct list to correspond with is KS-ITS at AI.

for info on ITS, you should start by looking into the :INFO program and
reading what it has to offer.

From AAD at AI.AI.MIT.EDU  Sat Mar 21 11:59:20 1987
From: AAD at AI.AI.MIT.EDU (Anthony A. Datri)
Date: Mar 21 87 05:59:20 EST
Subject: is this a mailing list?
Message-ID: <171734.870321.AAD@AI.AI.MIT.EDU>


Is this an ITS mailing list (duh!)?  If so, could I be added to it?  I'm relatively
new to ITS (turist account), and I'd love to find out more.  I have great
respect for an os that was named to make fun of IBM.  Also, I saw something
somewhere about something called CAMEXEC, which called it an its-like
operating system for the pdp-11.  Since I've got an 11/34 with nothing better
to run than 2.9.1 BSD or RT11, I'm interested.  Does anyone know anything
about this? (hmm.  that sounds like a stupid question, doesn't it?)  If
I seem confused, it's because I largely am.  I'm learning about ITS by
trial and error.

I bet this will seem the strangest to you.  IS ITS public domain at this
point?  If it is, what would it take to get a distribution?  This is a very
silly question, but I seriously intend to have a 2020 of my own someday.
If Mr. Crispin can do it, so can I 8^)

Thanks for  any time you spend putting up with and/or answering this mail.

Anthony A. Datri
aad at ai.ai.mit.edu (but i imagine you guessed that, eh?)

From JTW at MIT-SPEECH  Fri Mar 20 00:00:00 1987
From: JTW at MIT-SPEECH (John Wroclawski)
Date: Fri 20 Mar 87, 00:00
Subject: TCP buffers
In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12288011565.22.JTW@MIT-SPEECH>


Yow! Anyway, what I was going to say when the message cleverly decided to
send itself was that the second TCP buffer problem (which is the more
serious - the SYN problem loses packets slowly over time, but when the
IMP problem hits you have had it) is due to my driver code's apparent
inability to always recover correctly from a dropped ACC interrupt.

I haven't had a chance to look at the SYN problem yet, but given what
we learned from Dave's stuff it should be fairly easy to find.
-------


From JTW at MIT-SPEECH  Fri Mar 20 00:00:00 1987
From: JTW at MIT-SPEECH (John Wroclawski)
Date: Fri 20 Mar 87, 00:00
Subject: TCP buffers
In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12288009716.22.JTW@MIT-SPEECH>

Moon's PEEK mode actually showed two different problems with the TCP
buffer stuff. Alan mentioned the first one; there is a path which drops
SYN packets on the floor. Dave mentioned the second; the KS IMP driver
occasionally forgets what it is supposed to be doing. The secon
-------


From Moon at STONY-BROOK.SCRC.Symbolics.COM  Fri Mar 20 21:19:00 1987
From: Moon at STONY-BROOK.SCRC.Symbolics.COM (David A. Moon)
Date: Mar 20 87 15:19 EST
Subject: TCP buffers
In-Reply-To: <171046.870320.KLH@AI.AI.MIT.EDU>
Message-ID: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 20 Mar 87 01:47:48 EST
    From: Ken Harrenstien <KLH at AI.AI.MIT.EDU>

    Another approach would be to modify PEEK (or something else) to look at the
    buffers, including those not on any list.  The contents might give
    you a clue -- perhaps they are all from a particular host, or use a
    particular protocol, or all have the SYN or FIN bit set, etc.

I did that a month or two ago.  I don't remember any more what I found out,
except that there were a large number of buffers queued for transmission and
the IMP wasn't taking them.  But I don't remember what was in them.  We still
have the crash dumps and :p <filename <return> ? should say what the new mode is
(1A I think).



From ALAN at AI.AI.MIT.EDU  Fri Mar 20 21:30:42 1987
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 20 87 15:30:42 EST
Subject: TCP buffers
In-Reply-To: Msg of Fri 20 Mar 87 01:47:48 EST from Ken Harrenstien <KLH at AI.AI.MIT.EDU>
Message-ID: <171296.870320.ALAN@AI.AI.MIT.EDU>

I guess it wasn't announced to Bug-ITS when Moon put a mode into PEEK for
looking at TCP buffers (type "1A").  After using this mode on running
systems and crash dumps it appears that the lost packets are always SYN
packets with their Retransmit flag set.  JTW points out that the only
effect of a bug that causes retransmission of SYNs to get dropped would be
that opening connections would time-out more frequently than they should.
This doesn't address the issue of why the problem only seems to happen on
the KS's and never on the KL.



From JAR at AI.AI.MIT.EDU  Fri Mar 20 20:52:06 1987
From: JAR at AI.AI.MIT.EDU (Jonathan A Rees)
Date: Mar 20 87 14:52:06 EST
Subject: today's crash
Message-ID: <171239.870320.JAR@AI.AI.MIT.EDU>

"PK: Freeing packet still in use!  PI LEVEL 2 BUGHALT ..."

Dumped to CRASH; PACKET INUSE .

-Jonathan

From KLH at AI.AI.MIT.EDU  Fri Mar 20 07:47:48 1987
From: KLH at AI.AI.MIT.EDU (Ken Harrenstien)
Date: Mar 20 87 01:47:48 EST
Subject: TCP buffers
Message-ID: <171046.870320.KLH@AI.AI.MIT.EDU>

One approach for finding out where the buffers are going might be to
look at the various meters.  If you find a meter which has a count the
same as (or close to) the number of buffers that are "lost", then you've
found something.

Another approach would be to modify PEEK (or something else) to look at the
buffers, including those not on any list.  The contents might give
you a clue -- perhaps they are all from a particular host, or use a
particular protocol, or all have the SYN or FIN bit set, etc.

Considering the remarkable things that have already been discovered
with respect to .HANG and LOCKS, surely yet another long standing
mystery will shortly come to light.




From Alan at AI.AI.MIT.EDU  Mon Mar 16 00:09:00 1987
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 15 87 18:09 EST
Subject: Recent bugs
In-Reply-To: <132118.861218.ALAN@AI.AI.MIT.EDU>,
             <141115.870116.ALAN@AI.AI.MIT.EDU>
Message-ID: <870315180951.4.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Thu, 18 Dec 86 02:57:19 EST
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    TTYSET on a TTY opened as a device (rather than as a console)
    clobbers the wrong TTYST* words!

I am unable to reproduce this.  I'm certain I was able to clobber
SIXBIT/FOOBAR/ into the TTYST1 word of T0n+1 when I had T0n open as a
device, but I can't get it to happen now...  I must have been severely
faked out somehow.

    Date: Fri, 16 Jan 87 17:13:23 EST
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    After reading the following bug report [not included], you will realize
    that this reveals a bug in the way jobs are sometimes killed when they
    have locks locked.  If you -first- clobbering their PC's to point to a
    .LOGOUT in location 0, and only the .LOGOUT then checks to see if the
    PC is in the critical routine table, then the critical routine table is
    worthless...

I fixed the lock unlocking stuff to always use the correct PC, so .GUNing
somebody when he is in a critical region should now do the right thing.  I
didn't do anything to prevent lock unlocking instructions from clobbering
the location that contains the .LOGOUT.

From JTW%MIT-SPEECH at XX.LCS.MIT.EDU  Wed Mar 11 00:00:00 1987
From: JTW%MIT-SPEECH at XX.LCS.MIT.EDU (John Wroclawski)
Date: Wed 11 Mar 87, 00:00
Subject: not a bug
In-Reply-To: Message from "Eric Sven Ristad <RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>" of Wed 11 Mar 87 13:21:53-EST
Message-ID: <12285582215.16.JTW@MIT-SPEECH>


10.2.0.6

You can use the HOST program to find out things like this. (:HOST AI
from an ITS or HOST AI from a TOPS-20 like OZ)
-------

From RISTAD%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU  Wed Mar 11 00:00:00 1987
From: RISTAD%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU (Eric Sven Ristad)
Date: Wed 11 Mar 87, 00:00
Subject: not a bug
Message-ID: <mailman.1417.1479821137.4695.its@nocrew.org>

What is AI's telnet address (e.g. MX is 10.1.0.6)?
Thanks,

Eric

From deh at eneevax.umd.edu  Tue Mar 10 06:41:36 1987
From: deh at eneevax.umd.edu (Douglas Humphrey)
Date: Mar 10 87 00:41:36 EST
Subject: MD has internal troubles
Message-ID: <8703100541.AA13924@eneevax.umd.edu>

RP06 Disk drives are selling for less than the $500 that you state it
will take to fix the existing drive. Has someone contacted used hardware
places in the Boston area (to save shipping charges) to see if they will
either sell or donate an RP06 or two ? I will note that a place in Atlanta
just had several Hundred RP06 drives sent to a scrapper for cents per pound
because there is no market for them any longer. 

Doug


From CENT at AI.AI.MIT.EDU  Mon Mar  9 06:36:27 1987
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Mon,  9 Mar 87 00:36:27 EST
Subject: MD has internal troubles
Message-ID: <165407.870309.CENT@AI.AI.MIT.EDU>

(remailed for the record)

Date: Mar 6 87 16:00 EST
From: Alan Bawden <Alan at AI.AI.MIT.EDU>
Subject: MD
Well, head 7 on MD's RP06 is deteriorating fast.  JTW just tried cleaning
the heads, but it doesn't look like that helped the problem.  I'm
considering taking ITS down so as to not risk damage to the filesystem.
This drive is not on service contract, and neither AI nor presumably LCS
has any real interest in paying to get it fixed.  It cost about 500 bucks
to get this fixed when it happened to one of AI's drives.

[ CStacy broke the UNLOCK routine in the Salvager, by the way... ]

From SRA at XX.LCS.MIT.EDU  Fri Mar  6 19:24:00 1987
From: SRA at XX.LCS.MIT.EDU (Rob Austein)
Date: Mar 6 1987  13:24 EST
Subject: BT AUTO
In-Reply-To: Msg of 6 Mar 1987  12:47-EST from David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
Message-ID: <SRA.12284268841.BABYL@XX.LCS.MIT.EDU>

If we can do the hack with Gumby's clock, I say this is a win.  I have
always considered it a big feature that I can go home and sleep and
not be beheaded in the morning by 50 irate XX users who want to know
why their mail hasn't gotten through.  It'd be nice if MC and AI could
take care of themselves too.

It seems it ought to be possible to detect which drives are offline at
boot time; Twenex does this, perhaps DSKDMP or ITS could just zap QACT
when it sees that a drive is offline?

While we're adding twenexisms, how about automatic crash dumps and
automatic proceed or reload when there isn't a hacker on duty? :-)

From GUMBY at AI.AI.MIT.EDU  Fri Mar  6 18:47:39 1987
From: GUMBY at AI.AI.MIT.EDU (David Vinayak Wallace)
Date: Fri,  6 Mar 87 12:47:39 EST
Subject: BT AUTO
In-Reply-To: Msg of Thu 5 Mar 87 19:37 EST from Alan Bawden <Alan at AI.AI.MIT.EDU>
Message-ID: <164347.870306.GUMBY@AI.AI.MIT.EDU>

    Date: Thu, 5 Mar 87 19:37 EST
    From: Alan Bawden <Alan at AI.AI.MIT.EDU>

    In theory there is a bit that the 8080 sets to indicate that this
    is an auto-boot.  DSKDMP could test that bit and always load .;@
    ITS.  Then it could set some kind of a flag to tell DDT to
    immediately $G and then start it.

    Then we would have to change all of our habits about disk drives
    being offline, because we would always need to patch QACT in the
    binary as well as the running system.

This is reasonable.  We could get rid of that crufty ITS/NITS/XITS
naming randomness too (what's wrong with a link?).

    Then we have to figure out what to do about setting the time.
    After a power-glitch, a KS-10 will -always- forget the time.
    Getting the time from the network simply doesn't work.  (This
    afternoon when AI and MC asked for the time from the network, only
    -one- host responded to their query.  I'm kind of reluctant to set
    the time on the basis of a single answer.)

I still have that clock that didn't get installed because I/we
couldn't figure out which protocol was the best and what machine to
put it on.  Why not put it on MC?  I've been watching it for the last
several months and it keeps time better than my watch (which is what
we use otherwise, right?)

From Alan at AI.AI.MIT.EDU  Fri Mar  6 01:37:00 1987
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 5 87 19:37 EST
Subject: BT AUTO
In-Reply-To: <SRA.12284008604.BABYL@XX.LCS.MIT.EDU>
Message-ID: <870305193743.5.ALAN@PIGPEN.AI.MIT.EDU>

[ Should have combined this message with the previous one, but I
  overlooked this message the first time through my mail. ]

    Date: Thu, 5 Mar 1987  13:34 EST
    From: Rob Austein <SRA at XX.LCS.MIT.EDU>
    ...
    Or is it, for some reason beyond my ken, considered a feature that ITS
    needs a human to reboot?

Well, booting the system without human assistance just makes me a little
nervous, but we could think about it:

In theory there is a bit that the 8080 sets to indicate that this is an
auto-boot.  DSKDMP could test that bit and always load .;@ ITS.  Then it
could set some kind of a flag to tell DDT to immediately $G and then start
it.

Then we would have to change all of our habits about disk drives being
offline, because we would always need to patch QACT in the binary as well
as the running system.

Then we have to figure out what to do about setting the time.  After a
power-glitch, a KS-10 will -always- forget the time.  Getting the time from
the network simply doesn't work.  (This afternoon when AI and MC asked for
the time from the network, only -one- host responded to their query.  I'm
kind of reluctant to set the time on the basis of a single answer.)

From Alan at AI.AI.MIT.EDU  Fri Mar  6 01:10:00 1987
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 5 87 19:10 EST
Subject: BT AUTO
In-Reply-To: <163684.870305.ZVONA@AI.AI.MIT.EDU>
Message-ID: <870305191017.3.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Thu,  5 Mar 87 13:12:14 EST
    From: David Chapman <ZVONA at AI.AI.MIT.EDU>
    AI and MC both lost with BT AUTO.  I take it this was a powerglitch.
    I dumped to BTAUTO HUH? AI:, presumably this is gubbish if it really
    was a glitch.  Lost a lot of work, fuck.

Yeah, "BT AUTO" is what the 8080 front-end types when it decides to
automatically boot the machine after the machine is powered on.  For ITS
the boot routine just loads up DSKDMP and starts it, which is presumably
how you found the machine.  Since the boot routine zeros core before
loading DSKDMP (it does this to wipe out potential parity errors), your
crash dump contains nothing more than the boot routine itself.  Thanks for
tending to the problem!

From SRA at XX.LCS.MIT.EDU  Thu Mar  5 19:34:00 1987
From: SRA at XX.LCS.MIT.EDU (Rob Austein)
Date: Mar 5 1987  13:34 EST
Subject: BT AUTO
In-Reply-To: Msg of 5 Mar 1987  13:12-EST from David Chapman <ZVONA@AI.AI.MIT.EDU>
Message-ID: <SRA.12284008604.BABYL@XX.LCS.MIT.EDU>

Right, that's a powerglitch.  The power fail microcode on the KSs
doesn't seem to work any better than the powerfail code on the KL-Bs
(worse, actually, about once every six months XX or OZ will reboot
correctly after a powerfail and surprise the hell out of everybody).

I know that in the case of the KL-Bs running twenex microcode this has
been a problem for years.  It gets fixed, then broken, then fixed, ad
nauseum.  Unless Alan tells me otherwise I'd assume it's a similar
problem on the KSs.

Or is it, for some reason beyond my ken, considered a feature that ITS
needs a human to reboot?

From ZVONA at AI.AI.MIT.EDU  Thu Mar  5 19:12:14 1987
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: Thu,  5 Mar 87 13:12:14 EST
Subject: No subject
Message-ID: <163684.870305.ZVONA@AI.AI.MIT.EDU>

AI and MC both lost with BT AUTO.  I take it this was a powerglitch.
I dumped to BTAUTO HUH? AI:, presumably this is gubbish if it really
was a glitch.  Lost a lot of work, fuck.