From bawden at parc.xerox.com Sat Sep 30 22:20:00 1989 From: bawden at parc.xerox.com (Alan Bawden) Date: Sep 30 89 14:20 PDT Subject: can't yank from bolix In-Reply-To: <650153.890930.ZVONA@AI.AI.MIT.EDU> Message-ID: <19890930212059.0.ALAN@MR-BUN.parc.xerox.com> Date: Sat, 30 Sep 89 14:24:09 EDT From: David Chapman The bolix has this winning feature where you can send the top of the (bolix) kill ring to a terminal window input stream, simulating the user typing that text. This doesn't work on ITS. It does work on a random sun I just used as a test case. ITS seems to drop all but the first 50 characters or so. Big lose. What's the story? Can this be fixed? The problem is that when a network connection is direct-connected to a STY, the clock level routine that transfers characters from the net to the STY just blasts away without checking if there is room in the 65-character tty input buffer. (Note that on hardwired terminals, users can't type fast enough to fill up this buffer -- and if they do the system dings at them. Also ordinary .IOT to a STY will hang if there isn't room in the buffer.) The two routines STYCHA and STYTCP could be given a few instructions to check to see if the buffer is full, and if so, stop blasting. No blocking or anything complicated would be needed, since you're going to come back and look for more characters to move in the next clock tick anyway. This has a glitch: If nobody is reading anything out of the tty input buffer, like if your program is running and not looking for typein, and the buffer gets full, then you won't be able to ^Z it. The ^Z will just sit in a network buffer and never make it into the tty code (which checks for ^Z and ^_ does some other processing, before it even considers putting anything in the input buffer). I'll bet that the Sun you tried probably has the Unix-analog of this glitch: if a program isn't reading from the terminal, then input can get backed up sufficiently (perhaps back across the network) so that you can't do anything to interrupt it. Of course you might argue that the glitch is worth the convenience of being able to type extremently fast... From ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Sat Sep 30 19:24:09 1989 From: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (David Chapman) Date: Sep 30 89 14:24:09 EDT Subject: can't yank from bolix Message-ID: <650153.890930.ZVONA@AI.AI.MIT.EDU> The bolix has this winning feature where you can send the top of the (bolix) kill ring to a terminal window input stream, simulating the user typing that text. This doesn't work on ITS. It does work on a random sun I just used as a test case. ITS seems to drop all but the first 50 characters or so. Big lose. What's the story? Can this be fixed? From CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Wed Sep 20 10:14:02 1989 From: CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Pandora B. Berman) Date: Sep 20 89 04:14:02 EDT Subject: ai crash Message-ID: <646359.890920.CENT@AI.AI.MIT.EDU> Date: Tue, 19 Sep 89 11:47 PDT From: Alan Bawden Subject: ai crash To: Moon at stony-brook.scrc.symbolics.com, CENT%AI.AI.MIT.EDU at mintaka.lcs.mit.edu Cc: BUG-ITS%AI.AI.MIT.EDU at mintaka.lcs.mit.edu Date: Tue, 19 Sep 89 11:11 EDT From: "David A. Moon" Date: Tue, 19 Sep 89 02:05:05 EDT From: "Pandora B. Berman" KS10 CSL.V5.2 BT AUTO DSKDMP Isn't that the usual symptom of powering the machine off and back on again? Perhaps there was a power surge. Right, the 8080 prints its herald ("KS10 CSL.V5.2") only when it is reset. So either there was a power-glitch of some sort, or somebody pushed the RESET switch on the front of the machine. i suppose. i was logged in through ML's hardwired VT52 though; i don't think there was anyone else on the floor at that hour (2am), much less anyone who would fiddle with the buttons on any ITS, and if there was a power surge it was very local, because neither MC nor ML were affected, nor did i notice more macroscopic effects (fluorescents blinking). From bawden at parc.xerox.com Tue Sep 19 20:47:00 1989 From: bawden at parc.xerox.com (Alan Bawden) Date: Sep 19 89 11:47 PDT Subject: ai crash In-Reply-To: <19890919151141.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19890919184758.1.ALAN@MR-BUN.parc.xerox.com> Date: Tue, 19 Sep 89 11:11 EDT From: "David A. Moon" Date: Tue, 19 Sep 89 02:05:05 EDT From: "Pandora B. Berman" KS10 CSL.V5.2 BT AUTO DSKDMP Isn't that the usual symptom of powering the machine off and back on again? Perhaps there was a power surge. Right, the 8080 prints its herald ("KS10 CSL.V5.2") only when it is reset. So either there was a power-glitch of some sort, or somebody pushed the RESET switch on the front of the machine. (After about 30 seconds, if you don't type anything at the 8080, it decides that probably you want it to boot the machine. So it pretends you gave it the "BT" command (it types "BT AUTO" to let you know what it is doing) which starts up a DSKDMP (if you have an ITS pack mounted on unit 0).) From Moon at stony-brook.scrc.symbolics.com Tue Sep 19 17:11:00 1989 From: Moon at stony-brook.scrc.symbolics.com (David A. Moon) Date: Sep 19 89 11:11 EDT Subject: ai crash In-Reply-To: <645824.890919.CENT@AI.AI.MIT.EDU> Message-ID: <19890919151141.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 19 Sep 89 02:05:05 EDT From: "Pandora B. Berman" for absolutely no apparent reason, ai crashed this morning. it had just printed a line on the console giving the date & time (IT IS NOW...), then there was a blank line followed by KS10 CSL.V5.2 BT AUTO DSKDMP Isn't that the usual symptom of powering the machine off and back on again? Perhaps there was a power surge. From CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Tue Sep 19 08:05:05 1989 From: CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Pandora B. Berman) Date: Sep 19 89 02:05:05 EDT Subject: ai crash Message-ID: <645824.890919.CENT@AI.AI.MIT.EDU> for absolutely no apparent reason, ai crashed this morning. it had just printed a line on the console giving the date & time (IT IS NOW...), then there was a blank line followed by KS10 CSL.V5.2 BT AUTO DSKDMP i dumped it to CRASH;HUH WHAT, even though i rather doubt the crash dump will be useful. then i reloaded with no problems. maybe it was cosmic rays or something. From bawden at parc.xerox.com Mon Sep 11 00:34:00 1989 From: bawden at parc.xerox.com (Alan Bawden) Date: Sep 10 89 15:34 PDT Subject: 25th Anniversary of 36 Bits Message-ID: <19890910223434.2.ALAN@MR-BUN.parc.xerox.com> Article 471 of comp.org.decus: From: clive at pp.ACA.MCC.COM (Clive Dawson) Newsgroups: comp.arch,comp.org.decus Subject: 25th Anniversary of 36 Bits Keywords: 36-bits DEC-10 DEC-20 DECUS Date: Sep 5 89 17:05:12 GMT Organization: MCC, Austin, TX [The number of people who contributed to the recent discussion on Digital's 36-bit architecture made it seem appropriate to post this message here. My apologies for straying from the main subject matter.] A special event will take place at the Fall DECUS Symposium in Anaheim, California, November 6-10, 1989: The 25th Anniversary of 36-bit systems will be celebrated. In 1964, Digital announced the PDP-6. Twenty-five years later, the 36-bit architecture is still here serving a loyal customer base. The celebration will take place on the evening of Monday, November 6, 1989. The usual DEC 10/20 Update Session will be held from 3-5 PM. Last-minute announcements regarding Anniversary events will be made at this session, as well as in the Monday edition of Update.Daily (the Symposium newspaper). A meeting room in one of the Symposium hotels (Hilton or Marriott) will be made available for the anniversary events, which include: -- 36-Bit JEOPARDY! In the tradition of the 36-bit Trivia Bowl held at the 20th Anniversary celebration, experts on the history and folklore of 36-bit systems will compete against each other. Come and match wits with them! -- Memorabilia Exhibit and Swap You are encouraged to bring old manuals, listings, pieces of hardware (e.g. KA and/or KI consoles!), posters, buttons, tapes, and any other items related to 36-bit systems for exhibiting and/or swapping. Table space will be made available. -- Anniversary Dinner Dinner plans are not yet firm. It will either be catered by the hotel or we will adjourn to a nearby restaurant. -- 36-Bit Magic & War Stories Following dinner we will swap war stories and other legends of 36-bit lore. One of the most popular events of the 1984 celebration will be repeated: a reading of several infamous SPR's (and their equally infamous replies.) Come prepared to share share your favorite stories. Prizes for the best will be awarded. Note that these four events will NOT appear in the DECUS schedule since they are not official DECUS functions (and therefore do not require conference registration.) If you are planning to attend any of the 25th Anniversary events, please notify me as soon as possible, since we need to get a reasonable estimate on the number of people to expect. (Dinner plans depend on this, so please try not to delay.) E-mail: Internet: Clive at MCC.COM UUCP: ...!cs.utexas.edu!pp!clive U.S. mail: MCC, 3500 West Balcones Center, Austin, TX 78759 Phone: (512) 338-3430 This will also enable us to create a mailing list for any last minute announcements regarding the events. If you would like table space for exhibits, please mention this. Suggestions regarding dinner plans are also welcome. It may be difficult to find a reasonable restaurant nearby that could handle this. The 20th anniversary dinner was done by the hotel at a cost of $36/person (what else?!). Is this a reasonable fee? If not, let me know how much you would be willing to pay. This message is being sent to the TOPS-20 mailing list and the comp.arch and comp.org.decus news groups. Please redistribute as you see fit and pass the word to other 36-bitters who may not otherwise find out about this. See you in Anaheim! Clive Dawson From CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Fri Sep 8 04:08:49 1989 From: CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Pandora B. Berman) Date: Thu, 7 Sep 89 22:08:49 EDT Subject: quick dump fix Message-ID: <641945.890907.CENT@AI.AI.MIT.EDU> Date: Sat, 2 Sep 89 14:16 PDT From: Alan Bawden Subject: ml and mc stuff To: CENT%AI.AI.MIT.EDU at MINTAKA.lcs.mit.edu Date: Fri, 1 Sep 89 18:04:18 EDT From: "Pandora B. Berman" i got a good version off tape 238, and repaired the data for 238 (which was fine except for claiming you ABRTed rather than DUMPed) and 239. i note that TAPSET automatically sets the user to be the tape writer, which i suppose is not unfair. the broken version of ML:MACRO TAPES is now MACRO XT. it claims to be the same length as the good one. ZVONA usd HEP to dump 239 rather than bonzo, which might have had some effect on the situation. i'm not sure who to refer the matter to for more inspection. The file was busted -before- ZVONA did a dump, so that can't be a problem. Since you apparently got a good version back from 238, then it must have been OK at the beginning of the dump (when it was written to tape) and was then clobbered before the end of the dump (because the damaged file -did- contain a record for tape 238). The file contains nothing but zeros other than the records for the two tapes 238 and 329 (alias 239), just as if DUMP had decided to create an empty database. Thus I suspect that DUMP decided erroneously that the MACRO TAPES file didn't exist (probably it got some error other than FILE NOT FOUND when it when to open it) and decided to recreate it. A PDP-10 hacker (with a reasonable connection) can fix this in nothing flat. All he has to do is visit all the places in DUMP where the MACRO TAPES file is manipulated and fix them to be more careful. (Dave could do this in his sleep -- if my guess about the problem is correct.) would a PDP-10 hacker with a reasonable connection please look into this so i don't have to keep checking the MACRO TAPES file each time i use DUMP? thx. From Moon at stony-brook.scrc.symbolics.com Thu Sep 7 18:02:00 1989 From: Moon at stony-brook.scrc.symbolics.com (David A. Moon) Date: Sep 7 89 12:02 EDT Subject: It's so easy to forget In-Reply-To: <641460.890906.MLY@AI.AI.MIT.EDU> Message-ID: <19890907160253.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 6 Sep 89 19:36:12 EDT From: Richard Mlynarik It's so easy to forget that after one's Macintosh has crashed because of NCSA Telnet not checking for out-of-free-memory conditions and after one's unix "tcp/chaos gateway" telnet login session has been dropped on the floor (because the TCP stream died) that when one eventually re-reaches poor internetworkless AI that one will be greeted with a cheery --Attach Your Detached Tree-- Or in the words of that bouncy, upbeat reggae tune we were hearing a lot of about 6 or 7 years ago: "Every day, everything is getting worse." There's also one which claims to be about Babylon, but I think it's really about Unix, "Total destruction, only solution." From HUFF%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Thu Sep 7 13:47:35 1989 From: HUFF%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Robert Huff) Date: Thu, 7 Sep 89 07:47:35 EDT Subject: No subject Message-ID: <641633.890907.HUFF@AI.AI.MIT.EDU> Hello: A couple of times in the last couple days I have dialed in to AI and the screen/cursor control didn't work. I tried logging out, including off of the terminal access, and back in again. No luck. Yesterday evening it happened while I was logged on. THe first 5-10 minutes of the session were fine, then there was a few moments (longer than the usual delay from operating at 1200bps) of being unable to type into an Emacs session. and suddenly the cursor control was gone. Thanks, Robert Huff From MLY%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Thu Sep 7 01:36:12 1989 From: MLY%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Richard Mlynarik) Date: Wed, 6 Sep 89 19:36:12 EDT Subject: It's so easy to forget Message-ID: <641460.890906.MLY@AI.AI.MIT.EDU> It's so easy to forget that after one's Macintosh has crashed because of NCSA Telnet not checking for out-of-free-memory conditions and after one's unix "tcp/chaos gateway" telnet login session has been dropped on the floor (because the TCP stream died) that when one eventually re-reaches poor internetworkless AI that one will be greeted with a cheery --Attach Your Detached Tree--