Copyright (c) 1999 Massachusetts Institute of Technology This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ------------------------------ Date: Friday, 29 April 1983, 00:33-EDT From: Christopher C. Stacy To: David C. Plummer Cc: BUG-ITS at MIT-MC, ian at MIT-OZ In-reply-to: The message of 28 Apr 83 16:59-EDT from David C. Plummer Date: 28 April 1983 16:59 EDT From: David C. Plummer It's cheating. Terminal-0-F @Rutgers, c-Break, chaos:conn-list shows that the contact name the LispM is using is NAME @rutgers. Aha. Except that SYSTEM-T RUTGERS connects to MC and then gets me to RUTGERS ok. It also works for SCORE.  Date: 28 Apr 1983 17:43 EDT (Thu) From: Ian Macky To: David C. Plummer Cc: BUG-ITS@MIT-MC Subject: ARPA server In-reply-to: Msg of 28 Apr 1983 17:13 EDT from David C. Plummer Ah, OK, thanks much -- All it needed was for me to send a NL after the connection was established.  Date: 28 April 1983 17:13 EDT From: David C. Plummer Subject: ARPA server To: Ian @ MIT-OZ cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC I figured it out. You aren't following the protocol of the TCP NAME server. Connecting isn't enough. After you connect, you must then give the JCL. Try :chtn mcTCP rutgers 117 (the caps are important). When it opens the connection, type return.  Date: 28 April 1983 16:59 EDT From: David C. Plummer To: CSTACY @ MIT-MC cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC, ian @ MIT-OZ Date: 27 April 1983 21:41 EDT From: Christopher C. Stacy If I go to a LispM and finger RUTGERS, it connects to MC and I get a Finger listing from RUTGERS. I can also TELNET from a LispM to SCORE. So, I think the ARPA server works. It's cheating. Terminal-0-F @Rutgers, c-Break, chaos:conn-list shows that the contact name the LispM is using is NAME @rutgers.  Date: 27 April 1983 21:41 EDT From: Christopher C. Stacy To: DCP @ MIT-MC, ian @ MIT-OZ cc: BUG-ITS @ MIT-MC If I go to a LispM and finger RUTGERS, it connects to MC and I get a Finger listing from RUTGERS. I can also TELNET from a LispM to SCORE. So, I think the ARPA server works.  Date: 27 Apr 1983 20:22 EDT (Wed) From: Ian Macky To: David C. Plummer Cc: BUG-ITS@MIT-MC Subject: ARPA server In-reply-to: Msg of 11 Apr 1983 06:39 EST from David C. Plummer The ARPA server still doesn't work. If I go to MC and do F @RUTGERS then I get a Rutgers Finger display. If, from OZ, I connect to the ARPA server with "RUTGERS 117" then I never get the stuff. What it was doing a few seconds ago was just hanging... I waited a minute or so (on several occasions) but never got any response. Usually there's a "Failed to TCP connect" message, and sometimes a "Timed-out" and other similar things, but it has never once worked.  Date: Wednesday, 27 April 1983, 08:24-EDT From: Christopher Stacy Subject: SYS: To: BUG-ITS@MIT-MC Cc: ALAN@MIT-MC, DEVON@MIT-MC In-reply-to: The message of 27 Apr 83 05:24-EDT from Alan Bawden I have an idea for implementing Twenex-like logical names on ITS. The main feature which I want from logical names is search paths, so that COM: and SYS: and others could be made to do the right thing. The jobdev mechanism could be used as-is for this feature, but I dont want the overhead of a jobdev and the slowness of doing the IOTs multiple times. My idea for getting around this is a to extend JOBRET so that there is a way for the BDH to tell the system: "I am going away now. Disconnect the user from me and retry the OPEN call using these args I am giving you." Once this kind of JOBRET is done, the BDH's BOJ: channel is closed and he should logout or reuse. There will probably want to be some restrictions (like maybe: the BDH must not have .IOTed anything yet) based on internal implementation details. With this feature, a user could open the FOO: device, which would start a BDH. The BDH would do a JOBCAL and find out the OPEN parameters. Then the BDH does its thing to figure out where the user really wants to be OPEN to, and does a JOBRET to pass control back to ITS for retrying the OPEN call. I am willing to implement this in ITS, and maybe put some kind of interface on it for users (so they dont have to write their own BDH's whenever they want to make a logical name). Thoughts?  Date: 27 April 1983 11:04 EDT From: David C. Plummer Subject: SYS: To: CStacy @ MIT-OZ cc: BUG-ITS @ MIT-MC, ALAN @ MIT-MC, DEVON @ MIT-MC I am willing to implement this in ITS, and maybe put some kind of interface on it for users (so they dont have to write their own BDH's whenever they want to make a logical name). Thoughts? As I recall, you threatened to do this for the sake of things like HS: as well. Anyway, one possibility is to have users translate FOO:*;* * to LOGICL:*;* *. The LOGICL device could open DSK:hsname;xuname LOGICL to find an ascii file containing lines of LOGICAL-DEVICE &REST PATHS, where PATHS can contain *s for when to default to the field from the open call. You would have to be careful to make sure loops don't happen (e.g., foo: -> bar: -> foo: ...). Perhaps you can use LINK-DEPTH-EXCEEDED... To appease people like me who already have 6 translations, you may have to up the translation table size if you decide to use this method.  Date: Wednesday, 27 April 1983, 08:41-EDT From: Christopher Stacy Subject: SYS: To: BUG-ITS at MC Cc: ALAN at MC, DEVON at MC In-reply-to: The message of 27 Apr 83 05:24-EDT from Alan Bawden I have an idea for implementing Twenex-like logical names on ITS. The main feature which I want from logical names is search paths, so that COM: and SYS: and others could be made to do the right thing. The jobdev mechanism could be used as-is for this feature, but I dont want the overhead of a jobdev and the slowness of doing the IOTs multiple times. My idea for getting around this is a to extend JOBRET so that there is a way for the BDH to tell the system: "I am going away now. Disconnect the user from me and retry the OPEN call using these args I am giving you." Once this kind of JOBRET is done, the BDH's BOJ: channel is closed and he should logout or reuse. There will probably want to be some restrictions (like maybe: the BDH must not have .IOTed anything yet) based on internal implementation details. With this feature, a user could open the FOO: device, which would start a BDH. The BDH would do a JOBCAL and find out the OPEN parameters. Then the BDH does its thing to figure out where the user really wants to be OPEN to, and does a JOBRET to pass control back to ITS for retrying the OPEN call. I am willing to implement this in ITS, and maybe put some kind of interface on it for users (so they dont have to write their own BDH's whenever they want to make a logical name). Thoughts?  Date: 27 April 1983 05:24 EDT From: Alan Bawden Subject: SYS: To: DEVON @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 27 Apr 1983 02:36 EDT from Devon S. McCullough Date: 27 April 1983 02:36 EDT From: Devon S. McCullough Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3; prray tell? I thought about this some more, and I talked it over with Moon, and it appears that the answer is: For no good reason. There are some red herring issues like: What should happen if you try to read the binary directory listing from SYS:.FILE. (DIR)? And: What exactly should happen if you open SYS:FOO > for writing? But it appears that a perfectly good answer to most of those objections is: Well what makes you think that the SYS: device should behave at all like the DSK: device anyway? (Why should it have a binary directory, and why should you be able to write to it.) There would be the compatibility problem with current programs that use SYS: as a synonym for DSK:SYS;, but they could all be trivially fixed. Think of al the places that implement the SYS;, SYS1;, ... search themselves currently... (Now, can somebody think of something clever for the COM: device to do?)  Date: 27 April 1983 02:36 EDT From: Devon S. McCullough To: BUG-ITS @ MIT-MC Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3; prray tell?  Date: 27 April 1983 01:20 EDT From: Alan Bawden Subject: CRASH;CRASH QSKCH To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC In-reply-to: Msg of 26 Apr 1983 09:33 EDT from Ken Harrenstien Date: 26 April 1983 09:33 EDT From: Ken Harrenstien Note, by the way, that this has been with us for a long time; there are simply too many processes trying to run, and the present design of ITS imposes some limits which cannot be avoided without doing clever things like mapping buffers in and out of exec address space. Both CHAOS and TCP code are also liable to wild runaway use of buffers if the net hardware burps. Has anyone thought seriously about mapping buffers? (I appreciate that I have just said a mouthful.)  Date: 26 April 1983 13:05 EDT From: Richard Mark Soley Subject: CRASH;QSKCH To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC, TY @ MIT-MC In-reply-to: Msg of 26 Apr 1983 05:56 EDT from Christopher C. Stacy Date: 26 April 1983 05:56 EDT From: Christopher C. Stacy To: TY, SOLEY cc: BUG-ITS, JPG Re: CRASH;QSKCH Did ITS crash, or did you stop it? All that is on the console is "Warn KLDCP" --that is, ITS did not print any crash message and it looked like it was just halted in its tracks. In particular, I dont see the PC or anything printed anywhere. ITS didn't crash, we stopped it. No-one was getting any response at all. -- Richard  Date: 26 April 1983 09:33 EDT From: Ken Harrenstien Subject: CRASH;CRASH QSKCH To: JPG @ MIT-MC cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC Looking at this crash with PEEK's autopsy mode reveals that sure enough the system was out of low memory, because there were tons of disk channels open. Note, by the way, that this has been with us for a long time; there are simply too many processes trying to run, and the present design of ITS imposes some limits which cannot be avoided without doing clever things like mapping buffers in and out of exec address space. Both CHAOS and TCP code are also liable to wild runaway use of buffers if the net hardware burps. What is interesting is that one TEX job had 9 disk channels open, 7 of them to the same file! There was another TEX running too, tho not as hoggish. And there were several ATSIGN CHAOS jobs scattered around; these invariably seem to litter up the system whenever it gets wedged (cause or effect?)  Date: 26 April 1983 07:01 EDT From: Christopher C. Stacy Subject: Translations To: ALAN @ MIT-MC cc: BUG-DDT @ MIT-MC, PGW @ MIT-XX, BUG-its @ MIT-ML In-reply-to: Msg of 23 Apr 1983 16:23 EST from Alan Bawden DDT now uses an unlikely SNAME when it creates inferiors, to help prevent naive users from translating themselves into problems.  Date: 26 April 1983 05:56 EDT From: Christopher C. Stacy Subject: CRASH;QSKCH To: TY @ MIT-MC, SOLEY @ MIT-MC cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC Did ITS crash, or did you stop it? All that is on the console is "Warn KLDCP" --that is, ITS did not print any crash message and it looked like it was just halted in its tracks. In particular, I dont see the PC or anything printed anywhere. The messages it was printing were to tell you that the load on the system was too high (in the sense that there were no disk channels). That is why the system no doubt looked wedged to users. Btw, I fixed ITS so that it will only print those warning messages every thirty seconds, so it wil not overflow the console buffer (which is what the SYS MSGS LOST means. Maybe it should say SYS MSGS LOTS instead...)  Date: 26 April 1983 05:17 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Now ITS only does running out of resource checks if it has not done one in the last thirty seconds. This is to avoid deluging the system console with messages like "Warning: Inadequate space in low core LMEMFR/2".  Date: Tuesday, 26 April 1983, 00:37-EDT From: Christopher C. Stacy Subject: FileComputer To: PSZ at MIT-ML, HDT at MIT-OZ Cc: BUG-ITS at MIT-ML In-reply-to: The message of 24 Apr 83 14:11-EDT from Peter Szolovits There are two different, incompatible file systems on CADR-27. If you want to use what I believe is called the "FS" filesystem, you need to use CFTP. If you use the "FC" filesystem (written by RMS) you can use either CFTP or just the FC: device. I just typed :LISTF FC:CSTACY; on MC, and it listed my directory for me. What do you think is wrong? Cheers, Chris  Date: 25 April 1983 18:18 EDT From: Jeffrey P. Golden To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC Please check out CRASH;CRASH QSKCH. What happened is the system console began printing out pages and pages of "Warning: No free qsk channels. n SYS MSGS LOST" and then it crashed in some way, hence the CRASH dump. (I was not here at the time, I am just transmitting the contents of the log book to you so you can check this out.)  Date: 25 April 1983 04:13 EDT From: David C. Plummer Subject: ASSLIS is such a kludge! To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-LISP @ MIT-MC Date: 24 April 1983 18:31 EST From: Alan Bawden File deletion is supposed to work on the core-link, and I distinctly remember that in the (recent) past it HAS worked (DCP might remember otherwise?). I don't remember if it is supposed to or not. If anyone wants a few cheap laughs (and can read Midas), they should take a look at MC:L;ASSLIS >. It's certainly the kludgiest program I've seen in a long time. I thought I could read Midas, but I have a hard time reading that thing.  Date: 24 April 1983 18:31 EST From: Alan Bawden Subject: ASSLIS is such a kludge! To: BUG-ITS @ MIT-MC cc: BUG-LISP @ MIT-MC CLU:.FILE. (DIR) currently lists: LISP MIDAS BARQIO CLOSED-> HACTRN FOO MIDAS BARQIO CLOSED-> HACTRN L MIDAS BARQIO CLOSED-> HACTRN L MIDAS FOOQIO CLOSED-> HACTRN The reason it says " HACTRN" is that it used to say "ALAN HACTRN" until I logged out that job. Before that all four entries were in CLOSED->CLOSED state and I tried to delete tham using  in DDT. Instead of deleting them it seems to have decided I wanted to USE them. I checked, and DDT did not still have any CLx channels. I guess these will stay here until MC crashes next. File deletion is supposed to work on the core-link, and I distinctly remember that in the (recent) past it HAS worked (DCP might remember otherwise?). If anyone wants a few cheap laughs (and can read Midas), they should take a look at MC:L;ASSLIS >. It's certainly the kludgiest program I've seen in a long time.  Date: 24 April 1983 13:11 EST From: Peter Szolovits Subject: FileComputer To: HDT @ MIT-OZ cc: BUG-ITS @ MIT-ML In-reply-to: Msg of 24 Apr 1983 01:49 EST (Sun) from Howard D. Trachtman Date: 24 Apr 1983 01:49 EST (Sun) From: Howard D. Trachtman To: PSZ at MIT-OZ Re: FileComputer I'm not sure what happened to the fc device as accesable from ITS. I do know that cftp will work. Try :cftp fc login psz dir fc:psz; and you should see your files. The fc: is needed as the filecomputer supports two different file systems. Indeed you are right. Therefore the FC: device in ITS is broken. Could someone fix it?  Date: Sunday, 24 April 1983, 01:51-EST From: David A. Moon Subject: Running out of low core To: Christopher C. Stacy Cc: BUG-ITS at MIT-MC In-reply-to: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy Date: 19 April 1983 21:17 EST From: Christopher C. Stacy The check for running out of low core I put in goes off quite alot, and frequently overflows the system console message buffer. Usually when this goes off, it means that the system appears wedged to users. Do you suppose there could be a bug in the system with someone not returning some flavor of buffer space at the right time? More likely there is just isn't enough address space for all the disk buffers, disk directories, chaos buffers, tcp buffers, core link buffers, and everything else. Isn't it the case that if you wait a while and kill all jobs with open files the space always comes back eventually?  Date: 23 April 1983 16:23 EST From: Alan Bawden Subject: Translations To: PGW @ MIT-XX cc: BUG-DDT @ MIT-MC, BUG-its @ MIT-ML In-reply-to: Msg of 23 Apr 1983 1328-EST from Paul G. Weiss Date: 23 Apr 1983 1328-EST From: Paul G. Weiss To: bug-its at MIT-ML Re: Translations ... What follows is a wallpaper file so you can better understand what I mean: ------------------------------------------------ * arch;* *,ar1:inna;* * ... *:find arch; INFERIOR-CREATION FAILED? u:BYE  INFERIOR-CREATION FAILED?:INPUSH 1u This is because translating *:ARCH;* * => AR1:INNA;* * will cause translations to happen for devices other than DSK: (like USR:, which is why DDT can't create any inferior jobs). You should create the following two translations instead: DSK:ARCH;* * => AR1:INNA;* * ML:ARCH;* * => AR1:INNA;* * ;or whatever ITS you are using. (I have CC'd this to BUG-DDT beacuse I presume DDT could be more robust than this by supplying some unlikely-to-be-translated directory name whenever it tries to use the USR: device. I checked, and DDT currently doesn't supply an SNAME when opening USR:, which just begs to shaft people like this.)  Date: 23 Apr 1983 1328-EST From: Paul G. Weiss Subject: Translations To: bug-its@MIT-ML In order to get around the problem of TEX not accepting device names for input files, I have been using file translations. In particular, I do  arch;* *,ar1:inna;* * and use the "pseudo-directory" ARCH; to refer to stuff inside the archive. This works fine for TEX. The problem is that it causes other things to go awry, namely, when I try to do :FIND ARCH; it gives me a strange error. It also keeps me from logging out with u since it tries and fails to run :BYE. I must log out with 1u (or remove the translation). What follows is a wallpaper file so you can better understand what I mean: ------------------------------------------------ * arch;* *,ar1:inna;* * *archML INNA AR1 6.045J Free files = 175, Wasted Words = 0 0 H1 1 1 02/02/83 16:55:58 0 H10 1 3 03/10/83 18:23:21 0 H12 2 1 03/08/83 16:42:41 0 H13 6 1 03/09/83 10:16:47 0 H14 4 1 03/10/83 19:38:01 0 H15 6 1 03/10/83 22:32:47 0 H16 2 1 03/17/83 12:46:21 0 H17 2 1 03/29/83 15:33:57 0 H18 13 1 04/04/83 10:29:40 0 H19 1 4 04/07/83 22:28:43 0 H2 10 1 02/02/83 16:56:00 0 H20 1 2 04/07/83 22:29:43 0 H21 5 2 04/08/83 10:37:00 0 H23 2 1 04/13/83 16:02:52 0 H24 3 1 04/14/83 15:50:58 0 H25 2 1 04/20/83 17:13:16 0 H26 2 1 04/23/83 12:38:10 0 H26A 1 1 04/20/83 17:02:45 0 H26B 1 2 04/21/83 16:43:30 0 H26C 1 1 04/21/83 16:26:47 0 H26D 1 2 04/21/83 16:27:02 0 H26E 1 3 04/21/83 16:27:23 0 H26F 1 3 04/21/83 16:58:04 0 H3 23 1 02/07/83 16:43:30 0 H4 5 1 02/07/83 18:07:10 0 H6 1 1 02/14/83 19:10:38 0 H7 1 2 03/10/83 18:22:44 0 H8 11 1 02/24/83 15:27:48 0 H9 1 2 03/10/83 18:22:57 *:find arch; INFERIOR-CREATION FAILED? u:BYE  INFERIOR-CREATION FAILED?:INPUSH 1u ----------------------------------------- -------  Received: from SCRC-BLACKSTONE by SCRC-TENEX with CHAOS; Fri 22-Apr-83 11:27:24-EST Date: Friday, 22 April 1983, 11:23-EST From: Robert W. Kerns To: Christopher C. Stacy Cc: BUG-ITS@MIT-MC In-reply-to: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy Date: 19 April 1983 21:17 EST From: Christopher C. Stacy The check for running out of low core I put in goes off quite alot, and frequently overflows the system console message buffer. Usually when this goes off, it means that the system appears wedged to users. Do you suppose there could be a bug in the system with someone not returning some flavor of buffer space at the right time? I am of the opinion this problem has been with us for years.  Date: 22 April 1983 08:21 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC AI's processor is *fucked*. I turned it off. Maybe it will start randomly working again when I turn it back on, probably tomorrow or the next day.  Date: Friday, 22 April 1983, 07:58-EST From: Christopher Stacy Subject: MC is now the bug host. To: BUG-ITS at MC, BUG-MAIL at MC COMSAT now uses MC as the "bug host". I changed all the appropriate mailing lists, and installed the latest COMSAT on all four machines. I put the following in the MC:NAMES > file: ;;; MC is now the default BUG host. ;;; If a program exists on all machines, its BUG list normally ;;; only needs to be on MC. ;;; ;;; The reasons to define a BUG- name on some ITS besides MC include: ;;; o The program is not used on MC. ;;; o The program is mainly used on the other ITS, and most of ;;; the maintainers are there, and there is an entry ;;; on MC which forwards to the apporpriate machine. ;;; o In the absence of such reasons, define it on MC only. ;;; ;;; If a message is sent from some other ITS to a bug list which is not ;;; defined, it will be forwarded here. If the bug list is not defined ;;; here, the message will be sent instead to BUG-RANDOM-PROGRAM. Chris  Date: 20 April 1983 01:44 EST From: David C. Plummer Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems]] To: BUG-ITS @ MIT-MC Date: 15 April 1983 08:51 EST From: David C. Plummer Subject: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems] To: BUG-MAIL @ MIT-MC More info. I notice bug-mail is still on AI. Should this be changed? ------------------------------ Date: Thursday, 14 April 1983 21:15:03 EST From: Hank.Walker@CMU-CS-VLSI To: David C.Plummer Subject: Mailer problems Message-ID: <1983.4.15.2.10.27.Hank.Walker@CMU-CS-VLSI> It is probably not the UNIX mailer that is causing the problems. Mail messages from MIT go to CMU-CS-A. If it is TCP mail, it is shipped to the CMU-CS-PT VAX over the Ethernet, which translates the stuff into NCP, and sends it back to CMUA where it is delivered to me. That mail is then autoforwarded to me at CMU-CS-VLSI, where I live, even though INFO-COBOL has my CMU-CS-A mailing address. So the mail is delivered directly to CMU-CS-A, which is a KL10 running TOPS-10, rather than to a UNIX machine. I have no troubles receiving mail from any other site on the net to either CMU-CS-VLSI directly or to CMU-CS-VLSI, which communicates with the ARPAnet over an Ethernet gateway.  Date: 20 April 1983 01:44 EST From: David C. Plummer Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages]] To: BUG-ITS @ MIT-MC I originally sent this to BUG-MAIL@MC, which tried to go to AI, which is down. Perhaps somebody should find an AI backup tape, and get NAMES > (carefully) and get the more important BUG lists over to MC? There is a followup to this message coming soon... ------------------------------ Date: 14 April 1983 21:04 EST From: David C. Plummer Subject: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages] To: BUG-MAIL @ MIT-MC cc: Hank.Walker @ CMU-CS-A Forwarding complaint about the MC mailer. Following are some parts of the MC mail stats file. Other ditties of information: Other messages to CMU-CS-A get through successfully. The ones I saw happened to be small messages. Could this be the Unix braindeath that insists on completely delivering messages (instead of queuing) before it gives a completion reply? If so, the product of number of recipients by the length of the message is a roungh indication of the length of time it will take to deliver the message. If things are sufficiently slow, MC will correctly timeout. If this is true, I would have to say it is the Unix mail server that is broken. Date: Thursday, 14 April 1983 20:51:27 EST From: Hank.Walker@CMU-CS-VLSI To: David C.Plummer Subject: Infinite mail messages Message-ID: <1983.4.15.1.49.7.Hank.Walker@CMU-CS-VLSI> Would you please refrain from sending messages to INFO-COBOL until your mailer is fixed. I realize that it is not your fault, but quite frankly I am tired of receiving anywhere from 2 to 10 messages from anyone who sends mail originating at MIT, particularly mail that I've already seen before. Lean on your system manager, or charge him a quarter for every duplicated mail message that your system emits. 195935 ICP->CMU-CS-A(SMTP) 195939 XTO->Bob.Walker 195939 XTO->David.Nichols 195940 XTO->Dill 195940 XTO->Everhart 195940 XTO->gail.kaiser 195941 XTO->Hank.Walker 195941 XTO->Highnam 195942 XTO->Kazar 195942 XTO->Lamb 195943 XTO->Lehman 195943 XTO->muller@CMU-CS-GANDALF 195943 XTO->Provan 195944 XTO->Rudy.Nedved 195944 XTO->Sherman 195945 XTO->Shipman 195945 XTO->Shrager 195945 TEXT-> 200048 NO COMPLETION REPLY, R=10 200503 Queued: <[MIT-MC].635105> for CMU-CS-A 202005 Attempting to send messages queued to host CMU-CS-A 202005 ICP->CMU-CS-A(SMTP) 202008 QID=<[MIT-MC].635105> 202009 XTO->Bob.Walker 202009 XTO->David.Nichols 202010 XTO->Dill 202010 XTO->Everhart 202011 XTO->gail.kaiser 202011 XTO->Hank.Walker 202012 XTO->Highnam 202013 XTO->Kazar 202013 XTO->Lamb 202014 XTO->Lehman 202014 XTO->muller@CMU-CS-GANDALF 202015 XTO->Provan 202015 XTO->Rudy.Nedved 202016 XTO->Sherman 202016 XTO->Shipman 202017 XTO->Shrager 202017 TEXT-> 202120 NO COMPLETION REPLY, R=10  DCP@MIT-ML 04/19/83 22:13:15 To: (BUG its) at MIT-MC Has anybody changed the ATTY/DTTY code recently. It's probably pure coincidence, but MC has crashed on me several times just after sending me a message. Perhaps that's just a bad time to reference a disk?  Date: 19 April 1983 21:18 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC In XITS on MC, I patched out the LMEMFR check bug message for the moment.  Date: 19 April 1983 21:17 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC The check for running out of low core I put in goes off quite alot, and frequently overflows the system console message buffer. Usually when this goes off, it means that the system appears wedged to users. Do you suppose there could be a bug in the system with someone not returning some flavor of buffer space at the right time?  Date: 16 April 1983 04:36 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC ITS 1336 (XITS on MC) has additional warning messages for no free disk channels and no free job slots, to go with the no free low core warning. This junk seems to work.  Date: 16 April 1983 02:52 EST From: Christopher C. Stacy Subject: crash info To: BUG-ITS @ MIT-MC cc: ELLEN @ MIT-MC, JPG @ MIT-MC ITS now print warning when the amount of exec free space gets too low. This is to make it easier to walk over to the console and guess why the machine is wedged. Also put a bug message in the RH10 QINTE code where it has been dying all day, so it prints the disk number and offending controller bits. ITS 1334 installed on MC as XITS. If trouble, revert to NITS.  Date: 16 April 1983 01:17 EST From: Christopher C. Stacy Subject: hardware trouble To: BUG-ITS @ MIT-MC cc: ELLEN @ MIT-MC, JPG @ MIT-MC, GSB @ MIT-MC MC is having bad hardware trouble. ITS died several times today with disk hardware errors. This was at QINTE+45, where it checks some random ctrl bits (and the comment reads "worse than unsafe".) I think this was on unit #0. Just now the system came down because the -11 timed out waiting on the KL. Earlier today it came down becuase there were too many parity errors. Yesterday and the day before the -11 died, and had to be power cycled to get to work again.  Date: 13 April 1983 19:56 EST From: Ken Harrenstien Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets) To: Moon @ SCRC-TENEX cc: BUG-ITS @ MIT-MC, cmb @ SCRC-VIXEN, bug-lispm @ SCRC-TENEX The last ML ITS was assembled in middle of March, plenty of time for your NSUBNT change to take effect. I checked it out just now, and found that you modified the CHAOS source on SYSTEM; rather than SYSHAK; which is where all of the recent TCP/IP work has been happening. So I just now bumped up NSUBNT to 100. in the SYSHAK version (the only change you made) and someone will have to assemble a new ML ITS sometime. I guess now that things are obviously working, SYSHAK should be merged back into SYSTEM, so I will do that eventually.  Received: from SCRC-DALMATIAN by SCRC-TENEX with CHAOS; Wed 13-Apr-83 19:36:59-EST Date: Wednesday, 13 April 1983, 19:38-EST From: David A. Moon Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets) To: bug-its@MIT-MC Cc: cmb@SCRC-VIXEN, bug-lispm@SCRC-TENEX Note the date on the second enclosed message. I guess if this continues for another two months I'll find the time to do it myself. Date: Wednesday, 13 April 1983, 19:18-EST From: Clark M. Baker Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics To: BUG-LISPM at SCRC-TENEX I haven't been able to load files from ML onto a 3600 at Symbolics. However, ML is up. I can load files from ML onto a LM-2 at Symbolics. I can load files from ML onto MIT-PI. What is happening? Date: 21 February 1983 20:49 EST From: David A. Moon Subject: ML To: BUG-ITS @ MIT-MC I made NSUBNT (number of Chaosnet subnets) be a more reasonable size. ML (the only ITS machine that does its own Chaosnet routing) should get a reassembled ITS when convenient.  Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 13-Apr-83 19:34:50-EST Date: Wednesday, 13 April 1983, 19:36-EST From: David C. Plummer Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics To: cmb@SCRC-VIXEN, BUG-LISPM@SCRC-TENEX, BUG-ITS@MIT-MC In-reply-to: The message of 13 Apr 83 19:18-EST from Clark M. Baker Date: Wednesday, 13 April 1983, 19:18-EST From: Clark M. Baker I haven't been able to load files from ML onto a 3600 at Symbolics. However, ML is up. I can load files from ML onto a LM-2 at Symbolics. I can load files from ML onto MIT-PI. What is happening? I'll betchya ML's routing table isn't big enough. This has been CC'ed to BUG-ITS so somebody will be annoyed it is in they're mailbox and fix it (maybe me the next time I'm on MC).  Date: 11 April 1983 06:39 EST From: David C. Plummer Subject: ARPA server To: Ian @ MIT-OZ cc: BUG-ITS @ MIT-MC Date: 10 Apr 1983 1954-EST From: Ian Macky Is this ever going to work again? Would be nice to get Arpa FINGERs and such things from us Chaos-only ("we'll be up in THREE weeks, for sure") sites. ------- It should work. Try @DUP AI TCP. If you want the rest of the world to respond to FINGER, you will have to convince them to convert the NCP finger program to TCP, and also make sure whatever user program you are using contacts the correct socket number (I think the ARPA server wants it in octal, but i can't remember).  Date: 10 Apr 1983 1954-EST From: Ian Macky Subject: ARPA server To: Bug-ITS@MIT-MC Is this ever going to work again? Would be nice to get Arpa FINGERs and such things from us Chaos-only ("we'll be up in THREE weeks, for sure") sites. -------  Date: 7 April 1983 23:13 EST From: David C. Plummer To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 7 April 1983 17:26 EST From: Alan Bawden DIRHNG^F acts pretty graceless. Actually I can imagine that DIRHNG could reasonably display an informative directory. ...of what jobs have what directories open on the DIRHNG device. If you need a test case, the Versatec spooler always has one open on .glpr..  Date: 7 April 1983 17:26 EST From: Alan Bawden To: BUG-ITS @ MIT-MC DIRHNG^F acts pretty graceless. Actually I can imagine that DIRHNG could reasonably display an informative directory.  CSTACY@MIT-AI 04/05/83 11:58:45 To: (BUG ITS) at MIT-AI In ITS 1332, on MIT-AI: ITS crashed with the message PKT: Freeing packet still in use! Dumped to AI:CRASH;ITS FREPKT  Date: Tue, 5 Apr 1983 04:45 EST From: Leigh L. Klotz To: Edjik Cc: BUG-ITS@MIT-MC, BUG-MIDAS%OZ@MIT-MC, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC, KLH@MIT-MC Subject: Gross OZ lossage In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik KLH knows more about midas than most people, including you. Please keep your nitbrained views to yourself.  Date: 5 April 1983 01:43 EST From: Alan Bawden Subject: Gross OZ lossage To: MARTY @ MIT-OZ cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, DCP @ MIT-MC, KLH @ MIT-MC In-reply-to: Msg of 4 Apr 1983 23:19 EST (Mon) from Martin David Connor What is all this flaming horseshit in my mailbox?!?! Is there anyone who will argue that it was correct that there were TWO BUG-MIDAS mailing lists? No. Have we fixed that? Yes. (Thank you Ian.) Now is there somebody out there who can actually claim to be maintaining MIDAS to a greater extent than KLH? If so, then lets hear from them. If not, then everyone shut the hell up.  Date: 5 April 1983 00:57 EST From: David C. Plummer Subject: Gross 8 inch spikes in various people's heads To: MARTY @ MIT-OZ cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, KLH @ MIT-MC, BUG-MIDAS @ MIT-OZ And you, Mr. Conner, have as much to learn as I. Reactionary is not bullshit. Go read a history book someday and notice how progress is often achieved by reactionaries and their ideas. As for the local history of OZ, there were several people willing (and eager) to help in creating another ITS. Moon was willing to hack microcode and oversee changes needed to the system (e.g., for disk support) which I was willing to help with. As I recall, you were against the idea of ITS on OZ. Several other people attended the Wars of Futility where it was decided to run 20X. These people warned about all the features that 20X was lacking and many of the problems it had. But the wars were futile; the decision was out of our hands. So now our only recourse is to sit back and be little brats about the whole thing. "Nah, nah, I told you so..." I, for one, am proud to be one of these brats. For god's sake bring up a machine because it is the Right Thing, not because you hate another machine so much. Wrong. Both are often true. In fact, this is how TWENEX was developed. The history told to me was that BBN disliked Bots-10 so much they went off and wrote TENEX. DEC started seeing the light and bought it from them and made it work on a 20. Learn from the mistakes of another attempt, ... If TWENEX only could. Plummer, ... until you learn to work FOR A GOAL instead of AGAINST AN ALTERNATIVE you will be counterproductive to the causes you Support. Goal: Help build better Lisp Machines. I think I am working for this goal. Goal: help MIT when I have the time. I think I do a fair job here. Goal: convince people they lost completely when they decided to run TWENEX on OZ. Perhaps this is a subconsious goal. How actively I work toward it is not clear. I would hope to think I keep such discussions among (ITS) friends except when something blatant happens. If you didn't blindly defend the obvious problems, OZ would probably be a lot nicer. Penny, I already know I will regret sending this, because so many minds are already closed, but I had to try. Forgive me. Mine is closed just enough so that spikes cannot penetrate. I know who does the real TWENEX development at MIT, and they have often responded to the requests of others for (ITS-like) features. I hope they also understand the spirit in which I write these flames. Marty, you earned your second spike.  Date: 4 Apr 1983 23:19 EST (Mon) From: Martin David Connor To: David C. Plummer Cc: "NCP.EGK@SU-GSB-HOW"@SU-SCORE, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC, BUG-MIDAS@MIT-OZ, BUG-OZ@MIT-MC, KLH@MIT-MC Subject: Gross ITS lossage In-reply-to: Msg of 4 Apr 1983 21:40 EST from David C. Plummer Dogma, Plain and simple will be the downfall of ITS. It contains the ideas and talent to be great, but lacks the tolerance of other ideas that will see it wither and die. Most of what I have heard out of the ITS people is REACTIONARY bullshit. A system is just a system, and the thing I can't understand is why people that could design such beauty and generality can't quietly bide their time until they get the hardware and then create another system to show the world what is meant by winning. I would be proud to help bring up a new ITS, I would be proud to help bring up another 20, but not in a reationary spirit. But rather for the love of the hack. For god's sake bring up a machine because it is the Right Thing, not because you hate another machine so much. Learn from the mistakes of another attempt, but don't be driven by hate and arrogance. Plummer, you may be able to hack 98% of the world into the ground, but until you learn to work FOR A GOAL instead of AGAINST AND ALTERNATIVE you will be counterproductive to the causes you support. Penny, I already know I will regret sending this, because so many minds are already closed, but I had to try. Forgive me.  Date: 4 April 1983 21:40 EST From: David C. Plummer Subject: Re: Gross OZ lossage To: "NCP.EGK@SU-GSB-HOW" @ SU-SCORE cc: KLH @ MIT-MC, BUG-OZ @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-MIDAS @ MIT-OZ OZ is the successor to AI in hardware but not in spirit. I hope every program you use that was derived from ITS or is assembled in MIDAS breaks. I sometimes wish TOPS-20 were orificially shovable...  Received: from GSB-HOW with Pup; Mon 4 Apr 83 11:42:17-PST Date: Mon 4 Apr 83 11:41:35-PST From: Edjik Subject: Re: Gross OZ lossage To: KLH@MIT-MC cc: BUG-OZ@MIT-MC, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC, BUG-MIDAS%OZ@MIT-MC In-Reply-To: Your message of Mon 4 Apr 83 13:53:00-PST Gosh, I wonder just how many people on the 6 mailing lists that KLH shotgunned his msg to really give a ff about where the MIDAS sources live. Probably damn few. Oz is the successor to AI. Moving mailing lists and sources of system programs to it from AI seems natural to me. Since KLH got the msg Ian sent, he still is on the new offical list at oz, so why gripe? His talk of "sacrilege" conjures up images of the inquisition. Is KLH the defender of the ITS faith? Probably KLH's main gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20 site to look at the sources. If he uses it for TOPS-20 and 10X software, why does he need it on ITS? I hope the people in charge of the MIDAS mailing list and sources do the appropriate thing in response to KLH's flame, ie. ignore it. -- Edjik -------  Date: 4 Apr 1983 15:31 EST (Mon) From: Ian Macky To: Ken Harrenstien Cc: BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, bug-mail@MIT-OZ, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC Subject: Gross OZ lossage In-reply-to: Msg of 4 Apr 1983 13:53 EST from Ken Harrenstien Hmm. Since you obviously have strong feelings about this, and since that mailing list was screwed up by their being two parallel versions (one on OZ and one on AI), I have done as you asked (insisted) and merged the two and put the now official list on MC, with appropriate pointers all around.  Date: 4 April 1983 13:53 EST From: Ken Harrenstien Subject: Gross OZ lossage To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ. This implies that OZ has a BUG-MIDAS mailing list, and furthermore that this list is NOT the same as the official list on AI. This reminds me of the BUG-ATSIGN lossage. I consider myself one of those people who now and then maintain MIDAS. For the list to be moved without notice is reprehensible. For it to not be on an ITS is sacrilege. I must insist that either AI or MC be the official home of MIDAS sources and mailing lists. This should probably apply to all ITS developed software. Since I was the person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly use it for 10X/20X software, you can hardly say my viewpoint is wedged.  Date: 4 April 1983 10:26 EST From: Gail Zacharias Subject: [JMSK: forwarded] To: BUG-ITS @ MIT-MC Date: 04/03/83 10:19:53 From: JMSK SOMETHING VERRY WEird yust happened. I logged in as usual, the initfile ast me if I was on an H-19 to which I responded, as usual, in the affirmative, as usual. Now , if you've been following my exploits with the SUPERROM, you will recall that I keep my terminal in VT-100 mode, and let my INITfile change it to an H-19 when I log in (wait, it gets better). Well today, for the first time, I noticed my MODELINE said: IWASA VT100 VT100 and I was verrrry impressed ! I mean somehow ITS, with nothing in my Initfile to tell it, figured out that my terminal WAS A VT-100 (get it ? I WAS A VT-100 !!!!! ) THEN I GOT SUSPICIOUS, so I did a USERS, and discoverd: Yukizaku IWASA logged in thru a CRTSTY VT100 !!!!!!!!!!! The funny thing is, that's all my modeline shows !!! not MY job, even now, but IWASA VT100 !!!!!!!!!!!!!!!!!!!!!!!!! (in HANG state) weird, huh ?  Date: 3 Apr 1983 1502-EST From: P. David Lebling Subject: Re: ARC device directories To: CSTACY@MIT-MC, BUG-ITS@MIT-MC In-Reply-To: Your message of 19-Mar-83 2245-EST DIRED (not EMACS DIRED) and FIND depend on it. -------  Date: 3 April 1983 01:59 EST From: Steven A. Swernofsky To: BUG-ITS @ MIT-MC The annoying 15-second (?) pause in output has returned! -- Steve  Date: 1 April 1983 02:13 EST From: Christopher C. Stacy Subject: take paws off keys and wait To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, JSPEAR @ MIT-AI Date: 1 April 1983 01:04 EST From: Alan Bawden To: JSPEAR at MIT-AI cc: BUG-ITS at MIT-AI Re: take paws off keys and wait JSPEAR@MIT-AI 04/01/83 00:21:35 To: (BUG ITS) at MIT-AI :FINGER seems to respond with 'No users' when there are AI users, and :FINGER UNAME gives last logout time even if UNAME is currently on the system. I put up a new ITS where the main source version number had not changed, and forgot to dump out some of the random programs.  Date: 1 April 1983 01:04 EST From: Alan Bawden Subject: take paws off keys and wait To: JSPEAR @ MIT-AI cc: BUG-ITS @ MIT-AI In-reply-to: Msg of 04/01/83 00:21:35 from JSPEAR@MIT-AI JSPEAR@MIT-AI 04/01/83 00:21:35 To: (BUG ITS) at MIT-AI :FINGER seems to respond with 'No users' when there are AI users, and :FINGER UNAME gives last logout time even if UNAME is currently on the system. I dumped out a new finger on AI which seems to have fixed the problem. I never did find out just what was damaged about the old one..  JSPEAR@MIT-AI 04/01/83 00:21:35 To: (BUG ITS) at MIT-AI :FINGER seems to respond with 'No users' when there are AI users, and :FINGER UNAME gives last logout time even if UNAME is currently on the system.  Date: 31 March 1983 02:27 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC cc: GSB @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC AI, MC, and DM are running the latest version of ITS 1332. I reshuffled the version names and cards: NITS is what you want, and ITS is older. XITS is mostly GCd and not what you want. I'll do this for ML tonite or tomorrow. AI and DM have some more STYs (number doubled on DM). Also, latest COMSAT is installed all around.  Date: 31 March 1983 00:01 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Increased number of STYs on AI and DM.  Date: 29 March 1983 00:10 EST From: David A. Moon Subject: MLSLV bug To: RWK @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 28 March 1983 21:14 EST From: Robert W. Kerns To: BUG-ITS @ MIT-MC There are some MLSLV's on MC which are spending much of their time in WHYINT, and eating lots of CPU. Presumably they should be killing themselves, as part of network error handling or something. I fixed this, killed the jobs, and installed the new version everywhere. There were actually several bugs.  Date: 29 March 1983 00:09 EST From: David A. Moon To: BUG-ITS @ MIT-MC I gunned down about 5 arc devices that were hung in BOJSO with their creator (an FTP server) no longer in existence.  Date: 28 March 1983 21:14 EST From: Robert W. Kerns To: BUG-ITS @ MIT-MC There are some MLSLV's on MC which are spending much of their time in WHYINT, and eating lots of CPU. Presumably they should be killing themselves, as part of network error handling or something.  Date: 28 March 1983 21:05 EST From: Robert W. Kerns To: BUG-ITS @ MIT-MC I just found a detached 340C23 CHAOS job which appears to have gotten an ILOPR because it couldn't set its JNAME to MAIL, since there already seemed to be a job with that name. It doesn't look like ot checks for this possibility at all, but given that both the chaos address and job number parts of the UNAME are truncated, it should certainly have some strategy for dealing with this, like AOSing the UNAME or JNAME or something.  Date: Wednesday, 23 March 1983, 23:49-EST From: Robert W. Kerns Subject: thought for the day To: George J. Carrette Cc: BUG-ITS at MIT-MC In-reply-to: The message of 22 Mar 83 01:15-EST from George J. Carrette Date: 22 March 1983 01:15 EST From: George J. Carrette Taking a word frequency analysis of SYSENG;HOSTS >, we get the top ten "words" as: (522. HOST) (276. SERVER) (231. USER) (226. LISPM) (222. CHAOS) (205. PDP) (171. MIT) (157. UNIX) (102. VAX) (100. TAC) Out of curiosity, I measured (88. SCRC^_SCH^_SPA). I guess we won't make the top ten until sometime this summer. This argues for domains, of course.  ZOMBIE@MIT-AI 03/22/83 14:48:23 To: (BUG ITS) at MIT-AI AI will not accept MC or ML as devices although it does make supdup connections. Just thought someone might like to know... Sean  Date: 22 March 1983 01:15 EST From: George J. Carrette Subject: thought for the day To: BUG-ITS @ MIT-MC Taking a word frequency analysis of SYSENG;HOSTS >, we get the top ten "words" as: (522. HOST) (276. SERVER) (231. USER) (226. LISPM) (222. CHAOS) (205. PDP) (171. MIT) (157. UNIX) (102. VAX) (100. TAC)  Date: 21 March 1983 06:24 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC New PEEK and DDT installed on all four machines.  CSTACY@MIT-AI 03/21/83 02:59:59 Re: AI uptime To: (BUG ITS) at MIT-AI I am gonna have to bring it down to install the latest ITS version, so before I do... Today is Monday, the 21st of March, 1983. AI ITS 1325 has run for 16 days, 3 minutes, 11 seconds. System last revivde 15 days, 20 hours, 54 minutes, 59 seconds ago.  Date: 19 March 1983 22:56 EST From: David A. Moon Sender: ALAN @ MIT-MC Subject: job device wedged on MC To: BUG-ITS @ MIT-MC The created job was in JOBREU, hung at NJBREU+4 waiting for JBCG to clear. Previously it had pclsred from NJBRU1+7. The creator was hung in OPEN, at JBFLS, presumably trying to reuse it. Pclsring the creator caused it to start a new device job and the old one to go away. Looks to me like just an inherent race in the code, although there were multiple jobs trying to use the same AI: device. Maybe I'll look at the code more some other time.  Date: 19 March 1983 22:45 EST From: Christopher C. Stacy Subject: ARC device directories To: BUG-ITS @ MIT-MC What programs (other than ARCDEV) depend on understanding the binary representation of the internal directory?  Date: 18 March 1983 12:33 EST From: Ken Harrenstien Subject: INQUIR vs DDT To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC, BUG-INQUIR @ MIT-MC, RWK @ SCRC-TENEX Fixed in DDT.1430, installed on MC. I think what was going on was that it was failing to map in the database (probably out of file channels to open it with, since a broken TARAKA DVRSPL had them all). No, actually it was failing because the LSR1 file was smashed for real. I don't know why, but it was definitely munged. I fixed by copying the old version back over. DDT's LSRMAP now has an error return. All of it's callers seemed to be interested in finding out someone's HSNAME; I made them do something reasonable to fake it. That's the right thing from user prog viewpoint, since LSRMAP could fail no matter how cleverly it tries to find a good version. It should try harder, though.  Date: 18 March 1983 05:11 EST From: Christopher C. Stacy Subject: MLDEV To: BUG-ITS @ MIT-MC I reassembled the latest MLDEV on MC. I think it wasnt using HOSTS3 or something, since it wasnt doing anything useful. I think it works now; so I installed it.  Date: Friday, 18 March 1983, 04:40-EST From: Christopher C. Stacy Subject: INQUIR vs DDT To: Robert W. Kerns Cc: Ken Harrenstien , BUG-INQUIR at MIT-MC, BUG-ITS at MIT-MC, BUG-DDT at MIT-MC In-reply-to: The message of 18 Mar 83 00:48-EST from Robert W. Kerns Date: Friday, 18 March 1983, 00:48-EST From: Robert W. Kerns Date: 16 March 1983 18:36 EST From: Ken Harrenstien I think it is really bad for DDT to refuse to work just because it can't look up a name in INQUIR. This is just too much dependence; if we cant get a DDT to work then we are shafted, but good. DDT isn't supposed to not work in any serious way if the INQUIR database is trashed. It shouldn't lose any more seriously than failing to find your home directory. If it won't let you log in, that's a bug. The only other probable loser I can think of is :PRMAIL. I don't think that not working is serious. Fixed in DDT.1430, installed on MC. I think what was going on was that it was failing to map in the database (probably out of file channels to open it with, since a broken TARAKA DVRSPL had them all). DDT's LSRMAP now has an error return. All of it's callers seemed to be interested in finding out someone's HSNAME; I made them do something reasonable to fake it.  Date: Friday, 18 March 1983, 00:48-EST From: Robert W. Kerns Subject: INQUIR vs DDT To: Ken Harrenstien Cc: BUG-INQUIR at MIT-MC, BUG-ITS at MIT-MC, BUG-DDT at MIT-MC In-reply-to: The message of 16 Mar 83 18:36-EST from Ken Harrenstien Date: 16 March 1983 18:36 EST From: Ken Harrenstien I think it is really bad for DDT to refuse to work just because it can't look up a name in INQUIR. This is just too much dependence; if we cant get a DDT to work then we are shafted, but good. DDT isn't supposed to not work in any serious way if the INQUIR database is trashed. It shouldn't lose any more seriously than failing to find your home directory. If it won't let you log in, that's a bug. The only other probable loser I can think of is :PRMAIL. I don't think that not working is serious.  Date: 16 March 1983 18:36 EST From: Ken Harrenstien To: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC Considering how many things break totally when the INQUIR data base is corrupted, I would suggest that LSRTNS try to map in LSR1 OLD (ie previous version or versions) if it runs into problems with the standard file. Furthermore, INQUPD should try to make sure the existing file is OK before it renames it to LSR1 OLD. I think it is really bad for DDT to refuse to work just because it can't look up a name in INQUIR. This is just too much dependence; if we cant get a DDT to work then we are shafted, but good.  Date: Wednesday, 16 March 1983, 15:30-EST From: Christopher C. Stacy Subject: DIR device To: John G. Aspinall Cc: BUG-ITS at MIT-MC In-reply-to: The message of 16 Mar 83 13:31-EST from John G. Aspinall Date: 16 March 1983 13:31 EST From: John G. Aspinall The DIR device seems to be permanently getting device-full errors. This happens from emacs dired and from various flavours of top level invocation - ie DIR:CDATE UP , DIR:RDATE DOWN, etc. MC is probably permanently overloaded, and has no job slots for the device handlers for DIR: ....it works fine for me when there are available job slots.  Date: 16 March 1983 13:31 EST From: John G. Aspinall Subject: DIR device To: BUG-ITS @ MIT-MC The DIR device seems to be permanently getting device-full errors. This happens from emacs dired and from various flavours of top level invocation - ie DIR:CDATE UP , DIR:RDATE DOWN, etc.  Date: 13 March 1983 06:43 EST From: Alan Bawden Subject: TTYFLS problem To: BUG-ITS @ MIT-MC cc: BUG-EMACS @ MIT-MC, CSTACY @ MIT-MC, KMP @ MIT-MC TTYFLS, with it's single control bit set to 0, simply sets %TXIGN in the character in question. Unfortunately this causes .LISTEN to lie about the availability of input characters. Since EMACS won't redisplay if it thinks there are characters to be read, this is one way to cause an EMACS to fail to redisplay when proceeded. I don't think this exact screw can explain the mysterious "CStacy's lossage". Few programs probably use TTYFLS and even fewer with that control bit set to 0. But perhaps something else can cause .LISTEN to lie? (Does the MODLIN package do anything bizare?)  Date: 13 March 1983 06:36 EST From: Ken Harrenstien Subject: New TELNET installed To: BUG-ITS @ MIT-MC, BUG-TELNET @ MIT-MC I installed a new TELNET which fixes some throughput problems. In particular, one should not become hung waiting for typein to reach the remote host, and thus output will continue to be displayed and it should always be possible to break into command mode.  Date: 9 March 1983 17:17 EST From: David A. Moon Subject: .CALL 0, [ not SETZ ] To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 8 March 1983 15:39 EST From: Ken Harrenstien Is it the right thing that .CALLs which point to a non-SETZ word get an ILOPR instead of failing to skip? This is left over from about ten years ago, I believe, when that was going to be used for some kind of dynamic linking of subroutines. However, it is probably still right for it to ILOPR.  Date: 9 March 1983 03:54 EST From: Ken Harrenstien Subject: New ITS To: CSTACY @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC, TY @ MIT-MC, DCP @ MIT-MC, moon @ SCRC-TENEX cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC New XITS (1329) installed on MC. Old XITS renamed to ITS. There is no NITS. This version has a subtle change in SALV; SALV now starts at 212000 instead of 200000, in order to make room for extra ITS code! .;SALV 306BIN is the version that has this relocation hacked; SALV BIN still points to the old version. All future ITSes generated for MC must use SALV 306 or higher. This version of ITS tries to implement TCP URGENT handling for direct-connected STYs. I haven't tested it yet. All the known patches have also been incorporated; if I missed any we'll probably know about it pretty soon. The most important change is basically the one to SALV, since the 200000 address has always been hard-wired that way and there may conceivably be some ancient software that is in for a rude shock. There are no plans to change this for the KA ITSes at the moment.  Date: 8 March 1983 22:54 EST From: Alan Bawden Subject: ILOPR? To: DCP @ MIT-MC, KLH @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: The message of 8 Mar 1983 20:44 EST from David C. Plummer I was about to point out that there is already an error code for one variety of malformed .CALL, %ENSCL (illegal system call name). Except I find that the following: .CALL [SETZ ? SIXBIT /FOOBAR/ ? %CLERR,,1 ? SETZ 2] Fails to skip, yet also fails to load 1 with any error code (it does not even clear it.) The left half of .IOS 0 is loaded with %ENSCL however, so is is possible to find out the error if you look hard enough. I'll bet the idea is that if the first two words in a call block don't clearly identify it as such, then ITS has no business looking at the next word and using it to trash some other random location in the user's address space. Now that is all fine and good if the instruction following the .CALL is a .LOSE, since DDT will be able to figure it all out, but if instead there was a JRST to a error reporting routine, I'll bet total randomness would result from using the garbage left in 1 as an error code. I guess I have never been so unlucky as to misspell the name of a system call in a .CALL that I was planning on handling the errors from myself. I would argue that THIS case should be made an ILOPR as well! Another kind of malformed call block, namely one that doesn't terminate with a word with bit 4.9 on, generates %ETMRG (too many arguments). Since this error is NOT a function of which call was named in the call block, it really can only be interpreted as meaning "malformed call block". However it seems that ITS thinks that such call blocks are well-formed enough to actually risk storing the error code in any supplied error parameter. Since convention is to write error parameters at the beginning of a call block, I think this is reasonable. Funny, when I started this message I was planning on agreeing with KLH, but I seem to have convinced myself that DCP is right.  Date: 8 March 1983 20:44 EST From: David C. Plummer To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC I think ILOPRing is the right thing. One argument is to enumerate the common system calls and observe the effect of changing it. My first impression is a change would cause subtle bugs, especially during debugging (where I'd insist on ILOPR if I programmed it incorrectly). Another argument is philosophy: non-SKIP means failure to perform the desired operation. ILOPR means failure to perform the desired instruction. You can't have an operation before you have an instruction.  Date: 8 March 1983 18:18 EST From: Christopher C. Stacy Subject: for installation To: BUG-ITS @ MIT-MC New PEEK on all machines in SYSBIN;PEEK 565BIN.  Date: 8 March 1983 15:39 EST From: Ken Harrenstien To: BUG-ITS @ MIT-MC Is it the right thing that .CALLs which point to a non-SETZ word get an ILOPR instead of failing to skip? Currently the only thing which uses .CALL 0, is the symbolic system call frob, and presumably if any new secondary dispatch is invented for it (ie something other than SETZ as 1st word pointed at) it could also be made the sort of call that skipped on success. (this came up because a botched net server had a bad .CALL arg and was ILOPR'ing instead of getting a failure return which would have cleaned up the resulting mess)  Date: 7 March 1983 04:18 EST From: David A. Moon Subject: Autospeed dialups and system crashes To: ED @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 7 February 1983 00:37 EST From: Ed Schwalenberg Subject: Autospeed dialups and system crashes To: BUG-ITS @ MIT-MC If MC goes down and comes back up, and I've patiently remained dialled up while it was down, it typically types out 30 or so "x" characters and then just stays wedged, probably waiting for 300 baud input as opposed to 1200 baud which is what I normally use. I guess optimal behavior would be for the 11 to remember the baud rate and tell the 10 when it comes back up, while suboptimal behavior would be to flush the 11's input buffer and then retry autospeeding. Lousy behavior would be to hang up on the user. But the current behavior is just about pessimal. I don't know why it does this, since autospeeding and baud rates and all of that are entirely inside the 11; the 10 has nothing to do with it. But maybe someone gratuitously reloaded the 11, or maybe KLDCP did a Unibus reset or something?? Also I'm pretty sure the baud rate is set to 1200 when the program is first loaded, before autospeeding. I remember that a couple of years ago I tried to debug this and couldn't.  Date: 7 March 1983 02:59 EST From: David A. Moon Subject: terminal question To: GZ @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 5 March 1983 22:43 EST From: Gail Zacharias Is there anyway I can tell ITS to send parity bit high always (on dialup line). I'm getting a lot of framing errors and I figure this might help. On MC only, you can set all these parameters with :LSPEED. You want to turn on extra stop-bit, and then presumably set the character length one bit shorter to compensate.  Date: 5 March 1983 22:43 EST From: Gail Zacharias Subject: terminal question To: BUG-ITS @ MIT-MC Is there anyway I can tell ITS to send parity bit high always (on dialup line). I'm getting a lot of framing errors and I figure this might help.  Date: 5 March 1983 00:44 EST From: Christopher C. Stacy Subject: AHA! To: KMP @ MIT-MC cc: ALAN @ MIT-MC, DCP @ MIT-MC, KLOTZ @ MIT-MC, BUG-ITS @ MIT-MC When I use my Emacs init, Emacs does not redisplay after I type a character after a %PIATY interrupt. Things seem to work fine if I remove MODLIN from my init. Is it likely this will get fixed? I think MODLIN is spiffy, but I really hate having to refresh my own screen under these circumstances.  Date: 4 March 1983 02:16 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC cc: MOON @ SCRC-TENEX Hey, it looks to me like EMACS forgot to know to redisplay when I type something after my screen has been bashed (got-back-the-tty interrupt). Did someone break TECO, or ECHOIN, or am I hallucinating?  Date: 26 February 1983 20:29 EST From: Michael A. Bloom To: BUG-ITS @ MIT-MC I just connected to DM through the arpanet, and got a DDT instead of a PWORD.  Date: Thursday, 24 February 1983, 22:41-EST From: David C. Plummer Subject: Those mythical chaos BRD packets To: network at scrc, bug-lispm at oz, bug-its at mc, bug-twenex at xx, chaos-ncp-people at mc, bug-minits at mc, unix-chaos at vx, mit-in-people at mc I implemented chaos BRD packets in MINITS today. They seem to work. I also hacked some code for the Lisp Machine to actually test it, but it's just as gross and ugly as the rest of the current LispM chaos implementation.  Date: 22 February 1983 10:24 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC slightly less crockish WHOJ installed on MC, ML, and AI. Bugs to me.  Date: 21 February 1983 20:49 EST From: David A. Moon Subject: ML To: BUG-ITS @ MIT-MC I made NSUBNT (number of Chaosnet subnets) be a more reasonable size. ML (the only ITS machine that does its own Chaosnet routing) should get a reassembled ITS when convenient.  Date: 19 February 1983 20:11 EST From: Christopher C. Stacy Subject: [KLH: forwarded] To: BUG-ITS @ MIT-MC cc: ELLEN @ MIT-MC, BUG-PWORD @ MIT-MC, KLOTZ @ MIT-MC, GREGOR @ MIT-MC I see KLH already fixed the safe site problem by reassembling PWORD, so now it uses the same NETWRK goodies as TELSER.  Date: 19 February 1983 20:07 EST From: Christopher C. Stacy To: EBM @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: The message of 18 Feb 1983 20:34 EST from J. Eliot B. Moss Date: 18 February 1983 20:34 EST From: J. Eliot B. Moss To: BUG-ITS I CHTN'ed from XX and had MC request my password ... has the interface changed or is something screwy going on? I thought logins from other MIT machines did not require passwords ... TELSER apparently has a bug putting the host address where PWORD can see it, (or maybe PWORD needs to see a different format host address). I will look at and fix this in a moment.  Date: 19 February 1983 15:47 EST From: Kent M. Pitman Subject: MC crashing To: BUG-ITS @ MIT-MC, JPG @ MIT-MC, ELLEN @ MIT-MC MC was down this morning when I came in. Someone cold booted it and it only lasted a few minutes. He was in the midst of cold booting it when I came in to look at it just now, so I finished the booting. Next time it crashes, I'll try to poke a bit at the state and provide some debugging info. I posted a system message (in SYS;SYSTEM MAIL) warning that the system was being unreliable. If it stays up for a while, someone might want to remove that message. --kmp  Date: 19 February 1983 15:22 EST From: Tom Knight To: BUG-ITS @ MIT-MC MC would not boot from disk this afternoon, because it was hung, probably at PI level 3, shlunking unit 1 back and forth. Apparently booting with the boot switch is incapable of stopping the processor??? Eventually, by turning off unit 1, I got the machine to crash, and it then booted. This seems less than elegant as a way of solving the problem.  Date: Friday, 18 February 1983 22:05-EST Sender: KLOTZ @ MIT-OZ From: Leigh L. Klotz To: J. Eliot B. Moss Cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 18 Feb 1983 20:34 EST from J. Eliot B. Moss Gregor and I noticed this from cadr-20, which was a good site. Maybe someone broke the password system recently? Leigh.  Date: 18 February 1983 20:34 EST From: J. Eliot B. Moss To: BUG-ITS @ MIT-MC I CHTN'ed from XX and had MC request my password ... has the interface changed or is something screwy going on? I thought logins from other MIT machines did not require passwords ...  Date: 18 February 1983 08:16 EST From: Ken Harrenstien Subject: NETWRK and friends use HOSTS3 now To: BUG-ITS @ MIT-MC, BUG-TELNET @ MIT-MC, BUG-PEEK @ MIT-MC, BUG-NETWRK @ MIT-MC, BUG-MAIL @ MIT-MC, BUG-FTP @ MIT-MC I decided to do a little work on credit tonight. SYSENG;HOSTS XFILE now generates SYSBIN;HOSTS3 BIN as well. This is the new Internet host table and it is intended to become the standard. Both HOSTS1 and HOSTS2 will eventually go away. SYSENG;NETWRK has a new switch, $$HSTS3, that tells the routines to use HOSTS3 instead of HOSTS2. Also, the host number parser has been taught how to understand the new 4-octet syntax, as in "10.3.0.44" which is MC. TELNET has been modified to use the NETWRK routines (HOSTNM and SYMGET and friends). As a result, TELNET uses HOSTS3 and no longer needs HOSTS1. Hurray!!!!!!!!!!!!!!!! This of course implies that TELNET parses anything NETWRK does. The big question: is there ANY other software that still depends on HOSTS1?? I am going to flush that table VERY soon. HOST (alias HSTLOK) has likewise been modified for HOSTS3. TELSER also uses HOSTS3. PEEK now uses HOSTS3. COMSAT now uses ... QMAIL now ... FTPS now ... FTPU ... (All on MC only for the moment) Not a bad night's work. Ka-ching! There are still a number of programs that need to have $$HST3 turned on. The only thing you need to be careful of is references to NW$BYT and NW%ARP or NW%CHS; it is better to use the GETNET macro than NW$BYT. The file format itself is almost the same; only the format of host and net addresses is different. Note that ITS will understand either HOSTS2 or HOSTS3 format, using either NCP or TCP, so there is no need to retain HOSTS2 even if you are keeping NCP code around for posterity (which I recommend, by the way). As you upgrade, try to add a note to NETWRK pointing at your software, (see the first page) so that eventually we will have a handy list of things that use NETWRK and which will need to be reviewed in the event of future changes. --Ken  Date: 16 February 1983 21:04 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Hack :WHOJ installed on all ITSs now.  Date: 16 February 1983 08:27 EST From: Ken Harrenstien Subject: New PEEK on MC To: BUG-PEEK @ MIT-MC, BUG-ITS @ MIT-MC cc: RWK @ MIT-MC, HIC @ MIT-MC, EJS @ MIT-MC, RL @ MIT-MC, RLB @ MIT-MC, EBM @ MIT-MC I have installed another new PEEK on MC for testing. One feature of this version is that it does away with the stupid internal table that gave certain people (who are CC'd above) J mode by default. Those people who cannot type :P J can just type :PJ or PJ^K, if they establish the necessary link to SYS;TS PEEK. A more interesting feature is the ability to PEEK at ITS crash dumps. This must be invoked as JCL, to wit ":PEEK < filename". For example, :P Subject: I know this is a crock To: BUG-ITS @ MIT-MC cc: BUG-TALK @ MIT-MC There is now a crock version of TALK (WHOJ & friends) installed on MC and AI. If no one complains to much I will install it on ML and DM later on. This is not an RSEXEC frob at all, but a quick dirty hack based on the MLSLV (it reads TTY:). When I get a chance, I will convert TALK and IEC to work with TCP, but this was driving me crazy so I wrote this interim crock. Chris  Date: 15 February 1983 07:18 EST From: Ken Harrenstien To: BUG-ITS @ MIT-MC I just noticed that the :DOC for RFNAME doesn't mention that it can take a 3rd argument which is a BP to place to deposit an ASCIZ filename string.  Date: 13 February 1983 19:13 EST From: Kent M. Pitman Subject: Can somebody answer this? To: BUG-ITS @ MIT-MC Date: 12 February 1983 15:02 mst From: Schauble.HDSA at M.PCO.LISD.HIS To: KMP Re: ITS archive files Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 12-Feb-1983 17:03:33-est I'm looking for a way to transfer ITS archive files to Multics and have them arrive as Multics archives files. I recall that someone once wrote a program to do this. Do you perchange know anything about it? If not, do you have any documentation on the archive file format so that I can write one? I have no problem transfering a binary image of the ITS file, I just need to decode it. Thanks, Paul  Date: 13 February 1983 12:04 EST From: Ken Harrenstien To: BUG-PEEK @ MIT-MC, BUG-ITS @ MIT-MC New peek written to SYS;TS PEEK on MC only. If no bugs surface after a few days, it can be copied to other systems.  CSTACY@MIT-AI 02/11/83 14:07:04 To: (BUG ITS) at MIT-AI AI now has config options set for no 10-11 frobs such as the Chaosnet. This seems to work, I am typing this from it. I finished installing the MLDEV stuff here.  Date: 10 February 1983 06:54 EST From: David C. Plummer Subject: TCP NAME user/server To: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC, BUG-TCP @ MIT-MC cc: DCP @ MIT-MC, CSTACY @ MIT-MC, KLH @ MIT-MC, CENT @ MIT-ML Let's see if I can remember everything I just did. For MC: I linked DEVICE;JOBDEV AI to the same thing DEVICE;JOBDEV DM points to (SYSBIN;MLDEV BIN). This caused AI to appear as a device. ML's and DM's DEVICE directories are consistent (and hopefully have the correct programs). For AI: I installed the TCP NAME user/server program. :F @AI from MC now works. :F @MC from AI does not because AI tries to use the chaosnet!!??!!. The host table on AI says it is arpanet only, but apparently the system still has chaos code assembled in. :F @DM from AI does work. I tried to make sure the user ITS JOBDEVs were correct. MC:... doesn't work, again because it tries to use the chaosnet. DM: does work though. CSTACY, you should revise AI's greeting message (about MLSLV services), clean up any mess I may have left around, and perhaps assemble AI without chaosnet code (if that is the right thing).  Date: 7 February 1983 13:00 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC there is now a kludge in NETWRK for $$TCP inserters who bomb into ANALYZ, cuz I was getting bored with ISE0. I (or someone) should write a real TCP analyzer frob for it sometime.  CENT@MIT-ML 02/07/83 01:37:39 Re: TCP NAME user/server To: DCP at MIT-MC CC: (BUG ITS) at MIT-ML, (BUG NAME) at MIT-ML, (BUG TCP) at MIT-ML CC: KLH at MIT-MC Date: 6 February 1983 04:09 EST From: David C. Plummer Subject: TCP NAME user/server To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC, BUG-TCP @ MIT-MC I made the ITS name user and name server work under TCP. I made some spazzes, and there was a NCP/TCP difference causing a little more lossage. .... I installed and pdumped this on MC, ML and DM (what's going on with AI?). I tested it between MC and DM (both directions) and ML and DM (both directions). Source is back in SYSEN2; (whence it came). ai was down with minor disk lossage. please try installing now..  Date: 7 February 1983 00:37 EST From: Ed Schwalenberg Subject: Autospeed dialups and system crashes To: BUG-ITS @ MIT-MC If MC goes down and comes back up, and I've patiently remained dialled up while it was down, it typically types out 30 or so "x" characters and then just stays wedged, probably waiting for 300 baud input as opposed to 1200 baud which is what I normally use. I guess optimal behavior would be for the 11 to remember the baud rate and tell the 10 when it comes back up, while suboptimal behavior would be to flush the 11's input buffer and then retry autospeeding. Lousy behavior would be to hang up on the user. But the current behavior is just about pessimal. Obviously this is low-priority, though if somebody was to volunteer to fix the symptom by simply having MC never go down I'm sure they'd get a penny from JM. I'd be willing to give them a quarter, myself!  Date: 6 February 1983 04:09 EST From: David C. Plummer Subject: TCP NAME user/server To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC, BUG-TCP @ MIT-MC I made the ITS name user and name server work under TCP. I made some spazzes, and there was a NCP/TCP difference causing a little more lossage. Spazz 1: I completely blew it when doing the NETBLK for the LSN. I gave it %NSRFS as the wait state. A lot of good that does!! Spazz 2: I didn't know that a NETBLK for the LSN would probably return the new state as %NSRFC. There is another NETBLK waiting for it to go out of %NSRFC. Spazz 3: The /i switch (use IP/TCP) simply could not work. There is a comment to this effect in the code. Basically, :f /i@dm passes the /i on to DM, and :f @dm/i throws the /i away (this is conjecture, but seems to fit the data). Therefore, it always uses TCP over the arpanet. Difference: NCP didn't need a FORCE done to send the JCL to the other host? I know TCP does, but there was now such call in the program. There is now! I installed and pdumped this on MC, ML and DM (what's going on with AI?). I tested it between MC and DM (both directions) and ML and DM (both directions). Source is back in SYSEN2; (whence it came). Ken, I know several people complained that ITS thought it had a TCP NAME server but it never worked. Could you ask them to try again? Thanks.  Date: 6 February 1983 02:48 EST From: David C. Plummer To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC The CHAOS ARPA server now behaves as follows: Contact name TCP tries to establish a TCP connection Contact name NCP tries to establish an NCP connection, even though it should never succeed. Contact name ARPA tries to establish a TCP connection. If it times out (15 seconds), then it tries an NCP connection. Auxiliary connections may work again, using the network protocol that the primary connection is using.  Date: 1 February 1983 00:53 EST From: David A. Moon To: BUG-ITS @ MIT-MC Noticing that there was no CHAOS-TCP gateway on ML, I put one there. I didn't bother testing it.  Date: 31 January 1983 18:07 EST From: Richard Brenner To: BUG-ITS @ MIT-MC cc: ASB @ MIT-MC, JPG @ MIT-MC JPG@MIT-MC 01/31/83 17:56:21 Re: Job A wants the TTY To: ASB at MIT-MC CC: JPG at MIT-MC ASB@MIT-MC 01/31/83 17:23:03 Re: Job A wants the TTY Recently there has been a change in the way that the user is notified that a proceeded Macsyma needs the tty. Formerly, notification would be issued only once while in another Macsyma, but it now appears that this occurs whenever a file is loaded. To see this new behavior, start up a Macsyma, then after you get a (C1) ^Z it and ^P it. Then start a second Macsyma, and try something like INTEGRATE(X,X,0,1); I have not tried OA^K. I prefer the old behavior. This printout is done by ITS, not by MACSYMA, so we have no control over it. It happens whenever the job needs to go up to top-level for something which may very well happen while a file is being loaded. I'm not convinced there's been any change here, but if there has, it's an ITS issue, not a MACSYMA issue.  Date: 31 January 1983 12:02 EST From: Christopher C. Stacy Subject: broken? To: CENT @ MIT-ML cc: BUG-ITS @ MIT-ML, BUG-PEEK @ MIT-ML In-reply-to: The message of 01/30/83 00:28:08 from CENT at MIT-ML AI (and some other machines probably) have a slighlyt buggy version of PEEK. Copy MC:SYSBIN;PEEK > to the machine, and load up a job with it. Type $G and it will install itself. Ill do this if I get a chance today.  HDT@MIT-ML 01/31/83 00:35:39 To: (BUG ITS) at MIT-ML How can I get its typeout into a wall paper? (ie. the functionality of twenex's photo)  DCP@MIT-MC 01/30/83 13:22:25 To: rms at MIT-ML CC: (BUG ITS) at MIT-ML rms@MIT-ML (Sent by ___014@MIT-ML) 01/29/83 17:48:54 TELNET on a Lispm gets no response from the TCP server on ML or MC trying to go to CMUA even though ML is up and can successfully finger CMUA. It works for me, although the output from CMU is completely garbaged. Are you sure you are connecting to TCP and not to ARPA?  CENT@MIT-ML 01/30/83 00:28:08 Re: broken? To: (BUG ITS) at MIT-ML, (BUG PEEK) at MIT-ML :p on AI seems to be broken. when i try to kill a job, the display changes from whatever before to show that job, but doesn't ask GUN THIS JOB?. i think the problem is not that it thinks it has asked this and is waiting for an answer (typing y does not seem to do anything). i do give an argument, so it isn't that, unless . is broken in some fashion. :p on ML behaves properly, so perhaps the version on AI is bad somehow?  Date: 29 January 1983 21:11 EST From: David A. Moon To: BUG-ITS @ MIT-MC ML-device service between ML and MC now uses Chaosnet. Relink DEVICE;JOBDEV ML/MC if there are any fatal problems. Let me know if there are any problems. Making links does not work across this. I don't think it worked the old way either, unless it was patched in the binary and not fixed in the source. I'll probably fix this tomorrow (the two ends don't seem to agree on what the protocol is for sending over the arguments to the MLINK system call)  Date: 29 January 1983 20:43 EST From: Steven A. Swernofsky Subject: mail from 1200400006 To: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC cc: SASW @ MIT-MC I have been receiving messages which read "You have net mail from 1200400006:" followed by the normal message which indicates the receipt of mail. I think this is wrong. Is it? -- Steve  Date: 29 January 1983 20:29 EST From: David A. Moon Subject: MLSLV... To: ELLEN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC There do seem to be lots of cases of things like MLSLV's that think their connection is open, but the foreign host doesn't know about that connection, and JOB.nn's (MLDEV's) that have an open connection and no owner anymore. Note that neither program has been changed. Probably the advent of TCP has made the NCP implementation in the IMPs more unreliable? The Chaosnet version of the ML device certainly won't have these problems, and the TCP version shouldn't, so when they're installed things should look up. I guess I'll go ahead and install the Chaosnet version between ML and MC now.  rms@MIT-ML (Sent by ___014@MIT-ML) 01/29/83 17:48:54 To: (BUG ITS) at MIT-ML TELNET on a Lispm gets no response from the TCP server on ML or MC trying to go to CMUA even though ML is up and can successfully finger CMUA.  Date: 29 January 1983 01:41 EST From: V. Ellen Golden Subject: MLSLV... To: BUG-ITS @ MIT-MC cc: BUG-TCP @ MIT-MC There seems to be a pattern developing of MLSLVs opening connections and then lying around. In some cases this may be due to a system down, but shouldn't it time out? At this moment there are three such, all from ML or AI. ML and AI are both up now.  Date: 28 Jan 1983 1624-EST From: S. W. Galley Subject: Re: con't... To: ALAN@MIT-MC cc: BUG-ITS@MIT-MC In-Reply-To: Your message of 23-Jan-83 2145-EST Don't panic! DM is now running COMSAT, and I have converted the birthday-greeting program suitably -- it's independent of COMSYS. -------  Date: 27 Jan 1983 1056-EST From: P. David Lebling To: CStacy@MIT-MC, ALAN@MIT-MC cc: BUG-ITS@MIT-MC In-Reply-To: Your message of 25-Jan-83 1528-EST Comsat has been launched on DM. What I have done to (temporarily) deal with COMSYS is to convince it that all net mail gates through MIT-DMS (which will send it via Comsat, since FTP produces .MAIL. files). Eventually, stuff which produces Comsys request files should be changed by whomever is responsible for them. In any case, DM now is running a fully compatible Comsat, and Comsys is only run by hand periodically (by me). Dave -------  Date: 25 January 1983 23:35 EST From: Ken Harrenstien Subject: TCP for PEEK To: BUG-TCP @ MIT-MC, BUG-PEEK @ MIT-MC, BUG-ITS @ MIT-MC PEEK on MC has had some TCP connection status display stuff added. It is not very elegant but should suffice for a while.  Date: 25 January 1983 15:28 EST From: Christopher C. Stacy To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: The message of 23 Jan 83 21:45-EST from Alan Bawden Apparently no one wants to hack TCP for COMSYS in the old Muddle it runs in. I installed a ready-to-launch COMSAT on DM a while back, and I think PDL and company are going to start running it before February. I'll do something about birthday messages.  Date: Sunday, 23 January 1983 22:51-EST Sender: KLOTZ @ MIT-OZ From: Leigh L. Klotz To: Alan Bawden Cc: BUG-ITS @ MIT-MC Subject: con't... In-reply-to: The message of 23 Jan 1983 21:45 EST from Alan Bawden Happy birthday...  Date: 23 January 1983 21:45 EST From: Alan Bawden Subject: con't... To: BUG-ITS @ MIT-MC I noticed this because I missed my yearly birthday greeting message from COMSYS. Clearly if COMSYS is going away, we need a crash program to move this functionality to some other program!  Date: 23 January 1983 21:41 EST From: Alan Bawden Subject: COMSYS? To: BUG-ITS @ MIT-MC So just what is the story with mailers on DM? Someone has sort of installed COMSAT there, except it isn't running. COMSYS isn't running either, and there is a small queue of messages on the COMSYS directory waiting to be sent. I suppose the fact that DM is running a pre-TCP version of ITS might have something to do with all this...  Date: 21 January 1983 10:51 EST From: Ken Harrenstien To: BUG-ITS @ MIT-MC If ITS system mem (LMEMFR) is zero for more than a few seconds, a system console message should be printed so that it's more obvious why things are losing. MC has been skirting this (and falling victim to it) dangerously often lately during peak load.  Date: 20 January 1983 03:28 EST From: Tom Knight To: BUG-ITS @ MIT-MC MC was catatonic tonight with the sysjob hung on the core job. I took a dump, crash corrq. It was stopped with key 0. The microcode had to be reloaded before I could get the system to load, which might be related.  Date: 19 January 1983 15:27 EST From: Christopher C. Stacy To: mhk @ MIT-ML cc: BUG-ITS @ MIT-MC AI crashed with a parity error.  MHK@MIT-ML 01/19/83 11:08:23 To: (BUG ITS) at MIT-ML I was just on AI about 15 mins. ago. I think it may have crashed on me while I was trying to look at the following problem: :f @its bought me: [ ERROR; 10107>>PUSHJ 17,13251 Since your DDT lokks quite different from ours, and I don't know your calls very well, I didn't get very far and then the machine went away.  CENT@MIT-ML 01/17/83 03:04:05 Re: its bugs To: DCP at MIT-MC CC: (BUG ITS) at MIT-MC Date: 14 January 1983 14:13-EST From: David C. Plummer Where are the old bug reports? MC;SYSTEM;ITS BUGS only goes back to 7/25/81. At first glance, the file on AI is not any better. AI:SYSTEM;ITS OBUGS goes back to 1 June 79..  Date: Sunday, 16 January 1983 16:28-EST From: MOON at SCRC-TENEX To: David C. Plummer Cc: bug-its at MIT-MC, BUG-LISPM at MIT-OZ, bug-minits at MIT-MC, bug-supdup at MIT-MC, bug-twenex at MIT-XX at MIT-MC, Henry at MIT-OZ, unix-chaos at MIT-VAX Subject: not exactly about Supdup windows on color screen In-reply-to: The message of 16 Jan 1983 12:35-EST from David C. Plummer What ITS expects is for typing a character in the last column of a line to leave the cursor in that column, and for line feeding off the last line of the screen to scroll by the number of lines specified in the terminal characteristics (ITS won't use this unless the user says to use scroll mode). Thus the -only- way to move the cursor from one line to the next is via line feed (or %TDCRL or cursor-positioning). The terminal is required not to have any "intelligent" features where it secretly moves the cursor. I assume the Lisp machine Supdup is blowing it.  Date: 16 January 1983 13:46 EST From: David C. Plummer Subject: Supdup windows on color screen To: DCP @ SCRC-TENEX cc: BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC, BUG-SUPDUP @ MIT-MC, unix-chaos @ MIT-VAX, BUG-LISPM @ MIT-OZ, Henry @ MIT-OZ, bug-twenex @ MIT-XX OOPS. The complete paragraph from page 3, the first part of which is just as vital as the second: The TCMXH variable specifies the line width in number of characters. This value is one less than the screen width (ITS indicates line overflow by outputting an exclamation point at the end of the display line before moving to the next line). Note: the terminal must not do an automatic CRLF when a character is printed in the rightmost column. If this is unavoidable, the user SUPDUP must decrement the width it sends by one.  Date: Sunday, 16 January 1983, 12:35-EST From: David C. Plummer Subject: Supdup windows on color screen To: BUG-LISPM at MIT-OZ, bug-its at MIT-MC, bug-twenex at MIT-XX, bug-minits at MIT-MC, unix-chaos at MIT-VAX, bug-supdup at MIT-MC Cc: Henry at MIT-OZ In-reply-to: The message of 15 Jan 83 23:43-EST from Henry Lieberman Sorry if you get this 6 times because of all the mailing lists, but this problem exists in many places, and should really be resolved on a global scale. ------------------------------ What we need to do is document what ITS expects to see for line width, and what it expects the terminal to do when you try and type something on the last line (stick versus wrap). We should then make sure each user implementation and the non-ITS servers strictly obey this. (If you read the SUPDUP RFC [a copy in MC:DCP2;RFC SUPDUP], you will find the following, which I think is sufficient for everybody to check their programs. [Page 2] The SUPDUP protocol originated as the internal protocol used between parts of ITS, and between ITS and "intelligent" terminals. Over the network, a user host acts like an intelligent terminal programmed for ITS. [later in Page 2] Because this is also the internals of ITS, the right to change it any time if necessary to provide new features is reserved by MIT. [Page 3] Note: the terminal must not do an automatic CRLF when a character is printed in the rightmost column. If this is unavoidable, the user SUPDUP must decrement the width it sends by one.  Date: 14 January 1983 21:37-EST From: David C. Plummer To: BUG-ITS @ MIT-MC MC was found catatonic tonight. Taft says this is a recurring phenomena. The symptoms were: extrememly long wait to get a chaos supdup connection (if at all). STATUS answered immediately, however. ^Z from the console keybaord and the VT52 took a long time to respond. After that, loading a file looked like it was doomed to failure (though if I waited long enough, it may have loaded). SYS^F, SYS1^F, .TEMP.^F all failed to give me a directory listing. It's been a long time since I've played at the console, so CRASH;011483 LOOP may or may not contain anything useful. warm boot reload worked.  Date: 14 January 1983 14:13-EST From: David C. Plummer To: BUG-ITS @ MIT-MC Where are the old bug reports? MC;SYSTEM;ITS BUGS only goes back to 7/25/81. At first glance, the file on AI is not any better.  Date: 14 January 1983 14:05-EST From: David C. Plummer Subject: IOT control bits To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, GSB @ MIT-MC I think I noticed this 2 years ago, and I though Moon fixed it. Oh well. I discovered it by trying to turn a DDT display channel into super-image-output by toggling both bits. Great way to send ARDS pictures to your friends...  Date: 14 January 1983 02:57-EST From: Alan Bawden Subject: IOT control bits To: BUG-ITS @ MIT-MC cc: GSB @ MIT-MC This doesn't work as advertized: .call [setz ? sixbit /iot/ [%tipek,,ttyich] setzm t] While this does: .call [setz ? sixbit /iot/ %clbit,,%tipek movei ttyich setzm t] We could just fix the documentation of the IOT call to not claim that the left half of the first argument is XORed with the control bits...  Date: 13 Jan 1983 1432-EST From: CSTACY at MIT-DMS (Christopher C. Stacy) To: bug-its at MIT-DMS Message-id: <[MIT-DMS].254621> There is a hacked PEEK which is patched around the init problem in my directory on DM; I linked SYS;TS PEEK to it for the moment, until PEEK gets fixed.  Date: 13 January 1983 13:20-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC In ITS 1317 or higher on DM only, PEEK blows up trying purify itself. It dies trying to get a page at INITA.  Date: 13 January 1983 07:59-EST From: David C. Plummer To: BUG-ITS @ MIT-MC cc: DEVON @ MIT-MC I updated .INFO.;ITS .CALLS and .INFO.;ITS TTYVAR to reflect the fact that TTYOPT bit 1.3 is indeed in use, and is 1.3 %TPRSC This tty can do region scrolling. As defined in SYSTEM;BITS >.  Date: 13 January 1983 06:38-EST From: Devon S. McCullough Subject: supdup for personal computers To: DCP @ MIT-MC cc: BUG-ITS @ MIT-MC, GRUPP @ MIT-MC In-reply-to: The message of 13 Jan 1983 04:46-EST from David C. Plummer What I am trying to convey is, that we need a way to tell ITS to send %TDQOT's argument without sending the %TDQOT itself, even when the TCTYP is SOFTWARE, so that programs can use %TDQOT to talk funny protocols without the necessity of changing TCTYP to PRINTING and back. Inventing something like :TCTYP SUPDUP would work for dialups but not for network connections, because network servers currently assume that any %TDORS byte sent as output was caused by an output reset (they have no way of telling whether this is so) and do the equivalent of an output reset for telnet or whatever. If the user wants to actually send a %TDORS byte as data it must be quoted, as in %TDQOT %TDORS. This means that a network server talking to a TAC with :TCTYP SOFT must see the %TDQOT's, but only send the argument, not the %TDQOT. On the other hand, a server talking to another SUPDUP serving host does indeed want to pass along %TDQOT's uncensored. By the way, the current (losing) TCP server recognises %TDORS but not %TDQOT, so that funny microcomputer programs LMODEM and SLOSTY which have long worked with NCP are now broken under TCP.  Date: 13 January 1983 04:46-EST From: David C. Plummer Subject: supdup for personal computers To: DEVON @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 13 January 1983 01:51-EST From: Devon S. McCullough TTYOPT bit 1.3 seems to be available. Let's call it %TPQOT and simply have network servers look at this bit to decide whether %TDQOT should be sent or not, instead of checking for TCTYP=%TNSFW as is done now. I don't understand your problem, and that won't work anyway. My understanding of the ITS terminal system is that characters are translated as they are pulled out of the ITS terminal buffer. If the terminal type is software, then no translation is done. Because you are on a software terminal ITS will not look at anything (including %TDQOT) and therefore just send it out. Also, this translation is probably done before the implemention of STYNET sees the character, so "have network servers look" will do no good. The net result is that what you send to a super image output channel that is %TNSFW is exacly what the other end (terminal or STY) will see. You do get raw 8bit strings.  Date: 13 January 1983 01:51-EST From: Devon S. McCullough Subject: supdup for personal computers To: GJC @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: The message of 12 Jan 1983 12:45-EST from George J. Carrette I've been using SUPDUP on 8080 and 6502 personal computers to access ITS for years now, started using data compression about a year ago. My program SLOSTY is a modified PTY which does a simple Huffman code. I was planning to move up to fractional bits and other hairy codings, but lost interest when I quit logging in via the ARPAnet. Not being able to output arbitrary 8-bit strings defeats the whole purpose of doing data compression. It *IS* possible to output 8-bit strings from ITS, but it requires the ugly kludge of setting TCTYP to PRINTING in order for %TDQOT and %TDORS to work properly, restoring the original TCTYP when done. TTYOPT bit 1.3 seems to be available. Let's call it %TPQOT and simply have network servers look at this bit to decide whether %TDQOT should be sent or not, instead of checking for TCTYP=%TNSFW as is done now.  CSTACY@MIT-AI 01/13/83 01:18:34 To: (BUG ITS) at MIT-AI AI is back up now.  Date: 13 January 1983 00:12-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC MC seemed to be wedged: I could not login at the console or from my FILE job. Some other file job did get on tho, but I still coldnt get anything out of the terminal. I paused the system and I think the SYS job was running. I continued it, and it went into a very tight loop. This time SW0 didnt work. I got into DDT and found that U was zero. Dumped to CRASH2;LOOOP SYS and reloaded XITS.  Date: 12 January 1983 12:45-EST From: George J. Carrette Subject: supdup for personal computers To: DEVON @ MIT-MC cc: BUG-ITS @ MIT-MC Do you actually have this and the datacompression implemented? On what machines? By the way, you should not really need to send arbitrary eight-bit-strings just because you are doing data-compression. Certainly it is more convenient if you do, but you can certainly encode the information in whatever arbitrary characters that are available.  Date: 11 January 1983 20:59-EST From: Devon S. McCullough To: BUG-ITS @ MIT-MC cc: DEVON @ MIT-MC, GRUPP @ MIT-MC, RWH @ MIT-MC In-reply-to: The message of 01/10/83 18:22:27 from GSB@MIT-ML In order to support data-compression and other non-SUPDUP protocols peculiar to personal computers, we need to be able to output ARBITRARY EIGHT BIT STRINGS to the user. ITS currently does this in a grossly crappy way, using %TDQOT in Super-Image output mode. Since this is the ONLY mechanism for doing this, it shouldn't interact with the user's TCTYP, but it does. Users with terminals that happen to understand %TD codes get screwed because ITS does not simply send %TDQOT's argument, it sends the %TDQOT as well. This is no good. There should be a +%TPSUP bit analogous to %TPTEL to say you are talking to a SUPDUP connection. Programs that check TCTYP=%TNSFW now should look at this bit instead.  Date: 11 January 1983 18:54-EST From: David A. Moon Subject: RFNAME bug To: BUG-ITS @ MIT-MC Date: 10 January 1983 17:46-EST From: David A. Moon To: BUG-ITS @ MIT-MC RFNAME on another job's channel clobbers that job's UUAC (via CHNDCD via NRFNM1) without pclsring the job, probably causing it to go off and do weird things. Fixed in the source (SYSHAK;ITS)  Date: 10 Jan 1983 1658-EST From: SWG at MIT-DMS (S. W. Galley) To: bug-its at MIT-DMS Subject: SYSTEM CLOBBERED Message-id: <[MIT-DMS].254428> DM has been getting a lot of these lately, e.g. SYSTEM CLOBBERED BETWEEN 144467 AND 112110 XOR= 350231,,746375 ! 07:10:02 76277 71061 56520 40711 163616 115205 54000 152343 30356 113152 176000 27310 2104 50054 116051 127647 121075 61070 170210 123760 42430 16237 13201 134467 174067 166377 36562 56473 13506 152102 42527 121674 141177 131607 43454 61376 What do all those numbers mean? Where is the problem?  Date: 11 January 1983 01:32-EST From: Christopher C. Stacy Subject: AI is down To: BUG-ITS @ MIT-MC AI is sick. It runs sometimes for a while, with random jobs getting random parity errors. Sometimes the system gets an exec mode parity error. Just now it got KA: APR ERROR IN NULL JOB.  Date: 10 January 1983 17:46-EST From: David A. Moon To: BUG-ITS @ MIT-MC RFNAME on another job's channel clobbers that job's UUAC (via CHNDCD via NRFNM1) without pclsring the job, probably causing it to go off and do weird things.  Date: 10 Jan 1983 1248-EST From: SWG at MIT-DMS (S. W. Galley) To: KLH at MIT-DMS, BUG-ITS at MIT-DMS Subject: DM crash at 12:30 Message-id: <[MIT-DMS].254414> Job #9 was looping thru all PC values, apparently. PI 3 in progress, PI 1 request, no clock interrrupts, no EXEC mode. Dumped in DM:CRASH;JOB9 LOOP.  Date: 10 Jan 1983 1247-EST From: SWG at MIT-DMS (S. W. Galley) To: KLH at MIT-DMS, BUG-ITS at MIT-DMS Subject: DM crash Message-id: <[MIT-DMS].254413> ... at 11:00 at UQL5A+15. Dumped in DM:CRASH;UQL5A +15.  Date: 10 January 1983 04:09-EST From: RWK, CSTACY @ MIT-MC Sender: CSTACY @ MIT-MC Subject: DDT on MC To: BUG-ITS @ MIT-MC There is no (known) reason why we should not be running the latest DDT, which RWK thinks has all the needed patches and no other changes from the last correctly installed one. (Well, there was one set of bogus changes... sigh --RWK) Anyway, we debugged them, and installed them (MC only). I had thought CSTACY was going to install DDT from the sources some months ago, apparently he thought I was. So we did.  Date: 10 January 1983 01:56-EST From: Christopher C. Stacy Subject: DDT on MC To: BUG-ITS @ MIT-MC cc: JPG @ MIT-MC The DDT installed on MC was an old one which did not have the fix for the old :REAP command bug. Not understanding quite why this version was installed, I re-installed the DDT from SYSBIN;DDT BIN. This version has the fix. RWK thinks the source for DDT has all the patches, but I noticed it didnt have the :REAP fix, so I put that into the source.  Date: 10 January 1983 00:27-EST From: Herb Lin To: VUG-ITS @ MIT-MC, BUG-ITS @ MIT-MC can some system wizard tell me the format of tapes written on MC? density, block size, all that kind of stuff? i need to know for a machine to which I would like to move some MC files by tape. tnx.  Date: 9 January 1983 07:47-EST From: David C. Plummer Sender: DCP0 @ MIT-MC To: BUG-CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC I'm trying to run the syseng;hosts xfile, and when it tries to ftp to sail, it looks like the NETBLK timeout is around 4 minutes when it starts. Is this really necessary?  Date: 8 January 1983 14:30-EST From: David C. Plummer Subject: user/server times To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC I fixed the source of :TIMES (in tcp;) to only wait 10 seconds instead of 30 for the TCP connection to open/fail. I thought you could just use NETBLK...  Date: 7 January 1983 23:20-EST From: Christopher C. Stacy Subject: user/server times To: BUG-ITS @ MIT-MC I converted the :TIMES program along with the TIMSRV. The TIMES program has two run time switches called NCPTRY and TCPTRY. It defaultly tries both protocols and tells you which it won with. Tested and installed on MC.  Date: 7 January 1983 20:24-EST From: Christopher C. Stacy Subject: TIMSRV converted (big deal!) To: BUG-ITS @ MIT-MC I converted the time server (socket 45) for TCP as well as NCP. It is installed on MC and works with NCP (we dont have a TCP user to try it with yet.) Source is TCP;TIMSRV. Chris  Date: 3 Jan 1983 1554-EST From: SWG at MIT-DMS (S. W. Galley) To: KLH at MIT-DMS Cc: bug-its at MIT-DMS Subject: DM crash Message-id: <[MIT-DMS].254017> ITS 1312 crashed at 14:20 when SWPOPG was called with A/ 6. I dumped it to DM:CRASH;SWPOPG A/6.  Date: 3 January 1983 15:06-EST From: David A. Moon To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 3 January 1983 00:26-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC In ITS 1315 on AI and ML, shutting the system down doesnt seem to work all the time. I get the ITS NOT IN OPERATION message, but then it seems to go back to normal timesharing and you never get the SHUTDOWN COMPLETE message. The pager lights look like it is running normal timesharing, although you can't login, and the data lights show only the SYS job getting run. It doesn't shut down until various things are complete, such as all jobs gunned down and the not in operation message typed out on all terminals. Find the place that does the shutdown complete bug pause and see what it was waiting for. It could be that someone installed a daemon job with OPTLIV that fails to finish itself up and go away.  Date: 3 January 1983 14:57-EST From: David C. Plummer To: BUG-ITS @ MIT-MC Now that ITS has TCP, would it be feasible to hack the dover spooler to use the TCP route if the CHAOS route appears to be down? I don't know all the addressing issues, but if this is something that should be done, I'll help look into it.  Date: 3 January 1983 00:26-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC In ITS 1315 on AI and ML, shutting the system down doesnt seem to work all the time. I get the ITS NOT IN OPERATION message, but then it seems to go back to normal timesharing and you never get the SHUTDOWN COMPLETE message. The pager lights look like it is running normal timesharing, although you can't login, and the data lights show only the SYS job getting run.  Date: Friday, 31 December 1982, 10:38-EST From: David A. Moon Sender: jek at SCRC-VIXEN Subject: Chaosnet FILE server To: BUG-TENEX at SCRC, BUG-TWENEX at XX, BUG-ITS at MC 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.  Date: Wednesday, 29 December 1982, 23:36-EST From: David A. Moon Subject: Chaosnet FILE server To: BUG-TENEX at SCRC-POINTER, BUG-TWENEX at XX, BUG-ITS at MC 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.  Date: 29 December 1982 23:41-EST From: Ken Harrenstien Subject: Flow control in STYNET To: BUG-ITS @ MIT-MC 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!  Date: 29 December 1982 23:33-EST From: Ed Schwalenberg Subject: STYNET connections from CHAOS net lacking flow control To: BUG-ITS @ MIT-MC 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?  Date: 24 December 1982 12:34-EST From: Stavros M. Macrakis Subject: T1061 screwups To: BUG-ITS @ MIT-MC cc: KLH @ MIT-MC Bug was on this end. Sorry.  CENT@MIT-ML 12/19/82 23:02:10 Re: ai lossage To: (BUG ITS) at MIT-ML ai keeps halting. i keep continuing it.  Date: 11 December 1982 14:12-EST From: Ken Harrenstien To: BUG-ITS at MIT-MC, BUG-DDT at MIT-MC 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.  Date: 11 December 1982 02:44-EST From: Jeffrey P. Golden To: BUG-ITS at MIT-MC MC:SYSTEM;ITS 1279 and ITS 1281 were the same! So I deleted the former and linked it to the latter.  Date: 8 Dec 1982 2058-EST From: Robert W. Kerns Subject: Re: bogus uptime record To: SWG at MIT-DMS, BUG-ITS at MIT-MC cc: KFL at MIT-AI, RWK at SCRC-TENEX In-Reply-To: <[MIT-DMS].251798> 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! -------  Date: 8 Dec 1982 0942-EST From: SWG at MIT-DMS (S. W. Galley) To: BUG-ITS at MIT-MC Cc: KFL at MIT-AI In-reply-to: Message of 07 Dec 82 at 0439 EST by CStacy@MIT-MC Subject: bogus uptime record Message-id: <[MIT-DMS].251798> For the same reason, DM claimed to have been up for about 300 days!  Date: Tuesday, 7 December 1982, 23:09-PST From: David C. Plummer Subject: Re: SUPDUP TTYSMT To: Barry Margolin at MIT-MULTICS, rsl at SCRC-TENEX Cc: DCP at MIT-MC, BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, BUG-LISPM at MIT-MC In-reply-to: The message of 7 Dec 82 18:31-PST from Barry Margolin at MIT-MULTICS 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.  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.  Date: Tuesday, 7 December 1982, 12:23-PST From: Richard Lamson Subject: SUPDUP TTYSMT To: David C. Plummer Cc: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, BUG-LISPM at MIT-MC In-reply-to: The message of 6 Dec 82 07:10-PST from Bernard S. Greenberg 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  Date: 7 December 1982 11:21-EST From: Christopher C. Stacy To: BUG-ITS at MIT-MC ITS 1283 is now running as NITS on AI. ITS 1279 is called "ITS" on that machine.  Date: 7 December 1982 04:39-EST From: Christopher C. Stacy To: BUG-ITS at MIT-MC, KFL at MIT-AI In-reply-to: The message of 6 Dec 82 18:58-EST from KFL at MIT-AI KFL@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.  CENT@MIT-ML 12/07/82 00:33:00 Re: ai up? To: KFL at MIT-AI CC: (BUG its) at MIT-MC KFL@MIT-AI 12/06/82 18:58:07 To: (BUG its) at MIT-MC Why does AI claim to have been up for 195 days? "Surpassing all previous uptime records"? 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?  KFL@MIT-AI 12/06/82 18:58:07 To: (BUG its) at MIT-MC CC: kfl at MIT-MC Why does AI claim to have been up for 195 days? "Surpassing all previous uptime records"? ...Keith  Date: 5 December 1982 02:41-EST From: David C. Plummer To: uc.mp at MIT-EECS, jtw at MIT-SPEECH cc: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, BUG-LISPM at MIT-MC 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.  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  Date: 30 November 1982 02:06-EST From: Christopher C. Stacy Subject: AI KA Inquire database To: BUG-ITS at MIT-AI, (*MSG *AI) at MIT-AI The Inquire database on AI was apparently smashed by a hardware failure, and has been restored from about a week ago. If you made any modifications in the past week or two, you might want to check to see if they were lost. You can check by doing :WHOIS you@AI from an ARPAnet ITS.  Date: 28 November 1982 07:45-EST From: Christopher C. Stacy Subject: SYSMSG illoping - whats this all about To: KMP at MIT-MC cc: BUG-ITS at MIT-MC It needed to be repurified, which I just did. I guess I will make it figure that out itself in the future.  Date: 27 November 1982 11:43-EST From: Frank J. Wancho Subject: ARnn Structure To: BUG-ITS at MIT-MC The obvious answer to this query below would be to ignore the question and simply tell him to use the ARnn:CPM;fn1 fn2 construct in FTP. However, he is the first "outsider" to ask an intelligent question about the actual structure of ARChive files. Is there online documentation or can someone create such info that I can send him? I believe such info would be valuable to other sites wishing to FTP an entire ARChive file and *then* break it into its component files... --Frank -------------------- Date: 25 Nov 1982 2020-PST From: Jorge Phillips Re: cpm; directory Hi, I hadn't accessed the CPM; directory at [MC] for a LOOONG time and just found out that the directory's format has changed completely. I tried ftp'ng one of the ARnn files (ARnn NSTAR) and found out that it consists of sections of text and sections of control and non-printing characters (apparently code, or file structure info). Do I need a special program to access the contents of these files? Could you give me some hints of the format and contents of the ARxx files? Thanks for any help you can give. -jp  Date: 24 November 1982 19:14-EST From: Ed Schwalenberg Subject: Great idea for program To: ALAN at MIT-MC cc: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC What I wanted is a program that would do the calls in itself, assuming that this was to be used for simple stuff like my example. However, it would be useful to be able to do it in another arbitrary inferior, so I applaud your proposed extension.  Date: 24 November 1982 04:10-EST From: Alan Bawden Subject: Great idea for program To: ED at MIT-MC cc: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC One way to write this tool would be to use the SYSCALL function in MacLisp. Actually there is a problem that a lot of system calls have side effects on specific jobs. (Like the :IOPEN kludge opens a channel \in the current job/.) What you REALLY want then is a DDT command that does what you said, but in the current job. [The idea is to replace the sequence of commands that usually starts by typing "JJ 100/.CALL 200" with something like "JJ :DOCALL" right?]  Date: 24 November 1982 03:25-EST From: David C. Plummer Subject: Great idea for program To: ED at MIT-MC cc: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC Interesting idea, but I don't think I'd say great. (This idea comes from having spent a ridiculous amount of time trying to find out the TTYSMT variable of a tty.) That's easy: SYS^K TTYSMT+/ It's also in CNSGET, and I think it may be in TTYVAR (even though :CALL doesn'tdocument it).  Date: 24 November 1982 03:13-EST From: Ed Schwalenberg Sender: HDT at MIT-MC Subject: Great idea for program To: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC :DOCALL prompts for a system call name, prints the relevant documentation from ITS .CALLS, and prompts the user for the arguments to the call, with special magical abilities to cons up , , etc. type args, or open channels in the fashion of :IOPEN. It then executes the call, and types out the values for you, or types out the error code if it failed to work. (This idea comes from having spent a ridiculous amount of time trying to find out the TTYSMT variable of a tty.)  Date: 23 November 1982 20:37-EST From: Ken Harrenstien To: BUG-ITS at MIT-MC I installed a new KSC;HOSTS2 BIN compiler. If problems ae experienced with the current SYSBIN;HOSTS2 >, then use KSC;HOSTS2 OBIN.  Date: Monday, 22 November 1982, 03:27-EST From: Richard M. Stallman To: KLH at MIT-MC, EAK at MIT-MC Cc: BUG-ITS at MIT-MC I used to keep the source for any one program on only one machine. It used to cause continual lossage to have any file in two places. It's up to the people working on ITS, and maybe you can make it work out, but don't assume things will work with multiple copies of sources unless you are very careful.  Date: 21 Nov 1982 2231-EST From: KLOTZ at MIT-OZ at MIT-MC Subject: dover To: bug-its at MIT-OZ at MIT-MC Maybe there should be a program to hack the dover status so people don't have to go read .dovr.;%dover broken which tells them to create a file called .dovr.;.dovr. notice, which is different from .dovr.;.dovr.;broken, which they need to create too, but then have to gun the server (if they can figure out what the user name is)... ELLEN told me that when the dover goes down people still queue things on MC and gobble up disk space. Few people know how (or take the trouble to) stop the server on MC, possibly because it's so complicated. Leigh. -------  Date: 21 November 1982 02:43-EST From: Ed Schwalenberg Subject: Re: MASTER mode screwing up TTY handling, but good! To: RWK at SCRC-TENEX cc: PGS at MIT-MC, BUG-ITS at MIT-MC While I guess I can see that the superior would get no cycles at all, that still doesn't explain the wedgitude of the STY's. DCP and I had fun for hours, trying to figure out how to unscrew things without being able to log in. I finally got it unwedged by halting and continuing AI, but had to walk over to Tech Sq. to do it, which is cheating...  Date: 20 Nov 1982 1925-EST From: Robert W. Kerns Subject: Re: MASTER mode screwing up TTY handling, but good! To: PGS at MIT-MC, ED at MIT-MC cc: BUG-ITS at MIT-MC, RWK at SCRC-TENEX In-Reply-To: Your message of 20-Nov-82 1855-EST PGS is right. Other jobs in the same tree receive no CPU time while the master-mode job is running. If it waits for I/O or pages, then they may get a quantum now and then. I noticed this years ago and learned to be careful. Play with antisocial toys, and you'll get your fingers burnt! -------  Date: Saturday, 20 November 1982 18:45-EST Sender: PGS at MIT-OZ From: PGS at MIT-MC To: Ed Schwalenberg Cc: BUG-ITS at MIT-MC Subject: MASTER mode screwing up TTY handling, but good! In-reply-to: The message of 20 Nov 1982 02:42-EST from Ed Schwalenberg I don't know, but when I tried MASTER mode once, it didn't look to me like TTY handling was screwed. It looked like the DDT just wasn't getting much of any CPU time.  Date: 20 Nov 1982 1313-EST From: Robert W. Kerns Subject: Re: Feature To: KLH at MIT-MC, BUG-ITS at MIT-MC cc: RWK at SCRC-TENEX In-Reply-To: Your message of 20-Nov-82 1253-EST Sounds like an excellent idea. Terminal 0 and/or whatever terminal is the system console should probably be left alone, hardwired, though. Perhaps this can be done by a demon loaded at startup, which simply uses a special system call to copy the info? Perhaps this call should only work once, and then enable non-system-console terminals, and cause the ITS IN OPERATION message to be printed when it is done. This would prevent clobbering terminals already in use. Alternatively, it could be careful and ignore terminals which are in use. This would minimize the amount of EXEC code and debugging. -------  Date: 20 November 1982 12:41-EST From: Ken Harrenstien Subject: Feature To: BUG-ITS at MIT-MC cc: KLH at MIT-MC ITS should probably read a binary parameter file on startup to initialize its TTY tables rather than having them built in. This table can be maintained by a simple utility program that grovels over a source file, like HOSTSn does for HOSTS >. The network code will need to do something similar in order to initialize its gateway tables. If no objections, I may go ahead and do this.  Date: 20 November 1982 02:42-EST From: Ed Schwalenberg Subject: MASTER mode screwing up TTY handling, but good! To: BUG-ITS at MIT-MC I should know better than to frivolously show people MASTER mode, but anyway... Proceeding a job in Master mode without the TTY causes output on that TTY to be wedged, in that the * that DDT echoes after ^P never happens. Output from comm links continues to work, however. Now for the real killer: if that tree is then detached, the poor sucker who reowns it gets wedged, just by reowning it (his HACTRN says :$ Reowned $, then nothing more.) Stealing MASTER mode away, by grabbing it in another process, results in the wedged jobs continuing as if nothing had happened. This was all on MC, just now, version 1283. I tried to do the same thing on AI, to determine whether it was KL-specific, and discovered to my horror that not only does the same bug exist, but it apparantly wedges ALL sty's, since I was unable to log in again to clean up, being told that All network ports were in use! (The original hackery was also via a STY, by the way; from the SIPB plasma tv, to be specific.)  Date: 19 November 1982 19:23-EST From: Richard Brenner To: BUG-ITS at MIT-MC When trying to :move a file into an archive that (unknown to me) was full (no free files), I encountered the error -CHANNEL NOT OPEN This message was a little too obscure to be helpful to me, and it took KLH a few minutes to figure out what was happening. I clearer error message would have helped quite a lot.  Date: 17 November 1982 22:05-EST From: Ken Harrenstien To: EAK at MIT-MC cc: BUG-ITS at MIT-MC Date: 17 November 1982 21:00-EST From: Earl A. Killian I thought that sources were only supposedly to exist on one machine so that you never get copies out of sync and need to do merging. Thus, if you copied things from AI to MC, you should delete them from AI. Not necessarily, the main thing is to make it clear where the canonical source actually lives, normally in a comment at the start of the source file. I don't think it would be a good idea to have any machine (esp AI) totally without sources.  Date: 17 November 1982 21:00-EST From: Earl A. Killian To: CSTACY at MIT-MC cc: BUG-ITS at MIT-MC I thought that sources were only supposedly to exist on one machine so that you never get copies out of sync and need to do merging. Thus, if you copied things from AI to MC, you should delete them from AI.  Date: 17 November 1982 02:07-EST From: Ken Harrenstien Subject: Can't get there from here. To: DCP at SCRC-TENEX cc: BUG-ITS at MIT-MC, rp at SCRC-TENEX, rll at SCRC-TENEX I rebooted the front-end 11 per MOON's instructions about 2 hours ago. Local terminals were badly wedged, although Chaosnet connections seemd to be going through okay; it was however complaining periodically that no more chaosnet buffers were available. A typical example of wedgedness is that echo on the VT52 next to the console was at least 20 chars behind typein, and some typein seemed to be getting lost or at least processed in random spurts (only when one had pumped enough chars at it would anything happen). The rebooting seems to have fixed everything for now. Moon apparently thinks that the Dover spooler might have had something to do with the overall problem, but you'd have to ask him for any details. Something was very obviously clobbered in the 11. Perhaps when the Chaosnet goes wild, something overflows into the TTY buffers/pointers or otherwise throws a big wrench into the works? Pure speculation, I'm not familiar with it. It might even be the other way around, that some glitch in TTY handling (owing to the preponderance of "loose lines" blasting noise at the front-end) is screwing up not only the TTYs but the Chaosnet.  Date: Wednesday, 17 November 1982, 01:52-EST From: David C. Plummer Subject: Can't get there from here. To: bug-its at mc Cc: rp at SCRC-TENEX, rll at SCRC-TENEX I had a chaos connection to MC die on me tonight. (RP has complained that he gets about two per day.) When it happened to me I did some quick poking and the MC-IO-11 was not responding to STATUS but other hosts on subnet one were. MC is now up (and has been for 14 hours) so it looks like the 11 crapped. A couple nights ago TAFT called me for instructions on how to reload the 11. Is this flaking out becoming regular? Does the person(s) reloading it remember anything special about the circumstances (11 halted or running, ampex parity, dl10 parity, etc).  Date: 13 November 1982 20:37-EST From: Christopher C. Stacy To: BUG-ITS at MIT-MC PEEK automagically purifies and dumps out itself if necessary now.  Date: 13 November 1982 13:28-EST From: Ed Schwalenberg Subject: T21 as well... To: BUG-HARDWARE at MIT-MC cc: BUG-ITS at MIT-MC has been silenced.  Date: 13 November 1982 13:24-EST From: Ed Schwalenberg Subject: MC T32 emitting continuous garbage. To: BUG-HARDWARE at MIT-MC cc: BUG-ITS at MIT-MC I set the linespeed to 0 to disable T32, which was typing garbage at the system. Is there any documentation for LSPEED? I went blithely ahead and assumed that it worked like a reasonable program, but it would be nice to know. It would be similarly nice if the same programs worked for all known TTY types, but this is rapidly becoming a dead issue.  Date: 13 November 1982 23:18-EST From: Christopher C. Stacy To: BUG-ITS at MIT-MC There were a number of program sources which did not exist or were out of date on MC. I brought them up to date from the ones on AI, putting the overflow in the new SYSEN2; directory. MC should now be reagrded as the home of the most recent system program sources. I moved the BUG-ITS mailing list to MC, and updated pointers to it on AI, ML, and DM. The other bug-random-programs are still on AI. A copy of the AI NAMES file is in MC:KSC;AI NAMES. Chris  KLH@MIT-MC 11/13/82 01:15:28 Re: another SRCCOM feature To: (BUG ITS) at MIT-MC, (BUG SRCCOM) at MIT-MC I hope this isn't bothering BUG-ITS people, but since I developed this feature to help hack ITS I figure I might as well continue with the SRCCOM announcements. I added the /$ switch which does a binary compare like /# but with the difference that the files must be executable programs; SRCCOM will create two inferior processes and load the files into them in order to compare the two address spaces. This completely flushes any spurious diffs due to symbols, MIDAS info, blocking size, or SBLK/PDUMP format. Doesn't handle holey processes though; maybe later. I updated INFO;SRCCOM > on MC. I'm going to move the canonical location of SRCCOM to MC, I think.  Date: 12 November 1982 23:08-EST From: Christopher C. Stacy To: BUG-ITS at MIT-MC I am adding some features to PEEK which will be useful for TCP/IP debugging. I added the trivial "+" mode today, sort of as practice. Installed on MC.  KLH@MIT-MC 11/12/82 13:05:17 Re: Binary compare feature To: (BUG ITS) at MIT-MC, (BUG SRCCOM) at MIT-MC I have installed a new SRCCOM on MC with a crude binary compare feature. Use switcch /# to compare two files word by word. Interaction with other switches is likely to kill things. If nobody (mostly me, I guess) finds problems with it over the next few days, I'll install it in other places. Note that two different assemblies of the same sources will not produce identical binaries, because of the extra info that MIDAS puts in about who assembled it when. I'm not sure yet how to bypass this.  Date: 11 November 1982 22:22-EST From: Christopher C. Stacy To: DCP at MIT-MC cc: BUG-ITS at MIT-MC, KMP at MIT-MC, THREE-MINUTE-HATE at MIT-MC, Eric at MIT-EECS I made a mailing list for discussing some of the random ideas inspired by DCP's message about ITS on a VAX. It doesnt have to be just about VAX ITS, but it prevents message duplication and gets it off BUG-ITS. Here's what the mailing list looks like now: (VAX-ITS (EQV-LIST (FILE [DSK:CSTACY;VAXITS ARCHIV]) CSTACY DCP PGS ALAN KMP GUMBY DANNY KLH KLOTZ HAL GREGOR CENT ZVONA RMS DEVON)) Feel free to add yourself... Chris  Date: 11 November 1982 20:44-EST From: David C. Plummer To: KMP at MIT-MC cc: BUG-ITS at MIT-MC, THREE-MINUTE-HATE at MIT-MC, Eric at MIT-EECS [[Sorry for the message duplications...]] KMP@MIT-MC 11/11/82 17:46:24 better than teach ITS, you should get a crew together and bring one up. Unfortuantely that would require the cooperation of the owner(s) of a machine up on which (garp) to bring it. Here are the options I know of: There are rumors of the AI lab looking for a used -10 (KL probably) to appease the people who can't stand 20X and would prefer ITS. This would be an idea machine. Bring up ITS on an existing PDP-20. The only machine this is feasible on is OZ, and the feasibility of that seems to be asymptotically approaching zero (unless you want to pull of a coop some night). This would also require some microcode expertise. Moon obviously comes to mind. His commitment at symbolics also comes to mind. Bring it up on a non-10 architecture. This would be a lot of fun. The obvious choice is a vax. OK, who has the vax, who has the time, and who has the money to sponser such a moderate project? (Be prepared to be able to answer "What's wrong with Unix?" I'm sure each one of us can give some very good answers, but just be prepared.) TK actually suggested writing a report on ITS which described its winnages (.HANG for example) and its lossages (6 character, non-hierarchical filenames).  KLH@MIT-MC 11/11/82 08:26:16 Re: Comsat address & NAMES > To: JPG at MIT-MC CC: CBF at MIT-MC, (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC If I have some spare time during this TCP hacking, I can look into this. The problem is not really that NAMES is so big, but that COMSAT is so stupid about how it handles the compiled result. There are at least three things I can think of right away that would help eliminate this problem (this does not mean they are easy to do). For the time being, keeping NAMES small ought to buy enough time.  JPG@MIT-MC 11/11/82 05:58:39 Re: Comsat address & NAMES > To: CBF at MIT-MC CC: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC CBF@MIT-MC 11/07/82 16:23:34 Re: Comsat address & NAMES > To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC CC: JPG at MIT-MC It seems that the only solution to the address space problem that avoids removing mailing lists right and left is to move the bulk of their contents into separate files and put entries in that are only (@FILE ...). Anyway, the problem with just going through NAMES > and arbitrarily moving mailing lists into files is figuring out where to scatter all these lists to. They presumably each do have individual sponsers, but it is quite an effort to encourage each person to remove a mailing list to his own directory. Considering what a bad idea it is to have COMSAT crashing all the time, I would therefore suggest that a precious MFD slot be given over to this purpose... I have no objection to this, but I wish to point out that at least recently people have been cleaning out the NAMES file to the point where it is now just(?) 19 blocks, and COMSAT has been crashing much less frequently. Ah, but will this state last?  KLH@MIT-MC 11/10/82 15:50:51 Re: prev msg To: (BUG ITS) at MIT-MC Hmm, there is no longer a MIT-NET-CONNECT list. I forwarded the note to MIT-IN-GROUP and MIT-NETWORK-GROUP instead. Just in case anyone tries to reply to all recipients...  KLH@MIT-MC 11/10/82 15:44:32 Re: ITS TCP is coming... To: (BUG ITS) at MIT-MC, MIT-NET-CONNECT at MIT-MC I am now officially working on the installation of TCP/IP in ITS. The ITS sources in MC:SYSTEM; should be considered write-locked as of today; if you need to make some changes, see me to fold them in. Likewise, if you know that these sources are for some reason NOT the latest stuff, tell me immediately. Ditto any patches that haven't yet been put in the source. If more than a couple of people are interested in following the progress of this stuff, I will create a mailing list to keep them posted and possibly to solicit opinions on certain design issues. Here we go, folks!  Date: 9 November 1982 18:38-EST From: David C. Plummer To: CSTACY at MIT-MC cc: BUG-ITS at MIT-MC, Bug-Twenex at MIT-XX Date: 9 November 1982 17:40-EST From: Christopher C. Stacy The system ran out of ARPAnet sockets (I think) and would not accept incoming TELNET connections. Other sites seemed to think MC had died. I looked, and there were about a dozen 054Jnn NETRFC jobs hung in CLFSH->XX/RDCLS<-XX. They were all doing a FINISH call at 12527. I gunned most of them down. I dont know what this frob is for, but ALAN looked at the job and thinks it some sort of BOJ handler for something to do with the DOVER, like RFC133. What was this job, and I wonder why there were all these hung ones? Yes. These are wedged XX jobs. When I frequented MC I would typically find several in one day. Either ITS has a bug closing connections, or XX has the bug (perhaps both). I don't know NCP so I don't know if the above state is reasonable.  Date: 9 November 1982 17:40-EST From: Christopher C. Stacy To: BUG-ITS at MIT-MC The system ran out of ARPAnet sockets (I think) and would not accept incoming TELNET connections. Other sites seemed to think MC had died. I looked, and there were about a dozen 054Jnn NETRFC jobs hung in CLFSH->XX/RDCLS<-XX. They were all doing a FINISH call at 12527. I gunned most of them down. I dont know what this frob is for, but ALAN looked at the job and thinks it some sort of BOJ handler for something to do with the DOVER, like RFC133. What was this job, and I wonder why there were all these hung ones?  CBF@MIT-MC 11/07/82 16:23:34 Re: Comsat address & NAMES > To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC CC: JPG at MIT-MC It seems that the only solution to the address space problem that avoids removing mailing lists right and left is to move the bulk of their contents into separate files and put entries in that are only (@FILE ...). I presume an @FILE takes up much less space than several name in a mailing list. Anyway, the problem with just going through NAMES > and arbitrarily moving mailing lists into files is figuring out where to scatter all these lists to. They presumably each do have individual sponsers, but it is quite an effort to encourage each person to remove a mailing list to his own directory. Considering what a bad idea it is to have COMSAT crashing all the time, I would therefore suggest that a precious MFD slot be given over to this purpose. The names LISTS seems approriate, and it can store lists and collect log files for otherwise homeless mailing lists. This would also provide a nice central place to look at when some disk storage is needed (ie. by trimming old log files), which could actually result in less disk storage being used by log files. I'm not volunteering to do this quite yet, but if I don't hear any objections I may create the dir and start to do this at idle moments when I'm bored.  CSTACY@MIT-MC 11/04/82 03:21:10 To: (BUG ITS) at MIT-MC The pile-driving every few minutes at all hours outside Tech Square is apparently the cause of a very gross number of T-300 failures and problems on the CADRs. It seems to be shaking them to death, crashing heads and doing other bad things. I noticed that there were quite a few disk errors happenning on MC tonite. Is it likely that any of these are being caused by the vibrations from outside?  KLH@MIT-MC 11/03/82 19:13:57 To: PGS at MIT-ML CC: (BUG ITS) at MIT-MC PGS@MIT-ML 11/03/82 08:59:39 ML ITS 1278 has been running for 33 days now. Is this a record? (It certainly is on ML). I think AI holds the record, something like 80 days. The max uptime is stored in the creation date of SYS:RECORD TIME on each machine, starting from 0/0/00.  PGS@MIT-ML 11/03/82 08:59:39 To: (BUG ITS) at MIT-ML ML ITS 1278 has been running for 33 days now. Is this a record? (It certainly is on ML).  MP@MIT-MC 11/02/82 14:37:25 Re: size of MC's mailing list file To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC I sent some messages to a few lists that have been dormant for a few years. At the very least I hope to cut out some invalid addresses, and with luck maybe a few lists can be flushed. There are several lists that don't seem to have a clear maintainer, (for instance, the chaosnet, bikes, c100-fans, calculators, and multics-emacs lists); if they were to be moved into some indirect file in someone's directory, it isn't obvious who that someone should be. It would be nice to have a nice, non-volatile directory (USERS* and GUEST* I consider volatile) to put assorted indirect files in.  MOON@MIT-MC 10/31/82 19:33:49 To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC I need to repeat my message saying that there will be no mail service on MC if the NAMES file is not made smaller. It is completely filling Comsat's address space.  Date: Tuesday, 26 October 1982, 11:27-EDT From: Patrick Sobalvarro Subject: ai down? To: CENT at MIT-ML, phw at MIT-OZ, eric at MIT-EECS, bug-its at MIT-MC CENT@MIT-ML 10/26/82 04:47:18 Re: ai down? To: (BUG ITS) at MIT-ML i tried to supdup from ml to ai, by saying ai^H. after giving me the fallacious run-around about using the arpanet twice (because i was using ml from a chaos tip), it reported Host Dead. just to check, i tried :supdup ai /a. same result. however, ai was up durign this time. i was able to use it from its console. someone check this please? AI wasn't down; in fact, it was running perfectly. At 4:11 yesterday afternoon, JNC took AI off the Arpanet to screw with the tips or the tacs or whatever, and, well, he forgot to plug the boards back in. When I couldn't get to it this morning, TY said, "Oh, shit, that must have been Chiappa," and called him up and got him to fix it. The AI-10 is the AI Lab's only Arpanet socket, and lots of people indirect through it to get their net mail to OZ. Lots of important mailing lists are on AI (including BUG-ITS). AI's Arpa port is important to this lab, and I wish there were a less casual attitude about fucking with it.  SHAWN@MIT-ML 10/26/82 06:38:45 Re: ":alarm" To: (BUG ITS) at MIT-ML Does the ":alarm" command REALLY work? it seems it does the "wrong" thing for me all the time, (i.e. ":alarm .+00:" works, and it takes it, not only that, but ":alarm .+01:" sets for ".+17:23:55" when its 06:36:10am?), anyone care to explain what I am doing wrong? if anything? Thanks -shawn  CENT@MIT-ML 10/26/82 04:47:18 Re: ai down? To: (BUG ITS) at MIT-ML i tried to supdup from ml to ai, by saying ai^H. after giving me the fallacious run-around about using the arpanet twice (because i was using ml from a chaos tip), it reported Host Dead. just to check, i tried :supdup ai /a. same result. however, ai was up durign this time. i was able to use it from its console. someone check this please?  Date: 22 October 1982 03:56-EDT From: David C. Plummer Subject: [Forwarded: COMSAT, Re: ] To: BUG-ITS at MIT-MC Sorry, I can't spel... ------------------------------ COMSAT@MIT-MC 10/21/82 23:30:41 Re: Msg of Thursday, 21 October 1982 23:27-EDT To: DCP at MIT-MC A copy of your message is being returned, because: "BUT-ITS" at MIT-MC is an unknown recipient. Message not sent. Failed message follows: ------- Date: 21 October 1982 23:27-EDT From: David C. Plummer To: BUG-OZ at MIT-MC cc: BUT-ITS at MIT-MC, MT at MIT-MC, ERIC at MIT-MC There is a theory that part of the OZ wait-30-seconds problem is that the AI-Chaos-11 does not always have the power to bridge between subnets 6 and 1. If chaos sites think that ai-chaos-11 is the best route, when indeed it cannot route, then there will be a stalling effect until either ai-chaos-11 unwedges or mc-io-11 becomes the best route. This could take 15 to 30 seconds depending on how wedged ai-chaos-11 is. If this is the problem, then I may have improved the situation. I have modified the program that runs in ai-chaos-11 to give a higher cost for the cable subnets than mc-io-11. This should cause subnet 6 sites to always use mc-io-11 to get to subnet 1 and vice-versa (except of course when mc-io-11 is down, in which case the routing mechanism will figure out ai-chaos-11 can get there). This will take effect at the next reload of ai-chaos-11 (which happens to be down right now meaning no dover service to chaos sites). The correct solution, of course, is to put the oz-network-11 on subnet 6 as well as subnet 1. This is not happening due to a lack of hardware (unibus chaos interfaces).  DCP@MIT-MC 10/21/82 00:09:16 To: (BUG HOST) at MIT-MC, (BUG ITS) at MIT-MC I modified :HOST so that it now accepts multiple host as arguments, separated by commas. E.g., :HOST MC,AI,ML,DM  MOON@MIT-MC 10/19/82 00:13:43 To: (BUG ITS) at MIT-MC .;crash chaos is a crash where the system ran out of chaos buffers and got slow (so I'm told). All the buffers but one I could find were UNC's from BAK DOVER to socket 21 (octal) on the Dover Alto. Perhaps the IO-11 had really crashed, and that's why it wasn't swallowing the packets. Perhaps ITS should notice when the number of packets on DLCXMQ gets large and start throwing them away.  Date: 18 Oct 1982 2111-EDT From: J. Noel Chiappa Subject: [Ben Littauer : Re: TAC/ITS telnet bug?] To: bug-its at MIT-AI Mail-from: ARPANET site MIT-MC rcvd at 18-Oct-82 1844-EDT Date: 18 Oct 1982 18:38:41 EDT (Monday) From: Ben Littauer Subject: Re: TAC/ITS telnet bug? In-Reply-to: Your message of 14 Oct 1982 17:23:47 EDT (Thursday) To: Ben Littauer Cc: moon at SCRC-Tenex at MIT-MC, EAK @ mit-mc, REM @mit-mc, frye at BBN-UNIX, ditmars at BBN-UNIX, herman at BBN-UNIX, JNC at mit-mc Good News! (again) Well, the last patch wasn't QUITE enough, but we were on the right trail. REM apparently had his hopes dashed this weekend when SU-TAC continued displaying THE BUG. Further testing and reading of spagetti code proved beyond a shadow of a doubt that the "wedging" occurred when ITS sent the TELNET IAC character in one message, and followed with the DataMark in the next. Thumbing through the coroutines eventually showed that we were returning wrong in this case. I have a patch, already in SU-TAC, which will be released to the rest of the net tomorrow morning. It still is possible that there is some other case which causes wedging, so I won't claim that it can't happen again, but I don't think that it will. Sorry for the first false hopes, hope this one works... -ben- -------  Date: 16 Oct 1982 1629-EDT From: J. Noel Chiappa Subject: [Ben Littauer : Re: TAC/ITS telnet bug?] To: bug-its at MIT-MC Mail-from: ARPANET site MIT-MC rcvd at 14-Oct-82 1818-EDT Date: 14 Oct 1982 17:23:47 EDT (Thursday) From: Ben Littauer Subject: Re: TAC/ITS telnet bug? In-Reply-to: Your message of 14 Oct 1982 11:26:31 EDT (Thursday) To: Ben Littauer Cc: moon at SCRC-Tenex @ MIT-MC, EAK @ mit-mc, REM @mit-mc, frye at BBN-UNIX, ditmars at BBN-UNIX, herman at BBN-UNIX, JNC at mit-mc Good news! I found a local ITS afficionado, and with his help I was able to get the bug to happen. I discovered that what was happening was that the TAC would receive an NCP INS, which TELNET needs as a signal to start discarding terminal output, but it was not finding a matching TELNET DataMark in the data stream, the signal to STOP discarding terminal output. The funny thing was that the symptoms were so intermittent. Reading the TAC code, I found that if we receive a message containing the TELNET intercept character, IAC, in one message, and the DataMark was the first character of the next message, then the TAC would fail to see the DataMark. I have patched my test TAC and have since been unable to re-create the bug. I therefore hypothesize that ITS will occasionally send the IAC in one message and the DataMark in another: can any ITS network hackers verify or refute this? ARPANET TACs should have received the patch by tomorrow morning, so I would greatly appreciate hearing whether there is indeed a difference. It is possible that this fix will also cure the flakiness seen in negotiating TELNET binary mode with the TAC; anybody who has experienced those difficulties, PLEASE tell me if there is any change. I'm sorry this bug has been hanging (no pun intended) around so long, but I thank you for your patience and perseverence; we do want to hear about bugs, and we try to fix them as soon as possible, but the ones that people are finding now are getting to be the more subtle ones, so they do take longer... Your friendly neighborhood TAC "wizard". -ben- -------  CSTACY, PGS, ELLEN@MIT-MC (Sent by CSTACY@MIT-MC) 10/15/82 15:13:08 Re: for future reference To: (BUG ITS) at MIT-MC MC would not come up this afternoon due to some sort of lossage in the T300 subsystem. Running CHKR showed that it couldnt frob the T300s; power cycling unit 3 de-confused it and the system came up ok.  Date: Wednesday, 13 October 1982 05:31-EDT Sender: PGS at MIT-OZ From: PGS at MIT-MC To: DCP at MIT-OZ, bug-its at mc cc: twenex-haters at MIT-OZ AI is being backed up these days, and its disks seem fairly stable. The processor hardware is not currently flaking out, although we have no idea how long that will last. When I connect to it, often in the daytime, I am usually the only user using it. If we do indeed reconnect AI to the Chaosnet, then it'll make a pretty good mail computer, so I see no reason not to leave BUG-RANDOM-PROGRAM on it. Something we should take note of here is that Eric Ostrom, in his capacity as AI Lab Facilities Coordinator or some fancy title, has tracked down a KL Model A CPU (a la MC) that is being sold for $7500, supposedly in working order. The idea is to provide a machine of MC's power to AI lab members who prefer ITS to Twenex. If we bought one it would probably go where AI is now, both physically and spiritually (including network ports). Extra space would need to be allotted for memory; presumably 921 (Marty's office) would go away. Everyone who would like to see AI have a KL Model A running ITS should send a message to the effect to Eric@ee (not at OZ, where he doesn't read his mail), and CC it to PHW. Something strong along the lines of "I understand you're considering getting a KL to run ITS, well, do," is probably appropriate. -------  Date: 10 October 1982 23:52-EDT From: David A. Moon To: PGS at MIT-OZ cc: BUG-ITS at MIT-MC, akr at MIT-OZ Date: Sunday, 3 October 1982, 03:10-EDT From: Patrick Sobalvarro To: bug-its at MIT-OZ at MIT-MC Cc: akr at MIT-OZ at MIT-MC Alex Krymm (our new hardware person) has agreed to take a look at the prints for ML's Chaosnet interface and consider building one for AI. Questions: Is it really worth it? That is, will this just be a lot of thankless work for him? Or is it comparatively simple? Is someone who understands the hardware well around to answer the occasional question? I'll be happy to answer questions within the limited amount of time I have available. Would he have to do wirewrapping, or do we have wirelists that we can send to Augat? Of course not. It would be machine-wrapped. The only issue is finding documentation on the AI TTL I/O bus plus figuring out whether it is still there. It is unlikely to be 100% compatible with the ML/DM TTL I/O bus, hence the Chaosnet interface would need some small changes. If it's not still there it would need to be retrieved from wherever it went and hooked up again. I imagine Knight could help with this.  DCP@MIT-MC 10/10/82 14:19:44 To: (BUG ITS) at MIT-MC How willing are we to trust AI for mail? Specifically, should BUG- go to AI and probably end up in BUG-RANDOM-PROGRAM. Doing the conversion is not a trivial matter, since there are probably several lists which depend on this happening and winding up on AI. Alternatively, AI isn't doing that much as it is, so maybe that is a good place for the COMSAT computrons???  GJC@MIT-MC (Sent by GJC0@MIT-MC) 10/08/82 16:14:19 Re: The second most popular PDP-11 operating system on the NET? To: DCP at MIT-MC CC: (BUG ITS) at MIT-MC According to the FAX I gathered for SYSENG;HOSTS >, using NUMER;HOSTP, the most popular pdp-11 operating system on the "net" is UNIX, with 64 sites. The second most popular is MINITS with 27 sites.  Date: 8 October 1982 00:04-EDT From: Alan Bawden Subject: GENSYM servers??????? To: GJC at MIT-MC cc: BUG-ITS at MIT-MC Date: 7 October 1982 21:01-EDT From: George J. Carrette Re: GENSYM servers??????? yow You know about the YOW server on CCC? Give it a try.  GJC@MIT-MC 10/07/82 21:01:11 Re: GENSYM servers??????? To: ALAN at MIT-MC CC: (BUG ITS) at MIT-MC yow  Date: 7 October 1982 18:07-EDT From: Alan Bawden Subject: ON MC To: GJC at MIT-MC, DCP at MIT-MC cc: BUG-ITS at MIT-MC Date: 10/07/82 11:57:18 From: GJC We seem to have a lot of jobs like ___*** CHAOS GENSYM ...... MPV and ILOPR since people from Plasma have to lot in I'm going to gun these now. Maybe it is intermittent? I fixed the problem. When they rejected connections these GENSYM servers were POPJing off the bottom of the stack which generally caused them to jump into the accumulators...  GJC@MIT-MC 10/07/82 11:57:18 Re: ON MC To: (BUG ITS) at MIT-MC We seem to have a lot of jobs like ___*** CHAOS GENSYM ...... MPV and ILOPR since people from Plasma have to lot in I'm going to gun these now. Maybe it is intermittent?  Date: 7 October 1982 06:53-EDT From: David C. Plummer Subject: CPI numbers To: BUG-ITS at MIT-MC, ALAN at MIT-MC, Bug-TWENEX at MIT-XX cc: cm-i at MIT-OZ CHAOS EOF packets: There are two things going on here. First is that ITS will allow an EOF packet to be sent that has a non-zero bytelength for the data field. I don't think this is right. Second is that doing a TWENEX SIN JSYS on a chaos channel which has received an EOF will give you the bogus data in the EOF before signalling the end of file. Case in point: The gensym server on MC originally didn't set the byte length of the EOF, so twenex would print whatever happened to be in the packet at the time. For example, @type cha:mc.gensym_foobar 19EGSNMYF OOAB instead of just 19 To Alan and cm-i: The GENSYM server has been fixed to no tickle either bug.  Date: Wednesday, 6 October 1982, 06:07-EDT From: Robert W. Kerns Subject: archive device overload To: Alan Bawden Cc: BUG-ITS at MIT-MC, BUG-LMODEM at MIT-MC In-reply-to: The message of 2 Oct 82 16:58-EDT from Alan Bawden Date: 2 October 1982 16:58-EDT From: Alan Bawden 1) Is it really the case that there can't be more than about 8 jobdevices at any one time? I guess this is reasonable since there usually isn't any more than about 4 active at any one time. Yes. 2) I hope that the LMODEM program is taking the proper precautions to prevent the user from using up infinite channels. The maintainers should spend a minute or two thinking about correctly unwind-protecting their program so that this can't happen if they haven't already (in which case they should think about possible bugs). In this case, it isn't LMODEM's problem. They're staying around after LMODEM's channels have been closed. 3) What are archive devices waiting for when they go to sleep? Normally they seem to hang. These behaved as if they were waiting for a lock to free up. (The fact that they all disappeared after I gunned a couple presumably indicates that archive devices take the correct actions to insure that locks will be unlocked when jobs get killed.) Is there some sort of deadly embrace that is known to happen? Usually they're waiting for the lock to be freed that is held by whichever one of them that got the error. Generally, the error is a clobbered archive. It used to be true, may still be true, that having the archive too large to map would cause it to be permanently broken in this way. 4) Since the job on the user end of the job channel had gone away, shouldn't the job devices have been told about it? I don't find anything specific in the job device documentation about what happens when the user goes away, but I thought that the system simulated a .CLOSE on any channels associated with any terminated jobs, but this would have cleaned things up wouldn't it? (I just tried this myself, and that seems to be the case...) Yes, but the ARCHIVE device doesn't allow any of this until it's gotten the lock. 5) Perhaps the .SLEEP that the archive device is using (where?) shouldn't be forever, but instead it should wake up every five minutes and be sure it still has a reason to live. Something like that.  Date: Sunday, 3 October 1982, 03:10-EDT From: Patrick Sobalvarro To: bug-its at MIT-OZ at MIT-MC Cc: akr at MIT-OZ at MIT-MC Alex Krymm (our new hardware person) has agreed to take a look at the prints for ML's Chaosnet interface and consider building one for AI. Questions: Is it really worth it? That is, will this just be a lot of thankless work for him? Or is it comparatively simple? Is someone who understands the hardware well around to answer the occasional question? Would he have to do wirewrapping, or do we have wirelists that we can send to Augat?  Date: 3 October 1982 02:11-EDT From: Pandora B. Berman Subject: Lord of Light reincarnated To: BUG-ITS at MIT-AI cc: ALAN at MIT-AI with advice from moon and much assistance from alan (who did most of the actual work), Puff-The-Magic namedragon has been copied over from ML to do namedragonish things like keeping track of logout times. apparently the LOGOUT TIMES file has not been written to since the knight tvs were last patched out (presumably Taraka Namdrg wants to display on them before modifying the file?). we first considered patching Taraka Namdrg to not try to write out to the knight tvs, but that proved much too hairy.  Date: 2 October 1982 16:58-EDT From: Alan Bawden Subject: archive device overload To: BUG-ITS at MIT-MC, BUG-LMODEM at MIT-MC I noticed that my attempts to use the DIR device were reporting DEVICE FULL errors, and since the system was far from full I deduced that we had run out of some resource specific to jobdevices. Sure enough, there were eight or so sleeping archive devices. They were all associated with a nonexistant job that had presumably once been named LMODEM. (Although PEEK could have been mistaken about this if the job number had been recycled, the fact that they were all using an archive on the CPM directory backs this up.) I gunned a couple of them and suddenly the rest disappeared. I have several questions: 1) Is it really the case that there can't be more than about 8 jobdevices at any one time? I guess this is reasonable since there usually isn't any more than about 4 active at any one time. 2) I hope that the LMODEM program is taking the proper precautions to prevent the user from using up infinite channels. The maintainers should spend a minute or two thinking about correctly unwind-protecting their program so that this can't happen if they haven't already (in which case they should think about possible bugs). 3) What are archive devices waiting for when they go to sleep? Normally they seem to hang. These behaved as if they were waiting for a lock to free up. (The fact that they all disappeared after I gunned a couple presumably indicates that archive devices take the correct actions to insure that locks will be unlocked when jobs get killed.) Is there some sort of deadly embrace that is known to happen? 4) Since the job on the user end of the job channel had gone away, shouldn't the job devices have been told about it? I don't find anything specific in the job device documentation about what happens when the user goes away, but I thought that the system simulated a .CLOSE on any channels associated with any terminated jobs, but this would have cleaned things up wouldn't it? (I just tried this myself, and that seems to be the case...) 5) Perhaps the .SLEEP that the archive device is using (where?) shouldn't be forever, but instead it should wake up every five minutes and be sure it still has a reason to live.  Date: Saturday, 2 October 1982, 10:31-EDT From: Robert W. Kerns Subject: [MINSKY at MIT-OZ: clucftp] To: Christopher C. Stacy Cc: Bug-Twenex at MIT-XX, Bug-ITS at MIT-MC, MINSKY at MIT-OZ In-reply-to: The message of 2 Oct 82 04:26-EDT from Christopher C. Stacy Date: Saturday, 2 October 1982, 04:26-EDT From: Christopher C. Stacy This is reproducable. Anyone have any ideas why? Date: 30 Sep 1982 0032-EDT From: MINSKY at MIT-OZ Subject: clucftp To: cstacy at MIT-OZ cc: minsky at MIT-OZ When I use "get" to MC, it complains "bad format packet recieived". It used to work. Has anything changed? Possibly because of the addition of the AUTHOR to the OPEN response?  Date: Saturday, 2 October 1982, 04:26-EDT From: Christopher C. Stacy Subject: [MINSKY at MIT-OZ: clucftp] To: Bug-Twenex at XX, Bug-ITS at MC This is reproducable. Anyone have any ideas why? Date: 30 Sep 1982 0032-EDT From: MINSKY at MIT-OZ Subject: clucftp To: cstacy at MIT-OZ cc: minsky at MIT-OZ When I use "get" to MC, it complains "bad format packet recieived". It used to work. Has anything changed? -------  Date: 30 Sep 1982 2002-EDT From: J. Noel Chiappa Subject: [Ben Littauer : TAC/ITS telnet problems] To: bug-its at MIT-MC Mail-from: ARPANET site MIT-MC rcvd at 30-Sep-82 1601-EDT Date: 30 Sep 1982 15:52:57 EDT (Thursday) From: Ben Littauer Subject: TAC/ITS telnet problems To: REM at mit-mc, POURNE at mit-mc, EAK at mit-mc, JNC at mit-mc Cc: frye at BBN-UNIX, ditmars at BBN-UNIX, clifford at BBN-UNIX, littauer at BBN-UNIX There has been a lot of traffic recently about this TAC/ITS telnet bug. There are many misconceptions about what is going on in the TAC, and I can only assume that much of the speculation I see about what ITS is doing is also wrong. I am currently looking into this problem, and trying to sort out the facts. It would be helpful if I had a contact at MIT who could get me access to and account on MIT-MC and who would KNOW what MC is supposed to do in these funny situations. Any volunteers? I expect to be doing some investigation during this coming week. I can be reached via netmail or at BBN (497-3196). One major confusion about the TAC relates to its buffer sizes. The TAC has static buffering on input and dynamic buffering on output, and both input and output buffers are relatively small. The TIP's buffers could be of any size, depending on the configuration of the machine. The TAC does not have, nor will it ever have, 1000 character buffers for 63 terminals in a 32K word machine... -ben- -------  Date: 28 Sep 1982 2119-EDT From: J. Noel Chiappa Subject: Re: Anyone know why ITS got unfriendly? To: EAK at MIT-MC, POURNE at MIT-MC cc: BUG-ITS at MIT-MC, JNC at MIT-XX In-Reply-To: Your message of 28-Sep-82 2026-EDT I'll forward your message to the TAC maintainer, Clifford@BBN-UNIX, and see what we get back. -------  Date: 28 September 1982 20:26-EDT From: Earl A. Killian Subject: Anyone know why ITS got unfriendly? To: POURNE at MIT-MC cc: BUG-ITS at MIT-MC Because the TACs (the new TIP) seem to misimplement to TELNET protocol. When ITS tries to flush the data in the network using the same method that works on TIPs it causes things to come to a grinding halt. I suspect someone just removed the code that attempts to do the flushing as begin better than wedging.  GJC@MIT-MC 09/27/82 16:57:13 To: (BUG ITS) at MIT-MC I've noticed a funny intermittent bug from local MC terminals today. The characters "IOB" sometimes end up in the input stream randomly when other keys are typed. I've noticed this both on TTY 31 and on the VT52 near the system consol on the 9'th floor.  dcp, alan@MIT-MC (Sent by DCP@MIT-MC) 09/25/82 03:56:43 Re: What is the value of L?? To: (BUG ITS) at MIT-MC On MC ITS 1278, right now!! sys^K l= 134007 What!!!! This causes :VV to break, but that's a minor detail at this point. I loaded @ ITS and @ NITS into a job and L was 1000 as expected. I guess somebody decided to take a walk through the in core symbol table. LUBLK is still 1000 (thank god, otherwise PEEK would also be broken). (On ML and DM it's 742, and AI is 745.) Fixed in the running system (without knowing (or finding) where the symbol table is in memory).  Date: 24 September 1982 09:49-EDT From: Christopher C. Stacy Subject: ai namedragon To: CENT at MIT-AI cc: BUG-ITS at MIT-MC There being no TV-11 anymore, I retired the name dragon.  Date: 24 September 1982 04:12-EDT From: Pandora B. Berman Subject: ai namedragon To: BUG-ITS at MIT-AI for at least the past few weeks, taraka has been consistently hanging onto whatever verion of lsr1 was lsr1 1 when taraka was started up. that is, taraka is NOT checking at intervals for a newer version and releasing the old one to be deleted. it seems the only way to change tarka's idea of what is the current version of the database is to gun taraka and start a new one. this is much less than optimal. please investigate.  Date: 23 September 1982 03:28-EDT From: David C. Plummer Subject: Whither XGP? To: GUMBY at MIT-MC cc: PGS at MIT-MC, BUG-ITS at MIT-MC, DLW at MIT-OZ [Is BUG-ITS the right place for all of this??] My Versatec spooler understands KST files; it has nothing to do with the Versatec. If you read DCP;PRESS ANOUNC you will see that when the Versatec spooler TRIES to do press files, it translates the press fonts into somee (hopefully) reasonable XGP font. If you are trying to get closer to the state of the art, flush XGP format files. In theory (if I turned on XGP file recognition in the spooler), XGP files produced by R come out correctly, but XGP files produced by TJ6 or BOLIO (and I think @) cause it to crash. This is interesting, becuase the :DOVER program does the exact opposite (does everything (as far as I can tell) EXCEPT R produced XGP files). "Well, why don't you look at :DOVER to see how it does it?" you might ask. I did; it is just as incomprehensible when it comes to XGP files as anything else I've seen.  Date: 22 September 1982 23:21-EDT (Wednesday) Sender: GUMBY at MIT-OZ From: David Vinayak Wallace To: PGS at MIT-MC Cc: bug-its at mc, DLW at MIT-OZ Subject: Whither XGP? does the versacrock support KST fonts? I know it can't support tj6-style XGP files. Plummer said he would try to do it if he could find documentation on XGP-format files. i tried to find this a couple of years ago when I wanted to generate them with the lisp machine, but nobody knew where any sort of real documentation was. The best I could do was discuss scan format with RWK. With respect to "state of the art" ... are there really any equivalent printers (i.e. 200 dots to the inch)? -------  Date: Wednesday, 22 September 1982 15:39-EDT Sender: PGS at MIT-OZ From: PGS at MIT-MC To: David Vinayak Wallace Cc: bug-its at mc, DLW at MIT-OZ Subject: Whither XGP? Frankly, now that we have the Versatek on the seventh floor working, and there is the possibility of getting Canon laser printers, I think we should throw the XGP and associated hardware out, or give it away, or whatever. Re-interfacing it would take more people-hours than we can afford these days, and if we were going to spend them anyway, we might as well get something closer to state-of-the-art out of it. -------  Date: Wednesday, 22 September 1982 14:10-EDT Sender: KLOTZ at MIT-OZ From: KLOTZ at MIT-MC To: DLW at MIT-OZ Cc: bug-its at mc, David Vinayak Wallace Subject: Whither XGP? I suggest we give the XGP to Concourse, if we are allowed to. -------  Date: 22 Sep 1982 0948-EDT From: J. Noel Chiappa Subject: Re: Whither XGP? To: GUMBY at MIT-MC, bug-its at MIT-MC cc: JNC at MIT-XX In-Reply-To: Your message of 21-Sep-82 1816-EDT ML has it's own private direct PDP-10 interface to the CHAOS net. I don't know if you could plug the XGP-11 into the DL-10 (or the DTE, if it's a multi-11 one) on MC without buying new hardware, but I doubt it. In any case, the software would require tons of work, and I doubt there is anyone at MIT competent to do it. Basically, you're out of luck. -------  Date: Wednesday, 22 September 1982 07:42-EDT Sender: DLW at MIT-OZ From: DLW at MIT-MC To: David Vinayak Wallace Cc: bug-its at mc Subject: Whither XGP? ML talks to the Chaosnet directly, with a PDP-10 Chaosnet interface. There are no PDP-11s on ML. The XGP talks to its through the 10/11 interface, which is a broken and one-of-a-kind beast. It would be a great, great deal of work to interface the XGP in any other fashion. -------  Date: 21 September 1982 18:16-EDT (Tuesday) Sender: GUMBY at MIT-OZ From: David Vinayak Wallace To: bug-its at mc Subject: Whither XGP? How does ML talk to the Chaosnet? Does it use a 10/11 interface? A number of people have been screwed (including everybody in 6.001) because the XGP vanished. Would it be possible to put the XGP on either ML or MC, at least until large fixed-width fonts exist for either the dover or whatever new hardware we get? -------  Devon@MIT-ML 09/10/82 06:12:13 Re: AI's broken Ten-11 interface To: (BUG ITS) at MIT-ML, TK at MIT-ML When the Ten-11 interface is enabled, AI goes into an infinite loop while trying to initialize the Chaos-11's buffers. The NXM light stays off when it's running, but it quickly lights up when single-stepping. This occurs around pc=60477 (T11CK2) with the TV-11 disabled (so it won't die trying to hack the TV-11). Single-stepping this loop seems to show a SETZM instruction skipping. Perhaps the single-step key is bouncy, but this instruction is trying to write a zero into the Chaos-11 so it might be related to the Ten-11 failure. Would someone look at the crash dump in the file AI:CRASH;TREE TOAD and check this out? AI is only available via ARPAnet because it can't talk to the PDP-11's.  Date: 9 September 1982 01:58-EDT From: Devon S. McCullough To: DCP at MIT-MC cc: BUG-ITS at MIT-MC, FJW at MIT-MC DCP@MIT-MC (Sent by DCP0@MIT-MC) 09/07/82 12:35:41 To: DEVON at MIT-MC CC: (BUG ITS) at MIT-MC DEVON@MIT-MC 09/07/82 06:35:11 One question? If ITS sends a IAC WILL BINARY to a TIP or TAC, does this turn off interpretation of the IAC character somehow, so it should no longer be doubled? That would be nasty. An IAC is only doubled when a 377 wants to pass all the way through the TELNET stream. This is still the case when a machine is in TRANSMIT BINARY. I think there is a big difference of opinion on the intercept character issue. Characcters go from KEYBOARD to COMMAND PROCESSOR to TELNET STREAM to FOREIGN TELNET STREAM. Normally the command processor passes through characters to the telnet stream, unless the intercept character is typed. The impression from some people I get is that if the TAC goes into TRANSMIT BINARY, then the command processor will not trap the intercept character. Well, my opinion is that that is a completely cretenous behavior. TRANSMIT BINARY only has to do with the TELNET STREAM, and not the COMMAND PROCESSOR. If TACS will not intercept @ when in TRANSMIT BINARY, then it is in violation of the description of TRANSMIT BINARY found in the April 1976 ARPANET PROTOCOL HANDBOOK. I doubt it has changed. There is a difference in opinion. The command processor is free to decide when it's appropriate to catch the intercept character and when it's not, and currently it does the most reasonable thing. TIP users would be grossly inconvenienced if command characters were intercepted in binary mode. Fortunately they aren't. This issue is totally outside the scope of the protocol, and I saw no mention of it in the APRAnet Protocol Handbook - can you give me a page number?  DCP@MIT-MC (Sent by DCP0@MIT-MC) 09/08/82 01:17:01 To: (BUG DECUUO) at MIT-MC CC: (BUG ITS) at MIT-MC Just curious, What is the kludge in DECUUO that requires the second word of a UNAME entry in the MFD to be zero??  DCP@MIT-MC (Sent by DCP0@MIT-MC) 09/07/82 12:35:41 To: DEVON at MIT-MC CC: (BUG ITS) at MIT-MC DEVON@MIT-MC 09/07/82 06:35:11 One question? If ITS sends a IAC WILL BINARY to a TIP or TAC, does this turn off interpretation of the IAC character somehow, so it should no longer be doubled? That would be nasty. An IAC is only doubled when a 377 wants to pass all the way through the TELNET stream. This is still the case when a machine is in TRANSMIT BINARY. I think there is a big difference of opinion on the intercept character issue. Characcters go from KEYBOARD to COMMAND PROCESSOR to TELNET STREAM to FOREIGN TELNET STREAM. Normally the command processor passes through characters to the telnet stream, unless the intercept character is typed. The impression from some people I get is that if the TAC goes into TRANSMIT BINARY, then the command processor will not trap the intercept character. Well, my opinion is that that is a completely cretenous behavior. TRANSMIT BINARY only has to do with the TELNET STREAM, and not the COMMAND PROCESSOR. If TACS will not intercept @ when in TRANSMIT BINARY, then it is in violation of the description of TRANSMIT BINARY found in the April 1976 ARPANET PROTOCOL HANDBOOK. I doubt it has changed.  DEVON@MIT-MC 09/07/82 08:01:07 To: (BUG ITS) at MIT-MC I spent several hours this morning trying to track down a sporadic TAC or TELSER bug wherein either the TAC gets wedged and refuses to accept binary output when ITS wants to do so, or else it accepts and TELSER is too wedged to notice the ack from the TAC. Couldn't duplicate it once the symptoms became clear enough to try to get them on purpose. Who has done this before? Is there some interaction or protocol change I'm unaware of? I'm not sure whether the TAC or TELSER is at fault. The basic symptom is that I will send IAC WILL BINARY (I do :imgout 377 373 0 at DDT) and the TRBINF in telser stays zero. Alternating between WILL and WONT produces no effect either.  DEVON@MIT-MC 09/07/82 06:35:11 To: (BUG ITS) at MIT-MC One question? If ITS sends a IAC WILL BINARY to a TIP or TAC, does this turn off interpretation of the IAC character somehow, so it should no longer be doubled? That would be nasty.  Date: 7 September 1982 06:29-EDT From: Devon S. McCullough Subject: connecting to ITS from an ARPAnet TAC To: BUG-ITS at MIT-MC cc: DCP at MIT-MC, FJW at MIT-MC, EB at MIT-OZ TelSer should always initialize TelNet connections with IAC WILL BINARY. TCTYP really should try to adjust a TIP or TAC connection when %TPMTA is called for, maybe by means of a new keyword, like EIGHT or META. If connected via a TIP/TAC, TCTYP should then issue IAC DO BINARY. Extensive experiments tonight with USC-TAC show that everything will work fine if you tell a TAC that ITS is going to transmit binary. It works well for some people to ask the TIP/TAC to transmit binary, but this disables @ interception, and will thus screw many TIP/TAC users. The only way they'd have to undo this is either hang up and redial the TIP/TAC, or log out and wait for TelSer's 2 minute timeout. Since I need this feature to enable my terminal's META key, I have fixed my login file to do :IMGOUT 377 373 0 and logout to do :IMGOUT 377 376 0 when my TCTYP specifies %TPMTA. These magic numbers are IAC DO BINARY and IAC DONT BINARY respectively. Apropos nothing in particular, the TIP manual claims that if the host sends 207 ^J to a TIP in OLD TELNET it will work as if the user had typed @ ^J on his terminal, but it does work on TACs so I guess New TelNet never evolved a replacement for this necessary feature, or are they STILL ruinning OLD TELNET???  Date: 5 September 1982 14:09-EDT From: David C. Plummer Subject: MINITS supdup to MC To: KMP at MIT-MC cc: PGS at MIT-MC, PGA at MIT-MC, BUG-ITS at MIT-MC, BUG-MINITS at MIT-MC I believe there is a bug-minits mailing list. Anyway, I think MINITS does do the decrement hack necessary for ITS. I can not make it fail on my AAA which is connected to a MINITS and I am SUPDUPing to MC. I have tried printing files which have lines lengths greater than that of the terminal and cannot make it fail. I suspect the problem is actually the setup modes of the terminal. ITS assumes (or enforces in the initial string) and MINITS assumes (but does not currently have an initial string to enforce it with) that /terminals/ DO NOT automatically wrap when a character is displayed on the last column. This may be a personal preference, but if you are on an AAA and if the second bit of setup mode D is on, turn it off and tell me if it still loses. If you type S to get out of setup, it will save the current configuration (and hope you dont have wars over the proper modes).  Date: 5 September 1982 01:58-EDT From: Kent M. Pitman Subject: MINITS supdup to MC To: PGS at MIT-MC, PGA at MIT-MC cc: BUG-ITS at MIT-MC When Supdup'ing to MC, MINITS (I guess) incorrectly supports over-run lines. it seems that they don't end up incrementing ITS' notion of what line it's on, so at the bottom of the screen, some hardware scrolling happens because ITS doesn't realize soon enough that it's time to give a --more-- break and pop to the top of the screen. this effect is easy to reproduce. just print a file which has lines longer than the line length and watch what happens as you reach the bottom of the screen.  Date: 3 September 1982 21:45-EDT From: David C. Plummer To: DEVON at MIT-MC cc: DCP at MIT-MC, BUG-ITS at MIT-MC I think you are confused (though it could be me). DO TRANSMIT BINARY does not mean the TAC can't trap its escape character, itjust means it should not do any special processing on the characters. There is another option I belive for complete binary transmission which cannot be reverted; I do not think TRANSMIT BINARY is that option. I gues one of us should check the protocol specification...  Date: 3 September 1982 21:42-EDT From: Devon S. McCullough To: DCP at MIT-MC cc: BUG-ITS at MIT-MC DO TRANSMIT BINARY would screw people who try to close their ITS connection and reconnect, since in binary mode the TIP (TAC) does not hack local user commands. Perhaps the TIP/TAC ressets this when you close the connection? It would still be boring to logout and have to wait until TelSer gets around to closing your connection. Currently TelSer knows about CR and CRLF and sets your TCTYP in accordance with the protocol you are sending, so this is no problem.  DCP@MIT-MC 09/03/82 17:30:31 To: (BUG ITS) at MIT-MC Is there any reason why ITS should change a %TDFS into a space on overprinting terminals? Here is the problem: I am on an overprinting terminal, SUPDUPing to ITS. I Telnet to a system that can't deal with overprinting terminal. VAX VMS and I think VAX Unix have this problem. When using CHTN, I toggle VT52 emulation mode and tell the VAX I have a vt52 (with perhaps a higher screen). When the foreign system sends an ESCAPE C (or whatever it is that goes forward), CHTN tells ITS to go forward. When ITS is sending to a replacing terminal, it sends %TDFS (I hope), but for an overprinting terminal (which it still thinks I am in this case), it sends a space (which unfortunately is now destructive).  Date: 3 Sep 1982 1213-EDT From: J. Noel Chiappa Subject: TelSer To: DEVON at MIT-MC cc: BUG-ITS at MIT-MC, JNC at MIT-XX Sounds like a good idea to me. Will any ITS wizards out there speak up if this is unreasonable? Otherwise, I'd say do it. -------  DCP@MIT-MC 09/03/82 12:00:23 To: DEVON at MIT-MC CC: (BUG ITS) at MIT-MC If TELSER sends WILL TRANSMIT BINARY, then that only allows ITS to send binary to the TAC. You also want DO TRANSMIT BINARY which lets the TAC legally send binary to ITS. I aggree that most times there will be no noticiable difference in terminal handling. When a user types both RETURN and LINEFEED to something like DDT, ITS may get marginally confused, but thems the breaks. I do not use TACs. Somebody that does should try out a new TELSER on MC or ML some night and see if it works. Make sure CR, LF, and CR LF all do what you expect. Compare with old behavior.  DEVON@MIT-MC 09/03/82 03:22:06 To: (BUG ITS) at MIT-MC When TIPs were generally used, the default output mode was (apparently) binary, but now that TACs are in vogue, terminal programs that used to work with TIPs lose, because they are only receiving 7 bits. Perhaps TelSer should WILL Transmit Binary, which is necessary in some cases and harmless otherwise.  Date: 30 August 1982 05:48-EDT From: Christopher C. Stacy Subject: TV To: BUG-ITS at MIT-AI seems to drop bits. My ^C in previous :MAIL echoed as ^B but worked.  Date: 30 August 1982 05:48-EDT From: Christopher C. Stacy To: BUG-ITS at MIT-AI Sometimes when I am using a Knight TV, my screen gets garbled. I dont know what part of the TV system (10,11, or 10/11) is losing.  Date: Saturday, 28 August 1982 02:40-EDT To: cstacy at MIT-OZ Sender: RPS at MIT-OZ from:cent Subject:ai problems & bughalts cc: bug-its at MIT-OZ chris, leaving yellow-pad notes on the ai system console is better than nothing as a way to indicate what its particular brokenness is, but ignores the problem that the note might fall off. please record the brokenness state in the ai system logbook, so other people will know what's going on (also for a semi-permanent record -- lossage like the disk breaking needs to become part of general memory). thx. -------  Date: 23 August 1982 10:36-EDT From: Devon S. McCullough Subject: H19 emulators, and lossage and ANSI mode To: PGS at MIT-MC cc: BUG-ITS at MIT-OZ A bit would be cleaner, after all TCTYP can be told that HDS means H19 + some bit, just as GLASS means PRINTING with some different bits.  Date: Monday, 23 August 1982 08:52-EDT Sender: PGS at MIT-OZ From: PGS at MIT-MC To: DEVON at MIT-MC cc: BUG-ITS at MIT-OZ Subject:H19 emulators, and lossage and ANSI mode In implementing multiple insert/delete line for H19's, I used ANSI mode because it was the only way to get it (as I imagine you know if you wrote an emulator). This is what CRTSTY does. Looks to me like there are two possibilities; a new terminal type could be implemented (call it HDS or whatever) that would output only HDS codes, or a bit could be defined to say don't do multiple operations. I guess I'll do one of them when I get back. If anyone thinks one way is more tasteful than the other, let me know. I lean towards a separate type because it's easier to do :TCTYP HDS than :TCTYP H19 NO MULTIPLE (or worse yet, specify the bits). -------  DEVON@MIT-MC (Sent by DEVON7@MIT-MC) 08/20/82 08:10:24 To: (BUG ITS) at MIT-MC certain h-19 emulators don't support ANSI mode and no longer work with the latest ITS. short-distance screen scrolling in EMACS still works, but when trying to scroll the text a long way it just puts trash on the display, and I have to clear the screen (slow) Since the emulation I'm using is on a micro i suppose I could try to hack some new code, but the display driver has limited memeory in which to live, because when screen RAM is mapped in, most user RAM is mapped out to make room for the video. perhaps TECO can be kludged with some flag saying to insert/delete one at a time?  Date: 18 Aug 1982 0423-EDT From: DEVON at MIT-DMS (Devon S. McCullough) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].241228> using a TIP, it was never necessary to do @b o s, but now with TAC's it is. To avoid inconveniencing the user, how can this be done from ITS?  Date: 16 August 1982 19:52-EDT From: David C. Plummer To: REM at MIT-MC cc: BUG-ITS at MIT-MC, MIT-IN-PEOPLE at MIT-MC REM@MIT-MC 08/16/82 09:12:29 I am getting no echo whatsoever. I am typing this blindly. I pressed ctrl-S to stop output on second window (screen) of a ^R (PRINT), which has been doing this for weeks since the SU-TAC was installed. My theory is that ITS is doing an output reset, which is turning into a data mark or interrupt process or something in the TELNET protocol, and that TACs don't understand this. You will probably find that ^G will do the same thing. Has the TELNET protocol dropped this feature? Is ITS doing the wrong thing? Or is this missing from the implementation of TACs. Could somebody forward this to the code writers of the TAC software. If necessary, I will try and find out what ITS is doing. This has also happened to the DAVID-TAC (??) by people from the NAVY.  EAK@MIT-ML 08/16/82 15:15:02 To: (BUG ITS) at MIT-ML I was sittly quitely in :MAIL just now when I got a Console Free message. I thought someone had gunned me, so I quickly came back and spied on the system console, which said NET: RST TIMEOUT HST= 116000 15:08:57 116000 is the host I was coming from. Some weird network glitch? I don't know, but I also don't understand why my tree wasn't detached instead of destroyed.  REM@MIT-MC 08/16/82 09:12:29 To: (BUG ITS) at MIT-MC I am getting no echo whatsoever. I am typing this blindly. I pressed ctrl-S to stop output on second window (screen) of a ^R (PRINT), which has been doing this for weeks since the SU-TAC was installed.  Date: Saturday, 14 August 1982 14:47-EDT Sender: PGS at MIT-OZ From: PGS at MIT-MC To: David A. Moon Cc: BUG-ITS at MIT-MC, BUG-TELNET at MIT-MC, KLOTZ at MIT-OZ, RMS at MIT-OZ Subject: crufty lossage (of characters, perhaps) Date: Friday, 13 August 1982 02:03-EDT From: David A. Moon Re: crufty lossage (of characters, perhaps) :TCTYP ? will tell you about the PADDED option, which is probably what you need. Actually, I was losing completely, not knowing about needing to have the local end in image mode. But I became unwedged eventually. -------  CSTACY@MIT-MC 08/14/82 04:51:39 To: (BUG ITS) at MIT-MC I installed version 1278 as NITS on MC. If anything goes wrong, please take a crash dump and boot from ITS. Broken terminal support is supposedly fixed.  Date: 13 August 1982 02:03-EDT From: David A. Moon Subject: crufty lossage (of characters, perhaps) To: PGS at MIT-MC cc: BUG-TELNET at MIT-MC, BUG-ITS at MIT-MC, RMS at MIT-MC, KLOTZ at MIT-MC :TCTYP ? will tell you about the PADDED option, which is probably what you need.  Date: Tuesday, 10 August 1982 20:48-EDT Sender: PGS at MIT-OZ From: PGS at MIT-MC To: RZ at MIT-OZ cc: bug-its at MIT-OZ RZ@MIT-MC 08/10/82 16:40:36 I'm using one of the old ann arbors (it doesn't even have n-key rollover). With the new ITS there are several problems which I can't really explain. First, inside mail I am unable to type a rubout or C-Z. A rubout seems to turn into a C-W since the previous word always gets deleted. C-Z's don't do anything. THis is not true when talking to DDT or EMACS. Lock seems to idicate that that the right codes are being sent. Second, when I logout the DDT seems to revert to the same mode that MAIL and SEND are in. As a consequence, I can't log back in. Since most of the Ann Arbors at the lab are new, and have meta keys, Ann Arbors are initialized with +%TPMTA. Older Ann Arbors, like yours, don't have meta keys. Looks like ^Z and rubout are being read as meta-^Z and meta-rubout. If you do :TCTYP AAA -%TPMTA you should win. -------  Date: 10 August 1982 18:05-EDT From: Christopher C. Stacy To: BUG-ITS at MIT-MC I deinstalled the new ITS from MC, since it was crashing the system. I will look into it (sigh).  RZ@MIT-MC 08/10/82 16:40:36 To: (BUG ITS) at MIT-MC I'm using one of the old ann arbors (it doesn't even have n-key rollover). With the new ITS there are several problems which I can't really explain. First, inside mail I am unable to type a rubout or C-Z. A rubout seems to turn into a C-W since the previous word always gets deleted. C-Z's don't do anything. THis is not true when talking to DDT or EMACS. Lock seems to idicate that that the right codes are being sent. Second, when I logout the DDT seems to revert to the same mode that MAIL and SEND are in. As a consequence, I can't log back in.  PGS@MIT-MC 08/10/82 07:00:59 To: (BUG ITS) at MIT-MC ITS 1278 is now installed on ML, AI, and MC. It contains support for Ann Arbors, and the code for H19's has been rewritten to include multiple insert/delete line/char. TYMPAD has been changed to allow padding with nulls. H19's are being successfully padded with nulls, but it doesn't help a whole lot, because the padding for insert/delete operations isn't happening at the most featureful time imaginable. I'll fix this when I get back from vacation.  Date: 8 August 1982 19:56-EDT From: Patrick G. Sobalvarro Subject: crufty lossage (of characters, perhaps) To: BUG-TELNET at MIT-MC, BUG-ITS at MIT-MC cc: RMS at MIT-MC, KLOTZ at MIT-MC I'm trying to fix TS3TTY so that H19's are padded with nulls, and can do multiple insert/delete line, like Ann Arbors do (no more of this weenie weenie stuff). I think I'm winning. But I can't tell. Why can't I tell? Well, AI has no H19's hung on it, and it can't pump out the characters at 9600 baud anyway, and that's when things get critical. So what I usually do is go downstairs and connect an H19 to MC, and Telnet over to AI and do a :TCTYP H19 locally. And I lose; the padding, or the insert/delete line stuff, just doesn't seem to work; the terminal gets confused, and outputs things in random places, and I go back and grovel over the code some more. But last night I distilled a listing and injected it into my brain, and this afternoon when I saw that I was losing, I knew damned well that I should be winning, so I went over to a VT52, and Telnetted from it (on MC) to ML. Its terminal type was set to VT52 on both machines, and it exhibited the same sort of lossage that H19's were exhibiting for me. RMS suggested that perhaps the local machine didn't know its speed, so I set that to 9600 in both places, and it still lost. In fact, absolute positioning and insert/delete line/character type things seem to consistently lose through a Telnet. I believe I remember hearing this ascribed to VTS when people used to Telnet to XX when it first came up. Try this simple experiment: log in on a local terminal on ML, or DM, or MC, or maybe even AI, although I don't know if it's fast enough to cause the lossage. Telnet over to another machine (even the one you're on!), do TTY^K, and watch it go!  Date: 28 Jul 1982 1132-EDT From: CSTACY at MIT-DMS (Christopher C. Stacy) To: bug-its at MIT-DMS Message-id: <[MIT-DMS].238845> This system seems to be printing bogus LOGIN and LOGOUT messages. God knows what else it mightbe doing.  Date: 31 Jul 1982 1129-EDT From: SWG at MIT-DMS (S. W. Galley) To: SWG at MIT-DMS, CSTACY at MIT-DMS Cc: bug-its at MIT-DMS In-reply-to: <[MIT-DMS].238845> Subject: bogus LOGIN & LOGOUT messages Message-id: <[MIT-DMS].239379> No doubt it's because TAA patched ITS to record them for non-TTY trees as well as TTY-controlled ones.  CSTACY@MIT-MC 08/04/82 17:40:57 Re: sources To: (BUG ITS) at MIT-MC I saved the AI sources in SYSTEM, SYSENG, and SYSEN1 onto OZ for the moment.  TK@MIT-MC 07/31/82 15:26:29 To: (BUG ITS) at MIT-MC Just so other people who look at AI don't spin wheels unnecessarily. AI is currently dropping dead during the instruction following LPMR's (and possibly other pager related instructions). There also appears to be a bad file in the acount directory (cdata or something) which prevents the system from coming up, but which the salvager seems incapable of fixing trivially. I haven't looked at this second problem very hard. The following loop will hang the processor: LMPR JFCL JFCL AOJA .-3 PC stops at lpmr + 2, having fetched and done the fetch cycle (including PC increment) of the instruction at lmpr + 1. I probably won't get a chance to look at this further for a few days. I'd suggest a debugging strategy of using the logic analyzer to locate the place where the pulse train drops dead. This might be caused by additional pulses coming back from the pager. A likely failure is the TTL-DEC converters going to the pager.  Date: Sunday, 1 August 1982 06:07-EDT Sender: TERZOP at MIT-OZ From: TERZOP at MIT-MC To: KLOTZ at MIT-AI Cc: bug-its at ai, vision at ai Subject: AI's demise? Date: Saturday, 31 July 1982 00:24-EDT From: KLOTZ at MIT-AI To: bug-its at ai cc: vision at ai Re: AI's demise? What is going to happen to the XGP when AI finally quits working? Is the vision group going to get something to use for their lispm plots? Leigh. Hopefully SOMEONE will get a Cannon lazer printer or the equivalent, at which time a celebration for all can be held in the middle of Tech Square, the highlight of which will be the burial of the XGP ten feet under. -------  Date: 28 July 1982 23:16-EDT From: Alan Bawden Subject: MC emacs stuck in Kansas To: TFT at MIT-MC cc: BUG-MC at MIT-MC, BUG-ITS at MIT-MC TFT@MIT-MC 07/27/82 08:31:40 Re: MC emacs stuck in Kansas To: (BUG MC) at MIT-MC I think this should go to bug-mc, not bug-emacs: When I try to use either M-x find file, or C-x-C-f, to get a file from Oz, the defaulter gets very confused. I think it doesn't even know that Oz exists! ... Huh? Are you complaining that C-X C-F OZ:FOO.BAR doesn't work? (While you CAN reference files on AI f'rinstance?) While it IS possible that this could be made to work it isn't exactly trivial. Maybe someday someone will have a hack attack and do it. This is one of the prices we pay for running an incompatible timesharing system on OZ rather than an Incompatible Timesharing System.  Date: Saturday, 31 July 1982 00:24-EDT Sender: KLOTZ at MIT-OZ From: KLOTZ at MIT-AI To: bug-its at ai cc: vision at ai Subject:AI's demise? What is going to happen to the XGP when AI finally quits working? Is the vision group going to get something to use for their lispm plots? Leigh. -------  Date: 31 July 1982 18:59-EDT From: Tom Knight To: BUG-ITS at MIT-AI AI has decided to "work" for the time being. I.e., Moon and I intimidated it with scope probes, and it stopped failing. This is the second unrelated marginal failure in as many weeks, neither of which has been properly fixed. Don't count on it continuing to work.  MOON@MIT-MC 07/26/82 03:29:39 Re: AI's problems--TEN-11 software To: TK at MIT-AI, (BUG ITS) at MIT-AI For what's worth, I fixed these in the source. Someone who wanted to be useful might assemble and install a new system on AI. I made the Chaosnet respect TEN11F, which it hadn't heard of, and I made the pointer in the TV-11 memory get ranged checked in the 2 places it seemed to be used, causing a bug-halt with an appropriate message if it was wrong.  Date: 24 Jul 1982 0302-EDT From: Robert W. Kerns Subject: Re: .TEMP. To: CSTACY at MIT-AI, BUG-ITS at MIT-AI cc: RWK at SCRC-TENEX at MIT-MC In-Reply-To: Your message of 24-Jul-82 0243-EDT TMPKIL is supposed to run, of course, and there is supposed to be a .TEMP. directory, and there should be a -READ- -THIS- file in the directory that explains what the directory is for, and it should be reap-protected. I believe that TMPKIL explicitly does not delete -READ- -THIS-; the do-not-reap bit is to discourage people, not programs. -------  Date: 23 July 1982 17:01-EDT From: Christopher C. Stacy Subject: .TEMP. To: BUG-ITS at MIT-AI When the system came up after being broken the other day, I noticed TMPKIL running. I wasnt sure who/what started it, so I left it be.  Date: Friday, 23 July 1982, 13:59-EDT From: Robert W. Kerns Subject: AI:.TEMP.; To: Rodney A. Brooks Cc: BUG-ITS at MIT-AI, BUG-LISPM at MIT-AI In-reply-to: The message of 23 Jul 82 09:54-EDT from Rodney A. Brooks Date: 23 July 1982 09:54-EDT From: Rodney A. Brooks on lispm Terminal-Q complains of the non-existnece of directory AI: .TEMP.;LMSCN >. I assume this is either the reslt of recent vandalism or overzealous directory reclamation? Perhaps someone deleted the -READ- -THIS- file, and the program that reaps that directory (deleting files more than a day old that don't have the do-not-reap bit and are not -READ- -THIS-) ran, leaving no files in the directory? Does AI run that program? I seem to recall that it's run by PFTHMG DRAGON on MC. I think it's called TMPKIL.  Date: 22 July 1982 07:26-EDT From: Tom Knight To: BUG-ITS at MIT-AI cc: TK at MIT-AI AI's problems, after 2 nights of hacking, turned out to be software [sort-of]. The system was getting page faults referencing NXM exec pages, while PI in progress on channel 7. The problem had to do with a location in the TV-11 being the exactly wrong value to cause the LDB and ADD at SSLCK8+4 or so to produce an address of one more than the page boundary. This was compounded and made more difficult to find by a second bug in which turning off the 10-11 code makes the chaonet clock routine reference exec NXM, again at clock level, without checking the TEN11F flag. This happens on calls to T11CHK, which should just popj if TEN11F is disabled. This problem was eventually debugged with clipleads halting the machine on exec memory protect failures. The bugs have not been patched, but the system will presumably "never" get into that state again. I'll edit the sources after breakfast.  MOON@MIT-MC 07/16/82 22:09:18 Re: disk constipation To: DCP at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC DCP@MIT-MC 07/16/82 21:25:55 To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC Is there something wrong with the disk code? MC constipated for quite a while just now, and here is comsat's stats for the time: 205056 Attempting to send messages queued to host MIT-OZ 205056 ICP->MIT-OZ... 205057 QID=<[MIT-MC].317543> 205057 TO->MARTY 205059 CMSG ID=<[MIT-MC].317655> EXP->DCP@354 211553 TO->DCP Notice the 25 minute delay. The constipation did coincide with my typing G inside EMACS RMAIL. Then again, it could be unrelated. During the constipation, ANYBODY doing an OPEN on a disk file would hang, but could be PCLSR'd. This is usually due to running out of disk channels, and deadlocking where you have several programs each of which wants a lot of disk channels, has some, and is waiting for more. COMPLR and PUB are prime offenders in this respect since they open many channels and keep them open for many minutes. You can look at the variable in the system whose name is (I think) QFCHN, the number of free disk channels.  DCP@MIT-MC 07/16/82 21:25:55 To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC Is there something wrong with the disk code? MC constipated for quite a while just now, and here is comsat's stats for the time: 205056 Attempting to send messages queued to host MIT-OZ 205056 ICP->MIT-OZ... 205057 QID=<[MIT-MC].317543> 205057 TO->MARTY 205059 CMSG ID=<[MIT-MC].317655> EXP->DCP@354 211553 TO->DCP Notice the 25 minute delay. The constipation did coincide with my typing G inside EMACS RMAIL. Then again, it could be unrelated. During the constipation, ANYBODY doing an OPEN on a disk file would hang, but could be PCLSR'd.  Date: 14 July 1982 11:29-EDT From: David A. Moon Subject: [MP: ITS question] To: GREN at MIT-AI cc: BUG-ITS at MIT-MC, mp at MIT-XX Date: Wednesday, 14 July 1982 00:45-EDT Sender: GREN at MIT-OZ From: GREN at MIT-AI To: BUG-ITS at AI Subject: [MP: ITS question] Date: Saturday, 10 July 1982 21:37-EDT From: Mark Plotnick To: gren at MIT-MC Re: ITS question I hear you're an ITS expert. Could you tell me what this piece of code attempts to do? My intuition tell me that it's trying to figure out what tty number your console tty is at, but there must be easier ways to do this. .OPEN CH,[SIXBIT / #TTY/] .VALUE .SUSET [<.RIOC+CH>,,T] LDB N,[220600,,T] Mark I thought that bits 3.1-3.6 were the error code, set on non-skip .CALLs. That's .IOS. What is N getting? The TTY number. .SUSET .RCNSL would be a better way.  Date: Wednesday, 14 July 1982 00:45-EDT Sender: GREN at MIT-OZ From: GREN at MIT-AI To: BUG-ITS at AI Subject: [MP: ITS question] Date: Saturday, 10 July 1982 21:37-EDT From: Mark Plotnick To: gren at MIT-MC Re: ITS question I hear you're an ITS expert. Could you tell me what this piece of code attempts to do? My intuition tell me that it's trying to figure out what tty number your console tty is at, but there must be easier ways to do this. .OPEN CH,[SIXBIT / #TTY/] .VALUE .SUSET [<.RIOC+CH>,,T] LDB N,[220600,,T] Mark I thought that bits 3.1-3.6 were the error code, set on non-skip .CALLs. What is N getting? --gren -------  Date: 12 July 1982 16:02-EDT (Monday) Sender: RICH at MIT-OZ From: Charles Rich To: bug-oz at MIT-AI, bug-its at MIT-AI How do I get supdup (:OZ) on AI to use SAIL characters on AI TV's? (note: I have done :tctype sail before starting the supdup). -------  Date: 11 July 1982 19:56-EDT From: David A. Moon Subject: .IOC To: GREN at MIT-MC cc: BUG-ITS at MIT-MC It's the same as IOCHNM inside ITS. You can look at the comments on that. The right half is an index into internal device tables, and the left half contains device-dependent bits and fields. However, the reason it is not documented is probably that it is not generally useful and only exists for completeness.  Date: 11 July 1982 16:07-EDT From: Christopher C. Stacy To: BUG-ITS at MIT-AI In ITS 1273, DDT 1388, on AI: PWORD, MAIL, FINGER, and WHO, were all broken last night for some reason. Now they all work. Did someone fix this stuff, or did it (ummm) fix itself.  Date: 11 July 1982 05:36-EDT From: Ian G. Macky To: BUG-ITS at MIT-MC The World According to >INFO.;ITS USETS: .IOC + +- +- input/output channel The variable .IOC+ is the input/output channel word for channel , for n between 0 and 17 octal. Normally zero for a closed channel. [This is not horribly informative. Can anyone tell me what exactly is in thess words? I'll fix the USETS doc once the stuff is known... --gren]  Date: 11 July 1982 01:26-EDT From: Keith F. Lynch To: BUG-ITS at MIT-AI :F and :FINGER and :WHOIS all die, with or without jcl. :F gives me the header line, then XGP, then, immediately on a new line, ILOPR; 17770>>0 0/ 10400,,500000 0/ 10400,,500000 :FINGER and :WHOIS gives similar results. There is no problem with :U or :UJ or :WHO or :WHOJ. :F worked fine about two hours ago. ...Keith  Date: 11 July 1982 00:42-EDT From: Doug Humphrey To: BUG-ITS at MIT-AI :f and :who are blowing up on me. nothing special I am doing. :f blows with ILOPR; 17770>>0  Date: 10 July 1982 19:38-EDT From: Christopher C. Stacy Subject: I answered Guby's FINGER bug report (there was no bug) To: GUMBY at MIT-AI cc: BUG-ITS at MIT-AI  Date: 10 July 1982 19:13-EDT From: David Vinayak Wallace To: BUG-ITS at MIT-AI :f %bbnu hangs forever. Do all sites have finger servers? ITS should time out intelligently (it certainly does if another ITS is down).  Date: 5 July 1982 15:09-EDT From: David Chapman Sender: ___013 at MIT-AI To: BUG-ITS at MIT-AI sys3;ts k is linked to sys3;ts logout which ain't they'.  Date: 1 July 1982 19:00-EDT From: Ken Harrenstien Subject: AI not accepting ARPAnet connections To: BUG-ITS at MIT-AI, BUG-PWORD at MIT-AI Hey, what's with this server telnet lossage? Any attempt to connect gets me a "ITS being deubbgged, go away" message, but after two days of this crap I find that I can get in via CHaos from MC. I'm pretty pissed, since I've been trying to get at my mail to process ATSIGN, HOSTS3, and HEADER-PEOPLE stuff; also, unless I can get in you're going to lose the disk space that all the digests take up in my mail. Would whoever slammed the door please consider that 99% of network people are okay guys, and deserve a little notice. While this is being put to rights, how about flushing PWORD for connections from SRI-NIC? That used to be set up OK but someone apparently reset things. Again I'm irked; I used to think that friendships counted for something more than being treated like a total random.  Date: 30 Jun 1982 1501-EDT From: Robert P. Krajewski Subject: XGPSEND To: EBM at MIT-XX cc: BUG-OZ at MIT-OZ, BUG-ITS at MIT-AI [The Twenex program] does not work from XX or OZ. It can't create a spooling file. Have some protocols been changed or something ? Yes, people don't use the XGP much, but ... bob -------  Date: 26 June 1982 11:41-EDT From: Alan Bawden To: HDT at MIT-AI cc: BUG-ITS at MIT-MC Supdup figures that when you type P you probably don't even want it as your current job anymore, so it cleverly sets some OTHER job as being current. That's what it's doing when it valrets 1J to your DDT, it's trying to select your PREVIOUSLY selected job. This is why you somtimes get the error message JOB GONE? when leaving a supdup (the previously selected job has dissapeared since you started your supdup). I guess it's somebody's idea of a feature. I've never found the slightest bit convienent.  Date: 25 June 1982 22:24-EDT From: Howie Daniel Trachtman To: BUG-ITS at MIT-AI cc: HDT at MIT-AI This is minor, but I just thought you might like to know. I had a supdup to oz which I typed p to get back to ai`s ddt. I then later had to :mc for something... Then I did a p to get back to AI, and sent someone a message, and did not start up any jobs. However, when I did a :contin I got my oz job. Am I seeing things, or is this a bug? BTW, my mc job was still around afterwards. --Howard--  GJC@MIT-MC 06/22/82 23:31:39 Re: the strangest thing To: (BUG ITS) at MIT-MC I was running :CHTN HTJR, a vax running VMS. On the Vax I ran a program which does a lot of I/O displaying information like a PEEK program (it was a peek type program) and taking character input at interrupt level. I ran this peek program looking at itself, and low and behold the CHTN was too busy or something to listen very well, even to the CHTN break character. That is, I found I could not break out of CHTN nor get any response from the VAX which just kept outputing characters. I then hung up the phone and redialed MC. Being brave, I then did :UJOB GJC HACTRO and :SNARF CHTN. The CHTN and the DDT then seemed to have control of the TTY at the *same* time, DDT getting characters only once in a while with the CHTN doing lots of output to my TTY. I then HUNG UP the phone again, and sent this bug note. Later... It seems I can reproduce this condition at will.  MOON@MIT-MC 06/19/82 20:25:44 Re: MC:.MAIL.;NAMES > is too large To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC MC:.MAIL.;NAMES > is too large. It is causing the mailer to run out of address space frequently. If you read the file, a great deal of it looks like pure trash. I removed a few obviously obsolete entries; others should do the same. It may be necessary to remove some of the large mailing lsts into separate files (using @FILE). It would also be desirable to remove the personal entries for people who no longer exist; I don't know if there is a reliable way to tell whether someone no longer exists. I also personally feel that the full-name entries at the end of the file are worthless and should be flushed, although others may disagree.  Date: 17 June 1982 21:55-EDT From: David Chapman To: BUG-ITS at MIT-AI It seems that the msgs times was reset sometime last night. Everyone says that they had to read all the old messages again.  Date: 17 June 1982 20:21-EDT From: Mark J. Dulcey To: BUG-ITS at MIT-AI, BUG-BOLIO at MIT-AI, BUG-LISP at MIT-AI I corrected a bug in the file AI: LMIO1; RFONTW >, and installed the changes on the Lisp Machine. However, I know that these functions are also used by other folks (not on the Lisp Machine), so I thought I'd let you know so you can recompile and load the new FASL files.  MOON5@MIT-MC 06/16/82 15:49:09 Re: vandalism To: (BUG ITS) at MIT-MC I removed the garbage that someone not logged-in on some other ITS edited into the MC:SYS;SYSTEM MAIL. This is the second time today I believe.  DCP@MIT-MC 06/14/82 11:52:49 To: RICH at MIT-MC CC: (BUG ITS) at MIT-MC RICH@MIT-MC 06/14/82 10:35:45 Will it be possible soon to have OZ: as a device from ITS like MC:, etc. Not without a good deal of hacking. They are different operating systems, and OZ is not on the ARPAnet, which is what the infamous MLDEV uses. The standard ITS 6 character DIR, FN1 and FN2 will not map well to a twenex file system, and not many programs implement RMS's string open system call to get around this problem.  DCP@MIT-MC 06/14/82 11:52:49 To: RICH at MIT-MC CC: (BUG ITS) at MIT-MC RICH@MIT-MC 06/14/82 10:35:45 Will it be possible soon to have OZ: as a device from ITS like MC:, etc. Not without a good deal of hacking. They are different operating systems, and OZ is not on the ARPAnet, which is what the infamous MLDEV uses. The standard ITS 6 character DIR, FN1 and FN2 will not map well to a twenex file system, and not many programs implement RMS's string open system call to get around this problem.  Date: Monday, 14 June 1982, 14:30-EDT From: Christopher C. Stacy To: RICH at MIT-MC Cc: BUG-ITS at MIT-MC RICH@MIT-MC 06/14/82 10:35:45 To: (BUG ITS) at MIT-MC Will it be possible soon to have OZ: as a device from ITS like MC:, etc. As I explained when we were deciding what operating system to run, TOPS-20 doesn't have any facility for doing this sort of thing. It is a major task to write it into the guts of the Tops-20 monitor. I (or someone) will probably be working on it in the near future, but it is likely to take a while. Chris  MOON@MIT-MC 06/14/82 15:42:31 Re: OZ: device To: RICH at MIT-MC CC: (BUG ITS) at MIT-MC RICH@MIT-MC 06/14/82 10:35:45 To: (BUG ITS) at MIT-MC Will it be possible soon to have OZ: as a device from ITS like MC:, etc. It's possible but unlikely. The problem is that the inter-ITS devices simply relay system calls from the remote machine to the foreign machine. 20X has, of course, different system calls, and not all the ITS system calls map simply into 20X system calls. There is also the issue of incompatible file name lengths and syntax. On the other hand, since it was done for the FC: it can probably be done for OZ also assuming someone is available to do the work. If the FC: device used the standard file access protocol that 20X already supports, it would have been trivial to extend it into an OZ: device. Since it uses a private protocol instead, either that protocol will have to be implemented on TOPS-20 or an entirely new job-device program will have to be written.  RICH@MIT-MC 06/14/82 10:35:45 To: (BUG ITS) at MIT-MC Will it be possible soon to have OZ: as a device from ITS like MC:, etc.  MCB@MIT-MC 06/11/82 21:20:13 To: (BUG ITS) at MIT-MC I was just looking for some tip info and noticed that .info.;tip manual on MC appears to have been clobbered sometime early this morning.  Date: 8 June 1982 18:07-EDT From: David Vinayak Wallace To: BUG-ITS at MIT-AI cc: BUG-EMACS at MIT-AI When I am in emacs on a AAA and I get a send while the screen is redisplaying, part of the buffer is displayed under the mode line.  Date: 8 June 1982 12:30-EDT From: Martin David Connor To: BUG-ITS at MIT-AI, USER-A at MIT-AI I found not one, but wo bogus copies of OCTPUS on the SYS directories. One was 35 blocks long, and would not BINPRT. The other was small, and unrecognizable. Please keep your eyes open for this bogosity, because people are using these to log in and do damage. Thanks. Marty  Date: Wednesday, 2 June 1982, 07:26-EDT From: Robert W. Kerns Subject: 2-character escape sequences getting broken up To: David A. Moon Cc: bug-its at MIT-AI In-reply-to: The message of 27 May 82 03:00-EDT from David A. Moon Date: Thursday, 27 May 1982, 03:00-EDT From: David A. Moon DDT could avoid this by doing its interrupt-level typeout (e.g. of sends) on a separate I/O channel. DDT doesn't do interrupt-level typeout. DDT gets interrupted and goes off and does other typeout, via the HAKKAH kludge. I think the problem is with ECHOED (at ITS interrupt level) typeout anyway, not with DDT's typeout.  Date: 3 Jun 1982 1225-EDT From: PDL at MIT-DMS (P. David Lebling) To: MEYER at MIT-DMS Cc: BUG-ITS at MIT-DMS, BUG-EMACS at MIT-DMS Subject: M-X DIRED$MEYER;AR9: Message-id: <[MIT-DMS].233727> I was finally able to reproduce the problem, but it went away after a while. I have to assume that the problem is with EMACS, because even when it was losing in EMACS saying :PRINT DIRAR9:NAME1 UP worked in DDT. Alternatively it may be a funny timing problem with the archive or dir device. In any case, I am CCing this to BUG-ITS and BUG-EMACS in the hope that someone can help. For those who are hearing about this problem for the first time, in EMACS, M-X DIRED$MEYER;AR9: (and other archives, on DM) often gets FILE LOCKED? errors. It seems to always go away eventually, but eventually return. Could this be a JOBREU lossage with one of those devices not reiniting properly? Dave  Date: Saturday, 29 May 1982, 23:27-EDT From: Robert W. Kerns Subject: WHARTON To: GSB at MIT-ML Cc: bug-comsat at MIT-AI, bug-its at MIT-AI In-reply-to: The message of 29 May 82 17:29-EDT from GSB at MIT-ML From: GSB@MIT-ML Date: 05/29/82 17:29:23 GSB@MIT-ML 05/29/82 17:29:23 Is wharton no longer on the arpanet, or is the host table trashed? It's in the arpanet-bboards list, but it took me a bit to track this down because comsat issued no diagnostic for a "TO:(BBOARD WHARTON)", just sent it to bboard locally (which is a dumb thing to do). Wharton is off the arpanet due to administrative fuckup of some sort or another. They'll be back someday (at different address) when it all gets straightened out.  DCP@MIT-MC 05/29/82 20:00:29 To: GSB at MIT-ML CC: (BUG COMSAT) at MIT-ML, (BUG ITS) at MIT-ML :host WHARTON Lookup failed. So, it is not in the host table on MC. CAH tells me that WHARTON punted the ARPAnet, or the other way around. Politics, or something like that.  GSB@MIT-ML 05/29/82 17:29:23 To: (BUG COMSAT) at MIT-ML CC: (BUG ITS) at MIT-ML Is wharton no longer on the arpanet, or is the host table trashed? It's in the arpanet-bboards list, but it took me a bit to track this down because comsat issued no diagnostic for a "TO:(BBOARD WHARTON)", just sent it to bboard locally (which is a dumb thing to do).  Date: 29 May 1982 15:05-EDT From: Leonard N. Foner To: BUG-ITS at MIT-AI Something appears wrong with the way certain host names are being displayed by FINGER. While most of the lines printed out are fine, FINGER is consistently showing these lines wrong: FONER T Leonard N. Foner F T43 #27: At home GYRO A Scott W. Layson HACTRN 7.T44 Net site (Chaos) As you can see, the hostnames (in my case, MIT-TIP... I don't know about Scott) are not being displayed. I dunno what's wrong. Ciao.  Date: Thursday, 27 May 1982, 03:00-EDT From: David A. Moon Subject: 2-character escape sequences getting broken up To: rwk at SCRC-TENEX Cc: bug-its at MIT-AI DDT could avoid this by doing its interrupt-level typeout (e.g. of sends) on a separate I/O channel.  Date: Thursday, 27 May 1982, 02:18-EDT From: Robert W. Kerns Subject: Illegal chr after control P To: Michael Travers Cc: BUG-ITS at MIT-AI In-reply-to: The message of 27 May 82 01:18-EDT from Michael Travers Date: 27 May 1982 01:18-EDT From: Michael Travers I was SUPDUPing to AI from XX. While reading my mail with $^A I typed a space to a --More-- break. It spat out: TTY: MT; - ILLEGAL CHR AFTER CNTRL P ON TTY DISPLAY I can't reproduce this as nothing at all out of the ordinary was being done. I did notice that there was new mail in my mail file that I had not seen a notification for; perhaps it was trying to print it when it got the error. This is the usual screw with two-character escape sequences getting asynchronous typeout intervening between them.  Date: 27 May 1982 01:18-EDT From: Michael Travers To: BUG-ITS at MIT-AI I was SUPDUPing to AI from XX. While reading my mail with $^A I typed a space to a --More-- break. It spat out: TTY: MT; - ILLEGAL CHR AFTER CNTRL P ON TTY DISPLAY I can't reproduce this as nothing at all out of the ordinary was being done. I did notice that there was new mail in my mail file that I had not seen a notification for; perhaps it was trying to print it when it got the error.  CSTACY@MIT-MC 05/22/82 22:20:21 Re: hung TVs To: (BUG ITS) at MIT-MC On AI, sometimes when you get a TV by hitting call, you get wedged in TTYI. It looks like the person get blocked at TYI1+20. I dont know anything about that part of the system yet.  Date: 19 May 1982 1233-EDT From: J. Noel Chiappa To: CAMCAD at MIT-MC cc: JNC at MIT-XX, bug-mail at MIT-AI, bug-its at MIT-AI, ellen at MIT-XX I doubt that ITS will ever implement InterNet, and I see no signs of them implementing SMTP. In the meantime, you can get mail from ITS to InterNet sites by sending mail to "person%final_host"@forwarder_host; I am told that the ISI sites provide such a forwarding arrangement; others, closer to MIT, should be appearing shortly. -------  Date: 18 May 1982 21:29-EDT From: David C. Plummer To: BUG-ITS at MIT-MC, BUGDDT at MIT-MC, JPG at MIT-MC, ELLEN at MIT-MC, MERMAN at MIT-MC I don't know if anybody else has checked recently, but all four SYS directories are at least 95% full. Should we try to clear some out, or go to SYS4; (gack).  DCP@MIT-MC 05/17/82 11:35:15 To: (BUG ITS) at MIT-MC I replied to GJC (it was a user's (perhaps not his own) .MASK variable).  GJC@MIT-MC 05/17/82 02:30:57 To: (BUG ITS) at MIT-MC Saw a funny thing on the system consol today: 223616/ 204202,,321560 204202,721560 STEVER 02:10:17 anybody know what that location might be?  Date: 15 May 1982 03:20-EDT From: David A. Moon Subject: MC mem D To: ELLEN at MIT-MC cc: BUG-ITS at MIT-MC The problem with memory D is massive trauma to its electrical outlet under the floor, and its plug. The plastic is melted and somewhat burned. I left the floor pulled up and the plug unplugged so you can see it. I don't know whether this is due to a fault of mem D itself, however I saw no evidence of burned wiring inside its power control. Neither the circuit breaker on mem D nor the one on the wall is blown. This will need the attention of some sort of electrician. By the way, could you ask whoever is in charge not to block off maintenance access to the MC machine? I shoved the offending desk out into the main passageway where it will cause a massacre if there is a fire--hopefully this will ensure that it gets moved to someplace reasonable soon (not shoved back in front of the machine where it blocks off the memory doors).  Date: 12 May 1982 18:49-EDT From: David Vinayak Wallace To: BUG-ITS at MIT-AI :f ken PARERR; 14603>>TDNN 4,(5) 4/ 1 50000/ TLZN 14,45602  Date: 11 May 1982 08:26-EDT From: Martin David Connor Subject: GFR25 To: BUG-ITS at MIT-AI Whoever did GFR 25 seems to have reaped the wrong files. Since some twit opened all the files on the system on 2 April, reference date was no good for reaping on. The XGP login init was reaped, along with a couple other files. Whoever did it, please fix it. Thanks. Marty  Date: Friday, 7 May 1982 18:15-EDT From: KLOTZ at BBNG To: bug-its at ai cc: pgs at BBNG Subject:ITS Message Header on net. I received the following message at BBNG. It has an ITS-style header. I believe the local twenex inserted the first two lines. Mail-from: MIT-AI Received-Date: 7-May-82 0244-EDT PGS@MIT-AI 05/07/82 01:37:54 To: klotz at BBNG Does this stuff work? (I mean a qsend from AI). ^_  Date: 7 May 1982 0947-EDT From: S. W. Galley Subject: strange ITS crash To: bug-its at MIT-AI I just now reloaded DM ITS after it was hung in user mode, but with the parity-stop and run lights on. I dumped it to DM:CRASH;COMSYS >, because the light for job #5 (COMSYS COMSYS) was lit. PC/ 725717, parity buffer/ 0, pager mem addr/ 1,,337717 (in ARM-10), parity error light off! -------  Date: 6 May 1982 03:38-EDT From: Patrick G. Sobalvarro To: BUG-ITS at MIT-AI I answered NEVES's question.  NEVES@MIT-MC 05/05/82 20:03:19 To: (BUG ITS) at MIT-MC SIGH... HOW DOES ONE GET A FILE FROM A CHAOSNET SITE SUCH AS SPEECH TO MIT-MC WHILE ON THE MIT-MC END? THE CFTP PROGRAM ON ITS DOESN'T SEEM TO BE THE APPROPRIATE THING TO USE BECAUSE IT DOESN'T ALLOW ONE TO LOGIN TO THE OTHER MACHINE. -DAVE  Date: 4 May 1982 20:21-EDT From: Christopher C. Stacy Subject: weird! To: BUG-COMSAT at MIT-AI cc: BUG-ITS at MIT-AI In COMSAT 380, ITS 1273, on MIT-AI: COMSAT was not properly delivering mail to GUMBY. The stats log says the mail was delivered, and he got CLI messages saying it had been. But the mail seems to have gone into a black hole. I temporarily changed his netaddress to MC; receiving mail on another host seems to work fine. I wonder how many other people have been losing mail, and how this could be happenning?  MOON@MIT-MC 05/02/82 01:55:58 Re: JOB: device To: ALAN at MIT-MC CC: (BUG ITS) at MIT-MC ALAN@MIT-MC 04/30/82 01:38:18 To: (BUG ITS) at MIT-MC Why does opening the JOB device with a non-existant file specified cause a job device handler creation/destruction loop? Is this bizare behavior necessary to enable some debugging hack? (Like where you write the file to be loaded after starting up the user??) Or is this a bug and the thing should return some reasonable error code instead? It might be that the bootstrap loader for the job has to fit in the AC's and doesn't have enough locations left to signal an error -- maybe it does a .LOGOUT thinking that will make ITS signal an error for it, but someone broke ITS to reload the job instead? Just a theory.  ALAN@MIT-MC 04/30/82 01:38:18 To: (BUG ITS) at MIT-MC Why does opening the JOB device with a non-existant file specified cause a job device handler creation/destruction loop? Is this bizare behavior necessary to enable some debugging hack? (Like where you write the file to be loaded after starting up the user??) Or is this a bug and the thing should return some reasonable error code instead?  ELLEN@MIT-MC 04/27/82 04:36:57 Re: Changing the default for :find To: (BUG ITS) at MIT-MC CC: GJC at MIT-MC GJC didn't exactly explain it, but a better way to state the desired change to the FIND program is, should be assumed for directory unless another directory specification is given, or *; is indicated. I think that covers it, is it possible? Thanks.  GJC@MIT-MC 04/26/82 17:15:25 To: (BUG ITS) at MIT-MC I think it would be a good thing to change the DEFAULT filename used by FIND. The reason is that many people on the "USERS" type directories use find to find their files, and these people invariably type something like :FIND FOO*** therefore they end up searching the entire filesystem. In many cases they aren't fully aware that they have been put on some directory USERS7 lets say, so FIND is their only reasonable tool for listing the files they own. Furthermore, if somebody does want to search the entire filesystem, (perhaps not such a rare thing to do back in the days of ITS when the FIND program was written) I think it reasonable to make the person type something like :FIND ******;FOO.  DEVON@MIT-MC 04/25/82 00:51:44 To: (BUG ITS) at MIT-MC is the Control-P Eye display code legit? Rumor sez that ^P I x outputs x in image mode, but I get weird cursor pos errors.  Date: Saturday, 24 April 1982, 20:46-EST From: David Vinayak Wallace Subject: Access from DC area To: Bug-its at MIT-AI Cc: info-cobol at MIT-AI Date: 23 Apr 1982 0809-EST From: PALLEN at MIT-DMS (Peter Allen) To: Bug-its at MIT-AI Subject: Access from DC area Message-id: <[MIT-DMS].230024> Hello! Is it my imagination but have you people turned off access from the Dc are ...WOW! Precognition!  Date: 23 Apr 1982 0809-EST From: PALLEN at MIT-DMS (Peter Allen) To: Bug-its at MIT-AI Subject: Access from DC area Message-id: <[MIT-DMS].230024> Hello! Is it my imagination but have you people turned off access from the Dc are  Date: 22 April 1982 19:43-EST From: Leigh L. Klotz To: BUG-PWORD at MIT-AI cc: BUG-ITS at MIT-AI On ai's pword, in :send, with an h19 or printing ttyps (at least), tab echoes as ^I, and rubout doesn't back up over carriage returns, although it deletes characters (as shown by ctrl-l). Who broke this? Leigh.  Date: 20 Apr 1982 1054-EST From: Robert W. Kerns To: MARTY at MIT-AI, BUG-ITS at MIT-AI cc: RWK at SCRC-TENEX In-Reply-To: Your message of 20-Apr-82 0105-EST This happens when you have enabled DDT to search directories recently looked at, and one of the directorys you recently looked at doesn't exist (locally). DDT is telling you the actual error it got. ITS is telling you what was wrong with what DDT gave it. DDT shouldn't be putting things on its list of recent directories without verifying that they exist, but I'm in no hurry to fix this very occasional minor annoyance. -------  Date: 20 April 1982 00:37-EST From: Martin David Connor To: BUG-ITS at MIT-AI Doing :o gives the error message "NON-EXISTENT DIRECTORY" should it not say file not found or something more informative? Marty  Date: 19 April 1982 22:39-EST From: Christopher C. Stacy To: EB at MIT-AI cc: BUG-ITS at MIT-AI If you have some files which you urgently want and they're zeroed on pack 15, why dont you ask for them to be restored by sending mail to File-Retrieve. Due to multiple theories about how to proceed, the original restoration process was somewhat screwed up. Now, things that arent asked for specially will get restored as people have time to do so.  Date: 19 April 1982 22:05-EST From: Edward Barton To: BUG-ITS at MIT-AI Is pack 15 ever going to have anything except zeros on it?  Date: 19 April 1982 02:06-EST From: Martin David Connor Subject: Anatomy of Lossage To: BUG-ITS at MIT-AI, USER-ACCOUNTS at MIT-AI, AGRE at MIT-AI, user-accounts at MIT-MC I examined the system log, and the lossage of last friday happened something like this. 1) a user logged in as MINI0, :CHUNAMed to CRETIN, and started to play. First he/she copied DDT to the file sys;z ddt, then copied that file to SYS3;TS OCTPUS . This would allow logging in from PWORD without a password. 2) CRETIN then logged out, and then ___010 took over. First he/she deleted PANDA, then LOCK. Account MINI0 has been deleted. As has account CRETIN. The OCTPUS (camaflaged DDT) has been deleted. LOCK has been reinstalled. The system is approximately as it was. Marty  Date: Friday, 16 April 1982, 01:12-EST From: David A. Moon To: Patrick G. Sobalvarro Cc: BUG-ITS at MIT-AI In-reply-to: The message of 15 Apr 82 12:49-EST from Patrick G. Sobalvarro Date: 15 April 1982 12:49-EST From: Patrick G. Sobalvarro To: BUG-ITS at MIT-AI This morning's crash is on AI:CRASH;1273 CRASH. It broke at 137720. Someone more knowledgeable than me should probably look at it. Incidentally, 137720 is nowhere near the TTY code, as nearly as I can tell. Memory was acting flakey two hours before the crash. This looks like an instruction failed to execute properly. The system job is trying to get rid of a running job in the mistaken impression that its bit saying that it has done a .LOGOUT and should go away is set. The bit is not set and there is no sign that it has been. (Possibly the job has already gone away and this is a new job that somehow took its place, since it looks like it is just starting up.) There isn't any sign of register U having been clobbered; it had the same value much earlier in SYSGUN when DMNPLO was called. If it was hot in the machine room at the time this crash occurred, it was most likely a hardware failure.  Date: 15 April 1982 12:49-EST From: Patrick G. Sobalvarro To: BUG-ITS at MIT-AI This morning's crash is on AI:CRASH;1273 CRASH. It broke at 137720. Someone more knowledgeable than me should probably look at it. Incidentally, 137720 is nowhere near the TTY code, as nearly as I can tell. Memory was acting flakey two hours before the crash.  Date: 14 April 1982 22:02-EST From: Patrick G. Sobalvarro To: ZVONA at MIT-AI cc: DPH at MIT-AI, BUG-ITS at MIT-AI Date: Wednesday, 14 April 1982, 16:55-EST From: David Chapman There's some bogosity here, but it isn't in ITS. What you are complaining about is not a bug, but a feature. ... the error message you got meant that the system was full, and a job slot couldn't be found to load the job into. Well then the bogosity is that ITS is not smart enough to interpret the error that it gets when it can't find a job slot for a jobdev job. I can hardly see that that is a feature. I'm not sure what you mean by this. If ITS weren't smart enough to understand the condition that occurs when it can't find a job slot for a jobdev job, it wouldn't give you an error message at all. It would just blow out. As it happens, ITS generates a perfectly good error message when it can't find a job slot for a jobdev job. In fact, in the cases you folks were reporting, DDT was even reporting the condition to the user. It IS a shame that the error message is the same as that given when one attempts to write to a full pack. If the AI lab had decided to continue using ITS, it would have been a good thing to modernize some of the error messages. At the time ITS was first written, they were probably the most informative error messages around. Nowadays, however, we have operating systems like Twenex that give you lowercase error messages, and nothing like the functionality of job devices. I can hardly see that this is a feature.  Date: 14 April 1982 21:13-EST From: Alan Bawden To: BUG-ITS at MIT-MC, Zvona at MIT-AI cc: DPH at MIT-MC, PGS at MIT-MC Well then the bogosity is that ITS is not smart enough to interpret the error that it gets when it can't find a job slot for a jobdev job. I can hardly see that that is a feature. No, the real problem is that the only mechanism ITS has to communicate the error to you is that it gets to return one of 47 (octal) error codes. If we were designing ITS today we probably wouldn't do things that way, but... Perhaps a better error code (one that corresponds to a better error message) could be chosen for this situation. I forget now just what it is that you DO get (device full?), but scanning the list I would say that 10 (%ENADV, "DEVICE NOT AVAILABLE") is nicely ambiguous about exactly why you lost in this situation (system full).  Date: 14 April 1982 21:13-EST From: Alan Bawden To: BUG-ITS at MIT-MC, Zvona at MIT-AI cc: DPH at MIT-MC, PGS at MIT-MC Well then the bogosity is that ITS is not smart enough to interpret the error that it gets when it can't find a job slot for a jobdev job. I can hardly see that that is a feature. No, the real problem is that the only mechanism ITS has to communicate the error to you is that it gets to return one of 47 (octal) error codes. If we were designing ITS today we probably wouldn't do things that way, but... Perhaps a better error code (one that corresponds to a better error message) could be chosen for this situation. I forget now just what it is that you DO get (device full?), but scanning the list I would say that 10 (%ENADV, "DEVICE NOT AVAILABLE") is nicely ambiguous about exactly why you lost in this situation (system full).  Date: Wednesday, 14 April 1982, 16:55-EST From: David Chapman To: PGS at MIT-AI, DPH at MIT-AI Cc: BUG-ITS at MIT-AI In-reply-to: The message of 14 Apr 82 16:14-EST from Patrick G. Sobalvarro There's some bogosity here, but it isn't in ITS. What you are complaining about is not a bug, but a feature. ... the error message you got meant that the system was full, and a job slot couldn't be found to load the job into. Well then the bogosity is that ITS is not smart enough to interpret the error that it gets when it can't find a job slot for a jobdev job. I can hardly see that that is a feature.  Date: 14 April 1982 16:14-EST From: Patrick G. Sobalvarro To: ZVONA at MIT-AI, DPH at MIT-AI cc: BUG-ITS at MIT-AI From: David Chapman Sender: DPH at MIT-AI mc^K => ERROR: OPEN: USR: DPH; - DEVICE FULL levitt^A => MC: USERS4; LEVITT MAIL - DEVICE FULL Obviously there is some fundamental bogosity here. There's some bogosity here, but it isn't in ITS. What you are complaining about is not a bug, but a feature. ITS has these things called JOBDEVs, or job devices. They are what allow you to access files on other machines, get a pretty printout of the XGP queue, list your directory in various nice formats, and all sorts of other nice things. When you attempt to access a device whose name is not recognized by ITS, ITS loads up a program called ATSIGN DEVICE, which searches for a file called JOBDEV on the directory DEVICE;. If it finds it, it loads it up and runs it. If it doesn't find it, it errors out. However, the error message you got meant that the system was full, and a job slot couldn't be found to load the job into.  Date: 14 April 1982 13:22-EST From: David Chapman Sender: DPH at MIT-AI To: BUG-ITS at MIT-AI mc^K => ERROR: OPEN: USR: DPH; - DEVICE FULL levitt^A => MC: USERS4; LEVITT MAIL - DEVICE FULL Obviously there is some fundamental bogosity here.  PGS@MIT-MC 04/11/82 07:04:00 To: MARTY at MIT-MC CC: (BUG ITS) at MIT-MC Marty, you recently made a change to TTYTYP >. When you made your change, you also added gratuitous spaces before the tty numbers given as arguments to the TTxxx macros, which made them not assemble properly. Please be more careful about this sort of thing if you're going to modify the sources.  Date: 10 April 1982 16:02-EST From: Martin David Connor Subject: OZ Shutdown To: BUG-ITS at MIT-AI, BUG-OZ at MIT-AI, WIZARDS-OF-OZ at MIT-AI Between friday night and saturday morning the following events occured: - One of the air conditioning package units began to put out 70 degree air (50 degrees is normal). - AI began to get massive amounts of ECC errors. So many that the console could not keep up. I called FIXIT to come and look at the A/C. They came and the temperature went back down some. At this point, with the help of RMS and RG I replaced defective chips in the Stardust memory. - Early Saturday morning OZ got a memory parity error and shut itself down. I am not certain this was caused by excessive heat. - I decided that there was no point in leaving it powered on with the air conditioning marginal, I powered down OZ. ----------- What is being done about the A/C problem: Physical plant claims that the air conditioning is "balanced" with the idea that the major sources of heat on the 9th floor are ML and DM. This was once true, and worked. it is no longer good enough. I am preparing a map of the 9th floor so that they can redistribute the A/C in a way that makes better sense. My map will be ready Monday morning, and hopefully they can come in the same day. ----------- What this means w.r.t. OZ coming up: DEC may decide to start the 72 acceptance test again because of the parity error. This could delay our getting the machine. ----------- Opinion: Since DEC has only taken 2 weeks so far, I am willing to be patient and get things done right rather than risk losing AI by making too fast a move. ----------- This is bothersome, but with all of the things that have gone right, this minor setback is just that, minor. News as it happens; Marty  Date: 9 April 1982 18:05-EST From: Christopher C. Stacy Subject: bogus ITS version number resolved To: BUG-ITS at MIT-AI When I reloaded AI this afternoon, I reassembled ITS so that the version number went up. AI now has ITS 1270, which has PGS's TS3TTY changes in it, as NITS. (DDT, PEEK, NAME repurified.)  Date: 8 April 1982 22:19-EST From: Christopher C. Stacy Subject: The :NAME program To: Moon at SCRC-TENEX cc: PGS at MIT-AI, AGRE at MIT-AI, BUG-ITS at MIT-AI, BUG-NAME at MIT-AI Date: Thursday, 8 April 1982, 17:22-EST From: David A. Moon Subject: The :NAME program To: pgs at MIT-AI, agre at MIT-AI, bug-its at MIT-AI, bug-name at MIT-AI Did someone do something like copy SYSBIN;NAME BIN to SYS;TS NAME ? Looks as though something like that happenned. I just reinstalled the binary and pure versions in the right places.  Date: Thursday, 8 April 1982, 17:22-EST From: David A. Moon Subject: The :NAME program To: pgs at MIT-AI, agre at MIT-AI, bug-its at MIT-AI, bug-name at MIT-AI The DEBUG switch is *supposed* to be set in SYSBIN;NAME BIN, the output of assembling NAME. The file SYS;TS NAME, the output of purifying NAME, is *not* the same file, does not contain the same stuff, and is not supposed to have the debug switch set. It also completely takes care of installing itself when a new system is put in or it is moved from machine to machine, as long as DEBUG isn't set to suppress that. Did someone do something like copy SYSBIN;NAME BIN to SYS;TS NAME ? It seems like a real waste for someone (not me) to have gone to a lot of trouble to make this program install itself automatically if people are going to go jamming monkey wrenches into the works anyway.  Date: 8 April 1982 12:11-EST From: Patrick G. Sobalvarro Subject: name and finger losing in this morning's ITS To: AGRE at MIT-AI cc: BUG-ITS at MIT-AI, BUG-NAME at MIT-AI NAME was reinitialized because we had a new system this morning, and someone had left DEBUG set in SYSBIN;NAME BIN, so it didn't kill itself when it was done. This is fixed now. NAME hackers should remember to clear DEBUG when making a new dump, or we get confused users.  Date: 8 April 1982 11:15-EST From: Philip E. Agre To: BUG-ITS at MIT-AI :NAME loses in the ITS that was brought up this morning. You get .VAL 0; 252>>.LOGOU 0/ 10400,,500000 when it's done.  Date: 6 April 1982 13:44-EST From: Leigh L. Klotz To: DCB at MIT-AI, RZ at MIT-AI, PSZ at MIT-AI, BUG-ITS at MIT-AI cc: CSTACY at MIT-AI Ai is having some sort of hardware-like trouble. It crashes with a BAD PI 2, and then gets wedged so that STOP/RESET/START gives the same BUGHLT error. That's very strange, since it's not even running ITS then. Anyway, one time when this happened just before ITS crashed it printed out 777144,,000000 DIRECTORY NTEXLB TRASHED, or something like that. The salvager didn't report anything unusual. Leigh.  Date: 6 Apr 1982 0952-EST From: PDL at MIT-XX To: GJS at MIT-MC, (BUG ITS) at MIT-MC In-Reply-To: Your message of 6-Apr-82 0107-EST No it doesn't; you asked it to find all "sav4 *" and script the results to mc:scheme;. You must quote the underbar with a ^Q. -------  Date: 6 April 1982 01:34-EST From: Patrick G. Sobalvarro To: GJS at MIT-MC cc: BUG-ITS at MIT-AI GJS@MIT-MC 04/06/82 01:07:00 I don't know where this bug should go, but :find mc:scheme;_sav4 * goes into an infinite loop. FIND's JCL syntax is pulling a quick one on you. "_" means "the thing that comes before this is an output file specification." So what happened was this: FIND looked for all files that matched the pattern SAV4 * on all directories on MC, and sent the output to SCHEME;FIND OUTPUT. Since FIND takes such a long time on MC, and it spends most of its time doing .OPENs, it looked like it was hanging in one .OPEN.  GJS@MIT-MC 04/06/82 01:12:50 To: (BUG ITS) at MIT-MC Sorry about last message -- bug seems to have disappeared after I renamed _SAV4 6 to FOO 1. The way it hung was in .OPEN. When renamed back to old name, it worked. Seems to be some kind of disk lossage, but I dunno how to describe it better. Perhaps the directory is slightly inconsistent or something?  GJS@MIT-MC 04/06/82 01:07:00 To: (BUG ITS) at MIT-MC I don't know where this bug should go, but :find mc:scheme;_sav4 * goes into an infinite loop.  Date: 31 March 1982 07:25-EST From: Glenn S. Burke Subject: fc lossage? To: BUG-its at MIT-AI cc: BUG-LISP at MIT-ML, EB at MIT-ML Date: 30 March 1982 19:31-EST From: Edward Barton :lisp LISP 2122 Alloc? n * (open "fc:eb;ef >") MPV; 61322>>.CALL 61641 (RCHST) ---- The MPV does not come from the call, and no words have been written by it. This does not happen on ML, where apparently no one has been updating DEVICE;JOBDEV FC for some time.  Date: Tuesday, 30 March 1982, 03:10-EST From: Robert W. Kerns Subject: OPEN To: Leigh L. Klotz Cc: BUG-DDT at MIT-AI, BUG-ITS at MIT-AI In-reply-to: The message of 27 Mar 82 18:05-EST from Leigh L. Klotz Date: 27 March 1982 18:05-EST From: Leigh L. Klotz Shouldn't OPEN on the tty for output cause ddt to ask you to give the tty to the job? It doesn't seem to. I first noticed this behavior several months ago with R, which would run apparently OK ^P'd, but print out the first error message (from processed text) as soon as P'd. I guess this is because it didn't open the tty until then, or something. I just ^Z'd a finger and ^P'd it before it had printed out the hostname in brackets. As soon as I P'd it, it printed that out. It hadn't asked for the tty. It always asks for me. Note that it's not OPEN that should ask for the TTY, but trying to use it.  Date: 27 March 1982 18:05-EST From: Leigh L. Klotz Subject: OPEN To: BUG-DDT at MIT-AI cc: BUG-ITS at MIT-AI Shouldn't OPEN on the tty for output cause ddt to ask you to give the tty to the job? It doesn't seem to. I first noticed this behavior several months ago with R, which would run apparently OK ^P'd, but print out the first error message (from processed text) as soon as P'd. I guess this is because it didn't open the tty until then, or something. I just ^Z'd a finger and ^P'd it before it had printed out the hostname in brackets. As soon as I P'd it, it printed that out. It hadn't asked for the tty. Leigh.  Date: 27 March 1982 12:03-EST From: Christopher C. Stacy To: BUG-ITS at MIT-AI AI now has ITS 1269 as ITS. The old NITS is named OITS, and there is no NITS or NITS1; we go back to the canonical naming conventions on this machine now. This version has a fix in the RENAMEF call by RMS, which is not the same as the patch by Moon. DDT and PEEK were repurified. Chris  Date: 27 March 1982 02:39-EST From: Patrick G. Sobalvarro To: BUG-ITS at MIT-AI Explanatory note about my last message - @ NITS1 was trashed in the crash tonight. We're running NITS right now. I was trying to recover @ NITS1 from backup.  Date: 27 March 1982 02:37-EST From: Patrick G. Sobalvarro To: BUG-ITS at MIT-AI I just tried to get @ NITS1 off backup; DUMP shows the version of 3/5 on tape 206. Unfortunately, tape 206 seems not to have any such file on it, although it has lots of other files on it. I suspect that this lossage is brought to us courtesy of the wonderful folks who are always leaving backup tapes strewn everywhere about the floor; that is, I think the tape I have is mislabelled. In any case, I think it'll be easier to generate @ NITS1 again than to find the right tape. Is there someplace I can find the patches and make them to NITS, or should I assemble a new ITS?  WJL@MIT-ML 03/26/82 09:20:37 Re: ttyvar documentation out of date To: (BUG ITS) at MIT-ML tctyp also has a number for Z19's thats not in the table -- are there others?  Date: 22 March 1982 15:42-EST From: David C. Plummer To: MOON at SCRC-TENEX cc: DCP at MIT-MC, BUG-ITS at MIT-MC, rsl at MIT-MULTICS Small techincal point: The RFC for SUPDUP says that %TPCBS MUST be on. Indeed, ITS doesn't care , but other systems may. So %TPMTA is ONLY used for hard wired terminals? This is unfortunate. For purposes of modularity, I think that ITP should only be a transport mechanism for 7, 8, or 12 bit characters and know nothing of the character set it is transporting. Once thee character is assembled at the server, the server should look at %TOFCI and %TPMTA (it doesn't make much sence for both to be on) and do the system dependent things to the characters. mumble... It's probaly not worth flaming about, since became an issue in my terminal concentrator code, and it looks like I will be using the 12.bit character set anyway...  Date: Monday, 22 March 1982 02:25-EST From: MOON at SCRC-TENEX To: dcp at mc cc: bug-its at mc, bug-supdup at mc, rsl at multics Date: 18 March 1982 16:11-EST From: David C. Plummer To: BUG-ITS at MIT-MC, BUG-SUPDUP at MIT-MC, rsl at MIT-MULTICS Suppose I have an AAA terminal that is capable of generating a META bit. Suppose further that it is connected to a terminal concentrator that will talk SUPDUP to ITS. Since it is SUPDUP, I am supposed to use the intelligent terminal protocol. Therefore, the TTYOPT bits I think I should send include %TOFCI OFF (can't do full character input) %TPMTA ON (does have a hardware META bit) %TPCBS ON (using ITP) %TPMTA means that bit 7 is the meta bit. You don't have to use ITP to be Supdup, but if you do use ITP you have to send the 12-bit character set, not the 8-bit character set, and thus you can't use %TPMTA. Probably you want to have %TOFCI off but still send characters with the %TXMTA bit. Now, sombody comes along and types META-A. This has a code of 301 (200+101). Now as I understand it, ITP is only a mechanism for transmitting bytes, and does not assume the 5 bucky bits that are part of %TOFCI. No. ITS is a mechanism for inputting the internal ITS 12-bit character set "directly" rather than going through the conversion from 8-bit "ascii" characters. Therefore when it gets reassembled on ITS, it gets assembled as 301. This is fine until the TYI normalizer gets to it, and says, "Oh, this is %TXCTL+A" and converts it into a ^A. Well, does that mean I should change a 301 into a 1101 (%TXMTA+A) before sending it? NOW, how does EMACS handle this? If I connected by a modem and sent META-A, would ITS convert this from 301 into 1101 when it puts it in the input buffer? What is the consistent model? How does EMACS deal with this? and Should the TYI 7-bit normalizer look at %TOFCI before it goes around looking for TOP, CONTROL and META bits? EMACS doesn't handle any of this. It sees only the 12-bit character set.  REM@MIT-MC 03/19/82 19:56:39 To: (BUG ITS) at MIT-MC Hmmm, in the middle of RMAIL typing out some text onto the screen, it stopped typing. I waited a minute or so but it didn't continue, so I tried to close network connection but it didn't close, so I RESET the TIP port and reconnected, but upon attaching to my detached tree after connect TTYAC4+4>> typed out something about can't get the TTY (which got overprinted by BUG when I backspaced and it decided to put the cursor where it should be instead of where it had been) and then entered that breakpoint (which is also now overtyped). I guess I'll see now if I can continue my RMAIL any.  Date: 18 March 1982 16:11-EST From: David C. Plummer To: BUG-ITS at MIT-MC, BUG-SUPDUP at MIT-MC, rsl at MIT-MULTICS Suppose I have an AAA terminal that is capable of generating a META bit. Suppose further that it is connected to a terminal concentrator that will talk SUPDUP to ITS. Since it is SUPDUP, I am supposed to use the intelligent terminal protocol. Therefore, the TTYOPT bits I think I should send include %TOFCI OFF (can't do full character input) %TPMTA ON (does have a hardware META bit) %TPCBS ON (using ITP) Now, sombody comes along and types META-A. This has a code of 301 (200+101). Now as I understand it, ITP is only a mechanism for transmitting bytes, and does not assume the 5 bucky bits that are part of %TOFCI. Therefore when it gets reassembled on ITS, it gets assembled as 301. This is fine until the TYI normalizer gets to it, and says, "Oh, this is %TXCTL+A" and converts it into a ^A. Well, does that mean I should change a 301 into a 1101 (%TXMTA+A) before sending it? NOW, how does EMACS handle this? If I connected by a modem and sent META-A, would ITS convert this from 301 into 1101 when it puts it in the input buffer? What is the consistent model? How does EMACS deal with this? and Should the TYI 7-bit normalizer look at %TOFCI before it goes around looking for TOP, CONTROL and META bits?  Date: 18 March 1982 01:47-EDT From: Edward Barton To: BUG-ITS at MIT-AI When the system is revived it often happens that the datapoint controller gets wedged somehow. The result is that VT52's and such do not get the revived message, or if the system got reloaded may not get the message saying the system is in operation. (I may be confused about that case.) Lock's DPK command fixes things if you manage to figure out that the system is in fact up even though your VT52 or Ambassador behaves as if it weren't. Is there some way a DPK could happen automatically when the system is revived?  CBF@MIT-MC 03/11/82 12:58:20 Re: your crash dump To: MOON at MIT-MC CC: DCP at MIT-MC, CBF at MIT-MC, (BUG ITS) at MIT-MC The PC is on the system console somplace of course, I think I might even have written it in the log.  MOON@MIT-MC 03/09/82 02:41:06 Re: your crash dump To: DCP at MIT-MC, CBF at MIT-MC CC: (BUG ITS) at MIT-MC DCP@MIT-MC 03/08/82 13:22:48 To: (BUG ITS) at MIT-MC MC was very sick earlier today. CBF dumped the original problem to CRASH WEDGED Since you don't say what the PC was, it's a bit hard to tell what's going on. It seems to be actively transferring on both disk controllers, but looping at UCPRL with interrupts inhibited. Was the PC written on paper somewhere?  DCP@MIT-MC 03/08/82 13:22:48 To: (BUG ITS) at MIT-MC MC was very sick earlier today. CBF dumped the original problem to CRASH WEDGED Some symptoms: most .OPENs and .IOTs hung. I could do DCP^F, DCP2^F .TEMP.^F, but not SYS^F, SYS1^F, or even TTY^F. This almost looks like a directory cache problem. Unit 4 (T-300) got several errors shortly before this all happened. Strangness: I could run programs that were in my directory (presumably becuase my directory was cache). After several attempts to reload, we succeeded, but we are not sure what caused it to win. We cycled all three T-300, power cycled unit 3, and set IMPUP/0 (thinking it might be the ARPAnet). Some combintation of this caused it to come up, finally.  DCP@MIT-MC 03/08/82 13:22:48 To: (BUG ITS) at MIT-MC MC was very sick earlier today. CBF dumped the original problem to CRASH WEDGED Some symptoms: most .OPENs and .IOTs hung. I could do DCP^F, DCP2^F .TEMP.^F, but not SYS^F, SYS1^F, or even TTY^F. This almost looks like a directory cache problem. Unit 4 (T-300) got several errors shortly before this all happened. Strangness: I could run programs that were in my directory (presumably becuase my directory was cache). After several attempts to reload, we succeeded, but we are not sure what caused it to win. We cycled all three T-300, power cycled unit 3, and set IMPUP/0 (thinking it might be the ARPAnet). Some combintation of this caused it to come up, finally.  HIC@MIT-MC (Sent by HIC0@MIT-MC) 03/07/82 21:03:25 To: (BUG ITS) at MIT-MC MC's IO-11 was wedged in some unknown fashion. I reloaded it from home, and it got fixed.  HIC@MIT-MC (Sent by HIC0@MIT-MC) 03/07/82 21:08:53 To: (BUG ITS) at MIT-MC Well, MC's IO-11 crashed again,and I reloaded it again. Maybe it's a more organic failure than I thought.  HIC@MIT-MC (Sent by HIC0@MIT-MC) 03/07/82 21:03:25 To: (BUG ITS) at MIT-MC MC's IO-11 was wedged in some unknown fashion. I reloaded it from home, and it got fixed.  MOON@MIT-MC 03/05/82 02:46:04 To: (BUG ITS) at MIT-MC The RFNAME system call is broken such that it trashes random locations in user memory. This was killing the mailer on MC, so I patched the running system and the dump. Patch is to change NRFNAM+22 from JUMPE Q,POPJ1 to JRST POPJ1. The bug is that the code assumes that device-dependent RFNAME routines don't clobber Q. The one for the Arpanet does.  dcp@MIT-MC (Sent by HGA@MIT-MC) 03/05/82 01:10:32 To: (BUG ITS) at MIT-MC I took a quick look, and somebody changed the RFNAME code between ITS version 1261 and 1266. Did this break things?  dcp@MIT-MC (Sent by HGA@MIT-MC) 03/05/82 01:03:35 To: (BUG ITS) at MIT-MC RFNAME on some NET: and some CHAOS: channels seems to be broken. This started happening within the last week I think. For an example, pick an ARPA telser and from PEEK try to look at is variables with the V command. This is causing comsat to die at the moment getting a a PURPG on an RFNAME of a CHAOS channel.  Date: 4 March 1982 18:45-EST From: Earl A. Killian Subject: hardware/microcode mod To: CSTACY at MIT-AI cc: BUG-its at MIT-AI I thought the Jump in JFFL was what the programmer does if there's a free Lispm.  Date: 4 March 1982 1604-EST (Thursday) From: Guy.Steele at CMU-10A To: Christopher C. Stacy Subject: Re: hardware/microcode mod CC: bug-its at MIT-AI In-Reply-To: Christopher C. Stacy's message of 4 Mar 82 02:06-EST I assume that the new instruction JFFL (Jump if Find Free Lispmachine) is equivalent to JUMP (Do Not Jump)! --Guy  Date: 4 March 1982 11:43-EST From: David C. Plummer Subject: hardware/microcode mod To: CSTACY at MIT-AI cc: INFO-COBOL at MIT-MC, BUG-ITS at MIT-AI :doc instr JFFL JFFL ac,E Jump on Find Free LispMachine skip if at least one free lisp machine matching some description the value at E contains an AOBJN pointer. The AOBJN pointer points to ASCIZ strings in one of two forms: - or CADR- The star convention is allowed for building and room. It is not allowed for the CADR number. ac is a pointer to a block of zero words followed by a non-zero word which will receive an string of 7-bit characters (similar to JCL passing). It is suggested that the non-zero word be 1, which will cause the string to be ASCIZ. The string returned is a list of rooms (without stars) or free machines separated by commas. Example: move ac,freeLM JFFL ac,[-3,,[ [asciz /NE43-8**/] ;an 8th floor cadr [asciz /CADR-2/] ;color [asciz /38-350/] ;EECS terminal room ]] jrst .-1 ;I just gotta have one freeLM: repeat 10,[ 0 ? ] 1  Date: 4 March 1982 02:06-EST From: Christopher C. Stacy Subject: hardware/microcode mod To: BUG-ITS at MIT-AI All ITS machines now have hardware for a new machine instruction: JFFL - Jump if Find Free Lispmachine  MOON5@MIT-MC 03/03/82 02:43:26 Re: Hitting CALL on one TV hangs all of them To: cstacy at MIT-AI CC: (BUG ITS) at MIT-MC Upon reflection, I think you are probably being faked out by the fact that when the system is brought up (on AI) the system job goes catatonic for a minute or two trying to type out "ITS IN OPERATION" on all the TK-10 terminals that aren't there. Then after the available 1 or 2 job slots get used up, you can't create any jobs until the system job comes back and processes the request to create more job slots. The right solution to this is to reassemble the system with TK10P turned off; unfortunately this will renumber all the terminals, and absolute tty numbers are known in several places. NAMDRG knows the number of the free-screen TV. DMNSTR knows the number of the xgp console. The TTYTYP file knows the numbers of all the terminals; NAME and NAMDRG read this in when purified or something.  Date: 3 March 1982 01:54-EST From: James M. Turner Subject: Disk Writes To: BUG-ITS at MIT-AI *sigh* Does it try to write even if the pack with the most space is not enough. Alternately, is there any way to "reserve" the proper amount of space (again, approximately) so the other can't snarf it?  MOON@MIT-MC 03/03/82 01:52:34 To: JMTURN at MIT-AI CC: (BUG ITS) at MIT-MC Date: 2 March 1982 23:14-EST From: James M. Turner To: BUG-ITS at MIT-AI the fact that various demons (notably INQUIR UPDATE) will try to create new files of estimatably size on packs without that much space seems unreasonable. Rather than have these programs tie up that time and space with unfinished files, why not have them make a rough guess as to the size of the file, and pick a pack accordingly. The present setup requires some poor hacker to clear off sufficient space for the update. Files are always written on the pack with the most space. Unfortunately, when the file takes a long time to write, someone else can come in and grab the space before the file finishes being written.  Date: 2 March 1982 23:14-EST From: James M. Turner To: BUG-ITS at MIT-AI the fact that various demons (notably INQUIR UPDATE) will try to create new files of estimatably size on packs without that much space seems unreasonable. Rather than have these programs tie up that time and space with unfinished files, why not have them make a rough guess as to the size of the file, and pick a pack accordingly. The present setup requires some poor hacker to clear off sufficient space for the update. James  DCP@MIT-MC 02/24/82 21:05:49 To: (BUG ITS) at MIT-MC I case anybody cares, the reason MC was down memory 200-577 was that the AMPEX start address switches were set wrong. My theory is that when DEC Field Circus re-enabled sector 0 a finger kept going in the up-right direction and flipped the address switch. There is now a piece of paper on the inside of the AMPEX door wich gives a correct setting of the switches.  CSTACY@MIT-MC 02/24/82 21:53:16 To: MOON at MIT-MC CC: (BUG ITS) at MIT-MC I renamed the ITS dumps on MC in the canonical fashion as you suggested. NITS1 is current, ITS is old. Next patched ITS should be dumped out as NITS. Older stuff migrated to OxITS files. Copy of NITS1 on BACKUP. Chris  Date: Wednesday, 24 February 1982, 20:20-EST From: Robert W. Kerns Subject: Abnormal LOGOUT TIMES To: Edward Barton Cc: BUG-ITS at MIT-AI In-reply-to: The message of 24 Feb 82 17:51-EST from Edward Barton Date: 24 February 1982 17:51-EST From: Edward Barton To: BUG-ITS at MIT-AI Is this peculiar segment of CHANNA;LOGOUT TIMES normal, and will it hurt anything? It seems to have the effect of making logout times for people beyond the discontinuity inaccessible to :when. RJA 01/17/82 01:33:18 RJD 02/24/82 09:21:18 RK 02/16/82 02:20:32 02/19/82 14:16:10 RLB 01/11/82 23:38:59 RLL 02/20/82 20:24:08 It's abnormal, delete that line.  Date: Wednesday, 24 February 1982, 20:15-EST From: Robert W. Kerns Subject: MC memory F To: BUG-ITS at MIT-AI Cc: MOON at SCRC-TENEX Could this be related to a power supply dying in that memory? DEC fixed a power supply after (I think it was) Mem F dropped dead yesterday. Ty called me yesterday just as I was about to go sleep, so I just told him to call DEC instead of looking at it myself.  Date: 24 February 1982 17:51-EST From: Edward Barton To: BUG-ITS at MIT-AI Is this peculiar segment of CHANNA;LOGOUT TIMES normal, and will it hurt anything? It seems to have the effect of making logout times for people beyond the discontinuity inaccessible to :when. RJA 01/17/82 01:33:18 RJD 02/24/82 09:21:18 RK 02/16/82 02:20:32 02/19/82 14:16:10 RLB 01/11/82 23:38:59 RLL 02/20/82 20:24:08  MOON@MIT-MC 02/23/82 13:56:58 Re: Status of MC To: (BUG ITS) at MIT-MC CRASH;@ FEB22 indicates that bank 7 of mem F is acting up again. I can't tell which half, but probably this indicates that it was sheer coincidence that the right half of this bank started working when DEC fixed it a while back. If anyone wants to debug this, a good start would be to swap bank 7 right with bank 6 right and bank 7 left with bank 5 left, then either get it to fail in a diagnostic or put it back on-line and see what addresses fail. The map of physical locations of memory banks is inside the front door of mem A or B.  Date: 23 February 1982 00:00-EST From: Daniel L. Weinreb To: CSTACY at MIT-AI cc: BUG-ITS at MIT-AI Ed and I just noticed that you left ATSIGN DDT as an SBLK file instead of as a PDUMP file; it was apparent because the system was so incredibly slow. We have fixed it; please be more careful.  CSTACY@MIT-MC 02/22/82 06:30:47 To: (BUG ITS) at MIT-MC Installed ITS version 1268 as NITS1, old one is still NITS. Seems to work. There are no memory patches here.  Date: 22 February 1982 05:06-EST From: Christopher C. Stacy To: BUG-ITS at MIT-AI AI is now running ITS 1268, which as dumped as NITS. The current memory patches are dumped. The former system version is now called ITS. Chris  Date: Friday, 12 February 1982, 12:18-EST From: David L. Andre Subject: nulls on ITS To: MHS at MIT-MC, BUG-LISPM at SCRC-TENEX, BUG-ITS at MIT-AI Cc: DLA at SCRC-TENEX From: MHS@MIT-MC Date: 02/11/82 18:53:27 I tried to DOVER AI:LMWIND;WINDOC PRESS and the file turned out to be a bad press file. Would whoever knows about such things be able to reformat it please? This is yet another manifestation of the fact that many if not most files on 15 consist of nulls. Is nobody ever going to fix this?  GZ@MIT-MC 02/05/82 01:09:24 To: (BUG ITS) at MIT-MC It seems that :tctyp t1061 now turns off more processing, it didn't use to (in fact today is the first time I noticed it)  ALAN@MIT-MC 01/31/82 23:35:04 To: (BUG ITS) at MIT-MC > doesn't work when opening any of the core-link devices. (who cares!)  Date: 28 January 1982 20:49-EST From: Leigh L. Klotz To: ED at MIT-AI, BUG-ITS at MIT-AI cc: GJC at MIT-AI I think putting in the idle time and maybe the commode bits is a good idea, but I think people use the core allocation value, especially on MC, where they get unhappy at the first hint of paging. I don't know if they use TTY^F rather than peek, though, so this may not be important. Leigh.  Date: 28 January 1982 19:45-EST From: Ed Schwalenberg Subject: TTY:.FILE. (DIR) To: BUG-ITS at MIT-AI How about flushing the totally useless CORE and TOTAL figures in favor of idle time and perhaps comm mode bits? This would cut down greatly on the use of NAME to get the idle time, which in turn would reduce thrashing due to hacking LSR1 greatly.  Date: 27 January 1982 12:35-EST From: Stavros M. Macrakis Subject: ULSPBR To: MOON at MIT-MC cc: BUG-ITS at MIT-MC Yes, I know it's unfinished; so presumably the variable can be flushed.  MOON@MIT-MC 01/27/82 04:07:08 Re: ULSPBR To: MACRAK at MIT-MC CC: (BUG ITS) at MIT-MC It's a feature that GLS never finished.  MACRAK@MIT-MC 01/26/82 23:42:06 To: (BUG ITS) at MIT-MC Any special reason for user variable Ulspbr? I don't think the "Special Lisp instructions" are ever used... (are they even in the microcode?) and anyway, .Uset lspbr is commented out. All that ever happens is that it's saved and restored.  Date: 26 January 1982 15:46-EST From: Stavros M. Macrakis Subject: Disk delay To: BUG-ITS at MIT-MC I tried to print (in ddt) the file Macrak;Scalrp > several times and it just wouldn't respond. I then tried it in Teco, where it didn't respond either, so I ^P'd and looked at the job's Flsins, which was (I believe this is accurate) Skipe Qsnloc+40 TRN ; i.e. the directory was locked. After about 20 secs, the Teco won. How could this happen? I wasn't trying to write, so it presumably wasn't a directory GC. I did not try looking at other files, so I don't know if it had to do with this particular file. Anyway, a curious incident. Thought you might like to know.  Date: 23 January 1982 14:26-EST From: David Vinayak Wallace To: BUG-ITS at MIT-AI the file ai:.info.;its locks cantains nothing but nulls. Perhaps other fies got destroyed in the crash?  Date: 22 January 1982 01:16-EST From: Richard M. Stallman To: BUG-ITS at MIT-AI AI crashed with QFUD/1 but every QSNUD was nonzero.  DCP@MIT-MC 01/16/82 12:02:31 To: GREN at MIT-MC CC: (BUG ITS) at MIT-MC [See .INFO.;ITS UFD and SYSTEM;FSDEFS for more info.] The third word of the UFD is the sixbit of the name of the directory. Of the five words in the NAME area that describe the file, the right half of the fifth word contains the UFD index of the file author's HSNAME. This is why the author of some files is GUESTn or somesuch. If there were more room in the five word block, actual sixbit of the author's XUNAME could be stored there, but...  GREN@MIT-MC 01/16/82 01:36:13 To: (BUG ITS) at MIT-MC Just a question, not a bug: In the UFD, is just an index into the MFD or something, and *not* 1 word of sixbit... I ask since an author (sname) that doesn;t exist on one site prints as -??- or something else equally uninformative...  MOON5@MIT-MC 01/13/82 16:37:57 Re: one-proceed broken on MC To: (BUG ITS) at MIT-MC This was caused by some unidentified cretin copying the file SYS:ATSIGN DDT from some other machine onto MC. The proper procedure is to load up SYSBIN;DDT BIN and start it at PURIFY. Don't let it happen again! (And maybe someone can fix DDT to print a warning if it is not on the machine and ITS version it is purified for reason. The reasons why it should print a warning rather than dying should be obvious.)  Date: 13 Jan 1982 1643-EST From: SWG at MIT-DMS (S. W. Galley) To: Mike at BRL Cc: BUG-ITS at MIT-AI, Gurus at BRL In-reply-to: Message of 18 Dec 81 at 0359 EST by mike@BRL Subject: [Re: :HISTORY Lossage on DMS] Message-id: <[MIT-DMS].219986> The bug you reported was caused by an obsolete module -- now updated -- used by the HISTORY program, which translates a host name to its address by mapping the host table into primary storage: this makes an MPV error ("memory protection violation") less surprising, but no less spectacular!  ED@MIT-AI 01/13/82 03:21:06 Re: Is one-proceed broken on MC? To: DCP at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC There is a well-known long-standing bug in the hardware which will never be fixed which causes a one-proceed which faults on instruction fetch to execute the following instruction as well (which may be on a different page and thus ...). This is not it. A much more dramatic demonstration is simply that  and  are now abbreviations for P. Emacs complains of PDL overflow when proceeded in this way, which explains some bizarre behavior when I accidentally typed a  the other day.  DCP@MIT-MC 01/12/82 22:08:27 Re: Is one-proceed broken on MC? To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC On MC running ITS 1249 (11/21/81), and DDT 1388 (always used to work) :ddt (no init) :job j 100/jfcl 1000g 100>>JFCL ^N ILOPR;101>>0 0/ 0 0/ 0 Well, what can I say? It works on AI 1250, DDT 1388. It works on ML 1256, DDT 1388. It works on DM 1254, DDT 1388. I'm pretty sure this was working as little as a week ago. Has somebody made a gross patch to the DDT on MC? Or is our beloved MC microcode sick? Or is ITS not doing the right thing with the microcode?  GSB@MIT-ML 01/11/82 14:35:49 Re: ml dialups To: RSG at MIT-ML, OAF at MIT-ML CC: (BUG ITS) at MIT-ML RSG@MIT-ML 01/11/82 10:34:25 I don't know exactly who to complain to about this, but it seems that 2 of ML's Vadic modems are broken. (TTY 4 and TTY 32 I think are the numbers of the broken ones; TTY 1 and TTY 11 are OK.) TTY 4 answers busy when nobody is logged in on it. TTY 32 just doesn't answer at all. ---- TTY 4 answers now. Presumably someone didn't hang up after logging out or after a crash. TTY 32's number isn't the same as it used to be (actually, it now IS the same as it used to be), it has been back to being 6733 for some time. It answers, although (as i reported some time ago) when i last tried to use it (at least a week ago) i got lots of garbage. p.s. ml dialups can be complained about to OAF with CC to me, or to me and i forward.  RSG@MIT-ML 01/11/82 10:34:25 To: GSB at MIT-ML, (BUG ITS) at MIT-ML CC: RSG at MIT-ML I don't know exactly who to complain to about this, but it seems that 2 of ML's Vadic modems are broken. (TTY 4 and TTY 32 I think are the numbers of the broken ones; TTY 1 and TTY 11 are OK.) TTY 4 answers busy when nobody is logged in on it. TTY 32 just doesn't answer at all. Cheers -- rsg  RMS@MIT-AI 01/11/82 01:03:27 Re: Purpg on CBLok Corblk To: MACRAK at MIT-MC CC: RWK at MIT-MC, (BUG ITS) at MIT-MC I will do something reasonable about this situation.  Date: 10 January 1982 21:15-EST From: Christopher C. Stacy Subject: where is the DISK listing To: BUG-ITS at MIT-AI I frequently borrow the source listings, and if I have one it can always be found in top of my desk in 926.  MACRAK@MIT-MC 01/10/82 21:13:51 Re: Purpg on CBLok Corblk To: RWK at MIT-MC CC: (BUG ITS) at MIT-MC 100/ setz 101/ $0'corblk$ 102/ 1000,,%cblok 103/ 1000,,-1 104/ 400000,,110 110/ -1,,0 .call 100$x Manages to make page 0 pure (!!??) and get a Purpg error. All I asked for was locking the pages in core (%cblok). I seem to remember my original example doing something weird with -2,,0 but not -1,,0, but the above will do for now. On the other hand, using %cblok+%cbndr+%cbndw works fine. Perhaps there are both documentation and code bugs?: some sort of specification of r/w status is needed?  RMS@MIT-MC 01/10/82 16:33:46 To: (BUG ITS) at MIT-MC I just fixed a but whereby TTYSET in a job which doesn't own the tty can clobber the RH of TTYSTS when the job gets the tty.  Date: 10 January 1982 15:50-EST From: Richard M. Stallman To: BUG-ITS at MIT-AI Does anyone know where the listing of DISK is?  Date: 10 January 1982 15:50-EST From: Richard M. Stallman To: BUG-ITS at MIT-AI AI crashed at QCH3+3 because QFCHN was nonzero. It was 1. Looking thru the QUSR words, I found that there was indeed a free channel, which the loop at QCH2 had not found. Perhaps there is something that can free a disk channel while QCHSW is locked? If so, the error check has to be removed or done with interrupts locked.  Date: 10 January 1982 13:26-EST From: Stavros M. Macrakis Subject: PURPG in CORBLK call (incorrect analysis) To: RWK at MIT-MC cc: BUG-ITS at MIT-MC But none of my pages were pure.  DCP@MIT-MC 01/10/82 00:43:17 Re: CHAOS slots on MC To: (BUG ITS) at MIT-MC Should the number of CHAOS connections on MC be raised to 64, or should I CONTINUE to have to gun down (LISP Machine) file servers (usually about 10) every time the connection table gets hopelessly full?  RWK@MIT-MC 01/08/82 08:09:54 Re: PURPG in CORBLK call To: MACRAK at MIT-MC CC: (BUG ITS) at MIT-MC The error is right, it is getting a PURPG error attempting to write back the updated AOBJN pointer you supplied. You can't use a literal for an updated argument!  MACRAK@MIT-MC 01/07/82 19:45:02 To: (BUG ITS) at MIT-MC .call [setz?'corblk? %climm,,%cblok ? %climm,,-1 ? setz(%clin) [-2,,0] ] (in a job with .memt/4000) gives Purpg. Now, the call may be wrong (because of missing arg 5), but Purpg seems like the wrong error to give. It also isn't clear from the documentation that arg 5 is needed in this case, since with arg 3 = [-1,,0], arg 5 is NOT needed.  Date: 4 January 1982 23:00-EST From: David L. Andre To: BUG-ITS at MIT-AI cc: DLA at MIT-AI When are the files on pack three going to have real contents again? I'm being screwed again and again when the file system thinks that the contents are there, but I get all zeros. I'd much rather get an error "PACK NOT MOUNTED" than get bad data.  MACRAK@MIT-MC 01/04/82 20:09:31 To: (BUG ITS) at MIT-MC Is .info.;its corblk needed given its .calls?  MARTY@MIT-MC 01/04/82 18:12:48 To: (BUG ITS) at MIT-MC I was wondering if we get a DEC-20 and we use ITS, if we could call it TWITS?  MOON@MIT-MC 01/04/82 14:30:02 Re: AOSG not working with .HANG To: MACRAK at MIT-MC CC: (BUG ITS) at MIT-MC This is fixed in the source; the sense of the skip condition was backwards because the operands of the instruction were interchanged.  MACRAK@MIT-MC 01/04/82 13:19:23 To: (BUG ITS) at MIT-MC 100/ aosg 200 101/ .hang 200/ -5 increments c(200) up to -1, then stops, never skipping! What's weirder is that 100/aose 200 only increments 200 once! And this is despite all sorts of ^X^P'ing and memory examination which, one would think, would PClsr all over the place.  MOON@MIT-MC 12/29/81 13:06:56 Re: STY question To: MACRAK at MIT-MC CC: (BUG ITS) at MIT-MC MACRAK@MIT-MC 12/28/81 19:51:16 To: (BUG ITS) at MIT-MC How do you check if the far end (user) of a STY is waiting for input? :doc .call styget It's documented to "probably not work very well". I don't know whether or not that is true.  MACRAK@MIT-MC 12/28/81 19:51:16 To: (BUG ITS) at MIT-MC How do you check if the far end (user) of a STY is waiting for input?  JPG@MIT-MC 12/28/81 16:39:38 To: (BUG ITS) at MIT-MC My apologies for my recent BUG-ITS notes. I forgot I was logged in as JEFFG when I typed X^K, and the error message was not at all helpful in this regard.  JEFFG@MIT-MC 12/28/81 16:19:41 Re: continuation: To: (BUG ITS) at MIT-MC Oops: X^K now gives "CAN'T READ DISK FILE".  JEFFG@MIT-MC 12/28/81 16:18:52 To: (BUG ITS) at MIT-MC Why does :XFILE JPG;JPG ^Q_X work, but not X^K ? The latter has always done the trick in the past.  Date: 18 Dec 81 3:59:26-EST (Fri) From: Michael Muuss To: BUG-ITS at Mit-Ai cc: Gurus at BRL Subject: :HISTORY Lossage on DMS Via: BMD70; 18 Dec 81 4:01-EDT I ran this on DMS before I realized that BRL-BMD has probably not been added to the host tables yet. However, the result was sufficiently spectacular that I figured somebody would like to hear. Cheers! -Mike --------------------------------------- *:history brl-bmd *ERROR* DANGEROUS-INTERRUPT-NOT-HANDLED MPV!-INTERRUPTS #WORD *310000634117* LISTENING-AT-LEVEL 2 PROCESS 1 ^S :KILL * ---------------------------------------  GSB@MIT-ML 12/16/81 15:44:22 To: (BUG ITS) at MIT-ML CADR, CADDR, and CADDDR should be synonyms for the SECOND, THIRD, and FOURTH devices. Perhaps also there should be an NTH device which is the "last" one in the sequence, for not-quite-tape archival.  Date: 15 December 1981 19:21-EST From: Earl A. Killian To: DEVON at MIT-ML cc: BUG-ITS at MIT-ML Date: 12/12/81 18:21:15 From: DEVON at MIT-ML Of course this penalizes a (hypothetical?) user with lines of 128 or longer in favor of a user with slow connection, but does anyone really want 128. characters on a line? Yes. Date: 12/15/81 03:45:44 From: DEVON What should happen if a multi-character sequence like %TVMV0 gets an argument byte valued 214? It moves to that line/column of course. Is this to be taken as a %TDORS which has already flushed the real argument bytes further up the pipeline? No. Or must every buffer know about such sequences and delay the action of a %TDORS until this situation won't arise, Something like that. or do argument bytes 214 and 215 get quoted by %TDQOT? No, that's not at all the function of %TDQOT.  DEVON@MIT-MC 12/15/81 03:45:44 Re: SUPDUP To: (BUG ITS) at MIT-MC What should happen if a multi-character sequence like %TVMV0 gets an argument byte valued 214? Is this to be taken as a %TDORS which has already flushed the real argument bytes further up the pipeline? Or must every buffer know about such sequences and delay the action of a %TDORS until this situation won't arise, or do argument bytes 214 and 215 get quoted by %TDQOT?  DEVON@MIT-ML 12/12/81 18:21:15 To: (BUG ITS) at MIT-ML Another Output-Reset related gripe: when output characters reach the level where flow control happens, they are no longer flushable. This means that during a long listing I can type ^S (knowing that DDT will eventually shut up ten-twenty lines later) and before output stops I can use the intelligent terminal protocol to stop and start output several times, bacause response speed to flow control is an order of magnitude better than the response to ^S. If multi-character %td sequences were forbidden argument bytes >177 then %tdors would behave more like a genuine out-of-band signal, and maybe that would make it permissible to flush a buffer without knowing about multi-character sequences. Of course this penalizes a (hypothetical?) user with lines of 128 or longer in favor of a user with slow connection, but does anyone really want 128. characters on a line?  MOON@MIT-MC 12/11/81 14:59:30 Re: When does ITS send %TDMOV ? To: DEVON at MIT-MC CC: (BUG ITS) at MIT-MC When %TOMVU isn't set, thus the terminal needs to know where it's coming from as well as where it's going to. This would be the case on printing terminals. User-mode programs such as Emacs and Macsyma may send it in other circurmstances as well.  DEVON@MIT-MC 12/11/81 02:33:38 To: (BUG ITS) at MIT-MC when does ITS use %tdmov instead of %tdmv0? I never recieved (or bothered to implement) %tdmov on my terminal until just now, while testing a gross kludge that changes my tctyp to printing momentarily, upon changing it back I got all %tdmov's for a while. I'd like to know how to induce ITS to revert to the shorter %tdmv0.  Date: 6 December 1981 01:31-EST From: Christopher C. Stacy To: ALAN at MIT-MC cc: CHRIS at MIT-MC, BUG-ITS at MIT-MC, BUG-DDT at MIT-MC, DCP at MIT-MC ALAN@MIT-MC 12/05/81 16:22:32 Am I to understand that this means that version 1388 of DDT has ... Pissed off,Alan No.  ALAN@MIT-MC 12/05/81 16:42:00 To: (BUG ITS) at MIT-MC CC: (BUG DDT) at MIT-MC I reinstalled the old version of ddt  ALAN@MIT-MC 12/05/81 16:22:32 To: CHRIS at MIT-MC, (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC To: DCP at MIT-MC DCP@MIT-MC 12/05/81 14:06:07 To: CHRIS at MIT-AI CC: (BUG ITS) at MIT-MC CHRIS@MIT-AI 12/05/81 10:33:43 I reassembled and installed DDT 1388 on MC so that it will use the correct new hsname scheme. Chris Please do not make modifications to existing installed code without upping the version number. Some people's ready messages are assembled code and expect certain entrypoints within DDT. The loader checks to see if the version has changed, and if so does not load the ready message. Am I to understand that this means that version 1388 of DDT has a different mapping from symbols to locations depending on what MACHINE it is running on? That is TOTALLY unacceptable and completely brain-damaged. What good is a goddamned VERSION NUMBER anyway if you don't CHANGE it when you change the VERSION!!! Pissed off, Alan  Date: 5-DEC-1981 16:02:44.12 From: Robert W. Kerns Reply-to: RWK at MIT-MC Subject: DDT Pseudo-1138 To: CHRIS at MIT-MC Cc: BUG-ITS at MIT-MC Please undo your installation. You have re-installed a large set of bugs, since there were a lot of patches made to 1138. I'll talk to you about getting the HSNAME stuff in.  DCP@MIT-MC 12/05/81 14:06:07 To: CHRIS at MIT-AI CC: (BUG ITS) at MIT-MC CHRIS@MIT-AI 12/05/81 10:33:43 I reassembled and installed DDT 1388 on MC so that it will use the correct new hsname scheme. Chris Please do not make modifications to existing installed code without upping the version number. Some people's ready messages are assembled code and expect certain entrypoints within DDT. The loader checks to see if the version has changed, and if so does not load the ready message.  CHRIS@MIT-AI 12/05/81 10:33:43 To: (BUG its) at MIT-MC CC: CSTACY at MIT-AI I reassembled and installed DDT 1388 on MC so that it will use the correct new hsname scheme. Chris  MOON@MIT-MC 12/02/81 15:20:04 Re: System console To: CBF at MIT-MC CC: (BUG ITS) at MIT-MC I don't think it's easy to make different consoles have different size buffers. What information is it that you want to see?  ELLEN@MIT-MC 12/01/81 16:43:39 To: (BUG ITS) at MIT-MC On MC, when a new user logs in INQUIR no longer queries him to fill it out.  ELLEN@MIT-MC 12/01/81 17:03:45 Re: Previous message about INQUIR To: (BUG ITS) at MIT-MC Sorry, never mind, I just realized that someone had deleted the * LOGIN file on the GUEST0; directory on MC, which is what was calling INQUIR.  Date: 1 Dec 1981 1504-EST From: SWG at MIT-DMS (S. W. Galley) To: gsb at MIT-DMS Cc: BUG-its at MIT-DMS In-reply-to: <[MIT-DMS].216669> Subject: [Re: BUG => itsfgsbsdm's] Message-id: <[MIT-DMS].216742> I set DM's T00 width to 80. in TTYTYP 238.  CBF@MIT-MC 11/28/81 19:44:21 Re: System console To: (BUG ITS) at MIT-MC With the rate of activity on MC nowadays (actually for a couple of years) now, I've noticed that spying on the system console (or using :SYSMSG) has less and less often given me the information I was looking for. Frequently all one can see is the last 20 seconds of activity. Anyway, this is a suggestion that the system console's buffer be made substantially larger. If things work the way I guess they do, the only substantial disadvantage I can think of this having is that output resets on that terminal when it is being used an an ordinary terminal will take a long time.  Date: 22 November 1981 04:00-EST From: Chris Stacy Subject: last message To: BUG-ITS at MIT-AI Foo. I just found out what UNAME is.  Date: 22 November 1981 03:56-EST From: Chris Stacy To: BUG-ITS at MIT-AI ITS crashed in ZUSER2. The UNAME was SYS (USER=0). Examined some stuff on the TTY and reloaded ITS.  GSB@MIT-ML 11/20/81 17:26:30 To: (BUG ITS) at MIT-ML cstacy@MIT-ML (Sent by ___031@MIT-ML) 11/20/81 11:45:53 :TIME says ML ITS has run for over 287 days, but I know that it was reloaded a few minutes ago. the second value returned by RQDATE sez the system was brought up in 1983 (or should i interpret that as 1883?). The time program claims in the source to not handle uptimes greater than a year, so that explains why it says 287 days rather than 98 years.  MOON@MIT-MC 11/19/81 14:58:07 Re: :REATTA broken To: DCP at MIT-MC CC: (BUG ITS) at MIT-MC I changed the ATTACH system call to call ATTYCI rather than ATTYC2. A new system ought to get installed on MC soon. RMS, is this the correct fix?  DCP@MIT-MC 11/18/81 11:03:38 To: (BUG ITS) at MIT-MC Has the REATTA symbolic system call been changed (since may or so)? Has anybody else not been able to use the :REATTA program? :REATTA hasn't changed since December 1978, yet I have not been able to sucessfully use this program for a month (at least). Specifics: (from a space cadet keyboard over the chaos net) dcp0u :detach dcp0u --Attach your detached tree-- :reatta dcp/k ;;; at this point, nothing happens, but if I hit ;;; I get another PWORD, so I got detached again!! dcp0u --You have several detached trees-- --Attach a detached tree-- ERROR: ATTACH: BAD CHANNEL NUMBER 375>>.CALL 1046 (ATTACH) ;;; This is :REATTA bombing :calprt Arg 1: 3 ;;; JOB channel Arg 2: 400042 ;;; TTY to attach it to Control bits: 400000 :ichan 3 USR: DCP HACTRO (uai\10) ;;; looks valid to me. :vv DCP HACTRO 2 DCP; Det +15:11 ;;; the disowned tree DCP HACTRN ... DCP; ... I did a little poking: I can understand why (SYSTEM;ITS)NATTAC calls (SYSTEM;TS3TTY)ATTYC2 to decode the tty number, but why does ATTYC2 JRST to ATTYC7 instead of to ATTYC8. ATTYC7 does not allow 400000+ttynum but ATTYC8 does (that is the only difference between the routines).  DCP@MIT-MC 11/12/81 12:46:39 To: JPG at MIT-MC CC: (BUG ITS) at MIT-MC, ASB at MIT-MC, GJC at MIT-MC I did a little poking around and found the following: There is a mojor difference between TS3TTY 301 and TS#TTY 305. The majority of the difference seems to be in the ATTY** routines (the ones that determine if you have the TTY and whether you should wait for it). I tried the the following: a^K factor(ratsimp((x+y)^12)); ^Z ^P now I typed RETURN several times (say 20). After the 10th I got the message JOB A WANTS THE TTY. Macsyma wanted to SIOT. I looked at the siot string and it contained %TDMV1 codes among other things. When you P the macsyma you will see that the cursor goes to just above the JOB A WANTS THE TTY message, NOT where you left off and NOT where you happened to be. The culprit: RCPOS (Read cursor pos). In the rearrangement of the ATTY** routines it appears RCPOS has been changed to allow you to read the cursor even when you don't have the tty (it used to wait for the TTY). Unfortunately, MACSYMA uses this information to compute %TD codes.  JPG@MIT-MC 11/12/81 04:41:53 To: (BUG ITS) at MIT-MC CC: JPG at MIT-MC, ASB at MIT-MC, GJC at MIT-MC On about 10/29/81 I noticed that MACSYMA was misbehaving when it was $Ped after having been ^Zed and ^Ped. Namely the cursorpos calculation was off and it displayed the next expression one or two rows too high. Just now I showed it to RWK, and as we suspected it was an ITS (TS3TTY) problem, we transferred the MACSYMA over to ML which is running an older ITS (#1230 as opposed to #1244) and tried the same experiment there where it ran fine. The difference was that you get the interrupt for "Job wants the TTY" at an earlier point on ML than on MC, namely at CRSRP1+4>>.CALL RCPOS (which presumably does the necessary cursorpos recalculation) rather than at IFORCE+11>>.CALL SIOT . If it is relevant, I am on a VT52. Also, the thing I ask MACSYMA to do is FACTOR(RATSIMP((X+Y)^20)); which just uses up some time, so while it is computing, I ^Z ^P , and $P when it says "Job wants the TTY". (Sorry I am so verbose, but I wanted to make sure I included whatever info may be necessary.)  GJC@MIT-MC 11/09/81 11:39:10 To: (BUG ITS) at MIT-MC Right now there are about 20 NETRFC jobs from MIT-XX, all in the FINISH state and not doing anything else, but taking up net ports. I've gunned them down.  DCP@MIT-MC 11/07/81 20:08:50 Re: SCML system call To: (BUG ITS) at MIT-MC, RK at MIT-MC Why does SCML cause an error when it tries to set the echo area and it does not have the TTY? :CALL SCML does not say there are any errors for this system call. In fact, the routine ASCML in SYSTEM;TS3TTY puts the echo area in a magic field with DPB B,[$TBECL,,TTYTBL(U)] Which I guess will get put in the right place when the job gets .DTTY'd. But after the DBP it does a POPJ P, causing an error instead of AOS (P) POPJ P, which would appear to be the right thing.  Date: 6 November 1981 11:47-EST From: Richard C. Waters To: BUG-ITS at MIT-AI dump is broken in a weird way. if you try to list the files on a tape on dsk it gives you the error message that the file dsk:wall 1 doesn't exist, and just won't do anything. Dick  MOON@MIT-MC 10/28/81 19:23:06 Re: Installing TX XTEX To: DCB at MIT-MC CC: (BUG INSTALL) at MIT-MC, (BUG ITS) at MIT-MC This program doesn't work with files longer than 128K words (due to overflow problems in a halfword). It should be rewritten, for this and numerous other reasons. Volunteers?  Date: 27 Oct 1981 1518-EST From: SWG at MIT-DMS (S. W. Galley) To: MOON at MIT-MC Cc: (BUG ITS) at MIT-DMS In-reply-to: Message of 21 Oct 81 at 1502 EDT by MOON@MIT-MC Subject: [Re: catatonia - ACs/ JRST 4,] Message-id: <[MIT-DMS].213675> The PI lights at the time indicated normal states, I believe: PI IN PROGRESS [none] PI REQUEST [none] PI ACTIVE 1-7 IOB PI REQUEST 2,3,7 Curiously, the parity buffer didn't match the instruction register: INSN+MA/ 344000,,17 [AOJA 17] PAR BUFF/ 354000,,17 [AOSA 17], ODD, STOP I suppose your theory about some glitch turning off the PI system is a good one.  RLB@MIT-MC 10/27/81 02:17:45 To: (BUG ITS) at MIT-MC MC's T300 lossages of 7pm this evening noted in system log occurred while I had an Emacs writing lots of blocks to FOURTH:, like 10000 :ew... 100  Moon@MIT-MC 10/26/81 01:16:09 Re: System crashing works differently To: (BUG ITS) at MIT-MC ITS 1243, which has been installed on MC for a week or so now, does its crashing differently. Most halts (JRST 4,.) have been replaced with the new BUG macro, which types a message and goes to DDT. Documentation on this macro may be found in the source, where it is defined, near the front of ITS >. The BUG macro also replaces the SYSMSG facility. When this system is installed on other machines, it would be a good idea to install a new non-timesharing DDT along with it. Assemble MC:SYSTEM;DDT. The only change is to enable the feature of typing P to revive the system from a non-fatal error to work. Also install MC:SYS:TS SYSMSG when and where the new system is installed.  Date: 25 Oct 1981 2228-EST From: CSTACY at MIT-DMS (Christopher C. Stacy) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].213553> The DOVER program on DM thinks there is a chaosnet here and tried to use undefined system calls when it cannot spool to MC. It should just bomb out.  Date: 23 October 1981 21:57-EDT From: David A. Moon Subject: ITS IMP lossage To: JNC at MIT-XX cc: BUG-its at MIT-AI, jan at MIT-XX Date: 23 Oct 1981 1026-EDT From: J. Noel Chiappa Subject: ITS IMP lossage To: jan at MIT-XX, bug-its at MIT-AI cc: JNC at MIT-XX When an IMP goes down and is reloaded, ITS does not do the right thing in terms of bringing the net back up. It's necessary to go do a LOCK/N by hand to bring it up. This is not actually true. The time when ITS does not bring it back up is when it goes down several times in rapid succession (within 30 seconds I think), after which it decides that it must be broken and leaves it down.  MOON@MIT-MC 10/21/81 15:02:29 Re: catatonia - ACs/ JRST 4, To: SWG at MIT-DMS CC: (BUG ITS) at MIT-DMS Date: 21 Oct 1981 1105-EDT From: SWG at MIT-DMS (S. W. Galley) To: BUG-ITS at MIT-DMS Subject: catatonia - ACs/ JRST 4, Message-id: <[MIT-DMS].213236> Yesterday DM entered a catatonic state: in user mode, only the null job running, no response to ^Z or the left-most data switch. I stopped it with the STOP key and dumped it to DM:.;CRASH 6089. The ACs were clobbered: 0/ JRST 4,325 1-16/ JRST 4, 17=U/ AOJA U. XUUOH/ 700000,,STYO+1. Truly strange! Those are the correct ACs for the null job. Everything in the crash dump looks completely normal. You didn't say what the PI lights indicated; perhaps a power surge or static electricity turned off the PI system or stopped the machine or otherwise made it not take interrupts.  Date: 23 Oct 1981 1026-EDT From: J. Noel Chiappa Subject: ITS IMP lossage To: jan at MIT-XX, bug-its at MIT-AI cc: JNC at MIT-XX When an IMP goes down and is reloaded, ITS does not do the right thing in terms of bringing the net back up. It's necessary to go do a LOCK/N by hand to bring it up. I'm too burned out to grovel over the code and figure out what it does do and should do; perhaps someone would like to tackle this? -------  Date: 21 Oct 1981 1105-EDT From: SWG at MIT-DMS (S. W. Galley) To: BUG-ITS at MIT-DMS Subject: catatonia - ACs/ JRST 4, Message-id: <[MIT-DMS].213236> Yesterday DM entered a catatonic state: in user mode, only the null job running, no response to ^Z or the left-most data switch. I stopped it with the STOP key and dumped it to DM:.;CRASH 6089. The ACs were clobbered: 0/ JRST 4,325 1-16/ JRST 4, 17=U/ AOJA U. XUUOH/ 700000,,STYO+1. Truly strange!  Date: 14 October 1981 14:31-EDT From: Mike McMahon To: BUG-ITS at MIT-AI SYSTEM;FSDEFS 36 is broken. UDBLKS is multiply defined.  Date: 12 October 1981 20:49-EDT From: Christopher C. Stacy Subject: Jobs magically appearing (Robert P. Krajewski ) To: BUG-ITS at MIT-MC, BUG-PWORD at MIT-MC I responded to this person.  Date: 12 Oct 1981 1554-EDT From: Robert P. Krajewski Subject: Jobs magically appearing To: BUG-ITS at MIT-MC cc: BUG-PWORD at MIT-MC When I came over to AI via the CHAOSnet (from MIT-EECS), I decided to list my jobs BEFORE logging in (for no apparent reason). This is what I got: $$v * CONIVR P 63 EMACS P 24 MAIL P 25 LISP R 5 FOO - 17 MACSYM R 34 PLANER R 45 DIRECT P 57 UNIVERSE-SIMULATION W 107 *:version AI ITS.1223. PWORD.2449. TTY 42 16. Lusers, Fair Share = 29% *:time The time is 15:45:36 EDT. Today is Monday, the 12th of October, 1981. AI ITS 1223 has run for 1 day, 15 hours, 45 minutes, 28 seconds. :KILL *$$u AI ITS 1223 Console 42 Free. 15:45:46 The only thing I did before logging in was a finger. How can this be ? I noticed that AI PWORD's appearance had changed a little. bob -------  KLOTZ@MIT-MC 10/07/81 06:24:16 Re: --More-- To: (BUG ITS) at MIT-MC In the past couple of weeks, I've noticed that --more-- breaks have done some unusual things. I don't remembere then doing this before, but I'm not sure. Just now, a proceeded job tried to print out something, while my hactrn was in the middle of printing a page (of mail, read with ). When the --more-- appeared, it acted as if it got a space immediately and went to the next page. This was just now on a Vt52 on mc. Last week, I was using a dissapoint over a dialup, and every CLI interrupt would cause --more-- to flush. This may be the disappoint being random, but it didn't happen any other time.  seems to have a problem with --more--, too. A couple of times I've typed  while in the middle of a page and gotten "--more--flushed " printed out. This was on a dialup. Leigh.  RLB@MIT-MC 10/07/81 00:52:01 To: (BUG ITS) at MIT-MC I see I dumped the earlier MC crash to .;CORPG0 4 Handwriting in the log doesn't make it to BUG-ITS, does it?  Date: 6 October 1981 1808-EDT (Tuesday) From: Guy.Steele at CMU-10A To: glr at MIT-AI Subject: Re: > name conventions CC: bug-its at MIT-AI In-Reply-To: Ken Harrenstien's message of 6 Oct 81 16:52-EST Message-Id: <06Oct81 180837 GS70@CMU-10A> Ideas about making ">" do the right thing seem to pop up about twice a year for a last five or six years. No one seems to have gotten sufficiently excited about it to grovel through the ITS file directory code, though. (I think it was a major triumph when it was reorganized so that directories were kept sorted instead of re-sorting each time one was opened in ASCII mode; and another when directory GC was grossly sped up so it didn't take time n^3. I doubt the code has been touched in ten years except for those (actually, it probably has, but not significantly).) Anyone else know anything about this? --Guy  Date: 6 October 1981 17:52-EDT From: Ken Harrenstien Subject: > name conventions To: GLR at MIT-AI cc: BUG-ITS at MIT-AI That actually sounds like a good idea. I don't know if anyone is still keeping a list of ITS things-to-do, though.  Date: 6 October 1981 12:04-EDT From: Jerry Roylance Subject: > name conventions To: BUG-ITS at MIT-AI The naming conventions for an FN1 or FN2 of > could be changed to allow file extentions and version numbers. Say my directory has these files: DSK:FOO; BAR FASL DSK:FOO; BAR LSP123 DSK:FOO; BAR LSP124 DSK:FOO; BAR PRESS DSK:FOO; BAR TXT256 DSK:FOO; BAR TXT257 DSK:FOO; BAR UNFASL Then file lookup (for read) should work as: BAR > refers to BAR TXT257 (normal) BAR TXT> refers to BAR TXT275 BAR LSP> refers to BAR LSP257 Jerry  Date: 4 October 1981 03:10-EDT From: Christopher C. Stacy Subject: Ten/11 Interface seems to be flakey (so, what else is new?) To: BUG-ITS at MIT-AI cc: CSTACY at MIT-AI About midnight, AI stopped with a parity error. When CONTinued,it would halt again. During this time, the door buzzer was stuck on. Cycling the PDP-11 got the door to stop being noisy. However, I could not get the TVs work on ITS again. While I was scratching my head, ITS crashed at CHACK1+14. This is in some CORE code, and the error had something to do with a pointer to a non-existant luser. About now, I decided things were probably screwed up enough to want to reload and try again. Reloaded. When I ran SALVAGER, it found directories out of phase. I copied the most recent version to the other packs. This worked and ITS came back up. Later, when no one was logged in, I tried to make the system lose by buzzing the door from a LISPM. ITS halted. The job which got the parity error was a chaos DOOR server. It was halted at FROBIT+1, a .SLEEP which comes immediately after an access to the TEN11 interface. Since the TEN/11 interface seems pretty broken, I deleted the DOOR server from the DEVICE directory and put up a system message. Cheers, Chris  RSG@MIT-ML 09/30/81 11:58:24 To: (BUG ITS) at MIT-ML CC: RSG at MIT-ML I tried to copy a file from ML to MC. What got created on the MC directory is a locked file (multiple copies with the same name and a * in leftmost column of the directory listing). The file in question is MC: EF; RSG LISPIN . ... rsg  Date: 28 September 1981 15:26-EDT From: David Chapman To: BUG-ITS at MIT-AI I did a pdset on ai since the system seemed to think it was 11/11/81. Probably some files will have this creation data so maybe users should be warned in system msg.  Date: 27 September 1981 17:27-EDT From: Earl A. Killian Subject: [DCP: forwarded] To: BUG-ITS at MIT-MC Date: 25 September 1981 23:52-EDT From: David C. Plummer To: BUG-CRTSTY I think this is your fault: I am on a HEATH19 running under a CRTSTY. It looks like I got the TTYSMT variable of the last person to use this sty. It would be a good idea for CRTSTY to set that value to zero (or whatever is the right thing for the various terminal types) before shoving the ^Z down it. You should probably do this even if you think it is ITS's responsibility to set it to zero when the sty gets opened for the first time.  Date: 27 September 1981 04:32-EDT From: Richard M. Stallman To: BUG-ITS at MIT-AI My XX job became hung permanently in CHAOSO because its CHSNOS was 0. The net appeared to be working; I was able to make new connections to XX and MC. The connection state was still OPEN, according to PEEK. The "flag" was 20003. Ibf, Pbf and Ack were 0; both window sizes were 5. At the time the problem began, the fair share moved up to 120% and stayed there for several updates of the who line. Then it came back to a legitimate value. The problem was worse because this happened with SUPDUP at interrupt level and it would not recognize Break. Can Moon say what other info to look for if this happens again?  Date: 22 September 1981 21:51-EDT From: Ian G. Macky Subject: [RLB: jobdev / ITS bug, I guess] To: BUG-ITS at MIT-MC Ancient mail from my jobdev munging days, never had any more problems once I got my act together... probably should have just thrown this away, but dunno, maybe someone loves bug mail. ----- Date: 06/17/81 01:11:15 From: RLB Re: jobdev / ITS bug, I guess As best as I can determine, the system crashed doing a JOBRET for your JOB.07 returning whatever to your job FOO. At the point of the crash, the system is hacking FOO on behalf of JOB.07, and hence requires that FOO be (internally) stopped. But FOO was not stopped, which is ostensibly an impossible condition, do it halted. I randomly tried continuing at the location after the check, guessing that only FOO or JOB.07 would be screwed, but I didn't understand the clock interrupt level logic the system was up to, so it couldn't continue. I suggest that you try to recover as best you can the circumstances of what you were doing and the state of the code, and ship it off along with your munging of this note to BUG-ITS.  DEFBOB@MIT-MC 09/17/81 20:45:12 To: (BUG SYSTEM) at MIT-MC I don't know where to send this message so I'll send it here. If a user detaches his tree at 4:00 p.m. with the intention of attaching it a few hours later, say 8:00, is the tree nevertheless destroyed (?chopped down?) automatically by someone between those particular hours or between any other particular hours?  DEFBOB@MIT-MC 09/17/81 20:40:48 To: (BUG SYSTEM) at MIT-MC  DCP@MIT-MC 09/15/81 08:53:42 Re: CNSGET symbolic system call extension To: (BUG ITS) at MIT-MC CC: CWH at MIT-MC Now that there are a few places that use SUPDUP Graphics, might it be the right thing to include the SMARTS (or TTYSMT) variable in the CNSGET and CNSSET symbolic system calls. It is much easier to do (syscall 7 'cnsget tyo) and get all the necessary info than to do (syscall 1 'ttyvar tyo (car (pnget 'TTYSMT 6))) to recover the SMARTS variable.  GJC@MIT-MC 09/13/81 14:33:48 To: (BUG ITS) at MIT-MC For something really impressive, try :XFILE out of an archive! Incredibly SLOW, even on MC with fair-share=50% Almost as impressive is running LMODEM out of an archive.  Date: 10 September 1981 1402-EDT (Thursday) From: Guy.Steele at CMU-10A To: bug-its at MIT-AI, gosper at PARC-MAXC Subject: PDP-10 binary search trick Message-Id: <10Sep81 140255 GS70@CMU-10A> Does anyone know who invented the incredibly tight PDP-10 code for doing a binary search, which looks something like: SETZ INDEX, REPEAT N,[ CAML ITEM,TABLE+1_(INDEX) ADDI INDEX,1_ ] CAME ITEM,TABLE(I) JRST NOTFOUND ? I'm trying to track down some history. --Thanks, Guy  Date: 8 September 1981 14:54-EDT From: Jeremy Barkan To: BUG-ITS at MIT-AI cc: GOLDFARB at MIT-XX When using :dover, the its can't differeniate between the underscore in file name and underscore that is the antecedent in the font name specifier. Does it not quote underscore  rms@MIT-MC (Sent by ___114@MIT-MC) 08/28/81 04:25:11 To: (BUG ITS) at MIT-MC MC was hung withMEMFRZ locked bythecore job which was waiting for the 200000,, bit in an IMSOC6 word to clear. It was hung for manyminutes.  KLOTZ@MIT-MC 08/27/81 17:04:27 To: (BUG ITS) at MIT-MC DISTRIB: *TS EXPIRES: 08/31/81 17:01:55 KLOTZ@MIT-MC 08/27/81 17:01:55 Re: AI is down. The repairman fixed unit 7, but determined that unit 0 was broken. ITS cannot be brought up without that unit, so AI will remain down either until tomorrow when they come back to fix it, or until someone knowledgegable enough about the hardware comes around to swap cables. ^_ CSTACY was around when they came to fix the disks. He said he fixed 7, so they decided tobring third: back up. Disk 0 crapped out when they were bringing it up. All lights on the disk went out. He supposedly mumbled something about coming back tomorrow to replace the "carriage." Yuk.  Date: 27 August 1981 17:56-EDT From: Leigh L. Klotz To: BUG-ITS at MIT-AI I called symbolics and found Tom Knight, who came and switched the cables so that unit 7 is now unit 0. Leigh.  Date: 25 August 1981 04:06-EDT From: David A. Moon To: TK at MIT-AI, BUG-HARDWARE at MIT-AI, BUG-ITS at MIT-AI The xgp-11 blows its circuit breaker and makes smoke smell (not visible smoke). Probably someone should fix it.  Date: 24 August 1981 19:40-EDT From: Charles Frankston Subject: Re: MC To: JNC at MIT-XX cc: BUG-its at MIT-AI, BUG-mail at MIT-AI Date: 24 Aug 1981 1123-EDT From: J. Noel Chiappa In-Reply-To: Your message of 23-Aug-81 2242-EDT We don't even have a loopback plug for a local interface, so it must have been the BBN repairman. Please make sure who's at fault before randomly flaming! If you can give me some more info, I will go barf at the NCC; they seem to still have not learned that leaving loopback plugs on enabled ports is an absolute no-no. ------- I didn't send the message to flame. I was hoping someone would read it and take appropriate action. Perhaps the NCC merely had things logically looped back (can they do that?). In any event 3/54 (octal) was looped back for at least an hour prior to my sending the message; probably several hours in total. Plenty of time for every host on the net to unqueue their mail to themselves, rather than to MC.  Date: 24 Aug 1981 1123-EDT From: J. Noel Chiappa Subject: Re: MC To: CBF at SU-AI, bug-its at MIT-AI, bug-mail at MIT-AI cc: JNC at MIT-XX In-Reply-To: Your message of 23-Aug-81 2242-EDT We don't even have a loopback plug for a local interface, so it must have been the BBN repairman. Please make sure who's at fault before randomly flaming! If you can give me some more info, I will go barf at the NCC; they seem to still have not learned that leaving loopback plugs on enabled ports is an absolute no-no. -------  Date: 23 August 1981 17:09-EDT From: J. Noel Chiappa Subject: IMP cretinosity To: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC cc: JNC at MIT-MC I'd have liked to send this to BUG-ARPANET, but the people who should get this aren't on that list. Please add yourself if this sort of stuff concerns you. The C/30 got in this bizarro state this afternoon where it was looping trying to read in its micro-code from the micro-tape. I fixed it by removing the tape, powering the machine down, reinserting the tape, powering the machine back on and hitting the master reset button. This had the disadvantage that when it is powered off, all the hosts are turned off in the software, and it needs manual intervention by the NCC (which the guy on duty forgot to do) to turn them back on. The error message reported by any attempt to use the net was "Random network lossage", which sounds like the IMP lost all connection to the outside world, except that I verified (by looking at the lights) that its connections were in fact up. So if this happens again....  Date: 23 Aug 1981 1653-EDT From: J. Noel Chiappa To: KLOTZ at MIT-MC, (BUG ITS) at MIT-MC cc: JNC at MIT-XX In-Reply-To: Your message of 23-Aug-81 1636-EDT It was the IMP. -------  Date: 23 Aug 1981 1636-EDT From: J. Noel Chiappa To: KLOTZ at MIT-MC, (BUG ITS) at MIT-MC cc: JNC at MIT-XX In-Reply-To: Your message of 23-Aug-81 1457-EDT Perhaps the IMP was dead? It does die occasionally, you know. -------  Date: 23 Aug 1981 1942-PDT From: Charles Frankston Subject: MC To: bug-its at MIT-AI, bug-mail at MIT-AI Someone has left a loopback plug on the IMP port MC should be plugged into (ie, port 3 on IMP 54 octal). This not only results in human confusion but causes all sorts of problems with mail delivery (including mail loops etc.). Would someone please go remove the plug!  Date: 23 Aug 1981 1942-PDT From: Charles Frankston Subject: MC To: bug-its at MIT-AI, bug-mail at MIT-AI Someone has left a loopback plug on the IMP port MC should be plugged into (ie, port 3 on IMP 54 octal). This not only results in human confusion but causes all sorts of problems with mail delivery (including mail loops etc.). Would someone please go remove the plug!  Date: 23 August 1981 18:00-EDT From: J. Noel Chiappa Subject: IMP dead To: BUG-ITS at MIT-AI, ELLEN at MIT-AI, JAN at MIT-AI, JPG at MIT-AI, BUG-twenex at MIT-MC cc: JNC at MIT-AI The IMP that MC and XX are on is dead. BBN is sending a repairman, but the guy they are sending is a known turkey. We'll see. (BTW, this message too I would have liked to send to BUG-ARPANET@MC. PLease add yourself so I can stop pestering everyone who doesn't care.) Noel  KLOTZ@MIT-MC 08/23/81 14:57:27 To: (BUG ITS) at MIT-MC Just a little while ago, with very few users (no arpa users), MC decided the imp was down. I had been using the MC: device from AI succesfully, but then got a device not avail. error. I deposited SCLNET in supcor. It got cleared, but the net didn7t come back up. I tried the net command in lock, and that didn't work either. Then I tried making impup and imptcu get into teh state where it would try to bring the imp up. It didn't. I didn't touch the hardware. DCP was around, and couldn7t do anything, either. Leigh.  Date: 14 August 1981 06:18-EDT From: David A. Moon To: BUG-ITS at MIT-AI INQUIR data base smashed on AI between 8/14/81 02:37:40 and 8/14/81 03:01:11. INQUIR;LSR1 FUKT is a version which causes the name dragon to die by LSRGET taking a non-skip-return in its typical non-informative fashion. I haven't had enough sleep recently to diagnose it more than this.  GZ@MIT-MC 08/14/81 05:42:02 To: (BUG ITS) at MIT-MC I don't know if it matters but the last two or three times the system crashed, my speed got reset to 300 when it came up (as per :tctyp des). I'm on T10.  GJC@MIT-MC 08/14/81 00:54:26 To: (BUG ITS) at MIT-MC There is a job 55 037F55 NETRFC CCA AR3SI ? 14 6 0% REALTM 110 037F55 JOB.07 SYS *10!10 ? DSN 35 34 0% 7:03 PARERR 2 If I try to do 110X from peek it crashes the system, (but the system is able to revive evidently). -gjc  Date: 13 August 1981 18:33-EDT From: David Chapman To: BUG-ITS at MIT-AI :ee should get telsup, not telnet. So presumably should all the other hostname programs.  Date: 13 August 1981 06:08-EDT From: Leigh L. Klotz Subject: AI crash To: BUG-ITS at MIT-AI Just now, AI got in some sort of loop. None of the select-lock lights were on on any disk drives. It was running in exec mode, and it looked like it was looping because the PC didn't look like it was changing much, but the pager lights were all pretty much half lit. I looked around for people, and DLA told me that he knew that RG was not here. I halted it, and looked at where it halted. It seemed to be multiplying some numbers that it got from the TCMXV variable of tty 40. I printed out all the ac's, and some tty variables of tty 40 and near ttys. Now that I think of it, the routine ended in a popj, so I guess I should have looked back up the stack to see who called it and try to see if there was something else important that I could record about its looping, but I didn't. I booted it. Leigh.  Date: 12 August 1981 14:10-EDT From: Leigh L. Klotz Subject: QCHNRT+5 To: BUG-ITS at MIT-AI AI halted at this location at noon today. I tried to record as many significant-looking locations as I could on the console. It seemed to be that something it expected to be in some saved ac's somewhere wasn't there. I waited about 30 minutes before rebooting. I looked around and found PDL on dm, but he didn't answer. I paged RG, but he wasn't around. I noticed that RWK had dumped a crash on ai a while back, so I tried to dump it (since it appeared to be a software problem, as opposed to the random interrupt yesterday). I tried to find out how much free space there was from dskdmp, but couldn't. I forgot about the memory off being in the low memory, and dskdmp got an nxm trying to dump. At this point I wasn't sure if dskdmp was clobbered, so I was going to reload it from tape when rg showed up and said it was ok just to restart it. There is a little information in the log, but most is on the console. Leigh.  Date: 10 August 1981 12:58-EDT From: Leigh L. Klotz To: BUG-ITS at MIT-AI AI halted at QINTE+11 a little while ago. I looked for someone who knew what was going on with the recent disk problems, but no one was around. I found Stu Galley, and he came up and helped. The information is in the log. Regster Q contained 0, but he didn't know if that meant drive 0 or was irrelevant. We wrote down the pack id, sector number, and other information in the log. Leigh.  OAF@MIT-MC 08/10/81 12:25:52 To: (BUG ITS) at MIT-MC On Sunday morning 8/9/81 at 0900 on MC there were 10 users logged in, one macsyma, fair share 6%, and stayed that way. I gunned every non-logged-in job I could find from peek, including several people's crtsty's (old - idle easily an hour) CSTACY's bye (which also was hung) and a stack of NETRFCs with REALTM PARITY ERROR listed at extreme right. Then the fair share went to 60% or so. Did I did the right thing, wrong thing?? Are y'all the right people to inform?  Date: 9 August 1981 23:04-EDT From: David W. Payton To: BUG-ITS at MIT-AI Tex on MC seems to be broken. If you just try to type \input basic, it complains. Since this works on AI, there must be some problem. Who should I notify?  GREN@MIT-MC 08/03/81 00:53:35 To: (BUG ITS) at MIT-MC CC: FILE-RETRIEVAL at MIT-MC Would it be ok to load .INFO.;ITS TRANSL back from tape 511? It was taken off in '73. I saw pointers to that file in ITS .CALLS in the translation hacking part... Why was the file taken off? Is the information in it obsolete? Danke, --Gren  Date: 30 July 1981 11:57-EDT From: David Chapman To: BUG-ZWEI at MIT-AI cc: BUG-ITS at MIT-AI The file crash;quinte doffl has a negative creation date and a file author of DICK (whereas it was actually just created by RWK with dskdmp.) :listf can handle this, but zwei gets an errror parsing a negative date.  MOON@MIT-MC 07/29/81 00:39:31 Re: VALID CLEAR OR STORED SET error To: GREN at MIT-MC CC: (BUG ITS) at MIT-MC I wonder why this is not in the documentation (.INFO.;ITS JOB)? It means that either you tried to JOBRET and the other job was not waiting for a response, or you tried to JOBGET and the other job was not asking you to do something.  Date: 28 July 1981 19:39-EDT From: Robert W. Kerns Subject: ITS listings To: BUG-ITS at MIT-MC The ITS listings have been reprinted, and are nicely labeled, etc., so we can stand a chance of finding what we want. If anybody wants to look at the chicken scratches on the old ones, they live in a tape box beneath the table in 926. The listings for the PDP11 programs (IOELEV, 11DDT, TV) haven't been redone yet, but will be soon.  GREN@MIT-MC 07/28/81 01:13:55 To: (BUG ITS) at MIT-MC In the jobdevice I am debugging via an OJB: I try to pass back via JOBRET the 5 word block of data requested by a .RCHST. The JOBRET consistently pulls a VALID SET OR STORED CLEAR error. If I instal the jobdev in DEVICE; and try the exact same thing from there, it flies - No error. What *IS* this error? Noone can tell me.  Date: 27 Jul 1981 0912-EDT From: DEVON at MIT-DMS (Devon S. McCullough) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].205130> DM is outputting in groups af about 32 characters with 2-4 second delay betw  RWK@MIT-MC (Sent by RWK0@MIT-MC) 07/25/81 17:53:11 Re: REM's hangage To: (BUG ITS) at MIT-MC CC: REM at MIT-MC This was the usual problem of getting a SEND via MLSLV and having the MLSLV drop dead.  REM@MIT-MC (Sent by ___101@MIT-MC) 07/25/81 17:36:47 To: (BUG ITS) at MIT-MC I think I have a hung HACTRN. I was in RMAIL, did a Quit command, it said WRITTEN: REM;REM RMAIL then just hung, never coming back to DDT. I tried ctrl-Z many times but they just echoed as ^Z and finally filled thebuffer and beeped. I thought the system had hung so I went away for a half hour then reconnecte to find my detached job. I attached to it and found it still in the sme funny state, ^Z ^Q ^G all just echoed (as uparrow-Z uparrow-Q and a real live bell respectively) but didn't abort the job or give a ddt prompt or anything. I then disconnected again, leaving it detached for yo to look at.  Date: 25 July 1981 01:40-EDT From: David A. Moon To: BUG-ITS at MIT-AI WE TRIED TO WORK ON THE 10/11 INTERFACE BUT COULD NOOTT GET IT TO FAIL. IF AI STARTS GETTING PARITY ERRORS TRY SHUTTING OFF THE XGP SPOOLER AND STEPPING ON ANYONE WHO WANTS TO RUN D OR PW  Date: 23 July 1981 15:55-EDT From: David Chapman To: BUG-ITS at MIT-AI, BUG-GMSGS at MIT-AI running :gmsgs I get a directory full. Mine isn't. I assume the problem is that sys; is 97.7% full and it can't write sys;:msgs times.  Date: 21 Jul 1981 1211-EDT From: SWG at MIT-DMS (S. W. Galley) To: CSTACY at MIT-DMS Cc: bug-its at MIT-DMS In-reply-to: <[MIT-DMS].204538> Subject: [Re: DM stys] Message-id: <[MIT-DMS].204585> INQUIR & TTYTYP data have not yet caught up with reality, but soon they will.  Date: 21 Jul 1981 1157-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-ITS at MIT-DMS Subject: BUG => ITS Message-id: <[MIT-DMS].204581> When trying to append to a mail file in a directory that is full (99+% according to DSKUSE), COMSYS sits spinning its wheels in +OPEN, using up a much of the machine as there is free. Is it possible that writeover mode opens aren't giving DIRECTORY FULL errors?  Date: 21 Jul 1981 1037-EDT From: PDL at MIT-DMS (P. David Lebling) To: CSTACY at MIT-DMS Cc: bug-its at MIT-DMS In-reply-to: Message of 21 Jul 81 at 0009 EDT by CSTACY@MIT-DMS Subject: [Re: DM stys] Message-id: <[MIT-DMS].204570> T05 is the downlink to the Apollos. The Apollo <-> ITS FTP program logs in to DM as "MUDDLE". It says "[not in use]" because no one has updated the TTYLOC file yet.  Date: 21 Jul 1981 0009-EDT From: CSTACY at MIT-DMS (Christopher C. Stacy) To: bug-its at MIT-DMS Subject: DM stys Message-id: <[MIT-DMS].204538> Why is "MUDDLE" (File Directory Only) logged in on T05 and idle for 13 minutes, with a Console Location of "[not in use]"?  MOON@MIT-MC 07/13/81 19:57:00 To: WJL at MIT-ML CC: (BUG ITS) at MIT-MC WJL@MIT-ML 07/13/81 09:19:24 To: (BUG ITS) at MIT-ML 7/3 I copied a 16 block file from ai to ml using the ai device. I have since found that there were about 20 errors in the resulting file, randomly scattered throughout. All were changes of characters with no apparent consistency e.g. " " -> "`", ")" -> "i", "U" -> "M" ... Unfortunately, I don't have the original file anymore. This was a hardware bug with the IMP. I guess you didn't see the system message from OAF announcing that it had been fixed, or didn't correlate it with your problem.  WJL@MIT-ML 07/13/81 09:19:24 To: (BUG ITS) at MIT-ML 7/3 I copied a 16 block file from ai to ml using the ai device. I have since found that there were about 20 errors in the resulting file, randomly scattered throughout. All were changes of characters with no apparent consistency e.g. " " -> "`", ")" -> "i", "U" -> "M" ... Unfortunately, I don't have the original file anymore. -Bill Long  Date: Sunday, 12 July 1981, 19:19-EDT From: Robert W. Kerns To: REM at MIT-MC Cc: (BUG ITS) at MIT-MC, EHUANG at MIT-AI In-reply-to: The message of 12 Jul 81 17:01-EDT from REM at MIT-MC REM@MIT-MC 07/12/81 17:01:41 To: (BUG ITS) at MIT-MC CC: EHUANG at MIT-AI Darn. If you type ahead while in an editor (emacs/rmail) while a SEND is being typed on your screen, ITS doesn't buffer your input, so yo lose it. That means if you're in the middle of typing something and you get a flurry of SENDs or one long SEND you HAVE TO stop what you are doing until the SENDs are finished, then try to remember what you were doing after you've lost your train of thought. You can't evn finish the sentence you are in themiddle of before stopping to look at the SENDs. This is not true. However, it is unfortunately true that if you type a control-G during the printing of a SEND, the control-G will abort out of that printing, rather than being passed to the program. It is also true that characters which are intended to interrupt the program you were typing to will not cause an interrupt, but will be read as normal interrupt. This is a DDT problem that may or may not be possible to fix.  REM@MIT-MC 07/12/81 17:01:41 To: (BUG ITS) at MIT-MC CC: EHUANG at MIT-AI Darn. If you type ahead while in an editor (emacs/rmail) while a SEND is being typed on your screen, ITS doesn't buffer your input, so yo lose it. That means if you're in the middle of typing something and you get a flurry of SENDs or one long SEND you HAVE TO stop what you are doing until the SENDs are finished, then try to remember what you were doing after you've lost your train of thought. You can't evn finish the sentence you are in themiddle of before stopping to look at the SENDs.  Date: 10 Jul 1981 2359-EDT From: Alyson L. Abramowitz To: bug-its at MIT-AI cc: cstacy at MIT-AI, ala at MIT-AI Subject: Problems with applying for accounts on MIT-AI Message-ID: There appears to be a problem in the program that is run when a new user applies for an account on MIT-AI. The program asks the user for his/her Uname, real name, address, and reason for wanting an account just fine. Unfortunately after it does that it prints a ")" followed by a carriage return and just hangs there. A CTRL-G gets one out of that state (and back to DDT), but, unfortunately, it also looses all the information that the potential user just entered. I watch a potential new tourist do this a couple of times in a row tonight. He wasn't doing anything obviously wrong and the same thing happened every time. Can someone check into this? Thanks. --------  Moon@MIT-MC 07/10/81 21:05:33 To: RMS at MIT-AI CC: (BUG ITS) at MIT-AI Date: 9 July 1981 16:15-EDT From: Richard M. Stallman To: BUG-ITS at MIT-AI There has long been a problem whereby every so often a TV gets hung, but gunning or detaching its tree unhangs it. When I have looked, the cause has always been that the 10/11 interface spazzed writing into the 11, and so there is a -1 at the place where the 11 thinks the next character from the 10 will come, so the 11 never processes any more characters. Since the 10 is careful never to wrap completely around the buffer, it never comes back and writes over that -1 again, so it stays there forever. Detaching resets everyone's buffer pointers. Today, several TVs were hung and the usual fix did not unhang them. I discovered that they were hung becaue their TTOALC words contained 100 instead of the -1 that they should have contained. I hope this was due to the heat.  Date: 9 July 1981 16:15-EDT From: Richard M. Stallman To: BUG-ITS at MIT-AI There has long been a problem whereby every so often a TV gets hung, but gunning or detaching its tree unhangs it. Today, several TVs were hung and the usual fix did not unhang them. I discovered that they were hung becaue their TTOALC words contained 100 instead of the -1 that they should have contained.  Date: 8 July 1981 09:00-EDT From: Leigh L. Klotz To: RICH at MIT-AI cc: BUG-ITS at MIT-AI The home directory set in inquir, with the FILE option. With a machine name (CHURK@AI), it means that the user's home directory will be CHUCK only on AI. Without one, it will be that on any machine with a directory by that name. The HSNAME program will tell you what the home directory of a particular user is. Leigh.  Date: 8 July 1981 08:46-EDT From: Charles Rich Subject: enquiry To: BUG-ITS at MIT-AI cc: SIDNER at BBND Pray tell -- how does one change the home directory (i.e. where mail files are stored) for someone without a user directory? In particular I want to move CANDY from USERS1; to CHUCK; because USERS1;is too full. Is there something I can put in here login file, or can it be caught even before that? Thanks, Chuck.  FONER@MIT-MC 07/05/81 23:21:12 Re: Flakiness transferring file from AI to MC To: (BUG ITS) at MIT-MC, (BUG its) at MIT-AI CC: foner at MIT-AI I was trying to transfer a file from AI to MC earlier tonight, and the connection appeared to freeze. I got the ITS prompt again, but the file was marked locked (according to FIND) and PEEK C shows it with a J next to it. Eventually the file became unlocked, and included both the original file and many replications of some random cruft from elsewhere on the disk. Apparently the ^C was missed, and far more was transferred than intended. The file is MC:GUEST1;FONER LOSSAG. Past around 47% of the way through starts the peculiar lossage I've described. Might this have something to do with AI's IMP flakiness, or is this a genuine problem with ITS or FTP or whatever really does the transfer? I don't need an answer for this, really, since I can just retry the transfer. But it should probably be reported in case it's part of a consistent pattern of garbling. Ciao.  Date: 5 July 1981 20:37 edt From: Margolin at MIT-Multics (Barry Margolin) Subject: random bits Sender: Margolin.PDO at MIT-Multics To: bug-its at MIT-AI If there is a more appropriate BUG- list, please forward this and let me know. Thank you. AI has been turning on random high-order bits when it outputs accross the network. I notice this in netmail I receive from AI and when I SUPDUP or TELNET to AI. I am not sure whether this happens over the CHAOSnet (it happened when I TELNETted from MC to AI, if that helps), but it certainly happens over the ARPAnet. It is usually the 100 (octal) bit (spaces turning into tildes is the most common symptom), but sometimes it is the 200 bit, often turning alphabetics into invalid %TD codes when I am SUPDUPing.  Date: 5 July 1981 10:12-EDT From: Oded Anoaf Feingold Subject: AI Arpanet problems To: MOON5 at MIT-AI cc: JAN at MIT-MC, BUG-ARPA at MIT-AI, BUG-ITS at MIT-AI, control at BBNC, RClifford at BBNC David, thanks for the bit-level bug report. But as far as getting things done on Sunday goes, don't bother. The NCC nose that the IMP picks bits on occasion, that it does so neither at 16 nor 36 (nor any other obvious word-length type number) bit intervals, and there is a repair visit already scheduled: Tomorrow (Monday) at 0700 or so I will detach AI's IMP cable and install a loopback, someone from BBN field service will arrive and repair the IMP, and only when the IMP runs its own diagnostics will they try anything with AI back on the net. I certainly agree there is no reason to touch ML's IMP cable, or even look crosseyed at it. Past history: On Thursday TY took off AI's IMP cable (at the NCC's request) and they found the problem while running diagnostics. Apparently the fault showed up so fast that there was no reason to keep AI off the net for more than a few minutes - hence virtually no interruption to users. This time the repair procedure may take a few hours/days/millenia/ minutes, and since the IMP will be powered down to change cards, that means the other IMP 6 hosts will be off the net, as stated in .MSGS.;ARPA DOWN. [Note for NCC people - the specific errors David Moon spotted are: Bits with octal weights 10 and 4 get picked (spurious one). Bit with octal weight 10 gets dropped (spurious zero). There may be additional problems.] Oded  Date: 5 July 1981 04:07-EDT From: David A. Moon Subject: AI Arpanet problems (p.s.) To: BUG-ARPA at MIT-AI cc: BUG-ITS at MIT-AI I forgot to say in my previous message that the problems are believed to be entirely in the host-to-IMP direction.  Date: 5 July 1981 04:06-EDT From: David A. Moon Subject: AI Arpanet problems To: BUG-ARPA at MIT-AI cc: BUG-ITS at MIT-AI The problems are in the IMP, not in AI, as can be demonstrated by plugging ML into AI's IMP port. Please do not try this experiment yourself! It took me over an hour to get ML to work again on its own port after doing this, because the connectors are quite literally falling apart. And each time they are plugged and unplugged they get worse. The problems with the IMP, in terms of its 16-bit words, are at least the following. It's a little hard to tell but I think there may be problems with some other bits as well (actually I am fairly sure): Bits with octal weights 10 and 4 get picked (spurious one). Bit with octal weight 10 gets dropped (spurious zero). I will try and call up the NCC tomorrow about this, during the daytime, but it wouldn't hurt for anyone else who is around during the day to call them first. The number is 661-0100 and you need to convince them to give you a hardware guy, preferably Sunday rather than Monday.  Date: 4 July 1981 21:50-EDT From: David A. Moon Subject: not more CHAOS lossage To: DCP at MIT-MC cc: BUG-ITS at MIT-MC, CHAOS-NCP-PEOPLE at MIT-MC Date: 4`July 1981 1s:43-EDT From: David C. Plummer Subject: more CHAOS lossage To: BUG-ITS at MIT-MC cc: CHAOS-NCP-PEOPLE at MIT-MC Sitting on MC, I run :CHATST. Send a RFC to an ITS (AI or MC) with contact name STATUS and enough JCL to make the byte count of the packet 486. (that's right, 486. also breaks as does 488). It does not give me an unrecoverable data error as 489. does, yet it tries to send it. Response: what response, there is none. Now do it again, but send the 486. byte data length packet to either MC-CHAOS-11 or AI-CHAOS-11 and it comes back with the standard reply to status. The STATUS protocol does not accept arguments. The ITS server for it happens to implement this restriction and the pdp11 server happens not to. The number of bytes of arguments is irrelevant. If you wait long enough you will get back a "connection refused" reply; the system waits a long time (2 minutes?) for a server to pick up the queued request before sending this. The timeout may be too long.  Date: 4 July 1981 13:43-EDT From: David C. Plummer Subject: more CHAOS lossage To: BUG-ITS at MIT-MC cc: CHAOS-NCP-PEOPLE at MIT-MC I don't know who is (not) doing the following: Sitting on MC, I run :CHATST. Send a RFC to an ITS (AI or MC) with contact name STATUS and enough JCL to make the byte count of the packet 486. (that's right, 486. also breaks as does 488). It does not give me an unrecoverable data error as 489. does, yet it tries to send it. Response: what response, there is none. Now do it again, but send the 486. byte data length packet to either MC-CHAOS-11 or AI-CHAOS-11 and it comes back with the standard reply to status. I looked over the code breifly, looking for %CPMX(W and C) and I couldn't spot anything off hand. Could be a fencepost, could be somebody isn't keeping track of something (is everybody remembering the two header words that the system tacks on to the packet?). My guess is ITS will send but not receive. Does anybody ever remembering having problems sending large packets around and having the conneciton hang? If so, this might be the reason.  Date: 3 July 1981 17:11-EDT From: Steven T. Kirsch Subject: The DDT prompt went away a couple of days ago on MC... To: BUG-ITS at MIT-MC and never came back. Is this only on logins over the net? or a new feature. Only the prompt after the "if you are a tourist...." message has gone.  Date: 1 July 1981 23:49-EDT From: Christopher C. Stacy Subject: net interface problems? losing bits To: BUG-ITS at MIT-AI, pdl at MIT-DMS, eak at MIT-MC TELNETing in from a foreign TIP this evening, I watched a bunch of spaces get displayed as "`"s and "~"s. I thought this was a problem with my terminal (which has never happenned before), but after reading the other bug reports..... Chris  Date: 1 July 1981 22:40-EDT From: Howard I. Cannon Subject: AI Imp Interface To: BUG-ITS at MIT-MC I can't reproduce the problem now, so I am going to leave AI on the net for now. The only thing I did was to reset the IMP interface on AI with the front panel switch.  Date: 1 July 1981 20:08-EDT From: Mike McMahon To: BUG-ITS at MIT-AI I have renamed the server ftp to prevent incoming mail from being garbaged.  Date: 1 July 1981 19:01-EDT From: Eugene C. Ciccarelli Subject: Network interface problems To: BUG-ITS at MIT-AI I just got a message (via Chaosnet) from EAK who says AI's Arpanet interface is garbaging bits, and suggests someone taking AI off the network temporarily to avoid problems with misforwarded mail, etc.  Date: 1 Jul 1981 1522-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].202889> AI's net interface (possibly?) is losing. Getting a lot of picked and dropped bits from MLDEVs pulling files to DM from AI. This doesn't seem to happen pulling to DM from MC. (ML is down right now). Dave  Date: 1 July 1981 16:30-EDT From: Leigh L. Klotz To: BUG-ITS at MIT-AI I didn't see PDL's previous note, but MLDEV's on AI seem to be breaking at LOSE3. crash;mldev record and crash;mldev 1 are the dump and ac's of one. Leigh.  Date: 1 Jul 1981 1525-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].202891> Typically the aforementioned MLDEVs .VALUE at NTDI+14 with c/ 1000 and d/ 400  Date: 1 July 1981 14:27-EDT From: Earl A. Killian To: BUG-ITS at MIT-AI I'm telneting from LLL-S1 to AI and I find that on output a large number of characters output have their bits modified. In particular, a large number os spaces have turned into "`"s, i.e. the 100 bit got turned on. Also, I've seen ">" turn into "~", ":" into "z", and other weird things. This isn't happening to other hosts.  Date: 30 June 1981 05:21-EDT From: Leigh L. Klotz Sender: KLOTZ0 at MIT-MC Subject: ellen's hactrn To: BUG-ITS at MIT-MC cc: KLOTZ at MIT-MC, ELLEN at MIT-MC The same thing happened to me recently. There are some tourists on ai who have written this hack which runs as a disowned job and periodically sends random messages to the hackee. [Message from your Terminal]... Someone tried to do this to me, but the program seems not to work quite right, or something. It left me in CLOBI. I killed the job and it went away. I don't know that this is the same thing. Right now when I try to send to ellen, my hactrn hangs at the place where it is waiting to send. I do not know what failure code the open returned, because she had logged out by the time I tried to do it again, and the register had been trashed. But since it was looping, it must have been %EFLDIR or %ENAFL. Her old, bad hactrn was trying to read from CLO: _CLI_;ELLEN HACTRN, and had it open in .BAI. I guess this is why my sends to her didn't work, even though the hactrn which was trying to send to itself became HACTRO. That doesn't seem quite right, though. HCLOB was 0 and HHACK was -1. I'm not sure why her hactrn was trying to open itself. In the process of trying to look back up the stack to see who had opened this, I managed to trash the job. I did a CTYPE 41 X that I meant to do in another job in the hactro, and of course trashed it. It dumped itself, but I doubt that's of any use. It was trying to do a .IOT on it at FDRCO4, having been called at FDRCO1+3. I didn't get any farther. Leigh.  ELLEN@MIT-MC 06/30/81 04:05:59 To: (BUG ITS) at MIT-MC CC: (BUG DDT) at MIT-MC Three times in succession tonight I have control-Z'd out of an EMACS and had my DDT hang, typing control-G had no effect. Typing echoed but $$V or other commands had no effect. Upon hanging up (I am on a dialup line) and reconnecting, leaving my tree detached, I find on looking at a peek that my HACTRO is in state "*CLOBI" and it says "CLI" to the right of the "Time PIs" column. This has not happened to me from anyplace except exiting EMACS, however the EMACS job appears unaffected, as I can snarf it from the HACTRO and continue using it.  Date: 29 June 1981 19:47-EDT From: Earl A. Killian Subject: enquiry To: RICH at MIT-AI cc: BUG-ITS at MIT-AI Use the ALLOC command of the DUMP program.  Date: 29 June 1981 11:06-EDT From: Charles Rich Subject: enquiry To: BUG-ITS at MIT-AI I used to know, but now cannot remember and cannot find in the documentation, the answer to this question: How do I allocate a directory to a given device? Thanks, Chuck.  MOON@MIT-MC 06/24/81 16:02:01 Re: MC lack of response on the Chaosnet To: DCP at MIT-AI CC: (BUG ITS) at MIT-MC Date: 24 June 1981 15:32-EDT From: David C. Plummer To: BUG-ITS at MIT-AI I have noticed this in the past, and it is happening again. MC is at this moment down. It does not respond to the :TIMES program, nor the CTIMES program, nor to attempts to connect. It does however, answer a status packet (generated with :MOON;CHARFC MC STATUS ). I assume it is the 11 that handles the chaos net that is responsible for this. Why do you assume that? It's not true. If this is so, could it be fixed? MC should respond to the status for MC, and the chaos front end should respond to STATUS only sent to it, not to MC also. I realize this may be an efficiency hack, but it is doing the wrong thing. The problem was undoubtedly that there were no free job slots and therefore server processes could not be created. The STATUS response is generated directly by the system rather than by a server process, for exactly this reason: so that it will always work if the system is up, even when it is overloaded.  DCP@MIT-MC 06/24/81 15:38:11 To: (BUG ITS) at MIT-MC I guess that last bug report is slightly bogus. MC was not down, but it was dead to the outside world.  Date: 24 June 1981 15:32-EDT From: David C. Plummer To: BUG-ITS at MIT-AI I have noticed this in the past, and it is happening again. MC is at this moment down. It does not respond to the :TIMES program, nor the CTIMES program, nor to attempts to connect. It does however, answer a status packet (generated with :MOON;CHARFC MC STATUS ). I assume it is the 11 that handles the chaos net that is responsible for this. If this is so, could it be fixed? MC should respond to the status for MC, and the chaos front end should respond to STATUS only sent to it, not to MC also. I realize this may be an efficiency hack, but it is doing the wrong thing.  Date: 24 June 1981 00:55-EDT From: Steven T. Kirsch Subject: random clobberage on MC? To: BUG-ITS at MIT-MC This could be all in my head, but I noticed two clobberages today that struck me as a little strange: The end of SK;SK OBABYL appears to have some lines missing from the last message. SK;PASCAL LISP seems to be missing (or transpose and missing) characters at the end. You can read this file and see for yourself (it's only about 10 lines long). If comparision with the tape dump (Tape 325, file #95) shows a discrepancy, we are all in a lot of trouble (since ITS says, and I agree, that the file hasn't been modified in any normal way since it was dumped). I could be imagining all this and could have accidently clobbered these files myself. I thought I'd bring it up just to be on the safe side.  Date: 20 June 1981 18:10-EDT From: Alan Bawden Subject: opening the CLI device To: BUG-ITS at MIT-MC cc: DCP at MIT-MC When opening the CLI device fails because the core link already exists (returning %ENAFL) the target job gets interrupted anyway.  ALAN@MIT-MC 06/20/81 17:27:14 Re: recent MC crash & .getsys To: (BUG ITS) at MIT-MC The recent MC crash where the system died trying to gun a garbage job tree for me may be even more related to me than that. Earlier that evening I discovered that the .getsys uuo was acting strangely (never mind WHY I discovered that). It seems that it no longer works for some of the random sixbit keywords you can give it (for example: DEVS and NCALLS work, but GETS doesn't (!)). In the cases where it doesn't work it has a tendency to trash the two accumulators involved (aobjn pointer and sixbit key). Now, I was just going to ignore this all, figuring that nobody uses the thing anyway, but after talking with Moon it sounds like one of the garbaged words in the job in question was trashed with one of MY aobjn pointers from a failing .getsys! Perhaps it is worth someone's time to look into this.  RLB@MIT-MC 06/18/81 02:10:15 To: (BUG ITS) at MIT-MC Recent MC crash dumped as CRASH;CHACK1 14 Halt at CHACK1+14 Notes in the crash log. Acc U pointed to QCP HACTRP which ALAN says he was trying to gun when crash happened.  Date: 13 June 1981 13:47-EDT From: David C. Plummer To: BUG-ITS at MIT-AI, ALAN at MIT-AI MC has been having problems since about noon today (Saturday). It revived itself a few dozen times in the course of a couple hours. I may have been the cause of this. I have been hacking with the CLO: device this afternoon. Does anybody know if there are any bugs with this beast? I will refrain from using it until I hear a go ahead. If you want details on what I was doing with it, just ask.  Date: 11 June 1981 03:24-EDT From: David A. Moon Subject: Output reset doing weird things on MC tonight To: sk at MIT-MC cc: BUG-ITS at MIT-AI I broke something in the process of fixing another bug. It's fixed now.  SK@MIT-MC 06/11/81 01:53:53 Re: last message To: (BUG ITS) at MIT-MC re-attaching did work in one case.  SK@MIT-MC 06/11/81 01:49:51 Re: did something get "fixed" recently? To: (BUG ITS) at MIT-MC In logging in through the SAIL tip as usual, I discovered today that ^S'ing the "welcome" message would hang my terminal. This happened consistently. Up till today, I have had no problems ^Sing the message and I do it almost every time I log in. Also, typing Q in peek while it attempted to typeout caused me to hang. Reowning the detached tree did not make things work (still dead) in one case, and I forgot what happened in the other case. In any case, I think I had to close and re-open the connection about 5 times today. Let me know if you need more info.  GJC@MIT-MC 06/10/81 09:37:27 To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC Some people had their MAIL file on the PACK NOT AVAILABLE disk. If they recieved any mail since then, what happens is that instead of COMSAT specially handling the error, it takes it as FILE-NOT-FOUND and simply creates a new mail file. People lose their mail.  JPG@MIT-MC 06/10/81 06:35:24 To: CBF at MIT-MC CC: (BUG ITS) at MIT-MC As I have stated many times in the past, I certainly don't care whether SECOND: is an RP04 or a T-300.  Date: 10 Jun 1981 0158-EDT From: J. Noel Chiappa Subject: Re: SECOND: device on MC: To: CBF at MIT-MC, bug-its at MIT-MC cc: JNC at MIT-XX I've been saying that the likelihood of a T-300 control path failure is low for a while; the observed failure rates at this time seem to obviate theoretical discussions of the matter. I only saw that break once, and then it was a matter of switches wrong, and not anything broken. So saying that the T-300's are less reliable on those grounds isn't indicated. I have said that I thought that the reap path ought to have SECOND: somewhere after THIRD:, but JPG didn't like the idea the last time I mentioned it. -------  CBF@MIT-MC 06/10/81 01:22:01 Re: SECOND: device on MC: To: MOON at MIT-MC CC: JPG at MIT-MC, (BUG ITS) at MIT-MC MOON@MIT-MC 06/09/81 21:49:20 Re: SECOND: device on MC: The two times before this it was a Trident that went down. Hmm, now that I think about it you're right; but I didn't even notice it. Clearly my analysis is wrong. The reason I think it is better to have a Trident be SECOND: (ie. be first to be reaped to) because when a Trident goes down you get the choice of which Trident you want to leave down. When pack 13 goes down the way things work now, it is the most recently modified files that must go away. With the other scheme there is one, posible two whole packs of data more recent than the one lost.  MOON@MIT-MC 06/09/81 21:49:20 Re: SECOND: device on MC: To: CBF at MIT-MC CC: JPG at MIT-MC, (BUG ITS) at MIT-MC The two times before this it was a Trident that went down.  CBF@MIT-MC 06/09/81 20:38:46 Re: SECOND: device on MC: To: (BUG ITS) at MIT-MC CC: JPG at MIT-MC I think by this time it ought to be clear to all that the likelihood of one of the RP04's being down probably far exceeds the likelihood of one of the Trident's being down. Therefore I don't understand why it is still first in the migration path. One could perhaps argue that the Tridents might be less reliable since a failure of any item in the chain of hardware connecting the Tridents can bring them both down (DL10, I/O 11, Century controller), I might suggest that considering the percentage of storage those devices represent, the system will effectively be useless to most users anyway. Therefore I think the only relevant probability to consider is one Trident drive vs one RP04 going down, and I think its obvious which is the more reliable of the two.  Date: 9 June 1981 20:34-EDT From: David Eppstein Subject: Indirect cursor addressing To: BUG-EMACS at MIT-MC, BUG-ITS at MIT-MC I just checked again. MC has the problem too.  Date: 8 June 1981 1011-EDT (Monday) From: Guy.Steele at CMU-10A To: bug-its at MIT-AI Subject: Cleaning up my old directories Message-Id: <08Jun81 101127 GS70@CMU-10A> Dear everyone, I would like to undertake the task of grossly reaping my old ITS directories, first weeding through them a shipping good stuff to CMU. (Chuck Rich is after me to free up a few directories.) Before I can do this I need to get many files back from tape. Would someone be willing to help in this endeavor? On AI I need all files for directories GLS, TGQ, QUUX, and QX from tapes GFR9, GFR10, GFR11, 140, and 1407. On MC I need all files for directories GLS, QUUX, and QX from tapes GFR24, GFR25, GFR26, GFR27, and GFR28. Within a day or two of the reappearance of these files I can flush them all again and free up several directories. Thanks, Guy  Date: 7 June 1981 14:20-EDT From: Christopher C. Stacy To: BUG-ITS at MIT-AI on AI, 230479. memory errors in 47.4 hours. (!?!??) Well, at least ONE memory error, anyway. Chris  Date: 4 June 1981 11:39-EDT From: Maria Simi To: BUG-ITS at MIT-AI cc: MARIA at MIT-AI Please, somebody do something about the terminal in 939!!!! The line is broken. Thanks, maria.  Date: 1 June 1981 00:58-EDT From: Leonard N. Foner Subject: This is not a bug, but a question to persons unknown To: BUG-ITS at MIT-AI I have been occasionally curious as to how the fair share is determined. Any theories I nurtured about its being a measure of idle CPU time or anything of a similar sort were shattered tonight when I noticed upon login that the fair share was 103%. My question, of course, is just how this number is determined. Any help for this rather pointless question would be well received. Thanx.  Date: 24 May 1981 09:47-EDT From: Robert W. Kerns Subject: H19 To: Moon at MIT-AI cc: BUG-ITS at MIT-MC Moon@MIT-AI 05/24/81 01:37:31 Re: H19 To: rwk at MIT-MC kmp,bil@MIT-MC (Sent by BIL@MIT-MC) 05/23/81 21:56:03 To: (BUG ITS) at MIT-MC Recently, all the H19's on the 8th floor have been dying on ^S^Q problems with insertline/deleteline. These used to work. The change happened maybe a week ago? Can it be fixed back or what's up? -kmp Bob, do you know anything about this? I suppose ITS's idea of the padding got broken somehow? No, Kent is just wrong about it having ever worked at 9600 baud. There is some bug in the changes I made for padding H19's with nulls, and I haven't gotten around to debugging it yet. In the meantime, use -%TOLID at 9600 baud. I suppose :TCTYP should know this.  kmp,bil@MIT-MC (Sent by BIL@MIT-MC) 05/23/81 21:56:03 To: (BUG ITS) at MIT-MC Recently, all the H19's on the 8th floor have been dying on ^S^Q problems with insertline/deleteline. These used to work. The change happened maybe a week ago? Can it be fixed back or what's up? -kmp  Date: 23 May 1981 15:21-EDT From: David A. Moon Subject: Chaos connections to Dover losing To: JNC at MIT-XX cc: BUG-TWENEX at MIT-MC, BUG-its at MIT-AI Date: 23 May 1981 1255-EDT From: J. Noel Chiappa Something about the latest change in the AI-IO-11 broke connections from XX to the Dover. Actually, those work just fine. But the DOVERSEND program has a private Chaosnet server on MC, which I didn't know about it, that it uses to find out the state of the MC dover spooler and of spruce, which hadn't been converted and also failed to report back its errors properly. It's fixed now.  Date: 23 May 1981 1255-EDT From: J. Noel Chiappa Subject: Chaos connections to Dover losing To: bug-its at MIT-AI, bug-twenex at MIT-MC cc: JNC at MIT-XX Something about the latest change in the AI-IO-11 broke connections from XX to the Dover. -------  MOON@MIT-MC 05/21/81 20:50:59 Re: Bug fixed To: (BUG ITS) at MIT-MC That bug where network servers show up as logged in and looping forever trying to log in again is a bug in the LOGIN system call introduced by RWK a few months back and fixed in the source (ITS 1218).  Date: 20 May 1981 23:07-EDT From: Mike McMahon Subject: Lisp machine gets "file system fucked" trying to read directory from ML: To: BUG-LISPM at MIT-MC, BUG-ITS at MIT-MC cc: MMCM at MIT-AI, MOON at MIT-MC MOON@MIT-MC 05/20/81 17:17:41 Re: Lisp machine gets "file system fucked" trying to read directory from ML: There must also be a bug in the Lisp machine, that it dies so foully when it gets back an ISE0 error from a DIRECTORY operation (the real error is a CHNL NOT OPEN IOC error from the SIOT that is slurping in the MFD, but the error string reported by the file job says ISE0 for some reason, and has what the Lisp machine thinks is the wrong transaction ID.) This failing SIOT symbolic call appears not to set the error code as asked, so you still get ISE0, although it doesn't bomb out the file system any more. Date: 23 MAR 1981 0139-EST From: MMCM at MIT-AI (Mike McMahon) When you specify a non-existent directory to the DIRECTORY command, you don't get an error until interrupt time. Probably it should fill the first buffer at process level before returning to the user. This now properly gives an error via an asynch mark, however it would still be better if it would happen sooner.  Date: 20 May 1981 18:32-EDT From: Earl A. Killian Subject: [KREEN: Babyl Rave] To: KMP at MIT-MC cc: BUG-BABYL at MIT-MC, BUG-ITS at MIT-MC My first guess is that Babyl is eliminating MIT-DM from the header, except that MIT-DMS is what really occurs in the header, and so a "S" is left. This is the result of having DM be the only ITS machine whose official arpanet host name is not "MIT-" concatenated with what it returns as its machine name. Sigh. I supposed a special conditional is the only way to win.  MOON@MIT-MC 05/20/81 17:17:41 Re: Lisp machine gets "file system fucked" trying to read directory from ML: To: (BUG LISPM) at MIT-MC, (BUG ITS) at MIT-MC This is caused by a bug in ITS, such that SIOT does not work properly when reading a binary directory. MLSLV notices the bug while most other programs do not, since it tries to read past the end of the directory. The bug is fixed in the source (ITS 1216); as a byproduct the operation will be much faster. I guess I (or someone) should install this system on ML soon. (The Chaosnet is currently broken in the source, but ML doesn't have a Chaosnet, and only hosts without a Chaosnet cause the original symptom of the complaint from the Lisp machine.) There must also be a bug in the Lisp machine, that it dies so foully when it gets back an ISE0 error from a DIRECTORY operation (the real error is a CHNL NOT OPEN IOC error from the SIOT that is slurping in the MFD, but the error string reported by the file job says ISE0 for some reason, and has what the Lisp machine thinks is the wrong transaction ID.)  Date: 20 May 1981 13:13-EDT From: Robert W. Kerns To: EAK at MIT-MC cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC Date: 19 MAY 1981 2044-EDT From: EAK at MIT-MC (Earl A. Killian) To: (BUG DDT) at MIT-MC Perhaps :REAP FOO should work even if FOO is on an unmounted pack? Does ITS provide the ability to do this (ie. open a directory entry)? ITS dooesn't have a way to do this, although it does have bit 1.5 mean just the right thing in the case of links. Maybe the right thing is to make this bit work for non-links too?  Date: 19 May 1981 1506-EDT From: TAA at MIT-DMS (Timothy A. Anderson) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].198181> ITS 1214 seems to work much better with CFHPI+11 changed from PUSH P,C ? HRLI C,2200 to HRLI C,2200 ? PUSH P,C. The former causes UCPRL to be called with just an address, rather than a byte pointer, and crashes almost immediately. -taa  KLOTZ@MIT-MC 05/18/81 20:08:22 To: (BUG ITS) at MIT-MC I just got a chnl not open error when trying to write a file to the ai device from here. I got some other error before, which emacs was able to handle, but it cleared the screen before I saw it. Attempting to save it again got the channel not open error. It might have been directory full.  MOON@MIT-MC 05/17/81 02:30:37 To: (BUG ITS) at MIT-MC The AI: device is broken such that trying to write a file when there is zero free space on any pack causes the slave simply to .logout, causing an ioc error on the other end (with no error message, just channel not open) and no dead slave job lying around. Maybe this isn't a new bug, I don't know.  ed@MIT-ML (Sent by GSB@MIT-ML) 05/17/81 01:33:00 Re: record time To: (BUG ITS) at MIT-ML MC's record time seems to be 7 months, 23 days, etc.  MOON@MIT-MC 05/16/81 02:34:29 To: tc at MIT-AI CC: (BUG ITS) at MIT-MC The smoke alarm and the temperature alarm behind MC just triggered, neither of them for any discernible reason. By the time I was able to go and look at all the detectors, none of them had their light lit. So if the building burns down later this morning, you can blame me.  MOON@MIT-MC 05/14/81 16:30:32 To: RWK at MIT-MC CC: EAK at MIT-MC, (BUG ITS) at MIT-MC Date: 13 May 1981 23:36-EDT From: Robert W. Kerns To: EAK at MIT-MC cc: BUG-ITS at MIT-MC, rich at MIT-AI Date: 13 May 1981 23:25-EDT From: Earl A. Killian To: RWK at MIT-MC Isn't it supposed to say PACK NOT MOUNTED instead of undefined device? It does for SECOND:, because knowledge of that pack was wired in before the more general scheme was adopted. Not true. SECOND is treated the same as the other named packs. I have fixed the job device handler SYS:ATSIGN DEVICE to return pack not mounted instead of no such device when an OPEN on a known disk pack name gets to it.  Date: 14 May 1981 00:50-EDT From: Robert W. Kerns Subject: NO SUCH DEVICE To: BUG-ITS at MIT-MC, BUG-MAIL at MIT-MC Here's a good reason to know the names of all the disks even when not online: COMSAT@MIT-AI 05/14/81 00:47:43 Re: Msg of Thursday, 14 May 1981 00:43-EDT To: RWK at MIT-MC FAILED: (FILE [THIRD:NIS;*SYS MAIL]) at MIT-AI; Couldn't write message to file; "THIRD:NIS;*SYS MAIL" - NO SUCH DEVICE Failed message follows: -------  Date: 13 May 1981 23:36-EDT From: Robert W. Kerns To: EAK at MIT-MC cc: BUG-ITS at MIT-MC, rich at MIT-AI Date: 13 May 1981 23:25-EDT From: Earl A. Killian To: RWK at MIT-MC Isn't it supposed to say PACK NOT MOUNTED instead of undefined device? It does for SECOND:, because knowledge of that pack was wired in before the more general scheme was adopted. THIRD:, FOURTH:, VISION:, etc. are known from the name stored in the TUT on the disk, so ITS doesn't know anything about the pack at all if it's not mounted. Maybe this info wants to be included in the CONFIG file as well.  Date: 13 May 1981 21:22-EDT From: Robert W. Kerns To: RICH at MIT-AI cc: BUG-ITS at MIT-AI Date: 13 May 1981 17:37-EDT From: Charles Rich To: BUG-ITS at MIT-AI What happened to device THIRD:, it now says undefined device. Also I can't write to PK14: either now. (SECOND: still works). If only you'd noticed the message when you logged in that the disk drive was down.... I guess it would be a help if people would also send a message to *AI when this happens, since it is very easy to overlook SYSTEM MAIL when you log in.  Date: 13 May 1981 17:37-EDT From: Charles Rich To: BUG-ITS at MIT-AI What happened to device THIRD:, it now says undefined device. Also I can't write to PK14: either now. (SECOND: still works).  Date: 10 May 1981 03:55-EDT From: Charles Frankston Subject: [RGF: DM2500] To: FJW at MIT-MC cc: CBF at MIT-MC, BUG-ITS at MIT-MC, GZ at MIT-MC, MOON at MIT-MC, RGF at MIT-MC Date: 3 May 1981 00:12-EDT From: Frank J. Wancho RGF at MIT-MC Ok, I suppose the distinction is that since my DM3025A also responds to DM2500 codes and that I use :TCTYP DM SCROLL, everything works just fine for me. But, when another tries to emulate a DM2500 and uses the same :TCTYP command (effectively), it doesn't scroll except when using CRTSTY??? -- I claim again that :TCTYP does it right and the documentation in KSC;DM2500 DOC must be either misleading or incomplete... or not properly implemented in RGF's emulation or some combination... I explained the problem in detail. The documentation in KSC;DM2500 DOC is correct for a real Datamedia. Your DM3025A does not work the same way. You like the way it works better, great, tell your friend to make his work that way. I don't see what you expect us to do, go around the country with a soldering iron fixing Datamedias?  DCP@MIT-MC 05/10/81 00:34:42 To: (BUG ITS) at MIT-MC Is there a good reason why %PIATY (interrupt word 1, LH bit 4000) is NOT documented in MC:.INFO.;ITS INTRUP. I think I understand it well enough to document it, but I would prefer someone who knows precisely what it does to document it. Also, what about all the other bits in the Left Half? Are they real ntterupts, or just unused bits?  GJC@MIT-MC 05/09/81 17:23:52 To: (BUG ITS) at MIT-MC CC: RWK at MIT-MC I saw a GUMBY JOB.07 SYS with an MPV had been trying to read AR1:USERS2;ELDEFS could be that his archive is messed up and he doesn't know it?  RWK@MIT-MC 05/08/81 02:50:56 Re: Recent problems with archives and EMACS libraries To: (BUG ITS) at MIT-MC CC: MMCM at MIT-MC, KRONJ at MIT-MC, KMP at MIT-MC, JPG at MIT-MC CC: LPH at MIT-MC, GJC at MIT-MC, JGA at MIT-MC, ASB at MIT-MC CC: SGR at MIT-MC, CFFK at MIT-MC, (*MSG *MC) at MIT-MC These were due to the wrong port being enabled on the ARM-10 (the port for the DL10 wasn't on). This has been rectified. This affected mapping of pages from THIRD: and FOURTH: into memory. Read-only pages were not damaged, read/write pages were written back as zero. * If you had EMACS libraries that stopped working, they should work now. * If you had a program residing on THIRD: or FOURTH: that stopped working, it should work now. * If you had an archive that stopped working, it is now unusable. You should send a request to FILE-RETRIEVE requesting that it be recovered from tape. (Be sure to include the filename!). We are sorry for any inconvenience.  Date: 8 May 1981 00:28-EDT From: David Eppstein To: BUG-ITS at MIT-MC I have been getting a lot of "DEVICE FULL" errors lately when trying to read files from archives.  RLB@MIT-MC 05/07/81 20:22:39 To: (BUG ITS) at MIT-MC Supposing that the recent ARC device lossage had causes related to the Emacs lossage KMP etc have noted, I copied DEVICE;DEVICE ARC to MC from AI. Just before doing so, I $0L'd DEVICE;.FILE. (DIR) and after the copy I $0Y'd it to DEVICE;.FILE? (DIR) I don't want to risk trashing MY archives finding out whether the copy fixed anything, though.  MMCM@MIT-MC 05/07/81 17:41:09 Re: more file lossage To: (BUG ITS) at MIT-MC My EMACS init file, which has not changed in about a year, got broken today. I renamed the old one to MMCM;MMCM BROKEN, which still gets a LIB error when you try to load it, and copied over one from AI, which now loads successfully. The two files are identical, at least when you compare them they are.  LPH@MIT-MC 05/07/81 14:56:36 To: (BUG ITS) at MIT-MC the archive device is rather messed up. i get all sorts of trash appearing in the wasted words and in the number of blocks in files. some of my archives get UNRECOGNIZABLE file errors when i try to list them; though i can use emacs to visit the archive itself, the individual files can't be listed correctly at ddt...  GJC@MIT-MC 05/07/81 10:14:30 To: (BUG ITS) at MIT-MC The archive devices on MC are going down in flames the last few days, resulting in files being forever locked, etc.  KMP@MIT-MC 05/06/81 23:42:47 To: (BUG ITS) at MIT-MC, ECC at MIT-AI CC: EB at MIT-AI Today I noticed several unusual effects which affected Emacs, but which I attribute to ITS or hardware lossage. A dumped Emacs which I had and for which no files it depended on had changed suddenly stopped working. Doing M-X Load LibraryVT52 loaded the SAFETY library for half the afternoon in any version of Emacs. ECC and I both looked at this and were kinda confused. :PRINT showed EMACS;VT52 :EJ was really not the SAFETY library, so something was off. Later I was going to show EB how M-X Load LibraryVT52 was losing, but it said that the file was not in library format. This is wierd because it had still not been altered (since March, 1980). I just renamed EMACS;VT52 :EJ to EMACS;VT52 O:EJ and copied in EMACS;VT52 :EJ and suddenly my dumped Emacs is working again. M-X Load LibraryVT52 is now working also. A binary comparison of these files (I opened them in fixnum mode in lisp and did a word-by-word comparison) shows that they are identical and doing M-X Load LibraryEMACS;VT52 O:EJ now wins. I am wondering what kind of lossage could have caused this problem. Any ideas? Maybe the directory was somehow inconsistent? -kmp  Date: 3 May 1981 00:12-EDT From: Frank J. Wancho Subject: [RGF: DM2500] To: CBF at MIT-MC cc: BUG-ITS at MIT-MC, FJW at MIT-MC, GZ at MIT-MC, MOON at MIT-MC, RGF at MIT-MC Ok, I suppose the distinction is that since my DM3025A also responds to DM2500 codes and that I use :TCTYP DM SCROLL, everything works just fine for me. But, when another tries to emulate a DM2500 and uses the same :TCTYP command (effectively), it doesn't scroll except when using CRTSTY??? -- I claim again that :TCTYP does it right and the documentation in KSC;DM2500 DOC must be either misleading or incomplete... or not properly implemented in RGF's emulation or some combination... --Frank  CBF@MIT-MC 05/02/81 20:34:46 Re: [RGF: DM2500] To: MOON at MIT-MC CC: FJW at MIT-MC, RGF at MIT-MC, (BUG ITS) at MIT-MC CC: (BUG CRTSTY) at MIT-MC, GZ at MIT-MC Unfortunately, a real Datamedia will very easily drop out of roll mode. Exiting Insert/Delete mode (^X) will also exit roll mode. On some models apparently a Master Reset command (^_) will also exit roll mode. In order to actually use Datamedia hardware scroll features it would be necessary to always follow each of these commands with an enter roll mode. This would probably work for TCTYP support. The reason CRTSTY does not use this method is because it allows the use of all 80 columns on the terminal (if a terminal autowraps the way a Datamedia does, you cannot use the last column with TCTYP support). If the terminal were to operate in roll mode all the time, but the ITS user had asked for wrap mode (the default, as opposed to scroll mode), and were to output a character in the last column of the last line, the terminal would auto-newline and scroll irretrievably losing the top line of the screen before CRTSTY could do anything to compensate. In fact there would be no way CRTSTY could safely put a character in that position, short of temporarily exiting roll mode. I guess it seemed easier to implement scrolling with delete line.  MOON@MIT-MC 05/02/81 17:28:13 Re: [RGF: DM2500] To: FJW at MIT-MC, RGF at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC, GZ at MIT-MC I forgot to say in my previous message that by default ITS will never scroll but will always wrap around at the bottom of the screen. If you would prefer scrolling say :TCTYP SCROLL and then output from most programs will be scrolled.  MOON@MIT-MC 05/02/81 17:26:44 Re: [RGF: DM2500] To: FJW at MIT-MC, RGF at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC, GZ at MIT-MC ITS sends ^M ^J ^W when it wants to go to the next line, which should scroll if given on the bottom line. Real datamedias ignore the ^J in this circumstance, but ITS sends it anyway for the benefit of some simulated datamedias. ^W is erase-to-end-of-line of course. Maybe CRTSTY doesn't send the ^J? ITS assumes that roll mode is on and that you have set the line length short enough that the hopeless auto-nl misfeature does not get invoked. The :tctyp command does both of these I believe. You should not implement auto-nl and not implement lack of roll mode. What you should do is handle ^M by going to start of same line, ^J by going down a line and scrolling if that would take you off the bottom of the screen, both of these unconditionally. That will work with ITS but perhaps not with some other programs such as CRTSTY and WAITS that claim to know about datamedias. It will also work with TECO on Tenex and TOPS-20.  Date: 1 May 1981 03:43-EDT From: Robert W. Kerns Subject: mail files To: dp at MIT-ML cc: RICHARDSON.ALYSON at MIT-MC, BUG-its at MIT-AI Date: 30 Apr 1981 2249-EDT From: ALA To: bug-its at MIT-AI cc: richardson.alyson at KL2137 Reply-to: dp at MIT-ML Subject: mail files Message-ID: My mail file on mit-ai (users0;ala mail) seems to be locked. Can someone look into this? Thanks. Alyson (ala@mit-ai) -------- This means one of two things. One is that it may have already been deleted, but not yet removed from the directory because someone is reading it (such as RMAIL). The other possibility, which isn't likely in this case, is that the file is still being written, or is being appended to.  Date: 1 May 1981 03:22-EDT From: Frank J. Wancho Subject: [RGF: DM2500] To: BUG-ITS at MIT-MC, BUG-CRTSTY at MIT-MC cc: FJW at MIT-MC, RGF at MIT-MC, GZ at MIT-MC Ron is using the documentation found in KSC;DM2500 DOC and GZ's DM2500 emulation code for use on a TRS-80 to emulate a DM2500 on his micro and it seems that there is a difference in how a DM2500 is scrolled using TCTYP vs CRTSTY. (Now, I know there is, but my terminal emulates a DM2500 too, and I don't use CRTSTY, and it scrolls alright for me.) Is there a difference between the description of a DM2500 in that file and the ITS implementation as far as how scrolling is handled? The reason I ask is that I disagree with Ron and believe that the way ITS does is right and CRTSTY does it awkwardly (nad takes up an unnecessary job slot in the process. --Frank -------------------- Date: 05/01/81 01:34:12 From: RGF Re: DM2500 Frank, I still have problems with the DM2500 when I'm not using CRTSTY. The only time I can get a screen scroll is when I'm in CRTSTY, and it does a scroll by going to top line and issuing a delete, then going back to bottom line. Is it possible to have the "natural" DM2500 (whatever *that* is) do this? ====================  Date: 30 Apr 1981 2249-EDT From: ALA To: bug-its at MIT-AI cc: richardson.alyson at KL2137 Reply-to: dp at MIT-ML Subject: mail files Message-ID: My mail file on mit-ai (users0;ala mail) seems to be locked. Can someone look into this? Thanks. Alyson (ala@mit-ai) --------  Moon@MIT-MC 04/30/81 04:03:50 Re: THIRD; directory at AI To: rich at MIT-AI CC: RWK at MIT-MC, ZVONA at MIT-MC, (BUG ITS) at MIT-MC Please choose a different name for this directory. Having a device and a directory with the same name confuses both people and some programs.  Date: 29 April 1981 22:43-EST From: Robert W. Kerns To: ZVONA at MIT-AI cc: BUG-ITS at MIT-AI Date: 28 April 1981 20:50-EDT From: David Chapman To: BUG-ITS at MIT-AI there is a bogus directory third;. i suppose it is bogus since there is no second;. It is empty. also confusing. I don't know who created this losing directory, but I will go upstairs and try to find out, so I can explain to them why they should not do this. On the off chance that it was somebody on this mailing list with a momentary brain fade, I remind you all once again that directories should not share the same name as devices if you do not wish to confuse both programs and people. I have deleted the link which preserved the directory, so it will go away the next time the system is brought up.  Date: 29 April 1981 19:14-EDT From: Edward Barton To: BUG-ITS at MIT-AI LNKEDP is in the SYSCTB table, but :CALL LNKEDP doesn't know about it.  GJC@MIT-MC 04/28/81 23:35:42 To: (BUG ITS) at MIT-MC CC: RWK at MIT-MC There is a job on MC uname 500A41 jname ARPA Sname 500A41 status +LOGIN Chaos network connection to foreing addr PLASMA 15411 with flag F. it has 15:25:08 (i.e. one hell of a shitload) of cpu time. I'm just going to gun it as this seems to be a common and reported bug.  Date: 28 April 1981 20:50-EDT From: David Chapman To: BUG-ITS at MIT-AI there is a bogus directory third;. i suppose it is bogus since there is no second;. It is empty. also confusing.  Date: 20 April 1981 20:13-EST From: David Eppstein To: RWK at MIT-MC cc: BUG-ITS at MIT-MC, KLOTZ at MIT-MC KRONJ@MIT-MC 04/19/81 05:25:08 To: (BUG ITS) at MIT-MC Several problems: (2) If I do :COPY AR1:GUEST2;EINIT >,$ it shows the default file as AR1:GUEST2;EINIT 90 rather than >. (90 is the current version). This is irritating for copying the file to another Fn1. If I wanted 90 I would have said 90 and not >. This is a very useful feature. It won't hurt you to type a space and a '>', and it makes possible retaining version numbers when moving files, something which is done very often. I just found that out when copying my files to a new directory (I was told my archive was probably at fault for not compacting rather than ITS, so I got a new one.) (3) What happened to :TCTYP H19? How should I know? You haven't said anything about what problem you experienced. It was setting it to Glass,+/- a lot of things. The problem has been fixed.  Date: 20 April 1981 18:24-EST From: Robert W. Kerns To: KRONJ at MIT-MC cc: BUG-ITS at MIT-MC, KLOTZ at MIT-MC KRONJ@MIT-MC 04/19/81 05:25:08 To: (BUG ITS) at MIT-MC Several problems: (2) If I do :COPY AR1:GUEST2;EINIT >,$ it shows the default file as AR1:GUEST2;EINIT 90 rather than >. (90 is the current version). This is irritating for copying the file to another Fn1. If I wanted 90 I would have said 90 and not >. This is a very useful feature. It won't hurt you to type a space and a '>', and it makes possible retaining version numbers when moving files, something which is done very often. (3) What happened to :TCTYP H19? How should I know? You haven't said anything about what problem you experienced.  Date: 20 April 1981 02:38-EST From: David A. Moon Subject: New system needed To: BUG-ITS at MIT-AI I turned on support for insert/delete characters on C100s in TCTYP. Evidently this was premature since the system installed on MC is too old to support it. MC should get a new system ASAP (the source seems to be OK, it works on ML). Other machines may need new systems, too.  KRONJ@MIT-MC 04/19/81 05:29:11 To: (BUG ITS) at MIT-MC ...to continue: (3) What happened to :TCTYP H19? Problems (1) and (2) combine nastily: I used to copy EINIT > (my largest file) to a couple of other FN1s on the archive and then delete them to compact the archive and save space. Now it is not only harder to type the :COPY commands, but the process as a whole instead of saving space leaves me with a huge archive! Please fix soon. P.S. A command to compact archives so I wouldn't have to go through all that trash would be v. useful.  KRONJ@MIT-MC 04/19/81 05:25:08 To: (BUG ITS) at MIT-MC Several problems: (1) If I delete a large file or two from an archive (say around four blocks) it used to compact the archive to 0 wasted words. Now the wasted words just sit there and my archive gets larger and larger (unless this is some asynchronous process and by now it has been compacted). (2) If I do :COPY AR1:GUEST2;EINIT >,$ it shows the default file as AR1:GUEST2;EINIT 90 rather than >. (90 is the current version). This is irritating for copying the file to another Fn1. If I wanted 90 I would have said 90 and not >. (3) What happened to :TCTYP h  Date: 18 Apr 1981 0337-EST From: CSTACY at MIT-DMS (Christopher C. Stacy) To: BUG-its at MIT-DMS Cc: bug-tctyp at MIT-MC Subject: BUG => its Message-id: <[MIT-DMS].194515> On DM, doing :TCTYP H19 ERROR: CNSSET: MEANINGLESS ARGS 270>>.CALL 3467 (CNSSET) This wasnt broken 2 hours ago!  Date: 15 Apr 1981 1119-EST From: WJN at MIT-DMS (Wayne J. Noss) To: BUG-ITS at MIT-DMS Subject: BUG => ITS Message-id: <[MIT-DMS].194047> If I do AR4$^F just to look at an archive, the file author of the AR4 file gets set to my hsname. I think that, to be meaningful, the author should not be set by what is (should be) a read-only operation. the WJN  Date: 13 Apr 1981 1631-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: Re: My previous message about forced conversion to TCP To: Moon at MIT-AI, PHW at MIT-AI, av at MIT-DMS, psz at MIT-ML, wam at MIT-ML, jm at MIT-MC cc: (BUG ITS) at MIT-AI In-Reply-To: Your message of 4-Apr-81 0039-PST TOPS-20 does have a working TCP TELNET implementation. I wrote it. -- Mark -- PS: I agree with you that 1983 is premature for the changeover. -------  MOON@MIT-MC 04/13/81 12:06:51 Re: MLDEV broken To: (BUG ITS) at MIT-MC Doing DELETE on ML: and AI: from AI seems to have started trying to do the deletion twice, such that it hangs for a fairly long while then says file not found. I didn't try it on any file names with ">" or "<" in them since that could be dangerous. I haven't noticed this before today.  Date: 6 April 1981 23:35-EST From: Robert W. Kerns Subject: [GREN at MIT-MC: Forwarded] To: BUG-ITS at MIT-MC Date: 6 APR 1981 2304-EST From: GREN at MIT-MC (Ian G. Macky) To: (BUG DDT) at MIT-MC :MOVEing from SYS***; does not make any sort of message on the console. Was this omission on purpose? From or to, that is. ---------------- It seems DELEWO doesn't check for being a system directory.  Date: 6 April 1981 10:51-EST From: Robert W. Kerns Subject: This is an ARPAnet problem, but is there any way which ITS can help it? To: ELLEN at MIT-MC cc: BUG-MAIL at MIT-MC, BUG-ITS at MIT-MC ELLEN@MIT-MC 03/24/81 18:08:46 Re: This is an ARPAnet problem, but is there any way which ITS can help it? To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC MILNE@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 You should tell them about :REATTACH ... that's what it's for. Gad, sending the message automagically would be gross. If the problem is that their network just crashes totally and they cannot reconnect for a long period of time, they should be putting lots of pressure on it's implements to either fix it or go work for the post office (um, er, oh, so THAT'S the problem...)  MOON@MIT-MC 04/06/81 02:46:21 Re: Keeping track of system changes To: (BUG ITS) at MIT-MC Please log changes to ITS in the file MC:SYSTEM;ITS RECENT. I have moved this file off of my personal directory. Just a brief note will suffice to help keep track of what's going on. There is a ---- in the file at the point where new changes are supposed to be added. After that point are a collection of mostly fairly random ideas about things that could be changed in the future. It hasn't been updated since Sep 20, 1980, so if you made any changes worthy of note since then please put them in.  Date: 4 APR 1981 0406-EST From: Moon at MIT-AI (David A. Moon) To: RWK at MIT-MC CC: (BUG LISPM) at MIT-AI, (BUG ITS) at MIT-AI Date: 30 March 1981 19:26-EST From: Robert W. Kerns Subject: Supdup typeout process To: MOON at MIT-MC ... But the primary bug I was reporting was that typing control-greek-E blowing away the typeout process. Fixed in the source of TS3TTY !!. It was echoing as a garbage GT40 control command. I am not going to fix the GT40 simulator, it would injure my stomach and throat.  Date: 4 APR 1981 0339-EST From: Moon at MIT-AI (David A. Moon) Subject: My previous message about forced conversion to TCP To: PHW at MIT-AI, av at MIT-DMS, psz at MIT-ML, wam at MIT-ML To: jm at MIT-MC CC: (BUG ITS) at MIT-AI Two or three people at other sites have communicated with me about this. Apparently not even TOPS-20 actually has working TCP protocols (neither telnet, nor FTP, nor mail). The concensus seems to be that the change cannot possibly happen on most sites by 1983, and hopefully the sites can convince the sponsors to convince the network management accordingly. We are not alone in not having the manpower to make this sort of complex and unnecessary change, it would appear.  GJC@MIT-MC 04/03/81 17:23:08 To: (BUG ITS) at MIT-MC CC: (BUG EMACS) at MIT-MC Typing along in my EMACS, just got an ILLEGAL OPCODE message and was detached. Very strange, maybe I was being hacked. Everything working fine now.  GJC@MIT-MC 03/31/81 08:22:03 To: (BUG ITS) at MIT-MC CC: GJC at MIT-MC 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.  Moon@MIT-MC 03/30/81 17:04:12 Re: > filename convention To: WILL at MIT-AI CC: (BUG ITS) at MIT-AI Date: 29 MAR 1981 2249-EST From: WILL at MIT-AI (William D Clinger) To: (BUG ITS) at MIT-AI "will;atolia >" refers to "will;atolia demo10" rather than to "will;atolia 41". Is this as it should be? 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.  Moon@MIT-MC 03/30/81 17:01:21 Re: ITS Arpanet system maintenance To: JM at MIT-MC, av at MIT-DMS, phw at MIT-AI, wam at MIT-ML To: psz at MIT-ML CC: (BUG ITS) at MIT-MC, ELLEN at MIT-MC ... Our next major netwide effort will be to cutover all hosts to the new DOD Standard Protocols by 1 January of 1983. This is the cutoff date and it will be enforced. ... Maj. Joe Haughney DCA Code 531 Defense Communications Agency 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.  KMP@MIT-MC (Sent by PIQUE@MIT-MC) 03/30/81 01:04:04 Re: Long input echo delays To: (BUG ITS) at MIT-MC 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  Date: 29 MAR 1981 2249-EST From: WILL at MIT-AI (William D Clinger) To: (BUG ITS) at MIT-AI "will;atolia >" refers to "will;atolia demo10" rather than to "will;atolia 41". Is this as it should be? Peace, Will  Date: 26 MAR 1981 2139-EST From: zemon at MIT-AI (Landon M. Dyer) Sent-by: ___024 at MIT-AI To: (BUG ITS) at MIT-AI 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-  Date: 26 MAR 1981 1711-EST From: RMS at MIT-AI (Richard M. Stallman) To: GSB at MIT-AI, (BUG ITS) at MIT-AI 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.  ELLEN@MIT-MC 03/24/81 18:08:46 Re: This is an ARPAnet problem, but is there any way which ITS can help it? To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC MILNE@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  GSB@MIT-ML 03/21/81 00:06:59 Re: echoin To: (BUG ITS) at MIT-ML 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.  GJC@MIT-MC 03/20/81 19:05:21 To: (BUG ITS) at MIT-MC 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.  MOON@MIT-MC 03/20/81 16:30:35 Re: BUG => ITS (net hangage on DM) To: PDL at MIT-DMS CC: (BUG ITS) at MIT-MC 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"?  Date: 20 Mar 1981 1338-EST From: PDL at MIT-DMS (P. David Lebling) To: BUG-ITS at MIT-DMS 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  Date: 19 Mar 1981 at 0318-PST From: Stuart Mclure Cracraft To: bug-its at MC Subject: roll mode Sender: mclure at Sri-Unix If I telnet into mc, do :tctyp dm (which turns off roll mode on my datamedia), and then logout, ITS fails to turn roll mode back on.  Date: 18 Mar 1981 2041-EST From: TAA at MIT-DMS (Timothy A. Anderson) To: RWK at MIT-MC Cc: (BUG ITS) at MIT-MC, PDL at MIT-MC 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  RWK@MIT-MC 03/18/81 20:02:33 To: (BUG ITS) at MIT-MC CC: TAA at MIT-MC, PDL at MIT-MC 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.  Date: 18 Mar 1981 1943-EST From: TAA at MIT-DMS (Timothy A. Anderson) To: BUG-its at MIT-DMS 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  Date: 18 Mar 1981 1016-EST From: PDL at MIT-DMS (P. David Lebling) To: BUG-ITS at MIT-MC 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  CBF@MIT-MC 03/15/81 20:53:32 Re: TS3TTY 281, H19 padding & C100 char insert/delete To: MOON at MIT-MC CC: CBF at MIT-MC, (BUG ITS) at MIT-MC MOON@MIT-MC 03/15/81 20:23:08 Re: TS3TTY 281, H19 padding & C100 char insert/delete 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. Nah, RWK didn't do that, I did, and took it into account in the 5ms figure.  Date: 15 March 1981 21:08-EST From: Robert W. Kerns Subject: TS3TTY 281, H19 padding & C100 char insert/delete To: MOON at MIT-MC cc: CBF at MIT-MC, BUG-ITS at MIT-MC MOON@MIT-MC 03/15/81 20:23:08 Re: 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.  Date: 15 Mar 1981 (Sunday) 2100-EDT From: SHRAGE at WHARTON-10 ( Jeffrey Shrager) Subject: Typing a ":" To: bug-its at MIT-AI I might have bugged this before. I recall thinking that I should do so about three weeks ago. If not... here goes: When you are at DDT's "*" prompt, you cannot backspace and fix a missing ":". That is, for example, I begin typing a command and the realize that it should have had a colon before it. If I backspace (rubout) to the beginning and enter the colon then retype the command it does not realize that the colon is there and errors saying "you must type a colon..." If I bugged this before forgive me. My mind must be going. -- JEff  MOON@MIT-MC 03/15/81 20:23:08 Re: 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.  CBF@MIT-MC 03/15/81 05:46:47 Re: TS3TTY 281, H19 padding & C100 char insert/delete To: (BUG ITS) at MIT-MC 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.  moon@MIT-MC (Sent by ___165@MIT-MC) 03/11/81 23:43:18 To: (BUG ITS) at MIT-MC 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?  Date: 11 MAR 1981 0728-EST From: RWK at MIT-AI (Robert W. Kerns) Subject: LNKEDP To: (BUG ITS) at MIT-AI 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.  RWK@MIT-MC 03/11/81 07:08:07 To: (BUG ITS) at MIT-MC 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.  Date: 10 MAR 1981 1911-EST From: RLB at MIT-MC (Richard L. Bryan) To: EBM at MIT-MC, MT at MIT-MC CC: (BUG ITS) at MIT-MC GJC@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.  GJC@MIT-MC 03/10/81 18:22:26 Re: last bug note about jobs with unusally long running times. To: (BUG ITS) at MIT-MC gosh, I didn't think about the fact that MC has been up for ten days.  GJC@MIT-MC 03/10/81 18:02:59 To: (BUG ITS) at MIT-MC 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.  Date: 7 MAR 1981 1001-EST From: KLOTZ at MIT-AI (Leigh L. Klotz) To: (BUG ITS) at MIT-AI 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.  Moon@MIT-MC (Sent by ALAN@MIT-MC) 03/06/81 04:38:29 To: (BUG ITS) at MIT-MC I wonder how come TYONRM+2 got decremented or else got bit 35 turned off?  Date: 4 MAR 1981 1529-EST From: KLOTZ at MIT-AI (Leigh L. Klotz) To: (BUG ITS) at MIT-AI 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.  Date: 2 March 1981 03:12-EST From: Ed Schwalenberg Subject: Blast from the past To: PGS at MIT-AI cc: BUG-ITS at MIT-AI 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.  Date: 1 MAR 1981 2014-EST From: PGS at MIT-AI (Patrick G. Sobalvarro) To: (BUG ITS) at MIT-AI 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.  Date: 26 February 1981 03:36-EST From: Charles Frankston Subject: H19's on ITS To: EBM at MIT-XX cc: BUG-its at MIT-AI Date: 25 Feb 1981 2031-EST From: EBM at MIT-XX :TCTYP H19 would actually be useful if ITS would pad the ins/del line sequences. Our experience indicates that 17ms. per line inserted/deleted is required at 9600 baud, and no padding is needed at 1200 and lower. We just pad proportionately in between. (I.e., 4800 baud => 8.5ms pad, etc.) I don't think this will screw anybody very much, and would certainly please H19 users, though having ins/del char would be nice, too. Getting that would require adding a terminal type, though (sigh). Anyway, is anybody out there willing the hack TS3TTY to put in the padding? You message makes no sense, but I implemented it anyway. I don't think the H19 is 17ms PER line inserted or deleted, and I don't see why it only takes 8.5ms if the UART is running at 4800 baud. I implemented a padding of .625 ms per line moved at speeds higher than 1200 baud, and no padidng at 1200 baud. This is only in the source of course, some poor sucker who brings up the next ITS will have to debug it.  Date: 25 Feb 1981 2031-EST From: EBM at MIT-XX Subject: H19's on ITS To: bug-its at ai :TCTYP H19 would actually be useful if ITS would pad the ins/del line sequences. Our experience indicates that 17ms. per line inserted/deleted is required at 9600 baud, and no padding is needed at 1200 and lower. We just pad proportionately in between. (I.e., 4800 baud => 8.5ms pad, etc.) I don't think this will screw anybody very much, and would certainly please H19 users, though having ins/del char would be nice, too. Getting that would require adding a terminal type, though (sigh). Anyway, is anybody out there willing the hack TS3TTY to put in the padding? -------  JLK@MIT-MC 02/23/81 19:02:52 Re: MUX, ITS, and Tektronix wierdness To: (BUG ITS) at MIT-MC CC: RCE at MIT-MC After painstaking investigations, I have determined that ITS does some very wierd things on Chaos Supdup connections with a TCTYP of %TNTEK. There seems to be a bug where it ends up throwing away 2 packets completely. The only thing I change in my icp packet is the tctyp field (to say, teleray or somesuch) and it works fine. This is repeatable. Nothing in my software depends on the tctyp. The observed wedged state is that 2 packets are missing and ITS refuses to resend them, even though ITS agrees that they have not been acknowledged. Its hard for me to see how this dependency could exist (output reset wierdness maybe?)  Date: 23 FEB 1981 1138-EST From: SLH at MIT-AI (Stephen L. Hain) To: (BUG ITS) at MIT-AI Apparently a disk error has trashed my mail file, on ty's directory Laurel  RWK@MIT-MC 02/19/81 13:11:04 To: CSTACY at MIT-MC CC: (BUG ITS) at MIT-MC The IMP seems to be having troubles.  Date: 19 FEB 1981 1259-EST From: CSTACY at MIT-AI (Christopher C. Stacy) To: (BUG ITS) at MIT-AI This is really weird; I must be overlooking something simple. When I connect to any ITS from DCECTIP or PENTIP (which are the only ones I tried), funny things happen to my connection. These funny things are consistant, and do not happen when I use this same terminal/modem (300bd,btw) on non-net systems, or on a Unix I tried which is on the net. These funny things also do not happen on an AI Dialup. The funny things: the system pases in the middle of the SSTATUS and hangs for a few secs, sometimes I have to control-G out to pword toplevel. Various characters are received and echoed wrong. When I first saw this I thought that my terminal or modem was dropping bits, but it is now clear that the problem only occurs connecting to an ITS over a TIP. To wit, s := ^S n := ^N but N:=N a := ^A space := nothing? (sounds like its xmitting it, but no echo) atsign := same as space I cant imagine whats wrong. Help? Thanks, Chris  Date: 16 FEB 1981 1924-EST From: EB at MIT-AI (Edward Barton) Subject: ai paper tape punch To: (BUG ITS) at MIT-AI CC: CENT at MIT-AI MSG: DEAD PUNCH the ai papertape punch, hasn't worked in years and has miniscule to disappearing chance of ever being repaired. If the punch is really permanently losing, OPENs on PTP: should be made to fail with some appropriate error code.  Date: 14 FEB 1981 2128-EST From: RWK at MIT-AI (Robert W. Kerns) Subject: File clobberage To: (BUG MAIL) at MIT-AI CC: (BUG ITS) at MIT-AI Page 0 of AI:.MAIL.;^Q ^Q LIST ^Q QUEUE was bashed with random mail (what looked like a random mail file). I renamed the file .MAIL.; LIST CLOBRD, and copied the old set of (MSGS REMIND MASTER) to .SAVE *, and did a MAKQFI. It seems to be working OK now.  ED@MIT-ML 02/12/81 04:09:36 Re: Index to History To: (BUG ITS) at MIT-ML Those of you who want to experience the old days might wish to run ML:SYS;TS MONIT, which for some reason does not have symbols nor the correct start address (1300). It is pretty badly broken, but great fun to play with nevertheless. Too bad we don't have any working microtapes to really hack it with.  Date: 12 FEB 1981 0235-EST From: MOON5 at MIT-AI (David A. Moon) To: (BUG ITS) at MIT-AI I would kind of like to know why single pages of the inquir data base have been clobbered to what looks like pages out of other files three times in the last two days, on AI. I don't think anyone maps it in read-write, so it's hard to see how to blame it on Howard's memory. Anyone have any ideas? Anyone observe any other file clobbering problems?  Date: 8 FEB 1981 2226-EST From: MOON at MIT-AI (David A. Moon) To: (BUG ITS) at MIT-AI I tried to take AI down using the DOWN/KILL command in LOCK so that I could bring back a fixed disk. The command fails to do anything, it just gives an _ prompt.  Date: 8 February 1981 09:26-EST From: Robert W. Kerns To: KMP at MIT-MC cc: BUG-ITS at MIT-MC KMP@MIT-MC 02/07/81 05:20:27 To: (BUG ITS) at MIT-MC MC has been randomly resetting its arpa connections this evening. I don't know why. I didn't notice anyone running LOCK. I guess it does it on its own sometimes. Usually the net goes off, on, off then there's a bit of a gap (as much as a minute or two) and then back on again... There was a system message a while back informing everyone that the TIP and IMP were being moved. Perhaps this is what was doing it?  Date: 8 FEB 1981 0352-EST From: MP at MIT-AI (Mark A. Plotnick) Subject: long leaders To: (BUG ITS) at MIT-AI I just tried to get onto ML from a TIP. It wouldn't connect me, saying that the Host didn't support extended leaders. Is this something new? I thought extended leaders were required since Jan. 1.  Date: 7 FEB 1981 1227-EST From: JONL at MIT-AI (Jon L White) Subject: Crunch on AI:SYS;, part II To: (BUG ITS) at MIT-AI ITSDFS 4 ==> SYSENG; SAIDFS 17 ==> SYSENG' Both are "old" files. current versions still on SYS;  Date: 7 FEB 1981 1224-EST From: JONL at MIT-AI (Jon L White) Subject: Directory space crunch on AI:SYS; To: (BUG ITS) at MIT-AI, RWK at MIT-MC I moved ATSIGN ODEVIC and ATSIGN OHACTR to SYSBIN;, since one hadn't been referenced in over 2 years, and the other in almost a year.  KMP@MIT-MC 02/07/81 05:20:27 To: (BUG ITS) at MIT-MC MC has been randomly resetting its arpa connections this evening. I don't know why. I didn't notice anyone running LOCK. I guess it does it on its own sometimes. Usually the net goes off, on, off then there's a bit of a gap (as much as a minute or two) and then back on again...  Date: 7 February 1981 05:05-EST From: Charles Frankston Subject: confused about char ins/del To: BUG-ITS at MIT-MC cc: HAL at MIT-MC, C100-FANS at MIT-MC, Craig Everhart at CMU-10A Date: 7 February 1981 00:52-EST From: Earl A. Killian The C100 would probably work fairly well on ITS without using CRTSTY, just as it does on XX. This is to say that while it is completely trivial to construct legitimate sequences of requests to the virtual terminal support that will lose, those sequences don't tend to come up while editing in EMACS. With CRTSTY, however, it is extremely common for CRTSTY to produce such sequences as the result of other unrelated optimizations that it is doing. As a result CRTSTY definitely cannot use insert/delete character unless your terminal supports the set blank characteristics and set insert mode commands. On ITS it's not so clear, but I think having the default be off is still the right thing; users with the proper microcode or bravery can always try :TCTYP +%TOCID (I hope this works). :TCTYP +%TOCID does not work, in the sense that ITS has no entries for char ins/del on a C100 whether on by default or not. I was going to put entries in, but unfortunately, the C100 uses Escape-Null to exit insert mode. I can't put the null in an ASCIZ string which is what the table entries consist of, and I don't know TS3TTY well enough to figure out a good kludge..  Date: 7 FEB 1981 0435-EST From: CBF at MIT-MC (Charles Frankston) Subject: TS3TTY terminal padding To: (BUG ITS) at MIT-MC, (BUG TERMINALS) at MIT-MC Remember the feature to vary a terminal's line insert/delete padding in proportion to the number of lines left to be moved on the screen? Anyway, it was never exercised in any terminal defintions. EAK and I tried patching the entry for a C100 with PADCR=1 on ML and found it seems to work fine. However, when calculating the values for a 1200 baud C100 or for a Teleray 1061, we find that they would really want to be 1.7 and 2.5 milliseconds respectively. Rounding 2.5 ms up to 3 ms makes a difference of 12 ms (* 10 lines moved can get annoying). Therefore in the fine tradition of TS3TTY kludges, if the table entry is negative (which used to mean the value given is milliseconds per line to be moved), then it is the number of 1/8 milliseconds per line to be moved. This is MC:SYSTEM;TS3TTY 271, I have updated the terminal entries for the C100 and Teleray. Good luck to the next ITS debugger, why am I so verbose?  HIC@MIT-MC 02/04/81 17:55:35 To: (BUG ITS) at MIT-MC Oh well, I was confused...iot looks like some subtle off by a few error when the MMP almost gets full.  HIC@MIT-MC 02/04/81 17:52:07 To: (BUG ITS) at MIT-MC MC just tried to make an extra MMP page (one more than allowed). MEMFR was 7. Is someone forgetting to decrement this guy?  Date: 4 February 1981 05:01-EST From: Robert W. Kerns To: ED at MIT-AI cc: GNU at MIT-AI, BUG-ITS at MIT-AI Date: 2 February 1981 21:59-EST From: Ed Schwalenberg To: GNU at MIT-AI cc: BUG-ITS at MIT-AI What is the effect of linking to a free STY (i.e. Finger shows it as "STY not in use")? I saw someone doing it earlier tonight and wondered. It depends on the state of the STY. If you just link to an unused sty, you get a ?, since the tty you want to link to does not exist. What must have happened is that the sty became unused after the link existed, as for instance if someone logs out from a sty and you link to him just before or after the logout (but before the net connection is closed. I believe that the system doesn't really do anything with stys whose only activity is a link, and they will vanish, breaking the link. Actually, this isn't right at all. You can link to a free sty, and slave it, etc. The fact that you have done so is recorded. It doesn't work very well, tho, since there isn't anybody on the other end of the STY to gobble up it's output, so it quicly fills up it's output buffer and can't print anything more. FINGER's 'Sty not in use' merely means that it is unowned.  Date: 3 FEB 1981 0302-EST From: CENT at MIT-AI (Pandora B. Berman) Subject: bitten again To: (BUG MAIL) at MIT-AI, (BUG ITS) at MIT-AI comsat decided to take another walk over my mail file. today i logged in and typed :rmail, and found myself looking at a message sent to alan and bee. neither of whom i am. this was somewhat disconcerting, so i quit out of the rmail and poked around a bit. by now the rmail had obligingly copied the contents of my mail file into my rmail file and had deleted the mail file, so there was no way of finding out information about it. i have copied the entire bunch of new mail (everything before the first message that i know i have seen in rmail before; i use r-option append and gmsgs so the break was pretty clearly after the newest system msg) to the file ai:vsdb;foo2 mail. i also looked at this stuff: i am sure that the first seven msgs are not for me, and that the eighth (which starts with gubbish and turns into a news digest) probably is. evidence of when i was last seen by the system is a file i wrote the last time i was logged in (i know i read my mail that time); the file was written at 03:38 on 2/1, and i logged out within a few hours of that. the time of the first msg that is probably mine AND has a readable time is 13:35 on 2/1. this is the ninth msg in foo2 mail; the eighth msg (the news digest with gubbish at the front) does not have a readable time. the news digest canonically comes out at 10:00 PST which means 13:00 EST, but the ostats file has been written to disk 15 (third:) which is currently unaccesssible due to dead disk drive, so i can't tell exactly when it came out on sunday or what msgs i got earlier that morning. however, given the several hours between these times, i think that comsat (or something) walked over the first several msgs sent to me sunday morning and replaced them with the random stuff that is now the first seven msgs in foo2 mail. dave moon says that since i logged out sunday morning ai has had problems (disk drive losing causing locked blocks all over, and hic's memory losing in some way (he wasn't sure of the details when he mentioned this) causing programs to act in very random ways) either of which could have caused the lossage i experienced here. i guess i will have to wait until the third: pack comes back online before i can see what i missed; i may not be able to get the stuff i lost back because of the time delay here.  Date: 2 February 1981 21:59-EST From: Ed Schwalenberg To: GNU at MIT-AI cc: BUG-ITS at MIT-AI What is the effect of linking to a free STY (i.e. Finger shows it as "STY not in use")? I saw someone doing it earlier tonight and wondered. It depends on the state of the STY. If you just link to an unused sty, you get a ?, since the tty you want to link to does not exist. What must have happened is that the sty became unused after the link existed, as for instance if someone logs out from a sty and you link to him just before or after the logout (but before the net connection is closed. I believe that the system doesn't really do anything with stys whose only activity is a link, and they will vanish, breaking the link.  Date: 2 FEB 1981 0401-EST From: GNU at MIT-AI (John C. Gilmore) To: (BUG ITS) at MIT-AI What is the effect of linking to a free STY (i.e. Finger shows it as "STY not in use")? I saw someone doing it earlier tonight and wondered.  Date: 29 January 1981 18:44-EST From: Earl A. Killian Subject: Page ahead To: Guy.Steele at CMU-10A cc: BUG-its at MIT-AI, klh at MIT-AI Actually the documentation only existed on AI, not on the other machines. I've installed it elsewhere.  Date: 29 January 1981 1658-EST (Thursday) From: Guy.Steele at CMU-10A To: klh at MIT-AI Subject: Page ahead CC: bug-its at MIT-AI Message-Id: <29Jan81 165842 GS70@CMU-10A> I did some detective work. Get onto an ITS and try :DOC USET PAGRAN and :DOC USET PAGAHD  Date: 29 JAN 1981 1612-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: page ahead To: (BUG ITS) at MIT-AI Did I miss something? I have no idea what people are talking about with respect to "page ahead". Is that something like disk file read-ahead in that if you reference a page, the next sequential page is also swapped in?  Date: 29 January 1981 02:43-EST From: Earl A. Killian To: RMS at MIT-AI cc: BUG-ITS at MIT-AI When you first started hacking page ahead code in TECO/ITS I did a quick calculation that showed that it would be a noticable improvement on AI, but not so noticable on MC, because MC can search a page faster. I was moderately surprized at that result. Anyway, glad to hear it really wins. Of course, HIC's new memory may help a lot too...  Date: 28 JAN 1981 2159-EST From: RMS at MIT-AI (Richard M. Stallman) To: (BUG ITS) at MIT-AI Page ahead is a big improvement! On a lightely loaded system, moving the gap in TECO is about twice as fast. When there gets to be more load, it slows down, but the TECO, which was 165k with one 100k file, never even had 50 pages in at any time during moving the buffer from one end to the other.  Date: 28 JAN 1981 0634-EST From: RMS at MIT-AI (Richard M. Stallman) To: SPC at MIT-AI, CENT at MIT-AI, RWK at MIT-MC CC: (BUG ITS) at MIT-AI When SPC told me he was working on a :S program, I told him that there was already a :S. But then I looked for it and didn't find any. So I figured that the link had got lost somehow and nobody had missed it, so I told SPC it was ok to put in a new one. I don't know when or how the old :S went away. CENT, do you remember when you last used it? I used to use it but got out of the habit a long time ago.  Date: 28 January 1981 05:49-EST From: Robert W. Kerns To: SPC at MIT-MC, CENT at MIT-AI cc: RMS at MIT-AI, BUG-ITS at MIT-AI, BUG-DDT at MIT-AI Date: 27 January 1981 23:24-EST From: Pandora B. Berman To: RMS at MIT-AI cc: BUG-ITS at MIT-AI, BUG-DDT at MIT-AI what did you do to :s? when i tried to use it to send a msg to more than one person (using :s because :send only takes one recipient) it kept saying No message? :KILL This is most frustrating; a standard thing like this should not change so suddenly/incompatibly/without warning so that when a user expects it to act as it always has, it breaks incomprehensibly instead. please explain and fix. This was not RMS, this was SPC. I have deleted the offending program and restored the link to QSEND. *** SPC DO NOT DO THIS! ***. Replacing public programs with your own version is not at all polite. If this happened because you did not look before you put it on SYS3;, you should be aware that you *MUST* check for the name being in use on any of SYS, SYS1, SYS2, and SYS3. Please excersize more restraint and caution in the future.  Date: 27 JAN 1981 2324-EST From: CENT at MIT-AI (Pandora B. Berman) To: RMS at MIT-AI CC: (BUG ITS) at MIT-AI, (BUG DDT) at MIT-AI what did you do to :s? when i tried to use it to send a msg to more than one person (using :s because :send only takes one recipient) it kept saying No message? :KILL this is most frustrating; a standard thing like this should not change so suddenly/incompatibly/without warning so that when a user expects it to act as it always has, it breaks incomprehensibly instead. please explain and fix.  Date: 27 JAN 1981 2020-EST From: EB at MIT-AI (Edward Barton) Subject: SAUTH bug To: INFO-MLDEV at MIT-AI CC: EB at MIT-AI I have been playing around with MLDEV for a while, trying to figure out why it so often hangs up while the DDT :COPY command is trying to do a SAUTH call. If anyone thinks the following fix is wrong, please explain and delete it. If anyone knowledgeable thinks it is right, please assemble and install it. It seems not to hang, and to otherwise work, in my tests. AI SYSENG FREE BLOCKS #1=91 #2=53 #14=116 #4=78 #5=101 #13=355 #15=298 #3=95 2 MLDEV 61 6 +919 6/09/80 03:28:23 (1/12/81) RMS 5 MLDEV 62 7 +86 1/12/81 19:41:51 (1/22/81) USERS1 4 MLDEV 63 7 +139 1/22/81 00:51:45 (1/27/81) MOON 4 MLDEV 64 7 +143 ! 1/27/81 20:08:40 (1/27/81) EB ;COMPARISON OF DSK:SYSENG;MLDEV 63 AND DSK:SYSENG;MLDEV 64 ;OPTIONS ARE /3 **** FILE DSK:SYSENG;MLDEV 63, 17-39 (30351) SKIPE CALING ;AND IF USER IS STILL WAITING FOR RETURN FROM SYSTEM CALL SOSLE CALACK ;AND THIS REPLY IS TO HIS CURRENT ATTEMPT, NOT A PREVIOUS, JRST GOLOOP **** FILE DSK:SYSENG;MLDEV 64, 17-39 (30351) SOSG CALACK ; NOTE THE ACKNOWLEDGE AND SKIP IF NOT CURRENT YET SKIPN CALING ; CURRENT; SKIP IF USER IS WAITING JRST GOLOOP ; NOT CURRENT YET, KEEP WAITING; OR DON'T WANT IT ***************  GJC@MIT-MC 01/26/81 00:13:28 To: (BUG ITS) at MIT-MC Does anybody know about this ARGUS frob, SYS2;TS ARGUS on MC? Seems innocent enough, but it takes up incredible amounts of resources for a trivial program, was getting like 33% to 44% of MC for quite some time before I killed it. Sounds kind of buggy. I noticed it because it was being run by a lot of turists, that kind of thing usually is.  Date: 24 JAN 1981 1507-EST From: abrax at MIT-AI (Jeff Shrager) Sent-by: ___035 at MIT-AI Subject: Rubout to first char fails in DDT mode To: (BUG ITS) at MIT-AI If you forget the ":" to issue a real command and use rubout to get back to the beginning of the line and insert it, ITS forgets that there is a ":". Looks like someone's crufty code looks for the ":" ONLY on entry of the first character rather than at the beginning of the line entered after all of it comes in.  KMP@MIT-MC 01/21/81 23:55:20 To: (BUG ITS) at MIT-MC The system just hung for about a minute or so without accessing the disk. Now I did a peek about 5 seconds after it started letting me get to disk and there were only about 13 disk channels taken. Unless a lot were closed in a very short time, I wonder if the problem is really disk channels all used up or something else...  Date: 20 January 1981 16:31-EST From: George J. Carrette To: MOON at MIT-MC cc: BUG-ITS at MIT-MC, JM at MIT-MC, JPG at MIT-MC I know you need specific info about the state the running jobs where in. What I'll do is set up some example runs, and make sure the behavior is repeatable, and catch you sometime system conditions are right for a demo. -gjc  MOON@MIT-MC 01/20/81 15:48:24 Re: Terminal in 812 To: jerryb at MIT-AI CC: (BUG ITS) at MIT-AI, beppe at MIT-AI Date: 19 JAN 1981 1514-EST From: jerryb at MIT-AI (Gerald R. Barber) Sent-by: BEPPE at MIT-AI To: (BUG ITS) at MIT-AI ITS doesn't seem to be listening to the terminal in 812. The AI ITS nnnn CONSOLE 36 ... message is coming through alright but the system doesn't respond to ^Z. The system believes that Teleray has a meta key. Evidently the parity control switches in the back are not set correctly, such that c-Z sends c-m-Z. You want 8-bit characters, no parity, 1 stop bit.  MOON@MIT-MC 01/20/81 15:26:48 To: JPG at MIT-MC CC: (BUG ITS) at MIT-MC, GJC at MIT-MC, JM at MIT-MC JPG@MIT-MC 01/20/81 07:36:49 To: (BUG ITS) at MIT-MC CC: GJC at MIT-MC, JM at MIT-MC Forwarded for GJC: GJC@MIT-MC 01/19/81 20:09:53 To: JPG at MIT-MC, JM at MIT-MC foo, its worse now than ever. BALCH's two dissowned macsyma jobs are still running hours later, its 8:00pm, and the fair-share is 3%. But, somehow his jobs get a total of 60% share, plus all the physical memory they need, almost a Moby unshared. How come these CPU-intensive memory-intensive dissowned jobs don't get swapped out? It should be something like active-for 1 minute, inactive for 4 minutes. Were these jobs running in a system call or in user mode? Were they taking page faults? Were they getting some sort of interrupts such as pdl overflow? Were you able to reown them and stop them with the DDT control-X command? Without some specific information there is nothing I can do.  JPG@MIT-MC 01/20/81 07:36:49 To: (BUG ITS) at MIT-MC CC: GJC at MIT-MC, JM at MIT-MC Forwarded for GJC: GJC@MIT-MC 01/19/81 20:09:53 To: JPG at MIT-MC, JM at MIT-MC foo, its worse now than ever. BALCH's two dissowned macsyma jobs are still running hours later, its 8:00pm, and the fair-share is 3%. But, somehow his jobs get a total of 60% share, plus all the physical memory they need, almost a Moby unshared. How come these CPU-intensive memory-intensive dissowned jobs don't get swapped out? It should be something like active-for 1 minute, inactive for 4 minutes.  Date: 19 JAN 1981 1514-EST From: jerryb at MIT-AI (Gerald R. Barber) Sent-by: BEPPE at MIT-AI To: (BUG ITS) at MIT-AI ITS doesn't seem to be listening to the terminal in 812. The AI ITS nnnn CONSOLE 36 ... message is coming through alright but the system doesn't respond to ^Z.  Date: 19 JAN 1981 0249-EST From: MOON at MIT-AI (David A. Moon) To: (BUG ITS) at MIT-AI CHANNA;RAKASH DMNSTR does not work in the new ITS, I think because it tries to slave from a not logged in sty  Date: 18 January 1981 2332-EST (Sunday) From: Guy.Steele at CMU-10A To: gnu at MIT-ML (Sent by ___022@MIT-ML) Subject: Transcribing COM links CC: bug-its at MIT-ML In-Reply-To: gnu@MIT-ML's message of 18 Jan 81 02:53-EST Message-Id: <18Jan81 233212 GS70@CMU-10A> Presumably one could write a cross between FIDO and the SPY feature of LOCK as follows: have a program that runs as a demon (so it wakes up when the system is brought up). Once every couple of seconds it wakes up and scans the system TTY tables for COM links much as PEEK might. (Or JEDGAR -- this hack involves bits of sixteen other programs!) When one is found, then it uses the SPY device to gobble the characters and appenbd them to a file. If you're hairy enough you can transcribe several at once. This is not an offer to write the hack -- I have no time. I'm just outlining the technical possibilities. I will, however, remark that there may be a difference of kind rather than degree between random spying on other terminals and systematic transcription of people's conversations. It probably should not be done without at least a system message (which you see whenever you log in) to the effect that such monitoring is in progress. --Guy  FREND@MIT-ML 01/18/81 17:39:53 To: (BUG ITS) at MIT-ML I just logged in from the net, and before my login init was thru, I got a message from system overseer saying I did not look like an authorized user. there are about 8 people on now, half are tourists. I think this is a bug because if PWORD let me in at this time, the overseer program should not say he doesn't recognize me. Anyway, i will leave as soon as I ^C this message michael bloom  Date: 18 JAN 1981 1530-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: Spying on com-links To: gnu at MIT-ML CC: (BUG ITS) at MIT-AI Tell your friend to ask the UC Berkeley Comp Sci dept. Their UNIX systems have a talk program which, while a feeble imitation of ITS com links (eg no multiple party links), is much easier to modify for scripting, because it is a user program rather than part of the operating system. I suspect the patterns will be different (more sophomoric dialogue, owing to thousands of freshlings) but why not take advantage of a home-grown resource...  gnu@MIT-ML (Sent by ___022@MIT-ML) 01/18/81 02:53:56 To: (BUG ITS) at MIT-ML CC: GNU at MIT-ML A friend of mine would like to do a study of language pattern in com-links as a project for her class in Spoken/Written language differences. (She views com-links as a cross between the two.) Is there any easy way to have ITS record com-links somewhere for a week or two? The person doing the study is Nancy Levidow, a grad student in linguistics at UC Berkeley. (I'm assuming there are no privacy problems with this, as any comlink could be spied upon; just technical problems.) Easiest way to respond is via GNU@MC, since she's not on the net.  Date: 15 January 1981 0110-EST (Thursday) From: Guy.Steele at CMU-10A To: moon at MIT-MC Subject: Re: system hanging on disk... CC: eak at MIT-MC, bug-its at MIT-MC, ellen at MIT-MC, kmp at MIT-MC, rlb at MIT-MC In-Reply-To: Earl A. Killian's message of 14 Jan 81 21:09-EST Message-Id: <15Jan81 011000 GS70@CMU-10A> Or you could dynamically allocate disk channels... installing it would be a great new source of bugs. Hasn't been very much activity on the BUG-ITS mailing list lately anyway... --Q  Date: 14 January 1981 21:09-EST From: Earl A. Killian Subject: system hanging on disk... To: MOON at MIT-MC cc: BUG-ITS at MIT-MC, BIL at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC, RLB at MIT-MC Gee, you could implement real resource management, and require that any program that uses more than one disk channel, first say "reserve me N channels", avoiding the deadlock. Just kidding.  Moon@MIT-MC 01/14/81 02:24:39 Re: system hanging on disk... To: ELLEN at MIT-MC CC: KMP at MIT-MC, (BUG ITS) at MIT-MC, RLB at MIT-MC, BIL at MIT-MC CC: JONL at MIT-MC ELLEN@MIT-MC 01/14/81 01:47:41 Re: system hanging on disk... To: KMP at MIT-MC CC: (BUG ITS) at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC CC: ELLEN at MIT-MC I just happened to have a peek today when one of those hangs happened... and by gosh and by golly, there were two full VT52 screens plus a few lines of disk channels in use from a C in peek. I dunno... lots of TeX's and various INQUIRS (nasty Ellen here noting that some of the INQUIR channels were from unlogged lines doing WHOIS or NAME...). Anyway, it probably was running out of disk channels. How many are there? Yes, exhausting the supply of disk channels is the usual cause of this. There are a fairly humongous number I believe. Maybe I should see if ITS can be made to do something useful in this case. (It used to return errors instead of hanging, but someone decided it would be better to hang.) Maybe I can make it return an error after a while, which might encourage killing of jobs. TEX is a gross offender in this respect (so are PUB and COMPLR) in that they open many channels, making a deadlock more likely.  ELLEN@MIT-MC 01/14/81 01:47:41 Re: system hanging on disk... To: KMP at MIT-MC CC: (BUG ITS) at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC CC: ELLEN at MIT-MC I just happened to have a peek today when one of those hangs happened... and by gosh and by golly, there were two full VT52 screens plus a few lines of disk channels in use from a C in peek. I dunno... lots of TeX's and various INQUIRS (nasty Ellen here noting that some of the INQUIR channels were from unlogged lines doing WHOIS or NAME...). Anyway, it probably was running out of disk channels. How many are there?  KMP@MIT-MC 01/13/81 00:17:15 To: (BUG ITS) at MIT-MC CC: KMP at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC CC: ELLEN at MIT-MC There has been a very high incidence rate of jobs hanging for a long time (rlb: `several tens of seconds') waiting to do i/o to the disk. Is it possible that this is due to an ITS bug or is it more likely to be people using up all the disk channels/buffers/?? If it's possible that it's the former, could someone look into it? It's extremely irritating and has almost caused us to reload the system unnecessarily a couple times because disk i/o was unavailable for so long (one or two times ITS just started working again just as we were about to reload it; these were several-minute pauses) ... -kmp  Date: 12 Jan 1981 2042-EST From: EBM at MIT-XX Subject: Slight protocol change, and new MLDEV/MLSLV installed To: info-mldev at MIT-AI The MLSLV protocol has been upgraded in response to some catastrophes that occurred on DM about 6 weeks ago. Specifically, a number of files on SYS directories were deleted using MLSLV, and because of the way the protocol is constructed, there was no way to track down the culprit, even thought the usual console message were written. MLSLV has been extended by the addition of a LOGIN command and reply code. Logging in is REQUIRED only for deletion of files, but for simplicity and friendliness, MLDEV starts a login (but does not wait for the response) almost immediately. This should not particularly slow down the protocol. Instead of logging in as hhhJuu (host and user) MLSLV, it now logs in as XUNAME (of the foreign user) MLSLV, with a "terminal name" of hhhJuu. It should still be easy to match up jobs, connections, etc., via PEEK, and much easier to identify who is doing what. If it is deemed necessary to de-install the new MLSLV and MLDEV, it was installed using links: On each site, SYS;ATSIGN MLDEV is a link to SYS;ATSIGN NMLDEV, and SYS;ATSIGN OMLDEV is the old MLDEV. MLSLV is organized the same way, but lives in DEVICE; Bugs can be sent to me. Although this change is slightly incompatible, it should not prove to be a real problem for users, or for upgrading of other programs using the protocol. -------  Date: 12 January 1981 1412-EST (Monday) From: Guy.Steele at CMU-10A To: bug-its at MIT-MC Subject: File name > > CC: kmp at MIT-MC In-Reply-To: KMP@MIT-MC's message of 11 Jan 81 23:09-EST Message-Id: <12Jan81 141206 GS70@CMU-10A> Actually, I thought you weresupposed to get some kind of open error message like "bad file name" if both FN1 and FN2 were one of > or <.  KMP@MIT-MC 01/11/81 23:09:58 To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC :COPY TTY:,DSK:KMP;> > Hi.^M^J^C created a file called _COPY_ OUTPUT on my dir with `hi' in it ... While this *is* the greatest file of the last type in my dir, I should think there are more aesthetic filenames it could have chosen.  BARRYG@MIT-MC 01/09/81 20:26:19 Re: strange interaction between RMAIL and TCTYP GLASS To: (BUG RMAIL) at MIT-MC CC: (BUG ITS) at MIT-MC I normally run under TCTYP GLASS SCRL 22 (See MC: GUEST0; BARRYG LOGIN) and most programs (INFO, PRINT, MSGS, MAIL) that I use get along well with that. When using RMAIL, however, when the screen fills I get **MORE** (instead of --MORE-- as with other programs). No matter WHAT character is then typed, RMAIL prints out the rest of the message (again printing out **MORE** approximately every screenful but not pausing for input). I haven't tested this in EMACS, so I can't tell if the problem is general with EMACS or specific to ^R RMAIL. If you need help with this, I'll try a few things under EMACS to try isolating it. This is a minor bug (so far), but since we tourists are supposedly here for the purpose of testing programs, I present this bug for your delectation. barry gold  Date: 8 Jan 1981 1305-EST From: PDL at MIT-DMS (P. David Lebling) To: BERN at MIT-ML Cc: (BUG ITS) at MIT-ML In-reply-to: Message of 08 Jan 81 at 1211 EST by BERN@MIT-ML Message-id: <[MIT-DMS].178600> The author is stored as the directory number, which is why you see USERS1. Unfortunately, there isn't room in the directory entry for the full name.  BERN@MIT-ML 01/08/81 12:11:18 To: (BUG ITS) at MIT-ML Now that passwords are implemented on most machines, it is more appropriate when a file is created, written, or linked, that the author be the uname rather than the sname (or whatever it currently is). It is hard to find out who wrote in a file when the author name is USERS1 for example.  BARRYG@MIT-MC 12/23/80 21:12:57 To: (BUG ITS) at MIT-MC I would appreciate it if someone would, at your leisure, restore MC:GUEST0;BARRYG XMAIL from whatever backups are maintained. /barry  Date: 22 December 1980 11:55-EST From: Robert W. Kerns To: KMP at MIT-MC cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, MLK at MIT-MC, USER-ACCOUNTS at MIT-MC, USER-ACCOUNTS at MIT-AI Date: 22 December 1980 00:00-EST From: Kent M. Pitman To: RWK at MIT-MC, BUG-ITS at MIT-MC, USER-ACCOUNTS at MIT-MC cc: MLK at MIT-MC, ELLEN at MIT-MC Date: 21 December 1980 09:17-EST From: Michael L. Kazar To: USER-ACCOUNTS Some twerp just enslaved my terminal and $$U'ed me off. It was from a vadic dialup no less! May I suggest that maybe PWORD should not allow enslaves but only links. ?? ----- Would it be hard to set things up so that ^_E was disallowed from PWORD? Unlogged DDTs could also do it if it's easier to check uname than jname. Anyway, some unlogged random slaved a Macsyma user and lost him a lot of work the other day and he was quite upset. If this can't be done, I recommend that for the safety of our paying users, initiating links from unlogged pwords should be made impossible. This is, however, a more extreme measure than I would like to take if we can help it, though. Thanks. -kmp This has also happened several times recently on ML, and ML's PWORD is currently patched to disallow initiating links. But better than this would be to have ^_E not work on a not-logged-in dialup or STY (leaving local TTY's alone). This is a simple change to ITS, and minimizes the restrictions imposed to achieve the goal. If there are no objections I'm willing to do the (trivial) work.  Date: 22 December 1980 00:00-EST From: Kent M. Pitman To: RWK at MIT-MC, BUG-ITS at MIT-MC, USER-ACCOUNTS at MIT-MC cc: MLK at MIT-MC, ELLEN at MIT-MC Date: 21 December 1980 09:17-EST From: Michael L. Kazar To: USER-ACCOUNTS Some twerp just enslaved my terminal and $$U'ed me off. It was from a vadic dialup no less! May I suggest that maybe PWORD should not allow enslaves but only links. ?? ----- Would it be hard to set things up so that ^_E was disallowed from PWORD? Unlogged DDTs could also do it if it's easier to check uname than jname. Anyway, some unlogged random slaved a Macsyma user and lost him a lot of work the other day and he was quite upset. If this can't be done, I recommend that for the safety of our paying users, initiating links from unlogged pwords should be made impossible. This is, however, a more extreme measure than I would like to take if we can help it, though. Thanks. -kmp  GJC@MIT-MC 12/19/80 02:21:05 To: (BUG ITS) at MIT-MC CC: ELLEN at MIT-MC I'm not sure exactly who to complain to on this, I've complained about the bugginess of H19WHO many times before. Anyway, there is a DSN's tree with a running H19WHO on it now on MC which has used up 2 hours of CPU time. I've just :ujob jmsk hactro and :snarfed the job, and it significantly improves the fair share. This problem comes up very often when a user with an h19who gets detached. As soon as I reowned the tree the h19who typed out on my tty and stopped burning up cpu time. When ^X'd it was doing a .HANG ...now, how is it that you save jobs for examination??  Date: 19 December 1980 01:06-EST From: Frank J. Wancho Subject: Access to AI via DARCOM PTIP To: BUG-ITS at MIT-AI cc: FJW at MIT-MC, ELLEN at MIT-MC Attempts to connect to AI from the DARCOM-PTIP are met with "ITS being Debugged" when, in fact, it is not. I understand that the same message is sent when attempting to connect from other TIPs in the D.C. area. If you are trying to block randoms and are having trouble specifically with DARCOM-PTIP users, I would like to have the details so corrective action can be taken and the block can be removed. If not, then please remove the block. Thanks, Frank  Moon@MIT-MC (Sent by Moon at CADR16@MIT-MC) 12/16/80 22:35:23 To: CWH at MIT-MC CC: (BUG ITS) at MIT-MC CWH@MIT-MC 12/16/80 19:57:53 To: (BUG ITS) at MIT-MC If the userid contains a numeric digit as a character in the middle of the name, only the alphabetic characters preceding the digit are looked at when setting the file author. For instance, if a file is created by uname K7X, the file author is shown to be K. This sounds unlikely. File authors are stored as the disk address of the user's home directory. No name parsing is involved. (The reason they are stored this peculiar way is because whoever put them in couldn't find enough bits to store a sixbit name.)  CWH@MIT-MC 12/16/80 19:57:53 To: (BUG ITS) at MIT-MC If the userid contains a numeric digit as a character in the middle of the name, only the alphabetic characters preceding the digit are looked at when setting the file author. For instance, if a file is created by uname K7X, the file author is shown to be K.  GJC@MIT-MC 12/12/80 19:53:21 To: (BUG ITS) at MIT-MC MC appears to be crashing somewhat harder than I've ever seen an ITS system do. I have had files written out, e.g. GJC;FOO 1 a few minutes ago, and even compiled, so I *know* is was there, and then MC crashes, and when I get back 5 minutes later the file is *gone*. ouch.  Date: 11 DEC 1980 1935-EST From: JLK at MIT-AI (John L. Kulp) To: (BUG ITS) at MIT-AI MLDEV SEEMS TO BE TRUNCATING FILES. I JUST DID :COPY ON MC OF MC:DATDRW;WL BIN TO AI: AND THE FILE ON AI WAS NICELY ROUNDED OFF TO EXACTLY 72 BLOCKS (THE ACTUAL FILE IS 72 AND 709 WORDS).  RWK@MIT-MC 12/08/80 19:44:05 Re: CORBLK: NO CORE AVAILABLE To: RAM at MIT-MC CC: (BUG ITS) at MIT-MC That means there is no more virtual memory left in the system. I.e. there are too many people using the system to get anything done. The best thing to do is to go away for a while. Baring that, you can always just $P it again. When there is enough core, it will continue where it was. It may take a while, the easiest way to get some core freed up is to log out. There's lots of other people trying to get to any newly freed core before you.  RAM@MIT-MC 12/08/80 18:47:05 To: (BUG ITS) at MIT-MC running nbabyl i got: ERROR CORBLK: NO CORE AVAILABLE 15243>>.CALL 37607 (CORBLK)  Date: 6 December 1980 21:41-EST From: Robert W. Kerns Subject: File Authors To: JONL at MIT-MC cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC, BUG-EMACS at MIT-MC Date: 6 DEC 1980 0616-EST From: JONL at MIT-MC (Jon L White) To: (BUG ITS) at MIT-MC cc: RWK at MIT-MC, (BUG DDT) at MIT-MC Re: File Authors :MOVE , fails to preserve the file's author field. Not true! You're being confused by EMACS's DIRED, which displays the bug.  JONL@MIT-MC 12/06/80 06:16:49 Re: File Authors To: (BUG ITS) at MIT-MC CC: RWK at MIT-MC, (BUG DDT) at MIT-MC :MOVE , fails to preserve the file's author field.  REM@MIT-AI (Sent by ___010@MIT-AI) 12/04/80 20:16:16 To: (BUG ITS) at MIT-MC Gee, MC hasn't been very reliable lately, crashed again now...  Date: 26 NOV 1980 1255-EST From: CL at MIT-MC (Charles C. Linton) Sent-by: CL0 at MIT-MC Subject: T36 To: (BUG ITS) at MIT-MC CC: LPH at MIT-MC, (BUG R11) at MIT-MC The default TCTYP for T36 appears to have changed to a software imlac. (SIMLAC) It should be set for a standard telaray (T1061) at 9600 baud. Also, when I attempted to set it back to teleray from another console, the TCTYP program apparently wedged. i.e. it never returned. After killing the TCTYP program and examining the bits I found that %tpcbs was set. I cleared it using the :tctyp program. Then I again tried :tctyp t1061 and everything worked fine.  Date: 17 NOV 1980 1331-EST From: RICH at MIT-AI (Charles Rich) To: (BUG ITS) at MIT-AI How about allocating the CRASH; directory to SECOND: or THIRD:.  Date: 13 Nov 1980 1234-EST From: PDL at MIT-DMS (P. David Lebling) To: BUG-ITS at MIT-DMS Subject: BUG => ITS Message-id: <[MIT-DMS].168838> Lately DM has been getting a lot of parity errors that do not cause the system to stop even though parity stop is on. It prints: PARITY ERROR #N PC=FOO,,BAR HH:MM:SS DM ITS Revived! hh:mm:ss The parity stop switch is, of course, on. These errors don't seem to get stuffed in the PARADR buffer or get an IOR/AOR printed out, or anything. Is this supposed to be a feature? Or is it a bug, or is our parity stop switch not working? Dave  Date: 12 NOV 1980 0238-EST From: ECC at MIT-AI (Eugene C. Ciccarelli) Subject: T15 modem To: (BUG ITS) at MIT-AI For several days now, I have not been able to use the 258-6700 at all, but have been able to use 258-6701. Though I can connect to it ok, none of the characters seem to get through. Are others able to use it?  Date: 5 November 1980 13:58-EST From: Robert W. Kerns To: BUG-ITS at MIT-MC cc: ELLEN at MIT-MC Kruczynski, Len of USAFA-GATEWAY called. It seems that he can't connect to MC. He CAN connect to AI, XX, Multics, etc. However, when trying to go from MC to USAFA-GATEWAY via TELNET MC gets a RST TIMEOUT message printed on the system console (host=31001 = USAFA-GATEWAY). TELNET works fine from AI. His system maintainer may try to contact Moon.  GYRO@MIT-ML 11/04/80 23:08:52 To: (BUG its) at MIT-AI An AI crash a few minutes ago was simultaneous with a comm link that I opened (I mean a ^_c... in case "comm link" is somehow ambiguous?) being closed (^_n) by the other person. I don't know if it's really relevant but the coincidence was remarkable. Oh yes, I was in the middle of a :send when I started the link. -- Gyro -------  Date: Monday, 3 November 1980 12:40-EST From: Chris Ryland To: bug-r11 at mc, bug-its at mc Subject: buffer hogging It seems to me (from my travels with ESC V) that the Plasma TV system often lets buffers sit unused after people log out from MC; MC takes quite a while to close the connection, and even after that, Plasma takes a while to free the buffer. Both of these should be shortened, so that logging out---without logging back in nearly immediately---frees up the buffer.  Date: 27 October 1980 19:14-EDT From: Earl A. Killian Subject: Temporary files To: MOON at MIT-MC cc: BUG-ITS at MIT-MC, GJC at MIT-MC, RWK at MIT-MC Couldn't you also open the file, and then delete it. When you close the file, or when it is closed for you by killing the job, then it will be deleted by the system.  RWK@MIT-MC (Sent by ___011@MIT-MC) 10/26/80 06:09:56 Re: I replied to CSTACY To: (BUG ITS) at MIT-MC [Translating all devices to AI: including USR: and ERR:]  CSTACY@MIT-MC 10/26/80 00:19:09 To: (BUG ITS) at MIT-MC On MC, do: $^T foo,ai:foo; foo^F FILE.DIR. etc -- CANT READ SYSTEM'S ERROR MESSAGE bar^K INFERIOR-CREATION FAILED Chris ------  MOON@MIT-MC 10/24/80 20:35:22 Re: Temporary files To: GJC at MIT-MC CC: RWK at MIT-MC, (BUG ITS) at MIT-MC If you read the file .INFO.; ITS LOCKS it will tell you about features for creating unique IDs and having locks that get unlocked when a job is killed. Of course there is no way to run arbitrary code when a job is killed; that could easily make it impossible to kill. It's easy to tell whether a given job "points to" a file, if you include that job's job-number in the name of the file. You simply have one file per job-number, recreated when a job starts up. If you want to delete "left over" files in some cleanup procedure, simply check to see if the job has the name of that file in a fixed place in its memory (or we could allocate a new .OPTION bit or use the dragon's way of telling whether a job is a Macsyma).  Date: 24 October 1980 13:20-EDT From: George J. Carrette Subject: new error message system To: RWK at MIT-MC, BUG-ITS at MIT-MC Date: 24 October 1980 11:36-EDT From: Robert W. Kerns To: GJC Re: new error message system Files that want to be sure to go away when a process is killed can be written to .TEMP.; I've seen files on the so-called .TEMP. directory end up on back-up tape! Look, theres one now on MC:.TEMP.;LPH .PLOT. Each and every macsyma which starts up will probably create a new file on the .TEMP. directory, and these will have to be garbage collected better than they are now. The problem is, how can a clean-up program tell if any existing macsyma jobs point to one of the files? Well, I guess AGE greater than 8 hours is a reasonable heuristic. Does ITS have any thing which could give a UNIQUE process ID over the time between crashes? Is there any provision in ITS for letting a process take an interrupt when something tries to KILL it? It could then delete the file(s) and kill itself.  Date: 22 OCT 1980 2331-EDT From: EFH at MIT-AI (Edward F. Hardebeck) To: (BUG ITS) at MIT-AI the name dragon got a PURPG (PURPG;) 1371>>MOVEM 2,(3) 2/ MOVEI 20100(4) 63336/ 0 it is dumped on crash;namdrg >  Date: 20 October 1980 02:03-EDT From: Robert W. Kerns Subject: FOOO$U doing a :MASSACRE To: JNC at MIT-AI cc: BUG-ITS at MIT-MC Date: 17 October 1980 02:20-EDT From: J. Noel Chiappa To: RWK cc: JNC at MIT-AI Re: FOOO$U doing a :MASSACRE Barf! This has actively wedged me. What's the ratyionale, can it be changed, and if not, how do I avoid lossage (other than detaching all my jobs?) Noel The reason is that logging in on ITS is not permitted (by ITS) if a job has inferiors. One way to avoid lossage is to log in before doing anything. Of course, I think a better thing to do would be to allow logging in with inferior jobs. Since this is already done when a job is reowned, I wouldn't think this would be very hard to do... l  MOON@MIT-MC 10/19/80 04:18:06 Re: SPURIOUS CHARACTERS To: CENT at MIT-AI CC: TC at MIT-AI, RG at MIT-AI, (BUG ITS) at MIT-AI Date: 19 OCT 1980 0409-EDT From: CENT at MIT-AI (Pandora B. Berman) Subject: SPURIOUS CHARACTERS To: TC at MIT-AI, MOON at MIT-AI, RG at MIT-AI CC: (BUG ITS) at MIT-AI THE DATAPOINT IN LAUREL'S OFFICE (917) SEEMS TO OCCASIONALLY SEND SPURIOUS AND UNCALLED-FOR  ^H'S. I HAVE SEEN THIS HAPPEN A FEW TIMES AFTER RUNNING :F; THE OUTPUT FROM :F WOULD PRINT OUT FOLLOWED BY A ^H AND GOING BACK INTO WHATEVER JOB IS CURRENT. I HAVE NOT SEEN THIS BEHAVIOR CONNECTED WITH ANYTHING ELSE. I DON'T KNOW WHETHER THIS IS A HARDWARE OR SOFTWARE BUG. CAN SOMEONE LOOK INTO IT? It's a hardware bug, fixable by throwing the datapoint in the trash. They have really crappy keyboards.  Date: 19 OCT 1980 0409-EDT From: CENT at MIT-AI (Pandora B. Berman) Subject: SPURIOUS CHARACTERS To: TC at MIT-AI, MOON at MIT-AI, RG at MIT-AI CC: (BUG ITS) at MIT-AI THE DATAPOINT IN LAUREL'S OFFICE (917) SEEMS TO OCCASIONALLY SEND SPURIOUS AND UNCALLED-FOR  ^H'S. I HAVE SEEN THIS HAPPEN A FEW TIMES AFTER RUNNING :F; THE OUTPUT FROM :F WOULD PRINT OUT FOLLOWED BY A ^H AND GOING BACK INTO WHATEVER JOB IS CURRENT. I HAVE NOT SEEN THIS BEHAVIOR CONNECTED WITH ANYTHING ELSE. I DON'T KNOW WHETHER THIS IS A HARDWARE OR SOFTWARE BUG. CAN SOMEONE LOOK INTO IT?  MOON@MIT-MC 10/17/80 21:30:20 To: DCP at MIT-MC CC: (BUG ITS) at MIT-MC DCP@MIT-MC 10/17/80 16:54:08 To: (BUG ITS) at MIT-MC Symbolic IOT is documented to XOR the control bits of the call with the appropriate channel variable in the system. I am trying to use this with the TTY to change from %TJDIS mode to %TJSIO mode, and I am losing. There is a short program in MC:DCP;TEST > which I think should work from the specs in the documentation. Why am I losing?? It does XOR the control bits. Where the documentation says the LH of the first argument (the channel number) is also XOR'ed in it is lying. Use 5000,,%tjdis+%tjsio and your program will work (this is an immediate control bits arg.)  DCP@MIT-MC 10/17/80 16:54:08 To: (BUG ITS) at MIT-MC Symbolic IOT is documented to XOR the control bits of the call with the appropriate channel variable in the system. I am trying to use this with the TTY to change from %TJDIS mode to %TJSIO mode, and I am losing. There is a short program in MC:DCP;TEST > which I think should work from the specs in the documentation. Why am I losing??  GSB@MIT-ML 10/15/80 05:02:27 To: (BUG COMSAT) at MIT-ML CC: (BUG ITS) at MIT-ML The mailer lost again tonight because the system crashed renaming LISTS MSGS to LISTS MSGT. Either comsat should recognize this condition or ITS shouldn't increment the name unless its necessary.  GJC@MIT-MC 10/04/80 01:19:40 To: (BUG ITS) at MIT-MC, ELLEN at MIT-MC 3-6985 rang but didn't answer, I'm on 3-6986 now and am experiencing incredible line lossage and garbling, (am on a VT52 with a 1200 baud vadic), when recieving at high speed. Probably unrelated, but I thought you@might want to know.  GSB@MIT-ML 09/23/80 07:23:37 Re: ML believes tty 0 to be a teletype To: (BUG ITS) at MIT-ML with -%TOLWR...  Date: 8 SEP 1980 0343-EDT From: U at MIT-AI To: (BUG ITS) at MIT-AI CC: USER-A at MIT-AI, LEVITT at MIT-AI Hello. I am Dave Levitt's music box line. I like to send characters randomly to the AI machine over T33. Guess what I did today! I sent a ^Z and then after a while managed to send "UU" to log myself in. Isn't that marvelous? All I really did after that today was send a lot of "?" characters. I know ALL about DDT and ITS now. But just as I was working on trying to send :LOCK CRASH, some luser took my tree away from me. Now I have to start all over and try to get AI to listen to me again. You see, my buddy the PDP-6 (T06) and I have a little contest going to see who can cause the first system crash by sending garbage down the line. He's ahead of me: a few days ago he managed to get up a peek and type ^B to it. 80 blocks of USERS5;.PEEK. 1. Ahhh, but now I've logged in... Melodiously, U@AI U/klotz  Date: 7 SEP 1980 0217-EDT From: HIC at MIT-AI (Howard I. Cannon) To: (BUG ITS) at MIT-AI I fixed the bug on DM, in both the running monitor and in the BIN file. The bug was a PUSH P,TTEBAK which wanted to be a PUSHJ. --Howard  Date: 7 September 1980 02:04-EDT From: Howard I. Cannon Subject: BUG => its To: PDL at MIT-DMS cc: BUG-its at MIT-DMS Date: 6 Sep 1980 1318-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-its at MIT-DMS Re: BUG => its In case anyone wants to look at it, a crash of ITS 1193 is on DM:.;CRASH 5535. It crashed at UUOH0+2. I looked at another crash at UUOH0+2. It trapped from PI7 while PUSHJ'ed to the echoin code. It was hacking TTY 0 (I contained MOVE), and 1(p) had IBP B (CRASH 5535 seems identical). Unfortunatly, it did a pretty good job of wiping out its tracks, so I couldn't tell where it came from, but it is pretty clear that it POPJ'ed with the IBP B on the stack (XUUOH contained C, of course).  Date: 6 Sep 1980 1318-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].160451> In case anyone wants to look at it, a crash of ITS 1193 is on DM:.;CRASH 5535. It crashed at UUOH0+2.  Date: 5 Sep 1980 1047-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-its at MIT-DMS Subject: BUG => its Message-id: <[MIT-DMS].160320> The echoin bug is that at TTELP5+10/ TRNN A,xxx should be TRNE A,xxx. I will patch the source accordingly.  Date: 5 Sep 1980 1040-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-ITS at MIT-DMS Subject: BUG => ITS Message-id: <[MIT-DMS].160319> We tried running ITS 1193. It works okay except that ECHOIN seems to echo in the command area after the first character typed. Looking at TS3TTY 258 vs. 255 indicates new code that fools around with that sort of thing. I suspect it's buggy...  Date: 1 September 1980 18:46-EDT From: Robert W. Kerns Subject: The datacomputer is no more! To: KEN at MIT-AI cc: BUG-ITS at MIT-AI The problem is really that the datacomputer was discontinued last March or so. There were system messages about it long in advance. You must have missed seeing them or something. I don't know if there is any way to recover your files, although the fact that you were to connect at all would seem to indicate they are providing some sort of limited service, perhaps to allow recovery in cases such as yours. Perhaps sending a note to someone at CCA will help?  Date: 29 AUG 1980 2336-EDT From: KEN at MIT-AI (Kenneth Kahn) Subject: really a dftp problem but bug-dftp is broken To: (BUG ITS) at MIT-AI I sent the following message and recieved this COMSAT@MIT-AI 08/29/80 22:50:12 Re: Msg of Friday, 29 August 1980 22:50-EDT A copy of your message is being returned, because: "DFTP-HACKERS" at MIT-AI is an unknown recipient. Message not sent. Failed message follows: ------- KEN@MIT-AI 08/29/80 22:50:07 It seems my directory on the data computer has disappeared. When I :dftp I get dftp.guest rather than dftp.its.ken ... Can it be restored or at least long enough for a tape dump of my files? Could my question please be forwarded to whoever is hacking dftp these days?  MOON@MIT-MC 08/29/80 03:50:48 Re: Allocated devices To: ED at MIT-AI CC: RMS at MIT-AI, (BUG ITS) at MIT-AI Date: 28 AUG 1980 0013-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: Allocated devices To: RMS at MIT-AI, (BUG ITS) at MIT-AI Pnn: and Dnn: as devices work unless they have been "allocated" to the SECOND:, THIRD:, VISION: sort of pack. I don't know whether this is alleged to be a feature or a bug; I can't see any good that derives from it. It's because of the way the file system works on DM, which has actual reserved packs. Actually it could be fixed but it's random to use the numbers rather than the names. Slightly more serious is that there is no way (as far as I know) of knowing what allocated devices there are (in particular .GETSYS knows nothing about them) or what the mapping between pack numbers and allocated devices is. The :DSKUSE # command should print this information, but doesn't currently. There is also no way of telling what directories are allocated to what packs for the allocated directory scheme. The :DSKUSE dirname command prints this information.  Date: 28 Aug 1980 1032-EDT From: PDL at MIT-DMS (P. David Lebling) To: ED at MIT-AI Cc: RMS at MIT-AI, (BUG ITS) at MIT-AI In-reply-to: Message of 28 Aug 80 at 0013 EDT by ED@MIT-AI Subject: [Re: Allocated devices] Message-id: <[MIT-DMS].159324> In fact, DSKUSE does almost everything you are asking for; it will tell what packs are allocated, pack each allocated directory is on, and so on. It doesn't know much about the named pack hack, as this is fairly new, but maybe if I find some time... Dave  Date: 28 AUG 1980 0013-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: Allocated devices To: RMS at MIT-AI, (BUG ITS) at MIT-AI Pnn: and Dnn: as devices work unless they have been "allocated" to the SECOND:, THIRD:, VISION: sort of pack. I don't know whether this is alleged to be a feature or a bug; I can't see any good that derives from it. Slightly more serious is that there is no way (as far as I know) of knowing what allocated devices there are (in particular .GETSYS knows nothing about them) or what the mapping between pack numbers and allocated devices is. There is also no way of telling what directories are allocated to what packs for the allocated directory scheme. I don't think that anybody is being actively screwed by this, but it would be tasteful if a program could find out about such things without experimenting or sending mail to Moon.  Date: 27 AUG 1980 0610-EDT From: RMS at MIT-AI (Richard M. Stallman) To: (BUG ITS) at MIT-AI The device name P15: works for reading but gets Device not Available for writing (from :COPY).  Date: 20 Aug 1980 1423-EDT From: TAA at MIT-DMS (Timothy A. Anderson) To: SWG at MIT-DMS Cc: BUG-ITS at MIT-DMS, clr at MIT-DMS In-reply-to: <[MIT-DMS].158301> Subject: [Re: BUG => ITS] Message-id: <[MIT-DMS].158305> If the problem with .BATCH;NBATCH BAD was caused by a disk crash, which seems likely, it (shiver) was never reported by the salvager. Could this happen if the file it's sharing with were deleted before the system crashed? -taa  Date: 20 Aug 1980 1345-EDT From: SWG at MIT-DMS (S. W. Galley) To: BUG-ITS at MIT-DMS Cc: taa at MIT-DMS, clr at MIT-DMS Subject: BUG => ITS Message-id: <[MIT-DMS].158301> The file DM:.BATCH;NBATCH BAD is supposed to have the same contents as DM:.BATCH;NBATCH SAVE, but words 166000-167777 have ASCII text from some other file in them. Could this be from some disk crash since February?  RWK@MIT-MC (Sent by RWK0@MIT-MC) 08/13/80 02:36:25 Re: CNSSET/TCMXV bug To: (BUG ITS) at MIT-MC CC: BDG at MIT-MC When BDG sets his vertical screen size down to 1, ITS crashes at TYOAS7+3 because his cursor position is larger than his screen height. It died when DDT had the TTY, with his DDT at a .CALL CNSGET. It had of course recently done a ^PA. Probably .CALL CNSSET (which he had been playing with in a program of his) should not allow you to set the size below 2 in either dimension... I did not dump this because I wanted to get my buffer back. I hope I got enough info for you to figure out what happened anyway.  RWK@MIT-MC 08/05/80 18:24:53 To: (BUG ITS) at MIT-MC CC: TAFT at MIT-MC Both FINGER and SUPDUP, when going via CHAOS, are saying: ? Internal error - ISE0 There is no problem, when via ARPA  MOON@MIT-MC 08/01/80 21:51:55 Re: rubout problem To: EAK at MIT-MC CC: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC Date: 1 August 1980 19:42-EDT From: Earl A. Killian Subject: rubout problem To: BUG-DDT at MIT-MC, BUG-MAIL at MIT-MC cc: BUG-ITS at MIT-MC Perhaps DDT and other programs should be using ECHOIN to solve the rubout problem (where ABDCD echoes as ABDC instead of ABCD). If the rubout problem is the only reason why :MAIL doesn't use PI echoing, then maybe it should use it too. Unfortunately ECHOIN is rather difficult to use. I designed a scheme which would not require any changes to user programs but I don't have nearly enough time to implement it. The basic idea is that when a non-echoing character is typed the system defers echoing, and re-enables it when the next echoing character is read by the program (in the meantime the program may have typed out, for instance to echo erasure for a rubout). This wouldn't be too hard but the refinement to it is to go ahead and echo additional characters so you can see what you're typing, but if the program types anything out erase that echoage and do it again, which is too hard to do right now. I don't suppose there are any competent volunteers?  Date: 1 August 1980 19:42-EDT From: Earl A. Killian Subject: rubout problem To: BUG-DDT at MIT-MC, BUG-MAIL at MIT-MC cc: BUG-ITS at MIT-MC Perhaps DDT and other programs should be using ECHOIN to solve the rubout problem (where ABDCD echoes as ABDC instead of ABCD). If the rubout problem is the only reason why :MAIL doesn't use PI echoing, then maybe it should use it too.  DLW@MIT-MC 07/29/80 03:52:20 To: (BUG ITS) at MIT-MC 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.  REM@MIT-MC 07/20/80 00:17:16 To: (BUG ITS) at MIT-MC 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.  MOON@MIT-MC 07/10/80 05:12:56 Re: FILLEN on non-disk devices To: ED at MIT-AI, (BUG ITS) at MIT-AI 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.  Date: 10 JUL 1980 0401-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: FILLEN on non-disk devices To: (BUG ITS) at MIT-AI, (BUG MLDEV) at MIT-AI 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.  MOON@MIT-MC 07/06/80 04:34:02 Re: Fair Share and the GAME program To: EJS at MIT-MC CC: (BUG ITS) at MIT-MC, LPH at MIT-MC 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)  Date: 1 July 1980 23:32-EDT From: Earl A. Killian Subject: ITS H19 support To: MRC at MIT-AI cc: BUG-TCTYP at MIT-MC, BUG-ITS at MIT-AI 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.  Date: 1 JUL 1980 2202-EDT From: MRC at MIT-AI (Mark Crispin) Subject: ITS H19 support To: (BUG ITS) at MIT-AI 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.  Date: 1 July 1980 20:51-EDT From: Eric J. Swenson Subject: Fair Share and the GAME program To: MOON at MIT-MC, BUG-ITS at MIT-MC cc: LPH at MIT-MC 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@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  Date: 30 JUN 1980 1451-EDT From: MOON at MIT-MC (David A. Moon) Subject:  is S L O W To: SJK at MIT-MC CC: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC SJK@MIT-MC 06/30/80 00:02:03 Re:  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.  SJK@MIT-MC 06/30/80 00:02:03 Re:  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  MOON@MIT-MC 06/28/80 00:01:09 Re: KMP's halt at TTYI15+15 from :REATTA To: KMP at MIT-MC, (BUG ITS) at MIT-MC, (BUG REATTA) at MIT-MC CC: RLB at MIT-MC, JIM at MIT-MC I have fixed this in the source (TS3TTY). RMS, could you check the change and make sure I didn't break anything?  KMP@MIT-MC 06/27/80 14:09:45 To: (BUG ITS) at MIT-MC, (BUG REATTA) at MIT-MC, KMP at MIT-MC CC: RLB at MIT-MC, JIM at MIT-MC 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  Date: 25 Jun 1980 1749-EDT From: CSTACY at MIT-DMS (Christopher C. Stacy) To: BUG-its at MIT-DMS 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 ----  Date: 27 JUN 1980 1108-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG ITS) at MIT-MC CC: RWK at MIT-MC, (BUG EMACS) at MIT-MC, (BUG BABYL) at MIT-MC 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  Date: 27 JUN 1980 0352-EDT From: RMS at MIT-AI (Richard M. Stallman) To: (BUG DDT) at MIT-AI, (BUG ITS) at MIT-AI 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.  Date: 26 JUN 1980 0116-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG ITS) at MIT-AI 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??  ZRM@MIT-MC 06/25/80 17:59:25 To: (BUG ITS) at MIT-MC Having just fingered mc it occurs to me that listing ctrstys as users is redundant and leads to more confusion than information.  Date: 24 June 1980 20:59-EDT From: Earl A. Killian To: BUG-ITS at MIT-MC Date: 23 Jun 1980 2153-EDT 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@mit-ai or dyer@nbs-10. Thank you very much...  Date: 24 June 1980 20:59-EDT From: Earl A. Killian Subject: not getting software TTY codes To: ZEMON at MIT-DMS cc: BUG-ITS at MIT-MC 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?  Date: 24 JUN 1980 0300-EDT From: EB at MIT-AI (Edward Barton) Subject: CLI device To: (BUG ITS) at MIT-AI CC: EB at MIT-AI 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....  CPR@MIT-MC 06/23/80 08:23:32 To: (BUG ITS) at MIT-MC I got a 'all network ports in use' message as the 10th net tty...seems small.  GNU@MIT-MC 06/19/80 03:34:46 To: (BUG ITS) at MIT-MC 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".  JPG@MIT-MC 06/19/80 02:52:46 To: CMA at MIT-MC CC: ELLEN at MIT-MC, (BUG ITS) at MIT-MC CMA@MIT-MC 06/18/80 14:24:25 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.  JLK@MIT-MC 06/16/80 15:37:00 To: FILE-RETRIEVE at MIT-MC CC: (BUG ITS) at MIT-MC 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.  Date: 11 Jun 1980 1216-EDT From: PDL at MIT-DMS (P. David Lebling) To: BUG-its at MIT-DMS Cc: TAA at MIT-DMS, SWG at MIT-DMS, WJN at MIT-DMS 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  FMRC@MIT-ML 06/09/80 02:44:30 To: (BUG ITS) at MIT-ML 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?  Date: 6 JUN 1980 2327-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: Translations To: CBF at MIT-MC, CSTACY at MIT-MC CC: (BUG ITS) at MIT-AI 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.  ECC@MIT-AI 06/06/80 17:37:29 Re: tip port 5 To: (BUG its) at MIT-ML 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.  CBF@MIT-MC 06/06/80 17:43:32 Re: Translations To: CSTACY at MIT-MC CC: (BUG ITS) at MIT-MC CSTACY@MIT-MC 06/05/80 07:04:03 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? 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.  Date: 6 JUN 1980 0126-EDT From: RMS at MIT-AI (Richard M. Stallman) To: (BUG ITS) at MIT-AI 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.  CSTACY@MIT-MC 06/05/80 07:04:03 To: (BUG ITS) at MIT-MC 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  GJC@MIT-MC 06/02/80 16:23:55 To: (BUG ITS) at MIT-MC 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  JONL@MIT-MC 06/02/80 07:58:58 To: (BUG ITS) at MIT-MC CC: (BUG DDT) at MIT-MC :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.  Date: 30 May 1980 0512-PDT From: Scott J. Kramer Subject: Well... To: bug-pword at MC, bug-its at MC :DDTSYM BYERUN is set non-zero, don't know exactly what. -------  Date: 30 May 1980 0501-PDT From: Scott J. Kramer Subject: PWORD weirdness To: bug-pword at MC, bug-its at MC Wonderful bugs: MC ITS.1191. PWORD.1733. TTY 42 8. Lusers, Fair Share = 64% *$$u MC ITS 1191 Console 42 Free. 07:57:57 MC ITS.1191. PWORD.1733. TTY 42 8. Lusers, Fair Share = 74% *sjk$^A (This person's mail is forwarded to CHNL NOT OPEN Bad file = ^Q : ^Q ; ^Q ^Q *$^A (This person's mail is forwarded to Top level interrupt, tree detached MC ITS 1191 Console 42 Free. 07:58:07 MC ITS.1191. PWORD.1733. TTY 42 8. Lusers, Fair Share = 72% *sjk$^A (This person's mail is forwarded to CHNL NOT OPEN Bad file = ^Q : ^Q ; ^Q ^Q *$$u These are the topics for which HELP can give more info. Type: :HELP for more info on a given topic. ACOUNT LOGIN TCTYP LUSER ITS JCL PRINT LOGOUT SEND NAME SSTATU WHOJ BUG WHO DATE TIME TIMES TIMOON OCTPUS WHOIS HELP MAIL QSEND PRMAIL PRSEND LISTF USERS * *:logout See Ya Later ___035... The plural of spouse is spice. ...and it hangs here. And somehow :DDTSYM BYERUN is set to -1. Rather bizarre... -sjk -------  RWK@MIT-MC 05/29/80 13:16:43 Re: Scheduler observations To: (BUG ITS) at MIT-MC Response to --MORE-- in peek can still take 15 seconds or so (although not usually). It's a lot better, but not perfect. Also, I just gunned down a job with "1000000" interrupt according to PEEK. What is that interrupt? It took about 2 minutes for it to finally go away. In the meantime, it could not be :UJOB'd, its FLSINS was zero, its state in PEEK was *MULTICS, its inferior disappeared at about the 1 minute mark, etc. Also, HIC and I saw a hung tree. A WHOLIN job was hung waiting for output room, which isn't suprising but the HACTRN was hung in USRI. It went away OK when gunned (we were going to lunch, not investigating the system). A lot better than before, but still some quirks.  Date: 29 MAY 1980 0720-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG ITS) at MIT-MC CC: SJK at MIT-MC I'm not certain SJK's suggestion should be done. When I use DIR:, I often use it in more than one mode. However, I'm probably just abnormal. Second opinion?  RWK@MIT-MC 05/29/80 06:16:14 To: (BUG ITS) at MIT-MC FIRST: should be a synonym for writing to a primary pack, for the benifit of allocated directories.  GJC@MIT-MC 05/28/80 14:23:41 To: (BUG ITS) at MIT-MC CC: CL at MIT-MC, JLK at MIT-MC T36 seems to be wedged.  RWK@MIT-MC 05/27/80 15:57:22 Re: Schedualer lossage To: (BUG ITS) at MIT-MC CC: JM at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC Fooi, I sent mail before but it log lost in the crash. Anyway, there definitely IS a problem, but it's not just that performance is bad. There is a screwy interaction at work here between interrupts and I/O and the scheduler. When a job has non-defered pending interrupts, SCHACK does not skip-return, leading to doing a full schedual. I think this relates to the problem, in that only jobs with pending interrupts are scrod. Because they only get run when a full schedual is done, they can be heavily discriminated against under some circumstances. I'm not sure just what those circumstances are, but PEEK is screwed in --MORE-- but not elsewhere. This only happens during heavy load, presumably because the full schedual then happens more often. These observations are based on a lot of poking around, with H19WHO keeping me informed of the state of my current job. 1) EMACS does it's input in a single big SIOT, getting MPV's along the way, which it handles and creates the core. Unfortunately, these interrupts may take a very long time to go off, and it won't be schedualed until they do. 2) PEEK .SLEEP's except during the --MORE-- break, where it waits in an input .IOT ... which never returns, since when you type a space, the %PITYI interrupt is asserted in .PIRQC, but NEVER GOES OFF. If you clear this interrupt, disable %PITYI in .MASK, type the space, it reads the space. Then of course you have to restore the mask, since PEEK reads it's commands at interrupt level. 3) When COMSAT loses, getting schedualed but every minute or so, I've checked, found the pages required in core, at an ordinary BLT or TLNN etc., and with a %PIRLT interrupt that WAS NOT GOING OFF. Eventually the load would drop and it would run. 4) DDT sometimes doesn't get its interrupt when the inferior is ^Z'd, while it's sitting in it's .HANG I also saw a .DTTY take 20 seconds, I don't have any other clues on that. Oddly enough, giving DDT a ^G seems to wake it up when it's hung in that manner. Perhaps the TTY driver manages to frob it in just the right way to make it run again, I don't know. Or maybe it just happened to get schedualed when I typed &^G, but that seems unlikely; why didn't it get schedualed for 15 seconds before that? Anyway, I hope this is enough to track down the problem. The threshold of load before it shows up is fairly high, requiring many runnable jobs. Probably enough to fill SCHBTB or something and just sit there keeping it full.  RWK@MIT-MC 05/27/80 12:00:50 Re: Slowness To: (BUG ITS) at MIT-MC CC: JM at MIT-MC I'm not so sure that the reported slowness of disk I/O is anything other than very heavy disk loading. Looking at the channels listing in peek, we're often in the 20-25 channel range, and it's not uncommon for there to be 15 competitors for one disk drive. Normal is more like 15-20 range, with maybe 8-10 competitors for a drive. Today seems to be more disk intensive than usual for some reason. TY is doing a DUMP. There are several compilers and TEX jobs plus the dover spooler and PFTHMG and ... I've seen the system grind to a halt when there were 25 channels in use before. And indeed, when it drops back down to normal, it doesn't seem grossly slower than usual, although I can't assert it's normal. Under the 25-channel load, I read SYSEN1;DDT > (98 blocks) into an EMACS in 110 seconds, watching with H19WHO updatng every 5 seconds. Only 4 samples out of that period of 22 were in other than +DSKBI. Under conditions of about 18 channels in use the time was 65 seconds with only one sample not in +DSKBI. 65 seconds is not inconsistant with times I've observed before under "similar" load. It has also been observed by many people that the system is much less responsive WRT disk I/O when a dump is being taken. Disclamer: The above observations do not show that the system is performing as well as before. My only assertion is that the data doesn't show it when balanced with the load observed. and the lack of a control case. "Before" data would be necessary to make any reasonable judgements. Further Disclamer: The above does not mean that I think the schedular is working 100% right. There are other clear problems with it. Have yo utried continuing a --MORE-- break in PEEK lately? BTW, ITS doesn't use an elevator algorithm for its disk I/O does it? 110 seconds for 98 pages against say 12 competitors for one disk drive looks to me about right for randomly contending competitors, no? This works out to about 10 seconds for the single user, with having it seek the block, then wait until the next schedual to transfer the block to the user's address space (perform the SIOT) and queue up the next transfer. I.e. about 1/10 second for each pair of seek/xfer and schedual. Maybe elevator algorithm might be worthwhile during the heavier load situations? Also, read-ahead when you encounter an extent of more than one block might help. Maybe we should run the old system sometime in the daytime and take some performance measurements to compare with the current situation?  Date: 27 May 1980 10:32-EDT From: Earl A. Killian Subject: ITS 1188 is slower. To: BUG-ITS at MIT-MC cc: CBF at MIT-MC I agree; reading my large Babyl file into TECO took much much longer just now than it ever has under similar load.  CBF@MIT-MC 05/27/80 09:01:58 Re: ITS 1188 is slower. To: (BUG ITS) at MIT-MC ITS 1186 is slower It seems to take longer to do some things, ie. get into Rmail or Info. Quit starting seems to help. (ie. ^Z $P). This claim is based on response time vs. my past experience at various loads. I havn't tried to do any quantitive measurement.  GLS@MIT-MC 05/26/80 17:35:09 To: (BUG ITS) at MIT-MC See MC:CRASH;HALTPC 5550 for a crash at PC 5550 (see log).  Date: 12 MAY 1980 2214-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: Tabs To: ED at MIT-MC CC: (BUG ITS) at MIT-AI ED@MIT-MC 05/12/80 21:38:18 Re: Tabs This line begins with a tab. However, it echoes and redisplays consistantly with only one blank space at the beginning. This line begins with two tabs. It has 8 blank spaces. It appears to only happen at the beginning of the line. This is on a C100, using :tctyp c100. This appears to be an ITS problem; I cannot make it happen via software-TTY, so it must be C100 specific.  KMP@MIT-MC (Sent by ___131@MIT-MC) 05/10/80 23:39:34 To: (BUG ITS) at MIT-MC The system console stopped typing out at 20:02 tonight. The console 11's lights are locked on ... it looks kinda out of it ... I asked RG who advised not doing anything and just waiting until the system goes down voluntarily, so I'm leaving it be. -kmp  CBF@MIT-MC 05/10/80 21:18:52 Re: strange occurances on T13 (the first Vadic 3467 line) To: ASB at MIT-MC, (BUG ITS) at MIT-MC CC: KMP at MIT-MC, ELLEN at MIT-MC, SK at MIT-MC It is more than obvious that the T13 is not detecting hangup. (Ie. either the modem card, the wires from it to the DH-11, the DH-11, the tables in the I/O-11, the I/O-11, the tables in ITS, ITS, the KL-10 or something in the path is broken). Someone might look into fixing it before half the disk is taken up by bug reports.  ASB@MIT-MC 05/10/80 16:05:04 Re: ADDENDUM TO PREVIOUS NOTE To: (BUG ITS) at MIT-MC CC: KMP at MIT-MC, SK at MIT-MC, ELLEN at MIT-MC, ASB at MIT-MC I now find that although wake-up still fails, CNTL-Z works fine. The TCTYP was apparently irrelevant.  ASB@MIT-MC 05/10/80 14:47:44 To: (BUG ITS) at MIT-MC CC: KMP at MIT-MC, ELLEN at MIT-MC, ASB at MIT-MC, SK at MIT-MC I have repeatable problems characterized by the following: [1] My equipment: ADM-3A thru VADIC 3434 over FTS 835-6985 [2] Procedure: Dial the phone no. get CXR light on VADIC indicating carrier locks. Type a , observe TXD light on vadic flash, indicating that was successfully transmitted. No answering flash of RXD light on VADIC, indicating that the return copy of is not received. Repeat the transmission and return-receive failure as many times as desired. I have done it 10 times with identical behavior. Type :TCTYP FULL into MC. After each character I notice the TXD flash, but no RXD flash. No response yet. Type CNTL-Z . Now the machine wakes up and transmits the banner: MC ITS.1168.PWORD bla bla TTY whatever ## LUSERS etc bla bla Now I find that I can log in. After doing so, I do :P O and the line corresponding to me reads 13 137 ASB P T1061 24 80 X <- which I interpret to mean that the systems thinks my terminal is T1061. Perhaps I somehow told it this, though I am unaware of having done so. I have repeated this process successfully 3 times in the last 1/2 hour.  ASB@MIT-MC (Sent by ASB0@MIT-MC) 05/09/80 18:46:32 To: (BUG ITS) at MIT-MC CC: TYANG at MIT-MC, KMP at MIT-MC, CWH at MIT-MC Logged in as ASB, I tried to log in again thru a printing terminal to get a short listing. I found that I was attached to a tree belonging to TYANG, and could not log in on my own. So I detached his tree, logged in and all was well.  Date: 9 MAY 1980 1611-EDT From: RICH at MIT-AI (Charles Rich) To: (BUG ITS) at MIT-AI It is very irritating that the DVR^F command leaves the default device set to DVR: so that, for example, subsequence :PRINT commands which do not explicitly specify AI: or DSK: in the filename fail. The XGP^F command, on which DVR^F is assumedly modelled, does not have this problem.  Date: 9 May 1980 08:29-EDT From: Kent M. Pitman Subject: Here's another one... To: BUG-ITS at MIT-MC Date: 05/09/80 05:08:05 From: DLW at MIT-AI To: KMP Re: MC dialup failure on 5/8/80 Just for the record, I also have been unable to make 253-6985 respond to CR.  RWK@MIT-MC 05/09/80 02:12:41 To: KMP at MIT-MC, GZ at MIT-MC, DANIEL at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG PWORD) at MIT-MC If someone would be so kind as to tell me which TTY line does not get PWORD, I would be fix it. Noone has cared to tell me yet. It is hardly necessary to send to note to all of BUG-ITS to get this fixed. A single responsible bug report would do it. I am sure you are aware I do not have a modem in my office, let alone a vadic triple-speed.  KMP@MIT-ML 05/09/80 02:06:32 To: (BUG PWORD) at MIT-ML CC: GZ at MIT-ML, (BUG ITS) at MIT-ML, DANIEL at MIT-ML, KMP at MIT-ML People have complained to me about dialing MC (GZ) and ML (DANIEL) and getting DDT instead of PWORD on occasion in the last couple of days. Something might be mixed up.  KMP@MIT-MC 05/09/80 02:04:03 To: (BUG ITS) at MIT-MC CC: ASB at MIT-MC, SK at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC I got multiple reports this evening of dialing 7985 and not waking up MC ... Something may be messed up. ASB's line was also 1/2-dpx for unknown reasons (said he did not :Tctyp Half) on it and doesn't know how it got into that mode but he wasn't seeing anything he was typing for a while and :Tctyp Full corrected the problem. -kmp  RWK@MIT-MC 05/09/80 01:18:30 To: (BUG TECO) at MIT-MC, (BUG ITS) at MIT-MC It seems that EMACS can't be ^P'd while running a keyboard macro, because it keeps doing .CALL of TTYGET. Now while I doubt that TECO needs to be doing .CALL of TTYGET while doing a keyboard macro, on the other hand it should not require the TTY to do such a call, but should get the information out of .TTST1 and .TTST2 and TTSTS per-job variables.  KMP@MIT-MC 05/03/80 00:07:15 To: (BUG ITS) at MIT-MC, (BUG OS) at MIT-MC CC: RWK at MIT-MC There exists an AI:SYSENG;OS 93,95,and 96. 95 and 96 seemed to have been victims of hacks, so I deleted them and re-installed 93 which seems to work fine. -kmp  RWK@MIT-MC (Sent by ___106@MIT-MC) 05/03/80 00:04:13 Re: OS To: RICH at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG OS) at MIT-MC, KMP at MIT-MC KMP fixed OS; it had been vandalized.  Date: 2 MAY 1980 2342-EDT From: RICH at MIT-AI (Charles Rich) To: (BUG OS) at MIT-AI, (BUG ITS) at MIT-AI The :OS program seems to be broken. Regardless of whether it is given a logged in user name or not, it just does a and kills itself.  Date: 1 MAY 1980 1959-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: infinite translation To: GLS at MIT-AI, (BUG ITS) at MIT-AI, (BUG EMACS) at MIT-AI To: RWK at MIT-MC CC: DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC GLS@MIT-AI 05/01/80 17:11:40 Re: infinite translation Maybe making an infinite translation may be permitted, but ITS should certainly put an upper limit on the number of translation iterations (it does the same for links). An obvious such limit is the size of its internal translation table (which is fixed)! ITS already does this. EMACS attempts to open the ERR: device, and if that open fails, for ANY REASON including Too Many Translations, it simply tries again. The historical reason for this may lie in the fact that many programs (including TECO itself) were exhibiting the malfeasance of failing to CLOSE the ERR device when done, and the system would occasionally get wedged due to this. A suitable PEEK mode was invented, and TECO at least was fixed to close ERR when done, but this business of reexecuting a failed OPEN was not.  GLS@MIT-AI 05/01/80 17:11:40 Re: infinite translation To: (BUG ITS) at MIT-MC CC: RWK at MIT-MC, DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC RWK@MIT-MC (Sent by ___010@MIT-MC) 05/01/80 05:25:35 Re: infinite translation DUFTY had a translation of IO *:*;* * => *:*;* * in his EMACS. When it runs, it runs infinitely in OPEN. ITS really should forbid such a translation, since it causes the system to lose totally, with the time hidden from view (it does not show up in PEEK). Fair share dropped to 2%, with about 10% going to users, and the rest just disappearing. Anyway, probably the "right" thing to do is for ITS to detect attempts to define infinite translations, and return an error. Of course, DDT could detect this obvious case. Maybe making an infinite translation may be permitted, but ITS should certainly put an upper limit on the number of translation iterations (it does the same for links). An obvious such limit is the size of its internal translation table (which is fixed)!  Date: 1 MAY 1980 0943-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: infinite translation To: (BUG ITS) at MIT-AI, (BUG EMACS) at MIT-AI, RWK at MIT-MC CC: DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC The real bug here is in Emacs, which if the OPEN of the ERR: device fails simply retries. I complained about this some time ago. The fact that DDT will create an infinite translation entry of this sort by way of the user typing , is perhaps at fault. Maybe there should be YET ANOTHER DDT flag, or an improvement to one of the existing ones, which would turn off nearly all short commands which naive users would never want (, ,  are the "destructive" ones that come immediately to mind).  SJK@MIT-ML 05/01/80 07:10:54 Re:  DIR: ... To: (BUG its) at MIT-MC This isn't really a bug, just a suggestion. When one is using the DIR: "device" and does, for example,  DIR:LISP;CDATE DOWN and then does a  .INFO.; (ie no change to FN1 or FN2) the DIR: has been changed back to DSK: and the command barfs. But if one changes only FN1 and/or FN2 then a MODE NOT AVAILABLE error occurs. This really seems to be the opposite of what should happen, DIR: should be "sticky" if only the directory names is changed, otherwise it can revert back to DSK: if filenames are changed. I'm open to arguments for its present method of operation but vote that this be changed in the future if possible. Thanks. -sjk  RWK@MIT-MC (Sent by ___010@MIT-MC) 05/01/80 05:25:35 Re: infinite translation To: (BUG ITS) at MIT-MC CC: DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC DUFTY had a translation of IO *:*;* * => *:*;* * in his EMACS. When it runs, it runs infinitely in OPEN. ITS really should forbid such a translation, since it causes the system to lose totally, with the time hidden from view (it does not show up in PEEK). Fair share dropped to 2%, with about 10% going to users, and the rest just disappearing. Anyway, probably the "right" thing to do is for ITS to detect attempts to define infinite translations, and return an error. Of course, DDT could detect this obvious case.  Date: 28 APR 1980 0337-EDT From: cstacy at MIT-AI (Christopher C. Stacy) Sent-by: ___020 at MIT-AI To: (BUG ITS) at MIT-AI the same thing just happenned again! Chris Stacy  Date: 28 APR 1980 0326-EDT From: CSTACY at MIT-AI (Christopher C. Stacy) Sent-by: CSTAC0 at MIT-AI To: (BUG ITS) at MIT-AI I was logged out with the normal console free message, but I did not issue a logout command of any sort. I was apparently not being gunned. When I Zd back up and logged in, I was logged in as CSTAC0...ie, no detatched trees!?! This occurred on AI. Whatsit mean??? Chris  CBF@MIT-MC 04/27/80 15:15:39 Re: Archive device To: (BUG ITS) at MIT-MC The file AR6:CBF;1980 MINS seems to be perpetually locked. There is no job which has it open. Can this be repaired and is there a procedure for repairing should this occur again?  Date: 25 April 1980 14:00-EST From: Robert W. Kerns Sender: ___126 at MIT-MC To: BUG-ITS at MIT-MC If the number that PEEK prints just after the foreign address is the foreign connection number, then a second LSN by another job while waiting for the other host to get the OPN can somehow get the same connection! The number PEEK printed was identical for both jobs. See HMR;.PEEK. >, the number 12541 is the one I'm talking about. Am I misunderstanding what I'm seeing or is this an ITS bug? (Note that while the state shown is INCXMT, there was a period while they were both in OPEN)  Date: 20 APR 1980 1943-EST From: EB at MIT-AI (Edward Barton) To: (BUG ITS) at MIT-AI Why is it that when logging in from a dialup or a STY (with :PTY) that one gets the message "Tremont is Spooling and waiting" before the AI ITS.1168 etc ??  Date: 14 Apr 1980 (Monday) 2358-EDT From: WESTFW at WHARTON (William Westfield) Subject: :F SEEMS TO BE MESSED UP To: BUG-ITS at MIT-ML IF YOU DO JUST A :F, THINGS WORK PROPERLY, BUT IF YOU DO SOMETHING LIKE :F BILLW IT GOES INTO WHAT APPEARS TO BE AN INFINITE LOOP, IN WHICH IT KEEPS REOUTPUTTING THE TTY OUTPUT BUFFERS (?). I THINK :FINGER STILL WORKS PROPERLY. BILLW  SAM@MIT-AI 04/08/80 21:21:30 To: (BUG its) at MIT-ML One of the ML dialups is very bad. It starts out fine then worsens to the point where you can't get any characters over the line. Its one of the 300 baud ones. I have no way of saying which it is, --Sam  Date: 4 APR 1980 2026-EST From: JNC at MIT-AI (J. Noel Chiappa) Sent-by: ___050 at MIT-AI Subject: Logging in on AI... To: (BUG ITS) at MIT-AI Gets you the message "84375 Memory errors in 23.4 Hours". Is this machine serious, or do I detect little elves at work?  EAK@MIT-MC 04/01/80 17:34:17 To: (BUG ITS) at MIT-MC "MC TOPS-20 V4.0 Console 60 Fried"?  Date: 29 MAR 1980 1249-EST From: AGRE at MIT-AI (Philip E. Agre) To: (BUG DDT) at MIT-AI, (BUG ITS) at MIT-AI CC: AGRE at MIT-AI I think that the "excessive tourist usage may lead to a restricted policy" clause in the MIT-AI ITS login message sounds like a very unfriendly threat. I don't think that we have made sufficient efforts yet to explain to tourists exactly what the state of the world is and what is the behavior that is expected of members of the MIT-AI community. Such explanations should be made, and individuals who refuse to cooperate with us should be singled out for threats rather than just threatening hundreds of our guests for the misdeeds of a few. (And there ought to be more to this than an occasional flame by someone who has discovered a new form of tourist ignorance or misbehavior.) - Phil  Date: 28 MAR 1980 1707-EST From: JERRYB at MIT-AI (Gerald R. Barber) To: (BUG ITS) at MIT-AI What happened to fido? I hope he didn't die of old age.  Date: 26 MAR 1980 2207-EST From: KLH at MIT-AI (Ken Harrenstien) To: (BUG ITS) at MIT-AI SYSMSG should show more stuff. Nowadays things happen so fast (logins/outs) that if, e.g. my net connection breaks, by the time I get back 2 minutes later (yes two minutes) any evidence as to the nature of the lossage has long vanished from the minor fragments SYSMSG knows about. Foo.  Date: 25 MAR 1980 1908-EST From: MOON at MIT-MC (David A. Moon) Subject: DIRHNG: To: EBM at MIT-XX CC: (BUG its) at MIT-AI Date: 25 Mar 1980 1118-EST From: EBM at MIT-XX Subject: DIRHNG: To: bug-its at MIT-AI I believe that creating new links in a directory should also result in an interrupt on the channel open to the DIRHNG: device. It does. [Also, I have always believed that one should be able to read the device, which will result in hanging until a file is closed. The data returned could be garbage, or 0 -- it does not matter. The point is that one should not be REQUIRED to use interrupts for such things if they are unnecessary.] Maybe, but interrupts are trivial to use. Having a piece of documentation available on DIRHNG: would be nice, too. E.g., :call open, or something. Yes, it should be.  Date: 25 Mar 1980 1118-EST From: EBM at MIT-XX Subject: DIRHNG: To: bug-its at MIT-AI I believe that creating new links in a directory should also result in an interrupt on the channel open to the DIRHNG: device. [Also, I have always believed that one should be able to read the device, which will result in hanging until a file is closed. The data returned could be garbage, or 0 -- it does not matter. The point is that one should not be REQUIRED to use interrupts for such things if they are unnecessary.] Having a piece of documentation available on DIRHNG: would be nice, too. E.g., :call open, or something. -------  Date: 24 MAR 1980 2012-EST From: agre at MIT-AI (Philip E. Agre) Sent-by: GJS at MIT-AI To: (BUG ITS) at MIT-AI How about a program that asks all tourists to log out?  Date: 24 MAR 1980 1915-EST From: AGRE at MIT-AI (Philip E. Agre) To: (BUG ITS) at MIT-AI Is there a program that says "change working directory to my home directory"?  Date: 24 March 1980 17:24-EST From: "Guy L. Steele, Jr." Subject: Comma in ^O filespec loses!! To: KLH at MIT-AI, BUG-ITS at MIT-AI, BUG-DDT at MIT-AI It is semi-well-known that a comma ends a filespec in DDT, as does a CR; CR in addition ends the command. Consider :RENAME, for example; if you type :RENAME FOO GREPS,BARF GREPS the comma terminates the first file name and the second altmode redisplays the second file name. This is actually useful. However, had one used  instead of :RENAME (), then the comma terminates the command, but the command doesn't "run" until the second altmode is typed. Moreover, any stuff after the comma is lost -- the second altmode doesn't redisplay it or anything. Maybe for safety's sake the number of commas should be counted and a complaint registered if there are too many. Also, typing an altmode should NEVER cause the command to be run! The whole point is to be able to see the name of the file you are about to dastardly mung.  Date: 21 MAR 1980 2132-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: Comma in ^O filespec loses!! To: (BUG ITS) at MIT-AI, (BUG DDT) at MIT-AI Goddamit, I did an ^O and it said that it was about to delete ".FOO X". I typed in ",FOO X" which was what i really wanted to delete (the comma was mis-typed in an append command), and the '"'$)#$)"#%#("$'$ went ahead and screwed me by flushing the original ".FOO X" file!!!! Snarrrl!! Just what meaning is a comma supposed to have in a delete command anyway??? The FN1 wasn't changed at all.... you'd at least have expected it to try deleting "FOO X".  Date: 20 MAR 1980 0913-EST From: RICH at MIT-AI (Charles Rich) Subject: Device Handling To: ED at MIT-AI, MOON at MIT-AI CC: (BUG ITS) at MIT-AI Ok, with the help of your replies I think I understand the problem: the various machines do not recognize THEMSELVES as a valid device combined with ARn in the same way as other machines. This makes it much less convenient to write code which will run on any machine. For example, on AI :LISTF AIAR3:RICH; doesn't work, but on other machines it does. Ed, you are right, the extra colon was never right; the form :LISTF AI:AR3:RICH; only worked on AI because the first AI: was thrown away. I now think we have now narrowed this down to an honest-to-goodness bug. Thanks, Chuck.  Date: 20 March 1980 03:09-EST From: Ed Schwalenberg Subject: Device Handling To: RICH at MIT-AI, BUG-ITS at MIT-AI On AI you type :LISTF ML:ARn:UNAME; I can' believe that this ever worked, or could work. It certainly does not work now. :LISTF MLARn:UNAME; This has always been the form recognized by ITS. The unknown device handler checks to see if the first 2 chars are a machine name, and hands the rest of the device name to that machine. Inserting an extra : will cause most filename readers to ignore the ML: by clobbering the device field with ARn:. The exception is :FIND, which makes a LIST of all devices (and directories) to be searched. Is it possible you were led down the garden path by having similar archives on 2 machines? Experiment with the MLTTY: device and you will see that MLTTY: gives you ML's, ML:TTY: gives you AI's (TTY:) and TTYML: gives you NO SUCH DEVICE (the FIRST 2 chars must be the machine name.  Date: 19 MAR 1980 1824-EST From: RICH at MIT-AI (Charles Rich) Subject: Device Handling To: (BUG ITS) at MIT-AI On AI you type :LISTF ML:ARn:UNAME; to refer to an archive on another machine, but on DM you type it without the extra colon, i.e. :LISTF MLARn:UNAME; to get the same effect. The alternative form on either machine loses. Sigh... it would be nice if it were compatible, no?  Date: 17 March 1980 21:12-EST From: Ed Schwalenberg To: AGRE at MIT-AI, BUG-ITS at MIT-AI cc: SHADOW at MIT-AI Date: 17 MAR 1980 1509-EST From: AGRE at MIT-AI (Philip E. Agre) Sent-by: SHADOW at MIT-AI I did agrectl-s then :xfile agre;agre login on shadow's terminal, so I could read my mail without logging shadow out. It did all the gmsgs's right, but when it finally called :rmail, it did it on shadow's mail file. agrectl-s :rmail works right, so I suspect that the agrectl-s wasn't able to distribute over the whole :xfile execution. This led to a rather embarrasing error. Can it be fixed, or is it a feature? - Phil From DDT ORDER: $^S causes the next ^K, ^H or :-command, if it runs a program, to run it "as if were running it". Precisely, its .XUNAME variable will be instead of you and its .HSNAME will be set to 's HSNAME. If the program follows the current convention, it will use 's init file, etc. $^S works by setting the ..TUNAME and ..THSNAME variables. Since your XFILE runs 2 programs, you lose.  Date: 17 MAR 1980 1509-EST From: AGRE at MIT-AI (Philip E. Agre) Sent-by: SHADOW at MIT-AI To: (BUG ITS) at MIT-AI CC: SHADOW at MIT-AI I did agrectl-s then :xfile agre;agre login on shadow's terminal, so I could read my mail without logging shadow out. It did all the gmsgs's right, but when it finally called :rmail, it did it on shadow's mail file. agrectl-s :rmail works right, so I suspect that the agrectl-s wasn't able to distribute over the whole :xfile execution. This led to a rather embarrasing error. Can it be fixed, or is it a feature? - Phil  Date: 15 MAR 1980 2140-EST From: KLH at MIT-AI (Ken Harrenstien) To: EAK at MIT-MC CC: (BUG ITS) at MIT-AI Date: 9 February 1980 13:00-EST From: Earl A. Killian How about changing the definition of %TDICP n from being "insert n blanks in the current line" to being "insert next n characters in the current line"? I suspect that no programs would have to change (i.e. TECO wouldn't). The reason for the chnage would be to allow insertion to happen more reasonably on some terminals (in particular those with an insert character mode), without making it any less efficient for terminals like TVs or the Teleray. CRTSTY would make use of the new constraint on what can follow a %TDICP, and maybe ITS could too. I don't think it would be a good idea to change the %TDICP definition. The idea is certainly clever, but I am paranoid about what could happen if the output stream was interrupted or otherwise disrupted while counting down these N characters, since this is also in effect quoting the next N characters. It seems much more robust to have a way to enter insert-char mode and leave it; then a reset of this mode would always be effective. It would also be just as efficient, since a %TDICP N is two characters plus the string, whereas a %TDSIC and %TDEIC (Start & End insert-char mode) is also just two chars plus the string. I don't see anything wrong with having more %TD codes, except that a TTYOPT bit might be needed to say whether the terminal could handle it or not; if not, ITS would just simulate it with %TDICP's.  MOON@MIT-MC 03/14/80 10:50:49 Re: Your bug report about translations To: KMP at MIT-MC CC: (BUG ITS) at MIT-MC, ECC at MIT-AI Presumably the underlying cause is that translations don't affect the RENMWO system call. It is not obvious that they should, or what would be a consistent way of doing so. Fortunately translations are mainly useful for devices and directories rather than file names.  KLH@MIT-MC 03/14/80 04:59:05 To: (BUG ITS) at MIT-MC I think someone has barfed about this before, but... Is it really the right thing to turn foo < into foo > when writing??  KMP@MIT-MC (Sent by TURNIP@MIT-MC) 03/14/80 04:46:16 To: (BUG ITS) at MIT-MC, KMP at MIT-MC, ECC at MIT-AI CC: (BUG GMSGS) at MIT-MC Sigh. This 'feature' of writing to a temp file turns out to affect GMSGS for ECC ... We were just trying to isolate simpler cases, but the original ('real') attempt was to get GMSGS to output to a different file than xuname MAIL ... Its writing to a temp file and then Rename-While-Opening without checking translations is what prompted all this I guess.  ED@MIT-AI 03/14/80 02:56:10 To: ECC at MIT-AI, KMP at MIT-MC, (BUG ITS) at MIT-MC Both TECO and DDT are too smart for their own good, sometimes. The file OPENed in both cases (and thus subject to translations) is KMP;_TECO_ OUTPUT (or _COPY_ for DDT.). When the file is completely written, it is RENMWOed to FOO BAR, which operation is NOT subject to translation. There is a teco command to write output directly without renaming, search for "core link" in TECO ORDER for suggestions.  KMP@MIT-MC 03/14/80 01:07:49 To: (BUG ITS) at MIT-MC, ECC at MIT-AI CC: KMP at MIT-MC Doing  KMP;FOO BAR,KMP;BAR FOO on MC and then :CREATE'ing KMP;FOO BAR still creates the file FOO BAR. :COPY TTY:, ... gives similar results so I doubt this is a Teco problem. When I try to read the file, I get a file not found error because an input translation has been created but not an output translation... o ... produces the same results. In the former case, PEEK shows that there exists an IO translation. In the latter, it says there is just an output translation -- but in neither does it keep from writing to FOO BAR as a truename as it should. Can someone please fix this or tell me why I am misunderstanding what output translations are capable of? Thanks. -kmp  Date: 13 MAR 1980 1857-EST From: JERRYB at MIT-AI (Gerald R. Barber) To: (BUG ITS) at MIT-AI One outcome of the disk storage crunch getting worse and worse is that there will be more randoms deleting random files. It seem like a program that would combine the facilities of COMMON;FIND JUNK and DIRED would be useful. In addition, it would keep track of what files were deleted and who deleted them. In this way people would be less tempted to do rash deletions. It might do other things such as refusing to delete files that have not been backed up, files that are > versions and files where the file name is of a specific structure etc.  Date: 11 MAR 1980 1945-EST From: EB at MIT-AI (Edward Barton) To: (BUG ITS) at MIT-AI Why does :COPYing to other machines so often hang up doing an SAUTH ? That has happened about five times today.  RWK@MIT-MC (Sent by ___036@MIT-MC) 03/06/80 04:07:41 Re: TTY hangage To: (BUG ITS) at MIT-MC I don't know if anybody cares, but it's possible to wedge a TTY completely by doing :SPRT EJS;STYOUT DEBUG on MC. This outputs a random asii file as 8-bit codes. I don't know if the TTY code claims not to wedge TTY's in the case of garbage super-image output, but if it does, here's a counter-example.  Date: 4 MAR 1980 1437-EST From: gls at MIT-AI (Guy L. Steele, Jr.) Sent-by: RICH at MIT-AI To: MOON at MIT-AI CC: GLS at MIT-AI, (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI CC: (BUG ITS) at MIT-AI, (BUG TECO) at MIT-AI, (BUG EMACS) at MIT-AI CC: (BUG LISPM) at MIT-AI, cpr at MIT-MC Last note from RICH was really from GLS.  Date: 4 MAR 1980 1434-EST From: RICH at MIT-AI (Charles Rich) To: MOON at MIT-AI CC: GLS at MIT-AI, (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI CC: (BUG ITS) at MIT-AI, (BUG TECO) at MIT-AI, (BUG EMACS) at MIT-AI CC: (BUG LISPM) at MIT-AI, CPR at MIT-MC One obvious application of the Greek/Front key on the PDP-10 is that all such characters could be self-inserting in TEX format; thus typing  would insert "\alpha", etc. I don't know how much more convenient this would make it to type weird formulas in TEX.  Date: 3 MAR 1980 2337-EST From: MOON at MIT-MC (David A. Moon) Subject: Use of New Keyboards with ITS. To: JLK at MIT-MC CC: CPR at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC CC: (BUG ITS) at MIT-MC, (BUG TECO) at MIT-MC I don't think ITS is going to be able to accomodate all of the new modifier bits. There are no free bits in the present internal (18-bit) character code. I don't think making Greek input work is very important, since we certainly aren't going to go to the very large amount of trouble required to make Greek output work and have a more-than-7-bit printing-character set. It would be nice to make Super and Hyper work to ITS, although there are not enough bits available. Note that shift-lock has already been recycled. Shift is sort of recycled and sort of vestigially still there; it could be recycled for this. It isn't necessary to be able to represent all 16 combinations of the "bucky bits"; for instance there are 8 combinations of 0, 1, or 2-adjacent buckies. Since the function keys are there, you may as well make up top+>40 codes for them. Some of the function keys map into keys on the old keyboard; see the #\ table in LMIO;READ for something from which this mapping can be derived, as we are doing it on the Lisp machine now. From memory, it's clear-screen->form, delete->vt, clear-input->clear, macro->back-next (but should be system->backnext in your case), terminal->esc. It's not obvious that new keyboards will ever be attached to the AI TVs. We might, and we might not. It would involve slowing down the keyboard scanner substantially, and we might have to put some buffering in the keyboard microprocessor.  Date: 3 March 1980 21:41-EST From: John L. Kulp Subject: Use of New Keyboards with ITS. To: MOON at MIT-MC cc: CPR at MIT-MC, BUG-DDT at MIT-MC, BUG-LISP at MIT-MC, BUG-ITS at MIT-MC, BUG-TECO at MIT-MC We are going to hook up a new kbd to the PTV system in the next few days, and the obvious question comes up about how to encode all the function keys. I suppose they could be handled the way they are on the old keyboard, namely send chars with the TOP bit + 100 + . In order to distinguish them from the old kbd, how about encoding them in 140-177? Presumably the extra modifier bits (SUPER, HYPER, and GREEK) need to be allowed (that uses up all the bits available in the intelligent terminal protocol, unless we want to flush SHIFT and SHIFT-LOCK). It doesn't much matter what the encoding is, as long as its documented. I guess any part of the system which masks off the high modifier bits or otherwise depends on them being zero will have to get looked at. ITS presumably wants to know about the SYSTEM key (treat like BACK/NEXT). Its about time DDT knew about CLEAR (or CLEAR INPUT on the new kbds) which should behave like ^D. Also, HELP, STOP OUTPUT (^S, actually this should probably be defined to do an output hold at the terminal, followed by an output reset from the remote process (as is currently done)), ABORT (^G), END (^C), RESUME ($P), etc. TELNET and SUPDUP should be informed about the NETWORK key. Various programs should know about END, ABORT, RESUME, BREAK, QUOTE, HELP, STATUS (I'm not saying every program in the world should be retrofitted to know about these, but the basic ones -- DDT, TECO, LISP -- probably should). I suspect that not much is going to happen on this until AI TV's start getting new keyboards, but I would at least like to see the encoding defined now, so that where only simple changes are required, they can be done quickly when desired.  Date: 3 MAR 1980 1201-EST From: AGRE at MIT-AI (Philip E. Agre) To: (BUG ITS) at MIT-AI The terminal controller still seems to think that CADR-2 is still in 907. x6765 gets an occasional call looking for the person on CADR-2.  CFFK@MIT-MC 03/01/80 19:04:16 To: (BUG PEEK) at MIT-MC, (BUG ITS) at MIT-MC In PEEK M mode on a Macsyma I was running gave: Mem=216, Top=254, Shared=158, Out=-1, Total=215 What does Out=-1 signify?  KLH@MIT-MC 03/01/80 18:40:23 To: MOON at MIT-MC CC: (BUG ITS) at MIT-MC I think FAST-APPEND can win using the following algorithm: ------------------- If canonical file doesn't exist: Check for AOS'd version, and rename to canonical. Find message-EOF of file: Re-open in read mode if not already in. Set .ACCESS ptr to file-EOF Read backwards until a msg-EOF mark is seen (ie ctl-_) If canonical file already existed, msg-EOF is set to file-EOF. Re-open file in write-over mode Set .ACCESS ptr to msg-EOF Write message. If IOC for some reason, just stop. Close channel. ------------------- Note that there is no need to do anything about RENMWO'ing, because following attempts will always start at the right place, and it doesn't matter if the next attempt doesn't quite extend past the true file EOF, because following appends will still back up to the new msg-EOF mark. It would be a LOT more efficient if there was some way to both read and write the file while it was open; ironically enough the only way to do this now is to map into the system buffer and see what's there!! The data is there, but the system won't let you get at it. Foo. It would probably be easier to allow some way of doing this dual I/O ("read-while-locked"?) mode than to hack APPEND mode, since it doesn't depend on anything fundamental to the UFD. Another idea is for ITS to support this algorithm internally, given the EOF delimiter(s) as argument. Might be invoked by an OPEN mode bit, or a new CALL. This requires even less overhead and makes the feature generally available. This also prevents race conditions since presumably one process would be locked out while the other's APPEND effort progressed; this sort of system-supported reliability could also make it reasonable to use FAST-APPEND on normal MAIL files (since the FN2 is just 4 letters and an AOS will stand out). I'd claim this is a lot more useful than ECHOIN's hacking TECO buffers! The amount of really gross disk I/O that the COMSAT does seems to far exceed the amount of TTY-echo overhead being done, especially on AI. Any comments on this scheme? (No, I'm not likely to stop trying.)  BARRYG@MIT-MC 02/29/80 20:30:10 Re: filenames for automatic deletion To: (BUG ITS) at MIT-MC I use EMACS in autosave mode and I'm getting tired of cleaning up after it. I'm stuck with a filename1 of BARRYG (by convention), so is there a filename2 that will cause the file to be automatically reaped? If there is, it will simplify life as I want to keep the number of files I leave around to a minimum. /barry gold  Date: 1 December 1979 12:10-EST From: Robert W. Kerns Subject: Directory block shuffle To: GLS at MIT-AI cc: BUG-ITS at MIT-AI, DLW at MIT-AI It would be better to make it store the UNAME in the word with the reference date, so you could find out who even if the person didn't have a directory of his own....  Date: 11 December 1979 10:34-EST From: Earl A. Killian Subject: sorting To: BARRYG at MIT-MC cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC Date: 12/11/79 00:44:04 From: BARRYG at MIT-MC To: (BUG DDT) cc: (BUG ITS) Re: sorting Is there a way to sort a file on this system? If it's easier to do than explain, the file I want to sort is MC:GUEST1;BARRYG YAMATO to be sorted in ascending order on the first 40 characters of each line. Yes, try   40c  l  in TECO.  is the sort command - the first command string moves from the beginning of the record to the beginning of the key, the second command moves to the end of the key, and the third to the end of the record.  MACRAK@MIT-MC 12/13/79 17:28:41 To: (BUG ITS) at MIT-MC, (BUG SYS) at MIT-MC CC: RWK at MIT-MC ARGGGGH!! .open [1,,'nul] .status -> 2121 .open [1,,'dsk ? 'foobar ? 'quuzey] .status -> 43 What happened to the 100 bit?? (write) Peek seems to know that the chnl is opened for writing. Why doesn't .status?!  ED and ALAN and 42TLNT TELSER@MIT-MC (Sent by ALAN@MIT-MC) 02/28/80 03:02:19 Re: .FLT1 and 2 To: (BUG ITS) at MIT-MC These seem to be initialized to %pibrk and 0 on MC and not initialized elsewhere. Elsewhere, in fact, they seem to contain the UNAME and JNAME of the last job to .LOGOUT of that job slot (?!?!?) What are these, anyway? They aren't documented anywhere. Looking in the system also seems to comfirm that these values are used for COMPLETELY RANDOM stuff like the RENAME case of .MLINK ((??!!??!!??))  EJS@MIT-MC 02/26/80 20:24:16 To: (BUG ITS) at MIT-MC :call echoin and :call ttyesc do not provide documentation on the respective system calls. Could somebody please update the doc file? Thanks.  MOON@MIT-MC 02/24/80 21:37:03 To: ECC at MIT-MC CC: (BUG ITS) at MIT-MC ECC@MIT-MC 02/24/80 21:31:43 To: (BUG ITS) at MIT-AI The TV in 902 was garbling a lot of bits on the screen, in particular making the finger display shown when it is logged out almost totally unreadable. I logged in to see if :FINGER would produce a more readable listing, which it sorta did. However when I then logged out, it gave a little "bizzap!" sound (not very noisy) and the screen went blank, with nothing that I could type bringing it back. The garbling of bits was a central problem which I believe I have just fixed. If the screen is still blank, try turning the monitor off and back on (if you can't find the plug, pull the fuse in the back out and put it back in.)  ECC@MIT-MC 02/24/80 21:31:43 To: (BUG ITS) at MIT-AI The TV in 902 was garbling a lot of bits on the screen, in particular making the finger display shown when it is logged out almost totally unreadable. I logged in to see if :FINGER would produce a more readable listing, which it sorta did. However when I then logged out, it gave a little "bizzap!" sound (not very noisy) and the screen went blank, with nothing that I could type bringing it back.  JLK@MIT-MC 02/11/80 09:05:07 To: (BUG @) at MIT-MC CC: (BUG ITS) at MIT-MC I think it is a rather major loss that :@ defaults to MIDAS or somesuch, given the relatively few users of @ who make MIDAS listings. If one were to base the defaults on numbers, it should default to LISP code. But I don't suggest that. :@ with no other JCL should obviously be the same as :@ /L[RANDOM]/D[DOVER]/# these days.  Date: 10 FEB 1980 0203-EST From: bak at MIT-AI (William A. Kornfeld) Sent-by: ___101 at MIT-AI To: (BUG ITS) at MIT-AI This is a qubbling point, but if someone is REALLY bored he may wish to fix it. If an archive is on an unmounted disk (i.e. SECOND) and you do an AR2^F, it gives an incorrect error message. It thinks AR2 is a non-existent directory. The correct error message should be PACK NOT MOUNTED.  MOON@MIT-MC 02/09/80 16:25:23 Re: %TDICP suggestion (EAK) To: (BUG ITS) at MIT-MC CC: EAK at MIT-MC Hmm, clever. Sounds like it would work.  Date: 9 February 1980 13:00-EST From: Earl A. Killian Subject: %TDICP suggestion To: BUG-ITS at MIT-MC How about changing the definition of %TDICP n from being "insert n blanks in the current line" to being "insert next n characters in the current line"? I suspect that no programs would have to change (i.e. TECO wouldn't). The reason for the chnage would be to allow insertion to happen more reasonably on some terminals (in particular those with an insert character mode), without making it any less efficient for terminals like TVs or the Teleray. CRTSTY would make use of the new constraint on what can follow a %TDICP, and maybe ITS could too.  Date: 9 February 1980 13:00-EST From: Earl A. Killian To: BUG-ITS at MIT-MC cc: %TDICP SUGGESTION at MIT-MC How about changing the definition of %TDICP n from being "insert n blanks in the current line" to being "insert next n characters in the current line"? I suspect that no programs would have to change (i.e. TECO wouldn't). The reason for the chnage would be to allow insertion to happen more reasonably on some terminals (in particular those with an insert character mode), without making it any less efficient for terminals like TVs or the Teleray. CRTSTY would make use of the new constraint on what can follow a %TDICP, and maybe ITS could too.  Date: 9 FEB 1980 0941-EST From: GRAND at MIT-AI (Mark D. Grand) To: (BUG ITS) at MIT-AI How does one go about recovering a file that (I presume) was reaped?  CFFK@MIT-MC 02/07/80 10:21:33 To: (BUG ITS) at MIT-MC I was logged into TTY 7, and all of a sudden nearly everything I typed gave IBO.  Date: 27 JAN 1980 0457-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG ITS) at MIT-AI Someone should document the ECHOIN system call.  Date: 25 January 1980 01:40-EST From: Robert W. Kerns To: DLW at MIT-AI cc: AGRE at MIT-AI, BUG-ITS at MIT-AI Date: 23 January 1980 01:17-EST From: Daniel L. Weinreb To: AGRE at MIT-AI, BUG-ITS at MIT-AI Date: 22 JAN 1980 2028-EST From: AGRE at MIT-AI (Philip E. Agre) ... BUG-ITS: Does anyone think it might be more useful to display the MSNAME in the wholine, given that the SNAME is rather arbitrary? The main use I can see for the SNAME is that it seems to correlate with the *PRINT, :LISTF etc default directory in HACTRN, but I am not sure how good this correlation is. The TV can't display the MSNAME. The MSNAME lives only in DDT. (It could be added to ITS, but...) DDT's SNAME should correspond pretty well with the :PRINT default, which is a more useful thing to display. You don't change your MSNAME very often.  BEN@MIT-ML 01/24/80 08:42:45 To: (BUG ITS) at MIT-ML I use a Teleray 1061 with SIPB prom, and the display of overlong lines seems to be incorrect. I suspect that both the terminal and ITS are providing an extra , because the continuation skips a line before writing the remainder of the line. If something was previously on the skipped line, it remains (i.e. nobody does a clear-to-end-of-line on ). This makes the text remarkably difficult to read. This happens most noticeably in RMAIL. Ben Kuipers  GSB@MIT-ML 01/23/80 10:41:35 Re: ml lpt To: (BUG ITS) at MIT-ML CC: WAM at MIT-ML There are two consecutive columns near the left margin that don't print at all.  Date: 23 JAN 1980 0117-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: AGRE at MIT-AI, (BUG ITS) at MIT-AI Date: 22 JAN 1980 2028-EST From: AGRE at MIT-AI (Philip E. Agre) When you do a :CWD on a TV, the current-directory entry on the bottom line of the screen doesn't change to the new value until you use the directory, say by ^F'ing it. Philip: This is because the TV is showing you the "SNAME" of the running job, rather than the "MSNAME"; the latter is what is set by the :CWD command. BUG-ITS: Does anyone think it might be more useful to display the MSNAME in the wholine, given that the SNAME is rather arbitrary? The main use I can see for the SNAME is that it seems to correlate with the *PRINT, :LISTF etc default directory in HACTRN, but I am not sure how good this correlation is.  Date: 22 JAN 1980 2028-EST From: AGRE at MIT-AI (Philip E. Agre) To: (BUG ITS) at MIT-AI When you do a :CWD on a TV, the current-directory entry on the bottom line of the screen doesn't change to the new value until you use the directory, say by ^F'ing it.  MOON@MIT-MC 01/15/80 09:31:33 To: JONL at MIT-MC CC: (BUG ITS) at MIT-MC JONL@MIT-MC 01/15/80 01:37:49 To: (BUG ITS) at MIT-MC It would be nice to be able to display a directory with only the PRIMARY device shown - but FIND PK0:foo;* * shows all the SECOND: and THIRD: files too. The correct command is :FIND foo;* * &PACK 0. I am surprised that giving "PK0:" in a :FIND does not give you an error; I guess it must be simply ignored.  JONL@MIT-MC 01/15/80 01:37:49 To: (BUG ITS) at MIT-MC It would be nice to be able to display a directory with only the PRIMARY device shown - but FIND PK0:foo;* * shows all the SECOND: and THIRD: files too.  JLK@MIT-MC 01/14/80 12:46:25 To: (BUG ITS) at MIT-MC Well T37 is once again in the wedged state where ist output buffer pointer is garbaged. Is there a way to patch this to make it functional again? (I realize its probably impossible to track down this problem)  MOON@MIT-MC 12/27/79 08:04:42 Re: .STATUS and .CALL STATUS broken To: MACRAK at MIT-MC CC: (BUG ITS) at MIT-MC I thought I answered it. It's fixed in the source. It had evidently been broken for many years.  HAL@MIT-MC 12/26/79 22:24:08 To: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC i just sent a bug message about not being able to run crtsty. i now realize that this occurred because, at the moment i tried to run it, disc space went to zero. so i guess you can ignore the previous bug message.  HAL@MIT-MC 12/26/79 22:02:39 To: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC Has there just been some change to MC ITS ? Suddenly I can't seem to run CRTSTY .  MACRAK@MIT-MC 12/26/79 21:18:38 To: (BUG ITS) at MIT-MC I never received an answer about my complaint that .Status problem: namely, .Status doesn't seem to correctly report whether a Dsk or TTY channel is input or output! Try: 100/ $$0' !DSKfoo >$ .open 100$x .status$x 0/ 43 (not 143) This does not seem to depend on the mode of output (image, block) nor anything else I can find. Can anyone tell me how to find out whether a channel is open for input or output if this isn't considered a bug???  MOON@MIT-MC 12/20/79 00:07:07 To: MRC at MIT-AI CC: (BUG ITS) at MIT-MC Date: 19 DEC 1979 2137-EST From: MRC at MIT-AI (Mark Crispin) To: (BUG ITS) at MIT-AI Why does .CALL USRVAR insist upon MOVEM for the return argument value? It should allow 2000,, like the rest of .CALL does. It is not the same. The arguments to USRVAR, TTYVAR are really instructions.  Date: 19 DEC 1979 2137-EST From: MRC at MIT-AI (Mark Crispin) To: (BUG ITS) at MIT-AI Why does .CALL USRVAR insist upon MOVEM for the return argument value? It should allow 2000,, like the rest of .CALL does.  Date: 19 DEC 1979 2125-EST From: MRC at MIT-AI (Mark Crispin) To: (BUG ITS) at MIT-AI TELNET failed to assemble because %TXSFL apparently is no longer defined. All TELNET used it for was to turn the bit off along with %TXSFT. I removed the reference; can TELNET trust that that bit will never be on?  DLW@MIT-MC (Sent by DLW0@MIT-MC) 12/14/79 08:39:37 To: (BUG ITS) at MIT-MC It appears that ITS does not understand what %TOSAI on a DM2500 is supposed to do. On the SAIL-modified DMs, as well as our fake DMs, you send escape (033) followed by the low-order code in order to make it print an extended graphic. Could ITS be changed to transmit this sequencefor terminals with TCTYP of DM2500 with the %TOSAI bit set? This is not urgent...  BARRYG@MIT-MC 12/11/79 00:44:04 Re: sorting To: (BUG DDT) at MIT-MC CC: (BUG ITS) at MIT-MC Is there a way to sort a file on this system? If it's easier to do than explain, the file I want to sort is MC:GUEST1;BARRYG YAMATO to be sorted in ascending order on the first 40 characters of each line.  Date: 3 DEC 1979 0116-EST From: jnc at MIT-AI (J. Noel Chiappa) Sent-by: PK at MIT-AI Subject: Shutting down an ITS To: (BUG ITS) at MIT-AI It sort of unflavorful that you have to wait at least 5 mins to shut down the system (etc LOCK). In an emergency, you might want a fast shutdown to repatriate disk bufs, etc.... preumably one could patch, say, SHUTDN to the right thing, but it would be nice if there was a good way to do this without such hacks...  Date: 30 NOV 1979 1458-EST From: GLS at MIT-AI (Guy L. Steele, Jr.) To: (BUG ITS) at MIT-AI CC: GLS at MIT-AI, DLW at MIT-AI MSG: LOSER 1 DLW@MIT-AI 11/29/79 19:23:09 Re: Don't delete other people's files! Some very recently deleted a group of files on my directory. These were very important information, and some had been quite recently modified. If you are trying to create disk space, ASK people to delete their own files--don't do it yourself! The ITS no-security system can only work in an environment of reasonable, responsible people; deleting other people's files like this is highly irresponsible. I wonder how hard it would be to make the following modifications to the disk routines: [a] when a file is deleted, shuffle its five-word block to the middle of the directory rather than just overwriting it. Thus, a rotation of a number of five-word blocks would occur, I think. [b] install the uname of the deleting job as the file's "author". This would tend (though not guarantee) to preserve information as to who deleted a file. It might make it easier to deal with this problem, which has come up a lot recently.  RWK,RMS@MIT-MC (Sent by RWK@MIT-MC) 11/28/79 04:14:06 To: (BUG ITS) at MIT-MC Translations should canonicallize DSK: to MC: etc, or the result is unpredictible. (Do YOU know if MM Load LibraryFOO uses MC: or DSK: ??)  Date: 28 NOV 1979 0250-EST From: RMS at MIT-AI (Richard M. Stallman) To: (BUG ITS) at MIT-AI Control-CALL echoes as just a Z. It should probably echo as ^Z.  CFFK@MIT-MC 11/20/79 08:32:07 Re: Continuation of previous message To: (BUG ITS) at MIT-MC Thus MC is receiving burst of ~ 70 characters at a time. I realize that the real culprit is the TELNET program that runs on the MFE-NET. However is there any fix I can make at MC to circumvent this problem?  CFFK@MIT-MC 11/20/79 08:28:12 To: (BUG ITS) at MIT-MC If I log into MC from LLL-MFE, MC occasionally drops the last few characters of the lines I type in (and the ). The problem arises because I'm logged into LLL-MFE via the MFE-NET which works a-line-at-time. Thus MC is receiving  Date: 15 NOV 1979 1046-EST From: MAP at MIT-AI (Michael A. Patton) To: (BUG ITS) at MIT-AI CC: MAP at MIT-AI The node A/1/a in ITSTTY cannot be reached by any normal means (that I could find). The only way I could get there was with G.  REM@MIT-MC 11/11/79 22:46:41 Re: Not a bug, rather a query/gripe/request To: (BUG ITS) at MIT-MC Given the SIXBIT name of a STY device, such as "S20", or just the number such as 20, it should be easy to find out whether or not that STY is in use by any job (your own job, or anybody else). Anybody know how to do it? Apparantly currently you can't do it unless you know the TTY that is associated with it, thus making it impossible to write a subroutine that gets you a new STY you don't already have unless you have been keeping a list of STYs-you-have all along since you started acquiring STYs.  Date: 7 November 1979 06:31-EST From: Donald R. Woods Subject: net ports To: RWK at MIT-MC cc: BUG-CRTSTY at MIT-AI, BUG-ITS at MIT-MC Hmm, okay, I guess I hadn't been willing to believe that completely unrestricted simulated ttys would number only 6, so I assumed that only a subset of them were allowed as net ports. Amazing that you can survive with only 6! Assuming most of them are normally in use for net ports or lisp-machine users, I find it hard to believe that you can get enough STYs for CRTSTY and other uses. Maybe you don't use them as much on ITS as we do at SAIL.  Date: 6 NOV 1979 2108-EST From: CEH at MIT-MC (Charles E. Haynes) To: C100-FANS at MIT-MC Redistributed-To: bug-its at MC Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 6 Nov 1979 Recently I have become involved in a discussion of the relative merits of CRTSTY vs TCTYP support for C100's. My personal feeling is that the TCTYP support is inadequate in a number of areas, the largest being its lack of support for the "Sail" character set. Granted CRTSTY takes an extra job slot, I feel that its support is enough better that I prefer it (CRTSTY). What do other people think? -- Charles  Date: 7 November 1979 01:04-EST From: Robert W. Kerns Subject: net ports To: CSD.DON at SU-SCORE cc: BUG-ITS at MIT-MC, BUG-crtsty at MIT-AI Date: 5 Nov 1979 2308-PST From: CSD.DON at SU-SCORE To: bug-crtsty at MIT-AI Re: net ports Incidentally, I consider it a crock of the finest shit that, for whatever reason(s), CRTSTY uses up an extra network port (of which I'm told there are only 6) instead of a system-internal simulated tty. Do all STYs on ITS use net ports, or just CRTSTY STYs? With net ports so rare, such an implementation seems rather silly. It does use a system-internal simulated TTY. That's what a STY is. That is also what a "net port" is. It's not a limitation on how many network connections there are, but on the number of system-internal simulated tty's. While I would agree that 6 may be a little too few in the case of AI, it IS a very heavily loaded machine, and there is justification for wanting to limit the number of users coming in via the network. This has nothing to do with whether CRTSTY is implemented in the reasonable way; it is.  ED@MIT-MC 11/04/79 00:09:44 Re: I don't believe this To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC DDT version 1388 runs on AI and MC. On MC, lower-case characters typed as the first thing to DDT's command loop (as in foo/ or foo , as opposed to :foo) generates an OP? error. On AI, this is not the case. Further, loading SYS;ATSIGN DDT into a job gets the same foul behavior, but doing :copy sys;atsign ddt,common;random file and then loading common;random file WINS! It seems that the pure page that's always in core is broken. Starting up several 256K jobs that referenced all their pages managed to get the offending page swapped out which fixed things. From this I gather that when a pure page is swapped, it is replaced from the original, rather than put a dupe in the swap area. Wierd.  Date: 26 OCT 1979 1212-EDT From: EB at MIT-AI (Edward Barton) To: (BUG ITS) at MIT-AI :TIME, at least, claims that ITS has been up for 19 days surpassing all previous records for uptime. That seems doubtful in view of the power situation earlier today.  Date: 26 Oct 1979 0113-EDT From: HARV at MIT-DMS (Patrick L. Harvey) To: (BUG its) at MIT-DMS Subject: BUG its Message-id: <[MIT-DMS].127634> Continuation of previous message. After I finish with the new command, I get :KILL F$J and a $P results in JOB? ...  Date: 26 Oct 1979 0111-EDT From: HARV at MIT-DMS (Patrick L. Harvey) To: (BUG its) at MIT-DMS Subject: BUG its Message-id: <[MIT-DMS].127633> Sometimes when I do a :f then ^G it inthe middle, I start typing a new command line and I get Job F finished. Is this normal behavior?  Date: 26 October 1979 01:31-EDT From: Robert W. Kerns To: RMS at MIT-AI cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC Date: 26 October 1979 00:10-EDT From: Richard M. Stallman To: BUG-DDT at MIT-AI If I type Control-Top-H at the DDT now on AI, it seems to be treatd just as an H; but rubbing it out just backspaces and doesn't erase it. DDT doesn't quite expect to get numbers bigger than 177 in response to it's IOT on a non %TIFUL channel. Other than the [HELP] character, should it? (It already expects the [HELP] character.)  ED@MIT-MC 10/24/79 00:42:03 To: (BUG ITS) at MIT-MC, (FILE [UCODE;UCODE BUGS]) at MIT-MC On MC, single-instruction proceed still loses if the instruction page faults on fetch. Doing 100/ jrst 2000 2000/ jrst 4000 ... 30000/ jrst 0 1000G 100>> JRST 2000  results in: 0>> 0 note that 0, being swapped IN, doesn't execute.  Date: 23 OCT 1979 2254-EDT From: MRC at MIT-AI (Mark Crispin) To: (BUG ITS) at MIT-AI Could AI have more STYs generated, or CRTSTY be less willing to have lots of tourist STY users, or something? Today, I was unable to get a net port because there were three tourists on, one from a dialup and two from net sites, taking up 5 out of the 6 available STYs because each was running a CRTSTY.  pae@MIT-MC (Sent by ___043@MIT-MC) 10/21/79 15:02:33 To: (BUG ITS) at MIT-MC mctty^f does not work when you are on mc.  Date: 17 October 1979 22:18-EDT From: Howard I. Cannon To: DHD at MIT-AI, BUG-ITS at MIT-AI Date: 17 OCT 1979 2112-EDT From: DHD at MIT-AI (David Hodgson Dennis) Is there any way the init files that use up almost all the file slots on users1/users2/users3 could be compacted (or the dir allocation changed)? That way, tourists who actually wanted to use storage for something other then init files (like documents or lisp programs) could do so more readily. I think this might make tourist's use of the system more productive. Would this be too hard to do? ----- Unfortunatly, the size of a directory is fixed by the system and cannot be changed. We realize that the USERSn directories get full, and there is no easy fix. Generally, it is possible to reap enough from the dirs so that they are only about 75% full, but that takes time. If the guests were more responsible about cleaning up, the problem wouldn't be so bad. Many people are on INFO-MICRO and don't read their 15 blocks of mail for three months! You should not be using the USERn dirs for anything but very short term storage because you are lucky enough to have use of a real dir on ML. If a tourist wants to be productive, (s)he can always find a way -- it's really that most of them don't particularly care.  Date: 17 OCT 1979 2112-EDT From: DHD at MIT-AI (David Hodgson Dennis) To: (BUG ITS) at MIT-AI Is there any way the init files that use up almost all the file slots on users1/users2/users3 could be compacted (or the dir allocation changed)? That way, tourists who actually wanted to use storage for something other then init files (like documents or lisp programs) could do so more readily. I think this might make tourist's use of the system more productive. Would this be too hard to do?  Date: 16 Oct 1979 (Tuesday) 1457-EDT From: OTTO at WHARTON (George Otto) Subject: Solution to previously reported C100 problems. To: bug-its at MIT-AI, geoff at SRI-KA, To: eak at MIT-MC, OTTO (George Otto) As RWK@MIT first suggested, the problem with C100 screen control turned out to be caused by the local host, Wharton, eagerly removing ^L's from its ARPAnet transmissions before sending them on the the terminal. Thus the problem in entirly local. My appologies for even HINTING that ITS could have a bug in it, and many thanks for the help I received in tracking this problem down. George Otto  Date: 16 OCT 1979 1223-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: OTTO's C100 complaints To: (BUG ITS) at MIT-MC, (BUG EMACS) at MIT-MC, geoff at SRI-KL CC: OTTO at WHARTON (Sorry for not sending this note before, but I fell asleep). I talked with OTTO last night, and he's going to talk to the TELNET maintainer at his site.  Date: 16 October 1979 12:17-EDT From: Earl A. Killian Subject: Possible solution to errors in C100 support. To: OTTO at WHARTON cc: BUG-ITS at MIT-AI, Geoff at SRI-KA How are you getting to ITS? If you're using a TELNET program I suspect the problem is that it's doing some processing on the output ITS sends. Nothing in the path from ITS to your C100 should modify a single character output. :TCTYP C100 works for other people, over the network. That's why I suspect it is a local problem. Probably an over zealous operating system turning form feeds into LFs. P.S. don't include BUG-EMACS anymore, it's not relevant here.  Date: 16 Oct 1979 (Tuesday) 0446-EDT From: OTTO at WHARTON (George Otto) Subject: Possible solution to errors in C100 support. To: geoff at SRI-KA, OTTO (George Otto) cc: bug-emacs at MIT-AI, bug-its at MIT-AI In order to examine why the :CLEAR command was not clearing the screen of my CONCEPT APL, I put the terminal into transparent mode in order to examine the characters ITS was sending down the line in response to that command. The octal sequence was as follows: 015 015 012 177 033 023 177 012 012 012 012 012 012 012 012 177 177 177 177 177 177 Among other things you should notice that there is not a single "clear screen" (^L, FF, 014) in the entire transmission! Instead we have some carraige returns (^M, CR, 015), some line feeds (^J, LF, 012), a single "clear to end of line/field" ($ ^S, ESC DC3, 033 023), and some random padding characters (DEL, 177). If all the routines in ITS send this same sequence thinking it is going to clear a screen instead of just move the cursor down 9 lines, this may explain the problems I encountered earlier. I am using the CONCEPT Reference Manual (DN1300-7808-1) and the CONCEPT Reference Card (DN1300-7810) as my documentation for this analysis, both from Human Designed Systems, Inc., 3700 Market Street, Philadelphia, Pa. 19104.  Date: 15 Oct 1979 (Monday) 2341-EDT From: OTTO at WHARTON (George Otto) Subject: Possible errors in C100 support/additional information To: bug-its at MIT-AI I have tried the solution of indicating the speed of my terminal, with no luck. Increasing the speed to 600, 1200, and finally 9600 did not change the behavior at all; in all cases the previously reported errors occurred. Some additional information may be in order: 1) The :CLEAR command does not clear the screen, but only up-spaces about 10 lines, 2) The characters which are shipped out to my terminal in response to the "TCTYP C100" command switch my terminal over to the APL character set, which I must immediatly reset to make any sense of the transmissions, 3) My terminal is a CONCEPT APL, which, as far as anybody knows, is controlled identically to the CONCEPT 100. Local programs which use cursor homing, screen clearing, cursor addressing, and line insertion and deletion all work with no difficulty using the standard CONCEPT computer-issued command set. If I can provide more information, please let me know. George Otto  Date: 15 Oct 1979 (Monday) 2337-EDT From: OTTO at WHARTON (George Otto) Subject: Possible errors in C100 support/additional information. To: geoff at SRI-KA, OTTO (George Otto) cc: bug-its at MIT-AI, bug-emacs at MIT-AI I have tried the solution of indicating the speed of my terminal, with no luck. Increasing the speed to 600, 1200, and finally 9600 did not change the behavior at all; in all cases the previously reported errors occurred. Some additional information may be in order: 1) The :CLEAR command does not clear the screen, but only up-spaces about 10 lines, 2) The characters which are shipped out to my terminal in response to the "TCTYP C100" command switch my terminal over to the APL character set, which I must immediatly reset to make any sense of the transmissions, 3) My terminal is a CONCEPT APL, which, as far as anybody knows, is controlled identically to the CONCEPT 100. Local programs which use cursor homing, screen clearing, cursor addressing, and line insertion and deletion all work with no difficulty using the standard CONCEPT computer-issued command set. If I can provide more information, please let me know. George Otto  Date: 15 Oct 1979 (Monday) 2256-EDT From: OTTO at WHARTON (George Otto) Subject: Possible errors in C100 support/padding solution To: geoff at SRI-KA, OTTO (George Otto) cc: bug-its at MIT-AI, bug-emacs at MIT-AI I will try that solution, but keep in mind that I am operating at 300 buad now. George Otto  Date: 15 Oct 1979 1943-PDT Sender: GEOFF at SRI-KA Subject: Re: Possible errors in C100 terminal support From: the tty of Geoffrey S. Goodfellow To: OTTO at WHARTON Cc: bug-its at MIT-AI, bug-emacs at MIT-AI Message-ID: <[SRI-KA]15-Oct-79 19:43:51.GEOFF> In-Reply-To: Your message of 15 Oct 1979 (Monday) 2115-EDT Reply-to: Geoff @ SRI-KA Perhaps your terminal is not getting the right amount of padding... I suggest on the same TCTYP line along with C100 you add SPEED #, i.e. as in :TCTYP C100 SPEED 9600 so the system will insert the right amount of padding (9600 baud's worth in this case). I suspect this is your most likely cause of lossage if operating over 300 baud.  Date: 15 Oct 1979 (Monday) 2115-EDT From: OTTO at WHARTON (George Otto) Subject: Possible errors in C100 terminal support To: bug-its at MIT-AI, bug-emacs at MIT-AI, To: OTTO (George Otto) I am a new user on the ARPAnet and a new user on the MIT-AI computer. I have used INFO for the past several days, using a CONCEPT 100 terminal identified via a "TCTYP C100" command. My reason for sending this note is that the screen control on my terminal has been somewhat messy. I do not know if this is due to a mistake in screen control or in the INFO program, so I thought I'd simply describe the problem and let you sort it out. When I give a command such as "INFO INTRO" the display proceeds as if on a regular TTY, i.e., the information is "painted" on the screen line by line, scrolling the terminal when the cursor hits the bottom line of the display. This usually results in "INFO docu- mentation reader" line being left on the LAST line of the display screen instead of in its usual place two lines above that. This causes problems later when the screen is being overwritten, because some display lines which are blank simply do a linefeed over the previous text, leaving it on the screen along with the newer display. Needless to say, these garbage lines make understanding of the new display somewhat difficult. Once, and this happened on a redisplay request (^L) as well, the scrolling operation was proceeding as described above when the cursor jumped into the middle of the screen and continued from there. This left a very confusing screen as a result. I think that a fair number of these problems could be removed if the screen could be cleared once in awhile. This would remove possible garbage lines and also position the screen from the top down instead of from the bottom up, thus putting everything where it was expected right off the bat. As it is, the screen is NEVER cleared. If there is anything you would like me to try on my terminal to help identify what is going on more specifically, just let me know. George Otto (OTTO@WHARTON)  Date: 15 OCT 1979 1909-EDT From: GVEO at MIT-AI (George V.E. Otto) To: (BUG ITS) at MIT-AI I would like to report some trouble with either the screen control for a C100 terminal, or the way INFO handles its display. I have the full report of the problems in a file at Wharton, so I would like to netmail the report from there. What userids should I use to mail the error report?  Date: 15 OCT 1979 1607-EDT From: OTTO@Wharton Sent-by: ___021 at MIT-AI To: (BUG ITS) at MIT-AI I have a bug to report in either screen support of a CONCEPT 100 terminal or in the way INFO handles screen control. To whom should I send a description of the problems encountered? My addresses is OTTO@WHARTON. I have an edited file containing the description of the situation which I would liklike to send via netmail to the correcdt person or persons. George Otto  BNLGHC@MIT-MC 10/15/79 15:37:22 To: (BUG ITS) at MIT-MC My TEKtronix terminal (actually a 4051) is not being handled correctly by TCTYP and/or MACSYMA. The screen is not being erased, --Continued-- overwrites --pause--, etc.  HIC@MIT-MC 10/13/79 07:57:31 Re: Chaosnet FORCE. To: ED at MIT-MC, (BUG ITS) at MIT-MC I explained the bug to ED.  ED@MIT-MC 10/13/79 05:13:00 Re: Chaosnet FORCE. To: (BUG ITS) at MIT-MC The sequence: .iot chaoch,[go away] .call [setz ? sixbit /force/ ? setzi chaoch] .close chaoch, causes the target lisp machine to go into the error handler complaining that 3 is an illegal packet opcode. Doing a .SLEEP 30. after the force and before the close wins.  EAK@MIT-MC 10/08/79 18:01:27 To: (BUG ITS) at MIT-MC How about a ^_ command to do an input reset? I.e. flush randomness you accidentally typed.  Date: 6 OCT 1979 1740-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG ITS) at MIT-AI, KLH at MIT-MC I must admit I've had the same problem. It only takes two tourists running CRTSTY to use up 2/3 of the AI STYs.  KLH@MIT-MC 10/05/79 18:37:23 To: (BUG ITS) at MIT-MC I can hardly ever read my AI mail any more. Recently I had to let it pile up for a few days because I couldn't seem to find any time when all STY's weren't being hogged (either by LM's or T's or whatever). Considering the number of LM's, I would think the # of STY's should be grossly increased, although the # of net logins could be controlled as a separate limit. True, this implies more job slots, but I've always thought more were needed anyway. I've nevver seriously considered departing AI altogether, but the situation is getting grim.  Date: 3 OCT 1979 2049-EDT From: JLK at MIT-AI (John L. Kulp) To: (BUG ITS) at MIT-AI, ARC at MIT-AI :LISTF ARC:CHAOS; ON AI GIVES ARC NO SUCH DEVICE  Date: 3 OCT 1979 0819-EDT From: GRAND at MIT-AI (Mark D. Grand) To: (BUG ITS) at MIT-AI I DON'T know if this is an oversite on sombody's part or what, but when I try to :INFO MACLISP I get OPN016 INFO ;AI:LISP > PACK NOT MOUNTED?  Date: 2 Oct 1979 2341-PDT From: Mark Crispin Subject: [PAE at MIT-MC (Philip A. Earnhardt): **more** state on the last line of the screen] To: Bug-ITS at MIT-AI Has anybody looked at this problem? I've been told that it's a bug in ITS. Any comments? --------------- Mail from MIT-AI rcvd at 2-Oct-79 2238-PDT Date: 3 OCT 1979 0103-EDT From: PAE at MIT-MC (Philip A. Earnhardt) Subject: **more** state on the last line of the screen To: (BUG TELNET) at MIT-MC, (BUG emacs) at MIT-MULTICS two times tonight, I have gotten into a **more** state in multics emacs, telnet thru mc. Once this was through invoking emacs on the next-to-last line of my screen (which I believe was a known bug) and once while doing a multics command (using ^x-^m) in my minibuffer. Does anyone know where the problem/responsibility lies with this? thanks, philip --------------- -------  MACRAK@MIT-MC 10/01/79 19:00:55 To: (BUG ITS) at MIT-MC Two problems with carriage motion optimization on printing terminals: 1. Final spaces before cr aren't flushed. 2. Sometimes--especially when printing out Macsyma expressions using backspaces and linefeeds substituting for cr's and spaces--its seems to print out some backspaces, then some spaces, then more backspaces.  Sheldon Furst @MIT-MC (Sent by ___065@MIT-MC) 09/30/79 19:33:28 To: (BUG ITS) at MIT-MC [This is Sheldon Furst (FURST)] I connected to MC, did not log in, and typed "furst$" and got the response "This person's mail is forwarded to CHNL NOT OPEN (newline) Bad file = ^Q : ^Q ; ^Q ^Q". Tried it again, and got a "Fork disconnected" or something like that, then a console free message. I don't presume this is SUPPOSED to happen, is it? -- Sheldon  KMP@MIT-MC 09/11/79 14:09:48 Re: KMP;.LOGIN 227 To: (BUG ITS) at MIT-MC My login init gives an IRRECOVERABLE DATA ERROR when I try to read it.  KMP@MIT-MC 09/11/79 14:09:48 Re: KMP;.LOGIN 227 To: (BUG ITS) at MIT-MC My login init gives an IRRECOVERABLE DATA ERROR when I try to read it.  Date: 10 SEP 1979 2324-EDT From: MOON at MIT-MC (David A. Moon) Subject: New ITS on MC has disk deadlocks To: RWK at MIT-MC CC: (BUG ITS) at MIT-MC, JPG at MIT-MC This is fixed now.  Date: 10 SEP 1979 1839-EDT From: MOON at MIT-MC (David A. Moon) Subject: New ITS on MC has disk deadlocks To: RWK at MIT-MC CC: (BUG ITS) at MIT-MC, JPG at MIT-MC I already know about this, I guess I should be more anxious about fixing it if it is happening frequently. I don't think it's a new bug, I don't understand why it happens more now. The reason you can't list the TTY directory is probably that the DDT TTY^F command probably first checks for a TTY; directory on the disk.  RWK@MIT-MC (Sent by ___042@MIT-MC) 09/10/79 07:25:59 Re: AddendumP To: (BUG ITS) at MIT-MC CC: JPG at MIT-MC When it's hung as described, you can't list the TTY directory either.  Date: 10 SEP 1979 0723-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: ___041 at MIT-MC Subject: New ITS on MC has disk deadlocks To: (BUG ITS) at MIT-MC CC: RWK at MIT-MC, JPG at MIT-MC A phenomenon we've observed repeatedly on this new system is for it to go into a mode where reading directories (for everyone trying to do so) for up to several minutes. It tends to hang repeatedly with short unhangings for quite a while, and then suddenly clear up. It tends to happen when DUMP is running, grovelling over large numbers of directories. I just saw such a state, and managed to get a little info before it unhung. The DUMP's FLSINS was SKIPG QFUD (it was hung in this, QFUD being zero). All the directories were in use (QSNUD non-zero), aparently brought in by DUMP (mostly in alphabetical order). Other jobs trying to do things and getting hung hung waiting on QSKOSW, which was locked by the DUMP frob. That's about all I could get before it spontaneously started working again.  KMP@MIT-MC 09/06/79 20:54:40 To: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC System keeps dying here on me at least. Echos all chars but doesn't do anything. T^F doesn't even work ... wierd. Any guesses? It's like everything ITS does in the way of interrupt handling works, but that's all. No jobs no ddt commands run. I detached myself from another tty and then tried to ^Z the console. Took it fully a minute or more to get it to listen. another console next door had same problem. both freed at same time. system must be hanging some obscure way.  BRIAN@MIT-ML 09/01/79 13:10:00 Re: Moving files to an archive To: (BUG ITS) at MIT-ML CC: BRIAN at MIT-ML When I try to move the file ML:BRIAN;MAIL O-COMM onto ARC MAIL, I get no error message, and the file name appears in the directory as expected, but names a file of zero length. I have had a similar problem moving another fairly large file (14 blocks) on the archive (which is about 160 blocks), but a small file got moved OK.  Date: 28 AUG 1979 0101-EDT From: ED at MIT-AI (Ed Schwalenberg) To: (BUG ITS) at MIT-AI Why is it that .CALL [SETZ ? '?_____ ? SETZM] is an ILOPR, while .CALL [SETZ ? 'FOOBAR ? SETZM] fails to skip and returns an ILLEGAL SYSTEM CALL NAME error code? I smell a crock. Of course, I deserve no better, executing randomly named system calls. On the other hand, and related to this, the .GETSYS uuo returns a list of NCALLS that includes ?_____ not once, but 200- times. This should either be fixed or documented.  Date: 26 August 1979 19:03-EDT From: Earl A. Killian To: BUG-ITS at MIT-MC, BUG-DDT at MIT-MC When I exit my EMACS and type-ahead, most of the type-ahead isn't echoed. Perhaps DDT could check the %TXPIE bit and echo the character itself if ITS didn't? Or better, maybe ITS could do this? Also, what about DDT option to use MP echoing instead of PI echoing?  Date: 26 Aug 1979 0600-EDT From: RWK at MIT-MC To: EBM at MIT-DMS, BUG-its at MIT-DMS Subject: SYS directories full Message-id: <[MIT-DMS].120744> Date: 26 August 1979 06:51-EDT From: Robert W. Kerns Subject: SYS directories full To: EBM at MIT-DMS, BUG-its at MIT-DMS Date: 25 Aug 1979 1536-EDT From: EBM at MIT-DMS (J. Eliot B. Moss) To: (BUG its) at MIT-DMS Re: BUG its :linkn ml:sys2;ts nr,r;ts nr38 fails when the link already exists, because the directory is full. This is very annoying. MC has the same problem. I think that either the system call should be fixed, or some links in those two directoris should be gotten rid of so the directories are no longer full. The real problem here is that the directory is full. DDT has long supported, and MC has long had a SYS3 directory. I think that garbage links should be GC'd, but that if a directory is available a SYS3 directory should be created on the other machines.  Date: 25 Aug 1979 1536-EDT From: EBM at MIT-DMS (J. Eliot B. Moss) To: (BUG its) at MIT-DMS Subject: BUG its Message-id: <[MIT-DMS].120688> :linkn ml:sys2;ts nr,r;ts nr38 fails when the link already exists, because the directory is full. This is very annoying. MC has the same problem. I think that either the system call should be fixed, or some links in those two directoris should be gotten rid of so the directories are no longer full.  Date: 24 AUG 1979 1343-EDT From: CFFK at MIT-MC (Charles F. F. Karney) Subject: Support of harware tabbing on printing terminal by Plot2 To: RJF at MIT-MC CC: JPG at MIT-MC, (BUG PLOT2) at MIT-MC, (BUG ITS) at MIT-MC CC: (BUG CRTSTY) at MIT-MC Most of the shortcuts taken by PLOT2 when plotting on printing terminals are in fact done by ITS. (E.g. the suppression of trailing spaces on a line, and the use of backspaces instead of return+spaces.) Support of hardware tabs by PLOT2 would similarly be best done by ITS (e.g. via a new TCTYP). If this is not done then maybe CRTSTY could do the job. (I believe CRTSTY may have some minimum requirements which rules this out.) Support of tabs by PLOT2 itself would be the least desirable because (1) nothing else (e.g. :print) would benefit, and (2) because Plot2 would have to implement ITS's other shortcuts at the same time. (However, I don't rule out the support of tabbing by PLOT2.) If ITS or CRTSTY also supported abs. curdsor positioning on daisy wheel printers, you would be able to win using Plot2 by setting PLOTMODE:DISPLAY$ An absolute requirement for the implementation of any of this by any system is an EXACT specification of the commands needed to make the tabbing/cursor positioning work.  Date: 24 Aug 1979 0201-EDT From: KDO at MIT-DMS (Ken D Olum) To: (BUG its) at MIT-DMS Subject: BUG its Message-id: <[MIT-DMS].120603> The tty input buffer is too small. If you come from a site with a line editor (SAIL) and type a full line and CR the whole line will get sent at once and overfill your buffer. I had a good time typing this message.  GJC@MIT-MC 08/21/79 21:13:08 To: (BUG ITS) at MIT-MC I was running a peek, and the system fair-share was said to be 113% at one point. This is mighty fine if it is true!  EAK@MIT-MC 08/20/79 02:57:38 To: (BUG ITS) at MIT-MC Using the .LOSE argument of .CALL DISMIS is really terribly inconvenient when the interrupt stack pointer isn't in an AC. You have you put it in one to address the return PC etc., but then you've clobbered an AC which is hard to restore...  SKH@MIT-MC 08/11/79 20:29:51 To: (BUG ITS) at MIT-MC A suggestion: Change the more handling in WHOJ, PEEK, FINGER etc. to (:PRINT) to that of DDT'S implicit more (The one that vanishes if on a display). Its annoying to see the --more-- thing stick around. The vanishing more is 700% better.  RWK@MIT-MC (Sent by KMP@MIT-MC) 08/11/79 20:24:46 To: (BUG ITS) at MIT-MC The system with the ARCHIV handler doing a .CALL FINISH for 13 hours finally crashed, due to apparently related lossage. It's dumped in MC:CRASH;QFLDF1 H/50 The immediate cause of the crash was indexing the channel tables with H being 1 larger than the largest channel table index!  Ed@MIT-MC (Sent by PAE@MIT-MC) 08/11/79 15:02:50 To: (BUG ITS) at MIT-MC Look at MC:CHANNA;_DRGN_ TIMES (and MC:CHANNA;_DRGN_ TIMES, and MC:CHANNA;_DRGN_ TIMES, and MC:CHANNA;_DRGN_ TIMES, and MC:CHANNA;_DRGN_ TIMES, and...  RWK,KMP@MIT-MC (Sent by ___021@MIT-MC) 08/11/79 06:26:36 Re: .CALL FINISH won't To: (BUG ITS) at MIT-MC CC: (BUG ARCHIV) at MIT-MC, KMP at MIT-MC There's an archive device handler here, hung in a .CALL FINISH on its disk output channel. The channel is in REAI mode according to PEEK's C mode. It's definately an output channel, so I guess PEEK must display append-mode channel's oddly. Claims its 100% read. The .CALL FINISH is at OPNOUT+16 The job's flush instruction is SKIPE QSBFS+5 The PUSHJ P,UFLS is at QOCL2+1/ SKIPE QSBFS(A) A/ 1,,5 QSBFS+5/ 1 QSCRW+5/ 0 ;Read QSRAC+5/ %QAEFR+%QAACC+%QALBK+%QAMWO,,0 QSMPRC+5/ 0 ;No bytes left in buffer I don't know what else might be relevant. I leave the job KMP JOB.06 still hanging for your inspection. KMP HACTRN is still hanging on the job to finish.  KMP@MIT-MC 08/11/79 03:12:57 To: (BUG ITS) at MIT-MC If I have a file name FOO .EXP99 and write out a new file called FOO > it seems to write to FOO .EX100 This would be ok if it weren't for the fact that if I then compile FOO >, I end up compiling FOO .EXP99 ... can this be fixed? Like maybe to open the > file, you could find all contenders (files with max number of digits, ending in a digit), strip all trailing digits, readlist the digits and compare them? -kmp  Date: 9 AUG 1979 1812-EDT From: PAE at MIT-MC (Philip A. Earnhardt) Subject: Getting thrown to DDT by :SEND To: RWK at MIT-MC CC: (BUG EMACS) at MIT-MC, (BUG ITS) at MIT-MC RWK@MIT-MC 08/09/79 05:41:16 Re: Getting thrown to DDT by :SEND If you type a ^G while a SEND is printing, DDT has control of the terminal and you'll end up in DDT. Was this perhaps the problem? no, I was just typing characters...no control chars.  RWK@MIT-MC 08/09/79 05:41:16 Re: Getting thrown to DDT by :SEND To: PAE at MIT-MC CC: (BUG EMACS) at MIT-MC, (BUG ITS) at MIT-MC If you type a ^G while a SEND is printing, DDT has control of the terminal and you'll end up in DDT. Was this perhaps the problem?  Date: 8 AUG 1979 2050-EDT From: RMS at MIT-AI (Richard M. Stallman) To: (BUG ITS) at MIT-AI, ED at MIT-AI, RWK at MIT-MC RWK@MIT-MC (Sent by ___076@MIT-MC) 08/08/79 08:46:03 It would seem that NO SUCH DEVICE is not really what's wanted. Note that if you are WRITING a file, that you want normally to go on the secondary pack, it also says "NO SUCH DEVICE". In actual fact, there IS such a device, sitting broken and unavailable. I agree. "No such device" says "what you want makes no sense", which is not true in this case.  PAE@MIT-MC 08/08/79 19:46:18 To: (BUG ITS) at MIT-MC CC: (BUG EMACS) at MIT-MC I received a message while replying to mail (using emacs rmail), kept typing at the time, and somehow got kicked out of emacs back to ddt. I didn't think there was anything that would quit an emacs like that.  RWK@MIT-MC (Sent by ___076@MIT-MC) 08/08/79 08:46:03 To: (BUG ITS) at MIT-MC CC: ED at MIT-MC It would seem that NO SUCH DEVICE is not really what's wanted. Note that if you are WRITING a file, that you want normally to go on the secondary pack, it also says "NO SUCH DEVICE". In actual fact, there IS such a device, sitting broken and unavailable.  MOON@MIT-MC 08/08/79 03:10:39 Re: SECOND: To: ED at MIT-AI CC: (BUG ITS) at MIT-MC Date: 8 AUG 1979 0201-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: SECOND: To: (BUG ITS) at MIT-AI Printing a file on SECOND: on AI these days results in NO SUCH DEVICE, when one would expect a PACK NOT MOUNTED. Is this a bug or a feature? It does give you pack not mounted. You were probably typing SECOND: and indeed there is no such device if the pack isn't mounted. But you don't need to, and usually don't, give the device name if you're just printing a file.  Date: 8 AUG 1979 0201-EDT From: ED at MIT-AI (Ed Schwalenberg) Subject: SECOND: To: (BUG ITS) at MIT-AI Printing a file on SECOND: on AI these days results in NO SUCH DEVICE, when one would expect a PACK NOT MOUNTED. Is this a bug or a feature?  Date: 5 AUG 1979 2158-EDT From: BH at MIT-AI (Brian Harvey) To: (BUG ITS) at MIT-AI How come top-/ is infinity, but shift-/ is N ? (Of course I mean the blue slash key, not the grey one.) I realize that infinity is 016 octal and so is N, but the difference seems weird to me, e.g. when typing in EMACS and getting to the next line when one wanted an infinity.  Date: 3 AUG 1979 2030-EDT From: MRC at MIT-AI (Mark Crispin) To: (BUG ITS) at MIT-AI Padding on Telerays seems to lose in EMACS with i/d mode. Are you using Pentti's algorithm yet? Telerays require lots of padding!  Date: 29 JUL 1979 1748-EDT From: KEN at MIT-AI (Kenneth Kahn) Subject: the dirar devices. To: (BUG ITS) at MIT-AI I consistently get FILE LOCKED errors when printing ken;dirar3:name1 up dirar4:name1 up dirar7:name1 up dirarc:name1 up All the other names (for example dirar5:) seemed to work fine. The archives themselves seemed fine, peek showed no one holding on to them, and just creating a link from ar0 >, to ar7 > and then printing dirar0: avoided the problem.  GSB@MIT-ML 07/27/79 17:23:55 To: (BUG ITS) at MIT-ML why doesn't PK13: work like PK3: etc.?  Date: 27 JUL 1979 1130-EDT From: RICH at MIT-AI (Charles Rich) Subject: Job slots To: (BUG ITS) at MIT-AI I know we had this argument before, but I really think that we need more job slots. With 7 Lisp machines logged in (and soon to be more), the transient average of CHAOSnet jobs had gone up noticeably, with the result that people spend half the day doing :SHOUT FLUSH JOBS! which is a nuisance. As for example, right now, there is noone logged in from the ARPA net -- just local people, none of whom are running more than a Lisp and an Emacs and maybe an occasional compiler, and there are no free job slots to run even a :MAIL (I am doing this inside EMACS, and it will probably bomb the first time I try to send it!!!!!). Sincerely, Chuck Rich.  HIC@MIT-MC 07/25/79 14:32:27 To: BYRON at MIT-ML, (BUG ITS) at MIT-ML BYRON@MIT-ML 07/25/79 09:23:54 :tcytp c100 no no longer works, but gives back ERROR: CNSSET: MEANINGLESS ARGS 270>>.CALL 3330 (CNSSSET) Also, PWORD is no longer invoked on T04 (intentional?). ------ Some turkey loaded the wrong ITS (an old version) on ML. I just reloaded the system, and all this should be fixed now.  BYRON@MIT-ML 07/25/79 09:23:54 To: (BUG ITS) at MIT-ML :tcytp c100 no no longer works, but gives back ERROR: CNSSET: MEANINGLESS ARGS 270>>.CALL 3330 (CNSSSET) Also, PWORD is no longer invoked on T04 (intentional?).  BYRON@MIT-MC 07/25/79 10:55:25 To: (BUG ITS) at MIT-MC I continually get "Host reset" messages while SUPDUPing from MC to ML. They occur about once every 5 minutes or so, and detach me as well of course.  Date: 23 JUL 1979 0251-EDT From: RMS at MIT-AI (Richard M. Stallman) To: (BUG ITS) at MIT-AI, AGRE at MIT-AI, KEN at MIT-AI I just noticed that C-N on my TV was giving me only one more line at the bottom of my screen. The code was still the old speed-dependent stuff, so I checked and found that my TV was supposed to be running at 300 baud (luckily my TV didn't know that!). Probably it should be impossible to change the speed of a TV, and :TCTYP should barf very loud at anyone who tries. This is probably the result of an unconditional :TCTYP in an init file.  Date: 20 JUL 1979 1356-EDT From: JERRYB at MIT-AI (Gerald R. Barber) Subject: Dissappearance of init files To: (BUG ITS) at MIT-AI I keep losing some of my init files for no apparent reasons, usually either my EMACS or LISP inits. Is there a way to tell when a file was deleted and by whom? Failing this is there a way to set up some sort of mechanism so that in the future I will be told who deleted one of these files.  Date: 18 JUL 1979 2044-EDT From: RWK at MIT-AI (Robert W. Kerns) To: (BUG ITS) at MIT-AI CC: (BUG DDT) at MIT-AI There seems to have been a time around 4:30 pm on the 25 of June, when all the DDT's in the world (and a PWORD too) got scrod. I'm not certain right off exactly what happened to them, but many of them seem to have gotten their PC's set to -1, probably by having the stack-pointers changed out from under them. (They seemed to be doing a TYI at the time). The PWORD definately had a PDL underflow. Something like 40 crash files were dumped at the time. There are a few saved crash files on CRASH;(first name BUGDDT) The relavent PWORD crash file is PWORD PDLHAK.  Date: 18 JUL 1979 0242-EDT From: JNC at MIT-AI (J. Noel Chiappa) To: DLW at MIT-AI CC: (BUG ITS) at MIT-AI Well, IMPUP is definitely a symbol. Sounds like the system was slowly dying away; did anybosy see any "memory changed between" messages as it went? Sounds like the kind of cumulative bit rot whose origin is almost impossible to track down.... Noel  Date: 17 JUL 1979 1823-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG ITS) at MIT-AI To add to the rash of strange reports: last night, RK tried to use TELNET on MC and fond it halting with an "ERROR;" message at a .EVAL. I examined it; the symbol in question was "IMPUP", and going into SYS$J showed that IMPUP was not a known symbol. Maybe the exec symbol table was bashed? Anyway, the system crashed shortly after this (while I was examining the problem).  KMP@MIT-MC (Sent by ___031@MIT-MC) 07/17/79 07:53:33 Re: Unreproducible errors... To: (BUG ITS) at MIT-MC CC: (BUG COMPLR) at MIT-MC I got an error from the lisp compiler just about 2 seconds before the last crash. I don't know if it is related ... ;(LOAD ((DSK LIBLSP) TTY FASL)) - NON-EXISTENT DIRECTORY which is odd because that file and dir exist and as soon as system came back up the complr did the compilation with no errors. -kmp  GSB@MIT-MC 07/11/79 00:34:43 Re: c100 padding for i&d line To: (BUG ITS) at MIT-MC CC: EAK at MIT-MC !@#%^#&!@, ML is running an ITS 3 months older than MC, and the cruft in the tty code for it doesn't look at all like the stuff in the current source... It appears to win on MC, EXCEPT THAT CLEOS DOESN'T WORK AT ALL!! (This is still at 9600 baud.) (It doesn't on ML either.)  Date: 10 July 1979 18:41-EDT From: Earl A. Killian To: GSB at MIT-MC cc: BUG-ITS at MIT-MC Date: 07/10/79 13:12:20 From: GSB at MIT-ML To: (BUG ITS) at MIT-ML Padding for the c100 is insufficient for i&d line at 9600 baud. Can anyone tell me a place i can patch to experiment? You might experiment with CRTSTY's padding at 9600 and when you find the appropriate value, try it in ITS. Patch C1LIDP+7 to multiply by different padding times (which are floating point no.s - it is currently .75E-3).  GSB@MIT-ML 07/10/79 13:12:20 To: (BUG ITS) at MIT-ML Padding for the c100 is insufficient for i&d line at 9600 baud. Can anyone tell me a place i can patch to experiment?  Date: 2 JUL 1979 1046-EDT From: APW at MIT-AI (Andrew P. Witkin) To: (BUG ITS) at MIT-AI (sorry about the incomplete msg) The bug reported by bkph -- random garbling of type in-- has also struck the datamedia in E10 (T35).  Date: 2 JUL 1979 0954-EDT From: APW at MIT-AI (Andrew P. Witkin) To: (BUG ITS) at MIT-AI T  Date: 2 JUL 1979 0845-EDT From: BKPH at MIT-AI (Berthold K.P. Horn) To: (BUG ITS) at MIT-AI What's up with the Teletype lines? Both outside (telephone) and inside (DATAPOINT & Mini-Robot) lines have very peculiar random behaviour -- garbling characters, inserting characters, dropping bits, copying several times every second letter of what was typed recently and other such randomness...  JPG@MIT-MC 06/14/79 08:48:51 To: (BUG ITS) at MIT-MC Say, this system is locking disk blocks! It just crashed, and I reloaded it from scratch. Before the crash, the number of available blocks on #0,#1,#13 respectively were 320,380,201 . (I checked this just before the crash.) After the crash, the number available was 547,552,257 + I dumped out a 171 block crash file on CRASH;. I noticed this phenomenon about 2 weeks ago when the system crashed and RWK reloaded it, and mentioned it to him, but I wasn't as certain then, so didn't report it. I wonder if this has something to do with swapping disk somehow using user blocks or whatever, and the system's marking them at high-use time getting screwed up. Whatever, something is doing this!  Date: 11 JUN 1979 2014-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: E? USR:$ To: EAK at MIT-MC, RWK at MIT-MC, (BUG ITS) at MIT-MC CC: (BUG TECO) at MIT-MC Date: 10 JUN 1979 1242-EDT From: EAK at MIT-MC (Earl A. Killian) To: RWK, (BUG ITS) cc: (BUG TECO) Re: E? USR:$ Date: 06/09/79 03:47:19 From: RWK at MIT-MC To: (BUG TECO) Re: E? USR:$ creates an inferior. It should set the bit saying to fail if the job doesn't exist. Even better would be to have the USR: device obey the same convention as the DSK: device, i.e. if you open for reading then it is an error if it doesn't exist. RWK, you said once DDT could be fixed if ITS were so changed, is that still true? Yes, it's still true.  Date: 10 JUN 1979 1242-EDT From: EAK at MIT-MC (Earl A. Killian) Subject: E? USR:$ To: RWK at MIT-MC, (BUG ITS) at MIT-MC CC: (BUG TECO) at MIT-MC Date: 06/09/79 03:47:19 From: RWK at MIT-MC To: (BUG TECO) Re: E? USR:$ creates an inferior. It should set the bit saying to fail if the job doesn't exist. Even better would be to have the USR: device obey the same convention as the DSK: device, i.e. if you open for reading then it is an error if it doesn't exist. RWK, you said once DDT could be fixed if ITS were so changed, is that still true?  JKESS@MIT-MC 06/01/79 03:02:59 Re: to whoever is maintaining the CROCKS again To: (BUG ITS) at MIT-MC and CROCK loses its center point, writing randomly. Both of these are new bugs -- CROCK ran perfectly before today...  JKESS@MIT-MC 06/01/79 03:00:58 Re: to whoever maintains the CROCKs... To: (BUG ITS) at MIT-MC DCROCK fails totally to get its digit positioning right on VT100s.