1 Copyright (c) 1999 Massachusetts Institute of Technology
3 This program is free software; you can redistribute it and/or modify
4 it under the terms of the GNU General Public License as published by
5 the Free Software Foundation; either version 2 of the License, or (at
6 your option) any later version.
8 This program is distributed in the hope that it will be useful, but
9 WITHOUT ANY WARRANTY; without even the implied warranty of
10 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
11 General Public License for more details.
13 You should have received a copy of the GNU General Public License
14 along with this program; if not, write to the Free Software
15 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
16 ------------------------------
18 Date: Fri, 5 May 89 14:14:14 EDT
19 From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
20 To: BUG-PEEK@AI.AI.MIT.EDU
21 Message-ID: <591317.890505.DEVON@AI.AI.MIT.EDU>
23 watching the comsat stats file with 1C, it said
24 MPV; DSKTY3+1>>ILDB B,A B/ 0,,65 a/ 350700,,32000
33 Date: Sun, 20 Mar 88 13:48:17 EST
34 From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
35 To: BUG-PEEK@AI.AI.MIT.EDU
36 Message-ID: <344793.880320.DEVON@AI.AI.MIT.EDU>
38 I was sitting in 0C watching COMSAT and I got
39 MPV; 11772>>ILDB 2,1 2/ 151 1/ AOS 16,32000
40 with no apparent provocation. A day or so ago I got MPV right on
41 the heels of a **MORE** (not --more-- which was strange) but I
42 didn't notice where. 31777 seems to be the last word of the buffer
45 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Jan 87 00:29:12 EST
46 Date: Wed, 21 Jan 1987 00:25 EST
47 Message-ID: <SRA.12272592709.BABYL@XX.LCS.MIT.EDU>
48 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
49 To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
50 Cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
51 Subject: PEEK shouldn't ever PCLSR anyone
52 In-reply-to: Msg of 18 Jan 1987 22:51-EST from Alan Bawden <ALAN@AI.AI.MIT.EDU>
54 Date: Sunday, 18 January 1987 22:51-EST
55 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
57 In the case of the DQ device screw, I don't really understand why PEEK
58 PCLSRing the -server- would cause any kind of deadlock to be broken.
60 Not that surprising. Remember that DQ: is a very strange file. In
61 particular, see the code that uses register Y in OUTPUT and BOJINT to
62 avoid hanging forever at the SIOT in OUTPUT. I would not be surprised
63 if that code was intimately involved in this bug, I doubt anybody has
64 ever tried to make a JOB device do anything this twisted before.
66 Date: Sun, 18 Jan 87 22:51:43 EST
67 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
68 Subject: PEEK shouldn't ever PCLSR anyone
69 To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU
71 Message-ID: <141778.870118.ALAN@AI.AI.MIT.EDU>
73 I just found two obvious places in PEEK that would cause a job to get
76 The first would PCLSR any job that PEEK suspected might be a MUDDLE job (it
77 had some test involving the contents of the job's accumulators). Despite
78 the comment that threatened to "BREAK THE NECK OF THE ASSHOLE WHO REMOVES
79 ANY CODE HERE WITHOUT CONSULTING ME AND OBTAINING PERMISSION", I removed
82 The second would PCLSR any job that PEEK suspected might be an interesting
83 job device server. Any job whose JNAME started with the three characters
84 "JOB" would be PCLSR'd when PEEK went into "C" mode because PEEK used
85 .IOT's on the USR: device to probe around in its memory (to see if it was
86 an MLDEV, or other device server it knows about). I fixed this to use
87 memory mapping instead.
89 In the case of the DQ device screw, I don't really understand why PEEK
90 PCLSRing the -server- would cause any kind of deadlock to be broken. But
91 in any case, now there is a good chance that the next time COMSAT and DQ
92 get into this state, the mere act of discovering the lossage in PEEK (by
93 going into "C" mode to read the STATS file) will not cause the lossage to
94 vanish. Perhaps we will be able to find the problem now.
96 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 MAY 86 12:43:22 EDT
97 Date: Tue, 13 May 86 12:44:25 EDT
98 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
99 To: ZVONA@MC.LCS.MIT.EDU
100 cc: BUG-PEEK@MC.LCS.MIT.EDU
101 In-reply-to: Msg of Mon 12 May 86 20:15:40 EDT from David Chapman <ZVONA at MC.LCS.MIT.EDU>
102 Message-ID: <[AI.AI.MIT.EDU].38227.860513.ALAN>
104 Date: Mon, 12 May 86 20:15:40 EDT
105 From: David Chapman <ZVONA at MC.LCS.MIT.EDU>
106 BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;?
107 Some other directory on AI? Some altogether different place?
109 Probably it should go into AI:SYSDOC;.
111 Date: Mon, 12 May 86 20:15:40 EDT
112 From: David Chapman <ZVONA@MC.LCS.MIT.EDU>
113 To: BUG-PEEK@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
114 cc: ZVONA@MC.LCS.MIT.EDU
115 Message-ID: <[MC.LCS.MIT.EDU].911011.860512.ZVONA>
117 BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;?
118 Some other directory on AI? Some altogether different place?
120 Date: Tue, 4 Mar 86 18:15:40 EST
121 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
122 Subject: "W" mode sorting
123 To: BUG-PEEK@MC.LCS.MIT.EDU
124 cc: MOON@MC.LCS.MIT.EDU
125 Message-ID: <[MC.LCS.MIT.EDU].838752.860304.ALAN>
127 The Internet Routing table ("W" mode) sorting-by-age feature doesn't seem
128 to be functioning properly on AI right now. Perhaps this is because
129 currently AI has entries that are more than 5 days old?
131 Date: Mon, 3 Mar 86 02:12:36 EST
132 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
133 Subject: " mode in PEEK
134 To: BUG-ITS@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU
135 Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN>
137 I added a new mode to PEEK for printing the contents of the system message
138 buffer. (Type a doublequote to get it.) This is especially useful for
139 looking at crash dumps. While I was at it I added a few features to crash
140 dump mode itself. For a good example try (on AI):
142 and after looking at the crash dump display, type " to see some more
143 interesting error messages.
145 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 12:36:54 EST
146 Date: Sun, 5 Jan 1986 12:32 EST
147 Message-ID: <SRA.12172848298.BABYL@XX.LCS.MIT.EDU>
148 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
149 To: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
150 Cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-HOSTS3@MC.LCS.MIT.EDU,
151 BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
152 GUMBY@MC.LCS.MIT.EDU, namecallers@MC.LCS.MIT.EDU
154 In-reply-to: Msg of 2 Jan 1986 14:33-EST from Chris Lindblad <CJL@OZ.AI.MIT.EDU>
156 (Oh bleep, let's put this on namecallers and get it over with already).
158 From: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
160 Alan points out that when generating the hosts3 table, you only have to
161 be compatible with people who have been using the hosts3 table.
163 Not quite. Eg, JIS has MIT-OA.MIT.EDU as the IN-ADDR translation for
164 18.10.0.79, so if anybody out there is still using the old cannonical
165 name algorithm (name->address->name) they will think that is OA's
166 primary name, thus will include it in mail headers, thus people using
167 HOSTS3.BIN should be able to recognize it to avoid barfing on replies.
168 This is probably not as much of a problem for AI as for LCS because of
169 the relative numbers of TCP/IP machines.
171 There are bugs in your algorithm anyway. You are taking the name MITAI
172 and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa
173 domain only contained the primary names of hosts).
177 I really think it is silly to be genrating all these names. Just because
178 JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason
179 for us to clutter our host tables with them. I suggest that as soon as
180 possible, we eliminate references to the mit.edu domain. The longer
181 they're there, the harder it will be to take them out, and there's no
182 better time to make changes like this than during IAP.
184 Agreed. I never intended that all that cruft be there permenantly,
185 just for transition to try to keep the world from falling apart too
186 badly too fast. IAP does seem like a good time to punt it.
188 Over the next year, more than 100 hosts will be added to the host table.
189 We better start making each entry more compact if we expect it to keep
190 working. Alan says that we have only two pages left.
192 Right, but the key point is that HOSTS3 isn't going to work much
193 longer. One of two things will happen: (1) the NIC table will no
194 longer be anything like exhaustive, in which case the table is
195 incomplete, or (2) the NIC table will grow to the point where it is
196 completely unusable. My guess is that we will end up with a
197 HOSTS3.BIN that contains info for MIT, and Chaos-only machines will
198 either have to grok domains or just start blindly sending mail to some
199 forwarder if the address is unrecognized. Eventually HOSTS3 may
200 become identical with HOST3C if/when chaos machines grok domains, but
201 that's not for a while yet.
203 For the AI host table. I would be happy if you didn't generate any
204 names, and I specify all the names I want.
206 Ok. Nag me if you don't hear about this in the next few days.
208 Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JAN 86 14:41:23 EST
209 Date: Thu, 2 Jan 1986 14:33 EST
210 Message-ID: <CJL.12172083807.BABYL@MIT-OZ>
211 From: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
212 To: Rob Austein <SRA@XX.LCS.MIT.EDU>
213 Cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-HOSTS3@MC.LCS.MIT.EDU,
214 BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
217 In-reply-to: Msg of 2 Jan 1986 13:52-EST from Rob Austein <SRA at MIT-XX>
219 Date: Thursday, 2 January 1986 13:52-EST
220 From: Rob Austein <SRA at MIT-XX>
222 The problem is that all of those names are in somebody or another's
223 domain space at the present time. JIS has been advertising things
224 like MIT-AI.MIT.EDU, etc. The way things are set up currently you can
225 punt this cruft, but only a on a per-domain basis (ie, for all of
226 AI.MIT.EDU). If you (primarily CJL) want to do this, fine, tell me,
227 I'll do it. But you should think about it first, since people really
228 have been using some of those stupid names.
230 Some thoughts on this.
232 Alan points out that when generating the hosts3 table, you only have to
233 be compatible with people who have been using the hosts3 table.
235 There are bugs in your algorithm anyway. You are taking the name MITAI
236 and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa
237 domain only contained the primary names of hosts).
239 I really think it is silly to be genrating all these names. Just because
240 JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason
241 for us to clutter our host tables with them. I suggest that as soon as
242 possible, we eliminate references to the mit.edu domain. The longer
243 they're there, the harder it will be to take them out, and there's no
244 better time to make changes like this than during IAP.
246 Over the next year, more than 100 hosts will be added to the host table.
247 We better start making each entry more compact if we expect it to keep
248 working. Alan says that we have only two pages left.
250 For the AI host table. I would be happy if you didn't generate any
251 names, and I specify all the names I want.
253 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 2 Jan 86 13:50:05 EST
254 Date: Thu, 2 Jan 1986 13:52 EST
255 Message-ID: <SRA.12172076316.BABYL@XX.LCS.MIT.EDU>
256 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
257 To: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
258 Cc: BUG-HOSTS3@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU,
259 BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU,
260 SRA@XX.LCS.MIT.EDU, cjl@OZ.AI.MIT.EDU
262 In-reply-to: Msg of 1 Jan 1986 02:41-EST from Alan Bawden <ALAN@MC.LCS.MIT.EDU>
264 The problem is that all of those names are in somebody or another's
265 domain space at the present time. JIS has been advertising things
266 like MIT-AI.MIT.EDU, etc. The way things are set up currently you can
267 punt this cruft, but only a on a per-domain basis (ie, for all of
268 AI.MIT.EDU). If you (primarily CJL) want to do this, fine, tell me,
269 I'll do it. But you should think about it first, since people really
270 have been using some of those stupid names.
272 Date: Wed, 1 Jan 86 02:41:38 EST
273 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
275 To: BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
276 BUG-HOSTS3@MC.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU
277 cc: GUMBY@MC.LCS.MIT.EDU
278 Message-ID: <[MC.LCS.MIT.EDU].770028.860101.ALAN>
280 Ugh, bletch! Yuck! I just had to go and shuffle the memory layout in
281 (*gag*) PEEK because the HOSTS3 table has grown to be so huge that PEEK has
282 trouble keeping both it and ITS mapped in at the same time. (Gumby, this
283 is what caused that PEEK bug you discovered the other day.) If HOSTS3 gets
284 to be another -two- ITS blocks long, it is going to take some serious
285 thinking to keep PEEK working. Presumably there are other programs out
286 there that, like PEEK, simply were not designed with a 73 block host table
289 I notice that the current host table contains shitloads of totally
290 ridiculous host names. A particularly bad example is AI which has the
306 Might I suggest eliminating any name that starts with "MIT-" and ends
307 ".MIT.EDU"? (Also in the case of AI, I think we can do without the nicname
308 "MITAI" (without hyphen) and its derivatives.)
310 Date: Tue, 24 Dec 85 00:58:14 EST
311 From: "Pandora B. Berman" <CENT@MC.LCS.MIT.EDU>
312 Subject: total=out= inf.
313 To: BUG-PEEK@MC.LCS.MIT.EDU
314 Message-ID: <[MC.LCS.MIT.EDU].765406.851224.CENT>
316 there's a problem between the Normal mode of P and any other, at least, any
317 other i usually use. when i start a PEEK, the Total= and Out= figures at the
318 screen top are small and fit in their alloted spaces. however, if i switch
319 to some other display (look at some particular job or channel, or the help
320 display) and then back to N, these two numbers balloon to 10 or 12 or so
321 figures long, and the Status column info goes all to hell.
323 Date: Thu, 19 Dec 85 21:31:35 EST
324 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
325 Subject: weird display
326 To: BUG-PEEK@MC.LCS.MIT.EDU
327 Message-ID: <[MC.LCS.MIT.EDU].761687.851219.GUMBY>
329 Well MBECK was right; I finally was able to duplicate his bug. It's
330 tricky; only seems ta appear if started w/jcl. The symptom is the
331 runnable total and out columns have about 18 digits each, which
332 suggest the uuo which prints them out is somehow bashed. Trumm
333 appears to have a reasonable value in it.
337 Date: Thu, 19 Dec 85 18:04:06 EST
338 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
339 Subject: Strange-looking numbers
340 To: MBECK@MC.LCS.MIT.EDU
341 cc: BUG-PEEK@MC.LCS.MIT.EDU
342 In-reply-to: Msg of Wed 18 Dec 85 21:43:27 EST from Mark E. Becker <MBECK at MC.LCS.MIT.EDU>
343 Message-ID: <[MC.LCS.MIT.EDU].761316.851219.GUMBY>
345 Date: Wed, 18 Dec 85 21:43:27 EST
346 From: Mark E. Becker <MBECK at MC.LCS.MIT.EDU>
348 Was using Peek 593 when noticed some rather strange-looking numbers
349 for "Runnable Total" and "Out".
350 What do you mean by "strange-looking numbers?" I can't duplicate this.
352 Date: Wed, 18 Dec 85 21:43:27 EST
353 From: "Mark E. Becker" <MBECK@MC.LCS.MIT.EDU>
354 To: BUG-PEEK@MC.LCS.MIT.EDU
355 cc: MBECK@MC.LCS.MIT.EDU
356 Message-ID: <[MC.LCS.MIT.EDU].760171.851218.MBECK>
358 Was using Peek 593 when noticed some rather strange-looking numbers
359 for "Runnable Total" and "Out". This was after the first display had
360 been output... The JCL was :P 57J 8Z .
365 Date: Fri, 13 Dec 85 16:02:11 EST
366 From: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>
367 Subject: [macrakis: Supdup lossage]
368 To: BUG-PEEK@MIT-MC.ARPA
369 Message-ID: <[MIT-MC.ARPA].753036.851213.CSTACY>
371 Date: Thu, 5 Dec 85 00:08:11 EST
372 From: macrakis at harvard.HARVARD.EDU (Stavros Macrakis)
373 To: bug-supdup at mit-mc.arpa, ddl at harvard.HARVARD.EDU
376 In supdup'ing from Harvard (Unix 4.3) to Mit-MC, everything seems to work
377 perfectly until I try to run Peek. In particular, if I type ahead the
378 Peek command (e.g. `P^KJ'), it hangs up. The only way I seem to be able
379 to get out of this state is to quit (^^q) the supdup and reconnect.
380 Actually, now that I do the test, it appears that even without typeahead,
381 Peek's interrupt characters (commands) never get through. -- p^K ... wait
382 for end of display (space worrks fine at end of screen) ... q [hangs up].
383 The input characters do seem to be buffered up somewhere, because when
384 you type ^Z when it's hung up and before you quit, when you reconnect,
385 the peek has been ^Z'd.
387 Date: Mon, 2 Dec 85 17:58:51 EST
388 From: "J. Noel Chiappa" <JNC@MIT-MC.ARPA>
390 To: BUG-PEEK@MIT-MC.ARPA
392 Message-ID: <[MIT-MC.ARPA].738887.851202.JNC>
394 Any change of moving the STY list to a separate display?
395 These days that list is pretty long, and over a slow network
396 link it's annoying to have to plought through the whole thing
397 to see the TCP connection list.
399 Date: Tue, 6 Aug 85 06:26:44 EDT
400 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
401 Subject: PEEK "bug" fixed
402 To: CSTACY@MIT-MC.ARPA
403 cc: BUG-PEEK@MIT-MC.ARPA, BUG-CRTSTY@MIT-MC.ARPA
404 Message-ID: <[MIT-MC.ARPA].602153.850806.KLH>
406 Date: Thu, 9 May 85 00:12:55 EST
407 From: Christopher C. Stacy <CSTACY@MIT-MC>
408 In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien <KLH>
410 I still can't reproduce anything close to the the behaviour you
413 Date: Wed, 8 May 85 06:33:43 EST
414 From: Ken Harrenstien <KLH>
418 Here is how to tickle the PEEK bug. Connect to MC from somewhere
419 else on the Arpanet. Say ":P A". PEEK will clear the screen, and
422 OK, I found the problem. It turns out to be in CRTSTY when acting as
423 a SUPDUP user program (CTN). By using IPLIST (like using a howitzer on a
424 housefly) I found that PEEK was sending %TDORS, and ITS was waiting
425 for the remote site to respond with the appropriate Intelligent Terminal
426 Protocol sequence (^\ ^P <V> <H>, which reports the cursor position)
427 before allowing PEEK to do anything else! Since CTN was not responding
428 with that sequence until the user typed some input (due to a spazz
429 by whoever wrote the %TDORS handling code), the effect was that whenever
430 any ITS program did a .RESET TYOC, all output would stop until the user
431 became impatient... as it happens, PEEK does such a reset every time
432 any character is typed at it.
434 I have merged the fix into the SYSENG source of CRTSTY.
436 Date: Fri, 10 May 85 17:58:29 EST
437 From: Christopher C. Stacy <CSTACY@MIT-MC>
440 In-reply-to: Msg of Thu 9 May 85 20:49:01 EST from Ken Harrenstien <KLH>
441 Message-ID: <[MIT-MC].495962.850510.CSTACY>
443 Date: Thu, 9 May 85 20:49:01 EST
444 From: Ken Harrenstien <KLH>
447 This time I said :P A and nothing whatsoever hapened.
448 I ctl-Z'd and found I was at loc 22001, executing an .IOT 14,15
449 with the value "A in 15. I thought the problem might be TCP related
450 but this seems more unlikely. CSTACY, maybe you should try
451 logging in as something else?
453 Something is obviously screwing you, but I still can't duplicate it.
454 The previous tests were conducted under a variety of UNAMEs.
455 Here are the gory details of my latest attempt.
457 I logged into MC over 1200 baud dialup, and did :TN NIC and logged in
458 over there. I ran @TELNET MC and NIC connected me to MC where I
459 received a DDT and did not log in (having made arrangements with PWORD
460 for this earlier). I typed ":P A". I got the same results as
461 yesterday -- PEEK worked.
463 I flushed all my connections back to MC and typed ":TN NIC". I logged
464 into NIC and did "@TELNET MC". NIC connected me to MC and I logged in
465 as a normal user without any init file. I typed ":P A", and PEEK
466 worked. I typed "J" and it worked; I used "X" to gun myself down.
468 Maybe somehow the problem is terminal-type specific.
469 Does it happen to you if you don't run TCTYP?
471 Date: Thu, 9 May 85 20:49:01 EST
472 From: Ken Harrenstien <KLH@MIT-MC>
474 Message-ID: <[MIT-MC].494254.850509.KLH>
476 This time I said :P A and nothing whatsoever hapened.
477 I ctl-Z'd and found I was at loc 22001, executing an .IOT 14,15
478 with the value "A in 15. I thought the problem might be TCP related
479 but this seems more unlikely. CSTACY, maybe you should try
480 logging in as something else?
482 Date: Thu, 9 May 85 00:12:55 EST
483 From: Christopher C. Stacy <CSTACY@MIT-MC>
484 Subject: can't reproduce bug
487 In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien <KLH>
488 Message-ID: <[MIT-MC].492640.850509.CSTACY>
491 I still can't reproduce anything close to the the behaviour you
494 Date: Wed, 8 May 85 06:33:43 EST
495 From: Ken Harrenstien <KLH>
499 Here is how to tickle the PEEK bug. Connect to MC from somewhere
500 else on the Arpanet. Say ":P A". PEEK will clear the screen, and
503 I did some tests from various net hosts (using TELNET to get to the
504 remote site, and their TELNET to get to MC.) I invoked PEEK with
505 ":PEEK", and ":P A", and excersized the A,J,N,Z, and X commands.
506 I tried several of these tests 2 or 3 times.
508 1. PEEK works normally over LispM or MINITS Chaosnet SUPDUP.
510 2. Over a MINITS Chaosnet TELNET connection, PEEK works normally,
511 except that it does not update the display automatically.
512 PEEK starts up, displays whatever it is supposed to *twice*,
513 and then just sits there, and you have to type another command,
514 or use SPACE or Z. I think it is supposed to be a feature that
515 there is a long (infinite?) initial sleep time when the
516 console is a printing terminal. All the commands seem to work.
517 It is a bug that on a printing terminal it does the initial
520 3. I tested PEEK TNing to MC from SCORE, being a Datamedia
521 terminal. PEEK worked normally.
523 4. From BRL-BMD as a printing terminal, the sucky TCP connection
524 was almost unbearably slow, but PEEK seemed to behave the same
525 as on a MINITS Chaos TELNET connection.
527 5. From SRI-NIC as a printing terminal, PEEK seemed to behave the
528 same as on a MINITS Chaos TELNET connection. BTW, the thing
529 which it echoes at ":P A" is an "A" (folowed by the correct
532 6. As a final test, I came in from SRI-NIC and :TCTYP DM2500.
533 I typed ":P A". It echoed "A", paused for 1 second, and
534 gave me one normal ARPAnet display. After 20 seconds it
535 updated it. I typed "J", and it did. I used the "X"
536 command to gun myself down.
542 Date: Wed, 8 May 85 06:33:43 EST
543 From: Ken Harrenstien <KLH@MIT-MC>
545 cc: KLH@MIT-MC, BUG-PEEK@MIT-MC
546 Message-ID: <[MIT-MC].491306.850508.KLH>
548 Here is how to tickle the PEEK bug. Connect to MC from somewhere
549 else on the Arpanet. Say ":P A". PEEK will clear the screen, and
550 then do nothing. That's right, nothing. Eventually you will get
551 impatient, and type a space. Bang! Suddenly there is a flash
552 of something echoed too quickly to see (^A?), and the PEEK "A" display
553 appears. As far as X and Y go, nothing will happen. I don't know if
554 all this is something net-specific, but if it is it should be flushed.
555 Possibly the JCL handling is messed up?
557 It seems to be solidly repeatable.
559 Date: Tue, 7 May 85 19:19:52 EST
560 From: Christopher C. Stacy <CSTACY@MIT-MC>
563 In-reply-to: Msg of Tue 7 May 85 17:33:21 EST from Ken Harrenstien <KLH>
564 Message-ID: <[MIT-MC].490642.850507.CSTACY>
567 When I run PEEK, it automatically displays things for me. The X and Y
568 commands work fine for me. Glancing at a source compare of the latest
569 PEEK with the version from 1983, the only changes I see are where
570 people have installed some meter modes for some network stuff.
572 However, there is a very old bug which bites me sometimes, where PEEK
573 apparently does not turn its interrupts on or something. When it gets
574 to a **MORE** break, it hangs (and the prompt is wrong so the more
575 handler has clearly not gone off.) I think that in this mode, no
576 characters typed do anything. Somebody should track this down
577 someday, but it is sporadic and has been happenning for years.
579 Are you thinking of this latter bug, or are you claiming that PEEK is
580 completely broken? It normally works fine for me many times each day.
582 Date: Tue, 7 May 85 17:33:21 EST
583 From: Ken Harrenstien <KLH@MIT-MC>
585 Message-ID: <[MIT-MC].490459.850507.KLH>
587 For a few months now I've noticed that PEEK has been broken. I
588 wasn't quite sure whether to believe it at first, but now I'm
589 relatively sure. The problem is that PEEK does not go ahead and
590 show things on its own -- you hae to type a space or something to force
591 output, it seems. For certain commands like X and Y it simply does
592 not work or do anything. Now, I grant this may hae happened because of
593 someone's idea of "new improved featurefulness" but I find it annoying.
595 Date: 26 January 1985 02:39-EST
596 From: Christopher C. Stacy <CSTACY @ MIT-MC>
597 To: BUG-FINGER @ MIT-MC, BUG-PEEK @ MIT-MC
600 Does not mention when system is being debugged unless users are not allowed on.
602 Date: 13 January 1985 01:37-EST
603 From: Christopher C. Stacy <CSTACY @ MIT-MC>
605 cc: BUG-PEEK @ MIT-MC
607 First, you could just re-own the wholine job with :JOB WHOLIN
608 and then :KILL it, rather than using PEEK. I don't know why
609 PEEK behaves the way you describe, but someone can look at it
612 Date: 13 January 1985 01:30-EST
613 From: Howard D. Trachtman <HDT @ MIT-MC>
614 To: BUG-PEEK @ MIT-MC
617 I had a detached tree which I was trying to kill in peek.
618 I couldn't kill it. Basically I just wanted to get rid of
619 my wholin which was disowned and screwing me. number, etg. 32Y
620 offered to kill my entire tree (two hactr*'s) and I thought this
621 was a bug. I got rid of some useless jobs so that if it actually
622 went and killed the tree off I could live also. But they still wouldn't
623 got away. 5 minutes later, the system console printed that
624 it killed my hour old detached job. If this is at all interesting,
625 I can provide some more info, but I don't want to bore you all otherwise.
627 Date: 22 December 1984 04:32-EST
628 From: Pandora B. Berman <CENT @ MIT-MC>
629 Subject: PEEK down warning broken
630 To: BUG-PEEK @ MIT-MC
633 P pretends it is warning you that the system is being taken down. however,
634 the warning code is fukt. the warning (in the J display, at least) looks like
635 System going down in <timeA> (<timeB>)
636 where <timeA> is supposedly the remaining increment until the actual <timeB>
637 occurs. you'd expect that <timeB> would remain constant and <timeA> would
638 decrement to 0. what really happens, though, is <timeA> remains constant
639 (and doesn't jibe with the down warnings produced at top level), and <timeB>
640 increments to fit <timeA>!! please fix.
642 Date: 25 August 1984 16:16-EDT
643 From: David A. Moon <MOON @ MIT-MC>
644 To: BUG-PEEK @ MIT-MC
646 Needs to be fixed to work when the amount of free memory in the header
647 runs into four digits (!!)
649 Date: 18 March 1984 21:40-EST
650 From: Jon Solomon <JSOL @ MIT-MC>
651 To: BUG-PEEK @ MIT-MC
653 Sigh, every time I peek at the comsat stats file it gives me
654 an :$MPV not handled$ error and punts. This time after perhaps
655 two screenfuls. I'm on a vt100 running in vt52 mode, and I have
656 had this happen on vt100s running vt100 mode, and H19s.
660 Date: 15 November 1983 19:04 EST
661 From: Alan Bawden <ALAN @ MIT-MC>
663 To: BUG-PEEK @ MIT-MC
665 Is there documentation anywhere for the "E" command?
667 Date: 28 October 1983 06:56 EDT
668 From: David Vinayak Wallace <GUMBY @ MIT-MC>
669 To: BUG-PEEK @ MIT-MC
671 How come the down time message is so fukt?
673 Date: 21 October 1983 16:47 EDT
674 From: Jeffrey P. Golden <JPG @ MIT-MC>
675 To: BUG-PEEK @ MIT-MC
677 Someone should fix the "System going down in" message in PEEK.
678 The times it gives are preposterous.
680 Date: 19 July 1983 03:10 EDT
681 From: Jeffrey P. Golden <JPG @ MIT-MC>
682 To: BUG-PEEK @ MIT-MC
684 When I use LOCK to take the system down, it used to say
685 'System going down in 15:00' or whatever.
687 'System going down in 3:06:21:21 ( 3:09:28:44)'
688 These huge mysterious numbers are not very helpful.
690 Date: 9 July 1983 06:46 EDT
691 From: Christopher C. Stacy <CSTACY @ MIT-MC>
692 Subject: [ELLEN: forwarded]
693 To: BUG-PEEK @ MIT-MC
695 Date: 07/08/83 03:46:40
701 Peek seems not only to not allow you to type a space to redisplay
702 during an "O", but it also sometimes gets into a state where a space
703 will not do anything, no how... I can identify this state because
704 the "More" at the bottom will be
712 I regret that at this instant I cannot tell you how to produce this
713 state. But I suspect it might be related to hopping in and out of
714 PEEK repeatedly... as I sometimes do... then one time I suddenly
715 notice this wierdness...
716 I consider this highly wierd, and am sending this to you, to forward
717 as you please, since I believe it was you who last modified PEEK.
720 gsb@MIT-ML (Sent by TAR@MIT-ML) 05/08/83 00:56:23
721 To: (BUG PEEK) at MIT-ML
722 If i type ahead stuff at peek (like i do
726 then i can make it use **MORE** rather than --More--.
727 This is especially amusing because in **MORE** in peek, the two things
728 which do not work are space and rubout.