From GSB at MIT-MC Sun Mar 31 00:00:00 1985 From: GSB at MIT-MC (Glenn S. Burke) Date: 31 March 1985, 00:00 Subject: No subject Message-ID: rolm 4602 calling mc doesn't answer. From Moon at SCRC-STONY-BROOK.ARPA Sat Mar 16 21:25:00 1985 From: Moon at SCRC-STONY-BROOK.ARPA (David A. Moon) Date: Mar 16 85 15:25 EST Subject: Tapes for Swedes 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 at 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. From Moon at SCRC-STONY-BROOK.ARPA Fri Mar 15 01:56:00 1985 From: Moon at SCRC-STONY-BROOK.ARPA (David A. Moon) Date: Mar 14 85 19:56 EST Subject: ITS In-Reply-To: <91827@QZCOM> Message-ID: <850314195652.4.MOON@EUPHRATES.SCRC.Symbolics.COM> From: Bjorn_Danielsson_QZ%QZCOM.MAILNET at 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. From KLH at MIT-MC Thu Mar 7 00:00:00 1985 From: KLH at MIT-MC (Ken Harrenstien) Date: 7 March 1985, 00:00 Subject: Novelty Message-ID: 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. From CSTACY at MIT-MC Thu Mar 7 00:00:00 1985 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 7 March 1985, 00:00 Subject: timestamps Message-ID: 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 From ALAN at MIT-MC Thu Mar 7 00:00:00 1985 From: ALAN at MIT-MC (Alan Bawden) Date: 7 March 1985, 00:00 Subject: MC hardware status Message-ID: The most recent parity errors have occured in MH10-D. Also the microcode hangs about once a week it seems. From CSTACY at MIT-MC Wed Mar 6 00:00:00 1985 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 6 March 1985, 00:00 Subject: No subject Message-ID: (MC is getting the parity errors, not me...) From CSTACY at MIT-MC Wed Mar 6 00:00:00 1985 From: CSTACY at MIT-MC (Christopher C. Stacy) Date: 6 March 1985, 00:00 Subject: No subject Message-ID: We are getting a lot of parity errors lately, although I haven't looked to see where they are coming from. From marty at MIT-HTVAX.ARPA Wed Mar 6 19:59:26 1985 From: marty at MIT-HTVAX.ARPA (Martin David Connor) Date: Mar 06 85 13:59:26 EST (Wed) Subject: Received: lines Message-ID: <8503061859.AA26507@MIT-HTVAX.ARPA> 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 From DEVON at MIT-MC Sat Mar 2 00:00:00 1985 From: DEVON at MIT-MC (Devon S. McCullough) Date: 2 March 1985, 00:00 Subject: No subject Message-ID: 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?