sysdoc/its.bugs

   1 Copyright (c) 1999 Massachusetts Institute of Technology
   2
   3 This program is free software; you can redistribute it and/or modify
   4 it under the terms of the GNU General Public License as published by
   5 the Free Software Foundation; either version 3 of the License, or (at
   6 your option) any later version.
   7
   8 This program is distributed in the hope that it will be useful, but
   9 WITHOUT ANY WARRANTY; without even the implied warranty of
  10 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  11 General Public License for more details.
  12
  13 You should have received a copy of the GNU General Public License
  14 along with this program; if not, write to the Free Software
  15 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  16 ------------------------------
  17
  18 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Apr 90 22:37:18 EDT
  19 Received: from BU.EDU by mintaka.lcs.mit.edu id aa23808; 19 Apr 90 22:32 EDT
  20 Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 19 Apr 90 22:31:46 EDT
  21 Received: by bu-it.bu.edu (12/20/89); Thu, 19 Apr 90 22:31:38 EDT
  22 Date:  Thu, 19 Apr 90 22:31:38 EDT
  23 From: Phil Budne <budd@bu-it.bu.edu>
  24 Message-Id:  <9004200231.AA04513@bu-it.bu.edu>
  25 To: DIGEX%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu,
  26     DOOMSDAY%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu
  27 Subject: Re:  the future of ITS
  28 Cc: INFO-ITS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu,
  29     KS-OWNERS%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu
  30
  31 I started on a '10 simulator, but never wrote the 36 bit math needed.
  32 If you figure a 10 times performance hit a DS3100 or a SPARC might
  33 yield performance at the KA/KS level.
  34
  35
  36 \1f
  37 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 19 Apr 90 22:04:09 EDT
  38 Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8576; 19 Apr 90 22:01:59 EDT
  39 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
  40 Date: Thu, 19 Apr 90 22:01 EDT
  41 From: Alan Bawden <Alan@reagan.ai.mit.edu>
  42 Subject: Praise the hackers of the past!
  43 To: ZVONA@ai.ai.mit.edu
  44 Cc: BUG-ITS@ai.ai.mit.edu
  45 In-Reply-To: <722707.900418.ZVONA@AI.AI.MIT.EDU>
  46 Message-Id: <19900420020110.5.ALAN@PIGPEN.AI.MIT.EDU>
  47
  48     Date: Wed, 18 Apr 90 20:11:04 EDT
  49     From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
  50     ... the system crashed with
  51
  52     DIR 2 ZVONA CLOBBERED
  53     PI LEVEL 2 BUGHALT
  54
  55     I dumped to crash;zvona clobbr.  Reloaded OK.  THe directory also
  56     looks OK.  I don't think I did anything weird to provoke this....
  57
  58 Occasionally a crash dump really does enable you to figure out exactly what
  59 the problem was.  In this case the in-core copy of your directory really
  60 was trashed.  It's pretty clear why too.  The last 128. words of the ZVONA
  61 directory were replaced by the first 128. words of the C directory.  Since
  62 disk sectors are exactly 128. words long, and the C directory is stored
  63 right after the ZVONA directory on disk, it doesn't take Sherlock Holmes to
  64 figure out what happened.
  65
  66 Be thankful that many years ago some hacker made ITS paranoid about writing
  67 a directory back to disk without sanity checking it first.
  68 \1f
  69 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Apr 90 16:46:56 EDT
  70 Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09992;
  71           19 Apr 90 16:45 EDT
  72 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
  73 Received: from localhost by zurich.ai.mit.edu; Thu, 19 Apr 90 16:43:55 edt
  74 Date: Thu, 19 Apr 90 16:43:55 edt
  75 From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
  76 Message-Id: <9004192043.AA15383@zurich.ai.mit.edu>
  77 To: DIGEX%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
  78 Cc: DOOMSDAY%AI.AI.MIT.EDU@mintaka.lcs.mit.edu,
  79     KS-OWNERS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu,
  80     info-its%ai.ai.mit.edu@mintaka.lcs.mit.edu
  81 In-Reply-To: Doug Humphrey's message of Thu, 19 Apr 90 16:28:03 EDT <723026.900419.DIGEX@AI.AI.MIT.EDU>
  82 Subject: the future of ITS
  83 Reply-To: jinx@zurich.ai.mit.edu
  84
  85 I think that the idea of a PDP-10 simulator running on a fast Unix box
  86 is pretty funny, but would be a very cool hack.  Writing such a
  87 simulator (except IO instructions) is straight-forward, but changing
  88 ITS to do virtual IO would probably be far more painful.  It may also
  89 require a fair amount of hacking from a very small group of people
  90 (Alan, Moon,...), and that may not be reasonable.
  91
  92
  93
  94 \1f
  95 Date: Thu, 19 Apr 90 16:28:03 EDT
  96 From: Doug Humphrey <DIGEX%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
  97 Subject: the future of ITS
  98 To: DOOMSDAY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
  99 cc: INFO-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, KS-OWNERS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 100 Message-ID: <723026.900419.DIGEX@AI.AI.MIT.EDU>
 101
 102
 103 I would be interested in getting a discussion going on the future of
 104 ITS.  This would be open to any kind of strange ideas, from running
 105 it on existing KS-10 hardware (at MIT or not) to building a PDP-10
 106 software simulator that can run on existing and/or future cpus, like
 107 MIPS chips, etc.  In short, before these machines go away, and all of
 108 the ITS knowledgable people too far away, lets talk about this stuff.
 109
 110 Another point is that INFO-ITS and KS-OWNERS lists should continue to
 111 live after the ITS systems go into hibernation so that advances in the
 112 ITS state-of-the-art can be announced and discussed.
 113
 114 Comments, etc?
 115
 116 Doug Humphrey
 117 digex@mit-ai
 118 digex@tumtum.cs.umd.edu
 119 \1f
 120 Date: Wed, 18 Apr 90 20:11:04 EDT
 121 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 122 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 123 Message-ID: <722707.900418.ZVONA@AI.AI.MIT.EDU>
 124
 125 Well, this is spectacularly ironic.  I was just about to write a
 126 magtape of my AI directory to take to CA -- literally seconds from
 127 doing so -- when the system crashed with
 128
 129 DIR 2 ZVONA CLOBBERED
 130 PI LEVEL 2 BUGHALT
 131
 132 I dumped to crash;zvona clobbr.  Reloaded OK.  THe directory also
 133 looks OK.  I don't think I did anything weird to provoke this....
 134 \1f
 135 Date: Sat, 14 Apr 90 02:40:47 EDT
 136 From: Alan Bawden <ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 137 Subject:  A sad day
 138 To: INFO-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 139 Reply-to: Alan@Reagan.AI.MIT.EDU
 140 Message-ID: <721426.900414.ALAN@AI.AI.MIT.EDU>
 141
 142 I'm sorry to announce that we're going to shut down the ITS machines at
 143 MIT.  As we plan for the final shutdown, the file AI:SYS;GOOD BYE will be
 144 constantly updated to contain the current plans.  What follows is the
 145 current contents of that file, and it pretty much explain the situation:
 146
 147 -------
 148
 149 Well, the time has finally arrived to shut down the ITS machines for the
 150 last time.  The hardware is getting old, and the amount of maintenance
 151 required to keep things running is getting out of hand.  We've been losing
 152 ground at an accelerating rate for the last year.
 153
 154 The current plan is to turn AI and MC off for good sometime around the end
 155 of May.  We plan to take a snapshot of AI and MC's filesystem sometime
 156 before the final shutdown and to keep this snapshot available on some other
 157 file server for a couple of months.  People who have a large number of
 158 files to evacuate, but who lack efficient network access to AI and MC, are
 159 encouraged to simply wait until after this snapshot becomes available.
 160
 161 AI's second RP06 (SECOND:) will be fixed soon to make it easier for people
 162 to evacuate themselves.
 163
 164 Files on ITS backup tapes will be unavailable until someone writes the
 165 program to read them.  Before the shutdown, modest file retrieval requests
 166 (mail to FILE-R@AI) will be considered.  Extensive or complicated retrieval
 167 requests will have to wait until after the dust settles after the shutdown.
 168 Our judgment on these matters will be final.  Sorry.
 169
 170 All mailing lists will have to be moved elsewhere.  If you maintain a
 171 mailing list on AI or MC, you can save us some trouble by moving your
 172 mailing list yourself as soon as possible.  We'll try and do something
 173 responsible about those important lists that don't have obvious owners, but
 174 don't count on us to save your mailing list for you -- we might decide to
 175 just let it perish.
 176
 177 Please try not to pester us about the personal inconvenience this causes
 178 you.  We don't have any suggestions about where you should read your mail
 179 now, where you can keep your files, or where you can move your mailing
 180 list, and we wish we knew of another PDP-10 that you could use.  (If you
 181 -must- pester someone, send mail to DOOMSDAY@AI.)  We do appreciate your
 182 loyalty to ITS during its lifetime at MIT.  Stop by sometime and we can
 183 talk about the good old days when dinosaurs ruled the machine room.
 184
 185 As we continue to plan for doomsday, this file will be updated with the
 186 latest news.
 187
 188                                 - Alan
 189
 190 -------
 191
 192 \1f
 193 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU;  6 Mar 90 13:12:17 EST
 194 Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Mar 90 13:11:41 EST
 195 Received: from NIC.DDN.MIL by mintaka.lcs.mit.edu id aa14446; 6 Mar 90 13:03 EST
 196 Date: Tue, 6 Mar 90 09:49:38 PST
 197 From: Ken Harrenstien <KLH@nic.ddn.mil>
 198 Subject: Status?
 199 To: bug-its@mc.lcs.mit.edu
 200 cc: klh@nic.ddn.mil
 201 Message-ID: <12571572384.22.KLH@NIC.DDN.MIL>
 202
 203 Uh, I haven't been keeping up with ITS developments for a while.  Just
 204 noticed that MC is only reachable by a MX record through MINTAKA.  Does
 205 that mean it's no longer on the Internet at all?  No address is forthcoming
 206 from either our host tables or the DNS.
 207 -------
 208
 209 \1f
 210 Date: Thu, 25 Jan 90 04:43:45 EST
 211 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 212 Subject:  adios to ML
 213 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, POSTMASTER%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU,
 214     NGL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 215 Message-ID: <693233.900125.CENT@AI.AI.MIT.EDU>
 216
 217 alan has made an Executive Decision that trying to make ML work again, as
 218 well as keeping AI and MC in good shape, is Too Much Work For One
 219 Overloaded Grad Student However Encouraging His Friends Are. therefore, ML
 220 isn't coming up again. we did a full dump just before it came down in
 221 november, so all the files are available.
 222     there is a theory about purchasing (yes, we speak of $$) a System
 223 Concepts disk box to hook up to the 2 remaining ITSs; such a thing,
 224 according to the SC folks, would emulate some reasonable number of rp06s
 225 without including their well-known maintenance problems. NB: we do not have
 226 solid commitments on the money yet, so do not assume that we will get this
 227 object. there is reason to believe we will, but no guarantees. if we do,
 228 there should be no problem loading the ML files onto the space so obtained.
 229 in the mean time, we will try to make space for such files available on AI
 230 and MC on an as-needed basis.
 231     the ML dialups will be moved to MC.
 232     i have flushed the references to ML from the system-msg addresses and
 233 the inquir updater lists.
 234 \1f
 235 Date: Sat, 23 Dec 89 02:40:39 EST
 236 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 237 Subject: yow
 238 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 239 Message-ID: <682728.891223.CENT@AI.AI.MIT.EDU>
 240
 241 actually, it's not so surprising that some tourists can talk DDT too
 242 obscurely for me to understand....
 243 ----------
 244 From: "Stephen E. Robbins" <stever@ai.mit.edu>
 245 Date: Thu, 21 Dec 89 13:25:56 EST
 246 To: CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 247 Subject: Where unix-haters-request is
 248    Date: Wed, 20 Dec 89 22:13:42 EST
 249    From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 250    ....Candidates for entry into this august body must either prove their
 251    worth by a short rant on their pet piece of unix brain death, or produce
 252    witnesses of known authority to attest to their adherence to our high
 253    moral principles..
 254
 255 Does knowing about :DDTSYM DPSTOK/-1 followed by $$^R qualify as attesting
 256 to adherence of high moral principles?
 257
 258 - Stephen
 259 \1f
 260 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Dec 89 16:08:30 EST
 261 Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa15010;
 262           15 Dec 89 16:02 EST
 263 Received: from Fafnir.Think.COM by Think.COM; Fri, 15 Dec 89 16:03:23 -0500
 264 Return-Path: <gls@Think.COM>
 265 Received: from verdi.think.com by fafnir.think.com; Fri, 15 Dec 89 15:58:28 EST
 266 Received: from ungar.think.com by verdi.think.com; Fri, 15 Dec 89 15:56:16 EST
 267 From: Guy Steele <gls@think.com>
 268 Received: by ungar.think.com; Fri, 15 Dec 89 15:56:15 EST
 269 Date: Fri, 15 Dec 89 15:56:15 EST
 270 Message-Id: <8912152056.AA29450@ungar.think.com>
 271 To: Ed@alderaan.scrc.symbolics.com
 272 Cc: gumby@gang-of-four.stanford.edu, info-its@ai.ai.mit.edu,
 273     unix-haters@ai.ai.mit.edu, gls@think.com
 274 In-Reply-To: Ed Schwalenberg's message of Fri, 15 Dec 89 14:56 EST <19891215195628.4.ED@PEREGRINE.SCRC.Symbolics.COM>
 275 Subject: TTY MESSAGE FROM A UNIX WEENIE:  LOSSAGE?
 276
 277    Date: Fri, 15 Dec 89 14:56 EST
 278    From: Ed Schwalenberg <Ed@ALDERAAN.SCRC.Symbolics.COM>
 279
 280        Date: Thu, 14 Dec 89 19:57:05 -0800
 281        From: David Vinayak Wallace <gumby@gang-of-four.stanford.edu>
 282
 283        Those who never used TS BEAR may not recognise the message above, but
 284        those who do may be amused by how the cookie bear got permuted by the
 285        time the unix weenies heard about it.  Then again, note his last
 286        question...
 287
 288        >From: kim@watsup.waterloo.edu (T. Kim Nguyen)
 289        Subject: "cookie"
 290        Date: 11 Dec 89 09:13:31 GMT
 291
 292        While the machine was being dismantled, someone took a look inside and
 293        found this circuit board hooked into the machine.  Guess what was
 294        asking for cookies, and had not been found, even after people searched
 295        high and low through the software for the cookie monster...
 296
 297    I heard this story when I entered MIT in September 1974.  The version I
 298    heard allegedly took place at Dartmouth, and the cookie monster wouldn't
 299    go away even after the OS was changed; it took a TTY33 repairperson to
 300    discover the hardware hack in the system console.
 301
 302    I wrote a cookie program for the PDP-8 at MIT's Weather Radar group when
 303    I worked there in the summer of 1975, based on the story I had heard.
 304    I wasn't aware of TS BEAR until much later, although I don't know when
 305    it was written or what inspiration its author (who I think was GLS) had.
 306
 307 I wrote TS BEAR after hearing an oral description of a similar
 308 hack on (as I recall) Multics.  Richard Feynman was perhaps its
 309 most famous victim (it was I who sicced it on him--blush).
 310 \1f
 311 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Dec 89 15:51:16 EST
 312 Received: from [128.81.41.109] by mintaka.lcs.mit.edu id aa14529;
 313           15 Dec 89 15:44 EST
 314 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
 315 Date: Fri, 15 Dec 89 14:56 EST
 316 From: Ed Schwalenberg <Ed@alderaan.scrc.symbolics.com>
 317 Subject: TTY MESSAGE FROM A UNIX WEENIE:  LOSSAGE?
 318 To: David Vinayak Wallace <gumby@gang-of-four.stanford.edu>,
 319     info-its@ai.ai.mit.edu
 320 cc: unix-haters@ai.ai.mit.edu, gls@think.com
 321 In-Reply-To: <8912150357.AA06208@Gang-of-Four.Stanford.EDU>
 322 Message-ID: <19891215195628.4.ED@PEREGRINE.SCRC.Symbolics.COM>
 323
 324     Date: Thu, 14 Dec 89 19:57:05 -0800
 325     From: David Vinayak Wallace <gumby@gang-of-four.stanford.edu>
 326
 327     Those who never used TS BEAR may not recognise the message above, but
 328     those who do may be amused by how the cookie bear got permuted by the
 329     time the unix weenies heard about it.  Then again, note his last
 330     question...
 331
 332     >From: kim@watsup.waterloo.edu (T. Kim Nguyen)
 333     Subject: "cookie"
 334     Date: 11 Dec 89 09:13:31 GMT
 335
 336     While the machine was being dismantled, someone took a look inside and
 337     found this circuit board hooked into the machine.  Guess what was
 338     asking for cookies, and had not been found, even after people searched
 339     high and low through the software for the cookie monster...
 340
 341 I heard this story when I entered MIT in September 1974.  The version I
 342 heard allegedly took place at Dartmouth, and the cookie monster wouldn't
 343 go away even after the OS was changed; it took a TTY33 repairperson to
 344 discover the hardware hack in the system console.
 345
 346 I wrote a cookie program for the PDP-8 at MIT's Weather Radar group when
 347 I worked there in the summer of 1975, based on the story I had heard.
 348 I wasn't aware of TS BEAR until much later, although I don't know when
 349 it was written or what inspiration its author (who I think was GLS) had.
 350 \1f
 351 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Dec 89 12:51:50 EST
 352 Received: from orville.nas.nasa.gov by mintaka.lcs.mit.edu id aa09814;
 353           15 Dec 89 12:45 EST
 354 Received: Fri, 15 Dec 89 09:35:06 PST by orville.nas.nasa.gov (5.59/1.2)
 355 Date: Fri, 15 Dec 89 09:35:06 PST
 356 From: John Lekashman <lekash@orville.nas.nasa.gov>
 357 Message-Id: <8912151735.AA21356@orville.nas.nasa.gov>
 358 To: gumby@gang-of-four.stanford.edu, info-its@AI.ai.mit.edu
 359 Subject: Re:  TTY MESSAGE FROM A UNIX WEENIE:  LOSSAGE?
 360 Cc: unix-haters@AI.ai.mit.edu
 361
 362 The answer is yes.
 363 Either it really happened, or all of Seymour Papert's students
 364 are on drugs is true.  (oooooeeeee-eeeee).  At least back in
 365 the 70s.
 366                                 john
 367 \1f
 368 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 14 Dec 89 23:01:56 EST
 369 Received: from Gang-of-Four.Stanford.EDU by mintaka.lcs.mit.edu id aa22227;
 370           14 Dec 89 22:57 EST
 371 Received: by Gang-of-Four.Stanford.EDU (5.61/inc-1.0)
 372         id AA06208; Thu, 14 Dec 89 19:57:05 -0800
 373 Date: Thu, 14 Dec 89 19:57:05 -0800
 374 From: David Vinayak Wallace <gumby@gang-of-four.stanford.edu>
 375 Message-Id: <8912150357.AA06208@Gang-of-Four.Stanford.EDU>
 376 To: info-its@ai.ai.mit.edu
 377 Cc: unix-haters@ai.ai.mit.edu
 378 Subject: TTY MESSAGE FROM A UNIX WEENIE:  LOSSAGE?
 379
 380 Those who never used TS BEAR may not recognise the message above, but
 381 those who do may be amused by how the cookie bear got permuted by the
 382 time the unix weenies heard about it.  Then again, note his last
 383 question...
 384
 385 Makes one wonder what the loser who wrote the Canonical Losing Unix
 386 Mailer thought he was writing.
 387
 388 >From: kim@watsup.waterloo.edu (T. Kim Nguyen)
 389 Newsgroups: alt.folklore.computers
 390 Subject: "cookie"
 391 Message-ID: <KIM.89Dec11041331@watsup.waterloo.edu>
 392 Date: 11 Dec 89 09:13:31 GMT
 393
 394 OK, here's another one I heard about.  This one (I was told) happened
 395 at MIT, back in the 70s (oooooeeeee-ooooo), on some big network type
 396 machine.  At the same time every day, a message would appear on
 397 people's terminals, saying "Give me a cookie".  And if they did
 398 nothing, the machine would burp and kill their process or something.
 399 Eventually someone, in response to that message, typed "cookie", and
 400 the machine said "thanks" and continued working normally.  For the
 401 remainder of the machine's lifetime, people would type "cookie" at the
 402 same time every day and take it for granted that they had to do this.
 403
 404 While the machine was being dismantled, someone took a look inside and
 405 found this circuit board hooked into the machine.  Guess what was
 406 asking for cookies, and had not been found, even after people searched
 407 high and low through the software for the cookie monster...
 408
 409 So -- did this really happen, or are all of Seymour Papert's students
 410 on drugs?  :-)
 411
 412 --
 413 T. Kim Nguyen                             kim@watsup.waterloo.{edu|cdn}
 414                                                 kim@watsup.uwaterloo.ca
 415                             {uunet|utzoo|utai|decvax}watmath!watsup!kim
 416 Systems Design Engineering  --  University of Waterloo, Ontario, Canada
 417 \1f
 418 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU  9 Nov 89 10:10:19 EST
 419 Received: from [128.81.41.109] by mintaka.lcs.mit.edu id aa23311;
 420           9 Nov 89 10:05 EST
 421 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
 422 Date: Thu, 9 Nov 89 10:03 EST
 423 From: Ed Schwalenberg <Ed@alderaan.scrc.symbolics.com>
 424 Subject: looking for old weirdness
 425 To: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>,
 426     BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 427 cc: rdm%ncsa.uiuc.edu@mintaka.lcs.mit.edu
 428 In-Reply-To: <666900.891109.CENT@AI.AI.MIT.EDU>
 429 Message-ID: <19891109150307.9.ED@PEREGRINE.SCRC.Symbolics.COM>
 430
 431     Date: Thu,  9 Nov 89 04:19:39 EST
 432     From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 433
 434         Date: Fri, 3 Nov 89 13:32:49+060
 435         From: "Ronald D. Mabbitt" <rdm@ncsa.uiuc.edu>
 436         To: cent@ai.ai.mit.edu
 437         Subject: Zork, mdl, etc!
 438         Hi, I'm trying to find the original MDL Zork and MDL compiler and
 439         MDL manuals, etc, for possible academic anduse research use.  Is
 440         it findable?  It should be all old DARPA stuff, so there shouldn't
 441         be any licencing problems...
 442
 443     anyone know where this stuff might be hiding?
 444
 445 Presumably the MDL manuals can be found in the LCS Reading Room.
 446 The compiler sources are probably on DM backup tapes, wherever
 447 they've gone.  Perhaps sources to the manuals are also on backup
 448 tape.
 449
 450 The sources to Zork itself were not kept online, or if they were, they
 451 were kept encrypted.  I doubt you could resurrect it without help from
 452 one of the original Zork wizards.
 453
 454 You might ask TAA (Tim Anderson), who's now at Interleaf, 577-9800.
 455 My recollection is that he was only peripherally involved with Zork,
 456 but he might know how to get in touch with the others.
 457 \1f
 458 Date: Thu,  9 Nov 89 04:19:39 EST
 459 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 460 Subject: looking for old weirdness
 461 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 462 cc: rdm%ncsa.uiuc.edu@MINTAKA.LCS.MIT.EDU
 463 Message-ID: <666900.891109.CENT@AI.AI.MIT.EDU>
 464
 465     Date: Fri, 3 Nov 89 13:32:49+060
 466     From: "Ronald D. Mabbitt" <rdm@ncsa.uiuc.edu>
 467     To: cent@ai.ai.mit.edu
 468     Subject: Zork, mdl, etc!
 469     Hi, I'm trying to find the original MDL Zork and MDL compiler and
 470     MDL manuals, etc, for possible academic anduse research use.  Is
 471     it findable?  It should be all old DARPA stuff, so there shouldn't
 472     be any licencing problems...
 473
 474 anyone know where this stuff might be hiding?
 475 \1f
 476 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 Oct 89 19:56:21 EDT
 477 Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01041;
 478           23 Oct 89 19:47 EDT
 479 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
 480 From: "Leonard N. Foner" <foner@ai.mit.edu>
 481 Received: by wheat-chex (4.0/AI-4.10) id AA10349; Mon, 23 Oct 89 19:47:51 EDT
 482 Date: Mon, 23 Oct 89 19:47:51 EDT
 483 Message-Id: <8910232347.AA10349@wheat-chex>
 484 To: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 485 Cc: ALAN%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu,
 486     FONER%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu,
 487     BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu,
 488     BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 489 In-Reply-To: "Pandora B. Berman"'s message of Mon, 23 Oct 89 19:08:26 EDT <659250.891023.CENT@AI.AI.MIT.EDU>
 490 Subject: inquir broken
 491
 492    Date: Mon, 23 Oct 89 19:08:26 EDT
 493    From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 494
 495        Date: Mon, 23 Oct 89 15:20 PDT
 496        From: Alan Bawden <bawden@parc.xerox.com>
 497        Subject: inquir broken
 498        To: foner@ai.mit.edu
 499        Cc: CENT@ai, BUG-INQUIR@ai, BUG-ITS@ai, ARCHY@ai
 500            Date: Tue, 17 Oct 89 22:29:41 EDT
 501            From: "Leonard N. Foner" <foner@ai.mit.edu>
 502            I just fixed ARCHY's address to say
 503            ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.  Just specifying
 504            @SYMBOLICS.COM yields nondeterministic results
 505        The results are completely deterministic since we go out of our way to
 506        keep the name "Symbolics.COM" attached to -some- host in the host table
 507        we use.  (Remember host tables? -- we still use 'em.)  I don't happen
 508        to know which host that is at the moment, perhaps we need to move it to
 509        Elephant-Butte.
 510        Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM"
 511        in the NAMES file or INQUIR database does -not- affect what address the
 512        mailer uses in delivering the mail.  In either case it will be
 513        canonicalized to the primary name of the host (Elephant-Butte in this
 514        case).
 515    no, SCRC (and the other standard names) all canonicalize to STONY-BROOK.
 516
 517 That's fine.  Since the "@SYMBOLICS.COM" is hidden from the mailer at
 518 Stony by the mailing list expansion on AI, the Stony mailer can't spazz
 519 and do something stupid.
 520
 521        So perhaps someone should put Bill's address back the way it was
 522        before...
 523    i did that the next time i had an occasion to go into NAMES >..
 524
 525 Okay, thanks.  I was under the mistaken assumption that everything that
 526 looked like a domain name was getting delivered to Mintaka for domain
 527 lookup and delivery.  Guess not.  (Guess I was confused by all the
 528 @MINTAKA's all over ITS headers since the ARPAnet evaporated.)
 529
 530                                                 <LNF>
 531 \1f
 532 Date: Mon, 23 Oct 89 19:08:26 EDT
 533 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 534 Subject: inquir broken
 535 To: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 536 cc: FONER%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU,
 537     BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 538 Message-ID: <659250.891023.CENT@AI.AI.MIT.EDU>
 539
 540     Date: Mon, 23 Oct 89 15:20 PDT
 541     From: Alan Bawden <bawden@parc.xerox.com>
 542     Subject: inquir broken
 543     To: foner@ai.mit.edu
 544     Cc: CENT@ai, BUG-INQUIR@ai, BUG-ITS@ai, ARCHY@ai
 545         Date: Tue, 17 Oct 89 22:29:41 EDT
 546         From: "Leonard N. Foner" <foner@ai.mit.edu>
 547         I just fixed ARCHY's address to say
 548         ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.  Just specifying
 549         @SYMBOLICS.COM yields nondeterministic results
 550     The results are completely deterministic since we go out of our way to
 551     keep the name "Symbolics.COM" attached to -some- host in the host table
 552     we use.  (Remember host tables? -- we still use 'em.)  I don't happen
 553     to know which host that is at the moment, perhaps we need to move it to
 554     Elephant-Butte.
 555     Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM"
 556     in the NAMES file or INQUIR database does -not- affect what address the
 557     mailer uses in delivering the mail.  In either case it will be
 558     canonicalized to the primary name of the host (Elephant-Butte in this
 559     case).
 560 no, SCRC (and the other standard names) all canonicalize to STONY-BROOK.
 561
 562     So perhaps someone should put Bill's address back the way it was
 563     before...
 564 i did that the next time i had an occasion to go into NAMES >.
 565 \1f
 566 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 Oct 89 18:37:11 EDT
 567 Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa16237;
 568           23 Oct 89 18:24 EDT
 569 Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
 570         (5.61+/IDA-1.2.8/gandalf) id AA06924; Mon, 23 Oct 89 15:21:20 -0700
 571 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
 572         (5.61+/IDA-1.2.8/gandalf) id AA05120; Mon, 23 Oct 89 15:22:23 PDT
 573 Date: Mon, 23 Oct 89 15:20 PDT
 574 From: Alan Bawden <bawden@parc.xerox.com>
 575 Subject: inquir broken
 576 To: foner@ai.mit.edu
 577 Cc: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu,
 578     BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu,
 579     BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu,
 580     ARCHY%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 581 In-Reply-To: <8910180229.AA08171@wheat-chex>
 582 Message-Id: <19891023222018.3.ALAN@MR-BUN.parc.xerox.com>
 583
 584     Date: Tue, 17 Oct 89 22:29:41 EDT
 585     From: "Leonard N. Foner" <foner@ai.mit.edu>
 586     I just fixed ARCHY's address to say ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.
 587     Just specifying @SYMBOLICS.COM yields nondeterministic
 588     results
 589
 590 The results are completely deterministic since we go out of our way to keep
 591 the name "Symbolics.COM" attached to -some- host in the host table we use.
 592 (Remember host tables? -- we still use 'em.)  I don't happen to know which
 593 host that is at the moment, perhaps we need to move it to Elephant-Butte.
 594
 595 Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM" in
 596 the NAMES file or INQUIR database does -not- affect what address the mailer
 597 uses in delivering the mail.  In either case it will be canonicalized to
 598 the primary name of the host (Elephant-Butte in this case).
 599
 600 So perhaps someone should put Bill's address back the way it was before...
 601 \1f
 602 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 17 Oct 89 22:37:12 EDT
 603 Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18749;
 604           17 Oct 89 22:29 EDT
 605 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
 606 From: "Leonard N. Foner" <foner@ai.mit.edu>
 607 Received: by wheat-chex (4.0/AI-4.10) id AA08171; Tue, 17 Oct 89 22:29:41 EDT
 608 Date: Tue, 17 Oct 89 22:29:41 EDT
 609 Message-Id: <8910180229.AA08171@wheat-chex>
 610 To: CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 611 Cc: BUG-INQUIR%AI.AI.MIT.EDU@mintaka.lcs.mit.edu,
 612     BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu,
 613     ARCHY%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 614 In-Reply-To: "Pandora B. Berman"'s message of Tue, 17 Oct 89 02:43:42 EDT <656327.891017.CENT@AI.AI.MIT.EDU>
 615 Subject: inquir broken
 616 Cc: foner@ai.mit.edu
 617
 618    Date: Tue, 17 Oct 89 02:43:42 EDT
 619    From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 620
 621    i was trying to fix ARCHY's inquir entry to show his real net address,
 622    which is york%ila-west.dialnet.symbolics.com@symbolics.com. inquir has been
 623    fukt over (yes, i know, several years ago) so that it refuses to accept
 624    this address on the grounds that it is "too long for this item". when i ran
 625    inquir on AI, this msg flashed by before i could see it, and i was
 626    confronted merely with an altered inquir entry listing giving "T" as the
 627    address. fortunately i examined the modified entry and so did not send it
 628    off for installation. when i supduped over to MC, inquir showed me the
 629    error msg with a decent delay. on both machines, what seems to occur is
 630    that a T<CR> replaces the so-called too-long item, and the too-long item
 631    ends up appearing as if it had been typed to the What next? question.
 632        anyway, i had to go into NAMES > in order to fix archy's address..
 633
 634 I just fixed ARCHY's address to say ...@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.
 635 Just specifying @SYMBOLICS.COM yields nondeterministic
 636 results---sometimes, the mailer at whichever machine at Symbolics
 637 happens to get the mail becomes confused and will do something random
 638 with such an address, because the mailer doesn't yet "really"
 639 understand domains and sometimes thinks, "Wait, there's no site named
 640 Symbolics...  I guess I'll do something weird."  (There *is* a site
 641 named SCRC, but...)
 642
 643 It'll be a while until the mailer does understand domains correctly.  Until
 644 then, you should specify a real host, not a domain.
 645
 646                                                 <LNF>
 647 \1f
 648 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 17 Oct 89 12:30:18 EDT
 649 Received: from ALEXANDER.BBN.COM by mintaka.lcs.mit.edu id aa11140;
 650           17 Oct 89 12:19 EDT
 651 To: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 652 cc: BUG-INQUIR%AI.AI.MIT.EDU@mintaka.lcs.mit.edu,
 653     BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu,
 654     ARCHY%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 655 Subject: Re: inquir broken
 656 In-reply-to: Your message of Tue, 17 Oct 89 02:43:42 -0400.
 657              <656327.891017.CENT@AI.AI.MIT.EDU>
 658 Date: Tue, 17 Oct 89 12:08:22 -0400
 659 From: cstacy@bbn.com
 660 Message-ID:  <8910171219.aa11140@mintaka.lcs.mit.edu>
 661
 662     Date: Tue, 17 Oct 89 02:43:42 EDT
 663     From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 664     Message-ID: <656327.891017.CENT@AI.AI.MIT.EDU>
 665
 666     i was trying to fix ARCHY's inquir entry to show his real net address,
 667     which is york%ila-west.dialnet.symbolics.com@symbolics.com. inquir has been
 668     fukt over (yes, i know, several years ago) so that it refuses to accept
 669     this address on the grounds that it is "too long for this item".
 670
 671 I don't understand this part of the bug report.  The system has always had
 672 fixed limits on the length of the items.  The limits are defined in the file
 673 LSRTNS, and there is also a definition in INQUIR which must be kept in step.
 674 If INQUIR were to accept an overly long item, the INQUPD program would simply
 675 truncate the item, and mail back a message to the luser indicating that the
 676 data was truncated.  That the user interface doesn't let things get that far,
 677 is definitely a feature.  (This is especially true if the field under
 678 discussion is the network address!)
 679
 680 If your complaint is that 40 characters is too small, in these days of kludged
 681 up mailing addresses, I'd believe that.  It takes somewhat of an operation to
 682 change the database format though.
 683
 684     when i ran
 685     inquir on AI, this msg flashed by before i could see it, and i was
 686     confronted merely with an altered inquir entry listing giving "T" as the
 687     address. fortunately i examined the modified entry and so did not send it
 688     off for installation. when i supduped over to MC, inquir showed me the
 689     error msg with a decent delay. on both machines, what seems to occur is
 690     that a T<CR> replaces the so-called too-long item, and the too-long item
 691     ends up appearing as if it had been typed to the What next? question.
 692         anyway, i had to go into NAMES > in order to fix archy's address..
 693
 694 I have a version of INQUIR in which this bug is probably fixed, but I'm going
 695 to wait until I happen by MIT to try it out; it's too painful to debug over
 696 lots of telnet hops and so forth.
 697
 698 \1f
 699 Date: Tue, 17 Oct 89 02:43:42 EDT
 700 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 701 Subject: inquir broken
 702 To: BUG-INQUIR%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 703 cc: ARCHY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 704 Message-ID: <656327.891017.CENT@AI.AI.MIT.EDU>
 705
 706 i was trying to fix ARCHY's inquir entry to show his real net address,
 707 which is york%ila-west.dialnet.symbolics.com@symbolics.com. inquir has been
 708 fukt over (yes, i know, several years ago) so that it refuses to accept
 709 this address on the grounds that it is "too long for this item". when i ran
 710 inquir on AI, this msg flashed by before i could see it, and i was
 711 confronted merely with an altered inquir entry listing giving "T" as the
 712 address. fortunately i examined the modified entry and so did not send it
 713 off for installation. when i supduped over to MC, inquir showed me the
 714 error msg with a decent delay. on both machines, what seems to occur is
 715 that a T<CR> replaces the so-called too-long item, and the too-long item
 716 ends up appearing as if it had been typed to the What next? question.
 717     anyway, i had to go into NAMES > in order to fix archy's address.
 718 \1f
 719 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Sep 89 22:10:18 EDT
 720 Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa14259;
 721           30 Sep 89 20:28 EDT
 722 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
 723 Date: Sat, 30 Sep 89 20:29 EDT
 724 From: Mike McMahon <MMcM@stony-brook.scrc.symbolics.com>
 725 Subject: can't yank from bolix
 726 To: Alan Bawden <bawden@parc.xerox.com>
 727 cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 728 In-Reply-To: <19890930212059.0.ALAN@MR-BUN.parc.xerox.com>
 729 Message-ID: <19891001002913.4.MMCM@OWL.SCRC.Symbolics.COM>
 730
 731     Date: Sat, 30 Sep 89 14:20 PDT
 732     From: Alan Bawden <bawden@parc.xerox.com>
 733
 734     This has a glitch:  If nobody is reading anything out of the tty input
 735     buffer, like if your program is running and not looking for typein, and the
 736     buffer gets full, then you won't be able to ^Z it.  The ^Z will just sit in
 737     a network buffer and never make it into the tty code (which checks for ^Z
 738     and ^_ does some other processing, before it even considers putting
 739     anything in the input buffer).
 740
 741     I'll bet that the Sun you tried probably has the Unix-analog of this
 742     glitch: if a program isn't reading from the terminal, then input can get
 743     backed up sufficiently (perhaps back across the network) so that you can't
 744     do anything to interrupt it.
 745
 746 Fixed in Tenex :-)
 747 \1f
 748 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Sep 89 19:46:39 EDT
 749 Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa13872;
 750           30 Sep 89 19:41 EDT
 751 Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
 752         (5.61+/IDA-1.2.8/gandalf) id AA25560; Sat, 30 Sep 89 14:23:07 -0700
 753 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
 754         (5.61+/IDA-1.2.8/gandalf) id AA19080; Sat, 30 Sep 89 14:23:07 PDT
 755 Date: Sat, 30 Sep 89 14:20 PDT
 756 From: Alan Bawden <bawden@parc.xerox.com>
 757 Subject: can't yank from bolix
 758 To: ZVONA%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 759 Cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 760 In-Reply-To: <650153.890930.ZVONA@AI.AI.MIT.EDU>
 761 Message-Id: <19890930212059.0.ALAN@MR-BUN.parc.xerox.com>
 762
 763     Date: Sat, 30 Sep 89 14:24:09 EDT
 764     From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu>
 765
 766     The bolix has this winning feature where you can send the top of the
 767     (bolix) kill ring to a terminal window input stream, simulating the
 768     user typing that text.  This doesn't work on ITS.  It does work on a
 769     random sun I just used as a test case.  ITS seems to drop all but the
 770     first 50 characters or so.  Big lose.  What's the story?  Can this be
 771     fixed?
 772
 773 The problem is that when a network connection is direct-connected to a STY,
 774 the clock level routine that transfers characters from the net to the STY
 775 just blasts away without checking if there is room in the 65-character tty
 776 input buffer.  (Note that on hardwired terminals, users can't type fast
 777 enough to fill up this buffer -- and if they do the system dings at them.
 778 Also ordinary .IOT to a STY will hang if there isn't room in the buffer.)
 779
 780 The two routines STYCHA and STYTCP could be given a few instructions to
 781 check to see if the buffer is full, and if so, stop blasting.  No blocking
 782 or anything complicated would be needed, since you're going to come back
 783 and look for more characters to move in the next clock tick anyway.
 784
 785 This has a glitch:  If nobody is reading anything out of the tty input
 786 buffer, like if your program is running and not looking for typein, and the
 787 buffer gets full, then you won't be able to ^Z it.  The ^Z will just sit in
 788 a network buffer and never make it into the tty code (which checks for ^Z
 789 and ^_ does some other processing, before it even considers putting
 790 anything in the input buffer).
 791
 792 I'll bet that the Sun you tried probably has the Unix-analog of this
 793 glitch: if a program isn't reading from the terminal, then input can get
 794 backed up sufficiently (perhaps back across the network) so that you can't
 795 do anything to interrupt it.
 796
 797 Of course you might argue that the glitch is worth the convenience of being
 798 able to type extremently fast...
 799 \1f
 800 Date: Sat, 30 Sep 89 14:24:09 EDT
 801 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 802 Subject:  can't yank from bolix
 803 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 804 Message-ID: <650153.890930.ZVONA@AI.AI.MIT.EDU>
 805
 806 The bolix has this winning feature where you can send the top of the
 807 (bolix) kill ring to a terminal window input stream, simulating the
 808 user typing that text.  This doesn't work on ITS.  It does work on a
 809 random sun I just used as a test case.  ITS seems to drop all but the
 810 first 50 characters or so.  Big lose.  What's the story?  Can this be
 811 fixed?
 812 \1f
 813 Date: Wed, 20 Sep 89 04:14:02 EDT
 814 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 815 Subject: ai crash
 816 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 817 Message-ID: <646359.890920.CENT@AI.AI.MIT.EDU>
 818
 819     Date: Tue, 19 Sep 89 11:47 PDT
 820     From: Alan Bawden <bawden@parc.xerox.com>
 821     Subject: ai crash
 822     To: Moon@stony-brook.scrc.symbolics.com,
 823         CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 824     Cc: BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 825         Date: Tue, 19 Sep 89 11:11 EDT
 826         From: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
 827             Date: Tue, 19 Sep 89 02:05:05 EDT
 828             From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 829             KS10 CSL.V5.2
 830             BT AUTO
 831
 832              DSKDMP
 833         Isn't that the usual symptom of powering the machine off and back
 834         on again?  Perhaps there was a power surge.
 835
 836     Right, the 8080 prints its herald ("KS10 CSL.V5.2") only when it is
 837     reset.  So either there was a power-glitch of some sort, or somebody
 838     pushed the RESET switch on the front of the machine.
 839
 840 i suppose. i was logged in through ML's hardwired VT52 though; i don't
 841 think there was anyone else on the floor at that hour (2am), much less
 842 anyone who would fiddle with the buttons on any ITS, and if there was a
 843 power surge it was very local, because neither MC nor ML were affected, nor
 844 did i notice more macroscopic effects (fluorescents blinking).
 845 \1f
 846 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 19 Sep 89 15:05:48 EDT
 847 Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa17032;
 848           19 Sep 89 14:50 EDT
 849 Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
 850         (5.61+/IDA-1.2.8/gandalf) id AA26638; Tue, 19 Sep 89 11:45:07 -0700
 851 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
 852         (5.61+/IDA-1.2.8/gandalf) id AA14847; Tue, 19 Sep 89 11:49:05 PDT
 853 Date: Tue, 19 Sep 89 11:47 PDT
 854 From: Alan Bawden <bawden@parc.xerox.com>
 855 Subject: ai crash
 856 To: Moon@stony-brook.scrc.symbolics.com,
 857     CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 858 Cc: BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 859 In-Reply-To: <19890919151141.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
 860 Message-Id: <19890919184758.1.ALAN@MR-BUN.parc.xerox.com>
 861
 862     Date: Tue, 19 Sep 89 11:11 EDT
 863     From: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
 864
 865         Date: Tue, 19 Sep 89 02:05:05 EDT
 866         From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 867         KS10 CSL.V5.2
 868         BT AUTO
 869
 870          DSKDMP
 871
 872     Isn't that the usual symptom of powering the machine off and back on
 873     again?  Perhaps there was a power surge.
 874
 875 Right, the 8080 prints its herald ("KS10 CSL.V5.2") only when it is reset.
 876 So either there was a power-glitch of some sort, or somebody pushed the
 877 RESET switch on the front of the machine.
 878
 879 (After about 30 seconds, if you don't type anything at the 8080, it decides
 880 that probably you want it to boot the machine.  So it pretends you gave it
 881 the "BT" command (it types "BT AUTO" to let you know what it is doing)
 882 which starts up a DSKDMP (if you have an ITS pack mounted on unit 0).)
 883 \1f
 884 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 19 Sep 89 11:17:08 EDT
 885 Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa13635;
 886           19 Sep 89 11:11 EDT
 887 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
 888 Date: Tue, 19 Sep 89 11:11 EDT
 889 From: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
 890 Subject: ai crash
 891 To: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 892 cc: BUG-ITS%AI.AI.MIT.EDU@mintaka.lcs.mit.edu
 893 In-Reply-To: <645824.890919.CENT@AI.AI.MIT.EDU>
 894 Message-ID: <19890919151141.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
 895
 896     Date: Tue, 19 Sep 89 02:05:05 EDT
 897     From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
 898
 899     for absolutely no apparent reason, ai crashed this morning. it had just
 900     printed a line on the console giving the date & time (IT IS NOW...),
 901     then there was a blank line followed by
 902     KS10 CSL.V5.2
 903     BT AUTO
 904
 905      DSKDMP
 906
 907 Isn't that the usual symptom of powering the machine off and back on
 908 again?  Perhaps there was a power surge.
 909 \1f
 910 Date: Tue, 19 Sep 89 02:05:05 EDT
 911 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
 912 Subject: ai crash
 913 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
 914 Message-ID: <645824.890919.CENT@AI.AI.MIT.EDU>
 915
 916 for absolutely no apparent reason, ai crashed this morning. it had just
 917 printed a line on the console giving the date & time (IT IS NOW...),
 918 then there was a blank line followed by
 919 KS10 CSL.V5.2
 920 BT AUTO
 921
 922  DSKDMP
 923
 924 i dumped it to CRASH;HUH WHAT, even though i rather doubt the crash dump
 925 will be useful. then i reloaded with no problems. maybe it was cosmic rays
 926 or something.
 927 \1f
 928 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 10 Sep 89 18:45:52 EDT
 929 Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa23016;
 930           10 Sep 89 18:37 EDT
 931 Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
 932         (5.61+/IDA-1.2.8/gandalf) id AA19688; Sun, 10 Sep 89 15:33:12 -0700
 933 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
 934         (5.61+/IDA-1.2.8/gandalf) id AA03302; Sun, 10 Sep 89 15:36:37 PDT
 935 Date: Sun, 10 Sep 89 15:34 PDT
 936 From: Alan Bawden <bawden@parc.xerox.com>
 937 Subject: 25th Anniversary of 36 Bits
 938 To: Info-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
 939 Supersedes: <19890910220047.1.ALAN@MR-BUN.parc.xerox.com>
 940 Comments: There is too a host named MINTAKA.LCS.MIT.EDU.  Try again, Unix braindeath.
 941 Message-Id: <19890910223434.2.ALAN@MR-BUN.parc.xerox.com>
 942
 943 Article 471 of comp.org.decus:
 944 From: clive@pp.ACA.MCC.COM (Clive Dawson)
 945 Newsgroups: comp.arch,comp.org.decus
 946 Subject: 25th Anniversary of 36 Bits
 947 Keywords: 36-bits DEC-10 DEC-20 DECUS
 948 Date: 5 Sep 89 17:05:12 GMT
 949 Organization: MCC, Austin, TX
 950
 951 [The number of people who contributed to the recent discussion on
 952 Digital's 36-bit architecture made it seem appropriate to post this
 953 message here.  My apologies for straying from the main subject
 954 matter.]
 955
 956 A special event will take place at the Fall DECUS Symposium in Anaheim,
 957 California, November 6-10, 1989: The 25th Anniversary of 36-bit systems
 958 will be celebrated.  In 1964, Digital announced the PDP-6.  Twenty-five
 959 years later, the 36-bit architecture is still here serving a loyal
 960 customer base.
 961
 962 The celebration will take place on the evening of Monday, November 6,
 963 1989.  The usual DEC 10/20 Update Session will be held from 3-5 PM.
 964 Last-minute announcements regarding Anniversary events will be made at
 965 this session, as well as in the Monday edition of Update.Daily (the
 966 Symposium newspaper).  A meeting room in one of the Symposium hotels
 967 (Hilton or Marriott) will be made available for the anniversary
 968 events, which include:
 969
 970         -- 36-Bit JEOPARDY!
 971                 In the tradition of the 36-bit Trivia Bowl held at the
 972                 20th Anniversary celebration,  experts on the  history
 973                 and folklore of  36-bit systems  will compete  against
 974                 each other.  Come and match wits with them!
 975
 976         -- Memorabilia Exhibit and Swap
 977                 You are  encouraged to  bring old  manuals,  listings,
 978                 pieces of  hardware  (e.g. KA  and/or  KI  consoles!),
 979                 posters, buttons, tapes, and  any other items  related
 980                 to 36-bit  systems  for  exhibiting  and/or  swapping.
 981                 Table space will be made available.
 982
 983         -- Anniversary Dinner
 984
 985                 Dinner plans  are not  yet firm.   It will  either  be
 986                 catered by the hotel  or we will  adjourn to a  nearby
 987                 restaurant.
 988
 989         -- 36-Bit Magic & War Stories
 990                 Following dinner we  will swap war  stories and  other
 991                 legends of  36-bit  lore.   One of  the  most  popular
 992                 events of  the 1984  celebration will  be repeated:  a
 993                 reading of several infamous  SPR's (and their  equally
 994                 infamous replies.)  Come prepared to share share  your
 995                 favorite  stories.   Prizes  for  the  best  will   be
 996                 awarded.
 997
 998 Note that these four events will NOT appear in the DECUS schedule
 999 since they are not official DECUS functions (and therefore do not
1000 require conference registration.)  If you are planning to attend any
1001 of the 25th Anniversary events, please notify me as soon as possible,
1002 since we need to get a reasonable estimate on the number of people to
1003 expect.  (Dinner plans depend on this, so please try not to delay.)
1004
1005         E-mail:    Internet: Clive@MCC.COM
1006                    UUCP:  ...!cs.utexas.edu!pp!clive
1007         U.S. mail: MCC, 3500 West Balcones Center, Austin, TX 78759
1008         Phone:     (512) 338-3430
1009
1010 This will also enable us to create a mailing list for any last minute
1011 announcements regarding the events.  If you would like table space for
1012 exhibits, please mention this.  Suggestions regarding dinner plans are
1013 also welcome.  It may be difficult to find a reasonable restaurant
1014 nearby that could handle this.  The 20th anniversary dinner was done
1015 by the hotel at a cost of $36/person (what else?!).  Is this a
1016 reasonable fee?  If not, let me know how much you would be willing to
1017 pay.
1018
1019 This message is being sent to the TOPS-20 mailing list and the
1020 comp.arch and comp.org.decus news groups.  Please redistribute as you
1021 see fit and pass the word to other 36-bitters who may not otherwise
1022 find out about this.
1023
1024 See you in Anaheim!
1025
1026 Clive Dawson
1027 \1f
1028 Date: Thu,  7 Sep 89 22:08:49 EDT
1029 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1030 Subject: quick dump fix
1031 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1032 Message-ID: <641945.890907.CENT@AI.AI.MIT.EDU>
1033
1034     Date: Sat, 2 Sep 89 14:16 PDT
1035     From: Alan Bawden <bawden@parc.xerox.com>
1036     Subject: ml and mc stuff
1037     To: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
1038         Date: Fri, 1 Sep 89 18:04:18 EDT
1039         From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu>
1040         i got a good version off tape 238, and repaired the data for 238
1041         (which was fine except for claiming you ABRTed rather than DUMPed)
1042         and 239. i note that TAPSET automatically sets the user to be the
1043         tape writer, which i suppose is not unfair. the broken version of
1044         ML:MACRO TAPES is now MACRO XT. it claims to be the same length as
1045         the good one. ZVONA usd HEP to dump 239 rather than bonzo, which
1046         might have had some effect on the situation. i'm not sure who to
1047         refer the matter to for more inspection.
1048     The file was busted -before- ZVONA did a dump, so that can't be a
1049     problem.  Since you apparently got a good version back from 238, then
1050     it must have been OK at the beginning of the dump (when it was written
1051     to tape) and was then clobbered before the end of the dump (because the
1052     damaged file -did- contain a record for tape 238).
1053
1054     The file contains nothing but zeros other than the records for the two
1055     tapes 238 and 329 (alias 239), just as if DUMP had decided to create an
1056     empty database.  Thus I suspect that DUMP decided erroneously that the
1057     MACRO TAPES file didn't exist (probably it got some error other than
1058     FILE NOT FOUND when it when to open it) and decided to recreate it.  A
1059     PDP-10 hacker (with a reasonable connection) can fix this in nothing
1060     flat.  All he has to do is visit all the places in DUMP where the MACRO
1061     TAPES file is manipulated and fix them to be more careful.  (Dave could
1062     do this in his sleep -- if my guess about the problem is correct.)
1063
1064 would a PDP-10 hacker with a reasonable connection please look into this so
1065 i don't have to keep checking the MACRO TAPES file each time i use DUMP?
1066 thx.
1067 \1f
1068 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU  7 Sep 89 12:11:33 EDT
1069 Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa08922;
1070           7 Sep 89 12:01 EDT
1071 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
1072 Date: Thu, 7 Sep 89 12:02 EDT
1073 From: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
1074 Subject: It's so easy to forget
1075 To: Richard Mlynarik <MLY%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu>
1076 cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
1077 In-Reply-To: <641460.890906.MLY@AI.AI.MIT.EDU>
1078 Message-ID: <19890907160253.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
1079
1080     Date: Wed,  6 Sep 89 19:36:12 EDT
1081     From: Richard Mlynarik <MLY%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu>
1082
1083     It's so easy to forget that after one's Macintosh has crashed because
1084     of NCSA Telnet not checking for out-of-free-memory conditions and
1085     after one's unix "tcp/chaos gateway" telnet login session has been
1086     dropped on the floor (because the TCP stream died) that when one
1087     eventually re-reaches poor internetworkless AI that one will be
1088     greeted with a cheery
1089     --Attach Your Detached Tree--
1090
1091 Or in the words of that bouncy, upbeat reggae tune we were hearing
1092 a lot of about 6 or 7 years ago: "Every day, everything is getting
1093 worse."  There's also one which claims to be about Babylon, but I
1094 think it's really about Unix, "Total destruction, only solution."
1095 \1f
1096 Date: Thu,  7 Sep 89 07:47:35 EDT
1097 From: Robert Huff <HUFF%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1098 To: CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1099 cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1100 Message-ID: <641633.890907.HUFF@AI.AI.MIT.EDU>
1101
1102
1103 Hello:
1104         A couple of times in the last couple days I have dialed in to AI and
1105 the screen/cursor control didn't work. I tried logging out, including off of
1106 the terminal access, and back in again. No luck.
1107         Yesterday evening it happened while I was logged on. THe first 5-10
1108 minutes of the session were fine, then there was a few moments (longer than
1109 the usual delay from operating at 1200bps) of being unable to type into an
1110 Emacs session. and suddenly the cursor control was gone.
1111
1112                                         Thanks,
1113
1114                                         Robert Huff
1115 \1f
1116 Date: Wed,  6 Sep 89 19:36:12 EDT
1117 From: Richard Mlynarik <MLY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1118 Subject:  It's so easy to forget
1119 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1120 Message-ID: <641460.890906.MLY@AI.AI.MIT.EDU>
1121
1122 It's so easy to forget that after one's Macintosh has crashed because
1123 of NCSA Telnet not checking for out-of-free-memory conditions and
1124 after one's unix "tcp/chaos gateway" telnet login session has been
1125 dropped on the floor (because the TCP stream died) that when one
1126 eventually re-reaches poor internetworkless AI that one will be
1127 greeted with a cheery
1128 --Attach Your Detached Tree--
1129 \1f
1130 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Aug 89 20:29:29 EDT
1131 Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa22219;
1132           30 Aug 89 20:24 EDT
1133 Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
1134         (5.61+/IDA-1.2.8/gandalf) id AA04145; Wed, 30 Aug 89 17:20:46 -0700
1135 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
1136         (5.61+/IDA-1.2.8/gandalf) id AA13692; Wed, 30 Aug 89 17:23:30 PDT
1137 Date: Wed, 30 Aug 89 17:22 PDT
1138 From: Alan Bawden <bawden@arisia.xerox.com>
1139 Subject: ml and mc stuff
1140 To: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
1141 Cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
1142 In-Reply-To: <639391.890830.CENT@AI.AI.MIT.EDU>
1143 Message-Id: <19890831002221.0.ALAN@MR-BUN.parc.xerox.com>
1144
1145     Date: Wed, 30 Aug 89 17:03:03 EDT
1146     From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu>
1147     you were going to drop us a note explaining how to avoid mc's frequent
1148     parerr losses.
1149
1150 Here is what you do to disable parity checking:  At any time -after- you
1151 have started DSKDMP, type ^\ to get the 8080's attention.  This should
1152 result in a "KS10>" prompt.  The you type "PE0" followed by a carrage
1153 return.  You should get another "KS10>" prompt.  Then type ^Z.  The 8080
1154 will type "USR MOD" and now you are back where you were before you typed
1155 the ^\.
1156
1157 The reason you have to wait until after starting DSKDMP is that the BT
1158 command turns parity checking on.
1159
1160 You really can do this at -any- time once the PDP10 is rinning.  You can
1161 even walk up to a running ITS and do this.  And in fact you should probably
1162 do this to MC as soon as possible.
1163
1164     also, exactly what is it that's wrong with ML and needs
1165     to be fixed asap? the macro tapes file?
1166
1167 Right.  You can easily see that it is broken by going into DUMP and giving
1168 the TAPES command.  The output looks like:
1169
1170   _tapes
1171    LIST DEV =tty
1172      238 890804   INCR ALAN5      DUMP     0       .      SYSHST
1173      329 890814   INCR ZVONA      DUMP     0       .      USERS2
1174
1175 Where the hell are the rest of the tapes?  (And yeah, Zvona must have
1176 typoed when he made that incremental...)  A hacker should look at the bits
1177 in the existing MACRO TAPES file to see if he or she can figure out what
1178 went wrong.  (The latest version of DUMP is a suspect.)
1179
1180 To repair the damage, first restore the MACRO TAPES file from tape (try
1181 tape 238 first, then 237, etc.), and then use the TAPSET command to enter
1182 the information that is missing.
1183 \1f
1184 Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 14 Aug 89 16:46:09 EDT
1185 Received: from Xerox.COM by mintaka.lcs.mit.edu id aa27549; 14 Aug 89 16:43 EDT
1186 Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 89 13:38:49 PDT
1187 Date: Mon, 14 Aug 89 13:32 PDT
1188 From: bawden.pa@xerox.com
1189 Subject: Well, -we- had an earthquake.
1190 To: ZVONA%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
1191 cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu
1192 In-Reply-To: <633201.890813.ZVONA@AI.AI.MIT.EDU>
1193 Message-ID: <19890814203257.2.ALAN@ROCKY.parc.xerox.com>
1194 Line-fold: no
1195
1196     Date: Sun, 13 Aug 89 13:54:15 EDT
1197     From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu>
1198     At 10:09 this morning all the ITSes apparently died.  The consoles
1199     said BT AUTO and were in DSKDMP.  I take it this is what happens when
1200     the power glitches?
1201
1202 Yup.
1203                          (Probaly the fault of the thunderstorms.)
1204
1205 I hope they were good thunderstorms!
1206
1207     Anyway, I dumped to ai;auto boot? (probably useless) and booted OK.
1208
1209 Yeah, crash dumps are always useless after the 8080 has booted the machine
1210 since that clears core.  Of course it can't -hurt- to take a crash dump --
1211 you can tell that a crash dump is probably useless if it is very small.
1212 (The AUTO BOOT? dump you made is only a block long...)
1213 -------
1214 \1f
1215 Date: Sun, 13 Aug 89 13:54:15 EDT
1216 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1217 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1218 Message-ID: <633201.890813.ZVONA@AI.AI.MIT.EDU>
1219
1220 At 10:09 this morning all the ITSes apparently died.  The consoles
1221 said BT AUTO and were in DSKDMP.  I take it this is what happens when
1222 the power glitches?  (Probaly the fault of the thunderstorms.)
1223 Anyway, I dumped to ai;auto boot? (probably useless) and booted OK.
1224 \1f
1225 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 11 Aug 89 01:52:39 EDT
1226 Received: from XEROX.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 248263; 11 Aug 89 01:49:41 EDT
1227 Received: from Semillon.ms by ArpaGateway.ms ; 10 AUG 89 22:48:51 PDT
1228 Date: Thu, 10 Aug 89 22:46 PDT
1229 From: bawden.pa@Xerox.COM
1230 Subject: Barf!
1231 To: Bug-ITS@AI.AI.MIT.EDU
1232 Message-ID: <19890811054636.5.ALAN@ROCKY.parc.xerox.com>
1233 Line-fold: no
1234
1235 The MACRO TAPES database on ML seems to be screwed up.  This might be a
1236 symptom of something wrong with the new DUMP I installed there before I
1237 left for here.  Symptom:  Start DUMP.  Give the "TAPES" command.  There
1238 only appears to be saved tape information for the most recently written
1239 tape.
1240
1241 I -thought- that the information saved in the records in SYSENG;MACRO TAPES
1242 was unrelated to the format of actualy tape headers.  Perhaps I was
1243 wrong...  (But I still don't understand how that could clobber the entire
1244 database, even -old- versions of DUMP can't find any information.)
1245
1246 Unfortunately for you all, I'm unlikely to be able to fix this from out
1247 here.
1248 -------
1249 \1f
1250 Date: Thu, 20 Jul 89 14:58:16 EDT
1251 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1252 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1253 Message-ID: <623723.890720.ZVONA@AI.AI.MIT.EDU>
1254
1255 AI died.  Very dead; apparently a FEP crash, because the console
1256 wouldn't respond to c-\.  The BOOT switch didn't do anything either.
1257 RESET woke up the FEP and it booted OK.  Crash dump in CRASH;DEAD
1258 IN-H2O.
1259 \1f
1260 Date: Mon, 26 Jun 89 18:33:12 EDT
1261 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1262 Subject: access to AI
1263 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, mayer@IUVAX.CS.INDIANA.EDU
1264 cc: amarylis@LIFE.AI.MIT.EDU
1265 Message-ID: <614488.890626.CENT@AI.AI.MIT.EDU>
1266
1267     From: amarylis@ai.mit.edu (Eva Berlandi)
1268     Date: Mon, 26 Jun 89 17:01:04 EDT
1269     To: all-ai@wheaties.ai.mit.edu
1270     I got this message from this guy, and I can't help him, or know even if
1271     I ought to:
1272
1273         Date: Fri, 23 Jun 89 11:05:00 -0500
1274         From: mayer goldberg <mayer@iuvax.cs.indiana.edu>
1275         To: amarylis@corn-chex.ai.mit.edu
1276         Hello Ms. Berlandi,
1277              I don't suppose you know me, as I was logged on corn-chex via
1278         rms's account. I am trying to get to ai.ai.mit.edu, but had a
1279         problem finding its internet address ... I finally got 10.2.0.6,
1280         but it is not responding, so I am afraid, it must have been changed
1281         ... Given that it is in the "AI Lab", would you be able to find the
1282         address and send it to me? I would be most greatful to you.
1283         Mayer Goldberg.
1284
1285 Mr. Goldberg: Due to software rot, AI.AI.MIT.EDU is not directly on the
1286 Internet.  Since May, when our IMPs were turned off, AI has lived only on
1287 our local ChaosNet, and has only been able to deal with the InterNet via
1288 mail.  All other connection protocols, including TELNET/SUPDUP, are
1289 unusable until we get the necessary software written to put AI directly on
1290 the Internet.  If you think you have some special circumstance for
1291 deserving access to AI, please send mail to USER-ACCOUNTS@AI.AI.MIT.EDU
1292 explaining same, and we'll decide whether we agree and if so what we can do
1293 about it.
1294
1295 Amarylis: Questions concerning access to the AI machine (AI.AI.MIT.EDU)
1296 should be sent to the address USER-ACCOUNTS here.  Thanks.
1297 \1f
1298 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  4 Jun 89 14:04:01 EDT
1299 Received: from ML.AI.MIT.EDU (CHAOS 3133) by MC.LCS.MIT.EDU  4 Jun 89 14:03:38 EDT
1300 Date: Sun,  4 Jun 89 14:03:09 EDT
1301 From: Alan Bawden <ALAN%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1302 Subject:  it's a virus
1303 To: ZVONA%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1304 cc: BUG-ITS%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1305 Message-ID: <10054.890604.ALAN@ML.AI.MIT.EDU>
1306
1307     Date: Sat,  3 Jun 89 14:41:32 EDT
1308     From: David Chapman <ZVONA at AI>
1309     Subject:  it's a virus
1310     AI just crashed with parity error 377 001 300.  That's the one we're
1311     used to seeing on MC, right?
1312
1313 Right, although MC doesn't seem to be getting them anymore...
1314
1315     And it's never happened on AI before, right?
1316
1317 Actually, I think this has happend on AI about twice before...
1318
1319
1320 \1f
1321 Date: Sat,  3 Jun 89 14:41:32 EDT
1322 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1323 Subject:  it's a virus
1324 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1325 Message-ID: <603861.890603.ZVONA@AI.AI.MIT.EDU>
1326
1327 AI just crashed with parity error 377 001 300.  That's the one we're
1328 used to seeing on MC, right?  And it's never happened on AI before,
1329 right?  Shit.
1330 \1f
1331 Date: Fri, 26 May 89 14:08:17 EDT
1332 From: Richard Mlynarik <MLY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1333 Subject: jobdev;chaos tcp
1334 To: SRA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1335 cc: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1336 Message-ID: <600669.890526.MLY@AI.AI.MIT.EDU>
1337
1338 The lisp machines won't attempt to use TCP-GATEWAY on MC because
1339 MC doesn't have an internet address.  So what's the problem?
1340 \1f
1341 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 13:53:22 EDT
1342 Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 214249; 26 May 89 13:51:46 EDT
1343 Received: by bigboote.LCS.MIT.EDU
1344         id AA00896; Fri, 26 May 89 13:52:36 EDT
1345 Date: Fri, 26 May 89 13:52:36 EDT
1346 Message-Id: <8905261752.AA00896@bigboote.LCS.MIT.EDU>
1347 From: Rob Austein <sra@lcs.mit.edu>
1348 Sender: sra@bigboote.LCS.MIT.EDU
1349 To: ZVONA@ai.ai.mit.edu, RS@ai.ai.mit.edu
1350 Cc: BUG-ITS@ai.ai.mit.edu
1351 In-Reply-To: David Chapman's message of Fri, 26 May 89 12:44:56 EDT <600506.890526.ZVONA@AI.AI.MIT.EDU>
1352 Subject: system full
1353
1354    Date: Fri, 26 May 89 12:17:38 EDT
1355    From: David Chapman <ZVONA%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
1356
1357    AI was dead in the water, typing Warning:system full, no job slots
1358    on the console every two seconds.  I crash dumped to crash;sys ful.  I
1359    don't know whether this is relevant, but it was getting a lot of
1360    top-level interrupt 200s in TCP and CHAOS jobs not long before it lost
1361    it.
1362
1363    Date: Fri, 26 May 89 12:44:56 EDT
1364    From: David Chapman <ZVONA%AI.AI.MIT.EDU@mintaka.lcs.mit.edu>
1365
1366    Uh, actually, maybe the problem was that it was running ITS 1632
1367    (which RS brought up this morning) -- maybe something else has changed
1368    incompatibly, like say COMSAT?.  We're running 1633 again now.
1369
1370 Given that ITS.1632 has TCP code which would presumably be somewhat
1371 upset at the lack of an IMP behaving in any known fashion, this is not
1372 terribly surprising.
1373
1374 Yes, COMSAT would also be upset to find that AI was running ITS.1632
1375 again, since it determines what it should do about routing to TCP
1376 hosts by asking the monitor if it supports TCP or not.
1377
1378 Perhaps we should delete/hide JOBDEV;CHAOS TCP on AI and MC?  It's not
1379 like it's doing all those Lisp Machines any good to try getting to the
1380 ARPANET via MC and AI anymore.
1381 \1f
1382 Date: Fri, 26 May 89 13:30:39 EDT
1383 From: Alan Bawden <ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1384 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1385 cc: ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, RS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1386 Message-ID: <600605.890526.ALAN@AI.AI.MIT.EDU>
1387
1388 Right.  There were a bunch of things all going wrong here, most
1389 of them caused by the fact that the hosttable no longer
1390 contains IP addresses for AI and MC.  Certainly that is what
1391 made COMSAT crash, and I'm pretty sure that that is what caused
1392 the system to fill up with dead mail servers.
1393
1394 Rob, you should learn to be more suspicious of situations where
1395 you can't see any reason how something could fail to work.
1396 (The current series of Calvin & Hobbes comes to mind...)
1397 \1f
1398 Date: Fri, 26 May 89 12:44:56 EDT
1399 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1400 Subject:  system full
1401 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1402 cc: RS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1403 Message-ID: <600506.890526.ZVONA@AI.AI.MIT.EDU>
1404
1405 Uh, actually, maybe the problem was that it was running ITS 1632
1406 (which RS brought up this morning) -- maybe something else has changed
1407 incompatibly, like say COMSAT?.  We're running 1633 again now.
1408 \1f
1409 Date: Fri, 26 May 89 12:17:38 EDT
1410 From: David Chapman <ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
1411 To: BUG-ITS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
1412 Message-ID: <600479.890526.ZVONA@AI.AI.MIT.EDU>
1413
1414 AI was dead in the water, typing Warning:system full, no job slots
1415 on the console every two seconds.  I crash dumped to crash;sys ful.  I
1416 don't know whether this is relevant, but it was getting a lot of
1417 top-level interrupt 200s in TCP and CHAOS jobs not long before it lost
1418 it.
1419 \1f
1420 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU  2 May 89 17:53:25 EDT
1421 Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 202126; 2 May 89 17:46:58 EDT
1422 Received: by bigboote.LCS.MIT.EDU
1423         id AA01196; Tue, 2 May 89 17:48:20 EDT
1424 Date: Tue, 2 May 89 17:48:20 EDT
1425 Message-Id: <8905022148.AA01196@bigboote.LCS.MIT.EDU>
1426 From: Rob Austein <sra@lcs.mit.edu>
1427 Sender: sra@bigboote.LCS.MIT.EDU
1428 To: PGS@ai.ai.mit.edu
1429 Cc: BUG-ITS@ai.ai.mit.edu
1430 In-Reply-To: "Patrick G. Sobalvarro"'s message of Tue,  2 May 89 17:33:17 EDT <589618.890502.PGS@AI.AI.MIT.EDU>
1431 Subject: host tables in the brave new world
1432
1433    Date: Tue,  2 May 89 17:33:17 EDT
1434    From: "Patrick G. Sobalvarro" <PGS@ai.ai.mit.edu>
1435
1436    When we switched host table formats a few years ago, I stopped knowing
1437    how to update them.  Is there an easy way to add AI.MIT.EDU to them, now
1438    that that's showing up as a return address on mail from the Unixes?
1439
1440 You don't want to know.  Really.  You don't.
1441
1442 The short answer is that everything came to a grinding halt when XX
1443 went away and we are just about back on our feet now.  If all goes
1444 well, automatic table generation and installation should start up
1445 again within a few days.
1446 \1f
1447 Date: Tue,  2 May 89 17:33:17 EDT
1448 From: "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>
1449 Subject: host tables in the brave new world
1450 To: BUG-ITS@AI.AI.MIT.EDU
1451 Message-ID: <589618.890502.PGS@AI.AI.MIT.EDU>
1452
1453 When we switched host table formats a few years ago, I stopped knowing
1454 how to update them.  Is there an easy way to add AI.MIT.EDU to them, now
1455 that that's showing up as a return address on mail from the Unixes?
1456 \1f
1457 Received: from LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 31 Jan 89 19:28:23 EST
1458 Date: Tue 31 Jan 89 19:23:58-EST
1459 From: "J. Noel Chiappa" <JNC@LCS.MIT.EDU>
1460 To: Alan@AI.AI.MIT.EDU, SRA@LCS.MIT.EDU
1461 cc: BUG-ITS@AI.AI.MIT.EDU, JNC@LCS.MIT.EDU
1462 In-Reply-To: <19890131201142.2.ALAN@PIGPEN.AI.MIT.EDU>
1463 Message-ID: <12467048716.14.JNC@LCS.MIT.EDU>
1464
1465     That is, he believed that there was something we could do, -if- we
1466     knew the machine was about to crash, that would normalize relations
1467     with the IMP so that the NOC's software not to bitch.
1468
1469         This sounds sort of bogus to me. The p4200 ARPANet code
1470 doesn't give any warning when *it's* going to crash, but the NOC
1471 people don't seem to be turning p4200 ports off. Maybe it's just the
1472 frequency of the crashes, which proably generate little 'Host X on IMP
1473 Y went down' messages on te NOC console. I could also believe that the MC
1474 IMP code is doing something that causes a message to come out, hence
1475 the turnoff, but I'm not sure how likely this is.
1476
1477         However, I think the whole issue is moot. According to what I
1478 hear, they are going to turn off the ARPANet in the near future, and
1479 *ALL* the MIT IMP's are going away. If you want any ITS (including MC,
1480 which has out main mail forwarder) to have Internet access after that
1481 date, someone better get busy and write some local net driver for the
1482 machine (and then we can have them all on the Internet, not just MC
1483 and AI).
1484         You can have Pronet-10 interfaces for all the machines; Mike
1485 Patton has a ton of them, and they're pretty easy to program. I don't
1486 know how many Interlan Unibus Ethernet cards there are, but now that
1487 the 750's are mostly gone there may be a bunch of them too. They are
1488 somewhat harder to program, and you'd also have to write ARP.
1489
1490
1491         Noel
1492 -------
1493 \1f
1494 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 31 Jan 89 15:13:53 EST
1495 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
1496 Date: Tue, 31 Jan 89 15:11 EST
1497 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1498 To: SRA@XX.LCS.MIT.EDU
1499 cc: BUG-ITS@AI.AI.MIT.EDU, Zvona@AI.AI.MIT.EDU
1500 In-Reply-To: <CMM.0.88.602132868.sra@bigboote.LCS.MIT.EDU>
1501 Message-ID: <19890131201142.2.ALAN@PIGPEN.AI.MIT.EDU>
1502
1503     Date: Sun, 29 Jan 1989 22:07:48 EST
1504     From: Rob Austein <SRA@lcs.mit.edu>
1505
1506     Do we actually understand the syndrome well enough to say who all the
1507     culprits are?
1508
1509 I think so.  According to our spy at SAIL:
1510
1511         Date: Sun, 29 Jan 89 20:45:30 EST
1512         From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1513         ...  Joe [Weening] says that SAIL has the same problem with them we
1514         do, and that it actualy comes not from a change in the TIP software
1515         but from the NOC monitoring software, which now displays a message
1516         on the operator's console every time a host does something weird.
1517         Whatever MC does constitutes something weird, adn tehy get sick of
1518         seeing it, and so they manually turn off the host interface....
1519
1520 The only thing I would add to this is that according to a drone at the NOC
1521 I tried to get some information out of one day, the "something weird" that
1522 MC does is crash at the wrong time.  That is, he believed that there was
1523 something we could do, -if- we knew the machine was about to crash, that
1524 would normalize relations with the IMP so that the NOC's software not to
1525 bitch.  Needless to say, this isn't very useful if your machine gets errors
1526 that cause it to drop dead without warning (as MC has been doing).
1527
1528     I know that the NOC does this random shutoff thing, and I think I
1529     remember hearing that there was a hardware bug on our side;
1530
1531 There is no hardware bug on our side, unless you count the fact that the
1532 processor has a tendency to spontaneously drop dead.  There is nothing
1533 wrong with the LH/DH-11.
1534
1535     is there also, for example, a software problem in the IMP that causes
1536     this?
1537
1538 I have been accusing the vaguely defined "IMP software".  It sounds like
1539 software in question doesn't actually run in an IMP, but in some machine at
1540 the NOC.
1541
1542            The reason I ask is that we (well, MIT, or DARPA, or somebody)
1543     pay lots of money for the IMP ports, and if the NOC is shutting off
1544     our service because their software can't cope, I think we can
1545     legitimately give them some grief in the formal sense.  If it's just a
1546     stupid reaction on their part to a bug (hardware/software,
1547     our/DEC's/ACC's fault, I don't care), I guess we have to live with it.
1548
1549 It sounds to me like it is a stupid reaction on their part to a software
1550 bug in -their- software.  I don't think it is reasonable that we should
1551 have to live with it.
1552
1553     If this is BBN's fault beyond the NOC lossage, I think we should kick
1554     them, hard.  Hell, maybe we should call our congresscritters and
1555     complain about government waste due to incompetant contractors.
1556
1557 I have never understood the dividing line you draw between uneasonable
1558 behavior that we have to live with and uneasonable behavior that we should
1559 bitch about.  It seems quite clear to me that if you are running a network
1560 like the Arpanet, and your software causes your operators to shut off
1561 service to your users just because they crashed at the wrong moment, then
1562 your customers have legitimate cause to bitch.
1563 \1f
1564 Received: from bigboote.LCS.MIT.EDU (TCP 2206400176) by AI.AI.MIT.EDU 29 Jan 89 22:09:05 EST
1565 Received: by bigboote.LCS.MIT.EDU
1566         id AA11349; Sun, 29 Jan 89 22:07:52 EST
1567 Sender: Rob Austein <sra@bigboote.LCS.MIT.EDU>
1568 Date: Sun, 29 Jan 1989 22:07:48 EST
1569 From: Rob Austein <SRA@lcs.mit.edu>
1570 To: ALAN@ai.ai.mit.edu
1571 Cc: BUG-ITS@ai.ai.mit.edu
1572 In-Reply-To: Your message of Sun, 29 Jan 89 18:04:44 EST
1573 Message-Id: <CMM.0.88.602132868.sra@bigboote.LCS.MIT.EDU>
1574
1575 Do we actually understand the syndrome well enough to say who all the
1576 culprits are?  I know that the NOC does this random shutoff thing, and
1577 I think I remember hearing that there was a hardware bug on our side;
1578 is there also, for example, a software problem in the IMP that causes
1579 this?  The reason I ask is that we (well, MIT, or DARPA, or somebody)
1580 pay lots of money for the IMP ports, and if the NOC is shutting off
1581 our service because their software can't cope, I think we can
1582 legitimately give them some grief in the formal sense.  If it's just a
1583 stupid reaction on their part to a bug (hardware/software,
1584 our/DEC's/ACC's fault, I don't care), I guess we have to live with it.
1585
1586 If this is BBN's fault beyond the NOC lossage, I think we should kick
1587 them, hard.  Hell, maybe we should call our congresscritters and
1588 complain about government waste due to incompetant contractors.
1589 \1f
1590 Date: Sun, 29 Jan 89 18:04:44 EST
1591 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1592 To: ALAN@AI.AI.MIT.EDU
1593 cc: BUG-ITS@AI.AI.MIT.EDU
1594 Message-ID: <528214.890129.ZVONA@AI.AI.MIT.EDU>
1595
1596 Oh.  Giving the NOC a hard time is a fine reason; I just didn't know that
1597 there was one.
1598 \1f
1599 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 29 Jan 89 17:58:59 EST
1600 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
1601 Date: Sun, 29 Jan 89 17:57 EST
1602 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1603 To: ZVONA@AI.AI.MIT.EDU
1604 cc: BUG-ITS@AI.AI.MIT.EDU
1605 In-Reply-To: <528036.890128.ZVONA@AI.AI.MIT.EDU>
1606 Message-ID: <19890129225728.2.ALAN@PIGPEN.AI.MIT.EDU>
1607
1608     Date: Sat, 28 Jan 89 22:47:32 EST
1609     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1610     I've deleted ai:sys;net mail a couple times, because I don't think
1611     people need to be told again the gory details of how the NOC is losing
1612     and like that.  Somone restored it each time.  Is there a good reason
1613     for this?
1614
1615 The reason is that I'm pissed at the NOC for making it even less likely
1616 that anyone besides me will bring MC up when it crashes.  It makes me feel
1617 better to publicize their foolishness this way.  I think you have to put up
1618 with it because I do backups, and if I get pushed too hard I may stop doing
1619 that.
1620 \1f
1621 Date: Sat, 28 Jan 89 22:47:32 EST
1622 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1623 To: BUG-ITS@AI.AI.MIT.EDU
1624 Message-ID: <528036.890128.ZVONA@AI.AI.MIT.EDU>
1625
1626 I've deleted ai:sys;net mail a couple times, because I don't think
1627 people need to be told again the gory details of how the NOC is losing
1628 and like that.  Somone restored it each time.  Is there a good reason
1629 for this?
1630 \1f
1631 Date: Tue, 17 Jan 89 18:19:51 EST
1632 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1633 To: BUG-ITS@AI.AI.MIT.EDU
1634 Message-ID: <521426.890117.ZVONA@AI.AI.MIT.EDU>
1635
1636 AI wasn't talking to the net at all, in or out; Finger for instance
1637 complained that all sockets were in use.  I reset it with lock.
1638 \1f
1639 Received: from PIGPEN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 JAN 89  15:58:22 EST
1640 Date: Mon, 16 Jan 89 15:50 EST
1641 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1642 Subject: Unibus Chaosnet board...
1643 To: ROLL@KICKI.STACKEN.KTH.SE
1644 cc: bug-its@AI.AI.MIT.EDU
1645 In-Reply-To: <12462000174.22.411.4820@KICKI.STACKEN.KTH.SE>
1646 Message-ID: <19890116205029.5.ALAN@PIGPEN.AI.MIT.EDU>
1647
1648     Date: 12-Jan-89 18:11:30 +0100
1649     From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1650
1651
1652     There are tre banks of DIP-switches, what do they do?
1653        --------
1654
1655 Presumably two of them are network and host address.  These two should be
1656 right next to eachother, if I recall correctly.  The third must be the
1657 interrupt address.
1658
1659 Take a look at SYSTEM;KSNET >.  Since you can read the network address back
1660 from the board, you should be able to figure out what switches do what by
1661 plugging it in to some machine and playing with it.
1662 \1f
1663 Date: Fri, 13 Jan 89 22:19:19 EST
1664 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1665 Subject: Don't try this at home!
1666 To: BUG-ITS@AI.AI.MIT.EDU
1667 Message-ID: <519854.890113.ALAN@AI.AI.MIT.EDU>
1668
1669 If you tell ITS that your terminal has 8 columns or less, then when a
1670 **MORE** break happens ITS will try to continue the "**MORE**" onto
1671 the next line by doing "!<cr><lf>".  But (you guessed it) the <lf>
1672 causes a **MORE** break!  The result is a PDL overflow in Exec mode, and
1673 a crashed ITS.  See AI:CRASH;CRASH MORE for an example of this.
1674 \1f
1675 Date: Fri, 13 Jan 89 03:00:11 EST
1676 From: Charles Frankston <CBF@AI.AI.MIT.EDU>
1677 Subject: Re: Chaosnet through Internet.
1678 To: JNC@XX.LCS.MIT.EDU
1679 cc: BUG-ITS@AI.AI.MIT.EDU, JMR@KICKI.STACKEN.KTH.SE
1680 Message-ID: <519167.890113.CBF@AI.AI.MIT.EDU>
1681
1682 We did run chaos packets through the Internet from Livermore to MIT.  I
1683 think a total of about 10 packets were exchanged since we found that the
1684 fixed Chaos timeouts were ill-suited to the cross country delays and the
1685 accumulated retransmisson packets tickled bugs that caused XX's front end
1686 to crash.  EAK was doing the Livermore end and I think JTW hacked XX's
1687 front end.
1688 \1f
1689 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Jan 89 12:27:56 EST
1690 Received: from KICKI.STACKEN.KTH.SE by XX.LCS.MIT.EDU with TCP/SMTP; Thu 12 Jan 89 12:19:21-EST
1691 Address: "PoBox:36041, SE-100 71  Stockholm, SWEDEN"
1692 Organization: Stacken Computer Club
1693 Telephone: +46-8-669 9720
1694 Date: 12-Jan-89 18:11:30 +0100
1695 From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1696 To: bug-its@ai.ai.mit.edu
1697 Subject: Unibus Chaosnet board...
1698 Message-ID: <12462000174.22.411.4820@KICKI.STACKEN.KTH.SE>
1699
1700
1701 There are tre banks of DIP-switches, what do they do?
1702    --------
1703
1704 \1f
1705 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Jan 89 16:17:57 EST
1706 Date: Tue 10 Jan 89 16:09:22-EST
1707 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
1708 Subject: Re: Chaosnet through Internet.
1709 To: JMR@KICKI.STACKEN.KTH.SE, bug-its@AI.AI.MIT.EDU
1710 cc: JNC@XX.LCS.MIT.EDU
1711 In-Reply-To: <12461385557.1.2.79320@KICKI.STACKEN.KTH.SE>
1712 Message-ID: <12461508265.16.JNC@XX.LCS.MIT.EDU>
1713
1714         Ahhh, you don't want to know about this. At one point there was a
1715 discussion on using the IP packet protocol to carry around CHAOS streams.
1716 There was never a final, definite scheme on how to do this, although I think
1717 some kludges were in use.
1718         The rationale was that people would be able to get to a larger number
1719 of machines if you starting using IP packets, and it wouldn't be a major
1720 change. However, the interactions between 'pure' CHAOS machines and machines
1721 using CHAOS wrapped in IP can become tricky. (E.g. how does a 'pure' machine
1722 address a machine with a different high order IP address; 16 bit addresses
1723 don't map into 32 bits.) If you *really* care about this, some old stuff is
1724 online on ML:JNC;CHAOS IN and CHAOS2 *.
1725
1726         If you want to string a line between your CHAOS net and MIT's, fine,
1727 you might want to allocate subnet numbers from the MIT space. If you're going
1728 through the Internet, use TCP/IP - it almost works.
1729
1730         Noel
1731 -------
1732 \1f
1733 Received: from KICKI.STACKEN.KTH.SE (TCP 20273365334) by AI.AI.MIT.EDU 10 Jan 89 04:01:37 EST
1734 Date: 10-Jan-89  9:55:18 +0100
1735 From: Jan Michael Rynning <JMR@KICKI.STACKEN.KTH.SE>
1736 To: bug-its@ai.ai.mit.edu
1737 Subject: Chaosnet through Internet.
1738 Message-ID: <12461385557.1.2.79320@KICKI.STACKEN.KTH.SE>
1739
1740
1741 > Date: Sun, 8 Jan 89 15:17 EST
1742 > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1743 >
1744 > No.  Chaosnet does not bridge through Internet.
1745
1746 So, what's this?  (From RFC 1010 (assigned numbers)):
1747
1748 PROTOCOL NUMBERS
1749
1750    In the Internet Protocol (IP) [36,80] there is a field, called
1751    Protocol, to identify the the next level protocol.  This is an 8 bit
1752    field.
1753
1754    Assigned Internet Protocol Numbers
1755
1756       Decimal    Keyword     Protocol                         References
1757       -------    -------     --------                         ----------
1758 ...
1759           16     CHAOS       Chaos                                 [NC3]
1760    --------
1761
1762 \1f
1763 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  9 Jan 89 08:30:08 EST
1764 Received: from KICKI.STACKEN.KTH.SE by XX.LCS.MIT.EDU with TCP/SMTP; Mon 9 Jan 89 08:22:21-EST
1765 Address: "PoBox:36041, SE-100 71  Stockholm, SWEDEN"
1766 Organization: Stacken Computer Club
1767 Telephone: +46-8-669 9720
1768 References: Message from bug-its@AI.AI.MIT.EDU of  9-Jan-89 14:16:23
1769 In-reply-to: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
1770 Date:  9-Jan-89 14:23:39 +0100
1771 From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1772 To: bug-its@AI.AI.MIT.EDU
1773 Subject: Re: Chaos-net adresses
1774 Message-ID: <12461172265.28.2.91760@KICKI.STACKEN.KTH.SE>
1775
1776 foo
1777 roll@kicki.stacken.kth.se
1778
1779 Date: Sun, 8 Jan 89 15:17 EST
1780 Cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1781 To: Peter Lothberg <ROLL@kicki.stacken.kth.se>
1782 From: bug-its@AI.AI.MIT.EDU
1783 Subject: Chaos-net adresses
1784 Message-Id: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
1785
1786 >    Date:  8-Jan-89 15:38:08 +0100
1787 >    From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1788 >
1789 >    1,)  How do i set up the chaos net (unibus) board adress, i has no HW doc.
1790 >
1791 >Use the pair of DIP switches.  I don't think there ever was any documentation
1792 >other than the print set.  Did you not get a print set?
1793
1794 No, i did not get the print set for the Unibus board, i did get a drawing for
1795 the the Cardr board.
1796
1797 >    2,)  Do we need to coordinate the chaos-host numbers with the other chaos
1798 >     based hosts @ mit, when (if) we get our KS-ITS to talk to Internet?
1799 >
1800 >No.  Chaosnet does not bridge through Internet.
1801 >
1802 >     If we have to cordinate, if i got this right, i need a subnet here?
1803 >     (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6)
1804
1805 My thought, was, if it hapens in the future, that we get a bridge somehow,
1806 to the MIT-Chaos, it might be clever to chose a subnet not in use.
1807
1808 A lesson i learned from the work with the Nordical-Internet implementation
1809 was, 'do it right the first time if possible'.
1810
1811 -peter
1812
1813    --------
1814
1815 \1f
1816 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU  8 Jan 89 20:40:00 EST
1817 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
1818 Date: Sun, 8 Jan 89 15:17 EST
1819 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1820 Subject: Chaos-net adresses
1821 To: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1822 cc: bug-its@AI.AI.MIT.EDU
1823 In-Reply-To: <12460923678.29.411.15980@KICKI.STACKEN.KTH.SE>
1824 Message-ID: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
1825
1826     Date:  8-Jan-89 15:38:08 +0100
1827     From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1828
1829     1,)  How do i set up the chaos net (unibus) board adress, i has no HW doc.
1830
1831 Use the pair of DIP switches.  I don't think there ever was any documentation
1832 other than the print set.  Did you not get a print set?
1833
1834     2,)  Do we need to coordinate the chaos-host numbers with the other chaos
1835          based hosts @ mit, when (if) we get our KS-ITS to talk to Internet?
1836
1837 No.  Chaosnet does not bridge through Internet.
1838
1839          If we have to cordinate, if i got this right, i need a subnet here?
1840          (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6)
1841
1842 You need a subnet number for each chaos cable you have.  People whose cables
1843 aren't connected by bridges don't have to coordinate their subnet numbers.
1844 I'd guess that you have one cable and no bridges, so you need one subnet
1845 number.  May as well use 1.
1846
1847 You may have to purge MIT chaosnet addresses out of your host tables, if
1848 you got your host tables by copying the MIT ones.  Otherwise SI might think
1849 it can talk to AI via Chaosnet instead of Internet.
1850 \1f
1851 Received: from KICKI.STACKEN.KTH.SE (TCP 20273365334) by AI.AI.MIT.EDU  8 Jan 89 09:44:14 EST
1852 Address: "PoBox:36041, SE-100 71  Stockholm, SWEDEN"
1853 Organization: Stacken Computer Club
1854 Telephone: +46-8-669 9720
1855 Date:  8-Jan-89 15:38:08 +0100
1856 From: Peter Lothberg <ROLL@KICKI.STACKEN.KTH.SE>
1857 To: bug-its@ai.ai.mit.edu
1858 Subject: Chaos-net adresses
1859 Message-ID: <12460923678.29.411.15980@KICKI.STACKEN.KTH.SE>
1860
1861
1862 1,)  How do i set up the chaos net (unibus) board adress, i has no HW doc.
1863 2,)  Do we need to coordinate the chaos-host numbers with the other chaos
1864      based hosts @ mit, when (if) we get our KS-ITS to talk to Internet?
1865
1866      If we have to cordinate, if i got this right, i need a subnet here?
1867      (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6)
1868
1869 -peter
1870    --------
1871
1872 \1f
1873 Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 10 Nov 88 19:27:54 EST
1874 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
1875 Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
1876  5320; Thu, 10 Nov 88 19:22:28 EST
1877 Received: from kth.se by KTH-BITNET-GATEWAY ; 10 Nov 88 23:39:47 GMT
1878 Received: from KICKI.STACKEN.KTH.SE by kth.se (5.57+IDA+KTH/3.0)
1879         id AA13586; Fri, 11 Nov 88 00:39:36 +0100
1880 Address: "PoBox:36041, SE-100 71  Stockholm, SWEDEN"
1881 Organization: Stacken Computer Club
1882 Date: 11-Nov-88  0:39:51 +0100
1883 From: Peter_Lothberg <ROLL%SESTAK.BITNET@MITVMA.MIT.EDU>
1884 To: bug-its@ai.ai.mit.edu
1885 Subject: The container and MX
1886 Message-Id: <12445555798.20.2.175672@KICKI.STACKEN.KTH.SE>
1887
1888
1889 Arrived to Stockholm and we unpacked the container on wendsday.
1890
1891 The container has, sure shaked, the cardboard paper that we put between
1892 the cabinets, has bloue spots.....
1893
1894 But, everything was in the same position that we left it, so, hopfully
1895 it is not hurt by the transport, or the cold here.
1896
1897 We have put the machine on several places, while we are waiting for
1898 our new machine room to be completed.
1899
1900 My preliminary shedule is, to have it run by end of march.
1901
1902 -peter
1903
1904    --------
1905
1906 \1f
1907 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 26 Oct 88 23:45:34 EDT
1908 Date: Wed 26 Oct 88 23:42:03-EDT
1909 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
1910 To: Moon@STONY-BROOK.SCRC.Symbolics.COM, ZVONA@AI.AI.MIT.EDU
1911 cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
1912 In-Reply-To: <19881022002858.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
1913 Message-ID: <12441656808.31.JNC@XX.LCS.MIT.EDU>
1914
1915         It's actually in the back, inside the cabinet, on the CPU card,
1916 as I recall. (It might be next to the power switch, if I'm suffering
1917 brain fade.) However, it is in the back on the C/30's....
1918         The right thing is actually to call the NOC; they keep stats
1919 on the number of random restarts to highlight problem hardware, and
1920 pushing the button a lot could get us a new box, all full of new bugs...
1921
1922         Noel
1923 -------
1924 \1f
1925 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 24 Oct 88 15:48:43 EDT
1926 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
1927 Date: Mon, 24 Oct 88 15:46 EDT
1928 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1929 Subject: MC
1930 To: David Chapman <ZVONA@AI.AI.MIT.EDU>
1931 cc: BUG-ITS@AI.AI.MIT.EDU
1932 In-Reply-To: <470732.881024.ZVONA@AI.AI.MIT.EDU>
1933 Message-ID: <19881024194656.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
1934
1935     Date: Mon, 24 Oct 88 14:46:59 EDT
1936     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1937
1938     For what it's worth, I'm in favor of an immediate CPU swap.
1939
1940 Maybe the problem is the power supply, not the boards.  The errors
1941 it's getting are "impossible" in most cases, unless we are misreading
1942 the documentation.  Swapping the CPU might only make things worse.
1943 \1f
1944 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 Oct 88 15:29:27 EDT
1945 Date: Mon 24 Oct 88 15:26:16-EDT
1946 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
1947 To: ZVONA@AI.AI.MIT.EDU
1948 cc: BUG-ITS@AI.AI.MIT.EDU
1949 In-Reply-To: <470732.881024.ZVONA@AI.AI.MIT.EDU>
1950 Message-ID: <12441042264.12.SRA@XX.LCS.MIT.EDU>
1951
1952     Date: Mon, 24 Oct 88 14:46:59 EDT
1953     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1954
1955     MC wasn't talking to the net for 34 hours because people kept booting
1956     it without fixing the IMP problem.  I left a note on the console
1957     explaining how to win.
1958
1959     As a result, LISTS MSGS is over 2000 blocks again.
1960
1961     For what it's worth, I'm in favor of an immediate CPU swap.
1962
1963 Since BBN has admitted that at least some of this is their fault (IMP
1964 software), a CPU swap wouldn't solve the urgent problem.
1965
1966 The problem with swapping CPUs to "fix" the PAR ERR bug is that it
1967 would not solve the real problem (one of the KS CPUs being broken) but
1968 would remove the immediate cause for fixing the real problem.  Sad but
1969 true.
1970 -------
1971 \1f
1972 Date: Mon, 24 Oct 88 14:46:59 EDT
1973 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1974 To: BUG-ITS@AI.AI.MIT.EDU
1975 Message-ID: <470732.881024.ZVONA@AI.AI.MIT.EDU>
1976
1977 MC wasn't talking to the net for 34 hours because people kept booting
1978 it without fixing the IMP problem.  I left a note on the console
1979 explaining how to win.
1980
1981 As a result, LISTS MSGS is over 2000 blocks again.
1982
1983 For what it's worth, I'm in favor of an immediate CPU swap.
1984 \1f
1985 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 21 Oct 88 20:30:04 EDT
1986 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
1987 Date: Fri, 21 Oct 88 20:28 EDT
1988 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1989 To: David Chapman <ZVONA@AI.AI.MIT.EDU>
1990 cc: BUG-ITS@AI.AI.MIT.EDU
1991 In-Reply-To: <469253.881021.ZVONA@AI.AI.MIT.EDU>
1992 Message-ID: <19881022002858.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
1993
1994     Date: Fri, 21 Oct 88 16:05:33 EDT
1995     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1996
1997     MC isn't talking to the arpanet.  Powercycling doesn't help.  I gather this
1998     means I need to boot the IMP.  I dunno how.  Can someone show me?  (I can't
1999     find anyone around now.)
2000
2001 Push the boot button on the front of the IMP (maybe it's labelled Reset).
2002 Then wait an hour.
2003 \1f
2004 Date: Fri, 21 Oct 88 17:20:59 EDT
2005 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2006 To: LIAISON@AI.AI.MIT.EDU
2007 cc: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2008 Message-ID: <469383.881021.CENT@AI.AI.MIT.EDU>
2009
2010     Date: Fri, 21 Oct 88 16:05:33 EDT
2011     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
2012     To: BUG-ITS@AI.AI.MIT.EDU
2013     MC isn't talking to the arpanet.  Powercycling doesn't help.  I gather
2014     this means I need to boot the IMP.  I dunno how.  Can someone show me?
2015     (I can't find anyone around now.)
2016
2017 i looked at the LH/DH lights, decided they indicated IMP wedgitude, and
2018 called the NOC, after Ty checked and found that XX (@ 0/44) was having no
2019 problems. the nice man (norm, i think he said) there put 3/44 into and out
2020 of loopback, and then once i ran NET in LOCK to impulse MC, we had arpanet
2021 again.
2022    the guy at BBN claimed that we are not the only people having this
2023 problem, that it seems to be cropping up in several places all over, and
2024 that it appears therefore to be software. i gather They Are Working On It.
2025 i gave him MAP's name as the official administrator here. he said that the
2026 next the this happens, we should try to call as soon as possible so they
2027 can try to catch it before it reaches the steady-state wedgedness, and thus
2028 perhaps learn something. the NOC is at 873-3070.
2029 \1f
2030 Date: Fri, 21 Oct 88 16:05:33 EDT
2031 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
2032 To: BUG-ITS@AI.AI.MIT.EDU
2033 Message-ID: <469253.881021.ZVONA@AI.AI.MIT.EDU>
2034
2035 MC isn't talking to the arpanet.  Powercycling doesn't help.  I gather this
2036 means I need to boot the IMP.  I dunno how.  Can someone show me?  (I can't
2037 find anyone around now.)
2038 \1f
2039 Date: Thu, 20 Oct 88 22:42:07 EDT
2040 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2041 Subject: state of ML
2042 To: marilyn@WHEATIES.AI.MIT.EDU
2043 cc: BUG-ITS@AI.AI.MIT.EDU
2044 Message-ID: <468866.881020.CENT@AI.AI.MIT.EDU>
2045
2046 alan said that last week he had you generate a repair PO for ML's disk
2047 drive, which was broken. when he called DEC back on sunday to complain that
2048 they had in fact not fixed the disk, he got the impression that DEC thought
2049 that last week's PO had been closed already. as of now, DEC is -still-
2050 working on that disk, and the latest notes they left to each other do not
2051 boost my confidence, as they suggest that in trying to use MD to help fix
2052 ML's disk, they broke MD's disk as well. if at some point they actually fix
2053 these things so they are really fixed, they may want another PO for the
2054 work this week. in which case we get to generate another repair PO. alan is
2055 on vacation and will return sometime next week; if this needs to be acted
2056 upon before then, i'll do it.  note that AI should not be charged for any
2057 work to fix MD, which is LCS, and it's my guess that LCS shouldn't be
2058 charged for fixing MD either, since the Men From DEC say -they- broke it.
2059 \1f
2060 Date: Tue, 18 Oct 88 02:18:43 EDT
2061 From: "Christopher C. Stacy" <CSTACY@AI.AI.MIT.EDU>
2062 To: BUG-ITS@AI.AI.MIT.EDU
2063 Message-ID: <465449.881018.CSTACY@AI.AI.MIT.EDU>
2064
2065 Someone seems to have deleted the default DDT init file
2066 from AI's USERSn directories.  So I put them back.
2067 \1f
2068 Date: Tue, 18 Oct 88 01:12:33 EDT
2069 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2070 Subject: mc fall down go boom again
2071 To: BUG-ITS@AI.AI.MIT.EDU
2072 Message-ID: <465405.881018.CENT@AI.AI.MIT.EDU>
2073
2074 it crashed again, after alan had gone home. so i trucked upstairs to
2075 discover the same old bogus ?PAR ERR msg. i read the lights off the
2076 ACC box over the phone to alan, and he claims that the way the second
2077 row did not clear indicates that the problem has not been solved by
2078 swapping LH/DHs. in other words, the LH/DHs are not at fault. MC is
2079 currently up but not talking to the arpanet.
2080 \1f
2081 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Oct 88 23:29:41 EDT
2082 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
2083 Date: Mon, 17 Oct 88 23:28 EDT
2084 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
2085 Subject: Vacation.
2086 To: Bug-MAIL@AI.AI.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU
2087 Message-ID: <19881018032823.2.ALAN@OTIS.AI.MIT.EDU>
2088
2089 Due to the lossage with MC, there are a few things that I have done that
2090 you might all need to know about.  Especially since I'll be out of town
2091 this from this Wednesday through next Monday.
2092
2093 1.  I have swapped AI and MC's LH/DH-11s to see if this has any effect on
2094 the problem with the MC's IMP port.
2095
2096 2.  I have left COMSAT on MC running in hyper-active mode.  That is, I have
2097 patched all of its timeouts to very small values.  This makes COMSAT eat
2098 new mail faster, so that people who haven't been able to talk to MC for
2099 days have a better chance of delivering new mail before timing out.  Of
2100 course the flip side of this is that MC is growing a rather large queue of
2101 mail it hasn't been able to deliver.
2102
2103 The COMSAT PDUMP file (COMSAT LAUNCH) has the fast timeouts, but the SBLK
2104 file (COMSAT IV) does not.  So if it becomes necessary to undo what I have
2105 done, you should:  [a] notice that the files on .MAIL. are all links to the
2106 corresponding files on .BULK., [b] load .BULK.;COMSAT IV into a job (J$J
2107 $L .BULK.;COMSAT IV), [c] start it at PURIFY (PURIFY$G), and [d] put the
2108 resulting PDUMP file into .BULK.;COMSAT LAUNCH (which is -not- the default
2109 you will be offered!  Use delete, or type $ to change the offered
2110 default.).
2111
2112 3.  I have changed the algorithm employed by the SMTP and Chaos MAIL
2113 servers to decide whether or not to accept new MAIL > files.  The previous
2114 code tried to limit the number of MAIL files to 30.  The new code looks at
2115 the .MAIL. directory and computes how full it is and refuses new MAIL >
2116 files if it is more than 75% full.
2117
2118 If this has any bad effects, you can retract it by renaming
2119 DEVICE;CHAOS OMAIL to be DEVICE;CHAOS MAIL and renaming SYSBIN;FTPS OBIN to
2120 be SYSBIN;FTPS BIN.
2121 \1f
2122 Received: from ames.arc.nasa.gov (TCP 20031411003) by AI.AI.MIT.EDU  6 Oct 88 12:34:47 EDT
2123 Received: Thu, 6 Oct 88 09:23:05 PDT by ames.arc.nasa.gov (5.59/1.2)
2124 Date: Thu, 6 Oct 88 09:24:05 PST
2125 From: geoff@Fernwood.MPK.CA.US (the tty of Geoff Goodfellow)
2126 Subject: Re: License plate curiosity...
2127 Message-Id: <8810060924.2.UUL1.3#948@Fernwood.MPK.CA.US>
2128 To: Ed@ALDERAAN.SCRC.Symbolics.COM
2129 Cc: tops-20@score.stanford.edu, info-its@ai.ai.mit.edu, hic@symbolics.com,
2130         pgs@ai.ai.mit.edu, gls@think.com, vaf@score.stanford.edu
2131 In-Reply-To: Your message of Wed 5 Oct 88 17:27:28-PDTFrom: Vince Fuller <VAF@Score.Stanford.EDU>
2132
2133 i still have California JFCL.
2134 i believe JRST 4 belongs to Ken Olum (kdo@lucid.com).
2135 g
2136
2137 \1f
2138 Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU  6 Oct 88 12:05:10 EDT
2139 Return-Path: <barmar@Think.COM>
2140 Received: from sauron.think.com by Think.COM; Thu, 6 Oct 88 11:16:46 EDT
2141 Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 6 Oct 88 12:00:28 EDT
2142 Date: Thu, 6 Oct 88 12:01 EDT
2143 From: Barry Margolin <barmar@Think.COM>
2144 Subject: License plate curiosity...
2145 To: Ed Schwalenberg <Ed@alderaan.scrc.symbolics.com>
2146 Cc: Vince Fuller <VAF@score.stanford.edu>, tops-20@score.stanford.edu,
2147         info-its@ai.ai.mit.edu, geoff@fernwood.mpk.ca.us,
2148         hic@alderaan.scrc.symbolics.com, pgs@ai.ai.mit.edu, gls@Think.COM
2149 In-Reply-To: <19881006144203.6.ED@BLACK-BIRD.SCRC.Symbolics.COM>
2150 Message-Id: <19881006160115.7.BARMAR@OCCAM.THINK.COM>
2151
2152 A couple of weeks ago I was walking through the Lotus parking lot by
2153 Cambridge Gas & Electric and saw the license plate CAR-CDR.  Anyone know
2154 whose this is?
2155
2156                                                 barmar
2157 \1f
2158 Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 20024224555) by AI.AI.MIT.EDU  6 Oct 88 10:44:15 EDT
2159 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
2160 Date: Thu, 6 Oct 88 10:42 EDT
2161 From: Ed Schwalenberg <Ed@ALDERAAN.SCRC.Symbolics.COM>
2162 Subject: License plate curiosity...
2163 To: Vince Fuller <VAF@Score.Stanford.EDU>
2164 cc: tops-20@Score.Stanford.EDU, info-its@AI.AI.MIT.EDU, geoff@fernwood.mpk.ca.us,
2165     hic@ALDERAAN.SCRC.Symbolics.COM, pgs@AI.AI.MIT.EDU, gls@think.com
2166 In-Reply-To: <12436116360.19.VAF@Score.Stanford.EDU>
2167 Message-ID: <19881006144203.6.ED@BLACK-BIRD.SCRC.Symbolics.COM>
2168
2169     Date: Wed 5 Oct 88 17:27:28-PDT
2170     From: Vince Fuller <VAF@Score.Stanford.EDU>
2171
2172     The other day I saw a California licence plate that read "JRST 4" (I guess you
2173     can't get commas on licence plates...). Out of curiosity, who is the owner of
2174     this plate?
2175
2176             --Vince
2177     -------
2178
2179 Hmm.  I thought this was Geoff Goodfellow's, but SAIL:AIWORD.RF[UP,DOC]
2180 tells me he has JFCL.
2181
2182 HIC got Massachusetts HLRZ (the PDP-10 instruction that implements
2183 the "car" operation of Lisp); I believe this vehicle and plate is
2184 still around in the possession of PGS.
2185
2186 I had FOOBAR in Nevada and later in Massachusetts; I still have
2187 the physical plates from Nevada, though the vehicle which wore
2188 both sets is long since deceased.
2189
2190 There used to be a rather extensive discussion of this stuff in the
2191 jargon file(s), but it seems to have evaporated, except for the single
2192 note about JFCL.
2193 \1f
2194 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  5 Oct 88 21:09:41 EDT
2195 Return-Path: <VAF@Score.Stanford.EDU>
2196 Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 5 Oct 88 20:36:04-EDT
2197 Date: Wed 5 Oct 88 17:27:28-PDT
2198 From: Vince Fuller <VAF@Score.Stanford.EDU>
2199 Subject: License plate curiosity...
2200 To: tops-20@Score.Stanford.EDU
2201 Office: Pine Hall 167
2202 Phone:  415-723-6860
2203 Message-ID: <12436116360.19.VAF@Score.Stanford.EDU>
2204 ReSent-Date: Wed 5 Oct 88 21:06:17-EDT
2205 ReSent-From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2206 ReSent-To: info-its@AI.AI.MIT.EDU
2207 ReSent-Message-ID: <12436123427.45.SRA@XX.LCS.MIT.EDU>
2208
2209 The other day I saw a California licence plate that read "JRST 4" (I guess you
2210 can't get commas on licence plates...). Out of curiosity, who is the owner of
2211 this plate?
2212
2213         --Vince
2214 -------
2215 \1f
2216 Date: Wed,  5 Oct 88 14:23:26 EDT
2217 From: Rob Austein <SRA@AI.AI.MIT.EDU>
2218 Subject:  TCP/IP ior IMP weirdness
2219 To: BUG-ITS@AI.AI.MIT.EDU
2220 Message-ID: <457481.881005.SRA@AI.AI.MIT.EDU>
2221
2222 I got a call from BBN asking me to check out MC because they said it
2223 had first crashed then started spitting garbage onto its IMP (sic).
2224 The call was to tell me that until they hear further from us they will
2225 leave MC's port in loopback mode to keep from trashing the rest of the
2226 net.
2227
2228 I found MC crashed with several messages from last night about the IMP
2229 crashing and the IMP interface being reset followed by:
2230
2231 IMP: Interface reset
2232 PK: Node already on list
2233
2234 and a PI 7 BUGHALT.  There were no times on the last two message.
2235 Dump in CRASH; TCP.PK BUGHLT.  Reloaded ok except that now it can't
2236 talk to the net, presumably because BBN still has the IMP in loopback.
2237 I'm going to try to get them to undo that now....
2238 \1f
2239 Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU  3 Oct 88 15:46:16 EDT
2240 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
2241 Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
2242  0400; Mon, 03 Oct 88 15:33:45 EDT
2243 Received: from kth.se by KTH-BITNET-GATEWAY ; 03 Oct 88 19:11:10 GMT
2244 Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0)
2245         id AA18632; Mon, 3 Oct 88 20:10:59 +0100
2246 Date: Mon,  3 Oct 88 20:12:22 +0100
2247 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg)
2248 To: bug-its@ai.ai.mit.edu
2249 Subject: subnet 6
2250 Message-Id: <340A6Z@KICKI.STACKEN.KTH.SE>
2251
2252
2253   It might be so that, I did something wrong when we took away MX,
2254   i unplugged the transceivers, both where the KL was, and next to
2255   the chaos-11 3mbit ethernet gateway was. I don't knew if anyone
2256   has checked it out after that.
2257
2258
2259 \1f
2260 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  3 Oct 88 14:27:24 EDT
2261 Date: Mon 3 Oct 88 14:22:46-EDT
2262 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2263 Subject: Re: Chaosnet, hardware
2264 To: JTW@XX.LCS.MIT.EDU
2265 cc: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU, bug-its@AI.AI.MIT.EDU
2266 In-Reply-To: <JTW.12435309099.BABYL@XX.LCS.MIT.EDU>
2267 Message-ID: <12435525680.49.SRA@XX.LCS.MIT.EDU>
2268
2269 If I remember correctly, Moon's original CHAOSNET spec paper did specify
2270 a length limit derived from transmission speed and the retransmission
2271 algorithm.  I haven't read the paper in a long time, so I can't quote
2272 chapter and verse.
2273 -------
2274 \1f
2275 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  3 Oct 88 14:06:55 EDT
2276 Date: Mon 3 Oct 88 14:02:33-EDT
2277 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2278 Subject: Agre's dropped tty problems
2279 To: agre@wheaties.ai.mit.edu
2280 cc: bug-its@AI.AI.MIT.EDU
2281 In-Reply-To: <8810010048.AA15907@wheat-chex.ai.mit.edu>
2282 Message-ID: <12435522000.49.SRA@XX.LCS.MIT.EDU>
2283
2284 Or maybe it's just that the path from anywhere to subnet 6 is unreliable these
2285 days and sometimes the routing transients cause your packets to fall on the
2286 floor so that either ITS or your Lispm thinks the connection is dead.
2287 -------
2288 \1f
2289 Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU  3 Oct 88 00:52:52 EDT
2290 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
2291 Date: Sun, 2 Oct 88 23:50 CDT
2292 From: David Vinayak Wallace <Gumby@MCC.COM>
2293 Subject: Chaosnet, hardware
2294 To: JTW@XX.LCS.MIT.EDU
2295 cc: Peter Lothberg <ROLL%SESTAK.BITNET@MITVMA.MIT.EDU>, bug-its@AI.AI.MIT.EDU
2296 In-Reply-To: <JTW.12435309099.BABYL@XX.LCS.MIT.EDU>
2297 Message-ID: <881002235013.7.GUMBY@BRAHMA.ACA.MCC.COM>
2298
2299     Date: Sun, 2 Oct 1988  18:33 EDT
2300     From: JTW@XX.LCS.MIT.EDU
2301
2302          Presumably the limit is due to propagation delays screwing up the
2303     collision detection, rather than analog attenuation issues. This being
2304     the case, it should be pretty easy to calculate once you figure out
2305     exactly what a collision is. As a practical matter our subnet 1 was
2306     well over 500m at its peak, I think.
2307
2308 The Chaosnet Memo said that the limit was around 1KM for the reason you
2309 said.
2310 \1f
2311 Date: Sun,  2 Oct 88 21:58:54 EDT
2312 From: "Christopher C. Stacy" <CSTACY@AI.AI.MIT.EDU>
2313 Subject: dropping
2314 To: BUG-ITS@AI.AI.MIT.EDU
2315 cc: AGRE@AI.AI.MIT.EDU
2316 Message-ID: <455274.881002.CSTACY@AI.AI.MIT.EDU>
2317
2318 The 7814 modem randomly dropped me a second ago; when I dialed it back
2319 up again, I was on the same session as before (I wasn't logged out.)
2320 There seemed to be alot of pinegoi&6se on the line too.
2321 \1f
2322 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU  2 Oct 88 18:35:14 EDT
2323 Date: Sun, 2 Oct 1988  18:33 EDT
2324 Message-ID: <JTW.12435309099.BABYL@XX.LCS.MIT.EDU>
2325 From: JTW@XX.LCS.MIT.EDU
2326 To:   ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg)
2327 Cc:   bug-its@AI.AI.MIT.EDU
2328 Subject: Chaosnet, hardware
2329 In-reply-to: Msg of Sun  2 Oct 88 17:14:21 +0100 from ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg)
2330
2331
2332     From: ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg)
2333     Re:   Chaosnet, hardware
2334
2335     What is the electrical characteristics?
2336
2337 75 Ohm coax. Traditionally, solid-sheath CATV cable was used for its
2338 low-loss and shielding properties, but more recently most short runs
2339 were done with boring old RG-59U, which seems to work fine.
2340 Termination is just a 75-ohm non-inductive resistor on each end.
2341
2342 I've never seen any commentary on theoretical length limits, but
2343 perhaps someone who was around when it was designed will have more to
2344 say. Presumably the limit is due to propagation delays screwing up the
2345 collision detection, rather than analog attenuation issues. This being
2346 the case, it should be pretty easy to calculate once you figure out
2347 exactly what a collision is. As a practical matter our subnet 1 was
2348 well over 500m at its peak, I think.
2349 \1f
2350 Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU  2 Oct 88 12:20:18 EDT
2351 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
2352 Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
2353  2538; Sun, 02 Oct 88 12:17:49 EDT
2354 Received: from kth.se by KTH-BITNET-GATEWAY ; 02 Oct 88 16:14:10 GMT
2355 Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0)
2356         id AA04756; Sun, 2 Oct 88 17:13:56 +0100
2357 Date: Sun,  2 Oct 88 17:14:21 +0100
2358 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg)
2359 To: bug-its@ai.ai.mit.edu
2360 Subject: Chaosnet, hardware
2361 Message-Id: <5401T5@KICKI.STACKEN.KTH.SE>
2362
2363 What is the electrical characteristics?
2364
2365         Cable impendance?
2366         Maximal cable lenght?
2367         Terminators?
2368
2369
2370
2371 \1f
2372 Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 30 Sep 88 23:08:46 EDT
2373 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
2374 Date: Fri, 30 Sep 88 21:58 CDT
2375 From: David Vinayak Wallace <Gumby@MCC.COM>
2376 Subject: foo
2377 To: Alan Bawden <Alan@AI.AI.MIT.EDU>
2378 cc: agre@WHEATIES.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU
2379 In-Reply-To: <19881001013734.1.ALAN@PIGPEN.AI.MIT.EDU>
2380 Message-ID: <880930215803.1.GUMBY@BRAHMA.ACA.MCC.COM>
2381
2382     Date: Fri, 30 Sep 88 21:37 EDT
2383     From: Alan Bawden <Alan@AI.AI.MIT.EDU>
2384
2385     (It is a weird phenomenon that people always blame the machine at the
2386     farthest end of a network connection first.  I've seen people go and boot
2387     AI because their terminal concentrator crashed.)
2388
2389 Yea, I once booted XX because the IRS lost my tax rebate
2390 \1f
2391 Received: from wheat-chex.ai.mit.edu (TCP 20015023057) by AI.AI.MIT.EDU 30 Sep 88 22:05:22 EDT
2392 Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 21:56:44 EDT
2393 Date: Fri, 30 Sep 88 21:56:44 EDT
2394 From: agre@wheaties.ai.mit.edu (Philip E. Agre)
2395 Message-Id: <8810010156.AA16581@wheat-chex.ai.mit.edu>
2396 To: Alan@ai.ai.mit.edu
2397 Subject: Re:  foo
2398 Cc: bug-its@ai.ai.mit.edu
2399
2400 That's probably because networks are supposed to be transparent.
2401 Even when they break it doesn't immediately come to mind that they
2402 even exist.  But then people don't usually clean off the world when
2403 their glasses get dirty.
2404 \1f
2405 Received: from PIGPEN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 SEP 88  21:46:45 EDT
2406 Date: Fri, 30 Sep 88 21:37 EDT
2407 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
2408 Subject: foo
2409 To: agre@WHEATIES.AI.MIT.EDU
2410 cc: bug-its@AI.AI.MIT.EDU, Gumby@mcc.com
2411 In-Reply-To: <8810010048.AA15907@wheat-chex.ai.mit.edu>
2412 Message-ID: <19881001013734.1.ALAN@PIGPEN.AI.MIT.EDU>
2413
2414     Date: Fri, 30 Sep 88 20:48:48 EDT
2415     From: agre@wheaties.ai.mit.edu (Philip E. Agre)
2416     I talked with Alan about the problem a little and he thinks that AI is
2417     losing all its Chaos connections now and again.
2418
2419 That's not quite what I said.  I think that it is the Chaosnet itself that
2420 is the problem (probably subnet 6 being jammed).  The problem is not AI or
2421 ITS.
2422
2423 (It is a weird phenomenon that people always blame the machine at the
2424 farthest end of a network connection first.  I've seen people go and boot
2425 AI because their terminal concentrator crashed.)
2426 \1f
2427 Received: from wheat-chex.ai.mit.edu (TCP 20015023057) by AI.AI.MIT.EDU 30 Sep 88 20:57:13 EDT
2428 Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:48:48 EDT
2429 Date: Fri, 30 Sep 88 20:48:48 EDT
2430 From: agre@wheaties.ai.mit.edu (Philip E. Agre)
2431 Message-Id: <8810010048.AA15907@wheat-chex.ai.mit.edu>
2432 To: bug-its@ai.ai.mit.edu
2433 Subject: foo
2434
2435 From agre Fri Sep 30 20:47:14 1988
2436 Return-Path: <MAILER-DAEMON@wheaties.ai.mit.edu>
2437 Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:46:33 EDT
2438 Date: Fri, 30 Sep 88 20:46:33 EDT
2439 From: MAILER-DAEMON@wheaties.ai.mit.edu (Mail Delivery Subsystem)
2440 Subject: Returned mail: User unknown
2441 Message-Id: <8810010046.AB15897@wheat-chex.ai.mit.edu>
2442 To: agre
2443 Status: R
2444
2445    ----- Transcript of session follows -----
2446 550 bug-its... User unknown
2447
2448    ----- Unsent message follows -----
2449 Return-Path: <agre@wheaties.ai.mit.edu>
2450 Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:46:33 EDT
2451 Date: Fri, 30 Sep 88 20:46:33 EDT
2452 From: agre@wheaties.ai.mit.edu (Philip E. Agre)
2453 Message-Id: <8810010046.AA15894@wheat-chex.ai.mit.edu>
2454 To: Gumby@mcc.com
2455 Subject: Re:  connectionist problems
2456 Cc: bug-its
2457
2458 1. I am connecting through a telnet window on my lispm.
2459 2. No, nothing about DDT BUG BLAH BLAH
2460 3. I've never had my connection dropped while running any program but DDT.
2461 4. Ditto.
2462 5. Yes, my memory is quite consistent with the policy (which Alan told me
2463    about) of flushing over-an-hour-old detached jobs.
2464
2465 I talked with Alan about the problem a little and he thinks that AI is
2466 losing all its Chaos connections now and again.
2467
2468 \1f
2469 Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 30 Sep 88 19:12:31 EDT
2470 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
2471 Date: Fri, 30 Sep 88 18:01 CDT
2472 From: David Vinayak Wallace <Gumby@MCC.COM>
2473 Subject: connectionist problems
2474 To: Philip E. Agre <AGRE@AI.AI.MIT.EDU>
2475 cc: BUG-ITS@AI.AI.MIT.EDU
2476 In-Reply-To: <453833.880930.AGRE@AI.AI.MIT.EDU>
2477 Message-ID: <880930180110.0.GUMBY@BRAHMA.ACA.MCC.COM>
2478
2479     Date: Fri, 30 Sep 88 15:39:01 EDT
2480     From: "Philip E. Agre" <AGRE@AI.AI.MIT.EDU>
2481
2482     Hi -- AI randomly drops my terminal connection a couple dozen
2483     times a day.  In doing so it sometimes detaches me and sometimes
2484     flushes me altogether.  Am I doing something to bring this on
2485     myself?  If not it would be great if it stopped happening.
2486
2487 o - Are you connecting from a terminal concentrator?  If not, how?
2488 o - When you reconnect, do you get some message from ITS like
2489     "DDT BUG BLAH BLAH?"
2490 o - When you reconnect are you talking to DDT or to the program you were
2491     running when the connexion was dropped?
2492 o - Does this only happen when you're running some particular program?
2493 o - When "it sometimes detaches me and sometimes flushes me altogether"
2494     does it appear that you're logged out only if you wait a while?
2495     ITS's default behaviour is to keep jobs around if the connection is
2496     accidentally dropped, then GC them after a while if you don't
2497     reconnect.
2498
2499 "We need BITS, nothing but BITS" -- Chuck E. Dickens.
2500 \1f
2501 Date: Fri, 30 Sep 88 15:39:01 EDT
2502 From: "Philip E. Agre" <AGRE@AI.AI.MIT.EDU>
2503 To: BUG-ITS@AI.AI.MIT.EDU
2504 Message-ID: <453833.880930.AGRE@AI.AI.MIT.EDU>
2505
2506 Hi -- AI randomly drops my terminal connection a couple dozen
2507 times a day.  In doing so it sometimes detaches me and sometimes
2508 flushes me altogether.  Am I doing something to bring this on
2509 myself?  If not it would be great if it stopped happening.
2510 \1f
2511 Date: Fri, 16 Sep 88 00:16:04 EDT
2512 From: Peter Lothberg <ROLL@AI.AI.MIT.EDU>
2513 Subject: The "crack team", is dissasembling MX, for it's trip to Sweden
2514 To: INFO-ITS@AI.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU
2515 Message-ID: <444460.880916.ROLL@AI.AI.MIT.EDU>
2516
2517
2518 The crack team has begun to work;
2519
2520 A lot of the documentation for MX (KL-10) must be spread out, i
2521 can't find it around the machine.
2522
2523 So all of you that has bits and pices, bring it to the 9:th floor
2524 before sunday, please.
2525
2526
2527 (As the system will not fill the container more than 40% or so,
2528  we vold like donations of other stuff, like Lisp-machines, AAA terminals,
2529  a IMP, Conection machines, retired 2060's etc, (I'm not joking...))
2530
2531 -Peter
2532 \1f
2533 Date: Sun, 11 Sep 88 23:57:48 EDT
2534 From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
2535 Subject:  supdup
2536 To: BUG-ITS@AI.AI.MIT.EDU
2537 Message-ID: <441324.880911.DEVON@AI.AI.MIT.EDU>
2538
2539 Date: Sun, 11 Sep 88 09:39:59 EDT
2540 From: David C. Plummer <DCP at AI.AI.MIT.EDU>
2541 To:   DEVON at AI.AI.MIT.EDU
2542 Re:   supdup
2543
2544     Date: Sun,  4 Sep 88 12:41:31 EDT
2545     From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
2546     Subject:  supdup
2547     To: DCP@AI.AI.MIT.EDU
2548     Message-ID: <437397.880904.DEVON@AI.AI.MIT.EDU>
2549
2550     Many supdup servers around MIT emit %TDBS, which is not in any RFC
2551     I've ever seen, and breaks some user end supdups, such as ITS CRTSTY.
2552     Do you know if anyone has defined a new improved supdup that does
2553     allow %TDBS, and perhaps a few other useful things as well?
2554
2555 I've been away from this kind of stuff for a LONG time.  I'd suggest
2556 asking bug-ITS.
2557 \1f
2558 Date: Fri,  9 Sep 88 22:56:21 EDT
2559 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2560 Subject: return of MD
2561 To: BUG-ITS@AI.AI.MIT.EDU
2562 Message-ID: <440558.880909.CENT@AI.AI.MIT.EDU>
2563
2564 i plugged MD back into the *MSG and INQUPD routines.
2565 \1f
2566 Date: Fri,  9 Sep 88 17:19:49 EDT
2567 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2568 Subject: The end of the world as we used to know it
2569 To: BRAITHWAITE@TOPS20.DEC.COM
2570 cc: BUG-ITS@AI.AI.MIT.EDU
2571 Message-ID: <440394.880909.CENT@AI.AI.MIT.EDU>
2572
2573     Date: 9 Sep 1988 1033-EDT
2574     From: BRAITHWAITE@TOPS20.DEC.COM
2575     To: Rob Austein <SRA@XX.LCS.MIT.EDU>
2576     Subject: Re: [Pandora B. Berman: The end of the world as we used to know it]
2577     ReSent-Date: Fri 9 Sep 88 10:40:40-EDT
2578     ReSent-From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2579     ReSent-To: CENT@XX.LCS.MIT.EDU
2580
2581     for our records --- what is MX's serial number ?
2582        --------
2583 model PDP-1080 (or KL-10A), serial #1038
2584 \1f
2585 Date: Thu,  8 Sep 88 21:39:25 EDT
2586 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2587 Subject: The end of the world as we used to know it
2588 To: (*MSG *ITS)@AI.AI.MIT.EDU, ARPANET-BBOARDS@AI.AI.MIT.EDU,
2589     INFO-ITS@AI.AI.MIT.EDU
2590 Message-ID: <439827.880908.CENT@AI.AI.MIT.EDU>
2591
2592 "The time has come," said LCS,
2593     "MX at last must go.
2594 Its day has gone.  We need that space
2595     Most urgently."  And so
2596 Before we crate it, let us give
2597     A final cheerio.
2598
2599 Once there was a KL-10 called MIT-MC which belonged to the Macsyma
2600 Consortium.  It provided Macsyma, the symbolic algebra system, to
2601 researchers all over the world, and mail gatewaying and mailing list
2602 support to a large fraction of the Arpanet.  Things continued in this
2603 fashion from 1975 to 1983.
2604
2605 When the Macsyma Consortium dissolved in 1983, MC turned to providing
2606 cycles for MIT's Laboratory for Computer Science, and continued supporting
2607 much of the Arpanet's mail service.  But the machine itself was growing old
2608 and cranky.  In 1986, the mail services were moved to a smaller, more
2609 maintainable machine (a KS-10), and the name "MC" was moved with them.
2610 But the KL-10 continued to run under the new name "MX".
2611
2612 Now the end has come.  MX was down cold for several months, and has only
2613 been revived recently to copy some old 7-track tapes.  LCS can't keep MX
2614 any longer -- it needs the space for other purposes.  So the KL is being
2615 sent to the Home for Aged But Beloved PDP-10s; a crack team of hardware
2616 hackers will arrive next week to dismantle it and take it back with them to
2617 Sweden.
2618
2619 In celebration of this momentous event, we are holding a small farewell
2620 gathering:
2621                          Friday, 16 September 1988
2622                                    16:00
2623                           NE43-8th floor playroom
2624                   (545 Technology Square, Cambridge, MA)
2625
2626 Reservations are strenuously requested (though not strictly necessary) --
2627 we need a head count so we can figure out how many trays of institutional
2628 brownies to order.  Send yours to:
2629                             CENT@AI.AI.MIT.EDU
2630
2631 Offers of refreshement are also very welcome -- do you think we have any
2632 budget for this kind of thing?  Send all such offers also to CENT as above.
2633 \1f
2634 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU  6 Sep 88 21:16:38 EDT
2635 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
2636 Date: Tue, 6 Sep 88 21:12 EDT
2637 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
2638 Subject: mc par errs
2639 To: Pandora B. Berman <CENT@AI.AI.MIT.EDU>
2640 cc: BUG-ITS@AI.AI.MIT.EDU
2641 In-Reply-To: <437950.880906.CENT@AI.AI.MIT.EDU>
2642 Message-ID: <19880907011222.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
2643
2644     Date: Tue,  6 Sep 88 06:50:56 EDT
2645     From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2646
2647     the sysconsole died mysteriously this evening. it was in the middle of
2648     printing a msg to my DUMP about loading a tape and then saying ok, when
2649     all of a sudden it said
2650             ?rivPARITY
2651     and the console was talking to KLDCP. the easy way out was to reattach that
2652     hactrn to the vt52, so i took it. but when that tape was done and i tried
2653     to boot the system to regain access to the sysconsole, it died twice during
2654     the reboot process, at different places, each time with the blank but
2655     ominous msg: PARITY. the mem bays didn't indicate par errs, but i tried
2656     resetting them anyway. each time, after resetting bay D a couple times, its
2657     par err light would come on. after resetting more, the light would
2658     disappear, sometimes return, and then go away again. it did eventually
2659     cooperate and let the machine come up, but this was very odd..
2660
2661 These sound like parity errors in the front-end pdp-11's memory
2662 [I hope someone isn't going to tell me that that pdp-11 doesn't
2663 have parity on its memory and I've just made a fool of myself.]
2664 \1f
2665 Date: Tue,  6 Sep 88 06:50:56 EDT
2666 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2667 Subject: mc par errs
2668 To: BUG-ITS@AI.AI.MIT.EDU
2669 Message-ID: <437950.880906.CENT@AI.AI.MIT.EDU>
2670
2671 the sysconsole died mysteriously this evening. it was in the middle of
2672 printing a msg to my DUMP about loading a tape and then saying ok, when
2673 all of a sudden it said
2674         ?rivPARITY
2675 and the console was talking to KLDCP. the easy way out was to reattach that
2676 hactrn to the vt52, so i took it. but when that tape was done and i tried
2677 to boot the system to regain access to the sysconsole, it died twice during
2678 the reboot process, at different places, each time with the blank but
2679 ominous msg: PARITY. the mem bays didn't indicate par errs, but i tried
2680 resetting them anyway. each time, after resetting bay D a couple times, its
2681 par err light would come on. after resetting more, the light would
2682 disappear, sometimes return, and then go away again. it did eventually
2683 cooperate and let the machine come up, but this was very odd.
2684 \1f
2685 Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 22 Aug 88 13:32:30 EDT
2686 Return-Path: <gls@Think.COM>
2687 Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Mon, 22 Aug 88 13:30:49 EDT
2688 Received: by joplin.think.com; Mon, 22 Aug 88 13:30:32 EDT
2689 Date: Mon, 22 Aug 88 13:30:32 EDT
2690 From: gls@Think.COM
2691 Message-Id: <8808221730.AA03248@joplin.think.com>
2692 To: ALAN@ai.ai.mit.edu
2693 Cc: BUG-ITS@ai.ai.mit.edu
2694 In-Reply-To: Alan Bawden's message of Sun, 14 Aug 88 22:15:58 EDT <427454.880814.ALAN@AI.AI.MIT.EDU>
2695
2696    Date: Sun, 14 Aug 88 22:15:58 EDT
2697    From: Alan Bawden <ALAN@ai.ai.mit.edu>
2698
2699    AI is running an ITS patched so that .HANG with a non-zero AC is an illegal
2700    UUO.  System hackers should be on the lookout for any programs that appear
2701    to be broken by this.
2702
2703    The idea is to learn if anybody uses the AC field in .HANG for any private
2704    purposes before I give it a meaning.  I propose to make .HANG with a
2705    non-zero AC behave like the disjunction of .HANG and .SLEEP, so that you
2706    can wait for a location to change -or- for a timeout to occur.  So
2707
2708            movei 10,5*30.
2709            skipl lock
2710             .hang 10,           ; (sic)
2711            jumpe 10,timout              ; C(AC) = 0 if and only if timer expired.
2712                                    ; If not, C(AC) is negative of time to wait
2713                                    ; for (just like .SLEEP).
2714
2715    will wait for 5 seconds for C(LOCK) to be negative, and will then time out.
2716
2717
2718 Gee, why didn't we do this ten years ago???
2719 --Guy
2720 \1f
2721 Date: Sun, 14 Aug 88 22:15:58 EDT
2722 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2723 To: BUG-ITS@AI.AI.MIT.EDU
2724 Message-ID: <427454.880814.ALAN@AI.AI.MIT.EDU>
2725
2726 AI is running an ITS patched so that .HANG with a non-zero AC is an illegal
2727 UUO.  System hackers should be on the lookout for any programs that appear
2728 to be broken by this.
2729
2730 The idea is to learn if anybody uses the AC field in .HANG for any private
2731 purposes before I give it a meaning.  I propose to make .HANG with a
2732 non-zero AC behave like the disjunction of .HANG and .SLEEP, so that you
2733 can wait for a location to change -or- for a timeout to occur.  So
2734
2735         movei 10,5*30.
2736         skipl lock
2737          .hang 10,              ; (sic)
2738         jumpe 10,timout         ; C(AC) = 0 if and only if timer expired.
2739                                 ; If not, C(AC) is negative of time to wait
2740                                 ; for (just like .SLEEP).
2741
2742 will wait for 5 seconds for C(LOCK) to be negative, and will then time out.
2743 \1f
2744 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Aug 88 18:00:16 EDT
2745 Date: Fri 12 Aug 88 17:47:25-EDT
2746 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2747 Subject: Re: When the KL is shut down, and taken apart.
2748 To: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU
2749 cc: bug-its@AI.AI.MIT.EDU, tjg@XX.LCS.MIT.EDU, dempster@TOPS20.DEC.COM
2750 In-Reply-To: <7J14CB@KICKI.STACKEN.KTH.SE>
2751 Message-ID: <12421931449.38.SRA@XX.LCS.MIT.EDU>
2752
2753     Date: Fri, 12 Aug 88 12:41:06 +0200
2754     From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg)
2755
2756     When MX finally is going to be turned off and brought out from the
2757     9:th floor to Sweden, where it hopfully will become alive again.
2758
2759     I thought that it might be a god idea to have a 'burial cermony', or
2760     a small party. Or..??
2761
2762 Yeah, let's throw a wake.  Even though we plan for the machine to come
2763 back to life in Sweden, it'll be the end of an era here, and god knows
2764 the machine deserves a wake after all we've put it through.
2765
2766     (I want to have pictures of most of the people that has been involved
2767      in the ITS development, so we can have a 'history book' along with the
2768      machine, a this might be the right time to shoot them.)
2769
2770 Which are you shooting, the pictures or the people?
2771 -------
2772 \1f
2773 Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 12 Aug 88 08:13:35 EDT
2774 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
2775 Received: from SEKTH.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
2776  2956; Fri, 12 Aug 88 08:07:36 EDT
2777 Received: from kth.se by KTH-BITNET-GATEWAY ; 12 Aug 88 10:40:14 GMT
2778 Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0)
2779         id AA20391; Fri, 12 Aug 88 12:40:06 +0200
2780 Date: Fri, 12 Aug 88 12:41:06 +0200
2781 From: ROLL%SESTAK.BITNET@MITVMA.MIT.EDU (Peter Lothberg)
2782 To: bug-its@ai.ai.mit.edu, tjg@xx.lcs.mit.edu, dempster@tops20.dec.com
2783 Subject: When the KL is shut down, and taken apart.
2784 Message-Id: <7J14CB@KICKI.STACKEN.KTH.SE>
2785
2786
2787 When MX finally is going to be turned off and brought out from the
2788 9:th floor to Sweden, where it hopfully will become alive again.
2789
2790 I thought that it might be a god idea to have a 'burial cermony', or
2791 a small party. Or..??
2792
2793 (I want to have pictures of most of the people that has been involved
2794  in the ITS development, so we can have a 'history book' along with the
2795  machine, a this might be the right time to shoot them.)
2796
2797 Peter
2798
2799 \1f
2800 Date: Wed, 10 Aug 88 02:03:22 EDT
2801 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2802 Subject: KL hardware bug of the week club
2803 To: TY@AI.AI.MIT.EDU, TJG@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
2804 cc: CENT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2805 Message-ID: <425456.880810.CENT@AI.AI.MIT.EDU>
2806
2807 two weeks ago, the KL HARDWARE BUG OF THE WEEK CLUB brought you the
2808 repeated crash of the console 11.  we followed up with several days of
2809 incessant non-fatal parity errors which invariably led to fatal ones or
2810 ucode hangs, and topped it off with an admixture of crashing 11 again.
2811
2812 after a day or two to let you catch your breath, we now present:
2813
2814                         DEATH OF THE CAPSTAN MOTOR
2815
2816 the symptoms you will encounter include:
2817       tape not loading because the take-up reel won't spin to wind it
2818                                     and
2819     take-up reel ceasing to spin, for no apparent reason, in the middle
2820    of a copy operation, leading to tape piling up in the vacuum columns,
2821     the drive taking itself offline, and the copy stopping dead in its
2822             tracks because DUMP can no longer talk to the drive
2823
2824 This is serious; the MX tape drive is becoming unusable.  I can deal with
2825 the machine crashing; i can't fix that motor.  This problem just started
2826 occurring this evening and it seems to be getting rapidly worse; it's now
2827 sufficiently bad that i can't get through copying a single old tape
2828 successfully.  This must be fixed (competently) for me to do any more tape
2829 copying.  Call in DEC if you must, but get it done.
2830 \1f
2831 Date: Mon,  8 Aug 88 05:10:44 EDT
2832 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2833 Subject: ai console broken
2834 To: BUG-ITS@AI.AI.MIT.EDU
2835 Message-ID: <424212.880808.CENT@AI.AI.MIT.EDU>
2836
2837 ai's console makes obnoxious noises and lights its paper-out indicator
2838 whenever it tries to type more than 18 chars on a line.
2839 \1f
2840 Date: Sat,  6 Aug 88 05:26:22 EDT
2841 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2842 Subject: ominous new turn
2843 To: BUG-ITS@AI.AI.MIT.EDU
2844 Message-ID: <423574.880806.CENT@AI.AI.MIT.EDU>
2845
2846 MX has been getting parity errors right and left whenever i copy tapes.
2847 then the system console went west again (the 11 crashed), so i had to patch
2848 the sys job and move my dump job to the vt52. when i decided to punt the
2849 dump, i tried to boot the system to restore function to the console. this
2850 went OK until i tried to load MTPITS. then everything stopped. the state is
2851 characterized more by what it is not: MX does not respond to the disk boot
2852 button; the disk is not unsafe; the fault light is not on; the breakers are
2853 not tripped; the par err lights are not on. normally my next trick would
2854 be to power cycle the machine, but in its current fragile state, i don't
2855 want to do that without a real hacker around to help pick up the pieces.
2856 someone please check it out.
2857 \1f
2858 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 29 Jul 88 11:24:17 EDT
2859 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
2860 Date: Fri, 29 Jul 88 11:22 EDT
2861 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
2862 Subject: MX falls over, tapes flutter
2863 To: Pandora B. Berman <CENT@AI.AI.MIT.EDU>
2864 cc: BUG-ITS@AI.AI.MIT.EDU, BUG-MAGDMP@AI.AI.MIT.EDU, TJG@AI.AI.MIT.EDU
2865 In-Reply-To: <419832.880728.CENT@AI.AI.MIT.EDU>
2866 Message-ID: <19880729152207.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
2867
2868     Date: Thu, 28 Jul 88 23:48:02 EDT
2869     From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2870
2871     ....
2872     a possibly related problem: the second time this happened, i was running
2873     into a tape flap error. what happens -- apparently reproducibly with AI
2874     tape 1088 -- is that while reading the tape, it hits some region about 3/4
2875     of the way in that it doesn't like. the vacuum columns start to flutter.
2876     the tape continues feeding into them, slowly, until it apparently reaches a
2877     max enforced by the hardware. then the tape in the columns just flutters,
2878     not very far up or down, but a lot; the tape on the input spindle shakes in
2879     concert with them, but i couldn't tell whether the takeup reel was moving
2880     at all. the scary thing is that this aberrant behaviour produces no err
2881     msgs, so i can't tell what to do.
2882
2883 This behavior is what the drive looks like when there is a read error and
2884 the software keeps retrying the read.  The tape is actually going forwards and
2885 backwards about 9 inches very quickly.  I'm surprised it doesn't eventually
2886 give up and report a hard read error.  Maybe some bug.  You might end up not
2887 being to copy that tape.
2888 \1f
2889 Date: Thu, 28 Jul 88 23:48:02 EDT
2890 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2891 Subject: MX falls over, tapes flutter
2892 To: BUG-ITS@AI.AI.MIT.EDU, BUG-MAGDMP@AI.AI.MIT.EDU
2893 cc: TJG@AI.AI.MIT.EDU
2894 Message-ID: <419832.880728.CENT@AI.AI.MIT.EDU>
2895
2896 tonight MX got 2 errors of the form
2897  UUO while in AC BLK 0
2898  BUGHALT....
2899 within about 2 hours. alan looked at the first one and said "but it can't
2900 do that!" and explained that that purported to convey that the SYS job was
2901 running with accumulator block 0 selected, which i gather is a bad thing.
2902 when the second one occured he was on his way out the door, and suggested
2903 that if it keeps getting UUOs like this, maybe the processor is actually
2904 broken and needs to by fixed by (gulp) DEC. i have not touched it; someone
2905 competent please investigate.
2906
2907 a possibly related problem: the second time this happened, i was running
2908 into a tape flap error. what happens -- apparently reproducibly with AI
2909 tape 1088 -- is that while reading the tape, it hits some region about 3/4
2910 of the way in that it doesn't like. the vacuum columns start to flutter.
2911 the tape continues feeding into them, slowly, until it apparently reaches a
2912 max enforced by the hardware. then the tape in the columns just flutters,
2913 not very far up or down, but a lot; the tape on the input spindle shakes in
2914 concert with them, but i couldn't tell whether the takeup reel was moving
2915 at all. the scary thing is that this aberrant behaviour produces no err
2916 msgs, so i can't tell what to do.
2917
2918 NB: over the past several days the front-end 11 has crashed twice, causing
2919 the sysconsole to go west. the first time, this weekend, i used a bigger
2920 hammer by rebooting the whole machine. when it happened again earlier this
2921 evening, alan tried to apply sweet reason to it, but it didn't work, so
2922 he had to boot MX. but that wasn't what caused the lack of err msgs about
2923 the tape flutter, because the sysconsole was entirely capable of printing
2924 the UUO err msg.
2925
2926 see the system log. no film at 11.
2927 \1f
2928 Date: Tue, 26 Jul 88 02:16:06 EDT
2929 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2930 Subject: poor old kl hardware sux rocks
2931 To: BUG-ITS@AI.AI.MIT.EDU
2932 Message-ID: <418290.880726.CENT@AI.AI.MIT.EDU>
2933
2934 it's been crashing on me every 10-15 minutes for the past 2 hours.
2935 probably i have been forcing it to over-exertion by trying to read a
2936 remote tape -and- (via supdup) to catch up with my old mail at the
2937 same time. the remote tape is a copied KA full, which i am trying to
2938 list to a file; i suppose i'll just have to do that elsewhere while
2939 using the KL to send bits out.
2940      i don't mind the constant too many par err problems -- at least,
2941 i have been managing to make progress despite them. but now unit 0 has
2942 its UNSAFE light on. i don't want to deal with that at this hour.
2943 someone else please take a look at it. thanks.
2944 \1f
2945 Date: Sat, 23 Jul 88 02:17:38 EDT
2946 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2947 Subject: patched MX system
2948 To: BUG-ITS@AI.AI.MIT.EDU
2949 Message-ID: <417298.880723.CENT@AI.AI.MIT.EDU>
2950
2951 thanks to moon, MX is running MTPITS, a version of NITS patched to be
2952 especially nice to tape software. it should continue running MTPITS
2953 until the tape copying project is done.
2954 \1f
2955 Date: Sat,  2 Jul 88 14:04:15 EDT
2956 From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
2957 To: BUG-ITS@AI.AI.MIT.EDU
2958 Message-ID: <406657.880702.DEVON@AI.AI.MIT.EDU>
2959
2960 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.
2961 \1f
2962 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jun 88 22:26:47 EDT
2963 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Jun 88 22:13:53 EDT
2964 Date: Wed 22 Jun 88 22:13:36-EDT
2965 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2966 To: ZVONA@MC.LCS.MIT.EDU
2967 cc: BUG-ITS@MC.LCS.MIT.EDU
2968 In-Reply-To: <440792.880622.ZVONA@MC.LCS.MIT.EDU>
2969 Message-ID: <12408610560.16.SRA@XX.LCS.MIT.EDU>
2970
2971     Date: Wed, 22 Jun 88 21:28:11 EDT
2972     From: David Chapman <ZVONA@MC.LCS.MIT.EDU>
2973
2974     Why can't I link to a non-disk device?  The AI: device, in particular?
2975
2976 Presumably because the UFD definition for links allows SNAME, FN1, &
2977 FN2 but doesn't allow device names.  See AI:SYSTEM;FSDEFS.
2978
2979 Also presumably because by the time you get to deciphering links the
2980 filesystem code just knows that it must be dealing with a disk device.
2981
2982 Neither of which is a reason why you -shouldn't- be able to link to
2983 non-disk devices, just why you can't.
2984 -------
2985
2986 \1f
2987 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jun 88 21:28:36 EDT
2988 Date: Wed, 22 Jun 88 21:28:11 EDT
2989 From: David Chapman <ZVONA@MC.LCS.MIT.EDU>
2990 To: BUG-ITS@MC.LCS.MIT.EDU
2991 Message-ID: <440792.880622.ZVONA@MC.LCS.MIT.EDU>
2992
2993 This is a stupid question, but maybe someone won't mind educating me:
2994
2995 Why can't I link to a non-disk device?  The AI: device, in particular?
2996 \1f
2997 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jun 88 22:01:51 EDT
2998 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Jun 88 21:58:46 EDT
2999 Date: Thu 16 Jun 88 21:57:50-EDT
3000 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3001 Subject: Re: well, I hope there's SOME explanation for this
3002 To: PGS@XX.LCS.MIT.EDU
3003 cc: bug-twenex@XX.LCS.MIT.EDU, bug-its@MC.LCS.MIT.EDU,
3004     bug-finger@MC.LCS.MIT.EDU
3005 In-Reply-To: <PGS.12407009575.BABYL@XX.LCS.MIT.EDU>
3006 Message-ID: <12407034826.27.SRA@XX.LCS.MIT.EDU>
3007
3008     Date: Thu, 16 Jun 1988  19:39 EDT
3009     From: PGS@XX.LCS.MIT.EDU
3010
3011     This is not a joke.  This happens consistently on XX.
3012
3013         [PHOTO:  Recording initiated  Thu 16-Jun-88 7:33PM]
3014
3015          MIT TOPS-20 Command Processor 5(312162)-2
3016         No mail.
3017         @whois yomama yomama@mc
3018         [MC.LCS.MIT.EDU]
3019         -User-    --Full name--          Jobnam Idle TTY -Console location-
3020         ALAN   `  Alan Bawden            P      1:18 T05 723 x8843 Alan, HQM
3021            (Spaceman) [AI] Hacking too many things for my own good
3022            Birthday January 23;  NE43-723;  3-8843;  Home Phone 492-7274
3023            29 Reed St., Cambridge, MA 02140
3024
3025         @pop
3026
3027         [PHOTO:  Recording terminated  Thu 16-Jun-88 7:34PM]
3028
3029 The bug is in the Twenex finger program.  The only explaination I can
3030 think of is that the guy who wrote the parsing code in that program
3031 had his brain held hostage on planet Quorgon while he was writing that
3032 part of it.  The amazing thing is that the program runs at all.  Even
3033 more amazing is that it ever works in server mode, considering that it
3034 gets its JCL by each FINGER stuffing its RFC packet into the CHARFC
3035 job's shared RSCAN% buffer.
3036
3037 I suppose I might try to fix this some day, but since it only catches
3038 a subset of completely bogus names I don't intend to worry about it
3039 much.
3040 -------
3041
3042 \1f
3043 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jun 88 19:43:00 EDT
3044 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Jun 88 19:40:56 EDT
3045 Date: Thu, 16 Jun 1988  19:39 EDT
3046 Message-ID: <PGS.12407009575.BABYL@XX.LCS.MIT.EDU>
3047 From: PGS@XX.LCS.MIT.EDU
3048 To:   bug-twenex@XX.LCS.MIT.EDU, bug-its@MC.LCS.MIT.EDU,
3049       bug-finger@MC.LCS.MIT.EDU
3050 Subject: well, I hope there's SOME explanation for this
3051
3052 This is not a joke.  This happens consistently on XX.
3053
3054     [PHOTO:  Recording initiated  Thu 16-Jun-88 7:33PM]
3055
3056      MIT TOPS-20 Command Processor 5(312162)-2
3057     No mail.
3058     @whois yomama yomama@mc
3059     [MC.LCS.MIT.EDU]
3060     -User-    --Full name--          Jobnam Idle TTY -Console location-
3061     ALAN   `  Alan Bawden            P      1:18 T05 723 x8843 Alan, HQM
3062        (Spaceman) [AI] Hacking too many things for my own good
3063        Birthday January 23;  NE43-723;  3-8843;  Home Phone 492-7274
3064        29 Reed St., Cambridge, MA 02140
3065
3066     @pop
3067
3068     [PHOTO:  Recording terminated  Thu 16-Jun-88 7:34PM]
3069
3070 But, come to think of it: Alan, can I go to the dance on Saturday night?
3071 Oh, come on, pleeeeeze?!
3072
3073 \1f
3074 Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 15 Jun 88 19:18:55 EDT
3075 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
3076 Date: Wed, 15 Jun 88 19:15 EDT
3077 From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3078 Subject: Re: This is important!
3079 To: Alan Bawden <Alan@AI.AI.MIT.EDU>, kao@VERMITHRAX.SCH.Symbolics.COM, SRA@XX.LCS.MIT.EDU,
3080     maeda@MCC.COM, DCP@QUABBIN.SCRC.Symbolics.COM, cjl@WHEATIES.AI.MIT.EDU,
3081     Gumby@MCC.COM
3082 cc: Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-ITS@AI.AI.MIT.EDU,
3083     Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU
3084 In-Reply-To: <19880615210705.7.ALAN@PIGPEN.AI.MIT.EDU>
3085 Message-ID: <19880615231501.4.DCP@SWAN.SCRC.Symbolics.COM>
3086
3087     Date: Wed, 15 Jun 88 17:07 EDT
3088     From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3089         ...
3090         Date: Tue, 14 Jun 88 17:16 EDT
3091         From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3092         ...
3093         BTW, I think decreasing the file control lifetime would make the
3094         problem WORSE!!  (I'm not sure about that, though.)
3095
3096     I'd be interested in understanding why.  Is it because the thing that times
3097     out connections might not actually shut down the connection, but would
3098     cause the 3600 to forget about it, this accumulating even more useless
3099     connections?
3100
3101 Anytime the control connection dies (either because the network spazzed,
3102 or because the scavenger closes it), the next file operation will find
3103 this control connection (ConnA), notice it is dead, reset it (here's the bug:
3104 which forgets about it), reestablish connection, and then use ConnA for
3105 the duration of this single file operation.  The next file operation
3106 will not even find ConnA and must therefore cons up a new one (ConnB).
3107 ConnB will be found for a while.  When it dies, it will still be found
3108 (once), get forgotten about and used, and then ConnC must be consed up.
3109
3110 So... The more often the file connection scavenger runs, the faster the
3111 connections die, so the higher the rate of finding/forgetting and thus
3112 leaving open but connections around.
3113
3114         ...
3115
3116     Which finally brings me to the real point of the message.  Unfortunately,
3117     despite Symbolic's best efforts (for which I thank them), we are still left
3118     in a situation where we have to get zapped at least once by a site before
3119     we can send them the fix.  We can spread the fix around ourselves to the
3120     most likely places, but we can still lose now and then.
3121
3122     Therefore, unless anybody objects or has a better plan, I plan to install a
3123     tasteless little demon that checks for FTP and GATEWAY servers that are
3124     clearly idle, and guns them down.  That should be an effective defense
3125     against any future offenders.  (I'll have it keep a log of what it does, so
3126     that we can still spot the losers and send them the patch.)
3127
3128 Sounds fine to me.  I'd use 20 minutes as idle, which I think gives the
3129 typical 15 minute connection scavenger a chance first.  Also, be careful
3130 what you call "idle."  LispMs will issue reset-provoking-probes at
3131 rather short intervals, so you should measure idle by actualy byte
3132 (sequence number) traffic, not last-time-a-packet-seen (since chaos has
3133 a stronger are-you-alive idle probe).  I guess this is just process idle
3134 time...
3135 \1f
3136 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 Jun 88 17:10:31 EDT
3137 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
3138 Date: Wed, 15 Jun 88 17:07 EDT
3139 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3140 Subject: Re: This is important!
3141 To: kao@VERMITHRAX.SCH.Symbolics.COM, SRA@XX.LCS.MIT.EDU, maeda@MCC.COM,
3142     DCP@QUABBIN.SCRC.Symbolics.COM, cjl@WHEATIES.AI.MIT.EDU, Gumby@MCC.COM
3143 cc: Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-ITS@AI.AI.MIT.EDU,
3144     Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU
3145 In-Reply-To: <19880611005711.2.KAO@BINKLEY.SCH.Symbolics.COM>,
3146              <19880613151342.8.KAO@BINKLEY.SCH.Symbolics.COM>,
3147              <12406136710.21.SRA@XX.LCS.MIT.EDU>,
3148              <19880613161443.4.MAEDA@PELE.ACA.MCC.COM>,
3149              <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM>,
3150              <12406155402.19.SRA@XX.LCS.MIT.EDU>,
3151              <19880613221658.4.CJL@OTIS.AI.MIT.EDU>,
3152              <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM>,
3153              <19880614211637.8.DCP@SWAN.SCRC.Symbolics.COM>,
3154              <19880615034707.7.CJL@OTIS.AI.MIT.EDU>,
3155              <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM>,
3156              <880615114233.8.GUMBY@BRAHMA.ACA.MCC.COM>
3157 Message-ID: <19880615210705.7.ALAN@PIGPEN.AI.MIT.EDU>
3158
3159     Date: Mon, 13 Jun 88 08:13 PDT
3160     From: kao@VERMITHRAX.SCH.Symbolics.COM
3161     [Response from the developer.  Hope it helps.]
3162     Certainly a quick work around for this would be to reduce the
3163     file-control-lifetime for MC to something less than 15 minutes and make
3164     sure all the machines see the namespace update.
3165
3166 Although we haven't done this anywhere (unless our friends at MCC have done
3167 this?) this is a reasonable suggestion which did not occur to me when I
3168 spotted the problem initially.  Please thank the unnamed developer for me.
3169
3170     Date: Mon, 13 Jun 88 22:20 CDT
3171     From: David Vinayak Wallace <Gumby@MCC.COM>
3172     The problem is with FILE connections, not GATEWAY connections.
3173
3174 [ Aside to Gumby:  The problem with GATEWAY connections is only that
3175   someone who uses Chaos TCP-GATEWAY service on MC to access a remote FTP
3176   server winds up using zillions of Chaos -and- TCP connections on MC.  I
3177   suppose you are trying to say that if the problem with FTP connections
3178   gets solved, the problem with GATEWAY connections goes away.  This is
3179   correct. ]
3180
3181     Date: Tue, 14 Jun 88 17:16 EDT
3182     From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3183     ...I'm pretty sure the code in
3184     Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it....  I still need
3185     to run it by the person current maintainer (who isn't the author) for a
3186     sanity check.  Having you folks run it would be a good use-test....
3187
3188     BTW, I think decreasing the file control lifetime would make the
3189     problem WORSE!!  (I'm not sure about that, though.)
3190
3191 I'd be interested in understanding why.  Is it because the thing that times
3192 out connections might not actually shut down the connection, but would
3193 cause the 3600 to forget about it, this accumulating even more useless
3194 connections?
3195
3196     Date: Tue, 14 Jun 88 23:47 EDT
3197     From: Chris Lindblad <cjl@WHEATIES.AI.MIT.EDU>
3198     I added this to our local 7-2-patches system.  It will get loaded into
3199     most machines here when they boot.
3200
3201 Of course this isn't much of a test, since (as far as I know) all the
3202 machines that load 7-2-Patches are machines that can talk CHAOS QFILE to all
3203 the ITS machines, and they also talk TCP, so there is no reason they should
3204 need CHAOS GATEWAY service either.
3205
3206     Date: Wed, 15 Jun 88 11:42 CDT
3207     From: David Vinayak Wallace <Gumby@MCC.COM>
3208     This patch appears to have a bug (which I have reported to DCP).  I
3209     would not suggest supplying it to the unwary.
3210
3211 Now if Gumby and Maeda at MCC try this patch out, that will be a real test.
3212 As soon as they are satisfied that it works, then we can think about
3213 handing it out to other sites that we discover causing this problem in the
3214 future.
3215
3216 Which finally brings me to the real point of the message.  Unfortunately,
3217 despite Symbolic's best efforts (for which I thank them), we are still left
3218 in a situation where we have to get zapped at least once by a site before
3219 we can send them the fix.  We can spread the fix around ourselves to the
3220 most likely places, but we can still lose now and then.
3221
3222 Therefore, unless anybody objects or has a better plan, I plan to install a
3223 tasteless little demon that checks for FTP and GATEWAY servers that are
3224 clearly idle, and guns them down.  That should be an effective defense
3225 against any future offenders.  (I'll have it keep a log of what it does, so
3226 that we can still spot the losers and send them the patch.)
3227 \1f
3228 Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 15 Jun 88 12:46:09 EDT
3229 Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Wed 15 Jun 88 11:42:53-CDT
3230 Date: Wed, 15 Jun 88 11:42 CDT
3231 From: David Vinayak Wallace <Gumby@MCC.COM>
3232 Subject: This is important!
3233 To: kao@VERMITHRAX.SCH.Symbolics.COM
3234 cc: Alan@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, Customer-Reports@VERMITHRAX.SCH.Symbolics.COM,
3235     Bug-ITS@AI.AI.MIT.EDU
3236 In-Reply-To: <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM>
3237 Supersedes: <880615114204.7.GUMBY@BRAHMA.ACA.MCC.COM>
3238 Message-ID: <880615114233.8.GUMBY@BRAHMA.ACA.MCC.COM>
3239 Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY")
3240 Fonts: CPTFONT, TINY
3241
3242     Date: Wed, 15 Jun 88 08:14 PDT
3243     From: kao@VERMITHRAX.SCH.Symbolics.COM
3244
3245         Date: Fri, 10 Jun 88 17:42 EDT
3246         From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3247
3248 \ 61      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,
3249         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,
3250         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,
3251         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),
3252         FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233,
3253         Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2)
3254         on Symbolics 3640 #5233 (Hilbert's Nullstellensatz):
3255
3256 \ 60      Please, please, please, do something about the bug where when a 3600 uses
3257         TCP/FTP as a file access path it sometimes starts up dozens of FTP servers
3258         on the file server.  Twice now I have found MC.LCS.MIT.EDU with all of its
3259         network connections used up because someone somewhere was using FTP to
3260         access files on MC (or on some remote machine with MC serving as a
3261         CHOAS/TCP gateway).
3262
3263     Here is the patch written by DCP. It fixes the bug you reported.
3264
3265 This patch appears to have a bug (which I have reported to DCP).  I
3266 would not suggest supplying it to the unwary.
3267 \1f
3268 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 15 Jun 88 11:19:20 EDT
3269 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
3270 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
3271 Date: Wed, 15 Jun 88 08:14 PDT
3272 From: kao@VERMITHRAX.SCH.Symbolics.COM
3273 Subject: This is important!
3274 To: Alan%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM
3275 cc: Bug-Lispm%REAGAN.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Customer-Reports@VERMITHRAX.SCH.Symbolics.COM,
3276     Bug-ITS%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM
3277 In-Reply-To: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3278 References: <12405426732.27.SRA@XX.LCS.MIT.EDU>,
3279             <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3280 Message-ID: <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM>
3281 Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY")
3282                          (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")
3283 Fonts: CPTFONT, TINY, CPTFONTCB
3284
3285     Date: Fri, 10 Jun 88 17:42 EDT
3286     From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3287
3288 \ 61        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,
3289         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,
3290         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,
3291         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),
3292         FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233,
3293         Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2)
3294         on Symbolics 3640 #5233 (Hilbert's Nullstellensatz):
3295
3296 \ 60    Please, please, please, do something about the bug where when a 3600 uses
3297     TCP/FTP as a file access path it sometimes starts up dozens of FTP servers
3298     on the file server.  Twice now I have found MC.LCS.MIT.EDU with all of its
3299     network connections used up because someone somewhere was using FTP to
3300     access files on MC (or on some remote machine with MC serving as a
3301     CHOAS/TCP gateway).
3302
3303     I would appreciate a fix for this problem -quickly- because MIT depends on
3304     MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally
3305     disables the machine.  This is the kind of problem where I can get somebody
3306     at MIT with an official sounding title to call you all up on the phone and
3307     lodge "official" complaints.
3308
3309 Here is the patch written by DCP. It fixes the bug you reported.
3310
3311 ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: USER; Base: 10; Patch-File: T -*-
3312 ;;; Patch file for Private version 0.0
3313 ;;; Reason: Removing the connection from the file access path should not
3314 ;;; be part of the contract of resetting the connection.
3315 ;;; Function (FLAVOR:METHOD :RESET FS:TCP-FTP-CONN):  Don't remove.  (Doing so is "silly" anyway.)
3316 ;;; Remove function (FLAVOR:METHOD :REMOVE-CONN FS:TCP-FTP-FILE-ACCESS-PATH): No longer needed.
3317 ;;; Function (DEFUN-IN-FLAVOR FS:TCP-FTP-FIND-CONN FS:TCP-FTP-FILE-ACCESS-PATH):  Interact properly with multiple processes.
3318 ;;; Written by DCP, 6/14/88 16:18:34
3319 ;;; while running on Swan from MAMA-CASS|FEP1:>SCRC-7-2-E-from-IH-Genera-7-2-C.load.1
3320 ;;; with Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST,
3321 ;;; Nsage 27.175, Documentation Database 62.18, Metering Substrate 26.7,
3322 ;;; Metering 11.1, Hacks 14.1, IP-TCP 67.5, DNA 41.6, Version Control 52.9,
3323 ;;; Compare Merge 18.0, Experimental Lock Simple 19.0, VC Documentation 12.0,
3324 ;;; Symbolics In-House 16.7, Symbolics In-House Documentation 6.3,
3325 ;;; Experimental Statice 53.0, Unique-ID 11.2, DBFS 54.16, DBFS Utilities 9.0,
3326 ;;; Statice-Index 15.0, Statice-Record 26.1, Statice-Model 51.15,
3327 ;;; Statice Documentation 16.0, Experimental Statice Examples NEWEST, DBFS-DIR 25.4,
3328 ;;; Statice-Utilities 14.4, Tertiary Storage 10.0, DBFS Maintenance 12.0,
3329 ;;; Volume Librarian 9.0, Bug Tracking 24.11, Symbolics Boston 17.2, SCRC 37.0,
3330 ;;; Experimental Ndomains 18, microcode 3640-MIC 420, FEP 127,
3331 ;;; FEP0:>V127-lisp.flod(61), FEP0:>V127-loaders.flod(61), FEP0:>V127-tests.flod(61),
3332 ;;; FEP0:>v127-debug.flod(37), FEP0:>V127-ddt.flod(61), FEP0:>V127-info.flod(61),
3333 ;;; Machine serial number 4968,
3334 ;;; Be more imaginative than "Run" (from Q:>dcp>ideas>info-giving-process-preemption.lisp.8),
3335 ;;; System patches for 7.1 domain implementation (from Q:>dcp>domains>system-patches.lisp.5).
3336
3337
3338 (NOTE-PRIVATE-PATCH "TCP-FTP: Interact properly with DELETE operation")
3339
3340
3341 ;=====================================
3342 (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION)
3343 (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527")
3344 (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES
3345   "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-")
3346
3347 ;; Connections
3348
3349 (defmethod (:reset tcp-ftp-conn) ()
3350   (setq login-state nil)
3351   (setq state :free)
3352   (when telnet-stream
3353     (send telnet-stream :close :abort)
3354     (setq telnet-stream nil))
3355   (when data-stream
3356     (send data-stream :close :abort)
3357     \ 62(setq data-stream nil)\ 60)
3358   (when aux-stream
3359     (send aux-stream :close :abort)
3360     (setq aux-stream nil))
3361
3362   \ 62;; Don't remove the connection.  Doing so causes all sorts of grief.
3363 \ 60  \ 62;; There are some parts of the code that :RESET the connection and
3364 \ 60  \ 62;; then proceed to open up a new telnet-stream (e.g.,
3365 \ 60  \ 62;; \ 60tcp-ftp-validate-conn\ 62) and there are others that dolist the conns,
3366 \ 60  \ 62;; and removing a conn out from under them isn't very fun at all!
3367
3368 \ 60  \ 62;; \ 60(send file-access-path :remove-conn self)
3369   )
3370
3371
3372 ;=====================================
3373 (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION)
3374 (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527")
3375 (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES
3376   "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-")
3377
3378 (FUNDEFINE '(FLAVOR:METHOD :REMOVE-CONN TCP-FTP-FILE-ACCESS-PATH))
3379
3380 ;=====================================
3381 (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION)
3382 (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527")
3383 (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES
3384   "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-")
3385
3386 (defun-in-flavor (tcp-ftp-find-conn tcp-ftp-file-access-path) ()
3387   (loop for conn in conns
3388         when (send conn :allocate)
3389           return conn
3390         finally
3391           \ 62(let ((new-conn \ 60(make-instance 'tcp-ftp-conn
3392                                          :file-access-path self
3393                                          :service-access-path service-access-path)\ 62))
3394 \ 60          \ 62(without-interrupts
3395 \ 60            (push \ 62new-conn \ 60conns)\ 62)
3396 \ 60          (send *file-connection-scavenger* :run-reason self)
3397             (return \ 62new-conn\ 60)\ 62)\ 60))
3398
3399 \1f
3400 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 14 Jun 88 23:49:40 EDT
3401 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
3402 Date: Tue, 14 Jun 88 23:47 EDT
3403 From: Chris Lindblad <cjl@WHEATIES.AI.MIT.EDU>
3404 Subject: File-Control-Lifetime "fix" for MC FTP connections
3405 To: DCP@quabbin.scrc.symbolics.com
3406 cc: Gumby@mcc.com, SRA@xx.lcs, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU,
3407     TJG@xx.lcs
3408 In-Reply-To: The message of 14 Jun 88 17:16 EDT from David C. Plummer <DCP@quabbin.scrc.symbolics.com>
3409 Message-ID: <19880615034707.7.CJL@OTIS.AI.MIT.EDU>
3410
3411     Date: Tue, 14 Jun 88 17:16 EDT
3412     From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
3413
3414         Date: Mon, 13 Jun 88 22:20 CDT
3415         From: David Vinayak Wallace <Gumby@MCC.COM>
3416
3417         The problem is with FILE connections, not GATEWAY connections.
3418
3419         From poking into it (my machine is one of the main instigators) it looks
3420         like only Symbolics' implementation of FTP is to blame.
3421
3422     Yup.  Legit bug in the Slime mold.  I'm pretty sure the code in
3423     Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it.  I figured out
3424     how to reproduce the problem and this file does appear to fix it.  I
3425     still need to run it by the person current maintainer (who isn't the
3426     author) for a sanity check.  Having you folks run it would be a good
3427     use-test.  I didn't compile the file.
3428
3429     On the LispM end, this also fixes the orphan TCP (FTP) connection bug,
3430     which accompanies the ITS/TWENEX manifestation.
3431
3432 I added this to our local 7-2-patches system.  It will get loaded into
3433 most machines here when they boot.
3434
3435     BTW, I think decreasing the file control lifetime would make the problem
3436     WORSE!!  (I'm not sure about that, though.)
3437
3438         Isn't it nice to have a network problem which ISN'T due to unix
3439         violating the spec?  At least this way we can get it fixed rather than
3440         be told "Look, it works with all the unix systems I try; you must have a
3441         problem at your end."
3442 \1f
3443 Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 14 Jun 88 17:20:16 EDT
3444 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
3445 Date: Tue, 14 Jun 88 17:15 EDT
3446 From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3447 Subject: File-Control-Lifetime "fix" for MC FTP connections
3448 To: David Vinayak Wallace <Gumby@MCC.COM>, Chris Lindblad <cjl@WHEATIES.AI.MIT.EDU>
3449 cc: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU,
3450     TJG@XX.LCS.MIT.EDU
3451 In-Reply-To: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM>
3452 Message-ID: <19880614211534.7.DCP@SWAN.SCRC.Symbolics.COM>
3453
3454     Date: Mon, 13 Jun 88 22:20 CDT
3455     From: David Vinayak Wallace <Gumby@MCC.COM>
3456
3457     The problem is with FILE connections, not GATEWAY connections.
3458
3459     From poking into it (my machine is one of the main instigators) it looks
3460     like only Symbolics' implementation of FTP is to blame.
3461
3462 Yup.  Legit bug in the Slime mold.  I'm pretty sure the code in
3463 Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it.  I figured out
3464 how to reproduce the problem and this file does appear to fix it.  I
3465 still need to run it by the person current maintainer (who isn't the
3466 author) for a sanity check.  Having you folks run it would be a good
3467 use-test.  I didn't compile the file.
3468
3469 On the LispM end, this also fixes the orphan TCP (FTP) connection bug,
3470 which accompanies the ITS/TWENEX manifestation.
3471
3472     Isn't it nice to have a network problem which ISN'T due to unix
3473     violating the spec?  At least this way we can get it fixed rather than
3474     be told "Look, it works with all the unix systems I try; you must have a
3475     problem at your end."
3476
3477 \1f
3478 Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 14 Jun 88 17:20:13 EDT
3479 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
3480 Date: Tue, 14 Jun 88 17:16 EDT
3481 From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3482 Subject: File-Control-Lifetime "fix" for MC FTP connections
3483 To: David Vinayak Wallace <Gumby@MCC.COM>, Chris Lindblad <cjl@WHEATIES.AI.MIT.EDU>
3484 cc: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU,
3485     TJG@XX.LCS.MIT.EDU
3486 In-Reply-To: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM>
3487 Supersedes: <19880614211534.7.DCP@SWAN.SCRC.Symbolics.COM>
3488 Message-ID: <19880614211637.8.DCP@SWAN.SCRC.Symbolics.COM>
3489
3490     Date: Mon, 13 Jun 88 22:20 CDT
3491     From: David Vinayak Wallace <Gumby@MCC.COM>
3492
3493     The problem is with FILE connections, not GATEWAY connections.
3494
3495     From poking into it (my machine is one of the main instigators) it looks
3496     like only Symbolics' implementation of FTP is to blame.
3497
3498 Yup.  Legit bug in the Slime mold.  I'm pretty sure the code in
3499 Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it.  I figured out
3500 how to reproduce the problem and this file does appear to fix it.  I
3501 still need to run it by the person current maintainer (who isn't the
3502 author) for a sanity check.  Having you folks run it would be a good
3503 use-test.  I didn't compile the file.
3504
3505 On the LispM end, this also fixes the orphan TCP (FTP) connection bug,
3506 which accompanies the ITS/TWENEX manifestation.
3507
3508 BTW, I think decreasing the file control lifetime would make the problem
3509 WORSE!!  (I'm not sure about that, though.)
3510
3511     Isn't it nice to have a network problem which ISN'T due to unix
3512     violating the spec?  At least this way we can get it fixed rather than
3513     be told "Look, it works with all the unix systems I try; you must have a
3514     problem at your end."
3515
3516 \1f
3517 Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 13 Jun 88 23:23:05 EDT
3518 Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 13 Jun 88 22:21:08-CDT
3519 Date: Mon, 13 Jun 88 22:20 CDT
3520 From: David Vinayak Wallace <Gumby@MCC.COM>
3521 Subject: File-Control-Lifetime "fix" for MC FTP connections
3522 To: Chris Lindblad <cjl@WHEATIES.AI.MIT.EDU>
3523 cc: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU,
3524     TJG@XX.LCS.MIT.EDU
3525 In-Reply-To: <19880613221658.4.CJL@OTIS.AI.MIT.EDU>
3526 Message-ID: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM>
3527
3528 The problem is with FILE connections, not GATEWAY connections.
3529
3530 From poking into it (my machine is one of the main instigators) it looks
3531 like only Symbolics' implementation of FTP is to blame.
3532
3533 Isn't it nice to have a network problem which ISN'T due to unix
3534 violating the spec?  At least this way we can get it fixed rather than
3535 be told "Look, it works with all the unix systems I try; you must have a
3536 problem at your end."
3537 \1f
3538 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 13 Jun 88 18:18:48 EDT
3539 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
3540 Date: Mon, 13 Jun 88 18:16 EDT
3541 From: Chris Lindblad <cjl@WHEATIES.AI.MIT.EDU>
3542 Subject: File-Control-Lifetime "fix" for MC FTP connections
3543 To: SRA@XX.LCS.MIT.EDU
3544 cc: Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU
3545 In-Reply-To: <12406136710.21.SRA@XX.LCS.MIT.EDU>
3546 Message-ID: <19880613221658.4.CJL@OTIS.AI.MIT.EDU>
3547 Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")
3548                          (2 0 (NIL 0) (:FIX :ITALIC :NORMAL) "CPTFONTI")
3549 Fonts: CPTFONT, CPTFONTCB, CPTFONTI
3550
3551     Date: Mon 13 Jun 88 11:44:20-EDT
3552     From: Rob Austein <SRA@xx.lcs.mit.edu>
3553
3554     My impression is that this really isn't enough, given that MC's hostname
3555     seems to be wired into two zillion pieces of Lispm code (at least, \ 61I
3556     can't find anything in the namespace that would explain the way lispms
3557     always offer to use MC as a gateway\ 60).  Also, the fact that this approach
3558     only works if every namespace that includes a reference to MC gets the
3559     update and nobody anywhere decides to make the lifetime longer again.
3560     Right.  I also believe in the tooth fairy....
3561
3562 The lisp machines use MC as a gatway because the namespace says it supports
3563 the TCP-GATEWAY service.
3564
3565 \ 62Showing HOST MC in namespace LCS:
3566 \ 60...
3567 \ 61Service: TCP-GATEWAY CHAOS TCP-GATEWAY
3568 \ 60...
3569
3570     But I figured I'd give somebody else a chance to tell me that I'm an
3571     ignorant barbarian and that the fix is sufficient.
3572
3573 I personally doubt the fix will be sufficient.
3574 \1f
3575 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 88 13:32:50 EDT
3576 Date: Mon 13 Jun 88 13:27:00-EDT
3577 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3578 Subject: Re: File-Control-Lifetime "fix" for MC FTP connections
3579 To: DCP@QUABBIN.SCRC.Symbolics.COM
3580 cc: maeda@MCC.COM, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU,
3581     TJG@XX.LCS.MIT.EDU
3582 In-Reply-To: <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM>
3583 Message-ID: <12406155402.19.SRA@XX.LCS.MIT.EDU>
3584
3585     Date: Mon, 13 Jun 88 13:01 EDT
3586     From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3587
3588     [Don't shoot the messenger!!  I intend to look into this when I get out
3589     from under a week's worth of mail.  But don't tell my co-workers that,
3590     nor as a promise I'll find a fix.]
3591
3592 On that basis, I'm still glad to hear this.  Thanks for whatever you
3593 find time to do....
3594
3595                                         Is it really easier to load a patch
3596     on ALL the machines than it is to change a FEW namespaces?
3597
3598 Moot point, since (almost) all the Tech Square Lispms do automatic
3599 world load installation.
3600
3601 In any case, it is definitely more permanent to fix the code, too many
3602 people can and do edit the namespace for me to trust anything that can
3603 wipe out an important machine this completely to a namespace entry.
3604
3605 Also, once we have a patch we can tell the owners of offending
3606 machines to either install the patch or lose access to MC.  At the
3607 moment there's no constructive action we can ask offenders to take.
3608 -------
3609 \1f
3610 Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM (TCP 20024224451) by AI.AI.MIT.EDU 13 Jun 88 13:04:35 EDT
3611 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
3612 Date: Mon, 13 Jun 88 13:01 EDT
3613 From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
3614 Subject: File-Control-Lifetime "fix" for MC FTP connections
3615 To: Christopher Maeda <maeda@MCC.COM>, SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU,
3616     Bug-Lispm@REAGAN.AI.MIT.EDU
3617 cc: TJG@XX.LCS.MIT.EDU
3618 In-Reply-To: <19880613161443.4.MAEDA@PELE.ACA.MCC.COM>
3619 Message-ID: <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM>
3620
3621     Date: Mon, 13 Jun 88 11:14 CDT
3622     From: Christopher Maeda <maeda@MCC.COM>
3623
3624     Umm, What should we hicks at MCC set our file control lifetimes for MC
3625     to?  Since we have such a large lab contingent here, our Texas based
3626     namespace features such favorites as XX, AI, and yes, MC.  Changing all
3627     those namespaces would be kind of hard, especially since ours is
3628     supposed to be secure against the outside world.
3629
3630 [Don't shoot the messenger!!  I intend to look into this when I get out
3631 from under a week's worth of mail.  But don't tell my co-workers that,
3632 nor as a promise I'll find a fix.]  Is it really easier to load a patch
3633 on ALL the machines than it is to change a FEW namespaces?
3634
3635     Give em hell, Rob,
3636     Chris
3637
3638 \1f
3639 Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 13 Jun 88 12:24:33 EDT
3640 Received: from PELE.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 13 Jun 88 11:15:54-CDT
3641 Date: Mon, 13 Jun 88 11:14 CDT
3642 From: Christopher Maeda <maeda@MCC.COM>
3643 Subject: File-Control-Lifetime "fix" for MC FTP connections
3644 To: SRA@XX.LCS.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU
3645 cc: TJG@XX.LCS.MIT.EDU
3646 In-Reply-To: <12406136710.21.SRA@XX.LCS.MIT.EDU>
3647 Message-ID: <19880613161443.4.MAEDA@PELE.ACA.MCC.COM>
3648
3649 Umm, What should we hicks at MCC set our file control lifetimes for MC
3650 to?  Since we have such a large lab contingent here, our Texas based
3651 namespace features such favorites as XX, AI, and yes, MC.  Changing all
3652 those namespaces would be kind of hard, especially since ours is
3653 supposed to be secure against the outside world.
3654
3655 Give em hell, Rob,
3656 Chris
3657 \1f
3658 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 88 11:43:38 EDT
3659 Date: Mon 13 Jun 88 11:44:20-EDT
3660 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3661 Subject: File-Control-Lifetime "fix" for MC FTP connections
3662 To: Bug-ITS@AI.AI.MIT.EDU, Bug-Lispm@REAGAN.AI.MIT.EDU
3663 cc: TJG@XX.LCS.MIT.EDU
3664 Message-ID: <12406136710.21.SRA@XX.LCS.MIT.EDU>
3665
3666 So, is the feeling that this workaround (setting file control lifetime
3667 to something short for MC) sufficient or should I yell at Symbolics
3668 some more?
3669
3670 My impression is that this really isn't enough, given that MC's hostname
3671 seems to be wired into two zillion pieces of Lispm code (at least, I
3672 can't find anything in the namespace that would explain the way lispms
3673 always offer to use MC as a gateway).  Also, the fact that this approach
3674 only works if every namespace that includes a reference to MC gets the
3675 update and nobody anywhere decides to make the lifetime longer again.
3676 Right.  I also believe in the tooth fairy....
3677
3678 But I figured I'd give somebody else a chance to tell me that I'm an
3679 ignorant barbarian and that the fix is sufficient.
3680
3681 --Rob
3682 -------
3683 \1f
3684 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 13 Jun 88 11:17:26 EDT
3685 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
3686 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
3687 Date: Mon, 13 Jun 88 08:13 PDT
3688 From: kao@VERMITHRAX.SCH.Symbolics.COM
3689 Subject: Re: This is important!
3690 To: SRA%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Customer-Reports@VERMITHRAX.SCH.Symbolics.COM
3691 cc: Bug-Lispm%REAGAN.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, Bug-ITS%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM,
3692     TJG%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM
3693 In-Reply-To: <12405426732.27.SRA@XX.LCS.MIT.EDU>
3694 References: <12405426732.27.SRA@XX.LCS.MIT.EDU>,
3695             <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3696 Message-ID: <19880613151342.8.KAO@BINKLEY.SCH.Symbolics.COM>
3697
3698     Date: Fri 10 Jun 88 18:44:18-EDT
3699     From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3700
3701         Date: Fri, 10 Jun 88 17:42 EDT
3702         From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3703         Subject: This is important!
3704         Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3705
3706         Please, please, please, do something about the bug where when a 3600 uses
3707         TCP/FTP as a file access path it sometimes starts up dozens of FTP servers
3708         on the file server.  Twice now I have found MC.LCS.MIT.EDU with all of its
3709         network connections used up because someone somewhere was using FTP to
3710         access files on MC (or on some remote machine with MC serving as a
3711         CHOAS/TCP gateway).
3712
3713         I would appreciate a fix for this problem -quickly- because MIT depends on
3714         MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally
3715         disables the machine.  This is the kind of problem where I can get somebody
3716         at MIT with an official sounding title to call you all up on the phone and
3717         lodge "official" complaints.
3718
3719     Ahem.
3720
3721     I, Robert Austein, Systems Programmer in the MIT Laboratory for
3722     Computer Science Computational Resources group, HostAdmin etcetera of
3723     MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this
3724     bug that Alan has reported ASAP and stop abusing the Mail Cruncher.
3725
3726     This is pretty clearly not a MIT-specific bug because I've seen this
3727     same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC
3728     in Austin, Texas.
3729
3730     If this request is not sufficient I'll kick this matter upstairs to
3731     the people who negotiate contracts with Symbolics and let them yell at
3732     you, but that's a lot of hassle for everybody so let's not.
3733
3734     RSVP ASAP.  Thanks.
3735
3736     --Rob
3737     -------
3738
3739 [Response from the developer.  Hope it helps.]
3740
3741 Certainly a quick work around for this would be to reduce the
3742 file-control-lifetime for MC to something less than 15 minutes and make
3743 sure all the machines see the namespace update.
3744
3745 To change FTP from using multiple connections would be a major
3746 architectural change and would divert from the norms used for other file
3747 protocols.  I don't think that multiple connections are the problem
3748 here, cleaning up after them is what is causing the pain.  There are
3749 some long standing bugs that are very difficult to reproduce and track
3750 down that affect connection cleanup for FTP connections.  The easiest
3751 work around that I know of is the short file-control-lifetime in the
3752 host object.
3753 \1f
3754 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 10 Jun 88 21:00:11 EDT
3755 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
3756 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
3757 Date: Fri, 10 Jun 88 17:57 PDT
3758 From: kao@VERMITHRAX.SCH.Symbolics.COM
3759 Subject: Re: This is important!
3760 To: SRA%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM
3761 cc: Customer-Reports@VERMITHRAX.SCH.Symbolics.COM, Bug-Lispm%REAGAN.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM,
3762     Bug-ITS%AI.AI.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM, TJG%XX.LCS.MIT.EDU@STONY-BROOK.SCRC.Symbolics.COM
3763 In-Reply-To: <12405426732.27.SRA@XX.LCS.MIT.EDU>
3764 Message-ID: <19880611005711.2.KAO@BINKLEY.SCH.Symbolics.COM>
3765
3766     Date: Fri 10 Jun 88 18:44:18-EDT
3767     From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3768
3769         Date: Fri, 10 Jun 88 17:42 EDT
3770         From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3771         Subject: This is important!
3772         Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3773
3774         Please, please, please, do something about the bug where when a 3600 uses
3775         TCP/FTP as a file access path it sometimes starts up dozens of FTP servers
3776         on the file server.  Twice now I have found MC.LCS.MIT.EDU with all of its
3777         network connections used up because someone somewhere was using FTP to
3778         access files on MC (or on some remote machine with MC serving as a
3779         CHOAS/TCP gateway).
3780
3781         I would appreciate a fix for this problem -quickly- because MIT depends on
3782         MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally
3783         disables the machine.  This is the kind of problem where I can get somebody
3784         at MIT with an official sounding title to call you all up on the phone and
3785         lodge "official" complaints.
3786
3787     Ahem.
3788
3789     I, Robert Austein, Systems Programmer in the MIT Laboratory for
3790     Computer Science Computational Resources group, HostAdmin etcetera of
3791     MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this
3792     bug that Alan has reported ASAP and stop abusing the Mail Cruncher.
3793
3794     This is pretty clearly not a MIT-specific bug because I've seen this
3795     same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC
3796     in Austin, Texas.
3797
3798     If this request is not sufficient I'll kick this matter upstairs to
3799     the people who negotiate contracts with Symbolics and let them yell at
3800     you, but that's a lot of hassle for everybody so let's not.
3801
3802     RSVP ASAP.  Thanks.
3803
3804     --Rob
3805     -------
3806
3807 Request noted. The bug-report/fix-request has been forwarded to the development
3808 people and software support supervisor.  We'll get back to you by the
3809 end of next week.
3810 \1f
3811 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Jun 88 18:43:20 EDT
3812 Date: Fri 10 Jun 88 18:44:18-EDT
3813 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3814 Subject: Re: This is important!
3815 To: Customer-Reports@STONY-BROOK.SCRC.SYMBOLICS.COM
3816 cc: Bug-Lispm@REAGAN.AI.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU, TJG@XX.LCS.MIT.EDU
3817 In-Reply-To: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3818 Message-ID: <12405426732.27.SRA@XX.LCS.MIT.EDU>
3819
3820     Date: Fri, 10 Jun 88 17:42 EDT
3821     From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3822     Subject: This is important!
3823     Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3824
3825     Please, please, please, do something about the bug where when a 3600 uses
3826     TCP/FTP as a file access path it sometimes starts up dozens of FTP servers
3827     on the file server.  Twice now I have found MC.LCS.MIT.EDU with all of its
3828     network connections used up because someone somewhere was using FTP to
3829     access files on MC (or on some remote machine with MC serving as a
3830     CHOAS/TCP gateway).
3831
3832     I would appreciate a fix for this problem -quickly- because MIT depends on
3833     MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally
3834     disables the machine.  This is the kind of problem where I can get somebody
3835     at MIT with an official sounding title to call you all up on the phone and
3836     lodge "official" complaints.
3837
3838 Ahem.
3839
3840 I, Robert Austein, Systems Programmer in the MIT Laboratory for
3841 Computer Science Computational Resources group, HostAdmin etcetera of
3842 MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this
3843 bug that Alan has reported ASAP and stop abusing the Mail Cruncher.
3844
3845 This is pretty clearly not a MIT-specific bug because I've seen this
3846 same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC
3847 in Austin, Texas.
3848
3849 If this request is not sufficient I'll kick this matter upstairs to
3850 the people who negotiate contracts with Symbolics and let them yell at
3851 you, but that's a lot of hassle for everybody so let's not.
3852
3853 RSVP ASAP.  Thanks.
3854
3855 --Rob
3856 -------
3857 \1f
3858 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 10 Jun 88 17:45:23 EDT
3859 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
3860 Date: Fri, 10 Jun 88 17:42 EDT
3861 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
3862 Subject: This is important!
3863 To: Bug-Lispm@REAGAN.AI.MIT.EDU, Customer-Reports@STONY-BROOK.SCRC.SYMBOLICS.COM
3864 cc: Bug-ITS@AI.AI.MIT.EDU
3865 Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU>
3866 Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY")
3867 Fonts: CPTFONT, TINY
3868
3869 \ 61In 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,
3870 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,
3871 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,
3872 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),
3873 FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233,
3874 Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2)
3875 on Symbolics 3640 #5233 (Hilbert's Nullstellensatz):
3876
3877 \ 60Please, please, please, do something about the bug where when a 3600 uses
3878 TCP/FTP as a file access path it sometimes starts up dozens of FTP servers
3879 on the file server.  Twice now I have found MC.LCS.MIT.EDU with all of its
3880 network connections used up because someone somewhere was using FTP to
3881 access files on MC (or on some remote machine with MC serving as a
3882 CHOAS/TCP gateway).
3883
3884 I would appreciate a fix for this problem -quickly- because MIT depends on
3885 MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally
3886 disables the machine.  This is the kind of problem where I can get somebody
3887 at MIT with an official sounding title to call you all up on the phone and
3888 lodge "official" complaints.
3889 \1f
3890 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 25 May 88 18:17:27 EDT
3891 Date: Wed 25 May 88 18:17:03-EDT
3892 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
3893 Subject: Re: TCB's all in use.
3894 To: SRA@XX.LCS.MIT.EDU, ALAN@AI.AI.MIT.EDU
3895 cc: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU,
3896     ZVONA@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
3897 In-Reply-To: <12400803897.66.SRA@XX.LCS.MIT.EDU>
3898 Message-ID: <12401227468.31.JNC@XX.LCS.MIT.EDU>
3899
3900         Rob, your analysis is 100% on the money, and your selected fix
3901 also appears to be the Right Thing. I suggest we do that.
3902
3903         Noel
3904 -------
3905 \1f
3906 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 May 88 03:30:15 EDT
3907 Date: Tue 24 May 88 03:30:19-EDT
3908 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3909 Subject: Re: TCB's all in use.
3910 To: ALAN@AI.AI.MIT.EDU
3911 cc: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU,
3912     ZVONA@AI.AI.MIT.EDU
3913 In-Reply-To: <384099.880524.ALAN@AI.AI.MIT.EDU>
3914 Message-ID: <12400803897.66.SRA@XX.LCS.MIT.EDU>
3915
3916 The code itself is per spec, although it may not be sufficiently
3917 paranoid.  See RFC 793, pages 38-39.  It includes a diagram which is
3918 somewhat easier to follow than the text:
3919
3920 Figure 13 "Normal Close Sequence":
3921
3922       TCP A                                                TCP B
3923
3924   1.  ESTABLISHED                                          ESTABLISHED
3925
3926   2.  (Close)
3927       FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT
3928
3929   3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT
3930
3931   4.                                                       (Close)
3932       TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK
3933
3934   5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED
3935
3936   6.  (2 MSL)
3937       CLOSED
3938
3939 ITS is party "A" in this case.  COMSAT tells ITS "close this
3940 connection", ITS sends off a FIN.  Party "B" ACKs the packet but
3941 doesn't ACK the FIN until it feels like it (closing is half-duplex).
3942 When party "B" decides to close too, it sends a FIN to ITS (note the
3943 odd sequence numbers here).  ITS is supposed to ACK this FIN so that
3944 party "B" knows the connection has indeed been closed in everybody's
3945 opinion (ie, FIN is considered data to the extent that must be ACKed).
3946 So ITS sends the ACK and goes into the TIME-WAIT state.  If ITS hears
3947 nothing for a certain period of time ("2 MSL") ITS assumes
3948 everything's cool and punts the TCB.  If, however, ITS gets another
3949 FIN from party "B", ITS must assume that the ACK ITS just sent got
3950 lost, so ITS sends another ACK and resets the timer.
3951
3952 Whew.  No wonder so many implementers get confused by this!
3953
3954 It is easy to see how a misbehaving TCP on party "B" could keep us
3955 wedged here forever.
3956
3957 The RFC says that the only thing you can get when in a TIME-WAIT state
3958 is a retransmission of the other party's FIN.  Perhaps the ITS code
3959 takes that for a law of nature rather than a description of two
3960 working TCPs having a conversation.
3961
3962 It would be interesting to know if the packet that caused us to get to
3963 TSIATW is really the {FIN,ACK} packet we're assuming.  If not I'd
3964 think that's immediate grounds for dropping the connection on the
3965 floor, since it demonstrates that at least one party is seriously
3966 confused about the current state.
3967
3968 If it really is a FIN that we keep getting over and over and over, it
3969 might be reasonable to keep track of how many times we've gone through
3970 this routine and just punt when it gets ridiculous.  I think this is
3971 even legitimate: either the foreign machine is broken or the
3972 intervening path is consistantly losing our ACKs, and in either case
3973 it won't do any good to send more ACKs so we might as well not bother.
3974
3975
3976 Of course this is the first time I've ever tried to follow all those
3977 silly state diagrams in TCP, so I might be completely confused.
3978
3979 --Rob
3980 -------
3981 \1f
3982 Date: Tue, 24 May 88 01:47:53 EDT
3983 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3984 Subject:  TCB's all in use.
3985 To: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
3986 cc: GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
3987 Message-ID: <384099.880524.ALAN@AI.AI.MIT.EDU>
3988
3989 Here is my diagnosis of the lossage.  Consider the following code:
3990
3991     ; TSIATW - Received ACK while in TIME-WAIT state.  This should be
3992     ;       a re-transmit of the remote FIN.  ACK it, and restart
3993     ;       2-MSL timeout.
3994
3995     TSIATW: METER("TCP: ACK in .XSTMW")
3996             MOVSI T,(TC%ACK)
3997             TRCPKT R,"TSIATW ACK send in TIME-WAIT"
3998             CALL TSOSNR             ; Send simple ACK in response.
3999             JRST TSITM2             ; and restart 2-MSL timeout.
4000
4001 Well, if the guy on the other end keeps sending you ACKs, the timeout keeps
4002 getting reset and the TCB never gets freed.  I have verified that this is
4003 in fact the path that causes the problem by patching that JRST TSITM2 to be
4004 a POPJ P, and watching the stuck TCB's all vanish.
4005
4006 I actually don't understand the logic here, it would seem to me that you
4007 should only be sending an ACK for a actual FIN, not just an ACK.  I didn't
4008 look to see if the other guy was sending both ACK and FIN or just ACK.  Do
4009 you suppose it is likely that the other machines all have this bug as well
4010 and the two are just spinning their wheels bouncing ACKs back an forth?
4011
4012 There does seem to be other code that handles ACKing of FINs elsewhere in
4013 the the TCP code, but I don't understand enough to know if it is active
4014 when you are in the TIME-WAIT state or not.  Conceivably the POPJ P, I
4015 patched in might be the solution to the problem?
4016
4017 Suggestions?
4018 \1f
4019 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 23 May 88 14:20:00 EDT
4020 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
4021 Date: Mon, 23 May 88 14:14 EDT
4022 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
4023 Subject: What's with all these TIMWTs?
4024 To: GUMBY@AI.AI.MIT.EDU
4025 cc: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
4026 In-Reply-To: <424674.880523.GUMBY0@MC.LCS.MIT.EDU>
4027 Message-ID: <19880523181422.3.ALAN@PIGPEN.AI.MIT.EDU>
4028
4029     Date: Mon, 23 May 88 04:23:59 EDT
4030     From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4031     Right now there are 26 connections to unix.sri.com in state TIMWT, plus,
4032     plus one in FINWT1 to ub.cc.umich.edu.
4033     ...
4034     There really only looks like there are two lost packets (one to host 0!).
4035     ...
4036
4037 Its not a question of lost packets, its a question of TCBs, the
4038 per-connection data-structure ITS has to maintain throughout the
4039 connection's lifetime.  Unfortunately a connection can live on after a user
4040 process is done with it while the operating systems do some final
4041 handshaking to close things down cleanly.  It appears that some new version
4042 of Unix is making the rounds that does something that causes this
4043 handshaking to take virtually forever.
4044
4045 AI and MC each have 30 TCB's.  They used to have 20, but I increased that
4046 when this problem first started happening.  I just had to reload AI for the
4047 same reason.  There are crash dumps for the interested in
4048 AI:CRASH;CRASH TCB and MC:CRASH;TCP BITIT.
4049 \1f
4050 Date: Mon, 23 May 88 13:09:29 EDT
4051 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4052 To: BUG-ITS@AI.AI.MIT.EDU
4053 Message-ID: <383531.880523.ZVONA@AI.AI.MIT.EDU>
4054
4055 FTP just failed, complaining that "all sockets in use".  Peek showed
4056 only two FILE jobs an do FTPs besides mine.  What's going on?  How
4057 do I fix it?
4058 \1f
4059 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 88 04:05:23 EDT
4060 Date: Wed, 11 May 88 16:23:09 EDT
4061 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4062 Subject:  And you thought PDUMP finally worked.
4063 To: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU
4064 cc: ZVONA@MC.LCS.MIT.EDU
4065 Message-ID: <418741.880511.ALAN@MC.LCS.MIT.EDU>
4066
4067 Note the -times- in the following consecutive entries from the mailer STATS
4068 file on MC.
4069
4070     084735  Note: GC'ing MSGS, 5646555-1620312=4026243
4071     145143   ===> BUG: FATAL ERROR <===  Date: 05/11/88 14:51:42
4072             Autopsy from 22770 Preserved from 22061
4073             Last UUO = 017100,,062447 at 52657
4074
4075 MC was low on disk space at the time, which is probably what caused the
4076 original error, but what do you suppose was happening during the 6 hour
4077 pause?  I'll guess that there is a bug in the PDUMP system call (probably
4078 also having to do with low disk space) that kept COMSAT hung until Zvona
4079 logged in and noticed the problem.  Probably something he did to try and
4080 diagnose the problem PCLSR'd the call, and then it finished.
4081
4082 \1f
4083 Date: Wed, 20 Apr 88 14:43:01 EDT
4084 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4085 To: BUG-ITS@AI.AI.MIT.EDU
4086 Message-ID: <362739.880420.ZVONA@AI.AI.MIT.EDU>
4087
4088 AI is out of disk space again.  I noticed while deleting OSTATS to make
4089 some room that LISTS MSGS is 628 blocks, which seems big.
4090 \1f
4091 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU  3 Apr 88 18:26:05 EDT
4092 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
4093 Date: Sun, 3 Apr 88 18:22 EDT
4094 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
4095 Subject: MD down until further notice.
4096 To: Bug-ITS@AI.AI.MIT.EDU
4097 Message-ID: <880403182202.3.ALAN@DESCARTES.AI.MIT.EDU>
4098
4099 MD's RP06 won't load its heads.  I don't currently have the time to
4100 investigate this problem further.  Being MD, it isn't a very critical
4101 problem.
4102
4103 I guess we should be happy that it is always MD that breaks.
4104
4105 \1f
4106 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 29 Mar 88 13:23:17 EST
4107 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
4108 Date: Tue, 29 Mar 88 13:19 EST
4109 From: Chris Lindblad <CJL@REAGAN.AI.MIT.EDU>
4110 Subject: Some history questions.
4111 To: bug-its@AI.AI.MIT.EDU, bug-twenex@OZ.AI.MIT.EDU
4112 Message-ID: <880329131943.9.CJL@OTIS.AI.MIT.EDU>
4113
4114 I'm trying to track down the history of file version numbers, and of delete
4115 and expunge.
4116
4117 Was it really Tenex that invented the features of file version numbers and
4118 delete-and-expunge?
4119
4120 Or did file versions in the second name of files appear in ITS before Tenex,
4121 or was the idea inspired by Tenex?
4122
4123 Can anyone point me to an early Tenex paper describing these features?  Any
4124 ITS papers?
4125
4126 \1f
4127 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Mar 88 11:35:46 EST
4128 Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Mar 88 11:24:33 EST
4129 Date: Sat, 12 Mar 88 11:24:38 EST
4130 From: "Christopher M. Maeda" <MAEDA@AI.AI.MIT.EDU>
4131 Subject: UMass ITS's
4132 To: mike@OZ.AI.MIT.EDU
4133 cc: info-its@MC.LCS.MIT.EDU
4134 Message-ID: <340451.880312.MAEDA@AI.AI.MIT.EDU>
4135
4136 I heard of a pretty big Intelligent Tutoring Systems effort
4137 going on at UMass.  I have the paper at home if you want it.
4138 They aren't really doing anything new, just applying AI to a
4139 new area.  The most interesting thing about the paper is that
4140 they continually use the acronym ITS to describe their systems.
4141
4142 Chris
4143
4144 \1f
4145 Received: from MEAD.SCRC.Symbolics.COM (TCP 20024224752) by AI.AI.MIT.EDU  7 Mar 88 15:58:19 EST
4146 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
4147 Date: Mon, 7 Mar 88 15:57 EST
4148 From: Ed Schwalenberg <Ed@MEAD.SCRC.Symbolics.COM>
4149 Subject: Re: [ota: SPACE Digest V8 #156]
4150 To: Rob Austein <SRA@XX.LCS.MIT.EDU>, MAEDA@AI.AI.MIT.EDU
4151 cc: postmaster@MC.LCS.MIT.EDU, MarkL@ALLSPICE.LCS.MIT.EDU,
4152     Info-ITS@AI.AI.MIT.EDU
4153 In-Reply-To: <12380322663.23.SRA@XX.LCS.MIT.EDU>
4154 Message-ID: <880307155748.0.ED@BLACK-BIRD.SCRC.Symbolics.COM>
4155
4156     Date: Sun 6 Mar 88 23:23:32-EST
4157     From: Rob Austein <SRA@XX.LCS.MIT.EDU>
4158
4159         Date: Sun,  6 Mar 88 14:22:49 EST
4160         From: "Christopher M. Maeda" <MAEDA@AI.AI.MIT.EDU>
4161
4162         The following was posted to space digest in a discussion about
4163         remote logins to the moon.,,
4164     [Note COMSAT ".." lossage here^^.]
4165
4166             From: tektronix!reed!douglas@ucbvax.berkeley.edu  (P Douglas Reeder)
4167             Subject: Re: data and long distances
4168
4169             The distance problem applies to satelites in geosynchonous
4170             orbit, as well.  radio wave take a noticeable fraction of a
4171             second to get there and back.  That would play hell with high
4172             baud rates if not accounted for.  A comsat expert might know
4173             how it's done.
4174
4175     For interplanetary stuff you'd want to use a batched mail protocol
4176     like BSMTP over a high bandwidth transmission protocol like NETBLT for
4177     mail.  You could probably get away with SMTP to Lunagrad (Moonbase
4178     doesn't look like it's going to be an issue any time soon).
4179
4180     Remote login will be bad no matter what.  The best you could do would
4181     be something like RMS's local editing protocol, again using something
4182     like NETBLT for transmission so that at least screen updates would be
4183     fast once they arrived.
4184
4185 I actually tried using a computer in Miami from Antarctica via a geosynch
4186 satellite.  It was, er, painful.  But I did a fun experiment too: I did
4187 an analog loopback through the satellite, and watched my characters echo
4188 on the screen.  Then I tried typing a character, and while it was on its
4189 way up and back I digitally looped back my end.  After about 6 passes the
4190 character would begin to decay:
4191         aaaaaabp~~~~~~<rubout><rubout><rubout>
4192 Another satellite hacker (the gentleman in Miami) ran a PDP-11 to the satellite,
4193 ran the analog downlink back up to another channel on the same satellite, then
4194 to a terminal, for a total delay of about .75 sec.
4195 \1f
4196 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  6 Mar 88 23:50:25 EST
4197 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  6 Mar 88 23:32:24 EST
4198 Date: Sun 6 Mar 88 23:23:32-EST
4199 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
4200 Subject: Re: [ota: SPACE Digest V8 #156]
4201 To: MAEDA@AI.AI.MIT.EDU
4202 cc: info-its@MC.LCS.MIT.EDU, postmaster@MC.LCS.MIT.EDU,
4203     MarkL@ALLSPICE.LCS.MIT.EDU
4204 In-Reply-To: <336939.880306.MAEDA@AI.AI.MIT.EDU>
4205 Message-ID: <12380322663.23.SRA@XX.LCS.MIT.EDU>
4206
4207     Date: Sun,  6 Mar 88 14:22:49 EST
4208     From: "Christopher M. Maeda" <MAEDA@AI.AI.MIT.EDU>
4209
4210     The following was posted to space digest in a discussion about
4211     remote logins to the moon.,,
4212 [Note COMSAT ".." lossage here^^.]
4213
4214         From: tektronix!reed!douglas@ucbvax.berkeley.edu  (P Douglas Reeder)
4215         Subject: Re: data and long distances
4216
4217         The distance problem applies to satelites in geosynchonous
4218         orbit, as well.  radio wave take a noticeable fraction of a
4219         second to get there and back.  That would play hell with high
4220         baud rates if not accounted for.  A comsat expert might know
4221         how it's done.
4222
4223 For interplanetary stuff you'd want to use a batched mail protocol
4224 like BSMTP over a high bandwidth transmission protocol like NETBLT for
4225 mail.  You could probably get away with SMTP to Lunagrad (Moonbase
4226 doesn't look like it's going to be an issue any time soon).
4227
4228 Remote login will be bad no matter what.  The best you could do would
4229 be something like RMS's local editing protocol, again using something
4230 like NETBLT for transmission so that at least screen updates would be
4231 fast once they arrived.
4232
4233 You might also want to ask somebody at BBN about the current tuning of
4234 the ARPANET (net 10.0.0.0 itself): one of the three transcontinental
4235 channels is a comsat link, the other two are land lines, and all hell
4236 broke loose for the few days between when they installed the comsat
4237 link and when they got it tuned properly.
4238 -------
4239
4240 \1f
4241 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  6 Mar 88 20:20:27 EST
4242 Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  6 Mar 88 19:56:02 EST
4243 Date: Sun,  6 Mar 88 14:22:49 EST
4244 From: "Christopher M. Maeda" <MAEDA@AI.AI.MIT.EDU>
4245 Subject:  [ota: SPACE Digest V8 #156]
4246 To: info-its@MC.LCS.MIT.EDU, postmaster@MC.LCS.MIT.EDU
4247 Message-ID: <336939.880306.MAEDA@AI.AI.MIT.EDU>
4248
4249
4250 The following was posted to space digest in a discussion about
4251 remote logins to the moon.,,
4252
4253         From: tektronix!reed!douglas@ucbvax.berkeley.edu  (P Douglas Reeder)
4254         Subject: Re: data and long distances
4255
4256         The distance problem applies to satelites in geosynchonous
4257         orbit, as well.  radio wave take a noticeable fraction of a
4258         second to get there and back.  That would play hell with high
4259         baud rates if not accounted for.  A comsat expert might know
4260         how it's done.
4261
4262 Chris
4263
4264
4265 \1f
4266 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 Feb 88 12:29:35 EST
4267 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
4268 Date: Fri, 26 Feb 88 12:26 EST
4269 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
4270 Subject: What the heck is this?
4271 To: BUG-ITS@AI.AI.MIT.EDU
4272 Message-ID: <880226122631.0.ALAN@PIGPEN.AI.MIT.EDU>
4273
4274 These connections to ELBERETH.RUTGERS.EDU have been in this state since
4275 sometime yesterday.  I'm going to take a crash dump into
4276 AI:CRASH;TCP ELBERE and reload the system so that we can free up some
4277 network channels.
4278
4279
4280 AI ITS 1615  Peek 629   2/26/88 11:14:28  Up time = 19:21:17:00
4281 IMP is up.   TCP/IP is available.
4282 Ix Usr Uname  Jname  State   RWnd Ibf SWnd ReTxQ Lclprt Fgnprt Fgnhst
4283  5   6 15TLNT TELSER OPEN    5170  0 10000 0   0     27   2012 MONK.PROTEON.COM
4284  4  20 406T20 TCP    OPEN   11324  0 10000 0   0  10263     31 ATHENA.MIT.EDU
4285  0  24 406T24 TCP    SYNSNT  5170  0     0 1   0  12264     31 WALKER-EMH.ARPA
4286 23                   TIMWT   5170  0 20000 0   0     31   6150 ELBERETH.RUTGERS.EDU
4287 22                   TIMWT   5170  0 20000 0   0     31   3302 ELBERETH.RUTGERS.EDU
4288 21                   TIMWT   5170  0 20000 0   0     31   5746 ELBERETH.RUTGERS.EDU
4289 20                   TIMWT   5170  0 20000 0   0     31   3305 ELBERETH.RUTGERS.EDU
4290 17                   TIMWT   5170  0 20000 0   0     31  10021 TOPAZ.RUTGERS.EDU
4291 16                   TIMWT   5170  0 20000 0   0     31   6717 ELBERETH.RUTGERS.EDU
4292 15                   TIMWT   5170  0 20000 0   0     31   5712 ELBERETH.RUTGERS.EDU
4293 14                   TIMWT   5170  0 20000 0   0     31  11164 ELBERETH.RUTGERS.EDU
4294 13                   TIMWT   5170  0 20000 0   0     31  11602 ELBERETH.RUTGERS.EDU
4295 12                   TIMWT   5170  0 20000 0   0     31  10312 ELBERETH.RUTGERS.EDU
4296 11                   TIMWT   5170  0 20000 0   0     31  11407 ELBERETH.RUTGERS.EDU
4297 10                   TIMWT   5170  0 20000 0   0     31   5727 ELBERETH.RUTGERS.EDU
4298  7                   TIMWT   5170  0 20000 0   0     31  10614 ELBERETH.RUTGERS.EDU
4299  6                   TIMWT   5170  0 20000 0   0     31  11226 ELBERETH.RUTGERS.EDU
4300  3                   TIMWT   5170  0 20000 0   0     31   5235 ELBERETH.RUTGERS.EDU
4301  2                   TIMWT   5170  0 20000 0   0     31  10015 ELBERETH.RUTGERS.EDU
4302  1                   TIMWT   5170  0 20000 0   0     31  10340 ELBERETH.RUTGERS.EDU
4303 8 buffers (7 free)
4304
4305 STY Map
4306     Idx    STY owner   Idx    STY user    Host
4307 T15   6 15TLNT TELSER   12 JNC    CHTN    MONK.PROTEON.COM (TCP)
4308 T16  13 16TLNT TELSER   23 ALAN   P       PIGPEN.AI.MIT.EDU (Chaos)
4309
4310 \1f
4311 Date: Thu, 25 Feb 88 15:27:46 EST
4312 From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
4313 To: BUG-ITS@AI.AI.MIT.EDU
4314 Message-ID: <331879.880225.DEVON@AI.AI.MIT.EDU>
4315
4316 Suddenly AI is refusing telnet connections and reporting
4317 TCP: SYN queue full
4318 on the console, fairly often.  I have never noticed this before.
4319 \1f
4320 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 24 Feb 88 16:42:34 EST
4321 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
4322 Date: Wed, 24 Feb 88 16:39 EST
4323 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
4324 Subject: weird MC TCP lossage
4325 To: GUMBY@AI.AI.MIT.EDU
4326 cc: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU
4327 In-Reply-To: <331156.880224.GUMBY@AI.AI.MIT.EDU>
4328 Message-ID: <880224163949.6.ALAN@PIGPEN.AI.MIT.EDU>
4329
4330     Date: Wed, 24 Feb 88 06:25:47 EST
4331     From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
4332     ...  The stats file was very interesting.  COMSAT would wake up,
4333     connect to some host, deliver all the mail for that host, and then
4334     choke when it got to the next host for which it had mail.  The way in
4335     which it choked was interesting:  After the HELO it would read the
4336     terminating command from the previous connection.
4337
4338 This is the usual situation when some TCP resource runs out.  Opening a new
4339 pair of TCP channels fails, probably with some kind of device full error,
4340 which COMSAT apparently fumbles to produce this behavior.  At least, that's
4341 my theory.  SRA claims that the code in COMSAT couldn't possibly have this
4342 bug, and it must be ITS's fault, but I find this hard to believe given that
4343 no other program that uses TCP shows any kind of analogous behavior.
4344
4345 Unfortunately, it is hard to reproduce this situation so that we can see
4346 what COMSAT is -really- doing.
4347
4348     ...  I called someone on the ninth floor to ask him to take a crash
4349     dump, but mc appears not to have come back up....
4350
4351 It looks like it did come back up, but whoever you talked to was typing
4352 total jokes on the console.  Like giving nonexistent commands, and typing
4353 DDT commands to the 8080 front-end, etc.
4354
4355 \1f
4356 Date: Wed, 24 Feb 88 06:25:47 EST
4357 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
4358 Subject:  weird MC TCP lossage
4359 To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU
4360 Message-ID: <331156.880224.GUMBY@AI.AI.MIT.EDU>
4361
4362 I was unable to get any sort of tcp connection to MC this morning.
4363 Chaosnet worked fine.  I logged in; the machine was idle!  Early
4364 morning is often a busy time for ol'MC.
4365
4366 I spied on COMSAT, which was idle most of the time.  The stats file
4367 was very interesting.  COMSAT would wake up, connect to some host,
4368 deliver all the mail for that host, and then choke when it got to the
4369 next host for which it had mail.  The way in which it choked was
4370 interesting:  After the HELO it would read the terminating command
4371 from the previous connection.
4372
4373 For example COMSAT connected to DECWRL.DEC.COM and apparently
4374 delivered lots of mail successfully (one wonders what it was actually
4375 sending, but the remote host seemed happy).  Anyway, when done with
4376 decwrl.dec.com, it tried to talk to some other host, say, bbn.com.
4377 The stats file would say something like "ICP BBN.COM: Bad reply 221
4378 decwrl.dec.com signing off."
4379
4380 Well, this was certainly weird.  I called someone on the ninth floor
4381 to ask him to take a crash dump, but mc appears not to have come back
4382 up.  I don't know what the story is, but it seemed to be happy running
4383 in this weird state.  Perhaps our local TCP frobber can shed some
4384 light on this.
4385 \1f
4386 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Jan 88 13:46:41 EST
4387 Date: Thu, 28 Jan 88 13:46:28 EST
4388 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4389 Subject:  AI disk problems
4390 To: BUG-ITS@MC.LCS.MIT.EDU
4391 Message-ID: <364291.880128.GUMBY@MC.LCS.MIT.EDU>
4392
4393 (most of the people who need to see this can't because ai is down,
4394 but...)
4395
4396 AI's  drive 0 won't spin up.  I was unable to bring the system up with
4397 pack 0 on the other drive; ITS gets some sort of massbus error.
4398
4399 david
4400
4401 \1f
4402 Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 22 Jan 88 19:25:17 EST
4403 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
4404 Date: Fri, 22 Jan 88 19:26 EST
4405 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
4406 Subject: Ho ho ho
4407 To: ZVONA@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU
4408 cc: BUG-ITS@AI.AI.MIT.EDU
4409 In-Reply-To: <314839.880122.ZVONA@AI.AI.MIT.EDU>,
4410              <12368693472.13.SRA@XX.LCS.MIT.EDU>
4411 Message-ID: <880122192612.1.ALAN@THE-JOKER.AI.MIT.EDU>
4412
4413     Date: Fri, 22 Jan 88 14:27:24 EST
4414     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4415     Oh, wow, blast from the past department.  We just ran out of
4416     disk space on AI.  Maybe it's time to start running GFR?
4417
4418 I just moved some of the free space from SECOND: to the primary pack.  I
4419 will be happy to explain to anybody else (in person) how to do this.
4420
4421     Date: Fri 22 Jan 88 14:42:29-EST
4422     From: Rob Austein <SRA@XX.LCS.MIT.EDU>
4423     Penny ran GFR once or twice, a year or so ago, back when we moved all
4424     the sources from MX to AI and discovered how much space that took up.
4425     I don't think we've been running it on a regular basis, because there
4426     hasn't been a need.
4427
4428 "Hasn't been a need".  Ho ho ho.  We've been doing GFR's to tape every few
4429 months for quite some time now.
4430
4431 \1f
4432 Date: Fri, 22 Jan 88 14:27:24 EST
4433 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4434 To: BUG-ITS@AI.AI.MIT.EDU
4435 Message-ID: <314839.880122.ZVONA@AI.AI.MIT.EDU>
4436
4437 Oh, wow, blast from the past department.  We just ran out of
4438 disk space on AI.  Maybe it's time to start running GFR?
4439 \1f
4440 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  3 Jan 88 11:25:32 EST
4441 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  3 Jan 88 11:24:55 EST
4442 Date: Sun 3 Jan 88 11:24:16-EST
4443 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
4444 Subject: Re: Wanted: ITS license
4445 To: lysator@obelix.liu.se, bug-its@MC.LCS.MIT.EDU,
4446     enea!obelix!lysator@uunet.uu.net
4447 cc: JNC@XX.LCS.MIT.EDU
4448 In-Reply-To: <8801021756.AA27872@obelix.liu.se>
4449 Message-ID: <12363676652.29.JNC@XX.LCS.MIT.EDU>
4450
4451         You don't need a license of any kind to run ITS; the software
4452 is free and you can pass it around as you like. Just get the pack from
4453 Per and have fun! (Make sure he gives you all the sources!) Please let
4454 us know how you do if you get the machine; we'll be very interested to
4455 hear. We're all extremely pleased to see ITS catching on over in
4456 Europe; it was almost dead and gone at one point.
4457
4458         Noel
4459 -------
4460
4461 \1f
4462 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  2 Jan 88 14:42:15 EST
4463 Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU  2 Jan 88 14:42:01 EST
4464 Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
4465         id AA20668; Sat, 2 Jan 88 14:41:15 EST
4466 Received: by enea.se (5.57++/1.14)
4467         id AA14398; Sat, 2 Jan 88 19:58:45 +0100 (MET)
4468 Received: from asterix.liu.se by majestix.liu.se; Sat, 2 Jan 88 19:03:35 +0100
4469 Received: from obelix.liu.se by asterix.liu.se; Sat, 2 Jan 88 19:01:55 +0100
4470 Received: by obelix.liu.se; Sat, 2 Jan 88 18:56:51 SST
4471 Date: Sat, 2 Jan 88 18:56:51 SST
4472 From: Lysator <lysator@obelix.liu.se>
4473 Message-Id: <8801021756.AA27872@obelix.liu.se>
4474 To: bug-its@mc.lcs.mit.edu
4475 Subject: Wanted: ITS license
4476
4477 Hello!
4478 We - the computer club Lysator at Linkoping university, Sweden - would
4479 like to apply for an ITS license. We hope this is the right place
4480 for this request.
4481 We hope to acquire the following system in the near future:
4482 A DEC-2020, serial nr 04655, one or two TU45 and two or more RP06.
4483 We would like our system's name to be LI.
4484
4485 Peter Lothberg@stacken will hopefully assemble ITS for us on an
4486 rp06 pack, provided we get a license.
4487
4488 Please reply to lysator@obelix.LIU.SE (in the UUCP domain).
4489 Addition to this mailinglist (and others about ITS?) would be nice.
4490
4491 Thank you.
4492
4493 \1f
4494 Date: Sun, 29 Nov 87 03:10:04 EST
4495 From: John Wroclawski <JTW@AI.AI.MIT.EDU>
4496 Subject: More TCP stuff
4497 To: BUG-ITS@AI.AI.MIT.EDU
4498 Message-ID: <292213.871129.JTW@AI.AI.MIT.EDU>
4499
4500 I added a bunch of stuff to TCP to "optimize" (guess) the best packet
4501 size based on the path to the foreign entity, and to send and
4502 understand TCP max seg size options.  In the past, it has just used
4503 the minimum possible value everywhere to be safe. This has the effect
4504 of roughly doubling the potential throughput to MIT and arpanet hosts.
4505 On the other hand, this is all kinda heuristic, and one could imagine
4506 some problems...
4507
4508 If you could talk to AI well last week and you can't now, please send
4509 a note before assuming you are being screwed by the arpanet.
4510 \1f
4511 Date: Fri, 27 Nov 87 00:08:15 EST
4512 From: John Wroclawski <JTW@AI.AI.MIT.EDU>
4513 To: BUG-ITS@AI.AI.MIT.EDU
4514 Message-ID: <291890.871127.JTW@AI.AI.MIT.EDU>
4515
4516 ITS 1606 (NITS on AI at the moment) has a new IMP driver. Hopefully this
4517 will fix up the bad IMPOS crashes and improve the lost TCP buffer
4518 problem some. (And it's faster, too!)
4519
4520 Please collect crashdumps of anything that looks like an IP/IMP
4521 screwup and send a note to bug-its...
4522
4523 Oh yeah, the NET command in LOCK actually does something useful now, you
4524 might try it first if you think the arpanet is unhappy.
4525 \1f
4526 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Nov 87 16:54:10 EST
4527 Date: Sun, 15 Nov 1987  16:50 EST
4528 Message-ID: <SRA.12350891071.BABYL@XX.LCS.MIT.EDU>
4529 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
4530 To:   Bug-ITS@AI.AI.MIT.EDU
4531 Subject: [malis: new Arpanet end to end protocol ]
4532
4533 Follow up....
4534
4535 Date: Tue, 10 Nov 87 09:49:17 -0500
4536 From: Andy Malis <malis@CC5.BBN.COM>
4537 To:   Charles Hedrick <hedrick@ARAMIS.RUTGERS.EDU>
4538 cc:   tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
4539 Re:   new Arpanet end to end protocol
4540
4541 Charles,
4542
4543 Your message is quite wrong (I know - I designed the new
4544 End-to-End).  I would be interested in knowing (in private) who
4545 your "reliable source" is, so that such rumors can be source
4546 quenched.  After the recent messages on the tcp-ip list, I'm sure
4547 we all realize how important source quenching is.
4548
4549 The truth of the matter is:
4550
4551 PSN 7.0 has two different End-to-End protocols (old EE and new
4552 EE).  Either one or the other runs at any particular time, and
4553 the two cannot interoperate.  The ARPANET is currently using PSN
4554 7.0 with the old EE.  It is the new EE that will be tested on
4555 Nov. 7, 14-15, and 18.
4556
4557 The old EE protocol explicitly returned, across the PSN subnet, a
4558 separate RFNM packet for each message delivered to a destination
4559 host.  This RFNM packet was then converted, in the source PSN,
4560 into the 1822 RFNM for that message and delivered to the source
4561 host.  This had the result that, depending on traffic mixes,
4562 roughly about 45% to 50% of the packets going through the subnet
4563 were RFNMs.  Since the PSN does so much per-packet processing,
4564 even for these RFNMs, the network was passing much less host
4565 traffic than otherwise might be possible.
4566
4567 We fixed this in the new EE by making it an explicitly windowed
4568 protocol IN THE SUBNET.  The destination PSNs have the ability to
4569 aggregate ACKs (the new EE internal equivalent to RFNMs) and send
4570 multiple ACKs for the same connection in windowed ACK (by using
4571 an INTERNAL message sequence number).  In addition, these ACKs
4572 can now be piggybacked on data traffic, and many ACKs for
4573 different EE connections can be shipped together in the same
4574 subnet packet to a source PSN.
4575
4576 The important thing to note is that when the destination PSN
4577 receives an ACK for a connection, it generates, and sends to the
4578 source host, a separate 1822 RFNM for EACH and EVERY message
4579 submitted by the host and being acknowledged by the ACK.  There
4580 are no host-visible sequence numbers; the 1822 protocol stays the
4581 same as before.
4582
4583 What may have confused you is the fact that we at BBN are,
4584 concurrent with the PSN 7.0 testing, trying to track down which
4585 ARPANET hosts might be affected by a known BSD 4.2 network
4586 software problem that may cause RFNMs to be lost in the host
4587 itself (I believe it is related to the size of the message
4588 received PREVIOUS to the RFNM).  This bug has been fixed in BSD
4589 4.3, and I have been told that Lars Poulsen of ACC
4590 (lars@acc.arpa) has a patch for BSD 4.2-derived host software.
4591
4592 By the way, we have measured in our internal BBNNET (which has
4593 been running PSN 7.0 with the new EE only for over five months
4594 now) that only about 14% of the packets through the network only
4595 contain ACKs - the rest of the ACKs are being piggybacked on the
4596 data traffic.  We are very pleased with this result.  Also, most
4597 of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and
4598 others) use 1822, and they have had no problems with the new EE.
4599
4600 Regards,
4601 Andy
4602 \1f
4603 Date: Mon,  9 Nov 87 13:37:05 EST
4604 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4605 Subject:  MC:CRASH;PI FAULT
4606 To: BUG-ITS@AI.AI.MIT.EDU
4607 cc: MAP@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU
4608 In-reply-to: Msg of Mon  9 Nov 87 12:36:25 EST from Michael A.  Patton <MAP at AI.AI.MIT.EDU>
4609 Message-ID: <282278.871109.ALAN@AI.AI.MIT.EDU>
4610
4611     Date: Mon,  9 Nov 87 12:36:25 EST
4612     From: Michael A.  Patton <MAP at AI>
4613     I just reloaded MC.  It had gotten a "PAGE FAULT WITH PI IN PROGRESS".
4614     Dump is in MC:CRASH;PI FAULT.  Seems to have restarted all right.
4615
4616 This one is a good joke that has happened once before.  The fault was taken
4617 by the TCP checksumming code.  Presumably what happens is that when a
4618 packet arrives with a large enough bogus length, the checksumming code
4619 applies the checksumming algorithm to a huge block of memory that starts
4620 with the packet and extends up to some nonexistent page.
4621 \1f
4622 Date: Mon,  9 Nov 87 12:36:25 EST
4623 From: "Michael A.  Patton" <MAP@AI.AI.MIT.EDU>
4624 Sender: MAP0@AI.AI.MIT.EDU
4625 To: BUG-ITS@AI.AI.MIT.EDU
4626 cc: MAP@AI.AI.MIT.EDU
4627 Message-ID: <282226.871109.MAP0@AI.AI.MIT.EDU>
4628
4629 I just reloaded MC.  It had gotten a "PAGE FAULT WITH PI IN PROGRESS".
4630 Dump is in MC:CRASH;PI FAULT.  Seems to have restarted all right.
4631 \1f
4632 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU  6 Nov 87 17:11:29 EST
4633 Received: from SRI-NIC.ARPA (TCP 1200000063) by MC.LCS.MIT.EDU  6 Nov 87 17:10:23 EST
4634 Date: Fri, 6 Nov 87 13:54:46 PST
4635 From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
4636 Subject: [hedrick@aramis.rutgers.edu (Charles Hedrick): new Arpanet end to end protocol]
4637 To: bug-tcp@MC.LCS.MIT.EDU
4638 cc: bug-its@MC.LCS.MIT.EDU
4639 Message-ID: <12348532467.31.KLH@SRI-NIC.ARPA>
4640
4641 If this message is true, ITS systems will have problems, since the
4642 IMP code counts RFNMs.  I guess new code would need to be added which
4643 (depending on a runtime flag setting) handles the new scheme.  But someone
4644 needs to find out exactly what the new scheme is first...
4645                 ---------------
4646
4647 Received: from aramis.rutgers.edu by SRI-NIC.ARPA with TCP; Fri 6 Nov 87 12:06:51-PST
4648 Received: by athos.rutgers.edu (5.54/1.14)
4649         id AA24392; Fri, 6 Nov 87 02:20:54 EST
4650 Date: Fri, 6 Nov 87 02:20:54 EST
4651 From: hedrick@aramis.rutgers.edu (Charles Hedrick)
4652 Message-Id: <8711060720.AA24392@athos.rutgers.edu>
4653 To: tcp-ip@sri-nic.arpa
4654 Subject: new Arpanet end to end protocol
4655
4656 I have just heard from a reliable source a fairly interesting fact
4657 about the new end to end protocol implemented in PSN 7.0.  (Note that
4658 my terminology is probably slightly off in this message.  I don't know
4659 anything about the imp to host protocol, so I am almost certainly
4660 introducing some distortion in passing on this information.)
4661 Apparently one of the efficiency improvements in the new end to end
4662 protocol is that the IMP's will no longer attempt to return a RFNM for
4663 each packet.  You will be expected to look at the ID number included
4664 in the RFNM's.  Any outstanding RFNM's with ID numbers lower than the
4665 current one are also to be considered as acknowledged.  Many
4666 implementations apparently simply count RFNM's.  They assume that one
4667 acknowledgement is received per packet.  This will no longer be true
4668 with the new end to end protocol, and so these implementations will
4669 break.  I have some reason to think that most existing implementations
4670 fall into this category.  Tests of the new end to end protocol are
4671 scheduled for Nov 7, 14-15, and 18.  Implementors should be alert to
4672 misbehaviors during these test periods.
4673 -------
4674
4675 \1f
4676 Date: Mon,  2 Nov 87 15:48:24 EST
4677 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4678 Subject:  DIR device
4679 To: PGS@AI.AI.MIT.EDU
4680 cc: BUG-ITS@AI.AI.MIT.EDU
4681 In-reply-to: Msg of Sat 31 Oct 87 16:42:38 EST from Patrick G. Sobalvarro <PGS at AI.AI.MIT.EDU>
4682 Message-ID: <278714.871102.ALAN@AI.AI.MIT.EDU>
4683
4684     Date: Sat, 31 Oct 87 16:42:38 EST
4685     From: Patrick G. Sobalvarro <PGS at AI.AI.MIT.EDU>
4686     ^R dir:pgs; name2 @ doesn't get me a listing of the files on my directory
4687     whose second name is @.  This used to work, and NAME1 still does work.
4688
4689 That's cause DIR:PGS;SECOND @ is how you get a listing of the files on your
4690 directory whose second name is @.  DIR:PGS;FIRST FOO is how you get a
4691 listing of the files on your directory whose first name is FOO.
4692 DIR:PGS;NAME1 and DIR:PGS;NAME2 give directory listings -sorted- (not
4693 -filtered-) by first or second filename.  (For example DIR:PGS;NAME1 DOWN
4694 generates a listing of your directory backwards.)
4695 \1f
4696 Date: Sat, 31 Oct 87 16:42:38 EST
4697 From: "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>
4698 Subject:  DIR device
4699 To: BUG-ITS@AI.AI.MIT.EDU
4700 Message-ID: <278089.871031.PGS@AI.AI.MIT.EDU>
4701
4702 ^R dir:pgs; name2 @ doesn't get me a listing of the files on my directory
4703 whose second name is @.  This used to work, and NAME1 still does work.
4704 \1f
4705 Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 27 Oct 87 02:52:35 EST
4706 Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 26 Oct 87 23:49:58 PST
4707 Date: Mon, 26 Oct 87 23:06:19 PST
4708 From: Mark Crispin <MRC@PANDA.COM>
4709 Subject: Re: ITS outlives Multics?!
4710 To: GUMBY@AI.AI.MIT.EDU
4711 cc: Info-ITS@AI.AI.MIT.EDU
4712 In-Reply-To: <275589.871027.GUMBY@AI.AI.MIT.EDU>
4713 Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
4714 Phone: +1 (415) 968-1052
4715 Message-ID: <12345749289.8.MRC@PANDA.COM>
4716
4717 TOPS-10 and TOPS-20 both support 30-bit address spaces (although the KL
4718 CPU only allows 23).  Having written a large program using 30-bit addressing,
4719 I can assure you it isn't as kludgy as its detractors claim, and certainly a
4720 lot cleaner than some of the current faddish architectures.
4721
4722 I'm sure some bright hacker could figure out how to convert ITS to 30-bit
4723 addressing.
4724 -------
4725 \1f
4726 Date: Tue, 27 Oct 87 01:30:27 EST
4727 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
4728 Subject:  ITS outlives Multics?!
4729 To: "MRC@PANDA.COM"@AI.AI.MIT.EDU
4730 cc: INFO-ITS@AI.AI.MIT.EDU
4731 In-reply-to: Msg of Mon 26 Oct 87 10:04:15 PST from Mark Crispin <MRC at PANDA.COM>
4732 Message-ID: <275589.871027.GUMBY@AI.AI.MIT.EDU>
4733
4734     Date: Mon, 26 Oct 87 10:04:15 PST
4735     From: Mark Crispin <MRC at PANDA.COM>
4736
4737     We'll need some new CPU's though.  36-bits are decidedly out of fashion
4738     at Stanford, but perhaps there are some MIT VLSI hackers who might want
4739     to make a PDP-10 on a chip?
4740
4741 But the 18-bit address space is a lose.  Since you're making a new
4742 chip or chip set anyway, why not double the word length?  36-bit
4743 halfwords should keep people happy for a while.  We could have more
4744 registers, too.
4745 \1f
4746 Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 26 Oct 87 14:16:23 EST
4747 Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 26 Oct 87 11:08:04 PST
4748 Date: Mon, 26 Oct 87 10:04:15 PST
4749 From: Mark Crispin <MRC@PANDA.COM>
4750 Subject: Re: ITS outlives Multics?!
4751 To: ALAN@AI.AI.MIT.EDU
4752 cc: INFO-ITS@AI.AI.MIT.EDU
4753 In-Reply-To: <275113.871026.ALAN@AI.AI.MIT.EDU>
4754 Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
4755 Phone: +1 (415) 968-1052
4756 Message-ID: <12345606917.6.MRC@PANDA.COM>
4757
4758 That sounds good.  I'm sure the ITS hackers in 2155 will be able to think
4759 of something clever to solve the problem then.  TOPS-20's date format
4760 dies at the last 1/3 second of Wednesday, 7 August 2576 GMT (here on the
4761 west coast, just before 5PM PDT), so we have almost 589 years to worry
4762 about that.
4763
4764 We'll need some new CPU's though.  36-bits are decidedly out of fashion
4765 at Stanford, but perhaps there are some MIT VLSI hackers who might want
4766 to make a PDP-10 on a chip?
4767 -------
4768 \1f
4769 Date: Mon, 26 Oct 87 11:58:03 EST
4770 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4771 Subject:  ITS outlives Multics?!
4772 To: MRC@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU
4773 In-reply-to: Msg of Sun 25 Oct 87 13:59:55 PST from Mark Crispin <MRC at PANDA.COM>
4774 Message-ID: <275113.871026.ALAN@AI.AI.MIT.EDU>
4775
4776     Date: Sun, 25 Oct 87 13:59:55 PST
4777     From: Mark Crispin <MRC at PANDA.COM>
4778     ...
4779     I was quoted in a trade journal as saying that PANDA/TOPS-20
4780     will see the century tick.  What about ITS?  We're going to
4781     have to do something about that sixbit date format, you know!
4782
4783 (I intend to continue using ITS into retirement...)
4784
4785 The SIXBIT date format you are thinking of (from the .RDATE uuo) is for
4786 simple programs that want the date in MM/DD/YY format.  I presume that on
4787 January 1, 2000 those programs will want to print the date as 01/01/00, so
4788 this isn't a problem.
4789
4790 There are two other date formats.  The .RYEAR uuo returns the year as an
4791 18-bit quantity, so that will work for quite some time.  The other, more
4792 common, date format is the one used by the filesystem, and by programs that
4793 used the DATIME library; this is the format returned by the RQDATE system
4794 call.  This format packs the year, less 1900, in a 7-bit field, so this
4795 will last through 2027.  Since the bit to the left of the year field is
4796 unused, we can easily expand this to last through 2155.
4797
4798 Probably the most we will have to do is fix a few user programs that have
4799 the string "19" built into them.
4800 \1f
4801 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 26 Oct 87 11:35:46 EST
4802 Date: Mon 26 Oct 87 11:33:40-EST
4803 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
4804 Subject: Re: ML on the arpanet?
4805 To: ALAN@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU
4806 cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
4807 In-Reply-To: <275092.871026.ALAN@AI.AI.MIT.EDU>
4808 Message-ID: <12345590429.43.JNC@XX.LCS.MIT.EDU>
4809
4810         Right; they are around $10K or some such fabulous amount.
4811 The first one was one Marty bought and which got snarfed; I got
4812 ACC to donate the second one.
4813         If you want the other machine IP live why not write code
4814 to run an Interlan Ethernet card or something? I gave JTW a Pronet-10
4815 card; they are massively simple to program but nothing ever came of
4816 it.
4817                 Noel
4818 -------
4819 \1f
4820 Date: Mon, 26 Oct 87 11:18:20 EST
4821 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4822 Subject:  ML on the arpanet?
4823 To: GUMBY@AI.AI.MIT.EDU
4824 cc: BUG-ITS@AI.AI.MIT.EDU
4825 In-reply-to: Msg of Mon 26 Oct 87 02:22:12 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
4826 Message-ID: <275092.871026.ALAN@AI.AI.MIT.EDU>
4827
4828     Date: Mon, 26 Oct 87 02:22:12 EST
4829     From: David Vinayak Wallace <GUMBY at MC>
4830     Since Multics is going away can we snarf its imp port?
4831
4832 Wouldn't do us any good unless we can find another LH/DH.
4833 \1f
4834 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 87 02:23:04 EST
4835 Date: Mon, 26 Oct 87 02:22:12 EST
4836 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4837 Subject: ML on the arpanet?
4838 To: BUG-ITS@MC.LCS.MIT.EDU
4839 Message-ID: <316281.871026.GUMBY@MC.LCS.MIT.EDU>
4840
4841 Since Multics is going away can we snarf its imp port?
4842 \1f
4843 Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 25 Oct 87 17:23:27 EST
4844 Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Sun, 25 Oct 87 14:21:06 PST
4845 Date: Sun, 25 Oct 87 13:59:55 PST
4846 From: Mark Crispin <MRC@PANDA.COM>
4847 Subject: ITS outlives Multics?!
4848 To: INFO-ITS@AI.AI.MIT.EDU
4849 Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
4850 Phone: +1 (415) 968-1052
4851 Message-ID: <12345387677.6.MRC@PANDA.COM>
4852
4853 I just got a message from the Multics postmaster saying that
4854 MIT-Multics will be shut down on 31 December.  Athough it was
4855 inevitable it is still rather sad.  I find it somewhat ironic
4856 though that today, years after ITS was declared dead, there
4857 are more ITS systems in operation (even excluding the part-time
4858 systems) than ever.
4859
4860 I was quoted in a trade journal as saying that PANDA/TOPS-20
4861 will see the century tick.  What about ITS?  We're going to
4862 have to do something about that sixbit date format, you know!
4863 -------
4864 \1f
4865 Date: Wed, 14 Oct 87 15:02:26 EDT
4866 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4867 Subject:  Not to worry
4868 To: ZVONA@AI.AI.MIT.EDU
4869 cc: BUG-ITS@AI.AI.MIT.EDU
4870 In-reply-to: Msg of Mon 12 Oct 87 21:41:19 EDT from David Chapman <ZVONA at AI.AI.MIT.EDU>
4871 Message-ID: <269232.871014.ALAN@AI.AI.MIT.EDU>
4872
4873     Date: Mon, 12 Oct 87 21:41:19 EDT
4874     From: David Chapman <ZVONA at AI.AI.MIT.EDU>
4875     AI is getting frequent ECC corrected errors (one every few minutes) in
4876     consistent places on the disk.  Looks dangerous to me.
4877
4878 No worry.  A block with an ECC error needs special attention every time it
4879 is read.  ITS doesn't try to avoid using such blocks, so sometimes we get
4880 unlucky and a block with an ECC error gets used either in a file that needs
4881 to be touched frequently, or as a swapping block.  As long as it doesn't
4882 become an outrageous waste of paper, there isn't any problem.
4883 \1f
4884 Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 OCT 87  23:07:48 EDT
4885 Date: Mon 12 Oct 87 22:58:19-EDT
4886 From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
4887 To: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
4888 In-Reply-To: <268383.871012.ZVONA@AI.AI.MIT.EDU>
4889 Message-ID: <12342034127.16.JTW@MIT-SPEECH>
4890
4891     From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4892     To: BUG-ITS@AI.AI.MIT.EDU
4893
4894     AI crashed with BUGHLT Bad IMPOS, 2.  I dumped to crash;bad impos2.
4895     Booted OK.
4896
4897 This is known braindamange on my part related to the fact that I
4898 didn't notice that someone called a particular TCP routine from clock
4899 level when I wrote the IMP driver.
4900
4901 However, the machine should recover OK if you just $P it, rather than
4902 needing to reboot.
4903
4904         -john
4905 -------
4906 \1f
4907 Date: Mon, 12 Oct 87 21:41:19 EDT
4908 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4909 To: BUG-ITS@AI.AI.MIT.EDU
4910 Message-ID: <268387.871012.ZVONA@AI.AI.MIT.EDU>
4911
4912 AI is getting frequent ECC corrected errors (one every few minutes) in
4913 consistent places on the disk.  Looks dangerous to me.
4914 \1f
4915 Date: Mon, 12 Oct 87 21:32:01 EDT
4916 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
4917 To: BUG-ITS@AI.AI.MIT.EDU
4918 Message-ID: <268383.871012.ZVONA@AI.AI.MIT.EDU>
4919
4920 AI crashed with BUGHLT Bad IMPOS, 2.  I dumped to crash;bad impos2.
4921 Booted OK.
4922 \1f
4923 Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU  4 Oct 87 04:28:25 EDT
4924 Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Sun, 4 Oct 87 01:16:03 PDT
4925 Date: Sat, 3 Oct 87 23:08:38 PDT
4926 From: Mark Crispin <MRC@PANDA.COM>
4927 Subject: Re: The operating system that wouldn't die!  AAAAIIIIEEEEEE!!!!!
4928 To: ALAN@AI.AI.MIT.EDU
4929 cc: INFO-ITS@AI.AI.MIT.EDU, gls@THINK.COM
4930 In-Reply-To: <264420.871003.ALAN@AI.AI.MIT.EDU>
4931 Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
4932 Phone: +1 (415) 968-1052
4933 Message-ID: <12339709477.6.MRC@PANDA.COM>
4934
4935 Well, you know, we have to start thinking about what will happen
4936 when the century ticks.  I'm determined that TOPS-20 on PANDA will
4937 see it tick, which means fixing any bugs that have two-digit years.
4938 The question is, how will ITS handle it?
4939
4940 I think it will be damn funny if our 36-bit "dinosaurs" just tick
4941 the century and keep on smiling, while every Unix system in the
4942 world crashes!!!
4943
4944 -- Mark --
4945 -------
4946 \1f
4947 Received: from TB.CC.CMU.EDU (TCP 20000576442) by AI.AI.MIT.EDU  4 Oct 87 04:22:14 EDT
4948 Date: Sun 4 Oct 87 04:14:20-EDT
4949 From: Cthulhu <AD0R@TB.CC.CMU.EDU>
4950 Subject: its on a ka10
4951 To: info-its@AI.AI.MIT.EDU
4952 Message-ID: <12339732358.19.AD0R@TB.CC.CMU.EDU>
4953
4954
4955 It's amazing enough that they got the ka10 running.  I think they've got all
4956 core in that lovely machine.  These are truly wonderful people.
4957
4958 -------
4959 \1f
4960 Date: Sat,  3 Oct 87 23:02:14 EDT
4961 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4962 Subject:  The operating system that wouldn't die!  AAAAIIIIEEEEEE!!!!!
4963 To: INFO-ITS@AI.AI.MIT.EDU, gls@THINK.COM
4964 In-reply-to: Msg of Fri 2 Oct 87 11:34:35 EDT from gls at Think.COM
4965 Message-ID: <264420.871003.ALAN@AI.AI.MIT.EDU>
4966
4967     Date: Fri, 2 Oct 87 11:34:35 EDT
4968     From: gls at Think.COM
4969     To:   bug-its at ai.ai.mit.edu
4970     I just got my "Happy Birthday" message from Puff the Magic Dragon at AI.
4971     Maybe I'm silly, but this has made me very happy today.  It's nice that
4972     someone cared enough to set up the software so I get a message every year.
4973     (I think I am also affected by nostalgia for my days at MIT.)
4974     --Guy
4975
4976 Well a message like this is certainly guaranteed to make -my- day!  It's
4977 always nice to have people appreciate creaky-but-reliable old ITS for still
4978 being around after 20 years!
4979
4980 I thought I would take this opportunity to spread the word about something
4981 that I don't think has been very widely publicized.  Some of you may recall
4982 that a while ago some fellows in Sweden contacted us about running ITS on
4983 various PDP-10's that they owned?  Well, we mailed them a set of tapes for
4984 bringing up ITS on their 2020, which they were able to do without too much
4985 trouble (their biggest problem was -my- fault).  That all happened over a
4986 year ago.  Recently we learned that these guys have successfully -built-
4987 ITS paging hardware for their KA-10, and have ITS up and running there as
4988 well!  Totally Amazing.
4989 \1f
4990 Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU  2 Oct 87 15:57:56 EDT
4991 Return-Path: <gls@Think.COM>
4992 Received: from kali.think.com by Think.COM; Fri, 2 Oct 87 11:34:16 EDT
4993 Received: by kali.think.com; Fri, 2 Oct 87 11:34:35 EDT
4994 Date: Fri, 2 Oct 87 11:34:35 EDT
4995 From: gls@Think.COM
4996 Message-Id: <8710021534.AA06791@kali.think.com>
4997 To: bug-its@ai.ai.mit.edu
4998 Subject: Many thanks
4999
5000 I just got my "Happy Birthday" message from Puff the Magic Dragon at AI.
5001 Maybe I'm silly, but this has made me very happy today.  It's nice that
5002 someone cared enough to set up the software so I get a message every year.
5003 (I think I am also affected by nostalgia for my days at MIT.)
5004
5005 --Guy
5006 \1f
5007 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 29 Sep 87 20:03:45 EDT
5008 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 29 Sep 87 19:55:19 EDT
5009 Date: Tue, 29 Sep 1987  19:51 EDT
5010 Message-ID: <SRA.12338592166.BABYL@XX.LCS.MIT.EDU>
5011 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
5012 To:   BUG-ITS@MC.LCS.MIT.EDU
5013 Subject: SUPDUP/ITSTTY enhancement
5014
5015 I doubt this will ever get anywhere (too many rlogin fans out there)
5016 but just in case, I thought I ought to send it to the people who
5017 actually decide what SUPDUP looks like.
5018
5019 --Rob
5020
5021 To: Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
5022 Cc: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>, tcp-ip@SRI-NIC.ARPA
5023 Re: RCTE and stranger things
5024
5025 I was going to say something about that, but decided to wait to see if
5026 anybody had in fact read Dave's message.  You did, so here goes.
5027
5028 Yes, SUPDUP as specified in the RFC is character at a time.  However,
5029 I believe that a very minor enhancement to the protocol would handle
5030 that problem.  The big advantages of SUPDUP (sales pitch) are that (1)
5031 it works in a heterogenous environment (thus is better than rlogin),
5032 and (2) has a wider view of the terminal than just the print head of a
5033 hardcopy TTY (thus is better than TELNET).  In particular, there are a
5034 whole set of useful options under the heading of "The Intelligent
5035 Terminal Protocol".  Not all of these are documented in the SUPDUP
5036 RFCs, for a full explanation of the ITS terminal system see the file
5037 "MC: INFO; ITSTTY >" on MC.LCS.MIT.EDU.  It's a bit long, so if you're
5038 not up for a lot of reading, you want the parts on "Control of the
5039 TTY" and "The Intelligent Terminal Protocol".
5040
5041 The model I'm using for the local/remote echo and wakup problem is the
5042 TOPS-20 TEXTI% JSYS, which was mentioned obliquely a few messages ago
5043 when somebody referred to TOPS-20 EMACS enhancements.  For those who
5044 aren't familiar with TOPS-20, one of the arguments to TEXTI% is a
5045 break mask, a 128 bit vector indicating which characters should cause
5046 the TEXTI% call to return.  I believe that the EMACS extentions that
5047 were mentioned were based on an extension to TEXTI% which would cause
5048 any character with the meta bit (octal 200) turned on to act as a
5049 wakeup.  I may be wrong about this, I've never seen the code.
5050
5051 Presumably the entity that decides what the break mask should be is
5052 the server (where applications programs are running) while the entity
5053 that implements the break mask is the client (where the physical
5054 display terminal is).  So presumably the "change the break mask"
5055 sequence would begin with a %TDxxx code.  I can't think of any reason
5056 why the client would want to tell the server about break masks, but if
5057 so the process would be identical except for the escape character (a
5058 30x code, presumably).  Henceforth I'll refer to the entity sending
5059 the break mask as the "sender" and the entity receiving the break mask
5060 as the "recipient".
5061
5062 For the 12 bit character set SUPDUP permits, a complete break mask
5063 would be rather cumbersome, but there's a natural way to compress
5064 this.  Make the first data byte a flag byte, with one flag per bucky
5065 bit, one flag for characters with no bucky bits, and two unused bits.
5066 The flag bits indicate which bucky bits the sender wants the client to
5067 try to optimize; if a flag bit is set, a break mask is supplied, if a
5068 flag is cleared, no break mask is supplied and the receiver should
5069 fall back to the default behavior (wake on every character).  The most
5070 common message would presumably be one with the no-bucky-bit and
5071 control-bucky-bit flags set and all others cleared, indicating that
5072 any meta, super, or hyper characters are wakeups.  In general, if a
5073 program doesn't expect to see a class of characters, it should
5074 probably wake up on them so that it can tell the user about typing
5075 errors ASAP.
5076
5077 The flag byte is followed by a series of break masks (128 bits in 16
5078 bytes, presumably).  For completeness, this would have to be separate
5079 break masks for each case that the sender has indicated in the flag
5080 byte; ie, just because the sender wants to break on CONTROL-A and
5081 META-A doesn't mean the server wants to break on CONTROL-META-A.  This
5082 is part of the reason for the flag byte, so that the sender needn't
5083 send a lot of masks that are all ones.
5084
5085 All SUPDUP connections would still start out in character at a time
5086 remote echo mode.  Setting the break mask requests local echo of any
5087 characters that are not breaks.  Break characters are still handled
5088 remotely.  Setting the break mask with a zero flag byte (and thus no
5089 following masks) would put the connection back in the default
5090 character at a time mode.
5091
5092 One extension of this idea would be incremental changes to the break
5093 mask; if anybody cares enough to do it, there's always the two unused
5094 bits in the flag byte.  But the above covers the basic scheme.
5095
5096 Yes, a similar mechanism could be used in TELNET, without having to
5097 think about 12 bit characters and bucky bits, but TELNET is really not
5098 a very good model for a display terminal.  SUPDUP (and the abstract
5099 model of terminals and capabilities that underlies it) is a much
5100 better model.  I think the existing software speaks for itself.
5101
5102 --Rob
5103
5104 \1f