From ALAN at MIT-MC.ARPA  Mon Sep 30 22:37:39 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sep 30 85 17:37:39 EDT
Subject: Pooor MC
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.

From ALAN at MIT-MC.ARPA  Sat Sep 28 08:40:59 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sep 28 85 02:40:59 EDT
Subject: No subject
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.

From GZ at MIT-MC.ARPA  Sat Sep 28 05:39:45 1985
From: GZ at MIT-MC.ARPA (Gail Zacharias)
Date: Sep 27 85 23:39:45 EDT
Subject: No subject
Message-ID: <[MIT-MC.ARPA].661709.850927.GZ>

I keep getting top-level interrupts, about once every half hour.

From GZ at MIT-MC.ARPA  Sat Sep 28 05:15:08 1985
From: GZ at MIT-MC.ARPA (Gail Zacharias)
Date: Sep 27 85 23:15:08 EDT
Subject: No subject
Message-ID: <[MIT-MC.ARPA].661707.850927.GZ>

I keep getting top-level interrupts, about once every half hour.

From ALAN at MIT-MC.ARPA  Fri Sep 27 06:13:26 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sep 27 85 00:13:26 EDT
Subject: Bloat
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.

From ALAN at MIT-MC.ARPA  Tue Sep 24 11:07:32 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sep 24 85 05:07:32 EDT
Subject: Now installed on AI, and soon to be installed on MC.
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.

From DEVON at MIT-MC.ARPA  Sat Sep 21 23:34:46 1985
From: DEVON at MIT-MC.ARPA (Devon S. McCullough)
Date: Sep 21 85 17:34:46 EDT
Subject: No subject
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.

From PGS%MIT-OZ at MIT-MC.ARPA  Fri Sep 20 21:14:00 1985
From: PGS%MIT-OZ at MIT-MC.ARPA (PGS%MIT-OZ at MIT-MC.ARPA)
Date: Sep 20 1985  15:14 EDT
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>
Message-ID: <PGS.12144817429.BABYL@MIT-OZ>

    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.

From RIG at MIT-MC.ARPA  Fri Sep 20 19:33:15 1985
From: RIG at MIT-MC.ARPA (Ronald I. Greenberg)
Date: Sep 20 85 13:33:15 EDT
Subject: terminal handler for heath
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.

From GZ at MIT-MC.ARPA  Fri Sep 20 18:40:25 1985
From: GZ at MIT-MC.ARPA (Gail Zacharias)
Date: Sep 20 85 12:40:25 EDT
Subject: What fun!
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?

From JINX%MIT-OZ at MIT-MC.ARPA  Thu Sep 19 19:28:00 1985
From: JINX%MIT-OZ at MIT-MC.ARPA (Bill Rozas)
Date: Sep 19 1985  13:28 EDT (Thu)
Subject: Gnu Emacs on ITS
In-Reply-To: Msg of 19 Sep 1985  10:34-EDT from PGS
Message-ID: <JINX.12144535912.BABYL@MIT-OZ>

What about the pain of having to emulate BSD4.2 system calls?

From PGS%MIT-OZ at MIT-MC.ARPA  Thu Sep 19 16:34:00 1985
From: PGS%MIT-OZ at MIT-MC.ARPA (PGS%MIT-OZ at MIT-MC.ARPA)
Date: Sep 19 1985  10:34 EDT
Subject: No subject
In-Reply-To: Msg of 18 Sep 1985  22:45-EDT from George J. Carrette <GJC at MIT-MC.ARPA>
Message-ID: <PGS.12144504277.BABYL@MIT-OZ>

    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.

From GJC at MIT-MC.ARPA  Thu Sep 19 04:45:51 1985
From: GJC at MIT-MC.ARPA (George J. Carrette)
Date: Sep 18 85 22:45:51 EDT
Subject: No subject
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?

From PGS%MIT-OZ at MIT-MC.ARPA  Mon Sep 16 21:21:00 1985
From: PGS%MIT-OZ at MIT-MC.ARPA (PGS%MIT-OZ at MIT-MC.ARPA)
Date: Sep 16 1985  15:21 EDT
Subject: H-19 initialization
In-Reply-To: Msg of 16 Sep 1985  10:13-EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
Message-ID: <PGS.12143770091.BABYL@MIT-OZ>

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

    CRTSTY sends "[?2hEGOq\wy8y9y5x1" but TCTYP only sends "w"
    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 [?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?

From DEVON at MIT-MC.ARPA  Mon Sep 16 16:13:03 1985
From: DEVON at MIT-MC.ARPA (Devon S. McCullough)
Date: Sep 16 85 10:13:03 EDT
Subject: H-19 initialization
Message-ID: <[MIT-MC.ARPA].646431.850916.DEVON>

CRTSTY sends "[?2hEGOq\wy8y9y5x1" but TCTYP only sends "w"
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 [?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.

From ALAN at MIT-MC.ARPA  Wed Sep 11 08:14:32 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sep 11 85 02:14:32 EDT
Subject: What fun!
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...))

From KLH at MIT-MC.ARPA  Sat Sep  7 22:54:01 1985
From: KLH at MIT-MC.ARPA (Ken Harrenstien)
Date: Sat,  7 Sep 85 16:54:01 EDT
Subject: LOUIE looping
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.

From GSB at MIT-MC.ARPA  Fri Sep  6 10:08:06 1985
From: GSB at MIT-MC.ARPA (Glenn S. Burke)
Date: Fri,  6 Sep 85 04:08:06 EDT
Subject: parity errors
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.

From ALAN at MIT-MC.ARPA  Sun Sep  1 18:57:40 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sun,  1 Sep 85 12:57:40 EDT
Subject: Feature
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.)

From DEVON at MIT-MC.ARPA  Sun Sep  1 00:00:59 1985
From: DEVON at MIT-MC.ARPA (Devon S. McCullough)
Date: Aug 31 85 18:00:59 EDT
Subject: Feature
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?