From CSTACY at MIT-MC Mon Jan 31 18:02:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: January 31 1983 12:02 EST Subject: broken? In-Reply-To: The message of 01/30/83 00:28:08 from CENT at MIT-ML Message-ID: AI (and some other machines probably) have a slighlyt buggy version of PEEK. Copy MC:SYSBIN;PEEK > to the machine, and load up a job with it. Type $G and it will install itself. Ill do this if I get a chance today. From HDT at MIT-ML Mon Jan 31 00:00:00 1983 From: HDT at MIT-ML (HDT at MIT-ML) Date: 31 Jan 1983 00:00 Subject: No subject Message-ID: How can I get its typeout into a wall paper? (ie. the functionality of twenex's photo) From DCP at MIT-MC Sun Jan 30 00:00:00 1983 From: DCP at MIT-MC (DCP at MIT-MC) Date: 30 Jan 1983 00:00 Subject: No subject Message-ID: It works for me, although the output from CMU is completely garbaged. Are you sure you are connecting to TCP and not to ARPA? From CENT at MIT-ML Sun Jan 30 00:00:00 1983 From: CENT at MIT-ML (CENT at MIT-ML) Date: 30 Jan 1983 00:00 Subject: broken? Message-ID: :p on AI seems to be broken. when i try to kill a job, the display changes from whatever before to show that job, but doesn't ask GUN THIS JOB?. i think the problem is not that it thinks it has asked this and is waiting for an answer (typing y does not seem to do anything). i do give an argument, so it isn't that, unless . is broken in some fashion. :p on ML behaves properly, so perhaps the version on AI is bad somehow? From MOON at MIT-MC Sun Jan 30 03:11:00 1983 From: MOON at MIT-MC (David A. Moon) Date: January 29 1983 21:11 EST Subject: No subject Message-ID: ML-device service between ML and MC now uses Chaosnet. Relink DEVICE;JOBDEV ML/MC if there are any fatal problems. Let me know if there are any problems. Making links does not work across this. I don't think it worked the old way either, unless it was patched in the binary and not fixed in the source. I'll probably fix this tomorrow (the two ends don't seem to agree on what the protocol is for sending over the arguments to the MLINK system call) From SASW at MIT-MC Sun Jan 30 02:43:00 1983 From: SASW at MIT-MC (Steven A. Swernofsky) Date: January 29 1983 20:43 EST Subject: mail from 1200400006 Message-ID: I have been receiving messages which read "You have net mail from 1200400006:" followed by the normal message which indicates the receipt of mail. I think this is wrong. Is it? -- Steve From MOON at MIT-MC Sun Jan 30 02:29:00 1983 From: MOON at MIT-MC (David A. Moon) Date: January 29 1983 20:29 EST Subject: MLSLV... Message-ID: There do seem to be lots of cases of things like MLSLV's that think their connection is open, but the foreign host doesn't know about that connection, and JOB.nn's (MLDEV's) that have an open connection and no owner anymore. Note that neither program has been changed. Probably the advent of TCP has made the NCP implementation in the IMPs more unreliable? The Chaosnet version of the ML device certainly won't have these problems, and the TCP version shouldn't, so when they're installed things should look up. I guess I'll go ahead and install the Chaosnet version between ML and MC now. From ___014 at MIT-ML Sat Jan 29 00:00:00 1983 From: ___014 at MIT-ML (___014 at MIT-ML) Date: 29 Jan 1983 00:00 Subject: No subject Message-ID: TELNET on a Lispm gets no response from the TCP server on ML or MC trying to go to CMUA even though ML is up and can successfully finger CMUA. From ELLEN at MIT-MC Sat Jan 29 07:41:00 1983 From: ELLEN at MIT-MC (V. Ellen Golden) Date: January 29 1983 01:41 EST Subject: MLSLV... Message-ID: There seems to be a pattern developing of MLSLVs opening connections and then lying around. In some cases this may be due to a system down, but shouldn't it time out? At this moment there are three such, all from ML or AI. ML and AI are both up now. From SWG at MIT-XX Fri Jan 28 00:00:00 1983 From: SWG at MIT-XX (S. W. Galley) Date: 28 Jan 1983, 00:00 Subject: con't... In-Reply-To: Your message of 23-Jan-83 2145-EST Message-ID: Don't panic! DM is now running COMSAT, and I have converted the birthday-greeting program suitably -- it's independent of COMSYS. ------- From PDL at MIT-XX Thu Jan 27 00:00:00 1983 From: PDL at MIT-XX (P. David Lebling) Date: 27 Jan 1983, 00:00 Subject: No subject In-Reply-To: Your message of 25-Jan-83 1528-EST Message-ID: Comsat has been launched on DM. What I have done to (temporarily) deal with COMSYS is to convince it that all net mail gates through MIT-DMS (which will send it via Comsat, since FTP produces .MAIL. files). Eventually, stuff which produces Comsys request files should be changed by whomever is responsible for them. In any case, DM now is running a fully compatible Comsat, and Comsys is only run by hand periodically (by me). Dave ------- From KLH at MIT-MC Wed Jan 26 05:35:00 1983 From: KLH at MIT-MC (Ken Harrenstien) Date: January 25 1983 23:35 EST Subject: TCP for PEEK Message-ID: PEEK on MC has had some TCP connection status display stuff added. It is not very elegant but should suffice for a while. From CStacy at MIT-MC Tue Jan 25 21:28:00 1983 From: CStacy at MIT-MC (Christopher C. Stacy) Date: January 25 1983 15:28 EST Subject: No subject In-Reply-To: The message of 23 Jan 83 21:45-EST from Alan Bawden Message-ID: Apparently no one wants to hack TCP for COMSYS in the old Muddle it runs in. I installed a ready-to-launch COMSAT on DM a while back, and I think PDL and company are going to start running it before February. I'll do something about birthday messages. From ALAN at MIT-MC Mon Jan 24 03:45:00 1983 From: ALAN at MIT-MC (Alan Bawden) Date: January 23 1983 21:45 EST Subject: con't... Message-ID: I noticed this because I missed my yearly birthday greeting message from COMSYS. Clearly if COMSYS is going away, we need a crash program to move this functionality to some other program! From ALAN at MIT-MC Mon Jan 24 03:41:00 1983 From: ALAN at MIT-MC (Alan Bawden) Date: January 23 1983 21:41 EST Subject: COMSYS? Message-ID: So just what is the story with mailers on DM? Someone has sort of installed COMSAT there, except it isn't running. COMSYS isn't running either, and there is a small queue of messages on the COMSYS directory waiting to be sent. I suppose the fact that DM is running a pre-TCP version of ITS might have something to do with all this... From KLH at MIT-MC Fri Jan 21 16:51:00 1983 From: KLH at MIT-MC (Ken Harrenstien) Date: January 21 1983 10:51 EST Subject: No subject Message-ID: If ITS system mem (LMEMFR) is zero for more than a few seconds, a system console message should be printed so that it's more obvious why things are losing. MC has been skirting this (and falling victim to it) dangerously often lately during peak load. From TK at MIT-MC Thu Jan 20 09:28:00 1983 From: TK at MIT-MC (Tom Knight) Date: January 20 1983 03:28 EST Subject: No subject Message-ID: MC was catatonic tonight with the sysjob hung on the core job. I took a dump, crash corrq. It was stopped with key 0. The microcode had to be reloaded before I could get the system to load, which might be related. From CSTACY at MIT-MC Wed Jan 19 21:27:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: January 19 1983 15:27 EST Subject: No subject Message-ID: AI crashed with a parity error. From MHK at MIT-ML Wed Jan 19 00:00:00 1983 From: MHK at MIT-ML (MHK at MIT-ML) Date: 19 Jan 1983 00:00 Subject: No subject Message-ID: I was just on AI about 15 mins. ago. I think it may have crashed on me while I was trying to look at the following problem: :f @its bought me: [ ERROR; 10107>>PUSHJ 17,13251 Since your DDT lokks quite different from ours, and I don't know your calls very well, I didn't get very far and then the machine went away. From CENT at MIT-ML Mon Jan 17 00:00:00 1983 From: CENT at MIT-ML (CENT at MIT-ML) Date: 17 Jan 1983 00:00 Subject: its bugs Message-ID: Where are the old bug reports? MC;SYSTEM;ITS BUGS only goes back to 7/25/81. At first glance, the file on AI is not any better. AI:SYSTEM;ITS OBUGS goes back to 1 June 79.. From DCP at MIT-MC Sun Jan 16 19:46:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: January 16 1983 13:46 EST Subject: Supdup windows on color screen Message-ID: OOPS. The complete paragraph from page 3, the first part of which is just as vital as the second: The TCMXH variable specifies the line width in number of characters. This value is one less than the screen width (ITS indicates line overflow by outputting an exclamation point at the end of the display line before moving to the next line). Note: the terminal must not do an automatic CRLF when a character is printed in the rightmost column. If this is unavoidable, the user SUPDUP must decrement the width it sends by one. From DCPatSCRC-TENEX Sun Jan 16 00:00:00 1983 From: DCPatSCRC-TENEX (David C. Plummer) Date: Sunday, 16 January 1983, 00:00 Subject: Supdup windows on color screen In-Reply-To: The message of 15 Jan 83 23:43-EST from Henry Lieberman Message-ID: Sorry if you get this 6 times because of all the mailing lists, but this problem exists in many places, and should really be resolved on a global scale. ------------------------------ What we need to do is document what ITS expects to see for line width, and what it expects the terminal to do when you try and type something on the last line (stick versus wrap). We should then make sure each user implementation and the non-ITS servers strictly obey this. (If you read the SUPDUP RFC [a copy in MC:DCP2;RFC SUPDUP], you will find the following, which I think is sufficient for everybody to check their programs. [Page 2] The SUPDUP protocol originated as the internal protocol used between parts of ITS, and between ITS and "intelligent" terminals. Over the network, a user host acts like an intelligent terminal programmed for ITS. [later in Page 2] Because this is also the internals of ITS, the right to change it any time if necessary to provide new features is reserved by MIT. [Page 3] Note: the terminal must not do an automatic CRLF when a character is printed in the rightmost column. If this is unavoidable, the user SUPDUP must decrement the width it sends by one. From DCP at MIT-MC Fri Jan 14 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 14 January 1983, 00:00 Subject: No subject Message-ID: MC was found catatonic tonight. Taft says this is a recurring phenomena. The symptoms were: extrememly long wait to get a chaos supdup connection (if at all). STATUS answered immediately, however. ^Z from the console keybaord and the VT52 took a long time to respond. After that, loading a file looked like it was doomed to failure (though if I waited long enough, it may have loaded). SYS^F, SYS1^F, .TEMP.^F all failed to give me a directory listing. It's been a long time since I've played at the console, so CRASH;011483 LOOP may or may not contain anything useful. warm boot reload worked. From DCP at MIT-MC Fri Jan 14 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 14 January 1983, 00:00 Subject: No subject Message-ID: Where are the old bug reports? MC;SYSTEM;ITS BUGS only goes back to 7/25/81. At first glance, the file on AI is not any better. From DCP at MIT-MC Fri Jan 14 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 14 January 1983, 00:00 Subject: IOT control bits Message-ID: I think I noticed this 2 years ago, and I though Moon fixed it. Oh well. I discovered it by trying to turn a DDT display channel into super-image-output by toggling both bits. Great way to send ARDS pictures to your friends... From ALAN at MIT-MC Fri Jan 14 00:00:00 1983 From: ALAN at MIT-MC (Alan Bawden) Date: 14 January 1983, 00:00 Subject: IOT control bits Message-ID: This doesn't work as advertized: .call [setz ? sixbit /iot/ [%tipek,,ttyich] setzm t] While this does: .call [setz ? sixbit /iot/ %clbit,,%tipek movei ttyich setzm t] We could just fix the documentation of the IOT call to not claim that the left half of the first argument is XORed with the control bits... From CSTACY Thu Jan 13 00:00:00 1983 From: CSTACY (Christopher C. Stacy) Date: 13 Jan 1983, 00:00 Subject: No subject Message-ID: <[MIT-DMS].254621> There is a hacked PEEK which is patched around the init problem in my directory on DM; I linked SYS;TS PEEK to it for the moment, until PEEK gets fixed. From CSTACY at MIT-MC Thu Jan 13 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 13 January 1983, 00:00 Subject: No subject Message-ID: In ITS 1317 or higher on DM only, PEEK blows up trying purify itself. It dies trying to get a page at INITA. From DCP at MIT-MC Thu Jan 13 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 13 January 1983, 00:00 Subject: No subject Message-ID: I updated .INFO.;ITS .CALLS and .INFO.;ITS TTYVAR to reflect the fact that TTYOPT bit 1.3 is indeed in use, and is 1.3 %TPRSC This tty can do region scrolling. As defined in SYSTEM;BITS >. From DEVON at MIT-MC Thu Jan 13 00:00:00 1983 From: DEVON at MIT-MC (Devon S. McCullough) Date: 13 January 1983, 00:00 Subject: supdup for personal computers In-Reply-To: The message of 13 Jan 1983 04:46-EST from David C. Plummer Message-ID: What I am trying to convey is, that we need a way to tell ITS to send %TDQOT's argument without sending the %TDQOT itself, even when the TCTYP is SOFTWARE, so that programs can use %TDQOT to talk funny protocols without the necessity of changing TCTYP to PRINTING and back. Inventing something like :TCTYP SUPDUP would work for dialups but not for network connections, because network servers currently assume that any %TDORS byte sent as output was caused by an output reset (they have no way of telling whether this is so) and do the equivalent of an output reset for telnet or whatever. If the user wants to actually send a %TDORS byte as data it must be quoted, as in %TDQOT %TDORS. This means that a network server talking to a TAC with :TCTYP SOFT must see the %TDQOT's, but only send the argument, not the %TDQOT. On the other hand, a server talking to another SUPDUP serving host does indeed want to pass along %TDQOT's uncensored. By the way, the current (losing) TCP server recognises %TDORS but not %TDQOT, so that funny microcomputer programs LMODEM and SLOSTY which have long worked with NCP are now broken under TCP. From DCP at MIT-MC Thu Jan 13 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 13 January 1983, 00:00 Subject: supdup for personal computers Message-ID: Date: 13 January 1983 01:51-EST From: Devon S. McCullough TTYOPT bit 1.3 seems to be available. Let's call it %TPQOT and simply have network servers look at this bit to decide whether %TDQOT should be sent or not, instead of checking for TCTYP=%TNSFW as is done now. I don't understand your problem, and that won't work anyway. My understanding of the ITS terminal system is that characters are translated as they are pulled out of the ITS terminal buffer. If the terminal type is software, then no translation is done. Because you are on a software terminal ITS will not look at anything (including %TDQOT) and therefore just send it out. Also, this translation is probably done before the implemention of STYNET sees the character, so "have network servers look" will do no good. The net result is that what you send to a super image output channel that is %TNSFW is exacly what the other end (terminal or STY) will see. You do get raw 8bit strings. From DEVON at MIT-MC Thu Jan 13 00:00:00 1983 From: DEVON at MIT-MC (Devon S. McCullough) Date: 13 January 1983, 00:00 Subject: supdup for personal computers In-Reply-To: The message of 12 Jan 1983 12:45-EST from George J. Carrette Message-ID: I've been using SUPDUP on 8080 and 6502 personal computers to access ITS for years now, started using data compression about a year ago. My program SLOSTY is a modified PTY which does a simple Huffman code. I was planning to move up to fractional bits and other hairy codings, but lost interest when I quit logging in via the ARPAnet. Not being able to output arbitrary 8-bit strings defeats the whole purpose of doing data compression. It *IS* possible to output 8-bit strings from ITS, but it requires the ugly kludge of setting TCTYP to PRINTING in order for %TDQOT and %TDORS to work properly, restoring the original TCTYP when done. TTYOPT bit 1.3 seems to be available. Let's call it %TPQOT and simply have network servers look at this bit to decide whether %TDQOT should be sent or not, instead of checking for TCTYP=%TNSFW as is done now. From CSTACY at MIT-AI Thu Jan 13 00:00:00 1983 From: CSTACY at MIT-AI (CSTACY at MIT-AI) Date: 13 Jan 1983 00:00 Subject: No subject Message-ID: AI is back up now. From CSTACY at MIT-MC Thu Jan 13 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 13 January 1983, 00:00 Subject: No subject Message-ID: MC seemed to be wedged: I could not login at the console or from my FILE job. Some other file job did get on tho, but I still coldnt get anything out of the terminal. I paused the system and I think the SYS job was running. I continued it, and it went into a very tight loop. This time SW0 didnt work. I got into DDT and found that U was zero. Dumped to CRASH2;LOOOP SYS and reloaded XITS. From GJC at MIT-MC Wed Jan 12 00:00:00 1983 From: GJC at MIT-MC (George J. Carrette) Date: 12 January 1983, 00:00 Subject: supdup for personal computers Message-ID: Do you actually have this and the datacompression implemented? On what machines? By the way, you should not really need to send arbitrary eight-bit-strings just because you are doing data-compression. Certainly it is more convenient if you do, but you can certainly encode the information in whatever arbitrary characters that are available. From DEVON at MIT-MC Tue Jan 11 00:00:00 1983 From: DEVON at MIT-MC (Devon S. McCullough) Date: 11 January 1983, 00:00 Subject: No subject In-Reply-To: The message of 01/10/83 18:22:27 from GSB@MIT-ML Message-ID: In order to support data-compression and other non-SUPDUP protocols peculiar to personal computers, we need to be able to output ARBITRARY EIGHT BIT STRINGS to the user. ITS currently does this in a grossly crappy way, using %TDQOT in Super-Image output mode. Since this is the ONLY mechanism for doing this, it shouldn't interact with the user's TCTYP, but it does. Users with terminals that happen to understand %TD codes get screwed because ITS does not simply send %TDQOT's argument, it sends the %TDQOT as well. This is no good. There should be a +%TPSUP bit analogous to %TPTEL to say you are talking to a SUPDUP connection. Programs that check TCTYP=%TNSFW now should look at this bit instead. From MOON at MIT-MC Tue Jan 11 00:00:00 1983 From: MOON at MIT-MC (David A. Moon) Date: 11 January 1983, 00:00 Subject: RFNAME bug Message-ID: Date: 10 January 1983 17:46-EST From: David A. Moon To: BUG-ITS @ MIT-MC RFNAME on another job's channel clobbers that job's UUAC (via CHNDCD via NRFNM1) without pclsring the job, probably causing it to go off and do weird things. Fixed in the source (SYSHAK;ITS) From SWG Mon Jan 10 00:00:00 1983 From: SWG (S. W. Galley) Date: 10 Jan 1983, 00:00 Subject: SYSTEM CLOBBERED Message-ID: <[MIT-DMS].254428> DM has been getting a lot of these lately, e.g. SYSTEM CLOBBERED BETWEEN 144467 AND 112110 XOR= 350231,,746375 ! 07:10:02 76277 71061 56520 40711 163616 115205 54000 152343 30356 113152 176000 27310 2104 50054 116051 127647 121075 61070 170210 123760 42430 16237 13201 134467 174067 166377 36562 56473 13506 152102 42527 121674 141177 131607 43454 61376 What do all those numbers mean? Where is the problem? From CSTACY at MIT-MC Tue Jan 11 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 11 January 1983, 00:00 Subject: AI is down Message-ID: AI is sick. It runs sometimes for a while, with random jobs getting random parity errors. Sometimes the system gets an exec mode parity error. Just now it got KA: APR ERROR IN NULL JOB. From MOON at MIT-MC Mon Jan 10 00:00:00 1983 From: MOON at MIT-MC (David A. Moon) Date: 10 January 1983, 00:00 Subject: No subject Message-ID: RFNAME on another job's channel clobbers that job's UUAC (via CHNDCD via NRFNM1) without pclsring the job, probably causing it to go off and do weird things. From SWG Mon Jan 10 00:00:00 1983 From: SWG (S. W. Galley) Date: 10 Jan 1983, 00:00 Subject: DM crash at 12:30 Message-ID: <[MIT-DMS].254414> Job #9 was looping thru all PC values, apparently. PI 3 in progress, PI 1 request, no clock interrrupts, no EXEC mode. Dumped in DM:CRASH;JOB9 LOOP. From SWG Mon Jan 10 00:00:00 1983 From: SWG (S. W. Galley) Date: 10 Jan 1983, 00:00 Subject: DM crash Message-ID: <[MIT-DMS].254413> ... at 11:00 at UQL5A+15. Dumped in DM:CRASH;UQL5A +15. From RWK Mon Jan 10 00:00:00 1983 From: RWK (RWK) Date: 10 January 1983, 00:00 Subject: DDT on MC Message-ID: There is no (known) reason why we should not be running the latest DDT, which RWK thinks has all the needed patches and no other changes from the last correctly installed one. (Well, there was one set of bogus changes... sigh --RWK) Anyway, we debugged them, and installed them (MC only). I had thought CSTACY was going to install DDT from the sources some months ago, apparently he thought I was. So we did. From CSTACY at MIT-MC Mon Jan 10 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 10 January 1983, 00:00 Subject: DDT on MC Message-ID: The DDT installed on MC was an old one which did not have the fix for the old :REAP command bug. Not understanding quite why this version was installed, I re-installed the DDT from SYSBIN;DDT BIN. This version has the fix. RWK thinks the source for DDT has all the patches, but I noticed it didnt have the :REAP fix, so I put that into the source. From LIN at MIT-MC Mon Jan 10 00:00:00 1983 From: LIN at MIT-MC (Herb Lin) Date: 10 January 1983, 00:00 Subject: No subject Message-ID: can some system wizard tell me the format of tapes written on MC? density, block size, all that kind of stuff? i need to know for a machine to which I would like to move some MC files by tape. tnx. From DCP at MIT-MC Sun Jan 9 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 9 January 1983, 00:00 Subject: No subject Message-ID: I'm trying to run the syseng;hosts xfile, and when it tries to ftp to sail, it looks like the NETBLK timeout is around 4 minutes when it starts. Is this really necessary? From DCP at MIT-MC Sat Jan 8 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 8 January 1983, 00:00 Subject: user/server times Message-ID: I fixed the source of :TIMES (in tcp;) to only wait 10 seconds instead of 30 for the TCP connection to open/fail. I thought you could just use NETBLK... From CSTACY at MIT-MC Fri Jan 7 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 7 January 1983, 00:00 Subject: user/server times Message-ID: I converted the :TIMES program along with the TIMSRV. The TIMES program has two run time switches called NCPTRY and TCPTRY. It defaultly tries both protocols and tells you which it won with. Tested and installed on MC. From CSTACY at MIT-MC Fri Jan 7 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 7 January 1983, 00:00 Subject: TIMSRV converted (big deal!) Message-ID: I converted the time server (socket 45) for TCP as well as NCP. It is installed on MC and works with NCP (we dont have a TCP user to try it with yet.) Source is TCP;TIMSRV. Chris From SWG Mon Jan 3 00:00:00 1983 From: SWG (S. W. Galley) Date: 3 Jan 1983, 00:00 Subject: DM crash Message-ID: <[MIT-DMS].254017> ITS 1312 crashed at 14:20 when SWPOPG was called with A/ 6. I dumped it to DM:CRASH;SWPOPG A/6. From MOON at MIT-MC Mon Jan 3 00:00:00 1983 From: MOON at MIT-MC (David A. Moon) Date: 3 January 1983, 00:00 Subject: No subject Message-ID: Date: 3 January 1983 00:26-EST From: Christopher C. Stacy To: BUG-ITS @ MIT-MC In ITS 1315 on AI and ML, shutting the system down doesnt seem to work all the time. I get the ITS NOT IN OPERATION message, but then it seems to go back to normal timesharing and you never get the SHUTDOWN COMPLETE message. The pager lights look like it is running normal timesharing, although you can't login, and the data lights show only the SYS job getting run. It doesn't shut down until various things are complete, such as all jobs gunned down and the not in operation message typed out on all terminals. Find the place that does the shutdown complete bug pause and see what it was waiting for. It could be that someone installed a daemon job with OPTLIV that fails to finish itself up and go away. From DCP at MIT-MC Mon Jan 3 00:00:00 1983 From: DCP at MIT-MC (David C. Plummer) Date: 3 January 1983, 00:00 Subject: No subject Message-ID: Now that ITS has TCP, would it be feasible to hack the dover spooler to use the TCP route if the CHAOS route appears to be down? I don't know all the addressing issues, but if this is something that should be done, I'll help look into it. From CSTACY at MIT-MC Mon Jan 3 00:00:00 1983 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 3 January 1983, 00:00 Subject: No subject Message-ID: In ITS 1315 on AI and ML, shutting the system down doesnt seem to work all the time. I get the ITS NOT IN OPERATION message, but then it seems to go back to normal timesharing and you never get the SHUTDOWN COMPLETE message. The pager lights look like it is running normal timesharing, although you can't login, and the data lights show only the SYS job getting run.