From ALAN at MIT-MC  Tue Apr 30 07:16:24 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: Apr 30 85 01:16:24 EDT
Subject: Oh yeah, right...
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.

From CENT at MIT-MC  Sat Apr 27 05:53:01 1985
From: CENT at MIT-MC (Pandora B. Berman)
Date: Apr 26 85 22:53:01 EST
Subject: bring back old PDSET
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.

From GUMBY at MIT-MC  Fri Apr 26 09:05:57 1985
From: GUMBY at MIT-MC (David Vinayak Wallace)
Date: Apr 26 85 02:05:57 EST
Subject: More on IMP opto-isolator board -- fixt for now.
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

From GSB at MIT-MC  Tue Apr 23 14:49:26 1985
From: GSB at MIT-MC (Glenn S. Burke)
Date: Apr 23 85 07:49:26 EST
Subject: mc memory randomness
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).

From ALAN at MIT-MC  Tue Apr 23 04:57:01 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: Apr 22 85 21:57:01 EST
Subject: foo
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?

From Moon at SCRC-STONY-BROOK.ARPA  Tue Apr 16 05:32:00 1985
From: Moon at SCRC-STONY-BROOK.ARPA (David A. Moon)
Date: Apr 15 85 22:32 EST
Subject: M-X Copy File 
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 at 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 ^S?

Last week I thought, mistakenly, that using ^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?


From ALAN at MIT-MC  Thu Apr 11 20:10:07 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: Thu,11 Apr 85 13:10:07 EST
Subject: No subject
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?

From GJC at MIT-MC  Mon Apr  8 17:00:36 1985
From: GJC at MIT-MC (George J. Carrette)
Date: Apr 8 85 10:00:36 EST
Subject: blast from the past
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. 

From ALAN at MIT-MC  Mon Apr  8 07:12:06 1985
From: ALAN at MIT-MC (Alan Bawden)
Date: Apr 8 85 00:12:06 EST
Subject: blast from the past
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.

From GJC at MIT-MC  Mon Apr  8 00:08:18 1985
From: GJC at MIT-MC (George J. Carrette)
Date: Apr 7 85 17:08:18 EST
Subject: No subject
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.

From CSTACY at MIT-MC  Fri Apr  5 06:01:54 1985
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: Apr 4 85 23:01:54 EST
Subject: No subject
Message-ID: <mailman.1427.1479821148.4695.its@nocrew.org>

I replied to LIN.

From LIN at MIT-MC  Fri Apr  5 05:37:24 1985
From: LIN at MIT-MC (Herb Lin)
Date: Apr 4 85 22:37:24 EST
Subject: No subject
Message-ID: <mailman.1428.1479821148.4695.its@nocrew.org>

actually, i'm looking for a wizard.  how do you change the
password on ITS for your own account?

tnx.