github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-02-15 04:16:21 +00:00
Code Issues Releases Wiki Activity

Various ITS documentation files.

Browse Source
This commit is contained in:
Lars Brinkhoff
2018-05-13 20:21:37 +02:00
parent 69544b3832
commit 61b0dd1dfa
8 changed files with 8855 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

713
doc/sysdoc/peek.bugs Executable file
View File

@@ -0,0 +1,713 @@
Date: Fri, 5 May 89 14:14:14 EDT
From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
To: BUG-PEEK@AI.AI.MIT.EDU
Message-ID: <591317.890505.DEVON@AI.AI.MIT.EDU>
watching the comsat stats file with 1C, it said
MPV; DSKTY3+1>>ILDB B,A B/ 0,,65 a/ 350700,,32000
d/ 134
p/ c,,pdl+2
pdl+2/ cam dsktlp+2
pdl+1/ cam disk+23
pdl/ cam beg8+1

Date: Sun, 20 Mar 88 13:48:17 EST
From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
To: BUG-PEEK@AI.AI.MIT.EDU
Message-ID: <344793.880320.DEVON@AI.AI.MIT.EDU>
I was sitting in 0C watching COMSAT and I got
MPV; 11772>>ILDB 2,1 2/ 151 1/ AOS 16,32000
with no apparent provocation. A day or so ago I got MPV right on
the heels of a **MORE** (not --more-- which was strange) but I
didn't notice where. 31777 seems to be the last word of the buffer
being monitored.

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Jan 87 00:29:12 EST
Date: Wed, 21 Jan 1987 00:25 EST
Message-ID: <SRA.12272592709.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
Subject: PEEK shouldn't ever PCLSR anyone
In-reply-to: Msg of 18 Jan 1987 22:51-EST from Alan Bawden <ALAN@AI.AI.MIT.EDU>
Date: Sunday, 18 January 1987 22:51-EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
In the case of the DQ device screw, I don't really understand why PEEK
PCLSRing the -server- would cause any kind of deadlock to be broken.
Not that surprising. Remember that DQ: is a very strange file. In
particular, see the code that uses register Y in OUTPUT and BOJINT to
avoid hanging forever at the SIOT in OUTPUT. I would not be surprised
if that code was intimately involved in this bug, I doubt anybody has
ever tried to make a JOB device do anything this twisted before.

Date: Sun, 18 Jan 87 22:51:43 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: PEEK shouldn't ever PCLSR anyone
To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU
cc: JTW@AI.AI.MIT.EDU
Message-ID: <141778.870118.ALAN@AI.AI.MIT.EDU>
I just found two obvious places in PEEK that would cause a job to get
PCLSR'd.
The first would PCLSR any job that PEEK suspected might be a MUDDLE job (it
had some test involving the contents of the job's accumulators). Despite
the comment that threatened to "BREAK THE NECK OF THE ASSHOLE WHO REMOVES
ANY CODE HERE WITHOUT CONSULTING ME AND OBTAINING PERMISSION", I removed
it.
The second would PCLSR any job that PEEK suspected might be an interesting
job device server. Any job whose JNAME started with the three characters
"JOB" would be PCLSR'd when PEEK went into "C" mode because PEEK used
.IOT's on the USR: device to probe around in its memory (to see if it was
an MLDEV, or other device server it knows about). I fixed this to use
memory mapping instead.
In the case of the DQ device screw, I don't really understand why PEEK
PCLSRing the -server- would cause any kind of deadlock to be broken. But
in any case, now there is a good chance that the next time COMSAT and DQ
get into this state, the mere act of discovering the lossage in PEEK (by
going into "C" mode to read the STATS file) will not cause the lossage to
vanish. Perhaps we will be able to find the problem now.

Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 MAY 86 12:43:22 EDT
Date: Tue, 13 May 86 12:44:25 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: ZVONA@MC.LCS.MIT.EDU
cc: BUG-PEEK@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 12 May 86 20:15:40 EDT from David Chapman <ZVONA at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].38227.860513.ALAN>
Date: Mon, 12 May 86 20:15:40 EDT
From: David Chapman <ZVONA at MC.LCS.MIT.EDU>
BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;?
Some other directory on AI? Some altogether different place?
Probably it should go into AI:SYSDOC;.

Date: Mon, 12 May 86 20:15:40 EDT
From: David Chapman <ZVONA@MC.LCS.MIT.EDU>
To: BUG-PEEK@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
cc: ZVONA@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].911011.860512.ZVONA>
BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;?
Some other directory on AI? Some altogether different place?

Date: Tue, 4 Mar 86 18:15:40 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: "W" mode sorting
To: BUG-PEEK@MC.LCS.MIT.EDU
cc: MOON@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].838752.860304.ALAN>
The Internet Routing table ("W" mode) sorting-by-age feature doesn't seem
to be functioning properly on AI right now. Perhaps this is because
currently AI has entries that are more than 5 days old?

Date: Mon, 3 Mar 86 02:12:36 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: " mode in PEEK
To: BUG-ITS@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN>
I added a new mode to PEEK for printing the contents of the system message
buffer. (Type a doublequote to get it.) This is especially useful for
looking at crash dumps. While I was at it I added a few features to crash
dump mode itself. For a good example try (on AI):
:PEEK <CRASH;IMP NXM
and after looking at the crash dump display, type " to see some more
interesting error messages.

Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 12:36:54 EST
Date: Sun, 5 Jan 1986 12:32 EST
Message-ID: <SRA.12172848298.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
Cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-HOSTS3@MC.LCS.MIT.EDU,
BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
GUMBY@MC.LCS.MIT.EDU, namecallers@MC.LCS.MIT.EDU
Subject: Ick!
In-reply-to: Msg of 2 Jan 1986 14:33-EST from Chris Lindblad <CJL@OZ.AI.MIT.EDU>
(Oh bleep, let's put this on namecallers and get it over with already).
From: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
Alan points out that when generating the hosts3 table, you only have to
be compatible with people who have been using the hosts3 table.
Not quite. Eg, JIS has MIT-OA.MIT.EDU as the IN-ADDR translation for
18.10.0.79, so if anybody out there is still using the old cannonical
name algorithm (name->address->name) they will think that is OA's
primary name, thus will include it in mail headers, thus people using
HOSTS3.BIN should be able to recognize it to avoid barfing on replies.
This is probably not as much of a problem for AI as for LCS because of
the relative numbers of TCP/IP machines.
There are bugs in your algorithm anyway. You are taking the name MITAI
and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa
domain only contained the primary names of hosts).
Mea culpa.
I really think it is silly to be genrating all these names. Just because
JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason
for us to clutter our host tables with them. I suggest that as soon as
possible, we eliminate references to the mit.edu domain. The longer
they're there, the harder it will be to take them out, and there's no
better time to make changes like this than during IAP.
Agreed. I never intended that all that cruft be there permenantly,
just for transition to try to keep the world from falling apart too
badly too fast. IAP does seem like a good time to punt it.
Over the next year, more than 100 hosts will be added to the host table.
We better start making each entry more compact if we expect it to keep
working. Alan says that we have only two pages left.
Right, but the key point is that HOSTS3 isn't going to work much
longer. One of two things will happen: (1) the NIC table will no
longer be anything like exhaustive, in which case the table is
incomplete, or (2) the NIC table will grow to the point where it is
completely unusable. My guess is that we will end up with a
HOSTS3.BIN that contains info for MIT, and Chaos-only machines will
either have to grok domains or just start blindly sending mail to some
forwarder if the address is unrecognized. Eventually HOSTS3 may
become identical with HOST3C if/when chaos machines grok domains, but
that's not for a while yet.
For the AI host table. I would be happy if you didn't generate any
names, and I specify all the names I want.
Ok. Nag me if you don't hear about this in the next few days.

Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JAN 86 14:41:23 EST
Date: Thu, 2 Jan 1986 14:33 EST
Message-ID: <CJL.12172083807.BABYL@MIT-OZ>
From: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
To: Rob Austein <SRA@XX.LCS.MIT.EDU>
Cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-HOSTS3@MC.LCS.MIT.EDU,
BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
GUMBY@MC.LCS.MIT.EDU
Subject: Ick!
In-reply-to: Msg of 2 Jan 1986 13:52-EST from Rob Austein <SRA at MIT-XX>
Date: Thursday, 2 January 1986 13:52-EST
From: Rob Austein <SRA at MIT-XX>
The problem is that all of those names are in somebody or another's
domain space at the present time. JIS has been advertising things
like MIT-AI.MIT.EDU, etc. The way things are set up currently you can
punt this cruft, but only a on a per-domain basis (ie, for all of
AI.MIT.EDU). If you (primarily CJL) want to do this, fine, tell me,
I'll do it. But you should think about it first, since people really
have been using some of those stupid names.
Some thoughts on this.
Alan points out that when generating the hosts3 table, you only have to
be compatible with people who have been using the hosts3 table.
There are bugs in your algorithm anyway. You are taking the name MITAI
and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa
domain only contained the primary names of hosts).
I really think it is silly to be genrating all these names. Just because
JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason
for us to clutter our host tables with them. I suggest that as soon as
possible, we eliminate references to the mit.edu domain. The longer
they're there, the harder it will be to take them out, and there's no
better time to make changes like this than during IAP.
Over the next year, more than 100 hosts will be added to the host table.
We better start making each entry more compact if we expect it to keep
working. Alan says that we have only two pages left.
For the AI host table. I would be happy if you didn't generate any
names, and I specify all the names I want.

Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 2 Jan 86 13:50:05 EST
Date: Thu, 2 Jan 1986 13:52 EST
Message-ID: <SRA.12172076316.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Cc: BUG-HOSTS3@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU,
BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU,
SRA@XX.LCS.MIT.EDU, cjl@OZ.AI.MIT.EDU
Subject: Ick!
In-reply-to: Msg of 1 Jan 1986 02:41-EST from Alan Bawden <ALAN@MC.LCS.MIT.EDU>
The problem is that all of those names are in somebody or another's
domain space at the present time. JIS has been advertising things
like MIT-AI.MIT.EDU, etc. The way things are set up currently you can
punt this cruft, but only a on a per-domain basis (ie, for all of
AI.MIT.EDU). If you (primarily CJL) want to do this, fine, tell me,
I'll do it. But you should think about it first, since people really
have been using some of those stupid names.

Date: Wed, 1 Jan 86 02:41:38 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: Ick!
To: BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
BUG-HOSTS3@MC.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU
cc: GUMBY@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].770028.860101.ALAN>
Ugh, bletch! Yuck! I just had to go and shuffle the memory layout in
(*gag*) PEEK because the HOSTS3 table has grown to be so huge that PEEK has
trouble keeping both it and ITS mapped in at the same time. (Gumby, this
is what caused that PEEK bug you discovered the other day.) If HOSTS3 gets
to be another -two- ITS blocks long, it is going to take some serious
thinking to keep PEEK working. Presumably there are other programs out
there that, like PEEK, simply were not designed with a 73 block host table
in mind.
I notice that the current host table contains shitloads of totally
ridiculous host names. A particularly bad example is AI which has the
names:
AI.AI.MIT.EDU
AI
AI.MIT.EDU
MIT-AI
MIT-AI.ARPA
MIT-AI.MIT.EDU
MIT-MITAI
MIT-MITAI.ARPA
MIT-MITAI.MIT.EDU
MITAI
MITAI.AI.MIT.EDU
MITAI.MIT.EDU
Might I suggest eliminating any name that starts with "MIT-" and ends
".MIT.EDU"? (Also in the case of AI, I think we can do without the nicname
"MITAI" (without hyphen) and its derivatives.)

Date: Tue, 24 Dec 85 00:58:14 EST
From: "Pandora B. Berman" <CENT@MC.LCS.MIT.EDU>
Subject: total=out= inf.
To: BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].765406.851224.CENT>
there's a problem between the Normal mode of P and any other, at least, any
other i usually use. when i start a PEEK, the Total= and Out= figures at the
screen top are small and fit in their alloted spaces. however, if i switch
to some other display (look at some particular job or channel, or the help
display) and then back to N, these two numbers balloon to 10 or 12 or so
figures long, and the Status column info goes all to hell.

Date: Thu, 19 Dec 85 21:31:35 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject: weird display
To: BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].761687.851219.GUMBY>
Well MBECK was right; I finally was able to duplicate his bug. It's
tricky; only seems ta appear if started w/jcl. The symptom is the
runnable total and out columns have about 18 digits each, which
suggest the uuo which prints them out is somehow bashed. Trumm
appears to have a reasonable value in it.
I dunno.

Date: Thu, 19 Dec 85 18:04:06 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject: Strange-looking numbers
To: MBECK@MC.LCS.MIT.EDU
cc: BUG-PEEK@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 18 Dec 85 21:43:27 EST from Mark E. Becker <MBECK at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].761316.851219.GUMBY>
Date: Wed, 18 Dec 85 21:43:27 EST
From: Mark E. Becker <MBECK at MC.LCS.MIT.EDU>
Was using Peek 593 when noticed some rather strange-looking numbers
for "Runnable Total" and "Out".
What do you mean by "strange-looking numbers?" I can't duplicate this.

Date: Wed, 18 Dec 85 21:43:27 EST
From: "Mark E. Becker" <MBECK@MC.LCS.MIT.EDU>
To: BUG-PEEK@MC.LCS.MIT.EDU
cc: MBECK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].760171.851218.MBECK>
Was using Peek 593 when noticed some rather strange-looking numbers
for "Runnable Total" and "Out". This was after the first display had
been output... The JCL was :P 57J 8Z .
Regards,
Mark

Date: Fri, 13 Dec 85 16:02:11 EST
From: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>
Subject: [macrakis: Supdup lossage]
To: BUG-PEEK@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].753036.851213.CSTACY>
Date: Thu, 5 Dec 85 00:08:11 EST
From: macrakis at harvard.HARVARD.EDU (Stavros Macrakis)
To: bug-supdup at mit-mc.arpa, ddl at harvard.HARVARD.EDU
Re: Supdup lossage
In supdup'ing from Harvard (Unix 4.3) to Mit-MC, everything seems to work
perfectly until I try to run Peek. In particular, if I type ahead the
Peek command (e.g. `P^KJ'), it hangs up. The only way I seem to be able
to get out of this state is to quit (^^q) the supdup and reconnect.
Actually, now that I do the test, it appears that even without typeahead,
Peek's interrupt characters (commands) never get through. -- p^K ... wait
for end of display (space worrks fine at end of screen) ... q [hangs up].
The input characters do seem to be buffered up somewhere, because when
you type ^Z when it's hung up and before you quit, when you reconnect,
the peek has been ^Z'd.

Date: Mon, 2 Dec 85 17:58:51 EST
From: "J. Noel Chiappa" <JNC@MIT-MC.ARPA>
Subject: A display
To: BUG-PEEK@MIT-MC.ARPA
cc: JNC@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].738887.851202.JNC>
Any change of moving the STY list to a separate display?
These days that list is pretty long, and over a slow network
link it's annoying to have to plought through the whole thing
to see the TCP connection list.

Date: Tue, 6 Aug 85 06:26:44 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: PEEK "bug" fixed
To: CSTACY@MIT-MC.ARPA
cc: BUG-PEEK@MIT-MC.ARPA, BUG-CRTSTY@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].602153.850806.KLH>
Date: Thu, 9 May 85 00:12:55 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien <KLH>
I still can't reproduce anything close to the the behaviour you
described.
Date: Wed, 8 May 85 06:33:43 EST
From: Ken Harrenstien <KLH>
To: CSTACY
cc: KLH, BUG-PEEK
Here is how to tickle the PEEK bug. Connect to MC from somewhere
else on the Arpanet. Say ":P A". PEEK will clear the screen, and
then do nothing.
OK, I found the problem. It turns out to be in CRTSTY when acting as
a SUPDUP user program (CTN). By using IPLIST (like using a howitzer on a
housefly) I found that PEEK was sending %TDORS, and ITS was waiting
for the remote site to respond with the appropriate Intelligent Terminal
Protocol sequence (^\ ^P <V> <H>, which reports the cursor position)
before allowing PEEK to do anything else! Since CTN was not responding
with that sequence until the user typed some input (due to a spazz
by whoever wrote the %TDORS handling code), the effect was that whenever
any ITS program did a .RESET TYOC, all output would stop until the user
became impatient... as it happens, PEEK does such a reset every time
any character is typed at it.
I have merged the fix into the SYSENG source of CRTSTY.

Date: Fri, 10 May 85 17:58:29 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
To: KLH@MIT-MC
cc: BUG-PEEK@MIT-MC
In-reply-to: Msg of Thu 9 May 85 20:49:01 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].495962.850510.CSTACY>
Date: Thu, 9 May 85 20:49:01 EST
From: Ken Harrenstien <KLH>
To: BUG-PEEK
This time I said :P A and nothing whatsoever hapened.
I ctl-Z'd and found I was at loc 22001, executing an .IOT 14,15
with the value "A in 15. I thought the problem might be TCP related
but this seems more unlikely. CSTACY, maybe you should try
logging in as something else?
Something is obviously screwing you, but I still can't duplicate it.
The previous tests were conducted under a variety of UNAMEs.
Here are the gory details of my latest attempt.
I logged into MC over 1200 baud dialup, and did :TN NIC and logged in
over there. I ran @TELNET MC and NIC connected me to MC where I
received a DDT and did not log in (having made arrangements with PWORD
for this earlier). I typed ":P A". I got the same results as
yesterday -- PEEK worked.
I flushed all my connections back to MC and typed ":TN NIC". I logged
into NIC and did "@TELNET MC". NIC connected me to MC and I logged in
as a normal user without any init file. I typed ":P A", and PEEK
worked. I typed "J" and it worked; I used "X" to gun myself down.
Maybe somehow the problem is terminal-type specific.
Does it happen to you if you don't run TCTYP?

Date: Thu, 9 May 85 20:49:01 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: BUG-PEEK@MIT-MC
Message-ID: <[MIT-MC].494254.850509.KLH>
This time I said :P A and nothing whatsoever hapened.
I ctl-Z'd and found I was at loc 22001, executing an .IOT 14,15
with the value "A in 15. I thought the problem might be TCP related
but this seems more unlikely. CSTACY, maybe you should try
logging in as something else?

Date: Thu, 9 May 85 00:12:55 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
Subject: can't reproduce bug
To: KLH@MIT-MC
cc: BUG-PEEK@MIT-MC
In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].492640.850509.CSTACY>
I still can't reproduce anything close to the the behaviour you
described.
Date: Wed, 8 May 85 06:33:43 EST
From: Ken Harrenstien <KLH>
To: CSTACY
cc: KLH, BUG-PEEK
Here is how to tickle the PEEK bug. Connect to MC from somewhere
else on the Arpanet. Say ":P A". PEEK will clear the screen, and
then do nothing.
I did some tests from various net hosts (using TELNET to get to the
remote site, and their TELNET to get to MC.) I invoked PEEK with
":PEEK", and ":P A", and excersized the A,J,N,Z, and X commands.
I tried several of these tests 2 or 3 times.
1. PEEK works normally over LispM or MINITS Chaosnet SUPDUP.
2. Over a MINITS Chaosnet TELNET connection, PEEK works normally,
except that it does not update the display automatically.
PEEK starts up, displays whatever it is supposed to *twice*,
and then just sits there, and you have to type another command,
or use SPACE or Z. I think it is supposed to be a feature that
there is a long (infinite?) initial sleep time when the
console is a printing terminal. All the commands seem to work.
It is a bug that on a printing terminal it does the initial
display twice.
3. I tested PEEK TNing to MC from SCORE, being a Datamedia
terminal. PEEK worked normally.
4. From BRL-BMD as a printing terminal, the sucky TCP connection
was almost unbearably slow, but PEEK seemed to behave the same
as on a MINITS Chaos TELNET connection.
5. From SRI-NIC as a printing terminal, PEEK seemed to behave the
same as on a MINITS Chaos TELNET connection. BTW, the thing
which it echoes at ":P A" is an "A" (folowed by the correct
display.)
6. As a final test, I came in from SRI-NIC and :TCTYP DM2500.
I typed ":P A". It echoed "A", paused for 1 second, and
gave me one normal ARPAnet display. After 20 seconds it
updated it. I typed "J", and it did. I used the "X"
command to gun myself down.
Beats me to death.

Date: Wed, 8 May 85 06:33:43 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: CSTACY@MIT-MC
cc: KLH@MIT-MC, BUG-PEEK@MIT-MC
Message-ID: <[MIT-MC].491306.850508.KLH>
Here is how to tickle the PEEK bug. Connect to MC from somewhere
else on the Arpanet. Say ":P A". PEEK will clear the screen, and
then do nothing. That's right, nothing. Eventually you will get
impatient, and type a space. Bang! Suddenly there is a flash
of something echoed too quickly to see (^A?), and the PEEK "A" display
appears. As far as X and Y go, nothing will happen. I don't know if
all this is something net-specific, but if it is it should be flushed.
Possibly the JCL handling is messed up?
It seems to be solidly repeatable.

Date: Tue, 7 May 85 19:19:52 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
To: KLH@MIT-MC
cc: BUG-PEEK@MIT-MC
In-reply-to: Msg of Tue 7 May 85 17:33:21 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].490642.850507.CSTACY>
When I run PEEK, it automatically displays things for me. The X and Y
commands work fine for me. Glancing at a source compare of the latest
PEEK with the version from 1983, the only changes I see are where
people have installed some meter modes for some network stuff.
However, there is a very old bug which bites me sometimes, where PEEK
apparently does not turn its interrupts on or something. When it gets
to a **MORE** break, it hangs (and the prompt is wrong so the more
handler has clearly not gone off.) I think that in this mode, no
characters typed do anything. Somebody should track this down
someday, but it is sporadic and has been happenning for years.
Are you thinking of this latter bug, or are you claiming that PEEK is
completely broken? It normally works fine for me many times each day.

Date: Tue, 7 May 85 17:33:21 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: BUG-PEEK@MIT-MC
Message-ID: <[MIT-MC].490459.850507.KLH>
For a few months now I've noticed that PEEK has been broken. I
wasn't quite sure whether to believe it at first, but now I'm
relatively sure. The problem is that PEEK does not go ahead and
show things on its own -- you hae to type a space or something to force
output, it seems. For certain commands like X and Y it simply does
not work or do anything. Now, I grant this may hae happened because of
someone's idea of "new improved featurefulness" but I find it annoying.

Date: 26 January 1985 02:39-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-FINGER @ MIT-MC, BUG-PEEK @ MIT-MC
cc: ALAN @ MIT-MC
Does not mention when system is being debugged unless users are not allowed on.

Date: 13 January 1985 01:37-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: HDT @ MIT-MC
cc: BUG-PEEK @ MIT-MC
First, you could just re-own the wholine job with :JOB WHOLIN
and then :KILL it, rather than using PEEK. I don't know why
PEEK behaves the way you describe, but someone can look at it
someday I guess.

Date: 13 January 1985 01:30-EST
From: Howard D. Trachtman <HDT @ MIT-MC>
To: BUG-PEEK @ MIT-MC
cc: HDT @ MIT-MC
I had a detached tree which I was trying to kill in peek.
I couldn't kill it. Basically I just wanted to get rid of
my wholin which was disowned and screwing me. number, etg. 32Y
offered to kill my entire tree (two hactr*'s) and I thought this
was a bug. I got rid of some useless jobs so that if it actually
went and killed the tree off I could live also. But they still wouldn't
got away. 5 minutes later, the system console printed that
it killed my hour old detached job. If this is at all interesting,
I can provide some more info, but I don't want to bore you all otherwise.

Date: 22 December 1984 04:32-EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: PEEK down warning broken
To: BUG-PEEK @ MIT-MC
cc: BUG-FOO @ MIT-MC
P pretends it is warning you that the system is being taken down. however,
the warning code is fukt. the warning (in the J display, at least) looks like
System going down in <timeA> (<timeB>)
where <timeA> is supposedly the remaining increment until the actual <timeB>
occurs. you'd expect that <timeB> would remain constant and <timeA> would
decrement to 0. what really happens, though, is <timeA> remains constant
(and doesn't jibe with the down warnings produced at top level), and <timeB>
increments to fit <timeA>!! please fix.

Date: 25 August 1984 16:16-EDT
From: David A. Moon <MOON @ MIT-MC>
To: BUG-PEEK @ MIT-MC
Needs to be fixed to work when the amount of free memory in the header
runs into four digits (!!)

Date: 18 March 1984 21:40-EST
From: Jon Solomon <JSOL @ MIT-MC>
To: BUG-PEEK @ MIT-MC
Sigh, every time I peek at the comsat stats file it gives me
an :$MPV not handled$ error and punts. This time after perhaps
two screenfuls. I'm on a vt100 running in vt52 mode, and I have
had this happen on vt100s running vt100 mode, and H19s.
--jsol

Date: 15 November 1983 19:04 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: E
To: BUG-PEEK @ MIT-MC
Is there documentation anywhere for the "E" command?

Date: 28 October 1983 06:56 EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
To: BUG-PEEK @ MIT-MC
How come the down time message is so fukt?

Date: 21 October 1983 16:47 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: BUG-PEEK @ MIT-MC
Someone should fix the "System going down in" message in PEEK.
The times it gives are preposterous.

Date: 19 July 1983 03:10 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: BUG-PEEK @ MIT-MC
When I use LOCK to take the system down, it used to say
'System going down in 15:00' or whatever.
Now it says:
'System going down in 3:06:21:21 ( 3:09:28:44)'
These huge mysterious numbers are not very helpful.

Date: 9 July 1983 06:46 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: [ELLEN: forwarded]
To: BUG-PEEK @ MIT-MC
Date: 07/08/83 03:46:40
From: ELLEN
To: CSTACY
cc: ELLEN
wierd Peek...
Peek seems not only to not allow you to type a space to redisplay
during an "O", but it also sometimes gets into a state where a space
will not do anything, no how... I can identify this state because
the "More" at the bottom will be
**More**
instead of
--More--
I regret that at this instant I cannot tell you how to produce this
state. But I suspect it might be related to hopping in and out of
PEEK repeatedly... as I sometimes do... then one time I suddenly
notice this wierdness...
I consider this highly wierd, and am sending this to you, to forward
as you please, since I believe it was you who last modified PEEK.
Cheers.

gsb@MIT-ML (Sent by TAR@MIT-ML) 05/08/83 00:56:23
To: (BUG PEEK) at MIT-ML
If i type ahead stuff at peek (like i do
peek
jjjjjjjjjjjjjjjjjj
)
then i can make it use **MORE** rather than --More--.
This is especially amusing because in **MORE** in peek, the two things
which do not work are space and rubout.