From ZVONAatMIT-AI Thu Jul 30 00:00:00 1981 From: ZVONAatMIT-AI (David Chapman) Date: 30 July 1981, 00:00 Subject: No subject Message-ID: 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. From MOON at MIT-MC Wed Jul 29 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 29 Jul 1981 00:00 Subject: VALID CLEAR OR STORED SET error Message-ID: 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. From RWKatMIT-MC Tue Jul 28 00:00:00 1981 From: RWKatMIT-MC (Robert W. Kerns) Date: 28 July 1981, 00:00 Subject: ITS listings Message-ID: 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. From GREN at MIT-MC Tue Jul 28 00:00:00 1981 From: GREN at MIT-MC (GREN at MIT-MC) Date: 28 Jul 1981 00:00 Subject: No subject Message-ID: 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. From DEVON Mon Jul 27 00:00:00 1981 From: DEVON (Devon S. McCullough) Date: 27 Jul 1981, 00:00 Subject: BUG => its Message-ID: <[MIT-DMS].205130> DM is outputting in groups af about 32 characters with 2-4 second delay betw From RWK0 at MIT-MC Sat Jul 25 00:00:00 1981 From: RWK0 at MIT-MC (RWK0 at MIT-MC) Date: 25 Jul 1981 00:00 Subject: REM's hangage Message-ID: This was the usual problem of getting a SEND via MLSLV and having the MLSLV drop dead. From ___101 at MIT-MC Sat Jul 25 00:00:00 1981 From: ___101 at MIT-MC (___101 at MIT-MC) Date: 25 Jul 1981 00:00 Subject: No subject Message-ID: 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. From MOON5atMIT-AI Sat Jul 25 00:00:00 1981 From: MOON5atMIT-AI (David A. Moon) Date: 25 July 1981, 00:00 Subject: No subject Message-ID: 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 From ZVONAatMIT-AI Thu Jul 23 00:00:00 1981 From: ZVONAatMIT-AI (David Chapman) Date: 23 July 1981, 00:00 Subject: No subject Message-ID: 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. From SWG Tue Jul 21 00:00:00 1981 From: SWG (S. W. Galley) Date: 21 Jul 1981, 00:00 Subject: [Re: DM stys] In-Reply-To: <[MIT-DMS].204538> Message-ID: <[MIT-DMS].204585> INQUIR & TTYTYP data have not yet caught up with reality, but soon they will. From PDL Tue Jul 21 00:00:00 1981 From: PDL (P. David Lebling) Date: 21 Jul 1981, 00:00 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? From PDL Tue Jul 21 00:00:00 1981 From: PDL (P. David Lebling) Date: 21 Jul 1981, 00:00 Subject: [Re: DM stys] In-Reply-To: Message of 21 Jul 81 at 0009 EDT by CSTACY@MIT-DMS 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. From CSTACY Tue Jul 21 00:00:00 1981 From: CSTACY (Christopher C. Stacy) Date: 21 Jul 1981, 00:00 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]"? From MOON at MIT-MC Mon Jul 13 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 13 Jul 1981 00:00 Subject: No subject Message-ID: 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. From WJL at MIT-ML Mon Jul 13 00:00:00 1981 From: WJL at MIT-ML (WJL at MIT-ML) Date: 13 Jul 1981 00:00 Subject: No subject Message-ID: 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 From RWKatMIT-MC Sun Jul 12 00:00:00 1981 From: RWKatMIT-MC (Robert W. Kerns) Date: Sunday, 12 July 1981, 00:00 Subject: No subject In-Reply-To: The message of 12 Jul 81 17:01-EDT from REM at MIT-MC Message-ID: REM at 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. From REM at MIT-MC Sun Jul 12 00:00:00 1981 From: REM at MIT-MC (REM at MIT-MC) Date: 12 Jul 1981 00:00 Subject: No subject Message-ID: 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. From ECG.RICH.ALAatDEC-MARLBORO Fri Jul 10 00:00:00 1981 From: ECG.RICH.ALAatDEC-MARLBORO (Alyson L. Abramowitz) Date: 10 Jul 1981, 00:00 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. -------- From Moon at MIT-MC Fri Jul 10 00:00:00 1981 From: Moon at MIT-MC (Moon at MIT-MC) Date: 10 Jul 1981 00:00 Subject: No subject Message-ID: 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. From RMSatMIT-AI Thu Jul 9 00:00:00 1981 From: RMSatMIT-AI (Richard M. Stallman) Date: 9 July 1981, 00:00 Subject: No subject Message-ID: 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. From KLOTZatMIT-AI Wed Jul 8 00:00:00 1981 From: KLOTZatMIT-AI (Leigh L. Klotz) Date: 8 July 1981, 00:00 Subject: No subject Message-ID: The home directory set in inquir, with the FILE option. With a machine name (CHURK at 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. From RICHatMIT-AI Wed Jul 8 00:00:00 1981 From: RICHatMIT-AI (Charles Rich) Date: 8 July 1981, 00:00 Subject: enquiry Message-ID: 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. From FONER at MIT-MC Sun Jul 5 00:00:00 1981 From: FONER at MIT-MC (FONER at MIT-MC) Date: 05 Jul 1981 00:00 Subject: Flakiness transferring file from AI to MC Message-ID: 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. From Margolin Mon Jul 6 02:37:00 1981 From: Margolin (Barry Margolin) Date: 5 July 1981 20:37 edt Subject: random bits Message-ID: 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. From OAFatMIT-MC Sun Jul 5 00:00:00 1981 From: OAFatMIT-MC (Oded Anoaf Feingold) Date: 5 July 1981, 00:00 Subject: AI Arpanet problems Message-ID: 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 From MOON5atMIT-AI Sun Jul 5 00:00:00 1981 From: MOON5atMIT-AI (David A. Moon) Date: 5 July 1981, 00:00 Subject: AI Arpanet problems (p.s.) Message-ID: I forgot to say in my previous message that the problems are believed to be entirely in the host-to-IMP direction. From MOON5atMIT-AI Sun Jul 5 00:00:00 1981 From: MOON5atMIT-AI (David A. Moon) Date: 5 July 1981, 00:00 Subject: AI Arpanet problems Message-ID: 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. From MOONatMIT-MC Sat Jul 4 00:00:00 1981 From: MOONatMIT-MC (David A. Moon) Date: 4 July 1981, 00:00 Subject: not more CHAOS lossage Message-ID: 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. From DCPatMIT-MC Sat Jul 4 00:00:00 1981 From: DCPatMIT-MC (David C. Plummer) Date: 4 July 1981, 00:00 Subject: more CHAOS lossage Message-ID: 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. From SKatMIT-MC Fri Jul 3 00:00:00 1981 From: SKatMIT-MC (Steven T. Kirsch) Date: 3 July 1981, 00:00 Subject: The DDT prompt went away a couple of days ago on MC... Message-ID: 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. From CSTACYatMIT-AI Wed Jul 1 00:00:00 1981 From: CSTACYatMIT-AI (Christopher C. Stacy) Date: 1 July 1981, 00:00 Subject: net interface problems? losing bits Message-ID: 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 From HICatMIT-MC Wed Jul 1 00:00:00 1981 From: HICatMIT-MC (Howard I. Cannon) Date: 1 July 1981, 00:00 Subject: AI Imp Interface Message-ID: 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. From MMCMatMIT-AI Wed Jul 1 00:00:00 1981 From: MMCMatMIT-AI (Mike McMahon) Date: 1 July 1981, 00:00 Subject: No subject Message-ID: I have renamed the server ftp to prevent incoming mail from being garbaged. From ECCatMIT-AI Wed Jul 1 00:00:00 1981 From: ECCatMIT-AI (Eugene C. Ciccarelli) Date: 1 July 1981, 00:00 Subject: Network interface problems Message-ID: 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. From PDL Wed Jul 1 00:00:00 1981 From: PDL (P. David Lebling) Date: 1 Jul 1981, 00:00 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 From KLOTZatMIT-AI Wed Jul 1 00:00:00 1981 From: KLOTZatMIT-AI (Leigh L. Klotz) Date: 1 July 1981, 00:00 Subject: No subject Message-ID: 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. From PDL Wed Jul 1 00:00:00 1981 From: PDL (P. David Lebling) Date: 1 Jul 1981, 00:00 Subject: BUG => its Message-ID: <[MIT-DMS].202891> Typically the aforementioned MLDEVs .VALUE at NTDI+14 with c/ 1000 and d/ 400 From EAKatMIT-AI Wed Jul 1 00:00:00 1981 From: EAKatMIT-AI (Earl A. Killian) Date: 1 July 1981, 00:00 Subject: No subject Message-ID: 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.