From ALAN at AI.AI.MIT.EDU  Wed Apr 30 21:04:37 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Apr 30 86 15:04:37 EDT
Subject: tty types
In-Reply-To: Msg of Wed 30 Apr 86 02:43:20 EDT from Patrick G. Sobalvarro <PGS at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].33061.860430.ALAN>

    Date: Wed, 30 Apr 86 02:43:20 EDT
    From: Patrick G. Sobalvarro <PGS at AI>
        Date: Tue, 29 Apr 86 08:31:04 EDT
        From: Alan Bawden <ALAN at AI>
	(Note that until recently ROLM lines incorrectly had the %TYDIL bit
	set in their TTYTYP words, perhaps you are noticing an effect of
	this change.)
    I thought %TYDIL was correct for the ROLM lines, since they are exactly
    analogous to dialups; one connects terminals of different types to them, so
    they should have their tty types reset to something neutral when
    disconnected, etc.  And, if we supported it in the 11, they should hang up
    after they've been logged out for a while, all those dialup-y things.

I should have been more careful about how I used the word "incorrectly".
As you set things up originally the ROLM lines were just like dialups and
had %TYDIL set for all of the reasons you give.  This all worked just fine
and there wasn't a thing wrong with it.  Then I got my greasy fingers into
the act.  

I added a %TYRLM bit for the benefit of people and programs that wanted the
distinguish between ordinary dialups that you tended to connect to from
outside NE43 (like from home), and ROLM lines that you tended to connect to
from inside NE43 (like from your office).  In this state of affairs ITS
tested %TYDIL to determine if it should do all those dialup-y things, and
programs that wanted to know if you were at home could test to see if
%TYDIL was set and %TYRLM wasn't.

The problem is that there were a zillion programs (most of them written in
DDT command language) that just tested %TYDIL to see if the user was at
home.  Rather than fix all of them, I changed the meaning of %TYDIL to mean
what those programs already thought.  That way I only had to fix ITS to
test for %TYDIL+%TYRLM in those places where it was already testing just
for %TYDIL.

Now it is true that this broke programs that thought that %TYDIL meant
"connected through a line that needs to have its terminal type set", but
since somebody had to lose this argument I decided that these programs were
simply mistaken about the meaning of that bit.

From PGS at AI.AI.MIT.EDU  Wed Apr 30 08:43:20 1986
From: PGS at AI.AI.MIT.EDU (Patrick G. Sobalvarro)
Date: Apr 30 86 02:43:20 EDT
Subject: tty types
In-Reply-To: Msg of Tue 29 Apr 86 08:31:04 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].32866.860430.PGS>

    Date: Tue, 29 Apr 86 08:31:04 EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>

        Date: Mon, 28 Apr 86 15:44:36 EDT
        From: Leigh L. Klotz <KLOTZ at MC>
        I'm connected to MC via the Rolm Data Feature on T25.  My init
        file insists that I'm on a line that already knows its tty type
        and SUPDUP warns me not to net hop.  Perhaps the tty types file
        is broken?

    The TTYTYP file knows that T25 is a ROLM line, and the running ITS on MC at
    this moment does as well.  How does your init file determine if you are on
    a line that "already knows its tty type"?  Perhaps it does something bogus.
    (Note that until recently ROLM lines incorrectly had the %TYDIL bit set in
    their TTYTYP words, perhaps you are noticing an effect of this change.)

I thought %TYDIL was correct for the ROLM lines, since they are exactly
analogous to dialups; one connects terminals of different types to them, so
they should have their tty types reset to something neutral when
disconnected, etc.  And, if we supported it in the 11, they should hang up
after they've been logged out for a while, all those dialup-y things.

From ALAN at AI.AI.MIT.EDU  Tue Apr 29 14:31:04 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Apr 29 86 08:31:04 EDT
Subject: tty types
In-Reply-To: Msg of Mon 28 Apr 86 15:44:36 EDT from Leigh L. Klotz <KLOTZ at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].32475.860429.ALAN>

    Date: Mon, 28 Apr 86 15:44:36 EDT
    From: Leigh L. Klotz <KLOTZ at MC>
    I'm connected to MC via the Rolm Data Feature on T25.  My init
    file insists that I'm on a line that already knows its tty type
    and SUPDUP warns me not to net hop.  Perhaps the tty types file
    is broken?

The TTYTYP file knows that T25 is a ROLM line, and the running ITS on MC at
this moment does as well.  How does your init file determine if you are on
a line that "already knows its tty type"?  Perhaps it does something bogus.
(Note that until recently ROLM lines incorrectly had the %TYDIL bit set in
their TTYTYP words, perhaps you are noticing an effect of this change.)  I
don't know what SUPDUP does, but I do know that the nethop-detection code
was recently rewritten.  Perhaps it is doing something bogus as well.  

If this happens to you again, see if you can figure out just what TTY
variables are the source of the problem.  The output of :TCTYP DESCRIBE
would be a good place to start.

From CENT at AI.AI.MIT.EDU  Mon Apr 28 22:52:29 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Apr 28 86 16:52:29 EDT
Subject: log books
Message-ID: <[AI.AI.MIT.EDU].32120.860428.CENT>

all the KSs have log books. AI's and MX's are on the little DM cabinet.
MD's and ML's are on their CPUs. please write things in them. like "Brain
transplant performed, all is well", or "now running NITS", or "jumpers
attacked with soldering iron, arpanet up". if you don't write things down,
no one will know they happened if you are not available to say so.

From KLOTZ at MC.LCS.MIT.EDU  Mon Apr 28 21:44:36 1986
From: KLOTZ at MC.LCS.MIT.EDU (Leigh L. Klotz)
Date: Apr 28 86 15:44:36 EDT
Subject: No subject
Message-ID: <[MC.LCS.MIT.EDU].897692.860428.KLOTZ>

I'm connected to MC via the Rolm Data Feature on T25.  My init
file insists that I'm on a line that already knows its tty type
and SUPDUP warns me not to net hop.  Perhaps the tty types file
is broken?

From DANIEL at MC.LCS.MIT.EDU  Sat Apr 26 23:35:24 1986
From: DANIEL at MC.LCS.MIT.EDU (Daniel Weise)
Date: Apr 26 86 16:35:24 EST
Subject: No subject
Message-ID: <[MC.LCS.MIT.EDU].895936.860426.DANIEL>

I found MC in a PI level 7 bugpause.  The console line
above the bugpuase was "too many parity errors."  I dumped
to CRASH PARITY and cold booted.

Daniel

From DEVON at MC.LCS.MIT.EDU  Sun Apr 20 19:54:59 1986
From: DEVON at MC.LCS.MIT.EDU (Devon S. McCullough)
Date: Apr 20 86 12:54:59 EST
Subject: No subject
Message-ID: <[MC.LCS.MIT.EDU].889795.860420.DEVON>

MC bughalted sometime around 10am, bugpc/caia uret2+2
so I dumped it into .;CRASH URGH and tried to warm boot
but the KL10 halted immediately so I cold booted it.

From ALAN at AI.AI.MIT.EDU  Fri Apr 18 10:37:32 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Apr 18 86 03:37:32 EST
Subject: devices and names
Message-ID: <[AI.AI.MIT.EDU].28319.860418.ALAN>

The DEVICE directory was getting full due to the proliferation of various
ITS names (past, present, and future), 20X names (for RMTDEV), and various
concatenations of DIR with other device names.  So I increased, yet again,
the knowledge inside the unknown device handler (SYS;ATSIGN DEVICE) itself.

The unknown device handler now loads various foreign filesystem devices
from DEVICE;ATSIGN MLDEV or DEVICE;ATSIGN RMTDEV as appropriate.  Various
DIR devices that deal with the local filesystem are loaded directly from
DEVICE;ATSIGN DIRDEV.  Foreign filesystem DIR devices are loaded from
DEVICE;ATSIGN MLDEV.  (Archive DIR devices are not treated specially.)

Note that the unknown device handler always checks the DEVICE directory for
a JOBDEV file -before- looking at this new built-in knowledge, so it is
easy to do local customizations on each machine.  (Like on AI, the DIRAI
device is loaded from ATSIGN DIRDEV, whereas the default is to load it from
ATSIGN MLDEV.)

Oh yeah.  One of the reasons I was forced to do this is I added two
synonyms for MC and MX.  MC is now known also as "KL" and MX is now also
known as "KS".  The devices KL: and KS: work everywhere as appropriate.
When we swap the names "MC" and "MX" (that is, when MC becomes a KS10, and
MX becomes a KL10), we -won't- swap the names "KL" and "KS".  Thus the file
KL:ALAN;FOO BAR is the same file today as it will be next year, while
MC:ALAN;FOO BAR will be a different one.

(This did have the odd side effect that the NETWRK library now returns
"MIT-KL" as the SIXBIT name for MC...)

From ALAN at MC.LCS.MIT.EDU  Sat Apr  5 03:18:37 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Fri,  4 Apr 86 20:18:37 EST
Subject: MC UNIT 1/PACK 13
In-Reply-To: Msg of Fri  4 Apr 86 17:34:02 EST from Alan Bawden <ALAN at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].874128.860404.ALAN>

    Date: Fri,  4 Apr 86 17:34:02 EST
    From: Alan Bawden <ALAN at MC.LCS.MIT.EDU>
        Date: Fri,  4 Apr 86 02:08:45 EST
        From: Pandora B. Berman <CENT at AI>
        has DEC made any progress in fixing this RP04?...
    apparently they came today and replaced the entire RP04....

And apparently it works for me, although when TK tried to bring it up he
lost.

From ALAN at MC.LCS.MIT.EDU  Sat Apr  5 00:34:02 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Fri,  4 Apr 86 17:34:02 EST
Subject: MC UNIT 1/PACK 13
In-Reply-To: Msg of Fri  4 Apr 86 02:08:45 EST from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].873744.860404.ALAN>

    Date: Fri,  4 Apr 86 02:08:45 EST
    From: Pandora B. Berman <CENT at AI>
    To:   KARENS at AI
    cc:   BUG-ITS at AI
    Re:   MC UNIT 1/PACK 13
    has DEC made any progress in fixing this RP04?...

apparently they came today and replaced the entire RP04.  Whoever brought
MC up after this decided for some reason that it was still broken.  The
console hardcopy doesn't look like they tried very hard, but I wasn't there
so I don't know what really happened...  Perhaps I'll take MC down for a
few minutes tonight and see if I can figure out what the problem is.

From CENT at AI.AI.MIT.EDU  Fri Apr  4 09:08:45 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Fri,  4 Apr 86 02:08:45 EST
Subject: MC UNIT 1/PACK 13
Message-ID: <[AI.AI.MIT.EDU].23885.860404.CENT>

has DEC made any progress in fixing this RP04? i've gone by occasionally
and seen notes promising to come back with more parts, but it's still
offline. this is causing some potential problems: while Alan has made lots
of progress in moving everything vital to AI, he can't move anything from
SECOND: (PK13) because it's offline. maybe you could check on how DEC is
doing on this, and impulse them to further effort if necessary? thanks.