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. ------------------------------ Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Apr 90 22:37:18 EDT Received: from BU.EDU by mintaka.lcs.mit.edu id aa23808; 19 Apr 90 22:32 EDT Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 19 Apr 90 22:31:46 EDT Received: by bu-it.bu.edu (12/20/89); Thu, 19 Apr 90 22:31:38 EDT Date: Thu, 19 Apr 90 22:31:38 EDT From: Phil Budne Message-Id: <9004200231.AA04513@bu-it.bu.edu> To: DIGEX%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, DOOMSDAY%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu Subject: Re: the future of ITS Cc: INFO-ITS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, KS-OWNERS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu I started on a '10 simulator, but never wrote the 36 bit math needed. If you figure a 10 times performance hit a DS3100 or a SPARC might yield performance at the KA/KS level.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 19 Apr 90 22:04:09 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8576; 19 Apr 90 22:01:59 EDT Received: from PIGPEN.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA19917; Thu, 19 Apr 90 22:04:14 EDT Date: Thu, 19 Apr 90 22:01 EDT From: Alan Bawden Subject: Praise the hackers of the past! To: ZVONA@ai.ai.mit.edu Cc: BUG-ITS@ai.ai.mit.edu In-Reply-To: <722707.900418.ZVONA@AI.AI.MIT.EDU> Message-Id: <19900420020110.5.ALAN@PIGPEN.AI.MIT.EDU> Date: Wed, 18 Apr 90 20:11:04 EDT From: David Chapman ... the system crashed with DIR 2 ZVONA CLOBBERED PI LEVEL 2 BUGHALT I dumped to crash;zvona clobbr. Reloaded OK. THe directory also looks OK. I don't think I did anything weird to provoke this.... Occasionally a crash dump really does enable you to figure out exactly what the problem was. In this case the in-core copy of your directory really was trashed. It's pretty clear why too. The last 128. words of the ZVONA directory were replaced by the first 128. words of the C directory. Since disk sectors are exactly 128. words long, and the C directory is stored right after the ZVONA directory on disk, it doesn't take Sherlock Holmes to figure out what happened. Be thankful that many years ago some hacker made ITS paranoid about writing a directory back to disk without sanity checking it first.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Apr 90 16:46:56 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09992; 19 Apr 90 16:45 EDT Received: from zurich.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA15299; Thu, 19 Apr 90 16:45:32 EDT Received: from localhost by zurich.ai.mit.edu; Thu, 19 Apr 90 16:43:55 edt Date: Thu, 19 Apr 90 16:43:55 edt From: "Guillermo J. Rozas" Message-Id: <9004192043.AA15383@zurich.ai.mit.edu> To: DIGEX%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Cc: DOOMSDAY%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, KS-OWNERS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, info-its%ai.ai.mit.edu@mintaka.lcs.mit.edu In-Reply-To: Doug Humphrey's message of Thu, 19 Apr 90 16:28:03 EDT <723026.900419.DIGEX@AI.AI.MIT.EDU> Subject: the future of ITS Reply-To: jinx@zurich.ai.mit.edu I think that the idea of a PDP-10 simulator running on a fast Unix box is pretty funny, but would be a very cool hack. Writing such a simulator (except IO instructions) is straight-forward, but changing ITS to do virtual IO would probably be far more painful. It may also require a fair amount of hacking from a very small group of people (Alan, Moon,...), and that may not be reasonable.  Date: Thu, 19 Apr 90 16:28:03 EDT From: Doug Humphrey Subject: the future of ITS To: DOOMSDAY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: INFO-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, KS-OWNERS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <723026.900419.DIGEX@AI.AI.MIT.EDU> I would be interested in getting a discussion going on the future of ITS. This would be open to any kind of strange ideas, from running it on existing KS-10 hardware (at MIT or not) to building a PDP-10 software simulator that can run on existing and/or future cpus, like MIPS chips, etc. In short, before these machines go away, and all of the ITS knowledgable people too far away, lets talk about this stuff. Another point is that INFO-ITS and KS-OWNERS lists should continue to live after the ITS systems go into hibernation so that advances in the ITS state-of-the-art can be announced and discussed. Comments, etc? Doug Humphrey digex@mit-ai digex@tumtum.cs.umd.edu  Date: Wed, 18 Apr 90 20:11:04 EDT From: David Chapman To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <722707.900418.ZVONA@AI.AI.MIT.EDU> Well, this is spectacularly ironic. I was just about to write a magtape of my AI directory to take to CA -- literally seconds from doing so -- when the system crashed with DIR 2 ZVONA CLOBBERED PI LEVEL 2 BUGHALT I dumped to crash;zvona clobbr. Reloaded OK. THe directory also looks OK. I don't think I did anything weird to provoke this....  Date: Sat, 14 Apr 90 02:40:47 EDT From: Alan Bawden Subject: A sad day To: INFO-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Reply-to: Alan@Reagan.AI.MIT.EDU Message-ID: <721426.900414.ALAN@AI.AI.MIT.EDU> I'm sorry to announce that we're going to shut down the ITS machines at MIT. As we plan for the final shutdown, the file AI:SYS;GOOD BYE will be constantly updated to contain the current plans. What follows is the current contents of that file, and it pretty much explain the situation: ------- Well, the time has finally arrived to shut down the ITS machines for the last time. The hardware is getting old, and the amount of maintenance required to keep things running is getting out of hand. We've been losing ground at an accelerating rate for the last year. The current plan is to turn AI and MC off for good sometime around the end of May. We plan to take a snapshot of AI and MC's filesystem sometime before the final shutdown and to keep this snapshot available on some other file server for a couple of months. People who have a large number of files to evacuate, but who lack efficient network access to AI and MC, are encouraged to simply wait until after this snapshot becomes available. AI's second RP06 (SECOND:) will be fixed soon to make it easier for people to evacuate themselves. Files on ITS backup tapes will be unavailable until someone writes the program to read them. Before the shutdown, modest file retrieval requests (mail to FILE-R@AI) will be considered. Extensive or complicated retrieval requests will have to wait until after the dust settles after the shutdown. Our judgment on these matters will be final. Sorry. All mailing lists will have to be moved elsewhere. If you maintain a mailing list on AI or MC, you can save us some trouble by moving your mailing list yourself as soon as possible. We'll try and do something responsible about those important lists that don't have obvious owners, but don't count on us to save your mailing list for you -- we might decide to just let it perish. Please try not to pester us about the personal inconvenience this causes you. We don't have any suggestions about where you should read your mail now, where you can keep your files, or where you can move your mailing list, and we wish we knew of another PDP-10 that you could use. (If you -must- pester someone, send mail to DOOMSDAY@AI.) We do appreciate your loyalty to ITS during its lifetime at MIT. Stop by sometime and we can talk about the good old days when dinosaurs ruled the machine room. As we continue to plan for doomsday, this file will be updated with the latest news. - Alan -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 6 Mar 90 13:12:17 EST Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Mar 90 13:11:41 EST Received: from NIC.DDN.MIL by mintaka.lcs.mit.edu id aa14446; 6 Mar 90 13:03 EST Date: Tue, 6 Mar 90 09:49:38 PST From: Ken Harrenstien Subject: Status? To: bug-its@mc.lcs.mit.edu cc: klh@nic.ddn.mil Message-ID: <12571572384.22.KLH@NIC.DDN.MIL> Uh, I haven't been keeping up with ITS developments for a while. Just noticed that MC is only reachable by a MX record through MINTAKA. Does that mean it's no longer on the Internet at all? No address is forthcoming from either our host tables or the DNS. -------  Date: Thu, 25 Jan 90 04:43:45 EST From: "Pandora B. Berman" Subject: adios to ML To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, POSTMASTER%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, NGL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <693233.900125.CENT@AI.AI.MIT.EDU> alan has made an Executive Decision that trying to make ML work again, as well as keeping AI and MC in good shape, is Too Much Work For One Overloaded Grad Student However Encouraging His Friends Are. therefore, ML isn't coming up again. we did a full dump just before it came down in november, so all the files are available. there is a theory about purchasing (yes, we speak of $$) a System Concepts disk box to hook up to the 2 remaining ITSs; such a thing, according to the SC folks, would emulate some reasonable number of rp06s without including their well-known maintenance problems. NB: we do not have solid commitments on the money yet, so do not assume that we will get this object. there is reason to believe we will, but no guarantees. if we do, there should be no problem loading the ML files onto the space so obtained. in the mean time, we will try to make space for such files available on AI and MC on an as-needed basis. the ML dialups will be moved to MC. i have flushed the references to ML from the system-msg addresses and the inquir updater lists.  Date: Sat, 23 Dec 89 02:40:39 EST From: "Pandora B. Berman" Subject: yow To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <682728.891223.CENT@AI.AI.MIT.EDU> actually, it's not so surprising that some tourists can talk DDT too obscurely for me to understand.... ---------- From: "Stephen E. Robbins" Date: Thu, 21 Dec 89 13:25:56 EST To: CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Subject: Where unix-haters-request is Date: Wed, 20 Dec 89 22:13:42 EST From: "Pandora B. Berman" ....Candidates for entry into this august body must either prove their worth by a short rant on their pet piece of unix brain death, or produce witnesses of known authority to attest to their adherence to our high moral principles.. Does knowing about :DDTSYM DPSTOK/-1 followed by $$^R qualify as attesting to adherence of high moral principles? - Stephen  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Dec 89 16:08:30 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa15010; 15 Dec 89 16:02 EST Received: from Fafnir.Think.COM by Think.COM; Fri, 15 Dec 89 16:03:23 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Fri, 15 Dec 89 15:58:28 EST Received: from ungar.think.com by verdi.think.com; Fri, 15 Dec 89 15:56:16 EST From: Guy Steele Received: by ungar.think.com; Fri, 15 Dec 89 15:56:15 EST Date: Fri, 15 Dec 89 15:56:15 EST Message-Id: <8912152056.AA29450@ungar.think.com> To: Ed@alderaan.scrc.symbolics.com Cc: gumby@gang-of-four.stanford.edu, info-its@ai.ai.mit.edu, unix-haters@ai.ai.mit.edu, gls@think.com In-Reply-To: Ed Schwalenberg's message of Fri, 15 Dec 89 14:56 EST <19891215195628.4.ED@PEREGRINE.SCRC.Symbolics.COM> Subject: TTY MESSAGE FROM A UNIX WEENIE: LOSSAGE? Date: Fri, 15 Dec 89 14:56 EST From: Ed Schwalenberg Date: Thu, 14 Dec 89 19:57:05 -0800 From: David Vinayak Wallace Those who never used TS BEAR may not recognise the message above, but those who do may be amused by how the cookie bear got permuted by the time the unix weenies heard about it. Then again, note his last question... >From: kim@watsup.waterloo.edu (T. Kim Nguyen) Subject: "cookie" Date: 11 Dec 89 09:13:31 GMT While the machine was being dismantled, someone took a look inside and found this circuit board hooked into the machine. Guess what was asking for cookies, and had not been found, even after people searched high and low through the software for the cookie monster... I heard this story when I entered MIT in September 1974. The version I heard allegedly took place at Dartmouth, and the cookie monster wouldn't go away even after the OS was changed; it took a TTY33 repairperson to discover the hardware hack in the system console. I wrote a cookie program for the PDP-8 at MIT's Weather Radar group when I worked there in the summer of 1975, based on the story I had heard. I wasn't aware of TS BEAR until much later, although I don't know when it was written or what inspiration its author (who I think was GLS) had. I wrote TS BEAR after hearing an oral description of a similar hack on (as I recall) Multics. Richard Feynman was perhaps its most famous victim (it was I who sicced it on him--blush).  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Dec 89 15:51:16 EST Received: from [128.81.41.109] by mintaka.lcs.mit.edu id aa14529; 15 Dec 89 15:44 EST Received: from PEREGRINE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 358313; 15 Dec 89 14:59:03 EST Date: Fri, 15 Dec 89 14:56 EST From: Ed Schwalenberg Subject: TTY MESSAGE FROM A UNIX WEENIE: LOSSAGE? To: David Vinayak Wallace , info-its@ai.ai.mit.edu cc: unix-haters@ai.ai.mit.edu, gls@think.com In-Reply-To: <8912150357.AA06208@Gang-of-Four.Stanford.EDU> Message-ID: <19891215195628.4.ED@PEREGRINE.SCRC.Symbolics.COM> Date: Thu, 14 Dec 89 19:57:05 -0800 From: David Vinayak Wallace Those who never used TS BEAR may not recognise the message above, but those who do may be amused by how the cookie bear got permuted by the time the unix weenies heard about it. Then again, note his last question... >From: kim@watsup.waterloo.edu (T. Kim Nguyen) Subject: "cookie" Date: 11 Dec 89 09:13:31 GMT While the machine was being dismantled, someone took a look inside and found this circuit board hooked into the machine. Guess what was asking for cookies, and had not been found, even after people searched high and low through the software for the cookie monster... I heard this story when I entered MIT in September 1974. The version I heard allegedly took place at Dartmouth, and the cookie monster wouldn't go away even after the OS was changed; it took a TTY33 repairperson to discover the hardware hack in the system console. I wrote a cookie program for the PDP-8 at MIT's Weather Radar group when I worked there in the summer of 1975, based on the story I had heard. I wasn't aware of TS BEAR until much later, although I don't know when it was written or what inspiration its author (who I think was GLS) had.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Dec 89 12:51:50 EST Received: from orville.nas.nasa.gov by mintaka.lcs.mit.edu id aa09814; 15 Dec 89 12:45 EST Received: Fri, 15 Dec 89 09:35:06 PST by orville.nas.nasa.gov (5.59/1.2) Date: Fri, 15 Dec 89 09:35:06 PST From: John Lekashman Message-Id: <8912151735.AA21356@orville.nas.nasa.gov> To: gumby@gang-of-four.stanford.edu, info-its@AI.ai.mit.edu Subject: Re: TTY MESSAGE FROM A UNIX WEENIE: LOSSAGE? Cc: unix-haters@AI.ai.mit.edu The answer is yes. Either it really happened, or all of Seymour Papert's students are on drugs is true. (oooooeeeee-eeeee). At least back in the 70s. john  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 14 Dec 89 23:01:56 EST Received: from Gang-of-Four.Stanford.EDU by mintaka.lcs.mit.edu id aa22227; 14 Dec 89 22:57 EST Received: by Gang-of-Four.Stanford.EDU (5.61/inc-1.0) id AA06208; Thu, 14 Dec 89 19:57:05 -0800 Date: Thu, 14 Dec 89 19:57:05 -0800 From: David Vinayak Wallace Message-Id: <8912150357.AA06208@Gang-of-Four.Stanford.EDU> To: info-its@ai.ai.mit.edu Cc: unix-haters@ai.ai.mit.edu Subject: TTY MESSAGE FROM A UNIX WEENIE: LOSSAGE? Those who never used TS BEAR may not recognise the message above, but those who do may be amused by how the cookie bear got permuted by the time the unix weenies heard about it. Then again, note his last question... Makes one wonder what the loser who wrote the Canonical Losing Unix Mailer thought he was writing. >From: kim@watsup.waterloo.edu (T. Kim Nguyen) Newsgroups: alt.folklore.computers Subject: "cookie" Message-ID: Date: 11 Dec 89 09:13:31 GMT OK, here's another one I heard about. This one (I was told) happened at MIT, back in the 70s (oooooeeeee-ooooo), on some big network type machine. At the same time every day, a message would appear on people's terminals, saying "Give me a cookie". And if they did nothing, the machine would burp and kill their process or something. Eventually someone, in response to that message, typed "cookie", and the machine said "thanks" and continued working normally. For the remainder of the machine's lifetime, people would type "cookie" at the same time every day and take it for granted that they had to do this. While the machine was being dismantled, someone took a look inside and found this circuit board hooked into the machine. Guess what was asking for cookies, and had not been found, even after people searched high and low through the software for the cookie monster... So -- did this really happen, or are all of Seymour Papert's students on drugs? :-) -- T. Kim Nguyen kim@watsup.waterloo.{edu|cdn} kim@watsup.uwaterloo.ca {uunet|utzoo|utai|decvax}watmath!watsup!kim Systems Design Engineering -- University of Waterloo, Ontario, Canada  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 9 Nov 89 10:10:19 EST Received: from [128.81.41.109] by mintaka.lcs.mit.edu id aa23311; 9 Nov 89 10:05 EST Received: from PEREGRINE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 347958; 9 Nov 89 10:03:40 EST Date: Thu, 9 Nov 89 10:03 EST From: Ed Schwalenberg Subject: looking for old weirdness To: "Pandora B. Berman" , BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu cc: rdm%ncsa.uiuc.edu@mintaka.lcs.mit.edu In-Reply-To: <666900.891109.CENT@AI.AI.MIT.EDU> Message-ID: <19891109150307.9.ED@PEREGRINE.SCRC.Symbolics.COM> Date: Thu, 9 Nov 89 04:19:39 EST From: "Pandora B. Berman" Date: Fri, 3 Nov 89 13:32:49+060 From: "Ronald D. Mabbitt" To: cent@ai.ai.mit.edu Subject: Zork, mdl, etc! Hi, I'm trying to find the original MDL Zork and MDL compiler and MDL manuals, etc, for possible academic anduse research use. Is it findable? It should be all old DARPA stuff, so there shouldn't be any licencing problems... anyone know where this stuff might be hiding? Presumably the MDL manuals can be found in the LCS Reading Room. The compiler sources are probably on DM backup tapes, wherever they've gone. Perhaps sources to the manuals are also on backup tape. The sources to Zork itself were not kept online, or if they were, they were kept encrypted. I doubt you could resurrect it without help from one of the original Zork wizards. You might ask TAA (Tim Anderson), who's now at Interleaf, 577-9800. My recollection is that he was only peripherally involved with Zork, but he might know how to get in touch with the others.  Date: Thu, 9 Nov 89 04:19:39 EST From: "Pandora B. Berman" Subject: looking for old weirdness To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: rdm%ncsa.uiuc.edu@MINTAKA.LCS.MIT.EDU Message-ID: <666900.891109.CENT@AI.AI.MIT.EDU> Date: Fri, 3 Nov 89 13:32:49+060 From: "Ronald D. Mabbitt" To: cent@ai.ai.mit.edu Subject: Zork, mdl, etc! Hi, I'm trying to find the original MDL Zork and MDL compiler and MDL manuals, etc, for possible academic anduse research use. Is it findable? It should be all old DARPA stuff, so there shouldn't be any licencing problems... anyone know where this stuff might be hiding?  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 Oct 89 19:56:21 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01041; 23 Oct 89 19:47 EDT Received: from wheat-chex (wheat-chex.ai.mit.edu) by life.ai.mit.edu (4.0/AI-4.10) id AA29244; Mon, 23 Oct 89 19:48:03 EDT From: "Leonard N. Foner" Received: by wheat-chex (4.0/AI-4.10) id AA10349; Mon, 23 Oct 89 19:47:51 EDT Date: Mon, 23 Oct 89 19:47:51 EDT Message-Id: <8910232347.AA10349@wheat-chex> To: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu Cc: ALAN%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, FONER%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-Reply-To: "Pandora B. Berman"'s message of Mon, 23 Oct 89 19:08:26 EDT <659250.891023.CENT@AI.AI.MIT.EDU> Subject: inquir broken Date: Mon, 23 Oct 89 19:08:26 EDT From: "Pandora B. Berman" Date: Mon, 23 Oct 89 15:20 PDT From: Alan Bawden Subject: inquir broken To: foner@ai.mit.edu Cc: CENT@ai, BUG-INQUIR@ai, BUG-ITS@ai, ARCHY@ai Date: Tue, 17 Oct 89 22:29:41 EDT From: "Leonard N. Foner" I just fixed ARCHY's address to say ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM. Just specifying @SYMBOLICS.COM yields nondeterministic results The results are completely deterministic since we go out of our way to keep the name "Symbolics.COM" attached to -some- host in the host table we use. (Remember host tables? -- we still use 'em.) I don't happen to know which host that is at the moment, perhaps we need to move it to Elephant-Butte. Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM" in the NAMES file or INQUIR database does -not- affect what address the mailer uses in delivering the mail. In either case it will be canonicalized to the primary name of the host (Elephant-Butte in this case). no, SCRC (and the other standard names) all canonicalize to STONY-BROOK. That's fine. Since the "@SYMBOLICS.COM" is hidden from the mailer at Stony by the mailing list expansion on AI, the Stony mailer can't spazz and do something stupid. So perhaps someone should put Bill's address back the way it was before... i did that the next time i had an occasion to go into NAMES >.. Okay, thanks. I was under the mistaken assumption that everything that looked like a domain name was getting delivered to Mintaka for domain lookup and delivery. Guess not. (Guess I was confused by all the @MINTAKA's all over ITS headers since the ARPAnet evaporated.)  Date: Mon, 23 Oct 89 19:08:26 EDT From: "Pandora B. Berman" Subject: inquir broken To: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: FONER%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <659250.891023.CENT@AI.AI.MIT.EDU> Date: Mon, 23 Oct 89 15:20 PDT From: Alan Bawden Subject: inquir broken To: foner@ai.mit.edu Cc: CENT@ai, BUG-INQUIR@ai, BUG-ITS@ai, ARCHY@ai Date: Tue, 17 Oct 89 22:29:41 EDT From: "Leonard N. Foner" I just fixed ARCHY's address to say ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM. Just specifying @SYMBOLICS.COM yields nondeterministic results The results are completely deterministic since we go out of our way to keep the name "Symbolics.COM" attached to -some- host in the host table we use. (Remember host tables? -- we still use 'em.) I don't happen to know which host that is at the moment, perhaps we need to move it to Elephant-Butte. Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM" in the NAMES file or INQUIR database does -not- affect what address the mailer uses in delivering the mail. In either case it will be canonicalized to the primary name of the host (Elephant-Butte in this case). no, SCRC (and the other standard names) all canonicalize to STONY-BROOK. So perhaps someone should put Bill's address back the way it was before... i did that the next time i had an occasion to go into NAMES >.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 Oct 89 18:37:11 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa16237; 23 Oct 89 18:24 EDT Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06924; Mon, 23 Oct 89 15:21:20 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05120; Mon, 23 Oct 89 15:22:23 PDT Date: Mon, 23 Oct 89 15:20 PDT From: Alan Bawden Subject: inquir broken To: foner@ai.mit.edu Cc: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, ARCHY%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-Reply-To: <8910180229.AA08171@wheat-chex> Message-Id: <19891023222018.3.ALAN@MR-BUN.parc.xerox.com> Date: Tue, 17 Oct 89 22:29:41 EDT From: "Leonard N. Foner" I just fixed ARCHY's address to say ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM. Just specifying @SYMBOLICS.COM yields nondeterministic results The results are completely deterministic since we go out of our way to keep the name "Symbolics.COM" attached to -some- host in the host table we use. (Remember host tables? -- we still use 'em.) I don't happen to know which host that is at the moment, perhaps we need to move it to Elephant-Butte. Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM" in the NAMES file or INQUIR database does -not- affect what address the mailer uses in delivering the mail. In either case it will be canonicalized to the primary name of the host (Elephant-Butte in this case). So perhaps someone should put Bill's address back the way it was before...  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 17 Oct 89 22:37:12 EDT Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18749; 17 Oct 89 22:29 EDT Received: from wheat-chex (wheat-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA06601; Tue, 17 Oct 89 22:29:51 EDT From: "Leonard N. Foner" Received: by wheat-chex (4.0/AI-4.10) id AA08171; Tue, 17 Oct 89 22:29:41 EDT Date: Tue, 17 Oct 89 22:29:41 EDT Message-Id: <8910180229.AA08171@wheat-chex> To: CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Cc: BUG-INQUIR%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, ARCHY%AI.AI.MIT.EDU@mintaka.lcs.mit.edu In-Reply-To: "Pandora B. Berman"'s message of Tue, 17 Oct 89 02:43:42 EDT <656327.891017.CENT@AI.AI.MIT.EDU> Subject: inquir broken Cc: foner@ai.mit.edu Date: Tue, 17 Oct 89 02:43:42 EDT From: "Pandora B. Berman" i was trying to fix ARCHY's inquir entry to show his real net address, which is york%ila-west.dialnet.symbolics.com@symbolics.com. inquir has been fukt over (yes, i know, several years ago) so that it refuses to accept this address on the grounds that it is "too long for this item". when i ran inquir on AI, this msg flashed by before i could see it, and i was confronted merely with an altered inquir entry listing giving "T" as the address. fortunately i examined the modified entry and so did not send it off for installation. when i supduped over to MC, inquir showed me the error msg with a decent delay. on both machines, what seems to occur is that a T replaces the so-called too-long item, and the too-long item ends up appearing as if it had been typed to the What next? question. anyway, i had to go into NAMES > in order to fix archy's address.. I just fixed ARCHY's address to say ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM. Just specifying @SYMBOLICS.COM yields nondeterministic results---sometimes, the mailer at whichever machine at Symbolics happens to get the mail becomes confused and will do something random with such an address, because the mailer doesn't yet "really" understand domains and sometimes thinks, "Wait, there's no site named Symbolics... I guess I'll do something weird." (There *is* a site named SCRC, but...) It'll be a while until the mailer does understand domains correctly. Until then, you should specify a real host, not a domain.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 17 Oct 89 12:30:18 EDT Received: from ALEXANDER.BBN.COM by mintaka.lcs.mit.edu id aa11140; 17 Oct 89 12:19 EDT To: "Pandora B. Berman" cc: BUG-INQUIR%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, ARCHY%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Subject: Re: inquir broken In-reply-to: Your message of Tue, 17 Oct 89 02:43:42 -0400. <656327.891017.CENT@AI.AI.MIT.EDU> Date: Tue, 17 Oct 89 12:08:22 -0400 From: cstacy@bbn.com Message-ID: <8910171219.aa11140@mintaka.lcs.mit.edu> Date: Tue, 17 Oct 89 02:43:42 EDT From: "Pandora B. Berman" Message-ID: <656327.891017.CENT@AI.AI.MIT.EDU> i was trying to fix ARCHY's inquir entry to show his real net address, which is york%ila-west.dialnet.symbolics.com@symbolics.com. inquir has been fukt over (yes, i know, several years ago) so that it refuses to accept this address on the grounds that it is "too long for this item". I don't understand this part of the bug report. The system has always had fixed limits on the length of the items. The limits are defined in the file LSRTNS, and there is also a definition in INQUIR which must be kept in step. If INQUIR were to accept an overly long item, the INQUPD program would simply truncate the item, and mail back a message to the luser indicating that the data was truncated. That the user interface doesn't let things get that far, is definitely a feature. (This is especially true if the field under discussion is the network address!) If your complaint is that 40 characters is too small, in these days of kludged up mailing addresses, I'd believe that. It takes somewhat of an operation to change the database format though. when i ran inquir on AI, this msg flashed by before i could see it, and i was confronted merely with an altered inquir entry listing giving "T" as the address. fortunately i examined the modified entry and so did not send it off for installation. when i supduped over to MC, inquir showed me the error msg with a decent delay. on both machines, what seems to occur is that a T replaces the so-called too-long item, and the too-long item ends up appearing as if it had been typed to the What next? question. anyway, i had to go into NAMES > in order to fix archy's address.. I have a version of INQUIR in which this bug is probably fixed, but I'm going to wait until I happen by MIT to try it out; it's too painful to debug over lots of telnet hops and so forth.  Date: Tue, 17 Oct 89 02:43:42 EDT From: "Pandora B. Berman" Subject: inquir broken To: BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: ARCHY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <656327.891017.CENT@AI.AI.MIT.EDU> i was trying to fix ARCHY's inquir entry to show his real net address, which is york%ila-west.dialnet.symbolics.com@symbolics.com. inquir has been fukt over (yes, i know, several years ago) so that it refuses to accept this address on the grounds that it is "too long for this item". when i ran inquir on AI, this msg flashed by before i could see it, and i was confronted merely with an altered inquir entry listing giving "T" as the address. fortunately i examined the modified entry and so did not send it off for installation. when i supduped over to MC, inquir showed me the error msg with a decent delay. on both machines, what seems to occur is that a T replaces the so-called too-long item, and the too-long item ends up appearing as if it had been typed to the What next? question. anyway, i had to go into NAMES > in order to fix archy's address.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Sep 89 22:10:18 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa14259; 30 Sep 89 20:28 EDT Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 667215; 30 Sep 89 20:29:16 EDT Date: Sat, 30 Sep 89 20:29 EDT From: Mike McMahon Subject: can't yank from bolix To: Alan Bawden cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-Reply-To: <19890930212059.0.ALAN@MR-BUN.parc.xerox.com> Message-ID: <19891001002913.4.MMCM@OWL.SCRC.Symbolics.COM> Date: Sat, 30 Sep 89 14:20 PDT From: Alan Bawden 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. Fixed in Tenex :-)  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Sep 89 19:46:39 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa13872; 30 Sep 89 19:41 EDT Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25560; Sat, 30 Sep 89 14:23:07 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19080; Sat, 30 Sep 89 14:23:07 PDT Date: Sat, 30 Sep 89 14:20 PDT From: Alan Bawden Subject: can't yank from bolix To: ZVONA%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu Cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu 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...  Date: Sat, 30 Sep 89 14:24:09 EDT From: David Chapman Subject: can't yank from bolix To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU 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?  Date: Wed, 20 Sep 89 04:14:02 EDT From: "Pandora B. Berman" Subject: ai crash To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU 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@stony-brook.scrc.symbolics.com, CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Cc: BUG-ITS%AI.AI.MIT.EDU@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).  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 19 Sep 89 15:05:48 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa17032; 19 Sep 89 14:50 EDT Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26638; Tue, 19 Sep 89 11:45:07 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14847; Tue, 19 Sep 89 11:49:05 PDT Date: Tue, 19 Sep 89 11:47 PDT From: Alan Bawden Subject: ai crash To: Moon@stony-brook.scrc.symbolics.com, CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Cc: BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu 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).)  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 19 Sep 89 11:17:08 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa13635; 19 Sep 89 11:11 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 660133; 19 Sep 89 11:11:36 EDT Date: Tue, 19 Sep 89 11:11 EDT From: "David A. Moon" Subject: ai crash To: "Pandora B. Berman" cc: BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu 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.  Date: Tue, 19 Sep 89 02:05:05 EDT From: "Pandora B. Berman" Subject: ai crash To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU 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.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 10 Sep 89 18:45:52 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa23016; 10 Sep 89 18:37 EDT Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19688; Sun, 10 Sep 89 15:33:12 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03302; Sun, 10 Sep 89 15:36:37 PDT Date: Sun, 10 Sep 89 15:34 PDT From: Alan Bawden Subject: 25th Anniversary of 36 Bits To: Info-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu Supersedes: <19890910220047.1.ALAN@MR-BUN.parc.xerox.com> Comments: There is too a host named MINTAKA.LCS.MIT.EDU. Try again, Unix braindeath. Message-Id: <19890910223434.2.ALAN@MR-BUN.parc.xerox.com> Article 471 of comp.org.decus: From: clive@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: 5 Sep 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@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  Date: Thu, 7 Sep 89 22:08:49 EDT From: "Pandora B. Berman" Subject: quick dump fix To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU 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@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.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 7 Sep 89 12:11:33 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa08922; 7 Sep 89 12:01 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 653730; 7 Sep 89 12:03:04 EDT Date: Thu, 7 Sep 89 12:02 EDT From: "David A. Moon" Subject: It's so easy to forget To: Richard Mlynarik cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu 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."  Date: Thu, 7 Sep 89 07:47:35 EDT From: Robert Huff To: CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU 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  Date: Wed, 6 Sep 89 19:36:12 EDT From: Richard Mlynarik Subject: It's so easy to forget To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU 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--  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Aug 89 20:29:29 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa22219; 30 Aug 89 20:24 EDT Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04145; Wed, 30 Aug 89 17:20:46 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13692; Wed, 30 Aug 89 17:23:30 PDT Date: Wed, 30 Aug 89 17:22 PDT From: Alan Bawden Subject: ml and mc stuff To: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu Cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-Reply-To: <639391.890830.CENT@AI.AI.MIT.EDU> Message-Id: <19890831002221.0.ALAN@MR-BUN.parc.xerox.com> Date: Wed, 30 Aug 89 17:03:03 EDT From: "Pandora B. Berman" you were going to drop us a note explaining how to avoid mc's frequent parerr losses. Here is what you do to disable parity checking: At any time -after- you have started DSKDMP, type ^\ to get the 8080's attention. This should result in a "KS10>" prompt. The you type "PE0" followed by a carrage return. You should get another "KS10>" prompt. Then type ^Z. The 8080 will type "USR MOD" and now you are back where you were before you typed the ^\. The reason you have to wait until after starting DSKDMP is that the BT command turns parity checking on. You really can do this at -any- time once the PDP10 is rinning. You can even walk up to a running ITS and do this. And in fact you should probably do this to MC as soon as possible. also, exactly what is it that's wrong with ML and needs to be fixed asap? the macro tapes file? Right. You can easily see that it is broken by going into DUMP and giving the TAPES command. The output looks like: _tapes LIST DEV =tty 238 890804 INCR ALAN5 DUMP 0 . SYSHST 329 890814 INCR ZVONA DUMP 0 . USERS2 Where the hell are the rest of the tapes? (And yeah, Zvona must have typoed when he made that incremental...) A hacker should look at the bits in the existing MACRO TAPES file to see if he or she can figure out what went wrong. (The latest version of DUMP is a suspect.) To repair the damage, first restore the MACRO TAPES file from tape (try tape 238 first, then 237, etc.), and then use the TAPSET command to enter the information that is missing.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 14 Aug 89 16:46:09 EDT Received: from Xerox.COM by mintaka.lcs.mit.edu id aa27549; 14 Aug 89 16:43 EDT Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 89 13:38:49 PDT Date: Mon, 14 Aug 89 13:32 PDT From: bawden.pa@xerox.com Subject: Well, -we- had an earthquake. To: ZVONA%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-Reply-To: <633201.890813.ZVONA@AI.AI.MIT.EDU> Message-ID: <19890814203257.2.ALAN@ROCKY.parc.xerox.com> Line-fold: no Date: Sun, 13 Aug 89 13:54:15 EDT From: David Chapman At 10:09 this morning all the ITSes apparently died. The consoles said BT AUTO and were in DSKDMP. I take it this is what happens when the power glitches? Yup. (Probaly the fault of the thunderstorms.) I hope they were good thunderstorms! Anyway, I dumped to ai;auto boot? (probably useless) and booted OK. Yeah, crash dumps are always useless after the 8080 has booted the machine since that clears core. Of course it can't -hurt- to take a crash dump -- you can tell that a crash dump is probably useless if it is very small. (The AUTO BOOT? dump you made is only a block long...) -------  Date: Sun, 13 Aug 89 13:54:15 EDT From: David Chapman To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <633201.890813.ZVONA@AI.AI.MIT.EDU> At 10:09 this morning all the ITSes apparently died. The consoles said BT AUTO and were in DSKDMP. I take it this is what happens when the power glitches? (Probaly the fault of the thunderstorms.) Anyway, I dumped to ai;auto boot? (probably useless) and booted OK.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 11 Aug 89 01:52:39 EDT Received: from XEROX.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 248263; 11 Aug 89 01:49:41 EDT Received: from Semillon.ms by ArpaGateway.ms ; 10 AUG 89 22:48:51 PDT Date: Thu, 10 Aug 89 22:46 PDT From: bawden.pa@Xerox.COM Subject: Barf! To: Bug-ITS@AI.AI.MIT.EDU Message-ID: <19890811054636.5.ALAN@ROCKY.parc.xerox.com> Line-fold: no The MACRO TAPES database on ML seems to be screwed up. This might be a symptom of something wrong with the new DUMP I installed there before I left for here. Symptom: Start DUMP. Give the "TAPES" command. There only appears to be saved tape information for the most recently written tape. I -thought- that the information saved in the records in SYSENG;MACRO TAPES was unrelated to the format of actualy tape headers. Perhaps I was wrong... (But I still don't understand how that could clobber the entire database, even -old- versions of DUMP can't find any information.) Unfortunately for you all, I'm unlikely to be able to fix this from out here. -------  Date: Thu, 20 Jul 89 14:58:16 EDT From: David Chapman To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <623723.890720.ZVONA@AI.AI.MIT.EDU> AI died. Very dead; apparently a FEP crash, because the console wouldn't respond to c-\. The BOOT switch didn't do anything either. RESET woke up the FEP and it booted OK. Crash dump in CRASH;DEAD IN-H2O.  Date: Mon, 26 Jun 89 18:33:12 EDT From: "Pandora B. Berman" Subject: access to AI To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, mayer@IUVAX.CS.INDIANA.EDU cc: amarylis@LIFE.AI.MIT.EDU Message-ID: <614488.890626.CENT@AI.AI.MIT.EDU> From: amarylis@ai.mit.edu (Eva Berlandi) Date: Mon, 26 Jun 89 17:01:04 EDT To: all-ai@wheaties.ai.mit.edu I got this message from this guy, and I can't help him, or know even if I ought to: Date: Fri, 23 Jun 89 11:05:00 -0500 From: mayer goldberg To: amarylis@corn-chex.ai.mit.edu Hello Ms. Berlandi, I don't suppose you know me, as I was logged on corn-chex via rms's account. I am trying to get to ai.ai.mit.edu, but had a problem finding its internet address ... I finally got 10.2.0.6, but it is not responding, so I am afraid, it must have been changed ... Given that it is in the "AI Lab", would you be able to find the address and send it to me? I would be most greatful to you. Mayer Goldberg. Mr. Goldberg: Due to software rot, AI.AI.MIT.EDU is not directly on the Internet. Since May, when our IMPs were turned off, AI has lived only on our local ChaosNet, and has only been able to deal with the InterNet via mail. All other connection protocols, including TELNET/SUPDUP, are unusable until we get the necessary software written to put AI directly on the Internet. If you think you have some special circumstance for deserving access to AI, please send mail to USER-ACCOUNTS@AI.AI.MIT.EDU explaining same, and we'll decide whether we agree and if so what we can do about it. Amarylis: Questions concerning access to the AI machine (AI.AI.MIT.EDU) should be sent to the address USER-ACCOUNTS here. Thanks.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Jun 89 14:04:01 EDT Received: from ML.AI.MIT.EDU (CHAOS 3133) by MC.LCS.MIT.EDU 4 Jun 89 14:03:38 EDT Date: Sun, 4 Jun 89 14:03:09 EDT From: Alan Bawden Subject: it's a virus To: ZVONA%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-ITS%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <10054.890604.ALAN@ML.AI.MIT.EDU> Date: Sat, 3 Jun 89 14:41:32 EDT From: David Chapman Subject: it's a virus AI just crashed with parity error 377 001 300. That's the one we're used to seeing on MC, right? Right, although MC doesn't seem to be getting them anymore... And it's never happened on AI before, right? Actually, I think this has happend on AI about twice before...  Date: Sat, 3 Jun 89 14:41:32 EDT From: David Chapman Subject: it's a virus To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <603861.890603.ZVONA@AI.AI.MIT.EDU> AI just crashed with parity error 377 001 300. That's the one we're used to seeing on MC, right? And it's never happened on AI before, right? Shit.  Date: Fri, 26 May 89 14:08:17 EDT From: Richard Mlynarik Subject: jobdev;chaos tcp To: SRA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <600669.890526.MLY@AI.AI.MIT.EDU> The lisp machines won't attempt to use TCP-GATEWAY on MC because MC doesn't have an internet address. So what's the problem?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 13:53:22 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 214249; 26 May 89 13:51:46 EDT Received: by bigboote.LCS.MIT.EDU id AA00896; Fri, 26 May 89 13:52:36 EDT Date: Fri, 26 May 89 13:52:36 EDT Message-Id: <8905261752.AA00896@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: ZVONA@ai.ai.mit.edu, RS@ai.ai.mit.edu Cc: BUG-ITS@ai.ai.mit.edu In-Reply-To: David Chapman's message of Fri, 26 May 89 12:44:56 EDT <600506.890526.ZVONA@AI.AI.MIT.EDU> Subject: system full Date: Fri, 26 May 89 12:17:38 EDT From: David Chapman AI was dead in the water, typing Warning:system full, no job slots on the console every two seconds. I crash dumped to crash;sys ful. I don't know whether this is relevant, but it was getting a lot of top-level interrupt 200s in TCP and CHAOS jobs not long before it lost it. Date: Fri, 26 May 89 12:44:56 EDT From: David Chapman Uh, actually, maybe the problem was that it was running ITS 1632 (which RS brought up this morning) -- maybe something else has changed incompatibly, like say COMSAT?. We're running 1633 again now. Given that ITS.1632 has TCP code which would presumably be somewhat upset at the lack of an IMP behaving in any known fashion, this is not terribly surprising. Yes, COMSAT would also be upset to find that AI was running ITS.1632 again, since it determines what it should do about routing to TCP hosts by asking the monitor if it supports TCP or not. Perhaps we should delete/hide JOBDEV;CHAOS TCP on AI and MC? It's not like it's doing all those Lisp Machines any good to try getting to the ARPANET via MC and AI anymore.  Date: Fri, 26 May 89 13:30:39 EDT From: Alan Bawden To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, RS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <600605.890526.ALAN@AI.AI.MIT.EDU> Right. There were a bunch of things all going wrong here, most of them caused by the fact that the hosttable no longer contains IP addresses for AI and MC. Certainly that is what made COMSAT crash, and I'm pretty sure that that is what caused the system to fill up with dead mail servers. Rob, you should learn to be more suspicious of situations where you can't see any reason how something could fail to work. (The current series of Calvin & Hobbes comes to mind...)  Date: Fri, 26 May 89 12:44:56 EDT From: David Chapman Subject: system full To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: RS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <600506.890526.ZVONA@AI.AI.MIT.EDU> Uh, actually, maybe the problem was that it was running ITS 1632 (which RS brought up this morning) -- maybe something else has changed incompatibly, like say COMSAT?. We're running 1633 again now.  Date: Fri, 26 May 89 12:17:38 EDT From: David Chapman To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <600479.890526.ZVONA@AI.AI.MIT.EDU> AI was dead in the water, typing Warning:system full, no job slots on the console every two seconds. I crash dumped to crash;sys ful. I don't know whether this is relevant, but it was getting a lot of top-level interrupt 200s in TCP and CHAOS jobs not long before it lost it.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 2 May 89 17:53:25 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 202126; 2 May 89 17:46:58 EDT Received: by bigboote.LCS.MIT.EDU id AA01196; Tue, 2 May 89 17:48:20 EDT Date: Tue, 2 May 89 17:48:20 EDT Message-Id: <8905022148.AA01196@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: PGS@ai.ai.mit.edu Cc: BUG-ITS@ai.ai.mit.edu In-Reply-To: "Patrick G. Sobalvarro"'s message of Tue, 2 May 89 17:33:17 EDT <589618.890502.PGS@AI.AI.MIT.EDU> Subject: host tables in the brave new world Date: Tue, 2 May 89 17:33:17 EDT From: "Patrick G. Sobalvarro" When we switched host table formats a few years ago, I stopped knowing how to update them. Is there an easy way to add AI.MIT.EDU to them, now that that's showing up as a return address on mail from the Unixes? You don't want to know. Really. You don't. The short answer is that everything came to a grinding halt when XX went away and we are just about back on our feet now. If all goes well, automatic table generation and installation should start up again within a few days.  Date: Tue, 2 May 89 17:33:17 EDT From: "Patrick G. Sobalvarro" Subject: host tables in the brave new world To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <589618.890502.PGS@AI.AI.MIT.EDU> When we switched host table formats a few years ago, I stopped knowing how to update them. Is there an easy way to add AI.MIT.EDU to them, now that that's showing up as a return address on mail from the Unixes?  Received: from LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 31 Jan 89 19:28:23 EST Date: Tue 31 Jan 89 19:23:58-EST From: "J. Noel Chiappa" To: Alan@AI.AI.MIT.EDU, SRA@LCS.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, JNC@LCS.MIT.EDU In-Reply-To: <19890131201142.2.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <12467048716.14.JNC@LCS.MIT.EDU> That is, he believed that there was something we could do, -if- we knew the machine was about to crash, that would normalize relations with the IMP so that the NOC's software not to bitch. This sounds sort of bogus to me. The p4200 ARPANet code doesn't give any warning when *it's* going to crash, but the NOC people don't seem to be turning p4200 ports off. Maybe it's just the frequency of the crashes, which proably generate little 'Host X on IMP Y went down' messages on te NOC console. I could also believe that the MC IMP code is doing something that causes a message to come out, hence the turnoff, but I'm not sure how likely this is. However, I think the whole issue is moot. According to what I hear, they are going to turn off the ARPANet in the near future, and *ALL* the MIT IMP's are going away. If you want any ITS (including MC, which has out main mail forwarder) to have Internet access after that date, someone better get busy and write some local net driver for the machine (and then we can have them all on the Internet, not just MC and AI). You can have Pronet-10 interfaces for all the machines; Mike Patton has a ton of them, and they're pretty easy to program. I don't know how many Interlan Unibus Ethernet cards there are, but now that the 750's are mostly gone there may be a bunch of them too. They are somewhat harder to program, and you'd also have to write ARP. Noel -------  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 31 Jan 89 15:13:53 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 169823; Tue 31-Jan-89 15:11:37 EST Date: Tue, 31 Jan 89 15:11 EST From: Alan Bawden To: SRA@XX.LCS.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, Zvona@AI.AI.MIT.EDU In-Reply-To: Message-ID: <19890131201142.2.ALAN@PIGPEN.AI.MIT.EDU> Date: Sun, 29 Jan 1989 22:07:48 EST From: Rob Austein Do we actually understand the syndrome well enough to say who all the culprits are? I think so. According to our spy at SAIL: Date: Sun, 29 Jan 89 20:45:30 EST From: David Chapman ... Joe [Weening] says that SAIL has the same problem with them we do, and that it actualy comes not from a change in the TIP software but from the NOC monitoring software, which now displays a message on the operator's console every time a host does something weird. Whatever MC does constitutes something weird, adn tehy get sick of seeing it, and so they manually turn off the host interface.... The only thing I would add to this is that according to a drone at the NOC I tried to get some information out of one day, the "something weird" that MC does is crash at the wrong time. That is, he believed that there was something we could do, -if- we knew the machine was about to crash, that would normalize relations with the IMP so that the NOC's software not to bitch. Needless to say, this isn't very useful if your machine gets errors that cause it to drop dead without warning (as MC has been doing). I know that the NOC does this random shutoff thing, and I think I remember hearing that there was a hardware bug on our side; There is no hardware bug on our side, unless you count the fact that the processor has a tendency to spontaneously drop dead. There is nothing wrong with the LH/DH-11. is there also, for example, a software problem in the IMP that causes this? I have been accusing the vaguely defined "IMP software". It sounds like software in question doesn't actually run in an IMP, but in some machine at the NOC. The reason I ask is that we (well, MIT, or DARPA, or somebody) pay lots of money for the IMP ports, and if the NOC is shutting off our service because their software can't cope, I think we can legitimately give them some grief in the formal sense. If it's just a stupid reaction on their part to a bug (hardware/software, our/DEC's/ACC's fault, I don't care), I guess we have to live with it. It sounds to me like it is a stupid reaction on their part to a software bug in -their- software. I don't think it is reasonable that we should have to live with it. If this is BBN's fault beyond the NOC lossage, I think we should kick them, hard. Hell, maybe we should call our congresscritters and complain about government waste due to incompetant contractors. I have never understood the dividing line you draw between uneasonable behavior that we have to live with and uneasonable behavior that we should bitch about. It seems quite clear to me that if you are running a network like the Arpanet, and your software causes your operators to shut off service to your users just because they crashed at the wrong moment, then your customers have legitimate cause to bitch.  Received: from bigboote.LCS.MIT.EDU (TCP 2206400176) by AI.AI.MIT.EDU 29 Jan 89 22:09:05 EST Received: by bigboote.LCS.MIT.EDU id AA11349; Sun, 29 Jan 89 22:07:52 EST Sender: Rob Austein Date: Sun, 29 Jan 1989 22:07:48 EST From: Rob Austein To: ALAN@ai.ai.mit.edu Cc: BUG-ITS@ai.ai.mit.edu In-Reply-To: Your message of Sun, 29 Jan 89 18:04:44 EST Message-Id: Do we actually understand the syndrome well enough to say who all the culprits are? I know that the NOC does this random shutoff thing, and I think I remember hearing that there was a hardware bug on our side; is there also, for example, a software problem in the IMP that causes this? The reason I ask is that we (well, MIT, or DARPA, or somebody) pay lots of money for the IMP ports, and if the NOC is shutting off our service because their software can't cope, I think we can legitimately give them some grief in the formal sense. If it's just a stupid reaction on their part to a bug (hardware/software, our/DEC's/ACC's fault, I don't care), I guess we have to live with it. If this is BBN's fault beyond the NOC lossage, I think we should kick them, hard. Hell, maybe we should call our congresscritters and complain about government waste due to incompetant contractors.  Date: Sun, 29 Jan 89 18:04:44 EST From: David Chapman To: ALAN@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <528214.890129.ZVONA@AI.AI.MIT.EDU> Oh. Giving the NOC a hard time is a fine reason; I just didn't know that there was one.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 29 Jan 89 17:58:59 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 169431; Sun 29-Jan-89 17:57:23 EST Date: Sun, 29 Jan 89 17:57 EST From: Alan Bawden To: ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <528036.890128.ZVONA@AI.AI.MIT.EDU> Message-ID: <19890129225728.2.ALAN@PIGPEN.AI.MIT.EDU> Date: Sat, 28 Jan 89 22:47:32 EST From: David Chapman I've deleted ai:sys;net mail a couple times, because I don't think people need to be told again the gory details of how the NOC is losing and like that. Somone restored it each time. Is there a good reason for this? The reason is that I'm pissed at the NOC for making it even less likely that anyone besides me will bring MC up when it crashes. It makes me feel better to publicize their foolishness this way. I think you have to put up with it because I do backups, and if I get pushed too hard I may stop doing that.  Date: Sat, 28 Jan 89 22:47:32 EST From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <528036.890128.ZVONA@AI.AI.MIT.EDU> I've deleted ai:sys;net mail a couple times, because I don't think people need to be told again the gory details of how the NOC is losing and like that. Somone restored it each time. Is there a good reason for this?  Date: Tue, 17 Jan 89 18:19:51 EST From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <521426.890117.ZVONA@AI.AI.MIT.EDU> AI wasn't talking to the net at all, in or out; Finger for instance complained that all sockets were in use. I reset it with lock.  Received: from PIGPEN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 JAN 89 15:58:22 EST Date: Mon, 16 Jan 89 15:50 EST From: Alan Bawden Subject: Unibus Chaosnet board... To: ROLL@KICKI.STACKEN.KTH.SE cc: bug-its@AI.AI.MIT.EDU In-Reply-To: <12462000174.22.411.4820@KICKI.STACKEN.KTH.SE> Message-ID: <19890116205029.5.ALAN@PIGPEN.AI.MIT.EDU> Date: 12-Jan-89 18:11:30 +0100 From: Peter Lothberg There are tre banks of DIP-switches, what do they do? -------- Presumably two of them are network and host address. These two should be right next to eachother, if I recall correctly. The third must be the interrupt address. Take a look at SYSTEM;KSNET >. Since you can read the network address back from the board, you should be able to figure out what switches do what by plugging it in to some machine and playing with it.  Date: Fri, 13 Jan 89 22:19:19 EST From: Alan Bawden Subject: Don't try this at home! To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <519854.890113.ALAN@AI.AI.MIT.EDU> If you tell ITS that your terminal has 8 columns or less, then when a **MORE** break happens ITS will try to continue the "**MORE**" onto the next line by doing "!". But (you guessed it) the causes a **MORE** break! The result is a PDL overflow in Exec mode, and a crashed ITS. See AI:CRASH;CRASH MORE for an example of this.  Date: Fri, 13 Jan 89 03:00:11 EST From: Charles Frankston Subject: Re: Chaosnet through Internet. To: JNC@XX.LCS.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, JMR@KICKI.STACKEN.KTH.SE Message-ID: <519167.890113.CBF@AI.AI.MIT.EDU> We did run chaos packets through the Internet from Livermore to MIT. I think a total of about 10 packets were exchanged since we found that the fixed Chaos timeouts were ill-suited to the cross country delays and the accumulated retransmisson packets tickled bugs that caused XX's front end to crash. EAK was doing the Livermore end and I think JTW hacked XX's front end.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Jan 89 12:27:56 EST Received: from KICKI.STACKEN.KTH.SE by XX.LCS.MIT.EDU with TCP/SMTP; Thu 12 Jan 89 12:19:21-EST Address: "PoBox:36041, SE-100 71 Stockholm, SWEDEN" Organization: Stacken Computer Club Telephone: +46-8-669 9720 Date: 12-Jan-89 18:11:30 +0100 From: Peter Lothberg To: bug-its@ai.ai.mit.edu Subject: Unibus Chaosnet board... Message-ID: <12462000174.22.411.4820@KICKI.STACKEN.KTH.SE> There are tre banks of DIP-switches, what do they do? --------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Jan 89 16:17:57 EST Date: Tue 10 Jan 89 16:09:22-EST From: "J. Noel Chiappa" Subject: Re: Chaosnet through Internet. To: JMR@KICKI.STACKEN.KTH.SE, bug-its@AI.AI.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <12461385557.1.2.79320@KICKI.STACKEN.KTH.SE> Message-ID: <12461508265.16.JNC@XX.LCS.MIT.EDU> Ahhh, you don't want to know about this. At one point there was a discussion on using the IP packet protocol to carry around CHAOS streams. There was never a final, definite scheme on how to do this, although I think some kludges were in use. The rationale was that people would be able to get to a larger number of machines if you starting using IP packets, and it wouldn't be a major change. However, the interactions between 'pure' CHAOS machines and machines using CHAOS wrapped in IP can become tricky. (E.g. how does a 'pure' machine address a machine with a different high order IP address; 16 bit addresses don't map into 32 bits.) If you *really* care about this, some old stuff is online on ML:JNC;CHAOS IN and CHAOS2 *. If you want to string a line between your CHAOS net and MIT's, fine, you might want to allocate subnet numbers from the MIT space. If you're going through the Internet, use TCP/IP - it almost works. Noel -------  Received: from KICKI.STACKEN.KTH.SE (TCP 20273365334) by AI.AI.MIT.EDU 10 Jan 89 04:01:37 EST Date: 10-Jan-89 9:55:18 +0100 From: Jan Michael Rynning To: bug-its@ai.ai.mit.edu Subject: Chaosnet through Internet. Message-ID: <12461385557.1.2.79320@KICKI.STACKEN.KTH.SE> > Date: Sun, 8 Jan 89 15:17 EST > From: David A. Moon > > No. Chaosnet does not bridge through Internet. So, what's this? (From RFC 1010 (assigned numbers)): PROTOCOL NUMBERS In the Internet Protocol (IP) [36,80] there is a field, called Protocol, to identify the the next level protocol. This is an 8 bit field. Assigned Internet Protocol Numbers Decimal Keyword Protocol References ------- ------- -------- ---------- ... 16 CHAOS Chaos [NC3] --------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 9 Jan 89 08:30:08 EST Received: from KICKI.STACKEN.KTH.SE by XX.LCS.MIT.EDU with TCP/SMTP; Mon 9 Jan 89 08:22:21-EST Address: "PoBox:36041, SE-100 71 Stockholm, SWEDEN" Organization: Stacken Computer Club Telephone: +46-8-669 9720 References: Message from bug-its@AI.AI.MIT.EDU of 9-Jan-89 14:16:23 In-reply-to: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 9-Jan-89 14:23:39 +0100 From: Peter Lothberg To: bug-its@AI.AI.MIT.EDU Subject: Re: Chaos-net adresses Message-ID: <12461172265.28.2.91760@KICKI.STACKEN.KTH.SE> foo roll@kicki.stacken.kth.se Date: Sun, 8 Jan 89 15:17 EST Cc: David A. Moon To: Peter Lothberg From: bug-its@AI.AI.MIT.EDU Subject: Chaos-net adresses Message-Id: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM> > Date: 8-Jan-89 15:38:08 +0100 > From: Peter Lothberg > > 1,) How do i set up the chaos net (unibus) board adress, i has no HW doc. > >Use the pair of DIP switches. I don't think there ever was any documentation >other than the print set. Did you not get a print set? No, i did not get the print set for the Unibus board, i did get a drawing for the the Cardr board. > 2,) Do we need to coordinate the chaos-host numbers with the other chaos > based hosts @ mit, when (if) we get our KS-ITS to talk to Internet? > >No. Chaosnet does not bridge through Internet. > > If we have to cordinate, if i got this right, i need a subnet here? > (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6) My thought, was, if it hapens in the future, that we get a bridge somehow, to the MIT-Chaos, it might be clever to chose a subnet not in use. A lesson i learned from the work with the Nordical-Internet implementation was, 'do it right the first time if possible'. -peter --------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 8 Jan 89 20:40:00 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 517315; Sun 8-Jan-89 15:18:27 EST Date: Sun, 8 Jan 89 15:17 EST From: David A. Moon Subject: Chaos-net adresses To: Peter Lothberg cc: bug-its@AI.AI.MIT.EDU In-Reply-To: <12460923678.29.411.15980@KICKI.STACKEN.KTH.SE> Message-ID: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 8-Jan-89 15:38:08 +0100 From: Peter Lothberg 1,) How do i set up the chaos net (unibus) board adress, i has no HW doc. Use the pair of DIP switches. I don't think there ever was any documentation other than the print set. Did you not get a print set? 2,) Do we need to coordinate the chaos-host numbers with the other chaos based hosts @ mit, when (if) we get our KS-ITS to talk to Internet? No. Chaosnet does not bridge through Internet. If we have to cordinate, if i got this right, i need a subnet here? (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6) You need a subnet number for each chaos cable you have. People whose cables aren't connected by bridges don't have to coordinate their subnet numbers. I'd guess that you have one cable and no bridges, so you need one subnet number. May as well use 1. You may have to purge MIT chaosnet addresses out of your host tables, if you got your host tables by copying the MIT ones. Otherwise SI might think it can talk to AI via Chaosnet instead of Internet.  Received: from KICKI.STACKEN.KTH.SE (TCP 20273365334) by AI.AI.MIT.EDU 8 Jan 89 09:44:14 EST Address: "PoBox:36041, SE-100 71 Stockholm, SWEDEN" Organization: Stacken Computer Club Telephone: +46-8-669 9720 Date: 8-Jan-89 15:38:08 +0100 From: Peter Lothberg To: bug-its@ai.ai.mit.edu Subject: Chaos-net adresses Message-ID: <12460923678.29.411.15980@KICKI.STACKEN.KTH.SE> 1,) How do i set up the chaos net (unibus) board adress, i has no HW doc. 2,) Do we need to coordinate the chaos-host numbers with the other chaos based hosts @ mit, when (if) we get our KS-ITS to talk to Internet? If we have to cordinate, if i got this right, i need a subnet here? (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6) -peter --------  Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 10 Nov 88 19:27:54 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5321; Thu, 10 Nov 88 19:22:29 EST Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5320; Thu, 10 Nov 88 19:22:28 EST Received: from kth.se by KTH-BITNET-GATEWAY ; 10 Nov 88 23:39:47 GMT Received: from KICKI.STACKEN.KTH.SE by kth.se (5.57+IDA+KTH/3.0) id AA13586; Fri, 11 Nov 88 00:39:36 +0100 Address: "PoBox:36041, SE-100 71 Stockholm, SWEDEN" Organization: Stacken Computer Club Date: 11-Nov-88 0:39:51 +0100 From: Peter_Lothberg To: bug-its@ai.ai.mit.edu Subject: The container and MX Message-Id: <12445555798.20.2.175672@KICKI.STACKEN.KTH.SE> Arrived to Stockholm and we unpacked the container on wendsday. The container has, sure shaked, the cardboard paper that we put between the cabinets, has bloue spots..... But, everything was in the same position that we left it, so, hopfully it is not hurt by the transport, or the cold here. We have put the machine on several places, while we are waiting for our new machine room to be completed. My preliminary shedule is, to have it run by end of march. -peter --------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 26 Oct 88 23:45:34 EDT Date: Wed 26 Oct 88 23:42:03-EDT From: "J. Noel Chiappa" To: Moon@STONY-BROOK.SCRC.Symbolics.COM, ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <19881022002858.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12441656808.31.JNC@XX.LCS.MIT.EDU> It's actually in the back, inside the cabinet, on the CPU card, as I recall. (It might be next to the power switch, if I'm suffering brain fade.) However, it is in the back on the C/30's.... The right thing is actually to call the NOC; they keep stats on the number of random restarts to highlight problem hardware, and pushing the button a lot could get us a new box, all full of new bugs... Noel -------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 24 Oct 88 15:48:43 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 481133; Mon 24-Oct-88 15:47:09 EDT Date: Mon, 24 Oct 88 15:46 EDT From: David A. Moon Subject: MC To: David Chapman cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <470732.881024.ZVONA@AI.AI.MIT.EDU> Message-ID: <19881024194656.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 24 Oct 88 14:46:59 EDT From: David Chapman For what it's worth, I'm in favor of an immediate CPU swap. Maybe the problem is the power supply, not the boards. The errors it's getting are "impossible" in most cases, unless we are misreading the documentation. Swapping the CPU might only make things worse.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 Oct 88 15:29:27 EDT Date: Mon 24 Oct 88 15:26:16-EDT From: Rob Austein To: ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <470732.881024.ZVONA@AI.AI.MIT.EDU> Message-ID: <12441042264.12.SRA@XX.LCS.MIT.EDU> Date: Mon, 24 Oct 88 14:46:59 EDT From: David Chapman MC wasn't talking to the net for 34 hours because people kept booting it without fixing the IMP problem. I left a note on the console explaining how to win. As a result, LISTS MSGS is over 2000 blocks again. For what it's worth, I'm in favor of an immediate CPU swap. Since BBN has admitted that at least some of this is their fault (IMP software), a CPU swap wouldn't solve the urgent problem. The problem with swapping CPUs to "fix" the PAR ERR bug is that it would not solve the real problem (one of the KS CPUs being broken) but would remove the immediate cause for fixing the real problem. Sad but true. -------  Date: Mon, 24 Oct 88 14:46:59 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <470732.881024.ZVONA@AI.AI.MIT.EDU> MC wasn't talking to the net for 34 hours because people kept booting it without fixing the IMP problem. I left a note on the console explaining how to win. As a result, LISTS MSGS is over 2000 blocks again. For what it's worth, I'm in favor of an immediate CPU swap.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 21 Oct 88 20:30:04 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480334; Fri 21-Oct-88 20:29:11 EDT Date: Fri, 21 Oct 88 20:28 EDT From: David A. Moon To: David Chapman cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <469253.881021.ZVONA@AI.AI.MIT.EDU> Message-ID: <19881022002858.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 21 Oct 88 16:05:33 EDT From: David Chapman MC isn't talking to the arpanet. Powercycling doesn't help. I gather this means I need to boot the IMP. I dunno how. Can someone show me? (I can't find anyone around now.) Push the boot button on the front of the IMP (maybe it's labelled Reset). Then wait an hour.  Date: Fri, 21 Oct 88 17:20:59 EDT From: "Pandora B. Berman" To: LIAISON@AI.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <469383.881021.CENT@AI.AI.MIT.EDU> Date: Fri, 21 Oct 88 16:05:33 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU MC isn't talking to the arpanet. Powercycling doesn't help. I gather this means I need to boot the IMP. I dunno how. Can someone show me? (I can't find anyone around now.) i looked at the LH/DH lights, decided they indicated IMP wedgitude, and called the NOC, after Ty checked and found that XX (@ 0/44) was having no problems. the nice man (norm, i think he said) there put 3/44 into and out of loopback, and then once i ran NET in LOCK to impulse MC, we had arpanet again. the guy at BBN claimed that we are not the only people having this problem, that it seems to be cropping up in several places all over, and that it appears therefore to be software. i gather They Are Working On It. i gave him MAP's name as the official administrator here. he said that the next the this happens, we should try to call as soon as possible so they can try to catch it before it reaches the steady-state wedgedness, and thus perhaps learn something. the NOC is at 873-3070.  Date: Fri, 21 Oct 88 16:05:33 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <469253.881021.ZVONA@AI.AI.MIT.EDU> MC isn't talking to the arpanet. Powercycling doesn't help. I gather this means I need to boot the IMP. I dunno how. Can someone show me? (I can't find anyone around now.)  Date: Thu, 20 Oct 88 22:42:07 EDT From: "Pandora B. Berman" Subject: state of ML To: marilyn@WHEATIES.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <468866.881020.CENT@AI.AI.MIT.EDU> alan said that last week he had you generate a repair PO for ML's disk drive, which was broken. when he called DEC back on sunday to complain that they had in fact not fixed the disk, he got the impression that DEC thought that last week's PO had been closed already. as of now, DEC is -still- working on that disk, and the latest notes they left to each other do not boost my confidence, as they suggest that in trying to use MD to help fix ML's disk, they broke MD's disk as well. if at some point they actually fix these things so they are really fixed, they may want another PO for the work this week. in which case we get to generate another repair PO. alan is on vacation and will return sometime next week; if this needs to be acted upon before then, i'll do it. note that AI should not be charged for any work to fix MD, which is LCS, and it's my guess that LCS shouldn't be charged for fixing MD either, since the Men From DEC say -they- broke it.  Date: Tue, 18 Oct 88 02:18:43 EDT From: "Christopher C. Stacy" To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <465449.881018.CSTACY@AI.AI.MIT.EDU> Someone seems to have deleted the default DDT init file from AI's USERSn directories. So I put them back.  Date: Tue, 18 Oct 88 01:12:33 EDT From: "Pandora B. Berman" Subject: mc fall down go boom again To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <465405.881018.CENT@AI.AI.MIT.EDU> it crashed again, after alan had gone home. so i trucked upstairs to discover the same old bogus ?PAR ERR msg. i read the lights off the ACC box over the phone to alan, and he claims that the way the second row did not clear indicates that the problem has not been solved by swapping LH/DHs. in other words, the LH/DHs are not at fault. MC is currently up but not talking to the arpanet.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Oct 88 23:29:41 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 143539; Mon 17-Oct-88 23:28:33 EDT Date: Mon, 17 Oct 88 23:28 EDT From: Alan Bawden Subject: Vacation. To: Bug-MAIL@AI.AI.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU Message-ID: <19881018032823.2.ALAN@OTIS.AI.MIT.EDU> Due to the lossage with MC, there are a few things that I have done that you might all need to know about. Especially since I'll be out of town this from this Wednesday through next Monday. 1. I have swapped AI and MC's LH/DH-11s to see if this has any effect on the problem with the MC's IMP port. 2. I have left COMSAT on MC running in hyper-active mode. That is, I have patched all of its timeouts to very small values. This makes COMSAT eat new mail faster, so that people who haven't been able to talk to MC for days have a better chance of delivering new mail before timing out. Of course the flip side of this is that MC is growing a rather large queue of mail it hasn't been able to deliver. The COMSAT PDUMP file (COMSAT LAUNCH) has the fast timeouts, but the SBLK file (COMSAT IV) does not. So if it becomes necessary to undo what I have done, you should: [a] notice that the files on .MAIL. are all links to the corresponding files on .BULK., [b] load .BULK.;COMSAT IV into a job (J$J $L .BULK.;COMSAT IV), [c] start it at PURIFY (PURIFY$G), and [d] put the resulting PDUMP file into .BULK.;COMSAT LAUNCH (which is -not- the default you will be offered! Use delete, or type $ to change the offered default.). 3. I have changed the algorithm employed by the SMTP and Chaos MAIL servers to decide whether or not to accept new MAIL > files. The previous code tried to limit the number of MAIL files to 30. The new code looks at the .MAIL. directory and computes how full it is and refuses new MAIL > files if it is more than 75% full. If this has any bad effects, you can retract it by renaming DEVICE;CHAOS OMAIL to be DEVICE;CHAOS MAIL and renaming SYSBIN;FTPS OBIN to be SYSBIN;FTPS BIN.  Received: from ames.arc.nasa.gov (TCP 20031411003) by AI.AI.MIT.EDU 6 Oct 88 12:34:47 EDT Received: Thu, 6 Oct 88 09:23:05 PDT by ames.arc.nasa.gov (5.59/1.2) Date: Thu, 6 Oct 88 09:24:05 PST From: geoff@Fernwood.MPK.CA.US (the tty of Geoff Goodfellow) Subject: Re: License plate curiosity... Message-Id: <8810060924.2.UUL1.3#948@Fernwood.MPK.CA.US> To: Ed@ALDERAAN.SCRC.Symbolics.COM Cc: tops-20@score.stanford.edu, info-its@ai.ai.mit.edu, hic@symbolics.com, pgs@ai.ai.mit.edu, gls@think.com, vaf@score.stanford.edu In-Reply-To: Your message of Wed 5 Oct 88 17:27:28-PDTFrom: Vince Fuller i still have California JFCL. i believe JRST 4 belongs to Ken Olum (kdo@lucid.com). g  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 6 Oct 88 12:05:10 EDT Return-Path: Received: from sauron.think.com by Think.COM; Thu, 6 Oct 88 11:16:46 EDT Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 6 Oct 88 12:00:28 EDT Date: Thu, 6 Oct 88 12:01 EDT From: Barry Margolin Subject: License plate curiosity... To: Ed Schwalenberg Cc: Vince Fuller , tops-20@score.stanford.edu, info-its@ai.ai.mit.edu, geoff@fernwood.mpk.ca.us, hic@alderaan.scrc.symbolics.com, pgs@ai.ai.mit.edu, gls@Think.COM In-Reply-To: <19881006144203.6.ED@BLACK-BIRD.SCRC.Symbolics.COM> Message-Id: <19881006160115.7.BARMAR@OCCAM.THINK.COM> A couple of weeks ago I was walking through the Lotus parking lot by Cambridge Gas & Electric and saw the license plate CAR-CDR. Anyone know whose this is? barmar  Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 20024224555) by AI.AI.MIT.EDU 6 Oct 88 10:44:15 EDT Received: from BLACK-BIRD.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227033; Thu 6-Oct-88 10:42:12 EDT Date: Thu, 6 Oct 88 10:42 EDT From: Ed Schwalenberg Subject: License plate curiosity... To: Vince Fuller cc: tops-20@Score.Stanford.EDU, info-its@AI.AI.MIT.EDU, geoff@fernwood.mpk.ca.us, hic@ALDERAAN.SCRC.Symbolics.COM, pgs@AI.AI.MIT.EDU, gls@think.com In-Reply-To: <12436116360.19.VAF@Score.Stanford.EDU> Message-ID: <19881006144203.6.ED@BLACK-BIRD.SCRC.Symbolics.COM> Date: Wed 5 Oct 88 17:27:28-PDT From: Vince Fuller The other day I saw a California licence plate that read "JRST 4" (I guess you can't get commas on licence plates...). Out of curiosity, who is the owner of this plate? --Vince ------- Hmm. I thought this was Geoff Goodfellow's, but SAIL:AIWORD.RF[UP,DOC] tells me he has JFCL. HIC got Massachusetts HLRZ (the PDP-10 instruction that implements the "car" operation of Lisp); I believe this vehicle and plate is still around in the possession of PGS. I had FOOBAR in Nevada and later in Massachusetts; I still have the physical plates from Nevada, though the vehicle which wore both sets is long since deceased. There used to be a rather extensive discussion of this stuff in the jargon file(s), but it seems to have evaporated, except for the single note about JFCL.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 5 Oct 88 21:09:41 EDT Return-Path: Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 5 Oct 88 20:36:04-EDT Date: Wed 5 Oct 88 17:27:28-PDT From: Vince Fuller Subject: License plate curiosity... To: tops-20@Score.Stanford.EDU Office: Pine Hall 167 Phone: 415-723-6860 Message-ID: <12436116360.19.VAF@Score.Stanford.EDU> ReSent-Date: Wed 5 Oct 88 21:06:17-EDT ReSent-From: Rob Austein ReSent-To: info-its@AI.AI.MIT.EDU ReSent-Message-ID: <12436123427.45.SRA@XX.LCS.MIT.EDU> The other day I saw a California licence plate that read "JRST 4" (I guess you can't get commas on licence plates...). Out of curiosity, who is the owner of this plate? --Vince -------  Date: Wed, 5 Oct 88 14:23:26 EDT From: Rob Austein Subject: TCP/IP ior IMP weirdness To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <457481.881005.SRA@AI.AI.MIT.EDU> I got a call from BBN asking me to check out MC because they said it had first crashed then started spitting garbage onto its IMP (sic). The call was to tell me that until they hear further from us they will leave MC's port in loopback mode to keep from trashing the rest of the net. I found MC crashed with several messages from last night about the IMP crashing and the IMP interface being reset followed by: IMP: Interface reset PK: Node already on list and a PI 7 BUGHALT. There were no times on the last two message. Dump in CRASH; TCP.PK BUGHLT. Reloaded ok except that now it can't talk to the net, presumably because BBN still has the IMP in loopback. I'm going to try to get them to undo that now....  Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 3 Oct 88 15:46:16 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0401; Mon, 03 Oct 88 15:43:23 EDT Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0400; Mon, 03 Oct 88 15:33:45 EDT Received: from kth.se by KTH-BITNET-GATEWAY ; 03 Oct 88 19:11:10 GMT Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0) id AA18632; Mon, 3 Oct 88 20:10:59 +0100 Date: Mon, 3 Oct 88 20:12:22 +0100 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg) To: bug-its@ai.ai.mit.edu Subject: subnet 6 Message-Id: <340A6Z@KICKI.STACKEN.KTH.SE> It might be so that, I did something wrong when we took away MX, i unplugged the transceivers, both where the KL was, and next to the chaos-11 3mbit ethernet gateway was. I don't knew if anyone has checked it out after that.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 3 Oct 88 14:27:24 EDT Date: Mon 3 Oct 88 14:22:46-EDT From: Rob Austein Subject: Re: Chaosnet, hardware To: JTW@XX.LCS.MIT.EDU cc: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU, bug-its@AI.AI.MIT.EDU In-Reply-To: Message-ID: <12435525680.49.SRA@XX.LCS.MIT.EDU> If I remember correctly, Moon's original CHAOSNET spec paper did specify a length limit derived from transmission speed and the retransmission algorithm. I haven't read the paper in a long time, so I can't quote chapter and verse. -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 3 Oct 88 14:06:55 EDT Date: Mon 3 Oct 88 14:02:33-EDT From: Rob Austein Subject: Agre's dropped tty problems To: agre@wheaties.ai.mit.edu cc: bug-its@AI.AI.MIT.EDU In-Reply-To: <8810010048.AA15907@wheat-chex.ai.mit.edu> Message-ID: <12435522000.49.SRA@XX.LCS.MIT.EDU> Or maybe it's just that the path from anywhere to subnet 6 is unreliable these days and sometimes the routing transients cause your packets to fall on the floor so that either ITS or your Lispm thinks the connection is dead. -------  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 3 Oct 88 00:52:52 EDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Sun 2 Oct 88 23:50:32-CDT Date: Sun, 2 Oct 88 23:50 CDT From: David Vinayak Wallace Subject: Chaosnet, hardware To: JTW@XX.LCS.MIT.EDU cc: Peter Lothberg , bug-its@AI.AI.MIT.EDU In-Reply-To: Message-ID: <881002235013.7.GUMBY@BRAHMA.ACA.MCC.COM> Date: Sun, 2 Oct 1988 18:33 EDT From: JTW@XX.LCS.MIT.EDU Presumably the limit is due to propagation delays screwing up the collision detection, rather than analog attenuation issues. This being the case, it should be pretty easy to calculate once you figure out exactly what a collision is. As a practical matter our subnet 1 was well over 500m at its peak, I think. The Chaosnet Memo said that the limit was around 1KM for the reason you said.  Date: Sun, 2 Oct 88 21:58:54 EDT From: "Christopher C. Stacy" Subject: dropping To: BUG-ITS@AI.AI.MIT.EDU cc: AGRE@AI.AI.MIT.EDU Message-ID: <455274.881002.CSTACY@AI.AI.MIT.EDU> The 7814 modem randomly dropped me a second ago; when I dialed it back up again, I was on the same session as before (I wasn't logged out.) There seemed to be alot of pinegoi&6se on the line too.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 2 Oct 88 18:35:14 EDT Date: Sun, 2 Oct 1988 18:33 EDT Message-ID: From: JTW@XX.LCS.MIT.EDU To: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg) Cc: bug-its@AI.AI.MIT.EDU Subject: Chaosnet, hardware In-reply-to: Msg of Sun 2 Oct 88 17:14:21 +0100 from ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg) From: ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg) Re: Chaosnet, hardware What is the electrical characteristics? 75 Ohm coax. Traditionally, solid-sheath CATV cable was used for its low-loss and shielding properties, but more recently most short runs were done with boring old RG-59U, which seems to work fine. Termination is just a 75-ohm non-inductive resistor on each end. I've never seen any commentary on theoretical length limits, but perhaps someone who was around when it was designed will have more to say. Presumably the limit is due to propagation delays screwing up the collision detection, rather than analog attenuation issues. This being the case, it should be pretty easy to calculate once you figure out exactly what a collision is. As a practical matter our subnet 1 was well over 500m at its peak, I think.  Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 2 Oct 88 12:20:18 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2539; Sun, 02 Oct 88 12:17:50 EDT Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2538; Sun, 02 Oct 88 12:17:49 EDT Received: from kth.se by KTH-BITNET-GATEWAY ; 02 Oct 88 16:14:10 GMT Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0) id AA04756; Sun, 2 Oct 88 17:13:56 +0100 Date: Sun, 2 Oct 88 17:14:21 +0100 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg) To: bug-its@ai.ai.mit.edu Subject: Chaosnet, hardware Message-Id: <5401T5@KICKI.STACKEN.KTH.SE> What is the electrical characteristics? Cable impendance? Maximal cable lenght? Terminators?  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 30 Sep 88 23:08:46 EDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Fri 30 Sep 88 21:58:15-CDT Date: Fri, 30 Sep 88 21:58 CDT From: David Vinayak Wallace Subject: foo To: Alan Bawden cc: agre@WHEATIES.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU In-Reply-To: <19881001013734.1.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <880930215803.1.GUMBY@BRAHMA.ACA.MCC.COM> Date: Fri, 30 Sep 88 21:37 EDT From: Alan Bawden (It is a weird phenomenon that people always blame the machine at the farthest end of a network connection first. I've seen people go and boot AI because their terminal concentrator crashed.) Yea, I once booted XX because the IRS lost my tax rebate  Received: from wheat-chex.ai.mit.edu (TCP 20015023057) by AI.AI.MIT.EDU 30 Sep 88 22:05:22 EDT Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 21:56:44 EDT Date: Fri, 30 Sep 88 21:56:44 EDT From: agre@wheaties.ai.mit.edu (Philip E. Agre) Message-Id: <8810010156.AA16581@wheat-chex.ai.mit.edu> To: Alan@ai.ai.mit.edu Subject: Re: foo Cc: bug-its@ai.ai.mit.edu That's probably because networks are supposed to be transparent. Even when they break it doesn't immediately come to mind that they even exist. But then people don't usually clean off the world when their glasses get dirty.  Received: from PIGPEN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 SEP 88 21:46:45 EDT Date: Fri, 30 Sep 88 21:37 EDT From: Alan Bawden Subject: foo To: agre@WHEATIES.AI.MIT.EDU cc: bug-its@AI.AI.MIT.EDU, Gumby@mcc.com In-Reply-To: <8810010048.AA15907@wheat-chex.ai.mit.edu> Message-ID: <19881001013734.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Fri, 30 Sep 88 20:48:48 EDT From: agre@wheaties.ai.mit.edu (Philip E. Agre) I talked with Alan about the problem a little and he thinks that AI is losing all its Chaos connections now and again. That's not quite what I said. I think that it is the Chaosnet itself that is the problem (probably subnet 6 being jammed). The problem is not AI or ITS. (It is a weird phenomenon that people always blame the machine at the farthest end of a network connection first. I've seen people go and boot AI because their terminal concentrator crashed.)  Received: from wheat-chex.ai.mit.edu (TCP 20015023057) by AI.AI.MIT.EDU 30 Sep 88 20:57:13 EDT Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:48:48 EDT Date: Fri, 30 Sep 88 20:48:48 EDT From: agre@wheaties.ai.mit.edu (Philip E. Agre) Message-Id: <8810010048.AA15907@wheat-chex.ai.mit.edu> To: bug-its@ai.ai.mit.edu Subject: foo From agre Fri Sep 30 20:47:14 1988 Return-Path: Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:46:33 EDT Date: Fri, 30 Sep 88 20:46:33 EDT From: MAILER-DAEMON@wheaties.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8810010046.AB15897@wheat-chex.ai.mit.edu> To: agre Status: R ----- Transcript of session follows ----- 550 bug-its... User unknown ----- Unsent message follows ----- Return-Path: Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:46:33 EDT Date: Fri, 30 Sep 88 20:46:33 EDT From: agre@wheaties.ai.mit.edu (Philip E. Agre) Message-Id: <8810010046.AA15894@wheat-chex.ai.mit.edu> To: Gumby@mcc.com Subject: Re: connectionist problems Cc: bug-its 1. I am connecting through a telnet window on my lispm. 2. No, nothing about DDT BUG BLAH BLAH 3. I've never had my connection dropped while running any program but DDT. 4. Ditto. 5. Yes, my memory is quite consistent with the policy (which Alan told me about) of flushing over-an-hour-old detached jobs. I talked with Alan about the problem a little and he thinks that AI is losing all its Chaos connections now and again.  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 30 Sep 88 19:12:31 EDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Fri 30 Sep 88 18:01:49-CDT Date: Fri, 30 Sep 88 18:01 CDT From: David Vinayak Wallace Subject: connectionist problems To: Philip E. Agre cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <453833.880930.AGRE@AI.AI.MIT.EDU> Message-ID: <880930180110.0.GUMBY@BRAHMA.ACA.MCC.COM> Date: Fri, 30 Sep 88 15:39:01 EDT From: "Philip E. Agre" Hi -- AI randomly drops my terminal connection a couple dozen times a day. In doing so it sometimes detaches me and sometimes flushes me altogether. Am I doing something to bring this on myself? If not it would be great if it stopped happening. o - Are you connecting from a terminal concentrator? If not, how? o - When you reconnect, do you get some message from ITS like "DDT BUG BLAH BLAH?" o - When you reconnect are you talking to DDT or to the program you were running when the connexion was dropped? o - Does this only happen when you're running some particular program? o - When "it sometimes detaches me and sometimes flushes me altogether" does it appear that you're logged out only if you wait a while? ITS's default behaviour is to keep jobs around if the connection is accidentally dropped, then GC them after a while if you don't reconnect. "We need BITS, nothing but BITS" -- Chuck E. Dickens.  Date: Fri, 30 Sep 88 15:39:01 EDT From: "Philip E. Agre" To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <453833.880930.AGRE@AI.AI.MIT.EDU> Hi -- AI randomly drops my terminal connection a couple dozen times a day. In doing so it sometimes detaches me and sometimes flushes me altogether. Am I doing something to bring this on myself? If not it would be great if it stopped happening.  Date: Fri, 16 Sep 88 00:16:04 EDT From: Peter Lothberg Subject: The "crack team", is dissasembling MX, for it's trip to Sweden To: INFO-ITS@AI.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU Message-ID: <444460.880916.ROLL@AI.AI.MIT.EDU> The crack team has begun to work; A lot of the documentation for MX (KL-10) must be spread out, i can't find it around the machine. So all of you that has bits and pices, bring it to the 9:th floor before sunday, please. (As the system will not fill the container more than 40% or so, we vold like donations of other stuff, like Lisp-machines, AAA terminals, a IMP, Conection machines, retired 2060's etc, (I'm not joking...)) -Peter  Date: Sun, 11 Sep 88 23:57:48 EDT From: Devon Sean McCullough Subject: supdup To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <441324.880911.DEVON@AI.AI.MIT.EDU> Date: Sun, 11 Sep 88 09:39:59 EDT From: David C. Plummer To: DEVON at AI.AI.MIT.EDU Re: supdup Date: Sun, 4 Sep 88 12:41:31 EDT From: Devon Sean McCullough Subject: supdup To: DCP@AI.AI.MIT.EDU Message-ID: <437397.880904.DEVON@AI.AI.MIT.EDU> Many supdup servers around MIT emit %TDBS, which is not in any RFC I've ever seen, and breaks some user end supdups, such as ITS CRTSTY. Do you know if anyone has defined a new improved supdup that does allow %TDBS, and perhaps a few other useful things as well? I've been away from this kind of stuff for a LONG time. I'd suggest asking bug-ITS.  Date: Fri, 9 Sep 88 22:56:21 EDT From: "Pandora B. Berman" Subject: return of MD To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <440558.880909.CENT@AI.AI.MIT.EDU> i plugged MD back into the *MSG and INQUPD routines.  Date: Fri, 9 Sep 88 17:19:49 EDT From: "Pandora B. Berman" Subject: The end of the world as we used to know it To: BRAITHWAITE@TOPS20.DEC.COM cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <440394.880909.CENT@AI.AI.MIT.EDU> Date: 9 Sep 1988 1033-EDT From: BRAITHWAITE@TOPS20.DEC.COM To: Rob Austein Subject: Re: [Pandora B. Berman: The end of the world as we used to know it] ReSent-Date: Fri 9 Sep 88 10:40:40-EDT ReSent-From: Rob Austein ReSent-To: CENT@XX.LCS.MIT.EDU for our records --- what is MX's serial number ? -------- model PDP-1080 (or KL-10A), serial #1038  Date: Thu, 8 Sep 88 21:39:25 EDT From: "Pandora B. Berman" Subject: The end of the world as we used to know it To: (*MSG *ITS)@AI.AI.MIT.EDU, ARPANET-BBOARDS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU Message-ID: <439827.880908.CENT@AI.AI.MIT.EDU> "The time has come," said LCS, "MX at last must go. Its day has gone. We need that space Most urgently." And so Before we crate it, let us give A final cheerio. Once there was a KL-10 called MIT-MC which belonged to the Macsyma Consortium. It provided Macsyma, the symbolic algebra system, to researchers all over the world, and mail gatewaying and mailing list support to a large fraction of the Arpanet. Things continued in this fashion from 1975 to 1983. When the Macsyma Consortium dissolved in 1983, MC turned to providing cycles for MIT's Laboratory for Computer Science, and continued supporting much of the Arpanet's mail service. But the machine itself was growing old and cranky. In 1986, the mail services were moved to a smaller, more maintainable machine (a KS-10), and the name "MC" was moved with them. But the KL-10 continued to run under the new name "MX". Now the end has come. MX was down cold for several months, and has only been revived recently to copy some old 7-track tapes. LCS can't keep MX any longer -- it needs the space for other purposes. So the KL is being sent to the Home for Aged But Beloved PDP-10s; a crack team of hardware hackers will arrive next week to dismantle it and take it back with them to Sweden. In celebration of this momentous event, we are holding a small farewell gathering: Friday, 16 September 1988 16:00 NE43-8th floor playroom (545 Technology Square, Cambridge, MA) Reservations are strenuously requested (though not strictly necessary) -- we need a head count so we can figure out how many trays of institutional brownies to order. Send yours to: CENT@AI.AI.MIT.EDU Offers of refreshement are also very welcome -- do you think we have any budget for this kind of thing? Send all such offers also to CENT as above.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 6 Sep 88 21:16:38 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455252; Tue 6-Sep-88 21:12:46 EDT Date: Tue, 6 Sep 88 21:12 EDT From: David A. Moon Subject: mc par errs To: Pandora B. Berman cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <437950.880906.CENT@AI.AI.MIT.EDU> Message-ID: <19880907011222.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 6 Sep 88 06:50:56 EDT From: "Pandora B. Berman" the sysconsole died mysteriously this evening. it was in the middle of printing a msg to my DUMP about loading a tape and then saying ok, when all of a sudden it said ?rivPARITY and the console was talking to KLDCP. the easy way out was to reattach that hactrn to the vt52, so i took it. but when that tape was done and i tried to boot the system to regain access to the sysconsole, it died twice during the reboot process, at different places, each time with the blank but ominous msg: PARITY. the mem bays didn't indicate par errs, but i tried resetting them anyway. each time, after resetting bay D a couple times, its par err light would come on. after resetting more, the light would disappear, sometimes return, and then go away again. it did eventually cooperate and let the machine come up, but this was very odd.. These sound like parity errors in the front-end pdp-11's memory [I hope someone isn't going to tell me that that pdp-11 doesn't have parity on its memory and I've just made a fool of myself.]  Date: Tue, 6 Sep 88 06:50:56 EDT From: "Pandora B. Berman" Subject: mc par errs To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <437950.880906.CENT@AI.AI.MIT.EDU> the sysconsole died mysteriously this evening. it was in the middle of printing a msg to my DUMP about loading a tape and then saying ok, when all of a sudden it said ?rivPARITY and the console was talking to KLDCP. the easy way out was to reattach that hactrn to the vt52, so i took it. but when that tape was done and i tried to boot the system to regain access to the sysconsole, it died twice during the reboot process, at different places, each time with the blank but ominous msg: PARITY. the mem bays didn't indicate par errs, but i tried resetting them anyway. each time, after resetting bay D a couple times, its par err light would come on. after resetting more, the light would disappear, sometimes return, and then go away again. it did eventually cooperate and let the machine come up, but this was very odd.  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 22 Aug 88 13:32:30 EDT Return-Path: Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Mon, 22 Aug 88 13:30:49 EDT Received: by joplin.think.com; Mon, 22 Aug 88 13:30:32 EDT Date: Mon, 22 Aug 88 13:30:32 EDT From: gls@Think.COM Message-Id: <8808221730.AA03248@joplin.think.com> To: ALAN@ai.ai.mit.edu Cc: BUG-ITS@ai.ai.mit.edu In-Reply-To: Alan Bawden's message of Sun, 14 Aug 88 22:15:58 EDT <427454.880814.ALAN@AI.AI.MIT.EDU> Date: Sun, 14 Aug 88 22:15:58 EDT From: Alan Bawden AI is running an ITS patched so that .HANG with a non-zero AC is an illegal UUO. System hackers should be on the lookout for any programs that appear to be broken by this. The idea is to learn if anybody uses the AC field in .HANG for any private purposes before I give it a meaning. I propose to make .HANG with a non-zero AC behave like the disjunction of .HANG and .SLEEP, so that you can wait for a location to change -or- for a timeout to occur. So movei 10,5*30. skipl lock .hang 10, ; (sic) jumpe 10,timout ; C(AC) = 0 if and only if timer expired. ; If not, C(AC) is negative of time to wait ; for (just like .SLEEP). will wait for 5 seconds for C(LOCK) to be negative, and will then time out. Gee, why didn't we do this ten years ago??? --Guy  Date: Sun, 14 Aug 88 22:15:58 EDT From: Alan Bawden To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <427454.880814.ALAN@AI.AI.MIT.EDU> AI is running an ITS patched so that .HANG with a non-zero AC is an illegal UUO. System hackers should be on the lookout for any programs that appear to be broken by this. The idea is to learn if anybody uses the AC field in .HANG for any private purposes before I give it a meaning. I propose to make .HANG with a non-zero AC behave like the disjunction of .HANG and .SLEEP, so that you can wait for a location to change -or- for a timeout to occur. So movei 10,5*30. skipl lock .hang 10, ; (sic) jumpe 10,timout ; C(AC) = 0 if and only if timer expired. ; If not, C(AC) is negative of time to wait ; for (just like .SLEEP). will wait for 5 seconds for C(LOCK) to be negative, and will then time out.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Aug 88 18:00:16 EDT Date: Fri 12 Aug 88 17:47:25-EDT From: Rob Austein Subject: Re: When the KL is shut down, and taken apart. To: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU cc: bug-its@AI.AI.MIT.EDU, tjg@XX.LCS.MIT.EDU, dempster@TOPS20.DEC.COM In-Reply-To: <7J14CB@KICKI.STACKEN.KTH.SE> Message-ID: <12421931449.38.SRA@XX.LCS.MIT.EDU> Date: Fri, 12 Aug 88 12:41:06 +0200 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg) When MX finally is going to be turned off and brought out from the 9:th floor to Sweden, where it hopfully will become alive again. I thought that it might be a god idea to have a 'burial cermony', or a small party. Or..?? Yeah, let's throw a wake. Even though we plan for the machine to come back to life in Sweden, it'll be the end of an era here, and god knows the machine deserves a wake after all we've put it through. (I want to have pictures of most of the people that has been involved in the ITS development, so we can have a 'history book' along with the machine, a this might be the right time to shoot them.) Which are you shooting, the pictures or the people? -------  Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 12 Aug 88 08:13:35 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3058; Fri, 12 Aug 88 08:07:52 EDT Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2956; Fri, 12 Aug 88 08:07:36 EDT Received: from kth.se by KTH-BITNET-GATEWAY ; 12 Aug 88 10:40:14 GMT Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0) id AA20391; Fri, 12 Aug 88 12:40:06 +0200 Date: Fri, 12 Aug 88 12:41:06 +0200 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg) To: bug-its@ai.ai.mit.edu, tjg@xx.lcs.mit.edu, dempster@tops20.dec.com Subject: When the KL is shut down, and taken apart. Message-Id: <7J14CB@KICKI.STACKEN.KTH.SE> When MX finally is going to be turned off and brought out from the 9:th floor to Sweden, where it hopfully will become alive again. I thought that it might be a god idea to have a 'burial cermony', or a small party. Or..?? (I want to have pictures of most of the people that has been involved in the ITS development, so we can have a 'history book' along with the machine, a this might be the right time to shoot them.) Peter  Date: Wed, 10 Aug 88 02:03:22 EDT From: "Pandora B. Berman" Subject: KL hardware bug of the week club To: TY@AI.AI.MIT.EDU, TJG@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <425456.880810.CENT@AI.AI.MIT.EDU> two weeks ago, the KL HARDWARE BUG OF THE WEEK CLUB brought you the repeated crash of the console 11. we followed up with several days of incessant non-fatal parity errors which invariably led to fatal ones or ucode hangs, and topped it off with an admixture of crashing 11 again. after a day or two to let you catch your breath, we now present: DEATH OF THE CAPSTAN MOTOR the symptoms you will encounter include: tape not loading because the take-up reel won't spin to wind it and take-up reel ceasing to spin, for no apparent reason, in the middle of a copy operation, leading to tape piling up in the vacuum columns, the drive taking itself offline, and the copy stopping dead in its tracks because DUMP can no longer talk to the drive This is serious; the MX tape drive is becoming unusable. I can deal with the machine crashing; i can't fix that motor. This problem just started occurring this evening and it seems to be getting rapidly worse; it's now sufficiently bad that i can't get through copying a single old tape successfully. This must be fixed (competently) for me to do any more tape copying. Call in DEC if you must, but get it done.  Date: Mon, 8 Aug 88 05:10:44 EDT From: "Pandora B. Berman" Subject: ai console broken To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <424212.880808.CENT@AI.AI.MIT.EDU> ai's console makes obnoxious noises and lights its paper-out indicator whenever it tries to type more than 18 chars on a line.  Date: Sat, 6 Aug 88 05:26:22 EDT From: "Pandora B. Berman" Subject: ominous new turn To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <423574.880806.CENT@AI.AI.MIT.EDU> MX has been getting parity errors right and left whenever i copy tapes. then the system console went west again (the 11 crashed), so i had to patch the sys job and move my dump job to the vt52. when i decided to punt the dump, i tried to boot the system to restore function to the console. this went OK until i tried to load MTPITS. then everything stopped. the state is characterized more by what it is not: MX does not respond to the disk boot button; the disk is not unsafe; the fault light is not on; the breakers are not tripped; the par err lights are not on. normally my next trick would be to power cycle the machine, but in its current fragile state, i don't want to do that without a real hacker around to help pick up the pieces. someone please check it out.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 29 Jul 88 11:24:17 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440141; Fri 29-Jul-88 11:22:38 EDT Date: Fri, 29 Jul 88 11:22 EDT From: David A. Moon Subject: MX falls over, tapes flutter To: Pandora B. Berman cc: BUG-ITS@AI.AI.MIT.EDU, BUG-MAGDMP@AI.AI.MIT.EDU, TJG@AI.AI.MIT.EDU In-Reply-To: <419832.880728.CENT@AI.AI.MIT.EDU> Message-ID: <19880729152207.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 28 Jul 88 23:48:02 EDT From: "Pandora B. Berman" .... a possibly related problem: the second time this happened, i was running into a tape flap error. what happens -- apparently reproducibly with AI tape 1088 -- is that while reading the tape, it hits some region about 3/4 of the way in that it doesn't like. the vacuum columns start to flutter. the tape continues feeding into them, slowly, until it apparently reaches a max enforced by the hardware. then the tape in the columns just flutters, not very far up or down, but a lot; the tape on the input spindle shakes in concert with them, but i couldn't tell whether the takeup reel was moving at all. the scary thing is that this aberrant behaviour produces no err msgs, so i can't tell what to do. This behavior is what the drive looks like when there is a read error and the software keeps retrying the read. The tape is actually going forwards and backwards about 9 inches very quickly. I'm surprised it doesn't eventually give up and report a hard read error. Maybe some bug. You might end up not being to copy that tape.  Date: Thu, 28 Jul 88 23:48:02 EDT From: "Pandora B. Berman" Subject: MX falls over, tapes flutter To: BUG-ITS@AI.AI.MIT.EDU, BUG-MAGDMP@AI.AI.MIT.EDU cc: TJG@AI.AI.MIT.EDU Message-ID: <419832.880728.CENT@AI.AI.MIT.EDU> tonight MX got 2 errors of the form UUO while in AC BLK 0 BUGHALT.... within about 2 hours. alan looked at the first one and said "but it can't do that!" and explained that that purported to convey that the SYS job was running with accumulator block 0 selected, which i gather is a bad thing. when the second one occured he was on his way out the door, and suggested that if it keeps getting UUOs like this, maybe the processor is actually broken and needs to by fixed by (gulp) DEC. i have not touched it; someone competent please investigate. a possibly related problem: the second time this happened, i was running into a tape flap error. what happens -- apparently reproducibly with AI tape 1088 -- is that while reading the tape, it hits some region about 3/4 of the way in that it doesn't like. the vacuum columns start to flutter. the tape continues feeding into them, slowly, until it apparently reaches a max enforced by the hardware. then the tape in the columns just flutters, not very far up or down, but a lot; the tape on the input spindle shakes in concert with them, but i couldn't tell whether the takeup reel was moving at all. the scary thing is that this aberrant behaviour produces no err msgs, so i can't tell what to do. NB: over the past several days the front-end 11 has crashed twice, causing the sysconsole to go west. the first time, this weekend, i used a bigger hammer by rebooting the whole machine. when it happened again earlier this evening, alan tried to apply sweet reason to it, but it didn't work, so he had to boot MX. but that wasn't what caused the lack of err msgs about the tape flutter, because the sysconsole was entirely capable of printing the UUO err msg. see the system log. no film at 11.  Date: Tue, 26 Jul 88 02:16:06 EDT From: "Pandora B. Berman" Subject: poor old kl hardware sux rocks To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <418290.880726.CENT@AI.AI.MIT.EDU> it's been crashing on me every 10-15 minutes for the past 2 hours. probably i have been forcing it to over-exertion by trying to read a remote tape -and- (via supdup) to catch up with my old mail at the same time. the remote tape is a copied KA full, which i am trying to list to a file; i suppose i'll just have to do that elsewhere while using the KL to send bits out. i don't mind the constant too many par err problems -- at least, i have been managing to make progress despite them. but now unit 0 has its UNSAFE light on. i don't want to deal with that at this hour. someone else please take a look at it. thanks.  Date: Sat, 23 Jul 88 02:17:38 EDT From: "Pandora B. Berman" Subject: patched MX system To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <417298.880723.CENT@AI.AI.MIT.EDU> thanks to moon, MX is running MTPITS, a version of NITS patched to be especially nice to tape software. it should continue running MTPITS until the tape copying project is done.  Date: Sat, 2 Jul 88 14:04:15 EDT From: Devon Sean McCullough To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <406657.880702.DEVON@AI.AI.MIT.EDU> I found I had a detached tree from yesterday (phone lines here are ATROCIOUS) and it had an emacs in it...so I logged in and did alt-G at the emacs and I got --Undefined Symbols-- which to me says there's been bitrot.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jun 88 22:26:47 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Jun 88 22:13:53 EDT Date: Wed 22 Jun 88 22:13:36-EDT From: Rob Austein To: ZVONA@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU In-Reply-To: <440792.880622.ZVONA@MC.LCS.MIT.EDU> Message-ID: <12408610560.16.SRA@XX.LCS.MIT.EDU> Date: Wed, 22 Jun 88 21:28:11 EDT From: David Chapman Why can't I link to a non-disk device? The AI: device, in particular? Presumably because the UFD definition for links allows SNAME, FN1, & FN2 but doesn't allow device names. See AI:SYSTEM;FSDEFS. Also presumably because by the time you get to deciphering links the filesystem code just knows that it must be dealing with a disk device. Neither of which is a reason why you -shouldn't- be able to link to non-disk devices, just why you can't. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jun 88 21:28:36 EDT Date: Wed, 22 Jun 88 21:28:11 EDT From: David Chapman To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <440792.880622.ZVONA@MC.LCS.MIT.EDU> This is a stupid question, but maybe someone won't mind educating me: Why can't I link to a non-disk device? The AI: device, in particular?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jun 88 22:01:51 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Jun 88 21:58:46 EDT Date: Thu 16 Jun 88 21:57:50-EDT From: Rob Austein Subject: Re: well, I hope there's SOME explanation for this To: PGS@XX.LCS.MIT.EDU cc: bug-twenex@XX.LCS.MIT.EDU, bug-its@MC.LCS.MIT.EDU, bug-finger@MC.LCS.MIT.EDU In-Reply-To: Message-ID: <12407034826.27.SRA@XX.LCS.MIT.EDU> Date: Thu, 16 Jun 1988 19:39 EDT From: PGS@XX.LCS.MIT.EDU This is not a joke. This happens consistently on XX. [PHOTO: Recording initiated Thu 16-Jun-88 7:33PM] MIT TOPS-20 Command Processor 5(312162)-2 No mail. @whois yomama yomama@mc [MC.LCS.MIT.EDU] -User- --Full name-- Jobnam Idle TTY -Console location- ALAN ` Alan Bawden P 1:18 T05 723 x8843 Alan, HQM (Spaceman) [AI] Hacking too many things for my own good Birthday January 23; NE43-723; 3-8843; Home Phone 492-7274 29 Reed St., Cambridge, MA 02140 @pop [PHOTO: Recording terminated Thu 16-Jun-88 7:34PM] The bug is in the Twenex finger program. The only explaination I can think of is that the guy who wrote the parsing code in that program had his brain held hostage on planet Quorgon while he was writing that part of it. The amazing thing is that the program runs at all. Even more amazing is that it ever works in server mode, considering that it gets its JCL by each FINGER stuffing its RFC packet into the CHARFC job's shared RSCAN% buffer. I suppose I might try to fix this some day, but since it only catches a subset of completely bogus names I don't intend to worry about it much. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jun 88 19:43:00 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Jun 88 19:40:56 EDT Date: Thu, 16 Jun 1988 19:39 EDT Message-ID: From: PGS@XX.LCS.MIT.EDU To: bug-twenex@XX.LCS.MIT.EDU, bug-its@MC.LCS.MIT.EDU, bug-finger@MC.LCS.MIT.EDU Subject: well, I hope there's SOME explanation for this This is not a joke. This happens consistently on XX. [PHOTO: Recording initiated Thu 16-Jun-88 7:33PM] MIT TOPS-20 Command Processor 5(312162)-2 No mail. @whois yomama yomama@mc [MC.LCS.MIT.EDU] -User- --Full name-- Jobnam Idle TTY -Console location- ALAN ` Alan Bawden P 1:18 T05 723 x8843 Alan, HQM (Spaceman) [AI] Hacking too many things for my own good Birthday January 23; NE43-723; 3-8843; Home Phone 492-7274 29 Reed St., Cambridge, MA 02140 @pop [PHOTO: Recording terminated Thu 16-Jun-88 7:34PM] But, come to think of it: Alan, can I go to the dance on Saturday night? Oh, come on, pleeeeeze?!  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 15 Jun 88 19:18:55 EDT Received: from SWAN.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 301145; Wed 15-Jun-88 19:15:48 EDT Date: Wed, 15 Jun 88 19:15 EDT From: David C. Plummer Subject: Re: This is important! To: Alan Bawden , kao@VERMITHRAX.SCH.Symbolics.COM, SRA@XX.LCS.MIT.EDU, maeda@MCC.COM, DCP@QUABBIN.SCRC.Symbolics.COM, cjl@WHEATIES.AI.MIT.EDU, Gumby@MCC.COM cc: Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <19880615210705.7.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <19880615231501.4.DCP@SWAN.SCRC.Symbolics.COM> Date: Wed, 15 Jun 88 17:07 EDT From: Alan Bawden ... Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer ... BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) I'd be interested in understanding why. Is it because the thing that times out connections might not actually shut down the connection, but would cause the 3600 to forget about it, this accumulating even more useless connections? Anytime the control connection dies (either because the network spazzed, or because the scavenger closes it), the next file operation will find this control connection (ConnA), notice it is dead, reset it (here's the bug: which forgets about it), reestablish connection, and then use ConnA for the duration of this single file operation. The next file operation will not even find ConnA and must therefore cons up a new one (ConnB). ConnB will be found for a while. When it dies, it will still be found (once), get forgotten about and used, and then ConnC must be consed up. So... The more often the file connection scavenger runs, the faster the connections die, so the higher the rate of finding/forgetting and thus leaving open but connections around. ... Which finally brings me to the real point of the message. Unfortunately, despite Symbolic's best efforts (for which I thank them), we are still left in a situation where we have to get zapped at least once by a site before we can send them the fix. We can spread the fix around ourselves to the most likely places, but we can still lose now and then. Therefore, unless anybody objects or has a better plan, I plan to install a tasteless little demon that checks for FTP and GATEWAY servers that are clearly idle, and guns them down. That should be an effective defense against any future offenders. (I'll have it keep a log of what it does, so that we can still spot the losers and send them the patch.) Sounds fine to me. I'd use 20 minutes as idle, which I think gives the typical 15 minute connection scavenger a chance first. Also, be careful what you call "idle." LispMs will issue reset-provoking-probes at rather short intervals, so you should measure idle by actualy byte (sequence number) traffic, not last-time-a-packet-seen (since chaos has a stronger are-you-alive idle probe). I guess this is just process idle time...  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 Jun 88 17:10:31 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 119774; Wed 15-Jun-88 17:07:13 EDT Date: Wed, 15 Jun 88 17:07 EDT From: Alan Bawden Subject: Re: This is important! To: kao@VERMITHRAX.SCH.Symbolics.COM, SRA@XX.LCS.MIT.EDU, maeda@MCC.COM, DCP@QUABBIN.SCRC.Symbolics.COM, cjl@WHEATIES.AI.MIT.EDU, Gumby@MCC.COM cc: Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <19880611005711.2.KAO@BINKLEY.SCH.Symbolics.COM>, <19880613151342.8.KAO@BINKLEY.SCH.Symbolics.COM>, <12406136710.21.SRA@XX.LCS.MIT.EDU>, <19880613161443.4.MAEDA@PELE.ACA.MCC.COM>, <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM>, <12406155402.19.SRA@XX.LCS.MIT.EDU>, <19880613221658.4.CJL@OTIS.AI.MIT.EDU>, <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM>, <19880614211637.8.DCP@SWAN.SCRC.Symbolics.COM>, <19880615034707.7.CJL@OTIS.AI.MIT.EDU>, <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM>, <880615114233.8.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <19880615210705.7.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 13 Jun 88 08:13 PDT From: kao@VERMITHRAX.SCH.Symbolics.COM [Response from the developer. Hope it helps.] Certainly a quick work around for this would be to reduce the file-control-lifetime for MC to something less than 15 minutes and make sure all the machines see the namespace update. Although we haven't done this anywhere (unless our friends at MCC have done this?) this is a reasonable suggestion which did not occur to me when I spotted the problem initially. Please thank the unnamed developer for me. Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. [ Aside to Gumby: The problem with GATEWAY connections is only that someone who uses Chaos TCP-GATEWAY service on MC to access a remote FTP server winds up using zillions of Chaos -and- TCP connections on MC. I suppose you are trying to say that if the problem with FTP connections gets solved, the problem with GATEWAY connections goes away. This is correct. ] Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer ...I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it.... I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test.... BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) I'd be interested in understanding why. Is it because the thing that times out connections might not actually shut down the connection, but would cause the 3600 to forget about it, this accumulating even more useless connections? Date: Tue, 14 Jun 88 23:47 EDT From: Chris Lindblad I added this to our local 7-2-patches system. It will get loaded into most machines here when they boot. Of course this isn't much of a test, since (as far as I know) all the machines that load 7-2-Patches are machines that can talk CHAOS QFILE to all the ITS machines, and they also talk TCP, so there is no reason they should need CHAOS GATEWAY service either. Date: Wed, 15 Jun 88 11:42 CDT From: David Vinayak Wallace This patch appears to have a bug (which I have reported to DCP). I would not suggest supplying it to the unwary. Now if Gumby and Maeda at MCC try this patch out, that will be a real test. As soon as they are satisfied that it works, then we can think about handing it out to other sites that we discover causing this problem in the future. Which finally brings me to the real point of the message. Unfortunately, despite Symbolic's best efforts (for which I thank them), we are still left in a situation where we have to get zapped at least once by a site before we can send them the fix. We can spread the fix around ourselves to the most likely places, but we can still lose now and then. Therefore, unless anybody objects or has a better plan, I plan to install a tasteless little demon that checks for FTP and GATEWAY servers that are clearly idle, and guns them down. That should be an effective defense against any future offenders. (I'll have it keep a log of what it does, so that we can still spot the losers and send them the patch.)  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 15 Jun 88 12:46:09 EDT Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Wed 15 Jun 88 11:42:53-CDT Date: Wed, 15 Jun 88 11:42 CDT From: David Vinayak Wallace Subject: This is important! To: kao@VERMITHRAX.SCH.Symbolics.COM cc: Alan@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-ITS@AI.AI.MIT.EDU In-Reply-To: <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM> Supersedes: <880615114204.7.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <880615114233.8.GUMBY@BRAHMA.ACA.MCC.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY") Fonts: CPTFONT, TINY Date: Wed, 15 Jun 88 08:14 PDT From: kao@VERMITHRAX.SCH.Symbolics.COM Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden 1 In Symbolics 3640 Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, Metering Substrate 26.7, Metering 11.1, Hacks 14.1, IP-TCP 67.5, ILA-NFS 9.6, 7-2-Patches 1.8, MAC 14.5, TeX-DVI 2.2, QUIC 2.0, IMPRESS 2.0, LPD 2.2, Pascal Runtime 20.0, Compiler Tools Package 11.0, Compiler Tools Runtime 21.0, Pascal Package 9.0, Syntax Editor Runtime 4.0, TeX-SCT 2.1, TeX-Doc 2.0, TeX-Common 2.0, VIRTeX 2.0, TeX 2.0, LaTeX 2.0, SliTeX 2.0, YTeX 2.0, BibTeX 2.0, Illustrate 13.1, Macsyma 412.45, microcode 3640-MIC 420, FEP 127, FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233, Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2) on Symbolics 3640 #5233 (Hilbert's Nullstellensatz): 0 Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). Here is the patch written by DCP. It fixes the bug you reported. This patch appears to have a bug (which I have reported to DCP). I would not suggest supplying it to the unwary.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 15 Jun 88 11:19:20 EDT Received: from VERMITHRAX.SCH.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 419997; 15 Jun 88 11:17:15 EDT Received: from BINKLEY.SCH.Symbolics.COM by VERMITHRAX.SCH.Symbolics.COM via CHAOS with CHAOS-MAIL id 14264; Wed 15-Jun-88 08:14:45 PDT Date: Wed, 15 Jun 88 08:14 PDT From: kao@VERMITHRAX.SCH.Symbolics.COM Subject: This is important! To: Alan%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM cc: Bug-Lispm%REAGAN.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-ITS%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> References: <12405426732.27.SRA@XX.LCS.MIT.EDU>, <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Message-ID: <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY") (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, TINY, CPTFONTCB Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden 1 In Symbolics 3640 Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, Metering Substrate 26.7, Metering 11.1, Hacks 14.1, IP-TCP 67.5, ILA-NFS 9.6, 7-2-Patches 1.8, MAC 14.5, TeX-DVI 2.2, QUIC 2.0, IMPRESS 2.0, LPD 2.2, Pascal Runtime 20.0, Compiler Tools Package 11.0, Compiler Tools Runtime 21.0, Pascal Package 9.0, Syntax Editor Runtime 4.0, TeX-SCT 2.1, TeX-Doc 2.0, TeX-Common 2.0, VIRTeX 2.0, TeX 2.0, LaTeX 2.0, SliTeX 2.0, YTeX 2.0, BibTeX 2.0, Illustrate 13.1, Macsyma 412.45, microcode 3640-MIC 420, FEP 127, FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233, Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2) on Symbolics 3640 #5233 (Hilbert's Nullstellensatz): 0 Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Here is the patch written by DCP. It fixes the bug you reported. ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: USER; Base: 10; Patch-File: T -*- ;;; Patch file for Private version 0.0 ;;; Reason: Removing the connection from the file access path should not ;;; be part of the contract of resetting the connection. ;;; Function (FLAVOR:METHOD :RESET FS:TCP-FTP-CONN): Don't remove. (Doing so is "silly" anyway.) ;;; Remove function (FLAVOR:METHOD :REMOVE-CONN FS:TCP-FTP-FILE-ACCESS-PATH): No longer needed. ;;; Function (DEFUN-IN-FLAVOR FS:TCP-FTP-FIND-CONN FS:TCP-FTP-FILE-ACCESS-PATH): Interact properly with multiple processes. ;;; Written by DCP, 6/14/88 16:18:34 ;;; while running on Swan from MAMA-CASS|FEP1:>SCRC-7-2-E-from-IH-Genera-7-2-C.load.1 ;;; with Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, ;;; Nsage 27.175, Documentation Database 62.18, Metering Substrate 26.7, ;;; Metering 11.1, Hacks 14.1, IP-TCP 67.5, DNA 41.6, Version Control 52.9, ;;; Compare Merge 18.0, Experimental Lock Simple 19.0, VC Documentation 12.0, ;;; Symbolics In-House 16.7, Symbolics In-House Documentation 6.3, ;;; Experimental Statice 53.0, Unique-ID 11.2, DBFS 54.16, DBFS Utilities 9.0, ;;; Statice-Index 15.0, Statice-Record 26.1, Statice-Model 51.15, ;;; Statice Documentation 16.0, Experimental Statice Examples NEWEST, DBFS-DIR 25.4, ;;; Statice-Utilities 14.4, Tertiary Storage 10.0, DBFS Maintenance 12.0, ;;; Volume Librarian 9.0, Bug Tracking 24.11, Symbolics Boston 17.2, SCRC 37.0, ;;; Experimental Ndomains 18, microcode 3640-MIC 420, FEP 127, ;;; FEP0:>V127-lisp.flod(61), FEP0:>V127-loaders.flod(61), FEP0:>V127-tests.flod(61), ;;; FEP0:>v127-debug.flod(37), FEP0:>V127-ddt.flod(61), FEP0:>V127-info.flod(61), ;;; Machine serial number 4968, ;;; Be more imaginative than "Run" (from Q:>dcp>ideas>info-giving-process-preemption.lisp.8), ;;; System patches for 7.1 domain implementation (from Q:>dcp>domains>system-patches.lisp.5). (NOTE-PRIVATE-PATCH "TCP-FTP: Interact properly with DELETE operation") ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-") ;; Connections (defmethod (:reset tcp-ftp-conn) () (setq login-state nil) (setq state :free) (when telnet-stream (send telnet-stream :close :abort) (setq telnet-stream nil)) (when data-stream (send data-stream :close :abort) 2(setq data-stream nil)0) (when aux-stream (send aux-stream :close :abort) (setq aux-stream nil)) 2;; Don't remove the connection. Doing so causes all sorts of grief. 0 2;; There are some parts of the code that :RESET the connection and 0 2;; then proceed to open up a new telnet-stream (e.g., 0 2;; 0tcp-ftp-validate-conn2) and there are others that dolist the conns, 0 2;; and removing a conn out from under them isn't very fun at all! 0 2;; 0(send file-access-path :remove-conn self) ) ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-") (FUNDEFINE '(FLAVOR:METHOD :REMOVE-CONN TCP-FTP-FILE-ACCESS-PATH)) ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-") (defun-in-flavor (tcp-ftp-find-conn tcp-ftp-file-access-path) () (loop for conn in conns when (send conn :allocate) return conn finally 2(let ((new-conn 0(make-instance 'tcp-ftp-conn :file-access-path self :service-access-path service-access-path)2)) 0 2(without-interrupts 0 (push 2new-conn 0conns)2) 0 (send *file-connection-scavenger* :run-reason self) (return 2new-conn0)2)0))  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 14 Jun 88 23:49:40 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 119569; Tue 14-Jun-88 23:47:12 EDT Date: Tue, 14 Jun 88 23:47 EDT From: Chris Lindblad Subject: File-Control-Lifetime "fix" for MC FTP connections To: DCP@quabbin.scrc.symbolics.com cc: Gumby@mcc.com, SRA@xx.lcs, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@xx.lcs In-Reply-To: The message of 14 Jun 88 17:16 EDT from David C. Plummer Message-ID: <19880615034707.7.CJL@OTIS.AI.MIT.EDU> Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Yup. Legit bug in the Slime mold. I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it. I figured out how to reproduce the problem and this file does appear to fix it. I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test. I didn't compile the file. On the LispM end, this also fixes the orphan TCP (FTP) connection bug, which accompanies the ITS/TWENEX manifestation. I added this to our local 7-2-patches system. It will get loaded into most machines here when they boot. BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end."  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 14 Jun 88 17:20:16 EDT Received: from SWAN.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 300788; 14 Jun 88 17:16:27 EDT Date: Tue, 14 Jun 88 17:15 EDT From: David C. Plummer Subject: File-Control-Lifetime "fix" for MC FTP connections To: David Vinayak Wallace , Chris Lindblad cc: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <19880614211534.7.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Yup. Legit bug in the Slime mold. I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it. I figured out how to reproduce the problem and this file does appear to fix it. I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test. I didn't compile the file. On the LispM end, this also fixes the orphan TCP (FTP) connection bug, which accompanies the ITS/TWENEX manifestation. Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end."  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 14 Jun 88 17:20:13 EDT Received: from SWAN.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 300789; 14 Jun 88 17:17:18 EDT Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer Subject: File-Control-Lifetime "fix" for MC FTP connections To: David Vinayak Wallace , Chris Lindblad cc: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM> Supersedes: <19880614211534.7.DCP@SWAN.SCRC.Symbolics.COM> Message-ID: <19880614211637.8.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Yup. Legit bug in the Slime mold. I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it. I figured out how to reproduce the problem and this file does appear to fix it. I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test. I didn't compile the file. On the LispM end, this also fixes the orphan TCP (FTP) connection bug, which accompanies the ITS/TWENEX manifestation. BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end."  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 13 Jun 88 23:23:05 EDT Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 13 Jun 88 22:21:08-CDT Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace Subject: File-Control-Lifetime "fix" for MC FTP connections To: Chris Lindblad cc: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <19880613221658.4.CJL@OTIS.AI.MIT.EDU> Message-ID: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM> The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end."  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 13 Jun 88 18:18:48 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 119204; Mon 13-Jun-88 18:16:59 EDT Date: Mon, 13 Jun 88 18:16 EDT From: Chris Lindblad Subject: File-Control-Lifetime "fix" for MC FTP connections To: SRA@XX.LCS.MIT.EDU cc: Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <12406136710.21.SRA@XX.LCS.MIT.EDU> Message-ID: <19880613221658.4.CJL@OTIS.AI.MIT.EDU> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (2 0 (NIL 0) (:FIX :ITALIC :NORMAL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI Date: Mon 13 Jun 88 11:44:20-EDT From: Rob Austein My impression is that this really isn't enough, given that MC's hostname seems to be wired into two zillion pieces of Lispm code (at least, 1I can't find anything in the namespace that would explain the way lispms always offer to use MC as a gateway0). Also, the fact that this approach only works if every namespace that includes a reference to MC gets the update and nobody anywhere decides to make the lifetime longer again. Right. I also believe in the tooth fairy.... The lisp machines use MC as a gatway because the namespace says it supports the TCP-GATEWAY service. 2Showing HOST MC in namespace LCS: 0... 1Service: TCP-GATEWAY CHAOS TCP-GATEWAY 0... But I figured I'd give somebody else a chance to tell me that I'm an ignorant barbarian and that the fix is sufficient. I personally doubt the fix will be sufficient.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 88 13:32:50 EDT Date: Mon 13 Jun 88 13:27:00-EDT From: Rob Austein Subject: Re: File-Control-Lifetime "fix" for MC FTP connections To: DCP@QUABBIN.SCRC.Symbolics.COM cc: maeda@MCC.COM, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM> Message-ID: <12406155402.19.SRA@XX.LCS.MIT.EDU> Date: Mon, 13 Jun 88 13:01 EDT From: David C. Plummer [Don't shoot the messenger!! I intend to look into this when I get out from under a week's worth of mail. But don't tell my co-workers that, nor as a promise I'll find a fix.] On that basis, I'm still glad to hear this. Thanks for whatever you find time to do.... Is it really easier to load a patch on ALL the machines than it is to change a FEW namespaces? Moot point, since (almost) all the Tech Square Lispms do automatic world load installation. In any case, it is definitely more permanent to fix the code, too many people can and do edit the namespace for me to trust anything that can wipe out an important machine this completely to a namespace entry. Also, once we have a patch we can tell the owners of offending machines to either install the patch or lose access to MC. At the moment there's no constructive action we can ask offenders to take. -------  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 13 Jun 88 13:04:35 EDT Received: from SWAN.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 300367; Mon 13-Jun-88 13:02:06 EDT Date: Mon, 13 Jun 88 13:01 EDT From: David C. Plummer Subject: File-Control-Lifetime "fix" for MC FTP connections To: Christopher Maeda , SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU cc: TJG@XX.LCS.MIT.EDU In-Reply-To: <19880613161443.4.MAEDA@PELE.ACA.MCC.COM> Message-ID: <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 13 Jun 88 11:14 CDT From: Christopher Maeda Umm, What should we hicks at MCC set our file control lifetimes for MC to? Since we have such a large lab contingent here, our Texas based namespace features such favorites as XX, AI, and yes, MC. Changing all those namespaces would be kind of hard, especially since ours is supposed to be secure against the outside world. [Don't shoot the messenger!! I intend to look into this when I get out from under a week's worth of mail. But don't tell my co-workers that, nor as a promise I'll find a fix.] Is it really easier to load a patch on ALL the machines than it is to change a FEW namespaces? Give em hell, Rob, Chris  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 13 Jun 88 12:24:33 EDT Received: from PELE.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 13 Jun 88 11:15:54-CDT Date: Mon, 13 Jun 88 11:14 CDT From: Christopher Maeda Subject: File-Control-Lifetime "fix" for MC FTP connections To: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU cc: TJG@XX.LCS.MIT.EDU In-Reply-To: <12406136710.21.SRA@XX.LCS.MIT.EDU> Message-ID: <19880613161443.4.MAEDA@PELE.ACA.MCC.COM> Umm, What should we hicks at MCC set our file control lifetimes for MC to? Since we have such a large lab contingent here, our Texas based namespace features such favorites as XX, AI, and yes, MC. Changing all those namespaces would be kind of hard, especially since ours is supposed to be secure against the outside world. Give em hell, Rob, Chris  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 88 11:43:38 EDT Date: Mon 13 Jun 88 11:44:20-EDT From: Rob Austein Subject: File-Control-Lifetime "fix" for MC FTP connections To: Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU cc: TJG@XX.LCS.MIT.EDU Message-ID: <12406136710.21.SRA@XX.LCS.MIT.EDU> So, is the feeling that this workaround (setting file control lifetime to something short for MC) sufficient or should I yell at Symbolics some more? My impression is that this really isn't enough, given that MC's hostname seems to be wired into two zillion pieces of Lispm code (at least, I can't find anything in the namespace that would explain the way lispms always offer to use MC as a gateway). Also, the fact that this approach only works if every namespace that includes a reference to MC gets the update and nobody anywhere decides to make the lifetime longer again. Right. I also believe in the tooth fairy.... But I figured I'd give somebody else a chance to tell me that I'm an ignorant barbarian and that the fix is sufficient. --Rob -------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 13 Jun 88 11:17:26 EDT Received: from VERMITHRAX.SCH.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 418758; 13 Jun 88 11:15:47 EDT Received: from BINKLEY.SCH.Symbolics.COM by VERMITHRAX.SCH.Symbolics.COM via CHAOS with CHAOS-MAIL id 13531; Mon 13-Jun-88 08:13:31 PDT Date: Mon, 13 Jun 88 08:13 PDT From: kao@VERMITHRAX.SCH.Symbolics.COM Subject: Re: This is important! To: SRA%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Customer-Reports@VERMITHRAX.SCH.Symbolics.COM cc: Bug-Lispm%REAGAN.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Bug-ITS%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, TJG%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <12405426732.27.SRA@XX.LCS.MIT.EDU> References: <12405426732.27.SRA@XX.LCS.MIT.EDU>, <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Message-ID: <19880613151342.8.KAO@BINKLEY.SCH.Symbolics.COM> Date: Fri 10 Jun 88 18:44:18-EDT From: Rob Austein Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Ahem. I, Robert Austein, Systems Programmer in the MIT Laboratory for Computer Science Computational Resources group, HostAdmin etcetera of MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this bug that Alan has reported ASAP and stop abusing the Mail Cruncher. This is pretty clearly not a MIT-specific bug because I've seen this same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC in Austin, Texas. If this request is not sufficient I'll kick this matter upstairs to the people who negotiate contracts with Symbolics and let them yell at you, but that's a lot of hassle for everybody so let's not. RSVP ASAP. Thanks. --Rob ------- [Response from the developer. Hope it helps.] Certainly a quick work around for this would be to reduce the file-control-lifetime for MC to something less than 15 minutes and make sure all the machines see the namespace update. To change FTP from using multiple connections would be a major architectural change and would divert from the norms used for other file protocols. I don't think that multiple connections are the problem here, cleaning up after them is what is causing the pain. There are some long standing bugs that are very difficult to reproduce and track down that affect connection cleanup for FTP connections. The easiest work around that I know of is the short file-control-lifetime in the host object.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 10 Jun 88 21:00:11 EDT Received: from VERMITHRAX.SCH.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 418245; 10 Jun 88 20:58:59 EDT Received: from BINKLEY.SCH.Symbolics.COM by VERMITHRAX.SCH.Symbolics.COM via CHAOS with CHAOS-MAIL id 13385; Fri 10-Jun-88 17:57:00 PDT Date: Fri, 10 Jun 88 17:57 PDT From: kao@VERMITHRAX.SCH.Symbolics.COM Subject: Re: This is important! To: SRA%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM cc: Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-Lispm%REAGAN.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Bug-ITS%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, TJG%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <12405426732.27.SRA@XX.LCS.MIT.EDU> Message-ID: <19880611005711.2.KAO@BINKLEY.SCH.Symbolics.COM> Date: Fri 10 Jun 88 18:44:18-EDT From: Rob Austein Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Ahem. I, Robert Austein, Systems Programmer in the MIT Laboratory for Computer Science Computational Resources group, HostAdmin etcetera of MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this bug that Alan has reported ASAP and stop abusing the Mail Cruncher. This is pretty clearly not a MIT-specific bug because I've seen this same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC in Austin, Texas. If this request is not sufficient I'll kick this matter upstairs to the people who negotiate contracts with Symbolics and let them yell at you, but that's a lot of hassle for everybody so let's not. RSVP ASAP. Thanks. --Rob ------- Request noted. The bug-report/fix-request has been forwarded to the development people and software support supervisor. We'll get back to you by the end of next week.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Jun 88 18:43:20 EDT Date: Fri 10 Jun 88 18:44:18-EDT From: Rob Austein Subject: Re: This is important! To: Customer-Reports@STONY-BROOK.SCRC.SYMBOLICS.COM cc: Bug-Lispm@REAGAN.AI.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU In-Reply-To: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Message-ID: <12405426732.27.SRA@XX.LCS.MIT.EDU> Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Ahem. I, Robert Austein, Systems Programmer in the MIT Laboratory for Computer Science Computational Resources group, HostAdmin etcetera of MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this bug that Alan has reported ASAP and stop abusing the Mail Cruncher. This is pretty clearly not a MIT-specific bug because I've seen this same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC in Austin, Texas. If this request is not sufficient I'll kick this matter upstairs to the people who negotiate contracts with Symbolics and let them yell at you, but that's a lot of hassle for everybody so let's not. RSVP ASAP. Thanks. --Rob -------  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 10 Jun 88 17:45:23 EDT Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 118734; Fri 10-Jun-88 17:42:37 EDT Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! To: Bug-Lispm@REAGAN.AI.MIT.EDU, Customer-Reports@STONY-BROOK.SCRC.SYMBOLICS.COM cc: Bug-ITS@AI.AI.MIT.EDU Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY") Fonts: CPTFONT, TINY 1In Symbolics 3640 Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, Metering Substrate 26.7, Metering 11.1, Hacks 14.1, IP-TCP 67.5, ILA-NFS 9.6, 7-2-Patches 1.8, MAC 14.5, TeX-DVI 2.2, QUIC 2.0, IMPRESS 2.0, LPD 2.2, Pascal Runtime 20.0, Compiler Tools Package 11.0, Compiler Tools Runtime 21.0, Pascal Package 9.0, Syntax Editor Runtime 4.0, TeX-SCT 2.1, TeX-Doc 2.0, TeX-Common 2.0, VIRTeX 2.0, TeX 2.0, LaTeX 2.0, SliTeX 2.0, YTeX 2.0, BibTeX 2.0, Illustrate 13.1, Macsyma 412.45, microcode 3640-MIC 420, FEP 127, FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233, Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2) on Symbolics 3640 #5233 (Hilbert's Nullstellensatz): 0Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 25 May 88 18:17:27 EDT Date: Wed 25 May 88 18:17:03-EDT From: "J. Noel Chiappa" Subject: Re: TCB's all in use. To: SRA@XX.LCS.MIT.EDU, ALAN@AI.AI.MIT.EDU cc: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <12400803897.66.SRA@XX.LCS.MIT.EDU> Message-ID: <12401227468.31.JNC@XX.LCS.MIT.EDU> Rob, your analysis is 100% on the money, and your selected fix also appears to be the Right Thing. I suggest we do that. Noel -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 May 88 03:30:15 EDT Date: Tue 24 May 88 03:30:19-EDT From: Rob Austein Subject: Re: TCB's all in use. To: ALAN@AI.AI.MIT.EDU cc: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU In-Reply-To: <384099.880524.ALAN@AI.AI.MIT.EDU> Message-ID: <12400803897.66.SRA@XX.LCS.MIT.EDU> The code itself is per spec, although it may not be sufficiently paranoid. See RFC 793, pages 38-39. It includes a diagram which is somewhat easier to follow than the text: Figure 13 "Normal Close Sequence": TCP A TCP B 1. ESTABLISHED ESTABLISHED 2. (Close) FIN-WAIT-1 --> --> CLOSE-WAIT 3. FIN-WAIT-2 <-- <-- CLOSE-WAIT 4. (Close) TIME-WAIT <-- <-- LAST-ACK 5. TIME-WAIT --> --> CLOSED 6. (2 MSL) CLOSED ITS is party "A" in this case. COMSAT tells ITS "close this connection", ITS sends off a FIN. Party "B" ACKs the packet but doesn't ACK the FIN until it feels like it (closing is half-duplex). When party "B" decides to close too, it sends a FIN to ITS (note the odd sequence numbers here). ITS is supposed to ACK this FIN so that party "B" knows the connection has indeed been closed in everybody's opinion (ie, FIN is considered data to the extent that must be ACKed). So ITS sends the ACK and goes into the TIME-WAIT state. If ITS hears nothing for a certain period of time ("2 MSL") ITS assumes everything's cool and punts the TCB. If, however, ITS gets another FIN from party "B", ITS must assume that the ACK ITS just sent got lost, so ITS sends another ACK and resets the timer. Whew. No wonder so many implementers get confused by this! It is easy to see how a misbehaving TCP on party "B" could keep us wedged here forever. The RFC says that the only thing you can get when in a TIME-WAIT state is a retransmission of the other party's FIN. Perhaps the ITS code takes that for a law of nature rather than a description of two working TCPs having a conversation. It would be interesting to know if the packet that caused us to get to TSIATW is really the {FIN,ACK} packet we're assuming. If not I'd think that's immediate grounds for dropping the connection on the floor, since it demonstrates that at least one party is seriously confused about the current state. If it really is a FIN that we keep getting over and over and over, it might be reasonable to keep track of how many times we've gone through this routine and just punt when it gets ridiculous. I think this is even legitimate: either the foreign machine is broken or the intervening path is consistantly losing our ACKs, and in either case it won't do any good to send more ACKs so we might as well not bother. Of course this is the first time I've ever tried to follow all those silly state diagrams in TCP, so I might be completely confused. --Rob -------  Date: Tue, 24 May 88 01:47:53 EDT From: Alan Bawden Subject: TCB's all in use. To: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU cc: GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU Message-ID: <384099.880524.ALAN@AI.AI.MIT.EDU> Here is my diagnosis of the lossage. Consider the following code: ; TSIATW - Received ACK while in TIME-WAIT state. This should be ; a re-transmit of the remote FIN. ACK it, and restart ; 2-MSL timeout. TSIATW: METER("TCP: ACK in .XSTMW") MOVSI T,(TC%ACK) TRCPKT R,"TSIATW ACK send in TIME-WAIT" CALL TSOSNR ; Send simple ACK in response. JRST TSITM2 ; and restart 2-MSL timeout. Well, if the guy on the other end keeps sending you ACKs, the timeout keeps getting reset and the TCB never gets freed. I have verified that this is in fact the path that causes the problem by patching that JRST TSITM2 to be a POPJ P, and watching the stuck TCB's all vanish. I actually don't understand the logic here, it would seem to me that you should only be sending an ACK for a actual FIN, not just an ACK. I didn't look to see if the other guy was sending both ACK and FIN or just ACK. Do you suppose it is likely that the other machines all have this bug as well and the two are just spinning their wheels bouncing ACKs back an forth? There does seem to be other code that handles ACKing of FINs elsewhere in the the TCP code, but I don't understand enough to know if it is active when you are in the TIME-WAIT state or not. Conceivably the POPJ P, I patched in might be the solution to the problem? Suggestions?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 23 May 88 14:20:00 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 113962; Mon 23-May-88 14:14:19 EDT Date: Mon, 23 May 88 14:14 EDT From: Alan Bawden Subject: What's with all these TIMWTs? To: GUMBY@AI.AI.MIT.EDU cc: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <424674.880523.GUMBY0@MC.LCS.MIT.EDU> Message-ID: <19880523181422.3.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 23 May 88 04:23:59 EDT From: David Vinayak Wallace Right now there are 26 connections to unix.sri.com in state TIMWT, plus, plus one in FINWT1 to ub.cc.umich.edu. ... There really only looks like there are two lost packets (one to host 0!). ... Its not a question of lost packets, its a question of TCBs, the per-connection data-structure ITS has to maintain throughout the connection's lifetime. Unfortunately a connection can live on after a user process is done with it while the operating systems do some final handshaking to close things down cleanly. It appears that some new version of Unix is making the rounds that does something that causes this handshaking to take virtually forever. AI and MC each have 30 TCB's. They used to have 20, but I increased that when this problem first started happening. I just had to reload AI for the same reason. There are crash dumps for the interested in AI:CRASH;CRASH TCB and MC:CRASH;TCP BITIT.  Date: Mon, 23 May 88 13:09:29 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <383531.880523.ZVONA@AI.AI.MIT.EDU> FTP just failed, complaining that "all sockets in use". Peek showed only two FILE jobs an do FTPs besides mine. What's going on? How do I fix it?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 88 04:05:23 EDT Date: Wed, 11 May 88 16:23:09 EDT From: Alan Bawden Subject: And you thought PDUMP finally worked. To: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU cc: ZVONA@MC.LCS.MIT.EDU Message-ID: <418741.880511.ALAN@MC.LCS.MIT.EDU> Note the -times- in the following consecutive entries from the mailer STATS file on MC. 084735 Note: GC'ing MSGS, 5646555-1620312=4026243 145143 ===> BUG: FATAL ERROR <=== Date: 05/11/88 14:51:42 Autopsy from 22770 Preserved from 22061 Last UUO = 017100,,062447 at 52657 MC was low on disk space at the time, which is probably what caused the original error, but what do you suppose was happening during the 6 hour pause? I'll guess that there is a bug in the PDUMP system call (probably also having to do with low disk space) that kept COMSAT hung until Zvona logged in and noticed the problem. Probably something he did to try and diagnose the problem PCLSR'd the call, and then it finished.  Date: Wed, 20 Apr 88 14:43:01 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <362739.880420.ZVONA@AI.AI.MIT.EDU> AI is out of disk space again. I noticed while deleting OSTATS to make some room that LISTS MSGS is 628 blocks, which seems big.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 3 Apr 88 18:26:05 EDT Received: from DESCARTES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 102573; Sun 3-Apr-88 18:22:03 EDT Date: Sun, 3 Apr 88 18:22 EDT From: Alan Bawden Subject: MD down until further notice. To: Bug-ITS@AI.AI.MIT.EDU Message-ID: <880403182202.3.ALAN@DESCARTES.AI.MIT.EDU> MD's RP06 won't load its heads. I don't currently have the time to investigate this problem further. Being MD, it isn't a very critical problem. I guess we should be happy that it is always MD that breaks.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 29 Mar 88 13:23:17 EST Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 101867; Tue 29-Mar-88 13:19:44 EST Date: Tue, 29 Mar 88 13:19 EST From: Chris Lindblad Subject: Some history questions. To: bug-its@AI.AI.MIT.EDU, bug-twenex@OZ.AI.MIT.EDU Message-ID: <880329131943.9.CJL@OTIS.AI.MIT.EDU> I'm trying to track down the history of file version numbers, and of delete and expunge. Was it really Tenex that invented the features of file version numbers and delete-and-expunge? Or did file versions in the second name of files appear in ITS before Tenex, or was the idea inspired by Tenex? Can anyone point me to an early Tenex paper describing these features? Any ITS papers?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Mar 88 11:35:46 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Mar 88 11:24:33 EST Date: Sat, 12 Mar 88 11:24:38 EST From: "Christopher M. Maeda" Subject: UMass ITS's To: mike@OZ.AI.MIT.EDU cc: info-its@MC.LCS.MIT.EDU Message-ID: <340451.880312.MAEDA@AI.AI.MIT.EDU> I heard of a pretty big Intelligent Tutoring Systems effort going on at UMass. I have the paper at home if you want it. They aren't really doing anything new, just applying AI to a new area. The most interesting thing about the paper is that they continually use the acronym ITS to describe their systems. Chris  Received: from MEAD.SCRC.Symbolics.COM (TCP 20024224752) by AI.AI.MIT.EDU 7 Mar 88 15:58:19 EST Received: from BLACK-BIRD.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141317; Mon 7-Mar-88 15:58:00 EST Date: Mon, 7 Mar 88 15:57 EST From: Ed Schwalenberg Subject: Re: [ota: SPACE Digest V8 #156] To: Rob Austein , MAEDA@AI.AI.MIT.EDU cc: postmaster@MC.LCS.MIT.EDU, MarkL@ALLSPICE.LCS.MIT.EDU, Info-ITS@AI.AI.MIT.EDU In-Reply-To: <12380322663.23.SRA@XX.LCS.MIT.EDU> Message-ID: <880307155748.0.ED@BLACK-BIRD.SCRC.Symbolics.COM> Date: Sun 6 Mar 88 23:23:32-EST From: Rob Austein Date: Sun, 6 Mar 88 14:22:49 EST From: "Christopher M. Maeda" The following was posted to space digest in a discussion about remote logins to the moon.,, [Note COMSAT ".." lossage here^^.] From: tektronix!reed!douglas@ucbvax.berkeley.edu (P Douglas Reeder) Subject: Re: data and long distances The distance problem applies to satelites in geosynchonous orbit, as well. radio wave take a noticeable fraction of a second to get there and back. That would play hell with high baud rates if not accounted for. A comsat expert might know how it's done. For interplanetary stuff you'd want to use a batched mail protocol like BSMTP over a high bandwidth transmission protocol like NETBLT for mail. You could probably get away with SMTP to Lunagrad (Moonbase doesn't look like it's going to be an issue any time soon). Remote login will be bad no matter what. The best you could do would be something like RMS's local editing protocol, again using something like NETBLT for transmission so that at least screen updates would be fast once they arrived. I actually tried using a computer in Miami from Antarctica via a geosynch satellite. It was, er, painful. But I did a fun experiment too: I did an analog loopback through the satellite, and watched my characters echo on the screen. Then I tried typing a character, and while it was on its way up and back I digitally looped back my end. After about 6 passes the character would begin to decay: aaaaaabp~~~~~~ Another satellite hacker (the gentleman in Miami) ran a PDP-11 to the satellite, ran the analog downlink back up to another channel on the same satellite, then to a terminal, for a total delay of about .75 sec.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Mar 88 23:50:25 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 6 Mar 88 23:32:24 EST Date: Sun 6 Mar 88 23:23:32-EST From: Rob Austein Subject: Re: [ota: SPACE Digest V8 #156] To: MAEDA@AI.AI.MIT.EDU cc: info-its@MC.LCS.MIT.EDU, postmaster@MC.LCS.MIT.EDU, MarkL@ALLSPICE.LCS.MIT.EDU In-Reply-To: <336939.880306.MAEDA@AI.AI.MIT.EDU> Message-ID: <12380322663.23.SRA@XX.LCS.MIT.EDU> Date: Sun, 6 Mar 88 14:22:49 EST From: "Christopher M. Maeda" The following was posted to space digest in a discussion about remote logins to the moon.,, [Note COMSAT ".." lossage here^^.] From: tektronix!reed!douglas@ucbvax.berkeley.edu (P Douglas Reeder) Subject: Re: data and long distances The distance problem applies to satelites in geosynchonous orbit, as well. radio wave take a noticeable fraction of a second to get there and back. That would play hell with high baud rates if not accounted for. A comsat expert might know how it's done. For interplanetary stuff you'd want to use a batched mail protocol like BSMTP over a high bandwidth transmission protocol like NETBLT for mail. You could probably get away with SMTP to Lunagrad (Moonbase doesn't look like it's going to be an issue any time soon). Remote login will be bad no matter what. The best you could do would be something like RMS's local editing protocol, again using something like NETBLT for transmission so that at least screen updates would be fast once they arrived. You might also want to ask somebody at BBN about the current tuning of the ARPANET (net 10.0.0.0 itself): one of the three transcontinental channels is a comsat link, the other two are land lines, and all hell broke loose for the few days between when they installed the comsat link and when they got it tuned properly. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Mar 88 20:20:27 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Mar 88 19:56:02 EST Date: Sun, 6 Mar 88 14:22:49 EST From: "Christopher M. Maeda" Subject: [ota: SPACE Digest V8 #156] To: info-its@MC.LCS.MIT.EDU, postmaster@MC.LCS.MIT.EDU Message-ID: <336939.880306.MAEDA@AI.AI.MIT.EDU> The following was posted to space digest in a discussion about remote logins to the moon.,, From: tektronix!reed!douglas@ucbvax.berkeley.edu (P Douglas Reeder) Subject: Re: data and long distances The distance problem applies to satelites in geosynchonous orbit, as well. radio wave take a noticeable fraction of a second to get there and back. That would play hell with high baud rates if not accounted for. A comsat expert might know how it's done. Chris  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 Feb 88 12:29:35 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 94699; Fri 26-Feb-88 12:26:35 EST Date: Fri, 26 Feb 88 12:26 EST From: Alan Bawden Subject: What the heck is this? To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <880226122631.0.ALAN@PIGPEN.AI.MIT.EDU> These connections to ELBERETH.RUTGERS.EDU have been in this state since sometime yesterday. I'm going to take a crash dump into AI:CRASH;TCP ELBERE and reload the system so that we can free up some network channels. AI ITS 1615 Peek 629 2/26/88 11:14:28 Up time = 19:21:17:00 IMP is up. TCP/IP is available. Ix Usr Uname Jname State RWnd Ibf SWnd ReTxQ Lclprt Fgnprt Fgnhst 5 6 15TLNT TELSER OPEN 5170 0 10000 0 0 27 2012 MONK.PROTEON.COM 4 20 406T20 TCP OPEN 11324 0 10000 0 0 10263 31 ATHENA.MIT.EDU 0 24 406T24 TCP SYNSNT 5170 0 0 1 0 12264 31 WALKER-EMH.ARPA 23 TIMWT 5170 0 20000 0 0 31 6150 ELBERETH.RUTGERS.EDU 22 TIMWT 5170 0 20000 0 0 31 3302 ELBERETH.RUTGERS.EDU 21 TIMWT 5170 0 20000 0 0 31 5746 ELBERETH.RUTGERS.EDU 20 TIMWT 5170 0 20000 0 0 31 3305 ELBERETH.RUTGERS.EDU 17 TIMWT 5170 0 20000 0 0 31 10021 TOPAZ.RUTGERS.EDU 16 TIMWT 5170 0 20000 0 0 31 6717 ELBERETH.RUTGERS.EDU 15 TIMWT 5170 0 20000 0 0 31 5712 ELBERETH.RUTGERS.EDU 14 TIMWT 5170 0 20000 0 0 31 11164 ELBERETH.RUTGERS.EDU 13 TIMWT 5170 0 20000 0 0 31 11602 ELBERETH.RUTGERS.EDU 12 TIMWT 5170 0 20000 0 0 31 10312 ELBERETH.RUTGERS.EDU 11 TIMWT 5170 0 20000 0 0 31 11407 ELBERETH.RUTGERS.EDU 10 TIMWT 5170 0 20000 0 0 31 5727 ELBERETH.RUTGERS.EDU 7 TIMWT 5170 0 20000 0 0 31 10614 ELBERETH.RUTGERS.EDU 6 TIMWT 5170 0 20000 0 0 31 11226 ELBERETH.RUTGERS.EDU 3 TIMWT 5170 0 20000 0 0 31 5235 ELBERETH.RUTGERS.EDU 2 TIMWT 5170 0 20000 0 0 31 10015 ELBERETH.RUTGERS.EDU 1 TIMWT 5170 0 20000 0 0 31 10340 ELBERETH.RUTGERS.EDU 8 buffers (7 free) STY Map Idx STY owner Idx STY user Host T15 6 15TLNT TELSER 12 JNC CHTN MONK.PROTEON.COM (TCP) T16 13 16TLNT TELSER 23 ALAN P PIGPEN.AI.MIT.EDU (Chaos)  Date: Thu, 25 Feb 88 15:27:46 EST From: Devon Sean McCullough To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <331879.880225.DEVON@AI.AI.MIT.EDU> Suddenly AI is refusing telnet connections and reporting TCP: SYN queue full on the console, fairly often. I have never noticed this before.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 24 Feb 88 16:42:34 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 94062; Wed 24-Feb-88 16:39:52 EST Date: Wed, 24 Feb 88 16:39 EST From: Alan Bawden Subject: weird MC TCP lossage To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU In-Reply-To: <331156.880224.GUMBY@AI.AI.MIT.EDU> Message-ID: <880224163949.6.ALAN@PIGPEN.AI.MIT.EDU> Date: Wed, 24 Feb 88 06:25:47 EST From: David Vinayak Wallace ... The stats file was very interesting. COMSAT would wake up, connect to some host, deliver all the mail for that host, and then choke when it got to the next host for which it had mail. The way in which it choked was interesting: After the HELO it would read the terminating command from the previous connection. This is the usual situation when some TCP resource runs out. Opening a new pair of TCP channels fails, probably with some kind of device full error, which COMSAT apparently fumbles to produce this behavior. At least, that's my theory. SRA claims that the code in COMSAT couldn't possibly have this bug, and it must be ITS's fault, but I find this hard to believe given that no other program that uses TCP shows any kind of analogous behavior. Unfortunately, it is hard to reproduce this situation so that we can see what COMSAT is -really- doing. ... I called someone on the ninth floor to ask him to take a crash dump, but mc appears not to have come back up.... It looks like it did come back up, but whoever you talked to was typing total jokes on the console. Like giving nonexistent commands, and typing DDT commands to the 8080 front-end, etc.  Date: Wed, 24 Feb 88 06:25:47 EST From: David Vinayak Wallace Subject: weird MC TCP lossage To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU Message-ID: <331156.880224.GUMBY@AI.AI.MIT.EDU> I was unable to get any sort of tcp connection to MC this morning. Chaosnet worked fine. I logged in; the machine was idle! Early morning is often a busy time for ol'MC. I spied on COMSAT, which was idle most of the time. The stats file was very interesting. COMSAT would wake up, connect to some host, deliver all the mail for that host, and then choke when it got to the next host for which it had mail. The way in which it choked was interesting: After the HELO it would read the terminating command from the previous connection. For example COMSAT connected to DECWRL.DEC.COM and apparently delivered lots of mail successfully (one wonders what it was actually sending, but the remote host seemed happy). Anyway, when done with decwrl.dec.com, it tried to talk to some other host, say, bbn.com. The stats file would say something like "ICP BBN.COM: Bad reply 221 decwrl.dec.com signing off." Well, this was certainly weird. I called someone on the ninth floor to ask him to take a crash dump, but mc appears not to have come back up. I don't know what the story is, but it seemed to be happy running in this weird state. Perhaps our local TCP frobber can shed some light on this.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Jan 88 13:46:41 EST Date: Thu, 28 Jan 88 13:46:28 EST From: David Vinayak Wallace Subject: AI disk problems To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <364291.880128.GUMBY@MC.LCS.MIT.EDU> (most of the people who need to see this can't because ai is down, but...) AI's drive 0 won't spin up. I was unable to bring the system up with pack 0 on the other drive; ITS gets some sort of massbus error. david  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 22 Jan 88 19:25:17 EST Received: from THE-JOKER.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 88056; Fri 22-Jan-88 19:27:37 EST Date: Fri, 22 Jan 88 19:26 EST From: Alan Bawden Subject: Ho ho ho To: ZVONA@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <314839.880122.ZVONA@AI.AI.MIT.EDU>, <12368693472.13.SRA@XX.LCS.MIT.EDU> Message-ID: <880122192612.1.ALAN@THE-JOKER.AI.MIT.EDU> Date: Fri, 22 Jan 88 14:27:24 EST From: David Chapman Oh, wow, blast from the past department. We just ran out of disk space on AI. Maybe it's time to start running GFR? I just moved some of the free space from SECOND: to the primary pack. I will be happy to explain to anybody else (in person) how to do this. Date: Fri 22 Jan 88 14:42:29-EST From: Rob Austein Penny ran GFR once or twice, a year or so ago, back when we moved all the sources from MX to AI and discovered how much space that took up. I don't think we've been running it on a regular basis, because there hasn't been a need. "Hasn't been a need". Ho ho ho. We've been doing GFR's to tape every few months for quite some time now.  Date: Fri, 22 Jan 88 14:27:24 EST From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <314839.880122.ZVONA@AI.AI.MIT.EDU> Oh, wow, blast from the past department. We just ran out of disk space on AI. Maybe it's time to start running GFR?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Jan 88 11:25:32 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 3 Jan 88 11:24:55 EST Date: Sun 3 Jan 88 11:24:16-EST From: "J. Noel Chiappa" Subject: Re: Wanted: ITS license To: lysator@obelix.liu.se, bug-its@MC.LCS.MIT.EDU, enea!obelix!lysator@uunet.uu.net cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <8801021756.AA27872@obelix.liu.se> Message-ID: <12363676652.29.JNC@XX.LCS.MIT.EDU> You don't need a license of any kind to run ITS; the software is free and you can pass it around as you like. Just get the pack from Per and have fun! (Make sure he gives you all the sources!) Please let us know how you do if you get the machine; we'll be very interested to hear. We're all extremely pleased to see ITS catching on over in Europe; it was almost dead and gone at one point. Noel -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Jan 88 14:42:15 EST Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 2 Jan 88 14:42:01 EST Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA20668; Sat, 2 Jan 88 14:41:15 EST Received: by enea.se (5.57++/1.14) id AA14398; Sat, 2 Jan 88 19:58:45 +0100 (MET) Received: from asterix.liu.se by majestix.liu.se; Sat, 2 Jan 88 19:03:35 +0100 Received: from obelix.liu.se by asterix.liu.se; Sat, 2 Jan 88 19:01:55 +0100 Received: by obelix.liu.se; Sat, 2 Jan 88 18:56:51 SST Date: Sat, 2 Jan 88 18:56:51 SST From: Lysator Message-Id: <8801021756.AA27872@obelix.liu.se> To: bug-its@mc.lcs.mit.edu Subject: Wanted: ITS license Hello! We - the computer club Lysator at Linkoping university, Sweden - would like to apply for an ITS license. We hope this is the right place for this request. We hope to acquire the following system in the near future: A DEC-2020, serial nr 04655, one or two TU45 and two or more RP06. We would like our system's name to be LI. Peter Lothberg@stacken will hopefully assemble ITS for us on an rp06 pack, provided we get a license. Please reply to lysator@obelix.LIU.SE (in the UUCP domain). Addition to this mailinglist (and others about ITS?) would be nice. Thank you.  Date: Sun, 29 Nov 87 03:10:04 EST From: John Wroclawski Subject: More TCP stuff To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <292213.871129.JTW@AI.AI.MIT.EDU> I added a bunch of stuff to TCP to "optimize" (guess) the best packet size based on the path to the foreign entity, and to send and understand TCP max seg size options. In the past, it has just used the minimum possible value everywhere to be safe. This has the effect of roughly doubling the potential throughput to MIT and arpanet hosts. On the other hand, this is all kinda heuristic, and one could imagine some problems... If you could talk to AI well last week and you can't now, please send a note before assuming you are being screwed by the arpanet.  Date: Fri, 27 Nov 87 00:08:15 EST From: John Wroclawski To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <291890.871127.JTW@AI.AI.MIT.EDU> ITS 1606 (NITS on AI at the moment) has a new IMP driver. Hopefully this will fix up the bad IMPOS crashes and improve the lost TCP buffer problem some. (And it's faster, too!) Please collect crashdumps of anything that looks like an IP/IMP screwup and send a note to bug-its... Oh yeah, the NET command in LOCK actually does something useful now, you might try it first if you think the arpanet is unhappy.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Nov 87 16:54:10 EST Date: Sun, 15 Nov 1987 16:50 EST Message-ID: From: Rob Austein To: Bug-ITS@AI.AI.MIT.EDU Subject: [malis: new Arpanet end to end protocol ] Follow up.... Date: Tue, 10 Nov 87 09:49:17 -0500 From: Andy Malis To: Charles Hedrick cc: tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Re: new Arpanet end to end protocol Charles, Your message is quite wrong (I know - I designed the new End-to-End). I would be interested in knowing (in private) who your "reliable source" is, so that such rumors can be source quenched. After the recent messages on the tcp-ip list, I'm sure we all realize how important source quenching is. The truth of the matter is: PSN 7.0 has two different End-to-End protocols (old EE and new EE). Either one or the other runs at any particular time, and the two cannot interoperate. The ARPANET is currently using PSN 7.0 with the old EE. It is the new EE that will be tested on Nov. 7, 14-15, and 18. The old EE protocol explicitly returned, across the PSN subnet, a separate RFNM packet for each message delivered to a destination host. This RFNM packet was then converted, in the source PSN, into the 1822 RFNM for that message and delivered to the source host. This had the result that, depending on traffic mixes, roughly about 45% to 50% of the packets going through the subnet were RFNMs. Since the PSN does so much per-packet processing, even for these RFNMs, the network was passing much less host traffic than otherwise might be possible. We fixed this in the new EE by making it an explicitly windowed protocol IN THE SUBNET. The destination PSNs have the ability to aggregate ACKs (the new EE internal equivalent to RFNMs) and send multiple ACKs for the same connection in windowed ACK (by using an INTERNAL message sequence number). In addition, these ACKs can now be piggybacked on data traffic, and many ACKs for different EE connections can be shipped together in the same subnet packet to a source PSN. The important thing to note is that when the destination PSN receives an ACK for a connection, it generates, and sends to the source host, a separate 1822 RFNM for EACH and EVERY message submitted by the host and being acknowledged by the ACK. There are no host-visible sequence numbers; the 1822 protocol stays the same as before. What may have confused you is the fact that we at BBN are, concurrent with the PSN 7.0 testing, trying to track down which ARPANET hosts might be affected by a known BSD 4.2 network software problem that may cause RFNMs to be lost in the host itself (I believe it is related to the size of the message received PREVIOUS to the RFNM). This bug has been fixed in BSD 4.3, and I have been told that Lars Poulsen of ACC (lars@acc.arpa) has a patch for BSD 4.2-derived host software. By the way, we have measured in our internal BBNNET (which has been running PSN 7.0 with the new EE only for over five months now) that only about 14% of the packets through the network only contain ACKs - the rest of the ACKs are being piggybacked on the data traffic. We are very pleased with this result. Also, most of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and others) use 1822, and they have had no problems with the new EE. Regards, Andy  Date: Mon, 9 Nov 87 13:37:05 EST From: Alan Bawden Subject: MC:CRASH;PI FAULT To: BUG-ITS@AI.AI.MIT.EDU cc: MAP@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU In-reply-to: Msg of Mon 9 Nov 87 12:36:25 EST from Michael A. Patton Message-ID: <282278.871109.ALAN@AI.AI.MIT.EDU> Date: Mon, 9 Nov 87 12:36:25 EST From: Michael A. Patton I just reloaded MC. It had gotten a "PAGE FAULT WITH PI IN PROGRESS". Dump is in MC:CRASH;PI FAULT. Seems to have restarted all right. This one is a good joke that has happened once before. The fault was taken by the TCP checksumming code. Presumably what happens is that when a packet arrives with a large enough bogus length, the checksumming code applies the checksumming algorithm to a huge block of memory that starts with the packet and extends up to some nonexistent page.  Date: Mon, 9 Nov 87 12:36:25 EST From: "Michael A. Patton" Sender: MAP0@AI.AI.MIT.EDU To: BUG-ITS@AI.AI.MIT.EDU cc: MAP@AI.AI.MIT.EDU Message-ID: <282226.871109.MAP0@AI.AI.MIT.EDU> I just reloaded MC. It had gotten a "PAGE FAULT WITH PI IN PROGRESS". Dump is in MC:CRASH;PI FAULT. Seems to have restarted all right.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Nov 87 17:11:29 EST Received: from SRI-NIC.ARPA (TCP 1200000063) by MC.LCS.MIT.EDU 6 Nov 87 17:10:23 EST Date: Fri, 6 Nov 87 13:54:46 PST From: Ken Harrenstien Subject: [hedrick@aramis.rutgers.edu (Charles Hedrick): new Arpanet end to end protocol] To: bug-tcp@MC.LCS.MIT.EDU cc: bug-its@MC.LCS.MIT.EDU Message-ID: <12348532467.31.KLH@SRI-NIC.ARPA> If this message is true, ITS systems will have problems, since the IMP code counts RFNMs. I guess new code would need to be added which (depending on a runtime flag setting) handles the new scheme. But someone needs to find out exactly what the new scheme is first... --------------- Received: from aramis.rutgers.edu by SRI-NIC.ARPA with TCP; Fri 6 Nov 87 12:06:51-PST Received: by athos.rutgers.edu (5.54/1.14) id AA24392; Fri, 6 Nov 87 02:20:54 EST Date: Fri, 6 Nov 87 02:20:54 EST From: hedrick@aramis.rutgers.edu (Charles Hedrick) Message-Id: <8711060720.AA24392@athos.rutgers.edu> To: tcp-ip@sri-nic.arpa Subject: new Arpanet end to end protocol I have just heard from a reliable source a fairly interesting fact about the new end to end protocol implemented in PSN 7.0. (Note that my terminology is probably slightly off in this message. I don't know anything about the imp to host protocol, so I am almost certainly introducing some distortion in passing on this information.) Apparently one of the efficiency improvements in the new end to end protocol is that the IMP's will no longer attempt to return a RFNM for each packet. You will be expected to look at the ID number included in the RFNM's. Any outstanding RFNM's with ID numbers lower than the current one are also to be considered as acknowledged. Many implementations apparently simply count RFNM's. They assume that one acknowledgement is received per packet. This will no longer be true with the new end to end protocol, and so these implementations will break. I have some reason to think that most existing implementations fall into this category. Tests of the new end to end protocol are scheduled for Nov 7, 14-15, and 18. Implementors should be alert to misbehaviors during these test periods. -------  Date: Mon, 2 Nov 87 15:48:24 EST From: Alan Bawden Subject: DIR device To: PGS@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sat 31 Oct 87 16:42:38 EST from Patrick G. Sobalvarro Message-ID: <278714.871102.ALAN@AI.AI.MIT.EDU> Date: Sat, 31 Oct 87 16:42:38 EST From: Patrick G. Sobalvarro ^R dir:pgs; name2 @ doesn't get me a listing of the files on my directory whose second name is @. This used to work, and NAME1 still does work. That's cause DIR:PGS;SECOND @ is how you get a listing of the files on your directory whose second name is @. DIR:PGS;FIRST FOO is how you get a listing of the files on your directory whose first name is FOO. DIR:PGS;NAME1 and DIR:PGS;NAME2 give directory listings -sorted- (not -filtered-) by first or second filename. (For example DIR:PGS;NAME1 DOWN generates a listing of your directory backwards.)  Date: Sat, 31 Oct 87 16:42:38 EST From: "Patrick G. Sobalvarro" Subject: DIR device To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <278089.871031.PGS@AI.AI.MIT.EDU> ^R dir:pgs; name2 @ doesn't get me a listing of the files on my directory whose second name is @. This used to work, and NAME1 still does work.  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 27 Oct 87 02:52:35 EST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 26 Oct 87 23:49:58 PST Date: Mon, 26 Oct 87 23:06:19 PST From: Mark Crispin Subject: Re: ITS outlives Multics?! To: GUMBY@AI.AI.MIT.EDU cc: Info-ITS@AI.AI.MIT.EDU In-Reply-To: <275589.871027.GUMBY@AI.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12345749289.8.MRC@PANDA.COM> TOPS-10 and TOPS-20 both support 30-bit address spaces (although the KL CPU only allows 23). Having written a large program using 30-bit addressing, I can assure you it isn't as kludgy as its detractors claim, and certainly a lot cleaner than some of the current faddish architectures. I'm sure some bright hacker could figure out how to convert ITS to 30-bit addressing. -------  Date: Tue, 27 Oct 87 01:30:27 EST From: David Vinayak Wallace Subject: ITS outlives Multics?! To: "MRC@PANDA.COM"@AI.AI.MIT.EDU cc: INFO-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 26 Oct 87 10:04:15 PST from Mark Crispin Message-ID: <275589.871027.GUMBY@AI.AI.MIT.EDU> Date: Mon, 26 Oct 87 10:04:15 PST From: Mark Crispin We'll need some new CPU's though. 36-bits are decidedly out of fashion at Stanford, but perhaps there are some MIT VLSI hackers who might want to make a PDP-10 on a chip? But the 18-bit address space is a lose. Since you're making a new chip or chip set anyway, why not double the word length? 36-bit halfwords should keep people happy for a while. We could have more registers, too.  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 26 Oct 87 14:16:23 EST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 26 Oct 87 11:08:04 PST Date: Mon, 26 Oct 87 10:04:15 PST From: Mark Crispin Subject: Re: ITS outlives Multics?! To: ALAN@AI.AI.MIT.EDU cc: INFO-ITS@AI.AI.MIT.EDU In-Reply-To: <275113.871026.ALAN@AI.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12345606917.6.MRC@PANDA.COM> That sounds good. I'm sure the ITS hackers in 2155 will be able to think of something clever to solve the problem then. TOPS-20's date format dies at the last 1/3 second of Wednesday, 7 August 2576 GMT (here on the west coast, just before 5PM PDT), so we have almost 589 years to worry about that. We'll need some new CPU's though. 36-bits are decidedly out of fashion at Stanford, but perhaps there are some MIT VLSI hackers who might want to make a PDP-10 on a chip? -------  Date: Mon, 26 Oct 87 11:58:03 EST From: Alan Bawden Subject: ITS outlives Multics?! To: MRC@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sun 25 Oct 87 13:59:55 PST from Mark Crispin Message-ID: <275113.871026.ALAN@AI.AI.MIT.EDU> Date: Sun, 25 Oct 87 13:59:55 PST From: Mark Crispin ... I was quoted in a trade journal as saying that PANDA/TOPS-20 will see the century tick. What about ITS? We're going to have to do something about that sixbit date format, you know! (I intend to continue using ITS into retirement...) The SIXBIT date format you are thinking of (from the .RDATE uuo) is for simple programs that want the date in MM/DD/YY format. I presume that on January 1, 2000 those programs will want to print the date as 01/01/00, so this isn't a problem. There are two other date formats. The .RYEAR uuo returns the year as an 18-bit quantity, so that will work for quite some time. The other, more common, date format is the one used by the filesystem, and by programs that used the DATIME library; this is the format returned by the RQDATE system call. This format packs the year, less 1900, in a 7-bit field, so this will last through 2027. Since the bit to the left of the year field is unused, we can easily expand this to last through 2155. Probably the most we will have to do is fix a few user programs that have the string "19" built into them.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 26 Oct 87 11:35:46 EST Date: Mon 26 Oct 87 11:33:40-EST From: "J. Noel Chiappa" Subject: Re: ML on the arpanet? To: ALAN@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <275092.871026.ALAN@AI.AI.MIT.EDU> Message-ID: <12345590429.43.JNC@XX.LCS.MIT.EDU> Right; they are around $10K or some such fabulous amount. The first one was one Marty bought and which got snarfed; I got ACC to donate the second one. If you want the other machine IP live why not write code to run an Interlan Ethernet card or something? I gave JTW a Pronet-10 card; they are massively simple to program but nothing ever came of it. Noel -------  Date: Mon, 26 Oct 87 11:18:20 EST From: Alan Bawden Subject: ML on the arpanet? To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 26 Oct 87 02:22:12 EST from David Vinayak Wallace Message-ID: <275092.871026.ALAN@AI.AI.MIT.EDU> Date: Mon, 26 Oct 87 02:22:12 EST From: David Vinayak Wallace Since Multics is going away can we snarf its imp port? Wouldn't do us any good unless we can find another LH/DH.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 87 02:23:04 EST Date: Mon, 26 Oct 87 02:22:12 EST From: David Vinayak Wallace Subject: ML on the arpanet? To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <316281.871026.GUMBY@MC.LCS.MIT.EDU> Since Multics is going away can we snarf its imp port?  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 25 Oct 87 17:23:27 EST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Sun, 25 Oct 87 14:21:06 PST Date: Sun, 25 Oct 87 13:59:55 PST From: Mark Crispin Subject: ITS outlives Multics?! To: INFO-ITS@AI.AI.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12345387677.6.MRC@PANDA.COM> I just got a message from the Multics postmaster saying that MIT-Multics will be shut down on 31 December. Athough it was inevitable it is still rather sad. I find it somewhat ironic though that today, years after ITS was declared dead, there are more ITS systems in operation (even excluding the part-time systems) than ever. I was quoted in a trade journal as saying that PANDA/TOPS-20 will see the century tick. What about ITS? We're going to have to do something about that sixbit date format, you know! -------  Date: Wed, 14 Oct 87 15:02:26 EDT From: Alan Bawden Subject: Not to worry To: ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 12 Oct 87 21:41:19 EDT from David Chapman Message-ID: <269232.871014.ALAN@AI.AI.MIT.EDU> Date: Mon, 12 Oct 87 21:41:19 EDT From: David Chapman AI is getting frequent ECC corrected errors (one every few minutes) in consistent places on the disk. Looks dangerous to me. No worry. A block with an ECC error needs special attention every time it is read. ITS doesn't try to avoid using such blocks, so sometimes we get unlucky and a block with an ECC error gets used either in a file that needs to be touched frequently, or as a swapping block. As long as it doesn't become an outrageous waste of paper, there isn't any problem.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 OCT 87 23:07:48 EDT Date: Mon 12 Oct 87 22:58:19-EDT From: "John Wroclawski" To: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <268383.871012.ZVONA@AI.AI.MIT.EDU> Message-ID: <12342034127.16.JTW@MIT-SPEECH> From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU AI crashed with BUGHLT Bad IMPOS, 2. I dumped to crash;bad impos2. Booted OK. This is known braindamange on my part related to the fact that I didn't notice that someone called a particular TCP routine from clock level when I wrote the IMP driver. However, the machine should recover OK if you just $P it, rather than needing to reboot. -john -------  Date: Mon, 12 Oct 87 21:41:19 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <268387.871012.ZVONA@AI.AI.MIT.EDU> AI is getting frequent ECC corrected errors (one every few minutes) in consistent places on the disk. Looks dangerous to me.  Date: Mon, 12 Oct 87 21:32:01 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <268383.871012.ZVONA@AI.AI.MIT.EDU> AI crashed with BUGHLT Bad IMPOS, 2. I dumped to crash;bad impos2. Booted OK.  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 4 Oct 87 04:28:25 EDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Sun, 4 Oct 87 01:16:03 PDT Date: Sat, 3 Oct 87 23:08:38 PDT From: Mark Crispin Subject: Re: The operating system that wouldn't die! AAAAIIIIEEEEEE!!!!! To: ALAN@AI.AI.MIT.EDU cc: INFO-ITS@AI.AI.MIT.EDU, gls@THINK.COM In-Reply-To: <264420.871003.ALAN@AI.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12339709477.6.MRC@PANDA.COM> Well, you know, we have to start thinking about what will happen when the century ticks. I'm determined that TOPS-20 on PANDA will see it tick, which means fixing any bugs that have two-digit years. The question is, how will ITS handle it? I think it will be damn funny if our 36-bit "dinosaurs" just tick the century and keep on smiling, while every Unix system in the world crashes!!! -- Mark -- -------  Received: from TB.CC.CMU.EDU (TCP 20000576442) by AI.AI.MIT.EDU 4 Oct 87 04:22:14 EDT Date: Sun 4 Oct 87 04:14:20-EDT From: Cthulhu Subject: its on a ka10 To: info-its@AI.AI.MIT.EDU Message-ID: <12339732358.19.AD0R@TB.CC.CMU.EDU> It's amazing enough that they got the ka10 running. I think they've got all core in that lovely machine. These are truly wonderful people. -------  Date: Sat, 3 Oct 87 23:02:14 EDT From: Alan Bawden Subject: The operating system that wouldn't die! AAAAIIIIEEEEEE!!!!! To: INFO-ITS@AI.AI.MIT.EDU, gls@THINK.COM In-reply-to: Msg of Fri 2 Oct 87 11:34:35 EDT from gls at Think.COM Message-ID: <264420.871003.ALAN@AI.AI.MIT.EDU> Date: Fri, 2 Oct 87 11:34:35 EDT From: gls at Think.COM To: bug-its at ai.ai.mit.edu I just got my "Happy Birthday" message from Puff the Magic Dragon at AI. Maybe I'm silly, but this has made me very happy today. It's nice that someone cared enough to set up the software so I get a message every year. (I think I am also affected by nostalgia for my days at MIT.) --Guy Well a message like this is certainly guaranteed to make -my- day! It's always nice to have people appreciate creaky-but-reliable old ITS for still being around after 20 years! I thought I would take this opportunity to spread the word about something that I don't think has been very widely publicized. Some of you may recall that a while ago some fellows in Sweden contacted us about running ITS on various PDP-10's that they owned? Well, we mailed them a set of tapes for bringing up ITS on their 2020, which they were able to do without too much trouble (their biggest problem was -my- fault). That all happened over a year ago. Recently we learned that these guys have successfully -built- ITS paging hardware for their KA-10, and have ITS up and running there as well! Totally Amazing.  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 2 Oct 87 15:57:56 EDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 2 Oct 87 11:34:16 EDT Received: by kali.think.com; Fri, 2 Oct 87 11:34:35 EDT Date: Fri, 2 Oct 87 11:34:35 EDT From: gls@Think.COM Message-Id: <8710021534.AA06791@kali.think.com> To: bug-its@ai.ai.mit.edu Subject: Many thanks I just got my "Happy Birthday" message from Puff the Magic Dragon at AI. Maybe I'm silly, but this has made me very happy today. It's nice that someone cared enough to set up the software so I get a message every year. (I think I am also affected by nostalgia for my days at MIT.) --Guy  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 29 Sep 87 20:03:45 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 29 Sep 87 19:55:19 EDT Date: Tue, 29 Sep 1987 19:51 EDT Message-ID: From: Rob Austein To: BUG-ITS@MC.LCS.MIT.EDU Subject: SUPDUP/ITSTTY enhancement I doubt this will ever get anywhere (too many rlogin fans out there) but just in case, I thought I ought to send it to the people who actually decide what SUPDUP looks like. --Rob To: Michael Padlipsky Cc: "David C. Plummer" , tcp-ip@SRI-NIC.ARPA Re: RCTE and stranger things I was going to say something about that, but decided to wait to see if anybody had in fact read Dave's message. You did, so here goes. Yes, SUPDUP as specified in the RFC is character at a time. However, I believe that a very minor enhancement to the protocol would handle that problem. The big advantages of SUPDUP (sales pitch) are that (1) it works in a heterogenous environment (thus is better than rlogin), and (2) has a wider view of the terminal than just the print head of a hardcopy TTY (thus is better than TELNET). In particular, there are a whole set of useful options under the heading of "The Intelligent Terminal Protocol". Not all of these are documented in the SUPDUP RFCs, for a full explanation of the ITS terminal system see the file "MC: INFO; ITSTTY >" on MC.LCS.MIT.EDU. It's a bit long, so if you're not up for a lot of reading, you want the parts on "Control of the TTY" and "The Intelligent Terminal Protocol". The model I'm using for the local/remote echo and wakup problem is the TOPS-20 TEXTI% JSYS, which was mentioned obliquely a few messages ago when somebody referred to TOPS-20 EMACS enhancements. For those who aren't familiar with TOPS-20, one of the arguments to TEXTI% is a break mask, a 128 bit vector indicating which characters should cause the TEXTI% call to return. I believe that the EMACS extentions that were mentioned were based on an extension to TEXTI% which would cause any character with the meta bit (octal 200) turned on to act as a wakeup. I may be wrong about this, I've never seen the code. Presumably the entity that decides what the break mask should be is the server (where applications programs are running) while the entity that implements the break mask is the client (where the physical display terminal is). So presumably the "change the break mask" sequence would begin with a %TDxxx code. I can't think of any reason why the client would want to tell the server about break masks, but if so the process would be identical except for the escape character (a 30x code, presumably). Henceforth I'll refer to the entity sending the break mask as the "sender" and the entity receiving the break mask as the "recipient". For the 12 bit character set SUPDUP permits, a complete break mask would be rather cumbersome, but there's a natural way to compress this. Make the first data byte a flag byte, with one flag per bucky bit, one flag for characters with no bucky bits, and two unused bits. The flag bits indicate which bucky bits the sender wants the client to try to optimize; if a flag bit is set, a break mask is supplied, if a flag is cleared, no break mask is supplied and the receiver should fall back to the default behavior (wake on every character). The most common message would presumably be one with the no-bucky-bit and control-bucky-bit flags set and all others cleared, indicating that any meta, super, or hyper characters are wakeups. In general, if a program doesn't expect to see a class of characters, it should probably wake up on them so that it can tell the user about typing errors ASAP. The flag byte is followed by a series of break masks (128 bits in 16 bytes, presumably). For completeness, this would have to be separate break masks for each case that the sender has indicated in the flag byte; ie, just because the sender wants to break on CONTROL-A and META-A doesn't mean the server wants to break on CONTROL-META-A. This is part of the reason for the flag byte, so that the sender needn't send a lot of masks that are all ones. All SUPDUP connections would still start out in character at a time remote echo mode. Setting the break mask requests local echo of any characters that are not breaks. Break characters are still handled remotely. Setting the break mask with a zero flag byte (and thus no following masks) would put the connection back in the default character at a time mode. One extension of this idea would be incremental changes to the break mask; if anybody cares enough to do it, there's always the two unused bits in the flag byte. But the above covers the basic scheme. Yes, a similar mechanism could be used in TELNET, without having to think about 12 bit characters and bucky bits, but TELNET is really not a very good model for a display terminal. SUPDUP (and the abstract model of terminals and capabilities that underlies it) is a much better model. I think the existing software speaks for itself. --Rob