From MARTY%MIT-OZ at MIT-MC.ARPA Fri Mar 30 11:39:00 1984 From: MARTY%MIT-OZ at MIT-MC.ARPA (Martin David Connor) Date: Mar 30 1984 04:39 EST (Fri) Subject: [Who?: forwarded] Message-ID: Could someone stop MC from sending unparsable ITS mail headers out onto the network? Received: from MIT-MC by MIT-OZ via Chaosnet; 30 Mar 84 02:26-EST Date: 30 Mar 1984 00:00 From: TK at MIT-MC To: marty at MIT-OZ Indeed. It's about 65 degrees and was sunny until the sun went down. It was "cold" today, and everyone was complaining. From GSB at MIT-MC Wed Mar 28 00:00:00 1984 From: GSB at MIT-MC (Glenn S. Burke) Date: 28 March 1984, 00:00 Subject: ucprl5+1 again Message-ID: dumped to crash;ucplr5 gsb1 Also complained about extra garbage in ufd STUDNT. >From the looks of the return action on the system console, it's about to go again. It's definitely dropping characters too. From ALAN at MIT-MC Wed Mar 28 00:00:00 1984 From: ALAN at MIT-MC (Alan Bawden) Date: 28 March 1984, 00:00 Subject: All is not well... Message-ID: MC crashed twice this afternoon at QINTE+44. Crash dump in CRASH;QINTE +44. Some kind of disk hardware lossage? While I was sitting here it crashed again at UCPRL5+1. Thats in CRASH;UCPRL5 +1. Some kind of screwup running around circular page lists. From KLH at MIT-MC Fri Mar 23 00:00:00 1984 From: KLH at MIT-MC (Ken Harrenstien) Date: 23 March 1984, 00:00 Subject: ITSDOC? Message-ID: P.S. you might want to consider calling it SYSDOC instead, because this has the feature that changes to files therein will be reported on the system console. Not a real vital issue. From KLH at MIT-MC Fri Mar 23 00:00:00 1984 From: KLH at MIT-MC (Ken Harrenstien) Date: 23 March 1984, 00:00 Subject: ITSDOC? Message-ID: Actually I have been tempted a couple of times recently to revive the ITSDOC directory and set the documentation up as it was on AI, where .INFO.;ITS FOO was usually a link to ITSDOC;FOO >. This has the advantage of letting us keep numbered versions of the documentation, and given that I am frobbing the documentation occasionally these days, it might be nice to not always immediately lose the previous version. I like that idea! From ALAN at MIT-MC Mon Mar 19 00:00:00 1984 From: ALAN at MIT-MC (Alan Bawden) Date: 19 March 1984, 00:00 Subject: ITSDOC? In-Reply-To: Msg of 19 Mar 1984 02:09-EST from David Vinayak Wallace Message-ID: Date: 19 March 1984 02:09-EST From: David Vinayak Wallace What happened to the ITSDOC directory? When I wondered the same thing, we went and looked at AI backups to discover just where was kept there. What we found was nothing that isn't now named MC:.INFO.;ITS. Actually I have been tempted a couple of times recently to revive the ITSDOC directory and set the documentation up as it was on AI, where .INFO.;ITS FOO was usually a link to ITSDOC;FOO >. This has the advantage of letting us keep numbered versions of the documentation, and given that I am frobbing the documentation occasionally these days, it might be nice to not always immediately lose the previous version. From GUMBY at MIT-MC Mon Mar 19 00:00:00 1984 From: GUMBY at MIT-MC (David Vinayak Wallace) Date: 19 March 1984, 00:00 Subject: ITSDOC? Message-ID: What happened to the ITSDOC directory? From pgs%MIT-OZ at MIT-MC.ARPA Sun Mar 18 00:00:00 1984 From: pgs%MIT-OZ at MIT-MC.ARPA (Patrick G. Sobalvarro) Date: Sunday, 18 March 1984, 00:00 Subject: T03 SDRC ? In-Reply-To: The message of 18 Mar 1984 16:31-EST from Kent M Pitman Message-ID: Received: from MIT-MC by MIT-OZ via Chaosnet; 18 Mar 84 16:32-EST Date: 18 March 1984 16:31-EST From: Kent M Pitman Subject: T03 SDRC ? To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC I am pretty sure that T03 is not a line to SDRC any more. I think it is just a 300 baud dialup like T04-T07. Could someone please check this and update its info in whatever database is used by FINGER? Thanks. -kmp CStacy seems to have done this, but the 11 does not think that this line is under modem control, so it won't work very well as one. When I next work on this tty line cruft I'll change this, if the thing really is a dialup line. Incidentally, if T03 is a dialup now, what phone is it connected to? From KMP at MIT-MC Sun Mar 18 00:00:00 1984 From: KMP at MIT-MC (Kent M Pitman) Date: 18 March 1984, 00:00 Subject: T03 SDRC ? Message-ID: I am pretty sure that T03 is not a line to SDRC any more. I think it is just a 300 baud dialup like T04-T07. Could someone please check this and update its info in whatever database is used by FINGER? Thanks. -kmp From KLH at MIT-MC Tue Mar 13 00:00:00 1984 From: KLH at MIT-MC (Ken Harrenstien) Date: 13 March 1984, 00:00 Subject: CRASH;IPQUSI Message-ID: Thanks for the dump. I have fixed the bug in the source (INET), but did not bother to patch the current binary. ITS should be re-assembled one of these days. What happened was that a bad UDP datagram arrived which was not long enough to hold a UDP header. Bug #1 was not checking the length for this. Fortunately the UDP dest port value happened to be zero in that buffer, so the code tried to find a UDP queue for port 0. Bug #2 was that this succeeded -- it "found" an non-existent queue with all the relevant info zero. IPQUSI caught this when it noticed it was about to try interrupting the system job! Both bugs are now fixed, and I deleted the crash dump. From ALAN at MIT-MC Tue Mar 13 00:00:00 1984 From: ALAN at MIT-MC (Alan Bawden) Date: 13 March 1984, 00:00 Subject: No subject In-Reply-To: Msg of Tue 13 Mar 84 06:54 EST from Christopher C. Stacy Message-ID: Date: Tue, 13 Mar 84 06:54 EST From: Christopher C. Stacy Date: 29 February 1984 10:59-EST From: Kent M Pitman SYS4^F clears the screen and types NON-DIRECTORY DEVICE. Shouldn't this give a no such directory error? I assume DDT or ITS is somehow stripping the 4 and assuming I'm trying to reference the SYS device. My file defaults end up with SYS4: in them... I think this might be an ITS bug. In DDT at NCTLF2, it tries to open the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason, and succeeds. As I already said, the place to do something about this is in the unknown device handler. (You know, SYS;ATSIGN DEVICE? The file we don't have a source for?) ITS proper, and DDT are doing exactly the right things. From CStacy at MIT-MC.ARPA Tue Mar 13 12:54:00 1984 From: CStacy at MIT-MC.ARPA (Christopher C. Stacy) Date: Mar 13 84 06:54 EST Subject: No subject In-Reply-To: The message of 29 Feb 84 10:59-EST from Kent M Pitman Message-ID: Date: 29 February 1984 10:59-EST From: Kent M Pitman SYS4^F clears the screen and types NON-DIRECTORY DEVICE. Shouldn't this give a no such directory error? I assume DDT or ITS is somehow stripping the 4 and assuming I'm trying to reference the SYS device. My file defaults end up with SYS4: in them... I think this might be an ITS bug. In DDT at NCTLF2, it tries to open the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason, and succeeds. From GSB at MIT-MC Mon Mar 12 00:00:00 1984 From: GSB at MIT-MC (Glenn S. Burke) Date: 12 March 1984, 00:00 Subject: crash dumps Message-ID: bughalt at IPQUSI+6, dumped to CRASH;IPQUSI 031284. a couple days ago, bughalt at TYIREM (actually TYIRE1+1), dumped to CRASH;TYIREM 030984. From ALAN at MIT-MC Sun Mar 11 00:00:00 1984 From: ALAN at MIT-MC (Alan Bawden) Date: 11 March 1984, 00:00 Subject: RFNAME & randomness Message-ID: RFNAME on a SPY: channel should return the appropriate FN1. RFNAME on a CHAOS: channel should return as a directory name a host number just like TCP: channels. BTW, I have always felt that when opening the CLI: device, filenames should be treated exactly as they are when you open the USR: device. That is, you should be able to use a specification as the first filename if the second filename is 0. From KMP at MIT-MC Sat Mar 10 00:00:00 1984 From: KMP at MIT-MC (Kent M Pitman) Date: 10 March 1984, 00:00 Subject: No subject Message-ID: ITS was losing from network and local terminals (although apparently working ok from dialups). The 11 didn't seem to have a parity error light on and was not obviously stopped or anything, but we (ALAN and I) did :.;BOOT11 and the world went back to normal. Is this the right thing to have done and/or is there any more debugging information we could have scrounged up before reloading the 11? -kmp From JGA at MIT-MC Fri Mar 9 00:00:00 1984 From: JGA at MIT-MC (John G. Aspinall) Date: 9 March 1984, 00:00 Subject: jga;ar3: In-Reply-To: Msg of 9 Mar 1984 08:01-EST from Christopher C. Stacy Message-ID: Alan fixed it. I guess neither of us sent a follow up. Sorry to make unneeded work. cheers... From CSTACY at MIT-MC Fri Mar 9 00:00:00 1984 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 9 March 1984, 00:00 Subject: jga;ar3: In-Reply-To: Msg of 7 Mar 1984 11:40-EST from John G. Aspinall Message-ID: Maybe you already copied the files into a new AR3:, since reading and writing files there works fine for me. From GSB at MIT-MC Fri Mar 9 00:00:00 1984 From: GSB at MIT-MC (Glenn S. Burke) Date: 9 March 1984, 00:00 Subject: MIT Miraculous Levitation PDP-10 Message-ID: Date: 8 Mar 1984 20:45 PST (Thu) From: Ian Macky . . . The "internal error" was apparently due to cca's being down. And ML has officially gone west. But it hasn't reached the horizon yet, so don't dyke it out of the host tables. Its disk has been fixed, and its processor/pager problem is going to be worked on this weekend. While i don't expect it to accept incoming net connections ever, it will certainly need to reach out and write some files. From Ian at SRI-NIC Fri Mar 9 05:45:00 1984 From: Ian at SRI-NIC (Ian Macky) Date: Mar 8 1984 20:45 PST (Thu) Subject: [DJC%MIT-OZ: no such device + no such machine] Message-ID: <[SRI-NIC].IAN. 8-Mar-84 20:45:34> I can't think of a better place for this to go, since I forget the same of the server that the OZ FINGER uses... Date: March 8 1984 18:03-PST From: DJC%MIT-OZ at MIT-MC.ARPA To: bug-finger%MIT-OZ at MIT-MC.ARPA Re: no such device + no such machine Received: from MIT-MC by SRI-NIC with TCP; Thu 8 Mar 84 18:08:06-PST [PHOTO: Recording initiated Thu 8-Mar-84 8:58PM] MIT TOPS-20 Command Processor 5(750)-2 End of ATTACH.CMD.7 End of COMAND.CMD.5 @f chan at cca [CCA-UNIX via MIT-MC] ? Internal error - NO SUCH DEVICE [CCA-UNIX via MIT-ML] %No response %No path to site @pop [PHOTO: Recording terminated Thu 8-Mar-84 9:00PM] The "internal error" was apparently due to cca's being down. And ML has officially gone west. From JGA at MIT-MC Wed Mar 7 00:00:00 1984 From: JGA at MIT-MC (John G. Aspinall) Date: 7 March 1984, 00:00 Subject: jga;ar3: Message-ID: JGA;AR3: seems to have suffered in the recent archive brouhaha, at least I get a hung job every time I try to copy into it. Could someone knowledgeable take a look at it, and give me an informed opinion on whether I should go into salvage mode? From ALAN%MIT-OZ at MIT-MC.ARPA Sun Mar 4 20:58:00 1984 From: ALAN%MIT-OZ at MIT-MC.ARPA (Alan Bawden) Date: Mar 4 1984 14:58 EST Subject: %TPC.C In-Reply-To: Msg of 4 Mar 1984 00:00-EST from Devon S. McCullough Message-ID: Date: Sunday, 4 March 1984 00:00-EST From: Devon S. McCullough To: BUG-OZ at MIT-MC Re: SET TERMINAL ETX-IS-^C Date: 3 March 1984 20:50-EST From: David C. Plummer To: DEVON @ MIT-MC cc: BUG-MINITS @ MIT-MC Date: 3 March 1984 17:56-EST From: Devon S. McCullough ^\ ^C should toggle a flag (that gets reset when you close a connection) that interchanges ^C and ^Z on the keyboard so I don't have to do this manually. Alternatively, you could hack the 20X monitor to do the same thing... Hey, we could hack ITS to do this too. ITS already has a similar hack for exchanging "[" and "]" with "(" and ")". I bet we could even do it right. (There is at least one reasonable alternative to simply swapping ^Z and ^C at the lowest level of input. That is to simply have a way to move the CALL key from ^Z to ^C. Then you would want ^_^C to be the way to type a ^C, except that that already has a meaning I think...) From CSTACY at MIT-MC Fri Mar 2 00:00:00 1984 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 2 March 1984, 00:00 Subject: No subject In-Reply-To: Msg of 1 Mar 1984 22:29-EST from Leigh L. Klotz Message-ID: Date: 1 March 1984 22:29-EST From: Leigh L. Klotz To: BUG-ITS WHAT IS SYS2;TS LINE? It was written 9/5/77, and just says it's a PDUMP file. I did :LINE instead of :LINK. It printed Guess What!!?? Your program has just gone off into HYPERSPACE!^G Of course, it was disowned. It's appears to be a wholine program of some sort, but I don't know what the message means or where the source is. From ALAN at MIT-MC Thu Mar 1 00:00:00 1984 From: ALAN at MIT-MC (Alan Bawden) Date: 1 March 1984, 00:00 Subject: MC woes: PACK NOT BAWDENIZED In-Reply-To: Msg of Thu 1 Mar 84 17:02 EST from David A. Moon Message-ID: OK, using Moon's new routine in DUMP I have repaired the damage I caused last night. I used the incremental dump of Feb. 28 to reset the reference dates of all files to their state as of that dump. Thus currently no file on MC has a reference date later than 2/28/84 (although many of them have in fact been written since then). I can't think of any way that this situation can screw up except the following: someone who hadn't touched a file in a long time until yesterday, and who continues not to touch it for some time in the future will have his file migrate just a little sooner than he might expect. I don't know of any other program, besides DUMP, that uses the reference date for anything important. From KLOTZ at MIT-MC Thu Mar 1 00:00:00 1984 From: KLOTZ at MIT-MC (Leigh L. Klotz) Date: 1 March 1984, 00:00 Subject: No subject Message-ID: WHAT IS SYS2;TS LINE? It was written 9/5/77, and just says it's a PDUMP file. I did :LINE instead of :LINK. It printed Guess What!!?? Your program has just gone off into HYPERSPACE!^G Of course, it was disowned. From ALAN at MIT-MC Thu Mar 1 00:00:00 1984 From: ALAN at MIT-MC (Alan Bawden) Date: 1 March 1984, 00:00 Subject: archives Message-ID: MEYER;AR0 TODO and LPH;AR31 MACSYM are both broken archives, they should be restored from backup tape. (This was caused by the installation of a broken archive device the other day.) I have renamed them to MEYER;XAR0 TODO and LPH;XAR31 MACSYM because I believe I have seen COMSAT trying to reference them both, which makes trouble. They seem to be unsalvageable, but I didn't delete them in case someone knows something I don't.