Consolidate license copies

[its.git] / sysdoc / its.obugs2

Copyright (c) 1999 Massachusetts Institute of Technology

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
------------------------------

Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Sep 87 11:29:30 EDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Sep 87 11:26:37 EDT
Mail-From: RICCHIO created at 18-Sep-87 11:19:09
Date: Fri 18 Sep 87 11:19:09-EDT
From: Joe Ricchio <RICCHIO@XX.LCS.MIT.EDU>
Subject: MC/MD maintenance
To: SRA@XX.LCS.MIT.EDU
cc: Ricchio@XX.LCS.MIT.EDU
Message-ID: <12335615391.18.RICCHIO@XX.LCS.MIT.EDU>
ReSent-Date: Fri 18 Sep 87 11:23:07-EDT
ReSent-From: Rob Austein <SRA@XX.LCS.MIT.EDU>
ReSent-To: Postmaster@MC.LCS.MIT.EDU, Liaison@MC.LCS.MIT.EDU,
    Bug-ITS@MC.LCS.MIT.EDU
ReSent-Message-ID: <12335616112.55.SRA@XX.LCS.MIT.EDU>

Rob, Lester has scheduled Tuesday 9-22-87 @ 9AM for PM to the RP06
drives. Hope this is agreeable wiht you. If not please advise. Thanks

        Joe
-------

\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  7 Aug 87 06:34:11 EDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  7 Aug 87 04:26:56 EDT
Date: Thu, 6 Aug 1987  21:52 EDT
Message-ID: <SRA.12324458461.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   barmar@THINK.COM
Cc:   info-its@MC.LCS.MIT.EDU
Subject: Unix catching up to ITS
In-reply-to: Msg of 6 Aug 1987  14:00-EDT from barmar@Think.COM

No, that's the USR: device.  But they've invented the JOB: device too,
something called "portals" I think.

As Noel Chiappa said when talking about ITS and Multics, it's really
kind of scary to think that we are just now catching up to what we
were able to do twenty years ago.

\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  6 Aug 87 19:01:31 EDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU  6 Aug 87 18:06:10 EDT
Return-Path: <barmar@Think.COM>
Received: from godot.think.com by Think.COM; Thu, 6 Aug 87 14:00:44 EDT
Received: by godot.think.com; Thu, 6 Aug 87 14:00:39 EDT
Date: Thu, 6 Aug 87 14:00:39 EDT
From: barmar@Think.COM
Message-Id: <8708061800.AA08725@godot.think.com>
To: info-its@mc.lcs.mit.edu
Subject: Unix catching up to ITS

I read the following in the Usenet newsgroup comp.unix.wizards (== to
the Arpanet mailing list UNIX-WIZARDS).  AT&T has finally "invented"
the JOB: device!

Article 3409 of comp.unix.wizards:
Path: think!husc6!seismo!mnetor!utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.unix.wizards
Subject: /proc, /n/face
Message-ID: <8285@utzoo.UUCP>
Date: 10 Jul 87 19:06:20 GMT
References: <7879@brl-adm.ARPA> <2211@bunker.UUCP>, <6043@brl-smoke.ARPA>, <8244@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 42

> V8 /proc preserves the semantics of a normal Unix directory setup *exactly*,
> unless I missed something subtle when I read the code.  My impression is that
> /n/face does likewise.  In both cases the directory hierarchy is actually a
> figment of the kernel's imagination, but it is a consistent figment with the
> same semantics as normal directories.

Several people have asked what this is about, so I suppose I should elaborate
a bit.  This stuff has been presented in papers at Usenix conferences, but
not everybody's familiar with those.

/proc is V8's replacement for the ptrace() system call and related things.
It's a slightly-odd type of file system.  Once mounted, it looks like a
single directory containing a bunch of files with numeric names.  If you
open (say) file "12345", you are looking at the address space of process
number 12345.  Writes into the file are writes into the address space.
There are ioctls for things like stopping and starting the process, sending
it signals, etc.  Access to the files is naturally subject to the standard
Unix file-permission system.  The whole thing is actually a figment of the
kernel's imagination, with the "directory" manufactured on the fly whenever
someone tries to read it, and operations on the "files" turned into the
corresponding operations on the processes.  Apart from being cleaner than
ptrace(), /proc is also faster.

[description of /n/face deleted]

In both cases, these odd filesystems look exactly like real ones, down to
things like "." and ".." entries in the directories.  You can use all the
standard Unix tools to operate on them.

At least one System V implementation of /proc exists inside AT&T, but it
hasn't made it into any released software that I know of.  I believe /n/face
is strictly a V8ism at the moment.
-- 
Mars must wait -- we have un-         Henry Spencer @ U of Toronto Zoology
finished business on the Moon.     {allegra,ihnp4,decvax,pyramid}!utzoo!henry



\1f
Date: Sun,  2 Aug 87 20:34:10 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  IP routing table
To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU,
    JNC@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 15 Jul 87 01:55 EDT from Alan Bawden <ALAN@AI>
Message-ID: <236463.870802.ALAN@AI.AI.MIT.EDU>

    Date: Wed, 15 Jul 87 01:55 EDT
    From: Alan Bawden <ALAN at AI>
    ...  Try out:

      :ALAN;REDRCT

    (If anyone can think of a good directory for this to live on other than
    ALAN, let me know.)...

It finally occured to me that the right directory for something like this
is the one named ".".  (Remember ":.;BOOT11" on the KL?)  So make that:

  :.;REDRCT

to fool with IP routing.
\1f
Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by AI.AI.MIT.EDU 23 Jul 87 09:17:08 EDT
Received: from ROCKY-MOUNTAINS.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123996; Thu 23-Jul-87 08:59:35 EDT
Date: Thu, 23 Jul 87 08:55 EDT
From: Allan C. Wechsler <ACW@WAIKATO.S4CC.Symbolics.COM>
Subject: Musings on history
To: tk@STONY-BROOK.SCRC.Symbolics.COM,
    marker%random.s1.gov@mordor.s1.gov, ED@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, SIPB@mc.lcs.mit.edu
In-Reply-To: <870722140244.3.TK@CUCKOO.SCRC.Symbolics.COM>
Message-ID: <870723085519.1.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>

    Date: Wed, 22 Jul 87 14:02 EDT
    From: Tom Knight <tk@STONY-BROOK.SCRC.Symbolics.COM>
        Date: Tue, 21 Jul 87 16:38:22 PDT
        From: marker%random.s1.gov@mordor.s1.gov
        >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971.  This doesn't
        win but is still pretty impresive.

    especially since it wasn't backed up!

At least when I was a member, we backed up >nbdd> "by hand"
periodically.  We actually had to use those backup tapes occasionally.

\1f
Date: Thu, 23 Jul 87 00:26:56 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: MC crash
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <231258.870723.CENT@AI.AI.MIT.EDU>

it complained about IMPOS. dumped to CRASH;IMPOS LOSS.
\1f
Received: from nrl.arpa (TCP 3200600010) by AI.AI.MIT.EDU 22 Jul 87 17:33:32 EDT
Date: 22 Jul 87 16:08:00 EST
From: "VA::BAL" <bal%va.decnet@nrl.arpa>
Subject:  Musings on history
To: "tk" <tk@scrc-stony-brook.arpa>
cc: marker%random.s1.gov@mordor.s1.gov,ed@ai.ai.mit.edu,
    bug-its@ai.ai.mit.edu,sipb@athena.mit.edu
Reply-To: "VA::BAL" <bal%va.decnet@nrl.arpa>

Reply-To: bal%va.decnet@nrl.arpa
Full-Name: Brian A. LaMacchia
Address: Code 4771, Naval Research Laboratory
Address: 4555 Overlook Ave. SW, Washington, DC  20375-5000
Phone: (202) 767-3066


When this challenge was originally posted, Census data was mentioned.
Well, although it may not be the winner, the Census Bureau puts up a
good fight.  Here are the high points:

1920 Census Data was originally tabulated on Hollerith cards, but those
probably no longer exist.  1920 records are on microfilm (which I assume
doesn't qualify).  However, some of it is available on tape (see below).

The 1950 Census used a Univac I (I think) to count the population.  Data
from this census was originally written to Univac metal tape.  Some of
these tapes still exist, but it's unclear whether or not the bits on
them are still readable.

The 1960 Census used FOSDIC (Form Optical Scanner Direct Input to
Computer, or something like that) to convert all the forms to microfilm,
and then to bits.  These tapes still exist.

So it looks like 1950 (which wasn't tabulated until 1954 or so) or 1960
is the best bet.  However, you can get from the Census Bureau tapes
containing data summaries for each Census since 1920.  These are 1%
samples of the population, which don't contain any personal data, just
averages.  However, some of the numbers are from 1920, so I guess that's
"maintained data."

                                --Brian LaMacchia
                                  bal%va.decnet@nrl.arpa (current)
                                  balamac@athena.mit.edu
------
\1f
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 22 Jul 87 14:28:37 EDT
Received: from CUCKOO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 196728; Wed 22-Jul-87 12:58:55 EDT
Date: Wed, 22 Jul 87 14:02 EDT
From: Tom Knight <tk@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Musings on history
To: marker%random.s1.gov@mordor.s1.gov, ED@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, SIPB@mc.lcs.mit.edu
In-Reply-To: <8707212338.AA00695@random.s1.gov>
Message-ID: <870722140244.3.TK@CUCKOO.SCRC.Symbolics.COM>

    Date: Tue, 21 Jul 87 16:38:22 PDT
    From: marker%random.s1.gov@mordor.s1.gov

    >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971.  This doesn't
    win but is still pretty impresive.

especially since it wasn't backed up!

\1f
Received: from random.s1.gov (TCP 20003600056) by AI.AI.MIT.EDU 21 Jul 87 19:41:51 EDT
Received: by random.s1.gov id AA00695; Tue, 21 Jul 87 16:38:22 PDT
        id AA00695; Tue, 21 Jul 87 16:38:22 PDT
Date: Tue, 21 Jul 87 16:38:22 PDT
From: marker%random.s1.gov@mordor.s1.gov
Message-Id: <8707212338.AA00695@random.s1.gov>
To: ED@ai.ai.mit.edu
Cc: INFO-EXPLORER@ai.ai.mit.edu, BUG-ITS@ai.ai.mit.edu, SIPB@mc.lcs.mit.edu
In-Reply-To: Ed Schwalenberg's message of Sat, 18 Jul 87 00:20:05 EDT <228939.870718.ED@AI.AI.MIT.EDU>
Subject: Musings on history

>nbdd>sipb>pl>o>xind was compiled on November 11th, 1971.  This doesn't
win but is still pretty impresive.

                                        Charley
\1f
Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 18 Jul 87 18:26:30 EDT
Received: from nietzche by Think.COM via CHAOS; Sat, 18 Jul 87 18:27:31 EDT
Date: Sat, 18 Jul 87 18:25 EDT
From: Barry Margolin <barmar@think.com>
Subject: Musings on history
To: Ed Schwalenberg <ED@ai.ai.mit.edu>
Cc: INFO-EXPLORER@ai.ai.mit.edu, BUG-ITS@ai.ai.mit.edu, SIPB@mc.lcs.mit.edu
In-Reply-To: <228939.870718.ED@AI.AI.MIT.EDU>
Message-Id: <870718182532.2.BARMAR@NIETZSCHE.THINK.COM>

I think Roger Roach still has some tape archives from CTSS.

  barmar
\1f
Date: Sat, 18 Jul 87 00:20:05 EDT
From: Ed Schwalenberg <ED@AI.AI.MIT.EDU>
Subject: Musings on history
To: INFO-EXPLORER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
    SIPB@MC.LCS.MIT.EDU
Message-ID: <228939.870718.ED@AI.AI.MIT.EDU>

I just saw an old file creation date on AI, which led to the following thought:

        Those bits are "still around", despite the fact that the hardware
        they live on wasn't invented at the time the bits were written.

Which leads to a question:

        What is the oldest "continuously maintained" set of bits in the 
        computer universe?

Does Grace Hopper still have artillery aiming data on her Macintosh?  Did the
Census Department copy their punched cards from the 1920 census onto CD/ROM?
By continously maintained, I mean that the data has been used regularly since
its creation, or at least kept around on some form of reasonably
random-access memory in the hope or expectation that it would be used.  Thus,
the sine lookup table diode ROM in the artillery aiming machine doesn't count
if the machine doesn't still work, but AI:SYSEN2;PRUFD > does, even though it
hasn't actually been assembled in 15 years or so, and the object code hasn't
been run in 2.  And of course, by data I'm referring to "digital" information.
Rosetta stones, Dead Sea scrolls and Enrico Caruso records don't count, but
the first stock ticker tape might.

Any interesting candidates?  Send me your votes.  (The file mentioned above
dates from 28 February 1971, and is the oldest file on AI whose creation
date is believable.)
\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jul 87 01:59:15 EDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Jul 87 01:55:51 EDT
Date: Wed, 15 Jul 87 01:55:10 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  IP routing table
To: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
    JNC@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 14 Jul 87 13:40:44 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <227628.870715.ALAN@AI.AI.MIT.EDU>

    Date: Tue, 14 Jul 87 13:40:44 EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
        Date: Tue, 14 Jul 87 02:44:52 EDT
        From: J. Noel Chiappa <JNC at MC.LCS.MIT.EDU>
        You know, I wish there were some tools to manipulate this table....,
        some command that could delete routes, or modify the entyry, could be a
        real win.
    This sounds like an easy one night hack for someone.  I'd do it if I was
    certain just what kinds of commands were desirable.  Stop by my office some
    day, and spend 5 minutes helping me design it.

I was in the mood for a little hack, so I wrote one.  (Source on
SYSNET;REDRCT.)  Try out:

  :ALAN;REDRCT

(If anyone can think of a good directory for this to live on other than
ALAN, let me know.)  With no JCL it will remind you of its usage as
follows:

Usage is:

  :REDRCT <old gateway> <optional new gateway>

Gateways can be given as hostnames, or in decimal octet form (as in
"10.0.0.77").  If the new gateway is omitted, REDRCT will simply pick a
likely-looking gateway from ITS's list of main gateways.

REDRCT will ask for confirmation once after it interprets its command, to be
sure it properly understood what you asked it to do.  Then for each routing
table entry it finds that uses the old gateway, it will ask for confirmation
before clobbering it with the new gateway.


\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 87 14:16:39 EDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Jul 87 13:55:46 EDT
Date: Tue, 14 Jul 87 13:40:44 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  IP routing table
To: JNC@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 14 Jul 87 02:44:52 EDT from J. Noel Chiappa <JNC at MC.LCS.MIT.EDU>
Message-ID: <227392.870714.ALAN@AI.AI.MIT.EDU>

    Date: Tue, 14 Jul 87 02:44:52 EDT
    From: J. Noel Chiappa <JNC at MC.LCS.MIT.EDU>
    You know, I wish there were some tools to manipulate this table....,
    some command that could delete routes, or modify the entyry, could be a
    real win.

This sounds like an easy one night hack for someone.  I'd do it if I was
certain just what kinds of commands were desirable.  Stop by my office some
day, and spend 5 minutes helping me design it.


\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 87 02:45:32 EDT
Date: Tue, 14 Jul 87 02:44:52 EDT
From: "J. Noel Chiappa" <JNC@MC.LCS.MIT.EDU>
Subject: IP routing table
To: BUG-ITS@MC.LCS.MIT.EDU
cc: JNC@MC.LCS.MIT.EDU
Message-ID: <258985.870714.JNC@MC.LCS.MIT.EDU>

        You know, I wish there were some tools to manipulate this
table. For instance, the main gateway to a net went down, and
I wanted to switch to the backup; however, ITS doesn't discover
dead gateway, and you have to make the switch manually. There's
no tool to do this; I had to grovel in IPGWTN: for the right
netry (after doing the conversion to octal) and bash it by hand
(it picked up the right gateway from a Redirect, so it wasn't
totally by hand). Still, some command that could delete routes,
or modify the entyry, could be a real win.

        NOel

\1f
Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 30002424555) by AI.AI.MIT.EDU  5 Jun 87 19:51:37 EDT
Received: from LARRY-BIRD.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89235; Fri 5-Jun-87 19:45:54 EDT
Date: Fri, 5 Jun 87 18:03 EDT
From: Alan@AI.AI.MIT.EDU
Subject: Foo
To: Bug-Networks@ALDERAAN.SCRC.Symbolics.COM, Bug-ITS@ai.ai.mit.edu
cc: Customer-Reports@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870605194544.7.PALTER@LARRY-BIRD.SCRC.Symbolics.COM>
Supersedes: <870605180324.1.ALAN@PIGPEN.AI.MIT.EDU>,
            <870605194540.6.PALTER@LARRY-BIRD.SCRC.Symbolics.COM>
Redirected-Date: Fri, 5 Jun 87 19:45 EDT
Redirected-by: Palter@ALDERAAN.SCRC.Symbolics.COM
Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")
                         (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
Fonts: CPTFONT, CPTFONTCB, CPTFONTI

[This message has been redirected:
  Looks like something either on the LispM or AI didn't properly cleanup from your abort.
  I'm quite certain it's not Zmail as it has the necessary UNWIND-PROTECTs.
    Bug-Zmail has been removed;
    Bug-Networks, Bug-ITS@ai.ai.mit.edu have been added.]

In Symbolics 3650 Zmail in Genera 7.1, Hacks 3.0, IP-TCP 52.16,
ILA-NFS 3.2, 7-1-Patches 1.15, MAC 11.1, Conversion Tools 12.4,
Pascal 25.10, Experimental X-Window-System 17.4,
Experimental Illustrate 11.0, TeX 1.0, LaTeX 1.0, SliTeX 1.0, YTeX 1.0,
microcode 3650-MIC 396, FEP 206, FEP0:>g206-lisp.flod(14),
FEP0:>g206-loaders.flod(14), FEP0:>g206-debug.flod(4),
FEP0:>g206-info.flod(14), Machine serial number 30096,
Patches for conversion tool. (from SYS:CONVERSION-TOOLS;PATCHES.LISP.29), on Lisp Machine Pigpen:

I got this while trying to do the DESCRIBE that Gary requested.  I had just
previously inadvertently Aborted out of the error he wanted me to
investigate, and the next time I did a "G" to reproduce the problem again,
this happened:

\ 61Error: Can't have more than one directory open at a time
       For AI: ALAN; ALAN _ZMAIL
\ 60While in the function (FLAVOR:METHOD :COMMAND FS:HOST-UNIT) \18 FS:DIRECTORY-CHAOS \18 (FLAVOR:METHOD :DIRECTORY-STREAM FS:QFILE-ACCESS-PATH)

The condition signalled was FS:QNOT-ENOUGH-RESOURCES

\ 61(FLAVOR:METHOD :COMMAND FS:HOST-UNIT)\ 60:  (P.C. = 227)
   Arg 0 (SELF): #<HOST-UNIT 163637553>
   Arg 1 (SYS:SELF-MAPPING-TABLE): FS:HOST-UNIT
   Arg 2 (FLAVOR::.GENERIC.): :COMMAND
   Arg 3 (FS:MARK-P): NIL
   Arg 4 (FS:STREAM-OR-HANDLE): (:CREATE "I6770")
   Local 4 (FS:STREAM-OR-HANDLE): "I6770"
   Arg 5 (FS:SIMPLE-P): NIL
   Arg 6 (FS:WHOSTATE): "Directory"
   Rest arg (FS:COMMANDS): ("DIRECTORY" "" "" "" "" #/Return "AI: ALAN; ALAN _ZMAIL" #/Return)
   Local 8 (FS:HANDLE): "I6770"
   Local 9 (FS:STREAM): NIL
   Local 10 (FS:PKT): #<Chaos Packet 6201761>
   Local 11 (FS:SUCCESS): NIL
   Local 12 (STRING): "I6770 ERROR NER F Can't have more than one directory open at a time"
   Local 13 (FS:TRANSACTION-ID): "T6773"
   Local 14 (FS:CREATE-P): T
   Local 15: #<CASE-HANDLER 120033346>
   Local 16: (#<CASE-HANDLER 160200643> #<LEXICAL-CLOSURE (:INTERNAL ZWEI:READ-NEW-MAIL-TOP-LEVEL 1) 230300536> #<LEXICAL-CLOSURE (:INTERNAL ** 0) 230300101>)
   Local 17: (#<CASE-HANDLER 120033346> #<CASE-HANDLER 160200643> #<LEXICAL-CLOSURE (:INTERNAL ZWEI:READ-NEW-MAIL-TOP-LEVEL 1) 230300536> #<LEXICAL-CLOSURE (:INTERNAL ** 0) 230300101>)
   Special DBG:*BOUND-HANDLERS*: (#<CASE-HANDLER 120033346> #<CASE-HANDLER 160200643> #<LEXICAL-CLOSURE (:INTERNAL ZWEI:READ-NEW-MAIL-TOP-LEVEL 1) 230300536> #<LEXICAL-CLOSURE (:INTERNAL ** 0) 230300101>)

\ 61FS:DIRECTORY-CHAOS\ 60:  (P.C. = 141)
   Arg 0 (FS:ACCESS-PATH): #<ITS-QFILE-ACCESS-PATH AI using QFILE 163637523>
   Arg 1: #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
   Arg 2 (FS:OPTIONS): NIL
   Special FS:*COMMAND-ERROR-ARGUMENTS*: (:OPERATION :DIRECTORY-LIST)
   Special FS:*COMMAND-PATHNAME*: #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">

\ 61(FLAVOR:METHOD :DIRECTORY-STREAM FS:QFILE-ACCESS-PATH)\ 60:  (P.C. = 6)
   Arg 0 (SELF): #<ITS-QFILE-ACCESS-PATH AI using QFILE 163637523>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor FS:QFILE-ACCESS-PATH 250375074>
   Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-STREAM
   Arg 3 (CL:PATHNAME): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
   Arg 4 (FS:OPTIONS): NIL

\ 61(FLAVOR:METHOD :DIRECTORY-LIST FS:DIRECTORY-STREAM-FILE-ACCESS-PATH-MIXIN)\ 60:  (P.C. = 13)
   Arg 0 (SELF): #<ITS-QFILE-ACCESS-PATH AI using QFILE 163637523>
   Arg 1 (SYS:SELF-MAPPING-TABLE): FS:DIRECTORY-STREAM-FILE-ACCESS-PATH-MIXIN
   Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-LIST
   Arg 3 (CL:PATHNAME): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
   Arg 4 (FS:OPTIONS): (:SORTED)

\ 61(FLAVOR:METHOD :DIRECTORY-LIST FS:ACTIVE-PATHNAME-MIXIN)\ 60:  (P.C. = 12)
   Arg 0 (SELF): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor FS:ACTIVE-PATHNAME-MIXIN 220012056>
   Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-LIST
   Arg 3 (FS:OPTIONS): (:SORTED)

\ 61FS:DIRECTORY-LIST\ 60:  (P.C. = 100)
   Arg 0 (FS:FILENAME): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
   Rest arg (FS:OPTIONS): (:SORTED)

\ 61(FLAVOR:METHOD MAKE-INSTANCE ZWEI:INBOX-BUFFER)\ 60:  (P.C. = 110)  \ 62(from SYS:7-1-PATCHES;PATCH;7-1-PATCHES-1-6)
\ 60   Arg 0 (SELF): #<ITS-INBOX-BUFFER "AI: ALAN; ALAN MAIL for AI: ALAN; ALAN BABYL" 424115702>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:INBOX-BUFFER 220004106>
   Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION MAKE-INSTANCE 6700025>
   Rest arg: (:PARENT-BUFFER #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435> :PATHNAME #<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)

\ 61(FLAVOR:COMBINED MAKE-INSTANCE ZWEI:ITS-INBOX-BUFFER)\ 60:  (P.C. = 11)
   Arg 0 (SELF): #<ITS-INBOX-BUFFER "AI: ALAN; ALAN MAIL for AI: ALAN; ALAN BABYL" 424115702>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ITS-INBOX-BUFFER 220004052>
   Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION MAKE-INSTANCE 6700025>
   Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (:PARENT-BUFFER #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435> :PATHNAME #<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)

\ 61MAKE-INSTANCE\ 60:  (P.C. = 572)  \ 62(from SYS:PATCH;SYSTEM-349-177)
\ 60   Arg 0 (SYS:FLAVOR-NAME): ZWEI:ITS-INBOX-BUFFER
   Rest arg (FLAVOR::INIT-OPTIONS): (:PARENT-BUFFER #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435> :PATHNAME #<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)

\ 61(:INTERNAL (FLAVOR:METHOD ZWEI:READ-NEW-MAIL ZWEI:FILE-MAIL-BUFFER) 0 ZWEI:NEW-INBOXES)\ 60:  (P.C. = 27)
   Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): #<DTP-LOCATIVE 230300575>

\ 61(FLAVOR:METHOD ZWEI:READ-NEW-MAIL ZWEI:FILE-MAIL-BUFFER)\ 60:  (P.C. = 76)
   Arg 0 (SELF): #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:FILE-MAIL-BUFFER 220167476>
   Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION ZWEI:READ-NEW-MAIL 7011011>
   Arg 3 (ZWEI:INBOX-PATHNAMES): (#<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)

\ 61ZWEI:READ-NEW-MAIL-TOP-LEVEL\ 60:  (P.C. = 67)

\ 61ZWEI:COM-GET-NEW-MAIL-FROM-INBOX\ 60:  (P.C. = 7)

\ 61(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)\ 60:  (P.C. = 16)
   Arg 0 (SELF): #<PROCESS Main Zmail Window 15056221>
   Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS
   Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL 6704641>
   Arg 3 (SI:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL ZWEI:COMMAND-EXECUTE 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY) 230300474>
   Rest arg: NIL

\ 61ZWEI:COMMAND-EXECUTE\ 60:  (P.C. = 57)
   Arg 0 (ZWEI:COMMAND): ZWEI:COM-GET-NEW-MAIL-FROM-INBOX
   Arg 1 (ZWEI:CHAR): #/g
\ 62   --Defaulted args:--
\ 60   Arg 2 (ZWEI:PREFIX-CHAR): NIL
   Arg 3 (ZWEI:HOOK-LIST): NIL

\ 61ZWEI:ZMAIL-COMMAND-EXECUTE\ 60:  (P.C. = 6)
   Arg 0: ZWEI:COM-GET-NEW-MAIL-FROM-INBOX

\ 61(FLAVOR:METHOD :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)\ 60:  (P.C. = 7)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
   Arg 3 (ZWEI:CH): #/g

\ 61(:INTERNAL (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 0)\ 60:  (P.C. = 10)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
   Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g)

\ 61(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)\ 60:  (P.C. = 43)
   Arg 0 (SELF): #<PROCESS Main Zmail Window 15056221>
   Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS
   Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL 6704641>
   Arg 3 (SI:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL ** 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY) 230300355>
   Rest arg: NIL

\ 61(FLAVOR:WHOPPER :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-COMMAND-LOOP-MIXIN)\ 60:  (P.C. = 31)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-COMMAND-LOOP-MIXIN 200000464>
   Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 0) 150706134>
   Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 4 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
   Arg 5 (ZWEI:CHAR): #/g

\ 61(:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0)\ 60:  (P.C. = 13)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
   Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g)

\ 61(FLAVOR:WHOPPER :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)\ 60:  (P.C. = 21)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 150706121>
   Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 4 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
   Arg 5 (ZWEI:CHAR): #/g

\ 61(FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)\ 60:  (P.C. = 12)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
   Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g)

\ 61(FLAVOR:METHOD :COMMAND-LOOP ZWEI:ZMAIL-FRAME)\ 60:  (P.C. = 130)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP

\ 61(:INTERNAL (FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME) 0)\ 60:  (P.C. = 17)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP
   Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): NIL

\ 61(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)\ 60:  (P.C. = 40)
   Arg 0 (SELF): #<PROCESS Main Zmail Window 15056221>
   Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS
   Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL 6704631>
   Arg 3 (SI:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL ** 1 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 230300103>
   Rest arg: NIL

\ 61(FLAVOR:WHOPPER :COMMAND-LOOP ZWEI:ZMAIL-COMMAND-LOOP-MIXIN)\ 60:  (P.C. = 65)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-COMMAND-LOOP-MIXIN 200000464>
   Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME) 0) 150705665>
   Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 4 (FLAVOR::.GENERIC.): :COMMAND-LOOP

\ 61(FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME)\ 60:  (P.C. = 562)
   Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
   Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP
   Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): NIL

\ 61ZWEI:ZMAIL-PROCESS-TOP-LEVEL\ 60:  (P.C. = 104)
   Arg 0 (ZWEI:WINDOW): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>

\ 61SI:PROCESS-TOP-LEVEL\ 60:  (P.C. = 45)
   Arg 0 (IGNORE): NIL

   Special FS:%FILE-COMMAND-OPCODE: 200
   Special FS:*DONT-HACK-LOGIN*: NIL

\1f
Date: Tue,  5 May 87 18:20:25 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Datapoint on TCP buffer lossage
To: BUG-ITS@AI.AI.MIT.EDU
cc: JTW@AI.AI.MIT.EDU
Message-ID: <195885.870505.ALAN@AI.AI.MIT.EDU>

The forget-to-free-the-SYN-packet problem than happens on AI and MC so
much, really -does- also happen on the KL!  After 12 days running, the KL
has managed to lose just two packets in this manner.  Perhaps the fact that
the KL is so much faster explains why it happens so rarely there?
\1f
Date: Tue,  5 May 87 08:25:18 EDT
From: John Wilson <JOHNW@AI.AI.MIT.EDU>
To: INFO-ITS@AI.AI.MIT.EDU
Message-ID: <195618.870505.JOHNW@AI.AI.MIT.EDU>

Please add me to the mailing list.

        thanks,    John Wilson
\1f
Date: Tue,  5 May 87 05:38:08 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: MD up again
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <195595.870505.CENT@AI.AI.MIT.EDU>

since MD is up again, and doesn't show any immediate signs of disk lossage,
i have added it back to the *MSGS and INQUIR update facilities.
\1f
Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU  4 May 87 04:27:24 EDT
Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 4 May 87 01:23:28 PDT
Date: Mon, 4 May 87 00:05:09 PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
Subject: KS10 power fail
To: BUG-ITS@AI.AI.MIT.EDU
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12299611731.6.MRC@PANDA>

Hi.  I was reading some of the old BUG-ITS mail and saw some messages
about power fail recovery.  Forget about it on the KS10.  Although it
was originally going to be included (and I think the prototype machine
had it), production KS's don't have any battery backup for the MS10
memory.  Since MS10 is MOS based, once the power goes it gets nuked.

The best thing ITS can do is with a power fail interrupt is to quiet
down any disk traffic as quickly as possible (certainly nuke all reads
and any writes that aren't essential to prevent filesystem damage) and
halt.

Since KS10 power supplies are made by a real vendor and not DEC, KS's
don't see trivial little glitches.  The power has to be off for some
time, something like 250ms, for a KS to croak.  My KS has survived
power glitches that reset the digital clocks and zapped the TV!  So,
if you get a power fail interrupt there is a good chance that the
disks are already in the process of shutdown.
-------
\1f
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 20 Apr 87 16:17:00 EDT
Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 3302;
          Mon, 20 Apr 87 11:43:53 EDT
Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 6677;
          Mon, 20 Apr 87 17:43:46 EDT
Message-ID:  <247761@QZCOM>
In-Reply-To: <187812.870420.CENT@AI.AI.MIT.EDU>
Date:        20 Apr 87 16:16 +0200
From:        "Peter Lothberg STUPI" <ROLL@QZCOM.BITNET>
Reply-To:    "Peter Lothberg STUPI" <ROLL@QZCOM.BITNET>,
             "ITS bugs mailing list" <ITSBUGS@QZCOM.BITNET>
To:          "ITS bugs mailing list" <ITSBUGS@QZCOM.BITNET>
cc:          BUG-ITS@AI.AI.MIT.EDU
Subject:     alas, poor SAIL-KA

Mark Crispin bought the KA10 with the BBN pager. He wanted to
have a KA10 front panel, and we took the pager to attach to one
of our working KA10:s.
\1f
Date: Mon, 20 Apr 87 00:24:18 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: alas, poor SAIL-KA
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <187812.870420.CENT@AI.AI.MIT.EDU>

i sent LES@SAIL some info about old MAC PDP-10s....
----------
Date: 16 Apr 87  1253 PDT
From: Les Earnest <LES@SAIL.STANFORD.EDU>
Subject: re: PDP10 history project    
To:   CENT@AI.AI.MIT.EDU    
....
Incidentally, the Computer Museum already has a PDP-6 -- we gave them
ours.  At the time I thought that it was the only one left in the world.
We recently killed our KA10 and sold it to a collector for $500, including
the BBN pager.....
\1f
Date: Fri, 17 Apr 87 08:41:07 EDT
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
Subject: Same old Shit
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <186662.870417.GUMBY@AI.AI.MIT.EDU>

(as of today you can't say that on the radio any more)
AI crashed with the usual "Freeing packet still in use!"
See crash PKTFRE if you care
\1f
Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 16 Apr 87 04:36:44 EDT
Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Thu, 16 Apr 87 01:31:16 PDT
Date: Thu, 16 Apr 87 00:29:35 PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
Subject: Re: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262)
To: ALAN@AI.AI.MIT.EDU
cc: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
In-Reply-To: <185625.870416.ALAN@AI.AI.MIT.EDU>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12294897588.8.MRC@PANDA>

I am involved peripherally with this project.

There is NO attempt to shortchange or ignore ITS, WAITS, and TENEX.

But!!  We will need *papers* from people in these communities in order to
fairly cover these operating systems.

Otherwise, I will write up something really brief.  For ITS, in a few short
paragraphs I'll talk about DDT as the command decoder, PCLSR'ing, and the
environment that led to the creation of EMACS.

I think such coverage WOULD shortchange ITS.  There are lots of important
concepts that can and should be discussed in detail -- PCLSR'ing, ITS virtual
memory (not as good as TOPS-20/Tenex, but quite advanced for its time),
canonical terminals/SUPDUP/CRTSTY, symbolic system calls, CHEOPS, Knight TV
system, ...

TECO and TECO-based editors should be a paper in itself.
-------
\1f
Date: Thu, 16 Apr 87 02:04:00 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262)
To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Message-ID: <185625.870416.ALAN@AI.AI.MIT.EDU>

The following message was forwarded to me (it was originally sent to AIList
I think) with the suggestion that I should redistribute it to whatever
mailing lists of PDP-10 hackers I knew of.  I don't know anything more
about this than what is revealed here.

It does kind of sound like these guys are planning on writing a history of
PDP-10's that only mentions TOPS10 and TOPS20 and fails to consider ITS and
WAITS and perhaps shortchanges TENEX.  But I suspect that this is merely a
shortcoming of this announcement.

Date: 16 Mar 1987 1311-EST
From: "Joe Dempster, DTN: 336.2252 AT&T: 609.665.8711" <DEMPSTER@MARLBORO.DEC.COM>
Subject: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262)

This message originates from 2 sources:

        Les Earnest
        Computer Science Department
        STANFORD UNIVERSITY
        Stanford, CA  94305
        415.723.9729
        ARPA: LES@SAIL.STANFORD.EDU

        Joe Dempster
        DIGITAL EQUIPMENT CORPORATION
        6 Cherry Hill Executive Campus
        Route 70
        Cherry Hill, NJ  08002
        609.665.8711
        ARPA: DEMPSTER@MARLBORO.DEC.COM (MARKET)

The goal of this project is to publish an analysis and history of
the evolution, implementation and use of Digital's 36 bit systems.
This period began with the PDP-6 in 1964 and continues today with
TOPS 10/20 development, which is scheduled to end in 1988.

We are working aggressively to finish the project, and have it
published, by March/April 1988.  This will require that the
completed manuscript be ready to go into the publication cycle
by August 1987!

The project will attempt to answer the following questions:

        1. In what markets/applications were these systems used?

        2. Who were the users of these systems and what impact did
           roughly 2,500 TOPS 10/20 systems have on their organizations?

        3. Who were the principle system architects of these systems?
           What features, and if there had been sufficient time to
           implement them, would have significantly improved the
           architecture?

        4. What impact did the decision to continue to examine design
           extensions to the architecture have on the usefulness and
           acceptability of these systems.  This is in contrast to a
           more common practice today to work from a detailed design
           specification, sometimes dated, building follow-on systems
           which provide increased performance through the use of new
           component technologies and packaging techniques.

        5. What part of the overall design (TOPS10/20) was technology
           dependent and what can still be considered "unequaled" in
           relation to other computer architectures still undergoing
           active development?

        6. What type of development environment (both HW and SW)
           supported and contributed to the evolution of 36 bit
           systems?

        7. What influence did TOPS 10/20 have on other vendors system
           development?

This history will undoubtedly be assembled from many sources and
participants.  Some information will be anecdotal; there will be
interviews with the people involved (users and developers) and technical
papers will be solicited.  Of course there will also be the packaging
and assembly of facts as we see them.

The result will hopefully have sufficient depth to serve as:

        1. An introductory or advanced text on system design and
           hardware/system software implementation.

        2. A analysis of the success and difficulties of marketing
           complex systems into a very crowded market of competing
           alternatives.

        3. A catharsis for those of us who have contributed to the
           development and use these systems and who will now move
           onto new computing architectures and opportunities.

In addition to interviewing directly 25-50 developers, users and
product managers we will continue to work to identify contributors
and significant events up to when the final draft is submitted to
the publisher.  Two "topics" are already under development:

        1. Rob Gingell from SUN is working on a paper which looks
           at extensions to TOPS 20 which would have enhanced its
           capabilities.

        2. Frank da Cruz and Columbia are summarizing 10 years of
           experience and development of TOPS 20 systems.  Some
           effort will also be made to detail the process which
           lead to their selection of a follow-on architecture to
           TOPS 20.

There is a need to develop additional topics which represent the
use and application of the technology (TOPS 10/20) in other areas.
Specific recommendations are welcome as are proposals to develop
them.  A short abstract should accompany any such proposal.  Every
effort will be made to work with individuals or organizations
interested in making such a contribution.

There will be a standalone (no network connections) DECSYSTEM 2020
(YIPYIP) dedicated to supporting the project.  This system has a 3
line hunt group, with all lines accessible from a single number
(201.874.8612).

Both YIPYIP and MARKET will have "public" directories for remote
login (<log>DEMPSTER.PROJECT-10262 <Password>LCGLCG).  MARKET can
be accessed by modem (617.467.7437), however disk quota is limited.
MARKET's primary purpose <DEMPSTER.PROJECT-10262> is ARPAnet TELNET
access.  YIPYIP is a dedicated PROJECT-10262 system.  MAIL can also
be sent to DEMPSTER on either system.

YIPYIP and MARKET will keep a running summary of ideas and comments
up on Columbia's BBOARD software.  KERMIT also runs on each system
for uploads.

SAIL.STANFORD.EDU will support ARPAnet transfers to a "public" area:

        FTP<ret>
        CONNECT SAIL.STANFORD.EDU<ret>
        SEND AFN.EXT<ret>
        DSK: AFN.EXT [PUB,LES]<ret>

SAIL runs WAITS, an operating system similiar to TOPS 10.  File
names are limited to 6 characters and extensions limited to 3.


Implementation details:

        1. User input is welcomed and desired from all application
           and geographic areas.

        2. Input from past and present developers is also desired.

        3. Throughout the project a secondary goal will be to build
           a list of users/locations (installation date, duration and
           disposition) of PDP-6 and KA, KI, KL and KS systems.
           Serial numbers, if available, are requested.

        4. We anticipate that this project will generate a large
           volume of information (which we hope will arrive
           electronically).  Some information, for any number of
           reasons, may not be in line with the project's stated
           goals.  Therefore, all notes, interview material and
           submissions will be donated to the Computer Museum in Boston
           at the the completion of the project to be available for
           future reference and research.

Ideas, contributions, suggestions and criticism are welcome.  As these
36 bit systems were the products of a multitude of people, so too
will be the writing of their history.
\1f
Date: Tue, 31 Mar 87 18:21:04 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  [KLOTZ%OZ.AI.MIT.EDU: sys;system mail]
To: ZVONA@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Mon 30 Mar 87 14:54:07 EST from David Chapman <ZVONA at AI.AI.MIT.EDU>
Message-ID: <176953.870331.ALAN@AI.AI.MIT.EDU>

Nothing you could tell me about when DDT and PWORD handle newlines in the
presence or absence of SYSTEM MAIL would supprise me.  I've looked at that
code once before trying to make both programs do the same thing, and I was
unable to do that.  If anyone else thinks they want to straighten this out,
I can suggest about 8 other projects that would be more useful.
\1f
Date: Mon, 30 Mar 87 14:54:07 EST
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
Subject:  [KLOTZ%OZ.AI.MIT.EDU: sys;system mail]
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <176082.870330.ZVONA@AI.AI.MIT.EDU>

Well, this is really random.

Date: Mon 30 Mar 87 02:18-EST
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...
\1f
Date: Sun, 29 Mar 87 14:41:13 EST
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
cc: KLOTZ@AI.AI.MIT.EDU
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.
\1f
Date: Tue, 24 Mar 87 09:48:33 EST
From: Ed Schwalenberg <ED@AI.AI.MIT.EDU>
Subject: CAMEXEC
To: CENT@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, AAD@AI.AI.MIT.EDU,
    HENRY GAMMERDINGER@AI.AI.MIT.EDU
Message-ID: <173000.870324.ED@AI.AI.MIT.EDU>

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

        Date: Sat, 21 Mar 87 05:59:20 EST
        From: "Anthony A. Datri" <AAD@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@AI.
    ...
Before this gets out of hand, CAMEXEC was written by Mike Speciner, who was
MS@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).
\1f
Date: Tue, 24 Mar 87 03:40:44 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: is this a mailing list?
To: AAD@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <172875.870324.CENT@AI.AI.MIT.EDU>

    Date: Sat, 21 Mar 87 05:59:20 EST
    From: "Anthony A. Datri" <AAD@AI.AI.MIT.EDU>
    Subject: is this a mailing list?
    To: INFO-ITS@AI.AI.MIT.EDU, INFO-ITS-REQUEST@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@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@AI.

for info on ITS, you should start by looking into the :INFO program and
reading what it has to offer.
\1f
Date: Sat, 21 Mar 87 05:59:20 EST
From: "Anthony A. Datri" <AAD@AI.AI.MIT.EDU>
Subject: is this a mailing list?
To: INFO-ITS@AI.AI.MIT.EDU, INFO-ITS-REQUEST@AI.AI.MIT.EDU
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@ai.ai.mit.edu (but i imagine you guessed that, eh?)
\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 20:20:36 EST
Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87  20:09:06 EST
Date: Fri 20 Mar 87 20:03:32-EST
From: "John Wroclawski" <JTW@MIT-SPEECH>
Subject: Re: TCP buffers
To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU
cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
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.
-------

\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 19:56:09 EST
Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87  19:58:54 EST
Date: Fri 20 Mar 87 19:53:22-EST
From: "John Wroclawski" <JTW@MIT-SPEECH>
Subject: Re: TCP buffers
To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU
cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
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
-------

\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 16:35:06 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 20 Mar 87 16:23:56 EST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98275; Fri 20-Mar-87 15:20:04 EST
Date: Fri, 20 Mar 87 15:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: TCP buffers
To: Ken Harrenstien <KLH@AI.AI.MIT.EDU>
cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
    BUG-COMSAT@MC.LCS.MIT.EDU
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@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).


\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 15:31:34 EST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 15:34:47 EST
Date: Fri, 20 Mar 87 15:30:42 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  TCP buffers
To: KLH@AI.AI.MIT.EDU
cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU
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.


\1f
Date: Fri, 20 Mar 87 14:52:06 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  today's crash
To: BUG-ITS@AI.AI.MIT.EDU
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
\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 01:48:46 EST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 01:51:39 EST
Date: Fri, 20 Mar 87 01:47:48 EST
From: Ken Harrenstien <KLH@AI.AI.MIT.EDU>
Subject: TCP buffers
To: ALAN@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
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.



\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAR 87  18:12:06 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 28498; Sun 15-Mar-87 18:09:51 EST
Date: Sun, 15 Mar 87 18:09 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Recent bugs
To: BUG-ITS@AI.AI.MIT.EDU
cc: ED@AI.AI.MIT.EDU
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@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@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.
\1f
Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 MAR 87  13:41:26 EST
Date: Wed 11 Mar 87 13:38:43-EST
From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
Subject: Re: not a bug
To: RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: bug-system@AI.AI.MIT.EDU
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)
-------
\1f
Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 MAR 87  13:18:29 EST
Date: Wed 11 Mar 87 13:14-EST
From: Eric Sven Ristad <RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: not a bug
To: bug-system@AI.AI.MIT.EDU

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

Eric
\1f
Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 10 Mar 87 00:44:05 EST
Received: by eneevax.umd.edu (5.9/4.7)
        id AA13924; Tue, 10 Mar 87 00:41:36 EST
Date: Tue, 10 Mar 87 00:41:36 EST
From: Douglas Humphrey <deh@eneevax.umd.edu>
Message-Id: <8703100541.AA13924@eneevax.umd.edu>
To: BUG-ITS@AI.AI.MIT.EDU, BUG-KS@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU
Subject: Re:  MD has internal troubles

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

\1f
Date: Mon,  9 Mar 87 00:36:27 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: MD has internal troubles
To: BUG-KS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
Message-ID: <165407.870309.CENT@AI.AI.MIT.EDU>

(remailed for the record)

Date: Fri, 6 Mar 87 16:00 EST
From: Alan Bawden <Alan@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... ]
\1f
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  6 Mar 87 13:27:10 EST
Date: Fri, 6 Mar 1987  13:24 EST
Message-ID: <SRA.12284268841.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   BUG-ITS@AI.AI.MIT.EDU
Subject: BT AUTO
In-reply-to: Msg of 6 Mar 1987  12:47-EST from David Vinayak Wallace <GUMBY@AI.AI.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? :-)
\1f
Date: Fri,  6 Mar 87 12:47:39 EST
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
Subject:  BT AUTO
To: ALAN@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
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?)
\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAR 87  19:38:02 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 26567; Thu 5-Mar-87 19:39:05 EST
Date: Thu, 5 Mar 87 19:37 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: BT AUTO
To: SRA@XX.LCS.MIT.EDU
cc: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
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@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.)
\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAR 87  19:10:40 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 26559; Thu 5-Mar-87 19:11:45 EST
Date: Thu, 5 Mar 87 19:10 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: BT AUTO
To: ZVONA@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
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@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!
\1f
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  5 Mar 87 13:37:10 EST
Date: Thu, 5 Mar 1987  13:34 EST
Message-ID: <SRA.12284008604.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   David Chapman <ZVONA@AI.AI.MIT.EDU>
cc:   BUG-ITS@AI.AI.MIT.EDU
Subject: BT AUTO
In-reply-to: Msg of 5 Mar 1987  13:12-EST from David Chapman <ZVONA@AI.AI.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?
\1f
Date: Thu,  5 Mar 87 13:12:14 EST
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
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.
\1f
Date: Tue, 24 Feb 87 15:05:39 EST
From: kltoz@AI.AI.MIT.EDU
Sender: ___016@AI.AI.MIT.EDU
Subject: Rudy.Nedved and the end of TOPS-10
To: POOR-MX@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU,
    BUG-ITS@AI.AI.MIT.EDU
Message-ID: <159022.870224.___016@AI.AI.MIT.EDU>

Rudy Nedved is the person who caused the demise of info-cobol.
\1f
Date: Tue, 24 Feb 87 01:21:56 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: small request
To: Rudy.Nedved@H.CS.CMU.EDU
cc: POSTMASTER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
    POOR-MX@AI.AI.MIT.EDU
Message-ID: <158772.870224.CENT@AI.AI.MIT.EDU>

    Date: Monday, 23 February 1987 19:28:36 EST
    From: Rudy.Nedved@h.cs.cmu.edu
    To: postmaster@mc.lcs.mit.edu
    Subject: small request
    Hi, Could some kind person take the time out to remove
            MIT-MESSAGES@A.CS.CMU.EDU
    from the mit bboard distribution list? 
done, mostly by Gumby (i cleaned up a few things he missed).
                                           It has been eons since I made a
    change to a mailing list on MIT ITC 
you mean ITS, right?
                                        machines. Thanks much,
    -Rudy
    CMU CS/RI Postmaster

    P.S. The last TOPS-10 machine on the ARPANET, A.CS.CMU.EDU is going away
         in a week or so. The official shutoff time for users is this Monday,
         March 2nd.
alas, poor PDP-10s -- yet another casualty. it deserves recording
(wherefore the CCs to the other lists) and public mourning. probably if you
send a mildly clever farewell msg to arpanet-bboards it will get
broadcast...
\1f
Date: Mon, 23 Feb 87 23:36:44 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  confused
To: CENT@AI.AI.MIT.EDU
cc: BUG-LOCK@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Mon 23 Feb 87 22:49:38 EST from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <158719.870223.ALAN@AI.AI.MIT.EDU>

Actually, its ITS that is at fault, not LOCK.  You killed your LOCK job and
someone else's TELSER happened to get the same job slot before ITS got
around to printing the tattle on the system console.  I don't know why the
.SHUTDN uuo doesn't just do a BUG INFO to report what happened rather than
using the buggy kludge that it does...
\1f
Date: Mon,  9 Feb 87 11:54:49 EST
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <151362.870209.ZVONA@AI.AI.MIT.EDU>

AI crashed at 9:44 this morning with a bughalt message

PK: GF node wasnt on list

This came right after 

IMP output msg too big 2996  09:44:12

which is probably responsible.

Crash dump in crash;crash pknogf.
\1f
Date: Tue,  3 Feb 87 07:31:26 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: MD status
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <148487.870203.CENT@AI.AI.MIT.EDU>

OZ has a recalcitrant disk drive. lester has tried this and that but
it's still down. so he asked about hooking it up to one of the KSs for
testing. alan and i told him he could use MD. he promised to write
something in MD's log noting what he was doing.
\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jan 87 17:00:15 EST
Date: Sat, 31 Jan 87 17:01:01 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  TCP buffers
To: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
Message-ID: <165683.870131.ALAN@MC.LCS.MIT.EDU>

I wish we could figure out why ITS consistently dribbles away its TCP
buffers until there are none left.

I also wish that when this happens, COMSAT didn't exhibit this bizare
behavior:

162430  Unqueueing to host THEORY.LCS.MIT.EDU
162431    ICP->THEORY.LCS.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
162432  Unqueueing to host RED.RUTGERS.EDU
162433    ICP->RED.RUTGERS.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
162434  Unqueueing to host BRL-SEM.ARPA
162435    ICP->BRL-SEM.ARPA (TCP-SMTP=Bad Greeting="221 BCNU")
162435  Unqueueing to host LBL.ARPA
162436    ICP->LBL.ARPA (TCP-SMTP=Bad Greeting="221 BCNU")
162437  Unqueueing to host SDCSVAX.UCSD.EDU
162438    ICP->SDCSVAX.UCSD.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
162439  Unqueueing to host R20.UTEXAS.EDU
162440    ICP->R20.UTEXAS.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
162441  Unqueueing to host SAIL.STANFORD.EDU
162442    ICP->SAIL.STANFORD.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
162444  Unqueueing to host ATHENA.MIT.EDU
162444    ICP->ATHENA.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
162445  Unqueueing to host CHARON.MIT.EDU
162446    ICP->CHARON.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")

\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JAN 87  15:01:45 EST
Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19480; Mon 26-Jan-87 15:03:06 EST
Date: Mon, 26 Jan 87 15:03 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: IAP
To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU>
Message-ID: <870126150304.6.ALAN@KAREN.AI.MIT.EDU>

Despite the fact that in the IAP guide I promised four sessions of the ITS
course, there will -not- be a fourth session this week.  See you all again
next year!
\1f
Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 87  20:04:59 EST
Date: Thu 22 Jan 87 20:05:01-EST
From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
Subject: RP06 undocumented behavior
To: bug-its@AI.AI.MIT.EDU
Message-ID: <12273069628.19.JTW@MIT-SPEECH>


The twenex world recently discovered that an RP0x which gets a header
compare error (HCE) without getting a header CRC error (HCRC) at the
same time may need to have a recalibrate operation done rather than
just a recenter and retry type thing. Otherwise the head ends up
mispositioned till it eventually slams into the stops (which either
fixes it or breaks it but good).

Apparently this is contrary to what the "manual" says.

I don't know what ITS does in this case. Just writing it down for
the record.
-------
\1f
Date: Thu, 22 Jan 87 04:16:36 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  PEEK shouldn't ever PCLSR anyone
To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 21 Jan 1987  00:25 EST from Rob Austein <SRA at XX.LCS.MIT.EDU>
Message-ID: <143202.870122.ALAN@AI.AI.MIT.EDU>

After fixing PEEK to not needlessly PCLSR device servers a few days ago, I
have been periodically watching COMSAT and DQDEV on MC waiting to catch
them in the act of getting hung up.  This afternoon I found them in the
wedged state and was able to figure out what causes the problem.  The
problem has nothing to do with the BOJ/JOB code, and is not a bug in DQDEV.
Actually it is an apparently long-standing timing error in the
implementation of .HANG.  

Specifically, when you did (as DQDEV does)

        TRNN AC,%FLAG
         .HANG

the code for .HANG knew that the TRNN instruction could never skip unless
the C(AC) changed, and since nothing can change a job's accumulators
without PCLSRing the job, .HANG could simply hang forever.  This is all
well and good, except .HANG neglected to run the instruction once itself to
be certain that AC hadn't been changed by an interrupt routine that ran
-between- the TRNN and the .HANG.

I have assembled an ITS with the fix and I will test it the next time I get
a chance.
\1f
Date: Wed, 21 Jan 87 02:12:12 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: ai crashed
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <142633.870121.CENT@AI.AI.MIT.EDU>

again, or halted, or whatever it was. see CRASH;UNIT0 FUKT. Unit 0 had
spun down. i spun it up and reloaded. 
\1f
Date: Fri, 16 Jan 87 17:13:23 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  [MOON: Mysterious MC won't shut down crash explained]
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <141115.870116.ALAN@AI.AI.MIT.EDU>

After reading the following bug report, 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...

Date: Fri, 16 Jan 87 01:39:40 EST
From: David A. Moon <MOON at AI.AI.MIT.EDU>
To:   ALAN at AI.AI.MIT.EDU
cc:   BUG-COMSAT at AI.AI.MIT.EDU
Re:   Mysterious MC won't shut down crash explained

You aren't going to like this one damn bit.

TMPLOC 44,      -LCCBLK,,CCBLK  ;aobjn ptr to critical code table for lock hacking

looks like it would put an aobjn pointer into location 44, doesn't it?

It doesn't.  It puts -LCCBLK into location 44 and CCBLK into the next
location inline (where it happens to get ignored).  This is because

        ; TMPLOC <loc>,<parenthesized arg> - puts argument at given LOC
        ;       without changing location counter outside macro call.
DEFINE TMPLOC VAL,?ARG
[definition deleted]

Why the heck doesn't TMPLOC use a rest-of-line arg?

Now -LCCBLK is -1,,777772, an aobjn pointer to a page that is mapped
into absolute page 120, which contains whatever it happens to contain.
If the PC happens to lie within the bounds of the first word there,
the system executes the second word there as an instruction, with the
extra added feature (see IODCD1 in ITS) that if the LH is zero, SETOM
is substituted.  Thus when Comsat executes the .LOGOUT that ALOGO4
puts into its AC 0 when the system job guns it, the unlocking of
Comsat's locked switches, if that absolute page contains zeros,
will do a SETOM 0.  If Comsat doesn't pclsr, that -1 is never seen,
but if it does PCLSR out of the .LOGOUT (we still don't know where
it pclsred from), it executes that -1 as an instruction, causing the
lossage we saw.  Yow!

It looks like it's been this way for eons.  Maybe this also explains
why the Comsat locks don't always seem to work right.
\1f
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 16 Jan 87 04:17:47 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715239312833556@MIT-MULTICS.ARPA>; 16 Jan 1987 04:08:32 est
Message-ID:  <227734@QZCOM>
In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU>
Date:        16 Jan 87 01:07 +0100
From:        Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-To:    Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Subject:     IAP

If someone has a home-video-tape-recorder-and-camera-set at MIT
availible, it wold be nice to have a vide tape of the lecture,
for us that can't show up.



\1f
Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JAN 87  15:29:36 EST
Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 15 Jan 87 15:21-EST
Date: Thu, 15 Jan 87 15:23 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: IAP
To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
In-Reply-To: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU>
Message-ID: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU>

Those of you who missed the second session of the ITS course last night
should be aware that next week we will once again meet on -Wednesday-.
It seems I screwed up when I thought we couldn't have the playroom this
Tuesday, and it is actually -next- Tuesday than has the conflict.

Next Wednesday we'll do something about Job Devices.  How to write one, or
how they are implemented, or something like that...
\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JAN 87  16:52:54 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 17414; Wed 7-Jan-87 16:50:47 EST
Date: Wed, 7 Jan 87 16:50 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: IAP
To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Message-ID: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU>

Those of you who missed the first session of the ITS course last night
should be aware that next week we will meet on -Wednesday- instead of
Tuesday.  The following week we will go back to meeting on Tuesdays.  (All
meetings are in the 7th floor playroom at 7:30).

Next Wednesday we will hear a bit about the ITS filesystem (not all that
much to tell) and then Ed Schwalenberg will tell us about "CAMEXEC: An
ITS-style Operating System for PDP11's".
\1f
Date: Sun,  4 Jan 87 05:03:53 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  IAP
To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Message-ID: <136289.870104.ALAN@AI.AI.MIT.EDU>

Yes, there will be an IAP course this January about ITS.  The first meeting
will take place in the 7th floor playroom this Tuesday (the 6th) at 7:30 PM.

On Tuesday we will talk about a number of things, including what topics
people might want to hear about in future sessions.  As a main event, I am
preparing an explanation of everyone's favorite ITS feature:

               PCLSRing:  What it is, how it's implemented,
                   and why Lisp Machines should have it.

I'll try and satisfy both the people who want to hear about low-level,
bits-between-the-toes issues, and those who want to learn universal, cosmic
principles.  I'll even relate PCLSRing to quantum mechanics.
\1f
Date: Thu,  1 Jan 87 15:43:25 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  MX unit #5
To: KLOTZ@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 31 Dec 86 22:12:10 EST from Leigh L. Klotz <KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <135733.870101.ALAN@AI.AI.MIT.EDU>

    Date: Wed, 31 Dec 86 22:12:10 EST
    From: Leigh L. Klotz <KLOTZ at MX>
    I just got a non-recoverable disk data error on
    klotz;emacs \11:ej, which is on 14.

When you log in, SYS:SYSTEM MAIL warned you that unit #5 was sinking fast.
Yeah, many files on that pack/drive have suffered.

Perhaps I'll try swapping that pack with the one on unit #4 and see what
happens.  If we are really lucky, that will destroy both of them!

    Date: Wed, 31 Dec 86 22:28:06 EST
    From: Leigh L. Klotz <KLOTZ at MX>
    I renamed the bad file to klotz;.bad. :EJ, but the error went away.
    It had been repeatable.  Is anyone interested in this?  Should I be
    sending mail to POOR-MC?

POOR-MC is probably the right place, although perhaps there is a POOR-MX
list that I don't know about.  (POOR-KL?)
\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Dec 86 22:46:03 EST
Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 31 Dec 86 22:26:36 EST
Date: Wed, 31 Dec 86 22:28:06 EST
From: "Leigh L. Klotz" <KLOTZ%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <963808.861231.KLOTZ@MX.LCS.MIT.EDU>

I renamed the bad file to klotz;.bad. :EJ, but the error went away.
It had been repeatable.  Is anyone interested in this?  Should I be
sending mail to POOR-MC?


\1f
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Dec 86 22:19:49 EST
Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 31 Dec 86 22:10:41 EST
Date: Wed, 31 Dec 86 22:12:10 EST
From: "Leigh L. Klotz" <KLOTZ%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <963796.861231.KLOTZ@MX.LCS.MIT.EDU>

I just got a non-recoverable disk data error on
klotz;emacs \11:ej, which is on 14.


\1f
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 22 Dec 86 20:39:45 EST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29850; Mon 22-Dec-86 20:36:56 EST
Date: Mon, 22 Dec 86 20:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Kludging around the KS's flakey disk
To: Rob Austein <sra@MIT-AI.ARPA>
cc: Bug-ITS@MIT-AI.ARPA, Poor-MC@MIT-AI.ARPA
In-Reply-To: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU>
Supersedes: <861222150854.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <861222203625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 22 Dec 86 02:02 EST
    From: Rob Austein <sra@XX.LCS.MIT.EDU>

    I just spent five minutes looking at the DISK code.  Based on that
    wealth of experience, it appears to me that if I were to bring up the KS
    with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or
    so.

    Somebody tell me why I shouldn't do this, before I wear out the $P keys
    on the KS's console....

The idea was that if the disk goes unsafe, is reset, and goes unsafe
again within one second, it is probably about to explode and the fire
department should be called.  It looks like the code jumps to UNSAFE
for a lot of different reasons, not all of which are the drive going
unsafe.  The drive also goes unsafe for a lot of different reasons,
some of more consequence than others.

I agree that if you JFCL out the BUGPAUSE it won't do it any more, so if
you think this won't do irreparable harm to the disk, go ahead.

\1f
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Dec 86 02:04:20 EST
Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Dec 86 02:04-EST
Date: Mon, 22 Dec 86 02:02 EST
From: Rob Austein <sra@XX.LCS.MIT.EDU>
Subject: Kludging around the KS's flakey disk
To: Bug-ITS@AI.AI.MIT.EDU, Poor-MC@AI.AI.MIT.EDU
Message-ID: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU>

I just spent five minutes looking at the DISK code.  Based on that
wealth of experience, it appears to me that if I were to bring up the KS
with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or
so.

Somebody tell me why I shouldn't do this, before I wear out the $P keys
on the KS's console....
\1f
Date: Sun, 21 Dec 86 23:17:45 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  RP06s eat dead bears
To: GUMBY@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Sun 21 Dec 86 13:52:25 EST from David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
Message-ID: <133398.861221.ALAN@AI.AI.MIT.EDU>

    Date: Sun, 21 Dec 86 13:52:25 EST
    From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
    AI hung in a fashion I'd never seen on the KS's: disk accesses would
    hang forever.  Pages in core were easily accessible; ITS ran fine
    unless you tried to touch the disk.  I could create a job and run some
    instructions in low memory, but when I tried to do a .CALL OPEN ITS
    hung.

You must have been lucky.  Our RP06's have been causing ITS to hang in this
way ever since day 1.

    I went upstairs and the system console said:
    DSK: UNIT #1 CAME BACK ONLINE 
    DSK: UNIT #0 CAME BACK ONLINE
    DSK: UNIT #1 CAME BACK ONLINE
    and some status registers.  For all three, ER1= 40000 which is Drive
    Unsafe. 

Unsafe almost always comes on.  The interesting bits were the ones in ER3,
which according to the crash dump were (according to the crufty
documentation) "AC power low", "DC power low" and "Spare" (!).

    I dumped it to CRASH DSKOFL, not that I think it will help any.

Why?  I manadged to get the ER3 bits out of it.

    Notice that the crash file was written out but the dates were not set
    on the file?

DSKDMP never sets write dates, because it doesn't know how to tell the
time.  The DMPCPY program (which TARAKA runs when the system boots) sets
the date on any file it suspects is a crash dump.  In this case, DMPCPY
wasn't able to set the date either, because you had cold booted the
machine, so ITS didn't know what time it was when DMPCPY ran.

    ...  By the way, should these be going to BUG-ITS or KS-ITS -- I can
    never tell any more.

You sent this to the right place.  KS-ITS is almost -never- the right place
to send a Bug Report.
\1f
Date: Sun, 21 Dec 86 22:34:01 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Gee, that's not his host's name
To: RDZ@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, BUG-LISP@AI.AI.MIT.EDU
In-reply-to: Msg of Sat 20 Dec 86 13:22 EST from Ramin Zabih <RDZ at AI.AI.MIT.EDU>
Message-ID: <133383.861221.ALAN@AI.AI.MIT.EDU>

    Date: Sat, 20 Dec 86 13:22 EST
    From: Ramin Zabih <RDZ at AI>
    Typing :FINGER on AI just produced this output:
    ...
    RDZ       Ramin Zabih                 F      T23 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)

    It seems that someone is confused about the name of the 3600 I'm using...

RDZ's host has a short name of "NULL".  He's been expecting the name "NULL"
to break some program ever since he named it that.  I presume thats why he
mailed this bug report to Bug-LISP.

Nothing's broken actually.  I was just hacking him...
\1f
Date: Sun, 21 Dec 86 13:52:25 EST
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <133197.861221.GUMBY@AI.AI.MIT.EDU>

AI hung in a fashion I'd never seen on the KS's: disk accesses would 
hang forever.  Pages in core were easily accessible; ITS ran fine unless
you tried to touch the disk.  I could create a job and run some instructions
in low memory, but when I tried to do a .CALL OPEN ITS hung.

I went upstairs and the system console said:
DSK: UNIT #1 CAME BACK ONLINE 
DSK: UNIT #0 CAME BACK ONLINE
DSK: UNIT #1 CAME BACK ONLINE
and some status registers.  For all three, ER1= 40000 which is Drive Unsafe.

I dumped it to CRASH DSKOFL, not that I think it will help any.  Notice
that the crash file was written out but the dates were not set on the file?

I cold-booted just in case -- ITS seems to be running fine now.  By the way,
should these be going to BUG-ITS or KS-ITS -- I can never tell any more.

david
\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 DEC 86  13:23:05 EST
Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16312; Sat 20-Dec-86 13:22:41 EST
Date: Sat, 20 Dec 86 13:22 EST
From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
Subject: Gee, that's not my host's name
To: bug-lisp@OZ.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU
Message-ID: <861220132243.9.RDZ@NULLSTELLENSATZ.AI.MIT.EDU>

Typing :FINGER on AI just produced this output:

-User-    --Full name--          Jobnam Idle TTY -Console location-
___005 <  [not logged in]        HACTRN   23.T05 906 x1729 CENT, OAF
KWH       Ken Haase              HACTRN *:**.T15 Net site PREP (Chaos)
DPH       Daniel Huttenlocher    HACTRN   46.T16 723 x8843 Alan, DPH
RDZ       Ramin Zabih                 F      T23 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)

It seems that someone is confused about the name of the 3600 I'm using...


\1f
Date: Fri, 19 Dec 86 02:54:39 EST
From: Alan@AI,Moon@AI
Sender: ALAN@AI.AI.MIT.EDU
Subject:  OK, I just saw it happen again.
To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
Message-ID: <132522.861219.ALAN@AI.AI.MIT.EDU>

For most of yesterday (Thursday the 18th) COMSAT on MC was catatonic.  Our
guess is that it was stuck in a JOB device wait (waiting for the DQ
device).  As soon as Alan looked at the situation COMSAT started running
again, so probably something he did caused COMSAT to get PCLSR'd out of the
system call for the first time all day, and the second time the timing
screw did not occur.

The right thing is for someone to fix the last bug in the JOB/BOJ code.

A quick fix the COMSAT maintainers might consider, is to take an occasional
%PIRLT interrupt to keep its interactions with DQ lubricated.

A better fix would be for Alan to finish up the improved Domain Demon
interface, so that COMSAT can use it instead, and not be subject to this
particular class of ITS bug.
\1f
Date: Thu, 18 Dec 86 02:57:19 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <132118.861218.ALAN@AI.AI.MIT.EDU>

TTYSET on a TTY opened as a device (rather than as a console)
clobbers the wrong TTYST* words!
\1f
Date: Thu,  4 Dec 86 14:00:04 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  more fukt
To: CENT@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Thu  4 Dec 86 03:20:35 EST from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <126472.861204.ALAN@AI.AI.MIT.EDU>

    Date: Thu,  4 Dec 86 03:20:35 EST
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
    ... maybe lester didn't fix the disk hard enough.

I don't think it is related.  This is a problem we have had ever since we
went to two drives.  The symptom is that for no apparent reason a drive
interrupts you and reports that it has just recently come back online.
Both drives do it.  We have no idea why they do this.  We also have no idea
why the code that we put in to recover from this doesn't work.  (Perhaps we
need to reset the drive harder when this happens.)  Luckily this doesn't
seem to happen all that often, but it has been the most common reason for
AI crashes since we got the new drive.

It also seems that if one drive is in the middle of a transfer, and you
tell the other drive to do something, the first drive will interrupt you
and complain that you shouldn't bother it while it is busy.  We simply
ignore these complaints, which seems to work just fine.  (Like it's
happened 470 times since AI came up 10 hours ago...)
\1f
Date: Thu,  4 Dec 86 03:20:35 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: more fukt
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <126255.861204.CENT@AI.AI.MIT.EDU>

it happened again. dumped to CRASH;FUCKED AGAIN.
maybe lester didn't fix the disk hard enough.
\1f
Date: Thu,  4 Dec 86 01:19:00 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: &^*^&$%!!
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <126198.861204.CENT@AI.AI.MIT.EDU>

things were hanging all over, and alan diagnosed that a disk had briefly
gone offline, and AI had not quite recovered correctly. only thing i
could do, really, was to lift switch 0 and reload. crash dump (i think)
to CRASH;FUCKME HARDER, a fine traditional name.
\1f
Date: Wed, 19 Nov 86 00:52:23 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: ITS boot tapes
To: USER-ACCOUNTS@AI.AI.MIT.EDU, mkunix!shawn@EDDIE.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].120162.861119.CENT>

    From: mkunix!shawn@EDDIE.MIT.EDU
    Date: Fri, 14 Nov 86 16:56:21 est
    To: mit-eddie!user-accounts@mit-ai
    Subject: ITS boot tapes
    Howdy, I would like to make a copy of the great ITS operating system,
    yes, I know, most people would say 'why', but someday I hope to work in
    a group that has an old KL/KA and bring up ITS... Being in DEC this is
    possable, although probably not likely.
    In any case, I wonder if someone would be willing at some point to
    show, or instruct me, or guide me in some way in how to make the two
    tapes I would need to a) Boot ITS and build a system, and b) Load in
    the sources to ITS, and any applications that are deemed ok to
    take/have.
    Please forgive me if this is the wrong forum, but I have been trying to
    find help from various points and ran out of places to ask... Thanks
    for any help.
                                    -- Shawn
    Btw, it may be simpler for anyone who wishes to reply to me, to just
    send me mail on MC, since I don't know if ITS can deal with uucp path
    names, although it may. Thanks again.

of course ITS can deal with uucp paths, at least up to a point. however, as
you suspect, USER-A is the wrong place to ask. even you could have thought
of asking BUG-ITS.
\1f
Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 NOV 86  21:37:17 EST
Date: Sun, 16 Nov 86 21:31:19 EST
From: Rob Austein <SRA@MX.LCS.MIT.EDU>
Subject:  KL: .; IOELEV *
To: BUG-its@AI.AI.MIT.EDU, poor-mx@AI.AI.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].958244.861116.SRA>

I assembled and installed a new version of IOELEV for the KL.  The
only change is that it now knows that its name has changed (no longer
tells you you are connected to MC).  I'll change the namespace
sometime soon if there aren't any problems with this.

While I was installing this silliness, I reorganized the IOELEV
binaries.  KL Console-11 binaries are (as before) in IOELEV nnnBIN
with IOELEV BIN as a link to the latest version (now IOELEV 431BIN).
The AI-Chaos-11 binaries are now in IOELEV nnnAI with a link from
IOELEV AIBIN to the latest version (IOELEV 430AI, the one where I made
subnet six the "primary" address of AI-11 so dover spooling would work
better).

I don't expect any problems.  Next person who cold boots the KL please
tell me what happens (if no problems, tell me that).

--Rob
\1f
Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 NOV 86  19:52:40 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 11282; Thu 13-Nov-86 19:47:32 EST
Date: Thu, 13 Nov 86 19:47 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: AI wedged itself
To: SRA@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].117740.861112.SRA>
Message-ID: <861113194734.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Wed, 12 Nov 86 16:45:19 EST
    From: Rob Austein <SRA@AI.AI.MIT.EDU>
    Dump in AI:CRASH;WEDGED IDUNNO, not that I expect anybody to have any
    use for it.

Looks like there was a power glitch or something.  I'm told there were air
conditioning problems at the time as well.
\1f
Date: Wed, 12 Nov 86 16:52:39 EST
From: Rob Austein <SRA@AI.AI.MIT.EDU>
Subject:  "ECC" errors?
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].117747.861112.SRA>

Happened to be next to AI (had just rebooted it).  Heard one of the
RP06s start fibrulating (the sort of mad seek motion that I normally
only see on XX when both XX and its FE are trying to write on drive
zero at the same time).  A few seconds later an ECC message pops up on
the console.  Don't know if it means anything, but thought I should
report it.
\1f
Date: Wed, 12 Nov 86 16:45:19 EST
From: Rob Austein <SRA@AI.AI.MIT.EDU>
Subject:  AI wedged itself
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].117740.861112.SRA>

Dump in AI:CRASH;WEDGED IDUNNO, not that I expect anybody to have any
use for it.
--Rob
\1f
Received: from DIAMOND.S4CC.Symbolics.COM (TCP 20024231403) by AI.AI.MIT.EDU  4 Nov 86 16:33:11 EST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24769; Tue 4-Nov-86 16:27:49 EST
Date: Tue, 4 Nov 86 16:27 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: For those of you around MIT this January
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>, KS-ITS@AI.AI.MIT.EDU,
    BUG-ITS@AI.AI.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN>
Message-ID: <861104162735.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Sat, 25 Oct 86 01:38:44 EDT
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>

    Hackers,

    It has been suggested that it might be a good idea to teach an ITS course
    during IAP this year.  We have done this twice before with somewhat mixed
    results.  A few sessions were quite memorable, and a few were dogs.  Before
    I decide if I want to front for this again this year, I would like to hear
    from some other people.  Specifically I want to hear:

    Things people want to learn about.

    Opinions about what has worked in the past.

    Volunteers who would enjoy teaching about something.

    Ways of using this to burn excess machine cycles on our many (!) ITS
    machines.  (Student project ideas?)

I don't think I have any of my notes from IAP'83.  Do you (Alan) have
any from IAP'84?  I seemed to remember talking about some of the
following:
        UUOs/.CALL, their skip-on-success feature, their argument
          passing/returning syntax
        TTY management
        Devices, MLDEV:, CLU/I/O/A:, etc
        Jobs (and BOJs)
        File system, links, etc.
        Greenblat's History lecture
        Moon's hardware description of (the original) AI
With the general proliferation of PCs and high level languages, some of
the more gutsy things, which are the interesting things, may require a
(refresher) course on the assembly language concepts.

\1f
Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 27 Oct 86 06:51:15 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708249629097960@MIT-MULTICS.ARPA>; 27 Oct 1986 06:33:49 est
Date:        26 Oct 86 23:36 +0100
From:        Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, "Alan Bawden"
              <ALAN@AI.AI.MIT.EDU>
Subject:     For those of you around MIT this January
Message-ID:  <212189@QZCOM>
In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN>

We are interseted from Stockholm, two persons, major interest:
ITS Internals, what is doing what, and what is speaking to what
internaly.



\1f
Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Oct 86 15:47:35 EDT
Date: Sat, 25 Oct 1986  15:46 EDT
Message-ID: <SRA.12249680831.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc:   BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Subject: For those of you around MIT this January
In-reply-to: Msg of 25 Oct 1986  01:38-EDT from Alan Bawden <ALAN@AI.AI.MIT.EDU>

Gee, I haven't taught a short course since I left Wesleyan.  Sounds
like fun.  TECO, theory and practice?
\1f
Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Oct 86 02:21:54 EDT
Received: by eneevax.umd.edu (5.9/4.7)
        id AA23785; Sat, 25 Oct 86 02:20:02 EDT
Date: Sat, 25 Oct 86 02:20:02 EDT
From: Douglas Humphrey <deh@eneevax.umd.edu>
Message-Id: <8610250620.AA23785@eneevax.umd.edu>
To: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Subject: Re:  For those of you around MIT this January

Let me know when these courses would be and such and count me in. 
If I'm going to have one, these might be real helpful and 
certainly a Lot of fun. 

Doug
\1f
Date: Sat, 25 Oct 86 01:38:44 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  For those of you around MIT this January
To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].110499.861025.ALAN>

Hackers,

It has been suggested that it might be a good idea to teach an ITS course
during IAP this year.  We have done this twice before with somewhat mixed
results.  A few sessions were quite memorable, and a few were dogs.  Before
I decide if I want to front for this again this year, I would like to hear
from some other people.  Specifically I want to hear:

Things people want to learn about.

Opinions about what has worked in the past.

Volunteers who would enjoy teaching about something.

Ways of using this to burn excess machine cycles on our many (!) ITS
machines.  (Student project ideas?)
\1f
Date: Thu, 23 Oct 86 01:56:05 EDT
From: Ray Hirschfeld <RAY@AI.AI.MIT.EDU>
Subject:  emacs lossage
To: ALAN@AI.AI.MIT.EDU
cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 22 Oct 86 19:07:28 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].109744.861023.RAY>

    Date: Wed, 22 Oct 86 19:07:28 EDT
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    To:   RAY at AI.AI.MIT.EDU
    cc:   BUG-EMACS at AI.AI.MIT.EDU, BUG-ITS at AI.AI.MIT.EDU
    Re:   emacs lossage
        ...
    Well, a quick peek at your directory reveals:

    AI   RAY   
    FREE BLOCKS #0=285 #1=2674 
      ...
      0   TS     E       59 +161 ! 10/21/86 11:27:25 (10/22/86) 
      ...

    A look at this file reveals that it is an SBLK file, so it is unlikely that
    this is an EMACS that you dumped out for yourself intentionally.
    (Especially since it appears to be a vanilla EMACS with no libraries
    loaded.)  Perhaps you should delete this file.

Thanks, Alan!  I never thought to look there.  Removing the bogus
emacs fixed the problem.  I wonder where the hell it came from.

                                Ray
\1f
Date: Wed, 22 Oct 86 19:07:28 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  emacs lossage
To: RAY@AI.AI.MIT.EDU
cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 22 Oct 86 18:44:59 EDT from Ray Hirschfeld <RAY at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].109549.861022.ALAN>

    Date: Wed, 22 Oct 86 18:44:59 EDT
    From: Ray Hirschfeld <RAY at AI>
    Emacs on AI has been dying on me repeatedly over the last few days.
    It always chokes in the same place, with a message like:

    .VAL 0; 6767>>MOVEM 6,1377  6/   177  1377/   176

    A quick peek reveals that this immediately follows a .call corblk,
    which I guess is failing.

    Proceeding the job makes it work until the next try.

Well, a quick peek at your directory reveals:

AI   RAY   
FREE BLOCKS #0=285 #1=2674 
  ...
  0   TS     E       59 +161 ! 10/21/86 11:27:25 (10/22/86) 
  ...

A look at this file reveals that it is an SBLK file, so it is unlikely that
this is an EMACS that you dumped out for yourself intentionally.
(Especially since it appears to be a vanilla EMACS with no libraries
loaded.)  Perhaps you should delete this file.
\1f
Date: Wed, 22 Oct 86 18:44:59 EDT
From: Ray Hirschfeld <RAY@AI.AI.MIT.EDU>
Subject:  emacs lossage
To: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].109535.861022.RAY>

Emacs on AI has been dying on me repeatedly over the last few days.
It always chokes in the same place, with a message like:

.VAL 0; 6767>>MOVEM 6,1377  6/   177  1377/   176

A quick peek reveals that this immediately follows a .call corblk,
which I guess is failing.

Proceeding the job makes it work until the next try.
\1f
Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 SEP 86  20:50:06 EDT
Date: Fri 26 Sep 86 20:48:06-EDT
From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
Subject: Re: dump code fukt
To: Moon@SCRC-STONY-BROOK.ARPA, CENT@AI.AI.MIT.EDU
cc: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-Reply-To: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12242133556.4.JTW@MIT-SPEECH>

    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: dump code fukt


        Date: Fri, 26 Sep 86 03:56:39 EDT
        From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>

   ....

My first guess is hardware flaking, possibly followed by inadequate resetting
action by the software. The code hasn't changed in forever.

        MT:RETRYING WRITE OPERATION
        MAG TAPE STATUS TM03 error status decode routine needs to be written ?
        MTAPE: FORMATTER ERROR, STATUS= 140600,,40000

This is transport unsafe, usually means it went offline while trying to
write.

        MTAPE: FORMATTER ERROR, STATUS=150660,,100320
        MAG TAPE STATUS TM03 error status decode routine needs to be written ?

This is a mess. To some extent the bits are inconsistant (seems to imply a
number of data transfer errors during a positioning command), but could
possibly be interpreted as the result of a misformed data transfer command.

    I assume multi-reel incremental dumps have worked in the past...

Is this actually true?
-------
\1f
Received: from STONY-BROOK.SCRC.Symbolics.COM by AI.AI.MIT.EDU 26 Sep 86 12:55:07 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115737; Fri 26-Sep-86 12:47:14 EDT
Date: Fri, 26 Sep 86 12:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: dump code fukt
To: Pandora B. Berman <CENT@AI.AI.MIT.EDU>, JTW@AI.AI.MIT.EDU
cc: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].98958.860926.CENT0>
Message-ID: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 26 Sep 86 03:56:39 EDT
    From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>

    when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the
    end of the reel somewhere in the middle of VAFB;, saying

    MT:RETRYING WRITE OPERATION
    MAG TAPE STATUS TM03 error status decode routine needs to be written ?
    MTAPE: FORMATTER ERROR, STATUS= 140600,,40000

    and giving me a DUMP prompt.  thinking this might just be a case of
    terminal dirk, i cleaned the drive and started over again with the
    same tape. same result. so i tried dumping onto AI 231. this time, i
    got

    MTAPE: FORMATTER ERROR, STATUS=150660,,100320
    MAG TAPE STATUS TM03 error status decode routine needs to be written ?

    the job at a prompt, and the tape waiting at EOT. so i rewound it and
    ICHECK'd it. the ICHECK ended without any strange msgs. 

    maybe the first time was just due to incorrectly placed-EOT mark (it
    did have one, but i'm not sure which side they're -supposed- to be on),
    but the second tape worked OK. so something is wrong here..

The MT: and MTAPE: messages (why the inconsistency?) show up in :PEEK ",
so they came from the ITS system rather than from DUMP (it can be hard
to distinguish when you run DUMP on the system-console).  The
"error status decode routine needs to be written" message came from DUMP.
I guess its routine for explaining the details of tape errors was never
converted from the version for the KA/KL tape controller.

John, do you know what those octal numbers in the formatter error message
mean?  I assume multi-reel incremental dumps have worked in the past, so
has something in the hardware broken?  The tape code in ITS hasn't changed
recently, has it?

\1f
Date: Fri, 26 Sep 86 03:56:39 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Sender: CENT0@AI.AI.MIT.EDU
Subject: dump code fukt
To: BUG-DUMP@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].98958.860926.CENT0>

when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the
end of the reel somewhere in the middle of VAFB;, saying

MT:RETRYING WRITE OPERATION
MAG TAPE STATUS TM03 error status decode routine needs to be written ?
MTAPE: FORMATTER ERROR, STATUS= 140600,,40000

and giving me a DUMP prompt.  thinking this might just be a case of
terminal dirk, i cleaned the drive and started over again with the
same tape. same result. so i tried dumping onto AI 231. this time, i
got

MTAPE: FORMATTER ERROR, STATUS=150660,,100320
MAG TAPE STATUS TM03 error status decode routine needs to be written ?

the job at a prompt, and the tape waiting at EOT. so i rewound it and
ICHECK'd it. the ICHECK ended without any strange msgs. 

maybe the first time was just due to incorrectly placed-EOT mark (it
did have one, but i'm not sure which side they're -supposed- to be on),
but the second tape worked OK. so something is wrong here.
\1f
Date: Fri, 19 Sep 86 15:03:13 EDT
From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].96071.860919.RDZ>

AI crashed with "TTY: buffer empty at TYIREM".  Dump is in
CRASH;TYIREM CRASH
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 SEP 86  21:40:30 EDT
Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 SEP 86  21:19:54 EDT
Received: from AI.AI.MIT.EDU by ML.AI.MIT.EDU via Chaosnet; 13 SEP 86  21:04:42 EDT
Date: Sat, 13 Sep 86 21:08:22 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  When you run out of TCP buffers.
To: BUG-ITS@ML.AI.MIT.EDU
cc: BUG-COMSAT@ML.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].93646.860913.ALAN>

There must be a path through the ITS TCP code that fails to free a buffer
somehow.  Twice I have seen MC run itself completely out of buffers.  (See
the dump MC:CRASH;CRASH TCPFUL, for an example.)  In the most recent
example, ITS had been running for 35 days before this happened, which might
be relevant, although in the previous case it had only been running for 10
days.

Bug-COMSAT:  COMSAT behaves weirdly when this happens.  Take a look at some
of the recent stats files on MC.  Like for -every- host it tries to contact
with TCP it reports: Bad Greeting="+" or somesuch.
\1f
Date: Mon,  8 Sep 86 11:04:04 EDT
From: Daniel Huttenlocher <DPH@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].92012.860908.DPH>

AI bughalted trying to free a packet still in use.  Crash dump
in PKT USE.
\1f
Date: Thu,  4 Sep 86 15:29:10 EDT
From: Daniel Huttenlocher <DPH@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].90952.860904.DPH>

AI got a system revived at 14:38, and seemed to leave all jobs
hung or detached (at least ignoring tty input). about 45 mins later
it started printing system full messages on the console.  dumped
to SYS FULL
\1f
Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 Aug 86 02:00:37 EDT
Date: Thu, 21 Aug 1986  02:05 EDT
Message-ID: <SRA.12232491989.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc:   BUG-ITS@AI.AI.MIT.EDU
Subject: .RYEAR and time zones again
In-reply-to: Msg of 21 Aug 1986  00:12-EDT from Alan Bawden <ALAN@AI.AI.MIT.EDU>

Making it a new system call is fine.  What I'm looking for is a single
UUO that will return the information currently returned by .RLPDTM
plus time zone information.  Doesn't have to be in .RLPDTM format, but
should be easy to calculate things like DATIME"TIMGTN from it.

For that matter it would be a win if there was a system call that did
the DATIME"TIMGTN calculation with maximum hair and all the leap year
corrections understood to the human race, once, at system boot time,
then just added system uptime to that to get current time.  This
business of having to recalculate the number of leap years since 1 Jan
1900 every time you want an absolute time value is for the birds.
\1f
Date: Thu, 21 Aug 86 00:12:52 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  .RYEAR and time zones again
To: SRA@XX.LCS.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 20 Aug 1986  16:04 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].86070.860821.ALAN>

Why don't we just add another system call to return timezone related
information rather than trying to squeeze something into the last few bits
of .RYEAR?  First, I dislike recycling fields that are documented to be
zero (rather than being documented as reserved for future expansion.)
Second, given the existence of half-hour and even quarter-hour timezones in
parts of the world, five bits isn't really enough.  Third, while we are at
it, it might be a good idea to try and do something about generalizing the
daylight savings time stuff to cover whatever local laws there might be
geverning time.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 AUG 86  15:59:50 EDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Aug 86 15:58:57 EDT
Date: Wed, 20 Aug 1986  16:04 EDT
Message-ID: <SRA.12232382629.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   bug-its@MC.LCS.MIT.EDU
Subject: .RYEAR and time zones again

Sorry, I should have made that a formal propoal, bits and all.

Time zones range from +1200 to -1200 (international date line, one day
apart from each other).

The two possible formats would be:

        the five low bits of an integer in the range -12. -> +12.

or
        one sign bit (3.5) and four bits of integer range 0 -> +12.

Only difference is in how you insert/extract it, of course.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 AUG 86  15:32:21 EDT
Date: Wed, 20 Aug 86 15:31:28 EDT
From: Rob Austein <SRA@MC.LCS.MIT.EDU>
Subject: .RYEAR and time zones
To: BUG-ITS@MC.LCS.MIT.EDU
cc: SRA@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].73280.860820.SRA>

It would be nice if programs didn't have to have hardwired knowledge
of what time zone they are in (yes, I know, all ITS machines are at MIT
and thus in time zone -0500, but we're trying to be evangelical, here,
right?).

Bits 3.5 -> 3.1 of the result from .RYEAR are defined as zero.
24. (maxium time zone plus one) is 30 in octal.  Seems a timezone
would fit into those bits very nicely.

Anybody know of anything that would break if this were done?
About the only thing I can think of that this would mess up
would be grossitudes like MOVEI AC,@MEM (ignoring the fact that
HRRZ AC,MEM works just as well).  Does anybody really care
what's in those five zeroed bits?

(No, nothing of vital importance depends on this, it would just make
some code I was writing a little cleaner.)
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86  17:50:52 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86  17:49:53 EDT
Date: Sun, 17 Aug 86 17:48:54 EDT
From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].941512.860817.DEVON>

Closer examination of my problem controlling my telnet connection to MX
reveals that my logout file on AI is sending telnet IAC DONT TRBIN even
though the MX->AI connection is supdup and not telnet.  The problem is
that the only way I can test for a telnet connection is to look at %TPMTA
because the IAC DO TRBIN in the login file turns off the %TPTEL bit!

I guess the way to tell if you are telnetting or supduping is to first
look at %TPCBS, if it's on you're supdup, if it's off look at %TPMTA
and if it's on you're telnet, otherwise it's unknown but for my purposes
this case doesn't matter.  Maybe the tctyp program should handle this?
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86  17:26:26 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86  17:25:27 EDT
Date: Sun, 17 Aug 86 17:24:28 EDT
From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].941506.860817.DEVON>

note that BUG^K prompts "to:" but should prompt "to: bug-"

When I log in my init file checks for a telnet connection and
does :imgout 377 375 0 which sends a telnet IAC DO TRBIN so
that the TAC will pass @ characters instead of intercepting them,
and pass the 8th bit so the meta key works from my ann arbor.

it looks like nethopping bereaks this somehow, because after
nethopping to either AI or OZ the TAC stops passing meta bits
and starts to intercept @ characters.

        --Devon
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86  17:00:41 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86  16:59:42 EDT
Date: Sun, 17 Aug 86 16:58:43 EDT
From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].941505.860817.DEVON>

I tried nethopping from
\1f
Date: Tue,  5 Aug 86 05:10:49 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: TU40 resurrection
To: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
    file-r@MC.LCS.MIT.EDU
cc: DEC@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].79588.860805.CENT>

lester found another instance of the right drive belt somewhere, and even
installed it, so MX's tape drive works again. thanks, lester.

this means we can again read and write 800bpi 7track tapes. however, we
shouldn't WRITE any, because we can't read them anywhere else. i have run
an incremental dump of MX over the net, using Gut's drive (1600 bpi
9track). this causes a few non-fatal errors on the MX end but apparently
works (see system log). any future dumps of MX should be done this way;
i'll do them, or other interested parties (ty?) can ask how. it's only a
little more complicated than dumping to the local drive.

all old incremental tapes for MX are hereby retired and should only be used
to read off of. i have started a new set of incremental tapes at 375 (so
will not overwrite older tape data). all 1600bpi LCS ITS tapes are now on
the rack by the dover. i will try to run a full dump soon. we should get on
with the project of copying the GFR tapes, and then (if possible) proceed
forward into the past, copying full dumps as we go.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86  15:21:24 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86  13:32:07 EDT
Date: Tue, 29 Jul 86 11:39:53 EDT
From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].936970.860729.DEVON>

the door on MX's tape drive seems to be wedged partly open.
As far as I know, it is still true that if you use it, the
controller will deposit bad parity words into system buffers
which will cause MX to bughalt.  Anything new on this?
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86  15:21:17 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86  13:32:02 EDT
Date: Tue, 29 Jul 86 11:10:47 EDT
From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].936964.860729.DEVON>

the network stopped talking across the railroad tracks (as usual on rainy
days) so I left my plasma TV and walked over to the VT52 by MX's console.
Now :TCTYP DESCRIBE says I have Sail,-%TOSAI which looks like a bug to me.
It echoes H when I type backspace at DDT, for instance.
\1f
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 24 Jul 86 19:18:06 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49456; Thu 24-Jul-86 18:46:43 EDT
Date: Thu, 24 Jul 86 18:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MC
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
cc: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].75103.860724.ALAN>
Message-ID: <860724184615.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 24 Jul 86 15:15:31 EDT
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>

        Date: Thu, 24 Jul 1986  13:53 EDT
        From: Rob Austein <SRA at XX>
        MC seems to have stopped talking to its IMP....

    MC's IMP cable was half unplugged at the IMP end.

        PEEK on MC claims that there are no free packet buffers, all
        sockets in use, but shows nobody using the net.

    Who claimed all sockets were in use?  I guess some program told you this
    because both conditions return the same error code.  I don't actually
    understand why unplugging the IMP cable should cause all the buffers to get
    used up.  There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard
    wants to tell us.  (This happened on MC once before, see MC:CRASH;CRASH TCP.)

Maybe all the packet buffers were full of packets waiting to be sent to the IMP.


        Maybe a cable fell off ...

    Very good!

        I gunned COMSAT on MC so that it wouldn't time out all the messages in
        its queue trying to send through a broken interface.

    But of course Puff launched another one within an hour.

By the way, I believe the NET command in LOCK still resets the network,
cycling HOST MASTER READY on the IMP cable.  That wouldn't have plugged
the cable back in in this case of course, but might still have been
a useful thing to try.  I hope this command works on KS's.

\1f
Date: Thu, 24 Jul 86 15:15:31 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  MC
To: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
cc: BUG-MAIL@AI.AI.MIT.EDU
In-reply-to: Msg of Thu 24 Jul 1986  13:53 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].75103.860724.ALAN>

    Date: Thu, 24 Jul 1986  13:53 EDT
    From: Rob Austein <SRA at XX>
    MC seems to have stopped talking to its IMP....

MC's IMP cable was half unplugged at the IMP end.

    PEEK on MC claims that there are no free packet buffers, all
    sockets in use, but shows nobody using the net.

Who claimed all sockets were in use?  I guess some program told you this
because both conditions return the same error code.  I don't actually
understand why unplugging the IMP cable should cause all the buffers to get
used up.  There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard
wants to tell us.  (This happened on MC once before, see MC:CRASH;CRASH TCP.)

    Maybe a cable fell off ...

Very good!

    I gunned COMSAT on MC so that it wouldn't time out all the messages in
    its queue trying to send through a broken interface.

But of course Puff launched another one within an hour.
\1f
Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 24 Jul 86 14:18:57 EDT
Date: Thu, 24 Jul 1986  13:53 EDT
Message-ID: <SRA.12225280779.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   bug-its@AI.AI.MIT.EDU, bug-mail@AI.AI.MIT.EDU
Subject: MC

MC seems to have stopped talking to its IMP.  XX isn't having any
trouble with this, so it's (probably) not BBN doing something random.
Attempting to connect to 10.3.0.44 causes the IMP to claim that MC is
down.  PEEK on MC claims that there are no free packet buffers, all
sockets in use, but shows nobody using the net.  Maybe a cable fell
off the LH/DH or maybe something else.

I gunned COMSAT on MC so that it wouldn't time out all the messages in
its queue trying to send through a broken interface.
\1f
Date: Tue, 15 Jul 86 17:16:43 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  TCP Checksum Routine
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].70523.860715.ALAN>

This afternoon AI crashed because the TCP segment checksuming routine
referenced location 400000, which is normally non-existant in the system's
page table, thus taking a page fault.  The offending instruction was the
ILDB at THCKS5.  There is a crash dump in CRASH;CRASH TCPSUM, although I
may have trashed the accumulators and the BUGxxx locations before taking
the dump.  I guess we have to suspect that this routine checksums
randomness a lot, and we were only lucky to catch it this time because it
happened to hit the 2% of system memory that would cause it to halt.
\1f
Date: Sun, 13 Jul 86 17:58:41 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Disappear here.
To: DANIEL@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Sun 13 Jul 86 10:29:11 EDT from Daniel Weise <DANIEL at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].69293.860713.ALAN>

    Date: Sun, 13 Jul 86 10:29:11 EDT
    From: Daniel Weise <DANIEL at AI.AI.MIT.EDU>
    AI went catatonic this morning.  I took a dump to
    CATA TONIC and reloaded.

Thanks.  Its just unit #1 being broken again.
\1f
Date: Sun, 13 Jul 86 10:29:11 EDT
From: Daniel Weise <DANIEL@AI.AI.MIT.EDU>
Subject: Disappear here.
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].69227.860713.DANIEL>

AI went catatonic this morning.  I took a dump to
CATA TONIC and reloaded.

Daniel
\1f
Date: Sat, 12 Jul 86 03:56:36 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  DRAGON;SYSMSG LOG
To: BUG-ITS@AI.AI.MIT.EDU, MAGIC-DRAGON-KEEPER@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].68883.860712.ALAN>

The latest PFTHMG DRAGON (installed on the four KS10s, but not the KL)
permanently logs memory errors in addition to disk errors.  The file
DRAGON;DISK LOG is now called DRAGON;SYSMSG LOG.
\1f
Date: Thu, 26 Jun 86 19:36:12 EDT
From: "Andrew A. Berlin" <AAB@AI.AI.MIT.EDU>
Subject:  ROLM phones.
To: BUG-SYS@AI.AI.MIT.EDU
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
\1f
Date: Wed, 25 Jun 86 11:49:20 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Foo
To: TAFT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
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.
\1f
Date: Thu, 19 Jun 86 19:58:28 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: old mail
To: DAVIS@AI.AI.MIT.EDU
cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-SYSTEM@AI.AI.MIT.EDU
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@XX.LCS.MIT.EDU>
    Subject: old mail
    To: bug-system%OZ.AI.MIT.EDU@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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JUN 86  22:17:43 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUN 86  22:17:51 EDT
Date: Sun, 15 Jun 86 22:17:17 EDT
From: Daniel Weise <DANIEL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
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
\1f
Date: Mon,  9 Jun 86 21:37:04 EDT
From: Charles Frankston <CBF@AI.AI.MIT.EDU>
Subject: [Forwarded: JSLove@MIT-MULTICS.ARPA, Re: Re: info about INQUIR]
To: BUG-ITS@AI.AI.MIT.EDU
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@MIT-MULTICS.ARPA>
Subject:  Re: info about INQUIR
To: Jan Popiel <Popiel@MIT-MULTICS.ARPA>
Cc: sipb@MC.LCS.MIT.EDU
In-Reply-To:  Message of 9 Jun 86 13:32 EDT from "Jan Popiel"
Message-Id:  <860609182112.975425@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@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.
\1f
Date: Mon,  9 Jun 86 16:00:16 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  AI's losing network
To: BUG-ITS@AI.AI.MIT.EDU, CPH@OZ.AI.MIT.EDU
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.
\1f
Date: Mon,  9 Jun 86 15:48:44 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  AI's losing network
To: BUG-ITS@AI.AI.MIT.EDU, CPH@OZ.AI.MIT.EDU
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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86  15:22:22 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86  15:18:26 EDT
Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 9 JUN 86  14:30:16 EDT
Date: Mon, 9 Jun 1986  14:30 EDT
Message-ID: <CPH.12213491155.BABYL@MIT-OZ>
From: CPH@OZ.AI.MIT.EDU
To:   Bug-ITS@MX.LCS.MIT.EDU
Subject: AI's losing network

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.
\1f
Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JUN 86  00:25:33 EDT
Date: Sat 7 Jun 86 00:24:49-EDT
From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
Subject: Re: If you believe in Dovers, clap your hands!
To: ALAN@AI.AI.MIT.EDU
cc: TY@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-DOVER@AI.AI.MIT.EDU
Message-ID: <12212812879.9.JTW@MIT-SPEECH>

    Date: Sat,  7 Jun 86 00:08:53 EDT
    From: Alan Bawden <ALAN@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.
-------
\1f
Date: Sat,  7 Jun 86 00:08:53 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  If you believe in Dovers, clap your hands!
To: JTW@AI.AI.MIT.EDU
cc: TY@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
    BUG-DOVER@AI.AI.MIT.EDU
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!)
\1f
Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86  13:41:53 EDT
Date: Wed,  4 Jun 86 13:41:52 EDT
From: Chris Hanson <CPH%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  DOVER Lossage
To: BUG-SYSTEM@MX.LCS.MIT.EDU
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.
\1f
Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUN 86  19:53:34 EDT
Date: Mon,  2 Jun 86 19:53:24 EDT
From: "Michael A. Patton" <MAP%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: Actually the MX front end 11 I believe.
To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
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.
\1f
Date: Sun,  1 Jun 86 15:00:20 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Warning to ITS hackers
To: BUG-ITS@AI.AI.MIT.EDU
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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86  20:20:11 EDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 31 May 86 20:19:58 EDT
Date: Sat, 31 May 1986  20:18 EDT
Message-ID: <SRA.12211195221.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   macrakis%endor@HARVARD.HARVARD.EDU (Stavros Macrakis)
Cc:   bug-sys@MC.LCS.MIT.EDU, dudek@HARVARD.HARVARD.EDU
Subject: mit-mx
In-reply-to: Msg of 31 May 1986  18:53-EDT from macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)

    Date: Saturday, 31 May 1986  18:53-EDT
    From: macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)
    To:   dudek
    cc:   bug-sys@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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86  18:55:59 EDT
Received: from harvard.HARVARD.EDU by MC.LCS.MIT.EDU 31 May 86 18:55:41 EDT
Received: from endor.HARVARD.EDU (endor) by harvard.HARVARD.EDU; Sat, 31 May 86 18:53:35 EDT
Date: Sat, 31 May 86 18:53:26 EDT
Received: by endor.HARVARD.EDU; Fri, 30 May 86 19:19:33 EDT
From: macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)
To: dudek
Subject: mit-mx
Cc: bug-sys@mit-mc.arpa

tn etc. don't seem to know about `mx' == mx.lcs.mit.edu
\1f
Date: Sat, 31 May 86 04:13:37 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: MC TCP loss
To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].49182.860531.CENT>

while on MC and trying to finger out at other hosts, i kept getting an
"all sockets in use" msg. alan poked around and said the system was
out of TCP buffers and COMSAT was acting strangely, so i should raise
switch 0 and take a crash dump. CRASH;TCP LOSS.
\1f
Date: Sat, 31 May 86 03:23:01 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: mailing lists redux
To: GUMBY@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].49152.860531.CENT>

    Date: Wed, 28 May 86 17:01:04 EDT
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
    Subject:  KS-ITS mailing list
    To: GUMBY@AI.AI.MIT.EDU
    cc: CENT@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
        Date: Wed, 28 May 86 04:47:53 EDT
        From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
        Can't we fold this into INFO-ITS?
    INFO-ITS is an extremely low-volume mailing list.  It is for spreading
    information that ordinary ITS users and programmers might want to know.
    Like when a new device is installed (like LP7:), or a new Midas library
    is written, or a new machine is installed, or a new system call is
    installed or improved.
    KS-ITS is for people who are interested in the project of getting 2020s
    installed at MIT running ITS.  When I got the KS10 microcode to do
    ITS-style paging, I sent mail to KS-ITS.  The people on INFO-ITS I
    didn't bother until they could log in.
    A lot of mail that has gone to KS-ITS in the last few months should
    have been sent to BUG-ITS.  Like if AI crashes in some novel way,
    people send mail to KS-ITS "because AI is a KS", even though BUG-ITS is
    the proper recipient.
    The people on KS-ITS were interested in keeping in touch with a "good
    hack", which is distinct from both BUG-ITS and INFO-ITS.

gumby, the next time you ask 4 people's opinion about making the sort of
major change you suggested, why not wait until more than 1 replies before
deciding what to do? i have just spent 2 hours undoing the confusion you
created by going ahead with this merger after only one response. among
other things, you completely omitted the BUG-ITS archive.  fortunately i
discovered a BUG-ITS list member who hasn't logged in for the past few
days, and so was able to recover the lost msgs. i have also unmerged the
INFO-ITS and KS-ITS archives. also, it's considered courteous, when you
insist on rashly forging ahead in this fashion, to inform -all- the list
members involved; you only told those people on KS-ITS who were not on
INFO-ITS:
        Date: Wed, 28 May 86 05:49:01 EDT
        From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
        Subject:  KS-ITS mailing list
        To: KS-ITS-ONLY-PEOPLE@AI.AI.MIT.EDU
        The KS's have arrived and ITS runs on them, so we're folding the
        KS-ITS list into INFO-ITS.
        You're not on INFO-ITS nor BUG-ITS.  Unless I hear from you in the
        next few days I'll put you on INFO-ITS.
        david

i agree with alan -- the INFO-, BUG-, and KS-ITS have distinct purposes and
should be kept that way. now that the KSs run ITS, a lot of the discussion
previously carried on on KS-ITS should move to BUG-ITS or other more
appropriate lists, but that's another story.
\1f
Date: Wed, 28 May 86 17:21:32 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: ZVONA@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 28 May 86 11:39:49 EDT from David Chapman <ZVONA at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].47458.860528.ALAN>

    Date: Wed, 28 May 86 11:39:49 EDT
    From: David Chapman <ZVONA at AI.AI.MIT.EDU>
    Is there a reason ML is running ITS when everyone else is running NITS?

Heck, you should have looked yesterday!  AI was running NITS, MC was
running XITS, MD was running ITS...  The various names have no relation to
eachother.

    When MD came up, it deleted .temp.; because it was empty.  Does anything
    depend on that dir existing?   Just in case,  i recreated it.

Many things want there to be a .TEMP. directory.  However .TEMP. is on a
(very) short list of directories that are automatically created whenever
anyone tries to use them, so you needn't have gone to the trouble.  In
fact, you could have created it simply by typing .TEMP.^F!
\1f
Date: Wed, 28 May 86 16:48:18 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  ML up...
To: GUMBY@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Wed 28 May 86 04:12:21 EDT from David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].47443.860528.ALAN>

    Date: Wed, 28 May 86 04:12:21 EDT
    From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
    I brough ML up, and copied over LSR1, everything on SYS: created since
    the 15th, and .;@ NITS (which I then booted on ML).
    We should have a better way of doing this. 

Aiiiiiiieeee!!!!!

    Date: Wed, 28 May 86 04:15:43 EDT
    From: David Vinayak Wallace <GUMBY%ML.AI.MIT.EDU at MX.LCS.MIT.EDU>
    I lost moving @ NITS to ML:.;.  So ML's running ITS
    until someone competent wishes to do it.

Since each machine has different devices, addresses, terminals, names, etc.
The various ITS binaries are -totally- incompatible.  I shudder to think
what made you realize that you had lost...
\1f
Date: Wed, 28 May 86 11:39:49 EDT
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].47247.860528.ZVONA>

Is there a reason ML is running ITS when everyone else is running NITS?
When MD came up, it deleted .temp.; because it was empty.  Does anything
depend on that dir existing?   Just in case,  i recreated it.
\1f
Date: Wed, 28 May 86 08:25:34 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: Our Man Lester
To: BUG-ITS@AI.AI.MIT.EDU
cc: LAUREL@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].47197.860528.CENT>

appeared this morning after a significant absence. i asked him about
PM on AI and he said not next Tues. he has a meeting, so maybe Mon.,
or maybe even Fri. i mentioned that AI's disk filters needed changing,
and he agreed. he promised he'd send laurel and alan mail giving the
exact day.
\1f
Date: Wed, 28 May 86 06:52:36 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: it's probably not a good idea to GFR bug files
To: "GUMBY@"@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].47156.860528.CENT>

    Date: Wed, 28 May 86 06:37:38 EDT
    From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
    Subject:  it's probably not a good idea to GFR bug files:
    To: CENT@AI.AI.MIT.EDU
        Date: Wed, 28 May 86 06:26:48 EDT
        From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
            Date: Tue, 27 May 86 07:20:15 EDT
            From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
            FAILED: (FILE [LSPMAI;COMPLR BUGS]) at AI.AI.MIT.EDU; Couldn't
            write message to file;
                "DSK:LSPMAI;COMPLR BUGS" - LINK TO NON-EXISTENT FILE
            ...
        look again. the link is to an MX GFR tape. the file was gfr'd, by
        JPG or GSB, quite some time ago. are you requesting that it be
        retrieved or something?
    Yes, I think it should be.  
well, you're quite capable of hacking ITS tapes. if you don't, i'll get
around to it sometime.
                                Also, LSPMAI should be immune to GFR, 
talk Alan or whoever into adding it to the magic list...
                                                                      or
    at least, should be protected from having most-current bug files
    deleted.
i don't think ITS can do this.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86  04:16:36 EDT
Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86  04:16:18 EDT
Date: Wed, 28 May 86 04:15:43 EDT
From: David Vinayak Wallace <GUMBY%ML.AI.MIT.EDU@MX.LCS.MIT.EDU>
Subject: belay that
To: BUG-its@AI.AI.MIT.EDU
Message-ID: <[ML.AI.MIT.EDU].65.860528.GUMBY>

I lost moving @ NITS to ML:.;.  So ML's running ITS
until someone competent wishes to do it.
\1f
Date: Wed, 28 May 86 04:12:21 EDT
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
Sender: GUMBY0@AI.AI.MIT.EDU
Subject: ML up...
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].47096.860528.GUMBY0>

I brough ML up, and copied over LSR1, everything on SYS: created since
the 15th, and .;@ NITS (which I then booted on ML).
We should have a better way of doing this. 
\1f
Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86  02:24:13 EDT
Date: Wed, 28 May 86 02:23:09 EDT
From: David Vinayak Wallace <GUMBY@MX.LCS.MIT.EDU>
Subject:  ARPA contact name
To: JINX@OZ.AI.MIT.EDU
cc: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
    Bug-OZ@OZ.AI.MIT.EDU
In-reply-to: Msg of 27 May 1986  21:46 EDT (Tue) from Bill Rozas <JINX%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].922144.860528.GUMBY>

    Date: 27 May 1986  21:46 EDT (Tue)
    From: Bill Rozas <JINX at OZ>

    Shouldn't something which is more likely to stick around be used
    instead?  Using MX is hardly worth the effort, given its expected
    lifetime.

There has been more mail on this subject than it warrants.
1> Fix it to use the KL while it runs; patch it later.
2> Fix the chaos-only hosts (of which there aren't really too many left)
   to understand IP. 
\1f
Date: Tue, 27 May 86 22:51:56 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: ks lossage messages
To: GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].46889.860527.CENT>

    Date: Mon, 26 May 86 02:02 EDT
    From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
    Subject: ks lossage messages
    To: David Chapman <ZVONA@MX.LCS.MIT.EDU>
    cc: poor-ai@AI.AI.MIT.EDU
        Date: Mon, 19 May 86 11:12:12 EDT
        From: David Chapman <ZVONA@MX.LCS.MIT.EDU>
        Do we need a poor-ks?  
        At 6 this morning, MX started complaining often about being out of
        jobslots on the console.
    Messages like this used to go to BUG-ITS.  I figure they should anyway
    (and the poor-<xx> lists should be flushed, except for the special case
    of the KL).
i have flushed the POOR-AI list and folded the four msgs it had accumulated
in its archive file into the BUG-ITS archive.
\1f
Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86  21:46:43 EDT
Date: 27 May 1986  21:46 EDT (Tue)
Message-ID: <JINX.12210162593.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc:   BUG-ITS@AI.AI.MIT.EDU, Bug-OZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
      Cole%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, FTD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
      GLR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: [COLE: Telnet-ing through MC to live hosts...]
In-reply-to: Msg of 27 May 1986  16:11-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>


Why don't you just fix TELNET on OZ to use MX as a gateway?

Shouldn't something which is more likely to stick around be used
instead?  Using MX is hardly worth the effort, given its expected
lifetime.
\1f
Date: Tue, 27 May 86 16:11:20 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  [COLE: Telnet-ing through MC to live hosts...]
To: GLR@OZ.AI.MIT.EDU, Cole@OZ.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, FTD@OZ.AI.MIT.EDU,
    Bug-OZ@OZ.AI.MIT.EDU
In-reply-to: Msg of Tue 27 May 1986  15:13 EDT from Jerry Roylance <GLR%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].46638.860527.ALAN>

    Date: Tue, 27 May 1986  15:13 EDT
    From: Jerry Roylance <GLR at OZ>

    Date: Sunday, 25 May 1986  22:48-EDT
    From: COLE at OZ
    To:   David D. Story <FTD at OZ>
    cc:   bug-oz at OZ
    MC is rejecting OZ's request to telnet to arpanet hosts.
    But I was able to telnet from oz by typing:

    telnet
    TELNET> host-name telnet tcp mx

    I don't know what host computer OZ is now supposed to be using for its
    telnet connections.

Somebody seems to have decided that the MC KS will not supply TCP gateway
service.  I personally think this is silly.  I would not object if someone
else wants to take the heat for putting it back.

Why don't you just fix TELNET on OZ to use MX as a gateway?
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86  15:15:57 EDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86  15:15:25 EDT
Date: Tue, 27 May 1986  15:13 EDT
Message-ID: <GLR.12210090990.BABYL@MIT-OZ>
From: Jerry Roylance <GLR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Bug-ITS@MC.LCS.MIT.EDU
Subject: [COLE: Telnet-ing through MC to live hosts...]

Date: Sunday, 25 May 1986  22:48-EDT
From: COLE at OZ.AI.MIT.EDU
To:   David D. Story <FTD%MIT-OZ at MC.LCS.MIT.EDU>
cc:   bug-oz at OZ.AI.MIT.EDU
Re:   Telnet-ing through MC to live hosts...

MC is rejecting OZ's request to telnet to arpanet hosts.
But I was able to telnet from oz by typing:

telnet
TELNET> host-name telnet tcp mx

I don't know what host computer OZ is now supposed to be using for its telnet
connections.
\1f
Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86  14:31:38 EDT
Date: Tue, 27 May 86 14:30:45 EDT
From: Chris Hanson <CPH@MX.LCS.MIT.EDU>
Subject:  Just nitpicking...
To: BUG-ITS@MX.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].921807.860527.CPH>

MX still says "Connected to MC." when you dial it up.
I guess there is no single variable controlling the machine name.
\1f
Received: from MOSCOW-CENTRE.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 MAY 86  02:02:40 EDT
Date: Mon, 26 May 86 02:02 EDT
From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
Subject: ks lossage messages
To: David Chapman <ZVONA@MX.LCS.MIT.EDU>
cc: poor-ai@AI.AI.MIT.EDU
In-Reply-To: <[MX.LCS.MIT.EDU].587.860519.ZVONA>
Message-ID: <860526020227.5.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU>

    Date: Mon, 19 May 86 11:12:12 EDT
    From: David Chapman <ZVONA@MX.LCS.MIT.EDU>

    Do we need a poor-ks?  

    At 6 this morning, MX started complaining often about being out of
    jobslots on the console.

Messages like this used to go to BUG-ITS.  I figure they should anyway
(and the poor-<xx> lists should be flushed, except for the special case
of the KL).
\1f
Date: Thu, 22 May 86 01:20:17 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Someday when things calm down we might have time to look into things like this again
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].44418.860522.ALAN>

Outputting to a BOJ: channel after the device user no longer has his
JOB: channel open seems to simply hang.  (In the case I'm seeing it
is SIOT to a channel open in .UAO mode.)  I would have expected
this to signal an error, perhaps %ENAPP?
\1f
Date: Wed, 21 May 86 23:55:16 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: logbook location
To: SRA@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].44369.860521.CENT>

    Date: Wed, 21 May 1986  23:18 EDT
    From: Rob Austein <SRA@XX.LCS.MIT.EDU>
    To:   "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
    Cc:   BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
    Subject: At the tone, your name will be
    It would probably help if the ML and MD system logs were in some
    intuitively obvious place.  Now that you have reminded me of their
    existance I suspect they are sitting on top of the CPUs or disks or
    something.  If they were sitting by the consoles some of us space
    cadets might have remembered their existance and scrawled something in
    them.
if i could have put them safely any closer to the consoles, i would have.
i agree that on top of the CPUs is not the best location for visibility and
memory-jogging, but it appeared to be the best i could do. if we could get
some kind of little table beside MD's console (shoving the IMPLOD cabinet
over), that would be better.
\1f
Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 23:17:32 EDT
Date: Wed, 21 May 1986  23:18 EDT
Message-ID: <SRA.12208606423.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Cc:   BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
Subject: At the tone, your name will be
In-reply-to: Msg of 21 May 1986  22:57-EDT from "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>

It would probably help if the ML and MD system logs were in some
intuitively obvious place.  Now that you have reminded me of their
existance I suspect they are sitting on top of the CPUs or disks or
something.  If they were sitting by the consoles some of us space
cadets might have remembered their existance and scrawled something in
them.
\1f
Date: Wed, 21 May 86 22:57:57 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: At the tone, your name will be
To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].44335.860521.CENT>

I have relabelled everything in sight except the KS's tapes; i'll get
to those later this evening. i rediscovered the winning sort of
labels, so the binder labels should no longer be quite so eager to
come off.

NOTHING has been written in the ML and MD system logs for at least a
week.  nothing about bringing them down for DEC to borrow or loaning
disks to XX or any such matters. will someone who knows what's been
going on (SRA? JTW?) please insert a few notes so the rest of us can
remain mildly informed?
\1f
Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86  03:17:42 EDT
Date: Wed 21 May 86 03:19:00-EDT
From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
Subject: Re: ks lossage
To: JNC@XX.LCS.MIT.EDU, ALAN@AI.AI.MIT.EDU, ZVONA%MX.LCS.MIT.EDU@XX.LCS.MIT.EDU
cc: bug-its@AI.AI.MIT.EDU
In-Reply-To: <12208384120.19.JNC@XX.LCS.MIT.EDU>
Message-ID: <12208388143.21.JTW@MIT-SPEECH>

    From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
    Subject: Re: ks lossage

    I think the funny messages from the IMP have to do with some

The RFC that describes 1822L tells all, claiming that the IMP will
send the usual 3-NOP-and-a-reset sequence twice, once in 1822 format
and once in 1822L format, interleaving the messages. You are supposed
to tell it what you want by answering in your choice of format. If you
do this before it has sent the full sequence it will stop sending in
the protocol you don't want.

Which is all well and good, except that this RFC is dated in 1983.  So
it only took them three years to implement...?
-------
\1f
Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 02:56:08 EDT
Date: Wed 21 May 86 02:56:55-EDT
From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Subject: Re: ks lossage
To: ALAN@AI.AI.MIT.EDU, ZVONA@MX.LCS.MIT.EDU
cc: POOR-AI@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].42635.860519.ALAN>
Message-ID: <12208384120.19.JNC@XX.LCS.MIT.EDU>

        I think the funny messages from the IMP have to do with some
new leader format that BBN is introducing. They flag the new style
ones with what looks to old unmodified software with an illegal initial
code. We've just run acrosss this bringing up the 68000 GW IMP code.
-------
\1f
Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 02:38:44 EDT
Date: Wed 21 May 86 02:39:30-EDT
From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Subject: Re: flaky ML
To: ALAN@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].42474.860518.ALAN>
Message-ID: <12208380952.19.JNC@XX.LCS.MIT.EDU>

        Maybe it's not an accident that the 3 machines had bum memory
boards in them?
-------
\1f
Date: Wed, 21 May 86 00:35:26 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  6 5 4 3 2 1 ...
To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU,
    "(FILE [JNC:POOR MC])"@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].43668.860521.ALAN>

OK folks, I switched the names MC and MX in the ITS sources and created new
binaries for the two machines.  I also edited AI:SYSHST;HSTLCS to reflect
the swap.  So the first symptom of this name swap that anyone will notice
will appear early this morning when new host tables start circulating with
the Chaosnet addresses switched.  (Because we are switching both ArpaNet
addresses and physical connections, the change manifests itself in the host
tables as exchanged Chaosnet addresses.)
\1f
Date: Tue, 20 May 86 14:26:00 EDT
From: "Leigh L. Klotz" <KLOTZ@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].43062.860520.KLOTZ>

Just now I typed
P\vH
to get a histogram, and it started up a job called HP, which
said

File can't be OPENed - DSK:FORT;HP SAV
^V  VALRETS OR XFILES NESTED TOO DEEP?INPDL OVERFLOW - PDL RESET?  

but I guess that's another story.

The fair share is 74%, btw.
\1f
Date: Tue, 20 May 86 04:39:07 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: AI's first GFR
To: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].42900.860520.CENT>

sort of like its first date, or something -- it's just not the same
thereafter.

anyway, the GFR did run over AI SECOND:, taking 5K blocks off to tape.  Due
to cruftiness not yet worked around in the code (something to do with EOT),
we can't yet run incremental GFRs -- successive small GFRs onto the same
tape.  so i had to go for maximum usage of single tape instead. given the
amount of tape left, i think i could have gone for 6K blocks and won; that
we'll try next time.

the tape is in the rack with the other ITS tapes. as usual, this is a
Sacred GFR Tape -- be careful with it.

All and Sundry are reminded that all 4 KSs (when they're running ITS) are
regularly backed up -- help relieve AI's load by moving your files
elsewhere.
\1f
Date: Mon, 19 May 86 14:11:13 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  ks lossage
To: ZVONA@MX.LCS.MIT.EDU
cc: POOR-AI@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Mon 19 May 86 11:12:12 EDT from David Chapman <ZVONA at MX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].42635.860519.ALAN>

    Date: Mon, 19 May 86 11:12:12 EDT
    From: David Chapman <ZVONA at MX.LCS.MIT.EDU>
    ...
    When the machine booted it printed a lot of stuff I couldn't follow
    about the imp. 

All ITS machines with IMPs do this when you boot them now.  I presume the
software in the IMP has changed incompatibly somehow.  We all have to learn
to ignore this until somebody gets around to fixing it.

    'Nother funny thing: LAST time it was booted, it complained that it
    couldn't set the time, because 15 out of the 13 times it got from the
    net did not agree.  Besides sounding damn funny, it seems that
    requiring 15 good times is a little stringent.

Well, its just phrased a little funny.  It -asked- 25 people, and it
insists on getting 15 answers that agree back.  If only 13 people respond,
then indeed 15 of the 13 answers failed to agree!

I don't want to insist on a majority of the -responders-, since then if
only 1 machine responds that happens to be mistaken, the mistake spreads.
Look at it this way, this demon is just a convenience to save you from
having to run PDSET 95% of the time, you have to expect to do it manually
every now and then.
\1f
Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 MAY 86  11:10:47 EDT
Date: Mon, 19 May 86 11:12:12 EDT
From: David Chapman <ZVONA@MX.LCS.MIT.EDU>
Subject:  ks lossage
To: poor-ai@AI.AI.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].587.860519.ZVONA>

Do we need a poor-ks?  

At 6 this morning, MX started complaining often about being out of
jobslots on the console.  About 10, I couldn't supdup in, so I came
up.  I couldn't log into the console either -- it ignored ^Z.  So I
hit boot, and it said BT SW and ?BT 001200 and wouldn't listen to me.
So I got the fep and started at 777700 and that didn't work either, so
I booted again and it worked that time.  

My guess is that comsat is unhappy about its imp connection and dying
without freeing up its slot.  

When the machine booted it printed a lot of stuff I couldn't follow
about the imp. 

'Nother funny thing: LAST time it was booted, it complained that it
couldn't set the time, because 15 out of the 13 times it got from the
net did not agree.  Besides sounding damn funny, it seems that
requiring 15 good times is a little stringent.
\1f
Date: Sun, 18 May 86 21:39:55 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  flaky ML
To: CENT@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Sat 17 May 86 07:26:57 EDT from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].42474.860518.ALAN>

    Date: Sat, 17 May 86 07:26:57 EDT
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
    ML was getting a gross and astonishing number of ECC errors this morning.

We are talking -memory- EEC corrected errors rather than -disk- ECC
corrected errors I believe.

    see console output around 3-4 am. what does this? what can we do about it?

It means that there are some bad bits in ML's memory.  Its funny, AI has
never had a single one of these errors, but all -three- of the new KS10's
have memory boards in them that get ECC errors.

    i was dumping it and shoving some files on during this time -- maybe this
    has something to do with the flaky chaosnet?

Unlikely to be related other than the fact that you were just exercising
the machine in general.  The real problem here is that when I wrote the
code for logging the ECC errors, I didn't fully understand what it would be
like when they started happening regularly.  (My code also has a bug that
causes MD to essentially loop in the scheduler because of a bad bit in a
particularly sensitive location.)  I plan to re-write this code to be less
noisy and more robust soon.
\1f
Date: Sat, 17 May 86 07:30:43 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: dumped state
To: INFO-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].42220.860517.CENT>

as of this morning, all ITSs here (with the possible exception of the KL)
are being regularly backed up to tape. it -is- safe to store your files on
any of the KSs.
\1f
Date: Sat, 17 May 86 07:26:57 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: flaky ML
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].42218.860517.CENT>

ML was getting a gross and astonishing number of ECC errors this morning.
see console output around 3-4 am. what does this? what can we do about it?
i was dumping it and shoving some files on during this time -- maybe this
has something to do with the flaky chaosnet?
\1f
Date: Mon, 12 May 86 03:47:03 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: another way to confuse the issue
To: MBECK@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].37601.860512.CENT>

    Date: Sat, 10 May 86 01:11:28 EDT
    From: "Mark E. Becker" <MBECK@MC.LCS.MIT.EDU>
    Subject: MC <--> KS/MX mail switching
    To: CENT@MC.LCS.MIT.EDU
    After reading MC MAIL would it be a 'good thing' if I sent address
    update messages to those list maintainers saying that MBECK@MC should
    now be MBECK@KL ?

no. KL is a local-only nickname; on the general arpanet it's an alias for
SRI-KL, and sending your mail there would not help anyone. when the KS
(currently MX) and the KL (currently MC) switch names, they will retain
their model aliases -- the KL will be called MX or (locally) KL, while the
KS will be called MC or KS. this feature was arranged so we could do a
number of local transforms. for instance, the KS will have somewhat
restricted use, so it can concentrate on mail; thus, among other things, we
don't want all those people who get mail on the present MC to have that
mail land on the KS after the name switch. for this reason, someone has run
a program over the inquir database to change all net-addresses of MC to KL;
this will ensure that their mail will end up on the same physical machine
as it does now. all ITS machines share a common inquir database and forward
mail in accordance with the net-addresses people give therein, so all your
mail will end up where you currently get it now. since your mail goes to
OZ, it will continue to make one hop from MC (whichever hardware) to the
twenex; if you received it on MC-KL, you would find it would begin taking
an extra hop to reach your mailbox, because the KL will (probably) go off
the arpanet when the names are switched and all mail bound for it will have
to be forwarded through MC-KS or AI.
\1f
Date: Sun, 11 May 86 21:28:30 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Ask, and you shall recieve
To: SRA@XX.LCS.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU
cc: BUG-INQUIR@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU,
    SRA@MC.LCS.MIT.EDU, ZVONA@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 11 May 1986  04:59 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].37394.860511.ALAN>

    Date: Sun, 11 May 1986  04:59 EDT
    From: Rob Austein <SRA at XX.LCS.MIT.EDU>
    ...  (although it would be nice if it had some reasonable way to
    deduce what ITSs exist, at run-time).

Because I was updating so many programs to know about the new plethora of
ITS machines, I added exactly this feature.  There is a new table you can
ask for from the .GETSYS uuo: ITSNMS is a table of the sixbit names of the
-current- local ITS machines.  I have already converted most of the
programs that used to have built-in tables of ITS machines (INSTAL, FINGER,
FIND, etc.) to use this.  Do
:UUO GETSYS
for details.
\1f
Date: Sat, 10 May 86 18:26:28 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
cc: JSOL@AI.AI.MIT.EDU
In-reply-to: Msg of Sat 10 May 86 16:56:50 EDT from Jon Solomon <JSOL at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].37156.860510.ALAN>

    Date: Sat, 10 May 86 16:56:50 EDT
    From: Jon Solomon <JSOL at MC>
    for some reason I keep geting "all sockets in use" when there is
    nobody on the system. I did a :p a, and abuot 2/3rds of the connections
    are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe
    way to flush them?

I reloaded the system to get rid of them since nobody could connect to MC
using TCP.  I left a crash dump in MC:CRASH;CRASH TIMWTS if some networking
wizard wants to figure out what YALE.ARPA and SRI-UNIX.ARPA are doing that
cause these connections to stay in TIMWT seemingly forever.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 MAY 86  16:57:36 EDT
Date: Sat, 10 May 86 16:56:50 EDT
From: Jon Solomon <JSOL@MC.LCS.MIT.EDU>
To: BUG-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].909418.860510.JSOL>

for some reason I keep geting "all sockets in use" when there is
nobody on the system. I did a :p a, and abuot 2/3rds of the connections
are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe
way to flush them?
\1f
Date: Fri,  9 May 86 23:43:36 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  another mysterious lossage
To: CENT@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Fri  9 May 86 22:38:16 EDT from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].37001.860509.ALAN>

    Date: Fri,  9 May 86 22:38:16 EDT
    From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
    around 22:15 or so, AI stopped listening.... dumped it to CRASH;ITS
    HUNG, then reloaded. 

Looks like the same disk lossage again.  This time ITS had actually run out
of disk clannels.  Perhaps there is something wrong with one of the drives.
I'll try to figure this out after I get finished with this paper.  (I don't
grok the disk code well enough to do this immediately.)  I hope AI
continues to work for that long...  I renamed the crash to be
AI:CRASH;CRASH QLOSS"

BTW, penny, I figured out why MX's system console wouldn't talk to you.
The 8080 front end sometimes gets confused about the state of the system
console and stops forwarding characters through to the 10 (running out of
paper sometimes causes this to happen).  If you simply power-cycle the
LA120 this resets the 8080's opinion of things and you can use the system
console for input again.
\1f
Date: Fri,  9 May 86 22:38:16 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: another mysterious lossage
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].36993.860509.CENT>

around 22:15 or so, AI stopped listening. it was willing to echo typein but
would not act on it. also it echoed chaos packets, or heard them, or
something low-level like that. DPH and i figured out how to raise switch0
and dumped it to CRASH;ITS HUNG, then reloaded.
\1f
Date: Thu,  8 May 86 22:24:56 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Recent software crashes.
To: BUG-ITS@AI.AI.MIT.EDU
cc: SRA@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].36473.860508.ALAN>

Two recent crashes (in MC:CRASH;CRASH DRGFKT and AI:CRASH;CRASH BJUIS)
suggest that there is some problem with job device locking strategy.  I
guess we should have expected that having COMSAT using a job device 24
hours a day would expose some bugs.  The crash on MC is completely crazed
in the number of jobs that are confused.

AI just crashed again with the same lossage I complained about a couple
weeks ago.  The one where the system hangs up just like it does on MC when
the T-300 controller gets fucked.  (See AI:CRASH;CRASH QLOSS and
AI:CRASH;CRASH QLOSS'.)
\1f
Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU  8 May 86 07:46:48 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2693388755368144@MIT-MULTICS.ARPA>; 08 May 1986 07:32:35 edt
Date:        08 May 86 00:44 +0200
From:        Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU, "Alan Bawden"
              <ALAN@AI.AI.MIT.EDU>
Subject:     State of the world
Message-ID:  <172046@QZCOM>
In-Reply-To: <[AI.AI.MIT.EDU].35019.860506.ALAN>

We are looking forward, to the moment when we can load the tape
in the tape drive and have the system flying.



\1f
Date: Tue,  6 May 86 00:40:15 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  State of the world
To: KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].35019.860506.ALAN>

There are now -five- machines running ITS at MIT, more than have ever
existed simultaneously before.  There is the MC KL10, and four KS10's named
AI, MX, ML, and MD.  

The MC KL10 is off maintenance contract as of the first of this month, so I
suppose its days are numbered.  At some point before the KL10 passes on to
that great machine room in the sky, the MC KL10 and the MX KS10 will swap
their names, and we will plug the new MC KS10 into the old MC's Arpanet
port.  This assures that as far as the outside world is concerned, there
will always be an ITS named MC at that Arpanet address, performing mail
service functions for MIT.  (Let's not get into the hair we will be going
through to make all the mailing lists in the world continue to work.)

The KL10 will remain available for all those who wish to continue to use
it, under the name MX.  When the KL10 retires, the name MX will be retired
with it.

Various other owners of KS10's around the world will be receiving KS10 ITS
distribution tapes in the mail soon.  The last machine we booted (MD) was
built by a volunteer using the printed instructions we plan to include with
our ITS distribution kits.
\1f
Date: Thu,  1 May 86 05:28:04 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: imp lossage
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].33406.860501.CENT>

AI crashed around 3 or so. complained about IMP lossage of some sort.
dumped to CRASH;IMPOS LOSS.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86  15:05:01 EDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86  15:04:56 EDT
Date: Wed, 30 Apr 86 15:04:37 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  tty types
To: PGS@AI.AI.MIT.EDU
cc: KLOTZ@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
    BUG-SUPDUP@MC.LCS.MIT.EDU
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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86  02:43:41 EDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86  02:43:40 EDT
Date: Wed, 30 Apr 86 02:43:20 EDT
From: "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>
Subject:  tty types
To: ALAN@AI.AI.MIT.EDU
cc: KLOTZ@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
    BUG-SUPDUP@MC.LCS.MIT.EDU
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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 APR 86  08:31:35 EDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86  08:31:13 EDT
Date: Tue, 29 Apr 86 08:31:04 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  tty types
To: KLOTZ@AI.AI.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-SUPDUP@MC.LCS.MIT.EDU
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.
\1f
Date: Mon, 28 Apr 86 16:52:29 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: log books
To: BUG-ITS@AI.AI.MIT.EDU
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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 APR 86  15:44:27 EDT
Date: Mon, 28 Apr 86 15:44:36 EDT
From: "Leigh L. Klotz" <KLOTZ@MC.LCS.MIT.EDU>
To: BUG-ITS@MC.LCS.MIT.EDU
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?
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 APR 86  16:35:40 EST
Date: Sat, 26 Apr 86 16:35:24 EST
From: Daniel Weise <DANIEL@MC.LCS.MIT.EDU>
To: BUG-ITS@MC.LCS.MIT.EDU
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
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 APR 86  12:55:36 EST
Date: Sun, 20 Apr 86 12:54:59 EST
From: "Devon S. McCullough" <DEVON@MC.LCS.MIT.EDU>
To: BUG-ITS@MC.LCS.MIT.EDU
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.
\1f
Date: Fri, 18 Apr 86 03:37:32 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  devices and names
To: BUG-ITS@AI.AI.MIT.EDU, GZ@AI.AI.MIT.EDU
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...)
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 APR 86  20:18:29 EST
Date: Fri,  4 Apr 86 20:18:37 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  MC UNIT 1/PACK 13
To: KARENS@MC.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
    CENT@AI.AI.MIT.EDU
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.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 APR 86  17:33:53 EST
Date: Fri,  4 Apr 86 17:34:02 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  MC UNIT 1/PACK 13
To: KARENS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
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.
\1f
Date: Fri,  4 Apr 86 02:08:45 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: MC UNIT 1/PACK 13
To: KARENS@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
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.
\1f
Received: from MOSCOW-CENTRE.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAR 86  05:02:53 EST
Date: Mon, 31 Mar 86 05:02 EST
From: David Vinayak Wallace <Gumby@MIT-MC.ARPA>
Subject: disowned vs in background
To: BARTH@MIT-AI.ARPA, MBECK@MIT-AI.ARPA
cc: BUG-ITS@MIT-AI.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].22357.860329.CENT>
Message-ID: <860331050242.8.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU>

    Date: Sat, 29 Mar 86 17:23:33 EST
    From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>

        Date: Thu 27 Mar 86 06:47:55-EST
        From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
        I admit ignorance as well... when I see a "disowned" job on an ITS, its
        usually associated with some username somewhere.
                        ----------begin forwarded mail----------
        Date: Wed, 26 Mar 86 23:17:29 EST
        From: Richard Barth <BARTH@MC.LCS.MIT.EDU>

        Ignorant question for today...
        What's the difference between running a job in the background and
        disowning it?

    beyond my limited technical ability to describe. someone on this list should
    be able to help you more.

Roughly speaking, a disowned job has no superior nor controlling TTY,
(f'rinstance like COMSAT normally runs).  DDT lets you run jobs in
background, (e.g.  w/\10 or \e\e\10) by running them without the TTY and
handling output differently.  Their superior is still DDT.  From ITS's
point of view the only difference between running a job in foreground or
in background is who owns the TTY.

For a more detailed description, do :UUO .DISOWN, .ATTY, etc.

david

PS: bug-its people: what do you think of using BUG-ITS for questions
    like this?  I think it's a good idea, but if it's going to cause the
    fixers of bugs to remove themselves on the grounds of traffic
    levels, then we should have yet another list.
\1f
Date: Mon, 31 Mar 86 00:52:51 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  AI:CRASH;CRASH QLOSS
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].22618.860331.ALAN>

AI:CRASH;CRASH QLOSS contains a crash dump that I can't figure out.  I
don't, unfortunately, grok the interface between the main program level
disk code and the interrupt level.  It looked for all the world (to the
users) like what happens on MC when the system is hung trying to write
directories to the T-300's.  I can tell that the main program level code is
waiting for bits to arrive from interrupt level, but I don't understand why
interrupt level isn't coming through.

Of course, the fact that we have two disk drives for the first time on a KS
is something to be suspicious of...
\1f
Date: Sat, 29 Mar 86 17:23:33 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: disowned?
To: BARTH@AI.AI.MIT.EDU, MBECK@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].22357.860329.CENT>

    Date: Thu 27 Mar 86 06:47:55-EST
    From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
    To: Cent@MC.LCS.MIT.EDU
    cc: Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, Barth@MC.LCS.MIT.EDU
    I admit ignorance as well... when I see a "disowned" job on an ITS, its
    usually associated with some username somewhere.
                    ----------begin forwarded mail----------
    Date: Wed, 26 Mar 86 23:17:29 EST
    From: Richard Barth <BARTH@MC.LCS.MIT.EDU>
    To: MBECK@MC.LCS.MIT.EDU
    Ignorant question for today...
    What's the difference between running a job in the background and
    disowning it?

beyond my limited technical ability to describe. someone on this list should
be able to help you more.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAR 86  07:57:25 EST
Date: Sat, 29 Mar 86 07:58:39 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  So why did I bother you?
To: BUG-ITS@AI.AI.MIT.EDU
In-reply-to: Msg of Sat 29 Mar 86 05:40:15 EST from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].865489.860329.ALAN>

    Date: Sat, 29 Mar 86 05:40:15 EST
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    Well I just noticed that right now all new files on AI are being placed
    on the secondary pack!

This turned out to be easy to fix.  If the pack on unit #0 had enough free
space, ITS never noticed that it was not a primary pack.  I fixed ITS to
find a primary pack the first time someone writes a file after a boot.
\1f
Date: Sat, 29 Mar 86 05:40:15 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].22278.860329.ALAN>

When I booted AI Friday morning, I wanted to test that I had built a
working front-end filesystem and DSKDMP on the secondary pack.  Since both
the 8080 front end and DSKDMP assume they should boot from unit #0, I
switched the unit number plugs so that the secondary pack was on unit #0
and the primary pack was on unit #1.

Well I just noticed that right now all new files on AI are being placed on
the secondary pack!  Yesterday, with the units arranged the other way files
were being made on PK0: just like the should have.  Perhaps this is some
unforseen result of my decision to number the secondary pack #1?  (I should
have chosen #13 to be conventional, but couldn't think of any reason why I
couldn't choose any number I wanted.)  Barf.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAR 86  00:51:46 EST
Date: Sat, 29 Mar 86 00:53:03 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  crash;crash massbs:  I see no unit #1 here.
To: MLY@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 28 Mar 86 11:20:19 EST from Richard Mlynarik <MLY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].865339.860329.ALAN>

    Date: Fri, 28 Mar 86 11:20:19 EST
    From: Richard Mlynarik <MLY at MC>
    pi level 2 bughalt

Apparently the controller told ITS that drive #1, which I believe is
powered off, was asking for attention.  (Perhaps it was wondering when DEC
was coming back with the part they need to fix it.)  When ITS obligingly
asked the controller to ask the drive what its status was, the controller
reported that it timed out on the drive.  I guess we write this one off to
hardware flakeiness.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86  11:18:57 EST
Date: Fri, 28 Mar 86 11:20:19 EST
From: Richard Mlynarik <MLY@MC.LCS.MIT.EDU>
Sender: MLY5@MC.LCS.MIT.EDU
Subject: crash;crash massbs
To: BUG-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].864552.860328.MLY5>

pi level 2 bughalt
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86  09:17:59 EST
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 28 Mar 86 09:04:06 EST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449266; Fri 28-Mar-86 08:52:48-EST
Date: Fri, 28 Mar 86 09:00 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: where do sources live?
To: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>, ALAN@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU
In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Thu, 27 Mar 86 17:25:42 EST
    From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>

    Why not delete sources from MC to prevent forking?

Why not take the phones and phone books out of your office on the
grounds you have sets at home?

\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86  09:02:44 EST
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 28 Mar 86 09:04:06 EST
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449266; Fri 28-Mar-86 08:52:48-EST
Date: Fri, 28 Mar 86 09:00 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: where do sources live?
To: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>, ALAN@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU
In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Thu, 27 Mar 86 17:25:42 EST
    From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>

    Why not delete sources from MC to prevent forking?

Why not take the phones and phone books out of your office on the
grounds you have sets at home?

\1f
Date: Fri, 28 Mar 86 09:02:47 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  A new ITS is born
To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU,
    KARENS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].22057.860328.ALAN>

MIT-MX came up for the first time this morning.  (You can supdup there
right now, but you won't find much when you get there...)  There are still
some problems with the technology for creating new ITS systems from
scratch, but it mostly works.  Hopefully after doing the next two (ML and
MD) things will be pretty smooth.

All kind of worms are crawling out of the woodwork because of various
programs that -know- that all ITS machines are named "AI", "MC", "ML", or
"DM".  It should take another days hacking to stomp them all...
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86  09:00:09 EST
Date: Fri, 28 Mar 86 09:01:33 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  where do sources live?
To: GUMBY@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
In-reply-to: Msg of Thu 27 Mar 86 17:25:42 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].864470.860328.ALAN>

    Date: Thu, 27 Mar 86 17:25:42 EST
    From: David Vinayak Wallace <GUMBY at MC>
    Why not delete sources from MC to prevent forking?

Because I think in would be a good idea for them to get on the last full
dump of MC.
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAR 86  17:24:48 EST
Date: Thu, 27 Mar 86 17:25:42 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject:  where do sources live?
To: ALAN@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 27 Mar 86 16:59:17 EST from Alan Bawden <ALAN at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>

Why not delete sources from MC to prevent forking?
\1f
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAR 86  16:58:22 EST
Date: Thu, 27 Mar 86 16:59:17 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
To: JTW@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].863829.860327.ALAN>

Pinhead!  You modified MC:SYSNET;TELSER instead of AI:SYSNET;TELSER.
If people make pinheaded mistakes like this we will be up to our
necks in forked sources.

Everybody:  Remember that sources live on AI!  If you are in doubt,
look for a file named " MOVED TO AI " on the directory containing
the source in question on MC.  If this file exists, then all of
the sources on that directory now live on AI.  This has
been true of all SYS*** directories for a couple of days now.
\1f
Date: Sun, 23 Mar 86 21:27:35 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  Grand migration begins
To: BUG-ITS@AI.AI.MIT.EDU, BUG-DDT@AI.AI.MIT.EDU,
    KS-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].20774.860323.ALAN>

OK this is it.  The migration of ITS system files from MC to AI is
beginning.  I have already moved a few directories and mailing lists and
having just moved Bug-ITS and Bug-DDT to AI, I thought I would test them by
informing you all of how this migration will work.  I expect to have most
of the SYS*** directories moved to AI by tomorrow.  If you have some
question about the status of a particular directory, look for a file on
that directory named " MOVED TO AI ".  If that file exists, then the file
you are looking for now lives on AI, edits on MC are likely to be lost.  If
that file doesn't exist, then MC still has the master copy.  In any case,
if I am logged in, be cautious about timing screws.
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 MAR 86  16:31:26 EST
Received: from R20.UTEXAS.EDU by AI.AI.MIT.EDU.ARPA; 23 Mar 86 10:09:54 EST
Received: from ALAMO.UTEXAS (ALAMO.UTEXAS.EDU.#Internet) by R20.UTEXAS.EDU with TCP; Sun 23 Mar 86 09:08:28-CST
Date: Sun, 23 Mar 86 09:06 CST
From: Gavan Duffy <AI.DUFFY@UTEXAS-20.UTEXAS>
Subject: LMSEND
To: BUG-ITS@MIT-AI.ARPA
Message-ID: <860323090604.3.GAVAN@ALAMO.UTEXAS>

It isn't on AI. Sigh.  I had to CHTN to Jimi Hendrix to QSEND.

\1f
Date: Mon,  3 Mar 86 02:12:36 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  " mode in PEEK
To: BUG-ITS@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN>

I added a new mode to PEEK for printing the contents of the system message
buffer.  (Type a doublequote to get it.)  This is especially useful for
looking at crash dumps.  While I was at it I added a few features to crash
dump mode itself.  For a good example try (on AI):
:PEEK <CRASH;IMP NXM
and after looking at the crash dump display, type " to see some more
interesting error messages.
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 FEB 86  23:32:35 EST
Date: Wed, 26 Feb 86 23:35:16 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: ai crashed again
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].16595.860226.CENT>

not just with the NXM during DUMP lossage. it got that (during the CHECK
phase) and proceeded immediately to an MTAPE:RH11 error, IMP:I NXM...
dumped to CRASH;IMP NXM. so i reloaded and tried to run ICHECK on the
tape. it got a DSK ERR UNTI#0... BUGPC/CAI QHE+3  $Q-2/SKIPGE Q,,QSDU
dumped to CRASH;DISK ERR.
the second time, ICHECK worked.
\1f
Date: Tue, 25 Feb 86 14:02:21 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject:  Disk error
To: BUG-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].830224.860225.GUMBY>

MC crashed, it looks like because it thought one of the tridents had
been powered off.  I doubt anybody cares, but I dumped it to CRASH
QINTE0 just in case.
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 FEB 86  13:36:26 EST
Date: Mon, 24 Feb 86 13:38:49 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].16000.860224.ALAN>

Well, basically I don't seem to ever be able to get the space to end of
tape operation to work for me.  Symptom:  Mount a scratch tape and copy
some files onto it (using :COPY for example).  Rewind the tape (using the
REWIND command in DUMP).  Open MT0: in .BIO mode and issue a 
.MTAPE [ch,,[10]], while watching the drive.  Observe that it clearly
doesn't go to the end of the tape.  Do the same UUO again without closing
the channel and get an IRRECOVERABLE DATA ERROR.

We are certainly going to need space-to-end-of-tape to work before we can
start doing GFRs on a regular basis, since I understand GFR tapes are
just appended together.

Another oddity:  Suppose you wrote three files on the tape.  Rewind the
tape and try reading them (using :PRINT).  Observe that it looks like there
is an extra, fourth, empty file after the files you wrote (before you start
getting DEVICE FULL, which I presume is what you expect to get at the end
of the tape).
\1f
Date: Mon, 24 Feb 86 13:14:44 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  This tape misery never ends.
To: BUG-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].828798.860224.ALAN>

A fellow just tried to read a 7-track tape (from ML) on AI's tape drive.
The results were pretty interesting.  He certainly didn't get any bits back
and he caused DUMP and the magtape code to get pretty upset.  The real fun
started when he tried to kill the DUMP job.  His DDT got hung up in .UCLOSE
at MTICL+12 waiting for outstanding tape commands to go away.

I took a crash dump in AI:CRASH;MTAPE CLOSE.  Note that some interesting
error messages from the tape driver were printed on the system console
before this happened.

I'll bet lots of pinheads try this in the future.  Perhaps we sould license
people before they can run DUMP?
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 FEB 86  00:30:33 EST
Date: Wed, 19 Feb 86 00:32:01 EST
From: "Christopher C. Stacy" <CSTACY@AI.AI.MIT.EDU>
Subject: KS10 crash
To: BUG-ITS@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].14598.860219.CSTACY>

AI crashed in the IMP code (at IMPIOS+4).  I dumped it to CRASH;CSTACY IMPOS.
\1f
Date: Fri, 24 Jan 86 02:24:13 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  pifail again
To: BUG-ITS@MC.LCS.MIT.EDU
cc: CENT@AI.AI.MIT.EDU
In-reply-to: Msg of Fri 24 Jan 86 01:20:52 EST from Pandora B. Berman <CENT5%AI.AI.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].794321.860124.ALAN>

    Date: Fri, 24 Jan 86 01:20:52 EST
    From: Pandora B. Berman <CENT5 at AI>
    Re:   pifail again
    is the name of the latest crash dump, again during an incr. dump.

NXM on the Unibus again.  This time the victimized instruction:

MGWJD1: IORDI T,%TMCS1          ;Get controller status

Unfortunately, all of a sudden Penny seems unable to get through an
incremental dump without having this (or some Unibus NXM) happen.  (Unlike
the Chaos net board glitch the other day which only happened once.)  Maybe
the LH/DH really -does- have something to do with this?  Or perhaps someone
needs to physically tighten up everything on that Unibus.
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86  02:08:01 EST
Date: Fri, 24 Jan 86 01:20:52 EST
From: "Pandora B. Berman" <CENT5%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
Subject: pifail again
To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].11649.860124.CENT5>

is the name of the latest crash dump, again during an incr. dump.
\1f
Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JAN 86  14:50:57 EST
Date: Tue 21 Jan 86 14:49:58-EST
From: John Wroclawski <JTW%MIT-SPEECH@MIT-MC.ARPA>
Subject: Re: ai crash
To: Moon@SCRC-STONY-BROOK.ARPA
cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU,
    CENT@AI.AI.MIT.EDU
In-Reply-To: Message from "David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>" of Tue 21 Jan 86 14:15:38-EST


    Does anyone know how long the NXM timeout on a KS10 unibus is?  The
    Chaos board can be slower to respond (3 or 4 microseconds?) when you
    read it twice in a row, as I recall.

I think I remember it being 20 us.

    Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each
    other?  If not, connecting a Unibus cable between them might cause
    electrical problems.

That's a thought; they're not.

I'm inclined to write this off to cosmic rays, and worry about it if it
ever happens again after the hardware configuration of that unibus
settles down.
-------
\1f
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 21 Jan 86 14:05:53 EST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397698; Tue 21-Jan-86 13:51:23-EST
Date: Tue, 21 Jan 86 13:51 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: ai crash
To: JTW@MIT-MC.ARPA
cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-ITS@MC.LCS.MIT.EDU,
    KS-ITS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU
In-Reply-To: <[MC.LCS.MIT.EDU].790256.860120.ALAN>
Message-ID: <860121135123.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 20 Jan 86 23:00:11 EST
    From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>

        Date: Mon, 20 Jan 86 22:32:34 EST
        From: Pandora B. Berman <CENT at AI>
        dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt
        complained about. see log for numbers. it was checking the incr. dump
        when this happened. after AI came up, the first time i tried to run
        ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE
        IN DEV. HUNG or something -- see sys log for details. the second time
        i tried ICHECK, it worked.

    The immediate cause of the crash was here in the interrupt level Chaos net
    code:

    CHSRC5:     IORDI B,CAIRBF          ;Read out the data, halfwords
            IORDI C,CAIRBF

    The second read from CAIRBF got a Non-Existent I/O Register error; just
    like someone had suddenly unplugged the Chaos board.  

I have a vague memory that Chaos boards do this sometimes.  I hope I'm wrong.
Alan and I discussed kludges for making the software resilient to this, but
I hope we don't have to resort to them.  It would be in the grand tradition
of the previous two MIT-AI machines, though.

                                                          If there were system
    messages from the magtape code indicating that it was unhappy as well, then
    perhaps we can conclude that the fault happened somewhere in the "I" Unibus
    itself.  (It would be nice if :SYSMSG worked on a crash dump!)

I used to have a program to do this, I think.  Better would be to stick SYSMSG
inside PEEK and then take advantage of PEEK's existing crash-dump-analysis feature.

    Perhaps someone who knows more Unibusology than I do can offer an opinion
    about what might cause this?  Remember that this is the Unibus that
    supports the magtape drive, the DZ11's and the Chaosnet interface.  The
    magtape code was shooting bits back and forth like crazy at the time,
    presumably that contributed somehow?

    JTW:  Is the LH/DH plugged into this bus right now?  Perhaps it did
    something nasty?

JTW: Can you look at the crash dump and figure out whether the magtape RH-11
was supposed to be doing DMA at the time this crash happened?  Maybe it and
the Chaos board interfere with each other somehow?

Does anyone know how long the NXM timeout on a KS10 unibus is?  The Chaos
board can be slower to respond (3 or 4 microseconds?) when you read it twice
in a row, as I recall.

Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each other?  If not,
connecting a Unibus cable between them might cause electrical problems.

\1f
Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86  23:12:00 EST
Date: Mon 20 Jan 86 23:11:02-EST
From: John Wroclawski <JTW%MIT-SPEECH@MIT-MC.ARPA>
Subject: Re: ai crash
To: alan@MC.LCS.MIT.EDU
cc: CENT@AI.AI.MIT.EDU, bug-its@MC.LCS.MIT.EDU
In-Reply-To: Message from "Alan Bawden <ALAN@MC.LCS.MIT.EDU>" of Mon 20 Jan 86 23:06:09-EST

        JTW:  Is the LH/DH plugged into this bus right now?  Perhaps it did
        something nasty?

Yes, and maybe so. Specially since it doesn't seem to work like it is
supposed to right at the moment. It would be nice to know the state
of the UBA at that point in time...
-------
\1f
Date: Mon, 20 Jan 86 23:00:11 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  ai crash
To: BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
cc: CENT@AI.AI.MIT.EDU
In-reply-to: Msg of Mon 20 Jan 86 22:32:34 EST from Pandora B. Berman <CENT%AI.AI.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].790256.860120.ALAN>

    Date: Mon, 20 Jan 86 22:32:34 EST
    From: Pandora B. Berman <CENT at AI>
    dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt
    complained about. see log for numbers. it was checking the incr. dump
    when this happened. after AI came up, the first time i tried to run
    ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE
    IN DEV. HUNG or something -- see sys log for details. the second time
    i tried ICHECK, it worked.

The immediate cause of the crash was here in the interrupt level Chaos net
code:

CHSRC5: IORDI B,CAIRBF          ;Read out the data, halfwords
        IORDI C,CAIRBF

The second read from CAIRBF got a Non-Existent I/O Register error; just
like someone had suddenly unplugged the Chaos board.  If there were system
messages from the magtape code indicating that it was unhappy as well, then
perhaps we can conclude that the fault happened somewhere in the "I" Unibus
itself.  (It would be nice if :SYSMSG worked on a crash dump!)

Perhaps someone who knows more Unibusology than I do can offer an opinion
about what might cause this?  Remember that this is the Unibus that
supports the magtape drive, the DZ11's and the Chaosnet interface.  The
magtape code was shooting bits back and forth like crazy at the time,
presumably that contributed somehow?

JTW:  Is the LH/DH plugged into this bus right now?  Perhaps it did
something nasty?
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86  22:32:38 EST
Date: Mon, 20 Jan 86 22:32:34 EST
From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
Subject: ai crash
To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].11362.860120.CENT>

dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt
complained about. see log for numbers. it was checking the incr. dump
when this happened. after AI came up, the first time i tried to run
ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE
IN DEV. HUNG or something -- see sys log for details. the second time
i tried ICHECK, it worked.
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86  16:03:59 EST
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JAN 86  16:04:12 EST
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 17 Jan 86 16:03:39 EST
Date: Fri 17 Jan 86 15:31:41-EST
From: J. J. Tyrone Sealy <TY@XX.LCS.MIT.EDU>
Subject: Re: tape lossage
To: Moon@SCRC-STONY-BROOK.ARPA
cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU,
    TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
In-Reply-To: <860117134457.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12176026589.28.TY@XX.LCS.MIT.EDU>

If you can come over. Please do. Unless there is someone else that can fix it.
                                tnx..--TY
-------
\1f
Date: Fri, 17 Jan 86 15:51:48 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  tape lossage
To: CENT@AI.AI.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, TY@MC.LCS.MIT.EDU,
    Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Fri 17 Jan 86 13:44 EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].787522.860117.ALAN>

    Date: Fri, 17 Jan 86 13:44 EST
    From: David A. Moon <Moon at SCRC-STONY-BROOK>
        Date: Fri, 17 Jan 86 07:43:58 EST
        From: "Pandora B. Berman" <CENT at AI>
        i wandered over to bring up MC when it crashed, and noticed tape 4000
        on the drive. apparently Ty was running a full dump. the dump log
        contains a note on the MC 4000 line: "Something happened". dave,
        didn't you say something about 4000 being the max. number for an
        ITS tape? how does this get fixed?
    I don't recall saying that.  There is a limit on the highest tape number
    that's controlled by the size of the SYSENG;MACRO TAPES file.  The limit
    can be changed; I don't remember how, but it involves code in DUMP that's
    commented something like "Don't do this unless you are RJL, and even then
    be careful."  We probably don't need to import RJL to do it.  If you need
    me to come over and figure out the details, ask.

This limit must have been reached in the past since the full dump tapes
recorded in the database only go back to some time in 1983.  

But just in case, I figured out the way to change the limit and upped it to
5000.  So we probably don't need to worry about this limit on MC ever
again...
\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86  13:49:12 EST
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JAN 86  13:49:23 EST
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 17 Jan 86 13:48:45 EST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 395098; Fri 17-Jan-86 13:44:24-EST
Date: Fri, 17 Jan 86 13:44 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: tape lossage
To: Pandora B. Berman <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
cc: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU,
    TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].11164.860117.CENT>
Message-ID: <860117134457.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 17 Jan 86 07:43:58 EST
    From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>

    i wandered over to bring up MC when it crashed, and noticed tape 4000
    on the drive. apparently Ty was running a full dump. the dump log
    contains a note on the MC 4000 line: "Something happened". dave,
    didn't you say something about 4000 being the max. number for an
    ITS tape? how does this get fixed?

I don't recall saying that.  There is a limit on the highest tape number
that's controlled by the size of the SYSENG;MACRO TAPES file.  The limit
can be changed; I don't remember how, but it involves code in DUMP that's
commented something like "Don't do this unless you are RJL, and even then
be careful."  We probably don't need to import RJL to do it.  If you need
me to come over and figure out the details, ask.

\1f
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86  07:43:43 EST
Date: Fri, 17 Jan 86 07:43:58 EST
From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
Subject: tape lossage
To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
cc: TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, MOON%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].11164.860117.CENT>

i wandered over to bring up MC when it crashed, and noticed tape 4000
on the drive. apparently Ty was running a full dump. the dump log
contains a note on the MC 4000 line: "Something happened". dave,
didn't you say something about 4000 being the max. number for an
ITS tape? how does this get fixed?
\1f
Date: Sat, 11 Jan 86 18:25:45 EST
From: Chris Hanson <CPH@MC.LCS.MIT.EDU>
Subject:  Losing Dialup
To: BUG-SYSTEM@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].780740.860111.CPH>

When I dial x6985, I am getting a connection which responds to my
carriage return with the standard "Connected to MC.", but then it
fails to give me a HACTRN.  C-Z has no effect.

I notice that *nobody* is logged in from a dialup.  This seems like it
might be related.
\1f
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  6 Jan 86 04:47:57 EST
Received: from bostonu by csnet-relay.csnet id ac02199; 6 Jan 86 4:39 EST
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
        id AA14297; Sun, 5 Jan 86 17:08:56 est
Date: Sun, 5 Jan 1986  17:09 EST
Message-Id: <[BUCS20].JSOL. 5-Jan-86 17:09:02>
From: Jon Solomon <JSOL%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA>
To: Alan Bawden <mit-eddie!ALAN%MC.LCS.MIT.EDU@bu-cs.bunet>
Cc: BUG-ITS@mit-mc.arpa, BUG-MAIL@mit-mc.arpa, BUG-RANDOM-PROGRAM@mit-mc.arpa, 
    KS-ITS@mit-mc.arpa
Subject: [JSOL: TELECOM]  Consider this a warning.
Phase-Of-The-Moon: LQ+2D.21H.36M.2S.
In-Reply-To: Msg of 5 Jan 1986  15:26-EST from Alan Bawden <mit-eddie!ALAN%MC.LCS.MIT.EDU at bu-cs>

Okay, now I know the intended audience for my message. One fact that
I forgot to mention in the other message was that this JUST started
happening about a week ago. Whoever is hacking COMSAT, please take note.

Thanks,
--JSol


\1f
Date: Sun,  5 Jan 86 15:26:51 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  [JSOL: TELECOM]  Consider this a warning.
To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
    BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].773515.860105.ALAN>

    MSG:  *MSG   4866  
    Date: 01/05/86 13:22:00 
    From: JSOL at XX.LCS.MIT.EDU
    To:   *BBOARD at XX.LCS.MIT.EDU
    Re:   TELECOM

    Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU  5 Jan 86 13:21:49 EST
    Date: Sun 5 Jan 86 13:24:23-EST
    From: Jon Solomon <JSOL@XX.LCS.MIT.EDU>
    Subject: TELECOM
    To: BBOARD@MC.LCS.MIT.EDU
    Message-ID: <12172857686.19.JSOL@XX.LCS.MIT.EDU>

    Due to the installation of a new mail system, I can no longer ship off
    TELECOM to MC. Since there are quite a large number of MC users on
    TELECOM, and considering the fact that this restriction might affect
    other digests, I am sending this message to your bulletin board rather
    than individually to MC users.

I -believe- what he is refering to is the fact that digests tend to be
large enough that they exceed COMSAT's pitifully small size limitation.

I note that CSTACY claimed the lock for hacking COMSAT two weeks ago,
hacked on it for an evening, and hasn't logged in since then.

There are now about 130 BADREQ files on .MAIL2, many of them 2 weeks old.
(I'm going to have to create .MAIL3 soon...)

Warning:  If the day ever comes that I feel that it is Up-To-Me-
To-Do-Something about COMSAT (because of address space problems, lack of
proper domain support, or whatever) I will simply advise everybody that ITS
no longer supports mail for users or mail forwarding for the network and I
will shut it off.

I feel this day -rapidly- approaching.  I don't see any competent
programmers making the kind of necessary effort it is going to take to
straighten out this mess.  I am forwarding this message to a large audience
in the hopes that somebody will get inspired, but I realize this is
grasping at straws.
\1f
Date: Fri,  3 Jan 86 00:33:24 EST
From: "J. Noel Chiappa" <JNC@MC.LCS.MIT.EDU>
Subject: Static routes in MC's routing table
To: BUG-TCP@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, JNC@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].771596.860103.JNC>

        There are way too many (old) static routes in the table. They
don't seem to get updated correctly; data for SCRC was going through the
(loaded) MIT-GW instead of the (idle) MIT-AI-GW, although the rest
of the Internet got the change months ago. Someone should delete all
but the necessary ones. I deleted the SCRC one and patched it out in the
running system, with the result that it instantly picked up the right one.
        Also, the ICMP Redirect code is not the best possible in that
it does no handle per-Host Redirects well; it folds them all into
the single net entry. When we start attaching ITSen to subnetted nets,
this will lose big; traffic to different subnets will thrash the
cache line. For that matter, the ITS IP layer doesn't use the correct
'mask' algorithm for dealing with host addresses (per RFC940, etc).
\1f
Date: Sat, 28 Dec 85 19:00:48 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject:  page fault in system
To: GUMBY@MC.LCS.MIT.EDU
cc: HIC@MC.LCS.MIT.EDU, POOR-MC@MC.LCS.MIT.EDU,
    BUG-ITS@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 22 Dec 85 15:21:29 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].767454.851228.ALAN>

[ Why are we Cc'ing this message to HIC? ]

    Date: Sun, 22 Dec 85 15:21:29 EST
    From: David Vinayak Wallace <GUMBY at MC>
    ITS took a page fault.  Look in CRASS PAGFLT if you care.

Specifically, ITS took a page fault running in the scheduler.  It thought
it was looking at somebody's USTP bits, but U contains gubbish, and it
looks like the hardware pagetable must have contained some kind of a joke
as well.  I am tempted to agree with you that this was the result of
glitch.  (That must be what you think since you mailed this to Poor-MC,
right?)

    PS: Someone seems to have deleted the pooor-mc alias.

I don't think it ever really had that name, at least not for long.  I
suggested it, but I think somebody corrected my joke thinking it was a typo
almost instantly.
\1f
Date: Mon, 23 Dec 85 05:50:31 EST
From: Gail Zacharias <GZ@MC.LCS.MIT.EDU>
Subject:  Compression
To: ALAN@MC.LCS.MIT.EDU
cc: BUG-ITS@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU,
    LIN@MC.LCS.MIT.EDU, PGS@OZ.AI.MIT.EDU
In-reply-to: Msg of Mon 16 Dec 85 15:46:52 EST from Alan Bawden <ALAN at MIT-MC.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].764485.851223.GZ>

AR4:GZ;ENCODE and DECODE.  Encoding a large text file typically gives
a little over half of the original size.
\1f
Date: Mon, 23 Dec 85 00:22:08 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: IBO
To: BUG-ITS@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].764318.851223.GSB>

I just got "IBO" on the dialups.  i tried 6985, 6986, and 6989 for
good measure...
\1f
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Dec 85 14:30:51 EST
Date: Thu 19 Dec 85 14:02:59-EST
From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Subject: Re: ICMP: GW table full
To: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, bug-tcp@MC.LCS.MIT.EDU
cc: JNC@XX.LCS.MIT.EDU
In-Reply-To: <[MIT-MC.ARPA].757281.851216.ALAN>
Message-ID: <12168408267.46.JNC@XX.LCS.MIT.EDU>

        This is a harmless message. The IP routing table (see PEEK 'W'
display) is a cache of the most recently used routes; when it fills up and
needs to add a new route, it punts the lest recently route. The message
is unnecessary. It would be good to notice if the cache is too small
(e.g. if the route discarded was used less than five minutes ago) and
log that; it might also be good to add a count of the number of cache
flushes and the number flushed in, say, the last hour.
-------
\1f
Date: Mon, 16 Dec 85 23:20:56 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject: ICMP: GW table full
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].757281.851216.ALAN>

If you run SYSMSG on MC you will generally find that the message buffer
is 90% full of messages of the form:
ICMP: GW table full, net/gw 20024,,600000 1200,,76 =>  30001,,255000 1200,,400045 MON 22:07:12
I presume this all means something to KLH and the rest of you TCP hackers,
but to me it is just an annoying amount of output that seems to be associated
no problem that I can see.  Is this a symptom of a real problem, or does it
just mean that some fixed size table should be made a little larger?  Or
perhaps we should consider not bothering the system console with this
common event, whatever it is.
\1f
Date: Mon, 16 Dec 85 15:46:52 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Compression
To: LIN@MIT-MC.ARPA, GZ@MIT-MC.ARPA, PGS@MIT-OZ
cc: BUG-ITS@MIT-MC.ARPA, GUMBY@MIT-MC.ARPA
In-reply-to: Msg of Mon 16 Dec 1985  13:54 EST from PGS%MIT-OZ at MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].756680.851216.ALAN>

    Date: Mon, 16 Dec 1985  13:54 EST
    From: PGS at OZ
        Date: Monday, 16 December 1985  12:08-EST
        From: David Vinayak Wallace <GUMBY at MC>
        do you know about the ARx devices?

    I don't think those perform text compression, do they?

No, they don't.  They make a collection of small files take less space on
disk by removing the average of half a block of wasted space at the end of
every file.  They also take up less room in your directory because the
names of the files are stored in the archive itself, leaving only one entry
stored in your directory.

If you are looking for a program that compresses ASCII text by taking
advantage of the fact that certain sequences of characters are more common
than others, I think that Gail Zacharias (GZ@MC) has the best program for
this that I have seen.  I can't seem to find it at the moment though. Gail?
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 16 DEC 85  14:09:24 EST
Date: Mon, 16 Dec 1985  13:54 EST
Message-ID: <PGS.12167620265.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Cc:   BUG-ITS@MIT-MC.ARPA, LIN@MIT-MC.ARPA
In-reply-to: Msg of 16 Dec 1985  12:08-EST from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>

    Date: Monday, 16 December 1985  12:08-EST
    From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
    To:   LIN at MIT-MC.ARPA
    cc:   BUG-ITS at MIT-MC.ARPA

    do you know about the ARx devices?

I don't think those perform text compression, do they?
\1f
Date: Mon, 16 Dec 85 12:08:03 EST
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
To: LIN@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Mon 16 Dec 85 11:51:47 EST from Herb Lin <LIN at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].756162.851216.GUMBY>

do you know about the ARx devices?
\1f
Date: Mon, 16 Dec 85 11:51:47 EST
From: Herb Lin <LIN@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].756101.851216.LIN>

help requested from a wizard.  Is there any way of doing rXX text compression
on large text files purely on ITS...  Something analagous to the SQUEEZE 
programs available for micros?

thans.\18XXX

thanks.
\1f
Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 13 DEC 85  01:30:47 EST
Date: Fri, 13 Dec 85 01:28:45 EST
From: "Pandora B. Berman" <CENT%MIT-AI.ARPA@MIT-MC.ARPA>
Subject: ai died
To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA
Message-ID: <[MIT-AI.ARPA].8641.851213.CENT>

ai suddenly hit a PI LEVEL 7 BUGHALT. crash dump to CRASH;SUDDEN LOSS
\1f
Date: Mon,  9 Dec 85 19:41:51 EST
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  oops
To: BUG-SYSTEM@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].747566.851209.GUMBY>

As you can guess, that should have gone to bug-system@oz.  Sorry
\1f
Date: Mon,  9 Dec 85 18:04:22 EST
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  dialup problem
To: CHUNKA@MIT-OZ
cc: BUG-SYSTEM@MIT-MC.ARPA
In-reply-to: Msg of Mon 9 Dec 1985  16:22 EST from Chunka Mui <CHUNKA%MIT-OZ at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].747534.851209.GUMBY>

OZ doesn't have the hardware.  Your modem uses bell's 1200-baud
frequencies.  Vadic uses different ones.
\1f
Date: Sat,  7 Dec 85 19:02:36 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  .msgs.; bloated
To: BUG-COMSAT@MIT-MC.ARPA, CENT@MIT-AI.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Sat  7 Dec 85 06:10:23 EST from Pandora B. Berman <CENT%MIT-AI.ARPA at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].745744.851207.ALAN>

    Date: Sat,  7 Dec 85 06:10:23 EST
    From: Pandora B. Berman <CENT%MIT-AI.ARPA at MIT-MC.ARPA>
    for reasons unknown, AI can't figure out how to purge obsolete msgs
    from .MSGS.;. it wouldn't do it when the files weren't backed up, but
    i expected that. however, now the files are regularly backed up, the
    _LAST_ EXPIRE file looks well formed, but they -still- don't disappear
    on cue. MC, on the other hand, seems to have no problem in this regard.
    any ideas why?

A Typical message from MC:.MSGS.;*MSG > begins:

    DISTRIB:  *BBOARD
    EXPIRES: 12/14/85 12:38:14
    Received: from BORAX by MIT-MC.ARPA  7 Dec 85 12:38:13 EST

A typical message from AI:.MSGS.;*MSG > begins:

    Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 7 DEC 85  12:37:44 EST
    DISTRIB:  *BBOARD
    EXPIRES: 12/14/85 12:38:14
    Received: from BORAX by MIT-MC.ARPA  7 Dec 85 12:38:13 EST

I suspect the recieved line at the front fakes GMSGS out when it tries to
find the expiration date.  This could be fixed by changing COMSAT to not do
this, or by fixing GMSGS to be smarter.  Somebody else is going to fix this
one.  (I don't think it can be all -that- hard guys!)
\1f
Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 7 DEC 85  06:11:37 EST
Date: Sat,  7 Dec 85 06:10:23 EST
From: "Pandora B. Berman" <CENT%MIT-AI.ARPA@MIT-MC.ARPA>
Subject: .msgs.; bloated
To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA
Message-ID: <[MIT-AI.ARPA].8152.851207.CENT>

for reasons unknown, AI can't figure out how to purge obsolete msgs
from .MSGS.;. it wouldn't do it when the files weren't backed up, but
i expected that. however, now the files are regularly backed up, the
_LAST_ EXPIRE file looks well formed, but they -still- don't disappear
on cue. MC, on the other hand, seems to have no problem in this regard.
any ideas why?
\1f
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 29 Nov 85 23:50:31 EST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364604; Fri 29-Nov-85 23:45:47-EST
Date: Fri, 29 Nov 85 23:44 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Any takers?
To: Alan Bawden <ALAN@MIT-MC.ARPA>
cc: BUG-ITS@MIT-MC.ARPA, BUG-RANDOM-PROGRAM@MIT-MC.ARPA,
    BUG-DDT@MIT-MC.ARPA
In-Reply-To: <[MIT-MC.ARPA].692189.851024.ALAN>
Message-ID: <851129234420.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 24 Oct 85 23:38:25 EDT
    From: Alan Bawden <ALAN@MIT-MC.ARPA>

    With all of these parity errors MC gets these days, and with all of these
    naive users who haven't the slightest idea what to do when they have
    detached job trees, the amount of disowned junk is getting to be a pain.
    Now there is really no good reason why a program couldn't be written that
    would would look around in the system for jobs with your XUNAME and offer
    some intelligent (and clearly explained) choices to you.  Anybody
    interested?  I'm not up for thinking about the problem right now, but I'd
    be happy to brainstorm in person with anyone else who would like to take a
    crack at it.


I'm sure I wrote this at Ellen's request and she put it into the init files of
the known naive Macsyma users.  I think it was called RETACH or something like
that.

\1f
Date: Tue, 29 Oct 85 20:47:43 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Silly lineprinter devices again.
To: INFO-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].697383.851029.ALAN>

Remember the 7LP: and 7LR: devices?  Well, now that we have a third such
device on the 9th floor, and another one coming soon to the 8th, it would
make sense for me to tell you that I have installed 8LP: and 9LP: devices,
right?  WRONG!  Since a clear numbering trend is emerging it makes sense to
change the naming scheme so that the number comes -last-.  So the official
names are now:

        LP7:    The 7th floor QMS 2400
        LP8:    The 8th floor QMS 2400
        LP9:    The 9th floor QMS 1200

        LR7:    The 7th floor laserwriter

The two old names 7LP: and 7LR: continue to work for compatibility.
\1f
Date: Sun, 27 Oct 85 22:20:53 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  echoing weirdness
To: GRENNY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Sun 27 Oct 85 20:08:43 EST from Ian Macky <GRENNY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].694733.851027.ALAN>

    Date: Sun, 27 Oct 85 20:08:43 EST
    From: Ian Macky <GRENNY at MC>
    *fr^K!a l
    e
    [There goes GZ]
    cTo OAF.G.BRIDGET@MIT-OZ:
    ittle pkish, perhaps... <End>

    [the "ec" from "peckish" got echoed before anything else... how WEIRD!!
    (well, not before everything, but you see)]

Just another wierd case with echoing input at interrupt level.  ITS decides
how to do interrupt level echoing by looking at what job currently has
control of the TTY.  In this case DDT had control of the TTY for a few
moments while it typed the Argus message, so ITS echoed the two characters
you typed during those moments.  (I guess FR is looking at %TXPIE bits in
character to determine how to echo the user's typeahead.)

I'm suprised that FR and REPLY aren't handling %PIATY interrupts.  If they
were you wouldn't have seen this happen.  SEND seems to be hacking %PIATY;
why should SENDER vary this aspect of its behavior for replying vs. sending?
\1f
Date: Sun, 27 Oct 85 20:08:43 EST
From: Ian Macky <GRENNY@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].694678.851027.GRENNY>

echoing weirdness:

*fr^K!a l
e
[There goes GZ]
cTo OAF.G.BRIDGET@MIT-OZ:
ittle pkish, perhaps... <End>

[the "ec" from "peckish" got echoed before anything else... how WEIRD!!
(well, not before everything, but you see)]
\1f
Date: Thu, 24 Oct 85 23:38:25 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Any takers?
To: BUG-ITS@MIT-MC.ARPA, BUG-RANDOM-PROGRAM@MIT-MC.ARPA,
    BUG-DDT@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].692189.851024.ALAN>

With all of these parity errors MC gets these days, and with all of these
naive users who haven't the slightest idea what to do when they have
detached job trees, the amount of disowned junk is getting to be a pain.
Now there is really no good reason why a program couldn't be written that
would would look around in the system for jobs with your XUNAME and offer
some intelligent (and clearly explained) choices to you.  Anybody
interested?  I'm not up for thinking about the problem right now, but I'd
be happy to brainstorm in person with anyone else who would like to take a
crack at it.
\1f
Date: Tue, 22 Oct 85 14:29:28 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  super-image mode/slaved ttys
To: GUMBY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, ED@MIT-MC.ARPA
In-reply-to: Msg of Tue 22 Oct 85 00:14:31 EDT from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].688804.851022.ALAN>

    Date: Tue, 22 Oct 85 00:14:31 EDT
    From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
    ...
    1> I know he's on the same kind of terminal I am, so I want whatere
       goes down the wire to his terminal to go down the wire to mine.

    2> I want the system to hack ^P codes for me so that I can poke around
       even if our terminals don't match.

    In my previous letter I was asking for 1> above, but two would be more
    useful in most cases.  By "escape code" I meant some ^_ code to tell
    ITS just to pump the characters through.
    ...

Getting any scheme like 2 to work is probably impossible.  What do you do
if the guy's terminal supports insert and delete character and yours
doesn't?  What about if his terminal is 5 lines longer than yours?  Even
virtual terminals have characteristics that are visible to the programs
that use them.

1 could be made to work I guess.  You would have to do it at the level of
%TD codes rather than ^P codes (since that is the only level at which there
is really a universal language).  There is a bunch of other things you have
to worry about I guess, like making sure the characters you type get echoed
in the way his program desires.  Given that it can only work some of the
time, and that it is pretty hard to get right, I can think of better things
to do with our time.
\1f
Date: Tue, 22 Oct 85 00:14:31 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  super-image mode/slaved ttys
To: ALAN@MIT-MC.ARPA, ED@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-Reply-to:
        Msg of Mon, 21 Oct 85 13:48:07 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
        Msg of Mon, 21 Oct 85 18:23:37 EDT from Ed Schwalenberg <ED at MIT-MC.ARPA>,
Message-ID: <[MIT-MC.ARPA].687999.851022.GUMBY>

    Date: Mon, 21 Oct 85 13:48:07 EDT
    From: Alan Bawden <ALAN at MIT-MC.ARPA>

        Date: Mon, 21 Oct 85 06:11:40 EDT
        From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>

        Is there any way to get ITS to put your tty in super-image mode via
        escape codes?  Otherwise when you slave a tty you get ghubbish (making
        slaved ttys almost useless.  Are they a pre-TS3TTY relic?).

    I can't figure out what you are asking from this.  First please distinguish
    between super-image input and super-image output (two quite unrelated
    things despite the similarity in names).  Second please distinguish between
    the various kind of escape codes in the ITS world; are you talking about ^P
    codes?  Third, by "slaved ttys" are you refering to the state you can
    achieve in a com-link where one console's type-in is seen by another
    console's job-tree?

    Date: Mon, 21 Oct 85 18:23:37 EDT
    From: Ed Schwalenberg <ED at MIT-MC.ARPA>

    And fourth, is the TTY you are slaving logged-in or free, and what type
    (software, printing, AAA, etc.) is your TTY and the one you're slaving?

Ok.  Let me start over:

Luser :LUSERs me and tells me he can't run BABYL.  BABYL runs fine for
me on his mail file.  I'd like to ^_e him and poke around in the
debugger in his BABYL.  But all I get is ghubbish on my screen.

Two possible ways that ITS could get around this (and maybe both are
desirable for different circumstances):

1> I know he's on the same kind of terminal I am, so I want whatere
   goes down the wire to his terminal to go down the wire to mine.

2> I want the system to hack ^P codes for me so that I can poke around
   even if our terminals don't match.

In my previous letter I was asking for 1> above, but two would be more
useful in most cases.  By "escape code" I meant some ^_ code to tell
ITS just to pump the characters through.

Free vs logged-in isn't relevent to this, since you can :TCTYP a free
tty after sending a CALL through.
\1f
Date: Mon, 21 Oct 85 23:08:10 EDT
From: "Pandora B. Berman" <CENT@MIT-MC.ARPA>
Subject: file system not fukt
To: BUG-SYSTEM@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].687814.851021.CENT>

i should have been using $^R. my mind must be going. sorry to bother you.
\1f
Date: Mon, 21 Oct 85 23:00:01 EDT
From: "Pandora B. Berman" <CENT@MIT-MC.ARPA>
Subject: FILE SYSTEM FUKT
To: BUG-SYSTEM@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].687803.851021.CENT>

i was in ddt, moving some ostats files to third: with $$^O. it worked for
the first one i tried no problem -- this was the second most recently
created ostats file.  then i tried
$$^O ostats >,third:
and got the reply that it can't copy to a different directory -- third:
so i tried specifying the file version
$$^O ostats 3636,third:
and it replied
third: .mail.;ostats 3636 - file exists (!)

clearly someone is real confused here, and i don't think it's me.
\1f
Date: Mon, 21 Oct 85 13:48:07 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  super-image mode
To: GUMBY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Mon 21 Oct 85 06:11:40 EDT from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].687073.851021.ALAN>

    Date: Mon, 21 Oct 85 06:11:40 EDT
    From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
    Is there any way to get ITS to put your tty in super-image mode via
    escape codes?  Otherwise when you slave a tty you get ghubbish (making
    slaved ttys almost useless.  Are they a pre-TS3TTY relic?).

I can't figure out what you are asking from this.  First please distinguish
between super-image input and super-image output (two quite unrelated
things despite the similarity in names).  Second please distinguish between
the various kind of escape codes in the ITS world; are you talking about ^P
codes?  Third, by "slaved ttys" are you refering to the state you can
achieve in a com-link where one console's type-in is seen by another
console's job-tree?
\1f
Date: Mon, 21 Oct 85 06:11:40 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  super-image mode
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].686691.851021.GUMBY>

Is there any way to get ITS to put your tty in super-image mode via
escape codes?  Otherwise when you slave a tty you get ghubbish (making
slaved ttys almost useless.  Are they a pre-TS3TTY relic?).
\1f
Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 10 OCT 85  03:15:49 EDT
Date: Thu, 10 Oct 85 03:15:03 EDT
From: Oded Feingold <OAF%MIT-AI.ARPA@MIT-MC.ARPA>
To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA
Message-ID: <[MIT-AI.ARPA].5013.851010.OAF>

I plugged terminals in and out of TTY07, and eventually the DZ wouldn't
answer anymore.  I reloaded ITS, and left the crash dump on
        DZ SILENT.
I doubt there's much interesting there.
\1f
Date: Mon,  7 Oct 85 18:12:27 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: some job device losing
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].671384.851007.CSTACY>

I can't use any jobdevs right now because there are a whole pile of
what looks like MLDEVs with the jname "CFTP" and channels open on the
file "OZKS: ;".  I am going to gun them down, preserving one corpse
CRASH;MLDEV OZ.  The pc is/345 (.HANGing).

\1f
Date: Thu,  3 Oct 85 23:49:07 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Thu  3 Oct 85 15:08:07 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].668221.851003.TIM>

    Date: Thu,  3 Oct 85 15:08:07 EDT
    From: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
    To:   BUG-ITS at MIT-MC.ARPA

    There is a POOR-MC@MC list now.

What's it for?
\1f
Date: Thu,  3 Oct 85 15:08:07 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].667593.851003.CSTACY>

There is a POOR-MC@MC list now.
\1f
Date: Mon, 30 Sep 85 17:37:39 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Pooor MC
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].663719.850930.ALAN>

MC crashed twice today with parity errors in MH10-A (system memory).  The
I/O-11 crashed both times.  I reconfigured the machine to swap MH10-A and
MH10-B so that the next time errors occur in that box they won't be quite
so fatal.  Conceivably someone should log a service call with DEC.  I did
nothing.
\1f
Date: Sat, 28 Sep 85 02:40:59 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
To: GZ@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Fri 27 Sep 85 23:39:45 EDT from Gail Zacharias <GZ at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].661760.850928.ALAN>

    Date: Fri, 27 Sep 85 23:39:45 EDT
    From: Gail Zacharias <GZ at MIT-MC.ARPA>
    I keep getting top-level interrupts, about once every half hour.

They are parity errors.  Nothing that we can do anything about except throw
the memory out the window.  Look at the bright side: some operating systems
would have halted the whole machine every time that happened, rather than
just stopping a few jobs.

I suppose we could make the message the user gets when he gets detached
this way more explicit, but it hardly seems worth the effort given that the
day is fast approaching when ITS will only run on KS10s, which (for the
moment at least) are more reliable hardware.
\1f
Date: Fri, 27 Sep 85 23:39:45 EDT
From: Gail Zacharias <GZ@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].661709.850927.GZ>

I keep getting top-level interrupts, about once every half hour.
\1f
Date: Fri, 27 Sep 85 23:15:08 EDT
From: Gail Zacharias <GZ@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].661707.850927.GZ>

I keep getting top-level interrupts, about once every half hour.
\1f
Date: Fri, 27 Sep 85 00:13:26 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Bloat
To: BUG-COMSAT@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].661199.850927.ALAN>

Due to total bloat of .MAIL.; LISTS   MSGS I have created .MAIL2 and moved
many non-essential files there.  Most of the queued mail is destined for OZ
which will hopefull be up sometime tomorrow (so they tell me).  COMSAT
features that would be nice in a situation like this:

        It would be nice to be able to tell COMSAT to take all mail
destined for a particular host and dump it all in some file somewhere and
forget about it for a few days.  Bouncing failed mail back to senders is
counter-productive in a situation like the current one.

        It would be nice if COMSAT was smarter about the finite directory
size.  For example, if it looks to COMSAT like there might not be room to
GC the LISTS MSGS file in place, it could output the new LISTS MSGS on a
different directory (effectively doubling the available room for a GC).

        Easiest of all, perhaps you could set things up so that LISTS MSGS
and the MAIL > files didn't live on the same directory?  Having COMSAT's GC
fighting for space with mail servers is moderately annoying at times.
\1f
Date: Tue, 24 Sep 85 05:07:32 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Now installed on AI, and soon to be installed on MC.
To: INFO-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].657412.850924.ALAN>

There is now a demon job that runs when ITS starts up that attempts to set
the time from the network.  The message that the system types out at boot
time when it discovers that the clock has been reset no longer commands the
hacker to log in and run PDSET, instead it tells him that he should just
stick around a watch what happens in case he has to run it.  The demon will
print a message on the system console explaining what it did about the
time.  If the demon was unsatisfied that it could determine the time, the
message will try to attract the hacker's attention and explain to him what
the problem was and tell him that he does have to run PDSET after all.
\1f
Date: Sat, 21 Sep 85 17:34:46 EDT
From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].653477.850921.DEVON>

I keep getting toplevel interrupts (presumably parity errors?)
detaching my tree, twice in the last three hours.
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 20 SEP 85  15:13:46 EDT
Date: Fri, 20 Sep 1985  15:14 EDT
Message-ID: <PGS.12144817429.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   "Ronald I. Greenberg" <RIG@MIT-MC.ARPA>, devon@MIT-MC.ARPA
Cc:   BUG-ITS@MIT-MC.ARPA, bug-tctyp@MIT-MC.ARPA
Subject: terminal handler for heath
In-reply-to: Msg of 20 Sep 1985  13:33-EDT from Ronald I. Greenberg <RIG at MIT-MC.ARPA>

    Date: Friday, 20 September 1985  13:33-EDT
    From: Ronald I. Greenberg <RIG at MIT-MC.ARPA>
    To:   BUG-ITS at MIT-MC.ARPA
    Re:   terminal handler for heath

         It appears that the terminal handler for heath terminals has been
    screwed up.  Using either an actual heath or a Zenith Z-29-A,
    ":tctyp heath" results in something weird.  A "?2h" gets printed on the
    terminal, and ocassionally at some point in time (generally when you
    get to the bottom of the screen I think) the terminal becomes totally
    wedged.  This has been noticed by me and several other members of the
    Theory Group for the last couple days.

I guess I was wrong.  Devon, why don't you NOT put whatever you think is
right in the TCTYP initialization string and instead re-install the old
source and binaries.
\1f
Date: Fri, 20 Sep 85 13:33:15 EDT
From: Ronald I. Greenberg <RIG@MIT-MC.ARPA>
Subject:  terminal handler for heath
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].652278.850920.RIG>

     It appears that the terminal handler for heath terminals has been
screwed up.  Using either an actual heath or a Zenith Z-29-A,
":tctyp heath" results in something weird.  A "?2h" gets printed on the
terminal, and ocassionally at some point in time (generally when you
get to the bottom of the screen I think) the terminal becomes totally wedged.
This has been noticed by me and several other members of the Theory Group
for the last couple days.
\1f
Date: Fri, 20 Sep 85 12:40:25 EDT
From: Gail Zacharias <GZ@MIT-MC.ARPA>
Subject:  What fun!
To: ALAN@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Wed 11 Sep 85 02:14:32 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].652200.850920.GZ>

There are servers on OZ, EE and XX.  SPEECH is up to JTW I guess.  The device
will deduce Speech from SPxxxx, so you could add "SP" to the table.

Right, OZKS: does KANSAS: so jobdev kansas can go if there is a space problem.

I think I have the output problem fixed, so I guess I'm finished.  Should I
install it somewhere other than my dir?
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 SEP 85  13:59:59 EDT
Date: 19 Sep 1985  13:28 EDT (Thu)
Message-ID: <JINX.12144535912.BABYL@MIT-OZ>
From: Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>
Subject: Gnu Emacs on ITS
To:   PGS%MIT-OZ@MIT-MC.ARPA
Cc:   BUG-ITS@MIT-MC.ARPA, "George J. Carrette" <GJC@MIT-MC.ARPA>
In-reply-to: Msg of 19 Sep 1985  10:34-EDT from PGS

What about the pain of having to emulate BSD4.2 system calls?
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 SEP 85  12:32:14 EDT
Date: Thu, 19 Sep 1985  10:34 EDT
Message-ID: <PGS.12144504277.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc:   BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of 18 Sep 1985  22:45-EDT from George J. Carrette <GJC at MIT-MC.ARPA>

    Date: Wednesday, 18 September 1985  22:45-EDT
    From: George J. Carrette <GJC at MIT-MC.ARPA>
    To:   BUG-ITS at MIT-MC.ARPA
    cc:   INFO-EXPLORER at MIT-MC.ARPA

    I wonder what GNU EMACS would be like used side-by-side with ITS EMACS?
    Is the C compiler on ITS up to it?

I doubt that the address space on ITS is up to it, especially as the 10 C
compiler doesn't do byte-packing.
\1f
Date: Wed, 18 Sep 85 22:45:51 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
cc: INFO-EXPLORER@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].650277.850918.GJC>

I wonder what GNU EMACS would be like used side-by-side with ITS EMACS?
Is the C compiler on ITS up to it?
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 16 SEP 85  15:20:18 EDT
Date: Mon, 16 Sep 1985  15:21 EDT
Message-ID: <PGS.12143770091.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   "Devon S. McCullough" <DEVON@MIT-MC.ARPA>
Cc:   BUG-ITS@MIT-MC.ARPA, BUG-TCTYP@MIT-MC.ARPA
Subject: H-19 initialization
In-reply-to: Msg of 16 Sep 1985  10:13-EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>

    Date: Monday, 16 September 1985  10:13-EDT
    From: Devon S. McCullough <DEVON at MIT-MC.ARPA>

    CRTSTY sends "\e[?2h\eE\eG\eO\eq\e\\ew\ey8\ey9\ey5\ex1" but TCTYP only sends "\ew"
    which is why CRTSTY will always win and TCTYP sometimes loses totally,
    because if the H19 was last used in ANSI mode you need to send \e[?2h
    which either clears ANSI mode or puts a "?2h" turd on the screen.

My personal feeling is that you should $[?$h$33g$F the bastards and THEN see
if they try $259o$[J$[K'ing with you again.

Or, alternatively, why don't you just change the initialization string in
TCTYP to what you feel is right?
\1f
Date: Mon, 16 Sep 85 10:13:03 EDT
From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
Subject:  H-19 initialization
To: BUG-TCTYP@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].646431.850916.DEVON>

CRTSTY sends "\e[?2h\eE\eG\eO\eq\e\\ew\ey8\ey9\ey5\ex1" but TCTYP only sends "\ew"
which is why CRTSTY will always win and TCTYP sometimes loses totally,
because if the H19 was last used in ANSI mode you need to send \e[?2h
which either clears ANSI mode or puts a "?2h" turd on the screen.

CRTSTY also clears "graphics" (hah!) mode, where lower-case letters
produce strange glyphs on the screen.  I think it would be fun to
fix ITS so terminals with 128 different displayable codes can print
them if %TOSAI is turned on.  On H19's and VT52's this would produce
the oddity that control characters would echo down-arrow instead of ^
before the uppercased character.
\1f
Date: Wed, 11 Sep 85 02:14:32 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  What fun!
To: GZ@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].640776.850911.ALAN>

The DEVICE directory was getting a bit full.  The following three links
seemed to form a pattern.

  L   JOBDEV OZDNRF   ==> DEVICE;JOBDEV OZ        (7/18/85) GZ    
  L   JOBDEV OZKS     ==> DEVICE;JOBDEV OZ        (8/10/85) GZ    
  L   JOBDEV OZSS     ==> DEVICE;JOBDEV OZ        (8/13/85) GZ    

So I added OZ to the magic table in SYS:ATSIGN DEVICE so that -any- 4, 5,
or 6, character device name that starts with "OZ" automatically loads
DEVICE;JOBDEV OZ.  (AI, MC, ML and DM were already in the table.)  Then I
deleted the links.  There is also a link for a KANSAS: device.  Can we do
without this given that OZKS: works just as well?  Should I add XX and EE?
What about SPEECH?

How close are you to having this thing really working?  I haven't been able
to use it to -write- a file yet, although I have been using it to read all
kinds of things.  (There don't seem to be many other people using the Emacs
built on the long filename Teco, but it hasn't given me any problems at
all.  I guess once you think the device is "released" you can announce it
together with the new Emacs.  (I guess I should think about a long filename
version of MacLisp...))
\1f
Date: Sat,  7 Sep 85 16:54:01 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: LOUIE looping
To: BUG-MAIL@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].637052.850907.KLH>

LOUIE.UDEL.EDU appears to be looping back mail for several lists,
and giving us a bogus return-path to boot so that COMSAT error messages
just add more loops.  As a temporary measure I have put LOUIE in
the LUZRS table for SYSBIN;FTPS BIN.  This will cause all SMTP and FTP
connection attempts from that host to be rejected.  Obviously this
is a desperation measure and a better remedy would be to add some
smarts to COMSAT so that mail from there can be set aside for a while.
I don't have the time right now for this.  If someone is offended by the
unilateral censorship they can just put a zero back in LUZRS.
\1f
Date: Fri,  6 Sep 85 04:08:06 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: parity errors
To: log-service-call@MIT-XX.ARPA
cc: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].635367.850906.GSB>

MC's MH10 C was getting many parity errors, and has been shut off.
DEC has been called (log # B90393) and will be checking in in the morning.
\1f
Date: Sun,  1 Sep 85 12:57:40 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Feature
To: DEVON@MIT-MC.ARPA
cc: BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Sat 31 Aug 85 18:00:59 EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].630167.850901.ALAN>

    Date: Sat, 31 Aug 85 18:00:59 EDT
    From: Devon S. McCullough <DEVON at MIT-MC.ARPA>
    ...
    By the way, how does the system know about sharable pure pages?
    If it knows that much why doesn't it know about binaries' filenames?

It's because the concept of a "file" exists only at a higher level of
abstraction than the level where page sharing is done.  Sharing is done at
the level of pages and disk blocks.  A file is a name for a sequence of
disk blocks, but there is no way to go backwards from a disk address to see
which file (if any) it came from.  (Other than mapping over the entire
filesystem.)  If there was some reason this operation needed to be done
with great regularity, the information could be saved.  But it is rare to
want to do that, so we don't.  

(I actually have a tool that does it since I needed it once for debugging
disk ECC recovery on AI.  I think there might also be a routine in the
version of the salvager that runs under timesharing that does it.)
\1f
Date: Sat, 31 Aug 85 18:00:59 EDT
From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
Subject:  Feature
To: ALAN@MIT-MC.ARPA
cc: BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Sat 31 Aug 85 12:36:41 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].629753.850831.DEVON>

I was thinking that :SNARF could simply get the start address, etc,
from the croaked DDT, but Alan's suggestion is better.
By the way, how does the system know about sharable pure pages?
If it knows that much why doesn't it know about binaries' filenames?
\1f
Date: Sat, 31 Aug 85 12:36:41 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Feature
To: DEVON@MIT-MC.ARPA, BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Sat 31 Aug 85 03:57:02 EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].629584.850831.ALAN>

    Date: Sat, 31 Aug 85 03:57:02 EDT
    From: Devon S. McCullough <DEVON at MC>
    To:   BUG-DDT at MC
    I snarfed an emacs from a hactro and tried to do <alt>G
    "no start address" I don't know if this is a DDT bug or an ITS bug.

It isn't exactly anybody's bug.  The start address of a program is treated
just like the symbol table.  It is stored in binary files for the benefit
of people who load, start, and/or debug the program, but it is not kept
anywhere in the job itself.  ITS doesn't concern itself with where you
think a job should be restarted.

Now it -is- a little inconvenient that there is no way to go from a random
job you find floating around the system back to its binary to find its
symbols and starting address.  So let me float a few suggestions through
the air and see if anybody thinks they are a good idea:

(1) Add a user variable that would contain a starting address.  This would
    cover the common case that Devon complained about.  (Happens to me all
    the time too.)

(2) Add four user variables that would contain the filename of the binary
    for the this job.  This would enable symbols to be found as well as the
    start address.

(3) Add a user variable that contains the address of a block in the job's
    address space, in some extensible format we design later, that contains
    all kinds of information.  Like a vector of start addresses, filenames
    of binary files, etc.

(4) Since (3) requires cooperation from the job itself, but (1) covers the
    most common case, we could do both.  One user variable containing a
    start address and one containing the address of a block of information
    (or zero if the job doesn't have one).  Note that these are both 18 bit
    quantities, so this really only adds an extra word to every set of job
    variables.

A problem with (3) and (4) is that the new info-block user variable seems
somehow redundant with the existing use of the left half of .40ADDR.  The
16.-word block addressed by LH(.40ADDR) is currently only used for
temporary hacking by a job's superior; perhaps there is some way to combine
the two?  Perhaps one of the words addressed by RH(.40ADDR) can be the
info-block pointer if the job sets some bit in .OPTION?

I guess I'm in favor of at least (1) if not some variant of (4).
\1f
Date: Mon, 19 Aug 85 02:50:42 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
To: ALAN@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].617433.850819.GSB>

    Date: Sat, 17 Aug 85 22:30:43 EDT
    From: Alan Bawden <ALAN@MIT-MC.ARPA>

        Date: Fri, 16 Aug 85 17:06:59 EDT
        From: Glenn S. Burke <GSB at MC>

    I take it this was what you found printed on the system console?

Yes.  I had received a 'toplevel interrupt, tree detached' message.
My hactrn was not stopped however.
\1f
Date: Sat, 17 Aug 85 22:30:43 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  "dialup line disconnected, detached job #75, usr:gsb hactrn"
To: GSB@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Fri 16 Aug 85 17:06:59 EDT from Glenn S. Burke <GSB at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].616540.850817.ALAN>

    Date: Fri, 16 Aug 85 17:06:59 EDT
    From: Glenn S. Burke <GSB at MC>
    Re:   "dialup line disconnected, detached job #75, usr:gsb hactrn"

I take it this was what you found printed on the system console?

    huh?  If it was disconnected why did i not have to request further service
    from the ROLM feature?

That's pretty wierd all right.  ITS should never do that unless you are on
a tty line with %TYMDM set, and only T01 and T03 through T17 have that set in
the current ITS.  That bit -used- to be set for the Rolm lines, but that is
no longer the case because MC wasn't finding out about hangups.  Perhaps
there is something more fundamentally wrong with the hangup detection code?
\1f
Date: Fri, 16 Aug 85 17:06:59 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].615285.850816.GSB>

huh?  If it was disconnected why did i not have to request further service
from the ROLM feature?
\1f
Date: Fri, 16 Aug 85 12:34:08 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  SOPEN
To: GZ@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Mon 12 Aug 85 21:43:31 EDT from Gail Zacharias <GZ at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].614889.850816.ALAN>

    Date: Mon, 12 Aug 85 21:43:31 EDT
    From: Gail Zacharias <GZ at MIT-MC.ARPA>
    If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ
    REMIND instead.

SOPEN parsed the string as "DSK:GZ;GZ >" since the trailing space fooled it
into thinking that OMAIL was supposed to be another first filename.  I
fixed this problem in the source, I'll test it some time soon.  (I also
documented the fact that SOPEN defaults the device to "DSK" the second
filename to ">" and the sname to the job's current sname.)
\1f
Date: Tue, 13 Aug 85 12:33:18 EDT
From: Ed Schwalenberg <ED@MIT-MC.ARPA>
Subject: MC TTY13
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].610759.850813.ED>

MC's TTY13 dialup is in a state where it recognizes carrier-detect and ^Z to
mean "create a PWORD", but no typeout gets to the output buffer (according to
OS), much less to the terminal.  Gunning down the PWORD doesn't even produce
a console free message.
\1f
Date: Tue, 13 Aug 85 06:28:39 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject:  "TTY msg from <SITE>" should read "TTY msg from <user>@<site>"
To: DEVON@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA, bandy@LLL-CRG.ARPA
In-reply-to: Msg of Mon 12 Aug 85 23:33:11 EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].610343.850813.CSTACY>


    Date: Mon, 12 Aug 85 23:33:11 EDT
    From: Devon S. McCullough <DEVON at MIT-MC.ARPA>
    To:   BUG-ITS at MIT-MC.ARPA
    Re:   "TTY msg from <SITE>" should read "TTY msg from <user>@<site>"

      TTY msg from LLL-CRG.ARPA:
      bandy@lll-crg     <- this is for mc's broken mailer
      ya see, mc is throwing away the data in the "send from". i don't
      throw away the data. mc is the only site on teh whole internet
      that supports sends that throws away that return-path data.

      so bitch at the smtp/sender maintainers there...

------------
This discussion belongs on BUG-MAIL; please edit BUG-ITS from the
distribution of further messages (if any).

I am surprised that there are still people at this time who are
confused about the difference between a return path and a From
field.  The return path information given in the SMTP "SEND FROM"
command is not equivalent to the "From" field in a message header.
The return path is located on the ENVELOPE and the From field is
located in the header portion of the mail DATA.  RFC810 specifies:
"The SEND command requires that the mail data be delivered to the
user's terminal."  (Note that although an SMTP module may add a
field called Return-path in the header of a message it processes,
this feature is a transmission relay trace intended for debugging.)
The message recipient is not supposed to reply to the return path,
which is not really intended for humans; rather, the return path is
for use by SMTPs to generate error receipts.  If other systems are
using the return path in place of a header, then they are buggy.

It might be a feature for MC's SMTP to retain the return path for
the user, but if the message did not have a header it would still
be buggy; personally, I think adding the return path to incoming
sends clutters them up and wastes the reader's time.  This is why
most people's mail reading programs prune any return path fields
in the header from the message display.

It is definitely LLL-CRG which is violating protocol here.

Chris

PS. Early this year I reported this missing header bug to the TOPS-20
    mail system maintainers (then on SU-SCORE). Their response was
    that they should be putting headers on their outgoing sends, and
    that their system was broken.  I believe they fixed the bug, but
    I have since noticed that many TOPS-20 sites did not pick up this
    fix and have some old buggy SEND command.  Apparently Unix is
    distrbuted with this bug too. Maybe this explains your perception
    about MC being the only site which "throws away" the data.
\1f
Date: Mon, 12 Aug 85 23:33:11 EDT
From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
Subject:  "TTY msg from <SITE>" should read "TTY msg from <user>@<site>"
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].610043.850812.DEVON>

TTY msg from LLL-CRG.ARPA:
bandy@lll-crg   <- this is for mc's broken mailer

you said it. old its. there isn't anything more silly sometimes than its.

it's not what everyone else does. 

that send saying it's my fault went to me. tee hee
^_
TTY msg from LLL-CRG.ARPA:
bandy@lll-crg   <- this was generated by hand

it's mc that's throwing away data. sample conversation:
        helo lll-cr
        send from:<bandy@lll-crg>
        rcpt to:<devon@mit-mc>
        data    
        this is a send
        .
        quit

ya see, mc is throwing away the data in the "send from". i don't
throw away the data. mc is the only site on teh whole internet
that supports sends that throws away that return-path data.

so bitch at the smtp/sender maintainers there...

\1f
Date: Mon, 12 Aug 85 21:43:31 EDT
From: Gail Zacharias <GZ@MIT-MC.ARPA>
Subject: SOPEN
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].609927.850812.GZ>

If I give SOPEN the string "DSK: GZ; GZ     OMAIL ", it opens DSK:GZ;GZ REMIND
instead.
\1f
Date: Wed,  7 Aug 85 16:30:56 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  AI net connection loses
To: ALAN@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
In-reply-to: Msg of Tue  6 Aug 85 08:38:46 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].604169.850807.GUMBY>

    Date: Tue,  6 Aug 85 08:38:46 EDT
    From: Alan Bawden <ALAN>

        Date: Tue,  6 Aug 85 06:51:19 EDT
        From: David Vinayak Wallace <GUMBY>
        Why can't NET in LOCK reset AI's chaosnet interface?  Or am I confused?

    You are totally confused.  When the hardware breaks, what do you expect the
    software to do?  (It doesn't look to me like the problem is specific to AI
    anyway, it looks more like subnet 6 is broken somehow.)

It wasn't clear to me from her message what had lost.  And anyway,
frequently when the hardware gets wedged resetting it causes it to
start working again.  From her description of the symptoms I guessed
that perhaps something like that was happening.
\1f
Date: Tue,  6 Aug 85 08:38:46 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  AI net connection loses
To: GUMBY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
In-reply-to: Msg of Tue  6 Aug 85 06:51:19 EDT from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].602230.850806.ALAN>

    Date: Tue,  6 Aug 85 06:51:19 EDT
    From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
    Why can't NET in LOCK reset AI's chaosnet interface?  Or am I confused?

You are totally confused.  When the hardware breaks, what do you expect the
software to do?  (It doesn't look to me like the problem is specific to AI
anyway, it looks more like subnet 6 is broken somehow.)
\1f
Date: Tue,  6 Aug 85 06:51:19 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  AI net connection loses
To: BUG-ITS@MIT-MC.ARPA
cc: CENT@MIT-MC.ARPA
In-reply-to: Msg of Tue  6 Aug 85 05:04:47 EDT from Pandora B. Berman <CENT at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].602162.850806.GUMBY>

Why can't NET in LOCK reset AI's chaosnet interface?  Or am I confused?
\1f
Date: Tue,  6 Aug 85 05:04:47 EDT
From: Pandora B. Berman <CENT@MIT-MC.ARPA>
Subject: AI net connection loses
To: BUG-HARDWARE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].602119.850806.CENT>

this morning i was using MC on my terminal. around 04:30 or so response
got very slow, then a few minutes ceased altogether. AI had lost its
net connection again, so i couldn't talk to MC, OZ, or anything else.
someone please fix -- i can't work well with no terminal.
\1f
Date: Mon,  5 Aug 85 13:43:26 EDT
From: J. Noel Chiappa <JNC@MIT-MC.ARPA>
Subject: Grumble, Don't-Reap is no sticky
To: BUG-ITS@MIT-MC.ARPA
cc: JNC@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].601108.850805.JNC>

        I set the 'don't reap' bit on certain mailing list
address list files (e.g. for MIT-IP-PEOPLE), since they don't
get modified a lot and would otherwise have the potential
to go offline (e.g. if the Trident controller breaks).
        However, if you modify the file and write it back out
the 'don't reap' bit gets cleared! This is a lose...

        Noel
\1f
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 31 Jul 85 12:46:01 EDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286540; Wed 31-Jul-85 12:44:08-EDT
Date: Wed, 31 Jul 85 12:45 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: It's definite - TOPS-20 loses!
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>, bug-its@MIT-MC.ARPA
In-Reply-To: The message of 28 Jul 85 07:57-EDT from Ken Harrenstien <KLH@SRI-NIC.ARPA>
Message-ID: <850731124518.9.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Sun 28 Jul 85 04:57:33-PDT
    From: Ken Harrenstien <KLH@SRI-NIC.ARPA>

    I was able to log both ends of a telnet connection (using TOPS-20 TN here,
    and the ITS datagram logger on MC) and captured an instance of the lossage.
    MC is sending a repacketized segment which TOPS-20 incorrectly treats as
    additional data.  That is, MC's TCP sends off three separate segments, and
    then when no ACK is received it decides to retransmit, but is clever and
    lumps all the data together into a single segment which it then retransmits.
    This new segment has the proper sequence number (same as seq # of the
    original 1st segment).  The data in this segment is exactly that data
    which is duplicated in TN's log file.  The only possible explanation is
    that the TOPS-20 monitor's TCP code has a long-standing bug in it.

    It now occurs to me that I have seen this before when TN'ing to a VAX
    4.2BSD system.  I always blamed the BSD code for this, and other people
    claimed this was due to a bug in 4.2 server telnet, but somehow it never
    seemed to go away.  Looks as if this was actually a TOPS-20 bug!

    I will pursue this with the appropriate people.

Many too many implementations have the "Doesn't correctly handle
overlapping segments" bug.  The trickiest one is receiving a segment
some of whose data has already been acknowledged and some whose is new.
*sigh*

\1f
Date: Wed, 31 Jul 85 04:20:51 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: response to old bug report of mine: TS3TTY absolved
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].594867.850731.CSTACY>

Some time back I had reported a problem where when I first connected
to MC, the first few characters of each line appeared to be garbage.
This only happenned on dialup lines and would persist until I set the
terminal type. It really looked like ITS had initialized my TTY to
some wrong type -- the illegible graphics symbols appearing on my AAA
screen were likely-looiking control codes or padding.  I didn't want
to believe that the TTY code was broken, and some other people
asserted that my problem was not possibly the fault of ITS.  
Well, the other day I mentioned to my roomate that I was going to go
take a look at TS3TTY and convince myself it could not possibly be
broken.  He responded by pouring over the AAA terminal documentation
and frobbing the terminal, and finally located the real culprit.
Apparently the AAA has this feature (which we had enabled) where you
can turn some bit on if you desire the first few characters of each
line to be trashed for you.

So, this message is just a response for the record about that old bug
report I filed.  The ITS TTY code was *not* at fault.
\1f
Received: from SRI-NIC.ARPA by MIT-MC.ARPA 28 Jul 85 07:58:37 EDT
Date: Sun 28 Jul 85 04:57:33-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: It's definite - TOPS-20 loses!
To: bug-its@MIT-MC.ARPA
cc: klh@SRI-NIC.ARPA

I was able to log both ends of a telnet connection (using TOPS-20 TN here,
and the ITS datagram logger on MC) and captured an instance of the lossage.
MC is sending a repacketized segment which TOPS-20 incorrectly treats as
additional data.  That is, MC's TCP sends off three separate segments, and
then when no ACK is received it decides to retransmit, but is clever and
lumps all the data together into a single segment which it then retransmits.
This new segment has the proper sequence number (same as seq # of the
original 1st segment).  The data in this segment is exactly that data
which is duplicated in TN's log file.  The only possible explanation is
that the TOPS-20 monitor's TCP code has a long-standing bug in it.

It now occurs to me that I have seen this before when TN'ing to a VAX
4.2BSD system.  I always blamed the BSD code for this, and other people
claimed this was due to a bug in 4.2 server telnet, but somehow it never
seemed to go away.  Looks as if this was actually a TOPS-20 bug!

I will pursue this with the appropriate people.
-------
\1f
Date: Sun, 28 Jul 85 07:07:01 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem - yet more data
To: BUG-ITS@MIT-MC.ARPA, GSB@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].591010.850728.KLH>

I was finally able to provoke this bug simply with DDT ^R typeout of
a file -- conclusive proof that the problem does not lie with TECO,
EMACS, or RMAIL.  It is not reproducible however (doing another typeout
will not lose in the same place, if at all).
\1f
Date: Sun, 28 Jul 85 06:58:50 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem - yet more data
To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
    BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].590992.850728.KLH>

Well, with considerable pain I was able to cause an example of
this lossage while keeping a TCP datagram log.  However, the log
doesn't show what I expected; I was looking for the stretch of
duplicated text that I observed, and couldn't find it.  There are
some retransmissions but they are all correct.

Until GSB commented on the fact that the extra stuff seemed to be
a duplicate of previous stuff, I hadn't noticed this attribute, but
since then I've checked every instance and this appears to be always
true.  Something somewhere is being retransmitted or re-used.

Since this happens with both CTN (CRTSTY SUPDUP) and TOPS-20 TN,
it isn't a TOPS-20 user-program problem.  Since the outgoing datagram log on
MC shows no problems, the obvious deduction is that this looks like a
TOPS-20 monitor problem.  As it happens, the duplicated stuff does appear
to correspond to a re-packetized TCP segment.  More tests will be
necessary to confirm this, however.

This also implies that GSB's problem is actually something different
from this one.  Since he mentioned it happening with PEEK, I think
we should confine further discussion to BUG-ITS and leave out
BUG-RMAIL,TECO,EMACS unless more information turns up.
\1f
Date: Fri, 26 Jul 85 22:10:20 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  7LP: and 7LR:
To: INFO-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].589842.850726.ALAN>

Remember the 7LP: device I advertised in this spot last winter?  (I sends
output to the LN01 printer on the 7th floor.)  Well, I have just installed a
7LR: device for sending output to the new laserwriter (also on the 7th
floor).

While I was at it I gave both devices a new feature.  They now support
deletion so you can delete items from the queue.  For example, if 7LP^F
shows you the following:

    7th floor ln01 is ready and printing
     Time  Owner     Job Files                             Size
    *21:55 alan      905 7LP: BAWDEN; B 249                49481

    The most recent job printed was:
     21:21 alan          7LP: BAWDEN; .FILE. (DIR)

then you can delete job 905 by doing either ^O 7LP:905 or ^O 7LP:ALAN.  In
the later case all entries owned by ALAN are deleted.  The second filename
and directory are ignored.
\1f
Date: Thu, 25 Jul 85 16:39:03 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  Hardware
To: TY@MIT-MC.ARPA, MYK@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA,
    F-S@MIT-OZ
Message-ID: <[MIT-MC.ARPA].587801.850725.ALAN>

The parity errors MC was getting today seem to be closely correlated to
when the tape drive was being used.  I don't know when DEC is coming back
to fix the first memory box, but perhaps some diagnostics should be run to
see if the tape drive and it's DF10 are functioning properly.
\1f
Date: Wed, 24 Jul 85 18:06:43 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  I thought we were more carefull than this...
To: BUG-ITS@MIT-MC.ARPA
cc: DANIEL@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].586331.850724.ALAN>

MC was unusable for most of today because DEC brought up the machine with
the T-300's write-protected.  ITS should really say something more explicit
when this happens than "T300 ERR ... STATUS = 1 ...".
\1f
Date: Tue, 23 Jul 85 22:37:28 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: re: RMAIL display problem
To: KLH@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
    BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].586008.850723.GSB>

I cam make it happen with peek on a 60 high 118 wide screen, just like i
can with rmail.  looks like the cursor positioning goes bonkers as a
function of me typing at it.
\1f
Date: Mon, 22 Jul 85 18:06:15 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: re: RMAIL display problem  -- you'll like this
To: KLH@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
    BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].584681.850722.GSB>

right here in the privacy of my own office, i can reproduce this, freeze
the screen, and get a hardcopy of the lossage.  Isn't VMS wonderful?
\1f
Date: Mon, 22 Jul 85 13:30:54 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem
To: KLH@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
    BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].584298.850722.KLH>

Some additional data which supports the theory that a user-program or
ITS TTY bug may be involved:

Date: Thu, 18 Jul 85 22:40:40 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: RMAIL display problem
To: KLH@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].581085.850718.GSB>

All the times i have seen such an error i have been able to find duplicated
text on the screen and the supposition was that it was a duplicated
tcp packet or something like that.  I have seen this both internetting
from ru-net to here (from a 20) and i believe just within rutgers
(tops-20 -> tops-20 just on ru-net).
        ----------------------
Date: Fri, 19 Jul 85 23:45:04 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: tty lossage
To: KLH@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].582348.850719.GSB>

well maybe i should take back what i said last night.
I'm coming from a microvax vaxstation running a vt100 emulator window,
running decnet to a 750 (corwin) from whence i'm doing chaosnet supdup
to mc.  The window size is 94 wide by 55 high [i TOLD it 96 wide at this
end, you know how these things are...]  anyway, i have a two screen long
(at this screen size) message, and if i have it redisplay the first and
get a space (in rmail, go to next screen) before it finishes, it invariably
fucks up.

anyway, there ain't no tcp in THIS network path.
\1f
Received: from MIT-XX.ARPA by MIT-MC.ARPA 19 Jul 85 11:41:37 EDT
Date: Fri 19 Jul 85 11:43:49-EDT
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Subject: Re: memory woes
To: ALAN@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Alan Bawden <ALAN@MIT-MC.ARPA>" of Fri 19 Jul 85 08:34:10-EDT

        Ty was having parity error in some module of one sector. He
replaced that module and got the exact same error in the exact same
place (he said). He thought that was suspicious, and decided to
swap the parity controllers to see if the problem moved with the
controller. It didn't.
        Ask him for more details.
-------
\1f
Date: Fri, 19 Jul 85 08:33:23 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Thu 18 Jul 85 19:03:04 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].581459.850719.ALAN>

    Date: Thu, 18 Jul 85 19:03:04 EDT
    From: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
    Why does ITS think it has been up all year?

I guess somebody told MC it was 1984 when they first brought it up.
\1f
Date: Fri, 19 Jul 85 08:31:13 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  memory woes
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Fri 19 Jul 85 07:00:43 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].581458.850719.ALAN>

    Date: Fri, 19 Jul 85 07:00:43 EDT
    From: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
    unusable, so I deselected sector 1 where they were happenning
    (bank 3).  Then they appeared to move to sector 0.  I deselected
    sector 0 too.  

I presume you remembered to turn interleaving off when you deselected
sector 1.

                   If things seem to work well for a while today,
    someone might want to turn sector 1 back on and see if the
    errors move around.  We are down alot of memory at this point.
    I heard something about an Ampex parity detection module being
    replaced when DEC was frobbing the machine to replace a core
    stack in one of their memories.  

This wasn't DEC, it was TY I believe.  I think JNC can tell you about it as
well.
\1f
Date: Fri, 19 Jul 85 07:00:43 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: memory woes
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].581432.850719.CSTACY>

The Ampex was getting enough parity errors to render the system
unusable, so I deselected sector 1 where they were happenning
(bank 3).  Then they appeared to move to sector 0.  I deselected
sector 0 too.  If things seem to work well for a while today,
someone might want to turn sector 1 back on and see if the
errors move around.  We are down alot of memory at this point.
I heard something about an Ampex parity detection module being
replaced when DEC was frobbing the machine to replace a core
stack in one of their memories.  
What's the scoop latest on the hardware?
\1f
Date: Thu, 18 Jul 85 19:03:04 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].580878.850718.CSTACY>

Why does ITS think it has been up all year?
\1f
Date: Thu, 18 Jul 85 05:55:23 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem
To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
    BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].580138.850718.KLH>

I'm not sure where the fault for this one might be, hence the shotgun
message.

In RMAIL, when using "space" to step through successive screenfuls
of a long message, sometimes output fails to stop at the mode line;
it continues for several more lines and runs right off the bottom of
the screen, causing the terminal to either scroll or wrap up to
the top (depending on one's terminal).  The screen is then permanently
messed up until a complete redisplay is forced with ^L.

This happens for me when connected to MC either via SUPDUP (ie as a
software TTY) or via TELNET with a :TCTYP DM2500 declaration.  At
first I thought it might be a CRTSTY/SUPDUP problem, but my TELNET
experiments have convinced me that it really is MC's fault.
However, I haven't been able to find a foolproof way of reproducing
the lossage.  All I can say is that in the course of reading through
several SF-LOVERS digests on a 24x79 screen, this bug almost always
crops up someplace, sometimes twice or thrice in a row.  I type:
        N E ^K ^X r                             ; to invoke RMAIL
        <spaces as needed to read msg> d        ; for each message

This is probably a TECO bug of some variety, but there's an off
chance it might be an ITS TTY handling bug.  It's even possible
that some EMACS code is screwing up the redisplay.  This has happened
for quite a while (several months).  I hope someone else has a
notion of what to look for at this point.  If necessary, I could
try again to save a reproducible instance of this, although it is
a rather painful task.
\1f
Date: Fri, 12 Jul 85 09:13:59 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  crtsty lossage.
To: BUG-CRTSTY@MIT-MC.ARPA
cc: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
In-reply-to: Msg of Fri 12 Jul 85 02:18:26 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].573277.850712.ALAN>

I renamed SYSBIN;CRTSTY OBIN => CRTSTY BIN => CRTSTY XBIN.  I presume the
behavior we were observing was something that KLH introduced when he
assembled CRTSTY yesterday.

BTW, I notice there is a link from TS NCRTSTY to SYSBIN;CRTSTY NBIN, which
despite its name is a year older than any other version.  Is there a reason
for this?
\1f
Date: Fri, 12 Jul 85 02:18:26 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: crtsty lossage?
To: BUG-CRTSTY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].572965.850712.CSTACY>

I just dumped a dead CRTSTY into CRASH;CRTSTY VT100.
This was EAK CRTSTY, 
(.VALUE;IOCH7;) 70110>>SKIPGE @413  130624/  4,,27000

I guess it got a fatal interrupt, but I don't know
anything about this program.  There were n of these
guys lying around, all stopped in the same way.
\1f
Date: Fri, 12 Jul 85 00:56:15 EDT
From: Pandora B. Berman <CENT@MIT-MC.ARPA>
Subject: crtsty lossage?
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].572909.850712.CENT>

something's wrong. over the past several hours i have found half a dozen
CRTSTYs disowned with .VALUE 200. also several ___###s disowned. i can only
tell from what i see in PEEK; someone who knows more should check this.
\1f
Received: from MIT-XX.ARPA by MIT-MC.ARPA.ARPA; 10 Jul 85 23:20:03 EDT
Date: Wed 10 Jul 85 23:21:13-EDT
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Subject: Re: level2 bughalt
To: DANIEL@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
cc: JNC@MIT-XX.ARPA
In-Reply-To: Message from "Daniel Weise <DANIEL@MIT-MC.ARPA>" of Sun 7 Jul 85 17:07:05-EDT

        Well, the TARAKA DMPCPY business is a daemon copying the dump
from the swapping area (where DDTDSK put it) into the real file system.
The file seems to have gone into the directory '.' rather than 'CRASH';
'.' is the default directory used by DDTDSK.
        Noel
-------
\1f
Date: Mon,  8 Jul 85 14:54:11 EDT
From: Jonathan D. Taft <TAFT@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].567927.850708.TAFT>

DSK:UNIT 1 LOSING.RH CONI BITS=  1,,157236

Dumped to CRASH;UNIT1 LOSING

\1f
Date: Sun,  7 Jul 85 17:05:05 EDT
From: Daniel Weise <DANIEL@MIT-MC.ARPA>
Subject:  level2 bughalt
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].566858.850707.DANIEL>

MC wedged itself again this afternoon.  I took  crash
dump to CRASH LEVEL2 and warm booted.  But during
warm boot it printed something like
TARAKA DMPCPY .     CRASH LEVEL2 DELRNM 
(MC's vt52 is missing so I am typing this in from 
memory).

When I looked for crash;crash level2 the file
wasn't there.  What did I do wrong?

Daniel
\1f
Date: Fri,  5 Jul 85 00:41:26 EDT
From: David A. Moon <MOON@MIT-MC.ARPA>
Subject: Re: IMP down detection
To: JNC@MIT-XX.ARPA
cc: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].565142.850705.MOON>

    Date: Mon 24 Jun 85 17:54:25-EDT
    From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

            I think that it's a known bug with the IMP code that if the
    IMP cycles after ITS is up ITS doesn't deal with that correctly.

It used to work.  Maybe I broke it when I removed support for NCP protocol
a few years ago.
\1f
Date: Fri,  5 Jul 85 00:07:06 EDT
From: David A. Moon <MOON@MIT-MC.ARPA>
Subject: oh, yeah
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].565121.850705.MOON>

    Date: Mon,  1 Jul 85 17:20:31 EDT
    From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>

    It is probably a bug that ITS refuses all Chaosnet service
    when it is being debugged.  There is a feature in NETWRK
    for doing this in the Chaosnet specific code.  SYSDBG is
    maybe not quite fine-grain enough?  Also, should move
    TCPUSW and TCPUP to be near NETUSW, etc.

Yeah, probably it should assume NETUSW is good enough.
\1f
Date: Mon,  1 Jul 85 23:53:18 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Sender: GSB5@MIT-MC.ARPA
Subject: crash
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].562107.850701.GSB5>

crash;ucprl5 +1
\1f
Received: from MIT-XX.ARPA by MIT-MC.ARPA.ARPA;  1 Jul 85 23:11:38 EDT
Date: Mon 1 Jul 85 23:12:42-EDT
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Subject: Re: crashdump
To: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Alan Bawden <ALAN@MIT-MC.ARPA>" of Sat 29 Jun 85 05:43:22-EDT

        I'm dubious about this being a side effect of DEC playing around.
The exact thing DEC did involved no frobbing with cables at all; all the
did was disable some of the ports the processor was using to reference
memory. (I was supposed to explain all this but forgot).
        What they did was notice that we are running the machine in
two way interleave. Exactly why we are doing this is too long to explain
here, and I think Dave Moon did so once already. This being the case,
they decided that we would be less likely to have 'interference' on the
memories if we diabled KBUS2 and KBUS3 (which are after all duplicates of
KBUS0 and KBUS1 in two way interleave). I'm not sure I believe this, but
I do believe that it can't hurt and I didn't feel like arguing with the
DEC guy about it, so I let them do it. (Actually, they disabled the
memory ports to those busses, not the busses.)
        However, the DF10 has it's own memory bus and port, and should
not have been affected. It's probably a flaky caused by all the power
cycling in the last week.
                Noel
-------
\1f
Date: Mon,  1 Jul 85 21:00:22 EDT
From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].561917.850701.DEVON>

I snarfed an E job when I already had one (to see what I could see)
and it renamed it E!!!!! well that's okay, but wouldn't E! or E0 have done?
\1f
Date: Mon,  1 Jul 85 17:20:31 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: oh, yeah
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].561691.850701.CSTACY>

It is probably a bug that ITS refuses all Chaosnet service
when it is being debugged.  There is a feature in NETWRK
for doing this in the Chaosnet specific code.  SYSDBG is
maybe not quite fine-grain enough?  Also, should move
TCPUSW and TCPUP to be near NETUSW, etc.
\1f
Date: Sat, 29 Jun 85 05:41:16 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  crashdump
To: GSB@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Sat 29 Jun 85 02:39:48 EDT from Glenn S. Burke <GSB at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].559587.850629.ALAN>

    Date: Sat, 29 Jun 85 02:39:48 EDT
    From: Glenn S. Burke <GSB at MIT-MC.ARPA>
    crash;unit-0 lost

The DF10 got a NXM.  I suspect this is an artifact of the way DEC
reconfigured the memory last Wednesday.  Would we rather have the parity
errors back?  Damn machine.
\1f
Date: Sat, 29 Jun 85 02:39:48 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Sender: GSB5@MIT-MC.ARPA
Subject: crashdump
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].559506.850629.GSB5>

crash;unit-0 lost
\1f
Date: Wed, 26 Jun 85 22:01:16 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  MC up again with all 6 disks.
To: TY@MIT-MC.ARPA, Sollins@MIT-XX.ARPA, Finn@MIT-XX.ARPA
cc: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].557107.850626.ALAN>

JNC and I swapped the packs in unit 3 and 4 on MC (the rightmost two
T-300's) and the disk problems we were experiencing vanished.  Perhaps
there is some marginal interaction between drives and packs formatted with
different alignments?  If so, I guess there is some hope that things will
clear up after duplicating those packs tomorrow.

BUG-ITS:  For the record:  Earlier today JNC and TY brought MC up with
-none- of the T-300's because they believed them all to be broken.  They
were given this impression when UCOP got an error copying some user
directories.  In fact, it has been true for a long time that there are bad
blocks amoung the directories on those packs, but since we don't
really need those extra copies of the directories this is OK.  UCOP copies
the MFD -first-, and if it gets that far, that is good enough!
\1f
Date: Tue, 25 Jun 85 01:50:24 EDT
From: David A. Moon <MOON@MIT-MC.ARPA>
Sender: CENT@MIT-MC.ARPA
Subject: Addition to mailing list
To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc: BUG-ITS@MIT-MC.ARPA, ks-its@MIT-AI.ARPA
Message-ID: <[MIT-MC.ARPA].554803.850625.CENT>

    Date:        23 Jun 85 20:11 +0100
    From:        Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA

    Everybody here is waiting for the system to run, all of the hackers in
    Stockholm that have heard of ITS is lyric.

    I have started the work on planing howto actualy change the KA hardware,
    i want to have the posibility to run as much of the DEC diagnostics as
    possible. So some type of switch-selectable aproach is prefered, but it
    is no simple.

    In a month or so we shall try to have the two KI-10 Cpu:s running
    SMP with T10 7.02. We plan to use this system to assemble the ITS code.


    (       Are you sure you can deal with that volume of mail?  I don't think
            anyone will mind your being on them if you don't mind.
    )

    Pls try to add:  ITS_bugs%QZCOM.MAILNET@MIT-MULTICS.ARPA
    in both ITS bugs and ITS on ks20.

I have done so.

    Will report as soon there is any sucsess.

We eagerly await your report.  The box of tapes, processor prints, and
documentation is sitting right next to me, thanks to a lot of work by
Penny Berman.
\1f
Received: from MIT-XX.ARPA by MIT-MC.ARPA 24 Jun 85 17:55:25 EST
Date: Mon 24 Jun 85 17:54:25-EDT
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Subject: Re: IMP down detection
To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
cc: JNC@MIT-XX.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY@MIT-MC.ARPA>" of Mon 24 Jun 85 16:10:43-EDT

        I think that it's a known bug with the IMP code that if the
IMP cycles after ITS is up ITS doesn't deal with that correctly.
-------
\1f
Date: Mon, 24 Jun 85 16:10:35 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: IMP down detection
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].554168.850624.CSTACY>

At some point today, ITS decided the IMP was down.
It never noticed it coming back up, and thought it was
waiting for the ready line to flap.  I ran LOCK and
it reset everything.
\1f
Received: from MIT-XX.ARPA by MIT-MC.ARPA 21 Jun 85 15:05:13 EST
Date: Fri 21 Jun 85 15:03:48-EDT
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Subject: MC disk flakoes
To: bug-its@MIT-MC.ARPA
cc: JNC@MIT-XX.ARPA

        John Holden came and looked at the Tridents and pronounced them
all OK. Two needed touch ups to the alignment, but nothing major. He
says that it was probably the cables, which are known to be flaky. Since
he had to remove the cables to run the exerciser, he thinks that he
may have frobbed them in the right way to make the problems go away.
Things do seem to be working a bit better. We'll see.
-------
\1f
Date: Thu, 20 Jun 85 21:11:48 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject:  more re: mc was wedged this afternoon.
To: DANIEL@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Thu 20 Jun 85 12:12:00 EDT from Daniel Weise <DANIEL at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].550546.850620.GUMBY>

    Date: Thu, 20 Jun 85 12:12:00 EDT
    From: Daniel Weise <DANIEL at MIT-MC.ARPA>

    Claimed no net ports when only 4 people were logged in.
    Console  only echoed my typein but did nothin 
    wit it.  Tried warm booting.  THat failed.  Took
    crash dump to CRASH SAME and cold booted.

More bits: trying to open a STY gave DEVICE FULL, which is weird.
I've seen the same thing when MC couldn't get to its tridents.
\1f
Date: Thu, 20 Jun 85 12:12:00 EDT
From: Daniel Weise <DANIEL@MIT-MC.ARPA>
Subject:  mc was wedged this afternoon.
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].550424.850620.DANIEL>

Claimed no net ports when only 4 people were logged in.
Console  only echoed my typein but did nothin 
wit it.  Tried warm booting.  THat failed.  Took
crash dump to CRASH SAME and cold booted.

Daniel
\1f
Date: Sun, 16 Jun 85 20:29:08 EDT
From: Alan Bawden <ALAN@MIT-MC>
Subject:  mc needed cold booting this afternoon.
To: DANIEL@MIT-MC, JGA@MIT-MC
cc: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].544997.850616.ALAN>

    Date: Sat, 15 Jun 85 14:05:26 EDT
    From: Daniel Weise <DANIEL at MC>
    MC was really wedged this afternoon.  Every minute it kept typing
    system full, 0 pages, 0 qsk channels, etc.  No user jobs able to run.
    Warm booting didn't help so I took a dump to CRASH FULL and
    cold-booted, which seems to have fixed things.

Well, the crash dump shows an ITS that has been up for 5 minutes and is
having trouble initializing the first T-300.  So I guess this is the
canonical T-300 controller lossage.

    Date: Sat, 15 Jun 1985  12:04 EDT
    From: JGA at OZ
    A little bit more on the recent lossage I mentioned earlier...

    I was logged in when RHB got wedged.  Running Peek, I could see
    that his job and several others were sitting there with a state
    of "*logout", whatever that means.  Peek could not gun his tree,
    nor could Lock.

A state of "LOGOUT" (the "*" is irrelevant really) means that the job was
already on its way towords going away.  (Thats why gunning it didn't do
anything, it was already as gunned as it could get.)  Without a crash dump,
or an actual wedged system, I can only guess that this is another symptom
of the T-300 lossage.
\1f
Date: Sun, 16 Jun 85 20:26:35 EDT
From: Alan Bawden <ALAN@MIT-MC>
Subject:  CHTN lossage
To: JNC@MIT-MC
cc: BUG-ITS@MIT-MC
In-reply-to: Msg of Fri 14 Jun 85 18:52:47 EDT from J. Noel Chiappa <JNC at MIT-MC.ARPA>
Message-ID: <[MIT-MC].544988.850616.ALAN>

    Date: Fri, 14 Jun 85 18:52:47 EDT
    From: J. Noel Chiappa <JNC at MC>
        Recently I have been noticing that when XX goes down,
    my CHTN hangs and nothing the world seems to get me out, until it
    decides to timeout the connection. ANyone know why?

Yeah, I've noticed this too.  It's not new, its been happening for years.
Just looking at the code I can't figure out how it can happen.  (Note that
this is probably just a bug in CHTN; you take the risk of having bugs like
this when you go into super image input mode...)
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 JUN 85  14:15:18 EDT
Date: Sat, 15 Jun 1985  12:10 EDT
Message-ID: <JGA.12119355938.BABYL@MIT-OZ>
From: JGA%MIT-OZ@MIT-MC.ARPA
To:   bug-its@MIT-MC
Subject: weird wedgitude - part IIa

One more note - a finger of MC from OZ shows the dead HACTRNs
sitting there with " STY not in use" where the ttyloc usually
goes in the finger display.
\1f
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 JUN 85  14:15:17 EDT
Date: Sat, 15 Jun 1985  12:04 EDT
Message-ID: <JGA.12119354914.BABYL@MIT-OZ>
From: JGA%MIT-OZ@MIT-MC.ARPA
To:   bug-its@MIT-MC
Subject: weird wegitude, part II

A little bit more on the recent lossage I mentioned earlier...

I was logged in when RHB got wedged.  Running Peek, I could see
that his job and several others were sitting there with a state
of "*logout", whatever that means.  Peek could not gun his tree,
nor could Lock.

There were several different HACTRNs sitting around in this state,
which explains the lack of net ports I guess, as well as whole bunch
of lispm file jobs.  I don't know enough about lispm file jobs to tell
whether these were normal or not.

About two minutes later my tty got wedged, and I can't log back in
because of no net ports, so that's why I'm sending this from OZ.
\1f
Date: Sat, 15 Jun 85 14:05:26 EDT
From: Daniel Weise <DANIEL@MIT-MC.ARPA>
Subject:  mc needed cold booting this afternoon.
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].543663.850615.DANIEL>

MC was really wedged this afternoon.  Every
minute it kept typing system full, 0 pages, 0 qsk channels, etc.
No user jobs able to run.  Warm booting didn't help so
I took a dump to CRASH FULL and cold-booted, which seems
to have fixed things.

Daniel
\1f
Date: Fri, 14 Jun 85 18:52:47 EDT
From: J. Noel Chiappa <JNC@MIT-MC.ARPA>
Subject: CHTN lossage
To: BUG-ITS@MIT-MC.ARPA
cc: JNC@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].543165.850614.JNC>

        Recently I have been noticing that when XX goes down,
my CHTN hangs and nothing the world seems to get me out, until
it decides to timeout the connection. ANyone know why?
\1f
Date: Thu, 13 Jun 85 17:25:50 EDT
From: Robert H. Berman <RHB@MIT-MC.ARPA>
Subject: intermittent login probelm
To: JGA@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].541730.850613.RHB>

Same thing happened to me today too.
(around 4:30-5:30 PM)
I got about half-way in my login file
and the tterminal hung. tried loggin in several
times in a row with no success. Finally logged in
and everything has been ok since.
\1f
Date: Thu, 13 Jun 85 11:23:45 EDT
From: John G. Aspinall <JGA@MIT-MC.ARPA>
Subject:  wierd wegitude
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].541202.850613.JGA>

I'm having an intermittent problem of the terminal getting wedged when I log
in.  The symptoms are as follows.

Pword runs ok, and my login file starts executing.  At some point, either as
the login file ends, or at a point most of the way through it where I have a
:more query about whether to run babyl or not, almost all response to typed
characters stops.  The only characters that cause a response are ctrl-G and
rubout which provoke their usual behaviour.

My login file has not been changed in months.  Other people logging in from
the same concentrator (NPLASMA) have not seen the problem.  I get the problem
four or five times in a row, then everything is fine again.

John.
\1f
Received: from THINK.ARPA by MIT-MC.ARPA 11 Jun 85 16:58:04 EST
Received: by THINK.ARPA with CHAOS id AA28106; Tue, 11 Jun 85 16:52:46 edt
Date: Tuesday, 11 June 1985, 16:54-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: STINK
To: KLH@MIT-MC.ARPA, BUG-ITS@MC
Cc: gls@THINK.ARPA
In-Reply-To: <[MIT-MC.ARPA].538066.850611.KLH>
Message-Id: <850611165410.6.GLS@ROCK.ARPA>

Hurray!


I simply don't know what to think
Of this late resurrection of STINK,
  Once thought lost, at the last,
  In the mists of the past
Like its sibling, the famed missing link.

--Guy
\1f
Date: Tue, 11 Jun 85 05:36:46 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: STINK
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].538066.850611.KLH>

You may find this news hard to believe.

As you may recall, the source for STINK didn't assemble properly,
and had a higher version number than the (presumably working) binary.
The true source, if it ever existed, has been lost in the distant
fires of ITS dump tapes being burned at the stake.

I was thinking about a possible hack which at some point might require
the services of STINK.  Never mind what it is.  The problem as I saw
it was not the fact that STINK is unique and unsupported, but the
fact that STINK could not be supported without a real source.  So
I made a half-hearted attempt to investigate by comparing the (faulty)
result of an assembly with the existing binary, using SRCCOM's /$
switch.

Boy, am I glad I put that hack into SRCCOM.  The comparison much to
my surprise showed the binaries were virtually identical, except for
one changed label and a couple of missing symbols.  It only took a few
minutes to fix those and come up with a source that assembles into
exactly the same thing (modulo .FNAM2) as the old TS STINK!

Anyway, I wrote out this new source as STINK 200, and installed a new
TS STINK.  STINK lives again!  (phew)
\1f
Date: Thu,  6 Jun 85 18:11:40 EST
From: Chris Hanson <CPH@MIT-MC.ARPA>
To: BUG-SYSTEM@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].533331.850606.CPH>

Why do I have to give a password when I supdup over from OZ?
What kind of bullshit is this?
\1f
Date: Thu, 30 May 85 15:06:41 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  All network ports in use
To: GUMBY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: Msg of Thu 30 May 85 14:25:10 EST from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].524704.850530.ALAN>

    Date: Thu, 30 May 85 14:25:10 EST
    From: David Vinayak Wallace <GUMBY at MC>
    Every once in a while I am unable to connect to MC via chaos; I open a
    connexion and MC says "All network ports in use."  This is repeatable
    for about a minute or so, then I get a ddt.  loadp shows 11 free net
    ports.

I fixed a bug that used to cause something like this to happen a while ago.
A new ITS for MC has not been assembled since then.
\1f
Date: Thu, 30 May 85 14:25:10 EST
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject: All network ports in use
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].524623.850530.GUMBY>

Every once in a while I am unable to connect to MC via chaos; I open a 
connexion and MC says "All network ports in use."  This is repeatable for about
a minute or so, then I get a ddt.  loadp shows 11 free net ports.

What gives?
\1f
Date: Thu, 30 May 85 09:16:15 EST
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: T-300s inaccessible
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].524200.850530.CSTACY>

MC's T-300 disk controller was powered off somehow, although the
PDP11 and other frobs in the same rack were still on.   I power
cycled it and reloaded the system to get things going again.
\1f
Date: Wed, 29 May 85 15:52:32 EST
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject: Most puzzling...
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].523215.850529.ALAN>

Typical MC crash today:

MC BUGHLT's with an MUUO in exec mode (see apparently typical example in
CRASH;CRASH MUUO').  After
\eL XITS 
\eG
The salvager does -not- print its usual greeting, nor is anything else
printed on the system console.  However, if you raise switch 0, ITS will
stop just as if it was running normally (see example in CRASH;CRASH NOSALV).

Now doing
\eL XITS
\eG
again will aparently work, except that the system will hang trying to get
to unit 3 and you will need to try again after running BOOT11.

(Note that something similar to this must have happened to Gumby the other
day, except after a different initial crash...)
\1f
Date: Wed, 29 May 85 02:52:25 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Yow!  I am reliable yet?
To: BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].522693.850529.TIM>

The time is 02:46:34 EDT.
Today is Wednesday, the 29th of May, 1985.
MC ITS 1488 has run for 103 days, 2 hours, 13 minutes, 32 seconds.
Surpassing all previous MC records for uptime!
System last revived 1 day, 2 hours, 12 minutes, 33 seconds ago.
\1f
Date: Sun, 26 May 85 03:01:18 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject: latest crash
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].518640.850526.GUMBY>

I came in and MC was down; I looked at the pc; couldn't figure out what happened
so saved it in crash;crash gmmpp (it died at gmmpp+3).  I loaded a new xits, but 
the salvager never ran.  I halted it with switch 0 and reloaded from scratch.
\1f
Date: Sat, 25 May 85 21:28:34 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
Subject:  AI COMSAT down for the count.
To: CENT@MIT-MC
cc: BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, DCB@MIT-MC, TAFT@MIT-MC,
    ALAN@MIT-MC
In-reply-to: Msg of Sat 25 May 85 01:19:30 EST from Pandora B. Berman <CENT>
Message-ID: <[MIT-MC].518526.850525.CSTACY>

This was because COMSAT assumes that the DEAD-MAIL-RECEIPTS list
always exists, but I forgot to create it in NAMES >.  I convinced the
COMSAT on AI to gobble the latest NAMES before trying to unqueue
anything, things are back to normal now, and I re-installed the
mailer on AI.

Under certain conditions (such as fatal interrupts) AUTPSY comes out
empty.  COMSAT was probably dying with PDL overflows or something.

(BTW, I already fixed the other unrelated looping bug which ALAN
reported last week.)

\1f
Date: Sat, 25 May 85 01:19:30 EST
From: Pandora B. Berman <CENT@MIT-MC>
Subject: AI COMSAT down for the count.
To: BUG-MAIL@MIT-MC
cc: BUG-ITS@MIT-MC, DCB@MIT-MC, TAFT@MIT-MC
Message-ID: <[MIT-MC].517969.850525.CENT>

AI's COMSAT is stuck in a deadly loop. whenever it is launched, it
first, of course, tries to cut down on the queued msgs by sending one
of them. trouble is, the single one in its queue is to BUG-INQUIR@MC
(alias CSTACY) and COMSAT thinks it's from DEAD-MAIL-RECEIPTS@AI.  so
after sending it (it does get through, each time; cstacy now has
several of these in his mail) COMSAT tries to give a CMSG to
DEAD-MAIL-RECEIPTS@AI. there is no such address, so COMSAT says
::=<ignored>. then it tries to CMSG again to the same address. after
several times, it dies after just saying CMSG.

BURNUP 1 was the first corpse dumped by this process. BURNUP 8 is the
latest of several all of the same size (each died after only this work
on the queue, while #1 included previous activity).  I tried writing a
new NAMES > with the guilty address eqv'd to NUL:, as it is on MC;
COMSAT did not try to compile this before working on the queued mail.
BURNUP 9 is COMSAT dying after i renamed LIST EQV (the bin of NAMES >)
to something else; again, COMSAT did not look for the names database
before hacking the queued mail. this is a gross bug and should be
fixed; if there is no names database, maybe it's for a good reason,
like the previous one is fuckt and someone wants comsat to pick up the
new (hopefully cured) version. BURNUP 10 is from another experiment: i
tried renaming LISTS MSGS to something else, COMSAT looked for NMSGS,
found none, and died.

alan and moon tried to debug this over the phone, but couldn't get
enough data (AUTPSY kept containing 0 !). i have renamed AI:COMSAT
LAUNCH to COMSAT BRUNCH. ai now has enough pieces of mail that it
won't accept any more from outside. COMSAT should not be relaunched
on AI until someone fixes this.
\1f
Date: Mon, 20 May 85 03:54:02 EST
From: Pandora B. Berman <CENT@MIT-MC>
Subject: forwarding... someone forgot to hang up?
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].510876.850520.CENT>

Date: Fri, 17 May 85 22:29:22 EST
From: Robyn D. Spencer <TOOTSE@MIT-MC>
To: BUG-ROLM@MIT-MC
Message-ID: <[MIT-MC].509023.850517.TOOTSE>

bug-its
I (mason) just connected to mc through a rolm and found myself logged
in as tootse, as a mail notification popped up.
I just thought someone would like to know.

                                mark
\1f
Date: Wed, 15 May 85 20:08:30 EST
From: David A. Moon <MOON5@MIT-MC>
Subject:  MC crashes when you read AI backup tapes
To: CENT@MIT-MC, MOON@MIT-MC
cc: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].505155.850515.MOON5>

I wasn't able to figure out the problem in detail, but I did edit
a bug trap into the source at MGRD2.  Sometime you should exhibit
the problem with me physically present and I'll patch in this bug
trap and see if it goes off.
\1f
Date: Wed, 15 May 85 00:52:40 EST
From: Pandora B. Berman <CENT@MIT-MC>
Subject: patch for crufty ai tapes makes mc die horribly?
To: MOON@MIT-MC
cc: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].503776.850515.CENT>

i was trying to read some old AI tapes. they got errors, so with glenn's
advice i installed your patch:
    MOON5@MIT-ML 06/30/84 03:54:39
    To: GSB at MIT-ML, CENT at MIT-ML
    fyi the location to patch to disable tape read errors
    in ITS is MGMRT+1 which is changd from JRST MGERR to JRST MGRD2.
    It still tries a few times to retry errors but if it gets a fatal
    error it gives you whatever shitty data it got instead of barfing..
    ^_
then tried again with the tape. dump worked on tape a short while, with
some hiccupping and one reported error, then system died. crash dump in
CRASH IMRQ8. alan poked around at the code and thinks that possibly the
patch is fucking up the MEMBLT table...
\1f
Date: Mon, 13 May 85 18:54:28 EST
From: Glenn S. Burke <GSB@MIT-MC>
Sender: GSB5@MIT-MC
Subject: bugpause: tty: buffer empty at tyirem
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].501533.850513.GSB5>

CRASH;TYIREM NOBUFF
\1f
Date: Fri, 10 May 85 12:50:00 EST
From: Kent M Pitman <KMP@MIT-MC>
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].495319.850510.KMP>

MC has a pile of jobs which have PARERR'd out. Several dead COMSATs,
etc. Someone might want to look at this.
\1f
Date: Fri, 10 May 85 04:44:57 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: wedgitude
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].494815.850510.GSB>

CRASH;WEDGED AGAIN is an example of this evening's wedgitude, dumped
after being stopped by switch 0.
\1f
Received: from MIT-AI by MIT-MC via Chaosnet; 10 MAY 85  01:27:09 EDT
Date: Fri, 10 May 85 00:39:42 EST
From: J. Noel Chiappa <JNC@MIT-AI>
Subject: Zapppp!
To: BUG-its@MIT-MC
cc: JNC@MIT-AI
Message-ID: <[MIT-AI].590.850510.JNC>

        There was some breeze-shooting on the subject of speeding
up the DZ output interrupt service routines which I thought I'd
note down. Since a 9600 baud line running flat out generates
1000 interrupts/second, and the output ISR looks quite long at
the moment, a few lines running flat out will probably bring
the machine to its knees.
        The theory is that we should implement efficient block mode
output; i.e. the driver emulates a DMA device and takes big chunks of
data each time ITS talks to it. We should blow some of the extra
register sets that we have, one per DZ. 8 of the registers would be
used for things like holding a pointer to the registers, etc, and
temps, and the other 8 would be pointers to output buffers.
        The pointers would probably be AOBJN style pointers, with the
data uppacked one byte per word. (We can't use byte pointers because
there isn't any room for a count if so and there aren't enough
registers to have counts too, unless we restrict ourselves to 4
general registers and keep the counts in halfwords.) At that
point, the output ISR would be about 10 instructions long:

        OPBASE = 6              ;Base of AOBJN pointer block in regs

        IORDI A,%DZRCS(D)       ;Get CSR
        TRNN A,%DZCTR           ;Transmitter ready?
          JRST LOSE             ;No, spurious interrupt
        LDB A,[.BP %DZLM,A]     ;Get line number
        MOVE T,OPBASE(A)        ;Get AOBJN pointer for that line
        MOVE TT,(T)             ;Pick up data
        IOWRI TT,%DZRTD(D)      ;Write it out
        AOBJP T,DONE            ;All done yet?
        MOVEM T,OPBASE(A)       ;Put updated pointer back
        JRST 12,@TTYBRK         ;Dismiss

        Or something like that, anyway.
\1f
Date: Thu,  9 May 85 21:00:50 EST
From: Alan Bawden <ALAN@MIT-MC>
Subject:  unlocked
To: JTW@MIT-SPEECH
cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC
In-reply-to: Msg of Thu 9 May 85 18:24:42-EDT from John Wroclawski <JTW%MIT-SPEECH at MIT-MC.ARPA>
Message-ID: <[MIT-MC].494266.850509.ALAN>

    Date: Thu 9 May 85 18:24:42-EDT
    From: John Wroclawski <JTW at SPEECH>
        From: Alan Bawden <ALAN at MC>
        Subject: Everything is locked
        I guess it is unlikely, but it would be foolish of anyone else to try
        to assemble and try anything that uses KS-10 I/O instructions....
    Uh huh. Well, let me know when you think they work OK - I do hope to
    deal with the tape code sometime now that I'm back in town..

The I/O instructions work just fine.  Last night we installed Jinx's DZ-11
code and it works too, so the path is clear for you.
\1f
Date: Tue,  7 May 85 17:25:44 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: ALAN@MIT-MC
cc: CSTACY@MIT-MC, BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].490451.850507.KLH>

    Date: Mon,  6 May 85 21:15:15 EST
    From: Alan Bawden <ALAN@MIT-MC>
    In-reply-to: Msg of Mon  6 May 85 10:34:28 EST from Christopher C. Stacy <CSTACY>

    If your COMSAT problem has to do with the hair COMSAT's go through
    when starting up to prevent their being more than one COMSAT, then I
    believe I remember KLH mentioning this before.

Yes, this has happened.  Makes one wonder if locks really do work, or
if it is just the narrowness of the race window that gives one the impression
they work.
\1f
Date: Tue,  7 May 85 05:58:57 EST
From: Alan Bawden <ALAN@MIT-MC>
Subject: Everything is locked
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].489464.850507.ALAN>

I guess it is unlikely, but it would be foolish of anyone else to try to
assemble and try anything that uses KS-10 I/O instructions until I get a
chance to come in and install and verify the new microcode.  The macros in
KSDEFS are gone and have been replaced with the new I/O instructions I
microcoded up.  What this means is that everything is probably broken.
\1f
Date: Tue,  7 May 85 02:34:47 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject:  MC:.;IOEVEL AIBIN
To: ALAN@MIT-MC
cc: BUG-ITS@MIT-MC
In-reply-to: Msg of Mon  6 May 85 21:26:40 EST from Alan Bawden <ALAN>
Message-ID: <[MIT-MC].489263.850507.GUMBY>

Doesn't the system console watch .; like sys***;?
\1f
Date: Mon,  6 May 85 21:26:40 EST
From: Alan Bawden <ALAN@MIT-MC>
Subject:  MC:.;IOEVEL AIBIN
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].488587.850506.ALAN>

Someone deleted the file MC:.;IOELEV AIBIN.  It was either someone who
reads this mailing list who thought he was cleaning up, or it was a random.
In the later case there is nothing to be done, but in the former case I can
prevent this from happening again by reminding you all that AI-11 still
runs, and still network boots occasionall.
\1f
Date: Mon,  6 May 85 21:15:15 EST
From: Alan Bawden <ALAN@MIT-MC>
To: CSTACY@MIT-MC
cc: BUG-ITS@MIT-MC
In-reply-to: Msg of Mon  6 May 85 10:34:28 EST from Christopher C. Stacy <CSTACY>
Message-ID: <[MIT-MC].488567.850506.ALAN>

If your COMSAT problem has to do with the hair COMSAT's go through
when starting up to prevent their being more than one COMSAT, then I
believe I remember KLH mentioning this before.

If this is a case of initializing a shared database using the algorithm
given in .INFO.;ITS LOCKS, then perhaps the unlikely screw case documented
there managed to actually happen.
\1f
Date: Mon,  6 May 85 18:14:42 EST
From: Glenn S. Burke <GSB@MIT-MC>
To: CSTACY@MIT-MC
cc: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].488010.850506.GSB>

    Date: Mon,  6 May 85 10:34:28 EST
    From: Christopher C. Stacy <CSTACY@MIT-MC>

    I just had a problem with COMSAT similar to the problem with
    PWORD the other day, where locks did not get unlocked.
    As in the previous case, the involved code has been stable for
    a long time (years).  Is it possible that locks have become
    broken lately somehow?  I heard there are bugs in the mechanism
    but I don't know what they are -- maybe I am just hitting some
    kind of screw case lately.

I remember tracking down and patching the pword lock at least once
before, years ago (on AI).  Maybe once on ML too.  I don't believe
we knew what caused the problem.
\1f
Date: Mon,  6 May 85 10:34:28 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].487059.850506.CSTACY>

I just had a problem with COMSAT similar to the problem with
PWORD the other day, where locks did not get unlocked.
As in the previous case, the involved code has been stable for
a long time (years).  Is it possible that locks have become
broken lately somehow?  I heard there are bugs in the mechanism
but I don't know what they are -- maybe I am just hitting some
kind of screw case lately.
\1f
Date: Sun,  5 May 85 00:53:11 EST
From: Alan Bawden <ALAN@MIT-MC>
To: GSB@MIT-MC
cc: BUG-ITS@MIT-MC
In-reply-to: Msg of Sat  4 May 85 19:24:06 EST from Glenn S. Burke <GSB>
Message-ID: <[MIT-MC].485622.850505.ALAN>

Had there been paper the message would have read: "TTY: OUTPUT BUFFER
POINTER PAST END OF BUFFER".  I added this crash to the collection.
\1f
Date: Sat,  4 May 85 19:24:06 EST
From: Glenn S. Burke <GSB@MIT-MC>
Sender: GSB5@MIT-MC
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].485447.850504.GSB5>

mc crashed, was in ddt.  no paper in the system console.
dumped to crash;look later if anyone is interested and can find anything
interesting from it...
\1f
Date: Fri,  3 May 85 15:39:42 EDT
From: J. Noel Chiappa <JNC@MIT-MC>
Subject: Drugs
To: BUG-ITS@MIT-MC
cc: JNC@MIT-MC
Message-ID: <[MIT-MC].483905.850503.JNC>

        No, I'm not on them. I know what it looks like when
PEEk gets an MPV and that wasn't it. I'm not sure what it
was (it wasn't that the job had got and unhandled MPV,
which would have shown up in the N display) but it wasn't
PEEK losing its ass.
\1f
Date: Fri,  3 May 85 15:33:57 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC>
Subject:  No logins
To: JNC@MIT-MC
cc: BUG-ITS@MIT-MC, BUG-PWORD@MIT-MC
In-reply-to: Msg of Fri  3 May 85 12:48:09 EDT from J. Noel Chiappa <JNC>
Message-ID: <[MIT-MC].483895.850503.CSTACY>

    Date: Fri,  3 May 85 12:48:09 EDT
    From: J. Noel Chiappa <JNC>
    To:   BUG-ITS
    cc:   JNC
    Re:   No logins

    PWORD was getting MPV's. I couldn't fix this (and backing up to
    an older PWORD didn't fix it) so I temporarily flushed PWORD
    and replaced it with DDT so that at least people could log in.

Although JNC doesn't think so, I am convinced that he was faked out by
a bug in PEEK which sometimes causes it to print out "MPV not handled"
when it screws up.

When I went and ran PWORD, I did not get any kind of MPV problems, but
I did get hung after the command prompt.  Somehow, the lock word in
the password database was set and never cleared, so all jobs would
.HANG forever as soon as they tried to access the database.  The job
which had claimed the database was long gone.  I patched the password
database back into working order and re-installed PWORD.

The code for PWORD has not been changed in a long time, so I suspect
that some kind of hardware problem (or human) somehow screwed up the
ITS locks critical routine feature, or munged the database.
\1f
Date: Fri,  3 May 85 12:48:09 EDT
From: J. Noel Chiappa <JNC@MIT-MC>
Subject: No logins
To: BUG-ITS@MIT-MC
cc: JNC@MIT-MC
Message-ID: <[MIT-MC].483484.850503.JNC>

        PWORD was getting MPV's. I couldn't fix this (and backing
up to an older PWORD didn't fix it) so I temporarily flushed PWORD
and replaced it with DDT so that at least people could log in.
\1f
Date: Fri,  3 May 85 12:32:32 EDT
From: John G. Aspinall <JGA@MIT-MC>
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].483460.850503.JGA>

MC has been up all morning, but refuses to establish
proper connections for incoming network telnets and supdups.
Dialups also appear flaky, but I'm not sure about this.

Symptoms - you get the telser message "MC Maximum Confusion PDP-10"
and then nothing.

Finger from another site shows lots of un-logged-in HACTRNs sitting
there.  Note that outgoing chtn, telnet, supdup are fine.
Incoming finger is fine too.

I don't know enough about what's going on to do anything constructive,
but I'd be interested in finding out what the diagnosis is.
\1f
Date: Tue, 30 Apr 85 01:16:24 EDT
From: Alan Bawden <ALAN@MIT-MC>
Subject:  Oh yeah, right...
To: GREN@MIT-MC
cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC, BUG-DDT@MIT-MC
Message-ID: <[MIT-MC].476201.850430.ALAN>

    [Message from GREN at MIT-AI  1:05pm]
    hey, single-stepping isn't working right!

Oh yeah.  Until I get back into microcode hacking again, hackers who debug
programs using DDT on AI will find that features related to single stepping
don't work right.  I'll fix it eventually, I just haven't put in the
support for it yet.

I won't be fixing the fact that AI doesn't have a MAR, so somebody should
be fixing DDT to know that some ITS machines lack the feature.
\1f
Date: Fri, 26 Apr 85 22:53:01 EST
From: Pandora B. Berman <CENT@MIT-MC>
Subject: bring back old PDSET
To: BUG-PDSET@MIT-MC, BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].471957.850426.CENT>

MC crashed, and in being brought up had to have its time reset. in doing so
i had to employ the new frilly version of PDSET. yucko. the old one worked
fine with less verbiage and could parse 6-digit numbers into times and
dates, which the new one can't. please flush this and restore the previous
version.
\1f
Date: Fri, 26 Apr 85 02:05:57 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject:  More on IMP opto-isolator board -- fixt for now.
To: BUG-ITS@MIT-MC
cc: DCLARK@MIT-MC, ANN@MIT-MC, JTW@MIT-MC,
    moon@SCRC-STONY-BROOK
Message-ID: <[MIT-MC].470299.850426.GUMBY>

ITS was unable to get any bits through for long enough to open a
connection.  Noel found a similar chip to the broken one in a chaosnet
interface.  We (me, jtw, jnc) yanked it and installed it (the same hack was
apparently done five years ago).

As this is the second one to fail, it is likely that another one will soon,
and that the board may not appreciate being frobbed like this yet another
time.  I might make another isolator board sometime before the end of the
term if I can get away with it.

david
\1f
Date: Tue, 23 Apr 85 07:49:26 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: mc memory randomness
To: BUG-ITS@MIT-MC
cc: CENT@MIT-MC
Message-ID: <[MIT-MC].465864.850423.GSB>

mc tripped and fell down this morning.  As might be expected, the system
console hardcopy for the previous hour was all overprinted on a single line.
There was a parity error light on in the ampex (penny recorded this in the
log).

Cold booting worked until it checked NXM, when it decided that most
(but not all) of the two high MH10s were not there.  The memory was
listed in a large number of randomly sized chunks.  Power cycling
those two cabinets didn't help.  (The overtemp light had been on in C
-- don't know if it had been on as of when the machine went down.)
Deselecting them seemed to be a good idea and seems to be working...

Since the machine was up, and seeing the time, i decided to pass off
calling DEC to ann finn (unlike what i wrote in the log earlier).
\1f
Date: Mon, 22 Apr 85 21:57:01 EST
From: Alan Bawden <ALAN@MIT-MC>
Subject:  foo
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].465386.850422.ALAN>

MC's console card said I was supposed to load XITS, but there wasn't any
such file.  I dumped XITS myself several days back, so I wonder who renamed
it to be OXITS without explanation?
\1f
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 15 APR 85 22:35:51 EST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215097; Mon 15-Apr-85 22:35:39-EST
Date: Mon, 15 Apr 85 22:32 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: M-X Copy File 
To: Alan Bawden <ALAN@MIT-MC.ARPA>
cc: BUG-ITS@MIT-MC.ARPA
In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>,
             <[MIT-MC].451173.850411.ALAN>
Message-ID: <850415223234.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu,11 Apr 85 13:10:07 EST
    From: Alan Bawden <ALAN@MIT-MC>

    A file's author is currently apparently set from the UNAME of the writing
    job.  (I surmise, I haven't looked at the code yet.)  Perhaps the XUNAME
    should be used instead?

Here's the previous discussion of this:

    Date: Saturday, 15 September 1984, 12:06-EDT
    From: David A. Moon <Moon at SCRC-TENEX>

        Date: 14 September 1984 21:00-EDT
        From: Christopher C. Stacy <CSTACY @ MIT-MC>

        M-X Copy File does not preserve authors on ITS.
        It does preserve reference date (although maybe it should
        use DNRF instead of referencing the file to copy it) and
        the creation date.

    This is because the routine CLOSIT in the FILE job sets the author of the
    file it just wrote to the user's HSNAME.  Evidently it does this because
    the FILE job doesn't login under the name of the user who is using it.
    We can do one of
     (1) Make the FILE job login under the right name.
     (2) Make ITS set the file author from the XUNAME instead of the UNAME and
         make the file job set its XUNAME to the user's name instead of to
         a copy of its UNAME.
     (3) Make the FILE job set the author when it opens the file instead of
         when it closes it.
    Suggestions?
    -------
    Kerns suggests doing #3 or making ITS set the author from HSNAME instead
    of the UNAME.  That sounds good except what about \e^S?

Last week I thought, mistakenly, that using \e^S to run EMACS on
another's terminal would make me be the author of files that I write.
I think it should.  Hence:

  - ITS should set the author of the file to the HSNAME.
  - The file job should set its HSNAME to that of the user on whose
    behalf it is acting.
  - The file job shouldn't set the author gratuitously.

In the above, HSNAME would be XUNAME were it not for the fact that authors
are stored as directory numbers rather than as sixbit strings.

Anyone disagree?

\1f
Date: Thu,11 Apr 85 13:10:07 EST
From: Alan Bawden <ALAN@MIT-MC>
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].451173.850411.ALAN>

A file's author is currently apparently set from the UNAME of the writing
job.  (I surmise, I haven't looked at the code yet.)  Perhaps the XUNAME
should be used instead?
\1f
Date: Mon, 8 Apr 85 10:00:36 EST
From: George J. Carrette <GJC@MIT-MC>
Subject:  blast from the past
To: ALAN@MIT-MC
cc: BUG-ITS@MIT-MC, FILE-R@MIT-MC
In-reply-to: Msg of Mon 8 Apr 85 00:12:06 EST from Alan Bawden <ALAN>
Message-ID: <[MIT-MC].446519.850408100037.GJC>

Speaking of historically interesting files I propose that certain
MC/AI/ML backup tapes that would otherwise be discarded be put into
the MIT archives and/or the CCC facility. Example: CCC has an Imlac,
and I was showing Gill the :IMLOAD program and the IMLAC directory,
but of course the IMLAC directory was reaped long ago. But since CCC
has an old IBM 7 track drive they could actually make good use of the
tapes with the IMLAC stuff.  Personally I'm interested in seeing old
snapshots of conniver, planner, rabbit, etc, all of which are on
backup tape. 
\1f
Date: Mon, 8 Apr 85 00:12:06 EST
From: Alan Bawden <ALAN@MIT-MC>
Subject:  blast from the past
To: GJC@MIT-MC
cc: BUG-ITS@MIT-MC
In-reply-to: Msg of Sun 7 Apr 85 17:08:18 EST from George J. Carrette <GJC>
Message-ID: <[MIT-MC].446193.850408001206.ALAN>

    Date: Sun, 7 Apr 85 17:08:18 EST
    From: George J. Carrette <GJC>
    the end of the contents of l;bibop (memo) seems to have extra blocks in
    it from the mail status file.

... from a mail status file from around 1974!  I rescued this file
from ML's filesystem last year.  It was damaged on ML years ago.

Its actually interesting to see what mail status files looked like ten
years ago.
\1f
Date: Sun, 7 Apr 85 17:08:18 EST
From: George J. Carrette <GJC@MIT-MC>
To: BUG-ITS@MIT-MC
Message-ID: <[MIT-MC].445871.850407170822.GJC>

the end of the contents of l;bibop (memo)
seems to have extra blocks in it from the mail
status file.
\1f
Date: Thu, 4 Apr 85 23:01:54 EST
From: "Christopher C. Stacy" <CSTACY@MIT-MC>
To: BUG-ITS@MIT-MC

I replied to LIN.
\1f
Date: Thu, 4 Apr 85 22:37:24 EST
From: Herb Lin <LIN@MIT-MC>
To: BUG-ITS@MIT-MC

actually, i'm looking for a wizard.  how do you change the
password on ITS for your own account?

tnx.
\1f
Date: 31 March 1985 17:30-EST
From: Glenn S. Burke <GSB @ MIT-MC>
To: bede @ MIT-XX
cc: BUG-ITS @ MIT-MC

rolm 4602 calling mc doesn't answer.
\1f
Received: from 40700024534 by MIT-MC via Chaosnet; 16 MAR 85  18:10:30 EST
Received: from SCRC-EUPHRATES by SCRC-VALLECITO via CHAOS with CHAOS-MAIL id 2994; Sat 16-Mar-85 15:24:53-EST
Date: Sat, 16 Mar 85 15:25 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Tapes for Swedes
To: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc: bug-its@MIT-MC.ARPA
Message-ID: <850316152523.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

[Replying to a message that JTW forwarded to me]

    Date:        11 Mar 85 02:13 +0100
    From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA

    We can probably get access to a 7-track tape drive to read your tapes
    on, but we need some information about the format, like a backup program
    that we can read on a TOPS-10 or TOPS-20 machine. Even a listing would be
    helpful.

    Also, we would like to know what kind of tape drive and controller
    you are using, and if you use standard DEC core-dump format.

If you can read 7-track tapes in DEC core-dump format, we can send you
ITS dump tapes of all the relevant files, including the Midas assembler
and binaries of Midas that will run on Tops-10.  (I guess the right
thing would be to include Tops-20 binaries of Midas as well).  It will
probably be six or seven reels of tape.  The format is as simple as
could be, I expect we can send you a 1/2 page writeup describing it
along with the tapes.  Or I can send you a one-sentence writeup right
now: The files are delimited by tape file-marks; each file starts with a
header, which starts with an "aobjn pointer", and contains its name in
sixbit and some other stuff; the rest of the file is just the file, as
36-bit words; at the front of the tape is another header, also starting
with an "aobjn pointer", giving the tape name and some other stuff.
\1f
Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 14 MAR 85  23:44:46 EST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 197577; Thu 14-Mar-85 19:55:26-EST
Date: Thu, 14 Mar 85 19:56 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: ITS
To: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-Reply-To: <91827@QZCOM>
Message-ID: <850314195652.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA

    Does anyone over there have an ITS tape? 

It's been three weeks since you sent your message (I'm behind on my mail).
Was it ever clarified what type of tape drive you have and what formats
of tape you can read?  It's possible that we may have to write a 9-track
Tops-10/Tops-20 Interchange format tape for you, which would be possible
for us to do but would take a fair amount of work.  With the recent episode
of vandalism and destruction, there is only one running ITS machine in the
world and it has a 7-track tape drive.

Last year for archival purposes I dumped all the ITS and utility program
sources on two reels of 9-track, 3200-bpi tape in a format that you
definitely don't have a program to read.  Two copies of those tapes
exist in separate locations.  It is not inconceivable that I could make
another copy.  That might be useful, since the separate locations are
only three miles apart and hence could both be destroyed simultaneously.

    ... In the meantime we have gotten another
    machine, a KI10, which has been up and running several months.
    It runs a slightly modified TOPS-10 V7.02 (which isn't supposed
    to run on KI at all), and we have managed to simulate some
    KL instructions, for example ADJSP. We are planning hardware
    modifications so we can do ADJBP too. But TOPS-10 is not very
    exciting, so we have been thinking about getting up TENEX, or
    even TOPS-20. Do you know any place we can get a KI10 TENEX monitor?

I think it would be considerably less work to get ITS running on a KI10
than to get it running on a KS10.  The biggest difference between the
stock KI10 and the ITS-modified KA10 is that the KI10 paging is less
flexible (no split page tables between the upper and lower half of
user address space); but a small amount of software simulation could
handle that; certainly it wouldn't be as bad as what it takes to get
Tenex to run on the KI10.  Or you could fix the hardware, which evidently
you have the capability to do.

Want to have a race?  It wouldn't really be very fair, since there are
only a couple of very part-time people working on the KS10 here.

    Does BBN still run TENEX? Any pointers would be appreciated.

A perhaps little-known fact is that Symbolics still runs TENEX, on
a Foonly F-2.  I've been campaigning to get that machine thrown off the
roof for quite a while now, but unfortunately there are still people
using it.
\1f
Date: 7 March 1985 20:09-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Novelty
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 24 January 1985 20:56-EST
    From: Alan Bawden <ALAN @ MIT-MC>

    Just a event to ponder.  The other day I supduped from MC back to MC
    (presumably using Chaosnet, I didn't think to check), and I was greeted
    with the following:

        S.1487. PWORD.2630.
        TTY 52
        12. Lusers, Fair Share = 6%

        MC IT*

    Note that five characters ("MC IT") have been displaced.  Conceivably the
    fact that the machine was so heavily loaded, and that the user and server
    were both on the same machine, could have allowed some timing screw that
    almost never happens normally.

This is not new.  The phenomenon has existed for several years and was
first noticed on the AI KA-10 when telnet connections would sometimes produce
scrambled initial prompts.  I don't think anyone has made a serious effort
to identify the bug.  It could be in either the telnet server or in the
ITS STY code.  This would be a good case for any mystery lovers to investigate.
\1f
Date: 7 March 1985 16:45-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  timestamps
To: BUG-MAIL @ MIT-MC
cc: BUG-ITS @ MIT-MC, KLH @ SRI-NIC

I frobbed the Received: lines some more so that they look like the
usual RFC822 ones; this is for both the SMTP and CHAOS servers.

They look these:
   Received: from USC-ECLB.ARPA by MIT-MC.ARPA;  7 MAR 85 16:41:19 EST
   Received: from MIT-EECS by MIT-MC via Chaosnet; 7 MAR 85  16:41:02 EST

They use new routines in various packages:
   The DATIME library now has a routine called TIMRFC.
   The OUT package now supports the new directive TIM(F4).

Chris
\1f
Date: 7 March 1985 16:26-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: MC hardware status
To: BUG-ITS @ MIT-MC

The most recent parity errors have occured in MH10-D.  Also the microcode
hangs about once a week it seems.
\1f
Date: 6 March 1985 19:58-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

(MC is getting the parity errors, not me...)
\1f
Date: 6 March 1985 19:57-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

We are getting a lot of parity errors lately, although I haven't
looked to see where they are coming from.
\1f
Received: from MIT-HTVAX.ARPA by MIT-MC.ARPA; WED 6 MAR 1985 1404 EST
Received: by MIT-HTVAX.ARPA (4.12/4.7) 
        id AA26507; Wed, 6 Mar 85 13:59:31 est
Message-Id: <8503061859.AA26507@MIT-HTVAX.ARPA>
To: BUG-ITS@mit-mc.ARPA
Subject: Received: lines
Date: 06 Mar 85 13:59:26 EST (Wed)
From: Martin David Connor <marty@MIT-HTVAX.ARPA>


Thanks to whoever put in received lines.  They are very helpful in
tracing the path of a message.

Could they be altered slightly to conform to the RFC822 spec for such
fields?   It would be much easier to read if it were consistent with
the rest of the Received lines a message might contain.

Here is an excerpt from the RFC which specifies the order of the fields:

     received    =  "Received"    ":"            ; one per relay
                       ["from" domain]           ; sending host
                       ["by"   domain]           ; receiving host
                       ["via"  atom]             ; physical path
                      *("with" atom)             ; link/mail protocol
                       ["id"   msg-id]           ; receiver msg id
                       ["for"  addr-spec]        ; initial form
                        ";"    date-time         ; time received

  
\1f
Date: 2 March 1985 09:06-EST
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC

just got a looong hang, followed by host not responding/host reset the connection (I'm on via mit-tac) after which I was able to reconnect and reattach.  net lossage?
\1f
Date: 28 February 1985 03:05-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: PDSET
To: BUG-ITS @ MIT-MC
cc: GUMBY @ MIT-MC

I rewrote PDSET from scratch, and made some improvements to
the DWIM in the DATIME library.  The new PDSET has not yet
been tested entirely, and is not installed.  Also, I didn't
hack it up for the KS10 yet either.  Will do some evening...
\1f
Date: 21 February 1985 03:43-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  un-named hosts
To: BUG-TCP @ MIT-MC, BUG-MAIL @ MIT-MC, BUG-REPLY @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 20 Feb 1985 23:24-EST from Christopher C. Stacy <CSTACY>

    Date: 20 February 1985 23:24-EST
    From: Christopher C. Stacy <CSTACY>
    To:   BUG-MAIL

    Someone at SCRC just tried to send me a message from a host not
    in our tables; he was refused by our server.  I bet that the server
    died trying to look it up.   I'll make it say CHAOS|nnnn or something.


OK, I fixed this so that the Chaosnet SEND server will claim the
message came from a host named like "24516/CHAOS".

It occurred to me that it would be nice to be able to REPLY to these
guys too, so I went and hacked up the NETWRK library to accept various
numerical host names.  (There was some code in NETWRK to parse some of
these, but it was pretty broken and looked like it could never have worked.)

Then I hacked up SENDER a little, mostly to know about the following
poorly documented return convention of NETWRK"HSTLOOK: even if A gets
a host address, B may contain zero rather than a database pointer.

I also reassembled TELNET with the new NETWRK.  With the right
switches set, programs will now parse all these equivalent forms:

   MIT-AI       ; symbolic
   10.2.0.6     ; Internet address
   2/6          ; Host 2 on IMP 6.
   3130/CHAOS   ; (Other nets work too: 400006/ARPA is MIT-AI,
                                        77/SATNET is GOONHILLY-ECHO)


If anything mysterious starts happenning with programs as they are
re-assembled with the new NETWRK, let me know.

Chris
\1f
Date: Thu 21 Feb 85 00:40:56-EST
From: John Wroclawski <JTW%MIT-SPEECH@MIT-MC.ARPA>
Subject: Re: ITS
To: CENT@MIT-MC, Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc: BUG-ITS@MIT-MC
In-Reply-To: Message from "Pandora B. Berman <CENT @ MIT-MC>" of Wed 20 Feb 85 23:25:36-EST

    From: Pandora B. Berman <CENT @ MIT-MC>
    Subject: ITS
    
        From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
        To:          BUG-ITS@MIT-MC.ARPA
        Subject:     ITS
    
        ....
    
    
    it's been a long time since we said anything; sorry (at least we could
    have said it would take a long while or something). a chief problem
    that i have heard some of the hackers here mention about running ITS
    on your system is that the hardware list you sent does not include a
    paging box (i'm not sure what number that would be -- perhaps DM10 --
    someone will jump on me if i'm wrong).

Um, actually it's not a DEC frob at all, so it hasn't got a number. The
ones which were used at MIT were built either by us or Systems Concepts,
I believe. ITS paging is somewhat different than TOPS-10, both of which
are completely different than TENEX/TOPS-20.

On the other hand, it might be possible to pound on your KI10 enough
to get it to do ITS paging using the KI's paging hardware. The page
tables are of different format, the pages are larger, and of course
page faults are reported to the OS differently.


    also the ITS sources are not
    neatly available already on a single tape; someone would have to go
    through things and figure out what to send you, and we have all been
    sort of busy (we work full time on other things, or are students,
    etc.)

Hmmm, if they have a TOPS-10 running, they at least have something to
run MIDAS on. It's a start. Maybe when the KS is done things will be in
one place...

    i think BBN flushed their last tenex last spring; not sure who
    you could ask there for further details.
    
They did. There are still a few of them running around the Arpanet
though. If you can get the right paging hardware to run TENEX you
actually have a pretty good chance of getting TOPS-20 up, if you can
find a set of version 3 or 4 sources. You would either have to change
a lot of code or change the way traps and such work on the KI though.
For TENEX, I'd start by trying to get the latest sources from BBN,
presumably they still have them around.
-------
\1f
Date: 20 February 1985 23:19-EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: ITS
To: Bjorn_Danielsson_QZ%QZCOM.MAILNET @ MIT-MULTICS
cc: BUG-ITS @ MIT-MC

    Date:        20 Feb 85 19:42 +0100
    From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
    To:          BUG-ITS@MIT-MC.ARPA
    Subject:     ITS
    Does anyone over there have an ITS tape? We (of the computer club
    STACKEN) would very much like to take a look at it and see if we can
    run it on our KA10. Any kind of tape will do, we think we can manage to
    decode it. And we promise not to bother you with questions later. We
    are even prepared to promise Ronald Reagan that we won't give it to the
    Russians :-) We have finally found a room to put the machine in, and it
    will be installed very soon. In the meantime we have gotten another
    machine, a KI10, which has been up and running several months.  It runs
    a slightly modified TOPS-10 V7.02 (which isn't supposed to run on KI at
    all), and we have managed to simulate some KL instructions, for example
    ADJSP. We are planning hardware modifications so we can do ADJBP too.
    But TOPS-10 is not very exciting, so we have been thinking about
    getting up TENEX, or even TOPS-20. Do you know any place we can get a
    KI10 TENEX monitor?  Does BBN still run TENEX? Any pointers would be
    appreciated.

it's been a long time since we said anything; sorry (at least we could have
said it would take a long while or something). a chief problem that i have
heard some of the hackers here mention about running ITS on your system is
that the hardware list you sent does not include a paging box (i'm not sure
what number that would be -- perhaps DM10 -- someone will jump on me if i'm
wrong). also the ITS sources are not neatly available already on a single
tape; someone would have to go through things and figure out what to send
you, and we have all been sort of busy (we work full time on other things,
or are students, etc.) i think BBN flushed their last tenex last spring;
not sure who you could ask there for further details.

maybe some piece of your KI could be used as an ITS paging box? i don't
know (i'm not a hacker, alas, so i can't do more than speculate).
\1f
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655243468721180@MIT-MULTICS.ARPA>; 20 Feb 1985 18:37:48 est
Date:        20 Feb 85 19:42 +0100
From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          BUG-ITS@MIT-MC.ARPA
Subject:     ITS
Message-ID:  <91827@QZCOM>

Does anyone over there have an ITS tape?
We (of the computer club STACKEN) would very much like to take
a look at it and see if we can run it on our KA10. Any kind of
tape will do, we think we can manage to decode it. And we promise
not to bother you with questions later. We are even prepared to
promise Ronald Reagan that we won't give it to the Russians :-)
We have finally found a room to put the machine in, and it will be
installed very soon. In the meantime we have gotten another
machine, a KI10, which has been up and running several months.
It runs a slightly modified TOPS-10 V7.02 (which isn't supposed
to run on KI at all), and we have managed to simulate some
KL instructions, for example ADJSP. We are planning hardware
modifications so we can do ADJBP too. But TOPS-10 is not very
exciting, so we have been thinking about getting up TENEX, or
even TOPS-20. Do you know any place we can get a KI10 TENEX monitor?
Does BBN still run TENEX? Any pointers would be appreciated.

        Happy hacking,

        Bjorn Danielsson
        Datorforeningen STACKEN
        c/o NADA
        Royal Institute of Technology
        S-100 44 Stockholm
        SWEDEN



\1f
Date: 13 February 1985 17:56-EST
From: Glenn S. Braindeath <GSB @ MIT-MC>
Subject: "IBO"
To: BUG-ITS @ MIT-MC

I just got an IBO message...
I seem to remember that this ain't supposed to happen.
A minute later everything worked fine.  (i'mon 1200 baud dialup)
\1f
Date: 12 February 1985 18:17-EST
From: David A. Moon <MOON @ MIT-MC>
Subject: NTSDDT
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, TY @ MIT-MC, JNC @ MIT-XX

    Date: 12 February 1985 17:42-EST
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    Subject:  NTSDDT
    To: JNC @ MIT-XX
    cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
    In-reply-to: Msg of Tue 12 Feb 85 17:40:25-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>

        Date: Tue 12 Feb 85 17:40:25-EST
        From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
        To:   CSTACY at MIT-MC.ARPA
        cc:   BUG-ITS at MIT-MC.ARPA, TY at MIT-MC.ARPA, JNC at MIT-XX.ARPA
        Re:   NTSDDT

            Date: 12 February 1985 17:32-EST
            From: Christopher C. Stacy <CSTACY>

                Date: Tue 12 Feb 85 17:29:53-EST
                From: J. Noel Chiappa <JNC at MIT-XX.ARPA>

                I was speaking about making the system tattle on changes to
                .KLFE., or did you hack KLFEDR too?

            OOoh. I believe when you write a file on the front-end file system it
            changes pointers which live in files in the ITS directory.

        Nope. There is no entry for NTSDDT CMD in .KLFE.; but running
        KLFEDR reveals that it is there.

    OOoh. I believe when you write a file on the front-end file system it
    changes POINTERS WHICH LIVE IN FILES in the ITS directory.


It's more complicated than that.  We don't use the RSX-11 file system,
we use the KLDCP file system which DEC later flushed..  Also the front-end
files aren't in any one place on the disk, but are scattered all
over.  Some of them, especially the larger ones, reside in individual ITS
files, others are pieces portions of an ITS file.  And if you move or delete
anything on the .KLFE. directory you screw it up since somewhere there is
a KLDCP directory containing absolute disk addresses.
You could make the .KLFE. dir be proetcedt and also make KLFEDR tattle itself
somehow.
\1f
Date: Tue 12 Feb 85 17:55:29-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: NTSDDT
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Tue 12 Feb 85 17:42:00-EST

        I parsed that correctly the second time. Yes, there does seem
to be this file KLDCP (DIR) which macgically contains the actual blocks
of the RSX-11 directory. So you will get the miscreants name (if done
under ITS), but not which file he bashed.
-------
\1f
Date: 12 February 1985 17:42-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  NTSDDT
To: JNC @ MIT-XX
cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
In-reply-to: Msg of Tue 12 Feb 85 17:40:25-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>

    Date: Tue 12 Feb 85 17:40:25-EST
    From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
    To:   CSTACY at MIT-MC.ARPA
    cc:   BUG-ITS at MIT-MC.ARPA, TY at MIT-MC.ARPA, JNC at MIT-XX.ARPA
    Re:   NTSDDT

        Date: 12 February 1985 17:32-EST
        From: Christopher C. Stacy <CSTACY>

            Date: Tue 12 Feb 85 17:29:53-EST
            From: J. Noel Chiappa <JNC at MIT-XX.ARPA>

            I was speaking about making the system tattle on changes to
            .KLFE., or did you hack KLFEDR too?

        OOoh. I believe when you write a file on the front-end file system it
        changes pointers which live in files in the ITS directory.

    Nope. There is no entry for NTSDDT CMD in .KLFE.; but running
    KLFEDR reveals that it is there.

OOoh. I believe when you write a file on the front-end file system it
changes POINTERS WHICH LIVE IN FILES in the ITS directory.


\1f
Date: Tue 12 Feb 85 17:40:25-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: NTSDDT
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Tue 12 Feb 85 17:32:00-EST

        Nope. There is no entry for NTSDDT CMD in .KLFE.; but running
KLFEDR reveals that it is there.
-------
\1f
Date: 12 February 1985 17:32-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  NTSDDT
To: JNC @ MIT-XX
cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
In-reply-to: Msg of Tue 12 Feb 85 17:29:53-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>

    Date: Tue 12 Feb 85 17:29:53-EST
    From: J. Noel Chiappa <JNC at MIT-XX.ARPA>

    I was speaking about making the system tattle on changes to
    .KLFE., or did you hack KLFEDR too?

OOoh. I believe when you write a file on the front-end file system it
changes pointers which live in files in the ITS directory.
\1f
Date: Tue 12 Feb 85 17:29:53-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: NTSDDT
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Tue 12 Feb 85 17:12:00-EST

        I was speaking about making the system tattle on changes to
.KLFE., or did you hack KLFEDR too?
-------
\1f
Date: 12 February 1985 17:12-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  NTSDDT
To: JNC @ MIT-XX
cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
In-reply-to: Msg of Tue 12 Feb 85 12:29:46-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>

Huh? I put the file back into the front-end file system,
and it has been working for a couple of days.
\1f
Date: Tue 12 Feb 85 12:29:46-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: NTSDDT
To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
cc: TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Fri 8 Feb 85 13:17:00-EST

        It's not clear if this will do the right thing, since presumably
the file was also deleted from the RSX-11 directory, which would have used 
KLFEDR or whatever the fuck that program is called. In fact, you could
delete it with KLFEDR and not touch the directory entry in .KLFE. I guess.
-------
\1f
Date: 8 February 1985 23:04-EST
From: David E. Hirsch <HIRSCH @ MIT-MC>
To: BUG-ITS @ MIT-MC

this is NOT hirsh.  I just ROLM'ed to MC and whoops, here I am all logged in and everything.  Oh well.  I'm on T30.
\1f
Date: 8 February 1985 13:17-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: NTSDDT
To: BUG-ITS @ MIT-MC
cc: TY @ MIT-MC

The front end file NTSDDT seems to have been deleted over the weekend.
I re-created it; you can boot the system normally now.
I also made the front-end file directory be tattled on by the system job.
\1f
Date: 29 January 1985 18:00-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: MINITS HUBs making noise
To: BUG-MINITS @ MIT-MC
cc: BUG-ITS @ MIT-MC

NE438B, NE438C, and NE437A have terminal lines running open
or something.  They keep generating a lot of noise, some of
which is control-Zs, so they are connecting to MC and typing
the noise at us.  This eats up network resources and prevents
some people from logging in,etc.  I heard that the power company
is being flaking today, which may have something to do with it.
\1f
Date: 28 January 1985 15:20-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 27 Jan 1985 02:09-EST from Devon S. McCullough <DEVON>

You are probably getting memory parity errors.
\1f
Date: 27 January 1985 02:09-EST
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC

Two or three times in the last day or so I've gotten

top level interrupt, tree detached

This usually happens when I have been typing ^Z's and ^G's because
the system is not responding.  Now I have a dead detached tree.
I can usually type ^_'s to prove that the system itself is alive
even though nothing is responding.
\1f
Date: 26 January 1985 03:47-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: not knowing the time
To: BUG-FTP @ MIT-MC
cc: ALAN @ MIT-MC, BUG-ITS @ MIT-MC

OK, FTP servers now die cleanly if they don't know the time.
\1f
Date: 25 January 1985 23:10-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  no arpa?
To: GSB @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 25 Jan 1985 21:00-EST from Christopher C. Stacy <CSTACY>

    Date: 25 January 1985 21:00-EST
    From: Christopher C. Stacy <CSTACY>
        Date: Fri 25 Jan 85 12:08:58-EST
        From: Glenn S. Burke <GSB at XX>
        is mc's arpa connection busted?  can't reach it from rutgers 
        or xx via internet.
    It does for me at the moment.

I guess you can tell from this that Chris reads his mail in reverse!
\1f
Date: 25 January 1985 21:00-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  no arpa?
To: GSB @ MIT-XX
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of Fri 25 Jan 85 12:08:58-EST from Glenn S. Burke <GSB at MIT-XX.ARPA>

    Date: Fri 25 Jan 85 12:08:58-EST
    From: Glenn S. Burke <GSB at MIT-XX.ARPA>
    To:   bug-its at MIT-MC.ARPA
    Re:   no arpa?

    is mc's arpa connection busted?  can't reach it from rutgers 
    or xx via internet.

It does for me at the moment.
\1f
Date: Fri 25 Jan 85 12:08:58-EST
From: Glenn S. Burke <GSB@MIT-XX.ARPA>
Subject: no arpa?
To: bug-its@MIT-MC.ARPA

is mc's arpa connection busted?  can't reach it from rutgers or xx via internet.
-------
\1f
Date: 25 January 1985 13:06-EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-FTP @ MIT-MC
cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 25 Jan 1985 10:15-EST from Kent M Pitman <KMP>

    Date: 25 January 1985 10:15-EST
    From: Kent M Pitman <KMP>
    System went down at 6:25am this morning. Whoever brought it back up
    forgot to set the time so mostly no one could log in.

And MC hasn't been talking TCP since then, because the tables were clogged
with a zillion dead FTP servers because of the silly .VALUE-when-ITS-
doesn't-know-the-time screw I reported a couple weeks ago.
\1f
Date: 25 January 1985 10:15-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC

System went down at 6:25am this morning. Whoever brought it back up forgot
to set the time so mostly no one could log in.
\1f
Date: 24 January 1985 20:56-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Novelty
To: BUG-ITS @ MIT-MC

Just a event to ponder.  The other day I supduped from MC back to MC
(presumably using Chaosnet, I didn't think to check), and I was greeted
with the following:

    S.1487. PWORD.2630.
    TTY 52
    12. Lusers, Fair Share = 6%

    MC IT*

Note that five characters ("MC IT") have been displaced.  Conceivably the
fact that the machine was so heavily loaded, and that the user and server
were both on the same machine, could have allowed some timing screw that
almost never happens normally.
\1f