From AAB at AI.AI.MIT.EDU  Fri Jun 27 01:36:12 1986
From: AAB at AI.AI.MIT.EDU (Andrew A. Berlin)
Date: Jun 26 86 19:36:12 EDT
Subject: ROLM phones.
Message-ID: <[AI.AI.MIT.EDU].62057.860626.AAB>


It's getting pretty hard to get a ROLM phone connection to AI
these days.

Would it be possible to fix it so that AI hangs up the
ROLM phone after someone logs out (i.e. when it says
"Console Free", it should disconnect the Rolm phone).

- Andy

From ALAN at AI.AI.MIT.EDU  Wed Jun 25 17:49:20 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Jun 25 86 11:49:20 EDT
Subject: Foo
In-Reply-To: Msg of Wed 25 Jun 86 01:11:18 EDT from Jonathan D. Taft <TAFT at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].61315.860625.ALAN>

    Date: Wed, 25 Jun 86 01:11:18 EDT
    From: Jonathan D. Taft <TAFT at AI>
    To:   KS-ITS-CONFUSION at AI
    AI was unresponsive but running printing repeatedly on its console:
    "Warning: No free qsk channels"
    "System full no job slots."
    I dumped it to CRASH;FULL FORCED and reloaded.

Please send ITS bug reports to Bug-ITS.

This is the same disk hung lossage we have been experiencing ever since we
got the second drive as far as I can tell.  I guess the disk-going-offline
code that Moon wrote didn't actually address the correct problem, although
I do notice that in this crash dump NQOFFL has been AOSed once for each
drive (to bad there is no way to tell -when- this happened).  Foo.  Seems
to have happened again this morning as well.  Double foo.

From CENT at AI.AI.MIT.EDU  Fri Jun 20 01:58:28 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Jun 19 86 19:58:28 EDT
Subject: old mail
Message-ID: <[AI.AI.MIT.EDU].59198.860619.CENT>

    Date: Tue 17 Jun 86 15:57-EDT
    From: Randall Davis <DAVIS%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
    Subject: old mail
    To: bug-system%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU
    I've been getting old copies of info-space mailing list mailings (from
    Jan and now Fed) over the past couple of days.  It's been happening
    roughly since the crash when the mail queue was damaged.  When is the
    redundancy likely to end?  Is there anything to be done to cut off the
    useless mail?
this has nothing to do with OZ's mail queue, but is instead the result of
the retransmission of mail lost on (the old) MC this spring, as announced
in a msg to arpanet-bboards a few weeks ago (a copy is available if you
missed it).  you are fortunate to be on a mailing list which did not
absolutely depend on MC as a transmission step and which chose to
retransmit immediately, by other paths, those msgs which did not go through
the first time. most recipients of this mail are seeing it for the first
time; we regret that you are encoutering redundancy. the retransmission
process should be completed in about another week.

From DANIEL%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU  Mon Jun 16 04:17:17 1986
From: DANIEL%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Daniel Weise)
Date: Jun 15 86 22:17:17 EDT
Subject: No subject
Message-ID: <[MX.LCS.MIT.EDU].927113.860615.DANIEL>

When I dial in to MX, upon connecting the
11 says "Connected to MC."  Maybe someone
should tell it the new name.

Daniel

From CBF at AI.AI.MIT.EDU  Tue Jun 10 03:37:04 1986
From: CBF at AI.AI.MIT.EDU (Charles Frankston)
Date: Mon,  9 Jun 86 21:37:04 EDT
Subject: [Forwarded: JSLove@MIT-MULTICS.ARPA, Re: Re: info about INQUIR]
Message-ID: <[AI.AI.MIT.EDU].53941.860609.CBF>

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86  15:08:32 EDT
Received: from CHARON by MC.LCS.MIT.EDU  9 Jun 86 14:42:48 EDT
Received: by CHARON (5.15/4.7)
	id AA11138; Mon, 9 Jun 86 14:37:59 EDT
Received: by ATHENA (5.45/4.7)
	id AA15558; Mon, 9 Jun 86 14:39:42 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU  9 Jun 86 14:34:06 EDT
Date:  Mon, 9 Jun 86 14:21 EDT
From: "J. Spencer Love" <JSLove at MIT-MULTICS.ARPA>
Subject:  Re: info about INQUIR
To: Jan Popiel <Popiel at MIT-MULTICS.ARPA>
Cc: sipb at MC.LCS.MIT.EDU
In-Reply-To:  Message of 9 Jun 86 13:32 EDT from "Jan Popiel"
Message-Id:  <860609182112.975425 at MIT-MULTICS.ARPA>

What I suggested was this:  On ITS, there is the database maintained
using :INQUIR.  This database is not only consulted by :FINGER on ITS
and the FINGER protocol on the Internet and CHAOS, but was in the past
maintained consistently across 4 ITS sites.

This makes it a good example of a distributed database to be used as a
phone directory.  MIT Information Systems now encompasses MIT
telecommunications which produces the MIT directory.  Jan's group is now
writing a proposal and proposed specification for a system that might
eventually enable us to put the MIT Staff and Student directories on
line and allow people to update their own entries, and perhaps route
electronic mail as well.

Perhaps the original implementors of :INQUIR are known to people on this
list, or even former SIPB members.  Did anyone ever publish a paper on
this work, such as an undergraduate thesis?  Is the only documentation
of the goals and operation of this system in the source code?  What is
the source code written in and how could it be found?

Please direct replies to Popiel at MIT-Multics.ARPA.  I will assist him in
retrieving files and interpreting jargon.
                                        -- Spencer

----------------------------------------------------

What I (CBF) sent was this:


Well, you're right, in the past it was maintained consistently across 4
ITS sites;  now its maintained across 5 (AI, ML, MC, MD, & MX).  Anyway,
the mechanisms are fairly simple and CPU intensive.  Basically it is done
by mailing the updated record to all the other machines.  The mailer on
each machine spawn subtasks that merge the record into the database by
copying the entire database to one with a new name, and then using the ITS
rename while open call to atomically instantiate the new one and delete
the old one.

There is no attempt made to ensure that I don't change my record in rapid
succession on two different ITS's.  If I were to do that, it is
conceivable that entries on the different machines could be inconsistent.
In practice it just doesn't happen, or if it did, its trivial for
someone to fix it.  Note also that having the mailer daemon do the
database update (even on the same machine) simplifies a host of issues,
since the mailer is a single execution thread on ITS there is no need to
worry about concurrent updates.

If two man months have been put into this effort over the more than 10
years it has been in service, I would be shocked.

From ALAN at AI.AI.MIT.EDU  Mon Jun  9 22:00:16 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mon,  9 Jun 86 16:00:16 EDT
Subject: AI's losing network
In-Reply-To: Msg of Mon 9 Jun 1986  14:30 EDT from CPH at OZ.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].53546.860609.ALAN>

    Date: Mon, 9 Jun 1986  14:30 EDT
    From: CPH at OZ
    AI's network seems not to be working.  It is possible to connect from
    a terminal concentrator, but then it echoes characters very, very
    slowly.  The rest of the network is happy, all the bridges are running
    fine, etc.
    I tried reaching AI from both MX and OZ, and vice versa, with no luck.
    JAR and I tried cold-booting in the hope that it might work.  Again, a
    waste of time.

I don't know why it didn't occur to anyone that the problem was subnet 6,
and has nothing to do with AI, or ITS.

It turns out that subnet 6 doesn't work very well if you break it into two
pieces by terminating it at the junction box that the KS's are all plugged
into.

From ALAN at AI.AI.MIT.EDU  Mon Jun  9 21:48:44 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mon,  9 Jun 86 15:48:44 EDT
Subject: AI's losing network
In-Reply-To: Msg of Mon 9 Jun 1986  14:30 EDT from CPH at OZ.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].53545.860609.ALAN>

    Date: Mon, 9 Jun 1986  14:30 EDT
    From: CPH at OZ
    AI's network seems not to be working.  It is possible to connect from
    a terminal concentrator, but then it echoes characters very, very
    slowly.  The rest of the network is happy, all the bridges are running
    fine, etc.
    I tried reaching AI from both MX and OZ, and vice versa, with no luck.
    JAR and I tried cold-booting in the hope that it might work.  Again, a
    waste of time.

I don't know why it didn't occur to anyone that the problem was subnet 6,
and has nothing to do with AI, or ITS.

It turns out that subnet 6 doesn't work very well if you break it into two
pieces by terminating it at the junction box that the KS's are all plugged
into.

From CPH at OZ.AI.MIT.EDU  Mon Jun  9 20:30:00 1986
From: CPH at OZ.AI.MIT.EDU (CPH at OZ.AI.MIT.EDU)
Date: Jun 9 1986  14:30 EDT
Subject: AI's losing network
Message-ID: <CPH.12213491155.BABYL@MIT-OZ>

AI's network seems not to be working.  It is possible to connect from
a terminal concentrator, but then it echoes characters very, very
slowly.  The rest of the network is happy, all the bridges are running
fine, etc.

I tried reaching AI from both MX and OZ, and vice versa, with no luck.

JAR and I tried cold-booting in the hope that it might work.  Again, a
waste of time.

From JTW%MIT-SPEECH at XX.LCS.MIT.EDU  Sat Jun  7 00:00:00 1986
From: JTW%MIT-SPEECH at XX.LCS.MIT.EDU (John Wroclawski)
Date: Sat 7 Jun 86, 00:00
Subject: If you believe in Dovers, clap your hands!
Message-ID: <12212812879.9.JTW@MIT-SPEECH>

    Date: Sat,  7 Jun 86 00:08:53 EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    Subject:  If you believe in Dovers, clap your hands!

    .....

Unfortunately, I remember how the C compiler works. So at some point I'll
probably get around to making a couple of other changes to the spooler
(like, we don't really need it to distribute TeX font files anymore)
and compiling a new one.

In the meantime half of creation has changed their DOVER programs to
spool to MX. So we need to leave the spooler on the KL running for a
while.
-------

From ALAN at AI.AI.MIT.EDU  Sat Jun  7 06:08:53 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Sat,  7 Jun 86 00:08:53 EDT
Subject: If you believe in Dovers, clap your hands!
In-Reply-To: Msg of Fri  6 Jun 86 14:14:31 EDT from Jeffrey J Tyrone Sealy <TY%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].52858.860607.ALAN>

John, I'm just guessing it was you that moved the dover spooler from the KL
to the KS?  It didn't seem to be working.  I theorized that this had to do
with the fact that it had the device PK1: built into the source in many
places, so I launched another spooler with a translation from PK1: to DSK:
which now seems to be working.  I fixed the sources to use PK0: instead of
PK1:, which should work on any ITS machine for the forseeable future.  I
couldn't assemble the sources because (assuming I know how to run the C
compiler, which I don't) there are all kinds of C libraries that have been
migrated to KL GFR tapes.

Anyone who cares about dover spooling is free to finish what John and I
have started I guess.  Step one is to get back the C libraries I guess...
I've always been in favor of kicking the dover out the window, so I'm
certainly in no rush to do this myself.

While I was at it, I fixed the various job devices so that DVR^F would know
to contact the KS now, instead of the KL.

I did -not- install a MC:CHANNA;RAKASH DVRSPL on the KS, because any newly
launched demon still needs that translation to function.  Until someone
assembles (and links, how unaesthetic for an ITS!) the new sources, the
demon can be launched by hand by running the xfile .DOVR.;.SPOOL XFILE1 on
the KS.  (Hackers who might bring the MC KS up, take note!)

From CPH%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU  Wed Jun  4 19:41:52 1986
From: CPH%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Chris Hanson)
Date: Wed,  4 Jun 86 13:41:52 EDT
Subject: DOVER Lossage
Message-ID: <[MX.LCS.MIT.EDU].924307.860604.CPH>

I know this isn't really the right place, but BUG-DOVER looks like a
dead list to me...

Will someone please fix :DOVER so that it knows how to spool?
Obviously there IS a spooler, since DVR^F works fine -- except that
:DOVER doesn't seem to know how to talk to it.

From MAP%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU  Tue Jun  3 01:53:24 1986
From: MAP%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Michael A. Patton)
Date: Mon,  2 Jun 86 19:53:24 EDT
Subject: Actually the MX front end 11 I believe.
Message-ID: <[MX.LCS.MIT.EDU].923914.860602.MAP>

When you call up the MX (formerly MC) dialup it gives you the message:
	Connected to MC.
just before you get the MX banner from PWORD.  This should probably be
fixed.

From MOON at AI.AI.MIT.EDU  Sun Jun  1 21:00:20 1986
From: MOON at AI.AI.MIT.EDU (David A. Moon)
Date: Sun,  1 Jun 86 15:00:20 EDT
Subject: Warning to ITS hackers
Message-ID: <[AI.AI.MIT.EDU].49646.860601.MOON>

If you assemble the current source it won't run unless you use the
new microcode I'm debugging.  I think it will run if you patch
OVHCLK/ POPJ P, which will keep it from executing the instructions
that aren't implemented.  OIPBIT is non-zero now, but it should still
be a no-op with the released microcode.  It's unlikely that I will
finish this before next week, since I will be out of town.

From SRA at XX.LCS.MIT.EDU  Sun Jun  1 02:18:00 1986
From: SRA at XX.LCS.MIT.EDU (Rob Austein)
Date: May 31 1986  20:18 EDT
Subject: mit-mx
In-Reply-To: Msg of 31 May 1986  18:53-EDT from macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)
Message-ID: <SRA.12211195221.BABYL@XX.LCS.MIT.EDU>

    Date: Saturday, 31 May 1986  18:53-EDT
    From: macrakis%endor at harvard.HARVARD.EDU (Stavros Macrakis)
    To:   dudek
    cc:   bug-sys at mit-mc.arpa
    Re:   mit-mx

    tn etc. don't seem to know about `mx' == mx.lcs.mit.edu

What machine are you running telnet on?  MX.LCS.MIT.EDU is in the
domain database.  If your machine can't find it, that's not our fault.
I wouldn't expect just "mx" to work, unless you are on a machine in
the LCS.MIT.EDU domain.  Welcome to the future.

From macrakis%endor at harvard.HARVARD.EDU  Sun Jun  1 00:53:26 1986
From: macrakis%endor at harvard.HARVARD.EDU (Stavros Macrakis)
Date: May 31 86 18:53:26 EDT
Subject: mit-mx
Message-ID: <mailman.1418.1479821140.4695.its@nocrew.org>

tn etc. don't seem to know about `mx' == mx.lcs.mit.edu