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: 23 January 1985 23:47-EST From: Alan Bawden Subject: Tempest in a TELSER. To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, DANIEL @ MIT-MC In-reply-to: Msg of 23 Jan 1985 17:42-EST from Alan Bawden Date: 23 January 1985 17:42-EST From: Alan Bawden ... I plan to fix the timeout algorithm to close the connection after it sees the STY idle twice in a row. That, and a check every 15 seconds, should assure you of at -least- 15 seconds (but not more than 30) before closing the connection.... Ok I did this. Actually I did it with a 20 second timeout. Thus, you now get at least 20 seconds, at most 40 seconds, and an average of 30 seconds. A reason to want a longer timeout is to give the TELSER's single page a chance to swap out and stay out. This probably doesn't matter much on MC but it might help a bit on AI. An alternative solution, that would take a few more lines of code, would be for TELSERs to keep a USR: channel open to the toplevel job on the other end of the STY. Then they would get an interrupt when that job went away, indicating some kind of interesting job manipulation was taking place on the other side. Unfortunately nothing would happen if the tree was just detached, foo.  Date: 23 January 1985 17:42-EST From: Alan Bawden Subject: Tempest in a TELSER. To: DANIEL @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 22 Jan 1985 19:39-EST from Daniel Weise Date: 22 January 1985 19:39-EST From: Daniel Weise Why is MC suddenly breaking supdup connections when I log out? I prefer the behavior where I have to manually break the connection. 'Cause we are experimenting with adjusting the timeout to different values. Currently it is patched to be 15 seconds. For years it has been set at 5 minutes. I think we are all agreed that the current setting is a loser. I plan to fix the timeout algorithm to close the connection after it sees the STY idle twice in a row. That, and a check every 15 seconds, should assure you of at -least- 15 seconds (but not more than 30) before closing the connection. Unless anybody would like to object or propose anything else?  Date: 22 January 1985 19:39-EST From: Daniel Weise To: BUG-ITS @ MIT-MC Why is MC suddenly breaking supdup connections when I log out? I prefer the behavior where I have to manually break the connection.  Date: 22 January 1985 14:35-EST From: Alan Bawden Subject: TELSER timeout To: CBF @ MIT-MC, CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC The current timeout is definitely too short. MC has hung up on me instantly a couple of times in the last few days. Perhaps the code should be fixed to log itself out only if it sees the STY idle twice in a row.  Date: 20 January 1985 19:33-EST From: Alan Bawden Subject: Page fault caused by .GETSYS To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC In-reply-to: Msg of 19 Jan 1985 17:07-EST from Kent M Pitman Date: 19 January 1985 17:07-EST From: Kent M Pitman MC died claiming: Page fault in system at 304000,,130422 This has been happening on and off for quite some time. .GETSYS would sometimes cause a seemingly spurious page fault. I introduced this bug myself last summer and I just fixed it in the source. Sure feels good to delete some of those crash dumps knowing that you actually fixed the problem!  Date: 20 January 1985 10:46-EST From: Christopher C. Stacy Subject: Closing net connections when your STY goes away To: CBF @ MIT-MC cc: BUG-ITS @ MIT-MC, MRC @ SU-SCORE In-reply-to: Msg of 18 Jan 1985 22:42-EST from Charles Frankston Five minutes is admittedly a long time. I think I would be happy if it were one half minute, I think (15 seconds might be OK, but I want to be more gracious). If no one responds to CBF's query in a few days, I'll change it in the source.  Date: 20 January 1985 10:44-EST From: Christopher C. Stacy Subject: HSNAME change To: ALAN @ MIT-MC cc: BRUC @ MIT-MC, BUG-DDT @ MIT-MC, BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC, USER-ACCOUNTS @ MIT-MC In-reply-to: Msg of 19 Jan 1985 02:35-EST from Alan Bawden I fixed this (right this time).  Date: 19 January 1985 17:07-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC MC died claiming: Page fault in system at 304000,,130422 BugPC/ PFA3+2 I dumped this to CRASH;PFA3+2 19-JAN and cold booted. -kmp  Date: 19 January 1985 02:35-EST From: Alan Bawden Subject: HSNAME change To: CSTACY @ MIT-MC, KMP @ MIT-MC, BUG-INQUIR @ MIT-MC cc: USER-ACCOUNTS @ MIT-MC, BRUC @ MIT-MC, BUG-DDT @ MIT-MC, TAFT @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 18 Jan 1985 23:48-EST from Robert E. Bruccoleri Date: 18 January 1985 23:48-EST From: Robert E. Bruccoleri My home directory was changed from USERS0; to GUEST0; recently without the relocation of my files or the redirection of my mail.... Date: 18 January 1985 23:59-EST From: Kent M Pitman INQUIR seems to give people with a "Z" designation (clinical decision making group) a GUESTn home dir if they don't have a home dir of their own. This is arguably a bug.... Earlier the same day.... Date: 18 January 1985 09:26-EST From: Christopher C. Stacy Subject: AI file directories To: BUG-INQUIR at MC cc: BUG-DDT at MC, BUG-ITS at MC, KMP at MC, TAFT at MC Enough occasional and small users from AI use MC now that I was getting tired of using INQUIR to manually force their home directory to be AI0. This morning I taught INQUIR that if an "A" person comes along who does not have a directory, it will automatically stick them in AI0 (rather than USERSn). Of course, if AI0 starts getting too full due to many people, we can make more dirs. But I don't think that's too likely since most AI people with alot of files have their own directory and don't need to use AI0. Well, more than just AI users seem to have their directories changed, so I retracted the new version of LSRTNS, reassembled DDT (being careful to increment the version number this time) and installed it. The buggy ATSIGN DDT was renamed to be ATSIGN XDDT.  Date: 18 January 1985 22:42-EST From: Charles Frankston Subject: Closing net connections when your STY goes away To: CSTACY @ MIT-MC, MRC @ SU-SCORE cc: BUG-ITS @ MIT-MC Well, I think the current timeout is kind of long, so I have temporarily patched it to 15 seconds instead of 5 minutes. If anyone remembers why it was 5 minutes, I'd be interested in knowing. This will also help free up STYs faster for those times when the system is heavily loaded.  Date: 18 January 1985 17:35-EST From: Christopher C. Stacy Subject: TAC binary mode To: MRC @ SU-SCORE cc: BUG-ITS @ MIT-MC In-reply-to: Msg of Fri 18 Jan 85 09:25:48-PST from Mark Crispin Foo. We like it waiting for me to type "^Z", rather than gratitously disconnecting. As for decisions being cast in stone, I just happen to think it is the right decision (and the users and other programmers here concur.) If you re-read my message, I did suggest that perhaps there should be a way for users to ask to be disconnected upon logout. By the way, when coming in over the net I myself turn on binary mode in my login init file so that I can use the META key on my home terminal. Since I run a program (:TBMOFF) in my logout init file which turns it back off, I never get wedged.  Date: Fri 18 Jan 85 09:25:48-PST From: Mark Crispin To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Fri 18 Jan 85 03:06:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bullshit. The connection was *not* in a wedged state. It was waiting for me to type CTRL/Z to start another ITS job. I deliberately typed @ B I S because I wanted a binary link without the TAC intercept character interfering. The last thing I want when I am logged in to a host is to have the damn Tip (be it Internet, Chaos, Pup, DECnet, or whatever) decide to grab one of my characters as an intercept character. I know damned well how to change the intercept character, but with the advent of certain display editors which use all 128 ASCII characters for commands there is NO "safe" intercept character. One of the reasons why ITS in the old days was so great was that the system programmers of that time didn't consider the decisions of the past to be enshrined in stone and unchangable. -------  Date: 18 January 1985 09:26-EST From: Christopher C. Stacy Subject: AI file directories To: BUG-INQUIR @ MIT-MC cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC Enough occasional and small users from AI use MC now that I was getting tired of using INQUIR to manually force their home directory to be AI0. This morning I taught INQUIR that if an "A" person comes along who does not have a directory, it will automatically stick them in AI0 (rather than USERSn). Of course, if AI0 starts getting too full due to many people, we can make more dirs. But I don't think that's too likely since most AI people with alot of files have their own directory and don't need to use AI0.  Date: 18 January 1985 06:06-EST From: Christopher C. Stacy Sender: CSTAC0 @ MIT-MC To: MRC @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 17 Jan 1985 21:58-EST from Mark Crispin Come on, the bug is clearly in your user host which stopped paying attention to you. Closing your connection is just one thing which it prevented you from doing by putting you into a wedged state. It is a feature that ITS does not close connections when you log out. Maybe there should be a :LOGOUT option to force your connection closed though, for people who want this.  Date: 17 January 1985 23:10-EST From: Richard M. Stallman To: BUG-ITS @ MIT-MC I always find it unpleasant when OZ breaks connections with me just because I log out.  Date: 17 January 1985 21:58-EST From: Mark Crispin To: BUG-ITS @ MIT-MC I wish ITS closed the connection when you logged out. It is easier to re-open the connection if you want it than it is to extract yourself from a host which won't hang up when you log out. I had to gun my TELSER to get out of a @B I S connection from the TAC.  Date: 17 January 1985 15:06-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC MC's network terminals and the (AAA) next to the system console and such stopped responding. The system console seemed to be happy, so I ran :.;BOOT11 from there and things seem happy again.  Date: 11 January 1985 19:37-EST From: Leigh L. Klotz To: TAR @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC In-reply-to: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ Date: 9 January 1985 15:48-EST From: Thomas A. Russ Sender: TAR0 To: BUG-ITS :CHUNAME doesn't work. It prints the "-- Massacre and Reset --" question, but when I type , it responds with a single question mark ("?") and does nothing. Probably you, in your incarnation as TAR0, were trying to :CHUNAM to TAR, but there already was a TAR, possibly detached. DDT was informing you in its usual terse fashion, (which has saved us at last count over 2^23 character output calls since ITS was first booted).  Date: 10 January 1985 01:23-EST From: Howard D. Trachtman Subject: archives To: BUG-ITS @ MIT-MC cc: HDT @ MIT-MC, CSTACY @ MIT-MC It also seems to me that control-Zing out of writing a file in emacs and proceeding consitently leaves a Jjob in my name, but which doesn't seem to get restarted in a manner capable of finishing the write.  Date: 9 January 1985 23:12-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC cc: HDT @ MIT-MC When an archive device dies maybe it should return device not available or if it was because of size limitations, device full.  Date: 9 January 1985 16:04-EST From: Christopher C. Stacy To: TAR @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC In-reply-to: Msg of 9 Jan 1985 15:48-EST from Thomas A. Russ Date: 9 January 1985 15:48-EST From: Thomas A. Russ Sender: TAR0 To: BUG-ITS :CHUNAME doesn't work. It prints the "-- Massacre and Reset --" question, but when I type , it responds with a single question mark ("?") and does nothing. This would probably be a DDT bug, not an ITS bug. :CHUNAME works fine for me. Please send a real bug report, specifying the input you gave the function.  Date: 9 January 1985 15:48-EST From: Thomas A. Russ Sender: TAR0 @ MIT-MC To: BUG-ITS @ MIT-MC :CHUNAME doesn't work. It prints the "-- Massacre and Reset --" question, but when I type , it responds with a single question mark ("?") and does nothing.  Date: 4 January 1985 19:48-EST From: Ken Harrenstien Subject: Tape archives To: greif @ MIT-XX cc: BUG-ITS @ MIT-MC How much tape are you actually talking about flushing? I doubt you plan to re-use the tapes; therefore it must just be the storage requirements that you object to. But tapes don't take up much room at all (depending on how you chose to store them), and even if there is only one file on each tape which is worth keeping, it is still much easier to simply keep that tape than to try to achieve any kind of compaction. I don't think any ITS tapes should be junked unless a large majority of ITS users thinks it is reasonable. There just is no way to predict which files you will someday be interested in retrieving, and once they are flushed, they are gone forever. The ITS systems have vastly more historic significance than MIT-XX, or in fact most other computer systems on the network, and this should be a consideration. Incidentally, the notion of taking a complete file system dump and locking it away for backup, archival, or posterity is considered a good idea in other places as well. We do this on SRI-NIC, for example. Perhaps you are just doing it too often.  Date: 4 January 1985 01:21-EST From: Pandora B. Berman Subject: amazing brain damage To: BUG-ITS @ MIT-MC irene grief has apparently gotten the idea into her head that flushing all old ITS tapes up to six months ago is not only feasible but a good idea. see CENT;LCS TAPES for details.  Date: 2 January 1985 15:14-EST From: Christopher C. Stacy Subject: hangup To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC In-reply-to: Msg of 2 Jan 1985 14:15-EST from Alan Bawden Date: 2 January 1985 14:15-EST From: Alan Bawden In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy Ah! So perhaps the hangup detection is busted on some line? Did you experiment to see if it was a repeatable failure? Which line did this happen on? Unfortunately, I was running out the door at the time and didn't remember to check which dialup line I was on until it was too late. I suspect that it was T04. I suppose we could check the console log. Mostly I sent the message to make sure that other people thought that hangup detection is really supposed to work on all the lines we have. It doesn't work on the ROLM lines though, does it?  Date: 2 January 1985 14:15-EST From: Alan Bawden To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC In-reply-to: Msg of 2 Jan 1985 09:44-EST from Christopher C. Stacy Date: 2 January 1985 09:44-EST From: Christopher C. Stacy Date: 1 January 1985 20:05-EST From: Alan Bawden Date: 1 January 1985 15:55-EST From: Sydney E. Atkinson hanging up a dialup line does not log you out. It shouldn't. People shouldn't lose the contents of their editor buffers just because they tripped over the phone cord. Hanging up a dialup line detaches your job tree so that you can dial in again and reattach to it (or gun it down if it was wedged in some way). Have you observed some behavior other than this? The job was not detached either: it was left sitting there for at least five minutes, and when I dialup up the same line I was already logged in to SGA's session. Ah! So perhaps the hangup detection is busted on some line? Did you experiment to see if it was a repeatable failure? Which line did this happen on?  Date: 2 January 1985 09:44-EST From: Christopher C. Stacy To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, SGA @ MIT-MC In-reply-to: Msg of 1 Jan 1985 20:05-EST from Alan Bawden Date: 1 January 1985 20:05-EST From: Alan Bawden To: SGA cc: BUG-ITS In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson Date: 1 January 1985 15:55-EST From: Sydney E. Atkinson hanging up a dialup line does not log you out. It shouldn't. People shouldn't lose the contents of their editor buffers just because they tripped over the phone cord. Hanging up a dialup line detaches your job tree so that you can dial in again and reattach to it (or gun it down if it was wedged in some way). Have you observed some behavior other than this? The job was not detached either: it was left sitting there for at least five minutes, and when I dialup up the same line I was already logged in to SGA's session.  Date: 1 January 1985 20:05-EST From: Alan Bawden To: SGA @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 1 Jan 1985 15:55-EST from Sydney E. Atkinson Date: 1 January 1985 15:55-EST From: Sydney E. Atkinson hanging up a dialup line does not log you out. It shouldn't. People shouldn't lose the contents of their editor buffers just because they tripped over the phone cord. Hanging up a dialup line detaches your job tree so that you can dial in again and reattach to it (or gun it down if it was wedged in some way). Have you observed some behavior other than this?  Date: 1 January 1985 15:55-EST From: Sydney E. Atkinson To: BUG-ITS @ MIT-MC hanging up a dialup line does not log you out.  Date: 26 December 1984 22:57-EST From: David A. Moon Subject: How to take a dump of a machine that had been running? To: KMP @ MIT-MC cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC Date: Mon, 24 Dec 84 22:12 EST From: Kent M Pitman I hit Break and got to KLDCP. Then I said SP. When I tried to do DDT, it said it was in User Mode and that I had to do MR first. This is pretty dumb of KLDCP. SP is "stop" and DDT is "start at the start address of DDT, which is stashed in a location in low memory somewhere." I don't know why KLDCP can't switch from user mode to exec mode itself. I wasn't sure if that would destroy the useful state needed to do the dump. So I just hit the disk button on the machine and ran a full boot. Certainly MR will destroy less state than cold-booting from the disk button! MR (stands for master reset) probably loses at most the contents of the accumulators, and maybe not even that. Aside: it's a pity the designers of the pdp-11 front end for the KL10 never bothered to look at the software that runs on the pdp-10 for their user-interface ideas. I'm certainly glad I didn't take that job when it was offered to me! End of history lesson. Would the right thing to do have been to say MR, DDT, then dump it from there? I think so. Actually, a better approach would have been to continue the machine (I forget the two-letter abbreviation for that) then raise switch zero (the switch zero on the left). If it's in user mode it's probably scheduling periodically, and if it's scheduling periodically switch zero will get you to DDT in a clean state to take a dump. I'm not at all clear on what the various states of the machine are here... so I didn't know if I'd just be wasting my time trying to do something I really know nothing about. If I had any reason to think it would have worked, I'd have given it a shot. So let me know if it was the right thing (or what would have been) and next time I'll try it. -kmp It never hurts to take a dump, in my opinion.  Received: from MIT-FRANK-SINATRA by MIT-OZ via Chaosnet; 24 Dec 84 22:10-EST Date: Mon, 24 Dec 84 22:12 EST From: Kent M Pitman Subject: How to take a dump of a machine that had been running? To: KLH@MIT-MC.ARPA Cc: BUG-ITS@MIT-MC.ARPA I hit Break and got to KLDCP. Then I said SP. When I tried to do DDT, it said it was in User Mode and that I had to do MR first. I wasn't sure if that would destroy the useful state needed to do the dump. So I just hit the disk button on the machine and ran a full boot. Would the right thing to do have been to say MR, DDT, then dump it from there? I'm not at all clear on what the various states of the machine are here... so I didn't know if I'd just be wasting my time trying to do something I really know nothing about. If I had any reason to think it would have worked, I'd have given it a shot. So let me know if it was the right thing (or what would have been) and next time I'll try it. -kmp  Date: 24 December 1984 21:45-EST From: Ken Harrenstien Subject: MC being down today To: KMP @ MIT-MC cc: BUG-ITS @ MIT-MC Normally the best thing to do with a dead or comatose system is dump it, so that the corpse can be examined later.  Date: 24 December 1984 16:12-EST From: Kent M Pitman Subject: MC being down today To: BUG-ITS @ MIT-MC Poor MC had 0 free pages in low core since early this morning and wasn't doing anyone any good (wouldn't let anyone log in, etc). So I just reloaded it, which seemed to work fine. Sorry I didn't have any idea what kind of debugging info to offer since the machine was still running and other than 10,000 warnings about being out of free pages, it had nothing to say for itself. If there's debugging data I could have taken from KLDCP, please let me know and I'll get it next time if it loses this way again. -kmp  Date: Sun, 23 Dec 1984 10:59 EST Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: Peter Szolovits Cc: BUG-ITS@MIT-MC Subject: Heath 19 terminal control codes In-reply-to: Msg of 22 Dec 1984 15:54-EST from Peter Szolovits This was the right place. Either I'll answer you next time I'm on MC, or you can look at the strings in SYS; TS3TTY > if you feel brave. Yes, it does use ANSI mode, but only for multiple line/char insert/delete. So does CRTSTY.  Date: 22 December 1984 15:54-EST From: Peter Szolovits Subject: Heath 19 terminal control codes To: BUG-ITS @ MIT-MC cc: PSZ @ MIT-MC I would like to find out what the complete set of terminal commands is that ITS sends to terminals that it thinks are H19's. In particular, I know that some commands from the ANSI set are used as well as the "standard" Heath command set. The Kermit H19 emulator doesn't support $[nP and $[?2h, for example (though it does support $[nM and $[nL for vertical scrolling), and I'd like to find out what such commands would need to be added to Kermit to make it useable on MC. Sorry if this is the wrong mailing list.  Date: 22 December 1984 10:19-EST From: Christopher C. Stacy Subject: obscure bug in trivial feature To: BUG-ITS @ MIT-MC In-reply-to: Msg of 22 Dec 1984 02:52-EST from Christopher C. Stacy OK, the SYSDSK thing works now.  Date: Sat 22 Dec 84 03:58:10-EST From: J. Noel Chiappa Subject: MC busted, fixed To: ann@MIT-XX.ARPA cc: bug-its@MIT-MC.ARPA, JNC@MIT-XX.ARPA MC croaked last this evening with a busted +20V brick in the power supply. Not wanting the machine to be down forever, I replaced it. Can you please cause DEC to replace the busted one (sitting on top of the processor) with a fixed one and get that back to me? This may explain some of the problems MC was having recently with it halting after repetitively flashing the lights and not saying anything. The power supply was for the memory in the front end; the bootstrap ROM was seeing the disk controller get a NXM on a test transfer to 0. Noel -------  Date: 22 December 1984 02:57-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I think the SYSDSK code is probably mostly bankrupt. I noticed it not quite working the other day, and so there are some changes in it now, and it works a little better. Oh, well.  Date: 22 December 1984 02:52-EST From: Christopher C. Stacy Subject: obscure bug in trivial feature To: BUG-ITS @ MIT-MC SYSDSK is not called from QSOCL3 when a :MOVE happens since the input channel's file names are not looked at (and the output file is in another directory).  Date: 22 December 1984 02:52-EST From: Christopher C. Stacy Subject: obscure bug in trivial feature To: BUG-ITS @ MIT-MC SYSDSK is not called from QSOCL3 when a :MOVE happens since the input channel's file names are not looked at (and the output file is in another directory).  Date: 11 December 1984 19:05-EST From: Glenn S. Burke Subject: highly secure systems To: bug-swelling-itching-brain cc: BUG-ITS @ MIT-MC Whoever brought up ML didn't notice that it didn't know the time. Of course, said culprit probably was more familiar with the current software running there than I, so knew that there was no point. You see, you aren't allowed to get a ddt if the system doesn't know the time. Running pdset becomes a bit difficult.  Date: 9 December 1984 21:10-EST From: Alan Bawden Subject: 7LP: To: INFO-ITS @ MIT-MC cc: BUG-ITS @ MIT-MC I have installed a 7LP: device on MC and ML for using the LN01 printer on the 7th floor to generate simple hardcopy. Outputting to 7LP: opens a connection to PREP (where the spooler runs) and transmits your text. For example :COPY DSK:ALAN;ALAN LOGIN,7LP: makes hardcopy of my init file. Reading from 7LP:.FILE. (DIR) produces a listing of the queue on PREP, so you can type 7LP to DDT to see who's output is in front of yours.  Date: 8 December 1984 14:43-EST From: Alan Bawden Subject: Not about: RU-BLUE To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC, GSB @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ In-reply-to: Msg of 8 Dec 1984 07:38-EST from Ken Harrenstien Date: 8 December 1984 07:38-EST From: Ken Harrenstien ... the binary-compare feature to SRCCOM ... Oh yeah, I forgot about that feature! I used it a couple of times to compare KS microcode load files when I made trivial changes that theoretically changed only a single microinstruction. I must say, however, that I have never had very much luck applying it to midas BIN files. There always seems to be something you forget that causes all of the constants to move. I guess its worth trying again in this case. I can only think of two non-KS changes that have been made since I started, commenting one of them out (a trivial fix) should cause everything to assemble into the same places, I -think-...  Date: 8 December 1984 07:38-EST From: Ken Harrenstien Subject: RU-BLUE To: ALAN @ MIT-MC cc: GSB @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ Alan, would you believe that I added the binary-compare feature to SRCCOM just so that I could quickly verify that ITS still assembled into the same thing while I was adding all the NET/INET/TCP conditionals? It was pretty handy, too. Anyway, the same technique might work for ensuring that your own changes don't affect the KA/KL version of ITS.  Date: 8 December 1984 01:18-EST From: Alan Bawden Subject: BOJ device .UAI mode SIOT To: BUG-ITS @ MIT-MC An IOT on a BOJ channel open for input in block mode will return with the input pointer not fully counted out when the user closes his JOB channel. A SIOT on a BOJ channel open for input in unit ascii mode will simply hang forever if the user closes his JOB channel before the byte count becomes 0. The block mode behavior is what I would expect by analogy with reaching the end of a file.  Date: 6 December 1984 14:00-EST From: Alan Bawden Subject: RU-BLUE To: GSB @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC, Bug-MAIL @ MIT-OZ, MARTY @ MIT-OZ In-reply-to: Msg of 6 Dec 1984 02:34-EST from Glenn S. Burke Date: 6 December 1984 02:34-EST From: Glenn S. Burke Date: Thu, 6 Dec 84 00:02 EST From: "Christopher C. Stacy" ... I bet that ML has obsolete Internet routing tables for finding someone to ask about the gateway to net 128.6.xx.aa. ML is also probably unable to reach random other hosts. I'll fix this eventually. Seems to me that we should make the most of ml's existence while it still exists; it does arpa/chaos fairly well, after all. It has been 50 days since it's been booted, and i think it has had one parity stop and one random retryable disk error stop in that time. I forget how long it had been up before this uptime binge, but i think that too was a record. CStacy's observation about routing tables is correct. ML is running an ancient version of ITS without Moon's fix to that code. If we really want to make the most of ML, we should assemble a more modern version for it. Of course I have made a great number of edits to the source of ITS in the last few months, many having to do with the KA/KL conditionalizations, so there is no guarantee that an ITS assembled from the current sources will actually represent any improvements. (I have tried to make sure the binaries for the KA and KL didn't change, but...)  Date: 6 December 1984 02:34-EST From: Glenn S. Burke Subject: RU-BLUE To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC, DEVON @ MIT-MC, MARTY%MIT-OZ @ SCRC-STONY-BROOK, Bug-MAIL%MIT-OZ @ SCRC-STONY-BROOK Date: Thu, 6 Dec 84 00:02 EST From: "Christopher C. Stacy" BUG-MAIL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA In-reply-to: Date: 5 Dec 1984 22:49 EST (Wed) From: Martin David Connor I removed ML from the places that mail can be forwarded by. (DOMAINS.TXT). I know that RU-BLUE is up and often send mail there. MC can also reach RU-BLUE fine. ML is running the same mail software and has the same host tables. I bet that ML has obsolete Internet routing tables for finding someone to ask about the gateway to net 128.6.xx.aa. ML is also probably unable to reach random other hosts. I'll fix this eventually. Seems to me that we should make the most of ml's existence while it still exists; it does arpa/chaos fairly well, after all. It has been 50 days since it's been booted, and i think it has had one parity stop and one random retryable disk error stop in that time. I forget how long it had been up before this uptime binge, but i think that too was a record.  Date: Thu, 6 Dec 84 00:02 EST From: "Christopher C. Stacy" Subject: RU-BLUE To: Martin David Connor Cc: Bug-MAIL%MIT-OZ@SCRC-STONY-BROOK.ARPA, BUG-ITS@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA In-reply-to: Date: 5 Dec 1984 22:49 EST (Wed) From: Martin David Connor I removed ML from the places that mail can be forwarded by. (DOMAINS.TXT). I know that RU-BLUE is up and often send mail there. MC can also reach RU-BLUE fine. ML is running the same mail software and has the same host tables. I bet that ML has obsolete Internet routing tables for finding someone to ask about the gateway to net 128.6.xx.aa. ML is also probably unable to reach random other hosts. I'll fix this eventually.  Date: Mon 26 Nov 84 20:22:20-EST From: J. Noel Chiappa Subject: Re: MC hardware To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA cc: FINN@MIT-XX.ARPA, TY@MIT-XX.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Sun 25 Nov 84 11:51:00-EST I guess I'd consider this a non-optimal move. Since we have a modest maount of memory on the machine now, I don't think it such a big lose to switch off 25% of the memory until DEC can look at it. There is some possibility that they aren't confused when they say they are hot. Noel -------  Date: 25 November 1984 11:51-EST From: Christopher C. Stacy Subject: MC hardware To: BUG-ITS @ MIT-MC cc: FINN @ MIT-XX, TY @ MIT-XX On MC: memory boxes B and C are only online because their override switches are on. They are too hot, I think.  Date: Fri, 23 Nov 84 20:46 EST From: "Christopher C. Stacy" Subject: NITS? To: Alan Bawden Cc: BUG-ITS@MIT-MC.ARPA In-reply-to: The message of 23 Nov 84 13:17-EST from Alan Bawden Someone turned the card over accidently I guess.  Date: 23 November 1984 13:17-EST From: Alan Bawden Subject: NITS? To: BUG-ITS @ MIT-MC The Very Small Bulletin Board on MC told me to load NITS, but there isn't any such file. I turned the card around to say just ITS which does exist. I hope that this only means that thhe card was wrong and not that someone accidentally deleted the system we are supposed to be running.  Date: 16 November 1984 03:09-EST From: Alan Bawden Subject: ROLM lines To: BUG-ITS @ MIT-MC I just edited the TTYTYP file to remove the %TYMDM bits from all of the ROLM lines. Experiment reveals that MC never seems to get told when such a line is reconnected to a new terminal, thus setting this bit causes MC to remember old, sometimes incorrect, terminal type information. Removing the %TYMDM bits should cause ITS to reset the terminal type information whenever the tty becomes free. This is better than the current situation, where a user can be seriously confused, but since the ROLM -must- be able to do this correctly, someone should really be looking into fixing it.  Date: 6 November 1984 15:48-EST From: Alan Bawden Subject: ITS Uptime Server? To: MARTY @ MIT-OZ cc: BUG-ITS @ MIT-MC In-reply-to: Msg of Tue 6 Nov 84 11:36-EST from Martin David Connor Date: Tue 6 Nov 84 11:36-EST From: Martin David Connor Could someone implement an UPTIME chaos server for ITS? Done.  Date: Tue 6 Nov 84 11:36-EST From: Martin David Connor Subject: ITS Uptime Server? To: BUG-ITS@MIT-MC Could someone implement an UPTIME chaos server for ITS?  Date: 4 November 1984 14:42-EST From: Alan Bawden Subject: I just checked and he isn't blue... To: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC Every once in a great while when I log in I discover that %TOMOR is not set in my TTYOPT word. Since my LOGIN does nothing to change the default setting of more processing it must be the case that normally ITS or DDT (or PWORD?) turns it on. Well sometimes, given a blue Moon or something, it must fail to work...  Date: 30 October 1984 13:12-EST From: Alan Bawden To: STORY @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 30 Oct 1984 11:46-EST from Kenneth Byrd Story Date: 30 October 1984 11:46-EST From: Kenneth Byrd Story To: BUG-DDT I keep getting logged-out automatically by mc; what's the problem? Well, as far as I know nothing on ITS ever causes you to be "logged-out automatically". What exactly were the symptoms? Did you get a message like: "Top level interrupt, tree detached"? Did you just get "MC ITS 1382 Console XX Free. HH:MM:SS"? When you reconnected did DDT offer to reattach you to a detached tree or tell you that you had dead detached trees? How were you reaching MC? (ROLM? Dialup? Chaosnet?)  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 116836; Sun 28-Oct-84 17:38:27-EST Date: Sun, 28 Oct 84 17:38 EST From: "David A. Moon" Subject: Getting Detached from MC To: "Thomas A. Russ" cc: BUG-ITS@MIT-MC.ARPA, bede@MIT-XX.ARPA In-Reply-To: The message of 12 Oct 84 13:42-EDT from Thomas A. Russ Message-ID: <841028173837.9.MOON@EUPHRATES.SCRC.Symbolics> Date: 12 October 1984 13:42-EDT From: Thomas A. Russ I seem to be getting detached from MC regularly when I dial in over the ROLM switch from my office. I wonder if this could be some problem related to the ROLM system. I have DTI # 4303 connected to wall jack # 333 in room 369. I don't know what line on MC is being called. The symptom is that my job on MC gets a top level interrupt and is detached. The connection to MC is left intact. Even as I write this message, it happens again. There used to be a bug, which may still be around, where a disconnected dialup line got the bogus message "top level interrupt job detached" printed on it. The job was detached because the dialup line was disconnected, not because it got a top-level interrupt, but the logout/detach-message printer didn't know that. Of course if the dialup line was really disconnected, no one sees the erroneous message (except people spying on the dialup line, which is how this was discovered originally). I also believe that the Rolm switch has a bug where when you tell it to disconnect it drops "carrier detect" several seconds before it stops passing bits through, so you see some garbage bits. What all this suggests is that maybe you are getting detached because the Rolm switch is saying it's hanging up, or MC or its front-end pdp-11 incorrectly thinks the Rolm is saying it's hanging up.  Date: 12 October 1984 15:26-EDT From: Alan Bawden Subject: Getting Detached from MC To: TAR @ MIT-MC cc: BUG-ITS @ MIT-MC, bede @ MIT-XX In-reply-to: Msg of 12 Oct 1984 13:42-EDT from Thomas A. Russ Date: 12 October 1984 13:42-EDT From: Thomas A. Russ ... The symptom is that my job on MC gets a top level interrupt and is detached.... Well, it would be nice to know what interrupt it is that you are getting. If it happens sometime when you don't need to reattach the tree, you might leave it detached so that an ITS hacker can take a look at it.  Date: 12 October 1984 13:42-EDT From: Thomas A. Russ Subject: Getting Detached from MC To: BUG-ITS @ MIT-MC, bede @ MIT-XX cc: TAR @ MIT-MC I seem to be getting detached from MC regularly when I dial in over the ROLM switch from my office. I wonder if this could be some problem related to the ROLM system. I have DTI # 4303 connected to wall jack # 333 in room 369. I don't know what line on MC is being called. The symptom is that my job on MC gets a top level interrupt and is detached. The connection to MC is left intact. Even as I write this message, it happens again. Tom.  Date: 11 October 1984 15:30-EDT From: Alan Bawden Subject: Fair warning... To: BUG-ITS @ MIT-MC Until further notice everybody should be carefull about editing the sources for ITS itself, as I am in the process of conditionalizing it for the KS processor.  Date: Sun 7 Oct 84 16:20-EDT From: Martin David Connor Subject: 28 page host table too big? To: bug-its@MIT-MC CC: BUG-TCP@MIT-MC, INFO-HOSTS@MIT-MC I fetched the latest NIC host table and installed it on MC, and suddenly I couldn't get a DDT from OZ. I backed out, renaming it to SYSBIN;HOSTS3 TOOBG?, and was then able to SUPDUP in and get a DDT without it barfing and saying there was a PWORD bug. I bet the bug is it couldn't map the host table. Anyway, someone should look at PWORD.  Date: 2 October 1984 22:22-EDT From: Ed Schwalenberg Subject: Don't try this at home kids... To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC I was logged in from home as Alan did this, and got to see that my most-hated ITS bug has been fixed: when the system comes up from a crash, it no longer resets the baud rate on dialed-up lines. Thanks to whoever fixed this. PS. to Alan: Not coincidentally, I was doing :USET UPC when it crashed.  Date: 2 October 1984 21:54-EDT From: Alan Bawden Subject: Don't try this at home kids... To: BUG-ITS @ MIT-MC Setting %PSPUB in your PC flags causes all kinds of havoc to break out on MC. The first time I did it tonight the system console printed: PAGE FAIL ERROR #1, PC = 772740,,301 JOB # 34, USR: ALAN J , PFW = 543000,,301 When the job returned to DDT, DDT claimed it was getting a PURINS interrupt (which I didn't even think could happen on KLs!). I guess you can tell from this that I was actually setting all the flags... Since I couldn't see the system console from my office where I was doing this, I did it several times. Eventually I seem to have hung the microcode. A few controlled experiments later I crashed MC again with an error that contained the string "BAD PAGE FAIL WORD" (the decwriter was dropping so many characters thats about all I could see, I wish that sucker was more reliable).  Date: 30 September 1984 21:10-EDT From: David C. Plummer Subject: HOSTS3 To: CSTACY @ MIT-MC cc: BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, KLH @ SRI-NIC, MOON @ SCRC-TENEX Date: 25 September 1984 17:43-EDT From: Christopher C. Stacy MOON @ SCRC-TENEX The latest host table (including HSTNIC #384) is compiled and installed. The HOSTS3 compiler is "fixed". HOSTS3 hackers: The compiler does not do the sort of dynamic memory allocation I had assumed. I was therefore able to make some more room in the ITS version simply by moving where in core the table was being constructed. I didn't calculate how much room is left over for new code or tables, but the increase should hold us for a while. Of course, we are racing against the rate of host additions on the various networks in our table (the Internet, the Chaosnet, etc.) Hopefully by the time we run out it will be time to implement a hairy namespace system. Won't that be fun! This probably doesn't have a large place in our religion, but you could consider doing the conversion on a machine with a larger address space.  Date: 30 September 1984 02:01-EDT From: Alan Bawden Subject: Not critical To: BUG-ITS @ MIT-MC Giving string arguments to RENAME containing different directories and/or different devices should cause an error if the "from" device doesn't support that kind of renameing. I would suggest either %EBDDV or %ENSMD. Currently RENAME just ignores the device and directory in the "to" filename. The same goes for the devices in the MLINK call. Note that it is not unreasonable to imagine a job device that supported cross-directory and cross-device renameing and linking, so the error returned really should be a function of the device.  Date: 30 September 1984 01:30-EDT From: Glenn S. Burke To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 28 September 1984 19:13-EDT From: Christopher C. Stacy I was just detached because the BABYL I was running claims to have gotten a parity error. The message was top-level interrupt... I don't think the sysjob printed anything about parity errors, or even sweeped for them....I wonder if it was really a parity error... I wonder if this was what happenned to that guy the other day and what it is. Irrecoverable disk error in page mapping gives a parity error interrupt.  Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 86001; Fri 28-Sep-84 15:03:14-EDT Date: Fri, 28 Sep 84 15:03 EDT From: "David A. Moon" Subject: M-X Copy File To: "Robert W. Kerns" cc: "Christopher C. Stacy" , BUG-FILE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA, BUG-LISPM@MIT-MC.ARPA In-Reply-To: <840928023221.8.RWK@HUDSON.SCRC.Symbolics> Message-ID: <840928150349.8.MOON@EUPHRATES.SCRC.Symbolics> Date: Friday, 28 September 1984, 02:32-EDT From: Robert W. Kerns [I haven't looked at the code; I'm surmising what's going on from your message. But I think you've forgotten some of the more unfortunate parts of ITS!] No. Date: Saturday, 15 September 1984, 12:06-EDT From: David A. Moon Date: 14 September 1984 21:00-EDT From: Christopher C. Stacy M-X Copy File does not preserve authors on ITS. It does preserve reference date (although maybe it should use DNRF instead of referencing the file to copy it) and the creation date. This is because the routine CLOSIT in the FILE job sets the author of the file it just wrote to the user's HSNAME. HSNAME is the correct thing to set the file author to on ITS, because "file authors" are directories, not people. Yes, the problem is who sets it, not what it sets it to. It sets it at the time you close the file, even if you already set it yourself to something better, which is the source of the bug. Evidently it does this because the FILE job doesn't login under the name of the user who is using it. We can do one of (1) Make the FILE job login under the right name. I don't think this makes any difference. Isn't the problem overwriting the explicit CHANGE-PROPERTIES that COPYF does? If the file job logged in under the right name then it wouldn't need to set the author itself at the wrong time, because ITS would set it to the right value at the right time. (2) Make ITS set the file author from the XUNAME instead of the UNAME and make the file job set its XUNAME to the user's name instead of to a copy of its UNAME. This would involve changing the UFD format, since currently the file author is just the MFD index of the directory. How would changing the source of the person's name affect the UFD format? You're right that the file job would have to set its XUNAME to the person's HSNAME. (3) Make the FILE job set the author when it opens the file instead of when it closes it. I think this is right, and the easiest. Then if a CHANGE-PROPERTIES sets it to something else, it will prevail, right? Yes.  Received: from SCRC-HUDSON by SCRC-YUKON via CHAOS with CHAOS-MAIL id 63942; Fri 28-Sep-84 02:32:03-EDT Date: Fri, 28 Sep 84 02:32 EDT From: "Robert W. Kerns" Subject: M-X Copy File To: "David A. Moon" cc: "Christopher C. Stacy" , BUG-FILE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA, BUG-LISPM@MIT-MC.ARPA In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics> Message-ID: <840928023221.8.RWK@HUDSON.SCRC.Symbolics> [I haven't looked at the code; I'm surmising what's going on from your message. But I think you've forgotten some of the more unfortunate parts of ITS!] Date: Saturday, 15 September 1984, 12:06-EDT From: David A. Moon Date: 14 September 1984 21:00-EDT From: Christopher C. Stacy M-X Copy File does not preserve authors on ITS. It does preserve reference date (although maybe it should use DNRF instead of referencing the file to copy it) and the creation date. This is because the routine CLOSIT in the FILE job sets the author of the file it just wrote to the user's HSNAME. HSNAME is the correct thing to set the file author to on ITS, because "file authors" are directories, not people. Evidently it does this because the FILE job doesn't login under the name of the user who is using it. We can do one of (1) Make the FILE job login under the right name. I don't think this makes any difference. Isn't the problem overwriting the explicit CHANGE-PROPERTIES that COPYF does? (2) Make ITS set the file author from the XUNAME instead of the UNAME and make the file job set its XUNAME to the user's name instead of to a copy of its UNAME. This would involve changing the UFD format, since currently the file author is just the MFD index of the directory. (3) Make the FILE job set the author when it opens the file instead of when it closes it. I think this is right, and the easiest. Then if a CHANGE-PROPERTIES sets it to something else, it will prevail, right?  Date: 28 September 1984 19:13-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I was just detached because the BABYL I was running claims to have gotten a parity error. The message was top-level interrupt... I don't think the sysjob printed anything about parity errors, or even sweeped for them....I wonder if it was really a parity error... I wonder if this was what happenned to that guy the other day and what it is.  Date: 26 September 1984 01:22-EDT From: Christopher C. Stacy Subject: FOURTH is back online on MC To: TY @ MIT-XX, FINN @ MIT-XX cc: BUG-ITS @ MIT-MC, KMP @ MIT-MC, ALAN @ MIT-MC, PSZ @ MIT-MC, MEYER @ MIT-MC, GSB @ MIT-MC I didn't see any signs of the Trident disk repairman (John Holden?) here today, although I thought he was supposed to be come and work on unit #3 on MC (like I thought he was supposed to do a week ago when it broke.) Did he come? I put the disk back online and tried it out, and it seems to work. However, if the problem is intermittent, as soon as the drive gets hot again or whatever it will break and the system will crash etc.  Date: 26 September 1984 01:01-EDT From: Christopher C. Stacy Sender: CSTAC0 @ MIT-MC Subject: x3-5891 To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML In-reply-to: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden Date: 26 September 1984 00:54-EDT From: Alan Bawden Thats pretty strange given that that version of PWORD had been working on ML for months with no problems. Somehow I'm not very confident that we understand what is going on here... Yeah, but it was getting PDLOV interrupts and I increased the PDL size and now it works...what can I say? A new giant host table was installed today, so maybe PWORD's memory management is all shot to hell and I have somehow just masked it. I'll look at it in more detail soon. We should move this conversation to just BUG-PWORD. Chris  Date: 26 September 1984 01:01-EDT From: Christopher C. Stacy Sender: CSTAC0 @ MIT-MC Subject: x3-5891 To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML In-reply-to: Msg of 26 Sep 1984 00:54-EDT from Alan Bawden Date: 26 September 1984 00:54-EDT From: Alan Bawden Thats pretty strange given that that version of PWORD had been working on ML for months with no problems. Somehow I'm not very confident that we understand what is going on here... Yeah, but it was getting PDLOV interrupts and I increased the PDL size and now it works...what can I say? A new giant host table was installed today, so maybe PWORD's memory management is all shot to hell and I have somehow just masked it. I'll look at it in more detail soon. We should move this conversation to just BUG-PWORD. Chris  Date: 26 September 1984 00:54-EDT From: Alan Bawden Subject: x3-5891 To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML In-reply-to: Msg of 26 Sep 1984 00:43-EDT from Christopher C. Stacy Date: 26 September 1984 00:43-EDT From: Christopher C. Stacy PWORD was losing on ML because it did not have a big enough stack, so I fixed it. Thats pretty strange given that that version of PWORD had been working on ML for months with no problems. Why the same version of this program does not run on both MC and ML is a mystery to me. Somehow I'm not very confident that we understand what is going on here...  Date: 26 September 1984 00:43-EDT From: Christopher C. Stacy Subject: x3-5891 To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-PWORD @ MIT-MC, USER-A @ MIT-ML In-reply-to: Msg of 26 Sep 1984 00:00-EDT from Alan Bawden PWORD was losing on ML because it did not have a big enough stack, so I fixed it. Why the same version of this program does not run on both MC and ML is a mystery to me. Also, I fixed the host-deletion (for "VAR GOOD") stuff long ago, and although the new code works on MC, it doesn't seem to work on ML: I can't delete random numbered hosts from the safe list over there. I'll have to look into these things, but I don't have time today.  Date: 26 September 1984 00:00-EDT From: Alan Bawden Subject: x3-5891 To: BUG-PWORD @ MIT-MC cc: BUG-ITS @ MIT-MC Whenever you connect to ML these days PWORD says: Internal Error: Unknown Interrupt. Please do :BUG PWORD ^C Or call 1-617-253-5891 Even if nobody cares to fix this, I wonder if that phone number has any relationship to current reality...  Date: 25 September 1984 17:43-EDT From: Christopher C. Stacy Subject: HOSTS3 To: INFO-HOSTS @ MIT-MC cc: BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, KLH @ SRI-NIC, MOON @ SCRC-TENEX The latest host table (including HSTNIC #384) is compiled and installed. The HOSTS3 compiler is "fixed". HOSTS3 hackers: The compiler does not do the sort of dynamic memory allocation I had assumed. I was therefore able to make some more room in the ITS version simply by moving where in core the table was being constructed. I didn't calculate how much room is left over for new code or tables, but the increase should hold us for a while. Of course, we are racing against the rate of host additions on the various networks in our table (the Internet, the Chaosnet, etc.) Hopefully by the time we run out it will be time to implement a hairy namespace system. Won't that be fun!  Date: 25 September 1984 15:14-EDT From: David C. Plummer Subject: MATH-HUB To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC Date: 24 September 1984 19:35-EDT From: Alan Bawden MIT-MATH-HUB likes to start up a TELNET server on MC, cause it to open a STY, and then wait forever without outputing a ^Z (er, "call") to the STY. The TELNET job seem to be waiting to .IOT a 377 down its Chaos connection to MATH-HUB. This is a loss because it wastes a STY on MC for no good purpose. If you gun the TELNET job, MATH-HUB just reconnects and starts another one. Well, my guess is that somebody's terminal over there ha a happy T key. I found a not-logged-in telnet job from Math Hub, so here's what I did. :CHATST L TELNET uppercase matters! [Call] Gun down the old TELSER and wait for it to reconnect. Unfortunately, it didn't, so my experiment failed. If it did, I would have done O (opens the connection, I think) S (soak data, I think, to see what it really is sending) Maybe somebody else will have better luck some other time.  Date: 24 September 1984 19:35-EDT From: Alan Bawden Subject: MATH-HUB To: BUG-ITS @ MIT-MC cc: BUG-MINITS @ MIT-MC MIT-MATH-HUB likes to start up a TELNET server on MC, cause it to open a STY, and then wait forever without outputing a ^Z (er, "call") to the STY. The TELNET job seem to be waiting to .IOT a 377 down its Chaos connection to MATH-HUB. This is a loss because it wastes a STY on MC for no good purpose. If you gun the TELNET job, MATH-HUB just reconnects and starts another one.  Date: 24 September 1984 13:07-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC cc: BUG-TCP @ MIT-MC, INFO-HOSTS @ MIT-MC Well, I think we are finally out of address space. New host tables cannot be compiled anymore because they are too massive. People should not try to compile any changes until I get back to you, hopefully with a solution.  Date: 24 September 1984 12:18-EDT From: Christopher C. Stacy To: DEVON @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 22 Sep 1984 23:32-EDT from Devon S. McCullough Date: 22 September 1984 23:32-EDT From: Devon S. McCullough To: BUG-ITS What is %TDSTY and %TDUNF and whatever other innovations have hit the scene? Are they documented? DDT doesn't know about these symbols, and they are not in BITS. Where did you see them?  Date: 22 September 1984 23:32-EDT From: Devon S. McCullough To: BUG-ITS @ MIT-MC What is %TDSTY and %TDUNF and whatever other innovations have hit the scene? Are they documented?  Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 83844; Sat 22-Sep-84 14:47:57-EDT Date: Sat, 22 Sep 84 14:46 EDT From: "David A. Moon" Subject: M-X Copy File To: "Bernard S. Greenberg" cc: CSTACY@MIT-MC.ARPA, BUG-FILE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA In-Reply-To: <840921083548.6.BSG@CONCORD.SCRC.Symbolics> Message-ID: <840922144653.0.MOON@EUPHRATES.SCRC.Symbolics> Date: Friday, 21 September 1984, 08:35-EDT From: Bernard S. Greenberg Date: Saturday, 15 September 1984, 12:06-EDT From: David A. Moon Date: 14 September 1984 21:00-EDT From: Christopher C. Stacy M-X Copy File does not preserve authors on ITS. It does preserve reference date (although maybe it should use DNRF instead of referencing the file to copy it) and the creation date. This is because the routine CLOSIT in the FILE job sets the author of the file it just wrote to the user's HSNAME. Evidently it does this because the FILE job doesn't login under the name of the user who is using it. We can do one of (1) Make the FILE job login under the right name. (2) Make ITS set the file author from the XUNAME instead of the UNAME and make the file job set its XUNAME to the user's name instead of to a copy of its UNAME. (3) Make the FILE job set the author when it opens the file instead of when it closes it. Okay, let me try again. It doesn't know the right author at OPEN time. Yes it does. Suggestion #3 is that the FILE job set the author to the HSNAME at OPEN time, before the user has changed the author to something else, rather than at CLOSE time, after the user has changed the author to something else. Excuse me for not being ITSworthy enough, but if the FILE job has the option of (2), namely, setting the author to a quantity of its liking, why doesn't it remember the result of the PROPERTIES command sent at it for this purpose and set the author to what the user side WANTS it to be? Suggestion #2 refers to ITS, not the FILE job. Yes, I ought to have included the other logically possible suggestion: (4) Keep a copy of the author in the FILE job's memory, instead of in the file system. Set it to the HSNAME when the file is opened, set it to the new author when CHANGE-PROPERTIES is done, and copy it into the file system when the file is closed. Don't forget to change PROPERTIES, and maybe DIRECTORY-LIST, to return this private copy of the author instead of the one out in the file system.  Date: 22 September 1984 09:52-EDT From: David A. Moon Subject: Moon's sabotage of ITS To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 10 September 1984 18:37-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC The recent change in ITS where the SYS job is given 2 extra job slots worth of core (instead of just SYSB) causes the system to crash in CORS2 immediately when coming up. I had put a word count where a page count was expected, so the system job tried to get about two thousand pages when the system started up. Fixed in the source, but not reassembled since I wasn't physically present to test it.  Received: from SCRC-CONCORD by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 83372; Fri 21-Sep-84 08:34:39-EDT Date: Fri, 21 Sep 84 08:35 EDT From: "Bernard S. Greenberg" Subject: M-X Copy File To: Moon@SCRC-STONY-BROOK.ARPA, CSTACY@MIT-MC.ARPA, BUG-FILE@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics> Message-ID: <840921083548.6.BSG@CONCORD.SCRC.Symbolics> Date: Saturday, 15 September 1984, 12:06-EDT From: David A. Moon Date: 14 September 1984 21:00-EDT From: Christopher C. Stacy M-X Copy File does not preserve authors on ITS. It does preserve reference date (although maybe it should use DNRF instead of referencing the file to copy it) and the creation date. This is because the routine CLOSIT in the FILE job sets the author of the file it just wrote to the user's HSNAME. Evidently it does this because the FILE job doesn't login under the name of the user who is using it. We can do one of (1) Make the FILE job login under the right name. (2) Make ITS set the file author from the XUNAME instead of the UNAME and make the file job set its XUNAME to the user's name instead of to a copy of its UNAME. (3) Make the FILE job set the author when it opens the file instead of when it closes it. It doesn't know the right author at OPEN time. Suggestions? Excuse me for not being ITSworthy enough, but if the FILE job has the option of (2), namely, setting the author to a quantity of its liking, why doesn't it remember the result of the PROPERTIES command sent at it for this purpose and set the author to what the user side WANTS it to be?  Date: Mon, 17 Sep 1984 09:35 EDT Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: "Leigh L. Klotz" Cc: ALAN@MIT-MC, BUG-ITS@MIT-MC, CSTACY@MIT-MC, FEATURE-ENTENNMANS@MIT-MC, ITS-LOVERS@MIT-MC, Moon%SCRC-RIVERSIDE@MIT-MC.ARPA Subject: How to copy files on ITS without trashing them In-reply-to: Msg of 17 Sep 1984 00:11-EDT from Leigh L. Klotz Date: Monday, 17 September 1984 00:11-EDT From: Leigh L. Klotz To: ALAN at MIT-MC cc: BUG-ITS at MIT-MC, CSTACY at MIT-MC, FEATURE-ENTENNMANS at MIT-MC, ITS-LOVERS at MIT-MC, Moon at SCRC-RIVERSIDE Re: How to copy files on ITS without trashing them I always move files with TECO myself, <>'ing over the filenames. Hmm. I bring the machine down and copy them into the paging area with SALV.  Date: 17 September 1984 00:11-EDT From: Leigh L. Klotz Subject: How to copy files on ITS without trashing them To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, FEATURE-ENTENNMANS @ MIT-MC, ITS-LOVERS @ MIT-MC, Moon @ SCRC-RIVERSIDE In-reply-to: Msg of 16 Sep 1984 20:16-EDT from Alan Bawden I always move files with TECO myself, <>'ing over the filenames.  Date: 16 September 1984 20:16-EDT From: Alan Bawden Subject: How to copy files on ITS without trashing them To: CSTACY @ MIT-MC, Moon @ SCRC-RIVERSIDE cc: BUG-ITS @ MIT-MC, FEATURE-ENTENNMANS @ MIT-MC, ITS-LOVERS @ MIT-MC In-reply-to: Msg of Sun 16 Sep 84 16:55 EDT from David A. Moon Date: Sun, 16 Sep 84 16:55 EDT From: David A. Moon The most convenient way, I have always found, is to use the DIRED program.... My recent experience with the DIRED program is that it gets MPVs a lot. I always do such things by reading DIR:.FILE. (DIR) into an Emacs buffer and writing a TECO program to put together an XFILE for DDT to slurp up. I like this because it lets me run three different programs (the DIR device, Emacs and DDT), code in two obscure programming languages (TECO and DDT), and use two unrelated control-character-oriented command languages (Emacs and DDT). Using a JOB device as the first step gets the process started off on the right foot. If I can use a translation somehow, thats a big plus. Sometimes I run the XFILE in a separate DDT job that I then  so that I can watch the process using PEEK. This is especially entertaining when I are dealing with files using the ML device or the archive device. The fact that two jobs are typing on my console at the same time without having the operating system lose track of the position of my cursor is fun to contemplate. If what needs to be done is particularly complex, it's always fun to write a little assembly language program to do the job. Preferably by depositing it directly into a job using DDT, although if I must stoop to using an assembler I can make up for the loss of face by writing a hairy MIDAS macro.  Date: 16 September 1984 18:56-EDT From: Christopher C. Stacy To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-LISPM @ MIT-MC In-reply-to: Msg of 16 Sep 1984 16:32-EDT from Alan Bawden Sigh....so much for trusting ZWEI...  Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 61136; Sun 16-Sep-84 17:53:24-EDT Date: Sun, 16 Sep 84 17:50 EDT From: "David A. Moon" Subject: Source for :TIME To: Alan Bawden cc: BUG-ITS@MIT-MC.ARPA In-Reply-To: The message of 6 Sep 84 02:21-EDT from Alan Bawden Message-ID: <840916175052.0.MOON@EUPHRATES.SCRC.Symbolics> Date: 6 September 1984 02:21-EDT From: Alan Bawden Well, I just retrieved source files for a bunch of ITS system programs from AI and ML backup tapes. I was able to find an OLD source for :TIME (version 35, version 39 is installed on MC right now...). The most up to date source probably lives only on DM backup tapes. Do we have a way to read DM backup tapes? Did anyone write such a tool when the DM users moved to XX? The good news is that as far as I can tell, TIME is the -only- program whose source file is trapped in that particular way... I don't know of any way to do it, but the format is so simple. Each file on the tape is a file (i.e. there are tape marks between the files) and just has some header information at the front.  Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 61133; Sun 16-Sep-84 17:33:18-EDT Date: Sun, 16 Sep 84 17:30 EDT From: "David A. Moon" Subject: Top level interrupt To: Alan Bawden , CSTACY@MIT-MC.ARPA, BEN@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-Reply-To: The message of 13 Sep 84 21:55-EDT from Alan Bawden Message-ID: <840916173045.7.MOON@EUPHRATES.SCRC.Symbolics> Date: 13 September 1984 21:55-EDT From: Alan Bawden Date: 13 September 1984 19:44-EDT From: Christopher C. Stacy Date: 13 September 1984 14:46-EDT From: Benjamin Kuipers What is this nonsense about "Top level interrupt. Tree detached." No, it means that your top-level process (presumably HACTRN) got a fatal interrupt and died, detaching the entire tree. This could possibly be the result of a memory parity error. I looked around for such dead trees when I first got this bug report, but I didn't find any to figure out what happened to him. There have been no parity errors for the last day, so that couldn't be the reason. There used to be a buglet, which may still be there, related to this. When a dialup line hangs up the system job would type "Top level interrupt, tree detached" on it. Of course there's no one on the other end of a hung-up dialup line, so no one ever sees this message. But if it wasn't -really- hung up... Did this happen on a dialup line or a ROLM line by any chance?  Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 81783; Sun 16-Sep-84 16:51:40-EDT Date: Sun, 16 Sep 84 16:55 EDT From: "David A. Moon" Subject: How to copy files on ITS without trashing them To: CSTACY@MIT-MC.ARPA cc: Alan Bawden , BUG-LISPM@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA In-Reply-To: The message of 16 Sep 84 16:32-EDT from Alan Bawden Message-ID: <840916165519.5.MOON@EUPHRATES.SCRC.Symbolics> The most convenient way, I have always found, is to use the DIRED program. Not the Emacs one, the other one. It has a set of file-processing commands that take the star convention and it's fast. The only problem is that the right MOVE command has some obscure name like BC (don't trust my memory on this!)  Date: 16 September 1984 16:32-EDT From: Alan Bawden To: CSTACY @ MIT-MC cc: BUG-LISPM @ MIT-MC, BUG-ITS @ MIT-MC God DAMNIT! When I came in this morning MC had no free job slots because the system was completely full of dead TIME servers. After gunning about 50 of them so that I could work I found out that all of the binary files on SYSNET, including the time server, had been trashed. You can probably guess why: when you use M-X Copy File from a Lisp Machine it must clobber 36-bit binary files named BIN by DWIMing and treating them as 32-bit L-machine BIN files. I'll bet if there were any text files on the old TCP directory that contained imbedded ^M's they have been trashed as well by being copied in Lisp Machine character set mode. And I know you already noticed that Copy File clobbered all of the author information. You really should have used :MOVE rather than deluding yourself into thinking that a Lisp Machine could make the job easier. I reassembled the time server, but I leave it up to you to deal with the rest of the mess. I would advise retrieving the entire TCP directory and doing it again the right way.  Date: 15 September 1984 17:15-EDT From: Ray Hirschfeld Subject: ROLM lines To: BUG-ITS @ MIT-MC Because the new ROLM lines are specified as dialup lines in TTYTYP, typing ":ttyloc foo" produces a location of not "foo" but instead "Dialup: foo", a misfeature.  Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 81650; Sat 15-Sep-84 12:03:45-EDT Date: Saturday, 15 September 1984, 12:06-EDT From: David A. Moon Subject: M-X Copy File To: Christopher C. Stacy , BUG-FILE at MIT-MC cc: BUG-ITS at MIT-MC, BUG-LISPM at MIT-MC In-Reply-To: The message of 14 Sep 84 21:00-EDT from Christopher C. Stacy Message-ID: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics> Date: 14 September 1984 21:00-EDT From: Christopher C. Stacy M-X Copy File does not preserve authors on ITS. It does preserve reference date (although maybe it should use DNRF instead of referencing the file to copy it) and the creation date. This is because the routine CLOSIT in the FILE job sets the author of the file it just wrote to the user's HSNAME. Evidently it does this because the FILE job doesn't login under the name of the user who is using it. We can do one of (1) Make the FILE job login under the right name. (2) Make ITS set the file author from the XUNAME instead of the UNAME and make the file job set its XUNAME to the user's name instead of to a copy of its UNAME. (3) Make the FILE job set the author when it opens the file instead of when it closes it. Suggestions?  Date: 14 September 1984 21:03-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC, INFO-HOSTS @ MIT-MC The TCP; directory on MC is now called "SYSNET;".  Date: 14 September 1984 21:00-EDT From: Christopher C. Stacy Subject: M-X Copy File To: BUG-FILE @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-LISPM @ MIT-MC M-X Copy File does not preserve authors on ITS. It does preserve reference date (although maybe it should use DNRF instead of referencing the file to copy it) and the creation date.  Date: 14 September 1984 16:58-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC T-300 unit 3 was going offline spontanesouly, causing the system to hang on some operations. It should be fixed Monday or Tuesday.  Date: 13 September 1984 21:55-EDT From: Alan Bawden Subject: Top level interrupt To: CSTACY @ MIT-MC cc: BEN @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 13 Sep 1984 19:44-EDT from Christopher C. Stacy Date: 13 September 1984 19:44-EDT From: Christopher C. Stacy Date: 13 September 1984 14:46-EDT From: Benjamin Kuipers What is this nonsense about "Top level interrupt. Tree detached." No, it means that your top-level process (presumably HACTRN) got a fatal interrupt and died, detaching the entire tree. This could possibly be the result of a memory parity error. I looked around for such dead trees when I first got this bug report, but I didn't find any to figure out what happened to him. There have been no parity errors for the last day, so that couldn't be the reason. If he was neglecting to log in, PWORD gets a top level interrupt when your not-logged-in-time-limit expires rather than telling you why you are going away, but then it would have warned him in advance that this was likely to occur if he hadn't logged in. I hope there is no signifigance to the fact that what the SYSJOB really types is "Top level interrupt, tree detached"...  Date: 13 September 1984 20:43-EDT From: Glenn S. Burke Subject: supdup To: DCP @ MIT-MC cc: BUG-ITS @ MIT-MC, dab @ MIT-BORAX ok, i looked up %nsrcl -- cls received while in rfc received state. I made it treat this the same as %nscls, it now exits and says "Connection being closed by foreign host."  Date: 13 September 1984 20:32-EDT From: David C. Plummer Subject: supdup To: dab @ MIT-BORAX cc: BUG-ITS @ MIT-MC Received: by mit-borax.ARPA (4.12/4.7) id AA03676; Thu, 13 Sep 84 16:15:39 edt From: dab@mit-borax (David A. Bridgham) Date: 13 Sep 1984 1615-EDT (Thursday) I recently wrote a supdup server for VAX UNIX running on TCP. This is currently running on MIT-BORAX. To test it I would supdup in from lisp machines or CCC. This forwards through MC with no problem. However, from MC if I type ":supdup borax" it sits for a while and says that the connection timed out without getting established. Could anyone help? Thanks. It works for me. I get the error somebody else already reported by typing ^D to the login prompt. You are probably violating the logout protocol or something.  Date: 13 September 1984 19:44-EDT From: Christopher C. Stacy To: BEN @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 13 Sep 1984 14:46-EDT from Benjamin Kuipers Date: 13 September 1984 14:46-EDT From: Benjamin Kuipers To: BUG-ITS What is this nonsense about "Top level interrupt. Tree detached." This has happened to me twice in the last couple of hours. Have I been gunned? Ben No, it means that your top-level process (presumably HACTRN) got a fatal interrupt and died, detaching the entire tree. This could possibly be the result of a memory parity error.  Received: by mit-borax.ARPA (4.12/4.7) id AA03676; Thu, 13 Sep 84 16:15:39 edt From: dab@mit-borax (David A. Bridgham) Message-Id: <8409132015.AA03676@mit-borax.ARPA> Date: 13 Sep 1984 1615-EDT (Thursday) To: bug-its@mc Subject: supdup I recently wrote a supdup server for VAX UNIX running on TCP. This is currently running on MIT-BORAX. To test it I would supdup in from lisp machines or CCC. This forwards through MC with no problem. However, from MC if I type ":supdup borax" it sits for a while and says that the connection timed out without getting established. Could anyone help? Thanks. Dave  Date: 13 September 1984 14:46-EDT From: Benjamin Kuipers To: BUG-ITS @ MIT-MC What is this nonsense about "Top level interrupt. Tree detached." This has happened to me twice in the last couple of hours. Have I been gunned? Ben  Date: 12 September 1984 17:42-EDT From: Alan Bawden Subject: archive To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, CENT @ MIT-MC, CSTACY @ MIT-MC In-reply-to: Msg of 11 Sep 1984 13:12-EDT from Alan Bawden Date: 11 September 1984 13:12-EDT From: Alan Bawden Well .INFO. really is full to bursting, especially after I rescued some info files from ML. I suppose this is yet another excuse to create the SYSDOC directory and move a bunch of operating-system specific files there. The problem is that a fair number of them will want to leave links behind in .INFO. and links take up more directory room than a small file... OK, I created SYSDOC and moved a bunch of stuff there. .INFO. has a bit of room again. People who care are welcome to shuffle the documentation around more if they like. Just don't break anything.  Date: 12 September 1984 08:57-EDT From: Bill Long To: BUG-ITS @ MIT-MC When the Rolm switch tries 4991 to get MC, it times out.  Date: 11 September 1984 22:40-EDT From: Leigh L. Klotz Subject: 20th Anniversary of 36 Bits To: CENT @ MIT-MC cc: BUG-ITS @ MIT-MC, CC.Clive @ UTEXAS-20 In-reply-to: Msg of 11 Sep 1984 04:24-EDT from Pandora B. Berman Don't forget Don Eastlake, DEE@CCA, I think.  Date: 11 September 1984 13:12-EDT From: Alan Bawden Subject: archive To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, CENT @ MIT-MC In-reply-to: Msg of 11 Sep 1984 09:30-EDT from Christopher C. Stacy Date: 11 September 1984 09:30-EDT From: Christopher C. Stacy I moved it to .INFO. because I am usually have alot of trouble updating or re-assemble the ITS because the SYSTEM directory is full; I figured SYSTEM sources ought to live in SYSTEM and that info ought to live in .INFO.. Well .INFO. really is full to bursting, especially after I rescued some info files from ML. I suppose this is yet another excuse to create the SYSDOC directory and move a bunch of operating-system specific files there. The problem is that a fair number of them will want to leave links behind in .INFO. and links take up more directory room than a small file...  Date: 11 September 1984 09:30-EDT From: Christopher C. Stacy Subject: archive To: CENT @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 10 Sep 1984 23:50-EDT from Pandora B. Berman I moved it to .INFO. because I am usually have alot of trouble updating or re-assemble the ITS because the SYSTEM directory is full; I figured SYSTEM sources ought to live in SYSTEM and that info ought to live in .INFO..  Date: 11 September 1984 05:11-EDT From: Ed Schwalenberg Subject: Recent spate of crashes To: BUG-NAME @ MIT-MC cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC NAME uses CORBLK to read in the ASCII file SYSENG;TTYTYP > and parses through it looking for the magic comments of the form ;T00 System Console, which it records in its database. It is under the mistaken impression that the file in core will be terminated by either nulls or ^C's; the documentation for CORBLK says no such thing. In fact, the difference between the length of a file as returned by FILLEN and the next page boundary is filled with garbage. I edited SYSTEM;TTYTYP > to create a copy that is "identical" to the previous version except that it has some nulls in the garbage that follows the last valid word. The bug should be really fixed in the source. I wonder how many other programs depend on this sort of thing?  Date: 11 September 1984 04:24-EDT From: Pandora B. Berman Subject: Re: 20th Anniversary of 36 Bits To: CC.Clive @ UTEXAS-20 cc: BUG-ITS @ MIT-MC Date: Tue 11 Sep 84 02:44:10-CDT From: Clive Dawson Subject: Re: 20th Anniversary of 36 Bits To: CENT@MIT-MC.ARPA Thanks for the info and suggestions. We certainly have Greenblatt on the list. In fact I talked to him at AAAI here in Austin recently and there's a good chance we can get him to be on the panel at the Pioneer's Rountable session. I certainly would like to add other ITS people to the general list of invitees. Do you suppose you (or somebody else) could provide me with a list of such people, including a brief comment describing their connection to the 36-bit machines? I'll add Holloway (is he an original ITS developer?); also I have people like Gosper and Schroeppel of HAKMEM fame, and RMS. I suspect there are quite a few others. Thanks, CLive i'm not your best source for this, being a relative latecomer (i got to the lab in the middle of the lisp machine effort). try Tom Knight (TK@MC) -- built the Knight TV system (was attached to the AI KA-10) for his undergrad thesis -- and Ken Harrenstein (KLH@MC or @NIC) -- wrote COMSAT, the ITS mailer, for his -- for a better list. i believe holloway was mostly a hardware hacker; he had a lot to do with the KA paging box (we apparently have a confusion with the TOPS10 people over who did paging first). RWG and RMS are reachable at those names by mail to MC, as is MOON, who wrote the ITS microcode for the KL; i don't know where schroeppel is these days, he's been gone from here for a while. i think we have the AI-6's chess trophies for MAKHAK 6 around somewhere; probably RG knows.  Date: 10 September 1984 23:50-EDT From: Pandora B. Berman Subject: archive To: BUG-ITS @ MIT-MC i moved the ITS BUGS archive from .INFO.;, which was bursting, back to SYSTEM; where it apparently used to be, and where there is more space. i have no idea who thought it was a good idea to move it to .INFO. .  Date: 10 September 1984 23:16-EDT From: Pandora B. Berman Subject: 20th Anniversary of 36 Bits To: CC.Clive @ UTEXAS-20 cc: BUG-ITS @ MIT-MC don't forget ITS, Greenblatt (RG@OZ, currently at LMI in cambridge), Holloway (H@MC, currently at Symbolics in cambrige), and all the other ITS hackers. in many ways ITS is STILL the best 10-family OS (we are now in the process of porting it to a 2020).  Date: 10 September 1984 18:37-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC The recent change in ITS where the SYS job is given 2 extra job slots worth of core (instead of just SYSB) causes the system to crash in CORS2 immediately when coming up. Version 1378 is the same as 1377, but with the other new modules (INET, CORE, SYSJOB) incorporated. We also have the new TTYTYP file and the front-end files (IOELEV, BOOT11, etc) have been updated. This is all XITS. You can't boot the old version (ITS) in the normal fashion since one of the boot command files has been changed, so I hope it continues to work.  Date: 6 September 1984 02:21-EDT From: Alan Bawden Subject: Source for :TIME To: MOON @ MIT-MC cc: BUG-ITS @ MIT-MC Well, I just retrieved source files for a bunch of ITS system programs from AI and ML backup tapes. I was able to find an OLD source for :TIME (version 35, version 39 is installed on MC right now...). The most up to date source probably lives only on DM backup tapes. Do we have a way to read DM backup tapes? Did anyone write such a tool when the DM users moved to XX? The good news is that as far as I can tell, TIME is the -only- program whose source file is trapped in that particular way...  Date: 5 September 1984 23:56-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I gunned a tree which had jobs zorched by parity errors. The job state in PEEK went to *MULTIX and I thought it was trying to log out (since it usually does that after LOGOUT). It never went away and I could not UJOB it (job not found). I think it was blocked in a SLEEP call; I bashed its flush instruction to zero and it imediately went away.  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2640626229863307@MIT-MULTICS.ARPA>; 04 Sep 1984 15:17:09 edt Date: 04 Sep 84 15:00 +0200 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: BUG-ITS@MIT-MC Subject: ITS for swedish KA10 Message-ID: <68570@QZCOM> Thanks for your reply. I wasn't sure if my letters got through, or if I was addressing the right people. Our MAILNET connection is still somewhat experimental. The machine is a gift from DEC (or rather, we got it very cheap: 1 SEK which is approximately 15 cents), we have transported it from its previous home in Finland to Sweden, and are now planning to re-install it here. We have experienced hardware hackers who plan to build their own memory, paging box, and possibly other things too. Existing hardware: 1 KA10 cpu 3 MF10 in working condition 1 MF10 with essentially a missing backplane 2 DF10 data channel (18-bit) 1 RP10 disk controller 2 RH10 massbus controller 1 TM10 tape controller 1 DC10 with 32 lines 1 BA10 hard copy controller 1 TU10 tape drive 1 RP02 disk drive 1 Line printer 1 Card reader (!) Some of us work at the university computer center, so we have access to DEC10's and 20's where we can read tapes, cross-compile sources etc if necessary. We are grateful for any information you can give us, either through the network, or by ordinary mail to: Datorforeningen STACKEN c/o NADA Royal Institute of Technology S-100 44 Stockholm SWEDEN  Date: 3 September 1984 02:32-EDT From: Pandora B. Berman Subject: we hear you To: Bjorn_Danielsson_QZ%QZCOM.MAILNET @ MIT-MULTICS cc: BUG-ITS @ MIT-MC Date: 27 Aug 84 20:48 +0200 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: GSB@MIT-MC.ARPA Subject: ITS Hello. Some friends of mine in the computer club STACKEN in Stockholm, Sweden want to get hold of an ITS operating system for their KA-10 computer. Could you tell me if it is possible to get the sources and documentation, including information about the extra paging hardware? Bjorn Danielsson hello out there. we are glad to hear that, somewhere else in the world, ITS lovers exist. it is theoretically possible, but technically a bit difficult, to give your friends the information they need to bring up ITS on their KA -- difficult because it's hard to assemble. we are working on trying to put together the right stuff for them, but it may take a while. any further information you can give on what their KA is like can only be helpful. please address futher communications on this subject to BUG-ITS@MC, so we will all see them.  Date: 24 August 1984 21:29-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC SALV and exec DDT are write locked.  Date: 20 August 1984 16:51-EDT From: David Vinayak Wallace Subject: breaking ITS net connections To: mclure @ SRI-PRISM cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, SASW @ MIT-MC In-reply-to: Msg of Sun Aug 19 11:54:15 1984 from mclure at sri-prism From an ether tip typing the esacpe twice sends it through; I use the feature from the h19's in he basement of mjh all the time. But if you find that objectionable, why not change the escape character for your telnet to be something else? david PS: Bug-its: on the other hand, since everybody has infinite free time, and isn't working on things like theses, what's wrong with .e.g. 2u logging out and detaching non-hardwired lines?  Date: 19 August 1984 16:07-EDT From: Alan Bawden Subject: breaking ITS net connections To: mclure @ SRI-PRISM cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, SASW @ MIT-MC In-reply-to: Msg of Sun Aug 19 11:54:15 1984 from mclure at sri-prism Date: Sun Aug 19 11:54:15 1984 From: mclure at sri-prism That's just the point. If I am using the Stanford ethernet to access score, there are certain instances where my escape will be robbed by a superior program and unavailable to telnet.... Have you complained to anyone about this misfeature? Seems like your real problem is that you are forced to use a broken program to make your first hop over the network. I suppose we could put a command in DDT that guns its own telnet server... Always seems a shame to have to do things like this to compensate for other people's bugs.  Date: 19 August 1984 15:44-EDT From: David C. Plummer Subject: Re: breaking ITS net connections To: mclure @ SRI-PRISM cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC, SASW @ MIT-MC Date: Sun Aug 19 11:54:15 1984 From: mclure@sri-prism That's just the point. If I am using the Stanford ethernet to access score, there are certain instances where my escape will be robbed by a superior program and unavailable to telnet. So I am unable to close the connection because I can't escape back to my telnet (without escaping to the ethernet tip, or whatever other medium happens to be in the way). Your user program is seriously misdesigned. My question still stands. Is there a way in ITS DDT to break a connection manually? If not, I think one should be added as everyone else has one and it has shown itself to be desirable. No, and NO!!! Alan's message shows that this is considered a win (by the ITS community, at least). If your user program doesn't have a command to forcibly disconnect you, I suggest you find another program, or stop using ITS. How would you get out if you started running a program that has super-image-input on so you couldn't even type c-Z (er, CALL).  Received: by sri-prism.ARPA (4.12/4.16) id AA06644; Sun, 19 Aug 84 11:56:45 pdt Message-Id: <8408191856.AA06644@sri-prism.ARPA> Date: Sun Aug 19 11:54:15 1984 From: mclure@sri-prism To: CSTACY@MIT-MC Cc: bug-its@mit-mc, sasw@mit-mc Subject: Re: breaking ITS net connections That's just the point. If I am using the Stanford ethernet to access score, there are certain instances where my escape will be robbed by a superior program and unavailable to telnet. So I am unable to close the connection because I can't escape back to my telnet (without escaping to the ethernet tip, or whatever other medium happens to be in the way). My question still stands. Is there a way in ITS DDT to break a connection manually? If not, I think one should be added as everyone else has one and it has shown itself to be desirable. Stuart  Date: 19 August 1984 14:52-EDT From: Alan Bawden Subject: breaking ITS net connections To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, SASW @ MIT-MC, mclure @ SRI-PRISM Date: 19 August 1984 14:33-EDT From: Christopher C. Stacy After logging out of ITS, why not close the connection from your end, perhaps by killing your TELNET program or issuing a "close" command to it? This will not leave any ITS job hanging. Perhaps he in confused by the fact that ITS doesn't close the connection IMMEDIATELY after you log out? If you wait a few minutes after you logout, your TELNET server will wake up and break the connection. We regard this as a feature; it gives you a chance to re-use the connection by typing ^Z (er, CALL). Its like having a hardwired line, except it times out eventually. The same philosophy applies to the way ITS handles logging out from a dialup. Having this feature from dialups is actually even more of a win. It lets someone else log into the machine without having to re-dial the phone. The whole things seems like such a simple courtesy that I'm always surprised that the 20X wizards around here don't adopt the feature.  Date: 19 August 1984 14:33-EDT From: Christopher C. Stacy Subject: breaking ITS net connections To: mclure @ SRI-PRISM cc: BUG-ITS @ MIT-MC, SASW @ MIT-MC In-reply-to: Msg of Sun 19 Aug 84 10:57:35-PDT from Stuart McLure Cracraft After logging out of ITS, why not close the connection from your end, perhaps by killing your TELNET program or issuing a "close" command to it? This will not leave any ITS job hanging.  Date: Sun 19 Aug 84 10:57:35-PDT From: Stuart McLure Cracraft Subject: breaking ITS net connections To: bug-its@MIT-MC.ARPA, sasw@MIT-MC.ARPA Reply-To: mclure@sri-prism There seems to be no good way to break a net connection on the ITS machines. Perhaps there is one, but it is not obvious. TOPS-20 Arpanet machines usually break the connection upon logout. WAITS allows you to break it with the 'QUIT' command. Unix lets you break a net connection at the 'login:' prompt by typing ^D. Does ITS have an equivalent? I have left many jobs hanging/detached on MIT machines over the years whenever the telnet/modem/network configuration I am reaching it through does not allow an escape character of its own. Thanks. Stuart -------  Date: 18 August 1984 00:20-EDT From: David A. Moon To: BUG-ITS @ MIT-MC looks like the source to sys1;ts time is lost.  Date: 13 August 1984 22:00-EDT From: Pandora B. Berman Subject: someone has this KA, you see... To: BUG-ITS @ MIT-MC [damned if i know why they asked me.] ---------- Date: 13 Aug 84 15:38 +0200 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Pandora B. Berman" Subject: ITS Hello. Some friends of mine in the computer club STACKEN in Stockholm, Sweden want to get hold of an ITS operating system for their KA-10 computer. Could you tell me if it is possible to get the sources and documentation, including information about the extra paging hardware? Bjorn Danielsson  Date: 11 August 1984 19:44-EDT From: Alan Bawden Subject: mc:crash;tcp .value To: MOON @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, KLH @ MIT-MC In-reply-to: Msg of 11 Aug 1984 18:54-EDT from David A. Moon Date: 11 August 1984 18:54-EDT From: David A. Moon Date: 1 August 1984 18:12-EDT From: Alan Bawden Dunno who maintains the TCP server exactly, ... "The" TCP server? Guesswork reveals that it's the FTP/SMTP server... When I said "TCP server", I was talking about the Chaosnet TCP server. You know, the thing that gets loaded from DEVICE;CHAOS TCP. I didn't think too hard about how ambiguous that would sound in a bug note CC'd to BUG-TCP. Now a good question is how did I manage to mistake an FTP server for that? (Perhaps I need to think again about how the MOVE instruction works.)  Date: 11 August 1984 18:54-EDT From: David A. Moon Subject: mc:crash;tcp .value To: ALAN @ MIT-MC, KLH @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC Date: 1 August 1984 18:12-EDT From: Alan Bawden To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC Dunno who maintains the TCP server exactly, but I found a couple that had .VALUEd just now. I dumped one of them into CRASH;TCP .VALUE Seems to me that I'm seeing more of these guys .VALUEing recently so perhaps someone should take a look. "The" TCP server? Guesswork reveals that it's the FTP/SMTP server found in SYSBIN;FTPS BIN and it got an error from a FINISH system call in RETR05 called from the LIST command (look at location AUTPSY). I guess it's not robust to the user killing the connection while it's in the middle of listing a directory. I fixed this in the source but cannot reassemble FTPS because KLH's macros, which it uses, have been changed incompatibly. I found the file ksc;?out >, which purports to explain how to convert, but I can find no indication of how to convert OUTOPN in there so I'll leave this for KLH to fix or advise about. Presumably plenty of other programs are broken the same way. I didn't delete the CRASH file in case anyone else wants to look at it.  Date: 9 August 1984 11:02-EDT From: David C. Plummer Subject: rebooted hubs To: ALAN @ MIT-MC cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC, GUMBY @ MIT-MC, bug-minits @ MIT-OZ, DMS @ MIT-OZ Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Aug 84 19:11-EDT Date: 8 August 1984 19:04-EDT From: Alan Bawden In-reply-to: Msg of 8 Aug 1984 18:01-EDT from David C. Plummer Date: 8 August 1984 18:01-EDT From: David C. Plummer I think there are (undocumented) frobs that can follow the 034 of ITP to say this. If I can find it in the source in the next 4 minutes, I'll let you know... Undocumented? fooey! Do :INFO ITS TTY SMART ESCAPE and you will find what you are looking for. It's not documented in the SUPDUP RFC (though I didn't look very hard, but I remember that it isn't documented there).  Date: 8 August 1984 19:04-EDT From: Alan Bawden Subject: rebooted hubs To: DCP @ MIT-MC cc: BUG-ITS @ MIT-MC, GUMBY @ MIT-MC, bug-minits @ MIT-OZ, DMS @ MIT-OZ In-reply-to: Msg of 8 Aug 1984 18:01-EDT from David C. Plummer Date: 8 August 1984 18:01-EDT From: David C. Plummer I think there are (undocumented) frobs that can follow the 034 of ITP to say this. If I can find it in the source in the next 4 minutes, I'll let you know... Undocumented? fooey! Do :INFO ITS TTY SMART ESCAPE and you will find what you are looking for.  Date: 8 August 1984 18:01-EDT From: David C. Plummer Subject: rebooted hubs To: GUMBY @ MIT-MC cc: BUG-ITS @ MIT-MC, DMS @ MIT-OZ, bug-minits @ MIT-OZ Date: 8 August 1984 17:14-EDT From: David Vinayak Wallace In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel It would gubbish your screen unless there were a way to tell ITS that typeout had occurred. I think there are (undocumented) frobs that can follow the 034 of ITP to say this. If I can find it in the source in the next 4 minutes, I'll let you know... Here it is... gotta run... TYBCTL: CAIN A,^A ;^\^A => ALLOCATE OUTPUT CHARS. JRST TYBA CAIN A,^Z ;^\^Z => ZERO ALLOCATION JRST TYBZ CAIN A,^I ;^\^I => INFINITY ALLOCATION JRST TYBI CAIN A,^R ;^\^R => RESTART OUTPUT AT M.P. LEVEL. JRST TYBR CAIN A,^P ;^\^P => SET CURSOR POSITION AND RESTART OUTPUT AT M.P. LEVEL. JRST TYBP CAIN A,^\ ;^\^\ => INPUT A ^\. JRST TYBRET CAIN A,^C ;^\^C => SCREEN HAS BEEN SURREPTITIOUSLY CHANGED PUSHJ P,TYBC ;RETURN TO NORMAL ^\ STATUS BUT DON'T PASS ANY INPUT UP TO NORMAL INPUT LEVEL.  Date: 8 August 1984 17:58-EDT From: David C. Plummer Subject: rebooted hubs To: GUMBY @ MIT-MC cc: BUG-ITS @ MIT-MC, DMS @ MIT-OZ, bug-minits @ MIT-OZ Date: 8 August 1984 17:14-EDT From: David Vinayak Wallace In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel It would gubbish your screen unless there were a way to tell ITS that typeout had occurred. I think there are (undocumented) frobs that can follow the 034 of ITP to say this. If I can find it in the source in the next 4 minutes, I'll let you know...  Date: 8 August 1984 17:14-EDT From: David Vinayak Wallace Subject: rebooted hubs To: DMS @ MIT-OZ cc: BUG-ITS @ MIT-MC, bug-minits @ MIT-OZ In-reply-to: Msg of Mon 6 Aug 84 12:42:28-EDT from David Siegel It would gubbish your screen unless there were a way to tell ITS that typeout had occurred.  Date: 7 August 1984 19:02-EDT From: Leigh L. Klotz Subject: chuname broken To: MLY @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 5 Aug 1984 22:31-EDT from Richard Mlynarik Are you sure that you weren't already logged in (or detached) as MLY when you tried doing :CHUNAME MLY? That's what's usually happening when you get the ? response.  Date: 5 August 1984 23:42-EDT From: Alan Bawden Subject: chuname broken To: MLY @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC In-reply-to: Msg of 5 Aug 1984 22:31-EDT from Richard Mlynarik Date: 5 August 1984 22:31-EDT From: Richard Mlynarik Sender: MLY0 logged in as anything, and typing ":chuname mly" at ddt gets me the right "--massacre and reset--" but confirming with a space just gets me a "?" and my uname is still the same. This bug report seems to be saying that you were unable to get CHUNAME to work under any circumstances. Funny, because I can't seem to get it to fail under any circumstances. I notice that you sent this bug report logged in as "MLY0", perhaps you can tell me what other MLY's were logged in at the time, what you were logged in as, and what you tried to CHUNAME to.  Date: 5 August 1984 23:10-EDT From: Devon S. McCullough To: BUG-ITS @ MIT-MC emacs got a .val 0; 35572>>move 1,3 1/17450 3/24 when I tried to find a file on HS:  Date: 5 August 1984 22:31-EDT From: Richard Mlynarik Sender: MLY0 @ MIT-MC Subject: chuname broken To: BUG-ITS @ MIT-MC logged in as anything, and typing ":chuname mly" at ddt gets me the right "--massacre and reset--" but confirming with a space just gets me a "?" and my uname is still the same.  Date: 5 August 1984 16:13-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC The NETWRK package only defines a single Chaosnet packet buffer, so you can only hack on connection at a time.  Date: 1 August 1984 18:12-EDT From: Alan Bawden To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC Dunno who maintains the TCP server exactly, but I found a couple that had .VALUEd just now. I dumped one of them into CRASH;TCP .VALUE Seems to me that I'm seeing more of these guys .VALUEing recently so perhaps someone should take a look.  Date: 1 August 1984 13:42-EDT From: Christopher C. Stacy Subject: EMACS not working on MC, and BUG-EMACS broken To: RIG @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC In-reply-to: Msg of 1 Aug 1984 13:12-EDT from Ronald I. Greenberg The mail receipt you received from the COMSAT only indicates that a there is an addressee (ECARTER@OFFICE-2) who is a member of the BUG-EMACS mailing list, but who in fact does not exist. Your message was delivered to all the other BUG-EMACS people. I just tried EMACS on MC, and it is working fine.  Date: 1 August 1984 13:12-EDT From: Ronald I. Greenberg Sender: RIG0 @ MIT-MC To: BUG-ITS @ MIT-MC :bug emacs didn't work as evidenced by the following returned mail. COMSAT@MIT-MC 08/01/84 12:42:23 Re: Msg of Wednesday, 1 August 1984 12:39-EDT To: RIG at MIT-MC Queued: JSL at MIT-MULTICS, Carter at RUTGERS FAILED: ECARTER at OFFICE-2; Recipient name apparently rejected. Last reply was: {550 No such mailbox here} Failed message follows: ------- Date: 1 August 1984 12:39-EDT From: Ronald I. Greenberg To: BUG-EMACS @ MIT-MC A little while ago, while logged on to MC I found EMACS working improperly. For example, c-E, m-F, and m-B were going to incorrect places. One time m-F took me backwards one character! I would be interested in finding out what was wrong. Ron Greenberg rig@mc By the way, I suppose the emacs problem might really be a problem with the terminal. I will try to check this out.  Date: Fri, 27 Jul 1984 11:50 EDT Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: "Christopher C. Stacy" Cc: BUG-ITS@MIT-MC Subject: front end 11 In-reply-to: Msg of 27 Jul 1984 03:53-EDT from Christopher C. Stacy Date: Friday, 27 July 1984 03:53-EDT From: Christopher C. Stacy MC stopped answering the dialups in the afternoon, and when I came in long afterwards the system was apparently "dead"; it was not answering anything. It appeared to be running though. Unfortunately the front-end 11 seems to have dropped dead; I could not get to DDT or even 11DDT. I used the disk bootload button to get the 11 back, and stopped and dumped ITS to CRASH;ITS 11HUNG in case anyone wants it. Then I cold booted. Don't blame me. I wasn't installed.  Date: 27 July 1984 03:53-EDT From: Christopher C. Stacy Subject: front end 11 To: BUG-ITS @ MIT-MC cc: PGS @ MIT-MC MC stopped answering the dialups in the afternoon, and when I came in long afterwards the system was apparently "dead"; it was not answering anything. It appeared to be running though. Unfortunately the front-end 11 seems to have dropped dead; I could not get to DDT or even 11DDT. I used the disk bootload button to get the 11 back, and stopped and dumped ITS to CRASH;ITS 11HUNG in case anyone wants it. Then I cold booted.  Date: 25 July 1984 16:56-EDT From: Alan Bawden Subject: MC params To: BUG-ITS @ MIT-MC In-reply-to: Msg of 25 Jul 1984 16:41-EDT from J. Noel Chiappa Noel's message reminds me... Last night I moved the various notes and things that used to be taped to the inside front door of the first MF10 into the first MH10. Now most of that information actually has little to do with the MH10s, but I figured it was usefull to know what information we -used- to keep there in case anone ever decides to post some modern truth in that location. (I marked them as out of date in a big red pen.)  Date: 25 July 1984 16:41-EDT From: J. Noel Chiappa Subject: MC params To: BUG-ITS @ MIT-MC Since the whole Ampex seems to be online now, next time someone rebuilds the system they should change CONFIG > to allow MC to use all of the 2MW of memory on the system. Right now half the AMPEX is not being used.  Date: 20 July 1984 04:56-EDT From: Ken Harrenstien Subject: ITS seemed to be looping To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC Well, I am too tired to pursue it further tonight, but the fragments appear to have come from host GYMBLE by way of BBN-MILNET-GW; it had several SMTP connections open at the time. This doesn't help find the bug (for that it takes a lot of grovelling through the datagram buffers) but may serve as a warning signal.  Date: 20 July 1984 04:10-EDT From: Ken Harrenstien Subject: ITS seemed to be looping To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC Ignore my query about ITS version to :SL. I've been doing too much Unix ADB'ing and forgot ITS does the right thing as usual.  Date: 20 July 1984 04:04-EDT From: Ken Harrenstien Subject: ITS seemed to be looping To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC Keep CRASH;WHAT HEY around for a while. If your PC trace is right, it was looping in the IP fragment re-assembly code, which has in the past been a notorious source of bugs (since it is both very hard to understand and very seldom exercised). Can you tell me what version of ITS it was running, so I can :SL the symbols from the right file on .; (and please continue to take more crash dumps any time this happens, since it is unlikely that the bug can be determined just from one example). By the way, it makes sense that clock interrupts would be off, since this code runs at IMP interrupt level. Oh boy, time to play with PEEK autopsy mode again!  Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 65152; Mon 16-Jul-84 23:06:56-EDT Date: Mon, 16 Jul 84 23:06 EDT From: "David A. Moon" Subject: Ampex memory To: jnc@MIT-MC.ARPA cc: bug-its@MIT-MC.ARPA Message-ID: <840716230650.0.MOON@EUPHRATES.SCRC.Symbolics> Some (most? all?) of the ports on the Ampex memory don't work, I think because Ampex's transceiver cards for the DEC memory bus are flakey. That's probably why the cabling is weird. The interleaving options are all very confusing, especially since the cases that are not supposed to work actually do seem to work. I talked about this with CStacy this afternoon some. I think the bottom line is that you can put the system into 4-way interleave mode if all of ports 4 through 7 (or wherever the processor is plugged into) on the Ampex work, but if any of those ports are broken and can't be used you have to use 2-way interleave mode so the Ampex will still see all memory requests. It's also unclear whether 4-way mode is better since it should be only a few percent faster in the DEC memory (if I remember a measurement I made in about 1976 correctly) and should be substantially slower in the Ampex memory, since it can only do one operation at a time (two at a time when both sectors are working). MC:MOON;PERF > will measure various things but I don't know how you'll get the numbers for the MF10 configuration to compare against.  Date: 16 July 1984 15:45-EDT From: J. Noel Chiappa Subject: new memory To: BUG-ITS @ MIT-MC The MH10's are installed. They are 8 port (dual controller) boxes, so KBUS0-3 are bussed through all four boxes on port 7-4 (and thence to the Ampex ports 7-4). The DL10 is port 0, the RP10 is port 1, and the TM10 is port 2. (Don't ask why it's different from the Ampex). The TM10 bus is terminated on the last DEC box, as before, but the cable to the AMPEX is right there if anyone wants to plug it in for some reason. The MH10's are currently in 4-way interleave in the hardware. It looks like the processor is running two way interleaved; now that we have this wonderful working 4-way memory maybe we could switch back? Also, the AMPEX just got a write parity error on port 5. if this happens a lot someone should think about reseating the cables, etc. Finally, is there some sort of meter we can use to see if the machine is running faster?  Date: 16 July 1984 01:05-EDT From: Alan Bawden To: BUG-ITS @ MIT-MC CRASH;10JUL CRASH just happened again in exactly the same way. A comsat RESTRT job tried to rename STATS < to OSTATS >, and on the way out of the call it was noticed that there were still some locks locked.  ALAN@MIT-ML 07/14/84 06:45:02 To: (BUG ITS) at MIT-ML After remaining up for 13 days without even a memory error, ML finally crashed just now because of a software bug. At QSOC3E+15, on its way out of the system after trying to do an MLINK, an entry in QSNNR went negative. A dump of the same problem was taken by GSB a few weeks ago and can be found in MC:CRASH;QSOC3E +17@ML if anyone want to look for it...  Date: 14 July 1984 03:42-EDT From: Alan Bawden Subject: ITS seemed to be looping To: BUG-ITS @ MIT-MC In-reply-to: Msg of Sat 14 Jul 84 02:43 EDT from David A. Moon Date: Sat, 14 Jul 84 02:43 EDT From: David A. Moon Things to try: Raise switch 0 (the switch 0 on the left). If this goes to DDT, it's taking clock interrupts. Yeah, I forgot to mention that I tried that, and nothing happened. Hit Break and type PC . If I remember correctly, you can read the PC this way without halting the machine. There are some other status-type commands; PCF is the PC flags, PI is the interrupt status. OK, well it happened again which gave me a chance to try out the things I remembered from this message (wish I had made hardcopy as soon as I got it!). Repeated applications of PC showed it looping in the general vicinity of IPRD61 (assuming it was looping in the system, which is reasonable to assume if it isn't taking clock ints!). This is a routine in INET which looks to me like it might well loop given the right gubbish in memory. Perhaps with that information someone can take a look at the crash dump I took (still in CRASH;WHAT HEY) and figure out what caused this.  Date: 14 July 1984 03:27-EDT From: Alan Bawden Subject: Its a mystery to me. To: BUG-ITS @ MIT-MC cc: BUG-DDT @ MIT-MC How come when a job gets a parity error its superior DDT always gets a %PIB42? DDT seemingly get it simultaneous with the interrupt from the inferior, but thats what you would expect of a real B42, right? There doesn't seem to be anything wrong with what DDT is doing as far as I can tell...  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60736; Sat 14-Jul-84 02:40:13-EDT Date: Sat, 14 Jul 84 02:43 EDT From: "David A. Moon" Subject: ITS seemed to be looping To: alan@MIT-MC.ARPA Cc: bug-its@MIT-MC.ARPA Things to try: Raise switch 0 (the switch 0 on the left). If this goes to DDT, it's taking clock interrupts. Hit Break and type PC . If I remember correctly, you can read the PC this way without halting the machine. There are some other status-type commands; PCF is the PC flags, PI is the interrupt status. Hit Break and type SP . This stops the machine cleanly (between instructions). If this works, the microcode isn't looping. Now you can get the PC then type DDT (or ST 774000) to get into DDT and decode that PC. If the microcode is looping the SM command will restart it. This also does nasty things like resetting the I/O bus. I think it preserves the PC though. There is a command file, J KLHUNG, which prints out everything in sight. 90% of what it prints is worthless, but it includes micro and macro PCs. I believe there is a piece of paper taped to the machine that tells you to do J KLHUNG. Of course there are a lot of pieces of paper taped to the machine!  Date: 14 July 1984 01:50-EDT From: Alan Bawden To: BUG-ITS @ MIT-MC ITS died in a new way (for me) just now. The immediate symptoms were what I would expect if the microcode was looping. (No lights on any box were blinking, nothing was visibly doing anything, the system console had not printed anything to indicate anything was wrong.) I thrashed around a bit trying to find the KLDCP documentation to see if I could learn anything about what the processor was doing. When Taft found me a copy I was frustrated enough that I just took a crash dump (yeah, I know, thats probably worthless, its in CRASH;WHAT HEY) and reloaded it. So what should I have done?  Date: 11 July 1984 23:30-EDT From: Christopher C. Stacy Subject: ml doesn't get updates To: CENT @ MIT-MC cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 11 Jul 1984 23:16-EDT from Pandora B. Berman Aha, ML had the old version of INQUIR so that updates from MC went to ML, but ML didn't update itself! I installed the new one.  Date: 11 July 1984 23:16-EDT From: Pandora B. Berman Subject: ml doesn't get updates To: CSTACY @ MIT-MC cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC Date: 9 July 1984 16:02-EDT From: Christopher C. Stacy Subject: ml doesn't get updates To: CENT @ MIT-MC cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 9 Jul 1984 06:18-EDT from Pandora B. Berman ML should be getting updates; when it came back up I put it back in the list of machines to update and tested it. It worked for me; I'll look to see what is going wrong. i looked at the relevant STATS files. running INQUIR on ML creates a piece of mail to INQUPD at MC; this reaches MC and is only dealt with locally. at neither juncture is an INQUPD performed on ML.  Date: 11 July 1984 14:33-EDT From: Alan Bawden To: BUG-ITS @ MIT-MC In-reply-to: Msg of 10 Jul 1984 08:50-EDT from Patrick G. Sobalvarro Date: 10 July 1984 08:50-EDT From: Patrick G. Sobalvarro I found MC bug-halted. I dumped it to .;10JUL CRASH; dunno if anyone wants to poke at it. Actually its in CRASH;10JUL CRASH. While returning from a RENAME a job discovered it still had some locks locked. MC was parity erroring a bit at the time. Should we worry about this harder?  Date: 11 July 1984 11:27-EDT From: J. Noel Chiappa Subject: SECOND: hardwarily back To: BUG-ITS @ MIT-MC Drive 1 is fixed, but I can't remember how to invoke UCOP to bring the directories over. Someone should bring the system down and bring it back up with SECOND: around.  Date: Tue, 10 Jul 1984 21:10 EDT Message-ID: From: Jerry Roylance To: CHAOS-MAINT@MC, BUG-ITS@MC Subject: Subnet 6 Subnet 6 was broken at the MC bulkhead (return of the bad UHF connectors). The MC transceiver's power connector was also broken; everything is now in order.  Date: 10 July 1984 08:50-EDT From: Patrick G. Sobalvarro To: BUG-ITS @ MIT-MC I found MC bug-halted. I dumped it to .;10JUL CRASH; dunno if anyone wants to poke at it.  Date: 10 July 1984 00:49-EDT From: Alan Bawden To: DCP @ MIT-MC cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, CSTACY @ MIT-MC In-reply-to: Msg of 10 Jul 1984 00:19-EDT from David C. Plummer Date: 10 July 1984 00:19-EDT From: David C. Plummer I'm still not a speed reader. (I'm coming in over a vadic, AAA, ITS 1370, DDT 1480.) U prints the bye message and then clears the screen. OK, OK. I fixed it again. If its still broken, perhaps you better see Evelyn Wood, because I can't imagine how I can have failed to fix it this time.  Date: 10 July 1984 00:19-EDT From: David C. Plummer To: ALAN @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC, CSTACY @ MIT-MC I'm still not a speed reader. (I'm coming in over a vadic, AAA, ITS 1370, DDT 1480.) U prints the bye message and then clears the screen.  Date: 9 July 1984 19:10-EDT From: Alan Bawden Subject: oops To: DCP @ MIT-MC, BUG-DDT @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 9 Jul 1984 10:14-EDT from David C. Plummer Date: 9 July 1984 10:14-EDT From: David C. Plummer Either ITS was changed, or DDT was, and for the worse. When I log out, it does a :BYE followed by :OUTEST. I don't think either of these are at fault. What happens is that it prints the BYE message, and then clears the screen before printing the console free message. Needless to say, I'm not a speed reader. Believe it or not, another symptom of this same bug was the fact that :CHUNAME didn't work anymore. I fixed the bug and installed a new DDT.  Date: 9 July 1984 16:35-EDT From: Christopher C. Stacy To: BUG-DDT @ MIT-MC cc: BUG-ITS @ MIT-MC I de-installed the latest DDT, since there are all these bug reports coming in and the responsible hacker is asleep now.  Date: 9 July 1984 16:02-EDT From: Christopher C. Stacy Subject: ml doesn't get updates To: CENT @ MIT-MC cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 9 Jul 1984 06:18-EDT from Pandora B. Berman ML should be getting updates; when it came back up I put it back in the list of machines to update and tested it. It worked for me; I'll look to see what is going wrong.  Date: 9 July 1984 11:25-EDT From: Jeffrey P. Golden Subject: CHUNAME To: BUG-ITS @ MIT-MC When I am logged in as JEFFG and do :CHUNAME JPG It says OP? and won't chuname me.  Date: 9 July 1984 10:14-EDT From: David C. Plummer To: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC Either ITS was changed, or DDT was, and for the worse. When I log out, it does a :BYE followed by :OUTEST. I don't think either of these are at fault. What happens is that it prints the BYE message, and then clears the screen before printing the console free message. Needless to say, I'm not a speed reader.  Date: 9 July 1984 06:18-EDT From: Pandora B. Berman Subject: ml doesn't get updates To: BUG-INQUIR @ MIT-MC cc: BUG-ITS @ MIT-MC i modified my inquir entry a week ago to reflect my new office. ML still thinks i'm in 912. this is a bug. As long as ML is going to stay around for the indefinite (and probably not too short) future, would whoever diked it out of the inquir-update path please put it in again?  Date: 8 July 1984 15:38-EDT From: Christopher C. Stacy Subject: MLDEV To: BUG-ITS @ MIT-MC MLDEV does not work between ITS machines except via Chaosnet. Reminder to me to make it check for alternate host addresses on the ARPAnet and try them if Chaos is unresponsive.  Date: 7 July 1984 16:55-EDT From: Charles Frankston Subject: The saga of Subnet 6 To: CHAOS-MAINT @ MIT-MC, BUG-ITS @ MIT-MC cc: RZ @ MIT-MC MC-IO-11 and TOTO (OZ's network front end) don't communicate on subnet 6. Each one can apparently communicate with most of the other machines on subnet 6, but not with each other. DPH said that subnet 6 was extended a few days ago, which is apparently when this problem started. My guess is that TOTO can send to MC-IO-11 since TOTO's routing table says to use subnet 1 to talk to MC rather than subnet 6, but for some reason MC-IO-11 probably tries to use subnet 6 to talk to TOTO and this loses. Unplugging the MC-IO-11 subnet 6 interface allows MC and OZ to communicate. This is the state things have been left in. However, this causes hosts which do not implement dynamic routing, such as ML and MIT-VAX to be unable to talk to MC, since they think that subnet 6 is the way to get there..  Date: 7 July 1984 00:20-EDT From: Alan Bawden Subject: MC (not) broken To: BUG-ITS @ MIT-MC cc: DPH @ MIT-MC In-reply-to: Msg of Fri 6 Jul 1984 23:34 EDT from PGS at MIT-OZ Date: Thursday, 5 July 1984 18:12-EDT From: Christopher C. Stacy Something is wrong with MC's hardware. ITS is having trouble talking to the T-300s, and can barely reach the Chaosnet (even though the ncp statistics look reasonable). Users were getting wedged today unable to log out; one of my jobs was stuck in a CLOSE call with a FLSINS of zero. DPH reports that the IO-11 dropped very dead earlier. Just for the record, DPH disconnected MC from subnet 6 and all the Chaos net problems went away. Other wierdnesses reported by CStacy may or may not have anything to do with this. DPH should put himself on Bug-ITS.  Date: Fri, 6 Jul 1984 23:34 EDT Message-ID: From: PGS@MIT-OZ To: "Christopher C. Stacy" Cc: BUG-ITS@MIT-MC Subject: MC broken In-reply-to: Msg of 5 Jul 1984 18:12-EDT from Christopher C. Stacy Date: Thursday, 5 July 1984 18:12-EDT From: Christopher C. Stacy To: BUG-ITS at MIT-MC cc: BEDE at MIT-XX, MOON at SCRC-STONY-BROOK Re: MC broken Something is wrong with MC's hardware. ITS is having trouble talking to the T-300s, and can barely reach the Chaosnet (even though the ncp statistics look reasonable). Users were getting wedged today unable to log out; one of my jobs was stuck in a CLOSE call with a FLSINS of zero. DPH reports that the IO-11 dropped very dead earlier. Two mysteries: 1. What are these blue wires running around MC? Someone told me they are an attempt to "make MC think it is talking to the ROLM switch by faking out the DL-10 or something?" I suspect that this is just Ty trying to connect Rolm switch lines to normal tty lines (not under modem control). If you find out that it's something else, would you let me know?  Date: 5 July 1984 18:40-EDT From: Alan Bawden Subject: :HOSTAT To: BUG-ITS @ MIT-MC cc: PGS @ MIT-MC In-reply-to: Msg of 5 Jul 1984 14:21-EDT from Patrick G. Sobalvarro Date: 5 July 1984 14:21-EDT From: Patrick G. Sobalvarro To: BUG-ITS :hostat ai-chaos-11 gives sysbin; hosts1 > - file not found. I deleted the obsolete HOSTAT program so that people would stop being confused.  Date: 5 July 1984 18:12-EDT From: Christopher C. Stacy Subject: MC broken To: BUG-ITS @ MIT-MC cc: BEDE @ MIT-XX, MOON @ SCRC-STONY-BROOK Something is wrong with MC's hardware. ITS is having trouble talking to the T-300s, and can barely reach the Chaosnet (even though the ncp statistics look reasonable). Users were getting wedged today unable to log out; one of my jobs was stuck in a CLOSE call with a FLSINS of zero. DPH reports that the IO-11 dropped very dead earlier. Two mysteries: 1. What are these blue wires running around MC? Someone told me they are an attempt to "make MC think it is talking to the ROLM switch by faking out the DL-10 or something?" 2. The DEC log book says that the DL-10 had a bad module which was not replaced, but which was moved to another slot and that now everything "works fine". If no one has any good ideas, I will call DEC and have them see about working on the DL-10 again. Meanwhile, the system is not very usable.  Date: 5 July 1984 14:21-EDT From: Patrick G. Sobalvarro To: BUG-ITS @ MIT-MC :hostat ai-chaos-11 gives sysbin; hosts1 > - file not found.  Date: 4 July 1984 05:52-EDT From: David Vinayak Wallace To: BUG-ITS @ MIT-MC MC appears to be unable to talk to OZ (finger, telnet, supdup), but finds is with :UP. Has no trouble with other chaos hosts I tried (prep, eddie, speech).  MOON@MIT-ML 07/04/84 05:10:46 Re: HOSTAT OBERON To: (BUG ITS) at MIT-ML CC: GSB at MIT-ML, PSZ at MIT-ML :HOSTAT is an ancient program that retrieves a report on Arpanet hosts from DM. Obviously it should be flushed in favor of a program that uses Chaosnet HOSTAT protocol as PSZ evidently expected..  Date: 4 July 1984 01:59-EDT From: Glenn S. Burke Subject: [Forwarded: PSZ@MIT-MC, Re: ] To: BUG-ITS @ MIT-MC PSZ@MIT-MC 07/03/84 23:29:43 :HOSTAT OBERON on MC says: sysbin;hosts1 > - file not found.  Date: 25 June 1984 04:39-EDT From: David A. Moon To: BUG-ITS @ MIT-MC T10 on MC is broken. Twice I dialed up to it and my input was thoroughly garbled. I redialed to T12 and had no problems.  Date: 20 June 1984 23:16-EDT From: Charles Frankston To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC The dialup garbage is NOT Concept 100 control sequences. It seems to happen with me on triple modems, which seem to raise Carrier Detect before they've quite settled, perhaps before they're synchornized. If you wait an extra two seconds after dialing up before typing return, it probably won't happen.  Date: 20 June 1984 18:23-EDT From: Alan Bawden Subject: Dialup Gubble To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 20 Jun 1984 15:24-EDT from Christopher C. Stacy Date: 20 June 1984 15:24-EDT From: Christopher C. Stacy Sometimes when I dial in to the Vadics, ITS sends alot of unrecognizable garbage to my terminal when printing out the greeting message. This goes away after a TCTYP command, and a friend of mine on a VT100 claims the garbage looks like Concept-100 terminal control sequences, although on my AAA it just prints blobs. If this was true, then wouldn't everybody who uses Vadics see randomness when they dial up? (At least occasionally.) I have never seen anything of the sort. Perhaps its marsh gas?  Date: 20 June 1984 15:24-EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Sometimes when I dial in to the Vadics, ITS sends alot of unrecognizable garbage to my terminal when printing out the greeting message. This goes away after a TCTYP command, and a friend of mine on a VT100 claims the garbage looks like Concept-100 terminal control sequences, although on my AAA it just prints blobs.  Date: Sun 17 Jun 84 14:10:44-EDT From: J. Noel Chiappa Subject: Re: Looping in the scheduler (with interrupts on, luckily) To: DCP@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "David C. Plummer " of Sat 16 Jun 84 20:14:00-EDT I think this was due to the console 11 dying. It seemed to be completely frozted; i.e. trying "LOAD ADDR" didn't result in whatever number you had in the switches showing up in the ADDR lights. -------  Date: 16 June 1984 20:14-EDT From: David C. Plummer Sender: DCP0 @ MIT-MC Subject: Looping in the scheduler (with interrupts on, luckily) To: BUG-ITS @ MIT-MC This morning I dialed up MC and got on T12. I was merrily doing random things. I didn't do anything for a while, but when I tried I got no response. I figured MC died. I was wrong. Just recently ALAN noticed I was around and informed me that not only was my job still there, but it was taking up all the extra computrons MC could offer. It was looping in TYSTE1 waiting for the -11 to set DTEOST to some negative value. The -11 wasn't doing this. The job could not be logged out or easily examined because it couldn't be PCLSRed. The first thing I tried was to tell the job (by bashing the PC) to try sending another doorbell to the -11. That didn't work. So, I set DTEOST to -1 by myself. The job unfroze and we had control again (for some value of control). Sending a TTY message to that console (causing output) now waits at TYOW4 waiting for the output buffer to be sufficiently empty to output. This will never happen, but at least it is PCLSRable and doesn't take up the entire machine. As experiments, I tried using T13 and T14. The first attempt to output on these caused the same phenomena: Looping in TYSTE1. Bashing DTEOST to -1 and outputing again caused waiting at TYOW4. (Using :COPY to the TTY line was sufficient to cause this.) This unfortunately means T12, T13, and T14 are no longer usable for experimentation unless you go in and reset the pointers and counts... This is probably just a hardware lossage and requires MC to be rebooted to get the piece of dung -11 unwedged.  Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 46531; Mon 11-Jun-84 08:04:08-EDT Date: Mon, 11 Jun 84 08:02 EDT From: "Daniel L. Weinreb" Subject: TCP gatway To: BUG-LISPM@SCRC-RIVERSIDE.ARPA Cc: bug-its@MIT-MC.ARPA Message-ID: <840611080222.9.DLW@CHICOPEE.SCRC.Symbolics> In Symbolics 3600 Experimental System 243.758, Experimental Hardcopy 21.31, Experimental Zmail 84.157, Experimental LMFS 38.91, Experimental Tape 22.17, Experimental Basic Sage 2.26, Experimental New Documentation System 2.0, Experimental Print 35.10, Experimental IP-TCP 9.1, Japanese 15.0, Experimental TD80-Tape 1.22, cold load 114, microcode TMC5-MIC 290, FEP 18, Big band, on Chicopee: >>Error: Unable to invoke FILE (TCP-FTP) -- CMU-CS-SPICE (via MC on CHAOS) by any path. TCP-GATEWAY (TCP-GATEWAY) -- MC on CHAOS: Cannot connect to 21 at CMU-CS-SPICE via MC: Request to MC for a TCP 128.2.254.139 25 connection was refused. Reason given was "TCP connection to foreign host failed" While in the function NETI:GET-CONNECTION-FOR-SERVICE-1  NET:GET-CONNECTION-FOR-SERVICE  (:DEFUN-METHOD FS:TCP-FTP-VALIDATE-CONN) It would be nice if the MC gateway would pass on some more info than just "conection to foreign host failed". If you try to FTP to CMU-CS-SPICE right now, using FTPU on MC, it says that "Request for Connection was refused by foreign host"; it would be nice it this info had been passed through by the gateway.  Date: 12 June 1984 15:03-EDT From: Christopher C. Stacy Subject: Reconnecting Spock's brain. To: ALAN @ MIT-MC cc: BUG-TIMES @ MIT-MC, BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 12 Jun 1984 00:13-EDT from Alan Bawden Date: 12 June 1984 00:13-EDT From: Alan Bawden To: BUG-TIMES Re: Reconnecting Spock's brain. I am quite certain that the TIMES/CTIMES program is totally broken. The other night when MC was mistaken about the correct time, Penny ran :TIMES to find out what other sites on the net thought the time was. To our surprise the program reported that every machine it could reach more-or-less agreed with MC's bogus time. When Penny ran PDSET to correct MC, every machine made the corresponding correction. I also observe that the times the program reports are ALWAYS in ascending order! I think it is quite obvious what is going on here... I have fixed this, and spiffed the program up a little while at it.  Date: 23 May 1984 00:49-EDT From: Alan Bawden Subject: CRASH;STACKP FUCKED To: BUG-ITS @ MIT-MC I have just been informed by GSB that he made a crash dump of an ITS that had died trying to read an ML backup tape last Friday. Since it looks like this is a repeatable error (DLW crashed MC a couple of times trying to read in an AI backup tape last Sunday), its probably worth looking at. Note that there seems to be no trouble reading in MC's backup tapes. The dump GSB took is in CRASH;STACKP FUCKED. If you look at what's in P you will understand the name.  Date: 17 May 1984 23:43-EDT From: David Vinayak Wallace Subject: TENEX Remembered: Foo! To: CBF @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 17 May 1984 22:09-EDT from Charles Frankston Date: 17 May 1984 22:09-EDT From: Charles Frankston [From a letter about TENEX:] Date: 17 May 1984 13:14-EDT From: DIPACE at BBNF.ARPA Demand-paged-virtual memory, the first one of its kind; The question is, was it? Wasn't paging ITS around before TENEX? I believe so. But so certanly was the University of Manchester Atlas, Multics, and possibly the Berkeley XDS 940 time sharing system, although I don't know if it counts a demand paged. Oh, yeah, 360/67, TSS, CP/CMS, probably also both predate Tenex, but I'm not sure.. Foo. You know I meant on PDP-10s. Didn't ITS start out Base-and-bounds?  Date: 17 May 1984 22:09-EDT From: Charles Frankston Subject: TENEX Remembered To: GUMBY @ MIT-MC cc: BUG-ITS @ MIT-MC [From a letter about TENEX:] Date: 17 May 1984 13:14-EDT From: DIPACE at BBNF.ARPA Demand-paged-virtual memory, the first one of its kind; The question is, was it? Wasn't paging ITS around before TENEX? I believe so. But so certanly was the University of Manchester Atlas, Multics, and possibly the Berkeley XDS 940 time sharing system, although I don't know if it counts a demand paged. Oh, yeah, 360/67, TSS, CP/CMS, probably also both predate Tenex, but I'm not sure..  Date: 17 May 1984 21:06-EDT From: David Vinayak Wallace Subject: TENEX Remembered To: BUG-ITS @ MIT-MC In-reply-to: Msg of 17 May 1984 13:14-EDT from DIPACE at BBNF.ARPA [From a letter about TENEX:] Date: 17 May 1984 13:14-EDT From: DIPACE at BBNF.ARPA Demand-paged-virtual memory, the first one of its kind; The question is, was it? Wasn't paging ITS around before TENEX?  Date: 12 May 1984 18:14-EDT From: Kent M Pitman To: ELAN @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 12 May 1984 15:32-EDT From: Phyllis E. Koton Sender: ING @ MIT-MC Re: bizarre dialup error To: KMP @ MIT-MC The weirdest thing happened to me. I dialed up MC from home, hit a carriage return to get ITS attention, and it echoed the CR, but didn't print out any msg. SO I hit CR again, and again it echoed it, but no MC ITS ... so just to see what was going on, I said ":versio" and it said I was MC ITS USR:ING. IS THAT THE STRANGEST THING? I did whois on this ING and he is some tourist on the system. But I got logged in as him without ever saying login or giving a password. I am really psyched out by this. Do you think I should send mail to bug-its? --pk This isn't the first time such a thing has happened. Your guess is probably correct; ING somehow hung up without ITS noticing so when you dialed in, you got his already-logged-in tty line. I'm forwarding this to BUG-ITS in case they care, but I wouldn't lose any sleep over it. -kmp  Date: 8 May 1984 14:39-EDT From: Alan Bawden Subject: This afternoon's crash To: BUG-ITS @ MIT-MC TTY: BUFFER EMPTY AT TYIREM Dumped into CRASH;TYIREM 050884  Date: 2 May 1984 20:41-EDT From: Jacob Moskowitz To: BUG-ITS @ MIT-MC cc: CAREY @ MIT-MC I just logged in to the 300 baud line & discovered that I was already logged in as CAREY. Shouldn't ITS autologout on disconnect ?  Date: 2 May 1984 09:39 PDT (Wed) Message-ID: <[SRI-NIC].IAN. 2-May-84 09:39:34> From: Ian Macky To: Richard M. Stallman Cc: BUG-ITS@MIT-MC In-reply-to: Msg of 2 May 1984 02:00-PDT from Richard M. Stallman Date: Wednesday, 2 May 1984 02:00-PDT From: Richard M. Stallman To: BUG-ITS at MIT-MC When I supdup to MC, if I get tty 50, most characters do not echo and are not obeyed. Only rubout and control-G get any response from DDT. :TCTYP TTY 50 DESC shows exactly the same thing as other ttys that I get which work properly. I locked tty 50. The exact thing has happened to me before, too, many months ago tho.  Date: 2 May 1984 05:00-EDT From: Richard M. Stallman To: BUG-ITS @ MIT-MC When I supdup to MC, if I get tty 50, most characters do not echo and are not obeyed. Only rubout and control-G get any response from DDT. :TCTYP TTY 50 DESC shows exactly the same thing as other ttys that I get which work properly. I locked tty 50.  Date: 2 May 1984 04:57-EDT From: Patrick G. Sobalvarro To: BUG-ITS @ MIT-MC I'm unable to supdup to MC right now, because the supdup server claims that all network ports are in use, although only t42-t51 are in use. nsttys is 27, so we should be able to do better than this. The ttys actually seem to be there; could this be caused by someone not reassembling the supdup server after the last system installation?  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 25977; Wed 2-May-84 00:52:55-EDT Date: Wed, 2 May 84 00:54 EDT From: "David A. Moon" Subject: Meter hardware on MC To: BUG-ITS@MIT-MC.ARPA In-reply-to: The message of 2 Feb 84 01:34-EST from David A. Moon Date: 2 February 1984 01:34 EST From: David A. Moon DATAI 24,n executed in user mode clobbers locations n and n+1 in the system! It's a good thing I tested this by hand before writing a program to use it. ITS executes the instruction with XCTR, as it should. I suspect this is a bug in the microcode. I guess I'll use .suset [.rrunt,, like a good little boy. ------- I looked at the microcode and now think it's a bug in the hardware (MCL board of course). EPT REF clears the flag that SET PXCT sets? Fixed in the source of ITS! (Cleaning out my mail file).  Date: 22 April 1984 20:51-EST From: Alan Bawden Subject: Hack attack. To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC I just amused myself by recreating the source of SYS:ATSIGN DEVICE from the binary. I restrained myself from fixing any of its problems until I got it to work. Those results can be found in ALAN;@DEV 40. Then I made a couple of trivial changes (@DEV 43), debugged them, and installed it. I'll install the source in a better place as soon as I am sure I am done with it. I renamed the old binary to be ATSIGN ODEVIC in case of disaster. Things in the source I had questions about are commented with ";???". In the bugs-you-can-only-find-by-reading-the-source department: o I fixed the problem where the "<0" and ">0" devices refered to the D and ARC devices respectively. o I didn't do anything about KMP's complaint that SYS4^F in DDT is confusing. o I found a related randomness; try typing THIRD7^F to DDT.  Date: 13 April 1984 08:14-EST From: Ken Harrenstien Subject: IPQ: To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC The IPQ: device is for getting a handle on Internet Packet Queues. Its main purpose was to allow UDP user/server programs to be written, but it is also used by a packet-log debugging program. I don't consider it complete yet -- it works, but is difficult to use. There were never (and still aren't really) any good examples of things to use UDP for, so it didn't have high priority and thus was never simplified.  Date: 13 April 1984 01:05-EST From: Alan Bawden Subject: Why aren't you working on your thesis? To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 11 Mar 1984 16:48-EST from Alan Bawden Date: 11 March 1984 16:48-EST From: Alan Bawden RFNAME on a SPY: channel should return the appropriate FN1. RFNAME on a CHAOS: channel should return as a directory name a host number just like TCP: channels. I just implemented both of these. Whoever next installs a new ITS should try them out. KLH: What is the IPQ: device all about?  Date: 9 April 1984 20:25-EST From: Ken Harrenstien Subject: TCP Bug To: CLYNN @ BBNA cc: BUG-FTP @ MIT-MC, BUG-TCP @ MIT-MC, BUG-ITS @ MIT-MC, Barrett @ BBNG I fixed this bug (ACK 1 too high) in the source; someone assemble a new ITS one of these days. I also patched the running ITS on MC, so that CLynn can re-test right away to verify that it now works. (But didn't patch the ITS on disk, in case he wants to use the bug for a while to debug the TOPS-20 side).  Date: 30 Mar 1984 04:39 EST (Fri) Message-ID: From: Martin David Connor To: BUG-ITS@MIT-MC Subject: [Who?: forwarded] Could someone stop MC from sending unparsable ITS mail headers out onto the network? Received: from MIT-MC by MIT-OZ via Chaosnet; 30 Mar 84 02:26-EST TK@MIT-MC 03/30/84 02:08:32 To: marty at MIT-OZ Indeed. It's about 65 degrees and was sunny until the sun went down. It was "cold" today, and everyone was complaining.  Date: 28 March 1984 19:38-EST From: Glenn S. Burke Subject: ucprl5+1 again To: BUG-ITS @ MIT-MC dumped to crash;ucplr5 gsb1 Also complained about extra garbage in ufd STUDNT. From the looks of the return action on the system console, it's about to go again. It's definitely dropping characters too.  Date: 28 March 1984 16:44-EST From: Alan Bawden Subject: All is not well... To: BUG-ITS @ MIT-MC MC crashed twice this afternoon at QINTE+44. Crash dump in CRASH;QINTE +44. Some kind of disk hardware lossage? While I was sitting here it crashed again at UCPRL5+1. Thats in CRASH;UCPRL5 +1. Some kind of screwup running around circular page lists.  Date: 23 March 1984 05:28-EST From: Ken Harrenstien Subject: ITSDOC? To: ALAN @ MIT-MC cc: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC P.S. you might want to consider calling it SYSDOC instead, because this has the feature that changes to files therein will be reported on the system console. Not a real vital issue.  Date: 23 March 1984 05:25-EST From: Ken Harrenstien Subject: ITSDOC? To: ALAN @ MIT-MC cc: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC Actually I have been tempted a couple of times recently to revive the ITSDOC directory and set the documentation up as it was on AI, where .INFO.;ITS FOO was usually a link to ITSDOC;FOO >. This has the advantage of letting us keep numbered versions of the documentation, and given that I am frobbing the documentation occasionally these days, it might be nice to not always immediately lose the previous version. I like that idea!  Date: 19 March 1984 02:56-EST From: Alan Bawden Subject: ITSDOC? To: GUMBY @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 19 Mar 1984 02:09-EST from David Vinayak Wallace Date: 19 March 1984 02:09-EST From: David Vinayak Wallace What happened to the ITSDOC directory? When I wondered the same thing, we went and looked at AI backups to discover just where was kept there. What we found was nothing that isn't now named MC:.INFO.;ITS. Actually I have been tempted a couple of times recently to revive the ITSDOC directory and set the documentation up as it was on AI, where .INFO.;ITS FOO was usually a link to ITSDOC;FOO >. This has the advantage of letting us keep numbered versions of the documentation, and given that I am frobbing the documentation occasionally these days, it might be nice to not always immediately lose the previous version.  Date: 19 March 1984 02:09-EST From: David Vinayak Wallace Subject: ITSDOC? To: BUG-ITS @ MIT-MC What happened to the ITSDOC directory?  Received: from MIT-LISPM-31 by MIT-OZ via Chaosnet; 18 Mar 84 19:29-EST Date: Sunday, 18 March 1984, 19:29-EST From: Patrick G. Sobalvarro Subject: T03 SDRC ? To: KMP at MIT-MC, CStacy at MIT-MC, BUG-ITS at MIT-MC In-reply-to: The message of 18 Mar 1984 16:31-EST from Kent M Pitman Received: from MIT-MC by MIT-OZ via Chaosnet; 18 Mar 84 16:32-EST Date: 18 March 1984 16:31-EST From: Kent M Pitman Subject: T03 SDRC ? To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC I am pretty sure that T03 is not a line to SDRC any more. I think it is just a 300 baud dialup like T04-T07. Could someone please check this and update its info in whatever database is used by FINGER? Thanks. -kmp CStacy seems to have done this, but the 11 does not think that this line is under modem control, so it won't work very well as one. When I next work on this tty line cruft I'll change this, if the thing really is a dialup line. Incidentally, if T03 is a dialup now, what phone is it connected to?  Date: 18 March 1984 16:31-EST From: Kent M Pitman Subject: T03 SDRC ? To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC I am pretty sure that T03 is not a line to SDRC any more. I think it is just a 300 baud dialup like T04-T07. Could someone please check this and update its info in whatever database is used by FINGER? Thanks. -kmp  Date: 13 March 1984 15:22-EST From: Ken Harrenstien Subject: CRASH;IPQUSI To: BUG-ITS @ MIT-MC, GSB @ MIT-MC Thanks for the dump. I have fixed the bug in the source (INET), but did not bother to patch the current binary. ITS should be re-assembled one of these days. What happened was that a bad UDP datagram arrived which was not long enough to hold a UDP header. Bug #1 was not checking the length for this. Fortunately the UDP dest port value happened to be zero in that buffer, so the code tried to find a UDP queue for port 0. Bug #2 was that this succeeded -- it "found" an non-existent queue with all the relevant info zero. IPQUSI caught this when it noticed it was about to try interrupting the system job! Both bugs are now fixed, and I deleted the crash dump.  Date: 13 March 1984 12:17-EST From: Alan Bawden To: CSTACY @ MIT-MC cc: BUG-DDT @ MIT-MC, BUG-ITS @ MIT-MC, KMP @ MIT-MC In-reply-to: Msg of Tue 13 Mar 84 06:54 EST from Christopher C. Stacy Date: Tue, 13 Mar 84 06:54 EST From: Christopher C. Stacy Date: 29 February 1984 10:59-EST From: Kent M Pitman SYS4^F clears the screen and types NON-DIRECTORY DEVICE. Shouldn't this give a no such directory error? I assume DDT or ITS is somehow stripping the 4 and assuming I'm trying to reference the SYS device. My file defaults end up with SYS4: in them... I think this might be an ITS bug. In DDT at NCTLF2, it tries to open the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason, and succeeds. As I already said, the place to do something about this is in the unknown device handler. (You know, SYS;ATSIGN DEVICE? The file we don't have a source for?) ITS proper, and DDT are doing exactly the right things.  Date: Tue, 13 Mar 84 06:54 EST From: "Christopher C. Stacy" To: BUG-ITS@MIT-MC.ARPA Cc: Kent M Pitman , BUG-DDT@MIT-MC.ARPA In-reply-to: The message of 29 Feb 84 10:59-EST from Kent M Pitman Date: 29 February 1984 10:59-EST From: Kent M Pitman SYS4^F clears the screen and types NON-DIRECTORY DEVICE. Shouldn't this give a no such directory error? I assume DDT or ITS is somehow stripping the 4 and assuming I'm trying to reference the SYS device. My file defaults end up with SYS4: in them... I think this might be an ITS bug. In DDT at NCTLF2, it tries to open the file "SYS4:.FILE. (DIR)", starts up a JOB.07 frob for some reason, and succeeds.  Date: 12 March 1984 22:12-EST From: Glenn S. Burke Sender: GSB5 @ MIT-MC Subject: crash dumps To: BUG-ITS @ MIT-MC cc: BUG-TCP @ MIT-MC bughalt at IPQUSI+6, dumped to CRASH;IPQUSI 031284. a couple days ago, bughalt at TYIREM (actually TYIRE1+1), dumped to CRASH;TYIREM 030984.  Date: 11 March 1984 16:48-EST From: Alan Bawden Subject: RFNAME & randomness To: BUG-ITS @ MIT-MC RFNAME on a SPY: channel should return the appropriate FN1. RFNAME on a CHAOS: channel should return as a directory name a host number just like TCP: channels. BTW, I have always felt that when opening the CLI: device, filenames should be treated exactly as they are when you open the USR: device. That is, you should be able to use a specification as the first filename if the second filename is 0.  Date: 10 March 1984 18:52-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC cc: ALAN @ MIT-MC ITS was losing from network and local terminals (although apparently working ok from dialups). The 11 didn't seem to have a parity error light on and was not obviously stopped or anything, but we (ALAN and I) did :.;BOOT11 and the world went back to normal. Is this the right thing to have done and/or is there any more debugging information we could have scrounged up before reloading the 11? -kmp  Date: 9 March 1984 10:46-EST From: John G. Aspinall Subject: jga;ar3: To: CSTACY @ MIT-MC cc: ALAN @ MIT-MC, BUG-ARCDEV @ MIT-MC In-reply-to: Msg of 9 Mar 1984 08:01-EST from Christopher C. Stacy Alan fixed it. I guess neither of us sent a follow up. Sorry to make unneeded work. cheers...  Date: 9 March 1984 08:01-EST From: Christopher C. Stacy Subject: jga;ar3: To: JGA @ MIT-MC cc: ALAN @ MIT-MC, BUG-ARCDEV @ MIT-MC In-reply-to: Msg of 7 Mar 1984 11:40-EST from John G. Aspinall Maybe you already copied the files into a new AR3:, since reading and writing files there works fine for me.  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Fri 9-Mar-84 02:41:11-EST Return-path: Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 24-Jan-84 16:54:39-EST Received: from SCRC-EUPHRATES by SCRC-YUKON with CHAOS; Tue 24-Jan-84 16:43:46-EST Date: Tuesday, 24 January 1984, 16:54-EST From: David A. Moon Subject: The MC chaosnet ARPA server To: GZ at MIT-OZ Cc: CStacy at MIT-MC, Moon at SCRC-TENEX Redistributed-to: Ian@SRI-NIC.ARPA, BUG-ITS@MIT-MC.ARPA Redistributed-by: Moon%SCRC-TENEX@MIT-MC.ARPA Redistributed-date: Fri, 9 Mar 84 02:33 EST Date: Tue 24 Jan 84 04:43-EST From: Gail Zacharias Subject: The MC chaosnet ARPA server To: moon@MIT-MC, cstacy@MIT-MC CC: gz%MIT-OZ@MIT-MC.ARPA Connecting to this nowadays closes the connection with the close text of: ? Internal error - NO SUCH DEVICE I think the gateway used to (sort of) work in the past. Well, it works for me, for both FTP and FINGER. Ah, but wait a minute, I'm using the TCP server and you're using the ARPA server. They're the same program, but the contact name controls the order of trying networks. I just looked at the source (MC:MMCM;ARPA) and if you use it as the ARPA server it first tries TCP then if that fails tries NCP. But NCP ain't implemented anymore which is why you get "no such device" rather than "destination host dead" or something of the sort. I guess a little restructuring of this code is called for.  Date: 9 March 1984 02:15-EST From: Glenn S. Burke Sender: GSB5 @ MIT-MC Subject: MIT Miraculous Levitation PDP-10 To: Ian @ SRI-NIC cc: BUG-ITS @ MIT-MC Date: 8 Mar 1984 20:45 PST (Thu) From: Ian Macky . . . The "internal error" was apparently due to cca's being down. And ML has officially gone west. But it hasn't reached the horizon yet, so don't dyke it out of the host tables. Its disk has been fixed, and its processor/pager problem is going to be worked on this weekend. While i don't expect it to accept incoming net connections ever, it will certainly need to reach out and write some files.  Date: 8 Mar 1984 20:45 PST (Thu) Message-ID: <[SRI-NIC].IAN. 8-Mar-84 20:45:34> From: Ian Macky To: BUG-ITS@MC Subject: [DJC%MIT-OZ: no such device + no such machine] I can't think of a better place for this to go, since I forget the same of the server that the OZ FINGER uses... Date: Thursday, 8 March 1984 18:03-PST From: DJC%MIT-OZ at MIT-MC.ARPA To: bug-finger%MIT-OZ at MIT-MC.ARPA Re: no such device + no such machine Received: from MIT-MC by SRI-NIC with TCP; Thu 8 Mar 84 18:08:06-PST [PHOTO: Recording initiated Thu 8-Mar-84 8:58PM] MIT TOPS-20 Command Processor 5(750)-2 End of ATTACH.CMD.7 End of COMAND.CMD.5 @f chan@cca [CCA-UNIX via MIT-MC] ? Internal error - NO SUCH DEVICE [CCA-UNIX via MIT-ML] %No response %No path to site @pop [PHOTO: Recording terminated Thu 8-Mar-84 9:00PM] The "internal error" was apparently due to cca's being down. And ML has officially gone west.  Date: 7 March 1984 11:40-EST From: John G. Aspinall Subject: jga;ar3: To: BUG-ARCDEV @ MIT-MC, ALAN @ MIT-MC JGA;AR3: seems to have suffered in the recent archive brouhaha, at least I get a hung job every time I try to copy into it. Could someone knowledgeable take a look at it, and give me an informed opinion on whether I should go into salvage mode?  Date: Sun, 4 Mar 1984 14:58 EST Message-ID: From: Alan Bawden To: DCP@MIT-MC, BUG-ITS@MIT-MC Cc: BUG-OZ@MIT-MC, "Devon S. McCullough" Subject: %TPC.C In-reply-to: Msg of 4 Mar 1984 00:00-EST from Devon S. McCullough Date: Sunday, 4 March 1984 00:00-EST From: Devon S. McCullough To: BUG-OZ at MIT-MC Re: SET TERMINAL ETX-IS-^C Date: 3 March 1984 20:50-EST From: David C. Plummer To: DEVON @ MIT-MC cc: BUG-MINITS @ MIT-MC Date: 3 March 1984 17:56-EST From: Devon S. McCullough ^\ ^C should toggle a flag (that gets reset when you close a connection) that interchanges ^C and ^Z on the keyboard so I don't have to do this manually. Alternatively, you could hack the 20X monitor to do the same thing... Hey, we could hack ITS to do this too. ITS already has a similar hack for exchanging "[" and "]" with "(" and ")". I bet we could even do it right. (There is at least one reasonable alternative to simply swapping ^Z and ^C at the lowest level of input. That is to simply have a way to move the CALL key from ^Z to ^C. Then you would want ^_^C to be the way to type a ^C, except that that already has a meaning I think...)  Date: 2 March 1984 12:58-EST From: Christopher C. Stacy To: KLOTZ @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 1 Mar 1984 22:29-EST from Leigh L. Klotz Date: 1 March 1984 22:29-EST From: Leigh L. Klotz To: BUG-ITS WHAT IS SYS2;TS LINE? It was written 9/5/77, and just says it's a PDUMP file. I did :LINE instead of :LINK. It printed Guess What!!?? Your program has just gone off into HYPERSPACE!^G Of course, it was disowned. It's appears to be a wholine program of some sort, but I don't know what the message means or where the source is.  Date: 1 March 1984 22:52-EST From: Alan Bawden Subject: MC woes: PACK NOT BAWDENIZED To: CENT @ MIT-MC, CSTACY @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, JPG @ MIT-MC, KMP @ MIT-MC, Moon @ SCRC-TENEX cc: BUG-ITS @ MIT-MC In-reply-to: Msg of Thu 1 Mar 84 17:02 EST from David A. Moon OK, using Moon's new routine in DUMP I have repaired the damage I caused last night. I used the incremental dump of Feb. 28 to reset the reference dates of all files to their state as of that dump. Thus currently no file on MC has a reference date later than 2/28/84 (although many of them have in fact been written since then). I can't think of any way that this situation can screw up except the following: someone who hadn't touched a file in a long time until yesterday, and who continues not to touch it for some time in the future will have his file migrate just a little sooner than he might expect. I don't know of any other program, besides DUMP, that uses the reference date for anything important.  Date: 1 March 1984 22:29-EST From: Leigh L. Klotz To: BUG-ITS @ MIT-MC WHAT IS SYS2;TS LINE? It was written 9/5/77, and just says it's a PDUMP file. I did :LINE instead of :LINK. It printed Guess What!!?? Your program has just gone off into HYPERSPACE!^G Of course, it was disowned.  Date: 1 March 1984 15:06-EST From: Alan Bawden Subject: archives To: FILE-R @ MIT-MC, CSTACY @ MIT-MC cc: MEYER @ MIT-MC, LPH @ MIT-MC, BUG-ITS @ MIT-MC MEYER;AR0 TODO and LPH;AR31 MACSYM are both broken archives, they should be restored from backup tape. (This was caused by the installation of a broken archive device the other day.) I have renamed them to MEYER;XAR0 TODO and LPH;XAR31 MACSYM because I believe I have seen COMSAT trying to reference them both, which makes trouble. They seem to be unsalvageable, but I didn't delete them in case someone knows something I don't.  Date: Wed 29 Feb 84 23:28:59-EST From: RMS%MIT-OZ@MIT-MC.ARPA Subject: Archives To: bug-its@MIT-MC I at one point started a massive rewrite of arcdev to finish the problem that it cannot detect 'disk full' until after the user has closed the file, but I never finished it because it proved hairier than I had expected. -------  Date: 29 February 1984 18:56-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC I spoke with CStacy on the phone and he told me some bits I didn't have. He saved the old arc device as DEVICE;OLD ARCDEV. It was built from AI: SYSENG; ARCDEV 66, which is earlier than the oldest source (68) on MC: SYSENG; ... the implication being that MC: SYSENG; ARCDEV 68, although it has been around for 5 years, has never been compiled and/or tested. I re-installed DEVICE;OLD ARCDEV and things seem to work. CStacy had me patch MAPARC+6 to have a CAILE instead of a CAIL and redump it, but for some reason that didn't work. That may either be because I redumped it incorrectly or because the change is not as harmless as you would think. My testing may also have been confused by the fact that I had a couple of trashed archives. In any case, the state I am leaving this all in is that DEVICE;OLD ARCDEV (with no patches of any kind) has been replaced into DEVICE;JOBDEV ARC so that things are as they were yesterday and for the last several years. System people can start over again on their patches. Please stick around and test these things next time, though, so we aren't all stuck with broken archives. I have one archive which was enough screwed up by the experimental thing that was released earlier that I am having to retrieve an old copy of it from backup tape.  Date: 29 February 1984 18:29-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC Being suspicious that these archive problems were caused by the recent recompilation of ARCDEV, I recompiled the older version and installed it but the same problem occurs in that version. Someone should really look at this problem soon; I've made a real mess of some of my archives in all this testing. I'm reinstalling the new ARCDEV since it seems to not be the culprit.  Date: 29 February 1984 18:07-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC Archives are just completely broken. Try copying something into one and see if it works.  Date: 29 February 1984 10:59-EST From: Kent M Pitman To: BUG-DDT @ MIT-MC cc: BUG-ITS @ MIT-MC SYS4^F clears the screen and types NON-DIRECTORY DEVICE. Shouldn't this give a no such directory error? I assume DDT or ITS is somehow stripping the 4 and assuming I'm trying to reference the SYS device. My file defaults end up with SYS4: in them...  Date: 29 February 1984 01:10-EST From: Christopher C. Stacy To: GSB @ MIT-MC cc: BUG-ARCDEV @ MIT-MC In-reply-to: Msg of 29 Feb 1984 00:03-EST from Glenn S. Burke I installed your ARCDEV fix in the source and on MC.  Date: 29 February 1984 00:03-EST From: Glenn S. Burke To: BUG-ARCDEV @ MIT-MC The location 665 in the arc job device, whatever that is, should use CAILE instead of CAIL. I haven't looked at the source, but it's lossage was apparent and i had to patch this on ml to keep from irretrievably losing some stuff...  Date: 26 Feb 1984 18:48 PST (Sun) Message-ID: <[SRI-NIC].IAN.26-Feb-84 18:48:28> From: Ian Macky To: Leigh L. Klotz Cc: BUG-ITS@MIT-MC In-reply-to: Msg of 26 Feb 1984 18:44-PST from Leigh L. Klotz The LNKEDP call loops on HS: devices, or seems to when called from EMACS. I was (and still am) extremely ignorant about job devices... it's more surprising that it works at all. I'll look at it...  Date: 26 February 1984 21:44-EST From: Leigh L. Klotz To: BUG-ITS @ MIT-MC The LNKEDP call loops on HS: devices, or seems to when called from EMACS.  Date: 23 February 1984 15:26-EST From: Kent M Pitman Subject: DNRF To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC In-reply-to: Msg of 22 Feb 1984 22:33-EST from Alan Bawden Date: 22 February 1984 22:33-EST From: Alan Bawden To: KMP cc: BUG-ITS, CSTACY, JPG Re: DNRF In-reply-to: Msg of 22 Feb 1984 18:16-EST from Kent M Pitman Date: 22 February 1984 18:16-EST From: Kent M Pitman Shouldn't it be the case that deleting a file on the DNRF: device should err with WRONG TYPE DEVICE? ... We could only do this half-way really. We could "fix" DELETE to barf at seeing DNRF, but to make DELEWO barf would require making the channel remember that it was opened in this mode (a DNRF channel becomes a DSK channel after opening). Since GSB protests, I suggest we put this idea to sleep. I wasn't worried about DELEWO. Just DELETE (mostly accidental  or :DELETE; maybe I should have just suggested DDT watch for this). In any case, since everyone thinks it's a bad idea, I won't push it.  Date: 23 February 1984 01:17-EST From: Jeffrey P. Golden Subject: DNRF To: KMP @ MIT-MC cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC As long as there is all this mail on the subject ... I fully agree with GSB, and that we should leave things as they are.  Date: 23 February 1984 00:17-EST From: Ed Schwalenberg Subject: DNRF To: ALAN @ MIT-MC cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC I agree that things are better left as they are, lest we open Pandora's can of worms. I would point out that not only RENMWO, but DSKUPD, RESRDT and SRDATE "need to be fixed". The "right way" to achieve the functionality desired by KMP is through CAMEXEC-style translations, which have separate bits for all of the file operations: read, write, modify, append, delete, rename, and make link. Unfortunately, even CAMEXEC has no facility for prohibiting DELEWO, RENMWO, or MLNKWO (make link while open), on a properly opened channel. Obviously, ITS jobdevs could be invented which either ignore these operations or generate IOCERRORs if they are attempted.  Date: 22 February 1984 22:33-EST From: Alan Bawden Subject: DNRF To: KMP @ MIT-MC cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, JPG @ MIT-MC In-reply-to: Msg of 22 Feb 1984 18:16-EST from Kent M Pitman Date: 22 February 1984 18:16-EST From: Kent M Pitman Shouldn't it be the case that deleting a file on the DNRF: device should err with WRONG TYPE DEVICE? ... We could only do this half-way really. We could "fix" DELETE to barf at seeing DNRF, but to make DELEWO barf would require making the channel remember that it was opened in this mode (a DNRF channel becomes a DSK channel after opening). Since GSB protests, I suggest we put this idea to sleep.  Date: 22 February 1984 22:23-EST From: Alan Bawden Subject: ? To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC In-reply-to: Msg of 22 Feb 1984 17:47-EST from Christopher C. Stacy Date: 22 February 1984 17:47-EST From: Christopher C. Stacy Trying to rename DNRF: to DSK: on same directory gets me CANT RENAME TO ANOTHER DIRECTORY. If you do :CALL RENAME you will find that this can't possibly be an ITS bug. If you were using DDT, then it is DDT's problem.  Date: 22 February 1984 21:32-EST From: Glenn S. Burke Subject: delete an error on DNRF To: KMP @ MIT-MC cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC, JPG @ MIT-MC Yes, i disagree, because i sometimes use DNRF: as the default device when i do hand "gfring", in which i examine potentially deletable files.  Date: 22 February 1984 18:16-EST From: Kent M Pitman To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC, KMP @ MIT-MC Shouldn't it be the case that deleting a file on the DNRF: device should err with WRONG TYPE DEVICE? This would be handy since mostly I reference files on DNRF: exactly because I want to not bother them and if I have left my file defaults set to DNRF: it might have been by accident. I generally read others' files with DNRF: and would be happy knowing that this also provided greater protection against accidentally deleting them. I consider having to type ^O DSK: to delete such a file after viewing it with DNRF: to be a small price to pay for the change. Does someone disagree strongly with this argument? -kmp  Date: 22 February 1984 17:47-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Trying to rename DNRF: to DSK: on same directory gets me CANT RENAME TO ANOTHER DIRECTORY.  Date: 18 February 1984 03:48 EST From: David A. Moon To: BUG-ITS @ MIT-MC In SYSTEM;INET 108 I added the missing instruction whose absence caused all that ICMP spewage on MC's system console yesterday. Someone should reassemble the system some time. I guess it's not urgent since TCP/IP has been in use for over a year and as far as I know this only happened once.  Date: 18 February 1984 00:51 EST From: Pandora B. Berman Subject: new $$^F loses To: BUG-ITS @ MIT-MC it's a pain to have to type $$1^F all the time when i'm used to typing plain $$^F. also, it doesn't make filenames sticky anymore, another large pain.  Date: 14 February 1984 22:11 EST From: Alan Bawden Subject: LOGOUT TIMES To: WEISS @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 14 Feb 1984 15:35 EST from Paul G. Weiss Date: 14 February 1984 15:35 EST From: Paul G. Weiss After logging out at 15:33EST, my logout time was set to 14:16:03, as indicated by finger. Well, generally it takes a couple of minutes for this information to make it into the database of logout times. How long did you wait after logging out before checking? (Since it is not real important that this information be up-to-the-minute accurate, it is processed by a demon that only wakes up occasionally.)  Date: 14 February 1984 15:35 EST From: Paul G. Weiss To: BUG-ITS @ MIT-MC After logging out at 15:33EST, my logout time was set to 14:16:03, as indicated by finger.  Date: 13 February 1984 17:59 EST From: Ken Harrenstien Subject: conjecture about "TCP bugs" To: EAK @ MIT-MC cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC Date: 13 February 1984 13:56 EST From: Earl A. Killian In-reply-to: Msg of 13 Feb 1984 02:48 EST from Ken Harrenstien I cannot usually use MC for more than about 5 minutes without my connection wedging. This is from S1-C, a 4.1bsd 750 Unix with BBN TCP. Basically output just stops though input seems to get through for a little while. The BBN VAX TCP is known to have bugs, especially under any kind of load. However, if you are willing to reproduce this at a specific time, I can log the traffic and thereby identify the problem.  Date: 13 February 1984 15:26 EST From: Christopher C. Stacy Subject: [kmp at MIT-MC: ITS primitive devices] To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, KMP @ MIT-MC In-reply-to: Msg of 13 Feb 1984 13:36 EST from Alan Bawden Date: 13 February 1984 13:36 EST From: Alan Bawden Double Hmmm... Try :LISTF TCP: vs. :LISTF CHAOS:. Perhaps CHAOS: really \does/ belong in that table after all... I think you are right - so I added the CHAOS device to DEVTAB, accordingly. IPQ is for Internet datagrams; I believe it is part of the internals of the not-completely-implemented datagram service feature.  Date: 13 February 1984 13:56 EST From: Earl A. Killian Subject: conjecture about "TCP bugs" To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, CSTACY @ MIT-MC, DEVON @ MIT-MC In-reply-to: Msg of 13 Feb 1984 02:48 EST from Ken Harrenstien I cannot usually use MC for more than about 5 minutes without my connection wedging. This is from S1-C, a 4.1bsd 750 Unix with BBN TCP. Basically output just stops though input seems to get through for a little while.  Date: 13 February 1984 13:36 EST From: Alan Bawden Subject: [kmp at MIT-MC: ITS primitive devices] To: KMP @ MIT-MC cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of Sun 12 Feb 84 21:38 EST from Christopher C. Stacy [ KMP asked where he could find a list of all of ITS's built-in devices. I told him to look at the table of sixbit names starting at DEVTAB. ] Hmmm... Actually that table doesn't include CHAOS:, presumably because that table is used by OPEN and you can only open a CHAOS: channel using CHAOSO. But then TCP: \is/ in that table despite the fact that you have to use TCPOPN to open it. Double Hmmm... Try :LISTF TCP: vs. :LISTF CHAOS:. Perhaps CHAOS: really \does/ belong in that table after all...  Date: 13 February 1984 08:09 EST From: Ken Harrenstien To: BUG-HOST @ MIT-MC, BUG-HSTLOK @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-NETWRK @ MIT-MC I doubt anyone is actually on a list for this program, but the news is that HSTLOK has been renamed to HOST (to match its binary name) and revised to work on TNX as well as ITS. Some fixes to NETWRK were necessary. New source in SYSEN1;HOST and SYSENG;NETWRK.  Date: 13 February 1984 02:48 EST From: Ken Harrenstien Subject: conjecture about "TCP bugs" To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC, DEVON @ MIT-MC All I can say is that it is probably something specific to TACs, because I don't get that kind of screwage from host-to-host connections (either Unix or 20X). The TAC software changes every now and then, and was definitely broken at some points (see the Internet monthly report). However, to really PROVE TAC lossage, it needs to be spied on while it is actually happening. If anyone is able to easily reproduce the problem then it should be possible to easily figure out who is at fault.  Date: 12 February 1984 11:45 EST From: Christopher C. Stacy Subject: conjecture about "TCP bugs" To: BUG-ITS @ MIT-MC cc: BUG-TCP @ MIT-MC, DEVON @ MIT-MC Sometimes when using a Chaosnet connection (like a MINITS HUB) I have felt a distrubance in the force, as if thousands of words were crying out -- and then suddenly shuffled. The symptom is that there are long delays with no TTY service, making users think the system has crashed. Just now I was using a TAC for the first time in months, and when it happened it was extremely intrusive and scary. I wonder if it is ITS that is "broken" rather than anything in the TCP stuff. This might explain those "TCP bugs" people are always reporting. Maybe something about the way the TCP code works makes the problem more noticable to TAC users. Oh, well. Something to watch out for. Maybe I will put in something to let me check for it.  Date: 8 February 1984 18:18 EST From: David Vinayak Wallace To: BUG-ITS @ MIT-MC MC dropped my arpa connection three times in 20 minutes today. grump.  Date: 3 Feb 1984 09:09 PST (Fri) Message-ID: <[SRI-NIC].IAN. 3-Feb-84 09:09:11> From: Ian Macky To: David C. Plummer Cc: BUG-ITS@MIT-MC, GREN@MIT-MC Subject: Strange Happenings In-reply-to: Msg of 2 Feb 1984 21:55-PST from David C. Plummer Other direcectories were OK. I looked at .TEMP.; and GREN;, and maybe one or two others and they were all fine.  Date: 3 February 1984 03:41 EST From: Glenn S. Burke Sender: GSB5 @ MIT-MC Subject: mc wedgitude To: BUG-ITS @ MIT-MC The DL10 wedges with the par err light on. The one time i took a good look, none of the address lights were lit. Experimentation shows that this is at least not directly a function of the mf10 memories in cabinets E and F. The states of most other lights on the dl10 are recorded in the log book; i am not going to walk up the stairs again this morning to either get them, or boot the machine. In the no doubt useless hope that this has something to do with the memories, the NITS dump was patched so that addresses 1000000-2000000 are out. Note that the address switches of the mf10s seem to have been rearranged: the cabinets are all at monotonically increasing addresses from left to right now. An earlier spaz of parity errors (i don't know if it's related at all) had 2 or 3 from mf10 E, and about 6 from somewhere high up in the ampex, according to the printout on the system console.  Date: 3 February 1984 00:55 EST From: David C. Plummer Subject: Strange Happenings To: GREN @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 2 February 1984 20:18 EST From: Ian Macky A few minutes ago MC was acting rather strange. Any refernce to the .MAIL.; directory would hang you - either trying to write a file (:MAIL hung), or list the directory ^F (or :P D), or anything else. At the same time, KJB's BABYL fork couldn't be killed. His DDT would hang on the :KILL and not return. It just now stopped and all seems well, so I don't have any more information. What might have caused it? Were all the other directories accessable. I have seen this before when the directory cache becomes full and each entry is unflusable for some reason. I have seen both solutions to this: the system sooner or later unwedges, or it doesn't requiring reload. You may not have been able to kill KJB's babyl because it needed to update something in the file system (close a file, perhaps?) I'm a bit surprised .MAIL. didn't work. When I saw this behavior, most of the SYS directories worked, and sometimes .TEMP., and usuall a couple directories of people logged in.  Date: 2 February 1984 20:18 EST From: Ian Macky Subject: Strange Happenings To: BUG-ITS @ MIT-MC A few minutes ago MC was acting rather strange. Any refernce to the .MAIL.; directory would hang you - either trying to write a file (:MAIL hung), or list the directory ^F (or :P D), or anything else. At the same time, KJB's BABYL fork couldn't be killed. His DDT would hang on the :KILL and not return. It just now stopped and all seems well, so I don't have any more information. What might have caused it?  Date: 2 February 1984 01:34 EST From: David A. Moon Subject: Meter hardware on MC To: BUG-ITS @ MIT-MC cc: Moon @ SCRC-TENEX DATAI 24,n executed in user mode clobbers locations n and n+1 in the system! It's a good thing I tested this by hand before writing a program to use it. ITS executes the instruction with XCTR, as it should. I suspect this is a bug in the microcode. I guess I'll use .suset [.rrunt,, like a good little boy.  Date: 1 Feb 1984 20:43 EST (Wed) Message-ID: From: Martin David Connor To: bug-its@MIT-MC Subject: [GLR: bad mail from ML] Date: Wednesday, 1 February 1984 18:55-EST From: Jerry Roylance To: BUG-MAIL Re: bad mail from ML Got some bad format mail from ML -- no FROM:. ^_ 1, bad-header,, *** EOOH *** Received: from MIT-ML by MIT-OZ via Chaosnet; 31 Jan 84 21:39-EST TIM@MIT-ML 01/31/84 21:39:15 To: glr at MIT-OZ Where might I be able to find information on the RS-422 standard? ^_  Date: Wed, 1 Feb 84 05:14 EST From: "Christopher C. Stacy" Subject: more loose ends in ITS network support? To: Ken Harrenstien Cc: KMP@MIT-MC.ARPA, MOON%SCRC-TENEX@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA In-reply-to: The message of 31 Jan 84 16:08-EST from Ken Harrenstien CHAOSO and TCPOPN now behave a little more like OPEN. If these calls lose after arg checking (ie., channel numbers in range), for example if they want to say %EFLDV, that the error code will make it into the IOCHST word of the input channel. I removed the ISE0 crock for TCP from NETWRK's ANALYZ code, and reassembled TELNET, SUPDUP, and NAME. There should be no more random "Could not connect to foreign host with TCP messages" coming out anymore from either Chaosnet (!) or Internet programs. Installed on MC. Chris  Date: 30 January 1984 22:52 EST From: Christopher C. Stacy Subject: Chaosnet connections To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC In ITS 1362 on MIT-MC: Lately MC frequently gets into a state where all CHAOSO calls fail with DEVICE FULL. I increased the number of Chaosnet indices from 32. to 50., because there were 16/32 buffers free, and lots of pending RFCs and confused users. I hope this is the correct fix, and that GCing of something or other is not broken.  Date: 29 January 1984 09:09 EST From: Leigh L. Klotz Subject: EMACS echo area To: DEVON @ MIT-ML cc: BUG-ITS @ MIT-ML In-reply-to: Msg of 01/22/84 17:17:46 from DEVON at MIT-ML If you use the EMACS variable Echo Area Height instead of the raw flag FS Echo Lines your problems will be over.  Date: 28 January 1984 19:53 EST From: Alan Bawden Subject: _LSPM_ OUTPUT To: WGD @ MIT-MC cc: BUG-ITS @ MIT-MC, GZ @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX In-reply-to: Msg of 28 Jan 1984 19:30 EST from William G. Dubuque Date: 28 January 1984 19:30 EST From: William G. Dubuque Date: 27 January 1984 17:03 EST From: Alan Bawden Date: 27 January 1984 08:06 EST From: Bill Gosper BIL@mc and rwg@Russian tried to write out gz;grob > at about the same time.... What program was BIL using on MC? One possible theory is that he was using a program that did something incompetent. Better possibility (says Moon standing right behind me) is that RWG's file server got and error that he somehow never saw. I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file. As GZ mentioned, there was a _LSPM_ OUTPUT file laying around for awhile after my version was written. OK, so now we know that it was the file being written by the file server that never made it. Sounds like RWG was screwed by his Lisp machine not telling him about an error. Since we are now certain that this is not an ITS problem, or a problem with some non-lispmachine software, the next person to send mail on this subject should please delete BUG-ITS from the header.  Date: 28 January 1984 19:30 EST From: William G. Dubuque Sender: BIL @ MIT-MC To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, GZ @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX In-reply-to: Msg of 27 Jan 1984 17:03 EST from Alan Bawden Date: 27 January 1984 17:03 EST From: Alan Bawden To: RWG cc: BIL, BUG-ITS, GZ, bug-lispm at SCRC-TENEX Date: 27 January 1984 08:06 EST From: Bill Gosper BIL@mc and rwg@Russian tried to write out gz;grob > at about the same time.... What program was BIL using on MC? One possible theory is that he was using a program that did something incompetent. Better possibility (says Moon standing right behind me) is that RWG's file server got and error that he somehow never saw. I was running Nex (KMP's supped-up Emacs) on MC when I wrote the file. As GZ mentioned, there was a _LSPM_ OUTPUT file laying around for awhile after my version was written. I take it there are no known (a)synchronization problems that could be at the heart of this? Whatever the error someone should be responsible for making it know to the writer who loses since, of course, a lot could be lost this way.  Date: 27 January 1984 17:03 EST From: Alan Bawden To: RWG @ MIT-MC cc: BIL @ MIT-MC, BUG-ITS @ MIT-MC, GZ @ MIT-MC, bug-lispm @ SCRC-TENEX In-reply-to: Msg of 27 Jan 1984 08:06 EST from Bill Gosper Date: 27 January 1984 08:06 EST From: Bill Gosper BIL@mc and rwg@Russian tried to write out gz;grob > at about the same time.... What program was BIL using on MC? One possible theory is that he was using a program that did something incompetent. Better possibility (says Moon standing right behind me) is that RWG's file server got and error that he somehow never saw.  Date: 27 January 1984 08:06 EST From: Bill Gosper To: BUG-ITS @ MIT-MC cc: GZ @ MIT-MC, BIL @ MIT-MC, RWG @ MIT-MC, bug-lispm @ SCRC-TENEX BIL@mc and rwg@Russian tried to write out gz;grob > at about the same time. Russian paused about a minute in File Finish, but seemed to return from the m-X Copy File normally (RWG had typed ahead a c-and a few chars, but no aborts or anysuch.) Only BIL's version made it into gz;. GZ herself reported seeing an open file linger there for a few minutes and then disappear.  Date: 23 January 1984 14:30 EST From: Christopher C. Stacy To: USER-ACCOUNTS @ MIT-MC cc: BUG-ITS @ MIT-MC I had to reload the password database again; apparently there is a reproducible way to crash ITS and corrupt this file. Changes to the database made before 1/20 have been lost.{  Date: Mon, 23 Jan 84 02:28 EST From: David Vinayak Wallace Subject: I may be a loser, but... To: "David A. Moon" Cc: BUG-ITS@MIT-MC.ARPA In-reply-to: The message of 22 Jan 84 23:58-EST from David A. Moon Date: 22 January 1984 23:58 EST From: David A. Moon Date: Sunday, 22 January 1984, 07:39-EST From: David Vinayak Wallace MC died very strangely tonight. The IO bay and processor were frozen, but the memory and the ampex were happily flashing their lights as if nothing was wrong. There was a red NXM light illuminated on the processor bay (I didn't know there was such a light!). There isn't. You must have mistaken something else for the processor; perhaps the DL10... I'm a loser. It was the DL10. I wasn't able to figure out from that dump file how the system crashed. I suspect the answer is that it didn't! I also wasn't able to figure out how you stopped it or what command you used to dump it out (there weren't any symbols for some reason). I halted it with break, then used Y in ddt to make the dump. I assumed MC had died because: Neither the decscribbler nor the vt52 would respond to ^Z. You could not open a connection over arpa or chaos (I tried status, file, and supdup). Existing arpa, chaos, and dialup connections hung. Since you couldn't talk to it, I assumed it had crashed. The front-end was running fine, as I could wake it up with break. Perhaps this can help. david  Date: 22 January 1984 23:58 EST From: David A. Moon Subject: mc spills her cookies? To: GUMBY @ MIT-MC cc: BUG-ITS @ MIT-MC Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST Date: Sunday, 22 January 1984, 07:39-EST From: David Vinayak Wallace Subject: mc spills her cookies To: bug-its at MIT-MC MC died very strangely tonight. The IO bay and processor were frozen, but the memory and the ampex were happily flashing their lights as if nothing was wrong. There was a red NXM light illuminated on the processor bay (I didn't know there was such a light!). There isn't. You must have mistaken something else for the processor; perhaps the DL10, which is the wide bay over near the T-300 disk drives (between them and the tape drive). It's a pdp11-to-memory interface. Or it could have been the DF10, on the left-hand end of the row of 8 memory bays; it's a disk-to-memory interface. As I recall, both have red NXM lights. I put a crash dump in CRASH MEMPAR (since MC had been getting parity errors just before the crash), but since I cleverly neglected to record the state of the processor lights, it's probably useless. I wasn't able to figure out from that dump file how the system crashed. I suspect the answer is that it didn't! I also wasn't able to figure out how you stopped it or what command you used to dump it out (there weren't any symbols for some reason). It has been getting parity errors; I think the Ampex memory is turning to shit (or has been shit all along).  Date: 22 January 1984 23:42 EST From: David A. Moon Subject: MC crash at 5pm today, dumped to crash;pagfau 1/22/8 To: BUG-ITS @ MIT-MC, Hornig @ SCRC-TENEX Fixed in the source and patched in both the running system and the dump. When copying a Chaosnet packet into an Internet packet buffer, it was erroneously using the length of the destination rather than the length of the source as the length of the transfer; since the source was shorter it ran off the end of wired memory and took an exec page fault.  DEVON@MIT-ML 01/22/84 17:17:46 To: (BUG ITS) at MIT-ML This is a longstanding "feature" which is probably actually a bug. When I detach my tree, the info about the echo area is lost, so that if I reattach and continue an EMACS, it has forgotten about the echo area on the screen. Apparently this only happens if I was actually in EMACS when I was detached (by call waiting) so I tried the following experiment: :tctyp printing nosupdup emacs$j ^Z :tctyp software will clobber EMACS' echo area, even though the only thing typed at it while TCTYP was zero was a ^Z, but :tctyp printing nosupdup :tctyp software has no ill effect. I can always fix the echo area with the TECO command FS ECHO LINES$FS ECHO LINES$$ (restarting from DDT with $G clobbers the line saving info) but it really looks like an ITS bug to me..  Received: from MIT-JANIS by MIT-OZ via Chaosnet; 22 Jan 84 07:39-EST Date: Sunday, 22 January 1984, 07:39-EST From: David Vinayak Wallace Subject: mc spills her cookies To: bug-its at MIT-MC MC died very strangely tonight. The IO bay and processor were frozen, but the memory and the ampex were happily flashing their lights as if nothing was wrong. There was a red NXM light illuminated on the processor bay (I didn't know there was such a light!). I put a crash dump in CRASH MEMPAR (since MC had been getting parity errors just before the crash), but since I cleverly neglected to record the state of the processor lights, it's probably useless. david  Date: 19 January 1984 16:20 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC, ED @ MIT-MC Sometimes you are running some program and type ahead something you didn't really want. Perhaps when that typeahead is read it will flush valuable typeout on your screen, and perhaps also ^Z would have similar unwanted effects. Suppose you just wanted flush whatever pending typein there is. There is now a new BACKNEXT command: ^_^U is CLEAR INPUT. This flushes your TTY input buffer, very similar to if a .RESET had been done at it. It's in the source and patched in the running ITS. Minor bug: I am not entirely sure how to get the ^U to echo, will look at this with MOON later on this week or something. So, you can do things like this: :LISP * (SLEEP 6.)FOOBAR ^_^U ;typein cancelled before finished nap T ;the "foobar " was thrown away. Stay tuned for more exciting news...  Date: 15 January 1984 22:10 EST From: Leigh L. Klotz To: BUG-ITS @ MIT-MC I was using ITS at the time KMP noted the crash. I don't know if this was referring to my tty buffer or if this happened to others, but I was using EMACS at the time and all of a sudden got a logout message at the cursor position. Thereafter after each keystroke I got three more characters. I also got the following BYE message, but unfortunately the nick-name of the person ran off the edge of the screen. I kept pressing keys and getting more characters until I eventually got nothing, and then it hung up.  Date: 15 January 1984 18:38 EST From: Kent M Pitman Subject: MC crashed in tty code (TYOOU1+5; buffer ptr past eob) To: BUG-ITS @ MIT-MC In ITS in NEX 342, Emacs 162, Teco 1171, ITS 1359 on MIT-MC: ITS stopped with he following message: TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER The PC was TYOOU1+5. I dumped this to CRASH;TYOOU1 +5 and reloaded.  Date: 12 January 1984 05:24 EST From: Ken Harrenstien To: RWG @ MIT-MC cc: BUG-ITS @ MIT-MC, DCP @ MIT-MC, REM @ MIT-MC I suspect REM's problems have more to do with the TAC than with MC. I use MC every day via the net, from SRI-NIC, and response seems pretty good to me. I wonder if other TAC users have the same problems (whatever they are).  Date: 12 January 1984 01:44 EST From: David C. Plummer To: RWG @ MIT-MC cc: BUG-ITS @ MIT-MC, DCP @ MIT-MC, REM @ MIT-MC Date: 11 January 1984 22:58 EST From: Bill Gosper Although DCP's patch has cured the monster hangups in MC net service, echoing and typing are still pathologically slow these past weeks. REM is similarly mistreated via the arpanet. Gosper is a 9600 baud land line and a microwave away from MC. Just about any traffic on the land line will cause realtime delays. When only a microwave link away I notice very few hangups, and they are only for less than 1 second (I would guess they are about .7 seconds but I can't really tell).  Date: 11 January 1984 22:58 EST From: Bill Gosper To: BUG-ITS @ MIT-MC cc: DCP @ MIT-MC, REM @ MIT-MC Although DCP's patch has cured the monster hangups in MC net service, echoing and typing are still pathologically slow these past weeks. REM is similarly mistreated via the arpanet.  Date: 10 January 1984 04:45 EST From: Ken Harrenstien To: KMP @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC Date: 9 January 1984 22:59 EST From: Kent M Pitman Hmm. I just sent mail to BUG-FINGER asking :NAME KMP@OZ was replying right away with Could not connect to foreign host with TCP. but in fact, :OZ is doing this, too, so something must be confused with the network. Either a host table got written out which had OZ's arpanet address in it, or OZ was down and the NETWRK error analysis code doesn't know how to handle it properly (maybe because it doesn't know whether the connection attempt was using CHAOS or TCP). I re-did the NETWRK package to report TCP errors properly, but I don't know whether this will help or not. I doubt many programs have been recompiled with the new NETWRK yet.  Date: 9 January 1984 22:59 EST From: Kent M Pitman To: BUG-ITS @ MIT-MC cc: BUG-NAME @ MIT-MC Hmm. I just sent mail to BUG-FINGER asking :NAME KMP@OZ was replying right away with Could not connect to foreign host with TCP. but in fact, :OZ is doing this, too, so something must be confused with the network.  Date: 7 January 1984 15:00 EST From: Kent M Pitman Sender: KMP0 @ MIT-MC To: BUG-ITS @ MIT-MC MC has been getting parity errors (three in the last hour)... 14:16:12 #5 PC = 310000,,017213, JOB# 26, USR: TORBEN L ERR ADDR = 602005433716 PARITY ERRORS: 5,,433717 512500,,400 14:41:18 #6 PC = 710000,,107117, JOB# 66, USR: GIF HACTRN ERR ADDR = 602004377116 PARITY ERRORS: 4,,377117 211102,,403 14:41:33 #7 PC = 710000,,107117, JOB# 66, USR: GIF HACTRN ERR ADDR = 602004377116 PARITY ERRORS: 4,377117 211102,403 In case it matters, the machine room seems quite cool and dry (unlike last week).  Date: 6 January 1984 02:30 EST From: Christopher C. Stacy Subject: your patch is on disk now To: DCP @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 6 Jan 1984 02:14 EST from David C. Plummer You were trying to dump out a patched ITS BIN file instead of a world load. I don't know offhand know why this doesn't work, but I patched the NITS world load and dumped it out as XITS. I'll reassemble the system tomorrow probably anyway...  Date: 6 January 1984 02:14 EST From: David C. Plummer To: BUG-ITS @ MIT-MC, BUG-TWENEX @ MIT-MC cc: CHAOS-NCP-PEOPLE @ MIT-MC, RWG @ SPA-NIMBUS I have patched MC so that it only retransmits the first packet on the transmit queue instead of the entire queue. There are a few theories that say this is a reasonable thing to do. Its greatest impact is on the slow links which do packet filtering to avoid complete congestion. I would update the on disk version, but the L make patch Y method doesn't seem to work. (Actually, the resulting file was 7 or so blocks shorter.) So, if somebody could update the disk version, or make the patch each time ITS is booted, it would be appreciated. The patch is CHART2-1/ JFCL (was JUMPN A,CHART1) I have updated the source. Bug-Twenex people: the equivalent source change (if the Dec 10, 1983 code on EE:LIB:<5.MONITOR>CHAOS.MAC is anywhere near correct (OZ and SPEECH won't talk to me and I couldn't find it on XX) is to remove the JRST CHART1 at CHARTD-1 and replace it with the comment ;; fall through, since we only retransmit one packet of the list. This can also be patched to a JFCL if you want to test it. Other people: You may want to do (or at least try) similar things.  Date: 4 January 1984 00:46 EST From: Christopher C. Stacy To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 3 Jan 1984 23:35 EST from Alan Bawden Date: 3 January 1984 23:35 EST From: Alan Bawden To: BUG-ITS What happened to the source of SYS:ATSIGN DEVICE? The source does not seem to be online anywhere, and is not on MC's backup tape. I'll go looking for it on AI backup tape later on.  Date: 3 January 1984 23:35 EST From: Alan Bawden To: BUG-ITS @ MIT-MC What happened to the source of SYS:ATSIGN DEVICE?  Date: 21 December 1983 04:48 EST From: Christopher C. Stacy Subject: weirdness To: BUG-ITS @ MIT-MC, USER-ACCOUNTS @ MIT-MC cc: BUG-PWORD @ MIT-MC The PWORD accounts database was clobbered tonite somehow, apparently when the system crashed due to memory parity errors. (The DSK module was reporting them so I assume this means it was during disk DMA.) Apparently the file was clobbered when the system crashed, it has been zeroed or had some pointers shuffled or something -- I haven't looked at it yet but the file was still the correct length. I was under the impression that this sort of thing could not happen. USER-A people: Anyway, we got it back off of tape from Monday. Chris  Date: 18 December 1983 12:13 EST From: Christopher C. Stacy To: RK @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC In-reply-to: Msg of 17 Dec 1983 12:34 EST from "Richard Kovalcik, Jr." Date: 17 December 1983 12:34 EST From: "Richard Kovalcik, Jr." To: BUG-ITS, BUG-TCP cc: RK Any reason why MC is making outgoing TCP/IP connections but not accepting incoming ones? Mail is still backing up for MC on various sites becuase of this. -Rick For a while the system was in debug mode which does this.  Date: 17 December 1983 12:34 EST From: "Richard Kovalcik, Jr." To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC cc: RK @ MIT-MC Any reason why MC is making outgoing TCP/IP connections but not accepting incoming ones? Mail is still backing up for MC on various sites becuase of this. -Rick P.S. Both telnet and smtp gets resets immediately when you try to open to them from both CISL and MIT-Multics.  Date: 15 December 1983 18:23 EST From: Patrick G. Sobalvarro To: BUG-WHOIS @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 8 December 1983 01:29 EST From: Christopher C. Stacy To: PGS @ MIT-MC cc: BUG-FINGER @ MIT-MC, BUG-HOSTS @ MIT-MC In-reply-to: Msg of 7 Dec 1983 16:36 EST from Patrick G. Sobalvarro Date: 7 December 1983 16:36 EST From: Patrick G. Sobalvarro To: BUG-FINGER, BUG-HOSTS As of today, doing :f @oz on mc get me the error message "Could not connect to foreign host with TCP." Crufty, crufty lossage. ":F @OZ" works fine for me on MC. Maybe there is a bug in the ANALYZ code in the ITS NETWRK package, and when it could not connect to OZ over the Chaosnet it decided to give the most general TCP error message. This is the second time this bug has bitten me. ML is up right now. On MC, I did :whois pgs@ml. I immediately (not long enough for a chaos connection attempt to time out, but immediately) got the error message "Could not connect to foreign host with TCP." Immediately after that, it worked.  Date: 12 December 1983 07:59 EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Since all the INFO stuff is on FOURTH:, I can't read documentation that I want while the system is crippled.  Date: 10 December 1983 10:05 EST From: Patrick G. Sobalvarro Subject: wierd To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC, ITS-LOVERS @ MIT-MC In-reply-to: Msg of 10 Dec 1983 01:50 EST from Alan Bawden Date: 10 December 1983 01:50 EST From: Alan Bawden To: BUG-ITS cc: ITS-LOVERS Re: wierd Anybody have any idea where MC:SYS;FORMAT EXE came from? (Perhaps some subversives are planning on bringing 20X up on MC?) I'd bet that this was a case of someone cftping it over and saying yes to the stupid cftp defaults. Why the might have wanted to cftp it over, I don't know. Those cftp defaults have never ever been useful to me. If cftp did filename-merging, maybe they would be.  Date: 10 December 1983 01:50 EST From: Alan Bawden Subject: wierd To: BUG-ITS @ MIT-MC cc: ITS-LOVERS @ MIT-MC Anybody have any idea where MC:SYS;FORMAT EXE came from? (Perhaps some subversives are planning on bringing 20X up on MC?)  Date: 9 December 1983 11:37 EST From: Leigh L. Klotz Subject: Weirdness... To: EPS @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 9 Dec 1983 01:23 EST from Eric P. Scott You probably got a parity error.  Date: 9 December 1983 01:31 EST From: Eric P. Scott Subject: Weirdness (3) To: BUG-ITS @ MIT-MC I :SNARFed a CHTN and got (BADPI;IOCH12;IOCH0;) 2203>>.HANG 0/ 0 This just isn't my day. -=EPS=-  Date: 9 December 1983 01:28 EST From: Eric P. Scott Subject: Weirdness (2) To: BUG-ITS @ MIT-MC (BADPI;INF0;) 135252>>TDNN 2, 2/ 10000,,0 0/ 0 I :PDUMPed it to USERS1;EPS DEADDT if anyone cares. -=EPS=-  Date: 9 December 1983 01:23 EST From: Eric P. Scott Subject: Weirdness... To: BUG-ITS @ MIT-MC I got a tree detached by top-level interrupt followed by MC ITS REVIVED. No one else seems to have been affected. Weird... -=EPS=-  Date: 4 December 1983 23:07 EST From: Christopher C. Stacy Subject: hanging up phone lines To: CBF @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 4 Dec 1983 17:43 EST from Charles Frankston Date: 4 December 1983 17:43 EST From: Charles Frankston To: BUG-ITS Re: hanging up phone lines ITS needs better facilities for hanging up dialup lines. Since most other computers nowadays automatically hangup the phone line after logout (either immediately or with a short timeout), I think some users don't realize that they have to do this manually on ITS. I don't believe ML has the hardware to hangup a line. The I/O and Console 11's on MC have the appropriate hardware but don't give the pdp10 any way to control the appropriate bits. There used to be this .HANGUP UUO...maybe there should be a system call for reading and frobbing arbitrary bits on tty lines in the pdp-11. .HANGUP dialnum, ANCIENT HISTORY hang up a dialed line ;skip if successful This uuo NO LONGER EXISTS. It is documented here for historical purposes only. Its function is obsolete. Its opcode has been recycled as .REVIVE. This uuo was used to hang up on a line which had been dialed by the .DIAL uuo.  Date: 4 December 1983 17:43 EST From: Charles Frankston Subject: hanging up phone lines To: BUG-ITS @ MIT-MC ITS needs better facilities for hanging up dialup lines. Since most other computers nowadays automatically hangup the phone line after logout (either immediately or with a short timeout), I think some users don't realize that they have to do this manually on ITS. I don't believe ML has the hardware to hangup a line. The I/O and Console 11's on MC have the appropriate hardware but don't give the pdp10 any way to control the appropriate bits. At worst something like to LSPEED command could be used to hangup a line. At best the system would use the same sorts of timeouts it uses to close STY channels. If I get some time after the term I might look at the LSPEED covert channel. Informed suggestions on other approaches would be welcome.  Date: Friday, 2 December 1983, 00:44-EST From: David Vinayak Wallace Subject: safe site ap8 To: Pandora B. Berman Cc: TIM at MIT-MC, BUG-ITS at MIT-MC, user-a at MIT-MC In-reply-to: The message of 2 Dec 83 00:00-EST from Pandora B. Berman Date: 2 December 1983 00:00 EST From: Pandora B. Berman TIM@MIT-MC 11/29/83 05:35:55 Hmm, MC thinks that AP8 is an "insecure" site. Who/how does this get changed? it's built into something. i don't know how to change, but surely someone else does. I fixed this for MC and ML.  Date: 2 December 1983 00:00 EST From: Pandora B. Berman Subject: safe site To: TIM @ MIT-MC cc: BUG-ITS @ MIT-MC TIM@MIT-MC 11/29/83 05:35:55 Hmm, MC thinks that AP8 is an "insecure" site. Who/how does this get changed? (it's not THAT big a deal, but it probably doesn't know about other relatively new machines either). it's built into something. i don't know how to change, but surely someone else does.  Date: 15 November 1983 03:27 EST From: Christopher C. Stacy Subject: DIR: bug To: KMP @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 10/28/83 13:55:33 From: KMP If you do c-X c-F DIR: KMP; FIRST KMP, you'll note that Emacs thinks this is a link to KMP; DIR: FIRST KMP ... Is it possible that DIR: is not handling the LNKDP system call (or whatever it's called) correctly? It's called LNKEDP, and I just fixed DIR: to handle it properly. Installed on MC, old version in DEVICE;JOBDEV ODIR.  Date: 15 November 1983 03:08 EST From: Christopher C. Stacy Subject: DIR device rescued To: KMP @ MIT-MC cc: BUG-ITS @ MIT-MC Suffering arbitrary amounts of tedium, I just now recovered the source code to the DIR device from DM backup tape and put it in SYSENG;. I sure hope nothing else important was forgotten over there.  Date: 15 November 1983 03:01 EST From: Christopher C. Stacy Subject: hostat To: SHAWN @ MIT-ML cc: BUG-ITS @ MIT-ML In-reply-to: Msg of 11/15/83 00:34:36 from SHAWN at MIT-ML HOSTAT can not work anymore, since it wants to talk to DM's host status SURVEY server. Rewriting something similar is on my list of things to do in my spare time.  SHAWN@MIT-ML 11/15/83 00:34:36 Re: hostat To: (BUG ITS) at MIT-ML ERROR: OPEN: DSK: SYSBIN; HOSTS1 > - FILE NOT FOUND 4146>>.CALL 4434 (OPEN)  Date: 10 November 1983 15:09 EST From: Christopher C. Stacy Subject: ARPA net To: DEVON @ MIT-MC cc: BUG-ITS @ MIT-MC, DIGEX @ MIT-MC, KFL @ MIT-MC In-reply-to: Msg of 10 Nov 1983 11:10 EST from Devon S. McCullough I have a program called LOGN which I run when I log in. I will check it out and release it for you later today. It does the right thing with TAC binary mode, also also hacks TTYLOCs. There is another program called TBMOFF for my logout file (to turn TAC BINARNY MODE off).  Date: 10 November 1983 11:10 EST From: Devon S. McCullough Subject: ARPA net To: CSTACY @ MIT-MC cc: DEVON @ MIT-MC, DIGEX @ MIT-MC, KFL @ MIT-MC, BUG-ITS @ MIT-MC What's the correct way for a LOGIN init file to send IAC DO TRBIN and IAC WILL TRBIN to a TAC? ttyopt/ :if n %Q&%TPTEL> $(:$ do trbin $ imgout 377 375 0 $) works in most cases, except for the %TDQOT screw if your TCTYP is %TNSFW since then the TAC sees a %TDQOT before every character of the IAC sequence. I suppose I could save the value of TCTYP in DT somewhere, set TCTYP to zero, execute the IMGOUT program and then restore TCTYP, but it's not exactly clear to me how to do this, can it be done from DDT or must a program do it? If so, I will just write a hacked-up version of IMGOUT called TAC which accepts TAC commands and sends them. Every time I vary my procedures even slightly I get screwed by %TDQOT and TCTYP SOFT not knowing at what level to strip off the %TDQOT's... but my solution for a :TAC Binary Output Start is still wrong, since if the poor loser is using CRTSTY he will probably be screwed. Perhaps what we really need is a %TDIAC code which is simply intended for telling TELSER to try to frob the protocol in some way.  Date: 30 October 1983 21:35 EDT From: George J. Carrette To: BUG-ITS @ MIT-MC :FIND SYSENG;HOSTS HOSTS 666 written by CSR, beware.  Date: 30 October 1983 21:18 EDT From: David A. Moon Subject: That ITS out-of-low-core bug To: BUG-ITS @ MIT-MC Fixed in the source. I will come over probably some time this week and find the subtle bugs I no doubt introduced into the system; I wouldn't recommend trying to install the changes I made without me. Happy Hallowe'en.  Date: 30 October 1983 18:59 EDT From: Kent M. Pitman Subject: ITS wedgeding To: MOON @ SCRC-TENEX cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, JPG @ MIT-MC, TAFT @ MIT-MC, KLH @ SRI-NIC In-reply-to: Msg of 29 Oct 1983 15:59-EDT from MOON at SCRC-TENEX Date: Saturday, 29 October 1983 15:59-EDT From: MOON at SCRC-TENEX ... Lack of low core could not affect echoing on local terminals, and would only affect echoing on network terminals if there wasn't enough core to make network packet buffers. Of course maybe the users were confused and what they really meant was that their programs were busted. I was on just before it died. Echo time might not be the right phrase. The slowness was of the following sort... I typed :SRCCOM ... and waited a long time but gotten no output. Echo time for that time was normal. I finally typed ^G and V. The V did not echo. I typed some ^G's and maybe some other frustration chars (^D?) after a while and and found myself in a mode where I felt like what might be happening was that for every character I typed, a character would echo but it was out of phase by several characters with my input. The output from the V, by the way, indicated that the SRCCOM job had not loaded. Finally, though, no more input of any sort would echo, so I gave up and closed my connection. -kmp  Date: 30 October 1983 09:20 EDT From: Christopher C. Stacy Subject: RAT; To: JPG @ MIT-MC cc: BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, KLH @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC, moon @ SCRC-TENEX In-reply-to: Msg of 30 Oct 1983 09:16 EDT from Jeffrey P. Golden No, this is all long before a HACTRN has been created.  Date: 30 October 1983 09:16 EDT From: Jeffrey P. Golden Subject: RAT; To: CSTACY @ MIT-MC, moon @ SCRC-TENEX cc: BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, GSB @ MIT-MC, KLH @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC, JPG @ MIT-MC Date: Saturday, 29 October 1983 16:02-EDT From: MOON at SCRC-TENEX To: Christopher C. Stacy Cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC, KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC Subject: ITS wedgeding In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy Oh by the way, I forgot to mention about the job that had two disk channels open, where one was to "RAT;". The mode printed by Peek C mode for that channel was "RU", meaning that it was reading a directory ("UFD"). Probably this channel really belonged to some other job and peek was confused. Is the question: Why RAT; ? If so, isn't PWORD the answer?  Date: 30 October 1983 09:08 EDT From: Jeffrey P. Golden Subject: MC:BACKUP; To: BUG-ITS @ MIT-MC, MOON @ SCRC-TENEX cc: JPG @ MIT-MC Date: Saturday, 29 October 1983, 22:54-EDT From: David A. Moon To: Jeffrey P. Golden Cc: GSB@MIT-MC, BUG-ITS@MIT-MC The idea is to have a system there that works well enough that you can bring it up and run DUMP to load backup tapes. It doesn't have to support networks, terminals, etc. I agree with the idea. But if it is to work: [1] There should be a -READ- -THIS- file there which lists the key files that should be present on the BACKUP; direc. [2] Someone should look over that directory and delete useless or harmful files and replace them by the necessary files so that the idea Dave mentions can be carried out if it should ever be necessary.  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 29-Oct-83 22:51:38-EDT Date: Saturday, 29 October 1983, 22:54-EDT From: David A. Moon To: Jeffrey P. Golden Cc: GSB@MIT-MC, BUG-ITS@MIT-MC In-reply-to: The message of 14 Oct 83 04:46-EDT from Jeffrey P. Golden Date: 14 October 1983 04:46 EDT From: Jeffrey P. Golden GSB@MIT-MC 10/13/83 17:44:25 Re: MC directory slot BACKUP; is for backup copies of things on .; and occasionally other things. Why can't .; itself be used for this? For the couple of true backup @ files, which have the same names as files on .; , e.g. CRASH; would work fine. Or better, SYS; ? It should be preserved, and it does get updated occasionally. The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe almost everything there is garbage. If BACKUP; were trully for backup then leaving non-working stuff on that directory as is now the case may be hazardous for MC's health if ever invoked. I believe that it has proven itself useful on ML at least. I see no recent proof of this for MC:BACKUP; . The idea is to have a system there that works well enough that you can bring it up and run DUMP to load backup tapes. It doesn't have to support networks, terminals, etc.  Date: Saturday, 29 October 1983 16:02-EDT From: MOON at SCRC-TENEX To: Christopher C. Stacy Cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC, KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC Subject: ITS wedgeding In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy Oh by the way, I forgot to mention about the job that had two disk channels open, where one was to "RAT;". The mode printed by Peek C mode for that channel was "RU", meaning that it was reading a directory ("UFD"). Probably this channel really belonged to some other job and peek was confused.  Date: Saturday, 29 October 1983 15:59-EDT From: MOON at SCRC-TENEX To: Christopher C. Stacy Cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, GSB at MIT-MC, JPG at MIT-MC, KLH at SRI-NIC, KMP at MIT-MC, TAFT at MIT-MC, Moon at SCRC-TENEX Subject: ITS wedgeding In-reply-to: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy Date: Saturday, 29 October 1983, 01:52-EDT From: Christopher C. Stacy Subject: ITS wedgeding To: BUG-ITS at MIT-MC Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX, ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC TAFT@MIT-MC 10/28/83 14:31:11 Re: Crash of 10/28 14:27 MC was catatonic, but running. Though jobs could be logged in, no response to anything other than ^G could be obtained. I checked around that this was really the case and then stopped it. MC was also merrily printing lots of my little "Warning: " messages every chance it got. In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24, IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC: There is definitely something weird going on here. Of the 50 disk channels, none are free. There is no more free low core (for making file or network buffers.) There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot. They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP, respectively. They all have read 0% of their file. We can look at a representative wedged server job: user idx 101. ___101 TCP, is blocked inside a LOAD call: NLOADD+6/ SKIPG QSFBS(A) A/ 40 I don't entirely grok this disk code yet, but from the channel state (%QALBK) and mode (READ/USER DATA), and the comment where he blocks, it looks like he is waiting for the file channel to receive a buffer with the first page of the TCPSER file. Also, there may also be something weird file-wise with this particular job. Unlike the others, I think it has two (QUSR idx) channels: 17 and 40. According to PEEK, he is also opened RAT; (no file name), which I guess accounts for channel 17. But, huh? What? Why? Now, the TCP situation shows that there can be up to 180. packet buffers, of which zero are free out of a total zero allocated. I checked in XBUSER and friends. There is only one TCP frob around, and he's not doing a whole lot: TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL. Has received FIN for input, State is "Last ACK". User channel state: (input) Foreign host RESET, retransmit timeout (output). The close reason is: Closed by user, Closed by foreign host. This is (I think) reasonable, but does not account for all those other TCP servers! 1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY NETWORK CONNECTIONS? Is it that the connections went away before the jobs had a chance to get started, or what? What are all these jobs for, anyway? They have to load their programs before they can open their network connection. The incoming RFC (SYN in the TCP case) that started these jobs probably timed out and was rejected before you dumped the system, hence no trace of it was left. If they're trying to load the ATSIGN xxx program (rather than the actual server) that means they haven't even yet queried the system's RFC (SYN) queue to find out what contact name (port number) they are supposed to serve. The system is supposed to filter out duplicate RFCs and SYNs, so if that's working each of those jobs was created by a separate user attempt to connect. Of course if they block forever in the LOAD system call, once created they will never go away. 2. WHERE DID ALL THE LOW CORE GO? This seems to be the reason those server jobs can't get going. The lack of low core is indeed the reason the servers can't get going; they can't get a buffer to use to read their disk files they're trying to load. Even in PDUMP format the first page of the file has to be read into low core to find out what pages are to be loaded. One reason for lack of low core is bloatage of directories. I've been meaning to make a straightfoward but not totally simple fix to allow directories to be stored anywhere in core, but haven't got around to it. I guess you should bug me about this periodically. However, in this case that isn't the problem: there are only 9 pages of directories (DSKUDR in Peek M mode) plus 7 pages of disk buffers. I looked around at the MEMBLT and MEMPNT tables. A lot of the low core pages are just user pages of job 100, a worthless TEX job. See the large comment a few lines below SWPOPG; evidently the system keeps trying to swap out more and more pages to get some low memory, but keeps swapping out the wrong jobs. The right fix is to make it specifically swap out pages in "low" memory (as counted by LMEMFR) in this case, or else to put the core shuffler back in to move those pages to "high" memory. Maybe I'll look into this in a few days when I get time. 3. I heard that typein was echoing very slowly for users during this wedged period. I wonder if this was true, it was it true for local consoles as well as STYs? I don't really understand why this should be, in either case. When the system is running out of core, I have usually been able to do SYS$J (provided there was a channel for me to .OPEN on USR:) and look around. Lack of low core could not affect echoing on local terminals, and would only affect echoing on network terminals if there wasn't enough core to make network packet buffers. Of course maybe the users were confused and what they really meant was that their programs were busted.  Date: 29 October 1983 01:13 EDT From: Alan Bawden To: BUG-ITS @ MIT-MC Perhaps someone could write a demon that ran at system startup time that would look for files whose authors were set to non-existent directories and set them to be unknown. That way we would avoid recycled directories claiming that they authored files that were written by people now gone. I think about this now because I just noticed that MC:SYS1;TS STINK was authored by the newly created directory VASL...  Date: Saturday, 29 October 1983, 01:52-EDT From: Christopher C. Stacy Subject: ITS wedgeding To: BUG-ITS at MIT-MC Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX, ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC TAFT@MIT-MC 10/28/83 14:31:11 Re: Crash of 10/28 14:27 MC was catatonic, but running. Though jobs could be logged in, no response to anything other than ^G could be obtained. I checked around that this was really the case and then stopped it. MC was also merrily printing lots of my little "Warning: " messages every chance it got. In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24, IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC: There is definitely something weird going on here. Of the 50 disk channels, none are free. There is no more free low core (for making file or network buffers.) There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot. They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP, respectively. They all have read 0% of their file. We can look at a representative wedged server job: user idx 101. ___101 TCP, is blocked inside a LOAD call: NLOADD+6/ SKIPG QSFBS(A) A/ 40 I don't entirely grok this disk code yet, but from the channel state (%QALBK) and mode (READ/USER DATA), and the comment where he blocks, it looks like he is waiting for the file channel to receive a buffer with the first page of the TCPSER file. Also, there may also be something weird file-wise with this particular job. Unlike the others, I think it has two (QUSR idx) channels: 17 and 40. According to PEEK, he is also opened RAT; (no file name), which I guess accounts for channel 17. But, huh? What? Why? Now, the TCP situation shows that there can be up to 180. packet buffers, of which zero are free out of a total zero allocated. I checked in XBUSER and friends. There is only one TCP frob around, and he's not doing a whole lot: TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL. Has received FIN for input, State is "Last ACK". User channel state: (input) Foreign host RESET, retransmit timeout (output). The close reason is: Closed by user, Closed by foreign host. This is (I think) reasonable, but does not account for all those other TCP servers! 1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY NETWORK CONNECTIONS? Is it that the connections went away before the jobs had a chance to get started, or what? What are all these jobs for, anyway? 2. WHERE DID ALL THE LOW CORE GO? This seems to be the reason those server jobs can't get going. 3. I heard that typein was echoing very slowly for users during this wedged period. I wonder if this was true, it was it true for local consoles as well as STYs? I don't really understand why this should be, in either case. When the system is running out of core, I have usually been able to do SYS$J (provided there was a channel for me to .OPEN on USR:) and look around. Does anybody recognize these symptoms? (I have never tried to debug an ITS when it had not crashed at some definite place; I am relatively new at all this.) I have not yet looked to try to find what all the core is allocated to. I'll do that next sitting. I'd like people's thoughts on whether they think this is a bug, or what. I vaugely remember KLH saying something about this; maybe he has some idea what is going on. Chris  Date: 26 October 1983 23:54 EST From: Keith F. Lynch Subject: Uptime To: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC cc: KFL @ MIT-MC MC is claiming to have been up for 334 days. ...Keith  Date: 25 October 1983 12:14 EDT From: Christopher C. Stacy Subject: ZUSER crash of 10/25/83 To: BUG-ITS @ MIT-MC cc: KMP @ MIT-MC In crashed ITS 1353, CRASH;ITS LZUSUE, on MIT-MC: The system crashed because it was trying to finish logging out ___071, who had a current inferior job with one page still in core. It was a NAME (jname "F"), and it looks like it had just started loading - it had an open file channel which had read 0 wds in. Another weird thing is that his USYSN1 was 'SUPDUP', not the same as his reasonable USYSNM. That's about as far as I think I am going go with this: this info might be useful if a similar thing ever happens again. I wonder if it could be some kind of timing screw.  Date: 22 October 1983 17:14 EDT From: George J. Carrette To: BUG-ITS @ MIT-MC this isn't an its bug, just something I have noticed about TCP, both on XX and MC. Well, I can never seem to get more than about 7kbps transfer rate now, and usually get only about 3 or 4kbps on FTP. The net used to be much faster under NCP. The price of progress?  Date: 21 October 1983 15:18 EDT From: Kent M. Pitman To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC ITS crashed at 2:30. It was a BUGHALT, BUGPC/ 8 CAI LZUSUE R2+12 $Q-1/ PUSHJ P, BUGNIL I dumped this to CRASH;LZUSUE and reloaded the system.  Date: 17 October 1983 16:42 EDT From: Christopher C. Stacy Subject: ARPANET<->MILNET To: DCP @ MIT-MC cc: BUG-ITS @ MIT-MC, JSOL @ MIT-MC In-reply-to: Msg of 16 Oct 1983 15:39 EDT from David C. Plummer Date: 16 October 1983 15:39 EDT From: David C. Plummer To: JSOL cc: BUG-ITS Date: 16 October 1983 15:12 EDT From: Jon Solomon I don't know where to send this, but when you telnet from a chaos host using either MC's or ML's gateway, it doesn't seem to allow you to gateway to hosts which are not on Net-10. This includes LCS hosts, MILNET hosts, and BBN-NET hosts for starters. This is either a host table lossage (BBNC appears to be registered on MILNET), which I doubt, or this is the result of the MILNET split, in which case you aren't ALLOWED to telnet from ARPANET to MILNET. Fun, eh? No, TELNET and FTP are not yet administratively prohibited services between ARPANET and MILNET.  Date: 17 October 1983 16:38 EDT From: Christopher C. Stacy Subject: TCP server doesnt work off net 10. To: JSOL @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 16 Oct 1983 15:12 EDT from Jon Solomon You didn't say what system you were using the TCP server from, or what makes you think it is not working, and I suspect it might be on the other end. I am not near a Lisp machine to really test this right now, but when I halfway test it using only MC I can get a TCP connection to ISIA (a MILNET host.) I notice the TOPS-20 TELNET program on OZ does not let you connect to non-ARPANET hosts because its host table claims not to know about them. I'll make more test later.  Date: 16 Oct 1983 21:40 EDT (Sun) Message-ID: <[MIT-OZ].MARTY.16-Oct-83 21:40:41> From: Martin David Connor To: Jon Solomon Cc: BUG-SYSTEM%MIT-OZ@MIT-MC.ARPA, Staff%MIT-EECS@MIT-MC.ARPA, Bug-ITS@MIT-MC.ARPA Subject: bad host table In-reply-to: Msg of 16 Oct 1983 20:29-EDT from Jon Solomon Date: Sunday, 16 October 1983 20:29-EDT From: Jon Solomon To: BUG-SYSTEM, Staff at MIT-EECS [EECS people: I don't know who to send this to on EE] Your host tables don't have the necessary changes for the MILNET split, hence no milnet hosts can be connected to. Yes, in fact *any* non-arpa internet site will appear unreachable. So I wrote a little PCL hack. Basically, our TELNET (chaos gateway version) doesn't know how to connect to non-internet sites unless you fool it. So try: DECLARE PCL SS:ITN.PCL. ITN It would be nice if we could change TELNET to forget about HOSTS2.BIN which is what it is using, and why we are losing. This will all be less important when we are directly connected to the Arpanet.  Date: Sun, 16 Oct 1983 20:27 EDT Message-ID: <[MIT-OZ].JSOL.16-Oct-83 20:27:58> From: Jon Solomon To: David C. Plummer Cc: BUG-ITS@MIT-MC.ARPA Phase-Of-The-Moon: FQ+3D.2H.6M.14S. In-reply-to: Msg of 16 Oct 1983 20:00-EDT from David C. Plummer I see, you're right. why didn't I think to check and see what was actually being fed to MC! Now I know who to send my gripe to.  Date: 16 October 1983 20:00 EDT From: David C. Plummer To: JSOL @ MIT-OZ cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC Date: Sun, 16 Oct 1983 16:21 EDT From: Jon Solomon Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can telnet to them directly but OZ can't. Similarly you can telnet from ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage is in the gateway program. Works for me. From MC: :CHTN MCTCP BBNC 27 connects me to BBNC.  Date: Sun, 16 Oct 1983 16:21 EDT Message-ID: <[MIT-OZ].JSOL.16-Oct-83 16:21:59> From: Jon Solomon To: David C. Plummer Cc: BUG-ITS@MIT-MC.ARPA Phase-Of-The-Moon: FQ+2D.22H.0M.7S. In-reply-to: Msg of 16 Oct 1983 15:39-EDT from David C. Plummer Fun! Yes you are allowed to telnet to MILNET hosts. MC and ML can telnet to them directly but OZ can't. Similarly you can telnet from ECLC (ARPANET) to ECLA (MILNET) without a problem. I think the lossage is in the gateway program.  Date: 16 October 1983 15:39 EDT From: David C. Plummer To: JSOL @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 16 October 1983 15:12 EDT From: Jon Solomon I don't know where to send this, but when you telnet from a chaos host using either MC's or ML's gateway, it doesn't seem to allow you to gateway to hosts which are not on Net-10. This includes LCS hosts, MILNET hosts, and BBN-NET hosts for starters. This is either a host table lossage (BBNC appears to be registered on MILNET), which I doubt, or this is the result of the MILNET split, in which case you aren't ALLOWED to telnet from ARPANET to MILNET. Fun, eh?  Date: 16 October 1983 15:12 EDT From: Jon Solomon To: BUG-ITS @ MIT-MC I don't know where to send this, but when you telnet from a chaos host using either MC's or ML's gateway, it doesn't seem to allow you to gateway to hosts which are not on Net-10. This includes LCS hosts, MILNET hosts, and BBN-NET hosts for starters. --JSol  Date: 14 October 1983 04:46 EDT From: Jeffrey P. Golden To: GSB @ MIT-MC cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC GSB@MIT-MC 10/13/83 17:44:25 Re: MC directory slot To: JPG at MIT-MC CC: (BUG ITS) at MIT-MC BACKUP; is for backup copies of things on .; and occasionally other things. Why can't .; itself be used for this? For the couple of true backup @ files, which have the same names as files on .; , e.g. CRASH; would work fine. Or better, SYS; ? It should be preserved, and it does get updated occasionally. The last time a file was added to MC:BACKUP; was Feb. 1982 and I believe almost everything there is garbage. If BACKUP; were trully for backup then leaving non-working stuff on that directory as is now the case may be hazardous for MC's health if ever invoked. I believe that it has proven itself useful on ML at least. I see no recent proof of this for MC:BACKUP; .  Date: 13 October 1983 17:44 EDT From: Glenn S. Burke Subject: MC directory slot To: JPG @ MIT-MC cc: BUG-ITS @ MIT-MC BACKUP; is for backup copies of things on .; and occasionally other things. It should be preserved, and it does get updated occasionally. I believe that it has proven itself useful on ML at least.  Date: 13 October 1983 16:35 EDT From: Jeffrey P. Golden Subject: MC directory slot To: BUG-ITS @ MIT-MC Are all of you familiar with the MC:BACKUP; directory? I wonder how useful that directory is, or has its function been largely usurped by MC:.; et al?  Date: 13 October 1983 03:57 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I made the MLDEV/MLSLV use HOSTS3, and also fixed a minor bug where MLDEV was comparing 36 bit network numbers as CAIN A,NW%ARP. I bother mentioning the bug fix, because it seems to be everyone's favorite sleepytime bug for ITS network hacking.  Date: 12 October 1983 20:29 EDT From: Ken Harrenstien Subject: [ron: ML Routing] To: MARTY%MIT-OZ @ MIT-ML cc: BUG-ITS @ MIT-MC I doubt there is a real problem. ML was probably down at the time he tried, or the MILNET split cnfused things, or Ron was confused. MC and ML have the same "routing" code.  Date: 12 Oct 1983 15:23 EDT (Wed) Message-ID: <[MIT-OZ].MARTY.12-Oct-83 15:23:24> From: Martin David Connor To: Bug-ITS@MIT-MC.ARPA Subject: [ron: ML Routing] Does anyone understand why this is happening Date: Wednesday, 12 October 1983 14:58-EDT From: Ron Natalie To: bug-tcp Re: ML Routing I can talk to MIT-MC from our local nets but not MIT-ML. The nets in question are: BRLNET 128.20 BRLNET1 192.5.21 BRLNET2 192.5.22 they should be routed to your MILNET/ARPANET gateway. -Ron  Date: 12 October 1983 01:48 EDT From: Christopher C. Stacy Subject: normal host tables! To: BUG-ITS @ MIT-MC cc: INFO-HOSTS @ MIT-MC I snarfed the latest host table from the NIC, and installed it on ITS.  Date: 12 October 1983 01:37 EDT From: Christopher C. Stacy Subject: new host table To: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC cc: GSB @ MIT-MC, TK @ MIT-MC, ELLEN @ MIT-MC, DCLARK @ MIT-MC, JIS @ MIT-MC, KMP @ MIT-MC, TAFT @ MIT-MC The latest NIC:SPLIT-HOSTS.TXT file, dated 11 October 83, has MIT-MC back on the ARPAnet ("HOST : 10.3.0.44 : MIT-MC,MC :"). I think this means things have finally been set aright.  Date: 8 October 1983 05:28 EDT From: Christopher C. Stacy Subject: source write lock removed To: BUG-ITS @ MIT-MC  Date: 7 October 1983 20:34 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I JFCLd out the only-ARPANET patch I made a little while ago in the running system on MC. For one thing, no hosts know we are here on the ARPAnet, so we arent likely to get much unwanted traffic except from TAC users.  Date: 7 October 1983 19:05 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC At this moment, MC has the split host table which has itself on net 10. I just typed in a patch to make it refuse to connect to/from nets other than the ARPANET, though, to prevent lots of MILNET packets from being generated by unauthorized users. This isn't optimal; I'll frob it some more later tonite.  Date: Friday, 7 October 1983, 05:43-EDT From: Christopher C. Stacy Subject: INQUIR To: BUG-ITS at MIT-MC, BUG-INQUIR at MIT-MC Cc: GSB at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC I changed over all the INQUIR groups tonite, and installed new INQUIR and LSRPRT versions. I put up a messsage urging people to check to make sure their entry looks right. I used an editied version of ELLEN;PLASMA to find the PFC people, who have a new special group. I tried to make it preserve directory assignments, but it may have slightly confused people who are in the USERSi dirs on ML, since I forgot to make then specify the machine. I don't expect this to be a problem in most cases though. Chris  Date: 6 Oct 1983 08:13 EDT (Thu) Message-ID: <[MIT-OZ].IAN. 6-Oct-83 08:13:06> From: Ian Macky To: Bug-ITS@MIT-ML [PHOTO: Recording initiated Thu 6-Oct-83 8:11AM] TOPS-20 Command Processor 5(742)-2 [Commands] !f @nic [SRI-NIC via MIT-MC] %No response [SRI-NIC via MIT-ML] ? Internal error - DEVICE NOT ASSIGNABLE TO THIS PROCESSOR %No path to site !pop [PHOTO: Recording terminated Thu 6-Oct-83 8:12AM]  Date: Thursday, 6 October 1983, 02:54-EDT From: Christopher C. Stacy Subject: inconsistant sources available To: BUG-ITS at MC ITS is being hacked. If you arent KLH or myself, don't bother trying to assemble and run it.  Date: 5 October 1983 02:24 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-ML cc: TK @ MIT-ML ML has a version of ITS which does routing to the MILNET. The HOSTS3 bin file there is speciall hacked up. People should not install ITS host tables until further notice. MC is off the Internet, since it is connected to MILNET and it cannot deal with this. (I consulted KLH about one of us fixing this, so that MC could be on the MILNET, but he agrees it is too much dangerous trouble for what should be a very temporary situation.) MC and ML can talk to each other over the Chaosnet, of course.  Date: 4 October 1983 23:50 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC cc: GSB @ MIT-MC ML needs a new special host table, and a new ITS version. I'll take care of this tomorrow.  Date: 4 October 1983 05:40 EDT From: Pandora B. Berman Subject: Batch processing To: Ian @ MIT-OZ cc: MAGIC-DRAGON-KEEPER @ MIT-ML, ALAN @ MIT-MC, BUG-ITS @ MIT-MC, MAGIC-DRAGON-KEEPER @ MIT-MC Date: 4 Oct 1983 02:32 EDT (Tue) From: Ian Macky To: Alan Bawden Cc: BUG-ITS@MIT-MC, MAGIC-DRAGON-KEEPER@MIT-MC, Magic-Dragon-Keeper@MIT-ML Subject: Batch processing In-reply-to: Msg of 4 Oct 1983 02:22-EDT from Alan Bawden In case noone noticed, OZ has been sending Happy Birthday messages for months... oh, we noticed (could hardly miss doing so). but that's only for OZ users. there are other people in the world..  Date: 4 Oct 1983 02:32 EDT (Tue) Message-ID: <[MIT-OZ].IAN. 4-Oct-83 02:32:38> From: Ian Macky To: Alan Bawden Cc: BUG-ITS@MIT-MC, MAGIC-DRAGON-KEEPER@MIT-MC, Magic-Dragon-Keeper@MIT-ML Subject: Batch processing In-reply-to: Msg of 4 Oct 1983 02:22-EDT from Alan Bawden In case noone noticed, OZ has been sending Happy Birthday messages for months...  Date: 4 October 1983 02:22 EDT From: Alan Bawden Subject: Batch processing To: BUG-ITS @ MIT-MC, MAGIC-DRAGON-KEEPER @ MIT-MC, Magic-Dragon-Keeper @ MIT-ML In the latest version of Puff the Magic Dragon (installed on MC, not ML yet) I have generalized the feature where once an hour Puff would look for the files DRAGON;HOURLY RAYGUN and HOURLY TMPKIL and load and run them. Puff now will load ANY file on DRAGON; whose first file name is HOURLY and try to load it into a job and run it. While I was at it I made it check for files named DAILY, MNTHLY and YEARLY as well. (They are run at the end of the day, month and year, when Puff is cleaning his own house.) I nominate CStacy to write DRAGON;DAILY BTHDAY to replace poor DM's cheerful birthday greetings. There seems to have been some misimpression that Puff was ALREADY doing this.  Date: 3 October 1983 08:10 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC What finaly wound up sending out happy birthday announcements on ITS?  Date: 1 October 1983 22:07 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC Latest ITS (installed on MC) has the MILNET gateway in it so that forwarding will happen after the split. I will install this on ML later tonite or tomorrow.  Date: 30 September 1983 22:57 EDT From: Keith F. Lynch To: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC cc: KFL @ MIT-MC 9 users, fair share = 109% ? ...Keith  CENT@MIT-ML 09/27/83 01:10:11 Re: dm To: (BUG ITS) at MIT-ML i removed *DM from the ML system msg lists. someone had already done this on MC..  Date: 26 September 1983 21:33 EDT From: George J. Carrette To: BUG-ITS @ MIT-MC SRI-IU must have a bad address or something in the version of the host table we have.  Date: 25 September 1983 01:02 EDT From: Glenn S. Burke To: KLH @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 23 September 1983 02:27 EDT From: Ken Harrenstien Sender: KLH1 @ MIT-MC Patched MC (running sys & disk) at TCLK30+10/ CAILE D,556. Fix made in source but not assembled. ML not patched but eventually ought to be. Patched in the binary and the running system (it's been up 10 days!)  Date: 24 September 1983 22:13 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I merged DM:SYSENG; onto the MC SYSENx dirs.  Date: Saturday, 24 September 1983, 17:19-EDT From: Christopher C. Stacy Subject: DM To: BUG-INQUIR at MIT-MC, BUG-ITS at MIT-MC I diked DM out of INQUIR.  Date: 23 September 1983 06:00 EDT From: Christopher C. Stacy Subject: ITS software on DM To: BUG-ITS @ MIT-MC cc: BUG-RANDOM-PROGRAM @ MIT-MC, TAA @ MIT-DMS, PDL @ MIT-DMS, SWG @ MIT-DMS, Moon @ SCRC-TENEX I have snarfed the interesting things in DM:SYSENG; to a place on MC, and will be making sure we have everything from that directory. Are there any other interesting programs or systems (MIDAS or otherwise) we really should have on MC hiding out there? I bet there are, but I don't know where.  Date: 23 September 1983 02:27 EDT From: Ken Harrenstien Sender: KLH1 @ MIT-MC To: BUG-ITS @ MIT-MC Patched MC (running sys & disk) at TCLK30+10/ CAILE D,556. Fix made in source but not assembled. ML not patched but eventually ought to be.  Date: 16 September 1983 00:53 EDT From: Joseph A. Kay To: BUG-ITS @ MIT-MC At 00:10:25 ,16-sept-83, the LA-36 typed out 20 times: ( at MC):"LOGIN 542A02 0 HST205 " followed by the times (1 second apart). there was one intervening line from chaos, in their midst, after which some lines had 542A11 instead of 542A02. The same thing happened again 1 minute later with ~50 lines in a row,mostly "LOGIN 542A11 0 HST205" with times in two consecutive sequences (a 9 second gap between the sequences,1-second or less inside them). Occasionally lines had 542A12. At 00:35,there were 10 lines with times in 13-second span, saying: "LOGIN 030A16 0 HST017"... ---- --this may point out a problem, possibly elsewhere; or may help diagnose a future difficulty. I am not sure of its significance, but I hope it can be of help to you.  Date: Monday, September 12, 1983 5:40AM-EDT From: Christopher Stacy Subject: TOPS-20 usage of "TCP" protocol To: BUG-OZ CC: BUG-ITS at MIT-MC Programs which gateway through the TCP byte-stream gateways (ie., the "ARPA" CHAOSnet protocol, currently served only by ITS hosts on both nets), they should tell what sort of gatewaying is going on. Users cannot tell how they are getting from point A to point B - all they see is a virtual network where everything is magically connected by various secret means. If they were told what means was being employed to connect them with remote hosts on other networks, they would stand a chance of figuring out what was losing when the "gateway" did not work. BTW, probably the CHAOSNET "TCP" protocol user to get a byte stream should be made an available (optionally included, requires CHAOS support routines) call in the NETWRK packages (on all systems). It could take remote host address and port, and an AOBJN-style pointer to a table of gateway server addresses. When the DEC interface for IP comes out, and NETWRK will need rewriting anyway, would be a good time to do this. Chris  Date: 10 September 1983 06:35 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC ITS had the date wrong for a few minutes today while it was being debuggged, so a few files might have the wrong day (not too far off) on them. (Since only one or two people were on during this time, it should not be a real problem..this message is just FYI.)  Date: Friday, 9 September 1983, 15:43-EDT From: Christopher C. Stacy Subject: FILE bug To: BUG-ITS at MC In Release 4.4, site configuration 62, on Lisp Machine Apiary-6: >>Error: File system bug on host MIT-MC: CHANNEL NOT OPEN CHNL NOT OPEN For MC: AR2: CSTACY; .FILE. (DIR) While in the function (DEFUN-METHOD FS:FILE-PROCESS-ASYNC-MARK)  (DEFUN-METHOD FS:FILE-NEXT-READ-PKT)  (METHOD FS:FILE-INPUT-STREAM-MIXIN GET-NEXT-INPUT-PKT) (DEFUN-METHOD FS:FILE-PROCESS-ASYNC-MARK): (P.C. = 20) Arg 0 (SELF): # Arg 1 (SELF-MAPPING-TABLE): # Arg 2 (PKT): # Local 3 (STRING): "I1696 ERROR BUG R CHANNEL NOT OPEN CHNL NOT OPEN " . . . ZWEI:VIEW-WINDOW-DISPLAY: (P.C. = 44) Arg 0 (ZWEI-WINDOW): # Arg 1 (STREAM): # Arg 2 (FORCE-P): T  Date: 9 September 1983 15:14 EDT From: Kent M. Pitman To: BUG-MINITS @ MIT-MC, BUG-ITS @ MIT-MC Echo response time to ddt and mail and such is very slow on ITS today. It was like this sometime very recently, too. I'm coming in from HUB8A. Anyone got any ideas what might be so draggy? I get multi-second delays doing simple input and the fair share is 44%.  Date: 15 Aug 1983 00:43 EDT (Mon) Message-ID: <[MIT-OZ].GUMBY.15-Aug-83 00:43:28> From: David Vinayak Wallace To: SHAWN@MIT-ML Cc: Bug-its@MIT-OZ Subject: monmode bug(?) In-reply-to: Msg of 13 Aug 1983 23:02-EDT from SHAWN at MIT-ML Date: Saturday, 13 August 1983 23:02-EDT From: SHAWN at MIT-ML Is the fact that when you have 'prmmch' set, (printing machine name), and are in monmode, (for example 'ML: '), and you type "clear", when it goes to the top of your screen, it only prints the ':' not the 'ML:'. Is this a bug??? (If not, is there any reason for it other then that's how someone liked it?), Thanks. You'll notice that ^L will never reprint the prompt. It will echo whatever pending typing exists (in this case a ":"). This has nothing to do with either :MONMOD or PRMMCH.  Date: 14 August 1983 18:06 EDT From: Christopher C. Stacy Subject: new ITS version, install at leisure. To: BUG-ITS @ MIT-MC ITS 1351 changes .SHUTDN to not allow shutdowns further away than 30 days, and fixes some SYSJOB code which would have broken under certain assembly conditionals. I'll install it around eventually; nothing very interesting in here. (The .SHUTDN restriction is due to delta-t being computed wrong for the DEDBLK clock queue list entry; this would crash the system.)  GSB@MIT-ML 08/13/83 23:30:28 Re: c100 inschar lossage To: (BUG ITS) at MIT-ML Multiple insert-characters never ever ever succeed in outputting the null in the sequence which is what turns off insert-character mode, on anything but the first. This is what i presume is an insert-char operation with an argument, which comes in over a supdup. I have seen this lossage locally in what i presume are only single insert-character operations, but it cannot be reliably reproduced then. However multiple insert-char sequence coming from (say) emacs on OZ reliably produce the null for the first and none of the others.  SHAWN@MIT-ML 08/13/83 23:02:36 Re: monmode bug(?) To: (BUG its) at MIT-MC Is the fact that when you have 'prmmch' set, (printing machine name), and are in monmode, (for example 'ML: '), and you type "clear", when it goes to the top of your screen, it only prints the ':' not the 'ML:'. Is this a bug??? (If not, is there any reason for it other then that's how someone liked it?), Thanks. Yours In Hacking, -Shawn  Date: 11 August 1983 23:49 EDT From: V. Ellen Golden Subject: console decwriter keyboard stops working To: Moon @ SCRC-TENEX cc: CSTACY @ MIT-MC, ELLEN @ MIT-MC, BUG-ITS @ MIT-MC DEC appears to have fixed this problem (??!!!) when they PM'd the machine, which was down due to precisely this situation when they arrived... so I guess it is working.....  Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Thu 11-Aug-83 17:55:06-EDT Date: Thursday, 11 August 1983, 17:48-EDT From: David A. Moon Subject: console decwriter keyboard stops working To: Christopher C. Stacy Cc: ELLEN@MIT-MC, BUG-ITS@MIT-MC In-reply-to: The message of 6 Aug 83 10:38-EDT from Christopher C. Stacy Date: 6 August 1983 10:38 EDT From: Christopher C. Stacy Please get someone to look at MC's console typewriter. It frequently gets into this mode where the keyboard does not work at all, and nothing can be typed. Isn't there some DEC braindamage where this is caused by the cover not being quite closed all the way, and/or the thing thinking it is out of paper? Or is that some other model of decwriter?  Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Thu 11-Aug-83 17:51:25-EDT Date: Thursday, 11 August 1983, 17:45-EDT From: David A. Moon Subject: DM frotzed To: Christopher C. Stacy Cc: BUG-ITS@MIT-MC In-reply-to: The message of 8 Aug 83 03:31-EDT from Christopher C. Stacy Date: 8 August 1983 03:31 EDT From: Christopher C. Stacy I just noticed DM had crashed a while back (with no error messages or anything, and questionable state in the console). So I tried to reboot it. DSKDMP says the MFD is clobberred. There's a copy of the MFD on each drive and sometimes this message means that the disk controller or channel is broken or the processor is broken (what it really means is that dskdmp tried to read the mfd and either got a disk error or some checkword in it didn't have the right value).  Date: 8 August 1983 03:31 EDT From: Christopher C. Stacy Subject: DM frotzed To: BUG-ITS @ MIT-MC I just noticed DM had crashed a while back (with no error messages or anything, and questionable state in the console). So I tried to reboot it. DSKDMP says the MFD is clobberred. If there is a 9-track MAGDMP format tape for it, I will try to fix this, if anyone cares. If it cannot be fixed of course, someone will have to reload the file system. Should I look at it?  Date: Sunday, 7 August 1983, 10:17-EDT From: Christopher C. Stacy To: BUG-ITS at MIT-MC Cc: KMP at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC In-reply-to: The message of 6 Aug 83 00:23-EDT from Kent M. Pitman In crashed ITS 1348 in CRASH;LUUOEX, on MIT-MC: The routine which builds Internet datagram headers was smashed somehow. IPKHDR+3 (64012), normally a MOVEM, is zero (which of course looks like a UUO). Also, I am not sure exactly what this implies, but if you look at the "M" display in PEEK, it complains about not being able to trace some memory pointers ("Bad mem ptr data for 979 pages!"). Anyone else want to look at this dump further? If not I'll delete it in a few days.  Date: 6 August 1983 10:38 EDT From: Christopher C. Stacy To: ELLEN @ MIT-MC cc: BUG-ITS @ MIT-MC Please get someone to look at MC's console typewriter. It frequently gets into this mode where the keyboard does not work at all, and nothing can be typed. Being the console tty, this typically goes unnoticed until the system needs to be reloaded or something, sigh.  Date: 6 August 1983 00:23 EDT From: Kent M. Pitman To: BUG-ITS @ MIT-MC cc: ELLEN @ MIT-MC, JPG @ MIT-MC MC crashed with the message: MUUO in Exec Mode, PC = 304000,,64013 PI Level 7 BugHalt BUGPC/ LUUOEX Q-1/ JSR BUGAWF It had been down for an hour and a half, and there were no wizards in sight, so I dumped it to CRASH;LUUOEX and I reloaded the machine. I made an entry in the log book to this effect. --kmp  Date: 5 August 1983 00:25 EDT From: Zippy the Pinhead To: BUG-ITS @ MIT-MC From evan Fri Jul 1 23:34:10 1983 To: sys-bozos@cogs Subject: So I had this dream... The earth was going to be destroyed: there were these aliens who were going to eradicate all life on earth real soon so they could use it for themselves. There were two different castes of these aliens: A variety which resembled Dean Bob Randolph, and type which looked like Don Saklad. I addition to being about to kill everyone, these aliens had the additional bad feature of being obnoxious. The Dean Bob aliens were wandering around telling everyone that it was really best for us to be extermiated and that, in time, we would come to understand that the earth wasn't right for us. The Saklad aliens were bothering everyone with stupid questions about how to use the earth and the things on it. I was rather upset by the impending demise of EVERYBODY, but I discovered that we had been visited year earlier by friendly aliens, who had left us with a planetary defense system which would protect us from the nasty aliens. Unfortunately, these aliens had been here several years ago, and they had wired the defense system into the guts of the AI-10! In order to activate the defense system, you had to boot AI and log in as RMS, then type ":defend". The rest of the dream consisted of wandering around Tech Square trying to get someone to give me a Lisp-Machine memory card so that I could save all life on earth. No one would give me one. They all had important things to do with them. So I went from office to office trying to convince someone to help, and every time I rode the elevator, I was accosted by a Saklad alien asking some question like: "What is this water stuff and what do we do with it? Is it documented?" Then the phone rang and I woke up. Thank Heaven... ---Evan  Date: 5 August 1983 00:20 EDT From: Herb Lin Subject: tapes... To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 4 Aug 1983 23:42-EDT from Christopher C. Stacy tnx.  Date: Thursday, 4 August 1983, 23:42-EDT From: Christopher C. Stacy Subject: tapes... To: Herb Lin Cc: BUG-ITS at MIT-MC In-reply-to: The message of 4 Aug 83 23:05-EDT from Herb Lin You can read tapes between AI,ML, and MC. (DM has nine-track drives.) Just use LOAD command of DUMP as usual. I hear that due to drive alignment, the most successful place to read AI tapes is on ML. Also, there is a command in DUMP to read the backup directories from AI if they are re-loaded to disk someplace.  Date: 4 August 1983 23:05 EDT From: Herb Lin Subject: tapes... To: BUG-ITS @ MIT-MC this is addressed to system wizards - does anyone know if tapes written on the old AI machine can be read onto MC? If so, how can I do it... tnx.  Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 31-Jul-83 20:52:18-EDT Date: Sunday, 31 July 1983, 20:50-EDT From: David A. Moon Subject: MC crashes To: Christopher C. Stacy Cc: TAFT@MIT-MC, ELLEN@MIT-MC, BUG-ITS@MIT-MC In-reply-to: The message of 30 Jul 83 19:36-EDT from Christopher C. Stacy Somewhere on those scribbled-all-over pieces of paper attached to the machine it says how to get some information when it seems to be hung. There's a KLDCP command with some name I don't remember ("ALL" maybe) that prints a bunch of stuff, and a command file (J KLHUNG I think) that prints about three pages of stuff. Most of the three pages is useless, but buried in there are the micro and macro PCs and various error status bits. Somewhere unless some idiot has thrown it away there is a notebook containing the KLDCP commands, including how to get the current interrupt level and other things like that that are in the lights on KAs. I have no idea any more what the names of the commands were. Presumably all the information it is possible to get is in the KLHUNG output somewhere. There should be a microcode listing on-line in the UCODE directory in which you can look up micro PCs. They appear embedded in some syntax in the left margin, maybe "U nnnnn," or something like that. Microcode hung really means that some timeout inside of KLDCP went off, I believe, and doesn't really directly imply anything about the microcode. I think I have seen this caused by main memory parity errors sometimes. "ITS IS DOWN" means that a keep-alive counter incremented by the 60-cycle clock interrupt handler is not being incremented, at least as far as the pdp11 you are typing to (whichever of the two it is) thinks. ITS could be halted, looping at interrupt level, not taking interrupts because the interrupt hardware, I/O bus, or clock is broken, not running because the processor is broken, or working but not talking to the pdp11 because the interface is broken. The page-fault-in-system obviously should be investigated to see whether there was a reference to a wrong address, or a page fault on a good address, or code was clobbered, or the machine wasn't executing instructions correctly, or whatever. This one could easily be a software bug, so keep that in mind. Someone should delete the useless crash dump Taft made after a J NTSDDT.  Date: 30 July 1983 19:36 EDT From: Christopher C. Stacy Subject: MC crashes To: Moon @ SCRC-TENEX cc: TAFT @ MIT-MC, ELLEN @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 07/30/83 16:24:06 from TAFT Dave, I know you are real busy over there, but if you get a second could you please shed any light you have on this? It's pretty much beyond me. Date: 07/30/83 16:24:06 From: TAFT To: CSTACY cc: ELLEN Re: MC crash MC crashed twice this afternoon. The first time was with a microcode hung, but the second time the lights were just dead and there was no message whatsoever on the console. I tried to take a dump of this, but I am not sure that I got it right. I hit BREAK on the console, did a "J NTSDDT" and then did: $Y CRASH;NO MSG It seems to have tried writing out a dump, but perhaps this was the wrong way to get into DDT ? (It appeared to load a new one ?) Anyway I left the dump in CRASH;NO MSG, maybe someone wants to look at it. Otherwise it should be deleted. Jon The command "DDT" will get you into the current DDT. J NTSDDT runs a command file which resets some things and loads up a fresh DDT. I don't remember if it clobbers the KL10 state, but I think it does. Something is very wrong with MC. It has the following three problems, sometimes several times a day: o Microcode hung. Maybe this is not new, maybe it is a known expected ITS bug??? Is that why it has never been looked into? o Machine appears halted, typing on hardware ttys gets ITS IS DOWN, no messages on console. I guess this acts this way because the machine has either gone into a super tight loop (on the order of JRST .), or the microcode is off in never-never land and some instruction never returns. Maybe one thing to do is StoP the machine and look at the PC - I didn't yet. If the machine were really halted, I think the console-11 would say so. The IO-11 times out doing some protocol to ITS instead, and prints ITS IS DOWN. o ITS crashes with PAGE FAULT IN SYSTEM at the exact same address. Chris  Date: 28 July 1983 04:33 EDT From: Christopher C. Stacy Subject: CFTPing from ITS To: MARTY @ MIT-OZ cc: BUG-ITS @ MIT-MC, BUG-FILE @ MIT-OZ, kmp @ MIT-OZ In-reply-to: Msg of Jul 28 1983 3:19AM-EDT from Martin David Connor Date: Thursday, July 28, 1983 3:19AM-EDT From: Martin David Connor To: bug-its, bug-file at MIT-OZ Re: CFTPing from ITS I now find that supplying a non-existent username to LOGIN when CFTPing to MC or ML now hangs indefinitely. I discovered this when running a batch job that CFTPs and logs in as OZHOST. This used to work. Was there a change to the file server on MC? In FILE 520, ITS 1438, on MIT-MC: KMP and I saw this too, but thought we might be imagining something. Someone had broken FILE after version 518 by forgetting that on ITS, ASCII byte pointers must be explicit (440700) and cannot be set up with HRROI. It was MPVing because of this in COMST0 when called from the stuff around GETNAM. Fixed in the source and installed on the ITS systems.  Date: Thursday, July 28, 1983 3:19AM-EDT From: Martin David Connor Subject: CFTPing from ITS To: bug-its at MIT-MC, bug-file at MIT-OZ I now find that supplying a non-existent username to LOGIN when CFTPing to MC or ML now hangs indefinitely. I discovered this when running a batch job that CFTPs and logs in as OZHOST. This used to work. Was there a change to the file server on MC?  Date: 12 July 1983 01:32 EDT From: Ed Schwalenberg To: BUG-ARCDEV @ MIT-MC, BUG-ITS @ MIT-MC cc: BIL @ MIT-MC BIL's first problem comes from the archive device handler running out of room to fit the archive (archives can only hold about 170. blocks of stuff.) The archive device should report DEVICE FULL rather than seeming to win and producing 0-length files. Secondly, file creation dates are randomly munged, off by an hour or so. Thirdly, as we all know, the archive device needs to be done right for a change.  Date: 12 July 1983 00:20 EDT From: William G. Dubuque Sender: BIL @ MIT-MC To: BUG-ITS @ MIT-MC :MOVE ,AR0:RAT; produces a file of length 0 on AR0. Unfortunately i got screwed and moved a few unbackedup files there before noticing this. If you list the archive you will notice a few 0 length files there where this happened. All other files were :MOVEd there previously without such lossage. Is there a new DDT or ARCDEV or somesuch at the heart of this? Is there any way of getting around this (I want to preserve the creation date so :COPY wont do)?  Date: 3 Jul 1983 21:32 EDT (Sun) From: Ian Macky To: Alan Bawden Cc: BUG-ARGUS@MIT-MC, BUG-ITS@MIT-MC, CSTACY@MIT-MC Subject: Artificial Intuition? In-reply-to: Msg of 3 Jul 1983 15:57-EDT from Alan Bawden The source for ARGUS I found on MC was very very old, and is pretty grim stuff (having been written before I had any idea what I was doing)... I dunno where a more recent one is; I'll keep looking.  Date: 3 July 1983 15:57 EDT From: Alan Bawden Subject: Artificial Intuition? To: CSTACY @ MIT-MC cc: BUG-ARGUS @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 3 Jul 1983 09:44 EDT from Christopher C. Stacy Date: 3 July 1983 09:44 EDT From: Christopher C. Stacy This is CSTACY. I sat down at DEVON's console here just now, where DEVON had a disowned ARGUS looking for any CSTACY's. I started up an EMACS to look at something. I am sure you can imagine my surprise when I saw: [Here is CSTACY]. Startled, I ^Zd out of the EMACS I took my hands off the keyboard. Ever dutiful, ARGUS barked: [There goes CSTACY]. I suppose this bug has something to do with my having typed CSTACY$^S before running the EMACS. If it does not, congratulations! 'Tain't a bug in my opinion. Had always presumed that ARGUS did this by looking at all the XUNAME's in the system, but looking at the source it looks like it just reads TTY. Wierd!  Date: 3 July 1983 09:44 EDT From: Christopher C. Stacy Sender: DEVON @ MIT-MC Subject: Artificial Intuition? To: BUG-ARGUS @ MIT-MC cc: BUG-ITS @ MIT-MC This is CSTACY. I sat down at DEVON's console here just now, where DEVON had a disowned ARGUS looking for any CSTACY's. I started up an EMACS to look at something. I am sure you can imagine my surprise when I saw: [Here is CSTACY]. Startled, I ^Zd out of the EMACS I took my hands off the keyboard. Ever dutiful, ARGUS barked: [There goes CSTACY]. I suppose this bug has something to do with my having typed CSTACY$^S before running the EMACS. If it does not, congratulations!  SHAWN@MIT-ML 06/29/83 21:42:38 Re: wish list To: (BUG ITS) at MIT-ML I *WISH* ITS had a UNIX(tm) type GREP command. -Shawn  Date: 29 June 1983 17:19 EDT From: Alan Bawden Subject: CORBLK and .ACCESS interaction. To: BUG-ITS @ MIT-MC Here is a minimal case of some lossy interaction between CORBLKing and .ACCESSing the same file: .call [setz ? sixbit /open/ ? [.uii,,dsk] ? [sixbit /dsk/] [sixbit /names/] ? [sixbit />/] ? setz [sixbit /.mail./]] .lose %lsfil ;;These next two are not necessary for the misbehavior, but help to ;;make it more obvious later: .access dsk,[100] .iot dsk,a .access dsk,[2000] .iot dsk,b .access dsk,[0] .call [setz ? sixbit /corblk/ ? movei %cbndr ? movei %jself movei 7 ? setzi dsk] .lose %lssys .access dsk,[100] .iot dsk,b At the end of this sequence, A and B should obviously contain the same thing, but they don't. Typically B will get the contents of location 2100, rather than 100. It is not important what file you use, I just chose .MAIL.;NAMES > out of randomness.  Date: 21 June 1983 09:01 EDT From: David C. Plummer Subject: cli interrupts and emacs To: PGS @ MIT-OZ cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC Date: Tuesday, 21 June 1983, 04:23-EDT From: Patrick Sobalvarro I guess I'm a loser. I do use MODLIN. So am I, and so do I. I'd like to be a winner who uses MODLIN, though.  Date: Tuesday, 21 June 1983, 04:30-EDT From: Patrick Sobalvarro To: HAA@MIT-MC, BUG-ITS@MIT-MC In-reply-to: The message of 2 Jun 83 21:27-EDT from Herschell A. Andrews Date: 2 June 1983 21:27 EDT From: Herschell A. Andrews To: BUG-ITSTTY Does anyone know why my vt52 emuator suddenly started losing? It works fine on cmuc but loses bad on ITS. My software tty doesn't work either. Has something changed? I tried running a vt52 connected directly to MC and had no trouble; I'd say the trouble is probably in your emulator. Or have you figured the problem out already?  Date: Tuesday, 21 June 1983, 04:23-EDT From: Patrick Sobalvarro Subject: cli interrupts and emacs To: KMP@MIT-MC CC: BUG-ITS@MIT-MC, BUG-EMACS@MIT-MC In-reply-to: The message of 21 Jun 83 04:05-EDT from Kent M. Pitman Date: 21 June 1983 04:05 EDT From: Kent M. Pitman Do you use the MODLIN library? (For reasons I have never traced down, having this loaded seems to defeat Emacs' ability to recognize the tty having been potentially munged by superior typeout.) If you don't use the MODLIN library, perhaps you are a new data point. I guess I'm a loser (not a new data point, ha ha). I do use MODLIN.  Date: 21 June 1983 04:05 EDT From: Kent M. Pitman Sender: ___004 @ MIT-MC Subject: cli interrupts and emacs To: PGS @ MIT-MC cc: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC Do you use the MODLIN library? (For reasons I have never traced down, having this loaded seems to defeat Emacs' ability to recognize the tty having been potentially munged by superior typeout.) If you don't use the MODLIN library, perhaps you are a new data point.  Date: 21 June 1983 03:58 EDT From: Alan Bawden Subject: cli interrupts and emacs To: PGS @ MIT-MC cc: BUG-EMACS @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 21 Jun 1983 01:27 EDT from Patrick G. Sobalvarro Date: 21 June 1983 01:27 EDT From: Patrick G. Sobalvarro Correct me if I'm wrong, but once upon a time I seem to remember having Emacs uderstand that I'd gotten my screen bashed and redisplay it after a CLI interrupt as soon as I typed a character. This was a nice feature, something Twenex emacs couldn't do because of the way tty messages work there. Well, it doesn't work anymore. After a CLI interrupt, when I type characters, my Emacs doesn't redisplay at all. It doesn't do anything until I type something like ^L, which is an ECHOIN break character. Is ECHOIN broken? CStacy has complained of something like this in the past. DCP, I believe, claimed to have seen this too. I have never seen it. Is it reproducable? (I don't see how ECHOIN can itself be at fault, this works by having Emacs enable %PIATY interrupts, but perhaps emacs does does something bogus when it finds that this interrupt occured during an ECHOIN. I am pretty sure I have tested that case trying to reproduce this lossage, but I have never seen it fail... I just tried to find the source of TECO, but I couldn't, I wonder where it is?)  Date: 21 June 1983 01:27 EDT From: Patrick G. Sobalvarro Subject: cli interrupts and emacs To: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC Correct me if I'm wrong, but once upon a time I seem to remember having Emacs uderstand that I'd gotten my screen bashed and redisplay it after a CLI interrupt as soon as I typed a character. This was a nice feature, something Twenex emacs couldn't do because of the way tty messages work there. Well, it doesn't work anymore. After a CLI interrupt, when I type characters, my Emacs doesn't redisplay at all. It doesn't do anything until I type something like ^L, which is an ECHOIN break character. Is ECHOIN broken?  Date: 11 June 1983 04:19 EDT From: Pandora B. Berman Subject: DUMP To: CSTACY @ MIT-MC cc: PGS @ MIT-ML, BUG-ITS @ MIT-MC, Moon @ SCRC-TENEX i have in hand the relevant tapes from ai's last full dump. i expect to load the .tape files onto ml one dir at a time and then move them to dm. then i'll deal with the updates from the various incr. dump tapes after last august. chris, i will let you know when the dirs from the full dump are in place; that should be good enough for testing..  Date: 10 June 1983 17:40 EDT From: Glenn S. Burke Subject: DUMP To: Moon @ SCRC-TENEX cc: CSTACY @ MIT-MC, PGS @ MIT-MC, CENT @ MIT-MC, BUG-ITS @ MIT-MC The issue was disk space. I had been aware of the tape drive incompatibility when i suggested DM. People will just have to run the FIND and do the loading on different machines.  Date: 10 June 1983 02:59 EDT From: Christopher C. Stacy Subject: DUMP To: Moon @ SCRC-TENEX cc: PGS @ MIT-MC, CENT @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 10 Jun 1983 02:26-EDT from David A. Moon Date: Friday, 10 June 1983, 02:26-EDT From: David A. Moon To: Christopher C. Stacy cc: PGS, CENT, BUG-ITS Re: DUMP Date: 7 June 1983 14:01 EDT From: Christopher C. Stacy I have put a new command into DUMP. DFIND does a find for a deceased ITS. If someone reloads the .TAPEn; directories from AI onto DM, I will test it and you should be in business. The directories should be named %TAPEn; instead of .TAPEn;. But AI's tape drive was 7-track and DM's is 9-track. So DM can't read AI's tapes. Which machine they go on is just a variable in DUMP. The people who wanted this had picked DM, probably due to the number of free UFD slots...  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 10-Jun-83 02:33:36-EDT Date: Friday, 10 June 1983, 02:26-EDT From: David A. Moon Subject: DUMP To: Christopher C. Stacy Cc: PGS@MIT-MC, CENT@MIT-MC, BUG-ITS@MIT-MC In-reply-to: The message of 7 Jun 83 14:01-EDT from Christopher C. Stacy Date: 7 June 1983 14:01 EDT From: Christopher C. Stacy I have put a new command into DUMP. DFIND does a find for a deceased ITS. If someone reloads the .TAPEn; directories from AI onto DM, I will test it and you should be in business. The directories should be named %TAPEn; instead of .TAPEn;. But AI's tape drive was 7-track and DM's is 9-track. So DM can't read AI's tapes.  Date: 9 June 1983 15:57 EDT From: Kent M. Pitman Subject: Bug in ">" handling by Archive Device To: BUG-ARC @ MIT-MC cc: BUG-ITS @ MIT-MC If two files exist on an archive, FOO A and FOO B, then if you open FOO > for input, you'll get FOO A open, not FOO B. On DSK, FOO B will be opened. --kmp  Date: 7 June 1983 14:01 EDT From: Christopher C. Stacy Subject: DUMP To: PGS @ MIT-MC, CENT @ MIT-MC cc: BUG-ITS @ MIT-MC I have put a new command into DUMP. DFIND does a find for a deceased ITS. If someone reloads the .TAPEn; directories from AI onto DM, I will test it and you should be in business. The directories should be named %TAPEn; instead of .TAPEn;.  Date: 6 Jun 1983 18:32 EDT (Mon) From: Ian Macky To: David C. Plummer Cc: BUG-ITS@MIT-MC In-reply-to: Msg of 30 May 1983 16:30 EDT from David C. Plummer Date: 30 May 1983 16:30 EDT From: David C. Plummer To: BUG-ITS at MIT-MC Received: from MIT-MC by MIT-OZ; Mon 30 May 83 16:33:25-EDT Anybody know where the source for UNTALK is hiding? The creation date on SYS2;TS UNTALK is October 1977 (before the days when Midas insterted assembly information). It isn't on MC:SYSEN*; Ellen knew where it was, so I loaded a copy in my directory for the time being - it's GREN;UNTALK 87 (and there's UNTALK MAIL, too). It calls for an .INSRT file of UNCOLA's doing (UNCOLA;.MIDAS >) which was not on the same full-dump tape, so I dunno where it is.  Date: 6 June 1983 15:18 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I'll hack up DUMP to look on DM, tonite when I come in. I cant imagine it taking more than 20 minutes...  Date: 6 June 1983 15:13 EDT From: Patrick G. Sobalvarro Sender: PGS0 @ MIT-MC To: BUG-ITS @ MIT-MC I suggest that we install the AI:.TAPEn; directories on some ITS machine as AITAPn; and hack up a version of DUMP so that it'll be possible to find tapes when we need them. The problem is that there are no hardcopy dump logs except for the ones Penny did of the last couple of dumps. The hacking of DUMP should be trivial if we want to use only the FIND command; it can probably be done with translations. Glenn says that we can probably squeeze the directories on DM, and we might as well, because no one else is using the machine these days. I nominate Chris to do this. All in favor say aye. P.S. Ty and I once did an incremental dump of AI to ML thru the MLDEV using only translations. It took a long time, but, hey, it worked.  Date: 3 June 1983 09:07 EDT From: Christopher C. Stacy To: GSB @ MIT-ML cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC In-reply-to: Msg of 06/02/83 23:17:22 from GSB at MIT-ML Date: 06/02/83 23:17:22 From: GSB at MIT-ML Inqupd is writing out its new database to LSR1 >. When it runs out of disk space, it closes the incompletely written file. I think I have fixed my brain damage INQUPD. Now it writes out the provisional version to NLSR1 >, and disk-full interrupts prevent it from installing it (the interrupt handler had a bogus instruction in it.) It will still leave the incomplete version around as NLSR1. Later, I will put something in to get this deleted. In this case, DDT loses its ass when starting up when not-logged-in. It bugs out before it gets the system symbol table mapped in, making debugging incredibly difficult. Maybe DDT should do all its initialization before logging the user in (and needing to find his hsname.) I thought it already did this, but will look at. When CORBLK is doing block-mode map-from-disk, it apparently just tics the aobjn pointer away leaving MPV pages after end-of-file; no indication that you ran off the end. Is this an ITS bug? I made two invalid assumptions when looking at this broken system this afternoon, which caused me to believe that it was horribly trashed. (Maybe it is. It crashed randomly twice before, which lent great credence to its being trashed.) One was that DDT would not fail so grossly with the inquir database smashed. The other was that corblk would not intentionally act the way it did. ML *is* having some kind of trouble - COMSAT is repeat processing messages from May somehow. I guess the QML is broken somehow? Was it restored from tape, or is something even worse happenning? See BUG-MAIL. I have renamed INQUPD BIN to INQUPD FUCKED. I put the current database and program on ML. Let me know if there are more bugs with it (it ran fine for three weeks on MC, but of course some of the error code did not get exxcercised there.)  Date: Thursday, 2 June 1983 15:59-EDT From: MOON at SCRC-TENEX To: Patrick Sobalvarro Cc: bug-its at MIT-MC, BUG-LISPM at MIT-OZ In-reply-to: The message of 2 Jun 1983 07:57-EDT from Patrick Sobalvarro Date: Thursday, 2 June 1983, 07:57-EDT From: Patrick Sobalvarro If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at the end. I don't see these in Emacs. If I delete the nulls and write the file and read it again, they're back. With nulls, the file has 115 characters in it. I believe this is a bug in the ARC: device; it stores file lengths in words rather than in characters. Emacs deletes all sorts of characters at the ends of files in order to get around bugs like this, but the ITS file server is not as careful (or not as willing to cover up for the deficiencies of other programs).  Date: Thursday, 2 June 1983, 07:57-EDT From: Patrick Sobalvarro To: BUG-LISPM@MIT-OZ CC: bug-its@MIT-MC In MIT-Specific 19.3, System 94.23, ZMail 50.9, microcode 238, ZM GC@0, on Lisp Machine Thirty-one: If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at the end. I don't see these in Emacs. If I delete the nulls and write the file and read it again, they're back. With nulls, the file has 115 characters in it.  Date: 1 June 1983 19:53 EDT From: David C. Plummer To: PGS @ MIT-MC cc: CSTACY @ MIT-MC, BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC Date: 1 June 1983 01:02 EDT From: Patrick G. Sobalvarro In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy Wrongo, Roscoe. First, since there are never bugs in my code, you should have known you were wrong. Second, when you connect to MC via a terminal concentrator, I'll bet you use Supdup, not Telnet. If you use Supdup, then MC doesn't know you're on an Ann Arbor. In fact, when I use Telnet and do :tctyp aaa, I don't miss any characters in INQUIR. I provided 5ms of padding for %tdeof in the AAA code in TS3TTY, and that turns out to be more than enough. Your response was much better than mine could have been. I was a little mystified to learn that Stacy didn't know you WROTE the ITS code for AAAs. If it works on the Lisp Machine, then MINITS is probably responsible, because it provides no padding at all. That is true. Perhaps if I find some time this summer and get marginally bored I will correct this situation. Anyway, the cause of the manifestation (call it a bug if you wish) is CStacy's overeagerness to keep the screen as blank as possible. I think what is happening is that more than one %TDCLR is being sent before the text (if entered with :INQUIR DCP). This causes any AAA without padding to drop characters. [Also, the following are defined .CS=.7TYP 4,[ASCIZ /C/] .CSL=.7TYPL 4,[ASCIZ /C/] but are used in only 4 of the 10 places where they could be, the other six are .7TYP 4,[ASCIZ /C/] There are many other occurences of C scattered throughout.]  Date: 1 June 1983 02:04 EDT From: Christopher C. Stacy To: PGS @ MIT-MC cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 1 Jun 1983 01:02 EDT from Patrick G. Sobalvarro Date: 1 June 1983 01:02 EDT From: Patrick G. Sobalvarro To: CSTACY cc: BUG-INQUIR, BUG-ITS, BUG-MINITS It says "What next? ->", and then when I type a ^L, it says "Command-->". I just changed these to be a little better. Wrongo, Roscoe. First, since there are never bugs in my code, you should have known you were wrong. Second, when you connect to MC via a terminal concentrator, I'll bet you use Supdup... If it works on the Lisp Machine, then MINITS is probably responsible, because it provides no padding at all. Oh yeah. I guess I forgot to turn my brain on tonite!  Date: 1 June 1983 01:02 EDT From: Patrick G. Sobalvarro To: CSTACY @ MIT-MC cc: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy Date: Wednesday, 1 June 1983, 00:30-EDT From: Christopher C. Stacy To: Patrick G. Sobalvarro cc: BUG-ITS, BUG-INQUIR Date: 31 May 1983 16:21 EDT From: Patrick G. Sobalvarro I enter INQUIR via INQUIR PGS. The automagic listme that happens is broken; half of the characters in it are dropped. There is also a CR at the end of the command line that says Command--> I have had this sometimes happen to me on an AAA, buit it never ever happens on a Lisp Machine SUPDUP connection. I tried it just now. Just to make sure we are talking about the same program, the prompt is actually "What next? ->", right? It says "What next? ->", and then when I type a ^L, it says "Command-->". (incidentally, a more informative prompt [like, say, INQUIR>] would be better). This character dropping reminds me of Unix. The random cursor motion reminds me of another operating system for PDP-10s. I had entered INQUIR only to change my net address to MC. This looks to me like it must be an ITS problem, since it only happens on certain terminal types, and since that part of INQUIR hasn't been modified. I suspect that there is not enough padding after a clear screen operation for Ann Arbor terminals. If no TS3TTY/AAA wizard speaks up within a few days, I will start experimenting with the ITS tty code to see if that fixes the problem. Wrongo, Roscoe. First, since there are never bugs in my code, you should have known you were wrong. Second, when you connect to MC via a terminal concentrator, I'll bet you use Supdup, not Telnet. If you use Supdup, then MC doesn't know you're on an Ann Arbor. In fact, when I use Telnet and do :tctyp aaa, I don't miss any characters in INQUIR. I provided 5ms of padding for %tdeof in the AAA code in TS3TTY, and that turns out to be more than enough. If it works on the Lisp Machine, then MINITS is probably responsible, because it provides no padding at all.  Date: Wednesday, 1 June 1983, 00:30-EDT From: Christopher C. Stacy To: Patrick G. Sobalvarro Cc: BUG-ITS at MIT-MC, BUG-INQUIR at MIT-MC In-reply-to: The message of 31 May 83 16:21-EDT from Patrick G. Sobalvarro Date: 31 May 1983 16:21 EDT From: Patrick G. Sobalvarro I enter INQUIR via INQUIR PGS. The automagic listme that happens is broken; half of the characters in it are dropped. There is also a CR at the end of the command line that says Command--> I have had this sometimes happen to me on an AAA, buit it never ever happens on a Lisp Machine SUPDUP connection. I tried it just now. Just to make sure we are talking about the same program, the prompt is actually "What next? ->", right? (incidentally, a more informative prompt [like, say, INQUIR>] would be better). This character dropping reminds me of Unix. The random cursor motion reminds me of another operating system for PDP-10s. I had entered INQUIR only to change my net address to MC. This looks to me like it must be an ITS problem, since it only happens on certain terminal types, and since that part of INQUIR hasn't been modified. I suspect that there is not enough padding after a clear screen operation for Ann Arbor terminals. If no TS3TTY/AAA wizard speaks up within a few days, I will start experimenting with the ITS tty code to see if that fixes the problem.  Date: 30 May 1983 16:30 EDT From: David C. Plummer To: BUG-ITS @ MIT-MC Anybody know where the source for UNTALK is hiding? The creation date on SYS2;TS UNTALK is October 1977 (before the days when Midas insterted assembly information). It isn't on MC:SYSEN*;  Date: Tuesday, 24 May 1983, 03:33-EDT From: Christopher C. Stacy Subject: date-print on system console To: Jeffrey P. Golden Cc: BUG-ITS at MIT-MC In-reply-to: The message of 23 May 83 17:54-EDT from Jeffrey P. Golden OK, the SYSJOB will additionally print the date on the console about every 50 lines. This should get you at least one per page (why not?). The feature is run when the two minute clock ticks.  Date: 23 May 1983 17:54 EDT From: Jeffrey P. Golden Subject: date-print on system console To: BUG-ITS @ MIT-MC cc: JPG @ MIT-MC KLH@MIT-MC 05/23/83 17:30:31 To: JPG at MIT-MC CC: (BUG ITS) at MIT-MC JPG@MIT-MC 22 May 1983 13:22 EDT It would be nice if the system console had the date printed out more frequently than once every several pages. The sysjob routines could count the number of LF's and trigger a new date-print every so many lines (in addition to current time-based interval). This is what COMSAT does for its stats. Probably once per 3 pages is enough? If I could be assured that I could find the date somewhere in 3 consecutive pages if I only looked hard enough, that would be great! So I like this. CSTACY@MIT-MC 05/23/83 01:38:43 Re: IT IS NOW 1:39 ON MONDAY 23 MAY 1983 To: JPG at MIT-MC CC: (BUG ITS) at MIT-MC I think it prints the date when the very slow clock ticks, about once every two hours; it also prints it when assorted random things happen. How often do you want to see it, and what console log events are you interested in having full timestamps for? I like what KLH suggests better, but if I can't have that, I suppose once every half hour would be fine. Since ITS does not have 'auto-hangup' for its dialup lines, every now and then I have to find out who left a dialup line hung. Then I can give the loser a stern warning. By OS'ing the line I know the date and time the act was committed (and perhaps the loser's nickname!), but I need to look at the system console to get the login name.  Date: 23 May 1983 17:30 EDT From: Ken Harrenstien To: JPG @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 22 May 1983 13:22 EDT From: Jeffrey P. Golden It would be nice if the system console had the date printed out more frequently then once every several pages. The sysjob routines could count the number of LF's and trigger a new date-print every so many lines (in addition to current time-based interval). This is what COMSAT does for its stats. Probably once per 3 pages is enough?  Date: 23 May 1983 01:38 EDT From: Christopher C. Stacy Subject: IT IS NOW 1:39 ON MONDAY 23 MAY 1983 To: JPG @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 22 May 1983 13:22 EDT from Jeffrey P. Golden Date: 22 May 1983 13:22 EDT From: Jeffrey P. Golden To: BUG-ITS It would be nice if the system console had the date printed out more frequently then once every several pages. I think it prints the date when the very slow clock ticks, about once every two hour; it also prints it when assorted random things happen. How often do you want to see it, and what console log events are you interested in having full timestamps for?  Date: 22 May 1983 13:22 EDT From: Jeffrey P. Golden To: BUG-ITS @ MIT-MC It would be nice if the system console had the date printed out more frequently then once every several pages.  Date: 22 May 1983 06:27 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC When I come in over a TAC, I dont seem to be able to get meta bits through. Setting +%TPMTA doesn't work (it does on dialups though). Am I forgetting to do something (like a TAC command) or was I dreaming when I thought I had used meta keys over TIPs before?  Date: 19 May 1983 23:35 EDT From: Glenn S. Burke Subject: dirsiz To: BUG-ITS @ MIT-MC :call dirsiz claims the second arg sets quota, the source says (and uses) LH of second arg.  Date: 13 May 1983 16:08 EDT From: Christopher C. Stacy Subject: one more time... To: BUG-ITS @ MIT-MC, BUG-INQUIR @ MIT-MC cc: ELLEN @ MIT-MC, JPG @ MIT-MC, IAN @ MIT-OZ The new Inquire database is again experimentally installed on MC only. All bugs found last time appear to have been fixed. Send me mail if the old one needs to be re-installed or anything. Chris  Date: 11 May 1983 11:36 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC cc: BUG-INQUIRE @ MIT-MC, ian @ MIT-OZ I de-installed the new INQUIRE database and programs, because after a few real users I found some bugs. Will try again tomorrow. l  Date: 11 May 1983 00:07 EDT From: Christopher C. Stacy Subject: new Inquire database and stuff is being tested on MC To: BUG-INQUIRE @ MIT-MC cc: ALAN @ MIT-MC, BUG-ITS @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC, ian @ MIT-OZ OK, the new LSR1 database is installed on MC only. Experimental versions of INQUIR, LOOKUP, NAME, and INQUPD are running here. I have tested each of these, and they seem to work. If anyone notices anything very bad going on, send me mail. Note that the user interface on ITS does not let you send entries to Twenex, only the other way around. This is because I could not bring myself to deal with the INQUIR source code. I will fix this sometime by getting up more guts, or just rewriting it. Inquires on all the ITS will be the same. This has the good side effect that if I have badly blown it this evening, you can copy a database to MC from one of the other machines and de-install the experimental programs. Note that the databases are not in a completely compatible format. LSRTNS has been updated to the new format.  Date: 8 May 1983 23:30 EDT From: Christopher C. Stacy To: BUG-ARCHIVE @ MIT-MC I replied to SJOBRG.  Date: 8 May 1983 23:25 EDT From: Robert W. Sjoberg To: BUG-ARCHIVE @ MIT-MC Can someone please point me to documentation (if any) on the format of the ITS archive files? I need enough information to be able to extract directory information and file contents (I don't plan on adding anything or deleting, just reading) from an archive file. Thanks. --Bob  Date: Sunday, 8 May 1983, 06:59-EDT From: Christopher C. Stacy Subject: [Re: Is I.T.S. mistaken as to today's date?] To: Glenn S. Burke Cc: BUG-EXPIRE at MIT-DMS, BUG-ITS at MC, CENT at MIT-ML, SYS-OPERATING-TROUBLE at MIT-DMS In-reply-to: The message of 8 May 83 04:56-EDT from Glenn S. Burke Well, I just hacked GMSGS to do just expire hacking if it starts under the job name EXPIRE, and I hacked TARAKA DEMSTR on DM to start it up. So, now everday GMSGS will be run and the directory should stay cleaned. I have not tested this, so let me know if there are problems, but it really should work.  Date: 7 May 1983 02:55 EDT From: Christopher C. Stacy Subject: SYSHAK; To: BUG-ITS @ MIT-MC cc: JPG @ MIT-MC I merged SYSHAK back into SYSTEM;.  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 6-May-83 20:14:20-EDT Date: Friday, 6 May 1983, 20:27-EDT From: David A. Moon To: Jeffrey J Tyrone Sealy Cc: BUG-ITS@MIT-MC In-reply-to: The message of 6 May 83 11:28-EDT from Jeffrey J Tyrone Sealy Date: 6 May 1983 11:28 EDT From: Jeffrey J Tyrone Sealy The console-11 died today, and so ITS was running along fine but the cty was not doing anything and the swr was not being read. What is the optimum least obnoxious thing to do in this sort of event? Reboot the 11. Boot, RP0, P IOELEV, ITS ON. If this makes ITS crash as it sometimes does continue it.  Date: 6 May 1983 11:28 EDT From: Jeffrey J Tyrone Sealy To: BUG-ITS @ MIT-MC cc: Moon @ SCRC-TENEX The console-11 died today, and so ITS was running along fine but the cty was not doing anything and the swr was not being read. What is the optimum least obnoxious thing to do in this sort of event?  Date: Thursday, 5 May 1983 15:02-EDT From: MOON at SCRC-TENEX To: Christopher C. Stacy Cc: BUG-ITS at MIT-MC Subject: STLGET In-reply-to: The message of 5 May 1983 04:01-EDT from Christopher C. Stacy Well I guess it wouldn't hurt to make STLGET return a fifth value, although probably all the programs that call it look in the memory of the user whose index is the 4th value anyway.  Date: 5 May 1983 04:12 EDT From: Christopher C. Stacy Subject: removing AI from stuff To: BUG-ITS @ MIT-MC TALK (WHOJ,U,WHOM,etc) fixed.  Date: Thursday, 5 May 1983, 04:01-EDT From: Christopher C. Stacy Subject: STLGET To: David A. Moon Cc: BUG-ITS at MIT-MC In-reply-to: The message of 5 May 83 02:56-EDT from David A. Moon Date: Thursday, 5 May 1983, 02:56-EDT From: David A. Moon Date: 2 May 1983 08:05 EDT From: Christopher C. Stacy It would be nice if STLGET could actually return the HOSTS3 address of the host being served. It's sort of a crock to parse the name of the host, which might not always fix in six characters anyway. I am not sure if it is reasonable to try to get this info, but if I get ambitious I'll find out. You can get it from some standard place in the memory of the server job, I think. Right; it's documented in the TELSER source that a bunch of variables should not move (ttyloc, binary-mode flag, host. etc.) but I didn't think it was a good idea for the system to make even that assumption about what the telnet server is like...  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 5-May-83 03:21:42-EDT Date: Thursday, 5 May 1983, 03:20-EDT From: David A. Moon Subject: SYS: To: Christopher Stacy Cc: BUG-ITS@MIT-MC, ALAN@MIT-MC, DEVON@MIT-MC In-reply-to: The message of 27 Apr 83 08:41-EDT from Christopher Stacy Date: Wednesday, 27 April 1983, 08:41-EDT From: Christopher Stacy I have an idea for implementing Twenex-like logical names on ITS. 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." This sounds like a good idea to me.  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 5-May-83 02:57:26-EDT Date: Thursday, 5 May 1983, 02:56-EDT From: David A. Moon Subject: STLGET To: Christopher C. Stacy Cc: BUG-ITS@MIT-MC In-reply-to: The message of 2 May 83 08:05-EDT from Christopher C. Stacy Date: 2 May 1983 08:05 EDT From: Christopher C. Stacy It would be nice if STLGET could actually return the HOSTS3 address of the host being served. It's sort of a crock to parse the name of the host, which might not always fix in six characters anyway. I am not sure if it is reasonable to try to get this info, but if I get ambitious I'll find out. You can get it from some standard place in the memory of the server job, I think.  Date: 4 May 1983 23:36 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC I flushed AI from :INSTAL  CENT@MIT-ML 05/03/83 03:23:21 Re: *msg list info To: DEVON at MIT-MC CC: (BUG ITS) at MIT-MC Date: 3 May 1983 01:04 EDT From: Devon S. McCullough To: BUG-ITS @ MIT-MC Maybe it would be a good idea to be able to say :whois *ITS and get a description of what sort of messages should be addressed there, likewise for other magic mailing addressees. I wasn't able to find the info from :info even thought I am fairly sure it's in there somewhere.. no, there is already a meaning too close to *its for your suggestion to be wise: :whois @ITS would do a :whois on everyone logged in on the ITSs (it doesn't work quite right now because AI is gone; could someone dig into :name or wherever this is hacked in and remove AI references?). this aside, i don't know whether your idea could even be made to work (someone who knows more about :whois and mailing lists might be able to tell you). If you had looked in the menu for the MAIL subtree, you would have found the node Announcements (also available from the top-level menu and through a footnote from the new-user-info subtree), which gets you to this information. for that matter, it's also mentioned in the mailing lists file right where the sysmsg lists are defined..  Date: 3 May 1983 01:04 EDT From: Devon S. McCullough To: BUG-ITS @ MIT-MC Maybe it would be a good idea to be able to say :whois *ITS and get a description of what sort of messages should be addressed there, likewise for other magic mailing addressees. I wasn't able to find the info from :info even thought I am fairly sure it's in there somewhere.  Date: 2 May 1983 14:04 EDT From: Christopher C. Stacy Subject: AI To: BUG-ITS @ MIT-MC, ARPANET-BBOARDS @ MIT-ML The AI KA10 has been flushed, please update your programs. ...Each evening from December to December Before you drift asleep upon your cot Think back on all the tales that you remember Of Camelot Ask every person If he's heard the story And tell it loud and clear If he has not That once there was a fleeting wisp of glory Called Camelot Don't let it be forgot That once there was a spot For one brief shining moment That was known as Camelot.... [From the Lerner and Loewe musical "Camelot"]  Date: 2 May 1983 08:05 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC It would be nice if STLGET could actually return the HOSTS3 address of the host being served. It's sort of a crock to parse the name of the host, which might not always fix in six characters anyway. I am not sure if it is reasonable to try to get this info, but if I get ambitious I'll find out.  Date: 2 May 1983 02:07 EDT From: Christopher C. Stacy To: BUG-ITS @ MIT-MC In ITS 1342, the STLGET call returns a fourth value, as documented below. (Note that in previous ITS versions, Val 4 was present but only had the user index; this former behaviour was not documented.) STLGET: get information from Server Telnet arg 1 a val 1 XJNAME of server telnet val 2 TRMNAM of server telnet This is the sixbit name of the host connected to. val 3 SNAME of server telnet val 4 In LH: STY status bits In RH: index of telnet server job which owns the STY. This call can be used to find out where in the network a TTY really is. The STY status bits are from the STYSTS table in ITS. Some of the more interesting ones include: %SSNET==4000 ;4.3 = 1 => THIS STY CONNECTED TO SOME NET SOCKETS. %SSCHA==2000 ;4.2 = 0 FOR ARPANET, 1 FOR CHAOS NET %SSTCP==1000 ;4.1 = 1 for TCP internet (%SSCHA must be 0)  Date: 1 May 1983 01:58 EDT From: Alan Bawden Subject: SYS: To: ED @ MIT-MC cc: BUG-ITS @ MIT-MC, DEVON @ MIT-MC In-reply-to: Msg of 30 Apr 1983 21:25 EDT from Ed Schwalenberg Date: 30 April 1983 21:25 EDT From: Ed Schwalenberg Just for the sake of whatever ancient programs might depend on the behavior, I would strongly recommend that SYS: be equivalent to DSK:SYS; as the documentation states. Yeah, I was gonna mention a couple of days ago that it would be best to pick a new device name to have this behavior. SYSTEM:? CStacy's suggestion about giving JOBRET the ability to cause the OPEN to retry with different arguments is a good one I think. (I wonder if a kludge is possible even currently by giving the loser a translation and then causing him to get PCLSR'ed? That would be a wierd hack! The problem would be cleaning up all of the translations that would accumulate...) On the other hand I would really hate to have SYSTEM: (or whatever) be a jobdevice if it is going to be used all the time by DDT to find binarys.  Date: 30 April 1983 21:25 EDT From: Ed Schwalenberg Subject: SYS: To: ALAN @ MIT-MC cc: DEVON @ MIT-MC, BUG-ITS @ MIT-MC Just for the sake of whatever ancient programs might depend on the behavior, I would strongly recommend that SYS: be equivalent to DSK:SYS; as the documentation states. While on the subject of ITS devices, I'm spending idle moments compiling a document on them- for each device, listing where it is implemented, what it does, what machines have (or had) it, what option bits for it exist, etc. Contributions are solicited, particularly by those of you who delight in using obscure devices and have thus discovered unusual properties (like nil documentation!).