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: Fri, 5 May 89 14:14:14 EDT From: Devon Sean McCullough 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 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: From: Rob Austein To: Alan Bawden 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 Date: Sunday, 18 January 1987 22:51-EST From: Alan Bawden 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 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 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 Message-ID: <[AI.AI.MIT.EDU].38227.860513.ALAN> Date: Mon, 12 May 86 20:15:40 EDT From: David Chapman 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 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 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 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 From: Rob Austein To: Chris Lindblad Cc: Alan Bawden , 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 (Oh bleep, let's put this on namecallers and get it over with already). From: Chris Lindblad 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: From: Chris Lindblad To: Rob Austein Cc: Alan Bawden , 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 Date: Thursday, 2 January 1986 13:52-EST From: Rob Austein 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: From: Rob Austein To: Alan Bawden 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 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 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" 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 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 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 Message-ID: <[MC.LCS.MIT.EDU].761316.851219.GUMBY> Date: Wed, 18 Dec 85 21:43:27 EST From: Mark E. Becker 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" 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" 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" 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 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 In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien 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 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 , 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 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 Message-ID: <[MIT-MC].495962.850510.CSTACY> Date: Thu, 9 May 85 20:49:01 EST From: Ken Harrenstien 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 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 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 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 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 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 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 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 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 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 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 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 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 () where is supposedly the remaining increment until the actual occurs. you'd expect that would remain constant and would decrement to 0. what really happens, though, is remains constant (and doesn't jibe with the down warnings produced at top level), and increments to fit !! please fix.  Date: 25 August 1984 16:16-EDT From: David A. Moon 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 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 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 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 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 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 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.