1 Copyright (c) 1999 Massachusetts Institute of Technology
3 This program is free software; you can redistribute it and/or modify
4 it under the terms of the GNU General Public License as published by
5 the Free Software Foundation; either version 3 of the License, or (at
6 your option) any later version.
8 This program is distributed in the hope that it will be useful, but
9 WITHOUT ANY WARRANTY; without even the implied warranty of
10 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
11 General Public License for more details.
13 You should have received a copy of the GNU General Public License
14 along with this program; if not, write to the Free Software
15 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
16 ------------------------------
18 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Sep 87 11:29:30 EDT
19 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Sep 87 11:26:37 EDT
20 Mail-From: RICCHIO created at 18-Sep-87 11:19:09
21 Date: Fri 18 Sep 87 11:19:09-EDT
22 From: Joe Ricchio <RICCHIO@XX.LCS.MIT.EDU>
23 Subject: MC/MD maintenance
24 To: SRA@XX.LCS.MIT.EDU
25 cc: Ricchio@XX.LCS.MIT.EDU
26 Message-ID: <12335615391.18.RICCHIO@XX.LCS.MIT.EDU>
27 ReSent-Date: Fri 18 Sep 87 11:23:07-EDT
28 ReSent-From: Rob Austein <SRA@XX.LCS.MIT.EDU>
29 ReSent-To: Postmaster@MC.LCS.MIT.EDU, Liaison@MC.LCS.MIT.EDU,
30 Bug-ITS@MC.LCS.MIT.EDU
31 ReSent-Message-ID: <12335616112.55.SRA@XX.LCS.MIT.EDU>
33 Rob, Lester has scheduled Tuesday 9-22-87 @ 9AM for PM to the RP06
34 drives. Hope this is agreeable wiht you. If not please advise. Thanks
40 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Aug 87 06:34:11 EDT
41 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 7 Aug 87 04:26:56 EDT
42 Date: Thu, 6 Aug 1987 21:52 EDT
43 Message-ID: <SRA.12324458461.BABYL@XX.LCS.MIT.EDU>
44 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
46 Cc: info-its@MC.LCS.MIT.EDU
47 Subject: Unix catching up to ITS
48 In-reply-to: Msg of 6 Aug 1987 14:00-EDT from barmar@Think.COM
50 No, that's the USR: device. But they've invented the JOB: device too,
51 something called "portals" I think.
53 As Noel Chiappa said when talking about ITS and Multics, it's really
54 kind of scary to think that we are just now catching up to what we
55 were able to do twenty years ago.
58 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Aug 87 19:01:31 EDT
59 Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 6 Aug 87 18:06:10 EDT
60 Return-Path: <barmar@Think.COM>
61 Received: from godot.think.com by Think.COM; Thu, 6 Aug 87 14:00:44 EDT
62 Received: by godot.think.com; Thu, 6 Aug 87 14:00:39 EDT
63 Date: Thu, 6 Aug 87 14:00:39 EDT
64 From: barmar@Think.COM
65 Message-Id: <8708061800.AA08725@godot.think.com>
66 To: info-its@mc.lcs.mit.edu
67 Subject: Unix catching up to ITS
69 I read the following in the Usenet newsgroup comp.unix.wizards (== to
70 the Arpanet mailing list UNIX-WIZARDS). AT&T has finally "invented"
73 Article 3409 of comp.unix.wizards:
74 Path: think!husc6!seismo!mnetor!utzoo!henry
75 From: henry@utzoo.UUCP (Henry Spencer)
76 Newsgroups: comp.unix.wizards
77 Subject: /proc, /n/face
78 Message-ID: <8285@utzoo.UUCP>
79 Date: 10 Jul 87 19:06:20 GMT
80 References: <7879@brl-adm.ARPA> <2211@bunker.UUCP>, <6043@brl-smoke.ARPA>, <8244@utzoo.UUCP>
81 Organization: U of Toronto Zoology
84 > V8 /proc preserves the semantics of a normal Unix directory setup *exactly*,
85 > unless I missed something subtle when I read the code. My impression is that
86 > /n/face does likewise. In both cases the directory hierarchy is actually a
87 > figment of the kernel's imagination, but it is a consistent figment with the
88 > same semantics as normal directories.
90 Several people have asked what this is about, so I suppose I should elaborate
91 a bit. This stuff has been presented in papers at Usenix conferences, but
92 not everybody's familiar with those.
94 /proc is V8's replacement for the ptrace() system call and related things.
95 It's a slightly-odd type of file system. Once mounted, it looks like a
96 single directory containing a bunch of files with numeric names. If you
97 open (say) file "12345", you are looking at the address space of process
98 number 12345. Writes into the file are writes into the address space.
99 There are ioctls for things like stopping and starting the process, sending
100 it signals, etc. Access to the files is naturally subject to the standard
101 Unix file-permission system. The whole thing is actually a figment of the
102 kernel's imagination, with the "directory" manufactured on the fly whenever
103 someone tries to read it, and operations on the "files" turned into the
104 corresponding operations on the processes. Apart from being cleaner than
105 ptrace(), /proc is also faster.
107 [description of /n/face deleted]
109 In both cases, these odd filesystems look exactly like real ones, down to
110 things like "." and ".." entries in the directories. You can use all the
111 standard Unix tools to operate on them.
113 At least one System V implementation of /proc exists inside AT&T, but it
114 hasn't made it into any released software that I know of. I believe /n/face
115 is strictly a V8ism at the moment.
117 Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology
118 finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
123 Date: Sun, 2 Aug 87 20:34:10 EDT
124 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
125 Subject: IP routing table
126 To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU,
128 In-reply-to: Msg of Wed 15 Jul 87 01:55 EDT from Alan Bawden <ALAN@AI>
129 Message-ID: <236463.870802.ALAN@AI.AI.MIT.EDU>
131 Date: Wed, 15 Jul 87 01:55 EDT
132 From: Alan Bawden <ALAN at AI>
137 (If anyone can think of a good directory for this to live on other than
138 ALAN, let me know.)...
140 It finally occured to me that the right directory for something like this
141 is the one named ".". (Remember ":.;BOOT11" on the KL?) So make that:
145 to fool with IP routing.
147 Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by AI.AI.MIT.EDU 23 Jul 87 09:17:08 EDT
148 Received: from ROCKY-MOUNTAINS.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123996; Thu 23-Jul-87 08:59:35 EDT
149 Date: Thu, 23 Jul 87 08:55 EDT
150 From: Allan C. Wechsler <ACW@WAIKATO.S4CC.Symbolics.COM>
151 Subject: Musings on history
152 To: tk@STONY-BROOK.SCRC.Symbolics.COM,
153 marker%random.s1.gov@mordor.s1.gov, ED@AI.AI.MIT.EDU
154 cc: BUG-ITS@AI.AI.MIT.EDU, SIPB@mc.lcs.mit.edu
155 In-Reply-To: <870722140244.3.TK@CUCKOO.SCRC.Symbolics.COM>
156 Message-ID: <870723085519.1.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>
158 Date: Wed, 22 Jul 87 14:02 EDT
159 From: Tom Knight <tk@STONY-BROOK.SCRC.Symbolics.COM>
160 Date: Tue, 21 Jul 87 16:38:22 PDT
161 From: marker%random.s1.gov@mordor.s1.gov
162 >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971. This doesn't
163 win but is still pretty impresive.
165 especially since it wasn't backed up!
167 At least when I was a member, we backed up >nbdd> "by hand"
168 periodically. We actually had to use those backup tapes occasionally.
171 Date: Thu, 23 Jul 87 00:26:56 EDT
172 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
174 To: BUG-ITS@AI.AI.MIT.EDU
175 Message-ID: <231258.870723.CENT@AI.AI.MIT.EDU>
177 it complained about IMPOS. dumped to CRASH;IMPOS LOSS.
179 Received: from nrl.arpa (TCP 3200600010) by AI.AI.MIT.EDU 22 Jul 87 17:33:32 EDT
180 Date: 22 Jul 87 16:08:00 EST
181 From: "VA::BAL" <bal%va.decnet@nrl.arpa>
182 Subject: Musings on history
183 To: "tk" <tk@scrc-stony-brook.arpa>
184 cc: marker%random.s1.gov@mordor.s1.gov,ed@ai.ai.mit.edu,
185 bug-its@ai.ai.mit.edu,sipb@athena.mit.edu
186 Reply-To: "VA::BAL" <bal%va.decnet@nrl.arpa>
188 Reply-To: bal%va.decnet@nrl.arpa
189 Full-Name: Brian A. LaMacchia
190 Address: Code 4771, Naval Research Laboratory
191 Address: 4555 Overlook Ave. SW, Washington, DC 20375-5000
192 Phone: (202) 767-3066
195 When this challenge was originally posted, Census data was mentioned.
196 Well, although it may not be the winner, the Census Bureau puts up a
197 good fight. Here are the high points:
199 1920 Census Data was originally tabulated on Hollerith cards, but those
200 probably no longer exist. 1920 records are on microfilm (which I assume
201 doesn't qualify). However, some of it is available on tape (see below).
203 The 1950 Census used a Univac I (I think) to count the population. Data
204 from this census was originally written to Univac metal tape. Some of
205 these tapes still exist, but it's unclear whether or not the bits on
206 them are still readable.
208 The 1960 Census used FOSDIC (Form Optical Scanner Direct Input to
209 Computer, or something like that) to convert all the forms to microfilm,
210 and then to bits. These tapes still exist.
212 So it looks like 1950 (which wasn't tabulated until 1954 or so) or 1960
213 is the best bet. However, you can get from the Census Bureau tapes
214 containing data summaries for each Census since 1920. These are 1%
215 samples of the population, which don't contain any personal data, just
216 averages. However, some of the numbers are from 1920, so I guess that's
220 bal%va.decnet@nrl.arpa (current)
221 balamac@athena.mit.edu
224 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 22 Jul 87 14:28:37 EDT
225 Received: from CUCKOO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 196728; Wed 22-Jul-87 12:58:55 EDT
226 Date: Wed, 22 Jul 87 14:02 EDT
227 From: Tom Knight <tk@STONY-BROOK.SCRC.Symbolics.COM>
228 Subject: Musings on history
229 To: marker%random.s1.gov@mordor.s1.gov, ED@AI.AI.MIT.EDU
230 cc: BUG-ITS@AI.AI.MIT.EDU, SIPB@mc.lcs.mit.edu
231 In-Reply-To: <8707212338.AA00695@random.s1.gov>
232 Message-ID: <870722140244.3.TK@CUCKOO.SCRC.Symbolics.COM>
234 Date: Tue, 21 Jul 87 16:38:22 PDT
235 From: marker%random.s1.gov@mordor.s1.gov
237 >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971. This doesn't
238 win but is still pretty impresive.
240 especially since it wasn't backed up!
243 Received: from random.s1.gov (TCP 20003600056) by AI.AI.MIT.EDU 21 Jul 87 19:41:51 EDT
244 Received: by random.s1.gov id AA00695; Tue, 21 Jul 87 16:38:22 PDT
245 id AA00695; Tue, 21 Jul 87 16:38:22 PDT
246 Date: Tue, 21 Jul 87 16:38:22 PDT
247 From: marker%random.s1.gov@mordor.s1.gov
248 Message-Id: <8707212338.AA00695@random.s1.gov>
250 Cc: INFO-EXPLORER@ai.ai.mit.edu, BUG-ITS@ai.ai.mit.edu, SIPB@mc.lcs.mit.edu
251 In-Reply-To: Ed Schwalenberg's message of Sat, 18 Jul 87 00:20:05 EDT <228939.870718.ED@AI.AI.MIT.EDU>
252 Subject: Musings on history
254 >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971. This doesn't
255 win but is still pretty impresive.
259 Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 18 Jul 87 18:26:30 EDT
260 Received: from nietzche by Think.COM via CHAOS; Sat, 18 Jul 87 18:27:31 EDT
261 Date: Sat, 18 Jul 87 18:25 EDT
262 From: Barry Margolin <barmar@think.com>
263 Subject: Musings on history
264 To: Ed Schwalenberg <ED@ai.ai.mit.edu>
265 Cc: INFO-EXPLORER@ai.ai.mit.edu, BUG-ITS@ai.ai.mit.edu, SIPB@mc.lcs.mit.edu
266 In-Reply-To: <228939.870718.ED@AI.AI.MIT.EDU>
267 Message-Id: <870718182532.2.BARMAR@NIETZSCHE.THINK.COM>
269 I think Roger Roach still has some tape archives from CTSS.
273 Date: Sat, 18 Jul 87 00:20:05 EDT
274 From: Ed Schwalenberg <ED@AI.AI.MIT.EDU>
275 Subject: Musings on history
276 To: INFO-EXPLORER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
278 Message-ID: <228939.870718.ED@AI.AI.MIT.EDU>
280 I just saw an old file creation date on AI, which led to the following thought:
282 Those bits are "still around", despite the fact that the hardware
283 they live on wasn't invented at the time the bits were written.
285 Which leads to a question:
287 What is the oldest "continuously maintained" set of bits in the
290 Does Grace Hopper still have artillery aiming data on her Macintosh? Did the
291 Census Department copy their punched cards from the 1920 census onto CD/ROM?
292 By continously maintained, I mean that the data has been used regularly since
293 its creation, or at least kept around on some form of reasonably
294 random-access memory in the hope or expectation that it would be used. Thus,
295 the sine lookup table diode ROM in the artillery aiming machine doesn't count
296 if the machine doesn't still work, but AI:SYSEN2;PRUFD > does, even though it
297 hasn't actually been assembled in 15 years or so, and the object code hasn't
298 been run in 2. And of course, by data I'm referring to "digital" information.
299 Rosetta stones, Dead Sea scrolls and Enrico Caruso records don't count, but
300 the first stock ticker tape might.
302 Any interesting candidates? Send me your votes. (The file mentioned above
303 dates from 28 February 1971, and is the oldest file on AI whose creation
306 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jul 87 01:59:15 EDT
307 Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Jul 87 01:55:51 EDT
308 Date: Wed, 15 Jul 87 01:55:10 EDT
309 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
310 Subject: IP routing table
311 To: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
313 In-reply-to: Msg of Tue 14 Jul 87 13:40:44 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
314 Message-ID: <227628.870715.ALAN@AI.AI.MIT.EDU>
316 Date: Tue, 14 Jul 87 13:40:44 EDT
317 From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
318 Date: Tue, 14 Jul 87 02:44:52 EDT
319 From: J. Noel Chiappa <JNC at MC.LCS.MIT.EDU>
320 You know, I wish there were some tools to manipulate this table....,
321 some command that could delete routes, or modify the entyry, could be a
323 This sounds like an easy one night hack for someone. I'd do it if I was
324 certain just what kinds of commands were desirable. Stop by my office some
325 day, and spend 5 minutes helping me design it.
327 I was in the mood for a little hack, so I wrote one. (Source on
328 SYSNET;REDRCT.) Try out:
332 (If anyone can think of a good directory for this to live on other than
333 ALAN, let me know.) With no JCL it will remind you of its usage as
338 :REDRCT <old gateway> <optional new gateway>
340 Gateways can be given as hostnames, or in decimal octet form (as in
341 "10.0.0.77"). If the new gateway is omitted, REDRCT will simply pick a
342 likely-looking gateway from ITS's list of main gateways.
344 REDRCT will ask for confirmation once after it interprets its command, to be
345 sure it properly understood what you asked it to do. Then for each routing
346 table entry it finds that uses the old gateway, it will ask for confirmation
347 before clobbering it with the new gateway.
351 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 87 14:16:39 EDT
352 Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Jul 87 13:55:46 EDT
353 Date: Tue, 14 Jul 87 13:40:44 EDT
354 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
355 Subject: IP routing table
356 To: JNC@MC.LCS.MIT.EDU
357 cc: BUG-ITS@MC.LCS.MIT.EDU
358 In-reply-to: Msg of Tue 14 Jul 87 02:44:52 EDT from J. Noel Chiappa <JNC at MC.LCS.MIT.EDU>
359 Message-ID: <227392.870714.ALAN@AI.AI.MIT.EDU>
361 Date: Tue, 14 Jul 87 02:44:52 EDT
362 From: J. Noel Chiappa <JNC at MC.LCS.MIT.EDU>
363 You know, I wish there were some tools to manipulate this table....,
364 some command that could delete routes, or modify the entyry, could be a
367 This sounds like an easy one night hack for someone. I'd do it if I was
368 certain just what kinds of commands were desirable. Stop by my office some
369 day, and spend 5 minutes helping me design it.
373 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 87 02:45:32 EDT
374 Date: Tue, 14 Jul 87 02:44:52 EDT
375 From: "J. Noel Chiappa" <JNC@MC.LCS.MIT.EDU>
376 Subject: IP routing table
377 To: BUG-ITS@MC.LCS.MIT.EDU
378 cc: JNC@MC.LCS.MIT.EDU
379 Message-ID: <258985.870714.JNC@MC.LCS.MIT.EDU>
381 You know, I wish there were some tools to manipulate this
382 table. For instance, the main gateway to a net went down, and
383 I wanted to switch to the backup; however, ITS doesn't discover
384 dead gateway, and you have to make the switch manually. There's
385 no tool to do this; I had to grovel in IPGWTN: for the right
386 netry (after doing the conversion to octal) and bash it by hand
387 (it picked up the right gateway from a Redirect, so it wasn't
388 totally by hand). Still, some command that could delete routes,
389 or modify the entyry, could be a real win.
394 Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 30002424555) by AI.AI.MIT.EDU 5 Jun 87 19:51:37 EDT
395 Received: from LARRY-BIRD.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89235; Fri 5-Jun-87 19:45:54 EDT
396 Date: Fri, 5 Jun 87 18:03 EDT
397 From: Alan@AI.AI.MIT.EDU
399 To: Bug-Networks@ALDERAAN.SCRC.Symbolics.COM, Bug-ITS@ai.ai.mit.edu
400 cc: Customer-Reports@STONY-BROOK.SCRC.Symbolics.COM
401 Message-ID: <870605194544.7.PALTER@LARRY-BIRD.SCRC.Symbolics.COM>
402 Supersedes: <870605180324.1.ALAN@PIGPEN.AI.MIT.EDU>,
403 <870605194540.6.PALTER@LARRY-BIRD.SCRC.Symbolics.COM>
404 Redirected-Date: Fri, 5 Jun 87 19:45 EDT
405 Redirected-by: Palter@ALDERAAN.SCRC.Symbolics.COM
406 Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")
407 (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
408 Fonts: CPTFONT, CPTFONTCB, CPTFONTI
410 [This message has been redirected:
411 Looks like something either on the LispM or AI didn't properly cleanup from your abort.
412 I'm quite certain it's not Zmail as it has the necessary UNWIND-PROTECTs.
413 Bug-Zmail has been removed;
414 Bug-Networks, Bug-ITS@ai.ai.mit.edu have been added.]
416 In Symbolics 3650 Zmail in Genera 7.1, Hacks 3.0, IP-TCP 52.16,
417 ILA-NFS 3.2, 7-1-Patches 1.15, MAC 11.1, Conversion Tools 12.4,
418 Pascal 25.10, Experimental X-Window-System 17.4,
419 Experimental Illustrate 11.0, TeX 1.0, LaTeX 1.0, SliTeX 1.0, YTeX 1.0,
420 microcode 3650-MIC 396, FEP 206, FEP0:>g206-lisp.flod(14),
421 FEP0:>g206-loaders.flod(14), FEP0:>g206-debug.flod(4),
422 FEP0:>g206-info.flod(14), Machine serial number 30096,
423 Patches for conversion tool. (from SYS:CONVERSION-TOOLS;PATCHES.LISP.29), on Lisp Machine Pigpen:
425 I got this while trying to do the DESCRIBE that Gary requested. I had just
426 previously inadvertently Aborted out of the error he wanted me to
427 investigate, and the next time I did a "G" to reproduce the problem again,
430 \ 61Error: Can't have more than one directory open at a time
431 For AI: ALAN; ALAN _ZMAIL
432 \ 60While in the function (FLAVOR:METHOD :COMMAND FS:HOST-UNIT)
\18 FS:DIRECTORY-CHAOS
\18 (FLAVOR:METHOD :DIRECTORY-STREAM FS:QFILE-ACCESS-PATH)
434 The condition signalled was FS:QNOT-ENOUGH-RESOURCES
436 \ 61(FLAVOR:METHOD :COMMAND FS:HOST-UNIT)
\ 60: (P.C. = 227)
437 Arg 0 (SELF): #<HOST-UNIT 163637553>
438 Arg 1 (SYS:SELF-MAPPING-TABLE): FS:HOST-UNIT
439 Arg 2 (FLAVOR::.GENERIC.): :COMMAND
440 Arg 3 (FS:MARK-P): NIL
441 Arg 4 (FS:STREAM-OR-HANDLE): (:CREATE "I6770")
442 Local 4 (FS:STREAM-OR-HANDLE): "I6770"
443 Arg 5 (FS:SIMPLE-P): NIL
444 Arg 6 (FS:WHOSTATE): "Directory"
445 Rest arg (FS:COMMANDS): ("DIRECTORY" "" "" "" "" #/Return "AI: ALAN; ALAN _ZMAIL" #/Return)
446 Local 8 (FS:HANDLE): "I6770"
447 Local 9 (FS:STREAM): NIL
448 Local 10 (FS:PKT): #<Chaos Packet 6201761>
449 Local 11 (FS:SUCCESS): NIL
450 Local 12 (STRING): "I6770 ERROR NER F Can't have more than one directory open at a time"
451 Local 13 (FS:TRANSACTION-ID): "T6773"
452 Local 14 (FS:CREATE-P): T
453 Local 15: #<CASE-HANDLER 120033346>
454 Local 16: (#<CASE-HANDLER 160200643> #<LEXICAL-CLOSURE (:INTERNAL ZWEI:READ-NEW-MAIL-TOP-LEVEL 1) 230300536> #<LEXICAL-CLOSURE (:INTERNAL ** 0) 230300101>)
455 Local 17: (#<CASE-HANDLER 120033346> #<CASE-HANDLER 160200643> #<LEXICAL-CLOSURE (:INTERNAL ZWEI:READ-NEW-MAIL-TOP-LEVEL 1) 230300536> #<LEXICAL-CLOSURE (:INTERNAL ** 0) 230300101>)
456 Special DBG:*BOUND-HANDLERS*: (#<CASE-HANDLER 120033346> #<CASE-HANDLER 160200643> #<LEXICAL-CLOSURE (:INTERNAL ZWEI:READ-NEW-MAIL-TOP-LEVEL 1) 230300536> #<LEXICAL-CLOSURE (:INTERNAL ** 0) 230300101>)
458 \ 61FS:DIRECTORY-CHAOS
\ 60: (P.C. = 141)
459 Arg 0 (FS:ACCESS-PATH): #<ITS-QFILE-ACCESS-PATH AI using QFILE 163637523>
460 Arg 1: #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
461 Arg 2 (FS:OPTIONS): NIL
462 Special FS:*COMMAND-ERROR-ARGUMENTS*: (:OPERATION :DIRECTORY-LIST)
463 Special FS:*COMMAND-PATHNAME*: #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
465 \ 61(FLAVOR:METHOD :DIRECTORY-STREAM FS:QFILE-ACCESS-PATH)
\ 60: (P.C. = 6)
466 Arg 0 (SELF): #<ITS-QFILE-ACCESS-PATH AI using QFILE 163637523>
467 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor FS:QFILE-ACCESS-PATH 250375074>
468 Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-STREAM
469 Arg 3 (CL:PATHNAME): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
470 Arg 4 (FS:OPTIONS): NIL
472 \ 61(FLAVOR:METHOD :DIRECTORY-LIST FS:DIRECTORY-STREAM-FILE-ACCESS-PATH-MIXIN)
\ 60: (P.C. = 13)
473 Arg 0 (SELF): #<ITS-QFILE-ACCESS-PATH AI using QFILE 163637523>
474 Arg 1 (SYS:SELF-MAPPING-TABLE): FS:DIRECTORY-STREAM-FILE-ACCESS-PATH-MIXIN
475 Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-LIST
476 Arg 3 (CL:PATHNAME): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
477 Arg 4 (FS:OPTIONS): (:SORTED)
479 \ 61(FLAVOR:METHOD :DIRECTORY-LIST FS:ACTIVE-PATHNAME-MIXIN)
\ 60: (P.C. = 12)
480 Arg 0 (SELF): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
481 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor FS:ACTIVE-PATHNAME-MIXIN 220012056>
482 Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-LIST
483 Arg 3 (FS:OPTIONS): (:SORTED)
485 \ 61FS:DIRECTORY-LIST
\ 60: (P.C. = 100)
486 Arg 0 (FS:FILENAME): #<ITS-PATHNAME "AI: ALAN; ALAN _ZMAIL">
487 Rest arg (FS:OPTIONS): (:SORTED)
489 \ 61(FLAVOR:METHOD MAKE-INSTANCE ZWEI:INBOX-BUFFER)
\ 60: (P.C. = 110)
\ 62(from SYS:7-1-PATCHES;PATCH;7-1-PATCHES-1-6)
490 \ 60 Arg 0 (SELF): #<ITS-INBOX-BUFFER "AI: ALAN; ALAN MAIL for AI: ALAN; ALAN BABYL" 424115702>
491 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:INBOX-BUFFER 220004106>
492 Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION MAKE-INSTANCE 6700025>
493 Rest arg: (:PARENT-BUFFER #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435> :PATHNAME #<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)
495 \ 61(FLAVOR:COMBINED MAKE-INSTANCE ZWEI:ITS-INBOX-BUFFER)
\ 60: (P.C. = 11)
496 Arg 0 (SELF): #<ITS-INBOX-BUFFER "AI: ALAN; ALAN MAIL for AI: ALAN; ALAN BABYL" 424115702>
497 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ITS-INBOX-BUFFER 220004052>
498 Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION MAKE-INSTANCE 6700025>
499 Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (:PARENT-BUFFER #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435> :PATHNAME #<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)
501 \ 61MAKE-INSTANCE
\ 60: (P.C. = 572)
\ 62(from SYS:PATCH;SYSTEM-349-177)
502 \ 60 Arg 0 (SYS:FLAVOR-NAME): ZWEI:ITS-INBOX-BUFFER
503 Rest arg (FLAVOR::INIT-OPTIONS): (:PARENT-BUFFER #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435> :PATHNAME #<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)
505 \ 61(:INTERNAL (FLAVOR:METHOD ZWEI:READ-NEW-MAIL ZWEI:FILE-MAIL-BUFFER) 0 ZWEI:NEW-INBOXES)
\ 60: (P.C. = 27)
506 Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): #<DTP-LOCATIVE 230300575>
508 \ 61(FLAVOR:METHOD ZWEI:READ-NEW-MAIL ZWEI:FILE-MAIL-BUFFER)
\ 60: (P.C. = 76)
509 Arg 0 (SELF): #<BABYL-BUFFER "AI: ALAN; ALAN BABYL" 341272435>
510 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:FILE-MAIL-BUFFER 220167476>
511 Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION ZWEI:READ-NEW-MAIL 7011011>
512 Arg 3 (ZWEI:INBOX-PATHNAMES): (#<ITS-PATHNAME "AI: ALAN; ALAN MAIL">)
514 \ 61ZWEI:READ-NEW-MAIL-TOP-LEVEL
\ 60: (P.C. = 67)
516 \ 61ZWEI:COM-GET-NEW-MAIL-FROM-INBOX
\ 60: (P.C. = 7)
518 \ 61(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)
\ 60: (P.C. = 16)
519 Arg 0 (SELF): #<PROCESS Main Zmail Window 15056221>
520 Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS
521 Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL 6704641>
522 Arg 3 (SI:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL ZWEI:COMMAND-EXECUTE 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY) 230300474>
525 \ 61ZWEI:COMMAND-EXECUTE
\ 60: (P.C. = 57)
526 Arg 0 (ZWEI:COMMAND): ZWEI:COM-GET-NEW-MAIL-FROM-INBOX
527 Arg 1 (ZWEI:CHAR): #/g
528 \ 62 --Defaulted args:--
529 \ 60 Arg 2 (ZWEI:PREFIX-CHAR): NIL
530 Arg 3 (ZWEI:HOOK-LIST): NIL
532 \ 61ZWEI:ZMAIL-COMMAND-EXECUTE
\ 60: (P.C. = 6)
533 Arg 0: ZWEI:COM-GET-NEW-MAIL-FROM-INBOX
535 \ 61(FLAVOR:METHOD :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)
\ 60: (P.C. = 7)
536 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
537 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
538 Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
541 \ 61(:INTERNAL (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 0)
\ 60: (P.C. = 10)
542 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
543 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
544 Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
545 Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g)
547 \ 61(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)
\ 60: (P.C. = 43)
548 Arg 0 (SELF): #<PROCESS Main Zmail Window 15056221>
549 Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS
550 Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL 6704641>
551 Arg 3 (SI:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL ** 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY) 230300355>
554 \ 61(FLAVOR:WHOPPER :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-COMMAND-LOOP-MIXIN)
\ 60: (P.C. = 31)
555 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
556 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-COMMAND-LOOP-MIXIN 200000464>
557 Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 0) 150706134>
558 Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
559 Arg 4 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
560 Arg 5 (ZWEI:CHAR): #/g
562 \ 61(:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0)
\ 60: (P.C. = 13)
563 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
564 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
565 Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
566 Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g)
568 \ 61(FLAVOR:WHOPPER :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)
\ 60: (P.C. = 21)
569 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
570 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
571 Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 150706121>
572 Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
573 Arg 4 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
574 Arg 5 (ZWEI:CHAR): #/g
576 \ 61(FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)
\ 60: (P.C. = 12)
577 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
578 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
579 Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR
580 Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g)
582 \ 61(FLAVOR:METHOD :COMMAND-LOOP ZWEI:ZMAIL-FRAME)
\ 60: (P.C. = 130)
583 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
584 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
585 Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP
587 \ 61(:INTERNAL (FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME) 0)
\ 60: (P.C. = 17)
588 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
589 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
590 Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP
591 Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): NIL
593 \ 61(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)
\ 60: (P.C. = 40)
594 Arg 0 (SELF): #<PROCESS Main Zmail Window 15056221>
595 Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS
596 Arg 2 (FLAVOR::.GENERIC.): #<GENERIC-FUNCTION SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL 6704631>
597 Arg 3 (SI:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL ** 1 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 230300103>
600 \ 61(FLAVOR:WHOPPER :COMMAND-LOOP ZWEI:ZMAIL-COMMAND-LOOP-MIXIN)
\ 60: (P.C. = 65)
601 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
602 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-COMMAND-LOOP-MIXIN 200000464>
603 Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME) 0) 150705665>
604 Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
605 Arg 4 (FLAVOR::.GENERIC.): :COMMAND-LOOP
607 \ 61(FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME)
\ 60: (P.C. = 562)
608 Arg 0 (SELF): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
609 Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor ZWEI:ZMAIL-FRAME 200000046>
610 Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP
611 Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): NIL
613 \ 61ZWEI:ZMAIL-PROCESS-TOP-LEVEL
\ 60: (P.C. = 104)
614 Arg 0 (ZWEI:WINDOW): #<ZMAIL-FRAME Main Zmail Window 1523016 exposed>
616 \ 61SI:PROCESS-TOP-LEVEL
\ 60: (P.C. = 45)
619 Special FS:%FILE-COMMAND-OPCODE: 200
620 Special FS:*DONT-HACK-LOGIN*: NIL
623 Date: Tue, 5 May 87 18:20:25 EDT
624 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
625 Subject: Datapoint on TCP buffer lossage
626 To: BUG-ITS@AI.AI.MIT.EDU
627 cc: JTW@AI.AI.MIT.EDU
628 Message-ID: <195885.870505.ALAN@AI.AI.MIT.EDU>
630 The forget-to-free-the-SYN-packet problem than happens on AI and MC so
631 much, really -does- also happen on the KL! After 12 days running, the KL
632 has managed to lose just two packets in this manner. Perhaps the fact that
633 the KL is so much faster explains why it happens so rarely there?
635 Date: Tue, 5 May 87 08:25:18 EDT
636 From: John Wilson <JOHNW@AI.AI.MIT.EDU>
637 To: INFO-ITS@AI.AI.MIT.EDU
638 Message-ID: <195618.870505.JOHNW@AI.AI.MIT.EDU>
640 Please add me to the mailing list.
644 Date: Tue, 5 May 87 05:38:08 EDT
645 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
647 To: BUG-ITS@AI.AI.MIT.EDU
648 Message-ID: <195595.870505.CENT@AI.AI.MIT.EDU>
650 since MD is up again, and doesn't show any immediate signs of disk lossage,
651 i have added it back to the *MSGS and INQUIR update facilities.
653 Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 4 May 87 04:27:24 EDT
654 Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 4 May 87 01:23:28 PDT
655 Date: Mon, 4 May 87 00:05:09 PDT
656 From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
657 Subject: KS10 power fail
658 To: BUG-ITS@AI.AI.MIT.EDU
659 Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
660 Phone: +1 (415) 968-1052
661 Message-ID: <12299611731.6.MRC@PANDA>
663 Hi. I was reading some of the old BUG-ITS mail and saw some messages
664 about power fail recovery. Forget about it on the KS10. Although it
665 was originally going to be included (and I think the prototype machine
666 had it), production KS's don't have any battery backup for the MS10
667 memory. Since MS10 is MOS based, once the power goes it gets nuked.
669 The best thing ITS can do is with a power fail interrupt is to quiet
670 down any disk traffic as quickly as possible (certainly nuke all reads
671 and any writes that aren't essential to prevent filesystem damage) and
674 Since KS10 power supplies are made by a real vendor and not DEC, KS's
675 don't see trivial little glitches. The power has to be off for some
676 time, something like 250ms, for a KS to croak. My KS has survived
677 power glitches that reset the digital clocks and zapped the TV! So,
678 if you get a power fail interrupt there is a good chance that the
679 disks are already in the process of shutdown.
682 Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 20 Apr 87 16:17:00 EDT
683 Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 3302;
684 Mon, 20 Apr 87 11:43:53 EDT
685 Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 6677;
686 Mon, 20 Apr 87 17:43:46 EDT
687 Message-ID: <247761@QZCOM>
688 In-Reply-To: <187812.870420.CENT@AI.AI.MIT.EDU>
689 Date: 20 Apr 87 16:16 +0200
690 From: "Peter Lothberg STUPI" <ROLL@QZCOM.BITNET>
691 Reply-To: "Peter Lothberg STUPI" <ROLL@QZCOM.BITNET>,
692 "ITS bugs mailing list" <ITSBUGS@QZCOM.BITNET>
693 To: "ITS bugs mailing list" <ITSBUGS@QZCOM.BITNET>
694 cc: BUG-ITS@AI.AI.MIT.EDU
695 Subject: alas, poor SAIL-KA
697 Mark Crispin bought the KA10 with the BBN pager. He wanted to
698 have a KA10 front panel, and we took the pager to attach to one
699 of our working KA10:s.
701 Date: Mon, 20 Apr 87 00:24:18 EDT
702 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
703 Subject: alas, poor SAIL-KA
704 To: BUG-ITS@AI.AI.MIT.EDU
705 Message-ID: <187812.870420.CENT@AI.AI.MIT.EDU>
707 i sent LES@SAIL some info about old MAC PDP-10s....
709 Date: 16 Apr 87 1253 PDT
710 From: Les Earnest <LES@SAIL.STANFORD.EDU>
711 Subject: re: PDP10 history project
712 To: CENT@AI.AI.MIT.EDU
714 Incidentally, the Computer Museum already has a PDP-6 -- we gave them
715 ours. At the time I thought that it was the only one left in the world.
716 We recently killed our KA10 and sold it to a collector for $500, including
719 Date: Fri, 17 Apr 87 08:41:07 EDT
720 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
721 Subject: Same old Shit
722 To: BUG-ITS@AI.AI.MIT.EDU
723 Message-ID: <186662.870417.GUMBY@AI.AI.MIT.EDU>
725 (as of today you can't say that on the radio any more)
726 AI crashed with the usual "Freeing packet still in use!"
727 See crash PKTFRE if you care
729 Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 16 Apr 87 04:36:44 EDT
730 Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Thu, 16 Apr 87 01:31:16 PDT
731 Date: Thu, 16 Apr 87 00:29:35 PDT
732 From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
733 Subject: Re: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262)
734 To: ALAN@AI.AI.MIT.EDU
735 cc: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
736 In-Reply-To: <185625.870416.ALAN@AI.AI.MIT.EDU>
737 Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
738 Phone: +1 (415) 968-1052
739 Message-ID: <12294897588.8.MRC@PANDA>
741 I am involved peripherally with this project.
743 There is NO attempt to shortchange or ignore ITS, WAITS, and TENEX.
745 But!! We will need *papers* from people in these communities in order to
746 fairly cover these operating systems.
748 Otherwise, I will write up something really brief. For ITS, in a few short
749 paragraphs I'll talk about DDT as the command decoder, PCLSR'ing, and the
750 environment that led to the creation of EMACS.
752 I think such coverage WOULD shortchange ITS. There are lots of important
753 concepts that can and should be discussed in detail -- PCLSR'ing, ITS virtual
754 memory (not as good as TOPS-20/Tenex, but quite advanced for its time),
755 canonical terminals/SUPDUP/CRTSTY, symbolic system calls, CHEOPS, Knight TV
758 TECO and TECO-based editors should be a paper in itself.
761 Date: Thu, 16 Apr 87 02:04:00 EDT
762 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
763 Subject: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262)
764 To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
765 Message-ID: <185625.870416.ALAN@AI.AI.MIT.EDU>
767 The following message was forwarded to me (it was originally sent to AIList
768 I think) with the suggestion that I should redistribute it to whatever
769 mailing lists of PDP-10 hackers I knew of. I don't know anything more
770 about this than what is revealed here.
772 It does kind of sound like these guys are planning on writing a history of
773 PDP-10's that only mentions TOPS10 and TOPS20 and fails to consider ITS and
774 WAITS and perhaps shortchanges TENEX. But I suspect that this is merely a
775 shortcoming of this announcement.
777 Date: 16 Mar 1987 1311-EST
778 From: "Joe Dempster, DTN: 336.2252 AT&T: 609.665.8711" <DEMPSTER@MARLBORO.DEC.COM>
779 Subject: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262)
781 This message originates from 2 sources:
784 Computer Science Department
788 ARPA: LES@SAIL.STANFORD.EDU
791 DIGITAL EQUIPMENT CORPORATION
792 6 Cherry Hill Executive Campus
794 Cherry Hill, NJ 08002
796 ARPA: DEMPSTER@MARLBORO.DEC.COM (MARKET)
798 The goal of this project is to publish an analysis and history of
799 the evolution, implementation and use of Digital's 36 bit systems.
800 This period began with the PDP-6 in 1964 and continues today with
801 TOPS 10/20 development, which is scheduled to end in 1988.
803 We are working aggressively to finish the project, and have it
804 published, by March/April 1988. This will require that the
805 completed manuscript be ready to go into the publication cycle
808 The project will attempt to answer the following questions:
810 1. In what markets/applications were these systems used?
812 2. Who were the users of these systems and what impact did
813 roughly 2,500 TOPS 10/20 systems have on their organizations?
815 3. Who were the principle system architects of these systems?
816 What features, and if there had been sufficient time to
817 implement them, would have significantly improved the
820 4. What impact did the decision to continue to examine design
821 extensions to the architecture have on the usefulness and
822 acceptability of these systems. This is in contrast to a
823 more common practice today to work from a detailed design
824 specification, sometimes dated, building follow-on systems
825 which provide increased performance through the use of new
826 component technologies and packaging techniques.
828 5. What part of the overall design (TOPS10/20) was technology
829 dependent and what can still be considered "unequaled" in
830 relation to other computer architectures still undergoing
833 6. What type of development environment (both HW and SW)
834 supported and contributed to the evolution of 36 bit
837 7. What influence did TOPS 10/20 have on other vendors system
840 This history will undoubtedly be assembled from many sources and
841 participants. Some information will be anecdotal; there will be
842 interviews with the people involved (users and developers) and technical
843 papers will be solicited. Of course there will also be the packaging
844 and assembly of facts as we see them.
846 The result will hopefully have sufficient depth to serve as:
848 1. An introductory or advanced text on system design and
849 hardware/system software implementation.
851 2. A analysis of the success and difficulties of marketing
852 complex systems into a very crowded market of competing
855 3. A catharsis for those of us who have contributed to the
856 development and use these systems and who will now move
857 onto new computing architectures and opportunities.
859 In addition to interviewing directly 25-50 developers, users and
860 product managers we will continue to work to identify contributors
861 and significant events up to when the final draft is submitted to
862 the publisher. Two "topics" are already under development:
864 1. Rob Gingell from SUN is working on a paper which looks
865 at extensions to TOPS 20 which would have enhanced its
868 2. Frank da Cruz and Columbia are summarizing 10 years of
869 experience and development of TOPS 20 systems. Some
870 effort will also be made to detail the process which
871 lead to their selection of a follow-on architecture to
874 There is a need to develop additional topics which represent the
875 use and application of the technology (TOPS 10/20) in other areas.
876 Specific recommendations are welcome as are proposals to develop
877 them. A short abstract should accompany any such proposal. Every
878 effort will be made to work with individuals or organizations
879 interested in making such a contribution.
881 There will be a standalone (no network connections) DECSYSTEM 2020
882 (YIPYIP) dedicated to supporting the project. This system has a 3
883 line hunt group, with all lines accessible from a single number
886 Both YIPYIP and MARKET will have "public" directories for remote
887 login (<log>DEMPSTER.PROJECT-10262 <Password>LCGLCG). MARKET can
888 be accessed by modem (617.467.7437), however disk quota is limited.
889 MARKET's primary purpose <DEMPSTER.PROJECT-10262> is ARPAnet TELNET
890 access. YIPYIP is a dedicated PROJECT-10262 system. MAIL can also
891 be sent to DEMPSTER on either system.
893 YIPYIP and MARKET will keep a running summary of ideas and comments
894 up on Columbia's BBOARD software. KERMIT also runs on each system
897 SAIL.STANFORD.EDU will support ARPAnet transfers to a "public" area:
900 CONNECT SAIL.STANFORD.EDU<ret>
902 DSK: AFN.EXT [PUB,LES]<ret>
904 SAIL runs WAITS, an operating system similiar to TOPS 10. File
905 names are limited to 6 characters and extensions limited to 3.
908 Implementation details:
910 1. User input is welcomed and desired from all application
911 and geographic areas.
913 2. Input from past and present developers is also desired.
915 3. Throughout the project a secondary goal will be to build
916 a list of users/locations (installation date, duration and
917 disposition) of PDP-6 and KA, KI, KL and KS systems.
918 Serial numbers, if available, are requested.
920 4. We anticipate that this project will generate a large
921 volume of information (which we hope will arrive
922 electronically). Some information, for any number of
923 reasons, may not be in line with the project's stated
924 goals. Therefore, all notes, interview material and
925 submissions will be donated to the Computer Museum in Boston
926 at the the completion of the project to be available for
927 future reference and research.
929 Ideas, contributions, suggestions and criticism are welcome. As these
930 36 bit systems were the products of a multitude of people, so too
931 will be the writing of their history.
933 Date: Tue, 31 Mar 87 18:21:04 EST
934 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
935 Subject: [KLOTZ%OZ.AI.MIT.EDU: sys;system mail]
936 To: ZVONA@AI.AI.MIT.EDU
937 cc: BUG-ITS@AI.AI.MIT.EDU
938 In-reply-to: Msg of Mon 30 Mar 87 14:54:07 EST from David Chapman <ZVONA at AI.AI.MIT.EDU>
939 Message-ID: <176953.870331.ALAN@AI.AI.MIT.EDU>
941 Nothing you could tell me about when DDT and PWORD handle newlines in the
942 presence or absence of SYSTEM MAIL would supprise me. I've looked at that
943 code once before trying to make both programs do the same thing, and I was
944 unable to do that. If anyone else thinks they want to straighten this out,
945 I can suggest about 8 other projects that would be more useful.
947 Date: Mon, 30 Mar 87 14:54:07 EST
948 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
949 Subject: [KLOTZ%OZ.AI.MIT.EDU: sys;system mail]
950 To: BUG-ITS@AI.AI.MIT.EDU
951 Message-ID: <176082.870330.ZVONA@AI.AI.MIT.EDU>
953 Well, this is really random.
955 Date: Mon 30 Mar 87 02:18-EST
956 From: Leigh L. Klotz <KLOTZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
957 To: zvona%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU
960 Actually I wanted to put a * in the file but it turns out that ddt
961 prints out a crlf after the file if there wasn't one...
963 Date: Sun, 29 Mar 87 14:41:13 EST
964 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
965 To: BUG-ITS@AI.AI.MIT.EDU
966 cc: KLOTZ@AI.AI.MIT.EDU
967 Message-ID: <175557.870329.ZVONA@AI.AI.MIT.EDU>
969 I deleted ai:sys;system mail a few days ago, and then someone
970 wrote one that has just a crlf in it. I agree with him (Klotz
971 actually) that this looks better. Seems like a kludge this way;
972 maybe it would be better to patch ddt/pword to print the crlf
975 Date: Tue, 24 Mar 87 09:48:33 EST
976 From: Ed Schwalenberg <ED@AI.AI.MIT.EDU>
978 To: CENT@AI.AI.MIT.EDU
979 cc: BUG-ITS@AI.AI.MIT.EDU, AAD@AI.AI.MIT.EDU,
980 HENRY GAMMERDINGER@AI.AI.MIT.EDU
981 Message-ID: <173000.870324.ED@AI.AI.MIT.EDU>
983 Date: Tue, 24 Mar 87 03:40:44 EST
984 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
986 Date: Sat, 21 Mar 87 05:59:20 EST
987 From: "Anthony A. Datri" <AAD@AI.AI.MIT.EDU>
988 Subject: is this a mailing list?
990 IBM. Also, I saw something somewhere about something called CAMEXEC,
991 which called it an its-like operating system for the pdp-11. Since
994 as to CAMEXEC, yes, it is an ITS-emulating system, written by ED@AI.
996 Before this gets out of hand, CAMEXEC was written by Mike Speciner, who was
997 MS@AI a very long time ago (so long ago that the "@AI" part was seldom used,
998 since the ARPAnet didn't really work very well yet).
1000 Date: Tue, 24 Mar 87 03:40:44 EST
1001 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
1002 Subject: is this a mailing list?
1003 To: AAD@AI.AI.MIT.EDU
1004 cc: BUG-ITS@AI.AI.MIT.EDU
1005 Message-ID: <172875.870324.CENT@AI.AI.MIT.EDU>
1007 Date: Sat, 21 Mar 87 05:59:20 EST
1008 From: "Anthony A. Datri" <AAD@AI.AI.MIT.EDU>
1009 Subject: is this a mailing list?
1010 To: INFO-ITS@AI.AI.MIT.EDU, INFO-ITS-REQUEST@AI.AI.MIT.EDU
1011 Is this an ITS mailing list (duh!)? If so, could I be added to it?
1012 I'm relatively new to ITS (turist account), and I'd love to find out
1013 more. I have great respect for an os that was named to make fun of
1014 IBM. Also, I saw something somewhere about something called CAMEXEC,
1015 which called it an its-like operating system for the pdp-11. Since
1016 I've got an 11/34 with nothing better to run than 2.9.1 BSD or RT11,
1017 I'm interested. Does anyone know anything about this? (hmm. that
1018 sounds like a stupid question, doesn't it?) If I seem confused, it's
1019 because I largely am. I'm learning about ITS by trial and error.
1021 I bet this will seem the strangest to you. IS ITS public domain at
1022 this point? If it is, what would it take to get a distribution? This
1023 is a very silly question, but I seriously intend to have a 2020 of my
1024 own someday. If Mr. Crispin can do it, so can I 8^)
1026 Thanks for any time you spend putting up with and/or answering this
1029 INFO-ITS is, of course, a mailing list, but it is not used for regular
1030 mail. it follows the original fashion of lists named INFO-x, being a very
1031 large list used only for announcements of general interest and importance
1032 to the ITS community -- for instance, major changes in the system. you
1033 should not send mail to it. i will add you to it (if no one else has yet),
1034 but don't expect more than one or two msgs a year to be sent. BUG-ITS or
1035 one of the more specific ITS-related lists is probably the right list for
1036 your various questions.
1038 as to CAMEXEC, yes, it is an ITS-emulating system, written by ED@AI. he
1039 can give you lots of information about it.
1041 ITS is more or less public domain. however, there is no regular
1042 distribution system; each ITS kit is custom-made. for one thing, in the
1043 current scheme of things, each ITS in the world needs a unique two-letter
1044 ID, assigned here so it can be included in some of the deep internals. so
1045 we are not inclined to scatter ITS kits at random. if you get a KS, and
1046 want such a kit, the correct list to correspond with is KS-ITS@AI.
1048 for info on ITS, you should start by looking into the :INFO program and
1049 reading what it has to offer.
1051 Date: Sat, 21 Mar 87 05:59:20 EST
1052 From: "Anthony A. Datri" <AAD@AI.AI.MIT.EDU>
1053 Subject: is this a mailing list?
1054 To: INFO-ITS@AI.AI.MIT.EDU, INFO-ITS-REQUEST@AI.AI.MIT.EDU
1055 Message-ID: <171734.870321.AAD@AI.AI.MIT.EDU>
1058 Is this an ITS mailing list (duh!)? If so, could I be added to it? I'm relatively
1059 new to ITS (turist account), and I'd love to find out more. I have great
1060 respect for an os that was named to make fun of IBM. Also, I saw something
1061 somewhere about something called CAMEXEC, which called it an its-like
1062 operating system for the pdp-11. Since I've got an 11/34 with nothing better
1063 to run than 2.9.1 BSD or RT11, I'm interested. Does anyone know anything
1064 about this? (hmm. that sounds like a stupid question, doesn't it?) If
1065 I seem confused, it's because I largely am. I'm learning about ITS by
1068 I bet this will seem the strangest to you. IS ITS public domain at this
1069 point? If it is, what would it take to get a distribution? This is a very
1070 silly question, but I seriously intend to have a 2020 of my own someday.
1071 If Mr. Crispin can do it, so can I 8^)
1073 Thanks for any time you spend putting up with and/or answering this mail.
1076 aad@ai.ai.mit.edu (but i imagine you guessed that, eh?)
1078 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 20:20:36 EST
1079 Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 20:09:06 EST
1080 Date: Fri 20 Mar 87 20:03:32-EST
1081 From: "John Wroclawski" <JTW@MIT-SPEECH>
1082 Subject: Re: TCP buffers
1083 To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU
1084 cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
1085 In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
1086 Message-ID: <12288011565.22.JTW@MIT-SPEECH>
1089 Yow! Anyway, what I was going to say when the message cleverly decided to
1090 send itself was that the second TCP buffer problem (which is the more
1091 serious - the SYN problem loses packets slowly over time, but when the
1092 IMP problem hits you have had it) is due to my driver code's apparent
1093 inability to always recover correctly from a dropped ACC interrupt.
1095 I haven't had a chance to look at the SYN problem yet, but given what
1096 we learned from Dave's stuff it should be fairly easy to find.
1100 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 19:56:09 EST
1101 Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 19:58:54 EST
1102 Date: Fri 20 Mar 87 19:53:22-EST
1103 From: "John Wroclawski" <JTW@MIT-SPEECH>
1104 Subject: Re: TCP buffers
1105 To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU
1106 cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
1107 In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
1108 Message-ID: <12288009716.22.JTW@MIT-SPEECH>
1110 Moon's PEEK mode actually showed two different problems with the TCP
1111 buffer stuff. Alan mentioned the first one; there is a path which drops
1112 SYN packets on the floor. Dave mentioned the second; the KS IMP driver
1113 occasionally forgets what it is supposed to be doing. The secon
1117 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 16:35:06 EST
1118 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 20 Mar 87 16:23:56 EST
1119 Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98275; Fri 20-Mar-87 15:20:04 EST
1120 Date: Fri, 20 Mar 87 15:19 EST
1121 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1122 Subject: TCP buffers
1123 To: Ken Harrenstien <KLH@AI.AI.MIT.EDU>
1124 cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
1125 BUG-COMSAT@MC.LCS.MIT.EDU
1126 In-Reply-To: <171046.870320.KLH@AI.AI.MIT.EDU>
1127 Message-ID: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
1129 Date: Fri, 20 Mar 87 01:47:48 EST
1130 From: Ken Harrenstien <KLH@AI.AI.MIT.EDU>
1132 Another approach would be to modify PEEK (or something else) to look at the
1133 buffers, including those not on any list. The contents might give
1134 you a clue -- perhaps they are all from a particular host, or use a
1135 particular protocol, or all have the SYN or FIN bit set, etc.
1137 I did that a month or two ago. I don't remember any more what I found out,
1138 except that there were a large number of buffers queued for transmission and
1139 the IMP wasn't taking them. But I don't remember what was in them. We still
1140 have the crash dumps and :p <filename <return> ? should say what the new mode is
1145 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 15:31:34 EST
1146 Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 15:34:47 EST
1147 Date: Fri, 20 Mar 87 15:30:42 EST
1148 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1149 Subject: TCP buffers
1150 To: KLH@AI.AI.MIT.EDU
1151 cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU
1152 In-reply-to: Msg of Fri 20 Mar 87 01:47:48 EST from Ken Harrenstien <KLH at AI.AI.MIT.EDU>
1153 Message-ID: <171296.870320.ALAN@AI.AI.MIT.EDU>
1155 I guess it wasn't announced to Bug-ITS when Moon put a mode into PEEK for
1156 looking at TCP buffers (type "1A"). After using this mode on running
1157 systems and crash dumps it appears that the lost packets are always SYN
1158 packets with their Retransmit flag set. JTW points out that the only
1159 effect of a bug that causes retransmission of SYNs to get dropped would be
1160 that opening connections would time-out more frequently than they should.
1161 This doesn't address the issue of why the problem only seems to happen on
1162 the KS's and never on the KL.
1166 Date: Fri, 20 Mar 87 14:52:06 EST
1167 From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
1168 Subject: today's crash
1169 To: BUG-ITS@AI.AI.MIT.EDU
1170 Message-ID: <171239.870320.JAR@AI.AI.MIT.EDU>
1172 "PK: Freeing packet still in use! PI LEVEL 2 BUGHALT ..."
1174 Dumped to CRASH; PACKET INUSE .
1178 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 01:48:46 EST
1179 Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 01:51:39 EST
1180 Date: Fri, 20 Mar 87 01:47:48 EST
1181 From: Ken Harrenstien <KLH@AI.AI.MIT.EDU>
1182 Subject: TCP buffers
1183 To: ALAN@MC.LCS.MIT.EDU
1184 cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
1185 Message-ID: <171046.870320.KLH@AI.AI.MIT.EDU>
1187 One approach for finding out where the buffers are going might be to
1188 look at the various meters. If you find a meter which has a count the
1189 same as (or close to) the number of buffers that are "lost", then you've
1192 Another approach would be to modify PEEK (or something else) to look at the
1193 buffers, including those not on any list. The contents might give
1194 you a clue -- perhaps they are all from a particular host, or use a
1195 particular protocol, or all have the SYN or FIN bit set, etc.
1197 Considering the remarkable things that have already been discovered
1198 with respect to .HANG and LOCKS, surely yet another long standing
1199 mystery will shortly come to light.
1204 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAR 87 18:12:06 EST
1205 Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 28498; Sun 15-Mar-87 18:09:51 EST
1206 Date: Sun, 15 Mar 87 18:09 EST
1207 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1208 Subject: Recent bugs
1209 To: BUG-ITS@AI.AI.MIT.EDU
1210 cc: ED@AI.AI.MIT.EDU
1211 In-Reply-To: <132118.861218.ALAN@AI.AI.MIT.EDU>,
1212 <141115.870116.ALAN@AI.AI.MIT.EDU>
1213 Message-ID: <870315180951.4.ALAN@PIGPEN.AI.MIT.EDU>
1215 Date: Thu, 18 Dec 86 02:57:19 EST
1216 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1217 TTYSET on a TTY opened as a device (rather than as a console)
1218 clobbers the wrong TTYST* words!
1220 I am unable to reproduce this. I'm certain I was able to clobber
1221 SIXBIT/FOOBAR/ into the TTYST1 word of T0n+1 when I had T0n open as a
1222 device, but I can't get it to happen now... I must have been severely
1225 Date: Fri, 16 Jan 87 17:13:23 EST
1226 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1227 After reading the following bug report [not included], you will realize
1228 that this reveals a bug in the way jobs are sometimes killed when they
1229 have locks locked. If you -first- clobbering their PC's to point to a
1230 .LOGOUT in location 0, and only the .LOGOUT then checks to see if the
1231 PC is in the critical routine table, then the critical routine table is
1234 I fixed the lock unlocking stuff to always use the correct PC, so .GUNing
1235 somebody when he is in a critical region should now do the right thing. I
1236 didn't do anything to prevent lock unlocking instructions from clobbering
1237 the location that contains the .LOGOUT.
1239 Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 MAR 87 13:41:26 EST
1240 Date: Wed 11 Mar 87 13:38:43-EST
1241 From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
1242 Subject: Re: not a bug
1243 To: RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
1244 cc: bug-system@AI.AI.MIT.EDU
1245 In-Reply-To: Message from "Eric Sven Ristad <RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>" of Wed 11 Mar 87 13:21:53-EST
1246 Message-ID: <12285582215.16.JTW@MIT-SPEECH>
1251 You can use the HOST program to find out things like this. (:HOST AI
1252 from an ITS or HOST AI from a TOPS-20 like OZ)
1255 Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 MAR 87 13:18:29 EST
1256 Date: Wed 11 Mar 87 13:14-EST
1257 From: Eric Sven Ristad <RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
1259 To: bug-system@AI.AI.MIT.EDU
1261 What is AI's telnet address (e.g. MX is 10.1.0.6)?
1266 Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 10 Mar 87 00:44:05 EST
1267 Received: by eneevax.umd.edu (5.9/4.7)
1268 id AA13924; Tue, 10 Mar 87 00:41:36 EST
1269 Date: Tue, 10 Mar 87 00:41:36 EST
1270 From: Douglas Humphrey <deh@eneevax.umd.edu>
1271 Message-Id: <8703100541.AA13924@eneevax.umd.edu>
1272 To: BUG-ITS@AI.AI.MIT.EDU, BUG-KS@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU
1273 Subject: Re: MD has internal troubles
1275 RP06 Disk drives are selling for less than the $500 that you state it
1276 will take to fix the existing drive. Has someone contacted used hardware
1277 places in the Boston area (to save shipping charges) to see if they will
1278 either sell or donate an RP06 or two ? I will note that a place in Atlanta
1279 just had several Hundred RP06 drives sent to a scrapper for cents per pound
1280 because there is no market for them any longer.
1285 Date: Mon, 9 Mar 87 00:36:27 EST
1286 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
1287 Subject: MD has internal troubles
1288 To: BUG-KS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
1289 Message-ID: <165407.870309.CENT@AI.AI.MIT.EDU>
1291 (remailed for the record)
1293 Date: Fri, 6 Mar 87 16:00 EST
1294 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1296 Well, head 7 on MD's RP06 is deteriorating fast. JTW just tried cleaning
1297 the heads, but it doesn't look like that helped the problem. I'm
1298 considering taking ITS down so as to not risk damage to the filesystem.
1299 This drive is not on service contract, and neither AI nor presumably LCS
1300 has any real interest in paying to get it fixed. It cost about 500 bucks
1301 to get this fixed when it happened to one of AI's drives.
1303 [ CStacy broke the UNLOCK routine in the Salvager, by the way... ]
1305 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 6 Mar 87 13:27:10 EST
1306 Date: Fri, 6 Mar 1987 13:24 EST
1307 Message-ID: <SRA.12284268841.BABYL@XX.LCS.MIT.EDU>
1308 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
1309 To: BUG-ITS@AI.AI.MIT.EDU
1311 In-reply-to: Msg of 6 Mar 1987 12:47-EST from David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
1313 If we can do the hack with Gumby's clock, I say this is a win. I have
1314 always considered it a big feature that I can go home and sleep and
1315 not be beheaded in the morning by 50 irate XX users who want to know
1316 why their mail hasn't gotten through. It'd be nice if MC and AI could
1317 take care of themselves too.
1319 It seems it ought to be possible to detect which drives are offline at
1320 boot time; Twenex does this, perhaps DSKDMP or ITS could just zap QACT
1321 when it sees that a drive is offline?
1323 While we're adding twenexisms, how about automatic crash dumps and
1324 automatic proceed or reload when there isn't a hacker on duty? :-)
1326 Date: Fri, 6 Mar 87 12:47:39 EST
1327 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
1329 To: ALAN@AI.AI.MIT.EDU
1330 cc: BUG-ITS@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
1331 In-reply-to: Msg of Thu 5 Mar 87 19:37 EST from Alan Bawden <Alan at AI.AI.MIT.EDU>
1332 Message-ID: <164347.870306.GUMBY@AI.AI.MIT.EDU>
1334 Date: Thu, 5 Mar 87 19:37 EST
1335 From: Alan Bawden <Alan at AI.AI.MIT.EDU>
1337 In theory there is a bit that the 8080 sets to indicate that this
1338 is an auto-boot. DSKDMP could test that bit and always load .;@
1339 ITS. Then it could set some kind of a flag to tell DDT to
1340 immediately $G and then start it.
1342 Then we would have to change all of our habits about disk drives
1343 being offline, because we would always need to patch QACT in the
1344 binary as well as the running system.
1346 This is reasonable. We could get rid of that crufty ITS/NITS/XITS
1347 naming randomness too (what's wrong with a link?).
1349 Then we have to figure out what to do about setting the time.
1350 After a power-glitch, a KS-10 will -always- forget the time.
1351 Getting the time from the network simply doesn't work. (This
1352 afternoon when AI and MC asked for the time from the network, only
1353 -one- host responded to their query. I'm kind of reluctant to set
1354 the time on the basis of a single answer.)
1356 I still have that clock that didn't get installed because I/we
1357 couldn't figure out which protocol was the best and what machine to
1358 put it on. Why not put it on MC? I've been watching it for the last
1359 several months and it keeps time better than my watch (which is what
1360 we use otherwise, right?)
1362 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAR 87 19:38:02 EST
1363 Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 26567; Thu 5-Mar-87 19:39:05 EST
1364 Date: Thu, 5 Mar 87 19:37 EST
1365 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1367 To: SRA@XX.LCS.MIT.EDU
1368 cc: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
1369 In-Reply-To: <SRA.12284008604.BABYL@XX.LCS.MIT.EDU>
1370 Message-ID: <870305193743.5.ALAN@PIGPEN.AI.MIT.EDU>
1372 [ Should have combined this message with the previous one, but I
1373 overlooked this message the first time through my mail. ]
1375 Date: Thu, 5 Mar 1987 13:34 EST
1376 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
1378 Or is it, for some reason beyond my ken, considered a feature that ITS
1379 needs a human to reboot?
1381 Well, booting the system without human assistance just makes me a little
1382 nervous, but we could think about it:
1384 In theory there is a bit that the 8080 sets to indicate that this is an
1385 auto-boot. DSKDMP could test that bit and always load .;@ ITS. Then it
1386 could set some kind of a flag to tell DDT to immediately $G and then start
1389 Then we would have to change all of our habits about disk drives being
1390 offline, because we would always need to patch QACT in the binary as well
1391 as the running system.
1393 Then we have to figure out what to do about setting the time. After a
1394 power-glitch, a KS-10 will -always- forget the time. Getting the time from
1395 the network simply doesn't work. (This afternoon when AI and MC asked for
1396 the time from the network, only -one- host responded to their query. I'm
1397 kind of reluctant to set the time on the basis of a single answer.)
1399 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAR 87 19:10:40 EST
1400 Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 26559; Thu 5-Mar-87 19:11:45 EST
1401 Date: Thu, 5 Mar 87 19:10 EST
1402 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1404 To: ZVONA@AI.AI.MIT.EDU
1405 cc: BUG-ITS@AI.AI.MIT.EDU
1406 In-Reply-To: <163684.870305.ZVONA@AI.AI.MIT.EDU>
1407 Message-ID: <870305191017.3.ALAN@PIGPEN.AI.MIT.EDU>
1409 Date: Thu, 5 Mar 87 13:12:14 EST
1410 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1411 AI and MC both lost with BT AUTO. I take it this was a powerglitch.
1412 I dumped to BTAUTO HUH? AI:, presumably this is gubbish if it really
1413 was a glitch. Lost a lot of work, fuck.
1415 Yeah, "BT AUTO" is what the 8080 front-end types when it decides to
1416 automatically boot the machine after the machine is powered on. For ITS
1417 the boot routine just loads up DSKDMP and starts it, which is presumably
1418 how you found the machine. Since the boot routine zeros core before
1419 loading DSKDMP (it does this to wipe out potential parity errors), your
1420 crash dump contains nothing more than the boot routine itself. Thanks for
1421 tending to the problem!
1423 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 5 Mar 87 13:37:10 EST
1424 Date: Thu, 5 Mar 1987 13:34 EST
1425 Message-ID: <SRA.12284008604.BABYL@XX.LCS.MIT.EDU>
1426 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
1427 To: David Chapman <ZVONA@AI.AI.MIT.EDU>
1428 cc: BUG-ITS@AI.AI.MIT.EDU
1430 In-reply-to: Msg of 5 Mar 1987 13:12-EST from David Chapman <ZVONA@AI.AI.MIT.EDU>
1432 Right, that's a powerglitch. The power fail microcode on the KSs
1433 doesn't seem to work any better than the powerfail code on the KL-Bs
1434 (worse, actually, about once every six months XX or OZ will reboot
1435 correctly after a powerfail and surprise the hell out of everybody).
1437 I know that in the case of the KL-Bs running twenex microcode this has
1438 been a problem for years. It gets fixed, then broken, then fixed, ad
1439 nauseum. Unless Alan tells me otherwise I'd assume it's a similar
1442 Or is it, for some reason beyond my ken, considered a feature that ITS
1443 needs a human to reboot?
1445 Date: Thu, 5 Mar 87 13:12:14 EST
1446 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1447 To: BUG-ITS@AI.AI.MIT.EDU
1448 Message-ID: <163684.870305.ZVONA@AI.AI.MIT.EDU>
1450 AI and MC both lost with BT AUTO. I take it this was a powerglitch.
1451 I dumped to BTAUTO HUH? AI:, presumably this is gubbish if it really
1452 was a glitch. Lost a lot of work, fuck.
1454 Date: Tue, 24 Feb 87 15:05:39 EST
1455 From: kltoz@AI.AI.MIT.EDU
1456 Sender: ___016@AI.AI.MIT.EDU
1457 Subject: Rudy.Nedved and the end of TOPS-10
1458 To: POOR-MX@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU,
1459 BUG-ITS@AI.AI.MIT.EDU
1460 Message-ID: <159022.870224.___016@AI.AI.MIT.EDU>
1462 Rudy Nedved is the person who caused the demise of info-cobol.
1464 Date: Tue, 24 Feb 87 01:21:56 EST
1465 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
1466 Subject: small request
1467 To: Rudy.Nedved@H.CS.CMU.EDU
1468 cc: POSTMASTER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
1469 POOR-MX@AI.AI.MIT.EDU
1470 Message-ID: <158772.870224.CENT@AI.AI.MIT.EDU>
1472 Date: Monday, 23 February 1987 19:28:36 EST
1473 From: Rudy.Nedved@h.cs.cmu.edu
1474 To: postmaster@mc.lcs.mit.edu
1475 Subject: small request
1476 Hi, Could some kind person take the time out to remove
1477 MIT-MESSAGES@A.CS.CMU.EDU
1478 from the mit bboard distribution list?
1479 done, mostly by Gumby (i cleaned up a few things he missed).
1480 It has been eons since I made a
1481 change to a mailing list on MIT ITC
1482 you mean ITS, right?
1483 machines. Thanks much,
1485 CMU CS/RI Postmaster
1487 P.S. The last TOPS-10 machine on the ARPANET, A.CS.CMU.EDU is going away
1488 in a week or so. The official shutoff time for users is this Monday,
1490 alas, poor PDP-10s -- yet another casualty. it deserves recording
1491 (wherefore the CCs to the other lists) and public mourning. probably if you
1492 send a mildly clever farewell msg to arpanet-bboards it will get
1495 Date: Mon, 23 Feb 87 23:36:44 EST
1496 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1498 To: CENT@AI.AI.MIT.EDU
1499 cc: BUG-LOCK@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
1500 In-reply-to: Msg of Mon 23 Feb 87 22:49:38 EST from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
1501 Message-ID: <158719.870223.ALAN@AI.AI.MIT.EDU>
1503 Actually, its ITS that is at fault, not LOCK. You killed your LOCK job and
1504 someone else's TELSER happened to get the same job slot before ITS got
1505 around to printing the tattle on the system console. I don't know why the
1506 .SHUTDN uuo doesn't just do a BUG INFO to report what happened rather than
1507 using the buggy kludge that it does...
1509 Date: Mon, 9 Feb 87 11:54:49 EST
1510 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
1511 To: BUG-ITS@AI.AI.MIT.EDU
1512 Message-ID: <151362.870209.ZVONA@AI.AI.MIT.EDU>
1514 AI crashed at 9:44 this morning with a bughalt message
1516 PK: GF node wasnt on list
1518 This came right after
1520 IMP output msg too big 2996 09:44:12
1522 which is probably responsible.
1524 Crash dump in crash;crash pknogf.
1526 Date: Tue, 3 Feb 87 07:31:26 EST
1527 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
1529 To: BUG-ITS@AI.AI.MIT.EDU
1530 Message-ID: <148487.870203.CENT@AI.AI.MIT.EDU>
1532 OZ has a recalcitrant disk drive. lester has tried this and that but
1533 it's still down. so he asked about hooking it up to one of the KSs for
1534 testing. alan and i told him he could use MD. he promised to write
1535 something in MD's log noting what he was doing.
1537 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jan 87 17:00:15 EST
1538 Date: Sat, 31 Jan 87 17:01:01 EST
1539 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
1540 Subject: TCP buffers
1541 To: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU
1542 Message-ID: <165683.870131.ALAN@MC.LCS.MIT.EDU>
1544 I wish we could figure out why ITS consistently dribbles away its TCP
1545 buffers until there are none left.
1547 I also wish that when this happens, COMSAT didn't exhibit this bizare
1550 162430 Unqueueing to host THEORY.LCS.MIT.EDU
1551 162431 ICP->THEORY.LCS.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1552 162432 Unqueueing to host RED.RUTGERS.EDU
1553 162433 ICP->RED.RUTGERS.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1554 162434 Unqueueing to host BRL-SEM.ARPA
1555 162435 ICP->BRL-SEM.ARPA (TCP-SMTP=Bad Greeting="221 BCNU")
1556 162435 Unqueueing to host LBL.ARPA
1557 162436 ICP->LBL.ARPA (TCP-SMTP=Bad Greeting="221 BCNU")
1558 162437 Unqueueing to host SDCSVAX.UCSD.EDU
1559 162438 ICP->SDCSVAX.UCSD.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1560 162439 Unqueueing to host R20.UTEXAS.EDU
1561 162440 ICP->R20.UTEXAS.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1562 162441 Unqueueing to host SAIL.STANFORD.EDU
1563 162442 ICP->SAIL.STANFORD.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1564 162444 Unqueueing to host ATHENA.MIT.EDU
1565 162444 ICP->ATHENA.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1566 162445 Unqueueing to host CHARON.MIT.EDU
1567 162446 ICP->CHARON.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")
1570 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JAN 87 15:01:45 EST
1571 Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19480; Mon 26-Jan-87 15:03:06 EST
1572 Date: Mon, 26 Jan 87 15:03 EST
1573 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1575 To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
1576 In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU>
1577 Message-ID: <870126150304.6.ALAN@KAREN.AI.MIT.EDU>
1579 Despite the fact that in the IAP guide I promised four sessions of the ITS
1580 course, there will -not- be a fourth session this week. See you all again
1583 Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 87 20:04:59 EST
1584 Date: Thu 22 Jan 87 20:05:01-EST
1585 From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
1586 Subject: RP06 undocumented behavior
1587 To: bug-its@AI.AI.MIT.EDU
1588 Message-ID: <12273069628.19.JTW@MIT-SPEECH>
1591 The twenex world recently discovered that an RP0x which gets a header
1592 compare error (HCE) without getting a header CRC error (HCRC) at the
1593 same time may need to have a recalibrate operation done rather than
1594 just a recenter and retry type thing. Otherwise the head ends up
1595 mispositioned till it eventually slams into the stops (which either
1596 fixes it or breaks it but good).
1598 Apparently this is contrary to what the "manual" says.
1600 I don't know what ITS does in this case. Just writing it down for
1604 Date: Thu, 22 Jan 87 04:16:36 EST
1605 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1606 Subject: PEEK shouldn't ever PCLSR anyone
1607 To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
1608 In-reply-to: Msg of Wed 21 Jan 1987 00:25 EST from Rob Austein <SRA at XX.LCS.MIT.EDU>
1609 Message-ID: <143202.870122.ALAN@AI.AI.MIT.EDU>
1611 After fixing PEEK to not needlessly PCLSR device servers a few days ago, I
1612 have been periodically watching COMSAT and DQDEV on MC waiting to catch
1613 them in the act of getting hung up. This afternoon I found them in the
1614 wedged state and was able to figure out what causes the problem. The
1615 problem has nothing to do with the BOJ/JOB code, and is not a bug in DQDEV.
1616 Actually it is an apparently long-standing timing error in the
1617 implementation of .HANG.
1619 Specifically, when you did (as DQDEV does)
1624 the code for .HANG knew that the TRNN instruction could never skip unless
1625 the C(AC) changed, and since nothing can change a job's accumulators
1626 without PCLSRing the job, .HANG could simply hang forever. This is all
1627 well and good, except .HANG neglected to run the instruction once itself to
1628 be certain that AC hadn't been changed by an interrupt routine that ran
1629 -between- the TRNN and the .HANG.
1631 I have assembled an ITS with the fix and I will test it the next time I get
1634 Date: Wed, 21 Jan 87 02:12:12 EST
1635 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
1637 To: BUG-ITS@AI.AI.MIT.EDU
1638 Message-ID: <142633.870121.CENT@AI.AI.MIT.EDU>
1640 again, or halted, or whatever it was. see CRASH;UNIT0 FUKT. Unit 0 had
1641 spun down. i spun it up and reloaded.
1643 Date: Fri, 16 Jan 87 17:13:23 EST
1644 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1645 Subject: [MOON: Mysterious MC won't shut down crash explained]
1646 To: BUG-ITS@AI.AI.MIT.EDU
1647 Message-ID: <141115.870116.ALAN@AI.AI.MIT.EDU>
1649 After reading the following bug report, you will realize that this reveals
1650 a bug in the way jobs are sometimes killed when they have locks locked. If
1651 you -first- clobbering their PC's to point to a .LOGOUT in location 0, and
1652 only the .LOGOUT then checks to see if the PC is in the critical routine
1653 table, then the critical routine table is worthless...
1655 Date: Fri, 16 Jan 87 01:39:40 EST
1656 From: David A. Moon <MOON at AI.AI.MIT.EDU>
1657 To: ALAN at AI.AI.MIT.EDU
1658 cc: BUG-COMSAT at AI.AI.MIT.EDU
1659 Re: Mysterious MC won't shut down crash explained
1661 You aren't going to like this one damn bit.
1663 TMPLOC 44, -LCCBLK,,CCBLK ;aobjn ptr to critical code table for lock hacking
1665 looks like it would put an aobjn pointer into location 44, doesn't it?
1667 It doesn't. It puts -LCCBLK into location 44 and CCBLK into the next
1668 location inline (where it happens to get ignored). This is because
1670 ; TMPLOC <loc>,<parenthesized arg> - puts argument at given LOC
1671 ; without changing location counter outside macro call.
1672 DEFINE TMPLOC VAL,?ARG
1673 [definition deleted]
1675 Why the heck doesn't TMPLOC use a rest-of-line arg?
1677 Now -LCCBLK is -1,,777772, an aobjn pointer to a page that is mapped
1678 into absolute page 120, which contains whatever it happens to contain.
1679 If the PC happens to lie within the bounds of the first word there,
1680 the system executes the second word there as an instruction, with the
1681 extra added feature (see IODCD1 in ITS) that if the LH is zero, SETOM
1682 is substituted. Thus when Comsat executes the .LOGOUT that ALOGO4
1683 puts into its AC 0 when the system job guns it, the unlocking of
1684 Comsat's locked switches, if that absolute page contains zeros,
1685 will do a SETOM 0. If Comsat doesn't pclsr, that -1 is never seen,
1686 but if it does PCLSR out of the .LOGOUT (we still don't know where
1687 it pclsred from), it executes that -1 as an instruction, causing the
1688 lossage we saw. Yow!
1690 It looks like it's been this way for eons. Maybe this also explains
1691 why the Comsat locks don't always seem to work right.
1693 Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 16 Jan 87 04:17:47 EST
1694 Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715239312833556@MIT-MULTICS.ARPA>; 16 Jan 1987 04:08:32 est
1695 Message-ID: <227734@QZCOM>
1696 In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU>
1697 Date: 16 Jan 87 01:07 +0100
1698 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
1699 Reply-To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA,
1700 ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
1701 To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA,
1702 INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
1705 If someone has a home-video-tape-recorder-and-camera-set at MIT
1706 availible, it wold be nice to have a vide tape of the lecture,
1707 for us that can't show up.
1712 Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JAN 87 15:29:36 EST
1713 Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 15 Jan 87 15:21-EST
1714 Date: Thu, 15 Jan 87 15:23 EST
1715 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1717 To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
1718 In-Reply-To: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU>
1719 Message-ID: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU>
1721 Those of you who missed the second session of the ITS course last night
1722 should be aware that next week we will once again meet on -Wednesday-.
1723 It seems I screwed up when I thought we couldn't have the playroom this
1724 Tuesday, and it is actually -next- Tuesday than has the conflict.
1726 Next Wednesday we'll do something about Job Devices. How to write one, or
1727 how they are implemented, or something like that...
1729 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JAN 87 16:52:54 EST
1730 Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 17414; Wed 7-Jan-87 16:50:47 EST
1731 Date: Wed, 7 Jan 87 16:50 EST
1732 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1734 To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
1735 Message-ID: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU>
1737 Those of you who missed the first session of the ITS course last night
1738 should be aware that next week we will meet on -Wednesday- instead of
1739 Tuesday. The following week we will go back to meeting on Tuesdays. (All
1740 meetings are in the 7th floor playroom at 7:30).
1742 Next Wednesday we will hear a bit about the ITS filesystem (not all that
1743 much to tell) and then Ed Schwalenberg will tell us about "CAMEXEC: An
1744 ITS-style Operating System for PDP11's".
1746 Date: Sun, 4 Jan 87 05:03:53 EST
1747 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1749 To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
1750 Message-ID: <136289.870104.ALAN@AI.AI.MIT.EDU>
1752 Yes, there will be an IAP course this January about ITS. The first meeting
1753 will take place in the 7th floor playroom this Tuesday (the 6th) at 7:30 PM.
1755 On Tuesday we will talk about a number of things, including what topics
1756 people might want to hear about in future sessions. As a main event, I am
1757 preparing an explanation of everyone's favorite ITS feature:
1759 PCLSRing: What it is, how it's implemented,
1760 and why Lisp Machines should have it.
1762 I'll try and satisfy both the people who want to hear about low-level,
1763 bits-between-the-toes issues, and those who want to learn universal, cosmic
1764 principles. I'll even relate PCLSRing to quantum mechanics.
1766 Date: Thu, 1 Jan 87 15:43:25 EST
1767 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1769 To: KLOTZ@AI.AI.MIT.EDU
1770 cc: BUG-ITS@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU
1771 In-reply-to: Msg of Wed 31 Dec 86 22:12:10 EST from Leigh L. Klotz <KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
1772 Message-ID: <135733.870101.ALAN@AI.AI.MIT.EDU>
1774 Date: Wed, 31 Dec 86 22:12:10 EST
1775 From: Leigh L. Klotz <KLOTZ at MX>
1776 I just got a non-recoverable disk data error on
1777 klotz;emacs
\11:ej, which is on 14.
1779 When you log in, SYS:SYSTEM MAIL warned you that unit #5 was sinking fast.
1780 Yeah, many files on that pack/drive have suffered.
1782 Perhaps I'll try swapping that pack with the one on unit #4 and see what
1783 happens. If we are really lucky, that will destroy both of them!
1785 Date: Wed, 31 Dec 86 22:28:06 EST
1786 From: Leigh L. Klotz <KLOTZ at MX>
1787 I renamed the bad file to klotz;.bad. :EJ, but the error went away.
1788 It had been repeatable. Is anyone interested in this? Should I be
1789 sending mail to POOR-MC?
1791 POOR-MC is probably the right place, although perhaps there is a POOR-MX
1792 list that I don't know about. (POOR-KL?)
1794 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Dec 86 22:46:03 EST
1795 Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 31 Dec 86 22:26:36 EST
1796 Date: Wed, 31 Dec 86 22:28:06 EST
1797 From: "Leigh L. Klotz" <KLOTZ%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
1798 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
1799 Message-ID: <963808.861231.KLOTZ@MX.LCS.MIT.EDU>
1801 I renamed the bad file to klotz;.bad. :EJ, but the error went away.
1802 It had been repeatable. Is anyone interested in this? Should I be
1803 sending mail to POOR-MC?
1807 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Dec 86 22:19:49 EST
1808 Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 31 Dec 86 22:10:41 EST
1809 Date: Wed, 31 Dec 86 22:12:10 EST
1810 From: "Leigh L. Klotz" <KLOTZ%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
1811 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
1812 Message-ID: <963796.861231.KLOTZ@MX.LCS.MIT.EDU>
1814 I just got a non-recoverable disk data error on
1815 klotz;emacs
\11:ej, which is on 14.
1819 Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 22 Dec 86 20:39:45 EST
1820 Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29850; Mon 22-Dec-86 20:36:56 EST
1821 Date: Mon, 22 Dec 86 20:36 EST
1822 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
1823 Subject: Kludging around the KS's flakey disk
1824 To: Rob Austein <sra@MIT-AI.ARPA>
1825 cc: Bug-ITS@MIT-AI.ARPA, Poor-MC@MIT-AI.ARPA
1826 In-Reply-To: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU>
1827 Supersedes: <861222150854.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
1828 Message-ID: <861222203625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
1830 Date: Mon, 22 Dec 86 02:02 EST
1831 From: Rob Austein <sra@XX.LCS.MIT.EDU>
1833 I just spent five minutes looking at the DISK code. Based on that
1834 wealth of experience, it appears to me that if I were to bring up the KS
1835 with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or
1838 Somebody tell me why I shouldn't do this, before I wear out the $P keys
1839 on the KS's console....
1841 The idea was that if the disk goes unsafe, is reset, and goes unsafe
1842 again within one second, it is probably about to explode and the fire
1843 department should be called. It looks like the code jumps to UNSAFE
1844 for a lot of different reasons, not all of which are the drive going
1845 unsafe. The drive also goes unsafe for a lot of different reasons,
1846 some of more consequence than others.
1848 I agree that if you JFCL out the BUGPAUSE it won't do it any more, so if
1849 you think this won't do irreparable harm to the disk, go ahead.
1852 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Dec 86 02:04:20 EST
1853 Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Dec 86 02:04-EST
1854 Date: Mon, 22 Dec 86 02:02 EST
1855 From: Rob Austein <sra@XX.LCS.MIT.EDU>
1856 Subject: Kludging around the KS's flakey disk
1857 To: Bug-ITS@AI.AI.MIT.EDU, Poor-MC@AI.AI.MIT.EDU
1858 Message-ID: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU>
1860 I just spent five minutes looking at the DISK code. Based on that
1861 wealth of experience, it appears to me that if I were to bring up the KS
1862 with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or
1865 Somebody tell me why I shouldn't do this, before I wear out the $P keys
1866 on the KS's console....
1868 Date: Sun, 21 Dec 86 23:17:45 EST
1869 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1870 Subject: RP06s eat dead bears
1871 To: GUMBY@AI.AI.MIT.EDU
1872 cc: BUG-ITS@AI.AI.MIT.EDU
1873 In-reply-to: Msg of Sun 21 Dec 86 13:52:25 EST from David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
1874 Message-ID: <133398.861221.ALAN@AI.AI.MIT.EDU>
1876 Date: Sun, 21 Dec 86 13:52:25 EST
1877 From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
1878 AI hung in a fashion I'd never seen on the KS's: disk accesses would
1879 hang forever. Pages in core were easily accessible; ITS ran fine
1880 unless you tried to touch the disk. I could create a job and run some
1881 instructions in low memory, but when I tried to do a .CALL OPEN ITS
1884 You must have been lucky. Our RP06's have been causing ITS to hang in this
1885 way ever since day 1.
1887 I went upstairs and the system console said:
1888 DSK: UNIT #1 CAME BACK ONLINE
1889 DSK: UNIT #0 CAME BACK ONLINE
1890 DSK: UNIT #1 CAME BACK ONLINE
1891 and some status registers. For all three, ER1= 40000 which is Drive
1894 Unsafe almost always comes on. The interesting bits were the ones in ER3,
1895 which according to the crash dump were (according to the crufty
1896 documentation) "AC power low", "DC power low" and "Spare" (!).
1898 I dumped it to CRASH DSKOFL, not that I think it will help any.
1900 Why? I manadged to get the ER3 bits out of it.
1902 Notice that the crash file was written out but the dates were not set
1905 DSKDMP never sets write dates, because it doesn't know how to tell the
1906 time. The DMPCPY program (which TARAKA runs when the system boots) sets
1907 the date on any file it suspects is a crash dump. In this case, DMPCPY
1908 wasn't able to set the date either, because you had cold booted the
1909 machine, so ITS didn't know what time it was when DMPCPY ran.
1911 ... By the way, should these be going to BUG-ITS or KS-ITS -- I can
1912 never tell any more.
1914 You sent this to the right place. KS-ITS is almost -never- the right place
1915 to send a Bug Report.
1917 Date: Sun, 21 Dec 86 22:34:01 EST
1918 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
1919 Subject: Gee, that's not his host's name
1920 To: RDZ@AI.AI.MIT.EDU
1921 cc: BUG-ITS@AI.AI.MIT.EDU, BUG-LISP@AI.AI.MIT.EDU
1922 In-reply-to: Msg of Sat 20 Dec 86 13:22 EST from Ramin Zabih <RDZ at AI.AI.MIT.EDU>
1923 Message-ID: <133383.861221.ALAN@AI.AI.MIT.EDU>
1925 Date: Sat, 20 Dec 86 13:22 EST
1926 From: Ramin Zabih <RDZ at AI>
1927 Typing :FINGER on AI just produced this output:
1929 RDZ Ramin Zabih F T23 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)
1931 It seems that someone is confused about the name of the 3600 I'm using...
1933 RDZ's host has a short name of "NULL". He's been expecting the name "NULL"
1934 to break some program ever since he named it that. I presume thats why he
1935 mailed this bug report to Bug-LISP.
1937 Nothing's broken actually. I was just hacking him...
1939 Date: Sun, 21 Dec 86 13:52:25 EST
1940 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
1941 To: BUG-ITS@AI.AI.MIT.EDU
1942 Message-ID: <133197.861221.GUMBY@AI.AI.MIT.EDU>
1944 AI hung in a fashion I'd never seen on the KS's: disk accesses would
1945 hang forever. Pages in core were easily accessible; ITS ran fine unless
1946 you tried to touch the disk. I could create a job and run some instructions
1947 in low memory, but when I tried to do a .CALL OPEN ITS hung.
1949 I went upstairs and the system console said:
1950 DSK: UNIT #1 CAME BACK ONLINE
1951 DSK: UNIT #0 CAME BACK ONLINE
1952 DSK: UNIT #1 CAME BACK ONLINE
1953 and some status registers. For all three, ER1= 40000 which is Drive Unsafe.
1955 I dumped it to CRASH DSKOFL, not that I think it will help any. Notice
1956 that the crash file was written out but the dates were not set on the file?
1958 I cold-booted just in case -- ITS seems to be running fine now. By the way,
1959 should these be going to BUG-ITS or KS-ITS -- I can never tell any more.
1963 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 DEC 86 13:23:05 EST
1964 Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16312; Sat 20-Dec-86 13:22:41 EST
1965 Date: Sat, 20 Dec 86 13:22 EST
1966 From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
1967 Subject: Gee, that's not my host's name
1968 To: bug-lisp@OZ.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU
1969 Message-ID: <861220132243.9.RDZ@NULLSTELLENSATZ.AI.MIT.EDU>
1971 Typing :FINGER on AI just produced this output:
1973 -User- --Full name-- Jobnam Idle TTY -Console location-
1974 ___005 < [not logged in] HACTRN 23.T05 906 x1729 CENT, OAF
1975 KWH Ken Haase HACTRN *:**.T15 Net site PREP (Chaos)
1976 DPH Daniel Huttenlocher HACTRN 46.T16 723 x8843 Alan, DPH
1977 RDZ Ramin Zabih F T23 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)
1979 It seems that someone is confused about the name of the 3600 I'm using...
1983 Date: Fri, 19 Dec 86 02:54:39 EST
1984 From: Alan@AI,Moon@AI
1985 Sender: ALAN@AI.AI.MIT.EDU
1986 Subject: OK, I just saw it happen again.
1987 To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
1988 Message-ID: <132522.861219.ALAN@AI.AI.MIT.EDU>
1990 For most of yesterday (Thursday the 18th) COMSAT on MC was catatonic. Our
1991 guess is that it was stuck in a JOB device wait (waiting for the DQ
1992 device). As soon as Alan looked at the situation COMSAT started running
1993 again, so probably something he did caused COMSAT to get PCLSR'd out of the
1994 system call for the first time all day, and the second time the timing
1995 screw did not occur.
1997 The right thing is for someone to fix the last bug in the JOB/BOJ code.
1999 A quick fix the COMSAT maintainers might consider, is to take an occasional
2000 %PIRLT interrupt to keep its interactions with DQ lubricated.
2002 A better fix would be for Alan to finish up the improved Domain Demon
2003 interface, so that COMSAT can use it instead, and not be subject to this
2004 particular class of ITS bug.
2006 Date: Thu, 18 Dec 86 02:57:19 EST
2007 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2008 To: BUG-ITS@AI.AI.MIT.EDU
2009 Message-ID: <132118.861218.ALAN@AI.AI.MIT.EDU>
2011 TTYSET on a TTY opened as a device (rather than as a console)
2012 clobbers the wrong TTYST* words!
2014 Date: Thu, 4 Dec 86 14:00:04 EST
2015 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2017 To: CENT@AI.AI.MIT.EDU
2018 cc: BUG-ITS@AI.AI.MIT.EDU
2019 In-reply-to: Msg of Thu 4 Dec 86 03:20:35 EST from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
2020 Message-ID: <126472.861204.ALAN@AI.AI.MIT.EDU>
2022 Date: Thu, 4 Dec 86 03:20:35 EST
2023 From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
2024 ... maybe lester didn't fix the disk hard enough.
2026 I don't think it is related. This is a problem we have had ever since we
2027 went to two drives. The symptom is that for no apparent reason a drive
2028 interrupts you and reports that it has just recently come back online.
2029 Both drives do it. We have no idea why they do this. We also have no idea
2030 why the code that we put in to recover from this doesn't work. (Perhaps we
2031 need to reset the drive harder when this happens.) Luckily this doesn't
2032 seem to happen all that often, but it has been the most common reason for
2033 AI crashes since we got the new drive.
2035 It also seems that if one drive is in the middle of a transfer, and you
2036 tell the other drive to do something, the first drive will interrupt you
2037 and complain that you shouldn't bother it while it is busy. We simply
2038 ignore these complaints, which seems to work just fine. (Like it's
2039 happened 470 times since AI came up 10 hours ago...)
2041 Date: Thu, 4 Dec 86 03:20:35 EST
2042 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2044 To: BUG-ITS@AI.AI.MIT.EDU
2045 Message-ID: <126255.861204.CENT@AI.AI.MIT.EDU>
2047 it happened again. dumped to CRASH;FUCKED AGAIN.
2048 maybe lester didn't fix the disk hard enough.
2050 Date: Thu, 4 Dec 86 01:19:00 EST
2051 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2053 To: BUG-ITS@AI.AI.MIT.EDU
2054 Message-ID: <126198.861204.CENT@AI.AI.MIT.EDU>
2056 things were hanging all over, and alan diagnosed that a disk had briefly
2057 gone offline, and AI had not quite recovered correctly. only thing i
2058 could do, really, was to lift switch 0 and reload. crash dump (i think)
2059 to CRASH;FUCKME HARDER, a fine traditional name.
2061 Date: Wed, 19 Nov 86 00:52:23 EST
2062 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2063 Subject: ITS boot tapes
2064 To: USER-ACCOUNTS@AI.AI.MIT.EDU, mkunix!shawn@EDDIE.MIT.EDU
2065 cc: BUG-ITS@AI.AI.MIT.EDU
2066 Message-ID: <[AI.AI.MIT.EDU].120162.861119.CENT>
2068 From: mkunix!shawn@EDDIE.MIT.EDU
2069 Date: Fri, 14 Nov 86 16:56:21 est
2070 To: mit-eddie!user-accounts@mit-ai
2071 Subject: ITS boot tapes
2072 Howdy, I would like to make a copy of the great ITS operating system,
2073 yes, I know, most people would say 'why', but someday I hope to work in
2074 a group that has an old KL/KA and bring up ITS... Being in DEC this is
2075 possable, although probably not likely.
2076 In any case, I wonder if someone would be willing at some point to
2077 show, or instruct me, or guide me in some way in how to make the two
2078 tapes I would need to a) Boot ITS and build a system, and b) Load in
2079 the sources to ITS, and any applications that are deemed ok to
2081 Please forgive me if this is the wrong forum, but I have been trying to
2082 find help from various points and ran out of places to ask... Thanks
2085 Btw, it may be simpler for anyone who wishes to reply to me, to just
2086 send me mail on MC, since I don't know if ITS can deal with uucp path
2087 names, although it may. Thanks again.
2089 of course ITS can deal with uucp paths, at least up to a point. however, as
2090 you suspect, USER-A is the wrong place to ask. even you could have thought
2093 Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 NOV 86 21:37:17 EST
2094 Date: Sun, 16 Nov 86 21:31:19 EST
2095 From: Rob Austein <SRA@MX.LCS.MIT.EDU>
2096 Subject: KL: .; IOELEV *
2097 To: BUG-its@AI.AI.MIT.EDU, poor-mx@AI.AI.MIT.EDU
2098 Message-ID: <[MX.LCS.MIT.EDU].958244.861116.SRA>
2100 I assembled and installed a new version of IOELEV for the KL. The
2101 only change is that it now knows that its name has changed (no longer
2102 tells you you are connected to MC). I'll change the namespace
2103 sometime soon if there aren't any problems with this.
2105 While I was installing this silliness, I reorganized the IOELEV
2106 binaries. KL Console-11 binaries are (as before) in IOELEV nnnBIN
2107 with IOELEV BIN as a link to the latest version (now IOELEV 431BIN).
2108 The AI-Chaos-11 binaries are now in IOELEV nnnAI with a link from
2109 IOELEV AIBIN to the latest version (IOELEV 430AI, the one where I made
2110 subnet six the "primary" address of AI-11 so dover spooling would work
2113 I don't expect any problems. Next person who cold boots the KL please
2114 tell me what happens (if no problems, tell me that).
2118 Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 NOV 86 19:52:40 EST
2119 Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 11282; Thu 13-Nov-86 19:47:32 EST
2120 Date: Thu, 13 Nov 86 19:47 EST
2121 From: Alan Bawden <Alan@AI.AI.MIT.EDU>
2122 Subject: AI wedged itself
2123 To: SRA@AI.AI.MIT.EDU
2124 cc: BUG-ITS@AI.AI.MIT.EDU
2125 In-Reply-To: <[AI.AI.MIT.EDU].117740.861112.SRA>
2126 Message-ID: <861113194734.2.ALAN@PIGPEN.AI.MIT.EDU>
2128 Date: Wed, 12 Nov 86 16:45:19 EST
2129 From: Rob Austein <SRA@AI.AI.MIT.EDU>
2130 Dump in AI:CRASH;WEDGED IDUNNO, not that I expect anybody to have any
2133 Looks like there was a power glitch or something. I'm told there were air
2134 conditioning problems at the time as well.
2136 Date: Wed, 12 Nov 86 16:52:39 EST
2137 From: Rob Austein <SRA@AI.AI.MIT.EDU>
2138 Subject: "ECC" errors?
2139 To: BUG-ITS@AI.AI.MIT.EDU
2140 Message-ID: <[AI.AI.MIT.EDU].117747.861112.SRA>
2142 Happened to be next to AI (had just rebooted it). Heard one of the
2143 RP06s start fibrulating (the sort of mad seek motion that I normally
2144 only see on XX when both XX and its FE are trying to write on drive
2145 zero at the same time). A few seconds later an ECC message pops up on
2146 the console. Don't know if it means anything, but thought I should
2149 Date: Wed, 12 Nov 86 16:45:19 EST
2150 From: Rob Austein <SRA@AI.AI.MIT.EDU>
2151 Subject: AI wedged itself
2152 To: BUG-ITS@AI.AI.MIT.EDU
2153 Message-ID: <[AI.AI.MIT.EDU].117740.861112.SRA>
2155 Dump in AI:CRASH;WEDGED IDUNNO, not that I expect anybody to have any
2159 Received: from DIAMOND.S4CC.Symbolics.COM (TCP 20024231403) by AI.AI.MIT.EDU 4 Nov 86 16:33:11 EST
2160 Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24769; Tue 4-Nov-86 16:27:49 EST
2161 Date: Tue, 4 Nov 86 16:27 EST
2162 From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
2163 Subject: For those of you around MIT this January
2164 To: Alan Bawden <ALAN@AI.AI.MIT.EDU>, KS-ITS@AI.AI.MIT.EDU,
2165 BUG-ITS@AI.AI.MIT.EDU
2166 In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN>
2167 Message-ID: <861104162735.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
2169 Date: Sat, 25 Oct 86 01:38:44 EDT
2170 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2174 It has been suggested that it might be a good idea to teach an ITS course
2175 during IAP this year. We have done this twice before with somewhat mixed
2176 results. A few sessions were quite memorable, and a few were dogs. Before
2177 I decide if I want to front for this again this year, I would like to hear
2178 from some other people. Specifically I want to hear:
2180 Things people want to learn about.
2182 Opinions about what has worked in the past.
2184 Volunteers who would enjoy teaching about something.
2186 Ways of using this to burn excess machine cycles on our many (!) ITS
2187 machines. (Student project ideas?)
2189 I don't think I have any of my notes from IAP'83. Do you (Alan) have
2190 any from IAP'84? I seemed to remember talking about some of the
2192 UUOs/.CALL, their skip-on-success feature, their argument
2193 passing/returning syntax
2195 Devices, MLDEV:, CLU/I/O/A:, etc
2197 File system, links, etc.
2198 Greenblat's History lecture
2199 Moon's hardware description of (the original) AI
2200 With the general proliferation of PCs and high level languages, some of
2201 the more gutsy things, which are the interesting things, may require a
2202 (refresher) course on the assembly language concepts.
2205 Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 27 Oct 86 06:51:15 EST
2206 Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708249629097960@MIT-MULTICS.ARPA>; 27 Oct 1986 06:33:49 est
2207 Date: 26 Oct 86 23:36 +0100
2208 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
2209 Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
2210 To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, "Alan Bawden"
2211 <ALAN@AI.AI.MIT.EDU>
2212 Subject: For those of you around MIT this January
2213 Message-ID: <212189@QZCOM>
2214 In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN>
2216 We are interseted from Stockholm, two persons, major interest:
2217 ITS Internals, what is doing what, and what is speaking to what
2223 Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Oct 86 15:47:35 EDT
2224 Date: Sat, 25 Oct 1986 15:46 EDT
2225 Message-ID: <SRA.12249680831.BABYL@XX.LCS.MIT.EDU>
2226 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2227 To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2228 Cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
2229 Subject: For those of you around MIT this January
2230 In-reply-to: Msg of 25 Oct 1986 01:38-EDT from Alan Bawden <ALAN@AI.AI.MIT.EDU>
2232 Gee, I haven't taught a short course since I left Wesleyan. Sounds
2233 like fun. TECO, theory and practice?
2235 Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Oct 86 02:21:54 EDT
2236 Received: by eneevax.umd.edu (5.9/4.7)
2237 id AA23785; Sat, 25 Oct 86 02:20:02 EDT
2238 Date: Sat, 25 Oct 86 02:20:02 EDT
2239 From: Douglas Humphrey <deh@eneevax.umd.edu>
2240 Message-Id: <8610250620.AA23785@eneevax.umd.edu>
2241 To: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
2242 Subject: Re: For those of you around MIT this January
2244 Let me know when these courses would be and such and count me in.
2245 If I'm going to have one, these might be real helpful and
2246 certainly a Lot of fun.
2250 Date: Sat, 25 Oct 86 01:38:44 EDT
2251 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2252 Subject: For those of you around MIT this January
2253 To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2254 Message-ID: <[AI.AI.MIT.EDU].110499.861025.ALAN>
2258 It has been suggested that it might be a good idea to teach an ITS course
2259 during IAP this year. We have done this twice before with somewhat mixed
2260 results. A few sessions were quite memorable, and a few were dogs. Before
2261 I decide if I want to front for this again this year, I would like to hear
2262 from some other people. Specifically I want to hear:
2264 Things people want to learn about.
2266 Opinions about what has worked in the past.
2268 Volunteers who would enjoy teaching about something.
2270 Ways of using this to burn excess machine cycles on our many (!) ITS
2271 machines. (Student project ideas?)
2273 Date: Thu, 23 Oct 86 01:56:05 EDT
2274 From: Ray Hirschfeld <RAY@AI.AI.MIT.EDU>
2275 Subject: emacs lossage
2276 To: ALAN@AI.AI.MIT.EDU
2277 cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2278 In-reply-to: Msg of Wed 22 Oct 86 19:07:28 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
2279 Message-ID: <[AI.AI.MIT.EDU].109744.861023.RAY>
2281 Date: Wed, 22 Oct 86 19:07:28 EDT
2282 From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
2283 To: RAY at AI.AI.MIT.EDU
2284 cc: BUG-EMACS at AI.AI.MIT.EDU, BUG-ITS at AI.AI.MIT.EDU
2287 Well, a quick peek at your directory reveals:
2290 FREE BLOCKS #0=285 #1=2674
2292 0 TS E 59 +161 ! 10/21/86 11:27:25 (10/22/86)
2295 A look at this file reveals that it is an SBLK file, so it is unlikely that
2296 this is an EMACS that you dumped out for yourself intentionally.
2297 (Especially since it appears to be a vanilla EMACS with no libraries
2298 loaded.) Perhaps you should delete this file.
2300 Thanks, Alan! I never thought to look there. Removing the bogus
2301 emacs fixed the problem. I wonder where the hell it came from.
2305 Date: Wed, 22 Oct 86 19:07:28 EDT
2306 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2307 Subject: emacs lossage
2308 To: RAY@AI.AI.MIT.EDU
2309 cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2310 In-reply-to: Msg of Wed 22 Oct 86 18:44:59 EDT from Ray Hirschfeld <RAY at AI.AI.MIT.EDU>
2311 Message-ID: <[AI.AI.MIT.EDU].109549.861022.ALAN>
2313 Date: Wed, 22 Oct 86 18:44:59 EDT
2314 From: Ray Hirschfeld <RAY at AI>
2315 Emacs on AI has been dying on me repeatedly over the last few days.
2316 It always chokes in the same place, with a message like:
2318 .VAL 0; 6767>>MOVEM 6,1377 6/ 177 1377/ 176
2320 A quick peek reveals that this immediately follows a .call corblk,
2321 which I guess is failing.
2323 Proceeding the job makes it work until the next try.
2325 Well, a quick peek at your directory reveals:
2328 FREE BLOCKS #0=285 #1=2674
2330 0 TS E 59 +161 ! 10/21/86 11:27:25 (10/22/86)
2333 A look at this file reveals that it is an SBLK file, so it is unlikely that
2334 this is an EMACS that you dumped out for yourself intentionally.
2335 (Especially since it appears to be a vanilla EMACS with no libraries
2336 loaded.) Perhaps you should delete this file.
2338 Date: Wed, 22 Oct 86 18:44:59 EDT
2339 From: Ray Hirschfeld <RAY@AI.AI.MIT.EDU>
2340 Subject: emacs lossage
2341 To: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2342 Message-ID: <[AI.AI.MIT.EDU].109535.861022.RAY>
2344 Emacs on AI has been dying on me repeatedly over the last few days.
2345 It always chokes in the same place, with a message like:
2347 .VAL 0; 6767>>MOVEM 6,1377 6/ 177 1377/ 176
2349 A quick peek reveals that this immediately follows a .call corblk,
2350 which I guess is failing.
2352 Proceeding the job makes it work until the next try.
2354 Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 SEP 86 20:50:06 EDT
2355 Date: Fri 26 Sep 86 20:48:06-EDT
2356 From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
2357 Subject: Re: dump code fukt
2358 To: Moon@SCRC-STONY-BROOK.ARPA, CENT@AI.AI.MIT.EDU
2359 cc: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2360 In-Reply-To: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
2361 Message-ID: <12242133556.4.JTW@MIT-SPEECH>
2363 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
2364 Subject: dump code fukt
2367 Date: Fri, 26 Sep 86 03:56:39 EDT
2368 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2372 My first guess is hardware flaking, possibly followed by inadequate resetting
2373 action by the software. The code hasn't changed in forever.
2375 MT:RETRYING WRITE OPERATION
2376 MAG TAPE STATUS TM03 error status decode routine needs to be written ?
2377 MTAPE: FORMATTER ERROR, STATUS= 140600,,40000
2379 This is transport unsafe, usually means it went offline while trying to
2382 MTAPE: FORMATTER ERROR, STATUS=150660,,100320
2383 MAG TAPE STATUS TM03 error status decode routine needs to be written ?
2385 This is a mess. To some extent the bits are inconsistant (seems to imply a
2386 number of data transfer errors during a positioning command), but could
2387 possibly be interpreted as the result of a misformed data transfer command.
2389 I assume multi-reel incremental dumps have worked in the past...
2391 Is this actually true?
2394 Received: from STONY-BROOK.SCRC.Symbolics.COM by AI.AI.MIT.EDU 26 Sep 86 12:55:07 EDT
2395 Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115737; Fri 26-Sep-86 12:47:14 EDT
2396 Date: Fri, 26 Sep 86 12:47 EDT
2397 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
2398 Subject: dump code fukt
2399 To: Pandora B. Berman <CENT@AI.AI.MIT.EDU>, JTW@AI.AI.MIT.EDU
2400 cc: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2401 In-Reply-To: <[AI.AI.MIT.EDU].98958.860926.CENT0>
2402 Message-ID: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
2404 Date: Fri, 26 Sep 86 03:56:39 EDT
2405 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2407 when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the
2408 end of the reel somewhere in the middle of VAFB;, saying
2410 MT:RETRYING WRITE OPERATION
2411 MAG TAPE STATUS TM03 error status decode routine needs to be written ?
2412 MTAPE: FORMATTER ERROR, STATUS= 140600,,40000
2414 and giving me a DUMP prompt. thinking this might just be a case of
2415 terminal dirk, i cleaned the drive and started over again with the
2416 same tape. same result. so i tried dumping onto AI 231. this time, i
2419 MTAPE: FORMATTER ERROR, STATUS=150660,,100320
2420 MAG TAPE STATUS TM03 error status decode routine needs to be written ?
2422 the job at a prompt, and the tape waiting at EOT. so i rewound it and
2423 ICHECK'd it. the ICHECK ended without any strange msgs.
2425 maybe the first time was just due to incorrectly placed-EOT mark (it
2426 did have one, but i'm not sure which side they're -supposed- to be on),
2427 but the second tape worked OK. so something is wrong here..
2429 The MT: and MTAPE: messages (why the inconsistency?) show up in :PEEK ",
2430 so they came from the ITS system rather than from DUMP (it can be hard
2431 to distinguish when you run DUMP on the system-console). The
2432 "error status decode routine needs to be written" message came from DUMP.
2433 I guess its routine for explaining the details of tape errors was never
2434 converted from the version for the KA/KL tape controller.
2436 John, do you know what those octal numbers in the formatter error message
2437 mean? I assume multi-reel incremental dumps have worked in the past, so
2438 has something in the hardware broken? The tape code in ITS hasn't changed
2442 Date: Fri, 26 Sep 86 03:56:39 EDT
2443 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2444 Sender: CENT0@AI.AI.MIT.EDU
2445 Subject: dump code fukt
2446 To: BUG-DUMP@AI.AI.MIT.EDU
2447 cc: BUG-ITS@AI.AI.MIT.EDU
2448 Message-ID: <[AI.AI.MIT.EDU].98958.860926.CENT0>
2450 when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the
2451 end of the reel somewhere in the middle of VAFB;, saying
2453 MT:RETRYING WRITE OPERATION
2454 MAG TAPE STATUS TM03 error status decode routine needs to be written ?
2455 MTAPE: FORMATTER ERROR, STATUS= 140600,,40000
2457 and giving me a DUMP prompt. thinking this might just be a case of
2458 terminal dirk, i cleaned the drive and started over again with the
2459 same tape. same result. so i tried dumping onto AI 231. this time, i
2462 MTAPE: FORMATTER ERROR, STATUS=150660,,100320
2463 MAG TAPE STATUS TM03 error status decode routine needs to be written ?
2465 the job at a prompt, and the tape waiting at EOT. so i rewound it and
2466 ICHECK'd it. the ICHECK ended without any strange msgs.
2468 maybe the first time was just due to incorrectly placed-EOT mark (it
2469 did have one, but i'm not sure which side they're -supposed- to be on),
2470 but the second tape worked OK. so something is wrong here.
2472 Date: Fri, 19 Sep 86 15:03:13 EDT
2473 From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
2474 To: BUG-ITS@AI.AI.MIT.EDU
2475 Message-ID: <[AI.AI.MIT.EDU].96071.860919.RDZ>
2477 AI crashed with "TTY: buffer empty at TYIREM". Dump is in
2480 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 SEP 86 21:40:30 EDT
2481 Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 SEP 86 21:19:54 EDT
2482 Received: from AI.AI.MIT.EDU by ML.AI.MIT.EDU via Chaosnet; 13 SEP 86 21:04:42 EDT
2483 Date: Sat, 13 Sep 86 21:08:22 EDT
2484 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2485 Subject: When you run out of TCP buffers.
2486 To: BUG-ITS@ML.AI.MIT.EDU
2487 cc: BUG-COMSAT@ML.AI.MIT.EDU
2488 Message-ID: <[AI.AI.MIT.EDU].93646.860913.ALAN>
2490 There must be a path through the ITS TCP code that fails to free a buffer
2491 somehow. Twice I have seen MC run itself completely out of buffers. (See
2492 the dump MC:CRASH;CRASH TCPFUL, for an example.) In the most recent
2493 example, ITS had been running for 35 days before this happened, which might
2494 be relevant, although in the previous case it had only been running for 10
2497 Bug-COMSAT: COMSAT behaves weirdly when this happens. Take a look at some
2498 of the recent stats files on MC. Like for -every- host it tries to contact
2499 with TCP it reports: Bad Greeting="+" or somesuch.
2501 Date: Mon, 8 Sep 86 11:04:04 EDT
2502 From: Daniel Huttenlocher <DPH@AI.AI.MIT.EDU>
2503 To: BUG-ITS@AI.AI.MIT.EDU
2504 Message-ID: <[AI.AI.MIT.EDU].92012.860908.DPH>
2506 AI bughalted trying to free a packet still in use. Crash dump
2509 Date: Thu, 4 Sep 86 15:29:10 EDT
2510 From: Daniel Huttenlocher <DPH@AI.AI.MIT.EDU>
2511 To: BUG-ITS@AI.AI.MIT.EDU
2512 Message-ID: <[AI.AI.MIT.EDU].90952.860904.DPH>
2514 AI got a system revived at 14:38, and seemed to leave all jobs
2515 hung or detached (at least ignoring tty input). about 45 mins later
2516 it started printing system full messages on the console. dumped
2519 Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 Aug 86 02:00:37 EDT
2520 Date: Thu, 21 Aug 1986 02:05 EDT
2521 Message-ID: <SRA.12232491989.BABYL@XX.LCS.MIT.EDU>
2522 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2523 To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2524 Cc: BUG-ITS@AI.AI.MIT.EDU
2525 Subject: .RYEAR and time zones again
2526 In-reply-to: Msg of 21 Aug 1986 00:12-EDT from Alan Bawden <ALAN@AI.AI.MIT.EDU>
2528 Making it a new system call is fine. What I'm looking for is a single
2529 UUO that will return the information currently returned by .RLPDTM
2530 plus time zone information. Doesn't have to be in .RLPDTM format, but
2531 should be easy to calculate things like DATIME"TIMGTN from it.
2533 For that matter it would be a win if there was a system call that did
2534 the DATIME"TIMGTN calculation with maximum hair and all the leap year
2535 corrections understood to the human race, once, at system boot time,
2536 then just added system uptime to that to get current time. This
2537 business of having to recalculate the number of leap years since 1 Jan
2538 1900 every time you want an absolute time value is for the birds.
2540 Date: Thu, 21 Aug 86 00:12:52 EDT
2541 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2542 Subject: .RYEAR and time zones again
2543 To: SRA@XX.LCS.MIT.EDU
2544 cc: BUG-ITS@AI.AI.MIT.EDU
2545 In-reply-to: Msg of Wed 20 Aug 1986 16:04 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
2546 Message-ID: <[AI.AI.MIT.EDU].86070.860821.ALAN>
2548 Why don't we just add another system call to return timezone related
2549 information rather than trying to squeeze something into the last few bits
2550 of .RYEAR? First, I dislike recycling fields that are documented to be
2551 zero (rather than being documented as reserved for future expansion.)
2552 Second, given the existence of half-hour and even quarter-hour timezones in
2553 parts of the world, five bits isn't really enough. Third, while we are at
2554 it, it might be a good idea to try and do something about generalizing the
2555 daylight savings time stuff to cover whatever local laws there might be
2558 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 AUG 86 15:59:50 EDT
2559 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Aug 86 15:58:57 EDT
2560 Date: Wed, 20 Aug 1986 16:04 EDT
2561 Message-ID: <SRA.12232382629.BABYL@XX.LCS.MIT.EDU>
2562 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2563 To: bug-its@MC.LCS.MIT.EDU
2564 Subject: .RYEAR and time zones again
2566 Sorry, I should have made that a formal propoal, bits and all.
2568 Time zones range from +1200 to -1200 (international date line, one day
2569 apart from each other).
2571 The two possible formats would be:
2573 the five low bits of an integer in the range -12. -> +12.
2576 one sign bit (3.5) and four bits of integer range 0 -> +12.
2578 Only difference is in how you insert/extract it, of course.
2580 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 AUG 86 15:32:21 EDT
2581 Date: Wed, 20 Aug 86 15:31:28 EDT
2582 From: Rob Austein <SRA@MC.LCS.MIT.EDU>
2583 Subject: .RYEAR and time zones
2584 To: BUG-ITS@MC.LCS.MIT.EDU
2585 cc: SRA@MC.LCS.MIT.EDU
2586 Message-ID: <[MC.LCS.MIT.EDU].73280.860820.SRA>
2588 It would be nice if programs didn't have to have hardwired knowledge
2589 of what time zone they are in (yes, I know, all ITS machines are at MIT
2590 and thus in time zone -0500, but we're trying to be evangelical, here,
2593 Bits 3.5 -> 3.1 of the result from .RYEAR are defined as zero.
2594 24. (maxium time zone plus one) is 30 in octal. Seems a timezone
2595 would fit into those bits very nicely.
2597 Anybody know of anything that would break if this were done?
2598 About the only thing I can think of that this would mess up
2599 would be grossitudes like MOVEI AC,@MEM (ignoring the fact that
2600 HRRZ AC,MEM works just as well). Does anybody really care
2601 what's in those five zeroed bits?
2603 (No, nothing of vital importance depends on this, it would just make
2604 some code I was writing a little cleaner.)
2606 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86 17:50:52 EDT
2607 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86 17:49:53 EDT
2608 Date: Sun, 17 Aug 86 17:48:54 EDT
2609 From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
2610 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
2611 Message-ID: <[MX.LCS.MIT.EDU].941512.860817.DEVON>
2613 Closer examination of my problem controlling my telnet connection to MX
2614 reveals that my logout file on AI is sending telnet IAC DONT TRBIN even
2615 though the MX->AI connection is supdup and not telnet. The problem is
2616 that the only way I can test for a telnet connection is to look at %TPMTA
2617 because the IAC DO TRBIN in the login file turns off the %TPTEL bit!
2619 I guess the way to tell if you are telnetting or supduping is to first
2620 look at %TPCBS, if it's on you're supdup, if it's off look at %TPMTA
2621 and if it's on you're telnet, otherwise it's unknown but for my purposes
2622 this case doesn't matter. Maybe the tctyp program should handle this?
2624 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86 17:26:26 EDT
2625 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86 17:25:27 EDT
2626 Date: Sun, 17 Aug 86 17:24:28 EDT
2627 From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
2628 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
2629 Message-ID: <[MX.LCS.MIT.EDU].941506.860817.DEVON>
2631 note that BUG^K prompts "to:" but should prompt "to: bug-"
2633 When I log in my init file checks for a telnet connection and
2634 does :imgout 377 375 0 which sends a telnet IAC DO TRBIN so
2635 that the TAC will pass @ characters instead of intercepting them,
2636 and pass the 8th bit so the meta key works from my ann arbor.
2638 it looks like nethopping bereaks this somehow, because after
2639 nethopping to either AI or OZ the TAC stops passing meta bits
2640 and starts to intercept @ characters.
2644 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86 17:00:41 EDT
2645 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86 16:59:42 EDT
2646 Date: Sun, 17 Aug 86 16:58:43 EDT
2647 From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
2648 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
2649 Message-ID: <[MX.LCS.MIT.EDU].941505.860817.DEVON>
2651 I tried nethopping from
2653 Date: Tue, 5 Aug 86 05:10:49 EDT
2654 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2655 Subject: TU40 resurrection
2656 To: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
2657 file-r@MC.LCS.MIT.EDU
2658 cc: DEC@AI.AI.MIT.EDU
2659 Message-ID: <[AI.AI.MIT.EDU].79588.860805.CENT>
2661 lester found another instance of the right drive belt somewhere, and even
2662 installed it, so MX's tape drive works again. thanks, lester.
2664 this means we can again read and write 800bpi 7track tapes. however, we
2665 shouldn't WRITE any, because we can't read them anywhere else. i have run
2666 an incremental dump of MX over the net, using Gut's drive (1600 bpi
2667 9track). this causes a few non-fatal errors on the MX end but apparently
2668 works (see system log). any future dumps of MX should be done this way;
2669 i'll do them, or other interested parties (ty?) can ask how. it's only a
2670 little more complicated than dumping to the local drive.
2672 all old incremental tapes for MX are hereby retired and should only be used
2673 to read off of. i have started a new set of incremental tapes at 375 (so
2674 will not overwrite older tape data). all 1600bpi LCS ITS tapes are now on
2675 the rack by the dover. i will try to run a full dump soon. we should get on
2676 with the project of copying the GFR tapes, and then (if possible) proceed
2677 forward into the past, copying full dumps as we go.
2679 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86 15:21:24 EDT
2680 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86 13:32:07 EDT
2681 Date: Tue, 29 Jul 86 11:39:53 EDT
2682 From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
2683 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
2684 Message-ID: <[MX.LCS.MIT.EDU].936970.860729.DEVON>
2686 the door on MX's tape drive seems to be wedged partly open.
2687 As far as I know, it is still true that if you use it, the
2688 controller will deposit bad parity words into system buffers
2689 which will cause MX to bughalt. Anything new on this?
2691 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86 15:21:17 EDT
2692 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86 13:32:02 EDT
2693 Date: Tue, 29 Jul 86 11:10:47 EDT
2694 From: "Devon S. McCullough" <DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
2695 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
2696 Message-ID: <[MX.LCS.MIT.EDU].936964.860729.DEVON>
2698 the network stopped talking across the railroad tracks (as usual on rainy
2699 days) so I left my plasma TV and walked over to the VT52 by MX's console.
2700 Now :TCTYP DESCRIBE says I have Sail,-%TOSAI which looks like a bug to me.
2701 It echoes H when I type backspace at DDT, for instance.
2703 Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 24 Jul 86 19:18:06 EDT
2704 Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49456; Thu 24-Jul-86 18:46:43 EDT
2705 Date: Thu, 24 Jul 86 18:46 EDT
2706 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
2708 To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2709 cc: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU
2710 In-Reply-To: <[AI.AI.MIT.EDU].75103.860724.ALAN>
2711 Message-ID: <860724184615.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
2713 Date: Thu, 24 Jul 86 15:15:31 EDT
2714 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2716 Date: Thu, 24 Jul 1986 13:53 EDT
2717 From: Rob Austein <SRA at XX>
2718 MC seems to have stopped talking to its IMP....
2720 MC's IMP cable was half unplugged at the IMP end.
2722 PEEK on MC claims that there are no free packet buffers, all
2723 sockets in use, but shows nobody using the net.
2725 Who claimed all sockets were in use? I guess some program told you this
2726 because both conditions return the same error code. I don't actually
2727 understand why unplugging the IMP cable should cause all the buffers to get
2728 used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard
2729 wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.)
2731 Maybe all the packet buffers were full of packets waiting to be sent to the IMP.
2734 Maybe a cable fell off ...
2738 I gunned COMSAT on MC so that it wouldn't time out all the messages in
2739 its queue trying to send through a broken interface.
2741 But of course Puff launched another one within an hour.
2743 By the way, I believe the NET command in LOCK still resets the network,
2744 cycling HOST MASTER READY on the IMP cable. That wouldn't have plugged
2745 the cable back in in this case of course, but might still have been
2746 a useful thing to try. I hope this command works on KS's.
2749 Date: Thu, 24 Jul 86 15:15:31 EDT
2750 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2752 To: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2753 cc: BUG-MAIL@AI.AI.MIT.EDU
2754 In-reply-to: Msg of Thu 24 Jul 1986 13:53 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
2755 Message-ID: <[AI.AI.MIT.EDU].75103.860724.ALAN>
2757 Date: Thu, 24 Jul 1986 13:53 EDT
2758 From: Rob Austein <SRA at XX>
2759 MC seems to have stopped talking to its IMP....
2761 MC's IMP cable was half unplugged at the IMP end.
2763 PEEK on MC claims that there are no free packet buffers, all
2764 sockets in use, but shows nobody using the net.
2766 Who claimed all sockets were in use? I guess some program told you this
2767 because both conditions return the same error code. I don't actually
2768 understand why unplugging the IMP cable should cause all the buffers to get
2769 used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard
2770 wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.)
2772 Maybe a cable fell off ...
2776 I gunned COMSAT on MC so that it wouldn't time out all the messages in
2777 its queue trying to send through a broken interface.
2779 But of course Puff launched another one within an hour.
2781 Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 24 Jul 86 14:18:57 EDT
2782 Date: Thu, 24 Jul 1986 13:53 EDT
2783 Message-ID: <SRA.12225280779.BABYL@XX.LCS.MIT.EDU>
2784 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
2785 To: bug-its@AI.AI.MIT.EDU, bug-mail@AI.AI.MIT.EDU
2788 MC seems to have stopped talking to its IMP. XX isn't having any
2789 trouble with this, so it's (probably) not BBN doing something random.
2790 Attempting to connect to 10.3.0.44 causes the IMP to claim that MC is
2791 down. PEEK on MC claims that there are no free packet buffers, all
2792 sockets in use, but shows nobody using the net. Maybe a cable fell
2793 off the LH/DH or maybe something else.
2795 I gunned COMSAT on MC so that it wouldn't time out all the messages in
2796 its queue trying to send through a broken interface.
2798 Date: Tue, 15 Jul 86 17:16:43 EDT
2799 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2800 Subject: TCP Checksum Routine
2801 To: BUG-ITS@AI.AI.MIT.EDU
2802 Message-ID: <[AI.AI.MIT.EDU].70523.860715.ALAN>
2804 This afternoon AI crashed because the TCP segment checksuming routine
2805 referenced location 400000, which is normally non-existant in the system's
2806 page table, thus taking a page fault. The offending instruction was the
2807 ILDB at THCKS5. There is a crash dump in CRASH;CRASH TCPSUM, although I
2808 may have trashed the accumulators and the BUGxxx locations before taking
2809 the dump. I guess we have to suspect that this routine checksums
2810 randomness a lot, and we were only lucky to catch it this time because it
2811 happened to hit the 2% of system memory that would cause it to halt.
2813 Date: Sun, 13 Jul 86 17:58:41 EDT
2814 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2815 Subject: Disappear here.
2816 To: DANIEL@AI.AI.MIT.EDU
2817 cc: BUG-ITS@AI.AI.MIT.EDU
2818 In-reply-to: Msg of Sun 13 Jul 86 10:29:11 EDT from Daniel Weise <DANIEL at AI.AI.MIT.EDU>
2819 Message-ID: <[AI.AI.MIT.EDU].69293.860713.ALAN>
2821 Date: Sun, 13 Jul 86 10:29:11 EDT
2822 From: Daniel Weise <DANIEL at AI.AI.MIT.EDU>
2823 AI went catatonic this morning. I took a dump to
2824 CATA TONIC and reloaded.
2826 Thanks. Its just unit #1 being broken again.
2828 Date: Sun, 13 Jul 86 10:29:11 EDT
2829 From: Daniel Weise <DANIEL@AI.AI.MIT.EDU>
2830 Subject: Disappear here.
2831 To: BUG-ITS@AI.AI.MIT.EDU
2832 Message-ID: <[AI.AI.MIT.EDU].69227.860713.DANIEL>
2834 AI went catatonic this morning. I took a dump to
2835 CATA TONIC and reloaded.
2839 Date: Sat, 12 Jul 86 03:56:36 EDT
2840 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2841 Subject: DRAGON;SYSMSG LOG
2842 To: BUG-ITS@AI.AI.MIT.EDU, MAGIC-DRAGON-KEEPER@AI.AI.MIT.EDU
2843 Message-ID: <[AI.AI.MIT.EDU].68883.860712.ALAN>
2845 The latest PFTHMG DRAGON (installed on the four KS10s, but not the KL)
2846 permanently logs memory errors in addition to disk errors. The file
2847 DRAGON;DISK LOG is now called DRAGON;SYSMSG LOG.
2849 Date: Thu, 26 Jun 86 19:36:12 EDT
2850 From: "Andrew A. Berlin" <AAB@AI.AI.MIT.EDU>
2851 Subject: ROLM phones.
2852 To: BUG-SYS@AI.AI.MIT.EDU
2853 Message-ID: <[AI.AI.MIT.EDU].62057.860626.AAB>
2856 It's getting pretty hard to get a ROLM phone connection to AI
2859 Would it be possible to fix it so that AI hangs up the
2860 ROLM phone after someone logs out (i.e. when it says
2861 "Console Free", it should disconnect the Rolm phone).
2865 Date: Wed, 25 Jun 86 11:49:20 EDT
2866 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
2868 To: TAFT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
2869 In-reply-to: Msg of Wed 25 Jun 86 01:11:18 EDT from Jonathan D. Taft <TAFT at AI.AI.MIT.EDU>
2870 Message-ID: <[AI.AI.MIT.EDU].61315.860625.ALAN>
2872 Date: Wed, 25 Jun 86 01:11:18 EDT
2873 From: Jonathan D. Taft <TAFT at AI>
2874 To: KS-ITS-CONFUSION at AI
2875 AI was unresponsive but running printing repeatedly on its console:
2876 "Warning: No free qsk channels"
2877 "System full no job slots."
2878 I dumped it to CRASH;FULL FORCED and reloaded.
2880 Please send ITS bug reports to Bug-ITS.
2882 This is the same disk hung lossage we have been experiencing ever since we
2883 got the second drive as far as I can tell. I guess the disk-going-offline
2884 code that Moon wrote didn't actually address the correct problem, although
2885 I do notice that in this crash dump NQOFFL has been AOSed once for each
2886 drive (to bad there is no way to tell -when- this happened). Foo. Seems
2887 to have happened again this morning as well. Double foo.
2889 Date: Thu, 19 Jun 86 19:58:28 EDT
2890 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
2892 To: DAVIS@AI.AI.MIT.EDU
2893 cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-SYSTEM@AI.AI.MIT.EDU
2894 Message-ID: <[AI.AI.MIT.EDU].59198.860619.CENT>
2896 Date: Tue 17 Jun 86 15:57-EDT
2897 From: Randall Davis <DAVIS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
2899 To: bug-system%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
2900 I've been getting old copies of info-space mailing list mailings (from
2901 Jan and now Fed) over the past couple of days. It's been happening
2902 roughly since the crash when the mail queue was damaged. When is the
2903 redundancy likely to end? Is there anything to be done to cut off the
2905 this has nothing to do with OZ's mail queue, but is instead the result of
2906 the retransmission of mail lost on (the old) MC this spring, as announced
2907 in a msg to arpanet-bboards a few weeks ago (a copy is available if you
2908 missed it). you are fortunate to be on a mailing list which did not
2909 absolutely depend on MC as a transmission step and which chose to
2910 retransmit immediately, by other paths, those msgs which did not go through
2911 the first time. most recipients of this mail are seeing it for the first
2912 time; we regret that you are encoutering redundancy. the retransmission
2913 process should be completed in about another week.
2915 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JUN 86 22:17:43 EDT
2916 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUN 86 22:17:51 EDT
2917 Date: Sun, 15 Jun 86 22:17:17 EDT
2918 From: Daniel Weise <DANIEL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
2919 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
2920 Message-ID: <[MX.LCS.MIT.EDU].927113.860615.DANIEL>
2922 When I dial in to MX, upon connecting the
2923 11 says "Connected to MC." Maybe someone
2924 should tell it the new name.
2928 Date: Mon, 9 Jun 86 21:37:04 EDT
2929 From: Charles Frankston <CBF@AI.AI.MIT.EDU>
2930 Subject: [Forwarded: JSLove@MIT-MULTICS.ARPA, Re: Re: info about INQUIR]
2931 To: BUG-ITS@AI.AI.MIT.EDU
2932 Message-ID: <[AI.AI.MIT.EDU].53941.860609.CBF>
2934 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 15:08:32 EDT
2935 Received: from CHARON by MC.LCS.MIT.EDU 9 Jun 86 14:42:48 EDT
2936 Received: by CHARON (5.15/4.7)
2937 id AA11138; Mon, 9 Jun 86 14:37:59 EDT
2938 Received: by ATHENA (5.45/4.7)
2939 id AA15558; Mon, 9 Jun 86 14:39:42 EDT
2940 Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 9 Jun 86 14:34:06 EDT
2941 Date: Mon, 9 Jun 86 14:21 EDT
2942 From: "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA>
2943 Subject: Re: info about INQUIR
2944 To: Jan Popiel <Popiel@MIT-MULTICS.ARPA>
2945 Cc: sipb@MC.LCS.MIT.EDU
2946 In-Reply-To: Message of 9 Jun 86 13:32 EDT from "Jan Popiel"
2947 Message-Id: <860609182112.975425@MIT-MULTICS.ARPA>
2949 What I suggested was this: On ITS, there is the database maintained
2950 using :INQUIR. This database is not only consulted by :FINGER on ITS
2951 and the FINGER protocol on the Internet and CHAOS, but was in the past
2952 maintained consistently across 4 ITS sites.
2954 This makes it a good example of a distributed database to be used as a
2955 phone directory. MIT Information Systems now encompasses MIT
2956 telecommunications which produces the MIT directory. Jan's group is now
2957 writing a proposal and proposed specification for a system that might
2958 eventually enable us to put the MIT Staff and Student directories on
2959 line and allow people to update their own entries, and perhaps route
2960 electronic mail as well.
2962 Perhaps the original implementors of :INQUIR are known to people on this
2963 list, or even former SIPB members. Did anyone ever publish a paper on
2964 this work, such as an undergraduate thesis? Is the only documentation
2965 of the goals and operation of this system in the source code? What is
2966 the source code written in and how could it be found?
2968 Please direct replies to Popiel@MIT-Multics.ARPA. I will assist him in
2969 retrieving files and interpreting jargon.
2972 ----------------------------------------------------
2974 What I (CBF) sent was this:
2977 Well, you're right, in the past it was maintained consistently across 4
2978 ITS sites; now its maintained across 5 (AI, ML, MC, MD, & MX). Anyway,
2979 the mechanisms are fairly simple and CPU intensive. Basically it is done
2980 by mailing the updated record to all the other machines. The mailer on
2981 each machine spawn subtasks that merge the record into the database by
2982 copying the entire database to one with a new name, and then using the ITS
2983 rename while open call to atomically instantiate the new one and delete
2986 There is no attempt made to ensure that I don't change my record in rapid
2987 succession on two different ITS's. If I were to do that, it is
2988 conceivable that entries on the different machines could be inconsistent.
2989 In practice it just doesn't happen, or if it did, its trivial for
2990 someone to fix it. Note also that having the mailer daemon do the
2991 database update (even on the same machine) simplifies a host of issues,
2992 since the mailer is a single execution thread on ITS there is no need to
2993 worry about concurrent updates.
2995 If two man months have been put into this effort over the more than 10
2996 years it has been in service, I would be shocked.
2998 Date: Mon, 9 Jun 86 16:00:16 EDT
2999 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3000 Subject: AI's losing network
3001 To: BUG-ITS@AI.AI.MIT.EDU, CPH@OZ.AI.MIT.EDU
3002 In-reply-to: Msg of Mon 9 Jun 1986 14:30 EDT from CPH at OZ.AI.MIT.EDU
3003 Message-ID: <[AI.AI.MIT.EDU].53546.860609.ALAN>
3005 Date: Mon, 9 Jun 1986 14:30 EDT
3007 AI's network seems not to be working. It is possible to connect from
3008 a terminal concentrator, but then it echoes characters very, very
3009 slowly. The rest of the network is happy, all the bridges are running
3011 I tried reaching AI from both MX and OZ, and vice versa, with no luck.
3012 JAR and I tried cold-booting in the hope that it might work. Again, a
3015 I don't know why it didn't occur to anyone that the problem was subnet 6,
3016 and has nothing to do with AI, or ITS.
3018 It turns out that subnet 6 doesn't work very well if you break it into two
3019 pieces by terminating it at the junction box that the KS's are all plugged
3022 Date: Mon, 9 Jun 86 15:48:44 EDT
3023 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3024 Subject: AI's losing network
3025 To: BUG-ITS@AI.AI.MIT.EDU, CPH@OZ.AI.MIT.EDU
3026 In-reply-to: Msg of Mon 9 Jun 1986 14:30 EDT from CPH at OZ.AI.MIT.EDU
3027 Message-ID: <[AI.AI.MIT.EDU].53545.860609.ALAN>
3029 Date: Mon, 9 Jun 1986 14:30 EDT
3031 AI's network seems not to be working. It is possible to connect from
3032 a terminal concentrator, but then it echoes characters very, very
3033 slowly. The rest of the network is happy, all the bridges are running
3035 I tried reaching AI from both MX and OZ, and vice versa, with no luck.
3036 JAR and I tried cold-booting in the hope that it might work. Again, a
3039 I don't know why it didn't occur to anyone that the problem was subnet 6,
3040 and has nothing to do with AI, or ITS.
3042 It turns out that subnet 6 doesn't work very well if you break it into two
3043 pieces by terminating it at the junction box that the KS's are all plugged
3046 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 15:22:22 EDT
3047 Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86 15:18:26 EDT
3048 Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 9 JUN 86 14:30:16 EDT
3049 Date: Mon, 9 Jun 1986 14:30 EDT
3050 Message-ID: <CPH.12213491155.BABYL@MIT-OZ>
3051 From: CPH@OZ.AI.MIT.EDU
3052 To: Bug-ITS@MX.LCS.MIT.EDU
3053 Subject: AI's losing network
3055 AI's network seems not to be working. It is possible to connect from
3056 a terminal concentrator, but then it echoes characters very, very
3057 slowly. The rest of the network is happy, all the bridges are running
3060 I tried reaching AI from both MX and OZ, and vice versa, with no luck.
3062 JAR and I tried cold-booting in the hope that it might work. Again, a
3065 Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JUN 86 00:25:33 EDT
3066 Date: Sat 7 Jun 86 00:24:49-EDT
3067 From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
3068 Subject: Re: If you believe in Dovers, clap your hands!
3069 To: ALAN@AI.AI.MIT.EDU
3070 cc: TY@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-DOVER@AI.AI.MIT.EDU
3071 Message-ID: <12212812879.9.JTW@MIT-SPEECH>
3073 Date: Sat, 7 Jun 86 00:08:53 EDT
3074 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3075 Subject: If you believe in Dovers, clap your hands!
3079 Unfortunately, I remember how the C compiler works. So at some point I'll
3080 probably get around to making a couple of other changes to the spooler
3081 (like, we don't really need it to distribute TeX font files anymore)
3082 and compiling a new one.
3084 In the meantime half of creation has changed their DOVER programs to
3085 spool to MX. So we need to leave the spooler on the KL running for a
3089 Date: Sat, 7 Jun 86 00:08:53 EDT
3090 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3091 Subject: If you believe in Dovers, clap your hands!
3092 To: JTW@AI.AI.MIT.EDU
3093 cc: TY@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
3094 BUG-DOVER@AI.AI.MIT.EDU
3095 In-reply-to: Msg of Fri 6 Jun 86 14:14:31 EDT from Jeffrey J Tyrone Sealy <TY%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
3096 Message-ID: <[AI.AI.MIT.EDU].52858.860607.ALAN>
3098 John, I'm just guessing it was you that moved the dover spooler from the KL
3099 to the KS? It didn't seem to be working. I theorized that this had to do
3100 with the fact that it had the device PK1: built into the source in many
3101 places, so I launched another spooler with a translation from PK1: to DSK:
3102 which now seems to be working. I fixed the sources to use PK0: instead of
3103 PK1:, which should work on any ITS machine for the forseeable future. I
3104 couldn't assemble the sources because (assuming I know how to run the C
3105 compiler, which I don't) there are all kinds of C libraries that have been
3106 migrated to KL GFR tapes.
3108 Anyone who cares about dover spooling is free to finish what John and I
3109 have started I guess. Step one is to get back the C libraries I guess...
3110 I've always been in favor of kicking the dover out the window, so I'm
3111 certainly in no rush to do this myself.
3113 While I was at it, I fixed the various job devices so that DVR^F would know
3114 to contact the KS now, instead of the KL.
3116 I did -not- install a MC:CHANNA;RAKASH DVRSPL on the KS, because any newly
3117 launched demon still needs that translation to function. Until someone
3118 assembles (and links, how unaesthetic for an ITS!) the new sources, the
3119 demon can be launched by hand by running the xfile .DOVR.;.SPOOL XFILE1 on
3120 the KS. (Hackers who might bring the MC KS up, take note!)
3122 Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 13:41:53 EDT
3123 Date: Wed, 4 Jun 86 13:41:52 EDT
3124 From: Chris Hanson <CPH%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
3125 Subject: DOVER Lossage
3126 To: BUG-SYSTEM@MX.LCS.MIT.EDU
3127 Message-ID: <[MX.LCS.MIT.EDU].924307.860604.CPH>
3129 I know this isn't really the right place, but BUG-DOVER looks like a
3132 Will someone please fix :DOVER so that it knows how to spool?
3133 Obviously there IS a spooler, since DVR^F works fine -- except that
3134 :DOVER doesn't seem to know how to talk to it.
3136 Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUN 86 19:53:34 EDT
3137 Date: Mon, 2 Jun 86 19:53:24 EDT
3138 From: "Michael A. Patton" <MAP%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
3139 Subject: Actually the MX front end 11 I believe.
3140 To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
3141 Message-ID: <[MX.LCS.MIT.EDU].923914.860602.MAP>
3143 When you call up the MX (formerly MC) dialup it gives you the message:
3145 just before you get the MX banner from PWORD. This should probably be
3148 Date: Sun, 1 Jun 86 15:00:20 EDT
3149 From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
3150 Subject: Warning to ITS hackers
3151 To: BUG-ITS@AI.AI.MIT.EDU
3152 Message-ID: <[AI.AI.MIT.EDU].49646.860601.MOON>
3154 If you assemble the current source it won't run unless you use the
3155 new microcode I'm debugging. I think it will run if you patch
3156 OVHCLK/ POPJ P, which will keep it from executing the instructions
3157 that aren't implemented. OIPBIT is non-zero now, but it should still
3158 be a no-op with the released microcode. It's unlikely that I will
3159 finish this before next week, since I will be out of town.
3161 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86 20:20:11 EDT
3162 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 31 May 86 20:19:58 EDT
3163 Date: Sat, 31 May 1986 20:18 EDT
3164 Message-ID: <SRA.12211195221.BABYL@XX.LCS.MIT.EDU>
3165 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3166 To: macrakis%endor@HARVARD.HARVARD.EDU (Stavros Macrakis)
3167 Cc: bug-sys@MC.LCS.MIT.EDU, dudek@HARVARD.HARVARD.EDU
3169 In-reply-to: Msg of 31 May 1986 18:53-EDT from macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)
3171 Date: Saturday, 31 May 1986 18:53-EDT
3172 From: macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)
3174 cc: bug-sys@mit-mc.arpa
3177 tn etc. don't seem to know about `mx' == mx.lcs.mit.edu
3179 What machine are you running telnet on? MX.LCS.MIT.EDU is in the
3180 domain database. If your machine can't find it, that's not our fault.
3181 I wouldn't expect just "mx" to work, unless you are on a machine in
3182 the LCS.MIT.EDU domain. Welcome to the future.
3184 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86 18:55:59 EDT
3185 Received: from harvard.HARVARD.EDU by MC.LCS.MIT.EDU 31 May 86 18:55:41 EDT
3186 Received: from endor.HARVARD.EDU (endor) by harvard.HARVARD.EDU; Sat, 31 May 86 18:53:35 EDT
3187 Date: Sat, 31 May 86 18:53:26 EDT
3188 Received: by endor.HARVARD.EDU; Fri, 30 May 86 19:19:33 EDT
3189 From: macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis)
3192 Cc: bug-sys@mit-mc.arpa
3194 tn etc. don't seem to know about `mx' == mx.lcs.mit.edu
3196 Date: Sat, 31 May 86 04:13:37 EDT
3197 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3198 Subject: MC TCP loss
3199 To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU
3200 Message-ID: <[AI.AI.MIT.EDU].49182.860531.CENT>
3202 while on MC and trying to finger out at other hosts, i kept getting an
3203 "all sockets in use" msg. alan poked around and said the system was
3204 out of TCP buffers and COMSAT was acting strangely, so i should raise
3205 switch 0 and take a crash dump. CRASH;TCP LOSS.
3207 Date: Sat, 31 May 86 03:23:01 EDT
3208 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3209 Subject: mailing lists redux
3210 To: GUMBY@AI.AI.MIT.EDU
3211 cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU
3212 Message-ID: <[AI.AI.MIT.EDU].49152.860531.CENT>
3214 Date: Wed, 28 May 86 17:01:04 EDT
3215 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3216 Subject: KS-ITS mailing list
3217 To: GUMBY@AI.AI.MIT.EDU
3218 cc: CENT@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
3219 Date: Wed, 28 May 86 04:47:53 EDT
3220 From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
3221 Can't we fold this into INFO-ITS?
3222 INFO-ITS is an extremely low-volume mailing list. It is for spreading
3223 information that ordinary ITS users and programmers might want to know.
3224 Like when a new device is installed (like LP7:), or a new Midas library
3225 is written, or a new machine is installed, or a new system call is
3226 installed or improved.
3227 KS-ITS is for people who are interested in the project of getting 2020s
3228 installed at MIT running ITS. When I got the KS10 microcode to do
3229 ITS-style paging, I sent mail to KS-ITS. The people on INFO-ITS I
3230 didn't bother until they could log in.
3231 A lot of mail that has gone to KS-ITS in the last few months should
3232 have been sent to BUG-ITS. Like if AI crashes in some novel way,
3233 people send mail to KS-ITS "because AI is a KS", even though BUG-ITS is
3234 the proper recipient.
3235 The people on KS-ITS were interested in keeping in touch with a "good
3236 hack", which is distinct from both BUG-ITS and INFO-ITS.
3238 gumby, the next time you ask 4 people's opinion about making the sort of
3239 major change you suggested, why not wait until more than 1 replies before
3240 deciding what to do? i have just spent 2 hours undoing the confusion you
3241 created by going ahead with this merger after only one response. among
3242 other things, you completely omitted the BUG-ITS archive. fortunately i
3243 discovered a BUG-ITS list member who hasn't logged in for the past few
3244 days, and so was able to recover the lost msgs. i have also unmerged the
3245 INFO-ITS and KS-ITS archives. also, it's considered courteous, when you
3246 insist on rashly forging ahead in this fashion, to inform -all- the list
3247 members involved; you only told those people on KS-ITS who were not on
3249 Date: Wed, 28 May 86 05:49:01 EDT
3250 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
3251 Subject: KS-ITS mailing list
3252 To: KS-ITS-ONLY-PEOPLE@AI.AI.MIT.EDU
3253 The KS's have arrived and ITS runs on them, so we're folding the
3254 KS-ITS list into INFO-ITS.
3255 You're not on INFO-ITS nor BUG-ITS. Unless I hear from you in the
3256 next few days I'll put you on INFO-ITS.
3259 i agree with alan -- the INFO-, BUG-, and KS-ITS have distinct purposes and
3260 should be kept that way. now that the KSs run ITS, a lot of the discussion
3261 previously carried on on KS-ITS should move to BUG-ITS or other more
3262 appropriate lists, but that's another story.
3264 Date: Wed, 28 May 86 17:21:32 EDT
3265 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3266 To: ZVONA@AI.AI.MIT.EDU
3267 cc: BUG-ITS@AI.AI.MIT.EDU
3268 In-reply-to: Msg of Wed 28 May 86 11:39:49 EDT from David Chapman <ZVONA at AI.AI.MIT.EDU>
3269 Message-ID: <[AI.AI.MIT.EDU].47458.860528.ALAN>
3271 Date: Wed, 28 May 86 11:39:49 EDT
3272 From: David Chapman <ZVONA at AI.AI.MIT.EDU>
3273 Is there a reason ML is running ITS when everyone else is running NITS?
3275 Heck, you should have looked yesterday! AI was running NITS, MC was
3276 running XITS, MD was running ITS... The various names have no relation to
3279 When MD came up, it deleted .temp.; because it was empty. Does anything
3280 depend on that dir existing? Just in case, i recreated it.
3282 Many things want there to be a .TEMP. directory. However .TEMP. is on a
3283 (very) short list of directories that are automatically created whenever
3284 anyone tries to use them, so you needn't have gone to the trouble. In
3285 fact, you could have created it simply by typing .TEMP.^F!
3287 Date: Wed, 28 May 86 16:48:18 EDT
3288 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3290 To: GUMBY@AI.AI.MIT.EDU
3291 cc: BUG-ITS@AI.AI.MIT.EDU
3292 In-reply-to: Msg of Wed 28 May 86 04:12:21 EDT from David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
3293 Message-ID: <[AI.AI.MIT.EDU].47443.860528.ALAN>
3295 Date: Wed, 28 May 86 04:12:21 EDT
3296 From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
3297 I brough ML up, and copied over LSR1, everything on SYS: created since
3298 the 15th, and .;@ NITS (which I then booted on ML).
3299 We should have a better way of doing this.
3303 Date: Wed, 28 May 86 04:15:43 EDT
3304 From: David Vinayak Wallace <GUMBY%ML.AI.MIT.EDU at MX.LCS.MIT.EDU>
3305 I lost moving @ NITS to ML:.;. So ML's running ITS
3306 until someone competent wishes to do it.
3308 Since each machine has different devices, addresses, terminals, names, etc.
3309 The various ITS binaries are -totally- incompatible. I shudder to think
3310 what made you realize that you had lost...
3312 Date: Wed, 28 May 86 11:39:49 EDT
3313 From: David Chapman <ZVONA@AI.AI.MIT.EDU>
3314 To: BUG-ITS@AI.AI.MIT.EDU
3315 Message-ID: <[AI.AI.MIT.EDU].47247.860528.ZVONA>
3317 Is there a reason ML is running ITS when everyone else is running NITS?
3318 When MD came up, it deleted .temp.; because it was empty. Does anything
3319 depend on that dir existing? Just in case, i recreated it.
3321 Date: Wed, 28 May 86 08:25:34 EDT
3322 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3323 Subject: Our Man Lester
3324 To: BUG-ITS@AI.AI.MIT.EDU
3325 cc: LAUREL@AI.AI.MIT.EDU
3326 Message-ID: <[AI.AI.MIT.EDU].47197.860528.CENT>
3328 appeared this morning after a significant absence. i asked him about
3329 PM on AI and he said not next Tues. he has a meeting, so maybe Mon.,
3330 or maybe even Fri. i mentioned that AI's disk filters needed changing,
3331 and he agreed. he promised he'd send laurel and alan mail giving the
3334 Date: Wed, 28 May 86 06:52:36 EDT
3335 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3336 Subject: it's probably not a good idea to GFR bug files
3337 To: "GUMBY@"@AI.AI.MIT.EDU
3338 cc: BUG-ITS@AI.AI.MIT.EDU
3339 Message-ID: <[AI.AI.MIT.EDU].47156.860528.CENT>
3341 Date: Wed, 28 May 86 06:37:38 EDT
3342 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
3343 Subject: it's probably not a good idea to GFR bug files:
3344 To: CENT@AI.AI.MIT.EDU
3345 Date: Wed, 28 May 86 06:26:48 EDT
3346 From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
3347 Date: Tue, 27 May 86 07:20:15 EDT
3348 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
3349 FAILED: (FILE [LSPMAI;COMPLR BUGS]) at AI.AI.MIT.EDU; Couldn't
3350 write message to file;
3351 "DSK:LSPMAI;COMPLR BUGS" - LINK TO NON-EXISTENT FILE
3353 look again. the link is to an MX GFR tape. the file was gfr'd, by
3354 JPG or GSB, quite some time ago. are you requesting that it be
3355 retrieved or something?
3356 Yes, I think it should be.
3357 well, you're quite capable of hacking ITS tapes. if you don't, i'll get
3358 around to it sometime.
3359 Also, LSPMAI should be immune to GFR,
3360 talk Alan or whoever into adding it to the magic list...
3362 at least, should be protected from having most-current bug files
3364 i don't think ITS can do this.
3366 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 04:16:36 EDT
3367 Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86 04:16:18 EDT
3368 Date: Wed, 28 May 86 04:15:43 EDT
3369 From: David Vinayak Wallace <GUMBY%ML.AI.MIT.EDU@MX.LCS.MIT.EDU>
3371 To: BUG-its@AI.AI.MIT.EDU
3372 Message-ID: <[ML.AI.MIT.EDU].65.860528.GUMBY>
3374 I lost moving @ NITS to ML:.;. So ML's running ITS
3375 until someone competent wishes to do it.
3377 Date: Wed, 28 May 86 04:12:21 EDT
3378 From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
3379 Sender: GUMBY0@AI.AI.MIT.EDU
3381 To: BUG-ITS@AI.AI.MIT.EDU
3382 Message-ID: <[AI.AI.MIT.EDU].47096.860528.GUMBY0>
3384 I brough ML up, and copied over LSR1, everything on SYS: created since
3385 the 15th, and .;@ NITS (which I then booted on ML).
3386 We should have a better way of doing this.
3388 Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 02:24:13 EDT
3389 Date: Wed, 28 May 86 02:23:09 EDT
3390 From: David Vinayak Wallace <GUMBY@MX.LCS.MIT.EDU>
3391 Subject: ARPA contact name
3392 To: JINX@OZ.AI.MIT.EDU
3393 cc: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
3394 Bug-OZ@OZ.AI.MIT.EDU
3395 In-reply-to: Msg of 27 May 1986 21:46 EDT (Tue) from Bill Rozas <JINX%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
3396 Message-ID: <[MX.LCS.MIT.EDU].922144.860528.GUMBY>
3398 Date: 27 May 1986 21:46 EDT (Tue)
3399 From: Bill Rozas <JINX at OZ>
3401 Shouldn't something which is more likely to stick around be used
3402 instead? Using MX is hardly worth the effort, given its expected
3405 There has been more mail on this subject than it warrants.
3406 1> Fix it to use the KL while it runs; patch it later.
3407 2> Fix the chaos-only hosts (of which there aren't really too many left)
3410 Date: Tue, 27 May 86 22:51:56 EDT
3411 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3412 Subject: ks lossage messages
3413 To: GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
3414 cc: BUG-ITS@AI.AI.MIT.EDU
3415 Message-ID: <[AI.AI.MIT.EDU].46889.860527.CENT>
3417 Date: Mon, 26 May 86 02:02 EDT
3418 From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
3419 Subject: ks lossage messages
3420 To: David Chapman <ZVONA@MX.LCS.MIT.EDU>
3421 cc: poor-ai@AI.AI.MIT.EDU
3422 Date: Mon, 19 May 86 11:12:12 EDT
3423 From: David Chapman <ZVONA@MX.LCS.MIT.EDU>
3424 Do we need a poor-ks?
3425 At 6 this morning, MX started complaining often about being out of
3426 jobslots on the console.
3427 Messages like this used to go to BUG-ITS. I figure they should anyway
3428 (and the poor-<xx> lists should be flushed, except for the special case
3430 i have flushed the POOR-AI list and folded the four msgs it had accumulated
3431 in its archive file into the BUG-ITS archive.
3433 Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 21:46:43 EDT
3434 Date: 27 May 1986 21:46 EDT (Tue)
3435 Message-ID: <JINX.12210162593.BABYL@MIT-OZ>
3436 From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
3437 To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3438 Cc: BUG-ITS@AI.AI.MIT.EDU, Bug-OZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
3439 Cole%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, FTD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
3440 GLR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
3441 Subject: [COLE: Telnet-ing through MC to live hosts...]
3442 In-reply-to: Msg of 27 May 1986 16:11-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
3445 Why don't you just fix TELNET on OZ to use MX as a gateway?
3447 Shouldn't something which is more likely to stick around be used
3448 instead? Using MX is hardly worth the effort, given its expected
3451 Date: Tue, 27 May 86 16:11:20 EDT
3452 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3453 Subject: [COLE: Telnet-ing through MC to live hosts...]
3454 To: GLR@OZ.AI.MIT.EDU, Cole@OZ.AI.MIT.EDU
3455 cc: BUG-ITS@AI.AI.MIT.EDU, FTD@OZ.AI.MIT.EDU,
3456 Bug-OZ@OZ.AI.MIT.EDU
3457 In-reply-to: Msg of Tue 27 May 1986 15:13 EDT from Jerry Roylance <GLR%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
3458 Message-ID: <[AI.AI.MIT.EDU].46638.860527.ALAN>
3460 Date: Tue, 27 May 1986 15:13 EDT
3461 From: Jerry Roylance <GLR at OZ>
3463 Date: Sunday, 25 May 1986 22:48-EDT
3465 To: David D. Story <FTD at OZ>
3467 MC is rejecting OZ's request to telnet to arpanet hosts.
3468 But I was able to telnet from oz by typing:
3471 TELNET> host-name telnet tcp mx
3473 I don't know what host computer OZ is now supposed to be using for its
3476 Somebody seems to have decided that the MC KS will not supply TCP gateway
3477 service. I personally think this is silly. I would not object if someone
3478 else wants to take the heat for putting it back.
3480 Why don't you just fix TELNET on OZ to use MX as a gateway?
3482 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 15:15:57 EDT
3483 Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86 15:15:25 EDT
3484 Date: Tue, 27 May 1986 15:13 EDT
3485 Message-ID: <GLR.12210090990.BABYL@MIT-OZ>
3486 From: Jerry Roylance <GLR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
3487 To: Bug-ITS@MC.LCS.MIT.EDU
3488 Subject: [COLE: Telnet-ing through MC to live hosts...]
3490 Date: Sunday, 25 May 1986 22:48-EDT
3491 From: COLE at OZ.AI.MIT.EDU
3492 To: David D. Story <FTD%MIT-OZ at MC.LCS.MIT.EDU>
3493 cc: bug-oz at OZ.AI.MIT.EDU
3494 Re: Telnet-ing through MC to live hosts...
3496 MC is rejecting OZ's request to telnet to arpanet hosts.
3497 But I was able to telnet from oz by typing:
3500 TELNET> host-name telnet tcp mx
3502 I don't know what host computer OZ is now supposed to be using for its telnet
3505 Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 14:31:38 EDT
3506 Date: Tue, 27 May 86 14:30:45 EDT
3507 From: Chris Hanson <CPH@MX.LCS.MIT.EDU>
3508 Subject: Just nitpicking...
3509 To: BUG-ITS@MX.LCS.MIT.EDU
3510 Message-ID: <[MX.LCS.MIT.EDU].921807.860527.CPH>
3512 MX still says "Connected to MC." when you dial it up.
3513 I guess there is no single variable controlling the machine name.
3515 Received: from MOSCOW-CENTRE.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 MAY 86 02:02:40 EDT
3516 Date: Mon, 26 May 86 02:02 EDT
3517 From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
3518 Subject: ks lossage messages
3519 To: David Chapman <ZVONA@MX.LCS.MIT.EDU>
3520 cc: poor-ai@AI.AI.MIT.EDU
3521 In-Reply-To: <[MX.LCS.MIT.EDU].587.860519.ZVONA>
3522 Message-ID: <860526020227.5.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU>
3524 Date: Mon, 19 May 86 11:12:12 EDT
3525 From: David Chapman <ZVONA@MX.LCS.MIT.EDU>
3527 Do we need a poor-ks?
3529 At 6 this morning, MX started complaining often about being out of
3530 jobslots on the console.
3532 Messages like this used to go to BUG-ITS. I figure they should anyway
3533 (and the poor-<xx> lists should be flushed, except for the special case
3536 Date: Thu, 22 May 86 01:20:17 EDT
3537 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3538 Subject: Someday when things calm down we might have time to look into things like this again
3539 To: BUG-ITS@AI.AI.MIT.EDU
3540 Message-ID: <[AI.AI.MIT.EDU].44418.860522.ALAN>
3542 Outputting to a BOJ: channel after the device user no longer has his
3543 JOB: channel open seems to simply hang. (In the case I'm seeing it
3544 is SIOT to a channel open in .UAO mode.) I would have expected
3545 this to signal an error, perhaps %ENAPP?
3547 Date: Wed, 21 May 86 23:55:16 EDT
3548 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3549 Subject: logbook location
3550 To: SRA@AI.AI.MIT.EDU
3551 cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
3552 Message-ID: <[AI.AI.MIT.EDU].44369.860521.CENT>
3554 Date: Wed, 21 May 1986 23:18 EDT
3555 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3556 To: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3557 Cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
3558 Subject: At the tone, your name will be
3559 It would probably help if the ML and MD system logs were in some
3560 intuitively obvious place. Now that you have reminded me of their
3561 existance I suspect they are sitting on top of the CPUs or disks or
3562 something. If they were sitting by the consoles some of us space
3563 cadets might have remembered their existance and scrawled something in
3565 if i could have put them safely any closer to the consoles, i would have.
3566 i agree that on top of the CPUs is not the best location for visibility and
3567 memory-jogging, but it appeared to be the best i could do. if we could get
3568 some kind of little table beside MD's console (shoving the IMPLOD cabinet
3569 over), that would be better.
3571 Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 23:17:32 EDT
3572 Date: Wed, 21 May 1986 23:18 EDT
3573 Message-ID: <SRA.12208606423.BABYL@XX.LCS.MIT.EDU>
3574 From: Rob Austein <SRA@XX.LCS.MIT.EDU>
3575 To: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3576 Cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
3577 Subject: At the tone, your name will be
3578 In-reply-to: Msg of 21 May 1986 22:57-EDT from "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3580 It would probably help if the ML and MD system logs were in some
3581 intuitively obvious place. Now that you have reminded me of their
3582 existance I suspect they are sitting on top of the CPUs or disks or
3583 something. If they were sitting by the consoles some of us space
3584 cadets might have remembered their existance and scrawled something in
3587 Date: Wed, 21 May 86 22:57:57 EDT
3588 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3589 Subject: At the tone, your name will be
3590 To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU
3591 Message-ID: <[AI.AI.MIT.EDU].44335.860521.CENT>
3593 I have relabelled everything in sight except the KS's tapes; i'll get
3594 to those later this evening. i rediscovered the winning sort of
3595 labels, so the binder labels should no longer be quite so eager to
3598 NOTHING has been written in the ML and MD system logs for at least a
3599 week. nothing about bringing them down for DEC to borrow or loaning
3600 disks to XX or any such matters. will someone who knows what's been
3601 going on (SRA? JTW?) please insert a few notes so the rest of us can
3602 remain mildly informed?
3604 Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 03:17:42 EDT
3605 Date: Wed 21 May 86 03:19:00-EDT
3606 From: "John Wroclawski" <JTW%MIT-SPEECH@XX.LCS.MIT.EDU>
3607 Subject: Re: ks lossage
3608 To: JNC@XX.LCS.MIT.EDU, ALAN@AI.AI.MIT.EDU, ZVONA%MX.LCS.MIT.EDU@XX.LCS.MIT.EDU
3609 cc: bug-its@AI.AI.MIT.EDU
3610 In-Reply-To: <12208384120.19.JNC@XX.LCS.MIT.EDU>
3611 Message-ID: <12208388143.21.JTW@MIT-SPEECH>
3613 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
3614 Subject: Re: ks lossage
3616 I think the funny messages from the IMP have to do with some
3618 The RFC that describes 1822L tells all, claiming that the IMP will
3619 send the usual 3-NOP-and-a-reset sequence twice, once in 1822 format
3620 and once in 1822L format, interleaving the messages. You are supposed
3621 to tell it what you want by answering in your choice of format. If you
3622 do this before it has sent the full sequence it will stop sending in
3623 the protocol you don't want.
3625 Which is all well and good, except that this RFC is dated in 1983. So
3626 it only took them three years to implement...?
3629 Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 02:56:08 EDT
3630 Date: Wed 21 May 86 02:56:55-EDT
3631 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
3632 Subject: Re: ks lossage
3633 To: ALAN@AI.AI.MIT.EDU, ZVONA@MX.LCS.MIT.EDU
3634 cc: POOR-AI@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
3635 In-Reply-To: <[AI.AI.MIT.EDU].42635.860519.ALAN>
3636 Message-ID: <12208384120.19.JNC@XX.LCS.MIT.EDU>
3638 I think the funny messages from the IMP have to do with some
3639 new leader format that BBN is introducing. They flag the new style
3640 ones with what looks to old unmodified software with an illegal initial
3641 code. We've just run acrosss this bringing up the 68000 GW IMP code.
3644 Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 02:38:44 EDT
3645 Date: Wed 21 May 86 02:39:30-EDT
3646 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
3647 Subject: Re: flaky ML
3648 To: ALAN@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU
3649 cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU
3650 In-Reply-To: <[AI.AI.MIT.EDU].42474.860518.ALAN>
3651 Message-ID: <12208380952.19.JNC@XX.LCS.MIT.EDU>
3653 Maybe it's not an accident that the 3 machines had bum memory
3657 Date: Wed, 21 May 86 00:35:26 EDT
3658 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3659 Subject: 6 5 4 3 2 1 ...
3660 To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU,
3661 "(FILE [JNC:POOR MC])"@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU
3662 Message-ID: <[AI.AI.MIT.EDU].43668.860521.ALAN>
3664 OK folks, I switched the names MC and MX in the ITS sources and created new
3665 binaries for the two machines. I also edited AI:SYSHST;HSTLCS to reflect
3666 the swap. So the first symptom of this name swap that anyone will notice
3667 will appear early this morning when new host tables start circulating with
3668 the Chaosnet addresses switched. (Because we are switching both ArpaNet
3669 addresses and physical connections, the change manifests itself in the host
3670 tables as exchanged Chaosnet addresses.)
3672 Date: Tue, 20 May 86 14:26:00 EDT
3673 From: "Leigh L. Klotz" <KLOTZ@AI.AI.MIT.EDU>
3674 To: BUG-ITS@AI.AI.MIT.EDU
3675 Message-ID: <[AI.AI.MIT.EDU].43062.860520.KLOTZ>
3679 to get a histogram, and it started up a job called HP, which
3682 File can't be OPENed - DSK:FORT;HP SAV
3683 ^V VALRETS OR XFILES NESTED TOO DEEP?INPDL OVERFLOW - PDL RESET?
3685 but I guess that's another story.
3687 The fair share is 74%, btw.
3689 Date: Tue, 20 May 86 04:39:07 EDT
3690 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3691 Subject: AI's first GFR
3692 To: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
3693 Message-ID: <[AI.AI.MIT.EDU].42900.860520.CENT>
3695 sort of like its first date, or something -- it's just not the same
3698 anyway, the GFR did run over AI SECOND:, taking 5K blocks off to tape. Due
3699 to cruftiness not yet worked around in the code (something to do with EOT),
3700 we can't yet run incremental GFRs -- successive small GFRs onto the same
3701 tape. so i had to go for maximum usage of single tape instead. given the
3702 amount of tape left, i think i could have gone for 6K blocks and won; that
3703 we'll try next time.
3705 the tape is in the rack with the other ITS tapes. as usual, this is a
3706 Sacred GFR Tape -- be careful with it.
3708 All and Sundry are reminded that all 4 KSs (when they're running ITS) are
3709 regularly backed up -- help relieve AI's load by moving your files
3712 Date: Mon, 19 May 86 14:11:13 EDT
3713 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3715 To: ZVONA@MX.LCS.MIT.EDU
3716 cc: POOR-AI@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU
3717 In-reply-to: Msg of Mon 19 May 86 11:12:12 EDT from David Chapman <ZVONA at MX.LCS.MIT.EDU>
3718 Message-ID: <[AI.AI.MIT.EDU].42635.860519.ALAN>
3720 Date: Mon, 19 May 86 11:12:12 EDT
3721 From: David Chapman <ZVONA at MX.LCS.MIT.EDU>
3723 When the machine booted it printed a lot of stuff I couldn't follow
3726 All ITS machines with IMPs do this when you boot them now. I presume the
3727 software in the IMP has changed incompatibly somehow. We all have to learn
3728 to ignore this until somebody gets around to fixing it.
3730 'Nother funny thing: LAST time it was booted, it complained that it
3731 couldn't set the time, because 15 out of the 13 times it got from the
3732 net did not agree. Besides sounding damn funny, it seems that
3733 requiring 15 good times is a little stringent.
3735 Well, its just phrased a little funny. It -asked- 25 people, and it
3736 insists on getting 15 answers that agree back. If only 13 people respond,
3737 then indeed 15 of the 13 answers failed to agree!
3739 I don't want to insist on a majority of the -responders-, since then if
3740 only 1 machine responds that happens to be mistaken, the mistake spreads.
3741 Look at it this way, this demon is just a convenience to save you from
3742 having to run PDSET 95% of the time, you have to expect to do it manually
3745 Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 MAY 86 11:10:47 EDT
3746 Date: Mon, 19 May 86 11:12:12 EDT
3747 From: David Chapman <ZVONA@MX.LCS.MIT.EDU>
3749 To: poor-ai@AI.AI.MIT.EDU
3750 Message-ID: <[MX.LCS.MIT.EDU].587.860519.ZVONA>
3752 Do we need a poor-ks?
3754 At 6 this morning, MX started complaining often about being out of
3755 jobslots on the console. About 10, I couldn't supdup in, so I came
3756 up. I couldn't log into the console either -- it ignored ^Z. So I
3757 hit boot, and it said BT SW and ?BT 001200 and wouldn't listen to me.
3758 So I got the fep and started at 777700 and that didn't work either, so
3759 I booted again and it worked that time.
3761 My guess is that comsat is unhappy about its imp connection and dying
3762 without freeing up its slot.
3764 When the machine booted it printed a lot of stuff I couldn't follow
3767 'Nother funny thing: LAST time it was booted, it complained that it
3768 couldn't set the time, because 15 out of the 13 times it got from the
3769 net did not agree. Besides sounding damn funny, it seems that
3770 requiring 15 good times is a little stringent.
3772 Date: Sun, 18 May 86 21:39:55 EDT
3773 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3775 To: CENT@AI.AI.MIT.EDU
3776 cc: BUG-ITS@AI.AI.MIT.EDU
3777 In-reply-to: Msg of Sat 17 May 86 07:26:57 EDT from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
3778 Message-ID: <[AI.AI.MIT.EDU].42474.860518.ALAN>
3780 Date: Sat, 17 May 86 07:26:57 EDT
3781 From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
3782 ML was getting a gross and astonishing number of ECC errors this morning.
3784 We are talking -memory- EEC corrected errors rather than -disk- ECC
3785 corrected errors I believe.
3787 see console output around 3-4 am. what does this? what can we do about it?
3789 It means that there are some bad bits in ML's memory. Its funny, AI has
3790 never had a single one of these errors, but all -three- of the new KS10's
3791 have memory boards in them that get ECC errors.
3793 i was dumping it and shoving some files on during this time -- maybe this
3794 has something to do with the flaky chaosnet?
3796 Unlikely to be related other than the fact that you were just exercising
3797 the machine in general. The real problem here is that when I wrote the
3798 code for logging the ECC errors, I didn't fully understand what it would be
3799 like when they started happening regularly. (My code also has a bug that
3800 causes MD to essentially loop in the scheduler because of a bad bit in a
3801 particularly sensitive location.) I plan to re-write this code to be less
3802 noisy and more robust soon.
3804 Date: Sat, 17 May 86 07:30:43 EDT
3805 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3806 Subject: dumped state
3807 To: INFO-ITS@AI.AI.MIT.EDU
3808 Message-ID: <[AI.AI.MIT.EDU].42220.860517.CENT>
3810 as of this morning, all ITSs here (with the possible exception of the KL)
3811 are being regularly backed up to tape. it -is- safe to store your files on
3814 Date: Sat, 17 May 86 07:26:57 EDT
3815 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3817 To: BUG-ITS@AI.AI.MIT.EDU
3818 Message-ID: <[AI.AI.MIT.EDU].42218.860517.CENT>
3820 ML was getting a gross and astonishing number of ECC errors this morning.
3821 see console output around 3-4 am. what does this? what can we do about it?
3822 i was dumping it and shoving some files on during this time -- maybe this
3823 has something to do with the flaky chaosnet?
3825 Date: Mon, 12 May 86 03:47:03 EDT
3826 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3827 Subject: another way to confuse the issue
3828 To: MBECK@AI.AI.MIT.EDU
3829 cc: BUG-ITS@AI.AI.MIT.EDU
3830 Message-ID: <[AI.AI.MIT.EDU].37601.860512.CENT>
3832 Date: Sat, 10 May 86 01:11:28 EDT
3833 From: "Mark E. Becker" <MBECK@MC.LCS.MIT.EDU>
3834 Subject: MC <--> KS/MX mail switching
3835 To: CENT@MC.LCS.MIT.EDU
3836 After reading MC MAIL would it be a 'good thing' if I sent address
3837 update messages to those list maintainers saying that MBECK@MC should
3840 no. KL is a local-only nickname; on the general arpanet it's an alias for
3841 SRI-KL, and sending your mail there would not help anyone. when the KS
3842 (currently MX) and the KL (currently MC) switch names, they will retain
3843 their model aliases -- the KL will be called MX or (locally) KL, while the
3844 KS will be called MC or KS. this feature was arranged so we could do a
3845 number of local transforms. for instance, the KS will have somewhat
3846 restricted use, so it can concentrate on mail; thus, among other things, we
3847 don't want all those people who get mail on the present MC to have that
3848 mail land on the KS after the name switch. for this reason, someone has run
3849 a program over the inquir database to change all net-addresses of MC to KL;
3850 this will ensure that their mail will end up on the same physical machine
3851 as it does now. all ITS machines share a common inquir database and forward
3852 mail in accordance with the net-addresses people give therein, so all your
3853 mail will end up where you currently get it now. since your mail goes to
3854 OZ, it will continue to make one hop from MC (whichever hardware) to the
3855 twenex; if you received it on MC-KL, you would find it would begin taking
3856 an extra hop to reach your mailbox, because the KL will (probably) go off
3857 the arpanet when the names are switched and all mail bound for it will have
3858 to be forwarded through MC-KS or AI.
3860 Date: Sun, 11 May 86 21:28:30 EDT
3861 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3862 Subject: Ask, and you shall recieve
3863 To: SRA@XX.LCS.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU
3864 cc: BUG-INQUIR@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU,
3865 SRA@MC.LCS.MIT.EDU, ZVONA@MC.LCS.MIT.EDU
3866 In-reply-to: Msg of Sun 11 May 1986 04:59 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
3867 Message-ID: <[AI.AI.MIT.EDU].37394.860511.ALAN>
3869 Date: Sun, 11 May 1986 04:59 EDT
3870 From: Rob Austein <SRA at XX.LCS.MIT.EDU>
3871 ... (although it would be nice if it had some reasonable way to
3872 deduce what ITSs exist, at run-time).
3874 Because I was updating so many programs to know about the new plethora of
3875 ITS machines, I added exactly this feature. There is a new table you can
3876 ask for from the .GETSYS uuo: ITSNMS is a table of the sixbit names of the
3877 -current- local ITS machines. I have already converted most of the
3878 programs that used to have built-in tables of ITS machines (INSTAL, FINGER,
3879 FIND, etc.) to use this. Do
3883 Date: Sat, 10 May 86 18:26:28 EDT
3884 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3885 To: BUG-ITS@AI.AI.MIT.EDU
3886 cc: JSOL@AI.AI.MIT.EDU
3887 In-reply-to: Msg of Sat 10 May 86 16:56:50 EDT from Jon Solomon <JSOL at MC.LCS.MIT.EDU>
3888 Message-ID: <[AI.AI.MIT.EDU].37156.860510.ALAN>
3890 Date: Sat, 10 May 86 16:56:50 EDT
3891 From: Jon Solomon <JSOL at MC>
3892 for some reason I keep geting "all sockets in use" when there is
3893 nobody on the system. I did a :p a, and abuot 2/3rds of the connections
3894 are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe
3897 I reloaded the system to get rid of them since nobody could connect to MC
3898 using TCP. I left a crash dump in MC:CRASH;CRASH TIMWTS if some networking
3899 wizard wants to figure out what YALE.ARPA and SRI-UNIX.ARPA are doing that
3900 cause these connections to stay in TIMWT seemingly forever.
3902 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 MAY 86 16:57:36 EDT
3903 Date: Sat, 10 May 86 16:56:50 EDT
3904 From: Jon Solomon <JSOL@MC.LCS.MIT.EDU>
3905 To: BUG-ITS@MC.LCS.MIT.EDU
3906 Message-ID: <[MC.LCS.MIT.EDU].909418.860510.JSOL>
3908 for some reason I keep geting "all sockets in use" when there is
3909 nobody on the system. I did a :p a, and abuot 2/3rds of the connections
3910 are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe
3913 Date: Fri, 9 May 86 23:43:36 EDT
3914 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3915 Subject: another mysterious lossage
3916 To: CENT@AI.AI.MIT.EDU
3917 cc: BUG-ITS@AI.AI.MIT.EDU
3918 In-reply-to: Msg of Fri 9 May 86 22:38:16 EDT from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
3919 Message-ID: <[AI.AI.MIT.EDU].37001.860509.ALAN>
3921 Date: Fri, 9 May 86 22:38:16 EDT
3922 From: Pandora B. Berman <CENT at AI.AI.MIT.EDU>
3923 around 22:15 or so, AI stopped listening.... dumped it to CRASH;ITS
3924 HUNG, then reloaded.
3926 Looks like the same disk lossage again. This time ITS had actually run out
3927 of disk clannels. Perhaps there is something wrong with one of the drives.
3928 I'll try to figure this out after I get finished with this paper. (I don't
3929 grok the disk code well enough to do this immediately.) I hope AI
3930 continues to work for that long... I renamed the crash to be
3931 AI:CRASH;CRASH QLOSS"
3933 BTW, penny, I figured out why MX's system console wouldn't talk to you.
3934 The 8080 front end sometimes gets confused about the state of the system
3935 console and stops forwarding characters through to the 10 (running out of
3936 paper sometimes causes this to happen). If you simply power-cycle the
3937 LA120 this resets the 8080's opinion of things and you can use the system
3938 console for input again.
3940 Date: Fri, 9 May 86 22:38:16 EDT
3941 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
3942 Subject: another mysterious lossage
3943 To: BUG-ITS@AI.AI.MIT.EDU
3944 Message-ID: <[AI.AI.MIT.EDU].36993.860509.CENT>
3946 around 22:15 or so, AI stopped listening. it was willing to echo typein but
3947 would not act on it. also it echoed chaos packets, or heard them, or
3948 something low-level like that. DPH and i figured out how to raise switch0
3949 and dumped it to CRASH;ITS HUNG, then reloaded.
3951 Date: Thu, 8 May 86 22:24:56 EDT
3952 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3953 Subject: Recent software crashes.
3954 To: BUG-ITS@AI.AI.MIT.EDU
3955 cc: SRA@AI.AI.MIT.EDU
3956 Message-ID: <[AI.AI.MIT.EDU].36473.860508.ALAN>
3958 Two recent crashes (in MC:CRASH;CRASH DRGFKT and AI:CRASH;CRASH BJUIS)
3959 suggest that there is some problem with job device locking strategy. I
3960 guess we should have expected that having COMSAT using a job device 24
3961 hours a day would expose some bugs. The crash on MC is completely crazed
3962 in the number of jobs that are confused.
3964 AI just crashed again with the same lossage I complained about a couple
3965 weeks ago. The one where the system hangs up just like it does on MC when
3966 the T-300 controller gets fucked. (See AI:CRASH;CRASH QLOSS and
3967 AI:CRASH;CRASH QLOSS'.)
3969 Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 8 May 86 07:46:48 EDT
3970 Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2693388755368144@MIT-MULTICS.ARPA>; 08 May 1986 07:32:35 edt
3971 Date: 08 May 86 00:44 +0200
3972 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
3973 Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA,
3974 ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
3975 To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA,
3976 KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU, "Alan Bawden"
3977 <ALAN@AI.AI.MIT.EDU>
3978 Subject: State of the world
3979 Message-ID: <172046@QZCOM>
3980 In-Reply-To: <[AI.AI.MIT.EDU].35019.860506.ALAN>
3982 We are looking forward, to the moment when we can load the tape
3983 in the tape drive and have the system flying.
3988 Date: Tue, 6 May 86 00:40:15 EDT
3989 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
3990 Subject: State of the world
3991 To: KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU
3992 Message-ID: <[AI.AI.MIT.EDU].35019.860506.ALAN>
3994 There are now -five- machines running ITS at MIT, more than have ever
3995 existed simultaneously before. There is the MC KL10, and four KS10's named
3998 The MC KL10 is off maintenance contract as of the first of this month, so I
3999 suppose its days are numbered. At some point before the KL10 passes on to
4000 that great machine room in the sky, the MC KL10 and the MX KS10 will swap
4001 their names, and we will plug the new MC KS10 into the old MC's Arpanet
4002 port. This assures that as far as the outside world is concerned, there
4003 will always be an ITS named MC at that Arpanet address, performing mail
4004 service functions for MIT. (Let's not get into the hair we will be going
4005 through to make all the mailing lists in the world continue to work.)
4007 The KL10 will remain available for all those who wish to continue to use
4008 it, under the name MX. When the KL10 retires, the name MX will be retired
4011 Various other owners of KS10's around the world will be receiving KS10 ITS
4012 distribution tapes in the mail soon. The last machine we booted (MD) was
4013 built by a volunteer using the printed instructions we plan to include with
4014 our ITS distribution kits.
4016 Date: Thu, 1 May 86 05:28:04 EDT
4017 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
4018 Subject: imp lossage
4019 To: BUG-ITS@AI.AI.MIT.EDU
4020 Message-ID: <[AI.AI.MIT.EDU].33406.860501.CENT>
4022 AI crashed around 3 or so. complained about IMP lossage of some sort.
4023 dumped to CRASH;IMPOS LOSS.
4025 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 15:05:01 EDT
4026 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 15:04:56 EDT
4027 Date: Wed, 30 Apr 86 15:04:37 EDT
4028 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4030 To: PGS@AI.AI.MIT.EDU
4031 cc: KLOTZ@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
4032 BUG-SUPDUP@MC.LCS.MIT.EDU
4033 In-reply-to: Msg of Wed 30 Apr 86 02:43:20 EDT from Patrick G. Sobalvarro <PGS at AI.AI.MIT.EDU>
4034 Message-ID: <[AI.AI.MIT.EDU].33061.860430.ALAN>
4036 Date: Wed, 30 Apr 86 02:43:20 EDT
4037 From: Patrick G. Sobalvarro <PGS at AI>
4038 Date: Tue, 29 Apr 86 08:31:04 EDT
4039 From: Alan Bawden <ALAN at AI>
4040 (Note that until recently ROLM lines incorrectly had the %TYDIL bit
4041 set in their TTYTYP words, perhaps you are noticing an effect of
4043 I thought %TYDIL was correct for the ROLM lines, since they are exactly
4044 analogous to dialups; one connects terminals of different types to them, so
4045 they should have their tty types reset to something neutral when
4046 disconnected, etc. And, if we supported it in the 11, they should hang up
4047 after they've been logged out for a while, all those dialup-y things.
4049 I should have been more careful about how I used the word "incorrectly".
4050 As you set things up originally the ROLM lines were just like dialups and
4051 had %TYDIL set for all of the reasons you give. This all worked just fine
4052 and there wasn't a thing wrong with it. Then I got my greasy fingers into
4055 I added a %TYRLM bit for the benefit of people and programs that wanted the
4056 distinguish between ordinary dialups that you tended to connect to from
4057 outside NE43 (like from home), and ROLM lines that you tended to connect to
4058 from inside NE43 (like from your office). In this state of affairs ITS
4059 tested %TYDIL to determine if it should do all those dialup-y things, and
4060 programs that wanted to know if you were at home could test to see if
4061 %TYDIL was set and %TYRLM wasn't.
4063 The problem is that there were a zillion programs (most of them written in
4064 DDT command language) that just tested %TYDIL to see if the user was at
4065 home. Rather than fix all of them, I changed the meaning of %TYDIL to mean
4066 what those programs already thought. That way I only had to fix ITS to
4067 test for %TYDIL+%TYRLM in those places where it was already testing just
4070 Now it is true that this broke programs that thought that %TYDIL meant
4071 "connected through a line that needs to have its terminal type set", but
4072 since somebody had to lose this argument I decided that these programs were
4073 simply mistaken about the meaning of that bit.
4075 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 02:43:41 EDT
4076 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 02:43:40 EDT
4077 Date: Wed, 30 Apr 86 02:43:20 EDT
4078 From: "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>
4080 To: ALAN@AI.AI.MIT.EDU
4081 cc: KLOTZ@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
4082 BUG-SUPDUP@MC.LCS.MIT.EDU
4083 In-reply-to: Msg of Tue 29 Apr 86 08:31:04 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
4084 Message-ID: <[AI.AI.MIT.EDU].32866.860430.PGS>
4086 Date: Tue, 29 Apr 86 08:31:04 EDT
4087 From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
4089 Date: Mon, 28 Apr 86 15:44:36 EDT
4090 From: Leigh L. Klotz <KLOTZ at MC>
4091 I'm connected to MC via the Rolm Data Feature on T25. My init
4092 file insists that I'm on a line that already knows its tty type
4093 and SUPDUP warns me not to net hop. Perhaps the tty types file
4096 The TTYTYP file knows that T25 is a ROLM line, and the running ITS on MC at
4097 this moment does as well. How does your init file determine if you are on
4098 a line that "already knows its tty type"? Perhaps it does something bogus.
4099 (Note that until recently ROLM lines incorrectly had the %TYDIL bit set in
4100 their TTYTYP words, perhaps you are noticing an effect of this change.)
4102 I thought %TYDIL was correct for the ROLM lines, since they are exactly
4103 analogous to dialups; one connects terminals of different types to them, so
4104 they should have their tty types reset to something neutral when
4105 disconnected, etc. And, if we supported it in the 11, they should hang up
4106 after they've been logged out for a while, all those dialup-y things.
4108 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 APR 86 08:31:35 EDT
4109 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 08:31:13 EDT
4110 Date: Tue, 29 Apr 86 08:31:04 EDT
4111 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4113 To: KLOTZ@AI.AI.MIT.EDU
4114 cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-SUPDUP@MC.LCS.MIT.EDU
4115 In-reply-to: Msg of Mon 28 Apr 86 15:44:36 EDT from Leigh L. Klotz <KLOTZ at MC.LCS.MIT.EDU>
4116 Message-ID: <[AI.AI.MIT.EDU].32475.860429.ALAN>
4118 Date: Mon, 28 Apr 86 15:44:36 EDT
4119 From: Leigh L. Klotz <KLOTZ at MC>
4120 I'm connected to MC via the Rolm Data Feature on T25. My init
4121 file insists that I'm on a line that already knows its tty type
4122 and SUPDUP warns me not to net hop. Perhaps the tty types file
4125 The TTYTYP file knows that T25 is a ROLM line, and the running ITS on MC at
4126 this moment does as well. How does your init file determine if you are on
4127 a line that "already knows its tty type"? Perhaps it does something bogus.
4128 (Note that until recently ROLM lines incorrectly had the %TYDIL bit set in
4129 their TTYTYP words, perhaps you are noticing an effect of this change.) I
4130 don't know what SUPDUP does, but I do know that the nethop-detection code
4131 was recently rewritten. Perhaps it is doing something bogus as well.
4133 If this happens to you again, see if you can figure out just what TTY
4134 variables are the source of the problem. The output of :TCTYP DESCRIBE
4135 would be a good place to start.
4137 Date: Mon, 28 Apr 86 16:52:29 EDT
4138 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
4140 To: BUG-ITS@AI.AI.MIT.EDU
4141 Message-ID: <[AI.AI.MIT.EDU].32120.860428.CENT>
4143 all the KSs have log books. AI's and MX's are on the little DM cabinet.
4144 MD's and ML's are on their CPUs. please write things in them. like "Brain
4145 transplant performed, all is well", or "now running NITS", or "jumpers
4146 attacked with soldering iron, arpanet up". if you don't write things down,
4147 no one will know they happened if you are not available to say so.
4149 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 APR 86 15:44:27 EDT
4150 Date: Mon, 28 Apr 86 15:44:36 EDT
4151 From: "Leigh L. Klotz" <KLOTZ@MC.LCS.MIT.EDU>
4152 To: BUG-ITS@MC.LCS.MIT.EDU
4153 Message-ID: <[MC.LCS.MIT.EDU].897692.860428.KLOTZ>
4155 I'm connected to MC via the Rolm Data Feature on T25. My init
4156 file insists that I'm on a line that already knows its tty type
4157 and SUPDUP warns me not to net hop. Perhaps the tty types file
4160 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 APR 86 16:35:40 EST
4161 Date: Sat, 26 Apr 86 16:35:24 EST
4162 From: Daniel Weise <DANIEL@MC.LCS.MIT.EDU>
4163 To: BUG-ITS@MC.LCS.MIT.EDU
4164 Message-ID: <[MC.LCS.MIT.EDU].895936.860426.DANIEL>
4166 I found MC in a PI level 7 bugpause. The console line
4167 above the bugpuase was "too many parity errors." I dumped
4168 to CRASH PARITY and cold booted.
4172 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 APR 86 12:55:36 EST
4173 Date: Sun, 20 Apr 86 12:54:59 EST
4174 From: "Devon S. McCullough" <DEVON@MC.LCS.MIT.EDU>
4175 To: BUG-ITS@MC.LCS.MIT.EDU
4176 Message-ID: <[MC.LCS.MIT.EDU].889795.860420.DEVON>
4178 MC bughalted sometime around 10am, bugpc/caia uret2+2
4179 so I dumped it into .;CRASH URGH and tried to warm boot
4180 but the KL10 halted immediately so I cold booted it.
4182 Date: Fri, 18 Apr 86 03:37:32 EST
4183 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4184 Subject: devices and names
4185 To: BUG-ITS@AI.AI.MIT.EDU, GZ@AI.AI.MIT.EDU
4186 Message-ID: <[AI.AI.MIT.EDU].28319.860418.ALAN>
4188 The DEVICE directory was getting full due to the proliferation of various
4189 ITS names (past, present, and future), 20X names (for RMTDEV), and various
4190 concatenations of DIR with other device names. So I increased, yet again,
4191 the knowledge inside the unknown device handler (SYS;ATSIGN DEVICE) itself.
4193 The unknown device handler now loads various foreign filesystem devices
4194 from DEVICE;ATSIGN MLDEV or DEVICE;ATSIGN RMTDEV as appropriate. Various
4195 DIR devices that deal with the local filesystem are loaded directly from
4196 DEVICE;ATSIGN DIRDEV. Foreign filesystem DIR devices are loaded from
4197 DEVICE;ATSIGN MLDEV. (Archive DIR devices are not treated specially.)
4199 Note that the unknown device handler always checks the DEVICE directory for
4200 a JOBDEV file -before- looking at this new built-in knowledge, so it is
4201 easy to do local customizations on each machine. (Like on AI, the DIRAI
4202 device is loaded from ATSIGN DIRDEV, whereas the default is to load it from
4205 Oh yeah. One of the reasons I was forced to do this is I added two
4206 synonyms for MC and MX. MC is now known also as "KL" and MX is now also
4207 known as "KS". The devices KL: and KS: work everywhere as appropriate.
4208 When we swap the names "MC" and "MX" (that is, when MC becomes a KS10, and
4209 MX becomes a KL10), we -won't- swap the names "KL" and "KS". Thus the file
4210 KL:ALAN;FOO BAR is the same file today as it will be next year, while
4211 MC:ALAN;FOO BAR will be a different one.
4213 (This did have the odd side effect that the NETWRK library now returns
4214 "MIT-KL" as the SIXBIT name for MC...)
4216 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 APR 86 20:18:29 EST
4217 Date: Fri, 4 Apr 86 20:18:37 EST
4218 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4219 Subject: MC UNIT 1/PACK 13
4220 To: KARENS@MC.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU,
4222 In-reply-to: Msg of Fri 4 Apr 86 17:34:02 EST from Alan Bawden <ALAN at MC.LCS.MIT.EDU>
4223 Message-ID: <[MC.LCS.MIT.EDU].874128.860404.ALAN>
4225 Date: Fri, 4 Apr 86 17:34:02 EST
4226 From: Alan Bawden <ALAN at MC.LCS.MIT.EDU>
4227 Date: Fri, 4 Apr 86 02:08:45 EST
4228 From: Pandora B. Berman <CENT at AI>
4229 has DEC made any progress in fixing this RP04?...
4230 apparently they came today and replaced the entire RP04....
4232 And apparently it works for me, although when TK tried to bring it up he
4235 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 APR 86 17:33:53 EST
4236 Date: Fri, 4 Apr 86 17:34:02 EST
4237 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4238 Subject: MC UNIT 1/PACK 13
4239 To: KARENS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU
4240 cc: BUG-ITS@AI.AI.MIT.EDU
4241 In-reply-to: Msg of Fri 4 Apr 86 02:08:45 EST from Pandora B. Berman <CENT at AI.AI.MIT.EDU>
4242 Message-ID: <[MC.LCS.MIT.EDU].873744.860404.ALAN>
4244 Date: Fri, 4 Apr 86 02:08:45 EST
4245 From: Pandora B. Berman <CENT at AI>
4248 Re: MC UNIT 1/PACK 13
4249 has DEC made any progress in fixing this RP04?...
4251 apparently they came today and replaced the entire RP04. Whoever brought
4252 MC up after this decided for some reason that it was still broken. The
4253 console hardcopy doesn't look like they tried very hard, but I wasn't there
4254 so I don't know what really happened... Perhaps I'll take MC down for a
4255 few minutes tonight and see if I can figure out what the problem is.
4257 Date: Fri, 4 Apr 86 02:08:45 EST
4258 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
4259 Subject: MC UNIT 1/PACK 13
4260 To: KARENS@AI.AI.MIT.EDU
4261 cc: BUG-ITS@AI.AI.MIT.EDU
4262 Message-ID: <[AI.AI.MIT.EDU].23885.860404.CENT>
4264 has DEC made any progress in fixing this RP04? i've gone by occasionally
4265 and seen notes promising to come back with more parts, but it's still
4266 offline. this is causing some potential problems: while Alan has made lots
4267 of progress in moving everything vital to AI, he can't move anything from
4268 SECOND: (PK13) because it's offline. maybe you could check on how DEC is
4269 doing on this, and impulse them to further effort if necessary? thanks.
4271 Received: from MOSCOW-CENTRE.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAR 86 05:02:53 EST
4272 Date: Mon, 31 Mar 86 05:02 EST
4273 From: David Vinayak Wallace <Gumby@MIT-MC.ARPA>
4274 Subject: disowned vs in background
4275 To: BARTH@MIT-AI.ARPA, MBECK@MIT-AI.ARPA
4276 cc: BUG-ITS@MIT-AI.ARPA
4277 In-Reply-To: <[AI.AI.MIT.EDU].22357.860329.CENT>
4278 Message-ID: <860331050242.8.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU>
4280 Date: Sat, 29 Mar 86 17:23:33 EST
4281 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
4283 Date: Thu 27 Mar 86 06:47:55-EST
4284 From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
4285 I admit ignorance as well... when I see a "disowned" job on an ITS, its
4286 usually associated with some username somewhere.
4287 ----------begin forwarded mail----------
4288 Date: Wed, 26 Mar 86 23:17:29 EST
4289 From: Richard Barth <BARTH@MC.LCS.MIT.EDU>
4291 Ignorant question for today...
4292 What's the difference between running a job in the background and
4295 beyond my limited technical ability to describe. someone on this list should
4296 be able to help you more.
4298 Roughly speaking, a disowned job has no superior nor controlling TTY,
4299 (f'rinstance like COMSAT normally runs). DDT lets you run jobs in
4300 background, (e.g. w/
\10 or
\e\e\10) by running them without the TTY and
4301 handling output differently. Their superior is still DDT. From ITS's
4302 point of view the only difference between running a job in foreground or
4303 in background is who owns the TTY.
4305 For a more detailed description, do :UUO .DISOWN, .ATTY, etc.
4309 PS: bug-its people: what do you think of using BUG-ITS for questions
4310 like this? I think it's a good idea, but if it's going to cause the
4311 fixers of bugs to remove themselves on the grounds of traffic
4312 levels, then we should have yet another list.
4314 Date: Mon, 31 Mar 86 00:52:51 EST
4315 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4316 Subject: AI:CRASH;CRASH QLOSS
4317 To: BUG-ITS@AI.AI.MIT.EDU
4318 Message-ID: <[AI.AI.MIT.EDU].22618.860331.ALAN>
4320 AI:CRASH;CRASH QLOSS contains a crash dump that I can't figure out. I
4321 don't, unfortunately, grok the interface between the main program level
4322 disk code and the interrupt level. It looked for all the world (to the
4323 users) like what happens on MC when the system is hung trying to write
4324 directories to the T-300's. I can tell that the main program level code is
4325 waiting for bits to arrive from interrupt level, but I don't understand why
4326 interrupt level isn't coming through.
4328 Of course, the fact that we have two disk drives for the first time on a KS
4329 is something to be suspicious of...
4331 Date: Sat, 29 Mar 86 17:23:33 EST
4332 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
4334 To: BARTH@AI.AI.MIT.EDU, MBECK@AI.AI.MIT.EDU
4335 cc: BUG-ITS@AI.AI.MIT.EDU
4336 Message-ID: <[AI.AI.MIT.EDU].22357.860329.CENT>
4338 Date: Thu 27 Mar 86 06:47:55-EST
4339 From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
4340 To: Cent@MC.LCS.MIT.EDU
4341 cc: Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, Barth@MC.LCS.MIT.EDU
4342 I admit ignorance as well... when I see a "disowned" job on an ITS, its
4343 usually associated with some username somewhere.
4344 ----------begin forwarded mail----------
4345 Date: Wed, 26 Mar 86 23:17:29 EST
4346 From: Richard Barth <BARTH@MC.LCS.MIT.EDU>
4347 To: MBECK@MC.LCS.MIT.EDU
4348 Ignorant question for today...
4349 What's the difference between running a job in the background and
4352 beyond my limited technical ability to describe. someone on this list should
4353 be able to help you more.
4355 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAR 86 07:57:25 EST
4356 Date: Sat, 29 Mar 86 07:58:39 EST
4357 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4358 Subject: So why did I bother you?
4359 To: BUG-ITS@AI.AI.MIT.EDU
4360 In-reply-to: Msg of Sat 29 Mar 86 05:40:15 EST from Alan Bawden <ALAN at AI.AI.MIT.EDU>
4361 Message-ID: <[MC.LCS.MIT.EDU].865489.860329.ALAN>
4363 Date: Sat, 29 Mar 86 05:40:15 EST
4364 From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
4365 Well I just noticed that right now all new files on AI are being placed
4366 on the secondary pack!
4368 This turned out to be easy to fix. If the pack on unit #0 had enough free
4369 space, ITS never noticed that it was not a primary pack. I fixed ITS to
4370 find a primary pack the first time someone writes a file after a boot.
4372 Date: Sat, 29 Mar 86 05:40:15 EST
4373 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4374 To: BUG-ITS@AI.AI.MIT.EDU
4375 Message-ID: <[AI.AI.MIT.EDU].22278.860329.ALAN>
4377 When I booted AI Friday morning, I wanted to test that I had built a
4378 working front-end filesystem and DSKDMP on the secondary pack. Since both
4379 the 8080 front end and DSKDMP assume they should boot from unit #0, I
4380 switched the unit number plugs so that the secondary pack was on unit #0
4381 and the primary pack was on unit #1.
4383 Well I just noticed that right now all new files on AI are being placed on
4384 the secondary pack! Yesterday, with the units arranged the other way files
4385 were being made on PK0: just like the should have. Perhaps this is some
4386 unforseen result of my decision to number the secondary pack #1? (I should
4387 have chosen #13 to be conventional, but couldn't think of any reason why I
4388 couldn't choose any number I wanted.) Barf.
4390 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAR 86 00:51:46 EST
4391 Date: Sat, 29 Mar 86 00:53:03 EST
4392 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4393 Subject: crash;crash massbs: I see no unit #1 here.
4394 To: MLY@MC.LCS.MIT.EDU
4395 cc: BUG-ITS@MC.LCS.MIT.EDU
4396 In-reply-to: Msg of Fri 28 Mar 86 11:20:19 EST from Richard Mlynarik <MLY at MC.LCS.MIT.EDU>
4397 Message-ID: <[MC.LCS.MIT.EDU].865339.860329.ALAN>
4399 Date: Fri, 28 Mar 86 11:20:19 EST
4400 From: Richard Mlynarik <MLY at MC>
4403 Apparently the controller told ITS that drive #1, which I believe is
4404 powered off, was asking for attention. (Perhaps it was wondering when DEC
4405 was coming back with the part they need to fix it.) When ITS obligingly
4406 asked the controller to ask the drive what its status was, the controller
4407 reported that it timed out on the drive. I guess we write this one off to
4408 hardware flakeiness.
4410 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 11:18:57 EST
4411 Date: Fri, 28 Mar 86 11:20:19 EST
4412 From: Richard Mlynarik <MLY@MC.LCS.MIT.EDU>
4413 Sender: MLY5@MC.LCS.MIT.EDU
4414 Subject: crash;crash massbs
4415 To: BUG-ITS@MC.LCS.MIT.EDU
4416 Message-ID: <[MC.LCS.MIT.EDU].864552.860328.MLY5>
4420 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 09:17:59 EST
4421 Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 28 Mar 86 09:04:06 EST
4422 Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449266; Fri 28-Mar-86 08:52:48-EST
4423 Date: Fri, 28 Mar 86 09:00 EST
4424 From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
4425 Subject: where do sources live?
4426 To: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>, ALAN@MC.LCS.MIT.EDU
4427 cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU
4428 In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
4429 Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
4431 Date: Thu, 27 Mar 86 17:25:42 EST
4432 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4434 Why not delete sources from MC to prevent forking?
4436 Why not take the phones and phone books out of your office on the
4437 grounds you have sets at home?
4440 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 09:02:44 EST
4441 Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 28 Mar 86 09:04:06 EST
4442 Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449266; Fri 28-Mar-86 08:52:48-EST
4443 Date: Fri, 28 Mar 86 09:00 EST
4444 From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
4445 Subject: where do sources live?
4446 To: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>, ALAN@MC.LCS.MIT.EDU
4447 cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU
4448 In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
4449 Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
4451 Date: Thu, 27 Mar 86 17:25:42 EST
4452 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4454 Why not delete sources from MC to prevent forking?
4456 Why not take the phones and phone books out of your office on the
4457 grounds you have sets at home?
4460 Date: Fri, 28 Mar 86 09:02:47 EST
4461 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4462 Subject: A new ITS is born
4463 To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU,
4464 KARENS@AI.AI.MIT.EDU
4465 Message-ID: <[AI.AI.MIT.EDU].22057.860328.ALAN>
4467 MIT-MX came up for the first time this morning. (You can supdup there
4468 right now, but you won't find much when you get there...) There are still
4469 some problems with the technology for creating new ITS systems from
4470 scratch, but it mostly works. Hopefully after doing the next two (ML and
4471 MD) things will be pretty smooth.
4473 All kind of worms are crawling out of the woodwork because of various
4474 programs that -know- that all ITS machines are named "AI", "MC", "ML", or
4475 "DM". It should take another days hacking to stomp them all...
4477 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 09:00:09 EST
4478 Date: Fri, 28 Mar 86 09:01:33 EST
4479 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4480 Subject: where do sources live?
4481 To: GUMBY@AI.AI.MIT.EDU
4482 cc: BUG-ITS@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
4483 In-reply-to: Msg of Thu 27 Mar 86 17:25:42 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
4484 Message-ID: <[MC.LCS.MIT.EDU].864470.860328.ALAN>
4486 Date: Thu, 27 Mar 86 17:25:42 EST
4487 From: David Vinayak Wallace <GUMBY at MC>
4488 Why not delete sources from MC to prevent forking?
4490 Because I think in would be a good idea for them to get on the last full
4493 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAR 86 17:24:48 EST
4494 Date: Thu, 27 Mar 86 17:25:42 EST
4495 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4496 Subject: where do sources live?
4497 To: ALAN@MC.LCS.MIT.EDU
4498 cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU
4499 In-reply-to: Msg of Thu 27 Mar 86 16:59:17 EST from Alan Bawden <ALAN at MC.LCS.MIT.EDU>
4500 Message-ID: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
4502 Why not delete sources from MC to prevent forking?
4504 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAR 86 16:58:22 EST
4505 Date: Thu, 27 Mar 86 16:59:17 EST
4506 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4507 To: JTW@MC.LCS.MIT.EDU
4508 cc: BUG-ITS@MC.LCS.MIT.EDU
4509 Message-ID: <[MC.LCS.MIT.EDU].863829.860327.ALAN>
4511 Pinhead! You modified MC:SYSNET;TELSER instead of AI:SYSNET;TELSER.
4512 If people make pinheaded mistakes like this we will be up to our
4513 necks in forked sources.
4515 Everybody: Remember that sources live on AI! If you are in doubt,
4516 look for a file named " MOVED TO AI " on the directory containing
4517 the source in question on MC. If this file exists, then all of
4518 the sources on that directory now live on AI. This has
4519 been true of all SYS*** directories for a couple of days now.
4521 Date: Sun, 23 Mar 86 21:27:35 EST
4522 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4523 Subject: Grand migration begins
4524 To: BUG-ITS@AI.AI.MIT.EDU, BUG-DDT@AI.AI.MIT.EDU,
4525 KS-ITS@AI.AI.MIT.EDU
4526 Message-ID: <[AI.AI.MIT.EDU].20774.860323.ALAN>
4528 OK this is it. The migration of ITS system files from MC to AI is
4529 beginning. I have already moved a few directories and mailing lists and
4530 having just moved Bug-ITS and Bug-DDT to AI, I thought I would test them by
4531 informing you all of how this migration will work. I expect to have most
4532 of the SYS*** directories moved to AI by tomorrow. If you have some
4533 question about the status of a particular directory, look for a file on
4534 that directory named " MOVED TO AI ". If that file exists, then the file
4535 you are looking for now lives on AI, edits on MC are likely to be lost. If
4536 that file doesn't exist, then MC still has the master copy. In any case,
4537 if I am logged in, be cautious about timing screws.
4539 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 MAR 86 16:31:26 EST
4540 Received: from R20.UTEXAS.EDU by AI.AI.MIT.EDU.ARPA; 23 Mar 86 10:09:54 EST
4541 Received: from ALAMO.UTEXAS (ALAMO.UTEXAS.EDU.#Internet) by R20.UTEXAS.EDU with TCP; Sun 23 Mar 86 09:08:28-CST
4542 Date: Sun, 23 Mar 86 09:06 CST
4543 From: Gavan Duffy <AI.DUFFY@UTEXAS-20.UTEXAS>
4545 To: BUG-ITS@MIT-AI.ARPA
4546 Message-ID: <860323090604.3.GAVAN@ALAMO.UTEXAS>
4548 It isn't on AI. Sigh. I had to CHTN to Jimi Hendrix to QSEND.
4551 Date: Mon, 3 Mar 86 02:12:36 EST
4552 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4553 Subject: " mode in PEEK
4554 To: BUG-ITS@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU
4555 Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN>
4557 I added a new mode to PEEK for printing the contents of the system message
4558 buffer. (Type a doublequote to get it.) This is especially useful for
4559 looking at crash dumps. While I was at it I added a few features to crash
4560 dump mode itself. For a good example try (on AI):
4561 :PEEK <CRASH;IMP NXM
4562 and after looking at the crash dump display, type " to see some more
4563 interesting error messages.
4565 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 FEB 86 23:32:35 EST
4566 Date: Wed, 26 Feb 86 23:35:16 EST
4567 From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
4568 Subject: ai crashed again
4569 To: BUG-ITS@AI.AI.MIT.EDU
4570 Message-ID: <[AI.AI.MIT.EDU].16595.860226.CENT>
4572 not just with the NXM during DUMP lossage. it got that (during the CHECK
4573 phase) and proceeded immediately to an MTAPE:RH11 error, IMP:I NXM...
4574 dumped to CRASH;IMP NXM. so i reloaded and tried to run ICHECK on the
4575 tape. it got a DSK ERR UNTI#0... BUGPC/CAI QHE+3 $Q-2/SKIPGE Q,,QSDU
4576 dumped to CRASH;DISK ERR.
4577 the second time, ICHECK worked.
4579 Date: Tue, 25 Feb 86 14:02:21 EST
4580 From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
4582 To: BUG-ITS@MC.LCS.MIT.EDU
4583 Message-ID: <[MC.LCS.MIT.EDU].830224.860225.GUMBY>
4585 MC crashed, it looks like because it thought one of the tridents had
4586 been powered off. I doubt anybody cares, but I dumped it to CRASH
4587 QINTE0 just in case.
4589 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 FEB 86 13:36:26 EST
4590 Date: Mon, 24 Feb 86 13:38:49 EST
4591 From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
4592 To: BUG-ITS@AI.AI.MIT.EDU
4593 Message-ID: <[AI.AI.MIT.EDU].16000.860224.ALAN>
4595 Well, basically I don't seem to ever be able to get the space to end of
4596 tape operation to work for me. Symptom: Mount a scratch tape and copy
4597 some files onto it (using :COPY for example). Rewind the tape (using the
4598 REWIND command in DUMP). Open MT0: in .BIO mode and issue a
4599 .MTAPE [ch,,[10]], while watching the drive. Observe that it clearly
4600 doesn't go to the end of the tape. Do the same UUO again without closing
4601 the channel and get an IRRECOVERABLE DATA ERROR.
4603 We are certainly going to need space-to-end-of-tape to work before we can
4604 start doing GFRs on a regular basis, since I understand GFR tapes are
4605 just appended together.
4607 Another oddity: Suppose you wrote three files on the tape. Rewind the
4608 tape and try reading them (using :PRINT). Observe that it looks like there
4609 is an extra, fourth, empty file after the files you wrote (before you start
4610 getting DEVICE FULL, which I presume is what you expect to get at the end
4613 Date: Mon, 24 Feb 86 13:14:44 EST
4614 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4615 Subject: This tape misery never ends.
4616 To: BUG-ITS@MC.LCS.MIT.EDU
4617 Message-ID: <[MC.LCS.MIT.EDU].828798.860224.ALAN>
4619 A fellow just tried to read a 7-track tape (from ML) on AI's tape drive.
4620 The results were pretty interesting. He certainly didn't get any bits back
4621 and he caused DUMP and the magtape code to get pretty upset. The real fun
4622 started when he tried to kill the DUMP job. His DDT got hung up in .UCLOSE
4623 at MTICL+12 waiting for outstanding tape commands to go away.
4625 I took a crash dump in AI:CRASH;MTAPE CLOSE. Note that some interesting
4626 error messages from the tape driver were printed on the system console
4627 before this happened.
4629 I'll bet lots of pinheads try this in the future. Perhaps we sould license
4630 people before they can run DUMP?
4632 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 FEB 86 00:30:33 EST
4633 Date: Wed, 19 Feb 86 00:32:01 EST
4634 From: "Christopher C. Stacy" <CSTACY@AI.AI.MIT.EDU>
4636 To: BUG-ITS@AI.AI.MIT.EDU
4637 Message-ID: <[AI.AI.MIT.EDU].14598.860219.CSTACY>
4639 AI crashed in the IMP code (at IMPIOS+4). I dumped it to CRASH;CSTACY IMPOS.
4641 Date: Fri, 24 Jan 86 02:24:13 EST
4642 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4643 Subject: pifail again
4644 To: BUG-ITS@MC.LCS.MIT.EDU
4645 cc: CENT@AI.AI.MIT.EDU
4646 In-reply-to: Msg of Fri 24 Jan 86 01:20:52 EST from Pandora B. Berman <CENT5%AI.AI.MIT.EDU at MC.LCS.MIT.EDU>
4647 Message-ID: <[MC.LCS.MIT.EDU].794321.860124.ALAN>
4649 Date: Fri, 24 Jan 86 01:20:52 EST
4650 From: Pandora B. Berman <CENT5 at AI>
4652 is the name of the latest crash dump, again during an incr. dump.
4654 NXM on the Unibus again. This time the victimized instruction:
4656 MGWJD1: IORDI T,%TMCS1 ;Get controller status
4658 Unfortunately, all of a sudden Penny seems unable to get through an
4659 incremental dump without having this (or some Unibus NXM) happen. (Unlike
4660 the Chaos net board glitch the other day which only happened once.) Maybe
4661 the LH/DH really -does- have something to do with this? Or perhaps someone
4662 needs to physically tighten up everything on that Unibus.
4664 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86 02:08:01 EST
4665 Date: Fri, 24 Jan 86 01:20:52 EST
4666 From: "Pandora B. Berman" <CENT5%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
4667 Subject: pifail again
4668 To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
4669 Message-ID: <[AI.AI.MIT.EDU].11649.860124.CENT5>
4671 is the name of the latest crash dump, again during an incr. dump.
4673 Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JAN 86 14:50:57 EST
4674 Date: Tue 21 Jan 86 14:49:58-EST
4675 From: John Wroclawski <JTW%MIT-SPEECH@MIT-MC.ARPA>
4676 Subject: Re: ai crash
4677 To: Moon@SCRC-STONY-BROOK.ARPA
4678 cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU,
4680 In-Reply-To: Message from "David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>" of Tue 21 Jan 86 14:15:38-EST
4683 Does anyone know how long the NXM timeout on a KS10 unibus is? The
4684 Chaos board can be slower to respond (3 or 4 microseconds?) when you
4685 read it twice in a row, as I recall.
4687 I think I remember it being 20 us.
4689 Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each
4690 other? If not, connecting a Unibus cable between them might cause
4691 electrical problems.
4693 That's a thought; they're not.
4695 I'm inclined to write this off to cosmic rays, and worry about it if it
4696 ever happens again after the hardware configuration of that unibus
4700 Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 21 Jan 86 14:05:53 EST
4701 Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397698; Tue 21-Jan-86 13:51:23-EST
4702 Date: Tue, 21 Jan 86 13:51 EST
4703 From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
4706 cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-ITS@MC.LCS.MIT.EDU,
4707 KS-ITS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU
4708 In-Reply-To: <[MC.LCS.MIT.EDU].790256.860120.ALAN>
4709 Message-ID: <860121135123.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
4711 Date: Mon, 20 Jan 86 23:00:11 EST
4712 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4714 Date: Mon, 20 Jan 86 22:32:34 EST
4715 From: Pandora B. Berman <CENT at AI>
4716 dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt
4717 complained about. see log for numbers. it was checking the incr. dump
4718 when this happened. after AI came up, the first time i tried to run
4719 ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE
4720 IN DEV. HUNG or something -- see sys log for details. the second time
4721 i tried ICHECK, it worked.
4723 The immediate cause of the crash was here in the interrupt level Chaos net
4726 CHSRC5: IORDI B,CAIRBF ;Read out the data, halfwords
4729 The second read from CAIRBF got a Non-Existent I/O Register error; just
4730 like someone had suddenly unplugged the Chaos board.
4732 I have a vague memory that Chaos boards do this sometimes. I hope I'm wrong.
4733 Alan and I discussed kludges for making the software resilient to this, but
4734 I hope we don't have to resort to them. It would be in the grand tradition
4735 of the previous two MIT-AI machines, though.
4737 If there were system
4738 messages from the magtape code indicating that it was unhappy as well, then
4739 perhaps we can conclude that the fault happened somewhere in the "I" Unibus
4740 itself. (It would be nice if :SYSMSG worked on a crash dump!)
4742 I used to have a program to do this, I think. Better would be to stick SYSMSG
4743 inside PEEK and then take advantage of PEEK's existing crash-dump-analysis feature.
4745 Perhaps someone who knows more Unibusology than I do can offer an opinion
4746 about what might cause this? Remember that this is the Unibus that
4747 supports the magtape drive, the DZ11's and the Chaosnet interface. The
4748 magtape code was shooting bits back and forth like crazy at the time,
4749 presumably that contributed somehow?
4751 JTW: Is the LH/DH plugged into this bus right now? Perhaps it did
4754 JTW: Can you look at the crash dump and figure out whether the magtape RH-11
4755 was supposed to be doing DMA at the time this crash happened? Maybe it and
4756 the Chaos board interfere with each other somehow?
4758 Does anyone know how long the NXM timeout on a KS10 unibus is? The Chaos
4759 board can be slower to respond (3 or 4 microseconds?) when you read it twice
4760 in a row, as I recall.
4762 Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each other? If not,
4763 connecting a Unibus cable between them might cause electrical problems.
4766 Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 23:12:00 EST
4767 Date: Mon 20 Jan 86 23:11:02-EST
4768 From: John Wroclawski <JTW%MIT-SPEECH@MIT-MC.ARPA>
4769 Subject: Re: ai crash
4770 To: alan@MC.LCS.MIT.EDU
4771 cc: CENT@AI.AI.MIT.EDU, bug-its@MC.LCS.MIT.EDU
4772 In-Reply-To: Message from "Alan Bawden <ALAN@MC.LCS.MIT.EDU>" of Mon 20 Jan 86 23:06:09-EST
4774 JTW: Is the LH/DH plugged into this bus right now? Perhaps it did
4777 Yes, and maybe so. Specially since it doesn't seem to work like it is
4778 supposed to right at the moment. It would be nice to know the state
4779 of the UBA at that point in time...
4782 Date: Mon, 20 Jan 86 23:00:11 EST
4783 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4785 To: BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
4786 cc: CENT@AI.AI.MIT.EDU
4787 In-reply-to: Msg of Mon 20 Jan 86 22:32:34 EST from Pandora B. Berman <CENT%AI.AI.MIT.EDU at MC.LCS.MIT.EDU>
4788 Message-ID: <[MC.LCS.MIT.EDU].790256.860120.ALAN>
4790 Date: Mon, 20 Jan 86 22:32:34 EST
4791 From: Pandora B. Berman <CENT at AI>
4792 dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt
4793 complained about. see log for numbers. it was checking the incr. dump
4794 when this happened. after AI came up, the first time i tried to run
4795 ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE
4796 IN DEV. HUNG or something -- see sys log for details. the second time
4797 i tried ICHECK, it worked.
4799 The immediate cause of the crash was here in the interrupt level Chaos net
4802 CHSRC5: IORDI B,CAIRBF ;Read out the data, halfwords
4805 The second read from CAIRBF got a Non-Existent I/O Register error; just
4806 like someone had suddenly unplugged the Chaos board. If there were system
4807 messages from the magtape code indicating that it was unhappy as well, then
4808 perhaps we can conclude that the fault happened somewhere in the "I" Unibus
4809 itself. (It would be nice if :SYSMSG worked on a crash dump!)
4811 Perhaps someone who knows more Unibusology than I do can offer an opinion
4812 about what might cause this? Remember that this is the Unibus that
4813 supports the magtape drive, the DZ11's and the Chaosnet interface. The
4814 magtape code was shooting bits back and forth like crazy at the time,
4815 presumably that contributed somehow?
4817 JTW: Is the LH/DH plugged into this bus right now? Perhaps it did
4820 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 22:32:38 EST
4821 Date: Mon, 20 Jan 86 22:32:34 EST
4822 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
4824 To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
4825 Message-ID: <[AI.AI.MIT.EDU].11362.860120.CENT>
4827 dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt
4828 complained about. see log for numbers. it was checking the incr. dump
4829 when this happened. after AI came up, the first time i tried to run
4830 ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE
4831 IN DEV. HUNG or something -- see sys log for details. the second time
4832 i tried ICHECK, it worked.
4834 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 16:03:59 EST
4835 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JAN 86 16:04:12 EST
4836 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 17 Jan 86 16:03:39 EST
4837 Date: Fri 17 Jan 86 15:31:41-EST
4838 From: J. J. Tyrone Sealy <TY@XX.LCS.MIT.EDU>
4839 Subject: Re: tape lossage
4840 To: Moon@SCRC-STONY-BROOK.ARPA
4841 cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU,
4842 TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
4843 In-Reply-To: <860117134457.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
4844 Message-ID: <12176026589.28.TY@XX.LCS.MIT.EDU>
4846 If you can come over. Please do. Unless there is someone else that can fix it.
4850 Date: Fri, 17 Jan 86 15:51:48 EST
4851 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4852 Subject: tape lossage
4853 To: CENT@AI.AI.MIT.EDU
4854 cc: BUG-ITS@MC.LCS.MIT.EDU, TY@MC.LCS.MIT.EDU,
4855 Moon@SCRC-STONY-BROOK.ARPA
4856 In-reply-to: Msg of Fri 17 Jan 86 13:44 EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
4857 Message-ID: <[MC.LCS.MIT.EDU].787522.860117.ALAN>
4859 Date: Fri, 17 Jan 86 13:44 EST
4860 From: David A. Moon <Moon at SCRC-STONY-BROOK>
4861 Date: Fri, 17 Jan 86 07:43:58 EST
4862 From: "Pandora B. Berman" <CENT at AI>
4863 i wandered over to bring up MC when it crashed, and noticed tape 4000
4864 on the drive. apparently Ty was running a full dump. the dump log
4865 contains a note on the MC 4000 line: "Something happened". dave,
4866 didn't you say something about 4000 being the max. number for an
4867 ITS tape? how does this get fixed?
4868 I don't recall saying that. There is a limit on the highest tape number
4869 that's controlled by the size of the SYSENG;MACRO TAPES file. The limit
4870 can be changed; I don't remember how, but it involves code in DUMP that's
4871 commented something like "Don't do this unless you are RJL, and even then
4872 be careful." We probably don't need to import RJL to do it. If you need
4873 me to come over and figure out the details, ask.
4875 This limit must have been reached in the past since the full dump tapes
4876 recorded in the database only go back to some time in 1983.
4878 But just in case, I figured out the way to change the limit and upped it to
4879 5000. So we probably don't need to worry about this limit on MC ever
4882 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 13:49:12 EST
4883 Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JAN 86 13:49:23 EST
4884 Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 17 Jan 86 13:48:45 EST
4885 Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 395098; Fri 17-Jan-86 13:44:24-EST
4886 Date: Fri, 17 Jan 86 13:44 EST
4887 From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
4888 Subject: tape lossage
4889 To: Pandora B. Berman <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
4890 cc: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU,
4891 TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
4892 In-Reply-To: <[AI.AI.MIT.EDU].11164.860117.CENT>
4893 Message-ID: <860117134457.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
4895 Date: Fri, 17 Jan 86 07:43:58 EST
4896 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
4898 i wandered over to bring up MC when it crashed, and noticed tape 4000
4899 on the drive. apparently Ty was running a full dump. the dump log
4900 contains a note on the MC 4000 line: "Something happened". dave,
4901 didn't you say something about 4000 being the max. number for an
4902 ITS tape? how does this get fixed?
4904 I don't recall saying that. There is a limit on the highest tape number
4905 that's controlled by the size of the SYSENG;MACRO TAPES file. The limit
4906 can be changed; I don't remember how, but it involves code in DUMP that's
4907 commented something like "Don't do this unless you are RJL, and even then
4908 be careful." We probably don't need to import RJL to do it. If you need
4909 me to come over and figure out the details, ask.
4912 Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 07:43:43 EST
4913 Date: Fri, 17 Jan 86 07:43:58 EST
4914 From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
4915 Subject: tape lossage
4916 To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
4917 cc: TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, MOON%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
4918 Message-ID: <[AI.AI.MIT.EDU].11164.860117.CENT>
4920 i wandered over to bring up MC when it crashed, and noticed tape 4000
4921 on the drive. apparently Ty was running a full dump. the dump log
4922 contains a note on the MC 4000 line: "Something happened". dave,
4923 didn't you say something about 4000 being the max. number for an
4924 ITS tape? how does this get fixed?
4926 Date: Sat, 11 Jan 86 18:25:45 EST
4927 From: Chris Hanson <CPH@MC.LCS.MIT.EDU>
4928 Subject: Losing Dialup
4929 To: BUG-SYSTEM@MC.LCS.MIT.EDU
4930 Message-ID: <[MC.LCS.MIT.EDU].780740.860111.CPH>
4932 When I dial x6985, I am getting a connection which responds to my
4933 carriage return with the standard "Connected to MC.", but then it
4934 fails to give me a HACTRN. C-Z has no effect.
4936 I notice that *nobody* is logged in from a dialup. This seems like it
4939 Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jan 86 04:47:57 EST
4940 Received: from bostonu by csnet-relay.csnet id ac02199; 6 Jan 86 4:39 EST
4941 Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
4942 id AA14297; Sun, 5 Jan 86 17:08:56 est
4943 Date: Sun, 5 Jan 1986 17:09 EST
4944 Message-Id: <[BUCS20].JSOL. 5-Jan-86 17:09:02>
4945 From: Jon Solomon <JSOL%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA>
4946 To: Alan Bawden <mit-eddie!ALAN%MC.LCS.MIT.EDU@bu-cs.bunet>
4947 Cc: BUG-ITS@mit-mc.arpa, BUG-MAIL@mit-mc.arpa, BUG-RANDOM-PROGRAM@mit-mc.arpa,
4949 Subject: [JSOL: TELECOM] Consider this a warning.
4950 Phase-Of-The-Moon: LQ+2D.21H.36M.2S.
4951 In-Reply-To: Msg of 5 Jan 1986 15:26-EST from Alan Bawden <mit-eddie!ALAN%MC.LCS.MIT.EDU at bu-cs>
4953 Okay, now I know the intended audience for my message. One fact that
4954 I forgot to mention in the other message was that this JUST started
4955 happening about a week ago. Whoever is hacking COMSAT, please take note.
4962 Date: Sun, 5 Jan 86 15:26:51 EST
4963 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
4964 Subject: [JSOL: TELECOM] Consider this a warning.
4965 To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU,
4966 BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
4967 Message-ID: <[MC.LCS.MIT.EDU].773515.860105.ALAN>
4970 Date: 01/05/86 13:22:00
4971 From: JSOL at XX.LCS.MIT.EDU
4972 To: *BBOARD at XX.LCS.MIT.EDU
4975 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 13:21:49 EST
4976 Date: Sun 5 Jan 86 13:24:23-EST
4977 From: Jon Solomon <JSOL@XX.LCS.MIT.EDU>
4979 To: BBOARD@MC.LCS.MIT.EDU
4980 Message-ID: <12172857686.19.JSOL@XX.LCS.MIT.EDU>
4982 Due to the installation of a new mail system, I can no longer ship off
4983 TELECOM to MC. Since there are quite a large number of MC users on
4984 TELECOM, and considering the fact that this restriction might affect
4985 other digests, I am sending this message to your bulletin board rather
4986 than individually to MC users.
4988 I -believe- what he is refering to is the fact that digests tend to be
4989 large enough that they exceed COMSAT's pitifully small size limitation.
4991 I note that CSTACY claimed the lock for hacking COMSAT two weeks ago,
4992 hacked on it for an evening, and hasn't logged in since then.
4994 There are now about 130 BADREQ files on .MAIL2, many of them 2 weeks old.
4995 (I'm going to have to create .MAIL3 soon...)
4997 Warning: If the day ever comes that I feel that it is Up-To-Me-
4998 To-Do-Something about COMSAT (because of address space problems, lack of
4999 proper domain support, or whatever) I will simply advise everybody that ITS
5000 no longer supports mail for users or mail forwarding for the network and I
5003 I feel this day -rapidly- approaching. I don't see any competent
5004 programmers making the kind of necessary effort it is going to take to
5005 straighten out this mess. I am forwarding this message to a large audience
5006 in the hopes that somebody will get inspired, but I realize this is
5009 Date: Fri, 3 Jan 86 00:33:24 EST
5010 From: "J. Noel Chiappa" <JNC@MC.LCS.MIT.EDU>
5011 Subject: Static routes in MC's routing table
5012 To: BUG-TCP@MC.LCS.MIT.EDU
5013 cc: BUG-ITS@MC.LCS.MIT.EDU, JNC@MC.LCS.MIT.EDU
5014 Message-ID: <[MC.LCS.MIT.EDU].771596.860103.JNC>
5016 There are way too many (old) static routes in the table. They
5017 don't seem to get updated correctly; data for SCRC was going through the
5018 (loaded) MIT-GW instead of the (idle) MIT-AI-GW, although the rest
5019 of the Internet got the change months ago. Someone should delete all
5020 but the necessary ones. I deleted the SCRC one and patched it out in the
5021 running system, with the result that it instantly picked up the right one.
5022 Also, the ICMP Redirect code is not the best possible in that
5023 it does no handle per-Host Redirects well; it folds them all into
5024 the single net entry. When we start attaching ITSen to subnetted nets,
5025 this will lose big; traffic to different subnets will thrash the
5026 cache line. For that matter, the ITS IP layer doesn't use the correct
5027 'mask' algorithm for dealing with host addresses (per RFC940, etc).
5029 Date: Sat, 28 Dec 85 19:00:48 EST
5030 From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
5031 Subject: page fault in system
5032 To: GUMBY@MC.LCS.MIT.EDU
5033 cc: HIC@MC.LCS.MIT.EDU, POOR-MC@MC.LCS.MIT.EDU,
5034 BUG-ITS@MC.LCS.MIT.EDU
5035 In-reply-to: Msg of Sun 22 Dec 85 15:21:29 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
5036 Message-ID: <[MC.LCS.MIT.EDU].767454.851228.ALAN>
5038 [ Why are we Cc'ing this message to HIC? ]
5040 Date: Sun, 22 Dec 85 15:21:29 EST
5041 From: David Vinayak Wallace <GUMBY at MC>
5042 ITS took a page fault. Look in CRASS PAGFLT if you care.
5044 Specifically, ITS took a page fault running in the scheduler. It thought
5045 it was looking at somebody's USTP bits, but U contains gubbish, and it
5046 looks like the hardware pagetable must have contained some kind of a joke
5047 as well. I am tempted to agree with you that this was the result of
5048 glitch. (That must be what you think since you mailed this to Poor-MC,
5051 PS: Someone seems to have deleted the pooor-mc alias.
5053 I don't think it ever really had that name, at least not for long. I
5054 suggested it, but I think somebody corrected my joke thinking it was a typo
5057 Date: Mon, 23 Dec 85 05:50:31 EST
5058 From: Gail Zacharias <GZ@MC.LCS.MIT.EDU>
5059 Subject: Compression
5060 To: ALAN@MC.LCS.MIT.EDU
5061 cc: BUG-ITS@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU,
5062 LIN@MC.LCS.MIT.EDU, PGS@OZ.AI.MIT.EDU
5063 In-reply-to: Msg of Mon 16 Dec 85 15:46:52 EST from Alan Bawden <ALAN at MIT-MC.ARPA>
5064 Message-ID: <[MC.LCS.MIT.EDU].764485.851223.GZ>
5066 AR4:GZ;ENCODE and DECODE. Encoding a large text file typically gives
5067 a little over half of the original size.
5069 Date: Mon, 23 Dec 85 00:22:08 EST
5070 From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
5072 To: BUG-ITS@MC.LCS.MIT.EDU
5073 Message-ID: <[MC.LCS.MIT.EDU].764318.851223.GSB>
5075 I just got "IBO" on the dialups. i tried 6985, 6986, and 6989 for
5078 Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Dec 85 14:30:51 EST
5079 Date: Thu 19 Dec 85 14:02:59-EST
5080 From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
5081 Subject: Re: ICMP: GW table full
5082 To: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, bug-tcp@MC.LCS.MIT.EDU
5083 cc: JNC@XX.LCS.MIT.EDU
5084 In-Reply-To: <[MIT-MC.ARPA].757281.851216.ALAN>
5085 Message-ID: <12168408267.46.JNC@XX.LCS.MIT.EDU>
5087 This is a harmless message. The IP routing table (see PEEK 'W'
5088 display) is a cache of the most recently used routes; when it fills up and
5089 needs to add a new route, it punts the lest recently route. The message
5090 is unnecessary. It would be good to notice if the cache is too small
5091 (e.g. if the route discarded was used less than five minutes ago) and
5092 log that; it might also be good to add a count of the number of cache
5093 flushes and the number flushed in, say, the last hour.
5096 Date: Mon, 16 Dec 85 23:20:56 EST
5097 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5098 Subject: ICMP: GW table full
5099 To: BUG-ITS@MIT-MC.ARPA
5100 Message-ID: <[MIT-MC.ARPA].757281.851216.ALAN>
5102 If you run SYSMSG on MC you will generally find that the message buffer
5103 is 90% full of messages of the form:
5104 ICMP: GW table full, net/gw 20024,,600000 1200,,76 => 30001,,255000 1200,,400045 MON 22:07:12
5105 I presume this all means something to KLH and the rest of you TCP hackers,
5106 but to me it is just an annoying amount of output that seems to be associated
5107 no problem that I can see. Is this a symptom of a real problem, or does it
5108 just mean that some fixed size table should be made a little larger? Or
5109 perhaps we should consider not bothering the system console with this
5110 common event, whatever it is.
5112 Date: Mon, 16 Dec 85 15:46:52 EST
5113 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5114 Subject: Compression
5115 To: LIN@MIT-MC.ARPA, GZ@MIT-MC.ARPA, PGS@MIT-OZ
5116 cc: BUG-ITS@MIT-MC.ARPA, GUMBY@MIT-MC.ARPA
5117 In-reply-to: Msg of Mon 16 Dec 1985 13:54 EST from PGS%MIT-OZ at MIT-MC.ARPA
5118 Message-ID: <[MIT-MC.ARPA].756680.851216.ALAN>
5120 Date: Mon, 16 Dec 1985 13:54 EST
5122 Date: Monday, 16 December 1985 12:08-EST
5123 From: David Vinayak Wallace <GUMBY at MC>
5124 do you know about the ARx devices?
5126 I don't think those perform text compression, do they?
5128 No, they don't. They make a collection of small files take less space on
5129 disk by removing the average of half a block of wasted space at the end of
5130 every file. They also take up less room in your directory because the
5131 names of the files are stored in the archive itself, leaving only one entry
5132 stored in your directory.
5134 If you are looking for a program that compresses ASCII text by taking
5135 advantage of the fact that certain sequences of characters are more common
5136 than others, I think that Gail Zacharias (GZ@MC) has the best program for
5137 this that I have seen. I can't seem to find it at the moment though. Gail?
5139 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 16 DEC 85 14:09:24 EST
5140 Date: Mon, 16 Dec 1985 13:54 EST
5141 Message-ID: <PGS.12167620265.BABYL@MIT-OZ>
5142 From: PGS%MIT-OZ@MIT-MC.ARPA
5143 To: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
5144 Cc: BUG-ITS@MIT-MC.ARPA, LIN@MIT-MC.ARPA
5145 In-reply-to: Msg of 16 Dec 1985 12:08-EST from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5147 Date: Monday, 16 December 1985 12:08-EST
5148 From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5149 To: LIN at MIT-MC.ARPA
5150 cc: BUG-ITS at MIT-MC.ARPA
5152 do you know about the ARx devices?
5154 I don't think those perform text compression, do they?
5156 Date: Mon, 16 Dec 85 12:08:03 EST
5157 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
5159 cc: BUG-ITS@MIT-MC.ARPA
5160 In-reply-to: Msg of Mon 16 Dec 85 11:51:47 EST from Herb Lin <LIN at MIT-MC.ARPA>
5161 Message-ID: <[MIT-MC.ARPA].756162.851216.GUMBY>
5163 do you know about the ARx devices?
5165 Date: Mon, 16 Dec 85 11:51:47 EST
5166 From: Herb Lin <LIN@MIT-MC.ARPA>
5167 To: BUG-ITS@MIT-MC.ARPA
5168 Message-ID: <[MIT-MC.ARPA].756101.851216.LIN>
5170 help requested from a wizard. Is there any way of doing rXX text compression
5171 on large text files purely on ITS... Something analagous to the SQUEEZE
5172 programs available for micros?
5178 Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 13 DEC 85 01:30:47 EST
5179 Date: Fri, 13 Dec 85 01:28:45 EST
5180 From: "Pandora B. Berman" <CENT%MIT-AI.ARPA@MIT-MC.ARPA>
5182 To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA
5183 Message-ID: <[MIT-AI.ARPA].8641.851213.CENT>
5185 ai suddenly hit a PI LEVEL 7 BUGHALT. crash dump to CRASH;SUDDEN LOSS
5187 Date: Mon, 9 Dec 85 19:41:51 EST
5188 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
5190 To: BUG-SYSTEM@MIT-MC.ARPA
5191 Message-ID: <[MIT-MC.ARPA].747566.851209.GUMBY>
5193 As you can guess, that should have gone to bug-system@oz. Sorry
5195 Date: Mon, 9 Dec 85 18:04:22 EST
5196 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
5197 Subject: dialup problem
5199 cc: BUG-SYSTEM@MIT-MC.ARPA
5200 In-reply-to: Msg of Mon 9 Dec 1985 16:22 EST from Chunka Mui <CHUNKA%MIT-OZ at MIT-MC.ARPA>
5201 Message-ID: <[MIT-MC.ARPA].747534.851209.GUMBY>
5203 OZ doesn't have the hardware. Your modem uses bell's 1200-baud
5204 frequencies. Vadic uses different ones.
5206 Date: Sat, 7 Dec 85 19:02:36 EST
5207 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5208 Subject: .msgs.; bloated
5209 To: BUG-COMSAT@MIT-MC.ARPA, CENT@MIT-AI.ARPA
5210 cc: BUG-ITS@MIT-MC.ARPA
5211 In-reply-to: Msg of Sat 7 Dec 85 06:10:23 EST from Pandora B. Berman <CENT%MIT-AI.ARPA at MIT-MC.ARPA>
5212 Message-ID: <[MIT-MC.ARPA].745744.851207.ALAN>
5214 Date: Sat, 7 Dec 85 06:10:23 EST
5215 From: Pandora B. Berman <CENT%MIT-AI.ARPA at MIT-MC.ARPA>
5216 for reasons unknown, AI can't figure out how to purge obsolete msgs
5217 from .MSGS.;. it wouldn't do it when the files weren't backed up, but
5218 i expected that. however, now the files are regularly backed up, the
5219 _LAST_ EXPIRE file looks well formed, but they -still- don't disappear
5220 on cue. MC, on the other hand, seems to have no problem in this regard.
5223 A Typical message from MC:.MSGS.;*MSG > begins:
5226 EXPIRES: 12/14/85 12:38:14
5227 Received: from BORAX by MIT-MC.ARPA 7 Dec 85 12:38:13 EST
5229 A typical message from AI:.MSGS.;*MSG > begins:
5231 Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 7 DEC 85 12:37:44 EST
5233 EXPIRES: 12/14/85 12:38:14
5234 Received: from BORAX by MIT-MC.ARPA 7 Dec 85 12:38:13 EST
5236 I suspect the recieved line at the front fakes GMSGS out when it tries to
5237 find the expiration date. This could be fixed by changing COMSAT to not do
5238 this, or by fixing GMSGS to be smarter. Somebody else is going to fix this
5239 one. (I don't think it can be all -that- hard guys!)
5241 Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 7 DEC 85 06:11:37 EST
5242 Date: Sat, 7 Dec 85 06:10:23 EST
5243 From: "Pandora B. Berman" <CENT%MIT-AI.ARPA@MIT-MC.ARPA>
5244 Subject: .msgs.; bloated
5245 To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA
5246 Message-ID: <[MIT-AI.ARPA].8152.851207.CENT>
5248 for reasons unknown, AI can't figure out how to purge obsolete msgs
5249 from .MSGS.;. it wouldn't do it when the files weren't backed up, but
5250 i expected that. however, now the files are regularly backed up, the
5251 _LAST_ EXPIRE file looks well formed, but they -still- don't disappear
5252 on cue. MC, on the other hand, seems to have no problem in this regard.
5255 Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 29 Nov 85 23:50:31 EST
5256 Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364604; Fri 29-Nov-85 23:45:47-EST
5257 Date: Fri, 29 Nov 85 23:44 EST
5258 From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
5259 Subject: Any takers?
5260 To: Alan Bawden <ALAN@MIT-MC.ARPA>
5261 cc: BUG-ITS@MIT-MC.ARPA, BUG-RANDOM-PROGRAM@MIT-MC.ARPA,
5263 In-Reply-To: <[MIT-MC.ARPA].692189.851024.ALAN>
5264 Message-ID: <851129234420.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
5266 Date: Thu, 24 Oct 85 23:38:25 EDT
5267 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5269 With all of these parity errors MC gets these days, and with all of these
5270 naive users who haven't the slightest idea what to do when they have
5271 detached job trees, the amount of disowned junk is getting to be a pain.
5272 Now there is really no good reason why a program couldn't be written that
5273 would would look around in the system for jobs with your XUNAME and offer
5274 some intelligent (and clearly explained) choices to you. Anybody
5275 interested? I'm not up for thinking about the problem right now, but I'd
5276 be happy to brainstorm in person with anyone else who would like to take a
5280 I'm sure I wrote this at Ellen's request and she put it into the init files of
5281 the known naive Macsyma users. I think it was called RETACH or something like
5285 Date: Tue, 29 Oct 85 20:47:43 EST
5286 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5287 Subject: Silly lineprinter devices again.
5288 To: INFO-ITS@MIT-MC.ARPA
5289 Message-ID: <[MIT-MC.ARPA].697383.851029.ALAN>
5291 Remember the 7LP: and 7LR: devices? Well, now that we have a third such
5292 device on the 9th floor, and another one coming soon to the 8th, it would
5293 make sense for me to tell you that I have installed 8LP: and 9LP: devices,
5294 right? WRONG! Since a clear numbering trend is emerging it makes sense to
5295 change the naming scheme so that the number comes -last-. So the official
5298 LP7: The 7th floor QMS 2400
5299 LP8: The 8th floor QMS 2400
5300 LP9: The 9th floor QMS 1200
5302 LR7: The 7th floor laserwriter
5304 The two old names 7LP: and 7LR: continue to work for compatibility.
5306 Date: Sun, 27 Oct 85 22:20:53 EST
5307 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5308 Subject: echoing weirdness
5309 To: GRENNY@MIT-MC.ARPA
5310 cc: BUG-ITS@MIT-MC.ARPA
5311 In-reply-to: Msg of Sun 27 Oct 85 20:08:43 EST from Ian Macky <GRENNY at MIT-MC.ARPA>
5312 Message-ID: <[MIT-MC.ARPA].694733.851027.ALAN>
5314 Date: Sun, 27 Oct 85 20:08:43 EST
5315 From: Ian Macky <GRENNY at MC>
5319 cTo OAF.G.BRIDGET@MIT-OZ:
5320 ittle pkish, perhaps... <End>
5322 [the "ec" from "peckish" got echoed before anything else... how WEIRD!!
5323 (well, not before everything, but you see)]
5325 Just another wierd case with echoing input at interrupt level. ITS decides
5326 how to do interrupt level echoing by looking at what job currently has
5327 control of the TTY. In this case DDT had control of the TTY for a few
5328 moments while it typed the Argus message, so ITS echoed the two characters
5329 you typed during those moments. (I guess FR is looking at %TXPIE bits in
5330 character to determine how to echo the user's typeahead.)
5332 I'm suprised that FR and REPLY aren't handling %PIATY interrupts. If they
5333 were you wouldn't have seen this happen. SEND seems to be hacking %PIATY;
5334 why should SENDER vary this aspect of its behavior for replying vs. sending?
5336 Date: Sun, 27 Oct 85 20:08:43 EST
5337 From: Ian Macky <GRENNY@MIT-MC.ARPA>
5338 To: BUG-ITS@MIT-MC.ARPA
5339 Message-ID: <[MIT-MC.ARPA].694678.851027.GRENNY>
5346 cTo OAF.G.BRIDGET@MIT-OZ:
5347 ittle pkish, perhaps... <End>
5349 [the "ec" from "peckish" got echoed before anything else... how WEIRD!!
5350 (well, not before everything, but you see)]
5352 Date: Thu, 24 Oct 85 23:38:25 EDT
5353 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5354 Subject: Any takers?
5355 To: BUG-ITS@MIT-MC.ARPA, BUG-RANDOM-PROGRAM@MIT-MC.ARPA,
5357 Message-ID: <[MIT-MC.ARPA].692189.851024.ALAN>
5359 With all of these parity errors MC gets these days, and with all of these
5360 naive users who haven't the slightest idea what to do when they have
5361 detached job trees, the amount of disowned junk is getting to be a pain.
5362 Now there is really no good reason why a program couldn't be written that
5363 would would look around in the system for jobs with your XUNAME and offer
5364 some intelligent (and clearly explained) choices to you. Anybody
5365 interested? I'm not up for thinking about the problem right now, but I'd
5366 be happy to brainstorm in person with anyone else who would like to take a
5369 Date: Tue, 22 Oct 85 14:29:28 EDT
5370 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5371 Subject: super-image mode/slaved ttys
5372 To: GUMBY@MIT-MC.ARPA
5373 cc: BUG-ITS@MIT-MC.ARPA, ED@MIT-MC.ARPA
5374 In-reply-to: Msg of Tue 22 Oct 85 00:14:31 EDT from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5375 Message-ID: <[MIT-MC.ARPA].688804.851022.ALAN>
5377 Date: Tue, 22 Oct 85 00:14:31 EDT
5378 From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5380 1> I know he's on the same kind of terminal I am, so I want whatere
5381 goes down the wire to his terminal to go down the wire to mine.
5383 2> I want the system to hack ^P codes for me so that I can poke around
5384 even if our terminals don't match.
5386 In my previous letter I was asking for 1> above, but two would be more
5387 useful in most cases. By "escape code" I meant some ^_ code to tell
5388 ITS just to pump the characters through.
5391 Getting any scheme like 2 to work is probably impossible. What do you do
5392 if the guy's terminal supports insert and delete character and yours
5393 doesn't? What about if his terminal is 5 lines longer than yours? Even
5394 virtual terminals have characteristics that are visible to the programs
5397 1 could be made to work I guess. You would have to do it at the level of
5398 %TD codes rather than ^P codes (since that is the only level at which there
5399 is really a universal language). There is a bunch of other things you have
5400 to worry about I guess, like making sure the characters you type get echoed
5401 in the way his program desires. Given that it can only work some of the
5402 time, and that it is pretty hard to get right, I can think of better things
5403 to do with our time.
5405 Date: Tue, 22 Oct 85 00:14:31 EDT
5406 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
5407 Subject: super-image mode/slaved ttys
5408 To: ALAN@MIT-MC.ARPA, ED@MIT-MC.ARPA
5409 cc: BUG-ITS@MIT-MC.ARPA
5411 Msg of Mon, 21 Oct 85 13:48:07 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
5412 Msg of Mon, 21 Oct 85 18:23:37 EDT from Ed Schwalenberg <ED at MIT-MC.ARPA>,
5413 Message-ID: <[MIT-MC.ARPA].687999.851022.GUMBY>
5415 Date: Mon, 21 Oct 85 13:48:07 EDT
5416 From: Alan Bawden <ALAN at MIT-MC.ARPA>
5418 Date: Mon, 21 Oct 85 06:11:40 EDT
5419 From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5421 Is there any way to get ITS to put your tty in super-image mode via
5422 escape codes? Otherwise when you slave a tty you get ghubbish (making
5423 slaved ttys almost useless. Are they a pre-TS3TTY relic?).
5425 I can't figure out what you are asking from this. First please distinguish
5426 between super-image input and super-image output (two quite unrelated
5427 things despite the similarity in names). Second please distinguish between
5428 the various kind of escape codes in the ITS world; are you talking about ^P
5429 codes? Third, by "slaved ttys" are you refering to the state you can
5430 achieve in a com-link where one console's type-in is seen by another
5433 Date: Mon, 21 Oct 85 18:23:37 EDT
5434 From: Ed Schwalenberg <ED at MIT-MC.ARPA>
5436 And fourth, is the TTY you are slaving logged-in or free, and what type
5437 (software, printing, AAA, etc.) is your TTY and the one you're slaving?
5439 Ok. Let me start over:
5441 Luser :LUSERs me and tells me he can't run BABYL. BABYL runs fine for
5442 me on his mail file. I'd like to ^_e him and poke around in the
5443 debugger in his BABYL. But all I get is ghubbish on my screen.
5445 Two possible ways that ITS could get around this (and maybe both are
5446 desirable for different circumstances):
5448 1> I know he's on the same kind of terminal I am, so I want whatere
5449 goes down the wire to his terminal to go down the wire to mine.
5451 2> I want the system to hack ^P codes for me so that I can poke around
5452 even if our terminals don't match.
5454 In my previous letter I was asking for 1> above, but two would be more
5455 useful in most cases. By "escape code" I meant some ^_ code to tell
5456 ITS just to pump the characters through.
5458 Free vs logged-in isn't relevent to this, since you can :TCTYP a free
5459 tty after sending a CALL through.
5461 Date: Mon, 21 Oct 85 23:08:10 EDT
5462 From: "Pandora B. Berman" <CENT@MIT-MC.ARPA>
5463 Subject: file system not fukt
5464 To: BUG-SYSTEM@MIT-MC.ARPA
5465 Message-ID: <[MIT-MC.ARPA].687814.851021.CENT>
5467 i should have been using $^R. my mind must be going. sorry to bother you.
5469 Date: Mon, 21 Oct 85 23:00:01 EDT
5470 From: "Pandora B. Berman" <CENT@MIT-MC.ARPA>
5471 Subject: FILE SYSTEM FUKT
5472 To: BUG-SYSTEM@MIT-MC.ARPA
5473 Message-ID: <[MIT-MC.ARPA].687803.851021.CENT>
5475 i was in ddt, moving some ostats files to third: with $$^O. it worked for
5476 the first one i tried no problem -- this was the second most recently
5477 created ostats file. then i tried
5478 $$^O ostats >,third:
5479 and got the reply that it can't copy to a different directory -- third:
5480 so i tried specifying the file version
5481 $$^O ostats 3636,third:
5483 third: .mail.;ostats 3636 - file exists (!)
5485 clearly someone is real confused here, and i don't think it's me.
5487 Date: Mon, 21 Oct 85 13:48:07 EDT
5488 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5489 Subject: super-image mode
5490 To: GUMBY@MIT-MC.ARPA
5491 cc: BUG-ITS@MIT-MC.ARPA
5492 In-reply-to: Msg of Mon 21 Oct 85 06:11:40 EDT from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5493 Message-ID: <[MIT-MC.ARPA].687073.851021.ALAN>
5495 Date: Mon, 21 Oct 85 06:11:40 EDT
5496 From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
5497 Is there any way to get ITS to put your tty in super-image mode via
5498 escape codes? Otherwise when you slave a tty you get ghubbish (making
5499 slaved ttys almost useless. Are they a pre-TS3TTY relic?).
5501 I can't figure out what you are asking from this. First please distinguish
5502 between super-image input and super-image output (two quite unrelated
5503 things despite the similarity in names). Second please distinguish between
5504 the various kind of escape codes in the ITS world; are you talking about ^P
5505 codes? Third, by "slaved ttys" are you refering to the state you can
5506 achieve in a com-link where one console's type-in is seen by another
5509 Date: Mon, 21 Oct 85 06:11:40 EDT
5510 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
5511 Subject: super-image mode
5512 To: BUG-ITS@MIT-MC.ARPA
5513 Message-ID: <[MIT-MC.ARPA].686691.851021.GUMBY>
5515 Is there any way to get ITS to put your tty in super-image mode via
5516 escape codes? Otherwise when you slave a tty you get ghubbish (making
5517 slaved ttys almost useless. Are they a pre-TS3TTY relic?).
5519 Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 10 OCT 85 03:15:49 EDT
5520 Date: Thu, 10 Oct 85 03:15:03 EDT
5521 From: Oded Feingold <OAF%MIT-AI.ARPA@MIT-MC.ARPA>
5522 To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA
5523 Message-ID: <[MIT-AI.ARPA].5013.851010.OAF>
5525 I plugged terminals in and out of TTY07, and eventually the DZ wouldn't
5526 answer anymore. I reloaded ITS, and left the crash dump on
5528 I doubt there's much interesting there.
5530 Date: Mon, 7 Oct 85 18:12:27 EDT
5531 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
5532 Subject: some job device losing
5533 To: BUG-ITS@MIT-MC.ARPA
5534 Message-ID: <[MIT-MC.ARPA].671384.851007.CSTACY>
5536 I can't use any jobdevs right now because there are a whole pile of
5537 what looks like MLDEVs with the jname "CFTP" and channels open on the
5538 file "OZKS: ;". I am going to gun them down, preserving one corpse
5539 CRASH;MLDEV OZ. The pc is/345 (.HANGing).
5542 Date: Thu, 3 Oct 85 23:49:07 EDT
5543 From: Tim McNerney <TIM@MIT-MC.ARPA>
5544 To: CSTACY@MIT-MC.ARPA
5545 cc: BUG-ITS@MIT-MC.ARPA
5546 In-reply-to: Msg of Thu 3 Oct 85 15:08:07 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
5547 Message-ID: <[MIT-MC.ARPA].668221.851003.TIM>
5549 Date: Thu, 3 Oct 85 15:08:07 EDT
5550 From: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
5551 To: BUG-ITS at MIT-MC.ARPA
5553 There is a POOR-MC@MC list now.
5557 Date: Thu, 3 Oct 85 15:08:07 EDT
5558 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
5559 To: BUG-ITS@MIT-MC.ARPA
5560 Message-ID: <[MIT-MC.ARPA].667593.851003.CSTACY>
5562 There is a POOR-MC@MC list now.
5564 Date: Mon, 30 Sep 85 17:37:39 EDT
5565 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5567 To: BUG-ITS@MIT-MC.ARPA
5568 Message-ID: <[MIT-MC.ARPA].663719.850930.ALAN>
5570 MC crashed twice today with parity errors in MH10-A (system memory). The
5571 I/O-11 crashed both times. I reconfigured the machine to swap MH10-A and
5572 MH10-B so that the next time errors occur in that box they won't be quite
5573 so fatal. Conceivably someone should log a service call with DEC. I did
5576 Date: Sat, 28 Sep 85 02:40:59 EDT
5577 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5579 cc: BUG-ITS@MIT-MC.ARPA
5580 In-reply-to: Msg of Fri 27 Sep 85 23:39:45 EDT from Gail Zacharias <GZ at MIT-MC.ARPA>
5581 Message-ID: <[MIT-MC.ARPA].661760.850928.ALAN>
5583 Date: Fri, 27 Sep 85 23:39:45 EDT
5584 From: Gail Zacharias <GZ at MIT-MC.ARPA>
5585 I keep getting top-level interrupts, about once every half hour.
5587 They are parity errors. Nothing that we can do anything about except throw
5588 the memory out the window. Look at the bright side: some operating systems
5589 would have halted the whole machine every time that happened, rather than
5590 just stopping a few jobs.
5592 I suppose we could make the message the user gets when he gets detached
5593 this way more explicit, but it hardly seems worth the effort given that the
5594 day is fast approaching when ITS will only run on KS10s, which (for the
5595 moment at least) are more reliable hardware.
5597 Date: Fri, 27 Sep 85 23:39:45 EDT
5598 From: Gail Zacharias <GZ@MIT-MC.ARPA>
5599 To: BUG-ITS@MIT-MC.ARPA
5600 Message-ID: <[MIT-MC.ARPA].661709.850927.GZ>
5602 I keep getting top-level interrupts, about once every half hour.
5604 Date: Fri, 27 Sep 85 23:15:08 EDT
5605 From: Gail Zacharias <GZ@MIT-MC.ARPA>
5606 To: BUG-ITS@MIT-MC.ARPA
5607 Message-ID: <[MIT-MC.ARPA].661707.850927.GZ>
5609 I keep getting top-level interrupts, about once every half hour.
5611 Date: Fri, 27 Sep 85 00:13:26 EDT
5612 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5614 To: BUG-COMSAT@MIT-MC.ARPA
5615 cc: BUG-ITS@MIT-MC.ARPA
5616 Message-ID: <[MIT-MC.ARPA].661199.850927.ALAN>
5618 Due to total bloat of .MAIL.; LISTS MSGS I have created .MAIL2 and moved
5619 many non-essential files there. Most of the queued mail is destined for OZ
5620 which will hopefull be up sometime tomorrow (so they tell me). COMSAT
5621 features that would be nice in a situation like this:
5623 It would be nice to be able to tell COMSAT to take all mail
5624 destined for a particular host and dump it all in some file somewhere and
5625 forget about it for a few days. Bouncing failed mail back to senders is
5626 counter-productive in a situation like the current one.
5628 It would be nice if COMSAT was smarter about the finite directory
5629 size. For example, if it looks to COMSAT like there might not be room to
5630 GC the LISTS MSGS file in place, it could output the new LISTS MSGS on a
5631 different directory (effectively doubling the available room for a GC).
5633 Easiest of all, perhaps you could set things up so that LISTS MSGS
5634 and the MAIL > files didn't live on the same directory? Having COMSAT's GC
5635 fighting for space with mail servers is moderately annoying at times.
5637 Date: Tue, 24 Sep 85 05:07:32 EDT
5638 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5639 Subject: Now installed on AI, and soon to be installed on MC.
5640 To: INFO-ITS@MIT-MC.ARPA
5641 Message-ID: <[MIT-MC.ARPA].657412.850924.ALAN>
5643 There is now a demon job that runs when ITS starts up that attempts to set
5644 the time from the network. The message that the system types out at boot
5645 time when it discovers that the clock has been reset no longer commands the
5646 hacker to log in and run PDSET, instead it tells him that he should just
5647 stick around a watch what happens in case he has to run it. The demon will
5648 print a message on the system console explaining what it did about the
5649 time. If the demon was unsatisfied that it could determine the time, the
5650 message will try to attract the hacker's attention and explain to him what
5651 the problem was and tell him that he does have to run PDSET after all.
5653 Date: Sat, 21 Sep 85 17:34:46 EDT
5654 From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
5655 To: BUG-ITS@MIT-MC.ARPA
5656 Message-ID: <[MIT-MC.ARPA].653477.850921.DEVON>
5658 I keep getting toplevel interrupts (presumably parity errors?)
5659 detaching my tree, twice in the last three hours.
5661 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 20 SEP 85 15:13:46 EDT
5662 Date: Fri, 20 Sep 1985 15:14 EDT
5663 Message-ID: <PGS.12144817429.BABYL@MIT-OZ>
5664 From: PGS%MIT-OZ@MIT-MC.ARPA
5665 To: "Ronald I. Greenberg" <RIG@MIT-MC.ARPA>, devon@MIT-MC.ARPA
5666 Cc: BUG-ITS@MIT-MC.ARPA, bug-tctyp@MIT-MC.ARPA
5667 Subject: terminal handler for heath
5668 In-reply-to: Msg of 20 Sep 1985 13:33-EDT from Ronald I. Greenberg <RIG at MIT-MC.ARPA>
5670 Date: Friday, 20 September 1985 13:33-EDT
5671 From: Ronald I. Greenberg <RIG at MIT-MC.ARPA>
5672 To: BUG-ITS at MIT-MC.ARPA
5673 Re: terminal handler for heath
5675 It appears that the terminal handler for heath terminals has been
5676 screwed up. Using either an actual heath or a Zenith Z-29-A,
5677 ":tctyp heath" results in something weird. A "?2h" gets printed on the
5678 terminal, and ocassionally at some point in time (generally when you
5679 get to the bottom of the screen I think) the terminal becomes totally
5680 wedged. This has been noticed by me and several other members of the
5681 Theory Group for the last couple days.
5683 I guess I was wrong. Devon, why don't you NOT put whatever you think is
5684 right in the TCTYP initialization string and instead re-install the old
5685 source and binaries.
5687 Date: Fri, 20 Sep 85 13:33:15 EDT
5688 From: Ronald I. Greenberg <RIG@MIT-MC.ARPA>
5689 Subject: terminal handler for heath
5690 To: BUG-ITS@MIT-MC.ARPA
5691 Message-ID: <[MIT-MC.ARPA].652278.850920.RIG>
5693 It appears that the terminal handler for heath terminals has been
5694 screwed up. Using either an actual heath or a Zenith Z-29-A,
5695 ":tctyp heath" results in something weird. A "?2h" gets printed on the
5696 terminal, and ocassionally at some point in time (generally when you
5697 get to the bottom of the screen I think) the terminal becomes totally wedged.
5698 This has been noticed by me and several other members of the Theory Group
5699 for the last couple days.
5701 Date: Fri, 20 Sep 85 12:40:25 EDT
5702 From: Gail Zacharias <GZ@MIT-MC.ARPA>
5704 To: ALAN@MIT-MC.ARPA
5705 cc: BUG-ITS@MIT-MC.ARPA
5706 In-reply-to: Msg of Wed 11 Sep 85 02:14:32 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
5707 Message-ID: <[MIT-MC.ARPA].652200.850920.GZ>
5709 There are servers on OZ, EE and XX. SPEECH is up to JTW I guess. The device
5710 will deduce Speech from SPxxxx, so you could add "SP" to the table.
5712 Right, OZKS: does KANSAS: so jobdev kansas can go if there is a space problem.
5714 I think I have the output problem fixed, so I guess I'm finished. Should I
5715 install it somewhere other than my dir?
5717 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 SEP 85 13:59:59 EDT
5718 Date: 19 Sep 1985 13:28 EDT (Thu)
5719 Message-ID: <JINX.12144535912.BABYL@MIT-OZ>
5720 From: Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>
5721 Subject: Gnu Emacs on ITS
5722 To: PGS%MIT-OZ@MIT-MC.ARPA
5723 Cc: BUG-ITS@MIT-MC.ARPA, "George J. Carrette" <GJC@MIT-MC.ARPA>
5724 In-reply-to: Msg of 19 Sep 1985 10:34-EDT from PGS
5726 What about the pain of having to emulate BSD4.2 system calls?
5728 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 SEP 85 12:32:14 EDT
5729 Date: Thu, 19 Sep 1985 10:34 EDT
5730 Message-ID: <PGS.12144504277.BABYL@MIT-OZ>
5731 From: PGS%MIT-OZ@MIT-MC.ARPA
5732 To: "George J. Carrette" <GJC@MIT-MC.ARPA>
5733 Cc: BUG-ITS@MIT-MC.ARPA
5734 In-reply-to: Msg of 18 Sep 1985 22:45-EDT from George J. Carrette <GJC at MIT-MC.ARPA>
5736 Date: Wednesday, 18 September 1985 22:45-EDT
5737 From: George J. Carrette <GJC at MIT-MC.ARPA>
5738 To: BUG-ITS at MIT-MC.ARPA
5739 cc: INFO-EXPLORER at MIT-MC.ARPA
5741 I wonder what GNU EMACS would be like used side-by-side with ITS EMACS?
5742 Is the C compiler on ITS up to it?
5744 I doubt that the address space on ITS is up to it, especially as the 10 C
5745 compiler doesn't do byte-packing.
5747 Date: Wed, 18 Sep 85 22:45:51 EDT
5748 From: George J. Carrette <GJC@MIT-MC.ARPA>
5749 To: BUG-ITS@MIT-MC.ARPA
5750 cc: INFO-EXPLORER@MIT-MC.ARPA
5751 Message-ID: <[MIT-MC.ARPA].650277.850918.GJC>
5753 I wonder what GNU EMACS would be like used side-by-side with ITS EMACS?
5754 Is the C compiler on ITS up to it?
5756 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 16 SEP 85 15:20:18 EDT
5757 Date: Mon, 16 Sep 1985 15:21 EDT
5758 Message-ID: <PGS.12143770091.BABYL@MIT-OZ>
5759 From: PGS%MIT-OZ@MIT-MC.ARPA
5760 To: "Devon S. McCullough" <DEVON@MIT-MC.ARPA>
5761 Cc: BUG-ITS@MIT-MC.ARPA, BUG-TCTYP@MIT-MC.ARPA
5762 Subject: H-19 initialization
5763 In-reply-to: Msg of 16 Sep 1985 10:13-EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
5765 Date: Monday, 16 September 1985 10:13-EDT
5766 From: Devon S. McCullough <DEVON at MIT-MC.ARPA>
5768 CRTSTY sends "
\e[?2h
\eE
\eG
\eO
\eq
\e\
\ew
\ey8
\ey9
\ey5
\ex1" but TCTYP only sends "
\ew"
5769 which is why CRTSTY will always win and TCTYP sometimes loses totally,
5770 because if the H19 was last used in ANSI mode you need to send
\e[?2h
5771 which either clears ANSI mode or puts a "?2h" turd on the screen.
5773 My personal feeling is that you should $[?$h$33g$F the bastards and THEN see
5774 if they try $259o$[J$[K'ing with you again.
5776 Or, alternatively, why don't you just change the initialization string in
5777 TCTYP to what you feel is right?
5779 Date: Mon, 16 Sep 85 10:13:03 EDT
5780 From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
5781 Subject: H-19 initialization
5782 To: BUG-TCTYP@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
5783 Message-ID: <[MIT-MC.ARPA].646431.850916.DEVON>
5785 CRTSTY sends "
\e[?2h
\eE
\eG
\eO
\eq
\e\
\ew
\ey8
\ey9
\ey5
\ex1" but TCTYP only sends "
\ew"
5786 which is why CRTSTY will always win and TCTYP sometimes loses totally,
5787 because if the H19 was last used in ANSI mode you need to send
\e[?2h
5788 which either clears ANSI mode or puts a "?2h" turd on the screen.
5790 CRTSTY also clears "graphics" (hah!) mode, where lower-case letters
5791 produce strange glyphs on the screen. I think it would be fun to
5792 fix ITS so terminals with 128 different displayable codes can print
5793 them if %TOSAI is turned on. On H19's and VT52's this would produce
5794 the oddity that control characters would echo down-arrow instead of ^
5795 before the uppercased character.
5797 Date: Wed, 11 Sep 85 02:14:32 EDT
5798 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5801 cc: BUG-ITS@MIT-MC.ARPA
5802 Message-ID: <[MIT-MC.ARPA].640776.850911.ALAN>
5804 The DEVICE directory was getting a bit full. The following three links
5805 seemed to form a pattern.
5807 L JOBDEV OZDNRF ==> DEVICE;JOBDEV OZ (7/18/85) GZ
5808 L JOBDEV OZKS ==> DEVICE;JOBDEV OZ (8/10/85) GZ
5809 L JOBDEV OZSS ==> DEVICE;JOBDEV OZ (8/13/85) GZ
5811 So I added OZ to the magic table in SYS:ATSIGN DEVICE so that -any- 4, 5,
5812 or 6, character device name that starts with "OZ" automatically loads
5813 DEVICE;JOBDEV OZ. (AI, MC, ML and DM were already in the table.) Then I
5814 deleted the links. There is also a link for a KANSAS: device. Can we do
5815 without this given that OZKS: works just as well? Should I add XX and EE?
5818 How close are you to having this thing really working? I haven't been able
5819 to use it to -write- a file yet, although I have been using it to read all
5820 kinds of things. (There don't seem to be many other people using the Emacs
5821 built on the long filename Teco, but it hasn't given me any problems at
5822 all. I guess once you think the device is "released" you can announce it
5823 together with the new Emacs. (I guess I should think about a long filename
5824 version of MacLisp...))
5826 Date: Sat, 7 Sep 85 16:54:01 EDT
5827 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
5828 Subject: LOUIE looping
5829 To: BUG-MAIL@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
5830 Message-ID: <[MIT-MC.ARPA].637052.850907.KLH>
5832 LOUIE.UDEL.EDU appears to be looping back mail for several lists,
5833 and giving us a bogus return-path to boot so that COMSAT error messages
5834 just add more loops. As a temporary measure I have put LOUIE in
5835 the LUZRS table for SYSBIN;FTPS BIN. This will cause all SMTP and FTP
5836 connection attempts from that host to be rejected. Obviously this
5837 is a desperation measure and a better remedy would be to add some
5838 smarts to COMSAT so that mail from there can be set aside for a while.
5839 I don't have the time right now for this. If someone is offended by the
5840 unilateral censorship they can just put a zero back in LUZRS.
5842 Date: Fri, 6 Sep 85 04:08:06 EDT
5843 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
5844 Subject: parity errors
5845 To: log-service-call@MIT-XX.ARPA
5846 cc: BUG-ITS@MIT-MC.ARPA
5847 Message-ID: <[MIT-MC.ARPA].635367.850906.GSB>
5849 MC's MH10 C was getting many parity errors, and has been shut off.
5850 DEC has been called (log # B90393) and will be checking in in the morning.
5852 Date: Sun, 1 Sep 85 12:57:40 EDT
5853 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5855 To: DEVON@MIT-MC.ARPA
5856 cc: BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
5857 In-reply-to: Msg of Sat 31 Aug 85 18:00:59 EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
5858 Message-ID: <[MIT-MC.ARPA].630167.850901.ALAN>
5860 Date: Sat, 31 Aug 85 18:00:59 EDT
5861 From: Devon S. McCullough <DEVON at MIT-MC.ARPA>
5863 By the way, how does the system know about sharable pure pages?
5864 If it knows that much why doesn't it know about binaries' filenames?
5866 It's because the concept of a "file" exists only at a higher level of
5867 abstraction than the level where page sharing is done. Sharing is done at
5868 the level of pages and disk blocks. A file is a name for a sequence of
5869 disk blocks, but there is no way to go backwards from a disk address to see
5870 which file (if any) it came from. (Other than mapping over the entire
5871 filesystem.) If there was some reason this operation needed to be done
5872 with great regularity, the information could be saved. But it is rare to
5873 want to do that, so we don't.
5875 (I actually have a tool that does it since I needed it once for debugging
5876 disk ECC recovery on AI. I think there might also be a routine in the
5877 version of the salvager that runs under timesharing that does it.)
5879 Date: Sat, 31 Aug 85 18:00:59 EDT
5880 From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
5882 To: ALAN@MIT-MC.ARPA
5883 cc: BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
5884 In-reply-to: Msg of Sat 31 Aug 85 12:36:41 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
5885 Message-ID: <[MIT-MC.ARPA].629753.850831.DEVON>
5887 I was thinking that :SNARF could simply get the start address, etc,
5888 from the croaked DDT, but Alan's suggestion is better.
5889 By the way, how does the system know about sharable pure pages?
5890 If it knows that much why doesn't it know about binaries' filenames?
5892 Date: Sat, 31 Aug 85 12:36:41 EDT
5893 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5895 To: DEVON@MIT-MC.ARPA, BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
5896 In-reply-to: Msg of Sat 31 Aug 85 03:57:02 EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
5897 Message-ID: <[MIT-MC.ARPA].629584.850831.ALAN>
5899 Date: Sat, 31 Aug 85 03:57:02 EDT
5900 From: Devon S. McCullough <DEVON at MC>
5902 I snarfed an emacs from a hactro and tried to do <alt>G
5903 "no start address" I don't know if this is a DDT bug or an ITS bug.
5905 It isn't exactly anybody's bug. The start address of a program is treated
5906 just like the symbol table. It is stored in binary files for the benefit
5907 of people who load, start, and/or debug the program, but it is not kept
5908 anywhere in the job itself. ITS doesn't concern itself with where you
5909 think a job should be restarted.
5911 Now it -is- a little inconvenient that there is no way to go from a random
5912 job you find floating around the system back to its binary to find its
5913 symbols and starting address. So let me float a few suggestions through
5914 the air and see if anybody thinks they are a good idea:
5916 (1) Add a user variable that would contain a starting address. This would
5917 cover the common case that Devon complained about. (Happens to me all
5920 (2) Add four user variables that would contain the filename of the binary
5921 for the this job. This would enable symbols to be found as well as the
5924 (3) Add a user variable that contains the address of a block in the job's
5925 address space, in some extensible format we design later, that contains
5926 all kinds of information. Like a vector of start addresses, filenames
5927 of binary files, etc.
5929 (4) Since (3) requires cooperation from the job itself, but (1) covers the
5930 most common case, we could do both. One user variable containing a
5931 start address and one containing the address of a block of information
5932 (or zero if the job doesn't have one). Note that these are both 18 bit
5933 quantities, so this really only adds an extra word to every set of job
5936 A problem with (3) and (4) is that the new info-block user variable seems
5937 somehow redundant with the existing use of the left half of .40ADDR. The
5938 16.-word block addressed by LH(.40ADDR) is currently only used for
5939 temporary hacking by a job's superior; perhaps there is some way to combine
5940 the two? Perhaps one of the words addressed by RH(.40ADDR) can be the
5941 info-block pointer if the job sets some bit in .OPTION?
5943 I guess I'm in favor of at least (1) if not some variant of (4).
5945 Date: Mon, 19 Aug 85 02:50:42 EDT
5946 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
5947 Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
5948 To: ALAN@MIT-MC.ARPA
5949 cc: BUG-ITS@MIT-MC.ARPA
5950 Message-ID: <[MIT-MC.ARPA].617433.850819.GSB>
5952 Date: Sat, 17 Aug 85 22:30:43 EDT
5953 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5955 Date: Fri, 16 Aug 85 17:06:59 EDT
5956 From: Glenn S. Burke <GSB at MC>
5958 I take it this was what you found printed on the system console?
5960 Yes. I had received a 'toplevel interrupt, tree detached' message.
5961 My hactrn was not stopped however.
5963 Date: Sat, 17 Aug 85 22:30:43 EDT
5964 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5965 Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
5967 cc: BUG-ITS@MIT-MC.ARPA
5968 In-reply-to: Msg of Fri 16 Aug 85 17:06:59 EDT from Glenn S. Burke <GSB at MIT-MC.ARPA>
5969 Message-ID: <[MIT-MC.ARPA].616540.850817.ALAN>
5971 Date: Fri, 16 Aug 85 17:06:59 EDT
5972 From: Glenn S. Burke <GSB at MC>
5973 Re: "dialup line disconnected, detached job #75, usr:gsb hactrn"
5975 I take it this was what you found printed on the system console?
5977 huh? If it was disconnected why did i not have to request further service
5978 from the ROLM feature?
5980 That's pretty wierd all right. ITS should never do that unless you are on
5981 a tty line with %TYMDM set, and only T01 and T03 through T17 have that set in
5982 the current ITS. That bit -used- to be set for the Rolm lines, but that is
5983 no longer the case because MC wasn't finding out about hangups. Perhaps
5984 there is something more fundamentally wrong with the hangup detection code?
5986 Date: Fri, 16 Aug 85 17:06:59 EDT
5987 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
5988 Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
5989 To: BUG-ITS@MIT-MC.ARPA
5990 Message-ID: <[MIT-MC.ARPA].615285.850816.GSB>
5992 huh? If it was disconnected why did i not have to request further service
5993 from the ROLM feature?
5995 Date: Fri, 16 Aug 85 12:34:08 EDT
5996 From: Alan Bawden <ALAN@MIT-MC.ARPA>
5999 cc: BUG-ITS@MIT-MC.ARPA
6000 In-reply-to: Msg of Mon 12 Aug 85 21:43:31 EDT from Gail Zacharias <GZ at MIT-MC.ARPA>
6001 Message-ID: <[MIT-MC.ARPA].614889.850816.ALAN>
6003 Date: Mon, 12 Aug 85 21:43:31 EDT
6004 From: Gail Zacharias <GZ at MIT-MC.ARPA>
6005 If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ
6008 SOPEN parsed the string as "DSK:GZ;GZ >" since the trailing space fooled it
6009 into thinking that OMAIL was supposed to be another first filename. I
6010 fixed this problem in the source, I'll test it some time soon. (I also
6011 documented the fact that SOPEN defaults the device to "DSK" the second
6012 filename to ">" and the sname to the job's current sname.)
6014 Date: Tue, 13 Aug 85 12:33:18 EDT
6015 From: Ed Schwalenberg <ED@MIT-MC.ARPA>
6017 To: BUG-ITS@MIT-MC.ARPA
6018 Message-ID: <[MIT-MC.ARPA].610759.850813.ED>
6020 MC's TTY13 dialup is in a state where it recognizes carrier-detect and ^Z to
6021 mean "create a PWORD", but no typeout gets to the output buffer (according to
6022 OS), much less to the terminal. Gunning down the PWORD doesn't even produce
6023 a console free message.
6025 Date: Tue, 13 Aug 85 06:28:39 EDT
6026 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6027 Subject: "TTY msg from <SITE>" should read "TTY msg from <user>@<site>"
6028 To: DEVON@MIT-MC.ARPA
6029 cc: BUG-ITS@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA, bandy@LLL-CRG.ARPA
6030 In-reply-to: Msg of Mon 12 Aug 85 23:33:11 EDT from Devon S. McCullough <DEVON at MIT-MC.ARPA>
6031 Message-ID: <[MIT-MC.ARPA].610343.850813.CSTACY>
6034 Date: Mon, 12 Aug 85 23:33:11 EDT
6035 From: Devon S. McCullough <DEVON at MIT-MC.ARPA>
6036 To: BUG-ITS at MIT-MC.ARPA
6037 Re: "TTY msg from <SITE>" should read "TTY msg from <user>@<site>"
6039 TTY msg from LLL-CRG.ARPA:
6040 bandy@lll-crg <- this is for mc's broken mailer
6041 ya see, mc is throwing away the data in the "send from". i don't
6042 throw away the data. mc is the only site on teh whole internet
6043 that supports sends that throws away that return-path data.
6045 so bitch at the smtp/sender maintainers there...
6048 This discussion belongs on BUG-MAIL; please edit BUG-ITS from the
6049 distribution of further messages (if any).
6051 I am surprised that there are still people at this time who are
6052 confused about the difference between a return path and a From
6053 field. The return path information given in the SMTP "SEND FROM"
6054 command is not equivalent to the "From" field in a message header.
6055 The return path is located on the ENVELOPE and the From field is
6056 located in the header portion of the mail DATA. RFC810 specifies:
6057 "The SEND command requires that the mail data be delivered to the
6058 user's terminal." (Note that although an SMTP module may add a
6059 field called Return-path in the header of a message it processes,
6060 this feature is a transmission relay trace intended for debugging.)
6061 The message recipient is not supposed to reply to the return path,
6062 which is not really intended for humans; rather, the return path is
6063 for use by SMTPs to generate error receipts. If other systems are
6064 using the return path in place of a header, then they are buggy.
6066 It might be a feature for MC's SMTP to retain the return path for
6067 the user, but if the message did not have a header it would still
6068 be buggy; personally, I think adding the return path to incoming
6069 sends clutters them up and wastes the reader's time. This is why
6070 most people's mail reading programs prune any return path fields
6071 in the header from the message display.
6073 It is definitely LLL-CRG which is violating protocol here.
6077 PS. Early this year I reported this missing header bug to the TOPS-20
6078 mail system maintainers (then on SU-SCORE). Their response was
6079 that they should be putting headers on their outgoing sends, and
6080 that their system was broken. I believe they fixed the bug, but
6081 I have since noticed that many TOPS-20 sites did not pick up this
6082 fix and have some old buggy SEND command. Apparently Unix is
6083 distrbuted with this bug too. Maybe this explains your perception
6084 about MC being the only site which "throws away" the data.
6086 Date: Mon, 12 Aug 85 23:33:11 EDT
6087 From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
6088 Subject: "TTY msg from <SITE>" should read "TTY msg from <user>@<site>"
6089 To: BUG-ITS@MIT-MC.ARPA
6090 Message-ID: <[MIT-MC.ARPA].610043.850812.DEVON>
6092 TTY msg from LLL-CRG.ARPA:
6093 bandy@lll-crg <- this is for mc's broken mailer
6095 you said it. old its. there isn't anything more silly sometimes than its.
6097 it's not what everyone else does.
6099 that send saying it's my fault went to me. tee hee
6101 TTY msg from LLL-CRG.ARPA:
6102 bandy@lll-crg <- this was generated by hand
6104 it's mc that's throwing away data. sample conversation:
6106 send from:<bandy@lll-crg>
6107 rcpt to:<devon@mit-mc>
6113 ya see, mc is throwing away the data in the "send from". i don't
6114 throw away the data. mc is the only site on teh whole internet
6115 that supports sends that throws away that return-path data.
6117 so bitch at the smtp/sender maintainers there...
6120 Date: Mon, 12 Aug 85 21:43:31 EDT
6121 From: Gail Zacharias <GZ@MIT-MC.ARPA>
6123 To: BUG-ITS@MIT-MC.ARPA
6124 Message-ID: <[MIT-MC.ARPA].609927.850812.GZ>
6126 If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ REMIND
6129 Date: Wed, 7 Aug 85 16:30:56 EDT
6130 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
6131 Subject: AI net connection loses
6132 To: ALAN@MIT-MC.ARPA
6133 cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
6134 In-reply-to: Msg of Tue 6 Aug 85 08:38:46 EDT from Alan Bawden <ALAN at MIT-MC.ARPA>
6135 Message-ID: <[MIT-MC.ARPA].604169.850807.GUMBY>
6137 Date: Tue, 6 Aug 85 08:38:46 EDT
6138 From: Alan Bawden <ALAN>
6140 Date: Tue, 6 Aug 85 06:51:19 EDT
6141 From: David Vinayak Wallace <GUMBY>
6142 Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?
6144 You are totally confused. When the hardware breaks, what do you expect the
6145 software to do? (It doesn't look to me like the problem is specific to AI
6146 anyway, it looks more like subnet 6 is broken somehow.)
6148 It wasn't clear to me from her message what had lost. And anyway,
6149 frequently when the hardware gets wedged resetting it causes it to
6150 start working again. From her description of the symptoms I guessed
6151 that perhaps something like that was happening.
6153 Date: Tue, 6 Aug 85 08:38:46 EDT
6154 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6155 Subject: AI net connection loses
6156 To: GUMBY@MIT-MC.ARPA
6157 cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
6158 In-reply-to: Msg of Tue 6 Aug 85 06:51:19 EDT from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
6159 Message-ID: <[MIT-MC.ARPA].602230.850806.ALAN>
6161 Date: Tue, 6 Aug 85 06:51:19 EDT
6162 From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
6163 Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?
6165 You are totally confused. When the hardware breaks, what do you expect the
6166 software to do? (It doesn't look to me like the problem is specific to AI
6167 anyway, it looks more like subnet 6 is broken somehow.)
6169 Date: Tue, 6 Aug 85 06:51:19 EDT
6170 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
6171 Subject: AI net connection loses
6172 To: BUG-ITS@MIT-MC.ARPA
6173 cc: CENT@MIT-MC.ARPA
6174 In-reply-to: Msg of Tue 6 Aug 85 05:04:47 EDT from Pandora B. Berman <CENT at MIT-MC.ARPA>
6175 Message-ID: <[MIT-MC.ARPA].602162.850806.GUMBY>
6177 Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?
6179 Date: Tue, 6 Aug 85 05:04:47 EDT
6180 From: Pandora B. Berman <CENT@MIT-MC.ARPA>
6181 Subject: AI net connection loses
6182 To: BUG-HARDWARE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
6183 Message-ID: <[MIT-MC.ARPA].602119.850806.CENT>
6185 this morning i was using MC on my terminal. around 04:30 or so response
6186 got very slow, then a few minutes ceased altogether. AI had lost its
6187 net connection again, so i couldn't talk to MC, OZ, or anything else.
6188 someone please fix -- i can't work well with no terminal.
6190 Date: Mon, 5 Aug 85 13:43:26 EDT
6191 From: J. Noel Chiappa <JNC@MIT-MC.ARPA>
6192 Subject: Grumble, Don't-Reap is no sticky
6193 To: BUG-ITS@MIT-MC.ARPA
6195 Message-ID: <[MIT-MC.ARPA].601108.850805.JNC>
6197 I set the 'don't reap' bit on certain mailing list
6198 address list files (e.g. for MIT-IP-PEOPLE), since they don't
6199 get modified a lot and would otherwise have the potential
6200 to go offline (e.g. if the Trident controller breaks).
6201 However, if you modify the file and write it back out
6202 the 'don't reap' bit gets cleared! This is a lose...
6206 Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 31 Jul 85 12:46:01 EDT
6207 Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286540; Wed 31-Jul-85 12:44:08-EDT
6208 Date: Wed, 31 Jul 85 12:45 EDT
6209 From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
6210 Subject: It's definite - TOPS-20 loses!
6211 To: Ken Harrenstien <KLH@SRI-NIC.ARPA>, bug-its@MIT-MC.ARPA
6212 In-Reply-To: The message of 28 Jul 85 07:57-EDT from Ken Harrenstien <KLH@SRI-NIC.ARPA>
6213 Message-ID: <850731124518.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
6215 Date: Sun 28 Jul 85 04:57:33-PDT
6216 From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
6218 I was able to log both ends of a telnet connection (using TOPS-20 TN here,
6219 and the ITS datagram logger on MC) and captured an instance of the lossage.
6220 MC is sending a repacketized segment which TOPS-20 incorrectly treats as
6221 additional data. That is, MC's TCP sends off three separate segments, and
6222 then when no ACK is received it decides to retransmit, but is clever and
6223 lumps all the data together into a single segment which it then retransmits.
6224 This new segment has the proper sequence number (same as seq # of the
6225 original 1st segment). The data in this segment is exactly that data
6226 which is duplicated in TN's log file. The only possible explanation is
6227 that the TOPS-20 monitor's TCP code has a long-standing bug in it.
6229 It now occurs to me that I have seen this before when TN'ing to a VAX
6230 4.2BSD system. I always blamed the BSD code for this, and other people
6231 claimed this was due to a bug in 4.2 server telnet, but somehow it never
6232 seemed to go away. Looks as if this was actually a TOPS-20 bug!
6234 I will pursue this with the appropriate people.
6236 Many too many implementations have the "Doesn't correctly handle
6237 overlapping segments" bug. The trickiest one is receiving a segment
6238 some of whose data has already been acknowledged and some whose is new.
6242 Date: Wed, 31 Jul 85 04:20:51 EDT
6243 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6244 Subject: response to old bug report of mine: TS3TTY absolved
6245 To: BUG-ITS@MIT-MC.ARPA
6246 Message-ID: <[MIT-MC.ARPA].594867.850731.CSTACY>
6248 Some time back I had reported a problem where when I first connected
6249 to MC, the first few characters of each line appeared to be garbage.
6250 This only happenned on dialup lines and would persist until I set the
6251 terminal type. It really looked like ITS had initialized my TTY to
6252 some wrong type -- the illegible graphics symbols appearing on my AAA
6253 screen were likely-looiking control codes or padding. I didn't want
6254 to believe that the TTY code was broken, and some other people
6255 asserted that my problem was not possibly the fault of ITS.
6256 Well, the other day I mentioned to my roomate that I was going to go
6257 take a look at TS3TTY and convince myself it could not possibly be
6258 broken. He responded by pouring over the AAA terminal documentation
6259 and frobbing the terminal, and finally located the real culprit.
6260 Apparently the AAA has this feature (which we had enabled) where you
6261 can turn some bit on if you desire the first few characters of each
6262 line to be trashed for you.
6264 So, this message is just a response for the record about that old bug
6265 report I filed. The ITS TTY code was *not* at fault.
6267 Received: from SRI-NIC.ARPA by MIT-MC.ARPA 28 Jul 85 07:58:37 EDT
6268 Date: Sun 28 Jul 85 04:57:33-PDT
6269 From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
6270 Subject: It's definite - TOPS-20 loses!
6271 To: bug-its@MIT-MC.ARPA
6272 cc: klh@SRI-NIC.ARPA
6274 I was able to log both ends of a telnet connection (using TOPS-20 TN here,
6275 and the ITS datagram logger on MC) and captured an instance of the lossage.
6276 MC is sending a repacketized segment which TOPS-20 incorrectly treats as
6277 additional data. That is, MC's TCP sends off three separate segments, and
6278 then when no ACK is received it decides to retransmit, but is clever and
6279 lumps all the data together into a single segment which it then retransmits.
6280 This new segment has the proper sequence number (same as seq # of the
6281 original 1st segment). The data in this segment is exactly that data
6282 which is duplicated in TN's log file. The only possible explanation is
6283 that the TOPS-20 monitor's TCP code has a long-standing bug in it.
6285 It now occurs to me that I have seen this before when TN'ing to a VAX
6286 4.2BSD system. I always blamed the BSD code for this, and other people
6287 claimed this was due to a bug in 4.2 server telnet, but somehow it never
6288 seemed to go away. Looks as if this was actually a TOPS-20 bug!
6290 I will pursue this with the appropriate people.
6293 Date: Sun, 28 Jul 85 07:07:01 EDT
6294 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
6295 Subject: RMAIL display problem - yet more data
6296 To: BUG-ITS@MIT-MC.ARPA, GSB@MIT-MC.ARPA
6297 Message-ID: <[MIT-MC.ARPA].591010.850728.KLH>
6299 I was finally able to provoke this bug simply with DDT ^R typeout of
6300 a file -- conclusive proof that the problem does not lie with TECO,
6301 EMACS, or RMAIL. It is not reproducible however (doing another typeout
6302 will not lose in the same place, if at all).
6304 Date: Sun, 28 Jul 85 06:58:50 EDT
6305 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
6306 Subject: RMAIL display problem - yet more data
6307 To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
6308 BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
6309 Message-ID: <[MIT-MC.ARPA].590992.850728.KLH>
6311 Well, with considerable pain I was able to cause an example of
6312 this lossage while keeping a TCP datagram log. However, the log
6313 doesn't show what I expected; I was looking for the stretch of
6314 duplicated text that I observed, and couldn't find it. There are
6315 some retransmissions but they are all correct.
6317 Until GSB commented on the fact that the extra stuff seemed to be
6318 a duplicate of previous stuff, I hadn't noticed this attribute, but
6319 since then I've checked every instance and this appears to be always
6320 true. Something somewhere is being retransmitted or re-used.
6322 Since this happens with both CTN (CRTSTY SUPDUP) and TOPS-20 TN,
6323 it isn't a TOPS-20 user-program problem. Since the outgoing datagram log on
6324 MC shows no problems, the obvious deduction is that this looks like a
6325 TOPS-20 monitor problem. As it happens, the duplicated stuff does appear
6326 to correspond to a re-packetized TCP segment. More tests will be
6327 necessary to confirm this, however.
6329 This also implies that GSB's problem is actually something different
6330 from this one. Since he mentioned it happening with PEEK, I think
6331 we should confine further discussion to BUG-ITS and leave out
6332 BUG-RMAIL,TECO,EMACS unless more information turns up.
6334 Date: Fri, 26 Jul 85 22:10:20 EDT
6335 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6336 Subject: 7LP: and 7LR:
6337 To: INFO-ITS@MIT-MC.ARPA
6338 Message-ID: <[MIT-MC.ARPA].589842.850726.ALAN>
6340 Remember the 7LP: device I advertised in this spot last winter? (I sends
6341 output to the LN01 printer on the 7th floor.) Well, I have just installed a
6342 7LR: device for sending output to the new laserwriter (also on the 7th
6345 While I was at it I gave both devices a new feature. They now support
6346 deletion so you can delete items from the queue. For example, if 7LP^F
6347 shows you the following:
6349 7th floor ln01 is ready and printing
6350 Time Owner Job Files Size
6351 *21:55 alan 905 7LP: BAWDEN; B 249 49481
6353 The most recent job printed was:
6354 21:21 alan 7LP: BAWDEN; .FILE. (DIR)
6356 then you can delete job 905 by doing either ^O 7LP:905 or ^O 7LP:ALAN. In
6357 the later case all entries owned by ALAN are deleted. The second filename
6358 and directory are ignored.
6360 Date: Thu, 25 Jul 85 16:39:03 EDT
6361 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6363 To: TY@MIT-MC.ARPA, MYK@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA,
6365 Message-ID: <[MIT-MC.ARPA].587801.850725.ALAN>
6367 The parity errors MC was getting today seem to be closely correlated to
6368 when the tape drive was being used. I don't know when DEC is coming back
6369 to fix the first memory box, but perhaps some diagnostics should be run to
6370 see if the tape drive and it's DF10 are functioning properly.
6372 Date: Wed, 24 Jul 85 18:06:43 EDT
6373 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6374 Subject: I thought we were more carefull than this...
6375 To: BUG-ITS@MIT-MC.ARPA
6376 cc: DANIEL@MIT-MC.ARPA
6377 Message-ID: <[MIT-MC.ARPA].586331.850724.ALAN>
6379 MC was unusable for most of today because DEC brought up the machine with
6380 the T-300's write-protected. ITS should really say something more explicit
6381 when this happens than "T300 ERR ... STATUS = 1 ...".
6383 Date: Tue, 23 Jul 85 22:37:28 EDT
6384 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
6385 Subject: re: RMAIL display problem
6387 cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
6388 BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
6389 Message-ID: <[MIT-MC.ARPA].586008.850723.GSB>
6391 I cam make it happen with peek on a 60 high 118 wide screen, just like i
6392 can with rmail. looks like the cursor positioning goes bonkers as a
6393 function of me typing at it.
6395 Date: Mon, 22 Jul 85 18:06:15 EDT
6396 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
6397 Subject: re: RMAIL display problem -- you'll like this
6399 cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
6400 BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
6401 Message-ID: <[MIT-MC.ARPA].584681.850722.GSB>
6403 right here in the privacy of my own office, i can reproduce this, freeze
6404 the screen, and get a hardcopy of the lossage. Isn't VMS wonderful?
6406 Date: Mon, 22 Jul 85 13:30:54 EDT
6407 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
6408 Subject: RMAIL display problem
6410 cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
6411 BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
6412 Message-ID: <[MIT-MC.ARPA].584298.850722.KLH>
6414 Some additional data which supports the theory that a user-program or
6415 ITS TTY bug may be involved:
6417 Date: Thu, 18 Jul 85 22:40:40 EDT
6418 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
6419 Subject: RMAIL display problem
6421 Message-ID: <[MIT-MC.ARPA].581085.850718.GSB>
6423 All the times i have seen such an error i have been able to find duplicated
6424 text on the screen and the supposition was that it was a duplicated
6425 tcp packet or something like that. I have seen this both internetting
6426 from ru-net to here (from a 20) and i believe just within rutgers
6427 (tops-20 -> tops-20 just on ru-net).
6428 ----------------------
6429 Date: Fri, 19 Jul 85 23:45:04 EDT
6430 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
6431 Subject: tty lossage
6433 Message-ID: <[MIT-MC.ARPA].582348.850719.GSB>
6435 well maybe i should take back what i said last night.
6436 I'm coming from a microvax vaxstation running a vt100 emulator window,
6437 running decnet to a 750 (corwin) from whence i'm doing chaosnet supdup
6438 to mc. The window size is 94 wide by 55 high [i TOLD it 96 wide at this
6439 end, you know how these things are...] anyway, i have a two screen long
6440 (at this screen size) message, and if i have it redisplay the first and
6441 get a space (in rmail, go to next screen) before it finishes, it invariably
6444 anyway, there ain't no tcp in THIS network path.
6446 Received: from MIT-XX.ARPA by MIT-MC.ARPA 19 Jul 85 11:41:37 EDT
6447 Date: Fri 19 Jul 85 11:43:49-EDT
6448 From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
6449 Subject: Re: memory woes
6450 To: ALAN@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA
6451 cc: BUG-ITS@MIT-MC.ARPA, JNC@MIT-XX.ARPA
6452 In-Reply-To: Message from "Alan Bawden <ALAN@MIT-MC.ARPA>" of Fri 19 Jul 85 08:34:10-EDT
6454 Ty was having parity error in some module of one sector. He
6455 replaced that module and got the exact same error in the exact same
6456 place (he said). He thought that was suspicious, and decided to
6457 swap the parity controllers to see if the problem moved with the
6458 controller. It didn't.
6459 Ask him for more details.
6462 Date: Fri, 19 Jul 85 08:33:23 EDT
6463 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6464 To: CSTACY@MIT-MC.ARPA
6465 cc: BUG-ITS@MIT-MC.ARPA
6466 In-reply-to: Msg of Thu 18 Jul 85 19:03:04 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
6467 Message-ID: <[MIT-MC.ARPA].581459.850719.ALAN>
6469 Date: Thu, 18 Jul 85 19:03:04 EDT
6470 From: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
6471 Why does ITS think it has been up all year?
6473 I guess somebody told MC it was 1984 when they first brought it up.
6475 Date: Fri, 19 Jul 85 08:31:13 EDT
6476 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6477 Subject: memory woes
6478 To: CSTACY@MIT-MC.ARPA
6479 cc: BUG-ITS@MIT-MC.ARPA
6480 In-reply-to: Msg of Fri 19 Jul 85 07:00:43 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
6481 Message-ID: <[MIT-MC.ARPA].581458.850719.ALAN>
6483 Date: Fri, 19 Jul 85 07:00:43 EDT
6484 From: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
6485 unusable, so I deselected sector 1 where they were happenning
6486 (bank 3). Then they appeared to move to sector 0. I deselected
6489 I presume you remembered to turn interleaving off when you deselected
6492 If things seem to work well for a while today,
6493 someone might want to turn sector 1 back on and see if the
6494 errors move around. We are down alot of memory at this point.
6495 I heard something about an Ampex parity detection module being
6496 replaced when DEC was frobbing the machine to replace a core
6497 stack in one of their memories.
6499 This wasn't DEC, it was TY I believe. I think JNC can tell you about it as
6502 Date: Fri, 19 Jul 85 07:00:43 EDT
6503 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6504 Subject: memory woes
6505 To: BUG-ITS@MIT-MC.ARPA
6506 Message-ID: <[MIT-MC.ARPA].581432.850719.CSTACY>
6508 The Ampex was getting enough parity errors to render the system
6509 unusable, so I deselected sector 1 where they were happenning
6510 (bank 3). Then they appeared to move to sector 0. I deselected
6511 sector 0 too. If things seem to work well for a while today,
6512 someone might want to turn sector 1 back on and see if the
6513 errors move around. We are down alot of memory at this point.
6514 I heard something about an Ampex parity detection module being
6515 replaced when DEC was frobbing the machine to replace a core
6516 stack in one of their memories.
6517 What's the scoop latest on the hardware?
6519 Date: Thu, 18 Jul 85 19:03:04 EDT
6520 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6521 To: BUG-ITS@MIT-MC.ARPA
6522 Message-ID: <[MIT-MC.ARPA].580878.850718.CSTACY>
6524 Why does ITS think it has been up all year?
6526 Date: Thu, 18 Jul 85 05:55:23 EDT
6527 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
6528 Subject: RMAIL display problem
6529 To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
6530 BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
6531 Message-ID: <[MIT-MC.ARPA].580138.850718.KLH>
6533 I'm not sure where the fault for this one might be, hence the shotgun
6536 In RMAIL, when using "space" to step through successive screenfuls
6537 of a long message, sometimes output fails to stop at the mode line;
6538 it continues for several more lines and runs right off the bottom of
6539 the screen, causing the terminal to either scroll or wrap up to
6540 the top (depending on one's terminal). The screen is then permanently
6541 messed up until a complete redisplay is forced with ^L.
6543 This happens for me when connected to MC either via SUPDUP (ie as a
6544 software TTY) or via TELNET with a :TCTYP DM2500 declaration. At
6545 first I thought it might be a CRTSTY/SUPDUP problem, but my TELNET
6546 experiments have convinced me that it really is MC's fault.
6547 However, I haven't been able to find a foolproof way of reproducing
6548 the lossage. All I can say is that in the course of reading through
6549 several SF-LOVERS digests on a 24x79 screen, this bug almost always
6550 crops up someplace, sometimes twice or thrice in a row. I type:
6551 N E ^K ^X r ; to invoke RMAIL
6552 <spaces as needed to read msg> d ; for each message
6554 This is probably a TECO bug of some variety, but there's an off
6555 chance it might be an ITS TTY handling bug. It's even possible
6556 that some EMACS code is screwing up the redisplay. This has happened
6557 for quite a while (several months). I hope someone else has a
6558 notion of what to look for at this point. If necessary, I could
6559 try again to save a reproducible instance of this, although it is
6560 a rather painful task.
6562 Date: Fri, 12 Jul 85 09:13:59 EDT
6563 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6564 Subject: crtsty lossage.
6565 To: BUG-CRTSTY@MIT-MC.ARPA
6566 cc: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
6567 In-reply-to: Msg of Fri 12 Jul 85 02:18:26 EDT from Christopher C. Stacy <CSTACY at MIT-MC.ARPA>
6568 Message-ID: <[MIT-MC.ARPA].573277.850712.ALAN>
6570 I renamed SYSBIN;CRTSTY OBIN => CRTSTY BIN => CRTSTY XBIN. I presume the
6571 behavior we were observing was something that KLH introduced when he
6572 assembled CRTSTY yesterday.
6574 BTW, I notice there is a link from TS NCRTSTY to SYSBIN;CRTSTY NBIN, which
6575 despite its name is a year older than any other version. Is there a reason
6578 Date: Fri, 12 Jul 85 02:18:26 EDT
6579 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6580 Subject: crtsty lossage?
6581 To: BUG-CRTSTY@MIT-MC.ARPA
6582 cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA
6583 Message-ID: <[MIT-MC.ARPA].572965.850712.CSTACY>
6585 I just dumped a dead CRTSTY into CRASH;CRTSTY VT100.
6586 This was EAK CRTSTY,
6587 (.VALUE;IOCH7;) 70110>>SKIPGE @413 130624/ 4,,27000
6589 I guess it got a fatal interrupt, but I don't know
6590 anything about this program. There were n of these
6591 guys lying around, all stopped in the same way.
6593 Date: Fri, 12 Jul 85 00:56:15 EDT
6594 From: Pandora B. Berman <CENT@MIT-MC.ARPA>
6595 Subject: crtsty lossage?
6596 To: BUG-ITS@MIT-MC.ARPA
6597 Message-ID: <[MIT-MC.ARPA].572909.850712.CENT>
6599 something's wrong. over the past several hours i have found half a dozen
6600 CRTSTYs disowned with .VALUE 200. also several ___###s disowned. i can only
6601 tell from what i see in PEEK; someone who knows more should check this.
6603 Received: from MIT-XX.ARPA by MIT-MC.ARPA.ARPA; 10 Jul 85 23:20:03 EDT
6604 Date: Wed 10 Jul 85 23:21:13-EDT
6605 From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
6606 Subject: Re: level2 bughalt
6607 To: DANIEL@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
6609 In-Reply-To: Message from "Daniel Weise <DANIEL@MIT-MC.ARPA>" of Sun 7 Jul 85 17:07:05-EDT
6611 Well, the TARAKA DMPCPY business is a daemon copying the dump
6612 from the swapping area (where DDTDSK put it) into the real file system.
6613 The file seems to have gone into the directory '.' rather than 'CRASH';
6614 '.' is the default directory used by DDTDSK.
6618 Date: Mon, 8 Jul 85 14:54:11 EDT
6619 From: Jonathan D. Taft <TAFT@MIT-MC.ARPA>
6620 To: BUG-ITS@MIT-MC.ARPA
6621 Message-ID: <[MIT-MC.ARPA].567927.850708.TAFT>
6623 DSK:UNIT 1 LOSING.RH CONI BITS= 1,,157236
6625 Dumped to CRASH;UNIT1 LOSING
6628 Date: Sun, 7 Jul 85 17:05:05 EDT
6629 From: Daniel Weise <DANIEL@MIT-MC.ARPA>
6630 Subject: level2 bughalt
6631 To: BUG-ITS@MIT-MC.ARPA
6632 Message-ID: <[MIT-MC.ARPA].566858.850707.DANIEL>
6634 MC wedged itself again this afternoon. I took crash
6635 dump to CRASH LEVEL2 and warm booted. But during
6636 warm boot it printed something like
6637 TARAKA DMPCPY . CRASH LEVEL2 DELRNM
6638 (MC's vt52 is missing so I am typing this in from
6641 When I looked for crash;crash level2 the file
6642 wasn't there. What did I do wrong?
6646 Date: Fri, 5 Jul 85 00:41:26 EDT
6647 From: David A. Moon <MOON@MIT-MC.ARPA>
6648 Subject: Re: IMP down detection
6650 cc: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
6651 Message-ID: <[MIT-MC.ARPA].565142.850705.MOON>
6653 Date: Mon 24 Jun 85 17:54:25-EDT
6654 From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
6656 I think that it's a known bug with the IMP code that if the
6657 IMP cycles after ITS is up ITS doesn't deal with that correctly.
6659 It used to work. Maybe I broke it when I removed support for NCP protocol
6662 Date: Fri, 5 Jul 85 00:07:06 EDT
6663 From: David A. Moon <MOON@MIT-MC.ARPA>
6665 To: CSTACY@MIT-MC.ARPA
6666 cc: BUG-ITS@MIT-MC.ARPA
6667 Message-ID: <[MIT-MC.ARPA].565121.850705.MOON>
6669 Date: Mon, 1 Jul 85 17:20:31 EDT
6670 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6672 It is probably a bug that ITS refuses all Chaosnet service
6673 when it is being debugged. There is a feature in NETWRK
6674 for doing this in the Chaosnet specific code. SYSDBG is
6675 maybe not quite fine-grain enough? Also, should move
6676 TCPUSW and TCPUP to be near NETUSW, etc.
6678 Yeah, probably it should assume NETUSW is good enough.
6680 Date: Mon, 1 Jul 85 23:53:18 EDT
6681 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
6682 Sender: GSB5@MIT-MC.ARPA
6684 To: BUG-ITS@MIT-MC.ARPA
6685 Message-ID: <[MIT-MC.ARPA].562107.850701.GSB5>
6689 Received: from MIT-XX.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 23:11:38 EDT
6690 Date: Mon 1 Jul 85 23:12:42-EDT
6691 From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
6692 Subject: Re: crashdump
6693 To: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA
6694 cc: BUG-ITS@MIT-MC.ARPA, JNC@MIT-XX.ARPA
6695 In-Reply-To: Message from "Alan Bawden <ALAN@MIT-MC.ARPA>" of Sat 29 Jun 85 05:43:22-EDT
6697 I'm dubious about this being a side effect of DEC playing around.
6698 The exact thing DEC did involved no frobbing with cables at all; all the
6699 did was disable some of the ports the processor was using to reference
6700 memory. (I was supposed to explain all this but forgot).
6701 What they did was notice that we are running the machine in
6702 two way interleave. Exactly why we are doing this is too long to explain
6703 here, and I think Dave Moon did so once already. This being the case,
6704 they decided that we would be less likely to have 'interference' on the
6705 memories if we diabled KBUS2 and KBUS3 (which are after all duplicates of
6706 KBUS0 and KBUS1 in two way interleave). I'm not sure I believe this, but
6707 I do believe that it can't hurt and I didn't feel like arguing with the
6708 DEC guy about it, so I let them do it. (Actually, they disabled the
6709 memory ports to those busses, not the busses.)
6710 However, the DF10 has it's own memory bus and port, and should
6711 not have been affected. It's probably a flaky caused by all the power
6712 cycling in the last week.
6716 Date: Mon, 1 Jul 85 21:00:22 EDT
6717 From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
6718 To: BUG-ITS@MIT-MC.ARPA
6719 Message-ID: <[MIT-MC.ARPA].561917.850701.DEVON>
6721 I snarfed an E job when I already had one (to see what I could see)
6722 and it renamed it E!!!!! well that's okay, but wouldn't E! or E0 have done?
6724 Date: Mon, 1 Jul 85 17:20:31 EDT
6725 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6727 To: BUG-ITS@MIT-MC.ARPA
6728 Message-ID: <[MIT-MC.ARPA].561691.850701.CSTACY>
6730 It is probably a bug that ITS refuses all Chaosnet service
6731 when it is being debugged. There is a feature in NETWRK
6732 for doing this in the Chaosnet specific code. SYSDBG is
6733 maybe not quite fine-grain enough? Also, should move
6734 TCPUSW and TCPUP to be near NETUSW, etc.
6736 Date: Sat, 29 Jun 85 05:41:16 EDT
6737 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6740 cc: BUG-ITS@MIT-MC.ARPA
6741 In-reply-to: Msg of Sat 29 Jun 85 02:39:48 EDT from Glenn S. Burke <GSB at MIT-MC.ARPA>
6742 Message-ID: <[MIT-MC.ARPA].559587.850629.ALAN>
6744 Date: Sat, 29 Jun 85 02:39:48 EDT
6745 From: Glenn S. Burke <GSB at MIT-MC.ARPA>
6748 The DF10 got a NXM. I suspect this is an artifact of the way DEC
6749 reconfigured the memory last Wednesday. Would we rather have the parity
6750 errors back? Damn machine.
6752 Date: Sat, 29 Jun 85 02:39:48 EDT
6753 From: Glenn S. Burke <GSB@MIT-MC.ARPA>
6754 Sender: GSB5@MIT-MC.ARPA
6756 To: BUG-ITS@MIT-MC.ARPA
6757 Message-ID: <[MIT-MC.ARPA].559506.850629.GSB5>
6761 Date: Wed, 26 Jun 85 22:01:16 EDT
6762 From: Alan Bawden <ALAN@MIT-MC.ARPA>
6763 Subject: MC up again with all 6 disks.
6764 To: TY@MIT-MC.ARPA, Sollins@MIT-XX.ARPA, Finn@MIT-XX.ARPA
6765 cc: BUG-ITS@MIT-MC.ARPA
6766 Message-ID: <[MIT-MC.ARPA].557107.850626.ALAN>
6768 JNC and I swapped the packs in unit 3 and 4 on MC (the rightmost two
6769 T-300's) and the disk problems we were experiencing vanished. Perhaps
6770 there is some marginal interaction between drives and packs formatted with
6771 different alignments? If so, I guess there is some hope that things will
6772 clear up after duplicating those packs tomorrow.
6774 BUG-ITS: For the record: Earlier today JNC and TY brought MC up with
6775 -none- of the T-300's because they believed them all to be broken. They
6776 were given this impression when UCOP got an error copying some user
6777 directories. In fact, it has been true for a long time that there are bad
6778 blocks amoung the directories on those packs, but since we don't
6779 really need those extra copies of the directories this is OK. UCOP copies
6780 the MFD -first-, and if it gets that far, that is good enough!
6782 Date: Tue, 25 Jun 85 01:50:24 EDT
6783 From: David A. Moon <MOON@MIT-MC.ARPA>
6784 Sender: CENT@MIT-MC.ARPA
6785 Subject: Addition to mailing list
6786 To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
6787 cc: BUG-ITS@MIT-MC.ARPA, ks-its@MIT-AI.ARPA
6788 Message-ID: <[MIT-MC.ARPA].554803.850625.CENT>
6790 Date: 23 Jun 85 20:11 +0100
6791 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
6793 Everybody here is waiting for the system to run, all of the hackers in
6794 Stockholm that have heard of ITS is lyric.
6796 I have started the work on planing howto actualy change the KA hardware,
6797 i want to have the posibility to run as much of the DEC diagnostics as
6798 possible. So some type of switch-selectable aproach is prefered, but it
6801 In a month or so we shall try to have the two KI-10 Cpu:s running
6802 SMP with T10 7.02. We plan to use this system to assemble the ITS code.
6805 ( Are you sure you can deal with that volume of mail? I don't think
6806 anyone will mind your being on them if you don't mind.
6809 Pls try to add: ITS_bugs%QZCOM.MAILNET@MIT-MULTICS.ARPA
6810 in both ITS bugs and ITS on ks20.
6814 Will report as soon there is any sucsess.
6816 We eagerly await your report. The box of tapes, processor prints, and
6817 documentation is sitting right next to me, thanks to a lot of work by
6820 Received: from MIT-XX.ARPA by MIT-MC.ARPA 24 Jun 85 17:55:25 EST
6821 Date: Mon 24 Jun 85 17:54:25-EDT
6822 From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
6823 Subject: Re: IMP down detection
6824 To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
6826 In-Reply-To: Message from "Christopher C. Stacy <CSTACY@MIT-MC.ARPA>" of Mon 24 Jun 85 16:10:43-EDT
6828 I think that it's a known bug with the IMP code that if the
6829 IMP cycles after ITS is up ITS doesn't deal with that correctly.
6832 Date: Mon, 24 Jun 85 16:10:35 EDT
6833 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
6834 Subject: IMP down detection
6835 To: BUG-ITS@MIT-MC.ARPA
6836 Message-ID: <[MIT-MC.ARPA].554168.850624.CSTACY>
6838 At some point today, ITS decided the IMP was down.
6839 It never noticed it coming back up, and thought it was
6840 waiting for the ready line to flap. I ran LOCK and
6841 it reset everything.
6843 Received: from MIT-XX.ARPA by MIT-MC.ARPA 21 Jun 85 15:05:13 EST
6844 Date: Fri 21 Jun 85 15:03:48-EDT
6845 From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
6846 Subject: MC disk flakoes
6847 To: bug-its@MIT-MC.ARPA
6850 John Holden came and looked at the Tridents and pronounced them
6851 all OK. Two needed touch ups to the alignment, but nothing major. He
6852 says that it was probably the cables, which are known to be flaky. Since
6853 he had to remove the cables to run the exerciser, he thinks that he
6854 may have frobbed them in the right way to make the problems go away.
6855 Things do seem to be working a bit better. We'll see.
6858 Date: Thu, 20 Jun 85 21:11:48 EDT
6859 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
6860 Subject: more re: mc was wedged this afternoon.
6861 To: DANIEL@MIT-MC.ARPA
6862 cc: BUG-ITS@MIT-MC.ARPA
6863 In-reply-to: Msg of Thu 20 Jun 85 12:12:00 EDT from Daniel Weise <DANIEL at MIT-MC.ARPA>
6864 Message-ID: <[MIT-MC.ARPA].550546.850620.GUMBY>
6866 Date: Thu, 20 Jun 85 12:12:00 EDT
6867 From: Daniel Weise <DANIEL at MIT-MC.ARPA>
6869 Claimed no net ports when only 4 people were logged in.
6870 Console only echoed my typein but did nothin
6871 wit it. Tried warm booting. THat failed. Took
6872 crash dump to CRASH SAME and cold booted.
6874 More bits: trying to open a STY gave DEVICE FULL, which is weird.
6875 I've seen the same thing when MC couldn't get to its tridents.
6877 Date: Thu, 20 Jun 85 12:12:00 EDT
6878 From: Daniel Weise <DANIEL@MIT-MC.ARPA>
6879 Subject: mc was wedged this afternoon.
6880 To: BUG-ITS@MIT-MC.ARPA
6881 Message-ID: <[MIT-MC.ARPA].550424.850620.DANIEL>
6883 Claimed no net ports when only 4 people were logged in.
6884 Console only echoed my typein but did nothin
6885 wit it. Tried warm booting. THat failed. Took
6886 crash dump to CRASH SAME and cold booted.
6890 Date: Sun, 16 Jun 85 20:29:08 EDT
6891 From: Alan Bawden <ALAN@MIT-MC>
6892 Subject: mc needed cold booting this afternoon.
6893 To: DANIEL@MIT-MC, JGA@MIT-MC
6895 Message-ID: <[MIT-MC].544997.850616.ALAN>
6897 Date: Sat, 15 Jun 85 14:05:26 EDT
6898 From: Daniel Weise <DANIEL at MC>
6899 MC was really wedged this afternoon. Every minute it kept typing
6900 system full, 0 pages, 0 qsk channels, etc. No user jobs able to run.
6901 Warm booting didn't help so I took a dump to CRASH FULL and
6902 cold-booted, which seems to have fixed things.
6904 Well, the crash dump shows an ITS that has been up for 5 minutes and is
6905 having trouble initializing the first T-300. So I guess this is the
6906 canonical T-300 controller lossage.
6908 Date: Sat, 15 Jun 1985 12:04 EDT
6910 A little bit more on the recent lossage I mentioned earlier...
6912 I was logged in when RHB got wedged. Running Peek, I could see
6913 that his job and several others were sitting there with a state
6914 of "*logout", whatever that means. Peek could not gun his tree,
6917 A state of "LOGOUT" (the "*" is irrelevant really) means that the job was
6918 already on its way towords going away. (Thats why gunning it didn't do
6919 anything, it was already as gunned as it could get.) Without a crash dump,
6920 or an actual wedged system, I can only guess that this is another symptom
6921 of the T-300 lossage.
6923 Date: Sun, 16 Jun 85 20:26:35 EDT
6924 From: Alan Bawden <ALAN@MIT-MC>
6925 Subject: CHTN lossage
6928 In-reply-to: Msg of Fri 14 Jun 85 18:52:47 EDT from J. Noel Chiappa <JNC at MIT-MC.ARPA>
6929 Message-ID: <[MIT-MC].544988.850616.ALAN>
6931 Date: Fri, 14 Jun 85 18:52:47 EDT
6932 From: J. Noel Chiappa <JNC at MC>
6933 Recently I have been noticing that when XX goes down,
6934 my CHTN hangs and nothing the world seems to get me out, until it
6935 decides to timeout the connection. ANyone know why?
6937 Yeah, I've noticed this too. It's not new, its been happening for years.
6938 Just looking at the code I can't figure out how it can happen. (Note that
6939 this is probably just a bug in CHTN; you take the risk of having bugs like
6940 this when you go into super image input mode...)
6942 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 JUN 85 14:15:18 EDT
6943 Date: Sat, 15 Jun 1985 12:10 EDT
6944 Message-ID: <JGA.12119355938.BABYL@MIT-OZ>
6945 From: JGA%MIT-OZ@MIT-MC.ARPA
6947 Subject: weird wedgitude - part IIa
6949 One more note - a finger of MC from OZ shows the dead HACTRNs
6950 sitting there with " STY not in use" where the ttyloc usually
6951 goes in the finger display.
6953 Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 JUN 85 14:15:17 EDT
6954 Date: Sat, 15 Jun 1985 12:04 EDT
6955 Message-ID: <JGA.12119354914.BABYL@MIT-OZ>
6956 From: JGA%MIT-OZ@MIT-MC.ARPA
6958 Subject: weird wegitude, part II
6960 A little bit more on the recent lossage I mentioned earlier...
6962 I was logged in when RHB got wedged. Running Peek, I could see
6963 that his job and several others were sitting there with a state
6964 of "*logout", whatever that means. Peek could not gun his tree,
6967 There were several different HACTRNs sitting around in this state,
6968 which explains the lack of net ports I guess, as well as whole bunch
6969 of lispm file jobs. I don't know enough about lispm file jobs to tell
6970 whether these were normal or not.
6972 About two minutes later my tty got wedged, and I can't log back in
6973 because of no net ports, so that's why I'm sending this from OZ.
6975 Date: Sat, 15 Jun 85 14:05:26 EDT
6976 From: Daniel Weise <DANIEL@MIT-MC.ARPA>
6977 Subject: mc needed cold booting this afternoon.
6978 To: BUG-ITS@MIT-MC.ARPA
6979 Message-ID: <[MIT-MC.ARPA].543663.850615.DANIEL>
6981 MC was really wedged this afternoon. Every
6982 minute it kept typing system full, 0 pages, 0 qsk channels, etc.
6983 No user jobs able to run. Warm booting didn't help so
6984 I took a dump to CRASH FULL and cold-booted, which seems
6985 to have fixed things.
6989 Date: Fri, 14 Jun 85 18:52:47 EDT
6990 From: J. Noel Chiappa <JNC@MIT-MC.ARPA>
6991 Subject: CHTN lossage
6992 To: BUG-ITS@MIT-MC.ARPA
6994 Message-ID: <[MIT-MC.ARPA].543165.850614.JNC>
6996 Recently I have been noticing that when XX goes down,
6997 my CHTN hangs and nothing the world seems to get me out, until
6998 it decides to timeout the connection. ANyone know why?
7000 Date: Thu, 13 Jun 85 17:25:50 EDT
7001 From: Robert H. Berman <RHB@MIT-MC.ARPA>
7002 Subject: intermittent login probelm
7003 To: JGA@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
7004 Message-ID: <[MIT-MC.ARPA].541730.850613.RHB>
7006 Same thing happened to me today too.
7007 (around 4:30-5:30 PM)
7008 I got about half-way in my login file
7009 and the tterminal hung. tried loggin in several
7010 times in a row with no success. Finally logged in
7011 and everything has been ok since.
7013 Date: Thu, 13 Jun 85 11:23:45 EDT
7014 From: John G. Aspinall <JGA@MIT-MC.ARPA>
7015 Subject: wierd wegitude
7016 To: BUG-ITS@MIT-MC.ARPA
7017 Message-ID: <[MIT-MC.ARPA].541202.850613.JGA>
7019 I'm having an intermittent problem of the terminal getting wedged when I log
7020 in. The symptoms are as follows.
7022 Pword runs ok, and my login file starts executing. At some point, either as
7023 the login file ends, or at a point most of the way through it where I have a
7024 :more query about whether to run babyl or not, almost all response to typed
7025 characters stops. The only characters that cause a response are ctrl-G and
7026 rubout which provoke their usual behaviour.
7028 My login file has not been changed in months. Other people logging in from
7029 the same concentrator (NPLASMA) have not seen the problem. I get the problem
7030 four or five times in a row, then everything is fine again.
7034 Received: from THINK.ARPA by MIT-MC.ARPA 11 Jun 85 16:58:04 EST
7035 Received: by THINK.ARPA with CHAOS id AA28106; Tue, 11 Jun 85 16:52:46 edt
7036 Date: Tuesday, 11 June 1985, 16:54-EDT
7037 From: Guy Steele <gls@THINK.ARPA>
7039 To: KLH@MIT-MC.ARPA, BUG-ITS@MC
7041 In-Reply-To: <[MIT-MC.ARPA].538066.850611.KLH>
7042 Message-Id: <850611165410.6.GLS@ROCK.ARPA>
7047 I simply don't know what to think
7048 Of this late resurrection of STINK,
7049 Once thought lost, at the last,
7050 In the mists of the past
7051 Like its sibling, the famed missing link.
7055 Date: Tue, 11 Jun 85 05:36:46 EDT
7056 From: Ken Harrenstien <KLH@MIT-MC.ARPA>
7058 To: BUG-ITS@MIT-MC.ARPA
7059 Message-ID: <[MIT-MC.ARPA].538066.850611.KLH>
7061 You may find this news hard to believe.
7063 As you may recall, the source for STINK didn't assemble properly,
7064 and had a higher version number than the (presumably working) binary.
7065 The true source, if it ever existed, has been lost in the distant
7066 fires of ITS dump tapes being burned at the stake.
7068 I was thinking about a possible hack which at some point might require
7069 the services of STINK. Never mind what it is. The problem as I saw
7070 it was not the fact that STINK is unique and unsupported, but the
7071 fact that STINK could not be supported without a real source. So
7072 I made a half-hearted attempt to investigate by comparing the (faulty)
7073 result of an assembly with the existing binary, using SRCCOM's /$
7076 Boy, am I glad I put that hack into SRCCOM. The comparison much to
7077 my surprise showed the binaries were virtually identical, except for
7078 one changed label and a couple of missing symbols. It only took a few
7079 minutes to fix those and come up with a source that assembles into
7080 exactly the same thing (modulo .FNAM2) as the old TS STINK!
7082 Anyway, I wrote out this new source as STINK 200, and installed a new
7083 TS STINK. STINK lives again! (phew)
7085 Date: Thu, 6 Jun 85 18:11:40 EST
7086 From: Chris Hanson <CPH@MIT-MC.ARPA>
7087 To: BUG-SYSTEM@MIT-MC.ARPA
7088 Message-ID: <[MIT-MC.ARPA].533331.850606.CPH>
7090 Why do I have to give a password when I supdup over from OZ?
7091 What kind of bullshit is this?
7093 Date: Thu, 30 May 85 15:06:41 EST
7094 From: Alan Bawden <ALAN@MIT-MC.ARPA>
7095 Subject: All network ports in use
7096 To: GUMBY@MIT-MC.ARPA
7097 cc: BUG-ITS@MIT-MC.ARPA
7098 In-reply-to: Msg of Thu 30 May 85 14:25:10 EST from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
7099 Message-ID: <[MIT-MC.ARPA].524704.850530.ALAN>
7101 Date: Thu, 30 May 85 14:25:10 EST
7102 From: David Vinayak Wallace <GUMBY at MC>
7103 Every once in a while I am unable to connect to MC via chaos; I open a
7104 connexion and MC says "All network ports in use." This is repeatable
7105 for about a minute or so, then I get a ddt. loadp shows 11 free net
7108 I fixed a bug that used to cause something like this to happen a while ago.
7109 A new ITS for MC has not been assembled since then.
7111 Date: Thu, 30 May 85 14:25:10 EST
7112 From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
7113 Subject: All network ports in use
7114 To: BUG-ITS@MIT-MC.ARPA
7115 Message-ID: <[MIT-MC.ARPA].524623.850530.GUMBY>
7117 Every once in a while I am unable to connect to MC via chaos; I open a
7118 connexion and MC says "All network ports in use." This is repeatable for about
7119 a minute or so, then I get a ddt. loadp shows 11 free net ports.
7123 Date: Thu, 30 May 85 09:16:15 EST
7124 From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
7125 Subject: T-300s inaccessible
7126 To: BUG-ITS@MIT-MC.ARPA
7127 Message-ID: <[MIT-MC.ARPA].524200.850530.CSTACY>
7129 MC's T-300 disk controller was powered off somehow, although the
7130 PDP11 and other frobs in the same rack were still on. I power
7131 cycled it and reloaded the system to get things going again.
7133 Date: Wed, 29 May 85 15:52:32 EST
7134 From: Alan Bawden <ALAN@MIT-MC.ARPA>
7135 Subject: Most puzzling...
7136 To: BUG-ITS@MIT-MC.ARPA
7137 Message-ID: <[MIT-MC.ARPA].523215.850529.ALAN>
7139 Typical MC crash today:
7141 MC BUGHLT's with an MUUO in exec mode (see apparently typical example in
7142 CRASH;CRASH MUUO'). After
7145 The salvager does -not- print its usual greeting, nor is anything else
7146 printed on the system console. However, if you raise switch 0, ITS will
7147 stop just as if it was running normally (see example in CRASH;CRASH NOSALV).
7152 again will aparently work, except that the system will hang trying to get
7153 to unit 3 and you will need to try again after running BOOT11.
7155 (Note that something similar to this must have happened to Gumby the other
7156 day, except after a different initial crash...)
7158 Date: Wed, 29 May 85 02:52:25 EST
7159 From: Tim McNerney <TIM@MIT-MC.ARPA>
7160 Subject: Yow! I am reliable yet?
7161 To: BUG-ITS@MIT-MC.ARPA
7162 Message-ID: <[MIT-MC.ARPA].522693.850529.TIM>
7164 The time is 02:46:34 EDT.
7165 Today is Wednesday, the 29th of May, 1985.
7166 MC ITS 1488 has run for 103 days, 2 hours, 13 minutes, 32 seconds.
7167 Surpassing all previous MC records for uptime!
7168 System last revived 1 day, 2 hours, 12 minutes, 33 seconds ago.
7170 Date: Sun, 26 May 85 03:01:18 EST
7171 From: David Vinayak Wallace <GUMBY@MIT-MC>
7172 Subject: latest crash
7174 Message-ID: <[MIT-MC].518640.850526.GUMBY>
7176 I came in and MC was down; I looked at the pc; couldn't figure out what happened
7177 so saved it in crash;crash gmmpp (it died at gmmpp+3). I loaded a new xits, but
7178 the salvager never ran. I halted it with switch 0 and reloaded from scratch.
7180 Date: Sat, 25 May 85 21:28:34 EST
7181 From: Christopher C. Stacy <CSTACY@MIT-MC>
7182 Subject: AI COMSAT down for the count.
7184 cc: BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, DCB@MIT-MC, TAFT@MIT-MC,
7186 In-reply-to: Msg of Sat 25 May 85 01:19:30 EST from Pandora B. Berman <CENT>
7187 Message-ID: <[MIT-MC].518526.850525.CSTACY>
7189 This was because COMSAT assumes that the DEAD-MAIL-RECEIPTS list
7190 always exists, but I forgot to create it in NAMES >. I convinced the
7191 COMSAT on AI to gobble the latest NAMES before trying to unqueue
7192 anything, things are back to normal now, and I re-installed the
7195 Under certain conditions (such as fatal interrupts) AUTPSY comes out
7196 empty. COMSAT was probably dying with PDL overflows or something.
7198 (BTW, I already fixed the other unrelated looping bug which ALAN
7199 reported last week.)
7202 Date: Sat, 25 May 85 01:19:30 EST
7203 From: Pandora B. Berman <CENT@MIT-MC>
7204 Subject: AI COMSAT down for the count.
7206 cc: BUG-ITS@MIT-MC, DCB@MIT-MC, TAFT@MIT-MC
7207 Message-ID: <[MIT-MC].517969.850525.CENT>
7209 AI's COMSAT is stuck in a deadly loop. whenever it is launched, it
7210 first, of course, tries to cut down on the queued msgs by sending one
7211 of them. trouble is, the single one in its queue is to BUG-INQUIR@MC
7212 (alias CSTACY) and COMSAT thinks it's from DEAD-MAIL-RECEIPTS@AI. so
7213 after sending it (it does get through, each time; cstacy now has
7214 several of these in his mail) COMSAT tries to give a CMSG to
7215 DEAD-MAIL-RECEIPTS@AI. there is no such address, so COMSAT says
7216 ::=<ignored>. then it tries to CMSG again to the same address. after
7217 several times, it dies after just saying CMSG.
7219 BURNUP 1 was the first corpse dumped by this process. BURNUP 8 is the
7220 latest of several all of the same size (each died after only this work
7221 on the queue, while #1 included previous activity). I tried writing a
7222 new NAMES > with the guilty address eqv'd to NUL:, as it is on MC;
7223 COMSAT did not try to compile this before working on the queued mail.
7224 BURNUP 9 is COMSAT dying after i renamed LIST EQV (the bin of NAMES >)
7225 to something else; again, COMSAT did not look for the names database
7226 before hacking the queued mail. this is a gross bug and should be
7227 fixed; if there is no names database, maybe it's for a good reason,
7228 like the previous one is fuckt and someone wants comsat to pick up the
7229 new (hopefully cured) version. BURNUP 10 is from another experiment: i
7230 tried renaming LISTS MSGS to something else, COMSAT looked for NMSGS,
7231 found none, and died.
7233 alan and moon tried to debug this over the phone, but couldn't get
7234 enough data (AUTPSY kept containing 0 !). i have renamed AI:COMSAT
7235 LAUNCH to COMSAT BRUNCH. ai now has enough pieces of mail that it
7236 won't accept any more from outside. COMSAT should not be relaunched
7237 on AI until someone fixes this.
7239 Date: Mon, 20 May 85 03:54:02 EST
7240 From: Pandora B. Berman <CENT@MIT-MC>
7241 Subject: forwarding... someone forgot to hang up?
7243 Message-ID: <[MIT-MC].510876.850520.CENT>
7245 Date: Fri, 17 May 85 22:29:22 EST
7246 From: Robyn D. Spencer <TOOTSE@MIT-MC>
7248 Message-ID: <[MIT-MC].509023.850517.TOOTSE>
7251 I (mason) just connected to mc through a rolm and found myself logged
7252 in as tootse, as a mail notification popped up.
7253 I just thought someone would like to know.
7257 Date: Wed, 15 May 85 20:08:30 EST
7258 From: David A. Moon <MOON5@MIT-MC>
7259 Subject: MC crashes when you read AI backup tapes
7260 To: CENT@MIT-MC, MOON@MIT-MC
7262 Message-ID: <[MIT-MC].505155.850515.MOON5>
7264 I wasn't able to figure out the problem in detail, but I did edit
7265 a bug trap into the source at MGRD2. Sometime you should exhibit
7266 the problem with me physically present and I'll patch in this bug
7267 trap and see if it goes off.
7269 Date: Wed, 15 May 85 00:52:40 EST
7270 From: Pandora B. Berman <CENT@MIT-MC>
7271 Subject: patch for crufty ai tapes makes mc die horribly?
7274 Message-ID: <[MIT-MC].503776.850515.CENT>
7276 i was trying to read some old AI tapes. they got errors, so with glenn's
7277 advice i installed your patch:
7278 MOON5@MIT-ML 06/30/84 03:54:39
7279 To: GSB at MIT-ML, CENT at MIT-ML
7280 fyi the location to patch to disable tape read errors
7281 in ITS is MGMRT+1 which is changd from JRST MGERR to JRST MGRD2.
7282 It still tries a few times to retry errors but if it gets a fatal
7283 error it gives you whatever shitty data it got instead of barfing..
7285 then tried again with the tape. dump worked on tape a short while, with
7286 some hiccupping and one reported error, then system died. crash dump in
7287 CRASH IMRQ8. alan poked around at the code and thinks that possibly the
7288 patch is fucking up the MEMBLT table...
7290 Date: Mon, 13 May 85 18:54:28 EST
7291 From: Glenn S. Burke <GSB@MIT-MC>
7293 Subject: bugpause: tty: buffer empty at tyirem
7295 Message-ID: <[MIT-MC].501533.850513.GSB5>
7299 Date: Fri, 10 May 85 12:50:00 EST
7300 From: Kent M Pitman <KMP@MIT-MC>
7302 Message-ID: <[MIT-MC].495319.850510.KMP>
7304 MC has a pile of jobs which have PARERR'd out. Several dead COMSATs,
7305 etc. Someone might want to look at this.
7307 Date: Fri, 10 May 85 04:44:57 EST
7308 From: Glenn S. Burke <GSB@MIT-MC>
7311 Message-ID: <[MIT-MC].494815.850510.GSB>
7313 CRASH;WEDGED AGAIN is an example of this evening's wedgitude, dumped
7314 after being stopped by switch 0.
7316 Received: from MIT-AI by MIT-MC via Chaosnet; 10 MAY 85 01:27:09 EDT
7317 Date: Fri, 10 May 85 00:39:42 EST
7318 From: J. Noel Chiappa <JNC@MIT-AI>
7322 Message-ID: <[MIT-AI].590.850510.JNC>
7324 There was some breeze-shooting on the subject of speeding
7325 up the DZ output interrupt service routines which I thought I'd
7326 note down. Since a 9600 baud line running flat out generates
7327 1000 interrupts/second, and the output ISR looks quite long at
7328 the moment, a few lines running flat out will probably bring
7329 the machine to its knees.
7330 The theory is that we should implement efficient block mode
7331 output; i.e. the driver emulates a DMA device and takes big chunks of
7332 data each time ITS talks to it. We should blow some of the extra
7333 register sets that we have, one per DZ. 8 of the registers would be
7334 used for things like holding a pointer to the registers, etc, and
7335 temps, and the other 8 would be pointers to output buffers.
7336 The pointers would probably be AOBJN style pointers, with the
7337 data uppacked one byte per word. (We can't use byte pointers because
7338 there isn't any room for a count if so and there aren't enough
7339 registers to have counts too, unless we restrict ourselves to 4
7340 general registers and keep the counts in halfwords.) At that
7341 point, the output ISR would be about 10 instructions long:
7343 OPBASE = 6 ;Base of AOBJN pointer block in regs
7345 IORDI A,%DZRCS(D) ;Get CSR
7346 TRNN A,%DZCTR ;Transmitter ready?
7347 JRST LOSE ;No, spurious interrupt
7348 LDB A,[.BP %DZLM,A] ;Get line number
7349 MOVE T,OPBASE(A) ;Get AOBJN pointer for that line
7350 MOVE TT,(T) ;Pick up data
7351 IOWRI TT,%DZRTD(D) ;Write it out
7352 AOBJP T,DONE ;All done yet?
7353 MOVEM T,OPBASE(A) ;Put updated pointer back
7354 JRST 12,@TTYBRK ;Dismiss
7356 Or something like that, anyway.
7358 Date: Thu, 9 May 85 21:00:50 EST
7359 From: Alan Bawden <ALAN@MIT-MC>
7362 cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC
7363 In-reply-to: Msg of Thu 9 May 85 18:24:42-EDT from John Wroclawski <JTW%MIT-SPEECH at MIT-MC.ARPA>
7364 Message-ID: <[MIT-MC].494266.850509.ALAN>
7366 Date: Thu 9 May 85 18:24:42-EDT
7367 From: John Wroclawski <JTW at SPEECH>
7368 From: Alan Bawden <ALAN at MC>
7369 Subject: Everything is locked
7370 I guess it is unlikely, but it would be foolish of anyone else to try
7371 to assemble and try anything that uses KS-10 I/O instructions....
7372 Uh huh. Well, let me know when you think they work OK - I do hope to
7373 deal with the tape code sometime now that I'm back in town..
7375 The I/O instructions work just fine. Last night we installed Jinx's DZ-11
7376 code and it works too, so the path is clear for you.
7378 Date: Tue, 7 May 85 17:25:44 EST
7379 From: Ken Harrenstien <KLH@MIT-MC>
7381 cc: CSTACY@MIT-MC, BUG-ITS@MIT-MC
7382 Message-ID: <[MIT-MC].490451.850507.KLH>
7384 Date: Mon, 6 May 85 21:15:15 EST
7385 From: Alan Bawden <ALAN@MIT-MC>
7386 In-reply-to: Msg of Mon 6 May 85 10:34:28 EST from Christopher C. Stacy <CSTACY>
7388 If your COMSAT problem has to do with the hair COMSAT's go through
7389 when starting up to prevent their being more than one COMSAT, then I
7390 believe I remember KLH mentioning this before.
7392 Yes, this has happened. Makes one wonder if locks really do work, or
7393 if it is just the narrowness of the race window that gives one the impression
7396 Date: Tue, 7 May 85 05:58:57 EST
7397 From: Alan Bawden <ALAN@MIT-MC>
7398 Subject: Everything is locked
7400 Message-ID: <[MIT-MC].489464.850507.ALAN>
7402 I guess it is unlikely, but it would be foolish of anyone else to try to
7403 assemble and try anything that uses KS-10 I/O instructions until I get a
7404 chance to come in and install and verify the new microcode. The macros in
7405 KSDEFS are gone and have been replaced with the new I/O instructions I
7406 microcoded up. What this means is that everything is probably broken.
7408 Date: Tue, 7 May 85 02:34:47 EST
7409 From: David Vinayak Wallace <GUMBY@MIT-MC>
7410 Subject: MC:.;IOEVEL AIBIN
7413 In-reply-to: Msg of Mon 6 May 85 21:26:40 EST from Alan Bawden <ALAN>
7414 Message-ID: <[MIT-MC].489263.850507.GUMBY>
7416 Doesn't the system console watch .; like sys***;?
7418 Date: Mon, 6 May 85 21:26:40 EST
7419 From: Alan Bawden <ALAN@MIT-MC>
7420 Subject: MC:.;IOEVEL AIBIN
7422 Message-ID: <[MIT-MC].488587.850506.ALAN>
7424 Someone deleted the file MC:.;IOELEV AIBIN. It was either someone who
7425 reads this mailing list who thought he was cleaning up, or it was a random.
7426 In the later case there is nothing to be done, but in the former case I can
7427 prevent this from happening again by reminding you all that AI-11 still
7428 runs, and still network boots occasionall.
7430 Date: Mon, 6 May 85 21:15:15 EST
7431 From: Alan Bawden <ALAN@MIT-MC>
7434 In-reply-to: Msg of Mon 6 May 85 10:34:28 EST from Christopher C. Stacy <CSTACY>
7435 Message-ID: <[MIT-MC].488567.850506.ALAN>
7437 If your COMSAT problem has to do with the hair COMSAT's go through
7438 when starting up to prevent their being more than one COMSAT, then I
7439 believe I remember KLH mentioning this before.
7441 If this is a case of initializing a shared database using the algorithm
7442 given in .INFO.;ITS LOCKS, then perhaps the unlikely screw case documented
7443 there managed to actually happen.
7445 Date: Mon, 6 May 85 18:14:42 EST
7446 From: Glenn S. Burke <GSB@MIT-MC>
7449 Message-ID: <[MIT-MC].488010.850506.GSB>
7451 Date: Mon, 6 May 85 10:34:28 EST
7452 From: Christopher C. Stacy <CSTACY@MIT-MC>
7454 I just had a problem with COMSAT similar to the problem with
7455 PWORD the other day, where locks did not get unlocked.
7456 As in the previous case, the involved code has been stable for
7457 a long time (years). Is it possible that locks have become
7458 broken lately somehow? I heard there are bugs in the mechanism
7459 but I don't know what they are -- maybe I am just hitting some
7460 kind of screw case lately.
7462 I remember tracking down and patching the pword lock at least once
7463 before, years ago (on AI). Maybe once on ML too. I don't believe
7464 we knew what caused the problem.
7466 Date: Mon, 6 May 85 10:34:28 EST
7467 From: Christopher C. Stacy <CSTACY@MIT-MC>
7469 Message-ID: <[MIT-MC].487059.850506.CSTACY>
7471 I just had a problem with COMSAT similar to the problem with
7472 PWORD the other day, where locks did not get unlocked.
7473 As in the previous case, the involved code has been stable for
7474 a long time (years). Is it possible that locks have become
7475 broken lately somehow? I heard there are bugs in the mechanism
7476 but I don't know what they are -- maybe I am just hitting some
7477 kind of screw case lately.
7479 Date: Sun, 5 May 85 00:53:11 EST
7480 From: Alan Bawden <ALAN@MIT-MC>
7483 In-reply-to: Msg of Sat 4 May 85 19:24:06 EST from Glenn S. Burke <GSB>
7484 Message-ID: <[MIT-MC].485622.850505.ALAN>
7486 Had there been paper the message would have read: "TTY: OUTPUT BUFFER
7487 POINTER PAST END OF BUFFER". I added this crash to the collection.
7489 Date: Sat, 4 May 85 19:24:06 EST
7490 From: Glenn S. Burke <GSB@MIT-MC>
7493 Message-ID: <[MIT-MC].485447.850504.GSB5>
7495 mc crashed, was in ddt. no paper in the system console.
7496 dumped to crash;look later if anyone is interested and can find anything
7497 interesting from it...
7499 Date: Fri, 3 May 85 15:39:42 EDT
7500 From: J. Noel Chiappa <JNC@MIT-MC>
7504 Message-ID: <[MIT-MC].483905.850503.JNC>
7506 No, I'm not on them. I know what it looks like when
7507 PEEk gets an MPV and that wasn't it. I'm not sure what it
7508 was (it wasn't that the job had got and unhandled MPV,
7509 which would have shown up in the N display) but it wasn't
7510 PEEK losing its ass.
7512 Date: Fri, 3 May 85 15:33:57 EDT
7513 From: Christopher C. Stacy <CSTACY@MIT-MC>
7516 cc: BUG-ITS@MIT-MC, BUG-PWORD@MIT-MC
7517 In-reply-to: Msg of Fri 3 May 85 12:48:09 EDT from J. Noel Chiappa <JNC>
7518 Message-ID: <[MIT-MC].483895.850503.CSTACY>
7520 Date: Fri, 3 May 85 12:48:09 EDT
7521 From: J. Noel Chiappa <JNC>
7526 PWORD was getting MPV's. I couldn't fix this (and backing up to
7527 an older PWORD didn't fix it) so I temporarily flushed PWORD
7528 and replaced it with DDT so that at least people could log in.
7530 Although JNC doesn't think so, I am convinced that he was faked out by
7531 a bug in PEEK which sometimes causes it to print out "MPV not handled"
7534 When I went and ran PWORD, I did not get any kind of MPV problems, but
7535 I did get hung after the command prompt. Somehow, the lock word in
7536 the password database was set and never cleared, so all jobs would
7537 .HANG forever as soon as they tried to access the database. The job
7538 which had claimed the database was long gone. I patched the password
7539 database back into working order and re-installed PWORD.
7541 The code for PWORD has not been changed in a long time, so I suspect
7542 that some kind of hardware problem (or human) somehow screwed up the
7543 ITS locks critical routine feature, or munged the database.
7545 Date: Fri, 3 May 85 12:48:09 EDT
7546 From: J. Noel Chiappa <JNC@MIT-MC>
7550 Message-ID: <[MIT-MC].483484.850503.JNC>
7552 PWORD was getting MPV's. I couldn't fix this (and backing
7553 up to an older PWORD didn't fix it) so I temporarily flushed PWORD
7554 and replaced it with DDT so that at least people could log in.
7556 Date: Fri, 3 May 85 12:32:32 EDT
7557 From: John G. Aspinall <JGA@MIT-MC>
7559 Message-ID: <[MIT-MC].483460.850503.JGA>
7561 MC has been up all morning, but refuses to establish
7562 proper connections for incoming network telnets and supdups.
7563 Dialups also appear flaky, but I'm not sure about this.
7565 Symptoms - you get the telser message "MC Maximum Confusion PDP-10"
7568 Finger from another site shows lots of un-logged-in HACTRNs sitting
7569 there. Note that outgoing chtn, telnet, supdup are fine.
7570 Incoming finger is fine too.
7572 I don't know enough about what's going on to do anything constructive,
7573 but I'd be interested in finding out what the diagnosis is.
7575 Date: Tue, 30 Apr 85 01:16:24 EDT
7576 From: Alan Bawden <ALAN@MIT-MC>
7577 Subject: Oh yeah, right...
7579 cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC, BUG-DDT@MIT-MC
7580 Message-ID: <[MIT-MC].476201.850430.ALAN>
7582 [Message from GREN at MIT-AI 1:05pm]
7583 hey, single-stepping isn't working right!
7585 Oh yeah. Until I get back into microcode hacking again, hackers who debug
7586 programs using DDT on AI will find that features related to single stepping
7587 don't work right. I'll fix it eventually, I just haven't put in the
7590 I won't be fixing the fact that AI doesn't have a MAR, so somebody should
7591 be fixing DDT to know that some ITS machines lack the feature.
7593 Date: Fri, 26 Apr 85 22:53:01 EST
7594 From: Pandora B. Berman <CENT@MIT-MC>
7595 Subject: bring back old PDSET
7596 To: BUG-PDSET@MIT-MC, BUG-ITS@MIT-MC
7597 Message-ID: <[MIT-MC].471957.850426.CENT>
7599 MC crashed, and in being brought up had to have its time reset. in doing so
7600 i had to employ the new frilly version of PDSET. yucko. the old one worked
7601 fine with less verbiage and could parse 6-digit numbers into times and
7602 dates, which the new one can't. please flush this and restore the previous
7605 Date: Fri, 26 Apr 85 02:05:57 EST
7606 From: David Vinayak Wallace <GUMBY@MIT-MC>
7607 Subject: More on IMP opto-isolator board -- fixt for now.
7609 cc: DCLARK@MIT-MC, ANN@MIT-MC, JTW@MIT-MC,
7610 moon@SCRC-STONY-BROOK
7611 Message-ID: <[MIT-MC].470299.850426.GUMBY>
7613 ITS was unable to get any bits through for long enough to open a
7614 connection. Noel found a similar chip to the broken one in a chaosnet
7615 interface. We (me, jtw, jnc) yanked it and installed it (the same hack was
7616 apparently done five years ago).
7618 As this is the second one to fail, it is likely that another one will soon,
7619 and that the board may not appreciate being frobbed like this yet another
7620 time. I might make another isolator board sometime before the end of the
7621 term if I can get away with it.
7625 Date: Tue, 23 Apr 85 07:49:26 EST
7626 From: Glenn S. Burke <GSB@MIT-MC>
7627 Subject: mc memory randomness
7630 Message-ID: <[MIT-MC].465864.850423.GSB>
7632 mc tripped and fell down this morning. As might be expected, the system
7633 console hardcopy for the previous hour was all overprinted on a single line.
7634 There was a parity error light on in the ampex (penny recorded this in the
7637 Cold booting worked until it checked NXM, when it decided that most
7638 (but not all) of the two high MH10s were not there. The memory was
7639 listed in a large number of randomly sized chunks. Power cycling
7640 those two cabinets didn't help. (The overtemp light had been on in C
7641 -- don't know if it had been on as of when the machine went down.)
7642 Deselecting them seemed to be a good idea and seems to be working...
7644 Since the machine was up, and seeing the time, i decided to pass off
7645 calling DEC to ann finn (unlike what i wrote in the log earlier).
7647 Date: Mon, 22 Apr 85 21:57:01 EST
7648 From: Alan Bawden <ALAN@MIT-MC>
7651 Message-ID: <[MIT-MC].465386.850422.ALAN>
7653 MC's console card said I was supposed to load XITS, but there wasn't any
7654 such file. I dumped XITS myself several days back, so I wonder who renamed
7655 it to be OXITS without explanation?
7657 Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 15 APR 85 22:35:51 EST
7658 Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215097; Mon 15-Apr-85 22:35:39-EST
7659 Date: Mon, 15 Apr 85 22:32 EST
7660 From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
7661 Subject: M-X Copy File
7662 To: Alan Bawden <ALAN@MIT-MC.ARPA>
7663 cc: BUG-ITS@MIT-MC.ARPA
7664 In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>,
7665 <[MIT-MC].451173.850411.ALAN>
7666 Message-ID: <850415223234.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
7668 Date: Thu,11 Apr 85 13:10:07 EST
7669 From: Alan Bawden <ALAN@MIT-MC>
7671 A file's author is currently apparently set from the UNAME of the writing
7672 job. (I surmise, I haven't looked at the code yet.) Perhaps the XUNAME
7673 should be used instead?
7675 Here's the previous discussion of this:
7677 Date: Saturday, 15 September 1984, 12:06-EDT
7678 From: David A. Moon <Moon at SCRC-TENEX>
7680 Date: 14 September 1984 21:00-EDT
7681 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7683 M-X Copy File does not preserve authors on ITS.
7684 It does preserve reference date (although maybe it should
7685 use DNRF instead of referencing the file to copy it) and
7688 This is because the routine CLOSIT in the FILE job sets the author of the
7689 file it just wrote to the user's HSNAME. Evidently it does this because
7690 the FILE job doesn't login under the name of the user who is using it.
7692 (1) Make the FILE job login under the right name.
7693 (2) Make ITS set the file author from the XUNAME instead of the UNAME and
7694 make the file job set its XUNAME to the user's name instead of to
7695 a copy of its UNAME.
7696 (3) Make the FILE job set the author when it opens the file instead of
7700 Kerns suggests doing #3 or making ITS set the author from HSNAME instead
7701 of the UNAME. That sounds good except what about
\e^S?
7703 Last week I thought, mistakenly, that using
\e^S to run EMACS on
7704 another's terminal would make me be the author of files that I write.
7705 I think it should. Hence:
7707 - ITS should set the author of the file to the HSNAME.
7708 - The file job should set its HSNAME to that of the user on whose
7709 behalf it is acting.
7710 - The file job shouldn't set the author gratuitously.
7712 In the above, HSNAME would be XUNAME were it not for the fact that authors
7713 are stored as directory numbers rather than as sixbit strings.
7718 Date: Thu,11 Apr 85 13:10:07 EST
7719 From: Alan Bawden <ALAN@MIT-MC>
7721 Message-ID: <[MIT-MC].451173.850411.ALAN>
7723 A file's author is currently apparently set from the UNAME of the writing
7724 job. (I surmise, I haven't looked at the code yet.) Perhaps the XUNAME
7725 should be used instead?
7727 Date: Mon, 8 Apr 85 10:00:36 EST
7728 From: George J. Carrette <GJC@MIT-MC>
7729 Subject: blast from the past
7731 cc: BUG-ITS@MIT-MC, FILE-R@MIT-MC
7732 In-reply-to: Msg of Mon 8 Apr 85 00:12:06 EST from Alan Bawden <ALAN>
7733 Message-ID: <[MIT-MC].446519.850408100037.GJC>
7735 Speaking of historically interesting files I propose that certain
7736 MC/AI/ML backup tapes that would otherwise be discarded be put into
7737 the MIT archives and/or the CCC facility. Example: CCC has an Imlac,
7738 and I was showing Gill the :IMLOAD program and the IMLAC directory,
7739 but of course the IMLAC directory was reaped long ago. But since CCC
7740 has an old IBM 7 track drive they could actually make good use of the
7741 tapes with the IMLAC stuff. Personally I'm interested in seeing old
7742 snapshots of conniver, planner, rabbit, etc, all of which are on
7745 Date: Mon, 8 Apr 85 00:12:06 EST
7746 From: Alan Bawden <ALAN@MIT-MC>
7747 Subject: blast from the past
7750 In-reply-to: Msg of Sun 7 Apr 85 17:08:18 EST from George J. Carrette <GJC>
7751 Message-ID: <[MIT-MC].446193.850408001206.ALAN>
7753 Date: Sun, 7 Apr 85 17:08:18 EST
7754 From: George J. Carrette <GJC>
7755 the end of the contents of l;bibop (memo) seems to have extra blocks in
7756 it from the mail status file.
7758 ... from a mail status file from around 1974! I rescued this file
7759 from ML's filesystem last year. It was damaged on ML years ago.
7761 Its actually interesting to see what mail status files looked like ten
7764 Date: Sun, 7 Apr 85 17:08:18 EST
7765 From: George J. Carrette <GJC@MIT-MC>
7767 Message-ID: <[MIT-MC].445871.850407170822.GJC>
7769 the end of the contents of l;bibop (memo)
7770 seems to have extra blocks in it from the mail
7773 Date: Thu, 4 Apr 85 23:01:54 EST
7774 From: "Christopher C. Stacy" <CSTACY@MIT-MC>
7779 Date: Thu, 4 Apr 85 22:37:24 EST
7780 From: Herb Lin <LIN@MIT-MC>
7783 actually, i'm looking for a wizard. how do you change the
7784 password on ITS for your own account?
7788 Date: 31 March 1985 17:30-EST
7789 From: Glenn S. Burke <GSB @ MIT-MC>
7791 cc: BUG-ITS @ MIT-MC
7793 rolm 4602 calling mc doesn't answer.
7795 Received: from 40700024534 by MIT-MC via Chaosnet; 16 MAR 85 18:10:30 EST
7796 Received: from SCRC-EUPHRATES by SCRC-VALLECITO via CHAOS with CHAOS-MAIL id 2994; Sat 16-Mar-85 15:24:53-EST
7797 Date: Sat, 16 Mar 85 15:25 EST
7798 From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
7799 Subject: Tapes for Swedes
7800 To: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
7801 cc: bug-its@MIT-MC.ARPA
7802 Message-ID: <850316152523.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
7804 [Replying to a message that JTW forwarded to me]
7806 Date: 11 Mar 85 02:13 +0100
7807 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
7809 We can probably get access to a 7-track tape drive to read your tapes
7810 on, but we need some information about the format, like a backup program
7811 that we can read on a TOPS-10 or TOPS-20 machine. Even a listing would be
7814 Also, we would like to know what kind of tape drive and controller
7815 you are using, and if you use standard DEC core-dump format.
7817 If you can read 7-track tapes in DEC core-dump format, we can send you
7818 ITS dump tapes of all the relevant files, including the Midas assembler
7819 and binaries of Midas that will run on Tops-10. (I guess the right
7820 thing would be to include Tops-20 binaries of Midas as well). It will
7821 probably be six or seven reels of tape. The format is as simple as
7822 could be, I expect we can send you a 1/2 page writeup describing it
7823 along with the tapes. Or I can send you a one-sentence writeup right
7824 now: The files are delimited by tape file-marks; each file starts with a
7825 header, which starts with an "aobjn pointer", and contains its name in
7826 sixbit and some other stuff; the rest of the file is just the file, as
7827 36-bit words; at the front of the tape is another header, also starting
7828 with an "aobjn pointer", giving the tape name and some other stuff.
7830 Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 14 MAR 85 23:44:46 EST
7831 Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 197577; Thu 14-Mar-85 19:55:26-EST
7832 Date: Thu, 14 Mar 85 19:56 EST
7833 From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
7835 To: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
7836 cc: BUG-ITS@MIT-MC.ARPA
7837 In-Reply-To: <91827@QZCOM>
7838 Message-ID: <850314195652.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
7840 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
7842 Does anyone over there have an ITS tape?
7844 It's been three weeks since you sent your message (I'm behind on my mail).
7845 Was it ever clarified what type of tape drive you have and what formats
7846 of tape you can read? It's possible that we may have to write a 9-track
7847 Tops-10/Tops-20 Interchange format tape for you, which would be possible
7848 for us to do but would take a fair amount of work. With the recent episode
7849 of vandalism and destruction, there is only one running ITS machine in the
7850 world and it has a 7-track tape drive.
7852 Last year for archival purposes I dumped all the ITS and utility program
7853 sources on two reels of 9-track, 3200-bpi tape in a format that you
7854 definitely don't have a program to read. Two copies of those tapes
7855 exist in separate locations. It is not inconceivable that I could make
7856 another copy. That might be useful, since the separate locations are
7857 only three miles apart and hence could both be destroyed simultaneously.
7859 ... In the meantime we have gotten another
7860 machine, a KI10, which has been up and running several months.
7861 It runs a slightly modified TOPS-10 V7.02 (which isn't supposed
7862 to run on KI at all), and we have managed to simulate some
7863 KL instructions, for example ADJSP. We are planning hardware
7864 modifications so we can do ADJBP too. But TOPS-10 is not very
7865 exciting, so we have been thinking about getting up TENEX, or
7866 even TOPS-20. Do you know any place we can get a KI10 TENEX monitor?
7868 I think it would be considerably less work to get ITS running on a KI10
7869 than to get it running on a KS10. The biggest difference between the
7870 stock KI10 and the ITS-modified KA10 is that the KI10 paging is less
7871 flexible (no split page tables between the upper and lower half of
7872 user address space); but a small amount of software simulation could
7873 handle that; certainly it wouldn't be as bad as what it takes to get
7874 Tenex to run on the KI10. Or you could fix the hardware, which evidently
7875 you have the capability to do.
7877 Want to have a race? It wouldn't really be very fair, since there are
7878 only a couple of very part-time people working on the KS10 here.
7880 Does BBN still run TENEX? Any pointers would be appreciated.
7882 A perhaps little-known fact is that Symbolics still runs TENEX, on
7883 a Foonly F-2. I've been campaigning to get that machine thrown off the
7884 roof for quite a while now, but unfortunately there are still people
7887 Date: 7 March 1985 20:09-EST
7888 From: Ken Harrenstien <KLH @ MIT-MC>
7891 cc: BUG-ITS @ MIT-MC
7893 Date: 24 January 1985 20:56-EST
7894 From: Alan Bawden <ALAN @ MIT-MC>
7896 Just a event to ponder. The other day I supduped from MC back to MC
7897 (presumably using Chaosnet, I didn't think to check), and I was greeted
7902 12. Lusers, Fair Share = 6%
7906 Note that five characters ("MC IT") have been displaced. Conceivably the
7907 fact that the machine was so heavily loaded, and that the user and server
7908 were both on the same machine, could have allowed some timing screw that
7909 almost never happens normally.
7911 This is not new. The phenomenon has existed for several years and was
7912 first noticed on the AI KA-10 when telnet connections would sometimes produce
7913 scrambled initial prompts. I don't think anyone has made a serious effort
7914 to identify the bug. It could be in either the telnet server or in the
7915 ITS STY code. This would be a good case for any mystery lovers to investigate.
7917 Date: 7 March 1985 16:45-EST
7918 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7920 To: BUG-MAIL @ MIT-MC
7921 cc: BUG-ITS @ MIT-MC, KLH @ SRI-NIC
7923 I frobbed the Received: lines some more so that they look like the
7924 usual RFC822 ones; this is for both the SMTP and CHAOS servers.
7927 Received: from USC-ECLB.ARPA by MIT-MC.ARPA; 7 MAR 85 16:41:19 EST
7928 Received: from MIT-EECS by MIT-MC via Chaosnet; 7 MAR 85 16:41:02 EST
7930 They use new routines in various packages:
7931 The DATIME library now has a routine called TIMRFC.
7932 The OUT package now supports the new directive TIM(F4).
7936 Date: 7 March 1985 16:26-EST
7937 From: Alan Bawden <ALAN @ MIT-MC>
7938 Subject: MC hardware status
7939 To: BUG-ITS @ MIT-MC
7941 The most recent parity errors have occured in MH10-D. Also the microcode
7942 hangs about once a week it seems.
7944 Date: 6 March 1985 19:58-EST
7945 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7946 To: BUG-ITS @ MIT-MC
7948 (MC is getting the parity errors, not me...)
7950 Date: 6 March 1985 19:57-EST
7951 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7952 To: BUG-ITS @ MIT-MC
7954 We are getting a lot of parity errors lately, although I haven't
7955 looked to see where they are coming from.
7957 Received: from MIT-HTVAX.ARPA by MIT-MC.ARPA; WED 6 MAR 1985 1404 EST
7958 Received: by MIT-HTVAX.ARPA (4.12/4.7)
7959 id AA26507; Wed, 6 Mar 85 13:59:31 est
7960 Message-Id: <8503061859.AA26507@MIT-HTVAX.ARPA>
7961 To: BUG-ITS@mit-mc.ARPA
7962 Subject: Received: lines
7963 Date: 06 Mar 85 13:59:26 EST (Wed)
7964 From: Martin David Connor <marty@MIT-HTVAX.ARPA>
7967 Thanks to whoever put in received lines. They are very helpful in
7968 tracing the path of a message.
7970 Could they be altered slightly to conform to the RFC822 spec for such
7971 fields? It would be much easier to read if it were consistent with
7972 the rest of the Received lines a message might contain.
7974 Here is an excerpt from the RFC which specifies the order of the fields:
7976 received = "Received" ":" ; one per relay
7977 ["from" domain] ; sending host
7978 ["by" domain] ; receiving host
7979 ["via" atom] ; physical path
7980 *("with" atom) ; link/mail protocol
7981 ["id" msg-id] ; receiver msg id
7982 ["for" addr-spec] ; initial form
7983 ";" date-time ; time received
7987 Date: 2 March 1985 09:06-EST
7988 From: Devon S. McCullough <DEVON @ MIT-MC>
7989 To: BUG-ITS @ MIT-MC
7991 just got a looong hang, followed by host not responding/host reset the connection (I'm on via mit-tac) after which I was able to reconnect and reattach. net lossage?
7993 Date: 28 February 1985 03:05-EST
7994 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7996 To: BUG-ITS @ MIT-MC
7999 I rewrote PDSET from scratch, and made some improvements to
8000 the DWIM in the DATIME library. The new PDSET has not yet
8001 been tested entirely, and is not installed. Also, I didn't
8002 hack it up for the KS10 yet either. Will do some evening...
8004 Date: 21 February 1985 03:43-EST
8005 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8006 Subject: un-named hosts
8007 To: BUG-TCP @ MIT-MC, BUG-MAIL @ MIT-MC, BUG-REPLY @ MIT-MC
8008 cc: BUG-ITS @ MIT-MC
8009 In-reply-to: Msg of 20 Feb 1985 23:24-EST from Christopher C. Stacy <CSTACY>
8011 Date: 20 February 1985 23:24-EST
8012 From: Christopher C. Stacy <CSTACY>
8015 Someone at SCRC just tried to send me a message from a host not
8016 in our tables; he was refused by our server. I bet that the server
8017 died trying to look it up. I'll make it say CHAOS|nnnn or something.
8020 OK, I fixed this so that the Chaosnet SEND server will claim the
8021 message came from a host named like "24516/CHAOS".
8023 It occurred to me that it would be nice to be able to REPLY to these
8024 guys too, so I went and hacked up the NETWRK library to accept various
8025 numerical host names. (There was some code in NETWRK to parse some of
8026 these, but it was pretty broken and looked like it could never have worked.)
8028 Then I hacked up SENDER a little, mostly to know about the following
8029 poorly documented return convention of NETWRK"HSTLOOK: even if A gets
8030 a host address, B may contain zero rather than a database pointer.
8032 I also reassembled TELNET with the new NETWRK. With the right
8033 switches set, programs will now parse all these equivalent forms:
8036 10.2.0.6 ; Internet address
8037 2/6 ; Host 2 on IMP 6.
8038 3130/CHAOS ; (Other nets work too: 400006/ARPA is MIT-AI,
8039 77/SATNET is GOONHILLY-ECHO)
8042 If anything mysterious starts happenning with programs as they are
8043 re-assembled with the new NETWRK, let me know.
8047 Date: Thu 21 Feb 85 00:40:56-EST
8048 From: John Wroclawski <JTW%MIT-SPEECH@MIT-MC.ARPA>
8050 To: CENT@MIT-MC, Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
8052 In-Reply-To: Message from "Pandora B. Berman <CENT @ MIT-MC>" of Wed 20 Feb 85 23:25:36-EST
8054 From: Pandora B. Berman <CENT @ MIT-MC>
8057 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
8058 To: BUG-ITS@MIT-MC.ARPA
8064 it's been a long time since we said anything; sorry (at least we could
8065 have said it would take a long while or something). a chief problem
8066 that i have heard some of the hackers here mention about running ITS
8067 on your system is that the hardware list you sent does not include a
8068 paging box (i'm not sure what number that would be -- perhaps DM10 --
8069 someone will jump on me if i'm wrong).
8071 Um, actually it's not a DEC frob at all, so it hasn't got a number. The
8072 ones which were used at MIT were built either by us or Systems Concepts,
8073 I believe. ITS paging is somewhat different than TOPS-10, both of which
8074 are completely different than TENEX/TOPS-20.
8076 On the other hand, it might be possible to pound on your KI10 enough
8077 to get it to do ITS paging using the KI's paging hardware. The page
8078 tables are of different format, the pages are larger, and of course
8079 page faults are reported to the OS differently.
8082 also the ITS sources are not
8083 neatly available already on a single tape; someone would have to go
8084 through things and figure out what to send you, and we have all been
8085 sort of busy (we work full time on other things, or are students,
8088 Hmmm, if they have a TOPS-10 running, they at least have something to
8089 run MIDAS on. It's a start. Maybe when the KS is done things will be in
8092 i think BBN flushed their last tenex last spring; not sure who
8093 you could ask there for further details.
8095 They did. There are still a few of them running around the Arpanet
8096 though. If you can get the right paging hardware to run TENEX you
8097 actually have a pretty good chance of getting TOPS-20 up, if you can
8098 find a set of version 3 or 4 sources. You would either have to change
8099 a lot of code or change the way traps and such work on the KI though.
8100 For TENEX, I'd start by trying to get the latest sources from BBN,
8101 presumably they still have them around.
8104 Date: 20 February 1985 23:19-EST
8105 From: Pandora B. Berman <CENT @ MIT-MC>
8107 To: Bjorn_Danielsson_QZ%QZCOM.MAILNET @ MIT-MULTICS
8108 cc: BUG-ITS @ MIT-MC
8110 Date: 20 Feb 85 19:42 +0100
8111 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
8112 To: BUG-ITS@MIT-MC.ARPA
8114 Does anyone over there have an ITS tape? We (of the computer club
8115 STACKEN) would very much like to take a look at it and see if we can
8116 run it on our KA10. Any kind of tape will do, we think we can manage to
8117 decode it. And we promise not to bother you with questions later. We
8118 are even prepared to promise Ronald Reagan that we won't give it to the
8119 Russians :-) We have finally found a room to put the machine in, and it
8120 will be installed very soon. In the meantime we have gotten another
8121 machine, a KI10, which has been up and running several months. It runs
8122 a slightly modified TOPS-10 V7.02 (which isn't supposed to run on KI at
8123 all), and we have managed to simulate some KL instructions, for example
8124 ADJSP. We are planning hardware modifications so we can do ADJBP too.
8125 But TOPS-10 is not very exciting, so we have been thinking about
8126 getting up TENEX, or even TOPS-20. Do you know any place we can get a
8127 KI10 TENEX monitor? Does BBN still run TENEX? Any pointers would be
8130 it's been a long time since we said anything; sorry (at least we could have
8131 said it would take a long while or something). a chief problem that i have
8132 heard some of the hackers here mention about running ITS on your system is
8133 that the hardware list you sent does not include a paging box (i'm not sure
8134 what number that would be -- perhaps DM10 -- someone will jump on me if i'm
8135 wrong). also the ITS sources are not neatly available already on a single
8136 tape; someone would have to go through things and figure out what to send
8137 you, and we have all been sort of busy (we work full time on other things,
8138 or are students, etc.) i think BBN flushed their last tenex last spring;
8139 not sure who you could ask there for further details.
8141 maybe some piece of your KI could be used as an ITS paging box? i don't
8142 know (i'm not a hacker, alas, so i can't do more than speculate).
8144 Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655243468721180@MIT-MULTICS.ARPA>; 20 Feb 1985 18:37:48 est
8145 Date: 20 Feb 85 19:42 +0100
8146 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
8147 Reply-to: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
8148 To: BUG-ITS@MIT-MC.ARPA
8150 Message-ID: <91827@QZCOM>
8152 Does anyone over there have an ITS tape?
8153 We (of the computer club STACKEN) would very much like to take
8154 a look at it and see if we can run it on our KA10. Any kind of
8155 tape will do, we think we can manage to decode it. And we promise
8156 not to bother you with questions later. We are even prepared to
8157 promise Ronald Reagan that we won't give it to the Russians :-)
8158 We have finally found a room to put the machine in, and it will be
8159 installed very soon. In the meantime we have gotten another
8160 machine, a KI10, which has been up and running several months.
8161 It runs a slightly modified TOPS-10 V7.02 (which isn't supposed
8162 to run on KI at all), and we have managed to simulate some
8163 KL instructions, for example ADJSP. We are planning hardware
8164 modifications so we can do ADJBP too. But TOPS-10 is not very
8165 exciting, so we have been thinking about getting up TENEX, or
8166 even TOPS-20. Do you know any place we can get a KI10 TENEX monitor?
8167 Does BBN still run TENEX? Any pointers would be appreciated.
8172 Datorforeningen STACKEN
8174 Royal Institute of Technology
8181 Date: 13 February 1985 17:56-EST
8182 From: Glenn S. Braindeath <GSB @ MIT-MC>
8184 To: BUG-ITS @ MIT-MC
8186 I just got an IBO message...
8187 I seem to remember that this ain't supposed to happen.
8188 A minute later everything worked fine. (i'mon 1200 baud dialup)
8190 Date: 12 February 1985 18:17-EST
8191 From: David A. Moon <MOON @ MIT-MC>
8194 cc: BUG-ITS @ MIT-MC, TY @ MIT-MC, JNC @ MIT-XX
8196 Date: 12 February 1985 17:42-EST
8197 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8200 cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
8201 In-reply-to: Msg of Tue 12 Feb 85 17:40:25-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>
8203 Date: Tue 12 Feb 85 17:40:25-EST
8204 From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
8205 To: CSTACY at MIT-MC.ARPA
8206 cc: BUG-ITS at MIT-MC.ARPA, TY at MIT-MC.ARPA, JNC at MIT-XX.ARPA
8209 Date: 12 February 1985 17:32-EST
8210 From: Christopher C. Stacy <CSTACY>
8212 Date: Tue 12 Feb 85 17:29:53-EST
8213 From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
8215 I was speaking about making the system tattle on changes to
8216 .KLFE., or did you hack KLFEDR too?
8218 OOoh. I believe when you write a file on the front-end file system it
8219 changes pointers which live in files in the ITS directory.
8221 Nope. There is no entry for NTSDDT CMD in .KLFE.; but running
8222 KLFEDR reveals that it is there.
8224 OOoh. I believe when you write a file on the front-end file system it
8225 changes POINTERS WHICH LIVE IN FILES in the ITS directory.
8228 It's more complicated than that. We don't use the RSX-11 file system,
8229 we use the KLDCP file system which DEC later flushed.. Also the front-end
8230 files aren't in any one place on the disk, but are scattered all
8231 over. Some of them, especially the larger ones, reside in individual ITS
8232 files, others are pieces portions of an ITS file. And if you move or delete
8233 anything on the .KLFE. directory you screw it up since somewhere there is
8234 a KLDCP directory containing absolute disk addresses.
8235 You could make the .KLFE. dir be proetcedt and also make KLFEDR tattle itself
8238 Date: Tue 12 Feb 85 17:55:29-EST
8239 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
8241 To: CSTACY@MIT-MC.ARPA
8242 cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
8243 In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Tue 12 Feb 85 17:42:00-EST
8245 I parsed that correctly the second time. Yes, there does seem
8246 to be this file KLDCP (DIR) which macgically contains the actual blocks
8247 of the RSX-11 directory. So you will get the miscreants name (if done
8248 under ITS), but not which file he bashed.
8251 Date: 12 February 1985 17:42-EST
8252 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8255 cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
8256 In-reply-to: Msg of Tue 12 Feb 85 17:40:25-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>
8258 Date: Tue 12 Feb 85 17:40:25-EST
8259 From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
8260 To: CSTACY at MIT-MC.ARPA
8261 cc: BUG-ITS at MIT-MC.ARPA, TY at MIT-MC.ARPA, JNC at MIT-XX.ARPA
8264 Date: 12 February 1985 17:32-EST
8265 From: Christopher C. Stacy <CSTACY>
8267 Date: Tue 12 Feb 85 17:29:53-EST
8268 From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
8270 I was speaking about making the system tattle on changes to
8271 .KLFE., or did you hack KLFEDR too?
8273 OOoh. I believe when you write a file on the front-end file system it
8274 changes pointers which live in files in the ITS directory.
8276 Nope. There is no entry for NTSDDT CMD in .KLFE.; but running
8277 KLFEDR reveals that it is there.
8279 OOoh. I believe when you write a file on the front-end file system it
8280 changes POINTERS WHICH LIVE IN FILES in the ITS directory.
8284 Date: Tue 12 Feb 85 17:40:25-EST
8285 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
8287 To: CSTACY@MIT-MC.ARPA
8288 cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
8289 In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Tue 12 Feb 85 17:32:00-EST
8291 Nope. There is no entry for NTSDDT CMD in .KLFE.; but running
8292 KLFEDR reveals that it is there.
8295 Date: 12 February 1985 17:32-EST
8296 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8299 cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
8300 In-reply-to: Msg of Tue 12 Feb 85 17:29:53-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>
8302 Date: Tue 12 Feb 85 17:29:53-EST
8303 From: J. Noel Chiappa <JNC at MIT-XX.ARPA>
8305 I was speaking about making the system tattle on changes to
8306 .KLFE., or did you hack KLFEDR too?
8308 OOoh. I believe when you write a file on the front-end file system it
8309 changes pointers which live in files in the ITS directory.
8311 Date: Tue 12 Feb 85 17:29:53-EST
8312 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
8314 To: CSTACY@MIT-MC.ARPA
8315 cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
8316 In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Tue 12 Feb 85 17:12:00-EST
8318 I was speaking about making the system tattle on changes to
8319 .KLFE., or did you hack KLFEDR too?
8322 Date: 12 February 1985 17:12-EST
8323 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8326 cc: BUG-ITS @ MIT-MC, TY @ MIT-MC
8327 In-reply-to: Msg of Tue 12 Feb 85 12:29:46-EST from J. Noel Chiappa <JNC at MIT-XX.ARPA>
8329 Huh? I put the file back into the front-end file system,
8330 and it has been working for a couple of days.
8332 Date: Tue 12 Feb 85 12:29:46-EST
8333 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
8335 To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
8336 cc: TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA
8337 In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Fri 8 Feb 85 13:17:00-EST
8339 It's not clear if this will do the right thing, since presumably
8340 the file was also deleted from the RSX-11 directory, which would have used
8341 KLFEDR or whatever the fuck that program is called. In fact, you could
8342 delete it with KLFEDR and not touch the directory entry in .KLFE. I guess.
8345 Date: 8 February 1985 23:04-EST
8346 From: David E. Hirsch <HIRSCH @ MIT-MC>
8347 To: BUG-ITS @ MIT-MC
8349 this is NOT hirsh. I just ROLM'ed to MC and whoops, here I am all logged in and everything. Oh well. I'm on T30.
8351 Date: 8 February 1985 13:17-EST
8352 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8354 To: BUG-ITS @ MIT-MC
8357 The front end file NTSDDT seems to have been deleted over the weekend.
8358 I re-created it; you can boot the system normally now.
8359 I also made the front-end file directory be tattled on by the system job.
8361 Date: 29 January 1985 18:00-EST
8362 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8363 Subject: MINITS HUBs making noise
8364 To: BUG-MINITS @ MIT-MC
8365 cc: BUG-ITS @ MIT-MC
8367 NE438B, NE438C, and NE437A have terminal lines running open
8368 or something. They keep generating a lot of noise, some of
8369 which is control-Zs, so they are connecting to MC and typing
8370 the noise at us. This eats up network resources and prevents
8371 some people from logging in,etc. I heard that the power company
8372 is being flaking today, which may have something to do with it.
8374 Date: 28 January 1985 15:20-EST
8375 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8377 cc: BUG-ITS @ MIT-MC
8378 In-reply-to: Msg of 27 Jan 1985 02:09-EST from Devon S. McCullough <DEVON>
8380 You are probably getting memory parity errors.
8382 Date: 27 January 1985 02:09-EST
8383 From: Devon S. McCullough <DEVON @ MIT-MC>
8384 To: BUG-ITS @ MIT-MC
8386 Two or three times in the last day or so I've gotten
8388 top level interrupt, tree detached
8390 This usually happens when I have been typing ^Z's and ^G's because
8391 the system is not responding. Now I have a dead detached tree.
8392 I can usually type ^_'s to prove that the system itself is alive
8393 even though nothing is responding.
8395 Date: 26 January 1985 03:47-EST
8396 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8397 Subject: not knowing the time
8398 To: BUG-FTP @ MIT-MC
8399 cc: ALAN @ MIT-MC, BUG-ITS @ MIT-MC
8401 OK, FTP servers now die cleanly if they don't know the time.
8403 Date: 25 January 1985 23:10-EST
8404 From: Alan Bawden <ALAN @ MIT-MC>
8407 cc: BUG-ITS @ MIT-MC
8408 In-reply-to: Msg of 25 Jan 1985 21:00-EST from Christopher C. Stacy <CSTACY>
8410 Date: 25 January 1985 21:00-EST
8411 From: Christopher C. Stacy <CSTACY>
8412 Date: Fri 25 Jan 85 12:08:58-EST
8413 From: Glenn S. Burke <GSB at XX>
8414 is mc's arpa connection busted? can't reach it from rutgers
8416 It does for me at the moment.
8418 I guess you can tell from this that Chris reads his mail in reverse!
8420 Date: 25 January 1985 21:00-EST
8421 From: Christopher C. Stacy <CSTACY @ MIT-MC>
8424 cc: BUG-ITS @ MIT-MC
8425 In-reply-to: Msg of Fri 25 Jan 85 12:08:58-EST from Glenn S. Burke <GSB at MIT-XX.ARPA>
8427 Date: Fri 25 Jan 85 12:08:58-EST
8428 From: Glenn S. Burke <GSB at MIT-XX.ARPA>
8429 To: bug-its at MIT-MC.ARPA
8432 is mc's arpa connection busted? can't reach it from rutgers
8435 It does for me at the moment.
8437 Date: Fri 25 Jan 85 12:08:58-EST
8438 From: Glenn S. Burke <GSB@MIT-XX.ARPA>
8440 To: bug-its@MIT-MC.ARPA
8442 is mc's arpa connection busted? can't reach it from rutgers or xx via internet.
8445 Date: 25 January 1985 13:06-EST
8446 From: Alan Bawden <ALAN @ MIT-MC>
8447 To: BUG-FTP @ MIT-MC
8448 cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC
8449 In-reply-to: Msg of 25 Jan 1985 10:15-EST from Kent M Pitman <KMP>
8451 Date: 25 January 1985 10:15-EST
8452 From: Kent M Pitman <KMP>
8453 System went down at 6:25am this morning. Whoever brought it back up
8454 forgot to set the time so mostly no one could log in.
8456 And MC hasn't been talking TCP since then, because the tables were clogged
8457 with a zillion dead FTP servers because of the silly .VALUE-when-ITS-
8458 doesn't-know-the-time screw I reported a couple weeks ago.
8460 Date: 25 January 1985 10:15-EST
8461 From: Kent M Pitman <KMP @ MIT-MC>
8462 To: BUG-ITS @ MIT-MC
8464 System went down at 6:25am this morning. Whoever brought it back up forgot
8465 to set the time so mostly no one could log in.
8467 Date: 24 January 1985 20:56-EST
8468 From: Alan Bawden <ALAN @ MIT-MC>
8470 To: BUG-ITS @ MIT-MC
8472 Just a event to ponder. The other day I supduped from MC back to MC
8473 (presumably using Chaosnet, I didn't think to check), and I was greeted
8478 12. Lusers, Fair Share = 6%
8482 Note that five characters ("MC IT") have been displaced. Conceivably the
8483 fact that the machine was so heavily loaded, and that the user and server
8484 were both on the same machine, could have allowed some timing screw that
8485 almost never happens normally.