From MOON Mon Jun 30 00:00:00 1980 From: MOON (David A. Moon) Date: 30 JUN 1980, 00:00 Subject:  is S L O W Message-ID: SJK at MIT-MC 06/30/80 00:02:03 Re:  is S L O W Subject:  is S L O W To: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC Is there any reason for this command to be slower? I've noticed it sorta pauses after each line. This is a fairly recent occurrance, maybe's been this way for two weeks. Anyone else notice this? -sjk This is because the buffer for printing directories and files in DDT is preposterously small (80 characters), and an interaction with the job implementing the DIR: device is required for each buffer-load. RWK has promised to fix this but evidently hasn't had time. From SJK at MIT-MC Mon Jun 30 00:00:00 1980 From: SJK at MIT-MC (SJK at MIT-MC) Date: 30 Jun 1980 00:00 Subject:  is S L O W Message-ID: Is there any reason for this command to be slower? I've noticed it sorta pauses after each line. This is a fairly recent occurrance, maybe's been this way for two weeks. Anyone else notice this? -sjk From MOON at MIT-MC Sat Jun 28 00:00:00 1980 From: MOON at MIT-MC (MOON at MIT-MC) Date: 28 Jun 1980 00:00 Subject: KMP's halt at TTYI15+15 from :REATTA Message-ID: I have fixed this in the source (TS3TTY). RMS, could you check the change and make sure I didn't break anything? From KMP at MIT-MC Fri Jun 27 00:00:00 1980 From: KMP at MIT-MC (KMP at MIT-MC) Date: 27 Jun 1980 00:00 Subject: No subject Message-ID: I did :REATTA JIM /K from a terminal near Jim's to demo how REATTA works (the terminal I did it from was t22 on MC). I then typed  to see where we were in the reatta'd process, but nothing happened. The system had halted at TTYI15+15 (a JUMPL B,[JRST 4,.] which has a comment saying that the interrupting character belongs to no user). I suspect that REATTA and/or ITS needs to do something about this potential timing error. Control-Z is always the first char I type after a REATTA to get myself back to DDT where I can figure out what's going on ... Maybe it can just turn off interrupts -- will that help? -- or maybe ITS needs to be more tolerant of this type of error and just dismiss the interrupt and pretend it didn't see the character. In any case, the bug makes me nervous since I suggest REATTA to many of our users who get themselves dropped by the network... This was the nature of the system crash today at 12:15pm -kmp From CSTACY Wed Jun 25 00:00:00 1980 From: CSTACY (Christopher C. Stacy) Date: 25 Jun 1980, 00:00 Subject: BUG => its Message-ID: <[MIT-DMS].152408> On DMS with three users (one of them my crtsty) I got a FS from :sstatus of 102%. Is this broken? Chris ---- From KMP Fri Jun 27 00:00:00 1980 From: KMP (Kent M. Pitman) Date: 27 JUN 1980, 00:00 Subject: No subject Message-ID: I was running Babyl a little while ago and managed to get it into a wierd state where it started sending all sorts of garbage to the terminal that I just couldn't stop. I did  to get out of it -- that worked. My terminal went back to normal. When I P'd the job, the stream of garbage continued. After that, it was hard to tell if things were listening to me. I tried 'ing out of it again, but that didn't give me any re-assuring signs that my console was listening to me -- just streams of random characters displaying mostly. After a while, I noticed that the output I was seeing when I typed something was mixed part of the stuff I should be seeing and part of the stuff I'd seen a while back -- eg, "QUIQU^ IXX ?" or something when I typed  ... Presumably the XX? was from the 's earlier. I had JONL gun me and after 'ing the console again and typing some 's I finally saw my console free message and the wakeup message from the . RWK told me to do .0G and :PDUMP the Emacs job -- it's written to MC:KMP;TS SCREW if someone wants to look at if -- Since it's running Babyl and I don't want my mail clobbered, be extremely careful not to "Q" out of it if you do want to look at it ... If it's not worth looking at, that's fine by me. Send me a message saying so, so that I can delete the dump file. -kmp From RMS Fri Jun 27 00:00:00 1980 From: RMS (Richard M. Stallman) Date: 27 JUN 1980, 00:00 Subject: No subject Message-ID: I have :TCTYP QUERY in my init file, but very often I find that the bit has been cleared. Someone just linked to me and it didn't query. The bit was off. He said he didnt patch it off, so it must be a bug. From DLW Thu Jun 26 00:00:00 1980 From: DLW (Daniel L. Weinreb) Date: 26 JUN 1980, 00:00 Subject: No subject Message-ID: I just got :LUISERed by someone who was trying to create a file using :CREATE and getting confused. I hadn't known there even WAS a :CREATE, but there is such a program; it appears to be a simple TECO frob or something. Anyone know what this is?? From ZRM at MIT-MC Wed Jun 25 00:00:00 1980 From: ZRM at MIT-MC (ZRM at MIT-MC) Date: 25 Jun 1980 00:00 Subject: No subject Message-ID: Having just fingered mc it occurs to me that listing ctrstys as users is redundant and leads to more confusion than information. From EAKatMIT-MC Tue Jun 24 00:00:00 1980 From: EAKatMIT-MC (Earl A. Killian) Date: 24 June 1980, 00:00 Subject: No subject Message-ID: Date: 23 Jun 1980, 00:00 From: ZEMON at MIT-DMS (Landon M. Dyer) To: BUG-crtsty at MIT-DMS Re: BUG => crtsty I have a slight problem. I own a microcomputer system upon which I have simulated a superimage mode (SUPDUP?) terminal, i.e. a terminal which would (in theory) take the 'raw' output stream from ITS (escaped by 177s, as documented in INFO somewhere) and do nice (and fast) things without the aid of a front end preprocessor like CRTSTY. I have all of the escape sequences & so forth working (I have tested them out in local mode....), but to date my efforts to get ITS to beleive in my SUPDUP terminal have been fruitless, if not unspectacular -- ITS will either ignore me completely and continue to treat me as a printing terminal, or it will "blow up" and start sending me wierd and wonderful, if useless, control characters. 1) How do I get ITS to beleive in me? What bits must I twiddle in order to get the ITS buffer output codes to work for me? 2) If I can't get ITS to send me the buffer codes, how can I use CRTSTY's SOFT terminal emulator? (Having looked at the listing for the SOFT front end it seems that that is about what I have written to emulate -- but I can't get SOFT to work either.) It would be preferable to just set bits in DDT and not have to take up an extra job slot, of course. Please answer -- I am badly in need of some help here. You can send mail to either zemon at mit-ai or dyer at nbs-10. Thank you very much... From EAKatMIT-MC Tue Jun 24 00:00:00 1980 From: EAKatMIT-MC (Earl A. Killian) Date: 24 June 1980, 00:00 Subject: not getting software TTY codes Message-ID: You were using :TCTYP SOFT, and you weren't getting what looked like ITS internal codes? Maybe they were coming in their 200+ form instead of the 177 escape form? Could you tell us in octal what is sent when you type CR to DDT? From EB Tue Jun 24 00:00:00 1980 From: EB (Edward Barton) Date: 24 JUN 1980, 00:00 Subject: CLI device Message-ID: The system job deletes core link files which have not been referenced for two minutes. I do not believe that files which were opened as CLI: (perhaps as opposed to CLO:) should go away if the jobs to which interrupts were given still have those interrupts pending. The effect of the current practice is that a job which is ^Z'ed at the time it receives its CLI interrupt may later get that interrupt but not be able to open CLA:. Also, it would be nice if a channel open to CLO: could interrupt when input became available.... From CPR at MIT-MC Mon Jun 23 00:00:00 1980 From: CPR at MIT-MC (CPR at MIT-MC) Date: 23 Jun 1980 00:00 Subject: No subject Message-ID: I got a 'all network ports in use' message as the 10th net tty...seems small. From GNU at MIT-MC Thu Jun 19 00:00:00 1980 From: GNU at MIT-MC (GNU at MIT-MC) Date: 19 Jun 1980 00:00 Subject: No subject Message-ID: ITS seems to be flakier these days about when it types a colon (when in monitor mode). Often after running a program it will type *, ^W, or nothing, requiring you to hit CR to get your input interpreted as a command. What has happened? Can it be fixed to always provide a colon? In particular, :TCTYP *never* provides any prompt except ^W, and as I recall, never has. This ought get fixed. (Does anybody who works there use :monmode? I've heard it referred to as "crippled mode", but since I don't have an ITS manual handy ever, I can't remember the obscure ("incompatible") random control-strange-char-preceded-and-followed-by-other- strange-parameters "commands". From JPG at MIT-MC Thu Jun 19 00:00:00 1980 From: JPG at MIT-MC (JPG at MIT-MC) Date: 19 Jun 1980 00:00 Subject: No subject Message-ID: the command :tctyp padcr 0 padlf 0 padtab 1 width 228 seems to disconnect me from the system.It has happened twice. I don't see any way there could be a connection between the two. Getting disconnected unfortunately is also too easy to happen even without this scenario. Anyway, I am forwarding your mail to people who know more about these things. From JLK at MIT-MC Mon Jun 16 00:00:00 1980 From: JLK at MIT-MC (JLK at MIT-MC) Date: 16 Jun 1980 00:00 Subject: No subject Message-ID: Why are half of the login and emacs init files in the world on pack 13? I think this is a total loss. I imagine if someone is on a vacation or something, their whole directory gets put on pack 13, and they never notice it until pack 13 crashes. Can't this brain damaged dumping process be made more clever? The backlash from this is likely to be people writing programs for their logout file that sets the don't reap bit for all their files and copies them all to primary packs. I spent half the moring handling complaints from dozens of users who didn't understand why none of their normal activities worked (login, emacs, mail, etc.). I consider this to be a very serious lossage and hope steps can be taken to make sure this doesn't happen again. I suppose I can write a trival program that fixes all directories after every dump, but it is a loss that this should be necessary. From PDL Wed Jun 11 00:00:00 1980 From: PDL (P. David Lebling) Date: 11 Jun 1980, 00:00 Subject: BUG => its Message-ID: <[MIT-DMS].150758> Copying WJN;WJN READER to WJN;AR0:_WJNRE > causes a crash at USRUUO+5(?). This also happens (as an innocent experiment showed) in the newer ITS when you copy AI:COMMON;WJN READER to AI:COMMON;AR0:_WJNRE >. We didn't realize the bug was so virulent. Dave From FMRC at MIT-ML Mon Jun 9 00:00:00 1980 From: FMRC at MIT-ML (FMRC at MIT-ML) Date: 09 Jun 1980 00:00 Subject: No subject Message-ID: It is currently about 0240 EST and there is only one other user on. And it is sunday/mondaymorn at that. I just recieved a message from SYSTEM OVERSEER saying that I am not supposed to be on right now. This is I hope a bug? From ED Fri Jun 6 00:00:00 1980 From: ED (Ed Schwalenberg) Date: 6 JUN 1980, 00:00 Subject: Translations Message-ID: There are two seperate losses which are being confused here. There are a finite number of entries in the system translation table; if an attempt to create a translation (TRANAD) is done a DIRECTORY FULL error message is generated. This virtually never happens, and clearly did not happen in this case. If a translation gets chased more than 64 or so times, it is deemed to be losing and the error TOO MANY TRANSLATIONS is generated. I think from CSTACY's message he did  DSK:FOO;MUMBLE MUMBLE To: * which resulted in a translation from MUMBLE MUMBLE to itself. He then did :PRINT MUMBLE MUMBLE and got the correct error message. From ECC at MIT-AI Fri Jun 6 00:00:00 1980 From: ECC at MIT-AI (ECC at MIT-AI) Date: 06 Jun 1980 00:00 Subject: tip port 5 Message-ID: Apparently, ML thinks that MIT-TIP port 5 is room 508, which is occupied by Kent, Sollins, and Ciccarelli. Offhand, I don't know about the 508 -- that is probably still correct, but I'm not in that office (or group, for that matter) anymore. From CBF at MIT-MC Fri Jun 6 00:00:00 1980 From: CBF at MIT-MC (CBF at MIT-MC) Date: 06 Jun 1980 00:00 Subject: Translations Message-ID: No bug, the total number of translations is a fixed constant on each ITS. IN general you should not make a translation unless there is no other good way to accomplish the objective and it is highly anti-social to have more than a few at any given time. From RMS Fri Jun 6 00:00:00 1980 From: RMS (Richard M. Stallman) Date: 6 JUN 1980, 00:00 Subject: No subject Message-ID: Closing another job's disk channel inside IODCL, with U and P set up for that other job, got to QDEL11 which went to UUOTRO. UUOTRO assumes that U and P are set up to the job which is running. So it called ALOGOUT again which decided, since U was a which had an inferior and 40 had .LOGOUT 1, to act like a .BREAK. Giving the interrupt eventually crashed because it checked for LSWPR being nonzero. I think that UUOTRO assumes that LSWPR is zero. Probably UUOTRO should be changed to make these things true or bomb immediately if they are not. I can't say anything about the code in QDEL11 because that code is not in the DISK listing at all, but it is probably a loss for any close routine to go to UUOTRO. From CSTACY at MIT-MC Thu Jun 5 00:00:00 1980 From: CSTACY at MIT-MC (CSTACY at MIT-MC) Date: 05 Jun 1980 00:00 Subject: No subject Message-ID: There are too many translations active on MC. Can this happen? (If I interpreted the error messg correctly...) I tried to do a $^T which failed, also a :link command failed with "TRANS: - TOO MANY TRANSLATIONS". How dynamic is this situation, or is this really a bug? Thanks, Chris From GJC at MIT-MC Mon Jun 2 00:00:00 1980 From: GJC at MIT-MC (GJC at MIT-MC) Date: 02 Jun 1980 00:00 Subject: No subject Message-ID: I saw two detached HACTRO's today on MC, and they took an awful long time to die after being gunned with peek. The status stayed at *MULTIX for a couple minutes (near as I could tell), and then they went away... -gjc From JONL at MIT-MC Mon Jun 2 00:00:00 1980 From: JONL at MIT-MC (JONL at MIT-MC) Date: 02 Jun 1980 00:00 Subject: No subject Message-ID: :MOVE seems to lose the "don't-reap-me" bit, and also resets the reference date to time of :MOVEing. There ought to be a way to shuffle stuff to secondary or tertiary packs without destroying this valuable information.