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 2 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. ------------------------------ Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Sep 87 11:29:30 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Sep 87 11:26:37 EDT Mail-From: RICCHIO created at 18-Sep-87 11:19:09 Date: Fri 18 Sep 87 11:19:09-EDT From: Joe Ricchio Subject: MC/MD maintenance To: SRA@XX.LCS.MIT.EDU cc: Ricchio@XX.LCS.MIT.EDU Message-ID: <12335615391.18.RICCHIO@XX.LCS.MIT.EDU> ReSent-Date: Fri 18 Sep 87 11:23:07-EDT ReSent-From: Rob Austein ReSent-To: Postmaster@MC.LCS.MIT.EDU, Liaison@MC.LCS.MIT.EDU, Bug-ITS@MC.LCS.MIT.EDU ReSent-Message-ID: <12335616112.55.SRA@XX.LCS.MIT.EDU> Rob, Lester has scheduled Tuesday 9-22-87 @ 9AM for PM to the RP06 drives. Hope this is agreeable wiht you. If not please advise. Thanks Joe -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Aug 87 06:34:11 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 7 Aug 87 04:26:56 EDT Date: Thu, 6 Aug 1987 21:52 EDT Message-ID: From: Rob Austein To: barmar@THINK.COM Cc: info-its@MC.LCS.MIT.EDU Subject: Unix catching up to ITS In-reply-to: Msg of 6 Aug 1987 14:00-EDT from barmar@Think.COM No, that's the USR: device. But they've invented the JOB: device too, something called "portals" I think. As Noel Chiappa said when talking about ITS and Multics, it's really kind of scary to think that we are just now catching up to what we were able to do twenty years ago.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Aug 87 19:01:31 EDT Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 6 Aug 87 18:06:10 EDT Return-Path: Received: from godot.think.com by Think.COM; Thu, 6 Aug 87 14:00:44 EDT Received: by godot.think.com; Thu, 6 Aug 87 14:00:39 EDT Date: Thu, 6 Aug 87 14:00:39 EDT From: barmar@Think.COM Message-Id: <8708061800.AA08725@godot.think.com> To: info-its@mc.lcs.mit.edu Subject: Unix catching up to ITS I read the following in the Usenet newsgroup comp.unix.wizards (== to the Arpanet mailing list UNIX-WIZARDS). AT&T has finally "invented" the JOB: device! Article 3409 of comp.unix.wizards: Path: think!husc6!seismo!mnetor!utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: comp.unix.wizards Subject: /proc, /n/face Message-ID: <8285@utzoo.UUCP> Date: 10 Jul 87 19:06:20 GMT References: <7879@brl-adm.ARPA> <2211@bunker.UUCP>, <6043@brl-smoke.ARPA>, <8244@utzoo.UUCP> Organization: U of Toronto Zoology Lines: 42 > V8 /proc preserves the semantics of a normal Unix directory setup *exactly*, > unless I missed something subtle when I read the code. My impression is that > /n/face does likewise. In both cases the directory hierarchy is actually a > figment of the kernel's imagination, but it is a consistent figment with the > same semantics as normal directories. Several people have asked what this is about, so I suppose I should elaborate a bit. This stuff has been presented in papers at Usenix conferences, but not everybody's familiar with those. /proc is V8's replacement for the ptrace() system call and related things. It's a slightly-odd type of file system. Once mounted, it looks like a single directory containing a bunch of files with numeric names. If you open (say) file "12345", you are looking at the address space of process number 12345. Writes into the file are writes into the address space. There are ioctls for things like stopping and starting the process, sending it signals, etc. Access to the files is naturally subject to the standard Unix file-permission system. The whole thing is actually a figment of the kernel's imagination, with the "directory" manufactured on the fly whenever someone tries to read it, and operations on the "files" turned into the corresponding operations on the processes. Apart from being cleaner than ptrace(), /proc is also faster. [description of /n/face deleted] In both cases, these odd filesystems look exactly like real ones, down to things like "." and ".." entries in the directories. You can use all the standard Unix tools to operate on them. At least one System V implementation of /proc exists inside AT&T, but it hasn't made it into any released software that I know of. I believe /n/face is strictly a V8ism at the moment. -- Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry  Date: Sun, 2 Aug 87 20:34:10 EDT From: Alan Bawden Subject: IP routing table To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU In-reply-to: Msg of Wed 15 Jul 87 01:55 EDT from Alan Bawden Message-ID: <236463.870802.ALAN@AI.AI.MIT.EDU> Date: Wed, 15 Jul 87 01:55 EDT From: Alan Bawden ... Try out: :ALAN;REDRCT (If anyone can think of a good directory for this to live on other than ALAN, let me know.)... It finally occured to me that the right directory for something like this is the one named ".". (Remember ":.;BOOT11" on the KL?) So make that: :.;REDRCT to fool with IP routing.  Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by AI.AI.MIT.EDU 23 Jul 87 09:17:08 EDT Received: from ROCKY-MOUNTAINS.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123996; Thu 23-Jul-87 08:59:35 EDT Date: Thu, 23 Jul 87 08:55 EDT From: Allan C. Wechsler Subject: Musings on history To: tk@STONY-BROOK.SCRC.Symbolics.COM, marker%random.s1.gov@mordor.s1.gov, ED@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, SIPB@mc.lcs.mit.edu In-Reply-To: <870722140244.3.TK@CUCKOO.SCRC.Symbolics.COM> Message-ID: <870723085519.1.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM> Date: Wed, 22 Jul 87 14:02 EDT From: Tom Knight Date: Tue, 21 Jul 87 16:38:22 PDT From: marker%random.s1.gov@mordor.s1.gov >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971. This doesn't win but is still pretty impresive. especially since it wasn't backed up! At least when I was a member, we backed up >nbdd> "by hand" periodically. We actually had to use those backup tapes occasionally.  Date: Thu, 23 Jul 87 00:26:56 EDT From: "Pandora B. Berman" Subject: MC crash To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <231258.870723.CENT@AI.AI.MIT.EDU> it complained about IMPOS. dumped to CRASH;IMPOS LOSS.  Received: from nrl.arpa (TCP 3200600010) by AI.AI.MIT.EDU 22 Jul 87 17:33:32 EDT Date: 22 Jul 87 16:08:00 EST From: "VA::BAL" Subject: Musings on history To: "tk" cc: marker%random.s1.gov@mordor.s1.gov,ed@ai.ai.mit.edu, bug-its@ai.ai.mit.edu,sipb@athena.mit.edu Reply-To: "VA::BAL" Reply-To: bal%va.decnet@nrl.arpa Full-Name: Brian A. LaMacchia Address: Code 4771, Naval Research Laboratory Address: 4555 Overlook Ave. SW, Washington, DC 20375-5000 Phone: (202) 767-3066 When this challenge was originally posted, Census data was mentioned. Well, although it may not be the winner, the Census Bureau puts up a good fight. Here are the high points: 1920 Census Data was originally tabulated on Hollerith cards, but those probably no longer exist. 1920 records are on microfilm (which I assume doesn't qualify). However, some of it is available on tape (see below). The 1950 Census used a Univac I (I think) to count the population. Data from this census was originally written to Univac metal tape. Some of these tapes still exist, but it's unclear whether or not the bits on them are still readable. The 1960 Census used FOSDIC (Form Optical Scanner Direct Input to Computer, or something like that) to convert all the forms to microfilm, and then to bits. These tapes still exist. So it looks like 1950 (which wasn't tabulated until 1954 or so) or 1960 is the best bet. However, you can get from the Census Bureau tapes containing data summaries for each Census since 1920. These are 1% samples of the population, which don't contain any personal data, just averages. However, some of the numbers are from 1920, so I guess that's "maintained data." --Brian LaMacchia bal%va.decnet@nrl.arpa (current) balamac@athena.mit.edu ------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 22 Jul 87 14:28:37 EDT Received: from CUCKOO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 196728; Wed 22-Jul-87 12:58:55 EDT Date: Wed, 22 Jul 87 14:02 EDT From: Tom Knight Subject: Musings on history To: marker%random.s1.gov@mordor.s1.gov, ED@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, SIPB@mc.lcs.mit.edu In-Reply-To: <8707212338.AA00695@random.s1.gov> Message-ID: <870722140244.3.TK@CUCKOO.SCRC.Symbolics.COM> Date: Tue, 21 Jul 87 16:38:22 PDT From: marker%random.s1.gov@mordor.s1.gov >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971. This doesn't win but is still pretty impresive. especially since it wasn't backed up!  Received: from random.s1.gov (TCP 20003600056) by AI.AI.MIT.EDU 21 Jul 87 19:41:51 EDT Received: by random.s1.gov id AA00695; Tue, 21 Jul 87 16:38:22 PDT id AA00695; Tue, 21 Jul 87 16:38:22 PDT Date: Tue, 21 Jul 87 16:38:22 PDT From: marker%random.s1.gov@mordor.s1.gov Message-Id: <8707212338.AA00695@random.s1.gov> To: ED@ai.ai.mit.edu Cc: INFO-EXPLORER@ai.ai.mit.edu, BUG-ITS@ai.ai.mit.edu, SIPB@mc.lcs.mit.edu In-Reply-To: Ed Schwalenberg's message of Sat, 18 Jul 87 00:20:05 EDT <228939.870718.ED@AI.AI.MIT.EDU> Subject: Musings on history >nbdd>sipb>pl>o>xind was compiled on November 11th, 1971. This doesn't win but is still pretty impresive. Charley  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 18 Jul 87 18:26:30 EDT Received: from nietzche by Think.COM via CHAOS; Sat, 18 Jul 87 18:27:31 EDT Date: Sat, 18 Jul 87 18:25 EDT From: Barry Margolin Subject: Musings on history To: Ed Schwalenberg Cc: INFO-EXPLORER@ai.ai.mit.edu, BUG-ITS@ai.ai.mit.edu, SIPB@mc.lcs.mit.edu In-Reply-To: <228939.870718.ED@AI.AI.MIT.EDU> Message-Id: <870718182532.2.BARMAR@NIETZSCHE.THINK.COM> I think Roger Roach still has some tape archives from CTSS. barmar  Date: Sat, 18 Jul 87 00:20:05 EDT From: Ed Schwalenberg Subject: Musings on history To: INFO-EXPLORER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, SIPB@MC.LCS.MIT.EDU Message-ID: <228939.870718.ED@AI.AI.MIT.EDU> I just saw an old file creation date on AI, which led to the following thought: Those bits are "still around", despite the fact that the hardware they live on wasn't invented at the time the bits were written. Which leads to a question: What is the oldest "continuously maintained" set of bits in the computer universe? Does Grace Hopper still have artillery aiming data on her Macintosh? Did the Census Department copy their punched cards from the 1920 census onto CD/ROM? By continously maintained, I mean that the data has been used regularly since its creation, or at least kept around on some form of reasonably random-access memory in the hope or expectation that it would be used. Thus, the sine lookup table diode ROM in the artillery aiming machine doesn't count if the machine doesn't still work, but AI:SYSEN2;PRUFD > does, even though it hasn't actually been assembled in 15 years or so, and the object code hasn't been run in 2. And of course, by data I'm referring to "digital" information. Rosetta stones, Dead Sea scrolls and Enrico Caruso records don't count, but the first stock ticker tape might. Any interesting candidates? Send me your votes. (The file mentioned above dates from 28 February 1971, and is the oldest file on AI whose creation date is believable.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jul 87 01:59:15 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Jul 87 01:55:51 EDT Date: Wed, 15 Jul 87 01:55:10 EDT From: Alan Bawden Subject: IP routing table To: BUG-TCP@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, JNC@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 14 Jul 87 13:40:44 EDT from Alan Bawden Message-ID: <227628.870715.ALAN@AI.AI.MIT.EDU> Date: Tue, 14 Jul 87 13:40:44 EDT From: Alan Bawden Date: Tue, 14 Jul 87 02:44:52 EDT From: J. Noel Chiappa You know, I wish there were some tools to manipulate this table...., some command that could delete routes, or modify the entyry, could be a real win. This sounds like an easy one night hack for someone. I'd do it if I was certain just what kinds of commands were desirable. Stop by my office some day, and spend 5 minutes helping me design it. I was in the mood for a little hack, so I wrote one. (Source on SYSNET;REDRCT.) Try out: :ALAN;REDRCT (If anyone can think of a good directory for this to live on other than ALAN, let me know.) With no JCL it will remind you of its usage as follows: Usage is: :REDRCT Gateways can be given as hostnames, or in decimal octet form (as in "10.0.0.77"). If the new gateway is omitted, REDRCT will simply pick a likely-looking gateway from ITS's list of main gateways. REDRCT will ask for confirmation once after it interprets its command, to be sure it properly understood what you asked it to do. Then for each routing table entry it finds that uses the old gateway, it will ask for confirmation before clobbering it with the new gateway.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 87 14:16:39 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Jul 87 13:55:46 EDT Date: Tue, 14 Jul 87 13:40:44 EDT From: Alan Bawden Subject: IP routing table To: JNC@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 14 Jul 87 02:44:52 EDT from J. Noel Chiappa Message-ID: <227392.870714.ALAN@AI.AI.MIT.EDU> Date: Tue, 14 Jul 87 02:44:52 EDT From: J. Noel Chiappa You know, I wish there were some tools to manipulate this table...., some command that could delete routes, or modify the entyry, could be a real win. This sounds like an easy one night hack for someone. I'd do it if I was certain just what kinds of commands were desirable. Stop by my office some day, and spend 5 minutes helping me design it.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 87 02:45:32 EDT Date: Tue, 14 Jul 87 02:44:52 EDT From: "J. Noel Chiappa" Subject: IP routing table To: BUG-ITS@MC.LCS.MIT.EDU cc: JNC@MC.LCS.MIT.EDU Message-ID: <258985.870714.JNC@MC.LCS.MIT.EDU> You know, I wish there were some tools to manipulate this table. For instance, the main gateway to a net went down, and I wanted to switch to the backup; however, ITS doesn't discover dead gateway, and you have to make the switch manually. There's no tool to do this; I had to grovel in IPGWTN: for the right netry (after doing the conversion to octal) and bash it by hand (it picked up the right gateway from a Redirect, so it wasn't totally by hand). Still, some command that could delete routes, or modify the entyry, could be a real win. NOel  Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 30002424555) by AI.AI.MIT.EDU 5 Jun 87 19:51:37 EDT Received: from LARRY-BIRD.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89235; Fri 5-Jun-87 19:45:54 EDT Date: Fri, 5 Jun 87 18:03 EDT From: Alan@AI.AI.MIT.EDU Subject: Foo To: Bug-Networks@ALDERAAN.SCRC.Symbolics.COM, Bug-ITS@ai.ai.mit.edu cc: Customer-Reports@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <870605194544.7.PALTER@LARRY-BIRD.SCRC.Symbolics.COM> Supersedes: <870605180324.1.ALAN@PIGPEN.AI.MIT.EDU>, <870605194540.6.PALTER@LARRY-BIRD.SCRC.Symbolics.COM> Redirected-Date: Fri, 5 Jun 87 19:45 EDT Redirected-by: Palter@ALDERAAN.SCRC.Symbolics.COM Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI [This message has been redirected: Looks like something either on the LispM or AI didn't properly cleanup from your abort. I'm quite certain it's not Zmail as it has the necessary UNWIND-PROTECTs. Bug-Zmail has been removed; Bug-Networks, Bug-ITS@ai.ai.mit.edu have been added.] In Symbolics 3650 Zmail in Genera 7.1, Hacks 3.0, IP-TCP 52.16, ILA-NFS 3.2, 7-1-Patches 1.15, MAC 11.1, Conversion Tools 12.4, Pascal 25.10, Experimental X-Window-System 17.4, Experimental Illustrate 11.0, TeX 1.0, LaTeX 1.0, SliTeX 1.0, YTeX 1.0, microcode 3650-MIC 396, FEP 206, FEP0:>g206-lisp.flod(14), FEP0:>g206-loaders.flod(14), FEP0:>g206-debug.flod(4), FEP0:>g206-info.flod(14), Machine serial number 30096, Patches for conversion tool. (from SYS:CONVERSION-TOOLS;PATCHES.LISP.29), on Lisp Machine Pigpen: I got this while trying to do the DESCRIBE that Gary requested. I had just previously inadvertently Aborted out of the error he wanted me to investigate, and the next time I did a "G" to reproduce the problem again, this happened: 1Error: Can't have more than one directory open at a time For AI: ALAN; ALAN _ZMAIL 0While in the function (FLAVOR:METHOD :COMMAND FS:HOST-UNIT)  FS:DIRECTORY-CHAOS  (FLAVOR:METHOD :DIRECTORY-STREAM FS:QFILE-ACCESS-PATH) The condition signalled was FS:QNOT-ENOUGH-RESOURCES 1(FLAVOR:METHOD :COMMAND FS:HOST-UNIT)0: (P.C. = 227) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): FS:HOST-UNIT Arg 2 (FLAVOR::.GENERIC.): :COMMAND Arg 3 (FS:MARK-P): NIL Arg 4 (FS:STREAM-OR-HANDLE): (:CREATE "I6770") Local 4 (FS:STREAM-OR-HANDLE): "I6770" Arg 5 (FS:SIMPLE-P): NIL Arg 6 (FS:WHOSTATE): "Directory" Rest arg (FS:COMMANDS): ("DIRECTORY" "" "" "" "" #/Return "AI: ALAN; ALAN _ZMAIL" #/Return) Local 8 (FS:HANDLE): "I6770" Local 9 (FS:STREAM): NIL Local 10 (FS:PKT): # Local 11 (FS:SUCCESS): NIL Local 12 (STRING): "I6770 ERROR NER F Can't have more than one directory open at a time" Local 13 (FS:TRANSACTION-ID): "T6773" Local 14 (FS:CREATE-P): T Local 15: # Local 16: (# # #) Local 17: (# # # #) Special DBG:*BOUND-HANDLERS*: (# # # #) 1FS:DIRECTORY-CHAOS0: (P.C. = 141) Arg 0 (FS:ACCESS-PATH): # Arg 1: # Arg 2 (FS:OPTIONS): NIL Special FS:*COMMAND-ERROR-ARGUMENTS*: (:OPERATION :DIRECTORY-LIST) Special FS:*COMMAND-PATHNAME*: # 1(FLAVOR:METHOD :DIRECTORY-STREAM FS:QFILE-ACCESS-PATH)0: (P.C. = 6) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-STREAM Arg 3 (CL:PATHNAME): # Arg 4 (FS:OPTIONS): NIL 1(FLAVOR:METHOD :DIRECTORY-LIST FS:DIRECTORY-STREAM-FILE-ACCESS-PATH-MIXIN)0: (P.C. = 13) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): FS:DIRECTORY-STREAM-FILE-ACCESS-PATH-MIXIN Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-LIST Arg 3 (CL:PATHNAME): # Arg 4 (FS:OPTIONS): (:SORTED) 1(FLAVOR:METHOD :DIRECTORY-LIST FS:ACTIVE-PATHNAME-MIXIN)0: (P.C. = 12) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :DIRECTORY-LIST Arg 3 (FS:OPTIONS): (:SORTED) 1FS:DIRECTORY-LIST0: (P.C. = 100) Arg 0 (FS:FILENAME): # Rest arg (FS:OPTIONS): (:SORTED) 1(FLAVOR:METHOD MAKE-INSTANCE ZWEI:INBOX-BUFFER)0: (P.C. = 110) 2(from SYS:7-1-PATCHES;PATCH;7-1-PATCHES-1-6) 0 Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): # Rest arg: (:PARENT-BUFFER # :PATHNAME #) 1(FLAVOR:COMBINED MAKE-INSTANCE ZWEI:ITS-INBOX-BUFFER)0: (P.C. = 11) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): # Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (:PARENT-BUFFER # :PATHNAME #) 1MAKE-INSTANCE0: (P.C. = 572) 2(from SYS:PATCH;SYSTEM-349-177) 0 Arg 0 (SYS:FLAVOR-NAME): ZWEI:ITS-INBOX-BUFFER Rest arg (FLAVOR::INIT-OPTIONS): (:PARENT-BUFFER # :PATHNAME #) 1(:INTERNAL (FLAVOR:METHOD ZWEI:READ-NEW-MAIL ZWEI:FILE-MAIL-BUFFER) 0 ZWEI:NEW-INBOXES)0: (P.C. = 27) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): # 1(FLAVOR:METHOD ZWEI:READ-NEW-MAIL ZWEI:FILE-MAIL-BUFFER)0: (P.C. = 76) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): # Arg 3 (ZWEI:INBOX-PATHNAMES): (#) 1ZWEI:READ-NEW-MAIL-TOP-LEVEL0: (P.C. = 67) 1ZWEI:COM-GET-NEW-MAIL-FROM-INBOX0: (P.C. = 7) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 16) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS Arg 2 (FLAVOR::.GENERIC.): # Arg 3 (SI:CONTINUATION): # Rest arg: NIL 1ZWEI:COMMAND-EXECUTE0: (P.C. = 57) Arg 0 (ZWEI:COMMAND): ZWEI:COM-GET-NEW-MAIL-FROM-INBOX Arg 1 (ZWEI:CHAR): #/g 2 --Defaulted args:-- 0 Arg 2 (ZWEI:PREFIX-CHAR): NIL Arg 3 (ZWEI:HOOK-LIST): NIL 1ZWEI:ZMAIL-COMMAND-EXECUTE0: (P.C. = 6) Arg 0: ZWEI:COM-GET-NEW-MAIL-FROM-INBOX 1(FLAVOR:METHOD :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)0: (P.C. = 7) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR Arg 3 (ZWEI:CH): #/g 1(:INTERNAL (:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0) 0)0: (P.C. = 10) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS Arg 2 (FLAVOR::.GENERIC.): # Arg 3 (SI:CONTINUATION): # Rest arg: NIL 1(FLAVOR:WHOPPER :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-COMMAND-LOOP-MIXIN)0: (P.C. = 31) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): # Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): # Arg 4 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR Arg 5 (ZWEI:CHAR): #/g 1(:INTERNAL (FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME) 0)0: (P.C. = 13) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g) 1(FLAVOR:WHOPPER :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)0: (P.C. = 21) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): # Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): # Arg 4 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR Arg 5 (ZWEI:CHAR): #/g 1(FLAVOR:COMBINED :PROCESS-COMMAND-CHAR ZWEI:ZMAIL-FRAME)0: (P.C. = 12) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :PROCESS-COMMAND-CHAR Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): (#/g) 1(FLAVOR:METHOD :COMMAND-LOOP ZWEI:ZMAIL-FRAME)0: (P.C. = 130) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP 1(:INTERNAL (FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME) 0)0: (P.C. = 17) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): NIL 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS Arg 2 (FLAVOR::.GENERIC.): # Arg 3 (SI:CONTINUATION): # Rest arg: NIL 1(FLAVOR:WHOPPER :COMMAND-LOOP ZWEI:ZMAIL-COMMAND-LOOP-MIXIN)0: (P.C. = 65) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.WHOPPER-CONTINUATION.): # Arg 3 (FLAVOR::.OLD-SELF-MAPPING-TABLE.): # Arg 4 (FLAVOR::.GENERIC.): :COMMAND-LOOP 1(FLAVOR:COMBINED :COMMAND-LOOP ZWEI:ZMAIL-FRAME)0: (P.C. = 562) Arg 0 (SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): # Arg 2 (FLAVOR::.GENERIC.): :COMMAND-LOOP Rest arg (FLAVOR::.DAEMON-CALLER-ARGS.): NIL 1ZWEI:ZMAIL-PROCESS-TOP-LEVEL0: (P.C. = 104) Arg 0 (ZWEI:WINDOW): # 1SI:PROCESS-TOP-LEVEL0: (P.C. = 45) Arg 0 (IGNORE): NIL Special FS:%FILE-COMMAND-OPCODE: 200 Special FS:*DONT-HACK-LOGIN*: NIL  Date: Tue, 5 May 87 18:20:25 EDT From: Alan Bawden Subject: Datapoint on TCP buffer lossage To: BUG-ITS@AI.AI.MIT.EDU cc: JTW@AI.AI.MIT.EDU Message-ID: <195885.870505.ALAN@AI.AI.MIT.EDU> The forget-to-free-the-SYN-packet problem than happens on AI and MC so much, really -does- also happen on the KL! After 12 days running, the KL has managed to lose just two packets in this manner. Perhaps the fact that the KL is so much faster explains why it happens so rarely there?  Date: Tue, 5 May 87 08:25:18 EDT From: John Wilson To: INFO-ITS@AI.AI.MIT.EDU Message-ID: <195618.870505.JOHNW@AI.AI.MIT.EDU> Please add me to the mailing list. thanks, John Wilson  Date: Tue, 5 May 87 05:38:08 EDT From: "Pandora B. Berman" Subject: MD up again To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <195595.870505.CENT@AI.AI.MIT.EDU> since MD is up again, and doesn't show any immediate signs of disk lossage, i have added it back to the *MSGS and INQUIR update facilities.  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 4 May 87 04:27:24 EDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 4 May 87 01:23:28 PDT Date: Mon, 4 May 87 00:05:09 PDT From: Mark Crispin Subject: KS10 power fail To: BUG-ITS@AI.AI.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12299611731.6.MRC@PANDA> Hi. I was reading some of the old BUG-ITS mail and saw some messages about power fail recovery. Forget about it on the KS10. Although it was originally going to be included (and I think the prototype machine had it), production KS's don't have any battery backup for the MS10 memory. Since MS10 is MOS based, once the power goes it gets nuked. The best thing ITS can do is with a power fail interrupt is to quiet down any disk traffic as quickly as possible (certainly nuke all reads and any writes that aren't essential to prevent filesystem damage) and halt. Since KS10 power supplies are made by a real vendor and not DEC, KS's don't see trivial little glitches. The power has to be off for some time, something like 250ms, for a KS to croak. My KS has survived power glitches that reset the digital clocks and zapped the TV! So, if you get a power fail interrupt there is a good chance that the disks are already in the process of shutdown. -------  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 20 Apr 87 16:17:00 EDT Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 3302; Mon, 20 Apr 87 11:43:53 EDT Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 6677; Mon, 20 Apr 87 17:43:46 EDT Message-ID: <247761@QZCOM> In-Reply-To: <187812.870420.CENT@AI.AI.MIT.EDU> Date: 20 Apr 87 16:16 +0200 From: "Peter Lothberg STUPI" Reply-To: "Peter Lothberg STUPI" , "ITS bugs mailing list" To: "ITS bugs mailing list" cc: BUG-ITS@AI.AI.MIT.EDU Subject: alas, poor SAIL-KA Mark Crispin bought the KA10 with the BBN pager. He wanted to have a KA10 front panel, and we took the pager to attach to one of our working KA10:s.  Date: Mon, 20 Apr 87 00:24:18 EDT From: "Pandora B. Berman" Subject: alas, poor SAIL-KA To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <187812.870420.CENT@AI.AI.MIT.EDU> i sent LES@SAIL some info about old MAC PDP-10s.... ---------- Date: 16 Apr 87 1253 PDT From: Les Earnest Subject: re: PDP10 history project To: CENT@AI.AI.MIT.EDU .... Incidentally, the Computer Museum already has a PDP-6 -- we gave them ours. At the time I thought that it was the only one left in the world. We recently killed our KA10 and sold it to a collector for $500, including the BBN pager.....  Date: Fri, 17 Apr 87 08:41:07 EDT From: David Vinayak Wallace Subject: Same old Shit To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <186662.870417.GUMBY@AI.AI.MIT.EDU> (as of today you can't say that on the radio any more) AI crashed with the usual "Freeing packet still in use!" See crash PKTFRE if you care  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by AI.AI.MIT.EDU 16 Apr 87 04:36:44 EDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Thu, 16 Apr 87 01:31:16 PDT Date: Thu, 16 Apr 87 00:29:35 PDT From: Mark Crispin Subject: Re: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262) To: ALAN@AI.AI.MIT.EDU cc: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <185625.870416.ALAN@AI.AI.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12294897588.8.MRC@PANDA> I am involved peripherally with this project. There is NO attempt to shortchange or ignore ITS, WAITS, and TENEX. But!! We will need *papers* from people in these communities in order to fairly cover these operating systems. Otherwise, I will write up something really brief. For ITS, in a few short paragraphs I'll talk about DDT as the command decoder, PCLSR'ing, and the environment that led to the creation of EMACS. I think such coverage WOULD shortchange ITS. There are lots of important concepts that can and should be discussed in detail -- PCLSR'ing, ITS virtual memory (not as good as TOPS-20/Tenex, but quite advanced for its time), canonical terminals/SUPDUP/CRTSTY, symbolic system calls, CHEOPS, Knight TV system, ... TECO and TECO-based editors should be a paper in itself. -------  Date: Thu, 16 Apr 87 02:04:00 EDT From: Alan Bawden Subject: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262) To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <185625.870416.ALAN@AI.AI.MIT.EDU> The following message was forwarded to me (it was originally sent to AIList I think) with the suggestion that I should redistribute it to whatever mailing lists of PDP-10 hackers I knew of. I don't know anything more about this than what is revealed here. It does kind of sound like these guys are planning on writing a history of PDP-10's that only mentions TOPS10 and TOPS20 and fails to consider ITS and WAITS and perhaps shortchanges TENEX. But I suspect that this is merely a shortcoming of this announcement. Date: 16 Mar 1987 1311-EST From: "Joe Dempster, DTN: 336.2252 AT&T: 609.665.8711" Subject: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262) This message originates from 2 sources: Les Earnest Computer Science Department STANFORD UNIVERSITY Stanford, CA 94305 415.723.9729 ARPA: LES@SAIL.STANFORD.EDU Joe Dempster DIGITAL EQUIPMENT CORPORATION 6 Cherry Hill Executive Campus Route 70 Cherry Hill, NJ 08002 609.665.8711 ARPA: DEMPSTER@MARLBORO.DEC.COM (MARKET) The goal of this project is to publish an analysis and history of the evolution, implementation and use of Digital's 36 bit systems. This period began with the PDP-6 in 1964 and continues today with TOPS 10/20 development, which is scheduled to end in 1988. We are working aggressively to finish the project, and have it published, by March/April 1988. This will require that the completed manuscript be ready to go into the publication cycle by August 1987! The project will attempt to answer the following questions: 1. In what markets/applications were these systems used? 2. Who were the users of these systems and what impact did roughly 2,500 TOPS 10/20 systems have on their organizations? 3. Who were the principle system architects of these systems? What features, and if there had been sufficient time to implement them, would have significantly improved the architecture? 4. What impact did the decision to continue to examine design extensions to the architecture have on the usefulness and acceptability of these systems. This is in contrast to a more common practice today to work from a detailed design specification, sometimes dated, building follow-on systems which provide increased performance through the use of new component technologies and packaging techniques. 5. What part of the overall design (TOPS10/20) was technology dependent and what can still be considered "unequaled" in relation to other computer architectures still undergoing active development? 6. What type of development environment (both HW and SW) supported and contributed to the evolution of 36 bit systems? 7. What influence did TOPS 10/20 have on other vendors system development? This history will undoubtedly be assembled from many sources and participants. Some information will be anecdotal; there will be interviews with the people involved (users and developers) and technical papers will be solicited. Of course there will also be the packaging and assembly of facts as we see them. The result will hopefully have sufficient depth to serve as: 1. An introductory or advanced text on system design and hardware/system software implementation. 2. A analysis of the success and difficulties of marketing complex systems into a very crowded market of competing alternatives. 3. A catharsis for those of us who have contributed to the development and use these systems and who will now move onto new computing architectures and opportunities. In addition to interviewing directly 25-50 developers, users and product managers we will continue to work to identify contributors and significant events up to when the final draft is submitted to the publisher. Two "topics" are already under development: 1. Rob Gingell from SUN is working on a paper which looks at extensions to TOPS 20 which would have enhanced its capabilities. 2. Frank da Cruz and Columbia are summarizing 10 years of experience and development of TOPS 20 systems. Some effort will also be made to detail the process which lead to their selection of a follow-on architecture to TOPS 20. There is a need to develop additional topics which represent the use and application of the technology (TOPS 10/20) in other areas. Specific recommendations are welcome as are proposals to develop them. A short abstract should accompany any such proposal. Every effort will be made to work with individuals or organizations interested in making such a contribution. There will be a standalone (no network connections) DECSYSTEM 2020 (YIPYIP) dedicated to supporting the project. This system has a 3 line hunt group, with all lines accessible from a single number (201.874.8612). Both YIPYIP and MARKET will have "public" directories for remote login (DEMPSTER.PROJECT-10262 LCGLCG). MARKET can be accessed by modem (617.467.7437), however disk quota is limited. MARKET's primary purpose is ARPAnet TELNET access. YIPYIP is a dedicated PROJECT-10262 system. MAIL can also be sent to DEMPSTER on either system. YIPYIP and MARKET will keep a running summary of ideas and comments up on Columbia's BBOARD software. KERMIT also runs on each system for uploads. SAIL.STANFORD.EDU will support ARPAnet transfers to a "public" area: FTP CONNECT SAIL.STANFORD.EDU SEND AFN.EXT DSK: AFN.EXT [PUB,LES] SAIL runs WAITS, an operating system similiar to TOPS 10. File names are limited to 6 characters and extensions limited to 3. Implementation details: 1. User input is welcomed and desired from all application and geographic areas. 2. Input from past and present developers is also desired. 3. Throughout the project a secondary goal will be to build a list of users/locations (installation date, duration and disposition) of PDP-6 and KA, KI, KL and KS systems. Serial numbers, if available, are requested. 4. We anticipate that this project will generate a large volume of information (which we hope will arrive electronically). Some information, for any number of reasons, may not be in line with the project's stated goals. Therefore, all notes, interview material and submissions will be donated to the Computer Museum in Boston at the the completion of the project to be available for future reference and research. Ideas, contributions, suggestions and criticism are welcome. As these 36 bit systems were the products of a multitude of people, so too will be the writing of their history.  Date: Tue, 31 Mar 87 18:21:04 EST From: Alan Bawden Subject: [KLOTZ%OZ.AI.MIT.EDU: sys;system mail] To: ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 30 Mar 87 14:54:07 EST from David Chapman Message-ID: <176953.870331.ALAN@AI.AI.MIT.EDU> Nothing you could tell me about when DDT and PWORD handle newlines in the presence or absence of SYSTEM MAIL would supprise me. I've looked at that code once before trying to make both programs do the same thing, and I was unable to do that. If anyone else thinks they want to straighten this out, I can suggest about 8 other projects that would be more useful.  Date: Mon, 30 Mar 87 14:54:07 EST From: David Chapman Subject: [KLOTZ%OZ.AI.MIT.EDU: sys;system mail] To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <176082.870330.ZVONA@AI.AI.MIT.EDU> Well, this is really random. Date: Mon 30 Mar 87 02:18-EST From: Leigh L. Klotz To: zvona%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU Re: sys;system mail Actually I wanted to put a * in the file but it turns out that ddt prints out a crlf after the file if there wasn't one...  Date: Sun, 29 Mar 87 14:41:13 EST From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU cc: KLOTZ@AI.AI.MIT.EDU Message-ID: <175557.870329.ZVONA@AI.AI.MIT.EDU> I deleted ai:sys;system mail a few days ago, and then someone wrote one that has just a crlf in it. I agree with him (Klotz actually) that this looks better. Seems like a kludge this way; maybe it would be better to patch ddt/pword to print the crlf there instead.  Date: Tue, 24 Mar 87 09:48:33 EST From: Ed Schwalenberg Subject: CAMEXEC To: CENT@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, AAD@AI.AI.MIT.EDU, HENRY GAMMERDINGER@AI.AI.MIT.EDU Message-ID: <173000.870324.ED@AI.AI.MIT.EDU> Date: Tue, 24 Mar 87 03:40:44 EST From: "Pandora B. Berman" Date: Sat, 21 Mar 87 05:59:20 EST From: "Anthony A. Datri" Subject: is this a mailing list? ... IBM. Also, I saw something somewhere about something called CAMEXEC, which called it an its-like operating system for the pdp-11. Since ... ... as to CAMEXEC, yes, it is an ITS-emulating system, written by ED@AI. ... Before this gets out of hand, CAMEXEC was written by Mike Speciner, who was MS@AI a very long time ago (so long ago that the "@AI" part was seldom used, since the ARPAnet didn't really work very well yet).  Date: Tue, 24 Mar 87 03:40:44 EST From: "Pandora B. Berman" Subject: is this a mailing list? To: AAD@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <172875.870324.CENT@AI.AI.MIT.EDU> Date: Sat, 21 Mar 87 05:59:20 EST From: "Anthony A. Datri" Subject: is this a mailing list? To: INFO-ITS@AI.AI.MIT.EDU, INFO-ITS-REQUEST@AI.AI.MIT.EDU Is this an ITS mailing list (duh!)? If so, could I be added to it? I'm relatively new to ITS (turist account), and I'd love to find out more. I have great respect for an os that was named to make fun of IBM. Also, I saw something somewhere about something called CAMEXEC, which called it an its-like operating system for the pdp-11. Since I've got an 11/34 with nothing better to run than 2.9.1 BSD or RT11, I'm interested. Does anyone know anything about this? (hmm. that sounds like a stupid question, doesn't it?) If I seem confused, it's because I largely am. I'm learning about ITS by trial and error. I bet this will seem the strangest to you. IS ITS public domain at this point? If it is, what would it take to get a distribution? This is a very silly question, but I seriously intend to have a 2020 of my own someday. If Mr. Crispin can do it, so can I 8^) Thanks for any time you spend putting up with and/or answering this mail. INFO-ITS is, of course, a mailing list, but it is not used for regular mail. it follows the original fashion of lists named INFO-x, being a very large list used only for announcements of general interest and importance to the ITS community -- for instance, major changes in the system. you should not send mail to it. i will add you to it (if no one else has yet), but don't expect more than one or two msgs a year to be sent. BUG-ITS or one of the more specific ITS-related lists is probably the right list for your various questions. as to CAMEXEC, yes, it is an ITS-emulating system, written by ED@AI. he can give you lots of information about it. ITS is more or less public domain. however, there is no regular distribution system; each ITS kit is custom-made. for one thing, in the current scheme of things, each ITS in the world needs a unique two-letter ID, assigned here so it can be included in some of the deep internals. so we are not inclined to scatter ITS kits at random. if you get a KS, and want such a kit, the correct list to correspond with is KS-ITS@AI. for info on ITS, you should start by looking into the :INFO program and reading what it has to offer.  Date: Sat, 21 Mar 87 05:59:20 EST From: "Anthony A. Datri" Subject: is this a mailing list? To: INFO-ITS@AI.AI.MIT.EDU, INFO-ITS-REQUEST@AI.AI.MIT.EDU Message-ID: <171734.870321.AAD@AI.AI.MIT.EDU> Is this an ITS mailing list (duh!)? If so, could I be added to it? I'm relatively new to ITS (turist account), and I'd love to find out more. I have great respect for an os that was named to make fun of IBM. Also, I saw something somewhere about something called CAMEXEC, which called it an its-like operating system for the pdp-11. Since I've got an 11/34 with nothing better to run than 2.9.1 BSD or RT11, I'm interested. Does anyone know anything about this? (hmm. that sounds like a stupid question, doesn't it?) If I seem confused, it's because I largely am. I'm learning about ITS by trial and error. I bet this will seem the strangest to you. IS ITS public domain at this point? If it is, what would it take to get a distribution? This is a very silly question, but I seriously intend to have a 2020 of my own someday. If Mr. Crispin can do it, so can I 8^) Thanks for any time you spend putting up with and/or answering this mail. Anthony A. Datri aad@ai.ai.mit.edu (but i imagine you guessed that, eh?)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 20:20:36 EST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 20:09:06 EST Date: Fri 20 Mar 87 20:03:32-EST From: "John Wroclawski" Subject: Re: TCP buffers To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12288011565.22.JTW@MIT-SPEECH> Yow! Anyway, what I was going to say when the message cleverly decided to send itself was that the second TCP buffer problem (which is the more serious - the SYN problem loses packets slowly over time, but when the IMP problem hits you have had it) is due to my driver code's apparent inability to always recover correctly from a dropped ACC interrupt. I haven't had a chance to look at the SYN problem yet, but given what we learned from Dave's stuff it should be fairly easy to find. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 19:56:09 EST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 19:58:54 EST Date: Fri 20 Mar 87 19:53:22-EST From: "John Wroclawski" Subject: Re: TCP buffers To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12288009716.22.JTW@MIT-SPEECH> Moon's PEEK mode actually showed two different problems with the TCP buffer stuff. Alan mentioned the first one; there is a path which drops SYN packets on the floor. Dave mentioned the second; the KS IMP driver occasionally forgets what it is supposed to be doing. The secon -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 16:35:06 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 20 Mar 87 16:23:56 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98275; Fri 20-Mar-87 15:20:04 EST Date: Fri, 20 Mar 87 15:19 EST From: David A. Moon Subject: TCP buffers To: Ken Harrenstien cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <171046.870320.KLH@AI.AI.MIT.EDU> Message-ID: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 20 Mar 87 01:47:48 EST From: Ken Harrenstien Another approach would be to modify PEEK (or something else) to look at the buffers, including those not on any list. The contents might give you a clue -- perhaps they are all from a particular host, or use a particular protocol, or all have the SYN or FIN bit set, etc. I did that a month or two ago. I don't remember any more what I found out, except that there were a large number of buffers queued for transmission and the IMP wasn't taking them. But I don't remember what was in them. We still have the crash dumps and :p ? should say what the new mode is (1A I think).  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 15:31:34 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 15:34:47 EST Date: Fri, 20 Mar 87 15:30:42 EST From: Alan Bawden Subject: TCP buffers To: KLH@AI.AI.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 20 Mar 87 01:47:48 EST from Ken Harrenstien Message-ID: <171296.870320.ALAN@AI.AI.MIT.EDU> I guess it wasn't announced to Bug-ITS when Moon put a mode into PEEK for looking at TCP buffers (type "1A"). After using this mode on running systems and crash dumps it appears that the lost packets are always SYN packets with their Retransmit flag set. JTW points out that the only effect of a bug that causes retransmission of SYNs to get dropped would be that opening connections would time-out more frequently than they should. This doesn't address the issue of why the problem only seems to happen on the KS's and never on the KL.  Date: Fri, 20 Mar 87 14:52:06 EST From: Jonathan A Rees Subject: today's crash To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <171239.870320.JAR@AI.AI.MIT.EDU> "PK: Freeing packet still in use! PI LEVEL 2 BUGHALT ..." Dumped to CRASH; PACKET INUSE . -Jonathan  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 01:48:46 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 01:51:39 EST Date: Fri, 20 Mar 87 01:47:48 EST From: Ken Harrenstien Subject: TCP buffers To: ALAN@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <171046.870320.KLH@AI.AI.MIT.EDU> One approach for finding out where the buffers are going might be to look at the various meters. If you find a meter which has a count the same as (or close to) the number of buffers that are "lost", then you've found something. Another approach would be to modify PEEK (or something else) to look at the buffers, including those not on any list. The contents might give you a clue -- perhaps they are all from a particular host, or use a particular protocol, or all have the SYN or FIN bit set, etc. Considering the remarkable things that have already been discovered with respect to .HANG and LOCKS, surely yet another long standing mystery will shortly come to light.  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAR 87 18:12:06 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 28498; Sun 15-Mar-87 18:09:51 EST Date: Sun, 15 Mar 87 18:09 EST From: Alan Bawden Subject: Recent bugs To: BUG-ITS@AI.AI.MIT.EDU cc: ED@AI.AI.MIT.EDU In-Reply-To: <132118.861218.ALAN@AI.AI.MIT.EDU>, <141115.870116.ALAN@AI.AI.MIT.EDU> Message-ID: <870315180951.4.ALAN@PIGPEN.AI.MIT.EDU> Date: Thu, 18 Dec 86 02:57:19 EST From: Alan Bawden TTYSET on a TTY opened as a device (rather than as a console) clobbers the wrong TTYST* words! I am unable to reproduce this. I'm certain I was able to clobber SIXBIT/FOOBAR/ into the TTYST1 word of T0n+1 when I had T0n open as a device, but I can't get it to happen now... I must have been severely faked out somehow. Date: Fri, 16 Jan 87 17:13:23 EST From: Alan Bawden After reading the following bug report [not included], you will realize that this reveals a bug in the way jobs are sometimes killed when they have locks locked. If you -first- clobbering their PC's to point to a .LOGOUT in location 0, and only the .LOGOUT then checks to see if the PC is in the critical routine table, then the critical routine table is worthless... I fixed the lock unlocking stuff to always use the correct PC, so .GUNing somebody when he is in a critical region should now do the right thing. I didn't do anything to prevent lock unlocking instructions from clobbering the location that contains the .LOGOUT.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 MAR 87 13:41:26 EST Date: Wed 11 Mar 87 13:38:43-EST From: "John Wroclawski" Subject: Re: not a bug To: RISTAD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: bug-system@AI.AI.MIT.EDU In-Reply-To: Message from "Eric Sven Ristad " of Wed 11 Mar 87 13:21:53-EST Message-ID: <12285582215.16.JTW@MIT-SPEECH> 10.2.0.6 You can use the HOST program to find out things like this. (:HOST AI from an ITS or HOST AI from a TOPS-20 like OZ) -------  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 MAR 87 13:18:29 EST Date: Wed 11 Mar 87 13:14-EST From: Eric Sven Ristad Subject: not a bug To: bug-system@AI.AI.MIT.EDU What is AI's telnet address (e.g. MX is 10.1.0.6)? Thanks, Eric  Received: from eneevax.umd.edu (TCP 20002102401) by AI.AI.MIT.EDU 10 Mar 87 00:44:05 EST Received: by eneevax.umd.edu (5.9/4.7) id AA13924; Tue, 10 Mar 87 00:41:36 EST Date: Tue, 10 Mar 87 00:41:36 EST From: Douglas Humphrey Message-Id: <8703100541.AA13924@eneevax.umd.edu> To: BUG-ITS@AI.AI.MIT.EDU, BUG-KS@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Subject: Re: MD has internal troubles RP06 Disk drives are selling for less than the $500 that you state it will take to fix the existing drive. Has someone contacted used hardware places in the Boston area (to save shipping charges) to see if they will either sell or donate an RP06 or two ? I will note that a place in Atlanta just had several Hundred RP06 drives sent to a scrapper for cents per pound because there is no market for them any longer. Doug  Date: Mon, 9 Mar 87 00:36:27 EST From: "Pandora B. Berman" Subject: MD has internal troubles To: BUG-KS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <165407.870309.CENT@AI.AI.MIT.EDU> (remailed for the record) Date: Fri, 6 Mar 87 16:00 EST From: Alan Bawden Subject: MD Well, head 7 on MD's RP06 is deteriorating fast. JTW just tried cleaning the heads, but it doesn't look like that helped the problem. I'm considering taking ITS down so as to not risk damage to the filesystem. This drive is not on service contract, and neither AI nor presumably LCS has any real interest in paying to get it fixed. It cost about 500 bucks to get this fixed when it happened to one of AI's drives. [ CStacy broke the UNLOCK routine in the Salvager, by the way... ]  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 6 Mar 87 13:27:10 EST Date: Fri, 6 Mar 1987 13:24 EST Message-ID: From: Rob Austein To: BUG-ITS@AI.AI.MIT.EDU Subject: BT AUTO In-reply-to: Msg of 6 Mar 1987 12:47-EST from David Vinayak Wallace If we can do the hack with Gumby's clock, I say this is a win. I have always considered it a big feature that I can go home and sleep and not be beheaded in the morning by 50 irate XX users who want to know why their mail hasn't gotten through. It'd be nice if MC and AI could take care of themselves too. It seems it ought to be possible to detect which drives are offline at boot time; Twenex does this, perhaps DSKDMP or ITS could just zap QACT when it sees that a drive is offline? While we're adding twenexisms, how about automatic crash dumps and automatic proceed or reload when there isn't a hacker on duty? :-)  Date: Fri, 6 Mar 87 12:47:39 EST From: David Vinayak Wallace Subject: BT AUTO To: ALAN@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU In-reply-to: Msg of Thu 5 Mar 87 19:37 EST from Alan Bawden Message-ID: <164347.870306.GUMBY@AI.AI.MIT.EDU> Date: Thu, 5 Mar 87 19:37 EST From: Alan Bawden In theory there is a bit that the 8080 sets to indicate that this is an auto-boot. DSKDMP could test that bit and always load .;@ ITS. Then it could set some kind of a flag to tell DDT to immediately $G and then start it. Then we would have to change all of our habits about disk drives being offline, because we would always need to patch QACT in the binary as well as the running system. This is reasonable. We could get rid of that crufty ITS/NITS/XITS naming randomness too (what's wrong with a link?). Then we have to figure out what to do about setting the time. After a power-glitch, a KS-10 will -always- forget the time. Getting the time from the network simply doesn't work. (This afternoon when AI and MC asked for the time from the network, only -one- host responded to their query. I'm kind of reluctant to set the time on the basis of a single answer.) I still have that clock that didn't get installed because I/we couldn't figure out which protocol was the best and what machine to put it on. Why not put it on MC? I've been watching it for the last several months and it keeps time better than my watch (which is what we use otherwise, right?)  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAR 87 19:38:02 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 26567; Thu 5-Mar-87 19:39:05 EST Date: Thu, 5 Mar 87 19:37 EST From: Alan Bawden Subject: BT AUTO To: SRA@XX.LCS.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: Message-ID: <870305193743.5.ALAN@PIGPEN.AI.MIT.EDU> [ Should have combined this message with the previous one, but I overlooked this message the first time through my mail. ] Date: Thu, 5 Mar 1987 13:34 EST From: Rob Austein ... Or is it, for some reason beyond my ken, considered a feature that ITS needs a human to reboot? Well, booting the system without human assistance just makes me a little nervous, but we could think about it: In theory there is a bit that the 8080 sets to indicate that this is an auto-boot. DSKDMP could test that bit and always load .;@ ITS. Then it could set some kind of a flag to tell DDT to immediately $G and then start it. Then we would have to change all of our habits about disk drives being offline, because we would always need to patch QACT in the binary as well as the running system. Then we have to figure out what to do about setting the time. After a power-glitch, a KS-10 will -always- forget the time. Getting the time from the network simply doesn't work. (This afternoon when AI and MC asked for the time from the network, only -one- host responded to their query. I'm kind of reluctant to set the time on the basis of a single answer.)  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAR 87 19:10:40 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 26559; Thu 5-Mar-87 19:11:45 EST Date: Thu, 5 Mar 87 19:10 EST From: Alan Bawden Subject: BT AUTO To: ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <163684.870305.ZVONA@AI.AI.MIT.EDU> Message-ID: <870305191017.3.ALAN@PIGPEN.AI.MIT.EDU> Date: Thu, 5 Mar 87 13:12:14 EST From: David Chapman AI and MC both lost with BT AUTO. I take it this was a powerglitch. I dumped to BTAUTO HUH? AI:, presumably this is gubbish if it really was a glitch. Lost a lot of work, fuck. Yeah, "BT AUTO" is what the 8080 front-end types when it decides to automatically boot the machine after the machine is powered on. For ITS the boot routine just loads up DSKDMP and starts it, which is presumably how you found the machine. Since the boot routine zeros core before loading DSKDMP (it does this to wipe out potential parity errors), your crash dump contains nothing more than the boot routine itself. Thanks for tending to the problem!  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 5 Mar 87 13:37:10 EST Date: Thu, 5 Mar 1987 13:34 EST Message-ID: From: Rob Austein To: David Chapman cc: BUG-ITS@AI.AI.MIT.EDU Subject: BT AUTO In-reply-to: Msg of 5 Mar 1987 13:12-EST from David Chapman Right, that's a powerglitch. The power fail microcode on the KSs doesn't seem to work any better than the powerfail code on the KL-Bs (worse, actually, about once every six months XX or OZ will reboot correctly after a powerfail and surprise the hell out of everybody). I know that in the case of the KL-Bs running twenex microcode this has been a problem for years. It gets fixed, then broken, then fixed, ad nauseum. Unless Alan tells me otherwise I'd assume it's a similar problem on the KSs. Or is it, for some reason beyond my ken, considered a feature that ITS needs a human to reboot?  Date: Thu, 5 Mar 87 13:12:14 EST From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <163684.870305.ZVONA@AI.AI.MIT.EDU> AI and MC both lost with BT AUTO. I take it this was a powerglitch. I dumped to BTAUTO HUH? AI:, presumably this is gubbish if it really was a glitch. Lost a lot of work, fuck.  Date: Tue, 24 Feb 87 15:05:39 EST From: kltoz@AI.AI.MIT.EDU Sender: ___016@AI.AI.MIT.EDU Subject: Rudy.Nedved and the end of TOPS-10 To: POOR-MX@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <159022.870224.___016@AI.AI.MIT.EDU> Rudy Nedved is the person who caused the demise of info-cobol.  Date: Tue, 24 Feb 87 01:21:56 EST From: "Pandora B. Berman" Subject: small request To: Rudy.Nedved@H.CS.CMU.EDU cc: POSTMASTER@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, POOR-MX@AI.AI.MIT.EDU Message-ID: <158772.870224.CENT@AI.AI.MIT.EDU> Date: Monday, 23 February 1987 19:28:36 EST From: Rudy.Nedved@h.cs.cmu.edu To: postmaster@mc.lcs.mit.edu Subject: small request Hi, Could some kind person take the time out to remove MIT-MESSAGES@A.CS.CMU.EDU from the mit bboard distribution list? done, mostly by Gumby (i cleaned up a few things he missed). It has been eons since I made a change to a mailing list on MIT ITC you mean ITS, right? machines. Thanks much, -Rudy CMU CS/RI Postmaster P.S. The last TOPS-10 machine on the ARPANET, A.CS.CMU.EDU is going away in a week or so. The official shutoff time for users is this Monday, March 2nd. alas, poor PDP-10s -- yet another casualty. it deserves recording (wherefore the CCs to the other lists) and public mourning. probably if you send a mildly clever farewell msg to arpanet-bboards it will get broadcast...  Date: Mon, 23 Feb 87 23:36:44 EST From: Alan Bawden Subject: confused To: CENT@AI.AI.MIT.EDU cc: BUG-LOCK@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 23 Feb 87 22:49:38 EST from Pandora B. Berman Message-ID: <158719.870223.ALAN@AI.AI.MIT.EDU> Actually, its ITS that is at fault, not LOCK. You killed your LOCK job and someone else's TELSER happened to get the same job slot before ITS got around to printing the tattle on the system console. I don't know why the .SHUTDN uuo doesn't just do a BUG INFO to report what happened rather than using the buggy kludge that it does...  Date: Mon, 9 Feb 87 11:54:49 EST From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <151362.870209.ZVONA@AI.AI.MIT.EDU> AI crashed at 9:44 this morning with a bughalt message PK: GF node wasnt on list This came right after IMP output msg too big 2996 09:44:12 which is probably responsible. Crash dump in crash;crash pknogf.  Date: Tue, 3 Feb 87 07:31:26 EST From: "Pandora B. Berman" Subject: MD status To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <148487.870203.CENT@AI.AI.MIT.EDU> OZ has a recalcitrant disk drive. lester has tried this and that but it's still down. so he asked about hooking it up to one of the KSs for testing. alan and i told him he could use MD. he promised to write something in MD's log noting what he was doing.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jan 87 17:00:15 EST Date: Sat, 31 Jan 87 17:01:01 EST From: Alan Bawden Subject: TCP buffers To: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <165683.870131.ALAN@MC.LCS.MIT.EDU> I wish we could figure out why ITS consistently dribbles away its TCP buffers until there are none left. I also wish that when this happens, COMSAT didn't exhibit this bizare behavior: 162430 Unqueueing to host THEORY.LCS.MIT.EDU 162431 ICP->THEORY.LCS.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162432 Unqueueing to host RED.RUTGERS.EDU 162433 ICP->RED.RUTGERS.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162434 Unqueueing to host BRL-SEM.ARPA 162435 ICP->BRL-SEM.ARPA (TCP-SMTP=Bad Greeting="221 BCNU") 162435 Unqueueing to host LBL.ARPA 162436 ICP->LBL.ARPA (TCP-SMTP=Bad Greeting="221 BCNU") 162437 Unqueueing to host SDCSVAX.UCSD.EDU 162438 ICP->SDCSVAX.UCSD.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162439 Unqueueing to host R20.UTEXAS.EDU 162440 ICP->R20.UTEXAS.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162441 Unqueueing to host SAIL.STANFORD.EDU 162442 ICP->SAIL.STANFORD.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162444 Unqueueing to host ATHENA.MIT.EDU 162444 ICP->ATHENA.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162445 Unqueueing to host CHARON.MIT.EDU 162446 ICP->CHARON.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JAN 87 15:01:45 EST Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19480; Mon 26-Jan-87 15:03:06 EST Date: Mon, 26 Jan 87 15:03 EST From: Alan Bawden Subject: IAP To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870126150304.6.ALAN@KAREN.AI.MIT.EDU> Despite the fact that in the IAP guide I promised four sessions of the ITS course, there will -not- be a fourth session this week. See you all again next year!  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 87 20:04:59 EST Date: Thu 22 Jan 87 20:05:01-EST From: "John Wroclawski" Subject: RP06 undocumented behavior To: bug-its@AI.AI.MIT.EDU Message-ID: <12273069628.19.JTW@MIT-SPEECH> The twenex world recently discovered that an RP0x which gets a header compare error (HCE) without getting a header CRC error (HCRC) at the same time may need to have a recalibrate operation done rather than just a recenter and retry type thing. Otherwise the head ends up mispositioned till it eventually slams into the stops (which either fixes it or breaks it but good). Apparently this is contrary to what the "manual" says. I don't know what ITS does in this case. Just writing it down for the record. -------  Date: Thu, 22 Jan 87 04:16:36 EST From: Alan Bawden Subject: PEEK shouldn't ever PCLSR anyone To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 21 Jan 1987 00:25 EST from Rob Austein Message-ID: <143202.870122.ALAN@AI.AI.MIT.EDU> After fixing PEEK to not needlessly PCLSR device servers a few days ago, I have been periodically watching COMSAT and DQDEV on MC waiting to catch them in the act of getting hung up. This afternoon I found them in the wedged state and was able to figure out what causes the problem. The problem has nothing to do with the BOJ/JOB code, and is not a bug in DQDEV. Actually it is an apparently long-standing timing error in the implementation of .HANG. Specifically, when you did (as DQDEV does) TRNN AC,%FLAG .HANG the code for .HANG knew that the TRNN instruction could never skip unless the C(AC) changed, and since nothing can change a job's accumulators without PCLSRing the job, .HANG could simply hang forever. This is all well and good, except .HANG neglected to run the instruction once itself to be certain that AC hadn't been changed by an interrupt routine that ran -between- the TRNN and the .HANG. I have assembled an ITS with the fix and I will test it the next time I get a chance.  Date: Wed, 21 Jan 87 02:12:12 EST From: "Pandora B. Berman" Subject: ai crashed To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <142633.870121.CENT@AI.AI.MIT.EDU> again, or halted, or whatever it was. see CRASH;UNIT0 FUKT. Unit 0 had spun down. i spun it up and reloaded.  Date: Fri, 16 Jan 87 17:13:23 EST From: Alan Bawden Subject: [MOON: Mysterious MC won't shut down crash explained] To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <141115.870116.ALAN@AI.AI.MIT.EDU> After reading the following bug report, you will realize that this reveals a bug in the way jobs are sometimes killed when they have locks locked. If you -first- clobbering their PC's to point to a .LOGOUT in location 0, and only the .LOGOUT then checks to see if the PC is in the critical routine table, then the critical routine table is worthless... Date: Fri, 16 Jan 87 01:39:40 EST From: David A. Moon To: ALAN at AI.AI.MIT.EDU cc: BUG-COMSAT at AI.AI.MIT.EDU Re: Mysterious MC won't shut down crash explained You aren't going to like this one damn bit. TMPLOC 44, -LCCBLK,,CCBLK ;aobjn ptr to critical code table for lock hacking looks like it would put an aobjn pointer into location 44, doesn't it? It doesn't. It puts -LCCBLK into location 44 and CCBLK into the next location inline (where it happens to get ignored). This is because ; TMPLOC , - puts argument at given LOC ; without changing location counter outside macro call. DEFINE TMPLOC VAL,?ARG [definition deleted] Why the heck doesn't TMPLOC use a rest-of-line arg? Now -LCCBLK is -1,,777772, an aobjn pointer to a page that is mapped into absolute page 120, which contains whatever it happens to contain. If the PC happens to lie within the bounds of the first word there, the system executes the second word there as an instruction, with the extra added feature (see IODCD1 in ITS) that if the LH is zero, SETOM is substituted. Thus when Comsat executes the .LOGOUT that ALOGO4 puts into its AC 0 when the system job guns it, the unlocking of Comsat's locked switches, if that absolute page contains zeros, will do a SETOM 0. If Comsat doesn't pclsr, that -1 is never seen, but if it does PCLSR out of the .LOGOUT (we still don't know where it pclsred from), it executes that -1 as an instruction, causing the lossage we saw. Yow! It looks like it's been this way for eons. Maybe this also explains why the Comsat locks don't always seem to work right.  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 16 Jan 87 04:17:47 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715239312833556@MIT-MULTICS.ARPA>; 16 Jan 1987 04:08:32 est Message-ID: <227734@QZCOM> In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Date: 16 Jan 87 01:07 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: IAP If someone has a home-video-tape-recorder-and-camera-set at MIT availible, it wold be nice to have a vide tape of the lecture, for us that can't show up.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JAN 87 15:29:36 EST Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 15 Jan 87 15:21-EST Date: Thu, 15 Jan 87 15:23 EST From: Alan Bawden Subject: IAP To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU In-Reply-To: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Those of you who missed the second session of the ITS course last night should be aware that next week we will once again meet on -Wednesday-. It seems I screwed up when I thought we couldn't have the playroom this Tuesday, and it is actually -next- Tuesday than has the conflict. Next Wednesday we'll do something about Job Devices. How to write one, or how they are implemented, or something like that...  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JAN 87 16:52:54 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 17414; Wed 7-Jan-87 16:50:47 EST Date: Wed, 7 Jan 87 16:50 EST From: Alan Bawden Subject: IAP To: Info-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU> Those of you who missed the first session of the ITS course last night should be aware that next week we will meet on -Wednesday- instead of Tuesday. The following week we will go back to meeting on Tuesdays. (All meetings are in the 7th floor playroom at 7:30). Next Wednesday we will hear a bit about the ITS filesystem (not all that much to tell) and then Ed Schwalenberg will tell us about "CAMEXEC: An ITS-style Operating System for PDP11's".  Date: Sun, 4 Jan 87 05:03:53 EST From: Alan Bawden Subject: IAP To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <136289.870104.ALAN@AI.AI.MIT.EDU> Yes, there will be an IAP course this January about ITS. The first meeting will take place in the 7th floor playroom this Tuesday (the 6th) at 7:30 PM. On Tuesday we will talk about a number of things, including what topics people might want to hear about in future sessions. As a main event, I am preparing an explanation of everyone's favorite ITS feature: PCLSRing: What it is, how it's implemented, and why Lisp Machines should have it. I'll try and satisfy both the people who want to hear about low-level, bits-between-the-toes issues, and those who want to learn universal, cosmic principles. I'll even relate PCLSRing to quantum mechanics.  Date: Thu, 1 Jan 87 15:43:25 EST From: Alan Bawden Subject: MX unit #5 To: KLOTZ@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, POOR-MC@AI.AI.MIT.EDU In-reply-to: Msg of Wed 31 Dec 86 22:12:10 EST from Leigh L. Klotz Message-ID: <135733.870101.ALAN@AI.AI.MIT.EDU> Date: Wed, 31 Dec 86 22:12:10 EST From: Leigh L. Klotz I just got a non-recoverable disk data error on klotz;emacs :ej, which is on 14. When you log in, SYS:SYSTEM MAIL warned you that unit #5 was sinking fast. Yeah, many files on that pack/drive have suffered. Perhaps I'll try swapping that pack with the one on unit #4 and see what happens. If we are really lucky, that will destroy both of them! Date: Wed, 31 Dec 86 22:28:06 EST From: Leigh L. Klotz I renamed the bad file to klotz;.bad. :EJ, but the error went away. It had been repeatable. Is anyone interested in this? Should I be sending mail to POOR-MC? POOR-MC is probably the right place, although perhaps there is a POOR-MX list that I don't know about. (POOR-KL?)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Dec 86 22:46:03 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 31 Dec 86 22:26:36 EST Date: Wed, 31 Dec 86 22:28:06 EST From: "Leigh L. Klotz" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <963808.861231.KLOTZ@MX.LCS.MIT.EDU> I renamed the bad file to klotz;.bad. :EJ, but the error went away. It had been repeatable. Is anyone interested in this? Should I be sending mail to POOR-MC?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Dec 86 22:19:49 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 31 Dec 86 22:10:41 EST Date: Wed, 31 Dec 86 22:12:10 EST From: "Leigh L. Klotz" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <963796.861231.KLOTZ@MX.LCS.MIT.EDU> I just got a non-recoverable disk data error on klotz;emacs :ej, which is on 14.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 22 Dec 86 20:39:45 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29850; Mon 22-Dec-86 20:36:56 EST Date: Mon, 22 Dec 86 20:36 EST From: David A. Moon Subject: Kludging around the KS's flakey disk To: Rob Austein cc: Bug-ITS@MIT-AI.ARPA, Poor-MC@MIT-AI.ARPA In-Reply-To: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU> Supersedes: <861222150854.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <861222203625.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 22 Dec 86 02:02 EST From: Rob Austein I just spent five minutes looking at the DISK code. Based on that wealth of experience, it appears to me that if I were to bring up the KS with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or so. Somebody tell me why I shouldn't do this, before I wear out the $P keys on the KS's console.... The idea was that if the disk goes unsafe, is reset, and goes unsafe again within one second, it is probably about to explode and the fire department should be called. It looks like the code jumps to UNSAFE for a lot of different reasons, not all of which are the drive going unsafe. The drive also goes unsafe for a lot of different reasons, some of more consequence than others. I agree that if you JFCL out the BUGPAUSE it won't do it any more, so if you think this won't do irreparable harm to the disk, go ahead.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Dec 86 02:04:20 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Dec 86 02:04-EST Date: Mon, 22 Dec 86 02:02 EST From: Rob Austein Subject: Kludging around the KS's flakey disk To: Bug-ITS@AI.AI.MIT.EDU, Poor-MC@AI.AI.MIT.EDU Message-ID: <861222020255.2.SRA@WHORFIN.LCS.MIT.EDU> I just spent five minutes looking at the DISK code. Based on that wealth of experience, it appears to me that if I were to bring up the KS with UNSAFE+1 JFCL'd out, it would stop doing a BUGPAUSE every hour or so. Somebody tell me why I shouldn't do this, before I wear out the $P keys on the KS's console....  Date: Sun, 21 Dec 86 23:17:45 EST From: Alan Bawden Subject: RP06s eat dead bears To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sun 21 Dec 86 13:52:25 EST from David Vinayak Wallace Message-ID: <133398.861221.ALAN@AI.AI.MIT.EDU> Date: Sun, 21 Dec 86 13:52:25 EST From: David Vinayak Wallace AI hung in a fashion I'd never seen on the KS's: disk accesses would hang forever. Pages in core were easily accessible; ITS ran fine unless you tried to touch the disk. I could create a job and run some instructions in low memory, but when I tried to do a .CALL OPEN ITS hung. You must have been lucky. Our RP06's have been causing ITS to hang in this way ever since day 1. I went upstairs and the system console said: DSK: UNIT #1 CAME BACK ONLINE DSK: UNIT #0 CAME BACK ONLINE DSK: UNIT #1 CAME BACK ONLINE and some status registers. For all three, ER1= 40000 which is Drive Unsafe. Unsafe almost always comes on. The interesting bits were the ones in ER3, which according to the crash dump were (according to the crufty documentation) "AC power low", "DC power low" and "Spare" (!). I dumped it to CRASH DSKOFL, not that I think it will help any. Why? I manadged to get the ER3 bits out of it. Notice that the crash file was written out but the dates were not set on the file? DSKDMP never sets write dates, because it doesn't know how to tell the time. The DMPCPY program (which TARAKA runs when the system boots) sets the date on any file it suspects is a crash dump. In this case, DMPCPY wasn't able to set the date either, because you had cold booted the machine, so ITS didn't know what time it was when DMPCPY ran. ... By the way, should these be going to BUG-ITS or KS-ITS -- I can never tell any more. You sent this to the right place. KS-ITS is almost -never- the right place to send a Bug Report.  Date: Sun, 21 Dec 86 22:34:01 EST From: Alan Bawden Subject: Gee, that's not his host's name To: RDZ@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, BUG-LISP@AI.AI.MIT.EDU In-reply-to: Msg of Sat 20 Dec 86 13:22 EST from Ramin Zabih Message-ID: <133383.861221.ALAN@AI.AI.MIT.EDU> Date: Sat, 20 Dec 86 13:22 EST From: Ramin Zabih Typing :FINGER on AI just produced this output: ... RDZ Ramin Zabih F T23 <>: 709 x8827 RDZ, Zvona (Chaos) It seems that someone is confused about the name of the 3600 I'm using... RDZ's host has a short name of "NULL". He's been expecting the name "NULL" to break some program ever since he named it that. I presume thats why he mailed this bug report to Bug-LISP. Nothing's broken actually. I was just hacking him...  Date: Sun, 21 Dec 86 13:52:25 EST From: David Vinayak Wallace To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <133197.861221.GUMBY@AI.AI.MIT.EDU> AI hung in a fashion I'd never seen on the KS's: disk accesses would hang forever. Pages in core were easily accessible; ITS ran fine unless you tried to touch the disk. I could create a job and run some instructions in low memory, but when I tried to do a .CALL OPEN ITS hung. I went upstairs and the system console said: DSK: UNIT #1 CAME BACK ONLINE DSK: UNIT #0 CAME BACK ONLINE DSK: UNIT #1 CAME BACK ONLINE and some status registers. For all three, ER1= 40000 which is Drive Unsafe. I dumped it to CRASH DSKOFL, not that I think it will help any. Notice that the crash file was written out but the dates were not set on the file? I cold-booted just in case -- ITS seems to be running fine now. By the way, should these be going to BUG-ITS or KS-ITS -- I can never tell any more. david  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 DEC 86 13:23:05 EST Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16312; Sat 20-Dec-86 13:22:41 EST Date: Sat, 20 Dec 86 13:22 EST From: Ramin Zabih Subject: Gee, that's not my host's name To: bug-lisp@OZ.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU Message-ID: <861220132243.9.RDZ@NULLSTELLENSATZ.AI.MIT.EDU> Typing :FINGER on AI just produced this output: -User- --Full name-- Jobnam Idle TTY -Console location- ___005 < [not logged in] HACTRN 23.T05 906 x1729 CENT, OAF KWH Ken Haase HACTRN *:**.T15 Net site PREP (Chaos) DPH Daniel Huttenlocher HACTRN 46.T16 723 x8843 Alan, DPH RDZ Ramin Zabih F T23 <>: 709 x8827 RDZ, Zvona (Chaos) It seems that someone is confused about the name of the 3600 I'm using...  Date: Fri, 19 Dec 86 02:54:39 EST From: Alan@AI,Moon@AI Sender: ALAN@AI.AI.MIT.EDU Subject: OK, I just saw it happen again. To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <132522.861219.ALAN@AI.AI.MIT.EDU> For most of yesterday (Thursday the 18th) COMSAT on MC was catatonic. Our guess is that it was stuck in a JOB device wait (waiting for the DQ device). As soon as Alan looked at the situation COMSAT started running again, so probably something he did caused COMSAT to get PCLSR'd out of the system call for the first time all day, and the second time the timing screw did not occur. The right thing is for someone to fix the last bug in the JOB/BOJ code. A quick fix the COMSAT maintainers might consider, is to take an occasional %PIRLT interrupt to keep its interactions with DQ lubricated. A better fix would be for Alan to finish up the improved Domain Demon interface, so that COMSAT can use it instead, and not be subject to this particular class of ITS bug.  Date: Thu, 18 Dec 86 02:57:19 EST From: Alan Bawden To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <132118.861218.ALAN@AI.AI.MIT.EDU> TTYSET on a TTY opened as a device (rather than as a console) clobbers the wrong TTYST* words!  Date: Thu, 4 Dec 86 14:00:04 EST From: Alan Bawden Subject: more fukt To: CENT@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Thu 4 Dec 86 03:20:35 EST from Pandora B. Berman Message-ID: <126472.861204.ALAN@AI.AI.MIT.EDU> Date: Thu, 4 Dec 86 03:20:35 EST From: Pandora B. Berman ... maybe lester didn't fix the disk hard enough. I don't think it is related. This is a problem we have had ever since we went to two drives. The symptom is that for no apparent reason a drive interrupts you and reports that it has just recently come back online. Both drives do it. We have no idea why they do this. We also have no idea why the code that we put in to recover from this doesn't work. (Perhaps we need to reset the drive harder when this happens.) Luckily this doesn't seem to happen all that often, but it has been the most common reason for AI crashes since we got the new drive. It also seems that if one drive is in the middle of a transfer, and you tell the other drive to do something, the first drive will interrupt you and complain that you shouldn't bother it while it is busy. We simply ignore these complaints, which seems to work just fine. (Like it's happened 470 times since AI came up 10 hours ago...)  Date: Thu, 4 Dec 86 03:20:35 EST From: "Pandora B. Berman" Subject: more fukt To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <126255.861204.CENT@AI.AI.MIT.EDU> it happened again. dumped to CRASH;FUCKED AGAIN. maybe lester didn't fix the disk hard enough.  Date: Thu, 4 Dec 86 01:19:00 EST From: "Pandora B. Berman" Subject: &^*^&$%!! To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <126198.861204.CENT@AI.AI.MIT.EDU> things were hanging all over, and alan diagnosed that a disk had briefly gone offline, and AI had not quite recovered correctly. only thing i could do, really, was to lift switch 0 and reload. crash dump (i think) to CRASH;FUCKME HARDER, a fine traditional name.  Date: Wed, 19 Nov 86 00:52:23 EST From: "Pandora B. Berman" Subject: ITS boot tapes To: USER-ACCOUNTS@AI.AI.MIT.EDU, mkunix!shawn@EDDIE.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].120162.861119.CENT> From: mkunix!shawn@EDDIE.MIT.EDU Date: Fri, 14 Nov 86 16:56:21 est To: mit-eddie!user-accounts@mit-ai Subject: ITS boot tapes Howdy, I would like to make a copy of the great ITS operating system, yes, I know, most people would say 'why', but someday I hope to work in a group that has an old KL/KA and bring up ITS... Being in DEC this is possable, although probably not likely. In any case, I wonder if someone would be willing at some point to show, or instruct me, or guide me in some way in how to make the two tapes I would need to a) Boot ITS and build a system, and b) Load in the sources to ITS, and any applications that are deemed ok to take/have. Please forgive me if this is the wrong forum, but I have been trying to find help from various points and ran out of places to ask... Thanks for any help. -- Shawn Btw, it may be simpler for anyone who wishes to reply to me, to just send me mail on MC, since I don't know if ITS can deal with uucp path names, although it may. Thanks again. of course ITS can deal with uucp paths, at least up to a point. however, as you suspect, USER-A is the wrong place to ask. even you could have thought of asking BUG-ITS.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 NOV 86 21:37:17 EST Date: Sun, 16 Nov 86 21:31:19 EST From: Rob Austein Subject: KL: .; IOELEV * To: BUG-its@AI.AI.MIT.EDU, poor-mx@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].958244.861116.SRA> I assembled and installed a new version of IOELEV for the KL. The only change is that it now knows that its name has changed (no longer tells you you are connected to MC). I'll change the namespace sometime soon if there aren't any problems with this. While I was installing this silliness, I reorganized the IOELEV binaries. KL Console-11 binaries are (as before) in IOELEV nnnBIN with IOELEV BIN as a link to the latest version (now IOELEV 431BIN). The AI-Chaos-11 binaries are now in IOELEV nnnAI with a link from IOELEV AIBIN to the latest version (IOELEV 430AI, the one where I made subnet six the "primary" address of AI-11 so dover spooling would work better). I don't expect any problems. Next person who cold boots the KL please tell me what happens (if no problems, tell me that). --Rob  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 NOV 86 19:52:40 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 11282; Thu 13-Nov-86 19:47:32 EST Date: Thu, 13 Nov 86 19:47 EST From: Alan Bawden Subject: AI wedged itself To: SRA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].117740.861112.SRA> Message-ID: <861113194734.2.ALAN@PIGPEN.AI.MIT.EDU> Date: Wed, 12 Nov 86 16:45:19 EST From: Rob Austein Dump in AI:CRASH;WEDGED IDUNNO, not that I expect anybody to have any use for it. Looks like there was a power glitch or something. I'm told there were air conditioning problems at the time as well.  Date: Wed, 12 Nov 86 16:52:39 EST From: Rob Austein Subject: "ECC" errors? To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].117747.861112.SRA> Happened to be next to AI (had just rebooted it). Heard one of the RP06s start fibrulating (the sort of mad seek motion that I normally only see on XX when both XX and its FE are trying to write on drive zero at the same time). A few seconds later an ECC message pops up on the console. Don't know if it means anything, but thought I should report it.  Date: Wed, 12 Nov 86 16:45:19 EST From: Rob Austein Subject: AI wedged itself To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].117740.861112.SRA> Dump in AI:CRASH;WEDGED IDUNNO, not that I expect anybody to have any use for it. --Rob  Received: from DIAMOND.S4CC.Symbolics.COM (TCP 20024231403) by AI.AI.MIT.EDU 4 Nov 86 16:33:11 EST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24769; Tue 4-Nov-86 16:27:49 EST Date: Tue, 4 Nov 86 16:27 EST From: David C. Plummer Subject: For those of you around MIT this January To: Alan Bawden , KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN> Message-ID: <861104162735.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sat, 25 Oct 86 01:38:44 EDT From: Alan Bawden Hackers, It has been suggested that it might be a good idea to teach an ITS course during IAP this year. We have done this twice before with somewhat mixed results. A few sessions were quite memorable, and a few were dogs. Before I decide if I want to front for this again this year, I would like to hear from some other people. Specifically I want to hear: Things people want to learn about. Opinions about what has worked in the past. Volunteers who would enjoy teaching about something. Ways of using this to burn excess machine cycles on our many (!) ITS machines. (Student project ideas?) I don't think I have any of my notes from IAP'83. Do you (Alan) have any from IAP'84? I seemed to remember talking about some of the following: UUOs/.CALL, their skip-on-success feature, their argument passing/returning syntax TTY management Devices, MLDEV:, CLU/I/O/A:, etc Jobs (and BOJs) File system, links, etc. Greenblat's History lecture Moon's hardware description of (the original) AI With the general proliferation of PCs and high level languages, some of the more gutsy things, which are the interesting things, may require a (refresher) course on the assembly language concepts.  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 27 Oct 86 06:51:15 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708249629097960@MIT-MULTICS.ARPA>; 27 Oct 1986 06:33:49 est Date: 26 Oct 86 23:36 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, "Alan Bawden" Subject: For those of you around MIT this January Message-ID: <212189@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].110499.861025.ALAN> We are interseted from Stockholm, two persons, major interest: ITS Internals, what is doing what, and what is speaking to what internaly.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Oct 86 15:47:35 EDT Date: Sat, 25 Oct 1986 15:46 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: For those of you around MIT this January In-reply-to: Msg of 25 Oct 1986 01:38-EDT from Alan Bawden Gee, I haven't taught a short course since I left Wesleyan. Sounds like fun. TECO, theory and practice?  Received: from eneevax.umd.edu by AI.AI.MIT.EDU 25 Oct 86 02:21:54 EDT Received: by eneevax.umd.edu (5.9/4.7) id AA23785; Sat, 25 Oct 86 02:20:02 EDT Date: Sat, 25 Oct 86 02:20:02 EDT From: Douglas Humphrey Message-Id: <8610250620.AA23785@eneevax.umd.edu> To: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Subject: Re: For those of you around MIT this January Let me know when these courses would be and such and count me in. If I'm going to have one, these might be real helpful and certainly a Lot of fun. Doug  Date: Sat, 25 Oct 86 01:38:44 EDT From: Alan Bawden Subject: For those of you around MIT this January To: KS-ITS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].110499.861025.ALAN> Hackers, It has been suggested that it might be a good idea to teach an ITS course during IAP this year. We have done this twice before with somewhat mixed results. A few sessions were quite memorable, and a few were dogs. Before I decide if I want to front for this again this year, I would like to hear from some other people. Specifically I want to hear: Things people want to learn about. Opinions about what has worked in the past. Volunteers who would enjoy teaching about something. Ways of using this to burn excess machine cycles on our many (!) ITS machines. (Student project ideas?)  Date: Thu, 23 Oct 86 01:56:05 EDT From: Ray Hirschfeld Subject: emacs lossage To: ALAN@AI.AI.MIT.EDU cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 22 Oct 86 19:07:28 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].109744.861023.RAY> Date: Wed, 22 Oct 86 19:07:28 EDT From: Alan Bawden To: RAY at AI.AI.MIT.EDU cc: BUG-EMACS at AI.AI.MIT.EDU, BUG-ITS at AI.AI.MIT.EDU Re: emacs lossage ... Well, a quick peek at your directory reveals: AI RAY FREE BLOCKS #0=285 #1=2674 ... 0 TS E 59 +161 ! 10/21/86 11:27:25 (10/22/86) ... A look at this file reveals that it is an SBLK file, so it is unlikely that this is an EMACS that you dumped out for yourself intentionally. (Especially since it appears to be a vanilla EMACS with no libraries loaded.) Perhaps you should delete this file. Thanks, Alan! I never thought to look there. Removing the bogus emacs fixed the problem. I wonder where the hell it came from. Ray  Date: Wed, 22 Oct 86 19:07:28 EDT From: Alan Bawden Subject: emacs lossage To: RAY@AI.AI.MIT.EDU cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 22 Oct 86 18:44:59 EDT from Ray Hirschfeld Message-ID: <[AI.AI.MIT.EDU].109549.861022.ALAN> Date: Wed, 22 Oct 86 18:44:59 EDT From: Ray Hirschfeld Emacs on AI has been dying on me repeatedly over the last few days. It always chokes in the same place, with a message like: .VAL 0; 6767>>MOVEM 6,1377 6/ 177 1377/ 176 A quick peek reveals that this immediately follows a .call corblk, which I guess is failing. Proceeding the job makes it work until the next try. Well, a quick peek at your directory reveals: AI RAY FREE BLOCKS #0=285 #1=2674 ... 0 TS E 59 +161 ! 10/21/86 11:27:25 (10/22/86) ... A look at this file reveals that it is an SBLK file, so it is unlikely that this is an EMACS that you dumped out for yourself intentionally. (Especially since it appears to be a vanilla EMACS with no libraries loaded.) Perhaps you should delete this file.  Date: Wed, 22 Oct 86 18:44:59 EDT From: Ray Hirschfeld Subject: emacs lossage To: BUG-EMACS@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].109535.861022.RAY> Emacs on AI has been dying on me repeatedly over the last few days. It always chokes in the same place, with a message like: .VAL 0; 6767>>MOVEM 6,1377 6/ 177 1377/ 176 A quick peek reveals that this immediately follows a .call corblk, which I guess is failing. Proceeding the job makes it work until the next try.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 SEP 86 20:50:06 EDT Date: Fri 26 Sep 86 20:48:06-EDT From: "John Wroclawski" Subject: Re: dump code fukt To: Moon@SCRC-STONY-BROOK.ARPA, CENT@AI.AI.MIT.EDU cc: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12242133556.4.JTW@MIT-SPEECH> From: David A. Moon Subject: dump code fukt Date: Fri, 26 Sep 86 03:56:39 EDT From: "Pandora B. Berman" .... My first guess is hardware flaking, possibly followed by inadequate resetting action by the software. The code hasn't changed in forever. MT:RETRYING WRITE OPERATION MAG TAPE STATUS TM03 error status decode routine needs to be written ? MTAPE: FORMATTER ERROR, STATUS= 140600,,40000 This is transport unsafe, usually means it went offline while trying to write. MTAPE: FORMATTER ERROR, STATUS=150660,,100320 MAG TAPE STATUS TM03 error status decode routine needs to be written ? This is a mess. To some extent the bits are inconsistant (seems to imply a number of data transfer errors during a positioning command), but could possibly be interpreted as the result of a misformed data transfer command. I assume multi-reel incremental dumps have worked in the past... Is this actually true? -------  Received: from STONY-BROOK.SCRC.Symbolics.COM by AI.AI.MIT.EDU 26 Sep 86 12:55:07 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115737; Fri 26-Sep-86 12:47:14 EDT Date: Fri, 26 Sep 86 12:47 EDT From: David A. Moon Subject: dump code fukt To: Pandora B. Berman , JTW@AI.AI.MIT.EDU cc: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].98958.860926.CENT0> Message-ID: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 26 Sep 86 03:56:39 EDT From: "Pandora B. Berman" when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the end of the reel somewhere in the middle of VAFB;, saying MT:RETRYING WRITE OPERATION MAG TAPE STATUS TM03 error status decode routine needs to be written ? MTAPE: FORMATTER ERROR, STATUS= 140600,,40000 and giving me a DUMP prompt. thinking this might just be a case of terminal dirk, i cleaned the drive and started over again with the same tape. same result. so i tried dumping onto AI 231. this time, i got MTAPE: FORMATTER ERROR, STATUS=150660,,100320 MAG TAPE STATUS TM03 error status decode routine needs to be written ? the job at a prompt, and the tape waiting at EOT. so i rewound it and ICHECK'd it. the ICHECK ended without any strange msgs. maybe the first time was just due to incorrectly placed-EOT mark (it did have one, but i'm not sure which side they're -supposed- to be on), but the second tape worked OK. so something is wrong here.. The MT: and MTAPE: messages (why the inconsistency?) show up in :PEEK ", so they came from the ITS system rather than from DUMP (it can be hard to distinguish when you run DUMP on the system-console). The "error status decode routine needs to be written" message came from DUMP. I guess its routine for explaining the details of tape errors was never converted from the version for the KA/KL tape controller. John, do you know what those octal numbers in the formatter error message mean? I assume multi-reel incremental dumps have worked in the past, so has something in the hardware broken? The tape code in ITS hasn't changed recently, has it?  Date: Fri, 26 Sep 86 03:56:39 EDT From: "Pandora B. Berman" Sender: CENT0@AI.AI.MIT.EDU Subject: dump code fukt To: BUG-DUMP@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].98958.860926.CENT0> when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the end of the reel somewhere in the middle of VAFB;, saying MT:RETRYING WRITE OPERATION MAG TAPE STATUS TM03 error status decode routine needs to be written ? MTAPE: FORMATTER ERROR, STATUS= 140600,,40000 and giving me a DUMP prompt. thinking this might just be a case of terminal dirk, i cleaned the drive and started over again with the same tape. same result. so i tried dumping onto AI 231. this time, i got MTAPE: FORMATTER ERROR, STATUS=150660,,100320 MAG TAPE STATUS TM03 error status decode routine needs to be written ? the job at a prompt, and the tape waiting at EOT. so i rewound it and ICHECK'd it. the ICHECK ended without any strange msgs. maybe the first time was just due to incorrectly placed-EOT mark (it did have one, but i'm not sure which side they're -supposed- to be on), but the second tape worked OK. so something is wrong here.  Date: Fri, 19 Sep 86 15:03:13 EDT From: Ramin Zabih To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].96071.860919.RDZ> AI crashed with "TTY: buffer empty at TYIREM". Dump is in CRASH;TYIREM CRASH  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 SEP 86 21:40:30 EDT Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 SEP 86 21:19:54 EDT Received: from AI.AI.MIT.EDU by ML.AI.MIT.EDU via Chaosnet; 13 SEP 86 21:04:42 EDT Date: Sat, 13 Sep 86 21:08:22 EDT From: Alan Bawden Subject: When you run out of TCP buffers. To: BUG-ITS@ML.AI.MIT.EDU cc: BUG-COMSAT@ML.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].93646.860913.ALAN> There must be a path through the ITS TCP code that fails to free a buffer somehow. Twice I have seen MC run itself completely out of buffers. (See the dump MC:CRASH;CRASH TCPFUL, for an example.) In the most recent example, ITS had been running for 35 days before this happened, which might be relevant, although in the previous case it had only been running for 10 days. Bug-COMSAT: COMSAT behaves weirdly when this happens. Take a look at some of the recent stats files on MC. Like for -every- host it tries to contact with TCP it reports: Bad Greeting="+" or somesuch.  Date: Mon, 8 Sep 86 11:04:04 EDT From: Daniel Huttenlocher To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].92012.860908.DPH> AI bughalted trying to free a packet still in use. Crash dump in PKT USE.  Date: Thu, 4 Sep 86 15:29:10 EDT From: Daniel Huttenlocher To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].90952.860904.DPH> AI got a system revived at 14:38, and seemed to leave all jobs hung or detached (at least ignoring tty input). about 45 mins later it started printing system full messages on the console. dumped to SYS FULL  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 Aug 86 02:00:37 EDT Date: Thu, 21 Aug 1986 02:05 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-ITS@AI.AI.MIT.EDU Subject: .RYEAR and time zones again In-reply-to: Msg of 21 Aug 1986 00:12-EDT from Alan Bawden Making it a new system call is fine. What I'm looking for is a single UUO that will return the information currently returned by .RLPDTM plus time zone information. Doesn't have to be in .RLPDTM format, but should be easy to calculate things like DATIME"TIMGTN from it. For that matter it would be a win if there was a system call that did the DATIME"TIMGTN calculation with maximum hair and all the leap year corrections understood to the human race, once, at system boot time, then just added system uptime to that to get current time. This business of having to recalculate the number of leap years since 1 Jan 1900 every time you want an absolute time value is for the birds.  Date: Thu, 21 Aug 86 00:12:52 EDT From: Alan Bawden Subject: .RYEAR and time zones again To: SRA@XX.LCS.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 20 Aug 1986 16:04 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].86070.860821.ALAN> Why don't we just add another system call to return timezone related information rather than trying to squeeze something into the last few bits of .RYEAR? First, I dislike recycling fields that are documented to be zero (rather than being documented as reserved for future expansion.) Second, given the existence of half-hour and even quarter-hour timezones in parts of the world, five bits isn't really enough. Third, while we are at it, it might be a good idea to try and do something about generalizing the daylight savings time stuff to cover whatever local laws there might be geverning time.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 AUG 86 15:59:50 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 20 Aug 86 15:58:57 EDT Date: Wed, 20 Aug 1986 16:04 EDT Message-ID: From: Rob Austein To: bug-its@MC.LCS.MIT.EDU Subject: .RYEAR and time zones again Sorry, I should have made that a formal propoal, bits and all. Time zones range from +1200 to -1200 (international date line, one day apart from each other). The two possible formats would be: the five low bits of an integer in the range -12. -> +12. or one sign bit (3.5) and four bits of integer range 0 -> +12. Only difference is in how you insert/extract it, of course.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 AUG 86 15:32:21 EDT Date: Wed, 20 Aug 86 15:31:28 EDT From: Rob Austein Subject: .RYEAR and time zones To: BUG-ITS@MC.LCS.MIT.EDU cc: SRA@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].73280.860820.SRA> It would be nice if programs didn't have to have hardwired knowledge of what time zone they are in (yes, I know, all ITS machines are at MIT and thus in time zone -0500, but we're trying to be evangelical, here, right?). Bits 3.5 -> 3.1 of the result from .RYEAR are defined as zero. 24. (maxium time zone plus one) is 30 in octal. Seems a timezone would fit into those bits very nicely. Anybody know of anything that would break if this were done? About the only thing I can think of that this would mess up would be grossitudes like MOVEI AC,@MEM (ignoring the fact that HRRZ AC,MEM works just as well). Does anybody really care what's in those five zeroed bits? (No, nothing of vital importance depends on this, it would just make some code I was writing a little cleaner.)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86 17:50:52 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86 17:49:53 EDT Date: Sun, 17 Aug 86 17:48:54 EDT From: "Devon S. McCullough" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].941512.860817.DEVON> Closer examination of my problem controlling my telnet connection to MX reveals that my logout file on AI is sending telnet IAC DONT TRBIN even though the MX->AI connection is supdup and not telnet. The problem is that the only way I can test for a telnet connection is to look at %TPMTA because the IAC DO TRBIN in the login file turns off the %TPTEL bit! I guess the way to tell if you are telnetting or supduping is to first look at %TPCBS, if it's on you're supdup, if it's off look at %TPMTA and if it's on you're telnet, otherwise it's unknown but for my purposes this case doesn't matter. Maybe the tctyp program should handle this?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86 17:26:26 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86 17:25:27 EDT Date: Sun, 17 Aug 86 17:24:28 EDT From: "Devon S. McCullough" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].941506.860817.DEVON> note that BUG^K prompts "to:" but should prompt "to: bug-" When I log in my init file checks for a telnet connection and does :imgout 377 375 0 which sends a telnet IAC DO TRBIN so that the TAC will pass @ characters instead of intercepting them, and pass the 8th bit so the meta key works from my ann arbor. it looks like nethopping bereaks this somehow, because after nethopping to either AI or OZ the TAC stops passing meta bits and starts to intercept @ characters. --Devon  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 AUG 86 17:00:41 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 AUG 86 16:59:42 EDT Date: Sun, 17 Aug 86 16:58:43 EDT From: "Devon S. McCullough" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].941505.860817.DEVON> I tried nethopping from  Date: Tue, 5 Aug 86 05:10:49 EDT From: "Pandora B. Berman" Subject: TU40 resurrection To: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, file-r@MC.LCS.MIT.EDU cc: DEC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].79588.860805.CENT> lester found another instance of the right drive belt somewhere, and even installed it, so MX's tape drive works again. thanks, lester. this means we can again read and write 800bpi 7track tapes. however, we shouldn't WRITE any, because we can't read them anywhere else. i have run an incremental dump of MX over the net, using Gut's drive (1600 bpi 9track). this causes a few non-fatal errors on the MX end but apparently works (see system log). any future dumps of MX should be done this way; i'll do them, or other interested parties (ty?) can ask how. it's only a little more complicated than dumping to the local drive. all old incremental tapes for MX are hereby retired and should only be used to read off of. i have started a new set of incremental tapes at 375 (so will not overwrite older tape data). all 1600bpi LCS ITS tapes are now on the rack by the dover. i will try to run a full dump soon. we should get on with the project of copying the GFR tapes, and then (if possible) proceed forward into the past, copying full dumps as we go.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86 15:21:24 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86 13:32:07 EDT Date: Tue, 29 Jul 86 11:39:53 EDT From: "Devon S. McCullough" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].936970.860729.DEVON> the door on MX's tape drive seems to be wedged partly open. As far as I know, it is still true that if you use it, the controller will deposit bad parity words into system buffers which will cause MX to bughalt. Anything new on this?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86 15:21:17 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86 13:32:02 EDT Date: Tue, 29 Jul 86 11:10:47 EDT From: "Devon S. McCullough" To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].936964.860729.DEVON> the network stopped talking across the railroad tracks (as usual on rainy days) so I left my plasma TV and walked over to the VT52 by MX's console. Now :TCTYP DESCRIBE says I have Sail,-%TOSAI which looks like a bug to me. It echoes H when I type backspace at DDT, for instance.  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 24 Jul 86 19:18:06 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49456; Thu 24-Jul-86 18:46:43 EDT Date: Thu, 24 Jul 86 18:46 EDT From: David A. Moon Subject: MC To: Alan Bawden cc: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].75103.860724.ALAN> Message-ID: <860724184615.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 24 Jul 86 15:15:31 EDT From: Alan Bawden Date: Thu, 24 Jul 1986 13:53 EDT From: Rob Austein MC seems to have stopped talking to its IMP.... MC's IMP cable was half unplugged at the IMP end. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Who claimed all sockets were in use? I guess some program told you this because both conditions return the same error code. I don't actually understand why unplugging the IMP cable should cause all the buffers to get used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.) Maybe all the packet buffers were full of packets waiting to be sent to the IMP. Maybe a cable fell off ... Very good! I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. But of course Puff launched another one within an hour. By the way, I believe the NET command in LOCK still resets the network, cycling HOST MASTER READY on the IMP cable. That wouldn't have plugged the cable back in in this case of course, but might still have been a useful thing to try. I hope this command works on KS's.  Date: Thu, 24 Jul 86 15:15:31 EDT From: Alan Bawden Subject: MC To: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Thu 24 Jul 1986 13:53 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].75103.860724.ALAN> Date: Thu, 24 Jul 1986 13:53 EDT From: Rob Austein MC seems to have stopped talking to its IMP.... MC's IMP cable was half unplugged at the IMP end. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Who claimed all sockets were in use? I guess some program told you this because both conditions return the same error code. I don't actually understand why unplugging the IMP cable should cause all the buffers to get used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.) Maybe a cable fell off ... Very good! I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. But of course Puff launched another one within an hour.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 24 Jul 86 14:18:57 EDT Date: Thu, 24 Jul 1986 13:53 EDT Message-ID: From: Rob Austein To: bug-its@AI.AI.MIT.EDU, bug-mail@AI.AI.MIT.EDU Subject: MC MC seems to have stopped talking to its IMP. XX isn't having any trouble with this, so it's (probably) not BBN doing something random. Attempting to connect to 10.3.0.44 causes the IMP to claim that MC is down. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Maybe a cable fell off the LH/DH or maybe something else. I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface.  Date: Tue, 15 Jul 86 17:16:43 EDT From: Alan Bawden Subject: TCP Checksum Routine To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70523.860715.ALAN> This afternoon AI crashed because the TCP segment checksuming routine referenced location 400000, which is normally non-existant in the system's page table, thus taking a page fault. The offending instruction was the ILDB at THCKS5. There is a crash dump in CRASH;CRASH TCPSUM, although I may have trashed the accumulators and the BUGxxx locations before taking the dump. I guess we have to suspect that this routine checksums randomness a lot, and we were only lucky to catch it this time because it happened to hit the 2% of system memory that would cause it to halt.  Date: Sun, 13 Jul 86 17:58:41 EDT From: Alan Bawden Subject: Disappear here. To: DANIEL@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sun 13 Jul 86 10:29:11 EDT from Daniel Weise Message-ID: <[AI.AI.MIT.EDU].69293.860713.ALAN> Date: Sun, 13 Jul 86 10:29:11 EDT From: Daniel Weise AI went catatonic this morning. I took a dump to CATA TONIC and reloaded. Thanks. Its just unit #1 being broken again.  Date: Sun, 13 Jul 86 10:29:11 EDT From: Daniel Weise Subject: Disappear here. To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].69227.860713.DANIEL> AI went catatonic this morning. I took a dump to CATA TONIC and reloaded. Daniel  Date: Sat, 12 Jul 86 03:56:36 EDT From: Alan Bawden Subject: DRAGON;SYSMSG LOG To: BUG-ITS@AI.AI.MIT.EDU, MAGIC-DRAGON-KEEPER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].68883.860712.ALAN> The latest PFTHMG DRAGON (installed on the four KS10s, but not the KL) permanently logs memory errors in addition to disk errors. The file DRAGON;DISK LOG is now called DRAGON;SYSMSG LOG.  Date: Thu, 26 Jun 86 19:36:12 EDT From: "Andrew A. Berlin" Subject: ROLM phones. To: BUG-SYS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].62057.860626.AAB> It's getting pretty hard to get a ROLM phone connection to AI these days. Would it be possible to fix it so that AI hangs up the ROLM phone after someone logs out (i.e. when it says "Console Free", it should disconnect the Rolm phone). - Andy  Date: Wed, 25 Jun 86 11:49:20 EDT From: Alan Bawden Subject: Foo To: TAFT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 25 Jun 86 01:11:18 EDT from Jonathan D. Taft Message-ID: <[AI.AI.MIT.EDU].61315.860625.ALAN> Date: Wed, 25 Jun 86 01:11:18 EDT From: Jonathan D. Taft To: KS-ITS-CONFUSION at AI AI was unresponsive but running printing repeatedly on its console: "Warning: No free qsk channels" "System full no job slots." I dumped it to CRASH;FULL FORCED and reloaded. Please send ITS bug reports to Bug-ITS. This is the same disk hung lossage we have been experiencing ever since we got the second drive as far as I can tell. I guess the disk-going-offline code that Moon wrote didn't actually address the correct problem, although I do notice that in this crash dump NQOFFL has been AOSed once for each drive (to bad there is no way to tell -when- this happened). Foo. Seems to have happened again this morning as well. Double foo.  Date: Thu, 19 Jun 86 19:58:28 EDT From: "Pandora B. Berman" Subject: old mail To: DAVIS@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-SYSTEM@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].59198.860619.CENT> Date: Tue 17 Jun 86 15:57-EDT From: Randall Davis Subject: old mail To: bug-system%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU I've been getting old copies of info-space mailing list mailings (from Jan and now Fed) over the past couple of days. It's been happening roughly since the crash when the mail queue was damaged. When is the redundancy likely to end? Is there anything to be done to cut off the useless mail? this has nothing to do with OZ's mail queue, but is instead the result of the retransmission of mail lost on (the old) MC this spring, as announced in a msg to arpanet-bboards a few weeks ago (a copy is available if you missed it). you are fortunate to be on a mailing list which did not absolutely depend on MC as a transmission step and which chose to retransmit immediately, by other paths, those msgs which did not go through the first time. most recipients of this mail are seeing it for the first time; we regret that you are encoutering redundancy. the retransmission process should be completed in about another week.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JUN 86 22:17:43 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUN 86 22:17:51 EDT Date: Sun, 15 Jun 86 22:17:17 EDT From: Daniel Weise To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].927113.860615.DANIEL> When I dial in to MX, upon connecting the 11 says "Connected to MC." Maybe someone should tell it the new name. Daniel  Date: Mon, 9 Jun 86 21:37:04 EDT From: Charles Frankston Subject: [Forwarded: JSLove@MIT-MULTICS.ARPA, Re: Re: info about INQUIR] To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].53941.860609.CBF> Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 15:08:32 EDT Received: from CHARON by MC.LCS.MIT.EDU 9 Jun 86 14:42:48 EDT Received: by CHARON (5.15/4.7) id AA11138; Mon, 9 Jun 86 14:37:59 EDT Received: by ATHENA (5.45/4.7) id AA15558; Mon, 9 Jun 86 14:39:42 EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 9 Jun 86 14:34:06 EDT Date: Mon, 9 Jun 86 14:21 EDT From: "J. Spencer Love" Subject: Re: info about INQUIR To: Jan Popiel Cc: sipb@MC.LCS.MIT.EDU In-Reply-To: Message of 9 Jun 86 13:32 EDT from "Jan Popiel" Message-Id: <860609182112.975425@MIT-MULTICS.ARPA> What I suggested was this: On ITS, there is the database maintained using :INQUIR. This database is not only consulted by :FINGER on ITS and the FINGER protocol on the Internet and CHAOS, but was in the past maintained consistently across 4 ITS sites. This makes it a good example of a distributed database to be used as a phone directory. MIT Information Systems now encompasses MIT telecommunications which produces the MIT directory. Jan's group is now writing a proposal and proposed specification for a system that might eventually enable us to put the MIT Staff and Student directories on line and allow people to update their own entries, and perhaps route electronic mail as well. Perhaps the original implementors of :INQUIR are known to people on this list, or even former SIPB members. Did anyone ever publish a paper on this work, such as an undergraduate thesis? Is the only documentation of the goals and operation of this system in the source code? What is the source code written in and how could it be found? Please direct replies to Popiel@MIT-Multics.ARPA. I will assist him in retrieving files and interpreting jargon. -- Spencer ---------------------------------------------------- What I (CBF) sent was this: Well, you're right, in the past it was maintained consistently across 4 ITS sites; now its maintained across 5 (AI, ML, MC, MD, & MX). Anyway, the mechanisms are fairly simple and CPU intensive. Basically it is done by mailing the updated record to all the other machines. The mailer on each machine spawn subtasks that merge the record into the database by copying the entire database to one with a new name, and then using the ITS rename while open call to atomically instantiate the new one and delete the old one. There is no attempt made to ensure that I don't change my record in rapid succession on two different ITS's. If I were to do that, it is conceivable that entries on the different machines could be inconsistent. In practice it just doesn't happen, or if it did, its trivial for someone to fix it. Note also that having the mailer daemon do the database update (even on the same machine) simplifies a host of issues, since the mailer is a single execution thread on ITS there is no need to worry about concurrent updates. If two man months have been put into this effort over the more than 10 years it has been in service, I would be shocked.  Date: Mon, 9 Jun 86 16:00:16 EDT From: Alan Bawden Subject: AI's losing network To: BUG-ITS@AI.AI.MIT.EDU, CPH@OZ.AI.MIT.EDU In-reply-to: Msg of Mon 9 Jun 1986 14:30 EDT from CPH at OZ.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].53546.860609.ALAN> Date: Mon, 9 Jun 1986 14:30 EDT From: CPH at OZ AI's network seems not to be working. It is possible to connect from a terminal concentrator, but then it echoes characters very, very slowly. The rest of the network is happy, all the bridges are running fine, etc. I tried reaching AI from both MX and OZ, and vice versa, with no luck. JAR and I tried cold-booting in the hope that it might work. Again, a waste of time. I don't know why it didn't occur to anyone that the problem was subnet 6, and has nothing to do with AI, or ITS. It turns out that subnet 6 doesn't work very well if you break it into two pieces by terminating it at the junction box that the KS's are all plugged into.  Date: Mon, 9 Jun 86 15:48:44 EDT From: Alan Bawden Subject: AI's losing network To: BUG-ITS@AI.AI.MIT.EDU, CPH@OZ.AI.MIT.EDU In-reply-to: Msg of Mon 9 Jun 1986 14:30 EDT from CPH at OZ.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].53545.860609.ALAN> Date: Mon, 9 Jun 1986 14:30 EDT From: CPH at OZ AI's network seems not to be working. It is possible to connect from a terminal concentrator, but then it echoes characters very, very slowly. The rest of the network is happy, all the bridges are running fine, etc. I tried reaching AI from both MX and OZ, and vice versa, with no luck. JAR and I tried cold-booting in the hope that it might work. Again, a waste of time. I don't know why it didn't occur to anyone that the problem was subnet 6, and has nothing to do with AI, or ITS. It turns out that subnet 6 doesn't work very well if you break it into two pieces by terminating it at the junction box that the KS's are all plugged into.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 15:22:22 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86 15:18:26 EDT Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 9 JUN 86 14:30:16 EDT Date: Mon, 9 Jun 1986 14:30 EDT Message-ID: From: CPH@OZ.AI.MIT.EDU To: Bug-ITS@MX.LCS.MIT.EDU Subject: AI's losing network AI's network seems not to be working. It is possible to connect from a terminal concentrator, but then it echoes characters very, very slowly. The rest of the network is happy, all the bridges are running fine, etc. I tried reaching AI from both MX and OZ, and vice versa, with no luck. JAR and I tried cold-booting in the hope that it might work. Again, a waste of time.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JUN 86 00:25:33 EDT Date: Sat 7 Jun 86 00:24:49-EDT From: "John Wroclawski" Subject: Re: If you believe in Dovers, clap your hands! To: ALAN@AI.AI.MIT.EDU cc: TY@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-DOVER@AI.AI.MIT.EDU Message-ID: <12212812879.9.JTW@MIT-SPEECH> Date: Sat, 7 Jun 86 00:08:53 EDT From: Alan Bawden Subject: If you believe in Dovers, clap your hands! ..... Unfortunately, I remember how the C compiler works. So at some point I'll probably get around to making a couple of other changes to the spooler (like, we don't really need it to distribute TeX font files anymore) and compiling a new one. In the meantime half of creation has changed their DOVER programs to spool to MX. So we need to leave the spooler on the KL running for a while. -------  Date: Sat, 7 Jun 86 00:08:53 EDT From: Alan Bawden Subject: If you believe in Dovers, clap your hands! To: JTW@AI.AI.MIT.EDU cc: TY@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-DOVER@AI.AI.MIT.EDU In-reply-to: Msg of Fri 6 Jun 86 14:14:31 EDT from Jeffrey J Tyrone Sealy Message-ID: <[AI.AI.MIT.EDU].52858.860607.ALAN> John, I'm just guessing it was you that moved the dover spooler from the KL to the KS? It didn't seem to be working. I theorized that this had to do with the fact that it had the device PK1: built into the source in many places, so I launched another spooler with a translation from PK1: to DSK: which now seems to be working. I fixed the sources to use PK0: instead of PK1:, which should work on any ITS machine for the forseeable future. I couldn't assemble the sources because (assuming I know how to run the C compiler, which I don't) there are all kinds of C libraries that have been migrated to KL GFR tapes. Anyone who cares about dover spooling is free to finish what John and I have started I guess. Step one is to get back the C libraries I guess... I've always been in favor of kicking the dover out the window, so I'm certainly in no rush to do this myself. While I was at it, I fixed the various job devices so that DVR^F would know to contact the KS now, instead of the KL. I did -not- install a MC:CHANNA;RAKASH DVRSPL on the KS, because any newly launched demon still needs that translation to function. Until someone assembles (and links, how unaesthetic for an ITS!) the new sources, the demon can be launched by hand by running the xfile .DOVR.;.SPOOL XFILE1 on the KS. (Hackers who might bring the MC KS up, take note!)  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 13:41:53 EDT Date: Wed, 4 Jun 86 13:41:52 EDT From: Chris Hanson Subject: DOVER Lossage To: BUG-SYSTEM@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].924307.860604.CPH> I know this isn't really the right place, but BUG-DOVER looks like a dead list to me... Will someone please fix :DOVER so that it knows how to spool? Obviously there IS a spooler, since DVR^F works fine -- except that :DOVER doesn't seem to know how to talk to it.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUN 86 19:53:34 EDT Date: Mon, 2 Jun 86 19:53:24 EDT From: "Michael A. Patton" Subject: Actually the MX front end 11 I believe. To: BUG-ITS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].923914.860602.MAP> When you call up the MX (formerly MC) dialup it gives you the message: Connected to MC. just before you get the MX banner from PWORD. This should probably be fixed.  Date: Sun, 1 Jun 86 15:00:20 EDT From: "David A. Moon" Subject: Warning to ITS hackers To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49646.860601.MOON> If you assemble the current source it won't run unless you use the new microcode I'm debugging. I think it will run if you patch OVHCLK/ POPJ P, which will keep it from executing the instructions that aren't implemented. OIPBIT is non-zero now, but it should still be a no-op with the released microcode. It's unlikely that I will finish this before next week, since I will be out of town.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86 20:20:11 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 31 May 86 20:19:58 EDT Date: Sat, 31 May 1986 20:18 EDT Message-ID: From: Rob Austein To: macrakis%endor@HARVARD.HARVARD.EDU (Stavros Macrakis) Cc: bug-sys@MC.LCS.MIT.EDU, dudek@HARVARD.HARVARD.EDU Subject: mit-mx In-reply-to: Msg of 31 May 1986 18:53-EDT from macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis) Date: Saturday, 31 May 1986 18:53-EDT From: macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis) To: dudek cc: bug-sys@mit-mc.arpa Re: mit-mx tn etc. don't seem to know about `mx' == mx.lcs.mit.edu What machine are you running telnet on? MX.LCS.MIT.EDU is in the domain database. If your machine can't find it, that's not our fault. I wouldn't expect just "mx" to work, unless you are on a machine in the LCS.MIT.EDU domain. Welcome to the future.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86 18:55:59 EDT Received: from harvard.HARVARD.EDU by MC.LCS.MIT.EDU 31 May 86 18:55:41 EDT Received: from endor.HARVARD.EDU (endor) by harvard.HARVARD.EDU; Sat, 31 May 86 18:53:35 EDT Date: Sat, 31 May 86 18:53:26 EDT Received: by endor.HARVARD.EDU; Fri, 30 May 86 19:19:33 EDT From: macrakis%endor@harvard.HARVARD.EDU (Stavros Macrakis) To: dudek Subject: mit-mx Cc: bug-sys@mit-mc.arpa tn etc. don't seem to know about `mx' == mx.lcs.mit.edu  Date: Sat, 31 May 86 04:13:37 EDT From: "Pandora B. Berman" Subject: MC TCP loss To: BUG-ITS@AI.AI.MIT.EDU, BUG-TCP@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49182.860531.CENT> while on MC and trying to finger out at other hosts, i kept getting an "all sockets in use" msg. alan poked around and said the system was out of TCP buffers and COMSAT was acting strangely, so i should raise switch 0 and take a crash dump. CRASH;TCP LOSS.  Date: Sat, 31 May 86 03:23:01 EDT From: "Pandora B. Berman" Subject: mailing lists redux To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49152.860531.CENT> Date: Wed, 28 May 86 17:01:04 EDT From: Alan Bawden Subject: KS-ITS mailing list To: GUMBY@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU Date: Wed, 28 May 86 04:47:53 EDT From: David Vinayak Wallace Can't we fold this into INFO-ITS? INFO-ITS is an extremely low-volume mailing list. It is for spreading information that ordinary ITS users and programmers might want to know. Like when a new device is installed (like LP7:), or a new Midas library is written, or a new machine is installed, or a new system call is installed or improved. KS-ITS is for people who are interested in the project of getting 2020s installed at MIT running ITS. When I got the KS10 microcode to do ITS-style paging, I sent mail to KS-ITS. The people on INFO-ITS I didn't bother until they could log in. A lot of mail that has gone to KS-ITS in the last few months should have been sent to BUG-ITS. Like if AI crashes in some novel way, people send mail to KS-ITS "because AI is a KS", even though BUG-ITS is the proper recipient. The people on KS-ITS were interested in keeping in touch with a "good hack", which is distinct from both BUG-ITS and INFO-ITS. gumby, the next time you ask 4 people's opinion about making the sort of major change you suggested, why not wait until more than 1 replies before deciding what to do? i have just spent 2 hours undoing the confusion you created by going ahead with this merger after only one response. among other things, you completely omitted the BUG-ITS archive. fortunately i discovered a BUG-ITS list member who hasn't logged in for the past few days, and so was able to recover the lost msgs. i have also unmerged the INFO-ITS and KS-ITS archives. also, it's considered courteous, when you insist on rashly forging ahead in this fashion, to inform -all- the list members involved; you only told those people on KS-ITS who were not on INFO-ITS: Date: Wed, 28 May 86 05:49:01 EDT From: David Vinayak Wallace Subject: KS-ITS mailing list To: KS-ITS-ONLY-PEOPLE@AI.AI.MIT.EDU The KS's have arrived and ITS runs on them, so we're folding the KS-ITS list into INFO-ITS. You're not on INFO-ITS nor BUG-ITS. Unless I hear from you in the next few days I'll put you on INFO-ITS. david i agree with alan -- the INFO-, BUG-, and KS-ITS have distinct purposes and should be kept that way. now that the KSs run ITS, a lot of the discussion previously carried on on KS-ITS should move to BUG-ITS or other more appropriate lists, but that's another story.  Date: Wed, 28 May 86 17:21:32 EDT From: Alan Bawden To: ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 28 May 86 11:39:49 EDT from David Chapman Message-ID: <[AI.AI.MIT.EDU].47458.860528.ALAN> Date: Wed, 28 May 86 11:39:49 EDT From: David Chapman Is there a reason ML is running ITS when everyone else is running NITS? Heck, you should have looked yesterday! AI was running NITS, MC was running XITS, MD was running ITS... The various names have no relation to eachother. When MD came up, it deleted .temp.; because it was empty. Does anything depend on that dir existing? Just in case, i recreated it. Many things want there to be a .TEMP. directory. However .TEMP. is on a (very) short list of directories that are automatically created whenever anyone tries to use them, so you needn't have gone to the trouble. In fact, you could have created it simply by typing .TEMP.^F!  Date: Wed, 28 May 86 16:48:18 EDT From: Alan Bawden Subject: ML up... To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 28 May 86 04:12:21 EDT from David Vinayak Wallace Message-ID: <[AI.AI.MIT.EDU].47443.860528.ALAN> Date: Wed, 28 May 86 04:12:21 EDT From: David Vinayak Wallace I brough ML up, and copied over LSR1, everything on SYS: created since the 15th, and .;@ NITS (which I then booted on ML). We should have a better way of doing this. Aiiiiiiieeee!!!!! Date: Wed, 28 May 86 04:15:43 EDT From: David Vinayak Wallace I lost moving @ NITS to ML:.;. So ML's running ITS until someone competent wishes to do it. Since each machine has different devices, addresses, terminals, names, etc. The various ITS binaries are -totally- incompatible. I shudder to think what made you realize that you had lost...  Date: Wed, 28 May 86 11:39:49 EDT From: David Chapman To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47247.860528.ZVONA> Is there a reason ML is running ITS when everyone else is running NITS? When MD came up, it deleted .temp.; because it was empty. Does anything depend on that dir existing? Just in case, i recreated it.  Date: Wed, 28 May 86 08:25:34 EDT From: "Pandora B. Berman" Subject: Our Man Lester To: BUG-ITS@AI.AI.MIT.EDU cc: LAUREL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47197.860528.CENT> appeared this morning after a significant absence. i asked him about PM on AI and he said not next Tues. he has a meeting, so maybe Mon., or maybe even Fri. i mentioned that AI's disk filters needed changing, and he agreed. he promised he'd send laurel and alan mail giving the exact day.  Date: Wed, 28 May 86 06:52:36 EDT From: "Pandora B. Berman" Subject: it's probably not a good idea to GFR bug files To: "GUMBY@"@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47156.860528.CENT> Date: Wed, 28 May 86 06:37:38 EDT From: David Vinayak Wallace Subject: it's probably not a good idea to GFR bug files: To: CENT@AI.AI.MIT.EDU Date: Wed, 28 May 86 06:26:48 EDT From: Pandora B. Berman Date: Tue, 27 May 86 07:20:15 EDT From: David Vinayak Wallace FAILED: (FILE [LSPMAI;COMPLR BUGS]) at AI.AI.MIT.EDU; Couldn't write message to file; "DSK:LSPMAI;COMPLR BUGS" - LINK TO NON-EXISTENT FILE ... look again. the link is to an MX GFR tape. the file was gfr'd, by JPG or GSB, quite some time ago. are you requesting that it be retrieved or something? Yes, I think it should be. well, you're quite capable of hacking ITS tapes. if you don't, i'll get around to it sometime. Also, LSPMAI should be immune to GFR, talk Alan or whoever into adding it to the magic list... or at least, should be protected from having most-current bug files deleted. i don't think ITS can do this.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 04:16:36 EDT Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86 04:16:18 EDT Date: Wed, 28 May 86 04:15:43 EDT From: David Vinayak Wallace Subject: belay that To: BUG-its@AI.AI.MIT.EDU Message-ID: <[ML.AI.MIT.EDU].65.860528.GUMBY> I lost moving @ NITS to ML:.;. So ML's running ITS until someone competent wishes to do it.  Date: Wed, 28 May 86 04:12:21 EDT From: David Vinayak Wallace Sender: GUMBY0@AI.AI.MIT.EDU Subject: ML up... To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47096.860528.GUMBY0> I brough ML up, and copied over LSR1, everything on SYS: created since the 15th, and .;@ NITS (which I then booted on ML). We should have a better way of doing this.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 02:24:13 EDT Date: Wed, 28 May 86 02:23:09 EDT From: David Vinayak Wallace Subject: ARPA contact name To: JINX@OZ.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, Bug-OZ@OZ.AI.MIT.EDU In-reply-to: Msg of 27 May 1986 21:46 EDT (Tue) from Bill Rozas Message-ID: <[MX.LCS.MIT.EDU].922144.860528.GUMBY> Date: 27 May 1986 21:46 EDT (Tue) From: Bill Rozas Shouldn't something which is more likely to stick around be used instead? Using MX is hardly worth the effort, given its expected lifetime. There has been more mail on this subject than it warrants. 1> Fix it to use the KL while it runs; patch it later. 2> Fix the chaos-only hosts (of which there aren't really too many left) to understand IP.  Date: Tue, 27 May 86 22:51:56 EDT From: "Pandora B. Berman" Subject: ks lossage messages To: GUMBY@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].46889.860527.CENT> Date: Mon, 26 May 86 02:02 EDT From: David Vinayak Wallace Subject: ks lossage messages To: David Chapman cc: poor-ai@AI.AI.MIT.EDU Date: Mon, 19 May 86 11:12:12 EDT From: David Chapman Do we need a poor-ks? At 6 this morning, MX started complaining often about being out of jobslots on the console. Messages like this used to go to BUG-ITS. I figure they should anyway (and the poor- lists should be flushed, except for the special case of the KL). i have flushed the POOR-AI list and folded the four msgs it had accumulated in its archive file into the BUG-ITS archive.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 21:46:43 EDT Date: 27 May 1986 21:46 EDT (Tue) Message-ID: From: Bill Rozas To: Alan Bawden Cc: BUG-ITS@AI.AI.MIT.EDU, Bug-OZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, Cole%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, FTD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, GLR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: [COLE: Telnet-ing through MC to live hosts...] In-reply-to: Msg of 27 May 1986 16:11-EDT from Alan Bawden Why don't you just fix TELNET on OZ to use MX as a gateway? Shouldn't something which is more likely to stick around be used instead? Using MX is hardly worth the effort, given its expected lifetime.  Date: Tue, 27 May 86 16:11:20 EDT From: Alan Bawden Subject: [COLE: Telnet-ing through MC to live hosts...] To: GLR@OZ.AI.MIT.EDU, Cole@OZ.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, FTD@OZ.AI.MIT.EDU, Bug-OZ@OZ.AI.MIT.EDU In-reply-to: Msg of Tue 27 May 1986 15:13 EDT from Jerry Roylance Message-ID: <[AI.AI.MIT.EDU].46638.860527.ALAN> Date: Tue, 27 May 1986 15:13 EDT From: Jerry Roylance Date: Sunday, 25 May 1986 22:48-EDT From: COLE at OZ To: David D. Story cc: bug-oz at OZ MC is rejecting OZ's request to telnet to arpanet hosts. But I was able to telnet from oz by typing: telnet TELNET> host-name telnet tcp mx I don't know what host computer OZ is now supposed to be using for its telnet connections. Somebody seems to have decided that the MC KS will not supply TCP gateway service. I personally think this is silly. I would not object if someone else wants to take the heat for putting it back. Why don't you just fix TELNET on OZ to use MX as a gateway?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 15:15:57 EDT Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86 15:15:25 EDT Date: Tue, 27 May 1986 15:13 EDT Message-ID: From: Jerry Roylance To: Bug-ITS@MC.LCS.MIT.EDU Subject: [COLE: Telnet-ing through MC to live hosts...] Date: Sunday, 25 May 1986 22:48-EDT From: COLE at OZ.AI.MIT.EDU To: David D. Story cc: bug-oz at OZ.AI.MIT.EDU Re: Telnet-ing through MC to live hosts... MC is rejecting OZ's request to telnet to arpanet hosts. But I was able to telnet from oz by typing: telnet TELNET> host-name telnet tcp mx I don't know what host computer OZ is now supposed to be using for its telnet connections.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 14:31:38 EDT Date: Tue, 27 May 86 14:30:45 EDT From: Chris Hanson Subject: Just nitpicking... To: BUG-ITS@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].921807.860527.CPH> MX still says "Connected to MC." when you dial it up. I guess there is no single variable controlling the machine name.  Received: from MOSCOW-CENTRE.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 MAY 86 02:02:40 EDT Date: Mon, 26 May 86 02:02 EDT From: David Vinayak Wallace Subject: ks lossage messages To: David Chapman cc: poor-ai@AI.AI.MIT.EDU In-Reply-To: <[MX.LCS.MIT.EDU].587.860519.ZVONA> Message-ID: <860526020227.5.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU> Date: Mon, 19 May 86 11:12:12 EDT From: David Chapman Do we need a poor-ks? At 6 this morning, MX started complaining often about being out of jobslots on the console. Messages like this used to go to BUG-ITS. I figure they should anyway (and the poor- lists should be flushed, except for the special case of the KL).  Date: Thu, 22 May 86 01:20:17 EDT From: Alan Bawden Subject: Someday when things calm down we might have time to look into things like this again To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44418.860522.ALAN> Outputting to a BOJ: channel after the device user no longer has his JOB: channel open seems to simply hang. (In the case I'm seeing it is SIOT to a channel open in .UAO mode.) I would have expected this to signal an error, perhaps %ENAPP?  Date: Wed, 21 May 86 23:55:16 EDT From: "Pandora B. Berman" Subject: logbook location To: SRA@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44369.860521.CENT> Date: Wed, 21 May 1986 23:18 EDT From: Rob Austein To: "Pandora B. Berman" Cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Subject: At the tone, your name will be It would probably help if the ML and MD system logs were in some intuitively obvious place. Now that you have reminded me of their existance I suspect they are sitting on top of the CPUs or disks or something. If they were sitting by the consoles some of us space cadets might have remembered their existance and scrawled something in them. if i could have put them safely any closer to the consoles, i would have. i agree that on top of the CPUs is not the best location for visibility and memory-jogging, but it appeared to be the best i could do. if we could get some kind of little table beside MD's console (shoving the IMPLOD cabinet over), that would be better.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 23:17:32 EDT Date: Wed, 21 May 1986 23:18 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Subject: At the tone, your name will be In-reply-to: Msg of 21 May 1986 22:57-EDT from "Pandora B. Berman" It would probably help if the ML and MD system logs were in some intuitively obvious place. Now that you have reminded me of their existance I suspect they are sitting on top of the CPUs or disks or something. If they were sitting by the consoles some of us space cadets might have remembered their existance and scrawled something in them.  Date: Wed, 21 May 86 22:57:57 EDT From: "Pandora B. Berman" Subject: At the tone, your name will be To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44335.860521.CENT> I have relabelled everything in sight except the KS's tapes; i'll get to those later this evening. i rediscovered the winning sort of labels, so the binder labels should no longer be quite so eager to come off. NOTHING has been written in the ML and MD system logs for at least a week. nothing about bringing them down for DEC to borrow or loaning disks to XX or any such matters. will someone who knows what's been going on (SRA? JTW?) please insert a few notes so the rest of us can remain mildly informed?  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 03:17:42 EDT Date: Wed 21 May 86 03:19:00-EDT From: "John Wroclawski" Subject: Re: ks lossage To: JNC@XX.LCS.MIT.EDU, ALAN@AI.AI.MIT.EDU, ZVONA%MX.LCS.MIT.EDU@XX.LCS.MIT.EDU cc: bug-its@AI.AI.MIT.EDU In-Reply-To: <12208384120.19.JNC@XX.LCS.MIT.EDU> Message-ID: <12208388143.21.JTW@MIT-SPEECH> From: "J. Noel Chiappa" Subject: Re: ks lossage I think the funny messages from the IMP have to do with some The RFC that describes 1822L tells all, claiming that the IMP will send the usual 3-NOP-and-a-reset sequence twice, once in 1822 format and once in 1822L format, interleaving the messages. You are supposed to tell it what you want by answering in your choice of format. If you do this before it has sent the full sequence it will stop sending in the protocol you don't want. Which is all well and good, except that this RFC is dated in 1983. So it only took them three years to implement...? -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 02:56:08 EDT Date: Wed 21 May 86 02:56:55-EDT From: "J. Noel Chiappa" Subject: Re: ks lossage To: ALAN@AI.AI.MIT.EDU, ZVONA@MX.LCS.MIT.EDU cc: POOR-AI@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].42635.860519.ALAN> Message-ID: <12208384120.19.JNC@XX.LCS.MIT.EDU> I think the funny messages from the IMP have to do with some new leader format that BBN is introducing. They flag the new style ones with what looks to old unmodified software with an illegal initial code. We've just run acrosss this bringing up the 68000 GW IMP code. -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 May 86 02:38:44 EDT Date: Wed 21 May 86 02:39:30-EDT From: "J. Noel Chiappa" Subject: Re: flaky ML To: ALAN@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].42474.860518.ALAN> Message-ID: <12208380952.19.JNC@XX.LCS.MIT.EDU> Maybe it's not an accident that the 3 machines had bum memory boards in them? -------  Date: Wed, 21 May 86 00:35:26 EDT From: Alan Bawden Subject: 6 5 4 3 2 1 ... To: BUG-ITS@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU, "(FILE [JNC:POOR MC])"@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].43668.860521.ALAN> OK folks, I switched the names MC and MX in the ITS sources and created new binaries for the two machines. I also edited AI:SYSHST;HSTLCS to reflect the swap. So the first symptom of this name swap that anyone will notice will appear early this morning when new host tables start circulating with the Chaosnet addresses switched. (Because we are switching both ArpaNet addresses and physical connections, the change manifests itself in the host tables as exchanged Chaosnet addresses.)  Date: Tue, 20 May 86 14:26:00 EDT From: "Leigh L. Klotz" To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].43062.860520.KLOTZ> Just now I typed P H to get a histogram, and it started up a job called HP, which said File can't be OPENed - DSK:FORT;HP SAV ^V VALRETS OR XFILES NESTED TOO DEEP?INPDL OVERFLOW - PDL RESET? but I guess that's another story. The fair share is 74%, btw.  Date: Tue, 20 May 86 04:39:07 EDT From: "Pandora B. Berman" Subject: AI's first GFR To: BUG-DUMP@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42900.860520.CENT> sort of like its first date, or something -- it's just not the same thereafter. anyway, the GFR did run over AI SECOND:, taking 5K blocks off to tape. Due to cruftiness not yet worked around in the code (something to do with EOT), we can't yet run incremental GFRs -- successive small GFRs onto the same tape. so i had to go for maximum usage of single tape instead. given the amount of tape left, i think i could have gone for 6K blocks and won; that we'll try next time. the tape is in the rack with the other ITS tapes. as usual, this is a Sacred GFR Tape -- be careful with it. All and Sundry are reminded that all 4 KSs (when they're running ITS) are regularly backed up -- help relieve AI's load by moving your files elsewhere.  Date: Mon, 19 May 86 14:11:13 EDT From: Alan Bawden Subject: ks lossage To: ZVONA@MX.LCS.MIT.EDU cc: POOR-AI@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Mon 19 May 86 11:12:12 EDT from David Chapman Message-ID: <[AI.AI.MIT.EDU].42635.860519.ALAN> Date: Mon, 19 May 86 11:12:12 EDT From: David Chapman ... When the machine booted it printed a lot of stuff I couldn't follow about the imp. All ITS machines with IMPs do this when you boot them now. I presume the software in the IMP has changed incompatibly somehow. We all have to learn to ignore this until somebody gets around to fixing it. 'Nother funny thing: LAST time it was booted, it complained that it couldn't set the time, because 15 out of the 13 times it got from the net did not agree. Besides sounding damn funny, it seems that requiring 15 good times is a little stringent. Well, its just phrased a little funny. It -asked- 25 people, and it insists on getting 15 answers that agree back. If only 13 people respond, then indeed 15 of the 13 answers failed to agree! I don't want to insist on a majority of the -responders-, since then if only 1 machine responds that happens to be mistaken, the mistake spreads. Look at it this way, this demon is just a convenience to save you from having to run PDSET 95% of the time, you have to expect to do it manually every now and then.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 MAY 86 11:10:47 EDT Date: Mon, 19 May 86 11:12:12 EDT From: David Chapman Subject: ks lossage To: poor-ai@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].587.860519.ZVONA> Do we need a poor-ks? At 6 this morning, MX started complaining often about being out of jobslots on the console. About 10, I couldn't supdup in, so I came up. I couldn't log into the console either -- it ignored ^Z. So I hit boot, and it said BT SW and ?BT 001200 and wouldn't listen to me. So I got the fep and started at 777700 and that didn't work either, so I booted again and it worked that time. My guess is that comsat is unhappy about its imp connection and dying without freeing up its slot. When the machine booted it printed a lot of stuff I couldn't follow about the imp. 'Nother funny thing: LAST time it was booted, it complained that it couldn't set the time, because 15 out of the 13 times it got from the net did not agree. Besides sounding damn funny, it seems that requiring 15 good times is a little stringent.  Date: Sun, 18 May 86 21:39:55 EDT From: Alan Bawden Subject: flaky ML To: CENT@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sat 17 May 86 07:26:57 EDT from Pandora B. Berman Message-ID: <[AI.AI.MIT.EDU].42474.860518.ALAN> Date: Sat, 17 May 86 07:26:57 EDT From: Pandora B. Berman ML was getting a gross and astonishing number of ECC errors this morning. We are talking -memory- EEC corrected errors rather than -disk- ECC corrected errors I believe. see console output around 3-4 am. what does this? what can we do about it? It means that there are some bad bits in ML's memory. Its funny, AI has never had a single one of these errors, but all -three- of the new KS10's have memory boards in them that get ECC errors. i was dumping it and shoving some files on during this time -- maybe this has something to do with the flaky chaosnet? Unlikely to be related other than the fact that you were just exercising the machine in general. The real problem here is that when I wrote the code for logging the ECC errors, I didn't fully understand what it would be like when they started happening regularly. (My code also has a bug that causes MD to essentially loop in the scheduler because of a bad bit in a particularly sensitive location.) I plan to re-write this code to be less noisy and more robust soon.  Date: Sat, 17 May 86 07:30:43 EDT From: "Pandora B. Berman" Subject: dumped state To: INFO-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42220.860517.CENT> as of this morning, all ITSs here (with the possible exception of the KL) are being regularly backed up to tape. it -is- safe to store your files on any of the KSs.  Date: Sat, 17 May 86 07:26:57 EDT From: "Pandora B. Berman" Subject: flaky ML To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42218.860517.CENT> ML was getting a gross and astonishing number of ECC errors this morning. see console output around 3-4 am. what does this? what can we do about it? i was dumping it and shoving some files on during this time -- maybe this has something to do with the flaky chaosnet?  Date: Mon, 12 May 86 03:47:03 EDT From: "Pandora B. Berman" Subject: another way to confuse the issue To: MBECK@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37601.860512.CENT> Date: Sat, 10 May 86 01:11:28 EDT From: "Mark E. Becker" Subject: MC <--> KS/MX mail switching To: CENT@MC.LCS.MIT.EDU After reading MC MAIL would it be a 'good thing' if I sent address update messages to those list maintainers saying that MBECK@MC should now be MBECK@KL ? no. KL is a local-only nickname; on the general arpanet it's an alias for SRI-KL, and sending your mail there would not help anyone. when the KS (currently MX) and the KL (currently MC) switch names, they will retain their model aliases -- the KL will be called MX or (locally) KL, while the KS will be called MC or KS. this feature was arranged so we could do a number of local transforms. for instance, the KS will have somewhat restricted use, so it can concentrate on mail; thus, among other things, we don't want all those people who get mail on the present MC to have that mail land on the KS after the name switch. for this reason, someone has run a program over the inquir database to change all net-addresses of MC to KL; this will ensure that their mail will end up on the same physical machine as it does now. all ITS machines share a common inquir database and forward mail in accordance with the net-addresses people give therein, so all your mail will end up where you currently get it now. since your mail goes to OZ, it will continue to make one hop from MC (whichever hardware) to the twenex; if you received it on MC-KL, you would find it would begin taking an extra hop to reach your mailbox, because the KL will (probably) go off the arpanet when the names are switched and all mail bound for it will have to be forwarded through MC-KS or AI.  Date: Sun, 11 May 86 21:28:30 EDT From: Alan Bawden Subject: Ask, and you shall recieve To: SRA@XX.LCS.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU cc: BUG-INQUIR@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU, ZVONA@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 11 May 1986 04:59 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].37394.860511.ALAN> Date: Sun, 11 May 1986 04:59 EDT From: Rob Austein ... (although it would be nice if it had some reasonable way to deduce what ITSs exist, at run-time). Because I was updating so many programs to know about the new plethora of ITS machines, I added exactly this feature. There is a new table you can ask for from the .GETSYS uuo: ITSNMS is a table of the sixbit names of the -current- local ITS machines. I have already converted most of the programs that used to have built-in tables of ITS machines (INSTAL, FINGER, FIND, etc.) to use this. Do :UUO GETSYS for details.  Date: Sat, 10 May 86 18:26:28 EDT From: Alan Bawden To: BUG-ITS@AI.AI.MIT.EDU cc: JSOL@AI.AI.MIT.EDU In-reply-to: Msg of Sat 10 May 86 16:56:50 EDT from Jon Solomon Message-ID: <[AI.AI.MIT.EDU].37156.860510.ALAN> Date: Sat, 10 May 86 16:56:50 EDT From: Jon Solomon for some reason I keep geting "all sockets in use" when there is nobody on the system. I did a :p a, and abuot 2/3rds of the connections are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe way to flush them? I reloaded the system to get rid of them since nobody could connect to MC using TCP. I left a crash dump in MC:CRASH;CRASH TIMWTS if some networking wizard wants to figure out what YALE.ARPA and SRI-UNIX.ARPA are doing that cause these connections to stay in TIMWT seemingly forever.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 MAY 86 16:57:36 EDT Date: Sat, 10 May 86 16:56:50 EDT From: Jon Solomon To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].909418.860510.JSOL> for some reason I keep geting "all sockets in use" when there is nobody on the system. I did a :p a, and abuot 2/3rds of the connections are in TIMWT connected to YALE.ARPA or SRI-UNIX.ARPA. Is there some safe way to flush them?  Date: Fri, 9 May 86 23:43:36 EDT From: Alan Bawden Subject: another mysterious lossage To: CENT@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Fri 9 May 86 22:38:16 EDT from Pandora B. Berman Message-ID: <[AI.AI.MIT.EDU].37001.860509.ALAN> Date: Fri, 9 May 86 22:38:16 EDT From: Pandora B. Berman around 22:15 or so, AI stopped listening.... dumped it to CRASH;ITS HUNG, then reloaded. Looks like the same disk lossage again. This time ITS had actually run out of disk clannels. Perhaps there is something wrong with one of the drives. I'll try to figure this out after I get finished with this paper. (I don't grok the disk code well enough to do this immediately.) I hope AI continues to work for that long... I renamed the crash to be AI:CRASH;CRASH QLOSS" BTW, penny, I figured out why MX's system console wouldn't talk to you. The 8080 front end sometimes gets confused about the state of the system console and stops forwarding characters through to the 10 (running out of paper sometimes causes this to happen). If you simply power-cycle the LA120 this resets the 8080's opinion of things and you can use the system console for input again.  Date: Fri, 9 May 86 22:38:16 EDT From: "Pandora B. Berman" Subject: another mysterious lossage To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36993.860509.CENT> around 22:15 or so, AI stopped listening. it was willing to echo typein but would not act on it. also it echoed chaos packets, or heard them, or something low-level like that. DPH and i figured out how to raise switch0 and dumped it to CRASH;ITS HUNG, then reloaded.  Date: Thu, 8 May 86 22:24:56 EDT From: Alan Bawden Subject: Recent software crashes. To: BUG-ITS@AI.AI.MIT.EDU cc: SRA@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36473.860508.ALAN> Two recent crashes (in MC:CRASH;CRASH DRGFKT and AI:CRASH;CRASH BJUIS) suggest that there is some problem with job device locking strategy. I guess we should have expected that having COMSAT using a job device 24 hours a day would expose some bugs. The crash on MC is completely crazed in the number of jobs that are confused. AI just crashed again with the same lossage I complained about a couple weeks ago. The one where the system hangs up just like it does on MC when the T-300 controller gets fucked. (See AI:CRASH;CRASH QLOSS and AI:CRASH;CRASH QLOSS'.)  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 8 May 86 07:46:48 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2693388755368144@MIT-MULTICS.ARPA>; 08 May 1986 07:32:35 edt Date: 08 May 86 00:44 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: ITS_bugs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU, "Alan Bawden" Subject: State of the world Message-ID: <172046@QZCOM> In-Reply-To: <[AI.AI.MIT.EDU].35019.860506.ALAN> We are looking forward, to the moment when we can load the tape in the tape drive and have the system flying.  Date: Tue, 6 May 86 00:40:15 EDT From: Alan Bawden Subject: State of the world To: KS-ITS@AI.AI.MIT.EDU, INFO-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].35019.860506.ALAN> There are now -five- machines running ITS at MIT, more than have ever existed simultaneously before. There is the MC KL10, and four KS10's named AI, MX, ML, and MD. The MC KL10 is off maintenance contract as of the first of this month, so I suppose its days are numbered. At some point before the KL10 passes on to that great machine room in the sky, the MC KL10 and the MX KS10 will swap their names, and we will plug the new MC KS10 into the old MC's Arpanet port. This assures that as far as the outside world is concerned, there will always be an ITS named MC at that Arpanet address, performing mail service functions for MIT. (Let's not get into the hair we will be going through to make all the mailing lists in the world continue to work.) The KL10 will remain available for all those who wish to continue to use it, under the name MX. When the KL10 retires, the name MX will be retired with it. Various other owners of KS10's around the world will be receiving KS10 ITS distribution tapes in the mail soon. The last machine we booted (MD) was built by a volunteer using the printed instructions we plan to include with our ITS distribution kits.  Date: Thu, 1 May 86 05:28:04 EDT From: "Pandora B. Berman" Subject: imp lossage To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33406.860501.CENT> AI crashed around 3 or so. complained about IMP lossage of some sort. dumped to CRASH;IMPOS LOSS.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 15:05:01 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 15:04:56 EDT Date: Wed, 30 Apr 86 15:04:37 EDT From: Alan Bawden Subject: tty types To: PGS@AI.AI.MIT.EDU cc: KLOTZ@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-SUPDUP@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 30 Apr 86 02:43:20 EDT from Patrick G. Sobalvarro Message-ID: <[AI.AI.MIT.EDU].33061.860430.ALAN> Date: Wed, 30 Apr 86 02:43:20 EDT From: Patrick G. Sobalvarro Date: Tue, 29 Apr 86 08:31:04 EDT From: Alan Bawden (Note that until recently ROLM lines incorrectly had the %TYDIL bit set in their TTYTYP words, perhaps you are noticing an effect of this change.) I thought %TYDIL was correct for the ROLM lines, since they are exactly analogous to dialups; one connects terminals of different types to them, so they should have their tty types reset to something neutral when disconnected, etc. And, if we supported it in the 11, they should hang up after they've been logged out for a while, all those dialup-y things. I should have been more careful about how I used the word "incorrectly". As you set things up originally the ROLM lines were just like dialups and had %TYDIL set for all of the reasons you give. This all worked just fine and there wasn't a thing wrong with it. Then I got my greasy fingers into the act. I added a %TYRLM bit for the benefit of people and programs that wanted the distinguish between ordinary dialups that you tended to connect to from outside NE43 (like from home), and ROLM lines that you tended to connect to from inside NE43 (like from your office). In this state of affairs ITS tested %TYDIL to determine if it should do all those dialup-y things, and programs that wanted to know if you were at home could test to see if %TYDIL was set and %TYRLM wasn't. The problem is that there were a zillion programs (most of them written in DDT command language) that just tested %TYDIL to see if the user was at home. Rather than fix all of them, I changed the meaning of %TYDIL to mean what those programs already thought. That way I only had to fix ITS to test for %TYDIL+%TYRLM in those places where it was already testing just for %TYDIL. Now it is true that this broke programs that thought that %TYDIL meant "connected through a line that needs to have its terminal type set", but since somebody had to lose this argument I decided that these programs were simply mistaken about the meaning of that bit.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 02:43:41 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 02:43:40 EDT Date: Wed, 30 Apr 86 02:43:20 EDT From: "Patrick G. Sobalvarro" Subject: tty types To: ALAN@AI.AI.MIT.EDU cc: KLOTZ@AI.AI.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-SUPDUP@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 29 Apr 86 08:31:04 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].32866.860430.PGS> Date: Tue, 29 Apr 86 08:31:04 EDT From: Alan Bawden Date: Mon, 28 Apr 86 15:44:36 EDT From: Leigh L. Klotz I'm connected to MC via the Rolm Data Feature on T25. My init file insists that I'm on a line that already knows its tty type and SUPDUP warns me not to net hop. Perhaps the tty types file is broken? The TTYTYP file knows that T25 is a ROLM line, and the running ITS on MC at this moment does as well. How does your init file determine if you are on a line that "already knows its tty type"? Perhaps it does something bogus. (Note that until recently ROLM lines incorrectly had the %TYDIL bit set in their TTYTYP words, perhaps you are noticing an effect of this change.) I thought %TYDIL was correct for the ROLM lines, since they are exactly analogous to dialups; one connects terminals of different types to them, so they should have their tty types reset to something neutral when disconnected, etc. And, if we supported it in the 11, they should hang up after they've been logged out for a while, all those dialup-y things.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 APR 86 08:31:35 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 08:31:13 EDT Date: Tue, 29 Apr 86 08:31:04 EDT From: Alan Bawden Subject: tty types To: KLOTZ@AI.AI.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-SUPDUP@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 28 Apr 86 15:44:36 EDT from Leigh L. Klotz Message-ID: <[AI.AI.MIT.EDU].32475.860429.ALAN> Date: Mon, 28 Apr 86 15:44:36 EDT From: Leigh L. Klotz I'm connected to MC via the Rolm Data Feature on T25. My init file insists that I'm on a line that already knows its tty type and SUPDUP warns me not to net hop. Perhaps the tty types file is broken? The TTYTYP file knows that T25 is a ROLM line, and the running ITS on MC at this moment does as well. How does your init file determine if you are on a line that "already knows its tty type"? Perhaps it does something bogus. (Note that until recently ROLM lines incorrectly had the %TYDIL bit set in their TTYTYP words, perhaps you are noticing an effect of this change.) I don't know what SUPDUP does, but I do know that the nethop-detection code was recently rewritten. Perhaps it is doing something bogus as well. If this happens to you again, see if you can figure out just what TTY variables are the source of the problem. The output of :TCTYP DESCRIBE would be a good place to start.  Date: Mon, 28 Apr 86 16:52:29 EDT From: "Pandora B. Berman" Subject: log books To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].32120.860428.CENT> all the KSs have log books. AI's and MX's are on the little DM cabinet. MD's and ML's are on their CPUs. please write things in them. like "Brain transplant performed, all is well", or "now running NITS", or "jumpers attacked with soldering iron, arpanet up". if you don't write things down, no one will know they happened if you are not available to say so.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 APR 86 15:44:27 EDT Date: Mon, 28 Apr 86 15:44:36 EDT From: "Leigh L. Klotz" To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].897692.860428.KLOTZ> I'm connected to MC via the Rolm Data Feature on T25. My init file insists that I'm on a line that already knows its tty type and SUPDUP warns me not to net hop. Perhaps the tty types file is broken?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 APR 86 16:35:40 EST Date: Sat, 26 Apr 86 16:35:24 EST From: Daniel Weise To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].895936.860426.DANIEL> I found MC in a PI level 7 bugpause. The console line above the bugpuase was "too many parity errors." I dumped to CRASH PARITY and cold booted. Daniel  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 APR 86 12:55:36 EST Date: Sun, 20 Apr 86 12:54:59 EST From: "Devon S. McCullough" To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].889795.860420.DEVON> MC bughalted sometime around 10am, bugpc/caia uret2+2 so I dumped it into .;CRASH URGH and tried to warm boot but the KL10 halted immediately so I cold booted it.  Date: Fri, 18 Apr 86 03:37:32 EST From: Alan Bawden Subject: devices and names To: BUG-ITS@AI.AI.MIT.EDU, GZ@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].28319.860418.ALAN> The DEVICE directory was getting full due to the proliferation of various ITS names (past, present, and future), 20X names (for RMTDEV), and various concatenations of DIR with other device names. So I increased, yet again, the knowledge inside the unknown device handler (SYS;ATSIGN DEVICE) itself. The unknown device handler now loads various foreign filesystem devices from DEVICE;ATSIGN MLDEV or DEVICE;ATSIGN RMTDEV as appropriate. Various DIR devices that deal with the local filesystem are loaded directly from DEVICE;ATSIGN DIRDEV. Foreign filesystem DIR devices are loaded from DEVICE;ATSIGN MLDEV. (Archive DIR devices are not treated specially.) Note that the unknown device handler always checks the DEVICE directory for a JOBDEV file -before- looking at this new built-in knowledge, so it is easy to do local customizations on each machine. (Like on AI, the DIRAI device is loaded from ATSIGN DIRDEV, whereas the default is to load it from ATSIGN MLDEV.) Oh yeah. One of the reasons I was forced to do this is I added two synonyms for MC and MX. MC is now known also as "KL" and MX is now also known as "KS". The devices KL: and KS: work everywhere as appropriate. When we swap the names "MC" and "MX" (that is, when MC becomes a KS10, and MX becomes a KL10), we -won't- swap the names "KL" and "KS". Thus the file KL:ALAN;FOO BAR is the same file today as it will be next year, while MC:ALAN;FOO BAR will be a different one. (This did have the odd side effect that the NETWRK library now returns "MIT-KL" as the SIXBIT name for MC...)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 APR 86 20:18:29 EST Date: Fri, 4 Apr 86 20:18:37 EST From: Alan Bawden Subject: MC UNIT 1/PACK 13 To: KARENS@MC.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU In-reply-to: Msg of Fri 4 Apr 86 17:34:02 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].874128.860404.ALAN> Date: Fri, 4 Apr 86 17:34:02 EST From: Alan Bawden Date: Fri, 4 Apr 86 02:08:45 EST From: Pandora B. Berman has DEC made any progress in fixing this RP04?... apparently they came today and replaced the entire RP04.... And apparently it works for me, although when TK tried to bring it up he lost.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 APR 86 17:33:53 EST Date: Fri, 4 Apr 86 17:34:02 EST From: Alan Bawden Subject: MC UNIT 1/PACK 13 To: KARENS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Fri 4 Apr 86 02:08:45 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].873744.860404.ALAN> Date: Fri, 4 Apr 86 02:08:45 EST From: Pandora B. Berman To: KARENS at AI cc: BUG-ITS at AI Re: MC UNIT 1/PACK 13 has DEC made any progress in fixing this RP04?... apparently they came today and replaced the entire RP04. Whoever brought MC up after this decided for some reason that it was still broken. The console hardcopy doesn't look like they tried very hard, but I wasn't there so I don't know what really happened... Perhaps I'll take MC down for a few minutes tonight and see if I can figure out what the problem is.  Date: Fri, 4 Apr 86 02:08:45 EST From: "Pandora B. Berman" Subject: MC UNIT 1/PACK 13 To: KARENS@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].23885.860404.CENT> has DEC made any progress in fixing this RP04? i've gone by occasionally and seen notes promising to come back with more parts, but it's still offline. this is causing some potential problems: while Alan has made lots of progress in moving everything vital to AI, he can't move anything from SECOND: (PK13) because it's offline. maybe you could check on how DEC is doing on this, and impulse them to further effort if necessary? thanks.  Received: from MOSCOW-CENTRE.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAR 86 05:02:53 EST Date: Mon, 31 Mar 86 05:02 EST From: David Vinayak Wallace Subject: disowned vs in background To: BARTH@MIT-AI.ARPA, MBECK@MIT-AI.ARPA cc: BUG-ITS@MIT-AI.ARPA In-Reply-To: <[AI.AI.MIT.EDU].22357.860329.CENT> Message-ID: <860331050242.8.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU> Date: Sat, 29 Mar 86 17:23:33 EST From: "Pandora B. Berman" Date: Thu 27 Mar 86 06:47:55-EST From: "Mark Becker" I admit ignorance as well... when I see a "disowned" job on an ITS, its usually associated with some username somewhere. ----------begin forwarded mail---------- Date: Wed, 26 Mar 86 23:17:29 EST From: Richard Barth Ignorant question for today... What's the difference between running a job in the background and disowning it? beyond my limited technical ability to describe. someone on this list should be able to help you more. Roughly speaking, a disowned job has no superior nor controlling TTY, (f'rinstance like COMSAT normally runs). DDT lets you run jobs in background, (e.g. w/ or ) by running them without the TTY and handling output differently. Their superior is still DDT. From ITS's point of view the only difference between running a job in foreground or in background is who owns the TTY. For a more detailed description, do :UUO .DISOWN, .ATTY, etc. david PS: bug-its people: what do you think of using BUG-ITS for questions like this? I think it's a good idea, but if it's going to cause the fixers of bugs to remove themselves on the grounds of traffic levels, then we should have yet another list.  Date: Mon, 31 Mar 86 00:52:51 EST From: Alan Bawden Subject: AI:CRASH;CRASH QLOSS To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].22618.860331.ALAN> AI:CRASH;CRASH QLOSS contains a crash dump that I can't figure out. I don't, unfortunately, grok the interface between the main program level disk code and the interrupt level. It looked for all the world (to the users) like what happens on MC when the system is hung trying to write directories to the T-300's. I can tell that the main program level code is waiting for bits to arrive from interrupt level, but I don't understand why interrupt level isn't coming through. Of course, the fact that we have two disk drives for the first time on a KS is something to be suspicious of...  Date: Sat, 29 Mar 86 17:23:33 EST From: "Pandora B. Berman" Subject: disowned? To: BARTH@AI.AI.MIT.EDU, MBECK@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].22357.860329.CENT> Date: Thu 27 Mar 86 06:47:55-EST From: "Mark Becker" To: Cent@MC.LCS.MIT.EDU cc: Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, Barth@MC.LCS.MIT.EDU I admit ignorance as well... when I see a "disowned" job on an ITS, its usually associated with some username somewhere. ----------begin forwarded mail---------- Date: Wed, 26 Mar 86 23:17:29 EST From: Richard Barth To: MBECK@MC.LCS.MIT.EDU Ignorant question for today... What's the difference between running a job in the background and disowning it? beyond my limited technical ability to describe. someone on this list should be able to help you more.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAR 86 07:57:25 EST Date: Sat, 29 Mar 86 07:58:39 EST From: Alan Bawden Subject: So why did I bother you? To: BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Sat 29 Mar 86 05:40:15 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].865489.860329.ALAN> Date: Sat, 29 Mar 86 05:40:15 EST From: Alan Bawden Well I just noticed that right now all new files on AI are being placed on the secondary pack! This turned out to be easy to fix. If the pack on unit #0 had enough free space, ITS never noticed that it was not a primary pack. I fixed ITS to find a primary pack the first time someone writes a file after a boot.  Date: Sat, 29 Mar 86 05:40:15 EST From: Alan Bawden To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].22278.860329.ALAN> When I booted AI Friday morning, I wanted to test that I had built a working front-end filesystem and DSKDMP on the secondary pack. Since both the 8080 front end and DSKDMP assume they should boot from unit #0, I switched the unit number plugs so that the secondary pack was on unit #0 and the primary pack was on unit #1. Well I just noticed that right now all new files on AI are being placed on the secondary pack! Yesterday, with the units arranged the other way files were being made on PK0: just like the should have. Perhaps this is some unforseen result of my decision to number the secondary pack #1? (I should have chosen #13 to be conventional, but couldn't think of any reason why I couldn't choose any number I wanted.) Barf.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAR 86 00:51:46 EST Date: Sat, 29 Mar 86 00:53:03 EST From: Alan Bawden Subject: crash;crash massbs: I see no unit #1 here. To: MLY@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 28 Mar 86 11:20:19 EST from Richard Mlynarik Message-ID: <[MC.LCS.MIT.EDU].865339.860329.ALAN> Date: Fri, 28 Mar 86 11:20:19 EST From: Richard Mlynarik pi level 2 bughalt Apparently the controller told ITS that drive #1, which I believe is powered off, was asking for attention. (Perhaps it was wondering when DEC was coming back with the part they need to fix it.) When ITS obligingly asked the controller to ask the drive what its status was, the controller reported that it timed out on the drive. I guess we write this one off to hardware flakeiness.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 11:18:57 EST Date: Fri, 28 Mar 86 11:20:19 EST From: Richard Mlynarik Sender: MLY5@MC.LCS.MIT.EDU Subject: crash;crash massbs To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].864552.860328.MLY5> pi level 2 bughalt  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 09:17:59 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 28 Mar 86 09:04:06 EST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449266; Fri 28-Mar-86 08:52:48-EST Date: Fri, 28 Mar 86 09:00 EST From: David C. Plummer Subject: where do sources live? To: David Vinayak Wallace , ALAN@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY> Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 27 Mar 86 17:25:42 EST From: David Vinayak Wallace Why not delete sources from MC to prevent forking? Why not take the phones and phone books out of your office on the grounds you have sets at home?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 09:02:44 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 28 Mar 86 09:04:06 EST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449266; Fri 28-Mar-86 08:52:48-EST Date: Fri, 28 Mar 86 09:00 EST From: David C. Plummer Subject: where do sources live? To: David Vinayak Wallace , ALAN@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY> Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 27 Mar 86 17:25:42 EST From: David Vinayak Wallace Why not delete sources from MC to prevent forking? Why not take the phones and phone books out of your office on the grounds you have sets at home?  Date: Fri, 28 Mar 86 09:02:47 EST From: Alan Bawden Subject: A new ITS is born To: INFO-ITS@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].22057.860328.ALAN> MIT-MX came up for the first time this morning. (You can supdup there right now, but you won't find much when you get there...) There are still some problems with the technology for creating new ITS systems from scratch, but it mostly works. Hopefully after doing the next two (ML and MD) things will be pretty smooth. All kind of worms are crawling out of the woodwork because of various programs that -know- that all ITS machines are named "AI", "MC", "ML", or "DM". It should take another days hacking to stomp them all...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAR 86 09:00:09 EST Date: Fri, 28 Mar 86 09:01:33 EST From: Alan Bawden Subject: where do sources live? To: GUMBY@AI.AI.MIT.EDU cc: BUG-ITS@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU In-reply-to: Msg of Thu 27 Mar 86 17:25:42 EST from David Vinayak Wallace Message-ID: <[MC.LCS.MIT.EDU].864470.860328.ALAN> Date: Thu, 27 Mar 86 17:25:42 EST From: David Vinayak Wallace Why not delete sources from MC to prevent forking? Because I think in would be a good idea for them to get on the last full dump of MC.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAR 86 17:24:48 EST Date: Thu, 27 Mar 86 17:25:42 EST From: David Vinayak Wallace Subject: where do sources live? To: ALAN@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 27 Mar 86 16:59:17 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].863911.860327.GUMBY> Why not delete sources from MC to prevent forking?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAR 86 16:58:22 EST Date: Thu, 27 Mar 86 16:59:17 EST From: Alan Bawden To: JTW@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].863829.860327.ALAN> Pinhead! You modified MC:SYSNET;TELSER instead of AI:SYSNET;TELSER. If people make pinheaded mistakes like this we will be up to our necks in forked sources. Everybody: Remember that sources live on AI! If you are in doubt, look for a file named " MOVED TO AI " on the directory containing the source in question on MC. If this file exists, then all of the sources on that directory now live on AI. This has been true of all SYS*** directories for a couple of days now.  Date: Sun, 23 Mar 86 21:27:35 EST From: Alan Bawden Subject: Grand migration begins To: BUG-ITS@AI.AI.MIT.EDU, BUG-DDT@AI.AI.MIT.EDU, KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].20774.860323.ALAN> OK this is it. The migration of ITS system files from MC to AI is beginning. I have already moved a few directories and mailing lists and having just moved Bug-ITS and Bug-DDT to AI, I thought I would test them by informing you all of how this migration will work. I expect to have most of the SYS*** directories moved to AI by tomorrow. If you have some question about the status of a particular directory, look for a file on that directory named " MOVED TO AI ". If that file exists, then the file you are looking for now lives on AI, edits on MC are likely to be lost. If that file doesn't exist, then MC still has the master copy. In any case, if I am logged in, be cautious about timing screws.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 MAR 86 16:31:26 EST Received: from R20.UTEXAS.EDU by AI.AI.MIT.EDU.ARPA; 23 Mar 86 10:09:54 EST Received: from ALAMO.UTEXAS (ALAMO.UTEXAS.EDU.#Internet) by R20.UTEXAS.EDU with TCP; Sun 23 Mar 86 09:08:28-CST Date: Sun, 23 Mar 86 09:06 CST From: Gavan Duffy Subject: LMSEND To: BUG-ITS@MIT-AI.ARPA Message-ID: <860323090604.3.GAVAN@ALAMO.UTEXAS> It isn't on AI. Sigh. I had to CHTN to Jimi Hendrix to QSEND.  Date: Mon, 3 Mar 86 02:12:36 EST From: Alan Bawden Subject: " mode in PEEK To: BUG-ITS@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN> I added a new mode to PEEK for printing the contents of the system message buffer. (Type a doublequote to get it.) This is especially useful for looking at crash dumps. While I was at it I added a few features to crash dump mode itself. For a good example try (on AI): :PEEK Subject: ai crashed again To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].16595.860226.CENT> not just with the NXM during DUMP lossage. it got that (during the CHECK phase) and proceeded immediately to an MTAPE:RH11 error, IMP:I NXM... dumped to CRASH;IMP NXM. so i reloaded and tried to run ICHECK on the tape. it got a DSK ERR UNTI#0... BUGPC/CAI QHE+3 $Q-2/SKIPGE Q,,QSDU dumped to CRASH;DISK ERR. the second time, ICHECK worked.  Date: Tue, 25 Feb 86 14:02:21 EST From: David Vinayak Wallace Subject: Disk error To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].830224.860225.GUMBY> MC crashed, it looks like because it thought one of the tridents had been powered off. I doubt anybody cares, but I dumped it to CRASH QINTE0 just in case.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 FEB 86 13:36:26 EST Date: Mon, 24 Feb 86 13:38:49 EST From: Alan Bawden To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].16000.860224.ALAN> Well, basically I don't seem to ever be able to get the space to end of tape operation to work for me. Symptom: Mount a scratch tape and copy some files onto it (using :COPY for example). Rewind the tape (using the REWIND command in DUMP). Open MT0: in .BIO mode and issue a .MTAPE [ch,,[10]], while watching the drive. Observe that it clearly doesn't go to the end of the tape. Do the same UUO again without closing the channel and get an IRRECOVERABLE DATA ERROR. We are certainly going to need space-to-end-of-tape to work before we can start doing GFRs on a regular basis, since I understand GFR tapes are just appended together. Another oddity: Suppose you wrote three files on the tape. Rewind the tape and try reading them (using :PRINT). Observe that it looks like there is an extra, fourth, empty file after the files you wrote (before you start getting DEVICE FULL, which I presume is what you expect to get at the end of the tape).  Date: Mon, 24 Feb 86 13:14:44 EST From: Alan Bawden Subject: This tape misery never ends. To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].828798.860224.ALAN> A fellow just tried to read a 7-track tape (from ML) on AI's tape drive. The results were pretty interesting. He certainly didn't get any bits back and he caused DUMP and the magtape code to get pretty upset. The real fun started when he tried to kill the DUMP job. His DDT got hung up in .UCLOSE at MTICL+12 waiting for outstanding tape commands to go away. I took a crash dump in AI:CRASH;MTAPE CLOSE. Note that some interesting error messages from the tape driver were printed on the system console before this happened. I'll bet lots of pinheads try this in the future. Perhaps we sould license people before they can run DUMP?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 FEB 86 00:30:33 EST Date: Wed, 19 Feb 86 00:32:01 EST From: "Christopher C. Stacy" Subject: KS10 crash To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].14598.860219.CSTACY> AI crashed in the IMP code (at IMPIOS+4). I dumped it to CRASH;CSTACY IMPOS.  Date: Fri, 24 Jan 86 02:24:13 EST From: Alan Bawden Subject: pifail again To: BUG-ITS@MC.LCS.MIT.EDU cc: CENT@AI.AI.MIT.EDU In-reply-to: Msg of Fri 24 Jan 86 01:20:52 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].794321.860124.ALAN> Date: Fri, 24 Jan 86 01:20:52 EST From: Pandora B. Berman Re: pifail again is the name of the latest crash dump, again during an incr. dump. NXM on the Unibus again. This time the victimized instruction: MGWJD1: IORDI T,%TMCS1 ;Get controller status Unfortunately, all of a sudden Penny seems unable to get through an incremental dump without having this (or some Unibus NXM) happen. (Unlike the Chaos net board glitch the other day which only happened once.) Maybe the LH/DH really -does- have something to do with this? Or perhaps someone needs to physically tighten up everything on that Unibus.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86 02:08:01 EST Date: Fri, 24 Jan 86 01:20:52 EST From: "Pandora B. Berman" Subject: pifail again To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11649.860124.CENT5> is the name of the latest crash dump, again during an incr. dump.  Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JAN 86 14:50:57 EST Date: Tue 21 Jan 86 14:49:58-EST From: John Wroclawski Subject: Re: ai crash To: Moon@SCRC-STONY-BROOK.ARPA cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU In-Reply-To: Message from "David A. Moon " of Tue 21 Jan 86 14:15:38-EST Does anyone know how long the NXM timeout on a KS10 unibus is? The Chaos board can be slower to respond (3 or 4 microseconds?) when you read it twice in a row, as I recall. I think I remember it being 20 us. Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each other? If not, connecting a Unibus cable between them might cause electrical problems. That's a thought; they're not. I'm inclined to write this off to cosmic rays, and worry about it if it ever happens again after the hardware configuration of that unibus settles down. -------  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 21 Jan 86 14:05:53 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 397698; Tue 21-Jan-86 13:51:23-EST Date: Tue, 21 Jan 86 13:51 EST From: David A. Moon Subject: ai crash To: JTW@MIT-MC.ARPA cc: Alan Bawden , BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].790256.860120.ALAN> Message-ID: <860121135123.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 Jan 86 23:00:11 EST From: Alan Bawden Date: Mon, 20 Jan 86 22:32:34 EST From: Pandora B. Berman dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt complained about. see log for numbers. it was checking the incr. dump when this happened. after AI came up, the first time i tried to run ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE IN DEV. HUNG or something -- see sys log for details. the second time i tried ICHECK, it worked. The immediate cause of the crash was here in the interrupt level Chaos net code: CHSRC5: IORDI B,CAIRBF ;Read out the data, halfwords IORDI C,CAIRBF The second read from CAIRBF got a Non-Existent I/O Register error; just like someone had suddenly unplugged the Chaos board. I have a vague memory that Chaos boards do this sometimes. I hope I'm wrong. Alan and I discussed kludges for making the software resilient to this, but I hope we don't have to resort to them. It would be in the grand tradition of the previous two MIT-AI machines, though. If there were system messages from the magtape code indicating that it was unhappy as well, then perhaps we can conclude that the fault happened somewhere in the "I" Unibus itself. (It would be nice if :SYSMSG worked on a crash dump!) I used to have a program to do this, I think. Better would be to stick SYSMSG inside PEEK and then take advantage of PEEK's existing crash-dump-analysis feature. Perhaps someone who knows more Unibusology than I do can offer an opinion about what might cause this? Remember that this is the Unibus that supports the magtape drive, the DZ11's and the Chaosnet interface. The magtape code was shooting bits back and forth like crazy at the time, presumably that contributed somehow? JTW: Is the LH/DH plugged into this bus right now? Perhaps it did something nasty? JTW: Can you look at the crash dump and figure out whether the magtape RH-11 was supposed to be doing DMA at the time this crash happened? Maybe it and the Chaos board interfere with each other somehow? Does anyone know how long the NXM timeout on a KS10 unibus is? The Chaos board can be slower to respond (3 or 4 microseconds?) when you read it twice in a row, as I recall. Are the KS10 cabinet and the LH/DH cabinet firmly grounded to each other? If not, connecting a Unibus cable between them might cause electrical problems.  Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 23:12:00 EST Date: Mon 20 Jan 86 23:11:02-EST From: John Wroclawski Subject: Re: ai crash To: alan@MC.LCS.MIT.EDU cc: CENT@AI.AI.MIT.EDU, bug-its@MC.LCS.MIT.EDU In-Reply-To: Message from "Alan Bawden " of Mon 20 Jan 86 23:06:09-EST JTW: Is the LH/DH plugged into this bus right now? Perhaps it did something nasty? Yes, and maybe so. Specially since it doesn't seem to work like it is supposed to right at the moment. It would be nice to know the state of the UBA at that point in time... -------  Date: Mon, 20 Jan 86 23:00:11 EST From: Alan Bawden Subject: ai crash To: BUG-ITS@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU cc: CENT@AI.AI.MIT.EDU In-reply-to: Msg of Mon 20 Jan 86 22:32:34 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].790256.860120.ALAN> Date: Mon, 20 Jan 86 22:32:34 EST From: Pandora B. Berman dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt complained about. see log for numbers. it was checking the incr. dump when this happened. after AI came up, the first time i tried to run ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE IN DEV. HUNG or something -- see sys log for details. the second time i tried ICHECK, it worked. The immediate cause of the crash was here in the interrupt level Chaos net code: CHSRC5: IORDI B,CAIRBF ;Read out the data, halfwords IORDI C,CAIRBF The second read from CAIRBF got a Non-Existent I/O Register error; just like someone had suddenly unplugged the Chaos board. If there were system messages from the magtape code indicating that it was unhappy as well, then perhaps we can conclude that the fault happened somewhere in the "I" Unibus itself. (It would be nice if :SYSMSG worked on a crash dump!) Perhaps someone who knows more Unibusology than I do can offer an opinion about what might cause this? Remember that this is the Unibus that supports the magtape drive, the DZ11's and the Chaosnet interface. The magtape code was shooting bits back and forth like crazy at the time, presumably that contributed somehow? JTW: Is the LH/DH plugged into this bus right now? Perhaps it did something nasty?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 JAN 86 22:32:38 EST Date: Mon, 20 Jan 86 22:32:34 EST From: "Pandora B. Berman" Subject: ai crash To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11362.860120.CENT> dumped to CRASH;PI-IN PROGRS, which is what the PI lev. 6 bughalt complained about. see log for numbers. it was checking the incr. dump when this happened. after AI came up, the first time i tried to run ICHECK, DUMP got an error; it mentioned RH11 err and maybe MAG TAPE IN DEV. HUNG or something -- see sys log for details. the second time i tried ICHECK, it worked.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 16:03:59 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JAN 86 16:04:12 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 17 Jan 86 16:03:39 EST Date: Fri 17 Jan 86 15:31:41-EST From: J. J. Tyrone Sealy Subject: Re: tape lossage To: Moon@SCRC-STONY-BROOK.ARPA cc: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU In-Reply-To: <860117134457.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12176026589.28.TY@XX.LCS.MIT.EDU> If you can come over. Please do. Unless there is someone else that can fix it. tnx..--TY -------  Date: Fri, 17 Jan 86 15:51:48 EST From: Alan Bawden Subject: tape lossage To: CENT@AI.AI.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, TY@MC.LCS.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Fri 17 Jan 86 13:44 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].787522.860117.ALAN> Date: Fri, 17 Jan 86 13:44 EST From: David A. Moon Date: Fri, 17 Jan 86 07:43:58 EST From: "Pandora B. Berman" i wandered over to bring up MC when it crashed, and noticed tape 4000 on the drive. apparently Ty was running a full dump. the dump log contains a note on the MC 4000 line: "Something happened". dave, didn't you say something about 4000 being the max. number for an ITS tape? how does this get fixed? I don't recall saying that. There is a limit on the highest tape number that's controlled by the size of the SYSENG;MACRO TAPES file. The limit can be changed; I don't remember how, but it involves code in DUMP that's commented something like "Don't do this unless you are RJL, and even then be careful." We probably don't need to import RJL to do it. If you need me to come over and figure out the details, ask. This limit must have been reached in the past since the full dump tapes recorded in the database only go back to some time in 1983. But just in case, I figured out the way to change the limit and upped it to 5000. So we probably don't need to worry about this limit on MC ever again...  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 13:49:12 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JAN 86 13:49:23 EST Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 17 Jan 86 13:48:45 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 395098; Fri 17-Jan-86 13:44:24-EST Date: Fri, 17 Jan 86 13:44 EST From: David A. Moon Subject: tape lossage To: Pandora B. Berman cc: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].11164.860117.CENT> Message-ID: <860117134457.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 17 Jan 86 07:43:58 EST From: "Pandora B. Berman" i wandered over to bring up MC when it crashed, and noticed tape 4000 on the drive. apparently Ty was running a full dump. the dump log contains a note on the MC 4000 line: "Something happened". dave, didn't you say something about 4000 being the max. number for an ITS tape? how does this get fixed? I don't recall saying that. There is a limit on the highest tape number that's controlled by the size of the SYSENG;MACRO TAPES file. The limit can be changed; I don't remember how, but it involves code in DUMP that's commented something like "Don't do this unless you are RJL, and even then be careful." We probably don't need to import RJL to do it. If you need me to come over and figure out the details, ask.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 07:43:43 EST Date: Fri, 17 Jan 86 07:43:58 EST From: "Pandora B. Berman" Subject: tape lossage To: BUG-ITS%AI.AI.MIT.EDU@MC.LCS.MIT.EDU cc: TY%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, MOON%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11164.860117.CENT> i wandered over to bring up MC when it crashed, and noticed tape 4000 on the drive. apparently Ty was running a full dump. the dump log contains a note on the MC 4000 line: "Something happened". dave, didn't you say something about 4000 being the max. number for an ITS tape? how does this get fixed?  Date: Sat, 11 Jan 86 18:25:45 EST From: Chris Hanson Subject: Losing Dialup To: BUG-SYSTEM@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].780740.860111.CPH> When I dial x6985, I am getting a connection which responds to my carriage return with the standard "Connected to MC.", but then it fails to give me a HACTRN. C-Z has no effect. I notice that *nobody* is logged in from a dialup. This seems like it might be related.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jan 86 04:47:57 EST Received: from bostonu by csnet-relay.csnet id ac02199; 6 Jan 86 4:39 EST Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7) id AA14297; Sun, 5 Jan 86 17:08:56 est Date: Sun, 5 Jan 1986 17:09 EST Message-Id: <[BUCS20].JSOL. 5-Jan-86 17:09:02> From: Jon Solomon To: Alan Bawden Cc: BUG-ITS@mit-mc.arpa, BUG-MAIL@mit-mc.arpa, BUG-RANDOM-PROGRAM@mit-mc.arpa, KS-ITS@mit-mc.arpa Subject: [JSOL: TELECOM] Consider this a warning. Phase-Of-The-Moon: LQ+2D.21H.36M.2S. In-Reply-To: Msg of 5 Jan 1986 15:26-EST from Alan Bawden Okay, now I know the intended audience for my message. One fact that I forgot to mention in the other message was that this JUST started happening about a week ago. Whoever is hacking COMSAT, please take note. Thanks, --JSol  Date: Sun, 5 Jan 86 15:26:51 EST From: Alan Bawden Subject: [JSOL: TELECOM] Consider this a warning. To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].773515.860105.ALAN> MSG: *MSG 4866 Date: 01/05/86 13:22:00 From: JSOL at XX.LCS.MIT.EDU To: *BBOARD at XX.LCS.MIT.EDU Re: TELECOM Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 13:21:49 EST Date: Sun 5 Jan 86 13:24:23-EST From: Jon Solomon Subject: TELECOM To: BBOARD@MC.LCS.MIT.EDU Message-ID: <12172857686.19.JSOL@XX.LCS.MIT.EDU> Due to the installation of a new mail system, I can no longer ship off TELECOM to MC. Since there are quite a large number of MC users on TELECOM, and considering the fact that this restriction might affect other digests, I am sending this message to your bulletin board rather than individually to MC users. I -believe- what he is refering to is the fact that digests tend to be large enough that they exceed COMSAT's pitifully small size limitation. I note that CSTACY claimed the lock for hacking COMSAT two weeks ago, hacked on it for an evening, and hasn't logged in since then. There are now about 130 BADREQ files on .MAIL2, many of them 2 weeks old. (I'm going to have to create .MAIL3 soon...) Warning: If the day ever comes that I feel that it is Up-To-Me- To-Do-Something about COMSAT (because of address space problems, lack of proper domain support, or whatever) I will simply advise everybody that ITS no longer supports mail for users or mail forwarding for the network and I will shut it off. I feel this day -rapidly- approaching. I don't see any competent programmers making the kind of necessary effort it is going to take to straighten out this mess. I am forwarding this message to a large audience in the hopes that somebody will get inspired, but I realize this is grasping at straws.  Date: Fri, 3 Jan 86 00:33:24 EST From: "J. Noel Chiappa" Subject: Static routes in MC's routing table To: BUG-TCP@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, JNC@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].771596.860103.JNC> There are way too many (old) static routes in the table. They don't seem to get updated correctly; data for SCRC was going through the (loaded) MIT-GW instead of the (idle) MIT-AI-GW, although the rest of the Internet got the change months ago. Someone should delete all but the necessary ones. I deleted the SCRC one and patched it out in the running system, with the result that it instantly picked up the right one. Also, the ICMP Redirect code is not the best possible in that it does no handle per-Host Redirects well; it folds them all into the single net entry. When we start attaching ITSen to subnetted nets, this will lose big; traffic to different subnets will thrash the cache line. For that matter, the ITS IP layer doesn't use the correct 'mask' algorithm for dealing with host addresses (per RFC940, etc).  Date: Sat, 28 Dec 85 19:00:48 EST From: Alan Bawden Subject: page fault in system To: GUMBY@MC.LCS.MIT.EDU cc: HIC@MC.LCS.MIT.EDU, POOR-MC@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 22 Dec 85 15:21:29 EST from David Vinayak Wallace Message-ID: <[MC.LCS.MIT.EDU].767454.851228.ALAN> [ Why are we Cc'ing this message to HIC? ] Date: Sun, 22 Dec 85 15:21:29 EST From: David Vinayak Wallace ITS took a page fault. Look in CRASS PAGFLT if you care. Specifically, ITS took a page fault running in the scheduler. It thought it was looking at somebody's USTP bits, but U contains gubbish, and it looks like the hardware pagetable must have contained some kind of a joke as well. I am tempted to agree with you that this was the result of glitch. (That must be what you think since you mailed this to Poor-MC, right?) PS: Someone seems to have deleted the pooor-mc alias. I don't think it ever really had that name, at least not for long. I suggested it, but I think somebody corrected my joke thinking it was a typo almost instantly.  Date: Mon, 23 Dec 85 05:50:31 EST From: Gail Zacharias Subject: Compression To: ALAN@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU, LIN@MC.LCS.MIT.EDU, PGS@OZ.AI.MIT.EDU In-reply-to: Msg of Mon 16 Dec 85 15:46:52 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].764485.851223.GZ> AR4:GZ;ENCODE and DECODE. Encoding a large text file typically gives a little over half of the original size.  Date: Mon, 23 Dec 85 00:22:08 EST From: "Glenn S. Burke" Subject: IBO To: BUG-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].764318.851223.GSB> I just got "IBO" on the dialups. i tried 6985, 6986, and 6989 for good measure...  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Dec 85 14:30:51 EST Date: Thu 19 Dec 85 14:02:59-EST From: "J. Noel Chiappa" Subject: Re: ICMP: GW table full To: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, bug-tcp@MC.LCS.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <[MIT-MC.ARPA].757281.851216.ALAN> Message-ID: <12168408267.46.JNC@XX.LCS.MIT.EDU> This is a harmless message. The IP routing table (see PEEK 'W' display) is a cache of the most recently used routes; when it fills up and needs to add a new route, it punts the lest recently route. The message is unnecessary. It would be good to notice if the cache is too small (e.g. if the route discarded was used less than five minutes ago) and log that; it might also be good to add a count of the number of cache flushes and the number flushed in, say, the last hour. -------  Date: Mon, 16 Dec 85 23:20:56 EST From: Alan Bawden Subject: ICMP: GW table full To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].757281.851216.ALAN> If you run SYSMSG on MC you will generally find that the message buffer is 90% full of messages of the form: ICMP: GW table full, net/gw 20024,,600000 1200,,76 => 30001,,255000 1200,,400045 MON 22:07:12 I presume this all means something to KLH and the rest of you TCP hackers, but to me it is just an annoying amount of output that seems to be associated no problem that I can see. Is this a symptom of a real problem, or does it just mean that some fixed size table should be made a little larger? Or perhaps we should consider not bothering the system console with this common event, whatever it is.  Date: Mon, 16 Dec 85 15:46:52 EST From: Alan Bawden Subject: Compression To: LIN@MIT-MC.ARPA, GZ@MIT-MC.ARPA, PGS@MIT-OZ cc: BUG-ITS@MIT-MC.ARPA, GUMBY@MIT-MC.ARPA In-reply-to: Msg of Mon 16 Dec 1985 13:54 EST from PGS%MIT-OZ at MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].756680.851216.ALAN> Date: Mon, 16 Dec 1985 13:54 EST From: PGS at OZ Date: Monday, 16 December 1985 12:08-EST From: David Vinayak Wallace do you know about the ARx devices? I don't think those perform text compression, do they? No, they don't. They make a collection of small files take less space on disk by removing the average of half a block of wasted space at the end of every file. They also take up less room in your directory because the names of the files are stored in the archive itself, leaving only one entry stored in your directory. If you are looking for a program that compresses ASCII text by taking advantage of the fact that certain sequences of characters are more common than others, I think that Gail Zacharias (GZ@MC) has the best program for this that I have seen. I can't seem to find it at the moment though. Gail?  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 16 DEC 85 14:09:24 EST Date: Mon, 16 Dec 1985 13:54 EST Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: David Vinayak Wallace Cc: BUG-ITS@MIT-MC.ARPA, LIN@MIT-MC.ARPA In-reply-to: Msg of 16 Dec 1985 12:08-EST from David Vinayak Wallace Date: Monday, 16 December 1985 12:08-EST From: David Vinayak Wallace To: LIN at MIT-MC.ARPA cc: BUG-ITS at MIT-MC.ARPA do you know about the ARx devices? I don't think those perform text compression, do they?  Date: Mon, 16 Dec 85 12:08:03 EST From: David Vinayak Wallace To: LIN@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Mon 16 Dec 85 11:51:47 EST from Herb Lin Message-ID: <[MIT-MC.ARPA].756162.851216.GUMBY> do you know about the ARx devices?  Date: Mon, 16 Dec 85 11:51:47 EST From: Herb Lin To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].756101.851216.LIN> help requested from a wizard. Is there any way of doing rXX text compression on large text files purely on ITS... Something analagous to the SQUEEZE programs available for micros? thans.XXX thanks.  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 13 DEC 85 01:30:47 EST Date: Fri, 13 Dec 85 01:28:45 EST From: "Pandora B. Berman" Subject: ai died To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].8641.851213.CENT> ai suddenly hit a PI LEVEL 7 BUGHALT. crash dump to CRASH;SUDDEN LOSS  Date: Mon, 9 Dec 85 19:41:51 EST From: David Vinayak Wallace Subject: oops To: BUG-SYSTEM@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].747566.851209.GUMBY> As you can guess, that should have gone to bug-system@oz. Sorry  Date: Mon, 9 Dec 85 18:04:22 EST From: David Vinayak Wallace Subject: dialup problem To: CHUNKA@MIT-OZ cc: BUG-SYSTEM@MIT-MC.ARPA In-reply-to: Msg of Mon 9 Dec 1985 16:22 EST from Chunka Mui Message-ID: <[MIT-MC.ARPA].747534.851209.GUMBY> OZ doesn't have the hardware. Your modem uses bell's 1200-baud frequencies. Vadic uses different ones.  Date: Sat, 7 Dec 85 19:02:36 EST From: Alan Bawden Subject: .msgs.; bloated To: BUG-COMSAT@MIT-MC.ARPA, CENT@MIT-AI.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 7 Dec 85 06:10:23 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].745744.851207.ALAN> Date: Sat, 7 Dec 85 06:10:23 EST From: Pandora B. Berman for reasons unknown, AI can't figure out how to purge obsolete msgs from .MSGS.;. it wouldn't do it when the files weren't backed up, but i expected that. however, now the files are regularly backed up, the _LAST_ EXPIRE file looks well formed, but they -still- don't disappear on cue. MC, on the other hand, seems to have no problem in this regard. any ideas why? A Typical message from MC:.MSGS.;*MSG > begins: DISTRIB: *BBOARD EXPIRES: 12/14/85 12:38:14 Received: from BORAX by MIT-MC.ARPA 7 Dec 85 12:38:13 EST A typical message from AI:.MSGS.;*MSG > begins: Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 7 DEC 85 12:37:44 EST DISTRIB: *BBOARD EXPIRES: 12/14/85 12:38:14 Received: from BORAX by MIT-MC.ARPA 7 Dec 85 12:38:13 EST I suspect the recieved line at the front fakes GMSGS out when it tries to find the expiration date. This could be fixed by changing COMSAT to not do this, or by fixing GMSGS to be smarter. Somebody else is going to fix this one. (I don't think it can be all -that- hard guys!)  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 7 DEC 85 06:11:37 EST Date: Sat, 7 Dec 85 06:10:23 EST From: "Pandora B. Berman" Subject: .msgs.; bloated To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].8152.851207.CENT> for reasons unknown, AI can't figure out how to purge obsolete msgs from .MSGS.;. it wouldn't do it when the files weren't backed up, but i expected that. however, now the files are regularly backed up, the _LAST_ EXPIRE file looks well formed, but they -still- don't disappear on cue. MC, on the other hand, seems to have no problem in this regard. any ideas why?  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 29 Nov 85 23:50:31 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364604; Fri 29-Nov-85 23:45:47-EST Date: Fri, 29 Nov 85 23:44 EST From: David A. Moon Subject: Any takers? To: Alan Bawden cc: BUG-ITS@MIT-MC.ARPA, BUG-RANDOM-PROGRAM@MIT-MC.ARPA, BUG-DDT@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].692189.851024.ALAN> Message-ID: <851129234420.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 24 Oct 85 23:38:25 EDT From: Alan Bawden With all of these parity errors MC gets these days, and with all of these naive users who haven't the slightest idea what to do when they have detached job trees, the amount of disowned junk is getting to be a pain. Now there is really no good reason why a program couldn't be written that would would look around in the system for jobs with your XUNAME and offer some intelligent (and clearly explained) choices to you. Anybody interested? I'm not up for thinking about the problem right now, but I'd be happy to brainstorm in person with anyone else who would like to take a crack at it. I'm sure I wrote this at Ellen's request and she put it into the init files of the known naive Macsyma users. I think it was called RETACH or something like that.  Date: Tue, 29 Oct 85 20:47:43 EST From: Alan Bawden Subject: Silly lineprinter devices again. To: INFO-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].697383.851029.ALAN> Remember the 7LP: and 7LR: devices? Well, now that we have a third such device on the 9th floor, and another one coming soon to the 8th, it would make sense for me to tell you that I have installed 8LP: and 9LP: devices, right? WRONG! Since a clear numbering trend is emerging it makes sense to change the naming scheme so that the number comes -last-. So the official names are now: LP7: The 7th floor QMS 2400 LP8: The 8th floor QMS 2400 LP9: The 9th floor QMS 1200 LR7: The 7th floor laserwriter The two old names 7LP: and 7LR: continue to work for compatibility.  Date: Sun, 27 Oct 85 22:20:53 EST From: Alan Bawden Subject: echoing weirdness To: GRENNY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sun 27 Oct 85 20:08:43 EST from Ian Macky Message-ID: <[MIT-MC.ARPA].694733.851027.ALAN> Date: Sun, 27 Oct 85 20:08:43 EST From: Ian Macky *fr^K!a l e [There goes GZ] cTo OAF.G.BRIDGET@MIT-OZ: ittle pkish, perhaps... [the "ec" from "peckish" got echoed before anything else... how WEIRD!! (well, not before everything, but you see)] Just another wierd case with echoing input at interrupt level. ITS decides how to do interrupt level echoing by looking at what job currently has control of the TTY. In this case DDT had control of the TTY for a few moments while it typed the Argus message, so ITS echoed the two characters you typed during those moments. (I guess FR is looking at %TXPIE bits in character to determine how to echo the user's typeahead.) I'm suprised that FR and REPLY aren't handling %PIATY interrupts. If they were you wouldn't have seen this happen. SEND seems to be hacking %PIATY; why should SENDER vary this aspect of its behavior for replying vs. sending?  Date: Sun, 27 Oct 85 20:08:43 EST From: Ian Macky To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].694678.851027.GRENNY> echoing weirdness: *fr^K!a l e [There goes GZ] cTo OAF.G.BRIDGET@MIT-OZ: ittle pkish, perhaps... [the "ec" from "peckish" got echoed before anything else... how WEIRD!! (well, not before everything, but you see)]  Date: Thu, 24 Oct 85 23:38:25 EDT From: Alan Bawden Subject: Any takers? To: BUG-ITS@MIT-MC.ARPA, BUG-RANDOM-PROGRAM@MIT-MC.ARPA, BUG-DDT@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].692189.851024.ALAN> With all of these parity errors MC gets these days, and with all of these naive users who haven't the slightest idea what to do when they have detached job trees, the amount of disowned junk is getting to be a pain. Now there is really no good reason why a program couldn't be written that would would look around in the system for jobs with your XUNAME and offer some intelligent (and clearly explained) choices to you. Anybody interested? I'm not up for thinking about the problem right now, but I'd be happy to brainstorm in person with anyone else who would like to take a crack at it.  Date: Tue, 22 Oct 85 14:29:28 EDT From: Alan Bawden Subject: super-image mode/slaved ttys To: GUMBY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, ED@MIT-MC.ARPA In-reply-to: Msg of Tue 22 Oct 85 00:14:31 EDT from David Vinayak Wallace Message-ID: <[MIT-MC.ARPA].688804.851022.ALAN> Date: Tue, 22 Oct 85 00:14:31 EDT From: David Vinayak Wallace ... 1> I know he's on the same kind of terminal I am, so I want whatere goes down the wire to his terminal to go down the wire to mine. 2> I want the system to hack ^P codes for me so that I can poke around even if our terminals don't match. In my previous letter I was asking for 1> above, but two would be more useful in most cases. By "escape code" I meant some ^_ code to tell ITS just to pump the characters through. ... Getting any scheme like 2 to work is probably impossible. What do you do if the guy's terminal supports insert and delete character and yours doesn't? What about if his terminal is 5 lines longer than yours? Even virtual terminals have characteristics that are visible to the programs that use them. 1 could be made to work I guess. You would have to do it at the level of %TD codes rather than ^P codes (since that is the only level at which there is really a universal language). There is a bunch of other things you have to worry about I guess, like making sure the characters you type get echoed in the way his program desires. Given that it can only work some of the time, and that it is pretty hard to get right, I can think of better things to do with our time.  Date: Tue, 22 Oct 85 00:14:31 EDT From: David Vinayak Wallace Subject: super-image mode/slaved ttys To: ALAN@MIT-MC.ARPA, ED@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-Reply-to: Msg of Mon, 21 Oct 85 13:48:07 EDT from Alan Bawden Msg of Mon, 21 Oct 85 18:23:37 EDT from Ed Schwalenberg , Message-ID: <[MIT-MC.ARPA].687999.851022.GUMBY> Date: Mon, 21 Oct 85 13:48:07 EDT From: Alan Bawden Date: Mon, 21 Oct 85 06:11:40 EDT From: David Vinayak Wallace Is there any way to get ITS to put your tty in super-image mode via escape codes? Otherwise when you slave a tty you get ghubbish (making slaved ttys almost useless. Are they a pre-TS3TTY relic?). I can't figure out what you are asking from this. First please distinguish between super-image input and super-image output (two quite unrelated things despite the similarity in names). Second please distinguish between the various kind of escape codes in the ITS world; are you talking about ^P codes? Third, by "slaved ttys" are you refering to the state you can achieve in a com-link where one console's type-in is seen by another console's job-tree? Date: Mon, 21 Oct 85 18:23:37 EDT From: Ed Schwalenberg And fourth, is the TTY you are slaving logged-in or free, and what type (software, printing, AAA, etc.) is your TTY and the one you're slaving? Ok. Let me start over: Luser :LUSERs me and tells me he can't run BABYL. BABYL runs fine for me on his mail file. I'd like to ^_e him and poke around in the debugger in his BABYL. But all I get is ghubbish on my screen. Two possible ways that ITS could get around this (and maybe both are desirable for different circumstances): 1> I know he's on the same kind of terminal I am, so I want whatere goes down the wire to his terminal to go down the wire to mine. 2> I want the system to hack ^P codes for me so that I can poke around even if our terminals don't match. In my previous letter I was asking for 1> above, but two would be more useful in most cases. By "escape code" I meant some ^_ code to tell ITS just to pump the characters through. Free vs logged-in isn't relevent to this, since you can :TCTYP a free tty after sending a CALL through.  Date: Mon, 21 Oct 85 23:08:10 EDT From: "Pandora B. Berman" Subject: file system not fukt To: BUG-SYSTEM@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].687814.851021.CENT> i should have been using $^R. my mind must be going. sorry to bother you.  Date: Mon, 21 Oct 85 23:00:01 EDT From: "Pandora B. Berman" Subject: FILE SYSTEM FUKT To: BUG-SYSTEM@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].687803.851021.CENT> i was in ddt, moving some ostats files to third: with $$^O. it worked for the first one i tried no problem -- this was the second most recently created ostats file. then i tried $$^O ostats >,third: and got the reply that it can't copy to a different directory -- third: so i tried specifying the file version $$^O ostats 3636,third: and it replied third: .mail.;ostats 3636 - file exists (!) clearly someone is real confused here, and i don't think it's me.  Date: Mon, 21 Oct 85 13:48:07 EDT From: Alan Bawden Subject: super-image mode To: GUMBY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Mon 21 Oct 85 06:11:40 EDT from David Vinayak Wallace Message-ID: <[MIT-MC.ARPA].687073.851021.ALAN> Date: Mon, 21 Oct 85 06:11:40 EDT From: David Vinayak Wallace Is there any way to get ITS to put your tty in super-image mode via escape codes? Otherwise when you slave a tty you get ghubbish (making slaved ttys almost useless. Are they a pre-TS3TTY relic?). I can't figure out what you are asking from this. First please distinguish between super-image input and super-image output (two quite unrelated things despite the similarity in names). Second please distinguish between the various kind of escape codes in the ITS world; are you talking about ^P codes? Third, by "slaved ttys" are you refering to the state you can achieve in a com-link where one console's type-in is seen by another console's job-tree?  Date: Mon, 21 Oct 85 06:11:40 EDT From: David Vinayak Wallace Subject: super-image mode To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].686691.851021.GUMBY> Is there any way to get ITS to put your tty in super-image mode via escape codes? Otherwise when you slave a tty you get ghubbish (making slaved ttys almost useless. Are they a pre-TS3TTY relic?).  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 10 OCT 85 03:15:49 EDT Date: Thu, 10 Oct 85 03:15:03 EDT From: Oded Feingold To: BUG-ITS%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].5013.851010.OAF> I plugged terminals in and out of TTY07, and eventually the DZ wouldn't answer anymore. I reloaded ITS, and left the crash dump on DZ SILENT. I doubt there's much interesting there.  Date: Mon, 7 Oct 85 18:12:27 EDT From: Christopher C. Stacy Subject: some job device losing To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].671384.851007.CSTACY> I can't use any jobdevs right now because there are a whole pile of what looks like MLDEVs with the jname "CFTP" and channels open on the file "OZKS: ;". I am going to gun them down, preserving one corpse CRASH;MLDEV OZ. The pc is/345 (.HANGing).  Date: Thu, 3 Oct 85 23:49:07 EDT From: Tim McNerney To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Thu 3 Oct 85 15:08:07 EDT from Christopher C. Stacy Message-ID: <[MIT-MC.ARPA].668221.851003.TIM> Date: Thu, 3 Oct 85 15:08:07 EDT From: Christopher C. Stacy To: BUG-ITS at MIT-MC.ARPA There is a POOR-MC@MC list now. What's it for?  Date: Thu, 3 Oct 85 15:08:07 EDT From: Christopher C. Stacy To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].667593.851003.CSTACY> There is a POOR-MC@MC list now.  Date: Mon, 30 Sep 85 17:37:39 EDT From: Alan Bawden Subject: Pooor MC To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].663719.850930.ALAN> MC crashed twice today with parity errors in MH10-A (system memory). The I/O-11 crashed both times. I reconfigured the machine to swap MH10-A and MH10-B so that the next time errors occur in that box they won't be quite so fatal. Conceivably someone should log a service call with DEC. I did nothing.  Date: Sat, 28 Sep 85 02:40:59 EDT From: Alan Bawden To: GZ@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Fri 27 Sep 85 23:39:45 EDT from Gail Zacharias Message-ID: <[MIT-MC.ARPA].661760.850928.ALAN> Date: Fri, 27 Sep 85 23:39:45 EDT From: Gail Zacharias I keep getting top-level interrupts, about once every half hour. They are parity errors. Nothing that we can do anything about except throw the memory out the window. Look at the bright side: some operating systems would have halted the whole machine every time that happened, rather than just stopping a few jobs. I suppose we could make the message the user gets when he gets detached this way more explicit, but it hardly seems worth the effort given that the day is fast approaching when ITS will only run on KS10s, which (for the moment at least) are more reliable hardware.  Date: Fri, 27 Sep 85 23:39:45 EDT From: Gail Zacharias To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].661709.850927.GZ> I keep getting top-level interrupts, about once every half hour.  Date: Fri, 27 Sep 85 23:15:08 EDT From: Gail Zacharias To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].661707.850927.GZ> I keep getting top-level interrupts, about once every half hour.  Date: Fri, 27 Sep 85 00:13:26 EDT From: Alan Bawden Subject: Bloat To: BUG-COMSAT@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].661199.850927.ALAN> Due to total bloat of .MAIL.; LISTS MSGS I have created .MAIL2 and moved many non-essential files there. Most of the queued mail is destined for OZ which will hopefull be up sometime tomorrow (so they tell me). COMSAT features that would be nice in a situation like this: It would be nice to be able to tell COMSAT to take all mail destined for a particular host and dump it all in some file somewhere and forget about it for a few days. Bouncing failed mail back to senders is counter-productive in a situation like the current one. It would be nice if COMSAT was smarter about the finite directory size. For example, if it looks to COMSAT like there might not be room to GC the LISTS MSGS file in place, it could output the new LISTS MSGS on a different directory (effectively doubling the available room for a GC). Easiest of all, perhaps you could set things up so that LISTS MSGS and the MAIL > files didn't live on the same directory? Having COMSAT's GC fighting for space with mail servers is moderately annoying at times.  Date: Tue, 24 Sep 85 05:07:32 EDT From: Alan Bawden Subject: Now installed on AI, and soon to be installed on MC. To: INFO-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].657412.850924.ALAN> There is now a demon job that runs when ITS starts up that attempts to set the time from the network. The message that the system types out at boot time when it discovers that the clock has been reset no longer commands the hacker to log in and run PDSET, instead it tells him that he should just stick around a watch what happens in case he has to run it. The demon will print a message on the system console explaining what it did about the time. If the demon was unsatisfied that it could determine the time, the message will try to attract the hacker's attention and explain to him what the problem was and tell him that he does have to run PDSET after all.  Date: Sat, 21 Sep 85 17:34:46 EDT From: Devon S. McCullough To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].653477.850921.DEVON> I keep getting toplevel interrupts (presumably parity errors?) detaching my tree, twice in the last three hours.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 20 SEP 85 15:13:46 EDT Date: Fri, 20 Sep 1985 15:14 EDT Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: "Ronald I. Greenberg" , devon@MIT-MC.ARPA Cc: BUG-ITS@MIT-MC.ARPA, bug-tctyp@MIT-MC.ARPA Subject: terminal handler for heath In-reply-to: Msg of 20 Sep 1985 13:33-EDT from Ronald I. Greenberg Date: Friday, 20 September 1985 13:33-EDT From: Ronald I. Greenberg To: BUG-ITS at MIT-MC.ARPA Re: terminal handler for heath It appears that the terminal handler for heath terminals has been screwed up. Using either an actual heath or a Zenith Z-29-A, ":tctyp heath" results in something weird. A "?2h" gets printed on the terminal, and ocassionally at some point in time (generally when you get to the bottom of the screen I think) the terminal becomes totally wedged. This has been noticed by me and several other members of the Theory Group for the last couple days. I guess I was wrong. Devon, why don't you NOT put whatever you think is right in the TCTYP initialization string and instead re-install the old source and binaries.  Date: Fri, 20 Sep 85 13:33:15 EDT From: Ronald I. Greenberg Subject: terminal handler for heath To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].652278.850920.RIG> It appears that the terminal handler for heath terminals has been screwed up. Using either an actual heath or a Zenith Z-29-A, ":tctyp heath" results in something weird. A "?2h" gets printed on the terminal, and ocassionally at some point in time (generally when you get to the bottom of the screen I think) the terminal becomes totally wedged. This has been noticed by me and several other members of the Theory Group for the last couple days.  Date: Fri, 20 Sep 85 12:40:25 EDT From: Gail Zacharias Subject: What fun! To: ALAN@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Wed 11 Sep 85 02:14:32 EDT from Alan Bawden Message-ID: <[MIT-MC.ARPA].652200.850920.GZ> There are servers on OZ, EE and XX. SPEECH is up to JTW I guess. The device will deduce Speech from SPxxxx, so you could add "SP" to the table. Right, OZKS: does KANSAS: so jobdev kansas can go if there is a space problem. I think I have the output problem fixed, so I guess I'm finished. Should I install it somewhere other than my dir?  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 SEP 85 13:59:59 EDT Date: 19 Sep 1985 13:28 EDT (Thu) Message-ID: From: Bill Rozas Subject: Gnu Emacs on ITS To: PGS%MIT-OZ@MIT-MC.ARPA Cc: BUG-ITS@MIT-MC.ARPA, "George J. Carrette" In-reply-to: Msg of 19 Sep 1985 10:34-EDT from PGS What about the pain of having to emulate BSD4.2 system calls?  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 SEP 85 12:32:14 EDT Date: Thu, 19 Sep 1985 10:34 EDT Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: "George J. Carrette" Cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of 18 Sep 1985 22:45-EDT from George J. Carrette Date: Wednesday, 18 September 1985 22:45-EDT From: George J. Carrette To: BUG-ITS at MIT-MC.ARPA cc: INFO-EXPLORER at MIT-MC.ARPA I wonder what GNU EMACS would be like used side-by-side with ITS EMACS? Is the C compiler on ITS up to it? I doubt that the address space on ITS is up to it, especially as the 10 C compiler doesn't do byte-packing.  Date: Wed, 18 Sep 85 22:45:51 EDT From: George J. Carrette To: BUG-ITS@MIT-MC.ARPA cc: INFO-EXPLORER@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].650277.850918.GJC> I wonder what GNU EMACS would be like used side-by-side with ITS EMACS? Is the C compiler on ITS up to it?  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 16 SEP 85 15:20:18 EDT Date: Mon, 16 Sep 1985 15:21 EDT Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: "Devon S. McCullough" Cc: BUG-ITS@MIT-MC.ARPA, BUG-TCTYP@MIT-MC.ARPA Subject: H-19 initialization In-reply-to: Msg of 16 Sep 1985 10:13-EDT from Devon S. McCullough Date: Monday, 16 September 1985 10:13-EDT From: Devon S. McCullough CRTSTY sends "[?2hEGOq\wy8y9y5x1" but TCTYP only sends "w" which is why CRTSTY will always win and TCTYP sometimes loses totally, because if the H19 was last used in ANSI mode you need to send [?2h which either clears ANSI mode or puts a "?2h" turd on the screen. My personal feeling is that you should $[?$h$33g$F the bastards and THEN see if they try $259o$[J$[K'ing with you again. Or, alternatively, why don't you just change the initialization string in TCTYP to what you feel is right?  Date: Mon, 16 Sep 85 10:13:03 EDT From: Devon S. McCullough Subject: H-19 initialization To: BUG-TCTYP@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].646431.850916.DEVON> CRTSTY sends "[?2hEGOq\wy8y9y5x1" but TCTYP only sends "w" which is why CRTSTY will always win and TCTYP sometimes loses totally, because if the H19 was last used in ANSI mode you need to send [?2h which either clears ANSI mode or puts a "?2h" turd on the screen. CRTSTY also clears "graphics" (hah!) mode, where lower-case letters produce strange glyphs on the screen. I think it would be fun to fix ITS so terminals with 128 different displayable codes can print them if %TOSAI is turned on. On H19's and VT52's this would produce the oddity that control characters would echo down-arrow instead of ^ before the uppercased character.  Date: Wed, 11 Sep 85 02:14:32 EDT From: Alan Bawden Subject: What fun! To: GZ@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].640776.850911.ALAN> The DEVICE directory was getting a bit full. The following three links seemed to form a pattern. L JOBDEV OZDNRF ==> DEVICE;JOBDEV OZ (7/18/85) GZ L JOBDEV OZKS ==> DEVICE;JOBDEV OZ (8/10/85) GZ L JOBDEV OZSS ==> DEVICE;JOBDEV OZ (8/13/85) GZ So I added OZ to the magic table in SYS:ATSIGN DEVICE so that -any- 4, 5, or 6, character device name that starts with "OZ" automatically loads DEVICE;JOBDEV OZ. (AI, MC, ML and DM were already in the table.) Then I deleted the links. There is also a link for a KANSAS: device. Can we do without this given that OZKS: works just as well? Should I add XX and EE? What about SPEECH? How close are you to having this thing really working? I haven't been able to use it to -write- a file yet, although I have been using it to read all kinds of things. (There don't seem to be many other people using the Emacs built on the long filename Teco, but it hasn't given me any problems at all. I guess once you think the device is "released" you can announce it together with the new Emacs. (I guess I should think about a long filename version of MacLisp...))  Date: Sat, 7 Sep 85 16:54:01 EDT From: Ken Harrenstien Subject: LOUIE looping To: BUG-MAIL@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].637052.850907.KLH> LOUIE.UDEL.EDU appears to be looping back mail for several lists, and giving us a bogus return-path to boot so that COMSAT error messages just add more loops. As a temporary measure I have put LOUIE in the LUZRS table for SYSBIN;FTPS BIN. This will cause all SMTP and FTP connection attempts from that host to be rejected. Obviously this is a desperation measure and a better remedy would be to add some smarts to COMSAT so that mail from there can be set aside for a while. I don't have the time right now for this. If someone is offended by the unilateral censorship they can just put a zero back in LUZRS.  Date: Fri, 6 Sep 85 04:08:06 EDT From: Glenn S. Burke Subject: parity errors To: log-service-call@MIT-XX.ARPA cc: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].635367.850906.GSB> MC's MH10 C was getting many parity errors, and has been shut off. DEC has been called (log # B90393) and will be checking in in the morning.  Date: Sun, 1 Sep 85 12:57:40 EDT From: Alan Bawden Subject: Feature To: DEVON@MIT-MC.ARPA cc: BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 31 Aug 85 18:00:59 EDT from Devon S. McCullough Message-ID: <[MIT-MC.ARPA].630167.850901.ALAN> Date: Sat, 31 Aug 85 18:00:59 EDT From: Devon S. McCullough ... By the way, how does the system know about sharable pure pages? If it knows that much why doesn't it know about binaries' filenames? It's because the concept of a "file" exists only at a higher level of abstraction than the level where page sharing is done. Sharing is done at the level of pages and disk blocks. A file is a name for a sequence of disk blocks, but there is no way to go backwards from a disk address to see which file (if any) it came from. (Other than mapping over the entire filesystem.) If there was some reason this operation needed to be done with great regularity, the information could be saved. But it is rare to want to do that, so we don't. (I actually have a tool that does it since I needed it once for debugging disk ECC recovery on AI. I think there might also be a routine in the version of the salvager that runs under timesharing that does it.)  Date: Sat, 31 Aug 85 18:00:59 EDT From: Devon S. McCullough Subject: Feature To: ALAN@MIT-MC.ARPA cc: BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 31 Aug 85 12:36:41 EDT from Alan Bawden Message-ID: <[MIT-MC.ARPA].629753.850831.DEVON> I was thinking that :SNARF could simply get the start address, etc, from the croaked DDT, but Alan's suggestion is better. By the way, how does the system know about sharable pure pages? If it knows that much why doesn't it know about binaries' filenames?  Date: Sat, 31 Aug 85 12:36:41 EDT From: Alan Bawden Subject: Feature To: DEVON@MIT-MC.ARPA, BUG-DDT@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 31 Aug 85 03:57:02 EDT from Devon S. McCullough Message-ID: <[MIT-MC.ARPA].629584.850831.ALAN> Date: Sat, 31 Aug 85 03:57:02 EDT From: Devon S. McCullough To: BUG-DDT at MC I snarfed an emacs from a hactro and tried to do G "no start address" I don't know if this is a DDT bug or an ITS bug. It isn't exactly anybody's bug. The start address of a program is treated just like the symbol table. It is stored in binary files for the benefit of people who load, start, and/or debug the program, but it is not kept anywhere in the job itself. ITS doesn't concern itself with where you think a job should be restarted. Now it -is- a little inconvenient that there is no way to go from a random job you find floating around the system back to its binary to find its symbols and starting address. So let me float a few suggestions through the air and see if anybody thinks they are a good idea: (1) Add a user variable that would contain a starting address. This would cover the common case that Devon complained about. (Happens to me all the time too.) (2) Add four user variables that would contain the filename of the binary for the this job. This would enable symbols to be found as well as the start address. (3) Add a user variable that contains the address of a block in the job's address space, in some extensible format we design later, that contains all kinds of information. Like a vector of start addresses, filenames of binary files, etc. (4) Since (3) requires cooperation from the job itself, but (1) covers the most common case, we could do both. One user variable containing a start address and one containing the address of a block of information (or zero if the job doesn't have one). Note that these are both 18 bit quantities, so this really only adds an extra word to every set of job variables. A problem with (3) and (4) is that the new info-block user variable seems somehow redundant with the existing use of the left half of .40ADDR. The 16.-word block addressed by LH(.40ADDR) is currently only used for temporary hacking by a job's superior; perhaps there is some way to combine the two? Perhaps one of the words addressed by RH(.40ADDR) can be the info-block pointer if the job sets some bit in .OPTION? I guess I'm in favor of at least (1) if not some variant of (4).  Date: Mon, 19 Aug 85 02:50:42 EDT From: Glenn S. Burke Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn" To: ALAN@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].617433.850819.GSB> Date: Sat, 17 Aug 85 22:30:43 EDT From: Alan Bawden Date: Fri, 16 Aug 85 17:06:59 EDT From: Glenn S. Burke I take it this was what you found printed on the system console? Yes. I had received a 'toplevel interrupt, tree detached' message. My hactrn was not stopped however.  Date: Sat, 17 Aug 85 22:30:43 EDT From: Alan Bawden Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn" To: GSB@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Fri 16 Aug 85 17:06:59 EDT from Glenn S. Burke Message-ID: <[MIT-MC.ARPA].616540.850817.ALAN> Date: Fri, 16 Aug 85 17:06:59 EDT From: Glenn S. Burke Re: "dialup line disconnected, detached job #75, usr:gsb hactrn" I take it this was what you found printed on the system console? huh? If it was disconnected why did i not have to request further service from the ROLM feature? That's pretty wierd all right. ITS should never do that unless you are on a tty line with %TYMDM set, and only T01 and T03 through T17 have that set in the current ITS. That bit -used- to be set for the Rolm lines, but that is no longer the case because MC wasn't finding out about hangups. Perhaps there is something more fundamentally wrong with the hangup detection code?  Date: Fri, 16 Aug 85 17:06:59 EDT From: Glenn S. Burke Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn" To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].615285.850816.GSB> huh? If it was disconnected why did i not have to request further service from the ROLM feature?  Date: Fri, 16 Aug 85 12:34:08 EDT From: Alan Bawden Subject: SOPEN To: GZ@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Mon 12 Aug 85 21:43:31 EDT from Gail Zacharias Message-ID: <[MIT-MC.ARPA].614889.850816.ALAN> Date: Mon, 12 Aug 85 21:43:31 EDT From: Gail Zacharias If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ REMIND instead. SOPEN parsed the string as "DSK:GZ;GZ >" since the trailing space fooled it into thinking that OMAIL was supposed to be another first filename. I fixed this problem in the source, I'll test it some time soon. (I also documented the fact that SOPEN defaults the device to "DSK" the second filename to ">" and the sname to the job's current sname.)  Date: Tue, 13 Aug 85 12:33:18 EDT From: Ed Schwalenberg Subject: MC TTY13 To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].610759.850813.ED> MC's TTY13 dialup is in a state where it recognizes carrier-detect and ^Z to mean "create a PWORD", but no typeout gets to the output buffer (according to OS), much less to the terminal. Gunning down the PWORD doesn't even produce a console free message.  Date: Tue, 13 Aug 85 06:28:39 EDT From: Christopher C. Stacy Subject: "TTY msg from " should read "TTY msg from @" To: DEVON@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA, bandy@LLL-CRG.ARPA In-reply-to: Msg of Mon 12 Aug 85 23:33:11 EDT from Devon S. McCullough Message-ID: <[MIT-MC.ARPA].610343.850813.CSTACY> Date: Mon, 12 Aug 85 23:33:11 EDT From: Devon S. McCullough To: BUG-ITS at MIT-MC.ARPA Re: "TTY msg from " should read "TTY msg from @" TTY msg from LLL-CRG.ARPA: bandy@lll-crg <- this is for mc's broken mailer ya see, mc is throwing away the data in the "send from". i don't throw away the data. mc is the only site on teh whole internet that supports sends that throws away that return-path data. so bitch at the smtp/sender maintainers there... ------------ This discussion belongs on BUG-MAIL; please edit BUG-ITS from the distribution of further messages (if any). I am surprised that there are still people at this time who are confused about the difference between a return path and a From field. The return path information given in the SMTP "SEND FROM" command is not equivalent to the "From" field in a message header. The return path is located on the ENVELOPE and the From field is located in the header portion of the mail DATA. RFC810 specifies: "The SEND command requires that the mail data be delivered to the user's terminal." (Note that although an SMTP module may add a field called Return-path in the header of a message it processes, this feature is a transmission relay trace intended for debugging.) The message recipient is not supposed to reply to the return path, which is not really intended for humans; rather, the return path is for use by SMTPs to generate error receipts. If other systems are using the return path in place of a header, then they are buggy. It might be a feature for MC's SMTP to retain the return path for the user, but if the message did not have a header it would still be buggy; personally, I think adding the return path to incoming sends clutters them up and wastes the reader's time. This is why most people's mail reading programs prune any return path fields in the header from the message display. It is definitely LLL-CRG which is violating protocol here. Chris PS. Early this year I reported this missing header bug to the TOPS-20 mail system maintainers (then on SU-SCORE). Their response was that they should be putting headers on their outgoing sends, and that their system was broken. I believe they fixed the bug, but I have since noticed that many TOPS-20 sites did not pick up this fix and have some old buggy SEND command. Apparently Unix is distrbuted with this bug too. Maybe this explains your perception about MC being the only site which "throws away" the data.  Date: Mon, 12 Aug 85 23:33:11 EDT From: Devon S. McCullough Subject: "TTY msg from " should read "TTY msg from @" To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].610043.850812.DEVON> TTY msg from LLL-CRG.ARPA: bandy@lll-crg <- this is for mc's broken mailer you said it. old its. there isn't anything more silly sometimes than its. it's not what everyone else does. that send saying it's my fault went to me. tee hee ^_ TTY msg from LLL-CRG.ARPA: bandy@lll-crg <- this was generated by hand it's mc that's throwing away data. sample conversation: helo lll-cr send from: rcpt to: data this is a send . quit ya see, mc is throwing away the data in the "send from". i don't throw away the data. mc is the only site on teh whole internet that supports sends that throws away that return-path data. so bitch at the smtp/sender maintainers there...  Date: Mon, 12 Aug 85 21:43:31 EDT From: Gail Zacharias Subject: SOPEN To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].609927.850812.GZ> If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ REMIND instead.  Date: Wed, 7 Aug 85 16:30:56 EDT From: David Vinayak Wallace Subject: AI net connection loses To: ALAN@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA In-reply-to: Msg of Tue 6 Aug 85 08:38:46 EDT from Alan Bawden Message-ID: <[MIT-MC.ARPA].604169.850807.GUMBY> Date: Tue, 6 Aug 85 08:38:46 EDT From: Alan Bawden Date: Tue, 6 Aug 85 06:51:19 EDT From: David Vinayak Wallace Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused? You are totally confused. When the hardware breaks, what do you expect the software to do? (It doesn't look to me like the problem is specific to AI anyway, it looks more like subnet 6 is broken somehow.) It wasn't clear to me from her message what had lost. And anyway, frequently when the hardware gets wedged resetting it causes it to start working again. From her description of the symptoms I guessed that perhaps something like that was happening.  Date: Tue, 6 Aug 85 08:38:46 EDT From: Alan Bawden Subject: AI net connection loses To: GUMBY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA In-reply-to: Msg of Tue 6 Aug 85 06:51:19 EDT from David Vinayak Wallace Message-ID: <[MIT-MC.ARPA].602230.850806.ALAN> Date: Tue, 6 Aug 85 06:51:19 EDT From: David Vinayak Wallace Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused? You are totally confused. When the hardware breaks, what do you expect the software to do? (It doesn't look to me like the problem is specific to AI anyway, it looks more like subnet 6 is broken somehow.)  Date: Tue, 6 Aug 85 06:51:19 EDT From: David Vinayak Wallace Subject: AI net connection loses To: BUG-ITS@MIT-MC.ARPA cc: CENT@MIT-MC.ARPA In-reply-to: Msg of Tue 6 Aug 85 05:04:47 EDT from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].602162.850806.GUMBY> Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?  Date: Tue, 6 Aug 85 05:04:47 EDT From: Pandora B. Berman Subject: AI net connection loses To: BUG-HARDWARE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].602119.850806.CENT> this morning i was using MC on my terminal. around 04:30 or so response got very slow, then a few minutes ceased altogether. AI had lost its net connection again, so i couldn't talk to MC, OZ, or anything else. someone please fix -- i can't work well with no terminal.  Date: Mon, 5 Aug 85 13:43:26 EDT From: J. Noel Chiappa Subject: Grumble, Don't-Reap is no sticky To: BUG-ITS@MIT-MC.ARPA cc: JNC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].601108.850805.JNC> I set the 'don't reap' bit on certain mailing list address list files (e.g. for MIT-IP-PEOPLE), since they don't get modified a lot and would otherwise have the potential to go offline (e.g. if the Trident controller breaks). However, if you modify the file and write it back out the 'don't reap' bit gets cleared! This is a lose... Noel  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 31 Jul 85 12:46:01 EDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286540; Wed 31-Jul-85 12:44:08-EDT Date: Wed, 31 Jul 85 12:45 EDT From: David C. Plummer in disguise Subject: It's definite - TOPS-20 loses! To: Ken Harrenstien , bug-its@MIT-MC.ARPA In-Reply-To: The message of 28 Jul 85 07:57-EDT from Ken Harrenstien Message-ID: <850731124518.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Sun 28 Jul 85 04:57:33-PDT From: Ken Harrenstien I was able to log both ends of a telnet connection (using TOPS-20 TN here, and the ITS datagram logger on MC) and captured an instance of the lossage. MC is sending a repacketized segment which TOPS-20 incorrectly treats as additional data. That is, MC's TCP sends off three separate segments, and then when no ACK is received it decides to retransmit, but is clever and lumps all the data together into a single segment which it then retransmits. This new segment has the proper sequence number (same as seq # of the original 1st segment). The data in this segment is exactly that data which is duplicated in TN's log file. The only possible explanation is that the TOPS-20 monitor's TCP code has a long-standing bug in it. It now occurs to me that I have seen this before when TN'ing to a VAX 4.2BSD system. I always blamed the BSD code for this, and other people claimed this was due to a bug in 4.2 server telnet, but somehow it never seemed to go away. Looks as if this was actually a TOPS-20 bug! I will pursue this with the appropriate people. Many too many implementations have the "Doesn't correctly handle overlapping segments" bug. The trickiest one is receiving a segment some of whose data has already been acknowledged and some whose is new. *sigh*  Date: Wed, 31 Jul 85 04:20:51 EDT From: Christopher C. Stacy Subject: response to old bug report of mine: TS3TTY absolved To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].594867.850731.CSTACY> Some time back I had reported a problem where when I first connected to MC, the first few characters of each line appeared to be garbage. This only happenned on dialup lines and would persist until I set the terminal type. It really looked like ITS had initialized my TTY to some wrong type -- the illegible graphics symbols appearing on my AAA screen were likely-looiking control codes or padding. I didn't want to believe that the TTY code was broken, and some other people asserted that my problem was not possibly the fault of ITS. Well, the other day I mentioned to my roomate that I was going to go take a look at TS3TTY and convince myself it could not possibly be broken. He responded by pouring over the AAA terminal documentation and frobbing the terminal, and finally located the real culprit. Apparently the AAA has this feature (which we had enabled) where you can turn some bit on if you desire the first few characters of each line to be trashed for you. So, this message is just a response for the record about that old bug report I filed. The ITS TTY code was *not* at fault.  Received: from SRI-NIC.ARPA by MIT-MC.ARPA 28 Jul 85 07:58:37 EDT Date: Sun 28 Jul 85 04:57:33-PDT From: Ken Harrenstien Subject: It's definite - TOPS-20 loses! To: bug-its@MIT-MC.ARPA cc: klh@SRI-NIC.ARPA I was able to log both ends of a telnet connection (using TOPS-20 TN here, and the ITS datagram logger on MC) and captured an instance of the lossage. MC is sending a repacketized segment which TOPS-20 incorrectly treats as additional data. That is, MC's TCP sends off three separate segments, and then when no ACK is received it decides to retransmit, but is clever and lumps all the data together into a single segment which it then retransmits. This new segment has the proper sequence number (same as seq # of the original 1st segment). The data in this segment is exactly that data which is duplicated in TN's log file. The only possible explanation is that the TOPS-20 monitor's TCP code has a long-standing bug in it. It now occurs to me that I have seen this before when TN'ing to a VAX 4.2BSD system. I always blamed the BSD code for this, and other people claimed this was due to a bug in 4.2 server telnet, but somehow it never seemed to go away. Looks as if this was actually a TOPS-20 bug! I will pursue this with the appropriate people. -------  Date: Sun, 28 Jul 85 07:07:01 EDT From: Ken Harrenstien Subject: RMAIL display problem - yet more data To: BUG-ITS@MIT-MC.ARPA, GSB@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].591010.850728.KLH> I was finally able to provoke this bug simply with DDT ^R typeout of a file -- conclusive proof that the problem does not lie with TECO, EMACS, or RMAIL. It is not reproducible however (doing another typeout will not lose in the same place, if at all).  Date: Sun, 28 Jul 85 06:58:50 EDT From: Ken Harrenstien Subject: RMAIL display problem - yet more data To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA, BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].590992.850728.KLH> Well, with considerable pain I was able to cause an example of this lossage while keeping a TCP datagram log. However, the log doesn't show what I expected; I was looking for the stretch of duplicated text that I observed, and couldn't find it. There are some retransmissions but they are all correct. Until GSB commented on the fact that the extra stuff seemed to be a duplicate of previous stuff, I hadn't noticed this attribute, but since then I've checked every instance and this appears to be always true. Something somewhere is being retransmitted or re-used. Since this happens with both CTN (CRTSTY SUPDUP) and TOPS-20 TN, it isn't a TOPS-20 user-program problem. Since the outgoing datagram log on MC shows no problems, the obvious deduction is that this looks like a TOPS-20 monitor problem. As it happens, the duplicated stuff does appear to correspond to a re-packetized TCP segment. More tests will be necessary to confirm this, however. This also implies that GSB's problem is actually something different from this one. Since he mentioned it happening with PEEK, I think we should confine further discussion to BUG-ITS and leave out BUG-RMAIL,TECO,EMACS unless more information turns up.  Date: Fri, 26 Jul 85 22:10:20 EDT From: Alan Bawden Subject: 7LP: and 7LR: To: INFO-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].589842.850726.ALAN> Remember the 7LP: device I advertised in this spot last winter? (I sends output to the LN01 printer on the 7th floor.) Well, I have just installed a 7LR: device for sending output to the new laserwriter (also on the 7th floor). While I was at it I gave both devices a new feature. They now support deletion so you can delete items from the queue. For example, if 7LP^F shows you the following: 7th floor ln01 is ready and printing Time Owner Job Files Size *21:55 alan 905 7LP: BAWDEN; B 249 49481 The most recent job printed was: 21:21 alan 7LP: BAWDEN; .FILE. (DIR) then you can delete job 905 by doing either ^O 7LP:905 or ^O 7LP:ALAN. In the later case all entries owned by ALAN are deleted. The second filename and directory are ignored.  Date: Thu, 25 Jul 85 16:39:03 EDT From: Alan Bawden Subject: Hardware To: TY@MIT-MC.ARPA, MYK@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA, F-S@MIT-OZ Message-ID: <[MIT-MC.ARPA].587801.850725.ALAN> The parity errors MC was getting today seem to be closely correlated to when the tape drive was being used. I don't know when DEC is coming back to fix the first memory box, but perhaps some diagnostics should be run to see if the tape drive and it's DF10 are functioning properly.  Date: Wed, 24 Jul 85 18:06:43 EDT From: Alan Bawden Subject: I thought we were more carefull than this... To: BUG-ITS@MIT-MC.ARPA cc: DANIEL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].586331.850724.ALAN> MC was unusable for most of today because DEC brought up the machine with the T-300's write-protected. ITS should really say something more explicit when this happens than "T300 ERR ... STATUS = 1 ...".  Date: Tue, 23 Jul 85 22:37:28 EDT From: Glenn S. Burke Subject: re: RMAIL display problem To: KLH@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA, BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].586008.850723.GSB> I cam make it happen with peek on a 60 high 118 wide screen, just like i can with rmail. looks like the cursor positioning goes bonkers as a function of me typing at it.  Date: Mon, 22 Jul 85 18:06:15 EDT From: Glenn S. Burke Subject: re: RMAIL display problem -- you'll like this To: KLH@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA, BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].584681.850722.GSB> right here in the privacy of my own office, i can reproduce this, freeze the screen, and get a hardcopy of the lossage. Isn't VMS wonderful?  Date: Mon, 22 Jul 85 13:30:54 EDT From: Ken Harrenstien Subject: RMAIL display problem To: KLH@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA, BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].584298.850722.KLH> Some additional data which supports the theory that a user-program or ITS TTY bug may be involved: Date: Thu, 18 Jul 85 22:40:40 EDT From: Glenn S. Burke Subject: RMAIL display problem To: KLH@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].581085.850718.GSB> All the times i have seen such an error i have been able to find duplicated text on the screen and the supposition was that it was a duplicated tcp packet or something like that. I have seen this both internetting from ru-net to here (from a 20) and i believe just within rutgers (tops-20 -> tops-20 just on ru-net). ---------------------- Date: Fri, 19 Jul 85 23:45:04 EDT From: Glenn S. Burke Subject: tty lossage To: KLH@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].582348.850719.GSB> well maybe i should take back what i said last night. I'm coming from a microvax vaxstation running a vt100 emulator window, running decnet to a 750 (corwin) from whence i'm doing chaosnet supdup to mc. The window size is 94 wide by 55 high [i TOLD it 96 wide at this end, you know how these things are...] anyway, i have a two screen long (at this screen size) message, and if i have it redisplay the first and get a space (in rmail, go to next screen) before it finishes, it invariably fucks up. anyway, there ain't no tcp in THIS network path.  Received: from MIT-XX.ARPA by MIT-MC.ARPA 19 Jul 85 11:41:37 EDT Date: Fri 19 Jul 85 11:43:49-EDT From: "J. Noel Chiappa" Subject: Re: memory woes To: ALAN@MIT-MC.ARPA, CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Alan Bawden " of Fri 19 Jul 85 08:34:10-EDT Ty was having parity error in some module of one sector. He replaced that module and got the exact same error in the exact same place (he said). He thought that was suspicious, and decided to swap the parity controllers to see if the problem moved with the controller. It didn't. Ask him for more details. -------  Date: Fri, 19 Jul 85 08:33:23 EDT From: Alan Bawden To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Thu 18 Jul 85 19:03:04 EDT from Christopher C. Stacy Message-ID: <[MIT-MC.ARPA].581459.850719.ALAN> Date: Thu, 18 Jul 85 19:03:04 EDT From: Christopher C. Stacy Why does ITS think it has been up all year? I guess somebody told MC it was 1984 when they first brought it up.  Date: Fri, 19 Jul 85 08:31:13 EDT From: Alan Bawden Subject: memory woes To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Fri 19 Jul 85 07:00:43 EDT from Christopher C. Stacy Message-ID: <[MIT-MC.ARPA].581458.850719.ALAN> Date: Fri, 19 Jul 85 07:00:43 EDT From: Christopher C. Stacy unusable, so I deselected sector 1 where they were happenning (bank 3). Then they appeared to move to sector 0. I deselected sector 0 too. I presume you remembered to turn interleaving off when you deselected sector 1. If things seem to work well for a while today, someone might want to turn sector 1 back on and see if the errors move around. We are down alot of memory at this point. I heard something about an Ampex parity detection module being replaced when DEC was frobbing the machine to replace a core stack in one of their memories. This wasn't DEC, it was TY I believe. I think JNC can tell you about it as well.  Date: Fri, 19 Jul 85 07:00:43 EDT From: Christopher C. Stacy Subject: memory woes To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].581432.850719.CSTACY> The Ampex was getting enough parity errors to render the system unusable, so I deselected sector 1 where they were happenning (bank 3). Then they appeared to move to sector 0. I deselected sector 0 too. If things seem to work well for a while today, someone might want to turn sector 1 back on and see if the errors move around. We are down alot of memory at this point. I heard something about an Ampex parity detection module being replaced when DEC was frobbing the machine to replace a core stack in one of their memories. What's the scoop latest on the hardware?  Date: Thu, 18 Jul 85 19:03:04 EDT From: Christopher C. Stacy To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].580878.850718.CSTACY> Why does ITS think it has been up all year?  Date: Thu, 18 Jul 85 05:55:23 EDT From: Ken Harrenstien Subject: RMAIL display problem To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA, BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].580138.850718.KLH> I'm not sure where the fault for this one might be, hence the shotgun message. In RMAIL, when using "space" to step through successive screenfuls of a long message, sometimes output fails to stop at the mode line; it continues for several more lines and runs right off the bottom of the screen, causing the terminal to either scroll or wrap up to the top (depending on one's terminal). The screen is then permanently messed up until a complete redisplay is forced with ^L. This happens for me when connected to MC either via SUPDUP (ie as a software TTY) or via TELNET with a :TCTYP DM2500 declaration. At first I thought it might be a CRTSTY/SUPDUP problem, but my TELNET experiments have convinced me that it really is MC's fault. However, I haven't been able to find a foolproof way of reproducing the lossage. All I can say is that in the course of reading through several SF-LOVERS digests on a 24x79 screen, this bug almost always crops up someplace, sometimes twice or thrice in a row. I type: N E ^K ^X r ; to invoke RMAIL d ; for each message This is probably a TECO bug of some variety, but there's an off chance it might be an ITS TTY handling bug. It's even possible that some EMACS code is screwing up the redisplay. This has happened for quite a while (several months). I hope someone else has a notion of what to look for at this point. If necessary, I could try again to save a reproducible instance of this, although it is a rather painful task.  Date: Fri, 12 Jul 85 09:13:59 EDT From: Alan Bawden Subject: crtsty lossage. To: BUG-CRTSTY@MIT-MC.ARPA cc: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA In-reply-to: Msg of Fri 12 Jul 85 02:18:26 EDT from Christopher C. Stacy Message-ID: <[MIT-MC.ARPA].573277.850712.ALAN> I renamed SYSBIN;CRTSTY OBIN => CRTSTY BIN => CRTSTY XBIN. I presume the behavior we were observing was something that KLH introduced when he assembled CRTSTY yesterday. BTW, I notice there is a link from TS NCRTSTY to SYSBIN;CRTSTY NBIN, which despite its name is a year older than any other version. Is there a reason for this?  Date: Fri, 12 Jul 85 02:18:26 EDT From: Christopher C. Stacy Subject: crtsty lossage? To: BUG-CRTSTY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, CENT@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].572965.850712.CSTACY> I just dumped a dead CRTSTY into CRASH;CRTSTY VT100. This was EAK CRTSTY, (.VALUE;IOCH7;) 70110>>SKIPGE @413 130624/ 4,,27000 I guess it got a fatal interrupt, but I don't know anything about this program. There were n of these guys lying around, all stopped in the same way.  Date: Fri, 12 Jul 85 00:56:15 EDT From: Pandora B. Berman Subject: crtsty lossage? To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].572909.850712.CENT> something's wrong. over the past several hours i have found half a dozen CRTSTYs disowned with .VALUE 200. also several ___###s disowned. i can only tell from what i see in PEEK; someone who knows more should check this.  Received: from MIT-XX.ARPA by MIT-MC.ARPA.ARPA; 10 Jul 85 23:20:03 EDT Date: Wed 10 Jul 85 23:21:13-EDT From: "J. Noel Chiappa" Subject: Re: level2 bughalt To: DANIEL@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "Daniel Weise " of Sun 7 Jul 85 17:07:05-EDT Well, the TARAKA DMPCPY business is a daemon copying the dump from the swapping area (where DDTDSK put it) into the real file system. The file seems to have gone into the directory '.' rather than 'CRASH'; '.' is the default directory used by DDTDSK. Noel -------  Date: Mon, 8 Jul 85 14:54:11 EDT From: Jonathan D. Taft To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].567927.850708.TAFT> DSK:UNIT 1 LOSING.RH CONI BITS= 1,,157236 Dumped to CRASH;UNIT1 LOSING  Date: Sun, 7 Jul 85 17:05:05 EDT From: Daniel Weise Subject: level2 bughalt To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].566858.850707.DANIEL> MC wedged itself again this afternoon. I took crash dump to CRASH LEVEL2 and warm booted. But during warm boot it printed something like TARAKA DMPCPY . CRASH LEVEL2 DELRNM (MC's vt52 is missing so I am typing this in from memory). When I looked for crash;crash level2 the file wasn't there. What did I do wrong? Daniel  Date: Fri, 5 Jul 85 00:41:26 EDT From: David A. Moon Subject: Re: IMP down detection To: JNC@MIT-XX.ARPA cc: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].565142.850705.MOON> Date: Mon 24 Jun 85 17:54:25-EDT From: "J. Noel Chiappa" I think that it's a known bug with the IMP code that if the IMP cycles after ITS is up ITS doesn't deal with that correctly. It used to work. Maybe I broke it when I removed support for NCP protocol a few years ago.  Date: Fri, 5 Jul 85 00:07:06 EDT From: David A. Moon Subject: oh, yeah To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].565121.850705.MOON> Date: Mon, 1 Jul 85 17:20:31 EDT From: Christopher C. Stacy It is probably a bug that ITS refuses all Chaosnet service when it is being debugged. There is a feature in NETWRK for doing this in the Chaosnet specific code. SYSDBG is maybe not quite fine-grain enough? Also, should move TCPUSW and TCPUP to be near NETUSW, etc. Yeah, probably it should assume NETUSW is good enough.  Date: Mon, 1 Jul 85 23:53:18 EDT From: Glenn S. Burke Sender: GSB5@MIT-MC.ARPA Subject: crash To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].562107.850701.GSB5> crash;ucprl5 +1  Received: from MIT-XX.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 23:11:38 EDT Date: Mon 1 Jul 85 23:12:42-EDT From: "J. Noel Chiappa" Subject: Re: crashdump To: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Alan Bawden " of Sat 29 Jun 85 05:43:22-EDT I'm dubious about this being a side effect of DEC playing around. The exact thing DEC did involved no frobbing with cables at all; all the did was disable some of the ports the processor was using to reference memory. (I was supposed to explain all this but forgot). What they did was notice that we are running the machine in two way interleave. Exactly why we are doing this is too long to explain here, and I think Dave Moon did so once already. This being the case, they decided that we would be less likely to have 'interference' on the memories if we diabled KBUS2 and KBUS3 (which are after all duplicates of KBUS0 and KBUS1 in two way interleave). I'm not sure I believe this, but I do believe that it can't hurt and I didn't feel like arguing with the DEC guy about it, so I let them do it. (Actually, they disabled the memory ports to those busses, not the busses.) However, the DF10 has it's own memory bus and port, and should not have been affected. It's probably a flaky caused by all the power cycling in the last week. Noel -------  Date: Mon, 1 Jul 85 21:00:22 EDT From: Devon S. McCullough To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].561917.850701.DEVON> I snarfed an E job when I already had one (to see what I could see) and it renamed it E!!!!! well that's okay, but wouldn't E! or E0 have done?  Date: Mon, 1 Jul 85 17:20:31 EDT From: Christopher C. Stacy Subject: oh, yeah To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].561691.850701.CSTACY> It is probably a bug that ITS refuses all Chaosnet service when it is being debugged. There is a feature in NETWRK for doing this in the Chaosnet specific code. SYSDBG is maybe not quite fine-grain enough? Also, should move TCPUSW and TCPUP to be near NETUSW, etc.  Date: Sat, 29 Jun 85 05:41:16 EDT From: Alan Bawden Subject: crashdump To: GSB@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 29 Jun 85 02:39:48 EDT from Glenn S. Burke Message-ID: <[MIT-MC.ARPA].559587.850629.ALAN> Date: Sat, 29 Jun 85 02:39:48 EDT From: Glenn S. Burke crash;unit-0 lost The DF10 got a NXM. I suspect this is an artifact of the way DEC reconfigured the memory last Wednesday. Would we rather have the parity errors back? Damn machine.  Date: Sat, 29 Jun 85 02:39:48 EDT From: Glenn S. Burke Sender: GSB5@MIT-MC.ARPA Subject: crashdump To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].559506.850629.GSB5> crash;unit-0 lost  Date: Wed, 26 Jun 85 22:01:16 EDT From: Alan Bawden Subject: MC up again with all 6 disks. To: TY@MIT-MC.ARPA, Sollins@MIT-XX.ARPA, Finn@MIT-XX.ARPA cc: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].557107.850626.ALAN> JNC and I swapped the packs in unit 3 and 4 on MC (the rightmost two T-300's) and the disk problems we were experiencing vanished. Perhaps there is some marginal interaction between drives and packs formatted with different alignments? If so, I guess there is some hope that things will clear up after duplicating those packs tomorrow. BUG-ITS: For the record: Earlier today JNC and TY brought MC up with -none- of the T-300's because they believed them all to be broken. They were given this impression when UCOP got an error copying some user directories. In fact, it has been true for a long time that there are bad blocks amoung the directories on those packs, but since we don't really need those extra copies of the directories this is OK. UCOP copies the MFD -first-, and if it gets that far, that is good enough!  Date: Tue, 25 Jun 85 01:50:24 EDT From: David A. Moon Sender: CENT@MIT-MC.ARPA Subject: Addition to mailing list To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: BUG-ITS@MIT-MC.ARPA, ks-its@MIT-AI.ARPA Message-ID: <[MIT-MC.ARPA].554803.850625.CENT> Date: 23 Jun 85 20:11 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Everybody here is waiting for the system to run, all of the hackers in Stockholm that have heard of ITS is lyric. I have started the work on planing howto actualy change the KA hardware, i want to have the posibility to run as much of the DEC diagnostics as possible. So some type of switch-selectable aproach is prefered, but it is no simple. In a month or so we shall try to have the two KI-10 Cpu:s running SMP with T10 7.02. We plan to use this system to assemble the ITS code. ( Are you sure you can deal with that volume of mail? I don't think anyone will mind your being on them if you don't mind. ) Pls try to add: ITS_bugs%QZCOM.MAILNET@MIT-MULTICS.ARPA in both ITS bugs and ITS on ks20. I have done so. Will report as soon there is any sucsess. We eagerly await your report. The box of tapes, processor prints, and documentation is sitting right next to me, thanks to a lot of work by Penny Berman.  Received: from MIT-XX.ARPA by MIT-MC.ARPA 24 Jun 85 17:55:25 EST Date: Mon 24 Jun 85 17:54:25-EDT From: "J. Noel Chiappa" Subject: Re: IMP down detection To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Mon 24 Jun 85 16:10:43-EDT I think that it's a known bug with the IMP code that if the IMP cycles after ITS is up ITS doesn't deal with that correctly. -------  Date: Mon, 24 Jun 85 16:10:35 EDT From: Christopher C. Stacy Subject: IMP down detection To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].554168.850624.CSTACY> At some point today, ITS decided the IMP was down. It never noticed it coming back up, and thought it was waiting for the ready line to flap. I ran LOCK and it reset everything.  Received: from MIT-XX.ARPA by MIT-MC.ARPA 21 Jun 85 15:05:13 EST Date: Fri 21 Jun 85 15:03:48-EDT From: "J. Noel Chiappa" Subject: MC disk flakoes To: bug-its@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA John Holden came and looked at the Tridents and pronounced them all OK. Two needed touch ups to the alignment, but nothing major. He says that it was probably the cables, which are known to be flaky. Since he had to remove the cables to run the exerciser, he thinks that he may have frobbed them in the right way to make the problems go away. Things do seem to be working a bit better. We'll see. -------  Date: Thu, 20 Jun 85 21:11:48 EDT From: David Vinayak Wallace Subject: more re: mc was wedged this afternoon. To: DANIEL@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Thu 20 Jun 85 12:12:00 EDT from Daniel Weise Message-ID: <[MIT-MC.ARPA].550546.850620.GUMBY> Date: Thu, 20 Jun 85 12:12:00 EDT From: Daniel Weise Claimed no net ports when only 4 people were logged in. Console only echoed my typein but did nothin wit it. Tried warm booting. THat failed. Took crash dump to CRASH SAME and cold booted. More bits: trying to open a STY gave DEVICE FULL, which is weird. I've seen the same thing when MC couldn't get to its tridents.  Date: Thu, 20 Jun 85 12:12:00 EDT From: Daniel Weise Subject: mc was wedged this afternoon. To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].550424.850620.DANIEL> Claimed no net ports when only 4 people were logged in. Console only echoed my typein but did nothin wit it. Tried warm booting. THat failed. Took crash dump to CRASH SAME and cold booted. Daniel  Date: Sun, 16 Jun 85 20:29:08 EDT From: Alan Bawden Subject: mc needed cold booting this afternoon. To: DANIEL@MIT-MC, JGA@MIT-MC cc: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].544997.850616.ALAN> Date: Sat, 15 Jun 85 14:05:26 EDT From: Daniel Weise MC was really wedged this afternoon. Every minute it kept typing system full, 0 pages, 0 qsk channels, etc. No user jobs able to run. Warm booting didn't help so I took a dump to CRASH FULL and cold-booted, which seems to have fixed things. Well, the crash dump shows an ITS that has been up for 5 minutes and is having trouble initializing the first T-300. So I guess this is the canonical T-300 controller lossage. Date: Sat, 15 Jun 1985 12:04 EDT From: JGA at OZ A little bit more on the recent lossage I mentioned earlier... I was logged in when RHB got wedged. Running Peek, I could see that his job and several others were sitting there with a state of "*logout", whatever that means. Peek could not gun his tree, nor could Lock. A state of "LOGOUT" (the "*" is irrelevant really) means that the job was already on its way towords going away. (Thats why gunning it didn't do anything, it was already as gunned as it could get.) Without a crash dump, or an actual wedged system, I can only guess that this is another symptom of the T-300 lossage.  Date: Sun, 16 Jun 85 20:26:35 EDT From: Alan Bawden Subject: CHTN lossage To: JNC@MIT-MC cc: BUG-ITS@MIT-MC In-reply-to: Msg of Fri 14 Jun 85 18:52:47 EDT from J. Noel Chiappa Message-ID: <[MIT-MC].544988.850616.ALAN> Date: Fri, 14 Jun 85 18:52:47 EDT From: J. Noel Chiappa Recently I have been noticing that when XX goes down, my CHTN hangs and nothing the world seems to get me out, until it decides to timeout the connection. ANyone know why? Yeah, I've noticed this too. It's not new, its been happening for years. Just looking at the code I can't figure out how it can happen. (Note that this is probably just a bug in CHTN; you take the risk of having bugs like this when you go into super image input mode...)  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 JUN 85 14:15:18 EDT Date: Sat, 15 Jun 1985 12:10 EDT Message-ID: From: JGA%MIT-OZ@MIT-MC.ARPA To: bug-its@MIT-MC Subject: weird wedgitude - part IIa One more note - a finger of MC from OZ shows the dead HACTRNs sitting there with " STY not in use" where the ttyloc usually goes in the finger display.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 JUN 85 14:15:17 EDT Date: Sat, 15 Jun 1985 12:04 EDT Message-ID: From: JGA%MIT-OZ@MIT-MC.ARPA To: bug-its@MIT-MC Subject: weird wegitude, part II A little bit more on the recent lossage I mentioned earlier... I was logged in when RHB got wedged. Running Peek, I could see that his job and several others were sitting there with a state of "*logout", whatever that means. Peek could not gun his tree, nor could Lock. There were several different HACTRNs sitting around in this state, which explains the lack of net ports I guess, as well as whole bunch of lispm file jobs. I don't know enough about lispm file jobs to tell whether these were normal or not. About two minutes later my tty got wedged, and I can't log back in because of no net ports, so that's why I'm sending this from OZ.  Date: Sat, 15 Jun 85 14:05:26 EDT From: Daniel Weise Subject: mc needed cold booting this afternoon. To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].543663.850615.DANIEL> MC was really wedged this afternoon. Every minute it kept typing system full, 0 pages, 0 qsk channels, etc. No user jobs able to run. Warm booting didn't help so I took a dump to CRASH FULL and cold-booted, which seems to have fixed things. Daniel  Date: Fri, 14 Jun 85 18:52:47 EDT From: J. Noel Chiappa Subject: CHTN lossage To: BUG-ITS@MIT-MC.ARPA cc: JNC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].543165.850614.JNC> Recently I have been noticing that when XX goes down, my CHTN hangs and nothing the world seems to get me out, until it decides to timeout the connection. ANyone know why?  Date: Thu, 13 Jun 85 17:25:50 EDT From: Robert H. Berman Subject: intermittent login probelm To: JGA@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].541730.850613.RHB> Same thing happened to me today too. (around 4:30-5:30 PM) I got about half-way in my login file and the tterminal hung. tried loggin in several times in a row with no success. Finally logged in and everything has been ok since.  Date: Thu, 13 Jun 85 11:23:45 EDT From: John G. Aspinall Subject: wierd wegitude To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].541202.850613.JGA> I'm having an intermittent problem of the terminal getting wedged when I log in. The symptoms are as follows. Pword runs ok, and my login file starts executing. At some point, either as the login file ends, or at a point most of the way through it where I have a :more query about whether to run babyl or not, almost all response to typed characters stops. The only characters that cause a response are ctrl-G and rubout which provoke their usual behaviour. My login file has not been changed in months. Other people logging in from the same concentrator (NPLASMA) have not seen the problem. I get the problem four or five times in a row, then everything is fine again. John.  Received: from THINK.ARPA by MIT-MC.ARPA 11 Jun 85 16:58:04 EST Received: by THINK.ARPA with CHAOS id AA28106; Tue, 11 Jun 85 16:52:46 edt Date: Tuesday, 11 June 1985, 16:54-EDT From: Guy Steele Subject: STINK To: KLH@MIT-MC.ARPA, BUG-ITS@MC Cc: gls@THINK.ARPA In-Reply-To: <[MIT-MC.ARPA].538066.850611.KLH> Message-Id: <850611165410.6.GLS@ROCK.ARPA> Hurray! I simply don't know what to think Of this late resurrection of STINK, Once thought lost, at the last, In the mists of the past Like its sibling, the famed missing link. --Guy  Date: Tue, 11 Jun 85 05:36:46 EDT From: Ken Harrenstien Subject: STINK To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].538066.850611.KLH> You may find this news hard to believe. As you may recall, the source for STINK didn't assemble properly, and had a higher version number than the (presumably working) binary. The true source, if it ever existed, has been lost in the distant fires of ITS dump tapes being burned at the stake. I was thinking about a possible hack which at some point might require the services of STINK. Never mind what it is. The problem as I saw it was not the fact that STINK is unique and unsupported, but the fact that STINK could not be supported without a real source. So I made a half-hearted attempt to investigate by comparing the (faulty) result of an assembly with the existing binary, using SRCCOM's /$ switch. Boy, am I glad I put that hack into SRCCOM. The comparison much to my surprise showed the binaries were virtually identical, except for one changed label and a couple of missing symbols. It only took a few minutes to fix those and come up with a source that assembles into exactly the same thing (modulo .FNAM2) as the old TS STINK! Anyway, I wrote out this new source as STINK 200, and installed a new TS STINK. STINK lives again! (phew)  Date: Thu, 6 Jun 85 18:11:40 EST From: Chris Hanson To: BUG-SYSTEM@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].533331.850606.CPH> Why do I have to give a password when I supdup over from OZ? What kind of bullshit is this?  Date: Thu, 30 May 85 15:06:41 EST From: Alan Bawden Subject: All network ports in use To: GUMBY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Thu 30 May 85 14:25:10 EST from David Vinayak Wallace Message-ID: <[MIT-MC.ARPA].524704.850530.ALAN> Date: Thu, 30 May 85 14:25:10 EST From: David Vinayak Wallace Every once in a while I am unable to connect to MC via chaos; I open a connexion and MC says "All network ports in use." This is repeatable for about a minute or so, then I get a ddt. loadp shows 11 free net ports. I fixed a bug that used to cause something like this to happen a while ago. A new ITS for MC has not been assembled since then.  Date: Thu, 30 May 85 14:25:10 EST From: David Vinayak Wallace Subject: All network ports in use To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].524623.850530.GUMBY> Every once in a while I am unable to connect to MC via chaos; I open a connexion and MC says "All network ports in use." This is repeatable for about a minute or so, then I get a ddt. loadp shows 11 free net ports. What gives?  Date: Thu, 30 May 85 09:16:15 EST From: Christopher C. Stacy Subject: T-300s inaccessible To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].524200.850530.CSTACY> MC's T-300 disk controller was powered off somehow, although the PDP11 and other frobs in the same rack were still on. I power cycled it and reloaded the system to get things going again.  Date: Wed, 29 May 85 15:52:32 EST From: Alan Bawden Subject: Most puzzling... To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].523215.850529.ALAN> Typical MC crash today: MC BUGHLT's with an MUUO in exec mode (see apparently typical example in CRASH;CRASH MUUO'). After L XITS G The salvager does -not- print its usual greeting, nor is anything else printed on the system console. However, if you raise switch 0, ITS will stop just as if it was running normally (see example in CRASH;CRASH NOSALV). Now doing L XITS G again will aparently work, except that the system will hang trying to get to unit 3 and you will need to try again after running BOOT11. (Note that something similar to this must have happened to Gumby the other day, except after a different initial crash...)  Date: Wed, 29 May 85 02:52:25 EST From: Tim McNerney Subject: Yow! I am reliable yet? To: BUG-ITS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].522693.850529.TIM> The time is 02:46:34 EDT. Today is Wednesday, the 29th of May, 1985. MC ITS 1488 has run for 103 days, 2 hours, 13 minutes, 32 seconds. Surpassing all previous MC records for uptime! System last revived 1 day, 2 hours, 12 minutes, 33 seconds ago.  Date: Sun, 26 May 85 03:01:18 EST From: David Vinayak Wallace Subject: latest crash To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].518640.850526.GUMBY> I came in and MC was down; I looked at the pc; couldn't figure out what happened so saved it in crash;crash gmmpp (it died at gmmpp+3). I loaded a new xits, but the salvager never ran. I halted it with switch 0 and reloaded from scratch.  Date: Sat, 25 May 85 21:28:34 EST From: Christopher C. Stacy Subject: AI COMSAT down for the count. To: CENT@MIT-MC cc: BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, DCB@MIT-MC, TAFT@MIT-MC, ALAN@MIT-MC In-reply-to: Msg of Sat 25 May 85 01:19:30 EST from Pandora B. Berman Message-ID: <[MIT-MC].518526.850525.CSTACY> This was because COMSAT assumes that the DEAD-MAIL-RECEIPTS list always exists, but I forgot to create it in NAMES >. I convinced the COMSAT on AI to gobble the latest NAMES before trying to unqueue anything, things are back to normal now, and I re-installed the mailer on AI. Under certain conditions (such as fatal interrupts) AUTPSY comes out empty. COMSAT was probably dying with PDL overflows or something. (BTW, I already fixed the other unrelated looping bug which ALAN reported last week.)  Date: Sat, 25 May 85 01:19:30 EST From: Pandora B. Berman Subject: AI COMSAT down for the count. To: BUG-MAIL@MIT-MC cc: BUG-ITS@MIT-MC, DCB@MIT-MC, TAFT@MIT-MC Message-ID: <[MIT-MC].517969.850525.CENT> AI's COMSAT is stuck in a deadly loop. whenever it is launched, it first, of course, tries to cut down on the queued msgs by sending one of them. trouble is, the single one in its queue is to BUG-INQUIR@MC (alias CSTACY) and COMSAT thinks it's from DEAD-MAIL-RECEIPTS@AI. so after sending it (it does get through, each time; cstacy now has several of these in his mail) COMSAT tries to give a CMSG to DEAD-MAIL-RECEIPTS@AI. there is no such address, so COMSAT says ::=. then it tries to CMSG again to the same address. after several times, it dies after just saying CMSG. BURNUP 1 was the first corpse dumped by this process. BURNUP 8 is the latest of several all of the same size (each died after only this work on the queue, while #1 included previous activity). I tried writing a new NAMES > with the guilty address eqv'd to NUL:, as it is on MC; COMSAT did not try to compile this before working on the queued mail. BURNUP 9 is COMSAT dying after i renamed LIST EQV (the bin of NAMES >) to something else; again, COMSAT did not look for the names database before hacking the queued mail. this is a gross bug and should be fixed; if there is no names database, maybe it's for a good reason, like the previous one is fuckt and someone wants comsat to pick up the new (hopefully cured) version. BURNUP 10 is from another experiment: i tried renaming LISTS MSGS to something else, COMSAT looked for NMSGS, found none, and died. alan and moon tried to debug this over the phone, but couldn't get enough data (AUTPSY kept containing 0 !). i have renamed AI:COMSAT LAUNCH to COMSAT BRUNCH. ai now has enough pieces of mail that it won't accept any more from outside. COMSAT should not be relaunched on AI until someone fixes this.  Date: Mon, 20 May 85 03:54:02 EST From: Pandora B. Berman Subject: forwarding... someone forgot to hang up? To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].510876.850520.CENT> Date: Fri, 17 May 85 22:29:22 EST From: Robyn D. Spencer To: BUG-ROLM@MIT-MC Message-ID: <[MIT-MC].509023.850517.TOOTSE> bug-its I (mason) just connected to mc through a rolm and found myself logged in as tootse, as a mail notification popped up. I just thought someone would like to know. mark  Date: Wed, 15 May 85 20:08:30 EST From: David A. Moon Subject: MC crashes when you read AI backup tapes To: CENT@MIT-MC, MOON@MIT-MC cc: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].505155.850515.MOON5> I wasn't able to figure out the problem in detail, but I did edit a bug trap into the source at MGRD2. Sometime you should exhibit the problem with me physically present and I'll patch in this bug trap and see if it goes off.  Date: Wed, 15 May 85 00:52:40 EST From: Pandora B. Berman Subject: patch for crufty ai tapes makes mc die horribly? To: MOON@MIT-MC cc: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].503776.850515.CENT> i was trying to read some old AI tapes. they got errors, so with glenn's advice i installed your patch: MOON5@MIT-ML 06/30/84 03:54:39 To: GSB at MIT-ML, CENT at MIT-ML fyi the location to patch to disable tape read errors in ITS is MGMRT+1 which is changd from JRST MGERR to JRST MGRD2. It still tries a few times to retry errors but if it gets a fatal error it gives you whatever shitty data it got instead of barfing.. ^_ then tried again with the tape. dump worked on tape a short while, with some hiccupping and one reported error, then system died. crash dump in CRASH IMRQ8. alan poked around at the code and thinks that possibly the patch is fucking up the MEMBLT table...  Date: Mon, 13 May 85 18:54:28 EST From: Glenn S. Burke Sender: GSB5@MIT-MC Subject: bugpause: tty: buffer empty at tyirem To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].501533.850513.GSB5> CRASH;TYIREM NOBUFF  Date: Fri, 10 May 85 12:50:00 EST From: Kent M Pitman To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].495319.850510.KMP> MC has a pile of jobs which have PARERR'd out. Several dead COMSATs, etc. Someone might want to look at this.  Date: Fri, 10 May 85 04:44:57 EST From: Glenn S. Burke Subject: wedgitude To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].494815.850510.GSB> CRASH;WEDGED AGAIN is an example of this evening's wedgitude, dumped after being stopped by switch 0.  Received: from MIT-AI by MIT-MC via Chaosnet; 10 MAY 85 01:27:09 EDT Date: Fri, 10 May 85 00:39:42 EST From: J. Noel Chiappa Subject: Zapppp! To: BUG-its@MIT-MC cc: JNC@MIT-AI Message-ID: <[MIT-AI].590.850510.JNC> There was some breeze-shooting on the subject of speeding up the DZ output interrupt service routines which I thought I'd note down. Since a 9600 baud line running flat out generates 1000 interrupts/second, and the output ISR looks quite long at the moment, a few lines running flat out will probably bring the machine to its knees. The theory is that we should implement efficient block mode output; i.e. the driver emulates a DMA device and takes big chunks of data each time ITS talks to it. We should blow some of the extra register sets that we have, one per DZ. 8 of the registers would be used for things like holding a pointer to the registers, etc, and temps, and the other 8 would be pointers to output buffers. The pointers would probably be AOBJN style pointers, with the data uppacked one byte per word. (We can't use byte pointers because there isn't any room for a count if so and there aren't enough registers to have counts too, unless we restrict ourselves to 4 general registers and keep the counts in halfwords.) At that point, the output ISR would be about 10 instructions long: OPBASE = 6 ;Base of AOBJN pointer block in regs IORDI A,%DZRCS(D) ;Get CSR TRNN A,%DZCTR ;Transmitter ready? JRST LOSE ;No, spurious interrupt LDB A,[.BP %DZLM,A] ;Get line number MOVE T,OPBASE(A) ;Get AOBJN pointer for that line MOVE TT,(T) ;Pick up data IOWRI TT,%DZRTD(D) ;Write it out AOBJP T,DONE ;All done yet? MOVEM T,OPBASE(A) ;Put updated pointer back JRST 12,@TTYBRK ;Dismiss Or something like that, anyway.  Date: Thu, 9 May 85 21:00:50 EST From: Alan Bawden Subject: unlocked To: JTW@MIT-SPEECH cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC In-reply-to: Msg of Thu 9 May 85 18:24:42-EDT from John Wroclawski Message-ID: <[MIT-MC].494266.850509.ALAN> Date: Thu 9 May 85 18:24:42-EDT From: John Wroclawski From: Alan Bawden Subject: Everything is locked I guess it is unlikely, but it would be foolish of anyone else to try to assemble and try anything that uses KS-10 I/O instructions.... Uh huh. Well, let me know when you think they work OK - I do hope to deal with the tape code sometime now that I'm back in town.. The I/O instructions work just fine. Last night we installed Jinx's DZ-11 code and it works too, so the path is clear for you.  Date: Tue, 7 May 85 17:25:44 EST From: Ken Harrenstien To: ALAN@MIT-MC cc: CSTACY@MIT-MC, BUG-ITS@MIT-MC Message-ID: <[MIT-MC].490451.850507.KLH> Date: Mon, 6 May 85 21:15:15 EST From: Alan Bawden In-reply-to: Msg of Mon 6 May 85 10:34:28 EST from Christopher C. Stacy If your COMSAT problem has to do with the hair COMSAT's go through when starting up to prevent their being more than one COMSAT, then I believe I remember KLH mentioning this before. Yes, this has happened. Makes one wonder if locks really do work, or if it is just the narrowness of the race window that gives one the impression they work.  Date: Tue, 7 May 85 05:58:57 EST From: Alan Bawden Subject: Everything is locked To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].489464.850507.ALAN> I guess it is unlikely, but it would be foolish of anyone else to try to assemble and try anything that uses KS-10 I/O instructions until I get a chance to come in and install and verify the new microcode. The macros in KSDEFS are gone and have been replaced with the new I/O instructions I microcoded up. What this means is that everything is probably broken.  Date: Tue, 7 May 85 02:34:47 EST From: David Vinayak Wallace Subject: MC:.;IOEVEL AIBIN To: ALAN@MIT-MC cc: BUG-ITS@MIT-MC In-reply-to: Msg of Mon 6 May 85 21:26:40 EST from Alan Bawden Message-ID: <[MIT-MC].489263.850507.GUMBY> Doesn't the system console watch .; like sys***;?  Date: Mon, 6 May 85 21:26:40 EST From: Alan Bawden Subject: MC:.;IOEVEL AIBIN To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].488587.850506.ALAN> Someone deleted the file MC:.;IOELEV AIBIN. It was either someone who reads this mailing list who thought he was cleaning up, or it was a random. In the later case there is nothing to be done, but in the former case I can prevent this from happening again by reminding you all that AI-11 still runs, and still network boots occasionall.  Date: Mon, 6 May 85 21:15:15 EST From: Alan Bawden To: CSTACY@MIT-MC cc: BUG-ITS@MIT-MC In-reply-to: Msg of Mon 6 May 85 10:34:28 EST from Christopher C. Stacy Message-ID: <[MIT-MC].488567.850506.ALAN> If your COMSAT problem has to do with the hair COMSAT's go through when starting up to prevent their being more than one COMSAT, then I believe I remember KLH mentioning this before. If this is a case of initializing a shared database using the algorithm given in .INFO.;ITS LOCKS, then perhaps the unlikely screw case documented there managed to actually happen.  Date: Mon, 6 May 85 18:14:42 EST From: Glenn S. Burke To: CSTACY@MIT-MC cc: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].488010.850506.GSB> Date: Mon, 6 May 85 10:34:28 EST From: Christopher C. Stacy I just had a problem with COMSAT similar to the problem with PWORD the other day, where locks did not get unlocked. As in the previous case, the involved code has been stable for a long time (years). Is it possible that locks have become broken lately somehow? I heard there are bugs in the mechanism but I don't know what they are -- maybe I am just hitting some kind of screw case lately. I remember tracking down and patching the pword lock at least once before, years ago (on AI). Maybe once on ML too. I don't believe we knew what caused the problem.  Date: Mon, 6 May 85 10:34:28 EST From: Christopher C. Stacy To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].487059.850506.CSTACY> I just had a problem with COMSAT similar to the problem with PWORD the other day, where locks did not get unlocked. As in the previous case, the involved code has been stable for a long time (years). Is it possible that locks have become broken lately somehow? I heard there are bugs in the mechanism but I don't know what they are -- maybe I am just hitting some kind of screw case lately.  Date: Sun, 5 May 85 00:53:11 EST From: Alan Bawden To: GSB@MIT-MC cc: BUG-ITS@MIT-MC In-reply-to: Msg of Sat 4 May 85 19:24:06 EST from Glenn S. Burke Message-ID: <[MIT-MC].485622.850505.ALAN> Had there been paper the message would have read: "TTY: OUTPUT BUFFER POINTER PAST END OF BUFFER". I added this crash to the collection.  Date: Sat, 4 May 85 19:24:06 EST From: Glenn S. Burke Sender: GSB5@MIT-MC To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].485447.850504.GSB5> mc crashed, was in ddt. no paper in the system console. dumped to crash;look later if anyone is interested and can find anything interesting from it...  Date: Fri, 3 May 85 15:39:42 EDT From: J. Noel Chiappa Subject: Drugs To: BUG-ITS@MIT-MC cc: JNC@MIT-MC Message-ID: <[MIT-MC].483905.850503.JNC> No, I'm not on them. I know what it looks like when PEEk gets an MPV and that wasn't it. I'm not sure what it was (it wasn't that the job had got and unhandled MPV, which would have shown up in the N display) but it wasn't PEEK losing its ass.  Date: Fri, 3 May 85 15:33:57 EDT From: Christopher C. Stacy Subject: No logins To: JNC@MIT-MC cc: BUG-ITS@MIT-MC, BUG-PWORD@MIT-MC In-reply-to: Msg of Fri 3 May 85 12:48:09 EDT from J. Noel Chiappa Message-ID: <[MIT-MC].483895.850503.CSTACY> Date: Fri, 3 May 85 12:48:09 EDT From: J. Noel Chiappa To: BUG-ITS cc: JNC Re: No logins PWORD was getting MPV's. I couldn't fix this (and backing up to an older PWORD didn't fix it) so I temporarily flushed PWORD and replaced it with DDT so that at least people could log in. Although JNC doesn't think so, I am convinced that he was faked out by a bug in PEEK which sometimes causes it to print out "MPV not handled" when it screws up. When I went and ran PWORD, I did not get any kind of MPV problems, but I did get hung after the command prompt. Somehow, the lock word in the password database was set and never cleared, so all jobs would .HANG forever as soon as they tried to access the database. The job which had claimed the database was long gone. I patched the password database back into working order and re-installed PWORD. The code for PWORD has not been changed in a long time, so I suspect that some kind of hardware problem (or human) somehow screwed up the ITS locks critical routine feature, or munged the database.  Date: Fri, 3 May 85 12:48:09 EDT From: J. Noel Chiappa Subject: No logins To: BUG-ITS@MIT-MC cc: JNC@MIT-MC Message-ID: <[MIT-MC].483484.850503.JNC> PWORD was getting MPV's. I couldn't fix this (and backing up to an older PWORD didn't fix it) so I temporarily flushed PWORD and replaced it with DDT so that at least people could log in.  Date: Fri, 3 May 85 12:32:32 EDT From: John G. Aspinall To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].483460.850503.JGA> MC has been up all morning, but refuses to establish proper connections for incoming network telnets and supdups. Dialups also appear flaky, but I'm not sure about this. Symptoms - you get the telser message "MC Maximum Confusion PDP-10" and then nothing. Finger from another site shows lots of un-logged-in HACTRNs sitting there. Note that outgoing chtn, telnet, supdup are fine. Incoming finger is fine too. I don't know enough about what's going on to do anything constructive, but I'd be interested in finding out what the diagnosis is.  Date: Tue, 30 Apr 85 01:16:24 EDT From: Alan Bawden Subject: Oh yeah, right... To: GREN@MIT-MC cc: BUG-ITS@MIT-MC, KS-ITS@MIT-MC, BUG-DDT@MIT-MC Message-ID: <[MIT-MC].476201.850430.ALAN> [Message from GREN at MIT-AI 1:05pm] hey, single-stepping isn't working right! Oh yeah. Until I get back into microcode hacking again, hackers who debug programs using DDT on AI will find that features related to single stepping don't work right. I'll fix it eventually, I just haven't put in the support for it yet. I won't be fixing the fact that AI doesn't have a MAR, so somebody should be fixing DDT to know that some ITS machines lack the feature.  Date: Fri, 26 Apr 85 22:53:01 EST From: Pandora B. Berman Subject: bring back old PDSET To: BUG-PDSET@MIT-MC, BUG-ITS@MIT-MC Message-ID: <[MIT-MC].471957.850426.CENT> MC crashed, and in being brought up had to have its time reset. in doing so i had to employ the new frilly version of PDSET. yucko. the old one worked fine with less verbiage and could parse 6-digit numbers into times and dates, which the new one can't. please flush this and restore the previous version.  Date: Fri, 26 Apr 85 02:05:57 EST From: David Vinayak Wallace Subject: More on IMP opto-isolator board -- fixt for now. To: BUG-ITS@MIT-MC cc: DCLARK@MIT-MC, ANN@MIT-MC, JTW@MIT-MC, moon@SCRC-STONY-BROOK Message-ID: <[MIT-MC].470299.850426.GUMBY> ITS was unable to get any bits through for long enough to open a connection. Noel found a similar chip to the broken one in a chaosnet interface. We (me, jtw, jnc) yanked it and installed it (the same hack was apparently done five years ago). As this is the second one to fail, it is likely that another one will soon, and that the board may not appreciate being frobbed like this yet another time. I might make another isolator board sometime before the end of the term if I can get away with it. david  Date: Tue, 23 Apr 85 07:49:26 EST From: Glenn S. Burke Subject: mc memory randomness To: BUG-ITS@MIT-MC cc: CENT@MIT-MC Message-ID: <[MIT-MC].465864.850423.GSB> mc tripped and fell down this morning. As might be expected, the system console hardcopy for the previous hour was all overprinted on a single line. There was a parity error light on in the ampex (penny recorded this in the log). Cold booting worked until it checked NXM, when it decided that most (but not all) of the two high MH10s were not there. The memory was listed in a large number of randomly sized chunks. Power cycling those two cabinets didn't help. (The overtemp light had been on in C -- don't know if it had been on as of when the machine went down.) Deselecting them seemed to be a good idea and seems to be working... Since the machine was up, and seeing the time, i decided to pass off calling DEC to ann finn (unlike what i wrote in the log earlier).  Date: Mon, 22 Apr 85 21:57:01 EST From: Alan Bawden Subject: foo To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].465386.850422.ALAN> MC's console card said I was supposed to load XITS, but there wasn't any such file. I dumped XITS myself several days back, so I wonder who renamed it to be OXITS without explanation?  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 15 APR 85 22:35:51 EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215097; Mon 15-Apr-85 22:35:39-EST Date: Mon, 15 Apr 85 22:32 EST From: David A. Moon Subject: M-X Copy File To: Alan Bawden cc: BUG-ITS@MIT-MC.ARPA In-Reply-To: <840915120628.5.MOON@EUPHRATES.SCRC.Symbolics>, <[MIT-MC].451173.850411.ALAN> Message-ID: <850415223234.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu,11 Apr 85 13:10:07 EST From: Alan Bawden A file's author is currently apparently set from the UNAME of the writing job. (I surmise, I haven't looked at the code yet.) Perhaps the XUNAME should be used instead? Here's the previous discussion of this: 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. Suggestions? ------- Kerns suggests doing #3 or making ITS set the author from HSNAME instead of the UNAME. That sounds good except what about ^S? Last week I thought, mistakenly, that using ^S to run EMACS on another's terminal would make me be the author of files that I write. I think it should. Hence: - ITS should set the author of the file to the HSNAME. - The file job should set its HSNAME to that of the user on whose behalf it is acting. - The file job shouldn't set the author gratuitously. In the above, HSNAME would be XUNAME were it not for the fact that authors are stored as directory numbers rather than as sixbit strings. Anyone disagree?  Date: Thu,11 Apr 85 13:10:07 EST From: Alan Bawden To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].451173.850411.ALAN> A file's author is currently apparently set from the UNAME of the writing job. (I surmise, I haven't looked at the code yet.) Perhaps the XUNAME should be used instead?  Date: Mon, 8 Apr 85 10:00:36 EST From: George J. Carrette Subject: blast from the past To: ALAN@MIT-MC cc: BUG-ITS@MIT-MC, FILE-R@MIT-MC In-reply-to: Msg of Mon 8 Apr 85 00:12:06 EST from Alan Bawden Message-ID: <[MIT-MC].446519.850408100037.GJC> Speaking of historically interesting files I propose that certain MC/AI/ML backup tapes that would otherwise be discarded be put into the MIT archives and/or the CCC facility. Example: CCC has an Imlac, and I was showing Gill the :IMLOAD program and the IMLAC directory, but of course the IMLAC directory was reaped long ago. But since CCC has an old IBM 7 track drive they could actually make good use of the tapes with the IMLAC stuff. Personally I'm interested in seeing old snapshots of conniver, planner, rabbit, etc, all of which are on backup tape.  Date: Mon, 8 Apr 85 00:12:06 EST From: Alan Bawden Subject: blast from the past To: GJC@MIT-MC cc: BUG-ITS@MIT-MC In-reply-to: Msg of Sun 7 Apr 85 17:08:18 EST from George J. Carrette Message-ID: <[MIT-MC].446193.850408001206.ALAN> Date: Sun, 7 Apr 85 17:08:18 EST From: George J. Carrette the end of the contents of l;bibop (memo) seems to have extra blocks in it from the mail status file. ... from a mail status file from around 1974! I rescued this file from ML's filesystem last year. It was damaged on ML years ago. Its actually interesting to see what mail status files looked like ten years ago.  Date: Sun, 7 Apr 85 17:08:18 EST From: George J. Carrette To: BUG-ITS@MIT-MC Message-ID: <[MIT-MC].445871.850407170822.GJC> the end of the contents of l;bibop (memo) seems to have extra blocks in it from the mail status file.  Date: Thu, 4 Apr 85 23:01:54 EST From: "Christopher C. Stacy" To: BUG-ITS@MIT-MC I replied to LIN.  Date: Thu, 4 Apr 85 22:37:24 EST From: Herb Lin To: BUG-ITS@MIT-MC actually, i'm looking for a wizard. how do you change the password on ITS for your own account? tnx.  Date: 31 March 1985 17:30-EST From: Glenn S. Burke To: bede @ MIT-XX cc: BUG-ITS @ MIT-MC rolm 4602 calling mc doesn't answer.  Received: from 40700024534 by MIT-MC via Chaosnet; 16 MAR 85 18:10:30 EST Received: from SCRC-EUPHRATES by SCRC-VALLECITO via CHAOS with CHAOS-MAIL id 2994; Sat 16-Mar-85 15:24:53-EST Date: Sat, 16 Mar 85 15:25 EST From: David A. Moon Subject: Tapes for Swedes To: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: bug-its@MIT-MC.ARPA Message-ID: <850316152523.1.MOON@EUPHRATES.SCRC.Symbolics.COM> [Replying to a message that JTW forwarded to me] Date: 11 Mar 85 02:13 +0100 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA We can probably get access to a 7-track tape drive to read your tapes on, but we need some information about the format, like a backup program that we can read on a TOPS-10 or TOPS-20 machine. Even a listing would be helpful. Also, we would like to know what kind of tape drive and controller you are using, and if you use standard DEC core-dump format. If you can read 7-track tapes in DEC core-dump format, we can send you ITS dump tapes of all the relevant files, including the Midas assembler and binaries of Midas that will run on Tops-10. (I guess the right thing would be to include Tops-20 binaries of Midas as well). It will probably be six or seven reels of tape. The format is as simple as could be, I expect we can send you a 1/2 page writeup describing it along with the tapes. Or I can send you a one-sentence writeup right now: The files are delimited by tape file-marks; each file starts with a header, which starts with an "aobjn pointer", and contains its name in sixbit and some other stuff; the rest of the file is just the file, as 36-bit words; at the front of the tape is another header, also starting with an "aobjn pointer", giving the tape name and some other stuff.  Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 14 MAR 85 23:44:46 EST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 197577; Thu 14-Mar-85 19:55:26-EST Date: Thu, 14 Mar 85 19:56 EST From: David A. Moon Subject: ITS To: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: BUG-ITS@MIT-MC.ARPA In-Reply-To: <91827@QZCOM> Message-ID: <850314195652.4.MOON@EUPHRATES.SCRC.Symbolics.COM> From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Does anyone over there have an ITS tape? It's been three weeks since you sent your message (I'm behind on my mail). Was it ever clarified what type of tape drive you have and what formats of tape you can read? It's possible that we may have to write a 9-track Tops-10/Tops-20 Interchange format tape for you, which would be possible for us to do but would take a fair amount of work. With the recent episode of vandalism and destruction, there is only one running ITS machine in the world and it has a 7-track tape drive. Last year for archival purposes I dumped all the ITS and utility program sources on two reels of 9-track, 3200-bpi tape in a format that you definitely don't have a program to read. Two copies of those tapes exist in separate locations. It is not inconceivable that I could make another copy. That might be useful, since the separate locations are only three miles apart and hence could both be destroyed simultaneously. ... In the meantime we have gotten another machine, a KI10, which has been up and running several months. It runs a slightly modified TOPS-10 V7.02 (which isn't supposed to run on KI at all), and we have managed to simulate some KL instructions, for example ADJSP. We are planning hardware modifications so we can do ADJBP too. But TOPS-10 is not very exciting, so we have been thinking about getting up TENEX, or even TOPS-20. Do you know any place we can get a KI10 TENEX monitor? I think it would be considerably less work to get ITS running on a KI10 than to get it running on a KS10. The biggest difference between the stock KI10 and the ITS-modified KA10 is that the KI10 paging is less flexible (no split page tables between the upper and lower half of user address space); but a small amount of software simulation could handle that; certainly it wouldn't be as bad as what it takes to get Tenex to run on the KI10. Or you could fix the hardware, which evidently you have the capability to do. Want to have a race? It wouldn't really be very fair, since there are only a couple of very part-time people working on the KS10 here. Does BBN still run TENEX? Any pointers would be appreciated. A perhaps little-known fact is that Symbolics still runs TENEX, on a Foonly F-2. I've been campaigning to get that machine thrown off the roof for quite a while now, but unfortunately there are still people using it.  Date: 7 March 1985 20:09-EST From: Ken Harrenstien Subject: Novelty To: ALAN @ MIT-MC cc: BUG-ITS @ MIT-MC Date: 24 January 1985 20:56-EST From: Alan Bawden Just a event to ponder. The other day I supduped from MC back to MC (presumably using Chaosnet, I didn't think to check), and I was greeted with the following: S.1487. PWORD.2630. TTY 52 12. Lusers, Fair Share = 6% MC IT* Note that five characters ("MC IT") have been displaced. Conceivably the fact that the machine was so heavily loaded, and that the user and server were both on the same machine, could have allowed some timing screw that almost never happens normally. This is not new. The phenomenon has existed for several years and was first noticed on the AI KA-10 when telnet connections would sometimes produce scrambled initial prompts. I don't think anyone has made a serious effort to identify the bug. It could be in either the telnet server or in the ITS STY code. This would be a good case for any mystery lovers to investigate.  Date: 7 March 1985 16:45-EST From: Christopher C. Stacy Subject: timestamps To: BUG-MAIL @ MIT-MC cc: BUG-ITS @ MIT-MC, KLH @ SRI-NIC I frobbed the Received: lines some more so that they look like the usual RFC822 ones; this is for both the SMTP and CHAOS servers. They look these: Received: from USC-ECLB.ARPA by MIT-MC.ARPA; 7 MAR 85 16:41:19 EST Received: from MIT-EECS by MIT-MC via Chaosnet; 7 MAR 85 16:41:02 EST They use new routines in various packages: The DATIME library now has a routine called TIMRFC. The OUT package now supports the new directive TIM(F4). Chris  Date: 7 March 1985 16:26-EST From: Alan Bawden Subject: MC hardware status To: BUG-ITS @ MIT-MC The most recent parity errors have occured in MH10-D. Also the microcode hangs about once a week it seems.  Date: 6 March 1985 19:58-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC (MC is getting the parity errors, not me...)  Date: 6 March 1985 19:57-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC We are getting a lot of parity errors lately, although I haven't looked to see where they are coming from.  Received: from MIT-HTVAX.ARPA by MIT-MC.ARPA; WED 6 MAR 1985 1404 EST Received: by MIT-HTVAX.ARPA (4.12/4.7) id AA26507; Wed, 6 Mar 85 13:59:31 est Message-Id: <8503061859.AA26507@MIT-HTVAX.ARPA> To: BUG-ITS@mit-mc.ARPA Subject: Received: lines Date: 06 Mar 85 13:59:26 EST (Wed) From: Martin David Connor Thanks to whoever put in received lines. They are very helpful in tracing the path of a message. Could they be altered slightly to conform to the RFC822 spec for such fields? It would be much easier to read if it were consistent with the rest of the Received lines a message might contain. Here is an excerpt from the RFC which specifies the order of the fields: received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form ";" date-time ; time received  Date: 2 March 1985 09:06-EST From: Devon S. McCullough To: BUG-ITS @ MIT-MC just got a looong hang, followed by host not responding/host reset the connection (I'm on via mit-tac) after which I was able to reconnect and reattach. net lossage?  Date: 28 February 1985 03:05-EST From: Christopher C. Stacy Subject: PDSET To: BUG-ITS @ MIT-MC cc: GUMBY @ MIT-MC I rewrote PDSET from scratch, and made some improvements to the DWIM in the DATIME library. The new PDSET has not yet been tested entirely, and is not installed. Also, I didn't hack it up for the KS10 yet either. Will do some evening...  Date: 21 February 1985 03:43-EST From: Christopher C. Stacy Subject: un-named hosts To: BUG-TCP @ MIT-MC, BUG-MAIL @ MIT-MC, BUG-REPLY @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 20 Feb 1985 23:24-EST from Christopher C. Stacy Date: 20 February 1985 23:24-EST From: Christopher C. Stacy To: BUG-MAIL Someone at SCRC just tried to send me a message from a host not in our tables; he was refused by our server. I bet that the server died trying to look it up. I'll make it say CHAOS|nnnn or something. OK, I fixed this so that the Chaosnet SEND server will claim the message came from a host named like "24516/CHAOS". It occurred to me that it would be nice to be able to REPLY to these guys too, so I went and hacked up the NETWRK library to accept various numerical host names. (There was some code in NETWRK to parse some of these, but it was pretty broken and looked like it could never have worked.) Then I hacked up SENDER a little, mostly to know about the following poorly documented return convention of NETWRK"HSTLOOK: even if A gets a host address, B may contain zero rather than a database pointer. I also reassembled TELNET with the new NETWRK. With the right switches set, programs will now parse all these equivalent forms: MIT-AI ; symbolic 10.2.0.6 ; Internet address 2/6 ; Host 2 on IMP 6. 3130/CHAOS ; (Other nets work too: 400006/ARPA is MIT-AI, 77/SATNET is GOONHILLY-ECHO) If anything mysterious starts happenning with programs as they are re-assembled with the new NETWRK, let me know. Chris  Date: Thu 21 Feb 85 00:40:56-EST From: John Wroclawski Subject: Re: ITS To: CENT@MIT-MC, Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: BUG-ITS@MIT-MC In-Reply-To: Message from "Pandora B. Berman " of Wed 20 Feb 85 23:25:36-EST From: Pandora B. Berman Subject: ITS From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: BUG-ITS@MIT-MC.ARPA Subject: ITS .... it's been a long time since we said anything; sorry (at least we could have said it would take a long while or something). a chief problem that i have heard some of the hackers here mention about running ITS on your system is that the hardware list you sent does not include a paging box (i'm not sure what number that would be -- perhaps DM10 -- someone will jump on me if i'm wrong). Um, actually it's not a DEC frob at all, so it hasn't got a number. The ones which were used at MIT were built either by us or Systems Concepts, I believe. ITS paging is somewhat different than TOPS-10, both of which are completely different than TENEX/TOPS-20. On the other hand, it might be possible to pound on your KI10 enough to get it to do ITS paging using the KI's paging hardware. The page tables are of different format, the pages are larger, and of course page faults are reported to the OS differently. also the ITS sources are not neatly available already on a single tape; someone would have to go through things and figure out what to send you, and we have all been sort of busy (we work full time on other things, or are students, etc.) Hmmm, if they have a TOPS-10 running, they at least have something to run MIDAS on. It's a start. Maybe when the KS is done things will be in one place... i think BBN flushed their last tenex last spring; not sure who you could ask there for further details. They did. There are still a few of them running around the Arpanet though. If you can get the right paging hardware to run TENEX you actually have a pretty good chance of getting TOPS-20 up, if you can find a set of version 3 or 4 sources. You would either have to change a lot of code or change the way traps and such work on the KI though. For TENEX, I'd start by trying to get the latest sources from BBN, presumably they still have them around. -------  Date: 20 February 1985 23:19-EST From: Pandora B. Berman Subject: ITS To: Bjorn_Danielsson_QZ%QZCOM.MAILNET @ MIT-MULTICS cc: BUG-ITS @ MIT-MC Date: 20 Feb 85 19:42 +0100 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: BUG-ITS@MIT-MC.ARPA Subject: ITS Does anyone over there have an ITS tape? We (of the computer club STACKEN) would very much like to take a look at it and see if we can run it on our KA10. Any kind of tape will do, we think we can manage to decode it. And we promise not to bother you with questions later. We are even prepared to promise Ronald Reagan that we won't give it to the Russians :-) We have finally found a room to put the machine in, and it will be installed very soon. In the meantime we have gotten another machine, a KI10, which has been up and running several months. It runs a slightly modified TOPS-10 V7.02 (which isn't supposed to run on KI at all), and we have managed to simulate some KL instructions, for example ADJSP. We are planning hardware modifications so we can do ADJBP too. But TOPS-10 is not very exciting, so we have been thinking about getting up TENEX, or even TOPS-20. Do you know any place we can get a KI10 TENEX monitor? Does BBN still run TENEX? Any pointers would be appreciated. it's been a long time since we said anything; sorry (at least we could have said it would take a long while or something). a chief problem that i have heard some of the hackers here mention about running ITS on your system is that the hardware list you sent does not include a paging box (i'm not sure what number that would be -- perhaps DM10 -- someone will jump on me if i'm wrong). also the ITS sources are not neatly available already on a single tape; someone would have to go through things and figure out what to send you, and we have all been sort of busy (we work full time on other things, or are students, etc.) i think BBN flushed their last tenex last spring; not sure who you could ask there for further details. maybe some piece of your KI could be used as an ITS paging box? i don't know (i'm not a hacker, alas, so i can't do more than speculate).  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655243468721180@MIT-MULTICS.ARPA>; 20 Feb 1985 18:37:48 est Date: 20 Feb 85 19:42 +0100 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: BUG-ITS@MIT-MC.ARPA Subject: ITS Message-ID: <91827@QZCOM> Does anyone over there have an ITS tape? We (of the computer club STACKEN) would very much like to take a look at it and see if we can run it on our KA10. Any kind of tape will do, we think we can manage to decode it. And we promise not to bother you with questions later. We are even prepared to promise Ronald Reagan that we won't give it to the Russians :-) We have finally found a room to put the machine in, and it will be installed very soon. In the meantime we have gotten another machine, a KI10, which has been up and running several months. It runs a slightly modified TOPS-10 V7.02 (which isn't supposed to run on KI at all), and we have managed to simulate some KL instructions, for example ADJSP. We are planning hardware modifications so we can do ADJBP too. But TOPS-10 is not very exciting, so we have been thinking about getting up TENEX, or even TOPS-20. Do you know any place we can get a KI10 TENEX monitor? Does BBN still run TENEX? Any pointers would be appreciated. Happy hacking, Bjorn Danielsson Datorforeningen STACKEN c/o NADA Royal Institute of Technology S-100 44 Stockholm SWEDEN  Date: 13 February 1985 17:56-EST From: Glenn S. Braindeath Subject: "IBO" To: BUG-ITS @ MIT-MC I just got an IBO message... I seem to remember that this ain't supposed to happen. A minute later everything worked fine. (i'mon 1200 baud dialup)  Date: 12 February 1985 18:17-EST From: David A. Moon Subject: NTSDDT To: CSTACY @ MIT-MC cc: BUG-ITS @ MIT-MC, TY @ MIT-MC, JNC @ MIT-XX Date: 12 February 1985 17:42-EST From: Christopher C. Stacy Subject: NTSDDT To: JNC @ MIT-XX cc: BUG-ITS @ MIT-MC, TY @ MIT-MC In-reply-to: Msg of Tue 12 Feb 85 17:40:25-EST from J. Noel Chiappa Date: Tue 12 Feb 85 17:40:25-EST From: J. Noel Chiappa To: CSTACY at MIT-MC.ARPA cc: BUG-ITS at MIT-MC.ARPA, TY at MIT-MC.ARPA, JNC at MIT-XX.ARPA Re: NTSDDT Date: 12 February 1985 17:32-EST From: Christopher C. Stacy Date: Tue 12 Feb 85 17:29:53-EST From: J. Noel Chiappa I was speaking about making the system tattle on changes to .KLFE., or did you hack KLFEDR too? OOoh. I believe when you write a file on the front-end file system it changes pointers which live in files in the ITS directory. Nope. There is no entry for NTSDDT CMD in .KLFE.; but running KLFEDR reveals that it is there. OOoh. I believe when you write a file on the front-end file system it changes POINTERS WHICH LIVE IN FILES in the ITS directory. It's more complicated than that. We don't use the RSX-11 file system, we use the KLDCP file system which DEC later flushed.. Also the front-end files aren't in any one place on the disk, but are scattered all over. Some of them, especially the larger ones, reside in individual ITS files, others are pieces portions of an ITS file. And if you move or delete anything on the .KLFE. directory you screw it up since somewhere there is a KLDCP directory containing absolute disk addresses. You could make the .KLFE. dir be proetcedt and also make KLFEDR tattle itself somehow.  Date: Tue 12 Feb 85 17:55:29-EST From: J. Noel Chiappa Subject: Re: NTSDDT To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Tue 12 Feb 85 17:42:00-EST I parsed that correctly the second time. Yes, there does seem to be this file KLDCP (DIR) which macgically contains the actual blocks of the RSX-11 directory. So you will get the miscreants name (if done under ITS), but not which file he bashed. -------  Date: 12 February 1985 17:42-EST From: Christopher C. Stacy Subject: NTSDDT To: JNC @ MIT-XX cc: BUG-ITS @ MIT-MC, TY @ MIT-MC In-reply-to: Msg of Tue 12 Feb 85 17:40:25-EST from J. Noel Chiappa Date: Tue 12 Feb 85 17:40:25-EST From: J. Noel Chiappa To: CSTACY at MIT-MC.ARPA cc: BUG-ITS at MIT-MC.ARPA, TY at MIT-MC.ARPA, JNC at MIT-XX.ARPA Re: NTSDDT Date: 12 February 1985 17:32-EST From: Christopher C. Stacy Date: Tue 12 Feb 85 17:29:53-EST From: J. Noel Chiappa I was speaking about making the system tattle on changes to .KLFE., or did you hack KLFEDR too? OOoh. I believe when you write a file on the front-end file system it changes pointers which live in files in the ITS directory. Nope. There is no entry for NTSDDT CMD in .KLFE.; but running KLFEDR reveals that it is there. OOoh. I believe when you write a file on the front-end file system it changes POINTERS WHICH LIVE IN FILES in the ITS directory.  Date: Tue 12 Feb 85 17:40:25-EST From: J. Noel Chiappa Subject: Re: NTSDDT To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Tue 12 Feb 85 17:32:00-EST Nope. There is no entry for NTSDDT CMD in .KLFE.; but running KLFEDR reveals that it is there. -------  Date: 12 February 1985 17:32-EST From: Christopher C. Stacy Subject: NTSDDT To: JNC @ MIT-XX cc: BUG-ITS @ MIT-MC, TY @ MIT-MC In-reply-to: Msg of Tue 12 Feb 85 17:29:53-EST from J. Noel Chiappa Date: Tue 12 Feb 85 17:29:53-EST From: J. Noel Chiappa I was speaking about making the system tattle on changes to .KLFE., or did you hack KLFEDR too? OOoh. I believe when you write a file on the front-end file system it changes pointers which live in files in the ITS directory.  Date: Tue 12 Feb 85 17:29:53-EST From: J. Noel Chiappa Subject: Re: NTSDDT To: CSTACY@MIT-MC.ARPA cc: BUG-ITS@MIT-MC.ARPA, TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Tue 12 Feb 85 17:12:00-EST I was speaking about making the system tattle on changes to .KLFE., or did you hack KLFEDR too? -------  Date: 12 February 1985 17:12-EST From: Christopher C. Stacy Subject: NTSDDT To: JNC @ MIT-XX cc: BUG-ITS @ MIT-MC, TY @ MIT-MC In-reply-to: Msg of Tue 12 Feb 85 12:29:46-EST from J. Noel Chiappa Huh? I put the file back into the front-end file system, and it has been working for a couple of days.  Date: Tue 12 Feb 85 12:29:46-EST From: J. Noel Chiappa Subject: Re: NTSDDT To: CSTACY@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA cc: TY@MIT-MC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Fri 8 Feb 85 13:17:00-EST It's not clear if this will do the right thing, since presumably the file was also deleted from the RSX-11 directory, which would have used KLFEDR or whatever the fuck that program is called. In fact, you could delete it with KLFEDR and not touch the directory entry in .KLFE. I guess. -------  Date: 8 February 1985 23:04-EST From: David E. Hirsch To: BUG-ITS @ MIT-MC this is NOT hirsh. I just ROLM'ed to MC and whoops, here I am all logged in and everything. Oh well. I'm on T30.  Date: 8 February 1985 13:17-EST From: Christopher C. Stacy Subject: NTSDDT To: BUG-ITS @ MIT-MC cc: TY @ MIT-MC The front end file NTSDDT seems to have been deleted over the weekend. I re-created it; you can boot the system normally now. I also made the front-end file directory be tattled on by the system job.  Date: 29 January 1985 18:00-EST From: Christopher C. Stacy Subject: MINITS HUBs making noise To: BUG-MINITS @ MIT-MC cc: BUG-ITS @ MIT-MC NE438B, NE438C, and NE437A have terminal lines running open or something. They keep generating a lot of noise, some of which is control-Zs, so they are connecting to MC and typing the noise at us. This eats up network resources and prevents some people from logging in,etc. I heard that the power company is being flaking today, which may have something to do with it.  Date: 28 January 1985 15:20-EST From: Christopher C. Stacy To: DEVON @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 27 Jan 1985 02:09-EST from Devon S. McCullough You are probably getting memory parity errors.  Date: 27 January 1985 02:09-EST From: Devon S. McCullough To: BUG-ITS @ MIT-MC Two or three times in the last day or so I've gotten top level interrupt, tree detached This usually happens when I have been typing ^Z's and ^G's because the system is not responding. Now I have a dead detached tree. I can usually type ^_'s to prove that the system itself is alive even though nothing is responding.  Date: 26 January 1985 03:47-EST From: Christopher C. Stacy Subject: not knowing the time To: BUG-FTP @ MIT-MC cc: ALAN @ MIT-MC, BUG-ITS @ MIT-MC OK, FTP servers now die cleanly if they don't know the time.  Date: 25 January 1985 23:10-EST From: Alan Bawden Subject: no arpa? To: GSB @ MIT-MC cc: BUG-ITS @ MIT-MC In-reply-to: Msg of 25 Jan 1985 21:00-EST from Christopher C. Stacy Date: 25 January 1985 21:00-EST From: Christopher C. Stacy Date: Fri 25 Jan 85 12:08:58-EST From: Glenn S. Burke is mc's arpa connection busted? can't reach it from rutgers or xx via internet. It does for me at the moment. I guess you can tell from this that Chris reads his mail in reverse!  Date: 25 January 1985 21:00-EST From: Christopher C. Stacy Subject: no arpa? To: GSB @ MIT-XX cc: BUG-ITS @ MIT-MC In-reply-to: Msg of Fri 25 Jan 85 12:08:58-EST from Glenn S. Burke Date: Fri 25 Jan 85 12:08:58-EST From: Glenn S. Burke To: bug-its at MIT-MC.ARPA Re: no arpa? is mc's arpa connection busted? can't reach it from rutgers or xx via internet. It does for me at the moment.  Date: Fri 25 Jan 85 12:08:58-EST From: Glenn S. Burke Subject: no arpa? To: bug-its@MIT-MC.ARPA is mc's arpa connection busted? can't reach it from rutgers or xx via internet. -------  Date: 25 January 1985 13:06-EST From: Alan Bawden To: BUG-FTP @ MIT-MC cc: KMP @ MIT-MC, BUG-ITS @ MIT-MC In-reply-to: Msg of 25 Jan 1985 10:15-EST from Kent M Pitman Date: 25 January 1985 10:15-EST From: Kent M Pitman System went down at 6:25am this morning. Whoever brought it back up forgot to set the time so mostly no one could log in. And MC hasn't been talking TCP since then, because the tables were clogged with a zillion dead FTP servers because of the silly .VALUE-when-ITS- doesn't-know-the-time screw I reported a couple weeks ago.  Date: 25 January 1985 10:15-EST From: Kent M Pitman To: BUG-ITS @ MIT-MC System went down at 6:25am this morning. Whoever brought it back up forgot to set the time so mostly no one could log in.  Date: 24 January 1985 20:56-EST From: Alan Bawden Subject: Novelty To: BUG-ITS @ MIT-MC Just a event to ponder. The other day I supduped from MC back to MC (presumably using Chaosnet, I didn't think to check), and I was greeted with the following: S.1487. PWORD.2630. TTY 52 12. Lusers, Fair Share = 6% MC IT* Note that five characters ("MC IT") have been displaced. Conceivably the fact that the machine was so heavily loaded, and that the user and server were both on the same machine, could have allowed some timing screw that almost never happens normally.