Consolidate license copies

[its.git] / sysdoc / its.obugs1

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.
------------------------------

Date: 23 January 1985 23:47-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Tempest in a TELSER.
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, DANIEL @ MIT-MC
In-reply-to: Msg of 23 Jan 1985 17:42-EST from Alan Bawden <ALAN>

    Date: 23 January 1985 17:42-EST
    From: Alan Bawden <ALAN>
    ...  I plan to fix the timeout algorithm to close the connection after
    it sees the STY idle twice in a row.  That, and a check every 15
    seconds, should assure you of at -least- 15 seconds (but not more than
    30) before closing the connection....

Ok I did this.  Actually I did it with a 20 second timeout.  Thus, you now
get at least 20 seconds, at most 40 seconds, and an average of 30 seconds.
A reason to want a longer timeout is to give the TELSER's single page a
chance to swap out and stay out.  This probably doesn't matter much on MC
but it might help a bit on AI.  

An alternative solution, that would take a few more lines of code, would be
for TELSERs to keep a USR: channel open to the toplevel job on the other
end of the STY.  Then they would get an interrupt when that job went away,
indicating some kind of interesting job manipulation was taking place on
the other side.  Unfortunately nothing would happen if the tree was just
detached, foo.
\1f
Date: 23 January 1985 17:42-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Tempest in a TELSER.
To: DANIEL @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 22 Jan 1985 19:39-EST from Daniel Weise <DANIEL>

    Date: 22 January 1985 19:39-EST
    From: Daniel Weise <DANIEL>
    Why is MC suddenly breaking supdup connections when I 
    log out?  I prefer the behavior where I have to manually
    break the connection.

'Cause we are experimenting with adjusting the timeout to different values.
Currently it is patched to be 15 seconds.  For years it has been set at 5
minutes.  I think we are all agreed that the current setting is a loser.  I
plan to fix the timeout algorithm to close the connection after it sees the
STY idle twice in a row.  That, and a check every 15 seconds, should assure
you of at -least- 15 seconds (but not more than 30) before closing the
connection.

Unless anybody would like to object or propose anything else?
\1f
Date: 22 January 1985 19:39-EST
From: Daniel Weise <DANIEL @ MIT-MC>
To: BUG-ITS @ MIT-MC

Why is MC suddenly breaking supdup connections when I 
log out?  I prefer the behavior where I have to manually
break the connection.
\1f
Date: 22 January 1985 14:35-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: TELSER timeout
To: CBF @ MIT-MC, CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

The current timeout is definitely too short.  MC has hung up on me
instantly a couple of times in the last few days.  Perhaps the code should
be fixed to log itself out only if it sees the STY idle twice in a row.
\1f
Date: 20 January 1985 19:33-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Page fault caused by .GETSYS
To: BUG-ITS @ MIT-MC
cc: KMP @ MIT-MC
In-reply-to: Msg of 19 Jan 1985 17:07-EST from Kent M Pitman <KMP>

    Date: 19 January 1985 17:07-EST
    From: Kent M Pitman <KMP>
    MC died claiming:
     Page fault in system at 304000,,130422

This has been happening on and off for quite some time.  .GETSYS would
sometimes cause a seemingly spurious page fault.  I introduced this bug
myself last summer and I just fixed it in the source.  Sure feels good to
delete some of those crash dumps knowing that you actually fixed the
problem!
\1f
Date: 20 January 1985 10:46-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  Closing net connections when your STY goes away 
To: CBF @ MIT-MC
cc: BUG-ITS @ MIT-MC, MRC @ SU-SCORE
In-reply-to: Msg of 18 Jan 1985 22:42-EST from Charles Frankston <CBF>

Five minutes is admittedly a long time.  I think I would be happy if
it were one half minute, I think (15 seconds might be OK, but I want
to be more gracious).  If no one responds to CBF's query in a few days,
I'll change it in the source.

\1f
Date: 20 January 1985 10:44-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  HSNAME change
To: ALAN @ MIT-MC
cc: BRUC @ MIT-MC, BUG-DDT @ MIT-MC, BUG-INQUIR @ MIT-MC,
    BUG-ITS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC,
    USER-ACCOUNTS @ MIT-MC
In-reply-to: Msg of 19 Jan 1985 02:35-EST from Alan Bawden <ALAN>

I fixed this (right this time).
\1f
Date: 19 January 1985 17:07-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC died claiming:
 Page fault in system at 304000,,130422
 BugPC/ PFA3+2

I dumped this to CRASH;PFA3+2 19-JAN
and cold booted. -kmp
\1f
Date: 19 January 1985 02:35-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  HSNAME change
To: CSTACY @ MIT-MC, KMP @ MIT-MC, BUG-INQUIR @ MIT-MC
cc: USER-ACCOUNTS @ MIT-MC, BRUC @ MIT-MC, BUG-DDT @ MIT-MC,
    TAFT @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 18 Jan 1985 23:48-EST from Robert E. Bruccoleri <BRUC>

    Date: 18 January 1985 23:48-EST
    From: Robert E. Bruccoleri <BRUC at MC>
    My home directory was changed from USERS0; to GUEST0; recently
    without the relocation of my files or the redirection of my mail....

    Date: 18 January 1985 23:59-EST
    From: Kent M Pitman <KMP at MC>
    INQUIR seems to give people with a "Z" designation (clinical decision
    making group) a GUESTn home dir if they don't have a home dir of their
    own.  This is arguably a bug....

Earlier the same day....

    Date: 18 January 1985 09:26-EST
    From: Christopher C. Stacy <CSTACY at MC>
    Subject: AI file directories
    To: BUG-INQUIR at MC
    cc: BUG-DDT at MC, BUG-ITS at MC, KMP at MC, TAFT at MC
    Enough occasional and small users from AI use MC now that I was
    getting tired of using INQUIR to manually force their home directory
    to be AI0.  This morning I taught INQUIR that if an "A" person comes
    along who does not have a directory, it will automatically stick them
    in AI0 (rather than USERSn).  Of course, if AI0 starts getting too
    full due to many people, we can make more dirs.   But I don't think
    that's too likely since most AI people with alot of files have their
    own directory and don't need to use AI0.

Well, more than just AI users seem to have their directories changed, so I
retracted the new version of LSRTNS, reassembled DDT (being careful to
increment the version number this time) and installed it.  The buggy 
ATSIGN DDT was renamed to be ATSIGN XDDT.
\1f
Date: 18 January 1985 22:42-EST
From: Charles Frankston <CBF @ MIT-MC>
Subject:  Closing net connections when your STY goes away 
To: CSTACY @ MIT-MC, MRC @ SU-SCORE
cc: BUG-ITS @ MIT-MC

Well, I think the current timeout is kind of long, so I have temporarily
patched it to 15 seconds instead of 5 minutes.  If anyone remembers why
it was 5 minutes, I'd be interested in knowing.

This will also help free up STYs faster for those times when the system
is heavily loaded.
\1f
Date: 18 January 1985 17:35-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  TAC binary mode
To: MRC @ SU-SCORE
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of Fri 18 Jan 85 09:25:48-PST from Mark Crispin <MRC at SU-SCORE.ARPA>


Foo. We like it waiting for me to type "^Z", rather than gratitously
disconnecting.  As for decisions being cast in stone, I just happen to
think it is the right decision (and the users and other programmers
here concur.)  If you re-read my message, I did suggest that perhaps
there should be a way for users to ask to be disconnected upon logout.
By the way, when coming in over the net I myself turn on binary mode
in my login init file so that I can use the META key on my home
terminal.  Since I run a program (:TBMOFF) in my logout init file
which turns it back off, I never get wedged.

\1f
Date: Fri 18 Jan 85 09:25:48-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
To: CSTACY@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Fri 18 Jan 85 03:06:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Bullshit.  The connection was *not* in a wedged state.  It was
waiting for me to type CTRL/Z to start another ITS job.  I deliberately
typed @ B I S because I wanted a binary link without the TAC intercept
character interfering.  The last thing I want when I am logged in to a
host is to have the damn Tip (be it Internet, Chaos, Pup, DECnet, or
whatever) decide to grab one of my characters as an intercept character.
I know damned well how to change the intercept character, but with the
advent of certain display editors which use all 128 ASCII characters for
commands there is NO "safe" intercept character.

     One of the reasons why ITS in the old days was so great was that
the system programmers of that time didn't consider the decisions of the
past to be enshrined in stone and unchangable.
-------
\1f
Date: 18 January 1985 09:26-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: AI file directories
To: BUG-INQUIR @ MIT-MC
cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC

Enough occasional and small users from AI use MC now that I was
getting tired of using INQUIR to manually force their home directory
to be AI0.  This morning I taught INQUIR that if an "A" person comes
along who does not have a directory, it will automatically stick them
in AI0 (rather than USERSn).  Of course, if AI0 starts getting too
full due to many people, we can make more dirs.   But I don't think
that's too likely since most AI people with alot of files have their
own directory and don't need to use AI0.

\1f
Date: 18 January 1985 06:06-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Sender: CSTAC0 @ MIT-MC
To: MRC @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 17 Jan 1985 21:58-EST from Mark Crispin <MRC>


Come on, the bug is clearly in your user host which stopped paying
attention to you.  Closing your connection is just one thing which it
prevented you from doing by putting you into a wedged state.
It is a feature that ITS does not close connections when you log out.
Maybe there should be a :LOGOUT option to force your connection closed
though, for people who want this.
\1f
Date: 17 January 1985 23:10-EST
From: Richard M. Stallman <RMS @ MIT-MC>
To: BUG-ITS @ MIT-MC

I always find it unpleasant when OZ breaks connections with me
just because I log out.  
\1f
Date: 17 January 1985 21:58-EST
From: Mark Crispin <MRC @ MIT-MC>
To: BUG-ITS @ MIT-MC

I wish ITS closed the connection when you logged out.  It is easier to
re-open the connection if you want it than it is to extract yourself
from a host which won't hang up when you log out.  I had to gun my TELSER
to get out of a @B I S connection from the TAC.
\1f
Date: 17 January 1985 15:06-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC's network terminals and the (AAA) next to the system console and
such stopped responding. The system console seemed to be happy, so I
ran :.;BOOT11 from there and things seem happy again.
\1f
Date: 11 January 1985 19:37-EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To: TAR @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
In-reply-to: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ <TAR>

    Date: 9 January 1985 15:48-EST
    From: Thomas A. Russ <TAR>
    Sender: TAR0
    To:   BUG-ITS

    :CHUNAME doesn't work.  It prints the "-- Massacre and Reset --"
    question, but when I type <space>, it responds with a single question
    mark ("?") and does nothing.

Probably you, in your incarnation as TAR0, were trying to :CHUNAM to
TAR, but there already was a TAR, possibly detached.  DDT was informing
you in its usual terse fashion, (which has saved us at last count over
2^23 character output calls since ITS was first booted).

\1f
Date: 10 January 1985 01:23-EST
From: Howard D. Trachtman <HDT @ MIT-MC>
Subject: archives
To: BUG-ITS @ MIT-MC
cc: HDT @ MIT-MC, CSTACY @ MIT-MC

It also seems to me that control-Zing out of writing a file in emacs and
proceeding consitently leaves a Jjob in my name, but which doesn't seem
to get restarted in a manner capable of finishing the write.
\1f
Date: 9 January 1985 23:12-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: HDT @ MIT-MC

When an archive device dies maybe it should return device not available
or if it was because of size limitations, device full.
\1f
Date: 9 January 1985 16:04-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: TAR @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
In-reply-to: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ <TAR>

    Date: 9 January 1985 15:48-EST
    From: Thomas A. Russ <TAR>
    Sender: TAR0
    To:   BUG-ITS

    :CHUNAME doesn't work.  It prints the "-- Massacre and Reset --"
    question, but when I type <space>, it responds with a single question
    mark ("?") and does nothing.

This would probably be a DDT bug, not an ITS bug.
:CHUNAME works fine for me.  Please send a real bug report,
specifying the input you gave the function.
\1f
Date: 9 January 1985 15:48-EST
From: Thomas A. Russ <TAR @ MIT-MC>
Sender: TAR0 @ MIT-MC
To: BUG-ITS @ MIT-MC

:CHUNAME doesn't work.  It prints the "-- Massacre and Reset --"
question, but when I type <space>, it responds with a single question
mark ("?") and does nothing.

\1f
Date: 4 January 1985 19:48-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Tape archives
To: greif @ MIT-XX
cc: BUG-ITS @ MIT-MC

How much tape are you actually talking about flushing?  I doubt you plan
to re-use the tapes; therefore it must just be the storage requirements
that you object to.  But tapes don't take up much room at all (depending
on how you chose to store them), and even if there is only one file on
each tape which is worth keeping, it is still much easier to simply keep
that tape than to try to achieve any kind of compaction.

I don't think any ITS tapes should be junked unless a large majority of
ITS users thinks it is reasonable.  There just is no way to predict
which files you will someday be interested in retrieving, and once they
are flushed, they are gone forever.  The ITS systems have vastly more
historic significance than MIT-XX, or in fact most other computer systems
on the network, and this should be a consideration.

Incidentally, the notion of taking a complete file system dump and locking
it away for backup, archival, or posterity is considered a good idea in
other places as well.  We do this on SRI-NIC, for example.  Perhaps
you are just doing it too often.
\1f
Date: 4 January 1985 01:21-EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: amazing brain damage
To: BUG-ITS @ MIT-MC

irene grief has apparently gotten the idea into her head that
flushing all old ITS tapes up to six months ago is not only
feasible but a good idea. see CENT;LCS TAPES for details.
\1f
Date: 2 January 1985 15:14-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  hangup
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC
In-reply-to: Msg of 2 Jan 1985 14:15-EST from Alan Bawden <ALAN>


    Date: 2 January 1985 14:15-EST
    From: Alan Bawden <ALAN>
    In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy <CSTACY>

    Ah!  So perhaps the hangup detection is busted on some line?  Did you
    experiment to see if it was a repeatable failure?  Which line did this
    happen on?

Unfortunately, I was running out the door at the time and didn't
remember to check which dialup line I was on until it was too late.
I suspect that it was T04.  I suppose we could check the console log.

Mostly I sent the message to make sure that other people thought that
hangup detection is really supposed to work on all the lines we have.
It doesn't work on the ROLM lines though, does it?
\1f
Date: 2 January 1985 14:15-EST
From: Alan Bawden <ALAN @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC
In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy <CSTACY>

    Date: 2 January 1985 09:44-EST
    From: Christopher C. Stacy <CSTACY>
        Date: 1 January 1985 20:05-EST
        From: Alan Bawden <ALAN>
            Date: 1 January 1985 15:55-EST
            From: Sydney E. Atkinson <SGA>
            hanging up a dialup line does not log you out.
        It shouldn't.  People shouldn't lose the contents of their editor
        buffers just because they tripped over the phone cord.  Hanging up
        a dialup line detaches your job tree so that you can dial in again
        and reattach to it (or gun it down if it was wedged in some way).
        Have you observed some behavior other than this?
    The job was not detached either: it was left sitting there for at
    least five minutes, and when I dialup up the same line I was already
    logged in to SGA's session.

Ah!  So perhaps the hangup detection is busted on some line?  Did you
experiment to see if it was a repeatable failure?  Which line did this
happen on?
\1f
Date: 2 January 1985 09:44-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC
In-reply-to: Msg of 1 Jan 1985 20:05-EST from Alan Bawden <ALAN>

    Date: 1 January 1985 20:05-EST
    From: Alan Bawden <ALAN>
    To:   SGA
    cc:   BUG-ITS
    In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson <SGA>

        Date: 1 January 1985 15:55-EST
        From: Sydney E. Atkinson <SGA>
        hanging up a dialup line does not log you out.

    It shouldn't.  People shouldn't lose the contents of their editor buffers
    just because they tripped over the phone cord.  Hanging up a dialup line
    detaches your job tree so that you can dial in again and reattach to it (or
    gun it down if it was wedged in some way).  Have you observed some behavior
    other than this?

The job was not detached either: it was left sitting there for at
least five minutes, and when I dialup up the same line I was already
logged in to SGA's session.
\1f
Date: 1 January 1985 20:05-EST
From: Alan Bawden <ALAN @ MIT-MC>
To: SGA @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson <SGA>

    Date: 1 January 1985 15:55-EST
    From: Sydney E. Atkinson <SGA>
    hanging up a dialup line does not log you out.

It shouldn't.  People shouldn't lose the contents of their editor buffers
just because they tripped over the phone cord.  Hanging up a dialup line
detaches your job tree so that you can dial in again and reattach to it (or
gun it down if it was wedged in some way).  Have you observed some behavior
other than this?
\1f
Date: 1 January 1985 15:55-EST
From: Sydney E. Atkinson <SGA @ MIT-MC>
To: BUG-ITS @ MIT-MC

hanging up a dialup line does not log you out.
\1f
Date: 26 December 1984 22:57-EST
From: David A. Moon <MOON @ MIT-MC>
Subject: How to take a dump of a machine that had been running?
To: KMP @ MIT-MC
cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC

    Date: Mon, 24 Dec 84 22:12 EST
    From: Kent M Pitman <KMP@MIT-MC.ARPA>

    I hit Break and got to KLDCP. Then I said SP. 
    When I tried to do DDT, it said it was in User Mode and
    that I had to do MR first. 

This is pretty dumb of KLDCP.  SP is "stop" and DDT is "start
at the start address of DDT, which is stashed in a location in
low memory somewhere."  I don't know why KLDCP can't switch from
user mode to exec mode itself.

                               I wasn't sure if that would
    destroy the useful state needed to do the dump. So I just
    hit the disk button on the machine and ran a full boot. 

Certainly MR will destroy less state than cold-booting from the
disk button!  MR (stands for master reset) probably loses at most
the contents of the accumulators, and maybe not even that.

Aside: it's a pity the designers of the pdp-11 front end for the KL10
never bothered to look at the software that runs on the pdp-10 for their
user-interface ideas.  I'm certainly glad I didn't take that job when
it was offered to me!  End of history lesson.

    Would the right thing to do have been to say MR, DDT,
    then dump it from there? 

I think so.  Actually, a better approach would have been to
continue the machine (I forget the two-letter abbreviation for
that) then raise switch zero (the switch zero on the left).  If
it's in user mode it's probably scheduling periodically, and if
it's scheduling periodically switch zero will get you to DDT
in a clean state to take a dump.

                             I'm not at all clear on what the
    various states of the machine are here... so I didn't
    know if I'd just be wasting my time trying to do something
    I really know nothing about. If I had any reason to think
    it would have worked, I'd have given it a shot. So let me
    know if it was the right thing (or what would have been)
    and next time I'll try it. -kmp

It never hurts to take a dump, in my opinion.
\1f
Received: from MIT-FRANK-SINATRA by MIT-OZ via Chaosnet; 24 Dec 84 22:10-EST
Date: Mon, 24 Dec 84 22:12 EST
From: Kent M Pitman <KMP@MIT-MC.ARPA>
Subject: How to take a dump of a machine that had been running?
To: KLH@MIT-MC.ARPA
Cc: BUG-ITS@MIT-MC.ARPA

I hit Break and got to KLDCP. Then I said SP. 
When I tried to do DDT, it said it was in User Mode and
that I had to do MR first. I wasn't sure if that would
destroy the useful state needed to do the dump. So I just
hit the disk button on the machine and ran a full boot. 
Would the right thing to do have been to say MR, DDT,
then dump it from there? I'm not at all clear on what the
various states of the machine are here... so I didn't
know if I'd just be wasting my time trying to do something
I really know nothing about. If I had any reason to think
it would have worked, I'd have given it a shot. So let me
know if it was the right thing (or what would have been)
and next time I'll try it. -kmp
\1f
Date: 24 December 1984 21:45-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: MC being down today
To: KMP @ MIT-MC
cc: BUG-ITS @ MIT-MC

Normally the best thing to do with a dead or comatose system is dump
it, so that the corpse can be examined later.
\1f
Date: 24 December 1984 16:12-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: MC being down today
To: BUG-ITS @ MIT-MC

Poor MC had 0 free pages in low core since early this morning and wasn't
doing anyone any good (wouldn't let anyone log in, etc). So I just reloaded
it, which seemed to work fine. Sorry I didn't have any idea what kind of
debugging info to offer since the machine was still running and other than
10,000 warnings about being out of free pages, it had nothing to say for
itself. If there's debugging data I could have taken from KLDCP, please let
me know and I'll get it next time if it loses this way again. -kmp
\1f
Date: Sun, 23 Dec 1984  10:59 EST
Message-ID: <PGS.12073740865.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   Peter Szolovits <PSZ@MIT-MC>
Cc:   BUG-ITS@MIT-MC
Subject: Heath 19 terminal control codes
In-reply-to: Msg of 22 Dec 1984  15:54-EST from Peter Szolovits <PSZ at MIT-MC>

This was the right place.  Either I'll answer you next time I'm on MC, or you
can look at the strings in SYS; TS3TTY > if you feel brave.  Yes, it does use
ANSI mode, but only for multiple line/char insert/delete.  So does CRTSTY.
\1f
Date: 22 December 1984 15:54-EST
From: Peter Szolovits <PSZ @ MIT-MC>
Subject:  Heath 19 terminal control codes
To: BUG-ITS @ MIT-MC
cc: PSZ @ MIT-MC

I would like to find out what the complete set of terminal commands is
that ITS sends to terminals that it thinks are H19's.  In particular, I
know that some commands from the ANSI set are used as well as the
"standard" Heath command set.  The Kermit H19 emulator doesn't support
$[nP and $[?2h, for example (though it does support $[nM and $[nL for
vertical scrolling), and I'd like to find out what such commands would
need to be added to Kermit to make it useable on MC.  Sorry if this is
the wrong mailing list.
\1f
Date: 22 December 1984 10:19-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  obscure bug in trivial feature
To: BUG-ITS @ MIT-MC
In-reply-to: Msg of 22 Dec 1984 02:52-EST from Christopher C. Stacy <CSTACY>

OK, the SYSDSK thing works now.
\1f
Date: Sat 22 Dec 84 03:58:10-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: MC busted, fixed
To: ann@MIT-XX.ARPA
cc: bug-its@MIT-MC.ARPA, JNC@MIT-XX.ARPA

        MC croaked last this evening with a busted +20V brick in
the power supply. Not wanting the machine to be down forever, I
replaced it. Can you please cause DEC to replace the busted one
(sitting on top of the processor) with a fixed one and get that
back to me?
        This may explain some of the problems MC was having recently
with it halting after repetitively flashing the lights and not
saying anything. The power supply was for the memory in the
front end; the bootstrap ROM was seeing the disk controller get
a NXM on a test transfer to 0.
                Noel
-------
\1f
Date: 22 December 1984 02:57-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

I think the SYSDSK code is probably mostly bankrupt.
I noticed it not quite working the other day, and so
there are some changes in it now, and it works a little
better.  Oh, well.
\1f
Date: 22 December 1984 02:52-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: obscure bug in trivial feature
To: BUG-ITS @ MIT-MC

SYSDSK is not called from QSOCL3 when a :MOVE happens
since the input channel's file names are not looked
at (and the output file is in another directory).
\1f
Date: 22 December 1984 02:52-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: obscure bug in trivial feature
To: BUG-ITS @ MIT-MC

SYSDSK is not called from QSOCL3 when a :MOVE happens
since the input channel's file names are not looked
at (and the output file is in another directory).
\1f
Date: 11 December 1984 19:05-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: highly secure systems
To: bug-swelling-itching-brain
cc: BUG-ITS @ MIT-MC

Whoever brought up ML didn't notice that it didn't know the time.
Of course, said culprit probably was more familiar with the current
software running there than I, so knew that there was no point.

You see, you aren't allowed to get a ddt if the system doesn't know the
time.  Running pdset becomes a bit difficult.
\1f
Date: 9 December 1984 21:10-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  7LP:
To: INFO-ITS @ MIT-MC
cc: BUG-ITS @ MIT-MC

I have installed a 7LP: device on MC and ML for using the LN01 printer on
the 7th floor to generate simple hardcopy.  Outputting to 7LP: opens a
connection to PREP (where the spooler runs) and transmits your text.  For
example :COPY DSK:ALAN;ALAN LOGIN,7LP: makes hardcopy of my init file.
Reading from 7LP:.FILE. (DIR) produces a listing of the queue on PREP, so
you can type 7LP\ 6 to DDT to see who's output is in front of yours.
\1f
Date: 8 December 1984 14:43-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Not about: RU-BLUE
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC,
    DEVON @ MIT-MC, GSB @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ
In-reply-to: Msg of 8 Dec 1984 07:38-EST from Ken Harrenstien <KLH>

    Date: 8 December 1984 07:38-EST
    From: Ken Harrenstien <KLH>
    ... the binary-compare feature to SRCCOM ...

Oh yeah, I forgot about that feature!  I used it a couple of times to
compare KS microcode load files when I made trivial changes that
theoretically changed only a single microinstruction.  I must say, however,
that I have never had very much luck applying it to midas BIN files.  There
always seems to be something you forget that causes all of the constants to
move.  I guess its worth trying again in this case.  I can only think of
two non-KS changes that have been made since I started, commenting one of
them out (a trivial fix) should cause everything to assemble into the same
places, I -think-...
\1f
Date: 8 December 1984 07:38-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: RU-BLUE
To: ALAN @ MIT-MC
cc: GSB @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC,
    DEVON @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ

Alan, would you believe that I added the binary-compare feature to
SRCCOM just so that I could quickly verify that ITS still assembled
into the same thing while I was adding all the NET/INET/TCP conditionals?

It was pretty handy, too.  Anyway, the same technique might work for
ensuring that your own changes don't affect the KA/KL version of ITS.
\1f
Date: 8 December 1984 01:18-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  BOJ device .UAI mode SIOT
To: BUG-ITS @ MIT-MC

An IOT on a BOJ channel open for input in block mode will return with the
input pointer not fully counted out when the user closes his JOB channel.
A SIOT on a BOJ channel open for input in unit ascii mode will simply hang
forever if the user closes his JOB channel before the byte count becomes 0.
The block mode behavior is what I would expect by analogy with reaching the
end of a file.
\1f
Date: 6 December 1984 14:00-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  RU-BLUE
To: GSB @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC,
    DEVON @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ
In-reply-to: Msg of 6 Dec 1984 02:34-EST from Glenn S. Burke <GSB>

    Date: 6 December 1984 02:34-EST
    From: Glenn S. Burke <GSB>
        Date: Thu, 6 Dec 84 00:02 EST
        From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
        ... I bet that ML has obsolete Internet routing tables for finding
        someone to ask about the gateway to net 128.6.xx.aa.  ML is also
        probably unable to reach random other hosts.  I'll fix this
        eventually.

    Seems to me that we should make the most of ml's existence while it
    still exists;  it does arpa/chaos fairly well, after all.  It has been
    50 days since it's been booted, and i think it has had one parity stop
    and one random retryable disk error stop in that time.  I forget how
    long it had been up before this uptime binge, but i think that too was
    a record.

CStacy's observation about routing tables is correct.  ML is running an
ancient version of ITS without Moon's fix to that code.  If we really want
to make the most of ML, we should assemble a more modern version for it.
Of course I have made a great number of edits to the source of ITS in the
last few months, many having to do with the KA/KL conditionalizations, so
there is no guarantee that an ITS assembled from the current sources will
actually represent any improvements.  (I have tried to make sure the
binaries for the KA and KL didn't change, but...)
\1f
Date: 6 December 1984 02:34-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: RU-BLUE
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, DEVON @ MIT-MC,
    MARTY%MIT-OZ @ SCRC-STONY-BROOK, Bug-MAIL%MIT-OZ @ SCRC-STONY-BROOK

    Date: Thu, 6 Dec 84 00:02 EST
    From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
        BUG-MAIL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA
    In-reply-to: <MARTY.12069151570.BABYL@MIT-OZ>

        Date: 5 Dec 1984  22:49 EST (Wed)
        From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
        I removed ML from the places that mail can be forwarded by.
        (DOMAINS.TXT).  I know that RU-BLUE is up and often send mail there.

    MC can also reach RU-BLUE fine.  ML is running the same mail software and has
    the same host tables.  I bet that ML has obsolete Internet routing tables for
    finding someone to ask about the gateway to net 128.6.xx.aa.  ML is also
    probably unable to reach random other hosts.   I'll fix this eventually.

Seems to me that we should make the most of ml's existence while it
still exists;  it does arpa/chaos fairly well, after all.  It has been
50 days since it's been booted, and i think it has had one parity stop
and one random retryable disk error stop in that time.  I forget how
long it had been up before this uptime binge, but i think that too was
a record.
\1f
Date: Thu, 6 Dec 84 00:02 EST
From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
Subject: RU-BLUE
To: Martin David Connor <MARTY%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Cc: Bug-MAIL%MIT-OZ@SCRC-STONY-BROOK.ARPA, BUG-ITS@MIT-MC.ARPA,
    BUG-MAIL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA
In-reply-to: <MARTY.12069151570.BABYL@MIT-OZ>

    Date: 5 Dec 1984  22:49 EST (Wed)
    From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
    I removed ML from the places that mail can be forwarded by.
    (DOMAINS.TXT).  I know that RU-BLUE is up and often send mail there.

MC can also reach RU-BLUE fine.  ML is running the same mail software and has
the same host tables.  I bet that ML has obsolete Internet routing tables for
finding someone to ask about the gateway to net 128.6.xx.aa.  ML is also
probably unable to reach random other hosts.   I'll fix this eventually.

\1f
Date: Mon 26 Nov 84 20:22:20-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: MC hardware
To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
cc: FINN@MIT-XX.ARPA, TY@MIT-XX.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Sun 25 Nov 84 11:51:00-EST

        I guess I'd consider this a non-optimal move. Since we have a
modest maount of memory on the machine now, I don't think it such a
big lose to switch off 25% of the memory until DEC can look at it.
There is some possibility that they aren't confused when they say they
are hot.
                Noel
-------
\1f
Date: 25 November 1984 11:51-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: MC hardware
To: BUG-ITS @ MIT-MC
cc: FINN @ MIT-XX, TY @ MIT-XX

On MC: memory boxes B and C are only online because their
override switches are on.   They are too hot, I think.
\1f
Date: Fri, 23 Nov 84 20:46 EST
From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
Subject: NITS?
To: Alan Bawden <ALAN@MIT-MC.ARPA>
Cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: The message of 23 Nov 84 13:17-EST from Alan Bawden <ALAN at MIT-MC>

Someone turned the card over accidently I guess.
\1f
Date: 23 November 1984 13:17-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  NITS?
To: BUG-ITS @ MIT-MC

The Very Small Bulletin Board on MC told me to load NITS, but there isn't
any such file.  I turned the card around to say just ITS which does exist.
I hope that this only means that thhe card was wrong and not that someone
accidentally deleted the system we are supposed to be running.
\1f
Date: 16 November 1984 03:09-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  ROLM lines
To: BUG-ITS @ MIT-MC

I just edited the TTYTYP file to remove the %TYMDM bits from all of the
ROLM lines.  Experiment reveals that MC never seems to get told when such a
line is reconnected to a new terminal, thus setting this bit causes MC to
remember old, sometimes incorrect, terminal type information.  Removing the
%TYMDM bits should cause ITS to reset the terminal type information
whenever the tty becomes free.  This is better than the current situation,
where a user can be seriously confused, but since the ROLM -must- be able
to do this correctly, someone should really be looking into fixing it.
\1f
Date: 6 November 1984 15:48-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  ITS Uptime Server?
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of Tue 6 Nov 84 11:36-EST from Martin David Connor <MARTY%MIT-OZ at MIT-MC.ARPA>

    Date: Tue 6 Nov 84 11:36-EST
    From: Martin David Connor <MARTY at OZ>
    Could someone implement an UPTIME chaos server for ITS?

Done.
\1f
Date: Tue 6 Nov 84 11:36-EST
From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
Subject: ITS Uptime Server?
To: BUG-ITS@MIT-MC


Could someone implement an UPTIME chaos server for ITS?

\1f
Date: 4 November 1984 14:42-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  I just checked and he isn't blue...
To: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC

Every once in a great while when I log in I discover that %TOMOR is not set
in my TTYOPT word.  Since my LOGIN does nothing to change the default
setting of more processing it must be the case that normally ITS or DDT (or
PWORD?) turns it on.  Well sometimes, given a blue Moon or something, it
must fail to work...
\1f
Date: 30 October 1984 13:12-EST
From: Alan Bawden <ALAN @ MIT-MC>
To: STORY @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 30 Oct 1984 11:46-EST from Kenneth Byrd Story <STORY>

    Date: 30 October 1984 11:46-EST
    From: Kenneth Byrd Story <STORY>
    To:   BUG-DDT
    I keep getting logged-out automatically by mc; what's the problem?

Well, as far as I know nothing on ITS ever causes you to be "logged-out
automatically".  What exactly were the symptoms?  Did you get a message
like: "Top level interrupt, tree detached"?  Did you just get "MC ITS 1382
Console XX Free. HH:MM:SS"?  When you reconnected did DDT offer to reattach
you to a detached tree or tell you that you had dead detached trees?  How
were you reaching MC?  (ROLM? Dialup? Chaosnet?)
\1f
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 116836; Sun 28-Oct-84 17:38:27-EST
Date: Sun, 28 Oct 84 17:38 EST
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Getting Detached from MC
To: "Thomas A. Russ" <TAR@MIT-MC.ARPA>
cc: BUG-ITS@MIT-MC.ARPA, bede@MIT-XX.ARPA
In-Reply-To: The message of 12 Oct 84 13:42-EDT from Thomas A. Russ <TAR at MIT-MC>
Message-ID: <841028173837.9.MOON@EUPHRATES.SCRC.Symbolics>

    Date: 12 October 1984 13:42-EDT
    From: Thomas A. Russ <TAR @ MIT-MC>

    I seem to be getting detached from MC regularly when I dial in over
    the ROLM switch from my office.  I wonder if this could be some problem
    related to the ROLM system.  I have DTI # 4303 connected to wall jack # 333
    in room 369.

    I don't know what line on MC is being called.  The symptom is that my job
    on MC gets a top level interrupt and is detached.  The connection to MC
    is left intact.

    Even as I write this message, it happens again.

There used to be a bug, which may still be around, where a disconnected dialup
line got the bogus message "top level interrupt job detached" printed on it.
The job was detached because the dialup line was disconnected, not because it
got a top-level interrupt, but the logout/detach-message printer didn't know
that.  Of course if the dialup line was really disconnected, no one sees the
erroneous message (except people spying on the dialup line, which is how this
was discovered originally).

I also believe that the Rolm switch has a bug where when you tell it to disconnect
it drops "carrier detect" several seconds before it stops passing bits through,
so you see some garbage bits.

What all this suggests is that maybe you are getting detached because the Rolm
switch is saying it's hanging up, or MC or its front-end pdp-11  incorrectly thinks
the Rolm is saying it's hanging up.
\1f
Date: 12 October 1984 15:26-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Getting Detached from MC
To: TAR @ MIT-MC
cc: BUG-ITS @ MIT-MC, bede @ MIT-XX
In-reply-to: Msg of 12 Oct 1984 13:42-EDT from Thomas A. Russ <TAR>

    Date: 12 October 1984 13:42-EDT
    From: Thomas A. Russ <TAR>
    ...  The symptom is that my job on MC gets a top level interrupt and is
    detached....

Well, it would be nice to know what interrupt it is that you are getting.
If it happens sometime when you don't need to reattach the tree, you might
leave it detached so that an ITS hacker can take a look at it.
\1f
Date: 12 October 1984 13:42-EDT
From: Thomas A. Russ <TAR @ MIT-MC>
Subject: Getting Detached from MC
To: BUG-ITS @ MIT-MC, bede @ MIT-XX
cc: TAR @ MIT-MC

I seem to be getting detached from MC regularly when I dial in over
the ROLM switch from my office.  I wonder if this could be some problem
related to the ROLM system.  I have DTI # 4303 connected to wall jack # 333
in room 369.

I don't know what line on MC is being called.  The symptom is that my job
on MC gets a top level interrupt and is detached.  The connection to MC
is left intact.

Even as I write this message, it happens again.

        Tom.
\1f
Date: 11 October 1984 15:30-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Fair warning...
To: BUG-ITS @ MIT-MC

Until further notice everybody should be carefull about editing the sources
for ITS itself, as I am in the process of conditionalizing it for the KS
processor.
\1f
Date: Sun 7 Oct 84 16:20-EDT
From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
Subject: 28 page host table too big?
To: bug-its@MIT-MC
CC: BUG-TCP@MIT-MC, INFO-HOSTS@MIT-MC


I fetched the latest NIC host table and installed it on MC,
and suddenly I couldn't get a DDT from OZ.  I backed out, renaming it
to SYSBIN;HOSTS3 TOOBG?, and was then able to SUPDUP in and get a DDT without
it barfing and saying there was a PWORD bug. I bet the bug is it couldn't
map the host table.

Anyway, someone should look at PWORD.

\1f
Date: 2 October 1984 22:22-EDT
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: Don't try this at home kids...
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

I was logged in from home as Alan did this, and got to see that my most-hated
ITS bug has been fixed:  when the system comes up from a crash, it no longer
resets the baud rate on dialed-up lines.  Thanks to whoever fixed this.

PS. to Alan:  Not coincidentally, I was doing :USET UPC when it crashed.
\1f
Date: 2 October 1984 21:54-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Don't try this at home kids...
To: BUG-ITS @ MIT-MC

Setting %PSPUB in your PC flags causes all kinds of havoc to break out on
MC.  The first time I did it tonight the system console printed:

PAGE FAIL ERROR #1,  PC = 772740,,301  JOB # 34, USR: ALAN   J     , PFW = 543000,,301

When the job returned to DDT, DDT claimed it was getting a PURINS
interrupt (which I didn't even think could happen on KLs!).  I guess you
can tell from this that I was actually setting all the flags...

Since I couldn't see the system console from my office where I was doing
this, I did it several times.  Eventually I seem to have hung the
microcode.  A few controlled experiments later I crashed MC again with an
error that contained the string "BAD PAGE FAIL WORD" (the decwriter was
dropping so many characters thats about all I could see, I wish that sucker
was more reliable).
\1f
Date: 30 September 1984 21:10-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: HOSTS3
To: CSTACY @ MIT-MC
cc: BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, KLH @ SRI-NIC,
    MOON @ SCRC-TENEX

    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.
\1f
Date: 30 September 1984 02:01-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Not critical
To: BUG-ITS @ MIT-MC

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.
\1f
Date: 30 September 1984 01:30-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

    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.
\1f
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 86001; Fri 28-Sep-84 15:03:14-EDT
Date: Fri, 28 Sep 84 15:03 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: M-X Copy File 
To: "Robert W. Kerns" <RWK@SCRC-RIVERSIDE.ARPA>
cc: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>, BUG-FILE@MIT-MC.ARPA,
    BUG-ITS@MIT-MC.ARPA, BUG-LISPM@MIT-MC.ARPA
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.
\1f
Received: from SCRC-HUDSON by SCRC-YUKON via CHAOS with CHAOS-MAIL id 63942; Fri 28-Sep-84 02:32:03-EDT
Date: Fri, 28 Sep 84 02:32 EDT
From: "Robert W. Kerns" <RWK@SCRC-RIVERSIDE.ARPA>
Subject: M-X Copy File 
To: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
cc: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>, BUG-FILE@MIT-MC.ARPA,
    BUG-ITS@MIT-MC.ARPA, BUG-LISPM@MIT-MC.ARPA
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?
\1f
Date: 28 September 1984 19:13-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ 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.
\1f
Date: 26 September 1984 01:22-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: FOURTH is back online on MC
To: TY @ MIT-XX, FINN @ MIT-XX
cc: BUG-ITS @ MIT-MC, KMP @ MIT-MC, ALAN @ MIT-MC, PSZ @ MIT-MC,
    MEYER @ MIT-MC, GSB @ MIT-MC

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.
\1f
Date: 26 September 1984 01:01-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Sender: CSTAC0 @ MIT-MC
Subject:  x3-5891
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
In-reply-to: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden <ALAN>

    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
\1f
Date: 26 September 1984 01:01-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Sender: CSTAC0 @ MIT-MC
Subject:  x3-5891
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
In-reply-to: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden <ALAN>

    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
\1f
Date: 26 September 1984 00:54-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  x3-5891
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
In-reply-to: Msg of 26 Sep 1984 00:43-EDT from Christopher C. Stacy <CSTACY>

    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...
\1f
Date: 26 September 1984 00:43-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  x3-5891
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
In-reply-to: Msg of 26 Sep 1984 00:00-EDT from Alan Bawden <ALAN>


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.
\1f
Date: 26 September 1984 00:00-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  x3-5891
To: BUG-PWORD @ MIT-MC
cc: BUG-ITS @ MIT-MC

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...
\1f
Date: 25 September 1984 17:43-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  HOSTS3
To: INFO-HOSTS @ MIT-MC
cc: BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, KLH @ SRI-NIC,
    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!
\1f
Date: 25 September 1984 15:14-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: MATH-HUB
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC

    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.
\1f
Date: 24 September 1984 19:35-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: MATH-HUB
To: BUG-ITS @ MIT-MC
cc: BUG-MINITS @ 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.
\1f
Date: 24 September 1984 13:07-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: BUG-TCP @ MIT-MC, INFO-HOSTS @ MIT-MC

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.
\1f
Date: 24 September 1984 12:18-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 22 Sep 1984 23:32-EDT from Devon S. McCullough <DEVON>

    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?
\1f
Date: 22 September 1984 23:32-EDT
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC

What is %TDSTY and %TDUNF and whatever other innovations have hit the scene?
Are they documented?
\1f
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 83844; Sat 22-Sep-84 14:47:57-EDT
Date: Sat, 22 Sep 84 14:46 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: M-X Copy File 
To: "Bernard S. Greenberg" <BSG@SCRC-RIVERSIDE.ARPA>
cc: CSTACY@MIT-MC.ARPA, BUG-FILE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
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.
\1f
Date: 22 September 1984 09:52-EDT
From: David A. Moon <MOON @ MIT-MC>
Subject:  Moon's sabotage of ITS
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

    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.
\1f
Received: from SCRC-CONCORD by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 83372; Fri 21-Sep-84 08:34:39-EDT
Date: Fri, 21 Sep 84 08:35 EDT
From: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Subject: M-X Copy File 
To: Moon@SCRC-STONY-BROOK.ARPA, CSTACY@MIT-MC.ARPA, BUG-FILE@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
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?
\1f
Date: Mon, 17 Sep 1984  09:35 EDT
Message-ID: <PGS.12048286670.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   "Leigh L. Klotz" <KLOTZ@MIT-MC>
Cc:   ALAN@MIT-MC, BUG-ITS@MIT-MC, CSTACY@MIT-MC, FEATURE-ENTENNMANS@MIT-MC,
      ITS-LOVERS@MIT-MC, Moon%SCRC-RIVERSIDE@MIT-MC.ARPA
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>

    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.
\1f
Date: 17 September 1984 00:11-EDT
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject:  How to copy files on ITS without trashing them
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, FEATURE-ENTENNMANS @ MIT-MC,
    ITS-LOVERS @ MIT-MC, Moon @ SCRC-RIVERSIDE
In-reply-to: Msg of 16 Sep 1984 20:16-EDT from Alan Bawden <ALAN>

I always move files with TECO myself, <>'ing over the filenames.
\1f
Date: 16 September 1984 20:16-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  How to copy files on ITS without trashing them
To: CSTACY @ MIT-MC, Moon @ SCRC-RIVERSIDE
cc: BUG-ITS @ MIT-MC, FEATURE-ENTENNMANS @ MIT-MC, ITS-LOVERS @ MIT-MC
In-reply-to: Msg of Sun 16 Sep 84 16:55 EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>

    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 \e\e\10 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.
\1f
Date: 16 September 1984 18:56-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-LISPM @ MIT-MC
In-reply-to: Msg of 16 Sep 1984 16:32-EDT from Alan Bawden <ALAN>

Sigh....so much for trusting ZWEI...
\1f
Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 61136; Sun 16-Sep-84 17:53:24-EDT
Date: Sun, 16 Sep 84 17:50 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Source for :TIME
To: Alan Bawden <ALAN@MIT-MC.ARPA>
cc: BUG-ITS@MIT-MC.ARPA
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 35, 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.
\1f
Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 61133; Sun 16-Sep-84 17:33:18-EDT
Date: Sun, 16 Sep 84 17:30 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Top level interrupt
To: Alan Bawden <ALAN@MIT-MC.ARPA>, CSTACY@MIT-MC.ARPA, BEN@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA
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?
\1f
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 81783; Sun 16-Sep-84 16:51:40-EDT
Date: Sun, 16 Sep 84 16:55 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: How to copy files on ITS without trashing them
To: CSTACY@MIT-MC.ARPA
cc: Alan Bawden <ALAN@MIT-MC.ARPA>, BUG-LISPM@MIT-MC.ARPA,
    BUG-ITS@MIT-MC.ARPA
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!)
\1f
Date: 16 September 1984 16:32-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-LISPM @ MIT-MC, BUG-ITS @ MIT-MC

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.
\1f
Date: 15 September 1984 17:15-EDT
From: Ray Hirschfeld <RAY @ MIT-MC>
Subject:  ROLM lines
To: BUG-ITS @ MIT-MC

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.
\1f
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 81650; Sat 15-Sep-84 12:03:45-EDT
Date: Saturday, 15 September 1984, 12:06-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: M-X Copy File 
To: Christopher C. Stacy <CSTACY at MIT-MC>, BUG-FILE at MIT-MC
cc: BUG-ITS at MIT-MC, BUG-LISPM at MIT-MC
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?
\1f
Date: 14 September 1984 21:03-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC, INFO-HOSTS @ MIT-MC

The TCP; directory on MC is now called "SYSNET;".
\1f
Date: 14 September 1984 21:00-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: M-X Copy File 
To: BUG-FILE @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-LISPM @ 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.
\1f
Date: 14 September 1984 16:58-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

T-300 unit 3 was going offline spontanesouly, causing the
system to hang on some operations.  It should be fixed
Monday or Tuesday.
\1f
Date: 13 September 1984 21:55-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Top level interrupt
To: CSTACY @ MIT-MC
cc: BEN @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 13 Sep 1984 19:44-EDT from Christopher C. Stacy <CSTACY>

    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"...
\1f
Date: 13 September 1984 20:43-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: supdup
To: DCP @ MIT-MC
cc: BUG-ITS @ MIT-MC, dab @ MIT-BORAX

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."
\1f
Date: 13 September 1984 20:32-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: supdup
To: dab @ MIT-BORAX
cc: BUG-ITS @ MIT-MC

    Received: by mit-borax.ARPA (4.12/4.7)
        id AA03676; Thu, 13 Sep 84 16:15:39 edt
    From: dab@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.
\1f
Date: 13 September 1984 19:44-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BEN @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 13 Sep 1984 14:46-EDT from Benjamin Kuipers <BEN>

    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.
\1f
Received: by mit-borax.ARPA (4.12/4.7)
        id AA03676; Thu, 13 Sep 84 16:15:39 edt
From: dab@mit-borax (David A. Bridgham)
Message-Id: <8409132015.AA03676@mit-borax.ARPA>
Date: 13 Sep 1984 1615-EDT (Thursday)
To: bug-its@mc
Subject: supdup

        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.
                                                Dave
\1f
Date: 13 September 1984 14:46-EDT
From: Benjamin Kuipers <BEN @ MIT-MC>
To: BUG-ITS @ MIT-MC

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
\1f
Date: 12 September 1984 17:42-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  archive
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, CENT @ MIT-MC, CSTACY @ MIT-MC
In-reply-to: Msg of 11 Sep 1984 13:12-EDT from Alan Bawden <ALAN>

    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.
\1f
Date: 12 September 1984 08:57-EDT
From: Bill Long <WJL @ MIT-MC>
To: BUG-ITS @ MIT-MC

When the Rolm switch tries 4991 to get MC, it times out.
\1f
Date: 11 September 1984 22:40-EDT
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject:  20th Anniversary of 36 Bits
To: CENT @ MIT-MC
cc: BUG-ITS @ MIT-MC, CC.Clive @ UTEXAS-20
In-reply-to: Msg of 11 Sep 1984 04:24-EDT from Pandora B. Berman <CENT>

Don't forget Don Eastlake, DEE@CCA, I think.
\1f
Date: 11 September 1984 13:12-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  archive
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, CENT @ MIT-MC
In-reply-to: Msg of 11 Sep 1984 09:30-EDT from Christopher C. Stacy <CSTACY>

    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...
\1f
Date: 11 September 1984 09:30-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  archive
To: CENT @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 10 Sep 1984 23:50-EDT from Pandora B. Berman <CENT>

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..
\1f
Date: 11 September 1984 05:11-EDT
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: Recent spate of crashes
To: BUG-NAME @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC

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?
\1f
Date: 11 September 1984 04:24-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: Re: 20th Anniversary of 36 Bits
To: CC.Clive @ UTEXAS-20
cc: BUG-ITS @ MIT-MC

    Date: Tue 11 Sep 84 02:44:10-CDT
    From: Clive Dawson <CC.Clive@UTEXAS-20.ARPA>
    Subject: Re: 20th Anniversary of 36 Bits
    To: CENT@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@MC) --
built the Knight TV system (was attached to the AI KA-10) for his undergrad
thesis -- and Ken Harrenstein (KLH@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.
\1f
Date: 10 September 1984 23:50-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: archive
To: BUG-ITS @ MIT-MC

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. .
\1f
Date: 10 September 1984 23:16-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: 20th Anniversary of 36 Bits
To: CC.Clive @ UTEXAS-20
cc: BUG-ITS @ MIT-MC

don't forget ITS, Greenblatt (RG@OZ, currently at LMI in cambridge),
Holloway (H@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).
\1f
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.

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.
\1f
Date: 6 September 1984 02:21-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Source for :TIME
To: MOON @ MIT-MC
cc: BUG-ITS @ 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 35, 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...
\1f
Date: 5 September 1984 23:56-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

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.
\1f
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2640626229863307@MIT-MULTICS.ARPA>; 04 Sep 1984 15:17:09 edt
Date:        04 Sep 84 15:00 +0200
From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          BUG-ITS@MIT-MC
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



\1f
Date: 3 September 1984 02:32-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: we hear you
To: Bjorn_Danielsson_QZ%QZCOM.MAILNET @ MIT-MULTICS
cc: BUG-ITS @ MIT-MC

    Date:        27 Aug 84 20:48 +0200
    From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
    To:          GSB@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@MC, so we will all see them.
\1f
Date: 24 August 1984 21:29-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

SALV and exec DDT are write locked.
\1f
Date: 20 August 1984 16:51-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  breaking ITS net connections
To: mclure @ SRI-PRISM
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, SASW @ MIT-MC
In-reply-to: Msg of Sun Aug 19 11:54:15 1984 from mclure at sri-prism

From an ether tip typing the esacpe twice sends it through; I use the
feature from the h19's in he basement of mjh all the time.  But if you find
that objectionable, why not change the escape character for your telnet to
be something else?

david

PS: Bug-its: on the other hand, since everybody has infinite free time, and
    isn't working on things like theses, what's wrong with .e.g. \e\e2u
    logging out and detaching non-hardwired lines?
\1f
Date: 19 August 1984 16:07-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  breaking ITS net connections
To: mclure @ SRI-PRISM
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, SASW @ MIT-MC
In-reply-to: Msg of Sun Aug 19 11:54:15 1984 from mclure at sri-prism

    Date: Sun Aug 19 11:54:15 1984
    From: mclure at sri-prism
    That's just the point. If I am using the Stanford ethernet to
    access score, there are certain instances where my escape will
    be robbed by a superior program and unavailable to telnet....

Have you complained to anyone about this misfeature?  Seems like your real
problem is that you are forced to use a broken program to make your first
hop over the network.

I suppose we could put a command in DDT that guns its own telnet server...
Always seems a shame to have to do things like this to compensate for other
people's bugs.
\1f
Date: 19 August 1984 15:44-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: Re:  breaking ITS net connections
To: mclure @ SRI-PRISM
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC, SASW @ MIT-MC

    Date: Sun Aug 19 11:54:15 1984
    From: mclure@sri-prism

    That's just the point. If I am using the Stanford ethernet to
    access score, there are certain instances where my escape will
    be robbed by a superior program and unavailable to telnet. So
    I am unable to close the connection because I can't escape back
    to my telnet (without escaping to the ethernet tip, or whatever
    other medium happens to be in the way).

Your user program is seriously misdesigned.

    My question still stands. Is there a way in ITS DDT to break
    a connection manually? If not, I think one should be added
    as everyone else has one and it has shown itself to be desirable.

No, and NO!!!  Alan's message shows that this is considered a win
(by the ITS community, at least).  If your user program doesn't
have a command to forcibly disconnect you, I suggest you find
another program, or stop using ITS.  How would you get out if you
started running a program that has super-image-input on so you
couldn't even type c-Z (er, CALL).
\1f
Received: by sri-prism.ARPA (4.12/4.16)
        id AA06644; Sun, 19 Aug 84 11:56:45 pdt
Message-Id: <8408191856.AA06644@sri-prism.ARPA>
Date: Sun Aug 19 11:54:15 1984
From: mclure@sri-prism
To: CSTACY@MIT-MC
Cc: bug-its@mit-mc, sasw@mit-mc
Subject: Re:  breaking ITS net connections

That's just the point. If I am using the Stanford ethernet to
access score, there are certain instances where my escape will
be robbed by a superior program and unavailable to telnet. So
I am unable to close the connection because I can't escape back
to my telnet (without escaping to the ethernet tip, or whatever
other medium happens to be in the way).

My question still stands. Is there a way in ITS DDT to break
a connection manually? If not, I think one should be added
as everyone else has one and it has shown itself to be desirable.

        Stuart
\1f
Date: 19 August 1984 14:52-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  breaking ITS net connections
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, SASW @ MIT-MC, mclure @ SRI-PRISM

    Date: 19 August 1984 14:33-EDT
    From: Christopher C. Stacy <CSTACY>
    After logging out of ITS, why not close the connection from your end,
    perhaps by killing your TELNET program or issuing a "close" command
    to it?  This will not leave any ITS job hanging.

Perhaps he in confused by the fact that ITS doesn't close the connection
IMMEDIATELY after you log out?  If you wait a few minutes after you
logout, your TELNET server will wake up and break the connection.  We
regard this as a feature; it gives you a chance to re-use the connection by
typing ^Z (er, CALL).  Its like having a hardwired line, except it times
out eventually.  

The same philosophy applies to the way ITS handles logging out from a
dialup.  Having this feature from dialups is actually even more of a win.
It lets someone else log into the machine without having to re-dial the
phone.  The whole things seems like such a simple courtesy that I'm always
surprised that the 20X wizards around here don't adopt the feature.
\1f
Date: 19 August 1984 14:33-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  breaking ITS net connections
To: mclure @ SRI-PRISM
cc: BUG-ITS @ MIT-MC, SASW @ MIT-MC
In-reply-to: Msg of Sun 19 Aug 84 10:57:35-PDT from Stuart McLure Cracraft <G.MCLURE at SU-SCORE.ARPA>

After logging out of ITS, why not close the connection from your end,
perhaps by killing your TELNET program or issuing a "close" command
to it?  This will not leave any ITS job hanging.
\1f
Date: Sun 19 Aug 84 10:57:35-PDT
From: Stuart McLure Cracraft <G.MCLURE@SU-SCORE.ARPA>
Subject: breaking ITS net connections
To: bug-its@MIT-MC.ARPA, sasw@MIT-MC.ARPA
Reply-To: mclure@sri-prism

There seems to be no good way to break a net connection on the ITS
machines. Perhaps there is one, but it is not obvious. TOPS-20 Arpanet
machines usually break the connection upon logout. WAITS allows you
to break it with the 'QUIT' command. Unix lets you break a net
connection at the 'login:' prompt by typing ^D.

Does ITS have an equivalent? I have left many jobs hanging/detached
on MIT machines over the years whenever the telnet/modem/network
configuration I am reaching it through does not allow an escape
character of its own.

Thanks.

        Stuart
-------
\1f
Date: 18 August 1984 00:20-EDT
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

looks like the source to sys1;ts time is lost.
\1f
Date: 13 August 1984 22:00-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: someone has this KA, you see...
To: BUG-ITS @ MIT-MC

[damned if i know why they asked me.]
----------
Date:        13 Aug 84 15:38 +0200
From:        Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          "Pandora B. Berman" <CENT@MIT-MC>
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
\1f
Date: 11 August 1984 19:44-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  mc:crash;tcp .value
To: MOON @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, KLH @ MIT-MC
In-reply-to: Msg of 11 Aug 1984 18:54-EDT from David A. Moon <MOON>

    Date: 11 August 1984 18:54-EDT
    From: David A. Moon <MOON>
        Date: 1 August 1984 18:12-EDT
        From: Alan Bawden <ALAN @ MIT-MC>
        Dunno who maintains the TCP server exactly, ...
    "The" TCP server?  Guesswork reveals that it's the FTP/SMTP server...

When I said "TCP server", I was talking about the Chaosnet TCP server.  You
know, the thing that gets loaded from DEVICE;CHAOS TCP.  I didn't think too
hard about how ambiguous that would sound in a bug note CC'd to BUG-TCP.

Now a good question is how did I manage to mistake an FTP server for that?
(Perhaps I need to think again about how the MOVE instruction works.)
\1f
Date: 11 August 1984 18:54-EDT
From: David A. Moon <MOON @ MIT-MC>
Subject:  mc:crash;tcp .value
To: ALAN @ MIT-MC, KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC

    Date: 1 August 1984 18:12-EDT
    From: Alan Bawden <ALAN @ MIT-MC>
    To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC

    Dunno who maintains the TCP server exactly, but I found a couple
    that had .VALUEd just now.  I dumped one of them into CRASH;TCP .VALUE
    Seems to me that I'm seeing more of these guys .VALUEing recently
    so perhaps someone should take a look.

"The" TCP server?  Guesswork reveals that it's the FTP/SMTP server
found in SYSBIN;FTPS BIN and it got an error from a FINISH system call
in RETR05 called from the LIST command (look at location AUTPSY).
I guess it's not robust to the user killing the connection while it's
in the middle of listing a directory.

I fixed this in the source but cannot reassemble FTPS because KLH's
macros, which it uses, have been changed incompatibly.  I found the
file ksc;?out >, which purports to explain how to convert, but I can
find no indication of how to convert OUTOPN in there so I'll leave
this for KLH to fix or advise about.  Presumably plenty of other
programs are broken the same way.

I didn't delete the CRASH file in case anyone else wants to look at it.
\1f
Date: 9 August 1984 11:02-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: rebooted hubs
To: ALAN @ MIT-MC
cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC, GUMBY @ MIT-MC, bug-minits @ MIT-OZ,
    DMS @ MIT-OZ

    Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Aug 84 19:11-EDT
    Date: 8 August 1984 19:04-EDT
    From: Alan Bawden <ALAN @ MIT-MC>
    In-reply-to: Msg of 8 Aug 1984 18:01-EDT from David C. Plummer <DCP>

        Date: 8 August 1984 18:01-EDT
        From: David C. Plummer <DCP>
        I think there are (undocumented) frobs that can follow the 034 of
        ITP to say this.  If I can find it in the source in the next 4
        minutes, I'll let you know... 

    Undocumented?  fooey!  Do :INFO ITS TTY SMART ESCAPE and you will find what
    you are looking for.
It's not documented in the SUPDUP RFC (though I didn't look very
hard, but I remember that it isn't documented there). 
\1f
Date: 8 August 1984 19:04-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  rebooted hubs
To: DCP @ MIT-MC
cc: BUG-ITS @ MIT-MC, GUMBY @ MIT-MC, bug-minits @ MIT-OZ, DMS @ MIT-OZ
In-reply-to: Msg of 8 Aug 1984 18:01-EDT from David C. Plummer <DCP>

    Date: 8 August 1984 18:01-EDT
    From: David C. Plummer <DCP>
    I think there are (undocumented) frobs that can follow the 034 of
    ITP to say this.  If I can find it in the source in the next 4
    minutes, I'll let you know... 

Undocumented?  fooey!  Do :INFO ITS TTY SMART ESCAPE and you will find what
you are looking for.
\1f
Date: 8 August 1984 18:01-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: rebooted hubs
To: GUMBY @ MIT-MC
cc: BUG-ITS @ MIT-MC, DMS @ MIT-OZ, bug-minits @ MIT-OZ

    Date: 8 August 1984 17:14-EDT
    From: David Vinayak Wallace <GUMBY @ MIT-MC>
    In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel <DMS%MIT-OZ at MIT-MC.ARPA>

    It would gubbish your screen unless there were a way to tell ITS that
    typeout had occurred.

I think there are (undocumented) frobs that can follow the 034 of
ITP to say this.  If I can find it in the source in the next 4
minutes, I'll let you know... 

Here it is... gotta run...

TYBCTL: CAIN A,^A       ;^\^A => ALLOCATE OUTPUT CHARS.
         JRST TYBA
        CAIN A,^Z       ;^\^Z => ZERO ALLOCATION
         JRST TYBZ
        CAIN A,^I       ;^\^I => INFINITY ALLOCATION
         JRST TYBI
        CAIN A,^R       ;^\^R => RESTART OUTPUT AT M.P. LEVEL.
         JRST TYBR
        CAIN A,^P       ;^\^P => SET CURSOR POSITION AND RESTART OUTPUT AT M.P. LEVEL.
         JRST TYBP
        CAIN A,^\       ;^\^\ => INPUT A ^\.
         JRST TYBRET
        CAIN A,^C       ;^\^C => SCREEN HAS BEEN SURREPTITIOUSLY CHANGED
         PUSHJ P,TYBC
;RETURN TO NORMAL ^\ STATUS BUT DON'T PASS ANY INPUT UP TO NORMAL INPUT LEVEL.
\1f
Date: 8 August 1984 17:58-EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: rebooted hubs
To: GUMBY @ MIT-MC
cc: BUG-ITS @ MIT-MC, DMS @ MIT-OZ, bug-minits @ MIT-OZ

    Date: 8 August 1984 17:14-EDT
    From: David Vinayak Wallace <GUMBY @ MIT-MC>
    In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel <DMS%MIT-OZ at MIT-MC.ARPA>

    It would gubbish your screen unless there were a way to tell ITS that
    typeout had occurred.

I think there are (undocumented) frobs that can follow the 034 of
ITP to say this.  If I can find it in the source in the next 4
minutes, I'll let you know... 
\1f
Date: 8 August 1984 17:14-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  rebooted hubs
To: DMS @ MIT-OZ
cc: BUG-ITS @ MIT-MC, bug-minits @ MIT-OZ
In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel <DMS%MIT-OZ at MIT-MC.ARPA>

It would gubbish your screen unless there were a way to tell ITS that
typeout had occurred.
\1f
Date: 7 August 1984 19:02-EDT
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject:  chuname broken
To: MLY @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 5 Aug 1984 22:31-EDT from Richard Mlynarik <MLY>

Are you sure that you weren't already logged in (or detached) as
MLY when you tried doing :CHUNAME MLY?  That's what's usually happening
when you get the ? response.
\1f
Date: 5 August 1984 23:42-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  chuname broken
To: MLY @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
In-reply-to: Msg of 5 Aug 1984 22:31-EDT from Richard Mlynarik <MLY>

    Date: 5 August 1984 22:31-EDT
    From: Richard Mlynarik <MLY>
    Sender: MLY0
    logged in as anything, and typing ":chuname mly" at ddt
    gets me the right "--massacre and reset--" but confirming
    with  a space just gets me a "?" and my uname is still the same.

This bug report seems to be saying that you were unable to get CHUNAME to
work under any circumstances.  Funny, because I can't seem to get it to
fail under any circumstances.  I notice that you sent this bug report
logged in as "MLY0", perhaps you can tell me what other MLY's were logged
in at the time, what you were logged in as, and what you tried to CHUNAME
to.
\1f
Date: 5 August 1984 23:10-EDT
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC

emacs got a .val 0; 35572>>move 1,3 1/17450 3/24
when I tried to find a file on HS:
\1f
Date: 5 August 1984 22:31-EDT
From: Richard Mlynarik <MLY @ MIT-MC>
Sender: MLY0 @ MIT-MC
Subject: chuname broken
To: BUG-ITS @ MIT-MC

logged in as anything, and typing ":chuname mly" at ddt
gets me the right "--massacre and reset--" but confirming
with  a space just gets me a "?" and my uname is still the same.
\1f
Date: 5 August 1984 16:13-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

The NETWRK package only defines a single Chaosnet packet buffer,
so you can only hack on connection at a time.
\1f
Date: 1 August 1984 18:12-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC

Dunno who maintains the TCP server exactly, but I found a couple
that had .VALUEd just now.  I dumped one of them into CRASH;TCP .VALUE
Seems to me that I'm seeing more of these guys .VALUEing recently
so perhaps someone should take a look.
\1f
Date: 1 August 1984 13:42-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  EMACS not working on MC, and BUG-EMACS broken
To: RIG @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC
In-reply-to: Msg of 1 Aug 1984 13:12-EDT from Ronald I. Greenberg <RIG>


The mail receipt you received from the COMSAT only indicates that a
there is an addressee (ECARTER@OFFICE-2) who is a member of the
BUG-EMACS mailing list, but who in fact does not exist.  
Your message was delivered to all the other BUG-EMACS people.

I just tried EMACS on MC, and it is working fine.
\1f
Date: 1 August 1984 13:12-EDT
From: Ronald I. Greenberg <RIG @ MIT-MC>
Sender: RIG0 @ MIT-MC
To: BUG-ITS @ MIT-MC

     :bug emacs didn't work as evidenced by the following returned mail.
COMSAT@MIT-MC 08/01/84 12:42:23 Re: Msg of Wednesday, 1 August 1984 12:39-EDT
To: RIG at MIT-MC
Queued: JSL at MIT-MULTICS, Carter at RUTGERS
FAILED: ECARTER at OFFICE-2; Recipient name apparently rejected.
        Last reply was: {550 No such mailbox here}
 Failed message follows:
-------
Date: 1 August 1984 12:39-EDT
From: Ronald I. Greenberg <RIG @ MIT-MC>
To: BUG-EMACS @ MIT-MC

     A little while ago, while logged on to MC I found EMACS working improperly.
For example, c-E, m-F, and m-B were going to incorrect places.  One time m-F
took me backwards one character!  I would be interested in finding out what
was wrong.
                                Ron Greenberg
                                rig@mc

By the way, I suppose the emacs problem might really be a problem with the terminal.
I will try to check this out.
\1f
Date: Fri, 27 Jul 1984  11:50 EDT
Message-ID: <PGS.12034679855.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   "Christopher C. Stacy" <CSTACY@MIT-MC>
Cc:   BUG-ITS@MIT-MC
Subject: front end 11
In-reply-to: Msg of 27 Jul 1984  03:53-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: Friday, 27 July 1984  03:53-EDT
    From: Christopher C. Stacy <CSTACY at MIT-MC>

    MC stopped answering the dialups in the afternoon, and when I came in
    long afterwards the system was apparently "dead"; it was not answering
    anything.  It appeared to be running though.  Unfortunately the front-end
    11 seems to have dropped dead; I could not get to DDT or even 11DDT.  I
    used the disk bootload button to get the 11 back, and stopped and dumped
    ITS to CRASH;ITS 11HUNG in case anyone wants it.  Then I cold booted.

Don't blame me.  I wasn't installed.
\1f
Date: 27 July 1984 03:53-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: front end 11
To: BUG-ITS @ MIT-MC
cc: PGS @ MIT-MC

MC stopped answering the dialups in the afternoon, and when
I came in long afterwards the system was apparently "dead";
it was not answering anything.  It appeared to be running
though.  Unfortunately the front-end 11 seems to have dropped
dead; I could not get to DDT or even 11DDT.  I used the disk
bootload button to get the 11 back, and stopped and dumped
ITS to CRASH;ITS 11HUNG in case anyone wants it.  Then I cold
booted.
\1f
Date: 25 July 1984 16:56-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  MC params
To: BUG-ITS @ MIT-MC
In-reply-to: Msg of 25 Jul 1984 16:41-EDT from J. Noel Chiappa <JNC>

Noel's message reminds me...  Last night I moved the various notes and things
that used to be taped to the inside front door of the first MF10 into the
first MH10.  Now most of that information actually has little to do with
the MH10s, but I figured it was usefull to know what information we -used-
to keep there in case anone ever decides to post some modern truth in that
location.  (I marked them as out of date in a big red pen.)
\1f
Date: 25 July 1984 16:41-EDT
From: J. Noel Chiappa <JNC @ MIT-MC>
Subject: MC params
To: BUG-ITS @ MIT-MC

        Since the whole Ampex seems to be online now, next time someone
rebuilds the system they should change CONFIG > to allow MC to use all
of the 2MW of memory on the system. Right now half the AMPEX is not
being used.
\1f
Date: 20 July 1984 04:56-EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ITS seemed to be looping
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

Well, I am too tired to pursue it further tonight, but the fragments
appear to have come from host GYMBLE by way of BBN-MILNET-GW;
it had several SMTP connections open at the time.  This doesn't help
find the bug (for that it takes a lot of grovelling through the
datagram buffers) but may serve as a warning signal.
\1f
Date: 20 July 1984 04:10-EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ITS seemed to be looping
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

Ignore my query about ITS version to :SL.  I've been doing too much
Unix ADB'ing and forgot ITS does the right thing as usual.
\1f
Date: 20 July 1984 04:04-EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ITS seemed to be looping
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

Keep CRASH;WHAT HEY around for a while.  If your PC trace is right, it
was looping in the IP fragment re-assembly code, which has in the
past been a notorious source of bugs (since it is both very hard to
understand and very seldom exercised).  Can you tell me what version
of ITS it was running, so I can :SL the symbols from the right
file on .; (and please continue to take more crash dumps any time
this happens, since it is unlikely that the bug can be determined
just from one example).

By the way, it makes sense that clock interrupts would be off, since
this code runs at IMP interrupt level.

Oh boy, time to play with PEEK autopsy mode again!
\1f
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 65152; Mon 16-Jul-84 23:06:56-EDT
Date: Mon, 16 Jul 84 23:06 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Ampex memory
To: jnc@MIT-MC.ARPA
cc: bug-its@MIT-MC.ARPA
Message-ID: <840716230650.0.MOON@EUPHRATES.SCRC.Symbolics>

Some (most? all?) of the ports on the Ampex memory don't work, I think
because Ampex's transceiver cards for the DEC memory bus are flakey.
That's probably why the cabling is weird.  The interleaving options
are all very confusing, especially since the cases that are not
supposed to work actually do seem to work.  I talked about this with
CStacy this afternoon some.  I think the bottom line is that you can
put the system into 4-way interleave mode if all of ports 4 through 7
(or wherever the processor is plugged into) on the Ampex work, but if
any of those ports are broken and can't be used you have to use 2-way
interleave mode so the Ampex will still see all memory requests.  It's
also unclear whether 4-way mode is better since it should be only a few
percent faster in the DEC memory (if I remember a measurement I made in
about 1976 correctly) and should be substantially slower in the Ampex
memory, since it can only do one operation at a time (two at a time
when both sectors are working).

MC:MOON;PERF > will measure various things but I don't know how you'll
get the numbers for the MF10 configuration to compare against.

\1f
Date: 16 July 1984 15:45-EDT
From: J. Noel Chiappa <JNC @ MIT-MC>
Subject: new memory
To: BUG-ITS @ MIT-MC

        The MH10's are installed. They are 8 port (dual controller)
boxes, so KBUS0-3 are bussed through all four boxes on port 7-4 (and
thence to the Ampex ports 7-4). The DL10 is port 0, the RP10 is port
1, and the TM10 is port 2. (Don't ask why it's different from the
Ampex). The TM10 bus is terminated on the last DEC box, as before, but
the cable to the AMPEX is right there if anyone wants to plug it in
for some reason. The MH10's are currently in 4-way interleave in the
hardware. It looks like the processor is running two way interleaved;
now that we have this wonderful working 4-way memory maybe we could
switch back?
        Also, the AMPEX just got a write parity error on port 5. if
this happens a lot someone should think about reseating the cables,
etc. Finally, is there some sort of meter we can use to see if the
machine is running faster?
\1f
Date: 16 July 1984 01:05-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC

CRASH;10JUL CRASH just happened again in exactly the same way.
A comsat RESTRT job tried to rename STATS < to OSTATS >, and on the
way out of the call it was noticed that there were still some locks locked.
\1f
ALAN@MIT-ML 07/14/84 06:45:02
To: (BUG ITS) at MIT-ML
After remaining up for 13 days without even a memory error,
ML finally crashed just now because of a software bug.  At QSOC3E+15, on its way
out of the system after trying to do an MLINK, an entry in QSNNR went
negative.  A dump of the same problem was taken by GSB a few weeks ago
and can be found in MC:CRASH;QSOC3E +17@ML if anyone want to look for
it...

\1f
Date: 14 July 1984 03:42-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  ITS seemed to be looping
To: BUG-ITS @ MIT-MC
In-reply-to: Msg of Sat 14 Jul 84 02:43 EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

    Date: Sat, 14 Jul 84 02:43 EDT
    From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
    Things to try:

      Raise switch 0 (the switch 0 on the left).  If this goes to DDT, it's
      taking clock interrupts.

Yeah, I forgot to mention that I tried that, and nothing happened.

      Hit Break and type PC <return>.  If I remember correctly, you can
      read the PC this way without halting the machine.  There are some
      other status-type commands; PCF is the PC flags, PI is the interrupt
      status.

OK, well it happened again which gave me a chance to try out the things I
remembered from this message (wish I had made hardcopy as soon as I got
it!).  Repeated applications of <Break>PC<Return> showed it looping in the
general vicinity of IPRD61 (assuming it was looping in the system, which is
reasonable to assume if it isn't taking clock ints!).  This is a routine in
INET which looks to me like it might well loop given the right gubbish in
memory.

Perhaps with that information someone can take a look at the crash dump I
took (still in CRASH;WHAT HEY) and figure out what caused this.
\1f
Date: 14 July 1984 03:27-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Its a mystery to me.
To: BUG-ITS @ MIT-MC
cc: BUG-DDT @ MIT-MC

How come when a job gets a parity error its superior DDT always gets a
%PIB42?  DDT seemingly get it simultaneous with the interrupt from the
inferior, but thats what you would expect of a real B42, right?  There
doesn't seem to be anything wrong with what DDT is doing as far as I can
tell...
\1f
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60736; Sat 14-Jul-84 02:40:13-EDT
Date: Sat, 14 Jul 84 02:43 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: ITS seemed to be looping
To: alan@MIT-MC.ARPA
Cc: bug-its@MIT-MC.ARPA

Things to try:

  Raise switch 0 (the switch 0 on the left).  If this goes to DDT, it's
  taking clock interrupts.

  Hit Break and type PC <return>.  If I remember correctly, you can read
  the PC this way without halting the machine.  There are some other status-type
  commands; PCF is the PC flags, PI is the interrupt status.

  Hit Break and type SP <return>.  This stops the machine cleanly (between
  instructions).  If this works, the microcode isn't looping.  Now you can
  get the PC then type DDT (or ST 774000) to get into DDT and decode that PC.

  If the microcode is looping the SM command will restart it.  This also does
  nasty things like resetting the I/O bus.  I think it preserves the PC though.

  There is a command file, J KLHUNG, which prints out everything in sight.  90%
  of what it prints is worthless, but it includes micro and macro PCs.

I believe there is a piece of paper taped to the machine that tells you to
do J KLHUNG.  Of course there are a lot of pieces of paper taped to the machine!

\1f
Date: 14 July 1984 01:50-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC

ITS died in a new way (for me) just now.  The immediate symptoms were what
I would expect if the microcode was looping.  (No lights on any box were
blinking, nothing was visibly doing anything, the system console had not
printed anything to indicate anything was wrong.)  I thrashed around a bit
trying to find the KLDCP documentation to see if I could learn anything
about what the processor was doing.  When Taft found me a copy I was
frustrated enough that I just took a crash dump (yeah, I know, thats
probably worthless, its in CRASH;WHAT HEY) and reloaded it.  So what should
I have done?
\1f
Date: 11 July 1984 23:30-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  ml doesn't get updates
To: CENT @ MIT-MC
cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 11 Jul 1984 23:16-EDT from Pandora B. Berman <CENT>

Aha, ML had the old version of INQUIR so that updates from MC went to
ML, but ML didn't update itself!  I installed the new one.
\1f
Date: 11 July 1984 23:16-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: ml doesn't get updates
To: CSTACY @ MIT-MC
cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC

    Date: 9 July 1984 16:02-EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    Subject:  ml doesn't get updates
    To: CENT @ MIT-MC
    cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
    In-reply-to: Msg of 9 Jul 1984 06:18-EDT from Pandora B. Berman <CENT>
    ML should be getting updates; when it came back up I put
    it back in the list of machines to update and tested it.
    It worked for me; I'll look to see what is going wrong.

i looked at the relevant STATS files. running INQUIR on ML creates a piece
of mail to INQUPD at MC; this reaches MC and is only dealt with locally.
at neither juncture is an INQUPD performed on ML.
\1f
Date: 11 July 1984 14:33-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC
In-reply-to: Msg of 10 Jul 1984 08:50-EDT from Patrick G. Sobalvarro <PGS>

    Date: 10 July 1984 08:50-EDT
    From: Patrick G. Sobalvarro <PGS>
    I found MC bug-halted.  I dumped it to .;10JUL CRASH; dunno if anyone
    wants to poke at it.

Actually its in CRASH;10JUL CRASH.  While returning from a RENAME a job
discovered it still had some locks locked.  MC was parity erroring a bit at
the time.  Should we worry about this harder?
\1f
Date: 11 July 1984 11:27-EDT
From: J. Noel Chiappa <JNC @ MIT-MC>
Subject: SECOND: hardwarily back
To: BUG-ITS @ MIT-MC

        Drive 1 is fixed, but I can't remember how to invoke UCOP
to bring the directories over. Someone should bring the system down
and bring it back up with SECOND: around.
\1f
Date: Tue, 10 Jul 1984  21:10 EDT
Message-ID: <GLR.12030325365.BABYL@MIT-OZ>
From: Jerry Roylance <GLR@MIT-OZ>
To:   CHAOS-MAINT@MC, BUG-ITS@MC
Subject: Subnet 6


Subnet 6 was broken at the MC bulkhead (return of the bad UHF connectors).

The MC transceiver's power connector was also broken; everything is
now in order.
\1f
Date: 10 July 1984 08:50-EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-ITS @ MIT-MC

I found MC bug-halted.  I dumped it to .;10JUL CRASH; dunno if anyone
wants to poke at it.
\1f
Date: 10 July 1984 00:49-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: DCP @ MIT-MC
cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, CSTACY @ MIT-MC
In-reply-to: Msg of 10 Jul 1984 00:19-EDT from David C. Plummer <DCP>

    Date: 10 July 1984 00:19-EDT
    From: David C. Plummer <DCP>
    I'm still not a speed reader.  (I'm coming in over a vadic,
    AAA, ITS 1370, DDT 1480.)  <alt><alt>U prints the bye
    message and then clears the screen.

OK, OK.  I fixed it again.  If its still broken, perhaps you better see
Evelyn Wood, because I can't imagine how I can have failed to fix it this
time.
\1f
Date: 10 July 1984 00:19-EDT
From: David C. Plummer <DCP @ MIT-MC>
To: ALAN @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC, CSTACY @ MIT-MC

I'm still not a speed reader.  (I'm coming in over a vadic,
AAA, ITS 1370, DDT 1480.)  <alt><alt>U prints the bye
message and then clears the screen.
\1f
Date: 9 July 1984 19:10-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  oops
To: DCP @ MIT-MC, BUG-DDT @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 9 Jul 1984 10:14-EDT from David C. Plummer <DCP>

    Date: 9 July 1984 10:14-EDT
    From: David C. Plummer <DCP>
    Either ITS was changed, or DDT was, and for the worse.
    When I log out, it does a :BYE followed by :OUTEST.
    I don't think either of these are at fault.  What happens
    is that it prints the BYE message, and then clears the
    screen before printing the console free message.  Needless
    to say, I'm not a speed reader.

Believe it or not, another symptom of this same bug was the fact that
:CHUNAME didn't work anymore.  I fixed the bug and installed a new DDT.
\1f
Date: 9 July 1984 16:35-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-DDT @ MIT-MC
cc: BUG-ITS @ MIT-MC

I de-installed the latest DDT, since there are all these bug
reports coming in and the responsible hacker is asleep now.
\1f
Date: 9 July 1984 16:02-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  ml doesn't get updates
To: CENT @ MIT-MC
cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 9 Jul 1984 06:18-EDT from Pandora B. Berman <CENT>

ML should be getting updates; when it came back up I put
it back in the list of machines to update and tested it.
It worked for me; I'll look to see what is going wrong.
\1f
Date: 9 July 1984 11:25-EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: CHUNAME
To: BUG-ITS @ MIT-MC

When I am logged in as JEFFG and do :CHUNAME JPG 
It says OP?  and won't chuname me.
\1f
Date: 9 July 1984 10:14-EDT
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC

Either ITS was changed, or DDT was, and for the worse.
When I log out, it does a :BYE followed by :OUTEST.
I don't think either of these are at fault.  What happens
is that it prints the BYE message, and then clears the
screen before printing the console free message.  Needless
to say, I'm not a speed reader.
\1f
Date: 9 July 1984 06:18-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: ml doesn't get updates
To: BUG-INQUIR @ MIT-MC
cc: BUG-ITS @ MIT-MC

i modified my inquir entry a week ago to reflect my new office. ML
still thinks i'm in 912. this is a bug. As long as ML is going to
stay around for the indefinite (and probably not too short) future,
would whoever diked it out of the inquir-update path please put it
in again?
\1f
Date: 8 July 1984 15:38-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: MLDEV
To: BUG-ITS @ MIT-MC

MLDEV does not work between ITS machines except via Chaosnet.
Reminder to me to make it check for alternate host addresses
on the ARPAnet and try them if Chaos is unresponsive.
\1f
Date: 7 July 1984 16:55-EDT
From: Charles Frankston <CBF @ MIT-MC>
Subject:  The saga of Subnet 6
To: CHAOS-MAINT @ MIT-MC, BUG-ITS @ MIT-MC
cc: RZ @ MIT-MC

MC-IO-11 and TOTO (OZ's network front end) don't communicate on subnet 6.
Each one can apparently communicate with most of the other machines on
subnet 6, but not with each other.  DPH said that subnet 6 was extended a
few days ago, which is apparently when this problem started.

My guess is that TOTO can send to MC-IO-11 since TOTO's routing table says
to use subnet 1 to talk to MC rather than subnet 6, but for some reason
MC-IO-11 probably tries to use subnet 6 to talk to TOTO and this loses.

Unplugging the MC-IO-11 subnet 6 interface allows MC and OZ to
communicate.  This is the state things have been left in.  However, this
causes hosts which do not implement dynamic routing, such as ML and
MIT-VAX to be unable to talk to MC, since they think that subnet 6 is the
way to get there..
\1f
Date: 7 July 1984 00:20-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  MC (not) broken
To: BUG-ITS @ MIT-MC
cc: DPH @ MIT-MC
In-reply-to: Msg of Fri 6 Jul 1984  23:34 EDT from PGS at MIT-OZ

    Date: Thursday, 5 July 1984  18:12-EDT
    From: Christopher C. Stacy <CSTACY at MIT-MC>
    Something is wrong with MC's hardware.  ITS is having trouble
    talking to the T-300s, and can barely reach the Chaosnet (even
    though the ncp statistics look reasonable).  Users were getting
    wedged today unable to log out; one of my jobs was stuck in a
    CLOSE call with a FLSINS of zero.  DPH reports that the IO-11
    dropped very dead earlier.

Just for the record, DPH disconnected MC from subnet 6 and all the Chaos
net problems went away.  Other wierdnesses reported by CStacy may or may
not have anything to do with this.

DPH should put himself on Bug-ITS.
\1f
Date: Fri, 6 Jul 1984  23:34 EDT
Message-ID: <PGS.12029302870.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   "Christopher C. Stacy" <CSTACY@MIT-MC>
Cc:   BUG-ITS@MIT-MC
Subject: MC broken
In-reply-to: Msg of 5 Jul 1984  18:12-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: Thursday, 5 July 1984  18:12-EDT
    From: Christopher C. Stacy <CSTACY at MIT-MC>
    To:   BUG-ITS at MIT-MC
    cc:   BEDE at MIT-XX, MOON at SCRC-STONY-BROOK
    Re:   MC broken

    Something is wrong with MC's hardware.  ITS is having trouble
    talking to the T-300s, and can barely reach the Chaosnet (even
    though the ncp statistics look reasonable).  Users were getting
    wedged today unable to log out; one of my jobs was stuck in a
    CLOSE call with a FLSINS of zero.  DPH reports that the IO-11
    dropped very dead earlier.

    Two mysteries:

    1. What are these blue wires running around MC?
       Someone told me they are an attempt to "make MC think it
       is talking to the ROLM switch by faking out the DL-10 or something?"

I suspect that this is just Ty trying to connect Rolm switch lines to normal
tty lines (not under modem control).  If you find out that it's something
else, would you let me know?
\1f
Date: 5 July 1984 18:40-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  :HOSTAT
To: BUG-ITS @ MIT-MC
cc: PGS @ MIT-MC
In-reply-to: Msg of 5 Jul 1984 14:21-EDT from Patrick G. Sobalvarro <PGS>

    Date: 5 July 1984 14:21-EDT
    From: Patrick G. Sobalvarro <PGS>
    To:   BUG-ITS

    :hostat ai-chaos-11 gives sysbin; hosts1 > - file not found.

I deleted the obsolete HOSTAT program so that people would stop being
confused.
\1f
Date: 5 July 1984 18:12-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: MC broken
To: BUG-ITS @ MIT-MC
cc: BEDE @ MIT-XX, MOON @ SCRC-STONY-BROOK


Something is wrong with MC's hardware.  ITS is having trouble
talking to the T-300s, and can barely reach the Chaosnet (even
though the ncp statistics look reasonable).  Users were getting
wedged today unable to log out; one of my jobs was stuck in a
CLOSE call with a FLSINS of zero.  DPH reports that the IO-11
dropped very dead earlier.

Two mysteries:

1. What are these blue wires running around MC?
   Someone told me they are an attempt to "make MC think it
   is talking to the ROLM switch by faking out the DL-10 or something?"

2. The DEC log book says that the DL-10 had a bad module which was
   not replaced, but which was moved to another slot and that now
   everything "works fine".

If no one has any good ideas, I will call DEC and have them see
about working on the DL-10 again.  Meanwhile, the system is not
very usable.

\1f
Date: 5 July 1984 14:21-EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-ITS @ MIT-MC

:hostat ai-chaos-11 gives sysbin; hosts1 > - file not found.
\1f
Date: 4 July 1984 05:52-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC appears to be unable to talk to OZ (finger, telnet, supdup),
but finds is with :UP.  Has no trouble with other chaos hosts I tried
(prep, eddie, speech).
\1f
MOON@MIT-ML 07/04/84 05:10:46 Re: HOSTAT OBERON
To: (BUG ITS) at MIT-ML
CC: GSB at MIT-ML, PSZ at MIT-ML
:HOSTAT is an ancient program that retrieves a report on Arpanet hosts from DM.
Obviously it should be flushed in favor of a program that uses Chaosnet
HOSTAT protocol as PSZ evidently expected..
\1f
Date: 4 July 1984 01:59-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: [Forwarded: PSZ@MIT-MC, Re: ]
To: BUG-ITS @ MIT-MC

PSZ@MIT-MC 07/03/84 23:29:43
:HOSTAT OBERON
on MC says: sysbin;hosts1 > - file not found.
\1f
Date: 25 June 1984 04:39-EDT
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

T10 on MC is broken.  Twice I dialed up to it and my input
was thoroughly garbled.  I redialed to T12 and had no problems.
\1f
Date: 20 June 1984 23:16-EDT
From: Charles Frankston <CBF @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

The dialup garbage is NOT Concept 100 control sequences.  It seems to
happen with me on triple modems, which seem to raise Carrier Detect before
they've quite settled, perhaps before they're synchornized.  If you wait
an extra two seconds after dialing up before typing return, it probably
won't happen.
\1f
Date: 20 June 1984 18:23-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Dialup Gubble
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 20 Jun 1984 15:24-EDT from Christopher C. Stacy <CSTACY>

    Date: 20 June 1984 15:24-EDT
    From: Christopher C. Stacy <CSTACY>
    Sometimes when I dial in to the Vadics, ITS sends alot of
    unrecognizable garbage to my terminal when printing out the greeting
    message.  This goes away after a TCTYP command, and a friend of mine
    on a VT100 claims the garbage looks like Concept-100 terminal control
    sequences, although on my AAA it just prints blobs.

If this was true, then wouldn't everybody who uses Vadics see randomness
when they dial up?  (At least occasionally.)  I have never seen anything of
the sort.  

Perhaps its marsh gas?
\1f
Date: 20 June 1984 15:24-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Sometimes when I dial in to the Vadics, ITS sends alot of
unrecognizable garbage to my terminal when printing out the greeting
message.  This goes away after a TCTYP command, and a friend of mine
on a VT100 claims the garbage looks like Concept-100 terminal control
sequences, although on my AAA it just prints blobs.
\1f
Date: Sun 17 Jun 84 14:10:44-EDT
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: Looping in the scheduler (with interrupts on, luckily)
To: DCP@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
cc: JNC@MIT-XX.ARPA
In-Reply-To: Message from "David C. Plummer <DCP @ MIT-MC>" of Sat 16 Jun 84 20:14:00-EDT

        I think this was due to the console 11 dying. It seemed to
be completely frozted; i.e. trying "LOAD ADDR" didn't result in
whatever number you had in the switches showing up in the ADDR lights.
-------
\1f
Date: 16 June 1984 20:14-EDT
From: David C. Plummer <DCP @ MIT-MC>
Sender: DCP0 @ MIT-MC
Subject:  Looping in the scheduler (with interrupts on, luckily)
To: BUG-ITS @ MIT-MC

This morning I dialed up MC and got on T12.  I was merrily doing
random things.  I didn't do anything for a while, but when I
tried I got no response.  I figured MC died.  I was wrong.

Just recently ALAN noticed I was around and informed me that not
only was my job still there, but it was taking up all the extra
computrons MC could offer.  It was looping in TYSTE1 waiting for
the -11 to set DTEOST to some negative value.  The -11 wasn't
doing this.  The job could not be logged out or easily examined
because it couldn't be PCLSRed.

The first thing I tried was to tell the job (by bashing the PC)
to try sending another doorbell to the -11.  That didn't work.
So, I set DTEOST to -1 by myself.  The job unfroze and we had
control again (for some value of control).  Sending a TTY message
to that console (causing output) now waits at TYOW4 waiting for
the output buffer to be sufficiently empty to output.  This will
never happen, but at least it is PCLSRable and doesn't take up
the entire machine.

As experiments, I tried using T13 and T14.  The first attempt to
output on these caused the same phenomena: Looping in TYSTE1.
Bashing DTEOST to -1 and outputing again caused waiting at TYOW4.
(Using :COPY to the TTY line was sufficient to cause this.)  This
unfortunately means T12, T13, and T14 are no longer usable for
experimentation unless you go in and reset the pointers and
counts...

This is probably just a hardware lossage and requires MC to be
rebooted to get the piece of dung -11 unwedged.
\1f
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 46531; Mon 11-Jun-84 08:04:08-EDT
Date: Mon, 11 Jun 84 08:02 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: TCP gatway
To: BUG-LISPM@SCRC-RIVERSIDE.ARPA
Cc: bug-its@MIT-MC.ARPA
Message-ID: <840611080222.9.DLW@CHICOPEE.SCRC.Symbolics>

In Symbolics 3600 Experimental System 243.758,
Experimental Hardcopy 21.31, Experimental Zmail 84.157,
Experimental LMFS 38.91, Experimental Tape 22.17,
Experimental Basic Sage 2.26, Experimental New Documentation System 2.0,
Experimental Print 35.10, Experimental IP-TCP 9.1, Japanese 15.0,
Experimental TD80-Tape 1.22, cold load 114, microcode TMC5-MIC 290,
FEP 18, Big band, on Chicopee:

>>Error: 
         Unable to invoke FILE (TCP-FTP) -- CMU-CS-SPICE (via MC on CHAOS) by any path.
         TCP-GATEWAY (TCP-GATEWAY) -- MC on CHAOS: Cannot connect to 21 at CMU-CS-SPICE via MC:
         Request to MC for a TCP 128.2.254.139 25 connection was refused.
         Reason given was "TCP connection to foreign host failed"
While in the function NETI:GET-CONNECTION-FOR-SERVICE-1 \18 NET:GET-CONNECTION-FOR-SERVICE \18 (:DEFUN-METHOD FS:TCP-FTP-VALIDATE-CONN)

It would be nice if the MC gateway would pass on some more info than
just "conection to foreign host failed".  If you try to FTP to
CMU-CS-SPICE right now, using FTPU on MC, it says that "Request for
Connection was refused by foreign host"; it would be nice it this info
had been passed through by the gateway.
\1f
Date: 12 June 1984 15:03-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  Reconnecting Spock's brain.
To: ALAN @ MIT-MC
cc: BUG-TIMES @ MIT-MC, BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 12 Jun 1984 00:13-EDT from Alan Bawden <ALAN>

    Date: 12 June 1984 00:13-EDT
    From: Alan Bawden <ALAN>
    To:   BUG-TIMES
    Re:   Reconnecting Spock's brain.

    I am quite certain that the TIMES/CTIMES program is totally broken.  The
    other night when MC was mistaken about the correct time, Penny ran :TIMES
    to find out what other sites on the net thought the time was.  To our
    surprise the program reported that every machine it could reach
    more-or-less agreed with MC's bogus time.  When Penny ran PDSET to correct
    MC, every machine made the corresponding correction.  I also observe that
    the times the program reports are ALWAYS in ascending order!  I think it is
    quite obvious what is going on here...

I have fixed this, and spiffed the program up a little while at it.

\1f
Date: 23 May 1984 00:49-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  CRASH;STACKP FUCKED
To: BUG-ITS @ MIT-MC

I have just been informed by GSB that he made a crash dump of an ITS that
had died trying to read an ML backup tape last Friday.  Since it looks like
this is a repeatable error (DLW crashed MC a couple of times trying to read
in an AI backup tape last Sunday), its probably worth looking at.  Note
that there seems to be no trouble reading in MC's backup tapes.  The dump
GSB took is in CRASH;STACKP FUCKED.  If you look at what's in P you will
understand the name.
\1f
Date: 17 May 1984 23:43-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  TENEX Remembered: Foo!
To: CBF @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 17 May 1984 22:09-EDT from Charles Frankston <CBF>

    Date: 17 May 1984 22:09-EDT
    From: Charles Frankston <CBF>

        [From a letter about TENEX:]

            Date: 17 May 1984 13:14-EDT
            From: DIPACE at BBNF.ARPA

                          Demand-paged-virtual memory,
                          the first one of its kind;

        The question is, was it?  Wasn't paging ITS around before TENEX?

    I believe so.  But so certanly was the University of Manchester Atlas,
    Multics, and possibly the Berkeley XDS 940 time sharing system, although I
    don't know if it counts a demand paged.

    Oh, yeah, 360/67, TSS, CP/CMS, probably also both predate Tenex, but I'm
    not sure..
Foo.  You know I meant on PDP-10s.
Didn't ITS start out Base-and-bounds?
\1f
Date: 17 May 1984 22:09-EDT
From: Charles Frankston <CBF @ MIT-MC>
Subject: TENEX Remembered
To: GUMBY @ MIT-MC
cc: BUG-ITS @ MIT-MC

    [From a letter about TENEX:]

        Date: 17 May 1984 13:14-EDT
        From: DIPACE at BBNF.ARPA

                      Demand-paged-virtual memory,
                      the first one of its kind;

    The question is, was it?  Wasn't paging ITS around before TENEX?

I believe so.  But so certanly was the University of Manchester Atlas,
Multics, and possibly the Berkeley XDS 940 time sharing system, although I
don't know if it counts a demand paged.

Oh, yeah, 360/67, TSS, CP/CMS, probably also both predate Tenex, but I'm
not sure..
\1f
Date: 17 May 1984 21:06-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  TENEX Remembered
To: BUG-ITS @ MIT-MC
In-reply-to: Msg of 17 May 1984 13:14-EDT from DIPACE at BBNF.ARPA

[From a letter about TENEX:]

    Date: 17 May 1984 13:14-EDT
    From: DIPACE at BBNF.ARPA

                  Demand-paged-virtual memory,
                  the first one of its kind;

The question is, was it?  Wasn't paging ITS around before TENEX?
\1f
Date: 12 May 1984 18:14-EDT
From: Kent M Pitman <KMP @ MIT-MC>
To: ELAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 12 May 1984 15:32-EDT
    From: Phyllis E. Koton <elan @ MIT-MC>
    Sender: ING @ MIT-MC
    Re:   bizarre dialup error
    To: KMP @ MIT-MC

    The weirdest thing happened to me.  I dialed up MC from
    home, hit a carriage return to get ITS attention, and it echoed the
    CR, but didn't print out any msg.  SO I hit CR again, and again it 
    echoed it, but no MC ITS ...
    so just to see what was going on, I said ":versio" and it said I was
    MC ITS USR:ING.  IS THAT THE STRANGEST THING?  I did whois on this
    ING and he is some tourist on the system.  But I got logged in as
    him without ever saying login or giving a password.  I am really
    psyched out by this.  Do you think I should send mail to bug-its?
            --pk

This isn't the first time such a thing has happened. Your guess is probably
correct; ING somehow hung up without ITS noticing so when you dialed in,
you got his already-logged-in tty line. I'm forwarding this to BUG-ITS
in case they care, but I wouldn't lose any sleep over it.
-kmp
\1f
Date: 8 May 1984 14:39-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  This afternoon's crash
To: BUG-ITS @ MIT-MC

TTY: BUFFER EMPTY AT TYIREM
Dumped into CRASH;TYIREM 050884
\1f
Date: 2 May 1984 20:41-EDT
From: Jacob Moskowitz <JMSK @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: CAREY @ MIT-MC


        I just logged in to the 300 baud
line & discovered that I was already 
logged in as CAREY.  Shouldn't ITS autologout on disconnect ?
\1f
Date: 2 May 1984  09:39 PDT (Wed)
Message-ID: <[SRI-NIC].IAN. 2-May-84 09:39:34>
From: Ian Macky <Ian@SRI-NIC>
To:   Richard M. Stallman <RMS@MIT-MC>
Cc:   BUG-ITS@MIT-MC
In-reply-to: Msg of 2 May 1984  02:00-PDT from Richard M. Stallman <RMS at MIT-MC>

    Date: Wednesday, 2 May 1984  02:00-PDT
    From: Richard M. Stallman <RMS at MIT-MC>
    To:   BUG-ITS at MIT-MC

    When I supdup to MC, if I get tty 50, most characters do not echo and
    are not obeyed.  Only rubout and control-G get any response from DDT.
    :TCTYP TTY 50 DESC shows exactly the same thing as other ttys that
    I get which work properly.  I locked tty 50.

The exact thing has happened to me before, too, many months ago tho.
\1f
Date: 2 May 1984 05:00-EDT
From: Richard M. Stallman <RMS @ MIT-MC>
To: BUG-ITS @ MIT-MC

When I supdup to MC, if I get tty 50, most characters do not echo and
are not obeyed.  Only rubout and control-G get any response from DDT.
:TCTYP TTY 50 DESC shows exactly the same thing as other ttys that
I get which work properly.  I locked tty 50.
\1f
Date: 2 May 1984 04:57-EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-ITS @ MIT-MC

I'm unable to supdup to MC right now, because the supdup server claims that
all network ports are in use, although only t42-t51 are in use.  nsttys is
27, so we should be able to do better than this.  The ttys actually seem to 
be there; could this be caused by someone not reassembling the supdup server
after the last system installation?
\1f
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 25977; Wed 2-May-84 00:52:55-EDT
Date: Wed, 2 May 84 00:54 EDT
From: "David A. Moon" <Moon%SCRC-TENEX@SCRC-RIVERSIDE.ARPA>
Subject: Meter hardware on MC
To: BUG-ITS@MIT-MC.ARPA
In-reply-to: The message of 2 Feb 84 01:34-EST from David A. Moon <MOON5 at MIT-MC>

    Date: 2 February 1984 01:34 EST
    From: David A. Moon <MOON5 @ MIT-MC>

    DATAI 24,n executed in user mode clobbers locations n and n+1 in the system!
    It's a good thing I tested this by hand before writing a program to use it.
    ITS executes the instruction with XCTR, as it should.  I suspect this is
    a bug in the microcode.  I guess I'll use .suset [.rrunt,, like a good little boy.
    -------
    I looked at the microcode and now think it's a bug in the hardware (MCL board
    of course).  EPT REF clears the flag that SET PXCT sets?

Fixed in the source of ITS!  (Cleaning out my mail file).
\1f
Date: 22 April 1984 20:51-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Hack attack.
To: BUG-ITS @ MIT-MC
cc: KMP @ MIT-MC

I just amused myself by recreating the source of SYS:ATSIGN DEVICE from the
binary.  I restrained myself from fixing any of its problems until I got it
to work.  Those results can be found in ALAN;@DEV 40.  Then I made a couple
of trivial changes (@DEV 43), debugged them, and installed it.  I'll
install the source in a better place as soon as I am sure I am done with it.

I renamed the old binary to be ATSIGN ODEVIC in case of disaster.

Things in the source I had questions about are commented with ";???".

In the bugs-you-can-only-find-by-reading-the-source department:

o  I fixed the problem where the "<0" and ">0" devices refered to the D and
   ARC devices respectively.

o  I didn't do anything about KMP's complaint that SYS4^F in DDT is confusing.

o  I found a related randomness; try typing THIRD7^F to DDT.
\1f
Date: 13 April 1984 08:14-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject:  IPQ:
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

The IPQ: device is for getting a handle on Internet Packet Queues.
Its main purpose was to allow UDP user/server programs to be written,
but it is also used by a packet-log debugging program.  I don't
consider it complete yet -- it works, but is difficult to use.  There
were never (and still aren't really) any good examples of things to
use UDP for, so it didn't have high priority and thus was never simplified.
\1f
Date: 13 April 1984 01:05-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Why aren't you working on your thesis?
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 11 Mar 1984 16:48-EST from Alan Bawden <ALAN>

    Date: 11 March 1984 16:48-EST
    From: Alan Bawden <ALAN>
    RFNAME on a SPY: channel should return the appropriate FN1.
    RFNAME on a CHAOS: channel should return as a directory name a host number
        just like TCP: channels.

I just implemented both of these.  Whoever next installs a new ITS should
try them out.

KLH:  What is the IPQ: device all about?
\1f
Date: 9 April 1984 20:25-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: TCP Bug
To: CLYNN @ BBNA
cc: BUG-FTP @ MIT-MC, BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC,
    Barrett @ BBNG

I fixed this bug (ACK 1 too high) in the source; someone assemble a new ITS
one of these days.  I also patched the running ITS on MC, so that
CLynn can re-test right away to verify that it now works.  (But didn't
patch the ITS on disk, in case he wants to use the bug for a while
to debug the TOPS-20 side).
\1f
Date: 30 Mar 1984  04:39 EST (Fri)
Message-ID: <MARTY.12003417172.BABYL@MIT-OZ>
From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
To:   BUG-ITS@MIT-MC
Subject: [Who?: forwarded]


Could someone stop MC from sending unparsable ITS mail headers out
onto the network?  

Received: from MIT-MC by MIT-OZ via Chaosnet; 30 Mar 84 02:26-EST
TK@MIT-MC 03/30/84 02:08:32
To: marty at MIT-OZ
Indeed.  It's about 65 degrees and was sunny until the sun went down.
It was "cold" today, and everyone was complaining.
\1f
Date: 28 March 1984 19:38-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: ucprl5+1 again
To: BUG-ITS @ MIT-MC

dumped to crash;ucplr5 gsb1
Also complained about extra garbage in ufd STUDNT.

From the looks of the return action on the system console, it's
about to go again.  It's definitely dropping characters too.
\1f
Date: 28 March 1984 16:44-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  All is not well...
To: BUG-ITS @ MIT-MC

MC crashed twice this afternoon at QINTE+44.  Crash dump in CRASH;QINTE +44.
Some kind of disk hardware lossage?  While I was sitting here it
crashed again at UCPRL5+1.  Thats in CRASH;UCPRL5 +1.  Some kind of screwup
running around circular page lists.
\1f
Date: 23 March 1984 05:28-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ITSDOC?
To: ALAN @ MIT-MC
cc: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC

P.S. you might want to consider calling it SYSDOC instead, because
this has the feature that changes to files therein will be reported on
the system console.  Not a real vital issue.
\1f
Date: 23 March 1984 05:25-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ITSDOC?
To: ALAN @ MIT-MC
cc: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC


    Actually I have been tempted a couple of times recently to revive the
    ITSDOC directory and set the documentation up as it was on AI, where
    .INFO.;ITS FOO was usually a link to ITSDOC;FOO >.  This has the advantage
    of letting us keep numbered versions of the documentation, and given that I
    am frobbing the documentation occasionally these days, it might be nice to
    not always immediately lose the previous version.

I like that idea!
\1f
Date: 19 March 1984 02:56-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  ITSDOC?
To: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 19 Mar 1984 02:09-EST from David Vinayak Wallace <GUMBY>

    Date: 19 March 1984 02:09-EST
    From: David Vinayak Wallace <GUMBY>
    What happened to the ITSDOC directory?

When I wondered the same thing, we went and looked at AI backups to
discover just where was kept there.  What we found was nothing that isn't
now named MC:.INFO.;ITS. 

Actually I have been tempted a couple of times recently to revive the
ITSDOC directory and set the documentation up as it was on AI, where
.INFO.;ITS FOO was usually a link to ITSDOC;FOO >.  This has the advantage
of letting us keep numbered versions of the documentation, and given that I
am frobbing the documentation occasionally these days, it might be nice to
not always immediately lose the previous version.
\1f
Date: 19 March 1984 02:09-EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  ITSDOC?
To: BUG-ITS @ MIT-MC

What happened to the ITSDOC directory?
\1f
Received: from MIT-LISPM-31 by MIT-OZ via Chaosnet; 18 Mar 84 19:29-EST
Date: Sunday, 18 March 1984, 19:29-EST
From: Patrick G. Sobalvarro <pgs%MIT-OZ@MIT-MC.ARPA>
Subject: T03 SDRC ?
To: KMP at MIT-MC, CStacy at MIT-MC, BUG-ITS at MIT-MC
In-reply-to: The message of 18 Mar 1984 16:31-EST from Kent M Pitman <KMP at MIT-MC>

    Received: from MIT-MC by MIT-OZ via Chaosnet; 18 Mar 84 16:32-EST
    Date: 18 March 1984 16:31-EST
    From: Kent M Pitman <KMP @ MIT-MC>
    Subject: T03 SDRC ?
    To: BUG-ITS @ MIT-MC
    cc: KMP @ MIT-MC

    I am pretty sure that T03 is not a line to SDRC any more. I think it is
    just a 300 baud dialup like T04-T07. Could someone please check this and
    update its info in whatever database is used by FINGER? Thanks. -kmp

CStacy seems to have done this, but the 11 does not think that this line is
under modem control, so it won't work very well as one.  When I next work on
this tty line cruft I'll change this, if the thing really is a dialup line.
Incidentally, if T03 is a dialup now, what phone is it connected to?
\1f
Date: 18 March 1984 16:31-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: T03 SDRC ?
To: BUG-ITS @ MIT-MC
cc: KMP @ MIT-MC

I am pretty sure that T03 is not a line to SDRC any more. I think it is
just a 300 baud dialup like T04-T07. Could someone please check this and
update its info in whatever database is used by FINGER? Thanks. -kmp
\1f
Date: 13 March 1984 15:22-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: CRASH;IPQUSI
To: BUG-ITS @ MIT-MC, GSB @ MIT-MC

Thanks for the dump.  I have fixed the bug in the source (INET), but
did not bother to patch the current binary.  ITS should be re-assembled
one of these days.

What happened was that a bad UDP datagram arrived which was not long
enough to hold a UDP header.  Bug #1 was not checking the length for
this.  Fortunately the UDP dest port value happened to be zero in that
buffer, so the code tried to find a UDP queue for port 0.  Bug #2 was
that this succeeded -- it "found" an non-existent queue with all the
relevant info zero.  IPQUSI caught this when it noticed it was about
to try interrupting the system job!  Both bugs are now fixed, and
I deleted the crash dump.
\1f
Date: 13 March 1984 12:17-EST
From: Alan Bawden <ALAN @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC
In-reply-to: Msg of Tue 13 Mar 84 06:54 EST from Christopher C. Stacy <CStacy at MIT-MC.ARPA>

    Date: Tue, 13 Mar 84 06:54 EST
    From: Christopher C. Stacy <CStacy at MC>
        Date: 29 February 1984 10:59-EST
        From: Kent M Pitman <KMP>
        SYS4^F clears the screen and types NON-DIRECTORY DEVICE.
        Shouldn't this give a no such directory error? I assume
        DDT or ITS is somehow stripping the 4 and assuming I'm
        trying to reference the SYS device. My file defaults end
        up with SYS4: in them...
    I think this might be an ITS bug.  In DDT at NCTLF2, it tries to open
    the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason,
    and succeeds.

As I already said, the place to do something about this is in the unknown
device handler.  (You know, SYS;ATSIGN DEVICE?  The file we don't have a
source for?)  ITS proper, and DDT are doing exactly the right things.
\1f
Date: Tue, 13 Mar 84 06:54 EST
From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
To: BUG-ITS@MIT-MC.ARPA
Cc: Kent M Pitman <KMP@MIT-MC.ARPA>, BUG-DDT@MIT-MC.ARPA
In-reply-to: The message of 29 Feb 84 10:59-EST from Kent M Pitman <KMP>

    Date: 29 February 1984 10:59-EST
    From: Kent M Pitman <KMP>
    SYS4^F clears the screen and types NON-DIRECTORY DEVICE.
    Shouldn't this give a no such directory error? I assume
    DDT or ITS is somehow stripping the 4 and assuming I'm
    trying to reference the SYS device. My file defaults end
    up with SYS4: in them...

I think this might be an ITS bug.  In DDT at NCTLF2, it tries to open
the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason,
and succeeds.
\1f
Date: 12 March 1984 22:12-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Sender: GSB5 @ MIT-MC
Subject: crash dumps
To: BUG-ITS @ MIT-MC
cc: BUG-TCP @ MIT-MC

bughalt at IPQUSI+6, dumped to CRASH;IPQUSI 031284.
a couple days ago, bughalt at TYIREM (actually TYIRE1+1), dumped
to CRASH;TYIREM 030984.
\1f
Date: 11 March 1984 16:48-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  RFNAME & randomness
To: BUG-ITS @ MIT-MC

RFNAME on a SPY: channel should return the appropriate FN1.
RFNAME on a CHAOS: channel should return as a directory name a host number
        just like TCP: channels.

BTW, I have always felt that when opening the CLI: device, filenames should
be treated exactly as they are when you open the USR: device.  That is, you
should be able to use a <JOB> specification as the first filename if the
second filename is 0.
\1f
Date: 10 March 1984 18:52-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: ALAN @ MIT-MC

ITS was losing from network and local terminals (although apparently
working ok from dialups). The 11 didn't seem to have a parity error
light on and was not obviously stopped or anything, but we (ALAN and
I) did :.;BOOT11 and the world went back to normal. Is this the right
thing to have done and/or is there any more debugging information we
could have scrounged up before reloading the 11? -kmp
\1f
Date: 9 March 1984 10:46-EST
From: John G. Aspinall <JGA @ MIT-MC>
Subject:  jga;ar3:
To: CSTACY @ MIT-MC
cc: ALAN @ MIT-MC, BUG-ARCDEV @ MIT-MC
In-reply-to: Msg of 9 Mar 1984 08:01-EST from Christopher C. Stacy <CSTACY>

Alan fixed it.  I guess neither of us sent a follow up.
Sorry to make unneeded work.  cheers...
\1f
Date: 9 March 1984 08:01-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  jga;ar3:
To: JGA @ MIT-MC
cc: ALAN @ MIT-MC, BUG-ARCDEV @ MIT-MC
In-reply-to: Msg of 7 Mar 1984 11:40-EST from John G. Aspinall <JGA>


Maybe you already copied the files into a new AR3:, since reading and
writing files there works fine for me.
\1f
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Fri 9-Mar-84 02:41:11-EST
Return-path: <Moon@SCRC-TENEX>
Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 24-Jan-84 16:54:39-EST
Received: from SCRC-EUPHRATES by SCRC-YUKON with CHAOS; Tue 24-Jan-84 16:43:46-EST
Date: Tuesday, 24 January 1984, 16:54-EST
From: David A. Moon <Moon at SCRC-TENEX>
Subject: The MC chaosnet ARPA server
To: GZ at MIT-OZ
Cc: CStacy at MIT-MC, Moon at SCRC-TENEX
Redistributed-to: Ian@SRI-NIC.ARPA, BUG-ITS@MIT-MC.ARPA
Redistributed-by: Moon%SCRC-TENEX@MIT-MC.ARPA
Redistributed-date: Fri, 9 Mar 84 02:33 EST

    Date: Tue 24 Jan 84 04:43-EST
    From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
    Subject: The MC chaosnet ARPA server
    To: moon@MIT-MC, cstacy@MIT-MC
    CC: gz%MIT-OZ@MIT-MC.ARPA
    
    Connecting to this nowadays closes the connection with the close text of:
    ? Internal error - NO SUCH DEVICE
    
    I think the gateway used to (sort of) work in the past.

Well, it works for me, for both FTP and FINGER.  Ah, but wait a minute,
I'm using the TCP server and you're using the ARPA server.  They're the
same program, but the contact name controls the order of trying networks.
I just looked at the source (MC:MMCM;ARPA) and if you use it as the ARPA
server it first tries TCP then if that fails tries NCP.  But NCP ain't
implemented anymore which is why you get "no such device" rather than
"destination host dead" or something of the sort.  I guess a little
restructuring of this code is called for.
\1f
Date: 9 March 1984 02:15-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Sender: GSB5 @ MIT-MC
Subject:  MIT Miraculous Levitation PDP-10
To: Ian @ SRI-NIC
cc: BUG-ITS @ MIT-MC

    Date: 8 Mar 1984  20:45 PST (Thu)
    From: Ian Macky <Ian@SRI-NIC>

    . . .
    The "internal error" was apparently due to cca's being down.
    And ML has officially gone west.

But it hasn't reached the horizon yet, so don't dyke it out of the host
tables.  Its disk has been fixed, and its processor/pager problem is
going to be worked on this weekend.  While i don't expect it to
accept incoming net connections ever, it will certainly need to reach
out and write some files.
\1f
Date: 8 Mar 1984  20:45 PST (Thu)
Message-ID: <[SRI-NIC].IAN. 8-Mar-84 20:45:34>
From: Ian Macky <Ian@SRI-NIC>
To:   BUG-ITS@MC
Subject: [DJC%MIT-OZ: no such device + no such machine]

I can't think of a better place for this to go, since I forget the
same of the server that the OZ FINGER uses...

Date: Thursday, 8 March 1984  18:03-PST
From: DJC%MIT-OZ at MIT-MC.ARPA
To:   bug-finger%MIT-OZ at MIT-MC.ARPA
Re:   no such device + no such machine
Received: from MIT-MC by SRI-NIC with TCP; Thu 8 Mar 84 18:08:06-PST

[PHOTO:  Recording initiated  Thu 8-Mar-84 8:58PM]

 MIT TOPS-20 Command Processor 5(750)-2
 End of ATTACH.CMD.7
 End of COMAND.CMD.5
@f chan@cca
[CCA-UNIX via MIT-MC]
? Internal error - NO SUCH DEVICE

[CCA-UNIX via MIT-ML]
%No response
%No path to site
@pop

[PHOTO:  Recording terminated  Thu 8-Mar-84 9:00PM]


The "internal error" was apparently due to cca's being down.
And ML has officially gone west.
\1f
Date: 7 March 1984 11:40-EST
From: John G. Aspinall <JGA @ MIT-MC>
Subject:  jga;ar3:
To: BUG-ARCDEV @ MIT-MC, ALAN @ MIT-MC

JGA;AR3: seems to have suffered in the recent archive brouhaha,
at least I get a hung job every time I try to copy into it.
Could someone knowledgeable take a look at it, and give me an
informed opinion on whether I should go into salvage mode?
\1f
Date: Sun, 4 Mar 1984  14:58 EST
Message-ID: <ALAN.11996714138.BABYL@MIT-OZ>
From: Alan Bawden <ALAN%MIT-OZ@MIT-MC.ARPA>
To:   DCP@MIT-MC, BUG-ITS@MIT-MC
Cc:   BUG-OZ@MIT-MC, "Devon S. McCullough" <DEVON@MIT-MC>
Subject: %TPC.C
In-reply-to: Msg of 4 Mar 1984  00:00-EST from Devon S. McCullough <DEVON at MIT-MC>

    Date: Sunday, 4 March 1984  00:00-EST
    From: Devon S. McCullough <DEVON at MIT-MC>
    To:   BUG-OZ at MIT-MC
    Re:   SET TERMINAL ETX-IS-^C

    Date: 3 March 1984 20:50-EST
    From: David C. Plummer <DCP @ MIT-MC>
    To: DEVON @ MIT-MC
    cc: BUG-MINITS @ MIT-MC
        Date: 3 March 1984 17:56-EST
        From: Devon S. McCullough <DEVON @ MIT-MC>
        ^\ ^C should toggle a flag (that gets reset when you close a
        connection) that interchanges ^C and ^Z on the keyboard so I don't
        have to do this manually.
    Alternatively, you could hack the 20X monitor to do the same thing...

Hey, we could hack ITS to do this too.  ITS already has a similar hack for
exchanging "[" and "]" with "(" and ")".  I bet we could even do it right.

(There is at least one reasonable alternative to simply swapping ^Z and ^C
at the lowest level of input.  That is to simply have a way to move the
CALL key from ^Z to ^C.  Then you would want ^_^C to be the way to type a
^C, except that that already has a meaning I think...)
\1f
Date: 2 March 1984 12:58-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: KLOTZ @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 1 Mar 1984 22:29-EST from Leigh L. Klotz <KLOTZ>

    Date: 1 March 1984 22:29-EST
    From: Leigh L. Klotz <KLOTZ>
    To:   BUG-ITS

    WHAT IS SYS2;TS LINE?  It was written 9/5/77, and just says it's
    a PDUMP file.  I did :LINE instead of :LINK.  It printed
     Guess What!!??
     Your program has just gone off into HYPERSPACE!^G
    Of course, it was disowned.

It's appears to be a wholine program of some sort, but I don't know
what the message means or where the source is.
\1f
Date: 1 March 1984 22:52-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  MC woes: PACK NOT BAWDENIZED
To: CENT @ MIT-MC, CSTACY @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC,
    JPG @ MIT-MC, KMP @ MIT-MC, Moon @ SCRC-TENEX
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of Thu 1 Mar 84 17:02 EST from David A. Moon <Moon%SCRC-TENEX at MIT-MC.ARPA>

OK, using Moon's new routine in DUMP I have repaired the damage I caused
last night.  I used the incremental dump of Feb. 28 to reset the reference
dates of all files to their state as of that dump.  Thus currently no file
on MC has a reference date later than 2/28/84 (although many of them have
in fact been written since then).

I can't think of any way that this situation can screw up except the
following: someone who hadn't touched a file in a long time until
yesterday, and who continues not to touch it for some time in the future
will have his file migrate just a little sooner than he might expect.  I
don't know of any other program, besides DUMP, that uses the reference date
for anything important.
\1f
Date: 1 March 1984 22:29-EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To: BUG-ITS @ MIT-MC

WHAT IS SYS2;TS LINE?  It was written 9/5/77, and just says it's
a PDUMP file.  I did :LINE instead of :LINK.  It printed
 Guess What!!??
 Your program has just gone off into HYPERSPACE!^G
Of course, it was disowned.
\1f
Date: 1 March 1984 15:06-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  archives
To: FILE-R @ MIT-MC, CSTACY @ MIT-MC
cc: MEYER @ MIT-MC, LPH @ MIT-MC, BUG-ITS @ MIT-MC

MEYER;AR0 TODO and LPH;AR31 MACSYM are both broken archives, they should be
restored from backup tape.  (This was caused by the installation of a
broken archive device the other day.)  I have renamed them to MEYER;XAR0 TODO
and LPH;XAR31 MACSYM because I believe I have seen COMSAT trying to
reference them both, which makes trouble.  They seem to be unsalvageable,
but I didn't delete them in case someone knows something I don't.
\1f
Date: Wed 29 Feb 84 23:28:59-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Archives
To: bug-its@MIT-MC

I at one point started a massive rewrite of arcdev
to finish the problem that it cannot detect 'disk full'
until after the user has closed the file,
but I never finished it because it proved hairier than I had expected.
-------
\1f
Date: 29 February 1984 18:56-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC

I spoke with CStacy on the phone and he told me some bits I didn't have.

He saved the old arc device as DEVICE;OLD ARCDEV. It was built from
AI: SYSENG; ARCDEV 66, which is earlier than the oldest source (68) on
MC: SYSENG; ... the implication being that MC: SYSENG; ARCDEV 68,
although it has been around for 5 years, has never been compiled and/or
tested.

I re-installed DEVICE;OLD ARCDEV and things seem to work.

CStacy had me patch MAPARC+6 to have a CAILE instead of a CAIL and redump
it, but for some reason that didn't work. That may either be because I
redumped it incorrectly or because the change is not as harmless as you
would think.

My testing may also have been confused by the fact that I had a couple of
trashed archives.

In any case, the state I am leaving this all in is that DEVICE;OLD ARCDEV
(with no patches of any kind) has been replaced into DEVICE;JOBDEV ARC
so that things are as they were yesterday and for the last several years.

System people can start over again on their patches. Please stick around
and test these things next time, though, so we aren't all stuck with broken
archives. I have one archive which was enough screwed up by the experimental
thing that was released earlier that I am having to retrieve an old copy
of it from backup tape.
\1f
Date: 29 February 1984 18:29-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC

Being suspicious that these archive problems were caused by the recent
recompilation of ARCDEV, I recompiled the older version and installed
it but the same problem occurs in that version. Someone should really
look at this problem soon; I've made a real mess of some of my archives
in all this testing. I'm reinstalling the new ARCDEV since it seems to
not be the culprit.
\1f
Date: 29 February 1984 18:07-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC

Archives are just completely broken. Try copying something into one and
see if it works.
\1f
Date: 29 February 1984 10:59-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-DDT @ MIT-MC
cc: BUG-ITS @ MIT-MC

SYS4^F clears the screen and types NON-DIRECTORY DEVICE.
Shouldn't this give a no such directory error? I assume
DDT or ITS is somehow stripping the 4 and assuming I'm
trying to reference the SYS device. My file defaults end
up with SYS4: in them...
\1f
Date: 29 February 1984 01:10-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: GSB @ MIT-MC
cc: BUG-ARCDEV @ MIT-MC
In-reply-to: Msg of 29 Feb 1984 00:03-EST from Glenn S. Burke <GSB>

I installed your ARCDEV fix in the source and on MC.
\1f
Date: 29 February 1984 00:03-EST
From: Glenn S. Burke <GSB @ MIT-MC>
To: BUG-ARCDEV @ MIT-MC

The location 665 in the arc job device, whatever that is, should use CAILE
instead of CAIL.  I haven't looked at the source, but it's lossage was
apparent and i had to patch this on ml to keep from irretrievably losing
some stuff...
\1f
Date: 26 Feb 1984  18:48 PST (Sun)
Message-ID: <[SRI-NIC].IAN.26-Feb-84 18:48:28>
From: Ian Macky <Ian@SRI-NIC>
To:   Leigh L. Klotz <KLOTZ@MIT-MC>
Cc:   BUG-ITS@MIT-MC
In-reply-to: Msg of 26 Feb 1984  18:44-PST from Leigh L. Klotz <KLOTZ at MIT-MC>

    The LNKEDP call loops on HS: devices, or seems to when called from EMACS.

I was (and still am) extremely ignorant about job devices... it's more
surprising that it works at all.  I'll look at it...
\1f
Date: 26 February 1984 21:44-EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To: BUG-ITS @ MIT-MC

The LNKEDP call loops on HS: devices, or seems to when called from EMACS.
\1f
Date: 23 February 1984 15:26-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  DNRF
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC
In-reply-to: Msg of 22 Feb 1984 22:33-EST from Alan Bawden <ALAN>

    Date: 22 February 1984 22:33-EST
    From: Alan Bawden <ALAN>
    To:   KMP
    cc:   BUG-ITS, CSTACY, JPG
    Re:   DNRF
    In-reply-to: Msg of 22 Feb 1984 18:16-EST from Kent M Pitman <KMP>

        Date: 22 February 1984 18:16-EST
        From: Kent M Pitman <KMP>
        Shouldn't it be the case that deleting a file on the DNRF: device
        should err with WRONG TYPE DEVICE? ...

    We could only do this half-way really.  We could "fix" DELETE to barf at
    seeing DNRF, but to make DELEWO barf would require making the channel
    remember that it was opened in this mode (a DNRF channel becomes a DSK
    channel after opening).  Since GSB protests, I suggest we put this idea to
    sleep.

I wasn't worried about DELEWO. Just DELETE (mostly accidental \ f
or :DELETE; maybe I should have just suggested DDT watch for this). 
In any case, since everyone thinks it's a bad idea, I won't push it.
\1f
Date: 23 February 1984 01:17-EST
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: DNRF
To: KMP @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC

As long as there is all this mail on the subject ...
I fully agree with GSB, and that we should leave things as they are.
\1f
Date: 23 February 1984 00:17-EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: DNRF
To: ALAN @ MIT-MC
cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC

I agree that things are better left as they are, lest we open Pandora's
can of worms.  I would point out that not only RENMWO, but DSKUPD, RESRDT
and SRDATE "need to be fixed".

The "right way" to achieve the functionality desired by KMP is through
CAMEXEC-style translations, which have separate bits for all of the file
operations: read, write, modify, append, delete, rename, and make link.
Unfortunately, even CAMEXEC has no facility for prohibiting DELEWO, RENMWO,
or MLNKWO (make link while open), on a properly opened channel.  Obviously,
ITS jobdevs could be invented which either ignore these operations or generate
IOCERRORs if they are attempted.
\1f
Date: 22 February 1984 22:33-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  DNRF
To: KMP @ MIT-MC
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC
In-reply-to: Msg of 22 Feb 1984 18:16-EST from Kent M Pitman <KMP>

    Date: 22 February 1984 18:16-EST
    From: Kent M Pitman <KMP>
    Shouldn't it be the case that deleting a file on the DNRF: device
    should err with WRONG TYPE DEVICE? ...

We could only do this half-way really.  We could "fix" DELETE to barf at
seeing DNRF, but to make DELEWO barf would require making the channel
remember that it was opened in this mode (a DNRF channel becomes a DSK
channel after opening).  Since GSB protests, I suggest we put this idea to
sleep.
\1f
Date: 22 February 1984 22:23-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  \e\e\ f?
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
In-reply-to: Msg of 22 Feb 1984 17:47-EST from Christopher C. Stacy <CSTACY>

    Date: 22 February 1984 17:47-EST
    From: Christopher C. Stacy <CSTACY>
    Trying to rename DNRF: to DSK: on same directory gets me
    CANT RENAME TO ANOTHER DIRECTORY.

If you do :CALL RENAME you will find that this can't possibly be an ITS
bug.  If you were using DDT, then it is DDT's problem.
\1f
Date: 22 February 1984 21:32-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: delete an error on DNRF
To: KMP @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC, JPG @ MIT-MC

Yes, i disagree, because i sometimes use DNRF: as the default device when
i do hand "gfring", in which i examine potentially deletable files.
\1f
Date: 22 February 1984 18:16-EST
From: Kent M Pitman <KMP @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC, KMP @ MIT-MC

Shouldn't it be the case that deleting a file on the DNRF: device
should err with WRONG TYPE DEVICE? This would be handy since mostly
I reference files on DNRF: exactly because I want to not bother them
and if I have left my file defaults set to DNRF: it might have been
by accident. I generally read others' files with DNRF: and would be
happy knowing that this also provided greater protection against 
accidentally deleting them. I consider having to type ^O DSK:
to delete such a file after viewing it with DNRF: to be a small price
to pay for the change.

Does someone disagree strongly with this argument?
-kmp
\1f
Date: 22 February 1984 17:47-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Trying to rename DNRF: to DSK: on same directory gets me
CANT RENAME TO ANOTHER DIRECTORY.
\1f
Date: 18 February 1984 03:48 EST
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

In SYSTEM;INET 108 I added the missing instruction whose
absence caused all that ICMP spewage on MC's system console yesterday.
Someone should reassemble the system some time.  I guess it's not urgent
since TCP/IP has been in use for over a year and as far as I know this
only happened once.
\1f
Date: 18 February 1984 00:51 EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: new $$^F loses
To: BUG-ITS @ MIT-MC

it's a pain to have to type $$1^F all the time when i'm used to typing 
plain $$^F. also, it doesn't make filenames sticky anymore, another
large pain.
\1f
Date: 14 February 1984 22:11 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  LOGOUT TIMES
To: WEISS @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 14 Feb 1984 15:35 EST from Paul G. Weiss <WEISS>

    Date: 14 February 1984 15:35 EST
    From: Paul G. Weiss <WEISS>
    After logging out at 15:33EST, my logout time was set to
    14:16:03, as indicated by finger.

Well, generally it takes a couple of minutes for this information to make
it into the database of logout times.  How long did you wait after logging
out before checking?  (Since it is not real important that this information
be up-to-the-minute accurate, it is processed by a demon that only wakes up
occasionally.)
\1f
Date: 14 February 1984 15:35 EST
From: Paul G. Weiss <WEISS @ MIT-MC>
To: BUG-ITS @ MIT-MC

After logging out at 15:33EST, my logout time was set to
14:16:03, as indicated by finger.
\1f
Date: 13 February 1984 17:59 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: conjecture about "TCP bugs"
To: EAK @ MIT-MC
cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, CSTACY @ MIT-MC,
    DEVON @ MIT-MC

    Date: 13 February 1984 13:56 EST
    From: Earl A. Killian <EAK @ MIT-MC>
    In-reply-to: Msg of 13 Feb 1984 02:48 EST from Ken Harrenstien <KLH>

    I cannot usually use MC for more than about 5 minutes without
    my connection wedging.  This is from S1-C, a 4.1bsd 750 Unix with
    BBN TCP.  Basically output just stops though input seems to get
    through for a little while.

The BBN VAX TCP is known to have bugs, especially under any kind of load.
However, if you are willing to reproduce this at a specific time, I can
log the traffic and thereby identify the problem.
\1f
Date: 13 February 1984 15:26 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  [kmp at MIT-MC: ITS primitive devices]
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, KMP @ MIT-MC
In-reply-to: Msg of 13 Feb 1984 13:36 EST from Alan Bawden <ALAN>


    Date: 13 February 1984 13:36 EST
    From: Alan Bawden <ALAN>
    Double Hmmm...  Try :LISTF TCP: vs. :LISTF CHAOS:.  Perhaps CHAOS: really
    \does/ belong in that table after all...

I think you are right - so I added the CHAOS device to DEVTAB, accordingly.
IPQ is for Internet datagrams; I believe it is part of the internals
of the not-completely-implemented datagram service feature.
\1f
Date: 13 February 1984 13:56 EST
From: Earl A. Killian <EAK @ MIT-MC>
Subject:  conjecture about "TCP bugs"
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC
In-reply-to: Msg of 13 Feb 1984 02:48 EST from Ken Harrenstien <KLH>

I cannot usually use MC for more than about 5 minutes without
my connection wedging.  This is from S1-C, a 4.1bsd 750 Unix with
BBN TCP.  Basically output just stops though input seems to get
through for a little while.
\1f
Date: 13 February 1984 13:36 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  [kmp at MIT-MC: ITS primitive devices]
To: KMP @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of Sun 12 Feb 84 21:38 EST from Christopher C. Stacy <CStacy at MIT-MC.ARPA>

[ KMP asked where he could find a list of all of ITS's built-in devices.  I
  told him to look at the table of sixbit names starting at DEVTAB. ]

Hmmm...  Actually that table doesn't include CHAOS:, presumably because
that table is used by OPEN and you can only open a CHAOS: channel using
CHAOSO.  But then TCP: \is/ in that table despite the fact that you have to
use TCPOPN to open it.

Double Hmmm...  Try :LISTF TCP: vs. :LISTF CHAOS:.  Perhaps CHAOS: really
\does/ belong in that table after all...
\1f
Date: 13 February 1984 08:09 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-HOST @ MIT-MC, BUG-HSTLOK @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-NETWRK @ MIT-MC

I doubt anyone is actually on a list for this program, but
the news is that HSTLOK has been renamed to HOST (to match its
binary name) and revised to work on TNX as well as ITS.
Some fixes to NETWRK were necessary.  New source in SYSEN1;HOST and
SYSENG;NETWRK.
\1f
Date: 13 February 1984 02:48 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: conjecture about "TCP bugs"
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, DEVON @ MIT-MC

All I can say is that it is probably something specific to TACs,
because I don't get that kind of screwage from host-to-host
connections (either Unix or 20X).  The TAC software changes
every now and then, and was definitely broken at some points
(see the Internet monthly report).  However, to really PROVE
TAC lossage, it needs to be spied on while it is actually
happening.  If anyone is able to easily reproduce the problem
then it should be possible to easily figure out who is at fault.
\1f
Date: 12 February 1984 11:45 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: conjecture about "TCP bugs"
To: BUG-ITS @ MIT-MC
cc: BUG-TCP @ MIT-MC, DEVON @ MIT-MC


Sometimes when using a Chaosnet connection (like a MINITS HUB) I have
felt a distrubance in the force, as if thousands of words were crying
out -- and then suddenly shuffled.

The symptom is that there are long delays with no TTY service, making
users think the system has crashed.  Just now I was using a TAC for
the first time in months, and when it happened it was extremely
intrusive and scary.

I wonder if it is ITS that is "broken" rather than anything in the
TCP stuff.  This might explain those "TCP bugs" people are always
reporting. Maybe something about the way the TCP code works makes
the problem more noticable to TAC users.

Oh, well. Something to watch out for.
Maybe I will put in something to let me check for it.
\1f
Date: 8 February 1984 18:18 EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC dropped my arpa connection three times in 20 minutes today.  grump.
\1f
Date: 3 Feb 1984  09:09 PST (Fri)
Message-ID: <[SRI-NIC].IAN. 3-Feb-84 09:09:11>
From: Ian Macky <Ian@SRI-NIC>
To:   David C. Plummer <DCP@MIT-MC>
Cc:   BUG-ITS@MIT-MC, GREN@MIT-MC
Subject: Strange Happenings
In-reply-to: Msg of 2 Feb 1984  21:55-PST from David C. Plummer <DCP at MIT-MC>

Other direcectories were OK.  I looked at .TEMP.; and GREN;, and
maybe one or two others and they were all fine.
\1f
Date: 3 February 1984 03:41 EST
From: Glenn S. Burke <GSB @ MIT-MC>
Sender: GSB5 @ MIT-MC
Subject: mc wedgitude
To: BUG-ITS @ MIT-MC

The DL10 wedges with the par err light on.  The one time i took a good
look, none of the address lights were lit.  Experimentation shows
that this is at least not directly a function of the mf10 memories in
cabinets E and F.  The states of most other lights on the dl10 are
recorded in the log book;  i am not going to walk up the stairs again
this morning to either get them, or boot the machine.

In the no doubt useless hope that this has something to do with the
memories, the NITS dump was patched so that addresses 1000000-2000000
are out.  Note that the address switches of the mf10s seem to have
been rearranged:  the cabinets are all at monotonically increasing
addresses from left to right now.

An earlier spaz of parity errors (i don't know if it's related at all)
had 2 or 3 from mf10 E, and about 6 from somewhere high up in the ampex,
according to the printout on the system console.
\1f
Date: 3 February 1984 00:55 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: Strange Happenings
To: GREN @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 2 February 1984 20:18 EST
    From: Ian Macky <GREN @ MIT-MC>

    A few minutes ago MC was acting rather strange.  Any refernce to the
    .MAIL.; directory would hang you - either trying to write a file
    (:MAIL hung), or list the directory ^F (or :P D), or anything else.
    At the same time, KJB's BABYL fork couldn't be killed.  His DDT
    would hang on the :KILL and not return.  It just now stopped and
    all seems well, so I don't have any more information.  What might
    have caused it?
Were all the other directories accessable.  I have seen this
before when the directory cache becomes full and each entry is
unflusable for some reason.  I have seen both solutions to this:
the system sooner or later unwedges, or it doesn't requiring
reload. You may not have been able to kill KJB's babyl because it
needed to update something in the file system (close a file,
perhaps?)

I'm a bit surprised .MAIL. didn't work.  When I saw this
behavior, most of the SYS directories worked, and sometimes
.TEMP., and usuall a couple directories of people logged in.
\1f
Date: 2 February 1984 20:18 EST
From: Ian Macky <GREN @ MIT-MC>
Subject: Strange Happenings
To: BUG-ITS @ MIT-MC

A few minutes ago MC was acting rather strange.  Any refernce to the
.MAIL.; directory would hang you - either trying to write a file
(:MAIL hung), or list the directory ^F (or :P D), or anything else.
At the same time, KJB's BABYL fork couldn't be killed.  His DDT
would hang on the :KILL and not return.  It just now stopped and
all seems well, so I don't have any more information.  What might
have caused it?
\1f
Date: 2 February 1984 01:34 EST
From: David A. Moon <MOON5 @ MIT-MC>
Subject: Meter hardware on MC
To: BUG-ITS @ MIT-MC
cc: Moon @ SCRC-TENEX

DATAI 24,n executed in user mode clobbers locations n and n+1 in the system!
It's a good thing I tested this by hand before writing a program to use it.
ITS executes the instruction with XCTR, as it should.  I suspect this is
a bug in the microcode.  I guess I'll use .suset [.rrunt,, like a good little boy.
\1f
Date: 1 Feb 1984  20:43 EST (Wed)
Message-ID: <MARTY.11988388336.BABYL@MIT-OZ>
From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
To:   bug-its@MIT-MC
Subject: [GLR: bad mail from ML]

Date: Wednesday, 1 February 1984  18:55-EST
From: Jerry Roylance <GLR>
To:   BUG-MAIL
Re:   bad mail from ML

Got some bad format mail from ML -- no FROM:.


^_\f
1, bad-header,,
*** EOOH ***
Received: from MIT-ML by MIT-OZ via Chaosnet; 31 Jan 84 21:39-EST
TIM@MIT-ML 01/31/84 21:39:15
To: glr at MIT-OZ
Where might I be able to find information on the RS-422 standard?
^_\f
\1f
Date: Wed, 1 Feb 84 05:14 EST
From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
Subject: more loose ends in ITS network support?
To: Ken Harrenstien <KLH@MIT-MC.ARPA>
Cc: KMP@MIT-MC.ARPA, MOON%SCRC-TENEX@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA,
    BUG-ITS@MIT-MC.ARPA
In-reply-to: The message of 31 Jan 84 16:08-EST from Ken Harrenstien <KLH at MIT-MC>

CHAOSO and TCPOPN now behave a little more like OPEN.
If these calls lose after arg checking (ie., channel numbers in
range), for example if they want to say %EFLDV, that the error code
will make it into the IOCHST word of the input channel.

I removed the ISE0 crock for TCP from NETWRK's ANALYZ code, and
reassembled TELNET, SUPDUP, and NAME.  There should be no more random
"Could not connect to foreign host with TCP messages" coming out
anymore from either Chaosnet (!) or Internet programs.

Installed on MC.

Chris
\1f
Date: 30 January 1984 22:52 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  Chaosnet connections
To: BUG-ITS @ MIT-MC
cc: KMP @ MIT-MC

In ITS 1362 on MIT-MC:

Lately MC frequently gets into a state where all CHAOSO calls fail
with DEVICE FULL.  I increased the number of Chaosnet indices from 32.
to 50., because there were 16/32 buffers free, and lots of pending
RFCs and confused users.  I hope this is the correct fix, and that
GCing of something or other is not broken.
\1f
Date: 29 January 1984 09:09 EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject: EMACS echo area
To: DEVON @ MIT-ML
cc: BUG-ITS @ MIT-ML
In-reply-to: Msg of 01/22/84 17:17:46 from DEVON at MIT-ML

If you use the EMACS variable Echo Area Height instead of the raw flag
FS Echo Lines your problems will be over.


\1f
Date: 28 January 1984 19:53 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  _LSPM_ OUTPUT
To: WGD @ MIT-MC
cc: BUG-ITS @ MIT-MC, GZ @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX
In-reply-to: Msg of 28 Jan 1984 19:30 EST from William G. Dubuque <WGD>

    Date: 28 January 1984 19:30 EST
    From: William G. Dubuque <WGD>
        Date: 27 January 1984 17:03 EST
        From: Alan Bawden <ALAN>
            Date: 27 January 1984 08:06 EST
            From: Bill Gosper <RWG>
            BIL@mc and rwg@Russian tried to write out gz;grob > at about the
            same time....
        What program was BIL using on MC?  One possible theory is that he
        was using a program that did something incompetent.  Better
        possibility (says Moon standing right behind me) is that RWG's file
        server got and error that he somehow never saw.
    I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file.
    As GZ mentioned, there was a _LSPM_ OUTPUT file laying around for
    awhile after my version was written.

OK, so now we know that it was the file being written by the file server
that never made it.  Sounds like RWG was screwed by his Lisp machine not
telling him about an error.  Since we are now certain that this is not an
ITS problem, or a problem with some non-lispmachine software, the next
person to send mail on this subject should please delete BUG-ITS from the
header.
\1f
Date: 28 January 1984 19:30 EST
From: William G. Dubuque <WGD @ MIT-MC>
Sender: BIL @ MIT-MC
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, GZ @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX
In-reply-to: Msg of 27 Jan 1984 17:03 EST from Alan Bawden <ALAN>

    Date: 27 January 1984 17:03 EST
    From: Alan Bawden <ALAN>
    To:   RWG
    cc:   BIL, BUG-ITS, GZ, bug-lispm at SCRC-TENEX

        Date: 27 January 1984 08:06 EST
        From: Bill Gosper <RWG>
        BIL@mc and rwg@Russian tried to write out gz;grob > at about the
        same time....

    What program was BIL using on MC?  One possible theory is that he was using
    a program that did something incompetent.  Better possibility (says Moon
    standing right behind me) is that RWG's file server got and error that he
    somehow never saw.
I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file. As GZ
mentioned, there was a _LSPM_ OUTPUT file laying around for awhile
after my version was written. I take it there are no known (a)synchronization
problems that could be at the heart of this?
Whatever the error someone should be responsible for making it know to the
writer who loses since, of course, a lot could be lost this way.
\1f
Date: 27 January 1984 17:03 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: RWG @ MIT-MC
cc: BIL @ MIT-MC, BUG-ITS @ MIT-MC, GZ @ MIT-MC, bug-lispm @ SCRC-TENEX
In-reply-to: Msg of 27 Jan 1984 08:06 EST from Bill Gosper <RWG>

    Date: 27 January 1984 08:06 EST
    From: Bill Gosper <RWG>
    BIL@mc and rwg@Russian tried to write out gz;grob > at about the
    same time....

What program was BIL using on MC?  One possible theory is that he was using
a program that did something incompetent.  Better possibility (says Moon
standing right behind me) is that RWG's file server got and error that he
somehow never saw.
\1f
Date: 27 January 1984 08:06 EST
From: Bill Gosper <RWG @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: GZ @ MIT-MC, BIL @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX

BIL@mc and rwg@Russian tried to write out gz;grob > at about the
same time.  Russian paused about a minute in File Finish, but seemed to
return from the m-X Copy File normally (RWG had typed ahead
a c-and a few chars, but no aborts or anysuch.)  Only BIL's version
made it into gz;.  GZ herself reported seeing an open file linger
there for a few minutes and then disappear.
\1f
Date: 23 January 1984 14:30 EST
From: Christopher C. Stacy <CHRIS @ MIT-MC>
To: USER-ACCOUNTS @ MIT-MC
cc: BUG-ITS @ MIT-MC

I had to reload the password database again; apparently there is
a reproducible way to crash ITS and corrupt this file.
Changes to the database made before 1/20 have been lost.{
\1f
Date: Mon, 23 Jan 84 02:28 EST
From: David Vinayak Wallace <Gumby@MIT-MC.ARPA>
Subject: I may be a loser, but...
To: "David A. Moon" <MOON@MIT-MC.ARPA>
Cc: BUG-ITS@MIT-MC.ARPA
In-reply-to: The message of 22 Jan 84 23:58-EST from David A. Moon <MOON at MIT-MC>

    Date: 22 January 1984 23:58 EST
    From: David A. Moon <MOON @ MIT-MC>
        Date: Sunday, 22 January 1984, 07:39-EST
        From: David Vinayak Wallace <Gumby at MIT-MC>
        MC died very strangely tonight.  The IO bay and processor were frozen,
        but the memory and the ampex were happily flashing their lights as if
        nothing was wrong.  There was a red NXM light illuminated on the
        processor bay (I didn't know there was such a light!).

    There isn't.  You must have mistaken something else for the processor;
    perhaps the DL10...
I'm a loser.  It was the DL10.

    I wasn't able to figure out from that dump file how the system crashed.
    I suspect the answer is that it didn't!  I also wasn't able to figure
    out how you stopped it or what command you used to dump it out (there
    weren't any symbols for some reason).

I halted it with break, then used \eY in ddt to make the dump.

I assumed MC had died because:
Neither the decscribbler nor the vt52 would respond to ^Z.
You could not open a connection over arpa or chaos (I tried status,
file, and supdup).
Existing arpa, chaos, and dialup connections hung.

Since you couldn't talk to it, I assumed it had crashed.  The front-end
was running fine, as I could wake it up with break.

Perhaps this can help.

david
\1f
Date: 22 January 1984 23:58 EST
From: David A. Moon <MOON @ MIT-MC>
Subject: mc spills her cookies?
To: GUMBY @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST
    Date: Sunday, 22 January 1984, 07:39-EST
    From: David Vinayak Wallace <Gumby at MIT-MC>
    Subject: mc spills her cookies
    To: bug-its at MIT-MC

    MC died very strangely tonight.  The IO bay and processor were frozen,
    but the memory and the ampex were happily flashing their lights as if
    nothing was wrong.  There was a red NXM light illuminated on the
    processor bay (I didn't know there was such a light!).

There isn't.  You must have mistaken something else for the processor;
perhaps the DL10, which is the wide bay over near the T-300 disk drives
(between them and the tape drive).  It's a pdp11-to-memory interface.
Or it could have been the DF10, on the left-hand end of the row of 8
memory bays; it's a disk-to-memory interface.  As I recall, both have
red NXM lights.

    I put a crash dump in CRASH MEMPAR (since MC had been getting parity
    errors just before the crash), but since I cleverly neglected to record
    the state of the processor lights, it's probably useless.

I wasn't able to figure out from that dump file how the system crashed.
I suspect the answer is that it didn't!  I also wasn't able to figure
out how you stopped it or what command you used to dump it out (there
weren't any symbols for some reason).

It has been getting parity errors; I think the Ampex memory is turning
to shit (or has been shit all along).
\1f
Date: 22 January 1984 23:42 EST
From: David A. Moon <MOON @ MIT-MC>
Subject: MC crash at 5pm today, dumped to crash;pagfau 1/22/8
To: BUG-ITS @ MIT-MC, Hornig @ SCRC-TENEX

Fixed in the source and patched in both the running system and the
dump.  When copying a Chaosnet packet into an Internet packet buffer,
it was erroneously using the length of the destination rather than
the length of the source as the length of the transfer; since the
source was shorter it ran off the end of wired memory and took an
exec page fault.
\1f
DEVON@MIT-ML 01/22/84 17:17:46
To: (BUG ITS) at MIT-ML
This is a longstanding "feature" which is probably actually a bug.
When I detach my tree, the info about the echo area is lost, so
that if I reattach and continue an EMACS, it has forgotten about
the echo area on the screen.  Apparently this only happens if I
was actually in EMACS when I was detached (by call waiting) so
I tried the following experiment:

:tctyp printing nosupdup
emacs$j
^Z
:tctyp software

will clobber EMACS' echo area, even though the only thing typed at it
while TCTYP was zero was a ^Z, but

:tctyp printing nosupdup
:tctyp software

has no ill effect.  I can always fix the echo area with the TECO command
FS ECHO LINES$FS ECHO LINES$$ (restarting from DDT with $G clobbers the
line saving info) but it really looks like an ITS bug to me..
\1f
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST
Date: Sunday, 22 January 1984, 07:39-EST
From: David Vinayak Wallace <Gumby at MIT-MC>
Subject: mc spills her cookies
To: bug-its at MIT-MC

MC died very strangely tonight.  The IO bay and processor were frozen,
but the memory and the ampex were happily flashing their lights as if
nothing was wrong.  There was a red NXM light illuminated on the
processor bay (I didn't know there was such a light!).

I put a crash dump in CRASH MEMPAR (since MC had been getting parity
errors just before the crash), but since I cleverly neglected to record
the state of the processor lights, it's probably useless.

david
\1f
Date: 19 January 1984 16:20 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: KMP @ MIT-MC, ED @ MIT-MC

Sometimes you are running some program and type ahead something you
didn't really want.  Perhaps when that typeahead is read it will flush
valuable typeout on your screen, and perhaps also ^Z would have
similar unwanted effects.  Suppose you just wanted flush whatever
pending typein there is.

There is now a new BACKNEXT command: ^_^U is CLEAR INPUT.
This flushes your TTY input buffer, very similar to if 
a .RESET had been done at it.  

It's in the source and patched in the running ITS.  Minor bug: I am
not entirely sure how to get the ^U to echo, will look at this with
MOON later on this week or something.

So, you can do things like this:

:LISP
*
(SLEEP 6.)FOOBAR ^_^U         ;typein cancelled before finished nap
T                             ;the "foobar " was thrown away.



Stay tuned for more exciting news...
\1f
Date: 15 January 1984 22:10 EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To: BUG-ITS @ MIT-MC

I was using ITS at the time KMP noted the crash.  I don't know if this
was referring to my tty buffer or if this happened to others, but I was using
EMACS at the time and all of a sudden got a logout message at the
cursor position.  Thereafter after each keystroke I got three more characters.
I also got the following BYE message, but unfortunately the nick-name of
the person ran off the edge of the screen.  I kept pressing keys and
getting more characters until I eventually got nothing, and then it
hung up.
\1f
Date: 15 January 1984 18:38 EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  MC crashed in tty code (TYOOU1+5; buffer ptr past eob)
To: BUG-ITS @ MIT-MC

In ITS in NEX 342, Emacs 162, Teco 1171, ITS 1359 on MIT-MC:

ITS stopped with he following message:
 TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER
The PC was TYOOU1+5.
I dumped this to CRASH;TYOOU1 +5
and reloaded.
\1f
Date: 12 January 1984 05:24 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: RWG @ MIT-MC
cc: BUG-ITS @ MIT-MC, DCP @ MIT-MC, REM @ MIT-MC

I suspect REM's problems have more to do with the TAC than with MC.
I use MC every day via the net, from SRI-NIC, and response seems
pretty good to me.  I wonder if other TAC users have the same problems
(whatever they are).
\1f
Date: 12 January 1984 01:44 EST
From: David C. Plummer <DCP @ MIT-MC>
To: RWG @ MIT-MC
cc: BUG-ITS @ MIT-MC, DCP @ MIT-MC, REM @ MIT-MC

    Date: 11 January 1984 22:58 EST
    From: Bill Gosper <RWG @ MIT-MC>

    Although DCP's patch has cured the monster hangups in MC net service,
    echoing and typing are still pathologically slow these past weeks.
    REM is similarly mistreated via the arpanet.
Gosper is a 9600 baud land line and a microwave away from MC.
Just about any traffic on the land line will cause realtime
delays.  When only a microwave link away I notice very few
hangups, and they are only for less than 1 second (I would guess
they are about .7 seconds but I can't really tell).
\1f
Date: 11 January 1984 22:58 EST
From: Bill Gosper <RWG @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: DCP @ MIT-MC, REM @ MIT-MC

Although DCP's patch has cured the monster hangups in MC net service,
echoing and typing are still pathologically slow these past weeks.
REM is similarly mistreated via the arpanet.
\1f
Date: 10 January 1984 04:45 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: KMP @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC

    Date: 9 January 1984 22:59 EST
    From: Kent M Pitman <KMP @ MIT-MC>

    Hmm. I just sent mail to BUG-FINGER asking :NAME KMP@OZ
    was replying right away with

     Could not connect to foreign host with TCP.

    but in fact, :OZ is doing this, too, so something must
    be confused with the network.

Either a host table got written out which had OZ's arpanet
address in it, or OZ was down and the NETWRK error analysis code
doesn't know how to handle it properly (maybe because it doesn't
know whether the connection attempt was using CHAOS or TCP).
I re-did the NETWRK package to report TCP errors properly, but
I don't know whether this will help or not.  I doubt many programs
have been recompiled with the new NETWRK yet.
\1f
Date: 9 January 1984 22:59 EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: BUG-NAME @ MIT-MC

Hmm. I just sent mail to BUG-FINGER asking :NAME KMP@OZ
was replying right away with

 Could not connect to foreign host with TCP.

but in fact, :OZ is doing this, too, so something must
be confused with the network.
\1f
Date: 7 January 1984 15:00 EST
From: Kent M Pitman <KMP @ MIT-MC>
Sender: KMP0 @ MIT-MC
To: BUG-ITS @ MIT-MC

MC has been getting parity errors (three in the last hour)...

 14:16:12       #5   PC = 310000,,017213, JOB# 26, USR: TORBEN L
                     ERR ADDR = 602005433716
                     PARITY ERRORS:
                        5,,433717       512500,,400

 14:41:18       #6   PC = 710000,,107117, JOB# 66, USR: GIF HACTRN
                     ERR ADDR = 602004377116
                     PARITY ERRORS:
                        4,,377117       211102,,403

 14:41:33       #7   PC = 710000,,107117, JOB# 66, USR: GIF HACTRN
                     ERR ADDR = 602004377116
                     PARITY ERRORS:
                        4,377117        211102,403

In case it matters, the machine room seems quite cool and dry
(unlike last week).
\1f
Date: 6 January 1984 02:30 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  your patch is on disk now
To: DCP @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 6 Jan 1984 02:14 EST from David C. Plummer <DCP>


You were trying to dump out a patched ITS BIN file instead of a world
load.  I don't know offhand know why this doesn't work, but I patched
the NITS world load and dumped it out as XITS.  I'll reassemble the
system tomorrow probably anyway...

\1f
Date: 6 January 1984 02:14 EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC, BUG-TWENEX @ MIT-MC
cc: CHAOS-NCP-PEOPLE @ MIT-MC, RWG @ SPA-NIMBUS

I have patched MC so that it only retransmits the first packet on
the transmit queue instead of the entire queue.  There are a few
theories that say this is a reasonable thing to do.  Its greatest
impact is on the slow links which do packet filtering to avoid
complete congestion.  

I would update the on disk version, but the
        <alt>L
        make patch
        <alt>Y
method doesn't seem to work.  (Actually, the resulting file was 7
or so blocks shorter.)  So, if somebody could update the disk
version, or make the patch each time ITS is booted, it would be
appreciated.  The patch is
        CHART2-1/ JFCL  (was JUMPN A,CHART1)
I have updated the source.

Bug-Twenex people: the equivalent source change (if the Dec 10,
1983 code on EE:LIB:<5.MONITOR>CHAOS.MAC is anywhere near correct
(OZ and SPEECH won't talk to me and I couldn't find it on XX) is
to remove the
        JRST CHART1 at CHARTD-1
and replace it with the comment
        ;; fall through, since we only retransmit one packet of the list.
This can also be patched to a JFCL if you want to test it.

Other people: You may want to do (or at least try) similar things.
\1f
Date: 4 January 1984 00:46 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 3 Jan 1984 23:35 EST from Alan Bawden <ALAN>

    Date: 3 January 1984 23:35 EST
    From: Alan Bawden <ALAN>
    To:   BUG-ITS

    What happened to the source of SYS:ATSIGN DEVICE?

The source does not seem to be online anywhere, and is not on MC's
backup tape.  I'll go looking for it on AI backup tape later on.
\1f
Date: 3 January 1984 23:35 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC

What happened to the source of SYS:ATSIGN DEVICE?
\1f
Date: 21 December 1983 04:48 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  weirdness
To: BUG-ITS @ MIT-MC, USER-ACCOUNTS @ MIT-MC
cc: BUG-PWORD @ MIT-MC


The PWORD accounts database was clobbered tonite somehow, apparently
when the system crashed due to memory parity errors.  (The DSK module
was reporting them so I assume this means it was during disk DMA.)
Apparently the file was clobbered when the system crashed, it has been
zeroed or had some pointers shuffled or something -- I haven't looked
at it yet but the file was still the correct length. I was under the
impression that this sort of thing could not happen.

USER-A people: Anyway, we got it back off of tape from Monday.

Chris
\1f
Date: 18 December 1983 12:13 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: RK @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
In-reply-to: Msg of 17 Dec 1983 12:34 EST from "Richard Kovalcik, Jr." <RK>


    Date: 17 December 1983 12:34 EST
    From: "Richard Kovalcik, Jr." <RK>
    To:   BUG-ITS, BUG-TCP
    cc:   RK

    Any reason why MC is making outgoing TCP/IP connections but 
    not accepting incoming ones? Mail is still backing up for MC
    on various sites becuase of this.
    -Rick

For a while the system was in debug mode which does this.
\1f
Date: 17 December 1983 12:34 EST
From: "Richard Kovalcik, Jr." <RK @ MIT-MC>
To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
cc: RK @ MIT-MC

Any reason why MC is making outgoing TCP/IP connections but not accepting incoming ones?
Mail is still backing up for MC on various sites becuase of this.

-Rick

P.S.  Both telnet and smtp gets resets immediately when you try to open to
them from both CISL and MIT-Multics.
\1f
Date: 15 December 1983 18:23 EST
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-WHOIS @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 8 December 1983 01:29 EST
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    To: PGS @ MIT-MC
    cc: BUG-FINGER @ MIT-MC, BUG-HOSTS @ MIT-MC
    In-reply-to: Msg of 7 Dec 1983 16:36 EST from Patrick G. Sobalvarro <PGS>

        Date: 7 December 1983 16:36 EST
        From: Patrick G. Sobalvarro <PGS>
        To:   BUG-FINGER, BUG-HOSTS

        As of today, doing :f @oz on mc get me the error message "Could not
        connect to foreign host with TCP."  Crufty, crufty lossage.

    ":F @OZ" works fine for me on MC.
    Maybe there is a bug in the ANALYZ code in the ITS NETWRK package, and
    when it could not connect to OZ over the Chaosnet it decided to give
    the most general TCP error message.

This is the second time this bug has bitten me.  ML is up right now.  On MC,
I did :whois pgs@ml.  I immediately (not long enough for a chaos connection
attempt to time out, but immediately) got the error message "Could not
connect to foreign host with TCP."  Immediately after that, it worked.
\1f
Date: 12 December 1983 07:59 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Since all the INFO stuff is on FOURTH:, I can't read documentation
that I want while the system is crippled.
\1f
Date: 10 December 1983 10:05 EST
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
Subject:  wierd
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, ITS-LOVERS @ MIT-MC
In-reply-to: Msg of 10 Dec 1983 01:50 EST from Alan Bawden <ALAN>

    Date: 10 December 1983 01:50 EST
    From: Alan Bawden <ALAN>
    To:   BUG-ITS
    cc:   ITS-LOVERS
    Re:   wierd

    Anybody have any idea where MC:SYS;FORMAT EXE came from?  (Perhaps some
    subversives are planning on bringing 20X up on MC?)

I'd bet that this was a case of someone cftping it over and saying yes to the
stupid cftp defaults.  Why the might have wanted to cftp it over, I don't
know.  Those cftp defaults have never ever been useful to me.  If cftp did
filename-merging, maybe they would be.
\1f
Date: 10 December 1983 01:50 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: wierd
To: BUG-ITS @ MIT-MC
cc: ITS-LOVERS @ MIT-MC

Anybody have any idea where MC:SYS;FORMAT EXE came from?  (Perhaps some
subversives are planning on bringing 20X up on MC?)
\1f
Date: 9 December 1983 11:37 EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject:  Weirdness...
To: EPS @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 9 Dec 1983 01:23 EST from Eric P. Scott <EPS>

You probably got a parity error.
\1f
Date: 9 December 1983 01:31 EST
From: Eric P. Scott <EPS @ MIT-MC>
Subject: Weirdness (3)
To: BUG-ITS @ MIT-MC

I :SNARFed a CHTN and got (BADPI;IOCH12;IOCH0;) 2203>>.HANG   0/  0
This just isn't my day.
                                        -=EPS=-
\1f
Date: 9 December 1983 01:28 EST
From: Eric P. Scott <EPS @ MIT-MC>
Subject: Weirdness (2)
To: BUG-ITS @ MIT-MC

(BADPI;INF0;) 135252>>TDNN 2,   2/   10000,,0   0/   0
I :PDUMPed it to USERS1;EPS DEADDT if anyone cares.

                                        -=EPS=-
\1f
Date: 9 December 1983 01:23 EST
From: Eric P. Scott <EPS @ MIT-MC>
Subject: Weirdness...
To: BUG-ITS @ MIT-MC

I got a tree detached by top-level interrupt followed by
MC ITS REVIVED.  No one else seems to have been affected.
Weird...
                                        -=EPS=-
\1f
Date: 4 December 1983 23:07 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  hanging up phone lines
To: CBF @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 4 Dec 1983 17:43 EST from Charles Frankston <CBF>


    Date: 4 December 1983 17:43 EST
    From: Charles Frankston <CBF>
    To:   BUG-ITS
    Re:   hanging up phone lines

    ITS needs better facilities for hanging up dialup lines.  Since most other
    computers nowadays automatically hangup the phone line after logout
    (either immediately or with a short timeout), I think some users don't
    realize that they have to do this manually on ITS.

    I don't believe ML has the hardware to hangup a line.  The I/O and Console
    11's on MC have the appropriate hardware but don't give the pdp10 any way
    to control the appropriate bits.

There used to be this .HANGUP UUO...maybe there should be a system
call for reading and frobbing arbitrary bits on tty lines in the pdp-11.

.HANGUP dialnum,        ANCIENT HISTORY hang up a dialed line
        ;skip if successful

        This uuo NO LONGER EXISTS.
        It is documented here for historical purposes only.
        Its function is obsolete.
        Its opcode has been recycled as .REVIVE.

        This uuo was used to hang up on a line which had
        been dialed by the .DIAL uuo.
\1f
Date: 4 December 1983 17:43 EST
From: Charles Frankston <CBF @ MIT-MC>
Subject:  hanging up phone lines
To: BUG-ITS @ MIT-MC

ITS needs better facilities for hanging up dialup lines.  Since most other
computers nowadays automatically hangup the phone line after logout
(either immediately or with a short timeout), I think some users don't
realize that they have to do this manually on ITS.

I don't believe ML has the hardware to hangup a line.  The I/O and Console
11's on MC have the appropriate hardware but don't give the pdp10 any way
to control the appropriate bits.  At worst something like to LSPEED
command could be used to hangup a line.  At best the system would use the
same sorts of timeouts it uses to close STY channels.  If I get some time
after the term I might look at the LSPEED covert channel.  Informed
suggestions on other approaches would be welcome.
\1f
Date: Friday, 2 December 1983, 00:44-EST
From: David Vinayak Wallace <Gumby at MIT-MC>
Subject: safe site ap8
To: Pandora B. Berman <CENT at MIT-MC>
Cc: TIM at MIT-MC, BUG-ITS at MIT-MC, user-a at MIT-MC
In-reply-to: The message of 2 Dec 83 00:00-EST from Pandora B. Berman <CENT at MIT-MC>

    Date: 2 December 1983 00:00 EST
    From: Pandora B. Berman <CENT @ MIT-MC>
        TIM@MIT-MC 11/29/83 05:35:55
        Hmm, MC thinks that AP8 is an "insecure" site.  Who/how does this get
        changed? 

    it's built into something. i don't know how to change, but surely someone
    else does.

I fixed this for MC and ML.
\1f
Date: 2 December 1983 00:00 EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: safe site
To: TIM @ MIT-MC
cc: BUG-ITS @ MIT-MC

    TIM@MIT-MC 11/29/83 05:35:55
    Hmm, MC thinks that AP8 is an "insecure" site.  Who/how does this get
    changed?  (it's not THAT big a deal, but it probably doesn't know about
    other relatively new machines either).

it's built into something. i don't know how to change, but surely someone
else does.
\1f
Date: 15 November 1983 03:27 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  DIR: bug
To: KMP @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 10/28/83 13:55:33
    From: KMP

    If you do c-X c-F DIR: KMP; FIRST KMP, you'll note that Emacs thinks
    this is a link to KMP; DIR: FIRST KMP ... Is it possible that DIR: is
    not handling the LNKDP system call (or whatever it's called) correctly?

It's called LNKEDP, and I just fixed DIR: to handle it properly.
Installed on MC, old version in DEVICE;JOBDEV ODIR.
\1f
Date: 15 November 1983 03:08 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  DIR device rescued
To: KMP @ MIT-MC
cc: BUG-ITS @ MIT-MC


Suffering arbitrary amounts of tedium, I just now recovered the source
code to the DIR device from DM backup tape and put it in SYSENG;.
I sure hope nothing else important was forgotten over there.

\1f
Date: 15 November 1983 03:01 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  hostat
To: SHAWN @ MIT-ML
cc: BUG-ITS @ MIT-ML
In-reply-to: Msg of 11/15/83 00:34:36 from SHAWN at MIT-ML


HOSTAT can not work anymore, since it wants to talk to DM's
host status SURVEY server.  Rewriting something similar is
on my list of things to do in my spare time.


\1f
SHAWN@MIT-ML 11/15/83 00:34:36 Re: hostat
To: (BUG ITS) at MIT-ML

ERROR: OPEN: DSK: SYSBIN; HOSTS1 > - FILE NOT FOUND
4146>>.CALL 4434 (OPEN)


\1f
Date: 10 November 1983 15:09 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  ARPA net
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC, DIGEX @ MIT-MC, KFL @ MIT-MC
In-reply-to: Msg of 10 Nov 1983 11:10 EST from Devon S. McCullough <DEVON>


I have a program called LOGN which I run when I log in.  
I will check it out and release it for you later today.
It does the right thing with TAC binary mode, also also hacks TTYLOCs.
There is another program called TBMOFF for my logout file (to turn TAC
BINARNY MODE off).

\1f
Date: 10 November 1983 11:10 EST
From: Devon S. McCullough <DEVON @ MIT-MC>
Subject: ARPA net
To: CSTACY @ MIT-MC
cc: DEVON @ MIT-MC, DIGEX @ MIT-MC, KFL @ MIT-MC, BUG-ITS @ MIT-MC

What's the correct way for a LOGIN init file to send
 IAC DO TRBIN and IAC WILL TRBIN to a TAC?

ttyopt/
:if n %Q&%TPTEL>
$(:$ do trbin $ imgout 377 375 0
  $)

works in most cases, except for the %TDQOT screw if your TCTYP is %TNSFW
since then the TAC sees a %TDQOT before every character of the IAC sequence.
I suppose I could save the value of TCTYP in DT somewhere, set TCTYP to zero,
execute the IMGOUT program and then restore TCTYP, but it's not exactly
clear to me how to do this, can it be done from DDT or must a program do it?
If so, I will just write a hacked-up version of IMGOUT called TAC which
accepts TAC commands and sends them.

Every time I vary my procedures even slightly I get screwed by %TDQOT and
TCTYP SOFT not knowing at what level to strip off the %TDQOT's...

but my solution for a :TAC Binary Output Start is still wrong, since if
the poor loser is using CRTSTY he will probably be screwed.  Perhaps
what we really need is a %TDIAC code which is simply intended for
telling TELSER to try to frob the protocol in some way.
\1f
Date: 30 October 1983 21:35 EDT
From: George J. Carrette <GJC @ MIT-MC>
To: BUG-ITS @ MIT-MC

:FIND SYSENG;HOSTS
HOSTS 666 written by CSR, beware.
\1f
Date: 30 October 1983 21:18 EDT
From: David A. Moon <MOON @ MIT-MC>
Subject: That ITS out-of-low-core bug
To: BUG-ITS @ MIT-MC

Fixed in the source.  I will come over probably some time this
week and find the subtle bugs I no doubt introduced into the system;
I wouldn't recommend trying to install the changes I made without me.
Happy Hallowe'en.
\1f
Date: 30 October 1983 18:59 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject:  ITS wedgeding
To: MOON @ SCRC-TENEX
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC,
    JPG @ MIT-MC, TAFT @ MIT-MC, KLH @ SRI-NIC
In-reply-to: Msg of 29 Oct 1983  15:59-EDT from MOON at SCRC-TENEX

    Date: Saturday, 29 October 1983  15:59-EDT
    From: MOON at SCRC-TENEX

    ... Lack of low core could not affect echoing on local terminals, and would
    only affect echoing on network terminals if there wasn't enough core to
    make network packet buffers.  Of course maybe the users were confused
    and what they really meant was that their programs were busted.

I was on just before it died. Echo time might not be the right phrase.
The slowness was of the following sort... I typed :SRCCOM ...<return>
and waited a long time but gotten no output. Echo time for that time was 
normal. I finally typed ^G and \e\eV. The \e\eV did not echo. I typed some
^G's and maybe some other frustration chars (^D?) after a while and and 
found myself in a mode where I felt like what might be happening was that
for every character I typed, a character would echo but it was out of
phase by several characters with my input. The output from the \e\eV, by the
way, indicated that the SRCCOM job had not loaded. Finally, though, 
no more input of any sort would echo, so I gave up and closed my connection.
-kmp
\1f
Date: 30 October 1983 09:20 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  RAT;
To: JPG @ MIT-MC
cc: BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, KLH @ MIT-MC,
    KMP @ MIT-MC, TAFT @ MIT-MC, moon @ SCRC-TENEX
In-reply-to: Msg of 30 Oct 1983 09:16 EDT from Jeffrey P. Golden <JPG>


No, this is all long before a HACTRN has been created.
\1f
Date: 30 October 1983 09:16 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: RAT;
To: CSTACY @ MIT-MC, moon @ SCRC-TENEX
cc: BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, KLH @ MIT-MC,
    KMP @ MIT-MC, TAFT @ MIT-MC, JPG @ MIT-MC

   Date: Saturday, 29 October 1983  16:02-EDT
   From: MOON at SCRC-TENEX
   To:   Christopher C. Stacy <CStacy at MIT-MC>
   Cc:   BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
         KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC
   Subject: ITS wedgeding
   In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
   
   Oh by the way, I forgot to mention about the job that had two disk
   channels open, where one was to "RAT;".  The mode printed by Peek C
   mode for that channel was "RU", meaning that it was reading a
   directory ("UFD").  Probably this channel really belonged to some
   other job and peek was confused.
Is the question: Why RAT; ?
If so, isn't PWORD the answer?
\1f
Date: 30 October 1983 09:08 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: MC:BACKUP;
To: BUG-ITS @ MIT-MC, MOON @ SCRC-TENEX
cc: JPG @ MIT-MC

   Date: Saturday, 29 October 1983, 22:54-EDT
   From: David A. Moon <Moon@SCRC-TENEX>
   To: Jeffrey P. Golden <JPG@MIT-MC>
   Cc: GSB@MIT-MC, BUG-ITS@MIT-MC
   The idea is to have a system there that works well enough that you
   can bring it up and run DUMP to load backup tapes.  It doesn't have
   to support networks, terminals, etc.
I agree with the idea.  But if it is to work:
[1] There should be a -READ- -THIS- file there which lists the key 
files that should be present on the BACKUP; direc.
[2] Someone should look over that directory and delete useless or 
harmful files and replace them by the necessary files so that the idea 
Dave mentions can be carried out if it should ever be necessary.
\1f
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 29-Oct-83 22:51:38-EDT
Date: Saturday, 29 October 1983, 22:54-EDT
From: David A. Moon <Moon@SCRC-TENEX>
To: Jeffrey P. Golden <JPG@MIT-MC>
Cc: GSB@MIT-MC, BUG-ITS@MIT-MC
In-reply-to: The message of 14 Oct 83 04:46-EDT from Jeffrey P. Golden <JPG at MIT-MC>

    Date: 14 October 1983 04:46 EDT
    From: Jeffrey P. Golden <JPG @ MIT-MC>
       GSB@MIT-MC 10/13/83 17:44:25 Re: MC directory slot
       BACKUP; is for backup copies of things on .; and occasionally other things.
    Why can't .; itself be used for this?  For the couple of true backup @ files, 
    which have the same names as files on .; , e.g. CRASH; would work fine.
    Or better, SYS; ?

       It should be preserved, and it does get updated occasionally.
    The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe 
    almost everything there is garbage.  If BACKUP; were trully for backup 
    then leaving non-working stuff on that directory as is now the case 
    may be hazardous for MC's health if ever invoked.

       I believe that it has proven itself useful on ML at least.
    I see no recent proof of this for MC:BACKUP; .

The idea is to have a system there that works well enough that you
can bring it up and run DUMP to load backup tapes.  It doesn't have
to support networks, terminals, etc.
\1f
Date: Saturday, 29 October 1983  16:02-EDT
From: MOON at SCRC-TENEX
To:   Christopher C. Stacy <CStacy at MIT-MC>
Cc:   BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
      KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC
Subject: ITS wedgeding
In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>

Oh by the way, I forgot to mention about the job that had two disk
channels open, where one was to "RAT;".  The mode printed by Peek C
mode for that channel was "RU", meaning that it was reading a
directory ("UFD").  Probably this channel really belonged to some
other job and peek was confused.
\1f
Date: Saturday, 29 October 1983  15:59-EDT
From: MOON at SCRC-TENEX
To:   Christopher C. Stacy <CStacy at MIT-MC>
Cc:   BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
      KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC,
      Moon at SCRC-TENEX
Subject: ITS wedgeding
In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>

    Date: Saturday, 29 October 1983, 01:52-EDT
    From: Christopher C. Stacy <CStacy at MIT-MC>
    Subject: ITS wedgeding
    To: BUG-ITS at MIT-MC
    Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX,
        ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC

       TAFT@MIT-MC 10/28/83 14:31:11 Re:  Crash of 10/28 14:27
       MC was catatonic, but running.  Though jobs could be logged in, no
       response to anything other than ^G could be obtained.  I checked
       around that this was really the case and then stopped it.


    MC was also merrily printing lots of my little "Warning: <out of this
    or that>" messages every chance it got.

    In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24,
    IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC:

    There is definitely something weird going on here.
    Of the 50 disk channels, none are free.  
    There is no more free low core (for making file or network buffers.)

    There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot.
    They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP,
    respectively. They all have read 0% of their file.

      We can look at a representative wedged server job: user idx 101.
    ___101 TCP, is blocked inside a LOAD call:  NLOADD+6/ SKIPG QSFBS(A)  A/ 40
    I don't entirely grok this disk code yet, but from the channel state
    (%QALBK) and mode (READ/USER DATA), and the comment where he blocks,
    it looks like he is waiting for the file channel to receive a buffer
    with the first page of the TCPSER file.

    Also, there may also be something weird file-wise with this particular job.
    Unlike the others, I think it has two (QUSR idx) channels:  17 and 40.
    According to PEEK, he is also opened RAT; (no file name), which I
    guess accounts for channel 17.   But, huh? What? Why?

      Now, the TCP situation shows that there can be up to 180. packet
    buffers, of which zero are free out of a total zero allocated.

    I checked in XBUSER and friends.
    There is only one TCP frob around, and he's not doing a whole lot:
    TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL.  
    Has received FIN for input, State is "Last ACK".
    User channel state:  (input) Foreign host RESET, retransmit timeout (output).
    The close reason is:  Closed by user, Closed by foreign host.

    This is (I think) reasonable, but does not account for all those other TCP servers!


    1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY 
       NETWORK CONNECTIONS?  Is it that the connections went away 
       before the jobs had a chance to get started, or what?
       What are all these jobs for, anyway?

They have to load their programs before they can open their network
connection.  The incoming RFC (SYN in the TCP case) that started these
jobs probably timed out and was rejected before you dumped the system,
hence no trace of it was left.  If they're trying to load the ATSIGN xxx
program (rather than the actual server) that means they haven't even
yet queried the system's RFC (SYN) queue to find out what contact name
(port number) they are supposed to serve.

The system is supposed to filter out duplicate RFCs and SYNs, so if that's
working each of those jobs was created by a separate user attempt to connect.
Of course if they block forever in the LOAD system call, once created they
will never go away.

    2. WHERE DID ALL THE LOW CORE GO?  
       This seems to be the reason those server jobs can't get going.

The lack of low core is indeed the reason the servers can't get going; they
can't get a buffer to use to read their disk files they're trying to load.
Even in PDUMP format the first page of the file has to be read into low core
to find out what pages are to be loaded.

One reason for lack of low core is bloatage of directories.  I've been meaning
to make a straightfoward but not totally simple fix to allow directories to
be stored anywhere in core, but haven't got around to it.  I guess you should
bug me about this periodically.

However, in this case that isn't the problem: there are only 9 pages of
directories (DSKUDR in Peek M mode) plus 7 pages of disk buffers.  I looked
around at the MEMBLT and MEMPNT tables.  A lot of the low core pages are
just user pages of job 100, a worthless TEX job.  See the large comment
a few lines below SWPOPG; evidently the system keeps trying to swap
out more and more pages to get some low memory, but keeps swapping out
the wrong jobs.

The right fix is to make it specifically swap out pages in "low" memory
(as counted by LMEMFR) in this case, or else to put the core shuffler
back in to move those pages to "high" memory.  Maybe I'll look into this
in a few days when I get time.

    3. I heard that typein was echoing very slowly for users during this
       wedged period.  I wonder if this was true, it was it true for local
       consoles as well as STYs?  I don't really understand why this should
       be, in either case.  When the system is running out of core, I have
       usually been able to do SYS$J (provided there was a channel for me
       to .OPEN on USR:) and look around.

Lack of low core could not affect echoing on local terminals, and would only
affect echoing on network terminals if there wasn't enough core to make
network packet buffers.  Of course maybe the users were confused and
what they really meant was that their programs were busted.
\1f
Date: 29 October 1983 01:13 EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC

Perhaps someone could write a demon that ran at system startup time that
would look for files whose authors were set to non-existent directories and
set them to be unknown.  That way we would avoid recycled directories
claiming that they authored files that were written by people now gone.

I think about this now because I just noticed that MC:SYS1;TS STINK was
authored by the newly created directory VASL...
\1f
Date: Saturday, 29 October 1983, 01:52-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: ITS wedgeding
To: BUG-ITS at MIT-MC
Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX,
    ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC

   TAFT@MIT-MC 10/28/83 14:31:11 Re:  Crash of 10/28 14:27
   MC was catatonic, but running.  Though jobs could be logged in, no
   response to anything other than ^G could be obtained.  I checked
   around that this was really the case and then stopped it.


MC was also merrily printing lots of my little "Warning: <out of this
or that>" messages every chance it got.

In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24,
IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC:

There is definitely something weird going on here.
Of the 50 disk channels, none are free.  
There is no more free low core (for making file or network buffers.)

There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot.
They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP,
respectively. They all have read 0% of their file.

  We can look at a representative wedged server job: user idx 101.
___101 TCP, is blocked inside a LOAD call:  NLOADD+6/ SKIPG QSFBS(A)  A/ 40
I don't entirely grok this disk code yet, but from the channel state
(%QALBK) and mode (READ/USER DATA), and the comment where he blocks,
it looks like he is waiting for the file channel to receive a buffer
with the first page of the TCPSER file.

Also, there may also be something weird file-wise with this particular job.
Unlike the others, I think it has two (QUSR idx) channels:  17 and 40.
According to PEEK, he is also opened RAT; (no file name), which I
guess accounts for channel 17.   But, huh? What? Why?

  Now, the TCP situation shows that there can be up to 180. packet
buffers, of which zero are free out of a total zero allocated.

I checked in XBUSER and friends.
There is only one TCP frob around, and he's not doing a whole lot:
TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL.  
Has received FIN for input, State is "Last ACK".
User channel state:  (input) Foreign host RESET, retransmit timeout (output).
The close reason is:  Closed by user, Closed by foreign host.

This is (I think) reasonable, but does not account for all those other TCP servers!


1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY 
   NETWORK CONNECTIONS?  Is it that the connections went away 
   before the jobs had a chance to get started, or what?
   What are all these jobs for, anyway?

2. WHERE DID ALL THE LOW CORE GO?  
   This seems to be the reason those server jobs can't get going.

3. I heard that typein was echoing very slowly for users during this
   wedged period.  I wonder if this was true, it was it true for local
   consoles as well as STYs?  I don't really understand why this should
   be, in either case.  When the system is running out of core, I have
   usually been able to do SYS$J (provided there was a channel for me
   to .OPEN on USR:) and look around.


Does anybody recognize these symptoms?  
(I have never tried to debug an ITS when it had not crashed at some
definite place; I am relatively new at all this.)
I have not yet looked to try to find what all the core is allocated
to.  I'll do that next sitting.  I'd like people's thoughts on whether
they think this is a bug, or what.  I vaugely remember KLH saying
something about this; maybe he has some idea what is going on.

Chris

\1f
Date: 26 October 1983 23:54 EST
From: Keith F. Lynch <KFL @ MIT-MC>
Subject: Uptime
To: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
cc: KFL @ MIT-MC

  MC is claiming to have been up for 334 days.
                                                                ...Keith
\1f
Date: 25 October 1983 12:14 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: ZUSER crash of 10/25/83
To: BUG-ITS @ MIT-MC
cc: KMP @ MIT-MC

In crashed ITS 1353, CRASH;ITS LZUSUE, on MIT-MC:

The system crashed because it was trying to finish logging out
___071, who had a current inferior job with one page still in core.
It was a NAME (jname "F"), and it looks like it had just started
loading - it had an open file channel which had read 0 wds in.

Another weird thing is that his USYSN1 was 'SUPDUP', not the same as
his reasonable USYSNM.

That's about as far as I think I am going go with this: this info
might be useful if a similar thing ever happens again.  I wonder
if it could be some kind of timing screw.
\1f
Date: 22 October 1983 17:14 EDT
From: George J. Carrette <GJC @ MIT-MC>
To: BUG-ITS @ MIT-MC

this isn't an its bug, just something I have noticed about TCP,
both on XX and MC. Well, I can never seem to get more than about
7kbps transfer rate now, and usually get only about 3 or 4kbps
on FTP. The net used to be much faster under NCP. The price
of progress?
\1f
Date: 21 October 1983 15:18 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

ITS crashed at 2:30. It was a BUGHALT, BUGPC/ 8  CAI LZUSUE R2+12
                                        $Q-1/ PUSHJ P, BUGNIL
I dumped this to CRASH;LZUSUE and reloaded the system.
\1f
Date: 17 October 1983 16:42 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  ARPANET<->MILNET
To: DCP @ MIT-MC
cc: BUG-ITS @ MIT-MC, JSOL @ MIT-MC
In-reply-to: Msg of 16 Oct 1983 15:39 EDT from David C. Plummer <DCP>

    Date: 16 October 1983 15:39 EDT
    From: David C. Plummer <DCP>
    To:   JSOL
    cc:   BUG-ITS

        Date: 16 October 1983 15:12 EDT
        From: Jon Solomon <JSOL @ MIT-MC>

        I don't know where to send this, but when you telnet from a chaos host
        using either MC's or ML's gateway, it doesn't seem to allow you to
        gateway to hosts which are not on Net-10. This includes LCS hosts,
        MILNET hosts, and BBN-NET hosts for starters.

    This is either a host table lossage (BBNC appears to be
    registered on MILNET), which I doubt, or this is the result of
    the MILNET split, in which case you aren't ALLOWED to telnet from
    ARPANET to MILNET.  Fun, eh?

No, TELNET and FTP are not yet administratively prohibited services
between ARPANET and MILNET.

\1f
Date: 17 October 1983 16:38 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  TCP server doesnt work off net 10.
To: JSOL @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 16 Oct 1983 15:12 EDT from Jon Solomon <JSOL>


You didn't say what system you were using the TCP server from, or what
makes you think it is not working, and I suspect it might be on the
other end. I am not near a Lisp machine to really test this right now,
but when I halfway test it using only MC I can get a TCP connection to
ISIA (a MILNET host.)  I notice the TOPS-20 TELNET program on OZ does
not let you connect to non-ARPANET hosts because its host table claims
not to know about them.  I'll make more test later. 
\1f
Date: 16 Oct 1983  21:40 EDT (Sun)
Message-ID: <[MIT-OZ].MARTY.16-Oct-83 21:40:41>
From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
To:   Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
Cc:   BUG-SYSTEM%MIT-OZ@MIT-MC.ARPA, Staff%MIT-EECS@MIT-MC.ARPA,
      Bug-ITS@MIT-MC.ARPA
Subject: bad host table
In-reply-to: Msg of 16 Oct 1983  20:29-EDT from Jon Solomon <JSOL>

    Date: Sunday, 16 October 1983  20:29-EDT
    From: Jon Solomon <JSOL>
    To:   BUG-SYSTEM, Staff at MIT-EECS

    [EECS people: I don't know who to send this to on EE]

    Your host tables don't have the necessary changes for the MILNET
    split, hence no milnet hosts can be connected to.

Yes, in fact *any* non-arpa internet site will appear unreachable.
So I wrote a little PCL hack.
Basically, our TELNET (chaos gateway version) doesn't know how to
connect to non-internet sites unless you fool it.
So try:

   DECLARE PCL SS:<MARTY.PCL>ITN.PCL.
   ITN <your favorite internet/milnet site>

It would be nice if we could change TELNET to forget about HOSTS2.BIN
which is what it is using, and why we are losing.
This will all be less important when we are directly connected to the
Arpanet.  
\1f
Date: Sun, 16 Oct 1983  20:27 EDT
Message-ID: <[MIT-OZ].JSOL.16-Oct-83 20:27:58>
From: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
To:   David C. Plummer <DCP@MIT-MC.ARPA>
Cc:   BUG-ITS@MIT-MC.ARPA
Phase-Of-The-Moon: FQ+3D.2H.6M.14S.
In-reply-to: Msg of 16 Oct 1983  20:00-EDT from David C. Plummer <DCP at MIT-MC>

I see, you're right. why didn't I think to check and see what was
actually being fed to MC! Now I know who to send my gripe to.
\1f
Date: 16 October 1983 20:00 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: JSOL @ MIT-OZ
cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC

    Date: Sun, 16 Oct 1983  16:21 EDT
    From: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>

    Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can
    telnet to them directly but OZ can't. Similarly you can telnet from
    ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage
    is in the gateway program.

Works for me.  From MC:
        :CHTN MC<alt>TCP BBNC 27
connects me to BBNC.
\1f
Date: Sun, 16 Oct 1983  16:21 EDT
Message-ID: <[MIT-OZ].JSOL.16-Oct-83 16:21:59>
From: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
To:   David C. Plummer <DCP@MIT-MC.ARPA>
Cc:   BUG-ITS@MIT-MC.ARPA
Phase-Of-The-Moon: FQ+2D.22H.0M.7S.
In-reply-to: Msg of 16 Oct 1983  15:39-EDT from David C. Plummer <DCP at MIT-MC>

Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can
telnet to them directly but OZ can't. Similarly you can telnet from
ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage
is in the gateway program.
\1f
Date: 16 October 1983 15:39 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: JSOL @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 16 October 1983 15:12 EDT
    From: Jon Solomon <JSOL @ MIT-MC>

    I don't know where to send this, but when you telnet from a chaos host
    using either MC's or ML's gateway, it doesn't seem to allow you to
    gateway to hosts which are not on Net-10. This includes LCS hosts,
    MILNET hosts, and BBN-NET hosts for starters.

This is either a host table lossage (BBNC appears to be
registered on MILNET), which I doubt, or this is the result of
the MILNET split, in which case you aren't ALLOWED to telnet from
ARPANET to MILNET.  Fun, eh?
\1f
Date: 16 October 1983 15:12 EDT
From: Jon Solomon <JSOL @ MIT-MC>
To: BUG-ITS @ MIT-MC

I don't know where to send this, but when you telnet from a chaos host
using either MC's or ML's gateway, it doesn't seem to allow you to
gateway to hosts which are not on Net-10. This includes LCS hosts,
MILNET hosts, and BBN-NET hosts for starters.

--JSol
\1f
Date: 14 October 1983 04:46 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: GSB @ MIT-MC
cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC

   GSB@MIT-MC 10/13/83 17:44:25 Re: MC directory slot
   To: JPG at MIT-MC
   CC: (BUG ITS) at MIT-MC
   BACKUP; is for backup copies of things on .; and occasionally other things.
Why can't .; itself be used for this?  For the couple of true backup @ files, 
which have the same names as files on .; , e.g. CRASH; would work fine.
Or better, SYS; ?

   It should be preserved, and it does get updated occasionally.
The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe 
almost everything there is garbage.  If BACKUP; were trully for backup 
then leaving non-working stuff on that directory as is now the case 
may be hazardous for MC's health if ever invoked.

   I believe that it has proven itself useful on ML at least.
I see no recent proof of this for MC:BACKUP; .
\1f
Date: 13 October 1983 17:44 EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: MC directory slot
To: JPG @ MIT-MC
cc: BUG-ITS @ MIT-MC

BACKUP; is for backup copies of things on .; and occasionally other things.
It should be preserved, and it does get updated occasionally.  I believe
that it has proven itself useful on ML at least.
\1f
Date: 13 October 1983 16:35 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: MC directory slot
To: BUG-ITS @ MIT-MC

Are all of you familiar with the MC:BACKUP; directory?  I wonder how useful 
that directory is, or has its function been largely usurped by MC:.; et al?
\1f
Date: 13 October 1983 03:57 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

I made the MLDEV/MLSLV use HOSTS3, and also fixed a minor bug
where MLDEV was comparing 36 bit network numbers as CAIN A,NW%ARP.
I bother mentioning the bug fix, because it seems to be everyone's
favorite sleepytime bug for ITS network hacking.

\1f
Date: 12 October 1983 20:29 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: [ron: ML Routing]
To: MARTY%MIT-OZ @ MIT-ML
cc: BUG-ITS @ MIT-MC

I doubt there is a real problem.  ML was probably down at the
time he tried, or the MILNET split cnfused things, or Ron was
confused.  MC and ML have the same "routing" code.
\1f
Date: 12 Oct 1983  15:23 EDT (Wed)
Message-ID: <[MIT-OZ].MARTY.12-Oct-83 15:23:24>
From: Martin David Connor <MARTY%MIT-OZ@MIT-ML.ARPA>
To:   Bug-ITS@MIT-MC.ARPA
Subject: [ron: ML Routing]


Does anyone understand why this is happening 

Date: Wednesday, 12 October 1983  14:58-EDT
From: Ron Natalie <ron at brl-vgr>
To:   bug-tcp
Re:   ML Routing

I can talk to MIT-MC from our local nets but not MIT-ML.

The nets in question are:
        BRLNET  128.20
        BRLNET1 192.5.21
        BRLNET2 192.5.22
they should be routed to your MILNET/ARPANET gateway.

-Ron
\1f
Date: 12 October 1983 01:48 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: normal host tables!
To: BUG-ITS @ MIT-MC
cc: INFO-HOSTS @ MIT-MC

I snarfed the latest host table from the NIC, and
installed it on ITS.
\1f
Date: 12 October 1983 01:37 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  new host table
To: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC
cc: GSB @ MIT-MC, TK @ MIT-MC, ELLEN @ MIT-MC, DCLARK @ MIT-MC,
    JIS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC


The latest NIC:<NETINFO>SPLIT-HOSTS.TXT file, dated 11 October 83, has
MIT-MC back on the ARPAnet ("HOST : 10.3.0.44 : MIT-MC,MC :").
I think this means things have finally been set aright.

\1f
Date: 8 October 1983 05:28 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: source write lock removed
To: BUG-ITS @ MIT-MC


\1f
Date: 7 October 1983 20:34 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


I JFCLd out the only-ARPANET patch I made a little while ago
in the running system on MC.  For one thing, no hosts know
we are here on the ARPAnet, so we arent likely to get much
unwanted traffic except from TAC users.
\1f
Date: 7 October 1983 19:05 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


At this moment, MC has the split host table which has itself on
net 10.  I just typed in a patch to make it refuse to connect
to/from nets other than the ARPANET, though, to prevent lots
of MILNET packets from being generated by unauthorized users.
This isn't optimal; I'll frob it some more later tonite.
\1f
Date: Friday, 7 October 1983, 05:43-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: INQUIR
To: BUG-ITS at MIT-MC, BUG-INQUIR at MIT-MC
Cc: GSB at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC


I changed over all the INQUIR groups tonite, and installed new INQUIR
and LSRPRT versions.  I put up a messsage urging people to check to
make sure their entry looks right.  I used an editied version of
ELLEN;PLASMA to find the PFC people, who have a new special group.

I tried to make it preserve directory assignments, but it may have
slightly confused people who are in the USERSi dirs on ML, since I
forgot to make then specify the machine.  I don't expect this to be a
problem in most cases though.

Chris
\1f
Date: 6 Oct 1983  08:13 EDT (Thu)
Message-ID: <[MIT-OZ].IAN. 6-Oct-83 08:13:06>
From: Ian Macky <Ian@MIT-OZ>
To:   Bug-ITS@MIT-ML


[PHOTO:  Recording initiated  Thu 6-Oct-83 8:11AM]

 TOPS-20 Command Processor 5(742)-2
 [Commands]
!f @nic
[SRI-NIC via MIT-MC]
%No response
[SRI-NIC via MIT-ML]
? Internal error - DEVICE NOT ASSIGNABLE TO THIS PROCESSOR

%No path to site
!pop

[PHOTO:  Recording terminated  Thu 6-Oct-83 8:12AM]
\1f
Date: Thursday, 6 October 1983, 02:54-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: inconsistant sources available
To: BUG-ITS at MC


ITS is being hacked.  If you arent KLH or myself, don't bother trying
to assemble and run it.

\1f
Date: 5 October 1983 02:24 EDT
From: Christopher C. Stacy <CSTACY @ MIT-ML>
To: BUG-ITS @ MIT-ML
cc: TK @ MIT-ML

ML has a version of ITS which does routing to the MILNET.
The HOSTS3 bin file there is speciall hacked up.
People should not install ITS host tables until further notice.

MC is off the Internet, since it is connected to MILNET
and it cannot deal with this.  (I consulted KLH about one
of us fixing this, so that MC could be on the MILNET, but
he agrees it is too much dangerous trouble for what should
be a very temporary situation.)

MC and ML can talk to each other over the Chaosnet, of course.
\1f
Date: 4 October 1983 23:50 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: GSB @ MIT-MC


ML needs a new special host table, and a new ITS version.
I'll take care of this tomorrow.
\1f
Date: 4 October 1983 05:40 EDT
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: Batch processing
To: Ian @ MIT-OZ
cc: MAGIC-DRAGON-KEEPER @ MIT-ML, ALAN @ MIT-MC, BUG-ITS @ MIT-MC,
    MAGIC-DRAGON-KEEPER @ MIT-MC

    Date: 4 Oct 1983  02:32 EDT (Tue)
    From: Ian Macky <Ian@MIT-OZ>
    To:   Alan Bawden <ALAN@MIT-MC>
    Cc:   BUG-ITS@MIT-MC, MAGIC-DRAGON-KEEPER@MIT-MC, Magic-Dragon-Keeper@MIT-ML
    Subject: Batch processing
    In-reply-to: Msg of 4 Oct 1983  02:22-EDT from Alan Bawden <ALAN at MIT-MC>
    In case noone noticed, OZ has been sending Happy Birthday messages
    for months...

oh, we noticed (could hardly miss doing so). but that's only for OZ
users. there are other people in the world..
\1f
Date: 4 Oct 1983  02:32 EDT (Tue)
Message-ID: <[MIT-OZ].IAN. 4-Oct-83 02:32:38>
From: Ian Macky <Ian@MIT-OZ>
To:   Alan Bawden <ALAN@MIT-MC>
Cc:   BUG-ITS@MIT-MC, MAGIC-DRAGON-KEEPER@MIT-MC, Magic-Dragon-Keeper@MIT-ML
Subject: Batch processing
In-reply-to: Msg of 4 Oct 1983  02:22-EDT from Alan Bawden <ALAN at MIT-MC>

In case noone noticed, OZ has been sending Happy Birthday messages
for months...
\1f
Date: 4 October 1983 02:22 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Batch processing
To: BUG-ITS @ MIT-MC, MAGIC-DRAGON-KEEPER @ MIT-MC,
    Magic-Dragon-Keeper @ MIT-ML

In the latest version of Puff the Magic Dragon (installed on MC, not ML
yet) I have generalized the feature where once an hour Puff would look for
the files DRAGON;HOURLY RAYGUN and HOURLY TMPKIL and load and run them.
Puff now will load ANY file on DRAGON; whose first file name is HOURLY and
try to load it into a job and run it.  While I was at it I made it check
for files named DAILY, MNTHLY and YEARLY as well.  (They are run at the end
of the day, month and year, when Puff is cleaning his own house.)

I nominate CStacy to write DRAGON;DAILY BTHDAY to replace poor DM's
cheerful birthday greetings.

There seems to have been some misimpression that Puff was ALREADY doing
this.
\1f
Date: 3 October 1983 08:10 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


What finaly wound up sending out happy birthday announcements on ITS?
\1f
Date: 1 October 1983 22:07 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Latest ITS (installed on MC) has the MILNET gateway in it
so that forwarding will happen after the split.  I will
install this on ML later tonite or tomorrow.
\1f
Date: 30 September 1983 22:57 EDT
From: Keith F. Lynch <KFL @ MIT-MC>
To: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
cc: KFL @ MIT-MC

  9 users, fair share = 109% ?
                                                                ...Keith
\1f
CENT@MIT-ML 09/27/83 01:10:11 Re: dm
To: (BUG ITS) at MIT-ML
i removed *DM from the ML system msg lists. someone had already done
this on MC..
\1f
Date: 26 September 1983 21:33 EDT
From: George J. Carrette <GJC @ MIT-MC>
To: BUG-ITS @ MIT-MC

SRI-IU must have a bad address or something in the version of the host
table we have.
\1f
Date: 25 September 1983 01:02 EDT
From: Glenn S. Burke <GSB @ MIT-MC>
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 23 September 1983 02:27 EDT
    From: Ken Harrenstien <KLH @ MIT-MC>
    Sender: KLH1 @ MIT-MC

    Patched MC (running sys & disk) at TCLK30+10/ CAILE D,556.
    Fix made in source but not assembled.  ML not patched but eventually
    ought to be.

Patched in the binary and the running system (it's been up 10 days!)
\1f
Date: 24 September 1983 22:13 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

I merged DM:SYSENG; onto the MC SYSENx dirs.
\1f
Date: Saturday, 24 September 1983, 17:19-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: DM
To: BUG-INQUIR at MIT-MC, BUG-ITS at MIT-MC

I diked DM out of INQUIR.
\1f
Date: 23 September 1983 06:00 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  ITS software on DM
To: BUG-ITS @ MIT-MC
cc: BUG-RANDOM-PROGRAM @ MIT-MC, TAA @ MIT-DMS, PDL @ MIT-DMS,
    SWG @ MIT-DMS, Moon @ SCRC-TENEX


I have snarfed the interesting things in DM:SYSENG; to a place on MC,
and will be making sure we have everything from that directory.  Are
there any other interesting programs or systems (MIDAS or otherwise)
we really should have on MC hiding out there?  I bet there are, but
I don't know where.

\1f
Date: 23 September 1983 02:27 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Sender: KLH1 @ MIT-MC
To: BUG-ITS @ MIT-MC

Patched MC (running sys & disk) at TCLK30+10/ CAILE D,556.
Fix made in source but not assembled.  ML not patched but eventually
ought to be.
\1f
Date: 16 September 1983 00:53 EDT
From: Joseph A. Kay <JAK @ MIT-MC>
To: BUG-ITS @ MIT-MC

At 00:10:25 ,16-sept-83, the LA-36 typed out 20 times:
( at MC):"LOGIN 542A02 0 HST205 " followed by the times (1 second apart).
there  was one intervening line from chaos,  in their midst, after which
some lines had 542A11  instead of 542A02.
The same thing happened again 1 minute  later with ~50 lines in a row,mostly
"LOGIN 542A11 0 HST205" with times  in two consecutive sequences (a 9 second 
gap between the sequences,1-second  or less inside them). Occasionally 
lines had 542A12.
At 00:35,there were 10 lines with times in 13-second span, saying:
"LOGIN 030A16 0 HST017"...
----
--this may point out a problem, possibly elsewhere; or may help diagnose
a future difficulty. I am not sure of its significance, but I hope it can 
be of help to you.  
\1f
Date: Monday, September 12, 1983 5:40AM-EDT
From: Christopher Stacy <CSTACY@MIT-OZ>
Subject: TOPS-20 usage of "TCP" protocol
To: BUG-OZ
CC: BUG-ITS at MIT-MC

Programs which gateway through the TCP byte-stream gateways (ie., the
"ARPA" CHAOSnet protocol, currently served only by ITS hosts on both
nets), they should tell what sort of gatewaying is going on.

Users cannot tell how they are getting from point A to point B - all
they see is a virtual network where everything is magically connected
by various secret means.  If they were told what means was being
employed to connect them with remote hosts on other networks, they
would stand a chance of figuring out what was losing when the
"gateway" did not work.

BTW, probably the CHAOSNET "TCP" protocol user to get a byte stream
should be made an available (optionally included, requires CHAOS
support routines) call in the NETWRK packages (on all systems).  It
could take remote host address and port, and an AOBJN-style pointer to
a table of gateway server addresses.  When the DEC interface for IP
comes out, and NETWRK will need rewriting anyway, would be a good time
to do this.

Chris
\1f
Date: 10 September 1983 06:35 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

ITS had the date wrong for a few minutes today while it was being
debuggged, so a few files might have the wrong day (not too far
off) on them.  (Since only one or two people were on during
this time, it should not be a real problem..this message is just FYI.)
\1f
Date: Friday, 9 September 1983, 15:43-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: FILE bug
To: BUG-ITS at MC


In Release 4.4, site configuration 62, on Lisp Machine Apiary-6:

 >>Error: File system bug on host MIT-MC:
 CHANNEL NOT OPEN
 CHNL NOT OPEN
 For MC: AR2: CSTACY; .FILE. (DIR)
 While in the function (DEFUN-METHOD FS:FILE-PROCESS-ASYNC-MARK) \18 (DEFUN-METHOD FS:FILE-NEXT-READ-PKT) \18 (METHOD FS:FILE-INPUT-STREAM-MIXIN GET-NEXT-INPUT-PKT)

 (DEFUN-METHOD FS:FILE-PROCESS-ASYNC-MARK):  (P.C. = 20)
    Arg 0 (SELF): #<FILE-INPUT-CHARACTER-STREAM "MC: AR2: CSTACY; .FILE. (DIR)" 5535744>
    Arg 1 (SELF-MAPPING-TABLE): #<Map to flavor FS:FILE-DATA-STREAM-MIXIN -- 6. IV's, 0. FL's 60527270>
    Arg 2 (PKT): #<CHAOS Packet 53067315>
    Local 3 (STRING): "I1696 ERROR BUG R CHANNEL NOT OPEN
 CHNL NOT OPEN
 "
 .
 .
 .
ZWEI:VIEW-WINDOW-DISPLAY:  (P.C. = 44)
   Arg 0 (ZWEI-WINDOW): #<WINDOW 53501015>
   Arg 1 (STREAM): #<FILE-INPUT-CHARACTER-STREAM "MC: AR2: CSTACY; .FILE. (DIR)" 5535744>
   Arg 2 (FORCE-P): T
\1f
Date: 9 September 1983 15:14 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: BUG-MINITS @ MIT-MC, BUG-ITS @ MIT-MC

Echo response time to ddt and mail and such is very slow
on ITS today. It was like this sometime very recently, too.
I'm coming in from HUB8A. Anyone got any ideas what might
be so draggy? I get multi-second delays doing simple
input and the fair share is 44%.
\1f
Date: 15 Aug 1983  00:43 EDT (Mon)
Message-ID: <[MIT-OZ].GUMBY.15-Aug-83 00:43:28>
From: David Vinayak Wallace <GUMBY@MIT-OZ>
To:   SHAWN@MIT-ML
Cc:   Bug-its@MIT-OZ
Subject: monmode bug(?)
In-reply-to: Msg of 13 Aug 1983  23:02-EDT from SHAWN at MIT-ML

    Date: Saturday, 13 August 1983  23:02-EDT
    From: SHAWN at MIT-ML

    Is the fact that when you have 'prmmch' set, (printing machine name),
    and are in monmode, (for example 'ML: '), and you type "clear", when
    it goes to the top of your screen, it only prints the ':' not the 'ML:'.
    Is this a bug??? (If not, is there any reason for it other then that's
    how someone liked it?), Thanks.


You'll notice that ^L will never reprint the prompt.  It will echo
whatever pending typing exists (in this case a ":").  This has nothing
to do with either :MONMOD or PRMMCH.
\1f
Date: 14 August 1983 18:06 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: new ITS version, install at leisure.
To: BUG-ITS @ MIT-MC


ITS 1351 changes .SHUTDN to not allow shutdowns further away than 30 days,
and fixes some SYSJOB code which would have broken under certain assembly
conditionals.  I'll install it around eventually; nothing very interesting in here.

(The .SHUTDN restriction is due to delta-t being computed wrong for the DEDBLK
clock queue list entry; this would crash the system.)

\1f
GSB@MIT-ML 08/13/83 23:30:28 Re: c100 inschar lossage
To: (BUG ITS) at MIT-ML
Multiple insert-characters never ever ever succeed in outputting the
null in the sequence which is what turns off insert-character mode,
on anything but the first.  This is what i presume is an insert-char
operation with an argument, which comes in over a supdup.

I have seen this lossage locally in what i presume are only single
insert-character operations, but it cannot be reliably reproduced then.
However multiple insert-char sequence coming from (say) emacs on OZ
reliably produce the null for the first and none of the others.

\1f
SHAWN@MIT-ML 08/13/83 23:02:36 Re: monmode bug(?)
To: (BUG its) at MIT-MC

Is the fact that when you have 'prmmch' set, (printing machine name),
and are in monmode, (for example 'ML: '), and you type "clear", when
it goes to the top of your screen, it only prints the ':' not the 'ML:'.
Is this a bug??? (If not, is there any reason for it other then that's
how someone liked it?), Thanks.

                Yours In Hacking,
                  -Shawn

\1f
Date: 11 August 1983 23:49 EDT
From: V. Ellen Golden <ELLEN @ MIT-MC>
Subject: console decwriter keyboard stops working
To: Moon @ SCRC-TENEX
cc: CSTACY @ MIT-MC, ELLEN @ MIT-MC, BUG-ITS @ MIT-MC

DEC appears to have fixed this problem (??!!!) when they PM'd
the machine, which was down due to precisely this situation when
they arrived... so I guess it is working.....
\1f
Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Thu 11-Aug-83 17:55:06-EDT
Date: Thursday, 11 August 1983, 17:48-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: console decwriter keyboard stops working
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: ELLEN@MIT-MC, BUG-ITS@MIT-MC
In-reply-to: The message of 6 Aug 83 10:38-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: 6 August 1983 10:38 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    Please get someone to look at MC's console typewriter.
    It frequently gets into this mode where the keyboard
    does not work at all, and nothing can be typed.
Isn't there some DEC braindamage where this is caused by the cover
not being quite closed all the way, and/or the thing thinking it
is out of paper?  Or is that some other model of decwriter?
\1f
Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Thu 11-Aug-83 17:51:25-EDT
Date: Thursday, 11 August 1983, 17:45-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: DM frotzed
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: BUG-ITS@MIT-MC
In-reply-to: The message of 8 Aug 83 03:31-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: 8 August 1983 03:31 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    I just noticed DM had crashed a while back (with no error
    messages or anything, and questionable state in the console).
    So I tried to reboot it.  DSKDMP says the MFD is clobberred.
There's a copy of the MFD on each drive and sometimes this message
means that the disk controller or channel is broken or the processor 
is broken (what it really means is that dskdmp tried to read the mfd
and either got a disk error or some checkword in it didn't have the
right value).
\1f
Date: 8 August 1983 03:31 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: DM frotzed
To: BUG-ITS @ MIT-MC

I just noticed DM had crashed a while back (with no error
messages or anything, and questionable state in the console).
So I tried to reboot it.  DSKDMP says the MFD is clobberred.
If there is a 9-track MAGDMP format tape for it, I will try
to fix this, if anyone cares.  If it cannot be fixed of
course, someone will have to reload the file system.
Should I look at it?
\1f
Date: Sunday, 7 August 1983, 10:17-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
To: BUG-ITS at MIT-MC
Cc: KMP at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC
In-reply-to: The message of 6 Aug 83 00:23-EDT from Kent M. Pitman <KMP>

In crashed ITS 1348 in CRASH;LUUOEX, on MIT-MC:

The routine which builds Internet datagram headers was smashed
somehow.  IPKHDR+3 (64012), normally a MOVEM, is zero (which of 
course looks like a UUO).

Also, I am not sure exactly what this implies, but if you look at the
"M" display in PEEK, it complains about not being able to trace some
memory pointers ("Bad mem ptr data for 979 pages!").

Anyone else want to look at this dump further?  
If not I'll delete it in a few days.
\1f
Date: 6 August 1983 10:38 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: ELLEN @ MIT-MC
cc: BUG-ITS @ MIT-MC

Please get someone to look at MC's console typewriter.
It frequently gets into this mode where the keyboard
does not work at all, and nothing can be typed.
Being the console tty, this typically goes unnoticed
until the system needs to be reloaded or something, sigh.
\1f
Date: 6 August 1983 00:23 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC

MC crashed with the message:
 MUUO in Exec Mode, PC = 304000,,64013
 PI Level 7 BugHalt
  BUGPC/ LUUOEX
  \eQ-1/  JSR BUGAWF

It had been down for an hour and a half, and there were no wizards in sight,
so I dumped it to CRASH;LUUOEX and I reloaded the machine. I made an entry
in the log book to this effect.
--kmp
\1f
Date: 5 August 1983 00:25 EDT
From: Zippy the Pinhead <ZIPPY @ MIT-MC>
To: BUG-ITS @ MIT-MC



From evan Fri Jul  1 23:34:10 1983
To: sys-bozos@cogs
Subject: So I had this dream...


        The earth was going to be destroyed: there were these aliens
who were going to eradicate all life on earth real soon so they could
use it for themselves. There were two different castes of these aliens:
A variety which resembled Dean Bob Randolph, and type which looked like
Don Saklad. I addition to being about to kill everyone, these aliens had
the additional bad feature of being obnoxious. The Dean Bob aliens were
wandering around telling everyone that it was really best for us to be
extermiated and that, in time, we would come to understand that the earth
wasn't right for us. The Saklad aliens were bothering everyone with
stupid questions about how to use the earth and the things on it.

        I was rather upset by the impending demise of EVERYBODY, but I
discovered that we had been visited year earlier by friendly aliens, who
had left us with a planetary defense system which would protect us from
the nasty aliens. Unfortunately, these aliens had been here several
years ago, and they had wired the defense system into the guts of the
AI-10! In order to activate the defense system, you had to boot AI and
log in as RMS, then type ":defend".

        The rest of the dream consisted of wandering around Tech Square
trying to get someone to give me a Lisp-Machine memory card so that I
could save all life on earth. No one would give me one. They all had
important things to do with them. So I went from office to office trying
to convince someone to help, and every time I rode the elevator, I was
accosted by a Saklad alien asking some question like: "What is this
water stuff and what do we do with it? Is it documented?"

        Then the phone rang and I woke up. Thank Heaven...


                                        ---Evan

\1f
Date: 5 August 1983 00:20 EDT
From: Herb Lin <LIN @ MIT-MC>
Subject:  tapes...
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 4 Aug 1983 23:42-EDT from Christopher C. Stacy <CStacy>

tnx.
\1f
Date: Thursday, 4 August 1983, 23:42-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: tapes...
To: Herb Lin <LIN at MIT-MC>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 4 Aug 83 23:05-EDT from Herb Lin <LIN at MIT-MC>

You can read tapes between AI,ML, and MC.  (DM has nine-track drives.)
Just use LOAD command of DUMP as usual.  I hear that due to drive
alignment, the most successful place to read AI tapes is on ML.

Also, there is a command in DUMP to read the backup directories from
AI if they are re-loaded to disk someplace.
\1f
Date: 4 August 1983 23:05 EDT
From: Herb Lin <LIN @ MIT-MC>
Subject:  tapes...
To: BUG-ITS @ MIT-MC

this is addressed to system wizards - does anyone know if tapes written on 
the old AI machine can be read onto MC?  If so, how can I do it...

tnx.
\1f
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 31-Jul-83 20:52:18-EDT
Date: Sunday, 31 July 1983, 20:50-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: MC crashes
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: TAFT@MIT-MC, ELLEN@MIT-MC, BUG-ITS@MIT-MC
In-reply-to: The message of 30 Jul 83 19:36-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

Somewhere on those scribbled-all-over pieces of paper attached
to the machine it says how to get some information when it seems
to be hung.  There's a KLDCP command with some name I don't
remember ("ALL" maybe) that prints a bunch of stuff, and a command
file (J KLHUNG I think) that prints about three pages of stuff.
Most of the three pages is useless, but buried in there are the
micro and macro PCs and various error status bits.  Somewhere unless
some idiot has thrown it away there is a notebook containing the
KLDCP commands, including how to get the current interrupt level
and other things like that that are in the lights on KAs.  I have
no idea any more what the names of the commands were.  Presumably
all the information it is possible to get is in the KLHUNG output
somewhere.

There should be a microcode listing on-line in the UCODE directory
in which you can look up micro PCs.  They appear embedded in some
syntax in the left margin, maybe "U nnnnn," or something like that.

Microcode hung really means that some timeout inside of KLDCP went
off, I believe, and doesn't really directly imply anything about
the microcode.  I think I have seen this caused by main memory
parity errors sometimes.

"ITS IS DOWN" means that a keep-alive counter incremented by the
60-cycle clock interrupt handler is not being incremented, at least as
far as the pdp11 you are typing to (whichever of the two it is) thinks.
ITS could be halted, looping at interrupt level, not taking interrupts
because the interrupt hardware, I/O bus, or clock is broken, not
running because the processor is broken, or working but not talking to
the pdp11 because the interface is broken.

The page-fault-in-system obviously should be investigated to see whether
there was a reference to a wrong address, or a page fault on a good
address, or code was clobbered, or the machine wasn't executing instructions
correctly, or whatever.  This one could easily be a software bug, so
keep that in mind.

Someone should delete the useless crash dump Taft made after a J NTSDDT.
\1f
Date: 30 July 1983 19:36 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  MC crashes
To: Moon @ SCRC-TENEX
cc: TAFT @ MIT-MC, ELLEN @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 07/30/83 16:24:06 from TAFT


Dave,

I know you are real busy over there, but if you get a second could you
please shed any light you have on this?  It's pretty much beyond me.


    Date: 07/30/83 16:24:06
    From: TAFT
    To:   CSTACY
    cc:   ELLEN
    Re:   MC crash

       MC crashed twice this afternoon.  The first time was with a
    microcode hung, but the second time the lights were just dead and
    there was no message whatsoever on the console. 

    I tried to take a dump of this, but I am not sure that I got it 
    right.  I hit BREAK on the console, did a "J NTSDDT" and then did:
    $Y CRASH;NO MSG
    It seems to have tried writing out a dump, but perhaps this was
    the wrong way to get into DDT ? (It appeared to load a new one ?)
    Anyway I left the dump in CRASH;NO MSG, maybe someone wants to
    look at it. Otherwise it should be deleted.
                        Jon

The command "DDT" will get you into the current DDT.  J NTSDDT runs a
command file which resets some things and loads up a fresh DDT.  I
don't remember if it clobbers the KL10 state, but I think it does.

Something is very wrong with MC.  It has the following three problems,
sometimes several times a day:

  o Microcode hung.
    Maybe this is not new, maybe it is a known expected ITS bug???
    Is that why it has never been looked into?

  o Machine appears halted, typing on hardware ttys gets ITS IS DOWN,
    no messages on console.
    I guess this acts this way because the machine has either gone into a
    super tight loop (on the order of JRST .), or the microcode is off
    in never-never land and some instruction never returns.  Maybe one 
    thing to do is StoP the machine and look at the PC - I didn't yet.
    If the machine were really halted, I think the console-11 would say so.
    The IO-11 times out doing some protocol to ITS instead, and 
    prints ITS IS DOWN.

  o ITS crashes with PAGE FAULT IN SYSTEM at the exact same address.

Chris
\1f
Date: 28 July 1983 04:33 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  CFTPing from ITS
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-FILE @ MIT-OZ, kmp @ MIT-OZ
In-reply-to: Msg of Jul 28 1983 3:19AM-EDT from Martin David Connor <MARTY at MIT-OZ>

    Date: Thursday, July 28, 1983 3:19AM-EDT
    From: Martin David Connor <MARTY at MIT-OZ>
    To:   bug-its, bug-file at MIT-OZ
    Re:   CFTPing from ITS
    I now find that supplying a non-existent username to LOGIN
    when CFTPing to MC or ML now hangs indefinitely.
    I discovered this when running a batch job that CFTPs and
    logs in as OZHOST.
    This used to work.  Was there a change to the file server on MC?



In FILE 520, ITS 1438, on MIT-MC:

KMP and I saw this too, but thought we might be imagining something.
Someone had broken FILE after version 518 by forgetting that on ITS,
ASCII byte pointers must be explicit (440700) and cannot be set up
with HRROI.  It was MPVing because of this in COMST0 when called from
the stuff around GETNAM.  Fixed in the source and installed on the ITS 
systems.
\1f
Date: Thursday, July 28, 1983 3:19AM-EDT
From: Martin David Connor <MARTY@MIT-OZ>
Subject: CFTPing from ITS
To: bug-its at MIT-MC, bug-file at MIT-OZ


I now find that supplying a non-existent username to LOGIN
when CFTPing to MC or ML now hangs indefinitely.
I discovered this when running a batch job that CFTPs and
logs in as OZHOST.

This used to work.  Was there a change to the file server on MC?

\1f
Date: 12 July 1983 01:32 EDT
From: Ed Schwalenberg <ED @ MIT-MC>
To: BUG-ARCDEV @ MIT-MC, BUG-ITS @ MIT-MC
cc: BIL @ MIT-MC

BIL's first problem comes from the archive device handler running out
of room to fit the archive (archives can only hold about 170. blocks of stuff.)
The archive device should report DEVICE FULL rather than seeming to win and
producing 0-length files.  Secondly, file creation dates are randomly munged,
off by an hour or so.  Thirdly, as we all know, the archive device needs to be
done right for a change.
\1f
Date: 12 July 1983 00:20 EDT
From: William G. Dubuque <WGD @ MIT-MC>
Sender: BIL @ MIT-MC
To: BUG-ITS @ MIT-MC

:MOVE <file>,AR0:RAT;  produces a file of length 0 on AR0. Unfortunately
i got screwed and moved a few unbackedup files there before noticing this.
If you list the archive you will notice a few 0 length files there where
this happened. All other files were :MOVEd there previously without such
lossage. Is there a new DDT or ARCDEV or somesuch at the heart of this?
Is there any way of getting around this (I want to preserve the creation
date so :COPY wont do)?
\1f
Date: 3 Jul 1983  21:32 EDT (Sun)
From: Ian Macky <Ian@MIT-OZ>
To:   Alan Bawden <ALAN@MIT-MC>
Cc:   BUG-ARGUS@MIT-MC, BUG-ITS@MIT-MC, CSTACY@MIT-MC
Subject: Artificial Intuition?
In-reply-to: Msg of 3 Jul 1983  15:57-EDT from Alan Bawden <ALAN at MIT-MC>


The source for ARGUS I found on MC was very very old, and is
pretty grim stuff (having been written before I had any idea
what I was doing)... I dunno where a more recent one is;  I'll
keep looking.
\1f
Date: 3 July 1983 15:57 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Artificial Intuition?
To: CSTACY @ MIT-MC
cc: BUG-ARGUS @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 3 Jul 1983 09:44 EDT from Christopher C. Stacy <CSTACY>

    Date: 3 July 1983 09:44 EDT
    From: Christopher C. Stacy <CSTACY>
    This is CSTACY.  I sat down at DEVON's console here just now, where
    DEVON had a disowned ARGUS looking for any CSTACY's.  I started up an
    EMACS to look at something.  I am sure you can imagine my surprise
    when I saw:  [Here is CSTACY].

    Startled, I ^Zd out of the EMACS I took my hands off the keyboard.
    Ever dutiful, ARGUS barked:  [There goes CSTACY].  
    I suppose this bug has something to do with my having typed CSTACY$^S
    before running the EMACS.  If it does not, congratulations!

'Tain't a bug in my opinion.  

Had always presumed that ARGUS did this by looking at all the XUNAME's in
the system, but looking at the source it looks like it just reads TTY\ 6.
Wierd!
\1f
Date: 3 July 1983 09:44 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Sender: DEVON @ MIT-MC
Subject:  Artificial Intuition?
To: BUG-ARGUS @ MIT-MC
cc: BUG-ITS @ MIT-MC


This is CSTACY.  I sat down at DEVON's console here just now, where
DEVON had a disowned ARGUS looking for any CSTACY's.  I started up an
EMACS to look at something.  I am sure you can imagine my surprise
when I saw:  [Here is CSTACY].

Startled, I ^Zd out of the EMACS I took my hands off the keyboard.
Ever dutiful, ARGUS barked:  [There goes CSTACY].  
I suppose this bug has something to do with my having typed CSTACY$^S
before running the EMACS.  If it does not, congratulations!

\1f
SHAWN@MIT-ML 06/29/83 21:42:38 Re: wish list
To: (BUG ITS) at MIT-ML

I *WISH* ITS had a UNIX(tm) type GREP command.

                -Shawn
\1f
Date: 29 June 1983 17:19 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  CORBLK and .ACCESS interaction.
To: BUG-ITS @ MIT-MC

Here is a minimal case of some lossy interaction between CORBLKing and
.ACCESSing the same file:

        .call [setz ? sixbit /open/ ? [.uii,,dsk] ? [sixbit /dsk/]
                [sixbit /names/] ? [sixbit />/] ? setz [sixbit /.mail./]]
         .lose %lsfil
        ;;These next two are not necessary for the misbehavior, but help to
        ;;make it more obvious later:
        .access dsk,[100]
        .iot dsk,a
        .access dsk,[2000]
        .iot dsk,b
        .access dsk,[0]
        .call [setz ? sixbit /corblk/ ? movei %cbndr ? movei %jself
                movei 7 ? setzi dsk]
         .lose %lssys
        .access dsk,[100]
        .iot dsk,b

At the end of this sequence, A and B should obviously contain the same
thing, but they don't.  Typically B will get the contents of location 2100,
rather than 100.  It is not important what file you use, I just chose
.MAIL.;NAMES > out of randomness.
\1f
Date: 21 June 1983 09:01 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: cli interrupts and emacs
To: PGS @ MIT-OZ
cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC

    Date: Tuesday, 21 June 1983, 04:23-EDT
    From: Patrick Sobalvarro <PGS@MIT-OZ>

    I guess I'm a loser.  I do use MODLIN.
So am I, and so do I.  I'd like to be a winner who uses MODLIN, though.
\1f
Date: Tuesday, 21 June 1983, 04:30-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: HAA@MIT-MC, BUG-ITS@MIT-MC
In-reply-to: The message of 2 Jun 83 21:27-EDT from Herschell A. Andrews <HAA>

    Date: 2 June 1983 21:27 EDT
    From: Herschell A. Andrews <HAA>
    To:   BUG-ITSTTY

    Does anyone know why my vt52 emuator suddenly started losing? It works
    fine on cmuc but loses bad on ITS. My software tty doesn't work either.
    Has something changed?

I tried running a vt52 connected directly to MC and had no trouble; I'd say the
trouble is probably in your emulator.  Or have you figured the problem out
already?
\1f
Date: Tuesday, 21 June 1983, 04:23-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
Subject: cli interrupts and emacs
To: KMP@MIT-MC
CC: BUG-ITS@MIT-MC, BUG-EMACS@MIT-MC
In-reply-to: The message of 21 Jun 83 04:05-EDT from Kent M. Pitman <KMP at MIT-MC>

    Date: 21 June 1983 04:05 EDT
    From: Kent M. Pitman <KMP @ MIT-MC>

    Do you use the MODLIN library? (For reasons I have never traced down, having
    this loaded seems to defeat Emacs' ability to recognize the tty having been
    potentially munged by superior typeout.) If you don't use the MODLIN library,
    perhaps you are a new data point.

I guess I'm a loser (not a new data point, ha ha).
I do use MODLIN.
\1f
Date: 21 June 1983 04:05 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Sender: ___004 @ MIT-MC
Subject: cli interrupts and emacs
To: PGS @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC

Do you use the MODLIN library? (For reasons I have never traced down, having
this loaded seems to defeat Emacs' ability to recognize the tty having been
potentially munged by superior typeout.) If you don't use the MODLIN library,
perhaps you are a new data point.
\1f
Date: 21 June 1983 03:58 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  cli interrupts and emacs
To: PGS @ MIT-MC
cc: BUG-EMACS @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 21 Jun 1983 01:27 EDT from Patrick G. Sobalvarro <PGS>

    Date: 21 June 1983 01:27 EDT
    From: Patrick G. Sobalvarro <PGS>
    Correct me if I'm wrong, but once upon a time I seem to remember having
    Emacs uderstand that I'd gotten my screen bashed and redisplay it after a
    CLI interrupt as soon as I typed a character.  This was a nice feature,
    something Twenex emacs couldn't do because of the way tty messages work
    there.  Well, it doesn't work anymore.  After a CLI interrupt, when I
    type characters, my Emacs doesn't redisplay at all.  It doesn't do anything
    until I type something like ^L, which is an ECHOIN break character.  Is
    ECHOIN broken?

CStacy has complained of something like this in the past.  DCP, I believe,
claimed to have seen this too.  I have never seen it.  Is it reproducable?

(I don't see how ECHOIN can itself be at fault, this works by having Emacs
enable %PIATY interrupts, but perhaps emacs does does something bogus when
it finds that this interrupt occured during an ECHOIN.  I am pretty sure I
have tested that case trying to reproduce this lossage, but I have never
seen it fail...  I just tried to find the source of TECO, but I couldn't, I
wonder where it is?)
\1f
Date: 21 June 1983 01:27 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
Subject: cli interrupts and emacs
To: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC

Correct me if I'm wrong, but once upon a time I seem to remember having
Emacs uderstand that I'd gotten my screen bashed and redisplay it after a
CLI interrupt as soon as I typed a character.  This was a nice feature,
something Twenex emacs couldn't do because of the way tty messages work
there.  Well, it doesn't work anymore.  After a CLI interrupt, when I
type characters, my Emacs doesn't redisplay at all.  It doesn't do anything
until I type something like ^L, which is an ECHOIN break character.  Is
ECHOIN broken?
\1f
Date: 11 June 1983 04:19 EDT
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: DUMP
To: CSTACY @ MIT-MC
cc: PGS @ MIT-ML, BUG-ITS @ MIT-MC, Moon @ SCRC-TENEX

i have in hand the relevant tapes from ai's last full dump.  i expect to
load the .tape files onto ml one dir at a time and then move them to dm.
then i'll deal with the updates from the various incr.  dump tapes after
last august. chris, i will let you know when the dirs from the full
dump are in place; that should be good enough for testing..
\1f
Date: 10 June 1983 17:40 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: DUMP
To: Moon @ SCRC-TENEX
cc: CSTACY @ MIT-MC, PGS @ MIT-MC, CENT @ MIT-MC, BUG-ITS @ MIT-MC

The issue was disk space.  I had been aware of the tape drive incompatibility
when i suggested DM.  People will just have to run the FIND and do the
loading on different machines.

\1f
Date: 10 June 1983 02:59 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  DUMP
To: Moon @ SCRC-TENEX
cc: PGS @ MIT-MC, CENT @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 10 Jun 1983 02:26-EDT from David A. Moon <Moon at SCRC-TENEX>


    Date: Friday, 10 June 1983, 02:26-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
    To:   Christopher C. Stacy <CSTACY>
    cc:   PGS, CENT, BUG-ITS
    Re:   DUMP

        Date: 7 June 1983 14:01 EDT
        From: Christopher C. Stacy <CSTACY @ MIT-MC>
        I have put a new command into DUMP.
        DFIND does a find for a deceased ITS.
        If someone reloads the .TAPEn; directories from AI
        onto DM, I will test it and you should be in business.
        The directories should be named %TAPEn; instead of .TAPEn;.

    But AI's tape drive was 7-track and DM's is 9-track.  So DM can't read AI's tapes.

Which machine they go on is just a variable in DUMP.
The people who wanted this had picked DM, probably due to the
number of free UFD slots...
\1f
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 10-Jun-83 02:33:36-EDT
Date: Friday, 10 June 1983, 02:26-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: DUMP
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: PGS@MIT-MC, CENT@MIT-MC, BUG-ITS@MIT-MC
In-reply-to: The message of 7 Jun 83 14:01-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: 7 June 1983 14:01 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    I have put a new command into DUMP.
    DFIND does a find for a deceased ITS.
    If someone reloads the .TAPEn; directories from AI
    onto DM, I will test it and you should be in business.
    The directories should be named %TAPEn; instead of .TAPEn;.

But AI's tape drive was 7-track and DM's is 9-track.  So DM can't read AI's tapes.
\1f
Date: 9 June 1983 15:57 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Bug in ">" handling by Archive Device
To: BUG-ARC @ MIT-MC
cc: BUG-ITS @ MIT-MC

If two files exist on an archive, FOO A and FOO B, then if you open FOO >
for input, you'll get FOO A open, not FOO B.

On DSK, FOO B will be opened.
--kmp
\1f
Date: 7 June 1983 14:01 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: DUMP
To: PGS @ MIT-MC, CENT @ MIT-MC
cc: BUG-ITS @ MIT-MC


I have put a new command into DUMP.
DFIND does a find for a deceased ITS.
If someone reloads the .TAPEn; directories from AI
onto DM, I will test it and you should be in business.
The directories should be named %TAPEn; instead of .TAPEn;.

\1f
Date: 6 Jun 1983  18:32 EDT (Mon)
From: Ian Macky <Ian@MIT-OZ>
To:   David C. Plummer <DCP@MIT-MC>
Cc:   BUG-ITS@MIT-MC
In-reply-to: Msg of 30 May 1983 16:30 EDT from David C. Plummer <DCP at MIT-MC>

    Date: 30 May 1983 16:30 EDT
    From: David C. Plummer <DCP at MIT-MC>
    To:   BUG-ITS at MIT-MC
    Received: from MIT-MC by MIT-OZ; Mon 30 May 83 16:33:25-EDT

    Anybody know where the source for UNTALK is hiding?  The creation
    date on SYS2;TS UNTALK is October 1977 (before the days when
    Midas insterted assembly information).  It isn't on MC:SYSEN*;

Ellen knew where it was, so I loaded a copy in my directory for the
time being - it's GREN;UNTALK 87 (and there's UNTALK MAIL, too).  It
calls for an .INSRT file of UNCOLA's doing (UNCOLA;.MIDAS >) which was
not on the same full-dump tape, so I dunno where it is.
\1f
Date: 6 June 1983 15:18 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

I'll hack up DUMP to look on DM, tonite when I come in.
I cant imagine it taking more than 20 minutes...
\1f
Date: 6 June 1983 15:13 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
Sender: PGS0 @ MIT-MC
To: BUG-ITS @ MIT-MC

I suggest that we install the AI:.TAPEn; directories on some ITS machine as
AITAPn; and hack up a version of DUMP so that it'll be possible to find tapes
when we need them.  The problem is that there are no hardcopy dump logs
except for the ones Penny did of the last couple of dumps.  The hacking of
DUMP should be trivial if we want to use only the FIND command; it can
probably be done with translations.  Glenn says that we can probably squeeze
the directories on DM, and we might as well, because no one else is using the
machine these days.

I nominate Chris to do this.  All in favor say aye.

P.S.  Ty and I once did an incremental dump of AI to ML thru the MLDEV using
only translations.  It took a long time, but, hey, it worked.
\1f
Date: 3 June 1983 09:07 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: GSB @ MIT-ML
cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
In-reply-to: Msg of 06/02/83 23:17:22 from GSB at MIT-ML


    Date: 06/02/83 23:17:22
    From: GSB at MIT-ML

    Inqupd is writing out its new database to LSR1 >.  When it runs out of
    disk space, it closes the incompletely written file.

I think I have fixed my brain damage INQUPD.
Now it writes out the provisional version to NLSR1 >, and disk-full
interrupts prevent it from installing it (the interrupt handler had a
bogus instruction in it.) It will still leave the incomplete version
around as NLSR1. Later, I will put something in to get this deleted.

    In this case, DDT loses its ass when starting up when not-logged-in.
    It bugs out before it gets the system symbol table mapped in,
    making debugging incredibly difficult.

Maybe DDT should do all its initialization before logging the user in
(and needing to find his hsname.)  I thought it already did this,
but will look at.

    When CORBLK is doing block-mode map-from-disk, it apparently just
    tics the aobjn pointer away leaving MPV pages after end-of-file;
    no indication that you ran off the end.

Is this an ITS bug?

    I made two invalid assumptions when looking at this broken system
    this afternoon, which caused me to believe that it was horribly trashed.
    (Maybe it is.  It crashed randomly twice before, which lent great credence
    to its being trashed.)  One was that DDT would not fail so grossly with
    the inquir database smashed.  The other was that corblk would not 
    intentionally act the way it did.

ML *is* having some kind of trouble - COMSAT is repeat processing
messages from May somehow. I guess the QML is broken somehow?
Was it restored from tape, or is something even worse happenning?
See BUG-MAIL.

    I have renamed INQUPD BIN to INQUPD FUCKED.

I put the current database and program on ML.
Let me know if there are more bugs with it (it ran fine for three
weeks on MC, but of course some of the error code did not get
exxcercised there.)
\1f
Date: Thursday, 2 June 1983  15:59-EDT
From: MOON at SCRC-TENEX
To:   Patrick Sobalvarro <PGS at MIT-OZ>
Cc:   bug-its at MIT-MC, BUG-LISPM at MIT-OZ
In-reply-to: The message of 2 Jun 1983 07:57-EDT from Patrick Sobalvarro <PGS@MIT-OZ>

    Date: Thursday, 2 June 1983, 07:57-EDT
    From: Patrick Sobalvarro <PGS@MIT-OZ>

    If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at
    the end.  I don't see these in Emacs.  If I delete the nulls and write the file
    and read it again, they're back.  With nulls, the file has 115 characters in
    it.

I believe this is a bug in the ARC: device; it stores file lengths in words
rather than in characters.  Emacs deletes all sorts of characters at the ends
of files in order to get around bugs like this, but the ITS file server is
not as careful (or not as willing to cover up for the deficiencies of other
programs).
\1f
Date: Thursday, 2 June 1983, 07:57-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: BUG-LISPM@MIT-OZ
CC: bug-its@MIT-MC

In MIT-Specific 19.3, System 94.23, ZMail 50.9, microcode 238, ZM GC@0,
on Lisp Machine Thirty-one:

If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at
the end.  I don't see these in Emacs.  If I delete the nulls and write the file
and read it again, they're back.  With nulls, the file has 115 characters in
it.
\1f
Date: 1 June 1983 19:53 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: PGS @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC,
    BUG-MINITS @ MIT-MC

    Date: 1 June 1983 01:02 EDT
    From: Patrick G. Sobalvarro <PGS @ MIT-MC>
    In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy <CStacy>

    Wrongo, Roscoe.  First, since there are never bugs in my code, you should
    have known you were wrong.  Second, when you connect to MC via a terminal
    concentrator, I'll bet you use Supdup, not Telnet.  If you use Supdup, then
    MC doesn't know you're on an Ann Arbor.  In fact, when I use Telnet and do
    :tctyp aaa, I don't miss any characters in INQUIR.  I provided 5ms of padding
    for %tdeof in the AAA code in TS3TTY, and that turns out to be more than
    enough.

Your response was much better than mine could have been.  I was a
little mystified to learn that Stacy didn't know you WROTE the
ITS code for AAAs.

    If it works on the Lisp Machine, then MINITS is probably responsible, because
    it provides no padding at all.

That is true.  Perhaps if I find some time this summer and get
marginally bored I will correct this situation.

Anyway, the cause of the manifestation (call it a bug if you
wish) is CStacy's overeagerness to keep the screen as blank as
possible.  I think what is happening is that more than one %TDCLR
is being sent before the text (if entered with :INQUIR DCP).
This causes any AAA without padding to drop characters.

[Also, the following are defined
        .CS=.7TYP 4,[ASCIZ /\10C/]
        .CSL=.7TYPL 4,[ASCIZ /\10C/]
but are used in only 4 of the 10 places where they could be, the
other six are
        .7TYP 4,[ASCIZ /\10C/]
There are many other occurences of \10C scattered throughout.]
\1f
Date: 1 June 1983 02:04 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: PGS @ MIT-MC
cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: Msg of 1 Jun 1983 01:02 EDT from Patrick G. Sobalvarro <PGS>


    Date: 1 June 1983 01:02 EDT
    From: Patrick G. Sobalvarro <PGS>
    To:   CSTACY
    cc:   BUG-INQUIR, BUG-ITS, BUG-MINITS

    It says "What next? ->", and then when I type a ^L, it
    says "Command-->"<cr>.

I just changed these to be a little better.

    Wrongo, Roscoe.  First, since there are never bugs in my 
    code, you should have known you were wrong.  Second, when you connect
    to MC via a terminal concentrator, I'll bet you use Supdup...
    If it works on the Lisp Machine, then MINITS is probably
    responsible, because it provides no padding at all.

Oh yeah.  I guess I forgot to turn my brain on tonite!
\1f
Date: 1 June 1983 01:02 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC
In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy <CStacy>

    Date: Wednesday, 1 June 1983, 00:30-EDT
    From: Christopher C. Stacy <CStacy>
    To:   Patrick G. Sobalvarro <PGS>
    cc:   BUG-ITS, BUG-INQUIR

        Date: 31 May 1983 16:21 EDT
        From: Patrick G. Sobalvarro <PGS @ MIT-MC>
        I enter INQUIR via INQUIR PGS.  The automagic listme that happens is
        broken; half of the characters in it are dropped. There is also a
        CR at the end of the command line that says Command--> 

    I have had this sometimes happen to me on an AAA, buit it never ever
    happens on a Lisp Machine SUPDUP connection.  I tried it just now.
    Just to make sure we are talking about the same program, the prompt
    is actually "What next? ->", right?

It says "What next? ->", and then when I type a ^L, it says "Command-->"<cr>.


        (incidentally, a more informative prompt [like, say, INQUIR>] would be 
        better). This character dropping reminds me of Unix.  The random cursor 
        motion reminds me of another operating system for PDP-10s.  I had 
        entered INQUIR only to change my net address to MC.

    This looks to me like it must be an ITS problem, since it only happens
    on certain terminal types, and since that part of INQUIR hasn't been
    modified.  I suspect that there is not enough padding after a clear
    screen operation for Ann Arbor terminals.  If no TS3TTY/AAA wizard
    speaks up within a few days, I will start experimenting with the ITS tty
    code to see if that fixes the problem.

Wrongo, Roscoe.  First, since there are never bugs in my code, you should
have known you were wrong.  Second, when you connect to MC via a terminal
concentrator, I'll bet you use Supdup, not Telnet.  If you use Supdup, then
MC doesn't know you're on an Ann Arbor.  In fact, when I use Telnet and do
:tctyp aaa, I don't miss any characters in INQUIR.  I provided 5ms of padding
for %tdeof in the AAA code in TS3TTY, and that turns out to be more than
enough.

If it works on the Lisp Machine, then MINITS is probably responsible, because
it provides no padding at all.
\1f
Date: Wednesday, 1 June 1983, 00:30-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
To: Patrick G. Sobalvarro <PGS at MIT-MC>
Cc: BUG-ITS at MIT-MC, BUG-INQUIR at MIT-MC
In-reply-to: The message of 31 May 83 16:21-EDT from Patrick G. Sobalvarro <PGS at MIT-MC>

    Date: 31 May 1983 16:21 EDT
    From: Patrick G. Sobalvarro <PGS @ MIT-MC>
    I enter INQUIR via INQUIR PGS.  The automagic listme that happens is
    broken; half of the characters in it are dropped. There is also a
    CR at the end of the command line that says Command--> 

I have had this sometimes happen to me on an AAA, buit it never ever
happens on a Lisp Machine SUPDUP connection.  I tried it just now.
Just to make sure we are talking about the same program, the prompt
is actually "What next? ->", right?

    (incidentally, a more informative prompt [like, say, INQUIR>] would be 
    better). This character dropping reminds me of Unix.  The random cursor 
    motion reminds me of another operating system for PDP-10s.  I had 
    entered INQUIR only to change my net address to MC.

This looks to me like it must be an ITS problem, since it only happens
on certain terminal types, and since that part of INQUIR hasn't been
modified.  I suspect that there is not enough padding after a clear
screen operation for Ann Arbor terminals.  If no TS3TTY/AAA wizard
speaks up within a few days, I will start experimenting with the ITS tty
code to see if that fixes the problem.

\1f
Date: 30 May 1983 16:30 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC

Anybody know where the source for UNTALK is hiding?  The creation
date on SYS2;TS UNTALK is October 1977 (before the days when
Midas insterted assembly information).  It isn't on MC:SYSEN*;
\1f
Date: Tuesday, 24 May 1983, 03:33-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: date-print on system console
To: Jeffrey P. Golden <JPG at MIT-MC>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 23 May 83 17:54-EDT from Jeffrey P. Golden <JPG at MIT-MC>

OK, the SYSJOB will additionally print the date on the console about every 50 lines.
This should get you at least one per page (why not?).
The feature is run when the two minute clock ticks.
\1f
Date: 23 May 1983 17:54 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: date-print on system console
To: BUG-ITS @ MIT-MC
cc: JPG @ MIT-MC

   KLH@MIT-MC 05/23/83 17:30:31
   To: JPG at MIT-MC
   CC: (BUG ITS) at MIT-MC
       JPG@MIT-MC 22 May 1983 13:22 EDT
       It would be nice if the system console had the date printed out more 
       frequently than once every several pages.
   The sysjob routines could count the number of LF's and trigger a new 
   date-print every so many lines (in addition to current time-based 
   interval).  This is what COMSAT does for its stats.  Probably once per 3 
   pages is enough?
If I could be assured that I could find the date somewhere in 3 consecutive 
pages if I only looked hard enough, that would be great!  So I like this.
 
   CSTACY@MIT-MC 05/23/83 01:38:43 Re:  IT IS NOW 1:39 ON MONDAY 23 MAY 1983
   To: JPG at MIT-MC
   CC: (BUG ITS) at MIT-MC
   I think it prints the date when the very slow clock ticks, about once
   every two hours; it also prints it when assorted random things happen.
   How often do you want to see it, and what console log events are you
   interested in having full timestamps for?
I like what KLH suggests better, but if I can't have that, I suppose 
once every half hour would be fine.  Since ITS does not have 
'auto-hangup' for its dialup lines, every now and then I have to find 
out who left a dialup line hung.  Then I can give the loser a stern 
warning.  By OS'ing the line I know the date and time the act was 
committed (and perhaps the loser's nickname!), but I need to look at 
the system console to get the login name.  
\1f
Date: 23 May 1983 17:30 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
To: JPG @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 22 May 1983 13:22 EDT
    From: Jeffrey P. Golden <JPG @ MIT-MC>

    It would be nice if the system console had the date printed out more 
    frequently then once every several pages.

The sysjob routines could count the number of LF's and trigger a new date-print
every so many lines (in addition to current time-based interval).  This
is what COMSAT does for its stats.  Probably once per 3 pages is enough?
\1f
Date: 23 May 1983 01:38 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  IT IS NOW 1:39 ON MONDAY 23 MAY 1983
To: JPG @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 22 May 1983 13:22 EDT from Jeffrey P. Golden <JPG>

    Date: 22 May 1983 13:22 EDT
    From: Jeffrey P. Golden <JPG>
    To:   BUG-ITS

    It would be nice if the system console had the date printed out more 
    frequently then once every several pages.

I think it prints the date when the very slow clock ticks, about once
every two hour; it also prints it when assorted random things happen.
How often do you want to see it, and what console log events are you
interested in having full timestamps for?
\1f
Date: 22 May 1983 13:22 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: BUG-ITS @ MIT-MC

It would be nice if the system console had the date printed out more 
frequently then once every several pages.
\1f
Date: 22 May 1983 06:27 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


When I come in over a TAC, I dont seem to be able to get meta bits
through.  Setting +%TPMTA doesn't work (it does on dialups though).
Am I forgetting to do something (like a TAC command) or was I dreaming
when I thought I had used meta keys over TIPs before?
\1f
Date: 19 May 1983 23:35 EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: dirsiz
To: BUG-ITS @ MIT-MC

:call dirsiz claims the second arg sets quota, the source says (and uses)
LH of second arg.
\1f
Date: 13 May 1983 16:08 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: one more time...
To: BUG-ITS @ MIT-MC, BUG-INQUIR @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC, IAN @ MIT-OZ


The new Inquire database is again experimentally installed
on MC only.  All bugs found last time appear to have been
fixed.  Send me mail if the old one needs to be re-installed
or anything.

Chris
\1f
Date: 11 May 1983 11:36 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: BUG-INQUIRE @ MIT-MC, ian @ MIT-OZ


I de-installed the new INQUIRE  database and programs, because after
a few real users I found some bugs.  Will try again tomorrow.
l
\1f
Date: 11 May 1983 00:07 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: new Inquire database and stuff is being tested on MC
To: BUG-INQUIRE @ MIT-MC
cc: ALAN @ MIT-MC, BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC,
    ian @ MIT-OZ


OK, the new LSR1 database is installed on MC only.
Experimental versions of INQUIR, LOOKUP, NAME, and INQUPD are running here.
I have tested each of these, and they seem to work.
If anyone notices anything very bad going on, send me mail.

Note that the user interface on ITS does not let you send entries
to Twenex, only the other way around.  This is because I could not
bring myself to deal with the INQUIR source code.  I will fix this
sometime by getting up more guts, or just rewriting it.  Inquires
on all the ITS will be the same.  This has the good side effect that
if I have badly blown it this evening, you can copy a database to MC
from one of the other machines and de-install the experimental programs.

Note that the databases are not in a completely compatible format.
LSRTNS has been updated to the new format.
\1f
Date: 8 May 1983 23:30 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ARCHIVE @ MIT-MC

I replied to SJOBRG.
\1f
Date: 8 May 1983 23:25 EDT
From: Robert W. Sjoberg <SJOBRG @ MIT-MC>
To: BUG-ARCHIVE @ MIT-MC

Can someone please point me to documentation (if any) on the format of the
ITS archive files?  I need enough information to be able to extract
directory information and file contents (I don't plan on adding anything
or deleting, just reading) from an archive file.  Thanks.
--Bob
\1f
Date: Sunday, 8 May 1983, 06:59-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: [Re: Is I.T.S. mistaken as to today's date?]
To: Glenn S. Burke <GSB at MIT-ML>
Cc: BUG-EXPIRE at MIT-DMS, BUG-ITS at MC, CENT at MIT-ML,
    SYS-OPERATING-TROUBLE at MIT-DMS
In-reply-to: The message of 8 May 83 04:56-EDT from Glenn S. Burke <GSB at MIT-ML>

Well, I just hacked GMSGS to do just expire hacking if it starts under
the job name EXPIRE, and I hacked TARAKA DEMSTR on DM to start it up.
So, now everday GMSGS will be run and the directory should stay
cleaned.  I have not tested this, so let me know if there are
problems, but it really should work.
\1f
Date: 7 May 1983 02:55 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: SYSHAK;
To: BUG-ITS @ MIT-MC
cc: JPG @ MIT-MC


I merged SYSHAK back into SYSTEM;.
\1f
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 6-May-83 20:14:20-EDT
Date: Friday, 6 May 1983, 20:27-EDT
From: David A. Moon <Moon@SCRC-TENEX>
To: Jeffrey J Tyrone Sealy <TY@MIT-MC>
Cc: BUG-ITS@MIT-MC
In-reply-to: The message of 6 May 83 11:28-EDT from Jeffrey J Tyrone Sealy <TY at MIT-MC>

    Date: 6 May 1983 11:28 EDT
    From: Jeffrey J Tyrone Sealy <TY @ MIT-MC>
    The console-11 died today, and so ITS was running along fine
    but the cty was not doing anything and the swr was not being
    read.  What is the optimum least obnoxious thing to do in
    this sort of event?
Reboot the 11.  Boot, RP0, P IOELEV, ITS ON.  If this makes ITS crash
as it sometimes does continue it.
\1f
Date: 6 May 1983 11:28 EDT
From: Jeffrey J Tyrone Sealy <TY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: Moon @ SCRC-TENEX

The console-11 died today, and so ITS was running along fine
but the cty was not doing anything and the swr was not being
read.  What is the optimum least obnoxious thing to do in
this sort of event?
\1f
Date: Thursday, 5 May 1983  15:02-EDT
From: MOON at SCRC-TENEX
To:   Christopher C. Stacy <CStacy at MIT-MC>
Cc:   BUG-ITS at MIT-MC
Subject: STLGET
In-reply-to: The message of 5 May 1983 04:01-EDT from Christopher C. Stacy <CStacy at MIT-MC>

Well I guess it wouldn't hurt to make STLGET return a fifth value,
although probably all the programs that call it look in the memory of
the user whose index is the 4th value anyway.
\1f
Date: 5 May 1983 04:12 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: removing AI from stuff
To: BUG-ITS @ MIT-MC

TALK (WHOJ,U,WHOM,etc) fixed.
\1f
Date: Thursday, 5 May 1983, 04:01-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: STLGET
To: David A. Moon <Moon at SCRC-TENEX>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 5 May 83 02:56-EDT from David A. Moon <Moon at SCRC-TENEX>

    Date: Thursday, 5 May 1983, 02:56-EDT
    From: David A. Moon <Moon@SCRC-TENEX>
        Date: 2 May 1983 08:05 EDT
        From: Christopher C. Stacy <CSTACY @ MIT-MC>
        It would be nice if STLGET could actually return the HOSTS3 address
        of the host being served.  It's sort of a crock to parse the name
        of the host, which might not always fix in six characters anyway.
        I am not sure if it is reasonable to try to get this info, but if
        I get ambitious I'll find out.
    You can get it from some standard place in the memory of the server job,
    I think.

Right; it's documented in the TELSER source that a bunch of variables
should not move (ttyloc, binary-mode flag, host. etc.) but I didn't
think it was a good idea for the system to make even that assumption
about what the telnet server is like...
\1f
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 5-May-83 03:21:42-EDT
Date: Thursday, 5 May 1983, 03:20-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: SYS:
To: Christopher Stacy <CStacy@MIT-OZ>
Cc: BUG-ITS@MIT-MC, ALAN@MIT-MC, DEVON@MIT-MC
In-reply-to: The message of 27 Apr 83 08:41-EDT from Christopher Stacy <CStacy at MIT-OZ>

    Date: Wednesday, 27 April 1983, 08:41-EDT
    From: Christopher Stacy <CStacy at MIT-OZ>
    I have an idea for implementing Twenex-like logical names on ITS.
    My idea for getting around this is a to extend JOBRET so that there is
    a way for the BDH to tell the system: "I am going away now. Disconnect
    the user from me and retry the OPEN call using these args I am giving
    you."
This sounds like a good idea to me.
\1f
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 5-May-83 02:57:26-EDT
Date: Thursday, 5 May 1983, 02:56-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: STLGET
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: BUG-ITS@MIT-MC
In-reply-to: The message of 2 May 83 08:05-EDT from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: 2 May 1983 08:05 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    It would be nice if STLGET could actually return the HOSTS3 address
    of the host being served.  It's sort of a crock to parse the name
    of the host, which might not always fix in six characters anyway.
    I am not sure if it is reasonable to try to get this info, but if
    I get ambitious I'll find out.
You can get it from some standard place in the memory of the server job,
I think.
\1f
Date: 4 May 1983 23:36 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

I flushed AI from :INSTAL
\1f
CENT@MIT-ML 05/03/83 03:23:21 Re: *msg list info
To: DEVON at MIT-MC
CC: (BUG ITS) at MIT-MC
    Date: 3 May 1983 01:04 EDT
    From: Devon S. McCullough <DEVON @ MIT-MC>
    To: BUG-ITS @ MIT-MC
    Maybe it would be a good idea to be able to say :whois *ITS and get a
    description of what sort of messages should be addressed there,
    likewise for other magic mailing addressees.  I wasn't able to find the
    info from :info even thought I am fairly sure it's in there somewhere..

no, there is already a meaning too close to *its for your suggestion to be
wise: :whois @ITS would do a :whois on everyone logged in on the ITSs (it
doesn't work quite right now because AI is gone; could someone dig into
:name or wherever this is hacked in and remove AI references?). this aside,
i don't know whether your idea could even be made to work (someone who
knows more about :whois and mailing lists might be able to tell you).

If you had looked in the menu for the MAIL subtree, you would have found
the node Announcements (also available from the top-level menu and through
a footnote from the new-user-info subtree), which gets you to this
information. for that matter, it's also mentioned in the mailing lists file
right where the sysmsg lists are defined..
\1f
Date: 3 May 1983 01:04 EDT
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC

Maybe it would be a good idea to be able to say :whois *ITS and get a description of what sort of messages should be addressed there, likewise for other magic mailing addressees.  I wasn't able to find the info from :info even thought I am fairly sure it's in there somewhere.
\1f
Date: 2 May 1983 14:04 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  AI
To: BUG-ITS @ MIT-MC, ARPANET-BBOARDS @ MIT-ML


The AI KA10 has been flushed,
please update your programs.



    ...Each evening from December to December
    Before you drift asleep upon your cot
    Think back on all the tales that you remember
    Of Camelot

        Ask every person
        If he's heard the story
        And tell it loud and clear
        If he has not
        That once there was a fleeting wisp of glory
        Called Camelot

            Don't let it be forgot
            That once there was a spot
            For one brief shining moment
            That was known as Camelot....


[From the Lerner and Loewe musical "Camelot"]
\1f
Date: 2 May 1983 08:05 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


It would be nice if STLGET could actually return the HOSTS3 address
of the host being served.  It's sort of a crock to parse the name
of the host, which might not always fix in six characters anyway.
I am not sure if it is reasonable to try to get this info, but if
I get ambitious I'll find out.
\1f
Date: 2 May 1983 02:07 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


In ITS 1342, the STLGET call returns a fourth value, as documented
below.  (Note that in previous ITS versions, Val 4 was present but only
had the user index; this former behaviour was not documented.)

STLGET: get information from Server Telnet

        arg 1   a <TTY>

        val 1   XJNAME of server telnet
        val 2   TRMNAM of server telnet
                This is the sixbit name of the host connected to.
        val 3   SNAME of server telnet
        val 4   In LH: STY status bits
                In RH: index of telnet server job which owns the STY.

        This call can be used to find out where in the network
        a TTY really is.

        The STY status bits are from the STYSTS table in ITS.
        Some of the more interesting ones include:
        %SSNET==4000    ;4.3 = 1 => THIS STY CONNECTED TO SOME NET SOCKETS.
        %SSCHA==2000    ;4.2 = 0 FOR ARPANET, 1 FOR CHAOS NET
        %SSTCP==1000    ;4.1 = 1 for TCP internet (%SSCHA must be 0)

\1f
Date: 1 May 1983 01:58 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  SYS:
To: ED @ MIT-MC
cc: BUG-ITS @ MIT-MC, DEVON @ MIT-MC
In-reply-to: Msg of 30 Apr 1983 21:25 EDT from Ed Schwalenberg <ED>

    Date: 30 April 1983 21:25 EDT
    From: Ed Schwalenberg <ED>

    Just for the sake of whatever ancient programs might depend on the
    behavior, I would strongly recommend that SYS: be equivalent to
    DSK:SYS; as the documentation states.

Yeah, I was gonna mention a couple of days ago that it would be best to
pick a new device name to have this behavior.  SYSTEM:?

CStacy's suggestion about giving JOBRET the ability to cause the OPEN to
retry with different arguments is a good one I think.  (I wonder if a
kludge is possible even currently by giving the loser a translation and
then causing him to get PCLSR'ed?  That would be a wierd hack!  The problem
would be cleaning up all of the translations that would accumulate...)  On
the other hand I would really hate to have SYSTEM: (or whatever) be a
jobdevice if it is going to be used all the time by DDT to find binarys.
\1f
Date: 30 April 1983 21:25 EDT
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: SYS:
To: ALAN @ MIT-MC
cc: DEVON @ MIT-MC, BUG-ITS @ MIT-MC

Just for the sake of whatever ancient programs might depend on the behavior,
I would strongly recommend that SYS: be equivalent to DSK:SYS; as the
documentation states.

While on the subject of ITS devices, I'm spending idle moments compiling a
document on them- for each device, listing where it is implemented, what it
does, what machines have (or had) it, what option bits for it exist, etc.
Contributions are solicited, particularly by those of you who delight in
using obscure devices and have thus discovered unusual properties (like nil
documentation!).
\1f