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 Date: 23 January 1985 23:47-EST
19 From: Alan Bawden <ALAN @ MIT-MC>
20 Subject: Tempest in a TELSER.
22 cc: BUG-ITS @ MIT-MC, DANIEL @ MIT-MC
23 In-reply-to: Msg of 23 Jan 1985 17:42-EST from Alan Bawden <ALAN>
25 Date: 23 January 1985 17:42-EST
26 From: Alan Bawden <ALAN>
27 ... I plan to fix the timeout algorithm to close the connection after
28 it sees the STY idle twice in a row. That, and a check every 15
29 seconds, should assure you of at -least- 15 seconds (but not more than
30 30) before closing the connection....
32 Ok I did this. Actually I did it with a 20 second timeout. Thus, you now
33 get at least 20 seconds, at most 40 seconds, and an average of 30 seconds.
34 A reason to want a longer timeout is to give the TELSER's single page a
35 chance to swap out and stay out. This probably doesn't matter much on MC
36 but it might help a bit on AI.
38 An alternative solution, that would take a few more lines of code, would be
39 for TELSERs to keep a USR: channel open to the toplevel job on the other
40 end of the STY. Then they would get an interrupt when that job went away,
41 indicating some kind of interesting job manipulation was taking place on
42 the other side. Unfortunately nothing would happen if the tree was just
45 Date: 23 January 1985 17:42-EST
46 From: Alan Bawden <ALAN @ MIT-MC>
47 Subject: Tempest in a TELSER.
50 In-reply-to: Msg of 22 Jan 1985 19:39-EST from Daniel Weise <DANIEL>
52 Date: 22 January 1985 19:39-EST
53 From: Daniel Weise <DANIEL>
54 Why is MC suddenly breaking supdup connections when I
55 log out? I prefer the behavior where I have to manually
58 'Cause we are experimenting with adjusting the timeout to different values.
59 Currently it is patched to be 15 seconds. For years it has been set at 5
60 minutes. I think we are all agreed that the current setting is a loser. I
61 plan to fix the timeout algorithm to close the connection after it sees the
62 STY idle twice in a row. That, and a check every 15 seconds, should assure
63 you of at -least- 15 seconds (but not more than 30) before closing the
66 Unless anybody would like to object or propose anything else?
68 Date: 22 January 1985 19:39-EST
69 From: Daniel Weise <DANIEL @ MIT-MC>
72 Why is MC suddenly breaking supdup connections when I
73 log out? I prefer the behavior where I have to manually
76 Date: 22 January 1985 14:35-EST
77 From: Alan Bawden <ALAN @ MIT-MC>
78 Subject: TELSER timeout
79 To: CBF @ MIT-MC, CSTACY @ MIT-MC
82 The current timeout is definitely too short. MC has hung up on me
83 instantly a couple of times in the last few days. Perhaps the code should
84 be fixed to log itself out only if it sees the STY idle twice in a row.
86 Date: 20 January 1985 19:33-EST
87 From: Alan Bawden <ALAN @ MIT-MC>
88 Subject: Page fault caused by .GETSYS
91 In-reply-to: Msg of 19 Jan 1985 17:07-EST from Kent M Pitman <KMP>
93 Date: 19 January 1985 17:07-EST
94 From: Kent M Pitman <KMP>
96 Page fault in system at 304000,,130422
98 This has been happening on and off for quite some time. .GETSYS would
99 sometimes cause a seemingly spurious page fault. I introduced this bug
100 myself last summer and I just fixed it in the source. Sure feels good to
101 delete some of those crash dumps knowing that you actually fixed the
104 Date: 20 January 1985 10:46-EST
105 From: Christopher C. Stacy <CSTACY @ MIT-MC>
106 Subject: Closing net connections when your STY goes away
108 cc: BUG-ITS @ MIT-MC, MRC @ SU-SCORE
109 In-reply-to: Msg of 18 Jan 1985 22:42-EST from Charles Frankston <CBF>
111 Five minutes is admittedly a long time. I think I would be happy if
112 it were one half minute, I think (15 seconds might be OK, but I want
113 to be more gracious). If no one responds to CBF's query in a few days,
114 I'll change it in the source.
117 Date: 20 January 1985 10:44-EST
118 From: Christopher C. Stacy <CSTACY @ MIT-MC>
119 Subject: HSNAME change
121 cc: BRUC @ MIT-MC, BUG-DDT @ MIT-MC, BUG-INQUIR @ MIT-MC,
122 BUG-ITS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC,
123 USER-ACCOUNTS @ MIT-MC
124 In-reply-to: Msg of 19 Jan 1985 02:35-EST from Alan Bawden <ALAN>
126 I fixed this (right this time).
128 Date: 19 January 1985 17:07-EST
129 From: Kent M Pitman <KMP @ MIT-MC>
133 Page fault in system at 304000,,130422
136 I dumped this to CRASH;PFA3+2 19-JAN
137 and cold booted. -kmp
139 Date: 19 January 1985 02:35-EST
140 From: Alan Bawden <ALAN @ MIT-MC>
141 Subject: HSNAME change
142 To: CSTACY @ MIT-MC, KMP @ MIT-MC, BUG-INQUIR @ MIT-MC
143 cc: USER-ACCOUNTS @ MIT-MC, BRUC @ MIT-MC, BUG-DDT @ MIT-MC,
144 TAFT @ MIT-MC, BUG-ITS @ MIT-MC
145 In-reply-to: Msg of 18 Jan 1985 23:48-EST from Robert E. Bruccoleri <BRUC>
147 Date: 18 January 1985 23:48-EST
148 From: Robert E. Bruccoleri <BRUC at MC>
149 My home directory was changed from USERS0; to GUEST0; recently
150 without the relocation of my files or the redirection of my mail....
152 Date: 18 January 1985 23:59-EST
153 From: Kent M Pitman <KMP at MC>
154 INQUIR seems to give people with a "Z" designation (clinical decision
155 making group) a GUESTn home dir if they don't have a home dir of their
156 own. This is arguably a bug....
158 Earlier the same day....
160 Date: 18 January 1985 09:26-EST
161 From: Christopher C. Stacy <CSTACY at MC>
162 Subject: AI file directories
164 cc: BUG-DDT at MC, BUG-ITS at MC, KMP at MC, TAFT at MC
165 Enough occasional and small users from AI use MC now that I was
166 getting tired of using INQUIR to manually force their home directory
167 to be AI0. This morning I taught INQUIR that if an "A" person comes
168 along who does not have a directory, it will automatically stick them
169 in AI0 (rather than USERSn). Of course, if AI0 starts getting too
170 full due to many people, we can make more dirs. But I don't think
171 that's too likely since most AI people with alot of files have their
172 own directory and don't need to use AI0.
174 Well, more than just AI users seem to have their directories changed, so I
175 retracted the new version of LSRTNS, reassembled DDT (being careful to
176 increment the version number this time) and installed it. The buggy
177 ATSIGN DDT was renamed to be ATSIGN XDDT.
179 Date: 18 January 1985 22:42-EST
180 From: Charles Frankston <CBF @ MIT-MC>
181 Subject: Closing net connections when your STY goes away
182 To: CSTACY @ MIT-MC, MRC @ SU-SCORE
185 Well, I think the current timeout is kind of long, so I have temporarily
186 patched it to 15 seconds instead of 5 minutes. If anyone remembers why
187 it was 5 minutes, I'd be interested in knowing.
189 This will also help free up STYs faster for those times when the system
192 Date: 18 January 1985 17:35-EST
193 From: Christopher C. Stacy <CSTACY @ MIT-MC>
194 Subject: TAC binary mode
197 In-reply-to: Msg of Fri 18 Jan 85 09:25:48-PST from Mark Crispin <MRC at SU-SCORE.ARPA>
200 Foo. We like it waiting for me to type "^Z", rather than gratitously
201 disconnecting. As for decisions being cast in stone, I just happen to
202 think it is the right decision (and the users and other programmers
203 here concur.) If you re-read my message, I did suggest that perhaps
204 there should be a way for users to ask to be disconnected upon logout.
205 By the way, when coming in over the net I myself turn on binary mode
206 in my login init file so that I can use the META key on my home
207 terminal. Since I run a program (:TBMOFF) in my logout init file
208 which turns it back off, I never get wedged.
211 Date: Fri 18 Jan 85 09:25:48-PST
212 From: Mark Crispin <MRC@SU-SCORE.ARPA>
213 To: CSTACY@MIT-MC.ARPA
214 cc: BUG-ITS@MIT-MC.ARPA
215 In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Fri 18 Jan 85 03:06:00-PST
216 Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
217 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
219 Bullshit. The connection was *not* in a wedged state. It was
220 waiting for me to type CTRL/Z to start another ITS job. I deliberately
221 typed @ B I S because I wanted a binary link without the TAC intercept
222 character interfering. The last thing I want when I am logged in to a
223 host is to have the damn Tip (be it Internet, Chaos, Pup, DECnet, or
224 whatever) decide to grab one of my characters as an intercept character.
225 I know damned well how to change the intercept character, but with the
226 advent of certain display editors which use all 128 ASCII characters for
227 commands there is NO "safe" intercept character.
229 One of the reasons why ITS in the old days was so great was that
230 the system programmers of that time didn't consider the decisions of the
231 past to be enshrined in stone and unchangable.
234 Date: 18 January 1985 09:26-EST
235 From: Christopher C. Stacy <CSTACY @ MIT-MC>
236 Subject: AI file directories
237 To: BUG-INQUIR @ MIT-MC
238 cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC
240 Enough occasional and small users from AI use MC now that I was
241 getting tired of using INQUIR to manually force their home directory
242 to be AI0. This morning I taught INQUIR that if an "A" person comes
243 along who does not have a directory, it will automatically stick them
244 in AI0 (rather than USERSn). Of course, if AI0 starts getting too
245 full due to many people, we can make more dirs. But I don't think
246 that's too likely since most AI people with alot of files have their
247 own directory and don't need to use AI0.
250 Date: 18 January 1985 06:06-EST
251 From: Christopher C. Stacy <CSTACY @ MIT-MC>
252 Sender: CSTAC0 @ MIT-MC
255 In-reply-to: Msg of 17 Jan 1985 21:58-EST from Mark Crispin <MRC>
258 Come on, the bug is clearly in your user host which stopped paying
259 attention to you. Closing your connection is just one thing which it
260 prevented you from doing by putting you into a wedged state.
261 It is a feature that ITS does not close connections when you log out.
262 Maybe there should be a :LOGOUT option to force your connection closed
263 though, for people who want this.
265 Date: 17 January 1985 23:10-EST
266 From: Richard M. Stallman <RMS @ MIT-MC>
269 I always find it unpleasant when OZ breaks connections with me
270 just because I log out.
272 Date: 17 January 1985 21:58-EST
273 From: Mark Crispin <MRC @ MIT-MC>
276 I wish ITS closed the connection when you logged out. It is easier to
277 re-open the connection if you want it than it is to extract yourself
278 from a host which won't hang up when you log out. I had to gun my TELSER
279 to get out of a @B I S connection from the TAC.
281 Date: 17 January 1985 15:06-EST
282 From: Kent M Pitman <KMP @ MIT-MC>
285 MC's network terminals and the (AAA) next to the system console and
286 such stopped responding. The system console seemed to be happy, so I
287 ran :.;BOOT11 from there and things seem happy again.
289 Date: 11 January 1985 19:37-EST
290 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
292 cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
293 In-reply-to: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ <TAR>
295 Date: 9 January 1985 15:48-EST
296 From: Thomas A. Russ <TAR>
300 :CHUNAME doesn't work. It prints the "-- Massacre and Reset --"
301 question, but when I type <space>, it responds with a single question
302 mark ("?") and does nothing.
304 Probably you, in your incarnation as TAR0, were trying to :CHUNAM to
305 TAR, but there already was a TAR, possibly detached. DDT was informing
306 you in its usual terse fashion, (which has saved us at last count over
307 2^23 character output calls since ITS was first booted).
310 Date: 10 January 1985 01:23-EST
311 From: Howard D. Trachtman <HDT @ MIT-MC>
314 cc: HDT @ MIT-MC, CSTACY @ MIT-MC
316 It also seems to me that control-Zing out of writing a file in emacs and
317 proceeding consitently leaves a Jjob in my name, but which doesn't seem
318 to get restarted in a manner capable of finishing the write.
320 Date: 9 January 1985 23:12-EST
321 From: Christopher C. Stacy <CSTACY @ MIT-MC>
325 When an archive device dies maybe it should return device not available
326 or if it was because of size limitations, device full.
328 Date: 9 January 1985 16:04-EST
329 From: Christopher C. Stacy <CSTACY @ MIT-MC>
331 cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
332 In-reply-to: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ <TAR>
334 Date: 9 January 1985 15:48-EST
335 From: Thomas A. Russ <TAR>
339 :CHUNAME doesn't work. It prints the "-- Massacre and Reset --"
340 question, but when I type <space>, it responds with a single question
341 mark ("?") and does nothing.
343 This would probably be a DDT bug, not an ITS bug.
344 :CHUNAME works fine for me. Please send a real bug report,
345 specifying the input you gave the function.
347 Date: 9 January 1985 15:48-EST
348 From: Thomas A. Russ <TAR @ MIT-MC>
349 Sender: TAR0 @ MIT-MC
352 :CHUNAME doesn't work. It prints the "-- Massacre and Reset --"
353 question, but when I type <space>, it responds with a single question
354 mark ("?") and does nothing.
357 Date: 4 January 1985 19:48-EST
358 From: Ken Harrenstien <KLH @ MIT-MC>
359 Subject: Tape archives
363 How much tape are you actually talking about flushing? I doubt you plan
364 to re-use the tapes; therefore it must just be the storage requirements
365 that you object to. But tapes don't take up much room at all (depending
366 on how you chose to store them), and even if there is only one file on
367 each tape which is worth keeping, it is still much easier to simply keep
368 that tape than to try to achieve any kind of compaction.
370 I don't think any ITS tapes should be junked unless a large majority of
371 ITS users thinks it is reasonable. There just is no way to predict
372 which files you will someday be interested in retrieving, and once they
373 are flushed, they are gone forever. The ITS systems have vastly more
374 historic significance than MIT-XX, or in fact most other computer systems
375 on the network, and this should be a consideration.
377 Incidentally, the notion of taking a complete file system dump and locking
378 it away for backup, archival, or posterity is considered a good idea in
379 other places as well. We do this on SRI-NIC, for example. Perhaps
380 you are just doing it too often.
382 Date: 4 January 1985 01:21-EST
383 From: Pandora B. Berman <CENT @ MIT-MC>
384 Subject: amazing brain damage
387 irene grief has apparently gotten the idea into her head that
388 flushing all old ITS tapes up to six months ago is not only
389 feasible but a good idea. see CENT;LCS TAPES for details.
391 Date: 2 January 1985 15:14-EST
392 From: Christopher C. Stacy <CSTACY @ MIT-MC>
395 cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC
396 In-reply-to: Msg of 2 Jan 1985 14:15-EST from Alan Bawden <ALAN>
399 Date: 2 January 1985 14:15-EST
400 From: Alan Bawden <ALAN>
401 In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy <CSTACY>
403 Ah! So perhaps the hangup detection is busted on some line? Did you
404 experiment to see if it was a repeatable failure? Which line did this
407 Unfortunately, I was running out the door at the time and didn't
408 remember to check which dialup line I was on until it was too late.
409 I suspect that it was T04. I suppose we could check the console log.
411 Mostly I sent the message to make sure that other people thought that
412 hangup detection is really supposed to work on all the lines we have.
413 It doesn't work on the ROLM lines though, does it?
415 Date: 2 January 1985 14:15-EST
416 From: Alan Bawden <ALAN @ MIT-MC>
418 cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC
419 In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy <CSTACY>
421 Date: 2 January 1985 09:44-EST
422 From: Christopher C. Stacy <CSTACY>
423 Date: 1 January 1985 20:05-EST
424 From: Alan Bawden <ALAN>
425 Date: 1 January 1985 15:55-EST
426 From: Sydney E. Atkinson <SGA>
427 hanging up a dialup line does not log you out.
428 It shouldn't. People shouldn't lose the contents of their editor
429 buffers just because they tripped over the phone cord. Hanging up
430 a dialup line detaches your job tree so that you can dial in again
431 and reattach to it (or gun it down if it was wedged in some way).
432 Have you observed some behavior other than this?
433 The job was not detached either: it was left sitting there for at
434 least five minutes, and when I dialup up the same line I was already
435 logged in to SGA's session.
437 Ah! So perhaps the hangup detection is busted on some line? Did you
438 experiment to see if it was a repeatable failure? Which line did this
441 Date: 2 January 1985 09:44-EST
442 From: Christopher C. Stacy <CSTACY @ MIT-MC>
444 cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC
445 In-reply-to: Msg of 1 Jan 1985 20:05-EST from Alan Bawden <ALAN>
447 Date: 1 January 1985 20:05-EST
448 From: Alan Bawden <ALAN>
451 In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson <SGA>
453 Date: 1 January 1985 15:55-EST
454 From: Sydney E. Atkinson <SGA>
455 hanging up a dialup line does not log you out.
457 It shouldn't. People shouldn't lose the contents of their editor buffers
458 just because they tripped over the phone cord. Hanging up a dialup line
459 detaches your job tree so that you can dial in again and reattach to it (or
460 gun it down if it was wedged in some way). Have you observed some behavior
463 The job was not detached either: it was left sitting there for at
464 least five minutes, and when I dialup up the same line I was already
465 logged in to SGA's session.
467 Date: 1 January 1985 20:05-EST
468 From: Alan Bawden <ALAN @ MIT-MC>
471 In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson <SGA>
473 Date: 1 January 1985 15:55-EST
474 From: Sydney E. Atkinson <SGA>
475 hanging up a dialup line does not log you out.
477 It shouldn't. People shouldn't lose the contents of their editor buffers
478 just because they tripped over the phone cord. Hanging up a dialup line
479 detaches your job tree so that you can dial in again and reattach to it (or
480 gun it down if it was wedged in some way). Have you observed some behavior
483 Date: 1 January 1985 15:55-EST
484 From: Sydney E. Atkinson <SGA @ MIT-MC>
487 hanging up a dialup line does not log you out.
489 Date: 26 December 1984 22:57-EST
490 From: David A. Moon <MOON @ MIT-MC>
491 Subject: How to take a dump of a machine that had been running?
493 cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC
495 Date: Mon, 24 Dec 84 22:12 EST
496 From: Kent M Pitman <KMP@MIT-MC.ARPA>
498 I hit Break and got to KLDCP. Then I said SP.
499 When I tried to do DDT, it said it was in User Mode and
500 that I had to do MR first.
502 This is pretty dumb of KLDCP. SP is "stop" and DDT is "start
503 at the start address of DDT, which is stashed in a location in
504 low memory somewhere." I don't know why KLDCP can't switch from
505 user mode to exec mode itself.
507 I wasn't sure if that would
508 destroy the useful state needed to do the dump. So I just
509 hit the disk button on the machine and ran a full boot.
511 Certainly MR will destroy less state than cold-booting from the
512 disk button! MR (stands for master reset) probably loses at most
513 the contents of the accumulators, and maybe not even that.
515 Aside: it's a pity the designers of the pdp-11 front end for the KL10
516 never bothered to look at the software that runs on the pdp-10 for their
517 user-interface ideas. I'm certainly glad I didn't take that job when
518 it was offered to me! End of history lesson.
520 Would the right thing to do have been to say MR, DDT,
521 then dump it from there?
523 I think so. Actually, a better approach would have been to
524 continue the machine (I forget the two-letter abbreviation for
525 that) then raise switch zero (the switch zero on the left). If
526 it's in user mode it's probably scheduling periodically, and if
527 it's scheduling periodically switch zero will get you to DDT
528 in a clean state to take a dump.
530 I'm not at all clear on what the
531 various states of the machine are here... so I didn't
532 know if I'd just be wasting my time trying to do something
533 I really know nothing about. If I had any reason to think
534 it would have worked, I'd have given it a shot. So let me
535 know if it was the right thing (or what would have been)
536 and next time I'll try it. -kmp
538 It never hurts to take a dump, in my opinion.
540 Received: from MIT-FRANK-SINATRA by MIT-OZ via Chaosnet; 24 Dec 84 22:10-EST
541 Date: Mon, 24 Dec 84 22:12 EST
542 From: Kent M Pitman <KMP@MIT-MC.ARPA>
543 Subject: How to take a dump of a machine that had been running?
545 Cc: BUG-ITS@MIT-MC.ARPA
547 I hit Break and got to KLDCP. Then I said SP.
548 When I tried to do DDT, it said it was in User Mode and
549 that I had to do MR first. I wasn't sure if that would
550 destroy the useful state needed to do the dump. So I just
551 hit the disk button on the machine and ran a full boot.
552 Would the right thing to do have been to say MR, DDT,
553 then dump it from there? I'm not at all clear on what the
554 various states of the machine are here... so I didn't
555 know if I'd just be wasting my time trying to do something
556 I really know nothing about. If I had any reason to think
557 it would have worked, I'd have given it a shot. So let me
558 know if it was the right thing (or what would have been)
559 and next time I'll try it. -kmp
561 Date: 24 December 1984 21:45-EST
562 From: Ken Harrenstien <KLH @ MIT-MC>
563 Subject: MC being down today
567 Normally the best thing to do with a dead or comatose system is dump
568 it, so that the corpse can be examined later.
570 Date: 24 December 1984 16:12-EST
571 From: Kent M Pitman <KMP @ MIT-MC>
572 Subject: MC being down today
575 Poor MC had 0 free pages in low core since early this morning and wasn't
576 doing anyone any good (wouldn't let anyone log in, etc). So I just reloaded
577 it, which seemed to work fine. Sorry I didn't have any idea what kind of
578 debugging info to offer since the machine was still running and other than
579 10,000 warnings about being out of free pages, it had nothing to say for
580 itself. If there's debugging data I could have taken from KLDCP, please let
581 me know and I'll get it next time if it loses this way again. -kmp
583 Date: Sun, 23 Dec 1984 10:59 EST
584 Message-ID: <PGS.12073740865.BABYL@MIT-OZ>
585 From: PGS%MIT-OZ@MIT-MC.ARPA
586 To: Peter Szolovits <PSZ@MIT-MC>
588 Subject: Heath 19 terminal control codes
589 In-reply-to: Msg of 22 Dec 1984 15:54-EST from Peter Szolovits <PSZ at MIT-MC>
591 This was the right place. Either I'll answer you next time I'm on MC, or you
592 can look at the strings in SYS; TS3TTY > if you feel brave. Yes, it does use
593 ANSI mode, but only for multiple line/char insert/delete. So does CRTSTY.
595 Date: 22 December 1984 15:54-EST
596 From: Peter Szolovits <PSZ @ MIT-MC>
597 Subject: Heath 19 terminal control codes
601 I would like to find out what the complete set of terminal commands is
602 that ITS sends to terminals that it thinks are H19's. In particular, I
603 know that some commands from the ANSI set are used as well as the
604 "standard" Heath command set. The Kermit H19 emulator doesn't support
605 $[nP and $[?2h, for example (though it does support $[nM and $[nL for
606 vertical scrolling), and I'd like to find out what such commands would
607 need to be added to Kermit to make it useable on MC. Sorry if this is
608 the wrong mailing list.
610 Date: 22 December 1984 10:19-EST
611 From: Christopher C. Stacy <CSTACY @ MIT-MC>
612 Subject: obscure bug in trivial feature
614 In-reply-to: Msg of 22 Dec 1984 02:52-EST from Christopher C. Stacy <CSTACY>
616 OK, the SYSDSK thing works now.
618 Date: Sat 22 Dec 84 03:58:10-EST
619 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
620 Subject: MC busted, fixed
622 cc: bug-its@MIT-MC.ARPA, JNC@MIT-XX.ARPA
624 MC croaked last this evening with a busted +20V brick in
625 the power supply. Not wanting the machine to be down forever, I
626 replaced it. Can you please cause DEC to replace the busted one
627 (sitting on top of the processor) with a fixed one and get that
629 This may explain some of the problems MC was having recently
630 with it halting after repetitively flashing the lights and not
631 saying anything. The power supply was for the memory in the
632 front end; the bootstrap ROM was seeing the disk controller get
633 a NXM on a test transfer to 0.
637 Date: 22 December 1984 02:57-EST
638 From: Christopher C. Stacy <CSTACY @ MIT-MC>
641 I think the SYSDSK code is probably mostly bankrupt.
642 I noticed it not quite working the other day, and so
643 there are some changes in it now, and it works a little
646 Date: 22 December 1984 02:52-EST
647 From: Christopher C. Stacy <CSTACY @ MIT-MC>
648 Subject: obscure bug in trivial feature
651 SYSDSK is not called from QSOCL3 when a :MOVE happens
652 since the input channel's file names are not looked
653 at (and the output file is in another directory).
655 Date: 22 December 1984 02:52-EST
656 From: Christopher C. Stacy <CSTACY @ MIT-MC>
657 Subject: obscure bug in trivial feature
660 SYSDSK is not called from QSOCL3 when a :MOVE happens
661 since the input channel's file names are not looked
662 at (and the output file is in another directory).
664 Date: 11 December 1984 19:05-EST
665 From: Glenn S. Burke <GSB @ MIT-MC>
666 Subject: highly secure systems
667 To: bug-swelling-itching-brain
670 Whoever brought up ML didn't notice that it didn't know the time.
671 Of course, said culprit probably was more familiar with the current
672 software running there than I, so knew that there was no point.
674 You see, you aren't allowed to get a ddt if the system doesn't know the
675 time. Running pdset becomes a bit difficult.
677 Date: 9 December 1984 21:10-EST
678 From: Alan Bawden <ALAN @ MIT-MC>
680 To: INFO-ITS @ MIT-MC
683 I have installed a 7LP: device on MC and ML for using the LN01 printer on
684 the 7th floor to generate simple hardcopy. Outputting to 7LP: opens a
685 connection to PREP (where the spooler runs) and transmits your text. For
686 example :COPY DSK:ALAN;ALAN LOGIN,7LP: makes hardcopy of my init file.
687 Reading from 7LP:.FILE. (DIR) produces a listing of the queue on PREP, so
688 you can type 7LP
\ 6 to DDT to see who's output is in front of yours.
690 Date: 8 December 1984 14:43-EST
691 From: Alan Bawden <ALAN @ MIT-MC>
692 Subject: Not about: RU-BLUE
694 cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC,
695 DEVON @ MIT-MC, GSB @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ
696 In-reply-to: Msg of 8 Dec 1984 07:38-EST from Ken Harrenstien <KLH>
698 Date: 8 December 1984 07:38-EST
699 From: Ken Harrenstien <KLH>
700 ... the binary-compare feature to SRCCOM ...
702 Oh yeah, I forgot about that feature! I used it a couple of times to
703 compare KS microcode load files when I made trivial changes that
704 theoretically changed only a single microinstruction. I must say, however,
705 that I have never had very much luck applying it to midas BIN files. There
706 always seems to be something you forget that causes all of the constants to
707 move. I guess its worth trying again in this case. I can only think of
708 two non-KS changes that have been made since I started, commenting one of
709 them out (a trivial fix) should cause everything to assemble into the same
712 Date: 8 December 1984 07:38-EST
713 From: Ken Harrenstien <KLH @ MIT-MC>
716 cc: GSB @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC,
717 DEVON @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ
719 Alan, would you believe that I added the binary-compare feature to
720 SRCCOM just so that I could quickly verify that ITS still assembled
721 into the same thing while I was adding all the NET/INET/TCP conditionals?
723 It was pretty handy, too. Anyway, the same technique might work for
724 ensuring that your own changes don't affect the KA/KL version of ITS.
726 Date: 8 December 1984 01:18-EST
727 From: Alan Bawden <ALAN @ MIT-MC>
728 Subject: BOJ device .UAI mode SIOT
731 An IOT on a BOJ channel open for input in block mode will return with the
732 input pointer not fully counted out when the user closes his JOB channel.
733 A SIOT on a BOJ channel open for input in unit ascii mode will simply hang
734 forever if the user closes his JOB channel before the byte count becomes 0.
735 The block mode behavior is what I would expect by analogy with reaching the
738 Date: 6 December 1984 14:00-EST
739 From: Alan Bawden <ALAN @ MIT-MC>
742 cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC,
743 DEVON @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ
744 In-reply-to: Msg of 6 Dec 1984 02:34-EST from Glenn S. Burke <GSB>
746 Date: 6 December 1984 02:34-EST
747 From: Glenn S. Burke <GSB>
748 Date: Thu, 6 Dec 84 00:02 EST
749 From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
750 ... I bet that ML has obsolete Internet routing tables for finding
751 someone to ask about the gateway to net 128.6.xx.aa. ML is also
752 probably unable to reach random other hosts. I'll fix this
755 Seems to me that we should make the most of ml's existence while it
756 still exists; it does arpa/chaos fairly well, after all. It has been
757 50 days since it's been booted, and i think it has had one parity stop
758 and one random retryable disk error stop in that time. I forget how
759 long it had been up before this uptime binge, but i think that too was
762 CStacy's observation about routing tables is correct. ML is running an
763 ancient version of ITS without Moon's fix to that code. If we really want
764 to make the most of ML, we should assemble a more modern version for it.
765 Of course I have made a great number of edits to the source of ITS in the
766 last few months, many having to do with the KA/KL conditionalizations, so
767 there is no guarantee that an ITS assembled from the current sources will
768 actually represent any improvements. (I have tried to make sure the
769 binaries for the KA and KL didn't change, but...)
771 Date: 6 December 1984 02:34-EST
772 From: Glenn S. Burke <GSB @ MIT-MC>
775 cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, DEVON @ MIT-MC,
776 MARTY%MIT-OZ @ SCRC-STONY-BROOK, Bug-MAIL%MIT-OZ @ SCRC-STONY-BROOK
778 Date: Thu, 6 Dec 84 00:02 EST
779 From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
780 BUG-MAIL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA
781 In-reply-to: <MARTY.12069151570.BABYL@MIT-OZ>
783 Date: 5 Dec 1984 22:49 EST (Wed)
784 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
785 I removed ML from the places that mail can be forwarded by.
786 (DOMAINS.TXT). I know that RU-BLUE is up and often send mail there.
788 MC can also reach RU-BLUE fine. ML is running the same mail software and has
789 the same host tables. I bet that ML has obsolete Internet routing tables for
790 finding someone to ask about the gateway to net 128.6.xx.aa. ML is also
791 probably unable to reach random other hosts. I'll fix this eventually.
793 Seems to me that we should make the most of ml's existence while it
794 still exists; it does arpa/chaos fairly well, after all. It has been
795 50 days since it's been booted, and i think it has had one parity stop
796 and one random retryable disk error stop in that time. I forget how
797 long it had been up before this uptime binge, but i think that too was
800 Date: Thu, 6 Dec 84 00:02 EST
801 From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
803 To: Martin David Connor <MARTY%MIT-OZ@SCRC-STONY-BROOK.ARPA>
804 Cc: Bug-MAIL%MIT-OZ@SCRC-STONY-BROOK.ARPA, BUG-ITS@MIT-MC.ARPA,
805 BUG-MAIL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA
806 In-reply-to: <MARTY.12069151570.BABYL@MIT-OZ>
808 Date: 5 Dec 1984 22:49 EST (Wed)
809 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
810 I removed ML from the places that mail can be forwarded by.
811 (DOMAINS.TXT). I know that RU-BLUE is up and often send mail there.
813 MC can also reach RU-BLUE fine. ML is running the same mail software and has
814 the same host tables. I bet that ML has obsolete Internet routing tables for
815 finding someone to ask about the gateway to net 128.6.xx.aa. ML is also
816 probably unable to reach random other hosts. I'll fix this eventually.
819 Date: Mon 26 Nov 84 20:22:20-EST
820 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
821 Subject: Re: MC hardware
822 To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
823 cc: FINN@MIT-XX.ARPA, TY@MIT-XX.ARPA, JNC@MIT-XX.ARPA
824 In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Sun 25 Nov 84 11:51:00-EST
826 I guess I'd consider this a non-optimal move. Since we have a
827 modest maount of memory on the machine now, I don't think it such a
828 big lose to switch off 25% of the memory until DEC can look at it.
829 There is some possibility that they aren't confused when they say they
834 Date: 25 November 1984 11:51-EST
835 From: Christopher C. Stacy <CSTACY @ MIT-MC>
838 cc: FINN @ MIT-XX, TY @ MIT-XX
840 On MC: memory boxes B and C are only online because their
841 override switches are on. They are too hot, I think.
843 Date: Fri, 23 Nov 84 20:46 EST
844 From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
846 To: Alan Bawden <ALAN@MIT-MC.ARPA>
847 Cc: BUG-ITS@MIT-MC.ARPA
848 In-reply-to: The message of 23 Nov 84 13:17-EST from Alan Bawden <ALAN at MIT-MC>
850 Someone turned the card over accidently I guess.
852 Date: 23 November 1984 13:17-EST
853 From: Alan Bawden <ALAN @ MIT-MC>
857 The Very Small Bulletin Board on MC told me to load NITS, but there isn't
858 any such file. I turned the card around to say just ITS which does exist.
859 I hope that this only means that thhe card was wrong and not that someone
860 accidentally deleted the system we are supposed to be running.
862 Date: 16 November 1984 03:09-EST
863 From: Alan Bawden <ALAN @ MIT-MC>
867 I just edited the TTYTYP file to remove the %TYMDM bits from all of the
868 ROLM lines. Experiment reveals that MC never seems to get told when such a
869 line is reconnected to a new terminal, thus setting this bit causes MC to
870 remember old, sometimes incorrect, terminal type information. Removing the
871 %TYMDM bits should cause ITS to reset the terminal type information
872 whenever the tty becomes free. This is better than the current situation,
873 where a user can be seriously confused, but since the ROLM -must- be able
874 to do this correctly, someone should really be looking into fixing it.
876 Date: 6 November 1984 15:48-EST
877 From: Alan Bawden <ALAN @ MIT-MC>
878 Subject: ITS Uptime Server?
881 In-reply-to: Msg of Tue 6 Nov 84 11:36-EST from Martin David Connor <MARTY%MIT-OZ at MIT-MC.ARPA>
883 Date: Tue 6 Nov 84 11:36-EST
884 From: Martin David Connor <MARTY at OZ>
885 Could someone implement an UPTIME chaos server for ITS?
889 Date: Tue 6 Nov 84 11:36-EST
890 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
891 Subject: ITS Uptime Server?
895 Could someone implement an UPTIME chaos server for ITS?
898 Date: 4 November 1984 14:42-EST
899 From: Alan Bawden <ALAN @ MIT-MC>
900 Subject: I just checked and he isn't blue...
901 To: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
903 Every once in a great while when I log in I discover that %TOMOR is not set
904 in my TTYOPT word. Since my LOGIN does nothing to change the default
905 setting of more processing it must be the case that normally ITS or DDT (or
906 PWORD?) turns it on. Well sometimes, given a blue Moon or something, it
909 Date: 30 October 1984 13:12-EST
910 From: Alan Bawden <ALAN @ MIT-MC>
913 In-reply-to: Msg of 30 Oct 1984 11:46-EST from Kenneth Byrd Story <STORY>
915 Date: 30 October 1984 11:46-EST
916 From: Kenneth Byrd Story <STORY>
918 I keep getting logged-out automatically by mc; what's the problem?
920 Well, as far as I know nothing on ITS ever causes you to be "logged-out
921 automatically". What exactly were the symptoms? Did you get a message
922 like: "Top level interrupt, tree detached"? Did you just get "MC ITS 1382
923 Console XX Free. HH:MM:SS"? When you reconnected did DDT offer to reattach
924 you to a detached tree or tell you that you had dead detached trees? How
925 were you reaching MC? (ROLM? Dialup? Chaosnet?)
927 Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 116836; Sun 28-Oct-84 17:38:27-EST
928 Date: Sun, 28 Oct 84 17:38 EST
929 From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
930 Subject: Getting Detached from MC
931 To: "Thomas A. Russ" <TAR@MIT-MC.ARPA>
932 cc: BUG-ITS@MIT-MC.ARPA, bede@MIT-XX.ARPA
933 In-Reply-To: The message of 12 Oct 84 13:42-EDT from Thomas A. Russ <TAR at MIT-MC>
934 Message-ID: <841028173837.9.MOON@EUPHRATES.SCRC.Symbolics>
936 Date: 12 October 1984 13:42-EDT
937 From: Thomas A. Russ <TAR @ MIT-MC>
939 I seem to be getting detached from MC regularly when I dial in over
940 the ROLM switch from my office. I wonder if this could be some problem
941 related to the ROLM system. I have DTI # 4303 connected to wall jack # 333
944 I don't know what line on MC is being called. The symptom is that my job
945 on MC gets a top level interrupt and is detached. The connection to MC
948 Even as I write this message, it happens again.
950 There used to be a bug, which may still be around, where a disconnected dialup
951 line got the bogus message "top level interrupt job detached" printed on it.
952 The job was detached because the dialup line was disconnected, not because it
953 got a top-level interrupt, but the logout/detach-message printer didn't know
954 that. Of course if the dialup line was really disconnected, no one sees the
955 erroneous message (except people spying on the dialup line, which is how this
956 was discovered originally).
958 I also believe that the Rolm switch has a bug where when you tell it to disconnect
959 it drops "carrier detect" several seconds before it stops passing bits through,
960 so you see some garbage bits.
962 What all this suggests is that maybe you are getting detached because the Rolm
963 switch is saying it's hanging up, or MC or its front-end pdp-11 incorrectly thinks
964 the Rolm is saying it's hanging up.
966 Date: 12 October 1984 15:26-EDT
967 From: Alan Bawden <ALAN @ MIT-MC>
968 Subject: Getting Detached from MC
970 cc: BUG-ITS @ MIT-MC, bede @ MIT-XX
971 In-reply-to: Msg of 12 Oct 1984 13:42-EDT from Thomas A. Russ <TAR>
973 Date: 12 October 1984 13:42-EDT
974 From: Thomas A. Russ <TAR>
975 ... The symptom is that my job on MC gets a top level interrupt and is
978 Well, it would be nice to know what interrupt it is that you are getting.
979 If it happens sometime when you don't need to reattach the tree, you might
980 leave it detached so that an ITS hacker can take a look at it.
982 Date: 12 October 1984 13:42-EDT
983 From: Thomas A. Russ <TAR @ MIT-MC>
984 Subject: Getting Detached from MC
985 To: BUG-ITS @ MIT-MC, bede @ MIT-XX
988 I seem to be getting detached from MC regularly when I dial in over
989 the ROLM switch from my office. I wonder if this could be some problem
990 related to the ROLM system. I have DTI # 4303 connected to wall jack # 333
993 I don't know what line on MC is being called. The symptom is that my job
994 on MC gets a top level interrupt and is detached. The connection to MC
997 Even as I write this message, it happens again.
1001 Date: 11 October 1984 15:30-EDT
1002 From: Alan Bawden <ALAN @ MIT-MC>
1003 Subject: Fair warning...
1004 To: BUG-ITS @ MIT-MC
1006 Until further notice everybody should be carefull about editing the sources
1007 for ITS itself, as I am in the process of conditionalizing it for the KS
1010 Date: Sun 7 Oct 84 16:20-EDT
1011 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
1012 Subject: 28 page host table too big?
1014 CC: BUG-TCP@MIT-MC, INFO-HOSTS@MIT-MC
1017 I fetched the latest NIC host table and installed it on MC,
1018 and suddenly I couldn't get a DDT from OZ. I backed out, renaming it
1019 to SYSBIN;HOSTS3 TOOBG?, and was then able to SUPDUP in and get a DDT without
1020 it barfing and saying there was a PWORD bug. I bet the bug is it couldn't
1023 Anyway, someone should look at PWORD.
1026 Date: 2 October 1984 22:22-EDT
1027 From: Ed Schwalenberg <ED @ MIT-MC>
1028 Subject: Don't try this at home kids...
1030 cc: BUG-ITS @ MIT-MC
1032 I was logged in from home as Alan did this, and got to see that my most-hated
1033 ITS bug has been fixed: when the system comes up from a crash, it no longer
1034 resets the baud rate on dialed-up lines. Thanks to whoever fixed this.
1036 PS. to Alan: Not coincidentally, I was doing :USET UPC when it crashed.
1038 Date: 2 October 1984 21:54-EDT
1039 From: Alan Bawden <ALAN @ MIT-MC>
1040 Subject: Don't try this at home kids...
1041 To: BUG-ITS @ MIT-MC
1043 Setting %PSPUB in your PC flags causes all kinds of havoc to break out on
1044 MC. The first time I did it tonight the system console printed:
1046 PAGE FAIL ERROR #1, PC = 772740,,301 JOB # 34, USR: ALAN J , PFW = 543000,,301
1048 When the job returned to DDT, DDT claimed it was getting a PURINS
1049 interrupt (which I didn't even think could happen on KLs!). I guess you
1050 can tell from this that I was actually setting all the flags...
1052 Since I couldn't see the system console from my office where I was doing
1053 this, I did it several times. Eventually I seem to have hung the
1054 microcode. A few controlled experiments later I crashed MC again with an
1055 error that contained the string "BAD PAGE FAIL WORD" (the decwriter was
1056 dropping so many characters thats about all I could see, I wish that sucker
1059 Date: 30 September 1984 21:10-EDT
1060 From: David C. Plummer <DCP @ MIT-MC>
1063 cc: BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, KLH @ SRI-NIC,
1066 Date: 25 September 1984 17:43-EDT
1067 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1070 The latest host table (including HSTNIC #384) is compiled and installed.
1071 The HOSTS3 compiler is "fixed".
1073 HOSTS3 hackers: The compiler does not do the sort of dynamic memory
1074 allocation I had assumed. I was therefore able to make some more room in
1075 the ITS version simply by moving where in core the table was being
1076 constructed. I didn't calculate how much room is left over for new code
1077 or tables, but the increase should hold us for a while. Of course, we
1078 are racing against the rate of host additions on the various networks in
1079 our table (the Internet, the Chaosnet, etc.) Hopefully by the time we
1080 run out it will be time to implement a hairy namespace system.
1082 This probably doesn't have a large place in our religion, but you
1083 could consider doing the conversion on a machine with a larger
1086 Date: 30 September 1984 02:01-EDT
1087 From: Alan Bawden <ALAN @ MIT-MC>
1088 Subject: Not critical
1089 To: BUG-ITS @ MIT-MC
1091 Giving string arguments to RENAME containing different directories and/or
1092 different devices should cause an error if the "from" device doesn't
1093 support that kind of renameing. I would suggest either %EBDDV or %ENSMD.
1094 Currently RENAME just ignores the device and directory in the "to"
1097 The same goes for the devices in the MLINK call.
1099 Note that it is not unreasonable to imagine a job device that supported
1100 cross-directory and cross-device renameing and linking, so the error
1101 returned really should be a function of the device.
1103 Date: 30 September 1984 01:30-EDT
1104 From: Glenn S. Burke <GSB @ MIT-MC>
1106 cc: BUG-ITS @ MIT-MC
1108 Date: 28 September 1984 19:13-EDT
1109 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1111 I was just detached because the BABYL I was running claims to have
1112 gotten a parity error. The message was top-level interrupt...
1113 I don't think the sysjob printed anything about parity errors,
1114 or even sweeped for them....I wonder if it was really a parity error...
1115 I wonder if this was what happenned to that guy the other day and
1118 Irrecoverable disk error in page mapping gives a parity error interrupt.
1120 Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 86001; Fri 28-Sep-84 15:03:14-EDT
1121 Date: Fri, 28 Sep 84 15:03 EDT
1122 From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
1123 Subject: M-X Copy File
1124 To: "Robert W. Kerns" <RWK@SCRC-RIVERSIDE.ARPA>
1125 cc: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>, BUG-FILE@MIT-MC.ARPA,
1126 BUG-ITS@MIT-MC.ARPA, BUG-LISPM@MIT-MC.ARPA
1127 In-Reply-To: <840928023221.8.RWK@HUDSON.SCRC.Symbolics>
1128 Message-ID: <840928150349.8.MOON@EUPHRATES.SCRC.Symbolics>
1130 Date: Friday, 28 September 1984, 02:32-EDT
1131 From: Robert W. Kerns <RWK at SCRC-YUKON>
1133 [I haven't looked at the code; I'm surmising what's
1134 going on from your message. But I think you've forgotten
1135 some of the more unfortunate parts of ITS!]
1139 Date: Saturday, 15 September 1984, 12:06-EDT
1140 From: David A. Moon <Moon at SCRC-TENEX>
1142 Date: 14 September 1984 21:00-EDT
1143 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1145 M-X Copy File does not preserve authors on ITS.
1146 It does preserve reference date (although maybe it should
1147 use DNRF instead of referencing the file to copy it) and
1150 This is because the routine CLOSIT in the FILE job sets the author of the
1151 file it just wrote to the user's HSNAME.
1152 HSNAME is the correct thing to set the file author to on ITS,
1153 because "file authors" are directories, not people.
1155 Yes, the problem is who sets it, not what it sets it to. It sets it at the time
1156 you close the file, even if you already set it yourself to something better, which
1157 is the source of the bug.
1159 Evidently it does this because
1160 the FILE job doesn't login under the name of the user who is using it.
1162 (1) Make the FILE job login under the right name.
1163 I don't think this makes any difference. Isn't the problem
1164 overwriting the explicit CHANGE-PROPERTIES that COPYF does?
1166 If the file job logged in under the right name then it wouldn't need to set the
1167 author itself at the wrong time, because ITS would set it to the right value at
1170 (2) Make ITS set the file author from the XUNAME instead of the UNAME and
1171 make the file job set its XUNAME to the user's name instead of to
1172 a copy of its UNAME.
1173 This would involve changing the UFD format, since
1174 currently the file author is just the MFD index
1177 How would changing the source of the person's name affect the UFD format?
1179 You're right that the file job would have to set its XUNAME to the person's HSNAME.
1181 (3) Make the FILE job set the author when it opens the file instead of
1183 I think this is right, and the easiest. Then if a
1184 CHANGE-PROPERTIES sets it to something else, it will
1189 Received: from SCRC-HUDSON by SCRC-YUKON via CHAOS with CHAOS-MAIL id 63942; Fri 28-Sep-84 02:32:03-EDT
1190 Date: Fri, 28 Sep 84 02:32 EDT
1191 From: "Robert W. Kerns" <RWK@SCRC-RIVERSIDE.ARPA>
1192 Subject: M-X Copy File
1193 To: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
1194 cc: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>, BUG-FILE@MIT-MC.ARPA,
1195 BUG-ITS@MIT-MC.ARPA, BUG-LISPM@MIT-MC.ARPA
1196 In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>
1197 Message-ID: <840928023221.8.RWK@HUDSON.SCRC.Symbolics>
1199 [I haven't looked at the code; I'm surmising what's
1200 going on from your message. But I think you've forgotten
1201 some of the more unfortunate parts of ITS!]
1203 Date: Saturday, 15 September 1984, 12:06-EDT
1204 From: David A. Moon <Moon at SCRC-TENEX>
1206 Date: 14 September 1984 21:00-EDT
1207 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1209 M-X Copy File does not preserve authors on ITS.
1210 It does preserve reference date (although maybe it should
1211 use DNRF instead of referencing the file to copy it) and
1214 This is because the routine CLOSIT in the FILE job sets the author of the
1215 file it just wrote to the user's HSNAME.
1216 HSNAME is the correct thing to set the file author to on ITS,
1217 because "file authors" are directories, not people.
1219 Evidently it does this because
1220 the FILE job doesn't login under the name of the user who is using it.
1222 (1) Make the FILE job login under the right name.
1223 I don't think this makes any difference. Isn't the problem
1224 overwriting the explicit CHANGE-PROPERTIES that COPYF does?
1226 (2) Make ITS set the file author from the XUNAME instead of the UNAME and
1227 make the file job set its XUNAME to the user's name instead of to
1228 a copy of its UNAME.
1229 This would involve changing the UFD format, since
1230 currently the file author is just the MFD index
1233 (3) Make the FILE job set the author when it opens the file instead of
1235 I think this is right, and the easiest. Then if a
1236 CHANGE-PROPERTIES sets it to something else, it will
1239 Date: 28 September 1984 19:13-EDT
1240 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1241 To: BUG-ITS @ MIT-MC
1243 I was just detached because the BABYL I was running claims to have
1244 gotten a parity error. The message was top-level interrupt...
1245 I don't think the sysjob printed anything about parity errors,
1246 or even sweeped for them....I wonder if it was really a parity error...
1247 I wonder if this was what happenned to that guy the other day and
1250 Date: 26 September 1984 01:22-EDT
1251 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1252 Subject: FOURTH is back online on MC
1253 To: TY @ MIT-XX, FINN @ MIT-XX
1254 cc: BUG-ITS @ MIT-MC, KMP @ MIT-MC, ALAN @ MIT-MC, PSZ @ MIT-MC,
1255 MEYER @ MIT-MC, GSB @ MIT-MC
1257 I didn't see any signs of the Trident disk repairman (John Holden?)
1258 here today, although I thought he was supposed to be come and work
1259 on unit #3 on MC (like I thought he was supposed to do a week ago
1260 when it broke.) Did he come?
1262 I put the disk back online and tried it out, and it seems to work.
1263 However, if the problem is intermittent, as soon as the drive gets
1264 hot again or whatever it will break and the system will crash etc.
1266 Date: 26 September 1984 01:01-EDT
1267 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1268 Sender: CSTAC0 @ MIT-MC
1271 cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
1272 In-reply-to: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden <ALAN>
1274 Date: 26 September 1984 00:54-EDT
1275 From: Alan Bawden <ALAN>
1277 Thats pretty strange given that that version of PWORD had been working on
1278 ML for months with no problems.
1279 Somehow I'm not very confident that we understand what is going on here...
1281 Yeah, but it was getting PDLOV interrupts and I increased the PDL size
1282 and now it works...what can I say? A new giant host table was
1283 installed today, so maybe PWORD's memory management is all shot to
1284 hell and I have somehow just masked it. I'll look at it in more
1285 detail soon. We should move this conversation to just BUG-PWORD.
1289 Date: 26 September 1984 01:01-EDT
1290 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1291 Sender: CSTAC0 @ MIT-MC
1294 cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
1295 In-reply-to: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden <ALAN>
1297 Date: 26 September 1984 00:54-EDT
1298 From: Alan Bawden <ALAN>
1300 Thats pretty strange given that that version of PWORD had been working on
1301 ML for months with no problems.
1302 Somehow I'm not very confident that we understand what is going on here...
1304 Yeah, but it was getting PDLOV interrupts and I increased the PDL size
1305 and now it works...what can I say? A new giant host table was
1306 installed today, so maybe PWORD's memory management is all shot to
1307 hell and I have somehow just masked it. I'll look at it in more
1308 detail soon. We should move this conversation to just BUG-PWORD.
1312 Date: 26 September 1984 00:54-EDT
1313 From: Alan Bawden <ALAN @ MIT-MC>
1316 cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
1317 In-reply-to: Msg of 26 Sep 1984 00:43-EDT from Christopher C. Stacy <CSTACY>
1319 Date: 26 September 1984 00:43-EDT
1320 From: Christopher C. Stacy <CSTACY>
1321 PWORD was losing on ML because it did not have a big enough stack, so
1324 Thats pretty strange given that that version of PWORD had been working on
1325 ML for months with no problems.
1327 Why the same version of this program does not run on both
1328 MC and ML is a mystery to me.
1330 Somehow I'm not very confident that we understand what is going on here...
1332 Date: 26 September 1984 00:43-EDT
1333 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1336 cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML
1337 In-reply-to: Msg of 26 Sep 1984 00:00-EDT from Alan Bawden <ALAN>
1340 PWORD was losing on ML because it did not have a big enough stack, so
1341 I fixed it. Why the same version of this program does not run on both
1342 MC and ML is a mystery to me.
1344 Also, I fixed the host-deletion (for "VAR GOOD") stuff long ago, and
1345 although the new code works on MC, it doesn't seem to work on ML: I
1346 can't delete random numbered hosts from the safe list over there.
1348 I'll have to look into these things, but I don't have time today.
1350 Date: 26 September 1984 00:00-EDT
1351 From: Alan Bawden <ALAN @ MIT-MC>
1353 To: BUG-PWORD @ MIT-MC
1354 cc: BUG-ITS @ MIT-MC
1356 Whenever you connect to ML these days PWORD says:
1358 Internal Error: Unknown Interrupt.
1359 Please do :BUG PWORD <description of the problem> ^C
1360 Or call 1-617-253-5891
1362 Even if nobody cares to fix this, I wonder if that phone number has any
1363 relationship to current reality...
1365 Date: 25 September 1984 17:43-EDT
1366 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1368 To: INFO-HOSTS @ MIT-MC
1369 cc: BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, KLH @ SRI-NIC,
1372 The latest host table (including HSTNIC #384) is compiled and installed.
1373 The HOSTS3 compiler is "fixed".
1375 HOSTS3 hackers: The compiler does not do the sort of dynamic memory
1376 allocation I had assumed. I was therefore able to make some more room in
1377 the ITS version simply by moving where in core the table was being
1378 constructed. I didn't calculate how much room is left over for new code
1379 or tables, but the increase should hold us for a while. Of course, we
1380 are racing against the rate of host additions on the various networks in
1381 our table (the Internet, the Chaosnet, etc.) Hopefully by the time we
1382 run out it will be time to implement a hairy namespace system.
1385 Date: 25 September 1984 15:14-EDT
1386 From: David C. Plummer <DCP @ MIT-MC>
1389 cc: BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC
1391 Date: 24 September 1984 19:35-EDT
1392 From: Alan Bawden <ALAN @ MIT-MC>
1394 MIT-MATH-HUB likes to start up a TELNET server on MC, cause it to open a
1395 STY, and then wait forever without outputing a ^Z (er, "call") to the STY.
1396 The TELNET job seem to be waiting to .IOT a 377 down its Chaos connection
1397 to MATH-HUB. This is a loss because it wastes a STY on MC for no good
1398 purpose. If you gun the TELNET job, MATH-HUB just reconnects and starts
1400 Well, my guess is that somebody's terminal over there ha a happy
1401 T key. I found a not-logged-in telnet job from Math Hub, so
1407 Gun down the old TELSER and wait for it to reconnect.
1408 Unfortunately, it didn't, so my experiment failed. If it did, I
1410 O (opens the connection, I think)
1411 S (soak data, I think, to see what it really is sending)
1412 Maybe somebody else will have better luck some other time.
1414 Date: 24 September 1984 19:35-EDT
1415 From: Alan Bawden <ALAN @ MIT-MC>
1417 To: BUG-ITS @ MIT-MC
1418 cc: BUG-MINITS @ MIT-MC
1420 MIT-MATH-HUB likes to start up a TELNET server on MC, cause it to open a
1421 STY, and then wait forever without outputing a ^Z (er, "call") to the STY.
1422 The TELNET job seem to be waiting to .IOT a 377 down its Chaos connection
1423 to MATH-HUB. This is a loss because it wastes a STY on MC for no good
1424 purpose. If you gun the TELNET job, MATH-HUB just reconnects and starts
1427 Date: 24 September 1984 13:07-EDT
1428 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1429 To: BUG-ITS @ MIT-MC
1430 cc: BUG-TCP @ MIT-MC, INFO-HOSTS @ MIT-MC
1432 Well, I think we are finally out of address space.
1433 New host tables cannot be compiled anymore because
1434 they are too massive. People should not try to
1435 compile any changes until I get back to you,
1436 hopefully with a solution.
1438 Date: 24 September 1984 12:18-EDT
1439 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1441 cc: BUG-ITS @ MIT-MC
1442 In-reply-to: Msg of 22 Sep 1984 23:32-EDT from Devon S. McCullough <DEVON>
1444 Date: 22 September 1984 23:32-EDT
1445 From: Devon S. McCullough <DEVON>
1448 What is %TDSTY and %TDUNF and whatever other innovations
1450 Are they documented?
1453 DDT doesn't know about these symbols, and they are not in BITS.
1454 Where did you see them?
1456 Date: 22 September 1984 23:32-EDT
1457 From: Devon S. McCullough <DEVON @ MIT-MC>
1458 To: BUG-ITS @ MIT-MC
1460 What is %TDSTY and %TDUNF and whatever other innovations have hit the scene?
1461 Are they documented?
1463 Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 83844; Sat 22-Sep-84 14:47:57-EDT
1464 Date: Sat, 22 Sep 84 14:46 EDT
1465 From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
1466 Subject: M-X Copy File
1467 To: "Bernard S. Greenberg" <BSG@SCRC-RIVERSIDE.ARPA>
1468 cc: CSTACY@MIT-MC.ARPA, BUG-FILE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
1469 In-Reply-To: <840921083548.6.BSG@CONCORD.SCRC.Symbolics>
1470 Message-ID: <840922144653.0.MOON@EUPHRATES.SCRC.Symbolics>
1472 Date: Friday, 21 September 1984, 08:35-EDT
1473 From: Bernard S. Greenberg <BSG at SCRC-TENEX>
1475 Date: Saturday, 15 September 1984, 12:06-EDT
1476 From: David A. Moon <Moon at SCRC-TENEX>
1478 Date: 14 September 1984 21:00-EDT
1479 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1481 M-X Copy File does not preserve authors on ITS.
1482 It does preserve reference date (although maybe it should
1483 use DNRF instead of referencing the file to copy it) and
1486 This is because the routine CLOSIT in the FILE job sets the author of the
1487 file it just wrote to the user's HSNAME. Evidently it does this because
1488 the FILE job doesn't login under the name of the user who is using it.
1490 (1) Make the FILE job login under the right name.
1491 (2) Make ITS set the file author from the XUNAME instead of the UNAME and
1492 make the file job set its XUNAME to the user's name instead of to
1493 a copy of its UNAME.
1494 (3) Make the FILE job set the author when it opens the file instead of
1497 Okay, let me try again.
1499 It doesn't know the right author at OPEN time.
1501 Yes it does. Suggestion #3 is that the FILE job set the author to the HSNAME
1502 at OPEN time, before the user has changed the author to something else, rather
1503 than at CLOSE time, after the user has changed the author to something else.
1505 Excuse me for not being ITSworthy enough, but if the FILE job has the
1506 option of (2), namely, setting the author to a quantity of its
1507 liking, why doesn't it remember the result of the PROPERTIES
1508 command sent at it for this purpose and set the author to what
1509 the user side WANTS it to be?
1511 Suggestion #2 refers to ITS, not the FILE job.
1513 Yes, I ought to have included the other logically possible suggestion:
1515 (4) Keep a copy of the author in the FILE job's memory, instead
1516 of in the file system. Set it to the HSNAME when the file is
1517 opened, set it to the new author when CHANGE-PROPERTIES is
1518 done, and copy it into the file system when the file is closed.
1519 Don't forget to change PROPERTIES, and maybe DIRECTORY-LIST, to
1520 return this private copy of the author instead of the one out
1523 Date: 22 September 1984 09:52-EDT
1524 From: David A. Moon <MOON @ MIT-MC>
1525 Subject: Moon's sabotage of ITS
1527 cc: BUG-ITS @ MIT-MC
1529 Date: 10 September 1984 18:37-EDT
1530 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1531 To: BUG-ITS @ MIT-MC
1533 The recent change in ITS where the SYS job is given 2 extra job
1534 slots worth of core (instead of just SYSB) causes the system
1535 to crash in CORS2 immediately when coming up.
1537 I had put a word count where a page count was expected, so the system
1538 job tried to get about two thousand pages when the system started up.
1539 Fixed in the source, but not reassembled since I wasn't physically
1542 Received: from SCRC-CONCORD by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 83372; Fri 21-Sep-84 08:34:39-EDT
1543 Date: Fri, 21 Sep 84 08:35 EDT
1544 From: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
1545 Subject: M-X Copy File
1546 To: Moon@SCRC-STONY-BROOK.ARPA, CSTACY@MIT-MC.ARPA, BUG-FILE@MIT-MC.ARPA
1547 cc: BUG-ITS@MIT-MC.ARPA
1548 In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>
1549 Message-ID: <840921083548.6.BSG@CONCORD.SCRC.Symbolics>
1551 Date: Saturday, 15 September 1984, 12:06-EDT
1552 From: David A. Moon <Moon at SCRC-TENEX>
1554 Date: 14 September 1984 21:00-EDT
1555 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1557 M-X Copy File does not preserve authors on ITS.
1558 It does preserve reference date (although maybe it should
1559 use DNRF instead of referencing the file to copy it) and
1562 This is because the routine CLOSIT in the FILE job sets the author of the
1563 file it just wrote to the user's HSNAME. Evidently it does this because
1564 the FILE job doesn't login under the name of the user who is using it.
1566 (1) Make the FILE job login under the right name.
1567 (2) Make ITS set the file author from the XUNAME instead of the UNAME and
1568 make the file job set its XUNAME to the user's name instead of to
1569 a copy of its UNAME.
1570 (3) Make the FILE job set the author when it opens the file instead of
1572 It doesn't know the right author at OPEN time.
1574 Excuse me for not being ITSworthy enough, but if the FILE job has the
1575 option of (2), namely, setting the author to a quantity of its
1576 liking, why doesn't it remember the result of the PROPERTIES
1577 command sent at it for this purpose and set the author to what
1578 the user side WANTS it to be?
1580 Date: Mon, 17 Sep 1984 09:35 EDT
1581 Message-ID: <PGS.12048286670.BABYL@MIT-OZ>
1582 From: PGS%MIT-OZ@MIT-MC.ARPA
1583 To: "Leigh L. Klotz" <KLOTZ@MIT-MC>
1584 Cc: ALAN@MIT-MC, BUG-ITS@MIT-MC, CSTACY@MIT-MC, FEATURE-ENTENNMANS@MIT-MC,
1585 ITS-LOVERS@MIT-MC, Moon%SCRC-RIVERSIDE@MIT-MC.ARPA
1586 Subject: How to copy files on ITS without trashing them
1587 In-reply-to: Msg of 17 Sep 1984 00:11-EDT from Leigh L. Klotz <KLOTZ at MIT-MC>
1589 Date: Monday, 17 September 1984 00:11-EDT
1590 From: Leigh L. Klotz <KLOTZ at MIT-MC>
1592 cc: BUG-ITS at MIT-MC, CSTACY at MIT-MC, FEATURE-ENTENNMANS at MIT-MC,
1593 ITS-LOVERS at MIT-MC, Moon at SCRC-RIVERSIDE
1594 Re: How to copy files on ITS without trashing them
1596 I always move files with TECO myself, <>'ing over the filenames.
1598 Hmm. I bring the machine down and copy them into the paging area with SALV.
1600 Date: 17 September 1984 00:11-EDT
1601 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
1602 Subject: How to copy files on ITS without trashing them
1604 cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, FEATURE-ENTENNMANS @ MIT-MC,
1605 ITS-LOVERS @ MIT-MC, Moon @ SCRC-RIVERSIDE
1606 In-reply-to: Msg of 16 Sep 1984 20:16-EDT from Alan Bawden <ALAN>
1608 I always move files with TECO myself, <>'ing over the filenames.
1610 Date: 16 September 1984 20:16-EDT
1611 From: Alan Bawden <ALAN @ MIT-MC>
1612 Subject: How to copy files on ITS without trashing them
1613 To: CSTACY @ MIT-MC, Moon @ SCRC-RIVERSIDE
1614 cc: BUG-ITS @ MIT-MC, FEATURE-ENTENNMANS @ MIT-MC, ITS-LOVERS @ MIT-MC
1615 In-reply-to: Msg of Sun 16 Sep 84 16:55 EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>
1617 Date: Sun, 16 Sep 84 16:55 EDT
1618 From: David A. Moon <Moon at SCRC-RIVERSIDE>
1619 The most convenient way, I have always found, is to use the DIRED
1622 My recent experience with the DIRED program is that it gets MPVs a lot. I
1623 always do such things by reading DIR:.FILE. (DIR) into an Emacs buffer and
1624 writing a TECO program to put together an XFILE for DDT to slurp up. I
1625 like this because it lets me run three different programs (the DIR device,
1626 Emacs and DDT), code in two obscure programming languages (TECO and DDT),
1627 and use two unrelated control-character-oriented command languages (Emacs
1628 and DDT). Using a JOB device as the first step gets the process started
1629 off on the right foot. If I can use a translation somehow, thats a big
1632 Sometimes I run the XFILE in a separate DDT job that I then
\e\e\10 so that I
1633 can watch the process using PEEK. This is especially entertaining when I
1634 are dealing with files using the ML device or the archive device. The fact
1635 that two jobs are typing on my console at the same time without having
1636 the operating system lose track of the position of my cursor is fun to
1639 If what needs to be done is particularly complex, it's always fun to write a
1640 little assembly language program to do the job. Preferably by depositing
1641 it directly into a job using DDT, although if I must stoop to using an
1642 assembler I can make up for the loss of face by writing a hairy MIDAS
1645 Date: 16 September 1984 18:56-EDT
1646 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1648 cc: BUG-ITS @ MIT-MC, BUG-LISPM @ MIT-MC
1649 In-reply-to: Msg of 16 Sep 1984 16:32-EDT from Alan Bawden <ALAN>
1651 Sigh....so much for trusting ZWEI...
1653 Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 61136; Sun 16-Sep-84 17:53:24-EDT
1654 Date: Sun, 16 Sep 84 17:50 EDT
1655 From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
1656 Subject: Source for :TIME
1657 To: Alan Bawden <ALAN@MIT-MC.ARPA>
1658 cc: BUG-ITS@MIT-MC.ARPA
1659 In-Reply-To: The message of 6 Sep 84 02:21-EDT from Alan Bawden <ALAN at MIT-MC>
1660 Message-ID: <840916175052.0.MOON@EUPHRATES.SCRC.Symbolics>
1662 Date: 6 September 1984 02:21-EDT
1663 From: Alan Bawden <ALAN @ MIT-MC>
1665 Well, I just retrieved source files for a bunch of ITS system programs from
1666 AI and ML backup tapes. I was able to find an OLD source for :TIME
1667 (version 35, version 39 is installed on MC right now...). The most up to
1668 date source probably lives only on DM backup tapes. Do we have a way to
1669 read DM backup tapes? Did anyone write such a tool when the DM users moved
1670 to XX? The good news is that as far as I can tell, TIME is the -only-
1671 program whose source file is trapped in that particular way...
1673 I don't know of any way to do it, but the format is so simple. Each file
1674 on the tape is a file (i.e. there are tape marks between the files) and
1675 just has some header information at the front.
1677 Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 61133; Sun 16-Sep-84 17:33:18-EDT
1678 Date: Sun, 16 Sep 84 17:30 EDT
1679 From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
1680 Subject: Top level interrupt
1681 To: Alan Bawden <ALAN@MIT-MC.ARPA>, CSTACY@MIT-MC.ARPA, BEN@MIT-MC.ARPA
1682 cc: BUG-ITS@MIT-MC.ARPA
1683 In-Reply-To: The message of 13 Sep 84 21:55-EDT from Alan Bawden <ALAN at MIT-MC>
1684 Message-ID: <840916173045.7.MOON@EUPHRATES.SCRC.Symbolics>
1686 Date: 13 September 1984 21:55-EDT
1687 From: Alan Bawden <ALAN @ MIT-MC>
1689 Date: 13 September 1984 19:44-EDT
1690 From: Christopher C. Stacy <CSTACY>
1691 Date: 13 September 1984 14:46-EDT
1692 From: Benjamin Kuipers <BEN>
1693 What is this nonsense about "Top level interrupt. Tree detached."
1694 No, it means that your top-level process (presumably HACTRN) got a
1695 fatal interrupt and died, detaching the entire tree. This could
1696 possibly be the result of a memory parity error.
1698 I looked around for such dead trees when I first got this bug report, but I
1699 didn't find any to figure out what happened to him. There have been no
1700 parity errors for the last day, so that couldn't be the reason.
1702 There used to be a buglet, which may still be there, related to this. When
1703 a dialup line hangs up the system job would type "Top level interrupt, tree
1704 detached" on it. Of course there's no one on the other end of a hung-up dialup
1705 line, so no one ever sees this message. But if it wasn't -really- hung up...
1707 Did this happen on a dialup line or a ROLM line by any chance?
1709 Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 81783; Sun 16-Sep-84 16:51:40-EDT
1710 Date: Sun, 16 Sep 84 16:55 EDT
1711 From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
1712 Subject: How to copy files on ITS without trashing them
1713 To: CSTACY@MIT-MC.ARPA
1714 cc: Alan Bawden <ALAN@MIT-MC.ARPA>, BUG-LISPM@MIT-MC.ARPA,
1716 In-Reply-To: The message of 16 Sep 84 16:32-EDT from Alan Bawden <ALAN at MIT-MC>
1717 Message-ID: <840916165519.5.MOON@EUPHRATES.SCRC.Symbolics>
1719 The most convenient way, I have always found, is to use the DIRED program.
1720 Not the Emacs one, the other one. It has a set of file-processing commands
1721 that take the star convention and it's fast. The only problem is that the
1722 right MOVE command has some obscure name like BC (don't trust my memory on this!)
1724 Date: 16 September 1984 16:32-EDT
1725 From: Alan Bawden <ALAN @ MIT-MC>
1727 cc: BUG-LISPM @ MIT-MC, BUG-ITS @ MIT-MC
1729 God DAMNIT! When I came in this morning MC had no free job slots because
1730 the system was completely full of dead TIME servers. After gunning about
1731 50 of them so that I could work I found out that all of the binary files on
1732 SYSNET, including the time server, had been trashed. You can probably
1733 guess why: when you use M-X Copy File from a Lisp Machine it must clobber
1734 36-bit binary files named BIN by DWIMing and treating them as 32-bit
1735 L-machine BIN files. I'll bet if there were any text files on the old TCP
1736 directory that contained imbedded ^M's they have been trashed as well by
1737 being copied in Lisp Machine character set mode. And I know you already
1738 noticed that Copy File clobbered all of the author information. You really
1739 should have used :MOVE rather than deluding yourself into thinking that a
1740 Lisp Machine could make the job easier.
1742 I reassembled the time server, but I leave it up to you to deal with the
1743 rest of the mess. I would advise retrieving the entire TCP directory and
1744 doing it again the right way.
1746 Date: 15 September 1984 17:15-EDT
1747 From: Ray Hirschfeld <RAY @ MIT-MC>
1749 To: BUG-ITS @ MIT-MC
1751 Because the new ROLM lines are specified as dialup lines in TTYTYP,
1752 typing ":ttyloc foo" produces a location of not "foo" but instead
1753 "Dialup: foo", a misfeature.
1755 Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 81650; Sat 15-Sep-84 12:03:45-EDT
1756 Date: Saturday, 15 September 1984, 12:06-EDT
1757 From: David A. Moon <Moon at SCRC-TENEX>
1758 Subject: M-X Copy File
1759 To: Christopher C. Stacy <CSTACY at MIT-MC>, BUG-FILE at MIT-MC
1760 cc: BUG-ITS at MIT-MC, BUG-LISPM at MIT-MC
1761 In-Reply-To: The message of 14 Sep 84 21:00-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
1762 Message-ID: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>
1764 Date: 14 September 1984 21:00-EDT
1765 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1767 M-X Copy File does not preserve authors on ITS.
1768 It does preserve reference date (although maybe it should
1769 use DNRF instead of referencing the file to copy it) and
1772 This is because the routine CLOSIT in the FILE job sets the author of the
1773 file it just wrote to the user's HSNAME. Evidently it does this because
1774 the FILE job doesn't login under the name of the user who is using it.
1776 (1) Make the FILE job login under the right name.
1777 (2) Make ITS set the file author from the XUNAME instead of the UNAME and
1778 make the file job set its XUNAME to the user's name instead of to
1779 a copy of its UNAME.
1780 (3) Make the FILE job set the author when it opens the file instead of
1784 Date: 14 September 1984 21:03-EDT
1785 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1786 To: BUG-ITS @ MIT-MC, INFO-HOSTS @ MIT-MC
1788 The TCP; directory on MC is now called "SYSNET;".
1790 Date: 14 September 1984 21:00-EDT
1791 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1792 Subject: M-X Copy File
1793 To: BUG-FILE @ MIT-MC
1794 cc: BUG-ITS @ MIT-MC, BUG-LISPM @ MIT-MC
1796 M-X Copy File does not preserve authors on ITS.
1797 It does preserve reference date (although maybe it should
1798 use DNRF instead of referencing the file to copy it) and
1801 Date: 14 September 1984 16:58-EDT
1802 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1803 To: BUG-ITS @ MIT-MC
1805 T-300 unit 3 was going offline spontanesouly, causing the
1806 system to hang on some operations. It should be fixed
1809 Date: 13 September 1984 21:55-EDT
1810 From: Alan Bawden <ALAN @ MIT-MC>
1811 Subject: Top level interrupt
1813 cc: BEN @ MIT-MC, BUG-ITS @ MIT-MC
1814 In-reply-to: Msg of 13 Sep 1984 19:44-EDT from Christopher C. Stacy <CSTACY>
1816 Date: 13 September 1984 19:44-EDT
1817 From: Christopher C. Stacy <CSTACY>
1818 Date: 13 September 1984 14:46-EDT
1819 From: Benjamin Kuipers <BEN>
1820 What is this nonsense about "Top level interrupt. Tree detached."
1821 No, it means that your top-level process (presumably HACTRN) got a
1822 fatal interrupt and died, detaching the entire tree. This could
1823 possibly be the result of a memory parity error.
1825 I looked around for such dead trees when I first got this bug report, but I
1826 didn't find any to figure out what happened to him. There have been no
1827 parity errors for the last day, so that couldn't be the reason. If he was
1828 neglecting to log in, PWORD gets a top level interrupt when your
1829 not-logged-in-time-limit expires rather than telling you why you are going
1830 away, but then it would have warned him in advance that this was likely to
1831 occur if he hadn't logged in. I hope there is no signifigance to the fact
1832 that what the SYSJOB really types is "Top level interrupt, tree detached"...
1834 Date: 13 September 1984 20:43-EDT
1835 From: Glenn S. Burke <GSB @ MIT-MC>
1838 cc: BUG-ITS @ MIT-MC, dab @ MIT-BORAX
1840 ok, i looked up %nsrcl -- cls received while in rfc received state.
1841 I made it treat this the same as %nscls, it now exits and says
1842 "Connection being closed by foreign host."
1844 Date: 13 September 1984 20:32-EDT
1845 From: David C. Plummer <DCP @ MIT-MC>
1848 cc: BUG-ITS @ MIT-MC
1850 Received: by mit-borax.ARPA (4.12/4.7)
1851 id AA03676; Thu, 13 Sep 84 16:15:39 edt
1852 From: dab@mit-borax (David A. Bridgham)
1853 Date: 13 Sep 1984 1615-EDT (Thursday)
1855 I recently wrote a supdup server for VAX UNIX running on TCP.
1856 This is currently running on MIT-BORAX. To test it I would supdup in
1857 from lisp machines or CCC. This forwards through MC with no problem.
1858 However, from MC if I type ":supdup borax" it sits for a while and says
1859 that the connection timed out without getting established. Could anyone
1861 It works for me. I get the error somebody else already reported
1862 by typing ^D to the login prompt. You are probably violating the
1863 logout protocol or something.
1865 Date: 13 September 1984 19:44-EDT
1866 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1868 cc: BUG-ITS @ MIT-MC
1869 In-reply-to: Msg of 13 Sep 1984 14:46-EDT from Benjamin Kuipers <BEN>
1871 Date: 13 September 1984 14:46-EDT
1872 From: Benjamin Kuipers <BEN>
1875 What is this nonsense about
1876 "Top level interrupt. Tree detached."
1877 This has happened to me twice in the last couple
1878 of hours. Have I been gunned?
1881 No, it means that your top-level process (presumably HACTRN) got a
1882 fatal interrupt and died, detaching the entire tree. This could
1883 possibly be the result of a memory parity error.
1885 Received: by mit-borax.ARPA (4.12/4.7)
1886 id AA03676; Thu, 13 Sep 84 16:15:39 edt
1887 From: dab@mit-borax (David A. Bridgham)
1888 Message-Id: <8409132015.AA03676@mit-borax.ARPA>
1889 Date: 13 Sep 1984 1615-EDT (Thursday)
1893 I recently wrote a supdup server for VAX UNIX running on TCP.
1894 This is currently running on MIT-BORAX. To test it I would supdup in
1895 from lisp machines or CCC. This forwards through MC with no problem.
1896 However, from MC if I type ":supdup borax" it sits for a while and says
1897 that the connection timed out without getting established. Could anyone
1901 Date: 13 September 1984 14:46-EDT
1902 From: Benjamin Kuipers <BEN @ MIT-MC>
1903 To: BUG-ITS @ MIT-MC
1905 What is this nonsense about
1906 "Top level interrupt. Tree detached."
1907 This has happened to me twice in the last couple
1908 of hours. Have I been gunned?
1911 Date: 12 September 1984 17:42-EDT
1912 From: Alan Bawden <ALAN @ MIT-MC>
1915 cc: BUG-ITS @ MIT-MC, CENT @ MIT-MC, CSTACY @ MIT-MC
1916 In-reply-to: Msg of 11 Sep 1984 13:12-EDT from Alan Bawden <ALAN>
1918 Date: 11 September 1984 13:12-EDT
1919 From: Alan Bawden <ALAN>
1920 Well .INFO. really is full to bursting, especially after I rescued some
1921 info files from ML. I suppose this is yet another excuse to create the
1922 SYSDOC directory and move a bunch of operating-system specific files there.
1923 The problem is that a fair number of them will want to leave links behind
1924 in .INFO. and links take up more directory room than a small file...
1926 OK, I created SYSDOC and moved a bunch of stuff there. .INFO. has a bit of
1927 room again. People who care are welcome to shuffle the documentation
1928 around more if they like. Just don't break anything.
1930 Date: 12 September 1984 08:57-EDT
1931 From: Bill Long <WJL @ MIT-MC>
1932 To: BUG-ITS @ MIT-MC
1934 When the Rolm switch tries 4991 to get MC, it times out.
1936 Date: 11 September 1984 22:40-EDT
1937 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
1938 Subject: 20th Anniversary of 36 Bits
1940 cc: BUG-ITS @ MIT-MC, CC.Clive @ UTEXAS-20
1941 In-reply-to: Msg of 11 Sep 1984 04:24-EDT from Pandora B. Berman <CENT>
1943 Don't forget Don Eastlake, DEE@CCA, I think.
1945 Date: 11 September 1984 13:12-EDT
1946 From: Alan Bawden <ALAN @ MIT-MC>
1949 cc: BUG-ITS @ MIT-MC, CENT @ MIT-MC
1950 In-reply-to: Msg of 11 Sep 1984 09:30-EDT from Christopher C. Stacy <CSTACY>
1952 Date: 11 September 1984 09:30-EDT
1953 From: Christopher C. Stacy <CSTACY>
1954 I moved it to .INFO. because I am usually have alot of trouble updating
1955 or re-assemble the ITS because the SYSTEM directory is full; I figured
1956 SYSTEM sources ought to live in SYSTEM and that info ought to live in
1959 Well .INFO. really is full to bursting, especially after I rescued some
1960 info files from ML. I suppose this is yet another excuse to create the
1961 SYSDOC directory and move a bunch of operating-system specific files there.
1962 The problem is that a fair number of them will want to leave links behind
1963 in .INFO. and links take up more directory room than a small file...
1965 Date: 11 September 1984 09:30-EDT
1966 From: Christopher C. Stacy <CSTACY @ MIT-MC>
1969 cc: BUG-ITS @ MIT-MC
1970 In-reply-to: Msg of 10 Sep 1984 23:50-EDT from Pandora B. Berman <CENT>
1972 I moved it to .INFO. because I am usually have alot of trouble updating
1973 or re-assemble the ITS because the SYSTEM directory is full; I figured
1974 SYSTEM sources ought to live in SYSTEM and that info ought to live in .INFO..
1976 Date: 11 September 1984 05:11-EDT
1977 From: Ed Schwalenberg <ED @ MIT-MC>
1978 Subject: Recent spate of crashes
1979 To: BUG-NAME @ MIT-MC
1980 cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
1982 NAME uses CORBLK to read in the ASCII file SYSENG;TTYTYP > and parses through
1983 it looking for the magic comments of the form ;T00 System Console, which it
1984 records in its database. It is under the mistaken impression that the file
1985 in core will be terminated by either nulls or ^C's; the documentation for
1986 CORBLK says no such thing. In fact, the difference between the length of a
1987 file as returned by FILLEN and the next page boundary is filled with garbage.
1988 I edited SYSTEM;TTYTYP > to create a copy that is "identical" to the previous
1989 version except that it has some nulls in the garbage that follows the last
1990 valid word. The bug should be really fixed in the source. I wonder how many
1991 other programs depend on this sort of thing?
1993 Date: 11 September 1984 04:24-EDT
1994 From: Pandora B. Berman <CENT @ MIT-MC>
1995 Subject: Re: 20th Anniversary of 36 Bits
1996 To: CC.Clive @ UTEXAS-20
1997 cc: BUG-ITS @ MIT-MC
1999 Date: Tue 11 Sep 84 02:44:10-CDT
2000 From: Clive Dawson <CC.Clive@UTEXAS-20.ARPA>
2001 Subject: Re: 20th Anniversary of 36 Bits
2002 To: CENT@MIT-MC.ARPA
2003 Thanks for the info and suggestions. We certainly have Greenblatt on
2004 the list. In fact I talked to him at AAAI here in Austin recently and
2005 there's a good chance we can get him to be on the panel at the
2006 Pioneer's Rountable session. I certainly would like to add other ITS
2007 people to the general list of invitees. Do you suppose you (or
2008 somebody else) could provide me with a list of such people, including a
2009 brief comment describing their connection to the 36-bit machines? I'll
2010 add Holloway (is he an original ITS developer?); also I have people
2011 like Gosper and Schroeppel of HAKMEM fame, and RMS. I suspect there
2012 are quite a few others.
2016 i'm not your best source for this, being a relative latecomer (i got to the
2017 lab in the middle of the lisp machine effort). try Tom Knight (TK@MC) --
2018 built the Knight TV system (was attached to the AI KA-10) for his undergrad
2019 thesis -- and Ken Harrenstein (KLH@MC or @NIC) -- wrote COMSAT, the ITS
2020 mailer, for his -- for a better list. i believe holloway was mostly a
2021 hardware hacker; he had a lot to do with the KA paging box (we apparently
2022 have a confusion with the TOPS10 people over who did paging first). RWG
2023 and RMS are reachable at those names by mail to MC, as is MOON, who wrote
2024 the ITS microcode for the KL; i don't know where schroeppel is these days,
2025 he's been gone from here for a while.
2026 i think we have the AI-6's chess trophies for MAKHAK 6 around somewhere;
2029 Date: 10 September 1984 23:50-EDT
2030 From: Pandora B. Berman <CENT @ MIT-MC>
2032 To: BUG-ITS @ MIT-MC
2034 i moved the ITS BUGS archive from .INFO.;, which was bursting, back to
2035 SYSTEM; where it apparently used to be, and where there is more space.
2036 i have no idea who thought it was a good idea to move it to .INFO. .
2038 Date: 10 September 1984 23:16-EDT
2039 From: Pandora B. Berman <CENT @ MIT-MC>
2040 Subject: 20th Anniversary of 36 Bits
2041 To: CC.Clive @ UTEXAS-20
2042 cc: BUG-ITS @ MIT-MC
2044 don't forget ITS, Greenblatt (RG@OZ, currently at LMI in cambridge),
2045 Holloway (H@MC, currently at Symbolics in cambrige), and all the other ITS
2046 hackers. in many ways ITS is STILL the best 10-family OS (we are now in
2047 the process of porting it to a 2020).
2049 Date: 10 September 1984 18:37-EDT
2050 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2051 To: BUG-ITS @ MIT-MC
2053 The recent change in ITS where the SYS job is given 2 extra job
2054 slots worth of core (instead of just SYSB) causes the system
2055 to crash in CORS2 immediately when coming up.
2057 Version 1378 is the same as 1377, but with the other new modules
2058 (INET, CORE, SYSJOB) incorporated. We also have the new TTYTYP
2059 file and the front-end files (IOELEV, BOOT11, etc) have been
2060 updated. This is all XITS. You can't boot the old version
2061 (ITS) in the normal fashion since one of the boot command files
2062 has been changed, so I hope it continues to work.
2064 Date: 6 September 1984 02:21-EDT
2065 From: Alan Bawden <ALAN @ MIT-MC>
2066 Subject: Source for :TIME
2068 cc: BUG-ITS @ MIT-MC
2070 Well, I just retrieved source files for a bunch of ITS system programs from
2071 AI and ML backup tapes. I was able to find an OLD source for :TIME
2072 (version 35, version 39 is installed on MC right now...). The most up to
2073 date source probably lives only on DM backup tapes. Do we have a way to
2074 read DM backup tapes? Did anyone write such a tool when the DM users moved
2075 to XX? The good news is that as far as I can tell, TIME is the -only-
2076 program whose source file is trapped in that particular way...
2078 Date: 5 September 1984 23:56-EDT
2079 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2080 To: BUG-ITS @ MIT-MC
2082 I gunned a tree which had jobs zorched by parity errors.
2083 The job state in PEEK went to *MULTIX and I thought it was
2084 trying to log out (since it usually does that after LOGOUT).
2085 It never went away and I could not UJOB it (job not found).
2086 I think it was blocked in a SLEEP call; I bashed its flush
2087 instruction to zero and it imediately went away.
2089 Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2640626229863307@MIT-MULTICS.ARPA>; 04 Sep 1984 15:17:09 edt
2090 Date: 04 Sep 84 15:00 +0200
2091 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
2092 Reply-to: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
2094 Subject: ITS for swedish KA10
2095 Message-ID: <68570@QZCOM>
2097 Thanks for your reply. I wasn't sure if my letters got through, or
2098 if I was addressing the right people. Our MAILNET connection is still
2099 somewhat experimental.
2101 The machine is a gift from DEC (or rather, we got it very cheap: 1 SEK
2102 which is approximately 15 cents), we have transported it from its previous
2103 home in Finland to Sweden, and are now planning to re-install it here.
2104 We have experienced hardware hackers who plan to build their own memory,
2105 paging box, and possibly other things too.
2110 3 MF10 in working condition
2111 1 MF10 with essentially a missing backplane
2112 2 DF10 data channel (18-bit)
2114 1 RP10 disk controller
2115 2 RH10 massbus controller
2116 1 TM10 tape controller
2118 1 DC10 with 32 lines
2119 1 BA10 hard copy controller
2125 Some of us work at the university computer center, so we have access
2126 to DEC10's and 20's where we can read tapes, cross-compile sources etc
2127 if necessary. We are grateful for any information you can give us,
2128 either through the network, or by ordinary mail to:
2130 Datorforeningen STACKEN
2132 Royal Institute of Technology
2139 Date: 3 September 1984 02:32-EDT
2140 From: Pandora B. Berman <CENT @ MIT-MC>
2141 Subject: we hear you
2142 To: Bjorn_Danielsson_QZ%QZCOM.MAILNET @ MIT-MULTICS
2143 cc: BUG-ITS @ MIT-MC
2145 Date: 27 Aug 84 20:48 +0200
2146 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
2150 Some friends of mine in the computer club STACKEN in Stockholm, Sweden
2151 want to get hold of an ITS operating system for their KA-10 computer.
2152 Could you tell me if it is possible to get the sources and
2153 documentation, including information about the extra paging hardware?
2156 hello out there. we are glad to hear that, somewhere else in the world, ITS
2157 lovers exist. it is theoretically possible, but technically a bit
2158 difficult, to give your friends the information they need to bring up ITS
2159 on their KA -- difficult because it's hard to assemble. we are working on
2160 trying to put together the right stuff for them, but it may take a while.
2161 any further information you can give on what their KA is like can only be
2162 helpful. please address futher communications on this subject to
2163 BUG-ITS@MC, so we will all see them.
2165 Date: 24 August 1984 21:29-EDT
2166 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2167 To: BUG-ITS @ MIT-MC
2169 SALV and exec DDT are write locked.
2171 Date: 20 August 1984 16:51-EDT
2172 From: David Vinayak Wallace <GUMBY @ MIT-MC>
2173 Subject: breaking ITS net connections
2174 To: mclure @ SRI-PRISM
2175 cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, SASW @ MIT-MC
2176 In-reply-to: Msg of Sun Aug 19 11:54:15 1984 from mclure at sri-prism
2178 From an ether tip typing the esacpe twice sends it through; I use the
2179 feature from the h19's in he basement of mjh all the time. But if you find
2180 that objectionable, why not change the escape character for your telnet to
2185 PS: Bug-its: on the other hand, since everybody has infinite free time, and
2186 isn't working on things like theses, what's wrong with .e.g.
\e\e2u
2187 logging out and detaching non-hardwired lines?
2189 Date: 19 August 1984 16:07-EDT
2190 From: Alan Bawden <ALAN @ MIT-MC>
2191 Subject: breaking ITS net connections
2192 To: mclure @ SRI-PRISM
2193 cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, SASW @ MIT-MC
2194 In-reply-to: Msg of Sun Aug 19 11:54:15 1984 from mclure at sri-prism
2196 Date: Sun Aug 19 11:54:15 1984
2197 From: mclure at sri-prism
2198 That's just the point. If I am using the Stanford ethernet to
2199 access score, there are certain instances where my escape will
2200 be robbed by a superior program and unavailable to telnet....
2202 Have you complained to anyone about this misfeature? Seems like your real
2203 problem is that you are forced to use a broken program to make your first
2204 hop over the network.
2206 I suppose we could put a command in DDT that guns its own telnet server...
2207 Always seems a shame to have to do things like this to compensate for other
2210 Date: 19 August 1984 15:44-EDT
2211 From: David C. Plummer <DCP @ MIT-MC>
2212 Subject: Re: breaking ITS net connections
2213 To: mclure @ SRI-PRISM
2214 cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC, SASW @ MIT-MC
2216 Date: Sun Aug 19 11:54:15 1984
2217 From: mclure@sri-prism
2219 That's just the point. If I am using the Stanford ethernet to
2220 access score, there are certain instances where my escape will
2221 be robbed by a superior program and unavailable to telnet. So
2222 I am unable to close the connection because I can't escape back
2223 to my telnet (without escaping to the ethernet tip, or whatever
2224 other medium happens to be in the way).
2226 Your user program is seriously misdesigned.
2228 My question still stands. Is there a way in ITS DDT to break
2229 a connection manually? If not, I think one should be added
2230 as everyone else has one and it has shown itself to be desirable.
2232 No, and NO!!! Alan's message shows that this is considered a win
2233 (by the ITS community, at least). If your user program doesn't
2234 have a command to forcibly disconnect you, I suggest you find
2235 another program, or stop using ITS. How would you get out if you
2236 started running a program that has super-image-input on so you
2237 couldn't even type c-Z (er, CALL).
2239 Received: by sri-prism.ARPA (4.12/4.16)
2240 id AA06644; Sun, 19 Aug 84 11:56:45 pdt
2241 Message-Id: <8408191856.AA06644@sri-prism.ARPA>
2242 Date: Sun Aug 19 11:54:15 1984
2243 From: mclure@sri-prism
2245 Cc: bug-its@mit-mc, sasw@mit-mc
2246 Subject: Re: breaking ITS net connections
2248 That's just the point. If I am using the Stanford ethernet to
2249 access score, there are certain instances where my escape will
2250 be robbed by a superior program and unavailable to telnet. So
2251 I am unable to close the connection because I can't escape back
2252 to my telnet (without escaping to the ethernet tip, or whatever
2253 other medium happens to be in the way).
2255 My question still stands. Is there a way in ITS DDT to break
2256 a connection manually? If not, I think one should be added
2257 as everyone else has one and it has shown itself to be desirable.
2261 Date: 19 August 1984 14:52-EDT
2262 From: Alan Bawden <ALAN @ MIT-MC>
2263 Subject: breaking ITS net connections
2265 cc: BUG-ITS @ MIT-MC, SASW @ MIT-MC, mclure @ SRI-PRISM
2267 Date: 19 August 1984 14:33-EDT
2268 From: Christopher C. Stacy <CSTACY>
2269 After logging out of ITS, why not close the connection from your end,
2270 perhaps by killing your TELNET program or issuing a "close" command
2271 to it? This will not leave any ITS job hanging.
2273 Perhaps he in confused by the fact that ITS doesn't close the connection
2274 IMMEDIATELY after you log out? If you wait a few minutes after you
2275 logout, your TELNET server will wake up and break the connection. We
2276 regard this as a feature; it gives you a chance to re-use the connection by
2277 typing ^Z (er, CALL). Its like having a hardwired line, except it times
2280 The same philosophy applies to the way ITS handles logging out from a
2281 dialup. Having this feature from dialups is actually even more of a win.
2282 It lets someone else log into the machine without having to re-dial the
2283 phone. The whole things seems like such a simple courtesy that I'm always
2284 surprised that the 20X wizards around here don't adopt the feature.
2286 Date: 19 August 1984 14:33-EDT
2287 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2288 Subject: breaking ITS net connections
2289 To: mclure @ SRI-PRISM
2290 cc: BUG-ITS @ MIT-MC, SASW @ MIT-MC
2291 In-reply-to: Msg of Sun 19 Aug 84 10:57:35-PDT from Stuart McLure Cracraft <G.MCLURE at SU-SCORE.ARPA>
2293 After logging out of ITS, why not close the connection from your end,
2294 perhaps by killing your TELNET program or issuing a "close" command
2295 to it? This will not leave any ITS job hanging.
2297 Date: Sun 19 Aug 84 10:57:35-PDT
2298 From: Stuart McLure Cracraft <G.MCLURE@SU-SCORE.ARPA>
2299 Subject: breaking ITS net connections
2300 To: bug-its@MIT-MC.ARPA, sasw@MIT-MC.ARPA
2301 Reply-To: mclure@sri-prism
2303 There seems to be no good way to break a net connection on the ITS
2304 machines. Perhaps there is one, but it is not obvious. TOPS-20 Arpanet
2305 machines usually break the connection upon logout. WAITS allows you
2306 to break it with the 'QUIT' command. Unix lets you break a net
2307 connection at the 'login:' prompt by typing ^D.
2309 Does ITS have an equivalent? I have left many jobs hanging/detached
2310 on MIT machines over the years whenever the telnet/modem/network
2311 configuration I am reaching it through does not allow an escape
2312 character of its own.
2319 Date: 18 August 1984 00:20-EDT
2320 From: David A. Moon <MOON @ MIT-MC>
2321 To: BUG-ITS @ MIT-MC
2323 looks like the source to sys1;ts time is lost.
2325 Date: 13 August 1984 22:00-EDT
2326 From: Pandora B. Berman <CENT @ MIT-MC>
2327 Subject: someone has this KA, you see...
2328 To: BUG-ITS @ MIT-MC
2330 [damned if i know why they asked me.]
2332 Date: 13 Aug 84 15:38 +0200
2333 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
2334 To: "Pandora B. Berman" <CENT@MIT-MC>
2337 Some friends of mine in the computer club STACKEN in Stockholm, Sweden
2338 want to get hold of an ITS operating system for their KA-10 computer.
2339 Could you tell me if it is possible to get the sources and documentation,
2340 including information about the extra paging hardware?
2344 Date: 11 August 1984 19:44-EDT
2345 From: Alan Bawden <ALAN @ MIT-MC>
2346 Subject: mc:crash;tcp .value
2348 cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, KLH @ MIT-MC
2349 In-reply-to: Msg of 11 Aug 1984 18:54-EDT from David A. Moon <MOON>
2351 Date: 11 August 1984 18:54-EDT
2352 From: David A. Moon <MOON>
2353 Date: 1 August 1984 18:12-EDT
2354 From: Alan Bawden <ALAN @ MIT-MC>
2355 Dunno who maintains the TCP server exactly, ...
2356 "The" TCP server? Guesswork reveals that it's the FTP/SMTP server...
2358 When I said "TCP server", I was talking about the Chaosnet TCP server. You
2359 know, the thing that gets loaded from DEVICE;CHAOS TCP. I didn't think too
2360 hard about how ambiguous that would sound in a bug note CC'd to BUG-TCP.
2362 Now a good question is how did I manage to mistake an FTP server for that?
2363 (Perhaps I need to think again about how the MOVE instruction works.)
2365 Date: 11 August 1984 18:54-EDT
2366 From: David A. Moon <MOON @ MIT-MC>
2367 Subject: mc:crash;tcp .value
2368 To: ALAN @ MIT-MC, KLH @ MIT-MC
2369 cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
2371 Date: 1 August 1984 18:12-EDT
2372 From: Alan Bawden <ALAN @ MIT-MC>
2373 To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
2375 Dunno who maintains the TCP server exactly, but I found a couple
2376 that had .VALUEd just now. I dumped one of them into CRASH;TCP .VALUE
2377 Seems to me that I'm seeing more of these guys .VALUEing recently
2378 so perhaps someone should take a look.
2380 "The" TCP server? Guesswork reveals that it's the FTP/SMTP server
2381 found in SYSBIN;FTPS BIN and it got an error from a FINISH system call
2382 in RETR05 called from the LIST command (look at location AUTPSY).
2383 I guess it's not robust to the user killing the connection while it's
2384 in the middle of listing a directory.
2386 I fixed this in the source but cannot reassemble FTPS because KLH's
2387 macros, which it uses, have been changed incompatibly. I found the
2388 file ksc;?out >, which purports to explain how to convert, but I can
2389 find no indication of how to convert OUTOPN in there so I'll leave
2390 this for KLH to fix or advise about. Presumably plenty of other
2391 programs are broken the same way.
2393 I didn't delete the CRASH file in case anyone else wants to look at it.
2395 Date: 9 August 1984 11:02-EDT
2396 From: David C. Plummer <DCP @ MIT-MC>
2397 Subject: rebooted hubs
2399 cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC, GUMBY @ MIT-MC, bug-minits @ MIT-OZ,
2402 Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Aug 84 19:11-EDT
2403 Date: 8 August 1984 19:04-EDT
2404 From: Alan Bawden <ALAN @ MIT-MC>
2405 In-reply-to: Msg of 8 Aug 1984 18:01-EDT from David C. Plummer <DCP>
2407 Date: 8 August 1984 18:01-EDT
2408 From: David C. Plummer <DCP>
2409 I think there are (undocumented) frobs that can follow the 034 of
2410 ITP to say this. If I can find it in the source in the next 4
2411 minutes, I'll let you know...
2413 Undocumented? fooey! Do :INFO ITS TTY SMART ESCAPE and you will find what
2414 you are looking for.
2415 It's not documented in the SUPDUP RFC (though I didn't look very
2416 hard, but I remember that it isn't documented there).
2418 Date: 8 August 1984 19:04-EDT
2419 From: Alan Bawden <ALAN @ MIT-MC>
2420 Subject: rebooted hubs
2422 cc: BUG-ITS @ MIT-MC, GUMBY @ MIT-MC, bug-minits @ MIT-OZ, DMS @ MIT-OZ
2423 In-reply-to: Msg of 8 Aug 1984 18:01-EDT from David C. Plummer <DCP>
2425 Date: 8 August 1984 18:01-EDT
2426 From: David C. Plummer <DCP>
2427 I think there are (undocumented) frobs that can follow the 034 of
2428 ITP to say this. If I can find it in the source in the next 4
2429 minutes, I'll let you know...
2431 Undocumented? fooey! Do :INFO ITS TTY SMART ESCAPE and you will find what
2432 you are looking for.
2434 Date: 8 August 1984 18:01-EDT
2435 From: David C. Plummer <DCP @ MIT-MC>
2436 Subject: rebooted hubs
2438 cc: BUG-ITS @ MIT-MC, DMS @ MIT-OZ, bug-minits @ MIT-OZ
2440 Date: 8 August 1984 17:14-EDT
2441 From: David Vinayak Wallace <GUMBY @ MIT-MC>
2442 In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel <DMS%MIT-OZ at MIT-MC.ARPA>
2444 It would gubbish your screen unless there were a way to tell ITS that
2445 typeout had occurred.
2447 I think there are (undocumented) frobs that can follow the 034 of
2448 ITP to say this. If I can find it in the source in the next 4
2449 minutes, I'll let you know...
2451 Here it is... gotta run...
2453 TYBCTL: CAIN A,^A ;^\^A => ALLOCATE OUTPUT CHARS.
2455 CAIN A,^Z ;^\^Z => ZERO ALLOCATION
2457 CAIN A,^I ;^\^I => INFINITY ALLOCATION
2459 CAIN A,^R ;^\^R => RESTART OUTPUT AT M.P. LEVEL.
2461 CAIN A,^P ;^\^P => SET CURSOR POSITION AND RESTART OUTPUT AT M.P. LEVEL.
2463 CAIN A,^\ ;^\^\ => INPUT A ^\.
2465 CAIN A,^C ;^\^C => SCREEN HAS BEEN SURREPTITIOUSLY CHANGED
2467 ;RETURN TO NORMAL ^\ STATUS BUT DON'T PASS ANY INPUT UP TO NORMAL INPUT LEVEL.
2469 Date: 8 August 1984 17:58-EDT
2470 From: David C. Plummer <DCP @ MIT-MC>
2471 Subject: rebooted hubs
2473 cc: BUG-ITS @ MIT-MC, DMS @ MIT-OZ, bug-minits @ MIT-OZ
2475 Date: 8 August 1984 17:14-EDT
2476 From: David Vinayak Wallace <GUMBY @ MIT-MC>
2477 In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel <DMS%MIT-OZ at MIT-MC.ARPA>
2479 It would gubbish your screen unless there were a way to tell ITS that
2480 typeout had occurred.
2482 I think there are (undocumented) frobs that can follow the 034 of
2483 ITP to say this. If I can find it in the source in the next 4
2484 minutes, I'll let you know...
2486 Date: 8 August 1984 17:14-EDT
2487 From: David Vinayak Wallace <GUMBY @ MIT-MC>
2488 Subject: rebooted hubs
2490 cc: BUG-ITS @ MIT-MC, bug-minits @ MIT-OZ
2491 In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel <DMS%MIT-OZ at MIT-MC.ARPA>
2493 It would gubbish your screen unless there were a way to tell ITS that
2494 typeout had occurred.
2496 Date: 7 August 1984 19:02-EDT
2497 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
2498 Subject: chuname broken
2500 cc: BUG-ITS @ MIT-MC
2501 In-reply-to: Msg of 5 Aug 1984 22:31-EDT from Richard Mlynarik <MLY>
2503 Are you sure that you weren't already logged in (or detached) as
2504 MLY when you tried doing :CHUNAME MLY? That's what's usually happening
2505 when you get the ? response.
2507 Date: 5 August 1984 23:42-EDT
2508 From: Alan Bawden <ALAN @ MIT-MC>
2509 Subject: chuname broken
2511 cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
2512 In-reply-to: Msg of 5 Aug 1984 22:31-EDT from Richard Mlynarik <MLY>
2514 Date: 5 August 1984 22:31-EDT
2515 From: Richard Mlynarik <MLY>
2517 logged in as anything, and typing ":chuname mly" at ddt
2518 gets me the right "--massacre and reset--" but confirming
2519 with a space just gets me a "?" and my uname is still the same.
2521 This bug report seems to be saying that you were unable to get CHUNAME to
2522 work under any circumstances. Funny, because I can't seem to get it to
2523 fail under any circumstances. I notice that you sent this bug report
2524 logged in as "MLY0", perhaps you can tell me what other MLY's were logged
2525 in at the time, what you were logged in as, and what you tried to CHUNAME
2528 Date: 5 August 1984 23:10-EDT
2529 From: Devon S. McCullough <DEVON @ MIT-MC>
2530 To: BUG-ITS @ MIT-MC
2532 emacs got a .val 0; 35572>>move 1,3 1/17450 3/24
2533 when I tried to find a file on HS:
2535 Date: 5 August 1984 22:31-EDT
2536 From: Richard Mlynarik <MLY @ MIT-MC>
2537 Sender: MLY0 @ MIT-MC
2538 Subject: chuname broken
2539 To: BUG-ITS @ MIT-MC
2541 logged in as anything, and typing ":chuname mly" at ddt
2542 gets me the right "--massacre and reset--" but confirming
2543 with a space just gets me a "?" and my uname is still the same.
2545 Date: 5 August 1984 16:13-EDT
2546 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2547 To: BUG-ITS @ MIT-MC
2549 The NETWRK package only defines a single Chaosnet packet buffer,
2550 so you can only hack on connection at a time.
2552 Date: 1 August 1984 18:12-EDT
2553 From: Alan Bawden <ALAN @ MIT-MC>
2554 To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
2556 Dunno who maintains the TCP server exactly, but I found a couple
2557 that had .VALUEd just now. I dumped one of them into CRASH;TCP .VALUE
2558 Seems to me that I'm seeing more of these guys .VALUEing recently
2559 so perhaps someone should take a look.
2561 Date: 1 August 1984 13:42-EDT
2562 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2563 Subject: EMACS not working on MC, and BUG-EMACS broken
2565 cc: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC
2566 In-reply-to: Msg of 1 Aug 1984 13:12-EDT from Ronald I. Greenberg <RIG>
2569 The mail receipt you received from the COMSAT only indicates that a
2570 there is an addressee (ECARTER@OFFICE-2) who is a member of the
2571 BUG-EMACS mailing list, but who in fact does not exist.
2572 Your message was delivered to all the other BUG-EMACS people.
2574 I just tried EMACS on MC, and it is working fine.
2576 Date: 1 August 1984 13:12-EDT
2577 From: Ronald I. Greenberg <RIG @ MIT-MC>
2578 Sender: RIG0 @ MIT-MC
2579 To: BUG-ITS @ MIT-MC
2581 :bug emacs didn't work as evidenced by the following returned mail.
2582 COMSAT@MIT-MC 08/01/84 12:42:23 Re: Msg of Wednesday, 1 August 1984 12:39-EDT
2584 Queued: JSL at MIT-MULTICS, Carter at RUTGERS
2585 FAILED: ECARTER at OFFICE-2; Recipient name apparently rejected.
2586 Last reply was: {550 No such mailbox here}
2587 Failed message follows:
2589 Date: 1 August 1984 12:39-EDT
2590 From: Ronald I. Greenberg <RIG @ MIT-MC>
2591 To: BUG-EMACS @ MIT-MC
2593 A little while ago, while logged on to MC I found EMACS working improperly.
2594 For example, c-E, m-F, and m-B were going to incorrect places. One time m-F
2595 took me backwards one character! I would be interested in finding out what
2600 By the way, I suppose the emacs problem might really be a problem with the terminal.
2601 I will try to check this out.
2603 Date: Fri, 27 Jul 1984 11:50 EDT
2604 Message-ID: <PGS.12034679855.BABYL@MIT-OZ>
2605 From: PGS%MIT-OZ@MIT-MC.ARPA
2606 To: "Christopher C. Stacy" <CSTACY@MIT-MC>
2608 Subject: front end 11
2609 In-reply-to: Msg of 27 Jul 1984 03:53-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
2611 Date: Friday, 27 July 1984 03:53-EDT
2612 From: Christopher C. Stacy <CSTACY at MIT-MC>
2614 MC stopped answering the dialups in the afternoon, and when I came in
2615 long afterwards the system was apparently "dead"; it was not answering
2616 anything. It appeared to be running though. Unfortunately the front-end
2617 11 seems to have dropped dead; I could not get to DDT or even 11DDT. I
2618 used the disk bootload button to get the 11 back, and stopped and dumped
2619 ITS to CRASH;ITS 11HUNG in case anyone wants it. Then I cold booted.
2621 Don't blame me. I wasn't installed.
2623 Date: 27 July 1984 03:53-EDT
2624 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2625 Subject: front end 11
2626 To: BUG-ITS @ MIT-MC
2629 MC stopped answering the dialups in the afternoon, and when
2630 I came in long afterwards the system was apparently "dead";
2631 it was not answering anything. It appeared to be running
2632 though. Unfortunately the front-end 11 seems to have dropped
2633 dead; I could not get to DDT or even 11DDT. I used the disk
2634 bootload button to get the 11 back, and stopped and dumped
2635 ITS to CRASH;ITS 11HUNG in case anyone wants it. Then I cold
2638 Date: 25 July 1984 16:56-EDT
2639 From: Alan Bawden <ALAN @ MIT-MC>
2641 To: BUG-ITS @ MIT-MC
2642 In-reply-to: Msg of 25 Jul 1984 16:41-EDT from J. Noel Chiappa <JNC>
2644 Noel's message reminds me... Last night I moved the various notes and things
2645 that used to be taped to the inside front door of the first MF10 into the
2646 first MH10. Now most of that information actually has little to do with
2647 the MH10s, but I figured it was usefull to know what information we -used-
2648 to keep there in case anone ever decides to post some modern truth in that
2649 location. (I marked them as out of date in a big red pen.)
2651 Date: 25 July 1984 16:41-EDT
2652 From: J. Noel Chiappa <JNC @ MIT-MC>
2654 To: BUG-ITS @ MIT-MC
2656 Since the whole Ampex seems to be online now, next time someone
2657 rebuilds the system they should change CONFIG > to allow MC to use all
2658 of the 2MW of memory on the system. Right now half the AMPEX is not
2661 Date: 20 July 1984 04:56-EDT
2662 From: Ken Harrenstien <KLH @ MIT-MC>
2663 Subject: ITS seemed to be looping
2665 cc: BUG-ITS @ MIT-MC
2667 Well, I am too tired to pursue it further tonight, but the fragments
2668 appear to have come from host GYMBLE by way of BBN-MILNET-GW;
2669 it had several SMTP connections open at the time. This doesn't help
2670 find the bug (for that it takes a lot of grovelling through the
2671 datagram buffers) but may serve as a warning signal.
2673 Date: 20 July 1984 04:10-EDT
2674 From: Ken Harrenstien <KLH @ MIT-MC>
2675 Subject: ITS seemed to be looping
2677 cc: BUG-ITS @ MIT-MC
2679 Ignore my query about ITS version to :SL. I've been doing too much
2680 Unix ADB'ing and forgot ITS does the right thing as usual.
2682 Date: 20 July 1984 04:04-EDT
2683 From: Ken Harrenstien <KLH @ MIT-MC>
2684 Subject: ITS seemed to be looping
2686 cc: BUG-ITS @ MIT-MC
2688 Keep CRASH;WHAT HEY around for a while. If your PC trace is right, it
2689 was looping in the IP fragment re-assembly code, which has in the
2690 past been a notorious source of bugs (since it is both very hard to
2691 understand and very seldom exercised). Can you tell me what version
2692 of ITS it was running, so I can :SL the symbols from the right
2693 file on .; (and please continue to take more crash dumps any time
2694 this happens, since it is unlikely that the bug can be determined
2695 just from one example).
2697 By the way, it makes sense that clock interrupts would be off, since
2698 this code runs at IMP interrupt level.
2700 Oh boy, time to play with PEEK autopsy mode again!
2702 Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 65152; Mon 16-Jul-84 23:06:56-EDT
2703 Date: Mon, 16 Jul 84 23:06 EDT
2704 From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
2705 Subject: Ampex memory
2707 cc: bug-its@MIT-MC.ARPA
2708 Message-ID: <840716230650.0.MOON@EUPHRATES.SCRC.Symbolics>
2710 Some (most? all?) of the ports on the Ampex memory don't work, I think
2711 because Ampex's transceiver cards for the DEC memory bus are flakey.
2712 That's probably why the cabling is weird. The interleaving options
2713 are all very confusing, especially since the cases that are not
2714 supposed to work actually do seem to work. I talked about this with
2715 CStacy this afternoon some. I think the bottom line is that you can
2716 put the system into 4-way interleave mode if all of ports 4 through 7
2717 (or wherever the processor is plugged into) on the Ampex work, but if
2718 any of those ports are broken and can't be used you have to use 2-way
2719 interleave mode so the Ampex will still see all memory requests. It's
2720 also unclear whether 4-way mode is better since it should be only a few
2721 percent faster in the DEC memory (if I remember a measurement I made in
2722 about 1976 correctly) and should be substantially slower in the Ampex
2723 memory, since it can only do one operation at a time (two at a time
2724 when both sectors are working).
2726 MC:MOON;PERF > will measure various things but I don't know how you'll
2727 get the numbers for the MF10 configuration to compare against.
2730 Date: 16 July 1984 15:45-EDT
2731 From: J. Noel Chiappa <JNC @ MIT-MC>
2733 To: BUG-ITS @ MIT-MC
2735 The MH10's are installed. They are 8 port (dual controller)
2736 boxes, so KBUS0-3 are bussed through all four boxes on port 7-4 (and
2737 thence to the Ampex ports 7-4). The DL10 is port 0, the RP10 is port
2738 1, and the TM10 is port 2. (Don't ask why it's different from the
2739 Ampex). The TM10 bus is terminated on the last DEC box, as before, but
2740 the cable to the AMPEX is right there if anyone wants to plug it in
2741 for some reason. The MH10's are currently in 4-way interleave in the
2742 hardware. It looks like the processor is running two way interleaved;
2743 now that we have this wonderful working 4-way memory maybe we could
2745 Also, the AMPEX just got a write parity error on port 5. if
2746 this happens a lot someone should think about reseating the cables,
2747 etc. Finally, is there some sort of meter we can use to see if the
2748 machine is running faster?
2750 Date: 16 July 1984 01:05-EDT
2751 From: Alan Bawden <ALAN @ MIT-MC>
2752 To: BUG-ITS @ MIT-MC
2754 CRASH;10JUL CRASH just happened again in exactly the same way.
2755 A comsat RESTRT job tried to rename STATS < to OSTATS >, and on the
2756 way out of the call it was noticed that there were still some locks locked.
2758 ALAN@MIT-ML 07/14/84 06:45:02
2759 To: (BUG ITS) at MIT-ML
2760 After remaining up for 13 days without even a memory error,
2761 ML finally crashed just now because of a software bug. At QSOC3E+15, on its way
2762 out of the system after trying to do an MLINK, an entry in QSNNR went
2763 negative. A dump of the same problem was taken by GSB a few weeks ago
2764 and can be found in MC:CRASH;QSOC3E +17@ML if anyone want to look for
2768 Date: 14 July 1984 03:42-EDT
2769 From: Alan Bawden <ALAN @ MIT-MC>
2770 Subject: ITS seemed to be looping
2771 To: BUG-ITS @ MIT-MC
2772 In-reply-to: Msg of Sat 14 Jul 84 02:43 EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
2774 Date: Sat, 14 Jul 84 02:43 EDT
2775 From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
2778 Raise switch 0 (the switch 0 on the left). If this goes to DDT, it's
2779 taking clock interrupts.
2781 Yeah, I forgot to mention that I tried that, and nothing happened.
2783 Hit Break and type PC <return>. If I remember correctly, you can
2784 read the PC this way without halting the machine. There are some
2785 other status-type commands; PCF is the PC flags, PI is the interrupt
2788 OK, well it happened again which gave me a chance to try out the things I
2789 remembered from this message (wish I had made hardcopy as soon as I got
2790 it!). Repeated applications of <Break>PC<Return> showed it looping in the
2791 general vicinity of IPRD61 (assuming it was looping in the system, which is
2792 reasonable to assume if it isn't taking clock ints!). This is a routine in
2793 INET which looks to me like it might well loop given the right gubbish in
2796 Perhaps with that information someone can take a look at the crash dump I
2797 took (still in CRASH;WHAT HEY) and figure out what caused this.
2799 Date: 14 July 1984 03:27-EDT
2800 From: Alan Bawden <ALAN @ MIT-MC>
2801 Subject: Its a mystery to me.
2802 To: BUG-ITS @ MIT-MC
2803 cc: BUG-DDT @ MIT-MC
2805 How come when a job gets a parity error its superior DDT always gets a
2806 %PIB42? DDT seemingly get it simultaneous with the interrupt from the
2807 inferior, but thats what you would expect of a real B42, right? There
2808 doesn't seem to be anything wrong with what DDT is doing as far as I can
2811 Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60736; Sat 14-Jul-84 02:40:13-EDT
2812 Date: Sat, 14 Jul 84 02:43 EDT
2813 From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
2814 Subject: ITS seemed to be looping
2815 To: alan@MIT-MC.ARPA
2816 Cc: bug-its@MIT-MC.ARPA
2820 Raise switch 0 (the switch 0 on the left). If this goes to DDT, it's
2821 taking clock interrupts.
2823 Hit Break and type PC <return>. If I remember correctly, you can read
2824 the PC this way without halting the machine. There are some other status-type
2825 commands; PCF is the PC flags, PI is the interrupt status.
2827 Hit Break and type SP <return>. This stops the machine cleanly (between
2828 instructions). If this works, the microcode isn't looping. Now you can
2829 get the PC then type DDT (or ST 774000) to get into DDT and decode that PC.
2831 If the microcode is looping the SM command will restart it. This also does
2832 nasty things like resetting the I/O bus. I think it preserves the PC though.
2834 There is a command file, J KLHUNG, which prints out everything in sight. 90%
2835 of what it prints is worthless, but it includes micro and macro PCs.
2837 I believe there is a piece of paper taped to the machine that tells you to
2838 do J KLHUNG. Of course there are a lot of pieces of paper taped to the machine!
2841 Date: 14 July 1984 01:50-EDT
2842 From: Alan Bawden <ALAN @ MIT-MC>
2843 To: BUG-ITS @ MIT-MC
2845 ITS died in a new way (for me) just now. The immediate symptoms were what
2846 I would expect if the microcode was looping. (No lights on any box were
2847 blinking, nothing was visibly doing anything, the system console had not
2848 printed anything to indicate anything was wrong.) I thrashed around a bit
2849 trying to find the KLDCP documentation to see if I could learn anything
2850 about what the processor was doing. When Taft found me a copy I was
2851 frustrated enough that I just took a crash dump (yeah, I know, thats
2852 probably worthless, its in CRASH;WHAT HEY) and reloaded it. So what should
2855 Date: 11 July 1984 23:30-EDT
2856 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2857 Subject: ml doesn't get updates
2859 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
2860 In-reply-to: Msg of 11 Jul 1984 23:16-EDT from Pandora B. Berman <CENT>
2862 Aha, ML had the old version of INQUIR so that updates from MC went to
2863 ML, but ML didn't update itself! I installed the new one.
2865 Date: 11 July 1984 23:16-EDT
2866 From: Pandora B. Berman <CENT @ MIT-MC>
2867 Subject: ml doesn't get updates
2869 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
2871 Date: 9 July 1984 16:02-EDT
2872 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2873 Subject: ml doesn't get updates
2875 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
2876 In-reply-to: Msg of 9 Jul 1984 06:18-EDT from Pandora B. Berman <CENT>
2877 ML should be getting updates; when it came back up I put
2878 it back in the list of machines to update and tested it.
2879 It worked for me; I'll look to see what is going wrong.
2881 i looked at the relevant STATS files. running INQUIR on ML creates a piece
2882 of mail to INQUPD at MC; this reaches MC and is only dealt with locally.
2883 at neither juncture is an INQUPD performed on ML.
2885 Date: 11 July 1984 14:33-EDT
2886 From: Alan Bawden <ALAN @ MIT-MC>
2887 To: BUG-ITS @ MIT-MC
2888 In-reply-to: Msg of 10 Jul 1984 08:50-EDT from Patrick G. Sobalvarro <PGS>
2890 Date: 10 July 1984 08:50-EDT
2891 From: Patrick G. Sobalvarro <PGS>
2892 I found MC bug-halted. I dumped it to .;10JUL CRASH; dunno if anyone
2893 wants to poke at it.
2895 Actually its in CRASH;10JUL CRASH. While returning from a RENAME a job
2896 discovered it still had some locks locked. MC was parity erroring a bit at
2897 the time. Should we worry about this harder?
2899 Date: 11 July 1984 11:27-EDT
2900 From: J. Noel Chiappa <JNC @ MIT-MC>
2901 Subject: SECOND: hardwarily back
2902 To: BUG-ITS @ MIT-MC
2904 Drive 1 is fixed, but I can't remember how to invoke UCOP
2905 to bring the directories over. Someone should bring the system down
2906 and bring it back up with SECOND: around.
2908 Date: Tue, 10 Jul 1984 21:10 EDT
2909 Message-ID: <GLR.12030325365.BABYL@MIT-OZ>
2910 From: Jerry Roylance <GLR@MIT-OZ>
2911 To: CHAOS-MAINT@MC, BUG-ITS@MC
2915 Subnet 6 was broken at the MC bulkhead (return of the bad UHF connectors).
2917 The MC transceiver's power connector was also broken; everything is
2920 Date: 10 July 1984 08:50-EDT
2921 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
2922 To: BUG-ITS @ MIT-MC
2924 I found MC bug-halted. I dumped it to .;10JUL CRASH; dunno if anyone
2925 wants to poke at it.
2927 Date: 10 July 1984 00:49-EDT
2928 From: Alan Bawden <ALAN @ MIT-MC>
2930 cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, CSTACY @ MIT-MC
2931 In-reply-to: Msg of 10 Jul 1984 00:19-EDT from David C. Plummer <DCP>
2933 Date: 10 July 1984 00:19-EDT
2934 From: David C. Plummer <DCP>
2935 I'm still not a speed reader. (I'm coming in over a vadic,
2936 AAA, ITS 1370, DDT 1480.) <alt><alt>U prints the bye
2937 message and then clears the screen.
2939 OK, OK. I fixed it again. If its still broken, perhaps you better see
2940 Evelyn Wood, because I can't imagine how I can have failed to fix it this
2943 Date: 10 July 1984 00:19-EDT
2944 From: David C. Plummer <DCP @ MIT-MC>
2945 To: ALAN @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC, CSTACY @ MIT-MC
2947 I'm still not a speed reader. (I'm coming in over a vadic,
2948 AAA, ITS 1370, DDT 1480.) <alt><alt>U prints the bye
2949 message and then clears the screen.
2951 Date: 9 July 1984 19:10-EDT
2952 From: Alan Bawden <ALAN @ MIT-MC>
2954 To: DCP @ MIT-MC, BUG-DDT @ MIT-MC
2955 cc: BUG-ITS @ MIT-MC
2956 In-reply-to: Msg of 9 Jul 1984 10:14-EDT from David C. Plummer <DCP>
2958 Date: 9 July 1984 10:14-EDT
2959 From: David C. Plummer <DCP>
2960 Either ITS was changed, or DDT was, and for the worse.
2961 When I log out, it does a :BYE followed by :OUTEST.
2962 I don't think either of these are at fault. What happens
2963 is that it prints the BYE message, and then clears the
2964 screen before printing the console free message. Needless
2965 to say, I'm not a speed reader.
2967 Believe it or not, another symptom of this same bug was the fact that
2968 :CHUNAME didn't work anymore. I fixed the bug and installed a new DDT.
2970 Date: 9 July 1984 16:35-EDT
2971 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2972 To: BUG-DDT @ MIT-MC
2973 cc: BUG-ITS @ MIT-MC
2975 I de-installed the latest DDT, since there are all these bug
2976 reports coming in and the responsible hacker is asleep now.
2978 Date: 9 July 1984 16:02-EDT
2979 From: Christopher C. Stacy <CSTACY @ MIT-MC>
2980 Subject: ml doesn't get updates
2982 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
2983 In-reply-to: Msg of 9 Jul 1984 06:18-EDT from Pandora B. Berman <CENT>
2985 ML should be getting updates; when it came back up I put
2986 it back in the list of machines to update and tested it.
2987 It worked for me; I'll look to see what is going wrong.
2989 Date: 9 July 1984 11:25-EDT
2990 From: Jeffrey P. Golden <JPG @ MIT-MC>
2992 To: BUG-ITS @ MIT-MC
2994 When I am logged in as JEFFG and do :CHUNAME JPG
2995 It says OP? and won't chuname me.
2997 Date: 9 July 1984 10:14-EDT
2998 From: David C. Plummer <DCP @ MIT-MC>
2999 To: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
3001 Either ITS was changed, or DDT was, and for the worse.
3002 When I log out, it does a :BYE followed by :OUTEST.
3003 I don't think either of these are at fault. What happens
3004 is that it prints the BYE message, and then clears the
3005 screen before printing the console free message. Needless
3006 to say, I'm not a speed reader.
3008 Date: 9 July 1984 06:18-EDT
3009 From: Pandora B. Berman <CENT @ MIT-MC>
3010 Subject: ml doesn't get updates
3011 To: BUG-INQUIR @ MIT-MC
3012 cc: BUG-ITS @ MIT-MC
3014 i modified my inquir entry a week ago to reflect my new office. ML
3015 still thinks i'm in 912. this is a bug. As long as ML is going to
3016 stay around for the indefinite (and probably not too short) future,
3017 would whoever diked it out of the inquir-update path please put it
3020 Date: 8 July 1984 15:38-EDT
3021 From: Christopher C. Stacy <CSTACY @ MIT-MC>
3023 To: BUG-ITS @ MIT-MC
3025 MLDEV does not work between ITS machines except via Chaosnet.
3026 Reminder to me to make it check for alternate host addresses
3027 on the ARPAnet and try them if Chaos is unresponsive.
3029 Date: 7 July 1984 16:55-EDT
3030 From: Charles Frankston <CBF @ MIT-MC>
3031 Subject: The saga of Subnet 6
3032 To: CHAOS-MAINT @ MIT-MC, BUG-ITS @ MIT-MC
3035 MC-IO-11 and TOTO (OZ's network front end) don't communicate on subnet 6.
3036 Each one can apparently communicate with most of the other machines on
3037 subnet 6, but not with each other. DPH said that subnet 6 was extended a
3038 few days ago, which is apparently when this problem started.
3040 My guess is that TOTO can send to MC-IO-11 since TOTO's routing table says
3041 to use subnet 1 to talk to MC rather than subnet 6, but for some reason
3042 MC-IO-11 probably tries to use subnet 6 to talk to TOTO and this loses.
3044 Unplugging the MC-IO-11 subnet 6 interface allows MC and OZ to
3045 communicate. This is the state things have been left in. However, this
3046 causes hosts which do not implement dynamic routing, such as ML and
3047 MIT-VAX to be unable to talk to MC, since they think that subnet 6 is the
3050 Date: 7 July 1984 00:20-EDT
3051 From: Alan Bawden <ALAN @ MIT-MC>
3052 Subject: MC (not) broken
3053 To: BUG-ITS @ MIT-MC
3055 In-reply-to: Msg of Fri 6 Jul 1984 23:34 EDT from PGS at MIT-OZ
3057 Date: Thursday, 5 July 1984 18:12-EDT
3058 From: Christopher C. Stacy <CSTACY at MIT-MC>
3059 Something is wrong with MC's hardware. ITS is having trouble
3060 talking to the T-300s, and can barely reach the Chaosnet (even
3061 though the ncp statistics look reasonable). Users were getting
3062 wedged today unable to log out; one of my jobs was stuck in a
3063 CLOSE call with a FLSINS of zero. DPH reports that the IO-11
3064 dropped very dead earlier.
3066 Just for the record, DPH disconnected MC from subnet 6 and all the Chaos
3067 net problems went away. Other wierdnesses reported by CStacy may or may
3068 not have anything to do with this.
3070 DPH should put himself on Bug-ITS.
3072 Date: Fri, 6 Jul 1984 23:34 EDT
3073 Message-ID: <PGS.12029302870.BABYL@MIT-OZ>
3075 To: "Christopher C. Stacy" <CSTACY@MIT-MC>
3078 In-reply-to: Msg of 5 Jul 1984 18:12-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
3080 Date: Thursday, 5 July 1984 18:12-EDT
3081 From: Christopher C. Stacy <CSTACY at MIT-MC>
3082 To: BUG-ITS at MIT-MC
3083 cc: BEDE at MIT-XX, MOON at SCRC-STONY-BROOK
3086 Something is wrong with MC's hardware. ITS is having trouble
3087 talking to the T-300s, and can barely reach the Chaosnet (even
3088 though the ncp statistics look reasonable). Users were getting
3089 wedged today unable to log out; one of my jobs was stuck in a
3090 CLOSE call with a FLSINS of zero. DPH reports that the IO-11
3091 dropped very dead earlier.
3095 1. What are these blue wires running around MC?
3096 Someone told me they are an attempt to "make MC think it
3097 is talking to the ROLM switch by faking out the DL-10 or something?"
3099 I suspect that this is just Ty trying to connect Rolm switch lines to normal
3100 tty lines (not under modem control). If you find out that it's something
3101 else, would you let me know?
3103 Date: 5 July 1984 18:40-EDT
3104 From: Alan Bawden <ALAN @ MIT-MC>
3106 To: BUG-ITS @ MIT-MC
3108 In-reply-to: Msg of 5 Jul 1984 14:21-EDT from Patrick G. Sobalvarro <PGS>
3110 Date: 5 July 1984 14:21-EDT
3111 From: Patrick G. Sobalvarro <PGS>
3114 :hostat ai-chaos-11 gives sysbin; hosts1 > - file not found.
3116 I deleted the obsolete HOSTAT program so that people would stop being
3119 Date: 5 July 1984 18:12-EDT
3120 From: Christopher C. Stacy <CSTACY @ MIT-MC>
3122 To: BUG-ITS @ MIT-MC
3123 cc: BEDE @ MIT-XX, MOON @ SCRC-STONY-BROOK
3126 Something is wrong with MC's hardware. ITS is having trouble
3127 talking to the T-300s, and can barely reach the Chaosnet (even
3128 though the ncp statistics look reasonable). Users were getting
3129 wedged today unable to log out; one of my jobs was stuck in a
3130 CLOSE call with a FLSINS of zero. DPH reports that the IO-11
3131 dropped very dead earlier.
3135 1. What are these blue wires running around MC?
3136 Someone told me they are an attempt to "make MC think it
3137 is talking to the ROLM switch by faking out the DL-10 or something?"
3139 2. The DEC log book says that the DL-10 had a bad module which was
3140 not replaced, but which was moved to another slot and that now
3141 everything "works fine".
3143 If no one has any good ideas, I will call DEC and have them see
3144 about working on the DL-10 again. Meanwhile, the system is not
3148 Date: 5 July 1984 14:21-EDT
3149 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
3150 To: BUG-ITS @ MIT-MC
3152 :hostat ai-chaos-11 gives sysbin; hosts1 > - file not found.
3154 Date: 4 July 1984 05:52-EDT
3155 From: David Vinayak Wallace <GUMBY @ MIT-MC>
3156 To: BUG-ITS @ MIT-MC
3158 MC appears to be unable to talk to OZ (finger, telnet, supdup),
3159 but finds is with :UP. Has no trouble with other chaos hosts I tried
3160 (prep, eddie, speech).
3162 MOON@MIT-ML 07/04/84 05:10:46 Re: HOSTAT OBERON
3163 To: (BUG ITS) at MIT-ML
3164 CC: GSB at MIT-ML, PSZ at MIT-ML
3165 :HOSTAT is an ancient program that retrieves a report on Arpanet hosts from DM.
3166 Obviously it should be flushed in favor of a program that uses Chaosnet
3167 HOSTAT protocol as PSZ evidently expected..
3169 Date: 4 July 1984 01:59-EDT
3170 From: Glenn S. Burke <GSB @ MIT-MC>
3171 Subject: [Forwarded: PSZ@MIT-MC, Re: ]
3172 To: BUG-ITS @ MIT-MC
3174 PSZ@MIT-MC 07/03/84 23:29:43
3176 on MC says: sysbin;hosts1 > - file not found.
3178 Date: 25 June 1984 04:39-EDT
3179 From: David A. Moon <MOON @ MIT-MC>
3180 To: BUG-ITS @ MIT-MC
3182 T10 on MC is broken. Twice I dialed up to it and my input
3183 was thoroughly garbled. I redialed to T12 and had no problems.
3185 Date: 20 June 1984 23:16-EDT
3186 From: Charles Frankston <CBF @ MIT-MC>
3188 cc: BUG-ITS @ MIT-MC
3190 The dialup garbage is NOT Concept 100 control sequences. It seems to
3191 happen with me on triple modems, which seem to raise Carrier Detect before
3192 they've quite settled, perhaps before they're synchornized. If you wait
3193 an extra two seconds after dialing up before typing return, it probably
3196 Date: 20 June 1984 18:23-EDT
3197 From: Alan Bawden <ALAN @ MIT-MC>
3198 Subject: Dialup Gubble
3200 cc: BUG-ITS @ MIT-MC
3201 In-reply-to: Msg of 20 Jun 1984 15:24-EDT from Christopher C. Stacy <CSTACY>
3203 Date: 20 June 1984 15:24-EDT
3204 From: Christopher C. Stacy <CSTACY>
3205 Sometimes when I dial in to the Vadics, ITS sends alot of
3206 unrecognizable garbage to my terminal when printing out the greeting
3207 message. This goes away after a TCTYP command, and a friend of mine
3208 on a VT100 claims the garbage looks like Concept-100 terminal control
3209 sequences, although on my AAA it just prints blobs.
3211 If this was true, then wouldn't everybody who uses Vadics see randomness
3212 when they dial up? (At least occasionally.) I have never seen anything of
3215 Perhaps its marsh gas?
3217 Date: 20 June 1984 15:24-EDT
3218 From: Christopher C. Stacy <CSTACY @ MIT-MC>
3219 To: BUG-ITS @ MIT-MC
3221 Sometimes when I dial in to the Vadics, ITS sends alot of
3222 unrecognizable garbage to my terminal when printing out the greeting
3223 message. This goes away after a TCTYP command, and a friend of mine
3224 on a VT100 claims the garbage looks like Concept-100 terminal control
3225 sequences, although on my AAA it just prints blobs.
3227 Date: Sun 17 Jun 84 14:10:44-EDT
3228 From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
3229 Subject: Re: Looping in the scheduler (with interrupts on, luckily)
3230 To: DCP@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
3232 In-Reply-To: Message from "David C. Plummer <DCP @ MIT-MC>" of Sat 16 Jun 84 20:14:00-EDT
3234 I think this was due to the console 11 dying. It seemed to
3235 be completely frozted; i.e. trying "LOAD ADDR" didn't result in
3236 whatever number you had in the switches showing up in the ADDR lights.
3239 Date: 16 June 1984 20:14-EDT
3240 From: David C. Plummer <DCP @ MIT-MC>
3241 Sender: DCP0 @ MIT-MC
3242 Subject: Looping in the scheduler (with interrupts on, luckily)
3243 To: BUG-ITS @ MIT-MC
3245 This morning I dialed up MC and got on T12. I was merrily doing
3246 random things. I didn't do anything for a while, but when I
3247 tried I got no response. I figured MC died. I was wrong.
3249 Just recently ALAN noticed I was around and informed me that not
3250 only was my job still there, but it was taking up all the extra
3251 computrons MC could offer. It was looping in TYSTE1 waiting for
3252 the -11 to set DTEOST to some negative value. The -11 wasn't
3253 doing this. The job could not be logged out or easily examined
3254 because it couldn't be PCLSRed.
3256 The first thing I tried was to tell the job (by bashing the PC)
3257 to try sending another doorbell to the -11. That didn't work.
3258 So, I set DTEOST to -1 by myself. The job unfroze and we had
3259 control again (for some value of control). Sending a TTY message
3260 to that console (causing output) now waits at TYOW4 waiting for
3261 the output buffer to be sufficiently empty to output. This will
3262 never happen, but at least it is PCLSRable and doesn't take up
3265 As experiments, I tried using T13 and T14. The first attempt to
3266 output on these caused the same phenomena: Looping in TYSTE1.
3267 Bashing DTEOST to -1 and outputing again caused waiting at TYOW4.
3268 (Using :COPY to the TTY line was sufficient to cause this.) This
3269 unfortunately means T12, T13, and T14 are no longer usable for
3270 experimentation unless you go in and reset the pointers and
3273 This is probably just a hardware lossage and requires MC to be
3274 rebooted to get the piece of dung -11 unwedged.
3276 Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 46531; Mon 11-Jun-84 08:04:08-EDT
3277 Date: Mon, 11 Jun 84 08:02 EDT
3278 From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
3280 To: BUG-LISPM@SCRC-RIVERSIDE.ARPA
3281 Cc: bug-its@MIT-MC.ARPA
3282 Message-ID: <840611080222.9.DLW@CHICOPEE.SCRC.Symbolics>
3284 In Symbolics 3600 Experimental System 243.758,
3285 Experimental Hardcopy 21.31, Experimental Zmail 84.157,
3286 Experimental LMFS 38.91, Experimental Tape 22.17,
3287 Experimental Basic Sage 2.26, Experimental New Documentation System 2.0,
3288 Experimental Print 35.10, Experimental IP-TCP 9.1, Japanese 15.0,
3289 Experimental TD80-Tape 1.22, cold load 114, microcode TMC5-MIC 290,
3290 FEP 18, Big band, on Chicopee:
3293 Unable to invoke FILE (TCP-FTP) -- CMU-CS-SPICE (via MC on CHAOS) by any path.
3294 TCP-GATEWAY (TCP-GATEWAY) -- MC on CHAOS: Cannot connect to 21 at CMU-CS-SPICE via MC:
3295 Request to MC for a TCP 128.2.254.139 25 connection was refused.
3296 Reason given was "TCP connection to foreign host failed"
3297 While in the function NETI:GET-CONNECTION-FOR-SERVICE-1
\18 NET:GET-CONNECTION-FOR-SERVICE
\18 (:DEFUN-METHOD FS:TCP-FTP-VALIDATE-CONN)
3299 It would be nice if the MC gateway would pass on some more info than
3300 just "conection to foreign host failed". If you try to FTP to
3301 CMU-CS-SPICE right now, using FTPU on MC, it says that "Request for
3302 Connection was refused by foreign host"; it would be nice it this info
3303 had been passed through by the gateway.
3305 Date: 12 June 1984 15:03-EDT
3306 From: Christopher C. Stacy <CSTACY @ MIT-MC>
3307 Subject: Reconnecting Spock's brain.
3309 cc: BUG-TIMES @ MIT-MC, BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC
3310 In-reply-to: Msg of 12 Jun 1984 00:13-EDT from Alan Bawden <ALAN>
3312 Date: 12 June 1984 00:13-EDT
3313 From: Alan Bawden <ALAN>
3315 Re: Reconnecting Spock's brain.
3317 I am quite certain that the TIMES/CTIMES program is totally broken. The
3318 other night when MC was mistaken about the correct time, Penny ran :TIMES
3319 to find out what other sites on the net thought the time was. To our
3320 surprise the program reported that every machine it could reach
3321 more-or-less agreed with MC's bogus time. When Penny ran PDSET to correct
3322 MC, every machine made the corresponding correction. I also observe that
3323 the times the program reports are ALWAYS in ascending order! I think it is
3324 quite obvious what is going on here...
3326 I have fixed this, and spiffed the program up a little while at it.
3329 Date: 23 May 1984 00:49-EDT
3330 From: Alan Bawden <ALAN @ MIT-MC>
3331 Subject: CRASH;STACKP FUCKED
3332 To: BUG-ITS @ MIT-MC
3334 I have just been informed by GSB that he made a crash dump of an ITS that
3335 had died trying to read an ML backup tape last Friday. Since it looks like
3336 this is a repeatable error (DLW crashed MC a couple of times trying to read
3337 in an AI backup tape last Sunday), its probably worth looking at. Note
3338 that there seems to be no trouble reading in MC's backup tapes. The dump
3339 GSB took is in CRASH;STACKP FUCKED. If you look at what's in P you will
3340 understand the name.
3342 Date: 17 May 1984 23:43-EDT
3343 From: David Vinayak Wallace <GUMBY @ MIT-MC>
3344 Subject: TENEX Remembered: Foo!
3346 cc: BUG-ITS @ MIT-MC
3347 In-reply-to: Msg of 17 May 1984 22:09-EDT from Charles Frankston <CBF>
3349 Date: 17 May 1984 22:09-EDT
3350 From: Charles Frankston <CBF>
3352 [From a letter about TENEX:]
3354 Date: 17 May 1984 13:14-EDT
3355 From: DIPACE at BBNF.ARPA
3357 Demand-paged-virtual memory,
3358 the first one of its kind;
3360 The question is, was it? Wasn't paging ITS around before TENEX?
3362 I believe so. But so certanly was the University of Manchester Atlas,
3363 Multics, and possibly the Berkeley XDS 940 time sharing system, although I
3364 don't know if it counts a demand paged.
3366 Oh, yeah, 360/67, TSS, CP/CMS, probably also both predate Tenex, but I'm
3368 Foo. You know I meant on PDP-10s.
3369 Didn't ITS start out Base-and-bounds?
3371 Date: 17 May 1984 22:09-EDT
3372 From: Charles Frankston <CBF @ MIT-MC>
3373 Subject: TENEX Remembered
3375 cc: BUG-ITS @ MIT-MC
3377 [From a letter about TENEX:]
3379 Date: 17 May 1984 13:14-EDT
3380 From: DIPACE at BBNF.ARPA
3382 Demand-paged-virtual memory,
3383 the first one of its kind;
3385 The question is, was it? Wasn't paging ITS around before TENEX?
3387 I believe so. But so certanly was the University of Manchester Atlas,
3388 Multics, and possibly the Berkeley XDS 940 time sharing system, although I
3389 don't know if it counts a demand paged.
3391 Oh, yeah, 360/67, TSS, CP/CMS, probably also both predate Tenex, but I'm
3394 Date: 17 May 1984 21:06-EDT
3395 From: David Vinayak Wallace <GUMBY @ MIT-MC>
3396 Subject: TENEX Remembered
3397 To: BUG-ITS @ MIT-MC
3398 In-reply-to: Msg of 17 May 1984 13:14-EDT from DIPACE at BBNF.ARPA
3400 [From a letter about TENEX:]
3402 Date: 17 May 1984 13:14-EDT
3403 From: DIPACE at BBNF.ARPA
3405 Demand-paged-virtual memory,
3406 the first one of its kind;
3408 The question is, was it? Wasn't paging ITS around before TENEX?
3410 Date: 12 May 1984 18:14-EDT
3411 From: Kent M Pitman <KMP @ MIT-MC>
3413 cc: BUG-ITS @ MIT-MC
3415 Date: 12 May 1984 15:32-EDT
3416 From: Phyllis E. Koton <elan @ MIT-MC>
3417 Sender: ING @ MIT-MC
3418 Re: bizarre dialup error
3421 The weirdest thing happened to me. I dialed up MC from
3422 home, hit a carriage return to get ITS attention, and it echoed the
3423 CR, but didn't print out any msg. SO I hit CR again, and again it
3424 echoed it, but no MC ITS ...
3425 so just to see what was going on, I said ":versio" and it said I was
3426 MC ITS USR:ING. IS THAT THE STRANGEST THING? I did whois on this
3427 ING and he is some tourist on the system. But I got logged in as
3428 him without ever saying login or giving a password. I am really
3429 psyched out by this. Do you think I should send mail to bug-its?
3432 This isn't the first time such a thing has happened. Your guess is probably
3433 correct; ING somehow hung up without ITS noticing so when you dialed in,
3434 you got his already-logged-in tty line. I'm forwarding this to BUG-ITS
3435 in case they care, but I wouldn't lose any sleep over it.
3438 Date: 8 May 1984 14:39-EDT
3439 From: Alan Bawden <ALAN @ MIT-MC>
3440 Subject: This afternoon's crash
3441 To: BUG-ITS @ MIT-MC
3443 TTY: BUFFER EMPTY AT TYIREM
3444 Dumped into CRASH;TYIREM 050884
3446 Date: 2 May 1984 20:41-EDT
3447 From: Jacob Moskowitz <JMSK @ MIT-MC>
3448 To: BUG-ITS @ MIT-MC
3452 I just logged in to the 300 baud
3453 line & discovered that I was already
3454 logged in as CAREY. Shouldn't ITS autologout on disconnect ?
3456 Date: 2 May 1984 09:39 PDT (Wed)
3457 Message-ID: <[SRI-NIC].IAN. 2-May-84 09:39:34>
3458 From: Ian Macky <Ian@SRI-NIC>
3459 To: Richard M. Stallman <RMS@MIT-MC>
3461 In-reply-to: Msg of 2 May 1984 02:00-PDT from Richard M. Stallman <RMS at MIT-MC>
3463 Date: Wednesday, 2 May 1984 02:00-PDT
3464 From: Richard M. Stallman <RMS at MIT-MC>
3465 To: BUG-ITS at MIT-MC
3467 When I supdup to MC, if I get tty 50, most characters do not echo and
3468 are not obeyed. Only rubout and control-G get any response from DDT.
3469 :TCTYP TTY 50 DESC shows exactly the same thing as other ttys that
3470 I get which work properly. I locked tty 50.
3472 The exact thing has happened to me before, too, many months ago tho.
3474 Date: 2 May 1984 05:00-EDT
3475 From: Richard M. Stallman <RMS @ MIT-MC>
3476 To: BUG-ITS @ MIT-MC
3478 When I supdup to MC, if I get tty 50, most characters do not echo and
3479 are not obeyed. Only rubout and control-G get any response from DDT.
3480 :TCTYP TTY 50 DESC shows exactly the same thing as other ttys that
3481 I get which work properly. I locked tty 50.
3483 Date: 2 May 1984 04:57-EDT
3484 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
3485 To: BUG-ITS @ MIT-MC
3487 I'm unable to supdup to MC right now, because the supdup server claims that
3488 all network ports are in use, although only t42-t51 are in use. nsttys is
3489 27, so we should be able to do better than this. The ttys actually seem to
3490 be there; could this be caused by someone not reassembling the supdup server
3491 after the last system installation?
3493 Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 25977; Wed 2-May-84 00:52:55-EDT
3494 Date: Wed, 2 May 84 00:54 EDT
3495 From: "David A. Moon" <Moon%SCRC-TENEX@SCRC-RIVERSIDE.ARPA>
3496 Subject: Meter hardware on MC
3497 To: BUG-ITS@MIT-MC.ARPA
3498 In-reply-to: The message of 2 Feb 84 01:34-EST from David A. Moon <MOON5 at MIT-MC>
3500 Date: 2 February 1984 01:34 EST
3501 From: David A. Moon <MOON5 @ MIT-MC>
3503 DATAI 24,n executed in user mode clobbers locations n and n+1 in the system!
3504 It's a good thing I tested this by hand before writing a program to use it.
3505 ITS executes the instruction with XCTR, as it should. I suspect this is
3506 a bug in the microcode. I guess I'll use .suset [.rrunt,, like a good little boy.
3508 I looked at the microcode and now think it's a bug in the hardware (MCL board
3509 of course). EPT REF clears the flag that SET PXCT sets?
3511 Fixed in the source of ITS! (Cleaning out my mail file).
3513 Date: 22 April 1984 20:51-EST
3514 From: Alan Bawden <ALAN @ MIT-MC>
3515 Subject: Hack attack.
3516 To: BUG-ITS @ MIT-MC
3519 I just amused myself by recreating the source of SYS:ATSIGN DEVICE from the
3520 binary. I restrained myself from fixing any of its problems until I got it
3521 to work. Those results can be found in ALAN;@DEV 40. Then I made a couple
3522 of trivial changes (@DEV 43), debugged them, and installed it. I'll
3523 install the source in a better place as soon as I am sure I am done with it.
3525 I renamed the old binary to be ATSIGN ODEVIC in case of disaster.
3527 Things in the source I had questions about are commented with ";???".
3529 In the bugs-you-can-only-find-by-reading-the-source department:
3531 o I fixed the problem where the "<0" and ">0" devices refered to the D and
3532 ARC devices respectively.
3534 o I didn't do anything about KMP's complaint that SYS4^F in DDT is confusing.
3536 o I found a related randomness; try typing THIRD7^F to DDT.
3538 Date: 13 April 1984 08:14-EST
3539 From: Ken Harrenstien <KLH @ MIT-MC>
3542 cc: BUG-ITS @ MIT-MC
3544 The IPQ: device is for getting a handle on Internet Packet Queues.
3545 Its main purpose was to allow UDP user/server programs to be written,
3546 but it is also used by a packet-log debugging program. I don't
3547 consider it complete yet -- it works, but is difficult to use. There
3548 were never (and still aren't really) any good examples of things to
3549 use UDP for, so it didn't have high priority and thus was never simplified.
3551 Date: 13 April 1984 01:05-EST
3552 From: Alan Bawden <ALAN @ MIT-MC>
3553 Subject: Why aren't you working on your thesis?
3555 cc: BUG-ITS @ MIT-MC
3556 In-reply-to: Msg of 11 Mar 1984 16:48-EST from Alan Bawden <ALAN>
3558 Date: 11 March 1984 16:48-EST
3559 From: Alan Bawden <ALAN>
3560 RFNAME on a SPY: channel should return the appropriate FN1.
3561 RFNAME on a CHAOS: channel should return as a directory name a host number
3562 just like TCP: channels.
3564 I just implemented both of these. Whoever next installs a new ITS should
3567 KLH: What is the IPQ: device all about?
3569 Date: 9 April 1984 20:25-EST
3570 From: Ken Harrenstien <KLH @ MIT-MC>
3573 cc: BUG-FTP @ MIT-MC, BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC,
3576 I fixed this bug (ACK 1 too high) in the source; someone assemble a new ITS
3577 one of these days. I also patched the running ITS on MC, so that
3578 CLynn can re-test right away to verify that it now works. (But didn't
3579 patch the ITS on disk, in case he wants to use the bug for a while
3580 to debug the TOPS-20 side).
3582 Date: 30 Mar 1984 04:39 EST (Fri)
3583 Message-ID: <MARTY.12003417172.BABYL@MIT-OZ>
3584 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
3586 Subject: [Who?: forwarded]
3589 Could someone stop MC from sending unparsable ITS mail headers out
3592 Received: from MIT-MC by MIT-OZ via Chaosnet; 30 Mar 84 02:26-EST
3593 TK@MIT-MC 03/30/84 02:08:32
3595 Indeed. It's about 65 degrees and was sunny until the sun went down.
3596 It was "cold" today, and everyone was complaining.
3598 Date: 28 March 1984 19:38-EST
3599 From: Glenn S. Burke <GSB @ MIT-MC>
3600 Subject: ucprl5+1 again
3601 To: BUG-ITS @ MIT-MC
3603 dumped to crash;ucplr5 gsb1
3604 Also complained about extra garbage in ufd STUDNT.
3606 From the looks of the return action on the system console, it's
3607 about to go again. It's definitely dropping characters too.
3609 Date: 28 March 1984 16:44-EST
3610 From: Alan Bawden <ALAN @ MIT-MC>
3611 Subject: All is not well...
3612 To: BUG-ITS @ MIT-MC
3614 MC crashed twice this afternoon at QINTE+44. Crash dump in CRASH;QINTE +44.
3615 Some kind of disk hardware lossage? While I was sitting here it
3616 crashed again at UCPRL5+1. Thats in CRASH;UCPRL5 +1. Some kind of screwup
3617 running around circular page lists.
3619 Date: 23 March 1984 05:28-EST
3620 From: Ken Harrenstien <KLH @ MIT-MC>
3623 cc: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC
3625 P.S. you might want to consider calling it SYSDOC instead, because
3626 this has the feature that changes to files therein will be reported on
3627 the system console. Not a real vital issue.
3629 Date: 23 March 1984 05:25-EST
3630 From: Ken Harrenstien <KLH @ MIT-MC>
3633 cc: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC
3636 Actually I have been tempted a couple of times recently to revive the
3637 ITSDOC directory and set the documentation up as it was on AI, where
3638 .INFO.;ITS FOO was usually a link to ITSDOC;FOO >. This has the advantage
3639 of letting us keep numbered versions of the documentation, and given that I
3640 am frobbing the documentation occasionally these days, it might be nice to
3641 not always immediately lose the previous version.
3645 Date: 19 March 1984 02:56-EST
3646 From: Alan Bawden <ALAN @ MIT-MC>
3648 To: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC
3649 In-reply-to: Msg of 19 Mar 1984 02:09-EST from David Vinayak Wallace <GUMBY>
3651 Date: 19 March 1984 02:09-EST
3652 From: David Vinayak Wallace <GUMBY>
3653 What happened to the ITSDOC directory?
3655 When I wondered the same thing, we went and looked at AI backups to
3656 discover just where was kept there. What we found was nothing that isn't
3657 now named MC:.INFO.;ITS.
3659 Actually I have been tempted a couple of times recently to revive the
3660 ITSDOC directory and set the documentation up as it was on AI, where
3661 .INFO.;ITS FOO was usually a link to ITSDOC;FOO >. This has the advantage
3662 of letting us keep numbered versions of the documentation, and given that I
3663 am frobbing the documentation occasionally these days, it might be nice to
3664 not always immediately lose the previous version.
3666 Date: 19 March 1984 02:09-EST
3667 From: David Vinayak Wallace <GUMBY @ MIT-MC>
3669 To: BUG-ITS @ MIT-MC
3671 What happened to the ITSDOC directory?
3673 Received: from MIT-LISPM-31 by MIT-OZ via Chaosnet; 18 Mar 84 19:29-EST
3674 Date: Sunday, 18 March 1984, 19:29-EST
3675 From: Patrick G. Sobalvarro <pgs%MIT-OZ@MIT-MC.ARPA>
3677 To: KMP at MIT-MC, CStacy at MIT-MC, BUG-ITS at MIT-MC
3678 In-reply-to: The message of 18 Mar 1984 16:31-EST from Kent M Pitman <KMP at MIT-MC>
3680 Received: from MIT-MC by MIT-OZ via Chaosnet; 18 Mar 84 16:32-EST
3681 Date: 18 March 1984 16:31-EST
3682 From: Kent M Pitman <KMP @ MIT-MC>
3684 To: BUG-ITS @ MIT-MC
3687 I am pretty sure that T03 is not a line to SDRC any more. I think it is
3688 just a 300 baud dialup like T04-T07. Could someone please check this and
3689 update its info in whatever database is used by FINGER? Thanks. -kmp
3691 CStacy seems to have done this, but the 11 does not think that this line is
3692 under modem control, so it won't work very well as one. When I next work on
3693 this tty line cruft I'll change this, if the thing really is a dialup line.
3694 Incidentally, if T03 is a dialup now, what phone is it connected to?
3696 Date: 18 March 1984 16:31-EST
3697 From: Kent M Pitman <KMP @ MIT-MC>
3699 To: BUG-ITS @ MIT-MC
3702 I am pretty sure that T03 is not a line to SDRC any more. I think it is
3703 just a 300 baud dialup like T04-T07. Could someone please check this and
3704 update its info in whatever database is used by FINGER? Thanks. -kmp
3706 Date: 13 March 1984 15:22-EST
3707 From: Ken Harrenstien <KLH @ MIT-MC>
3708 Subject: CRASH;IPQUSI
3709 To: BUG-ITS @ MIT-MC, GSB @ MIT-MC
3711 Thanks for the dump. I have fixed the bug in the source (INET), but
3712 did not bother to patch the current binary. ITS should be re-assembled
3715 What happened was that a bad UDP datagram arrived which was not long
3716 enough to hold a UDP header. Bug #1 was not checking the length for
3717 this. Fortunately the UDP dest port value happened to be zero in that
3718 buffer, so the code tried to find a UDP queue for port 0. Bug #2 was
3719 that this succeeded -- it "found" an non-existent queue with all the
3720 relevant info zero. IPQUSI caught this when it noticed it was about
3721 to try interrupting the system job! Both bugs are now fixed, and
3722 I deleted the crash dump.
3724 Date: 13 March 1984 12:17-EST
3725 From: Alan Bawden <ALAN @ MIT-MC>
3727 cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC
3728 In-reply-to: Msg of Tue 13 Mar 84 06:54 EST from Christopher C. Stacy <CStacy at MIT-MC.ARPA>
3730 Date: Tue, 13 Mar 84 06:54 EST
3731 From: Christopher C. Stacy <CStacy at MC>
3732 Date: 29 February 1984 10:59-EST
3733 From: Kent M Pitman <KMP>
3734 SYS4^F clears the screen and types NON-DIRECTORY DEVICE.
3735 Shouldn't this give a no such directory error? I assume
3736 DDT or ITS is somehow stripping the 4 and assuming I'm
3737 trying to reference the SYS device. My file defaults end
3738 up with SYS4: in them...
3739 I think this might be an ITS bug. In DDT at NCTLF2, it tries to open
3740 the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason,
3743 As I already said, the place to do something about this is in the unknown
3744 device handler. (You know, SYS;ATSIGN DEVICE? The file we don't have a
3745 source for?) ITS proper, and DDT are doing exactly the right things.
3747 Date: Tue, 13 Mar 84 06:54 EST
3748 From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
3749 To: BUG-ITS@MIT-MC.ARPA
3750 Cc: Kent M Pitman <KMP@MIT-MC.ARPA>, BUG-DDT@MIT-MC.ARPA
3751 In-reply-to: The message of 29 Feb 84 10:59-EST from Kent M Pitman <KMP>
3753 Date: 29 February 1984 10:59-EST
3754 From: Kent M Pitman <KMP>
3755 SYS4^F clears the screen and types NON-DIRECTORY DEVICE.
3756 Shouldn't this give a no such directory error? I assume
3757 DDT or ITS is somehow stripping the 4 and assuming I'm
3758 trying to reference the SYS device. My file defaults end
3759 up with SYS4: in them...
3761 I think this might be an ITS bug. In DDT at NCTLF2, it tries to open
3762 the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason,
3765 Date: 12 March 1984 22:12-EST
3766 From: Glenn S. Burke <GSB @ MIT-MC>
3767 Sender: GSB5 @ MIT-MC
3768 Subject: crash dumps
3769 To: BUG-ITS @ MIT-MC
3770 cc: BUG-TCP @ MIT-MC
3772 bughalt at IPQUSI+6, dumped to CRASH;IPQUSI 031284.
3773 a couple days ago, bughalt at TYIREM (actually TYIRE1+1), dumped
3774 to CRASH;TYIREM 030984.
3776 Date: 11 March 1984 16:48-EST
3777 From: Alan Bawden <ALAN @ MIT-MC>
3778 Subject: RFNAME & randomness
3779 To: BUG-ITS @ MIT-MC
3781 RFNAME on a SPY: channel should return the appropriate FN1.
3782 RFNAME on a CHAOS: channel should return as a directory name a host number
3783 just like TCP: channels.
3785 BTW, I have always felt that when opening the CLI: device, filenames should
3786 be treated exactly as they are when you open the USR: device. That is, you
3787 should be able to use a <JOB> specification as the first filename if the
3788 second filename is 0.
3790 Date: 10 March 1984 18:52-EST
3791 From: Kent M Pitman <KMP @ MIT-MC>
3792 To: BUG-ITS @ MIT-MC
3795 ITS was losing from network and local terminals (although apparently
3796 working ok from dialups). The 11 didn't seem to have a parity error
3797 light on and was not obviously stopped or anything, but we (ALAN and
3798 I) did :.;BOOT11 and the world went back to normal. Is this the right
3799 thing to have done and/or is there any more debugging information we
3800 could have scrounged up before reloading the 11? -kmp
3802 Date: 9 March 1984 10:46-EST
3803 From: John G. Aspinall <JGA @ MIT-MC>
3806 cc: ALAN @ MIT-MC, BUG-ARCDEV @ MIT-MC
3807 In-reply-to: Msg of 9 Mar 1984 08:01-EST from Christopher C. Stacy <CSTACY>
3809 Alan fixed it. I guess neither of us sent a follow up.
3810 Sorry to make unneeded work. cheers...
3812 Date: 9 March 1984 08:01-EST
3813 From: Christopher C. Stacy <CSTACY @ MIT-MC>
3816 cc: ALAN @ MIT-MC, BUG-ARCDEV @ MIT-MC
3817 In-reply-to: Msg of 7 Mar 1984 11:40-EST from John G. Aspinall <JGA>
3820 Maybe you already copied the files into a new AR3:, since reading and
3821 writing files there works fine for me.
3823 Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Fri 9-Mar-84 02:41:11-EST
3824 Return-path: <Moon@SCRC-TENEX>
3825 Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 24-Jan-84 16:54:39-EST
3826 Received: from SCRC-EUPHRATES by SCRC-YUKON with CHAOS; Tue 24-Jan-84 16:43:46-EST
3827 Date: Tuesday, 24 January 1984, 16:54-EST
3828 From: David A. Moon <Moon at SCRC-TENEX>
3829 Subject: The MC chaosnet ARPA server
3831 Cc: CStacy at MIT-MC, Moon at SCRC-TENEX
3832 Redistributed-to: Ian@SRI-NIC.ARPA, BUG-ITS@MIT-MC.ARPA
3833 Redistributed-by: Moon%SCRC-TENEX@MIT-MC.ARPA
3834 Redistributed-date: Fri, 9 Mar 84 02:33 EST
3836 Date: Tue 24 Jan 84 04:43-EST
3837 From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
3838 Subject: The MC chaosnet ARPA server
3839 To: moon@MIT-MC, cstacy@MIT-MC
3840 CC: gz%MIT-OZ@MIT-MC.ARPA
3842 Connecting to this nowadays closes the connection with the close text of:
3843 ? Internal error - NO SUCH DEVICE
3845 I think the gateway used to (sort of) work in the past.
3847 Well, it works for me, for both FTP and FINGER. Ah, but wait a minute,
3848 I'm using the TCP server and you're using the ARPA server. They're the
3849 same program, but the contact name controls the order of trying networks.
3850 I just looked at the source (MC:MMCM;ARPA) and if you use it as the ARPA
3851 server it first tries TCP then if that fails tries NCP. But NCP ain't
3852 implemented anymore which is why you get "no such device" rather than
3853 "destination host dead" or something of the sort. I guess a little
3854 restructuring of this code is called for.
3856 Date: 9 March 1984 02:15-EST
3857 From: Glenn S. Burke <GSB @ MIT-MC>
3858 Sender: GSB5 @ MIT-MC
3859 Subject: MIT Miraculous Levitation PDP-10
3861 cc: BUG-ITS @ MIT-MC
3863 Date: 8 Mar 1984 20:45 PST (Thu)
3864 From: Ian Macky <Ian@SRI-NIC>
3867 The "internal error" was apparently due to cca's being down.
3868 And ML has officially gone west.
3870 But it hasn't reached the horizon yet, so don't dyke it out of the host
3871 tables. Its disk has been fixed, and its processor/pager problem is
3872 going to be worked on this weekend. While i don't expect it to
3873 accept incoming net connections ever, it will certainly need to reach
3874 out and write some files.
3876 Date: 8 Mar 1984 20:45 PST (Thu)
3877 Message-ID: <[SRI-NIC].IAN. 8-Mar-84 20:45:34>
3878 From: Ian Macky <Ian@SRI-NIC>
3880 Subject: [DJC%MIT-OZ: no such device + no such machine]
3882 I can't think of a better place for this to go, since I forget the
3883 same of the server that the OZ FINGER uses...
3885 Date: Thursday, 8 March 1984 18:03-PST
3886 From: DJC%MIT-OZ at MIT-MC.ARPA
3887 To: bug-finger%MIT-OZ at MIT-MC.ARPA
3888 Re: no such device + no such machine
3889 Received: from MIT-MC by SRI-NIC with TCP; Thu 8 Mar 84 18:08:06-PST
3891 [PHOTO: Recording initiated Thu 8-Mar-84 8:58PM]
3893 MIT TOPS-20 Command Processor 5(750)-2
3897 [CCA-UNIX via MIT-MC]
3898 ? Internal error - NO SUCH DEVICE
3900 [CCA-UNIX via MIT-ML]
3905 [PHOTO: Recording terminated Thu 8-Mar-84 9:00PM]
3908 The "internal error" was apparently due to cca's being down.
3909 And ML has officially gone west.
3911 Date: 7 March 1984 11:40-EST
3912 From: John G. Aspinall <JGA @ MIT-MC>
3914 To: BUG-ARCDEV @ MIT-MC, ALAN @ MIT-MC
3916 JGA;AR3: seems to have suffered in the recent archive brouhaha,
3917 at least I get a hung job every time I try to copy into it.
3918 Could someone knowledgeable take a look at it, and give me an
3919 informed opinion on whether I should go into salvage mode?
3921 Date: Sun, 4 Mar 1984 14:58 EST
3922 Message-ID: <ALAN.11996714138.BABYL@MIT-OZ>
3923 From: Alan Bawden <ALAN%MIT-OZ@MIT-MC.ARPA>
3924 To: DCP@MIT-MC, BUG-ITS@MIT-MC
3925 Cc: BUG-OZ@MIT-MC, "Devon S. McCullough" <DEVON@MIT-MC>
3927 In-reply-to: Msg of 4 Mar 1984 00:00-EST from Devon S. McCullough <DEVON at MIT-MC>
3929 Date: Sunday, 4 March 1984 00:00-EST
3930 From: Devon S. McCullough <DEVON at MIT-MC>
3931 To: BUG-OZ at MIT-MC
3932 Re: SET TERMINAL ETX-IS-^C
3934 Date: 3 March 1984 20:50-EST
3935 From: David C. Plummer <DCP @ MIT-MC>
3937 cc: BUG-MINITS @ MIT-MC
3938 Date: 3 March 1984 17:56-EST
3939 From: Devon S. McCullough <DEVON @ MIT-MC>
3940 ^\ ^C should toggle a flag (that gets reset when you close a
3941 connection) that interchanges ^C and ^Z on the keyboard so I don't
3942 have to do this manually.
3943 Alternatively, you could hack the 20X monitor to do the same thing...
3945 Hey, we could hack ITS to do this too. ITS already has a similar hack for
3946 exchanging "[" and "]" with "(" and ")". I bet we could even do it right.
3948 (There is at least one reasonable alternative to simply swapping ^Z and ^C
3949 at the lowest level of input. That is to simply have a way to move the
3950 CALL key from ^Z to ^C. Then you would want ^_^C to be the way to type a
3951 ^C, except that that already has a meaning I think...)
3953 Date: 2 March 1984 12:58-EST
3954 From: Christopher C. Stacy <CSTACY @ MIT-MC>
3956 cc: BUG-ITS @ MIT-MC
3957 In-reply-to: Msg of 1 Mar 1984 22:29-EST from Leigh L. Klotz <KLOTZ>
3959 Date: 1 March 1984 22:29-EST
3960 From: Leigh L. Klotz <KLOTZ>
3963 WHAT IS SYS2;TS LINE? It was written 9/5/77, and just says it's
3964 a PDUMP file. I did :LINE instead of :LINK. It printed
3966 Your program has just gone off into HYPERSPACE!^G
3967 Of course, it was disowned.
3969 It's appears to be a wholine program of some sort, but I don't know
3970 what the message means or where the source is.
3972 Date: 1 March 1984 22:52-EST
3973 From: Alan Bawden <ALAN @ MIT-MC>
3974 Subject: MC woes: PACK NOT BAWDENIZED
3975 To: CENT @ MIT-MC, CSTACY @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC,
3976 JPG @ MIT-MC, KMP @ MIT-MC, Moon @ SCRC-TENEX
3977 cc: BUG-ITS @ MIT-MC
3978 In-reply-to: Msg of Thu 1 Mar 84 17:02 EST from David A. Moon <Moon%SCRC-TENEX at MIT-MC.ARPA>
3980 OK, using Moon's new routine in DUMP I have repaired the damage I caused
3981 last night. I used the incremental dump of Feb. 28 to reset the reference
3982 dates of all files to their state as of that dump. Thus currently no file
3983 on MC has a reference date later than 2/28/84 (although many of them have
3984 in fact been written since then).
3986 I can't think of any way that this situation can screw up except the
3987 following: someone who hadn't touched a file in a long time until
3988 yesterday, and who continues not to touch it for some time in the future
3989 will have his file migrate just a little sooner than he might expect. I
3990 don't know of any other program, besides DUMP, that uses the reference date
3991 for anything important.
3993 Date: 1 March 1984 22:29-EST
3994 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
3995 To: BUG-ITS @ MIT-MC
3997 WHAT IS SYS2;TS LINE? It was written 9/5/77, and just says it's
3998 a PDUMP file. I did :LINE instead of :LINK. It printed
4000 Your program has just gone off into HYPERSPACE!^G
4001 Of course, it was disowned.
4003 Date: 1 March 1984 15:06-EST
4004 From: Alan Bawden <ALAN @ MIT-MC>
4006 To: FILE-R @ MIT-MC, CSTACY @ MIT-MC
4007 cc: MEYER @ MIT-MC, LPH @ MIT-MC, BUG-ITS @ MIT-MC
4009 MEYER;AR0 TODO and LPH;AR31 MACSYM are both broken archives, they should be
4010 restored from backup tape. (This was caused by the installation of a
4011 broken archive device the other day.) I have renamed them to MEYER;XAR0 TODO
4012 and LPH;XAR31 MACSYM because I believe I have seen COMSAT trying to
4013 reference them both, which makes trouble. They seem to be unsalvageable,
4014 but I didn't delete them in case someone knows something I don't.
4016 Date: Wed 29 Feb 84 23:28:59-EST
4017 From: RMS%MIT-OZ@MIT-MC.ARPA
4021 I at one point started a massive rewrite of arcdev
4022 to finish the problem that it cannot detect 'disk full'
4023 until after the user has closed the file,
4024 but I never finished it because it proved hairier than I had expected.
4027 Date: 29 February 1984 18:56-EST
4028 From: Kent M Pitman <KMP @ MIT-MC>
4029 To: BUG-ITS @ MIT-MC
4031 I spoke with CStacy on the phone and he told me some bits I didn't have.
4033 He saved the old arc device as DEVICE;OLD ARCDEV. It was built from
4034 AI: SYSENG; ARCDEV 66, which is earlier than the oldest source (68) on
4035 MC: SYSENG; ... the implication being that MC: SYSENG; ARCDEV 68,
4036 although it has been around for 5 years, has never been compiled and/or
4039 I re-installed DEVICE;OLD ARCDEV and things seem to work.
4041 CStacy had me patch MAPARC+6 to have a CAILE instead of a CAIL and redump
4042 it, but for some reason that didn't work. That may either be because I
4043 redumped it incorrectly or because the change is not as harmless as you
4046 My testing may also have been confused by the fact that I had a couple of
4049 In any case, the state I am leaving this all in is that DEVICE;OLD ARCDEV
4050 (with no patches of any kind) has been replaced into DEVICE;JOBDEV ARC
4051 so that things are as they were yesterday and for the last several years.
4053 System people can start over again on their patches. Please stick around
4054 and test these things next time, though, so we aren't all stuck with broken
4055 archives. I have one archive which was enough screwed up by the experimental
4056 thing that was released earlier that I am having to retrieve an old copy
4057 of it from backup tape.
4059 Date: 29 February 1984 18:29-EST
4060 From: Kent M Pitman <KMP @ MIT-MC>
4061 To: BUG-ITS @ MIT-MC
4063 Being suspicious that these archive problems were caused by the recent
4064 recompilation of ARCDEV, I recompiled the older version and installed
4065 it but the same problem occurs in that version. Someone should really
4066 look at this problem soon; I've made a real mess of some of my archives
4067 in all this testing. I'm reinstalling the new ARCDEV since it seems to
4070 Date: 29 February 1984 18:07-EST
4071 From: Kent M Pitman <KMP @ MIT-MC>
4072 To: BUG-ITS @ MIT-MC
4074 Archives are just completely broken. Try copying something into one and
4077 Date: 29 February 1984 10:59-EST
4078 From: Kent M Pitman <KMP @ MIT-MC>
4079 To: BUG-DDT @ MIT-MC
4080 cc: BUG-ITS @ MIT-MC
4082 SYS4^F clears the screen and types NON-DIRECTORY DEVICE.
4083 Shouldn't this give a no such directory error? I assume
4084 DDT or ITS is somehow stripping the 4 and assuming I'm
4085 trying to reference the SYS device. My file defaults end
4086 up with SYS4: in them...
4088 Date: 29 February 1984 01:10-EST
4089 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4091 cc: BUG-ARCDEV @ MIT-MC
4092 In-reply-to: Msg of 29 Feb 1984 00:03-EST from Glenn S. Burke <GSB>
4094 I installed your ARCDEV fix in the source and on MC.
4096 Date: 29 February 1984 00:03-EST
4097 From: Glenn S. Burke <GSB @ MIT-MC>
4098 To: BUG-ARCDEV @ MIT-MC
4100 The location 665 in the arc job device, whatever that is, should use CAILE
4101 instead of CAIL. I haven't looked at the source, but it's lossage was
4102 apparent and i had to patch this on ml to keep from irretrievably losing
4105 Date: 26 Feb 1984 18:48 PST (Sun)
4106 Message-ID: <[SRI-NIC].IAN.26-Feb-84 18:48:28>
4107 From: Ian Macky <Ian@SRI-NIC>
4108 To: Leigh L. Klotz <KLOTZ@MIT-MC>
4110 In-reply-to: Msg of 26 Feb 1984 18:44-PST from Leigh L. Klotz <KLOTZ at MIT-MC>
4112 The LNKEDP call loops on HS: devices, or seems to when called from EMACS.
4114 I was (and still am) extremely ignorant about job devices... it's more
4115 surprising that it works at all. I'll look at it...
4117 Date: 26 February 1984 21:44-EST
4118 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
4119 To: BUG-ITS @ MIT-MC
4121 The LNKEDP call loops on HS: devices, or seems to when called from EMACS.
4123 Date: 23 February 1984 15:26-EST
4124 From: Kent M Pitman <KMP @ MIT-MC>
4127 cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC
4128 In-reply-to: Msg of 22 Feb 1984 22:33-EST from Alan Bawden <ALAN>
4130 Date: 22 February 1984 22:33-EST
4131 From: Alan Bawden <ALAN>
4133 cc: BUG-ITS, CSTACY, JPG
4135 In-reply-to: Msg of 22 Feb 1984 18:16-EST from Kent M Pitman <KMP>
4137 Date: 22 February 1984 18:16-EST
4138 From: Kent M Pitman <KMP>
4139 Shouldn't it be the case that deleting a file on the DNRF: device
4140 should err with WRONG TYPE DEVICE? ...
4142 We could only do this half-way really. We could "fix" DELETE to barf at
4143 seeing DNRF, but to make DELEWO barf would require making the channel
4144 remember that it was opened in this mode (a DNRF channel becomes a DSK
4145 channel after opening). Since GSB protests, I suggest we put this idea to
4148 I wasn't worried about DELEWO. Just DELETE (mostly accidental
\ f
4149 or :DELETE; maybe I should have just suggested DDT watch for this).
4150 In any case, since everyone thinks it's a bad idea, I won't push it.
4152 Date: 23 February 1984 01:17-EST
4153 From: Jeffrey P. Golden <JPG @ MIT-MC>
4156 cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
4158 As long as there is all this mail on the subject ...
4159 I fully agree with GSB, and that we should leave things as they are.
4161 Date: 23 February 1984 00:17-EST
4162 From: Ed Schwalenberg <ED @ MIT-MC>
4165 cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC
4167 I agree that things are better left as they are, lest we open Pandora's
4168 can of worms. I would point out that not only RENMWO, but DSKUPD, RESRDT
4169 and SRDATE "need to be fixed".
4171 The "right way" to achieve the functionality desired by KMP is through
4172 CAMEXEC-style translations, which have separate bits for all of the file
4173 operations: read, write, modify, append, delete, rename, and make link.
4174 Unfortunately, even CAMEXEC has no facility for prohibiting DELEWO, RENMWO,
4175 or MLNKWO (make link while open), on a properly opened channel. Obviously,
4176 ITS jobdevs could be invented which either ignore these operations or generate
4177 IOCERRORs if they are attempted.
4179 Date: 22 February 1984 22:33-EST
4180 From: Alan Bawden <ALAN @ MIT-MC>
4183 cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC
4184 In-reply-to: Msg of 22 Feb 1984 18:16-EST from Kent M Pitman <KMP>
4186 Date: 22 February 1984 18:16-EST
4187 From: Kent M Pitman <KMP>
4188 Shouldn't it be the case that deleting a file on the DNRF: device
4189 should err with WRONG TYPE DEVICE? ...
4191 We could only do this half-way really. We could "fix" DELETE to barf at
4192 seeing DNRF, but to make DELEWO barf would require making the channel
4193 remember that it was opened in this mode (a DNRF channel becomes a DSK
4194 channel after opening). Since GSB protests, I suggest we put this idea to
4197 Date: 22 February 1984 22:23-EST
4198 From: Alan Bawden <ALAN @ MIT-MC>
4201 cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
4202 In-reply-to: Msg of 22 Feb 1984 17:47-EST from Christopher C. Stacy <CSTACY>
4204 Date: 22 February 1984 17:47-EST
4205 From: Christopher C. Stacy <CSTACY>
4206 Trying to rename DNRF: to DSK: on same directory gets me
4207 CANT RENAME TO ANOTHER DIRECTORY.
4209 If you do :CALL RENAME you will find that this can't possibly be an ITS
4210 bug. If you were using DDT, then it is DDT's problem.
4212 Date: 22 February 1984 21:32-EST
4213 From: Glenn S. Burke <GSB @ MIT-MC>
4214 Subject: delete an error on DNRF
4216 cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC, JPG @ MIT-MC
4218 Yes, i disagree, because i sometimes use DNRF: as the default device when
4219 i do hand "gfring", in which i examine potentially deletable files.
4221 Date: 22 February 1984 18:16-EST
4222 From: Kent M Pitman <KMP @ MIT-MC>
4224 cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC, KMP @ MIT-MC
4226 Shouldn't it be the case that deleting a file on the DNRF: device
4227 should err with WRONG TYPE DEVICE? This would be handy since mostly
4228 I reference files on DNRF: exactly because I want to not bother them
4229 and if I have left my file defaults set to DNRF: it might have been
4230 by accident. I generally read others' files with DNRF: and would be
4231 happy knowing that this also provided greater protection against
4232 accidentally deleting them. I consider having to type ^O DSK:
4233 to delete such a file after viewing it with DNRF: to be a small price
4234 to pay for the change.
4236 Does someone disagree strongly with this argument?
4239 Date: 22 February 1984 17:47-EST
4240 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4241 To: BUG-ITS @ MIT-MC
4243 Trying to rename DNRF: to DSK: on same directory gets me
4244 CANT RENAME TO ANOTHER DIRECTORY.
4246 Date: 18 February 1984 03:48 EST
4247 From: David A. Moon <MOON @ MIT-MC>
4248 To: BUG-ITS @ MIT-MC
4250 In SYSTEM;INET 108 I added the missing instruction whose
4251 absence caused all that ICMP spewage on MC's system console yesterday.
4252 Someone should reassemble the system some time. I guess it's not urgent
4253 since TCP/IP has been in use for over a year and as far as I know this
4256 Date: 18 February 1984 00:51 EST
4257 From: Pandora B. Berman <CENT @ MIT-MC>
4258 Subject: new $$^F loses
4259 To: BUG-ITS @ MIT-MC
4261 it's a pain to have to type $$1^F all the time when i'm used to typing
4262 plain $$^F. also, it doesn't make filenames sticky anymore, another
4265 Date: 14 February 1984 22:11 EST
4266 From: Alan Bawden <ALAN @ MIT-MC>
4267 Subject: LOGOUT TIMES
4269 cc: BUG-ITS @ MIT-MC
4270 In-reply-to: Msg of 14 Feb 1984 15:35 EST from Paul G. Weiss <WEISS>
4272 Date: 14 February 1984 15:35 EST
4273 From: Paul G. Weiss <WEISS>
4274 After logging out at 15:33EST, my logout time was set to
4275 14:16:03, as indicated by finger.
4277 Well, generally it takes a couple of minutes for this information to make
4278 it into the database of logout times. How long did you wait after logging
4279 out before checking? (Since it is not real important that this information
4280 be up-to-the-minute accurate, it is processed by a demon that only wakes up
4283 Date: 14 February 1984 15:35 EST
4284 From: Paul G. Weiss <WEISS @ MIT-MC>
4285 To: BUG-ITS @ MIT-MC
4287 After logging out at 15:33EST, my logout time was set to
4288 14:16:03, as indicated by finger.
4290 Date: 13 February 1984 17:59 EST
4291 From: Ken Harrenstien <KLH @ MIT-MC>
4292 Subject: conjecture about "TCP bugs"
4294 cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, CSTACY @ MIT-MC,
4297 Date: 13 February 1984 13:56 EST
4298 From: Earl A. Killian <EAK @ MIT-MC>
4299 In-reply-to: Msg of 13 Feb 1984 02:48 EST from Ken Harrenstien <KLH>
4301 I cannot usually use MC for more than about 5 minutes without
4302 my connection wedging. This is from S1-C, a 4.1bsd 750 Unix with
4303 BBN TCP. Basically output just stops though input seems to get
4304 through for a little while.
4306 The BBN VAX TCP is known to have bugs, especially under any kind of load.
4307 However, if you are willing to reproduce this at a specific time, I can
4308 log the traffic and thereby identify the problem.
4310 Date: 13 February 1984 15:26 EST
4311 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4312 Subject: [kmp at MIT-MC: ITS primitive devices]
4314 cc: BUG-ITS @ MIT-MC, KMP @ MIT-MC
4315 In-reply-to: Msg of 13 Feb 1984 13:36 EST from Alan Bawden <ALAN>
4318 Date: 13 February 1984 13:36 EST
4319 From: Alan Bawden <ALAN>
4320 Double Hmmm... Try :LISTF TCP: vs. :LISTF CHAOS:. Perhaps CHAOS: really
4321 \does/ belong in that table after all...
4323 I think you are right - so I added the CHAOS device to DEVTAB, accordingly.
4324 IPQ is for Internet datagrams; I believe it is part of the internals
4325 of the not-completely-implemented datagram service feature.
4327 Date: 13 February 1984 13:56 EST
4328 From: Earl A. Killian <EAK @ MIT-MC>
4329 Subject: conjecture about "TCP bugs"
4331 cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC
4332 In-reply-to: Msg of 13 Feb 1984 02:48 EST from Ken Harrenstien <KLH>
4334 I cannot usually use MC for more than about 5 minutes without
4335 my connection wedging. This is from S1-C, a 4.1bsd 750 Unix with
4336 BBN TCP. Basically output just stops though input seems to get
4337 through for a little while.
4339 Date: 13 February 1984 13:36 EST
4340 From: Alan Bawden <ALAN @ MIT-MC>
4341 Subject: [kmp at MIT-MC: ITS primitive devices]
4343 cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
4344 In-reply-to: Msg of Sun 12 Feb 84 21:38 EST from Christopher C. Stacy <CStacy at MIT-MC.ARPA>
4346 [ KMP asked where he could find a list of all of ITS's built-in devices. I
4347 told him to look at the table of sixbit names starting at DEVTAB. ]
4349 Hmmm... Actually that table doesn't include CHAOS:, presumably because
4350 that table is used by OPEN and you can only open a CHAOS: channel using
4351 CHAOSO. But then TCP: \is/ in that table despite the fact that you have to
4352 use TCPOPN to open it.
4354 Double Hmmm... Try :LISTF TCP: vs. :LISTF CHAOS:. Perhaps CHAOS: really
4355 \does/ belong in that table after all...
4357 Date: 13 February 1984 08:09 EST
4358 From: Ken Harrenstien <KLH @ MIT-MC>
4359 To: BUG-HOST @ MIT-MC, BUG-HSTLOK @ MIT-MC
4360 cc: BUG-ITS @ MIT-MC, BUG-NETWRK @ MIT-MC
4362 I doubt anyone is actually on a list for this program, but
4363 the news is that HSTLOK has been renamed to HOST (to match its
4364 binary name) and revised to work on TNX as well as ITS.
4365 Some fixes to NETWRK were necessary. New source in SYSEN1;HOST and
4368 Date: 13 February 1984 02:48 EST
4369 From: Ken Harrenstien <KLH @ MIT-MC>
4370 Subject: conjecture about "TCP bugs"
4372 cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, DEVON @ MIT-MC
4374 All I can say is that it is probably something specific to TACs,
4375 because I don't get that kind of screwage from host-to-host
4376 connections (either Unix or 20X). The TAC software changes
4377 every now and then, and was definitely broken at some points
4378 (see the Internet monthly report). However, to really PROVE
4379 TAC lossage, it needs to be spied on while it is actually
4380 happening. If anyone is able to easily reproduce the problem
4381 then it should be possible to easily figure out who is at fault.
4383 Date: 12 February 1984 11:45 EST
4384 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4385 Subject: conjecture about "TCP bugs"
4386 To: BUG-ITS @ MIT-MC
4387 cc: BUG-TCP @ MIT-MC, DEVON @ MIT-MC
4390 Sometimes when using a Chaosnet connection (like a MINITS HUB) I have
4391 felt a distrubance in the force, as if thousands of words were crying
4392 out -- and then suddenly shuffled.
4394 The symptom is that there are long delays with no TTY service, making
4395 users think the system has crashed. Just now I was using a TAC for
4396 the first time in months, and when it happened it was extremely
4397 intrusive and scary.
4399 I wonder if it is ITS that is "broken" rather than anything in the
4400 TCP stuff. This might explain those "TCP bugs" people are always
4401 reporting. Maybe something about the way the TCP code works makes
4402 the problem more noticable to TAC users.
4404 Oh, well. Something to watch out for.
4405 Maybe I will put in something to let me check for it.
4407 Date: 8 February 1984 18:18 EST
4408 From: David Vinayak Wallace <GUMBY @ MIT-MC>
4409 To: BUG-ITS @ MIT-MC
4411 MC dropped my arpa connection three times in 20 minutes today. grump.
4413 Date: 3 Feb 1984 09:09 PST (Fri)
4414 Message-ID: <[SRI-NIC].IAN. 3-Feb-84 09:09:11>
4415 From: Ian Macky <Ian@SRI-NIC>
4416 To: David C. Plummer <DCP@MIT-MC>
4417 Cc: BUG-ITS@MIT-MC, GREN@MIT-MC
4418 Subject: Strange Happenings
4419 In-reply-to: Msg of 2 Feb 1984 21:55-PST from David C. Plummer <DCP at MIT-MC>
4421 Other direcectories were OK. I looked at .TEMP.; and GREN;, and
4422 maybe one or two others and they were all fine.
4424 Date: 3 February 1984 03:41 EST
4425 From: Glenn S. Burke <GSB @ MIT-MC>
4426 Sender: GSB5 @ MIT-MC
4427 Subject: mc wedgitude
4428 To: BUG-ITS @ MIT-MC
4430 The DL10 wedges with the par err light on. The one time i took a good
4431 look, none of the address lights were lit. Experimentation shows
4432 that this is at least not directly a function of the mf10 memories in
4433 cabinets E and F. The states of most other lights on the dl10 are
4434 recorded in the log book; i am not going to walk up the stairs again
4435 this morning to either get them, or boot the machine.
4437 In the no doubt useless hope that this has something to do with the
4438 memories, the NITS dump was patched so that addresses 1000000-2000000
4439 are out. Note that the address switches of the mf10s seem to have
4440 been rearranged: the cabinets are all at monotonically increasing
4441 addresses from left to right now.
4443 An earlier spaz of parity errors (i don't know if it's related at all)
4444 had 2 or 3 from mf10 E, and about 6 from somewhere high up in the ampex,
4445 according to the printout on the system console.
4447 Date: 3 February 1984 00:55 EST
4448 From: David C. Plummer <DCP @ MIT-MC>
4449 Subject: Strange Happenings
4451 cc: BUG-ITS @ MIT-MC
4453 Date: 2 February 1984 20:18 EST
4454 From: Ian Macky <GREN @ MIT-MC>
4456 A few minutes ago MC was acting rather strange. Any refernce to the
4457 .MAIL.; directory would hang you - either trying to write a file
4458 (:MAIL hung), or list the directory ^F (or :P D), or anything else.
4459 At the same time, KJB's BABYL fork couldn't be killed. His DDT
4460 would hang on the :KILL and not return. It just now stopped and
4461 all seems well, so I don't have any more information. What might
4463 Were all the other directories accessable. I have seen this
4464 before when the directory cache becomes full and each entry is
4465 unflusable for some reason. I have seen both solutions to this:
4466 the system sooner or later unwedges, or it doesn't requiring
4467 reload. You may not have been able to kill KJB's babyl because it
4468 needed to update something in the file system (close a file,
4471 I'm a bit surprised .MAIL. didn't work. When I saw this
4472 behavior, most of the SYS directories worked, and sometimes
4473 .TEMP., and usuall a couple directories of people logged in.
4475 Date: 2 February 1984 20:18 EST
4476 From: Ian Macky <GREN @ MIT-MC>
4477 Subject: Strange Happenings
4478 To: BUG-ITS @ MIT-MC
4480 A few minutes ago MC was acting rather strange. Any refernce to the
4481 .MAIL.; directory would hang you - either trying to write a file
4482 (:MAIL hung), or list the directory ^F (or :P D), or anything else.
4483 At the same time, KJB's BABYL fork couldn't be killed. His DDT
4484 would hang on the :KILL and not return. It just now stopped and
4485 all seems well, so I don't have any more information. What might
4488 Date: 2 February 1984 01:34 EST
4489 From: David A. Moon <MOON5 @ MIT-MC>
4490 Subject: Meter hardware on MC
4491 To: BUG-ITS @ MIT-MC
4492 cc: Moon @ SCRC-TENEX
4494 DATAI 24,n executed in user mode clobbers locations n and n+1 in the system!
4495 It's a good thing I tested this by hand before writing a program to use it.
4496 ITS executes the instruction with XCTR, as it should. I suspect this is
4497 a bug in the microcode. I guess I'll use .suset [.rrunt,, like a good little boy.
4499 Date: 1 Feb 1984 20:43 EST (Wed)
4500 Message-ID: <MARTY.11988388336.BABYL@MIT-OZ>
4501 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
4503 Subject: [GLR: bad mail from ML]
4505 Date: Wednesday, 1 February 1984 18:55-EST
4506 From: Jerry Roylance <GLR>
4508 Re: bad mail from ML
4510 Got some bad format mail from ML -- no FROM:.
4516 Received: from MIT-ML by MIT-OZ via Chaosnet; 31 Jan 84 21:39-EST
4517 TIM@MIT-ML 01/31/84 21:39:15
4519 Where might I be able to find information on the RS-422 standard?
4522 Date: Wed, 1 Feb 84 05:14 EST
4523 From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
4524 Subject: more loose ends in ITS network support?
4525 To: Ken Harrenstien <KLH@MIT-MC.ARPA>
4526 Cc: KMP@MIT-MC.ARPA, MOON%SCRC-TENEX@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA,
4528 In-reply-to: The message of 31 Jan 84 16:08-EST from Ken Harrenstien <KLH at MIT-MC>
4530 CHAOSO and TCPOPN now behave a little more like OPEN.
4531 If these calls lose after arg checking (ie., channel numbers in
4532 range), for example if they want to say %EFLDV, that the error code
4533 will make it into the IOCHST word of the input channel.
4535 I removed the ISE0 crock for TCP from NETWRK's ANALYZ code, and
4536 reassembled TELNET, SUPDUP, and NAME. There should be no more random
4537 "Could not connect to foreign host with TCP messages" coming out
4538 anymore from either Chaosnet (!) or Internet programs.
4544 Date: 30 January 1984 22:52 EST
4545 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4546 Subject: Chaosnet connections
4547 To: BUG-ITS @ MIT-MC
4550 In ITS 1362 on MIT-MC:
4552 Lately MC frequently gets into a state where all CHAOSO calls fail
4553 with DEVICE FULL. I increased the number of Chaosnet indices from 32.
4554 to 50., because there were 16/32 buffers free, and lots of pending
4555 RFCs and confused users. I hope this is the correct fix, and that
4556 GCing of something or other is not broken.
4558 Date: 29 January 1984 09:09 EST
4559 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
4560 Subject: EMACS echo area
4562 cc: BUG-ITS @ MIT-ML
4563 In-reply-to: Msg of 01/22/84 17:17:46 from DEVON at MIT-ML
4565 If you use the EMACS variable Echo Area Height instead of the raw flag
4566 FS Echo Lines your problems will be over.
4570 Date: 28 January 1984 19:53 EST
4571 From: Alan Bawden <ALAN @ MIT-MC>
4572 Subject: _LSPM_ OUTPUT
4574 cc: BUG-ITS @ MIT-MC, GZ @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX
4575 In-reply-to: Msg of 28 Jan 1984 19:30 EST from William G. Dubuque <WGD>
4577 Date: 28 January 1984 19:30 EST
4578 From: William G. Dubuque <WGD>
4579 Date: 27 January 1984 17:03 EST
4580 From: Alan Bawden <ALAN>
4581 Date: 27 January 1984 08:06 EST
4582 From: Bill Gosper <RWG>
4583 BIL@mc and rwg@Russian tried to write out gz;grob > at about the
4585 What program was BIL using on MC? One possible theory is that he
4586 was using a program that did something incompetent. Better
4587 possibility (says Moon standing right behind me) is that RWG's file
4588 server got and error that he somehow never saw.
4589 I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file.
4590 As GZ mentioned, there was a _LSPM_ OUTPUT file laying around for
4591 awhile after my version was written.
4593 OK, so now we know that it was the file being written by the file server
4594 that never made it. Sounds like RWG was screwed by his Lisp machine not
4595 telling him about an error. Since we are now certain that this is not an
4596 ITS problem, or a problem with some non-lispmachine software, the next
4597 person to send mail on this subject should please delete BUG-ITS from the
4600 Date: 28 January 1984 19:30 EST
4601 From: William G. Dubuque <WGD @ MIT-MC>
4602 Sender: BIL @ MIT-MC
4604 cc: BUG-ITS @ MIT-MC, GZ @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX
4605 In-reply-to: Msg of 27 Jan 1984 17:03 EST from Alan Bawden <ALAN>
4607 Date: 27 January 1984 17:03 EST
4608 From: Alan Bawden <ALAN>
4610 cc: BIL, BUG-ITS, GZ, bug-lispm at SCRC-TENEX
4612 Date: 27 January 1984 08:06 EST
4613 From: Bill Gosper <RWG>
4614 BIL@mc and rwg@Russian tried to write out gz;grob > at about the
4617 What program was BIL using on MC? One possible theory is that he was using
4618 a program that did something incompetent. Better possibility (says Moon
4619 standing right behind me) is that RWG's file server got and error that he
4621 I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file. As GZ
4622 mentioned, there was a _LSPM_ OUTPUT file laying around for awhile
4623 after my version was written. I take it there are no known (a)synchronization
4624 problems that could be at the heart of this?
4625 Whatever the error someone should be responsible for making it know to the
4626 writer who loses since, of course, a lot could be lost this way.
4628 Date: 27 January 1984 17:03 EST
4629 From: Alan Bawden <ALAN @ MIT-MC>
4631 cc: BIL @ MIT-MC, BUG-ITS @ MIT-MC, GZ @ MIT-MC, bug-lispm @ SCRC-TENEX
4632 In-reply-to: Msg of 27 Jan 1984 08:06 EST from Bill Gosper <RWG>
4634 Date: 27 January 1984 08:06 EST
4635 From: Bill Gosper <RWG>
4636 BIL@mc and rwg@Russian tried to write out gz;grob > at about the
4639 What program was BIL using on MC? One possible theory is that he was using
4640 a program that did something incompetent. Better possibility (says Moon
4641 standing right behind me) is that RWG's file server got and error that he
4644 Date: 27 January 1984 08:06 EST
4645 From: Bill Gosper <RWG @ MIT-MC>
4646 To: BUG-ITS @ MIT-MC
4647 cc: GZ @ MIT-MC, BIL @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX
4649 BIL@mc and rwg@Russian tried to write out gz;grob > at about the
4650 same time. Russian paused about a minute in File Finish, but seemed to
4651 return from the m-X Copy File normally (RWG had typed ahead
4652 a c-and a few chars, but no aborts or anysuch.) Only BIL's version
4653 made it into gz;. GZ herself reported seeing an open file linger
4654 there for a few minutes and then disappear.
4656 Date: 23 January 1984 14:30 EST
4657 From: Christopher C. Stacy <CHRIS @ MIT-MC>
4658 To: USER-ACCOUNTS @ MIT-MC
4659 cc: BUG-ITS @ MIT-MC
4661 I had to reload the password database again; apparently there is
4662 a reproducible way to crash ITS and corrupt this file.
4663 Changes to the database made before 1/20 have been lost.{
4665 Date: Mon, 23 Jan 84 02:28 EST
4666 From: David Vinayak Wallace <Gumby@MIT-MC.ARPA>
4667 Subject: I may be a loser, but...
4668 To: "David A. Moon" <MOON@MIT-MC.ARPA>
4669 Cc: BUG-ITS@MIT-MC.ARPA
4670 In-reply-to: The message of 22 Jan 84 23:58-EST from David A. Moon <MOON at MIT-MC>
4672 Date: 22 January 1984 23:58 EST
4673 From: David A. Moon <MOON @ MIT-MC>
4674 Date: Sunday, 22 January 1984, 07:39-EST
4675 From: David Vinayak Wallace <Gumby at MIT-MC>
4676 MC died very strangely tonight. The IO bay and processor were frozen,
4677 but the memory and the ampex were happily flashing their lights as if
4678 nothing was wrong. There was a red NXM light illuminated on the
4679 processor bay (I didn't know there was such a light!).
4681 There isn't. You must have mistaken something else for the processor;
4683 I'm a loser. It was the DL10.
4685 I wasn't able to figure out from that dump file how the system crashed.
4686 I suspect the answer is that it didn't! I also wasn't able to figure
4687 out how you stopped it or what command you used to dump it out (there
4688 weren't any symbols for some reason).
4690 I halted it with break, then used
\eY in ddt to make the dump.
4692 I assumed MC had died because:
4693 Neither the decscribbler nor the vt52 would respond to ^Z.
4694 You could not open a connection over arpa or chaos (I tried status,
4696 Existing arpa, chaos, and dialup connections hung.
4698 Since you couldn't talk to it, I assumed it had crashed. The front-end
4699 was running fine, as I could wake it up with break.
4701 Perhaps this can help.
4705 Date: 22 January 1984 23:58 EST
4706 From: David A. Moon <MOON @ MIT-MC>
4707 Subject: mc spills her cookies?
4709 cc: BUG-ITS @ MIT-MC
4711 Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST
4712 Date: Sunday, 22 January 1984, 07:39-EST
4713 From: David Vinayak Wallace <Gumby at MIT-MC>
4714 Subject: mc spills her cookies
4715 To: bug-its at MIT-MC
4717 MC died very strangely tonight. The IO bay and processor were frozen,
4718 but the memory and the ampex were happily flashing their lights as if
4719 nothing was wrong. There was a red NXM light illuminated on the
4720 processor bay (I didn't know there was such a light!).
4722 There isn't. You must have mistaken something else for the processor;
4723 perhaps the DL10, which is the wide bay over near the T-300 disk drives
4724 (between them and the tape drive). It's a pdp11-to-memory interface.
4725 Or it could have been the DF10, on the left-hand end of the row of 8
4726 memory bays; it's a disk-to-memory interface. As I recall, both have
4729 I put a crash dump in CRASH MEMPAR (since MC had been getting parity
4730 errors just before the crash), but since I cleverly neglected to record
4731 the state of the processor lights, it's probably useless.
4733 I wasn't able to figure out from that dump file how the system crashed.
4734 I suspect the answer is that it didn't! I also wasn't able to figure
4735 out how you stopped it or what command you used to dump it out (there
4736 weren't any symbols for some reason).
4738 It has been getting parity errors; I think the Ampex memory is turning
4739 to shit (or has been shit all along).
4741 Date: 22 January 1984 23:42 EST
4742 From: David A. Moon <MOON @ MIT-MC>
4743 Subject: MC crash at 5pm today, dumped to crash;pagfau 1/22/8
4744 To: BUG-ITS @ MIT-MC, Hornig @ SCRC-TENEX
4746 Fixed in the source and patched in both the running system and the
4747 dump. When copying a Chaosnet packet into an Internet packet buffer,
4748 it was erroneously using the length of the destination rather than
4749 the length of the source as the length of the transfer; since the
4750 source was shorter it ran off the end of wired memory and took an
4753 DEVON@MIT-ML 01/22/84 17:17:46
4754 To: (BUG ITS) at MIT-ML
4755 This is a longstanding "feature" which is probably actually a bug.
4756 When I detach my tree, the info about the echo area is lost, so
4757 that if I reattach and continue an EMACS, it has forgotten about
4758 the echo area on the screen. Apparently this only happens if I
4759 was actually in EMACS when I was detached (by call waiting) so
4760 I tried the following experiment:
4762 :tctyp printing nosupdup
4767 will clobber EMACS' echo area, even though the only thing typed at it
4768 while TCTYP was zero was a ^Z, but
4770 :tctyp printing nosupdup
4773 has no ill effect. I can always fix the echo area with the TECO command
4774 FS ECHO LINES$FS ECHO LINES$$ (restarting from DDT with $G clobbers the
4775 line saving info) but it really looks like an ITS bug to me..
4777 Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST
4778 Date: Sunday, 22 January 1984, 07:39-EST
4779 From: David Vinayak Wallace <Gumby at MIT-MC>
4780 Subject: mc spills her cookies
4781 To: bug-its at MIT-MC
4783 MC died very strangely tonight. The IO bay and processor were frozen,
4784 but the memory and the ampex were happily flashing their lights as if
4785 nothing was wrong. There was a red NXM light illuminated on the
4786 processor bay (I didn't know there was such a light!).
4788 I put a crash dump in CRASH MEMPAR (since MC had been getting parity
4789 errors just before the crash), but since I cleverly neglected to record
4790 the state of the processor lights, it's probably useless.
4794 Date: 19 January 1984 16:20 EST
4795 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4796 To: BUG-ITS @ MIT-MC
4797 cc: KMP @ MIT-MC, ED @ MIT-MC
4799 Sometimes you are running some program and type ahead something you
4800 didn't really want. Perhaps when that typeahead is read it will flush
4801 valuable typeout on your screen, and perhaps also ^Z would have
4802 similar unwanted effects. Suppose you just wanted flush whatever
4803 pending typein there is.
4805 There is now a new BACKNEXT command: ^_^U is CLEAR INPUT.
4806 This flushes your TTY input buffer, very similar to if
4807 a .RESET had been done at it.
4809 It's in the source and patched in the running ITS. Minor bug: I am
4810 not entirely sure how to get the ^U to echo, will look at this with
4811 MOON later on this week or something.
4813 So, you can do things like this:
4817 (SLEEP 6.)FOOBAR ^_^U ;typein cancelled before finished nap
4818 T ;the "foobar " was thrown away.
4822 Stay tuned for more exciting news...
4824 Date: 15 January 1984 22:10 EST
4825 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
4826 To: BUG-ITS @ MIT-MC
4828 I was using ITS at the time KMP noted the crash. I don't know if this
4829 was referring to my tty buffer or if this happened to others, but I was using
4830 EMACS at the time and all of a sudden got a logout message at the
4831 cursor position. Thereafter after each keystroke I got three more characters.
4832 I also got the following BYE message, but unfortunately the nick-name of
4833 the person ran off the edge of the screen. I kept pressing keys and
4834 getting more characters until I eventually got nothing, and then it
4837 Date: 15 January 1984 18:38 EST
4838 From: Kent M Pitman <KMP @ MIT-MC>
4839 Subject: MC crashed in tty code (TYOOU1+5; buffer ptr past eob)
4840 To: BUG-ITS @ MIT-MC
4842 In ITS in NEX 342, Emacs 162, Teco 1171, ITS 1359 on MIT-MC:
4844 ITS stopped with he following message:
4845 TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER
4846 The PC was TYOOU1+5.
4847 I dumped this to CRASH;TYOOU1 +5
4850 Date: 12 January 1984 05:24 EST
4851 From: Ken Harrenstien <KLH @ MIT-MC>
4853 cc: BUG-ITS @ MIT-MC, DCP @ MIT-MC, REM @ MIT-MC
4855 I suspect REM's problems have more to do with the TAC than with MC.
4856 I use MC every day via the net, from SRI-NIC, and response seems
4857 pretty good to me. I wonder if other TAC users have the same problems
4858 (whatever they are).
4860 Date: 12 January 1984 01:44 EST
4861 From: David C. Plummer <DCP @ MIT-MC>
4863 cc: BUG-ITS @ MIT-MC, DCP @ MIT-MC, REM @ MIT-MC
4865 Date: 11 January 1984 22:58 EST
4866 From: Bill Gosper <RWG @ MIT-MC>
4868 Although DCP's patch has cured the monster hangups in MC net service,
4869 echoing and typing are still pathologically slow these past weeks.
4870 REM is similarly mistreated via the arpanet.
4871 Gosper is a 9600 baud land line and a microwave away from MC.
4872 Just about any traffic on the land line will cause realtime
4873 delays. When only a microwave link away I notice very few
4874 hangups, and they are only for less than 1 second (I would guess
4875 they are about .7 seconds but I can't really tell).
4877 Date: 11 January 1984 22:58 EST
4878 From: Bill Gosper <RWG @ MIT-MC>
4879 To: BUG-ITS @ MIT-MC
4880 cc: DCP @ MIT-MC, REM @ MIT-MC
4882 Although DCP's patch has cured the monster hangups in MC net service,
4883 echoing and typing are still pathologically slow these past weeks.
4884 REM is similarly mistreated via the arpanet.
4886 Date: 10 January 1984 04:45 EST
4887 From: Ken Harrenstien <KLH @ MIT-MC>
4889 cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC
4891 Date: 9 January 1984 22:59 EST
4892 From: Kent M Pitman <KMP @ MIT-MC>
4894 Hmm. I just sent mail to BUG-FINGER asking :NAME KMP@OZ
4895 was replying right away with
4897 Could not connect to foreign host with TCP.
4899 but in fact, :OZ is doing this, too, so something must
4900 be confused with the network.
4902 Either a host table got written out which had OZ's arpanet
4903 address in it, or OZ was down and the NETWRK error analysis code
4904 doesn't know how to handle it properly (maybe because it doesn't
4905 know whether the connection attempt was using CHAOS or TCP).
4906 I re-did the NETWRK package to report TCP errors properly, but
4907 I don't know whether this will help or not. I doubt many programs
4908 have been recompiled with the new NETWRK yet.
4910 Date: 9 January 1984 22:59 EST
4911 From: Kent M Pitman <KMP @ MIT-MC>
4912 To: BUG-ITS @ MIT-MC
4913 cc: BUG-NAME @ MIT-MC
4915 Hmm. I just sent mail to BUG-FINGER asking :NAME KMP@OZ
4916 was replying right away with
4918 Could not connect to foreign host with TCP.
4920 but in fact, :OZ is doing this, too, so something must
4921 be confused with the network.
4923 Date: 7 January 1984 15:00 EST
4924 From: Kent M Pitman <KMP @ MIT-MC>
4925 Sender: KMP0 @ MIT-MC
4926 To: BUG-ITS @ MIT-MC
4928 MC has been getting parity errors (three in the last hour)...
4930 14:16:12 #5 PC = 310000,,017213, JOB# 26, USR: TORBEN L
4931 ERR ADDR = 602005433716
4933 5,,433717 512500,,400
4935 14:41:18 #6 PC = 710000,,107117, JOB# 66, USR: GIF HACTRN
4936 ERR ADDR = 602004377116
4938 4,,377117 211102,,403
4940 14:41:33 #7 PC = 710000,,107117, JOB# 66, USR: GIF HACTRN
4941 ERR ADDR = 602004377116
4945 In case it matters, the machine room seems quite cool and dry
4948 Date: 6 January 1984 02:30 EST
4949 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4950 Subject: your patch is on disk now
4952 cc: BUG-ITS @ MIT-MC
4953 In-reply-to: Msg of 6 Jan 1984 02:14 EST from David C. Plummer <DCP>
4956 You were trying to dump out a patched ITS BIN file instead of a world
4957 load. I don't know offhand know why this doesn't work, but I patched
4958 the NITS world load and dumped it out as XITS. I'll reassemble the
4959 system tomorrow probably anyway...
4962 Date: 6 January 1984 02:14 EST
4963 From: David C. Plummer <DCP @ MIT-MC>
4964 To: BUG-ITS @ MIT-MC, BUG-TWENEX @ MIT-MC
4965 cc: CHAOS-NCP-PEOPLE @ MIT-MC, RWG @ SPA-NIMBUS
4967 I have patched MC so that it only retransmits the first packet on
4968 the transmit queue instead of the entire queue. There are a few
4969 theories that say this is a reasonable thing to do. Its greatest
4970 impact is on the slow links which do packet filtering to avoid
4971 complete congestion.
4973 I would update the on disk version, but the
4977 method doesn't seem to work. (Actually, the resulting file was 7
4978 or so blocks shorter.) So, if somebody could update the disk
4979 version, or make the patch each time ITS is booted, it would be
4980 appreciated. The patch is
4981 CHART2-1/ JFCL (was JUMPN A,CHART1)
4982 I have updated the source.
4984 Bug-Twenex people: the equivalent source change (if the Dec 10,
4985 1983 code on EE:LIB:<5.MONITOR>CHAOS.MAC is anywhere near correct
4986 (OZ and SPEECH won't talk to me and I couldn't find it on XX) is
4988 JRST CHART1 at CHARTD-1
4989 and replace it with the comment
4990 ;; fall through, since we only retransmit one packet of the list.
4991 This can also be patched to a JFCL if you want to test it.
4993 Other people: You may want to do (or at least try) similar things.
4995 Date: 4 January 1984 00:46 EST
4996 From: Christopher C. Stacy <CSTACY @ MIT-MC>
4998 cc: BUG-ITS @ MIT-MC
4999 In-reply-to: Msg of 3 Jan 1984 23:35 EST from Alan Bawden <ALAN>
5001 Date: 3 January 1984 23:35 EST
5002 From: Alan Bawden <ALAN>
5005 What happened to the source of SYS:ATSIGN DEVICE?
5007 The source does not seem to be online anywhere, and is not on MC's
5008 backup tape. I'll go looking for it on AI backup tape later on.
5010 Date: 3 January 1984 23:35 EST
5011 From: Alan Bawden <ALAN @ MIT-MC>
5012 To: BUG-ITS @ MIT-MC
5014 What happened to the source of SYS:ATSIGN DEVICE?
5016 Date: 21 December 1983 04:48 EST
5017 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5019 To: BUG-ITS @ MIT-MC, USER-ACCOUNTS @ MIT-MC
5020 cc: BUG-PWORD @ MIT-MC
5023 The PWORD accounts database was clobbered tonite somehow, apparently
5024 when the system crashed due to memory parity errors. (The DSK module
5025 was reporting them so I assume this means it was during disk DMA.)
5026 Apparently the file was clobbered when the system crashed, it has been
5027 zeroed or had some pointers shuffled or something -- I haven't looked
5028 at it yet but the file was still the correct length. I was under the
5029 impression that this sort of thing could not happen.
5031 USER-A people: Anyway, we got it back off of tape from Monday.
5035 Date: 18 December 1983 12:13 EST
5036 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5038 cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
5039 In-reply-to: Msg of 17 Dec 1983 12:34 EST from "Richard Kovalcik, Jr." <RK>
5042 Date: 17 December 1983 12:34 EST
5043 From: "Richard Kovalcik, Jr." <RK>
5044 To: BUG-ITS, BUG-TCP
5047 Any reason why MC is making outgoing TCP/IP connections but
5048 not accepting incoming ones? Mail is still backing up for MC
5049 on various sites becuase of this.
5052 For a while the system was in debug mode which does this.
5054 Date: 17 December 1983 12:34 EST
5055 From: "Richard Kovalcik, Jr." <RK @ MIT-MC>
5056 To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC
5059 Any reason why MC is making outgoing TCP/IP connections but not accepting incoming ones?
5060 Mail is still backing up for MC on various sites becuase of this.
5064 P.S. Both telnet and smtp gets resets immediately when you try to open to
5065 them from both CISL and MIT-Multics.
5067 Date: 15 December 1983 18:23 EST
5068 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
5069 To: BUG-WHOIS @ MIT-MC
5070 cc: BUG-ITS @ MIT-MC
5072 Date: 8 December 1983 01:29 EST
5073 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5075 cc: BUG-FINGER @ MIT-MC, BUG-HOSTS @ MIT-MC
5076 In-reply-to: Msg of 7 Dec 1983 16:36 EST from Patrick G. Sobalvarro <PGS>
5078 Date: 7 December 1983 16:36 EST
5079 From: Patrick G. Sobalvarro <PGS>
5080 To: BUG-FINGER, BUG-HOSTS
5082 As of today, doing :f @oz on mc get me the error message "Could not
5083 connect to foreign host with TCP." Crufty, crufty lossage.
5085 ":F @OZ" works fine for me on MC.
5086 Maybe there is a bug in the ANALYZ code in the ITS NETWRK package, and
5087 when it could not connect to OZ over the Chaosnet it decided to give
5088 the most general TCP error message.
5090 This is the second time this bug has bitten me. ML is up right now. On MC,
5091 I did :whois pgs@ml. I immediately (not long enough for a chaos connection
5092 attempt to time out, but immediately) got the error message "Could not
5093 connect to foreign host with TCP." Immediately after that, it worked.
5095 Date: 12 December 1983 07:59 EST
5096 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5097 To: BUG-ITS @ MIT-MC
5099 Since all the INFO stuff is on FOURTH:, I can't read documentation
5100 that I want while the system is crippled.
5102 Date: 10 December 1983 10:05 EST
5103 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
5106 cc: BUG-ITS @ MIT-MC, ITS-LOVERS @ MIT-MC
5107 In-reply-to: Msg of 10 Dec 1983 01:50 EST from Alan Bawden <ALAN>
5109 Date: 10 December 1983 01:50 EST
5110 From: Alan Bawden <ALAN>
5115 Anybody have any idea where MC:SYS;FORMAT EXE came from? (Perhaps some
5116 subversives are planning on bringing 20X up on MC?)
5118 I'd bet that this was a case of someone cftping it over and saying yes to the
5119 stupid cftp defaults. Why the might have wanted to cftp it over, I don't
5120 know. Those cftp defaults have never ever been useful to me. If cftp did
5121 filename-merging, maybe they would be.
5123 Date: 10 December 1983 01:50 EST
5124 From: Alan Bawden <ALAN @ MIT-MC>
5126 To: BUG-ITS @ MIT-MC
5127 cc: ITS-LOVERS @ MIT-MC
5129 Anybody have any idea where MC:SYS;FORMAT EXE came from? (Perhaps some
5130 subversives are planning on bringing 20X up on MC?)
5132 Date: 9 December 1983 11:37 EST
5133 From: Leigh L. Klotz <KLOTZ @ MIT-MC>
5134 Subject: Weirdness...
5136 cc: BUG-ITS @ MIT-MC
5137 In-reply-to: Msg of 9 Dec 1983 01:23 EST from Eric P. Scott <EPS>
5139 You probably got a parity error.
5141 Date: 9 December 1983 01:31 EST
5142 From: Eric P. Scott <EPS @ MIT-MC>
5143 Subject: Weirdness (3)
5144 To: BUG-ITS @ MIT-MC
5146 I :SNARFed a CHTN and got (BADPI;IOCH12;IOCH0;) 2203>>.HANG 0/ 0
5147 This just isn't my day.
5150 Date: 9 December 1983 01:28 EST
5151 From: Eric P. Scott <EPS @ MIT-MC>
5152 Subject: Weirdness (2)
5153 To: BUG-ITS @ MIT-MC
5155 (BADPI;INF0;) 135252>>TDNN 2, 2/ 10000,,0 0/ 0
5156 I :PDUMPed it to USERS1;EPS DEADDT if anyone cares.
5160 Date: 9 December 1983 01:23 EST
5161 From: Eric P. Scott <EPS @ MIT-MC>
5162 Subject: Weirdness...
5163 To: BUG-ITS @ MIT-MC
5165 I got a tree detached by top-level interrupt followed by
5166 MC ITS REVIVED. No one else seems to have been affected.
5170 Date: 4 December 1983 23:07 EST
5171 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5172 Subject: hanging up phone lines
5174 cc: BUG-ITS @ MIT-MC
5175 In-reply-to: Msg of 4 Dec 1983 17:43 EST from Charles Frankston <CBF>
5178 Date: 4 December 1983 17:43 EST
5179 From: Charles Frankston <CBF>
5181 Re: hanging up phone lines
5183 ITS needs better facilities for hanging up dialup lines. Since most other
5184 computers nowadays automatically hangup the phone line after logout
5185 (either immediately or with a short timeout), I think some users don't
5186 realize that they have to do this manually on ITS.
5188 I don't believe ML has the hardware to hangup a line. The I/O and Console
5189 11's on MC have the appropriate hardware but don't give the pdp10 any way
5190 to control the appropriate bits.
5192 There used to be this .HANGUP UUO...maybe there should be a system
5193 call for reading and frobbing arbitrary bits on tty lines in the pdp-11.
5195 .HANGUP dialnum, ANCIENT HISTORY hang up a dialed line
5198 This uuo NO LONGER EXISTS.
5199 It is documented here for historical purposes only.
5200 Its function is obsolete.
5201 Its opcode has been recycled as .REVIVE.
5203 This uuo was used to hang up on a line which had
5204 been dialed by the .DIAL uuo.
5206 Date: 4 December 1983 17:43 EST
5207 From: Charles Frankston <CBF @ MIT-MC>
5208 Subject: hanging up phone lines
5209 To: BUG-ITS @ MIT-MC
5211 ITS needs better facilities for hanging up dialup lines. Since most other
5212 computers nowadays automatically hangup the phone line after logout
5213 (either immediately or with a short timeout), I think some users don't
5214 realize that they have to do this manually on ITS.
5216 I don't believe ML has the hardware to hangup a line. The I/O and Console
5217 11's on MC have the appropriate hardware but don't give the pdp10 any way
5218 to control the appropriate bits. At worst something like to LSPEED
5219 command could be used to hangup a line. At best the system would use the
5220 same sorts of timeouts it uses to close STY channels. If I get some time
5221 after the term I might look at the LSPEED covert channel. Informed
5222 suggestions on other approaches would be welcome.
5224 Date: Friday, 2 December 1983, 00:44-EST
5225 From: David Vinayak Wallace <Gumby at MIT-MC>
5226 Subject: safe site ap8
5227 To: Pandora B. Berman <CENT at MIT-MC>
5228 Cc: TIM at MIT-MC, BUG-ITS at MIT-MC, user-a at MIT-MC
5229 In-reply-to: The message of 2 Dec 83 00:00-EST from Pandora B. Berman <CENT at MIT-MC>
5231 Date: 2 December 1983 00:00 EST
5232 From: Pandora B. Berman <CENT @ MIT-MC>
5233 TIM@MIT-MC 11/29/83 05:35:55
5234 Hmm, MC thinks that AP8 is an "insecure" site. Who/how does this get
5237 it's built into something. i don't know how to change, but surely someone
5240 I fixed this for MC and ML.
5242 Date: 2 December 1983 00:00 EST
5243 From: Pandora B. Berman <CENT @ MIT-MC>
5246 cc: BUG-ITS @ MIT-MC
5248 TIM@MIT-MC 11/29/83 05:35:55
5249 Hmm, MC thinks that AP8 is an "insecure" site. Who/how does this get
5250 changed? (it's not THAT big a deal, but it probably doesn't know about
5251 other relatively new machines either).
5253 it's built into something. i don't know how to change, but surely someone
5256 Date: 15 November 1983 03:27 EST
5257 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5260 cc: BUG-ITS @ MIT-MC
5262 Date: 10/28/83 13:55:33
5265 If you do c-X c-F DIR: KMP; FIRST KMP, you'll note that Emacs thinks
5266 this is a link to KMP; DIR: FIRST KMP ... Is it possible that DIR: is
5267 not handling the LNKDP system call (or whatever it's called) correctly?
5269 It's called LNKEDP, and I just fixed DIR: to handle it properly.
5270 Installed on MC, old version in DEVICE;JOBDEV ODIR.
5272 Date: 15 November 1983 03:08 EST
5273 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5274 Subject: DIR device rescued
5276 cc: BUG-ITS @ MIT-MC
5279 Suffering arbitrary amounts of tedium, I just now recovered the source
5280 code to the DIR device from DM backup tape and put it in SYSENG;.
5281 I sure hope nothing else important was forgotten over there.
5284 Date: 15 November 1983 03:01 EST
5285 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5288 cc: BUG-ITS @ MIT-ML
5289 In-reply-to: Msg of 11/15/83 00:34:36 from SHAWN at MIT-ML
5292 HOSTAT can not work anymore, since it wants to talk to DM's
5293 host status SURVEY server. Rewriting something similar is
5294 on my list of things to do in my spare time.
5298 SHAWN@MIT-ML 11/15/83 00:34:36 Re: hostat
5299 To: (BUG ITS) at MIT-ML
5301 ERROR: OPEN: DSK: SYSBIN; HOSTS1 > - FILE NOT FOUND
5302 4146>>.CALL 4434 (OPEN)
5306 Date: 10 November 1983 15:09 EST
5307 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5310 cc: BUG-ITS @ MIT-MC, DIGEX @ MIT-MC, KFL @ MIT-MC
5311 In-reply-to: Msg of 10 Nov 1983 11:10 EST from Devon S. McCullough <DEVON>
5314 I have a program called LOGN which I run when I log in.
5315 I will check it out and release it for you later today.
5316 It does the right thing with TAC binary mode, also also hacks TTYLOCs.
5317 There is another program called TBMOFF for my logout file (to turn TAC
5321 Date: 10 November 1983 11:10 EST
5322 From: Devon S. McCullough <DEVON @ MIT-MC>
5325 cc: DEVON @ MIT-MC, DIGEX @ MIT-MC, KFL @ MIT-MC, BUG-ITS @ MIT-MC
5327 What's the correct way for a LOGIN init file to send
5328 IAC DO TRBIN and IAC WILL TRBIN to a TAC?
5332 $(:$ do trbin $ imgout 377 375 0
5335 works in most cases, except for the %TDQOT screw if your TCTYP is %TNSFW
5336 since then the TAC sees a %TDQOT before every character of the IAC sequence.
5337 I suppose I could save the value of TCTYP in DT somewhere, set TCTYP to zero,
5338 execute the IMGOUT program and then restore TCTYP, but it's not exactly
5339 clear to me how to do this, can it be done from DDT or must a program do it?
5340 If so, I will just write a hacked-up version of IMGOUT called TAC which
5341 accepts TAC commands and sends them.
5343 Every time I vary my procedures even slightly I get screwed by %TDQOT and
5344 TCTYP SOFT not knowing at what level to strip off the %TDQOT's...
5346 but my solution for a :TAC Binary Output Start is still wrong, since if
5347 the poor loser is using CRTSTY he will probably be screwed. Perhaps
5348 what we really need is a %TDIAC code which is simply intended for
5349 telling TELSER to try to frob the protocol in some way.
5351 Date: 30 October 1983 21:35 EDT
5352 From: George J. Carrette <GJC @ MIT-MC>
5353 To: BUG-ITS @ MIT-MC
5356 HOSTS 666 written by CSR, beware.
5358 Date: 30 October 1983 21:18 EDT
5359 From: David A. Moon <MOON @ MIT-MC>
5360 Subject: That ITS out-of-low-core bug
5361 To: BUG-ITS @ MIT-MC
5363 Fixed in the source. I will come over probably some time this
5364 week and find the subtle bugs I no doubt introduced into the system;
5365 I wouldn't recommend trying to install the changes I made without me.
5368 Date: 30 October 1983 18:59 EDT
5369 From: Kent M. Pitman <KMP @ MIT-MC>
5370 Subject: ITS wedgeding
5371 To: MOON @ SCRC-TENEX
5372 cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC,
5373 JPG @ MIT-MC, TAFT @ MIT-MC, KLH @ SRI-NIC
5374 In-reply-to: Msg of 29 Oct 1983 15:59-EDT from MOON at SCRC-TENEX
5376 Date: Saturday, 29 October 1983 15:59-EDT
5377 From: MOON at SCRC-TENEX
5379 ... Lack of low core could not affect echoing on local terminals, and would
5380 only affect echoing on network terminals if there wasn't enough core to
5381 make network packet buffers. Of course maybe the users were confused
5382 and what they really meant was that their programs were busted.
5384 I was on just before it died. Echo time might not be the right phrase.
5385 The slowness was of the following sort... I typed :SRCCOM ...<return>
5386 and waited a long time but gotten no output. Echo time for that time was
5387 normal. I finally typed ^G and
\e\eV. The
\e\eV did not echo. I typed some
5388 ^G's and maybe some other frustration chars (^D?) after a while and and
5389 found myself in a mode where I felt like what might be happening was that
5390 for every character I typed, a character would echo but it was out of
5391 phase by several characters with my input. The output from the
\e\eV, by the
5392 way, indicated that the SRCCOM job had not loaded. Finally, though,
5393 no more input of any sort would echo, so I gave up and closed my connection.
5396 Date: 30 October 1983 09:20 EDT
5397 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5400 cc: BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, KLH @ MIT-MC,
5401 KMP @ MIT-MC, TAFT @ MIT-MC, moon @ SCRC-TENEX
5402 In-reply-to: Msg of 30 Oct 1983 09:16 EDT from Jeffrey P. Golden <JPG>
5405 No, this is all long before a HACTRN has been created.
5407 Date: 30 October 1983 09:16 EDT
5408 From: Jeffrey P. Golden <JPG @ MIT-MC>
5410 To: CSTACY @ MIT-MC, moon @ SCRC-TENEX
5411 cc: BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, KLH @ MIT-MC,
5412 KMP @ MIT-MC, TAFT @ MIT-MC, JPG @ MIT-MC
5414 Date: Saturday, 29 October 1983 16:02-EDT
5415 From: MOON at SCRC-TENEX
5416 To: Christopher C. Stacy <CStacy at MIT-MC>
5417 Cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
5418 KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC
5419 Subject: ITS wedgeding
5420 In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
5422 Oh by the way, I forgot to mention about the job that had two disk
5423 channels open, where one was to "RAT;". The mode printed by Peek C
5424 mode for that channel was "RU", meaning that it was reading a
5425 directory ("UFD"). Probably this channel really belonged to some
5426 other job and peek was confused.
5427 Is the question: Why RAT; ?
5428 If so, isn't PWORD the answer?
5430 Date: 30 October 1983 09:08 EDT
5431 From: Jeffrey P. Golden <JPG @ MIT-MC>
5433 To: BUG-ITS @ MIT-MC, MOON @ SCRC-TENEX
5436 Date: Saturday, 29 October 1983, 22:54-EDT
5437 From: David A. Moon <Moon@SCRC-TENEX>
5438 To: Jeffrey P. Golden <JPG@MIT-MC>
5439 Cc: GSB@MIT-MC, BUG-ITS@MIT-MC
5440 The idea is to have a system there that works well enough that you
5441 can bring it up and run DUMP to load backup tapes. It doesn't have
5442 to support networks, terminals, etc.
5443 I agree with the idea. But if it is to work:
5444 [1] There should be a -READ- -THIS- file there which lists the key
5445 files that should be present on the BACKUP; direc.
5446 [2] Someone should look over that directory and delete useless or
5447 harmful files and replace them by the necessary files so that the idea
5448 Dave mentions can be carried out if it should ever be necessary.
5450 Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 29-Oct-83 22:51:38-EDT
5451 Date: Saturday, 29 October 1983, 22:54-EDT
5452 From: David A. Moon <Moon@SCRC-TENEX>
5453 To: Jeffrey P. Golden <JPG@MIT-MC>
5454 Cc: GSB@MIT-MC, BUG-ITS@MIT-MC
5455 In-reply-to: The message of 14 Oct 83 04:46-EDT from Jeffrey P. Golden <JPG at MIT-MC>
5457 Date: 14 October 1983 04:46 EDT
5458 From: Jeffrey P. Golden <JPG @ MIT-MC>
5459 GSB@MIT-MC 10/13/83 17:44:25 Re: MC directory slot
5460 BACKUP; is for backup copies of things on .; and occasionally other things.
5461 Why can't .; itself be used for this? For the couple of true backup @ files,
5462 which have the same names as files on .; , e.g. CRASH; would work fine.
5465 It should be preserved, and it does get updated occasionally.
5466 The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe
5467 almost everything there is garbage. If BACKUP; were trully for backup
5468 then leaving non-working stuff on that directory as is now the case
5469 may be hazardous for MC's health if ever invoked.
5471 I believe that it has proven itself useful on ML at least.
5472 I see no recent proof of this for MC:BACKUP; .
5474 The idea is to have a system there that works well enough that you
5475 can bring it up and run DUMP to load backup tapes. It doesn't have
5476 to support networks, terminals, etc.
5478 Date: Saturday, 29 October 1983 16:02-EDT
5479 From: MOON at SCRC-TENEX
5480 To: Christopher C. Stacy <CStacy at MIT-MC>
5481 Cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
5482 KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC
5483 Subject: ITS wedgeding
5484 In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
5486 Oh by the way, I forgot to mention about the job that had two disk
5487 channels open, where one was to "RAT;". The mode printed by Peek C
5488 mode for that channel was "RU", meaning that it was reading a
5489 directory ("UFD"). Probably this channel really belonged to some
5490 other job and peek was confused.
5492 Date: Saturday, 29 October 1983 15:59-EDT
5493 From: MOON at SCRC-TENEX
5494 To: Christopher C. Stacy <CStacy at MIT-MC>
5495 Cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC,
5496 KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC,
5498 Subject: ITS wedgeding
5499 In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
5501 Date: Saturday, 29 October 1983, 01:52-EDT
5502 From: Christopher C. Stacy <CStacy at MIT-MC>
5503 Subject: ITS wedgeding
5504 To: BUG-ITS at MIT-MC
5505 Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX,
5506 ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC
5508 TAFT@MIT-MC 10/28/83 14:31:11 Re: Crash of 10/28 14:27
5509 MC was catatonic, but running. Though jobs could be logged in, no
5510 response to anything other than ^G could be obtained. I checked
5511 around that this was really the case and then stopped it.
5514 MC was also merrily printing lots of my little "Warning: <out of this
5515 or that>" messages every chance it got.
5517 In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24,
5518 IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC:
5520 There is definitely something weird going on here.
5521 Of the 50 disk channels, none are free.
5522 There is no more free low core (for making file or network buffers.)
5524 There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot.
5525 They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP,
5526 respectively. They all have read 0% of their file.
5528 We can look at a representative wedged server job: user idx 101.
5529 ___101 TCP, is blocked inside a LOAD call: NLOADD+6/ SKIPG QSFBS(A) A/ 40
5530 I don't entirely grok this disk code yet, but from the channel state
5531 (%QALBK) and mode (READ/USER DATA), and the comment where he blocks,
5532 it looks like he is waiting for the file channel to receive a buffer
5533 with the first page of the TCPSER file.
5535 Also, there may also be something weird file-wise with this particular job.
5536 Unlike the others, I think it has two (QUSR idx) channels: 17 and 40.
5537 According to PEEK, he is also opened RAT; (no file name), which I
5538 guess accounts for channel 17. But, huh? What? Why?
5540 Now, the TCP situation shows that there can be up to 180. packet
5541 buffers, of which zero are free out of a total zero allocated.
5543 I checked in XBUSER and friends.
5544 There is only one TCP frob around, and he's not doing a whole lot:
5545 TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL.
5546 Has received FIN for input, State is "Last ACK".
5547 User channel state: (input) Foreign host RESET, retransmit timeout (output).
5548 The close reason is: Closed by user, Closed by foreign host.
5550 This is (I think) reasonable, but does not account for all those other TCP servers!
5553 1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY
5554 NETWORK CONNECTIONS? Is it that the connections went away
5555 before the jobs had a chance to get started, or what?
5556 What are all these jobs for, anyway?
5558 They have to load their programs before they can open their network
5559 connection. The incoming RFC (SYN in the TCP case) that started these
5560 jobs probably timed out and was rejected before you dumped the system,
5561 hence no trace of it was left. If they're trying to load the ATSIGN xxx
5562 program (rather than the actual server) that means they haven't even
5563 yet queried the system's RFC (SYN) queue to find out what contact name
5564 (port number) they are supposed to serve.
5566 The system is supposed to filter out duplicate RFCs and SYNs, so if that's
5567 working each of those jobs was created by a separate user attempt to connect.
5568 Of course if they block forever in the LOAD system call, once created they
5571 2. WHERE DID ALL THE LOW CORE GO?
5572 This seems to be the reason those server jobs can't get going.
5574 The lack of low core is indeed the reason the servers can't get going; they
5575 can't get a buffer to use to read their disk files they're trying to load.
5576 Even in PDUMP format the first page of the file has to be read into low core
5577 to find out what pages are to be loaded.
5579 One reason for lack of low core is bloatage of directories. I've been meaning
5580 to make a straightfoward but not totally simple fix to allow directories to
5581 be stored anywhere in core, but haven't got around to it. I guess you should
5582 bug me about this periodically.
5584 However, in this case that isn't the problem: there are only 9 pages of
5585 directories (DSKUDR in Peek M mode) plus 7 pages of disk buffers. I looked
5586 around at the MEMBLT and MEMPNT tables. A lot of the low core pages are
5587 just user pages of job 100, a worthless TEX job. See the large comment
5588 a few lines below SWPOPG; evidently the system keeps trying to swap
5589 out more and more pages to get some low memory, but keeps swapping out
5592 The right fix is to make it specifically swap out pages in "low" memory
5593 (as counted by LMEMFR) in this case, or else to put the core shuffler
5594 back in to move those pages to "high" memory. Maybe I'll look into this
5595 in a few days when I get time.
5597 3. I heard that typein was echoing very slowly for users during this
5598 wedged period. I wonder if this was true, it was it true for local
5599 consoles as well as STYs? I don't really understand why this should
5600 be, in either case. When the system is running out of core, I have
5601 usually been able to do SYS$J (provided there was a channel for me
5602 to .OPEN on USR:) and look around.
5604 Lack of low core could not affect echoing on local terminals, and would only
5605 affect echoing on network terminals if there wasn't enough core to make
5606 network packet buffers. Of course maybe the users were confused and
5607 what they really meant was that their programs were busted.
5609 Date: 29 October 1983 01:13 EDT
5610 From: Alan Bawden <ALAN @ MIT-MC>
5611 To: BUG-ITS @ MIT-MC
5613 Perhaps someone could write a demon that ran at system startup time that
5614 would look for files whose authors were set to non-existent directories and
5615 set them to be unknown. That way we would avoid recycled directories
5616 claiming that they authored files that were written by people now gone.
5618 I think about this now because I just noticed that MC:SYS1;TS STINK was
5619 authored by the newly created directory VASL...
5621 Date: Saturday, 29 October 1983, 01:52-EDT
5622 From: Christopher C. Stacy <CStacy at MIT-MC>
5623 Subject: ITS wedgeding
5624 To: BUG-ITS at MIT-MC
5625 Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX,
5626 ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC
5628 TAFT@MIT-MC 10/28/83 14:31:11 Re: Crash of 10/28 14:27
5629 MC was catatonic, but running. Though jobs could be logged in, no
5630 response to anything other than ^G could be obtained. I checked
5631 around that this was really the case and then stopped it.
5634 MC was also merrily printing lots of my little "Warning: <out of this
5635 or that>" messages every chance it got.
5637 In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24,
5638 IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC:
5640 There is definitely something weird going on here.
5641 Of the 50 disk channels, none are free.
5642 There is no more free low core (for making file or network buffers.)
5644 There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot.
5645 They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP,
5646 respectively. They all have read 0% of their file.
5648 We can look at a representative wedged server job: user idx 101.
5649 ___101 TCP, is blocked inside a LOAD call: NLOADD+6/ SKIPG QSFBS(A) A/ 40
5650 I don't entirely grok this disk code yet, but from the channel state
5651 (%QALBK) and mode (READ/USER DATA), and the comment where he blocks,
5652 it looks like he is waiting for the file channel to receive a buffer
5653 with the first page of the TCPSER file.
5655 Also, there may also be something weird file-wise with this particular job.
5656 Unlike the others, I think it has two (QUSR idx) channels: 17 and 40.
5657 According to PEEK, he is also opened RAT; (no file name), which I
5658 guess accounts for channel 17. But, huh? What? Why?
5660 Now, the TCP situation shows that there can be up to 180. packet
5661 buffers, of which zero are free out of a total zero allocated.
5663 I checked in XBUSER and friends.
5664 There is only one TCP frob around, and he's not doing a whole lot:
5665 TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL.
5666 Has received FIN for input, State is "Last ACK".
5667 User channel state: (input) Foreign host RESET, retransmit timeout (output).
5668 The close reason is: Closed by user, Closed by foreign host.
5670 This is (I think) reasonable, but does not account for all those other TCP servers!
5673 1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY
5674 NETWORK CONNECTIONS? Is it that the connections went away
5675 before the jobs had a chance to get started, or what?
5676 What are all these jobs for, anyway?
5678 2. WHERE DID ALL THE LOW CORE GO?
5679 This seems to be the reason those server jobs can't get going.
5681 3. I heard that typein was echoing very slowly for users during this
5682 wedged period. I wonder if this was true, it was it true for local
5683 consoles as well as STYs? I don't really understand why this should
5684 be, in either case. When the system is running out of core, I have
5685 usually been able to do SYS$J (provided there was a channel for me
5686 to .OPEN on USR:) and look around.
5689 Does anybody recognize these symptoms?
5690 (I have never tried to debug an ITS when it had not crashed at some
5691 definite place; I am relatively new at all this.)
5692 I have not yet looked to try to find what all the core is allocated
5693 to. I'll do that next sitting. I'd like people's thoughts on whether
5694 they think this is a bug, or what. I vaugely remember KLH saying
5695 something about this; maybe he has some idea what is going on.
5700 Date: 26 October 1983 23:54 EST
5701 From: Keith F. Lynch <KFL @ MIT-MC>
5703 To: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
5706 MC is claiming to have been up for 334 days.
5709 Date: 25 October 1983 12:14 EDT
5710 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5711 Subject: ZUSER crash of 10/25/83
5712 To: BUG-ITS @ MIT-MC
5715 In crashed ITS 1353, CRASH;ITS LZUSUE, on MIT-MC:
5717 The system crashed because it was trying to finish logging out
5718 ___071, who had a current inferior job with one page still in core.
5719 It was a NAME (jname "F"), and it looks like it had just started
5720 loading - it had an open file channel which had read 0 wds in.
5722 Another weird thing is that his USYSN1 was 'SUPDUP', not the same as
5723 his reasonable USYSNM.
5725 That's about as far as I think I am going go with this: this info
5726 might be useful if a similar thing ever happens again. I wonder
5727 if it could be some kind of timing screw.
5729 Date: 22 October 1983 17:14 EDT
5730 From: George J. Carrette <GJC @ MIT-MC>
5731 To: BUG-ITS @ MIT-MC
5733 this isn't an its bug, just something I have noticed about TCP,
5734 both on XX and MC. Well, I can never seem to get more than about
5735 7kbps transfer rate now, and usually get only about 3 or 4kbps
5736 on FTP. The net used to be much faster under NCP. The price
5739 Date: 21 October 1983 15:18 EDT
5740 From: Kent M. Pitman <KMP @ MIT-MC>
5742 cc: BUG-ITS @ MIT-MC
5744 ITS crashed at 2:30. It was a BUGHALT, BUGPC/ 8 CAI LZUSUE R2+12
5745 $Q-1/ PUSHJ P, BUGNIL
5746 I dumped this to CRASH;LZUSUE and reloaded the system.
5748 Date: 17 October 1983 16:42 EDT
5749 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5750 Subject: ARPANET<->MILNET
5752 cc: BUG-ITS @ MIT-MC, JSOL @ MIT-MC
5753 In-reply-to: Msg of 16 Oct 1983 15:39 EDT from David C. Plummer <DCP>
5755 Date: 16 October 1983 15:39 EDT
5756 From: David C. Plummer <DCP>
5760 Date: 16 October 1983 15:12 EDT
5761 From: Jon Solomon <JSOL @ MIT-MC>
5763 I don't know where to send this, but when you telnet from a chaos host
5764 using either MC's or ML's gateway, it doesn't seem to allow you to
5765 gateway to hosts which are not on Net-10. This includes LCS hosts,
5766 MILNET hosts, and BBN-NET hosts for starters.
5768 This is either a host table lossage (BBNC appears to be
5769 registered on MILNET), which I doubt, or this is the result of
5770 the MILNET split, in which case you aren't ALLOWED to telnet from
5771 ARPANET to MILNET. Fun, eh?
5773 No, TELNET and FTP are not yet administratively prohibited services
5774 between ARPANET and MILNET.
5777 Date: 17 October 1983 16:38 EDT
5778 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5779 Subject: TCP server doesnt work off net 10.
5781 cc: BUG-ITS @ MIT-MC
5782 In-reply-to: Msg of 16 Oct 1983 15:12 EDT from Jon Solomon <JSOL>
5785 You didn't say what system you were using the TCP server from, or what
5786 makes you think it is not working, and I suspect it might be on the
5787 other end. I am not near a Lisp machine to really test this right now,
5788 but when I halfway test it using only MC I can get a TCP connection to
5789 ISIA (a MILNET host.) I notice the TOPS-20 TELNET program on OZ does
5790 not let you connect to non-ARPANET hosts because its host table claims
5791 not to know about them. I'll make more test later.
5793 Date: 16 Oct 1983 21:40 EDT (Sun)
5794 Message-ID: <[MIT-OZ].MARTY.16-Oct-83 21:40:41>
5795 From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
5796 To: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
5797 Cc: BUG-SYSTEM%MIT-OZ@MIT-MC.ARPA, Staff%MIT-EECS@MIT-MC.ARPA,
5799 Subject: bad host table
5800 In-reply-to: Msg of 16 Oct 1983 20:29-EDT from Jon Solomon <JSOL>
5802 Date: Sunday, 16 October 1983 20:29-EDT
5803 From: Jon Solomon <JSOL>
5804 To: BUG-SYSTEM, Staff at MIT-EECS
5806 [EECS people: I don't know who to send this to on EE]
5808 Your host tables don't have the necessary changes for the MILNET
5809 split, hence no milnet hosts can be connected to.
5811 Yes, in fact *any* non-arpa internet site will appear unreachable.
5812 So I wrote a little PCL hack.
5813 Basically, our TELNET (chaos gateway version) doesn't know how to
5814 connect to non-internet sites unless you fool it.
5817 DECLARE PCL SS:<MARTY.PCL>ITN.PCL.
5818 ITN <your favorite internet/milnet site>
5820 It would be nice if we could change TELNET to forget about HOSTS2.BIN
5821 which is what it is using, and why we are losing.
5822 This will all be less important when we are directly connected to the
5825 Date: Sun, 16 Oct 1983 20:27 EDT
5826 Message-ID: <[MIT-OZ].JSOL.16-Oct-83 20:27:58>
5827 From: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
5828 To: David C. Plummer <DCP@MIT-MC.ARPA>
5829 Cc: BUG-ITS@MIT-MC.ARPA
5830 Phase-Of-The-Moon: FQ+3D.2H.6M.14S.
5831 In-reply-to: Msg of 16 Oct 1983 20:00-EDT from David C. Plummer <DCP at MIT-MC>
5833 I see, you're right. why didn't I think to check and see what was
5834 actually being fed to MC! Now I know who to send my gripe to.
5836 Date: 16 October 1983 20:00 EDT
5837 From: David C. Plummer <DCP @ MIT-MC>
5839 cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC
5841 Date: Sun, 16 Oct 1983 16:21 EDT
5842 From: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
5844 Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can
5845 telnet to them directly but OZ can't. Similarly you can telnet from
5846 ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage
5847 is in the gateway program.
5849 Works for me. From MC:
5850 :CHTN MC<alt>TCP BBNC 27
5851 connects me to BBNC.
5853 Date: Sun, 16 Oct 1983 16:21 EDT
5854 Message-ID: <[MIT-OZ].JSOL.16-Oct-83 16:21:59>
5855 From: Jon Solomon <JSOL%MIT-OZ@MIT-MC.ARPA>
5856 To: David C. Plummer <DCP@MIT-MC.ARPA>
5857 Cc: BUG-ITS@MIT-MC.ARPA
5858 Phase-Of-The-Moon: FQ+2D.22H.0M.7S.
5859 In-reply-to: Msg of 16 Oct 1983 15:39-EDT from David C. Plummer <DCP at MIT-MC>
5861 Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can
5862 telnet to them directly but OZ can't. Similarly you can telnet from
5863 ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage
5864 is in the gateway program.
5866 Date: 16 October 1983 15:39 EDT
5867 From: David C. Plummer <DCP @ MIT-MC>
5869 cc: BUG-ITS @ MIT-MC
5871 Date: 16 October 1983 15:12 EDT
5872 From: Jon Solomon <JSOL @ MIT-MC>
5874 I don't know where to send this, but when you telnet from a chaos host
5875 using either MC's or ML's gateway, it doesn't seem to allow you to
5876 gateway to hosts which are not on Net-10. This includes LCS hosts,
5877 MILNET hosts, and BBN-NET hosts for starters.
5879 This is either a host table lossage (BBNC appears to be
5880 registered on MILNET), which I doubt, or this is the result of
5881 the MILNET split, in which case you aren't ALLOWED to telnet from
5882 ARPANET to MILNET. Fun, eh?
5884 Date: 16 October 1983 15:12 EDT
5885 From: Jon Solomon <JSOL @ MIT-MC>
5886 To: BUG-ITS @ MIT-MC
5888 I don't know where to send this, but when you telnet from a chaos host
5889 using either MC's or ML's gateway, it doesn't seem to allow you to
5890 gateway to hosts which are not on Net-10. This includes LCS hosts,
5891 MILNET hosts, and BBN-NET hosts for starters.
5895 Date: 14 October 1983 04:46 EDT
5896 From: Jeffrey P. Golden <JPG @ MIT-MC>
5898 cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC
5900 GSB@MIT-MC 10/13/83 17:44:25 Re: MC directory slot
5902 CC: (BUG ITS) at MIT-MC
5903 BACKUP; is for backup copies of things on .; and occasionally other things.
5904 Why can't .; itself be used for this? For the couple of true backup @ files,
5905 which have the same names as files on .; , e.g. CRASH; would work fine.
5908 It should be preserved, and it does get updated occasionally.
5909 The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe
5910 almost everything there is garbage. If BACKUP; were trully for backup
5911 then leaving non-working stuff on that directory as is now the case
5912 may be hazardous for MC's health if ever invoked.
5914 I believe that it has proven itself useful on ML at least.
5915 I see no recent proof of this for MC:BACKUP; .
5917 Date: 13 October 1983 17:44 EDT
5918 From: Glenn S. Burke <GSB @ MIT-MC>
5919 Subject: MC directory slot
5921 cc: BUG-ITS @ MIT-MC
5923 BACKUP; is for backup copies of things on .; and occasionally other things.
5924 It should be preserved, and it does get updated occasionally. I believe
5925 that it has proven itself useful on ML at least.
5927 Date: 13 October 1983 16:35 EDT
5928 From: Jeffrey P. Golden <JPG @ MIT-MC>
5929 Subject: MC directory slot
5930 To: BUG-ITS @ MIT-MC
5932 Are all of you familiar with the MC:BACKUP; directory? I wonder how useful
5933 that directory is, or has its function been largely usurped by MC:.; et al?
5935 Date: 13 October 1983 03:57 EDT
5936 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5937 To: BUG-ITS @ MIT-MC
5939 I made the MLDEV/MLSLV use HOSTS3, and also fixed a minor bug
5940 where MLDEV was comparing 36 bit network numbers as CAIN A,NW%ARP.
5941 I bother mentioning the bug fix, because it seems to be everyone's
5942 favorite sleepytime bug for ITS network hacking.
5945 Date: 12 October 1983 20:29 EDT
5946 From: Ken Harrenstien <KLH @ MIT-MC>
5947 Subject: [ron: ML Routing]
5948 To: MARTY%MIT-OZ @ MIT-ML
5949 cc: BUG-ITS @ MIT-MC
5951 I doubt there is a real problem. ML was probably down at the
5952 time he tried, or the MILNET split cnfused things, or Ron was
5953 confused. MC and ML have the same "routing" code.
5955 Date: 12 Oct 1983 15:23 EDT (Wed)
5956 Message-ID: <[MIT-OZ].MARTY.12-Oct-83 15:23:24>
5957 From: Martin David Connor <MARTY%MIT-OZ@MIT-ML.ARPA>
5958 To: Bug-ITS@MIT-MC.ARPA
5959 Subject: [ron: ML Routing]
5962 Does anyone understand why this is happening
5964 Date: Wednesday, 12 October 1983 14:58-EDT
5965 From: Ron Natalie <ron at brl-vgr>
5969 I can talk to MIT-MC from our local nets but not MIT-ML.
5971 The nets in question are:
5975 they should be routed to your MILNET/ARPANET gateway.
5979 Date: 12 October 1983 01:48 EDT
5980 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5981 Subject: normal host tables!
5982 To: BUG-ITS @ MIT-MC
5983 cc: INFO-HOSTS @ MIT-MC
5985 I snarfed the latest host table from the NIC, and
5986 installed it on ITS.
5988 Date: 12 October 1983 01:37 EDT
5989 From: Christopher C. Stacy <CSTACY @ MIT-MC>
5990 Subject: new host table
5991 To: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC
5992 cc: GSB @ MIT-MC, TK @ MIT-MC, ELLEN @ MIT-MC, DCLARK @ MIT-MC,
5993 JIS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC
5996 The latest NIC:<NETINFO>SPLIT-HOSTS.TXT file, dated 11 October 83, has
5997 MIT-MC back on the ARPAnet ("HOST : 10.3.0.44 : MIT-MC,MC :").
5998 I think this means things have finally been set aright.
6001 Date: 8 October 1983 05:28 EDT
6002 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6003 Subject: source write lock removed
6004 To: BUG-ITS @ MIT-MC
6008 Date: 7 October 1983 20:34 EDT
6009 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6010 To: BUG-ITS @ MIT-MC
6013 I JFCLd out the only-ARPANET patch I made a little while ago
6014 in the running system on MC. For one thing, no hosts know
6015 we are here on the ARPAnet, so we arent likely to get much
6016 unwanted traffic except from TAC users.
6018 Date: 7 October 1983 19:05 EDT
6019 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6020 To: BUG-ITS @ MIT-MC
6023 At this moment, MC has the split host table which has itself on
6024 net 10. I just typed in a patch to make it refuse to connect
6025 to/from nets other than the ARPANET, though, to prevent lots
6026 of MILNET packets from being generated by unauthorized users.
6027 This isn't optimal; I'll frob it some more later tonite.
6029 Date: Friday, 7 October 1983, 05:43-EDT
6030 From: Christopher C. Stacy <CStacy at MIT-MC>
6032 To: BUG-ITS at MIT-MC, BUG-INQUIR at MIT-MC
6033 Cc: GSB at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC
6036 I changed over all the INQUIR groups tonite, and installed new INQUIR
6037 and LSRPRT versions. I put up a messsage urging people to check to
6038 make sure their entry looks right. I used an editied version of
6039 ELLEN;PLASMA to find the PFC people, who have a new special group.
6041 I tried to make it preserve directory assignments, but it may have
6042 slightly confused people who are in the USERSi dirs on ML, since I
6043 forgot to make then specify the machine. I don't expect this to be a
6044 problem in most cases though.
6048 Date: 6 Oct 1983 08:13 EDT (Thu)
6049 Message-ID: <[MIT-OZ].IAN. 6-Oct-83 08:13:06>
6050 From: Ian Macky <Ian@MIT-OZ>
6054 [PHOTO: Recording initiated Thu 6-Oct-83 8:11AM]
6056 TOPS-20 Command Processor 5(742)-2
6059 [SRI-NIC via MIT-MC]
6061 [SRI-NIC via MIT-ML]
6062 ? Internal error - DEVICE NOT ASSIGNABLE TO THIS PROCESSOR
6067 [PHOTO: Recording terminated Thu 6-Oct-83 8:12AM]
6069 Date: Thursday, 6 October 1983, 02:54-EDT
6070 From: Christopher C. Stacy <CStacy at MIT-MC>
6071 Subject: inconsistant sources available
6075 ITS is being hacked. If you arent KLH or myself, don't bother trying
6076 to assemble and run it.
6079 Date: 5 October 1983 02:24 EDT
6080 From: Christopher C. Stacy <CSTACY @ MIT-ML>
6081 To: BUG-ITS @ MIT-ML
6084 ML has a version of ITS which does routing to the MILNET.
6085 The HOSTS3 bin file there is speciall hacked up.
6086 People should not install ITS host tables until further notice.
6088 MC is off the Internet, since it is connected to MILNET
6089 and it cannot deal with this. (I consulted KLH about one
6090 of us fixing this, so that MC could be on the MILNET, but
6091 he agrees it is too much dangerous trouble for what should
6092 be a very temporary situation.)
6094 MC and ML can talk to each other over the Chaosnet, of course.
6096 Date: 4 October 1983 23:50 EDT
6097 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6098 To: BUG-ITS @ MIT-MC
6102 ML needs a new special host table, and a new ITS version.
6103 I'll take care of this tomorrow.
6105 Date: 4 October 1983 05:40 EDT
6106 From: Pandora B. Berman <CENT @ MIT-ML>
6107 Subject: Batch processing
6109 cc: MAGIC-DRAGON-KEEPER @ MIT-ML, ALAN @ MIT-MC, BUG-ITS @ MIT-MC,
6110 MAGIC-DRAGON-KEEPER @ MIT-MC
6112 Date: 4 Oct 1983 02:32 EDT (Tue)
6113 From: Ian Macky <Ian@MIT-OZ>
6114 To: Alan Bawden <ALAN@MIT-MC>
6115 Cc: BUG-ITS@MIT-MC, MAGIC-DRAGON-KEEPER@MIT-MC, Magic-Dragon-Keeper@MIT-ML
6116 Subject: Batch processing
6117 In-reply-to: Msg of 4 Oct 1983 02:22-EDT from Alan Bawden <ALAN at MIT-MC>
6118 In case noone noticed, OZ has been sending Happy Birthday messages
6121 oh, we noticed (could hardly miss doing so). but that's only for OZ
6122 users. there are other people in the world..
6124 Date: 4 Oct 1983 02:32 EDT (Tue)
6125 Message-ID: <[MIT-OZ].IAN. 4-Oct-83 02:32:38>
6126 From: Ian Macky <Ian@MIT-OZ>
6127 To: Alan Bawden <ALAN@MIT-MC>
6128 Cc: BUG-ITS@MIT-MC, MAGIC-DRAGON-KEEPER@MIT-MC, Magic-Dragon-Keeper@MIT-ML
6129 Subject: Batch processing
6130 In-reply-to: Msg of 4 Oct 1983 02:22-EDT from Alan Bawden <ALAN at MIT-MC>
6132 In case noone noticed, OZ has been sending Happy Birthday messages
6135 Date: 4 October 1983 02:22 EDT
6136 From: Alan Bawden <ALAN @ MIT-MC>
6137 Subject: Batch processing
6138 To: BUG-ITS @ MIT-MC, MAGIC-DRAGON-KEEPER @ MIT-MC,
6139 Magic-Dragon-Keeper @ MIT-ML
6141 In the latest version of Puff the Magic Dragon (installed on MC, not ML
6142 yet) I have generalized the feature where once an hour Puff would look for
6143 the files DRAGON;HOURLY RAYGUN and HOURLY TMPKIL and load and run them.
6144 Puff now will load ANY file on DRAGON; whose first file name is HOURLY and
6145 try to load it into a job and run it. While I was at it I made it check
6146 for files named DAILY, MNTHLY and YEARLY as well. (They are run at the end
6147 of the day, month and year, when Puff is cleaning his own house.)
6149 I nominate CStacy to write DRAGON;DAILY BTHDAY to replace poor DM's
6150 cheerful birthday greetings.
6152 There seems to have been some misimpression that Puff was ALREADY doing
6155 Date: 3 October 1983 08:10 EDT
6156 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6157 To: BUG-ITS @ MIT-MC
6160 What finaly wound up sending out happy birthday announcements on ITS?
6162 Date: 1 October 1983 22:07 EDT
6163 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6164 To: BUG-ITS @ MIT-MC
6166 Latest ITS (installed on MC) has the MILNET gateway in it
6167 so that forwarding will happen after the split. I will
6168 install this on ML later tonite or tomorrow.
6170 Date: 30 September 1983 22:57 EDT
6171 From: Keith F. Lynch <KFL @ MIT-MC>
6172 To: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
6175 9 users, fair share = 109% ?
6178 CENT@MIT-ML 09/27/83 01:10:11 Re: dm
6179 To: (BUG ITS) at MIT-ML
6180 i removed *DM from the ML system msg lists. someone had already done
6183 Date: 26 September 1983 21:33 EDT
6184 From: George J. Carrette <GJC @ MIT-MC>
6185 To: BUG-ITS @ MIT-MC
6187 SRI-IU must have a bad address or something in the version of the host
6190 Date: 25 September 1983 01:02 EDT
6191 From: Glenn S. Burke <GSB @ MIT-MC>
6193 cc: BUG-ITS @ MIT-MC
6195 Date: 23 September 1983 02:27 EDT
6196 From: Ken Harrenstien <KLH @ MIT-MC>
6197 Sender: KLH1 @ MIT-MC
6199 Patched MC (running sys & disk) at TCLK30+10/ CAILE D,556.
6200 Fix made in source but not assembled. ML not patched but eventually
6203 Patched in the binary and the running system (it's been up 10 days!)
6205 Date: 24 September 1983 22:13 EDT
6206 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6207 To: BUG-ITS @ MIT-MC
6209 I merged DM:SYSENG; onto the MC SYSENx dirs.
6211 Date: Saturday, 24 September 1983, 17:19-EDT
6212 From: Christopher C. Stacy <CStacy at MIT-MC>
6214 To: BUG-INQUIR at MIT-MC, BUG-ITS at MIT-MC
6216 I diked DM out of INQUIR.
6218 Date: 23 September 1983 06:00 EDT
6219 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6220 Subject: ITS software on DM
6221 To: BUG-ITS @ MIT-MC
6222 cc: BUG-RANDOM-PROGRAM @ MIT-MC, TAA @ MIT-DMS, PDL @ MIT-DMS,
6223 SWG @ MIT-DMS, Moon @ SCRC-TENEX
6226 I have snarfed the interesting things in DM:SYSENG; to a place on MC,
6227 and will be making sure we have everything from that directory. Are
6228 there any other interesting programs or systems (MIDAS or otherwise)
6229 we really should have on MC hiding out there? I bet there are, but
6233 Date: 23 September 1983 02:27 EDT
6234 From: Ken Harrenstien <KLH @ MIT-MC>
6235 Sender: KLH1 @ MIT-MC
6236 To: BUG-ITS @ MIT-MC
6238 Patched MC (running sys & disk) at TCLK30+10/ CAILE D,556.
6239 Fix made in source but not assembled. ML not patched but eventually
6242 Date: 16 September 1983 00:53 EDT
6243 From: Joseph A. Kay <JAK @ MIT-MC>
6244 To: BUG-ITS @ MIT-MC
6246 At 00:10:25 ,16-sept-83, the LA-36 typed out 20 times:
6247 ( at MC):"LOGIN 542A02 0 HST205 " followed by the times (1 second apart).
6248 there was one intervening line from chaos, in their midst, after which
6249 some lines had 542A11 instead of 542A02.
6250 The same thing happened again 1 minute later with ~50 lines in a row,mostly
6251 "LOGIN 542A11 0 HST205" with times in two consecutive sequences (a 9 second
6252 gap between the sequences,1-second or less inside them). Occasionally
6254 At 00:35,there were 10 lines with times in 13-second span, saying:
6255 "LOGIN 030A16 0 HST017"...
6257 --this may point out a problem, possibly elsewhere; or may help diagnose
6258 a future difficulty. I am not sure of its significance, but I hope it can
6261 Date: Monday, September 12, 1983 5:40AM-EDT
6262 From: Christopher Stacy <CSTACY@MIT-OZ>
6263 Subject: TOPS-20 usage of "TCP" protocol
6265 CC: BUG-ITS at MIT-MC
6267 Programs which gateway through the TCP byte-stream gateways (ie., the
6268 "ARPA" CHAOSnet protocol, currently served only by ITS hosts on both
6269 nets), they should tell what sort of gatewaying is going on.
6271 Users cannot tell how they are getting from point A to point B - all
6272 they see is a virtual network where everything is magically connected
6273 by various secret means. If they were told what means was being
6274 employed to connect them with remote hosts on other networks, they
6275 would stand a chance of figuring out what was losing when the
6276 "gateway" did not work.
6278 BTW, probably the CHAOSNET "TCP" protocol user to get a byte stream
6279 should be made an available (optionally included, requires CHAOS
6280 support routines) call in the NETWRK packages (on all systems). It
6281 could take remote host address and port, and an AOBJN-style pointer to
6282 a table of gateway server addresses. When the DEC interface for IP
6283 comes out, and NETWRK will need rewriting anyway, would be a good time
6288 Date: 10 September 1983 06:35 EDT
6289 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6290 To: BUG-ITS @ MIT-MC
6292 ITS had the date wrong for a few minutes today while it was being
6293 debuggged, so a few files might have the wrong day (not too far
6294 off) on them. (Since only one or two people were on during
6295 this time, it should not be a real problem..this message is just FYI.)
6297 Date: Friday, 9 September 1983, 15:43-EDT
6298 From: Christopher C. Stacy <CStacy at MIT-MC>
6303 In Release 4.4, site configuration 62, on Lisp Machine Apiary-6:
6305 >>Error: File system bug on host MIT-MC:
6308 For MC: AR2: CSTACY; .FILE. (DIR)
6309 While in the function (DEFUN-METHOD FS:FILE-PROCESS-ASYNC-MARK)
\18 (DEFUN-METHOD FS:FILE-NEXT-READ-PKT)
\18 (METHOD FS:FILE-INPUT-STREAM-MIXIN GET-NEXT-INPUT-PKT)
6311 (DEFUN-METHOD FS:FILE-PROCESS-ASYNC-MARK): (P.C. = 20)
6312 Arg 0 (SELF): #<FILE-INPUT-CHARACTER-STREAM "MC: AR2: CSTACY; .FILE. (DIR)" 5535744>
6313 Arg 1 (SELF-MAPPING-TABLE): #<Map to flavor FS:FILE-DATA-STREAM-MIXIN -- 6. IV's, 0. FL's 60527270>
6314 Arg 2 (PKT): #<CHAOS Packet 53067315>
6315 Local 3 (STRING): "I1696 ERROR BUG R CHANNEL NOT OPEN
6321 ZWEI:VIEW-WINDOW-DISPLAY: (P.C. = 44)
6322 Arg 0 (ZWEI-WINDOW): #<WINDOW 53501015>
6323 Arg 1 (STREAM): #<FILE-INPUT-CHARACTER-STREAM "MC: AR2: CSTACY; .FILE. (DIR)" 5535744>
6326 Date: 9 September 1983 15:14 EDT
6327 From: Kent M. Pitman <KMP @ MIT-MC>
6328 To: BUG-MINITS @ MIT-MC, BUG-ITS @ MIT-MC
6330 Echo response time to ddt and mail and such is very slow
6331 on ITS today. It was like this sometime very recently, too.
6332 I'm coming in from HUB8A. Anyone got any ideas what might
6333 be so draggy? I get multi-second delays doing simple
6334 input and the fair share is 44%.
6336 Date: 15 Aug 1983 00:43 EDT (Mon)
6337 Message-ID: <[MIT-OZ].GUMBY.15-Aug-83 00:43:28>
6338 From: David Vinayak Wallace <GUMBY@MIT-OZ>
6341 Subject: monmode bug(?)
6342 In-reply-to: Msg of 13 Aug 1983 23:02-EDT from SHAWN at MIT-ML
6344 Date: Saturday, 13 August 1983 23:02-EDT
6345 From: SHAWN at MIT-ML
6347 Is the fact that when you have 'prmmch' set, (printing machine name),
6348 and are in monmode, (for example 'ML: '), and you type "clear", when
6349 it goes to the top of your screen, it only prints the ':' not the 'ML:'.
6350 Is this a bug??? (If not, is there any reason for it other then that's
6351 how someone liked it?), Thanks.
6354 You'll notice that ^L will never reprint the prompt. It will echo
6355 whatever pending typing exists (in this case a ":"). This has nothing
6356 to do with either :MONMOD or PRMMCH.
6358 Date: 14 August 1983 18:06 EDT
6359 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6360 Subject: new ITS version, install at leisure.
6361 To: BUG-ITS @ MIT-MC
6364 ITS 1351 changes .SHUTDN to not allow shutdowns further away than 30 days,
6365 and fixes some SYSJOB code which would have broken under certain assembly
6366 conditionals. I'll install it around eventually; nothing very interesting in here.
6368 (The .SHUTDN restriction is due to delta-t being computed wrong for the DEDBLK
6369 clock queue list entry; this would crash the system.)
6372 GSB@MIT-ML 08/13/83 23:30:28 Re: c100 inschar lossage
6373 To: (BUG ITS) at MIT-ML
6374 Multiple insert-characters never ever ever succeed in outputting the
6375 null in the sequence which is what turns off insert-character mode,
6376 on anything but the first. This is what i presume is an insert-char
6377 operation with an argument, which comes in over a supdup.
6379 I have seen this lossage locally in what i presume are only single
6380 insert-character operations, but it cannot be reliably reproduced then.
6381 However multiple insert-char sequence coming from (say) emacs on OZ
6382 reliably produce the null for the first and none of the others.
6385 SHAWN@MIT-ML 08/13/83 23:02:36 Re: monmode bug(?)
6386 To: (BUG its) at MIT-MC
6388 Is the fact that when you have 'prmmch' set, (printing machine name),
6389 and are in monmode, (for example 'ML: '), and you type "clear", when
6390 it goes to the top of your screen, it only prints the ':' not the 'ML:'.
6391 Is this a bug??? (If not, is there any reason for it other then that's
6392 how someone liked it?), Thanks.
6398 Date: 11 August 1983 23:49 EDT
6399 From: V. Ellen Golden <ELLEN @ MIT-MC>
6400 Subject: console decwriter keyboard stops working
6401 To: Moon @ SCRC-TENEX
6402 cc: CSTACY @ MIT-MC, ELLEN @ MIT-MC, BUG-ITS @ MIT-MC
6404 DEC appears to have fixed this problem (??!!!) when they PM'd
6405 the machine, which was down due to precisely this situation when
6406 they arrived... so I guess it is working.....
6408 Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Thu 11-Aug-83 17:55:06-EDT
6409 Date: Thursday, 11 August 1983, 17:48-EDT
6410 From: David A. Moon <Moon@SCRC-TENEX>
6411 Subject: console decwriter keyboard stops working
6412 To: Christopher C. Stacy <CSTACY@MIT-MC>
6413 Cc: ELLEN@MIT-MC, BUG-ITS@MIT-MC
6414 In-reply-to: The message of 6 Aug 83 10:38-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
6416 Date: 6 August 1983 10:38 EDT
6417 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6418 Please get someone to look at MC's console typewriter.
6419 It frequently gets into this mode where the keyboard
6420 does not work at all, and nothing can be typed.
6421 Isn't there some DEC braindamage where this is caused by the cover
6422 not being quite closed all the way, and/or the thing thinking it
6423 is out of paper? Or is that some other model of decwriter?
6425 Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Thu 11-Aug-83 17:51:25-EDT
6426 Date: Thursday, 11 August 1983, 17:45-EDT
6427 From: David A. Moon <Moon@SCRC-TENEX>
6429 To: Christopher C. Stacy <CSTACY@MIT-MC>
6431 In-reply-to: The message of 8 Aug 83 03:31-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
6433 Date: 8 August 1983 03:31 EDT
6434 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6435 I just noticed DM had crashed a while back (with no error
6436 messages or anything, and questionable state in the console).
6437 So I tried to reboot it. DSKDMP says the MFD is clobberred.
6438 There's a copy of the MFD on each drive and sometimes this message
6439 means that the disk controller or channel is broken or the processor
6440 is broken (what it really means is that dskdmp tried to read the mfd
6441 and either got a disk error or some checkword in it didn't have the
6444 Date: 8 August 1983 03:31 EDT
6445 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6447 To: BUG-ITS @ MIT-MC
6449 I just noticed DM had crashed a while back (with no error
6450 messages or anything, and questionable state in the console).
6451 So I tried to reboot it. DSKDMP says the MFD is clobberred.
6452 If there is a 9-track MAGDMP format tape for it, I will try
6453 to fix this, if anyone cares. If it cannot be fixed of
6454 course, someone will have to reload the file system.
6455 Should I look at it?
6457 Date: Sunday, 7 August 1983, 10:17-EDT
6458 From: Christopher C. Stacy <CStacy at MIT-MC>
6459 To: BUG-ITS at MIT-MC
6460 Cc: KMP at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC
6461 In-reply-to: The message of 6 Aug 83 00:23-EDT from Kent M. Pitman <KMP>
6463 In crashed ITS 1348 in CRASH;LUUOEX, on MIT-MC:
6465 The routine which builds Internet datagram headers was smashed
6466 somehow. IPKHDR+3 (64012), normally a MOVEM, is zero (which of
6467 course looks like a UUO).
6469 Also, I am not sure exactly what this implies, but if you look at the
6470 "M" display in PEEK, it complains about not being able to trace some
6471 memory pointers ("Bad mem ptr data for 979 pages!").
6473 Anyone else want to look at this dump further?
6474 If not I'll delete it in a few days.
6476 Date: 6 August 1983 10:38 EDT
6477 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6479 cc: BUG-ITS @ MIT-MC
6481 Please get someone to look at MC's console typewriter.
6482 It frequently gets into this mode where the keyboard
6483 does not work at all, and nothing can be typed.
6484 Being the console tty, this typically goes unnoticed
6485 until the system needs to be reloaded or something, sigh.
6487 Date: 6 August 1983 00:23 EDT
6488 From: Kent M. Pitman <KMP @ MIT-MC>
6489 To: BUG-ITS @ MIT-MC
6490 cc: ELLEN @ MIT-MC, JPG @ MIT-MC
6492 MC crashed with the message:
6493 MUUO in Exec Mode, PC = 304000,,64013
6498 It had been down for an hour and a half, and there were no wizards in sight,
6499 so I dumped it to CRASH;LUUOEX and I reloaded the machine. I made an entry
6500 in the log book to this effect.
6503 Date: 5 August 1983 00:25 EDT
6504 From: Zippy the Pinhead <ZIPPY @ MIT-MC>
6505 To: BUG-ITS @ MIT-MC
6509 From evan Fri Jul 1 23:34:10 1983
6511 Subject: So I had this dream...
6514 The earth was going to be destroyed: there were these aliens
6515 who were going to eradicate all life on earth real soon so they could
6516 use it for themselves. There were two different castes of these aliens:
6517 A variety which resembled Dean Bob Randolph, and type which looked like
6518 Don Saklad. I addition to being about to kill everyone, these aliens had
6519 the additional bad feature of being obnoxious. The Dean Bob aliens were
6520 wandering around telling everyone that it was really best for us to be
6521 extermiated and that, in time, we would come to understand that the earth
6522 wasn't right for us. The Saklad aliens were bothering everyone with
6523 stupid questions about how to use the earth and the things on it.
6525 I was rather upset by the impending demise of EVERYBODY, but I
6526 discovered that we had been visited year earlier by friendly aliens, who
6527 had left us with a planetary defense system which would protect us from
6528 the nasty aliens. Unfortunately, these aliens had been here several
6529 years ago, and they had wired the defense system into the guts of the
6530 AI-10! In order to activate the defense system, you had to boot AI and
6531 log in as RMS, then type ":defend".
6533 The rest of the dream consisted of wandering around Tech Square
6534 trying to get someone to give me a Lisp-Machine memory card so that I
6535 could save all life on earth. No one would give me one. They all had
6536 important things to do with them. So I went from office to office trying
6537 to convince someone to help, and every time I rode the elevator, I was
6538 accosted by a Saklad alien asking some question like: "What is this
6539 water stuff and what do we do with it? Is it documented?"
6541 Then the phone rang and I woke up. Thank Heaven...
6547 Date: 5 August 1983 00:20 EDT
6548 From: Herb Lin <LIN @ MIT-MC>
6551 cc: BUG-ITS @ MIT-MC
6552 In-reply-to: Msg of 4 Aug 1983 23:42-EDT from Christopher C. Stacy <CStacy>
6556 Date: Thursday, 4 August 1983, 23:42-EDT
6557 From: Christopher C. Stacy <CStacy at MIT-MC>
6559 To: Herb Lin <LIN at MIT-MC>
6560 Cc: BUG-ITS at MIT-MC
6561 In-reply-to: The message of 4 Aug 83 23:05-EDT from Herb Lin <LIN at MIT-MC>
6563 You can read tapes between AI,ML, and MC. (DM has nine-track drives.)
6564 Just use LOAD command of DUMP as usual. I hear that due to drive
6565 alignment, the most successful place to read AI tapes is on ML.
6567 Also, there is a command in DUMP to read the backup directories from
6568 AI if they are re-loaded to disk someplace.
6570 Date: 4 August 1983 23:05 EDT
6571 From: Herb Lin <LIN @ MIT-MC>
6573 To: BUG-ITS @ MIT-MC
6575 this is addressed to system wizards - does anyone know if tapes written on
6576 the old AI machine can be read onto MC? If so, how can I do it...
6580 Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 31-Jul-83 20:52:18-EDT
6581 Date: Sunday, 31 July 1983, 20:50-EDT
6582 From: David A. Moon <Moon@SCRC-TENEX>
6584 To: Christopher C. Stacy <CSTACY@MIT-MC>
6585 Cc: TAFT@MIT-MC, ELLEN@MIT-MC, BUG-ITS@MIT-MC
6586 In-reply-to: The message of 30 Jul 83 19:36-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
6588 Somewhere on those scribbled-all-over pieces of paper attached
6589 to the machine it says how to get some information when it seems
6590 to be hung. There's a KLDCP command with some name I don't
6591 remember ("ALL" maybe) that prints a bunch of stuff, and a command
6592 file (J KLHUNG I think) that prints about three pages of stuff.
6593 Most of the three pages is useless, but buried in there are the
6594 micro and macro PCs and various error status bits. Somewhere unless
6595 some idiot has thrown it away there is a notebook containing the
6596 KLDCP commands, including how to get the current interrupt level
6597 and other things like that that are in the lights on KAs. I have
6598 no idea any more what the names of the commands were. Presumably
6599 all the information it is possible to get is in the KLHUNG output
6602 There should be a microcode listing on-line in the UCODE directory
6603 in which you can look up micro PCs. They appear embedded in some
6604 syntax in the left margin, maybe "U nnnnn," or something like that.
6606 Microcode hung really means that some timeout inside of KLDCP went
6607 off, I believe, and doesn't really directly imply anything about
6608 the microcode. I think I have seen this caused by main memory
6609 parity errors sometimes.
6611 "ITS IS DOWN" means that a keep-alive counter incremented by the
6612 60-cycle clock interrupt handler is not being incremented, at least as
6613 far as the pdp11 you are typing to (whichever of the two it is) thinks.
6614 ITS could be halted, looping at interrupt level, not taking interrupts
6615 because the interrupt hardware, I/O bus, or clock is broken, not
6616 running because the processor is broken, or working but not talking to
6617 the pdp11 because the interface is broken.
6619 The page-fault-in-system obviously should be investigated to see whether
6620 there was a reference to a wrong address, or a page fault on a good
6621 address, or code was clobbered, or the machine wasn't executing instructions
6622 correctly, or whatever. This one could easily be a software bug, so
6625 Someone should delete the useless crash dump Taft made after a J NTSDDT.
6627 Date: 30 July 1983 19:36 EDT
6628 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6630 To: Moon @ SCRC-TENEX
6631 cc: TAFT @ MIT-MC, ELLEN @ MIT-MC, BUG-ITS @ MIT-MC
6632 In-reply-to: Msg of 07/30/83 16:24:06 from TAFT
6637 I know you are real busy over there, but if you get a second could you
6638 please shed any light you have on this? It's pretty much beyond me.
6641 Date: 07/30/83 16:24:06
6647 MC crashed twice this afternoon. The first time was with a
6648 microcode hung, but the second time the lights were just dead and
6649 there was no message whatsoever on the console.
6651 I tried to take a dump of this, but I am not sure that I got it
6652 right. I hit BREAK on the console, did a "J NTSDDT" and then did:
6654 It seems to have tried writing out a dump, but perhaps this was
6655 the wrong way to get into DDT ? (It appeared to load a new one ?)
6656 Anyway I left the dump in CRASH;NO MSG, maybe someone wants to
6657 look at it. Otherwise it should be deleted.
6660 The command "DDT" will get you into the current DDT. J NTSDDT runs a
6661 command file which resets some things and loads up a fresh DDT. I
6662 don't remember if it clobbers the KL10 state, but I think it does.
6664 Something is very wrong with MC. It has the following three problems,
6665 sometimes several times a day:
6668 Maybe this is not new, maybe it is a known expected ITS bug???
6669 Is that why it has never been looked into?
6671 o Machine appears halted, typing on hardware ttys gets ITS IS DOWN,
6672 no messages on console.
6673 I guess this acts this way because the machine has either gone into a
6674 super tight loop (on the order of JRST .), or the microcode is off
6675 in never-never land and some instruction never returns. Maybe one
6676 thing to do is StoP the machine and look at the PC - I didn't yet.
6677 If the machine were really halted, I think the console-11 would say so.
6678 The IO-11 times out doing some protocol to ITS instead, and
6681 o ITS crashes with PAGE FAULT IN SYSTEM at the exact same address.
6685 Date: 28 July 1983 04:33 EDT
6686 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6687 Subject: CFTPing from ITS
6689 cc: BUG-ITS @ MIT-MC, BUG-FILE @ MIT-OZ, kmp @ MIT-OZ
6690 In-reply-to: Msg of Jul 28 1983 3:19AM-EDT from Martin David Connor <MARTY at MIT-OZ>
6692 Date: Thursday, July 28, 1983 3:19AM-EDT
6693 From: Martin David Connor <MARTY at MIT-OZ>
6694 To: bug-its, bug-file at MIT-OZ
6695 Re: CFTPing from ITS
6696 I now find that supplying a non-existent username to LOGIN
6697 when CFTPing to MC or ML now hangs indefinitely.
6698 I discovered this when running a batch job that CFTPs and
6700 This used to work. Was there a change to the file server on MC?
6704 In FILE 520, ITS 1438, on MIT-MC:
6706 KMP and I saw this too, but thought we might be imagining something.
6707 Someone had broken FILE after version 518 by forgetting that on ITS,
6708 ASCII byte pointers must be explicit (440700) and cannot be set up
6709 with HRROI. It was MPVing because of this in COMST0 when called from
6710 the stuff around GETNAM. Fixed in the source and installed on the ITS
6713 Date: Thursday, July 28, 1983 3:19AM-EDT
6714 From: Martin David Connor <MARTY@MIT-OZ>
6715 Subject: CFTPing from ITS
6716 To: bug-its at MIT-MC, bug-file at MIT-OZ
6719 I now find that supplying a non-existent username to LOGIN
6720 when CFTPing to MC or ML now hangs indefinitely.
6721 I discovered this when running a batch job that CFTPs and
6724 This used to work. Was there a change to the file server on MC?
6727 Date: 12 July 1983 01:32 EDT
6728 From: Ed Schwalenberg <ED @ MIT-MC>
6729 To: BUG-ARCDEV @ MIT-MC, BUG-ITS @ MIT-MC
6732 BIL's first problem comes from the archive device handler running out
6733 of room to fit the archive (archives can only hold about 170. blocks of stuff.)
6734 The archive device should report DEVICE FULL rather than seeming to win and
6735 producing 0-length files. Secondly, file creation dates are randomly munged,
6736 off by an hour or so. Thirdly, as we all know, the archive device needs to be
6737 done right for a change.
6739 Date: 12 July 1983 00:20 EDT
6740 From: William G. Dubuque <WGD @ MIT-MC>
6741 Sender: BIL @ MIT-MC
6742 To: BUG-ITS @ MIT-MC
6744 :MOVE <file>,AR0:RAT; produces a file of length 0 on AR0. Unfortunately
6745 i got screwed and moved a few unbackedup files there before noticing this.
6746 If you list the archive you will notice a few 0 length files there where
6747 this happened. All other files were :MOVEd there previously without such
6748 lossage. Is there a new DDT or ARCDEV or somesuch at the heart of this?
6749 Is there any way of getting around this (I want to preserve the creation
6750 date so :COPY wont do)?
6752 Date: 3 Jul 1983 21:32 EDT (Sun)
6753 From: Ian Macky <Ian@MIT-OZ>
6754 To: Alan Bawden <ALAN@MIT-MC>
6755 Cc: BUG-ARGUS@MIT-MC, BUG-ITS@MIT-MC, CSTACY@MIT-MC
6756 Subject: Artificial Intuition?
6757 In-reply-to: Msg of 3 Jul 1983 15:57-EDT from Alan Bawden <ALAN at MIT-MC>
6760 The source for ARGUS I found on MC was very very old, and is
6761 pretty grim stuff (having been written before I had any idea
6762 what I was doing)... I dunno where a more recent one is; I'll
6765 Date: 3 July 1983 15:57 EDT
6766 From: Alan Bawden <ALAN @ MIT-MC>
6767 Subject: Artificial Intuition?
6769 cc: BUG-ARGUS @ MIT-MC, BUG-ITS @ MIT-MC
6770 In-reply-to: Msg of 3 Jul 1983 09:44 EDT from Christopher C. Stacy <CSTACY>
6772 Date: 3 July 1983 09:44 EDT
6773 From: Christopher C. Stacy <CSTACY>
6774 This is CSTACY. I sat down at DEVON's console here just now, where
6775 DEVON had a disowned ARGUS looking for any CSTACY's. I started up an
6776 EMACS to look at something. I am sure you can imagine my surprise
6777 when I saw: [Here is CSTACY].
6779 Startled, I ^Zd out of the EMACS I took my hands off the keyboard.
6780 Ever dutiful, ARGUS barked: [There goes CSTACY].
6781 I suppose this bug has something to do with my having typed CSTACY$^S
6782 before running the EMACS. If it does not, congratulations!
6784 'Tain't a bug in my opinion.
6786 Had always presumed that ARGUS did this by looking at all the XUNAME's in
6787 the system, but looking at the source it looks like it just reads TTY
\ 6.
6790 Date: 3 July 1983 09:44 EDT
6791 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6792 Sender: DEVON @ MIT-MC
6793 Subject: Artificial Intuition?
6794 To: BUG-ARGUS @ MIT-MC
6795 cc: BUG-ITS @ MIT-MC
6798 This is CSTACY. I sat down at DEVON's console here just now, where
6799 DEVON had a disowned ARGUS looking for any CSTACY's. I started up an
6800 EMACS to look at something. I am sure you can imagine my surprise
6801 when I saw: [Here is CSTACY].
6803 Startled, I ^Zd out of the EMACS I took my hands off the keyboard.
6804 Ever dutiful, ARGUS barked: [There goes CSTACY].
6805 I suppose this bug has something to do with my having typed CSTACY$^S
6806 before running the EMACS. If it does not, congratulations!
6809 SHAWN@MIT-ML 06/29/83 21:42:38 Re: wish list
6810 To: (BUG ITS) at MIT-ML
6812 I *WISH* ITS had a UNIX(tm) type GREP command.
6816 Date: 29 June 1983 17:19 EDT
6817 From: Alan Bawden <ALAN @ MIT-MC>
6818 Subject: CORBLK and .ACCESS interaction.
6819 To: BUG-ITS @ MIT-MC
6821 Here is a minimal case of some lossy interaction between CORBLKing and
6822 .ACCESSing the same file:
6824 .call [setz ? sixbit /open/ ? [.uii,,dsk] ? [sixbit /dsk/]
6825 [sixbit /names/] ? [sixbit />/] ? setz [sixbit /.mail./]]
6827 ;;These next two are not necessary for the misbehavior, but help to
6828 ;;make it more obvious later:
6834 .call [setz ? sixbit /corblk/ ? movei %cbndr ? movei %jself
6835 movei 7 ? setzi dsk]
6840 At the end of this sequence, A and B should obviously contain the same
6841 thing, but they don't. Typically B will get the contents of location 2100,
6842 rather than 100. It is not important what file you use, I just chose
6843 .MAIL.;NAMES > out of randomness.
6845 Date: 21 June 1983 09:01 EDT
6846 From: David C. Plummer <DCP @ MIT-MC>
6847 Subject: cli interrupts and emacs
6849 cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC
6851 Date: Tuesday, 21 June 1983, 04:23-EDT
6852 From: Patrick Sobalvarro <PGS@MIT-OZ>
6854 I guess I'm a loser. I do use MODLIN.
6855 So am I, and so do I. I'd like to be a winner who uses MODLIN, though.
6857 Date: Tuesday, 21 June 1983, 04:30-EDT
6858 From: Patrick Sobalvarro <PGS@MIT-OZ>
6859 To: HAA@MIT-MC, BUG-ITS@MIT-MC
6860 In-reply-to: The message of 2 Jun 83 21:27-EDT from Herschell A. Andrews <HAA>
6862 Date: 2 June 1983 21:27 EDT
6863 From: Herschell A. Andrews <HAA>
6866 Does anyone know why my vt52 emuator suddenly started losing? It works
6867 fine on cmuc but loses bad on ITS. My software tty doesn't work either.
6868 Has something changed?
6870 I tried running a vt52 connected directly to MC and had no trouble; I'd say the
6871 trouble is probably in your emulator. Or have you figured the problem out
6874 Date: Tuesday, 21 June 1983, 04:23-EDT
6875 From: Patrick Sobalvarro <PGS@MIT-OZ>
6876 Subject: cli interrupts and emacs
6878 CC: BUG-ITS@MIT-MC, BUG-EMACS@MIT-MC
6879 In-reply-to: The message of 21 Jun 83 04:05-EDT from Kent M. Pitman <KMP at MIT-MC>
6881 Date: 21 June 1983 04:05 EDT
6882 From: Kent M. Pitman <KMP @ MIT-MC>
6884 Do you use the MODLIN library? (For reasons I have never traced down, having
6885 this loaded seems to defeat Emacs' ability to recognize the tty having been
6886 potentially munged by superior typeout.) If you don't use the MODLIN library,
6887 perhaps you are a new data point.
6889 I guess I'm a loser (not a new data point, ha ha).
6892 Date: 21 June 1983 04:05 EDT
6893 From: Kent M. Pitman <KMP @ MIT-MC>
6894 Sender: ___004 @ MIT-MC
6895 Subject: cli interrupts and emacs
6897 cc: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC
6899 Do you use the MODLIN library? (For reasons I have never traced down, having
6900 this loaded seems to defeat Emacs' ability to recognize the tty having been
6901 potentially munged by superior typeout.) If you don't use the MODLIN library,
6902 perhaps you are a new data point.
6904 Date: 21 June 1983 03:58 EDT
6905 From: Alan Bawden <ALAN @ MIT-MC>
6906 Subject: cli interrupts and emacs
6908 cc: BUG-EMACS @ MIT-MC, BUG-ITS @ MIT-MC
6909 In-reply-to: Msg of 21 Jun 1983 01:27 EDT from Patrick G. Sobalvarro <PGS>
6911 Date: 21 June 1983 01:27 EDT
6912 From: Patrick G. Sobalvarro <PGS>
6913 Correct me if I'm wrong, but once upon a time I seem to remember having
6914 Emacs uderstand that I'd gotten my screen bashed and redisplay it after a
6915 CLI interrupt as soon as I typed a character. This was a nice feature,
6916 something Twenex emacs couldn't do because of the way tty messages work
6917 there. Well, it doesn't work anymore. After a CLI interrupt, when I
6918 type characters, my Emacs doesn't redisplay at all. It doesn't do anything
6919 until I type something like ^L, which is an ECHOIN break character. Is
6922 CStacy has complained of something like this in the past. DCP, I believe,
6923 claimed to have seen this too. I have never seen it. Is it reproducable?
6925 (I don't see how ECHOIN can itself be at fault, this works by having Emacs
6926 enable %PIATY interrupts, but perhaps emacs does does something bogus when
6927 it finds that this interrupt occured during an ECHOIN. I am pretty sure I
6928 have tested that case trying to reproduce this lossage, but I have never
6929 seen it fail... I just tried to find the source of TECO, but I couldn't, I
6930 wonder where it is?)
6932 Date: 21 June 1983 01:27 EDT
6933 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
6934 Subject: cli interrupts and emacs
6935 To: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC
6937 Correct me if I'm wrong, but once upon a time I seem to remember having
6938 Emacs uderstand that I'd gotten my screen bashed and redisplay it after a
6939 CLI interrupt as soon as I typed a character. This was a nice feature,
6940 something Twenex emacs couldn't do because of the way tty messages work
6941 there. Well, it doesn't work anymore. After a CLI interrupt, when I
6942 type characters, my Emacs doesn't redisplay at all. It doesn't do anything
6943 until I type something like ^L, which is an ECHOIN break character. Is
6946 Date: 11 June 1983 04:19 EDT
6947 From: Pandora B. Berman <CENT @ MIT-ML>
6950 cc: PGS @ MIT-ML, BUG-ITS @ MIT-MC, Moon @ SCRC-TENEX
6952 i have in hand the relevant tapes from ai's last full dump. i expect to
6953 load the .tape files onto ml one dir at a time and then move them to dm.
6954 then i'll deal with the updates from the various incr. dump tapes after
6955 last august. chris, i will let you know when the dirs from the full
6956 dump are in place; that should be good enough for testing..
6958 Date: 10 June 1983 17:40 EDT
6959 From: Glenn S. Burke <GSB @ MIT-ML>
6961 To: Moon @ SCRC-TENEX
6962 cc: CSTACY @ MIT-MC, PGS @ MIT-MC, CENT @ MIT-MC, BUG-ITS @ MIT-MC
6964 The issue was disk space. I had been aware of the tape drive incompatibility
6965 when i suggested DM. People will just have to run the FIND and do the
6966 loading on different machines.
6969 Date: 10 June 1983 02:59 EDT
6970 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6972 To: Moon @ SCRC-TENEX
6973 cc: PGS @ MIT-MC, CENT @ MIT-MC, BUG-ITS @ MIT-MC
6974 In-reply-to: Msg of 10 Jun 1983 02:26-EDT from David A. Moon <Moon at SCRC-TENEX>
6977 Date: Friday, 10 June 1983, 02:26-EDT
6978 From: David A. Moon <Moon at SCRC-TENEX>
6979 To: Christopher C. Stacy <CSTACY>
6980 cc: PGS, CENT, BUG-ITS
6983 Date: 7 June 1983 14:01 EDT
6984 From: Christopher C. Stacy <CSTACY @ MIT-MC>
6985 I have put a new command into DUMP.
6986 DFIND does a find for a deceased ITS.
6987 If someone reloads the .TAPEn; directories from AI
6988 onto DM, I will test it and you should be in business.
6989 The directories should be named %TAPEn; instead of .TAPEn;.
6991 But AI's tape drive was 7-track and DM's is 9-track. So DM can't read AI's tapes.
6993 Which machine they go on is just a variable in DUMP.
6994 The people who wanted this had picked DM, probably due to the
6995 number of free UFD slots...
6997 Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 10-Jun-83 02:33:36-EDT
6998 Date: Friday, 10 June 1983, 02:26-EDT
6999 From: David A. Moon <Moon@SCRC-TENEX>
7001 To: Christopher C. Stacy <CSTACY@MIT-MC>
7002 Cc: PGS@MIT-MC, CENT@MIT-MC, BUG-ITS@MIT-MC
7003 In-reply-to: The message of 7 Jun 83 14:01-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
7005 Date: 7 June 1983 14:01 EDT
7006 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7007 I have put a new command into DUMP.
7008 DFIND does a find for a deceased ITS.
7009 If someone reloads the .TAPEn; directories from AI
7010 onto DM, I will test it and you should be in business.
7011 The directories should be named %TAPEn; instead of .TAPEn;.
7013 But AI's tape drive was 7-track and DM's is 9-track. So DM can't read AI's tapes.
7015 Date: 9 June 1983 15:57 EDT
7016 From: Kent M. Pitman <KMP @ MIT-MC>
7017 Subject: Bug in ">" handling by Archive Device
7018 To: BUG-ARC @ MIT-MC
7019 cc: BUG-ITS @ MIT-MC
7021 If two files exist on an archive, FOO A and FOO B, then if you open FOO >
7022 for input, you'll get FOO A open, not FOO B.
7024 On DSK, FOO B will be opened.
7027 Date: 7 June 1983 14:01 EDT
7028 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7030 To: PGS @ MIT-MC, CENT @ MIT-MC
7031 cc: BUG-ITS @ MIT-MC
7034 I have put a new command into DUMP.
7035 DFIND does a find for a deceased ITS.
7036 If someone reloads the .TAPEn; directories from AI
7037 onto DM, I will test it and you should be in business.
7038 The directories should be named %TAPEn; instead of .TAPEn;.
7041 Date: 6 Jun 1983 18:32 EDT (Mon)
7042 From: Ian Macky <Ian@MIT-OZ>
7043 To: David C. Plummer <DCP@MIT-MC>
7045 In-reply-to: Msg of 30 May 1983 16:30 EDT from David C. Plummer <DCP at MIT-MC>
7047 Date: 30 May 1983 16:30 EDT
7048 From: David C. Plummer <DCP at MIT-MC>
7049 To: BUG-ITS at MIT-MC
7050 Received: from MIT-MC by MIT-OZ; Mon 30 May 83 16:33:25-EDT
7052 Anybody know where the source for UNTALK is hiding? The creation
7053 date on SYS2;TS UNTALK is October 1977 (before the days when
7054 Midas insterted assembly information). It isn't on MC:SYSEN*;
7056 Ellen knew where it was, so I loaded a copy in my directory for the
7057 time being - it's GREN;UNTALK 87 (and there's UNTALK MAIL, too). It
7058 calls for an .INSRT file of UNCOLA's doing (UNCOLA;.MIDAS >) which was
7059 not on the same full-dump tape, so I dunno where it is.
7061 Date: 6 June 1983 15:18 EDT
7062 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7063 To: BUG-ITS @ MIT-MC
7065 I'll hack up DUMP to look on DM, tonite when I come in.
7066 I cant imagine it taking more than 20 minutes...
7068 Date: 6 June 1983 15:13 EDT
7069 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
7070 Sender: PGS0 @ MIT-MC
7071 To: BUG-ITS @ MIT-MC
7073 I suggest that we install the AI:.TAPEn; directories on some ITS machine as
7074 AITAPn; and hack up a version of DUMP so that it'll be possible to find tapes
7075 when we need them. The problem is that there are no hardcopy dump logs
7076 except for the ones Penny did of the last couple of dumps. The hacking of
7077 DUMP should be trivial if we want to use only the FIND command; it can
7078 probably be done with translations. Glenn says that we can probably squeeze
7079 the directories on DM, and we might as well, because no one else is using the
7082 I nominate Chris to do this. All in favor say aye.
7084 P.S. Ty and I once did an incremental dump of AI to ML thru the MLDEV using
7085 only translations. It took a long time, but, hey, it worked.
7087 Date: 3 June 1983 09:07 EDT
7088 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7090 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC
7091 In-reply-to: Msg of 06/02/83 23:17:22 from GSB at MIT-ML
7094 Date: 06/02/83 23:17:22
7097 Inqupd is writing out its new database to LSR1 >. When it runs out of
7098 disk space, it closes the incompletely written file.
7100 I think I have fixed my brain damage INQUPD.
7101 Now it writes out the provisional version to NLSR1 >, and disk-full
7102 interrupts prevent it from installing it (the interrupt handler had a
7103 bogus instruction in it.) It will still leave the incomplete version
7104 around as NLSR1. Later, I will put something in to get this deleted.
7106 In this case, DDT loses its ass when starting up when not-logged-in.
7107 It bugs out before it gets the system symbol table mapped in,
7108 making debugging incredibly difficult.
7110 Maybe DDT should do all its initialization before logging the user in
7111 (and needing to find his hsname.) I thought it already did this,
7114 When CORBLK is doing block-mode map-from-disk, it apparently just
7115 tics the aobjn pointer away leaving MPV pages after end-of-file;
7116 no indication that you ran off the end.
7120 I made two invalid assumptions when looking at this broken system
7121 this afternoon, which caused me to believe that it was horribly trashed.
7122 (Maybe it is. It crashed randomly twice before, which lent great credence
7123 to its being trashed.) One was that DDT would not fail so grossly with
7124 the inquir database smashed. The other was that corblk would not
7125 intentionally act the way it did.
7127 ML *is* having some kind of trouble - COMSAT is repeat processing
7128 messages from May somehow. I guess the QML is broken somehow?
7129 Was it restored from tape, or is something even worse happenning?
7132 I have renamed INQUPD BIN to INQUPD FUCKED.
7134 I put the current database and program on ML.
7135 Let me know if there are more bugs with it (it ran fine for three
7136 weeks on MC, but of course some of the error code did not get
7139 Date: Thursday, 2 June 1983 15:59-EDT
7140 From: MOON at SCRC-TENEX
7141 To: Patrick Sobalvarro <PGS at MIT-OZ>
7142 Cc: bug-its at MIT-MC, BUG-LISPM at MIT-OZ
7143 In-reply-to: The message of 2 Jun 1983 07:57-EDT from Patrick Sobalvarro <PGS@MIT-OZ>
7145 Date: Thursday, 2 June 1983, 07:57-EDT
7146 From: Patrick Sobalvarro <PGS@MIT-OZ>
7148 If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at
7149 the end. I don't see these in Emacs. If I delete the nulls and write the file
7150 and read it again, they're back. With nulls, the file has 115 characters in
7153 I believe this is a bug in the ARC: device; it stores file lengths in words
7154 rather than in characters. Emacs deletes all sorts of characters at the ends
7155 of files in order to get around bugs like this, but the ITS file server is
7156 not as careful (or not as willing to cover up for the deficiencies of other
7159 Date: Thursday, 2 June 1983, 07:57-EDT
7160 From: Patrick Sobalvarro <PGS@MIT-OZ>
7161 To: BUG-LISPM@MIT-OZ
7164 In MIT-Specific 19.3, System 94.23, ZMail 50.9, microcode 238, ZM GC@0,
7165 on Lisp Machine Thirty-one:
7167 If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at
7168 the end. I don't see these in Emacs. If I delete the nulls and write the file
7169 and read it again, they're back. With nulls, the file has 115 characters in
7172 Date: 1 June 1983 19:53 EDT
7173 From: David C. Plummer <DCP @ MIT-MC>
7175 cc: CSTACY @ MIT-MC, BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC,
7178 Date: 1 June 1983 01:02 EDT
7179 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
7180 In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy <CStacy>
7182 Wrongo, Roscoe. First, since there are never bugs in my code, you should
7183 have known you were wrong. Second, when you connect to MC via a terminal
7184 concentrator, I'll bet you use Supdup, not Telnet. If you use Supdup, then
7185 MC doesn't know you're on an Ann Arbor. In fact, when I use Telnet and do
7186 :tctyp aaa, I don't miss any characters in INQUIR. I provided 5ms of padding
7187 for %tdeof in the AAA code in TS3TTY, and that turns out to be more than
7190 Your response was much better than mine could have been. I was a
7191 little mystified to learn that Stacy didn't know you WROTE the
7194 If it works on the Lisp Machine, then MINITS is probably responsible, because
7195 it provides no padding at all.
7197 That is true. Perhaps if I find some time this summer and get
7198 marginally bored I will correct this situation.
7200 Anyway, the cause of the manifestation (call it a bug if you
7201 wish) is CStacy's overeagerness to keep the screen as blank as
7202 possible. I think what is happening is that more than one %TDCLR
7203 is being sent before the text (if entered with :INQUIR DCP).
7204 This causes any AAA without padding to drop characters.
7206 [Also, the following are defined
7207 .CS=.7TYP 4,[ASCIZ /
\10C/]
7208 .CSL=.7TYPL 4,[ASCIZ /
\10C/]
7209 but are used in only 4 of the 10 places where they could be, the
7211 .7TYP 4,[ASCIZ /
\10C/]
7212 There are many other occurences of
\10C scattered throughout.]
7214 Date: 1 June 1983 02:04 EDT
7215 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7217 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC
7218 In-reply-to: Msg of 1 Jun 1983 01:02 EDT from Patrick G. Sobalvarro <PGS>
7221 Date: 1 June 1983 01:02 EDT
7222 From: Patrick G. Sobalvarro <PGS>
7224 cc: BUG-INQUIR, BUG-ITS, BUG-MINITS
7226 It says "What next? ->", and then when I type a ^L, it
7227 says "Command-->"<cr>.
7229 I just changed these to be a little better.
7231 Wrongo, Roscoe. First, since there are never bugs in my
7232 code, you should have known you were wrong. Second, when you connect
7233 to MC via a terminal concentrator, I'll bet you use Supdup...
7234 If it works on the Lisp Machine, then MINITS is probably
7235 responsible, because it provides no padding at all.
7237 Oh yeah. I guess I forgot to turn my brain on tonite!
7239 Date: 1 June 1983 01:02 EDT
7240 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
7242 cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC
7243 In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy <CStacy>
7245 Date: Wednesday, 1 June 1983, 00:30-EDT
7246 From: Christopher C. Stacy <CStacy>
7247 To: Patrick G. Sobalvarro <PGS>
7248 cc: BUG-ITS, BUG-INQUIR
7250 Date: 31 May 1983 16:21 EDT
7251 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
7252 I enter INQUIR via INQUIR PGS. The automagic listme that happens is
7253 broken; half of the characters in it are dropped. There is also a
7254 CR at the end of the command line that says Command-->
7256 I have had this sometimes happen to me on an AAA, buit it never ever
7257 happens on a Lisp Machine SUPDUP connection. I tried it just now.
7258 Just to make sure we are talking about the same program, the prompt
7259 is actually "What next? ->", right?
7261 It says "What next? ->", and then when I type a ^L, it says "Command-->"<cr>.
7264 (incidentally, a more informative prompt [like, say, INQUIR>] would be
7265 better). This character dropping reminds me of Unix. The random cursor
7266 motion reminds me of another operating system for PDP-10s. I had
7267 entered INQUIR only to change my net address to MC.
7269 This looks to me like it must be an ITS problem, since it only happens
7270 on certain terminal types, and since that part of INQUIR hasn't been
7271 modified. I suspect that there is not enough padding after a clear
7272 screen operation for Ann Arbor terminals. If no TS3TTY/AAA wizard
7273 speaks up within a few days, I will start experimenting with the ITS tty
7274 code to see if that fixes the problem.
7276 Wrongo, Roscoe. First, since there are never bugs in my code, you should
7277 have known you were wrong. Second, when you connect to MC via a terminal
7278 concentrator, I'll bet you use Supdup, not Telnet. If you use Supdup, then
7279 MC doesn't know you're on an Ann Arbor. In fact, when I use Telnet and do
7280 :tctyp aaa, I don't miss any characters in INQUIR. I provided 5ms of padding
7281 for %tdeof in the AAA code in TS3TTY, and that turns out to be more than
7284 If it works on the Lisp Machine, then MINITS is probably responsible, because
7285 it provides no padding at all.
7287 Date: Wednesday, 1 June 1983, 00:30-EDT
7288 From: Christopher C. Stacy <CStacy at MIT-MC>
7289 To: Patrick G. Sobalvarro <PGS at MIT-MC>
7290 Cc: BUG-ITS at MIT-MC, BUG-INQUIR at MIT-MC
7291 In-reply-to: The message of 31 May 83 16:21-EDT from Patrick G. Sobalvarro <PGS at MIT-MC>
7293 Date: 31 May 1983 16:21 EDT
7294 From: Patrick G. Sobalvarro <PGS @ MIT-MC>
7295 I enter INQUIR via INQUIR PGS. The automagic listme that happens is
7296 broken; half of the characters in it are dropped. There is also a
7297 CR at the end of the command line that says Command-->
7299 I have had this sometimes happen to me on an AAA, buit it never ever
7300 happens on a Lisp Machine SUPDUP connection. I tried it just now.
7301 Just to make sure we are talking about the same program, the prompt
7302 is actually "What next? ->", right?
7304 (incidentally, a more informative prompt [like, say, INQUIR>] would be
7305 better). This character dropping reminds me of Unix. The random cursor
7306 motion reminds me of another operating system for PDP-10s. I had
7307 entered INQUIR only to change my net address to MC.
7309 This looks to me like it must be an ITS problem, since it only happens
7310 on certain terminal types, and since that part of INQUIR hasn't been
7311 modified. I suspect that there is not enough padding after a clear
7312 screen operation for Ann Arbor terminals. If no TS3TTY/AAA wizard
7313 speaks up within a few days, I will start experimenting with the ITS tty
7314 code to see if that fixes the problem.
7317 Date: 30 May 1983 16:30 EDT
7318 From: David C. Plummer <DCP @ MIT-MC>
7319 To: BUG-ITS @ MIT-MC
7321 Anybody know where the source for UNTALK is hiding? The creation
7322 date on SYS2;TS UNTALK is October 1977 (before the days when
7323 Midas insterted assembly information). It isn't on MC:SYSEN*;
7325 Date: Tuesday, 24 May 1983, 03:33-EDT
7326 From: Christopher C. Stacy <CStacy at MIT-MC>
7327 Subject: date-print on system console
7328 To: Jeffrey P. Golden <JPG at MIT-MC>
7329 Cc: BUG-ITS at MIT-MC
7330 In-reply-to: The message of 23 May 83 17:54-EDT from Jeffrey P. Golden <JPG at MIT-MC>
7332 OK, the SYSJOB will additionally print the date on the console about every 50 lines.
7333 This should get you at least one per page (why not?).
7334 The feature is run when the two minute clock ticks.
7336 Date: 23 May 1983 17:54 EDT
7337 From: Jeffrey P. Golden <JPG @ MIT-MC>
7338 Subject: date-print on system console
7339 To: BUG-ITS @ MIT-MC
7342 KLH@MIT-MC 05/23/83 17:30:31
7344 CC: (BUG ITS) at MIT-MC
7345 JPG@MIT-MC 22 May 1983 13:22 EDT
7346 It would be nice if the system console had the date printed out more
7347 frequently than once every several pages.
7348 The sysjob routines could count the number of LF's and trigger a new
7349 date-print every so many lines (in addition to current time-based
7350 interval). This is what COMSAT does for its stats. Probably once per 3
7352 If I could be assured that I could find the date somewhere in 3 consecutive
7353 pages if I only looked hard enough, that would be great! So I like this.
7355 CSTACY@MIT-MC 05/23/83 01:38:43 Re: IT IS NOW 1:39 ON MONDAY 23 MAY 1983
7357 CC: (BUG ITS) at MIT-MC
7358 I think it prints the date when the very slow clock ticks, about once
7359 every two hours; it also prints it when assorted random things happen.
7360 How often do you want to see it, and what console log events are you
7361 interested in having full timestamps for?
7362 I like what KLH suggests better, but if I can't have that, I suppose
7363 once every half hour would be fine. Since ITS does not have
7364 'auto-hangup' for its dialup lines, every now and then I have to find
7365 out who left a dialup line hung. Then I can give the loser a stern
7366 warning. By OS'ing the line I know the date and time the act was
7367 committed (and perhaps the loser's nickname!), but I need to look at
7368 the system console to get the login name.
7370 Date: 23 May 1983 17:30 EDT
7371 From: Ken Harrenstien <KLH @ MIT-MC>
7373 cc: BUG-ITS @ MIT-MC
7375 Date: 22 May 1983 13:22 EDT
7376 From: Jeffrey P. Golden <JPG @ MIT-MC>
7378 It would be nice if the system console had the date printed out more
7379 frequently then once every several pages.
7381 The sysjob routines could count the number of LF's and trigger a new date-print
7382 every so many lines (in addition to current time-based interval). This
7383 is what COMSAT does for its stats. Probably once per 3 pages is enough?
7385 Date: 23 May 1983 01:38 EDT
7386 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7387 Subject: IT IS NOW 1:39 ON MONDAY 23 MAY 1983
7389 cc: BUG-ITS @ MIT-MC
7390 In-reply-to: Msg of 22 May 1983 13:22 EDT from Jeffrey P. Golden <JPG>
7392 Date: 22 May 1983 13:22 EDT
7393 From: Jeffrey P. Golden <JPG>
7396 It would be nice if the system console had the date printed out more
7397 frequently then once every several pages.
7399 I think it prints the date when the very slow clock ticks, about once
7400 every two hour; it also prints it when assorted random things happen.
7401 How often do you want to see it, and what console log events are you
7402 interested in having full timestamps for?
7404 Date: 22 May 1983 13:22 EDT
7405 From: Jeffrey P. Golden <JPG @ MIT-MC>
7406 To: BUG-ITS @ MIT-MC
7408 It would be nice if the system console had the date printed out more
7409 frequently then once every several pages.
7411 Date: 22 May 1983 06:27 EDT
7412 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7413 To: BUG-ITS @ MIT-MC
7416 When I come in over a TAC, I dont seem to be able to get meta bits
7417 through. Setting +%TPMTA doesn't work (it does on dialups though).
7418 Am I forgetting to do something (like a TAC command) or was I dreaming
7419 when I thought I had used meta keys over TIPs before?
7421 Date: 19 May 1983 23:35 EDT
7422 From: Glenn S. Burke <GSB @ MIT-MC>
7424 To: BUG-ITS @ MIT-MC
7426 :call dirsiz claims the second arg sets quota, the source says (and uses)
7429 Date: 13 May 1983 16:08 EDT
7430 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7431 Subject: one more time...
7432 To: BUG-ITS @ MIT-MC, BUG-INQUIR @ MIT-MC
7433 cc: ELLEN @ MIT-MC, JPG @ MIT-MC, IAN @ MIT-OZ
7436 The new Inquire database is again experimentally installed
7437 on MC only. All bugs found last time appear to have been
7438 fixed. Send me mail if the old one needs to be re-installed
7443 Date: 11 May 1983 11:36 EDT
7444 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7445 To: BUG-ITS @ MIT-MC
7446 cc: BUG-INQUIRE @ MIT-MC, ian @ MIT-OZ
7449 I de-installed the new INQUIRE database and programs, because after
7450 a few real users I found some bugs. Will try again tomorrow.
7453 Date: 11 May 1983 00:07 EDT
7454 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7455 Subject: new Inquire database and stuff is being tested on MC
7456 To: BUG-INQUIRE @ MIT-MC
7457 cc: ALAN @ MIT-MC, BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC,
7461 OK, the new LSR1 database is installed on MC only.
7462 Experimental versions of INQUIR, LOOKUP, NAME, and INQUPD are running here.
7463 I have tested each of these, and they seem to work.
7464 If anyone notices anything very bad going on, send me mail.
7466 Note that the user interface on ITS does not let you send entries
7467 to Twenex, only the other way around. This is because I could not
7468 bring myself to deal with the INQUIR source code. I will fix this
7469 sometime by getting up more guts, or just rewriting it. Inquires
7470 on all the ITS will be the same. This has the good side effect that
7471 if I have badly blown it this evening, you can copy a database to MC
7472 from one of the other machines and de-install the experimental programs.
7474 Note that the databases are not in a completely compatible format.
7475 LSRTNS has been updated to the new format.
7477 Date: 8 May 1983 23:30 EDT
7478 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7479 To: BUG-ARCHIVE @ MIT-MC
7481 I replied to SJOBRG.
7483 Date: 8 May 1983 23:25 EDT
7484 From: Robert W. Sjoberg <SJOBRG @ MIT-MC>
7485 To: BUG-ARCHIVE @ MIT-MC
7487 Can someone please point me to documentation (if any) on the format of the
7488 ITS archive files? I need enough information to be able to extract
7489 directory information and file contents (I don't plan on adding anything
7490 or deleting, just reading) from an archive file. Thanks.
7493 Date: Sunday, 8 May 1983, 06:59-EDT
7494 From: Christopher C. Stacy <CStacy at MIT-MC>
7495 Subject: [Re: Is I.T.S. mistaken as to today's date?]
7496 To: Glenn S. Burke <GSB at MIT-ML>
7497 Cc: BUG-EXPIRE at MIT-DMS, BUG-ITS at MC, CENT at MIT-ML,
7498 SYS-OPERATING-TROUBLE at MIT-DMS
7499 In-reply-to: The message of 8 May 83 04:56-EDT from Glenn S. Burke <GSB at MIT-ML>
7501 Well, I just hacked GMSGS to do just expire hacking if it starts under
7502 the job name EXPIRE, and I hacked TARAKA DEMSTR on DM to start it up.
7503 So, now everday GMSGS will be run and the directory should stay
7504 cleaned. I have not tested this, so let me know if there are
7505 problems, but it really should work.
7507 Date: 7 May 1983 02:55 EDT
7508 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7510 To: BUG-ITS @ MIT-MC
7514 I merged SYSHAK back into SYSTEM;.
7516 Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 6-May-83 20:14:20-EDT
7517 Date: Friday, 6 May 1983, 20:27-EDT
7518 From: David A. Moon <Moon@SCRC-TENEX>
7519 To: Jeffrey J Tyrone Sealy <TY@MIT-MC>
7521 In-reply-to: The message of 6 May 83 11:28-EDT from Jeffrey J Tyrone Sealy <TY at MIT-MC>
7523 Date: 6 May 1983 11:28 EDT
7524 From: Jeffrey J Tyrone Sealy <TY @ MIT-MC>
7525 The console-11 died today, and so ITS was running along fine
7526 but the cty was not doing anything and the swr was not being
7527 read. What is the optimum least obnoxious thing to do in
7529 Reboot the 11. Boot, RP0, P IOELEV, ITS ON. If this makes ITS crash
7530 as it sometimes does continue it.
7532 Date: 6 May 1983 11:28 EDT
7533 From: Jeffrey J Tyrone Sealy <TY @ MIT-MC>
7534 To: BUG-ITS @ MIT-MC
7535 cc: Moon @ SCRC-TENEX
7537 The console-11 died today, and so ITS was running along fine
7538 but the cty was not doing anything and the swr was not being
7539 read. What is the optimum least obnoxious thing to do in
7542 Date: Thursday, 5 May 1983 15:02-EDT
7543 From: MOON at SCRC-TENEX
7544 To: Christopher C. Stacy <CStacy at MIT-MC>
7545 Cc: BUG-ITS at MIT-MC
7547 In-reply-to: The message of 5 May 1983 04:01-EDT from Christopher C. Stacy <CStacy at MIT-MC>
7549 Well I guess it wouldn't hurt to make STLGET return a fifth value,
7550 although probably all the programs that call it look in the memory of
7551 the user whose index is the 4th value anyway.
7553 Date: 5 May 1983 04:12 EDT
7554 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7555 Subject: removing AI from stuff
7556 To: BUG-ITS @ MIT-MC
7558 TALK (WHOJ,U,WHOM,etc) fixed.
7560 Date: Thursday, 5 May 1983, 04:01-EDT
7561 From: Christopher C. Stacy <CStacy at MIT-MC>
7563 To: David A. Moon <Moon at SCRC-TENEX>
7564 Cc: BUG-ITS at MIT-MC
7565 In-reply-to: The message of 5 May 83 02:56-EDT from David A. Moon <Moon at SCRC-TENEX>
7567 Date: Thursday, 5 May 1983, 02:56-EDT
7568 From: David A. Moon <Moon@SCRC-TENEX>
7569 Date: 2 May 1983 08:05 EDT
7570 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7571 It would be nice if STLGET could actually return the HOSTS3 address
7572 of the host being served. It's sort of a crock to parse the name
7573 of the host, which might not always fix in six characters anyway.
7574 I am not sure if it is reasonable to try to get this info, but if
7575 I get ambitious I'll find out.
7576 You can get it from some standard place in the memory of the server job,
7579 Right; it's documented in the TELSER source that a bunch of variables
7580 should not move (ttyloc, binary-mode flag, host. etc.) but I didn't
7581 think it was a good idea for the system to make even that assumption
7582 about what the telnet server is like...
7584 Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 5-May-83 03:21:42-EDT
7585 Date: Thursday, 5 May 1983, 03:20-EDT
7586 From: David A. Moon <Moon@SCRC-TENEX>
7588 To: Christopher Stacy <CStacy@MIT-OZ>
7589 Cc: BUG-ITS@MIT-MC, ALAN@MIT-MC, DEVON@MIT-MC
7590 In-reply-to: The message of 27 Apr 83 08:41-EDT from Christopher Stacy <CStacy at MIT-OZ>
7592 Date: Wednesday, 27 April 1983, 08:41-EDT
7593 From: Christopher Stacy <CStacy at MIT-OZ>
7594 I have an idea for implementing Twenex-like logical names on ITS.
7595 My idea for getting around this is a to extend JOBRET so that there is
7596 a way for the BDH to tell the system: "I am going away now. Disconnect
7597 the user from me and retry the OPEN call using these args I am giving
7599 This sounds like a good idea to me.
7601 Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 5-May-83 02:57:26-EDT
7602 Date: Thursday, 5 May 1983, 02:56-EDT
7603 From: David A. Moon <Moon@SCRC-TENEX>
7605 To: Christopher C. Stacy <CSTACY@MIT-MC>
7607 In-reply-to: The message of 2 May 83 08:05-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
7609 Date: 2 May 1983 08:05 EDT
7610 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7611 It would be nice if STLGET could actually return the HOSTS3 address
7612 of the host being served. It's sort of a crock to parse the name
7613 of the host, which might not always fix in six characters anyway.
7614 I am not sure if it is reasonable to try to get this info, but if
7615 I get ambitious I'll find out.
7616 You can get it from some standard place in the memory of the server job,
7619 Date: 4 May 1983 23:36 EDT
7620 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7621 To: BUG-ITS @ MIT-MC
7623 I flushed AI from :INSTAL
7625 CENT@MIT-ML 05/03/83 03:23:21 Re: *msg list info
7627 CC: (BUG ITS) at MIT-MC
7628 Date: 3 May 1983 01:04 EDT
7629 From: Devon S. McCullough <DEVON @ MIT-MC>
7630 To: BUG-ITS @ MIT-MC
7631 Maybe it would be a good idea to be able to say :whois *ITS and get a
7632 description of what sort of messages should be addressed there,
7633 likewise for other magic mailing addressees. I wasn't able to find the
7634 info from :info even thought I am fairly sure it's in there somewhere..
7636 no, there is already a meaning too close to *its for your suggestion to be
7637 wise: :whois @ITS would do a :whois on everyone logged in on the ITSs (it
7638 doesn't work quite right now because AI is gone; could someone dig into
7639 :name or wherever this is hacked in and remove AI references?). this aside,
7640 i don't know whether your idea could even be made to work (someone who
7641 knows more about :whois and mailing lists might be able to tell you).
7643 If you had looked in the menu for the MAIL subtree, you would have found
7644 the node Announcements (also available from the top-level menu and through
7645 a footnote from the new-user-info subtree), which gets you to this
7646 information. for that matter, it's also mentioned in the mailing lists file
7647 right where the sysmsg lists are defined..
7649 Date: 3 May 1983 01:04 EDT
7650 From: Devon S. McCullough <DEVON @ MIT-MC>
7651 To: BUG-ITS @ MIT-MC
7653 Maybe it would be a good idea to be able to say :whois *ITS and get a description of what sort of messages should be addressed there, likewise for other magic mailing addressees. I wasn't able to find the info from :info even thought I am fairly sure it's in there somewhere.
7655 Date: 2 May 1983 14:04 EDT
7656 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7658 To: BUG-ITS @ MIT-MC, ARPANET-BBOARDS @ MIT-ML
7661 The AI KA10 has been flushed,
7662 please update your programs.
7666 ...Each evening from December to December
7667 Before you drift asleep upon your cot
7668 Think back on all the tales that you remember
7672 If he's heard the story
7673 And tell it loud and clear
7675 That once there was a fleeting wisp of glory
7678 Don't let it be forgot
7679 That once there was a spot
7680 For one brief shining moment
7681 That was known as Camelot....
7684 [From the Lerner and Loewe musical "Camelot"]
7686 Date: 2 May 1983 08:05 EDT
7687 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7688 To: BUG-ITS @ MIT-MC
7691 It would be nice if STLGET could actually return the HOSTS3 address
7692 of the host being served. It's sort of a crock to parse the name
7693 of the host, which might not always fix in six characters anyway.
7694 I am not sure if it is reasonable to try to get this info, but if
7695 I get ambitious I'll find out.
7697 Date: 2 May 1983 02:07 EDT
7698 From: Christopher C. Stacy <CSTACY @ MIT-MC>
7699 To: BUG-ITS @ MIT-MC
7702 In ITS 1342, the STLGET call returns a fourth value, as documented
7703 below. (Note that in previous ITS versions, Val 4 was present but only
7704 had the user index; this former behaviour was not documented.)
7706 STLGET: get information from Server Telnet
7710 val 1 XJNAME of server telnet
7711 val 2 TRMNAM of server telnet
7712 This is the sixbit name of the host connected to.
7713 val 3 SNAME of server telnet
7714 val 4 In LH: STY status bits
7715 In RH: index of telnet server job which owns the STY.
7717 This call can be used to find out where in the network
7720 The STY status bits are from the STYSTS table in ITS.
7721 Some of the more interesting ones include:
7722 %SSNET==4000 ;4.3 = 1 => THIS STY CONNECTED TO SOME NET SOCKETS.
7723 %SSCHA==2000 ;4.2 = 0 FOR ARPANET, 1 FOR CHAOS NET
7724 %SSTCP==1000 ;4.1 = 1 for TCP internet (%SSCHA must be 0)
7727 Date: 1 May 1983 01:58 EDT
7728 From: Alan Bawden <ALAN @ MIT-MC>
7731 cc: BUG-ITS @ MIT-MC, DEVON @ MIT-MC
7732 In-reply-to: Msg of 30 Apr 1983 21:25 EDT from Ed Schwalenberg <ED>
7734 Date: 30 April 1983 21:25 EDT
7735 From: Ed Schwalenberg <ED>
7737 Just for the sake of whatever ancient programs might depend on the
7738 behavior, I would strongly recommend that SYS: be equivalent to
7739 DSK:SYS; as the documentation states.
7741 Yeah, I was gonna mention a couple of days ago that it would be best to
7742 pick a new device name to have this behavior. SYSTEM:?
7744 CStacy's suggestion about giving JOBRET the ability to cause the OPEN to
7745 retry with different arguments is a good one I think. (I wonder if a
7746 kludge is possible even currently by giving the loser a translation and
7747 then causing him to get PCLSR'ed? That would be a wierd hack! The problem
7748 would be cleaning up all of the translations that would accumulate...) On
7749 the other hand I would really hate to have SYSTEM: (or whatever) be a
7750 jobdevice if it is going to be used all the time by DDT to find binarys.
7752 Date: 30 April 1983 21:25 EDT
7753 From: Ed Schwalenberg <ED @ MIT-MC>
7756 cc: DEVON @ MIT-MC, BUG-ITS @ MIT-MC
7758 Just for the sake of whatever ancient programs might depend on the behavior,
7759 I would strongly recommend that SYS: be equivalent to DSK:SYS; as the
7760 documentation states.
7762 While on the subject of ITS devices, I'm spending idle moments compiling a
7763 document on them- for each device, listing where it is implemented, what it
7764 does, what machines have (or had) it, what option bits for it exist, etc.
7765 Contributions are solicited, particularly by those of you who delight in
7766 using obscure devices and have thus discovered unusual properties (like nil