From MoonatSCRC Fri Dec 31 00:00:00 1982 From: MoonatSCRC (David A. Moon) Date: Friday, 31 December 1982, 00:00 Subject: Chaosnet FILE server Message-ID: I have installed new versions of the FILE server on EE,ML,MC,OZ,SCRC,SPEECH,XX. Sources are on MC,OZ,SCRC,XX. Please let me know if there are any problems. The 20X version can be deinstalled by deleting SYSTEM:CHAOS.FILE.497. The ITS version can be deinstalled by copying MC:DEVICE;CHAOS OFILE to DSK:DEVICE; CHAOS FILE. From MoonatSCRC-POINTER Wed Dec 29 00:00:00 1982 From: MoonatSCRC-POINTER (David A. Moon) Date: Wednesday, 29 December 1982, 00:00 Subject: Chaosnet FILE server Message-ID: I have installed new versions of the FILE server on EE,ML,MC,OZ,SCRC,SPEECH,XX. Sources are on MC,OZ,SCRC,XX. Please let me know if there are any problems. The 20X version can be deinstalled by deleting SYSTEM:CHAOS.FILE.497. The ITS version can be deinstalled by copying MC:DEVICE;CHAOS OFILE to DSK:DEVICE; CHAOS FILE. From KLH at MIT-MC Wed Dec 29 00:00:00 1982 From: KLH at MIT-MC (Ken Harrenstien) Date: 29 December 1982, 00:00 Subject: Flow control in STYNET Message-ID: After thinking about it for a while, I agree with Moon and you will find that the TCP STYNET similarly lacks flow control on input. This not only provides the best approximation to being directly connected, but also is by far the simplest way to avoid having things get hung up. I don't see any point in "fixing" this, unless we also worry about trying to fix direct and dialed-in TTY lines. Note that the intelligent terminal protocol does allow the terminal to hack flow control and make sure that stuff gets to ITS (or whatever program) properly. I guess you could compare this Alto lossage with someone trying to play back a recording of modem tones into a MC dialup and expecting ITS to exert flow control! From ED at MIT-MC Wed Dec 29 00:00:00 1982 From: ED at MIT-MC (Ed Schwalenberg) Date: 29 December 1982, 00:00 Subject: STYNET connections from CHAOS net lacking flow control Message-ID: A while ago someone complained to me that he was losing attempting to edit a file on his Alto or something and then piss out the file as a command to an ITS. His symptom sounded like TTY input buffer overflow, i.e., the echoed output was missing chunks, and had feeps instead. I see that KLH just discovered that in Chaos STYNET, there is no flow control, and Moon comments that it's only a problem with line-at-a-time input. This gives rise to two questions: Is it similarly a problem with Arpa STYNET, and is it worth fixing so that intelligent terminals and hosts can shove script files across the network and have them work as expected? From MACRAK at MIT-MC Fri Dec 24 00:00:00 1982 From: MACRAK at MIT-MC (Stavros M. Macrakis) Date: 24 December 1982, 00:00 Subject: T1061 screwups Message-ID: Bug was on this end. Sorry. From CENT at MIT-ML Sun Dec 19 00:00:00 1982 From: CENT at MIT-ML (CENT at MIT-ML) Date: 19 Dec 1982 00:00 Subject: ai lossage Message-ID: ai keeps halting. i keep continuing it. From KLHatMIT-MC Sat Dec 11 00:00:00 1982 From: KLHatMIT-MC (Ken Harrenstien) Date: 11 December 1982, 00:00 Subject: No subject Message-ID: It is kind of painful that DDT doesn't repurify itself or anything when a new system is brought up. Every other program now knows how to do this. I don't necessarily advocate that DDT actually dump itself to SYS;ATSIGN DDT (a little dangerous since so much stuff depends on that), but at least it ought to be able to re-set whatever variables or stuff it has to, to compensate for running under a new system version. A little slower on startup, but at least not fatal (as so many poor lusers are finding). It definitely DOES keep some people from logging in. From JPGatMIT-MC Sat Dec 11 00:00:00 1982 From: JPGatMIT-MC (Jeffrey P. Golden) Date: 11 December 1982, 00:00 Subject: No subject Message-ID: MC:SYSTEM;ITS 1279 and ITS 1281 were the same! So I deleted the former and linked it to the latter. From RWKatSCRC-TENEX Wed Dec 8 00:00:00 1982 From: RWKatSCRC-TENEX (Robert W. Kerns) Date: 8 Dec 1982, 00:00 Subject: bogus uptime record In-Reply-To: <[MIT-DMS].251798> Message-ID: That's nothing. Once when someone set the time wrong on MC, I claimed to have been up for 2 years straight. I felt much better when that was straightened out, believe you me! ------- From SWG Wed Dec 8 00:00:00 1982 From: SWG (S. W. Galley) Date: 8 Dec 1982, 00:00 Subject: bogus uptime record In-Reply-To: Message of 07 Dec 82 at 0439 EST by CStacy@MIT-MC Message-ID: <[MIT-DMS].251798> For the same reason, DM claimed to have been up for about 300 days! From DCPatSCRC-TENEX Tue Dec 7 00:00:00 1982 From: DCPatSCRC-TENEX (David C. Plummer) Date: Tuesday, 7 December 1982, 00:00 Subject: SUPDUP TTYSMT In-Reply-To: The message of 7 Dec 82 18:31-PST from Barry Margolin at MIT-MULTICS Message-ID: Return-Path: Date: 7 December 1982 21:31 est From: Barry Margolin at MIT-MULTICS Subject: Re: SUPDUP TTYSMT To: Richard Lamson cc: David C. Plummer , BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, BUG-LISPM at MIT-MC In-Reply-To: Message of 7 December 1982 21:23 est from Richard Lamson The TTYSMT variable already has other non-graphics information in it. It has information about local-editing and line-saving capability, I believe. Indeed true. To determine if the terminal supports supdup graphics you test the BIT in ttysmt which is for that purpose; it is incorrect to test the entire variable against zero. From Barry Wed Dec 8 03:31:00 1982 From: Barry (Barry) Date: 7 December 1982 21:31 est Subject: SUPDUP TTYSMT In-Reply-To: Message of 7 December 1982 21:23 est from Richard Lamson Message-ID: The TTYSMT variable already has other non-graphics information in it. It has information about local-editing and line-saving capability, I believe. From rslatSCRC-TENEX Tue Dec 7 00:00:00 1982 From: rslatSCRC-TENEX (Richard Lamson) Date: Tuesday, 7 December 1982, 00:00 Subject: SUPDUP TTYSMT In-Reply-To: The message of 6 Dec 82 07:10-PST from Bernard S. Greenberg Message-ID: Date: 4 December 1982 21:42-EST From: David C. Plummer To: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, BUG-LISPM at MIT-MC New field in the right half of the SUPDUP TTYSMT (TTY Smarts or graphics variable). DEFSYM %TRTIM==003700 DEFSYM $TRTIM==060500 ;5 BIT FIELD WHICH IS THE SIGNED OFFSET FROM GMT ;MINUS #o20; A VALUE OF ZERO MEANS DON'T ;KNOW, DON'T CARE, OR USER PROGRAM HASN'T ;IMPLEMENTED IT YET Yoiks! I was under them impression that TTYSMT was always going to be reserved for graphics information only. That is, a graphics server would always be able to tell that the device didn't support graphics if TTYSMT was zero. Are you sure this is what you want to do, rather than create a new user variable? -- Richard From CSTACYatMIT-MC Tue Dec 7 00:00:00 1982 From: CSTACYatMIT-MC (Christopher C. Stacy) Date: 7 December 1982, 00:00 Subject: No subject Message-ID: ITS 1283 is now running as NITS on AI. ITS 1279 is called "ITS" on that machine. From CStacyatMIT-MC Tue Dec 7 00:00:00 1982 From: CStacyatMIT-MC (Christopher C. Stacy) Date: 7 December 1982, 00:00 Subject: No subject In-Reply-To: The message of 6 Dec 82 18:58-EST from KFL at MIT-AI Message-ID: KFL at MIT-AI 12/06/82 18:58:07 Why does AI claim to have been up for 195 days? "Surpassing all previous uptime records"? ...Keith Because the system time was wrong for a few minutes when it first came up the other day. From CENT at MIT-ML Tue Dec 7 00:00:00 1982 From: CENT at MIT-ML (CENT at MIT-ML) Date: 07 Dec 1982 00:00 Subject: ai up? Message-ID: i think it got confused during being brought up after the power shutdown this past sunday, or maybe shortly thereafter. don't know how though. the claim is wildly wrong. cstacy, did you bring ai up? do you know anything more about this? From KFL at MIT-AI Mon Dec 6 00:00:00 1982 From: KFL at MIT-AI (KFL at MIT-AI) Date: 06 Dec 1982 00:00 Subject: No subject Message-ID: previous uptime records"? ...Keith From DCPatMIT-MC Sun Dec 5 00:00:00 1982 From: DCPatMIT-MC (David C. Plummer) Date: 5 December 1982, 00:00 Subject: No subject Message-ID: OK, OK. For all of you who were wondering why in hell I did this, I'll tell you. Symbolics has imprisoned me in sunny southern California for 3 weeks. I still log into MC occaisionally which isn't too difficult since we do happen to be on the chaosnet. If any of you have ever seen me hacking on MC, my prompt that DDT prints out has an amazing amount of junk in it. One of those items is the time. Unfortunately, it is eastern time, not pacific time. Sooo... ALAN and I started making joking comments to each other about time zone correction in prompts, and this is what happened. I don't know how many of us bug-its, bug-twenex, bug-supdup or bug-lispm are going to take this seriously, but if I find some spare time I may make local modifications to this LISPM and hack my prompt code accordingly. I will probably get around to putting it in the KTVs and MINITS systems at some point in time. From DCPatMIT-MC Sat Dec 4 00:00:00 1982 From: DCPatMIT-MC (David C. Plummer) Date: 4 December 1982, 00:00 Subject: No subject Message-ID: New field in the right half of the SUPDUP TTYSMT (TTY Smarts or graphics variable). DEFSYM %TRTIM==003700 DEFSYM $TRTIM==060500 ;5 BIT FIELD WHICH IS THE SIGNED OFFSET FROM GMT ;MINUS #o20; A VALUE OF ZERO MEANS DON'T ;KNOW, DON'T CARE, OR USER PROGRAM HASN'T ;IMPLEMENTED IT YET