From DLW at MIT-MC Tue Jul 29 00:00:00 1980 From: DLW at MIT-MC (DLW at MIT-MC) Date: 29 Jul 1980 00:00 Subject: No subject Message-ID: In the version of ITS on MC, if you come in from SAIL on a TELNET connection, set +%TPMTA, and send characters with the eighth bit on, ITS does not see them at all. From REM at MIT-MC Sun Jul 20 00:00:00 1980 From: REM at MIT-MC (REM at MIT-MC) Date: 20 Jul 1980 00:00 Subject: No subject Message-ID: Is there any really good reason for discarding a CLI file being passed from one job to another just because that recipient job hasn't processed it in a minute or two? The recipient job was enabled for CLI interrup, but had been ^Z'd, thus couldn't process it immediately. The fact that it was enabled for interrupt means it wasn't just a random message to job that didn't want it. From MOON at MIT-MC Thu Jul 10 00:00:00 1980 From: MOON at MIT-MC (MOON at MIT-MC) Date: 10 Jul 1980 00:00 Subject: FILLEN on non-disk devices Message-ID: The bug is not in ITS, which does what it's documented to, but in the special job device which is used if you read the directory of a non-directory device. Apparently after opening it simply SIOTs to the BOJ: device, assuming that the first thing you will do after opening is an IOT, but if you do something else novel effects occur. From ED Thu Jul 10 00:00:00 1980 From: ED (Ed Schwalenberg) Date: 10 JUL 1980, 00:00 Subject: FILLEN on non-disk devices Message-ID: Doesn't fail, it just doesn't work. This causes e.g. AIPTP from MC to cause MLSLV on AI to die horribly, believing that SIXBIT/.FILE./ is a byte size. The code in MLSLV is reasonable given system calls that work as they should. The documentation DOES say that it doesn't work on non-disk devices, but claims that it returns error 34 in that case. From MOON at MIT-MC Sun Jul 6 00:00:00 1980 From: MOON at MIT-MC (MOON at MIT-MC) Date: 06 Jul 1980 00:00 Subject: Fair Share and the GAME program Message-ID: The ITS bug that caused fair share to be very low on occasion when the system was lightly loaded has been fixed. (In response to your message of 1 July 20:51) From EAKatMIT-MC Tue Jul 1 00:00:00 1980 From: EAKatMIT-MC (Earl A. Killian) Date: 1 July 1980, 00:00 Subject: ITS H19 support Message-ID: Try :TCTYP VT52 +%TOLID which at least gets you line insert/delete. There is no excuse for :TCTYP HEATH or :TCTYP H19 not existing to do at least this. From MRC Tue Jul 1 00:00:00 1980 From: MRC (Mark Crispin) Date: 1 JUL 1980, 00:00 Subject: ITS H19 support Message-ID: Is there any chance that H19's will be added to ITS soon? I'll use :TCTYP VT52 for now since CRTSTY is too expensive, but these things do seem to be becoming more popular. From EJSatMIT-MC Tue Jul 1 00:00:00 1980 From: EJSatMIT-MC (Eric J. Swenson) Date: 1 July 1980, 00:00 Subject: Fair Share and the GAME program Message-ID: I'm getting tired of people telling me that the GAME program bites the royal... because of the system load restrictions (determined from the system Fair Share and the number of users). Here is a message from Leo Harten (LPH at MC). Is it possible that ITS is not calculating the fair share correctly or is it just not a reliable indication of system load even when averaged over time? ----- [Mail from LPH] ----: the fair share determiner is not useful to trek players. when no one is running a job, fair share is 5%. if i start a macsyma running for i:1 thru 1.e6 do (j:i); and then get 60% fair share, then i can play trek!!! to have to start a running job in order to play games at 3 am is ludicrous! there are 11 lusers right now, and since no one is actively running anything, the fair share is artificially low. is this a feature of the new dragon? (as in star trek: the motion picture, that's not a bug, that's a vejur!) ----- [End of Mail from LPH] ---- So is there anything wrong with Fair Share? Is it an accurate measure of anything or can it be used in place of a one-hundred-sided die? -- Eric