From GJC at MIT-MC Tue Mar 31 00:00:00 1981 From: GJC at MIT-MC (GJC at MIT-MC) Date: 31 Mar 1981 00:00 Subject: No subject Message-ID: A job 542C54 CHAOS 54C54 +LOGIN ? 2 0 55% 14:43:32 just used up 14 hours of MC cpu time doing absolutely nothing. Maybe this is not a problem, I don't know. From Moon at MIT-MC Mon Mar 30 00:00:00 1981 From: Moon at MIT-MC (Moon at MIT-MC) Date: 30 Mar 1981 00:00 Subject: > filename convention Message-ID: Well, yes and no. That's what the ">" convention is defined to do. I would not care to defend that as the best choice among the possible definitions of what it should do. From Moon at MIT-MC Mon Mar 30 00:00:00 1981 From: Moon at MIT-MC (Moon at MIT-MC) Date: 30 Mar 1981 00:00 Subject: ITS Arpanet system maintenance Message-ID: This is a non-trivial change. If we are to do it, it will require approximately one man-year of highly-skilled system programming, possibly more, and it is unlikely that I will be available for this. If I were you, I would start communicating with the sponsors and inform them that it will be impossible to meet this deadline without extra funding to hire someone to do it. I expect that most other hosts that don't run TOPS-20/TENEX nor Multics are in the same boat. By the way, unlike the 96-bit leader change which we did 2 or 3 years ago, this change is of absolutely no benefit to us (unless it really is enforced, in which case it "benefits" us by allowing us to continue to use the Arpanet). The DOD Standard protocols (Internet and TCP) provide the same functionality as the existing protocols, except with the details all changed around, and with some additional functionality for AUTODIN II which is not of much interest to us. From PIQUE at MIT-MC Mon Mar 30 00:00:00 1981 From: PIQUE at MIT-MC (PIQUE at MIT-MC) Date: 30 Mar 1981 00:00 Subject: Long input echo delays Message-ID: I am coming in over a 300baud dialup and I have been experiencing long echo delays intermittently. eg, in com links, where I assume I am talking directly to the operating system, sometimes things will hang and then I will get a burst of 80chars all at once after about a 5 second wait. On a direct dialup this does not sound `normal', so in case it's a bug that can be fixed, I figured I would mention it. -kmp From WILL Sun Mar 29 00:00:00 1981 From: WILL (William D Clinger) Date: 29 MAR 1981, 00:00 Subject: No subject Message-ID: "will;atolia >" refers to "will;atolia demo10" rather than to "will;atolia 41". Is this as it should be? Peace, Will From zemon Thu Mar 26 00:00:00 1981 From: zemon (Landon M. Dyer) Date: 26 MAR 1981, 00:00 Subject: No subject Message-ID: I will be a good Luser and report a small bug I have seen : When I log on from NBS-TIP (MITER-TIP, PENT-TIP, etc etc.) the following stragne thing happens. ITS will print out the usualy warnings about tourist usage during the daytime, then : AI ITS.1197. PWORD.1733. TTY 43 /\ || \\=== ITS will 'hang' about here (the actual position varies from login to login.) Typing a space or ^Z will get ITS to continu printing, though. This has been going on for at least a month, possibly two... -Landon- From RMS Thu Mar 26 00:00:00 1981 From: RMS (Richard M. Stallman) Date: 26 MAR 1981, 00:00 Subject: No subject Message-ID: I think I have fixed the ECHOIN bug with a patch to make NECHOIN+12 or so call TYIFL2 instead of UFLS. TYIFL2 is a new tag which is TYIFLS plus a few. Refer to the source. I haven't tried this out. From ELLEN at MIT-MC Tue Mar 24 00:00:00 1981 From: ELLEN at MIT-MC (ELLEN at MIT-MC) Date: 24 Mar 1981 00:00 Subject: This is an ARPAnet problem, but is there any way which ITS can help it? Message-ID: MILNE at MIT-AI Howdy, One other thing from all of us over in Britian.I am not sure if this is the best mail box for this, but perhaps you can pass it on. Our link from edinburgh to MIT is very complex, going thourgh at least 5 machines before getting to MIT. This is then extremely unreliable. very often we get cut off by a failure over here, and can't get back to close our job. This is a British and ARPA problem, but results in us staying logged in when we don't exist. I talso seems that these crashes always take place just before I finish typing MAIL. What is the current thing to kill these jobs? Could it be clever and discover we were in MAIL and send the partial message for us, perhaps with a message added at the botto bottom? Anyway, this is the basic problem, though I'd let you know. cheers, Rob Milne, Edinburgh From GSB at MIT-ML Sat Mar 21 00:00:00 1981 From: GSB at MIT-ML (GSB at MIT-ML) Date: 21 Mar 1981 00:00 Subject: echoin Message-ID: It seems that ECHOIN does not cause the setting (or clearing or whatever) of the flag which says that input has been waited for near the bottom of the screen. This causes my tty prescan to sometimes be very gross by causing a --more-- when a character is typed when it is on the last line of the screen. I have temporarily patched this by fooling it to not use echoin for the first character of its input, but a combination of rubbing out and forced redisplay can make it happen still. From GJC at MIT-MC Fri Mar 20 00:00:00 1981 From: GJC at MIT-MC (GJC at MIT-MC) Date: 20 Mar 1981 00:00 Subject: No subject Message-ID: The load on MC in terms of the number of users and the jobs they are running had not been great for the last few hours. 20 users, fiar share = 67%, 5 macsymas, no TEX's or GLP's or other core hoggers running. However, system response is *BAD*, *REALLY* BAD. Long pauses whilegetting i/o in Peek, echoing slow, you can type ahead maybe ten or so characters. A rubout might take 3 seconds to happen. From MOON at MIT-MC Fri Mar 20 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 20 Mar 1981 00:00 Subject: BUG => ITS (net hangage on DM) Message-ID: I changed the network code around slightly in that system to make it more robust to the hardware problems MC was having at the time (which turned out to be a marginal optical isolator in the network interface). I don't know anything about the DM network interface, which is different from all the others. I thought you already had a patch in to take out some of the change; did the patch get lost or is it failing in the presence of the patch? The changes to the code had to do with deciding when the net was up and when it was down, and fixed problems where the system would crash if it went up and down too rapidly. Maybe you could look at a source compare of the old and new IMP and SYSJOB files, and give a "second opinion"? From PDL Fri Mar 20 00:00:00 1981 From: PDL (P. David Lebling) Date: 20 Mar 1981, 00:00 Subject: BUG => ITS Message-ID: <[MIT-DMS].190788> Ever since we have been running ITS 1198 on DM, we have every so often gotten into a state where after a crash the net will not come up. When it gets into this state the only way out is to power cycle the net interface. I suppose this sounds like a hardware lossage, but as it started when we installed 1198, I am suspicious. Any chance someone knowledgeable could look at this in the code? Dave From TAA Wed Mar 18 00:00:00 1981 From: TAA (Timothy A. Anderson) Date: 18 Mar 1981, 00:00 Subject: No subject In-Reply-To: Message of 18 Mar 81 at 2002 EST by RWK@MIT-MC Message-ID: <[MIT-DMS].190561> If I say J$J, set .pagrange from DDT, then kill J, whoever gets that job slot next will have .pagrange set (determined by saying J$J quickly and getting the same job slot...). This apparently was the cause of the lossage with inqupd on DM, anyway. -taa From RWK at MIT-MC Wed Mar 18 00:00:00 1981 From: RWK at MIT-MC (RWK at MIT-MC) Date: 18 Mar 1981 00:00 Subject: No subject Message-ID: It looks like RMS patched INQUPD to do a .SUSET of .SPAGRANGE Do you have any evidence other than INQUPD that .SPAGRANGE isn't being cleared? Note that in my INQUPD I have here, .PAGAHEAD is zero, which should mean that the feature is disabled. A word search sdoesn't show any .SUSET for turning it on. What I see looks more like the standard lossage with the entry for ______. What I don't understand is how the current one got in there. It's the one introduced by OSI1P (now PST) on the 7th of March. I could have sworn I eliminated that one when it caused the database to lose before. From TAA Wed Mar 18 00:00:00 1981 From: TAA (Timothy A. Anderson) Date: 18 Mar 1981, 00:00 Subject: BUG => its Message-ID: <[MIT-DMS].190555> In ITS 1198 (on DM), and ITS 1207 (MC), .pagahd and .pagrange have the amusing property that they are not reset by killing the job they are set in. Thus, if I get job 3, set those variables, and kill it, whoever gets job 3 next will end up with them set. The bug PDL reported about the death of inqupd on DM seems to be related to its use of page-ahead: when we patched out all the appropriate susets, it ran to completion. RWK, could this be the cause of your problems with it on MC? DM has been exhibiting rather entertaining behavior with respect to the NSWPGS user variable: jobs with page-ahead set (due to the leftover .pagahd and .pagrange from old inqupds) get negative nswpgs with high frequency. We've also been observing reasonably random behavior in certain jobs, perhaps caused by their pages being swapped in at the wrong place? -taa From PDL Wed Mar 18 00:00:00 1981 From: PDL (P. David Lebling) Date: 18 Mar 1981, 00:00 Subject: Interesting statistics Message-ID: <[MIT-DMS].190487> PEEKing at a freshly minted INQUPD on DM produces: DM ITS 1198 Peek 463 03/18/81 09:52:16 Up time = 12:53:26 Memory: Free=26 Runnable Total=182 Out=-91 Users: High=23 Runnable=5 Index Uname Jname Sname Status TTY Core Out %Time Time PIs 21 INQUPD INQUPD INQUIR PAGE ? 163 -91 11% 11 Fair Share 35% Totals: 163 11% 11 Logout time = 1:26:42 Lost 32% Idle 0% Null time = 9:44:28 Ch Idx Uname Jname Mode Bks+Wds Rd% Pk File Name 12 21 INQUPD INQUPD RI 0+0 0% 19 INQUIR; LSR1 LOCK I watched it get up to 168 in and -238 out before it quit. Dave From CBF at MIT-MC Sun Mar 15 00:00:00 1981 From: CBF at MIT-MC (CBF at MIT-MC) Date: 15 Mar 1981 00:00 Subject: TS3TTY 281, H19 padding & C100 char insert/delete Message-ID: Nah, RWK didn't do that, I did, and took it into account in the 5ms figure. From RWKatMIT-MC Sun Mar 15 00:00:00 1981 From: RWKatMIT-MC (Robert W. Kerns) Date: 15 March 1981, 00:00 Subject: TS3TTY 281, H19 padding & C100 char insert/delete Message-ID: MOON at MIT-MC 03/15/81 20:23:08 Re: TS3TTY 281, H19 padding & C100 char insert/delete Subject: TS3TTY 281, H19 padding & C100 char insert/delete To: CBF at MIT-MC CC: (BUG ITS) at MIT-MC You probably didn't read the comments, since RWK changed the padding units to be of 1/8's of milliseconds rather than milliseconds in the case of Y-position dependent padding. I didn't do this. I thought CBF must have done it. It was done before I hacked this. From MOON at MIT-MC Sun Mar 15 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 15 Mar 1981 00:00 Subject: TS3TTY 281, H19 padding & C100 char insert/delete Message-ID: You probably didn't read the comments, since RWK changed the padding units to be of 1/8's of milliseconds rather than milliseconds in the case of Y-position dependent padding. From CBF at MIT-MC Sun Mar 15 00:00:00 1981 From: CBF at MIT-MC (CBF at MIT-MC) Date: 15 Mar 1981 00:00 Subject: TS3TTY 281, H19 padding & C100 char insert/delete Message-ID: In response to RWK's testing of the H19 line insert/delete padding, I have raised it a little bit in the source. I probably rounded down where I should have rounded up in calculating it. I went to patch it in the running system on MC, and found a highly ridiculous value of 5 ms of padding per line moved there. (I am raising the value from .625 ms per line moved to .75). Please tell me that this 5ms value is totally random. If its true, it is not consistent with other programs which use 18 ms net for each line isnet/delete done. I have left the 5ms figure pending clarification. In the grand tradition of TS3TTY kludges, I have put entries for char insert/delete in for the C100. In order to put the the null needed to exit char insert in the ASCIZ string, I have resorted to 8 bit characters and used a 200. As best as I can tell this will be loaded as 8 bits and deposited as 7 on a Morton and then be caught at the apropriate level and turned into the kludge thats needed to get a null out on a Morton. However, if I'm wrong there are two other possible results: 1) Use of char insert on a C100 on a Morton will result in never exiting char insert mode. This would probably result in rather random screen lossage. 2) It will crash ML? (Does DM have Morton also?) Whoever brings up the next ITS on these machines should probably test this immediately to make sure option 2 does not result. Note that %TOCID will not be turned on by default for :TCTYP C100 since char insert/delete only works on new microcode C100s. If you have an old microcode C100 you should mail someone like me a set of 4 or 5 2716s depending on whether you also want a Sail character Prom for the 2nd charset slot. From ___165 at MIT-MC Wed Mar 11 00:00:00 1981 From: ___165 at MIT-MC (___165 at MIT-MC) Date: 11 Mar 1981 00:00 Subject: No subject Message-ID: How come When the GLP spooler wires down its pages in the I/O portion of memory, they don't get shuffled into high memory? I thought there was code for this. This caused MC to deadlock. Maybe there is too much high memory available and it didn't try to swap it out? From RWK Wed Mar 11 00:00:00 1981 From: RWK (Robert W. Kerns) Date: 11 MAR 1981, 00:00 Subject: LNKEDP Message-ID: Oh, it's just the entry in SYSCTD not indicating the need to decode the channel argument. I'll fix it when MC comes back up again. From RWK at MIT-MC Wed Mar 11 00:00:00 1981 From: RWK at MIT-MC (RWK at MIT-MC) Date: 11 Mar 1981 00:00 Subject: No subject Message-ID: I've just brought up the new ITS on MC. It seems to be OK except for a few minor problems: The padding on H19's for I/D line doesn't seem to work right in some circumstances. I'm not sure what's going on, but it fails whenever EMACS recomputes the window, resulting in ^S^Q lossage. But it always seems to work when I Insert or delete any number of lines manually. The LNKEDP system call always gives WRONG TYPE DEVICE. It's not immediately obvious to me just why, from looking at the source. (BTW, this was put in the wrong place, effectivly removing the LOAD system call by screwing the binary search). Anyway, MC is about to go down for PM, so I'll leave this for later. As near as I can tell, page-ahead is winning, or at least isn't causing the system to lose. But I haven't tried it on a very loaded system yet. From RLB Tue Mar 10 00:00:00 1981 From: RLB (Richard L. Bryan) Date: 10 MAR 1981, 00:00 Subject: No subject Message-ID: GJC at MIT-MC 03/10/81 18:02:59 On MC now we are getting jobs like 66 420C66 CHAOS DVR +LOGIN? which are continuously running and have 3:43:20 cpu time on them. They are trying to log in when already logged in. The login fails ("CAN'T MODIFY JOB"), the uname is incremented, and the login is retried. From GJC at MIT-MC Tue Mar 10 00:00:00 1981 From: GJC at MIT-MC (GJC at MIT-MC) Date: 10 Mar 1981 00:00 Subject: last bug note about jobs with unusally long running times. Message-ID: gosh, I didn't think about the fact that MC has been up for ten days. From GJC at MIT-MC Tue Mar 10 00:00:00 1981 From: GJC at MIT-MC (GJC at MIT-MC) Date: 10 Mar 1981 00:00 Subject: No subject Message-ID: On MC now we are getting jobs like 66 420C66 CHAOS DVR +LOGIN? which are continuously running and have 3:43:20 cpu time on them. From KLOTZ Sat Mar 7 00:00:00 1981 From: KLOTZ (Leigh L. Klotz) Date: 7 MAR 1981, 00:00 Subject: No subject Message-ID: I got a non-rec data err on .teco.;tecord > and just then got one on .tape5;tape 2626. I had gotten one on tecord a week ago but not one since. Should I get tecord off backup tape? Leigh. From ALAN at MIT-MC Fri Mar 6 00:00:00 1981 From: ALAN at MIT-MC (ALAN at MIT-MC) Date: 06 Mar 1981 00:00 Subject: No subject Message-ID: I wonder how come TYONRM+2 got decremented or else got bit 35 turned off? From KLOTZ Wed Mar 4 00:00:00 1981 From: KLOTZ (Leigh L. Klotz) Date: 4 MAR 1981, 00:00 Subject: No subject Message-ID: For at least the past couple of weeks I've been getting random beeps. (Usually in emacs, but probably because I've spent most of my time there; it happened last night in maclisp.) They seem to be cli interrupts, as when I ^Z out of the job it happens again. But, I have no sends and :ddtsym cliunm is 0. (Should I be looking at a similar location in emacs?) It flashes once. I have ..belcnt/1, if that matters. Leigh. From EDatMIT-AI Mon Mar 2 00:00:00 1981 From: EDatMIT-AI (Ed Schwalenberg) Date: 2 March 1981, 00:00 Subject: Blast from the past Message-ID: Many and many a year ago, in a kingdom by the sea, I complained of this, and it was said, "If you don't like it, you fix it." So I fixed the archive device handler to return PNM if that was the problem. Unfortunately, the source to which I did this was not in sync with the working binary, and my "fix" broke other things. The archive device has only recently recovered from this long history of lossage. This time, however, I am going to leave it alone. From PGS Sun Mar 1 00:00:00 1981 From: PGS (Patrick G. Sobalvarro) Date: 1 MAR 1981, 00:00 Subject: No subject Message-ID: When the pack that an archive resides on is not mounted, and one attempts to list the archive, the losing error message, "DSK:AR1;.FILE. (DIR) - NON-EXISTENT DIRECTORY" is printed, and one's working directory is changed to AR1;. Something more reasonable, like "PACK NOT MOUNTED" might be more of a win.