2-Jan-86 08:55:31-PST,905;000000000001 Return-Path: <@CU20B.COLUMBIA.EDU:STAFF.HERSHMAN@NYU20> Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 2 Jan 86 08:55:16-PST Received: from NYU20 by CU20B with DECnet; 2 Jan 86 11:58:32 EST Date: Thu 2 Jan 86 11:58:45-EST From: Ittai Hershman Subject: Cache memory for front-end To: Tops-20@SU-SCORE.ARPA.Internet Office-Phone: 212-285-6068 A seemingly small outfit called Minntronics (St. Paul, MN) recently sent me a direct-mail blurb on cache memory for 11/40 front-ends of DECSYSTEM-%0's. It seems that they have been selling these to PDP-11 customers since 1979, but all of a sudden have discovered the 10/20 market. They claim that several 10/20 customers have bought the cache and found performance improvements of up to 30% or so. Have any of you tried the unit, or heard any reliable information about it? Thanx, -Ittai ------- 2-Jan-86 08:58:03-PST,572;000000000000 Return-Path: <@CU20B.COLUMBIA.EDU:STAFF.HERSHMAN@NYU20> Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 2 Jan 86 08:57:52-PST Received: from NYU20 by CU20B with DECnet; 2 Jan 86 12:01:08 EST Date: Thu 2 Jan 86 12:01:22-EST From: Ittai Hershman Subject: oops To: Tops-20@SU-SCORE.ARPA.Internet Reply-To: Ittai@NYU Office-Phone: 212-285-6068 I meant to add REPLY-TO: Ittai@NYU and hit ^Z to fast... Not all mailers know how to route to my sending address, so please send replies to Ittai@NYU. Sorry, -Ittai ------- 3-Jan-86 13:26:51-PST,407;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Jan 86 13:26:32-PST Date: Fri 3 Jan 86 14:28:43-MST From: Walt Subject: Source for TSTAT To: TOPS-20@SU-SCORE.ARPA Message-ID: <12172366956.9.HAAS@UTAH-20.ARPA> Does anybody have the source for the TSTAT.EXE which is on the TCP/IP tools tape? Thanks in advance -- Walt ------- 8-Jan-86 12:46:19-PST,746;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 8 Jan 86 12:46:09-PST Date: Wed 8 Jan 86 13:47:53-MST From: Randy Frank Subject: DEC Support for TCP/IP To: tops-20@SU-SCORE.ARPA Message-ID: <12173670243.35.FRANK@UTAH-20.ARPA> I just got a copy of the SPD for TCP/IP-20 from DEC. Evidently DEC has unbundled TCP/IP. I assume that if you had a Tops-20AN license then you automatically (free) get a license to TCP/IP-20. However, there is one unbelievable phrase in the SPD dealing with sources: "NOTE: Software built from the sources kit is not supported". Thus, if you are a source code customer, DEC makes no claim that the sources they send you work. ------- 9-Jan-86 06:21:55-PST,328;000000000000 Return-Path: Received: from G.BBN.COM by SU-SCORE.ARPA with TCP; Thu 9 Jan 86 06:21:36-PST Date: Thu 9 Jan 86 09:20:43-EST From: Dan Tappan Subject: DMZ32's To: tops20@SU-SCORE.ARPA Does anyone out there know whether DMZ32's will ever be supported by the KL front-end? ------- 9-Jan-86 17:46:57-PST,998;000000000001 Mail-From: BILLW created at 9-Jan-86 17:46:54 Date: Thu 9 Jan 86 17:46:54-PST From: William "Chops" Westfield Subject: Lisp machines talking to MEIS based 20's To: su-tops-20@SU-SCORE.ARPA Message-ID: <12173986822.16.BILLW@SU-SCORE.ARPA> We have had problems with symbolics lisp machines talking directly to the 10 Mb ethernet interfaces on the local 20's. This turns out to be because the LM is sending a packet whose hardware and software data lengths differ by 2, and the 20 discards all packets whose length differs by more than 1. It turns out that there is a simple patch to tops20 to allow it to accept these packets, which seems to allow LM's and 20's to talk to each other just fine. at IPRCI1-2, change CAILE T1,1 to CAILE T2,2 Since both we and the LM people around here view this as a bug in the LM code, we hope to have it fixed by symbolics. therefore I have put this patch in MONITR.MIC, rather than in the sources. BillW ------- 13-Jan-86 15:22:17-PST,1076;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Jan 86 15:21:44-PST Date: Mon 13 Jan 86 15:24:49-PST From: Ted Shapin Subject: Multiple RP07 query To: tops-20@SU-SCORE.ARPA Phone: (714)961-3393; Mail:Beckman Instruments, Inc. Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634 Message-ID: <12175009532.18.BEC.SHAPIN@USC-ECL.ARPA> Subject: MULTIPLE RP07 STRUCTURE DOES ANYONE KNOW OF A PATCH OR POSSIBLY A SOURCE CODE CHANGE THAT WILL ALLOW A MULTIPLE RP07 STRUCTURE ON TOPS-20 (V5.1 OR V6.1). DEC'S DOCUMENTATION STATES THE ONLY DISK DRIVE THAT CAN'T BE MADE INTO A MULTIPLE SPINDLE STRUCTURE IS THE RP07. WHY? I DON'T KNOW. I ALSO THOUGHT (FROM INFORMATION GATHERED AT DECUS SESSIONS A FEW YEARS AGO THAT THIS WAS GOING TO BE IMPLEMENTED BY VERSION 6), BUT ALAS NO SUCH LUCK. IF ANYONE OUT THERE HAS ANY INFORMATION ON THIS I WOULD SHURE APPRECIATE IT. THANKS. WILL WOOD BECKMAN INSTRUMENTS, X-11 2500 HARBOR BLVD. FULLERTON CA., 92634 ------- 13-Jan-86 15:55:58-PST,770;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Jan 86 15:55:45-PST Date: Thu 19 Dec 85 14:14:43-PST From: Ted Shapin Subject: One-way password transform wanted To: info-ibmpc@USC-ISIB.ARPA, info-cpm@AMSAA.ARPA Phone: (714)961-3393; Mail:Beckman Instruments, Inc. Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634 Message-ID: <12168443171.43.BEC.SHAPIN@USC-ECL.ARPA> ReSent-Date: Mon 13 Jan 86 15:58:50-PST ReSent-From: Ted Shapin ReSent-To: tops-20@SU-SCORE.ARPA ReSent-Message-ID: <12175015725.18.BEC.SHAPIN@USC-ECL.ARPA> I am looking for a one-way transform algorithm that could be used with passwords on 8088 and/or 8080 systems. ------- 13-Jan-86 16:14:52-PST,1468;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Jan 86 16:14:29-PST Date: Mon 13 Jan 86 18:17:47-CST From: Clive Dawson Subject: Re: Multiple RP07 query To: BEC.SHAPIN@USC-ECL.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Ted Shapin " of Mon 13 Jan 86 17:36:22-CST Multiple-RP07 structures are indeed being used at quite a few sites, including Stanford, Univ. of Texas, and here at MCC. There are at least two (possibly more?) different versions of the necessary patches, some of which preserve compatibility with vanilla file structures and some of which don't. We're using one of the versions which does not preserve compatibility, which we got in early 1983 from Mark Crispin. This means that even our traditional, "small" structures must be rebuilt in order to be used by the new monitor. Also, this set of patches really should be used only if you have sources, since one of the .UNV files is involved. The monitor changes are simple, but must be made with care. Changes are also required in the CHECKD program, as well as BOOT and MTBOOT in the front-end area (and floppies). If you have access to the TOPS-20 archives (see the directory at SCORE) you should find several messages on the subject sometime in 1983. If you can't find them, let me know and I'll dig up Mark's original message. Clive ------- 16-Jan-86 14:15:22-PST,1520;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Jan 86 14:14:54-PST Date: Thu 16 Jan 86 15:15:37-MST From: Walt Subject: SYN with a window size of zero To: TCP-IP@SRI-NIC.ARPA, TOPS20@SU-SCORE.ARPA Message-ID: <12175783367.9.HAAS@UTAH-20.ARPA> One of our TCP implementations (TOPS-20) opens a TCP connection with a segment that contains the usual SYN and a window size of zero. According to one interpretation of the spec there should be no legal response to such a segment since the normal response is SYN+ACK and the SYN in the response would take up sequence number space, which does not exist according to the sender of the first segment. According to another intepretation, the window size refers to data octets only, and the sequence number space taken by SYNs and FINs shouldn't count. Various implementations handle this in various ways - some apparantly assume that it's silly to send SYN with a window size of zero, and just go ahead and reply with SYN+ACK. One implementation appears to go into a tight loop in this situation. Does anybody have any references that would resolve the apparent ambiguity? It isn't clear to me how to apply the robustness principle to this case - one could imagine that an implementation could have an unusual situation where it needed to open a connection but didn't at the moment have any place to put a reply. Thanks in advance for any helpful comments -- Walt ------- 16-Jan-86 18:45:52-PST,1168;000000000000 Return-Path: Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Jan 86 18:45:44-PST Date: 16 Jan 1986 21:44-EST Sender: CERF@USC-ISI.ARPA Subject: Re: SYN with a window size of zero From: CERF@USC-ISI.ARPA To: Haas@UTAH-20.ARPA Cc: TCP-IP@SRI-NIC.ARPA, TOPS20@SU-SCORE.ARPA Message-ID: <[USC-ISI.ARPA]16-Jan-86 21:44:33.CERF> In-Reply-To: <12175783367.9.HAAS@UTAH-20.ARPA> Walt, since one could not successfully "open" a connection without getting the matching SYN-ACK, it seems appropriate for the recipient of such a packet to respond, despite the apparent violation. As you know, it is allowed to send at least one octet into a closed (0) window to assure that when it opens you hear that. The SYN can safely elicit an ACK without opening the window any further. Depending on the implementation, some systems don't apply the window size until AFTER the connection has reached the OPEN state which it cannot get to without first exchanging SYN-ACKs. Jon Postel will undoubtedly have a reference to page xx para gg and sugestion to look in one of Dave Clark's marvelous tutorial sections... Vint Cerf 17-Jan-86 03:03:56-PST,3811;000000000000 Mail-From: BILLW created at 17-Jan-86 03:03:51 Date: Fri 17 Jan 86 03:03:51-PST From: William "Chops" Westfield Subject: TVT performace improvements... To: su-tops-20@SU-SCORE.ARPA cc: larson@SRI-KL.ARPA, sarvela@SRI-KL.ARPA Message-ID: <12175923218.10.BILLW@SU-SCORE.ARPA> The following message will be sent to various mailing lists with wider circulation after the code has run for a while. I haven't tested out the sources yet, but SU-Score and SRI-Stripe are both running with equivilent patches that were installed using MDDT. It seems to cause nothing except goodness, especially on Stripe (which is behind a particurally unhappy gateway) - The time it took the sample losing code segment to run went down from 30-40 seconds to a much more reasonable 1-2 seconds... Enjoy BillW ------------------------------ BUG: Under certain situations, throughput on TOPS20 TVTs drops to approximately 0 for long periods of time. I believe that the problem got worse with v6.1, and may be the reason that the TVT SMTP server doesn't work well under 6.1. Reproduce by: I think this shows up best when trying to run a dialout type program while logged in on a TVT. However, the following program will exhibit the problem too: start: movei 6,^d32 loop: movei 1,"%" pbout movei 1,^d30 disms sojg 6,loop haltf Diagnosis: The tops20 TVT scanner attempts to send characters that are part of "echoing" immediately. It's criteria for recognizing "echoes" is that there be fewer than 8 characters in the terminal output buffer. Since the TCP process runs at a very high priority, it will probably get to look at the TTY output buffers if the user process blocks for any reason. In the case above, therefore, there is a good chance that 32 separate 1 byte packets are queued. And there are certainly lots of machines that don't like to receive 32 almost back-to-back short packets. This leads to many retransmissions and excessive use of CPU time on both systems, not to mention any gateways that might be in between them. Fix: Make TOPS20 TCP pickier about what it considers echoing. In addition to there being only a few characters in the buffer, have it insist that the retransmission queue for that connection be empty. (If a person types faster than the Round trip times, it won't hurt to have his echoing clumped together a little anyway.) This is much simpler than having the TCP repacketize retransmissions. The relevant code is in TVTSRV, just before OPSCA7: [This is from 6.1 sources. There should be an easy equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ] SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT JRST OPSCA7 ; No. IFE STANSW,< MOVX T1,^D200 ; The function to queue for PZ if a lot MOVX T2, ; to send - wait a bit, maybe more CAIGE T4,^D8 ; Less that 8 is echoing so MOVX T2, ; Force it now CALL (T2) ; See Note above >;IFE STANSW IFN STANSW,< ;;; there is not going to be any more output if all of the ;;; output buffers are full, so send packets immediately. CALL TTSOBF ;output buffer full? CAIGE T4,^D8 ; or looks like echoing. SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now MOVX T2, ; otherwise wait for more data LOAD T1,QNEXT,<+TCBRXQ(TCB)> ;check if retranmission queue empty? CAIE T1,TCBRXQ(TCB) ;skip if RXQ empty CAIL T4,^D8 ; or if a large packet TRNA MOVX T2, ; otherwise wait for more data MOVEI T1,^D200 ; for a couple hundred millisecs. CALL (T2) ;call appropriate packet routine. >;IFN STANSW OPSCA7: MOVE T2,LINADR ; Restore address of terminal block OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT ------- 17-Jan-86 14:25:12-PST,916;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 17 Jan 86 14:24:46-PST Date: Thu 16 Jan 86 22:37:57-PST From: Mark Crispin Subject: front end cache memory To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12175874812.10.MRC@PANDA> Minntronics Corp, 2599 White Bear Ave., St Paul MN 55109, (612) 770-5247 sells their model 8040AP Cache memory for the PDP-11/40 front end in a DECSYSTEM 10 or 20. They claim a 33% performance improvement on the front end, software transparency, and otherwise no effect on the system. They offer a 2 week free trial. Apparently they just discovered the 10/20 market. I have no relation to Minntronics; I just visited their booth at DEXPO and remembered that people asked about their product. ------- 17-Jan-86 16:38:05-PST,548;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 17 Jan 86 16:38:01-PST Date: Fri 17 Jan 86 16:40:37-PST From: Kirk Lougheed Subject: HLP:DOVER.HLP To: su-tops-20@SU-SCORE.ARPA I've updated the Dover help file to more accurately reflect the state of Dover support these days. It mentions the three Dovers and it reflects the fact that SWITCH.INI is no longer used. If anyone has something better, or wants to do a better job, let me know. Kirk ------- 17-Jan-86 17:21:10-PST,655;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 17 Jan 86 17:21:06-PST Date: Fri 17 Jan 86 17:23:39-PST From: Bill Palmer Subject: new version of GETLOC To: su-tops-20@SU-SCORE.ARPA I improved the GETLOC module for FINGER and friends somewhat so that when confronted with a connection from a TCP-based ethertip, it goes through the same machinations as with a pup connection, rather than just printing [36.40.0.85] or whatever. Relinking with this new GETLOC should fix FINGER, TTYLOC, WIZARDS, etc. It can be found in on Sierra. Bill ------- 18-Jan-86 00:42:13-PST,1061;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 18 Jan 86 00:42:04-PST Date: Sat 18 Jan 86 01:42:36-MST From: Jay Lepreau Subject: Re: SYN with a window size of zero To: CERF@USC-ISI.ARPA cc: Haas@UTAH-20.ARPA, TCP-IP@SRI-NIC.ARPA, TOPS20@SU-SCORE.ARPA In-Reply-To: <[USC-ISI.ARPA]16-Jan-86 21:44:33.CERF> Message-ID: <12176159649.11.LEPREAU@UTAH-20.ARPA> This recently came up in another context: the TAC's put garbage in the window field in their initial SYN, all the way up to 64K. This raised havoc with some of our hosts which remembered the max window size they'd ever seen. I talked to the TAC folks at BBN who maintained that since the window is only defined relative to the ack seq number, the window is meaningless unless ACK is set, and therefore it's not their bug, it's ours. Sounds plausible, so we fixed it here. (A zero initial window is quite good behavior, in contrast with the TAC's, which are clearly violating the robustness principle.) ------- 18-Jan-86 01:13:05-PST,693;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 18 Jan 86 01:12:47-PST Date: Sat 18 Jan 86 00:24:44-PST From: Mark Crispin Subject: TOPS-20 EGP implementation To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12176156395.8.MRC@PANDA> An implemention of the Exterior Gateway Protocol (EGP) now exists for TOPS-20. This allows a multi-homed TOPS-20 system to be used as an Internet gateway in the brave new world that no longer allows "dumb" gateways. Interested parties should contact me. -- Mark -- ------- 19-Jan-86 12:38:55-PST,685;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 19 Jan 86 12:38:52-PST Date: Sun 19 Jan 86 12:41:34-PST From: Kirk Lougheed Subject: bugfix to TFTPSR To: su-tops-20@SU-SCORE.ARPA I've fixed the bug in TFTPSR that caused it to not timeout inactive connections, which eventually resulted in a hung server. TFTPSR is used to boot configuration files for SUNBOOT13, version 4.2 and greater. If you have a -20 that is booting configuration files, you must install this new version of TFTPSR. The binary is SYSTEM:TFTPSR.EXE, the source is PS:TFTPSR.MAC.8, both on Sierra. Kirk ------- 20-Jan-86 22:21:39-PST,647;000000000000 Mail-From: BILLW created at 20-Jan-86 22:21:35 Date: 20 Jan 1986 22:21-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: new version of GETLOC From: William "Chops" Westfield To: whp4@SU-SIERRA.ARPA Cc: su-tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]20-Jan-86 22:21:35.BILLW> In-Reply-To: The message of Fri 17 Jan 86 17:23:39-PST from Bill Palmer I made some more modifications to TTYLOC: Have the new TVT code pay attention to GL%DES (description only) flag. Add a $RMREL in NAMTVT or some such - prevents [36.8.0.60].#Internet The sources at sierra have been updated. BillW 21-Jan-86 09:28:43-PST,1315;000000000000 Return-Path: Received: from cu-arpa.cs.cornell.edu by SU-SCORE.ARPA with TCP; Tue 21 Jan 86 09:27:53-PST Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA14957; Tue, 21 Jan 86 12:29:51 EST Date: Tue, 21 Jan 86 12:29:36 est From: george@gvax.cs.cornell.edu (George R. Boyce) Message-Id: <8601211729.AA00457@gvax.cs.cornell.edu> Received: by gvax.cs.cornell.edu (4.30/4.30) id AA00457; Tue, 21 Jan 86 12:29:36 est To: tops-20@su-score.arpa Subject: V6.1 distribution I finally got my source distribution and a have a few flames/questions. In fall of 84 and spring of 85, at DECUS, I was told I'ld receive the distribution around early November. That was considered a safe date by the nervous digital spokesperson... Not even he thought that it would take longer than that. Well, here are the dates I see on my material: exec tape written: 08/27/85 exec letter dated: 09/05/85 mon letter dated: 09/05/85 rsx20f letter written:09/05/85 mon tape written: 09/20/85 rsx20f pack written: 12/05/85 received by shipping: 12/11/85 expected delivery: 01/17/86 received: 01/21/86 Am I missing something or did this process take an unreasonable amount of time?? george Boyce, Cornell Computer Services, george@cornell 21-Jan-86 12:08:23-PST,469;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Jan 86 12:05:37-PST Date: Tue 21 Jan 86 13:06:46-MST From: Randy Frank Subject: Re: V6.1 distribution To: george@GVAX.CS.CORNELL.EDU, tops-20@SU-SCORE.ARPA In-Reply-To: <8601211729.AA00457@gvax.cs.cornell.edu> Message-ID: <12177070629.23.FRANK@UTAH-20.ARPA> I think it's called what happens when a vendor has written off a product. ------- 21-Jan-86 18:31:23-PST,902;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Jan 86 18:27:30-PST Date: Tue 21 Jan 86 18:22:34-PST From: Stu Grossman Subject: Re: V6.1 distribution To: FRANK@UTAH-20.ARPA cc: george@GVAX.CS.CORNELL.EDU, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Tue 21 Jan 86 14:11:12-PST Actually, its an artifact of the SDC (Software Delay Center). This is the group within DEC that has to bless all tapes before they get shipped to customers. Supposedly, they do the tape copying and final shipment. In reality, they just sit on the tapes for at least one fiscal quarter, and then send the originals back to Marlboro where the actual distribution copies are promptly made. Note that the last part of this process only occurs for LCG tapes. Stu Grossman ------- 22-Jan-86 18:08:39-PST,639;000000000000 Return-Path: Received: from cu-arpa.cs.cornell.edu by SU-SCORE.ARPA with TCP; Wed 22 Jan 86 18:04:43-PST Message-Id: <8601220005.AA16734@cu-arpa.cs.cornell.edu> Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA16734; Tue, 21 Jan 86 19:05:39 EST To: tops-20@su-score.arpa Subject: tops-20 V6.1 distribution Date: Tue, 21 Jan 86 19:03:51 -0500 From: george@vax3.ccs.cornell.edu And on top of the 4+ months it took to get the exec/monitor source distribution, it of course arrived without monsym and macsym. Sigh. George Boyce, Cornell Computer Services, george@vax[1234].ccs.cornell.edu 24-Jan-86 00:04:08-PST,647;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 23 Jan 86 23:59:34-PST Date: Fri, 24 Jan 1986 01:02 MST Message-ID: From: "Frank J. Wancho" To: TOPS-20@SU-SCORE.ARPA Subject: Semi-automated BUILD I know of MIT's OPEN package and SUBDIR. What do you or your administrators use to set up login directories other than BUILD? Points to sources welcome! If there is sufficient interest, I'll summarize your replies and make whatever source I collect available (with the authors' permission, of course). Thanks, Frank 24-Jan-86 05:58:27-PST,2767;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 24 Jan 86 05:58:14-PST Date: Fri, 24 Jan 1986 07:29 EST Message-ID: From: Rob Austein To: MRC%PANDA@SUMEX-AIM.ARPA, SU-TOPS-20@SU-SCORE.ARPA Cc: sra@XX.LCS.MIT.EDU Subject: Twenex domain resolver In-reply-to: Msg of 20 Dec 1985 14:42-EST from Mark Crispin I just happened to be digging through the TOPS-20 mail archive (trying to figure out why the spiffy new TCP code we stole from you and other people is consistently hanging solid in the IP fork), and happened to notice that Mark had forwarded my flame about domain resolver lossage here. So an update seems in order. I have been in touch with Mockapetris again recently. I understand from him that you people have 6.1'ified GTDOM, but I don't know how current you are or if you are running a resolver. Anyway, Paul says he is about ready to release this thing publicly (I think he may even mean it). In the last few days he has fixed several major standing bugs, including one that was causing XX to emulate a yoyo earlier this week (deadly embrace in the locking code, triggered by environmental conditions like cache timeouts). He also fixed the bug I mentioned to Mark earlier where the resolver was throwing legal packets on the floor. I don't have this stuff up yet, but XX was running tolerably well (until this week) even with a number of major bugs in this code, so with a little bit of luck the new code will at least be runable without constant care and feeding. As an added bonus, he just added support for MX entries, complete with (sez he) a frob to generate MXs from MDs and MFs. Haven't seen this part yet. I expect to have the current stuff up on XX within the next week. If you are interested I will let you know how it goes. While I am blathering.... Quite a while back I rewrote a then-current copy of GTDOM.MAC to use IFSKP./ENDIF. and DO./ENDDO. rather than Paul's rather amusing coding style. I am now in the process of (groan) merging his bugfixes into my code (to be fair, he has cleaned up a lot from the version that got me disgusted enough to rewrite it). Anyway, once this mess settles down a bit, would you people be interested in using the structured version? I despair of ever getting Paul to distribute it, the one time I tried to talk to him about it he started on about paging characteristics of structured code. But I suspect that if Stanford and MIT are both promoting a more reasonable version the majority of sites would use it ("Help stamp out labels in literals!"). Let me know if you are interested in this. --Rob 24-Jan-86 10:47:21-PST,1139;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 24 Jan 86 10:43:21-PST Date: Fri 24 Jan 86 10:09:42-PST From: Mark Crispin Subject: Re: Twenex domain resolver To: SRA@XX.LCS.MIT.EDU cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12177835749.9.MRC@PANDA> Rob - I certainly am interested in a 5.4 version of your code for the PANDA monitor. Sooner or later, Milnet and DREnet will adopt domains. How stable is your 5.4 code? I don't understand what Mockapetris has against structured code. If anything, it should have better paging characteristics than code using lots of literals; of course, this makes more of a difference on machines like the SC30M than a KL10. I'll lobby around Stanford for adoption of your code. SUMEX is the last 5.3 holdout, but will be migrating to 6.1 real soon. I hope that the 6.1 changes to GTDOM are under a REL6 flag... -- Mark -- ------- 24-Jan-86 20:11:04-PST,2025;000000000001 Mail-From: HEGARTY created at 24-Jan-86 20:10:47 Date: Fri 24 Jan 86 20:10:47-PST From: Paul Hegarty Subject: Common File System Login capability To: TOPS-20@SU-SCORE.ARPA Message-ID: <12177945175.22.HEGARTY@SU-SCORE.ARPA> Last August, I made modifications to our 6.1 Monitor to allow the "login structure" (that is to say, the structure which contains login directories) to be on a disk pack other than "PS:". System boot-up and swapping do NOT occur on this pack, only logins. Since we have run this software for 5 months without mishap (with 8000 users across 3 systems), and since DEC may not be offering something similar for a while, I want to make it generally available. The obvious purpose of this is to allow for CFS sites to give each user ONE directory which he can log into from any of the systems. The boot-up pack need only have the 17 or so basic directories and a total of about 30 files (including catastrophe files if you keep your SUBSYS and most of your SYSTEM:, etc. on the common structure). Only the monitor changes need be made (there are no EXEC or Galaxy hacks). All user software works under this scheme save for ones which use HRLI AC,540000 constructs (instead of RCDIR) to find login directories. Also, PS: can be defined to be either the login structure OR the boot-up structure, so, whichever way you define it, programs that use "PS:" and mean the other structure will obviously not work. Note that if you define PS: to be the user structure, Galaxy will break (since it so graciously uses PS: instead of SPOOL: or some such). Mail works as long as you point POBOX: to the login structure and get the latest version of MM. The sources are in [SU-SIERRA]PS:. There is documentation as well as REDIT files. Note that two of the changes only apply to Stanford Monitors (re: Unix style directory naming). Feel free to contact me (Hegarty@Sierra) with questions or suggestions. ... Paul ------- 24-Jan-86 22:41:06-PST,2591;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 24 Jan 86 22:40:57-PST Date: Sat, 25 Jan 1986 01:39 EST Message-ID: From: Rob Austein To: Mark Crispin Cc: SRA@XX.LCS.MIT.EDU, SU-TOPS-20@SU-SCORE.ARPA Subject: Twenex domain resolver In-reply-to: Msg of 24 Jan 1986 13:09-EST from Mark Crispin My 5.4 code is pretty much the same functionality as Paul's 5.0 code (modulo his recent bugfixes which I am currently installing). The one major bug I know of is that the wait loop for the resolver has to run NOINT, which means that you lose big if the resolver ever goes away or hangs. It has to run NOINT because there are some resources in the shared database which GTDOM% has locked down while it is waiting for the resolver; most of these locks could probably be dispensed with (with some work), but the cache lock is a problem. The resolver passes back pointers to RRs in the cache, and for this to work the process receiving the pointers has to already hold a read lock on the cache (which the resolver carefully ignores when it gets its write lock!), since otherwise the cache gc process (when it exists) could slip in that window and do something that invalidates the pointer. I don't know of any way to really fix this and still use the shared memory idea, which would put us back with VAF's idea of having .GTDOM/.GTHST use IPCF to talk to the resolver, which is kind of high overhead. My current plan is to install this kludge (purely as a workaround, I hasten to add) where the resolver wait loop (which is a busy wait, not a DISET) will also check INTDFF to see if there is an interrupt trying to happen (ie, check if INTDFF<>SOS INTDF or whatever the cannonical value is). I really don't like this idea, so if you have a better one, holler. I could repeat Paul's ideas on paging but I don't think they are relevant. I think the real issue with Paul's assembler code is just that he doesn't believe there is such a thing as elegant assembler code so he doesn't try. It is pretty easy to see which parts of .GTDOM were written by Paul and which by Wook. I'll send another message to this list when I get my version up to what Paul is currently distributing. I'm not going to have much more time for hacking this in the near future, since it looks like I am taking over maintanence of COMSAT and getting it to grok domains, but we can work something out. --Rob 25-Jan-86 21:27:09-PST,1882;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Jan 86 21:26:51-PST Date: Sun 26 Jan 86 01:30:09-AST From: Peter Gergely Subject: New version of CHKBBD available To: TOPS-20@SU-SCORE.ARPA Reply-To: PETER@DREA-XX.ARPA Postal-address: 9 Grove St., P.O. Box 1012, Dartmouth, NS B2Y 3Z7, Canada Phone-Number: (902) 426-3100 x 215 [8:30am to 4:15pm Atlantic time] Message-ID: <12178221766.16.GERGELY@DREA-XX.ARPA> For all of you that use CHKBBD (check bulletin board IDX files), to clean up your BBOARD database entries, there is a new version available. It can be FTP'ed ANONYMOUSly from DREA-XX on CHKBBD.MAC. New features include: - a FORMAT subcommand and/or switch with keywords NORMAL, USER, BRIEF which result in the NORMAL display; one showing a USER, his read time and the file on a one line entry; and just the number of readers respectively - an OUTPUT subcommand and/or switch which allows an output file to be given - a DAYS subcommand and/or switch which allows you to remove entries whose last read date is older than the current date minus the number of DAYS given (default 366 days). - a DATE subcommand and/or switch which allows you to specify an exact date for entry extinction (see DAYS). - Complete cleanup of .IDX files whose corresponding mail file is empty, nonexistant, or deleted. This leaves the .IDX file with 0 length. If you pick it up you will also need PJGSYM.*, and possibly CMD.* to compile it and make modifications. Please let me know if you do grab the file, as I would like to maintain an update list, rather than bother the whole TOPS-20 list. CHKBBD will also accept an indirect file for input (useful for keeping a list of active bboards). - Peter ------- 27-Jan-86 15:28:01-PST,651;000000000000 Mail-From: BILLW created at 27-Jan-86 15:27:57 Date: Mon 27 Jan 86 15:27:57-PST From: William "Chops" Westfield Subject: new 6-1-setspd To: su-tops-20@SU-SCORE.ARPA cc: drf@SU-SCORE.ARPA Message-ID: <12178680117.19.BILLW@SU-SCORE.ARPA> I added an INHIBIT keyword to the TERMINAL command of SETSPD. This sets the TTNTM bit in the terminal data, which is essentially a REFUSE ALL MESSAGES bit in static storage, and can be used to prevent terminals that should NEVER receive sends (such as the APS on Score) from getting screwed. Source code (not yet tested) on sierra in <6-1-sources>SETSPD.MAC BillW ------- 28-Jan-86 22:24:40-PST,376;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Jan 86 22:24:31-PST Date: Tue 28 Jan 86 22:27:07-PST From: Bob Albrightson Subject: xns To: tops20@SU-SCORE.ARPA I am looking for an implementation of NS for tops20. Does anybody know where I can find such a beast? -thanks. -bob ------- 29-Jan-86 15:48:10-PST,617;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 29 Jan 86 15:48:06-PST Date: Wed 29 Jan 86 15:49:55-PST From: Kirk Lougheed Subject: bboard program To: su-tops-20@SU-SCORE.ARPA The file PS:BBOARD.DREA is the latest version of BBoard from DREA, incorporating some changes/fixes/whatevers from UTEXAS-20. It appears to be pretty close to the BBOARD.MAC that we're running here. If anyone is interested in checking it out and possibly making the DREA version be the Stanford version, please do so. Kirk ------- 31-Jan-86 14:47:48-PST,1999;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 31 Jan 86 14:47:33-PST Date: Fri 31 Jan 86 17:50:56-EST From: Thomas De Bellis Subject: EXEC problem with use of private Galaxy To: Tops-20@SU-SCORE.ARPA Message-ID: <12179721955.11.SY.SLOGIN@CU20B.COLUMBIA.EDU> Recently, I was testing out a new version of Galaxy here at the Columbia Computer Center. The testing was going on in GLXLIB `private' mode so I wouldn't interfere with normal system usage. In particular, I was checking out some code that I had added to MOUNTR at the request of our operations department. I issued a cancel command to throw out a test mount request that I had queued and boy was I ever surprised to find out that my job wedged! My changes were so small... It turns out after a lot of detective work that the bug of my EXEC hanging in private Galaxy mode is, in fact, an EXEC bug and a rather old one at that. I have verified that it exists in current 6.1 sources. Briefly, when you go into private Galaxy mode, the EXEC goes through some logic to get the PID of the private Quasar that you are running so that you can exchange IPCF messages with it. Unfortunately, when you are doing mount'ish things, you can also get messages from the moby device animal but the EXEC never bothers to find this private PID out. Thus, you are left with the situation where QSRPID points to a private Quasar (like it should) and MDAPID is left pointing to the system MOUNTR (like it *shouldn't*). When messages come in from the private MOUNTR, they are not recognised as such and they are tossed by the EXEC and you hang. Neat huh? The EXEC changes are pretty minimal. If any of you are scratching your heads about this, drop me a note and I'll mail them to you. They are for a 5 EXEC, but are trivially tailored to a 6 EXEC. -- Tom De Bellis Columbia Computer Center ------- 3-Feb-86 16:41:12-PST,2495;000000000001 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Feb 86 16:41:01-PST Date: Mon 3 Feb 86 18:12:40-CST From: Clive Dawson Subject: IPNIDV patch to prevent IPGHTF's. To: tops20@SU-SCORE.ARPA Symptom: IPGHTF BUGINF's and failure to establish network connections. Diagnosis: IPGHTF's indicate that the ARP tables (pointed to by GHTAR1 and GHTAR2) are full. The recommended action is to increase the size of these tables by upping NIMAXH. Unfortunately, this will not always solve the problem. We had NIMAXH set to 200. and a network with only about 100. hosts. Inspecting the table pointed to by GHTAR1 revealed that each host had multiple (as many as 5 or 6) entries, causing the table to fill up prematurely. This led to the discovery of a bug which was introduced when a binary search algorithm was added to speed up ARP table searching. In particular, when the binary search exits with failure, T1 and T2 are supposed to point to the table locations where the new entry can be inserted. This is only true half the time, when the last entry examined is .gt. the target. When the last entry examined is .lt. the target, the appropriate insertion point should be one greater. Cure: At ISRCH+10 in IPNIDV.MAC, change CAMG T2,(T1) ;HOST # .GT. MIDDLE ? IFSKP. MOVEI P1,1(P2) ;YES. LOW = MIDDLE + 1 JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED ENDIF. JUMPE P2,ISNFND ;IF MIDDLE IS ZERO, DONE - NOT FOUND to: CAMG T2,(T1) ;HOST # .GT. MIDDLE ? IFSKP. MOVEI P1,1(P2) ;YES. LOW = MIDDLE + 1 AOS T1 ; Adjust T1 & P2 to point to correct the AOS P2 ; insertion point in the case where ; the last entry examined is .LT. host. JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED ENDIF. JUMPE P2,ISNFND ;IF MIDDLE IS ZERO, DONE - NOT FOUND This patch was apllied to our 5.4 monitor and all is working fine. Examination of the sources for TCP/IP-20 Version 4.0 reveals the same problem, so this patch should apply to 6.1 as well. Cheers, Clive P.S. Here's a small addition to TOPS-20 folklore: A messed-up ARP table (either due to the above bug or to host address changes) can be fixed on the fly with no apparent ill effects by entering MDDT and setting GHTCNT to 0. ------- 3-Feb-86 22:17:07-PST,918;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Feb 86 22:16:56-PST Date: Tue 4 Feb 86 00:22:03-CST From: Clive Dawson Subject: Initializing the ARP table To: tops-20@SU-SCORE.ARPA Regarding my bit of folklore in a previous message, Chuck Hedrick just reminded me of the "ETHERNET INITIALIZE (ADDRESS MAPPING FILE)" command in IPHOST. Hopefully safer, it will, however, deprive you from experiencing that exquisite split-second between typing carriage return to MDDT and knowing you've avoided a BUGHLT. (Anybody have a good Sniglet* for that?) Clive (*) (TM) For those who don't know, a Sniglet is any word that doesn't appear in the dictionary but should. A good example in this case is IGNISECOND, the overlapping moment of time when the hand is locking the car door even as the brain is saying "my keys are in there!" ------- 4-Feb-86 04:43:41-PST,2709;000000000000 Mail-From: BILLW created at 4-Feb-86 04:38:11 Date: Tue 4 Feb 86 04:38:11-PST From: William "Chops" Westfield Subject: results of tonights hacking... (TCP stuff). To: su-tops-20@SU-SCORE.ARPA Message-ID: <12180658983.2.BILLW@SU-SCORE.ARPA> It turns out that the tops20 retransmitter seems to run a lot more often than it should. In particular, it gets signaled to run whenever an ACK is received (in REMSEQ) AND/OR whenever "packets previously made untransmittable ...become transmittable". The time interval used in these cases was either the next retransmission time as calculated by the "packet last transmitted time" plus the "packet rexmit interval". Unfortunately, the retransmission scheme used to probe a 0 window sets the next time to run the RX process a long ways (2 minutes) away, but does NOT update the packet retransmission interval. Thus what happens when output is sent to an ethertip that has returned to its exec is that the probe packet is retransmitted at whatever the last retransmission interval for that connection was (typically 300 ms or so), and the tip responds with an ACK for old data and a 0 window, which causes REMSEQ to signal RX again, completely bypassing the long retransmission interval that should be used for the 0 window probe. In addition, the second piece of code (I haven't quite figured out what it THINKS it's doing yet), appears to contain some sort of fencepost error, as RX is frequently started up on a TCB, only to decided that it doesn't have any packets to retransmit! More wasted cycles. I plan to look into this further. So. I added code to avoid signaling RX when the send window is 0. This appears to cause the system to behave much more reasonable for this case. I also believe that this code will properly fail to timeout a connection when the send window is zero, but that has not been extensively tested. The new code is on Score in <6-1-MONITOR> (in TCPTCP). This version also contains new code for scanning TVT output - it looks at a bitmap instead of carefully locking and examining the dynamic data for ALL the TVTs each time (in TVTSRV). It seems to work fine. (What happened to <6-1-exp-mon>? Well, that contains the REALLY new stuff (it doesn't even compile yet.) The (un)special handling of DEC TCP buffers with respect to not thrashing page tables is now also in this TCPTCP (it has been in <6-1-exp-mon>, and running on Score and Sushi for some time now, without any apparent problems). For kicks, Score also contains a runtime patch to count the times that RX decided is didn't have anything to do after all in REXABT. Enjoy BillW ------- 5-Feb-86 15:15:17-PST,1223;000000000000 Return-Path: Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Feb 86 15:14:38-PST Received: from bostonu by csnet-relay.csnet id ab15094; 5 Feb 86 16:19 EST Received: from BUCS20 by bu-cs.ARPA (3.0/4.7) id AA29434; Wed, 5 Feb 86 14:41:08 EST Date: Wed 5 Feb 86 14:40:02-EST From: Philip Budne Subject: TOPS-20 RSHD/RMT To: tops-20%SU-SCORE@bu-cs.bunet Message-Id: <12180997923.21.BUDD@BUCS20> I have written a Un*x style RSHD (Remote Shell Daemon), that uses proxy login on a TVT to provide a remove command interpeter. I have been trying to implement an RMT (remote tape protocol) server under TOPS-20 so that we can make better use of the '20s TU78. RMT is a program running on a TVT (with every terminal mode bit frobbed that I could think of), listening for tape commands. The BSD rdump program connects up, issues an open and a write for 10240 characters. (ie; "W10240\n.....). However, we lose data, and the RMT hangs waiting for the rest of the block. Systems: TOPS-20 5.4(1025) vs. SUN/3 3.0, 11/750 BSD 4.2, SUN/2 Any guesses to why the data lands on the floor? ------- 5-Feb-86 15:47:58-PST,1990;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Feb 86 15:47:43-PST Date: Wed 5 Feb 86 17:52:26-CST From: Clive Dawson Subject: Another ARP patch To: tops20@SU-SCORE.ARPA Another bug in the ARP table updating routines has been uncovered. Here's another patch which should be applied together with the one I sent out a couple of days ago. SYMPTOM: ARP table messed up. Entries out of order and extraneous 0 entries. Monitor will at the very least generate a lot of unnecessary ARP traffic. DIAGNOSIS: When the ARP search routine fails to find an entry, it returns a pointer which tells where to insert the new entry. Sometime later the actual update takes place, and the monitor carefully goes NOSKED to make sure nobody else tries a simultaneous update. However, updates may have already taken place by this time, making the pointer returned by the previous search invalid. CURE: After going NOSKED, call the search routine again to make sure the insertion pointer is valid. In IPNIDV.MAC, at ARPUPD+3, change: NOSKED ;DON'T LET OTHERS INTO THE GHT MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE to: NOSKED ;DON'T LET OTHERS INTO THE GHT MOVE T2,SPADR ;Get internet address CALL INTSRC ;Search table again to ensure pointer is valid SKIPA ;Not found, as expected JRST [OKSKED RET] ;Aha! Somebody else did it for us MOVEM T1,AREA1 ;Save insertion pointers MOVEM T2,AREA2 ;... MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE ................. BTW, I'm also a bit concerned about the following code at the end of ARPUPD: OKSKED ;TABLE IS SAFE NOW MOVX T1,GH%ARP ;GET UPDATED BY ARP FLAG IORM T1,GH.GCF(T3) ;SET IT IN THE GHT RET It seems to me that the flag should be set *before* going OKSKED, since, again, there is a possibility that another update will happen and the pointer in T3 will be invalid. Clive ------- 5-Feb-86 18:39:40-PST,538;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Feb 86 18:39:29-PST Date: Wed 5 Feb 86 18:17:08-PST From: Bruce Tanner Subject: PCL To: TOPS20@SU-SCORE.ARPA Message-ID: <12181070213.33.CERRITOS@USC-ECL.ARPA> While building a PCL exec from the tools tape, I noticed that no PCL documentation was included. If the 6.1 PCL is different from the 5.1 version, does anybody have the new documentation? Also, why no source code? Thanks, -Bruce ------- 6-Feb-86 08:52:03-PST,4988;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 08:51:47-PST Received: from (MAILER)UDCVM.BITNET by WISCVM.WISC.EDU on 02/06/86 at 10:13:33 CST Return-path: RJONES@UDCVM.BITNET Received: by UDCVM (Mailer X1.23) id 6375; Thu, 06 Feb 86 10:37:41 EST Received: by UDCVM (Mailer X1.23) id 4115; Tue, 04 Feb 86 18:10:07 EST Date: Tue, 4 Feb 1986 16:12 EST From: Rob Jones Subject: Minntronics Cache for KL FE To: CC: We recently installed the Minntronics memory cache in the Front End 11/40 of our 2065. We did this as a experiment to determine if we could add to the throughput capability of the FE under heavy terminal loads. The cache installs very easily, Field Service did the installation for us and charged the usual 2 hour minimum, though we had to pay for an additional 3 hours as a result of some complications I will describe later. We became aware of the product as a result of seeing it at work in a DN2xx remote station on a DEC10 ANF10 network. A local DEC10 site has been using it with 11/40s and Emulex DH emulators (CS11) successfully for quite a few years without ever replacing it. The DEC10 site had done some benchmarking and found that the cache increased the throughput of the 11 by about 30%. We are using the Emulex CS11 in our FE on the DEC20 and have not had any trouble at all with it. We support 32 lines with one Unibus slot in the FE box in addition to the 96 lines we have on the usual DHs. That worked so well that we decided to try the cache. Getting the cache installed and testing it took a little doing. At first we did not know how to coordinate this through DEC FS. So we just went ahead and installed it ourselves. The cache worked fine for about a day and then it died from infant mortality. We pulled it out, put back the Unibus jumper and breathed a sigh of relief when the system booted without further trouble. The local DEC FS manager then educated us about the advantages of having them do such installations. They were quite supportive of the project. We returned the cache and arranged for another installation, this time with DEC FS and the local Minntronics people in attendence. Unfortunately, the system would not boot with it inplace. There is a switch on the cache which isolates it electronically from the Unibus, and it had no effect on the boot problem, so we figured that we had a DOA board. We sent it back and let the project rest for a while. This summer we had funds to purchase the Minntronics cache and decided to tryd again. Unfortunately the arrival of the cache coincided with the arrival of our MCA25 upgrade and the installation of the Minntronics was deferred until our system became stable (-we had some trouble with the MCA25 installation). We kept asking DEC FS about installing the cache, and our CE at the time was dragging his feet about it. Finally we had a change in CEs and the new fellow was quite enthusiastic about it. We made an attempt to get the new cache installed at the end of the fall semester but the cache turned out to be defective, which cost us 3 hours of FS charges for the FE diagnosis. The diagnosis was done because we couldn't believe that we had another DOA board. So our CE got another DEC FS engineer out here who had experience installing the same cache in the FE of a 1091. He helped our CE shake out the FE, determining that it was in good shape and that the cache was at fault. We called Minntronics and got another module via overnight air express. It was installed two weeks ago and the system has been running just fine. You may be wondering "Does it speed up the FE?" I wish I could give you some numbers, but the only evaluation I can give is subjective. Local terminals seem to run "faster". But with our beginning of our spring semester rush we have not had the time to do any benchmarks. We hope to be doing some benchmarks within the next couple of weeks to see if the cache is doing anything for the FE. I frankly do not expect to see a dramatic difference. From my discussions with the DEC10 site systems people I feel that we will see a statistical improvement under high terminal I/O loads, where the aggregate speed of I/O will improve rather than users saying "Jeez, the system is faster!". By the way, the only difference to the standard "B STRING" diagnostics was that one of the KL clock tests complained that a KL clock was slow when running with the cache active. The cache can be disabled in software, as well as by flipping a little switch on its front panel. The DEC10 site has their 11 diagnostics patched to disable the cache when running the memory diagnostics. Not having sources, we can't do the same for our FS CE. If you are interested I will let you know how our benchmarks turn out. 6-Feb-86 16:08:48-PST,972;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 16:08:23-PST Date: Thu 6 Feb 86 18:13:42-CST From: Clive Dawson Subject: Features of TOPS-20 Version 7 To: tops-20@SU-SCORE.ARPA Folks-- The DECUS Large Systems SIG is putting together some input for DEC about what features/enhancements/fixes/cleanups they should include in TOPS-20 version 7. Note that version 7 will likely be the last official (DEC-released) version of TOPS-20, so this is really our last chance to give them any input. The only constraint here is that I need your comments *quickly*, i.e. within a week. We were planning to give this sort of info to DEC at Spring DECUS, but it turns out that it will fit into the planning schedule much better if we give it to them this month. Please send directly to me at CLIVE@MCC. I'll summarize the results and post them on the list. Thanks, Clive ------- 8-Feb-86 15:20:47-PST,6898;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sat 8 Feb 86 15:20:28-PST Date: Sat 8 Feb 86 18:26:30-EST From: Charlie C Kim Subject: DEQNAs and NI-20s - an update To: tops-20@SU-SCORE.ARPA cc: US.CCK@CU20B.COLUMBIA.EDU Message-ID: <12181825583.12.US.CCK@CU20B.COLUMBIA.EDU> In a previous message, a problem with communications between TOPS-20 and DEQNA based systems was reported. After further experimentation, the following has been found. First, let's emphasize that the problem probably extends to any system which sends an ARP packet of size 64 or larger (tested on DEQNA and DECNA (CTI bus)). Second, though a minimum packet size of 60 on the DEQNA seems to present a number of problems, a packet size of 62 seems to work okay. Third, the solution of using the internet to ethernet mappings file doesn't work too well when the DEQNA based system is a SUBARP gateway; this means that you have to put every host on the other size of gateway in this file! Fourth, the idea of modifying TOPS-20 to accept ARP packets of size 64 isn't very good since it is already supposed to do that! The following describes the problem with TOPS-20. Problem: The ARP "portal" on TOPS-20 is configured to receive packets of size 64. Though packets of this size are received, they seem to be corrupt by the time they reach the IPNIDV routines. Packets of sizes 60 and 62 are received correctly. The packets are known not to be corrupt; this is based upon correct functioning with other systems and actually watching ARP packets go by on the network. See end for examples of the corruption. Diagnosis: In IPNIDV, AR.WRD is the number of words in a ARP buffer and AR.MAX is the number of bytes in the buffer which is posted as usable to the NI-20 for a receive. Both values exclude the ethernet header. AR.WRD is set to +4 words, AR.MAX is to MINPKT+4 bytes, and MINPKT is 50 bytes. MINPKT is the number of data bytes plus 4 bytes for the CRC. (The reasons for including this in the data buffer isn't clear to me; I think it has something to do with the internal loopback). The +4 for AR.MAX is probably the fuzz factor (amount by which we are willing to receive over the nominal specification). The +4 for AR.WRD seems to translate into: 1 word for fuzz bytes, 1 word for rounding, 1 word for the header, and 1 other word (reason for allowing it not discernable). AR.MAX specifies 54 bytes. Dropping the four bytes for the CRC, this should be sufficient to handle an incoming 64 (50+14) byte packet. AR.WRD seems to be large enough too (as a matter of fact, it seems to be one word too large). Something goes wrong though. Possible the NI-20 driver (module PHYKNI) or NI-20 is doing something wrong. (Maybe something wraps around????) Solution: Maybe set ar.max to receive a 66 byte packet? Appendix: The following information was obtained by reading the ARP send buffers with XPEEK%. Though there can be no guarantees to the validity of the data, it seems to be indicative of what the NI-20 has received. In the following, the first two packets were send from a DEQNA based system and the third from a DECNA based system (CTI bus) with packet sizes set to 62, 64, and 66 respectively. In the dumps, there are 4 fields. The first is the starting byte. The second is ,, in octal. The third is the 4 bytes in hex. The last is the four bytes in decimal. Send buffer with Request opcode, ethernet hardware Protocol type: INTERNET Source hardware address: 08-00-2B-02-68-23 Source protocol address: CU-CC.COLUMBIA.EDU (128.59.32.139) Destination hardware address: 00-00-00-00-00-00 Destination protocol address: CUCCA.COLUMBIA.EDU (128.59.32.134) Buffer dump: 1/ 4000,,0 08-00-00-00 8.0.0.0 5/ 1,,4000 00-01-08-00 0.1.8.0 ;Hardware type,,protocol 9/ 3004,,1 06-04-00-01 6.4.0.1 13/ 4000,,25402 08-00-2B-02 8.0.43.2 17/ 64043,,100073 68-23-80-3B 104.35.128.59 21/ 20213,,0 20-8B-00-00 32.139.0.0 25/ 0,,0 00-00-00-00 0.0.0.0 29/ 100073,,20206 80-3B-20-86 128.59.32.134 33/ 1507,,150627 03-47-D1-97 3.71.209.151 37/ 50020,,4000 50-10-08-00 80.16.8.0 41/ 46110,,0 4C-48-00-00 76.72.0.0 45/ 61543,,65400 63-63-6B-00 99.99.107.0 49/ 54040,,46101 58-20-4C-41 88.32.76.65 53/ 76602,,172574 7D-82-F5-7C 125.130.245.124 57/ 0,,0 00-00-00-00 0.0.0.0 61/ 0,,0 00-00-00-00 0.0.0.0 Send buffer with Request opcode, unknown hw type - 9491! Protocol type: 0! Source hardware address: 08-00-2B-02-34-7B Source protocol address: CUCCA-WP.COLUMBIA.EDU (128.59.32.138) Destination hardware address: 00-00-00-00-00-00 Destination protocol address: CU20B.COLUMBIA.EDU (128.59.32.128) Buffer dump: 1/ 4000,,0 08-00-00-00 8.0.0.0 5/ 22423,,0 25-13-00-00 37.19.0.0 ;Hardware type,,protocol??? 9/ 3004,,1 06-04-00-01 6.4.0.1 13/ 4000,,25402 08-00-2B-02 8.0.43.2 17/ 32173,,100073 34-7B-80-3B 52.123.128.59 21/ 20212,,0 20-8A-00-00 32.138.0.0 25/ 0,,0 00-00-00-00 0.0.0.0 29/ 100073,,20200 80-3B-20-80 128.59.32.128 33/ 30031,,314 30-19-00-CC 48.25.0.204 37/ 50020,,3776 50-10-07-FE 80.16.7.254 41/ 102546,,0 85-66-00-00 133.102.0.0 45/ 177775,,447 FF-FD-01-27 255.253.1.39 49/ 100073,,0 80-3B-00-00 128.59.0.0 53/ 1001,,65740 02-01-6B-E0 2.1.107.224 57/ 0,,0 00-00-00-00 0.0.0.0 61/ 0,,0 00-00-00-00 0.0.0.0 Send buffer with Request opcode, unknown hw type - 11301! Protocol type: 0! Source hardware address: 08-00-2B-02-30-6D Source protocol address: PRO-CCK.COLUMBIA.EDU (128.59.32.38) Destination hardware address: 00-00-00-00-00-00 Destination protocol address: CU20B.COLUMBIA.EDU (128.59.32.128) Buffer dump: 1/ 4000,,0 08-00-00-00 8.0.0.0 5/ 26045,,0 2C-25-00-00 44.37.0.0 ;hardware,,protocol 9/ 3004,,1 06-04-00-01 6.4.0.1 13/ 4000,,25402 08-00-2B-02 8.0.43.2 17/ 30155,,100073 30-6D-80-3B 48.109.128.59 21/ 20046,,0 20-26-00-00 32.38.0.0 25/ 0,,0 00-00-00-00 0.0.0.0 29/ 100073,,20200 80-3B-20-80 128.59.32.128 33/ 177777,,0 FF-FF-00-00 255.255.0.0 37/ 177777,,0 FF-FF-00-00 255.255.0.0 41/ 177777,,0 FF-FF-00-00 255.255.0.0 45/ 177777,,0 FF-FF-00-00 255.255.0.0 49/ 177777,,0 FF-FF-00-00 255.255.0.0 53/ 177777,,0 FF-FF-00-00 255.255.0.0 57/ 0,,0 00-00-00-00 0.0.0.0 61/ 0,,0 00-00-00-00 0.0.0.0 ------- 9-Feb-86 15:06:43-PST,1474;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 9 Feb 86 15:06:34-PST Date: Sun 9 Feb 86 15:11:22-PST From: Stu Grossman Subject: Re: DEQNAs and NI-20s - an update To: US.CCK@CU20B.COLUMBIA.EDU cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charlie C Kim " of Sat 8 Feb 86 15:56:13-PST A receive buffer size of ^D50 bytes will allow ARP to receive a datagram with a maximum of ^D46 bytes of 'user' data. The extra four bytes are required for receive buffers because the NI-20 microcode wants to put the datagram's CRC at the end of the data. At the time NISRV was written, it was not possible to hide this from the higher layers (NISRV's callers), that is why people have to make accomodations for the CRC (in receive buffers only). If an ARP datagram arrives that is too large to fit into the buffer, NISRV will return the buffer with an error indication. ARP looks at this, and rejects datagrams that are received in error. This occurs before any other processing is done. Is it possible that the DEQNA is transmitting a 'padded' datagram with a length field at the beginning of the datagram? Your best bet would be to capture the buffer as soon as possible inside of ARP (at ARPCDR I think). Also be sure to note the length of the datagram (as returned in field UNBSZ of the UN block). Good luck, Stu ------- 12-Feb-86 13:09:56-PST,550;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Wed 12 Feb 86 13:09:31-PST Date: Wed 12 Feb 86 15:09:40-CST From: CC.KASSEBAUM@R20.UTEXAS.EDU Subject: Patches to run 6.1 EXEC on 5.x Monitor To: tops20@SU-SCORE.ARPA Message-ID: <12182849248.41.CC.KASSEBAUM@R20.UTEXAS.EDU> Requesting patches for a 5.4 monitor to run 6.1 EXEC. This will make testing our local changes to the EXEC much easier. I recall someone from DEC saying there was a patch to do this. Regards, Don K ------- 12-Feb-86 16:43:50-PST,712;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Feb 86 16:43:40-PST Date: Wed 12 Feb 86 16:43:32-PST From: Bruce Tanner Subject: QUEUE% JSYS To: TOPS20@SU-SCORE.ARPA Message-ID: <12182888182.26.CERRITOS@USC-ECL.ARPA> Has anybody used the QUEUE% jsys? I wrote a little program to print a file and I got no errors and no output request. The only thing I can get it to do is give a "QUEUX3: Fatal error returned from application" if I ask for a response to a response block. There must be something I'm doing wrong, but I don't know what. Does anybody have a sample program that sends a print request? -Bruce ------- 12-Feb-86 17:55:56-PST,672;000000000000 Received: from LOTS-B by Score with Pup; Wed 12 Feb 86 17:55:40-PST Date: Wed 12 Feb 86 17:51:50-PST From: Paul Hegarty Subject: Re: QUEUE% JSYS To: CERRITOS@USC-ECL.ARPA cc: TOPS-20%Score@LOTS-B In-Reply-To: <12182888182.26.CERRITOS@USC-ECL.ARPA> Message-ID: <12182900616.203.H.HEGARTY@LOTS-B> The QUEUE% JSYS does work (though its error messages are, to say the least, unhelpful). I suspect that the reason it doesn't work for you is that you are not specifying the FULL filename (all fields). If you are interested in a sample program (which just prints a file), just ask and ye shall receive ... ... Paul ------- 12-Feb-86 18:12:15-PST,1009;000000000001 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Wed 12 Feb 86 18:12:01-PST Date: 12 Feb 1986 2108-EST From: Bill Melohn To: CC.KASSEBAUM@R20.UTEXAS.EDU, tops20@SU-SCORE.ARPA Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224" Subject: Re: Patches to run 6.1 EXEC on 5.x Monitor Message-ID: <"MS11(5116)+GLXLIB5(0)" 12182903551.11.108.6572 at MARLBORO.DEC.COM> References: Message from CC.KASSEBAUM@R20.UTEXAS.EDU of 12-Feb-86 1619-EST In-reply-to: <12182849248.41.CC.KASSEBAUM@R20.UTEXAS.EDU> I believe you will find that the 6.1 EXEC will run successfully under 5.1 or 5.4. To run the 5.1 EXEC under 6.1, you need to patch the OWGBP at SYSLOS+27 (referenced at EXEC02+31) from 620200,, to 160200,,. Otherwise due to the newer KL microcode you will get a section greater than 37 reference and the error TOPS-20 Command processor not properly initialized. Bill -------- 13-Feb-86 03:16:18-PST,1202;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 03:16:11-PST Date: Thu 13 Feb 86 00:08:50-PST From: Mark Crispin Subject: LPTSPL and PLPT0: To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12182969246.8.MRC@PANDA> LPTSPL doesn't assign its printer on a START command; it waits until there is something to print. This leaves PLPT0:, etc. available for any random process that wants to assign it. Is there some magic command that I'm unaware of that would cause LPTSPL to assign the printer right away? I'd also like to get BATCON to assign the PTY's for each of its streams too. It isn't crucial for my system, but for other systems I would imagine it would be a security bug. This is also a rather old class of bug; I remember when I was an undergraduate we used to screw the TOPS-10 LPTSPL by doing "SYSTAT L" repeatedly to keep it from getting the printer. DEC, are you listening? Is anybody still working on Galaxy who would consider a "grab all resources you'd ever need now" command? ------- 13-Feb-86 03:46:03-PST,938;000000000001 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 03:45:56-PST Date: Thu 13 Feb 86 00:19:42-PST From: Mark Crispin Subject: DZ11 question for 2020's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12182971223.8.MRC@PANDA> Folks, my 2020 has 4 DZ11's for a total of 32 DZ11 ports. I'm using a grand total of 5 lines now, of which only two are DZ11 ports (the other three are the KLINIK, CTY, and DECnet lines). Right now I have TTY2 and TTY21 wired up. TTY2 is a 4800 hardwire connected to a VT100 (that's why it's 4800 instead of 9600!) while TTY21 is a 1200 baud dialup. I'm going to add a 9600 Heath-19 soon. My question is: am I really winning by using separate DZ11's, or would I be better off having all my lines on a single DZ? ------- 13-Feb-86 03:46:19-PST,1764;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 03:46:04-PST Date: Thu 13 Feb 86 00:37:12-PST From: Mark Crispin Subject: TOPS-20 4.1 bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12182974408.8.MRC@PANDA> If anybody on this list if running TOPS-20 4.1 (e.g. has a 2020) you may want this fix. I SPR'd it to DEC several months ago, but apparently if you don't have a software contract with DEC your SPR's get circular filed. Obviously no software person even saw the SPR, since the bug is serious and obvious (and the fix was included) and it still exists in Autopatch 12. Problem: HNGU0F and HNGU1F functionality doesn't work in 4.1 Diagnosis: Person who added it doesn't remember how release 4 worked. There was no RSI; all data that was loaded non-zero was in RSCOD. Solution: In STG.MAC, replace: RS HNGU0F,HNGU0 RS HNGU1F,HNGU1 with: HNGU0F::HNGU0 HNGU1F::HNGU1 in a RESCD area. RESCD is write-allowed in release 4.1, unlike release 5 and later. Comment: I mentioned this to a few DEC people, who seemed fairly perturbed that SWS would fail to pass on an SPR just because it wasn't submitted by a paying customer. I took the trouble to fill in and mail the SPR only because I thought DEC would like the bugfix. I don't expect an answer, much less help in debugging a problem, but if I go to the trouble of SPR'ing a bug and including the fix, I wish somebody would take the time to look at it. In general, the TOPS-20 list has been more effective in passing on bug reports to DEC than SPR'ing. ------- 13-Feb-86 14:03:43-PST,368;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 14:03:21-PST Date: Thu 13 Feb 86 15:47:14-CST From: Clive Dawson Subject: DISCARD server To: tops-20@SU-SCORE.ARPA Do any sites out there have ECHO and/or DISCARD TCP servers running on their TOPS-20 systems? Thanks, Clive ------- 14-Feb-86 20:36:37-PST,2564;000000000000 Return-Path: Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Feb 86 20:36:19-PST Received: from bgsu by csnet-relay.csnet id ac04021; 14 Feb 86 23:21 EST Received: by bgsuvax.UUCP (4.12/4.7) id AA25374; Fri, 14 Feb 86 16:45:59 est Date: Fri, 14 Feb 86 16:45:59 est From: Steve Herber To: "tops20%su-score.arpa" <@CSNET-RELAY.ARPA,@bgsu.CSNET:tops20%su-score.arpa@csnet-relay.arpa> Subject: Applying local patches with AUTOPATCH Cc: herber%bgsu.csnet@CSNET-RELAY.ARPA Does anyone have any experience (or success even) merging local edits into AUTOPATCH'ed products using the COMPAR, MERGE and UPDATE utilities in the directory? We have tried using COMPAR to produce a file of local edits in 'AUTOPATCH' format from an original DEC source file and a locally modified file. We then use the MERGE utility to merge the local edits into the .Cnn file (nn is the Autopatch tape #) for that particular product. When we then SUBMIT the .CTL file that PEP uses to AUTOPATCH the product, we usually (depending on the phases of the MOON, time of day, you get the idea...) get CHECKSUM errors when UPDATE runs to apply one of the .Cnn AUTOPATCH file's patches to the product. For example: (from the GALAXY-20-V4-2, AUTOPATCH tape 10 log) @R ASL:UPDATE **@PAT:GALV42.SUP .... PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C06 <- this is the file that we .... used the MERGE utility to .... combine our local edits to .... MOUNTR.MAC. PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C07 <- Worked OK here also .... PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C08 <- Worked OK .... PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C09 <- Worked OK .... PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C10 <- Here the UPDATE program ?UPDSUM Checksum error displays a checksum error .... We have gone through a number of iterations with TOPS-20 telephone support on this and they cannot tell us a valid way to merge local patches into AUTOPATCHable products. There is of course, the good old "edit-the-file- after-you-autopatch" method of applying local patches (UGH!!). I want to automate this process as much as possible and what I keep hearing from DEC is "If you don't have any local patches, you wouldn't have this problem". Thanks for the consideration..... Steve Herber CSNET herber@bgsu.CSNET Sr. Systems Programmer UUCP ...!osu-eddie!bgsuvax!herber Bowling Green State Univ. 15-Feb-86 13:19:26-PST,1036;000000000000 Mail-From: G.FUSSELL created at 15-Feb-86 13:19:15 Date: Sat 15 Feb 86 13:19:15-PST From: Carl Fussell Subject: autobaud To: tops20@SU-SCORE.ARPA Address: Santa Clara University Message-ID: <12183637423.20.G.FUSSELL@SU-SCORE.ARPA> I was hoping someone on this list might have some experience with what we are trying to do and can perhaps give us some advice. We have just recently set up a facility that will permit our users to dial in on remote lines at speeds up to 9600 baud. As a result, we would like to set those lines to REMOTE AUTO. Has anyone else been successful at this? We are running a 6.0 monitor although withing a week or two, we will be on 6.1 with new front end code. We just learned that autobauding 300/1200 is broke (it used to work before we ran 6.0 monitor) so that probably explains 9600 not working. I am just wondering that if we get the 300/1200 back, will autobauding up to 9600 be possible. Thanx much for any information... Carl ------- 16-Feb-86 11:38:13-PST,3313;000000000001 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Sun 16 Feb 86 11:37:45-PST Date: 16 Feb 86 14:41:33 EST From: Charles Hedrick Subject: TCP zero window bug? To: tops-20@SU-SCORE.ARPA Message-ID: <12183881783.22.HEDRICK@RED.RUTGERS.EDU> symptom: can't get mail through to our Pyramid 90X (Unix 4.2) system. FTP's to it hang. We have noticed problems in receiving mail from at least one TOPS-20 site outside Rutgers. diagnosis: Unlike TOPS-20, Unix sends acks as soon as it gets TCP packets. Since it hasn't yet delivered the data to the user, these packets are still taking up buffer space. Thus the window size in the ack is small. Indeed in many cases it is zero. Once the system delivers the data to the user, the buffer space is freed and the window size increases. At that point Unix sends another packet announcing the new window. If the packet containing this window update should be dropped, the sender is left thinking it has a zero window. According to the protocol, the sender should probe this zero window now and then by trying to send one byte. There is code in TOPS-20 to do this, but apparently it is not used all the time when it should be. The code is triggered when the packetizer is asked to send a packet and notices that the send window is zero. Unfortunatley, there is code at prcac4-2 which overoptimizes. It fails to call the packetizer if the window is zero, presumably on the theory that if there is a zero window, nothing can be sent. Unfortunately, this means that the probing is never started. This problem does not show up between 2 TOPS-20 systems, since TOPS-20 does not ack a packet until it has passed the data to the application. At that point, the buffer space has been freed, and there is a new window. So the ack and the window update are in the same packet. If an ack is dropped, the other end will retransmit until it sees the ack. Thus there is no way a TOPS-20 window update can be lost. cure: the following diff is believed to correct this problem. At least we haven't seen the problem since installing it. There are other problems with the code that probes zero windows. They are being worked on at Score. But those problems are efficiency issues, whereas this one causes connections to hang. Actually the use of 250 msec. in the call to encpkt is purely arbitrary. It would probably be better to use some function of the current round-trip time. File 1) TCPTCP.MAC.8,11-Feb-86 20:01:42 File 2) TCPTCP.MAC.9,11-Feb-86 20:38:58 ************ following change is above PRCAC4 1)32 IMULI T3,3 ; 3 * Offered window **** 2)32 JUMPE T3,PRCA4A ;[221] if window set to zero, special handling 2) IMULI T3,3 ; 3 * Offered window ************** 1)32 PRCAC4: 1) ;See if packets which might have been made untransmittable due to **** 2)32 JRST PRCAC4 ;[221] 2) PRCA4A: MOVEI T1,^D250 ;[221] here when now have zero window. 2) CALL ENCPKT ;[221] send packet eventually to start 2) ;[221] probe of zero window, in case 2) ;[221] we drop the window update 2) PRCAC4: 2) ;See if packets which might have been made untransmittable due to ************** ------- 17-Feb-86 09:35:49-PST,1570;000000000000 Return-Path: Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Mon 17 Feb 86 09:35:29-PST Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.01/4.7.34) id AA11231; Mon, 17 Feb 86 09:39:47 pst Message-Id: <8602171739.AA11231@decwrl.DEC.COM> Date: Monday, 17 Feb 1986 09:39:57-PST From: ridder%warlok.DEC@decwrl.DEC.COM (Hans) To: tops-20@su-score Subject: Re: DZ11 question for 2020's Date: 17 Feb 1986 1039-MST From: Hans To: "tops-20@su-score" at DECWRL Subject: Re: DZ11 question for 2020's Message-ID: <"MS10(2137)+GLXLIB5(0)" 12184121795.24.143.60983 at WARLOK.TCP> Mark, each DZ has a FIFO (they call it a SILO) for all received characters in an eight line group. An interrupt is generated whenever the FIFO /is/ non-empty (as opposed to whenever it /goes/ non-empty.) The interrupt handler (DZRDIN in TTDZDV) completely empties the FIFO before exiting. My feeling is that if you group your lines on one DZ then you have a better chance of finding more then one character in the FIFO and thus saving an interrupt! Since DZs cause alot of them, I would think anything you can do to help would make your 2020 a little happier. But then the percentage change might be so small as to be un-noticable. As for transmit interrupts, they happen on a priority basis, with line 7 having a higher priority than line 0. In theory, line 7 would be serviced better (giving better output rate) than line 0. I wonder if that really happens? -------- 18-Feb-86 09:13:32-PST,436;000000000000 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 18 Feb 86 09:13:15-PST Date: 18 Feb 86 12:18:42 EST From: Don Subject: [NET]STAT source To: Tops-20@SU-SCORE.ARPA Message-ID: <12184380065.33.WATROUS@RED.RUTGERS.EDU> Does anybody have a recent source to NETSTAT or any of its successors (called perhaps TCPSTAT or TSTATS)? Thanks, Don ------- 19-Feb-86 02:09:29-PST,586;000000000000 Mail-From: BILLW created at 19-Feb-86 02:09:23 Date: Wed 19 Feb 86 02:09:23-PST From: William "Chops" Westfield Subject: BBN Interne code. To: su-tops-20@SU-SCORE.ARPA Message-ID: <12184564056.33.BILLW@SU-SCORE.ARPA> BBN has let us look at their current version of the tops20 TCP code. It's currently in <6-1-EXP-MON.BBN> on score, and includes a "TOPS20-Internetworking.DOC" that presumably explains how things are supposed to work. Ill be looking at this, of course, but I thought some other people might also be interested... BillW ------- 19-Feb-86 10:15:13-PST,1650;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 19 Feb 86 10:14:48-PST Date: Wed 19 Feb 86 13:19:26-EST From: Thomas De Bellis Subject: Possible CRDIR% directory page count bug To: Tops-20@SU-SCORE.ARPA Message-ID: <12184653267.49.SY.SLOGIN@CU20B.COLUMBIA.EDU> Here is something that I have a tough time explaining: A user created a subdirectory and then killed it causing his allocated directory pages to go negative. I think I can explain that part, the weird thing was that after he sent me a note about it, his directory went back to normal (ie, 0 pages instead of -1). Here is a log of it happening, anyone have any ideas? [Journal begin, HP2621: WS2:CREATE-KILL-BUG.JRN.1, Mon 17 Feb 86 9:07:17PM] A>i disk PSA: 0 Pages assigned +INF Working pages, +INF Permanent pages allowed 51650 Pages free on PSA:, 176350 pages used. A>^Ecreate /wor 10 /per 10 psa: [New] A>i disk PSA: 0 Pages assigned +INF Working pages, +INF Permanent pages allowed 51638 Pages free on PSA:, 176362 pages used. A>vd PSA: FOO1.DIRECTORY.1;P20200 0 0(0) 17-Feb-86 21:07:38 OP.ERIC A>^Ecreate /kill psa: [Old] [Confirm] A>i disk PSA: -1 Pages assigned +INF Working pages, +INF Permanent pages allowed 51636 Pages free on PSA:, 176364 pages used. A>jc [Journal end: WS2:CREATE-KILL-BUG.JRN.1, Mon 17 Feb 86 9:08:12PM] Shortly after this, the page count was back at 0!!! -- Tom De Bellis Columbia Computer Center ------- 19-Feb-86 19:59:59-PST,748;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 19 Feb 86 19:59:48-PST Date: Wed 19 Feb 86 23:04:49-EST From: Ken Rossman Subject: Re: Possible CRDIR% directory page count bug To: Sy.SLogin@CU20B.COLUMBIA.EDU, Tops-20@SU-SCORE.ARPA In-Reply-To: <12184653267.49.SY.SLOGIN@CU20B.COLUMBIA.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12184759833.30.SY.KEN@CU20B.COLUMBIA.EDU> By sending you a note about it, MM created a MAIL.CPY file, which had to go through normal TOPS-20 file system allocation, which in turn might have found the discrepancy and cleaned it up... well, that's my guess. ------- 20-Feb-86 15:59:53-PST,3215;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Feb 86 15:59:29-PST Date: Thu 20 Feb 86 18:04:33-CST From: Clive Dawson Subject: Recap of ARP bugs To: tops-20@SU-SCORE.ARPA A couple of messages earlier this month contained patches to IPNIDV.MAC which cured problems in TOPS-20's ARP table. Original symptoms of the bugs included running out of table space due to duplicate entries and failure to find ARP entries which resulted in unnecessary network ARP traffic. (The new SYSDPY has an ARP command which allows you to examine your ARP table and quickly determine whether you are suffering from this.) One more bug in the binary search routine has since been fixed. I'm still not convinced these routines are totally sound, however. There are several places where the ARP search routines return pointers to a given entry. There is no guarantee, however, that those pointers will still be valid when they are used, since the table may have been modified in the interim. In any case our current version has been running for almost two weeks with no apparent problems. The following .DIF file contains the new fix as well as the previous ones. Clive File 1) IPNIDV.MAC created: 1047 03-Mar-1985 File 2) IPNIDV.MAC created: 0724 08-Feb-1986 ***************************************** 1)1 ; UPD ID= 419, SNARK:IPNIDV.MAC.87, 3-Mar-85 11:47:12 by PAETZOLD *........................................ 2)1 ;IPNIDV.MAC.3, 5-Feb-86 17:26:30, Edit by AI.CLIVE 2) ;[MCC-34] Fix GHT search routines so that duplicate ARP entries don't happen 2) ; and also fix a race condition with ARPUPD. 2) ; UPD ID= 419, SNARK:IPNIDV.MAC.87, 3-Mar-85 11:47:12 by PAETZOLD ********ISRCH**************************** 1)39 ISRCH: MOVE P2,P3 ;BUILD MIDDLE BY TAKING THE HIGH *.......INTSRC+7......................... 2)39 IFN MCCSW,< ;[MCC-34] 2) SOS P3 ;HIGH is offset to last entry, not # of entries 2) >;IFN MCCSW ;[MCC-34] 2) ISRCH: MOVE P2,P3 ;BUILD MIDDLE BY TAKING THE HIGH ********ISRCH+11************************* 1)39 JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED *.......ISRCH+11......................... 2)39 IFN MCCSW,< ;[MCC-34] 2) AOS T1 ;Adjust T1 & P2 to point to correct the 2) AOS P2 ; insertion point in the case where 2) ; the last entry examined is .LT. host. 2) >;IFN MCCSW ;[MCC-34] 2) JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED ********ARPUPD+4************************* 1)55 MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE *.......ARPUPD+4......................... 2)55 IFN MCCSW,< ;[MCC-34] 2) MOVE T2,SPADR ;Get internet address 2) CALL INTSRC ;Search table again to ensure pointer is valid 2) SKIPA ;Not found, as expected 2) JRST [OKSKED 2) RET] ;Aha! Somebody else did it for us 2) MOVEM T1,AREA1 ;Save insertion pointers 2) MOVEM T2,AREA2 ;... 2) >;IFN MCCSW ;[MCC-34] 2) MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE ********[ END OF FILCOM AT RPC1+20 ]******** ------- 21-Feb-86 04:22:31-PST,3556;000000000000 Mail-From: BILLW created at 21-Feb-86 04:22:24 Date: Fri 21 Feb 86 04:22:24-PST From: William "Chops" Westfield Subject: Tops20 TVT performance improvments To: tops-20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <12185112557.8.BILLW@SU-SCORE.ARPA> BUG: Under certain situations, throughput on TOPS20 TVTs drops to approximately 0 for long periods of time. I believe that the problem got worse with v6.1, and may be the reason that the TVT SMTP server doesn't work well under 6.1. Reproduce by: I think this shows up best when trying to run a dialout type program while logged in on a TVT. However, the following program will exhibit the problem too: start: movei 6,^d32 loop: movei 1,"%" pbout movei 1,^d30 disms sojg 6,loop haltf Diagnosis: The tops20 TVT scanner attempts to send characters that are part of "echoing" immediately. It's criteria for recognizing "echoes" is that there be fewer than 8 characters in the terminal output buffer. Since the TCP process runs at a very high priority, it will probably get to look at the TTY output buffers if the user process blocks for any reason. In the case above, therefore, there is a good chance that 32 separate 1 byte packets are queued. And there are certainly lots of machines that don't like to receive 32 almost back-to-back short packets. This leads to many retransmissions and excessive use of CPU time on both systems, not to mention any gateways that might be in between them. Fix: Make TOPS20 TCP pickier about what it considers echoing. In addition to there being only a few characters in the buffer, have it insist that the retransmission queue for that connection be empty. (If a person types faster than the Round trip times, it won't hurt to have his echoing clumped together a little anyway.) This is much simpler than having the TCP repacketize retransmissions. By the way, it turns out that this is "reinventing the wheel", as almost identical suggestions were made by John Nagle in RFC896. It is surprising, however, that this makes such a difference even on local ethernets with no gateways involved. Admittedly, tops20's scheduling of TCP provides a pathological case! The relevant code is in TVTSRV, just before OPSCA7: [This is from 6.1 sources. There should be an easy equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ] SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT JRST OPSCA7 ; No. IFE STANSW,< MOVX T1,^D200 ; The function to queue for PZ if a lot MOVX T2, ; to send - wait a bit, maybe more CAIGE T4,^D8 ; Less that 8 is echoing so MOVX T2, ; Force it now CALL (T2) ; See Note above >;IFE STANSW IFN STANSW,< ;;; there is not going to be any more output if all of the ;;; output buffers are full, so send packets immediately. CALL TTSOBF ;output buffer full? CAIGE T4,^D8 ; or looks like echoing. SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now MOVX T2, ; otherwise wait for more data LOAD T1,QNEXT,<+TCBRXQ(TCB)> ;check if retranmission queue empty? CAIE T1,TCBRXQ(TCB) ;skip if RXQ empty CAIL T4,^D8 ; or if a large packet TRNA MOVX T2, ; otherwise wait for more data MOVEI T1,^D200 ; for a couple hundred millisecs. CALL (T2) ;call appropriate packet routine. >;IFN STANSW OPSCA7: MOVE T2,LINADR ; Restore address of terminal block OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT ------- 21-Feb-86 06:46:59-PST,2017;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 21 Feb 86 06:46:51-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 21 Feb 86 06:49:50-PST Date: Fri 21 Feb 86 06:12:11-PST From: Mark Crispin Subject: Re: Tops20 TVT performance improvments To: BILLW@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <12185112557.8.BILLW@SU-SCORE.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12185132542.9.MRC@PANDA> A release 5.4 equivalent of BillW's change is follows. It does make a difference. SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT JRST OPSCA7 ; No. IFE PANDASW,< ;[5] MOVX T1,^D200 ; The function to queue for PZ if a lot XMOVEI T2,ENCPKT ; to send - wait a bit, maybe more CAIGE T4,^D8 ; Less that 8 is echoing so XMOVEI T2,FRCPKT ; Queue for PZ promptly CALL (T2) ; See Note above >;IFE PANDASW IFN PANDASW,< ;[5] ;;; FRCPKT is called if: ;;; . There are less than 8 bytes (probably echoing) in the packet and the ;;; retransmission queue is empty ;;; OR ;;; . The terminal output buffer is full ;;; Otherwise ENCPKT is called instead CALL TTSOBF ; Is output buffer full? IFSKP. CALL FRCPKT ; Yes, might as well send it now ELSE. CAIL T4,^D8 ; Looks like echoing? IFSKP. LOAD T1,QNEXT,<+TCBRXQ(TCB)> ; Yes, get RXQ CAIE T1,TCBRXQ(TCB) ; Is the retransmission queue empty? ANSKP. CALL FRCPKT ; Yes, queue for PZ promptly ELSE. MOVX T1,^D200 ; Output not full and not echoing, wait a bit CALL ENCPKT ; for more to output ENDIF. ENDIF. >;IFN PANDASW OPSCA7: MOVE T2,LINADR ; Restore address of terminal block OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT I don't believe this problem was the cause of the TVT SMTP server problem, nor will this fix repair it. The TVT SMTP server doesn't echo. ------- 22-Feb-86 02:29:23-PST,1159;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 22 Feb 86 02:29:15-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 22 Feb 86 02:34:33-PST Date: Sat 22 Feb 86 01:55:10-PST From: Mark Crispin Subject: PDP-11/20 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12185347898.8.MRC@PANDA> Through an amusing set of circumstances I have found myself the proud(?) owner of a PDP-11/20, serial number 1779. According to the bus list on the back, it has a KA11, a KP11(?), a KL11A, two MM11F's, and a DR11B. I believe an MM11F is an 8K memory. There was a Unibus cable coming out of the Unibus backplane between the KP11 (or is it KD11?) and the KL11A; there are boards there but nothing listed, there was also a zillion wire cable coming from the DR11B. Can anybody tell me what use, if any, this boat anchor sitting on my living room floor is? Apparently it is dysfunctional; in any case none of the console lights light even when you try to LOAD ADDRESS... ------- 22-Feb-86 09:13:19-PST,509;000000000000 Return-Path: Received: from CS.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sat 22 Feb 86 09:13:10-PST Date: Sat 22 Feb 86 12:16:57-EST From: Bill Schilit Subject: Re: PDP-11/20 To: MRC%PANDA@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Sat 22 Feb 86 07:19:51-EST in any case none of the console lights light even when you try LOAD ADDRESS... Try plugging it in. - Bill ------- 23-Feb-86 06:38:22-PST,820;000000000001 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Sun 23 Feb 86 06:38:12-PST Date: 23 Feb 86 09:21:34 EST From: Charles Hedrick Subject: previous patch for probing zero windows To: tops-20@SU-SCORE.ARPA Message-ID: <12185658540.26.HEDRICK@RED.RUTGERS.EDU> A week or soago, I proposed a patch around prcac4 to handle problems probing zero windows. It has since become clear that there are more serious problems than this with zero windows. This patch certainly doesn't solve all ofthe problems. It doesn't seem to cause any terrible problems, but I suspect that a complete solution will not involve that patch. So I recommend that you remove it if you put it in, but there is no great emergency involved in doing so. ------- 23-Feb-86 17:39:48-PST,1962;000000000001 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 23 Feb 86 17:39:40-PST Date: Sun 23 Feb 86 17:44:57-PST From: Kirk Lougheed Subject: 6.1 Filesystem Rebuild Screw To: tops-20@SU-SCORE.ARPA Problem: DLUSER fails to properly restore directories when rebuilding the public structure created by the monitor's filesystem initialization routines. Analysis: The DLUSER data was taken from a filesystem that had Release 6.1 password encryption. Since the monitor does not ask about enabling password encryption when creating a structure, the new public structure did not have the encryption bit set in the home blocks. CRDIR% carefully disallows setting an encrypted password for a directory on a non-encrypted structure, returning a CRDI27 error code. Solution(s): One solution would be to have the monitor ask about password encryption when the monitor is started from PC 143. This would be preferable. Note that CHECKD should also ask that question when initializing a filesystem. The solution I took was to remove the check in CRDIR%. My feeling is that if I took the trouble to specify a password encryption version, I should be allowed to set such an encrypted password, regardless of whether I was able to, or remembered to, set up an encrypted structure. The relevant code fragment from JSYSF.MAC follows: UMOVE T1,.CDPEV(Q2) ;Get user-supplied encryption version IFE STANSW,< ;; Don't check for password encryption on structure. This can severely ;; hamper efforts to restore a filesystem using DLUSER information. JUMPE T1,CRDP1A ;Bypass structure check if zero (unencrypted) MOVE T3,CRDSFL ;Get status flags for the structure TXNN T3,MS%CRY ;Is password encryption on for this structure? RETBAD(CRDI27,) >;IFE STANSW CRDP1A: CALL CHKPEV ;Test validity of encryption version number ------- 23-Feb-86 20:59:17-PST,874;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 23 Feb 86 20:59:07-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 23 Feb 86 21:04:35-PST Date: Sun 23 Feb 86 19:48:31-PST From: Mark Crispin Subject: Bug in DECnet-20 SRV: device To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12185805440.8.MRC@PANDA> Validity: All DECnet-20 monitors (6.0 or earlier). DECnet-36 monitors and non-DECnet monitors don't have this bug. Problem: Can't get a TASK SRV: JFN, e.g. SRV:TASK-FOOBAR Diagnosis: Fencepost error in test for object type number being out of range. Solution: At SRCNAM+13 (FILNSP in 4.x monitors, else NSPSRV), change SKIPG T1 to SKIPGE T1 ------- 24-Feb-86 02:42:00-PST,1978;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Feb 86 02:41:51-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 24 Feb 86 02:45:55-PST Date: Mon 24 Feb 86 02:17:38-PST From: Mark Crispin Subject: SMTP over DECnet To: TOPS-20@SU-SCORE.ARPA cc: ridder%warlok.DEC@DECWRL.DEC.COM Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12185876278.8.MRC@PANDA> Folks - It has been pointed out to me that DEC is going to be using SMTP over DECnet for mail in at least some applications, and that the assigned object type is named object type "MX-LISTENER". The development MM sources on PANDA have already been changed to use this instead of the old 125 (which was an interim object type anyway) and the distribution sources on SIMTEL20 will be updated soon once a flurry of activity with MMailr winds down. If you are using MM/SMTP over DECnet you may want to change over to this new object type. In SMTDCN.MAC, the file name is SRV:TASK.MX-LISTENER, in MMAILR.MAC, the name is DCN:node-TASK-MX-LISTENER. This replaces SRV:125 and DCN:node-125. If you are running a NSPSRV DECnet monitor (pre-6.1), you will need to patch monitor location SRCNAM+13 from SKIPG T1 to SKIPGE T1 to run the new SMTDCN. If anybody at DEC involved with this is listening, please get in touch with me. My implementation of DECnet/SMTP is in fairly extensive use in the field and there are various TOPS-10 and VAX systems that talk to TOPS-20 systems using it. That's a strong argument to try to get some degree of compatibility going; hopefully in these dying days of 36-bits we aren't going to see much wheel-reinvention and Not-Invented-Here syndrome... Some people at DEC already have my DECnet/SMTP software, but if you don't please let me know and I'll make sure you get it post haste. ------- 24-Feb-86 16:39:28-PST,1272;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Feb 86 16:39:14-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 24 Feb 86 16:44:45-PST Date: Mon 24 Feb 86 16:42:47-PST From: Mark Crispin Subject: 36 bits at DECUS: the decline continues To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12186033772.9.MRC@PANDA> I just got my preliminary program for DECUS in Dallas (4/28-5/2). Large Systems sessions are now only three days. Tuesday morning are the marketing sessions, Tuesday afternoon are the highend VAX sessions, Wednesday morning is TOPS-20, Wednesday afternoon is TOPS-10, and most of Thursday are the migration to VMS sessions except at the very end there are two hours for a Town Meeting and the Menu. It's sad and depressing. On the other hand, given the sparse attendance at the last DECUS it's somewhat amazing that there's even that much in the way of 36-bit sessions. On an up note, there will be two Large Systems pre-symposia sessions. The first one is by Bob McQueen about Ethernet/802.3 planning, the second is by Len Bosack about TCP/IP. ------- 24-Feb-86 21:07:36-PST,9305;000000000001 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Mon 24 Feb 86 21:06:47-PST Date: 25 Feb 86 00:11:37 EST From: Charles Hedrick Subject: TCP zero window probe patch (2nd try) To: tops-20@SU-SCORE.ARPA Message-ID: <12186082712.19.HEDRICK@RED.RUTGERS.EDU> This patch makes TOPS-20 probe zero send windows in TCP. When talking to a Unix system, if the wrong packet gets dropped (e.g. due to a congested gateway, or other packet losage) it is possible for a TCP send to hang. The scenario is this: TOPS-20 is sending data. It sends enough to have fully used up the window allocation given by the other end. The other end ACK's these packets, including a zero window in the ACK. (This would not happen with another 20, but would be the normal case if the other system is 4.2.) At this point, the 20 will do nothing until it gets another packet with a non-zero window allocation. If that packet should be dropped, we have a classic deadlock. Each end is waiting for the other to do something. In order to prevent this problem, the TCP spec says that a system looking into a zero window should "probe" now and then. The simplest kind of probe is a one-byte packet. As long as the window stays closed, this packet will be ignored, or ACKed with another ACK containing a zero window. When the other end is ready to get data again, an ACK with nonzero window will be sent. There are other kinds of probe possible, including a packet with an intentionally illegal sequence number. (This has some advantages that I don't want to talk about here.) But something of this kind is essential to avoid hangs in dealing with Unix. TOPS-20 uses a different ACK strategy, so this sort of hang will not show up when talking between two TOPS-20 systems. Anyway, TOPS-20 does not probe zero windows. It has some of the code needed to do so, but it is not called at all the right times. The following patch makes the code work in all of the cases that I can test. It is not an aesthetically very pleasing implementation. It uses normal data packets as probes, rather than the special illegal packet that I would regard as better. After the bad experience with my previous patch, this time I instrumented a Unix system so that I could watch packets go by, and tried it under various loading conditions. It seems to do something reasonable. Anything better would require a separate mechanism for probes, rather than using the normal packetizing and retranmission code. There are patterns of traffic which would cause this code to use a full data packet as a probe. I suspect this would never happen in practice, and even if it did, I believe such a probe would still work. (This is the one part of the code that I have not been able to test, as I can't contrive any circumstance that will exercise it.) The following patch also includes an unrelated fix from BillW at Score. Because these two patches are intertwined, it was impossible to give you mine without his. In addition to the changes below, I suggest that you might want to change TCPRXW (in STG.MAC) from 120000 to 30000 (2 min. to 30 sec). This controls how often probes are sent. The correct value depends upon the speed of your network and how often packets are dropped. If packet losssage is at all common, 2 min. seems a bit long to wait to restart the connection. It would be a bad idea to set it much shorter than 30 sec. Ideally, this time should by adjusted dynamically, but I leave that for a later project. This code has been tested only in 5.4. I have glanced only briefly at the corresponding 6.1 code. REDIT 1(103) COMPARE by user HEDRICK, 24-Feb-86 23:41:13 File 1: RED:TCPTCP.MAC.1 File 2: RED:TCPTCP.MAC.3 ***** CHANGE #1; PAGE 32, LINE 10; PAGE 32, LINE 10 LOAD T2,TSSEQ,(TCB) ; Get current Send Sequence SUB T2,T1 ; Bytes used in send window MODSEQ T2 ; (Must be .ge. 0) LSH T2,2 ; 4 * Used LOAD T3,TSWND,(TCB) ; Get new Send Window IMULI T3,3 ; 3 * Offered window CAMGE T2,T3 ; If Used/Offered .lt. 3/4 CALL FRCPKT ; Run PZ, but after RA PRCAC4:  --------------------------------- LOAD T2,TSSEQ,(TCB) ; Get current Send Sequence SUB T2,T1 ; Bytes used in send window MODSEQ T2 ; (Must be .ge. 0) LSH T2,2 ; 4 * Used LOAD T3,TSWND,(TCB) ; Get new Send Window JUMPE T3,PRCA4A ;[221] if window set to zero, special handling IMULI T3,3 ; 3 * Offered window CAMGE T2,T3 ; If Used/Offered .lt. 3/4 CALL FRCPKT ; Run PZ, but after RA JRST PRCAC4 ;[221] PRCA4A: ;[223] here when now have zero window, with window used in T2 ;[223] MOVEI T1,^D250 ;[221] here when now have zero window. MOVE T1,TCPRXW ;[223] probe interval, in msec SKIPN T2 ;[223] only probe if nothing else outstanding CALL ENCPKT ;[221] send packet eventually to start ;[221] probe of zero window, in case ;[221] we drop the window update PRCAC4:  ***** CHANGE #2; PAGE 66, LINE 7; PAGE 66, LINE 7 ; Compute the amount of window space available to send into as ; provided by the remote end. LOAD T1,TSLFT,(TCB) ; Send Left LOAD T3,TSWND,(TCB) ; Send Window offered SKIPN T3 ; Allow sending if window is shut MOVX T3,1 ; Need probe to sense remote window openning LOAD T2,TSSEQ,(TCB) ; Send Sequence SKIPE PKT ; or LOAD T2,PESEQ,(PKT) ; Packet end sequence if partial packet ADD T1,T3 ; Compute Send Right  --------------------------------- ; Compute the amount of window space available to send into as ; provided by the remote end. LOAD T1,TSLFT,(TCB) ; Send Left LOAD T3,TSWND,(TCB) ; Send Window offered ;[223] SKIPN T3 ; Allow sending if window is shut ;[223] MOVX T3,1 ; Need probe to sense remote window openning ;[223] We treat a zero window specially because the code below is going ;[223] to turn a 1 back into a 0 if we just do MOVX T3,1 at this point. ;[223] If there is already a partially filled packet, then at one point ;[223] there must have been enough data for it. We use that packet as ;[223] a probe instead of the usual 1-byte probe. IFE. T3 ;[223] if window is shut LOAD T2,TSSEQ,(TCB) ;[223] and if nothing already outstanding SUB T2,T1 ;[223] MODSEQ T2 ;[223] currently used window JUMPN T2,PKTIZ5 ;[223] something already out, just say 0 window MOVX WNDSPC,1 ;[223] assume one-char probe ;[223] the following code is here because of the Stanford part of edit 221. ;[223] should it ever be removed, then this might not be right. JUMPE PKT,PKTIZ6 ;[223] no partial packet, so that's right LOAD T2,PESEQ,(PKT) ;[223] packet end sequence number SUB T2,T1 ;[223] Difference is number bytes in pkt MODSEQ T2 ;[223] Possible wrap JUMPE T2,PKTIZ6 ;[223] nothing really there, use 1 byte probe MOVE WNDSPC,T2 ;[223] Use existing packet as probe JRST PKTIZ6 ;[223] ENDIF. ;[223] LOAD T2,TSSEQ,(TCB) ; Send Sequence ;[221] SKIPE PKT ; or ;[221] LOAD T2,PESEQ,(PKT) ; Packet end sequence if partial packet ADD T1,T3 ; Compute Send Right  ***** CHANGE #3; PAGE 66, LINE 42; PAGE 66, LINE 63 ; known and the apparent amount of useable window space is known. ; Set XFRCNT to the (maximum) amount which can actually be sent in this ; Pkt. In the case of a TVT, it is not known how much is available ; and we will assume a full packet (or window, etc) is to be sent. CAML BUFCNT,WNDSPC ; Take min of what is available to be  --------------------------------- ; known and the apparent amount of useable window space is known. ; Set XFRCNT to the (maximum) amount which can actually be sent in this ; Pkt. In the case of a TVT, it is not known how much is available ; and we will assume a full packet (or window, etc) is to be sent. COMMENT | ;[221] Problem: Large data transfers to some hosts don't work. Diagnosis: At some point in the transfer, the packetizer (PZ) emptied the last (currently) available user buffer, which partially filled a packet. Say that the data in this packet consumes 80% of the advertised send window. In the absence of a push, the packet was held pending more user data. When the next user buffer is presented, the PZ tries to resume filling the current packet. Just before PKTIZ5 (in TCPTCP.MAC), the PZ calculates how much available window space it has. Since, after taking into account the data already in the current packet, only 20% of the window is usable, the silly-window avoidance code holds everything pending a window update or a push. Since neither of these happens, things hang until the somebody times out. Cure: The PZ should not include data in the current packet in its silly window calculations. It does need to account for this data immediately after that calculation, to prevent overflowing the send window. | IFN. PKT ;[221] Have partially filled pkt? LOAD T2,PESEQ,(PKT) ;[221] Yes, get end seq LOAD T1,TSSEQ,(TCB) ;[221] and send seq SUB T2,T1 ;[221] Difference is number bytes in pkt MODSEQ T2 ;[221] Possible wrap SUB WNDSPC,T2 ;[221] WNDSPC = #bytes can still put in pkt ENDIF. ;[221] CAML BUFCNT,WNDSPC ; Take min of what is available to be  ------- 27-Feb-86 17:31:12-PST,564;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 27 Feb 86 17:31:02-PST Date: Thu, 27 Feb 1986 18:30 MST Message-ID: From: "Frank J. Wancho" To: TOPS-20@SU-SCORE.ARPA Subject: RSCAN in EXEC? Has anyone modified EXEC so that it can behave like most other programs and accept a command line via RSCAN? The purpose is to provide certain EXEC features through a front-end MENU program without writing a mini-EXEC in the process. --Frank 1-Mar-86 16:36:01-PST,1294;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Sat 1 Mar 86 16:35:50-PST Received: ID ; Sat 1 Mar 86 19:35:43-EST Date: Sat 1 Mar 86 19:35:40-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: BAT block editing To: TOPS-20@SU-SCORE.ARPA Message-ID: <12187343196.6.VAF@C.CS.CMU.EDU> Here's the problem: I have a structure that had a bad drive on it for a short period of time on which CHECKD was run. The result is that the BAT blocks for the unit that was on the bad drive are now full. I'd like to delete some of the bogus BAT block entries rather than rebuild the whole structure, but the EDIT (BAT blocks) command in my version of CHECKD doesn't work (it allows one to "edit" the BAT blocks but doesn't update them on exit). Does anyone have a version of CHECKD (usable on a 5.4 system) on which the EDIT (BAT blocks) command works properly (or some other program which is capable of editing the BAT blocks to solve this problem)? Sources would be preferred, since we have the local mod to allow structures with more than 3 units and the structure in question has more than 3 units. My alternative is to patch the BAT blocks by hand in FILDDT, which would be a royal pain... Thanks in advance, --Vince ------- 1-Mar-86 17:18:21-PST,552;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Mar 86 17:18:12-PST Date: Sat 1 Mar 86 18:16:40-MST From: Randy Frank Subject: Re: BAT block editing To: Vince.Fuller@C.CS.CMU.EDU, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12187343196.6.VAF@C.CS.CMU.EDU> Message-ID: <12187350662.10.FRANK@UTAH-20.ARPA> there is a program BATUPD from the sws-kit years ago; I put a copy on [utah-20]:batupd.exe. No idea if it still works, but it probably does. Good luck. ------- 2-Mar-86 21:11:49-PST,999;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sun 2 Mar 86 21:11:43-PST Date: Mon, 3 Mar 1986 00:13 EST Message-ID: From: Rob Austein To: su-tops-20@SU-SCORE.ARPA cc: sra@XX.LCS.MIT.EDU Subject: Domain resolver code The new GTDOM% code has now been up for over a week straight on XX, and the resolver is still working ok. It looks pretty solid. Paul Mockapetris has been talking about combining this stuff with the work he has been doing on the nameserver lately to make up a formal release, but don't hold your breath. Anybody out there want to start womping up a 6.1 version (which Paul isn't going to do anyway)? MKL@NIC has been trying, without much luck (there's some hairy page mapping code in the initialization routine that causes him grief). Other than that and some PSECT twiddling, it should be a pretty easy job. Code is in XX:. --Rob 3-Mar-86 18:17:21-PST,900;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 18:17:01-PST Date: 3 Mar 1986 2119-EST From: Bill Melohn To: TOPS-20@score Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224" Subject: My Intgration/Migration Message-ID: <"MS11(5136)+GLXLIB5(0)" 12187886310.20.108.28302 at MARLBORO.DEC.COM> I am leaving the TOPS-20 group as of this Friday. Jim McCollum will be taking over all of my responsiblities for ARPAnet, LAT, and CTERM related matters. Jim can be reached at (617) 467-4635 (McCollum@TOPS20.DEC.COM). I have accepted a job working for Sun Microsystems' data communications group in Mountain View, California. It has been a pleasure meeting and working with many of you. I will most likely continue to work with those of you who have Suns in the future. Bill -------- 3-Mar-86 21:03:42-PST,605;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 21:03:31-PST Date: Mon 3 Mar 86 22:03:07-MST From: Randy Frank Subject: Re: My Intgration/Migration To: MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA In-Reply-To: <"MS11(5136)+GLXLIB5(0)" 12187886310.20.108.28302 at MARLBORO.DEC.COM> Message-ID: <12187916173.11.FRANK@UTAH-20.ARPA> Reminds me of a saying a while ago in Seattle during one of Boeing's many downturns: "Will the last one left using Tops-20 please remember to turn out the lights..." ------- 3-Mar-86 21:12:51-PST,624;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 21:12:38-PST Date: 4 Mar 1986 0014-EST From: John J Purretta To: Randy Frank , MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA Large Systems Marketing: 297-6062 Subject: Re: My Intgration/Migration Message-ID: <"MS11(5136)+GLXLIB5(0)" 12187918285.13.1021.8725 at MARLBORO.DEC.COM> References: Message from Randy Frank of 4-Mar-86 0013-EST In-reply-to: <12187916173.11.FRANK@UTAH-20.ARPA> Ok. /jp -------- 3-Mar-86 23:07:29-PST,1900;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 23:07:19-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 3 Mar 86 23:08:56-PST Date: Mon 3 Mar 86 22:48:55-PST From: Mark Crispin Subject: Re: My Intgration/Migration To: FRANK@UTAH-20.ARPA cc: MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12187916173.11.FRANK@UTAH-20.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12187935434.8.MRC@PANDA> Well, since I am planning to keep PANDA running (and to hack TOPS-20 on it) into the next century, I may well be the last TOPS-20 user. I'll remember to turn off the lights, unless, of course, I stop using TOPS-20 when MY lights get turned out! I sure hope DEC puts TOPS-20 in the public domain once 7.0 (the last DEC TOPS-20) is released. I'd sure like to be able to release 7.1. By the way, once I finish DECnet-36 on the 2020, I think I'm going to work on a command editor in the monitor. What's next? Maybe TP4 (certainly 2020 TCP/IP), maybe command DWIM,... Say, let's consider a lighter topic. Assuming all goes well -- that is, DEC lets go of TOPS-20 -- what should subsequent versions of our favorite operating system be called? After all, "TOPS-20" is a DEC trademark and it isn't reasonable or appropriate to continue using it in the post-DEC era. To forestall the suggestions for "Twenex", let me point out that machines other than DEC-20's run TOPS-20. "Viros" probably doesn't make sense (after all, VM/370 is a *real* "virtual operation system"); we could have "Snark" but what are we hunting? Per Hjerppe can explain why "Krans" (yet another pre-release name) isn't acceptable. I'm sure there'll be no lack of suggestions. -- Mark -- ------- 4-Mar-86 06:32:56-PST,900;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 06:32:46-PST Date: Tue 4 Mar 86 09:48:03-AST From: Reid Broome Subject: Disk Exerciser for TOPS-20 To: tops-20@SU-SCORE.ARPA Postal-Address: P.O. Box 1012, 9 Grove St., Dartmouth, NS B2Y 3Z7, Canada Phone: (902) 426-3100 x158 Message-ID: <12188011733.31.BROOME@DREA-XX.ARPA> During the latter part of this week, Field Service will be installing an RP07 on our DEC-2060. The current PS: (now on RP06's) will be moved to this new RP07 drive. I would like to be 100% sure that this RP07 drive is "virtually" error free before moving PS: to it. Does anyone have or know of a disk exerciser program written for TOPS-20? I would expect that such a program would write and read data to a disk with verification. Thanks in advance, Reid Broome ------- 4-Mar-86 11:08:56-PST,1056;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 11:08:37-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 4 Mar 86 11:08:40-PST Date: Tue 4 Mar 86 10:12:53-PST From: Mark Crispin Subject: FB%NDF loses disk pages To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12188059946.10.MRC@PANDA> Problem: The following sequence loses disk pages: $COPY TTY: A.A TESTING... ^Z $REV A.A : SET UNDELETABLE (sets FB%NDL) $COPY TTY: A.A.1 ?File is marked "Never Delete": A.A.1 $ The FDB is still there and its page and byte counts are still set, however, it no longer has an index block. Both the index block and the data page are lost, and will show up as lost the next time you run CHECKD. Diagnosis: Somebody is clearing the index block pointer prematurely in a superceding OPENF% Solution: None yet. ------- 4-Mar-86 11:11:48-PST,788;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 11:11:11-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 4 Mar 86 11:12:04-PST Date: Tue 4 Mar 86 10:48:05-PST From: Mark Crispin Subject: Fix to FB%NDL loses pages bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12188066354.10.MRC@PANDA> At DELFIL+30, add a STOR P3,FBADR,(D) in the literal when the file is FB%NDL: TXNE A,FB%NDL JRST [ STOR P3,FBADR,(D) ;PUT ADR BACK INTO FDB MOVEI A,DELX13 ;YES - RETURN AN ERROR JRST DELFIX] This puts the address of the index file back into the FDB prior to returning the error. ------- 4-Mar-86 13:49:35-PST,1433;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 13:49:07-PST Date: 4 Mar 1986 1648-EST From: Jim McCollum To: TOPS20@score Reply-to: McCollum@TOPS20.DEC.COM Subject: The new kid in town Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12188099250.130.29.193333 at TOPS20.DEC.COM> Hello, At Mark Crispin's urgings I am sending this out to introduce myself to all of you. My name is Jim McCollum and I'll be taking over Bill Melohn's TCP/IP responsibilities for TOPS-20. My mailing address is McCollum@TOPS20.DEC.COM. I may have met some of you at the fall DECUS in Anahiem. If you don't remember, don't worry, I probably don't remember you either. For those of you who are planning on attending spring DECUS in Dallas I will be there too and we'll have a chance to meet. I'm looking forward to that based on some of the things I've heard about members of this community. This is my first foray into the world of ARPAnet, but I'm confident I can meet the needs of the TOPS-20 community. For those of you you are wondering where things stand with TOPS-20 these days, about all I can say is that we are starting the planning stage for release 7.0 now. More details will be available at DECUS and I hope some of you are going to be there. See you in Dallas. Jim -------- 4-Mar-86 17:50:26-PST,550;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 17:50:16-PST Date: Tue 4 Mar 86 17:47:45-PST From: Stu Grossman Subject: Re: My Intgration/Migration To: MRC%PANDA@SUMEX-AIM.ARPA cc: FRANK@UTAH-20.ARPA, MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Tue 4 Mar 86 00:29:09-PST I think that something put out by PANDA should be called PANDex (or maybe exPANDex)! Stu ------- 5-Mar-86 06:21:46-PST,3439;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 06:21:31-PST Date: Wed 5 Mar 86 09:21:55-EST From: Thomas De Bellis Subject: Re: Disk Exerciser for TOPS-20 To: BROOME@DREA-XX.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: <12188011733.31.BROOME@DREA-XX.ARPA> Message-ID: <12188280044.37.SY.SLOGIN@CU20B.COLUMBIA.EDU> Reid, I don't know if you'll find an exerciser per se, but I can give you a couple of suggestions and let you know what we do here at Columbia when we want to test out a suspected drive. Basically, all we are interested in is whether the drive is getting errors or not and we don't particularly care how we find this out. The only constraint we have is that we'd like to find the information out without having to have the system be unavailable for users. We'd also like the testing procedure to not crash the system nor overly effect system performance. This precludes the use of regular diagnostics because either you've got to have the system running that funny field circus diagnostic monitor or you've got some other program doing special seeks all over the place under timesharing and things can get confused. The following solution was actually thought up by our operations staff and it is now our standard procedure for verifying disks. The disk is mounted in a batch job and then set unavailable to new users. The batch job uses MAKDMP to create a nice *BIG* file. It then spends the rest of its time copying this file all over the place in the disk. This is accomplished by a simple batch loop: FOO:: @COPY DUMP.EXE.0 DUMP.EXE.-1 @BACKTO FOO When it gets an error (ie, the structure is full), Batcon makes it go to an error label. Here, all the files except one are deleted and the entire structure is expunged. If an error occurs during this part, we assume something is wrong and abort the batch job. Otherwise, we jump back to the FOO:: label and start all over. Now for the fun part: we let this batch job run *several days*! By doing this, we have shaken out marginal drives that have passed diagnostic tests. Clearly, a lot of disk activity is going on here that you want to have happen. The drive is being tested under conditions that are exactly like or worse than normal operating conditions. Things like the disk bit table get written a lot, FDB's get created and deleted; yep, lots of good stuff. To see how the drive is actually doing, we simply run SPEAR and look at the errors for the drive. This is better than us trying to interprete some obscure diagnostic's output. We know how to read SPEAR listings and Field Service knows how to read it also (well, mostly). There is seldom (if ever) disagreement as to how the drive is performing. If you are interested in the batch job, let me know and I'll mail it to you. If you really want a program to do this, it is pretty easy to cobble up a macro program that does PMAP%'s until the disk fills up and then deletes pages. Alternatively, I remember a program called DIRTST on the SWSKIT that has a verify command that reads from the disk. You may want to try that. Hope I've been of some help, -- Thomas De Bellis Columbia Computer Center ------- 5-Mar-86 08:32:16-PST,651;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 08:32:04-PST Date: Wed 5 Mar 86 11:30:02-EST From: Ken Rossman Subject: Re: My Intgration/Migration To: GROSSMAN@SU-SIERRA.ARPA, MRC%PANDA@SUMEX-AIM.ARPA cc: FRANK@UTAH-20.ARPA, MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Stu Grossman " of Wed 5 Mar 86 03:54:06-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12188303366.74.SY.KEN@CU20B.COLUMBIA.EDU> sPANDex? PANDOS? PANDAmonium? ------- 5-Mar-86 12:00:35-PST,737;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 12:00:24-PST Date: 5 Mar 1986 1459-EST From: Bill Melohn To: Ken Rossman , GROSSMAN@SU-SIERRA.ARPA, MRC%PANDA@SUMEX-AIM.ARPA cc: FRANK@UTAH-20.ARPA, MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224" Subject: Re: My Intgration/Migration Message-ID: <"MS11(5136)+GLXLIB5(0)" 12188341464.17.108.10760 at MARLBORO.DEC.COM> References: Message from Ken Rossman of 5-Mar-86 1142-EST In-reply-to: <12188303366.74.SY.KEN@CU20B.COLUMBIA.EDU> PANDora? -------- 5-Mar-86 14:29:36-PST,905;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 14:29:00-PST Date: Wed 5 Mar 86 14:27:25-PST From: Stu Grossman Subject: Re: Disk Exerciser for TOPS-20 To: Sy.SLogin@CU20B.COLUMBIA.EDU cc: BROOME@DREA-XX.ARPA, Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Thomas De Bellis " of Wed 5 Mar 86 07:02:31-PST There is a program called PAGES that does a fairly good job of testing disks. I beleive that it comes on the tools tape. Basically, it can be used to generate and verify the contents of a set of test files. You can control the number of files, and their size. It also has some whizzies for controlling the data pattern and other things. Additionally, it also returns some performance figures for the set of operations it was told to do. Stu ------- 5-Mar-86 16:20:02-PST,742;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 16:19:44-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 5 Mar 86 12:55:30-PST Date: Wed 5 Mar 86 12:50:12-PST From: Mark Crispin Subject: Re: My Intgration/Migration To: sy.Ken@CU20B.COLUMBIA.EDU cc: GROSSMAN@SU-SIERRA.ARPA, MRC%PANDA@SUMEX-AIM.ARPA, FRANK@UTAH-20.ARPA, MELOHN@MARLBORO.DEC.COM, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12188303366.74.SY.KEN@CU20B.COLUMBIA.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12188350729.8.MRC@PANDA> Hmm. My 2020's MONNAM.TXT is "4664 Pandamonium Reigns!"... ------- 5-Mar-86 22:15:11-PST,4674;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 22:14:55-PST Date: Thu 6 Mar 86 01:15:31-EST From: Ken Rossman Subject: DEC20<->VAX DECnet: HELP!!! To: TOPS-20@SU-SCORE.ARPA cc: sa.Dev@CU20B.COLUMBIA.EDU, sy.Ken@CU20B.COLUMBIA.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12188453642.15.SY.KEN@CU20B.COLUMBIA.EDU> To those of you who enjoy figuring out tough DECnet datacomm problems, here's a real toughie we've been working on for a long time now. For the past month and a half, we have been trying to get a VAX 780 and a DEC-20 (DN20) to talk to each other, but no matter what we try, no matter what hardware we replace, we aren't able to get them to sign on. Here is the initial link config information: - The VAX-780 (CUCHEM) and the DEC-20 (CU20B) HAD been talking very well for the past few years until this past mid January. - They used a synchronous link, running at 19.2K baud, over Gandalf LDS309 modems. A KDP (KMC11/DUP11 combination) is used on the 20 (DN20) end, and a DMR11 is used on the VAX end. - The modems do the synch clocking. - The DN20 is still Phase III DECnet (though the TOPS-20 system it is attached to is TOPS-20 V6.1, Phase IV). The VAX is Phase IV (VMS 4.2). - As far as we know or remember, no software changes were made to either the 20 or the VAX across the period during which the link has not been working. When the link stopped working, an initial look revealed that the modem at the VAX end had failed. This was replaced. However, these modems need tuning for the particular line they are on, and during the tuning process, special high speed modules (DIP chips) which allow the modems to run at 19.2K baud were damaged. The modems, therefore, had to be run at 9600. Second round: - LDS309's tuned for the line, and run at 9600 while new high speed modules are put on order. - Modems and wire seem to be working fine on the bit level. Bit error rate tester shows bit samples over loopback at over a million bits and no errors. - DECnet loopback also works fine through both modems (i.e. from the 20 to the VAX's modem, and from the VAX through to the 20's modem). - All loops are completely clean. - Although bits and loopback packets seem to go through fine, when the modems are placed in normal operation mode, the two machines simply refuse to talk to each other. Round three: - We were able to dig up a new set of LDS309 modems which did not need special high speed modules to run at 19.2K. We put these modems on both ends of the wire, and are back up to 19.2K baud. This seems to make a DMR happiest (9600 baud has never worked well with a DMR and DECnet here for some reason). - Again, the modems are properly tuned, and pass all bits through without error, and DECnet loopback test packets just fine. - While loops work fine, placing the modems in normal mode still does not cause a proper DECnet signon to happen. Round four: - We finally decided to get a little smarter and put a data scope on the link. We now have records of proper DECnet signon over a working link and the attempted signon of this 20-VAX link. - We seem to get the following DDCMP signon sequence: START START STACK ACK DATA after which, for some strange reason, the whole START, START, STACK, ACK starts over again (no ACK or NAK of the data packet, and no apparent timeout -- at least it seems to happen fast enough that it would not seem to be a timeout condition). - We are also seeing some very short packets coming across (far too short -- like synchs a character or two, and then idle bits). - Earlier in the evolution of this problem, we saw short packets also, though they were only a byte or so short, AND we saw NAK packets, with bad CRC reason codes (just what you'd expect). This was before today, when we had the DMR in the VAX replaced. Now I am not sure exactly what we've got. We haven't analyzed the latest DDCMP signon printouts we got from the data scope tonight yet. So there you have about a month and a half's worth of mess. If ANYONE who has worked with DECnet at all has ANY ideas to offer (particularly anyone at DEC who has worked with this level of signon, and with synch modem connections of this type) has anything to offer at all, PLEASE speak up. We are out of things to try. /Ken ------- 5-Mar-86 23:41:51-PST,605;000000000000 Return-Path: <@MC.LCS.MIT.EDU:JTW@SPEECH.MIT.EDU> Received: from MC.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 23:41:32-PST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 MAR 86 02:41:39 EST Date: Wed 5 Mar 86 14:41:01-EST From: John Wroclawski Subject: Emulex DH? To: tops20@SU-SCORE.ARPA cc: alw@DEEP-THOUGHT.MIT.EDU Anybody know for sure whether you {can,can't} use an Emulex DH replacement on an unmodified RSX20F FE? Assuming it works at all, can the wonderful (?) RSX autobaud code deal with it? thanks, -john ------- 6-Mar-86 08:11:51-PST,595;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 08:11:36-PST Date: Thu 6 Mar 86 08:12:10-PST From: Bob Knight Subject: Re: Emulex DH? To: JTW%MIT-SPEECH@MC.LCS.MIT.EDU, tops20@SU-SCORE.ARPA In-Reply-To: Message from "John Wroclawski " of Thu 6 Mar 86 00:14:21-PST Message-ID: <12188562259.36.KNIGHT@SRI-NIC.ARPA> I dunno for sure about an Emulex, but I've used Dilog and Able boards with success. However, this was before the advent of the new autobaud code. Bob ------- 6-Mar-86 11:22:21-PST,981;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 11:22:10-PST Date: Thu 6 Mar 86 10:53:20-PST From: Stu Grossman Subject: Re: DEC20<->VAX DECnet: HELP!!! To: sy.Ken@CU20B.COLUMBIA.EDU cc: TOPS-20@SU-SCORE.ARPA, sa.Dev@CU20B.COLUMBIA.EDU In-Reply-To: Message from "Ken Rossman " of Wed 5 Mar 86 23:15:08-PST You may be getting bitten by Routing passwords verification. I beleive that the VAX may be requiring a valid password from the DN20's routing layer before it will talk to it. The command on the VAX that controls this is in NCP. I beleive that it's called SET CIRCUIT PASSWORD, or maybe SET EXECUTOR VERIFICATION ON/OFF. You can also alter the password in the DN20 by hacking one of the files output by NETGEN. I beleive the file you want is a .M11 (or .MAC) file, and the password is DECNET-20 or something like that. Stu ------- 6-Mar-86 12:38:24-PST,885;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 12:38:03-PST Date: Thu 6 Mar 86 15:17:56-EST From: Eric R. Crane Subject: Re: Emulex DH? To: JTW%MIT-SPEECH@MC.LCS.MIT.EDU cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "John Wroclawski " of Thu 6 Mar 86 02:52:07-EST Office: Ucc 134, (412) 268-3568 Secretary: Ava Ford, (412) 268-2638 Message-ID: <12188606997.71.EC0N@TE.CC.CMU.EDU> We are using them on 6 of our 20's here for a total of 80 lines per system. I did not have to make any changes to V15-15, except for the supplied patches. We did have some problems with the Unibus terminators though, I can not remember what, and since the person who did the work is nolonger around I can not find out what it was. - Eric Crane Carnegie Mellon ------- 6-Mar-86 18:03:55-PST,1020;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 18:03:41-PST Received: from philabs.UUCP by seismo.CSS.GOV with UUCP; Thu, 6 Mar 86 21:02:28 EST Received: by philabs.uucp (4.12/3.14) id AA08175; Thu, 6 Mar 86 07:52:31 est Date: Thu, 6 Mar 86 07:52:31 est From: Return-Path: Message-Id: <8603061252.AA08175@philabs.uucp> To: philabs!seismo!TOPS-20@SU-SCORE.ARPA Subject: FB%NDL fix again Mark's fix is good, but this fix is probably what DEC would really want: In subr DELFIL in DISC.MAC, move the two lines that read SETZRO FBADR,(D) CALL UPDDIR down lower so they follow the lines TXNE A,FB%NDL JRST [ MOVEI A,DELX13 ;YES - RETURN AN ERROR JRST DELFIX] This performs the test for FB%NDL *before* blasting the index block address and updating the directory. (It also makes the comments read more sensibly!) rick ace philabs!nyit!rick@SEISMO.ARPA 7-Mar-86 01:17:08-PST,1114;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 01:16:58-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 7 Mar 86 01:19:01-PST Date: Fri 7 Mar 86 01:12:40-PST From: Mark Crispin Subject: another FB%NDL bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12188748034.8.MRC@PANDA> Just when you thought it was safe to twiddle the FDB bits at night...You have entered the FB%NDL zone! Problem: You can rename a file on top of a file that is FB%NDL. The pages of the former FB%NDL file are lost to the system. Diagnosis: The code in DSKREN blithly assumes that it is alright to ignore errors from DSKDEL because it always fails in the DSKREN case. This is wrong, but on the other hand by the time we get to that point we have already nuked the source FDB and we had better go through with the rename or we will nuke the source file. Solution: Coming soon to a mailbox near you. ------- 7-Mar-86 12:03:45-PST,567;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 12:03:20-PST Date: Fri, 7 Mar 86 20:02 GMT From: HAMMON%LLL@LLL-MFE.ARPA Subject: RE:DEC20<->VAX: HELP!!! To: tops20@SU-SCORE.ARPA From: Randy Hammon To: sy.ken@cu20b.arpa cc: tops20@SU-SCORE.ARPA I had some trouble of a similar flavor and had to fix it by( at the vax end ) issuing "set node ""your dn20 node number"" receive password decnet20" to ncp. Evidently the password it's looking for is DECNET20. ------- 7-Mar-86 12:27:23-PST,648;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 12:27:06-PST Received: ID ; Fri 7 Mar 86 15:08:11-EST Date: Fri 7 Mar 86 15:08:07-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: Address space query To: TOPS-20@SU-SCORE.ARPA Message-ID: <12188867354.17.VAF@C.CS.CMU.EDU> Could someone enlighten me as to what is necessary to create a new monitor section? We have run out of room in MNTSEC for the host table, so I want to move it to its own section. What data structures do I need to add, what to I have to tell the pager at initialization, etc.? --Vince ------- 7-Mar-86 13:05:25-PST,639;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 13:05:11-PST Date: 7 Mar 1986 1604-EST From: Tom Blinn To: tops20@su-score Subject: Computervision CADDS 4 workstation query Message-ID: <"MS11(5136)+GLXLIB5(0)" 12188877637.19.275.6882 at MARLBORO.DEC.COM> Is anyone out there using a Computervision CADDS 4 workstation with TCP/IP to network with TOPS-20? If so, was the hookup reasonably straight-forward? What application support is TOPS-20 providing for the workstation? Any information will be appreciated. Tom Blinn -------- 7-Mar-86 14:50:05-PST,1266;000000000000 Return-Path: Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 14:49:29-PST Received: from bostonu by csnet-relay.csnet id aj02042; 7 Mar 86 17:22 EST Received: by bu-cs.ARPA (5.31/4.7) id AA00290; Fri, 7 Mar 86 16:44:48 EST Return-Path: Received: by bucsd.ARPA (5.31/4.7) id AA00409; Fri, 7 Mar 86 16:45:01 EST Date: Fri, 7 Mar 86 16:45:01 EST From: budd%bostonu.csnet@CSNET-RELAY.ARPA Message-Id: <8603072145.AA00409@bucsd.ARPA> To: tops-20@su-score.ARPA Subject: TOPS-20 vs. Solar Wind A month ago we installed a pair of SUN-3's; the two systems share major filesystems via NFS over the "house" ethernet (pending arrival of additional hardware). Ever since the binary system went into production (15 users each), we have had problems with our '20. The twenty is unable to run for more than a day or two (usually about 24 hours) before we are crushed by screaming BUGxxxs. KNIFQE/IPIBLP is most common among other internet BUGs. This occurs even with a VANILLA DEC monitor. The monitor we run is 5.4(1025), which is postively ancient. Has this problem been previously diagnosed or cured? Thanks!! Phil Budne Boston University / Distributed Systems 7-Mar-86 16:48:10-PST,2204;000000000000 Return-Path: Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 16:47:51-PST Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.03/4.7.34) id AA16125; Fri, 7 Mar 86 16:49:45 pst Message-Id: <8603080049.AA16125@decwrl.DEC.COM> Date: Friday, 7 Mar 1986 16:46:09-PST From: ridder%warlok.DEC@decwrl.DEC.COM (Hans) To: tops20@su-score Subject: Re: DEC20<->VAX DECnet: HELP!!! Date: 7 Mar 1986 1741-MST From: Hans To: "TOPS20@SU-SCORE" at DECWRL Subject: Re: DEC20<->VAX DECnet: HELP!!! Message-ID: <"MS10(2137)+GLXLIB5(0)" 12188917193.10.143.84173 at WARLOK.TCP> If it is the vax which starts over with the DDCMP START, then what you have is a Router Verification rejection. (You might try turning on logging of DECnet events to the console to verify this.) VMS thinks that phase III nodes should do verification /even if you tell it NOT to!/ The DN20 sends a password of DECNET20 by default so what you want to do is tell the vax about it like this: NCP> SET NODE DN20:: RECEIVE PASSWORD DECNET20 NCP> DEFINE NODE DN20:: RECEIVE PASSWORD DECNET20 using NCP on the vax (DN20:: is whatever your DN20's name is). Also, while we're on the subject of phase III/phase IV problems, if you have a problem with the DN20 setting the circuit state to OFF whenever it (or the vax) crashes, try this one: NCP> SET CIRCUIT TRANSPORT TYPE ROUTING 3 NCP> DEFINE CIRCUIT TRANSPORT TYPE ROUTING 3 to the vax also (substitute the proper name of the circuit going TO the DN20). This tells the vax to never send a phase IV packet to whatever is on the other end of the circuit. The DN20 code is quite paranoid and shuts off the circuit whenever it gets a packet it doesn't understand (contrary to DECnet specifications). For those who don't understand the difference between SET and DEFINE, SET changes the "volitile" database which only lasts until the next re-boot, DEFINE changes the "permanent" database which is used a boot time to initialize the volitile database (in other words DEFINE makes it stick!). -hans -------- 7-Mar-86 17:03:49-PST,740;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 17:03:24-PST Date: Fri 7 Mar 86 18:02:56-MST From: Mark Crispin Subject: Re: TOPS-20 vs. Solar Wind To: budd%bostonu.csnet@CSNET-RELAY.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: <8603072145.AA00409@bucsd.ARPA> Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12188921026.17.MRC@SIMTEL20.ARPA> KNIFQE/IPIBLP generally indicate a paucity of buffers. Some work was done in July '84 to alleviate this problem; this was UPD ID 212, IPNIDV.MAC.68. It shouldn't be hard to fix this problem. I wonder if your SUNs are in broadcast-happy mode? ------- 7-Mar-86 17:08:50-PST,1972;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 17:08:31-PST Date: 7 Mar 1986 2007-EST From: Bob Longo To: Ken Rossman , TOPS-20@SU-SCORE.ARPA cc: sa.Dev@CU20B.COLUMBIA.EDU Mail-Stop: LAO Phone: 213-417-4240 Subject: Re: DEC20<->VAX DECnet: HELP!!! Message-ID: <"MS11(5136)+GLXLIB5(0)" 12188921888.14.355.12342 at MARLBORO.DEC.COM> References: Message from Ken Rossman of 6-Mar-86 0151-EST In-reply-to: <12188453642.15.SY.KEN@CU20B.COLUMBIA.EDU> I have seen situations similar in the past. I would look VERY carefully at the DMR switch settings. I has the ability to talk to both DDCMP version 4.0 and (with the switch in the other setting) to prior versions. I had this problem when I tried to connect a DMR and a DMC together. It took some doing to get the combinations correct. Here is what I have found to work: Switch Pack Settings =========== ======== E134 1-9 off, 10 on E121 1-8 on, 9 off, 10 on E39 1-7 off, 8-9 on, 10 off Another gotcha can be the distribution panel for the DMR. I found that the panel comes from the factory set so that Field Service can run diagnostics, but will not work when you try to hook it up to a modem. So, look also at the H3001 switch settings (field service is supposed to know how to properly set them). I have also run up against problems with modems that do not signal properly, e.g., they work for an IBM system, but not with ours. We had to use some very fancy equipment to see in what order signals were raised, as the software in the DN20 waits for a proper sequence before proceeding. I doubt this is your problem, but you may want to keep it in mind. Good luck and let me know what the solution turns out to be. -------- 9-Mar-86 11:48:45-PST,6986;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 9 Mar 86 11:48:35-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 9 Mar 86 11:38:11-PST Date: Sun 9 Mar 86 01:44:50-PST From: Mark Crispin Subject: FB%NDL: The Final(?) Chapter To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12189278179.2.MRC@PANDA> After a lot of work, I've come to the conclusion that FB%NDL was never completely implemented by DEC. It turns out that it was never set for the root-directory files it was supposed to be set for, nor were the implications for rename considered, and it's obvious that the DELFIL (which expunges a file) check for FB%NDL was never tested. I have fixed all of these problems in the PANDA monitor. I won't bother with listing the root-directory files changes, since setting FB%NDL can always be done by hand. Those changes are fairly obvious, if tedious, ones to FILINI and DSKALC. All the other changes below are to DISC. Fixing DELFIL was fairly simple. I elected to adopt Rick Ace's suggested fix, which is to move the lines: SETZRO FBADR,(D) ;REMOVE XB ADR FROM DIR CALL UPDDIR ;UPDATE DIRECTORY, FILE IS EFFECTIVELY at DELFIL+16L down so that it comes after the lines: TXNE A,FB%NDL ;IS THIS FILE MARKED "NEVER DELETE"? JRST [ MOVEI A,DELX13 ;YES - RETURN AN ERROR JRST DELFIX] and before the line MOVE A,P3 ; GONE AFTER THIS POINT. Fixing DSKREN was more complicated. First, I decided that a file that is set FB%NDL should be disallowed as the source or destination of a rename. There are ways to avoid both of these, but I felt semantically that a file that you care enough about that you disallow deletion even by privileged users should not have its data pages renamed away or destroyed. If you wish to allow the source file of a rename to be FB%NDL, then you should not include the check for it or the RENDF1 bugchk. What will happen if you rename an FB%NDL file will be that the data pages will be renamed to the destination file, but the source FDB will not be destroyed and will remain as an empty file. If you wish to allow the destination file of a rename to be FB%NDL, then you should not include the check for it. You will need to do some work in the DELFIL loop for the destination file; probably the best way would be to temporarily turn off FB%NDL at the same time FB%PRM is turned on before the loop, then undo the mischief after the DELFIL succeeds. I haven't extensively exercised these possibilities, as I was more interested in making RNAMF% involving an FB%NDL file not lose pages from the filesystem and (as noted above) I think that a file that is "undeleteable" should not be "deleteable" by allowing its rename elsewhere or its being renamed over. I should note that an FB%NDL file can be overwritten by a program that opens that generation for write. Also, a new generation of the file can be written. This seemed consistant with my perception of the semantics of FB%NDL -- a file that can be updated, but cannot be deleted. The changes to DSKREN follow. At DSKREA+20L, after: TXNE B,FB%LNG ;IS IT A LONG FILE SETOM DSKTYP ;YES - INDICATE insert: TXNE B,FB%NDL ;IS DESTINATION FILE MARKED "NEVER DELETE"? RETBAD (DELX13,) ;YES, DISALLOW This will disallow destination files in RNAMF% from having FB%NDL set. At DSKREO+2L, after: MOVE A,SRCFDB ;RESTORE SOURCE FDB insert: TMNE FB%NDL,.FBCTL(A) ;IS SOURCE FILE MARKED "NEVER DELETE"? RETBAD (DELX13,) ;YES, DISALLOW This will disallow source files in RNAMF% from having FB%NDL set. At DSKRE1+39L, after: CALL DELFIL ;... replace: JFCL ;MIGHT COME HERE IF PERMANENT with: IFNSK. ;;; DELFIL failed for a miscellaneous reason (not permanent as DEC's comment ;;;states). This isn't very serious, since the file pages are being moved by ;;;us. However, an old crufty FDB has been left behind, so we log it. MOVE A,DIRORA ;GET BASE ADDRESS OF DIR LOAD A,DRNUM,(A) ;GET DIR # OF MAPPED DIR LOAD B,CURSTR ;GET THE STRUCTURE NUMBER BUG.(CHK,RENDF1,DISC,SOFT,,<,>) ENDIF. This will bugchk RENDF1 any failure to eliminate the FDB of the source file (the file pages have already been removed). This generally will happen only when the archiving system is sick or in some wierd file opening timing race. It will not happen if the source FDB is permanent, in spite of the DEC comment. 27 lines further down, replace: CALL DELFIL ;DELETE OLD CONTENT OF DESTINATION JFCL ;ALWAYS FAILS SINCE PERMANENT BIT SET with: ;;; If DELFIL fails, it isn't because the FDB was permanent. Whatever the ;;;condition was, if there is an index block address we had better correct ;;;it otherwise we'll lose disk pages. DO. CALL DELFIL ;DELETE OLD CONTENT OF DESTINATION SKIPN .FBADR(D) ;LOST, IS THERE AN INDEX BLOCK? EXIT. ;WON OR NO INDEX BLOCK, CONTINUE MOVX B,FB%NDL ;"HOUSTON, WE HAVE A PROBLEM HERE" TDNN B,.FBCTL(D) ;DID IT GET MARKED "NEVER DELETE"? IFSKP. ANDCAM B,.FBCTL(D) ;YES, MUST BE A TIMING RACE, BUT WE MUST WIN LOOP. ; IT, SO NUKE THE BIT AND DO IT AGAIN ENDIF. IFQN. FBARC,(D) ;HAVE ARCHIVE STATUS? MOVX B,AR%NDL ;YES, SEE IF PROHIBITED TDNN B,.FBBBT(D) ;WELL? ANSKP. ANDCAM B,.FBBBT(D) ;THAT'S THE PROBLEM, NUKE THAT BIT LOOP. ;TRY IT AGAIN ENDIF. CAIE A,DELFX2 ;DESTINATION FILE BUSY? BUG.(HLT,RENDF2,DISC,SOFT,) MOVX A,^D1000 ;UGH. CAN'T DO MUCH ABOUT THIS DISMS% ;WAIT A SECOND LOOP. ;NOW TRY AGAIN ENDDO. This catches all the conditions where the destination file's old index block could not be deleted. The AR%NDL condition is pretty unlikely since AR%RAR should also be set which would have been nabbed by ARACCK early on. However, it is possible although unlikely that a race condition could have set this, as it could have set FB%NDL. At this point we have already removed the index block from the source FDB, so we really do want to plop it down in the destination FDB -- this is why I decided to nuke any AR%NDL or FB%NDL bits which may have been set by a race since (1) the condition is unlikely (2) if it happens it was probably deliberately provoked by a hacker (3) the alternative is to lose disk pages I am less happy about the DELFX2 handler, but if that particular situation happens there is relatively little that can be done. I'd still claim that it is highly unlikely to happen in an uncontrived situation and so again the goal should be to seek for the means that does not lose disk pages. -- Mark -- ------- 11-Mar-86 16:37:16-PST,1029;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 11 Mar 86 16:37:01-PST Date: Tue 11 Mar 86 19:39:14-EST From: Frank da Cruz Subject: TOPS-20 LAT Service To: TOPS20@SU-SCORE.ARPA Message-ID: <12189965286.29.SY.FDC@CU20B.COLUMBIA.EDU> TOPS-20 LAT service apparently does not allow 8-bit transparent terminal i/o. Binary files cannot be sent to DEC-20 Kermit through a LAT box (DECserver 100) unless you give SET PARITY commands to Kermit to force it to use 8th-bit prefixing. The same binary files can be sent to DEC-20 Kermit through a regular terminal port without having to use 8th-bit prefixing. In other words, all the SFCOC's, MTOPR's, SFMOD's, STPAR's, and STIW's you must do to make the terminal transparent just don't work for a LAT terminal. By contrast, Ultrix LAT service does not pose this problem -- opening a LAT terminal in raw mode in Ultrix works just like opening a regular terminal in raw mode. ------- 12-Mar-86 14:08:34-PST,1167;000000000000 Return-Path: Received: from anl-mcs.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:08:13-PST Received: by anl-mcs.ARPA (4.12/4.9) id AA06095; Wed, 12 Mar 86 16:11:35 cst Date: Wed, 12 Mar 86 16:11:35 cst From: nugent@anl-mcs.ARPA (Nugent) Message-Id: <8603122211.AA06095@anl-mcs.ARPA> To: tops-20@su-score Subject: Tops-20 TCP NVT question Cc: nugent@anl-mcs.ARPA Problem: The ATNVT% JSYS does not like to attach NVTs to TCP connections which are not new. However, I want to have a Deamon read a few characters on a connection and then start up a job on an NVT depending on what it reads (RSHD). Does anyone know of a way to work around this? I have tried the obvious ways: Open another JFN with a different local port #. Althought the MCRF says this is possible, the local port is forced to be the same. Setting TCP PUSH on receive doesn't help because there are still buffers allocated. The BBN code does not like you to close and reopen the connection, even if I could get the remote host to cooperate. Various attempts to close and flush buffers with TCOPR% generate ILPTN1 bughlts. 12-Mar-86 14:19:14-PST,833;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:18:25-PST Date: Wed, 12 Mar 1986 17:20 EST Message-ID: From: Rob Austein To: nugent@ANL-MCS.ARPA (Nugent) Cc: tops-20@SU-SCORE.ARPA Subject: Tops-20 TCP NVT question In-reply-to: Msg of 12 Mar 1986 17:11-EST from nugent@anl-mcs.ARPA (Nugent) I'm pretty sure you can't get there from here, because once you have read from the connection as a file you have all sorts of buffers irrevocably allocated (some of them in the layer between the JFN and JCN interfaces, some of it in the depths of the BBN code). If you ever figure out how to do this, let me know. I could get incoming TCP SUPDUP running in ten minutes if I could get around this. 12-Mar-86 14:30:11-PST,716;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:29:48-PST Date: Wed 12 Mar 86 15:31:44-MST From: Walt Subject: Re: Tops-20 TCP NVT question To: nugent@ANL-MCS.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: <8603122211.AA06095@anl-mcs.ARPA> Message-ID: <12190204221.24.HAAS@UTAH-20.ARPA> For my TOPS-20 implementation of the Unix daemons, I eventually punted on this problem by having the daemon do a passive open, and start a new copy of itself as soon as the TCP connection completed. This was done on a straight TCP JFN not an NVT however. If you come up with a more elegant solution let me know! Cheers -- Walt ------- 12-Mar-86 14:57:27-PST,1066;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:57:03-PST Received: ID ; Wed 12 Mar 86 17:59:48-EST Date: Wed 12 Mar 86 17:59:46-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: Tops-20 TCP NVT question To: SRA@XX.LCS.MIT.EDU cc: nugent@ANL-MCS.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message-ID: <12190209322.34.VAF@C.CS.CMU.EDU> One hack you could try would be to ATNVT% the jfn and then ASND% the TVT. You can then read some stuff from the TVT and when you're done, CRJOB% a new job onto the NVT (doing a RELD% might be sufficient). The problem with this is that there is a race condition between the ATNVT% and the ASND% and I don't think that ATNVT% will pick a TVT that has already been ASND%'ed (so you can't assign it first, and then ATNVT% to avoid the race condition). You could probably hack it with some small monitor mods (maybe add an argument to ATNVT% that is the TVT device designator to use?) --Vince ------- 12-Mar-86 16:09:08-PST,1009;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 16:08:45-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 12 Mar 86 16:13:15-PST Date: Wed 12 Mar 86 15:34:26-PST From: Mark Crispin Subject: Re: Tops-20 TCP NVT question To: nugent@ANL-MCS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: <8603122211.AA06095@anl-mcs.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12190215633.11.MRC@PANDA> The easiest way to solve the problem is to have the job being started do the work. That is, instead of CRJOB%'ing the job to have an EXEC or whatever CRJOB% it to have a "pre-EXEC" that does your work and replaces itself with whatever program you want. Not only does this method work and is the point of least resistance, it's also the easiest way to do what you want to do even if ATNVT% didn't have that restriction! ------- 12-Mar-86 16:32:57-PST,2346;000000000000 Return-Path: Received: from columbia.edu by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 16:32:34-PST Received: by columbia.edu (5.31/5.10) id AA05486; Wed, 12 Mar 86 19:35:38 EST Received: by cucca.columbia.edu; Wed, 12 Mar 86 19:36:46 est Date: Wed, 12 Mar 86 19:36:46 est From: Charlie C. Kim To: tops-20@su-score.arpa Subject: The DEC-20 KNI and DEQNAs: one last update The KNI will receive size 64 ARP packets--if you push the minimum packet that it will accept over that by at least 2. The problem probably lies with the KNI or the specification for the KNI. It seems packets which are close to the posted maximum (within 2 bytes) are corrupted. If so, then the same problem should also occur for IP packets which have a maximum of 1500 (in our monitor at least), but I haven't tested this yet (something to look for if you are having problems with large packets though...). The following patches to IPNIDV makes tops-20 allow "68" byte ARP packets (effectively, 66 bytes - better safe than sorry, I hate rebooting the 20s): ------- EMINPL==^D46 ;MINIMUM ETHERNET PACKET LENGTH ncu307,< MINPKT==EMINPL+4 ;MINIMUM ETHERNET PACKET LENGTH PLUS CRC BYTES > cu307,< MINPKT==EMINPL+4+8 ;MINIMUM ETHERNET PACKET LENGTH PLUS CRC BYTES ;plus 8 spill over bytes for silly machines > -------- ; If AR.LEN is less than MINPKT (Ethernet minimum packet size ; plus 4 bytes for the CRC) we must make the ARP packets atleast ; that size. NCU307,< IFL AR.LEN-EMINPL,< AR.WRD==+4 ;WORD SIZE OF ARP PACKET (PLUS A COUPLE) AR.LEN==EMINPL ;BYTES IN ARP PACKET ARE ETHERNET MINIMUM AR.MAX==MINPKT+4 ;MAX BFR SIZE WITH ETHERNET CRC (PLUS 4) > > CU307,< IFL AR.LEN-EMINPL,< ar.wrd==</4>; compute the # of words needed, AR.LEN==EMINPL ;BYTES IN ARP PACKET ARE ETHERNET MINIMUM AR.MAX==MINPKT ;max buffer size includes all the junk ;we need > > -------- Phew, glad to get this out the way (seems like every time I ignored it and fixed the other device, we would get something else that would send oversized packets and we finally got something we don't have source code for yet.) Charlie C. Kim User Services Group Academic Information Systems Division Columbia University ------- 13-Mar-86 11:38:11-PST,2162;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 13 Mar 86 11:37:53-PST Date: Thu 13 Mar 86 14:40:53-EST From: Frank da Cruz Subject: TOPS-20 LAT service vs Kermit, cont'd To: TOPS-20@SU-SCORE.ARPA Message-ID: <12190435261.12.SY.FDC@CU20B.COLUMBIA.EDU> Disregard last message... Turns out that, unbeknownst to me, the behavior reported previously occurred from a PC that was connected by LAT to a VAX Ultrix system that was TELNET'd to a DEC-20 via TCP/IP over Ethernet, and it was TELNET stripping the high order bit, not LAT. However, there is still a problem with DEC-20 LAT service. The symptom is that you can't transfer files of any kind into a DEC-20 through LAT using Kermit or Modem or any similar protocol. You can, however, transfer files from the DEC-20 to the PC with no problem. Logging of a file transfer reveals that a typical Kermit data packet (80-90 characters) is truncated by the LAT box to 30-40 characters. If you reduce the Kermit packet size to, say, 37, then everything works, even binary files without 8th-bit prefixing. The mystery is that everything works fine when the host is a VAX Ultrix system rather than a DEC-20. Therefore, the LAT box itself is not at fault; the culprit must the TOPS-20 LAT service. In fact, the LAT specification says LAT_MIN_RECV_SLOT_SIZE should be in the range 1-255, and 127 is recommended. The TOPS-20 6.1 monitor's LATSRV module, however, sets the corresponding symbol MXSLSI to 40 (decimal). We haven't tried changing the monitor to increase this number, and are not sure what the consequences would be. For now, those who want to use Kermit to send files to a DEC-20 through a LAT box must set their packet size to 37 or less. Those who want to use MODEM will have to use Kermit instead, since MODEM packet sizes cannot be changed. This note does not address the other problems we've been having with TOPS-20 LAT service, like random disconnections, etc. We noticed that several of the other recommended parameter settings are not followed in LATSRV. ------- 14-Mar-86 06:34:13-PST,398;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Mar 86 06:34:03-PST Received: ID ; Fri 14 Mar 86 09:38:27-EST Date: Fri 14 Mar 86 09:38:26-EST From: WOHL@TL-20B.ARPA Subject: edt20 To: tops20@SU-SCORE.ARPA Does anyone know where I can find EDT20? I have the manuals but can't find the executable. Aaron ------- 15-Mar-86 01:41:26-PST,2135;000000000000 Mail-From: BILLW created at 15-Mar-86 01:41:22 Date: Sat 15 Mar 86 01:41:22-PST From: William "Chops" Westfield Subject: new monitor sources probably ready for RDIST... To: su-tops-20@SU-SCORE.ARPA Message-ID: <12190850411.8.BILLW@SU-SCORE.ARPA> I think that the monitor currently running on Score has shown itself stable enough to warant distributing the latest changes to other Stanford tops20 sites. Some important fixes have been made in the network code, and now that most ethertips are using TCP, these fixes are becomming quite important: 1) Fix IPGCOL/INTFR6 buginf/bugchk/problems, effectively by replacing the IPFREE module with a new version from BBN. 2) allow more connections. The defaults are now to have 32 TVTs (score is running with this set to 50 in PARSCO.MAC), and to have the total number of TCP connections be the number of TVTs plus 25. A test in STG that complained about "too many wait bits" has been made more reasonable; TVTs use many fewer wait bits than a full BBN TCP connection, and DEC JFN connections use fewer than STG used to assume. 3) TCB used to be looked up for each packet arriving via a has table hashed off of the local port. When 90% of the connections were on the same local port (telnet), this was not such a good idea, so the table is now hashed off the foreign host and ports also (rewrite CHKADD). And the hash table was made a lot larger... 4) A bug that may have caused extra empty packets to be sent to TVTs has been eliminated, I think. The code was not distinguishing between the case where a packet HAD to be sent (eg, as an ACK) and the case where a packet SHOULD be sent (eg because there was data). It does now. 5) Miscellaneous minor fixes... Modules effected: PARAMS, STG, TVTSRV, TCPTCP, ANAUNV, IPFREE (On score in <6-1-MONITOR>) Enjoy BillW PS The actual TCP code may remain stable for a while - now that TCP is not causing daily problems (though it still isn't as efficient as pup), the next project is to get the ISI/MIT domain code working. ------- 15-Mar-86 17:32:34-PST,2076;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 15 Mar 86 17:32:21-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 15 Mar 86 17:34:15-PST Date: Sat 15 Mar 86 16:48:16-PST From: Mark Crispin Subject: DTR control patch To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191015506.11.MRC@PANDA> By popular demand, I am publishing the latest and greatest DTR control patch. It is in the form of a MIC file. Note the instructions at the bottom of the patch, which are necessary to actually enable the patch. You will have to do this manually since it is different between release 5.1 and release 6.1. This patch enables two new TTY MTOPR% functions. Function 400003 will hang up the given terminal line, function 400004 will pick it up. This is compatible with the functions in Stanford and PANDA monitors, where these functions are given the symbolic names .MOHUP (hang up) and .MODUP (DTR up). This patch uses function .DFLDU (15) to DTEQ, which is supported from the KL to the -11 only in the more recent versions of RSX-20F. If you have an older version of RSX-20F, you'll get an 11-HALT (ILF or some such) when you try to use function 400004. In that case, get a new version of RSX-20F from DEC. @GET SYSTEM:MONITR @START 140 *FFF/DTRPAT:CAIE T3,400003 *DTRPAT+1/JRST DTRPAT+4 *DTRPAT+2/CALL TTHNGU *DTRPAT+3/JRST RSKP *DTRPAT+4/CAIE T3,400004 *DTRPAT+5/RET *DTRPAT+6/JSP CX,SAVT *DTRPAT+7/MOVE A,MSTRDT *DTRPAT+10/MOVS C,B *DTRPAT+11/SKIPA B,.+1 *DTRPAT+12/15,,.FEDLS *DTRPAT+13/CALL FIXARG *DTRPAT+14/HLRZ D,C *DTRPAT+15/SETZ C, *DTRPAT+16/CALL DTEQI *DTRPAT+17/JRST RSKP *DTRPAT+20/FFF: ! Now look at TTMTOP+7 (release 6.1) or TTMTO1+4 (release 5.1). It ! jumps to a literal which has a MOVEI T1,MTOX1 followed by a RET. ! Patch the RET to JRST DTRPAT. Then type CTRL/Z followed by ! SAVE SYSTEM:MONITR.EXE. ------- 16-Mar-86 00:14:42-PST,730;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 16 Mar 86 00:14:31-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 16 Mar 86 00:16:30-PST Date: Sat 15 Mar 86 23:25:47-PST From: Mark Crispin Subject: GFLOAT format To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191087871.11.MRC@PANDA> It appears that KS10's don't implement GFLOAT format floating point. Does anybody know of any version of the KS10 microcode that does? I was under the impression that unlike KL's there was a fair amount of free microcode space in the KS. ------- 16-Mar-86 00:53:31-PST,591;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 16 Mar 86 00:53:21-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 16 Mar 86 00:35:27-PST Date: Sun 16 Mar 86 00:01:42-PST From: Mark Crispin Subject: for your amusement! To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191094411.11.MRC@PANDA> Get a close look at SPR 20-20966 in the 15 February 86 Dispatch, specifically at the PHOTO output... ------- 16-Mar-86 01:55:50-PST,1436;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 16 Mar 86 01:55:43-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 16 Mar 86 01:54:42-PST Date: Sun 16 Mar 86 01:04:55-PST From: Mark Crispin Subject: SPR 20-19605A (in December '85 CTCO) To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191105920.11.MRC@PANDA> I am skeptical of DEC's patch for this. Basically, they have decided that ACJ denials should be respected for logouts due to the timer after a carrier-off interrupt expiring. They've decided that if this happens the job should go and wait for another COFTIM interval and keep on waiting and asking ACJ until the user attaches or the ACJ says OK. The problem with DEC's patch is that they glibly eliminate the entry to JSYS context (which would destroy any possibility of returning to the interrupted code) in the ACJ check. This might be alright, but they do a GTDAL% JSYS which probably is *not* alright to do from exec mode unless you're in JSYS context! Worse, there are a couple of places that the code can get to FLOGO1 without entering JSYS context. I would suggest as a start that the GTDAL% be replaced with CALL IGTDAL and that the FLOGO1 jumps be made to go through the MCENTR path. ------- 17-Mar-86 09:22:54-PST,779;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 09:22:40-PST Date: Mon 17 Mar 86 12:24:20-EST From: Eric R. Crane Subject: Integration tools To: tops-20@SU-SCORE.ARPA Office: Ucc 134, (412) 268-3568 Secretary: Ava Ford, (412) 268-2638 Message-ID: <12191458979.14.EC0N@TE.CC.CMU.EDU> I was going through list of integration tools in the Large Systems News, and for the first time noticed VMAIL/VMAILR. I went to get the files off of the tapes and found only the executables. Does anyone have the source to these? I have an old version of VMAIL that we are using with MMAILR, but I am interested in also being able to send mail to our Vaxen. - Eric Crane Carnegie Mellon ------- 17-Mar-86 10:43:33-PST,1875;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 10:43:15-PST Date: 17 Mar 1986 1342-EST From: Tom Blinn To: Eric R. Crane cc: tops-20@su-score Subject: Re: Integration tools Message-ID: <"MS11(5136)+GLXLIB5(0)" 12191473268.17.275.10192 at MARLBORO.DEC.COM> References: Message from Eric R. Crane of 17-Mar-86 1248-EST In-reply-to: <12191458979.14.EC0N@TE.CC.CMU.EDU> Eric, First, you probably have an older TOOLS tape. On the most recent TOPS-20 tapes, some sources were sent along with the executables. However, there is no guarantee that the sources correspond to the binaries, or are all you might need to rebuild the binaries (in fact, I can assure you that is NOT the case -- sorry about that!). VMAIL and VMAILR are/were unsupported internal tools for exchanging mail between TOPS-20 and VMS systems, and were formerly shipped to SWS (Software Specialists) as part of one of the SWSKIT tapes (I believe it was the DECnet SWSKIT). We're on the verge of releasing MS for both TOPS-10 and TOPS-20. It will include a SUPPORTED mailer agent for exchanging mail with other systems on a DECnet network, including but not necessarily limited to VAX/VMS systems. It also works with TCP/IP, although I'm not sure of the details of which mailer agent we're using. (I'm composing and sending this with our latest internal field test version of the new MS.) While I can't offer to send you the new software, I can assure you that you would be better off just being patient for a little while yet, and waiting for MS. You'll be glad you did. Tom PS: If you really want the VMAIL.MAC and VMAILR.MAC, you can anonymous FTP them from MARKET, out of TOOLS:*.MAC. -------- 17-Mar-86 13:01:43-PST,2858;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 13:01:32-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 17 Mar 86 13:03:12-PST Date: Mon 17 Mar 86 12:57:40-PST From: Mark Crispin Subject: Re: Integration tools To: ECON@TE.CC.CMU.EDU cc: tops-20@SU-SCORE.ARPA In-Reply-To: <12191458979.14.EC0N@TE.CC.CMU.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191497816.8.MRC@PANDA> Here's some information on the MM front re: DECnet mailing to VAXen, for those of us who have no interest whatsoever in MS. The primary problem with DECnet mailing to VAXen is that VMS uses a goofy mail transport protocol called MAIL11 which (like many other DEC protocols) is almost but not quite usable. I hope the membership of this list will take my word on this and not require me to go into nauseating details why. There are two outs. The first, which I consider the superior approach, is to use SMTP over DECnet. While SMTP isn't the Ultimate Mail Transport Protocol either, at least it is usable for 7-bit text. It turns out that there actually is an assigned DECnet service for it -- object TASK, name MX-LISTENER. MMailr will deliver DECnet SMTP mail to this service, and the MM-supplied SMTDCN utility will listen for incoming mail and fire up MAISER's to handle it. I know of several sites which have written VMS DECnet SMTP listeners that talk to MMailr, most using the old interim 127 object (but presumably easy to fix to use TASK MX-LISTENER). Despite repeated requests, none of these sites have made their VMS software publicly available. The usual excuse is "we're still working on it." If I don't get some software from one of you soon I'll start naming names... The other out which is barely acceptable as an interim solution is to use a modified VMAIL/VMAILR to talk MAIL11 to VMS. There is a modified version of VMAIL on the MM distribution directory ([SIMTEL20] for you ARPA folks). There is also a version of VMAILR floating around that will interact with a slightly modified MMailr (at some loss of MMailr performance). The main problem with these tools are the protocol related ones and also that you can only have one message coming into the -20 at a time. I have been talking with various people at DEC about getting MMailr and MX (the DEC DECnet equivalent of MMailr) to interact in nice ways. You can expect progress in this area this year. However, to my thinking this will only replacce VMAIL/VMAILR. This is great in itself but I still think the best way is to go SMTP for all DECnet hosts, especially if you are also an ARPA site. MAIL11 just has too many shortcomings. ------- 17-Mar-86 15:57:41-PST,925;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 15:57:29-PST Received: ID ; Mon 17 Mar 86 19:01:08-EST Date: Mon 17 Mar 86 19:01:07-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: Domain service query To: tops-20@SU-SCORE.ARPA Message-ID: <12191531211.6.VAF@C.CS.CMU.EDU> Has anyone had any trouble using the ISI/BBN Domain server stuff for TOPS-20? It was working fine here until a few days ago when some of the hosts suddenly vanished from DSV's knowledge. MAKEDB gives no errors when processing the source for our domain database and I can't see anything wrong with the domain database either, but DSV doesn't think all records matching some pattern (*.SEI.CMU.EDU, for the curious) exist. Are there any known bugs in the system that would cause this or, can anyone think of something I might have missed? Thanks, --Vince ------- 17-Mar-86 17:03:57-PST,553;000000000000 Return-Path: Received: from hplabs.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 17:03:43-PST Received: from HP-HULK by hplabs.ARPA ; Mon, 17 Mar 86 17:04:29 pst Date: Mon 17 Mar 86 17:04:47-PST From: Haruka Takano Subject: 4M for rel 5? To: Tops20%Score@HPLABS I seem to remember a discussion a while back on this mailing list about mods to allow 4M of memory on a system. Is this available for release 5? Is anyone running with 4M? Thanks for any pointers. --Haruka ------- 18-Mar-86 00:05:38-PST,1134;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Mar 86 00:05:28-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 18 Mar 86 00:07:29-PST Date: Mon 17 Mar 86 23:28:31-PST From: Mark Crispin Subject: Re: 4M for rel 5? To: Takano%HP-HULK@HPLABS.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Haruka Takano " of Mon 17 Mar 86 23:04:55-PST Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191612659.8.MRC@PANDA> You can't really have 4M on a KL system because the RH20 can't do I/O to the last page. Leaving that aside, it is difficult to build a 4M system for release 5 due to the address space eaten up by the CST's -- you need 64 pages of section 1 address space. That's out of the question for systems with networks, although it may be possible to squeeze it for a non-network system that's otherwise intelligently configured. Release 6 systems fix this problem since the CST's are out of section 1. ------- 18-Mar-86 00:41:32-PST,579;000000000000 Return-Path: Received: from hplabs.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Mar 86 00:41:16-PST Received: from HP-HULK by hplabs.ARPA ; Tue, 18 Mar 86 00:41:21 pst Date: Tue 18 Mar 86 00:41:36-PST From: Haruka Takano Subject: Re: 4M for rel 5? To: MRC%PANDA@SUMEX-AIM.ARPA Cc: Takano%HP-HULK@HPLABS, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Tue 18 Mar 86 00:07:19-PST I thought that might be the case, but I wanted to make sure. Thanks. --Haruka ------- 18-Mar-86 19:19:50-PST,2322;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Mar 86 19:19:37-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 18 Mar 86 19:15:02-PST Date: Tue 18 Mar 86 19:09:33-PST From: Mark Crispin Subject: major change to 1822 (IMP) software To: TOPS-20@SU-SCORE.ARPA, TCP-IP@SRI-NIC.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12191827659.11.MRC@PANDA> All sites should be aware of the changes to the ARPANET, Milnet, DRENET, and other BBN IMP-based networks using the 1822 protocol that are announced in RFC 979. This report, "PSN END-TO-END FUNCTIONAL SPECIFICATION" is a MUST read by the site personnel responsible for the network software for every host on these networks. This report succumbs to the popular tradition of changing terminology just as we've gotten accustomed to the old terminology. Basically, an IMP is now called a PSN (Packet Switch Node) and the protocol/software that runs on the IMP is now called EE (End-to-End protocol and module). The most important changes are as follows: (1) VDH hosts are no longer supported. If you're still a VDH, you had better replace your VDH with a pair of ECU boxes, etc. I think VDH's are extinct animals these days though. (2) Uncontrolled (subtype 3) regular messages will no longer be supported. This is being replaced by a new Datagram service. All the other changes are upwards compatible and in general are wins. I am concerned about change (2) above. TOPS-20 uses uncontrolled regular messages and other operating systems may do so as well. For what TOPS-20 does with uncontrolled regular messages it is alright to substitute the datagram service for uncontrolled regular messages, but since there will be no period of overlap between the two I'm concerned about flag days. I would like to lobby for the new datagram service to be accessed by using a subtype 3 regular message. Incidentally, I am wondering whether or not it would be a good idea to always use datagrams for TCP/IP packets. Perhaps this would increase performance on the network if 1822 was spared the overhead of reliable delivery? ------- 19-Mar-86 00:53:41-PST,4745;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 00:53:18-PST Date: Wed 19 Mar 86 03:46:26-EST From: Ken Rossman Subject: Re: DEC20<->VAX DECnet: HELP!!! To: TOPS-20@SU-SCORE.ARPA cc: sa.Dev@CU20B.COLUMBIA.EDU In-Reply-To: <12188453642.15.SY.KEN@CU20B.COLUMBIA.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12191888985.21.SY.KEN@CU20B.COLUMBIA.EDU> Many thanks to those who contributed suggestions on the VAX <-> 20 DECnet connection problem we've been having here over the past couple of months. Unfortunately, none of the suggestions worked. We tried changing the verification password parameters around in various ways, but to no avail, and there is no SET CIRCUIT DMC-0 ROUTING TYPE III command anymore on the VAX (if there ever was one). I have decoded packets a bit further, and I find that we are not even getting to the router verification packet point in the protocol (which pretty well eliminates the theory of III/IV router verification passwords anyway). There are only two data packets thrown out (one from each system), then about 10 seconds of silence, followed by DDCMP resynch coming from the VAX (never from the DN20). Neither data packet got ACKed, as far as I can see from the first sample. The data packets are router layer init packets. The data scope sample I have in front of me shows a 10 byte router init packet coming from the DN20, only some of which I can decode (I don't have proper documentation), and a 12 byte router init packet coming from the VAX. The VAX packet I have decoded, and I know it to be a Phase IV format packet (which the DN20 should ignore, since it will see a node number that is far too large, given that the area field contains a 1). Why the VAX does not read the III router init from the DN20 and downshift into III emulation I don't know. Both sides seem to just time out and restart (though why it's only about 10 seconds I don't know -- I don't see any timer values set to 10 secs). I have compared all of the packets I can from this link to a DN20-VAX link that is working properly, and except for node numbers, they are pretty much identical. That is, packets up to the router init are identical. The working link sequence seems to be: DN20 VAX ------------- START ; DN20 throws out a START START ; VAX throws out a START STACK ; DN20 sends START ACK ACK ; VAX sends STACK ACK DATA ; DN20 sends Phase III router init ACK ; VAX ACKs router init packet DATA ; VAX sends Phase III router init ; (VAX now in Phase III mode) ACK ; Again VAX ACKs 20 router init (???) ACK ; DN20 ACKs VAX router init DATA ; DN20 sends router verification, complete ; with "DECNET20" password. ACK ; VAX ACKs router verification packet DATA ; VAX sends HELLO/TEST packet : ; (127 byte test packet, all 252(8) bytes) : From here on in, we get into normal traffic patterns, and the nodes have signed on to each other. A few more HELLO/TEST packets are sent from the VAX, and ACKed by the DN20. The bad link looks like this: DN20 VAX ------------- START ; DN20 throws out a START START ; VAX throws out a START STACK ; DN20 sends START ACK ACK ; VAX sends STACK ACK DATA ; DN20 sends Phase III router init DATA ; VAX sends Phase IV router init (!!!), ; though this could just have been timing. The VAX sometimes ACKs the DN20's III router init, sometimes it doesn't. But it then gets quiet here for 10 seconds or so, and DDCMP starts over with the START, START, STACK, ACK sequence again. The VAX is always the one to throw off the first START msg after the 10 second dead time, and this sometimes after it has ACKed the DN20 router init packet, but has NOT sent its own router init packet. Incidentally, we swapped the circuit on the VAX so that we were using a DMF32 for part of the time, and the results were pretty much the same, except that I NEVER see a VAX router init packet thrown out when we used the DMF. The VAX does ACK the DN20's III router init packet when it sees it, but is then silent for awhile, and throws out the START message again. The only other thing I'd like to know more about at this point is the exact meaning of the two flag bits in some of these packets (the SELECT flag, and the QSYNCH flag). Sometimes these flags are set, other times they are not. Might this have anything to do with the current situation? Again, any information concerning possible problems would be very much appreciated! I've run out of things to try. /Ken ------- 19-Mar-86 04:29:48-PST,2878;000000000000 Return-Path: Received: from bbnccs.arpa by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 04:29:24-PST Date: Wed, 19 Mar 86 6:50:40 EST From: Andrew Malis Subject: Re: major change to 1822 (IMP) software In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST To: Mark Crispin Cc: TOPS-20@su-score.arpa, TCP-IP@sri-nic.arpa, malis@bbnccs.arpa Mark, Boy, I wrote the thing, and I didn't even receive the distribution notice! I wonder how many others I've missed ... I initially (some time ago) resisted some of terminology changes that you mentioned, but was overruled by many others that prefer the new terminology (including DCA, by the way). Some of these changes go back several years now in BBN and DCA literature, but are just making their way out to the rest of the world. By the way, the software that runs on the PSN is referred to as PSN Release x, with the End-to-End being one module of the PSN. Other modules include, for example, Store-and-Forward, Routing, and X.25 L3. VDHs, as you mention, are mostly extinct animals these days. The story on uncontrolled messages is a bit more complicated. Up to now, the EE's flow control has been (in the absence of subnet congestion control) the only governor of the amount of traffic a host can submit to the network. When you take that away by using uncontrolled messages, you are really introducing the possibility of debilitating congestion on the network. As a result, the use of uncontrolled messages has been, shall we say, controlled (administratively). There are, I believe, no hosts on the MILNET that have permission to send them, and only a small number on the ARPANET (mostly associated with packet speech). I know of no TOPS-20s that are currently allowed to submit uncontrolled messages. As an example, neither of the hosts at SUMEX are enabled, and at the ISI complex, the only enabled host is ISI-SPEECH11 (I just checked these). After we decided to upgrade the uncontrolled messages into the new datagram service, we also found that because of scheduling constraints, we wouldn't be able to include it in PSN 7.0 (the first new EE release). Even if we had, its use would (due to the absence of congestion control) have to be limited to the same small set of hosts. The good news is that subnet congestion control is actively under development, and both it and datagrams are scheduled for PSN Release 8.0. At that time, we can experiment (on the ARPANET first, of course) with always using datagrams for TCP/IP traffic. That was one of the reasons why we decided to upgrade to the new datagrams - the old uncontrolled messages just weren't useful enough to support this. By the way - the datagrams, when included, will be accessed by good old subtype 3. Regards, Andy 19-Mar-86 04:45:29-PST,1181;000000000000 Return-Path: Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 04:45:21-PST Date: 19 Mar 1986 04:28-PST Sender: CERF@USC-ISI.ARPA Subject: Re: major change to 1822 (IMP) software From: CERF@USC-ISI.ARPA To: MRC%PANDA@SUMEX-AIM.ARPA Cc: TOPS-20@SU-SCORE.ARPA, TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]19-Mar-86 04:28:08.CERF> In-Reply-To: <12191827659.11.MRC@PANDA> Mark, I would be very hesitant to put a lot of traffic on "uncontrolled" datagrams. The term "uncontrolled" meant just that. No flow/congestion control; except to discard a type 3 datagram if you had nothing else to do with it. When we ran packetized voice tests on the ARPANET using the current type 3 datagrams, we interfered pretty severely with network performance. I don't know how far the new end/end would go towards making this any better. Andy Malis at BBN would be a good person to ask. My assumption for the moment is that they have reduced the need for RFNM-like behavior (not to zero, you still need acks on an end/end basis, but not one per packet) but this does not put control onto the type 3 packets, as far as I know. Vint 19-Mar-86 17:53:17-PST,3307;000000000000 Return-Path: Received: from bbnccs.arpa by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 17:52:34-PST Date: Wed, 19 Mar 86 20:51:37 EST From: Andrew Malis Subject: Re: major change to 1822 (IMP) software In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST To: Mark Crispin Cc: TOPS-20@su-score.arpa, TCP-IP@sri-nic.arpa, malis@bbnccs.arpa My apologies if any of you receive this twice - as far as I can tell, my original message went into a black hole. Andy ------- Date: Wed, 19 Mar 86 6:50:40 EST From: Andrew Malis Subject: Re: major change to 1822 (IMP) software In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST To: Mark Crispin Cc: TOPS-20@su-score.arpa, TCP-IP@sri-nic.arpa, malis@bbnccs.arpa Mark, Boy, I wrote the thing, and I didn't even receive the distribution notice! I wonder how many others I've missed ... I initially (some time ago) resisted some of terminology changes that you mentioned, but was overruled by many others that prefer the new terminology (including DCA, by the way). Some of these changes go back several years now in BBN and DCA literature, but are just making their way out to the rest of the world. By the way, the software that runs on the PSN is referred to as PSN Release x, with the End-to-End being one module of the PSN. Other modules include, for example, Store-and-Forward, Routing, and X.25 L3. VDHs, as you mention, are mostly extinct animals these days. The story on uncontrolled messages is a bit more complicated. Up to now, the EE's flow control has been (in the absence of subnet congestion control) the only governor of the amount of traffic a host can submit to the network. When you take that away by using uncontrolled messages, you are really introducing the possibility of debilitating congestion on the network. As a result, the use of uncontrolled messages has been, shall we say, controlled (administratively). There are, I believe, no hosts on the MILNET that have permission to send them, and only a small number on the ARPANET (mostly associated with packet speech). I know of no TOPS-20s that are currently allowed to submit uncontrolled messages. As an example, neither of the hosts at SUMEX are enabled, and at the ISI complex, the only enabled host is ISI-SPEECH11 (I just checked these). After we decided to upgrade the uncontrolled messages into the new datagram service, we also found that because of scheduling constraints, we wouldn't be able to include it in PSN 7.0 (the first new EE release). Even if we had, its use would (due to the absence of congestion control) have to be limited to the same small set of hosts. The good news is that subnet congestion control is actively under development, and both it and datagrams are scheduled for PSN Release 8.0. At that time, we can experiment (on the ARPANET first, of course) with always using datagrams for TCP/IP traffic. That was one of the reasons why we decided to upgrade to the new datagrams - the old uncontrolled messages just weren't useful enough to support this. By the way - the datagrams, when included, will be accessed by good old subtype 3. Regards, Andy 20-Mar-86 15:26:03-PST,7571;000000000000 Return-Path: Received: from Cs (CS.UCL.AC.UK.#Internet) by SU-SCORE.ARPA with TCP; Thu 20 Mar 86 15:24:26-PST Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a004147; 20 Mar 86 20:23 GMT Via: DCT; by DUNDEE on Thursday, 20-Mar-86 20:24:23-GMT Date: Thu 20 Mar 86 20:22:38-GMT From: Alan Greig Subject: [Alan Greig : KA10's never die....] To: tops-20@su-score.arpa Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan%dundee-tech.ac.uk@cs.ucl.ac.uk Never seemed to arrive before so here goes again. --------------- Mail-From: CCD-ARG created at 28-Feb-86 19:15:15 Date: Fri 28 Feb 86 19:15:15-GMT From: Alan Greig Subject: KA10's never die.... To: tops-20@ARPA.SU-SCORE cc: alan@DCT Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan@DCT I found the following message in the Speakers Corner conference at York University in England. It originated in the Swedish COM system and found it's way over Janet into York COM (For those who don't know, COM is the Electronic conferencing system thats an optional part of the Simula system). I'm sure some others on the tops20 group might find it interesting. (Text 16633) 86-02-23 01.54 Per Lindberg QZ @ QZCOM (Per Lindberg QZ) (severa l receivers) Subject: Subject: The saga of KATIA ------------------------------------------------------------ %Original date: 21 Feb 86 23:46 +0100. TF: PST010.COM[3,5] %FROM: Per_Lindberg_QZ@ODEN Have I told you about the large computer now installed and running at Stacken, the computer club at the KTH (the Royal Institute of Technology) in Stockholm? No? Well, then... A few years ago, DEC (Digital Equipment Corp) in Sweden had a sort of "white elephant" on their hands, a DECsystem-10 (the same type you are running COM on), but a very old model with a KA10 CPU, single transistor logic boards and good old core memory. Big as hell, lots of blinkenlights, and with an appetite for kiloAmpere that would ruin any computer hobbyist. The customer that had leased the thing did not want it any more, and DEC did not even try to find another. But instead of scrapping it, they gave it to us in Stacken. Sure, we could take care of it, and even payed the transport (about 3000 SEK). But where would we house such a beast? Fortunately, KTH promised us a place to run it. For two years it was kept in a garage at KTH while we lobbyed the KTH administration to give us that place. (There is a constant shortage of space at KTH, alas). It was not after a new guy in Stacken, Peter Lothberg, had renewed the efforts by pestering the Principal himself for a while that we finally got the promised room to install it in. Then around last spring (1985) the work started. During the summer of 1985 the place was refitted with a real raised computer room floor, electrical power, terminal lines, a cooling machine with outdoor condensors, and everything else needed to make the place a full-fledged computer center. Meanwhile, our DEC-10, now named "KATIA" (a pun on "Nadja" which is the DEC-2020 at KTH and "KA-TIA", where "tia" is 10:er in swedish), was temporary installed and tested at CCCC (Colossal Cave Computer Center), Peter:s playroom where he already has a DECsystem-10 going. That DEC-10, (named KICKI) was used for testing and debuggning Katia. Without it, it might still be nonfunctional. When the room was finished, Katia was moved in and re-debugged. (You don't move such a beast without dislocating at least a few wires). And then, one night last autumn, the champagne bottle, which had been bought for just this reason, was opened. Katia was installed, and up and running! According to the tradition, which begun with the installing of Kicki a year eariler, the bottle is uncorked when you can give the command MAKE LOVE on the console, which makes a file named "LOVE" with the venerable TECO editor, and get the resonse "NOT WAR?" on the console. (This is a "hack" in TECO, installed for obvious reasons long ago, probably way back in the sixties). Then on the 23rd of October 1985 Katia was officially inaugurated as Stacken was throwing its first Big Party in its 7-year history, where participants could awe at the extremely rare sight of over 100 computer hobbyists, nerds and hackers in (get this!) ties and jackets (some of them even pinstriped!) The members and a large number of specially invited dignitaries met at a splendid Dinner With Everything at the KTH student corps house. Speeches were held, glasses were raised, jokes were cracked and the atmosphere was high. After the coffee everyone walked over to the room where Katia stood happily humming since a few days, where the Principal inaugurated Katia by cutting a punched tape spanned across the door. Such a project can't be done without two things: many highly skilled enthusiasts and a lot of money. Fortunately, Stacken had both. The latter came from selling copies of our EMACS workalike editor "AMIS" for about 500 USD a copy to other installations of DEC-10s, VAXen, PR1MEs and Norsk Data. AMIS was our first success back in 1980, when me and six others got fed up with not having a really good editor. (I'm using it right now for writing this text). So AMIS, aside from preventing us from going berserk, gave us the means to install Katia. By the way, we can use more hardware. All sorts of donations are appreciated. Especially disks, but we'll take anything that could possibly be connected to a DECsystem-10. Also terminals, cooling machines... anything. Send inquiries to me, or better still, to: Datorforeningen Stacken, c/o NADA, KTH, S-10044 Stockholm, SWEDEN. Katia is a neat hobby computer. Those kids and their daddys with CBM-64:s can go suck on a BASIC manual. The DEC-10 is a REAL COMPUTER, 36 bit words, real tape, disks, DECtapes and a glorious collection of blinking lights. It runs the TOPS-10 timesharing operating system, one of the finest and most user-friendly OS ever made (it beats both VMS and UNIX singlehandedly), rivalled only by TOPS-20. And the awesome sight of Katia:s 12 large blue cabinets with the blinking lights, its designed front panel and the rest of the hardware filling the room stirs the heart. Katia looks like a computer should! This machine and its worshippers are not unlike the phenomenon of people lovingly restoring old steam engines and cars. But while Katia definitely is a veteran computer, it's still modern. It outperforms a medium-sized VAX and has a much neater instruction set. (Long live the DECsystem-10 designers!) And there are gigabytes upon gigabytes with highly sophisticated software which we can run on it. Our only problem so far is what to do with all those unused CPU cycles. Anyone wants a million prime numbers? (Text 16633)------------------------------ [Actually the MAKE LOVE trap is in COMPIL and in the old days when tops20 exec still had the compil interface in it, you could get the not war response on tops20 as well. Although this code has been conditionalled out for some time it was only with tops20 version 5 that it went alltogether. A sad day !! To the maintainers of PCL : If goto hell on the dec10 responds with get stuffed can't we have something like that or better under tops20 ? ---Alan] ------- ------- 20-Mar-86 16:19:36-PST,376;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Mar 86 16:19:30-PST Date: Thu 20 Mar 86 16:21:43-PST From: Frank M. Fujimoto Subject: TTYINI To: su-tops-20@SU-SCORE.ARPA I've fixed up TTYINI to know about TCP Tips. Sources are on Sierra in PS:TTYINI.MAC -frank ------- 22-Mar-86 00:50:05-PST,2162;000000000001 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sat 22 Mar 86 00:49:54-PST Date: Sat, 22 Mar 1986 22:21 EST Message-ID: From: Rob Austein To: Vince.Fuller@C.CS.CMU.EDU Cc: sra@XX.LCS.MIT.EDU, tops-20@SU-SCORE.ARPA Subject: Domain service query In-reply-to: Msg of 17 Mar 1986 19:01-EST from Vince.Fuller@C.CS.CMU.EDU Vince, I don't know of any reason why DSV should suddenly stop believing in *.SEI.CMU.EDU. You might check to see if you did something that caused it to use some previously untested piece of code (like adding enough RRs that your database is now using both sections of the database rather than just the low section). You might want to try copying the V5 stuff from XX and seeing if it works any better (XX:*.*). In the version 5 code DSV comes in two flavors, NUFORK and NUMAIN, depending on whether or not you are running it under a JEEVES. NUMAIN is the one you probably want, I'm not certain it has ever been tested. I know NUFORK works (with a two section database) because XX is one of the nameservers for LCS.MIT.EDU. Paul Mockapetris claims to have a new and wonderful version of the nameserver with large numbers of bugs fixed (I believe him, but it has been long enough since I talked to him about it that I no longer remember what the bugs were). Unfortunately, he has the sources protected against anybody reading them (his way of enforcing a write lock), so this doesn't do you any immediate good. The version I have on XX is from around the end of January, just before Paul started the massive rewrite. If you do copy the sources from XX, be warned that the MIT version and the ISI version have diverged slightly (ISI has the new nameserver code, MIT has an improved version of GTDOM%). Eventually either Paul or I will do a merge (and merge in the changes certain brave souls are making to get the monitor code to run under 6.1), but for now I would not advise putting any more work into this stuff than you absolutely have to in order to survive. --Rob 24-Mar-86 07:12:59-PST,938;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Mon 24 Mar 86 07:12:49-PST Received: from (MAILER)UDCVM.BITNET by WISCVM.WISC.EDU on 03/24/86 at 09:10:29 CST Return-path: MHICKEY@UDCVM.BITNET Received: by UDCVM (Mailer X1.23) id 1540; Mon, 24 Mar 86 10:11:39 EST Date: Mon, 24 Mar 1986 10:01 EST From: Mike Hickey Subject: Gosling Emacs info To: , , Greetings! I've recently unearthed sources for Gosling Emacs and am frantically searching for the documentation and associated MLISP files. Any help would be greatly appreciated as I have three ports to do: DEC-2065/TOPS, VAX 8600/VMS, and IBM-PC/MS-DOS. For those who are interested I will summarize to the appopriate nets. Thanks in advance, /Mike 24-Mar-86 15:04:58-PST,1127;000000000000 Return-Path: Received: from hydra.ARPA (RIACS-HYDRA.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Mon 24 Mar 86 15:04:41-PST From: Barry Leiner Message-Id: <8603242302.AA20250@hydra.ARPA> Received: by hydra.ARPA (4.12/4.01) Mon, 24 Mar 86 15:02:12 pst Date: 24 Mar 1986 1502-PST (Monday) To: Mark Crispin Cc: TOPS-20@SU-SCORE.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: major change to 1822 (IMP) software In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST. <12191827659.11.MRC@PANDA> Mark, You might be interested to know that I have been lobbying with the DDN and BBN for several years now to run an experiment using IP over ARpanet uncontrolled packets (subtype 3). My reasoning was that, since some statistics I saw showed that something like half the packets were arpanet acknowledgments (RFNMs), it would seem that a significant amount of traffic loading on the net might be eliminated and we might actually get better performance. However, thus far that experiment has not been performed. Barry ---------- 24-Mar-86 22:12:47-PST,1280;000000000000 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Mon 24 Mar 86 22:12:35-PST Date: 20 Mar 86 04:29:46 EST From: Charles Hedrick Subject: more TCP oddities To: tops-20@SU-SCORE.ARPA Message-ID: <12192159018.17.HEDRICK@RED.RUTGERS.EDU> It is interesting to see the problems people are having writing Unix-compatible servers. I just tried to write a user process that would talk to rexecd on a Unix machine, and had an even worse problem. I want to ship off - user information - a command to execute - a bunch of text which will be primary input and then get back a bunch of stuff which will be primary output. If I am reading the spec correctly, Unix expects to see an end of file at the end of the primary input. If I am reading the monitor code correctly, there is no way to generate an end of file on output without closing the connection entirely. There is a TCOPR call that says "send a FIN". It turns out to do a close. I looked at the code in TCPTCP, and it looks to me like the only way of telling TCPTCP to send a FIN is to clear the bit saying that the connection is open. If I understand what is going on, this seems to be a fairly major omission. ------- 25-Mar-86 15:09:36-PST,779;000000000000 Return-Path: Received: from A.BBN.COM by SU-SCORE.ARPA with TCP; Tue 25 Mar 86 15:08:36-PST Date: 25 Mar 1986 10:04-EST Sender: CLYNN@A.BBN.COM Subject: Re: more TCP oddities From: CLYNN@A.BBN.COM To: HEDRICK@RED.RUTGERS.EDU Cc: tops-20@SU-SCORE.ARPA Cc: CLynn@A.BBN.COM Message-ID: <[A.BBN.COM]25-Mar-86 10:04:33.CLYNN> In-Reply-To: <12192159018.17.HEDRICK@RED.RUTGERS.EDU> Have you tried it? The code in TCPJFN does indeed do a "CLOSE%" (without setting the TCP%WT bit); CLOSE% (in TCPBBN) sends a FIN (as soon as flow control permits), returning without waiting for the remote end to send its FIN (since the TCP%WT bit was not set). You should then be able to read from the JFN until the remote end sends its FIN (causing an EOF error). 26-Mar-86 04:53:59-PST,995;000000000000 Mail-From: BILLW created at 26-Mar-86 04:53:54 Date: Wed 26 Mar 86 04:53:54-PST From: William "Chops" Westfield Subject: Score is running a domain resolver... To: nethax@SU-GREGORIO.ARPA, su-tops-20@SU-SCORE.ARPA cc: mkl@SRI-NIC.ARPA Message-ID: <12193769044.10.BILLW@SU-SCORE.ARPA> (assuming it hasn't crashed since I sent this message) You can play with the tops20 resolver and stuff using DOMAIN:DQUERY for general querys, or DOMAIN:DADDR to just look up host addresses using the domain code instead of the host table code. Apparently, you can't test it on the stanford domain because that isn't officially allocated, or some such. Ill try to look into this to see if the initial database can be tweaked to think that stanford.edu does exist after all... Gee, Im sure glad we have domains - we can get rid of that big, 116 page host table and replace it with a domain database that's only 1024 pages long... (sigh, :-( ? :-) BillW ------- 26-Mar-86 10:50:13-PST,697;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 26 Mar 86 10:49:36-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 26 Mar 86 10:46:50-PST Date: Wed 26 Mar 86 10:33:33-PST From: Mark Crispin Subject: LN03's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12193830877.7.MRC@PANDA> I'd like to know what people think about DEC LN03 laser printers. At $3500 with a possible 12% discount that seems like a very attractive price. The question is, are they merely "inexpensive" or are they also "cheap"? ------- 27-Mar-86 11:28:12-PST,379;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 27 Mar 86 11:27:54-PST Date: Thu 27 Mar 86 13:26:15-CST From: AI.HASSAN@MCC.ARPA Subject: Eliza To: tops-20@SU-SCORE.ARPA cc: ailist@SRI-AI.ARPA Where could I run Eliza (Weizenbaum's program) or get a copy of the source code? Send reply to hassan@mcc.arpa---Thanks. H. ------- 27-Mar-86 15:56:09-PST,734;000000000000 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Thu 27 Mar 86 15:55:49-PST Date: 25 Mar 86 11:28:30 EST From: Charles Hedrick Subject: Re: more TCP oddities To: CLYNN@BBNA.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: <[A.BBN.COM]25-Mar-86 10:04:33.CLYNN> Message-ID: <12193545966.38.HEDRICK@RED.RUTGERS.EDU> Yes, I tried it. I got an immediate end of fine on input. I looked throught the code in the monitor, and more or less convinced myself that that form of CLOSE clears the UOP bit, thus making it impossible to read from the channel. Since both you and BillW report being able to read after doing the TCOPR, I will look again. ------- 27-Mar-86 23:54:11-PST,1850;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 27 Mar 86 23:53:59-PST Date: Fri 28 Mar 86 02:53:08-EST From: Ken Rossman Subject: Firing up DECnet on an NI To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12194238579.10.SY.KEN@CU20B.COLUMBIA.EDU> We are experiencing problems getting DECnet service to work on a newly installed NI20. Previously, this DEC-20 talked to the rest of the network via a CI20. Once the NI was installed, however, I can only get an "Operation Failure" error message when I attempt to "NCP>SET CIRCUIT NI-0-0 STATE ON". I believe I am able to verify that the actual NI hardware is working because we also run TCP/IP service on this machine, and using IPHOST I can turn off TCP/IP service over the CI, and can still connect to hosts on the local Ethernet. I don't have much else to go on. I have a couple of entries from SPEAR that claim the "component is in the wrong state", though I don't understand how this could be. SHOW CIRCUIT NI-0-0 STATUS gives me some info about something called a designated router. The problem system lists itself in this field, while other systems which have NI's list other machines as designated routers. One other point: There is one other machine which serves as a CI/NI gateway, and has been serving in this capacity for awhile now. Could this machine somehow be interfering in the NI startup on this new addition to the NI/CI network? This new machine will be the second machine to have both a CI and an NI with DECnet service enabled on both circuits. Do I have to include special NCP commands to limit one of the two machines as a gateway or something? Any other ideas? /Ken ------- 28-Mar-86 01:07:10-PST,826;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 01:06:57-PST Date: Fri 28 Mar 86 04:05:58-EST From: Ken Rossman Subject: 8 bit VMS to TOPS-20 file transfers To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12194251837.10.SY.KEN@CU20B.COLUMBIA.EDU> I think this must have been batted around a few times in the past, but since I don't remember what the answer was, I'll ask again: Is there any way to do a bare 8-bit file transfer between VMS 4.x and TOPS-20 V6.1? TOPS-20 NFT has no such option that I can find, and VMS COPY bombs out with some obscure RMS error message (but then, all VMS RMS error messages are obscure to me). /Ken ------- 28-Mar-86 07:07:25-PST,1494;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 07:07:16-PST Date: 28 Mar 1986 1003-EST From: Tom Blinn To: Mark Crispin cc: tops-20@su-score Subject: Re: LN03's Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12194316952.14.275.7772 at MARLBORO.DEC.COM> References: Message from Mark Crispin of 26-Mar-86 1420-EST In-reply-to: <12193830877.7.MRC@PANDA> I'm probably somewhat biased, so I'll be interested to see what other feedback you get. My impression of the LN03 is that, while it is inexpensive, it is not a "cheap" printer. It has a number of good features when compared to other printers in its price class. Some of these are in areas such as the size of the paper trays (less "out of paper" service), and the way the paper gets stacked in the output hopper (proper collating sequence). I'm told that a number of the other printers in its class lack some of these features; I can't say from personal knowledge, as we (naturally) don't buy the others. The LN03 also has very good print quality, and while there isn't much software on the -10s and -20s to support it (although you CAN hang it off a regular terminal port), it is quite well supported on the VAX by VMS. (You can even hang it off a DECserver-100 terminal port and share it from several VAXes in a cluster.) Regards, Tom -------- 28-Mar-86 07:10:26-PST,859;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 07:10:16-PST Date: 28 Mar 1986 1006-EST From: Tom Blinn To: Ken Rossman cc: tops-20@su-score Subject: Re: Firing up DECnet on an NI Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12194317493.14.275.10543 at MARLBORO.DEC.COM> References: Message from Ken Rossman of 28-Mar-86 0300-EST In-reply-to: <12194238579.10.SY.KEN@CU20B.COLUMBIA.EDU> You don't have your machine (the problem child) defined as an end node, do you? If it is a non-routing end node, you can only have one active circuit to the outside world. I realize you probably already realize this, but I figured that it never hurts to double-check the obvious. Tom -------- 28-Mar-86 07:25:47-PST,2289;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 07:25:37-PST Date: 28 Mar 1986 1022-EST From: Tom Blinn To: Ken Rossman cc: tops-20@su-score Subject: Re: 8 bit VMS to TOPS-20 file transfers Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12194320296.14.275.20054 at MARLBORO.DEC.COM> References: Message from Ken Rossman of 28-Mar-86 0412-EST In-reply-to: <12194251837.10.SY.KEN@CU20B.COLUMBIA.EDU> You have two choices: 1) Use the DAP protocol yourself to talk to FAL on the VAX; NFT uses DAP, but NFT imposes a conversion from the 8-bit bytes that the VAX (and the TOPS-20 system) exchange over the DECnet link to 7-bit bytes on the TOPS-20 disk. (The default exchange mode is /ASCII. You could try using /IMAGE on the destination file, but I'm not sure you'd get anything useful.) 2) You could write your own software, using the routines in DIL to set up the link and pass the messages back and forth across the net (or you can roll your own in MACRO). The "Network File Transfer Guide" states that "Binary files cannot be copied from a VAX/VMS or RSX system to a TOPS-20 system;" and then goes on to talk about using the /MACY11 switch to move MACY11 format object files to VMS or RSX. This guide also documents the /FIXED and /VARIABLE switch on the NFT copy commands. There are certain styles of VMS files that you can't readily copy from the VAX system to TOPS-20, because the file attributes on VMS are not compatible with the way TOPS-20 wants to receive the file (which is, by default, as variable-length ASCII text). If the file is really text (e.g., RUNOFF or DSR output), you can use TECO to convert the file to a format that can be "pushed" from the VAX to TOPS-20; just read the file in via EDIT/TECO, then at the "*" prompt type "EX" and two escapes. There's also a way to change the file attributes with CONVERT/FDL, but it's more trouble, and TECO is faster. If the file is not text, DIL may be your best bet. DIU is supposed to be on its way, but I don't know for sure when it will be shipping. Hope this helps! Tom -------- 29-Mar-86 22:30:08-PST,801;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 29 Mar 86 22:30:06-PST Date: Sat 29 Mar 86 22:30:34-PST From: Mark Crispin Subject: ENVIRONMENT program To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12194747836.14.CRISPIN@SUMEX-AIM.ARPA> I got a new version of the ENVIRONMENT program from DEC. The new version is on SYS: at Score and Epic, at SUMEX, and at LOTS. It comprehends 2065's, works on 2020's, and even gives a halfway reasonable output on an SC-30M (although it doesn't find any memory; the old one did but the information was wrong). I'll try to get a copy of the source. ------- 30-Mar-86 01:32:33-PST,735;000000000000 Mail-From: BILLW created at 30-Mar-86 01:32:26 Date: Sun 30 Mar 86 01:32:25-PST From: William "Chops" Westfield Subject: Score now running new mail software. To: su-bboards@SU-SCORE.ARPA, su-tops-20@SU-SCORE.ARPA, System@SU-SCORE.ARPA Message-ID: <12194780942.9.BILLW@SU-SCORE.ARPA> Score is currently running a new version of the mail software that fully supports domains. The only change that should be visible to uses is that they should be able to reply to messages from obscure places (eg vangogh.Berkeley.EDU) that used to cause an error. Report any strange mailer behavior to me (If mail REALLY isn't working, drop by MJH030 in person - the phone isn't working either!) BillW ------- 30-Mar-86 16:32:08-PST,637;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Mar 86 16:31:54-PST Date: Sun 30 Mar 86 16:31:28-PST From: Stu Grossman Subject: Re: Firing up DECnet on an NI To: sy.Ken@CU20B.COLUMBIA.EDU cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Rossman " of Fri 28 Mar 86 08:38:46-PST Your NI probably has the wrong Ethernet address for use with DECnet. To fix that, put the line "ETHERNET 0 DECNET" into your 6-1-CONFIG.CMD file. This line must come after the NODE command in the same file. Stu ------- 30-Mar-86 16:35:24-PST,617;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Mar 86 16:35:11-PST Date: Sun 30 Mar 86 16:34:46-PST From: Stu Grossman Subject: Re: Firing up DECnet on an NI To: BLINN@MARLBORO.DEC.COM cc: sy.Ken@CU20B.COLUMBIA.EDU, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tom Blinn " of Fri 28 Mar 86 07:06:00-PST His problem is has nothing to do with end node service. 6.1 only supports end node service on the NI, so therefore it wasn't an end node while it was talking DECnet through the CI. ------- 30-Mar-86 19:58:25-PST,2524;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Mar 86 19:58:14-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 30 Mar 86 19:57:55-PST Date: Sun 30 Mar 86 19:49:38-PST From: Mark Crispin Subject: GNU Emacs for TOPS-20 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12194980684.8.MRC@PANDA> I've had some preliminary discussion with Richard Stallman (the principal developer of TOPS-20 EMACS) about the possibility of porting his "GNU Emacs" to TOPS-20. For those of you who haven't been following these things, Stallman is working on a public-domain Unix clone called GNU, the intent being to have a free version of the Unix environment available. He already has a version of Emacs written in C that runs under Unix called GNU Emacs. Stallman feels that the project of porting GNU Emacs to TOPS-20 is feasible albeit unexciting; he cautions that the result will probably be larger and slower than the extant TOPS-20 EMACS. On the other hand, the prospect of having a common Emacs editor on both TOPS-20 and Unix excites me, and even more so the prospect of having an Emacs that runs in extended addressing! I for one am sick and tired of running out of space for new buffers/files in TOPS-20 EMACS on a daily basis... I also brought up the issue of the need for a reasonable means to use Emacs when XON/XOFF flow control cannot be avoided. Stallman appears willing to take on this project provided there is a sufficient infusion of funds to his GNU development group (I think it's called the Free Software Foundation). I may be willing to put in some of my own money for this project, although if it's only going to run in extended addressing it won't be of much use to me on my 2020. But you winners with KL's may benefit by this, and especially by having a common editor. In any case, no commitments have been made by anyone in this. I would like to hear if there is any interest in helping to fund this worthy project. I don't know what kind of funding level Stallman is thinking of, but it can't be that much, especially when spread over a community of TOPS-20 sites. Apparently some amount of work would have to be done to get it running on a PDP-10 since like many C programs it assumes that pointers, addresses, and integers can be mixed freely. ------- 31-Mar-86 15:32:31-PST,587;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 31 Mar 86 15:31:45-PST Date: Mon 31 Mar 86 15:30:21-PST From: LARSON@SRI-KL.ARPA Subject: tcp bug fix To: tops-20@SU-SCORE.ARPA Is anyone (other than the NIC) running the bug fix from Charlie Lynn that Ken Harrenstien described in his message of August 7, 1985 ? The problem was duplicate data being received on a TCP connection, and had been blamed on 4.2BSD. Will this (or equivalent) be in DEC's version? (It would be nice to have it installed and tested.) Alan ------- 3-Apr-86 11:28:29-PST,588;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Thu 3 Apr 86 11:28:16-PST Date: Thu 3 Apr 86 10:34:59-CST From: Donald Blais Subject: ftp loops for bad host in command line To: tops-20@SU-SCORE.ARPA Message-ID: <12195906443.43.CC.BLAIS@R20.UTEXAS.EDU> @ftp other ?No such host - No string for that Host number - "other" ?H^\^A^Cm ?H^\^A^Cm ?H^\^A^Cm . . . FTP gets into a loop if a bad host is given on the command line. Has anyone encountered this? Anyone have a fix to prevent it? ------- 3-Apr-86 12:08:51-PST,715;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Thu 3 Apr 86 12:08:25-PST Received: ID ; Thu 3 Apr 86 14:56:41-EST Date: Thu 3 Apr 86 14:56:40-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: ftp loops for bad host in command line To: CC.BLAIS@R20.UTEXAS.EDU cc: tops-20@SU-SCORE.ARPA In-Reply-To: <12195906443.43.CC.BLAIS@R20.UTEXAS.EDU> Message-ID: <12195943159.5.VAF@C.CS.CMU.EDU> What version of FTP do you have? I believe this bug was fixed some time ago in the version that I distribute from CMU (the RESCAN buffer was not being cleared early enough, so an error would cause the EXEC to run FTP again, ad nauseum). --Vince ------- 3-Apr-86 16:10:11-PST,734;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 3 Apr 86 16:09:55-PST Date: Thu 3 Apr 86 16:08:56-PST From: Kirk Lougheed Subject: Re: ftp loops for bad host in command line To: CC.BLAIS@R20.UTEXAS.EDU cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Donald Blais " of Thu 3 Apr 86 15:40:42-PST It looks like you're using an old version of the Stanford FTP. The problem doesn't happen at Stanford, so it looks like we've fixed the bug. The most recent sources can be found in PS: on Sierra. Since our IMP interface is down right now, you should try connecting to host 36.10.0.13. Kirk ------- 4-Apr-86 05:36:44-PST,3757;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 4 Apr 86 05:36:32-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 4 Apr 86 04:47:19-PST Date: Fri 4 Apr 86 03:26:25-PST From: Mark Crispin Subject: XON/XOFF madness To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12196112415.8.MRC@PANDA> Lately, I've given a fair amount of thought to the whole issue of XON/XOFF, terminals, TOPS-20, and EMACS. As you probably know, DEC believes that terminals should use XON/XOFF as flow control, while EMACS uses those ASCII characters as its CTRL/Q and CTRL/S commands. This has been traditionally a major stumbling block in using EMACS on many popular terminals and some packet-switched networks. Some models of VT1xx terminals (the VT125 and a VT100 with printer port among others) do not allow disabling automatic transmission of XOFF; vanilla VT100's don't work at all well at 9600 baud unless they can use XON/XOFF flow control. I've concluded that it's probably hopeless to fight DEC and the rest of the industry on this one; XON/XOFF flow control appears here to stay. I've also concluded that hacking EMACS is *not* the right approach. There are other applications -- TELNET for one -- which disable XON/XOFF flow control for their own purposes. You really want compatibility and that means allowing the user to send CTRL/Q and CTRL/S to his application program even though his terminal is XON/XOFF flow controlled. What I think is the right thing is a new TERMINAL command called TERMINAL [NO] XON-XOFF. When this command is given the terminal is *always* in TERMINAL PAUSE COMMAND mode; the setting of the pause-on-command bit is ignored. In TERMINAL XON-XOFF mode, the CTRL/\ character (034 octal) is redefined to be a command character. Two CTRL/\'s send a single CTRL/\ to the host. CTRL/\ S and CTRL/\ Q are equivalent to CTRL/S and CTRL/Q respectively, and are interpreted as such by the low-level TTY drivers but are *not* considered to be XOFF and XON. I have not decided on what other characters after CTRL/\ should do; perhaps they should be reserved for future expansion. Why CTRL/\? All of the alphabetic controls are commonly used functions in EMACS. CTRL/^ is hard or non-obvious to enter on many terminals and is used as the escape character by many versions of TELNET and Stanford Ethertips. CTRL/_ and CTRL/] are similarly difficult to enter on various terminals. CTRL/\ seems to be the only "simple to enter on most terminals" character that at the same time isn't used very much. I should emphasize that this would only happen if the user enters TERMINAL XON-XOFF mode; otherwise CTRL/\ would be an ordinary character as before. I imagine that with real smart terminals you can have function keys programmed to do this or even had the terminal's ROM reprogrammed to send those sequences when the appropriate key is pressed. I am planning on putting this in PANDA monitors fairly soon and offering it to Stanford for their monitors (their Tymnet and Uninet users would really appreciate it!). Ultimately, I'd like to get DEC to adopt it for version 7 or otherwise make it part of the TOPS-20 standard. I would however like to hear opinions first; I certainly can be swayed on the interface. I'm especially interested in hearing from PANDA and Stanford sites on this proposal; however I feel it is of utmost importance that we get some sort of concensus on how to implement this functionality so everybody is welcome to contribute. -- Mark -- ------- 4-Apr-86 09:05:53-PST,726;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Fri 4 Apr 86 09:05:21-PST Received: from (MAILER)UDCVM.BITNET by WISCVM.WISC.EDU on 04/04/86 at 11:02:31 CST Return-path: MHICKEY@UDCVM.BITNET Received: by UDCVM (Mailer X1.23) id 1878; Fri, 04 Apr 86 12:01:51 EST Date: Fri, 4 Apr 1986 11:58 EST From: Mike Hickey Subject: Looking for MARVIN::SCOTT To: , On the current Integration Tools Tape there is a file (EMACS030.MEM) mentioning MARVIN::SCOTT as a contact person. Anybody know where this node::user is located? /Mike 7-Apr-86 06:19:56-PST,1077;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 7 Apr 86 06:19:44-PST Date: Mon 7 Apr 86 09:19:08-EST From: Frank da Cruz Subject: LAT Slot Size and Kermit on DEC-10/20 To: TOPS-20@SU-SCORE.ARPA Message-ID: <12196930288.17.SY.FDC@CU20B.COLUMBIA.EDU> An answer to the LAT vs Kermit on DEC-10/20 question... --------------- Date: Wednesday, 26 Mar 1986 04:52:44-PST From: appellof%kl1026.DEC@decwrl.DEC.COM Subject: LAT slot size and KERMIT Frank, I am the LAT developer for TOPS-10 (same code as -20). I got your gripe about KERMIT file transfer to the -20. You are right. The parameter MXSLSI is the max slot size which may be sent to the host. It can be changed to a larger value with no problem. The only side effect may be that the link from the LATbox to the -20 gets blocked more often because there may not be enough space in the TTY input buffers on the -20 to accomodate a larger packet all at once. Carl Appellof -------- ------- 9-Apr-86 01:05:56-PST,1226;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Apr 86 01:05:43-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 9 Apr 86 01:04:48-PST Date: Wed 9 Apr 86 00:53:33-PST From: Mark Crispin Subject: printer madness To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12197395306.6.MRC@PANDA> I have a Centronics 737-1 parallel printer connected to my 2020 on one of the TTY ports via a serial/parallel interface. This is a popular 80-column microcomputer dot-matrix printer. However, it lacks mechanical tab and form feed. Right now, I have a LPTSPL talking to it via "START PRINTER 1/DEVICE:TTY7:". Tabs get ignored and form feeds are output as "^L" (I assume it is TOPS-20 that does that and not the printer). The results are less than fully satisfactory. Does anybody have a version of modern LPTSPL (I'm running Autopatch #12 Galaxy) that correct supports "TTY printers" including tab and formfeed simulation? I know it's been done zillions of times; the question is if it is still being done today? -- Mark -- ------- 9-Apr-86 02:14:28-PST,2327;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Apr 86 02:14:14-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 9 Apr 86 02:13:24-PST Date: Wed 9 Apr 86 01:19:11-PST From: Mark Crispin Subject: VT100 madness To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12197399971.6.MRC@PANDA> Folks - I've been considering getting a VT1XX-AC for my VT100. This is the printer port option; I already have a VT1XX-AB (advanced video option) installed. I have two reasons: first, the VT1XX-AC also gives you the microcode to support Delete Character, Delete Line, Insert Line, and Insert mode. Second, I have a parallel printer via a serial/parallel interface presently connected to a TTY port. It uses CTS for flow control, which the DZ11 doesn't respect (actually, neither does the VT1XX-AC, but I made a cable which shorts CTS to DSR and the VT1XX-AC does respect that). If it ends up that I really do need to use flow control on the printer (the 2K buffer on the serial/parallel interface helps a lot!) I may be forced to have it hang off of the VT100. The question I have is: according to the DEC documentation for the VT1XX-AC, you can't turn off Auto XON/XOFF on a VT100 with the VT1XX-AC installed. However, it is reputed that you can do so on a VT102, which from what I understand is a single board non-expandable functional equivalent of a VT100 with a VT1XX-AB and VT1XX-AC installed. Is it possible (hope hope) that the DEC documentation is lying? It certainly lies about this in several places in the VT125 manual -- some places say you can turn off Auto XON/XOFF, other places say you can't (the fact is that you can't). I'm hoping perhaps some bright person realized that the only time you *must* have Auto XON/XOFF is when the printer port is actually being used and decided to leave it as a user-settable option. After all, they seem to have come to this conclusion with the VT102. Does anybody know the facts of the matter? Is there an upgrade for the VT100 available other than the printer port which will provide the insert/delete functions? -- Mark -- ------- 9-Apr-86 05:34:56-PST,1499;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 9 Apr 86 05:34:43-PST Date: Wed 9 Apr 86 08:33:44-EST From: Thomas De Bellis Subject: Re: printer madness To: MRC%PANDA@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12197395306.6.MRC@PANDA> Message-ID: <12197446311.12.SY.SLOGIN@CU20B.COLUMBIA.EDU> Howdy MRC, We've been doing that kind of stuff for years and years (even since before 1980 when I got my hands into things). You handle the problem by properly conditioning the line in the SETUP code--this just means issuing a couple of extra jsyi to get Tops-20 to do wonderful things for you. Off the top of my head, our LPTSPL handles a TTY pretty much like a magnetic tape (they sort of look similiar to the Galactic eye). When it gets a setup request from Quasar, it jumps off some place and does some special monkeying around. We find out what the device is and if it is a terminal, then I issue a SFCOC% and some other terminal jsyi (like a STTYP%) goodies to make things nice. The idea is that the monitor then does all that translation stuff for you. I have versions of LPTSPL around that do this for 4.0, 5.0, 5.1, 6.0 and 6.1 monitors. It is about the simplest modification that I have ever had to make. Let me know know which version you want, send me two 2020 boxtops and I'll throw in a version of WPI Teco for free. -- Tom ------- 9-Apr-86 19:49:37-PST,1590;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Apr 86 19:49:33-PST Date: Wed 9 Apr 86 19:49:24-PST From: Kirk Lougheed Subject: LPTSPL and TCP Ethertips To: su-tops-20@SU-SCORE.ARPA cc: trewitt@SU-AMADEUS.ARPA I've modified LPTSPL so that it uses TCP instead of PUP to print files on Ethertip serial and parallel printers. I've also flushed all PUP support, including host to host spooling, from LPTSPL. Host to host spooling can be replaced by TCPSPL and LPD. This LPTSPL works on Ethertip versions 4.400 and greater. (Actually, I've only tried in on version 4.404 and greater, but I suspect it will work on version 4.400.) The method for setting up a TCP printer is quite similar to the PUP procedure. To print on line 16 (octal) of Tip-AELb (36.40.0.85), define a logical name like so: define TCPLPT: TCP:.4412000125-4014;TIMEOUT:60;CONNECTION:ACTIVE Note that the foreign host field is octal, yet the foreign port is decimal. The local host and port fields are not specified. Ethertip ports 4000+ are raw TCP streams, i.e., no telnet procotol processing is done. To start the printer, you give an OPR command like so: OPR>start printer 12 /device:tcplpt: If you need XON/XOFF, you must specify "flowcontrol" for that line in the Ethertip configuration file. "no exec" is another good thing to specify for a serial printer line; it prevents a user EXEC from ever being created. The new LPTSPL sources are PS:<5-1-GALAXY>LPTSPL.MAC.0. Kirk ------- 10-Apr-86 22:58:27-PST,591;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Apr 86 22:58:15-PST Date: Thu, 10 Apr 1986 22:40 MST Message-ID: From: "Frank J. Wancho" To: TOPS-20@SU-SCORE.ARPA Subject: Got an excess RH20? If you're a federal government agency with an unused RH20 you'd be willing to excess, please contact my office at 505-678-6257 (AV:258-, FTS: 898-). I'll get back to you immediately. We could use two here and our sister site could use another two. Thanks, Frank 13-Apr-86 00:10:50-PST,1601;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Apr 86 00:10:38-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 13 Apr 86 00:11:05-PST Date: Sat 12 Apr 86 23:09:28-PST From: Mark Crispin Subject: 6.1 manuals To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12198424933.6.MRC@PANDA> Is anyone other than me irked by the poor quality of the 6.1 revisions of the TOPS-20 manuals? The 5.1 System Manager's manual was typeset in a variable-width font; the 6.1 equivalent is in the same fixed-width font with ugly whole-space right justification that so many other DEC manuals use (seriously, DEC, it'd be better to have a ragged right margin than to put in extraneous spaces in a fixed-width font document). The worst travesty is the 6.1 JSYS manual (MCRM). There are huge margins (4cm left and right margins, 4.5 cm bottom margin). Where once the JSYS names in the header were printed in a bold font, they now are merely underlined. It looks like an LPT version of the JSYS manual was printed on a laser printer. It used to be that the DEC hardcopy manuals were more attractive and easier to read than printing the online LPT versions. I'd dump my locally-printed versions of the online files as soon as a hardcopy was available. Now, I see no reason to do so. At least with the LPT file I can make it print in a larger font than the default so it doesn't have mile-wide margins. ------- 13-Apr-86 07:49:26-PST,2574;000000000000 Return-Path: Received: from SU-SUSHI.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Apr 86 07:49:23-PST Date: Sun 13 Apr 86 07:49:34-PST From: William "Chops" Westfield Subject: Sushi running Domain based mail system... To: su-bboards@SU-SUSHI.ARPA, su-tops-20@SU-SCORE.ARPA, nethax@SU-GREGORIO.ARPA Message-ID: <12198519616.7.BILLW@SU-SUSHI.ARPA> Sushi is now running a version of tops20 and the MM mail system (and some other popular network utilities like TELNET) that supports the new "Domain" host naming scheme. This is beleived to be working fairly well. The current strategy is to look at the host name provided by the user. If it is not already in domain format (eg if it doesn't contain and "."s), .STANFORD.EDU is tacked on the end as the parent domain. The name is looked up using the domain protocol (maybe twice). If this fails, any added domain is removed, and the software ties again using the old host table. If this fails, the host name is considered illegal. What this means: You should now be able to reply to messages from all sorts of weird places (like Lots-A.Stanford.Edu, or AI.AI.MIT.EDU, or BUGS.Berkeley.Edu). It would take a while to fully explain domains, but what it amounts to is that the only one who has to know stuff about any given host is the organization directly responsible for it. Occasionally it may take several seconds to verify a host name while the software goes out and queries sites all over the country to try and find out whether that name really exists. Answers are cached, so this shouldn't happen for popular hosts very often. Since .STANFORD.EDU is appended to short names, you can say things like MAIL USER@KRAKATOA instead of MAIL USER@KRAKATOA.STANFORD.EDU. For the same reason, KRAKATOA by itself now means the Stanford host of that name, and not the University of Washington Krakatoa. (to get to UW's host, you should type its fully qualified host name: UW-KRAKATOA.ARPA; however...) Since the host table is used as a last resort, you CAN type short names like UCBVAX instead of UCBVAX.BERKELEY.EDU, or XX instead of XX.LCS.MIT.EDU. The system discovers that XX.STANFORD.EDU doesn't exist quite quickly... Enjoy BillW ++++++ There is a theory which states that if ever anyone discovers exactly what domains are for, and why they are here, they will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another which states that this has already happened. ------- 13-Apr-86 07:53:22-PST,624;000000000000 Mail-From: BILLW created at 13-Apr-86 07:53:19 Date: Sun 13 Apr 86 07:53:19-PST From: William "Chops" Westfield Subject: oops, almost forgot... To: su-tops-20@SU-SCORE.ARPA Message-ID: <12198520298.15.BILLW@SU-SCORE.ARPA> An added feature of the domain code is that it is somewhat smarter than the code that loads the internet host table with respect to the addresses it will choose to use. For example currently a host that is only on SUNet will pick the Milnet address for SRI-NIC, but the domain code will realize that the arpanet address is a much better choice... BillW ------- 13-Apr-86 09:20:54-PST,819;000000000000 Return-Path: Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Apr 86 09:20:43-PST Received: from 156206300 by CSNET-RELAY.ARPA id a018308; 13 Apr 86 12:18 EST Return-Path: Received: by bu-cs.ARPA (5.31/4.7) id AA02834; Sun, 13 Apr 86 12:19:50 EST Date: Sun, 13 Apr 86 12:19:50 EST From: Barry Shein Message-Id: <8604131719.AA02834@bu-cs.ARPA> To: MRC%PANDA@sumex-aim.ARPA, TOPS-20@su-score.ARPA Subject: Re: 6.1 manuals Perhaps DEC is trying to one-up IBM in the ugly manual race? I think IBM still does theirs on a selectric with those lovely +------+ line printer diagrams. Closing the primitive typeset gap? -Barry Shein, Boston University (actually, I haven't seen the 6.1 manuals yet.) 14-Apr-86 07:41:47-PST,2376;000000000000 Return-Path: <@CU20B.COLUMBIA.EDU:STAFF.DOBKIN@NYU20> Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 14 Apr 86 07:41:24-PST Received: from NYU20 by CU20B with DECnet; 14 Apr 86 10:39:36 EST Date: Mon 14 Apr 86 10:39:38-EST From: Daniel B Dobkin Subject: Re: 6.1 manuals To: MRC%PANDA@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA Reply-To: nyu.dbd@cu20b In-Reply-To: <12198424933.6.MRC@PANDA> Message-ID: <12198779952.25.STAFF.DOBKIN@NYU20> I've been meaning to ask about this for a few days; Mark's message has spurred me into action! The poor quality is only one of the things wrong with the 6.1 documentation; a more serious problem is its availability, or lack thereof. The MCRM that Mark (rightly, I think) complains about is only available as part of the $800+ doc kit; if you want to order it separately, you can only get the 5.1 manual (the January Documentation Products Directory, incidentally, refers to TOPS-20 AN V5.1 documentation -- no mention of V6.1 at all). In fact, just about anything you'd want to order extra copies of is not available except in the kit; most of the manuals you don't really need, of course, you can order to your heart's content. Some of the most useful manuals (notably the Monitor Tables book) are missing completely. When I called DEC to ask about ordering extra copies of the 6.1 MCRM, I was told there was no such part number! ("Where are you getting that part number from? I don't see it here...." It took a few minutes to convince them that the manual I wanted was sitting right on my desk.) A little checking on their part turned up the information that we're all free to reproduce the single copy we have, so long as we reproduce the copyright page. (That is a problem in and of itself -- our copy center won't reproduce that volume of copyrighted material!) The one useful piece of 6.1 documentation that they do have, though it isn't listed, is the T20 Quick Reference Guide, available without the little binder as AV-P173B-TM. And that costs almost twice as much as its v5.1 cousin did, including the binder. I guess now that DEC sees TOPS as on the way out, the documentation is doomed to precede it. Daniel B Dobkin New York University Graduate School of Business Administration (insert customary disclaimers here) ------- 14-Apr-86 14:14:32-PST,1430;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Mon 14 Apr 86 14:14:08-PST Date: Mon 14 Apr 86 17:10:29-EST From: Betsy Ramsey Subject: Re: 6.1 manuals To: TOPS-20@SU-SCORE.ARPA cc: NYU.DBD@CU20B.COLUMBIA.EDU Company: American Mathematical Society Message-ID: <12198851103.56.EWR@XX.LCS.MIT.EDU> We were also unable to order TOPS-20 documentation from DECdirect. I've spoken to Susan Porada and others in the Large Systems group at DEC. They are aware of the problem and are trying to get DECdirect to carry the new manuals. DECdirect won't sell any manual that didn't sell over 50 copies in twelve months, so they've moth-balled most of the TOPS documentation. If they stopped to think about it, though, they'd realize the only reason no one was buying the manuals was because a new version of the operating system hadn't been released in three years. Now that V6.1 is out, you'd think they'd jump at the chance to make some money. We'd like to order at least ten copies of the "TOPS-20 Commands Reference Manual" alone. In the meantime, the Large Systems group has indicated that they will work with your salesman in getting hold of the manuals directly from SDC or wherever. That's the approach we're going to try. Betsy Ramsey American Mathematical Society Net-Address: EWR@XX.LCS.MIT.EDU ------- 14-Apr-86 14:15:30-PST,1425;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Mon 14 Apr 86 14:14:57-PST Date: Mon 14 Apr 86 17:14:02-EST From: Betsy Ramsey Subject: DECnet File Transfer Security Issue To: TOPS-20@SU-SCORE.ARPA Company: American Mathematical Society Message-ID: <12198851749.56.EWR@XX.LCS.MIT.EDU> We just became a DECnet site (our two DEC-20s and VAX 8600 are on an Ethernet), and some security issues are beginning to confront us. The NFT program on the DEC-20s and VMS on the VAX require that, when accessing files on the remote system, the user enter his remote username and password. (For that matter, the same is true of TELNET at Internet sites.) Interactively, this is not much of a security issue because NFT (TELNET) turns echo off when it reads the user's password and VMS allows the use of symbol substitution. It does present a problem in batch, however. My question to the community is: how does your site handle this password issue for batch users? Do you use these programs in batch? Do you use a "public" account for file transfers? If you have any suggestions, please respond directly to me. I will summarize any responses I receive. Thanks. Betsy Ramsey American Mathematical Society Arpa: EWR@XX.LCS.MIT.EDU ------- 14-Apr-86 15:41:28-PST,707;000000000000 Return-Path: Received: from BUCS20 ([192.12.185.20].#Internet) by SU-SCORE.ARPA with TCP; Mon 14 Apr 86 15:40:50-PST Date: Mon 14 Apr 86 18:41:30-EST From: Philip Budne Subject: Re: DECnet File Transfer Security Issue To: EWR@XX.LCS.MIT.EDU cc: TOPS-20%SU-SCORE@BU-CS Reply-To: budd@[192.12.185.20] In-Reply-To: <12198851749.56.EWR@XX.LCS.MIT.EDU> Message-ID: <12198867672.11.BUDD@BUCS20> If you are using VMS 4.x and TOPS-20 6.1 you should be able to use 'proxy access'. 6.1 presents the username in the correct manner to VMS. IT DOES NOT WORK IN REVERSE. (ie; you must run NFT on the twenty). Phil Budne Boston University / Distributed Systems ------- 14-Apr-86 21:11:51-PST,1267;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Apr 86 21:11:42-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 14 Apr 86 21:07:40-PST Date: Mon 14 Apr 86 20:27:58-PST From: Mark Crispin Subject: Re: DECnet File Transfer Security Issue To: EWR@XX.LCS.MIT.EDU cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12198851749.56.EWR@XX.LCS.MIT.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12198919823.9.MRC@PANDA> Betsy - Most sites use a combination of a public "ANONYMOUS" account and the FTS program to allow batching of NFT requests. I have found FTS to be invaluable with 1200 baud DECnet. Unfortunately, FTS does have a problem. It uses RMS. I have discovered that there are certain files that FTS simply cannot handle; it blows up with "RMS error" and some number that I don't have the foggiest idea what it means (didn't the designers of RMS know about translating error numbers to strings? Or is that TOPS-20 concept too advanced for them?). NFT is quite happy to transfer the same file, however. This in two out of 60 or so files the last time. -- Mark -- ------- 15-Apr-86 02:38:32-PST,645;000000000000 Return-Path: Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Apr 86 02:38:22-PST Received: from nmt by csnet-relay.csnet id a008056; 15 Apr 86 5:35 EST Received: from PINON (pinon.ARPA) by nmtvax (4.12/4.7) id AA16470; Mon, 14 Apr 86 08:42:34 mst Date: Mon 14 Apr 86 08:37:35-MST From: Greg Titus Subject: Re: 6.1 manuals To: tops-20@su-score.arpa In-Reply-To: Message from "Mike Ames " of Sun 13 Apr 86 13:29:10-MST Yeah, and they dropped the MONSYM and MACSYM listings from the MCRM, too. Jerks ... greg ------- 15-Apr-86 21:11:29-PST,973;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 15 Apr 86 21:10:52-PST Date: Wed 16 Apr 86 00:10:13-EST From: Ken Rossman Subject: SMTJFN hangups To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12199189656.52.SY.KEN@CU20B.COLUMBIA.EDU> Is anyone else out there having problems with SMTJFN (the TCP mail receiver currently being distributed with the ARPAnet mail system out of Stanford)? Lately, we've been seeing conditions where SMTJFN gets hung up somewhere along the line, probably just after it has started an inferior process receiving mail and before it has had a chance to open a new connection for subsequent requests. The end result is that it is often found in a state where it is not ready to receive new incoming connections. Are we the only ones seeing this problem? /Ken ------- 15-Apr-86 23:16:24-PST,1302;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Apr 86 23:16:13-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 15 Apr 86 23:17:33-PST Date: Tue 15 Apr 86 22:16:24-PST From: Mark Crispin Subject: TOPS-20 6.1 documentation To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12199201707.6.MRC@PANDA> I got a call today from Susan Porada, the nice lady who runs the TOPS-20 documentation group. Most of us know Sue from meeting her at the documentation booth at DECUS. It turns out that all is not the way it seems with the 6.1 documentation; the manuals *are* lineprinter files printed on a laser printer but there is a reason for this. She'll be commenting about what's been happening with TOPS-20 documentation at DECUS in a few days and possibly also to this list. In the meantime, I'd like to ask everybody to hold off from further flaming about the quality of 6.1 documentation until you hear what's going on. I think we can give her some constructive input as to the directions of TOPS-20 documentation, but the present messages on this subject aren't. -- Mark -- ------- 16-Apr-86 00:35:51-PST,2773;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Apr 86 00:35:40-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 16 Apr 86 00:36:07-PST Date: Tue 15 Apr 86 23:48:07-PST From: Mark Crispin Subject: Re: SMTJFN hangups To: sy.Ken@CU20B.COLUMBIA.EDU cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12199189656.52.SY.KEN@CU20B.COLUMBIA.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12199218403.6.MRC@PANDA> Ken - This problem is a monitor bug. It allows connections to be tied up in SYN.SYN state for ages. If you are unfortunate to have a host that is determined to send you a SYN but not ack the SYN you send back (this is common in a "one-way gateway" situation) you can find your mail service (or whatever other service) go south. This is related to a bug in Unix, where it repeatedly tries reconnecting to a host without giving up after a while. I've talked about this problem to a few Unix gurus; they're aware of the bug and there is a fix that is starting to get distributed. I've been investigating various workarounds in SMTJFN, but believe that the right fix is to have TOPS-20 time out SYN's that don't go fully open much faster than it presently does. It does *not* fix the problem to have multiple streams listen on the SMTP port at a time. Guess what. Unix thinks it's a good idea to open multiple simultaneous connections to the same host. Why they think that is an advantage is beyond me; Dave Mills has had the same problem with them on Fuzzballs. I guess somebody who doesn't really understand network dynamics thinks that two simultaneous SMTP streams to the same host will be faster than a single connection used to send multiple messages. Anyway, what results is that your multiple listening streams get gobbled down by the same host. By the way, SMTJFN does not come out of Stanford. It comes from PANDA. The network distributed MM sources are on SIMTEL20 on its directory; generally, the version on SS: at SUMEX is reasonably up to date. The Score SCO: directory is NOT a distribution directory; Bill Westfield has been doing domain experimentation with the Score copy of MM and I have NOT been maintaining it (Westfield and I ARE communicating, and presently his work and some new stuff on PANDA's development directory will be merged and placed in the distributed directories). Please keep in mind that Score's copy of MM is experimental for Score and should not be exported from Score unless you're working with Westfield. If you want the supported version, get it from SIMTEL20. -- Mark -- ------- 17-Apr-86 13:57:36-PST,1003;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 17 Apr 86 13:57:25-PST Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Thu 17 Apr 86 13:58:30-PST Date: Thu 17 Apr 86 13:36:47-PST From: David Roode Subject: DEC 20 Maintenance Packaging To: TOPS-20%BIONET@SUMEX-AIM.ARPA Message-ID: <12199631400.28.ROODE@IC2060> Has anyone been able to find a field service base package which has MG memory instead of MF? Our local branch manager insists that the only packages that exist (such as the KL10-EE) have MF memory bundled in, and none have MG. He won't let us substitute a stack of MG for the MF. The KL10-EE is basically nothing more than the KL10-E Model B CPU, 2 channels, an MF/MG memory controller, and 256K of MF memory. There should be an alternative option number reflecting the substitution of 1M MG for the 256K MF. Are other field service branches being this ridiculous? ------- 18-Apr-86 02:12:33-PST,1811;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Apr 86 02:12:18-PST Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Fri 18 Apr 86 02:12:46-PST Return-Path: <@SUMEX-AIM:KNIGHT@SRI-NIC.ARPA> Received: from SUMEX-AIM by IC2060 with Cafard; Thu 17 Apr 86 21:47:23-PST Received: from SRI-NIC.ARPA by SUMEX-AIM.ARPA with TCP; Thu 17 Apr 86 21:31:46-PST Date: Thu 17 Apr 86 21:30:45-PST From: Bob Knight Subject: Re: DEC 20 Maintenance Packaging To: ROODE%BIONET@SUMEX-AIM.ARPA, BOB@WASHINGTON.ARPA cc: vivian@SRI-NIC.ARPA, lundberg@WASHINGTON.ARPA In-Reply-To: <12199701729.50.ROODE@IC2060> Message-ID: <12199717684.13.KNIGHT@SRI-NIC.ARPA> ReSent-Date: Fri 18 Apr 86 01:36:59-PST ReSent-From: David Roode ReSent-To: TOPS-20@SU-SCORE.ARPA ReSent-Message-ID: <12199762508.52.ROODE@IC2060> There is another site - New Mexico Tech Pinon has at least 1 MW MG, with no MF. And their maintenance contract specifies MF memory in the base configuration. Contact Mike Ames (ames@nmt.csnet) to verify this information. Not to beat too harshly on the local field circus people (god knows they get quite enough abuse!), but DEC in general just doesn't give a rats ass about 36 bits (to be quaint and colloquial), even with their so-called commitment to support 5 years out. DEC Corporate is at fault, and there really isn't much going to be effected by goosing the field people. Speaking personally, I've given up on DEC. I have no interest in VMS, and I have even less interest in non-cost-effective UNIX boxes. DEC made a commitment to a corporate architecure; that's fine, but they alienated a lot of people doing so, whether they realize it or not. Bob ------- 18-Apr-86 09:46:00-PST,807;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Apr 86 09:45:44-PST Date: Fri 18 Apr 86 09:44:35-PST From: Erik Lundberg Subject: Re: DEC 20 Maintenance Packaging To: KNIGHT@SRI-NIC.ARPA cc: tops-20@SU-SCORE.ARPA, bob@WASHINGTON.ARPA In-Reply-To: <12199717684.13.KNIGHT@SRI-NIC.ARPA> Message-ID: <12199851272.22.LUNDBERG@WASHINGTON.ARPA> Our local field service office was pretty obliging. They simply unbundled maintenance on the system, which includes MF-20 memory, into its consituent parts. Then they took off the MF-20 part and added MG-20. It made the list of items on our contract grow, but the price did indeed drop by the difference between the MF and MG memory that we had. Erik ------- 19-Apr-86 02:37:50-PST,741;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sat 19 Apr 86 02:37:40-PST Date: Sat 19 Apr 86 02:37:29-PST From: Mark Lottor Subject: CFORK% bug To: tops-20@SU-SCORE.ARPA Message-ID: <12200035665.15.MKL@SRI-NIC.ARPA> Problem: System dies with ILMNRF during a CFORK% (6.1 Monitor). Why: Call to KFORK1 doesn't setup P2. Fix: Fix the code at CFFAT in FORK.MAC (add the lines in lowercase) CFFAT: CALL CLRLFK ;YES. CLEAR MAPPING POP P,1 ;GET LOCAL INDEX CALL SETJFK ;GET JOB-WIDE FORK HANDLE move p2,p adjsp p,1 CALL KFORK1 ;ZAP THE FORK adjsp p,-1 CALL FUNLK ;RELEASE FORK LOCK RETERR (CFRKX3) ;GIVE NO RESOURCES ERROR ------- 20-Apr-86 06:25:59-PST,3044;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Apr 86 06:25:46-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 20 Apr 86 06:20:58-PST Return-Path: <@SUMEX-AIM:CPERLMAN@MARLBORO.DEC.COM> Received: from SUMEX-AIM by PANDA with Cafard; Fri 18 Apr 86 12:38:52-PST Received: from MARLBORO.DEC.COM by SUMEX-AIM.ARPA with TCP; Fri 18 Apr 86 12:30:06-PST Date: 18 Apr 1986 1530-EST From: CPERLMAN@MARLBORO.DEC.COM To: Mark Crispin Subject: Re: TOPS-20 6.1 documentation Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12199881459.23.660.3195 at MARLBORO.DEC.COM> References: Message from Mark Crispin of 16-Apr-86 0226-EST In-reply-to: <12199201707.6.MRC@PANDA> ReSent-Date: Sun 20 Apr 86 02:22:47-PST ReSent-From: Mark Crispin ReSent-To: TOPS-20@SU-SCORE.ARPA ReSent-Message-ID: <12200295135.6.MRC@PANDA> Hi, I'm Susan Porada and as Mark told you, I run the 10/20 Documentation Group. I promised Mark I would respond to members of this list in case some of you won't be at DECUS. Appearance of 6.1 manuals...In general, we worked to get our document source files to be as "self-contained" as possible. We did this for several reasons: to decrease cut and paste activities by illustrators, to decrease final production time so that writers could keep the books opened longer to catch last minute changes, to increase writer productivity due to fewer things that needed to be checked during the production cycle, and to increase the completeness of the machine-readable source file by eliminating dependencies on production/printing people so that the manuals will be easier to maintain in the future by someone other than my group. These plans caused several of the niceties to go away: typeset heads in the MCRM (that was a manual cut and paste operation in all versions previous to 6.1), lack of typesetting in the 6.1 System Manager's Guide (the system we previously used did not have pagination so that galleys had to be cut; we have replaced that typesetting system), decrease of two-color print (which requires markup by us and 2 passes at the printer). I agree with Mark about the small type and wide margins in the MCRM. The book was improperly reduced at the printing vendor and to not hold up the release any longer, we made the decision to let it go as printed. I am interested in constructive input for the documentation that we can incorporate during the next development cycle. In addition to ideas I have, I'm sure many of you can provide insight into areas to consider. I will be at the publications booth at DECUS all week to discuss this. Please stop by. Availability of 6.1 manuals... We know there is a problem and I am working with DECdirect to understand what can be done. We are as concerned about this as you are and I hope to have some answers by DECUS. Until DECUS..... Susan -------- -------- 20-Apr-86 06:42:26-PST,3212;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Apr 86 06:42:17-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 20 Apr 86 06:39:48-PST Date: Sun 20 Apr 86 02:48:04-PST From: Mark Crispin Subject: TOPS-20 documentation To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12200299738.6.MRC@PANDA> Friends, I have forwarded Susan Porada's message to the TOPS-20 list; it's clear that she intended to send it to the entire list but it ended up only being sent to me. Such are the problems one faces with "reply sender" vs. "reply all"... If you have not gotten a copy of her message please let me know. Susan's message definitely puts an entirely different perspective on the issue. I for one was completely unaware that DEC had such inadequate tools for documentation preparation. It is completely ridiculous in this day and age for people to have to cut and paste documents that have been prepared online. In spite of my liking for polished and typeset documentation, I think DEC is on the right track here. Reading between the lines a bit, I see the possibility that at some point the DSR source files for the various TOPS-20 manuals will be made available to customers. Given a choice between machine-readable documentation and typeset documentation, I'll take the former. Once we have the source files we can always convert them into Scribe and have nicely-typeset manuals. In other matters - Since DECUS is only a week away, I would like to take this opportunity to remind those who are going that this DECUS will pretty much settle what DEC does to TOPS-20 in the 2 years of development that are left to us. I urge those of you who are attending to give serious consideration of placing utmost emphasis on these issues and hammer them home: . when TOPS development ends, provide sources to all customers . when TOPS development ends, place TOPS in the public domain . provide machine-readable versions of all current TOPS manuals (Susan's work just makes this possible...this doesn't say that DEC will actually DO it! We have to ask for this) . upgrade TOPS languages to the same level as on VMS We really do need to push these. The languages are very important, as the long-term viability of TOPS after DEC throws in the towel depends on having a reasonable base of languages. The current TOPS situation with languages is at best barely adequate today. If we had modern versions of the languages, there are lots of hackers out there who can take care of keeping the monitor viable at least until maintenance ends in 1993. Be nice about it. DEC has no reason to do anything for a site that will have nothing to do with DEC equipment once their 10 or 20 goes away. Remember, with a set of current languages, machine-readable documentation, and TOPS in the public domain, we will have a helluva base to build on in the post-DEC era. We should be able to induce DEC to do this for us. -- Mark -- ------- 21-Apr-86 11:01:10-PST,823;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Mon 21 Apr 86 11:00:50-PST Date: Mon 21 Apr 86 14:02:23-EST From: Donna Lynch Subject: SMTJFN hangs To: tops-20@SU-SCORE.ARPA cc: admin@RADC-TOPS20.ARPA Message-ID: <12200651869.7.ADMIN@RADC-TOPS20.ARPA> I am having the same problem, only I run SMTPSV. I find a connection from 128.29.2.0 left in a SYN.SYN state. This host is hanging up my mail system. They are not even in the host tables. Is there anything being done, anything I can do to stop this? I would call the host administrator, but I dont know who it is. I am going on vacation soon. I need a solution to this problem or we may be without mail for the duration of my trip. Please help!!! --Donna ------- 23-Apr-86 00:35:47-PST,444;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 23 Apr 86 00:35:43-PST Date: Wed 23 Apr 86 00:36:13-PST From: Kirk Lougheed Subject: Sierra's AN20 is fixed.... To: su-tops-20@SU-SCORE.ARPA cc: vivian@SRI-NIC.ARPA Sierra's AN20 is operational once again, barring electrical accidents and DEC FE's who understand the device less than I do. Kirk ------- 23-Apr-86 05:11:37-PST,2190;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Wed 23 Apr 86 05:11:21-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA04110; Wed, 23 Apr 86 13:58:42 -0100 Date: 23 Apr 1986 13:06-EST From: steinar@oslo-vax Subject: Scheduler data from WATCH/SYSDPY ? To: TOPS20@SU-SCORE.ARPA Cc: Steinar@Oslo.ARPA Message-Id: <514641971/steinar@oslo-vax> Hi folks, As a part of their M.Sc study in digital simulation, 20 of our students are trying to simulate and model the behaviour of the T20 scheduler. All programs are written in SIMULA - a simulation language dedicated for doing discrete queue-simulation. The programs will implement the various scheduler lists, the priority queues, some of the monitor fork-data-structures, the up - and down movement in the queues, process blocking, the short and long cycle etc. Some of the programs are already up and running. However, we would like to fetch data from our own system by studying the WATCH - or SYSDPY output and use this as input to the programs. We're running monitor V6.1(7030), but have got no V6.1 documentation at all (This was ordered in January - adding an overseas-factor to the usual delay, we'll probably have the manuals some time next year ?) As for WATCH and SYSDPY, we have only some old .HLP files. So, what we would like to have WATCH to output - or to be able to calculate using the WATCH output, is : - The *average* number of processes on GOLST during the interval (NRUN?) - The *total* number of processes during the interval - The *total* number of blockings during the interval and how the blockings were distributed among terminal input wait, terminal output wait etc., i.e. the average number of processes on each of the seven wait lists during the interval. - The average duration for each type of blocking - The average life-time for a process Answers to some of these questions will be appreciated. Please send them to me directly. Steinar Kjaernsroed, Institute of Informatics, University of Oslo, NORWAY 2-May-86 15:32:16-PDT,2186;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 2 May 86 15:31:58-PDT Date: Fri 2 May 86 15:32:23-PDT From: Stu Grossman Subject: Re: XON/XOFF madness To: MRC%PANDA@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 4 Apr 86 07:55:28-PST I really like the way that XON/XOFF works on local (ie: -20F) terminals. To summarize: XON/XOFF is mostly (and quickly) handled by the front end as long as the program has not turned off TT%PGM for the terminal. This is the mode that the EXEC, and most other programs normally run in. If the program turns off TT%PGM, then -20F passes XON/XOFF (now just ^Q and ^S) directly to TOPS-20, who then passes them directly onto the program. This is the mode that EMACS normally uses. Because of this, output overruns are possible when using EMACS. However, TOPS-20 EMACS tends to be rather cretinous with respect to terminal I/O, and therefore it rarely if ever gets an overrun. This method of doing XON/XOFF works well, because there is some co-operation between the front-end and the monitor. The real bugaboo is networks. Most network terminal servers do not co-operate with the monitor as well as -20F, and therefore XON/XOFF performance is usually rather poor. In fact in some cases the terminal servers don't even treat XON/XOFF special! This is done to make things like EMACS work "correctly"! The secret to good XON/XOFF performance AND EMACS compatibility is to: 1) handle XON/XOFF as locally as possible (preferably inside of whatever computer the terminal is directly connected to). In addition, ALWAYS pass the XON/XOFF to TOPS-20 regardless of whether local XON/XOFF is enabled or not. 2) Provide a mechanism of telling the terminal server that local XON/XOFF handling should be enabled/disabled. TTYSRV has a special routine that gets called at all the right times for changing the state of a terminal servers' local XON/XOFF handling. Just have this routine send a special message to the terminal server. ------- 6-May-86 09:32:32-PDT,1045;000000000000 Return-Path: Received: from BUCS20.BU.EDU by SU-SCORE.ARPA with TCP; Tue 6 May 86 09:32:05-PDT Date: Tue 6 May 86 12:30:15-EDT From: Philip Budne Subject: New (?) PDP-10 operating system grows in popularity.. To: tops-20@SU-SCORE.ARPA Message-ID: <12204556335.18.BUDD@BUCS20.BU.EDU> 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 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. ....... stuff here about name swap of MC and MX ........ 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. phil ------- 6-May-86 11:20:39-PDT,1745;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Tue 6 May 86 11:19:56-PDT Date: Tue 6 May 86 11:17:52-PDT From: Bob Albrightson Subject: [Bob Albrightson : ] To: tops20@SU-SCORE.ARPA cc: dtc@WASHINGTON.ARPA Message-ID: <12204575924.9.BOB@WASHINGTON.ARPA> A friend of mine asked me to forward this. In a nutshell, he wants to port some rpc code from a 4.2 machine to tops20: _________________________________ >Date: Wed, 23 Apr 86 10:09:53 PST From: dtc (Dennis T. Ching) To: furuta@mimsy.umd.edu Subject: RPC for Ward and other TOPS-20's Cc: dtc Status: RO Rick, I'm considering putting our "heterogeneous RPC" on Ward. However, just talking to Jan Sanislo convinced me that we have monumental problems. I'm writing this to ask you if there is any way to cut these problems down to a managable size, in at least the following areas: 1) best C compiler for TOPS-20 2) UNIX 4.2BSD-style network interface The first area includes any C programming environment support, such as a high- level debugger, etc. The second area arises because (as I understand it) the Berkeley notion of sockets is far from available on TOPS-20. Hence, to get things such as read(), write(), sendto(), recvfrom(), signal(), and wait(), one might have to re-implement these routines (in C) using the appropriate JSYS calls. Do you know if anyone else has done this already, by any chance? Bob Albrightson will be copying the latest C compiler from Utah, and sending out an e-mail inquiry addressed to TOPS-20@score, but we have no assurance that we'll turn up good leads. Thanks in advance for any info. --Dennis ------- 6-May-86 13:30:10-PDT,1349;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Tue 6 May 86 13:29:46-PDT Date: Tue, 6 May 1986 14:58 EDT Message-ID: From: Rob Austein To: Bob Albrightson Cc: dtc@WASHINGTON.ARPA, tops20@SU-SCORE.ARPA Subject: [Bob Albrightson : ] In-reply-to: Msg of 6 May 1986 14:17-EDT from Bob Albrightson Anybody doing serious work with C on TOPS-20 should at least examine Greg Titus's C compiler. The cost is trivial, and the compiler generates native code. The library routines could use some work to cope with network tasks; there isn't any code for it now, but it wouldn't be that hard to add some (and I'd be interested in working on this, if anybody else is interested). One major advantage of this compiler is that it uses real PDP-10 byte pointers for character pointers, so it is much more useful for system programing tasks than the other -20 C compilers I've seen. There isn't any source level debugger, though. Sigh. Using IDDT on it is less painful than you'd expect, but this is obviously non-optimal. Contact C20%NMT.CSNET@CSNET-RELAY.ARPA for more details. --Rob [This is an unsollicited plug by a reasonably satisfied customer] 6-May-86 15:50:10-PDT,1267;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 6 May 86 15:49:37-PDT Date: Tue 6 May 86 18:41:56-EDT From: Ken Rossman Subject: Loading DECSA DECnet routers from TOPS-20 To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12204623996.77.SY.KEN@CU20B.COLUMBIA.EDU> I was trying to avoid asking this on TOPS-20 but I'm not finding out where to get direct answers elsewhere, so here goes. Anyone out there know how to download a DECSA DECnet router box (Pluto) from a DEC-20 via an NI? I did the DECSA software gen on a VMS system, and then wrote the load files to tape, reading them onto the -20 in 8 bit packed byte format (8 bit ILDB format), so the first thing I'm not sure about is are the files in the appropriate format? NCP seems happy enough with the set of node definition commands I give it, but when I go to load the DECSA, I get an almost immediate "Operation failed, attempting trigger" error message. If indeed it did try the trigger, that didn't work either (nor does pressing the "start" button on the front panel). Any info would be greatly appreciated. /Ken ------- 7-May-86 09:20:29-PDT,452;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 7 May 86 09:20:02-PDT Date: Wed 7 May 86 09:19:17-PDT From: Stu Grossman Subject: Re: Loading DECSA DECnet routers from TOPS-20 To: sy.Ken@CU20B.COLUMBIA.EDU cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Rossman " of Tue 6 May 86 17:58:21-PDT Try reading the manuals. ------- 7-May-86 14:54:06-PDT,1809;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Wed 7 May 86 14:53:49-PDT Date: Wed 7 May 86 16:53:55-CDT From: Clive Dawson Subject: Recent DEC response to SPR on EDT To: tops-20@SU-SCORE.ARPA Message-ID: <12204877398.25.AI.CLIVE@MCC.ARPA> An SPR in the 1-Mar-86 Software Dispatch complains that you can't type REENTER to get back into EDT. For those of you who missed it, here is DEC's response: Thank you for your SPR. We agree that the current behavior is not very clean and have included a DDT patch which will fix this with a better error message. Since EDT is a VMS compatibility product, it would not be appropriate to allow users the REENTER capability which does not exist under VMS. Thank you for your support of our software. They then go on to give an 8-line patch which will produce the message "?CANNOT REENTER EDT". Nice going, DEC. There's been much lip service given over the last couple of years to the idea of bringing VMS up to standards that *might*, *some day*, be even marginally acceptable to the TOPS-20 community. Responses like this, presumably from people who are involved in that effort, show me that it will never happen. Clearly, any feature that VMS doesn't already have now is worthless, right? How encouraging it would have been to read a response like: Thank you for your SPR. We agree that the current behavior is not very clean and have modified EDT to support the REENTER capability. We will consider adding the REENTER capability to VMS in the near future, at which point VMS EDT will be able to take advantage of this feature. Thank you for your support of our software. Dream on, McDuff... Clive ------- 8-May-86 21:53:44-PDT,2540;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Thu 8 May 86 21:53:27-PDT Received: from philabs.UUCP by seismo.CSS.GOV with UUCP; Thu, 8 May 86 23:58:28 EDT Received: by philabs.uucp (4.12/3.14) id AA25093; Thu, 8 May 86 16:54:22 edt Date: Thu, 8 May 86 16:54:22 edt From: Return-Path: Message-Id: <8605082054.AA25093@philabs.uucp> To: philabs!seismo!TOPS-20@SU-SCORE.ARPA Subject: Ongoing VMS development >From Clive Dawson's article... > An SPR in the 1-Mar-86 Software Dispatch complains that you > can't type REENTER to get back into EDT. For those of you > who missed it, here is DEC's response: > > Thank you for your SPR. We agree that the current behavior > is not very clean and have included a DDT patch which will fix > this with a better error message. Since EDT is a VMS compatibility > product, it would not be appropriate to allow users the REENTER > capability which does not exist under VMS. Thank you for your > support of our software. > > They then go on to give an 8-line patch which will produce the > message "?CANNOT REENTER EDT". > > Nice going, DEC. There's been much lip service given over the last couple > of years to the idea of bringing VMS up to standards that *might*, *some > day*, be even marginally acceptable to the TOPS-20 community. Responses > like this, presumably from people who are involved in that effort, show > me that it will never happen. Clearly, any feature that VMS doesn't > already have now is worthless, right? Not necessarily worthless, but probably not worth including in a lame-duck OS like VMS. Now before you bust a gut laughing, read this excerpt from the Regular Rumor Roundup column on page 51 of the May issue of Digital Review magazine: All computer architectures and operating systems have a finite life span, and VAX/VMS is no exception: Headhunters in DEC's western engineering group, quartered in Bellevue, Washington, are looking for hardware and software specialists to help design a new high-performance ECL processor with a next- generation operating system. Maybe if we write to them early enough they can squeeze the COMND JSYS into that new OS :-). ----- Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 ARPA: philabs!nyit!rick@SEISMO.ARPA UUCP: {decvax,seismo}!philabs!nyit!rick 9-May-86 01:09:08-PDT,775;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 9 May 86 01:08:53-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 9 May 86 01:08:43-PDT Date: Fri 9 May 86 00:05:04-PDT From: Mark Crispin Subject: Re: New (?) PDP-10 operating system grows in popularity.. To: BUDD@BUCS20.BU.EDU cc: tops-20@SU-SCORE.ARPA In-Reply-To: <12204556335.18.BUDD@BUCS20.BU.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12205239877.8.MRC@PANDA> I expect to be one of the beta test sites for KS10 ITS. They'll find out from me whether or not it works on RM03 disks... So, I'll have an ITS pack as I have a TOPS-10 pack. ------- 11-May-86 11:14:00-PDT,1605;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 11 May 86 11:13:47-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 11 May 86 11:14:05-PDT Date: Sat 10 May 86 20:40:26-PDT From: Mark Crispin Subject: BAD KL10 microcode bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12205726913.7.MRC@PANDA> I have discovered what I think is a really bad KL10 microcode bug. Consider the following instruction sequence, run in section 1: SECN==5 ; section to do this in FIRST==360000 ; first location LAST==377777 ; last location MOVSI T1,SECN ; load section SETZM @[SECN,,FIRST] ; clear first location MOVE T2,[FIRST,,FIRST+1] ; clear rest of area BLT T2,LAST(T1) ; do the clear This works as expected. However, when the value of LAST is greater than 377777, it gets an illegal memory read and doesn't do any BLT'ing at all. I first discovered this when SIMTEL20 bought it with an ILMNRF bughlt with the page fail word pointing to SECN-1,,FIRST !!!! SUMEX has the same code segment (or an equivalent) in its monitor, but for some reason it isn't crashing. However, I have verified that the bug is there too so SUMEX must be lucking out. SUMEX is running ucode 400, SIMTEL20 is running 351. Comments or helpful hints would be appreciated. This has stopped the installation of a new monitor at SIMTEL20 and I fear it could crash SUMEX at any time. ------- 11-May-86 12:02:28-PDT,581;000000000000 Return-Path: Received: from su-sierra.arpa by SU-SCORE.ARPA with TCP; Sun 11 May 86 12:02:20-PDT Date: Sun 11 May 86 12:03:18-PDT From: Bill Palmer Subject: Re: BAD KL10 microcode bug To: MRC%PANDA@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12205726913.7.MRC@PANDA> Message-ID: <12205894914.9.WHP4@su-sierra.arpa> That's not a bug, that's a feature! You're doing global indexing, and the Y field is interpreted as a signed displacement. Go read the fine print in your hardware manual... Bill ------- 11-May-86 14:06:02-PDT,1821;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 11 May 86 14:05:47-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 11 May 86 14:05:44-PDT Date: Sun 11 May 86 13:20:30-PDT From: Mark Crispin Subject: Re: BAD KL10 microcode bug To: whp4@SU-SIERRA.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12205894914.9.WHP4@su-sierra.arpa> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12205908968.6.MRC@PANDA> Ugh, Bill Palmer is right. The relevant statement is the last sentence on page 1-28 of the Hardware Reference Manual: "The case where the address word is local is quite unlike local indexing: the index is assumed to be a global addres, and the 18-bit Y is interpreted as a signed displacement (maximum magnitude 2^17), which is added to it algebraically. I'm sure there must have been a good reason for this, but I find myself somewhat at a loss to think of one. Are indexed data structures really likely to cross a section boundary? I would think it would be more useful for Y to be an unsigned number added to the global address with no carry from bit 18 into the section number. In other words, it would index the same way it does in section 0 with the exception that the left half of the index register would be taken as a section number. Of course, this is very biased from the monitor's point of view, where different structures are in discrete sections. Have the implementors of Common Lisp or any of the extended compilers found this definition preferable? Is anybody who was at DEC at the time still available to comment on the motivation for this? I realize it is much too late to have any chance of changing it. ------- 11-May-86 20:27:01-PDT,1415;000000000000 Return-Path: Received: from BUCS20.BU.EDU by SU-SCORE.ARPA with TCP; Sun 11 May 86 20:26:22-PDT Date: Sun 11 May 86 23:27:12-EDT From: Philip Budne Subject: Re: BAD KL10 microcode bug (global index with IFIW) To: tops-20@SU-SCORE.ARPA Message-ID: <12205986647.11.BUDD@BUCS20.BU.EDU> I was a member of the FORTRAN-10/20 v10 team, and I also wrote a PASCAL-like compiler that generates extended code. Mark comments that he finds sign extension of the Y field of an IFIW in the presence of a global index annoying; It is highly desirable in any extended compiler that arrays (or any other data structure) larger then 256K be accessible in a linear manner. In practice you end up using EFIWs to reference data more than IFIWs. However the signed IFIW Y field can be used in those cases when the folded offset is within 128K of a global index. For a stack oriented language is is often convenient to reference parameters stored on a stack (in this case a multi-section global stack) by "MOVE r,-n(P)" without having to worry about the stack crossing a section boundary. A highly recursive tower of hannoi solver compiled with my compiler can solve the problem for very large , the only limit is the number of SECTIONS created for stack. > ;IFN FLAME Solution: Use an XBLT. Heck, these days XBLT works from section 0! -Phil ------- 11-May-86 22:07:27-PDT,1309;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 11 May 86 22:06:07-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 11 May 86 21:42:31-PDT Date: Sun 11 May 86 21:11:01-PDT From: Mark Crispin Subject: TCP: device bug for 5.x systems To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12205994625.6.MRC@PANDA> Problem: None observed, due to luck. Diagnosis: The VLUKD routine for the TCP: device double-skips under 5.4, when it should only skip return. Fortunately, all the calls to it in LOOKUP skip over an instruction that doesn't really need to be done, but perhaps something will be surprised. Solution: At TCPVER:, replace SKIPN T1 ;any version stuff? JRST OKRET ;no so return MOVEI T1,TCPXX4 ;get error code JRST NOKRET ;return with error with: IFN. T1 ;version specified? RETBAD(TCPXX4,) ;yes, return this error ENDIF. SETONE TCDGN,(TCB) ;flag that we do not have to do this again TQNN ;do we need to unlock? OKINT ;yes so allow interrupts RETSKP ;+2 return In version 6.x systems, there is no SK2RET returns, so this doesn't matter. ------- 11-May-86 23:07:58-PDT,534;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 11 May 86 23:07:18-PDT Date: Sun 11 May 86 23:00:59-PDT From: Stu Grossman Subject: Re: BAD KL10 microcode bug To: MRC%PANDA@SUMEX-AIM.ARPA cc: whp4@SU-SIERRA.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12205908968.6.MRC@PANDA> Message-ID: <12206014644.19.GROSSMAN@SU-SIERRA.ARPA> The reason for this behavior is so that data structures in extended memory could cross section boundaries. ------- 15-May-86 14:11:36-PDT,2568;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Bjorn_Carlsson_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 15 May 86 14:10:19-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2694026779721373@MIT-MULTICS.ARPA>; 15 May 1986 16:46:19 edt Date: 07 May 86 13:30 +0200 From: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Resent-To: Tops-20@SU-SCORE.ARPA Subject: Loading DECSA DECnet routers from TOPS-20 Message-ID: <171889@QZCOM> In-Reply-To: <12204623996.77.SY.KEN@CU20B.COLUMBIA.EDU> I've tried to load a DECSA from a DEC2060 with some success. We did the installation on a VMS system and copied the files to the -20 over DECnet. (with /FIXED:512/MACY11 and /IMAGE switches to NFT). This is how we defined it in NCP: ;* ;* Define load parameters for Karon (DECnet router, DECSA). ;* Set Node Karon Diagnostic File Sys:CsvLdi.Sys Set Node Karon Dump File Serr:CsvRtr.Dmp Set Node Karon Hardware Address 08002B024CFF Set Node Karon Host Vera Set Node Karon Cpu Pdp-11 Set Node Karon Service Circuit NI-0-0 Set Node Karon Service Password 471142 Set Node Karon Load File Sys:CsvRtr.Sys Set Node Karon Secondary Loader Sys:Pluto2.Sys Set Node Karon Tertiary Loader Sys:Pluto3.Sys ;* Using these definitions to NCP we succeded in loading/starting the DECSA by pressing the Start-button. The DECSA and the -20 are connected to a DELNI which is connected to the ethernet with a H4000. We had some problems when we first tried to use a XEROX tranceiver to the ethernet (we had to but the DELNI in local mode). What we still haven't succeded in is to make the DECSA read its configuration-files from the -20 (in this case PS:KARONSB.CFG & PS:KARONRTR.CFG). The DECSA sends a request over DECnet to read the file PS:KARONSB.CFG, Userid: PLUTO, Account:PLUTO, Password:PLUTO and the -20 FAL receives the request, but after that nothing happens. The DECSA is running with default parameters. Some of the parameters you can alter with NCP (via TELL), but parameters like Maximum Addr. et.c. must be read from the configuration file at startup. I haven't had time trying to figure out why it doesn't work but it's probably some problem with the -20 FAL. We're currently loading the DECSA from a VMS machine on the same ethernet. 16-May-86 13:26:17-PDT,867;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Fri 16 May 86 13:25:05-PDT Date: Fri 16 May 86 13:22:56-PDT From: Ted Shapin Subject: PCL DOC wanted To: tops-20@SU-SCORE.ARPA Phone: (714)961-3393; Mail:Beckman Instruments, Inc. Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634 Message-ID: <12207220132.29.BEC.SHAPIN@USC-ECL.ARPA> From: Will Subject: PCL EXEC DOCUMENTATION Does anyone out there have a good set of online PCL documentation applicable to the V6.1 EXEC? I have been thinking abount implementing it however, if I do my user community will be hounding me for it. If DEC has supplied such documentation (which I doubt since they label PCL as "unsupported") I can't find it on my 6.1 Dist. Tape or my EXEC sources tape. Thanx ------- 16-May-86 15:50:40-PDT,842;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Fri 16 May 86 15:49:55-PDT Received: from (SYSTEM)SITVXB.BITNET by WISCVM.WISC.EDU on 05/16/86 at 13:48:40 CDT Date: Fri, 16 May 86 14:40:10 EDT From: rmcqueen(Robert C McQueen)%sitvxb.BITNET@WISCVM.WISC.EDU Message-Id: <860516144010.007@sitvxb> Subject: DECUS at San Fransico To: TOPS-20@SU-SCORE.ARPA There has been interest expressed at some of the previous DECUS symposium that there should be a TOPS to UNIX migration session. If there is some interest (meaning you would like to speak on the subject), I'll submit the session. Please get back to me before the end of this weekend, because the deadline is Sunday midnight. Robert McQueen Arpa: SIT.MCQUEEN@CU20B.COLUMBIA.EDU BITNET: RMCQUEEN@SITVXA 16-May-86 17:57:14-PDT,610;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 16 May 86 17:56:52-PDT Date: Fri, 16 May 1986 20:54 EDT Message-ID: From: Rob Austein To: Ted Shapin Cc: tops-20@SU-SCORE.ARPA Subject: PCL DOC wanted In-reply-to: Msg of 16 May 1986 16:22-EDT from Ted Shapin There's a copy of the standard PCL document in XX:PCL.DOC. I don't know if that's what you are looking for, but it's the only document I'm aware of. --Rob 17-May-86 00:14:49-PDT,1395;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Sat 17 May 86 00:14:26-PDT Return-Path: Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Sat, 17 May 86 02:12:41 EDT Received: by enea.uucp; Sat, 17 May 86 06:02:26 +0200 (MET) Received: by kuling.UUCP; Fri, 16 May 86 19:51:51 -0100 Date: Fri, 16 May 86 19:51:51 -0100 From: enea!kuling!victor@seismo.CSS.GOV (Bjorn Victor) Message-Id: <8605161851.AA01517@kuling.UUCP> To: TOPS20@SU-SCORE.ARPA Cc: kuling!victor@seismo.CSS.GOV Subject: Swappable Free Space This week, one of our machines hit the roof of system-wide logical names, i.e. the General Pool of Swappable Free Space was filled, resulting in various things. After poking around a bit in SYSDPY and STG (the only monitor module we have without a source license), it seems that the symbol SWFREL==:10000 ;SIZE OF OLD SWAPPABLE FREESPACE POOL could have something to do with the SIZE OF the SWAPPABLE FREESPACE POOL? Is it harmless to increase this value (and does it help me), should I look somewhere else, or should we just cut out the least useful logical names? Thankful for help --Bjorn Victor UUCP: {mcvax,seismo}!enea!kuling!victor Computing Science Dept/UPMAIL ARPA: enea!kuling!victor@SEISMO.CSS.GOV Uppsala University, PO Box 2059 S-750 02 UPPSALA, SWEDEN 17-May-86 16:31:42-PDT,323;000000000000 Mail-From: BILLW created at 17-May-86 16:31:24 Date: Sat 17 May 86 16:31:24-PDT From: William "Chops" Westfield Subject: ChaosNet To: tops-20@SU-SCORE.ARPA Message-ID: <12207516587.49.BILLW@SU-SCORE.ARPA> Has anybody added chaosnet support into V6.1 of tops20 yet? Thanks Bill W ------- 18-May-86 21:47:15-PDT,1254;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 18 May 86 21:46:55-PDT Date: Sun, 18 May 1986 22:47 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SU-SCORE.ARPA Subject: MICOM 600 hookup I've just examined the archives of this list, and none of the messages close to this subject seem to answer the following basic question about connecting a MICOM 600 to a -20 front end. I have all the ports in question set to REMOTE 9600, but the MICOM 600 wants DTR high always, except on logout, when it expects to see DTR toggled low for 150us (min) to 150s (max). If DTR doesn't return in 150s, it assumes that port is "unavailable", and operator intervention is required at the MICOM console to restore service on that port. (I can't believe that, but it was what I was told.) The catch is that the REMOTE setting will never bring DTR high unless it sees RI, and the MICOM doesn't supply that signal; it only supplies DSR, CTS, and DCD upon receiving a connection request, and it won't even do that unless it sees DTR. Catch-22. Now what? How have those of you with MICOM 600s solved this problem? --Frank 19-May-86 11:11:46-PDT,569;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Mon 19 May 86 11:11:18-PDT Date: Mon 19 May 86 11:10:08-PDT From: Bob Albrightson Subject: Re: MICOM 600 hookup To: WANCHO@SIMTEL20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message-ID: <12207982388.18.BOB@WASHINGTON.ARPA> On the contrary. The 600 we have does send RI. It seems to work fine here. What setting is the thumbwheel on the micom interface cards that go to the 20? -bob ------- 19-May-86 14:05:08-PDT,528;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 19 May 86 14:04:49-PDT Date: Mon 19 May 86 16:01:19-CDT From: Clive Dawson Subject: Autopatch 12 Tapes (Source) To: tops20@SU-SCORE.ARPA Message-ID: <12208013553.54.AI.CLIVE@MCC.ARPA> Has anybody out there received their *source* Autopatch 12 tapes for the monitor and the exec? I received the standard AP12 tape about 3 weeks ago, but as usual the source versions are lagging. Thanks, CLive ------- 19-May-86 14:37:41-PDT,2286;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 19 May 86 14:37:17-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 19 May 86 14:37:33-PDT Date: Mon 19 May 86 13:49:47-PDT From: Mark Crispin Subject: personal 10/20 mailing list To: TOPS-20@SU-SCORE.ARPA cc: SIT.McQueen@CU20B.COLUMBIA.EDU, Postmaster@LLL-MFE.ARPA, Postmaster@A.CS.CMU.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12208011453.7.MRC@PANDA> Friends - I am establishing a mailing list of owners of personal PDP-10's. Exactly what constitutes a "personal PDP-10" is rather fuzzy, but the general idea is a PDP-10 which is owned an operated by an individual or club primarily for hack value. I know of several KA's and KI's (mostly in Europe) that fit into this category; I would also like to identify other people like myself who have personal 2020's (that's what "PANDA" is). I understand that many of these systems do not have network mail access. That's something that CAN be corrected. A serial line mail protocol called Cafard (French for "cockroach") has been established and is in production use at a number of sites including PANDA. Cafard is fully integrated into the TOPS-20 mail system. Joe Smith at Tymshare (formerally at the Colorado School of Mines) has been given a copy of the complete MM package and is considering implementing it for TOPS-10. It shouldn't be too hard to create an ITS implementation. Cafard is much the same idea as UUCP, only unlike UUCP its source and protocol are completely public. PANDA deals with several megabytes of mail a week, since it sits at the hub of a 4-system Cafard mail network informally called "PANDAnet." I think if we get more sites joining we ought to call it "36-bitnet"!!! In any event, if you are the owner of a personal PDP-10, or know of somebody who does, please get in touch with me. I would like to collect: name, net-address (if reachable on the net), postal mail address, telephone, system type and configuration, and operating system(s) in use. Please also pass this message on through the TOPS-10 grapevine. ------- 19-May-86 16:05:51-PDT,713;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 19 May 86 16:05:39-PDT Date: Mon 19 May 86 16:06:08-PDT From: Bruce Tanner Subject: Re: Swappable Free Space To: TOPS20@SU-SCORE.ARPA In-Reply-To: <8605161851.AA01517@kuling.UUCP> Message-ID: <12208036274.12.CERRITOS@USC-ECL.ARPA> Interestingly enough, we've just run into this problem today. Mount complained about not being able to associate MTA0: with MT0: because of insufficient swappable free space. Is it just a case of rebuilding with a larger SWFREL? I'm not sure I can convince our people to do without so many system-wide logical names. Help! -Bruce ------- 20-May-86 15:13:43-PDT,500;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Tue 20 May 86 15:13:22-PDT Date: Tue 20 May 86 17:12:39-CDT From: Clive Dawson Subject: Autopatch 12 Source Tapes To: tops-20@SU-SCORE.ARPA Message-ID: <12208288681.23.AI.CLIVE@MCC.ARPA> I spoke with Diane Lorion (DEC Large System Marketing) this afternoon, and she informed me that the source tapes for Autopatch 12 were delayed. They are due out of SDC on May 27. Clive ------- 22-May-86 13:29:48-PDT,1231;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 22 May 86 13:29:27-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 22 May 86 13:30:12-PDT Date: Thu 22 May 86 12:29:28-PDT From: Mark Crispin Subject: VT220 vs. TOPS-20 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12208783264.6.MRC@PANDA> I'm experimenting with a VT220 clone here. I've already noted the obvious problems with dealing using a VT200 series terminal with TOPS-20, such as the lack of an escape key and having greater than/less than where you expect the shift key instead of over period and comma. What I'm trying to figure out is how to use the international character set facility. As far as I can tell, you can only use this when you are in 8-bit data transmission mode, but TOPS-20 sends 7 bits with parity! Apparently VMS does so as well, since my instructions for the DEC Electronic Store quite explicitly tell you to use 7 bit space parity, ignore parity mode. Is the international character set facility useful at all on any DEC system? ------- 23-May-86 16:23:40-PDT,602;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Fri 23 May 86 16:23:21-PDT Date: Fri 23 May 86 16:05:10-PDT From: Bob Albrightson Subject: tops20 To: tops20@SU-SCORE.ARPA Message-ID: <12209084674.8.BOB@WASHINGTON.ARPA> I am interested in gathering system statistics, particularly subsystem statistics. I made the mistake of believing that WATCH would supply me with that info. Is there a way to find out what programs have been run and various other subsystem level stuff like runtime etc... -thanks. -bob ------- 26-May-86 00:13:36-PDT,495;000000000000 Return-Path: Received: from su-sierra.arpa by SU-SCORE.ARPA with TCP; Mon 26 May 86 00:13:25-PDT Date: Mon 26 May 86 00:12:57-PDT From: Stu Grossman Subject: Re: tops20 To: BOB@WASHINGTON.ARPA cc: tops20@su-score.arpa In-Reply-To: Message from "Bob Albrightson " of Sun 25 May 86 13:35:49-PDT The EXEC command: @INFO SUBSYS probably does what you want. More stuff might be available via GETABs. ------- 27-May-86 10:16:44-PDT,1468;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Tue 27 May 86 10:16:16-PDT Received: from philabs.UUCP by seismo.CSS.GOV with UUCP; Tue, 27 May 86 11:29:37 EDT Received: by philabs.uucp (4.12/3.14) id AA24212; Tue, 27 May 86 10:20:55 edt Date: Tue, 27 May 86 10:20:55 edt From: Return-Path: Message-Id: <8605271420.AA24212@philabs.uucp> To: philabs!seismo!TOPS-20@SU-SCORE.ARPA Subject: ILPSEC BUGHLT fix TOPS-20 V6.1 The recent Autopatch 12 or 13 distribution has a new bug that has been known to cause ILPSEC BUGHLTs. The bug was a side-effect of a performance enhancement. The fix follows. I think this is all correct, but I'm doing it from memory without looking at the code... The subroutine REMFPB (in PAGEM or PAGUTL) has become buggy in Autopatch 12. It no longer returns to its caller. The fix is to add some new code, marked with the comments ;[NEW]... below: REMFPB::PIOFF HRRZ T1,DELPGQ IFE. T1 ;[NEW] IS QUEUE EMPTY? PION ;[NEW] YES, RE-ENABLE INTERRUPTS RET ;[NEW] RETURN TO CALLER ENDIF. ;[NEW] Without this fix, REMFPB tries to process page 0. That ultimately led to the ILPSEC BUGHLT. I can't imagine how this routine works properly at all, so the fact that the monitor runs for a long time without a BUGHLT leads one to believe that REMFPB is rarely called. Rick Ace 29-May-86 08:01:51-PDT,638;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Thu 29 May 86 08:01:36-PDT Received: ID ; Thu 29 May 86 11:01:39-EDT Date: Thu 29 May 86 11:01:39-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: GALAXY printer query To: tops-20@SU-SCORE.ARPA Message-ID: <12210569515.29.VAF@C.CS.CMU.EDU> Has anyone modified GALAXY to support multiple printer types? What I am looking for is some mechanism where I can associate each printer with a server that understands how to talk to it rather than having to modify LPTSPL (yech) to handle all types of printers. --Vince ------- 29-May-86 10:30:39-PDT,695;000000000000 Return-Path: Received: from cu-arpa.cs.cornell.edu by SU-SCORE.ARPA with TCP; Thu 29 May 86 10:30:01-PDT Message-Id: <8605291728.AA06059@cu-arpa.cs.cornell.edu> Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA06059; Thu, 29 May 86 13:28:53 EDT To: tops-20@su-score.arpa Subject: mm for vms Date: Thu, 29 May 86 13:27:41 -0500 From: george@vax1.ccs.cornell.edu I have not heard much information recently and we are about ready to migrate to a vms system... So, does anyone have any recent info about a mail program for vms with capabilities similar to tops-20 mm or ms? Thanks! -george, george@{{gvax.cs,vax1.ccs}.cornell.edu,crnlcs.bitnet} 30-May-86 08:12:55-PDT,1897;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 30 May 86 08:12:38-PDT Date: Fri 30 May 86 10:17:29-EDT From: Thomas De Bellis Subject: Re: GALAXY printer query To: Vince.Fuller@C.CS.CMU.EDU cc: Tops-20@SU-SCORE.ARPA In-Reply-To: <12210569515.29.VAF@C.CS.CMU.EDU> Message-ID: <12210823620.13.SY.SLOGIN@CU20B.COLUMBIA.EDU> Vince, I did that a long, long time ago--1983? Fortunately, I did this to a CMU Galaxy, so the changes should be easy to pick up. Basically, I modified the QSRSCH module to schedule the Galaxy object to processor link up on more parameters than just object type and attribute specifications. Specifically, I made it also consider the processor program name which the processor gives to QSRADM from its IB block when it sends a hello. The QSRLPT module was changed to have an additional field in the PRINTER keyword entry for the program name. When QSRSCH tries to do the link up, it must now find a processor for the object type whose name matches the required program name specified in the LPFORM.INI file. It's a pretty obvious thing to do. This has worked like a champ for us for years. I am able to get processors off the ARPAnet and have them up in about a day. Right now, we are running three printer processors: LPTSPL (9700 stuff, DRP code, Printronix, IBM tapes), LSRSPL (Imagen Ethernet stuff) and TCPSPL (Unix spooler, Laserwriter stuff). Please see the sources in SNARK:<5.GALAXY.US> on CU20B and contact me for any further questions. Our Galaxy used to assemble for three sites; CMU Comp Center, CMU Computer Science department and Columbia. You shouldn't have any trouble picking up the changes. In fact, you could probably just take our code and assemble it for CMU! Good Luck, -- Tom ------- 30-May-86 13:43:43-PDT,1389;000000000000 Return-Path: <@WISCVM.WISC.EDU,@WESLEYAN.BITNET,@VAX.WESLYN:DECK@VAX.WESLYN> Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Fri 30 May 86 13:43:10-PDT Received: from (MAILER)WESLYN.BITNET by WISCVM.WISC.EDU on 05/30/86 at 13:34:25 CDT Date: 30-MAY-1986 14:16:35.93 From: DECK%VAX.WESLYN%WESLEYAN.BITNET@WISCVM.WISC.EDU To: tops-20@su-score.arpa Subject: Mail for a Vax I have been working on a mail system for our Vax at Wesleyan which works in principle like mail on the 20's. It currently consists of four programs: SMTPFORK, BSMTPFORK, MM and MAISER. SMTPFORK is a smtp server for Tektronix's version of TCP/IP. BSMTPFORK is a bsmtp server for incoming bitnet mail. MM is the user interface. MAISER delivers incoming mail, SMTPFORK, BSMTPFORK, and MM write files to sys$mailq: and MAISER picks up the files in sys$mailq: and sends them to ether a local users, across the local ethernet, or across Bitnet. The user interface has had the least amount of work done to it since we were primarily interested in a gateway between our 20s on the local ethernet and Bitnet. Anyone who might be interested in this can contact me for a document describing it in more detail. Joe Deck deck%kla.weslyn@wesleyan.bitnet 30-May-86 19:28:08-PDT,1221;000000000000 Return-Path: Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Fri 30 May 86 19:27:26-PDT Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.05/4.7.34) id AA06834; Fri, 30 May 86 17:27:47 pdt Message-Id: <8605310027.AA06834@decwrl.DEC.COM> Date: Friday, 30 May 1986 09:07:45-PDT From: ridder%d2c2.DEC@decwrl.DEC.COM To: tops20@su-score Subject: Re: MICOM 600 hookup ======== Date: 30 May 1986 0957-MDT From: Hans To: "tops20@su-score"@DECWRL Reply-to: Ridder@WARLOK Subject: Re: MICOM 600 hookup Message-ID: <"MS11(5206)+GLXLIB5(0)" 12210841779.104.27.45279 at D2C2> We here at the CSC used to have a MICOM (600 I think) and it worked just fine with the lines set to REMOTE AUTO. What we had to do was rummage around in the MICOM documents and find the correct "protocol" to set the thumbwheel switch. I seem to remember it was protocol 9. The "normal" protocol (sometimes called "Hot DTR") is protocol 8. I may have these backwards. Also, I think our cables had pins 2, 3, 5, 6, 7, 8, 20, 22. I know this might look strange, but that's the way I remember it (strange that is). -hans -------- 30-May-86 19:59:43-PDT,1242;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 30 May 86 19:59:35-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 30 May 86 19:59:47-PDT Date: Fri 30 May 86 18:17:54-PDT From: Mark Crispin Subject: MM for a Vax To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12210943844.8.MRC@PANDA> Dear MM-for-a-VAX developers: I would like to urge any and ALL of you who are developing an MM clone for VAX/VMS that you return the favor that you enjoyed on the DEC-20 with MM-20. In other words, SEND ME YOUR VMS MM CLONES! It may help somebody else from reinventing the wheel. I am especially interested in a VAX MM clone which has been demonstrated to work over DECnet with DEC-20 MM. Consider it your payment for the years of MM development and support on the DEC-20. Tools such as EMACS and MM came about because people were willing to share them. Please help. Time and time again I am asked about MM for a VAX, and even more so for a VAX MM that is known to work with MM-20 over DECnet (SMTP DECnet mailing). -- Mark -- ------- 2-Jun-86 22:00:39-PDT,652;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jun 86 22:00:27-PDT Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Mon 2 Jun 86 22:01:26-PDT Date: Mon 2 Jun 86 21:46:47-PDT From: David Roode Subject: MCA25/2065 To: TOPS-20@SU-SCORE.ARPA Message-ID: <12211768302.38.ROODE@IC2060> I would like to talk to anyone about to trade a 2065 upgraded system in to DEC for credit on a VAX, or to anyone whose workload is falling who would like to downgrade to a 2060 again. Call 415-965-5585 or replies to me only--no need to bother the list. ------- 4-Jun-86 01:21:27-PDT,2434;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 4 Jun 86 01:21:18-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 4 Jun 86 01:06:14-PDT Date: Wed 4 Jun 86 00:04:38-PDT From: Mark Crispin Subject: TOPS-20 and TTY parity To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12212055542.7.MRC@PANDA> Lately, I've done a bit of experimentation with the state of parity handling on TTY lines in TOPS-20. I've concluded that while the TOPS-20 monitor handles correctly handles even parity, most of the system utilities which do display handling do not. This includes virtually all non-DEC software and most DEC software; TV TECO was the only exception. Even the EXEC was an offender. One of the offenders was TELNET, in spite of its supposedly having code to handle parity. I determined why it didn't work, but decided that since the user who demanded that it "must" support parity never said anything it was never used and decided to flush the code. It might make TELNET a little bit faster. The basic problem is that any program which uses binary mode must do its own parity handling, something that obviously is not forthcoming. An additional problem has come up with TOPS-20's 8th bit parity on 7-bit ASCII characters, in that this precludes any use of the international character set on VT220's. This may seem pretty random, but on the other hand VMS supports it! I feel that enforcing 8th bit parity (mode "7E") has become a mistake. I am tempted to remove parity handling from TOPS-20 altogether on the grounds that nobody could possibly be depending upon it since so many tools violate it. What I am more likely to do is implement a new TERMINAL class command, TERMINAL PARITY or some such, that specifies whether or not parity should be applied. If it is not set, then TOPS-20 will use space parity on output characters except in binary mode. On input characters, the '200 bit will be discarded unless the terminal is in binary mode. By the way, this mode is essentially what happens on all lines except for physical hardwired lines. I am interested in any comments. I haven't decided what the default setting should be. At the very least for VT220's it should default to no parity handling! ------- 4-Jun-86 14:53:21-PDT,1585;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 4 Jun 86 14:52:47-PDT Date: Wed 4 Jun 86 14:52:54-PDT From: Bob Knight Subject: DH-11's at 19200 baud. To: tops-20@SU-SCORE.ARPA Message-ID: <12212217246.26.KNIGHT@SRI-NIC.ARPA> Hi - well, I finally tried the modification for DH's at 19.2K baud. It works, actually, and fairly well. Here's the procedure for doing so: o In the DH-11 locate the M4540 card. This is the DC11 clock. o On this card, locate E12 and E13. E12 is a 7492 and E13 is a 7493. o Pin 9 of E12 is the 19.2K baud clock. Pin 12 of E13 is the 134.5 baud clock. o Cut the trace from pin 12 of E13 that goes to the paddle end of the board. o Install a (short) jumper from pin 9 of E12 to the paddle side of the trace cut in the previous step. Ensure that there are no shorts, bridges, etc. o Plug the 4540 back in. Now, when you tell the DH to go to 134.5 baud on a line, it will actually function at 19.2K baud. Appropriate modifications to the EXEC and monitor will make things work fairly transparently. Bob PS: I take no responsibility for any damage that occurs from usage of these instructions. Furthermore, note that our DHs aren't under DEC maintenance, and I doubt that Field Service looks kindly on this type of modification. PPS: Mark Kapplein of DEC told me about this modification a number of years ago, and deserves the credit for first having done this. Thanks, Mark. ------- 4-Jun-86 19:36:24-PDT,1026;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 4 Jun 86 19:35:58-PDT Date: Wed 4 Jun 86 22:34:37-EDT From: Ken Rossman Subject: DMR vs DMC communications mode To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12212268532.212.SY.KEN@CU20B.COLUMBIA.EDU> Does anyone out there know exactly what the difference is between DMR and DMC mode in a DEC DMR line driver board? I am (still) trying to get a DECSA to talk to remote DECnet links, but seem to be getting timeouts. The documentation warns that DMC compatibility mode is not supported by the DECSA, but I suspect that is the mode all of my current links use to talk to my existing DN20s. /Ken P.S. -- Many thanks to all of you who answered my previous inquiries about getting the DECSA loaded over Ethernet from a -20. In piecing it all together, I have managed to get the thing loaded. ------- 6-Jun-86 04:55:29-PDT,1666;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Fri 6 Jun 86 04:55:14-PDT Return-Path: Received: from munnari.OZ by seismo.CSS.GOV with UUCP; Fri, 6 Jun 86 07:43:33 EDT Received: from charlie (via mulga) by munnari with SunIII (5.5) id AA01007; Fri, 6 Jun 86 20:48:06 EST Received: by charlie .Deakin (4.12) id AA07080; Fri, 6 Jun 86 17:26:32 est Date: 06 Jun 86 17:26:29 +1000 (Fri) Message-Id: <104.518426789@charlie> To: Tops20 People Subject: Need some new disk utilities From: Craig Warren We recently have had a bad run of problems on our RP06 drives and some of our utilities have proved invaluable. It seems that I will probably be using these utilities for quite a while, so I thought I might try and get more up to date versions. Here is what I currently have: $ralph RALPH - Image mode pack copier for RP04 and RP06 disk drives. Version of 1-December-1981. Program is ARTHUR, version is 1(51) Program is MERLIN, version is 2(7)-4 Program is CHECKD, version is 5.1(82) Arthur & Merlin basically allow the copying,renaming or deleting of directories. I know that we have an old version of Tops20 as 6.1 hasn't reached Australia yet! Anyway, if anyone can help me with new versions of these programs or programs they use for manipulating disks and structures, I would greatly appreciate it. Craig Warren UUCP: {seismo,ubc-vision,ukc,mcvax}!munnari!charlie.oz!ccw ARPA: munnari!charlie.oz!ccw@SEISMO.ARPA 6-Jun-86 07:29:46-PDT,881;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Fri 6 Jun 86 07:29:35-PDT Date: Fri 6 Jun 86 09:31:16-CDT From: Clifford A. Wilkes Subject: CERBERUS with domains To: tops20@SU-SCORE.ARPA Department: Computation Center - A20/R20 staff Message-ID: <12212661138.40.CC.WILKES@R20.UTEXAS.EDU> We at the University of Texas are in need of a version of the CERBERUS package which will handle domain names. It should also allow for about 10,000 users (we have over 7,000 accounts on one of our 20's now). Also, it should work with 6.1 which our current version apparently does not. We are too understaffed and overburdened to undertake the conversion ourselves so we would be grateful to anyone who could supply an updated version or point us to one. Thanks in advance. <@> ------- 6-Jun-86 08:58:10-PDT,998;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Fri 6 Jun 86 08:57:47-PDT Received: from (MAILER)UDCVM.BITNET by WISCVM.WISC.EDU on 06/06/86 at 10:59:02 CDT Return-path: MHICKEY@UDCVM.BITNET Received: by UDCVM (Mailer X1.23) id 8293; Fri, 06 Jun 86 11:59:42 EST Date: Fri, 6 Jun 1986 11:50 EST From: Mike Hickey Subject: Missing line numbers To: We recently upgraded to 6.1 on our 2065 and found that EDIT line numbers were being stripped when a file was printed. TSC was called but was not able to reproduce the problem. We're running a vanilla GALAXY and relatively vanilla (support for local terms added) MONITR. LPTSPL was hacked to support TTYNNN: printers but the vanilla 6.1 LPTSPL has the same problem. Has anyone seen this "problem" or have any hints? We're not a source site so be gentle.... /Mike 6-Jun-86 19:09:38-PDT,932;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Peter_Lothberg_STUPI@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Jun 86 19:09:26-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2695946090699726@MIT-MULTICS.ARPA>; 06 Jun 1986 21:54:50 edt Date: 05 Jun 86 14:45 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: DH-11's at 19200 baud. Message-ID: <178677@QZCOM> In-Reply-To: <12212217246.26.KNIGHT@SRI-NIC.ARPA> Another way of supporting 19.200 baud is using the external clock input, then you have to provide an external clock, but dont need to change anything on the pc bords. 6-Jun-86 22:58:13-PDT,1360;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Jun 86 22:58:01-PDT Date: Sat 7 Jun 86 00:59:25-CDT From: Clive Dawson Subject: Talking to SUN-3 Workstations To: tops20@SU-SCORE.ARPA Message-ID: <12212830103.34.AI.CLIVE@MCC.ARPA> We've recently installed various Sun-3 workstations on our corporate Ethernet, and discovered that they cannot communicate with our DEC-20 unless entries for them are manually inserted into the 20's ARP table. Further investigation reveals that the 20 is receiving ARP packets from these systems, but immediately discards them because the Hardware Address Type and the Protocol Address Type fields of the packet contain what seems to be random garbage. The ARPRCV routine in IPNIDV checks these values and expects them to be 1 and 4000(8) respectively. Another problem we've seen (which may have the same cause) is that several Symbolics Lisp Machines immediately hung when some of the disk-less SUN-3's were connected to the net. This was apparently also attributed to bad broadcast packets being sent by the Suns. Has anybody else seen this problem? I'm really hoping this turns out to be a software bug, rather than some sort of hardware incompatibility. The SUN 3's apparently have new Ethernet interface boards... Clive ------- 6-Jun-86 23:44:16-PDT,824;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 6 Jun 86 23:44:05-PDT Received: ID ; Sat 7 Jun 86 02:45:41-EDT Date: Sat 7 Jun 86 02:45:40-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Question about rebuilding BOOT.EXB To: tops-20@SU-SCORE.ARPA Message-ID: <12212838521.5.VAF@C.CS.CMU.EDU> Could someone outline the procedure for rebuilding and installing BOOT.EXB? I recall doing this once long ago but have forgotten what I did (we have a source patch to BOOT that is necessary to support our 5 x RP06 PS:). Believe me, the last thing you want to discover after 8 hours of file system rebuilding is that the standard BOOT won't load the monitor and you've misplaced your hacked version (and forgotten how to recreate it...) --Vince ------- 8-Jun-86 18:15:07-PDT,3188;000000000000 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Sun 8 Jun 86 18:14:40-PDT Date: 8 Jun 86 21:11:02 EDT From: Charles Hedrick Subject: Ethernet issues To: tops-20@SU-SCORE.ARPA Message-ID: <12213301892.45.HEDRICK@RED.RUTGERS.EDU> 1) I suspect your Suns can't talk to your 20's because Unix has a tendency to produce ARP packets that are too long. Here is our current version. This is in IPNIDV.MAC. Sun is not the only machine with this problem. IFL AR.LEN-EMINPL,< ;[212] AR.WRD==+4 ;WORD SIZE OF ARP PACKET (PLUS A COUPLE) ;[212] AR.LEN==EMINPL ;BYTES IN ARP PACKET ARE ETHERNET MINIMUM ;[212] AR.MAX==MINPKT+4 ;MAX BFR SIZE WITH ETHERNET CRC (PLUS 4) AR.WRD==+5 ;[212]WORD SIZE OF ARP PACKET (PLUS A COUPLE) AR.LEN==EMINPL+4 ;[212]BYTES IN ARP PACKET ARE ETHERNET MINIMUM AR.MAX==MINPKT+8 ;[212]MAX BFR SIZE WITH ETHERNET CRC (PLUS 4) > We have never explained why it is that this bug causes bytes at the beginning of the ARP packet to be garbaged, but it does. 2) Diskless Suns are very sensitive to broadcast addresses. We don't know exactly what is going on, but we do know that if you have some Suns that use subnetting and some that do not, they get into some sort of war, and usually take down every other network interface on that Ethernet whose TCP/IP code is not battle-hardened. It is quite possible that the same sort of thing could be happening between a Sun and a 3600. Suns produce broadcast packets using the address net.0. I.e. your network number (including subnet number if you install 4.3-style subnets) with the host part 0. Sun's release 3.0 also accepts -1, the new standard, as a broadcast, although they do not produce this address. I have no idea what 3600's do, since I can't find our copy of the Symbolics TCP documentation. If you have release 3.0 on your Suns, you might be able to figure out what is going on by using etherfind. If you tell it to display headers (the -x option), you can find the actual address being used for broadcasts. However you'll have to be careful doing the test. When the actual disaster is in progress, the Sun doing the monitoring will be spending all of its CPU time in the low-level IP code, and etherfind will get no CPU. But you can probably find a way to arrange for the Symbolics to send some broadcast packets while all your diskless Suns are turned off. Or perhaps you have an IBM PC with the MIT TCP software. netwatch will work fine for this. We put diskless Suns on their own Ethernet. The Ethernet is so critical to them, and we have so many random machines doing so many wierd things, that we felt it was safer not to have anything else on their net. The subject of broadcast addresses has been discussed at length in the TCP-IP mailing list. As I understand it, -1 (i.e. 255.255.255.255) is now the correct address. This is fairly recent, and not all that many machines support it. I think we are probably going to go down our list of machines one by one making sure that they all agree on the broadcast address. ------- 9-Jun-86 11:51:58-PDT,448;000000000001 Mail-From: G.ELDRE created at 9-Jun-86 11:51:42 Date: Mon 9 Jun 86 11:51:41-PDT From: Tim Eldredge Subject: Looking for MAKIMP To: tops-20@SU-SCORE.ARPA Message-ID: <12213494977.38.G.ELDRE@SU-SCORE.ARPA> I'm looking for a copy of MAKIMP which supports the 300dpi imagens as well as the 240dpi ones. This may belong on Laser-lovers, but makimp is a 20 program only so I thought I'd try this list first. ------- 10-Jun-86 11:57:36-PDT,546;000000000000 Return-Path: Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Jun 86 11:57:16-PDT Date: 10 Jun 1986 11:57 PDT (Tue) Message-ID: From: Peter King To: Tim Eldredge Cc: tops-20@SU-SCORE.ARPA Subject: Looking for MAKIMP In-reply-to: Msg of 9 Jun 1986 11:51-PDT from Tim Eldredge There is a program called DVIIMP (on Score) that will convert DVI files to 300dpi IMP files. Peter 11-Jun-86 15:01:13-PDT,1615;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Wed 11 Jun 86 15:00:45-PDT Return-Path: Received: from munnari.oz by seismo.CSS.GOV with UUCP; Wed, 11 Jun 86 17:49:13 EDT Received: from seismo by munnari with UUCP (5.5) id AA29882; Thu, 12 Jun 86 07:44:34 EST Received: by seismo.CSS.GOV; Wed, 11 Jun 86 15:18:31 EDT Date: Wed 11 Jun 86 13:18:39-MDT From: Douglas Hendry Subject: Re: Need some new disk utilities To: ccw@charlie.oz Cc: munnari!TOPS20%SU-SCORE.ARPA@seismo.CSS.GOV, Hendry@UTAH-20.ARPA In-Reply-To: <104.518426789@charlie> Message-Id: <12214024174.26.HENDRY@UTAH-20.ARPA> At last---the package for you should go out with this afternoon's or tomorrow morning's AirBorne Express. We have gone 8 and 1/2 months with no secretary and the office is in a dreadful state. We finally got a new secretary just a month ago, and she is making good progress in helping us crawl out of the very deep hole we are in. Trying to run an installation with 1000 users on a DEC-20/60 + 2 VAX 750's + 2 PDP-11/60's with a staff of 2 and a part-time student operator is frankly ridiculous, but that is what we have to do here. Another 750 is going online to the San Diego Cray this week, and in August, a VAX 8600 will be installed; for this we get 0 extra help! --Nelson H.F. Beebe (aka HENDRY@UTAH-20) P.S. One effect of the Cray VAX connection should be direct ARPA mail access to me sometime this summer. ------- 13-Jun-86 00:44:55-PDT,1789;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Jun 86 00:44:42-PDT Date: Thu, 12 Jun 1986 22:46 MDT Message-ID: From: WANCHO@SIMTEL20.ARPA To: TOPS-20@SU-SCORE.ARPA Subject: MICOM-600 connections The correct solution is to set the thumbwheel switch to 9 and set the -20 ports to REMOTE with the appropriate jumper cut on each port for a modem connection. My thanks to all who replied. That solved the first problem. The second now involves selecting the optimum flow control option. This is required because there's a pair of COMDESIGN TC500A stat muxes on a four-wire 9.6 KBPS circuit in between the MICOM-600 and the -20, and all the channels and ports must be configured to run at 9.6 KBPS. There are four choices: 1. NONE, which naturally results in lost characters, 2. XON/XOFF in either or both directions, which disallows "xmodem" style file transfers, and the users lose ^S/^Q transparency, which I would like to avoid if at all possible, 3. DTR-busy, which is *might* be a possibility, but only by cheating and swapping some more pins around, and is similar to... 4. CTS/RTS control. This looks like the one. We looked in the DH-11 manuals and couldn't find any evidence that CTS was honored. But, we tried that option anyway. The result was that the MICOM line side didn't respond to my wakeup on the one channel/port I use as a "dialout" and we couldn't test further at that time. So, the question is: does the front end honor CTS for flow control on output from the -20 and does it exert RTS (or some other signal - which one) on input to the -20 when the -20 port is configured REMOTE? Is there a "better" way? --Frank 13-Jun-86 07:51:23-PDT,791;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Fri 13 Jun 86 07:51:01-PDT Date: Fri 13 Jun 86 09:52:49-CDT From: Clifford A. Wilkes Subject: Laserwriter output To: tops20@SU-SCORE.ARPA Department: Computation Center - A20/R20 staff Message-ID: <12214500068.44.CC.WILKES@R20.UTEXAS.EDU> Has anyone written a driver to allow terminal output to be directed through the printer port to an Apple Laserwriter? We have a number of users with such printers and they would like to be able to get Scribe output printed on them. We have a program to accomplish this for Diablo printers but it is very old and very poorly documented. Any help would be appreciated. Thanks in advance. <@> ------- 15-Jun-86 03:15:39-PDT,1458;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 15 Jun 86 03:15:30-PDT Date: Mon 16 Jun 86 03:16:16-PDT From: Mark Crispin Subject: I NEED A LAWYER To: SU-BBoards@SUMEX-AIM.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA, G.Gorin%LOTS-A@SUMEX-AIM.ARPA, SSRG@SUMEX-AIM.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12215236155.11.CRISPIN@SUMEX-AIM.ARPA> Saturday (14 June) night at about 11:00PM, I had the misfortune of being hit by a drunk driver. Neither I nor my passenger appear to have been injured beyond bruises, but my BMW was demolished. The other driver was tested by the police, found to be drunk, and hauled away to the county jail in handcuffs. The loss of my car is going to cause me serious inconvenience, as well as ruining my vacation plans. I do not wish to accept any insurance company settlement until after I have talked it over with a lawyer to see if my interests would be better served by seeking redress in the courts. I am interested in recommendations for a *good* lawyer who specializes in torts involving damages caused by a drunk driver. If you have had a similar "experience" and have any recommendations for or against a particular lawyer, I would appreciate getting mail. If there is any interest I will summarize the results to BBoard. ------- 15-Jun-86 07:50:59-PDT,1758;000000000000 Return-Path: Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Sun 15 Jun 86 07:50:54-PDT Date: Sun 15 Jun 86 07:48:27-PDT From: Frank Chen Subject: Re: I NEED A LAWYER To: Crispin@SUMEX-AIM.ARPA cc: SU-BBoards@SUMEX-AIM.ARPA, SU-TOPS-20@SU-SCORE.ARPA, G.Gorin%LOTS-A@SUMEX-AIM.ARPA, SSRG@SUMEX-AIM.ARPA In-Reply-To: Message from "Mark Crispin " of Sun 15 Jun 86 03:15:37-PDT Also-known-as: IZZY087%UCLAVM.BITNET@WISCVM Telephone: (213) 824-5706 You are certainly taking the right step in not settling right away. An insurance company is likely to give you only the value of the car, if it is considered "totaled", or less (like offering to repair) if it is only considered "major" damage (which of course hardly makes you whole). However, the law in California (under Taylor v. Superior Court) is that, if the other party was a drunk driver, you can collect punitive damages in addition to the value of your BMW and its loss of use, even if you suffered no physical injuries. I am currently working on a similar case here in LA. Now, whether the other party has insurance is another matter (you might not be able to collect). But note that if you do choose to sue, it may take up to two years to get to court if you sue in Municipal Court (for claims under $25,0000) or five years if you sue in Superior Court. As for choosing a lawyer, I think many plaintiff's lawyers are considered "good" or "successful" merely because they happen to have handled a few very good cases resulting in a large damages award... not necessarily reflecting their talents and abilities as a lawyer. In any case, I wish you luck in finding one. Frank ------- 16-Jun-86 17:39:26-PDT,945;000000000000 Return-Path: <@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 16 Jun 86 17:39:01-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2696804464218969@MIT-MULTICS.ARPA>; 16 Jun 1986 20:21:04 edt Date: 16 Jun 86 19:29 +0200 From: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: Laserwriter output Message-ID: <181062@QZCOM> In-Reply-To: <12214500068.44.CC.WILKES@R20.UTEXAS.EDU> We have a program TPRINT written in assembly that is reasonably well documented. It is designed mainly for VT100 etc type terminals, but I think is compatible with a number of other types. 18-Jun-86 06:17:42-PDT,576;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 18 Jun 86 06:17:26-PDT Date: Wed 18 Jun 86 09:17:10-EDT From: Ken Rossman Subject: Dual-port TU78's, TOPS-20, and Ultrix To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12215793376.285.SY.KEN@CU20B.COLUMBIA.EDU> Does anyone out there know for sure if TU78's can be dual-ported between a TOPS-20 system and an Ultrix (VAX 86xx) system without problems? ------- 18-Jun-86 07:29:40-PDT,798;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jun 86 07:29:11-PDT Date: Wed 18 Jun 86 08:27:43-MDT From: Randy Frank Subject: Re: Dual-port TU78's, TOPS-20, and Ultrix To: sy.Ken@CU20B.COLUMBIA.EDU, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12215793376.285.SY.KEN@CU20B.COLUMBIA.EDU> Message-ID: <12215806219.9.FRANK@UTAH-20.ARPA> that is our exact configruation: we have two tu78s on one dual ported TM78 between a DEC-20 and an 8600 (Unix 4.3). We regularly run with one tu78 switched to the 20 and one to the 8600 w/o problems. Neither system cares to which system the drive(s) are switched when they are booted, either. We NEVER run with the drives in the dual port position (A/B) for obvious reasons. ------- 18-Jun-86 09:11:10-PDT,726;000000000000 Return-Path: Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jun 86 09:10:46-PDT Date: 18 Jun 1986 09:10 PDT (Wed) Message-ID: From: Peter King To: Ken Rossman Cc: TOPS-20@SU-SCORE.ARPA Subject: Dual-port TU78's, TOPS-20, and Ultrix In-reply-to: Msg of 18 Jun 1986 06:17-PDT from Ken Rossman Yes. I know for sure that a TU78 can be dual ported between a TOPS-20 and an Ultrix (Unix) system without problems. Just don't try to have them both access the tape at the same time. This can be managed with people rather than software. Peter King 19-Jun-86 09:13:40-PDT,962;000000000001 Return-Path: <@MIT-MULTICS.ARPA:Peter_Lothberg_STUPI@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jun 86 17:12:40-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2696974135434865@MIT-MULTICS.ARPA>; 18 Jun 1986 19:28:55 edt Date: 18 Jun 86 20:06 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: Dual-port TU78's, TOPS-20, and Ultrix Message-ID: <181650@QZCOM> In-Reply-To: <12215793376.285.SY.KEN@CU20B.COLUMBIA.EDU> We have dual.ported a TU78 between Tops-10 and Vms, and it works. TU78 is the only tape drive that can be shared between a 36 and a 32 bit machine. (Without swapping boards) 19-Jun-86 19:45:41-PDT,964;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Jun 86 19:45:17-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 19 Jun 86 19:43:32-PDT Date: Thu 19 Jun 86 18:49:29-PDT From: Mark Crispin Subject: Re: Dual-port TU78's, TOPS-20, and Ultrix To: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA In-Reply-To: <181650@QZCOM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12216192474.11.MRC@PANDA> Peter, That isn't quite true, you can share a TU72 between a VAX and a PDP-10. At Anaheim DECUS (the last US DECUS any 36-bit iron appeared at), they were demonstrating this at an otherwise desolate LSM booth. -- Mark -- ------- 20-Jun-86 09:34:52-PDT,1047;000000000001 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Fri 20 Jun 86 09:26:22-PDT Date: 20 Jun 86 12:27:19 EDT From: Beth Subject: Migration from TOPS-20 to UNIX To: tops-20@SU-SCORE.ARPA, unix-wizards@BRL.ARPA cc: binde@RED.RUTGERS.EDU Message-ID: <12216352279.3.BINDE@RED.RUTGERS.EDU> It looks as if we will be unplugging two of our TOPS-20 systems and moving the users to UNIX (on a Pyramid 90X). We don't expect to be able to run the machines concurrently for more than a month or so, and we'd like to be able to read DUMPER tapes on the UNIX system to migrate user files. Could anyone give us a pointer to a program that does this? Or to other ways to accomplish the same thing? Since I don't normally read this newsgroup, I would appreciate it if you could reply directly to me. (I will summarize the replies for anyone who is interested.) Thank you. ARPA: BINDE@RUTGERS.RED.EDU UUCP: {seismo,allegra,ihnp4,shasta}!topaz!binde ------- 20-Jun-86 11:38:48-PDT,686;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Jun 86 11:38:19-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 20 Jun 86 11:37:45-PDT Date: Fri 20 Jun 86 11:35:46-PDT From: Mark Crispin Subject: questionable change in IPIPIP To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12216375663.7.MRC@PANDA> In Autopatch 12 or 13, SNDPNG-5 was changed to CAIE T4,GW%DUM. I am a bit dubious of this change, although Bill Melohn is generally reliable. Anybody want to comment about this change? ------- 21-Jun-86 19:52:17-PDT,1452;000000000000 Return-Path: Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Sat 21 Jun 86 19:51:58-PDT Date: 21 Jun 86 22:53:13 EDT From: Charles Hedrick Subject: changes at Rutgers To: tops-20@SU-SCORE.ARPA Message-ID: <12216728364.17.HEDRICK@RED.RUTGERS.EDU> A recent message from Beth Binde may have left some readers wondering whether I have taken leave of my senses. No, we are not replacing two DEC-20's by one Pyramid 90x. In fact, we are replacing our instructional DEC-20 by a Pyramid 98x (an upgrade of our existing Pyramid 90x) and a group of Suns, and our general-access University DEC-20 by a Pyramid 98xe and 1.5 VAX 8650's running VMS. (The other .5 8650 will replace a 780.) Our oldest DEC-20, RED.RUTGERS.EDU, is likely to stay for a bit longer. (It is the CS Dept's research machine.) As long as we have any DEC-20's, I will attempt to prevent Pascal, Elisp and Common Lisp from succumbing to software rot. (Although we still distribute SAIL, its user base seems to have slowly vanished, except at NIH in Bethesda.) However no new development work is planned for Rutgers DEC-20 software once the current spate of Common Lisp work is finished. Currently we plan to stabilize on TOPS-20 5.4. If anyone is prepared to tell us that some new version of the system is getting at least as good performance as 5.4, I would reconsider that decision. ------- 23-Jun-86 10:40:10-PDT,1202;000000000000 Return-Path: Received: from sun.com by SU-SCORE.ARPA with TCP; Mon 23 Jun 86 10:39:50-PDT Received: from snail.sun.com (snail-ptp) by sun.com (3.2/SMI-3.0) id AA10940; Mon, 23 Jun 86 10:41:13 PDT Received: from sluggo.sun.uucp by snail.sun.com (3.2/SMI-3.2) id AA28044; Mon, 23 Jun 86 10:41:40 PDT Received: by sluggo.sun.uucp (1.1/SMI-3.0DEV3) id AA01051; Mon, 23 Jun 86 10:39:15 PDT Date: Mon, 23 Jun 86 10:39:15 PDT From: melohn@SUN.COM (Bill Melohn) Message-Id: <8606231739.AA01051@sluggo.sun.uucp> To: TOPS-20@SU-SCORE.ARPA Subject: Re: questionable change in IPIPIP If I recall from my "generally reliable" memory, the change Mark mentions changed the kind of pings sent to HOST gateways. Previously, ECHO pings were sent only to PRIME gateways, and ECHO-REPLIES to HOST and DUMB gateways. This change made TOPS-20 send ECHOs to PRIME and HOST gateways, and ECHO-REPLIES to DUMB gateways. If you don't like the new behavior, you can defeat it by changing any defined HOST gateways (in the INTERNET.GATEWAYS file) to DUMB gateways. Unless you have a TOPS-20 -> CI -> TOPS-20 -> inet IP gateway, you should probably never notice or need this change. 23-Jun-86 14:09:37-PDT,413;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 23 Jun 86 14:08:58-PDT Date: Mon 23 Jun 86 16:37:15-EDT From: Ittai Hershman Subject: TOPS-20 NFS? To: Tops-20@SU-SCORE.ARPA Message-ID: <12217184211.167.NYU.ITTAI@CU20B.COLUMBIA.EDU> Are there any implementations of NFS for TOPS-20 out there? -Ittai ------- 24-Jun-86 00:48:02-PDT,892;000000000000 Return-Path: Received: from su-sierra.arpa by SU-SCORE.ARPA with TCP; Tue 24 Jun 86 00:47:35-PDT Date: Tue 24 Jun 86 00:48:05-PDT From: Stu Grossman Subject: Re: TOPS-20 NFS? To: NYU.ITTAI@CU20B.COLUMBIA.EDU cc: Tops-20@su-score.arpa In-Reply-To: <12217184211.167.NYU.ITTAI@CU20B.COLUMBIA.EDU> Message-ID: <12217306333.11.GROSSMAN@su-sierra.arpa> Wishful thinking. Actually, the real question should be: "Are there any Unixes with reasonable file systems?" By the way, TOPS-20 already has a network file system. It's called CFS. It only works between homogenous systems, (the same is true of NFS). It also does a pretty good job of preserving the semantics of the file system (this is not true of NFS). Currently, it only works over the CI (not true of NFS), but that could be changed. Stu Grossman ------- 25-Jun-86 07:07:22-PDT,3463;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Wed 25 Jun 86 07:06:45-PDT Received: from philabs.UUCP by seismo.CSS.GOV with UUCP; Wed, 25 Jun 86 09:17:40 EDT Received: by philabs.uucp (4.12/3.14) id AA12601; Wed, 25 Jun 86 08:07:09 edt Date: Wed, 25 Jun 86 08:07:09 edt From: Return-Path: Message-Id: <8606251207.AA12601@philabs.uucp> To: philabs!seismo!TOPS-20@SU-SCORE.ARPA Cc: rick@seismo.CSS.GOV Subject: Re: TOPS-20 NFS? In-Reply-To: Message from Stu Grossman at Wed Jun 25 03:42:30 1986 Comments on Stu Grossman's filesystem observations: > Actually, the real question should be: "Are there any Unixes with reasonable > file systems?" The UNIX filesystem ain't so bad. The TOPS-20 filesystem feature I miss most on UNIX is PMAP. Given the diversity of hardware implementations UNIX runs on, however, it's not surprising there's no PMAP tho'. One place where UNIX wins big over TOPS-20: ease of creating, deleting, and referencing subdirectories (WHY can't I say <.BAR> to reference the directory BAR that is immediately inferior to my connected directory? Even VMS got this one right!). > By the way, TOPS-20 already has a network file system. It's called CFS. It > only works between homogenous systems, (the same is true of NFS). Not true. NFS operates in a heterogeneous environment of host CPUs, networks, and operating systems. Although NFS supports most UNIX filesystem semantics, it is not restricted to UNIX environments (e.g., there exists a DOS implementation of NFS). > [CFS] also > does a pretty good job of preserving the semantics of the file system (this is > not true of NFS). *Which* filesystem? NFS does a pretty good job of preserving the semantics of the UNIX file system. Apparently, many vendors share this view, as there is a growing list of vendors who have licensed NFS technology from Sun Microsystems for their products. > Currently, it only works over the CI (not true of NFS), but > that could be changed. CFS relies heavily upon two characteristics of the CI: its speed and reliability. Were a slower and/or less reliable network connection (say, a non-local-area Internet link) to be substituted for the CI, the performance of CFS would suffer severely, to the point where the gains of CFS would be outweighed by the poor performance. NFS performance is also impaired by a slower network connection, but only the performance of the client host suffers. NFS is far more robust than CFS in coping with intermittent failures of the hardware link between hosts; there is no UNIX or NFS analog of the CFRECN BUGHLT. Oh yes, you can license a C language implementation of NFS from Sun Microsystems. As -20s give way to newer iron, this becomes very attractive. ----- Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 ARPA: philabs!nyit!rick@SEISMO.ARPA UUCP: {decvax,seismo}!philabs!nyit!rick DISCLAIMER: I neither work for nor am affiliated with either Digital Equipment Corp. or Sun Microsystems. The opinions expressed above represent my own views and not necessarily those of my employer. No claims are made to the accuracy of any information contained herein. 25-Jun-86 07:24:51-PDT,4334;000000000000 Return-Path: Received: from sun.com by SU-SCORE.ARPA with TCP; Wed 25 Jun 86 07:24:13-PDT Received: from snail.sun.com (snail-ptp) by sun.com (3.2/SMI-3.0) id AA19457; Wed, 25 Jun 86 07:25:43 PDT Received: from opus.sun.uucp by snail.sun.com (3.2/SMI-3.2) id AA11710; Wed, 25 Jun 86 07:26:20 PDT Received: by opus.sun.uucp (3.2/SMI-3.2) id AA00378; Wed, 25 Jun 86 07:23:07 PDT Date: Wed, 25 Jun 86 07:23:07 PDT From: gingell@SUN.COM (Rob Gingell) Message-Id: <8606251423.AA00378@opus.sun.uucp> To: GROSSMAN@su-sierra.arpa, NYU.ITTAI@CU20B.COLUMBIA.EDU Subject: Re: TOPS-20 NFS? Cc: Tops-20@su-score.arpa Ittai Hershman asks (>>): >>Are there any implementations of NFS for TOPS-20 out there? None of which I'm aware. Stu Grossman replies (>): >Wishful thinking. Perhaps. >Actually, the real question should be: "Are there any Unixes with reasonable >file systems?" This is certainly a question, though it is not clear it is relevant to the concerns that Ittai has. By the way, what is a "reasonable file system"? I concede the example that "TOPS-20 has a reasonable file system". But, I don't want an example of a reasonable file system, I want to know what qualities make a reasonable file system, and which of these you're claiming that UNIX lacks. >By the way, TOPS-20 already has a network file system. It's called CFS. It >only works between homogenous systems, (the same is true of NFS). It also >does a pretty good job of preserving the semantics of the file system (this is >not true of NFS). Currently, it only works over the CI (not true of NFS), but >that could be changed. There is a misconception buried in here, namely that NFS is a "UNIX file system". NFS is a "network file system" of which UNIX can be a client. It is not intended to be a "networked UNIX file system". It certainly has UNIX-like attributes, a product of its heritage and likely environs, but it also consciously NOT UNIX-like in areas which were thought to be UNIX-specific. The statement that NFS works only between homogenous systems is false: there are existence proofs of both hardware and software heterogeneity: NFS on MS-DOS (obviously different hardware too) NFS on different hardware architectures running UNIX Some will claim that there is an NFS server running on VMS -- I've avoided listing it above simply to avoid getting into a semantic argument over it, since presently it is implemented by running a UNIX NFS server program on top of Eunice on top of VMS. There will certainly never be, nor could there be, such examples for CFS. Stu says the NFS does not run over the CI. True. But NFS does not run over hardware, it runs over "transports" like UDP/IP. Seems to me that IP runs over the CI... And sure, you could change CFS to run over something other than SCA and CI-based protocols -- it's only software after all. But the code wasn't written to do that in 6.1, so you're going to be making a lot more severe change to CFS to have it run over Ethernet than you will to port NFS to TOPS-20. Is NFS better than CFS? Is an apple better than an orange? Both questions are meaningless without a qualifying "for what?" CFS provides a distributed TOPS-20 file system, and if that's what Ittai needs, then CFS is what he should use. When I had a cluster of 20's, that's what I used and if I had the same configuration again, I'd use CFS in preference to NFS because it is a better solution for that specific configuration. If Ittai needs to have a lot of different systems (or, just one non-TOPS-20 system) sharing a common file name space, then NFS solves (or potentially solves) his problem in ways CFS never will or even could. I suspect if he needed a distributed TOPS-20 file system he'd be using CFS and not have asked the question in the first place. But, getting back to Ittai's original question. No, there's not an NFS for TOPS-20. Adding it would be a non-trivial job, but depending on what you wanted to do it might be a relatively contained task. So, Ittai, what is it you would use an NFS on TOPS-20 for if you had it? Would it just be a server? Client and server? Would client have to be transparent (i.e., would you be willing to run a "NFS 'ftp'")? - Rob 25-Jun-86 09:58:36-PDT,502;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 25 Jun 86 09:58:15-PDT Rick Ace sez: > and referencing subdirectories (WHY can't I say <.BAR> to reference the ReSent-Date: Wed 25 Jun 86 09:58:46-PDT ReSent-From: Bob Knight ReSent-To: tops20@SU-SCORE.ARPA ReSent-Message-ID: <12217668725.20.KNIGHT@SRI-NIC.ARPA> Well, with some rather trivial modifications that Stanford made, you have that capability and more. Bob 25-Jun-86 12:57:19-PDT,780;000000000000 Return-Path: Received: from portia.stanford.edu by SU-SCORE.ARPA with TCP; Wed 25 Jun 86 12:56:48-PDT Received: by portia.stanford.edu; Wed, 25 Jun 86 13:05:38 PDT Date: 25 Jun 1986 1305-PDT (Wednesday) From: Paul Hegarty To: Cc: hegarty@portia.stanford.edu, SU-TOPS-20@score.stanford.edu Subject: Re: TOPS-20 NFS? In-Reply-To: / Wed, 25 Jun 86 08:07:09 edt. <8606251207.AA12601@philabs.uucp> At Stanford, we have added the capability to access subdirectories by the <.BAR> convention (including <..>). This make TOPS-20 somewhat more flexible, but still doesn't allow names equivalent to "../../foo". ... Paul 26-Jun-86 17:55:52-PDT,1162;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 26 Jun 86 17:55:33-PDT Date: Thu 26 Jun 86 20:51:02-EDT From: Ittai Hershman Subject: Re: TOPS-20 NFS? To: gingell@SUN.COM cc: GROSSMAN@SU-SIERRA.ARPA, Tops-20@SU-SCORE.ARPA In-Reply-To: <8606251423.AA00378@opus.sun.uucp> Message-ID: <12218016843.9.NYU.ITTAI@CU20B.COLUMBIA.EDU> My systems are down for AC work, so I can only respond to the mail I was CC'ed on: Stu's and Rob's. My interest in NFS was as a multi-OS soultion (as Rob suspected). More specifically, we are starting to think about integrating the 300+ PC's we have with our timesharing systems. With the introduction of MS-DOS/NFS, a PC could potentially became an adequate "workstation" for many of our users. I do not know enough about NFS to flame, but it seems like a good mechanism for what I'd like to see... Quite simple actually. If the rest of you have the energy to continue, I am sure I could learn a lot from the flaming. If not, I guess It isn't a solution (yet, anyway) I could use at NYU. Thanx, -Ittai ------- 1-Jul-86 14:35:32-PDT,1210;000000000000 Return-Path: Received: from MCC.COM by SU-SCORE.ARPA with TCP; Tue 1 Jul 86 14:33:51-PDT Date: Tue 1 Jul 86 16:34:15-CDT From: Clive Dawson Subject: KNIPPE (a.k.a. KNICAE) BUGINF's To: tops20@SU-SCORE.ARPA Reply-To: Clive@MCC Message-ID: <12219291740.45.AI.CLIVE@MCC.COM> For many months now our NI Ethernet interface has been halting every day or two with a so-called "planned parity error", which is the NI's method of issuing a bug report. Under TOPS-20 5.4, it was reported via a KNIPPE as error number 7757. Version 6.1 issues a separate BUGINF for each error, and provides more information about what's going on. The explanation for error 7757 is that the NI had to wait more than 50 microseconds for access to the CBUS. Has anybody else seen this problem? The DDC hardware people have not uncovered anything, and say this doesn't look like a hardware problem. A bad side effect of this (perhaps fixed in 6.1?) is that when the NI halts and has to be reloaded via KNILDR, there is about a 1 in 3 chance of crashing due to messed up internet free space blocks. Any help or pointers would be appreciated. Thanks, CLive ------- 1-Jul-86 16:35:10-PDT,800;000000000000 Return-Path: Received: from su-sierra.arpa by SU-SCORE.ARPA with TCP; Tue 1 Jul 86 16:34:48-PDT Date: Tue 1 Jul 86 16:14:24-PDT From: Stu Grossman Subject: Re: KNIPPE (a.k.a. KNICAE) BUGINF's To: Clive@MCC.ARPA cc: tops20@su-score.arpa In-Reply-To: <12219291740.45.AI.CLIVE@MCC.COM> Message-ID: <12219309971.14.GROSSMAN@su-sierra.arpa> There is an ECO which addresses this problem (CBUS timeouts). You should have Field Service make sure that the KLIPA boards for the NI are all up to the highest rev level. Also, 6.1 should solve the problem with KNILDR causing Internet related crashes. As a temporary work around, you could get away with disabling the routine in IPIPIP that deals with the NI going down. Stu ------- 2-Jul-86 08:16:53-PDT,3955;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 2 Jul 86 08:16:17-PDT Date: Wed 2 Jul 86 11:15:09-EDT From: Thomas De Bellis Subject: Columbia PTYCON available on SCORE To: Tops-20@SU-SCORE.ARPA Message-ID: <12219484870.35.SY.SLOGIN@CU20B.COLUMBIA.EDU> We have been doing some heavy EXEC development here at Columbia as of late. Part of the work involves merging some 6.1 EXEC features into our (very modified) EXEC working sources. This occasionally involves testing a not-logged-in EXEC, and as you all know, that can be a pain. As things stand, it usually means that you have to take system time and either redefine DEFAULT-EXEC: or copy the EXEC into the SYSTEM directory. You have to worry about setting everything back, getting the system or hoping the nobody logs in. Alternatively, you might write some hack to CRJOB up something and then attach to it. This is kind of annoying. What we wanted was a cheap way to fire up a not-logged-in EXEC and then be able to easily play with it. Since we had seen BATCON change from the old way of logging things in (^C to the PTY to get MEXEC to fire up a job) to the new way of logging things in (rolling its own with a CRJOB% for better error recovery), we took a cue and decided to follow suit and insert similiar functionality into PTYCON. A new PTYCON source is on SCORE for ANONYMOUS access in PS:. It is the result of several copies of PTYCON being merged, plus some additional features added to facilitate EXEC development (without adversely affecting normal system usage). If any of you are doing EXEC development or just want to have a nice PTYCON, we'd like you to play around with it and report any bugs you find to us. Here is a brief list of highlights of the new version: - Upper / lowercase input has been enabled. This enables you to send lower case input to a subjob directly from command level. - World famous CUCCA mode line flashing hack has been re-installed. This causes your screen to flash instead of a bell beeping when using certain terminals. Good for late nights. - Buffering problem under high loads has been fixed. PTYCON would occasionally lose output under high loads. - Added help files. These help files are fairly extensive, and replace a formerly unfunctional utility. - Flow control switches have been added. This allows you to use EMACS or any other programs which require ASCII ^S or ^Q to be sent. - Allow a clean startup after an EXIT. The program no longer blows up after being restarted, allowing it to be a kept fork. - Added a NO PUSH command to kill the previous EXEC fork. This is a very nice feature for working with new EXEC's on PUSH's since the EXEC is now kept by default. - Added some more valid ESCAPE characters. Now you may use any of 16 different escape characters (there were formerly 11). It parses for escape characters somewhat more cleanly, now. - Added CTRL-H error recovery in the COMND interface. There was a bug that prevented parse errors for being retried. - Much nicer error recover so you don't lose all your subjobs if it blows up. - Added /SLOGIN: switch to the CONNECT command. This is taken from the Tops-10 OPSER :SLOGIN command. It logs you in fast without a fuss. - Added /TOP-LEVEL: switch to the CONNECT command. This allows you to load the top-level fork of an arbitrary job. Load something reasonable into a not-logged-in job, like SDDT and pretend you're using a REAL operating system. - Lots of other cutenesses too numerous to mention. We let the programmer have some fun. Again, please report any problems or suggestions to Sy.Chris and Sy.SLogin at CU20B. -- Tom De Bellis Columbia DEC20 Systems Group ------- 2-Jul-86 14:27:26-PDT,808;000000000000 Return-Path: Received: from ohio-state.ARPA by SU-SCORE.ARPA with TCP; Wed 2 Jul 86 14:26:31-PDT Return-Path: Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA08269; Wed, 2 Jul 86 17:25:41 edt Message-Id: <8607022125.AA08269@ohio-state.ARPA> Date: Wed 2 Jul 86 17:27:49-EDT From: Lum Johnson Subject: Wanted: VAX/VMS TCP/IP software To: TOPS-20%OSU-20@ohio-state.ARPA Another OSU site running VMS on a VAX-750 needs a TCP/IP implementation to hook into our ethernet. They don't have net access yet, so they'd like me to if anyone out there knows of a reasonable VAX/VMS TCP/IP implementation? Preferably less expensive than Wollongong (sp?). Thanks. Lum Johnson ------- 3-Jul-86 08:22:33-PDT,1470;000000000000 Return-Path: <@WISCVM.ARPA,@WESLEYAN.BITNET,@VAX.WESLYN:SST.D-BIGELOW@KLA.WESLYN> Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Thu 3 Jul 86 08:22:16-PDT Received: from (MAILER)WESLYN.BITNET by WISCVM.ARPA on 07/03/86 at 10:23:07 CDT Received: from KLA.WESLYN by VAX.WESLYN 3-JUL-1986 11:20:20.28 Date: Thu, 3 Jul 1986 11:18 EDT Message-ID: From: Douglas Bigelow To: Lum Johnson Cc: TOPS-20@SU-SCORE.ARPA Subject: Wanted: VAX/VMS TCP/IP software In-reply-to: Msg of 2 Jul 1986 17:27-EDT from Lum Johnson By now you've probably heard several plugs for VMS TCP/IP from Tektronix. Last I knew, their software was more or less free to universities, and you get source code too! To those of us who have had "differences" with Wollogong, TEK TCP has been a godsend. You'll find occasional references to TEK TCP on the INFO-VAX mailing list. There seem to be enough active software developers out there using it to make it worth a mailing list of its own. If we end up being the ones supporting the list, I'll add you to it (if you want.) If you need the name of the contact at Tektronix and haven't got it yet, please send me mail directly. (I don't want to post the guy's name to the whole world without getting his permission first.) -- Doug Bigelow 6-Jul-86 08:32:37-PDT,870;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 6 Jul 86 08:32:22-PDT Date: Sun, 6 Jul 1986 09:33 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SU-SCORE.ARPA Subject: CMD Package improvements Over the years it seems that DEC's CMD package has served utility programmers quite well. It also seems that several of you have made improvements to the package, especially in the area of error handling. I already have Vince Fuller's, which comes with his FTPSRT and another by Peter Gergeley. I'd like to collect other versions which may be lurking in your systems for a possible merge. If you have a favorite version, send me a pointer to an FTPable location or just send me a REDIT file if your copy is not on a net host. --Frank 8-Jul-86 09:25:36-PDT,740;000000000000 Return-Path: Received: from ohio-state.ARPA by SU-SCORE.ARPA with TCP; Tue 8 Jul 86 09:25:19-PDT Return-Path: Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA06684; Tue, 8 Jul 86 11:24:32 edt Message-Id: <8607081524.AA06684@ohio-state.ARPA> Date: Tue 8 Jul 86 11:25:32-EDT From: Lum Johnson Subject: Re: Wanted: VAX/VMS TCP/IP software To: SST.D-BIGELOW@KLA.WESLYN%Wesleyan.Bitnet%WISCVM.ARPA Cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Douglas Bigelow" of Tue 8 Jul 86 11:23:39-EDT No, actually, your's is the second reply I've received, other than those requesting a summary of replies. Thanks! Lum ------- 9-Jul-86 11:54:26-PDT,676;000000000000 Return-Path: <@CSNET-RELAY.ARPA,@BU-CS.BU.EDU:jsol@BUIT1.BU.EDU> Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Jul 86 11:53:39-PDT Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id aa03643; 9 Jul 86 14:37 EDT Received: by bu-cs.bu.edu (5.31/4.7) id AA23149; Wed, 9 Jul 86 12:51:49 EDT Return-Path: Received: by buit1.bu.edu (5.31/4.7) id AA09509; Wed, 9 Jul 86 12:51:25 EDT Date: Wed, 9 Jul 86 12:51:25 EDT From: Jon Solomon Message-Id: <8607091651.AA09509@buit1.bu.edu> To: TOPS20@SU-SCORE.ARPA Subject: DX Has anyone heard of DX which is billed as a document transfer program? Thanks, --jsol 10-Jul-86 11:36:39-PDT,499;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jul 86 11:36:21-PDT Date: Thu 10 Jul 86 14:19:38-EDT From: Donna Lynch Subject: AMAR To: tops-20@SU-SCORE.ARPA cc: admin@RADC-TOPS20.ARPA Message-ID: <12221615605.6.ADMIN@RADC-TOPS20.ARPA> DEC didn't convert AMAR to 6.1, but did release the sources to the DECUS library. Has anyone fixed it to work for 6.1? Are you willing to share your code? ------- 10-Jul-86 20:32:10-PDT,577;000000000001 Mail-From: BILLW created at 10-Jul-86 20:32:00 Date: Thu 10 Jul 86 20:32:00-PDT From: William "Chops" Westfield Subject: dumper... To: tops20@SU-SCORE.ARPA Message-ID: <12221716160.24.BILLW@SU-SCORE.ARPA> I just noticed that Stanford is using a rather old version of DUMPER, due to our reaction to some of the bad versions of DUMPER that came out with the 6.1 field test tapes. Have all the problems been ironed out? Will the latest version of DUMPER work with older monitors, older tapes, and so on an so worth? Thanks Bill W ------- 11-Jul-86 07:29:30-PDT,2270;000000000001 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 11 Jul 86 07:29:18-PDT Date: Fri 11 Jul 86 10:30:31-EDT From: Thomas De Bellis Subject: Re: dumper... To: BILLW@SU-SCORE.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: <12221716160.24.BILLW@SU-SCORE.ARPA> Message-ID: <12221836040.35.SY.SLOGIN@CU20B.COLUMBIA.EDU> Ah... Welcome to the DUMPER club! DUMPER is a big ugly mess--we are devoting a whole staff member's time to cleaning it up this summer before we stop doing active development work on our 20's. The version of DUMPER that we run right now is a variant of V402 which was what we ran under 5.1. That had a lot of efficiency hacks, some of which you may remember as coming from Case Western Reserve University. I believe I posted this DUMPER to Tops-20 back in late '83 or '84. So, what's going on? Well, we have about 7 versions of DUMPER that we are in the process of checking out and merging. We are using as our base the latest DUMPER that was shipped with 6.1. The only 6.1 specific things that come to mind are all the encryption changes that allow DUMPER to create directories without the Tops-20 encryption algorythm being applied. You really need that if you're doing encryption (which we think about every 3 or 4 months). Off the top of my head, I believe that 6.1 DUMPER will run on a 5 series system--it checks to see if it is on a 6 series monitor. The tape format is still compatible or it does checking. They did a lot of hacking on the archival stuff. You may need to recompile it with your Galaxy to get the archival code to talk to a modified Quasar. You have my condolences if you are running that unmentionable, abominable archival system. We're fixing up some bugs, cleaning some gawd-awful code and experimenting with being able to write save sets to arbitrary devices (disks, ethernet) instead of just mag tapes. This should look something like what we did to PTYCON (ie, take a crock and make it nice and wizzy) only it's a lot more work. We're probably going to leave DUMPER alone after that. Expect to hear something from us by late August or early September. -- Tom ------- 13-Jul-86 13:24:28-PDT,694;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sun 13 Jul 86 13:24:15-PDT Date: Sun 13 Jul 86 16:29:18-EDT From: Betsy Ramsey Subject: Re: AMAR To: ADMIN@RADC-TOPS20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: <12221615605.6.ADMIN@RADC-TOPS20.ARPA> Company: American Mathematical Society Message-ID: <12222425642.15.EWR@XX.LCS.MIT.EDU> DEC did release the V5.1 version of AMAR-20 to the DECUS Library. They also sent it out of house for upgrading to V6.1, and the new version is in beta test right now (we're a test site). I don't know what DEC's policy will be re- garding the upgraded version. ------- 13-Jul-86 16:55:29-PDT,1180;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Jacob_Palme_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Jul 86 16:55:17-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699134774312692@MIT-MULTICS.ARPA>; 13 Jul 1986 19:39:34 edt Date: 13 Jul 86 13:47 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: International character set Message-ID: <187463@QZCOM> In-Reply-To: <12208783264.6.MRC@PANDA> In the future, 8-bit character sets are going to be used and supported more and more, but the transition will be slow. In fact, my personal belief is that the transition to 8-bit sets is what will finally kill TOPS-10 and TOPS-20, since even if these systems theoretically could be rewritten for 8-bit character set, such a large amount of software would have to be rewritten that this will probably not occur without support from DEC. 13-Jul-86 18:51:57-PDT,2171;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Jul 86 18:51:46-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 13 Jul 86 18:44:15-PDT Date: Sun 13 Jul 86 17:53:58-PDT From: Mark Crispin Subject: Re: International character set To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <187463@QZCOM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12222473824.6.MRC@PANDA> The PANDA monitor (running on PANDA, SIMTEL20, STL-HOST1, and DREA-XX) already has some initial support for the DEC 8-bit international character set. One of the three hardwired terminals connected to PANDA is a VT220 clone which is run in VT220 native 8-bit mode. PANDA is committed to handling the DEC 8-bit character set, or whatever international standard comes up to replace 7-bit ASCII. We actually would argue for a 9 or 12 bit character set, but we all know those pooor braindead VAXen couldn't cope with such a concept so... In any case, the PANDA 2020 is going to playing the mail game with other machines worldwide for some years to come. Whether or not TOPS-10/20 dies elsewhere all depends upon whether or not DEC puts TOPS-20 into the public domain in 1988 when development ends. If you are planning to run TOPS after 1988 (or even if you aren't but are "interested") and haven't made your feelings known to DEC about this yet, please do! If DEC will place TOPS (and all associated 36-bit software) in the public domain in 1988, TOPS stands a chance. We can all thank DEC for the great job they did in the past couple of decades, and allow other vendors a chance. Please don't flame at DEC on this! Since DEC wants out of 36-bits, just encourage them to get out, completely; and give them a pleasant "thank you". We all wish it could be otherwise, but right now it is too important to have TOPS in the public domain than to take out one's frustrations in flaming. -- Mark -- ------- 14-Jul-86 13:20:22-PDT,733;000000000000 Return-Path: Received: from su-sierra.arpa by SU-SCORE.ARPA with TCP; Mon 14 Jul 86 13:19:43-PDT Date: Mon 14 Jul 86 13:19:17-PDT From: Stu Grossman Subject: Re: International character set To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@su-score.arpa In-Reply-To: <187463@QZCOM> Message-ID: <12222685964.12.GROSSMAN@su-sierra.arpa> The latest version of Tops-10 will have full 8 bit character support for terminals. It works well enough so that you can actually use a VT240 in VT2xx mode reasonably. Stu ------- 15-Jul-86 05:21:24-PDT,1661;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Jul 86 05:21:12-PDT Date: Tue 15 Jul 86 07:57:43-EDT From: Donna Lynch Subject: AMAR To: tops-20@SU-SCORE.ARPA Message-ID: <12222856799.8.ADMIN@RADC-TOPS20.ARPA> ------------------------------------------------------------------------------- Date: 11 Jul 1986 1114-EDT From: Reed B. Powell To: Donna Lynch Large-Systems-Marketing: LCG Product Line Location: "297-4261 MRO2-2/3C (Pole 5A)" REPLY: "MARKET:: or MRVAX::" Subject: Re: AMAR Just a note on the status of AMAR, so that a lot of people don't spend a lot time doing what has already been done: We (DEC) found it very difficult to keep up the development of the AMAR product, and therefore put it into the DECUS library (5.1 version of AMAR), rather than continue it as a product. This caused a stir, to say the least. We have since entered into an agreement with another company to do the 6.1 and 7.03 AMAR development (as well as for all later versions of TOPS-10/20). Those versions will then be placed into the DECUS library as well. The 6.1 version of AMAR is currently in field test at two customer sites; work is to begin any day now for the TOPS10 V7.03 development. When the 6.1 version is deemed complete by the people at Systems Concepts doing the work for us, it will be put into the DECUS library. I will try to remember to let the INFO list know when that happens. -reed ------------------------------------------------------------------------------- ------- 16-Jul-86 18:06:02-PDT,1113;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Jan_Michael_Rynning@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Jul 86 18:05:20-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699386209953839@MIT-MULTICS.ARPA>; 16 Jul 1986 17:30:09 edt Date: 16 Jul 86 13:36 +0200 From: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Tops-20@SU-SCORE.ARPA Subject: Re: International character set Message-ID: <188365@QZCOM> In-Reply-To: <12222473824.6.MRC@PANDA> ISO is working on a 16-bit world-wide character set. I doubt we will ever see an 8-bit character set that replaces ASCII. There are too many national characters in languages based on the Latin alphabet, to squeeze them into 8 bits. 16-Jul-86 18:57:24-PDT,2430;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 16 Jul 86 18:57:04-PDT Date: Wed 16 Jul 86 15:10:49-EDT From: Betsy Ramsey Subject: AMAR To: TOPS20@SU-SCORE.ARPA Company: American Mathematical Society Message-ID: <12223197789.74.EWR@XX.LCS.MIT.EDU> This message is for those who read the recent mail concerning AMAR and were wondering what AMAR is. Quoting from the preface to the "AMAR-20 Reference Manual": The AMAR (Automatic Measurement, Analysis, and Reporting) software monitor looks at computer system performance and resource use on a continuous basis and maintains an historical database. It provides periodic reports which are useful for problem detection and analysis, load balancing, and capacity planning. Currently there are two parts to the AMAR software monitor -- System AMAR and Workload AMAR. System AMAR monitors the activity of the computer as a whole and the activity of individual devices such as tape drives and disk packs. Workload AMAR (also called the Workload System) monitors the corresponding activity of individual jobs. AMS has used AMAR for slightly over three years, and we find it to be a very useful tool. The data collection programs incur much less system overhead than does WATCH, and AMAR automatically rolls up the raw data into historical databases, allowing long-term tracking of system usage for capacity planning purposes, and generation of "typical day" reports. Its report generation tools are fairly flexible, especially in Workload AMAR. On the negative side, AMAR requires 22 snoop pages if you run MONMAX (the default is 12 pages). We had to eliminate some device support from the monitor in order to free up enough snoop pages. The data collection programs occupy from 3000 to 5000 pages on one of your permanently mounted structures, pages that some sites do not have readily available. (The historical files and most AMAR executables can reside on a non-permanently mounted structure, however, where they occupy between 7000 and 25000 pages.) I'd be happy to talk to anyone interested in AMAR, either through this forum or privately. Betsy Ramsey American Mathematical Society Providence, RI 401-272-9500 x295 Arpanet: EWR@XX.LCS.MIT.EDU ------- 17-Jul-86 11:11:05-PDT,375;000000000000 Mail-From: G.ELDRE created at 17-Jul-86 11:10:44 Date: Thu 17 Jul 86 11:10:44-PDT From: Tim Eldredge Subject: Name Server To: tops20@SU-SCORE.ARPA Message-ID: <12223448993.51.G.ELDRE@SU-SCORE.ARPA> Does anyone have a IEN116 name server for TOPS20 or unix? I know this is an ancient (~1979) protocol, but I find myself needing one. ------- 17-Jul-86 15:19:33-PDT,441;000000000000 Return-Path: Received: from su-sierra.arpa by SU-SCORE.ARPA with TCP; Thu 17 Jul 86 15:19:13-PDT Date: Thu 17 Jul 86 13:35:26-PDT From: Greg Satz Subject: KCC To: su-tops-20@su-score.arpa Phone: (415) 723-1004 Message-ID: <12223475335.48.SATZ@su-sierra.arpa> Binaries for KCC are available from the NIC. Is anyone still interested in KCC? Someone may want to get the sources. ------- 17-Jul-86 21:55:19-PDT,666;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 17 Jul 86 21:55:14-PDT Date: Thu 17 Jul 86 21:50:58-PDT From: Mark Crispin Subject: Re: KCC To: SATZ@SU-SIERRA.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: <12223475335.48.SATZ@su-sierra.arpa> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12223565545.31.CRISPIN@SUMEX-AIM.ARPA> I'm interested in KCC, but would want a version that generates running code for real C programs. The last version of KCC I tried didn't generate good code for the MMSTAT program. ------- 17-Jul-86 22:04:19-PDT,4172;000000000000 Mail-From: BILLW created at 17-Jul-86 22:04:11 Date: Thu 17 Jul 86 22:04:11-PDT From: William "Chops" Westfield Subject: Connections hanging in SYN.SYN (esp SMTJFN). BUGFIX Supplied! To: tops20@SU-SCORE.ARPA Message-ID: <12223567950.10.BILLW@SU-SCORE.ARPA> A while ago, this message was sent, explaining why suddenly a tops20 system would stop receiving SMTP connections, even though the network appeared to be in good shape otherwise... Message 1996 2773 16 Apr 86 From: Mark Crispin Subject: Re: SMTJFN hangups This problem is a monitor bug. It allows connections to be tied up in SYN.SYN state for ages. If you are unfortunate to have a host that is determined to send you a SYN but not ack the SYN you send back (this is common in a "one-way gateway" situation) you can find your mail service (or whatever other service) go south. : I've been investigating various workarounds in SMTJFN, but believe that the right fix is to have TOPS-20 time out SYN's that don't go fully open much faster than it presently does. It does *not* fix the problem to have multiple streams listen on the SMTP port at a time. : Well, recently Score was hit with this problem again (and being bothered by another 20 (TL-20B), as opposed to a unix system), and I decided that it was time to produce some sort of fix. The following is the result. When the 20 receives an ICMP Destination unreachable message, it has always marked the host as being down (in the HSTSTS table). The solution I chose was to use a new code in HSTSTS to mean "unreachable", and to have the retransmitter check for this code when retransmitting packets containing a SYN, and to abort the connection if thye host is "unreachable". The effect is that the connection gets a "retranmission timeout" very quickly, rather than haging in a SYN.SYN state. TCP: OPENF's clear relevant portions of HSTSTS, preventing false aborts, hopefully. I suppose BBN interface programs could behave improperly under some circumstances... Note that the case where an ICMP destination unreachable packet is not received will still leave the connection in its wedged state, waiting for the 5 minute retransmission timeout, or whatever. Here are the relevant changes. It is practicle to do a binary only patch of the monitor, Score ran this way for several days... Enjoy BillW ------------------------------ In TCPTCP.MAC: ------------------------------ JRST REXM1B REXM1A: CALL ULKTTY REXM1B: ; Common processing LOAD T1,PIDO,(PKT) ; Internet data offset in words XMOVEI TPKT,PKTELI(PKT) ; Pointer to Internet portion ADD TPKT,T1 ; Pointer to TCP portion IFN STANSW,<;;; avoid "one way gateways" hanging connections in SYN.SYN IFQN. PSYN,(TPKT) ;retransmission contain a SYN ? LOAD T1,PIDH,(PKT) ;get destination host CALL HSTHSH ;get its hash index SETO T2, IFG. T2 ;if we know the host status HLRZ T1,HSTSTS(T2) ;get the host status CAIN T1,(HS%VAL!) ;unreachable ? JRST REXMI2 ;return "rexmit timeout" error ENDIF. ENDIF. >;IFN STANSW SKIPN TCPON ; Force error if TCP is turned off ------------------------------ In IPIPIP.MAC: ------------------------------ ICMPDU: LOAD T1,CMCOD,(CPKT) ; Get code for destination unreachable CAIE T1,DU%NET ; Net unreachable? CAIN T1,DU%HST ; Host unreachable? CAIA ; Yes to either JRST ICMUSR ; No to both, give it to user SAVET LOAD T1,PIDH,-PKTELI+.CMINH(CPKT) ; Get the host which caused it all CALL HSTHSH ; Get its hash code JUMPL T2,ICMUSR ; If .LT. 0, no room, else new MOVEM T1,HOSTNN(T2) ; Put host number in hash table in case new IFE STANSW,< MOVX T1,HS%VAL! ; Value status, system down, reason 1 >;IFE STANSW IFN STANSW,<;;; use special code for icmp unreachable MOVX T1,HS%VAL! ; Value status, system down, reason 13 >;IFN STANSW HLLM T1,HSTSTS(T2) ; Put this status into table JRST ICMUSR ; In case some user wants it... ------- 20-Jul-86 02:21:25-PDT,415;000000000001 Return-Path: Received: from BRL-SEM.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Jul 86 02:21:12-PDT Date: Thu, 17 Jul 86 15:30:35 EDT From: Ron Natalie To: Tim Eldredge cc: tops20@su-score.arpa Subject: Re: Name Server Message-ID: <8607171530.aa01377@SEM.BRL.ARPA> Is this the same as RFC811? I have one of those for UNIX. -Ron 20-Jul-86 14:15:41-PDT,740;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Jul 86 14:15:24-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 20 Jul 86 14:09:23-PDT Date: Sun 20 Jul 86 13:57:06-PDT From: Mark Crispin Subject: note to BillW's SYN.SYN fix To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12224265713.7.MRC@PANDA> It probably isn't necessary to have the reason code 13. A zero reason code would be reported by Telnet as "network trouble" which is probably a better message in any case. So I would suggest just setting HS%VAL and checking for just that. ------- 21-Jul-86 13:23:03-PDT,1425;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 21 Jul 86 13:22:49-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 21 Jul 86 13:16:53-PDT Date: Mon 21 Jul 86 13:17:42-PDT From: Mark Crispin Subject: DECUS news To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12224520683.7.MRC@PANDA> From the 1986/1987 US Chapter DECUS Program Library Software Abstracts: "The DECUS Library is discontinuing the availability of its older DECsystem-10 and DECSYSTEM-20 individual programs offerings [all but 2 DEC-10 programs and 5 DEC-20 programs - MRC]. These programs have become inactive as individual programs since they can be obtained as part of our DECSYSTEM-10/20 'Library Tapes'. The DECUS Library will continue to offer these 'Library Tapes", the Special Packages, and all new submissions and revisions..." Actually, you'd be even more depressed if you had a PDP-8. They're down to 10 DECUS library programs with no "library tapes". In terms of pages allocated for each, we have: . Professional-300 13 . Rainbow 2 . CP/M 21 . DECmate 3 . PDP-11 119 . VAX 48 . DECsystem-10 5 . DECSYSTEM-20 6 . PDP-8 3 Duh, I wonder what somebody with a PDP-15 is supposed to do? (-: ------- 21-Jul-86 14:46:27-PDT,768;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Mon 21 Jul 86 14:45:55-PDT Date: Mon 21 Jul 86 17:33:20-EDT From: Betsy Ramsey Subject: Re: DECUS news To: MRC%PANDA@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12224520683.7.MRC@PANDA> Company: American Mathematical Society Message-ID: <12224534451.51.EWR@XX.LCS.MIT.EDU> Douglas Bigelow, the DECUS TOPS Librarian, is the reason that any TOPS programs made it into the Library "Software Abstracts" book at all this time. He made an enormous effort to reorganize the TOPS offerings (whose sales have been less than overwhelming, apparently) so that those sections wouldn't be cut from the book. Thanks, Doug! ------- 21-Jul-86 18:51:10-PDT,649;000000000000 Return-Path: Received: from bu-cs.bu.edu by SU-SCORE.ARPA with TCP; Mon 21 Jul 86 18:50:56-PDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA16364; Mon, 21 Jul 86 21:55:00 EDT Date: Mon, 21 Jul 86 21:55:00 EDT From: bzs@bu-cs.bu.edu (Barry Shein) Message-Id: <8607220155.AA16364@bu-cs.bu.edu> To: MRC%PANDA@SUMEX-AIM.ARPA, TOPS-20@SU-SCORE.ARPA Subject: Re: DECUS news As I remember (haven't looked lately) there weren't ANY Ultrix (UNIX) programs in the DECUS library. Do you think that's an accident? I have no idea, don't think much about it. -Barry Shein, Boston University 21-Jul-86 19:00:13-PDT,552;000000000000 Return-Path: Received: from bu-cs.bu.edu by SU-SCORE.ARPA with TCP; Mon 21 Jul 86 19:00:01-PDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA16449; Mon, 21 Jul 86 22:05:09 EDT Date: Mon, 21 Jul 86 22:05:09 EDT From: bzs@bu-cs.bu.edu (Barry Shein) Message-Id: <8607220205.AA16449@bu-cs.bu.edu> To: tops-20@su-score Subject: Re: ULTRIX comment apologies, that was supposed to just be chat to MRC, hit the wrong key, ugh. ignore it. how embarrassing. -(barry shein, out there somewhere) 21-Jul-86 21:59:01-PDT,845;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Mon 21 Jul 86 21:58:41-PDT Return-Path: Received: from munnari.oz by seismo.CSS.GOV with UUCP; Tue, 22 Jul 86 00:42:18 EDT Received: from charlie (via mulga) by munnari with SunIII (5.5) id AA29701; Tue, 22 Jul 86 13:49:36 EST Received: by charlie .Deakin (4.12) id AA02475; Tue, 22 Jul 86 11:04:30 est Date: 22 Jul 86 11:04:28 +1000 (Tue) Message-Id: <104.522378268@charlie> To: Tops20 People Subject: Tops20 V6.1 From: Craig Warren Could someone tell me roughly how long V6.1 has been released in the states. We have not sighted it yet anywhere in oz. Craig Warren ccw%charlie.oz@seismo.css.gov 22-Jul-86 07:10:13-PDT,4056;000000000000 Return-Path: <@WISCVM.ARPA,@WESLEYAN.BITNET:SST.D-BIGELOW@KLA.WESLYN> Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Tue 22 Jul 86 07:09:57-PDT Received: from (MAILER)WESLYN.BITNET by WISCVM.ARPA on 07/22/86 at 09:11:18 CDT Received: from KLA.WESLYN by VAX.WESLYN 22-JUL-1986 10:07:13.11 Date: Tue, 22 Jul 1986 10:05 EDT Message-ID: From: Douglas Bigelow To: Tops20@SU-SCORE.ARPA Subject: DECUS library catalog After reading Mark's comments about the diminished size of the TOPS sections of the current DECUS library catalog, I thought you'd be interested in a few statistics about the library, and the health (or lack therof) of the DEC-10/20 portions.) This is fairly long and probably boring to many of you, so I apologize in advance. As Betsy said, I'm the one responsible for what you see in this year's catalog. The library staff decided that the TOPS sections of the catalog were bloated and had to be cut down. The default algorithm for weeding out old entries, which is applied to all other operating system sections, is simply to phase out entries which have had no sales activity. I've fought that (successfully) for years, arguing that sales of collection tapes (like 20-LIB-5) are based upon the descriptions of the individual programs (like 20-156) that make up the collection. Since it's much more attractive financially to buy a collection tape and get 5-50 programs then to buy them individually, you'd soon wipe out all the individual tapes and then have no descriptions in the catalog for the collection tapes. (I'm sure this is very confusing if you don't use the library. Look at last year's catalog for details.) Now for some statistics from fiscal 1985. At the time of the report I'm looking at, the top seller in the entire library was VAX-LIB-2, with 519 sales. The top seller in the 11 library was 11-SP-18, with 465 sales. The top 107 sellers are mostly VAX and 11, with a few PRO submissions thrown in. Most of them sold over 30 each. The best TOPS20 entry was 20-LIB-7, with 12 sales. The best TOPS10 entry was 10-LIB-1, with 7 sales. The best non-collection entry was 20-178, number 488 on the list of top sellers, with 5 sales. About thirty other programs had sales of 1 or 2, out of a total library of over 575 entries. Each individual submission has a certain overhead cost associated with it, namely storage, processing, author tape replacement, etc. Submissions that don't sell cost DECUS money. In the 85/86 catalog, the TOPS10 and TOPS20 sections had 61 pages, or 25.6% of the catalog. The revenues generated by TOPS sales was *much* smaller than that, a miniscule portion of the total DECUS library sales revenue. On the other hand, DECUS distributes about 50,000 catalogs to the membership, at considerable expense. Put bluntly, the TOPS sales weren't covering their own advertising costs. Faced with statistics like that, I decided it was time to stop fighting to maintain a very large profile for a library that almost nobody is purchasing from. In order that we cut down the size of the catalog section without removing all the useful information, I donated several weeks of my time to reorganizing the TOPS10 and TOPS20 catalog entries into what I hope is a useful format. You need to retain last year's catalog to make best use of it, but it's better than what would have happened otherwise, I assure you. Note that we have *not* lost any programs -- each and every submission is available on a collection tape. It's simply the individual entries that had to go. By the way, I'm not arguing with Mark, I'm agreeing with him. I've been the DEC-10/-20 librarian for five years, and it's been sad to see it wither from the strongest segment to one of the weakest. But naturally, it's going to mirror the fate of DEC-10s and -20s, so nobody should be too surprised. 26-Jul-86 10:47:45-PDT,1904;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Jacob_Palme_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 26 Jul 86 10:47:31-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700236902576074@MIT-MULTICS.ARPA>; 26 Jul 1986 13:48:22 edt Date: 26 Jul 86 12:45 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Tops-20@SU-SCORE.ARPA Subject: Re: International character set Message-ID: <190272@QZCOM> In-Reply-To: <188365@QZCOM> ISO has two 8-bit character sets: ISO 6937/2 and ISO/DIS 8859/1. The difference between these alphabets is that ISO 6937/2 uses overprinting of two characters on top of each other, so that more than one transmitted characters is needed for one imaged character, while ISO/DIS 8859/1 is based on one transmitted character for each imaged character. Thus, 8859 is limited to 2x95 imaged characters, while ISO 6937 has more than 256 different imaged characters. In addition to these, there is a de-facto-standard for IBM PC clones created by IBM, which like 8859 is based on one transmitted character for each imaged character. It is too early to tell which of these three will be the standard used in the future, but I very much believe that one of them will ultimately replace the 7-bit ASCII alphabet, at least in Europe where we have various national characters not covered by ASCII. To be able to handle these new alphabets, virtually all software which handles text files (text editors, message systems, compilers, etc etc.) will have to be rewritten. It is this very large effort which I believe will ultimately be the death of Tops-10/20. 30-Jul-86 11:57:00-PDT,785;000000000000 Return-Path: <@MIT-MULTICS.ARPA:KPJ_Jaakkola_QZ-DEC@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jul 86 11:56:34-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700584187769534@MIT-MULTICS.ARPA>; 30 Jul 1986 14:16:27 edt Date: 30 Jul 86 13:11 +0200 From: KPJ_Jaakkola_QZ-DEC%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ-DEC%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Tops-20@SU-SCORE.ARPA Subject: Re: International character set Message-ID: <191409@QZCOM> In-Reply-To: <190272@QZCOM> Will there ever be a standard standard? 31-Jul-86 16:04:10-PDT,797;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Thu 31 Jul 86 16:03:17-PDT Return-Path: Received: from munnari.oz by seismo.CSS.GOV with UUCP; Thu, 31 Jul 86 18:57:58 EDT Received: from charlie (via mulga) by munnari with SunIII (5.5) id AA13227; Fri, 1 Aug 86 08:17:32 EST Received: by charlie .Deakin (4.12) id AA26915; Thu, 31 Jul 86 15:48:43 est Date: 31 Jul 86 15:48:40 +1000 (Thu) Message-Id: <104.523172920@charlie> To: Tops20 People Subject: Interested in MACSYMA From: Craig Warren Can anyone tell me if their is a version of MACSYMA for Tops20? Craig Warren ccw%charlie.oz@seismo.css.gov 31-Jul-86 18:19:15-PDT,741;000000000000 Return-Path: Received: from GSB-HOW.STANFORD.EDU by SU-SCORE.ARPA with TCP; Thu 31 Jul 86 18:19:03-PDT Date: Thu 31 Jul 86 18:18:40-PDT From: Eric M. Berg Subject: Re: Interested in MACSYMA To: munnari!charlie.oz!ccw@SEISMO.CSS.GOV cc: TOPS20@SU-SCORE.ARPA Phone-#s: 723-1576 (GSB-CF), 329-9940 (home) Yes, there is a version of MACSYMA for TOPS-20. It's distributed by the MACSYMA group of Symbolics. I don't know how much it costs to license. You can contact them as follows: Symbolics MACSYMA Group 257 Vassar Street Cambridge, Ma. 02139 SMI-MACSYMA@MIT-MC (This address is from 1983 documentation; no guaranteee that it's up to date.) ------- 1-Aug-86 08:57:56-PDT,605;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 1 Aug 86 08:57:35-PDT Date: Fri, 1 Aug 1986 11:57 EDT Message-ID: From: Rob Austein To: munnari!charlie.oz!ccw@SEISMO.CSS.GOV Cc: A.ERIC@GSB-HOW.STANFORD.EDU, TOPS20@SU-SCORE.ARPA Subject: Interested in MACSYMA In-reply-to: Msg of 31 Jul 1986 21:18-EDT from Eric M. Berg Your best bet for a mail address would be something at Symbolics, not MC. Maybe MACSYMA or SMI-MACSYMA at SCRC-STONY-BROOK.ARPA. 3-Aug-86 11:26:58-PDT,912;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Peter_Lothberg_STUPI@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sun 3 Aug 86 11:26:42-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700929516350718@MIT-MULTICS.ARPA>; 03 Aug 1986 14:11:56 edt Date: 03 Aug 86 06:18 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Tops-20@SU-SCORE.ARPA Subject: Tops-10 7.03 Message-ID: <192142@QZCOM> Is there anybody out there still running a KI-10, and have thougt of restore the code DEC accidentially wiped out? We also have an Emacs mode command line editor for Tops10 (7.02) if anybody is interested. 4-Aug-86 13:44:37-PDT,757;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Rolf_Nordhagen_UiO@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Aug 86 13:43:54-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2701025085594775@MIT-MULTICS.ARPA>; 04 Aug 1986 16:44:45 edt Date: 04 Aug 86 15:23 +0200 From: Rolf_Nordhagen_UiO%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Rolf_Nordhagen_UiO%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: AMAR Message-ID: <192276@QZCOM> In-Reply-To: <12222856799.8.ADMIN@RADC-TOPS20.ARPA> What is AMAR? 4-Aug-86 17:23:51-PDT,1813;000000000000 Mail-From: BILLW created at 4-Aug-86 17:23:47 Date: 4 Aug 1986 17:23-PDT Sender: BILLW@SU-SCORE.ARPA Subject: Re: DEC-20 and Bridge TCP interactions From: William "Chops" Westfield To: bridge2!cmj@GLACIER.STANFORD.EDU Cc: powell@ARGUS.STANFORD.EDU, hedrick@RED.RUTGERS.EDU, su-tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA] 4-Aug-86 17:23:46.BILLW> In-Reply-To: <8607091841.AA05023@bridge2.ARPA> I think that I have found the BUG in Tops-20 that was causing all the difficulties when trying to communicate with Bridge Ethernet terminal concentrators. Rather than a bug in the tops20 TCP, this turned out to be a bug in the setuo of termial buffers for the tcp connection. A recent modification to this code attempted to allocate enough TTY buffers to almost fill a maximum sized TCP segment. Unfortunately, I forgot to take into account that a terminal buffer might be bigger than a maximum sized packet. In this case, 0 buffers were allocated with a "total size" of 1022 (sort of what happens when you stuff a negative number into a (small) fixed width field). It is not at all surprising that thing became confused under these circumstances. The fix is to insert the lines: CAIN T2,0 MOVEI T2,1 Just after the IDIVI at TVTSOF+10. It is safe to do this to a running monitor - it looks something like this: @mddt tvtsof 11/ CAILE T2,4 $w $< fff/ 0 cain t2,0 fff+1/ 0 movei t2,1 $> ^Z My appologies to the people at Bridge for assuming for a long time that this was their problem. Of course, there are performance improvements you get by using larger buffers, but... The sources are available on Score as <6-1-monitor>TVTSRV.MAC The object code patch has been installed on Score, LOTS A/B/C, and Sushi. Enjoy BillW 4-Aug-86 19:19:09-PDT,1367;000000000001 Return-Path: Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 4 Aug 86 19:18:57-PDT Date: Mon 4 Aug 86 22:20:01-EDT From: Eric R. Crane Subject: VMS <--> Tops-20 DECnet To: info-vax@SRI-KL.ARPA, tops-20@SU-SCORE.ARPA Office: Ucc 134, (412) 268-3568 Secretary: Ava Ford, (412) 268-2638 Message-ID: <12228256657.25.EC0N@TE.CC.CMU.EDU> First a quick description of our situation... We have 2 DECnet links from V4.2 VMS systems to V5.4 Tops-20 systems. The first link it a pair of 1Mb DMC-11's, and the other is a pair of DMR-11's at 1Mb in DMC compatability mode. What we see on our these systems when we start DECnet is the DN20 says the circuit is "starting" and the Vax says "Syncronizing". The DMC link has been in use for 5 months and just stopped working last week. That is the problem. What we have tried doing to isolate or fix these problems is check out all of the DMR's and DMC's involed by connecting them to other systems, looping back at the local system, and looping back at the remote system. All of these seem to work just fine when we are talking 20 to 20 or Vax to Vax. Has anyone else had this type of problem? We have not changed any software on any of the systems involved for over 2 months. - Eric Crnae Carnegie Mellon Computation Center ------- 4-Aug-86 20:12:40-PDT,2631;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 4 Aug 86 20:12:16-PDT Date: Mon 4 Aug 86 23:12:45-EDT From: Ken Rossman Subject: Re: VMS <--> Tops-20 DECnet To: EC0N@TE.CC.CMU.EDU cc: info-vax@SRI-KL.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: <12228256657.25.EC0N@TE.CC.CMU.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12228266258.146.SY.KEN@CU20B.COLUMBIA.EDU> We have 2 DECnet links from V4.2 VMS systems to V5.4 Tops-20 systems. The first link it a pair of 1Mb DMC-11's, and the other is a pair of DMR-11's at 1Mb in DMC compatability mode. What we see on our these systems when we start DECnet is the DN20 says the circuit is "starting" and the Vax says "Syncronizing". The DMC link has been in use for 5 months and just stopped working last week. That is the problem. Has anyone else had this type of problem? We have not changed any software on any of the systems involved for over 2 months. Eric, we had this problem with a VAX at the Chemistry department (and are currently having this problem talking to you guys!). If you put a data scope on the line, you will see the following: START START STACK ACK DATA(router-init) (10 second or so pause -- timeout -- same sequence over and over again). We never did fix our problem with the Chemistry VAX -- we just put them on Ethernet instead and forgot about the VAX. As with you guys, this problem came seemingly out of nowhere and just stuck with us, no matter what we tried, it would seem. I will tell you some things that DID work, though. We originally had a KDP (DUP11/KMC11 combination) in our DN20 plugged into the DMR11 in a VAX/780. This was the combination that stopped working. We then tried plugging our DN20 into the VAX/730 at Chem, which also had a DMR11, and lo and behold, the link came up. I have no idea why, as the software running on both was supposedly the same, and I don't know what else could have been different between the 780 and the 730. So we just ran for awhile plugged into the 730, and later, swapped to an Ethernet LAN bridge and dropped the synch connection altogether. Another thing that worked on the 780 was to drop back a version of VMS. Again, I don't know what changed in that version. In any case, Eric, as I said, this seems to be what's happening between CU and CMU now, as well as (I would guess) locally at your site. You and I should get together and take a close look at the problem. /Ken ------- 5-Aug-86 07:45:23-PDT,1497;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 07:45:00-PDT Date: Tue 5 Aug 86 10:45:45-EDT From: Thomas De Bellis Subject: Memory allocation bug in GLXOTS To: Tops-20@SU-SCORE.ARPA Message-ID: <12228392415.174.SY.SLOGIN@CU20B.COLUMBIA.EDU> GLXOTS has a routine called CREDAT which is used to create data pages so that the memory initializing routines get the correct count of available pages. It also performs the function of setting these pages to a known initial value. Unfortunately, it sets the arguments to .ZCHNK, a routine that eventually does a BLT to zero out memory space, backwards; it gives a negative amount of space to zero and starts from the end. This could cause either GLXMEM to not know how many pages can be used for user programs or blow away part of the GLXLIB segment. The code to be replaced is at the end of GLXOTS a few lines up from OTS%L: Old code: TOPS20 < ;TOPS-20 ONLY XMOVEI S1,D%BEG-D%END## ;GET LENGTH OF PAGE PAGES XMOVEI S2,D%END## ;POINT TO LAST DATA WORD $CALL .ZCHNK ;ZAP ALL WORDS POPJ P, ;RETURN > ;END OF TOPS-20 CONDITIONAL New Code: TOPS20 < ;TOPS-20 ONLY XMOVEI S1,D%END##-D%BEG ;C122 ;Get positive length of data area XMOVEI S2,D%BEG ;C122 ;Point to the first word $CALL .ZCHNK ;ZAP ALL WORDS POPJ P, ;RETURN > -- Tom De Bellis Columbia Systems Group ------- 5-Aug-86 08:12:55-PDT,1506;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 08:12:43-PDT Date: Tue 5 Aug 86 11:14:05-EDT From: Thomas De Bellis Subject: GLXLIB start up speed up To: Tops-20@SU-SCORE.ARPA Message-ID: <12228397573.174.SY.SLOGIN@CU20B.COLUMBIA.EDU> Ever wonder why programs that use GLXLIB take so very long to start up? That is, I mean, aside from that really efficient Tops-10 PORTAL calling interface... Part of the problem is that the GLXMEM initializing routines use the RPACS% jsys to get the initial memory configuration. This means that you have to do around 400 some odd jsyi, one for ever page past the code PSECT--this is real bad news. I've modified GLXMEM to do one XRMAP% jsys to get the initial page map and then translate the data into Galaxy internal format. The amount of time it takes to init the GLXLIB segment here has dropped by about %75. I've put the modified GLXMEM on Score in PS: for public perusal, the routine that changed is M%INIT. I've made it compatible with older monitors by having it still do the RPACS% if XRMAP breaks. I invite interested hackers to have a look at some real monkey business I did to speed things up in the conversion routine, PAGFRE (using byte pointers to do address arithmatic). Warning: this is real bit dinking here--not for the faint of heart. -- Tom De Bellis Columbia Systems Group ------- 5-Aug-86 08:31:50-PDT,1721;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 08:31:36-PDT Date: Tue 5 Aug 86 11:32:49-EDT From: Thomas De Bellis Subject: NMLT20 and Galaxy To: Tops-20@SU-SCORE.ARPA Message-ID: <12228400983.174.SY.SLOGIN@CU20B.COLUMBIA.EDU> I have a rather thorny problem here at Columbia. I have a whole bunch of DEC20's (used to be six of them before we tossed one to try out an 8650 super winning Unix box) and all of them want to run the same much modified Galaxy that we have so that they can all print to each other. However, a certain orange toad insists on running a 5.1 monitor and that means that Galaxy has to be able to work on either 6.1 or 5.1. This is no big deal since it is pretty easy to make MOUNTR behave and it's the only thing that really wants to do sixish CFS things. Unfortunately, the interface between Galaxy and NMLT20 (or any application program) has changed (at least the GALGEN macros have) and when I assemble this Galaxy with the old NCPTAB.REL and try to run it on the 5.1 system, the NMLT20 there blows up and dies. I can't make it work by assemblying it with the old G$$ATB, either. Has anyone got any ideas on this? I have a feeling that any site that runs their own applications (such as CMU with their ALERT application) is going to have trouble getting that to work. Has anyone tried making their own Galaxy applications work on the 6.1 Galaxy? Has anyone ever done an application? Can somebody give me some pointers? Getting the 5.1 system to upgrade is pretty much out of the question. -- Tom De Bellis Columbia Systems Group ------- 5-Aug-86 11:29:17-PDT,1410;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 11:28:59-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 5 Aug 86 11:30:03-PDT Date: Tue 5 Aug 86 10:54:42-PDT From: Mark Crispin Subject: PDP-8/F To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12228426811.6.MRC@PANDA> I recently acquired a PDP-8/F. I've been able to determine that it's an Omnibus machine (part of the E, M, and A series). Physically, it looks very much like a PDP-8/E with the back cut off (that is, it only has 20 slots). That would describe a PDP-8/M ... would anybody know how a PDP-8/F differs from a PDP-8/M? Unlike the PDP-11/20 that I got earlier (and subsequently got rid of), the PDP-8/F works. It definitely has 8K (and therefore the timesharing option). The only peripheral is the teletype control. Does anybody have any old PDP-8 documentation or software that they'd be willing to part with? I'm looking for the standard PDP-8 set in particular: . Small Computer Handbook . Introduction to Programming . Programming Languages and of course I'd be happy for prints, etc. I'd also like to get my paws on *any* software that would run on it, especially the Binary Loader, 8K FOCAL, and 8K BASIC. ------- 5-Aug-86 15:24:21-PDT,5427;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 15:23:13-PDT Date: Tue 5 Aug 86 15:25:14-PDT From: Mark Crispin Subject: Unix dead??? (long message) To: SU-etc@SUMEX-AIM.ARPA, TOPS-20@SU-SCORE.ARPA, Unix-Wizards@BRL.ARPA, Boken@RED.RUTGERS.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12228476060.57.CRISPIN@SUMEX-AIM.ARPA> The following is from the August '86 issue of the DEC Professional. It's amusing, if nothing else. I believe Dvorak is a VMS/IBM PC junkie. UNIX IS DEAD! WANNA FIGHT?? John C. Dvorak Summer is over and a plague of UNIX programmers is upon us. College kids, wet behind the ears; greenhorns, rubes. They pour out of various campuses talking about ROFF and ED and pipes and paths, and they look for work. They're impressed with themselves. After all, they've learned the language of a secret society. If they're from Berkeley, they've learned the secret language of a secret society. They all program in C, and wherever they go they change the prompts on whatever computer they get their hands on so it resembles a UNIX machine. They creative ones go into whatever operating system they have to use and find a symbol or token table; then they change the commands to look like UNIX. The *more* creative ones customize the commands further so they are even more cryptic and weird than UNIX. Whether these people ever do any real work is a mystery. "Yes, weeell, to list my files I merely type P; MJOI." "P; MJOI?? What they heck does that mean?" "It just so happens that if I put my coffee cup on the keyboard and rock it a certain way, that's what it will type; so, I do that to list my files!" While it's good to see these kids doing something other than wasting quarters on endless games of Pole Position, I'm not so sure UNIX dabbling is much better for society. I feel this way, not so much because UNIX is an old-fashioned OS that has a special place reserved in hell, but because its time has passed. UNIX is dead, but no one bothered to claim the body. It lives like a zombie on college computers and serves as a gateway to all sorts of weird networks. UNIX haunts marketing men, too. I remember when Fortune Systems was getting started. That's about the time that a bumper crop of college-bred UNIX drones was dumped like mulch into the marketplace. They all were singing the praises of UNIX to the low end of the market. So, I went to this strategy demonstration given by one of the vice presidents of Fortune Systems. These guys surely were ahead of their time, and it was a perfect example of having too much bad information. The Fortune 16:32 (or was it 32:16? In either case it looked like a biblical reference...) said unto us: "Come to me for thine microprocessor and spend, spend, spend!" it was the first camel of microcomputers. Like a horse designed by committee (aka camel), the Fortune was preceded by too much market research. A lot of this was skewed by the hordes of UNIX maniacs running through the valley waving the UNIX flag. First of all, I was shown a slide that clearly showed the Motorola 68000 as the world's greatest microprocessor. The 68000 beat everything. Personally, I can't remember what it was pitted against -- probably the 8080, the 6502 and a 4004. Whatever, this was the chip to use. Then the company did some market research and, because writers, pundits, researchers, secretaries, publishers, and programmers all said that UNIX was the next hot operating system, they chose it for their own little machine. The UNIX community yelled, "Yea!" But, they continued to use free university-provided time, and none of the UNIX hackers bought the little UNIX boxes. Well, that was okay, it was intended to be a business machine, anyway. Ooops! Gee, it seems that the businessmen couldn't cope with UNIX and "$ ls /bin/pr -p -t" or any other such nonsense. So they had to build a performance-sapping shell around the system, code name: SLOW. So much for the UNIX world takeover. I figured that would be the last I heard of it. No so. Last week, a guy walked up to me as I was writing this column on a portable computer in a San Francisco bistro. he had been reading it through binoculars from across the room. "So, you don't like UNIX, huh, Dvorak? What's better, MS-DOS?? Hahahaha!" "IBM's VM is the happening operating system," was my quick rejoinder. "VM doesn't run on minis and micros. It's just a shell, anyway," he shot back. "Is not!" "Is too!" "Is not!" He took a swing at me and I caught him a good one in the stomach. We punched each other for a good 15 minutes. All of a sudden he stopped and yelled, "Hey, what's going on here? Where am I? Wow, I remember my name! What happened?" "We were fighting about UNIX," I said. "UNIX? I was fighting about UNIX? My God...I was hypnotized!" True story. So, try snapping your fingers in the face of one of these UNIX maniacs next time he flies off the handle. See what happens. ------- 5-Aug-86 17:07:01-PDT,936;000000000000 Return-Path: <@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 17:06:24-PDT Return-Path: <@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: by seismo.CSS.GOV; Tue, 5 Aug 86 19:45:17 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2701122138147601@MIT-MULTICS.ARPA>; 05 Aug 1986 19:42:18 edt Date: 05 Aug 86 16:05 +0200 From: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Tops20 People" Subject: Interested in MACSYMA Message-Id: <192632@QZCOM> In-Reply-To: <104.523172920@charlie> We have been running a version on the system here at UCD for a number of years. 5-Aug-86 20:05:19-PDT,586;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 20:05:06-PDT Date: Tue 5 Aug 86 20:07:14-PDT From: Theresa Stetson Subject: File archival To: tops-20@SRI-KL.ARPA To whom it may concern: I do not wish to have any of my files put on tape and archived. I use them in spurts, and have a good idea of what is on my directory at any point in time. I cannot wait 24 hours for something to come to me off tape. Please arrange this immediately. Thank you, Theresa@SRI-KL Micom L1670 ------- 5-Aug-86 21:15:30-PDT,672;000000000000 Return-Path: <@SRI-KL.ARPA:bzs@bu-cs.bu.edu> Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 21:15:16-PDT Received: from bu-cs.bu.edu by SRI-KL.ARPA with TCP; Tue 5 Aug 86 21:17:22-PDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA21440; Wed, 6 Aug 86 00:08:41 EDT Date: Wed, 6 Aug 86 00:08:41 EDT From: bzs@bu-cs.bu.edu (Barry Shein) Message-Id: <8608060408.AA21440@bu-cs.bu.edu> To: tops-20@SRI-KL.ARPA In-Reply-To: Theresa Stetson's message of Tue 5 Aug 86 20:07:14-PDT Subject: File archival Yeah! Would you guys leave poor Theresa's files alone! -Mobilization Committee to Denounce Archiving of Theresa's Files 5-Aug-86 21:21:02-PDT,838;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 21:20:51-PDT Date: Tue 5 Aug 86 21:22:43-PDT From: Bob Knight Subject: Re: Unix dead??? (long message) To: Crispin@SUMEX-AIM.ARPA, SU-etc@SUMEX-AIM.ARPA, TOPS-20@SU-SCORE.ARPA, Unix-Wizards@BRL.ARPA, Boken@RED.RUTGERS.EDU In-Reply-To: <12228476060.57.CRISPIN@SUMEX-AIM.ARPA> Message-ID: <12228541138.12.KNIGHT@SRI-NIC.ARPA> I suppose it's appropriate to restate that old adage "a fool and his money are soon parted". Judging by Mr. Dvorak's output that I've read, any publisher who pays him money to be a seer with respect to the computing market is a fool. I don't doubt that the people who founded SUN read this article. And they're laughing. All the way to the bank. Bob ------- 6-Aug-86 09:13:51-PDT,1084;000000000000 Return-Path: Received: from sun.com by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 09:13:33-PDT Received: from snail.sun.com (snail-ptp) by sun.com (3.2/SMI-3.0) id AA22285; Wed, 6 Aug 86 09:12:47 PDT Received: from plaid.consult. com by snail.sun.com (3.2/SMI-3.2) id AA18126; Wed, 6 Aug 86 09:14:20 PDT Received: by plaid.consult. com (3.2/SMI-3.2) id AA02309; Wed, 6 Aug 86 09:18:16 PDT Date: Wed, 6 Aug 86 09:18:16 PDT From: chuq@Sun.COM (Chuq Von Rospach- Lord of the OtherRealms) Message-Id: <8608061618.AA02309@plaid.consult. com> To: Boken@RED.RUTGERS.EDU, Crispin@SUMEX-AIM.arpa, SU-etc@SUMEX-AIM.arpa, TOPS-20@SU-SCORE.arpa, Unix-Wizards@BRL.ARPA Subject: Re: Unix dead??? (long message) Just a nice little reminder. Posting copyrighted material is ILLEGAL. Posting Dvorak's column from the Dec Professional, content discussions aside, puts the poster and the network at potential legal liability. We are NOT above the law, no matter how much some people might like us to believe. This sort of garbage should not happen. chuq 6-Aug-86 11:04:11-PDT,1591;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 11:03:13-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 6 Aug 86 11:04:04-PDT Date: Wed 6 Aug 86 10:25:42-PDT From: Mark Crispin Subject: Re: Unix dead??? (long message) To: chuq@SUN.COM cc: Boken@RED.RUTGERS.EDU, Crispin@SUMEX-AIM.ARPA, SU-etc@SUMEX-AIM.ARPA, TOPS-20@SU-SCORE.ARPA, Unix-Wizards@BRL.ARPA In-Reply-To: <8608061618.AA02309@plaid.consult. com> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12228683675.7.MRC@PANDA> There is nothing that irritates me more than pseudo-legal experts who make sweeping statements about what the law says when lawyers are much more reticent on the issue. Individual lawyers may have opinions, and certain opinionated laymen may have their beliefs, but only the courts are authoritative. A reasonable argument can be made that passing on an editorial from a trade publication to various academic and trade distributions for the purposes of alerting the individuals in that distribution to the opinions expressed in that editorial is protected under the Fair Use Doctrine. I wonder if there is any relation beyond coincidence that both parties who flamed about "posting copyrighted material is illegal" are from SUN. Maybe this is a plot by SUN to close off people's brains so they will sign any terrible license agreement SUN comes up with. Sorry for passing this to all the mailing lists. ------- 6-Aug-86 11:33:01-PDT,3108;000000000000 Return-Path: Received: from sun.com by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 11:32:29-PDT Received: from snail.sun.com (snail-ptp) by sun.com (3.2/SMI-3.0) id AA22850; Wed, 6 Aug 86 11:17:02 PDT Received: from plaid.consult. com by snail.sun.com (3.2/SMI-3.2) id AA19349; Wed, 6 Aug 86 11:18:35 PDT Received: by plaid.consult. com (3.2/SMI-3.2) id AA02915; Wed, 6 Aug 86 11:22:30 PDT Date: Wed, 6 Aug 86 11:22:30 PDT From: chuq@Sun.COM (Chuq Von Rospach- Lord of the OtherRealms) Message-Id: <8608061822.AA02915@plaid.consult. com> To: MRC%PANDA@SUMEX-AIM.ARPA, chuq@Sun.COM Subject: Re: Unix dead??? (long message) Cc: Boken@RED.RUTGERS.EDU, Crispin@SUMEX-AIM.ARPA, SU-etc@SUMEX-AIM.ARPA, TOPS-20@SU-SCORE.ARPA, Unix-Wizards@BRL.ARPA > There is nothing that irritates me more than pseudo-legal experts who > make sweeping statements about what the law says when lawyers are much > more reticent on the issue. There is nothing that irritates ME more than someone who breaks the law and tries to bluster their way out of it. I quote from the SAME issue of Dec Professional: COPYRIGHT 1986 by Professional Press, Inc. All rights reserved. No part of this publication may be reproduced in any form without written permission of the publisher. > A reasonable argument can be made that passing on an editorial from a > trade publication to various academic and trade distributions for the > purposes of alerting the individuals in that distribution to the > opinions expressed in that editorial is protected under the Fair Use > Doctrine. Fair Use covers EXCERPTS. That wasn't, by any sense of the word. It was a clear copyright violation. > I wonder if there is any relation beyond coincidence that both parties > who flamed about "posting copyrighted material is illegal" are from > SUN. Maybe this is a plot by SUN to close off people's brains so they > will sign any terrible license agreement SUN comes up with. Mark, besides bordering on the purely slanderous, you're flaming nuts. It just happens that there are a couple of people who happen to believe in following the rules. I happen to be a writer, and so copyright is an interest of mine as well as way of life. The fact that two people from anywhere mention it should have made you wonder whether there was a basis in the accusation, not more defensive. I'm also sorry for passing this to all the mailing lists, but I couldn't let Marks name calling go uncommented on. You're wrong Mark, and I don't care how much you tell, that was a FLAGRANT copyright violation. It YOU wrote a piece of software, and I took a copy and gave it away on CompuServe, you'd scream and yell until the walls fell down. Why do you think you have the right to do the same thing to someone else? This is my last public word on the subject. Please, folks. don't ignore copyright. You can put yourself at legal and financial risk. You can also put your home site at risk, as well as the entire network. It just ain't worth it. We ARE NOT ABOVE THE LAW. chuq 6-Aug-86 15:12:42-PDT,571;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 15:12:13-PDT Date: Wed 6 Aug 86 15:12:50-PDT From: Bruce Tanner Subject: Exec hacks To: tops20@SU-SCORE.ARPA Message-ID: <12228735948.44.CERRITOS@USC-ECL.ARPA> I've just gotten an exec source license and would like to survey all the time honored mods that everybody as made to their exec. So, what are the top 10 exec enhancements that you couldn't live without? Obviously, source code would be appreciated. -Bruce ------- 6-Aug-86 18:15:00-PDT,679;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 18:14:44-PDT Date: Wed 6 Aug 86 21:15:44-EDT From: Ken Rossman Subject: Re: Unix dead??? (long message) To: SU-etc@SUMEX-AIM.ARPA, TOPS-20@SU-SCORE.ARPA, Unix-Wizards@BRL.ARPA In-Reply-To: <8608061822.AA02915@plaid.consult. com> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12228769243.35.SY.KEN@CU20B.COLUMBIA.EDU> Mark, besides bordering on the purely slanderous, you're flaming nuts. Umm, lets see here... WHO did you say was bordering on slander here??? ------- 6-Aug-86 18:16:59-PDT,697;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 18:16:46-PDT Date: Wed 6 Aug 86 21:18:08-EDT From: Ken Rossman Subject: Re: Exec hacks To: CERRITOS@USC-ECL.ARPA, tops20@SU-SCORE.ARPA In-Reply-To: <12228735948.44.CERRITOS@USC-ECL.ARPA> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12228769680.35.SY.KEN@CU20B.COLUMBIA.EDU> So, what are the top 10 exec enhancements that you couldn't live without? I'd put my vote in for PCL and PCL-like command structure enhancements, and an EMACS-like command line editor at the very least. /K ------- 6-Aug-86 20:50:01-PDT,1290;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Wed 6 Aug 86 20:49:44-PDT Date: Wed 6 Aug 86 23:50:52-EDT From: Eric R. Crane Subject: Solved VMS <--> Tops-20 DECnet To: Tops-20@SU-SCORE.ARPA, info-vax@SRI-KL.ARPA Office: Ucc 134, (412) 268-3568 Secretary: Ava Ford, (412) 268-2638 Message-ID: <12228797484.46.EC0N@TE.CC.CMU.EDU> Well, it took many hours of beating my head against a wall, but I was finally able to fix my communications problem. The cause was that we had set the executors MAXIMUM ADDRESS to 512. I did not use much logic in finding this, it was a stab in the dark after logging gave me the error "Adjacent node block size to small". Setting the MAXIMUM ADDRESS back to 255 cause the Vax to talk to the 20 again. For those of you with 20's and Vaxen who do not have plans to sink money into NI20's because your Tops-20 systems are not going to be here much longer you might want to remember this when planning your DECnet networks. For those of you who have burnt the midnight oil learning everything you can (dare?) about DECnet. Is this a bug? Did I miss something in the documentation? Should I SPR it? - Eric R. Crane Carnegie Mellon Computation Center ------- 7-Aug-86 06:02:32-PDT,741;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 7 Aug 86 06:02:21-PDT Date: Thu 7 Aug 86 09:02:54-EDT From: Ken Rossman Subject: Re: Solved VMS <--> Tops-20 DECnet To: EC0N@TE.CC.CMU.EDU, Tops-20@SU-SCORE.ARPA, info-vax@SRI-KL.ARPA In-Reply-To: <12228797484.46.EC0N@TE.CC.CMU.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12228897979.19.SY.KEN@CU20B.COLUMBIA.EDU> Well Eric, I'm glad it took you only "many hours" to find your DN20-VAX DECnet link problem. We spent four months on this one and finally gave up when our Ethernet connection to the VAX in question came in... /Ken ------- 7-Aug-86 08:54:02-PDT,11254;000000000001 Return-Path: <@Cs.Ucl.AC.UK,@dundee.ac.uk:Alan@dundee-tech.ac.uk> Received: from Cs.Ucl.AC.UK by SU-SCORE.ARPA with TCP; Thu 7 Aug 86 08:52:02-PDT Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a005478; 7 Aug 86 15:40 BST Via: DCT; by DUNDEE on Thursday, 7-Aug-86 15:39:12-GMT Date: Thu 7 Aug 86 15:21:23-GDT From: Alan Greig Subject: Exec source changes To: tops-20@su-score.arpa Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan%dundee-tech.ac.uk@Cs.Ucl.AC.UK Anyone forced to work on an extremely overloaded system will appreciate some fast way of freeing up a terminal at the end of a job. Before the vaxes began to sprout everywhere there was a free bit of floor in DCT it used to be common to see approaching 100 jobs on the system and load averages of above 50. At times if a class of 30 students finished a practical at the same time and typed logout. It would take the system about 30 minutes to free the terminals. The solution adopted by us and many others was to add a fast logout command which doesn't do a deldf% jsys (expunge) and also detaches the job before executing lgout%. This gives an instantaneous free of the terminal under almost any load. Of course you have to check for logout capability before doing this and hope that access control doesn't screw you if your site runs some special quota checking etc. Finally if the logout is going to fail it fails quickly and its possible with local terminals to re-attach the job to the old controlling terminal before the user has wandered off. This was easily the most effective and most used change we ever made. If people can be bothered reading it, here's a list of most of the changes we have done in the last 5 years or so. Many have been superseded by now and as tops-20 development has been more or less frozen for some time here, there's not a lot of new changes but they will give some pointers. Alan (ARG) ** 15-DEC-81 ** ARG ** Symptom:Wanted an easier way of sending and reading mail Cure: Add the commands TELL user and MESSAGE Which run MM in EPHEMERON fork Module: EXEC0,EXEC1,EXECGL ** 17-DEC-81 ** ARG ** Symptom:Lazy continue doesn't work if the program has been ^C 'd out of thus you end up creating multiple forks of the form OPR, OPR0,OPR1 etc. Cure: Remove offending instruction just before RSUBS4 which checks to see if the fork has terminated voluntarily Module: EXEC0 ** 18-DEC-81 ** ARG ** Symptom:Dismount command accepts infinite number of keywords Cure: 20-14203 1-Jun-80 Module: EXECMT 5-APR-82 ** ARG ** Symptom:PCL has lazy connect, EXEC doesn't !! Cure: Add the code to EXEC Module: EXEC0,EXEC1,EXECGL 6-APR-82 ** ARG ** Symptom:Want ^EMDDT command Cure: add command and code Module: EXEC0,EXEC1,EXECGL 9-APR-82 ** ARG ** Symptom:The I/O subcommands to START and CONTINUE don't work Exec closes the jfns as soon as it returns to command level causing the subfork to bomb out. Cure: Add code to remove the jfns from EXEC's table after doing SPJFN (Same code as used in GET command to do similiar thing) Module: EXECP 13-APR-82 ** ARG ** Symptom:EXEC doesn't have KKJOB but PCL does Cure: Add code to do it !! Module: EXEC0,EXEC1,EXECGL 14-APR-82 ** ARG ** Symptom:Want SET [NO] LOGOUT-CAPABILITY Cure: Add it in Module: EXECPR,EXECSE,EXECP,EXECIN 16-APR-82 ** ARG ** Symptom:KKJOB knows about log capability but LOGOUT doesn't Cure: Add the code to logout command Module: EXEC1 Symptom:EXEC allows user to SET FILE EPHEMERAL/AUTOKEEP but no way to tell if a file has these classes set Cure: Add code to directory command to print ;R (rms) ;E (Ephemeral) ;K (autokeep) or ;CLASS:n if unknown type Module: EXEC3 24-MAY-82 ** ARG ** Symptom:EXEC is to slow !! Some of the commands such as INFO DISK take a very long time to return usually unwanted information Cure: Add new command SET FAST-MODE which will try to allow certain commands to run faster. Change the INFO DISK command to not check for deleted files if running in FAST mode (only do GTDAL). Make FAST mode be default for time being. Module: DCT,EXEC0,EXECIN,EXECSE,EXECGL,EXECPR 9-JUN-82 ** ARG ** Symptom:Want exec to type out system:ctrlc-message.txt if it exists on initial ctrl/c at terminal Cure: Add code to do so Module: EXEC0 21-JUN-82 ** ARG ** Symptom: Want to print number of jobs message on CTRL-C Cure: Add it Module: EXEC0 7-JUL-82 ** ARG ** Symptom:INFO OUTPUT lists all output queues which is annoying if there is a long plotter queue and you only want to see the print queue Cure: Add INFO PRINT-REQUESTS and INFO PLOT-REQUESTS Module: EXECIN,EXECGL,EXECQU 16-JUL-82 ** ARG ** Symptom:EXEC does not have any interface to the SED editor Cure: Add one similiar to EMACS (it don't work though!!) Module: EXECED 16-JUL-82 ** ARG ** Symptom:Want SET FILE UNDELETABLE Cure: Add it Module: EXECSE 19-JUL-82 ** ARG ** Symptom:Want INFO ERROR-MESSAGE (for error number) Cure: Add code Module: EXECIN 22-jul-82 ** ARG ** Symptom:Want SET EDITOR command Cure: Add it Module: EXECED,EXECSE,EXECGL 20-Aug-82 ** ARG ** Symptom:If 2 Versions of a help file exist and the higher generation is deleted then HELP does not see the valid file Cure: Make MAKLST: GTJFN HLP:*.HLP.* (extra wild card generation) Also put ERJMP .+1 after TBADD in case of entry already in table error Module: EXECIN 10-Sep-82 ** ARG ** Symptom:Want to be able to speak to SYSJB1 which is not under job 0 Cure: Add optional job number to ^Espeak and if job non zero then use SYSTEM:SYSJB1.COMMANDS and wake specified job Module: EXEC2 10-Sep-82 ** ARG ** Symptom:CSAVE and SAVE can get PDLOV if too many distinct memory blocks are specified Cure: Put erjmp after PUSH Module: EXECP 23-Sep-82 ** ARG ** Symptom:Want to be able to stop Dumper from saving certain files Cure: Add code for SET FILE UNSAVEABLE (BY DUMPER) Module: EXECSE 5-Oct-82 ** ARG ** Symptom:Don't want connect command to always default to login directory Cure: Add SET DEFAULT (FOR) CONNECT Module: EXEC1,EXECSE,EXECIN,EXECGL,EXECPR 24-Oct-82 ** CB ** Symptom:Want to connect staff to structure other than PS: after they login Cure: Rewrite LOGCHK and add code to call it. Module: EXEC0,EXEC1,EXECGL,EXECPR,EXEXEC 28-Oct-82 ** CB ** Symptom:EXEC doesn't print exclamation marks after uptime Cure: Add code to ETYPE at %K to print them. Module: EXECSU 14-Dec-82 ** CB ** Symptom:Students can connect when they are not supposed to Cure: Add code to prevent them. Give funny error message when they fail Module: EXEC1 20-Mar-83 ** CB ** Symptom:SCRIBE can be used as a compiler but was not recognised by EXEC Cure: Add it as a language. Module: EXECCS 08-Aug-83 ** CB ** Symptom:No INFO FILE-TRANSFER command Cure: Add it Module: EXECQU, EXECGL, EXECIN 11-Sep-83 ** CB ** Symptom:No SET ENABLED/DISABLED PROMPT command Cure: Add it Module: EXECSE, EXECGL, EXECCA 11-Sep-83 ** CB ** Symptom:No SET TER nn MODE ... command (As in OLD-PCL) Cure: Add it Module: EXECSE, EXECGL, EXECCA 11-Sep-83 ** CB ** Symptom:Can't tell printer that file contains codes for scribe files Cure: Implement a /FILE:SCRIBE switch for the PRINT command Module: EXECQU 11-Sep-83 ** CB ** Symptom:All commands are UPPERCASE. Most untidy Cure: Make them lowercase. Module: All modules!! 13-Sep-83 ** CB ** Symptom:Teletypes still in use which can't print lowercase. Cure: Make commands uppercase again. Module: All modules!! 14-Sep-83 ** ARG ** Symptom:Pascal programs don't load Cure: Pass /RUN:link instead of !Link Module: EXECCS 14-Sep-83 ** ARG ** Symptom:Always get list files with Simula Cure: Don't output comma to Simula unless LST wanted Module: EXECCS 17-Nov-83 ** CB ** Symptom:Untidy code in LOGCHK and when it was called Cure: Rewrite LOGCHK and call it SETLOG and remove call in EXEC1. Module: EXEXEC, EXEC1 17-Nov-83 ** CB ** Symptom:INFO DOWNTIME is not very nice Cure: Make it read system tables instead of running MHALT Should also check for SYSTEM:MHALT.TXT and type it if there. Module: EXECIN 18-Nov-83 ** CB ** Symptom:Staff want to put files in class libraries but don't want students renaming them into their own directories. Cure: No spare bits which only Wheels can set but can use the file class field. Implement a value .FBNRN (renameable) which when set prevents file from being renamed. The file should also be set NO DELETEABLE. Module: EXECSE, EXECDE 18-Nov-83 ** CB ** Symptom:DEC were using the RH of .FBCTL to store a pointer to a name string. This clobbered the FB%NDL bit (bit 18). Cure: Stop using .FBCTL. Use .FBUSW instead. Module: EXEC3 26-Jan-84 ** CB ** Symptom:VT05 ttys can clear the screen but our VT05s are not real ones and can't use the real VT05 clear screen code. Cure: Replace the string which should be sent with a string containing 24 blank lines. Appalling isn't it. Module: EXEC1 13-May-84 ** CB ** Symptom:Want to take LOGOUT.CMD when logging out or KK'ing Cure: Add the code to do it. Module: EXEC1,EXECPR,EXECGL,EXECSU 13-May-84 ** CB ** Symptom:We have no way of knowing how many PUSHES we have done. Cure: Add command SET LEVEL-INDICATION and SET NO .. to turn it off. Module: EXECCA,EXECGL,EXECPR,EXECSU,EXECSE 14-May-84 ** CB ** Symptom:We have an AUTOPATCH tape but can't use it since we have a customized version of the EXEC Cure: Apply the patches by hand. 08-Jul-84 ** CB ** Symptom:Same as above but tape 7 Cure: Apply patches by hand. 18-Jul-84 ** CB ** Symptom:Cobol version 13 does not have a /W switch. Exec always passes one. Cure: Since Cobol always outputs warnings whether the /WARN switch is set or not we don't really need it. Thus we always set the bit to say that warnings are not required. They will be output anyway. Module: EXECCS 24-Jul-84 ** CB ** Symptom:Don't need Simula hack to prevent list files anymore. Cure: Remove it. Module: EXECCS 07-Sep-84 ** CB ** Symptom:Want range of numbers for NUMBER sub-command of BUILD command Cure: Add some code at NUMBE1 Module: EXEC4 21-Sep-84 ** ARG ** Symptom:Want to force everyone to use MS and not MAIL. Cure: Add the MAIL command which runs MS SEND. Module: EXEC1,EXECCA,EXECGL 01-Oct-84 ** CB ** Symptom:Need to be able to CANCEL a FILE-TRANSFER request Cure: Add the code to do it Module: EXECQU 05-Oct-84 ** ARG ** Symptom:ETYPE interpreted % when doing mail check typeout Cure: Fix it Module: EXECSU 05-Dec-*4 ** CB ** Symptom:COMPILE didn't recognise BCPL Cure: Add it to the language tables and remove some of the many versions of the COBOL extension. Module: EXECCS 10-Jun-85 ** ARG ** Symptom:Exec needs to talk to MM now, not MS Cure: Just change it Module: EXEC1 30-Oct-85 ** ARG ** Symptom:KKJOB command does not drop DTR on remote lines if not logged in Cure: Real solution lies in a monitor 'fix' but make KKJOB do a vanilla Logout if not logged in for now Module: EXEC1 ------- 7-Aug-86 11:08:44-PDT,1395;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Thu 7 Aug 86 11:08:06-PDT Date: Thu, 7 Aug 1986 14:10 EDT Message-ID: From: Rob Austein To: Bruce Tanner Cc: tops20@SU-SCORE.ARPA Subject: Exec hacks In-reply-to: Msg of 6 Aug 1986 18:12-EDT from Bruce Tanner Here's two EXEC mods that aren't much work and are a big win. 1) PRARG% fork control. You know the funny five instruction sequence that SOS (pardon me, EDIT-20) and EMACS (well, MIT-TECO) use to cause the EXEC to re-run the last COMPILE-class command? We added three similar codes, which cause the EXEC to KILL, KEEP, or CONTINUE,BACKGROUND the fork issuing the call after the next HALTF%. This is a major win, particularly when combined with the AUTOKEEP (;K) attribute. 2) SIXBIT user/directory group names. Our EXEC displays (and BUILDs) directory/user groups as a word of sixbit, rather than a decimal number. The monitor could care less, it just tests for equality. So my private directories are on group SRA instead of group 123456. To do the full-word version of this you need to do a little monitor work (change some HRRZs to MOVEs), but even a halfword of sixbit is a prettier than a number. --Rob 7-Aug-86 12:08:55-PDT,790;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 7 Aug 86 12:08:36-PDT Date: Thu 7 Aug 86 15:08:27-EDT From: Ken Rossman Subject: DECSA/Pluto To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12228964524.13.SY.KEN@CU20B.COLUMBIA.EDU> I've *finally* gotten our DECSA/Pluto DECnet router up and running fully. After batting a download problem around TOPS-20 for awhile, and getting past that, we had been having problems keeping nodes online with this thing. Now, after replacing the Protocol Assist Modules with higher revs, the thing works fine. Thanks to all of you who helped me figure this thing out! /Ken ------- 7-Aug-86 13:39:31-PDT,1283;000000000000 Return-Path: Received: from SRI-STRIPE.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Aug 86 13:39:10-PDT Date: Thu 7 Aug 86 13:41:23-PDT From: David L. Edwards Subject: Request for comments: IP Interrupts To: tops-20@SU-SCORE.ARPA In several programs which need to deal with IP directly, I have found that it would be useful to be able to receive an interrupt when a packet is placed into the queue. After kicking around the idea for a while, I have created a possible monitor interface. However, before implementing this interface, I would appreciate any comment or suggestions you might have (including any information of a possible previous implementation...) My proposal consists of defining an additional argument to IPOPR% as follows: .IPQIC (400001) Place specified Internet queue handle on software interrupt channel. AC2: Internet queue handle AC3: Channel number; -1 to remove An interrupt would be generated if the queue has an entry when the function is executed or when the state of the receive queue becomes non-empty. Subsequent entries would not cause an interrupt. The specified queue handle must be owned by the calling job. Your comments would be appreciated. -dle ------- 7-Aug-86 16:00:25-PDT,952;000000000000 Return-Path: <@SRI-KL.ARPA,@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Aug 86 16:00:05-PDT Received: from MIT-MULTICS.ARPA by SRI-KL.ARPA with TCP; Thu 7 Aug 86 16:02:00-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2701291016280201@MIT-MULTICS.ARPA>; 07 Aug 1986 18:36:56 edt Date: 07 Aug 86 10:56 +0200 From: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, tops-20@SRI-KL.ARPA Subject: File archival Message-ID: <193228@QZCOM> In-Reply-To: <193113@QZCOM> This is fascinating - but surely not for public consumption ? :-) Cheer up Theresa - our users also get upset when we migrate their files. 16-Aug-86 14:59:51-PDT,2242;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sat 16 Aug 86 14:59:39-PDT Date: Sat 16 Aug 86 17:59:07-EDT From: Thomas De Bellis Subject: NMLT20 and Galaxy problem solved To: Tops-20@SU-SCORE.ARPA Message-ID: <12231354889.293.SY.SLOGIN@CU20B.COLUMBIA.EDU> Thanks to a suggestion, I was able to pinpoint why I wasn't able to assemble 6.1 Galaxy with a 5.1 NMLT20 command table. The problem specifically was that I could not link OPR. It was looking for two symbols called NCPMAN and NCPDEV. This is because the new Galaxy uses a list of program version symbols which are assembled into any given module. That way, you can DDT the module and find out what version .REL's were used in the assembly. The new G$$ATB (in GALCNF) provides a generic method for generating the symbolic references and the linked module is expected to have them. I created a new module called NCPNUM which simply defined them to be 260,5. Everything linked up fine. The second problem was that NMLT20 just will not work in `standard' Galaxy debug mode. Any program that talks to Galaxy should go into private mode and get special PIDs (instead of the system ones) when a 1 is deposited into location 135. What can go into location 135 and what can happen is actually a little more complicated than this; I simplify for the purposes of explanation. If you drop a 1 into location 135 in NMLT20, it goes and gets private Galaxy PID's just fine and then blows up the minute you send it anything. This confused me; I solved the problem by getting suspicious and testing out the 6.1 NMLT20. It completely dies if you put a 1 in location 135. Has anybody been able to use NMLT20 in private Galaxy mode? Anyway, if you define NCPMAN and NCPDEV for OPR and the JFCL the MSTR%'s in MOUNTR at STSTR1+10 and STRDM0+13, a 6.1 Galaxy runs just fine. We tested it a few hours on last Friday on the 5.1 system and everything works. There were some raised eyebrows about the SYSTEM:DEVICE-STATUS.BIN getting rewritten, but there seem to have been no ill aftereffects. -- Thomas De Bellis Columbia Systems Group ------- 18-Aug-86 12:10:43-PDT,1737;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Per_Lindberg_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Aug 86 12:09:37-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2702228871714896@MIT-MULTICS.ARPA>; 18 Aug 1986 15:07:51 edt Date: 11 Aug 86 20:46 +0200 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, SU-etc@SUMEX-AIM.ARPA, Tops-20@SU-SCORE.ARPA, unix-wizards@BRL-AOS.ARPA, Boken@RED.RUTGERS.EDU Subject: Unix dead??? Message-ID: <194173@QZCOM> In-Reply-To: <12228476060.57.CRISPIN@SUMEX-AIM.ARPA> Well, he's good at humourous writing, no doubt. That was really funny! Although some of the laughs was on the writer... UNIX dead!? Well, in that case someone forgot to tell it so, because it hasn't stopped moving yet. And what about slow menu-oriented operating systems? I recall some unmentionable horror called P/OS which runs on the DEC Professional. It took only half a day for it to drive me crazy. And don't tell me you can put THAT in front of a naive user and expect him to be off on his own. (I have TEACHED univeristy-level engineering students (most of them with a Ph.D.) on how to use P/OS, and they had a hell of a time getting the knack of it. I have also been teaching C programming under UNIX, and that didn't cause any troubles at all). Enuff of this for now; I'm not going to waste any more time rebutting fools. If they prefer VMS (or was that MVS?), fine. Good luck. 18-Aug-86 15:39:56-PDT,387;000000000000 Mail-From: BILLW created at 18-Aug-86 15:39:52 Date: Mon 18 Aug 86 15:39:52-PDT From: William "Chops" Westfield Subject: domain bugfix... To: su-tops-20@SU-SCORE.ARPA Message-ID: <12231886596.15.BILLW@Score.Stanford.EDU> In GTDOM.MAC, at GTDRWT+4 or so, change CAME T1,JOBNO to CAME T1,GBLJNO The sources on Score have been corrected. BillW ------- 19-Aug-86 10:10:54-PDT,1445;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 19 Aug 86 10:10:14-PDT Date: Tue 19 Aug 86 13:10:24-EDT From: Melissa Metz Subject: .TITCE ATI% bug? To: Tops-20@SU-SCORE.ARPA cc: sluggo@CUNIXC.COLUMBIA.EDU Message-ID: <12232088763.305.SY.MM@CU20B.COLUMBIA.EDU> Key Phrase: Enabling an interrupt on a 2 character escape sequence has unexpected results Problem: Using the 6.1 version Exec from DEC, and the "Set Status-Watch" command, set an interrupt on the two character sequence "AB": Set Status-Watch Interrupt "AB" Now, as expected, when an "A" is typed it doesn't show up, since the monitor is waiting to see if the next letter is a "B". If it is a "B", the interrupt goes off (correctly). If any character besides "A" or "B" is typed, both the "A" and the second character are echoed. However, if another "A" is typed, one "A" is echoed. If four "A"'s are typed, two are echoed. If two "A"'s and then a "B" are typed, "AB" is echoed and no interrupt occurs. (Note that ^R doesn't affect what was echoed.) The monitor seems to be getting confused if it gets the first character of a two-character interrupt sequence twice in a row. Has anybody got any ideas about what's going on? -- Melissa Metz Columbia Systems Group ------- 19-Aug-86 16:57:20-PDT,926;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 19 Aug 86 16:57:03-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 19 Aug 86 16:47:11-PDT Date: Tue 19 Aug 86 16:10:07-PDT From: Mark Crispin Subject: Re: .TITCE ATI% bug? To: SY.MM@CU20B.COLUMBIA.EDU cc: Tops-20@SU-SCORE.ARPA In-Reply-To: <12232088763.305.SY.MM@CU20B.COLUMBIA.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12232154248.6.MRC@PANDA> Melissa - The behavior you describe for .TITCE seems perfectly reasonable. If you want the interrupt, you type "AB". If you want to send an "A" to the program, you type "AA". If you want to send "AB" to the program, you type "AAB". If you want to send "AC" to the program, you type "AAC" or as a hack you can send "AC". -- Mark -- ------- 19-Aug-86 17:29:50-PDT,1128;000000000001 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Tue 19 Aug 86 17:29:37-PDT Date: Tue 19 Aug 86 17:29:38-PDT From: Stu Grossman Subject: Re: .TITCE ATI% bug? To: SY.MM@CU20B.COLUMBIA.EDU cc: Tops-20@Score.Stanford.EDU, sluggo@[128.59.32.130] In-Reply-To: <12232088763.305.SY.MM@CU20B.COLUMBIA.EDU> Message-ID: <12232168722.16.GROSSMAN@Sierra.Stanford.EDU> The behavior you are seeing is intentional. It allows people to type in the character sequence AB by using the keystrokes AAB. If this behavior didn't exist, it would be much more difficult to generate the character sequence AB (you might have to use the keystrokes AxB for instance). Two character escape sequences were originally implemented for CTERM. CTERM is a network remote terminal protocol (on the order of TELNET). When it was implemented, it was deemed desirable to make escape sequences a little harder to type so that people wouldn't have to be so paranoid about which keystrokes would pop them out of the remote environment. ------- 20-Aug-86 00:15:26-PDT,587;000000000001 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Aug 86 00:15:15-PDT Date: Wed 20 Aug 86 00:17:40-PDT From: Mark Lottor Subject: hostname converter To: tops-20@SU-SCORE.ARPA Message-ID: <12232243004.18.MKL@SRI-NIC.ARPA> I wrote a little hack that will scan thru a text file and try to pick out mail addresses and replace any nicknames with the official host name. It appears to work fine on MAILING-LISTS.TXT and other distribution list type files. See PS:DOMNIT.EXE and DOMNIT.MID on the NIC. ------- 20-Aug-86 00:50:59-PDT,6140;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Aug 86 00:50:49-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 20 Aug 86 00:48:51-PDT Date: Wed 20 Aug 86 00:42:08-PDT From: Mark Crispin Subject: DEC's PDP's To: TOPS-20@SU-SCORE.ARPA, Boken@RED.RUTGERS.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12232247456.6.MRC@PANDA> A number of people have requested my list of all the DEC PDP's, so I thought I'd bore you all with it. The PDP-1 was an 18 bit machine. It was DEC's first computer, and some of the first timesharing systems were designed for it. It's also unique in being one's complement; all later DEC computers were two's complement. Some machines, such as one of MIT's PDP-1s, were in operation until the late '70s. The PDP-2 was a designation reserved for a 24 bit machine, but as far as I can tell it was never even designed and definitely none were ever built. The PDP-3 was a 36 bit machine that was designed but never built by DEC. However, Scientific Engineering Institute built one in 1960. The PDP-4 was an 18 bit machine that was intended to be a cheaper, slower alternative to the PDP-1. It was so slow that it didn't sell well, although it was interesting for its auto-incrementing memory registers. It was not program-compatible with the PDP-1, but its instruction set was the basis of DEC's future 18 bit computers. The PDP-5 was a 12 bit machine designed to be a small laboratory system. It used many of the ideas in the LINC (Laboratory Instruction Computer, designed by Lincoln Labs at MIT, some of which were built by DEC). The PDP-6 was a 36 bit machine and the first machine to implement the most wonderful computer architecture known to man. It was rather expensive and difficult to maintain, and not many were sold. As a result, DEC cancelled 36 bit computers for what was to be the first of many times. The PDP-7 was an 18 bit machine and the sucessor to the PDP-4. It was a major price/performance win over the PDP-4 and the first DEC computer to use wire-wrapping. The PDP-8 was a 12 bit machine and the sucessor to the PDP-8. It basically defined the term "minicomputer", and went through several incarnations. The original PDP-8 was followed by the extremely slow PDP-8/S (as bad as the PDP-4 was to the PDP-1, but at least the /S was program-compatible). DEC recouped with the PDP-8/I (using MSI integrated circuits) and the smaller PDP-8/L, and somewhat later came out with the "Omnibus 8" machines -- the PDP-8/E, the PDP-8/F (a half-sized version of the PDP-8/E), the PDP-8/M (an OEM version of the PDP-8/F), and the final machine, the single board PDP-8/A. The PDP-8/A still exists after a fashion as a current DEC product. The PDP-9 was an 18 bit machine and the sucessor to the PDP-7. It had a faster memory than the PDP-7 and was the first microprogrammed DEC computer. Modulo a 300 wire(!) ECO required in the first machines, the PDP-9 was a reliable machine and some are still in operation today. There was a short-lived PDP-9/L. The PDP-10 was a 36 bit machine and the sucessor to the PDP-6. It is especially noted for its software, which represents the pinnacle of DEC software engineering and has never been equalled. The first KA10, largely installed in universities, created a whole generation of timesharing hackers. The follow-on KI10, with paging and using IC's instead of discrete components but otherwise unexciting, mostly was sold to commercial organizations. The KL10 went through several incarnations and is today the most representative of this marvelous machine. The KS10 was a small, low-speed (approximately KA10 performance) processor which was DEC's last successful implementation of this architecture. The PDP-11 was a 16-bit machine that went through more implementations and operating systems than can be counted. Presently it superceded the less powerful PDP-8 as the representative minicomputer. While the PDP-11 used octal, it was in its deep heart of hearts a hexidecimal machine, and the first indicator of the creeping IBMification of DEC that took full fruit in the VAX. [I can hear the flames now...] Rather than fight it the customers loved it; more PDP-11's have been sold than any other DEC computer (possibly more than all the others combined). The PDP-12 was a 12 bit machine and the sucessor to the PDP-8. It combined a LINC and a PDP-8 type processor in the same box and basically was a new model of the LINC-8 which was the same thing. No PDP-13 was ever designed or built. Even DEC gets superstitious. The PDP-14 was a 12 bit machine with a 1 bit register. It was used as a process control engine in applications that were felt to be too rugged for a PDP-8, and basically replaced a set of relays. Later DEC made PDP-8's suitable for this sort of thing, but it didn't stop them from the ultimate silliness of building a PDP-14 that used a PDP-8 as its console processor! The PDP-15 was an 18 bit machine and the final one of this design built by DEC. More PDP-15's were built and sold than any of the others, and it went through several incarnations including some which used a PDP-11 as a front end. Apparently the cancellation of the PDP-15 came as a great surprise to the "Tiger Team" who worked on it, although considering its general ungainliness compared to comparable performance PDP-11's it wasn't surprising. In many ways the PDP-15 died for the same reason the PDP-10 did. The PDP-16 was a "roll your own" 16 bit machine based on various "building blocks". Every PDP-16 was essentially custom-designed by the customer. It got a fair amount of attention when it was announced but evidentally didn't sell very well. There was no PDP-17 or any other designator. DEC apparently decided that "PDP" had a perjorative ring to it. ------- 20-Aug-86 17:20:10-PDT,1839;000000000001 Mail-From: BILLW created at 20-Aug-86 17:20:05 Date: Wed 20 Aug 86 17:20:05-PDT From: William "Chops" Westfield Subject: Bugs in TCP LPTSPLing, TOPS20, and ethertip software. To: su-tops-20@SU-SCORE.ARPA, lougheed@SU-SCORE.ARPA, csc@SU-SCORE.ARPA Message-ID: <12232429127.15.BILLW@Score.Stanford.EDU> Well, you see there is the epson printer over in TERMAN that is connected to a TIP line, spoooling from sierra. It doesn't work - whenever a long file is printed, only part actually comes out, if anything at all happens.... After a little (read a LOT) of investigation, I think understand what is going on. The EPSON serial to parallel converter card sends out a ^Q every second or so when it doesn't have characters in its buffer. On the whole, I think this is a good idea - it prevents lock ups if one ^Q is lost somewhere. The TIP, if flow-control is enabled, will resume output only if it has been stopped - otherwise it sends the character on to the 20. LPTSPL of course, does not attempt to read from the line printer, so these characters are never received. Eventually, the TIP decides that it isn't getting much in the way of ACKS for data that it has sent, and times out the connection. The Bug in the TIP code is that after this happens, the connection seems to sit sround in a wedged state (subsequent attempts to connect to the same port succeed, and then immediately disconnect). The Bug in LTPSPL is that it should read any data that happens to exist from TCP LPTs, say every time it does a SOUT%. The Bug in TOPS20 is that there isn't any way to tell whether there is input pending on a TCP connection (unless its a TVT). Ill keep people informed of progress in correcting these bugs... Any additional insights will be appreciated... BillW ------- 20-Aug-86 17:29:12-PDT,692;000000000001 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Wed 20 Aug 86 17:29:06-PDT Date: Wed 20 Aug 86 17:32:33-PDT From: Stu Grossman Subject: Re: Bugs in TCP LPTSPLing, TOPS20, and ethertip software. To: BILLW@Score.Stanford.EDU cc: su-tops-20@Score.Stanford.EDU, lougheed@Score.Stanford.EDU, csc@Score.Stanford.EDU In-Reply-To: <12232429127.15.BILLW@Score.Stanford.EDU> Message-ID: <12232431399.17.GROSSMAN@Sierra.Stanford.EDU> Doesn't SIBE% work for the TCP: device? Also, I think that you can set up things so that you get a PSI whenever input is available from a JFN. Stu ------- 21-Aug-86 12:15:41-PDT,1413;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Aug 86 12:15:30-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 21 Aug 86 12:10:00-PDT Date: Thu 21 Aug 86 11:11:18-PDT From: Mark Crispin Subject: EXEC feature needed To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12232624137.6.MRC@PANDA> Something for the DEC people to consider as an EXEC enhancement. From time to time I have needed to change a file's byte size. I don't mean changing the byte size byte in the FDB, I mean also changing the data representation. Common changes are: 7 bit ASCII to 8 bit ASCII, 8 bit ASCII to 7 bit ASCII, 36 bit (1 byte/word right justified, a.k.a. paper tape image format) to 7 or 8 bit bytes, vice versa. I always write a little DDT program to do this, but it is somewhat annoying. What I would like to do is something like: @copy source.bin dest.bin, @@source bytesize 36 @@destination bytesize 8 @@ @ Another thing that really annoys me is that the EXEC TYPE and COPY commands ignore an 8 bit bytesize when the destination is TTY:. For example, @type 8-bit-file.txt and @copy 8-bit-file.txt tty: both lose. You have to do @copy 8-bit-file.txt tty:, @@byte 8 @@ I'd consider this a bug. ------- 21-Aug-86 12:29:03-PDT,5210;000000000001 Return-Path: Received: from DREA-GRIFFIN.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Aug 86 12:27:45-PDT Date: Thu, 21 Aug 86 16:11 ADT From: Peter Gergely Subject: Update to UDIRECTORY To: tops20@SU-SCORE.ARPA Message-ID: <860821161152.4.PETER@DREA-GRIFFIN.ARPA> Alias-Addresses: GERGELY@DREA-XX.ARPA and PETER@GRIFFIN.Drea.Dialnet.Symbolics.Com Postal-address: 9 Grove St., P.O. Box 1012, Dartmouth, NS B2Y 3Z7, Canada Phone-Number: (902) 426-3100 x 215 [8:30am to 4:15pm Atlantic time] Template-for-reply: COMPATIBLE-1R-REPLY-TEMPLATE Due to a few extra features that I wanted, UDIRECTORY has been enhanced. UDIRECTORY is a "universal" directory listing program for TOPS-20. It will show the status of ALL files in a directory. There is a sample output at the end of the message. The following changes have been made to the copy submitted to the decus library: * The output subcommand now takes an optional switch after the filename. The switch values are /NORMAL (default), or /FIELD-MODE (for later use in EMACS with FIELD mode, more on this later). * The AUTOMATIC subcommand takes an optional second argument for the number of significant chars to keep the sorted list on. * An extra subcommand for INCLUDE and OMIT, called BYTE-COUNT, which will include or omit the byte-count column respectively Availability: - Via ANONYMOUS FTP from DREA-XX the following files: PS:UDIREC*.* ;source and exe PCL:UDIRECTORY.PCL ;PCL interface, edit the ;filename within for ;your location PS:PJGSYM.* ;Required symbols, etc. PS:CMD.* ;The COMND interface. ;Pick it up if yours is ;different EMACS:FIELD.* ;The FIELD Library for ;emacs. It is sort of ;like a database package ;for EMACS. Written by ;me a long time ago. NOTE: I have no objections to anyone grabbing the stuff, but I would greatly appreciate some mail to the effect that you have so I can keep an update mailing list (rather than announcing to TOPS20). - Peter ======================================================================== Sample output generated by typing: UDIRECTORY PS:, OUTPUT TEST.TXT AUTOMATIC FILE 1 INCLUDE BANNER !BLANK LINE ======================================================================== NOTE: The status symbols are: * - Marked Bad File + - Directory File . - Directory has A - Archived D - Deleted subdirectories F - Fortran data file I - Invisible L - Long File N - Not created O - Offline P - Permanent or not Closed R - Archive Requested S - No save on backup T - Temporary File W - Last Write X - No delete not closed PS: Status Filename Pages Last Write Writer AMORT.SAI.35 42 18-Jul-86 14:02:21 GERGELY BBOARD.JOHNSON.1 9 18-Jul-86 14:02:23 GERGELY DE-LBR.EXE.1 4 18-Jul-86 14:02:24 GERGELY DIRECTORY.OWNER.3 1 18-Jul-86 14:02:24 GERGELY DOMNIT.EXE.6 1 20-Aug-86 09:14:10 MKL DOMNIT.MID.17 1 20-Aug-86 09:14:24 MKL AIO HEARTS.B20.22 23 18-Jul-86 14:02:25 GERGELY I QPRINT.SAI.290 25 18-Jul-86 14:02:26 GERGELY SCORE.EXE.1 6 18-Jul-86 14:02:27 GERGELY D TEST.TXT.9 3 21-Aug-86 15:28:17 GERGELY TEST.TXT.10 2 21-Aug-86 15:31:37 GERGELY TEST.TXT.11 1 21-Aug-86 15:33:14 GERGELY TesT.SAI.1 42 21-Aug-86 12:34:38 GERGELY UDIREC.MAC.45 22 21-Aug-86 12:37:04 GERGELY PS: contains a total of 159 Pages, 446163 Bytes, in 14 Files. 42 Pages, 105338 Bytes, in 1 File (A). 9 Pages, 22126 Bytes, in 1 File (B). 7 Pages, 11856 Bytes, in 4 Files (D). 0 Pages, 56715 Bytes, in 1 File (H). 25 Pages, 63129 Bytes, in 1 File (Q). 6 Pages, 15360 Bytes, in 1 File (S). 48 Pages, 115880 Bytes, in 4 Files (T). 22 Pages, 55759 Bytes, in 1 File (U). 3 Pages, 5932 Bytes, in 1 File (Deleted) 0 Pages, 56715 Bytes, in 1 File (Archived) 25 Pages, 119844 Bytes, in 2 Files (Invisible) 23 Pages, 56715 Bytes, in 1 File (Offline) ======================================================================== NOTE: the summary byte count above is calculated by multiplying the number of 7-bit bytes into the actual bytesize times the byte count. The byte count column if displayed will have the true file values. The summary byte count is strictly for information purposes if you have to download things to somewhere else. ======================================================================== ------- 21-Aug-86 16:31:15-PDT,1626;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Aug 86 16:30:43-PDT Return-Path: Received: from oslo-vax.uio.edu (OSLO-VAX.ARPA.#Internet) by SUMEX-AIM.ARPA with TCP; Thu 21 Aug 86 14:17:21-PDT From: Anders Ellefsrud Date: Thu, 21 Aug 86 22:18:33 -0100 Message-Id: <26145.8608212118@oslo-vax.uio.edu> To: Crispin@Sumex-Aim.Arpa Subject: Communication with QUASAR ReSent-Date: Thu 21 Aug 86 16:17:08-PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@SU-SCORE.ARPA ReSent-Message-ID: <12232679813.15.CRISPIN@SUMEX-AIM.ARPA> I have a problem with talking to QUASAR. Steinar Kjernsrod (steinar@oslo-vax) told me to contact you. ---- We are running TOPS-20 6.1. The problem is that we don't have source files available so I can't figure out the format of the message to MSEND to QUASAR. We want to write a program that can perform queue operations like printing files, submitting batch jobs and look at the queues. I actually have a listing of QSRMAC.MAC, but I think its a bit old. Its version number is 4.0(1230). I've also tried to look at the messages the EXEC MSENDs with the '@inf out' command, but I can't recognize anything of what it sends. What I CAN see is that it is quite different from the queue example (in Small Executive) in R. Gorins book. I would appreciate any hints of the format of the message to send to QUASAR, and also what I get back. Anders Ellefsrud Institute for Informatics University of Oslo, Norway anders@oslo-vax.arpa 21-Aug-86 16:44:21-PDT,603;000000000000 Mail-From: BILLW created at 21-Aug-86 16:44:06 Date: 21 Aug 1986 16:44-PDT Sender: BILLW@SU-SCORE.ARPA Subject: Re: Communication with QUASAR From: William "Chops" Westfield To: anders@OSLO-VAX.ARPA Cc: tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]21-Aug-86 16:44:05.BILLW> In-Reply-To: <26145.8608212118@oslo-vax.uio.edu> version 6.1 tops20 has a QUEUE% jsys that should make it unnecessary for you to format your own IPCF messages. Its documented in the 6.1 jsys reference manual, and ill send an online copy to Mr ellefsrud (its about 12K long...) BillW 22-Aug-86 05:57:25-PDT,729;000000000000 Return-Path: Received: from AFSC-HQ.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Aug 86 05:57:12-PDT Date: Fri 22 Aug 86 09:00:23-EDT From: Stephen M.King Subject: Mail from TOPS20 into a DecNetted Vax? To: tops20@SU-SCORE.ARPA Postal-address: HQ AFSC/SIRZ, Andrews AFB, DC 20334 Phone: (301)981-5134; AUTOVON: 858-5134 I've a Dec-2040 and Vax 11/785 with 2 DecNetted 780 nodes using Wollongong's software/hardware. I'm able to send/receive between other Vax's, etc but can NOT send from my 2040 into the DECNETTED nodes. Does anyone have any idea of what the address syntax might be? Called Wollongong... their 'suggestions' haven't worked. Thanks, Steve King ------- 23-Aug-86 04:29:38-PDT,864;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Peter_Lothberg_STUPI@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 23 Aug 86 04:29:19-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2702632393872083@MIT-MULTICS.ARPA>; 23 Aug 1986 07:13:13 edt Date: 20 Aug 86 21:51 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: [rende: Tops-20 ver 1 Message-ID: <196875@QZCOM> Is there anybody, who has or knews were to find a distribution of version 1 of Tops-20. Rumours tell that there is a KI-10 switch in the code. 25-Aug-86 17:25:24-PDT,959;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Aug 86 17:21:42-PDT Date: Mon 25 Aug 86 17:18:11-PDT From: Bruce Tanner Subject: Tape drive configuration To: TOPS-20@SU-SCORE.ARPA Message-ID: <12233739502.26.CERRITOS@USC-ECL.ARPA> We are going to replace 3 TU77s on 2 2060s with TU78s. We think that the cheapest and most flexible configuration is two dual-ported TU78 masters connected to both systems, giving us zero, one or two tape drives on either machine. Our CEs aren't very enthused about this configuration, without any real reason why it won't work. I recall that dual ported TU78s were discussed a couple of months ago and were said to work fine. Is there any problem with two TM78 controllers on an RH20? I would assume TOPS-20 would have an MTA and MTB set of devices. Has anyone tried this or know why it won't work? Thanks, -Bruce ------- 25-Aug-86 19:46:49-PDT,1666;000000000000 Return-Path: <@SUMEX-AIM.ARPA,@PANDA:CARL@SCU> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Aug 86 19:46:12-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 25 Aug 86 19:48:06-PDT Received: from SCU by PANDA with Cafard; Mon 25 Aug 86 18:46:01-PDT Date: Mon 25 Aug 86 17:43:37-PDT From: Carl Fussell On-Terminal: 31 Subject: DEC 2060 equipment To: tops-20@SU-SCORE.ARPA Message-ID: <12233744131.12.CARL@SCU> Our University has sold a basic 2060. This leaves us with some excess hardware that we were planning to sell to a broker. Before I do that, I tho't I might inquire to see if any sites out there might be interested in purchasing any of it (any offer considered... we are not really trying to make a lot of money off this). Anyway, if anyone is interested in something, let me know. It has all been under maint contract and DEC will be doing the deinstallation of everything. Quan Part Descript 5 DC20-AA 8-line basic async group 5 DC20-DA 8-line async expansion group 1 DC20-EC Comm Expansion Cabinet 1 DC20-CC Cables + Dist Cabinet for DC20-AA 1 MF20-LC 256K Internal Second Mem 3 MF20-E 256K Expansion 4 RH20 Internal Channel 1 RTP06-AA Disk Sys Controller + RP06-AA 1 RTP20-HA Master subsys/1091 (drive, controller, and DX20) 1 CI20-AA KL10 CI Port Adapter (almost brand new) If there should be anyone who is interested and replys, don't be concerned if I don't respond immediately... I will be out of town for about a week. Carl Fussell Santa Clara University G.FUSSELL@SU-SCORE.ARPA CARL%SCU%PANDA@SUMEX-AIM.ARPA ------- 25-Aug-86 21:18:55-PDT,3430;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 25 Aug 86 21:18:05-PDT Date: Tue 26 Aug 86 00:19:10-EDT From: Ken Rossman Subject: Re: Tape drive configuration To: CERRITOS@USC-ECL.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12233739502.26.CERRITOS@USC-ECL.ARPA> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12233783373.141.SY.KEN@CU20B.COLUMBIA.EDU> I probably started the discussion you were referring to... We plan to run 3 2065's and one VAX8650 (Ultrix) from four TU78's, which are set up as two masters and two slaves. The two masters will, of course, each have a dual port kit. We currently have one 2065 and the 8650 sharing one set of 78's, and this seems to work OK, except that you have to do things in the right order when switching the drives from the 8650 to the -20 (especially if the -20 rebooted while the drives were switched to the 8650). You need to first make sure there is no tape on the drive you are switching from the 8650 to the -20, then you need to switch it, then you need to put the tape up, THEN you need to PROBABLY set that tape drive available from OPR again (if you go through the mount system). We've seen it happen several times now that OPR will refuse to set a drive available even after the thumbwheel has been switched because MOUNTR doesn't yet believe it's there. A tape has to go up on the drive first, so that the controller "pings" the channel (I guess that's about as close a description of what I think is happening as I am technically capable of right now), so that MOUNTR knows it's there. Now, back before the 8650 came, we had those drives dual ported between two -20's, and we had problems when one system crashed and reloaded while the other system had the drives in use. I understand this is because the drive was busy at the time TOPS-20 pinged all its devices on the channel, and the controller didn't answer the ping so no controller or device blocks were set up in the monitor at the time. Try as we would at the time, we could not get the drives to be visible on the newly loaded system unless we reloaded. Since then, we just left the situation alone and didn't use those drives dual ported between two -20's. I was told back when we discussed this on the list awhile back that this was really a non-problem, and that if I just put a tape up with the drive switched to the proper system, and readied the drive, TOPS-20 would wake up and realize it was there finally. This was NOT my experience with the 78's dual-ported between two -20's awhile back (though I might have done something wrong)... however, we have had no problems along these lines other than the ones mentioned above with the drives ported between a -20 and the 8650. Seems to work fine that way. I *was* told, though, that I should not use thumbwheel position 2, which is the actual DUAL port position (drives visible by BOTH systems at the same time). I guess the software probably can't handle this (though in TOPS-20 if you keep track of where the drives are, you can just set them unavailable on one system and available on the other, and software regular them that way). Anyway, we just switch them back and forth physically using thumbwheel positions 0 and 1 to change systems. /Ken ------- 25-Aug-86 21:20:04-PDT,859;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 25 Aug 86 21:19:50-PDT Date: Tue 26 Aug 86 00:21:05-EDT From: Ken Rossman Subject: Re: Tape drive configuration To: CERRITOS@USC-ECL.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12233739502.26.CERRITOS@USC-ECL.ARPA> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12233783722.141.SY.KEN@CU20B.COLUMBIA.EDU> Oh, also, for a time, we had the 78's set as MTB's on the "other" system (the -20 that they weren't NORMALLY connected to) because that system had 77's on it also. Perhaps this was a source of some of our "drive not seen" problems, but we WERE able to use both the 77's and the 78's on the SAME system, same channel, no problem, as I remember. /Ken ------- 25-Aug-86 22:02:49-PDT,487;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Aug 86 22:02:37-PDT Date: Mon 25 Aug 86 22:05:04-PDT From: Bob Knight Subject: Re: Tape drive configuration To: CERRITOS@USC-ECL.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: <12233739502.26.CERRITOS@USC-ECL.ARPA> Message-ID: <12233791727.25.KNIGHT@SRI-NIC.ARPA> why have two masters? one master dual-ported with a slave will work just fine... bob ------- 26-Aug-86 14:24:52-PDT,1427;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 26 Aug 86 14:24:13-PDT Date: Tue 26 Aug 86 13:43:51-EDT From: Melissa Metz Subject: Reserved Channels for fork 0 To: Tops-20@SU-SCORE.ARPA cc: sluggo@CUNIXC.COLUMBIA.EDU Message-ID: <12233929860.151.SY.MM@CU20B.COLUMBIA.EDU> We're putting up a new version of the Columbia EXEC and we ran into a minor snag. The new EXEC incoporates an extra interrupt which is used for the SET STATUS-WATCH command (which we're rewriting to make nice). Our EXEC has lots of interrupts. In fact, we only have one or two spare channels left! The EXEC seemed to work fine when we tested it under another fork. However, when we used our modified PTYCON to set it up as fork 0, strange behavior resulted. The status watch interrupt kept popping the job into the mini-exec. This is without the job having been in the mini-exec before (meaning the code at EXEC2 in MEXEC hadn't fooled around with any of the interrupts yet). So we found something that is interesting: If you put SDDT in the top level fork and .FHSLF in AC1 and then do a RCM$X, you get a 3 in AC1. The monitor seems to want to reserve channels 34 and 35 for the top-level fork. 34 is used by the MEXEC. What is 35 used for? Who reserves channel 35? Does this mean that I can't use it? -- Melissa ------- 26-Aug-86 15:13:16-PDT,756;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Tue 26 Aug 86 15:11:39-PDT Date: Tue 26 Aug 86 13:30:37-PDT From: Bruce Tanner Subject: Re: Tape drive configuration To: KNIGHT@SRI-NIC.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12233791727.25.KNIGHT@SRI-NIC.ARPA> Message-ID: <12233960220.33.CERRITOS@USC-ECL.ARPA> The reason for two masters is (1) you can run one drive on both machines at the same time and (2) there is no single point of failure that will knock all your tape drives out. And we would treat the drives like dual-ported disks, i.e. never leave them in the A/B position, but mount and dismount (set available/unavailable) the units. -Bruce ------- 27-Aug-86 17:51:19-PDT,1115;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Wed 27 Aug 86 17:50:41-PDT Received: from (MAILER)INDYCMS.BITNET by WISCVM.WISC.EDU on 08/26/86 at 16:21:43 CDT Received: by INDYCMS (Mailer X1.23) id 7530; Tue, 26 Aug 86 08:10:57 EDT Date: Tue, 26 Aug 1986 07:51 EDT From: Mark H. Wood Subject: TU78s dual-ported between '20s To: We have been doing this for several years here, with few problems. We DO use the thumbwheels rather than SET [UN]AVAILABLE. There is a patch to PHYM78 that makes the lost-drives-on-reboot problem happen much less often: replace INIUNI+5/ TRNN T1,240 with INIUNI+5/ TRNN T1,DI.PRS which causes the initialization code to ask the drive, "are you present," instead of, "are you available or in maintenance mode?" I SPR'ed this in 1984 (20-20370, 1-Nov-84 p. 4-14) but DEC has been unable to reproduce the problem. If this patch helps anyone, I'd appreciate it if you'd tell DEC. 28-Aug-86 10:03:42-PDT,1100;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 28 Aug 86 10:03:26-PDT Date: Thu 28 Aug 86 10:42:06-EDT From: Thomas De Bellis Subject: DIRTST To: Tops-20@SU-SCORE.ARPA Message-ID: <12234421061.37.SY.SLOGIN@CU20B.COLUMBIA.EDU> Recently we were checking out some problems with our RA81 disks and we ran DIRTST to look over all the directory files. We got quite a scare when it blew up saying that it couldn't even map a file's page table. It turns out that the version of DIRTST that we have doesn't check the FDB's of files that it is scanning and it will try to map any file as a directory file. So, if some wise guy makes a file called FOO.DIRECTORY in his directory (say, to list all his foo's), DIRTST croaks on it. The fix is to make DIRTST check the control word of the the file's FDB and skip any non-directory file. I've put a copy of DIRTST.MAC up on SCORE in PS: for general perusal. Does any one know if this is the latest available? -- Tom ------- 28-Aug-86 10:04:15-PDT,2105;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 28 Aug 86 10:03:44-PDT Date: Thu 28 Aug 86 11:07:33-EDT From: Thomas De Bellis Subject: Re: Communication with QUASAR To: Tops-20@SU-SCORE.ARPA cc: Crispin@SUMEX-AIM.ARPA, anders@OSLO-VAX.ARPA, steinar@OSLO-VAX.ARPA In-Reply-To: Message from "The Mailer Daemon " of Fri 22 Aug 86 16:58:52-EDT Message-ID: <12234425693.37.SY.SLOGIN@CU20B.COLUMBIA.EDU> I got asked about how to talk to Quasar under a 6.1 monitor a few days ago. I've dusted off a few programs and put them up on SCORE in PS: for general perusal. These are QCOUNT and LPTQUA. QCOUNT asks Quasar to send back a list of its internal counters. It's a good example on how to use page mode IPCF to talk to Quasar. The counters are fun to read, I guess. LPTQUA asks for a file and forms name and submits a print request to Quasar--it is probably the more directly useful of the two. Both these files are quite old; I believe I wrote them in 1981. So some of my ideas about symbol usage were incorrect, instead of doing something like a STORE FOO,L.BAR_-^D18,BAZ; you should use the GLXLIB STOLIM Macro and do STOLIM FOO,BAZ,BAR (I was unaware of it at the time). The IPCF interface into Galaxy has not changed substantially since 1980 (when I started looking at it); this may be in part to it being so hairy. At any rate, just about any copy of QSRMAC is good to stare at, but you are also going to need GLXMAC as this contains the Galaxy message header definitions. Tops-20 6.1 provides a jsys to allow a program to send requests to Quasar--I believe it is called the QUEUE% jsys. The new Quasar has some code to field these operating system requests. It may be easier to use QUEUE% if it is documented then writing a whole program from scratch. Since we had allready done this (a number of times), we never bothered to look at it. I don't know of any program that uses QUEUE%, unfortunately. -- Tom ------- 31-Aug-86 05:14:01-PDT,1695;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Aug 86 05:13:57-PDT Date: Sun 31 Aug 86 05:16:13-PDT From: Mark Crispin Subject: KLINIK's To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12235180936.12.CRISPIN@SUMEX-AIM.ARPA> Friends - I thought it might be a good idea if we could collect all the KLINIK phone numbers and passwords currently in use on the Stanford 20's into a single database. I'd also encourage the connection and default enabling of a KLINIK for all our systems, but that's another issue. This came up a few minutes ago, when a user reported to me that Sushi was down and it apparently was not coming back up. The best I could do was tell him to call BillW. It seems a shame to wake up a system hacker at 5AM on Sunday morning when there is an insomniac hacker online who might have been able to help if only he knew how to get to Sushi's KLINIK (that is, if Sushi *has* a KLINIK). I also suggest that some sort of "current state" document be drawn up describing the present known status and behavior of all the 20's. This would be extremely useful to a foreign hacker trying to figure out what (if anything) to do. It can range from "Score has a logic analyzer to catch the cause of our CRAM crashes. If Score crashes, don't touch!" to "Sierra gets into this hung state where instead of entering BOOT it just sits there. To fix it, do a FORCE MF20 configuration." (both of these are examples and are not to be taken seriously!). -- Mark -- ------- 3-Sep-86 05:24:13-PDT,798;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Sep 86 05:24:00-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 3 Sep 86 05:24:57-PDT Date: Wed 3 Sep 86 04:08:43-PDT From: Mark Crispin Subject: LINK hint To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12235955081.7.MRC@PANDA> If you are having problems with LINK looping in its SYCHR1 routine, add a /COUNTER to your LINK commands after loading all your REL files and look for a PSECT overlap. It appears that LINK doesn't report PSECT overlaps until well into the /GO processing and the SYCHR1 endless loop bug will bite you long before that. ------- 3-Sep-86 22:23:30-PDT,1323;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Sep 86 22:23:12-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 3 Sep 86 22:24:32-PDT Date: Wed 3 Sep 86 20:50:44-PDT From: Mark Crispin Subject: RM03 madness To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12236137493.10.MRC@PANDA> Anybody out there have an idea on this one? I have an RM03 that periodically goes out to lunch with a voltage fault (anyway, that's what the LED on the fault board indicates). Except for one occurance, the front panel FAULT button clears the fault; on the one occurance the fault board fault clear switch cleared it. This problem happened when I first got that drive, but it ran away and hid when I started debugging. My first impulse was to suspect the drive power supply boards, so I swapped all three of them with the supplies in another known working drive. The problem recurred on the same drive. The other thing the service manual suggested was a bad fault board. I swapped it as well. Again the problem did not move. I'm stumped, and of course the problem isn't solid. I'm almost tempted to swap out that drive. ------- 6-Sep-86 00:11:20-PDT,913;000000000000 Return-Path: Received: from BUCS20.BU.EDU by SU-SCORE.ARPA with TCP; Sat 6 Sep 86 00:11:04-PDT Date: Sat 6 Sep 86 03:10:25-EDT From: Philip Budne Subject: BUCS20 Yard Sale To: tops-20@SU-SCORE.ARPA Message-ID: <12236698132.21.BUDD@BUCS20.BU.EDU> The Boston University CS KL has a week to live, so I've decided to set up a yard sale of fun things I've written or collected over the years. Its all in PS: on BUCS20.BU.EDU [192.12.185.20] <.UDP> Source for my UDP: device <.HACKS> Misc hacks CTYSPY keeps last 60 lines of CTY output in a PMAP file CRAWL (+CREEP) Crawls around DECnet's to discover topology VMESS Get phone directories of all local nodes CZ Unix like CD with command completion SRCCOM COMND-ized ITS srccom (w/ interactive merge) <.PHONE> VMS compatible phone <.RSH> An almost working RSHD + RSH program ------- 6-Sep-86 12:43:34-PDT,933;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 6 Sep 86 12:43:22-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 6 Sep 86 12:40:36-PDT Date: Sat 6 Sep 86 11:39:58-PDT From: Mark Crispin Subject: SPR 20-17812 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12236823660.7.MRC@PANDA> The patch in this SPR as published has a bug that breaks escape after numeric fields. Here's my suggested replacement, at CMNUMR+2: CAME T1,T2 ;NIN SAW WHOLE FIELD? IFSKP. JXN F,CM%ESC,XCOMXR ;DON'T DO THIS IF SAW AN ESCAPE CALL RDCRLF ;MAKE SURE CM%EOC LIT IF APPROPRIATE IFSKP. CALL UNCRLF ;BACK UP OVER CRLF ELSE. CALL CMDIP ;BACK UP OVER NON-CRLF ENDIF. JRST XCOMXR ;RETURN NUMBER ALREADY IN T2 ENDIF. ------- 6-Sep-86 20:31:29-PDT,451;000000000000 Mail-From: GROSSMAN created at 6-Sep-86 20:31:25 Date: Sat 6 Sep 86 20:31:25-PDT From: Stu Grossman Subject: Software dispatch and autopatch To: su-tops-20@SU-SCORE.ARPA Message-ID: <12236920406.9.GROSSMAN@Score.Stanford.EDU> Does anybody at Stanford currently receive the TOPS-20 Software Dispatch and/or Autopatch distribution? If so, please let me know as I would like to borrow them. Thanks, Stu ------- 7-Sep-86 00:46:00-PDT,1336;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 7 Sep 86 00:45:55-PDT Date: Sun 7 Sep 86 00:45:11-PDT From: Mark Crispin Subject: Re: Software dispatch and autopatch To: GROSSMAN@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: <12236920406.9.GROSSMAN@Score.Stanford.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12236966605.11.CRISPIN@SUMEX-AIM.ARPA> Stu - At one time LOTS was the central point that all the Software Dispatches and Autopatch tapes came to. They should still be getting all that stuff. If not, I have a complete 6.1 distribution set with TCP/IP and DECnet, RSX VB15-21, KL ucode 407, and Autopatch tape #13 (including monitor and EXEC sources). I also have almost two years' worth of Software Dispatches and CTCO's at home which you can borrow. I'm a bit reluctant to lend my tapes out (I can't replace them!), but I have all the files loaded on a disk pack and all set up for an Autopatch run (everything is SELECTed). If you let me use a scratch RP06 pack and your KL I can copy my pack to tape, run Autopatch on your machine, take a copy back and leave you with a 6.1 AP20: pack Autopatched up to AP13. -- Mark -- ------- 7-Sep-86 08:17:10-PDT,2310;000000000000 Return-Path: Received: from cu-arpa.cs.cornell.edu by SU-SCORE.ARPA with TCP; Sun 7 Sep 86 08:16:50-PDT Message-Id: <8609071515.AA27238@cu-arpa.cs.cornell.edu> Received: by cu-arpa.cs.cornell.edu (5.45/4.30) id AA27238; Sun, 7 Sep 86 11:15:56 EDT To: Philip Budne Cc: tops-20@su-score.arpa Subject: Re: BUCS20 Yard Sale In-Reply-To: Your message of Sat 6 Sep 86 03:10:25-EDT. <12236698132.21.BUDD@BUCS20.BU.EDU> Date: Sun, 07 Sep 86 11:09:24 -0500 From: george@vax1.ccs.cornell.edu Your sale prompts me to tell the following story. We traded our '20 in on an 8500 and are currently doing a conversion. We decided to set a deadline of 9/1 and also set our maintenance contract to expire on that date. Hello, Murphey? The machine proceeded to commit suicide at 00:30 8/30 (Saturday morning), with an SBUS error message we had never before seen. While still under contract, our coverage was 9-5 M-F. Thus we calculate that it took slightly over 7 hours of non-contract maintenance for our '20 (2065) to determine that it would *not* go out with out a bang. Of course it (err, he) couldn't know (?) that the local office would agree to fix it (him). They arrived 9/3 to perform surgery... Not having the proper replacement board, they scheduled repair for 9/4. They left for the day with the machine running. Sigh. You would think we would have learned that this was a machine sick with emotional problems.... The '20 shut off two fans, without tripping an air-flow sensor, and proceeded to try and fry itself. We seem to have caught it (him) in time and DEC returned to finish repairs last Friday. Post surgery tests ran without a flaw and the repair team left for lunch with the machine booting... Sigh. The machine hung after the resident monitor loaded. More repair, more tests. Much later in the day we discover that the master tape unit was off causing the massbus and the boot process to hang. DEC is returning Monday with more parts. The story, I am sure, is not over. But I am *NOT* going in to work this weekend. Let the machine die, I say. Long live KL. Long live TOPS. George Boyce, Academic Computing, Cornell University george@vax1.ccs.cornell.edu (128.84.252.10), george@crnlcs.bitnet 8-Sep-86 06:25:50-PDT,3009;000000000001 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 8 Sep 86 06:25:31-PDT Date: Mon 8 Sep 86 09:23:40-EDT From: Thomas De Bellis Subject: LPTSPL and TCPSPL bug To: Tops-20@SU-SCORE.ARPA Message-ID: <12237290366.276.SY.SLOGIN@CU20B.COLUMBIA.EDU> I sent this message a couple of days ago, but I guess our mailer got hungry... Problem: Defining a printer with a unit number greater than 9 breaks LPTSPL (and any other printer spooler based on LPTSPL such as TCPSPL). We have many, many printers on campus which just got connected to our DEC20's via TCP/IP and defining printers in LPFORM.INI worked just fine until we got to unit 10. Then LPTSPL could never seem to find the associated forms for the printer. Diagnosis: The GENDEV routine in LPTSPL is used to construct a line printer `key' of the form LPTxxx, where xxx is a 3 digit decimal number with leading zeros. This key is used to search the LPFORM.INI file for corresponding unit forms definitions. GENDEV uses an algorithm which only works for printer unit numbers of the range 0 to 9. It directly adds SIXBIT /LPT000/ to the unit number to come up with printer keys of the form LPT001, LPT002, etc. This obviously breaks on anything higher than 9. If you do try unit 10, you get a key like 'LPT00:'--the LPFORM.INI parsing routines will never find this. Cure: Fix the code to do the addition correctly. More or less, this means aligning the bytes of the number that is to be added on sixbit byte boundaries. Old: ADD S1,OBJ.UN(T1) ;ADD THE UNIT NUMBER. ADD S1,[SIXBIT/LPT000/] ;CREATE THE PHYSICAL DEVICE NAME. GEND.1: MOVEM S1,J$LDEV(J) ;AND SAVE IT New: ADD S1,OBJ.UN(T1) ;ADD THE UNIT NUMBER. TOPS20 <$CALL SIXOFF > ;CU30 ;Convert to sixbit offset ADD S1,[SIXBIT/LPT000/] ;CREATE THE PHYSICAL DEVICE NAME. GEND.1: MOVEM S1,J$LDEV(J) ;AND SAVE IT ;Insert this routine someplace REMARK Routine to convert a decimal number in S1 to sixbit offset ;CU30 Expects number in S1. Recursively peels off digits and stuffs them ; on the stack. These digits are then pulled off and shifted into the ; right place. Expects to be able to clobber S2 SIXOFF: IDIVI S1,^D10 ;CU30 ;Pull off a digit PUSH P,S2 ;CU30 ;Save the remainder JUMPE S1,SIXOF1 ;CU30 ;Jump if nothing left $CALL SIXOFF ;CU30 ;Call ourselves with reduced number ;CU30 ;Note that we return to SIXOF1 ;CU30 ;First time S1 will be zero SIXOF1: POP P,S2 ;CU30 ;Get the number LSH S2,^D30 ;CU30 ;Shift to upper 2 sixbit bytes LSHC S1,^D6 ;CU30 ;Now shift the combined acs over $RET ;CU30 ;Return someplace This code is running on Columbia computer center machines. We've had no problems with it. It will work with up to 999 printers which other parts of Galaxy will correctly handle internally. -- Thomas De Bellis Columbia Systems Group ------- 8-Sep-86 10:34:46-PDT,1018;000000000000 Mail-From: ALDERSON created at 8-Sep-86 10:34:21 Date: Mon 8 Sep 86 10:34:19-PDT From: Rich Alderson Subject: Re: Software dispatch and autopatch To: GROSSMAN@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: <12236920406.9.GROSSMAN@Score.Stanford.EDU> X-Organization: Stanford University X-Office-Address: LOTS Computing Facility; Sweet Hall, 4th Floor; Stanford, CA 94305 X-Office-Phone: (415) 723-4159 X-Postal-Address: 1885 California Ave. #75; Mountain View, CA 94041 X-Home-Phone: (415) 965-4337 (residential office) Message-ID: <12237335998.44.ALDERSON@Score.Stanford.EDU> Due to the same bureaucratic brouhaha that kept us from receiving the SDC release of version 6.1, we have received neither the Software Dispatches nor the Autopatch tapes for the past year. Digital is looking into sending us the back issues of the Dispatches; presumably, when we receive the correct SDC release, it will be up-to-date wrt the autopatch tapes. Rich ------- 8-Sep-86 11:37:50-PDT,1589;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Sep 86 11:37:10-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 8 Sep 86 11:34:02-PDT Return-Path: <@SUMEX-AIM:RASPUZZI@TOPS20.DEC.COM> Received: from SUMEX-AIM by PANDA with Cafard; Mon 8 Sep 86 07:45:21-PDT Received: from TOPS20.DEC.COM by SUMEX-AIM.ARPA with TCP; Mon 8 Sep 86 07:27:32-PDT Date: 8 Sep 1986 1025-EDT From: "Michael Raspuzzi" To: mrc%panda@sumex-aim.arpa Loc/MS: "MRO1-2/L14 (Pole M13)" Phone: "DTN 297-2346 (617-467-2346)" Quote: "If my grandmother had wheels, she'd be a wagon." Subject: Patch for edit spr 17812 Message-ID: <"MS11(6001)+GLXLIB5(0)" 12237301615.15.140.10984 at TOPS20.DEC.COM> ReSent-Date: Mon 8 Sep 86 10:58:03-PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@SU-SCORE.ARPA ReSent-Message-ID: <12237340318.7.MRC@PANDA> Mark, Seems the incorrect DDT file was sent with the answer to that SPR. Here is the correct one that made it to the autopatch tape. Mike **** Note - This patch applies to 4.1 ONLY if you have edit number 7248 to COMND. @ENA $GET SYSTEM:MONITR.EXE $ST 140 DDT FFF/ 0 CMNMR1: TLNE 400000 FFF+1/ 0 JRST XCOMXR FFF+2/ 0 CALL RDCRLF FFF+3/ 0 JRST FFF+6 FFF+4/ 0 CALL UNCRLF FFF+5/ 0 JRST XCOMXR FFF+6/ 0 CALL CMDIP FFF+7/ 0 JRST XCOMXR FFF+10/ 0 FFF: CMNUMR+3/ JRST XCOMXR# JRST CMNMR1 ^Z $SAVE SYSTEM:MONITR.EXE PS:MONITR.EXE.2 Saved -------- 8-Sep-86 14:15:25-PDT,1314;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Mon 8 Sep 86 14:14:23-PDT Received: from philabs.UUCP by seismo.CSS.GOV with UUCP; Mon, 8 Sep 86 16:22:49 EDT Received: by philabs.uucp (4.12/3.14) id AA24545; Mon, 8 Sep 86 15:53:22 edt Date: Mon, 8 Sep 86 15:53:22 edt From: Return-Path: Message-Id: <8609081953.AA24545@philabs.uucp> To: philabs!seismo!TOPS20@SU-SCORE.ARPA Subject: fastest file copy A few questions on copying file pages: 1. What is the fastest technique for copying pages from one file to another file? The kind of answer I'm looking for is a detailed one, describing the bits in the PMAP JSYS, etc. A fragment of MACRO code showing the loop to copy the pages would be perfect. 2. Defend the answer you gave to Question 1. Compare it to another "fast" algorithm and argue why it's faster. 3. Which releases of the EXEC (if any) use this algorithm in the COPY command? Alternatively, are there any public-domain utilities that use it (and how could one obtain same)? Thanks in advance for any help you can offer. Rick Ace ARPA: philabs!nyit!rick@SEISMO.ARPA UUCP: {allegra, decvax, seismo}!philabs!nyit!rick 9-Sep-86 06:15:02-PDT,553;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Tue 9 Sep 86 06:14:45-PDT Date: Tue 9 Sep 86 08:13:15-CDT From: Donald Blais Subject: Finger for 6.1 To: tops20@SU-SCORE.ARPA Message-ID: <12237550614.51.CC.BLAIS@R20.UTEXAS.EDU> Does anyone have a version of Finger that works with 6.1 or one that gets host information without loading the host tables? We want to regain the ability to use Finger for remote sites now that domain style addressing is in use. ------- 10-Sep-86 13:04:42-PDT,1409;000000000000 Return-Path: Received: from MCC.COM by SU-SCORE.ARPA with TCP; Wed 10 Sep 86 13:03:44-PDT Date: Wed 10 Sep 86 14:51:05-CDT From: Clive Dawson Subject: DELNI Strangeness To: tops20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <12237885182.55.AI.CLIVE@MCC.COM> Here's a bit of info to add to the general folklore: We moved to a new building last week, and after putting everything back together, we found that TELNET connections from our Sun workstations to our DEC-20 (they're on separate Ethernets, gateway is a Sun) were suffering from horribly poor throughput. Echo delays ranged from 1 to 10 seconds, with no load to speak of on any of the systems or the nets. After being stumped for a couple of days, we finally realized that the only thing that had changed was that the Sun gateway and the DEC-20 were now sharing the same DELNI, whereas before they had been on two different DELNIs. We made a quick switch and put the Sun onto its own transceiver two meters away from the DELNI's transceiver. The results were immediate and dramatic. Echoing delays disappeared completely and users were once again happy. Now the obvious question: Does anybody have an explanation? Is there something fundamentally different about intra-DELNI communication that could cause such enormous performance problems? Thanks, Clive ------- 10-Sep-86 15:56:04-PDT,650;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 10 Sep 86 15:54:48-PDT Date: Wed 10 Sep 86 19:53:20-ADT From: Peter Gergely Subject: XMODEM transfers for a DEC-20? To: tops20@SU-SCORE.ARPA, info-mac@SUMEX-AIM.ARPA Postal-address: 9 Grove St., P.O. Box 1012, Dartmouth, NS B2Y 3Z7, Canada Phone-Number: (902) 426-3100 x 215 [8:30am to 4:15pm Atlantic time] Message-ID: <12237918361.14.GERGELY@DREA-XX.ARPA> Does anyone have a program to allow XMODEM transfers to and from a DEC-20. It would be really nice if it could support MACBINARY as well. - Peter ------- 10-Sep-86 16:21:30-PDT,1049;000000000000 Mail-From: BILLW created at 10-Sep-86 16:21:15 Date: 10 Sep 1986 16:21-PDT Sender: BILLW@SU-SCORE.ARPA Subject: Re: XMODEM transfers for a DEC-20? From: William "Chops" Westfield To: GERGELY@DREA-XX.ARPA Cc: tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]10-Sep-86 16:21:14.BILLW> In-Reply-To: <12237918361.14.GERGELY@DREA-XX.ARPA> There exists both MACGET/MACPUT and MODEM for tops20. the former are distriubuted from SUMEX (from the directory), and the latter from SIMTEL20 (something like PD:TMODEM.MAC). The MODEM is particurally featurful, allowing use as both XMODEM (eg dial into the 20), and MODEM (dial out of the 20). It was also written with efficiency in mind, and can do local transfers at 9600 bps without many retransmissions being required. I am somewhat biased, having written the original version. Frank Wancho and others have made significant improvemts since then, especially in getting it to work over questionable paths to unusual machines. BillW 10-Sep-86 21:32:05-PDT,999;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 10 Sep 86 21:30:51-PDT Date: Wed 10 Sep 86 20:07:50-MDT From: Frank J. Wancho Subject: Re: XMODEM transfers for a DEC-20? To: GERGELY@DREA-XX.ARPA cc: tops20@SU-SCORE.ARPA, info-mac@SUMEX-AIM.ARPA, WANCHO@SIMTEL20.ARPA In-Reply-To: <12237918361.14.GERGELY@DREA-XX.ARPA> Message-ID: <12237953768.6.WANCHO@SIMTEL20.ARPA> Peter, What you want is TOPS-20:TMODEM.MAC from here. TMODEM is a cross between the old TOPS-20 MODEM and DIAL programs by Bill Westfield and the TELNET program. TMODEM has all the lastest extensions to the so-called "xmodem" protocol, including CRC or CHECKSUM, wildcard "batch mode" transfers, and 1K packet options with fall-back and fall-up. Extensive help text is built-in in the traditional TOPS-20 style. Bugs to BUG-TMODEM@SIMTEL20. Send to INFO-TMODEM-REQUEST@SIMTEL20 to get on the announcements list. --Frank ------- 11-Sep-86 15:46:24-PDT,992;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 11 Sep 86 15:45:31-PDT Date: Thu 11 Sep 86 18:43:55-EDT From: Ken Rossman Subject: KL Keepalives and NI microcode bugs (?) To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12238178790.152.SY.KEN@CU20B.COLUMBIA.EDU> Folks, if any of you are still having Keepalive (or KPALVH) KL halts that appear to be NI related, we may finally have an answer for that one. DEC has found and fixed some bugs in the NI microcode (KNILDR). We're only just running the new version here as of a few hours ago today, but I do know that a site in downtown Manhattan that was previously able to crash their system at will with a certain network program is now no longer able to do so when running the new microcode. The new KNILDR is V1(170). Drop me a note if you need it. /Ken ------- 12-Sep-86 07:05:12-PDT,930;000000000000 Return-Path: Received: from A20.CC.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 07:04:04-PDT Date: Fri 12 Sep 86 09:03:16-CDT From: CC.GALVIN@A20.CC.UTEXAS.EDU Subject: Building a 6-1 non-CI monitor To: tops20@SU-SCORE.ARPA Message-ID: <12238346151.9.CC.GALVIN@A20.CC.UTEXAS.EDU> We're trying to build a non-CFS, no KLIPA monitor from sources (we have NI but not CI). Unfortunately, turning off the 4 CI-related switches in SYSFLG (ftklipa,ftmscp,mscdbg, and cfssca) cause some 50 undefined globals to appear. From looking at the code causing the errors it appears that there are many occurences where CI-related code was not surrounded by appropriate conditionals. Has anyone succeeded in build a monitor in this way? I find it hard to believe that DEC never tried turning off CI and compiling the monitor, but that's what the evidence suggests. --Pete ------- 12-Sep-86 08:01:40-PDT,845;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 08:01:19-PDT Date: Fri 12 Sep 86 10:58:18-EDT From: Robert C McQueen Subject: Fall DECUS Symposium Pre-Symp Seminars To: TOPS-20@SU-SCORE.ARPA Message-ID: <12238356171.201.SIT.MCQUEEN@CU20B.COLUMBIA.EDU> The Large Systems SIG is sponsoring two pre-symposium seminars. One of the seminars may be cancelled due to lack of interest. If you are interested in attending the TOPS-20 6.1 Performance Analysis and Tuning seminar, I'd suggest that you send your registration in very soon. The seminar is being run because of requests by several people who were "VAX System Managers" who are now having to run a -20. Bob McQueen Large Systems SIG Symposium Coordinator ------- 12-Sep-86 08:26:45-PDT,773;000000000000 Return-Path: Received: from SRI-STRIPE.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 08:26:24-PDT Date: Fri 12 Sep 86 08:25:40-PDT From: David L. Edwards Subject: Re: KL Keepalives and NI microcode bugs (?) To: sy.Ken@CU20B.COLUMBIA.EDU cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Rossman " of Thu 11 Sep 86 23:10:30-PDT Unfortunately, one of our -20's which has been experiencing Keepalives which are NI related, got another under the new version of the NI microcode. We had been running in the 'risky' configuration for approximately 5 hours and will continue to do so until the crashes become intolerable again. DEC is continuing to investigate. -dle ------- 12-Sep-86 08:43:30-PDT,1166;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 08:43:03-PDT Date: 12 Sep 1986 1141-EDT From: "David Lomartire" To: David L. Edwards , sy.Ken@CU20B.COLUMBIA.EDU cc: TOPS-20@SU-SCORE.ARPA DTN: 297-5508 Mailstop: MRO1-2/L10 Subject: Re: KL Keepalives and NI microcode bugs (?) Message-ID: <"MS11(6001)+GLXLIB5(0)" 12238364075.116.209.16540 at TOPS20.DEC.COM> References: Message from David L. Edwards of 12-Sep-86 1135-EDT We have investigated the dump in question at SRI and found that the wrong version of the NI microcode was in use at the time; version 167. However, the other SRI system has been running the new version (170) for over 20 hours. Currently, the SRI system KL is still running with the old microcode and may continue to experience the KPALVH problem. Note that version 170 is NOT going to be the final, supported version of the microcode. This version contains various diagnostic features which will be removed. The final version will be 171. Dave -------- 12-Sep-86 09:11:02-PDT,1792;000000000000 Return-Path: <@po2.andrew.cmu.edu:leong@andrew.cmu.edu> Received: from po2.andrew.cmu.edu by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 09:10:20-PDT Received: by po2.andrew.cmu.edu (4.12/3.15) id ; Thu, 11 Sep 86 19:59:21 edt Received: FROM leong VIA queuemail ID ; Thu, 11 Sep 86 19:59:04 edt Message-Id: Date: Thu, 11 Sep 86 19:58:36 edt From: leong@andrew.cmu.edu (John Leong) To: AI.CLIVE@MCC.COM Subject: Re: DELNI Strangeness Cc: tops20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA Clive, I don't really know what specifically is your problem with the DELNI. However, one thing you may care to check is this : The DELNI (and for that matter, almost all multiport tranceiver in the market) does not handle "heart beat" correctly. For all practical purposes, heart beat is a kind of acknowledgment from the tranceiver to the station. Within a very short period of time after the tranceiver finished sending the packet into the coax cable, it issue a heart beat signal on the collision pairs of the tranceiver cable - essentially saying "all's well". In the case of the DELNI, this signal is (mistakenly) fanned out to ALL attached stations. The station doing the transmit will know it is a heart beat. However, the other attached stations will treat it as an asynchonous collision notification. Most station will ignore it but I don't know about the DEC-20. However, definitely, do not attached a repeater to a DELNI. Repeater will not toss away heart beat. It will act on it and generate collision reinforcement (jam) on the other side!!! The result is excessive collisions. Very bad news to the overall band width availability. John Leong . 12-Sep-86 10:32:47-PDT,1498;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 10:31:18-PDT Date: Fri 12 Sep 86 13:33:00-EDT From: Betsy Ramsey Subject: DECUS Session Chairmen To: TOPS20@SU-SCORE.ARPA Organization: American Mathematical Society Message-ID: <12238384332.67.EWR@XX.LCS.MIT.EDU> The DECUS Large Systems SIG is looking for people to chair sessions at the fall symposium in San Francisco. The Large Systems SIG is present- ing a number of high-end VAX- and DECsystem-related sessions. A session chairman's responsibilities include introducing the speaker(s), and filling in a multiple-choice session evaluation form. A Session Chairmen Meeting is held Sunday evening before the symposium to brief chairmen on their responsibilities. If you are planning to attend a Large Systems session (code "LSnnn" in the Preliminary Program) at San Francisco, please seriously consider volunteering to chair the session. Sessions may not be held without chairmen. If you would like more information, or if you wish to volunteer to be a chairman, please send mail to me and/or Bob McQueen (Large Systems SIG Symposium Coordinator): Betsy Ramsey Arpa: EWR@XX.LCS.MIT.EDU Bob McQueen Arpa: SIT.MCQUEEN@CU20B.COLUMBIA.EDU Bitnet: RMCQUEEN@SITVXA Betsy Ramsey American Mathematical Society P.O. Box 6248 Providence, RI 02940 401-272-9500 x295 ------- 12-Sep-86 11:53:03-PDT,829;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 12 Sep 86 11:50:08-PDT Received: ID ; Fri 12 Sep 86 14:48:37-EDT Date: Fri 12 Sep 86 14:48:36-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Minor, annoying bug To: tops-20@SU-SCORE.ARPA Message-ID: <12238398096.31.VAF@C.CS.CMU.EDU> I have noticed that when a TOPS-20 is up for a fairly long while (longer than a week or so) and is idle at least half of the time, the system idle time given by INFO MONITOR eventually becomes "+INF%", and then even later wraps around to 0% again. Has anyone tracked down and fix the bug that causes this? It is (obviously) not that big a deal (not big enough to be worth looking for, unless someone has already fixed it), but it is a minor annoyance. --Vince ------- 15-Sep-86 12:12:07-PDT,840;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 15 Sep 86 12:02:35-PDT Date: Mon 15 Sep 86 12:18:30-EDT From: Ken Rossman Subject: Re: KL Keepalives and NI microcode bugs (?) To: LOMARTIRE@TOPS20.DEC.COM, DLE@SRI-STRIPE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <"MS11(6001)+GLXLIB5(0)" 12238364075.116.209.16540 at TOPS20.DEC.COM> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12239157203.300.SY.KEN@CU20B.COLUMBIA.EDU> We've been running NI ucode 170 since last Thursday and it seems to be working fine. I don't believe we've had any more Keepalives since then, but then our machines were also down for a good portion of this past weekend, so it hasn't been that long yet. /Ken ------- 16-Sep-86 16:03:24-PDT,967;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 16 Sep 86 13:14:16-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 16 Sep 86 10:31:20-PDT Date: Tue 16 Sep 86 09:08:54-PDT From: Mark Crispin Subject: LPTSPL security problem To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12239417598.7.MRC@PANDA> If you've been annoyed by the security problem that LPTSPL fails to assign PLPTn: at startup (and thus a user can assign PLPTn: directly and print without spooler accounting), there is a workaround. In your SYSTEM.CMD file do a SET PRINTER 0 FORMS NORMAL before the START PRINTER 0 command, and so on for each printer which does not not already have a FORMS request. LPTSPL will grab the printers right away with this change. Thanks to Tom DeBellis for this hack! ------- 22-Sep-86 07:55:13-PDT,3257;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 22 Sep 86 07:52:40-PDT Date: Mon 22 Sep 86 10:51:10-EDT From: leslie maltz Subject: Large Systems SIG Menu To: tops-20@SU-SCORE.ARPA Message-ID: <12240976313.17.SIT.MALTZ@CU20B.COLUMBIA.EDU> As Chairperson of the DECUS Large Systems Special Interest Group (SIG), I'd like to share with you some fairly recent events that you might find interesting. Over the course of the last two plus years the leadership and membership of the SIG have been doing a lot of fairly deep thinking to determine whether we should continue to exist within the DECUS structure in today's world. As you may already know, many of us got our start on DEC's 36 bit systems and abruptly found ourselves learning a new architecture. After long deliberation and discussions with our membership as well as many people involved elsewhere inside (including the VAX SIG Steering Committee) and outside of DECUS, the SIG has emerged as a strong viable organization. I'd like to share with you a brief description of what we think we are all about and then ask your assistance for a few minutes. The LARGE SYSTEMS SIG has as its focus the issues and concerns associated with the management, support, and use of Digital's highend computing systems. Users of highend systems have many problems in common which are distinct from users of the vast majority of smaller computing systems. Such problems include support issues in a multi-vendor environment, software licensing for clusters and networks, large databases (manipulation and storage), performance and tuning, reliability, operator interfaces, project accounting, configuration design, and support for "real", fast, heavy duty cycle (reliable) peripherals. Such issues are important in a "data center"-like and/or corporate/campus networked environment or wherever VAXes are being used in support of mainframe-like (highend computing) activities. As such the LARGE SYSTEMS SIG sponsors activities oriented toward the management and use of large VAXes, VAXclusters, DECsystems-10s, and DECSYSTEM-20s. We welcome members who are interested in any/all of such systems. In that light, the SIG is sponsoring its annual MENU. The MENU is our official ballot through which users can indicate their priorities and concerns regarding Digital's plans, products, and services. Regardless of whether you are currently a member of our SIG or not, I encourage you to consider the items listed in the MENU and to express your wishes via the ballot. Digital responds to our MENU in several ways. First, it gives a strong, unified message of the wishes of the user base. Numbers count! Second, they formally respond to us at the semi-annual symposium (which is in San Francisco in October). So please respond by mailing your ballot form back to us via U.S. Mail or electronically to CRB@NIHCUDEC.BITNET. The menu is available using ANONYMOUS FTP from SRI-STRIPE.ARPA. The menu is DECUS-LGSYS.MENU, on SRI-STRIPE. Use your userid for a password. Leslie Malt SIG Chair ------- 23-Sep-86 01:24:35-PDT,1119;000000000000 Return-Path: <@SUMEX-AIM.ARPA,@PANDA:CARL@SCU> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Sep 86 01:24:10-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 23 Sep 86 01:22:08-PDT Received: from SCU by PANDA with Cafard; Tue 23 Sep 86 00:19:57-PDT Date: Mon 22 Sep 86 23:50:06-PDT From: Carl Fussell On-Terminal: 67 Subject: charging To: tops-20%su-score%sumex-aim@PANDA Message-ID: <12241150881.13.CARL@SCU> I need to find some information and am hoping that readers of this list might be able to help. Our university is expanding its computer resources (both large systems as well as PCs) and is considering implementing some type of charge scheme to partially cover the cost of new systems being purchased. I was asked to look into this but have no experience with typical rates and so on. I was hoping that if anyone on this list has info on charging schemes, they would send it to me... both related to large system usage and PC usage if possible. Thanx in advance... Carl Fussell Carl%SCU%PANDA@SUMEX-AIM or G.Fussell@Score ------- 23-Sep-86 12:40:05-PDT,15041;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Sep 86 12:38:40-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 23 Sep 86 12:32:22-PDT Date: Tue 23 Sep 86 12:04:20-PDT From: Mark Crispin Subject: Security problems To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12241284545.7.MRC@PANDA> [Note: The following message deals with a series of computer breakins at Stanford's Unix systems, but some of the lessons learned are quite apropos to TOPS-20 and VMS as well. I am passing this on to the TOPS-20 list, since many of you have multiple systems. -- MRC] Lessons learned from a recent rash of Unix computer breakins Introduction A number of Unix computers in the San Francisco area have recently been plagued with breakins by reasonably talented intruders. An analysis of the breakins (verified by a telephone conversation with the intruders!) show that the networking philosophy offered by Berkeley Unix, combined with the human nature of systems programmers, creates an environment in which breakins are more likely, and in which the consequences of breakins are more dire than they need to be. People who study the physical security of buildings and military bases believe that human frailty is much more likely than technology to be at fault when physical breakins occur. It is often easier to make friends with the guard, or to notice that he likes to watch the Benny Hill show on TV and then wait for that show to come on, than to try to climb fences or outwit burglar alarms. Summary of Berkeley Unix networking mechanism: The user-level networking features are built around the principles of "remote execution" and "trusted host". For example, if you want to copy a file from computer A to computer B, you type the command rcp A:file B:file If you want to copy the file /tmp/xyz from the computer that you are now using over to computer C where it will be called /usr/spool/breakin, you type the command rcp /tmp/xyz C:/usr/spool/breakin The decision of whether or not to permit these copy commands is based on "permission" files that are stored on computers A, B, and C. The first command to copy from A to B will only work if you have an account on both of those computers, and the permission file stored in your directory on both of those computers authorizes this kind of remote access. Each "permission file" contains a list of computer names and user login names. If the line "score.stanford.edu reid" is in the permission file on computer "B", it means that user "reid" on computer "score.stanford.edu" is permitted to perform remote operations such as rcp, in or out, with the same access privileges that user "reid" has on computer B. How the breakins happened. One of the Stanford campus computers, used primarily as a mail gateway between Unix and IBM computers on campus, had a guest account with user id "guest" and password "guest". The intruder somehow got his hands on this account and guessed the password. There are a number of well-known security holes in early releases of Berkeley Unix, many of which are fixed in later releases. Because this computer is used as a mail gateway, there was no particular incentive to keep it constantly up to date with the latest and greatest system release, so it was running an older version of the system. The intruder instantly cracked "root" on that computer, using the age-old trojan horse trick. (He had noticed that the guest account happened to have write permission into a certain scratch directory, and he had noticed that under certain circumstances, privileged jobs could be tricked into executing versions of programs out of that scratch directory instead of out of the normal system directories). Once the intruder cracked "root" on this computer, he was able to assume the login identity of everybody who had an account on that computer. In particular, he was able to pretend to be user "x" or user "y", and in that guise ask for a remote login on other computers. Sooner or later he found a [user,remote-computer] pair for which there was a permission file on the other end granting access, and now he was logged on to another computer. Using the same kind of trojan horse tricks, he was able to break into root on the new computer, and repeat the process iteratively. In most cases the intruder left trojan-horse traps behind on every computer that he broke into, and in most cases he created login accounts for himself on the computers that he broke into. Because no records were kept, it is difficult to tell exactly how many machines were penetrated, but the number could be as high as 30 to 60 on the Stanford campus alone. An intruder using a similar modus operandi has been reported at other installations. How "human nature" contributed to the problem The three technological entry points that made this intrusion possible were: * The large number of permission files, with entirely too many permissions stored in them, found all over the campus computers (and, for that matter, all over the ARPAnet). * The presence of system directories in which users have write permission. * Very sloppy and undisciplined use of search paths in privileged programs and superuser shell scripts. Permissions: Berkeley networking mechanism encourages carelessness. The Berkeley networking mechanism is very very convenient. I use it all the time. You want to move a file from one place to another? just type "rcp" and it's there. Very fast and very efficient, and quite transparent. But sometimes I need to move a file to a machine that I don't normally use. I'll log on to that machine, quickly create a temporary permission file that lets me copy a file to that machine, then break back to my source machine and type the copy command. However, until I'm quite certain that I am done moving files, I don't want to delete my permission file from the remote end or edit that entry out of it. Most of us use display editors, and oftentimes these file copies are made to remote machines on which the display editors don't always work quite the way we want them to, so there is a large nuisance factor in running the text editor on the remote end. Therefore the effort in removing one entry from a permission file--by running the text editor and editing it out--is high enough that people don't do it as often as they should. And they don't want to *delete* the permission file, because it contains other entries that are still valid. So, more often than not, the permission files on rarely-used remote computers end up with extraneous permissions in them that were installed for a one-time-only operation. Since the Berkeley networking commands have no means of prompting for a password or asking for the name of a temporary permission file, everybody just edits things into the permanent permission file. And then, of course, they forget to take it out when they are done. Write permission in system directories permits trojan horse attacks. All software development is always behind schedule, and programmers are forever looking for ways to do things faster. One convenient trick for reducing the pain of releasing new versions of some program is to have a directory such as /usr/local/bin or /usr/stanford/bin or /usr/new in which new or locally-written versions of programs are kept, and asking users to put that directory on their search paths. The systems programmers then give themselves write access to that directory, so that they can intall a new version just by typing "make install" rather than taking some longer path involving root permissions. Furthermore, it somehow seems more secure to be able to install new software without typing the root password. Therefore it is a nearly-universal practice on computers used by programmers to have program directories in which the development programmers have write permission. However, if a user has write permission in a system directory, and if an intruder breaks into that user's account, then the intruder can trivially break into root by using that write permission to install a trojan horse. Search paths: people usually let convenience dominate caution. Search paths are almost universally misused. For example, many people write shell scripts that do not specify an explicit search path, which makes them vulnerable to inheriting the wrong path. Many people modify the root search path so that it will be convenient for systems programmers to use interactively as the superuser, forgetting that the same search path will be used by system maintenance scripts run automatically during the night. It is so difficult to debug failures that are caused by incorrect search paths in automatically-run scripts that a common "repair" technique is to put every conceivable directory into the search path of automatically-run scripts. Essentially every Unix computer I have ever explored has grievous security leaks caused by underspecified or overlong search paths for privileged users. Summary conclusion: Wizards cause leaks The people who are most likely to be the cause of leaks are the wizards. When something goes wrong on a remote machine, often a call goes in to a wizard for help. The wizard is usually busy or in a hurry, and he often is sloppier than he should be with operations on the remote machine. The people who are most likely to have permission files left behind on stray remote machines are the wizards who once offered help on that machine. But, alas, these same wizards are the people who are most likely to have write access to system directories on their home machines, because it seems to be in the nature of wizards to want to collect as many permissions as possible for their accounts. Maybe that's how they establish what level of wizard that they are. The net result is that there is an abnormally high probability that when an errant permission file is abused by an intruder, that it will lead to the account of somebody who has an unusually large collection of permissions on his own machine, thereby making it easier to break into root on that machine. Conclusions. My conclusions from all this are these: * Nobody, no matter how important, should have write permission into any directory on the system search path. Ever. * Somebody should carefully re-think the user interface of the Berkeley networking mechanisms, to find ways to permit people to type passwords as they are needed, rather than requiring them to edit new permissions into their permissions files. * The "permission file" security access mechanism seems fundamentally vulnerable. It would be quite reasonable for a system manager to forbid the use of them, or to drastically limit the use of them. Mechanized checking is easy. * Programmer convenience is the antithesis of security, because it is going to become intruder convenience if the programmer's account is ever compromised. This is especially true in setting up the search path for the superuser. Lament I mentioned in the introduction that we had talked to the intruders on the telephone. To me the most maddening thing about this intrusion was not that it happened, but that we were unable to convince any authorities that it was a serious problem, and could not get the telephone calls traced. At one point an intruder spent 2 hours talking on the telephone with a Stanford system manager, bragging about how he had done it, but there was no way that the call could be traced to locate him. A few days later, I sat there and watched the intruder log on to one Stanford comptuer, and I watched every keystroke that he typed on his keyboard, and I watched him break in to new directories, but there was nothing that I could do to catch him because he was coming in over the telephone. Naturally as soon as he started to do anything untoward I blasted the account that he was using and logged him off, but sooner or later new intruders will come along, knowing that they will not be caught because what they are doing is not considered serious. It isn't necessarily serious, but it could be. I don't want to throw such people in jail, and I don't want to let them get away either. I just want to catch them and shout at them and tell them that they are being antisocial. Brian Reid DEC Western Research and Stanford University [Some TOPS-20 conclusions: (1) Nobody should ever have access to , for any reason whatsoever. A common means of leaving a Trojan horse behind on TOPS-20 is to put a password on . If you have a password on your you have probably been and are still being cracked, perhaps without your knowledge! It is truly trivial to crack a TOPS-20 wide open if you know a password on . PANDA monitors forbid all CRDIR%'s on except during structure creation. Stanford monitors had an earlier version of this; I don't know if they still do. (2) Nobody should ever have group access to any of the SYS: directories, and especially not to SYSTEM:. (3) All users should have different passwords on each system they have an account on. This especially holds true for Wheels, but is not limited to them. Encrypted passwords help, but users should be forbidden from using any word that can be found in a dictionary, proper name, or commonly used number (e.g. social security, telephone). (4) Sites should log all significant security events on the console. This list can include capabilities enablings, directory creations (or at least those which create accounts or change privileges), use of CRJOB%, excessive password failures, privileged user logins/logouts. The monitor at PANDA logs all of the above and more; it also fixes up the old Tenex LOGTTY stuff (it suffered software rot over the years). (5) Sites should forbid unprivileged use of CRJOB%. In most monitors it is a security hole. (6) Sites should require periodic password changes. ] ------- 24-Sep-86 11:53:10-PDT,4374;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Sep 86 11:51:46-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 24 Sep 86 11:47:19-PDT Date: Wed 24 Sep 86 11:00:37-PDT From: Mark Crispin Subject: VAX MM To: TOPS-20@Score.Stanford.EDU cc: Kashtan@SRI-IU.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12241535089.7.MRC@PANDA> Folks, I want to call your attention to the following problem. The need for a VAX/VMS version of MM has become acute. I have been receiving telephone calls and/or electronic mail messages requesting one daily. It is obvious that DEC's electronic mail offerings have not proved to be a satisfactory substitute for MM-20. Dave Kashtan at SRI has developed a surprisingly complete version of MM written in C. I have used it on VMS and Unix; it is excellent although it is missing a few relatively minor functionalities. It is reputed (by those who have seen the source code; I have not) that it is essentially a transliteration of the MM-20 source code. I can believe this since it follows the MM-20 interface much more closely than a blind design cloning would do. Kashtan has done an excellent job. The problem is that SRI considers this problem to be proprietary. The details of licensing are unclear, but what is clear is that this program is unavailable to me (beyond my being able to run it on a VMS system I have an account on). SRI's reasoning is that apparently they have spent a fair amount of R&D dollars on VAX MM and they wish to recover it. I do not buy this argument. Based on the information I have, SRI's expendicture on VAX MM is substantially smaller than the R&D money that Stanford alone spent on MM-20. This doesn't include the large amount of R&D work done to MM-20 at other organizations. It was this large collective effort that built MM-20 into what it is today. None of these organizations made claims that impacted MM-20's public domain status, and certainly much of this work would not have happened had MM-20 been proprietary. We have already seen EMACS subverted in the VMS/Unix community to be several forms of high-priced proprietary packages. I don't know what can be done to stop this from happening further with MM. Kashtan seems to be sympathetic. Perhaps a start might be if the members of the community who care about this send messages to Kashtan that he can show to his superiors expressing their feelings on this issue. Please make sure your letters are well-reasoned, non-inflammatory, and non-abusive. I do not object to SRI creating other proprietary programs using the portable TOPS-20 interface technology that was developed for VAX MM. In fact, I encourage SRI to do so. I know that other TOPS-20 utilities have been ported in this way (although if SRI tries to sell a TOPS-20 TELNET clone they had better talk to me first since TELNET is not public domain!). I feel that retaining the good mailsystem technology in the public domain will serve to reduce the creeping robber-baronism that has pervaded the computer industry in recent years, and will serve to generate good will for SRI. I can think of no better advertising for any proprietary TOPS-20 clone utilities SRI may develop than a free version of MM *in source form*. I have a more direct interest in VAX MM. Certain portions of MM-20 have become quite difficult to modify; the main part of the user interface (a.k.a. the MM program itself) in particular. I would be quite interested in further work to VAX MM to make the user interface a complete reimplementation of the MM-20 user interface so that that part of it may be substituted for the old MM.MAC module. It would be an amazing win if we had true transparency of the user interface between the 20's and the VAXen (or other CPU's) even if other components (e.g. the mailers) differ. Friends, let's work together and see what can be done. I've copied Dave Kashtan on this since I believe he's on our side. If it comes down to it, I see no other recourse than to support some other project to completely redo Kashtan's work. I hope this can be avoided. -- Mark -- ------- 24-Sep-86 13:21:49-PDT,4755;000000000000 Return-Path: Received: from SRI-IU.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Sep 86 13:20:57-PDT Date: Wed 24 Sep 86 13:19:51-PDT From: David L. Kashtan Subject: Re: VAX MM To: MRC%PANDA@SUMEX-AIM.ARPA Cc: TOPS-20@SU-SCORE.ARPA Message-ID: In-Reply-To: Message from "Mark Crispin " of Wed 24 Sep 86 11:00:37-PDT Postal-Address: 15139 Old Ranch Rd; Los Gatos, CA 95030 Phone: (415) 859-5830 (SRI); (408) 353-1643 (Home) I would like to respond to some of the things that Mark has stated in his message about VAX mail systems: The origin of MultiNet MM-32 (It is really now part of a larger system consisting of a mail reader/composer, MM-32, a queued mail delivery system, Pony Express, and a Multi-Protocol network, MultiNet): The work began as a potential research project to be funded by DEC. The initial work, done on SRI internal R&D funds, was a portable TOPS-20 runtime system. I took the most commonly used TOPS-20 system calls, like COMND, and implemented a portable 32-bit architecture based version of these calls written in "C". This effort was EXTREMENLY difficult and time consuming. I did not work from TOPS-20 sources, just from the way a particular TOPS-20 system (SRI-AI) appeared to the user (me). In particular, the COMND and GTJFN calls took many many iterations of test cases on the -20 and rewrites of code on the VAX to make things the same. There are many extremely subtle influences of various defaults and filename processing in GTJFN. The real research part of the project was to look into using a Knowledge-based system to "understand" MACRO-20 programs and in a semi-automated fashion produce a portable 32-bit architecture version of the program. For various reasons, the project did NOT get funded by DEC and has since been laid to rest, but in the process of getting ready for this part of the project (and to really test the portable TOPS-20 runtime system) I decided to see how difficult it would be to transliterate MM-20. I got through enough of this (the top-level parsing) to convince myself that it was feasable. Eventually it became apparent that a portable version of MM for 32-bit architectures would be a good idea. The decision was NOT to transliterate MM-20 but to completely re-implement it to take advantage of large address spaces. The reason that this new MM DOES come so close to presenting the same user interface as MM-20 is that it uses the portable TOPS-20 runtime system and a transliteration of the COMND control blocks. The result is that this MM can operate on mail files that are many times larger than ones on the -20 (A typical example is a 4Mb MAIL.TXT file, which this MM can "get" in about 1/2 sec). SRI's position: SRI does not consider the MM code to be proprietary (and intends to distribute full MM sources to licensees). SRI does consider the portable TOPS-20 runtime system to be proprietary and will only be supplying object libraries. SRI is just now starting to license MM for VMS and UNIX and is indeed charging real money for it. I do not think that there is any chance of getting MultiNet MM-32 placed in the public domain (and there is certainly no chance of doing the same with the portable TOPS-20 runtime system). I think that well reasoned letters might influence the final price and I also think that there is a good chance that sites that can/will do development work can get essentially free copies. I think this would go a long way towards continuing the kind of community work that made MM-20 as good as it today. It also would place the majority of the financial burden on those sites that JUST use the software. I will be more than happy to pass to the powers that be, any messages that you send me (I will actively filter out the abusive/non- constructive ones). Other TOPS-20 utilities: I don't know how many other widely useful TOPS-20 utilities are likely to be developed by me (I really don't have much time for it). I have done a telnet and ftp (none of which are derived from TOPS-20 code -- all are just based on the interaction I saw when using them on TOPS-20). Mail delivery: On UNIX MultiNet MM-32 uses "sendmail" as the delivery facility. On VMS MultiNet can use either VAXmail (ugh!) or Pony Express as the delivery facility. Pony Express is not SRI's property, although SRI has distribution rights. There is no way that I can place this in the public domain and VAXmail is a truly poor mail delivery system. David ------- 25-Sep-86 15:46:17-PDT,1671;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Thu 25 Sep 86 15:44:15-PDT Received: ID ; Thu 25 Sep 86 18:21:46-EDT Date: Thu 25 Sep 86 18:21:10-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: TOPS-20 MAISER and source routing To: tops-20@SU-SCORE.ARPA Message-ID: <12241844665.5.VAF@C.CS.CMU.EDU> Is it the case that TOPS-20 MAISER is supposed to correctly implement source routing? If so, something appears (at least to me) to be broken. Given the following particular source route to the SMTP server on C.CS.CMU.EDU (from an actual example): MAIL FROM: RCPT TO:<@C.CS.CMU.EDU,@SIMTEL20.ARPA:LYNN@PANDA> I believe, according to the SMTP spec, that C.CS.CMU.EDU should remove itself from the RCPT TO: list, add itself to the MAIL FROM: list, and relay the mail to SIMTEL20.ARPA as follows: MAIL FROM:<@C.CS.CMU.EDU:GRIPE@A.CS.CMU.EDU> RCPT TO:<@SIMTEL20.ARPA:LYNN@PANDA> (please correct me if I am wrong). However, the source code to MAISER (and the actual execution of this particular case) would seem to indicate that the local host, C.CS.CMU.EDU, is attempting to verify the existance of host PANDA, which it naturally knows nothing about. The result is a "no such host - PANDA" error from the SMTP server. It seems to me that for source routing purposes, MAISER should only be verifying the next hop in the source route. I have tried this same experiment to two other TOPS-20's, CS.COLUMBIA.EDU and RED.RUTGERS.EDU, so it isn't just CMU's version of MAISER. Is my interpretation of RFC821 wrong or is MAISER doing the wrong thing here? --Vince ------- 25-Sep-86 22:32:56-PDT,2582;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 25 Sep 86 22:32:09-PDT Date: Fri 26 Sep 86 01:30:58-EDT From: Thomas De Bellis Subject: GLXTXT ^F doesn't work for some FD's To: Tops-20@SU-SCORE.ARPA Message-ID: <12241922907.136.SY.SLOGIN@CU20B.COLUMBIA.EDU> Problem: Galaxy programs, such as LPTSPL, that type out file descriptors occasionally come out with files that look like this: DEVICE:FOO.BAR.1.BAZ.BOOM. The .BAZ.BOOM isn't a Tops-10 SFD nor a symbolic generation number--it be real garbage. The files seemed to be opened ok, but typing them out in a $TEXT macro with ^F descriptor seems to randomly get this kind of junk. Diagnosis: PROF, the GLXTXT routine that processes file descriptors, does the wrong thing for Tops-20 file specifications. PROF assumes that file names are ASCIZ text. This isn't true--they are counted strings and the .FDLEN field tells you how long the string is. The file string in the FD block can be directly following by another block, so if you just SOUT% the string, you may get garbage at the end. This often happened with files at the end of a print request that was a word shorter than the previous request. Cure: Please... Hey, wait a minute, I'm not that Tom... I'll just fix the code! Flush Bogus Cruft: TOPS20 < PROF: MOVEI S1,.FDSTG ;GET OFFSET TO DESCRIPTIVE STRING PUSH P,CALOC ;SAVE LOCATION OF ARGUMENT ADDM S1,CALOC ;POINT TO "STRING PART" OF FD PUSHJ P,PROT ;HANDLE AS ASCIZ TEXT POP P,CALOC ;RESTORE ORIGINAL LOCATION > ;END TOPS20 CONDITIONAL Replace with Super Cuspy Winnitude: TOPS20 < PROF: MOVE P2,CALOC ;C127 ;Get location of passed FD LOAD P1,.FDLEN(P2),FD.LEN ;C127 ;Number of words in the FD SUBI P1,.FDFIL ;C127 ;Subtract off the header length ADDI P2,.FDSTG ;C127 ;P2 now points to the GTJFN string SETZM S1,TTXBUF+1 ;C127 ;Insure that the string is real ASCIZ! PROFLP: MOVE S1,P2 ;C127 ;Point to the current word of string $CALL FETCH ;C127 ;Go load it into S1 MOVEM S1,TTXBUF ;C127 ;Store the word in our temporary buffer MOVEI S1,TTXBUF ;C127 ;Now point to our ASCIZ text $CALL PUTT ;C127 ;Handle as if it were ASCIZ text ADDI P2,1 ;C127 ;Point to next word SOJG P1,PROFLP ;C127 ;Process more file words > ;END TOPS20 CONDITIONAL We're running this on CU20B. Er, um, if we go off the Internet for a few days it's probably something random like an EXEC bug... Er... -- Tom ------- 29-Sep-86 01:04:02-PDT,2246;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Sep 86 01:03:42-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 29 Sep 86 01:03:00-PDT Date: Mon 29 Sep 86 00:32:55-PDT From: Mark Crispin Subject: disk integrity question To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12242731539.7.MRC@PANDA> PANDA uses 3 RM03's for its filesystem, each with a distinct structure (I may be crazy to have a home 2020, but I'm no fool). Yesterday, I opened unit 0 (which has my PS) for the first time in several months to put my TOPS-10 DSKB on. When I spun up DSKB I got an incredible bearing noise, much louder than my unit 2 which always has been a noisy starter. I spun it down before the heads loaded and took a look. I didn't see anything wrong with the pack or the drive, but I decided to look at my PS just to be sure. What I saw totally freaked me out. The bottom platter of my PS was visibly warped! About 1/5 of its circumference was warped up to almost half the distance separating it from the next platter! A quick look at the drive's heads reassured me that the bottom platter of RM03's isn't actually used and that (from an eyeball measurement) the spacing was still greater than the thickness of the head assembly. There was no visible scoring or other evidence of damage on the pack, nor was there any oxide dust in the shroud. Shaken, I put DSKB away and decided to try my PS again. I figured that if it would damage the drive it would do so already, and at used market prices I could afford to replace (not fix) it. It went up without any problems, it passed all the diagnostics, and has run TOPS-20 without so much as a soft ECC. Has anybody heard of such a thing? I'm thinking of just considering that drive/pack to be non-removable media for as long as they continue to work. I definitely don't want to risk another pack in that drive. The pack has been totally error free in spite of the warped bottom platter, so I'd hate to retire it if there's no good reason to. ------- 1-Oct-86 01:42:54-PDT,647;000000000000 Return-Path: Received: from GSB-WHY.STANFORD.EDU by SU-SCORE.ARPA with TCP; Wed 1 Oct 86 01:42:49-PDT Date: Wed 1 Oct 86 01:43:28-PDT From: Jim Lewinson Subject: M-Box/MCA-25 Kits at GSB To: SU-TOPS-20@SU-SCORE.ARPA In case anyone is looking for them, DEC forgot the MCA-25 and M-Box Kits from the LOTS spares cabinet in the GSB machine room. Hopefully they will get back there by Thursday, however, the CERAS machine room area is in a certain amount of disarray at this point. Jim P.S. Out of curiosity, how many other sites are using those cabinets? ------- 1-Oct-86 03:27:21-PDT,1036;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 1 Oct 86 03:26:30-PDT Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Wed 1 Oct 86 03:26:43-PDT Date: Wed 1 Oct 86 03:11:17-PDT From: David Roode Subject: Disk allocation fix for 6.1 To: TOPS-20@SU-SCORE.ARPA Phone: (415) 965-5585 Message-ID: <12243284657.15.ROODE@IC2060> There is an SPR in the Oct. 1 dispatch that is a reprint of an early printing, this time with DDT patch. The problem corrected is a slowdown in disk access on RP0x structures that are >2/3 full due to a deliberate scattering of pages one per cylinder as files grow. Files are unlikely to have any consecutive n pages on fewer than n cylinders so long as n is less than the maximum cylinder number. The performance implications are obvious. This is the only SPR printed with response in the Oct 1 dispatch, which is thinner than usual. If you don't use autopatch, don't miss it... ------- 1-Oct-86 15:55:34-PDT,3245;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Wed 1 Oct 86 15:54:11-PDT Received: ID ; Wed 1 Oct 86 18:14:44-EDT Date: Wed 1 Oct 86 17:37:30-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Potential MAISER problem for multi-homed hosts To: TOPS-20@SU-SCORE.ARPA Message-ID: <12243409578.5.VAF@C.CS.CMU.EDU> This is a bug that bit us today, so I thought I would share it. The HSTNAM module, used by MAISER, MM, and MMAILR assumes that the primary address of the local host as returned by the .GTHSZ GTHST% function is the same as that returned by a .GTHSN GTHST% function performed on the local host name. It is possible for this to not be the case, i.e. if the addresses in HOSTS.TXT for the local host are not in the same order as in the SITE-ADDRESS.TXT (or INTERNET.ADDRESS) file. The result can be confusion on the part of clients of the HSTNAM module, MAISER in particular (when it attempts to determine of the host name in a RCPT TO: line matches the local host). I discovered this today when our MAISER (modified to disallow relaying) started rejecting mail that should be delivered to the local host - because the .GTHSN GTHST% result did not match that of the .GTHSZ GTHST%, it didn't believe that mail addressed to user@C.CS.CMU.EDU was really deliverable to C.CS.CMU.EDU... Anyway, to make a long story short, I made the following hack to HSTNAM to prevent this problem from recurring (modified lines marked by "CSM33"): $GTHNS::SAVEAC STKVAR ;CSM33 TXC A,.LHALF ; is string pointer LH -1? TXCN A,.LHALF HRLI A,() ; yes, set up byte pointer MOVEM A,HSTPTR ; save host pointer MOVEM B,HSTNUM ; save host address MOVEM B,HSTNMX ;CSM33 CAME B,[-1] ; want local address? IFSKP. MOVX A,.GTHSZ ; yes, get local address so can output GTHST% ; bracketed if unnamed local host ERJMP R ; not on Internet MOVEM D,HSTNUM ; set new host address ENDIF. MOVX A,.GTHNS ; number to name conversion MOVE B,HSTPTR ; destination pointer MOVE C,HSTNUM ; host address GTHST% IFNJE. MOVE A,B ; set up byte pointer for $ADDOM MOVEM C,HSTNUM ; return host address MOVE B,HSTNMX ;CSM33 Get original argument CAME B,[-1] ;CSM33 Special local host? IFSKP. ;CSM33 Yes - need to insure primary address MOVEM A,HSTNMX ;CSM33 Save this pointer MOVX A,.GTHSN ;CSM33 Name to number function MOVE B,HSTPTR ;CSM33 The name we just got GTHST% ;CSM33 Translate it ERJMP $GTHN1 ;CSM33 Failed??? MOVEM C,HSTNUM ;CSM33 Update host number $GTHN1: MOVE A,HSTNMX ;CSM33 Restore the pointer ENDIF. ;CSM33 This patch forces the local host address to be retranslated from its official name into its official host number. You will not need this change unless: A) You have a multi-homed host and B) You change the order of the host's addresses in HOSTS.TXT (or in the domain database) without the corresponding change to SITE-ADDRESS.TXT (or INTERNET.ADDRESS) or vice-versa. The moral of the story is to be careful when changing even the order of the addresses for a host... --Vince ------- 1-Oct-86 16:01:18-PDT,470;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 1 Oct 86 16:01:01-PDT Date: Wed, 1 Oct 1986 19:02 EDT Message-ID: From: Rob Austein To: su-tops-20@SU-SCORE.ARPA cc: sra@XX.LCS.MIT.EDU, dhb@XX.LCS.MIT.EDU Subject: BOOTP server? Is there a TOPS-20 implementation of the BOOTP server (RFC 951)? Thought I'd ask where it was invented first. --Rob 2-Oct-86 03:08:43-PDT,3139;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 2 Oct 86 03:08:31-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 2 Oct 86 03:07:40-PDT Date: Thu 2 Oct 86 02:18:59-PDT From: Mark Crispin Subject: Re: Potential MAISER problem for multi-homed hosts To: Vince.Fuller@C.CS.CMU.EDU cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12243409578.5.VAF@C.CS.CMU.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12243537279.7.MRC@PANDA> Vince - I request that you discuss mailsystem matters with me privately *before* sending messages to the entire TOPS-20 list. The mailsystem is not a DEC product, nor is it unsupported; I continue to be active in developing it and probably will continue hacking it long after CMUC is history. The problem you describe is due to your failing to create a correct INTERNET.ADDRESS file. There are two attributes in this file that are very important and must *not* be left to chance. The first one, DEFAULT, specifies which interface is the default to use (and whose address is the default to use as the local IP address) when communicating with non-directly connected networks. The second one, PREFERRED, is the "preferred" interface to use when you are doing a hostname lookup on another multi-homed host with the same set of interfaces you have. For example, at Stanford the multi-homed TOPS-20's have their ARPANET address as the DEFAULT address, since generally the ARPANET address is nearer to random networks than the Stanford LAN address is. However, the Stanford LAN address is preferred, so a connection between Score and SUMEX-AIM uses the Stanford LAN instead of the ARPANET. The symptoms you describe are those of failure to set up a default and preferred address (incidentally, the preferred address defaults to the default address). In this case, simply the first address in INTERNET.ADDRESS is used, but the HOSTS.TXT address list is not prioritized in any special way. In other words, your problem is one of GIGO. You might (justifiably) claim that the first INTERNET.ADDRESS entry should be the DEFAULT address if none is specified, and that therefore HOSTS.TXT prioritizing would then be done correctly. However, I believe that with domains around the corner it isn't worth wasting time on HOSTS.TXT code at all. But it is really a monitor bug. Again, please speak to me about mailsystem stuff first. I know the code intimately. I wrote every line in MAISER; I know how it works and can answer any confusions you might have without giving everybody else on the TOPS-20 list heart attacks. Incidentally, everybody else; the official Internet repositories of the mailsystem are [SIMTEL20] and/or [SUMEX-AIM]SS:. I keep these directories reasonably up to date. The current development directory is on PANDA, so it is always "safe" to use the SUMEX-AIM/SIMTEL20 copies. Untested code doesn't leave PANDA. -- Mark -- ------- 6-Oct-86 10:32:48-PDT,935;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 6 Oct 86 10:30:24-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 6 Oct 86 10:30:11-PDT Date: Mon 6 Oct 86 02:27:11-PDT From: Mark Crispin Subject: helpful hint of the week To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12244587349.6.MRC@PANDA> If batch stops working, check your OPR logs. If the error message is "Illegal for created job to enter MINI-EXEC", then before you go on a wild goose chase looking for a monitor or EXEC bug you should first check the protection of SYSTEM:EXEC.EXE. It might have inadvertantly been protected to 777700 or something similar that impacts world access. I'm not sure if 777712 would work or if you have to use 777752. ------- 8-Oct-86 16:13:17-PDT,1477;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 8 Oct 86 16:12:27-PDT Date: Wed 8 Oct 86 16:12:16-PDT From: Mark Crispin Subject: 36 bit fire sale To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12245261837.17.CRISPIN@SUMEX-AIM.ARPA> At DECUS DEC LSM distributed some brochures about a fire sale they are having on 36 bit equipment until 24 October. To summarize: Product MLP Sale Refurbished KL10-FA $190K $75K $50K Note: I have rounded some KL10-PV $67K $25K $15K prices to even thousands. KL10-RE $261K $125K MLP is Maynard List Price. 2020-ME $63K $25K $15K Refurbished is warrantied 2020-MG $63K $25K $15K as new equipment. MCA25 $40K $25K MCA25-AA $125K $65K MF20-E $20K $5K $4K MG20-DA $80K $56K MG20-DC $58K $41K MG20-E $28K $20K MG20-LA $40K $25K $20K MG20-LC $40K $25K MG20-LG $50K $35K $30K MH10-E $25K $5K MH10-LA $35K $15K $12K MS10-BA $6K $1K CI20-AA $20K $15K CI20-BA $20K $15K CI20-CA $20K $15K DN20F-MA $29K $20K NIA20-AA $11K $8K NIA20-BA $11K $8K NIA20-CA $11K $8K DC20-AA $6K $2K DC20-CC $3K $1K DZ11-AA $3K $1K DZ11-BA $2K $850 RH20 $19K $8K TU77-AF $24K $11K $9K TX03A-AA $45K $40K TX03F-AA $34K $29K TX02-FH $90K $80K TX03-B $6K $5K ------- 10-Oct-86 10:12:44-PDT,1036;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 10 Oct 86 10:10:28-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 10 Oct 86 10:10:20-PDT Date: Fri 10 Oct 86 21:18:23-PDT From: Mark Crispin Subject: TOPS-20 microfiche To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12245841852.6.MRC@PANDA> The latest LSM Product Summary has listings for TOPS-20 microfiche. The electronic store didn't know about the part numbers, so I don't know how much they are. Maybe one of the DEC people on this list could find out for us (hint hint). KL EXEC sources QT101-FR KL monitor sources QT100-FR Front end sources QT029-FR KL EXEC, monitor, FE combined QT102-FR KS EXEC sources QT038-FR KS monitor sources QT030-FR It is probably too much to hope that buying the fiche from DEC would be cheaper than making it yourself. ------- 12-Oct-86 23:37:20-PDT,1378;000000000000 Return-Path: Received: from seismo.CSS.GOV ([192.12.141.25].#Internet) by SU-SCORE.ARPA with TCP; Sun 12 Oct 86 23:36:40-PDT Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) id AA01633; Mon, 13 Oct 86 02:38:04 EDT Received: from charlie (via mulga) by munnari with SunIII (5.5) id AA11995; Mon, 13 Oct 86 15:43:41 EST Received: by charlie .Deakin (4.12) id AA16373; Mon, 13 Oct 86 15:21:30 est Date: 13 Oct 86 15:21:26 +1000 (Mon) Message-Id: <104.529564886@charlie> To: Tops20 People Subject: Problem with GPSS From: Craig Warren Sorry if this isn't the appropriate spot for this, but... We have a problem with GPSS on our DEC-20. A certain control file keeps giving a Fatal Compilation message. When we transfer the control file to a fellow institutions Cyber, the control file runs ok. Assumption: The DEC-20 version 10(57) has a bug. Solution: Contact the suppliers. From all my documentation, I gather that GPSS comes from Simulation Software Design and Development Can anyone tell me whether there is a newer version of GPSS; a net or Telex/Fax address for the above group; or an alternative supplier of the package. Does anyone know if there is a Unix version? Craig Warren ccw%charlie.oz@seismo.css.gov 13-Oct-86 08:57:43-PDT,1297;000000000000 Return-Path: Received: from CS.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 13 Oct 86 08:56:26-PDT Date: Mon 13 Oct 86 11:56:49-EDT From: Bill Schilit Subject: keepalives & pitraps To: tops-20@SU-SCORE.ARPA Message-ID: <12246493287.20.BILL@CS.COLUMBIA.EDU> I've just been looking at a PITRAP (page fault while PI in progress) BUGHLT and I found something strange which may be causing some problems. There is code in IMPDV which is called at PI level but is in the extended NON resident psect (XSWAPCD aka XNCOD). Has anyone else noticed this? The start addresses of XSWAPCD and XRESCD are defined by the symbols XRCOD and XNCOD (tack on a Z for the ending addresses). All the routines following IMICHK in IMPDV are a problem. Above IMICHK is the statement XRESCD, however, IMICHK is defined with an XNENT which puts us right back into swappable code. Specifically I was looking at routine IMODUN which gets called at PI level from IMPANX via the NTODUN dispatch at label IMODN0. I'm a little unclear how things worked at all with these non resident PI routines... could someone out there check their system to see if they see the same problem? Could this be one of the causes of keepalive halts? - Bill ------- 13-Oct-86 12:10:04-PDT,592;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Mon 13 Oct 86 12:04:52-PDT Date: Mon 13 Oct 86 12:04:49-PDT From: Bill Palmer Subject: Re: keepalives & pitraps To: BILL@CS.COLUMBIA.EDU cc: tops-20@Score.Stanford.EDU In-Reply-To: <12246493287.20.BILL@CS.COLUMBIA.EDU> Message-ID: <12246527513.11.WHP4@Sierra.Stanford.EDU> We had this same problem at Stanford a year or two ago. I thought it had been posted on the list, but maybe not. You might check the archives on SCORE. Bill ------- 13-Oct-86 17:22:52-PDT,2056;000000000000 Mail-From: BILLW created at 13-Oct-86 17:17:34 Date: 13 Oct 1986 17:17-PDT Sender: BILLW@SU-SCORE.ARPA Subject: PITRAPs in IMPDV From: William "Chops" Westfield To: schilit@CS.COLUMBIA.EDU Cc: tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]13-Oct-86 17:17:34.BILLW> I sent this bugfix out about a year ago... BillW Begin forwarded message Date: 20 Sep 1985 20:16-PDT From: William "Chops" Westfield To: tops20@SU-SCORE.ARPA Subject: PITRAP bughlts from IMP code in v6.1 Score and Sierra have been experiencing occasional PITRAP bughalts from the IMP driver in tops20 6.1 FT5, getting worse with apparently unrelated monitor edits, and with FT6. The problems turned out to be due to a misuse of XNENT macros in IMPDV, where XRENT macros should have been used. The updated source code should be available from SU-SIERRA: <6-1-MONITOR> sometime in the near future. Many thanks to Mark Crispin, who instantly recognized that the trap was occuring on the instruction fetch rather than on the data reference, saving many hours of useless dump analysis. (How emabarassing not to have noticed this myself). BillW Begin forwarded message Well, a little looking at the monitor showed that the IMPDV code that is carefully declared to be XRESCD wasn't really inside the boundries of what the monitor though was actually resident. More staring at the source showed other strangness, such as compiling IMPDV yielded a load module with only 24 words inside of XRESCD. I was about ready to complain about obscure bugs in macro, when I noticed that there were a number of XNENT FOO,BAR type entry points. That extra "N" looked suspicious, and indeed, XNENT carefully puts you in XSWAPCD, regardless whether it is immediately proceded by an XRESCD macro or not. Sigh. I changed a couple of them to XRENT's, and the monitor is compiling now - Im pretty sure this was the problem. BillW End forwarded message ----------------- End forwarded message 14-Oct-86 06:59:53-PDT,786;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Tue 14 Oct 86 06:59:30-PDT Date: Tue 14 Oct 86 09:00:28-CDT From: G.ATTAYA@R20.UTEXAS.EDU Subject: Re: 36 bit fire sale To: Crispin@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12245261837.17.CRISPIN@SUMEX-AIM.ARPA> Message-ID: <12246734251.55.G.ATTAYA@R20.UTEXAS.EDU> Tulane University is in the process of selling both of their KL's, with all peripherials, etc, for the - get this - approximately $23K - that is the TOTAL price, not the price each - 2KL's, MG on one, MF on other, RP07's RP06's LP07, front-end's DN (no CI or hsc or RA stuff - tapes are a beatup tu77 and some tu45's). It was being de-cabled last week - price is a "good" rumor. ------- 15-Oct-86 14:05:40-PDT,3010;000000000000 Return-Path: <@WISCVM.WISC.EDU,@WESLEYAN.BITNET:SST.D-BIGELOW@KLA.WESLYN> Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Wed 15 Oct 86 14:02:55-PDT Received: from (MAILER)WESLYN.BITNET by WISCVM.WISC.EDU on 10/15/86 at 13:22:45 CDT Received: from KLA.WESLYN by VAX.WESLYN 15-OCT-1986 14:16:12.31 Date: Wed, 15 Oct 1986 14:15 EDT Message-ID: From: Douglas Bigelow To: Clive , John cc: Tops20@SU-SCORE.ARPA Subject: DELNI Strangeness In-reply-to: Msg of Thu 11 Sep 86 19:58:36 edt from leong@andrew.cmu.edu (John Leong) I think I have a variation of the same problem you two discussed in the recent TOPS20 "Re: DELNI Strangeness" mail. Can either of you (or someone else) offer advice? I have an Ethernet with two DEC-20s and a VAX on it, and a fiber optics remote repeater on it connected to another net some 600 meters away. The repeaters are American Photonics RL6000R models, functionally equivalent to a DEC DEREP. At the other end of the fiber optics link is a DELNI network with three MicroVAXes and a cisco Systems terminal server plugged into it. At the main end of the link, the fiber optics repeater is plugged into a DEC H4000 tranceiver. The remote end is plugged directly into the DELNI. Now the interesting part. This is a TCP/IP network, and I can telnet and ftp fine back and forth between any two hosts with excellent response. However, when I use the terminal server, the response is terrible and the server statistics report many collisions and retransmissions. If I test the terminal server by bypassing the DELNI and plugging directly into a tranceiver, it works perfectly. So (John in particular), do I have a heartbeat problem? If so, where is it coming from? The H4000? Would it help if I replaced that tranceiver with one on which heartbeat could be disabled? Should I put the remote repeater on a separate piece of cable and then connect that to the DELNI through slot nine? (Wasting three tranceivers in the process?) Here is a diagram of the net: + Slot | uvax--[1 ] | Fiber optics repeaters uvax--[2 ] |H4000--(~~~~~~~~~~~~~~~~~~~~~~~~~~~~~)---------[3 ] | uvax--[4 ] <=DELNI | <=COAX t/s--[5 ] | [6 ] |--dec20 [7 ] |--dec20 [8 ] |--vax [ ] + [9*] connector disabled Any suggestions on the cheapest/quickest way to solve the problem would be much appreciated. Thanks -- Doug 16-Oct-86 12:50:47-PDT,542;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Oct 86 12:43:13-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 16 Oct 86 12:40:30-PDT Date: Thu 16 Oct 86 12:16:12-PDT From: Mark Crispin Subject: VTTREK help file To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12247316016.7.MRC@PANDA> Does anybody have the help file for VTTREK? ------- 16-Oct-86 20:14:06-PDT,1408;000000000000 Return-Path: Received: from GSB-HOW.STANFORD.EDU by SU-SCORE.ARPA with TCP; Thu 16 Oct 86 20:05:23-PDT Date: Thu 16 Oct 86 20:02:09-PDT From: Eric M. Berg Subject: DEC on viable upgrade paths To: tops-20@SU-SCORE.ARPA Phone-#s: 723-1576 (GSB-CF), 329-9940 (home), 725-6900 x.31576 (Voice mail) The following is taken from an article on the front page of the Sept./Oct. '86 issue of DEC's "Large Systems News": Looking for a Proven Growth Path? DIGITAL LAUNCHES VAX SYSTEMS ATTRACT PROGRAM FOR HEWLETT-PACKARD USERS On February 25, 1986, John Young, president and CEO of Hewlett-Packard, introduced HP's new RISC-based Precision Architecture-- the company's long-range strategy to connect all of its systems.... [paragraph describing new H-P products omitted here] In the meantime, some questions must be addressed. What options are available as users outgrow the capabilities of HP 3000 systems that they're now using? How can users ensure that the Series 930 and Series 950 will provide the future growth path and stable computing environment they need? .... Why wait for the answers? Digital has it now.... (I wish I thought this was written to be tongue-in-cheek, but I'm afraid that they're entirely serious about it.) ------- 20-Oct-86 06:44:24-PDT,921;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 20 Oct 86 06:42:39-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 20 Oct 86 06:43:11-PDT Date: Mon 20 Oct 86 05:11:23-PDT From: Mark Crispin Subject: custom VT100 character sets To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12248287255.7.MRC@PANDA> Does anyone on this list possess the arcane knowledge of how to make special character set ROM's for the VT100? I have an AVO already installed. Better yet, has anyone already made ROM's for German and/or Japanese characters and would be willing to give or sell me a set? Do your ROM's correspond to any standard (e.g. VT220 international characters or JIS)? Even a katakana ROM would be useful... ------- 20-Oct-86 16:01:26-PDT,902;000000000000 Mail-From: BILLW created at 20-Oct-86 16:01:14 Date: Mon 20 Oct 86 16:01:14-PDT From: William "Chops" Westfield Subject: domain errors... To: su-tops-20@Score.Stanford.EDU, mockapetris@E.ISI.EDU cc: sra@XX.LCS.MIT.EDU Message-ID: <12248405557.29.BILLW@Score.Stanford.EDU> Is your DOMAIN:DOMAIN.ERROR growing at an alarming rate? Does the job running the resolver open and close this (long) file many times every minute? This could be a performance problem! :-). I think that nufork becomes confused when it trys to reply to broadcast domain reqeusts from ethertips, or some such, (but I haven't looked at it very much at all). At any rate, to prevent your error file from filling up with "JSYS SNDIN FAILED" messages, just delete NUFORK.EXE from the domain: directory (since this the the name server, which isn't used anyway...) Enjoy BillW ------- 21-Oct-86 11:01:53-PDT,1428;000000000001 Return-Path: Received: from im4u.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Tue 21 Oct 86 11:00:09-PDT Date: Tue, 21 Oct 86 12:38:09 cdt Posted-Date: Tue, 21 Oct 86 12:38:09 cdt Message-Id: <8610211738.AA00624@im4u.UTEXAS.EDU> Received: from pop.cs.utexas.edu by im4u.UTEXAS.EDU (4.22/4.22) id AA00624; Tue, 21 Oct 86 12:38:10 cdt Received: by pop.cs.utexas.edu (LFL/UT SM); Tue, 21 Oct 86 12:38:03 CDT From: ctp@pop.cs.UTEXAS.EDU To: tops-20@su-score.ARPA Subject: Articles wanted for Large Systems SIG Newsletter The end of the month is approaching and I still have room in.... The Large Systems SIG Newsletter If you have something relevant to say about Information Centers, Large VAX site management, DECsystem-10's or DECSYSTEM-20's send me an article. I prefer that submissions be sent to me electronicly but I will take articles in just about any form; BACKUP, DUMPER, VMS-BACKUP, TAR, ASCII, hardcopy. I also prefer that the text be unformatted ASCII without RUNOFF, TeX or SCRIBE (or what have you) commands embeded. ----- Clyde T. Poole, DECUS, Large Systems SIG, Newsletter Editor ARPA: ctp@sally.utexas.edu VOICE: (512) 471-9551 UUCP: {harvard,ihnp4,seismo}!ut-sally!ctp CIS: 75226,3135 Overland: UT at Austin, Department of Computer Sciences Taylor Hall 2.124, Austin, TX 78712-1188 "Life is a bitch ... and then you die" 22-Oct-86 09:31:19-PDT,613;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Oct 86 18:53:40-PDT Date: Tue 21 Oct 86 18:55:22-PDT From: Mark Crispin Subject: MOVSLJ bug? To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12248699401.57.CRISPIN@SUMEX-AIM.ARPA> I discovered the hard way that the updated destination byte pointer returned by MOVSLJ using one-word global byte pointers is a two-word global byte pointer. Is this a bug, a feature, or a misfeature? ------- 22-Oct-86 10:05:13-PDT,699;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Oct 86 03:26:09-PDT Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Wed 22 Oct 86 03:27:30-PDT Date: Wed 22 Oct 86 03:22:26-PDT From: David Roode Subject: SET HOST from VMS to TOPS-20 v.6.1 To: TOPS-20@SU-SCORE.ARPA Phone: (415) 965-5585 Message-ID: <12248791711.13.ROODE@BIONET> Is the following the symptom of the failure of CTERM to work between VMS and TOPS-20? Does anyone have a fix for it? Has anyone SPR'd it to DEC? $ set host ic2060 %SYSTEM-F-INVLOGIN, login information invalid at remote node $ lo ------- 22-Oct-86 12:58:33-PDT,816;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 22 Oct 86 12:53:34-PDT Date: Wed 22 Oct 86 15:54:52-EDT From: Betsy Ramsey Subject: Re: SET HOST from VMS to TOPS-20 v.6.1 To: ROODE%BIONET@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12248791711.13.ROODE@BIONET> Organization: American Mathematical Society Message-ID: <12248895918.65.EWR@XX.LCS.MIT.EDU> I get that message when DECnet logins are not allowed on the DEC-20 side. You can check with the INFO SYSTEM command. If no DECnet logins are allowed, you can enable them with the ^ESET LOGINS DECNET command. (I disallow SET HOSTing to my DEC-20s because everyone can get to them with the terminal servers, and I don't want the extra overhead.) ------- 22-Oct-86 13:42:59-PDT,829;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Oct 86 13:42:22-PDT Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Wed 22 Oct 86 13:42:00-PDT Date: Wed 22 Oct 86 13:28:42-PDT From: David Roode Subject: Re: SET HOST from VMS to TOPS-20 v.6.1 To: EWR@XX.LCS.MIT.EDU cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <12248895918.65.EWR@XX.LCS.MIT.EDU> Phone: (415) 965-5585 Message-ID: <12248902079.41.ROODE@BIONET> Thanks very much for the information that disallowing DECNET logins produces this symptoms. We are still running the 5.1 Exec; I suspect that the ^Eset login any from 5.1 did not include the DECNET logins bit from 6.1. What exactly are the reported problems between 20 and VMS re: CTERM? ------- 23-Oct-86 16:21:41-PDT,1033;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Jan_Michael_Rynning@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 23 Oct 86 16:16:40-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707937290258707@MIT-MULTICS.ARPA>; 23 Oct 1986 16:48:10 edt Date: 23 Oct 86 13:57 +0100 From: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: MOVSLJ bug? Message-ID: <211198@QZCOM> In-Reply-To: <12248699401.57.CRISPIN@SUMEX-AIM.ARPA> June 1982 update to the Processor Reference Manual, section 2.12, last sentence before "CAUTION": However the reader should note that when a global pointer is given as one word, the instruction always converts it to two. It's documented. Hence it's a misfeature, not a bug. 23-Oct-86 23:15:54-PDT,1184;000000000000 Return-Path: Received: from sun.com by SU-SCORE.ARPA with TCP; Thu 23 Oct 86 23:10:26-PDT Received: from snail.sun.com by sun.com (3.2/SMI-3.0) id AA04780; Thu, 23 Oct 86 23:10:55 PDT Received: from sluggo.wseng.sun.com.com by snail.sun.com (3.2/SMI-3.2) id AA20495; Thu, 23 Oct 86 23:10:17 PDT Received: by sluggo.wseng.sun.com.com (3.2/SMI-3.2) id AA11388; Thu, 23 Oct 86 23:09:09 PDT Date: Thu, 23 Oct 86 23:09:09 PDT From: melohn@Sun.COM (Bill Melohn) Message-Id: <8610240609.AA11388@sluggo.wseng.sun.com.com> To: ROODE%BIONET@SUMEX-AIM.Stanford.EDU Subject: Re: SET HOST from VMS to TOPS-20 v.6.1 Cc: tops-20@score.stanford.edu Date: Wed 22 Oct 86 13:28:42-PDT From: David Roode Subject: Re: SET HOST from VMS to TOPS-20 v.6.1 What exactly are the reported problems between 20 and VMS re: CTERM? ------- It depends largely on which version of VMS you are running. VMS 4.4 has many bug fixes on the VMS side for dealing with TOPS-20 systems. Some things like FMS and TDMS cannot work, because VMS implements them in the CTDRIVER using VMS specific unpublished "extensions" to the protocol. 24-Oct-86 14:35:00-PDT,2963;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 24 Oct 86 14:32:58-PDT Date: Fri 24 Oct 86 17:32:43-EDT From: Ken Rossman Subject: COMND% Jsys emulation package written in C now available To: TOPS-20@SU-SCORE.ARPA cc: ctp@SALLY.UTEXAS.EDU, Kashtan@SRI-STRIPE.ARPA, northrup%osu-20@OHIO-STATE.ARPA, Vivian@SRI-NIC.ARPA, sy.Ken@CU20B.COLUMBIA.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12249438019.69.SY.KEN@CU20B.COLUMBIA.EDU> To those of you who I spoke to at DECUS (and for those others of you who are interested), there is now a COMND Jsys emulation package written in C which is available for anonymous FTP from CU20B.COLUMBIA.EDU. The Columbia University Computer Center does not have any Unix machines directly on ARPAnet, so the source code has been copied over to CU20B.COLUMBIA.EDU, and resides in WS: (note that's structure WS:, not PS:). This package, known as CCMD, was developed by Andrew Lowry and Howie Kaye under 4.2BSD, and later DEC ULTRIX, but is also designed to work with various micro OS's (e.g. all of the code runs under MS-DOS). It is not an entirely faithful representation of TOPS-20 COMND% (some code is more general and other parts are less general), but hopefully a good working subset is there. Please take note of several things: - This package is copyrighted, and the copyright notices should always accompany the software. - The package is freely distributed, as long as it is not resold. See the actual copyright notices accompanying the software for more info. - Neither Columbia University nor anyone working for Columbia assumes any responsibility for support of the code, or for its correct operation. However, we would appreciate it, in the spirit of friendly program development sharing, if any of you who do development with this package would let us know if you find any bugs, or make any changes, so we can incorporate the bugfixes and/or changes in the source copies here. - This package is really still only in ALPHA test, but there was sufficient interest in the package generated at DECUS and from other folks I've talked to, that it seemed like the package should be released to those who feel adventuresome and who especially wouldn't mind helping us get it debugged and developed. I have created a discussion list here on CU20B known as Info-TOPSUX, which exists for the purpose of discussing TOPS-20 to Unix conversion in general. Mail to Info-TOPSUX-Request if you would like to be added to this list. Any other questions to SY.KEN@CU20B.COLUMBIA.EDU. /Ken P.S. -- I had also mentioned at DECUS an MM-like mail user interface also written in C and COMND-ized, but we're not yet ready to release info on this package yet. ------- 24-Oct-86 23:03:03-PDT,1223;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 24 Oct 86 23:02:07-PDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 24 Oct 86 23:03:41-PDT Date: Fri 24 Oct 86 21:54:31-PDT From: Mark Crispin Subject: domain lossage with SEISMO To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249518448.7.MRC@PANDA> Apparently for some non-trivial amount of time one of the Internet name solvers was authoritatively stating that SEISMO.CSS.GOV was not a valid name and/or was transmogrifying it to TRIVIA.CSS.GOV. This has caused a number of users on TOPS-20's running domain software to have bounced mail; I've seen messages regarding this problem at MIT and on the CSD DEC-20's at Stanford. I believe that host-table based TOPS-20 systems were not affected by this, and that the problem has cleared by now. At about the same time, the sendmail configuration file at SEISMO was messed up, causing a lot of valid addresses that SEISMO is a relay for to be rejected. I believe this problem has been cleared as well. ------- 26-Oct-86 17:10:18-PST,1988;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 26 Oct 86 17:08:26-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 26 Oct 86 17:08:39-PST Date: Sun 26 Oct 86 13:39:29-PST From: Mark Crispin Subject: summer time madness To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12249963540.7.MRC@PANDA> Friends, You may be distressed to find out that Congress has changed the rules for summer time (a.k.a. Daylight Savings Time) again. Next year summer time will start on the *first* Sunday in April instead of the last. There is no knowledge of this in TOPS-20 as of 6.1 Autopatch #13. I'm sure DEC has recognized this problem and a future Autopatch tape will address it, but I'm sure a lot of customers will be caught napping next April. TOPS-20 presently offers the following options for summer time: . never apply summer time . always apply summer time . apply summer time by algorithm, using the following values: . the year in which the rule became effective (presently 1975) . the last day of the year on which summer time starts (the day picked is the Sunday preceeding it) . the last day of the year on which summer time ends (the day picked is the Sunday preceeding it) The simplest approach is to set the effective rule year to 1987 and set the latest start day to April 7. However, this has the effect of cancelling summer time display for earlier years (haven't you noticed that you see things like "19-Jul-73 16:20:23-PST" instead of "19-Jul-73 17:20:23-PDT"?). Tenex had code to deal with the fuel shortage summer time of the 70's; I'm thinking of making the present algorithm cells be a set of vectors. Question: does Canadian law follow US (e.g. is Canada going to change the start of summer time as well)? ------- 27-Oct-86 12:27:41-PST,735;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Mon 27 Oct 86 12:27:38-PST Date: Mon 27 Oct 86 12:28:32-PST From: Frank M. Fujimoto Subject: bboard bug fix To: su-tops-20@Score.Stanford.EDU Message-ID: <12250212767.29.FMF@Sierra.Stanford.EDU> sites which use msplit to pare down the bboard files (like sierra) often run into a problem when people use bboard su-* to read all of the stanford bboards, since this will also try to find the .idx files for su-xxx-date. bboard has been patched to ignore these files (or any other .txt file which doesn't have a .idx file, too) source is in ps: on sierra -frank ------- 27-Oct-86 17:48:51-PST,1636;000000000000 Return-Path: Received: from venera.isi.edu by SU-SCORE.ARPA with TCP; Mon 27 Oct 86 17:48:37-PST Received: from LOCALHOST.ARPA by venera.isi.edu (5.54/1.2) id AA11290; Mon, 27 Oct 86 17:49:56 PST Message-Id: <8610280149.AA11290@venera.isi.edu> To: "William " Chops " Westfield" Cc: su-tops-20@score.stanford.edu Cc: sra@xx.lcs.mit.edu Cc: pvm@venera.isi.edu Subject: Re: domain errors... In-Reply-To: Your message of Mon 20 Oct 86 16:01:14-PDT. <12248405557.29.BILLW@Score.Stanford.EDU> Date: Mon, 27 Oct 86 17:49:48 PST From: Paul Mockapetris The JEEVES code logs things in three streams: fatal, error, and log. Fatal is really a misnomer and is stuff which always gets logged, usually to the operator's terminal, error usually gets logged, log stuff only if enabled. In each case, there is a lock variable and a file gets opened and closed before the lock is released, so info can come from either the name server or resolver process without getting interleaved. Obviously, the volume can get huge, and the overhead large. Unintentionally huge logs happen when something which was thought to be rare gets common, and I have gotten burned several times myself. As a result, several types of logging were changed from error to log in my more recent versions. I believe the SNDIN error was an example. Sorry about that. paul P.S. I have been subverted to the dark side of the force, so mail to me can be addressed to pvm@venera.isi.edu or mockapetris@isi.edu, although the 20s will still forward. 27-Oct-86 19:06:29-PST,906;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Mon 27 Oct 86 19:00:20-PST Date: Mon, 27 Oct 1986 22:05 EST Message-ID: From: Rob Austein To: Tops-20@SU-SCORE.ARPA Subject: Daylight Savings Time The following is out of the depths of the ITS DATIME library (which provides support similar to IDTIM%/ODTIM%). Seems appropriate in view of the matter Mark brought up. This is not a new problem. --Rob ;SUBROUTINE TO CHECK FOR THE FORCED DAYLIGHT TIME DECLARED BY CONGRESS ; FOR THE FUEL SHORTAGE FROM 6 JAN 74 THRU THE SUMMER OF 74. ; ALSO, FOR THE MODIFICATION WHEREIN WE GO BACK TO DAYLIGHT ; TIME IN LATE FEBRUARY OF 75 RATHER THAN LATE APRIL. AS THE LAW ; STANDS TODAY, WE REVERT TO APRIL-OCTOBER IN 1976, AND THIS CODE ; DOES THAT, TOO, BUT WATCH YOUR LOCAL CONGRESSMAN.... 27-Oct-86 19:27:23-PST,874;000000000000 Return-Path: <@CU20B.COLUMBIA.EDU:STAFF.HERSHMAN@NYU20> Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Mon 27 Oct 86 19:22:53-PST Received: from NYU20 by CU20B with DECnet; 27 Oct 86 22:24:28 EST Date: Mon 27 Oct 86 22:23:01-EST From: Ittai Hershman Subject: Re: Daylight Savings Time To: Tops-20@SU-SCORE.ARPA cc: Staff.Hershman@NYU20 Reply-To: Ittai@NYU In-Reply-To: Office-Phone: 212-285-6068 Message-ID: <12250288223.15.STAFF.HERSHMAN@NYU20> Hey guys, you're really behind in such matters. DEC solved the problem in VMS -- you have to change the time manually!!! -Ittai PS: As I recall, it has been SPRed, and DEC's response was basically that since there was no way to implement DST and make everyone happy, they felt it should not be done in the OS. ------- 28-Oct-86 15:44:16-PST,1229;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Oct 86 15:42:48-PST Date: Tue 28 Oct 86 15:29:37-PST From: Mark Crispin Subject: DEC license transfer policy To: TOPS-20@SU-SCORE.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12250507876.22.CRISPIN@SUMEX-AIM.ARPA> A trade magazine reports that effective January 1 you cannot transfer your DEC software licenses when you sell your equipment. It was also claimed that you lose any trade-in value on your software license when you upgrade, but apparently that was incorrect and DEC is modifying their public pronouncements so they don't imply that. This doesn't affect 10/20 sites all that much since 10/20 hardware and software licenses are pretty much worthless for resale, but you should keep this in mind before considering a DEC software license to be a tangible asset on your books. As far as I know, there has not been any decision made by DEC either way on the question of abolishing 10/20 software licenses (and placing all the 10/20 software in the public domain) when development ends in 1988. ------- 29-Oct-86 17:54:15-PST,975;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Wed 29 Oct 86 17:48:26-PST Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP id AA11486; Wed, 29 Oct 86 19:40:26 EST Received: from charlie (via mulga) by munnari with SunIII (5.5) id AA24479; Thu, 30 Oct 86 10:46:13 EST Received: by charlie .Deakin (4.12) id AA04381; Thu, 30 Oct 86 10:21:51 est Date: 30 Oct 86 10:21:48 +1000 (Thu) Message-Id: <104.531015708@charlie> To: Tops20 People Subject: 2 questions that have been asked before From: Craig Warren 1. Can Tops-20 be patched to use an RP07 as a bootable PS: structure? Is this supported in V6? 2. Can an RP07 that has been used as a structure on a VAX be used on a DEC-20 without going back to the factory for 36 bit sector formatting? Craig Warren ccw%charlie.oz@seismo.css.gov 30-Oct-86 01:40:33-PST,839;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 30 Oct 86 01:38:54-PST Date: Thu 30 Oct 86 02:40:44-MST From: Mark Crispin Subject: Re: 2 questions that have been asked before To: munnari!charlie.oz!ccw@SEISMO.CSS.GOV cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: <104.531015708@charlie> Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12250881271.8.MRC@SIMTEL20.ARPA> Craig - Lots of sites use RP07's as PS: structures. It's supported by DEC. What you cannot do with an RP07 is have the *front end* booted from it. This is because the RP07 is too fast for the RH11. There is a field procedure to reformat an RP07. Your Field Service troll should know how to do this. -- Mark -- ------- 30-Oct-86 13:18:56-PST,607;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Thu 30 Oct 86 13:17:03-PST Date: Thu 30 Oct 86 12:54:00-PST From: Bruce Tanner Subject: Password expiration To: TOPS-20@SU-SCORE.ARPA Message-ID: <12251003836.46.CERRITOS@USC-ECL.ARPA> I've been asked to implement a way to enforce our rules on maximum password age. Nothing fancy, I'm sure its being done all over the place. Would someone point me to an existing package that I can use? I'd also like to look at the password generator described in RFC972. -Bruce ------- 31-Oct-86 04:53:35-PST,832;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 04:52:07-PST Date: Fri 31 Oct 86 07:42:35-EST From: Ken Rossman Subject: TU78 unit number swapping To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12251176520.145.SY.KEN@CU20B.COLUMBIA.EDU> We have a pair of TU78's (on a single TM78 controller), which are dual-ported between to TOPS-20 systems. For some reason, every once in awhile, the unit numbers of the drives seem to get swapped so that what used to be drive 0 is shown as 1 and 1 is shown as 0. Also, I think at one point in the past, we had them show up as units 2 and 3. Anyone ever seen this? Anyone know why this happens? /Ken ------- 31-Oct-86 05:31:30-PST,1582;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 05:30:48-PST Date: Fri 31 Oct 86 08:32:26-EST From: Ken Rossman Subject: CFS confusion/lockup To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12251185595.145.SY.KEN@CU20B.COLUMBIA.EDU> Any CFS wizards out there want to try this one on for size? We have a CFS cluster with three KL's and one HSC50 in it. The HSC50 controls 9 RA81's. In the past couple of weeks, we have seen a problem where apparently GTJFN%'s on files in a certain directory (or perhaps it's just a GTJFN% on a certain file) will hang the calling process uninterruptably. Unfortunately, this file ends up being one which is commonly used, so lots of users tend to get hung up very fast, and the system becomes unusable for the majority of users. Users who never get around to accessing the particular file that happens to cause the problem will never get hung, but since it tends to usually be a commonly used file, most of the users do get hung. The only solution we've been able to come up with that works is to reload all KL's in the cluster. Accompanying these situations somewhere along the line are FLKTIM, FLKNS, and MSCCDF BUGCHK's (additional data for the FLKNS is a job fork number of 1 -- the others I don't have additional data on currently). Anyone seen anything like this happen? Any ideas on what might be happening and how to fix? /Ken ------- 31-Oct-86 07:36:00-PST,1164;000000000000 Return-Path: Received: from im4u.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 07:34:05-PST Date: Fri, 31 Oct 86 09:32:47 cst Posted-Date: Fri, 31 Oct 86 09:32:47 cst Message-Id: <8610311532.AA18171@im4u.UTEXAS.EDU> Received: from pop.cs.utexas.edu by im4u.UTEXAS.EDU (4.22/4.22) id AA18171; Fri, 31 Oct 86 09:32:49 cst Received: by pop.cs.utexas.edu (LFL/UT SM); Fri, 31 Oct 86 09:32:38 CST From: ctp@pop.cs.UTEXAS.EDU To: tops-20@su-score.ARPA Subject: Newsletters Does your site have a newsletter that publishes articles that might be interesting to other large sites? If so, please add me to your newsletter mailing list. I am sure that every now and then there are articles that are worthy of being reprinted (with permission) in the DECUS Large Systems SIG Newsletter. ----- Clyde T. Poole, Computing Resources Manager ARPA: ctp@sally.utexas.edu VOICE: (512) 471-9551 UUCP: {harvard,ihnp4,seismo}!ut-sally!ctp CIS: 75226,3135 Overland: UT at Austin, Department of Computer Sciences Taylor Hall 2.124, Austin, TX 78712-1188 "Life is a bitch ... and then you die" 31-Oct-86 09:08:49-PST,1934;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 09:06:23-PST Date: Fri 31 Oct 86 11:58:15-EST From: Christopher Edward Kalish Subject: UFPGS% bug? To: Tops-20@SU-SCORE.ARPA Office: 719 Watson Telephone: (212) 280-3538 Home: Room 9A8 Wallach Telephone: (212) 280-6697 Message-ID: <12251223063.156.SY.CHRIS@CU20B.COLUMBIA.EDU> Problem: UFPGS% will crash TOPS-20 V6.1 if given a nonexistent page to update. Description: UFPGS% will allow a process to attempt to update a file page which is no longer current. That is, a process can open and map a file, then unmap the file, close it, and then try updating the file page. This will produce the following BUGHLT: BUGHLT: CFNLTK CFSSRV - NULL DISK ADDRESS GIVEN TO CFSAWT Module: CFSSRV Hardness: SOFT Additional data: Cause: A call was made to create an OFN access token, but SPTH for the OFN is not set up. The following code crashes the 6.1 Tops-20 monitor that we're currently running at Columbia University: TITLE CRASH SEARCH MONSYM, MACSYM STDAC. MAPPGE==100 ; Reserve a page for mapping START: MOVX T1, HRROI T2, [ASCIZ \TEMP.TMP.0\] GTJFN% ; Get a JFN on some file JSERR MOVX T2, OPENF% ; Open the file JSERR HRRM T1, Q1 ; Save our JFN for later use HRLZS T1 MOVX T2, <.FHSLF,,MAPPGE> MOVX T3, PMAP% ; Map the file page to our process JSERR SETO T1, MOVX T2, <.FHSLF,,MAPPGE> SETZ T3, PMAP% ; Unmap the file JSERR MOVX T1, HRR T1, Q1 CLOSF% ; Close the file, but keep the JFN JSERR HRLZ T1, Q1 ; *** Now, try updating the file page we had MOVX T2, 1 ; *** UFPGS% ; *** Update the file pages - WE CRASH HERE JSERR HALTF% JRST CRASH2 END START ------- 31-Oct-86 13:45:51-PST,1008;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 13:45:04-PST Date: Fri 31 Oct 86 13:44:19-PST From: Ken Harrenstien Subject: Device type 025? To: tops-20@SU-SCORE.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12251275139.17.KLH@SRI-NIC.ARPA> There seems to be a conflict here. In MONSYM.MAC, the symbol .DVADS is defined as 025 for "AYDIN DISPLAY" (whatever that is). However, in the INIDVT table in STG.MAC (which sets up DEVCHR), 025 is used as the device type for the TCP: device. There is no .DVTCP symbol, although one would reasonably expect this. I find it hard to believe that the INIDVT table doesn't use symbolic .DVxxx constants, and even harder to believe that there is no .DVxxx for TCP:. This is for the 6.1 sources from Stanford. Considering the mess things are in, I'm not sure whether it is safe to write portable code which does a DVCHR% on a JFN to see whether it is a TCP stream or not. ------- 31-Oct-86 15:44:06-PST,484;000000000000 Mail-From: BILLW created at 31-Oct-86 15:43:36 Date: Fri 31 Oct 86 15:43:36-PST From: William "Chops" Westfield Subject: ANSI Tape question... To: tops-20@Score.Stanford.EDU Message-ID: <12251296853.40.BILLW@Score.Stanford.EDU> IIn version 5.?, apparently it is not possible to read files from an ansi labeled tape unless the fiels are sorted in alphabetic order. Has this been fixed in 6.1? Is tehre a fix for this? Thanks Bill W ------- 31-Oct-86 15:45:26-PST,1463;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 15:44:53-PST Date: Fri 31 Oct 86 18:46:11-EST From: Ken Rossman Subject: Re: TU78 unit number swapping To: LARSON@SRI-KL.ARPA cc: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12251297326.145.SY.KEN@CU20B.COLUMBIA.EDU> You would like them to get the right unit numbers. This is easy to do, even though DEC forgot that they put the code in to make it easy. Just specify the mapping between the drives and their serial numbers, and they will be carefully put in the correct positions. Do this on each system that they are connected to. ; Magtape logical number/serial number correspondence magtape 0 7023 tu78 magtape 1 3450 tu78 This is in 6-1-CONFIG.CMD, no? We have had these commands in all of our config files for a long time now, but seems that didn't help. I suppose it's not really important since you can always just go by whatever the software believes is the case, and not worry about it (we go through MOUNTR and do volume checking and all that most of the time, so there shouldn't be all that much confusion). I was just curious why this happens. I had thought the unit numbers were hardwired inside the drives somewhere, so I was baffled when they suddenly flip-flopped. /Ken ------- 1-Nov-86 00:59:06-PST,1508;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 00:57:24-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 1 Nov 86 00:56:04-PST Date: Sat 1 Nov 86 00:43:12-PST From: Mark Crispin Subject: Re: Device type 025? To: KLH@SRI-NIC.ARPA cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12251275139.17.KLH@SRI-NIC.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12251395085.7.MRC@PANDA> Ken - I agree that the absence of a .DVTCP symbol is a bug, but I don't believe it is a good idea to have device dependence unless it is absolutely necessary. That is, your routines that may run on more than just TCP streams should only use the device independent I/O jsi and *not* MTOPR%, TCOPR%, IPOPR%, etc. You should only have TCP-dependent code at a level which already knows that the stream is TCP. In case you didn't know, the preferred way to do a "push" on a TCP stream is to use SOUTR% instead of SOUT% when you want to push. This is device-independent. It requires a bit of discipline to be device-independent, but it is definitely possible. My network software is all device- independent. I have never needed to look up the device type via DVCHR%. I suspect this is true of DEC's programmers as well, which is probably why the DVCHR% types haven't been well-maintained. -- Mark -- ------- 1-Nov-86 05:41:45-PST,808;000000000000 Return-Path: Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 05:40:01-PST Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id aa15685; 1 Nov 86 3:15 EST Received: by bu-cs.bu.edu (5.31/4.7) id AA16418; Sat, 1 Nov 86 01:46:54 EST Return-Path: Received: by bucsd.bu.edu (5.31/4.7) id AA26345; Sat, 1 Nov 86 01:46:48 EST Date: Sat, 1 Nov 86 01:46:48 EST From: budd@BU-CS.BU.EDU Message-Id: <8611010646.AA26345@bucsd.bu.edu> To: KLH@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA Subject: Re: Device type 025? I recall seeing that internal versions of 6.1 (pre release) used .DVNET (ie; the old NCP NET device) for TCP. You can always do a STDEV on /TCP/ to get a device designator. And determine the correct number from that. -phil 1-Nov-86 09:52:37-PST,3266;000000000000 Return-Path: Received: from oslo-vax.arpa by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 09:49:10-PST Date: 1 Nov 1986 18:49-EST From: steinar@oslo-vax.arpa Subject: Re: CFS confusion/lockup To: TOPS-20@SU-SCORE.ARPA Message-Id: <531251353/steinar@oslo-vax> In-Reply-To: Ken's message of Thu, 1-Jan-70 00:59:59 MET Ken, we've experienced these problems for two years now! We have two KLs in the cluster sharing three RA81s through the HSC50. The context is almost like you describe it: Upon increasing load, both systems eventually go into a hung-state. Prior to the hung we usually see a lot of FLKTIM/FLKNS bugchks. However, unlike what you say, the KL are totally "dead" from the user's point of view because _nobody_ will be able to do anything. You may very well be able to log in a new job, but at the very moment you access one of the RA81s, this job gets hunged as well. Sometimes both systems get hunged, sometimes only one of them. Sometimes the load grows to "infinity" on the system which is still "alive", I think a load-average of 174 is the highest score up till now! Sometimes reload of one the KLs will do, sometimes we have to reload both. Sometimes reloading of CI-20 cured the problem, sometimes not. Sometimes ILLFDB ("Illegal format for FDB in directory ..") and ILLACC(?) ("Illegal account block in directory ..") bugcks accompagny the FLKTIMs and FLKNSes The ILLFDB and ILLACCs always relate to directories on the same structure, and after a while you get "%Disk structure damaged - cannot allocate space" whenever you try to do disk i/o. A reload of one or both KLs will apparently fix the problem, however, CHECKD reveals that the file system has been clobbered and garbaged. In the worst cases we had to reformat the RA81 (we have one structure per RA81) and rebuild all directories from our backup tapes! (growf!). The "solution" to the problem: We have lots of dumps from the hung-situations, and engineers from both Marlboro and DEC Support Centre in Europe have been analyzing them. Up till now we've got work-arounds, patches and FCOs to fix the problem but the problem was still there. Two months ago DEC said the problem partly is due to the arbitration algorithm for the C-bus - the CI-20 KLIPA resides in channel slots 6 and 7 on the C-bus, these are 'slow' channels and are polled half as often as channels 0 to 3. They seem to think the C-bus gets overloaded causing loss of packets from the CI. If this is so, one may very well imagine that this eventually will cause the filesystem to be garbaged. You cannot plug the CI-20 into one of the fast channels, so they've not been able to produce any workarounds for the problem. We've been advised to use Massbus disks instead and leave the clustered RA81s for the moment. We've done so, and have at the moment 3 dual-ported RP07s. Unfortunately, we have some hardware problems with the Massbus cable and the RH20s, so it's too early for us to say if things have improved and the problems have gone .. Steinar Kjaernsroed, Institute of Informatics, University of Oslo, NORWAY email: steinar@oslo-vax.arpa 1-Nov-86 12:18:57-PST,1266;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Martin_Hughes_EuroKom@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 12:17:35-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708712789471349@MIT-MULTICS.ARPA>; 01 Nov 1986 15:13:09 est Date: 31 Oct 86 14:07 +0100 From: Martin_Hughes_EuroKom%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Martin_Hughes_EuroKom%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA, "Mark Crispin" Subject: RSX-20F patch Message-ID: <213073@QZCOM> We are using RSX-20F version 15-3. Does anyone know of a patch to cause the detaching of a job immediately the carrier drops. According to the manual, $DMINT receives an interrupt when carrier drops. It checks that the interrupt comes from a carrier drop. It then sets up various flags to say that carrier is lost and waits for carrier to come back up inside a set time. The patch we want stops these procedures from happening, $DMINT handles a carrier drop in the same way as an interrupt from a ring. Thanks, Martin 1-Nov-86 12:26:02-PST,811;000000000000 Return-Path: <@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 12:24:30-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708713125765357@MIT-MULTICS.ARPA>; 01 Nov 1986 15:18:45 est Date: 31 Oct 86 16:37 +0100 From: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA, "Mark Crispin" Subject: RSX-20F patch Message-ID: <213111@QZCOM> In-Reply-To: <213073@QZCOM> Apogies about the Version number - we run Rsx- 15-13. 1-Nov-86 12:35:32-PST,960;000000000000 Return-Path: <@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 12:34:20-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708713903224747@MIT-MULTICS.ARPA>; 01 Nov 1986 15:31:43 est Date: 31 Oct 86 16:33 +0100 From: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_O'Connor_UCD@EUROKOM To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SCORE.STANFORD.EDU Cc: John_O'Connor_UCD@EUROKOM Subject: summer time madness Message-ID: <213110@QZCOM> In-Reply-To: <12249963540.7.MRC@PANDA> Now you know what it feels like for a non-American user who has to change system time 2-3 times to account for the Dec-20's behaviour. 1-Nov-86 14:51:04-PST,1139;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 14:48:54-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 1 Nov 86 14:50:03-PST Date: Sat 1 Nov 86 13:52:56-PST From: Mark Crispin Subject: Re: summer time madness To: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <213110@QZCOM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12251538851.7.MRC@PANDA> John - If you want to use a different summer time scheme than the North American one that TOPS-20 uses for its algorithm, patch location DSTFLG in the monitor. Setting it to NEVDST will turn off summer time. Setting it to ALLDST will turn on summer time. Setting it to 0 will use the North American algorithm. I suspect that ALL non-North American users will want to patch DSTFLG to NEVDST, and perhaps patch it to ALLDST during their summer times. -- Mark -- ------- 4-Nov-86 15:13:51-PST,457;000000000001 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Tue 4 Nov 86 15:08:59-PST Received: ID ; Tue 4 Nov 86 17:33:25-EST Date: Tue 4 Nov 86 15:56:29-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: DUMPER query To: TOPS-20@SU-SCORE.ARPA Message-ID: <12252315008.6.VAF@C.CS.CMU.EDU> Has anyone modified DUMPER to write tape savesets to disk files (a la the VMS BACKUP program)? --Vince ------- 6-Nov-86 13:05:57-PST,1016;000000000000 Return-Path: <@SUMEX-AIM.ARPA,@MIT-MULTICS.ARPA:John_O'Connor_UCD@QZCOM.MAILNET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Nov 86 13:04:13-PST Received: from MIT-MULTICS.ARPA by SUMEX-AIM.ARPA with TCP; Thu 6 Nov 86 13:04:55-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2709143738503018@MIT-MULTICS.ARPA>; 06 Nov 1986 14:55:38 est Date: 06 Nov 86 11:54 +0100 From: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_O'Connor_UCD@EUROKOM To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: TOPS-20@SCORE.STANFORD.EDU, John_O'Connor_UCD@EUROKOM Subject: Re: summer time madness Message-ID: <214994@QZCOM> In-Reply-To: <214749@QZCOM> I found them in our 5.1 monitor o.k. Anyway - doesnt 6.1 have DISABLE DST command in the 6-1-CONFIG.CMD file ? 6-Nov-86 14:36:03-PST,863;000000000000 Return-Path: <@SUMEX-AIM.ARPA:ROODE@BIONET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Nov 86 14:34:38-PST Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Thu 6 Nov 86 14:30:17-PST Date: Thu 6 Nov 86 14:17:07-PST From: David Roode Subject: DECNET Errors in SPEAR To: TOPS-20@SU-SCORE.ARPA Phone: (415) 965-5585 Message-ID: <12252853974.13.ROODE@BIONET> We are getting constant "Partial routing update loss" errors in the system error files, under 6.1 with an NI. The increased size of the error files is a concern--this amounts to 5,000 pages per month. Does anyone have a way to avoid this error, or this error logging, since we see no signs of any problems. On this same network we have a lot of PUP traffic, and some XNS traffic, and a medium amount of IP traffic. ------- 6-Nov-86 16:30:25-PST,1213;000000000000 Return-Path: Received: from sun.com by SU-SCORE.ARPA with TCP; Thu 6 Nov 86 16:29:05-PST Received: from snail.sun.com by sun.com (3.2/SMI-3.0) id AA21341; Thu, 6 Nov 86 16:29:14 PST Received: from sluggo.sun.com by snail.sun.com (3.2/SMI-3.2) id AA20396; Thu, 6 Nov 86 16:28:19 PST Received: by sluggo.sun.com (3.2/SMI-3.2) id AA00211; Thu, 6 Nov 86 16:27:04 PST Date: Thu, 6 Nov 86 16:27:04 PST From: melohn@Sun.COM (Bill Melohn) Message-Id: <8611070027.AA00211@sluggo.sun.com> To: ROODE%BIONET@SUMEX-AIM.Stanford.EDU, TOPS-20@SU-SCORE.ARPA Subject: Re: DECNET Errors in SPEAR You are probably seeing this error because one or more of the other routers on your Ether have their max address set higher than yours. You can increase the max address via the config file entry DECNET MAX-ADDRESS, or tell the event logger to ignore the message by issuing the NCP command CLEAR LOGGING {FILE,CONSOLE,ALL?} EVENT 4.3 (or whatever the event number is for routing update loss). You can check out the other routers via the NCP command TELL {NODE} SHOW EXECUTOR CHARACTERISTICS. Remember, addresses higher than 255 will not work with phase 3 DECNET nodes (like DN20 MCBs). 7-Nov-86 11:33:05-PST,1480;000000000000 Return-Path: <@SUMEX-AIM.ARPA,@MIT-MULTICS.ARPA:Lars_Lindwall_LIDAC@QZCOM.MAILNET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Nov 86 11:30:44-PST Received: from MIT-MULTICS.ARPA by SUMEX-AIM.ARPA with TCP; Fri 7 Nov 86 11:30:32-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2709228136507129@MIT-MULTICS.ARPA>; 07 Nov 1986 14:22:16 est Date: 07 Nov 86 10:32 +0100 From: Lars_Lindwall_LIDAC%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Lars_Lindwall_LIDAC%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_O'Connor_UCD@EUROKOM To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: TOPS-20@SCORE.STANFORD.EDU, John_O'Connor_UCD@EUROKOM Subject: Re: summer time madness Message-ID: <215214@QZCOM> In-Reply-To: <214994@QZCOM> 6.1 has DISABLE DST in the CONFIG.CMD file. However, whenever we switch to or from daylight-saving time we have to run a program that resets system wallclock time. If we were able to patch the DSTFLG location at these moments instead, we would make more elegant use of the built-in DST features of TOPS-20. To do this we need the values of the symbols NEVDST and ALLDST. If you have found them in your version 5 monitor, what are they? 7-Nov-86 19:48:48-PST,826;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Nov 86 19:46:52-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 7 Nov 86 19:46:21-PST Date: Fri 7 Nov 86 18:08:36-PST From: Mark Crispin Subject: Re: summer time madness To: Lars_Lindwall_LIDAC%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_O'Connor_UCD%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <215214@QZCOM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253158258.7.MRC@PANDA> You should be able to check those values in MDDT or EDDT. DSTFLG is a cell, and NEVDST and ALLDST are both symbols. ------- 8-Nov-86 21:04:48-PST,1184;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 8 Nov 86 21:00:04-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 8 Nov 86 20:59:30-PST Date: Sat 8 Nov 86 20:44:52-PST From: Mark Crispin Subject: Re: MM bug To: CERRITOS@USC-ECL.ARPA cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12252874497.44.CERRITOS@USC-ECL.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253448849.7.MRC@PANDA> Bruce - The bug that causes MM to blow up if you do "MM BBOARD" on an MM fork that is declared KEEP START is due to IDXJFN being in an area of MM's data space that is not initialized at startup. This is fixed in MM 1118 as part of a more comprehensive fix, but for now you can move the definition of IDXJFN from where it is presently located to just after MSGJFN. Alternatively, you can patch MM at GO+2 to do a SETZM IDXJFN after the RESET%. A number of users at a number of sites have complained about this bug sporadically. I recommend that all MM sites install this fix. -- Mark -- ------- 10-Nov-86 09:09:36-PST,1675;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Mon 10 Nov 86 09:08:25-PST Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA02057; Mon, 10 Nov 86 12:06:35 EST Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.8) id AA10495; Mon, 10 Nov 86 17:50:11 +0100 (MET) Received: from majestix.ida.liu.se by liuida.UUCP; Mon, 10 Nov 86 17:30:31 +0100 Received: from LISBET by majestix.ida.liu.se; Mon, 10 Nov 86 17:30:23 +0100 Message-Id: <8611101630.AA10214@majestix.ida.liu.se> Received: from FREJA (not validated) by LISBET; Mon 10 Nov 86 17:40:02 Received: from ATHENA by FREJA using MAIL-11 Mon 10 Nov 86 17:24:28 Date: Nov 10, 1986 17:24 From: enea!aida.uppsala.se!VICTOR@seismo.CSS.GOV To: TOPS-20@score.stanford.edu Subject: Re: summer time madness Mailed-To: Lars_Lindwall_LIDAC@QZCOM.MAILNET, TOPS-20@SCORE.Stanford.EDU Here is how we patch the monitor to use the Swedish algorithm for daylight savings. (Assume you've done @get system:monitr.exe first). @ddt ; ******** Make TOPS-20 switch to and from Daylight Savings Time at the ; correct times. ; Year when DST-rule went into effect. =dstbgn/ *1980. ; Number of the day DST is to begin. (Last Sunday in March). =dston/ *31.+29.+31.-1. ; Number of the day DST ends. (Last Sunday in September). =dstoff/ *31.+29.+31.+30.+31.+30.+31.+31.+30.-1 *^Z ...and @save, of course. The say DAYLIGHT AUTOMATIC in 6-1-CONFIG.CMD, and you'll win. -- Bjorn Victor, Dept of Computer Systems, Uppsala Univ, Sweden ------- 13-Nov-86 17:03:16-PST,3972;000000000000 Mail-From: GROSSMAN created at 13-Nov-86 17:03:12 Date: Thu 13 Nov 86 17:03:12-PST From: Stu Grossman Subject: The latest and greatest. To: su-tops-20@Score.Stanford.EDU Message-ID: <12254719218.17.GROSSMAN@Score.Stanford.EDU> The latest and greatest set of TOPS-20 sources are now on SIERRA. They reflect Autopatch tape 14, and therefore have many bug fixes above and beyond version 6.1 field test tape 6 (which most of you are currently running). We have been running a monitor based on these sources for about a month and have seen no major problems. In addition, this monitor speeds up access to large files by approximately 30%. This was exhibited during an EXEC COPY command of a dump file from one structure to another. This monitor also contains many local bug fixes for things such as IP subnets, IP/TCP performance. Also, the 'Shutdown complete' message now comes out at the right time. There are many other bug fixes, and they are too numerous to mention here, but it's all in the sources (in comments). Now, a word about the sources: The sources now exist in a somewhat different arrangement. They are now in a tree structure with some amount of ordering and naming conventions. The head of the tree is pointed at by the system wide logical name 61: on SIERRA. The directory at 61: contains a file called -README-.TXT. PLEASE TAKE A LITTLE TIME AND READ THIS FILE!!!!!!!! It describes the structure of the directories and some guidelines on their usage. There is also a file called LOGICALS.CMD. This does the obvious, and should be the 'official' names for the various directories and search lists that comprise the source tree. Let me take a moment and breifly discuss some of the salient features of the new directory tree. First, there are now directories that are considered 'SACROSANCT'. These should not be touched under ANY circumstanses. They reflect the exact set of sources from DEC and are what the Stanford sources are based on. Second, the directories that contain Stanford code, now contain ONLY Stanford code. That means that a complete set of monitor sources consists of the union of the directories SRC:<6.1.MONITOR.STANFORD>, and SRC:<6.1.MONITOR>. In case of conflicts, the Stanford sources are preferred. The logical name M61: is a search list which reflects this organisation. This organisation was done so as to make the code merging process easier. It also gives people a better idea of how much of the monitor we really change. The above organisation also applies to Galaxy, and the utilities and languages directories. I made a token attempt to do this to the EXEC, but my patience ran out. Volunteers for this heinous task will be greatly appreciated. Now, for a breif word about build procedures: First, it is no longer necessary to build different monitors for machines with different memory sizes. The monitor is now smart enough to automatically size it's tables according to the amount of memory actually present on your system. Therefore everyone should probably build for a 4 meg machine. Second, the number of spooled LPTs (LPTx: devices) should no longer be related to the number of physical LPTs (PLPTx: devices) for machines that have network line printers. This parameter is now seperate and distinct from the number of physical LPTs. You should set this parameter so that it generates enough LPTx: devices to accomodate all of the GALAXY printer units that you spool to. Third, LAT has been removed from this monitor. It saves some space and computes. You should also set the parameter NTTLAH to 0 in your per site PARxyz.MAC file. In fact, compare PARSRA with you PARsite to see if you will need anything else changed. Well, have fun! I'm leaving on vacation in a few moments, and won't be back until December. Really, I'm not joking! Yours truly, Stu ------- 15-Nov-86 16:38:58-PST,2312;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 15 Nov 86 16:35:33-PST Date: Sat 15 Nov 86 17:36:49-MST From: Frank J. Wancho Subject: Host Table Conversions To: TOPS-20@SU-SCORE.ARPA Message-ID: <12255238702.6.WANCHO@SIMTEL20.ARPA> We are still running a 2040 here with 512KW. The amount of space we have allocated in the monitor to accommodate even a stripped HOSTS.TXT file appears to be causing performance problems with Internet connections as it limits the amount of internet free space (or words to that effect). Up until yesterday, I had been hand-editing HOSTS.TXT (aided with an EMACS macro) to remove all NET and GATEWAY entries and all HOST entries which do not contain any of the strings TAC, TCP/TELNET, TCP/FTP, or TCP/SMTP, and then restoring three entries we needed for our mailing lists. Yesterday, I decided it was time to do something as the performance problems was causing various crashes both here and on STL-HOST1. I wrote a small, simple-minded C program to process the HOSTS.TXT file as above, and, in addition, remove all the nicnames. the resulting file is 109 disk pages, vs. the original 159 pages. Then I needed a utility to process the various mailing lists we have here to replace the host name with the Official host name. That was also written, and also somewhat simple-minded. The source and executables for both programs are available in PS: here for anybody to grab. The first program is FIXHST and takes two arguments, the HOSTS.TXT input file name, and an output file name. An optional third argument may be specified to name a file containing entries to be appended as-is to the output file. The second program, CVTLST, takes only two arguments: the mailing list file name, with the entries expected to be one per line, and an output file name. Host names which cannot be found are written as (null), and the last entry has a trailing comma, meaning the output file will need to be edited. CVTLST must be run on all mailing list files BEFORE you load the stripped hosts file into the system. Both source files should be compiled with the latest KCC if you need to change its action. Trying to keep up with the times, Frank ------- 19-Nov-86 11:13:25-PST,1049;000000000000 Mail-From: BILLW created at 19-Nov-86 11:12:49 Date: 19 Nov 1986 11:12-PST Sender: BILLW@SU-SCORE.ARPA Subject: [enea!tut!jh@seismo.CSS.GOV (Juha Hein{nen): TCP/IP for TOP...] From: William "Chops" Westfield To: tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]19-Nov-86 11:12:48.BILLW> Is this true? Did the Issue of whether DEC was charging for TCP ever get resolved? Assuming that this person has a source license, can he just get TCP sources from some random site ? Begin forwarded message Date: Sun, 16 Nov 86 14:20:12 -0200 From: enea!tut!jh@seismo.CSS.GOV (Juha Hein{nen) To: tcp-ip@sri-nic.arpa Subject: TCP/IP for TOPS-20 A neighboring university has got two DEC 2060s and would like to run TCP/IP on them. The problem is that Digital doesn't support TCP/IP in Europe and refuse to sell the product. Are there any other sources than Digital whom they could get TCP/IP for TOPS-20? Juha Heinanen Tampere Univ. of Technology Finland ----------------- End forwarded message 20-Nov-86 10:31:47-PST,991;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Bjorn_Carlsson_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Nov 86 10:30:34-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710319812473934@MIT-MULTICS.ARPA>; 20 Nov 1986 05:36:52 est Date: 20 Nov 86 01:15 +0100 From: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: [enea!tut!jh@seismo.CSS.GOV (Juha Hein{nen): TCP/IP for TOP...] Message-ID: <218570@QZCOM> In-Reply-To: <"[SU-SCORE.ARPA]19-Nov-86 11:12:48.BILLW"@NODOMAIN> Eh? We're running TCP/IP on a 2065 here in Stockholm, Sweden, and we got it from DEC. (Over a NIA-20). And the last time I looked at a map Sweden certainly was located in Europe. 21-Nov-86 10:26:13-PST,1081;000000000000 Return-Path: Received: from MCC.COM by SU-SCORE.ARPA with TCP; Fri 21 Nov 86 10:24:54-PST Date: Fri 21 Nov 86 12:26:17-CST From: Clive Dawson Subject: Net woes To: tops20@SU-SCORE.ARPA Message-ID: <12256744113.39.AI.CLIVE@MCC.COM> We are being plagued with various network problems which I'm wondering if anybody else has seen. The most serious one happens after TOPS-20 has been up for a day or two, at which point we begin getting a rash of IPGCOL's and INTFR6's. Both our AN20 and IPNI networks become unusable, and we are forced to reload. Don Watrous at Rutgers suggested reducing the NI's packet-size from 1500 to 576, but that has not solved the problem. Another possibly related problem which happens sometimes after the network starts misbehaving: @ftp TOPS-20 FTP 3.0, type HELP if you need it. FTP>racine ?Couldn't connect to RACINE.AI.MCC.COM - TCP specification atrribute not known to TCP Any tips or info about similar experiences would be appreciated. Thanks, Clive ------- 21-Nov-86 13:47:18-PST,1299;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 21 Nov 86 13:44:01-PST Date: Fri, 21 Nov 1986 16:19 EST Message-ID: From: Rob Austein To: Clive Dawson Cc: tops-20@SU-SCORE.ARPA Subject: Net woes In-reply-to: Msg of 21 Nov 1986 13:26-EST from Clive Dawson Date: Friday, 21 November 1986 13:26-EST From: Clive Dawson @ftp TOPS-20 FTP 3.0, type HELP if you need it. FTP>racine ?Couldn't connect to RACINE.AI.MCC.COM - TCP specification atrribute not known to TCP Well, this is kind of interesting. Look in TCPJFN.MAC, just after TCPATR:. It seems that you get this error code (TCPXX5) if there's something wrong with one of the filespec attributes (like specifying ;COPIES: on a TCP connection). But it also seems you can get this error if you get to this routine and there isn't a TCB in FILTCB(JFN). Amazing, the things one can reuse error codes for.... Given that this happens to you when your net has started falling apart, I would assume that your problem is the lost TCB case. This might actually be of some use tracking down the problem. --Rob 21-Nov-86 18:25:51-PST,1363;000000000000 Mail-From: BILLW created at 21-Nov-86 18:25:27 Date: 21 Nov 1986 18:25-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: Net woes From: William "Chops" Westfield To: AI.CLIVE@MCC.COM Cc: tops20@Score.Stanford.EDU Message-ID: <[SU-SCORE.ARPA]21-Nov-86 18:25:27.BILLW> In-Reply-To: <12256744113.39.AI.CLIVE@MCC.COM> We had the problem with getting repetative IPGCOLs and INTFRxs after the system had been running for a while. Eventually the system would become completely wedged or crash. I looked at the code in IPFREE, and as near as I could tell all the IP garbage collector did was pick up garbage from one area and throw it down again. Our solution was to modify the monitor to use the BBN version of IPFREE instead, which seems to work much better. I think changes were necessary to STG, IPFREE, and ANAUNV. The BBN IPREE uses two word headers to the free block lists, but I never did figure out what else was different about it (aside from extensive cosmetic changes...) The TCP code had undergone other improvements at Stanford too. The latest version has achieved throughput of over 400K bps using stanford (TCP: device) FTP and CMU (BBN interface) FTPSRT. (6.1 monitor, MCA25, MEIS). Ill check about making it available to interested parties. (This should not be a problem for source sites). BillW 24-Nov-86 20:09:27-PST,1485;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Mon 24 Nov 86 20:07:16-PST Date: Mon, 24 Nov 1986 23:11 EST Message-ID: From: Rob Austein To: Tops-20@SU-SCORE.ARPA Subject: Bug in HSTINI routine Bug: Tops-20 falls over and dies while reading SYSTEM:HOSTS.TXT, or somewhere in that general area. In our case it was an ILMNRF BUGHLT just -after- returning from HSTINI. Diagnosis: HSTINI was written back in the days when you could count the number of networks on your fingers and you didn't need a dedicated computer just to type in the hostnames for you. In the TRVAR at the head of HSTINI there's this thing called TMPBUF which is 10 words long. You would think that 40 characters would be enough. Well, this random unix hacker just added DUMMY-HOST-FOR-INITIALIZATION.LCS.MIT.EDU to XX's host tables. Asciz strings do not make very good BLT pointers. Cure: In MNETDV, somewhere around RDFLD2:+13, change AOS COUNT ;count is probably -2(P) ;in case you have to do this with DDT to AOS T2,COUNT CAIL T2,50 ;Still room in TMPBUF? JRST PEOLX ;No, pretend premature EOL A more elegant fix would be to make the length of TMPBUF a symbol and check against that. 40 characters is probably too short these days (groan). Also, give this error its own message instead of using the one for premature EOL. --Rob 2-Dec-86 14:40:34-PST,545;000000000000 Return-Path: Received: from USC-ECLB.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Dec 86 14:38:17-PST Date: Tue 2 Dec 86 14:36:30-PST From: Christopher Ho Subject: patch to SPLFK% To: Tops20@SU-SCORE.ARPA Office: Ucc 178 (213)743-2957 Message-ID: <12259673248.56.CHRIS@USC-ECLB.ARPA> I am looking for DEC's Edit 3086 for Tops-20 v5.1. This was a patch to fix the SPLFK% JSYS; it was supposedly on Autopatch tape #8, but we don't use Autopatch. Any help would be appreciated. Thanks. ------- 2-Dec-86 18:20:36-PST,2342;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 2 Dec 86 18:16:48-PST Date: Tue 2 Dec 86 21:13:53-EST From: Thomas De Bellis Subject: Net Woes; Running out IP free space To: Tops-20@SU-SCORE.ARPA Message-ID: <12259712821.136.SY.SLOGIN@CU20B.COLUMBIA.EDU> Here at Columbia I have been grappling on and off with the IP free space problem for a couple of months now. To say that we are getting bitten by it is to put matters lightly. It is maddening. The system can not perform any Internet services and the internet fork running the garbage collector *really* slows us down. I have tried everything I can think of to grab the space back. This has included some rather drastic (and perhaps foolish) measures such as stomping the INTFSP variable to some arbitrary value and calling FREINI in IPFREE. That I am willing to engage in such nonsense as calling a once only boot time routine while the system is running indicates how desperate I'm getting--nothing I have tried has ever worked short of rebooting the system. What we'd like is some way of backing out of the problem. I'd even settle for a consistent way of reproducing it. So far, we have some interesting leads. Here is our current situation: We have an 8650 running Ultrix 1.2 that has no local printer. All of these printers are on our various 20's (which aside from this problem are still alive and kicking, thank you), but just about all of the print traffic goes through one machine, CU20D. Want to guess where we see most of our IPGCOL bugchks? Apparently, the LPD daemon that we were running on CU20D was getting hung (for an unrelated reason), but the Vax seemed to be still trying to make connections. We suspect that these failed connections caused some storage to be lost. Right now, I have our print daemon on another machine ^C'ed and I have the Vax set up trying to spool files to that machine. I'm going to leave it running and see what happens. If any of you have other good ideas or possible tricks to try to tickle the bug, please mail them to me. At this rate, another software crash one way or the other isn't going to be noticed. I am willing to try just about anything. -- Tom ------- 3-Dec-86 08:24:26-PST,1259;000000000001 Return-Path: <@SUMEX-AIM.ARPA,@PANDA:CARL@SCU> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Dec 86 08:23:39-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 3 Dec 86 08:24:33-PST Received: from SCU by PANDA with Cafard; Wed 3 Dec 86 07:18:38-PST Date: Wed 3 Dec 86 06:35:38-PST From: Carl Fussell On-Terminal: 67 Subject: Reading DEC 20 dumper tapes on VAX. To: tops-20@SU-SCORE.ARPA, info-vax@SRI-KL.ARPA Message-ID: <12259847851.2.CARL@SCU> We are experiencing a problem and perhaps some on these lists can shed some light. We are a DEC 20/TOPS-20 site converting to a VAX 8650. We got the conversion tools tape from DEC but have been unable to get the tape utility on it to read our Tops Dumper tapes onto the VAX. The dumper that wrote these is vanilla and I believe the latest version. I don't think that Interchange format was used when they were written... is that going to cause us problems? Is anyone else on VAXes had any luck reading Tops 20 Dumper tapes onto a VAX VMS system with any success with any tool?? Thanx in advance for any suggestions, advice, condolences, ... Carl Fussell Carl%scu%panda@sumex-aim.arpa g.fussell@su-score.arpa ------- 3-Dec-86 08:53:07-PST,931;000000000001 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Wed 3 Dec 86 08:52:36-PST Received: from (SYSTEM)SITVXA.BITNET by WISCVM.WISC.EDU on 12/03/86 at 10:53:17 CST Date: Wed, 3 Dec 86 11:54:10 EST From: rmcqueen(Robert C McQueen)%sitvxa.BITNET@WISCVM.WISC.EDU Message-Id: <861203115400.001@sitvxa> Subject: Reading DEC-20 dumper tapes on a VAX To: g.fussell@su-score.arpa cc: info-vax@sri-kl.arpa , tops-20@su-score.arpa If you are using the SI-DUMPER utility, the standard mistake that I have seen is that you haven't defined the command for SI-DUMPER. There should be a ..CLD file as part of the distribution to define the command. If you still have a problem with SI-DUMPER drop me another note, since it works fine on my VAX systems. Robert McQueen Stevens Institute of Technology RMCQUEEN@SITVXA.BITNET SIT.MCQUEEN@CU20B.COLUMBIA.EDU 3-Dec-86 10:40:50-PST,2355;000000000000 Return-Path: Received: from MCC.COM by SU-SCORE.ARPA with TCP; Wed 3 Dec 86 10:39:23-PST Date: Wed 3 Dec 86 12:40:50-CST From: Clive Dawson Subject: Re: Net Woes; Running out IP free space To: Sy.SLogin@CU20B.COLUMBIA.EDU cc: Tops-20@SU-SCORE.ARPA In-Reply-To: <12259712821.136.SY.SLOGIN@CU20B.COLUMBIA.EDU> Message-ID: <12259892488.13.AI.CLIVE@MCC.COM> A few days after I reported problems with IP free space similar to Tom's, our network configuration changed slightly. In particular, a bunch of SUN 3's which used to share a Ethernet cable with our 20 were put onto their own subnet. Guess what? We haven't had any free space problems since! Here's my theory: A well known problem with these new SUN workstations is that they are sending out oversized ARP packets. For some unknown reason, the 20 can't handle these properly. You would think that the extra trailing bytes would simply be ignored, but in fact what happens is that the extra bytes cause corruption at the BEGINNING of the packet. Nobody can figure out what the KLNI might be doing to cause this. (Perhaps some strange buffer wrap-around ?) Anyway, Rutgers has a patch for this which they claim works for them. When I installed that patch (which essentially increases the ARP buffer size by a few bytes), I found I still had problems. In particular, I started crashing with ILMNRF's. I tracked this down to the fact that my ARP buffer links were getting corrupted in the buffer headers. I removed the Rutgers patch, deciding it was better to not be able to talk to SUN 3's rather than crash completely. Back to the free space problem... We started getting IPGCOL's at about the same time that a bunch of SUN 3's got installed on our Ethernet cable. When the SUNs got taken off, the problem went away. I suspect that those oversized ARP packets are somehow causing corruption of the free space links, which over time will cause more and more blocks to get "lost". This explains why the problem doesn't show up until the system has been up for a day or two. So the current question is, do you have SUN 3's on your net, Tom? BTW, I hear that SUN has fixed the problem in their latest software release (version 3?), but many of our systems don't have this release yet. Clive ------- 4-Dec-86 12:15:54-PST,921;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Bjorn_Carlsson_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Dec 86 12:11:54-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2711563515424428@MIT-MULTICS.ARPA>; 04 Dec 1986 15:05:15 est Date: 04 Dec 86 03:32 +0100 From: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Thomas De Bellis" Cc: Tops-20@SU-SCORE.ARPA Subject: Re: Net Woes; Running out IP free space Message-ID: <221037@QZCOM> In-Reply-To: <12259892488.13.AI.CLIVE@MCC.COM> We've also had a lot of IPGCOL's and we're on an ethernet with SUNs. So you may be right. 4-Dec-86 16:57:00-PST,3606;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 4 Dec 86 16:56:10-PST Date: Thu 4 Dec 86 19:53:32-EST From: Thomas De Bellis Subject: Update: Net Woes; Running out IP free space To: Tops-20@SU-SCORE.ARPA Message-ID: <12260222482.136.SY.SLOGIN@CU20B.COLUMBIA.EDU> Thank you all for your comments--it's refreshing to get some new ideas. To answer some questions, yes, we are running the very latest 6.1 release. We had to go through a bit of politicing to get the latest internet stuff, but that's another story. Frank Wancho suggests that it might have something to do with the size of our host tables. Right now, I would be inclined to doubt that this is the problem. The machine (CU20D) that is getting most of the IPGCOL's is running a reduced size (4 page) HOSTS.TXT table. We do this to reduce total system start up time since we don't allow the students to access the general ARPAnet, anyway. The machine (CU20B) that does have the full sized tables (160 pages) doesn't seem to have the problem as much. Also, one of the other crazy things that I have tried to get us back IP free space was to call the routine that reads the HOSTS.TXT file to reinit things. That didn't work so I then tried deleting the HOSTS.TXT file and calling the monitor routine again in MDDT to reclaim any space I could. It didn't work. Nothing works. Grumph!!!! My own suspicions about LPD don't seem to have panned out very well. Since my last letter, I have left that ^C'ed LPD daemon sitting on CU20B and several processes on the VAX trying to talk to it. IP free space on CU20B is just fine. In fact, we've been up even longer than usual... I guess that was a blind alley or I havn't properly reproduced the situation. Clive Dawson's comments about SUN 3's are *most* interesting. We do have an ethernet and our CS department has several SUN workstations floating around. I don't know if we have any SUN 3's so I'll have to track that down, but perhaps a couple of them got connected to the campus network from their internal network. I have some questions about that, though. Aren't ARP packets broadcast to *all* hosts on that ethernet? I have 3 DEC20's on the same ethernet (and same subnet), wouldn't they have all gotten the IPGCOL problem at the same time? Our impression is that CU20D is getting the most problems (over 4000 IPGCOL's to CU20B's 1). What about the other machines? How might I get some machine that I have control of to send out these oversized ARP packets to test this theory? I can get time on one of our 20's and some Ultrix systems (a VAX 8650 and a 750). If somebody has a quick and dirty program to try or knows of a parameter that I can set to change to force funny ARP packet sizes, I'd love to hear about it. Andrew Sweer's suggestion about the packetizing code would seem to jive with our environment in that the machine that saw more traffic would get more problems. While we have seen ILMNRF's, our problem seems to manifest itself by an INTFR6 followed by +infinity IPGCOL's. However, I like that patch that stomps WNDSPC to zero and the continues. I'll check with a couple of people about putting this in and then seeing what happens. Along these lines, has anyone every succeeded by any means to get back the IP free space once it is exhausted? Where is it going?? We don't care how crazy your method is--this is New York City: we'll try anything. -- Tom ------- 7-Dec-86 07:15:01-PST,726;000000000000 Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 7 Dec 86 07:11:15-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 7 Dec 86 07:10:23-PST Date: Sun 7 Dec 86 05:01:06-PST From: Mark Crispin Subject: ^O in TEXTI%, etc. To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12260879218.7.MRC@PANDA> Dan Murphy put in a feature to TEXTI% back in 1981 that causes CTRL/O to be equivalent to CTRL/R if it is ever seen in the input stream. I have no idea what the purpose of this change was. I think it's a bug. Comments? ------- 8-Dec-86 12:09:06-PST,671;000000000000 Return-Path: Received: from SRI-STRIPE.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Dec 86 12:02:53-PST Date: Mon 8 Dec 86 12:04:43-PST From: David L. Edwards Subject: Bug in NTINF% To: tops20@SU-SCORE.ARPA Message-ID: <12261218481.16.DLE@SRI-STRIPE.ARPA> There is a bug in NTINF% where if you are using a job number for a detached job, the system will crash with an ILLUUO. The problem is at NTRRH1 in JSYSA. The following should fix the problem. Old: New: NTRRH1: HLRZ T1,JOBPT(T1) NTRRH1: HLRE T1,JOBPT(T1) SKIPGE T1 RETBAD (GTJIX2) This problem is being reported to DEC. -dle ------- 8-Dec-86 12:14:58-PST,1474;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Dec 86 12:11:17-PST Date: Mon 8 Dec 86 12:09:47-PST From: Andrew Sweer Subject: TCP Packetizer bug To: TOPS-20@SU-SCORE.ARPA Message-ID: <12261219403.13.SWEER@SUMEX-AIM.ARPA> Some versions of TCPTCP.MAC have a bug which can cause the transfer of data from a user buffer to a monitor packet buffer to go past the end of the packet, causing random lossage in the data following the packet. At SUMEX-AIM, this has caused ILMNRF, INTFRn, and various other BUGHLTs, as well as loops in the Internet fork which can lead to DDMPNR crashes. To see if you have this bug, examine location PKTIZ7+5. If this contains a SUB 7,2, then you have the bug. The fix is to ensure that AC7 is non-negative following the SUB 7,2. A source fix looks like the following: following the SUB WNDSPC,T2 at PKTIZ7+5 add CAIGE WNDSPC,0 MOVEI WNDSPC,0 To make a DDT patch replace the SUB WNDSPC,T2 with a call to the patch space and do the non-negativity check there, as in: PKTIZ7+5/ SUB WNDSPC,T2 CALL FFF FFF/ SUB WNDSPC,T2 FFF+1/ CAIGE WNDSPC,0 FFF+2/ MOVEI WNDSPC,0 FFF+3/ RET In the week or so that this fix has been installed at SUMEX-AIM, we have had no crashes, and a little counter in our version of it indicates that we have avoided 10 or so occurrences of the negative window space. Andy ------- 8-Dec-86 15:35:33-PST,1874;000000000001 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Mon 8 Dec 86 15:33:41-PST Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA10161; Mon, 8 Dec 86 16:41:52 EST Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.11) id AA03034; Mon, 8 Dec 86 22:05:32 +0100 (MET) Received: from majestix.ida.liu.se by liuida.UUCP; Mon, 8 Dec 86 20:38:35 +0100 Received: from LISBET by majestix.ida.liu.se; Mon, 8 Dec 86 20:38:26 +0100 Received: from FREJA (not validated) by LISBET; Mon 8 Dec 86 20:37:58 Received: from ATHENA (not validated) by FREJA; Mon 8 Dec 86 20:36:47 Date: Mon 8 Dec 86 19:53:41 From: Bj|rn Victor Subject: DISCARD (TAPE INFORMATION) To: TOPS-20@score.stanford.edu Cc: Victor%AIDA%ATHENA%FREJA%LISBET@majestix.ida.liu.se Message-Id: <861208195341.16.VICTOR@AIDA> The .ARDIS function of ARCF% has funny ideas about who is allowed to discard tape information of files. You have to be WHOPR to discard the info for just one tape run, but anybody can discard both runs without even read access to the file. Silly thing, so I patched it. Since we don't have sources, it's in MIC format (suppose you just did @get system:monitr.exe): ;;; Patch for the .ARDIS function of ARCF% ;;; Anybody could do DISCARD (TAPE INFORMATION) for any file. ;;; A more reasonable thing is to check Owner access first. @ddt ;First write a routine that checks for Owner access =fff/$ckown:move t1,p3^j =hrlzi t2,(dc%cn)^j =call dirchk^j =trna^j =jrst rskp^j =movei t1,whelx1^j =ret^j *fff: ;Old contents: JUMPE Q1,CLRBOT =ardis+6/jumpe q1,fff^i =call $ckown^j =ret^j =jrst clrbot^j *fff: *^z ------- 8-Dec-86 16:48:15-PST,1892;000000000001 Return-Path: <@SUMEX-AIM.ARPA,@MIT-MULTICS.ARPA:Bjorn_Carlsson_QZ@QZCOM.MAILNET> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Dec 86 16:45:44-PST Received: from MIT-MULTICS.ARPA by SUMEX-AIM.ARPA with TCP; Mon 8 Dec 86 16:38:41-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2711924693731374@MIT-MULTICS.ARPA>; 08 Dec 1986 19:24:53 est Message-ID: <221943@QZCOM> Date: 09 Dec 86 00:18 +0100 From: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Bjorn_Carlsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SCORE.STANFORD.EDU Subject: [rende: RELRNG BUGHLTs when doing CRLNM JSYS. SYMPTOM: RELRNG BUGHLTs when doing CRLNM with TCP:;FOREIGN-HOST:192.9.200.37 (This will cause BUGHLTs on non-TCP/IP systems too). DIAGNOSIS: RELATR misinterprets contents of offset LNATR when releasing the attribute blocks after a failed parse. RELATR does a SKIPN T2,LNATR(T1) to check if there are any blocks to release, but this will not always work, since it is possible that the left half of LNATR sometimes contains an attribute code from a failed attempt to parse the argument to the attribute. (In this case the dots will have to be quoted with ^V, otherwise the IP address will be assumed to be a filename, extension and generation number, and the parse will fail when we find ".37" with the code for "FOREIGN-HOST" in the left half of LNATR and no attribute blocks created). CURE: Teach RELATR to check the right half of LNATR before trying to release the attribute block(s). This patch seems to fix the problem: LOGNAM$: RELATR+3/ JRST FFF FFF/ HRRZ T1,T2 FFF+1/ JUMPN T1,RELAT1 FFF+2/ RET FFF+3/ FFF: 8-Dec-86 20:35:37-PST,804;000000000001 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Dec 86 20:33:32-PST Date: Mon 8 Dec 86 20:33:17-PST From: Bruce Tanner Subject: Involuntary Archival To: TOPS-20@SU-SCORE.ARPA Message-ID: <12261311061.49.CERRITOS@USC-ECL.ARPA> Has anyone tried using the SAVE/COLLECT command in DUMPER? It looks like it does an archive of files based on their online expiration dates, which is what I'd like to do. My problem is that it seems to have some weird bugs, like archiving expired files when the directory archive-online-expired- files flag is OFF and only doing an archive request when it should be saving the file. If I'm the only one who has ever tried this, I'll SPR it with the fixes I've made. -Bruce ------- 11-Dec-86 14:08:34-PST,1962;000000000000 Return-Path: <@SUMEX-AIM.ARPA:LYNN@PANDA> Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Dec 86 14:06:45-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Thu 11 Dec 86 13:55:45-PST Date: Thu 11 Dec 86 13:51:22-PST From: Mark Crispin Subject: VT100 dip switch question Sender: LYNN%PANDA@SUMEX-AIM.Stanford.EDU To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12262024328.8.LYNN@PANDA> Does anyone have a VT100 technical (as opposed to operator's) manual that can answer this question? I recently got ahold of a pair of katakana (one of the Japanese alphabets) character set ROM's and installed them in my VT125. One ROM went on the motherboard, the other on the AVO. Testing confirms that the katakana character sets are on the Alternate Standard and Alternate Graphics character sets. On a real katakana VT100, the NO SCROLL key becomes a CTRL/N CTRL/O mode switch (instead of its present CTRL/S CTRL/Q switch) and is called the "kana" key. Also, it appears that the Alternate Standard character set is always set up as the G1 character set. On my VT100, NO SCROLL is still a XON/XOFF switch, and I have to run a program to send ESC ) 1 to set G1 to the Alternate Standard (katakana) character set. It powers up or resets to have G1 as the USASCII character set. None of the SETUP options seem to govern this behavior. There are some DIP switches on the AVO which might. However, none of them are documented! Does anyone have such documentation or at least know how to change the G1 character set and the behavior of NO SCROLL? -- Mark -- PS: I asked my friends in Japan, but their katakana VT100's have the older style of AVO using jumpers instead of dip switches and it wasn't practical to try to figure out a correspondence. ------- 12-Dec-86 22:46:10-PST,2191;000000000000 Return-Path: Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Fri 12 Dec 86 22:43:45-PST Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA04051; Sat, 13 Dec 86 01:44:35 EST Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.11) id AA11894; Sat, 13 Dec 86 05:41:35 +0100 (MET) Received: from majestix.ida.liu.se by liuida.UUCP; Sat, 13 Dec 86 02:23:51 +0100 Received: from LISBET by majestix.ida.liu.se; Sat, 13 Dec 86 02:23:35 +0100 Received: from FREJA (not validated) by LISBET; Sat 13 Dec 86 00:03:30 Received: from ATHENA (not validated) by FREJA; Sat 13 Dec 86 00:01:49 Received: from CARMEN by AIDA with Cafard; Sat 13 Dec 86 00:02:59 Date: Fri 12 Dec 86 23:43:07 From: Bjorn Victor Subject: ADBRK% and BUGHLT NOSKTR To: TOPS-20@score.stanford.edu Cc: Victor%CARMEN%ATHENA%FREJA%LISBET@majestix.ida.liu.se Message-Id: <861212234307.14.VICTOR@CARMEN> ADBRK never checks its fork handle argument, and if you give it a bogus one (I haven't tried other than 0), the system crashes with a NOSKTR BUGHLT. In the following patch, I used the RFHJFK routine to check the argument; I'm not at all certain this is the best routine to ask, or even The Right Way to avoid NOSKTRs, but it's a bit hard figuring out how to do it better with only MDDT (no sources). Any hints on a better/more correct way are appreciated. DDT patch: ;;; Patch for ADBRK%, which never checks its fork handle argument. ;;; This crashes the machine very easily, e.g. by executing ADBRK% with ac1/0 ;;; ;;; This patch checks the fork handle argument for a valid, single, relative ;;; fork handle which should be in use. Probably easier, better etc to do in ;;; source, but since we don't have it... @ddt =.adbrk+7/^[^[ =fff/adjsp p,-1^j =jrst itrap1^j *fff: *^z ------- 15-Dec-86 16:41:33-PST,1692;000000000000 Mail-From: BILLW created at 15-Dec-86 16:40:40 Return-Path: Date: Fri 12 Dec 86 23:43:07 From: Bjorn Victor Subject: ADBRK% and BUGHLT NOSKTR To: TOPS-20@score.stanford.edu Cc: Victor%CARMEN%ATHENA%FREJA%LISBET@majestix.ida.liu.se Message-Id: <861212234307.14.VICTOR@CARMEN> ReSent-To: tops-20@SU-SCORE.ARPA ReSent-From: BILLW at SU-SCORE.ARPA (connected to PS:<6-EXEC>) ReSent-Date: 15 Dec 1986 ADBRK never checks its fork handle argument, and if you give it a bogus one (I haven't tried other than 0), the system crashes with a NOSKTR BUGHLT. In the following patch, I used the RFHJFK routine to check the argument; I'm not at all certain this is the best routine to ask, or even The Right Way to avoid NOSKTRs, but it's a bit hard figuring out how to do it better with only MDDT (no sources). Any hints on a better/more correct way are appreciated. DDT patch: ;;; Patch for ADBRK%, which never checks its fork handle argument. ;;; This crashes the machine very easily, e.g. by executing ADBRK% with ac1/0 ;;; ;;; This patch checks the fork handle argument for a valid, single, relative ;;; fork handle which should be in use. Probably easier, better etc to do in ;;; source, but since we don't have it... @ddt =.adbrk+7/^[^[ =fff/adjsp p,-1^j =jrst itrap1^j *fff: *^z -------