-
Notifications
You must be signed in to change notification settings - Fork 2
/
its.obugs0
15483 lines (13177 loc) · 571 KB
/
its.obugs0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Date: Friday, 29 April 1983, 00:33-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
To: David C. Plummer <DCP at MIT-MC>
Cc: BUG-ITS at MIT-MC, ian at MIT-OZ
In-reply-to: The message of 28 Apr 83 16:59-EDT from David C. Plummer <DCP at MIT-MC>
Date: 28 April 1983 16:59 EDT
From: David C. Plummer <DCP @ MIT-MC>
It's cheating. Terminal-0-F @Rutgers, c-Break, chaos:conn-list
shows that the contact name the LispM is using is NAME @rutgers.
Aha. Except that SYSTEM-T RUTGERS connects to MC and then gets
me to RUTGERS ok. It also works for SCORE.
Date: 28 Apr 1983 17:43 EDT (Thu)
From: Ian Macky <Ian@MIT-OZ>
To: David C. Plummer <DCP@MIT-MC>
Cc: BUG-ITS@MIT-MC
Subject: ARPA server
In-reply-to: Msg of 28 Apr 1983 17:13 EDT from David C. Plummer <DCP at MIT-MC>
Ah, OK, thanks much -- All it needed was for me to send a NL after
the connection was established.
Date: 28 April 1983 17:13 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: ARPA server
To: Ian @ MIT-OZ
cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC
I figured it out. You aren't following the protocol of the TCP
NAME server. Connecting isn't enough. After you connect, you
must then give the JCL. Try :chtn mcTCP rutgers 117 (the caps
are important). When it opens the connection, type return.
Date: 28 April 1983 16:59 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: CSTACY @ MIT-MC
cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC, ian @ MIT-OZ
Date: 27 April 1983 21:41 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
If I go to a LispM and finger RUTGERS, it connects to MC and I
get a Finger listing from RUTGERS. I can also TELNET from a
LispM to SCORE. So, I think the ARPA server works.
It's cheating. Terminal-0-F @Rutgers, c-Break, chaos:conn-list
shows that the contact name the LispM is using is NAME @rutgers.
Date: 27 April 1983 21:41 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: DCP @ MIT-MC, ian @ MIT-OZ
cc: BUG-ITS @ MIT-MC
If I go to a LispM and finger RUTGERS, it connects to MC and I
get a Finger listing from RUTGERS. I can also TELNET from a
LispM to SCORE. So, I think the ARPA server works.
Date: 27 Apr 1983 20:22 EDT (Wed)
From: Ian Macky <Ian@MIT-OZ>
To: David C. Plummer <DCP@MIT-MC>
Cc: BUG-ITS@MIT-MC
Subject: ARPA server
In-reply-to: Msg of 11 Apr 1983 06:39 EST from David C. Plummer <DCP at MIT-MC>
The ARPA server still doesn't work. If I go to MC and do F @RUTGERS
then I get a Rutgers Finger display. If, from OZ, I connect to the
ARPA server with "RUTGERS 117" then I never get the stuff. What it
was doing a few seconds ago was just hanging... I waited a minute or
so (on several occasions) but never got any response. Usually there's
a "Failed to TCP connect" message, and sometimes a "Timed-out" and
other similar things, but it has never once worked.
Date: Wednesday, 27 April 1983, 08:24-EDT
From: Christopher Stacy <CStacy@MIT-OZ>
Subject: SYS:
To: BUG-ITS@MIT-MC
Cc: ALAN@MIT-MC, DEVON@MIT-MC
In-reply-to: The message of 27 Apr 83 05:24-EDT from Alan Bawden <ALAN at MIT-MC>
I have an idea for implementing Twenex-like logical names on ITS.
The main feature which I want from logical names is search paths,
so that COM: and SYS: and others could be made to do the right thing.
The jobdev mechanism could be used as-is for this feature, but I dont
want the overhead of a jobdev and the slowness of doing the IOTs
multiple times.
My idea for getting around this is a to extend JOBRET so that there is
a way for the BDH to tell the system: "I am going away now. Disconnect
the user from me and retry the OPEN call using these args I am giving
you." Once this kind of JOBRET is done, the BDH's BOJ: channel is
closed and he should logout or reuse. There will probably want to be
some restrictions (like maybe: the BDH must not have .IOTed anything
yet) based on internal implementation details.
With this feature, a user could open the FOO: device, which would
start a BDH. The BDH would do a JOBCAL and find out the OPEN
parameters. Then the BDH does its thing to figure out where the user
really wants to be OPEN to, and does a JOBRET to pass control back to
ITS for retrying the OPEN call.
I am willing to implement this in ITS, and maybe put some kind of
interface on it for users (so they dont have to write their own BDH's
whenever they want to make a logical name).
Thoughts?
Date: 27 April 1983 11:04 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: SYS:
To: CStacy @ MIT-OZ
cc: BUG-ITS @ MIT-MC, ALAN @ MIT-MC, DEVON @ MIT-MC
I am willing to implement this in ITS, and maybe put some kind of
interface on it for users (so they dont have to write their own BDH's
whenever they want to make a logical name).
Thoughts?
As I recall, you threatened to do this for the sake of things
like HS: as well. Anyway, one possibility is to have users
translate FOO:*;* * to LOGICL:*;* *. The LOGICL device could
open DSK:hsname;xuname LOGICL to find an ascii file containing
lines of LOGICAL-DEVICE &REST PATHS, where PATHS can contain *s
for when to default to the field from the open call. You would
have to be careful to make sure loops don't happen (e.g., foo: ->
bar: -> foo: ...). Perhaps you can use LINK-DEPTH-EXCEEDED...
To appease people like me who already have 6 translations, you
may have to up the translation table size if you decide to use
this method.
Date: Wednesday, 27 April 1983, 08:41-EDT
From: Christopher Stacy <CStacy at MIT-OZ>
Subject: SYS:
To: BUG-ITS at MC
Cc: ALAN at MC, DEVON at MC
In-reply-to: The message of 27 Apr 83 05:24-EDT from Alan Bawden <ALAN at MIT-MC>
I have an idea for implementing Twenex-like logical names on ITS.
The main feature which I want from logical names is search paths,
so that COM: and SYS: and others could be made to do the right thing.
The jobdev mechanism could be used as-is for this feature, but I dont
want the overhead of a jobdev and the slowness of doing the IOTs
multiple times.
My idea for getting around this is a to extend JOBRET so that there is
a way for the BDH to tell the system: "I am going away now. Disconnect
the user from me and retry the OPEN call using these args I am giving
you." Once this kind of JOBRET is done, the BDH's BOJ: channel is
closed and he should logout or reuse. There will probably want to be
some restrictions (like maybe: the BDH must not have .IOTed anything
yet) based on internal implementation details.
With this feature, a user could open the FOO: device, which would
start a BDH. The BDH would do a JOBCAL and find out the OPEN
parameters. Then the BDH does its thing to figure out where the user
really wants to be OPEN to, and does a JOBRET to pass control back to
ITS for retrying the OPEN call.
I am willing to implement this in ITS, and maybe put some kind of
interface on it for users (so they dont have to write their own BDH's
whenever they want to make a logical name).
Thoughts?
Date: 27 April 1983 05:24 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: SYS:
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 27 Apr 1983 02:36 EDT from Devon S. McCullough <DEVON>
Date: 27 April 1983 02:36 EDT
From: Devon S. McCullough <DEVON>
Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3;
prray tell?
I thought about this some more, and I talked it over with Moon, and it
appears that the answer is: For no good reason.
There are some red herring issues like: What should happen if you try to
read the binary directory listing from SYS:.FILE. (DIR)? And: What
exactly should happen if you open SYS:FOO > for writing? But it appears
that a perfectly good answer to most of those objections is: Well what
makes you think that the SYS: device should behave at all like the DSK:
device anyway? (Why should it have a binary directory, and why should you
be able to write to it.)
There would be the compatibility problem with current programs that use
SYS: as a synonym for DSK:SYS;, but they could all be trivially fixed.
Think of al the places that implement the SYS;, SYS1;, ... search
themselves currently...
(Now, can somebody think of something clever for the COM: device to do?)
Date: 27 April 1983 02:36 EDT
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC
Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3; prray tell?
Date: 27 April 1983 01:20 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: CRASH;CRASH QSKCH
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC
In-reply-to: Msg of 26 Apr 1983 09:33 EDT from Ken Harrenstien <KLH>
Date: 26 April 1983 09:33 EDT
From: Ken Harrenstien <KLH>
Note, by the way, that this has been with us for a long time; there
are simply too many processes trying to run, and the present design of
ITS imposes some limits which cannot be avoided without doing clever
things like mapping buffers in and out of exec address space. Both
CHAOS and TCP code are also liable to wild runaway use of buffers if
the net hardware burps.
Has anyone thought seriously about mapping buffers? (I appreciate that I
have just said a mouthful.)
Date: 26 April 1983 13:05 EDT
From: Richard Mark Soley <SOLEY @ MIT-MC>
Subject: CRASH;QSKCH
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC, TY @ MIT-MC
In-reply-to: Msg of 26 Apr 1983 05:56 EDT from Christopher C. Stacy <CSTACY>
Date: 26 April 1983 05:56 EDT
From: Christopher C. Stacy <CSTACY>
To: TY, SOLEY
cc: BUG-ITS, JPG
Re: CRASH;QSKCH
Did ITS crash, or did you stop it? All that is on the console
is "Warn KLDCP" --that is, ITS did not print any crash message
and it looked like it was just halted in its tracks. In particular,
I dont see the PC or anything printed anywhere.
ITS didn't crash, we stopped it. No-one was getting any response at all.
-- Richard
Date: 26 April 1983 09:33 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: CRASH;CRASH QSKCH
To: JPG @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC
Looking at this crash with PEEK's autopsy mode reveals that sure
enough the system was out of low memory, because there were tons
of disk channels open.
Note, by the way, that this has been with us for a long time; there
are simply too many processes trying to run, and the present design of
ITS imposes some limits which cannot be avoided without doing clever
things like mapping buffers in and out of exec address space. Both
CHAOS and TCP code are also liable to wild runaway use of buffers if
the net hardware burps.
What is interesting is that one TEX job had 9 disk channels open, 7
of them to the same file! There was another TEX running too, tho not
as hoggish. And there were several ATSIGN CHAOS jobs scattered
around; these invariably seem to litter up the system whenever it
gets wedged (cause or effect?)
Date: 26 April 1983 07:01 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: Translations
To: ALAN @ MIT-MC
cc: BUG-DDT @ MIT-MC, PGW @ MIT-XX, BUG-its @ MIT-ML
In-reply-to: Msg of 23 Apr 1983 16:23 EST from Alan Bawden <ALAN>
DDT now uses an unlikely SNAME when it creates inferiors, to help
prevent naive users from translating themselves into problems.
Date: 26 April 1983 05:56 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: CRASH;QSKCH
To: TY @ MIT-MC, SOLEY @ MIT-MC
cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC
Did ITS crash, or did you stop it? All that is on the console
is "Warn KLDCP" --that is, ITS did not print any crash message
and it looked like it was just halted in its tracks. In particular,
I dont see the PC or anything printed anywhere.
The messages it was printing were to tell you that the load on the
system was too high (in the sense that there were no disk channels).
That is why the system no doubt looked wedged to users.
Btw, I fixed ITS so that it will only print those warning messages
every thirty seconds, so it wil not overflow the console buffer
(which is what the SYS MSGS LOST means. Maybe it should say
SYS MSGS LOTS instead...)
Date: 26 April 1983 05:17 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
Now ITS only does running out of resource checks if it has not done
one in the last thirty seconds. This is to avoid deluging the system
console with messages like "Warning: Inadequate space in low core LMEMFR/2".
Date: Tuesday, 26 April 1983, 00:37-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: FileComputer
To: PSZ at MIT-ML, HDT at MIT-OZ
Cc: BUG-ITS at MIT-ML
In-reply-to: The message of 24 Apr 83 14:11-EDT from Peter Szolovits <PSZ at MIT-ML>
There are two different, incompatible file systems on CADR-27.
If you want to use what I believe is called the "FS" filesystem, you
need to use CFTP. If you use the "FC" filesystem (written by RMS) you
can use either CFTP or just the FC: device.
I just typed :LISTF FC:CSTACY; on MC, and it listed my directory for me.
What do you think is wrong?
Cheers,
Chris
Date: 25 April 1983 18:18 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC
Please check out CRASH;CRASH QSKCH.
What happened is the system console began printing out pages and pages
of "Warning: No free qsk channels.
n SYS MSGS LOST"
and then it crashed in some way, hence the CRASH dump. (I was not here
at the time, I am just transmitting the contents of the log book to you
so you can check this out.)
Date: 25 April 1983 04:13 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: ASSLIS is such a kludge!
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-LISP @ MIT-MC
Date: 24 April 1983 18:31 EST
From: Alan Bawden <ALAN @ MIT-MC>
File deletion is supposed to work on the core-link, and I distinctly
remember that in the (recent) past it HAS worked (DCP might remember
otherwise?).
I don't remember if it is supposed to or not.
If anyone wants a few cheap laughs (and can read Midas), they should take a
look at MC:L;ASSLIS >. It's certainly the kludgiest program I've seen in a
long time.
I thought I could read Midas, but I have a hard time reading that thing.
Date: 24 April 1983 18:31 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: ASSLIS is such a kludge!
To: BUG-ITS @ MIT-MC
cc: BUG-LISP @ MIT-MC
CLU:.FILE. (DIR) currently lists:
LISP MIDAS BARQIO CLOSED-> HACTRN
FOO MIDAS BARQIO CLOSED-> HACTRN
L MIDAS BARQIO CLOSED-> HACTRN
L MIDAS FOOQIO CLOSED-> HACTRN
The reason it says " HACTRN" is that it used to say "ALAN HACTRN" until I
logged out that job. Before that all four entries were in CLOSED->CLOSED
state and I tried to delete tham using in DDT. Instead of deleting them
it seems to have decided I wanted to USE them. I checked, and DDT did not
still have any CLx channels. I guess these will stay here until MC crashes
next.
File deletion is supposed to work on the core-link, and I distinctly
remember that in the (recent) past it HAS worked (DCP might remember
otherwise?).
If anyone wants a few cheap laughs (and can read Midas), they should take a
look at MC:L;ASSLIS >. It's certainly the kludgiest program I've seen in a
long time.
Date: 24 April 1983 13:11 EST
From: Peter Szolovits <PSZ @ MIT-ML>
Subject: FileComputer
To: HDT @ MIT-OZ
cc: BUG-ITS @ MIT-ML
In-reply-to: Msg of 24 Apr 1983 01:49 EST (Sun) from Howard D. Trachtman <HDT at MIT-OZ>
Date: 24 Apr 1983 01:49 EST (Sun)
From: Howard D. Trachtman <HDT at MIT-OZ>
To: PSZ at MIT-OZ
Re: FileComputer
I'm not sure what happened to the fc device as accesable from ITS.
I do know that cftp will work.
Try :cftp fc
login psz
dir fc:psz;
and you should see your files. The fc: is needed as the filecomputer
supports two different file systems.
Indeed you are right. Therefore the FC: device in ITS is broken. Could
someone fix it?
Date: Sunday, 24 April 1983, 01:51-EST
From: David A. Moon <Moon at MIT-MC>
Subject: Running out of low core
To: Christopher C. Stacy <CSTACY at MIT-MC>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy <CSTACY at MIT-MC>
Date: 19 April 1983 21:17 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
The check for running out of low core I put in goes off quite alot,
and frequently overflows the system console message buffer. Usually
when this goes off, it means that the system appears wedged to users.
Do you suppose there could be a bug in the system with someone not
returning some flavor of buffer space at the right time?
More likely there is just isn't enough address space for all the disk
buffers, disk directories, chaos buffers, tcp buffers, core link buffers,
and everything else. Isn't it the case that if you wait a while and
kill all jobs with open files the space always comes back eventually?
Date: 23 April 1983 16:23 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Translations
To: PGW @ MIT-XX
cc: BUG-DDT @ MIT-MC, BUG-its @ MIT-ML
In-reply-to: Msg of 23 Apr 1983 1328-EST from Paul G. Weiss <PGW at MIT-XX>
Date: 23 Apr 1983 1328-EST
From: Paul G. Weiss <PGW at MIT-XX>
To: bug-its at MIT-ML
Re: Translations
...
What follows is a wallpaper file so you can better understand what I mean:
------------------------------------------------
* arch;* *,ar1:inna;* *
...
*:find arch;
INFERIOR-CREATION FAILED? u:BYE
INFERIOR-CREATION FAILED?:INPUSH 1u
This is because translating *:ARCH;* * => AR1:INNA;* * will cause
translations to happen for devices other than DSK: (like USR:, which is why
DDT can't create any inferior jobs). You should create the following two
translations instead:
DSK:ARCH;* * => AR1:INNA;* *
ML:ARCH;* * => AR1:INNA;* * ;or whatever ITS you are using.
(I have CC'd this to BUG-DDT beacuse I presume DDT could be more robust
than this by supplying some unlikely-to-be-translated directory name
whenever it tries to use the USR: device. I checked, and DDT currently
doesn't supply an SNAME when opening USR:, which just begs to shaft people
like this.)
Date: 23 Apr 1983 1328-EST
From: Paul G. Weiss <PGW@MIT-XX>
Subject: Translations
To: bug-its@MIT-ML
In order to get around the problem of TEX not accepting device names for
input files, I have been using file translations. In particular, I do
arch;* *,ar1:inna;* *
and use the "pseudo-directory" ARCH; to refer to stuff inside the archive.
This works fine for TEX.
The problem is that it causes other things to go awry, namely, when I try
to do
:FIND ARCH;
it gives me a strange error.
It also keeps me from logging out with u since it tries and fails to run
:BYE. I must log out with 1u (or remove the translation).
What follows is a wallpaper file so you can better understand what I mean:
------------------------------------------------
* arch;* *,ar1:inna;* *
*archML INNA AR1 6.045J
Free files = 175, Wasted Words = 0
0 H1 1 1 02/02/83 16:55:58
0 H10 1 3 03/10/83 18:23:21
0 H12 2 1 03/08/83 16:42:41
0 H13 6 1 03/09/83 10:16:47
0 H14 4 1 03/10/83 19:38:01
0 H15 6 1 03/10/83 22:32:47
0 H16 2 1 03/17/83 12:46:21
0 H17 2 1 03/29/83 15:33:57
0 H18 13 1 04/04/83 10:29:40
0 H19 1 4 04/07/83 22:28:43
0 H2 10 1 02/02/83 16:56:00
0 H20 1 2 04/07/83 22:29:43
0 H21 5 2 04/08/83 10:37:00
0 H23 2 1 04/13/83 16:02:52
0 H24 3 1 04/14/83 15:50:58
0 H25 2 1 04/20/83 17:13:16
0 H26 2 1 04/23/83 12:38:10
0 H26A 1 1 04/20/83 17:02:45
0 H26B 1 2 04/21/83 16:43:30
0 H26C 1 1 04/21/83 16:26:47
0 H26D 1 2 04/21/83 16:27:02
0 H26E 1 3 04/21/83 16:27:23
0 H26F 1 3 04/21/83 16:58:04
0 H3 23 1 02/07/83 16:43:30
0 H4 5 1 02/07/83 18:07:10
0 H6 1 1 02/14/83 19:10:38
0 H7 1 2 03/10/83 18:22:44
0 H8 11 1 02/24/83 15:27:48
0 H9 1 2 03/10/83 18:22:57
*:find arch;
INFERIOR-CREATION FAILED? u:BYE
INFERIOR-CREATION FAILED?:INPUSH 1u
-----------------------------------------
-------
Received: from SCRC-BLACKSTONE by SCRC-TENEX with CHAOS; Fri 22-Apr-83 11:27:24-EST
Date: Friday, 22 April 1983, 11:23-EST
From: Robert W. Kerns <RWK@SCRC-TENEX>
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: BUG-ITS@MIT-MC
In-reply-to: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy <CSTACY at MIT-MC>
Date: 19 April 1983 21:17 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
The check for running out of low core I put in goes off quite alot,
and frequently overflows the system console message buffer. Usually
when this goes off, it means that the system appears wedged to users.
Do you suppose there could be a bug in the system with someone not
returning some flavor of buffer space at the right time?
I am of the opinion this problem has been with us for years.
Date: 22 April 1983 08:21 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
AI's processor is *fucked*. I turned it off. Maybe it will start
randomly working again when I turn it back on, probably tomorrow or
the next day.
Date: Friday, 22 April 1983, 07:58-EST
From: Christopher Stacy <CStacy at MIT-OZ>
Subject: MC is now the bug host.
To: BUG-ITS at MC, BUG-MAIL at MC
COMSAT now uses MC as the "bug host". I changed all the appropriate
mailing lists, and installed the latest COMSAT on all four machines.
I put the following in the MC:NAMES > file:
;;; MC is now the default BUG host.
;;; If a program exists on all machines, its BUG list normally
;;; only needs to be on MC.
;;;
;;; The reasons to define a BUG- name on some ITS besides MC include:
;;; o The program is not used on MC.
;;; o The program is mainly used on the other ITS, and most of
;;; the maintainers are there, and there is an entry
;;; on MC which forwards to the apporpriate machine.
;;; o In the absence of such reasons, define it on MC only.
;;;
;;; If a message is sent from some other ITS to a bug list which is not
;;; defined, it will be forwarded here. If the bug list is not defined
;;; here, the message will be sent instead to BUG-RANDOM-PROGRAM.
Chris
Date: 20 April 1983 01:44 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems]]
To: BUG-ITS @ MIT-MC
Date: 15 April 1983 08:51 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems]
To: BUG-MAIL @ MIT-MC
More info. I notice bug-mail is still on AI. Should this be changed?
------------------------------
Date: Thursday, 14 April 1983 21:15:03 EST
From: Hank.Walker@CMU-CS-VLSI
To: David C.Plummer <DCP@MIT-MC>
Subject: Mailer problems
Message-ID: <1983.4.15.2.10.27.Hank.Walker@CMU-CS-VLSI>
It is probably not the UNIX mailer that is causing the problems. Mail
messages from MIT go to CMU-CS-A. If it is TCP mail, it is shipped
to the CMU-CS-PT VAX over the Ethernet, which translates the stuff into
NCP, and sends it back to CMUA where it is delivered to me. That mail is
then autoforwarded to me at CMU-CS-VLSI, where I live, even though INFO-COBOL
has my CMU-CS-A mailing address. So the mail is delivered directly
to CMU-CS-A, which is a KL10 running TOPS-10, rather than to a UNIX machine.
I have no troubles receiving mail from any other site on the net to either
CMU-CS-VLSI directly or to CMU-CS-VLSI, which communicates with the ARPAnet
over an Ethernet gateway.
Date: 20 April 1983 01:44 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages]]
To: BUG-ITS @ MIT-MC
I originally sent this to BUG-MAIL@MC, which tried to go to AI,
which is down. Perhaps somebody should find an AI backup tape,
and get NAMES > (carefully) and get the more important BUG lists
over to MC? There is a followup to this message coming soon...
------------------------------
Date: 14 April 1983 21:04 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages]
To: BUG-MAIL @ MIT-MC
cc: Hank.Walker @ CMU-CS-A
Forwarding complaint about the MC mailer. Following are some
parts of the MC mail stats file. Other ditties of information:
Other messages to CMU-CS-A get through successfully. The ones I
saw happened to be small messages. Could this be the Unix
braindeath that insists on completely delivering messages
(instead of queuing) before it gives a completion reply? If so,
the product of number of recipients by the length of the message
is a roungh indication of the length of time it will take to
deliver the message. If things are sufficiently slow, MC will
correctly timeout. If this is true, I would have to say it is
the Unix mail server that is broken.
Date: Thursday, 14 April 1983 20:51:27 EST
From: Hank.Walker@CMU-CS-VLSI
To: David C.Plummer <DCP@MIT-MC>
Subject: Infinite mail messages
Message-ID: <1983.4.15.1.49.7.Hank.Walker@CMU-CS-VLSI>
Would you please refrain from sending messages to INFO-COBOL until your
mailer is fixed. I realize that it is not your fault, but quite frankly I
am tired of receiving anywhere from 2 to 10 messages from anyone who sends
mail originating at MIT, particularly mail that I've already seen before.
Lean on your system manager, or charge him a quarter for every duplicated
mail message that your system emits.
195935 ICP->CMU-CS-A(SMTP)
195939 XTO->Bob.Walker
195939 XTO->David.Nichols
195940 XTO->Dill
195940 XTO->Everhart
195940 XTO->gail.kaiser
195941 XTO->Hank.Walker
195941 XTO->Highnam
195942 XTO->Kazar
195942 XTO->Lamb
195943 XTO->Lehman
195943 XTO->muller@CMU-CS-GANDALF
195943 XTO->Provan
195944 XTO->Rudy.Nedved
195944 XTO->Sherman
195945 XTO->Shipman
195945 XTO->Shrager
195945 TEXT->
200048 NO COMPLETION REPLY, R=10
200503 Queued: <[MIT-MC].635105> for CMU-CS-A
202005 Attempting to send messages queued to host CMU-CS-A
202005 ICP->CMU-CS-A(SMTP)
202008 QID=<[MIT-MC].635105>
202009 XTO->Bob.Walker
202009 XTO->David.Nichols
202010 XTO->Dill
202010 XTO->Everhart
202011 XTO->gail.kaiser
202011 XTO->Hank.Walker
202012 XTO->Highnam
202013 XTO->Kazar
202013 XTO->Lamb
202014 XTO->Lehman
202014 XTO->muller@CMU-CS-GANDALF
202015 XTO->Provan
202015 XTO->Rudy.Nedved
202016 XTO->Sherman
202016 XTO->Shipman
202017 XTO->Shrager
202017 TEXT->
202120 NO COMPLETION REPLY, R=10
DCP@MIT-ML 04/19/83 22:13:15
To: (BUG its) at MIT-MC
Has anybody changed the ATTY/DTTY code recently. It's probably
pure coincidence, but MC has crashed on me several times
just after sending me a message. Perhaps that's just a bad
time to reference a disk?
Date: 19 April 1983 21:18 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
In XITS on MC, I patched out the LMEMFR check bug message for the moment.
Date: 19 April 1983 21:17 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
The check for running out of low core I put in goes off quite alot,
and frequently overflows the system console message buffer. Usually
when this goes off, it means that the system appears wedged to users.
Do you suppose there could be a bug in the system with someone not
returning some flavor of buffer space at the right time?
Date: 16 April 1983 04:36 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
ITS 1336 (XITS on MC) has additional warning messages for no
free disk channels and no free job slots, to go with the no
free low core warning. This junk seems to work.
Date: 16 April 1983 02:52 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: crash info
To: BUG-ITS @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC
ITS now print warning when the amount of exec free space
gets too low. This is to make it easier to walk over to the
console and guess why the machine is wedged. Also put a bug
message in the RH10 QINTE code where it has been dying all day,
so it prints the disk number and offending controller bits.
ITS 1334 installed on MC as XITS.
If trouble, revert to NITS.
Date: 16 April 1983 01:17 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: hardware trouble
To: BUG-ITS @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC, GSB @ MIT-MC
MC is having bad hardware trouble.
ITS died several times today with disk hardware errors.
This was at QINTE+45, where it checks some random ctrl bits (and the
comment reads "worse than unsafe".) I think this was on unit #0.
Just now the system came down because the -11 timed out waiting on the
KL. Earlier today it came down becuase there were too many parity
errors. Yesterday and the day before the -11 died, and had to be
power cycled to get to work again.
Date: 13 April 1983 19:56 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets)
To: Moon @ SCRC-TENEX
cc: BUG-ITS @ MIT-MC, cmb @ SCRC-VIXEN, bug-lispm @ SCRC-TENEX
The last ML ITS was assembled in middle of March, plenty of time for your
NSUBNT change to take effect. I checked it out just now, and found
that you modified the CHAOS source on SYSTEM; rather than SYSHAK; which
is where all of the recent TCP/IP work has been happening. So I just
now bumped up NSUBNT to 100. in the SYSHAK version (the only change you
made) and someone will have to assemble a new ML ITS sometime.
I guess now that things are obviously working, SYSHAK should be merged back
into SYSTEM, so I will do that eventually.
Received: from SCRC-DALMATIAN by SCRC-TENEX with CHAOS; Wed 13-Apr-83 19:36:59-EST
Date: Wednesday, 13 April 1983, 19:38-EST
From: David A. Moon <Moon@SCRC-TENEX>
Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets)
To: bug-its@MIT-MC
Cc: cmb@SCRC-VIXEN, bug-lispm@SCRC-TENEX
Note the date on the second enclosed message. I guess if this continues
for another two months I'll find the time to do it myself.
Date: Wednesday, 13 April 1983, 19:18-EST
From: Clark M. Baker <cmb at SCRC-VIXEN>
Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics
To: BUG-LISPM at SCRC-TENEX
I haven't been able to load files from ML onto a 3600 at Symbolics.
However, ML is up. I can load files from ML onto a LM-2 at Symbolics.
I can load files from ML onto MIT-PI. What is happening?
Date: 21 February 1983 20:49 EST
From: David A. Moon <MOON5 @ MIT-MC>
Subject: ML
To: BUG-ITS @ MIT-MC
I made NSUBNT (number of Chaosnet subnets) be a more reasonable size.
ML (the only ITS machine that does its own Chaosnet routing) should
get a reassembled ITS when convenient.
Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 13-Apr-83 19:34:50-EST
Date: Wednesday, 13 April 1983, 19:36-EST
From: David C. Plummer <DCP@SCRC-TENEX>
Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics
To: cmb@SCRC-VIXEN, BUG-LISPM@SCRC-TENEX, BUG-ITS@MIT-MC
In-reply-to: The message of 13 Apr 83 19:18-EST from Clark M. Baker <cmb at SCRC-VIXEN>
Date: Wednesday, 13 April 1983, 19:18-EST
From: Clark M. Baker <cmb at SCRC-VIXEN>
I haven't been able to load files from ML onto a 3600 at Symbolics.
However, ML is up. I can load files from ML onto a LM-2 at Symbolics.
I can load files from ML onto MIT-PI. What is happening?
I'll betchya ML's routing table isn't big enough. This has been CC'ed
to BUG-ITS so somebody will be annoyed it is in they're mailbox and fix
it (maybe me the next time I'm on MC).
Date: 11 April 1983 06:39 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: ARPA server
To: Ian @ MIT-OZ
cc: BUG-ITS @ MIT-MC
Date: 10 Apr 1983 1954-EST
From: Ian Macky <Ian@MIT-OZ>
Is this ever going to work again? Would be nice to get Arpa FINGERs and
such things from us Chaos-only ("we'll be up in THREE weeks, for sure")
sites.
-------
It should work. Try @<DCP>DUP AI TCP. If you want the rest of
the world to respond to FINGER, you will have to convince them to
convert the NCP finger program to TCP, and also make sure
whatever user program you are using contacts the correct socket
number (I think the ARPA server wants it in octal, but i can't
remember).
Date: 10 Apr 1983 1954-EST
From: Ian Macky <Ian@MIT-OZ>
Subject: ARPA server
To: Bug-ITS@MIT-MC
Is this ever going to work again? Would be nice to get Arpa FINGERs and
such things from us Chaos-only ("we'll be up in THREE weeks, for sure")
sites.
-------
Date: 7 April 1983 23:13 EST
From: David C. Plummer <DCP @ MIT-MC>
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC
Date: 7 April 1983 17:26 EST
From: Alan Bawden <ALAN @ MIT-MC>
DIRHNG^F acts pretty graceless. Actually I can imagine that DIRHNG could
reasonably display an informative directory.
...of what jobs have what directories open on the DIRHNG device.
If you need a test case, the Versatec spooler always has one open
on .glpr..
Date: 7 April 1983 17:26 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC
DIRHNG^F acts pretty graceless. Actually I can imagine that DIRHNG could
reasonably display an informative directory.
CSTACY@MIT-AI 04/05/83 11:58:45
To: (BUG ITS) at MIT-AI
In ITS 1332, on MIT-AI:
ITS crashed with the message PKT: Freeing packet still in use!
Dumped to AI:CRASH;ITS FREPKT
Date: Tue, 5 Apr 1983 04:45 EST
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To: Edjik <NCP.EG%U-GSB-HOW@SU-SCORE>
Cc: BUG-ITS@MIT-MC, BUG-MIDAS%OZ@MIT-MC, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC,
KLH@MIT-MC
Subject: Gross OZ lossage
In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik <NCP.EGK at SU-GSB-HOW at SU-SCORE>
KLH knows more about midas than most people, including you. Please keep
your nitbrained views to yourself.
Date: 5 April 1983 01:43 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Gross OZ lossage
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, DCP @ MIT-MC,
KLH @ MIT-MC
In-reply-to: Msg of 4 Apr 1983 23:19 EST (Mon) from Martin David Connor <MARTY at MIT-OZ>
What is all this flaming horseshit in my mailbox?!?! Is there anyone who
will argue that it was correct that there were TWO BUG-MIDAS mailing lists?
No. Have we fixed that? Yes. (Thank you Ian.)
Now is there somebody out there who can actually claim to be maintaining
MIDAS to a greater extent than KLH? If so, then lets hear from them. If
not, then everyone shut the hell up.
Date: 5 April 1983 00:57 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: Gross 8 inch spikes in various people's heads
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, KLH @ MIT-MC,
BUG-MIDAS @ MIT-OZ
And you, Mr. Conner, have as much to learn as I.
Reactionary is not bullshit. Go read a history book someday and
notice how progress is often achieved by reactionaries and their
ideas.
As for the local history of OZ, there were several people willing
(and eager) to help in creating another ITS. Moon was willing to
hack microcode and oversee changes needed to the system (e.g.,
for disk support) which I was willing to help with. As I recall,
you were against the idea of ITS on OZ. Several other people
attended the Wars of Futility where it was decided to run 20X.
These people warned about all the features that 20X was lacking
and many of the problems it had. But the wars were futile; the
decision was out of our hands.
So now our only recourse is to sit back and be little brats about
the whole thing. "Nah, nah, I told you so..." I, for one, am
proud to be one of these brats.
For god's sake bring up a machine because it is the Right Thing, not
because you hate another machine so much.
Wrong. Both are often true. In fact, this is how TWENEX was
developed. The history told to me was that BBN disliked Bots-10 so
much they went off and wrote TENEX. DEC started seeing the light
and bought it from them and made it work on a 20.
Learn from the mistakes of
another attempt, ...
If TWENEX only could.
Plummer, ... until you learn to work FOR A GOAL instead of
AGAINST AN ALTERNATIVE you will be counterproductive to the
causes you Support.
Goal: Help build better Lisp Machines. I think I am working for
this goal. Goal: help MIT when I have the time. I think I do a
fair job here. Goal: convince people they lost completely when
they decided to run TWENEX on OZ. Perhaps this is a subconsious
goal. How actively I work toward it is not clear. I would hope
to think I keep such discussions among (ITS) friends except when
something blatant happens. If you didn't blindly defend the
obvious problems, OZ would probably be a lot nicer.
Penny, I already know I will regret sending this, because so many
minds are already closed, but I had to try. Forgive me.
Mine is closed just enough so that spikes cannot penetrate. I
know who does the real TWENEX development at MIT, and they have
often responded to the requests of others for (ITS-like)
features. I hope they also understand the spirit in which I
write these flames.
Marty, you earned your second spike.
Date: 4 Apr 1983 23:19 EST (Mon)
From: Martin David Connor <MARTY@MIT-OZ>
To: David C. Plummer <DCP@MIT-MC>
Cc: "NCP.EGK@SU-GSB-HOW"@SU-SCORE, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC,
BUG-MIDAS@MIT-OZ, BUG-OZ@MIT-MC, KLH@MIT-MC
Subject: Gross ITS lossage
In-reply-to: Msg of 4 Apr 1983 21:40 EST from David C. Plummer <DCP at MIT-MC>
Dogma, Plain and simple will be the downfall of ITS.
It contains the ideas and talent to be great, but lacks the tolerance
of other ideas that will see it wither and die.