From MOON at MIT-MC  Wed Dec 26 00:00:00 1984
From: MOON at MIT-MC (David A. Moon)
Date: 26 December 1984, 00:00
Subject: How to take a dump of a machine that had been running?
Message-ID: <mailman.1029.1479821124.4695.its@nocrew.org>

    Date: Mon, 24 Dec 84 22:12 EST
    From: Kent M Pitman <KMP at 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.

From KMP at MIT-MC.ARPA  Tue Dec 25 04:12:00 1984
From: KMP at MIT-MC.ARPA (Kent M Pitman)
Date: Dec 24 84 22:12 EST
Subject: How to take a dump of a machine that had been running?
Message-ID: <mailman.1030.1479821124.4695.its@nocrew.org>

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

From KLH at MIT-MC  Mon Dec 24 00:00:00 1984
From: KLH at MIT-MC (Ken Harrenstien)
Date: 24 December 1984, 00:00
Subject: MC being down today
Message-ID: <mailman.1031.1479821124.4695.its@nocrew.org>

Normally the best thing to do with a dead or comatose system is dump
it, so that the corpse can be examined later.

From KMP at MIT-MC  Mon Dec 24 00:00:00 1984
From: KMP at MIT-MC (Kent M Pitman)
Date: 24 December 1984, 00:00
Subject: MC being down today
Message-ID: <mailman.1032.1479821124.4695.its@nocrew.org>

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

From PGS%MIT-OZ at MIT-MC.ARPA  Sun Dec 23 16:59:00 1984
From: PGS%MIT-OZ at MIT-MC.ARPA (PGS%MIT-OZ at MIT-MC.ARPA)
Date: Dec 23 1984  10:59 EST
Subject: Heath 19 terminal control codes
In-Reply-To: Msg of 22 Dec 1984  15:54-EST from Peter Szolovits <PSZ at MIT-MC>
Message-ID: <PGS.12073740865.BABYL@MIT-OZ>

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.

From PSZ at MIT-MC  Sat Dec 22 00:00:00 1984
From: PSZ at MIT-MC (Peter Szolovits)
Date: 22 December 1984, 00:00
Subject: Heath 19 terminal control codes
Message-ID: <mailman.1033.1479821124.4695.its@nocrew.org>

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.

From CSTACY at MIT-MC  Sat Dec 22 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 22 December 1984, 00:00
Subject: obscure bug in trivial feature
In-Reply-To: Msg of 22 Dec 1984 02:52-EST from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.1034.1479821124.4695.its@nocrew.org>

OK, the SYSDSK thing works now.

From JNC at MIT-XX.ARPA  Sat Dec 22 00:00:00 1984
From: JNC at MIT-XX.ARPA (J. Noel Chiappa)
Date: Sat 22 Dec 84, 00:00
Subject: MC busted, fixed
Message-ID: <mailman.1035.1479821124.4695.its@nocrew.org>

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

From CSTACY at MIT-MC  Sat Dec 22 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 22 December 1984, 00:00
Subject: No subject
Message-ID: <mailman.1036.1479821124.4695.its@nocrew.org>

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.

From CSTACY at MIT-MC  Sat Dec 22 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 22 December 1984, 00:00
Subject: obscure bug in trivial feature
Message-ID: <mailman.1037.1479821124.4695.its@nocrew.org>

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

From CSTACY at MIT-MC  Sat Dec 22 00:00:00 1984
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: 22 December 1984, 00:00
Subject: obscure bug in trivial feature
Message-ID: <mailman.1038.1479821124.4695.its@nocrew.org>

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

From GSB at MIT-MC  Tue Dec 11 00:00:00 1984
From: GSB at MIT-MC (Glenn S. Burke)
Date: 11 December 1984, 00:00
Subject: highly secure systems
Message-ID: <mailman.1039.1479821124.4695.its@nocrew.org>

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.

From ALAN at MIT-MC  Sun Dec  9 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 9 December 1984, 00:00
Subject: 7LP:
Message-ID: <mailman.1040.1479821124.4695.its@nocrew.org>

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 to DDT to see who's output is in front of yours.

From ALAN at MIT-MC  Sat Dec  8 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 8 December 1984, 00:00
Subject: Not about: RU-BLUE
In-Reply-To: Msg of 8 Dec 1984 07:38-EST from Ken Harrenstien <KLH>
Message-ID: <mailman.1041.1479821124.4695.its@nocrew.org>

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

From KLH at MIT-MC  Sat Dec  8 00:00:00 1984
From: KLH at MIT-MC (Ken Harrenstien)
Date: 8 December 1984, 00:00
Subject: RU-BLUE
Message-ID: <mailman.1042.1479821124.4695.its@nocrew.org>

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.

From ALAN at MIT-MC  Sat Dec  8 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 8 December 1984, 00:00
Subject: BOJ device .UAI mode SIOT
Message-ID: <mailman.1043.1479821124.4695.its@nocrew.org>

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.

From ALAN at MIT-MC  Thu Dec  6 00:00:00 1984
From: ALAN at MIT-MC (Alan Bawden)
Date: 6 December 1984, 00:00
Subject: RU-BLUE
In-Reply-To: Msg of 6 Dec 1984 02:34-EST from Glenn S. Burke <GSB>
Message-ID: <mailman.1044.1479821124.4695.its@nocrew.org>

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

From GSB at MIT-MC  Thu Dec  6 00:00:00 1984
From: GSB at MIT-MC (Glenn S. Burke)
Date: 6 December 1984, 00:00
Subject: RU-BLUE
Message-ID: <mailman.1045.1479821124.4695.its@nocrew.org>

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

        Date: 5 Dec 1984  22:49 EST (Wed)
        From: Martin David Connor <MARTY%MIT-OZ at 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.

From CStacy at MIT-MC.ARPA  Thu Dec  6 06:02:00 1984
From: CStacy at MIT-MC.ARPA (Christopher C. Stacy)
Date: Dec 6 84 00:02 EST
Subject: RU-BLUE
In-Reply-To: <MARTY.12069151570.BABYL@MIT-OZ>
Message-ID: <mailman.1046.1479821124.4695.its@nocrew.org>

    Date: 5 Dec 1984  22:49 EST (Wed)
    From: Martin David Connor <MARTY%MIT-OZ at 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.