From DCP at MIT-MC  Sun Sep 30 00:00:00 1984
From: DCP at MIT-MC (David C. Plummer)
Date: 30 September 1984, 00:00
Subject: HOSTS3
Message-ID: <mailman.1062.1479821125.4695.its@nocrew.org>

    Date: 25 September 1984 17:43-EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
        MOON @ SCRC-TENEX

    The latest host table (including HSTNIC #384) is compiled and installed.
    The HOSTS3 compiler is "fixed".

    HOSTS3 hackers: The compiler does not do the sort of dynamic memory
    allocation I had assumed. I was therefore able to make some more room in
    the ITS version simply by moving where in core the table was being
    constructed.  I didn't calculate how much room is left over for new code
    or tables, but the increase should hold us for a while.  Of course, we
    are racing against the rate of host additions on the various networks in
    our table (the Internet, the Chaosnet, etc.)  Hopefully by the time we
    run out it will be time to implement a hairy namespace system.  
    Won't that be fun!
This probably doesn't have a large place in our religion, but you
could consider doing the conversion on a machine with a larger
address space.

From ALAN at MIT-MC  Sun Sep 30 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 30 September 1984, 00:00
Subject: Not critical
Message-ID: <mailman.1063.1479821125.4695.its@nocrew.org>

Giving string arguments to RENAME containing different directories and/or
different devices should cause an error if the "from" device doesn't
support that kind of renameing.  I would suggest either %EBDDV or %ENSMD.
Currently RENAME just ignores the device and directory in the "to"
filename.

The same goes for the devices in the MLINK call.

Note that it is not unreasonable to imagine a job device that supported
cross-directory and cross-device renameing and linking, so the error
returned really should be a function of the device.

From GSB at MIT-MC  Sun Sep 30 00:00:00 1984
From: GSB at MIT-MC (Glenn S. Burke)
Date: 30 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1064.1479821125.4695.its@nocrew.org>

    Date: 28 September 1984 19:13-EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>

    I was just detached because the BABYL I was running claims to have
    gotten a parity error.   The message was top-level interrupt...
    I don't think the sysjob printed anything about parity errors,
    or even sweeped for them....I wonder if it was really a parity error...
    I wonder if this was what happenned to that guy the other day and
    what it is.

Irrecoverable disk error in page mapping gives a parity error interrupt.

From Moon at SCRC-RIVERSIDE.ARPA  Fri Sep 28 21:03:00 1984
From: Moon at SCRC-RIVERSIDE.ARPA (David A. Moon)
Date: Sep 28 84 15:03 EDT
Subject: M-X Copy File 
In-Reply-To: <840928023221.8.RWK@HUDSON.SCRC.Symbolics>
Message-ID: <840928150349.8.MOON@EUPHRATES.SCRC.Symbolics>

    Date: Friday, 28 September 1984, 02:32-EDT
    From: Robert W. Kerns <RWK at SCRC-YUKON>

    [I haven't looked at the code; I'm surmising what's
    going on from your message.  But I think you've forgotten
    some of the more unfortunate parts of ITS!]

No.

	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.  
    HSNAME is the correct thing to set the file author to on ITS,
    because "file authors" are directories, not people.

Yes, the problem is who sets it, not what it sets it to.  It sets it at the time
you close the file, even if you already set it yourself to something better, which
is the source of the bug.

						  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.
    I don't think this makes any difference.  Isn't the problem
    overwriting the explicit CHANGE-PROPERTIES that COPYF does?

If the file job logged in under the right name then it wouldn't need to set the
author itself at the wrong time, because ITS would set it to the right value at
the right time.

	 (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.
    This would involve changing the UFD format, since
    currently the file author is just the MFD index
    of the directory.

How would changing the source of the person's name affect the UFD format?

You're right that the file job would have to set its XUNAME to the person's HSNAME.

	 (3) Make the FILE job set the author when it opens the file instead of
	     when it closes it.
    I think this is right, and the easiest.  Then if a
    CHANGE-PROPERTIES sets it to something else, it will
    prevail, right?

Yes.

From RWK at SCRC-RIVERSIDE.ARPA  Fri Sep 28 08:32:00 1984
From: RWK at SCRC-RIVERSIDE.ARPA (Robert W. Kerns)
Date: Sep 28 84 02:32 EDT
Subject: M-X Copy File 
In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>
Message-ID: <840928023221.8.RWK@HUDSON.SCRC.Symbolics>

[I haven't looked at the code; I'm surmising what's
going on from your message.  But I think you've forgotten
some of the more unfortunate parts of ITS!]

    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.  
HSNAME is the correct thing to set the file author to on ITS,
because "file authors" are directories, not people.

					      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.
I don't think this makes any difference.  Isn't the problem
overwriting the explicit CHANGE-PROPERTIES that COPYF does?

     (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.
This would involve changing the UFD format, since
currently the file author is just the MFD index
of the directory.

     (3) Make the FILE job set the author when it opens the file instead of
	 when it closes it.
I think this is right, and the easiest.  Then if a
CHANGE-PROPERTIES sets it to something else, it will
prevail, right?

From CSTACY at MIT-MC  Fri Sep 28 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 28 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1065.1479821125.4695.its@nocrew.org>

I was just detached because the BABYL I was running claims to have
gotten a parity error.   The message was top-level interrupt...
I don't think the sysjob printed anything about parity errors,
or even sweeped for them....I wonder if it was really a parity error...
I wonder if this was what happenned to that guy the other day and
what it is.

From CSTACY at MIT-MC  Wed Sep 26 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 26 September 1984, 00:00
Subject: FOURTH is back online on MC
Message-ID: <mailman.1066.1479821125.4695.its@nocrew.org>

I didn't see any signs of the Trident disk repairman (John Holden?)
here today, although I thought he was supposed to be come and work
on unit #3 on MC (like I thought he was supposed to do a week ago
when it broke.)   Did he come?

I put the disk back online and tried it out, and it seems to work.
However, if the problem is intermittent, as soon as the drive gets
hot again or whatever it will break and the system will crash etc.

From CSTACY at MIT-MC  Wed Sep 26 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 26 September 1984, 00:00
Subject: x3-5891
In-Reply-To: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1067.1479821125.4695.its@nocrew.org>

    Date: 26 September 1984 00:54-EDT
    From: Alan Bawden <ALAN>

    Thats pretty strange given that that version of PWORD had been working on
    ML for months with no problems.
    Somehow I'm not very confident that we understand what is going on here...

Yeah, but it was getting PDLOV interrupts and I increased the PDL size
and now it works...what can I say?  A new giant host table was
installed today, so maybe PWORD's memory management is all shot to
hell and I have somehow just masked it.  I'll look at it in more
detail soon.   We should move this conversation to just BUG-PWORD.

Chris

From CSTACY at MIT-MC  Wed Sep 26 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 26 September 1984, 00:00
Subject: x3-5891
In-Reply-To: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1068.1479821125.4695.its@nocrew.org>

    Date: 26 September 1984 00:54-EDT
    From: Alan Bawden <ALAN>

    Thats pretty strange given that that version of PWORD had been working on
    ML for months with no problems.
    Somehow I'm not very confident that we understand what is going on here...

Yeah, but it was getting PDLOV interrupts and I increased the PDL size
and now it works...what can I say?  A new giant host table was
installed today, so maybe PWORD's memory management is all shot to
hell and I have somehow just masked it.  I'll look at it in more
detail soon.   We should move this conversation to just BUG-PWORD.

Chris

From ALAN at MIT-MC  Wed Sep 26 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 26 September 1984, 00:00
Subject: x3-5891
In-Reply-To: Msg of 26 Sep 1984 00:43-EDT from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1069.1479821125.4695.its@nocrew.org>

    Date: 26 September 1984 00:43-EDT
    From: Christopher C. Stacy <CSTACY>
    PWORD was losing on ML because it did not have a big enough stack, so
    I fixed it.  

Thats pretty strange given that that version of PWORD had been working on
ML for months with no problems.

		 Why the same version of this program does not run on both
    MC and ML is a mystery to me.

Somehow I'm not very confident that we understand what is going on here...

From CSTACY at MIT-MC  Wed Sep 26 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 26 September 1984, 00:00
Subject: x3-5891
In-Reply-To: Msg of 26 Sep 1984 00:00-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1070.1479821125.4695.its@nocrew.org>


PWORD was losing on ML because it did not have a big enough stack, so
I fixed it.  Why the same version of this program does not run on both
MC and ML is a mystery to me.

Also, I fixed the host-deletion (for "VAR GOOD") stuff long ago, and
although the new code works on MC, it doesn't seem to work on ML: I
can't delete random numbered hosts from the safe list over there.

I'll have to look into these things, but I don't have time today.

From ALAN at MIT-MC  Wed Sep 26 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 26 September 1984, 00:00
Subject: x3-5891
Message-ID: <mailman.1071.1479821125.4695.its@nocrew.org>

Whenever you connect to ML these days PWORD says:

Internal Error: Unknown Interrupt.
Please do :BUG PWORD <description of the problem> ^C
Or call 1-617-253-5891

Even if nobody cares to fix this, I wonder if that phone number has any
relationship to current reality...

From CSTACY at MIT-MC  Tue Sep 25 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 25 September 1984, 00:00
Subject: HOSTS3
Message-ID: <mailman.1072.1479821125.4695.its@nocrew.org>

The latest host table (including HSTNIC #384) is compiled and installed.
The HOSTS3 compiler is "fixed".

HOSTS3 hackers: The compiler does not do the sort of dynamic memory
allocation I had assumed. I was therefore able to make some more room in
the ITS version simply by moving where in core the table was being
constructed.  I didn't calculate how much room is left over for new code
or tables, but the increase should hold us for a while.  Of course, we
are racing against the rate of host additions on the various networks in
our table (the Internet, the Chaosnet, etc.)  Hopefully by the time we
run out it will be time to implement a hairy namespace system.  
Won't that be fun!

From DCP at MIT-MC  Tue Sep 25 00:00:00 1984
From: DCP at MIT-MC (David C. Plummer)
Date: 25 September 1984, 00:00
Subject: MATH-HUB
Message-ID: <mailman.1073.1479821125.4695.its@nocrew.org>

    Date: 24 September 1984 19:35-EDT
    From: Alan Bawden <ALAN @ MIT-MC>

    MIT-MATH-HUB likes to start up a TELNET server on MC, cause it to open a
    STY, and then wait forever without outputing a ^Z (er, "call") to the STY.
    The TELNET job seem to be waiting to .IOT a 377 down its Chaos connection
    to MATH-HUB.  This is a loss because it wastes a STY on MC for no good
    purpose.  If you gun the TELNET job, MATH-HUB just reconnects and starts
    another one.
Well, my guess is that somebody's terminal over there ha a happy
T key.  I found a not-logged-in telnet job from Math Hub, so
here's what I did.
	:CHATST
	L TELNET
uppercase matters!
	[Call]
Gun down the old TELSER and wait for it to reconnect.
Unfortunately, it didn't, so my experiment failed.  If it did, I
would have done
	O (opens the connection, I think)
	S (soak data, I think, to see what it really is sending)
Maybe somebody else will have better luck some other time.

From ALAN at MIT-MC  Mon Sep 24 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 24 September 1984, 00:00
Subject: MATH-HUB
Message-ID: <mailman.1074.1479821125.4695.its@nocrew.org>

MIT-MATH-HUB likes to start up a TELNET server on MC, cause it to open a
STY, and then wait forever without outputing a ^Z (er, "call") to the STY.
The TELNET job seem to be waiting to .IOT a 377 down its Chaos connection
to MATH-HUB.  This is a loss because it wastes a STY on MC for no good
purpose.  If you gun the TELNET job, MATH-HUB just reconnects and starts
another one.

From CSTACY at MIT-MC  Mon Sep 24 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 24 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1075.1479821125.4695.its@nocrew.org>

Well, I think we are finally out of address space.
New host tables cannot be compiled anymore because
they are too massive.  People should not try to
compile any changes until I get back to you,
hopefully with a solution.

From CSTACY at MIT-MC  Mon Sep 24 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 24 September 1984, 00:00
Subject: No subject
In-Reply-To: Msg of 22 Sep 1984 23:32-EDT from Devon S. McCullough <DEVON>
Message-ID: <mailman.1076.1479821125.4695.its@nocrew.org>

    Date: 22 September 1984 23:32-EDT
    From: Devon S. McCullough <DEVON>
    To:   BUG-ITS

    What is %TDSTY and %TDUNF and whatever other innovations 
    have hit the scene?
    Are they documented?


DDT doesn't know about these symbols, and they are not in BITS.
Where did you see them?

From DEVON at MIT-MC  Sat Sep 22 00:00:00 1984
From: DEVON at MIT-MC (Devon S. McCullough)
Date: 22 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1077.1479821125.4695.its@nocrew.org>

What is %TDSTY and %TDUNF and whatever other innovations have hit the scene?
Are they documented?

From Moon at SCRC-RIVERSIDE.ARPA  Sat Sep 22 20:46:00 1984
From: Moon at SCRC-RIVERSIDE.ARPA (David A. Moon)
Date: Sep 22 84 14:46 EDT
Subject: M-X Copy File 
In-Reply-To: <840921083548.6.BSG@CONCORD.SCRC.Symbolics>
Message-ID: <840922144653.0.MOON@EUPHRATES.SCRC.Symbolics>

    Date: Friday, 21 September 1984, 08:35-EDT
    From: Bernard S. Greenberg <BSG at SCRC-TENEX>

	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.

Okay, let me try again.

    It doesn't know the right author at OPEN time.

Yes it does.  Suggestion #3 is that the FILE job set the author to the HSNAME
at OPEN time, before the user has changed the author to something else, rather
than at CLOSE time, after the user has changed the author to something else.

    Excuse me for not being ITSworthy enough, but if the FILE job has the
    option of (2), namely, setting the author to a quantity of its
    liking, why doesn't it remember the result of the PROPERTIES
    command sent at it for this purpose and set the author to what
    the user side WANTS it to be?

Suggestion #2 refers to ITS, not the FILE job.

Yes, I ought to have included the other logically possible suggestion:

	 (4) Keep a copy of the author in the FILE job's memory, instead
	     of in the file system.  Set it to the HSNAME when the file is
	     opened, set it to the new author when CHANGE-PROPERTIES is
	     done, and copy it into the file system when the file is closed.
	     Don't forget to change PROPERTIES, and maybe DIRECTORY-LIST, to
	     return this private copy of the author instead of the one out
	     in the file system.

From MOON at MIT-MC  Sat Sep 22 00:00:00 1984
From: MOON at MIT-MC (David A. Moon)
Date: 22 September 1984, 00:00
Subject: Moon's sabotage of ITS
Message-ID: <mailman.1078.1479821125.4695.its@nocrew.org>

    Date: 10 September 1984 18:37-EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    To: BUG-ITS @ MIT-MC

    The recent change in ITS where the SYS job is given 2 extra job
    slots worth of core (instead of just SYSB) causes the system
    to crash in CORS2 immediately when coming up.

I had put a word count where a page count was expected, so the system
job tried to get about two thousand pages when the system started up.
Fixed in the source, but not reassembled since I wasn't physically
present to test it.

From BSG at SCRC-STONY-BROOK.ARPA  Fri Sep 21 14:35:00 1984
From: BSG at SCRC-STONY-BROOK.ARPA (Bernard S. Greenberg)
Date: Sep 21 84 08:35 EDT
Subject: M-X Copy File 
In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>
Message-ID: <840921083548.6.BSG@CONCORD.SCRC.Symbolics>

    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.
It doesn't know the right author at OPEN time.
    Suggestions?
Excuse me for not being ITSworthy enough, but if the FILE job has the
option of (2), namely, setting the author to a quantity of its
liking, why doesn't it remember the result of the PROPERTIES
command sent at it for this purpose and set the author to what
the user side WANTS it to be?

From PGS%MIT-OZ at MIT-MC.ARPA  Mon Sep 17 15:35:00 1984
From: PGS%MIT-OZ at MIT-MC.ARPA (PGS%MIT-OZ at MIT-MC.ARPA)
Date: Sep 17 1984  09:35 EDT
Subject: How to copy files on ITS without trashing them
In-Reply-To: Msg of 17 Sep 1984  00:11-EDT from Leigh L. Klotz <KLOTZ at MIT-MC>
Message-ID: <PGS.12048286670.BABYL@MIT-OZ>

    Date: Monday, 17 September 1984  00:11-EDT
    From: Leigh L. Klotz <KLOTZ at MIT-MC>
    To:   ALAN at MIT-MC
    cc:   BUG-ITS at MIT-MC, CSTACY at MIT-MC, FEATURE-ENTENNMANS at MIT-MC,
          ITS-LOVERS at MIT-MC, Moon at SCRC-RIVERSIDE
    Re:   How to copy files on ITS without trashing them

    I always move files with TECO myself, <>'ing over the filenames.

Hmm.  I bring the machine down and copy them into the paging area with SALV.

From KLOTZ at MIT-MC  Mon Sep 17 00:00:00 1984
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: 17 September 1984, 00:00
Subject: How to copy files on ITS without trashing them
In-Reply-To: Msg of 16 Sep 1984 20:16-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1079.1479821126.4695.its@nocrew.org>

I always move files with TECO myself, <>'ing over the filenames.

From ALAN at MIT-MC  Sun Sep 16 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 16 September 1984, 00:00
Subject: How to copy files on ITS without trashing them
In-Reply-To: Msg of Sun 16 Sep 84 16:55 EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>
Message-ID: <mailman.1080.1479821126.4695.its@nocrew.org>

    Date: Sun, 16 Sep 84 16:55 EDT
    From: David A. Moon <Moon at SCRC-RIVERSIDE>
    The most convenient way, I have always found, is to use the DIRED
    program....

My recent experience with the DIRED program is that it gets MPVs a lot.  I
always do such things by reading DIR:.FILE. (DIR) into an Emacs buffer and
writing a TECO program to put together an XFILE for DDT to slurp up.  I
like this because it lets me run three different programs (the DIR device,
Emacs and DDT), code in two obscure programming languages (TECO and DDT),
and use two unrelated control-character-oriented command languages (Emacs
and DDT).  Using a JOB device as the first step gets the process started
off on the right foot.  If I can use a translation somehow, thats a big
plus.

Sometimes I run the XFILE in a separate DDT job that I then  so that I
can watch the process using PEEK.  This is especially entertaining when I
are dealing with files using the ML device or the archive device.  The fact
that two jobs are typing on my console at the same time without having
the operating system lose track of the position of my cursor is fun to
contemplate.

If what needs to be done is particularly complex, it's always fun to write a
little assembly language program to do the job.  Preferably by depositing
it directly into a job using DDT, although if I must stoop to using an
assembler I can make up for the loss of face by writing a hairy MIDAS
macro.

From CSTACY at MIT-MC  Sun Sep 16 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 16 September 1984, 00:00
Subject: No subject
In-Reply-To: Msg of 16 Sep 1984 16:32-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1081.1479821126.4695.its@nocrew.org>

Sigh....so much for trusting ZWEI...

From Moon at SCRC-RIVERSIDE.ARPA  Sun Sep 16 23:50:00 1984
From: Moon at SCRC-RIVERSIDE.ARPA (David A. Moon)
Date: Sep 16 84 17:50 EDT
Subject: Source for :TIME
In-Reply-To: The message of 6 Sep 84 02:21-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <840916175052.0.MOON@EUPHRATES.SCRC.Symbolics>

    Date: 6 September 1984 02:21-EDT
    From: Alan Bawden <ALAN @ MIT-MC>

    Well, I just retrieved source files for a bunch of ITS system programs from
    AI and ML backup tapes.  I was able to find an OLD source for :TIME
    (version 25, version 39 is installed on MC right now...).  The most up to
    date source probably lives only on DM backup tapes.  Do we have a way to
    read DM backup tapes?  Did anyone write such a tool when the DM users moved
    to XX?  The good news is that as far as I can tell, TIME is the -only-
    program whose source file is trapped in that particular way...

I don't know of any way to do it, but the format is so simple.  Each file
on the tape is a file (i.e. there are tape marks between the files) and
just has some header information at the front.

From Moon at SCRC-RIVERSIDE.ARPA  Sun Sep 16 23:30:00 1984
From: Moon at SCRC-RIVERSIDE.ARPA (David A. Moon)
Date: Sep 16 84 17:30 EDT
Subject: Top level interrupt
In-Reply-To: The message of 13 Sep 84 21:55-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <840916173045.7.MOON@EUPHRATES.SCRC.Symbolics>

    Date: 13 September 1984 21:55-EDT
    From: Alan Bawden <ALAN @ MIT-MC>

	Date: 13 September 1984 19:44-EDT
	From: Christopher C. Stacy <CSTACY>
	    Date: 13 September 1984 14:46-EDT
	    From: Benjamin Kuipers <BEN>
	    What is this nonsense about "Top level interrupt.  Tree detached."
	No, it means that your top-level process (presumably HACTRN) got a
	fatal interrupt and died, detaching the entire tree.  This could
	possibly be the result of a memory parity error.

    I looked around for such dead trees when I first got this bug report, but I
    didn't find any to figure out what happened to him.  There have been no
    parity errors for the last day, so that couldn't be the reason.

There used to be a buglet, which may still be there, related to this.  When
a dialup line hangs up the system job would type "Top level interrupt, tree
detached" on it.  Of course there's no one on the other end of a hung-up dialup
line, so no one ever sees this message.  But if it wasn't -really- hung up...

Did this happen on a dialup line or a ROLM line by any chance?

From Moon at SCRC-RIVERSIDE.ARPA  Sun Sep 16 22:55:00 1984
From: Moon at SCRC-RIVERSIDE.ARPA (David A. Moon)
Date: Sep 16 84 16:55 EDT
Subject: How to copy files on ITS without trashing them
In-Reply-To: The message of 16 Sep 84 16:32-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <840916165519.5.MOON@EUPHRATES.SCRC.Symbolics>

The most convenient way, I have always found, is to use the DIRED program.
Not the Emacs one, the other one.  It has a set of file-processing commands
that take the star convention and it's fast.  The only problem is that the
right MOVE command has some obscure name like BC (don't trust my memory on this!)

From ALAN at MIT-MC  Sun Sep 16 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 16 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1082.1479821126.4695.its@nocrew.org>

God DAMNIT!  When I came in this morning MC had no free job slots because
the system was completely full of dead TIME servers.  After gunning about
50 of them so that I could work I found out that all of the binary files on
SYSNET, including the time server, had been trashed.  You can probably
guess why: when you use M-X Copy File from a Lisp Machine it must clobber
36-bit binary files named BIN by DWIMing and treating them as 32-bit
L-machine BIN files.  I'll bet if there were any text files on the old TCP
directory that contained imbedded ^M's they have been trashed as well by
being copied in Lisp Machine character set mode.  And I know you already
noticed that Copy File clobbered all of the author information.  You really
should have used :MOVE rather than deluding yourself into thinking that a
Lisp Machine could make the job easier.

I reassembled the time server, but I leave it up to you to deal with the
rest of the mess.  I would advise retrieving the entire TCP directory and
doing it again the right way.

From RAY at MIT-MC  Sat Sep 15 00:00:00 1984
From: RAY at MIT-MC (Ray Hirschfeld)
Date: 15 September 1984, 00:00
Subject: ROLM lines
Message-ID: <mailman.1083.1479821126.4695.its@nocrew.org>

Because the new ROLM lines are specified as dialup lines in TTYTYP,
typing ":ttyloc foo" produces a location of not "foo" but instead
"Dialup: foo", a misfeature.

From MoonatSCRC-TENEX  Sat Sep 15 00:00:00 1984
From: MoonatSCRC-TENEX (David A. Moon)
Date: Saturday, 15 September 1984, 00:00
Subject: M-X Copy File 
In-Reply-To: The message of 14 Sep 84 21:00-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
Message-ID: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>

    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?

From CSTACY at MIT-MC  Fri Sep 14 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 14 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1084.1479821126.4695.its@nocrew.org>

The TCP; directory on MC is now called "SYSNET;".

From CSTACY at MIT-MC  Fri Sep 14 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 14 September 1984, 00:00
Subject: M-X Copy File 
Message-ID: <mailman.1085.1479821126.4695.its@nocrew.org>

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.

From CSTACY at MIT-MC  Fri Sep 14 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 14 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1086.1479821126.4695.its@nocrew.org>

T-300 unit 3 was going offline spontanesouly, causing the
system to hang on some operations.  It should be fixed
Monday or Tuesday.

From ALAN at MIT-MC  Thu Sep 13 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 13 September 1984, 00:00
Subject: Top level interrupt
In-Reply-To: Msg of 13 Sep 1984 19:44-EDT from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1087.1479821126.4695.its@nocrew.org>

    Date: 13 September 1984 19:44-EDT
    From: Christopher C. Stacy <CSTACY>
        Date: 13 September 1984 14:46-EDT
        From: Benjamin Kuipers <BEN>
        What is this nonsense about "Top level interrupt.  Tree detached."
    No, it means that your top-level process (presumably HACTRN) got a
    fatal interrupt and died, detaching the entire tree.  This could
    possibly be the result of a memory parity error.

I looked around for such dead trees when I first got this bug report, but I
didn't find any to figure out what happened to him.  There have been no
parity errors for the last day, so that couldn't be the reason.  If he was
neglecting to log in, PWORD gets a top level interrupt when your
not-logged-in-time-limit expires rather than telling you why you are going
away, but then it would have warned him in advance that this was likely to
occur if he hadn't logged in.  I hope there is no signifigance to the fact
that what the SYSJOB really types is "Top level interrupt, tree detached"...

From GSB at MIT-MC  Thu Sep 13 00:00:00 1984
From: GSB at MIT-MC (Glenn S. Burke)
Date: 13 September 1984, 00:00
Subject: supdup
Message-ID: <mailman.1088.1479821126.4695.its@nocrew.org>

ok, i looked up %nsrcl -- cls received while in rfc received state.
I made it treat this the same as %nscls, it now exits and says
"Connection being closed by foreign host."

From DCP at MIT-MC  Thu Sep 13 00:00:00 1984
From: DCP at MIT-MC (David C. Plummer)
Date: 13 September 1984, 00:00
Subject: supdup
Message-ID: <mailman.1089.1479821126.4695.its@nocrew.org>

    Received: by mit-borax.ARPA (4.12/4.7)
    	id AA03676; Thu, 13 Sep 84 16:15:39 edt
    From: dab at mit-borax (David A. Bridgham)
    Date: 13 Sep 1984 1615-EDT (Thursday)

    	I recently wrote a supdup server for VAX UNIX running on TCP.
    This is currently running on MIT-BORAX.  To test it I would supdup in
    from lisp machines or CCC.  This forwards through MC with no problem.
    However, from MC if I type ":supdup borax" it sits for a while and says
    that the connection timed out without getting established.  Could anyone
    help?  Thanks.
It works for me.  I get the error somebody else already reported
by typing ^D to the login prompt.  You are probably violating the
logout protocol or something.

From CSTACY at MIT-MC  Thu Sep 13 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 13 September 1984, 00:00
Subject: No subject
In-Reply-To: Msg of 13 Sep 1984 14:46-EDT from Benjamin Kuipers <BEN>
Message-ID: <mailman.1090.1479821126.4695.its@nocrew.org>

    Date: 13 September 1984 14:46-EDT
    From: Benjamin Kuipers <BEN>
    To:   BUG-ITS

    What is this nonsense about 
    "Top level interrupt.  Tree detached."
    This has happened to me twice in the last couple
    of hours.  Have I been gunned?
    			Ben

No, it means that your top-level process (presumably HACTRN) got a
fatal interrupt and died, detaching the entire tree.  This could
possibly be the result of a memory parity error.

From BEN at MIT-MC  Thu Sep 13 00:00:00 1984
From: BEN at MIT-MC (Benjamin Kuipers)
Date: 13 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1091.1479821126.4695.its@nocrew.org>

What is this nonsense about 
"Top level interrupt.  Tree detached."
This has happened to me twice in the last couple
of hours.  Have I been gunned?
			Ben

From ALAN at MIT-MC  Wed Sep 12 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 12 September 1984, 00:00
Subject: archive
In-Reply-To: Msg of 11 Sep 1984 13:12-EDT from Alan Bawden <ALAN>
Message-ID: <mailman.1092.1479821126.4695.its@nocrew.org>

    Date: 11 September 1984 13:12-EDT
    From: Alan Bawden <ALAN>
    Well .INFO. really is full to bursting, especially after I rescued some
    info files from ML.  I suppose this is yet another excuse to create the
    SYSDOC directory and move a bunch of operating-system specific files there.
    The problem is that a fair number of them will want to leave links behind
    in .INFO. and links take up more directory room than a small file...

OK, I created SYSDOC and moved a bunch of stuff there.  .INFO. has a bit of
room again.  People who care are welcome to shuffle the documentation
around more if they like.  Just don't break anything.

From WJL at MIT-MC  Wed Sep 12 00:00:00 1984
From: WJL at MIT-MC (Bill Long)
Date: 12 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1093.1479821126.4695.its@nocrew.org>

When the Rolm switch tries 4991 to get MC, it times out.

From KLOTZ at MIT-MC  Tue Sep 11 00:00:00 1984
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: 11 September 1984, 00:00
Subject: 20th Anniversary of 36 Bits
In-Reply-To: Msg of 11 Sep 1984 04:24-EDT from Pandora B. Berman <CENT>
Message-ID: <mailman.1094.1479821126.4695.its@nocrew.org>

Don't forget Don Eastlake, DEE at CCA, I think.

From ALAN at MIT-MC  Tue Sep 11 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 11 September 1984, 00:00
Subject: archive
In-Reply-To: Msg of 11 Sep 1984 09:30-EDT from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1095.1479821126.4695.its@nocrew.org>

    Date: 11 September 1984 09:30-EDT
    From: Christopher C. Stacy <CSTACY>
    I moved it to .INFO. because I am usually have alot of trouble updating
    or re-assemble the ITS because the SYSTEM directory is full; I figured
    SYSTEM sources ought to live in SYSTEM and that info ought to live in
    .INFO..

Well .INFO. really is full to bursting, especially after I rescued some
info files from ML.  I suppose this is yet another excuse to create the
SYSDOC directory and move a bunch of operating-system specific files there.
The problem is that a fair number of them will want to leave links behind
in .INFO. and links take up more directory room than a small file...

From CSTACY at MIT-MC  Tue Sep 11 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 11 September 1984, 00:00
Subject: archive
In-Reply-To: Msg of 10 Sep 1984 23:50-EDT from Pandora B. Berman <CENT>
Message-ID: <mailman.1096.1479821126.4695.its@nocrew.org>

I moved it to .INFO. because I am usually have alot of trouble updating
or re-assemble the ITS because the SYSTEM directory is full; I figured
SYSTEM sources ought to live in SYSTEM and that info ought to live in .INFO..

From ED at MIT-MC  Tue Sep 11 00:00:00 1984
From: ED at MIT-MC (Ed Schwalenberg)
Date: 11 September 1984, 00:00
Subject: Recent spate of crashes
Message-ID: <mailman.1097.1479821126.4695.its@nocrew.org>

NAME uses CORBLK to read in the ASCII file SYSENG;TTYTYP > and parses through
it looking for the magic comments of the form ;T00 System Console, which it
records in its database.  It is under the mistaken impression that the file
in core will be terminated by either nulls or ^C's; the documentation for
CORBLK says no such thing.  In fact, the difference between the length of a
file as returned by FILLEN and the next page boundary is filled with garbage.
I edited SYSTEM;TTYTYP > to create a copy that is "identical" to the previous
version except that it has some nulls in the garbage that follows the last
valid word.  The bug should be really fixed in the source.  I wonder how many
other programs depend on this sort of thing?

From CENT at MIT-MC  Tue Sep 11 00:00:00 1984
From: CENT at MIT-MC (Pandora B. Berman)
Date: 11 September 1984, 00:00
Subject: 20th Anniversary of 36 Bits
Message-ID: <mailman.1098.1479821126.4695.its@nocrew.org>

    Date: Tue 11 Sep 84 02:44:10-CDT
    From: Clive Dawson <CC.Clive at UTEXAS-20.ARPA>
    Subject: Re: 20th Anniversary of 36 Bits
    To: CENT at MIT-MC.ARPA
    Thanks for the info and suggestions.  We certainly have Greenblatt on
    the list.  In fact I talked to him at AAAI here in Austin recently and
    there's a good chance we can get him to be on the panel at the
    Pioneer's Rountable session.  I certainly would like to add other ITS
    people to the general list of invitees.  Do you suppose you (or
    somebody else) could provide me with a list of such people, including a
    brief comment describing their connection to the 36-bit machines?  I'll
    add Holloway (is he an original ITS developer?); also I have people
    like Gosper and Schroeppel of HAKMEM fame, and RMS.  I suspect there
    are quite a few others.
    Thanks,
    CLive

i'm not your best source for this, being a relative latecomer (i got to the
lab in the middle of the lisp machine effort). try Tom Knight (TK at MC) --
built the Knight TV system (was attached to the AI KA-10) for his undergrad
thesis -- and Ken Harrenstein (KLH at MC or @NIC) -- wrote COMSAT, the ITS
mailer, for his -- for a better list.  i believe holloway was mostly a
hardware hacker; he had a lot to do with the KA paging box (we apparently
have a confusion with the TOPS10 people over who did paging first).  RWG
and RMS are reachable at those names by mail to MC, as is MOON, who wrote
the ITS microcode for the KL; i don't know where schroeppel is these days,
he's been gone from here for a while.
i think we have the AI-6's chess trophies for MAKHAK 6 around somewhere;
probably RG knows.

From CENT at MIT-MC  Mon Sep 10 00:00:00 1984
From: CENT at MIT-MC (Pandora B. Berman)
Date: 10 September 1984, 00:00
Subject: archive
Message-ID: <mailman.1099.1479821126.4695.its@nocrew.org>

i moved the ITS BUGS archive from .INFO.;, which was bursting, back to
SYSTEM; where it apparently used to be, and where there is more space.
i have no idea who thought it was a good idea to move it to .INFO. .

From CENT at MIT-MC  Mon Sep 10 00:00:00 1984
From: CENT at MIT-MC (Pandora B. Berman)
Date: 10 September 1984, 00:00
Subject: 20th Anniversary of 36 Bits
Message-ID: <mailman.1100.1479821126.4695.its@nocrew.org>

don't forget ITS, Greenblatt (RG at OZ, currently at LMI in cambridge),
Holloway (H at MC, currently at Symbolics in cambrige), and all the other ITS
hackers.  in many ways ITS is STILL the best 10-family OS (we are now in
the process of porting it to a 2020).

From CSTACY at MIT-MC  Mon Sep 10 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 10 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1101.1479821126.4695.its@nocrew.org>

The recent change in ITS where the SYS job is given 2 extra job
slots worth of core (instead of just SYSB) causes the system
to crash in CORS2 immediately when coming up.

Version 1378 is the same as 1377, but with the other new modules
(INET, CORE, SYSJOB) incorporated.  We also have the new TTYTYP
file and the front-end files (IOELEV, BOOT11, etc) have been
updated.   This is all XITS.   You can't boot the old version
(ITS) in the normal fashion since one of the boot command files
has been changed, so I hope it continues to work.

From ALAN at MIT-MC  Thu Sep  6 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 6 September 1984, 00:00
Subject: Source for :TIME
Message-ID: <mailman.1102.1479821126.4695.its@nocrew.org>

Well, I just retrieved source files for a bunch of ITS system programs from
AI and ML backup tapes.  I was able to find an OLD source for :TIME
(version 25, version 39 is installed on MC right now...).  The most up to
date source probably lives only on DM backup tapes.  Do we have a way to
read DM backup tapes?  Did anyone write such a tool when the DM users moved
to XX?  The good news is that as far as I can tell, TIME is the -only-
program whose source file is trapped in that particular way...

From CSTACY at MIT-MC  Wed Sep  5 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 5 September 1984, 00:00
Subject: No subject
Message-ID: <mailman.1103.1479821126.4695.its@nocrew.org>

I gunned a tree which had jobs zorched by parity errors.
The job state in PEEK went to *MULTIX and I thought it was
trying to log out (since it usually does that after LOGOUT).
It never went away and I could not UJOB it (job not found).
I think it was blocked in a SLEEP call; I bashed its flush
instruction to zero and it imediately went away.

From Bjorn_Danielsson_QZ%QZCOM.MAILNET at MIT-MULTICS.ARPA  Tue Sep  4 15:00:00 1984
From: Bjorn_Danielsson_QZ%QZCOM.MAILNET at MIT-MULTICS.ARPA (Bjorn_Danielsson_QZ%QZCOM.MAILNET at MIT-MULTICS.ARPA)
Date: 04 Sep 84 15:00 +0200
Subject: ITS for swedish KA10
Message-ID: <68570@QZCOM>

Thanks for your reply. I wasn't sure if my letters got through, or
if I was addressing the right people. Our MAILNET connection is still
somewhat experimental.

The machine is a gift from DEC (or rather, we got it very cheap: 1 SEK
which is approximately 15 cents), we have transported it from its previous
home in Finland to Sweden, and are now planning to re-install it here.
We have experienced hardware hackers who plan to build their own memory,
paging box, and possibly other things too.

Existing hardware:

        1  KA10 cpu
        3  MF10 in working condition
        1  MF10 with essentially a missing backplane
        2  DF10 data channel (18-bit)

        1  RP10 disk controller
        2  RH10 massbus controller
        1  TM10 tape controller

        1  DC10 with 32 lines
        1  BA10 hard copy controller
        1  TU10 tape drive
        1  RP02 disk drive
        1  Line printer
        1  Card reader (!)

Some of us work at the university computer center, so we have access
to DEC10's and 20's where we can read tapes, cross-compile sources etc
if necessary. We are grateful for any information you can give us,
either through the network, or by ordinary mail to:

        Datorforeningen STACKEN
        c/o NADA
        Royal Institute of Technology
        S-100 44 Stockholm
        SWEDEN




From CENT at MIT-MC  Mon Sep  3 00:00:00 1984
From: CENT at MIT-MC (Pandora B. Berman)
Date: 3 September 1984, 00:00
Subject: we hear you
Message-ID: <mailman.1104.1479821126.4695.its@nocrew.org>

    Date:        27 Aug 84 20:48 +0200
    From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET at MIT-MULTICS.ARPA
    To:          GSB at MIT-MC.ARPA
    Subject:     ITS
    Hello.
    Some friends of mine in the computer club STACKEN in Stockholm, Sweden
    want to get hold of an ITS operating system for their KA-10 computer.
    Could you tell me if it is possible to get the sources and
    documentation, including information about the extra paging hardware?
			    Bjorn Danielsson

hello out there. we are glad to hear that, somewhere else in the world, ITS
lovers exist. it is theoretically possible, but technically a bit
difficult, to give your friends the information they need to bring up ITS
on their KA -- difficult because it's hard to assemble. we are working on
trying to put together the right stuff for them, but it may take a while.
any further information you can give on what their KA is like can only be
helpful.  please address futher communications on this subject to
BUG-ITS at MC, so we will all see them.