2-Jan-84 12:01:34-PST,397;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jan 84 12:01:27-PST Date: Mon 2 Jan 84 13:01:37-MST From: Randy Frank Subject: Edit A to RSX20F To: tops20@SU-SCORE.ARPA Does anyone have a copy of Edit A (break through write) to RSX20F on-line, or a pointer to the Dispatch where it appeared. Thanks. Randy ------- 2-Jan-84 14:29:49-PST,553;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jan 84 14:29:35-PST Date: 2 Jan 84 17:30:25 EST From: Rob Liebschutz Subject: Re: Edit A to RSX20F To: FRANK@UTAH-20.ARPA, tops20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of 2 Jan 84 15:01:37 EST Rutgers:: ps:rsxpatch.vb14-45g is an RSX cmd file to install Edit A to RSX20F. This file is publicly protected and is available through anonymous FTP login. Rob ------- 2-Jan-84 23:25:56-PST,3500;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jan 84 23:25:53-PST Date: Mon 2 Jan 84 23:25:49-PST From: Kirk Lougheed Subject: new Ethernet software To: su-tops-20@SU-SCORE.ARPA This message describes the recent changes to the Stanford TOPS-20 Ethernet software. The source files are on PS:<5-3-MONITOR> on Sierra. The majority of the changes are transparent to the operation of the networks. Most are related to adding 10MB support, better utilization of the Multinet data structures, and cleaning up the interfaces between modules. As it now stands the PUP and Internet protocols are much more interdependent. Internet relies on the subnet routing tables supplied by PUP and PUP makes extensive use of NCT's to make interface dependent decisions. A non-Stanford site without PUP should be able to use the Internet code successfully, however until we change our subnet routing mechanism, PUP is an integral part of our Internet support. The software assumes that the MEIS hardware is capable of handling the 32-bit header mode and reading IP datagrams. The only site that does not meet those criteria is LOTS-A. We expect to have that system upgraded within the next week. The systems at full MEIS revision levels (Sierra, LOTS-B) can enable full MEIS data mode support by setting the MEIMDF cell in PUP.MAC to -1 and by setting EVENCF switch in EVENCF.MAC to 0. We expect to upgrade all systems in the not too distant future, but for now the main thrust of the Ethernet development effort is going to be the 10MB hardware. The SITE-ADDRESS file now has three Ethernet related keywords. ETHERNET means the specified interface is a 10MB MEIS; ETHER3MB (replacing ETHER) indicates the interface is a 3MB MEIS; and HARDWARE takes a 6 octet hardware address for the 10MB MEIS. Everyone installing the new network code will have to change the ETHER keyword to ETHER3MB. Instead of running the ETHER program at startup to initialize the MEIS(s) and to set the system clock, a program called SYSTEM:TIME is invoked to set the clock after the Multinet code has set up the networks. The source to TIME is PS:TIME.MAC and is essentially ETHER less the hardware initialization code. TIME could very well be rewritten to take advantage of an Internet time server. To get TIME to work properly, it was necessary to call the Multinet initialization code and to start the PUP, Internet, and ARP background processes very early, just before SETSPD. TIME is run after SETSPD and just before the TAD is asked for. A further change is that the Multinet code is turned on even if the system is standalone or if IP debugging is in effect. You might notice a longish delay between the BOOT message saying the swappable monitor is loaded and the output of the TIME program. Most of the monitor's time is being spent reading in the host table! To implement the Address Resolution Protocol (ARP) as specified in RFC826, another monitor background fork was added. The module is ARP.MAC and talks only with the ENET module. The ARP fork presently does nothing; in fact, parts of it still need to be written. There is a new SYSDPY to go along with this monitor. It will not work very well to run an old SYSDPY under the new monitor; it will not work at all to run a new SYSDPY under an old monitor. The sources to SYSDPY are on PS:. ------- 3-Jan-84 01:24:09-PST,1117;000000000000 Mail-From: MRC created at 3-Jan-84 01:24:02 Date: Tue 3 Jan 84 01:24:01-PST From: Mark Crispin Subject: DEC TCP JFN interface bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: Incorrect test for valid loal port when using the DEC TCP JFN interface. User's given port numbers are not validated at all; in particular, it allows unprivileged users to open ports less than 0.255 or greater than 128.0 (the latter are ports generated by default). Unprivileged users should only be allowed to open local ports between those two values. Diagnosis: Bad coding in test in HSTPR4; the test is a no-op! Solution: At HSTPR5-11 or so, replace: CAIL T2,100000 ;Special high port number? CAILE T2,377 ;special low port number? JRST HSTPR5 ;no and no so no checks with: CAIGE T2,100000 ;Special high port number? CAIG T2,377 ;No, special low port number? CAIA ;Yes to either, must check JRST HSTPR5 ;No to both, allow ------- 3-Jan-84 05:09:37-PST,1309;000000000000 Mail-From: MRC created at 3-Jan-84 05:09:31 Date: Tue 3 Jan 84 05:09:31-PST From: Mark Crispin Subject: new mailsystem release To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is to announce a new release of the TOPS-20 mailsystem. The most significant change is that the mailsystem now uses the DEC TCP interface (the TCP: device) instead of the BBN interface. The TCPIO package is no longer used. Major changes have been made to MMAILR, with changes of varying degrees to other modules. SMTPSV has not been changed as yet. This is because I expect to announce a new version of NETSRV shortly which will use the DEC TCP interface and supercede INTSRV. Sites which do not have the latest DEC release of TCP/IP and do not have the critical bugfixes documented in earlier messages (in particular, the TELNET announcement) should not run this release. The BBN TCP version of the mailsystem can be found on MRC:; this is the last version that ran with BBN TCP. I am not planning on any further development or maintenance on the BBN TCP version, although it (and the Tenex version) will remain online for the nonce. ------- 3-Jan-84 21:44:17-PST,1004;000000000000 Mail-From: MRC created at 3-Jan-84 21:44:09 Date: Tue 3 Jan 84 21:44:09-PST From: Mark Crispin Subject: bogus TOS and DF set in IP header To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: BBN NOC complaining about us sending messages with bogus type-of-service and dont-fragment bits set in the IP header. Diagnosis: DEC JFN OPENF% code (TCPOPN) is not allocating enough words for the OPEN% JSYS call. The last word contains these parameters, and is being set from randomness. Solution: Allocate enough words. Zero the IP parameters word. At TCPOPN+1, replace: STKVAR <>,OPNJCN,TCPOER> with: STKVAR <,OPNJCN,TCPOER> At TCPOP1+20 or thereabouts, insert: SETZM .TCPIP+TCPBCB ;no IP parameters, please immediately after: SETZM .TCPOP+TCPBCB ;clear the reserved word out ------- 4-Jan-84 00:17:53-PST,660;000000000000 Mail-From: MRC created at 4-Jan-84 00:17:44 Date: Wed 4 Jan 84 00:17:44-PST From: Mark Crispin Subject: more bogus IP options To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In addition to fixing the TCPOPN bugs with setting bogus IP options, you also have to fix it in the I/O code. Specifically, in TCPTCP.MAC you need to replace all occurances of <.TCPBO-.TCPBF+1> with .TCPBS, and in all places where SETZM .TCPBO(T1) is done you need to add SETZM .TCPBI(T1) as well. I hope DEC is getting these changes. ------- 4-Jan-84 18:49:32-PST,884;000000000000 Mail-From: MRC created at 4-Jan-84 18:49:23 Date: Wed 4 Jan 84 18:49:23-PST From: Mark Crispin Subject: Bogus IP options bugs To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The message which stated that <.TCPBO-.TCPBF+1> needs to be replaced with .TCPBS and that you need to insert SETZM .TCPBI(T1) after all SETZM .TCPBO(T1) instructions should have stated that the module to change is TCPJFN.MAC and not TCPTCP.MAC. All of Stanford's TCP modules are on MRC:. If you want to use them on your system, you will need to set STANSW to 1 and PUPSW to 0; possibly you may need to delete some code dealing with Stanford's Ethernet service in MNETDV. But at least it will be a start in getting a working 5.3 TCP... ------- 5-Jan-84 01:24:44-PST,1518;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Jan 84 01:24:37-PST Date: Thu 5 Jan 84 01:24:34-PST From: Kirk Lougheed Subject: Pipes for TOPS-20 To: tops-20@SU-SCORE.ARPA I have written an implementation of the pipe pseudo-device for TOPS-20. It is a JFN interface device (GTJFN%, OPENF%, SIN%, SOUT%, etc.) modeled after the UNIX pipe mechanism. The changes to the TOPS-20 monitor are quite minimal; you could add this device without monitor sources beyond STG.MAC and PROLOG.UNV. The code is also relatively compact; it takes up about one page of monitor virtual address space. So far I have only one serious program that uses pipes. It is a multi-process Galaxy spooler that at present handles three Imagen laser printers. Pipes are used by each of three main processes to communicate with their formatting process (MAKIMP) and their downloading process (IS). This program has been in constant operation since mid-November. The source code and documentation are publicly available on Sierra in the directory as PIPE.MAC, PIPE.MSS, and PIPE.DOC. The documentation describes the JSYS interface in detail, suggests a few ways in which pipes might be used, and presents a number of detailed program fragments. I would be glad to offer assistance to anyone installing or using this code. I would be delighted if someone is inspired to port a UNIX shell to the DEC-20. Kirk ------- 5-Jan-84 09:58:11-PST,434;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Jan 84 09:57:58-PST Date: Thu 5 Jan 84 09:57:50-PST From: Kirk Lougheed Subject: Overly protected files To: tops-20@SU-SCORE.ARPA The ANONYMOUS directory on Sierra was protected so as to render its files invisible. The pipe source and documentation files should now be visible. Kirk ------- 6-Jan-84 07:45:40-PST,402;000000000000 Mail-From: MRC created at 6-Jan-84 06:50:51 Date: Fri 6 Jan 84 06:50:51-PST From: Mark Crispin Subject: TCP: JFN BUG To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) At TCPCLW+3, there is a bogus HRRI T1,INTZOT before the MKWAIT INTZOT. It should be flushed. ------- 6-Jan-84 08:15:32-PST,975;000000000000 Mail-From: MRC created at 6-Jan-84 08:15:30 Date: Fri 6 Jan 84 08:15:30-PST From: Mark Crispin Subject: NETSRV To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Last night I did further debugging on the TCP: device ATNVT% JSYS and completed the Internet NETSRV. I am now ALPHA testing it on Score. This is not a hacked up version of INTSRV (which was ISI's hacks of an old version of NETSRV) but rather a conversion of my last NCP NETSRV. Consequently it has many of my later NETSRV improvements, such as a reliable Finger server. Please do not try to run NETSRV on your systems yet. Once I am satisfied with the Alpha-test on Score I will ask Kirk to Beta-test it on Sierra. I expect to be doing quite a bit of follow-up work on NETSRV in the next few days, so you're best off waiting until it is stable. ------- 6-Jan-84 12:09:59-PST,3403;000000000000 Mail-From: MRC created at 6-Jan-84 12:09:47 Date: Fri 6 Jan 84 12:09:47-PST From: Mark Crispin Subject: whither 36 bits? To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It's that time of year, time to start thinking about Spring DECUS. Spring DECUS is going to be depressing, to say the least. Because DECUS management is a bunch of losers, there'll be no DEXPO in Cincinnati (sp?) or in Anaheim. We're going to hear the same tired promises from DEC about how wonderful the future is going to be; about the legendary release 6 (which I doubt will ever see customer ship), about the CI, the NI, etc. etc. We'll have cute tricks like Las Vegas DECUS where Ms. R- G- asked us to hold our brickbats until Wednesday...after she can hop on a plane back to Massachusetts so she can report she heard "few complaints" about DEC's "integration" strategy. We'll be told how wonderful the already-obsolete VAX architecture is, and what a joy VAX/VMS is to use. Oh? You like multi-processes? Well, you can learn Unix, an operating system with no user interface, whose sole redeeming feature seems to be that it requires absolutely no competance to become a Unix system programmer, thus satisfying the driving ambitions of a great number of untalented individuals. This isn't to say that there aren't talented, competant Unix system programmers; there are many. But there are many of the other sort. Oh, so you don't want Unix? Well, in 5 years VAX/VMS will be almost as good as TOPS-20 is... In the last few months I've talked to several commercial DEC-20 shops. In each of them, the story is the same; they liked the -20 but the cost of ownership is killing them. They need more computing power and after the Jupiter/36 bit cancellation fiasco their management is going to be damned if they ever buy another DEC product. Wanna make some good money? There's a lot of openings for people who can convert databases from the various -20 systems to IBM. If IBM came out with a 36 bit engine they'd make a killing in our market. What can we do? Tell DEC they've lost our market? They don't care; they want to lose us as customers. We demand quality software. Quality software costs a lot of money to develop. DEC would much rather fob off the dreck they've dumped on their -11 and VAX customers for years. That way they can continue to hire inexperienced kids at low salaries instead of having to pay for good people. Who can we go to? IBM? It's a big migration step, even if anything ever comes out of IBM TOPS-20. Foonly? Anybody who's ever dealt with Foonly will dismiss them? Tymshare? They have yet to state a credible commitment, or any commitment to build the engines we really want to buy: . very large 36 bit super-computer . workstation 36 bit computer (at under $10K) Systems Concepts? The Japanese? No announcements from either as yet... Getting even? There isn't much we can do, unless we wanted to go into the 36-bit manufacturing business. It looks like the trade press is doing it for us; DEC continues to take a beating for cancelling 36 bits. The only thing I could think of that would be worse for DEC is if Data General announced a DG-20... ------- 6-Jan-84 18:15:23-PST,998;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Jan 84 18:15:20-PST Date: 6 Jan 1984 18:15 PST (Fri) Message-ID: From: David Eppstein To: SU-TOPS-20@Score Subject: New Pup FTP server There is a new version of the Pup FTP server running on Sierra (source in [Sierra]SRA:PUPFSV.MAC). This fixes a bad security hole: any user (including ANONYMOUS) could CONNECT to the directory of a wheeled account (but not to non-privileged directories) without a password or with a bad password. There have been quite a few other changes and I only just put it up on Sierra, so normally I would not announce it this soon. However I felt the above bug was serious enough to require immediate action. It has been tested with all the combinations of PUPFTP commands I could think of, and is able to receive mail, so if there are any bugs left then with luck they are all minor. 6-Jan-84 19:25:17-PST,552;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Jan 84 19:25:15-PST Date: Fri 6 Jan 84 19:25:10-PST From: David Eppstein Subject: more PUPFSV To: SU-TOPS-20@SU-SCORE.ARPA well there was a bug - some EOCs would cause the server to hang. this was causing pup mail to get delivered but then the mailer would not see the final eoc and think the mail had been lost. fixed now. make sure you have SRA:PUPFSV.EXE.230 not 229 or SYSTEM:PUPFSV.EXE.82 not 81. ------- 6-Jan-84 19:41:24-PST,795;000000000000 Mail-From: MRC created at 6-Jan-84 19:41:17 Date: Fri 6 Jan 84 19:41:17-PST From: Mark Crispin Subject: fix for hanging CZ%ABT CLOSF% on TCP: device To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: CZ%ABT CLOSF% on TCP: device hanging in INTZOT scheduler test. This hung the mailer's network fork. Diagnosis: TCPCLZ routine in TCPJFN.MAC monitor module tests for close wait (and consequently the need to do an INTZOT block) before the test for CZ%ABT. Solution: Move the test. At TCPCLZ+4L, delete JN TCDCW,(TCB),TCPCLW ;if in close wait get to it and re-insert it 7 lines below, right before the CLOSE% call. ------- 8-Jan-84 01:00:41-PST,472;000000000000 Mail-From: MRC created at 8-Jan-84 01:00:39 Date: Sun 8 Jan 84 01:00:39-PST From: Mark Crispin Subject: new FINGER To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Score's Finger program now uses the DEC TCP: interface. Some other cleanups were made in its network Finger code. The new version is on MRC: at Score. ------- 8-Jan-84 18:36:00-PST,1341;000000000001 Return-Path: Received: from JPL-VAX.ARPA by SU-SCORE.ARPA with TCP; Sun 8 Jan 84 18:35:45-PST Date: 8 Jan 1984 1831 PST From: Eric P. Scott Subject: Spreading the gospel To: TOPS-20@SU-SCORE Cc: TCP-IP@SRI-NIC,Info-VAX@SRI-KL Reply-To: EPS@JPL-VAX To them, TCP/IP is an "alternative network technology," "internet software" means IBM protocol emulator, X.25 is THE way to achieve multi-vendor compatibility, and understanding of networking internals is a black art. We who (of course) know better once again have the opportunity to liberate misguided little minds from such nonsense. Yes kids, I refer to none other than the 1984 Spring DECUS U.S. Symposium! Being the good (hah!) volunteer that I am, I'll request a VAX/VMS ARPANET/DDN Users session, try to schedule it early in the week, and not against the TOPS-20 session. I need additional speakers, so let me know before the deadline if you're willing. What I really want to see this time is some other sessions for the benefit of those who don't know what TCP/IP is all about. The deadline for abstracts is January 20, so let's try to develop a workable plan of attack reasonably soon so we can submit several together with appropriate scheduling constraints. Am I talking conspiracy here? You bet. -=EPS=- ------ 8-Jan-84 23:50:10-PST,2230;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 8 Jan 84 23:50:00-PST Date: Sun 8 Jan 84 23:49:55-PST From: Kirk Lougheed Subject: Yet another TCP: bug To: tops-20@SU-SCORE.ARPA The sequential input code for the TCP: device suffers at least three problems when a connection is closing. It does not set the EOF flag in the JFN status word; it (usually) forgets to give the user the last buffer of data; and it manages to drop a piece of storage on the floor. The following patch remedies those problems. My embryonic TCPFTP is working much better now, however I would not be surprised if yet more problems with the TCP: device were to emerge. Kirk ---------- ;;; The first part of the patch is to exit if the EOF JFN flag is set. TCSQI0: ;here to see if input is possible IFN STANSW,< TQNN ;time to exit if EOF flag is now set >;IFN STANSW CALL TCPSIO ;set things up (like TCB) RET ;pass down any problems or errors ;;;; The second part of the patch is after getting an error from the RECV%. ;;;; If the error is "connection closing", then we assume that EOF is near. ;;;; We flush the buffer we cannot use, then if the emptying buffer is empty ;;;; we try replacing it with the active buffer. If there is no longer an ;;;; active buffer, we set EOFF to flag the higher levels that they should ;;;; exit to the device independent code. TCGIBR: ;here on an error from the RECV% CALL ERTRAN ;translate the error IFN STANSW,< MOVEM T1,LSTERR ;save that error code MOVE T1,TCGIBB ;get address of the buffer we can't use CALL TCPRLB ;release it MOVE T1,LSTERR ;get back the error code CAIE T1,TCPX33 ;connection closing? IFSKP. SKIPE TJIBE(TCB) ;yes. skip if no emptying buffer RETSKP ;must be trying to fill active buffer SKIPN T2,TJIBA(TCB) ;get pointer to active buffer TQO ;nothing there, set the EOF flag MOVEM T2,TJIBE(TCB) ;make it the emptying buffer SETZM TJIBA(TCB) ;no more active buffer RETSKP ;return success always ENDIF. >;IFN STANSW SETONE ;set the error bit RET ;return to lower levels ------- 9-Jan-84 05:40:09-PST,789;000000000000 Date: Mon 9 Jan 84 05:18:33-PST From: Mark Crispin Subject: getting some more address space Sender: OPERATOR@SU-SCORE.ARPA To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) If the esteemed membership of this list has any members who are really hungry for address space, I should note that even if you turn DECnet off the DECnet free storage pool is still there. This is a rather large area which could be put to better use, I suspect. On the other hand, I'm using it now as a place to store my TCP: JFN buffers. Better than the general pool, considering that we have had some free storage lossage bugs with TCP:... -- Mark -- ------- 9-Jan-84 11:34:59-PST,572;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Jan 84 11:34:54-PST Date: Mon 9 Jan 84 11:39:31-PST From: Andrew Sweer Subject: Re: New Pup FTP server To: Kronj@SU-SIERRA.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "David Eppstein " of Fri 6 Jan 84 18:15:00-PST There is a new version of the Pup FTP server running on Sierra (source in [Sierra]SRA:PUPFSV.MAC). David, What ever happened to the Pup FTP software in PS:? Andy ------- 9-Jan-84 11:42:19-PST,1018;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Jan 84 11:42:10-PST Date: 9 Jan 1984 11:41 PST (Mon) Message-ID: From: David Eppstein To: Andrew Sweer Cc: SU-TOPS-20@SU-SCORE.ARPA Subject: What happened to the program in It's being beaten into a multi-protocol FTP (Pup and TCP - this is the "embryonic TCPFTP" Kirk referred to in a recent message). The Pup user FTP part has been working for a month or so; Kirk has just started working on the TCP part (Frank Fujimoto was working on it before); and I recently decided to try putting up the Pup server based on the same sources (which is what the announcement was about). A working (for Pup) version of the user program can usually be found in NEW:NFTP.EXE on Sierra, if you want to try it. It is still a bit rough around some of the edges though, so I would not put it up in place of FTP or PUPFTP. 9-Jan-84 20:49:19-PST,747;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Jan 84 20:49:12-PST Date: Mon 9 Jan 84 20:49:07-PST From: Kirk Lougheed Subject: Facilities CAD program sought To: tops-20@SU-SCORE.ARPA cc: burke@SU-SIERRA.ARPA I'm looking for pointers to CAD programs for facility or architectual design. The person who wants to use such a program is the EE facilities manager. He has a rather large building coming online for the Stanford Center for Integrated Systems. Any and all pointers would be appreciated. I'm looking some something that will run on any of TOPS-20, TOPS-10, UNIX, VAX/VMS, or one of the micro operating systems. Thanks, Kirk ------- 10-Jan-84 09:49:02-PST,624;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Jan 84 09:48:35-PST Received: ID ; Tue 10 Jan 84 12:49:35-EST Date: Tue 10 Jan 84 12:49:34-EST From: VAF@CMU-CS-C.ARPA Subject: DNLOAD To: TOPS-20@SU-SCORE.ARPA Is the source for DNLOAD available? I need to write a program which loads a secondary front end and then monitors it, reloading if protocol is lost (like NMLT20 does for DECnet). If possible, I'd prfer not to have to rewrite the code to do the downloading or dumping, since it already exists in DNLOAD and NMLT20. --Vince ------- 10-Jan-84 19:53:29-PST,842;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Jan 84 19:53:20-PST Date: 10 Jan 84 22:54:04 EST From: Charles Hedrick Subject: speed of the DTE To: tops-20@SU-SCORE.ARPA I am trying to tune our implementation of PUP. It uses a front end (effectively a DN20, although it uses an 11/60 as the processor), to which a 3MHz ethernet is connected. It is of some interest to know how fast we can expect to go through the DTE. I just timed a transfer at 40Kbaud effective throughput (that is, actual data bits, not including acknowledgements, retransmissions, and other things involved in the protocol). I am curious to know how close we are getting to the limits of the hardware. Does anybody have any data on the actual bandwidth of a DTE? ------- 11-Jan-84 11:13:25-PST,959;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 11 Jan 84 11:13:14-PST Date: 11 Jan 84 14:14:00 EST From: Don Subject: Most inane patch of (well, discovered in) 1984 To: Tops-20@SU-SCORE.ARPA Ever type HEL PROT (for HELP PROTECTION) when PROTECTION is the only help topic which could complete PROT? Well, you can't in the 5.1 EXEC. You *must* type it out or use recognition! The reasoning (straight from EXEC.TCO): Problem: HELP keywords are implicitly completed. Diagnosis: COMND implicitly completes keywords, but HELP keywords are really file names, so this is undesirable. Solution: If keyword was not explicitly completed (check CM%ESC), then if input keyword (in atom buffer) is a substring of complete keyword, then it's an error. This "fix" is easily removed by commenting out the 8 lines before HLPCNF: in EXECIN. Don ------- 12-Jan-84 11:09:56-PST,740;000000000000 Mail-From: ALMQUIST created at 12-Jan-84 11:09:48 Date: Thu 12 Jan 84 11:09:48-PST From: Philip Almquist Subject: Re: Most inane patch of (well, discovered in) 1984 To: WATROUS@RUTGERS.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Don " of Wed 11 Jan 84 14:14:00-PST Don, I guess such things are a matter of taste, since I personally find the change (breaking implicit completion of HELP keywords) to be a reasonable even if not terribly important fix. Ever type "Help macs" to get help on Macsyma and get a cryptic description of a bunch of Macsym macros? I have known users who would be temporarily quite baffled by something like that. Philip ------- 12-Jan-84 11:19:35-PST,808;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Jan 84 11:19:15-PST Date: 12 Jan 84 14:20:10 EST From: Don Subject: Re: Most inane patch of (well, discovered in) 1984 To: ALMQUIST@SU-SCORE.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Philip Almquist " of 12 Jan 84 14:09:48 EST That argument could be used to justify the forced completion of *all* commands. How many people have been burned by typing CON instead of CONN? My main objection (aside from the inconvenience) was the reasoning. You can't use abbreviations on help topics because they're "really" file names. Why should a functionality be (artificially!) limited because of the way it's implemented? Don ------- 12-Jan-84 19:53:37-PST,1228;000000000000 Mail-From: MDP created at 12-Jan-84 19:53:29 Date: Thu 12 Jan 84 19:53:28-PST From: Mike Peeler Subject: Re: Most inane patch of (well, discovered in) 1984 To: ALMQUIST@SU-SCORE.ARPA cc: WATROUS@RUTGERS.ARPA, Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Philip Almquist " of Thu 12 Jan 84 11:10:15-PST Philip, You say you typed "help macs" and got help on Macsym when you really wanted to know about Macsyma. I would not conclude from this that "macs" should not have been allowed. I would be more inclined to say that Macsyma should have been a help topic. Forget that inclination. Let's say your system does not have Macsyma and so there is no reason for such a help topic. All I can say is, everyone I have ever trained to use TOPS-20 would have looked, with ? or ESC, before leaping into the wrong help topic. Just because you want to be protected from yourself, I should be prevented from abbreviating "cobwebs" on the hunch that I might be looking for Cobol? I think if it is a matter of taste, it should be left the way TOPS-20 normally works, since exceptions serve to confuse those who understand the rule. Mike ------- 12-Jan-84 21:19:44-PST,690;000000000000 Mail-From: MRC created at 12-Jan-84 21:19:39 Date: Thu 12 Jan 84 21:19:39-PST From: Mark Crispin Subject: bug in TCP: ATNVT% To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In the TVTJFN code, there is a routine to handle the failure to handle a failure to attach a TCB to a TVT. It ends (at TVTJFN+63 in DDT) with a RETBAD (). This is a bogon; it should be RETERR (). The MDDT patch is to change the RET at TVTJFN+63 to JRST MRETNE. The absence of this patch is likely to cause an ILMNRF bughlt as the monitor jumps into randomness! ------- 12-Jan-84 22:21:34-PST,1056;000000000000 Mail-From: MRC created at 12-Jan-84 22:21:25 Date: Thu 12 Jan 84 22:21:25-PST From: Mark Crispin Subject: ATNVT% for TCP: device To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) We have implemented the ATNVT% JSYS for the TCP: device. The necessary support for ATNVT is in MRC: in files TCPJFN.MAC and MNETDV.MAC. You will also need to add TVTJFN and TATTVT as globals in GLOBS.MAC. I have upgraded the NETSRV program to use the TCP: device. This version of NETSRV is based on my last NCP version of NETSRV; as such it has several bugfixes that never made it into the INTSRV program. If your monitor has Stanford's ATNVT% support, then you can run the new NETSRV (on MRC:). As of this writing, Score is running (in production) TCP: JFN versions of TELNET, the mailsystem, Finger, and NETSRV. Work is in progress on a TCP: version of FTP user and server. ------- 13-Jan-84 08:50:45-PST,949;000000000000 Mail-From: MRC created at 13-Jan-84 08:50:33 Date: Fri 13 Jan 84 08:50:33-PST From: Mark Crispin Subject: more TCP/IP improvements To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have just fixed TCP: opens so that the status of the host (as returned by 1822 and/or a gateway) is now respected. This fixes the silly behavior of TELNET'ing to a host which is obviously down and having to wait for the transmission timeout. Now, if the network provides the service of informing the originating host that the destination is down, OPENF% will respect it. The relevant changes are in TCPJFN and IPIPIP, although they depend upon all the other changes put into TCP here at Stanford. Besides being nice for users using TELNET, this change should also improve mailsystem performance. ------- 13-Jan-84 10:54:29-PST,891;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Jan 84 10:54:19-PST Date: Fri 13 Jan 84 11:53:16-MST From: Walt Subject: Re: speed of the DTE To: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Tue 10 Jan 84 22:54:04-MST I once got ours up to 149 kbaud by increasing the buffer size in FESRV. This was accomplished by sending 1524 byte messages through an FESRV with a buffer large enough to hold the whole thing. The DTE20 was running RSX20F protocol. The speed improvement was a result of the fact that with the larger buffer, it is not necessary to wait for a 20ms scheduler cycle to send the next 254-byte string data message across the DTE20. We have since dropped the buffer size back to normal because of storage limitations. Cheers -- Walt ------- 14-Jan-84 15:24:11-PST,709;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Jan 84 15:23:59-PST Date: Sat 14 Jan 84 15:23:53-PST From: Kirk Lougheed Subject: bug in TCPTCP.MAC To: tops-20@SU-SCORE.ARPA In TCPTCP.MAC at PKTZ16+10 the wrong AC is being compared. The resulting problem of TCB's hung in a NOT.FIN state manifested itself while we were having problems with our SU-Net gateway host shutting down in the middle of connections. LOAD T2,TSSYN,(TCB) ; Get send state IFE STANSW,< CAIE T3,FINSNT ; Sending a FIN now? >;IFE STANSW IFN STANSW,< CAIE T2,FINSNT ; Sending a FIN now? >;IFN STANSW JRST PKTZ17 ; No ------- 16-Jan-84 16:39:17-PST,384;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 16 Jan 84 16:39:04-PST Received: ID ; Mon 16 Jan 84 19:39:50-EST Date: Mon 16 Jan 84 19:39:49-EST From: ERC@CMU-CS-C.ARPA Subject: TFTP To: tops-20@SU-SCORE.ARPA Do any of you know of or have a TFTP program/server for Tops-20? - Thanks Eric Crane ------- 16-Jan-84 19:42:28-PST,1888;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 16 Jan 84 19:42:12-PST Date: 16 Jan 84 22:42:17 EST From: Charles Hedrick Subject: FINGER To: tops-20@SU-SCORE.ARPA For those of you that use MIT-derived versions of FINGER, I now have it working over TCP and PUP. I have repeat 0'ed a lot of the old network support, including the ability to say FINGER FOO@MIT and have it look at all MIT machines. But the normal uses work. It tries PUP first, then TCP. The code required is s:finger.fai, s: fngsrv.mac, and the code after the label FNGSRV: in s:pupsrv.mac. The latter requires help from us to get, as we can only give code involving PUP to sites licensed by Xerox. The TCP support requires that TCPJFN be working. This means having the fix for duplex JFN's, and the various TCPJFN patches broadcast by MRC. (We simply use his version of TCPJFN.MAC.) During debugging of this code we ran into various strange hangs and even a couple of crashes. This version uses a simpler approach than those, and seems to work reliably. Note that you cannot simply CRJOB FINGER.EXE onto a TVT, because of the negotiation problem. When FINGER finishes, it will log out or detach. At that point, the TVT code will ask the other end to send back a timing mark. Most FINGER user processes will not understand, and will hang. The PUP code requires BSP support in the monitor. (The traditional PUP implementation has this, but at least one site has removed it to save [a very small amount of] monitor address space.) Although our monitor supports duplex JFN's for PUP [code kindly donated by MRC], our PUPSRV has not yet been updated to use them, so we use separate JFN's for input and output. FINGER.FAI is structured to be able to work either way. ------- 16-Jan-84 23:30:09-PST,2699;000000000000 Mail-From: MRC created at 16-Jan-84 23:29:55 Date: Mon 16 Jan 84 23:29:54-PST From: Mark Crispin Subject: Re: FINGER To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Mon 16 Jan 84 22:42:17-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In response to Chuck's message about the Rutgers version of the MIT-derived Finger, I should mention that the Stanford Finger program also works over both TCP and Pup, and is available in the MRC: directory at SU-SCORE. Score supports ANONYMOUS FTP logins. Like RUTGERS', this version of Finger requires that TCPJFN, the DEC TCP: JFN interface to TCP/IP, be working (which is defined as "having Stanford's bugfixes to the latest DEC release" and not "the latest DEC release"). As there is no official Pup Finger protocol, our Finger program prefers TCP over Pup. Stanford Finger is superior to MIT-based Finger in that our Finger does not require a Cerberus daemon. Last logout date/time is recorded by a logout hook in a cooperating ACJ. Stanford Finger's code is also somewhat cleaner. MIT Finger does have the INQUIR/WHOIS functionality, so these trade-offs must be made by a site deciding which Finger program to run. I was never made aware of any Xerox licensing requirement that prevents us from distributing code involving Pup to sites which are not licensed by Xerox. Telnet, the mailsystem, and Finger all support Pup, but do not have a single line of Xerox code in it. They simply use the PUP: device, which support has been extensively modified at Stanford. I would imagine such licensing requirements would be illegal, and I can't imagine Stanford's lawyers agreeing to them. There is another reason why you cannot CRJOB% FINGER.EXE onto a TVT, more important than the negotiation problem. As the Internet Finger protocol does not have any required greeting by the Finger service prior to sending the command line to the Finger server, there is a timing race between the creation of a TVT and the attaching of a job running FINGER.EXE (you cannot CRJOB% directly onto a TVT in any case; you must CRJOB% detached and then ATACH%). During that critical interval, if the Finger command line arrives, it will be discarded and lost (except for the terminating CRLF, which will try to start an EXEC!). The INTSRV-based Finger servier, distributed by ISI, has this bug. The new TCP: JFN interface NETSRV, running at Score for the past week or so, fixes this problem. -- Mark -- ------- 17-Jan-84 05:25:44-PST,1176;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Tue 17 Jan 84 05:25:34-PST Date: Tue 17 Jan 84 06:24:34-MST From: Norm Samuelson Subject: terminal i/o question To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 I have what I hope is a simple dumb question, but I have not yet found a simple solution. I want to be output as a REAL escape character, but on input it must echo as a DOLLAR SIGN. If I use image mode for the output I will loose "pause on end-of-page". If I set the CCOC bits they affect both input and output the same way. I tried getting deferred interrupts on , but the byte pointer and buffer I had given to TEXTI were not updated with other characters already read from the terminal on that line. If there were a way to get TEXTI to NOT echo the break character it might solve my problem, but I remember that as a problem that EMACS developers wanted fixed for years and never got from DEC. Can anyone tell me a simple way to solve this? - Sam - ------- 17-Jan-84 07:32:50-PST,543;000000000000 Return-Path: <@CMU-CS-C.ARPA:ZUBKOFF%TARTAN@CMU-CS-C.ARPA> Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 17 Jan 84 07:32:42-PST Received: from TARTAN by CMU-CS-C with TLnet; 17 Jan 84 10:33:48-EST Received: ID ; Tue 17 Jan 84 10:30:14-EST Date: Tue, 17 Jan 1984 10:30 EST From: Leonard N. Zubkoff To: Tops-20@SU-SCORE.ARPA Subject: Ssave% Does anyone have a fix for the infamous case where a job hangs because someone logs it out while it's Ssave%'ing? 17-Jan-84 10:22:37-PST,1016;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 17 Jan 84 10:22:25-PST Date: 17 Jan 1984 10:21-PST Sender: BILLW@SRI-KL Subject: Re: FINGER From: BILLW@SRI-KL To: MRC@SU-SCORE Cc: HEDRICK@RUTGERS, tops-20@SU-SCORE Message-ID: <[SRI-KL]17-Jan-84 10:21:51.BILLW> In-Reply-To: The message of Mon 16 Jan 84 23:29:54-PST from Mark Crispin I have a finger server that handles one connection at a time, using a file as intermediate between finger and the TCP connection. It seems to hang frequently, but does get around all of the TVT related problems. I also have a (I guess MIT based) FINGER program that uses a modified tcpio for net connections. These may be of use to other slow moving sites that are still running 5.2 (The new finger also has long host number support, requiring a new cerberus, and that the cerberus.pmap file be rebuilt.) BillW PS: The relevant files are SRI-KL:TFING.MAC, TCPIO.SRI, CERBER.FAI 17-Jan-84 11:00:42-PST,603;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Tue 17 Jan 84 11:00:30-PST Date: Tue 17 Jan 84 13:59:55-EST From: Chris Maio Subject: Re: FINGER To: BILLW@SRI-KL.ARPA cc: MRC@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "BILLW@SRI-KL" of Tue 17 Jan 84 13:21:00-EST Last summer I wrote a simple finger server that uses SPJFN% rather than a TVT or temporary file, and it seems to be perfectly reliable. The source is in [COLUMBIA-20]FNGSRV.MAC. - Chris ------- 17-Jan-84 19:45:29-PST,771;000000000000 Mail-From: MRC created at 17-Jan-84 19:45:14 Date: Tue 17 Jan 84 19:45:14-PST From: Mark Crispin Subject: Re: FINGER To: CHRIS@COLUMBIA-20.ARPA cc: BILLW@SRI-KL.ARPA, HEDRICK@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Chris Maio " of Tue 17 Jan 84 11:00:53-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Yes, SPJFN% is the proper way to have a Finger server. That is what my old NCP NETSRV did, and that is what the current NETSRV I have released for the 5.3 TCP does. Needless to say, it is much easier having an SPJFN% Finger server with the TCP: JFN interface than it is with the BBN interface! ------- 18-Jan-84 11:41:53-PST,8115;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jan 84 11:41:22-PST Date: 18 Jan 84 14:38:06 EST From: Charles Hedrick Subject: Management Bulletin 18 To: nic@SRI-NIC.ARPA I would appreciate some clarfication about the most recent Arpanet Management Bulletin. There is, of course, no question about its technical content. It contains a number of very useful rules for password management. Any site that wants to implement reasonable security should certainly follow them. The question is about the implication that policies of the sort recommended there might become mandatory for all Arpanet hosts. I think you should give very careful consideration before adopting restrictions on managerial policies of hosts. The Arpanet contains hosts of widely varying types, and different policies may be appropriate for them. I have attached an appendix in which I attempt to convince you that for some sites, it may make sense not to adopt tight password control. Note that I don't really care whether you believe my arguments or not. It is only necessary for you are agree that it is possible for reasonable managers to adopt strategies involving calculated risk in security areas. In particular, I am not at all certain that I want to adopt the sorts of password management policies that you suggest. In that case, you have several options open to you: - You can say that you know better than I do, and you will not allow any site connected to the Arpanet to be managed in the way that I propose. You could probably even make this stick. You could claim that most of our research is government-supported, and that failure to implement proper security would result in waste of government resources by unauthorized users. - You can say that security is the responsibility of the end host. In that case, your guidelines are applicable only to hosts that care about security. If a host chooses to ignore them, that's their problem. This has been the traditional Arpanet view. - You can adopt a compromise and say that your policies are intended to be mandatory only to the extent needed to protect other hosts from people who may break our security and then use us as a base from which to attack the Arpanet. Thus we might apply careful password control only to people who have access to the Arpanet. (Our privileged users already follow fairly strict policies.) I would appreciate knowing which sort of policy you intend to pursue, since some of them will require us to do some work. In particular, I would like to know as soon as possible whether you are changing the traditional doctrine that security is the responsbility of the destination host, since such a change will significantly increase our responsibility towards the rest of the network. You might consider adopting different approaches for the Arpanet and Milnet. I thought the rationale for the split was that different managerial philosophies were applicable for the two networks. I am concerned that having made the split, policies will now be designed for Milnet, and then as an afterthought applied automatically to the Arpanet because no one can think of any good arguments why they shouldn't be. The rest of this document is a brief justification of why we maintain loose security policies. ------------------- I agree completely that good password management is a must for sites that work on confidential material. The problem is that University research sites have intrinsicallly different needs than military sites, and it may not make sense to apply the same policies. For a site that does not work with confidential data, security is motivated by the following considerations: - we want to prevent malicious users from doing damage to our system or to users' files - we want to avoid unauthorized use of resources [Note that I do not list the fact that we want to avoid being used as a base for attacks on other Arpanet sites. Longstanding Arpanet policy calls for security to be supplied at the host. If you are changing that policy, then you are introducing an important change in my security considerations, and I would like to know it clearly.] If you have confidential information, you are interested in your "technical security". That is, you want to make sure the Russians can't break into your system. It isn't enough that they haven't done so yet. For systems that do not store confidential information, this is not so important. We are free to adopt the more direct criterion that the aim of security is to minimize the number of actual problems caused to users. This is quite different from technical security because it involves the psychology of our user population. This distinction is brought into clear focus by an exchange I had with the management of the CMU Comp Center. We had suggested an agreement with them whereby we would provide backup for each other in case of prolonged failure. They did not agree. One of their objections was that they had done a lot of work on security in the Tops-20 operating system, and they did not want to run at a site that used the standard software. It was clear that they had done all of this work because they had had continuing security problems. So the question is: suppose you have a choice between - a site where lots of holes have been plugged, but where there is a history of continuing damage due to security problems - a site where there have been few security problems, and little work on security It is clear that if you expect your data to be attacked by well-motivated people, you will choose the first site. But if you do not have confidential data, you will probably choose the second, because there is less likelihood that you will actually be bothered by a security problem. From talking with other Universities, we believe that there is a fairly clear correlation between sites that attempt tight security and sites that have problems with security. Of course correlation does not prove causality. But we have good reason for thinking that attempts to provide more security than your user community feels are justified result in less actual security. As I am sure you know, the sorts of operating systems we are dealing with are not completely tight. Furthermore, there is little hope that they will ever be completely tight. Thus there will be holes, no matter what we do. For this reason it is critical for us to maintain good enough relations with our users that they do not attempt to crack the system. In many places, there is a sort of escalating spiral wherein every hole the staff closes leads to yet more sophisticated attacks. I believe it is more important to prevent such an escalation from occuring than to fix any of the specific holes. We have in fact had experience with at least three different security policies here at Rutgers. The degree of damage done to the system has been least under the policy that pays least attention to security. By the way, I have one other security policy that is relevant here. That is, I always try to maintain security monitoring that is one step beyond my security enforcement. That is, suppose I know how to detect a certain set of security violations. I now have two choices: - I can develop ways to prevent all of those violations - I can develop ways to prevent some subset of them, but detect all of them. Which results in the most security? At first glance one might argue that the first does. After all, we have plugged more holes. I claim that the second is better, in that you have a better idea of whether your security is being compromised or not. If you start getting a lot of violations, you can always implement the additional protection. But then you should find a way to expand the set of things that you detect, so that you always detect more violations than you are prepared to prevent. ------- 18-Jan-84 15:17:03-PST,926;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jan 84 15:16:49-PST Date: Wed 18 Jan 84 17:17:39-CST From: Clive Dawson Subject: Front end lines To: tops-20@SU-SCORE.ARPA We would like to add 16 new lines to our front end but have run out of backplane space for DH-11's and also have run out of floor space for an expansion cabinet. We do have a couple of spare slots in the backplane, and so I am considering going with a device made by Emulex called the CS21H. It apparently looks just like a DH11 but takes up only a single slot, uses very little power, and is quite a bit cheaper than the DEC product. The CS21 is in use on quite a few VAX systems around here with good results. Before going ahead, I'd like to make sure that they work on a DEC-20 as well. Does anybody out there have one? Thanks, Clive ------- 18-Jan-84 15:24:59-PST,695;000000000000 Mail-From: ALMQUIST created at 18-Jan-84 15:24:45 Date: Wed 18 Jan 84 15:24:45-PST From: Philip Almquist Subject: Re: Front end lines To: CC.Clive@UTEXAS-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Wed 18 Jan 84 15:17:06-PST Clive, You should talk to the CMU Computation Center people, since I know that they got some DH-11 lookalikes from Emulex. However, it's a long enough walk to Pittsburgh from here that I'm not about to check the model number... My recollection is that the things work ok on 20's except that they confuse the front end diagnostics a little. Philip ------- 18-Jan-84 16:26:38-PST,941;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jan 84 16:26:24-PST Date: Wed 18 Jan 84 16:26:53-PST From: William "Chops" Westfield Subject: echoing $ and outputing escape To: tops-20@SU-SCORE.ARPA Someone recently asked about how to have echo as a $ when typed, but be output as an escape when output by the program. As near as I can tell, setting data mode 3 (.TTATE: Disable the translation of output. "Obeys the CCOC word on input only") should accomplish this. It doesn't, however. I think this is a bug, TTATE is supposed to still do translation on formatting characters only, and I would not consider escape to be a formating character. Beside, the jsys manual specifically notes that this data mode is useful for display terminals. My immediate idea for a solution is to change location CHITAB+33 from 17,,TTSME to 17,,TCOUT ------- 18-Jan-84 16:29:05-PST,441;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jan 84 16:28:46-PST Date: Wed 18 Jan 84 16:29:21-PST From: William "Chops" Westfield Subject: continuation of prev message re escape and $ To: tops-20@SU-SCORE.ARPA This patch seems to have the desired effect. Note that translation of escape to $ takes place elsewhere for other data modes. Enjoy BillW ------- 18-Jan-84 17:07:59-PST,1611;000000000000 Mail-From: MRC created at 18-Jan-84 17:07:39 Date: Wed 18 Jan 84 17:07:39-PST From: Mark Crispin Subject: TCPJFN bug: port number validation To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: FTP server using TCP: JFN interface won't work if user isn't privileged. Diagnosis: The TCP: device does not allow unprivileged users to use a local port less than [1.0]. Unfortunately, one of these ports is the FTP data port. The test should only come into place if the connection is passive; that is, active connections should be allowed on any low-numbered port. Solution: Remove the privilege check from GTJFN%. Add a privilege check to OPENF%. In the HSTPRT code, remove the three lines: MOVX T2, TDNN T2,CAPENB ;Required privs? RET ;no so error In the TCPOPN code, between the two instructions: LOAD T1,TLP,(TCB) ;Get the local port MOVEM T1,.TCPLP+TCPBCB ;save the local port and LOAD T1,TLH,(TCB) ;get the local host number insert the following new code: TMNN TCDFS,(TCB) ;Active flag? CAILE T1,377 ;Not active - special low port? CAIL T1,100000 ;Active or not low - special high port? ANNSK. ;Special port - must do privilege check MOVX T1, TDNN T1,CAPENB ;Required privs? RETBAD(NTWZX1) ;Indicate must be network wizard ENDIF. A new version of TCPJFN.MAC incorporating this fix in on MRC:TCPJFN.MAC. ------- 18-Jan-84 17:37:14-PST,530;000000000000 Mail-From: MRC created at 18-Jan-84 17:36:54 Date: Wed 18 Jan 84 17:36:54-PST From: Mark Crispin Subject: Re: echoing $ and outputing escape To: BILLW@SRI-KL.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "William "Chops" Westfield " of Wed 18 Jan 84 16:26:40-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) SPR 20-17801 had a fix for outputting ESCAPE correctly in .TTATE mode. ------- 18-Jan-84 17:56:52-PST,517;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jan 84 17:56:41-PST Date: 18 Jan 1984 17:57-PST Sender: BILLW@SRI-KL Subject: escape and $ From: William "Chops" Westfield To: tops-20@SCORE Message-ID: <[SRI-KL]18-Jan-84 17:57:09.BILLW> DECs patch is silly. It uses code to accomplish the same thing my patch accomplishes by just chaning the table. Does anybody agree with me? (The SPR MRC mentions is in the 15-nov-83 dispatch). BillW 19-Jan-84 05:24:59-PST,1288;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Jan 84 05:24:50-PST Date: Thu 19 Jan 84 06:24:38-MST From: Norm Samuelson Subject: Adding tables to the monitor To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 There are some things I would like to store in tables in the monitor. One that would probably be helpful to many sites is a BOX NUMBER (stored as a string of some reasonable length, up to 8 or 10 words max). Another that is specific to our needs is a user number for our network. I am considering adding a new JSYS to store a value in that table, and another to read the table. Has it already been done by somebody else? If so, I would be willing to flatter the author by copying it, if not I will do it and make it available to anyone who is interested, along with code for QUASAR to look in the table if a queue message comes with no box number. We already have code in LPTSPL to use the box number, which is inserted by the EXEC on a PRINT command, but of course cant be filled in on spooled output requests, which is why the table belongs in the monitor. - Sam - ------- 19-Jan-84 06:24:11-PST,1501;000000000000 Mail-From: MRC created at 19-Jan-84 06:24:01 Date: Thu 19 Jan 84 06:24:01-PST From: Mark Crispin Subject: more on port restrictions in TCPJFN To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) MRC:TCPJFN.MAC.51 has the latest generation in the great port restriction saga. The code announced in the last message has a couple of bugs, but this new version has been tested and shown to work. With this version of TCPJFN, the following behaviors will be observed: . any user may get and open any port between [1.0] and [127.255] inclusive. . only privileged users may get or open absolute ports [128.0] or higher; this is the address space of ports the system will generate for a user. . unprivileged users may get ports less than [1.0], but may only open them if the ;CONNECTION attribute is ACTIVE. . ports less than [1.0] or .GE. [128.0] may only be got (via GTJFN%, of course) if a "#" is placed after the port number to confirm, regardless of privileges (of course, an unprivileged user can't get ports [128.0] or higher in any case). In other words, for the following TCP: connections: TCP:1 not valid TCP:1# valid if privileged TCP:1#.host-port;CONNECTION:ACTIVE valid for all users TCP:456 valid TCP:456# valid TCP:32768 not valid TCP:32768# valid if privileged ------- 19-Jan-84 12:03:25-PST,1007;000000000000 Mail-From: ALMQUIST created at 19-Jan-84 12:03:06 Date: Thu 19 Jan 84 12:03:06-PST From: Philip Almquist Subject: Re: Adding tables to the monitor To: Samuelson@SANDIA.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Norm Samuelson " of Thu 19 Jan 84 05:25:01-PST CMU did what you want, by adding a new function to SETJB% as I recall. Actually, they did more than you asked for: most (or perhaps by now all) print defaults are stored in the Monitor, so output to Lpt: is not only filed in the right bin but everything else comes out right, too: unit, forms, orientation (portait/landscape), ... It may be a more complicated change than you want to deal with, especially since you will probably have to weed out the laser printer support that pervades CMU's Galaxy and Execqu. However, if you're up to it Vince Fuller (VAF@CMU-CS-C) can probably direct you to the appropriate sources (sorry, Vince!). Philip ------- 19-Jan-84 16:39:11-PST,1014;000000000000 Return-Path: Received: from JPL-VAX.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Jan 84 16:38:59-PST Date: 19 Jan 1984 1636 PST From: Eric P. Scott Subject: ARPAnet/DDN Session at Spring DECUS To: TOPS-20@SU-SCORE Cc: TCP-IP@SRI-NIC,Info-VAX@SRI-KL Reply-To: EPS@JPL-VAX I received quite a bit of positive feedback (from DEC even!) to my "Spreading the gospel" query, but alas no one seems prepared this early in the game to make firm commitments. Unless I hear a bunch of "I'll help!"'s by tomorrow afternoon, I will request 2 hours for "Internetworking the ARPA way," a series of mini- sessions tied together by a common theme. Some of these will be geared toward the pagan masses, some will be presentations on work done and in progress (using DEC computers), and somewhere in there will be a users panel. I expect representatives from the DDN-PMO and Digital to be in attendance. I need volunteers, I need volunteers, I need volunteers... -=EPS=- ------ 19-Jan-84 21:04:48-PST,663;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Jan 84 21:04:29-PST Date: Thu 19 Jan 84 22:04:15-MST From: Randy Frank Subject: Re: Front end lines To: CC.Clive@UTEXAS-20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Wed 18 Jan 84 16:53:42-MST we have very sucessfuly used the Able DH/DM which is fundamentally the same as the Emulex sc21. It is also a one board DH11/DM11. No problems other than it doesn't have split baud rates. Can't comment on the Emulex in a 20, although we have used them w/o problem in Vaxen. ------- 20-Jan-84 04:14:57-PST,877;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Jan 84 04:14:47-PST Date: 20 Jan 84 07:13:37 EST From: Charles Hedrick Subject: Re: ARPAnet/DDN Session at Spring DECUS To: EPS@JPL-VAX.ARPA cc: TCP-IP@SRI-NIC.ARPA, Info-VAX@SRI-KL.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Eric P. Scott " of 19 Jan 84 19:36:00 EST I would certainly be happy to help. I will definitely be at DECUS, since it is in my home town! [You will finally get a list of good restaurants.] Anything in particular you would like from me. I know, or can find out by then, about most of the software and protocols commonly used on the 20. I don't know as much as some of the folks at Stanford, BBN, and ISI, and I use only DDN itself, I don't use TCP for local networking [yet]. ------- 20-Jan-84 17:27:48-PST,2002;000000000000 Return-Path: Received: from JPL-VAX.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Jan 84 17:27:27-PST Date: 20 Jan 1984 1727 PST From: Eric P. Scott Subject: "Internetworking the ARPA Way" at Spring DECUS To: TOPS-20@SU-SCORE Cc: TCP-IP@SRI-NIC,Info-VAX@SRI-KL Reply-To: EPS@JPL-VAX I have requested two hours sponsored by the Networks SIG for "Internetworking The ARPA Way" with the following abstract: Originally designed to replace the traditional Host-to-Host protocol used on the ARPAnet until 1983, TCP/IP is rapidly gaining acceptance outside the ARPA community due to its inherent suitability to local area networks and independence from any particular manufacturer, machine architecture, or operating system, as well as bundled support in Berkeley's 4.2 VAX Unix distribution. The specifications for the DoD Standard Protocol Suite of which TCP/IP is the most well-known are in the public domain; implementations for various systems are available from several vendors. This session will consist of several back-to-back subsessions intended to introduce newcomers to the ARPA philosophy, current R&D in the field, current concerns and future directions, and Digital's commitments to support this technology. Time will be provided for questions and general discussion, but it is suggested that experiences with particular hardware/software combinations be the subject of Birds-of-a-Feather sessions. Listed speakers are myself, Mark Crispin of Stanford University, Charles Hedrick of Rutgers University, an unnamed representative of the DDN Program Management Office, and an unnamed Digital Person. All that has been accomplished is that a block of time has been requested for scheduling. Between now and June we have to work out the details of how that time will be used. Eric P. Scott Networked Computer Systems Group Computer Science and Applications Section Jet Propulsion Laboratory ------ 20-Jan-84 18:15:32-PST,4120;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Jan 84 18:15:02-PST Date: 20 Jan 84 21:14:51 EST From: Charles Hedrick Subject: DTE results To: tops-20@SU-SCORE.ARPA I was astounded at the response to my question about the speed of the DTE. I haven't gotten so a big result from such a little question for a long time. Since there seems to be so much interest, I thought I would summarize the results for the benefit of the readers in general. 1) The highest number I heard was 500Kbaud, which several people agreed was the design maximum of the hardware. 2) The next highest was the result of tests conducted by Dan Tappan and others at BBN. These tests looped back packets between the 20 and the 11, using test software. There is no claim that they represent anything you could get with a practical protocol running under normal timesharing. The throughput turned out to depend upon the length of the packets. The asymptotic speed, with infinite packet size, was 345 Kbaud for an 11/23, and 270 Kbaud for an 11/03. The fact that the results are processor-dependent suggests that this is still being affected by the processors, and is not the true speed of the DTE hardware alone. 3) The highest speed with actual protocols seemed to be from CHAOS users, some of whom claimed 150 to 200 Kbaud, under ideal circumstances. 4) The lower bound was about 50 Kbaud, which is about the speed that a number of people said they were seeing. We are now getting between 80 and 130 Kbaud net throughput (i.e. actual data bits) for PUP. We have reason to believe that the limiting factor is the 20 support code. It seems to reactivate the user's process for every packet. Simple calculations suggest that the maximum one could expect for such a strategy is about 150 Kbaud. For rates approaching those of a disk, one would need either very big packet sizes, or for the monitor to do I/O into and out of internal buffers, activating the user program only for every few pages of data. I believe the latter suggestion is the most practical. It turns out that we can't get much more than 135 Kbaud out of the machines we are trying to talk to, so we are not going to try to get any better performance. We do hope that the TCP code is being designed to do a better job. Incidentally, we have now seen a couple of glitches in the DTE behavior. I reported earlier that we seemed to be seeing cases where a to-11 doorbell did not cause an interrupt. We have put into our device driver code to detect the case where the to-11 doorbell bit is set, but an interrupt is not triggered. This code is being activated on the order of 10 to 25 times a day on each of our 3 DTE's. It is hard to believe that we have 3 DTE's whose hardware is broken in the same way. We don't see any way that our software could be getting confused. It's a very easy test. We look for both Interrupts enabled and To-11 Doorbell. These bits should never be visible except in interrupt-level code, since they should cause an interrupt. We suspect that the normal DEC code does DTE resets often enough that they clear this condition before it has a chance to cause trouble. Because we are doing full duplex transfers at high data rates, we cannot afford to reset the DTE except under very carefully controlled circumstances. (If the receive side did a Reset it could message up a Send transfer that happened to be in progres and visa versa.) Today we detected a second glitch: We believe we are getting two Done interrupts from the same To-10 transfer. In this case the evidence is not quite as clean. In principle a bug in our driver could be causing the situation. However the code involved in checking for this particular situation is fairly brief, and we think it is unlikely that our problem is software. It is possible that DEC's code is able to ignore spurious interrupts, and so is not bothered by this problem either. (Needless to say, our driver now ignores these extra Dones.) ------- 21-Jan-84 01:43:37-PST,1380;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 21 Jan 84 01:43:30-PST Date: Sat 21 Jan 84 01:38:45-PST From: Kirk Lougheed Subject: Re: DTE results To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Fri 20 Jan 84 21:14:51-PST Although this doesn't have much to do with DTE's, it may be of interest. I have timed the Stanford 3MB MEIS (Massbus Ethernet Interface Subsystem) at 280 Kbaud between two -20's using the PUP protocols. We regularly move files between -20's at rates in excess of 100 Kbaud. Network congestion and the nature of the other host appear to be the most important factors influencing the actual transfer rate. Higher PUP speeds could easily be obtained by increasing the packet size. Since the MEIS is a Massbus device, software is our major limiting factor, not the hardware. I'm sorry to say, however, that I've not seen TCP file transfers faster than 80 Kbaud under the same conditions. I have made a number of improvements to the original Xerox/Sumex/CMU PUP code to increase its speed and efficiency. You are welcome to the changes. A prototype of the 10MB MEIS is now being microcoded and bench tested by George Schnurle of Stanford Computer Science. Kirk ------- 22-Jan-84 05:08:18-PST,1263;000000000000 Mail-From: MRC created at 22-Jan-84 05:08:11 Date: Sun 22 Jan 84 05:08:11-PST From: Mark Crispin To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The documentation is inaccurate for ;PERSIST and ;TIMEOUT. The default for ;PERSIST and ;TIMEOUT is 0 - no timeout. This default happens only if the attribute is not given. It is not valid to null-specify the attribute value - there is no such thing as the "30 second" defaults as documented. The ;PERSIST value affects the OPENF% timeout. It also sets the "persist" flag in the OPEN% call. Too bad there isn't a way to set an OPEN% timeout without setting "persist". The ;TIMEOUT value affects the timeout for BIN%/BOUT% (that is, it sends the timeout AC for SEND%/RECV%). It does not affect OPENF% in any way. I consider the present behavior of the timeouts defaulting to no timeout to be desirable. I hope that instead of changing the code that the documentation is changed. I wouldn't be too unhappy is ;PERSIST were changed to default, but ;TIMEOUT should never be set non-zero unless the user sets it. -- Mark -- ------- 23-Jan-84 02:33:01-PST,683;000000000000 Return-Path: Received: from CMU-CS-A by SU-SCORE.ARPA with TCP; Mon 23 Jan 84 02:32:47-PST Date: 23 Jan 84 0532 EST From: Rudy.Nedved@CMU-CS-A To: TOPS-20@SU-SCORE Subject: Delivery-Notices Message-Id: <23Jan84.053223.EN0C@CMU-CS-A> As mentioned previosly, the Delivery-Notice mechanism that Mark Crispin put into several versions of XMAILR/MMAILR was not too tolerant with loaded machines or slow queueing mechanisms. I strongly encourage people to comment out, patch out and install a version with out this bogous message in it. I am getting tired of telling local users to ignore the error. The problem is not the local mail system!!!!! -Rudy 23-Jan-84 03:03:55-PST,1949;000000000000 Return-Path: Received: from CMU-CS-A by SU-SCORE.ARPA with TCP; Mon 23 Jan 84 03:03:39-PST Date: 23 Jan 84 0602 EST From: Rudy.Nedved@CMU-CS-A To: HEDRICK@RUTGERS, TOPS-20@SU-SCORE Subject: CMUFTP Message-Id: <23Jan84.060220.EN0C@CMU-CS-A> CMU for a while had a hack called CMUFTP working on its VMS, TOPS-10, TOPS-20 and Unix machines which was heavily used. The CMUFTP protocol was a modified version of Xerox's Easy File Transfer Protocol which uses PUP as datagrams. The timeouts and various tolerances were modified to allow file transfer to work, remote program execution to work most of the time and mail to work under most conditions. When we coded the stuff, we didn't even attempt to handle the eventual net expansion problem...having more then ~255 hosts or having multiple logical cables (for reliability or security issues). We did add some hacks to deal with using the same facilities for 10MB hosts but we keep hitting problems that can only be correctly solved by putting routing code into all the CMUFTP systems and to add a "I am still alive packet" to the CMUFTP protocol to deal with the logical CLOSE that can take more then the maximum timeout. Since ARPA required IP based services to be implemented for our primary hosts and since the UDP and TCP level protocols satisfied all of our current and expected feature needs with network usage, we switched our efforts to phasing out CMUFTP and brining up IP based protocols. We have code working for VMS (from SRI I think), ALTOs (from MIT), Unix (from BBN), TOPS-20 (from BBN/DEC) and for TOPS-10 (from Provan@LLL-MFE). We are working on getting stuff for our PERQ systems and CMU has buried somewhere TCP/IP code for IBM PCs. In other words, anyone who has imported this crock of ours should 1) be considered desperados and 2) not expect too much help from CMU. -Rudy President of "Stamp out CMUFTP by 1985" Club 23-Jan-84 09:56:06-PST,1707;000000000000 Mail-From: MRC created at 23-Jan-84 09:55:55 Date: Mon 23 Jan 84 09:55:55-PST From: Mark Crispin Subject: Re: Delivery-Notices To: Rudy.Nedved@CMU-CS-A.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Mon 23 Jan 84 05:32:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I should note that the latest release of MMailr that supports the TCP: device does not have the "Delivery-Notice" code. Nor does it support the slow, 50-byte Pushed segment style of sending that the Delivery- Notice indicated was happening. It has been observed that there are still sites whose TCP's are sufficiently broken so that they cannot receive a large chunk of SMTP data that does not have extraneous Pushed segments. The only difference is that formerly, they received messages with the obnoxious "Delivery-Notice". Now, they don't receive mail at all. I suggest that Rudy Nedved take charge of telling those sites what is wrong. A year is long enough to help out sites with broken TCP's, especially when I took crap from presuming to help out such people. Incidentally, the "intolerance of loaded machines or slow queueing mechanisms" that Rudy referred to is the intolerance of data throughput of less than 1000 bytes/2 minutes, or a delay of greater than 5 minutes in receiving an acknowledgement of receipt of the message. A TCP or SMTP server which fails to achieve performance within those criteria should be considered faulty. That is not the sort of software I would like to see DoD computers running in the event of nuclear war. ------- 23-Jan-84 21:12:37-PST,2853;000000000000 Return-Path: Received: from CMU-CS-A by SU-SCORE.ARPA with TCP; Mon 23 Jan 84 21:12:17-PST Date: 24 Jan 84 0012 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: Delivery-Notices CC: TOPS-20@SU-SCORE In-Reply-To: "Mark Crispin's message of 23 Jan 84 12:55-EST" Message-Id: <24Jan84.001207.EN0C@CMU-CS-A> I should note that the latest release of MMailr that supports the TCP: device does not have the "Delivery-Notice" code. Nor does it support the slow, 50-byte Pushed segment style of sending that the Delivery- Notice indicated was happening. I just wish the sites would pick up the change. It has been observed that there are still sites whose TCP's are sufficiently broken so that they cannot receive a large chunk of SMTP data that does not have extraneous Pushed segments. The only difference is that formerly, they received messages with the obnoxious "Delivery-Notice". Now, they don't receive mail at all. I suggest that Rudy Nedved take charge of telling those sites what is wrong. A year is long enough to help out sites with broken TCP's, especially when I took crap from presuming to help out such people. No thanks to the job appointment. I suspect it is the case that most of the offending sites are running 4.2 Berkeley Unix and that Berkeley has either not fixed the problem or has not distributed the bug fix except to a few sites. People tend to not make changes to things if things work more then 70% of the time. Incidentally, the "intolerance of loaded machines or slow queueing mechanisms" that Rudy referred to is the intolerance of data throughput of less than 1000 bytes/2 minutes, or a delay of greater than 5 minutes in receiving an acknowledgement of receipt of the message. A TCP or SMTP server which fails to achieve performance within those criteria should be considered faulty. That is not the sort of software I would like to see DoD computers running in the event of nuclear war. People and organizations have different priorities when compared to each other. At CMU, we apply higher priority to guaranteeing that mail gets thru or gets rejected. Therefore our "250 DATA command worked" does not come until after we are sure we have the message queued. Other sites just say "250..." when they get the "." and don't worry about whether the machine crashes right afterwards. We also accept mail on machines that are trying to munge large chunks of data in almost real time....this has higher priority then receiving mail. If sites are suppose to have a certain level of performance to deal with a nuclear war then I suspect the goverment has contracted those sites to deal with them. CMU is in the research business not in the war business. Maybe your machine is? -Rudy 24-Jan-84 08:39:47-PST,2773;000000000000 Mail-From: MRC created at 24-Jan-84 08:39:39 Date: Tue 24 Jan 84 08:39:39-PST From: Mark Crispin Subject: DECUS customer strategy To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have come up with the following menu of demands we should present to DEC in Cincinnati. There doesn't seem to be much of a reason to be nice to DEC; nor does there seem to be any reason for us to go to lengths to compromise. DEC should be compromising with US, not the other way around: . While DEC's announced licensing policy for TOPS-10/20 on third-party machines is an improvment, we have decided it is no longer adequate. We feel that TOPS-10, TOPS-20, and all 36 bit compilers, utilities, and associated software should be placed in the public domain no later than [choose a date - how about 1 January 1985?]. Our arguments for this are: . legal - DEC's copyrights may be invalid . restraint of trade - DEC's licensing of software can have the effect of discouraging third-parties . ethical - DEC owes it to its departing customer base to give those customers the maximum chance of supporting their systems . All schematics, design specifications, functional descriptions, and all related documentation pertaining to 36 products including but not limited to: KL-10, KS-10, Jupiter, Minnow, Dolphin, Unicorn, MASSBUS, S-BUS, X-BUS, etc. etc. should be placed in the public domain, to maximize customer support possibilities and to assist third-parties in every possible way in designing, building, and marketing viable 36-bit products. "Related documentation" includes diagnostics. . The next generation of VAX hardware products must have a 36-bit emulation mode, much as IBM supplies in their processor products to support customers with non-portable software using discontinued engines. This must also include suitable modifications to VAX/VMS to support whatever system calls (UUO's, jsi) that this software might attempt to use, so that the software will function as it would on an actual 36-bit engine. Finally, some friendly advice for DEC. If DEC no longer wants to get its hands dirty with 36 bit products, perhaps they should allow that part of LSG working on 36 bits to spin off and ultimately purchase their independence from DEC the corporation. I am convinced that most, if not all, of the inadequate progress with 36 development inside DEC is the direct result of talented people being deliberately stymied from accomplishing their goals; and that the source of this interference is in DEC management. ------- 24-Jan-84 21:47:55-PST,620;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 24 Jan 84 21:47:45-PST Date: Tuesday, 24 January 1984, 19:23-PST From: Ken Olum Subject: PS: which is not named PS: To: tops-20 at SU-SCORE When you have a PS: which is not named "FOO" instead of "PS" but becomes PS because the system serial number is in the home block, then the system mounts FOO as FOO and then ^Edefines PS to be FOO. Is there any good reason to do it this way instead of MOUNTing FOO with alias PS? That way JFNS and DIRST and so on would return PS: instead of FOO:. Ken 25-Jan-84 05:03:24-PST,882;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Wed 25 Jan 84 05:03:16-PST Date: Wed 25 Jan 84 06:03:00-MST From: Norm Samuelson Subject: Re: PS: which is not named PS: To: KDO@SRI-KL.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Olum " of Tue 24 Jan 84 22:51:03-MST Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 Today there is no real good reason not to, BUT! Some day - DEC is planning to support a common file system. When they do, you would NOT want FOO to be known only as PS:, but more likely you would want the "ps" on each system to have a name related to the host name. I believe that it is a REQUIREMENT for CFS that every structure must have a unique name. - Sam - ------- 25-Jan-84 05:59:55-PST,955;000000000000 Mail-From: MRC created at 25-Jan-84 05:59:48 Date: Wed 25 Jan 84 05:59:48-PST From: Mark Crispin Subject: Re: PS: which is not named PS: To: KDO@SRI-KL.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Olum " of Tue 24 Jan 84 21:47:58-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is a perfectly good reason for a primary structure not named PS: to be mounted as its own name with a ^Edefine PS: to be that name (as opposed to mounting the structure with alias PS:). It's called the Common File System. The whole concept of PS: should be considered semi-obsolete. There is simply a primary structure of arbitrary name, which must be unique across a CFS cluster. PS: is now just the default name for the primary structure, and the logical name of PS: is there mostly for compatibility. ------- 25-Jan-84 06:36:07-PST,1589;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 25 Jan 84 06:35:55-PST Date: 25 Jan 84 09:35:27 EST From: Charles Hedrick Subject: request for a service To: cic@CSNET-CIC.ARPA, msggroup@BRL.ARPA, tops-20@SU-SCORE.ARPA, nic@SRI-NIC.ARPA We have had several occasions recently where someone wanted to establish a research collaboration with a colleague, but we have been unable to find a route for computer mail. In one case this was for a University in Australia, which supposedly has a UUCP address, and in another case it was somebody on Bitnet. (Interestingly enough, in both cases we had claimed routes, but the mail disappeared in the bit bucket. We were unable to locate anyone who could help us in figuring out where it went.) There are a number of Universities that are not part of the Arpanet, CSnet, etc. but which those of us in the community would like to be able to reach. Does anyone know of either - a database listing as many universities as possible and how to get mail to them (all possible routes, for those that are on more than one net) - a mailing list for discussin delivery paths. This would include both changes in existing networks and forwarding services, and tips on finding obscure places. If possible the maintainer of the database should add information as it shows up on this mailing list. If these things do not exist, would anyone like to create them? This would seem a perfect job for NIC or CIC, if they are willing. ------- 26-Jan-84 07:56:01-PST,1125;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 26 Jan 84 07:55:48-PST Date: 26 Jan 1984 1045-EST From: Allan Titcomb To: Local-nets at MIT-MC cc: Tops-20 at SU-SCORE, Telecom at USC-ECLC, Info-VAX at MIT-MC, Info-UNIX at BRL DTN: 231-4849 LOC: MR2-2/8D2 Subject: Local Networks Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11986706558.26.270.14826 at DEC-MARLBORO> I would like to learn more about the real networking world. From what I have heard so far it seems that sites often end up with quite a number of networks, protocols, and systems supported with varying success. Certainly, there is much more to the story than I had thought. I would like to know which implementations on Ethernet have been moved to various sites successfully, what hardware is supported, which operating systems etc.. Is anyone running both TCP and something else on the same wire? Who has the best terminal concentrator on Ethernet? Does it support VAX's? 20's ? both?? Thanks for whatever comes my way. Allan -------- 26-Jan-84 13:52:23-PST,1114;000000000000 Return-Path: Received: from su-shasta by SU-SCORE.ARPA with TCP; Thu 26 Jan 84 13:51:36-PST Date: Thursday, 26 Jan 1984 13:50-PST To: "David C. Plummer" Cc: TITCOMB at DEC-MARLBORO.ARPA , Local-nets at MIT-MC.ARPA , Tops-20 at SU-SCORE.ARPA , Telecom at USC-ECLC.ARPA , lispm-networks%SCRC-TENEX at MIT-MC.ARPA Subject: Re: Local Networks In-Reply-To: Your message of Thu, 26 Jan 84 16:12 EST. From: Jeff Mogul At Stanford, we have a 10mb network on which we are running IP Pup XNS Chaos V (local distributed system protocol) and several different Address Resolution Protocols. Some of our machines can run all of these but Chaos (which is why we're waiting for Symbolics' IP) We've had several years experience running Pup, IP, and V over a 3mb ethernet without major problems related to running multiple protocols (except at gateways!). -Jeff 26-Jan-84 14:03:28-PST,2182;000000000000 Return-Path: <@MIT-MC:DCP@SCRC-TENEX> Received: from MIT-MC by SU-SCORE.ARPA with TCP; Thu 26 Jan 84 14:02:46-PST Received: from SCRC-CHARLES by SCRC-QUABBIN with CHAOS; Thu 26-Jan-84 16:25:34-EST Date: Thu, 26 Jan 84 16:12 EST From: "David C. Plummer" Subject: Local Networks To: TITCOMB@DEC-MARLBORO.ARPA cc: Local-nets@MIT-MC.ARPA, Tops-20@SU-SCORE.ARPA, Telecom@USC-ECLC.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA In-Reply-To: <"MS10(2124)+GLXLIB1(1136)" 11986706558.26.270.14826 at DEC-MARLBORO> Date: 26 Jan 1984 1045-EST From: Allan Titcomb I would like to learn more about the real networking world. From what I have heard so far it seems that sites often end up with quite a number of networks, protocols, and systems supported with varying success. Certainly, there is much more to the story than I had thought. I would like to know which implementations on Ethernet have been moved to various sites successfully, what hardware is supported, which operating systems etc.. Symbolics delivers Chaosnet software with each machine (these days 3600s connected to Ethernets). I have heard of very few problems in bringing up the network between machines. MIT is perhaps the largest site with Chaosnet protocols running (they started it all). Is anyone running both TCP and something else on the same wire? In addition to the Chaosnet protocols, Symbolics is preparing to beta-test TCP/IP, which is (at it should be) a "brother" of Chaosnet as far as the Lisp Machine network system goes. There may also be plans to implement DECnet and/or XNS some day. BTW, if you want to cause some trouble, call me (617 864-4660) and I'll tell you why it is HARD to implement DECnet (over the Ethernet) as a brother to other protocols on the same machine. Who has the best terminal concentrator on Ethernet? Does it support VAX's? 20's ? both?? Well, I wrote one, which talks Chaos protocols. It has its problems, but it is in pretty wide use at MIT. Thanks for whatever comes my way. Allan -------- 29-Jan-84 22:20:57-PST,422;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 29 Jan 84 22:20:47-PST Date: Sun 29 Jan 84 22:20:39-PST From: Kirk Lougheed Subject: Modula-2 Compiler? To: tops-20@SU-SCORE.ARPA, info-vax@SRI-KL.ARPA Does anyone know where I can get ahold of a Modula-2 compiler for any of TOPS-20, TOPS-10, or UNIX 4.x BSD? Thanks, Kirk ------- 30-Jan-84 11:47:06-PST,1623;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Jan 84 11:46:53-PST Date: Mon 30 Jan 84 11:27:39-MST From: Norm Samuelson Subject: Dumb problem with GTJFN To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 I have been having a dumb problem with GTJFN which I have not had time to find. I think it is related to a patch which may have been on this mailing list some months back. The bug does not occur in most systems I have tried it on, but I cant find any such patch in the .RED files that ALU writes for me. The bug is this: MOVX T1,GJ%SHT HRROI T2,[ASCIZ/FOO.BAR.1/] GTJFN ERJMP BAD1 ;this one works MOVX T1,GJ%SHT HRROI T2,[ASCIZ/FOO.BAR.1/] GTJFN ERJMP BAD2 ;This takes the error jump Where FOO.BAR.1 does not exist. The second GTJFN gets the File not found error. This may seem like it would be good, since getting two JFNs on one generation of one file may lead to problems, BUT!!! It happens that a few DEC programs fail when this happens. The first is EDIT. When you try to exit, he gets a new jfn on the output file and it fails, so he wont write anything. The second is the EXEC, when you specify a generation number on a COPY or RENAME. Does anybody remember a "fix" that caused the second GTJFN to fail? I remember some discussion about the whole thing, but with my limited access to TOPS-20 (only between 4 and 8 AM), it has not been easy for me to find it. - Sam - ------- 30-Jan-84 13:49:28-PST,1203;000000000000 Mail-From: MRC created at 30-Jan-84 13:49:04 Date: Mon 30 Jan 84 13:49:04-PST From: Mark Crispin Subject: Re: Dumb problem with GTJFN To: Samuelson@SANDIA.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Norm Samuelson " of Mon 30 Jan 84 11:47:08-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I believe I know what is causing the problem with a 90% certainty. I don't know what a fix would be. The first GTJFN% causes an FDB with "non-existant" status to be created for the file. The second GTJFN% encounters the "non-existant" FDB, and returns "file not found" as a consequence. The file does not "exist" until after it is closed. Non-existant files with data in them are what the PURGE subcommand of EXPUNGE gets rid of. Typically this only happens as a result of a system crash. The code that causes this bogosity is in DIRECT. There is another related bug having to do with mail files that was reported on the list a while ago - opening a deleted file GJ%FOU would set the file as "non-existant" as well as undeleting it. ------- 30-Jan-84 16:43:46-PST,942;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Jan 84 16:43:32-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2621810219082436@MIT-MULTICS.ARPA>; 30 Jan 1984 19:36:59 est Date: 29 Jan 84 14:26 +0100 From: Bo_Dahlberg_(DEC)@QZCOM.MAILNET Reply-to: Bo_Dahlberg_(DEC)@QZCOM.MAILNET, TOPS-10/20_SIG@QZCOM.MAILNET, ALMQUIST_%_SU-SCORE.ARPA(Philip_Almquist)@QZCOM.MAILNET To: TOPS-10/20_SIG@QZCOM.MAILNET, "Clive Dawson" , ALMQUIST_%_SU-SCORE.ARPA(Philip_Almquist)@ QZCOM.MAILNET cc: tops-20 Subject: Re: Front end lines Message-ID: <39180@QZCOM> In-Reply-To: <37962@QZCOM> You haven't think of to use DZ11 at QZ they use DZ11 with good result. (Text 39180)------------------------------ 30-Jan-84 17:39:47-PST,887;000000000000 Return-Path: Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Jan 84 17:39:32-PST Date: 30 Jan 1984 17:38-PST Sender: LEINER@USC-ISI Subject: Re: "Internetworking the ARPA Way" at Spring DECUS From: LEINER@USC-ISI To: EPS@JPL-VAX Cc: TCP-IP@SRI-NIC, TOPS-20@SU-SCORE, Info-VAX@SRI-KL Message-ID: <[USC-ISI]30-Jan-84 17:38:03.LEINER> In-Reply-To: The message of 20 Jan 1984 1727 PST from Eric P. Scott Eric, Small but not minor correction. TCP/IP was not designed for the purpose of replacing NCP but was designed to support an environment consisting of multiple heterogeneous networks each capable of providing datagram service at a minimum. IP provides the means for interconnecting the networks and TCP provides the means for providing a virtual circuit using that datagram service. Barry 30-Jan-84 17:42:54-PST,685;000000000000 Return-Path: Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Jan 84 17:42:42-PST Date: 30 Jan 1984 17:40-PST Sender: LEINER@USC-ISI Subject: Re: "Internetworking the ARPA Way" at Spring DECUS From: LEINER@USC-ISI To: EPS@JPL-VAX Cc: TCP-IP@SRI-NIC, TOPS-20@SU-SCORE, Info-VAX@SRI-KL Message-ID: <[USC-ISI]30-Jan-84 17:40:44.LEINER> In-Reply-To: The message of 20 Jan 1984 1727 PST from Eric P. Scott Eric, I'd like to ask you to provide a pre-pub copy of what you are planning on presenting if you intend (as it sounds from the aabstract) to represent the ARPA philosphy, approach, etc. Thanks much. Barry 30-Jan-84 20:27:21-PST,2162;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.SLOGIN@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Jan 84 20:26:45-PST Received: from CU20B by CUCS20 with DECnet; 30 Jan 84 23:26:57 EST Date: Mon 30 Jan 84 23:26:44-EST From: Thomas De Bellis Subject: B362LB.REL To: Tops-20%SU-SCORE@COLUMBIA-20.ARPA Reply-To: CC.SLogin@Columbia-20 Recently we received a tape from DEC with a new release of DX-TOPS20, DEC's package to ship files between DECmate word processors and DECSYSTEM-20s. The tape was missing a couple of BLISS compiled files (XPORT.REL and B362LB.REL) and I couldn't load up all the .REL files because of this. So, I did some digging around and pulled some files off one of the hosts on our local DECnet (CCnet) and attempted to use them. This turned out to not do me much good because, although I was able to sucessfully link up the modules, the resultant .EXE file, when run, continually displayed the menu and never accepted any input characters. In short, it was totally unusable. A few days ago, DEC tried again and sent us another tape with all the same DX stuff on it with a couple of the forgotten modules included (various flavors of XPORT). I say "a couple" because they still forgot to include B362LB.REL. So, I pulled this off of our friendly CCnet host but the linked .EXE file still loses like the first one (I.E., it continually displays the menu and never accepts any input characters.) Since the version of B362LB that I used was written on 25-Feb-82, I suspect that it is out of date. I have anonymously logged in on lots of places all over, but I have been unable to find a later copy of B362LB anywhere. If somebody could point me at a copy (like some kind soul at DEC-MARLBORO), I would be very happy. I think it's kind of funny that the folks at Merrimac have screwed up twice on this, but others around here don't have my sense of humor and they would probably be somewhat annoyed to have to wait another couple of weeks for DEC to ship us another tape. Anyway, any help would sure be appreciated! -- Thomas De Bellis ------- 30-Jan-84 22:04:29-PST,1617;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Jan 84 22:04:15-PST Date: 30 Jan 84 20:58:11 EST From: Rich Acuff at Ohio State Subject: Position open for DEC-20 Manager at Ohio State To: Tops-20@SU-SCORE.ARPA The following position is now open at OSU. In order to apply for it, however, you must act fast. Please send applications to: The Ohio State University Personnel Office Columbus, Ohio 43210 and notify Acuff@RUTGERS.ARPA via electronic mail so that the Computer Science Dept. can ask for them explicitly. U-4220-2067-010984 OSU Instruction and Research Computer Center; bachelor's degree in computer science or related field or an equivalent combination of education and experience; programming and supervisory experience; programming experience with DEC-20 computer system and ability to prepare proposals, function specifications and procedure documentation desired; supervises operation of computer system; set priorities and schedules usage; reports system failures in programs and equipment; coordinates establishment of customer accounts and the accounting/ billing of utilization; supervises staff; assigns projects and monitors progress; assists customers in use of computer facilities; provides customer consultation and training. Salary: $21,480-31,560. The Ohio State University is an Equal Opportunity, Affirmative Action Employer ------- 1-Feb-84 10:24:32-PST,1323;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 1 Feb 84 10:24:15-PST Date: 1 Feb 84 13:23:55 EST From: Charles Hedrick Subject: strange results with TTMSG To: tops-20@SU-SCORE.ARPA We have mostly gotten rid of TTMSG. With MRC's SEND system, normal user sends are done by SOUT. But [You have a message from...] and [System going down in...] are still done with TTMSG, or its equivalent. We find that messages sent with TTMSG sometimes do odd things to terminals. The clearest case is a Visual 55. You you send a message to a V55 with TTMSG, half the existing lines on the screen vanish. Often the first 10 lines. But sometimes every other line. Originally I figured this was just a glitch in the V55. Now someone reports that TTMSG causes some DM2500 terminals to go into screen-retransmit mode. LINK's seem to have similar properties. We have gone into monitor mode, and no funny characters are coming out. Does anybody have any idea what is going on? How would the results of TTMSG differ from SOUT, from the point of view of a terminal? We will take this up with Visual, as it sounds like a terminal glitch, but it could be that the front end is failing to send stop bits or something equally obscure. ------- 2-Feb-84 10:32:17-PST,2017;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 2 Feb 84 10:31:58-PST Date: 2 Feb 84 13:31:30 EST From: Charles Hedrick Subject: future of 36 bits To: bosack@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA I was really hot about this a year ago. I confess that I find it hard to get up any enthusiasm at the moment. I am beginning to conclude that we will be better off moving to Unix. As I understand it, Bell pushed Unix internally because they wanted to get out from under DEC. Finally, they say with a sigh of relief, we can buy a machine from anybody we want to. All we have to do is implement a C compiler... Well, of course that's maybe a bit overly optimistic, but I confess I am feeling this relief also. It is great to get back to salesmen who have deliverable products, and product lines that don't have to overprice their products to avoid competing with VMS. I am not just talking about the 20 line. We have had a VAXstation 100 on order for well over a year now. (I am inclined to think it is 2 years, but that may be an exaggeration.) And now even VAX products are being overpriced to avoid competing with VMS (or at least I have to assume that is the motivation): look at Ultrix. Suppose they really do continue the 20 line. The best we can hope for is a 4x KL for (old) KL prices. But I find it hard to believe that I am really going to be able to justify spending that amount of money. At this point I am much more interested in machines with KL performance in the $100K price range. And that they will never do because it will interfere with their precious VAX. I just don't want to get back into a product line that I know is going to be stifled at every turn by the constraints of not competing with VMS. I really think the right thing to do is to get busy on Unix development and look for other vendors. I can no longer afford to deal with companies that worship sacred cows. ------- 2-Feb-84 11:12:27-PST,1558;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 2 Feb 84 11:12:09-PST Date: Thu 2 Feb 84 12:10:48-MST From: Norm Samuelson Subject: Re: future of 36 bits To: HEDRICK@RUTGERS.ARPA, bosack@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Thu 2 Feb 84 13:31:30-MST Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 We too have decided to move toward UNIX in the long run, not because it is such a wonderful operating system, but because you can find plenty of engines to run it. But, in the next few years we are seriously considering buying another PDP-10. A KL at a reduced price is one option, but 4xKL at KL price would be even more attractive. We view this as a way to put off the decision to truly move to UNIX in hopes that something better will turn up. We would hate to retrain everybody to use UNIX, just to find in a couple of years that something better has come along. I would really like to see DEC do ANYTHING positive. I used to be very big on DEC. They had done much better at meeting my needs than CDC or IBM or anybody else. But, alas, they seem to be overly impressed with the "wonderfullness" of VMS. I did take the time to write to DEC management to express our feelings (a few months back), and I agree with Len, if you have not let them know how you feel, you really should. - Sam - ------- 2-Feb-84 11:44:04-PST,3753;000000000000 Mail-From: MRC created at 2-Feb-84 11:43:01 Date: Thu 2 Feb 84 11:43:01-PST From: Mark Crispin Subject: Re: future of 36 bits To: HEDRICK@RUTGERS.ARPA cc: bosack@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Thu 2 Feb 84 13:31:30-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bravo Chuck! Why don't you read this as a statement during LSG Product Line in Cincinnati? [It can't be any later, as Rose Ann will probably take another early flight back to Massachusetts!] There is various talk about re-implementing TOPS-20 in various high-level languages (e.g. Pascal and Modula-2). The problem that I see is that it is the hardware vendors who are either developing the product or who are supporting the work. This is no good; the product will be proprietary to the hardware vendor. This is worthless. No matter how good it may be, it cannot compete with Unix. If the operating system must be proprietary, it should be owned by a vendor not locked into a particular hardware vendor. To compete with Unix, we must fight it in its own market place. Unix's vunerabilities as software are well-known. A portable TOPS-20, rethought to incorporate the past 15 years of human engineering science (e.g. natural pipes) would blow Unix out of the water in the software front. The problem is that the present world considers market considerations to be more important that human engineering. That makes sense. A Lisp'er probably sees Unix or TOPS-20 as something in the way of his Lisp. Individuals such as myself who live in the system software (and care a lot more about what the operating system is like) aren't the people who buy computers. What do you think about the following reasoning? . We, the research community, invented Unix. We also invented Tenex and hence TOPS-20. We are competant to undertake any operating system project, perhaps uniquely so. . Certain higher level languages are finally coming around to realize that certain programming constructs (e.g. co-routines) do exist and that assembly programming will exist as long as there is no higher level language that doesn't adequately support such constructs. The (valid) arguments for assembly programming in the past were: . assembly programming provides greater freedom for the programmer . a good programmer's productivity is not impaired by assembly programming, as he has to spend a significant amount of time working around limitations in the high level language . high level languages have too much overhead for real-time or other high performance applications . all too many system bugs turn out to be the compiler generating bad code Of these arguments, the last one seems to be the most powerful one today. C is the worst villian in this regard. . VMS is garbage. It will always be garbage, even if they make its interface identical to TOPS-20 5+ years in the future. VMS is written in assembly language or Bliss - the latter might as well be assembly language. . We the research community, not DEC or IBM or..., should write the portable TOPS-20. . It is in DEC's interest to support such an effort, including but not limited to financial support. When (I wouldn't say if) the project succeeds, DEC would have an interest in making sure we will provide this operating system for the VAX. It would not do for people to start panic-selling their VAXen for an IBM (or DG!!!) engine that runs the operating system everybody wants to run. ------- 2-Feb-84 19:15:05-PST,1157;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 2 Feb 84 19:14:53-PST Date: Thu 2 Feb 84 20:13:53-MST From: Norm Samuelson Subject: Future operating systems To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 An idea we have kicked around at times may someday be viable (I dont think it will be possible for another couple years at least, but it may not take too much longer than that. How about writing a good friendly high-performance flexible and TRANSPORTABLE operating system in ADA? If there ever was a language that had some hope of being both portable enough and powerful enough to do the job, ADA should be it. The research community (the ARPANET) would be the ideal place to develop such an operating system, with all the talent around, and all the existing knowledge of what is both good and bad about existing systems, coupled with availability of government funding to keep the product in the public domain. Is it worth a try? - Sam - ------- 3-Feb-84 00:44:13-PST,3208;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Feb 84 00:44:00-PST Date: Fri 3 Feb 84 03:45:22-EST From: John T. Wroclawski Subject: Re: future of 36 bits To: HEDRICK@RUTGERS.ARPA cc: bosack@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Thu 2 Feb 84 13:31:30-EST Even though I often wake up feeling like Chuck does, I think it is worth one more round of trying at this time. I offer the following reasons in support of this. 1) I am inclined to believe that Norm S. is right, and something better @i(is) coming down the road in two years. The whole model of computing is moving from "operating systems" to "total environments", ranging from the Apple Mac to the Symbolics 3600. Coupled with this is the idea of a true distributed computing environment, invisible to the user. Symbolics is darn close to that right now. The major problems with this vision currently are cost and "the inertia factor"; the first is already going away under the onslaught of volume production technology, and the second will fade as things like Macs/Dandelions/3600's become more common. UNIX really cannot hope to compete with this, since despite the efforts of some good people it is conceptually rooted in an earlier time frame. If you are really interested in the best available computing environment, it seems silly to switch to UNIX only get left behind again. The trick is to make it through the next few years, and a faster cheaper -10 might be a good way to do that. 2) A decision from DEC to build foonley's machines or whatever would to some extent require a recognition on the part of top management that the -20 and VAX product line do not totally overlap, that the people who want -20s see the alternative as IBM or UNIX on a non-DEC machine, and that DEC should do something to not lose these customers. Under these circumstances, one can (just barely) imagine them doing a machine in the $100K KL range, if a bigger one worked. A nice repackaged F4, say, with builtin ethernet and disk interface. DEC isn't so monolithic as it used to be. 3) If nothing else, a strong message at this time should at least cause DEC to push harder on short-term support of current KL-based sites, both in the areas of price reduction of currently available products and introductin of some useful stopgaps like the rumored 25%-speedup-for-not-much-money. Not to mention counteracting the apparent impression, put forth by some field reps, that all of us are just divinely happy with the current strategy. My understanding of all this is that lots of the pieces for doing a machine are in place, resulting in a deliverable product in a shorter time than you would expect. DEC management's decision on this will be made in the immediate future. Those customer opinions (apparently not all that many...) which were already received at DEC have had some effect. It's probably worth your time to add to the list... Ken Olsen 146 Main St. Maynard, MA 01754 ------- 3-Feb-84 11:58:31-PST,3363;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Feb 84 11:57:31-PST Date: Fri 3 Feb 84 12:56:36-MST From: Randy Frank Subject: Re: future of 36 bits To: HEDRICK@RUTGERS.ARPA, bosack@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Thu 2 Feb 84 13:31:30-MST My position is somewhere in the middle of those stated by Len and Chuck: We haven't rules out staying with a (future) DEC-20, but the machine will have to carry it's own weight. Namely, we are no longer willing to pay obscene amounts of money just because something runs Tops-20. Unfortunately, even if DEC decides now to do a replacement, I'm not optimistic that the above would be true. Every time recently DEC has had a chance to show thay maybe some sense had set it, I've seen no sign of it. Case in point: we've now been told tentative pricing on the ethernet interface for the 20 at about $19,000. Once again we have order-of-magnitude price differences between hardware for the 20 any almost anything else we are buying. We have basically decided this can't go on. A future 20 has to stand on its own as a cost-effective system to own. We won't buy it just because it's a 20. Likewise, the migration strategy to VMS puts us again at the mercy of a single vendor. Even if DEC does all the things to VMS thay say they'll do, if we move off Tops-20 in a major way it will be to a system such as Unix where no single vendor can hold us over a barrel. One of the more promising signs at the last Unix user's group meeting in DC is that a number of vendors are now producing VAX-class machines on which they've decided to port Berkeley 4.2 Unix instead of Bell System V. (At least DEC had the smarts to also adopt Berkeley Unix instead of System V for the Vax; it shows they still listen to customers on occasion). Assuming that Berkeley 4.2 and Bell System V are both the same "Unix" is roughly the same as saying both Tops-10 and Tops-20 are both the same "Tops" operating systems for the KL. Most of what makes Unix an possible alternative to Tops-20 are features in 4.2 but not in System V: multifork shells (execs), networking support, large scale virtual memory support, etc. At least in the case of migrating to Unix we're moving to a system with approximately the same kernel (monitor) power of Tops-20. Admitedly the user interface has major problems, but one can see solutions to these with a reasonable amount of effort. The work required the bring VMS up to something even remotely approximating Unix or Tops-20 is enormous, and given the other pressures on VMS development seem remote. Our potential reliance on Unix doesn't leave DEC out of our plans. Clearly the new Vax Venus is a strong contender for a good machine to run Unix. However, DEC must face the fact that, as far as we are concerned, the Venus had better be a machine that is aggressively priced relative to the other options for running Unix in its performance class. While price/ performance has usually been secondary to us relative to functionality, if "n" difference boxes all run the same version of the same operating system, all of a sudden price/performance starts to become a major consideration. Randy ------- 4-Feb-84 18:11:31-PST,827;000000000000 Mail-From: MRC created at 4-Feb-84 18:11:23 Date: Sat 4 Feb 84 18:11:23-PST From: Mark Crispin Subject: TCP: JFN close bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: With bugfix to not block in close wait if CZ%ABT set, rapid consecutive connections on the same host/port pairs hang when the second connection closes. Diagnosis: If the connection is closed via a CZ%ABT close, the TCDCW bit in the TCB is never cleared. A subsequent usage instance of that TCB will hang in "close wait" even though a CLOSE% was never done. Solution: Clear TCDCW if aborting. At TCPABT, insert: SETZRO TCDCW,(TCB) ;no more CLOSF% block before the ABORT%. ------- 5-Feb-84 16:32:51-PST,1224;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sun 5 Feb 84 16:32:36-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2622327972115938@MIT-MULTICS.ARPA>; 05 Feb 1984 19:26:12 est Date: 04 Feb 84 22:03 +0100 From: Per_Danielsson@QZCOM Reply-to: Per_Danielsson@QZCOM, TOPS-10/20_SIG@QZCOM To: TOPS-10/20_SIG@QZCOM, tops-20 , "Norm Samuelson" Subject: Future operating systems Message-ID: <40325@QZCOM> In-Reply-To: <40114@QZCOM> Writing operating systems in ADA has the drawback that ADA is not a interpretive language (perhaps an ADA-interpreter could be made?). For a really flexible and easy to use system you should be able to get at the functions in the operating systems fast and preferably as "commands" (or functions) in an interpreter. A Lispmachine is an excellent example of such a system, where the programming language and the operating system are integrated. There's really no reason why such systems could not be written for large time-sharing computers as well. (Text 40325)------------------------------ 7-Feb-84 14:38:50-PST,666;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 7 Feb 84 14:38:26-PST Date: Tue 7 Feb 84 14:41:23-PST From: William "Chops" Westfield Subject: Performance measuring tools. To: tops20@SU-SCORE.ARPA Does anyonw have tools for measuring performance of user programs, preferrably from a system demon job someplace? I have a version of Len Bosack's RBDIS.MAC, which is the kind of thing that I need, but I have been unable to get it to work properly under version 5, (Mostly because I dont understand wht it is doing). Has anyone updated this or similar programs ? Thanks Bill W ------- 10-Feb-84 14:27:13-PST,1386;000000000000 Mail-From: MRC created at 10-Feb-84 14:27:03 Date: Fri 10 Feb 84 14:27:02-PST From: Mark Crispin Subject: TOPS-20 "Runaway ACK" bug To: Chase@USC-ISIB.ARPA, TOPS-20@SU-SCORE.ARPA cc: Mills@USC-ISID.ARPA, ROODE@SRI-NIC.ARPA, Rudy.Nedved@CMU-CS-A.ARPA, Satz@SRI-NIC.ARPA, NIC-STAFF@SRI-NIC.ARPA, Dale@USC-ISIB.ARPA, ACTION@USC-ISIC.ARPA, JGoldberger@USC-ISIB.ARPA, Dougherty@USC-ISIB.ARPA, VGordon@USC-ISI.ARPA In-Reply-To: Message from "Dale Chase " of Fri 10 Feb 84 12:09:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: Sites complaining about being swamped with ACKs from TOPS-20. Solution: In TCPTCP.MAC, at the end of the PKZ23A routine, there is code which looks something like MOVEI T1,^D200 or MOVEI T1,TVTWTM CALL ENCPKT CALL ENCPKT In DDT, this will be at PKZ23A+12 - PKZ23A+13 on some systems; on other systems it will be at PKZ23A+6 - PKZ23A+7. This code should be changed to: MOVE T1,TVTWTM CALL DLAYPZ In addition, location TVTWTM should be changed to 60000. in DDT or by editing STG.MAC to change TVTWTM to ^D60000. Many sites have some portion of these changes. The fix should not be considered in effect until all of these changes are put in. ------- 10-Feb-84 15:03:47-PST,1035;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 10 Feb 84 15:03:43-PST Date: Fri 10 Feb 84 15:03:24-PST From: Kirk Lougheed Subject: bug in SU EXEC To: su-tops-20@SU-SCORE.ARPA This is a local bug that has to do with Stanford's password encryption scheme. It has been seen to bite privileged users on Sierra. The symptom is that directories are built with the CD%CRP (password is encrypted) bit set, yet their passwords are plaintext. Users are thus unable to login. The fix to EXEC4 is to make sure that a CRDIR% from the EXEC can never set CD%CRP. The only user program that should ever need to do so is DLUSER restoring a filesystem. CRSUB1: MOVE A,KREDIR ;GET POINTER TO NAME STRING MOVEI B,CRBLK IFN STANSW,< MOVX C,CD%CRP ;GET "PASSWORD IS ENCRYPTED" BIT ANDCAM C,.CDMOD(B) ;MAKE SURE IT IS CLEARED. >;IFN STANSW HLL B,Q1 ;XWD FLAGS, PARAMETER BLOCK ADDRESS MOVE C,CRPASS ;GET 0 OR POINTER TO PASSWORD ------- 13-Feb-84 11:09:03-PST,816;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Feb 84 11:08:52-PST Received: ID ; Mon 13 Feb 84 14:08:49-EST Date: Mon 13 Feb 84 14:08:45-EST From: Vince Fuller Subject: Extended addressing and PAGLCK BUGHLT's To: TOPS-20@SU-SCORE.ARPA I have been experiencing occaisional (about once a week) PAGLCK BUGHLT's which I believe are due to some bug in extended addressing. The reason for this conclusion is that the crashes typically occur a very short time after running a program of mine which runs in section 1 and maps files into sections 2 and above. Are there any unpublished fixes that anyone has for extended addressing problems? Any pointers, ideas, or suggestions would be appreciated. --Vince ------- 13-Feb-84 14:20:20-PST,757;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Feb 84 14:19:23-PST Date: 13 Feb 1984 1719-EST From: Alan H. Martin To: VAF at CMU-CS-C, TOPS-20 at SU-SCORE DTN: 231-4528 Mail-Stop: MR1-2/L14 Office-location: "MR1-2/M8 (By the cat posters)" Subject: Re: Extended addressing and PAGLCK BUGHLT's Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11991496900.34.659.26849 at DEC-MARLBORO> There is a cure for PAGLCK BUGHLTs caused by extended addressing in the 19-Jan-84 Large Buffer. Ask your local Software Specialist for the answer to SPR 20-19727. I can't promise that this is the definitive solution to your problem, but I hope it helps. /AHM -------- 13-Feb-84 16:05:36-PST,982;000000000001 Mail-From: MRC created at 13-Feb-84 16:05:28 Date: Mon 13 Feb 84 16:05:28-PST From: Mark Crispin Subject: Re: 5.3 crashes To: CC.Clive@UTEXAS-20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Mon 13 Feb 84 15:55:42-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: ILFPTE, ILMNRF crashes when system receives an IMP going down message from the IMP. Diagnosis: STKVAR CHKIBF isn't long enough; it is 20 (16 decimal) words or 80 characters long. The theoretical maximum length of the string is longer. The stack is trashed. Solution: Increase the CHKIBF STKVAR to at least 30 words. At CHKI7 in IMPDV.MAC, change STKVAR <> to STKVAR <>. Note that Score's monitor has a different message and being paranoid, I make its CHKIBF be 40 words. ------- 13-Feb-84 16:49:42-PST,887;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Feb 84 16:49:24-PST Received: ID ; Mon 13 Feb 84 19:48:52-EST Date: Mon 13 Feb 84 19:48:37-EST From: Vince Fuller Subject: ILMNRF in DTACH% code To: TOPS-20@SU-SCORE.ARPA Problem: ILMNRF BUGHLT during DTACH% JSYS. This problem has been around for a while, but it would appear that the 5.3 monitor hits it more often and thus it is more noticible. Diagnosis: LDTACH (in DTACH) references a STKVAR before setting it to anything. Since it expects a tty number to have been placed in the STKVAR, lower routines (in particular, STADYN) are rather surprised to find garbage. Solution: Move the MOVEM T2,LDATLN at LDTACH+21L up to LDTACH+3L. LDATLN is thus setup as expected in the literal at LDTACH+10L. ------- 13-Feb-84 16:54:08-PST,593;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Feb 84 16:53:55-PST Received: ID ; Mon 13 Feb 84 19:53:56-EST Date: Mon 13 Feb 84 19:53:55-EST From: Vince Fuller Subject: Wedged TCP connections To: TOPS-20@SU-SCORE.ARPA Does anyone know what the connections with JCN #'s like 0,-1 mean and how they come about existing? CMU-CS-C seems to gradually accumulate them and ABORT%ing them seems to have the unfortunate side effect of aborting the system with an INTNQ2 BUGHLT... --Vince ------- 13-Feb-84 23:13:33-PST,860;000000000000 Mail-From: G.DAIR created at 13-Feb-84 23:13:24 Date: Mon 13 Feb 84 23:13:24-PST From: Willis Dair Subject: interrupt at 20? To: TOPS-20@SU-SCORE.ARPA Phones: Work - (408) 984-4082; Home - (408) 923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 I just got this message from one of my users. Does anyone know where it comes from and what cause it? Willis ------- Date: Mon 13 Feb 84 18:58:42-PST From: Dan O'Neill Subject: wierdness Sender: D.ONEILL@SCU To: Dair@SCU Reply-To: Dan I was logging into the system from home and was promptly logged out under really strange circumstances. Just after NOTICE: was printed out and my login.cmd file did a systat on me the message "INTERRUPT AT 20" appeared on the screen. Next thing you know, I was logged out. ????? dan ------- 14-Feb-84 07:10:55-PST,876;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 14 Feb 84 07:10:47-PST Received: ID ; Tue 14 Feb 84 10:11:26-EST Date: Tue 14 Feb 84 10:11:24-EST From: Vince Fuller Subject: Re: interrupt at 20? To: G.Dair@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Willis Dair " of Tue 14 Feb 84 02:17:31-EST It means that the user's top fork died of an unhandled interrupt - probably an illegal instruction trap - at PC=20. The monitor trapped this and logged the job out, since there was nothing else it could do with the dead job. If the user had been priviliged, he would have been put in the Mini-Exec. The cause of this was probably the Exec trashing itself. Certain PCL problems are known to cause this occaisionally. --Vince ------- 14-Feb-84 12:49:38-PST,2490;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Tue 14 Feb 84 12:49:25-PST Date: 14 Feb 1984 15:46-EST Sender: CLYNN@BBNA Subject: TOPS-20 TCP exceedeing window From: CLYNN@BBNA To: TOPS-20@SU-SCORE Cc: Mills@USC-ISID, Braden@USC-ISI Message-ID: <[BBNA]14-Feb-84 15:46:02.CLYNN> Problem: TOPS20 TCP exceeds the send window. [When this happens and the foreign TCP discards packets that contain data exceeding the window, the packet will have to be retransmitted. This in turn causes the retransmission algorithm to back off. After a few iterations throughput approches of one packet per maximum retransmission interval (1 min). Frequent PUSHes would tend to get around the problem.] Diagnosis: When the TCP pacektizer holds a packet until the application program supplies more data, the available window space computation does not account for data already in the packet. Solution: In module TCPTCP.MAC, add the lines indicated with a star. PKTIZ3:SETSEC BFR,INTSEC ; Make extended address LOAD BUFCNT,TSBYT,(TCB) ; Get total (SEND) queued byte count PKTIZ4: * LOAD PKT,TSCPK,(TCB) ; May have partially filled packet ; Force our idea of the availble window space to 0 if we cannot send ; data but have to generate only an ACK. LOAD T1,TSSYN,(TCB) ; Send state LOAD T2,TRSYN,(TCB) ; Receive state CAIE T1,SYNABL ; If send side is SYNABL or CAIN T2,SYNABL ; Recv side is SYNABL then JRST PKTIZ5 ; Make useable window 0 ; 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 SUB T1,T2 ; Minus Sequence ------------------------------------------------------------ CAIN T1,TCBSBQ(TCB) ; Is the queue empty? CALL SNDFIN ; Include a FIN in this packet PKTZ16: ; PFIN is 1, TSSYN=FINSNT, DG scheduled ; if R=NOTSYN * ; Now all control and data have been stored in the packet. * * CALL PKTEND ; Returns next seq num after this Pkt * STOR T1,PESEQ,(PKT) ; Save computed end of packet * ; If we are ACKing a remote FIN, the receive side becomes NOTSYNCHED. ------ 14-Feb-84 13:04:50-PST,920;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Tue 14 Feb 84 13:04:37-PST Date: 14 Feb 1984 12:04-EST Sender: CLYNN@BBNA Subject: Re: Wedged TCP connections From: CLYNN@BBNA To: VAF@CMU-CS-C Cc: TOPS-20@SU-SCORE Message-ID: <[BBNA]14-Feb-84 12:04:35.CLYNN> In-Reply-To: The message of Mon 13 Feb 84 19:53:55-EST from Vince Fuller Vince, JCNs 0,,-1 are created when some job, such as the ftp control program (FTSCTT), does an ATNVT% JSYS to attach an open TVT connection to a TVT. The INTNQ2 BUGHLT is the result of trying to remove some item form some queue when the item is not really in any queue. What process is doing the ABORT%ing (c(FORKX)=c(INTFRK)?)? Is there a DUMP.CPY/MONITR.EXE available? The queue entry of the item is in T1; is it near TCB, PKT, BFR? The caller can be found by looking back up the UPDL stack. Charlie 15-Feb-84 11:08:21-PST,2017;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Wed 15 Feb 84 11:08:02-PST Date: 15 Feb 1984 1012-PST From: Ted Shapin Subject: SED Editor Bug To: tops20@SU-SCORE.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 This bug is apparently in all versions of Chris Hall's SED editor up to Nov 83. When a user gave a search string longer than 40 characters, some memory locations were being overwritten, which caused problems with the pick, slide, and change case commands. This is because these commands' storage locations at PICKLN:, PICKSP:, SLIDES:, CASSPS:, and CASLNS: immediately follow the search string storage location at SRCKEY: where there is only allocated enough storage for 40 characters. The storage location PICKLN: is used for the number of lines to pick. When the user would give a search string longer than 40 characters, the 41st through 45th characters of the search string would be in PICKLN: and under certain conditions the pick command would pick s until the user's directory was out of space because the nnnPIK.TMP file would be growing from the infinite loop created by the bad data in PICKLN:. This occurred only when the 41st character of the search string was less than an octal 100 (an @ sign) and the user would then give the pick command. CHANGES TO SED CODE TO FIX BUG ------------------------------- Change from: SRCKEY: BLOCK 10 Change to: SRCKEY: BLOCK 40 Change from: SROKEY: BLOCK 10 Change to: SROKEY: BLOCK 40 Change from: SUBSTG: BLOCK 10 Change to: SUBSTG: BLOCK 40 Change from: RECSC1: BLT T1,PARBUF+7 Change to: RECSC1: BLT T1,PARBUF+37 Change from: SUBSRC+1: BLT T2,SROKEY+7 Change to: SUBSRC+1: BLT T2,SROKEY+37 Change from: SRGTKY+1: BLT T1,SROKEY+7 Change to: SRGTKY+1: BLT T1,SROKEY+37 Howard C. Hoagland ------- 16-Feb-84 13:11:20-PST,779;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Feb 84 13:10:42-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623256738786884@MIT-MULTICS.ARPA>; 16 Feb 1984 13:25:38 est Date: 15 Feb 84 01:46 +0100 From: KPJ_Jaakkola_QZ@QZCOM Reply-to: KPJ_Jaakkola_QZ@QZCOM, TOPS-10/20_SIG@QZCOM To: TOPS-10/20_SIG@QZCOM cc: tops-20 Subject: interrupt at 20? Message-ID: <41915@QZCOM> In-Reply-To: <41882@QZCOM> Top fork stops at address 20, either due to a HALTF% or an error. Job lacks privileges, monitor Mini-EXEC (MEXEC) displays the message, and logs out the job. (Text 41915)------------------------------ 16-Feb-84 15:40:04-PST,411;000000000000 Mail-From: G.ELDRE created at 16-Feb-84 15:39:45 Date: Thu 16 Feb 84 15:39:45-PST From: Tim Eldredge Subject: Tape Reading programs To: tops-20@SU-SCORE.ARPA Does anyone have a program that will read binary data written on an IBM system? I have a tape with a mixture of binary and EBCDIC fields on it and I need the data. Any pointers would be appreciated. Thanks ------- 19-Feb-84 13:54:30-PST,1322;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 18 Feb 84 22:51:55-PST Date: Sat 18 Feb 84 22:51:51-PST From: Kirk Lougheed Subject: Etherlpt support and '#' To: su-tops-20@SU-SCORE.ARPA Another piece of software that breaks when '#' is removed as a valid filename character is the EtherLPT support in the LPTSPL used by (at least) LOTS, GSB, and Sierra. A destination EtherLPT is specified by giving a logical name such as LOTSB: to the /DEVICE: switch in OPR. LOTSB: expands to something like the following PUP:!J.60#2#3 The TAPGET routine in LPTSPL used to take LOTSB: and expand it correctly. Removing '#' as a non-special character causes the GTJFN% internal expansion of that logical name to break on the '#'. Nothing much useful happens beyond that point. I have installed code in LPTSPL to expand the logical name string and to insert CTRL-V's in front of the #, !, and + characters. The modified LPTSPL appears to work correctly for PLPT's and EtherLPT's. Note that if you are running EtherLPT service you will have to run this LPTSPL and fix your EtherLPT logical names when you install the latest monitor with '#' support removed. The source is SRA:<4-2-GALAXY>LPTSPL.MAC. Kirk ------- 19-Feb-84 15:32:34-PST,636;000000000000 Mail-From: MRC created at 19-Feb-84 15:32:15 Date: Sun 19 Feb 84 15:32:15-PST From: Mark Crispin Subject: new MMailr To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have just fixed a long-standing bug in MMailr which can cause it to hang if two of the MMailr processes try to generate a return message at the same time. This is relatively infrequent, but it has happened. The new version is on MRC:MMAILR.MAC. You'll need the latest DEC TCP and all of Stanford's fixes to run it. ------- 21-Feb-84 08:19:28-PST,2511;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Feb 84 08:19:08-PST Date: 21 Feb 84 11:19:07 EST From: Charles Hedrick Subject: Arpanet security proposal To: tops-20@SU-SCORE.ARPA A month or so ago, the DDN management bulletin suggested DCA was considering enforcing some security policies on all Arpanet hosts. I asked DCA what was going on, and got a very thoughtful response from GPark. It said, in effect, that DCA was trying to keep the gateway between the Arpanet and DDN open, and that to do so, some moderate security on the Arpanet seems to be needed. I am wondering what other people think about this? I agree - that the password control policies proposed are quite reasonable, given that one wants to maintain some security - that DDN should have security My problem is that I am not entirely sure that I want to do anything of this sort on my systems. Note also that eventually Rutgers is likely to have almost all of our machines networked, and there will surely be some sort of gateway to the Arpanet. So potentially we end up having DCA controlling security policies on all of our systems. The problem is that up to now, I have tried to keep as close to the old AI Lab philosophy as I thought I could get away with within a traditional computer center. We pay as little attention as possible to security. My highest priority is to maintain a friendly relationship with my users. I will do almost anything necessary to avoid the sort of escalating battles between staff and hackers that can occur when one tries to keep tight security. There are known security holes on our systems, and I quite honestly do not care. The issues are: - can I really get away with this? Are there now too many hackers in the world for it to be safe, or too many bureacrats around me? I confess that I find myself out of tune even with some of my own staff on this. E.g. some of them have already started implementing the recommended policies on one of the systems. - do other universities agree? - given a choice between a free Arpanet/DDN gateway and a free Arpanet, which should we choose? I am quite tempted to say that I would like to resist any additional security measures. If this means constructing a wall between Rutgers and the Arpanet (e.g. passwords for outgoing connections) or between the Arpanet and DDN, I think I might prefer that. ------- 21-Feb-84 16:38:43-PST,1191;000000000000 Return-Path: <@Ucl-Cs.ARPA:Michael_Walsh__Univ._College_Dublin@Qzcom.SWEDEN> Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Tue 21 Feb 84 16:38:14-PST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 22 Feb 84 0:35 GMT Via: QZCOM; Date: Tuesday, 21-Feb-84 21:05:46-GMT Date: 21 Feb 84 13:25 +0100 From: Michael_Walsh__Univ._College_Dublin%qzcom@ucl-cs.arpa Reply-to: Michael_Walsh__Univ._College_Dublin%qzcom@ucl-cs.arpa, TOPS-10/20_SIG%qzcom@ucl-cs.arpa, Tops-20_ To: TOPS-10/20_SIG%qzcom@ucl-cs.arpa, tops20 cc: Tops-20_ Subject: DN20 crashes. Message-ID: <42872@QZCOM> We are having problems with a DN20 continually crashing. DN20 stop bufinf, followed by DTELPI. The DEC20 configuration is 2060 with V5.1, Galaxy 4.2. The link is a 2780 to RSCS V3.0 with VM/SP v2.1. The same problem is found at one other site. As yet, we have no diagnosis or fix. Has anyone seen this, and perhaps, have a fix? 22-Feb-84 00:31:47-PST,1082;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Feb 84 00:31:35-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623690165275187@MIT-MULTICS.ARPA>; 21 Feb 1984 13:49:25 est Date: 21 Feb 84 13:25 +0100 From: Michael_Walsh__Univ._College_Dublin@QZCOM.MAILNET Reply-to: Michael_Walsh__Univ._College_Dublin@QZCOM.MAILNET, TOPS-10/20_SIG@QZCOM.MAILNET, tops20_%_SU-SCORE.ARPA@QZCOM.MAILNET To: TOPS-10/20_SIG@QZCOM.MAILNET, tops20_%_SU-SCORE.ARPA@QZCOM.MAILNET cc: tops-20 Subject: DN20 crashes. Message-ID: <42872@QZCOM> We are having problems with a DN20 continually crashing. DN20 stop bufinf, followed by DTELPI. The DEC20 configuration is 2060 with V5.1, Galaxy 4.2. The link is a 2780 to RSCS V3.0 with VM/SP v2.1. The same problem is found at one other site. As yet, we have no diagnosis or fix. Has anyone seen this, and perhaps, have a fix? 22-Feb-84 11:30:30-PST,925;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Feb 84 11:30:15-PST Date: Wed 22 Feb 84 11:30:14-PST From: Kirk Lougheed Subject: BBN interface oddity To: tops-20@SU-SCORE.ARPA Behavior: The BBN interface stores BBN error codes in LSTERR in addition to returning the error code in user AC1. Under such conditions ERSTR% takes a +1 failure return, however GETER% will return the error code. Question: Is this the desirable or intended behavior? Replacing the RETERR macro at TCPERO+1 with "JRST EMRET1" causes the BBN code to leave LSTERR alone. Are there any user programs that take advantage of this side effect of the BBN interface? We noticed this behavior when the TCP: interface started returning the occasional BBN error code instead of a normal JSYS error code. Kirk ------- 22-Feb-84 13:02:34-PST,643;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Feb 84 13:02:23-PST Date: 22 Feb 1984 16:00-EST Sender: CLYNN@BBNA Subject: Re: BBN interface oddity From: CLYNN@BBNA To: Lougheed@SU-SIERRA Cc: tops-20@SU-SCORE Message-ID: <[BBNA]22-Feb-84 16:00:44.CLYNN> In-Reply-To: The message of Wed 22 Feb 84 11:30:14-PST from Kirk Lougheed Placing of BBN TCP interface error codes in LSTERR is not intentional. Since it was not documented as happening, there should not be any programs which use it. The problem will be fixed; thanks for reporting it. Charles Lynn 22-Feb-84 18:30:35-PST,994;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Feb 84 18:30:26-PST Date: 22 Feb 1984 2128-EST From: -MH- To: "Michael_Walsh__Univ._College_dublin@QZCOM.MAILNET" at SU-SCORE cc: Tops-20 at SU-SCORE Reply-to: Hovsepian at DEC-MARLBORO DECnet-address: "Hovsepian@Market" Telephone: "(213)647-9817 HAC, (213)417-4240 DEC" Subject: Re: DN20 crashes. Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11993901373.11.396.27181 at DEC-MARLBORO> Regarding: Message from Michael_Walsh__Univ._College_Dublin@QZCOM.MAILNET of 21-Feb-84 1325-EST In-reply-to: <42872@QZCOM> I would be very surprised if this problem was not modem related. The DTELPI happens when the DTE loses a PI assignment, but I'll bet that if you fiddle with (raise it) the clear-to-send-delay setting and verify that your modems are half-duplex and strapped properly, your link will stay up. -------- 27-Feb-84 02:15:52-PST,1444;000000000000 Mail-From: MRC created at 27-Feb-84 02:15:43 Date: Mon 27 Feb 84 02:15:43-PST From: Mark Crispin Subject: TCP: GTJFN% bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: Attempt to use the same local port when running the same application to the same foreign host consecutively. Connection is rejected because the former connection's TCB hasn't expired yet. Diagnosis: Using the JFN as a unique number in local port generation isn't good enough. Solution: Create a new global symbol JOBUNI for "job unique number". Put it in GLOBS.MAC, and add it in STG.MAC any place in the JSB. This cell, accessed by AOS ac,JOBUNI is guaranteed to return unique values for the duration of the job. For TCP purposes it will wrap around every 64 TCP: GTJFN%'s which hopefully will suffice. In TCPJFN.MAC, remove the following lines in front of TCPST2: MOVE T1,JFN ;get the JFN IDIVI T1,MLJFN ;get the JFN number CAIGE T1,<1B<35-6>> ;legitimate JFN? JRST TCPST2 ;yes BUG.(CHK,TCPJTB,TCPJFN,SOFT,) RETBAD(TCPX29) ;return an error TCPST2: At HSTPR5, replace MOVEI T2,(JFN) ;get the jfn IDIVI T2,MLJFN ;get the jfn number with AOS T2,JOBUNI ;get next unique number for this job ANDI T2,77 ;only last 6 bits please ------- 27-Feb-84 09:58:32-PST,1333;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 27 Feb 84 09:58:20-PST Date: Mon 27 Feb 84 12:58:26-EST From: Chris Maio Subject: TCP: jfns and ILMNRF bughlts To: Tops-20@SU-SCORE.ARPA Problem: ILMNRF bughlts caused by opening a TCP: jfn that was obtained by passing an invalid filespec to GTJFN. Repeat-by: Open a jfn obtained with "TCP:.-79", e.g. a connection to a finger server where the host name or number has been omitted. Diagnosis: When HSTPRT(TCPJFN) is called to parse the name and extension fields of an invalid TCP: filespec, it may return negative host numbers, which GTJFN then stores into the TCB associated with the JFN. Assuming that the Stanford TCPJFN patches have been installed, OPENF then passes the negative host number to HSTHSH(MNETDV), which winds up indexing into section 6 and causing an ILMNRF bughlt. Solution: At HSTPR2+11 in TCPJFN.MAC, insert the line marked with "*" below: HSTPR2: ... MOVE T1,HSTPT1 ;get the initial pointer MOVEI T3,10 ;octal number NIN ;attempt to read host number ERJMP HSTPR3 ;hmmm. not number. must be a string * JUMPLE T2,R ;CU124 Host number must be positive MOVEM T2,HSTPHN ;save the host number ... - Chris ------- 27-Feb-84 16:53:15-PST,2097;000000000000 Mail-From: MRC created at 27-Feb-84 16:52:59 Date: Mon 27 Feb 84 16:52:59-PST From: Mark Crispin Subject: TCP: hanging bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: Strange behavior from TCP: SIN%. Data which is indicated to be available by SIBE% is unavailable to SIN%. Truncated data from SIN%. This behavior is especially noticed after having opened, read, and closed a small disk file and then getting that same JFN number when GTJFN%'ing TCP: (e.g. having a TELNET.CMD file!). Diagnosis: TCPJFN doesn't implement the device driver interface to IO correctly. A device driver is expected to set up a "file length", a "current byte number", and a "input buffer byte count". If the "file length" minus the "byte number" is greater than the "byte count", the "byte count" is truncated by IO to match the results of this function. TCPJFN doesn't set up the "file length" at all; it is left at some totally random value. TCPJFN thinks that zeroing the "byte number" after each buffer is alright to work around it; it is only if the random "file length" is a suitably large number". Solution: Make TCPJFN implement "file length"; this is a running total of all the "byte counts" in all the buffers it has had. Remove the bogon which cleared the "byte number" (not the byte count as mislabelled in the comment). The "byte number" is now the total number of bytes read on that connection, a useful value that can be read by RFPTR% and reported by INFORMATION FILE-STATUS. In TCPJFN.MAC, at TCPOP3-5 or thereabouts, insert: SETZM FILLEN(JFN) ;initially zero length At TCSQI2+6, after the MOVEM T1,FILBCI(JFN), insert: ADDM T1,FILLEN(JFN) ;update file length At TCSQI3-3L, remove: SETZM FILBNI(JFN) ;save new byte count I've been scratching my head over this bug for ages; a variant of it existed in NCP as well. I'm glad it's finally fixed. ------- 27-Feb-84 17:28:18-PST,835;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 27 Feb 84 17:28:09-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2624232244046280@MIT-MULTICS.ARPA>; 27 Feb 1984 20:24:04 est Date: 25 Feb 84 11:08 +0100 From: Bertil_Hansson_ADB/SU%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bertil_Hansson_ADB/SU%QZCOM.MAILNET@MIT-MULTICS.ARPA, Speakers_corner%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Speakers_corner%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, tops-20 Subject: Astrology. Message-ID: <43472@QZCOM> Is there anyone out there who has seen some good astrology software for TOPS or Berkeley UNIX? 28-Feb-84 11:25:16-PST,1119;000000000000 Return-Path: Received: from yale by SU-SCORE.ARPA with TCP; Tue 28 Feb 84 11:24:56-PST Received: by YALE-BULLDOG via CHAOS; Tue, 28 Feb 84 14:22:20 EST Date: Tue, 28 Feb 84 14:19:20 EST From: John R Ellis Subject: Trivial batch question To: tops-20@SU-SCORE.ARPA A batch job that I run frequently once got this logout message: 0:32:52 MONTR Killed Job 29, User C.S.ELLIS, Account Q, TTY 220, 0:32:52 MONTR at 28-Feb-84 00:32:52, Used 0:59:04 in 2:08:05, 0:32:52 MONTR Used this session 0:16:06 in 0:32:37 This is the only time I've ever seen the "Used this session" line. Other executions of the job produce the normal logout message. Looking at the code in MEXEC that prints the "Killed Job" message, I find: SKIPN JSSRTM ;Session start SKIPE JSSCTM ; at beginning of job? SKIPA ;No-- print time this session JRST LOGUS2 ;Yes-- don't repeat ourselves So what would cause a batch job to "randomly" change sessions in the middle? ------- 28-Feb-84 13:13:44-PST,640;000000000000 Mail-From: MRC created at 28-Feb-84 13:13:32 Date: Tue 28 Feb 84 13:13:32-PST From: Mark Crispin Subject: Re: Trivial batch question To: Ellis@YALE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "John R Ellis " of Tue 28 Feb 84 11:25:20-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Well, your log file indicates that the session change happened at midnight (0:32:52-0:32:37 allowing for fuzz on the seconds). This strongly implies that your system has an accounting shift at midnight. ------- 28-Feb-84 13:16:18-PST,444;000000000000 Return-Path: Received: from SRI-NIC by SU-SCORE.ARPA with TCP; Tue 28 Feb 84 13:15:52-PST Date: Tue 28 Feb 84 13:17:05-PST From: David Roode Subject: Re: Trivial batch question To: Ellis@YALE, TOPS-20@SU-SCORE Location: EJ286 Phone: (415) 859-2774 You can define shift changes in the CONFIG.CMD file. At shift changes, session entries are automatically generated for all logged in jobs. ------- 28-Feb-84 13:28:16-PST,979;000000000000 Return-Path: Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Feb 84 13:28:04-PST Date: 28 Feb 1984 16:28-EST Sender: DIPACE@BBNF Subject: Re: Trivial batch question From: DIPACE@BBNF To: Ellis@YALE Cc: tops-20@SU-SCORE Message-ID: <[BBNF]28-Feb-84 16:28:18.DIPACE> In-Reply-To: The message of Tue, 28 Feb 84 14:19:20 EST from John R Ellis Notice that the time of the job is 00:32:52 and time used this session is 32:57 ? You system did a shift change at midnight. The accounting file is closed "cleanly" every shift change so that the data is self contained and can be processed without waiting for some trailing logout to match some login record. A "pseudo" logout-login is done for all logged in jobs when the shift change occurs. This also helps at sites that may have different prices for different shifts, since the cpu time used on each shift is split correctly. Hope this helps, Frank DiPace 28-Feb-84 13:47:49-PST,716;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Feb 84 13:47:40-PST Date: 28 Feb 1984 1639-EST From: -MH- To: Ellis at YALE, tops-20 at SU-SCORE Reply-to: Hovsepian at DEC-MARLBORO DECnet-address: "Hovsepian@Market" Telephone: "(213)647-9817 HAC, (213)417-4240 DEC" Subject: Re: Trivial batch question Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11995421653.12.396.9795 at DEC-MARLBORO> Regarding: Message from John R Ellis of 28-Feb-84 1428-EST Look at the time stamp on your log file, your system did a shift change (at midnight) while your batch job was running. -------- 1-Mar-84 00:13:09-PST,2093;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.BILL@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 1 Mar 84 00:12:54-PST Received: from CU20B by CUCS20 with DECnet; 1 Mar 84 03:12:42 EST Date: Thu 1 Mar 84 03:11:51-EST From: Bill Schilit Subject: Carrier off crashes system To: tops-20%SU-SCORE@COLUMBIA-20.ARPA date: 1-MAR-84 System Program: MONITR(MEXEC,FILMSC) submitted: B. Schilit phone: (212) 280-3538 Key Phrase: Carrier off action often crashes the system. Problem/Diagnosis: Recently we have had a number of crashes following a carrier loss on a line, when the user re-attaches to his job. Some of these crashes indicate that JOBCOF(MEXEC) is not saving registers. One recent crash, MDDJFN, was caused when JOBCOF called LDTACH called TTYDAS called CHKDES which changed the value in DEV. When the user re-attached, this fork called GETFDB which assumed that DEV was still setup for the JFN (with DSKDTB) -- but unfortunately TTYDTB had got in there. The result was the MDDJFN BUGHLT, trying to get an FDB on a non-directory device. Cure: Save DEV at the entry to JOBCOF, better yet, save everything at the entry to JOBCOF. Included here is an older patch to save register CX, which was also being destroyed. JOBCOF::SKIPGE SLOWF ;IN JSYS CONTEXT? JRST [ MCENTR ;NO, GET THERE PUSH P,[IFIW!MRETN] ;SETUP RETURN JRST .+1] PUSH P,CX ;CU47 Save CX (SE1ENT destroys it) SE1ENT ;GET INTO SECTION 1 POP P,CX ;CU47 Get CX back, and really save it. SAVEAC ;CU47 SAVEAC in section zero would cause ;CU47 JOBCOF to return in section zero ;CU91 SAVET ACSAV ;CU91 Save everything, DEV as well, since ;CU91 LDTACH->TTYDAS->CHKDES changes it. - Bill ------- 4-Mar-84 00:20:19-PST,619;000000000000 Mail-From: G.FUSSELL created at 4-Mar-84 00:20:11 Date: Sun 4 Mar 84 00:20:11-PST From: Carl Fussell Subject: emacs and clones.... To: tops20@SU-SCORE.ARPA Address: Santa Clara University This question should be directed to some sort of editting mailing list but I do not know if one exists... Does any sort of Emacs-like editor or clone exist that runs on PDP-11's? In particular, one that would run under RT11. If such an 'animal' exist and anyone knows of it, I would very much appreciate hearing about it. Thanx for any information.... Carl ------- 4-Mar-84 17:05:47-PST,806;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Sun 4 Mar 84 17:05:37-PST Date: Sun 4 Mar 84 18:05:34-MST From: Norm Samuelson Subject: Re: emacs and clones.... To: G.FUSSELL@SU-SCORE.ARPA, tops20@SU-SCORE.ARPA In-Reply-To: Message from "Carl Fussell " of Sun 4 Mar 84 01:22:26-MST Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 We have an emacs clone that runs on PDP-11s. We had to modify it to run under RSX-11. I think it was written for RT-11. Contact Tom Brengle or Dan Jones (Brengle%lll@LLL-MFE or Jones%lll@LLL-MFE) for more info on where we got it and what it was really written for, etc. - Sam - ------- 5-Mar-84 08:20:20-PST,541;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 5 Mar 84 08:20:11-PST Date: Mon 5 Mar 84 09:19:23-MST From: Randy Frank Subject: TCPJFN ACJ Call bug To: TOPS-20@SU-SCORE.ARPA Symptom: various hung job problems after a job fails on a TCP open due to ACJ not allowing open. Analysis: JFN for TCP: is locked Cure: RETERR on ACJ failure should be a RETBAD so that calling code can clean up jfn block and unlock it before issuing failure return to user. ------- 5-Mar-84 12:51:36-PST,799;000000000000 Return-Path: Received: from AFSC-HQ.ARPA by SU-SCORE.ARPA with TCP; Mon 5 Mar 84 12:51:26-PST Date: Mon 5 Mar 84 15:49:48-EST From: Stephen M.King Subject: Security!! Need some help. To: tops20@SU-SCORE.ARPA Postal-address: HQ AFSC/ACDPS, Andrews AFB, DC 20334 Phone: (301)981-4002; AUTOVON: 858-4002 System Managers, We've been following someone (off and on) trying to breach our system (didn't make it). OSI came over today and asked if I could provide some info. The 'user' was attempting to login as J.JAB and CUSP. It would be appreciated if whichever system manager recognizes these directory names please get back to me ASAP... so I can pass onto my hired killers. Thanks. Steve King System Manager @ AFSC-HQ ------- 5-Mar-84 13:35:53-PST,471;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.BILL@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 5 Mar 84 13:35:43-PST Received: from CU20B by CUCS20 with DECnet; 5 Mar 84 16:33:50 EST Date: Mon 5 Mar 84 16:32:36-EST From: Bill Schilit Subject: SCRIBE device query To: TOPS-20%SU-SCORE@COLUMBIA-20.ARPA Does anyone out there have SCRIBE working with the XEROX MemoryWriter 620 series of typewriter/terminals? - Bill ------- 6-Mar-84 06:09:08-PST,826;000000000000 Return-Path: Received: from yale by SU-SCORE.ARPA with TCP; Tue 6 Mar 84 06:08:59-PST Received: by YALE-BULLDOG via CHAOS; Tue, 6 Mar 84 09:07:35 EST Received: from YALE-RING by YALE-RES via CHAOS; Tue, 6 Mar 84 09:07:43 EST Subject: DEC 2060 for sale Date: Tue, 6 Mar 84 09:07:54 EST From: Jim Philbin To: Tops-20@SU-SCORE.ARPA cc: INSEAD (European Institute for Business Administration) is in the process of selling a DECSYSTEM 2060 configured as follows: Model B, 512K memory, 48 TTY ports, 1 RP06, 1 TU45 Interested parties should contact M. Pierre-Yves Saint-Oyant Computer Center INSEAD Fontainebleau, France Tel: (6) 422-4827 Telex: 690389F 6-Mar-84 15:47:03-PST,1266;000000000000 Mail-From: MRC created at 6-Mar-84 15:46:22 Date: Tue 6 Mar 84 15:46:22-PST From: Mark Crispin Subject: more 36 bit follies To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I just received this disgusting advertising poster in the mail from DEC. It says "THINK BIG [with BIG in 5 inch high letters] For the first time, Digital brings together the power of mainframe and VAX resources in special systems packages." It goes on to call a VAX-11/780 a "superminicomputer" but otherwise just blathers about the price reductions announced at DECUS last fall. The really obscene thing about it though is that in the picture, there is a closeup of a VAX with a 20 in the background. The VAX is made to look physically much larger than the 20. There is a man holding a printout and looking at it, apparently walking with great haste from the 20 to the VAX. Also in the news, Ken Olson has officially and finally decided (as opposed to tenatively) that Digital will NOT build any more 36 bit processors. Apparently this precludes DEC acquiring the rights for the F1 as well. And so it goes. ------- 6-Mar-84 23:13:00-PST,1729;000000000000 Mail-From: MRC created at 6-Mar-84 23:12:47 Date: Tue 6 Mar 84 23:12:47-PST From: Mark Crispin Subject: the future? To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The following is inspired by Tuesday's final decision by DEC to cancel 36 bit CPU's: "Hey, what's that new computer over there?" "I don't know. Let's look. Gee, it's friendly." "Oh, it MUST be a Dinosaur!" Dinosaur Industries announces a new series of 36 bit systems, completely compatible with DEC's discontinued DECsystem-10 and DECSYSTEM-20. Three models are offered: the 10 MIPS 3+ megaword Brontosaurus, the desk-top Pterodactyl, and the very aggressively priced medium-sized Tyrannosaurus. "Tyrannosaurus is our price-performance leader," said X, V-P of Marketing. "While our entire product line is competitively priced, Tyrannosaurus is aimed directly at DEC's VAX. We are committed, now and in the future, to remain the price/performance leader." All three models are available for immediate delivery, X added. Bundled with each Dinosaur is DINOS, which is Dinosaur's licensed version of TOPS-20. "DINOS is only an interim operating system," X stated. "We recognize our customers' reluctance to continue using non-portable operating systems. Our Engineering group is developing a portable operating system which is upwards compatible with DINOS, and in fact is running it in-house now." X declined to state the name of the new OS or details, but informed sources say it is called PortosaurOS and includes a Unix emulator. ------- 7-Mar-84 01:12:32-PST,448;000000000000 Return-Path: <@MIT-MC:EGK@MIT-OZ> Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 7 Mar 84 01:12:23-PST Date: Wed 7 Mar 84 04:12:04-EST From: Edjik Subject: A limerick for those 36 bit Blues (and oranges!) To: Tops-20@SU-SCORE.ARPA There was a nasty old man named Ken Who hated the PDP-10 He killed em with his Axe Then tried to sell us a VAX But we'd sooner have a fast IBM! --Edjik ------- 9-Mar-84 16:25:52-PST,616;000000000000 Mail-From: JPBION created at 9-Mar-84 16:15:16 Date: Fri 9 Mar 84 16:15:16-PST From: noiB .P leoJ Subject: Front end floppies To: tops-20@SU-SCORE.ARPA Does anyone out there have a program to FORMAT (i.e., not "INI") a floppy for use by the front end? I have a set of IBM 3740, single density floppies which INI complains about as being "Not ready" when I try to initialize them. Do I have floppies with the wrong format; I have been told that this is the correct format, but my source may have been mistaken. Thanks for any help in this problem! -Joel ------- 9-Mar-84 16:53:58-PST,705;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Fri 9 Mar 84 16:53:37-PST Date: Fri 9 Mar 84 18:54:07-CST From: Clive Dawson Subject: New micro code release To: tops-20@SU-SCORE.ARPA Out of curiosity, how many people who have received the new microcode release for the KL got TWO copies of the floppy and of the tape in the package? I know of two sites besides mine that experienced this. The folks at the SDC may have discovered a new method to enable them to claim increased througput! Clive P.S. Has anybody installed it? There were some SPR's in a recent dispatch which alluded to problems... ------- 9-Mar-84 18:11:32-PST,652;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 9 Mar 84 18:11:22-PST Received: ID ; Fri 9 Mar 84 21:11:47-EST Date: Fri 9 Mar 84 21:11:46-EST From: Vince Fuller Subject: Re: New micro code release To: CC.Clive@UTEXAS-20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Fri 9 Mar 84 20:15:51-EST I got two complete copies of everything - floppies, tapes, installation guide, etc. but one cover letter. I did install it, and haven't seen any problems that might be attributed to it. --Vince ------- 9-Mar-84 20:43:15-PST,771;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Fri 9 Mar 84 20:43:04-PST Date: Fri 9 Mar 84 23:45:09-EST From: Ken Rossman Subject: Re: Front end floppies To: JPBion@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "noiB .P leoJ " of Fri 9 Mar 84 19:42:26-EST Address: 716 Watson Labs, 612 W.115th St, NY, NY 10025 Phone: (212) 280-3703 I am not completely sure about this, but if you compare the IBM floppies with DEC floppies that do work as FE floppies, I think you'll see that the "synchronization hole" (that an optical sensor uses to figure out degree of rotation of the disk) is located in different places on each disk. /Ken ------- 9-Mar-84 20:45:18-PST,646;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Fri 9 Mar 84 20:45:05-PST Date: Fri 9 Mar 84 23:47:13-EST From: Ken Rossman Subject: Re: New micro code release To: VAF@CMU-CS-C.ARPA, CC.Clive@UTEXAS-20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince Fuller " of Fri 9 Mar 84 21:15:44-EST Address: 716 Watson Labs, 612 W.115th St, NY, NY 10025 Phone: (212) 280-3703 Don't remember whether we received two copies, but we've been running the new microcode on one of our machines here and have seen nothing unusual. ------- 10-Mar-84 12:14:58-PST,698;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sat 10 Mar 84 12:14:40-PST Date: 10 Mar 84 15:13:47 EST From: Charles Hedrick Subject: seeing double To: tops-20@SU-SCORE.ARPA We got two complete shipments of the new microcode, each of which contained two copies of the floppy and documentation tape. This was not just a simple packaging error, because the bill of materials showed that there were supposed to be two copies. I have no explanation for why we got two shipments. I think we eventually ended up with two copies of 5.1 source also. Since this includes an RP06 for us, we aren't complaining! ------- 10-Mar-84 13:06:07-PST,1192;000000000000 Return-Path: Received: from yale by SU-SCORE.ARPA with TCP; Sat 10 Mar 84 13:05:52-PST Received: by YALE-BULLDOG via CHAOS; Sat, 10 Mar 84 16:05:16 EST Date: Sat, 10 Mar 84 16:00:27 EST From: John R Ellis Subject: SYSDPY To: Tops-20@SU-SCORE.ARPA Our version of SYSPDY (5(546)) doesn't show the number of private pages used by extended-addressing processes: Frk Sup User PC Last call Status Runtime Name Mapped pages 64 57 1002502 *RDTTY frozen 8:40.7 F64 Does anyone have a version or a quick patch that does show the private pages? A typical memory map for the above process, ELISP, looks like: @i mem 233. pages, Entry vector loc 751 len 4 0-71 Fork 1 1000-1071 R, CW, E 1000 Private R, W, E 1001-1035 S:ELISP.EXE.9 3-37 R, CW, E 1036-1037 Private R, W, E 1040-1071 S:ELISP.EXE.9 42-73 R, CW, E 1707-1757 S:ELISP.EXE.9 74-144 R, CW, E 1760-1777 Fork 1 760-777 R, CW, E 4040 Private R, W, E 4740 Private R, E ... ------- 12-Mar-84 07:44:17-PST,1494;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.SLOGIN@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 12 Mar 84 07:44:05-PST Received: from CU20B by CUCS20 with DECnet; 12 Mar 84 10:44:40 EST Date: Mon 12 Mar 84 10:45:42-EST From: Thomas De Bellis Subject: Re: New micro code release To: CC.Clive%UTEXAS-20@COLUMBIA-20.ARPA cc: Tops-20%SU-SCORE@COLUMBIA-20.ARPA In-Reply-To: Message from "Clive Dawson " of Fri 9 Mar 84 21:40:01-EST Reply-to: CC.SLogin@Columbia-20 We had the same thing happen, Clive. They sent us two complete kits. No, wait, I think that they only sent us one tape, but two installation manuals and two floppies. We liked that because that meant we could keep one set in a safe place and the other over at the machine room in case one of our PS's got wiped out. Currently, we are only running the new microcode (326) on one machine, CU20B. I didn't have the nerve to inflict it on the other machines until we had run with it for a few weeks. All our other 20's are running 275. I really hadn't noticed any problem with it all. Perhaps we don't run the kind of job mix that would tickle any microcode bugs (IE, no COBOL and almost NO user mode extended addressing applications--only our SNDSRV uses it). To which SPR's are you refering to? I hadn't been keeping up on any of this. Are there any that would make you stop running the new microcode? Thanks! -- Tom ------- 12-Mar-84 08:00:59-PST,1243;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 12 Mar 84 08:00:48-PST Received: ID ; Mon 12 Mar 84 11:01:37-EST Return-Path: Received: from SANDIA by CMU-CS-C with TCP; Mon 12 Mar 84 10:30:31-EST Date: Mon 12 Mar 84 08:29:47-MST From: Tom Linnerooth Subject: Re: New micro code release To: VAF@CMU-CS-C.ARPA In-Reply-To: Message from "Vince Fuller " of Fri 9 Mar 84 19:14:28-MST ReSent-date: Mon 12 Mar 84 11:01:33-EST ReSent-from: Vince Fuller ReSent-to: TOPS-20@SU-SCORE.ARPA I got two copies of the floppies, cover letter, and tape. We just installed it last Friday, and so far we have seen no problems. I thought it was rather strange that I got two copies of everything, but since I have two systems, I thought maybe that was the reason (even though I have never recieved duplicates before, and the second system is a "right to reproduce" type system. What I thought was really crazy was the distribution of the mag tape containing three one-page text files. Much money and trouble could have been saved if they had just sent the typed pages. Tom ------- 13-Mar-84 08:00:11-PST,635;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Tue 13 Mar 84 07:59:59-PST Date: Tue 13 Mar 84 07:59:26-PST From: Bob Albrightson Subject: Re: New micro code release To: CC.Clive@UTEXAS-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Fri 9 Mar 84 17:35:47-PST We also received duplicates of tape and floppies for microcode release 326. I was begining to believe that DEC thought we had two systems when we only have one. I guess we wont have to make a backup of tape or diskette. -bob ------- 13-Mar-84 10:18:18-PST,961;000000000000 Return-Path: <@CMU-CS-C.ARPA:BYRNE%TARTAN@CMU-CS-C.ARPA> Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 13 Mar 84 10:18:02-PST Received: from TARTAN by CMU-CS-C with TLnet; 13 Mar 84 13:18:09-EST Received: ID ; Tue 13 Mar 84 13:17:52-EST Date: Tue 13 Mar 84 13:17:49-EST From: Steve Subject: PAGLCK To: tops-20@SU-SCORE.ARPA cc: byrne%TARTAN@CMU-CS-C.ARPA Work-phone: (412) 621-2210 We've been regularly experiencing PAGLCK bughlts recently. DDC tells us that there is a patch to fix this problem, but didn't know what it was. They also said that there was a previous patch that exacerbated the situation and was to be avoided at all costs. Our local DEC office surely won't know which patch is the right one (even if they know about both of them, which is doubtful given their level of expertise), so... Does anyone know what the correct patch is? steve ------- 13-Mar-84 14:35:36-PST,684;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Tue 13 Mar 84 14:35:18-PST Date: Tue 13 Mar 84 16:35:58-CST From: Clive Dawson Subject: Used DEC 2060's To: tops20@SU-SCORE.ARPA A friend who works at a local college asked me what the used market for DEC 2060's is like these days. There are undoubtedly several sites (mostly commercial, I imagine) that have already decided to abandon DEC and get rid of their 20's. If anybody on this list knows of any used 2060's on the market, or of any sites that are contemplating jumping ship to IBM, I'd appreciate a pointer. Thanks, Clive ------- 13-Mar-84 15:25:44-PST,628;000000000000 Return-Path: Received: from USC-ECLC.ARPA by SU-SCORE.ARPA with TCP; Tue 13 Mar 84 15:24:54-PST Date: Tue 13 Mar 84 15:24:45-PST From: Chris Subject: Re: Used DEC 2060's To: CC.Clive@UTEXAS-20.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Tue 13 Mar 84 14:45:26-PST Phone: (213) 743-5520 Office: PHE-220 I dont know of anyone in particular, but I have an advertisment from a used computer dealer that is selling 2040's, albeit model A's, for $25k-$47k apparently in good working condition... Chris. ------- 13-Mar-84 16:41:07-PST,575;000000000000 Mail-From: MRC created at 13-Mar-84 16:39:41 Date: Tue 13 Mar 84 16:39:41-PST From: Mark Crispin Subject: used 20's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A 2040 for $25K? That's a damn good price, even if it is a model A. If anybody sees an advertisement for a 2020 for $10K or less, please tell me. I happen to think a 2020 would make a very good home/personal computer, albeit at the right price. -- Mark -- ------- 13-Mar-84 17:05:55-PST,575;000000000000 Mail-From: MRC created at 13-Mar-84 16:39:41 Date: Tue 13 Mar 84 16:39:41-PST From: Mark Crispin Subject: used 20's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A 2040 for $25K? That's a damn good price, even if it is a model A. If anybody sees an advertisement for a 2020 for $10K or less, please tell me. I happen to think a 2020 would make a very good home/personal computer, albeit at the right price. -- Mark -- ------- 13-Mar-84 17:57:02-PST,542;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 13 Mar 84 17:56:54-PST Date: Tue 13 Mar 84 18:56:49-MST From: Randy Frank Subject: Re: used 20's To: MRC@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Tue 13 Mar 84 18:49:54-MST A saw that 2040 add also; my guess is that it is a KL cpu only - they've probably stripped out everything of possible use on a model B machine such as rh20s, DTEs, memory... ------- 14-Mar-84 10:57:08-PST,545;000000000001 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 14 Mar 84 10:56:58-PST Date: 14 Mar 1984 13:58-EST Sender: CLYNN@BBNA Subject: TCP Bug From: CLYNN@BBNA To: TOPS-20@SU-SCORE Cc: cak@PURDUE Message-ID: <[BBNA]14-Mar-84 13:58:32.CLYNN> A bug which causes TCP to forget a received maximum segmant size option still exists at some sites. The SETZ T1, before the call to TCPMXP at USREV2-2 should be changed to LOAD T1,TSMXP,(TCB) (or move 1,$TSMXP(P5) ). Please make this correction. CLynn 15-Mar-84 08:25:15-PST,857;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 08:25:05-PST Received: ID ; Thu 15 Mar 84 11:12:00-EST Date: Thu 15 Mar 84 11:11:16-EST From: Vince Fuller Subject: Strange crashes To: TOPS-20@SU-SCORE.ARPA Recently, I've had a couple of ILLUUO crashes. The top of UPDL points looks like a normal JSYS entry into the MONRD code, and the AC contents and user image agree with this - it is Mel Pleasant's WATCH program, examining the TTLINK word in the JSB, nothing unusual about that.There's only one slight problem - there's no MONRD code to execute. The JSTAB entry for MONRD points off into a bunch of zeroes, which are not known to be very executable. Has anyone else seen anything like this before or have any suggestions? --Vince ------- 15-Mar-84 10:51:17-PST,1306;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 10:51:05-PST Date: 15 Mar 84 13:51:45 EST From: Charles Hedrick Subject: tape drive problems To: tops-20@SU-SCORE.ARPA We are going crazy. More specifically, our third-shift operator (who gets to do all our backups) is going crazy. One of our 20's has a single TU77 tape drive. The theory was that all the drive was going to do was backups, and one drive should be enough for that. (Not a good theory, I realize, but I didn't buy the machine.) It periodically goes out to lunch. Normally the error shows up as a tape write error. Sometimes DUMPER blows up. Once it just started spinning down the tape writing duplicate records. Sometimes it can't label the tapes. Field service has looked at the drive, and is unable to find anything. It does diagnositics just great. Sometimes powering the controller off and on fixes the problem. Sometimes just not using the drive for a while fixes it. Sometimes we have to reload the system to get it to work. We are beginning to think that there may be a software problem as well as a hardware problem. Does anybody have any ideas? Is the TU77 supposed to be able to back up 3 RP06's reliably? ------- 15-Mar-84 14:25:08-PST,831;000000000000 Return-Path: Received: from CMU-CS-A by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 14:24:48-PST Date: 15 Mar 84 1640 EST From: Rudy.Nedved@CMU-CS-A To: Charles Hedrick Subject: Re: tape drive problems CC: tops-20@SU-SCORE In-Reply-To: "Charles Hedrick's message of 15 Mar 84 13:51-EST" Message-Id: <15Mar84.164000.EN0C@CMU-CS-A> TU77 gave us the same problem when we had them. If I remeber correctly the tape controller would return an error via a "catchall" bit. We fought with the thing....it is definitely a hardware problem with software not being able to recover. The problem acted up like stormy weather and would disappear for good chunks of time. We finally got rid of the drive and said "Yippee!". I wish you luck....we blew about a man-year or so on the drives -Rudy 15-Mar-84 14:46:23-PST,1252;000000000001 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 14:46:13-PST Date: Thu 15 Mar 84 16:46:12-CST From: Clive Dawson Subject: Re: tape drive problems To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Thu 15 Mar 84 13:51:45-CST Welcome to the club, Chuck! We're using a single TU77 to back up 3 RP07's and 4 RP06's every week. We too have experienced various problems similar to the ones you describe. One of the most annoying problems was the spontaneous appearance of the error message: ?Tape is write-protected while DUMPER was doing a save and was within a quarter of an inch from the end of the tape. This problem got traced to a loose write-protect switch. What happens is that the switch tends to loose lubrication, and the friction when mounting a write-protected tape causes enough strain to eventually loosen the mounting. Try moving the switch in and out delicately with your finger, making sure that that action is smooth and easy. Our engineer says that once a switch goes bad it should not be tightened or lubricated--it must be replaced. ------- 15-Mar-84 15:07:17-PST,3256;000000000001 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 15:07:01-PST Date: Thu 15 Mar 84 17:07:11-CST From: Clive Dawson Subject: Re: tape drive problems To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Thu 15 Mar 84 13:51:45-CST Welcome to the club, Chuck! We're using a single TU77 to back up 3 RP07's and 4 RP06's every week. We too have experienced various problems similar to the ones you describe. One of the most annoying problems was the spontaneous appearance of the error message: ?Tape is write-protected while DUMPER was doing a save and was within a quarter of an inch from the end of the tape. This problem got traced to a loose write-protect switch. What happens is that the switch tends to loose lubrication, and the friction when mounting a write-protected tape causes enough strain to eventually loosen the mounting. Try moving the switch in and out delicately with your finger, making sure that that action is smooth and easy. Our engineer says that once a switch goes bad it should not be tightened or lubricated--it must be replaced. We have also had trouble with loss of vacuum, particularly just after loading and near the end of the tape. This problem was traced to a loose upper hub which didn't grab the tape reel tightly enough. After many attempts to adjust the tightness of the hub such that it would grab the reel properly and at the same time not cause you to break both your thumbs trying to press the lock down, the engineer finally gave up and ordered a "new-style hub assembly". Apparently these come standard on the TU77's and 78's these days, but the older drives don't have them. I believe that almost all other problems we've seen (failure to write labels when initializing, write errors, duplicate records) were eventually written off as being caused by either bad tape or dirty heads. We find that when doing a long backup it is almost essential to clean the heads after every one or two tapes. I have always been curious whether this is a function of the brand of tapes we use (Graham mostly) or if everybody needs to clean this often. One exception to this was the time I used SPEAR's ANALYZE function to discover that 95% of all tape errors in a 2-3 day period had occurred on tracks 3 or 5 of the tape. This was convincing enough evidence to cause our engineer to do a head adjustment. The only case in which I'm pretty sure there's a software problem is when DUMPER comes to a bad spot on a tape and goes into a seemingly infinite loop trying to read a given record. The hardware backs up and retries a dozen or more times, then it looks like the software backs up and tries several times. Finally an "%Error trying to read record nnnn" appears. At this point, instead of skipping ahead, it more often than not starts all over again trying to read the same record. Perhaps this depends on whether or not a blocking factor is set? I don't remember having any trouble which required us to reload the system or turn the controller on and off. Good luck, Clive ------- 15-Mar-84 15:40:43-PST,996;000000000001 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 15:40:31-PST Date: 15 Mar 1984 16:40 MST (Thu) Message-ID: From: "Frank J. Wancho" To: Charles Hedrick Cc: tops-20@SU-SCORE.ARPA, WANCHO@SIMTEL20 Subject: tape drive problems In-reply-to: Msg of 15 Mar 1984 11:51-MST from Charles Hedrick When they finally installed the permanent A/C louvers (last month), there was a rather strong draft near our TU77 that would cause the door to pop open somewhere in the middle of an 11-tape full backup, and the DUMPER (batch) job would simply disappear! Not even so much as an error message with a chance to recover!!! The CE fixed the latch, and we haven't had the problem since. The question remains as to why the job vanished... (Almost as bad as CP/M's BDOS Error on A:, if you'll pardon the comparison.) --Frank 15-Mar-84 16:54:21-PST,746;000000000000 Mail-From: ALMQUIST created at 15-Mar-84 16:54:03 Date: Thu 15 Mar 84 16:54:03-PST From: Philip Almquist Subject: Re: tape drive problems To: Rudy.Nedved@CMU-CS-A.ARPA cc: HEDRICK@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Thu 15 Mar 84 16:40:00-PST The problem at CMU was that the TU77 would magically become write-locked (according to the controller) in the middle of a backup. Ie, Chuck's problem is not quite the same. I seem to recall that we were able to mitigate the problem somewhat by making the monitor use a voting algorithm when reading the tape drive status. Rudy's solution (getting rid of the TU77) worked better... Philip ------- 15-Mar-84 18:55:37-PST,1875;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 15 Mar 84 18:55:30-PST Date: Thu 15 Mar 84 18:54:50-PST From: William "Chops" Westfield Subject: making EMACS more efficient on TOPS20 To: tops20@SU-SCORE.ARPA I have implemented half of the much requested EMACS mode for the tops20 TEXTI jsys. (break on meta characters remains undone). While I was at it, I made some changes to TTYSRV to make short string output to terminal more efficient. The patches have been running at SRI for quite a while now with no obvious ill effects. The changes to EMACS are less well debugged, but seem to work for the most part.... I have not done any performance measurements to figure out how much this has helped, but it seems that it ought to do quite a bit... Interested parties may FTP the following files from the EMACS directory on SRI-KL: TEXTI.MEM Describes the changes to the monitor. TECO.DIF SRCCOM of the new TECO with the standard MIT TECO.MID.1209. TECO.MID.1237 is the updated source code.... Enjoy BillW PS: This should serve as an example: people have been suggesting changes such as this for a long time, but nothing had ever been done. I had assumed that this was because it had been looked at and people had decided that it was too difficult, and would not have done anything except for the prompting of kirk lougheed at sierra. As it turned out, the patches were not difficult at all! Everyone seems to have just been waiting for someone else to do it... My thanks to Kirk Lougheed for help debugging the new monitor, and for general advice on monitor internals; to Mike McMahon for help with TECO internals; and to the staff and users at SRI for their bug reports and tolerence... ------- 16-Mar-84 16:03:46-PST,1292;000000000000 Return-Path: Received: from SRI-NIC by SU-SCORE.ARPA with TCP; Fri 16 Mar 84 16:03:26-PST Date: Fri 16 Mar 84 16:05:29-PST From: David Roode Subject: [POSTEL@USC-ISIF.ARPA: Domain Style Names - Coming Soon] To: TOPS-20@SU-SCORE cc: Postel@USC-ISIF Location: EJ286 Phone: (415) 859-2774 You will also need to build a new monitor probably, in order to accomodate 700 some additional host nicknames. --------------- Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Fri 16 Mar 84 13:53:12-PST Date: 16 Mar 1984 13:39:00 PST From: POSTEL@USC-ISIF.ARPA Subject: Domain Style Names - Coming Soon To: TCP-IP@SRI-NIC.ARPA Hi: An interesting and entertaining thing will happen next Wednesday. Domain Style Names will become the normal thing for all hosts in the Internet. The Host Tables maintained by the NIC will change to have ".ARPA" appended to the official name of every host in the table. This may cause a few programs to have a few problems. If you want to try things out prior to Wednesday you can test with the table in the file DHOSTS.TXT on SRI-NIC. For more information see DDN MGT Bulletin 22, and RFCs 897 & 881. --jon. ------- ------- 17-Mar-84 06:15:32-PST,767;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 17 Mar 84 06:15:24-PST Date: 17 Mar 1984 0912-EST From: Kevin Paetzold To: ROODE at SRI-NIC, TOPS-20 at SU-SCORE cc: Postel at USC-ISIF Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: Re: [POSTEL@USC-ISIF.ARPA: Domain Style Names - Coming Soon] Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12000058917.14.126.7840 at DEC-MARLBORO> Regarding: Message from David Roode of 16-Mar-84 1921-EST I am sending out a new monitor (if not today then tomorrow) which among a million bug fixes has a much larger NHOSTS (double). -------- 17-Mar-84 14:38:33-PST,503;000000000000 Mail-From: MRC created at 17-Mar-84 14:38:21 Date: Sat 17 Mar 84 14:38:21-PST From: Mark Crispin Subject: Internet software To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Kevin's new release of TCP/IP has my endorsement as being up to the latest revision level. Also, for the first time, the TELNET source is publicly distributed as a part of this release. ------- 17-Mar-84 17:05:16-PST,392;000000000000 Mail-From: MRC created at 17-Mar-84 17:05:06 Date: Sat 17 Mar 84 17:05:06-PST From: Mark Crispin Subject: MONSYM bug for new TCP/IP To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) You will need to add .HSFUZ as 14B26 in order to compile the monitor. ------- 17-Mar-84 21:01:16-PST,604;000000000000 Mail-From: MRC created at 17-Mar-84 21:01:05 Date: Sat 17 Mar 84 21:01:05-PST From: Mark Crispin Subject: TCP OPENF% wait performance bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In Kevin's latest release, modify TCPJFN.MAC in the TCPOP3 routine to add MOVE FX,FORKX before the MOVEM T3,FKSTA2(FX). Otherwise some totally random location may be clobbered and TCP: OPENF%'s will not return immediately when it is discovered that the host is down. ------- 18-Mar-84 00:42:24-PST,981;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 18 Mar 84 00:42:14-PST Date: Sun 18 Mar 84 00:41:27-PST From: Kirk Lougheed Subject: Problems with new host table To: tops-20@SU-SCORE.ARPA This evening I experimented with the new NIC host table that has the .ARPA domain appended to every host name. I discovered two things. First, the 2477 value for NHOSTS in Kevin Paetzold's latest TCP: monitor is too small. I was able to load in only 87% of the NIC host table. After bumping NHOSTS to 3001 (a prime), the newly bloated host table was able to fit. The only piece of user software that I saw malfunction under the new host table was MM. When I tried to send mail to myself, MM addressed it to Lougheed@SU-SIERRA.ARPA.ARPA. Sierra and Score are running the same version of MM. I don't doubt but that Mark will have a fix available in the very near future. Kirk ------- 18-Mar-84 01:37:12-PST,1248;000000000000 Mail-From: MRC created at 18-Mar-84 01:37:05 Date: Sun 18 Mar 84 01:37:05-PST From: Mark Crispin Subject: new host table To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Until such time as you hear on the list otherwise, you should NOT run the version of the NIC host table that has the .ARPA domains. This is because the TOPS-20 user software, including TELNET and the mailsystem, has some understanding (albeit of an earlier design) of domains already and that understanding conflicts with the NIC way of doing things. The migration of TOPS-20 to domains will take two logical steps. All the TOPS-20 user software will migrate from its physical (e.g. ".ARPA") domain understanding. It will be limited to relative domains only (the funny .#xxx names). The other step will be a complete rewrite of HSTINI and the GTHST% JSYS. In all probability there will be no significant development on this front until April. You should all spare yourselves hassle and not use the new NIC host table until after an announcement on this list comes out saying it is okay. -- Mark -- ------- 18-Mar-84 03:38:52-PST,1522;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 18 Mar 84 03:38:44-PST Date: Sun 18 Mar 84 03:38:43-PST From: Kirk Lougheed Subject: New host table, again. To: tops-20@SU-SCORE.ARPA In all probability there will be no significant developments in domain handling by TOPS-20 anytime soon, much less by April. Furthermore, using the correct NIC host table in the interim is hardly painful. I made the necessary changes in Sierra's software, relinked the appropriate programs, and was successfully using the new host table within a couple of hours. For the benefit of others, I've enclosed a summary of my changes. To use the new NIC host table, the following change to MNETDV is necessary. At GTHSIL+5 remove the line "CAIE T2,"." with the comment "END ON DOT". GTHST% will then parse a something like FOO.ARPA correctly, instead of breaking its parse after FOO and returning an error. If you are using Mark Crispin's software that uses his HSTNAM module, the following few lines should be commented out of HSTNAM.MAC. Any programs that use HSTNAM (e.g. MM, MMAILR, TELNET) should be relinked with the new HSTNAM.REL. ;;; HRROI B,[ASCIZ/ARPA/] ; add ARPA domain ;;; CALL $ADDOM ; add domain, leave pointer in A ELSE. MOVEI A,"[" ; start bracketed number ;;; HRROI A,HSTSTR ; now remove ARPA domain ;;; HRROI B,[ASCIZ/ARPA/] ;;; CALL $RMDOM MOVX A,.GTHSN ; translate name to number ------- 18-Mar-84 15:21:20-PST,681;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 18 Mar 84 15:21:10-PST Date: 18 Mar 1984 16:21 MST (Sun) Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE Subject: .ARPA OK. Suppose that those of us unprivileged few (i.e., as yet without source licenses), simply ignore this changeover event for the momemt. What will happen? As best as I can figure, MMAILR *might* refuse mail because it can't find host.ARPA in the table in response to a HELO, but will probably accept it anyway. That's about it. Right? Is there anything I've overlooked? --Frank 18-Mar-84 16:51:57-PST,979;000000000000 Mail-From: MRC created at 18-Mar-84 16:51:47 Date: Sun 18 Mar 84 16:51:47-PST From: Mark Crispin Subject: .ARPA To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The current MMAILR software understands the .ARPA domain. There is no problem in this regard. I really recommend that the TOPS-20 sites ignore the current changeover level until there is software which really understands and implements domains in a constructive manner. The "new NIC host table" is a workaround to deal with uncooperative software and is NOT a step in the right direction. If you stick with the non-.ARPA'ed host table you will continue to correctly implement host naming with the current revision of the operating system and user software. False starts such as bloated host tables are just going to get in the way of doin things right. ------- 19-Mar-84 01:20:56-PST,1134;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 19 Mar 84 01:20:45-PST Date: Mon 19 Mar 84 01:20:32-PST From: Kirk Lougheed Subject: more TCP bugs/problems To: tops-20@SU-SCORE.ARPA Two more TCP problems, both in TCPTCP.MAC in the DEC monitor. First, in the latest DEC monitor, there is a classic typo at NUWND4-4. The MOVE instruction there should really be a MOVEI. The code should read like so: CAILE T1,<.RTJST(-1,PWNDO)> ; But not more so than MOVEI T1,<.RTJST(-1,PWNDO)> ; Size of window field The second problem is that Charlie Lynn's patch to make TCPMXP pay attention to maximum segment size options has a side effect. TCPMXP does not always check to make sure that the length specified by the foreign host is acceptable on that particular network. The CSNET-RELAY host (for example) quite willingly told Sierra to send 1024 byte datagrams over a network with a maximum packet size of 1007 bytes. My suggested patch is to move the label TCPMX6 to TCPMXP+12, just before the packet radio kludge. Kirk ------- 19-Mar-84 01:47:45-PST,575;000000000000 Mail-From: MRC created at 19-Mar-84 01:46:19 Date: Mon 19 Mar 84 01:45:18-PST From: Mark Crispin Subject: TCP To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Kirk's second "problem" is not a problem at all. The value in question is the TCP segment size, which is not necessarily the same as the size of IP datagrams. TCP fragments oversize TCP segments so that the IP datagrams don't exceed the network's supported packet size. ------- 19-Mar-84 12:48:56-PST,2560;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Mon 19 Mar 84 12:48:41-PST Date: 19 Mar 1984 15:49-EST Sender: CLYNN@BBNA Subject: More TCP segment sizes From: CLYNN@BBNA To: TOPS-20@SU-SCORE Cc: MRC@SU-SCORE, Lougheed@SU-SIERRA, Paetzold@DEC-MARLBORO Cc: cak@PURDUE Message-ID: <[BBNA]19-Mar-84 15:49:56.CLYNN> The large packets produced by my recent segment size patch are the result of my looking at a wrong version of the TCPMXP routine. It should appear as shown below; the change bars in the right margin are differences which I mistakenly thought had been made (test at beginning for +infinity, TCPMX6 label moved [Kirk's suggestion would not allow PR nets to specify a larger segment size]). As Chris Kent has observed, the minimum segment size which will be accepted (128. octets) is too large for some situations. Changes to allow smaller segements are being developed, but will not be simple "patches". Charlie ------------------------------ ;TSMXP ;Update maximum packet size generated on connection. ;T1/ Foreign specified limit (from option), or 0 or +infinity ; CALL TCPMXP TCPMXP: SAVEAC LOCAL SKIPLE PSZ,T1 ; Save argument if specified CAIL PSZ,177777 ; No size if +infinity | TRNA ; No size specified | JRST TCPMX6 ; Try to use specified size LOAD T1,TFH,(TCB) ; Get foreign address CALL LCLHST ; Is it one of us? SKIPA PSZ,[^D576] ; No, sociable maximum MOVE PSZ,TCPBYS ; Yes, big ones ; Packet Radio Kludge - small packets to certain nets LOAD T2,TFH,(TCB) ; Foreign address contains NETNUM T2,T2 ; Foreign net number CAIE T2,^D1 ; BBN-PR CAIN T2,^D2 ; SF-PR-1 MOVEI PSZ,^D254 CAIE T2,^D5 ; SILL-PR CAIN T2,^D6 ; SF-PR-2 MOVEI PSZ,^D254 CAIE T2,^D9 ; BRAGG-PR CAIN T2,^D47 ; SAC-PR MOVEI PSZ,^D254 ; End of Kludge TCPMX6: | LOAD T1,TLH,(TCB) ; Foreigner's name for us CALL FNDNCT ; Put address of interface in T2 CAIA ; Not found SKIPG T1,NTPSIZ(P1) ; Get max size for that (interface) net MOVE T1,INTXPB ; None or 0, use maximum packet length CAMLE PSZ,T1 ; Use it if smaller MOVE PSZ,T1 ;TCPMX6: | CAMLE PSZ,TCPBYS ; User want bigger than we support? MOVE PSZ,TCPBYS ; Yes, Clamp to our max CAIGE PSZ,<.RTJST(-1,PIDO)+.RTJST(-1,PTDO)>*4+^D8 ; Beware too MOVX PSZ,<<.RTJST(-1,PIDO)+.RTJST(-1,PTDO)>*4+^D8> ; small STOR PSZ,TSMXP,(TCB) ; Set max packet size for connection RESTORE RET 20-Mar-84 11:43:21-PST,1149;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Mar 84 11:43:15-PST Date: Tue 20 Mar 84 11:39:24-PST From: Kirk Lougheed Subject: Re: PUP-NETWORK.DIRECTORY.208 To: SWEER@SUMEX-AIM.ARPA cc: Nethax@SUMEX-AIM.ARPA, su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Andrew Sweer " of Tue 20 Mar 84 08:37:03-PST To cope with the latest PUP-NETWORK.DIRECTORY, a version of PUPFTP with an expanded host table may be copied from Sierra as PS:PUPFTP.EXE.466 (use TCP FTP, I guess). On a related topic, an alpha version of a multi-protocol FTP is being tested on Sierra. It is one program that knows about both PUP and TCP protocols, thereby eliminating the need for a user to know about multiple FTP programs. Its user interface is that of PUPFTP. When we are done alpha testing the program (another week and a half), the new FTP should replace both PUPFTP and the present FTP on the Stanford TOPS-20 systems. PUPFTP as an independent program will be junked -- typing PUPFTP will give you the new FTP. Kirk ------- 21-Mar-84 02:01:40-PST,733;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 02:01:33-PST Date: Wed 21 Mar 84 03:01:22-MST From: Jay Lepreau Subject: Re: Problems with new host table To: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Sun 18 Mar 84 01:53:38-MST Those of you with access to "sed" on a Unix system or as part of the C/Unix environment that we send out for the 20 might try the following in a one line .cmd file: sed "s/: \\([A-Z][-A-Z0-9]*[A-Z0-9]\\)\\.ARPA,\\1/: \\1/" hosts.txt.0 >hosts.txt.-1 This is the version for the 20; on a real Unix each doubled \\ should be only single. Hack hack! ------- 21-Mar-84 07:09:18-PST,594;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 07:09:09-PST Date: Wed 21 Mar 84 08:09:00-MST From: Randy Frank Subject: Re: Problems with new host table To: Lepreau@UTAH-20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Jay Lepreau " of Wed 21 Mar 84 03:29:14-MST I mentioned to the NIC that everyone doesn't want/need to the new .ARPA host table, and they replied that they will continue to maintain the non-.ARPA host table as OHOST.TXT for the forseeable future. ------- 21-Mar-84 10:02:09-PST,2262;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 10:01:56-PST Date: 21 Mar 84 10:04:23 PST (Wed) To: tops-20@Su-Score cc: roode@Uci-750a, raj@Uci-750a Subject: New DECsystem-10/20? From: Mike Iglesias In the new issue of Information Systems News (March 19), there is the following article... DEC Readies Upgrade of 10/20s Digital Equipment Corp. (DEC) is developing a new minicomputer - based on a different architecture than its VAX series - that will provide an upgrade and new migration paths for its aged DECsystem 10/20s, sources close to the company said last week. The new minicomputer, code-named Nautilus, is currently being worked on by DEC's advanced development laboratories. The system will reportedly incorporate Reduced Instruction Set Computer (RISC) architecture using VLSI technology for speeds of up to 15 MIPS, industry sources said. In addition, Nautilus will require less cooling and less power than current DEC minicomputers, while the chips will have more gate arrays build in than the emitter-coupled logic (ECL) chips used by both DEC and IBM in most current models. RICS, a type of technology developed at the University of California at Berkeley several years ago, runs faster than conventional computers. It also has more instructions because it uses a simpler form of logic. Outside sources said DEC might turn to Fujisu Ltd. of Japan or Motorola Inc's Phoenix division in Arizona, to make the chips. Sources added the forthcoming minicomputer is a potential high end for all 32-bit systems. -------- The rest of the article went on to describe the KL model C cpu, with a redesigned cache and cpu for about 30% faster performance. It is described as a 'quick-fix answer' to the criticism from users about no upgrade path and to keep 10/20 users with the company while it takes steps to provide a better migration path. The article also talked about the software to convert 36 software to 32 bit systems and the impending announcement of the VAX 11/785, which is supposed to be 1.5 to 1.7 times the performance of an 11/780. I'll believe the story about the Nautilus when they actually ship some... 21-Mar-84 13:00:53-PST,1230;000000000000 Mail-From: MRC created at 21-Mar-84 13:00:44 Date: Wed 21 Mar 84 13:00:44-PST From: Mark Crispin Subject: Re: New DECsystem-10/20? To: iglesias@UCI-750A.ARPA cc: tops-20@SU-SCORE.ARPA, roode@UCI-750A.ARPA, raj@UCI-750A.ARPA In-Reply-To: Message from "Mike Iglesias " of Wed 21 Mar 84 10:04:23-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It is my personal belief that DEC has *no* credibility in this whatsoever. VAX and RISC are as opposite as opposite can be. VAX is the supreme example of the philosophy that all the world's problems can be solved by microcode. I can be made to believe that DEC is looking into RISC. DEC would be even stupider than they've already shown themselves to be if they weren't. I'd even be willing to believe it is called Nautilus. Projects do not necessarily mean "product on the way", especially if it's DEC. More on the "integration" front. One of my most reliable spies tells me that several DEC-20/VAX customers have started to dump both as a result of DEC's "integration"...in favor of the IBM 4341. -- Mark -- ------- 21-Mar-84 15:41:32-PST,580;000000000001 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 15:41:24-PST Date: Wed 21 Mar 84 15:41:14-PST From: Kirk Lougheed Subject: tape to tape copy To: TOPS-20@SU-SCORE.ARPA I need to do a tape to tape copy of some DUMPER tapes. The MTU program is apparently unable to cope with such tapes, allegedly because of some inadequate internal parameters. Does anyone have either 1.) the sources to MTU, or 2.) another program that can be used to copy DUMPER tapes? Thanks, Kirk ------- 21-Mar-84 16:08:27-PST,1421;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 16:08:02-PST Date: Wed 21 Mar 84 19:06:20-EST From: John T. Wroclawski Subject: Re: New DECsystem-10/20? To: iglesias@UCI-750A.ARPA cc: tops-20@SU-SCORE.ARPA, roode@UCI-750A.ARPA, raj@UCI-750A.ARPA In-Reply-To: Message from "Mike Iglesias " of Wed 21 Mar 84 10:04:23-EST With the exception of the seriously muddled explanation of what RISC architecture is all about, the Info Sys article is, I believe, substantially correct. Several other manufacturers (IBM, HP) are also working on machines in the same class. Several smaller companies (Pyramid, Ridge) already have products based on RISC principles. In most cases these products offer price/performance ratios startlingly higher than the offerings of the "major" vendors. What the article may fail to make clear is that the hypothetical DEC machine they are discussing is neither a PDP-10 nor a VAX, but something completely new. It will be interesting to see if such a machine is ever introduced as a product. On one hand, DEC wil have to move in this direction to remain competitive. On the other hand, they have all those VAXes out there. Although it would be much easier to port the VMS environment to a new machine than the TOPS-20 one, it will still take a major effort on DEC's part. ------- 21-Mar-84 20:30:36-PST,646;000000000001 Return-Path: Received: from SRI-NIC by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 20:30:27-PST Date: Wed 21 Mar 84 20:32:25-PST From: David Roode Subject: Re: tape to tape copy To: Lougheed@SU-SIERRA, TOPS-20@SU-SCORE In-Reply-To: Message from "Kirk Lougheed " of Wed 21 Mar 84 15:51:48-PST Location: EJ286 Phone: (415) 859-2774 I believe that it is large record sizes caused by blocking factors that confound MTU. MTU worked fine for Dumper tapes before blocking factors were available in Dumper. An MTU capable of larger physical tape records would be very nice. ------- 21-Mar-84 20:51:39-PST,498;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Mar 84 20:51:31-PST Received: ID ; Wed 21 Mar 84 23:50:56-EST Date: Wed 21 Mar 84 23:50:56-EST From: Vince Fuller Subject: Re: tape to tape copy To: Lougheed%SU-Sierra@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA We have a program called TCOPY which is supposed to be able to handle this. If you want it, I will see if I can dig it up. --Vince ------- 22-Mar-84 01:06:06-PST,1662;000000000001 Mail-From: G.DAIR created at 22-Mar-84 01:05:58 Date: Thu 22 Mar 84 01:05:58-PST From: Willis Dair Subject: DUMPER bug To: TOPS-20@SU-SCORE.ARPA Phones: Work - 408/984-4082; Home - 408/923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 I found a rather serious bug in DUMPER 4.1(402) yesterday when I was refreshing our PS: structure. This DUMPER came on a recent update tape. I was creating the directories and restoring the files from a full incremental tape with the CREATE command in DUMPER. I found that the directory groups for the directories were missing. I finally traced it to DUMPER. In the vicinity of LODUST, before the CRDIR%, the bits CD%FED and CD%NED are set in AC2. This has to do with off-line expiration. We do not set any off-line expiration on our system. That means the value of the off-line expiration is 0. CRDIR% gags when you try to set the off-line exp. greater than the system maximum. Since off-line expiration is zero, CRDIR% gags. However, the directory being created is in a half-way state of being created. The directory is created, but CRDIR% quits before creating the directory groups and does not create MAIL.TXT.1 in the directory. The thing that is bad is that DUMPER sees this error and says "Oh it is OK, just continue..." at LODUS9. My immediate fix was to remove CD%FED and CD%NED bits, since we are not concerned with off-line expiration. We are running V5 and not V5.1. Have they fixed CRDIR% in 5.1? If 5.1 doesn't automatically set the default off-line expiration date to 180, I will SPR DUMPER. Willis ------- 22-Mar-84 12:38:31-PST,1312;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 22 Mar 84 12:38:17-PST Date: 22 Mar 84 15:39:56 EST From: Charles Hedrick Subject: Does anybody know what is going on? To: tops-20@SU-SCORE.ARPA I recently looked through the Dispatch for problems that might be performance-related. One interesting one was SPR 20-19460 (published 1-Dec-83). It claimed to fix a problem that we have observed, where the system comes to a halt when you withhold windfall. The patch came in two pieces. One of the pieces seemed clearly more important. When I went to put it in, I found that it was already present in the source. At SCDNL1+5, SKIPN T2,NGOJOB was supposed to be changed to SKIPN T2,NBPROC. This was claimed to be monitor edit 3028, valid in 5.1. I reproduce the relevant line from the 5.1 source: ELSE. ;**;[2837] CHANGE 1 LINE AT SCDNL1:+5L TAM 14-OCT-82 SKIPN T2,NBPROC ;[2837] ANY RUNNABLE FORKS? IFSKP. Any idea why they would put in a path that has been in for 1.5 years? Does this have anything to do with the fact that the source for AP 6 seemed to have a very different history from that of the original 5.1 release? Are the developers working with different sources from the rest of us? ------- 22-Mar-84 16:06:18-PST,1021;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 22 Mar 84 16:06:01-PST Received: ID ; Thu 22 Mar 84 19:08:17-EST Date: Thu 22 Mar 84 19:08:13-EST From: Vince Fuller Subject: SMTPSV/MAISER To: TOPS-20@SU-SCORE.ARPA Is anyone (else) out there using MAISER as a subfork, with primary I/O jfns redirected to the network? I have a version of SMTPSV which listens for incoming TCP connections, and fires up MAISER SPJFN'ed to the network jfn. Unfortunately, this arrangement seems to fail in two different ways (seemingly at random, naturally...): - MAISER gets into a loop where it is apparently reading from the network but not getting anywhere, the result is that it uses up a lot of CPU time and does nothing useful until killed. - After a MAISER subfork halts, SMTPSV hangs indefintely attempting to do a CLOSF% on the net jfn. Any ideas why these things are happening? --Vince ------- 22-Mar-84 19:09:38-PST,685;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 22 Mar 84 19:09:31-PST Date: Thu 22 Mar 84 16:59:23-PST From: Bill Palmer Subject: front-end lines To: tops-20 at SU-SCORE We'd like to add more front-end lines to our 2060 at Fairchild (we currently have 32) but we'd rather avoid paying a lot of money to DEC for some old power and slot hungry equipment if we could pay less money for more modern stuff. What have other people done in this situation? In particular, has anyone ever dirtied their hands enough to make a DMF-32 work with RSX-20F? I'd appreciate any relevant information. Bill ------- 22-Mar-84 21:16:12-PST,459;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 22 Mar 84 21:16:04-PST Date: Thu 22 Mar 84 22:16:04-MST From: Randy Frank Subject: Re: front-end lines To: whp4@SRI-KL.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bill Palmer " of Thu 22 Mar 84 20:28:19-MST We're using Able DH/DMs with no problems. The only feature they lack is split baud rates. ------- 22-Mar-84 21:41:15-PST,532;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 22 Mar 84 21:41:05-PST Date: 23 Mar 84 00:05:41 EST From: Charles Hedrick Subject: MAISER as a fork To: vaf@CMU-CS-C.ARPA cc: tops-20@SU-SCORE.ARPA We tried to do this and gave up, for reasons similar to yours. We also tried to do it with FINGER, and gave up. We ended up changing FINGER so that if started at a +x entry point, it expected a JFN in some AC, and would use that for all I/O. ------- 23-Mar-84 08:32:30-PST,899;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Fri 23 Mar 84 08:32:20-PST Date: Fri 23 Mar 84 09:32:21-MST From: Norm Samuelson Subject: Laser Printers To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 We seem to do more printing than many other sites. We have three Versatec printer/plotters on our 2090 (a tall blue DEC-20), and we are running thru around 7500 pages per day. We are looking for a laser printer that could handle that sort of work load without falling apart. I know that many of you have some form of laser printers and I am looking for experiences/recommendations. I would also like to know how those printers are attached to DEC-20s (ethernet, async, DN20, or whatever). - Sam - ------- 23-Mar-84 17:16:34-PST,1132;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 23 Mar 84 17:16:24-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2626391703941724@MIT-MULTICS.ARPA>; 23 Mar 1984 20:15:03 est Date: 23 Mar 84 09:58 +0100 From: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "William Chops Westfield" , TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, tops-20 Subject: making EMACS more efficient on TOPS20 Message-ID: <48195@QZCOM> In-Reply-To: <47624@QZCOM> Many sites here in Europe would be interested in your patch. Is there any way you could send a copy of your patches to the KOM teleconference at QZ-stockholm. Or else, send me a short tape: Michel E Debar - FNDP computing Centre - Rue Grandgagnage, 21 - 5000 Namur --- I would make sure that your fixes go out on the European Symposium tape. 23-Mar-84 17:16:55-PST,1321;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 23 Mar 84 17:16:38-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2626391748443569@MIT-MULTICS.ARPA>; 23 Mar 1984 20:15:48 est Date: 23 Mar 84 09:36 +0100 From: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA, G.FUSSELL_%_SU-SCORE.ARPA%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: G.FUSSELL_%_SU-SCORE.ARPA%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, tops-20 Subject: emacs and clones.... Message-ID: <48194@QZCOM> In-Reply-To: <44988@QZCOM> I have no real specifics but here are some pointers: - there is a version of MINCE (originated with mark of the Unicorn), which runs on microcomputers, and on pdp 11's . W e have a copy that runs under unix version 6 on a pdp 11/45. So there may be other versions working. - Computer Corporation of America has a version of Emacs coded in C that runs on Vaxen... you might try to acquire the sources and hack them... but 11s' tend to be small don't they. Cheers 24-Mar-84 02:37:59-PST,1321;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 24 Mar 84 02:37:48-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2626418594364423@MIT-MULTICS.ARPA>; 24 Mar 1984 03:43:14 est Date: 23 Mar 84 09:36 +0100 From: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA, G.FUSSELL_%_SU-SCORE.ARPA%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: G.FUSSELL_%_SU-SCORE.ARPA%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, tops-20 Subject: emacs and clones.... Message-ID: <48194@QZCOM> In-Reply-To: <44988@QZCOM> I have no real specifics but here are some pointers: - there is a version of MINCE (originated with mark of the Unicorn), which runs on microcomputers, and on pdp 11's . W e have a copy that runs under unix version 6 on a pdp 11/45. So there may be other versions working. - Computer Corporation of America has a version of Emacs coded in C that runs on Vaxen... you might try to acquire the sources and hack them... but 11s' tend to be small don't they. Cheers 25-Mar-84 19:15:08-PST,682;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Sun 25 Mar 84 19:14:55-PST Date: Sun 25 Mar 84 20:13:07-MST From: Norm Samuelson Subject: Laser Printer replies To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 I have had a couple of requests for copies of the responses to my questions about laser printers. I put the replies received already, and will put any further replies, into the file DIST:LASER-PRINTER-MAIL.TXT at SANDIA. The file can be FTP'd using ANONYMOUS login. - Sam - ------- 26-Mar-84 12:36:12-PST,972;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 26 Mar 84 12:36:02-PST Date: 26 Mar 1984 1536-EST From: Reed B. Powell To: tops-20 at SU-SCORE Large-Systems-Marketing: Integration Program Office Location: "231-4261 MRO2-2/3C (Pole 4A)" REPLY: "MARKET:: or MRVAX::" Subject: TOPS==>VMS Tools Session at DECUS Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12002488154.29.146.38053 at DEC-MARLBORO> I will be presenting a session at Cinci DECUS on the tools that we have collected for the Integration Tools Clearinghouse, which aid people who happen to be moving from TOPS (10 or 20) to VMS. While the tools in the Clearinghouse are useful, there is not a vast wealth of them. Are there any folks out there with programs they think would be useful, who would like to submit some tools, and at the same time get some free publicity on them at DECUS? thanks, -reed -------- 26-Mar-84 14:13:02-PST,1323;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 26 Mar 84 14:12:06-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2626639680782981@MIT-MULTICS.ARPA>; 26 Mar 1984 17:08:00 est Date: 23 Mar 84 09:36 +0100 From: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Michel_E._Debar%QZCOM.MAILNET@MIT-MULTICS.ARPA, G.FUSSELL_%_SU-SCORE.ARPA%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: G.FUSSELL_%_SU-SCORE.ARPA%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, tops-20 Subject: emacs and clones.... Message-ID: <48194@QZCOM> In-Reply-To: <44988@QZCOM> I have no real specifics but here are some pointers: - there is a version of MINCE (originated with mark of the Unicorn), which runs on microcomputers, and on pdp 11's . W e have a copy that runs under unix version 6 on a pdp 11/45. So there may be other versions working. - Computer Corporation of America has a version of Emacs coded in C that runs on Vaxen... you might try to acquire the sources and hack them... but 11s' tend to be small don't they. Cheers 26-Mar-84 14:44:47-PST,1851;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Mon 26 Mar 84 14:23:34-PST Date: Mon 26 Mar 84 15:22:21-MST From: Norm Samuelson Subject: Re: TOPS==>VMS Tools Session at DECUS To: POWELL@DEC-MARLBORO.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Reed B. Powell " of Mon 26 Mar 84 13:36:00-MST Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 Return-Path: <@SU-SCORE.ARPA:POWELL@DEC-MARLBORO.ARPA> Received: from SU-SCORE.ARPA by SANDIA.ARPA with TCP; Mon 26 Mar 84 13:41:42-MST Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 26 Mar 84 12:36:02-PST Date: 26 Mar 1984 1536-EST From: Reed B. Powell To: tops-20 at SU-SCORE Large-Systems-Marketing: Integration Program Office Location: "231-4261 MRO2-2/3C (Pole 4A)" REPLY: "MARKET:: or MRVAX::" Subject: TOPS==>VMS Tools Session at DECUS Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12002488154.29.146.38053 at DEC-MARLBORO> I will be presenting a session at Cinci DECUS on the tools that we have collected for the Integration Tools Clearinghouse, which aid people who happen to be moving from TOPS (10 or 20) to VMS. While the tools in the Clearinghouse are useful, there is not a vast wealth of them. Are there any folks out there with programs they think would be useful, who would like to submit some tools, and at the same time get some free publicity on them at DECUS? thanks, -reed -------- Reed, In all honesty, I think the fact that there are very few tools should tell yoy (DEC) just how interested we (your (ex?)-customers) are in "INTEGRATION", and also what a poor job you are doing in making it look attractive. - Sam - ------- 26-Mar-84 23:49:45-PST,396;000000000000 Mail-From: G.EGK created at 26-Mar-84 23:49:37 Date: Mon 26 Mar 84 23:49:37-PST From: Edjik Subject: Re: Laser Printer replies To: Samuelson@SANDIA.ARPA cc: TOPS-20@SU-SCORE.ARPA, G.EGK@SU-SCORE.ARPA In-Reply-To: Message from "Norm Samuelson " of Sun 25 Mar 84 19:15:18-PST ok, ill ftp the DIST:Laser-Printer-Mail.Txt file. --E+ ------- 27-Mar-84 06:42:29-PST,1189;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Tue 27 Mar 84 06:42:18-PST Date: Tue 27 Mar 84 09:43:28-EST From: Rich Cower Subject: [Rich Cower : Re: TOPS==>VMS Tools Session at DECUS] To: tops-20@SU-SCORE.ARPA Mail-From: COWER created at 27-Mar-84 09:35:50 Date: Tue 27 Mar 84 09:35:50-EST From: Rich Cower Subject: Re: TOPS==>VMS Tools Session at DECUS To: Samuelson@SANDIA.ARPA cc: COWER@COLUMBIA-20.ARPA In-Reply-To: Message from "Norm Samuelson " of Mon 26 Mar 84 17:49:41-EST I think a better approach might be a series of tools to help users migrate to VM/CMS. My personal experience with making a move from Tops-20 to VM/CMS, and Tops-20 to VMS is I found the move to VM/CMS much easier primarily due to the documentation provided. Think about it. Indications are many of your users are moving this way, so why not make some money on it. It might be viewed as a bit sleezy, but certainly no more sleezy than leading people down the Jupiter road and then killing the project. ..Rich ------- ------- 27-Mar-84 10:27:22-PST,495;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 27 Mar 84 10:27:08-PST Date: 27 Mar 84 13:29:01 EST From: Charles Hedrick Subject: SORT To: tops-20@SU-SCORE.ARPA We are trying to install the newest version of SPSS. It requires SORT, edit 500. We have edit 467. So does DEC-Marlboro. Does anybody know anything about this version of SORT? We have tried it with the one we have, and it does not work. ------- 27-Mar-84 12:09:52-PST,762;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 27 Mar 84 12:09:28-PST Date: 27 Mar 1984 1508-EST From: Bob Longo To: HEDRICK at RUTGERS cc: TOPS20 at SU-SCORE Mail-Stop: LAO Phone: 213-417-4240 Subject: Re: SORT Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12002745218.13.355.7349 at DEC-MARLBORO> Regarding: Message from Charles Hedrick of 27-Mar-84 1329-EST SORT has been on the Autopatch tapes since tape #4. The edits on each of the tapes is: TAPE EDITS ---- ----- 4 472-500 5 501-512 6 513-515 In other words, if you had a current Autopatch Tape #6 SORT, you would be at SORT 4.3(515). -Bob -------- 27-Mar-84 15:24:58-PST,722;000000000000 Return-Path: <@COLUMBIA-20.ARPA:CCIMS.BEECHER@CUTC20> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Tue 27 Mar 84 15:24:40-PST Received: from CUTC20 by CUCS20 with DECnet; 27 Mar 84 18:25:41 EST Date: Tue 27 Mar 84 17:48:50-EST From: Ben Subject: Re: SORT To: HEDRICK%RUTGERS@COLUMBIA-20.ARPA cc: tops-20%SU-SCORE@COLUMBIA-20.ARPA In-Reply-To: Message from "Charles Hedrick " of Tue 27 Mar 84 13:29:01-EST We have version 4.3(500) of the Sort utility. If you have access to a CCnet host you can copy it from CUTC20::PS:SORT.EXE using NFT. Otherwise let me know and I'll put a copy on the ARPAnet machine, Columbia-20. Ben ------- 28-Mar-84 06:02:05-PST,636;000000000000 Return-Path: Received: from AFSC-HQ.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Mar 84 06:01:57-PST Date: Wed 28 Mar 84 09:03:21-EST From: PAHIA@AFSC-HQ.ARPA Subject: SPELL PROGRAM To: TOPS-20@SU-SCORE.ARPA cc: KING@AFSC-HQ.ARPA Anyone familiar with the program SPELL (version 5)? I am interested in a version or modification which would allow the user to accept the recommended changes rather than having the program force the new changes on you. For example, the word IM is automatically corrected by spell to I`M without allowing the user to reject the change. Any ideas would be appreciated. ------- 28-Mar-84 12:25:28-PST,1399;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Mar 84 12:25:11-PST Date: Wed 28 Mar 84 13:20:11-MST From: Randy Frank Subject: Strange Behavior with new monitor To: tops-20@SU-SCORE.ARPA We are experiencing a very strange happening with the new TCP monitor that Kevin just released, and are wondering if anyone else out there has seen this: We are crashing with SKDPF1s. The analysis shows that TCPOTS scheduler test somehow has gotten called from section 0, even though the scheduler was entered at EDMS0 in section 1. In the previous monitor (with MRC's changes) TCPOTS had a EA.ENT to enter extended addressing. Kevin (properly) took this out since the test should already be called from section 1. Indeed, when we took the EA.ENT out of the previous monitor, we started to crash with SKDPF1s also, so the problem is not a problem with the new monitor, but something that has been there all along, and just masked by the EA.ENT. The purpose of this msg is to see if we are alone is seeing this, or if anyone has seen it happen. We are at a total loss to understand how the scheduler is getting into section 0, especially since it starts out in section 1. For the moment we've put the EA.ENT back into the new release, but are bothered by the implications. Any ideas are welcome... ------- 28-Mar-84 12:45:44-PST,1004;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Mar 84 12:45:19-PST Received: ID ; Wed 28 Mar 84 15:46:46-EST Date: Wed 28 Mar 84 15:46:44-EST From: Vince Fuller Subject: New FTP To: TOPS-20@SU-SCORE.ARPA This message is primarily intended as a warning to current users of my FTP program. The current version of FTP in PS: on CMU-CS-C has been modified a bit to be somewhat compatible with the DEC/BBN version of FTP. Specifically: . The remote file is now parsed before the local file in GET. . If a is typed as the local file in GET, or the remote file in SEND, the user is reprompted for a file name (a la old FTP). . The LOGIN command now accepts a password after the username. There have also been a large number of bugfixes, mostly care of Dale Chase at ISI, to this version as well as some enhancements for hosts which are on multiple networks. --Vince ------- 28-Mar-84 15:27:31-PST,391;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Mar 84 15:27:11-PST Date: 28 Mar 84 18:28:02 EST From: Charles Hedrick Subject: SKDPF1 To: frank@UTAH-20.ARPA cc: Tops-20@SU-SCORE.ARPA We got one not long ago with the previous TCP, i.e. the one based on autopatch 6. I have not looked at the dump. ------- 28-Mar-84 15:41:48-PST,391;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Mar 84 15:27:11-PST Date: 28 Mar 84 18:28:02 EST From: Charles Hedrick Subject: SKDPF1 To: frank@UTAH-20.ARPA cc: Tops-20@SU-SCORE.ARPA We got one not long ago with the previous TCP, i.e. the one based on autopatch 6. I have not looked at the dump. ------- 28-Mar-84 20:44:52-PST,709;000000000001 Mail-From: BOSACK created at 28-Mar-84 20:44:46 Date: Wed 28 Mar 84 20:44:46-PST From: Len Bosack Subject: Subtle bug in PHYM78 To: TOPS20@SU-SCORE.ARPA Symptom: Various crashes when using a TU78. All involve clobbering some data to all ones. Crashes vary depending on load and system configuration. Diagnosis: If you have a TM78 and ANY OTHER DEVICE on the same RH, the CALL PHYRWD at ANLY10 in PHYM78 can consider scheduling IO to another device on this channel. This will result in P3 changing to a different UDB. The following SETOM will trash something. Surprise. Cure: Reverse the order of the SETOM and CALL. Consider taking TW's name in vain. ------- 29-Mar-84 00:21:12-PST,741;000000000000 Mail-From: MRC created at 29-Mar-84 00:20:59 Date: Thu 29 Mar 84 00:20:59-PST From: Mark Crispin Subject: SKDPF1 in TCP To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) What makes you think that scheduler tests run in section 1?????? They run in section 0 in release 5. Read the code which actually calls the scheduler test. The EA.ENT is needed at TCPOTS: in TCPJFN.MAC, and will continue to be needed there for the duration of release 5. I think DEC has in fact fixed the scheduler to be entirely section 1 in release 6, but that has nothing to do with release 5. -- Mark -- ------- 29-Mar-84 10:24:23-PST,729;000000000001 Mail-From: G.NORM created at 29-Mar-84 10:23:53 Date: Thu 29 Mar 84 10:23:53-PST From: Norm Kincl Subject: Re: tape to tape copy To: Lougheed@SU-SIERRA.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Wed 21 Mar 84 15:41:38-PST I have a copy of a program written at Energy Enterprises in Denver that does intelligent copies of DUMPER tapes. It knows how to change densities, deal with different number of input and output tapes, etc. Its only restriction is that you have to mount the tapes with MOUNTR (can be unlabeled tapes) to get it to work properly. If you are interested, I can try and get it to you somehow. -Norm Kincl ------- 29-Mar-84 19:29:34-PST,1633;000000000000 Mail-From: BOSACK created at 29-Mar-84 19:29:18 Date: Thu 29 Mar 84 19:29:18-PST From: Len Bosack Subject: LUG meeting on alternatives to 'integration' To: Tops20@SU-SCORE.ARPA [The next Bay LUG meeting may be of wider interest] The next Bay Area LUG meeting will introduce some alternatives to the "integration" path as outlined by DEC. The meeting will focus on the various architectures offered by other vendors, all of which will provide you with TOPS-20 compatibility. The meeting will be held at the Stanford University Graduate School of Business, Rm. 53. Those needing directions or other information (nearby hotels, etc.) should contact Mary Davillier, 415-497-9717. A representative from DEC will clarify the recently announced policy of unbundling the TOPS-20 software. The scheduled agenda: 9:00-9:30 Arrival, coffee and donuts 9:30-10:00 DEC policy statement 10:00-10:30 Stanford's future plan - Len Bosack 10:30-10:45 - break - 10:45-11:30 System Concepts - Michael Leavitt 11:30-12:15 Foonly - Dave Poole 12:15-1:30 - Lunch - 1:30-2:15 Elxsi - Hal Kinney, Vicki Voss 2:15-2:30 - break - 2:30-3:45 Tymshare 26KL product 3:45-4:30 GENERAL Q & A The meeting is open to all those interested; there are no registrations or reservations to attend; simply be at the GSB on time so as not to interrupt the presentations. If you must come late, please try and schedule your entrance during a break or the lunch hour. All participants at the LUG meeting MUST confine their comments and questions to technical matters only. ------- 29-Mar-84 20:14:43-PST,749;000000000000 Mail-From: MRC created at 29-Mar-84 20:14:34 Date: Thu 29 Mar 84 20:14:34-PST From: Mark Crispin Subject: more LUG meeting To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Len's message about the LUG meeting neglected to include the date! Unless I am mistaken, the meeting is scheduled for Tuesday, April 10. The SF Bay Area LUG is less formal than most LUGs, but consists of good people who are worth meeting and talking to. This meeting ought to be quite interesting. I'm going to check if the speakers would mind having their presentations taped; if not I think I will do so. -- Mark -- ------- 30-Mar-84 06:45:22-PST,761;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 30 Mar 84 06:45:14-PST Date: 30 Mar 1984 0946-EST From: Kevin Paetzold To: MRC at SU-SCORE, TOPS-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: Re: SKDPF1 in TCP Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12003472911.21.126.10878 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 29-Mar-84 0325-EST i hate to burst your bubble but scheduler tests in release 5.3 run in section one. if they do not on your system it is probably because one of your hacks is wrong. check the facts. -------- 30-Mar-84 07:31:22-PST,717;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 30 Mar 84 07:31:13-PST Received: ID ; Fri 30 Mar 84 10:32:52-EST Date: Fri 30 Mar 84 10:32:50-EST From: Vince Fuller Subject: Re: more LUG meeting To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Thu 29 Mar 84 23:19:06-EST If you are able to tape the presentations, please let me (or the list) know if we can obtain copies. Others of us who are not fortunate enough to live on the west coast, or for some reason or another cannot make the meeting, may be interested in the proceedings. --Vince ------- 30-Mar-84 10:37:46-PST,570;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Fri 30 Mar 84 10:37:31-PST Date: Fri 30 Mar 84 10:38:06-PST From: Erik Lundberg Subject: Re: more LUG meeting To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince Fuller " of Fri 30 Mar 84 08:14:56-PST We would be interested in obtaining copies of the tape of the LUG meeting, and would be willing to pay something as rent, or whatever, to help defray the costs. --Erik ------- 30-Mar-84 16:07:48-PST,3080;000000000000 Mail-From: MRC created at 30-Mar-84 16:07:27 Date: Fri 30 Mar 84 16:07:27-PST From: Mark Crispin Subject: videotaping of Integration alternatives To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am working on getting permissions to tape the SF Bay Area LUG meeting on "Alternatives to Integration" at Stanford this April 10. I will certainly audio-tape the session; videotaping is a possibility provided there is sufficient interest. I need to know NOW what interest there will be in having a videotape of the session, and how committed you are. If the session is videotaped, I plan on doing it personally; it will be much cheaper than having it done commercially. I would be investing a great time of time and money and must have sufficient firm commitments to enable me to break even. The total session time is 5 1/2 hours. However, some parts may run over or other parts may be "off the record". It is safe to assume that the recorded session will be from 4 to 6 hours. I intent to master the recording onto 3/4" U-MATIC and make 1/2" Beta II copies onto three L-500 tapes from that. This will provide for better quality and less generation loss than if I started with a Beta master. Your cost will be around $75/copy for a complete Beta transcript of the LUG. This is less than what you'll pay for professional copying costs, much less production. The price probably will not be much higher than that; if I cannot recover my expenses at $75/copy I won't do it. If I get enough orders I'll even pay the postage. I don't think the price will go much lower than this unless there are a great many orders (50+) as I would still have out-of-pocket expenses. It is possible to make VHS copies, but as I will be obliged to rent VHS equipment there will be a small premium for VHS; something on the order of $35-$50 divided by the number of VHS orders. If anybody wants U-MATIC copies, there will be a somewhat larger premium for that (probably around $300), since I am not planning on editing onto U-MATIC and would have to buy time in an editing room to do it. A 1" reel-to-reel video format will similarly be expensive. However, if anybody wants my U-MATIC originals, I'll let go of those for a reasonable cost. I should emphasize that I am not making money on this. I am doing this because: (1) it should be fun, (2) it would be a public service to the TOPS-20 community, (3) it will help pay for video equipment I'll be using for this job. The price is much lower than commercial work. If you want a videotape of the meeting, please send me a message as soon as possible stating what format videotape you want. If I get the permissions and get enough positive replies, I'll start collecting money and make the arrangements. If all goes well I'd expect to have the paid-for tapes in the mail later that week. -- Mark -- ------- 1-Apr-84 15:53:19-PST,790;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 1 Apr 84 15:53:16-PST Date: Sun 1 Apr 84 15:53:12-PST From: David Eppstein Subject: Improved EMACS support in EXEC To: SU-TOPS-20@SU-SCORE.ARPA I have just finished improving the EMACS support in the EXEC EDIT command. Changes are: (1) Apply SET KEEP setting even to the editor fork (this was broken by SET KEEP IGNORE but works in a vanilla EXEC) (2) Use full name of file always, so that EMACS doesn't get confused (3) Add /GOTO: switch to go to specific character in file (for programs like TeX to use to go to error locations) (4) Reuse old EMACS fork even if given a new filename Changed modules are EXECP, EXECGL, EXECED. ------- 1-Apr-84 23:31:08-PST,2795;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 1 Apr 84 23:30:59-PST Date: Sun 1 Apr 84 23:30:56-PST From: Kirk Lougheed Subject: Stanford FTP Available To: tops-20@SU-SCORE.ARPA This rather long message is to announce the availability of the Stanford FTP user program to the TOPS-20 Internet community. The Stanford FTP was developed to meet our need for a smart, friendly, and well documented FTP program. Advantages over previous FTP programs include: - COMND% JSYS interface including abortable subcommands and every command synonym you're likely to use. Flexible command line formats for the SEND and GET commands. - Error conditions often handled without aborting command. For example if a user gives a command that requires a previous LOGIN command, FTP will prompt for the login, and then retry the original command. All commands are available even if no connection has been opened; if a command needs a connection, FTP will prompt to open one. - Extensive internal self-documentation via the FTP HELP command. Extensive Scribe formatted documentation is also available. - FTP.INIT file for customizing various program parameters, including default usernames for login on foreign hosts. - INSTALL and UPDATE commands for conditional file transfers. Very useful for maintaining identical directories on several systems. - Multi-protocol that so users only need to know about one FTP user interface. Currently only TCP and Stanford Pup are implemented, but extension to protocols such as Chaos or DECnet is straightforward. - Multiple logical byte sizes and modes available. All modes, and all byte sizes from 1 to 36. Even EBCDIC. - Efficient PMAP output to disk files even for non-paged transfers. Transfers to non-disk files are still possible (except paged type). - Single synchronous fork rather than unpredictable PSI or multi-forking. Timeouts in critical points for extra robustness. - Use of TCP: device instead of the BBN JSYS interface. This requires that you run the most recent version of the DEC 5.3 monitor. Sites interested in only the TCP portion of the Stanford FTP can retrieve sources and documentation from PS: on SU-SCORE. The main source directory is PS: on SU-SIERRA. Sites with Pup support should retrieve sources from that directory. The primary author of the Stanford FTP program is David Eppstein (net address Kronj@Sierra). I believe he has done an outstanding job of software engineering and I am quite proud to be able to offer his software to the rest of the Internet community. Comments, suggestions, bug reports to BUG-FTP@Sierra. ------- 1-Apr-84 23:46:57-PST,832;000000000000 Return-Path: Received: from CMU-CS-A.ARPA by SU-SCORE.ARPA with TCP; Sun 1 Apr 84 23:46:48-PST Date: 30 Mar 84 1953 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: videotaping of Integration alternatives CC: TOPS-20@SU-SCORE In-Reply-To: "Mark Crispin's message of 30 Mar 84 19:07-EST" Message-Id: <30Mar84.195344.2@CMU-CS-A> Resent-To: TOPS-20@SU-SCORE.ARPA Resent-From: Rudy.Nedved@CMU-CS-A.ARPA Resent-Date: 2 Apr 84 0248 EST I think CMU (at least I will pay for it if not) is interested in a VHS tape....we have VHS systems all over the place because of Robotics (real hard to show demos when you have ripped a flexible assembly station apart to build it up better and you have space problems). So count 1 order for a VHS in for CMU. Thanks Mark! -Rudy 2-Apr-84 12:07:55-PST,831;000000000000 Mail-From: MRC created at 2-Apr-84 12:07:42 Date: Mon 2 Apr 84 12:07:42-PST From: Mark Crispin Subject: videotaping CANCELLED To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I regret to inform those of you who were interested in having a videotape of the "Integration Alternatives" LUG meeting (and there were enough of you to make it worth doing) that the videotaping has been CANCELLED. Of the three speakers, two were adamantly against any taping; one was iffy. In addition, the person responsible for the meeting room objects. Sorry. It would have been a great idea if it could be done, but you can't force people to give their permission if they don't want to. ------- 3-Apr-84 11:22:20-PST,619;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 3 Apr 84 11:22:04-PST Date: 3 Apr 1984 11:19 PST (Tue) Message-ID: From: David Eppstein To: SU-TOPS-20@Score Subject: Important bugfix to old PUPFTP and new FTP Both of these programs were not checksumming Pup transfers correctly. This showed up as garbaged files sent to remote hosts like CSLI and SUMEX. Fixed versions are in SYS:FTP.EXE and OLD:PUPFTP.EXE on Sierra. Thanks to Kirk Lougheed and Frank Gilmurray for pointing me at the bug. 3-Apr-84 22:45:51-PST,1777;000000000000 Mail-From: MRC created at 3-Apr-84 22:45:41 Date: Tue 3 Apr 84 22:45:41-PST From: Mark Crispin Subject: scheduler tests To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is a follow on to the series of messages about WTCONC (and hence, scheduler tests) running in section 0 when it isn't supposed to be. I have made several tests. The results are quite conclusive; parts of the scheduler DO run in section 0, even in a "vanilla DEC" system. In particular, the code at DISMSE and below runs in section 0 quite a bit. However, the code in front of it (EDMS0, EDMSH, etc.) does not run in section 0 very often. DISXE is one of the places that it does get called from section 0. Since PSI service jumps to DISMSE in several places I would consider it the #1 culprit. It IS the hardest thing to trace. If DEC wishes to claim that scheduler tests run in section 1, may I suggest that it be fully tested (such as taking the scheduler out of section 0). In the interim, I suggest as a temporary workaround something like putting an EA.ENT at FRIBP2 or thereabouts. This will at least guarantee that WTCONC doesn't get run in section 0. I also just got a SKDPF1 from ANISRT. The buffer pointed to by IMPFRI was not in core, much less locked (which has caused me to get AN20 IO PAGE FAULTS and ILULK2 bughlts). Has anybody else seen this? The latest TCP release seems to have made this problem much worse. Curiously, from what I saw of the pager's status the page WAS in core. The page fail status was "invalid page mapping" which may indicate some microcode bug being tickled??? ------- 3-Apr-84 23:11:34-PST,428;000000000000 Mail-From: MRC created at 3-Apr-84 23:11:25 Date: Tue 3 Apr 84 23:11:25-PST From: Mark Crispin Subject: more scheduler To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Actually, the EA.ENT should be at SAVRT probably because there is no stack context to return to in the dismiss code. ------- 5-Apr-84 13:12:34-PST,365;000000000000 Mail-From: G.ELDRE created at 5-Apr-84 13:12:26 Date: Thu 5 Apr 84 13:12:26-PST From: Tim Eldredge Subject: Hung terminals To: tops-20@SU-SCORE.ARPA I am having a problem with terminals getting hung in TTOBET. Do any of you have a solution to either prevent such hangs or a way to clear them short of rebooting the -11? ------- 5-Apr-84 14:34:31-PST,818;000000000001 Mail-From: MRC created at 5-Apr-84 14:34:06 Date: Thu 5 Apr 84 14:34:06-PST From: Mark Crispin Subject: scheduler and section 1 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: Scheduler tests, despite DEC's claim, do not run in section 1 all the time. Diagnosis: At least one place where they don't is from WTCONC. There are possibly others. The call is from the dismiss code, but via PSI service (i.e. not from EDMS0 or EDMSH). PSI service still seems to run in section 0. Workaround: At DISMSH, insert a SE1ENT (this is right, even though it is officially obsolete. EA.ENT requires a return PC context which doesn't exist). ------- 5-Apr-84 16:10:52-PST,816;000000000000 Mail-From: MRC created at 5-Apr-84 16:10:35 Date: Thu 5 Apr 84 16:10:35-PST From: Mark Crispin Subject: Re: Hung terminals To: g.eldre@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Eldredge " of Thu 5 Apr 84 13:12:38-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Tim - I find that TTOBET can happen if a dialup line runs open. At Stanford, our Centrex dial tone sounds like carrier to some of our 1200 baud modems. It happens slow enough however to prevent TTYSTP from triggering. My trick is to set the speed of the terminal line to 0. It may also be necessary to zero the TTOCT word of the dynamic data. -- Mark -- ------- 5-Apr-84 16:47:02-PST,564;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Apr 84 16:46:42-PST Date: Thu 5 Apr 84 16:49:09-PST From: Andrew Sweer Subject: Re: Hung terminals To: g.eldre@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Eldredge " of Thu 5 Apr 84 13:27:06-PST I've found that sometimes I've been able to unwedge terminals hung in TTOBET by doing a CFOBF jsys on 400000+TTY# via SDDT. Sometimes you have to do it a few times. Andy ------- 6-Apr-84 13:33:44-PST,851;000000000000 Mail-From: ALMQUIST created at 6-Apr-84 13:33:41 Date: Fri 6 Apr 84 13:33:41-PST From: Philip Almquist Subject: REPLY fix To: su-tops-20@SU-SCORE.ARPA Problem: REPLY can send the reply to the wrong user if the text of the reply is typed on the command line. The problem happens rather infrequently but has obvious and unfortunate privacy ramifications. Diagnosis: A new send arrives while the reply is being sent. If the send manages to update Sends.Txt before REPLY reads it then the reply goes to the sender of the new send rather than to the sender of the original send. Cure: Give the user a chance to abort the send if REPLY chooses the wrong recipient. The fixed version is available on Score as Mrc:Reply.*. I have not installed it anywhere. Philip ------- 6-Apr-84 13:42:00-PST,699;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Apr 84 13:41:44-PST Date: Fri 6 Apr 84 15:45:06-CST From: Clive Dawson Subject: Think BIG To: tops-20@SU-SCORE.ARPA Remember those disgusting Think Big posters that DEC sent out a few weeks ago? If you get another one, don't assume it's a duplicate. I just received another poster today, and almost tossed it out before unrolling it completely. The new posters have a different picture showing one of the new DEC-20's, with no trace of one of those blue toys. All in all a great improvement! I might even hang this one up. Cheers, Clive ------- 6-Apr-84 14:21:27-PST,3034;000000000000 Mail-From: MRC created at 6-Apr-84 14:21:09 Date: Fri 6 Apr 84 14:21:09-PST From: Mark Crispin Subject: mailsystem changes for domains To: TOPS-20@SU-SCORE.ARPA cc: "*MRC:HOST-NAMING.TXT.1"@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am presently beta-testing a set of changes to the TOPS-20 mailsystem for migrating to Internet domains. The purpose of this message is to outline the general strategy of these changes, not all of which have been implemented yet. The special meaning of ".ARPA" at the end of host names has been removed. In its place is a new relative domain, ".#Internet". Those of you who have non-Internet networks (e.g. Chaosnet) will recognize this syntax. Some of you may have seen this beastie escape Score in outgoing mail while I was debugging; this should be fixed now. To those of you unfamiliar to the concept of "relative domains", this is a concept internal to the TOPS-20 mailsystem, and is used to identify physical routing for sites which are on more than one network in the small-i internet sense. Sites which are only on one kind of network can more or less ignore "relative domains". The reason for relative domains is that different kinds of networks have different naming registries. For example, there is a site, Mordor, on Stanford's non-Internet LAN, different from the Internet host which has MORDOR as one of its nicknames. Mordor.#Pup (Stanford's LAN is a 3MB Pup Ethernet) and MORDOR.#Internet are two different entities recognized as such by TOPS-20 and available to the user via this syntax. Soon, the means by which non-Internet TOPS-20 sites route to Internet will change. Instead of an ARPA entry in DOMAINS.TXT there will be an Internet entry. This is because Internet will be comprised of other top-level domains other than ARPA, and hence the domain name will no longer be optional. This change will not affect Internet TOPS-20 systems' DOMAINS.TXT usage. Because of the possibility of confusion arising between the "pseudo-domains" used by DOMAINS.TXT and real domains as defined by Internet, the syntax of pseudo-domains will probably change sometime in the near future. This will affect all sites, and will be announced when it happens -- I need to think out the matter. The use of the term "domain" to refer to the TOPS-20 mailsystem's concept of "pseudo" and "relative" "domains" has been unfortunate, as it still confuses people who don't understand the difference between these and real domains. Hopefully the incompatible syntax differences from real domains will make that more clear. "Pseudo" and "relative" domains are strictly local user interface entities, to work around the absence of cooperation between different networks' naming registries. They have nothing to do with real, NIC-registered domains. -- Mark -- ------- 6-Apr-84 15:03:50-PST,888;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Apr 84 15:03:47-PST Date: 6 Apr 1984 15:04 PST (Fri) Message-ID: From: David Eppstein To: SU-TOPS-20@Score Cc: Janet Coursey Subject: Bugfix for FTP with MEIS data modes disabled If FTP runs on a 20 that does not have the various MEIS data modes available, it is supposed to use Tenex-Paged mode instead of MEIS-Paged. However, it was only setting the local transfer type to that, and not changing the remote transfer type. This has now been fixed, and installed at Sierra (where I would never see the bug) and as PUPFTP at Score (where it was causing problems). This should only affect FTP and not the old PUPFTP (which can not have different local and remote transfer types). 7-Apr-84 12:08:12-PST,661;000000000000 Mail-From: MRC created at 7-Apr-84 12:08:03 Date: Sat 7 Apr 84 12:08:02-PST From: Mark Crispin Subject: microcode 350 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Has anybody else had problems with the new microcode? I find that it will not run with my BOOT. I noticed that BOOT.EXB is different on the new floppy. Did DEC change BOOT to match the new microcode? Does anybody have the source for the new BOOT, if that is the case? It needs a patch for our filesystem. I prefer not to patch the EXB file. ------- 7-Apr-84 12:40:08-PST,757;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 7 Apr 84 12:39:55-PST Date: Sat 7 Apr 84 12:40:32-PST From: Kirk Lougheed Subject: Re: microcode 350 To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Sat 7 Apr 84 12:19:48-PST Mark, The 5.1 microcode is version 326. The 6.0 microcode is version 350. If you copied the floppies I think you did, you shouldn't have: they were part of the preliminary Release 6 Field Test package. I guess someone forgot to tell you that. I have the floppies with the version 326 microcode in my office. That version of microcode works just fine. Kirk ------- 8-Apr-84 09:52:04-PST,737;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sun 8 Apr 84 09:51:56-PST Date: Sun 8 Apr 84 10:54:11-MST From: Randy Frank Subject: moving sys: off ps: To: tops-20@SU-SCORE.ARPA For a number of reasons we plan on moving the sys: directories off ps: and onto a mountable structure. I can't think of any good reasons not to do this. Are there any that I am missing? I'm already taking into account the fact that there are certain programs used at startup that probably shouldn't be on a mountable structure since they may be needed before the structure is mounted, and that when I come up standalone it won't be mounted. Anything else I'm missing? ------- 8-Apr-84 11:41:18-PST,591;000000000000 Mail-From: MRC created at 8-Apr-84 11:41:15 Date: Sun 8 Apr 84 11:41:15-PST From: Mark Crispin Subject: Pup ILPSEC bughlts To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am getting Pup ILPSEC bughlts from the REMITQ code. Analysis of the dump shows what happened: IORBQ and BGPBQ got daisy-chained together. One is a two-way linked list and the other is a one-way linked list. Surprise. Has anybody else seen this problem? ------- 8-Apr-84 16:03:56-PST,508;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 8 Apr 84 16:03:53-PST Date: Sun 8 Apr 84 16:03:45-PST From: Kirk Lougheed Subject: Re: Pup ILPSEC bughlts To: MRC@SU-SCORE.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Sun 8 Apr 84 11:49:36-PST I have seen such crashes before, but I have not been able to figure out why the two lists were clobbered. Kirk ------- 8-Apr-84 16:29:02-PST,1398;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sun 8 Apr 84 16:28:49-PST Date: 8 Apr 84 19:32:09 EST From: Charles Hedrick Subject: moving SYS: off PS: To: frank@UTAH-20.ARPA cc: tops-20@SU-SCORE.ARPA We now have SYS: on a non-PS: structure on 2 of our 3 machines. It works. You want to think about the following: - think about your startup sequence. The first few files that run under SYSJOB may need to be on PS:, since the structure having SYS: will not be mounted until MOUNTR is up and has time to process some commands. - that about disaster situations. We like to minimize the number of drives that must be working to get up a minimal running system. That either means having the most important programs from SYSTEM: on the pack with your SYS:, or the most important programs from SYS: on the pack with your SYSTEM:. We do the latter. Here is what we have on PS:: RED: BATCON.EXE.9 CHECKD.EXE.1012 DLUSER.EXE.4 DSKMSG.SPE.1 DUMPER.EXE.7034 GLXLIB.EXE.5 INFO.EXE.3 INTRO.SPE.1 KLMSG.SPE.1 MAKDMP.EXE.1 MAPPER.EXE.2 MOUNTR.EXE.12 NETMSG.SPE.1 ORION.EXE.6011 PTYCON.EXE.17 QUASAR.EXE.12 SMTPSV.EXE.6 SPEAR.EXE.1 .SPE.1 SPRCOM.SPE.1 SPRMSG.SPE.1 SPRRET.SPE.1 SPRSUM.SPE.1 TPEMSG.SPE.1 Total of 24 files ------- 8-Apr-84 17:20:39-PST,666;000000000000 Mail-From: MRC created at 8-Apr-84 17:20:36 Date: Sun 8 Apr 84 17:20:36-PST From: Mark Crispin Subject: Re: Pup ILPSEC bughlts To: Lougheed@SU-SIERRA.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Sun 8 Apr 84 16:03:59-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Actually, the only thing "clobbered" is the head of BGPBQ. Its tail and the list itself (from the tail) look alright. I am putting some debugging hooks into Score in the next few days which will try to catch this. ------- 8-Apr-84 21:44:16-PST,892;000000000000 Return-Path: <@MIT-MC:BLIV.MKL@MIT-OZ> Received: from MIT-MC by SU-SCORE.ARPA with TCP; Sun 8 Apr 84 21:44:05-PST Date: Mon 9 Apr 84 00:46:58-EST From: Mark K. Lottor Subject: Summer job wanted To: tops-20@SU-SCORE.ARPA Hello, I'm looking for a summer job doing DEC-20 systems programmming or something close to it. I'm currently a junior at Carnegie-Mellon University majoring in Applied Math/Computer Science. I've been a part-time systems software programmer at CMU's Computation Center for the last year and have 2 years Macro-20 experience, and have been into computers for 8 years. I've also been doing work with IP/TCP protocols on TOPS-20. Reply and I'll mail my resume via U.S. mail. Lottor%TE%Carnegie.Mailnet@Mit-Multics or Mark K. Lottor Box 1831 1060 Morewood Avenue Pittsburgh, PA 15213 ------- 9-Apr-84 12:26:56-PST,733;000000000000 Mail-From: G.DAIR created at 9-Apr-84 12:26:36 Date: Mon 9 Apr 84 12:26:36-PST From: Willis Dair Subject: Re: moving sys: off ps: To: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Sun 8 Apr 84 09:52:10-PST Phones: Work - 408/984-4082; Home - 408/923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 Moving SYS: off of PS: will work if you give the SYS: directory appropriate world access. However, we wanted to have some of our programs in SYS: to have only group access. This will not work across structures. The user will have to access the SYS: structure before the user groups will be in affect. -* Willis ------- 9-Apr-84 12:56:21-PST,638;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Apr 84 12:56:12-PST Date: 9 Apr 84 15:59:03 EST From: Don Subject: Re: moving sys: off ps: To: G.Dair@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Willis Dair " of 9 Apr 84 15:26:36 EST We have a patch in our monitor (with corresponding changes in MOUNTR and OPR) which allows group access on PS: to work for (specified) other structures. Let me know if you are interested in this. If there's enough interest, I'll post the changes to the list. Don ------- 9-Apr-84 14:23:56-PST,673;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Apr 84 14:23:19-PST Date: Mon 9 Apr 84 17:25:37-EST From: Chris Maio Subject: disk/channel performance To: tops-20@SU-SCORE.ARPA Does anyone have any information on o disk/channel performance programs for TOPS-20? o improving performance by dual-porting an RP07 between two RH's on the same machine? (can TOPS-20 be made to take advantage of this?) o performance degradation due to replacing a structure composed of 3 RP06's on two RH's with a single RP07? Thanks in advance. Chris and Bill ------- 9-Apr-84 17:06:34-PST,1850;000000000000 Mail-From: BOSACK created at 9-Apr-84 17:06:17 Date: Mon 9 Apr 84 17:06:17-PST From: Len Bosack Subject: Updated LUG agenda To: Tops-20@SU-SCORE.ARPA [Here is the text of the revised LUG agenda - LB] There has been a schedule and room change for the LUG meeting to be held April 10, 1984. We have had to change the scheduled time and room to accommodate the large number of persons planning to attend. The meeting will start at 11:15 (promptly) in Bishop Auditorium, Graduate School of Business (Rm. 70). The revised agenda: 11:00-11:30 Arrival, coffee and donuts 11:30-11:45 Opening Statement - Wally Stropp 11:45-12:15 Stanford's future plan - Len Bosack 12:15-1:30 - Lunch - 1:30-2:15 Systems Concept - Michael Leavitt 2:15-3:00 Foonley - Dave Poole 3:00-3:15 - break - 3:15-4:00 Elxsi - Hal Kinney, Vicki Voss 4:00-4:45 Tymshare 26KL product 4:45-5:30 GENERAL Q & A Ground Rules: As this is part of a very emotional episode affecting all who are attending, we would like to ensure that this meeting is going to be conducted as a technical forum in which the audience will receive information from the various speakers. All questions will be held until all speakers have completed their presentations. All questions will be limited to the clarification of material brought up by the speaker. There will be no subjective rambling about how things "should" be done, legal issues, personal conflicts, etc. allowed. As professionsals, our management is paying our way to this meeting to gather information in making a sound financial decision. If we want to continue to see a viable TOPS-10/-20 engine available in the market- place, let's show a courteous and attentive disposition and provide a constructive base for that marketplace. ------- 10-Apr-84 06:16:09-PST,832;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Apr 84 06:15:55-PST Date: Tue 10 Apr 84 07:18:24-MST From: Norm Samuelson Subject: Re: moving sys: off ps: To: G.Dair@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Willis Dair " of Mon 9 Apr 84 13:36:54-MST Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 Accessing another structure that EVERYBODY will want to access is really very easy to accomplish if you make one small change to the EXEC. When you are about to TAKE the LOGIN.CMD and COMAND.CMD files, you can TAKE one more file, SYSTEM:COMAND.CMD. That file is a logical place for commands like that. - Sam - ------- 10-Apr-84 08:33:09-PST,1163;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Apr 84 08:32:55-PST Date: Tue 10 Apr 84 09:35:17-MST From: Norm Samuelson Subject: DECUS Large Systems SIG - Networks and Communications To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 Due to a change in our interest in DEC, and the need to spend more time with my family after a year of working 4am to noon, I am resigning from my position as Networks and Communications "working group coordinator" in the Large Systems SIG of DECUS. I know that many of you on this list are well qualified for the position. If any of you are interested in the position, please contact one of the following: myself - Samuelson@SANDIA - (415) 422-0661 Clive Dawson - CC.Clive@UTexas-20 or Leslie Maltz - (201) 420-5478 The position is open now, and it is likely that the first volunteer will get the job. (Any additional volunteers for help with the SIG will, I am sure, be greeted with open arms also). - Sam - ------- 10-Apr-84 09:05:07-PST,680;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Apr 84 09:04:55-PST Date: Tue 10 Apr 84 10:07:17-MST From: Norm Samuelson Subject: TU-77 problems To: TOPS-20@SU-SCORE.ARPA Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 I have been having problems with my TU77s for some time now. When unloading a tape there si some probability that I will 1) do it successfully 2) get a rash of TM2CCI's but otherwise do it ok 3) get a KPALVH Have any of you seen such a problem? Do you have a fix for it? - Sam - ------- 10-Apr-84 10:52:50-PST,483;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Apr 84 10:52:26-PST Date: 10 Apr 84 13:55:09 EST From: Don Subject: Re: moving sys: off ps: To: G.Dair@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Don " of 9 Apr 84 15:59:03 EST The code to make PS: group access work for selected other structures may be found in [RUTGERS]PUBLIC.*. Don ------- 10-Apr-84 12:15:55-PST,810;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Apr 84 12:15:38-PST Received: ID ; Tue 10 Apr 84 15:18:13-EST Date: Tue 10 Apr 84 15:18:11-EST From: VAF@CMU-CS-C.ARPA Subject: Re: scheduler tests To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Wed 4 Apr 84 01:49:53-EST With the latest release, we have also been experiencing AN20 IO page fails (BUGCHK ANIOPF) as well as occaisional IOPGF BUGHLT's. Neither of these were occurring before the latest release. One curious note - the ANIOPF's seem to occur most frequently right after system startup. Unfortunately, I do not have dumps for the IOPGF, since we have been extremely low on disk space lately. ------- 10-Apr-84 16:12:48-PST,932;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Apr 84 16:12:38-PST Received: ID ; Tue 10 Apr 84 19:15:54-EST Date: Tue 10 Apr 84 19:15:53-EST From: Vince Fuller Subject: FTP/FTPSRT bugfixes To: TOPS-20@SU-SCORE.ARPA I am interested in collecting all known bugfixes to FTP and FTPSRT in order to merge them into the versions that I maintain. In particular, there is a bug in one of them whereby the PORT negotiation is not properly handled some of the time. The result is that FTPSRT cannot connect back the local host to establish a data connection. The problem only seems to occur with TOPS-20 hosts and does not occur if the PORT negotiation is omitted. Has anyone else managed to get this to happen predictably or to find a fix for it? In any case, I'd appreciate pointers to bugfixes to FTP or FTPSRT. --Vince ------- 11-Apr-84 15:57:38-PST,547;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.BILL@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Wed 11 Apr 84 15:57:19-PST Received: from CU20B by CUCS20 with DECnet; 11 Apr 84 19:00:13 EST Date: Wed 11 Apr 84 19:00:27-EST From: Bill Schilit Subject: Looking for JSLOOK To: tops-20@SU-SCORE Does anyone know the whereabouts of a working version of the SWSKIT program JSLOOK? The version I have is from '77. Thanks ever so much in advance... - Bill (Columbia Computer Center) ------- 11-Apr-84 17:19:01-PST,473;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 11 Apr 84 17:18:51-PST Date: 11 Apr 1984 18:21 MST (Wed) Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE Cc: hh@WSMRB Subject: SimScript II.5 for TOPS-20 Is anybody running subject system on their machine? If so, where did you get it and what is the load impact, if anything significant? --Frank 12-Apr-84 05:29:42-PST,427;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Apr 84 05:29:35-PST Date: Thu 12 Apr 84 07:32:39-CST From: G.TI.DAK@UTEXAS-20.ARPA Subject: Group Access Rights To: tops20@SU-SCORE.ARPA Has anybody modified TOPS-20 (monitor, ACJ, etc) to allow group access rights to work across structures. Regards, Donald Kassebaum (TI Computer Science Labatory) ------- 12-Apr-84 09:01:18-PST,402;000000000000 Mail-From: G.TJM created at 12-Apr-84 09:01:06 Date: Thu 12 Apr 84 09:01:06-PST From: Ted Markowitz Subject: Password generation To: tops-20@SU-SCORE.ARPA I seem to remember pointers to algorithms for generating random passwords that were pronounceable or otherwise memorable. Can anyone lead the way to the descriptions of these? Thanks in advance... --ted ------- 12-Apr-84 11:50:47-PST,752;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Apr 84 11:50:27-PST Date: Thu 12 Apr 84 12:34:54-MST From: Norm Samuelson Subject: Re: Password generation To: G.TJM@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Ted Markowitz " of Thu 12 Apr 84 10:08:07-MST Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 Sandia has a pronouncable password generator. It was originally written in BASIC. There is a FORTRAN version in DIST:PASWD.FOR with a MACRO subroutine in DIST:PWSHFT.MAC. The files can be FTP'd with ANONYMOUS login. - Sam - ------- 12-Apr-84 12:26:42-PST,1024;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Apr 84 12:26:25-PST Date: Thu 12 Apr 84 13:28:26-MST From: Tom Linnerooth Subject: Re: Password generation To: Samuelson@SANDIA.ARPA, G.TJM@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Norm Samuelson " of Thu 12 Apr 84 12:59:24-MST Sam was not quite correct in his reply concerning our password generator. It is available as DIST:PASWD.FOR, but it does not need the other file he mentioned. This is because the program has been modified to generate a better sequence, and at the same time was converted to use FORTRAN 77 character data. We also modified FORLIB by adding routines GTRAN and SVRAN to better satisfy our requirements. Rather than go to all this trouble, you may just copy DIST:PASWD.FOR and edit it to use the FORTRAN random number routines in a more conventional manner, using the system clock as a seed. Tom ------- 13-Apr-84 10:13:50-PST,1083;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Apr 84 10:13:14-PST Date: Thu 12 Apr 84 20:25:35-EST From: Chris Maio Subject: TCP bug hangs TOPS-20 To: TOPS-20@SU-SCORE.ARPA A problem with the 5.3 monitor occasionally causes our system to hang; has anyone else seen this? The "BG" process run by the internet fork seems to forget to unlock TCBHLK occasionally. ABTJCS (called from CLZFF%) runs NOINT and tries to acquire this lock in order to release internet resources (regardless of whether any process in the job has ever acquired any), and since CLZFF% is called from the RESET% jsys, it's essentially impossible to run any programs when the internet fork has fouled up the lock, and the system becomes useless unless you can get into MDDT to clear the lock by hand. As far as I can tell, the NOINT and OKINT in ABTJCS are unnecessary, and removing them should prevent the system from hanging, but does anyone know a fix for the source of the problem? - Chris ------- 13-Apr-84 15:42:06-PST,1042;000000000001 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Apr 84 15:41:51-PST Date: Fri 13 Apr 84 15:42:38-PST From: Bjorn Lindskog Subject: Incremental backups To: tops-20@SU-SCORE.ARPA Does anyone know how DUMPER treats deleted files when doing an incremental back-up? Presumably, a back-up starting with a full and a number of incrementals should be a snap-shot of the file system at the time the last incremental was taken. However, files deleted between incrementals undoubtly change the structure of the file system, but is this registered by DUMPER in the incrementals? That is, when completely restoring a crashed structure from the back-ups, will the incrementals only add files or will they both add and remove files? By the way, is the amount of data that fits on an RP06 fixed in hardware, or is it possible (by using another type of pack or another formatting) to fit less? (Yes, I mean LESS) Thanks in advance, -- Bjorn ------- 13-Apr-84 16:41:39-PST,1873;000000000001 Return-Path: <@RUTGERS.ARPA:PLEASANT@RU-BLUE.ARPA> Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Apr 84 16:41:27-PST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 13 Apr 84 19:44:12 EST Date: 13 Apr 84 19:44:50 EST From: Mel Subject: problems with TU-78s To: Tops-20@SU-SCORE.ARPA Reply-to: Pleasant at Rutgers Office: H028-Hill Cntr, Busch Camp, PO Box 879, Piscataway, NJ x2287 Home: 81 Gage Road, East Brunswick, NJ 08816, (201) 828-8252 We've seemed to have developed a problem with our TU78s. Actually, according to our operator, we've had the problem ever since our new system (with TU78s) arrived. Apparently, the archival system (the one that comes on -20s) constantly fouls up in one form or another e.g. we haven't had a clean run yet. It works much better (as best as can be expected) on our TU77s and TU45. The symptoms vary. We've seen cases where the tape drive isn't moving but a ^T shows that Dumper is still running. Looking at the Dumper in Sysdpy shows that Dumper is actually proceeding (as opposed to stuck in a loop). Many times, Dumper simply bombs out with one of many hardware errors. You might ask why I think our problem is different than all of the other tape problems that have been reported. Well, the problem is not consistent across all of our drives. Only the 78s seem to be affected in this manner. Also, we can run backups and restores and do other tape operations on the 78s without problems. Even users are able to use the drives all the time - again without problems. So my question - has anyone seen a problem like this one? Does anyone know of an SPR we've might have missed geared specifically toward TU78s (we've looked but didn't find anything)? Is there some obscure monitor bug that is tickled by Dumper? etc.... -Mel ------- 14-Apr-84 14:14:17-PST,814;000000000001 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Apr 84 14:14:05-PST Date: Sat 14 Apr 84 14:15:04-PST From: Witold Paluszynski Subject: Re: Incremental backups To: BJORN@WASHINGTON.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bjorn Lindskog " of Fri 13 Apr 84 16:24:19-PST When restoring files from backup tapes DUMPER does not care about existing files; it just restores whatever is on the tapes. The only exception I know of is when the version of a file on the disk is newer than the version on the tape. In general, all information DUMPER uses when restoring a file is that from FDB. Isn't that right? If it is it can't know about files that don't exist. Witold ------- 16-Apr-84 21:56:25-PST,6094;000000000000 Mail-From: MRC created at 16-Apr-84 21:56:07 Date: Mon 16 Apr 84 21:56:07-PST From: Mark Crispin Subject: Integration Alternatives To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The following is a set of VERY subjective opinions I have as a result of the LUG meeting on Integration Alternatives, held at Stanford on April 10. DEC was supposed to make a presentation and decided not to. There were four non-DEC vendors present: Systems Concepts, Foonly, Elxsi, and Tymshare. Elxsi talked about their new computer architecture; the other three about their ersatz PDP-10's. Elxsi undoubtably gave the prettiest presentation. They have a message-passing operating system, with a virtual memory scheme that looks somewhat like TOPS-20's. Obviously, though, they failed to do their research as to the crowd they were talking to. There was, at best, polite interest in their operating system. Also one must wonder about a company that has gotten this incredible amount of backing but has only sold a few systems (their income from capital is about 5 times their profits!). Once they realized they were barking up the wrong tree they asked Poole about microcoding their machine to run PDP-10 instructions; Poole had to explain to them that the result wouldn't be all that good. Tymshare said more or less the same thing they did in Las Vegas, although they claim they have fixed many of the bugs encountered there. Their machine is basically a 60% KL (some would say less than that), and it sells for $300K -- too much. There is also a considerable amount of speculation that that part of Tymshare may turn into a pumpkin as a result of the takeover by McDonnell Douglas. To Tymshare's credit, they have a real-live working machine, running TYMCOM-20 (there is a word for the relation between TYMCOM-20 and TOPS-20. The word is "identity"). Also, Tymshare's credibility is enhanced by the fact that they are primarily building this machine for themselves and would build and use it in-house even if nobody else did. It is too bad that they are using Foonly F4's as their primary CPU and not something more competant. Foonly gave a very good presentation of the PDP-10's history and a rather good handout. They mentioned the F4, but properly ascertained that what the customers really want is a better-than-KL machine. They have dusted off the F1 design and modernized it to be KL-compatible. This new machine is called the F1B. The question is whether or not one will actually be built. Poole certainly has proved that he can build PDP-10's, but this new machine would be quite complex. He's talking about first deliveries in 1985 for $450K for the CPU. Systems Concepts mentioned two processors they are developing: Mars and Mars II. Mars would be approximately 3xKL speed, Mars II twice that. They claim that it will have a much smaller footprint than KL's or F1B's. They passed around some very pretty multi-layer PC boards for the first processor, Mars. They expect to have a prototype powered on "soon." You may have heard of Systems Concepts as the vendors of the SA-10. All in all, I think Foonly and Systems Concepts made the best showing. They certainly consider each other to be their primary competition, and have very strong feelings about the right way to go about doing things (they are taking very different approaches). The problem is that neither the F1B nor the Mars/Mars II physically exist yet. Both Foonly and Systems Concepts seemed to exude confidence that they will have operational prototypes soon; Systems Concepts seems to be somewhat closer to that goal but I haven't been to Foonly yet so I can't say for sure. Personally, I feel that the best strategy is to give all three (Tymshare, Foonly, and Systems Concepts) a call and compare what they have to offer against your needs. Neither seems to be the clear victor yet. I have some ideas who will be, but I decline to state them in a public forum. The only clear facts now are: . Tymshare has a slow machine that is too expensive . Foonly and Systems Concepts are building fact machines, but they don't exist yet . DEC is still dilly-dallying about the software license issue. In the software licensing issue, Tymshare seems to be somewhat ahead of both Foonly and Systems Concepts. Tymshare claims that what runs on their "System 26KL" is "TYMCOM-20" which "looks like TOPS-20" but which really isn't. Of course, it is almost totally identical except in the physical I/O drivers. They seem to be defying DEC to take legal action; DEC has not done anything and in fact it may now be too late for DEC to do so. DEC has mumbled about TOPS-20 licenses for 3rd-party machines for $80K for the first machine and $40K for subsequent machines but a number of legal issues remain. I don't pretend to understand all the ramifications, but apparently it may be that DEC has legally abandoned the property. I guess the most objectionable thing about the Foonly F4 (which is the base of the System 26KL) is that it has several very slow instructions. Floating point is horrible, and even byte instructions take over 2 microseconds. That is why I consider Foonly's F1B and System Concepts' Mars/Mars II to be much more interesting. I am not sure, but I think that a Mars II would be somewhat faster than an F1B when you look at Foonly's and System Concepts' claims. I am sure this will only be known for sure once the machines actually exists and real benchmarks can be run on them. I will close with the note that this is VERY subjective. It should not be implied as an endorsement or non-endorsement of any vendor. My dismissing of Elxsi was mostly because I don't think their market is with us, and I think they think the same thing. I personally wish all the vendors the best of luck. ------- 19-Apr-84 02:55:32-PST,1121;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Apr 84 02:55:21-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2628671609105205@MIT-MULTICS.ARPA>; 19 Apr 1984 05:33:29 est Date: 13 Apr 84 22:19 +0200 From: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, "Ted Markowitz " Subject: Password generation Message-ID: <51682@QZCOM> In-Reply-To: <51479@QZCOM> I know of at least one system where such has been accomplished, namely the AIDA system in Uppsala, Sweden. If you wish to get a copy of the program generating such passwords, please contact the system administrator Per Danielsson in this COM system, who can contact the author of the program. (Beware, the password are pronouncable, but alas! only if you have an Orcish mind!) 19-Apr-84 16:48:23-PST,1029;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.BILL@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Apr 84 16:48:00-PST Received: from CU20B by CUCS20 with DECnet; 19 Apr 84 14:51:50 EST Date: Thu 19 Apr 84 14:51:45-EST From: Bill Schilit Subject: RESET% JSYS (CCOC please) To: tops-20@SU-SCORE.ARPA Has anyone flamed about the RESET% jsys not resetting the CCOC words to their initial values? Does anyone care or think this is a bad idea? I have this problem where my program acts strangely if I LOAD then START it, but not if I LOAD, SAVE then RUN it. The weirdness occurs because LINK uses PA1050, and PA1050 does an SFCOC to present a TOPS-10 look alike. By the time my program is all setup in its little fork the CCOC words are still setup for PA1050. Now I guess I could change PA1050 to save/restore on the EXIT. But I think it should really be something in RESET%, although it is a job wide function... What's your opinion, I'd like to know... - Bill ------- 19-Apr-84 17:48:42-PST,2925;000000000000 Return-Path: <@COLUMBIA-20.ARPA:GINGELL@CWR20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 19 Apr 84 17:48:25-PST Received: from CWR20B by CUCS20 with DECnet; 19 Apr 84 20:47:50 EST Date: Thu 19 Apr 84 20:46:37-EST From: Rob Gingell Subject: Re: RESET% JSYS (CCOC please) To: Sy.Bill@CU20B cc: tops-20%SU-SCORE@CUCS20 In-Reply-To: Message from "Bill Schilit " of Thu 19 Apr 84 20:02:15-EST I personally, don't want the RESET% JSYS touching any of the terminal modes or settings. In fact, in addition to not doing the CCOC word setting, RESET% action number 4 (as itemized in the manual) ought to be removed entirely, for the following reasons. 1. The JSYS does not do what the documentation says. The documentation states that the controlling terminal's JFN mode word is affected. What it in fact does is to see if the job has a controlling TTY and if so, set the mode word of the primary output which might of course be redirected to something other than the job's controlling terminal. In fact, it should be using the process's controlling terminal since SCTTY% might have redirected it. 2. Having a fork affect a job-wide resource in this implicit fashion has annoying side effects. I run a "daemon" in my job which performs various time-dependent functions. Some of these functions are run as subforks of the daemon. Although these processes may not affect the terminal, they all begin with the RESET% JSYS. It's hard for EMACS/SED/your-favorite- non-standard-TTY-mode-program to work properly when the TTY modes are suddenly changed out from underneath it. If I run two programs which expect to have my sole attention at the terminal simultaneously, then competition for the terminal settings and strange effects would be expected. But for an operation performed by just about every program to have this kind of global effect in a multiprocess environment is anachronistic and loaded with potential races. We have in fact, removed this "feature" of RESET% and have been running without it for a few years. There has been just one side effect that we have found, and that is that there is a RESET% in the LGOUT% code which expects this effect, and this was fixed by just inserting the code in-line there. The other program which one might expect to have problems, the EXEC, doesn't because it doesn't have any RESET% calls in it (!). Rob P.S. While we're on the subject of race conditions and surprises over job-wide resources, anyone want to flame about the RSCAN% JSYS? For a good time -- have a background fork which sleeps for a while and then runs something like MM or MS or anything which attempts to re-read the command line via RSCAN%. Some amazing things happen when the (probably random) contents of the rescan buffer are fed to such programs. ------- 20-Apr-84 11:18:49-PST,2711;000000000000 Return-Path: Received: from yale by SU-SCORE.ARPA with TCP; Fri 20 Apr 84 11:17:56-PST Received: by YALE-BULLDOG via CHAOS; Fri, 20 Apr 84 14:19:45 EST Date: Fri, 20 Apr 84 14:19:09 EST From: John R Ellis Subject: RSCAN To: tops-20@SU-SCORE.ARPA Cc: Mishkin@YALE.ARPA In-Reply-To: Rob Gingell (?Invalid domain (host)), Thu 19 Apr 84 20:46:37-EST P.S. While we're on the subject of race conditions and surprises over job-wide resources, anyone want to flame about the RSCAN% JSYS? For a good time -- have a background fork which sleeps for a while and then runs something like MM or MS or anything which attempts to re-read the command line via RSCAN%. Some amazing things happen when the (probably random) contents of the rescan buffer are fed to such programs. Sure, I'll flame. For years we've been running typical user environments with process trees 3, 4, or 5 levels deep and up to 10 or more processes. (We had to solve the global terminal mode problem, but that's another story.) Users often switch between forks at random times in their execution. In this environment, not only did we encounter problems with RSCAN using a global resource, but the global resource is tied to the job's controlling terminal, not the process's controlling terminal. RSCAN won't work if the process has a controlling terminal different from that of the job. Our session manager tool uses PTYs that are SCTTYed to the process tree under the session manager, and using RSCAN was out of the question. We've always wondered about the randomness of RSCAN, especially since TOPS-20 has long provided a much better solution to passing arguments to child processes, the process argument block (PRARG). One of the first things we did was to change the EXEC to give programs their command lines via PRARG by default instead of via RSCAN. Our runtime library provides standard tools for extracting and parsing the arguments in various ways. For programs that have a submode that parse commands using COMND, unfortunately you couldn't give a string pointer instead of a JFN to COMND. So one of our routines takes the command line, writes it to a temp file, opens the temp file, and gives that JFN to COMND. It's amazingly fast and has much the same effect as RSCAN, supplying a stream to parsers that want a stream instead of a vector of string arguments. I'm mystified why such a gross wart like RSCAN has remained for all these years in standard TOPS-20. Is there any reason I'm not aware of, other than initial bad design and/or historical inertia? ------- 20-Apr-84 15:51:08-PST,1307;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Apr 84 15:50:49-PST Date: Friday, 20 April 1984, 15:00-PST From: Ken Olum Subject: String argument to COMND% To: Ellis at YALE.ARPA, tops-20 at SU-SCORE.ARPA Cc: Mishkin at YALE.ARPA In-reply-to: The message of 20 Apr 84 11:19-PST from John R Ellis Date: Fri, 20 Apr 84 14:19:09 EST From: John R Ellis For programs that have a submode that parse commands using COMND, unfortunately you couldn't give a string pointer instead of a JFN to COMND.... Yes, you CAN do this. I've been doing it for quite a while in a RSCAN/COMND package that I wrote. All you have to do it to copy the string into the command buffer and set up the pointers and the unparsed-character count so that the string looks like read-but-not-parsed input (i.e. so that it looks like a reparse is going on) and then call COMND as normal. If something goes wrong with your parse so that COMND thinks it needs more input it will try to read from whatever JFN you give it -- you can prevent undesirable behavior here by putting such bogus JFNs in the command state blocks that COMND will get an error which you can then trap. Ken 20-Apr-84 16:11:31-PST,1674;000000000000 Return-Path: Received: from yale by SU-SCORE.ARPA with TCP; Fri 20 Apr 84 16:11:18-PST Received: by YALE-BULLDOG via CHAOS; Fri, 20 Apr 84 19:12:19 EST Date: Fri, 20 Apr 84 19:10:29 EST From: John R Ellis Subject: Re: String argument to COMND% To: Ken Olum Cc: Ellis@YALE.ARPA, tops-20@SU-SCORE.ARPA, Mishkin@YALE.ARPA In-Reply-To: Ken Olum , Friday, 20 April 1984, 15:00-PST Ellis: For programs that have a submode that parse commands using COMND, unfortunately you couldn't give a string pointer instead of a JFN to COMND.... Olum: ...All you have to do it to copy the string into the command buffer... Of course. What I meant was that most JSYSes take a JFN, a device designator, or a string descriptor, but unfortunately the COMND only takes a JFN. The disadvantage of stuffing the COMND JSYS buffer as you suggest is that it needs a control structure quite a bit different from the normal command loop for reading from a JFN (e.g. terminal). It isn't exceedingly hard to do buffer stuffing, but it is an annoyance to program this up, especially if one wants to parse multiple commands contained in one input string (e.g. a string with newlines in it). We found it much easier, trivial, just to dump the string into a temp file and then use the normal control structure to read from the temp file. For our applications (parsing program-command-line arguments) this is quite acceptable. And adapting old RSCAN/COMND clients to use this method with PRARG is probably easier than hacking them to do buffer stuffing. ------- 20-Apr-84 21:42:39-PST,1487;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Apr 84 21:42:29-PST Received: ID ; Sat 21 Apr 84 00:45:42-EST Date: Sat 21 Apr 84 00:45:40-EST From: Vince Fuller Subject: Mail system query To: tops-20@SU-SCORE.ARPA Has anyone managed to extend the TOPS-20 mail system to fully support personal names? By this, I mean that all components of the mailsystem that need to deal with usernames also accept human names, perhaps also accepting non-ambiguous abbreviations, and that all components correctly handle cases where: 1. The personal name is ambiguous - matches more than one user 2. The name string matches both a user and at least one personal name By "correctly handle" I mean that for case 1) a rejection is sent that lists the possible matches (up to a limit) and for case 2) the mail is delivered to the username BUT a "rejection" warning is also returned to the sender indicating that the mail may not have been delivered to the expected recepient. I have modified MM, MMAILBOX, and MMAILR to support personal names but am having some trouble with case 2 - MMAILR crashes while attempting to "free a bad block" when it is necessary to both deliver the message and to send back an error. I have stared at the code for a while and can't figure out why this is the case. Advice from people who have tried this in the past would be appreciated. --Vince ------- 23-Apr-84 11:23:19-PST,569;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Apr 84 11:23:01-PST Date: Mon 23 Apr 84 14:11:59-EST From: TGRADY@DEC-MARLBORO.ARPA Subject: Re: Mail system query To: VAF@CMU-CS-C.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince Fuller " of Sun 22 Apr 84 11:19:41-EST We are considering just such a feature in planning for the future versions of DECmail/MS. If you have any more thoughts on the subject, I'd appreciate hearing from you. tim grady. ------- 23-Apr-84 18:46:55-PST,1199;000000000000 Mail-From: MRC created at 23-Apr-84 18:46:45 Date: Mon 23 Apr 84 18:46:45-PST From: Mark Crispin Subject: host naming To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A first draft specification for a rewrite of GTHST% has been developed and is being circulated amoung the people who are most concerned with the implementation. The most important thing is that the GTHST% functions dealing with "host indices" and the various GETAB% tables HSTNAM, HSTSTS, and HOSTN are not included. This is more or less because they are not implementable in an environment which uses a Domain Name Resolver and local cache instead of a monolithic host table. This affects the SYSDPY program (ANH command) and some older versions of Telnet and FTP. If there are any other programs which still load an internal version of the "host table" serious consideration should be made to fixing those programs. The functions .GTHSN and .GTHNS of GTHST% will be unchanged; most of the proposed GTHST% changes are upwards-compatible extensions. ------- 23-Apr-84 18:49:20-PST,937;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Apr 84 18:49:08-PST Date: Mon, 23 Apr 1984 14:08 PST From: KDO at SRI-KL To: tops-20 at score Subject: ILULK2 BUGHLT's caused by wrapping of lock count In FREE at GRORE1 (Grow resident storage by locking new pages) there appears the following comment: ; * * BUG: NEED TO LOCK DOWN ONLY WHEN CROSS PAGE BOUNDARY. ; * * PAGES NEVER GET PROPERLY UNLOCKED. This is indeed true. In fact, it's so bad that the lock count in the left part of CST1 can wrap around to 0 (because the page has been locked 10000 times) so that the page looks unlocked. Then when you try to unlock it you get an ILULK2 "Unlocking a page not locked" BUGHLT. Is this known about yet? Is there a good fix for it? (I put a patch in the page-locker to not allow wraparound, but it would be nicer if pages weren't spuriously locked). Ken 23-Apr-84 20:23:58-PST,1339;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Apr 84 20:23:49-PST Date: Mon 23 Apr 84 22:27:27-CST From: Clive Dawson Subject: Re: host naming To: MRC@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 23 Apr 84 21:27:31-CST While on the subject of GTHST%, I'll point out some strange behavior I discovered today which may have a bearing on the organization of the host tables. An examination of the current HOSTS.TXT file reveals that SATNET is considered both a network and a host. When TOPS-20 processes HOSTS.TXT and sets up HOSTN, HSTNAM, HSTSTS, etc., it will in fact create two separate entries in HOSTN for SATNET. Each entry has its own separate name string in HSTNAM, but points to the SAME entry in the hashed host tables, including HSTSTS. The result of this is that the info about SATNET as a network is lost, and successive calls to GTHST will return two entries for SATNET as a server host. The problem is that both network and host are identified as 4.0.0.0. The obvious solution seems to be that SATNET should have a SINGLE entry in HOSTN, and that HSTSTS should have BOTH HS%SRV and HS%NET turned on. Does this make sense? Cheers, Clive ------- 23-Apr-84 22:12:33-PST,1015;000000000000 Mail-From: MRC created at 23-Apr-84 22:12:15 Date: Mon 23 Apr 84 22:12:15-PST From: Mark Crispin Subject: Re: host naming To: CC.Clive@UTEXAS-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Mon 23 Apr 84 20:24:13-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Clive - The HSTSTS and HOSTN tables as presently constituted will cease to exist with the rewritten GTHST%. So you're essentially talking about a non-issue. I always thought it was a mistake to include gateways and networks in the host table because of these conflicts, but the person who wrote that code thought it was useful to have SYSDPY output symbolic names for them. Perhaps he was right. In any case, the present implementation should be considered interim only. It has many problems other than the obvious ones you point out. -- Mark -- ------- 24-Apr-84 16:58:36-PST,1183;000000000000 Mail-From: MRC created at 24-Apr-84 16:58:05 Date: Tue 24 Apr 84 16:58:05-PST From: Mark Crispin Subject: SKDPF1/ILULK2/IOPGF bugfix To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: SKDPF1, ILULK2 bughlts from AN20 service. AN20 buffer which should have been locked wasn't. Diagnosis: Buffer locked so many times that the lock count wraps around to zero. A path exists by which an AN20 buffer can avoid being unlocked. Proposed solution: THIS SOLUTION HAS NOT BEEN TESTED YET. PLEASE DO NOT INSTALL THIS PATCH UNLESS YOU ARE WILLING TO HELP ME DEBUG THE PROBLEM. Rewrite IMINRB to unlock the AN20 buffers before releasing: IMINRB::SETZ T1, ;RELEASE BUFFERS LEFT BY PI ROUTINES EXCH T1,IMINFB ;GET ALL GARBAGE BUFFERS DO. JXE T1,.RHALF,R ;DONE IF ALL RELEASED SETSEC T1,INTSEC ;IN THE RIGHT SECTION LOAD T2,NBQUE,(T1) ;FOLLOW DOWN ANY CHAIN CALL IMPULK ;UNLOCK AND RELEASE ONE MOVE T1,T2 ;GET THE NEXT BUFFER ADDRESS LOOP. ;SEE IF ANY MORE ON CHAIN ENDDO. ------- 24-Apr-84 19:55:54-PST,442;000000000000 Mail-From: MRC created at 24-Apr-84 19:55:42 Date: Tue 24 Apr 84 19:55:42-PST From: Mark Crispin Subject: previous patch To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There are other problems which make the previous patch invalid. Perhaps you want to hold off installing it until further notice. ------- 25-Apr-84 15:46:44-PST,699;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 25 Apr 84 15:46:07-PST Date: Wednesday, 25 April 1984, 14:38-PST From: Ken Olum Subject: IP + CHAOSNet To: tops-20 at score I am trying to make a monitor that handles both CHAOSNET and IP-over-ETHERNET (using a DTE) for Fairchild. Has anyone tried to do anything like this before? Is there a version of CHAOS.MAC that has been converted to use MULTINET? The file MULTINET.DOC from BBN claims that there is code for driving DTE-connected Ethernets, but the 5.3 source that I have (from DEC) doesn't have any such code. Has this code gotten lost somewhere? Help? Ken 26-Apr-84 17:28:15-PST,980;000000000000 Mail-From: MRC created at 26-Apr-84 17:28:00 Date: Thu 26 Apr 84 17:28:00-PST From: Mark Crispin Subject: EXEC bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is SPR 20-19955 which DEC has published as unanswered. Problem: Commands such as LOAD %"/NOINI" FOO blow up the EXEC with: ?String must be quoted Not logged off or similar lossage. This prevents building MM et al. This problem was introduced in the Autopatch 6 EXEC and is in the V6 EXEC as of this writing. Diagnosis: Routine CMPER in EXECCS attempts to insert a comma before any percent that is not preceeded by a comma. It blows it. Workaround: Patch out the JRST CMPER at CMIND+16. This will at least make the EXEC work as before. It is also necessary if you want to be able to use the supplied BUILD-MM.CTL file. ------- 27-Apr-84 06:15:26-PST,1563;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Apr 84 06:15:13-PST Date: 27 Apr 84 09:17:13 EST From: Don Subject: Re: EXEC bug To: MRC@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of 26 Apr 84 20:28:00 EST The problem here is that CMPER expects to have extra space (due to the "compact" reformatting it does on the command string) in the string it's copying from/to. It comes to the "%" and says "Ah, replace this with ",%". It then goes back to read from the string and finds the same "%", now shoved one character to the right - instant loop - overwriting *lots* of memory (hence the gibberish about "Not logged off"!). The following will make CMPER make space for any comma it tries to insert: Replace the IDPB Q1,CDPTR ;[941] WRITE THE COMMA PRECEED THE "%" SIGN at CMPER+4 with move a,cdptr ;[230] must make room to insert comma move b,cmppt0 ;[230] call subbp ;[230] movn c,a ;[230] move this many characters movei a,1 ;[230] increasing size of string by 1 addb a,cmpsiz ;[230] caile a,cmpmsz ;[230] still ok? error ;[230] no movni a,1 ;[230] must move string one to the left adjbp a,cmppt0 ;[230] move b,cmppt0 ;[230] movem a,cmppt0 ;[230] caie c,0 ;[230] be sure we're moving something sout ;[230] make room idpb q1,a ;[230] now put comma in string ldb a,csptr ;[230] get source char (%) again ------- 27-Apr-84 09:38:18-PST,3048;000000000001 Return-Path: <@COLUMBIA-20.ARPA:SY.SLOGIN@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Apr 84 09:37:55-PST Received: from CU20B by CUCS20 with DECnet; 27 Apr 84 12:39:44 EST Date: Fri 27 Apr 84 12:40:28-EST From: Thomas De Bellis Subject: DUMPER 402 To: Tops-20@SU-SCORE.ARPA Reply-to: CC.SLogin@COLUMBIA-20 Hello, Awhile ago I received a utilities update tape from DEC. Since our base DUMPER was pretty old (version 307 from 1980), I decided that I should probably bite the bullet and put up the new copy (version 402) that they sent us. I can only suppose that they must have made some kind of mistake and sent out a pre-released version. The quality of the product that I recieved was abysmal. If you are running this code, I strongly urge to you to read the rest of this message; I can save you a substantial amount of CPU time. DEC implemented a new feature that causes a ^A to type out the current file being looked at. This is very nice. Unfortunately, their implementation isn't. It really slows DUMPER down. A JFNS% is inserted in the main jfn stepping loop to write the current file name to a buffer which the ^A interrupt routine types out. You'd think they'd do something reasonable like having the ^A routine know enough to do the JFNS itself, since you're probably going to hit the ^A less times then you'll loop in the main jfn stepping code. But, no ... Worse, ^A and ^E interfere with each other. If you type a ^E and issue a command, STABLK gets trashed which breaks ^A. The most minimal testing would have revealed this. Other parts of DUMPER, most notably the CHECK code are slowed down by having to do a JFNS to update the ^A typeout buffer. The real kicker is that this information is ALLREADY availible in the tape buffer and all they had to do was BLT it into the ^A buffer. Oh yeah, they still have not installed Case Western's simple modifications (which merely involve moving a chunk of code) that dramatically improve incremental file scan time. I won't go on about all the other useless wastes of CPU time that I've fixed... On the brighter side, I made the ^A typeout code a little cuter by making it type out the page number of the current file being written to tape. That's fun to fool with. With a blocking factor of 14 and a density of 6250 BPI on a system with a load of 4.28, I was able to observe transfer rates in the hundreds of pages to tape per second. It also works on RESTORE and CHECK, too (on CHECK, it gets the page number from the tape record). Neat! The source is availible for anonymous FTP'ing from COLUMBIA-20 in PS:DUMPER.MAC. If you try it, please let me know how you make out. We (Columbia) and Case Western have been running it as our floor version for awhile so it's pretty safe. -- Tom Ps: I havn't gotten around to inserting the invalid archive date fix for you archivers. We don't run archiving here. ------- 27-Apr-84 13:33:54-PST,986;000000000001 Mail-From: G.DAIR created at 27-Apr-84 13:33:41 Date: Fri 27 Apr 84 13:33:41-PST From: Willis Dair Subject: Re: DUMPER 402 To: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Thomas De Bellis " of Fri 27 Apr 84 09:38:43-PST Phones: Work - 408/984-4082; Home - 408/923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 We have also found mucho problems with the new DUMPER. Control-E, as you mentioned does mess things up. We have found that sometimes DUMPER will write stuff out to random directories all by itself after a bunch of Control-E's. Also, I have SPR'ed a serious problem with DUMPER. If the offline expiration date is greated on the tape for a directory than the system default offline expiration date, a CREATE command will create "half-made" directories with no MAIL.TXT.1 file. If you will look back in the TOPS-20 archives, I have flamed about this before. Willis ------- 27-Apr-84 16:09:21-PST,796;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Apr 84 16:08:53-PST Date: Fri 27 Apr 84 16:08:40-PST From: Kirk Lougheed Subject: Stanford FTP bugfixes To: tops-20@SU-SCORE.ARPA People using the Stanford FTP should be aware of some recent bugfixes. The changed modules are FTP.MAC, TCPFTP.MAC, FTPUTL.MAC, and TCPXFR.MAC. The TCP only version of the program lives on PS: on Score; the multi-protocol version lives on PS: on Sierra. The problems fixed include: - Paged receive of binary files works correctly. - The two line variant of the GET command defaults generation numbers correctly. - 36-bit text files are sent to UNIX systems correctly. Kirk ------- 27-Apr-84 16:52:39-PST,1514;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Apr 84 16:52:01-PST Date: 27 Apr 1984 1950-EST From: Bob Longo To: G.Dair at SU-SCORE, TOPS-20 at SU-SCORE Mail-Stop: LAO Phone: 213-417-4240 Subject: Re: DUMPER 402 Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12010922960.19.355.26451 at DEC-MARLBORO> Regarding: Message from Willis Dair of 27-Apr-84 1642-EST The problem you are seeing with "half-made" directories with no MAIL.TXT file (also do not have directory groups and default generation-retention count is not set) is a problem with the monitor, not DUMPER. When CRDIR% is creating the directory for DUMPER, it checks the given offline expiration period against the system maximum, TPRCYC. Since you don't have the TAPE-RECYCLE-PERIOD command in 5-3-CONFIG.CMD, TPRCYC is never set. The monitor does not bother to check the system default when it finds TPRCYC is zero, it simply returns an ARGX27 and leaves an incomplete directory. Neglecting to check offline expiration period default, as well as archive expiration default period, happens at other places in the monitor besides CRDIR%. A temporary fix for the problem is to insert the following in your 5-3-CONFIG.CMD file: TAPE-RECYCLE-PERIOD 180 ARCHIVE-TAPE-RECYCLE-PERIOD 3650 These are what the defaults are supposed to be. -Bob -------- 27-Apr-84 22:44:23-PST,539;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Apr 84 22:44:15-PST Date: Sat 28 Apr 84 00:46:07-CST From: Clive Dawson Subject: Re: EXEC bug To: tops-20@SU-SCORE.ARPA Regarding the EXEC bug which Mark reported: if you want to get the LOAD, EXECUTE, etc. commands to work without patching the Exec, just include the (from) guide word. E.G. LOAD (from) %"/NOINI" FOO will work, whereas LOAD %"/NOINI" FOO will fail. Clive ------- 28-Apr-84 06:01:37-PST,745;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Sat 28 Apr 84 06:01:28-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629461748517215@MIT-MULTICS.ARPA>; 28 Apr 1984 09:02:28 est Date: 21 Apr 84 22:19 +0200 From: Son_VoBa_DEC-Marlboro%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Son_VoBa_DEC-Marlboro%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20@SU-SCORE.ARPA Subject: TYMCOM-20 Message-ID: <52551@QZCOM> The phrase for TYMCOM-20 and TOPS-20 is they are "bug for bug compatible". 29-Apr-84 15:59:35-PDT,1803;000000000001 Mail-From: MRC created at 29-Apr-84 15:59:27 Date: Sun 29 Apr 84 15:59:27-PDT From: Mark Crispin Subject: SKDPF1/IOPGF/ILULK2/PITRAP bugfixes To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have substantially rewritten IMPDV's buffer handling logic to fix bugs having to do with improper AN20 buffer locking and unlocking. There were a number of bugs and/or bogosities in DEC's code. What it comes down to is that the code was much too complicated, apparently in an attempt to be "efficient". What efficiency there was in the old logic perished with NCP and pre-Multinet monitors. The new code is substantially simpler in concept, incorporates some smaller routines together to prevent incomplete logic flows, and restores an important debugging functionality which broke some time ago. No major "efficiency" is lost; in fact for the most part the new routines are faster. The new IMPDV is on SU-SCORE as MRC:<5-3-MONITOR>IMPDV.MAC. Sites outside of Stanford will need to set the "STANSW" assembly parameter non-zero or rename it to their own local site-specific assembly parameter. STANSW=0 generates vanilla DEC code. People who don't have access to this file can get it from me individually as long as you have a DEC TCP license. I have reason to believe that I have fixed most if not all of the bugs that caused AN20 IO PAGE FAILs and various bughlts relating to ARPANET service. I definitely identified the bug which caused the system to crash "after a day or so"; that bug hid bugs which crashed the system immediately. Score has run for almost 16 hours with the rewritten code with no apparent problems. ------- 29-Apr-84 19:20:41-PDT,1051;000000000001 Mail-From: G.DAIR created at 29-Apr-84 19:20:23 Date: Sun 29 Apr 84 19:20:23-PDT From: Willis Dair Subject: Re: DUMPER 402 To: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Bob Longo " of Fri 27 Apr 84 16:50:00-PST Phones: Work - 408/984-4082; Home - 408/923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 The code around that area is pretty gross looking. It is really bad. GTDIR returns 180 whether TPRCYC is set or not. This should probably be set as a default instead of zero. What really bothers me about DUMPER is that the error is returned and DUMPER ignores it and no warning or error is printed. Having created the structure, I fought for 2 to 3 days fixing mail files. Finally, I wrote a program to make sure all directories had mail files. What I did was to remove the bits CD%FED and CD%NED in the CRDIR call ( this was the way the old DUMPER was set up). Hopefully, no one has to go through this same problem. Willis ------- 30-Apr-84 12:19:53-PDT,1097;000000000001 Mail-From: MRC created at 30-Apr-84 12:19:38 Date: Mon 30 Apr 84 12:19:38-PDT From: Mark Crispin Subject: Stanford TCP bugfixes To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have prepared a directory containing Stanford's TCP monitor bugfixes, minus all the STANSW references. These are pure source files, and the only way you can determine the changes are by FILCOM'ing with the vanilla DEC ones. The directory is: MRC: You may find these sources easier to deal with than the actual Stanford working sources; in particular these sources are guaranteed not to have Stanfordisms in it. In particular, the IMPDV.MAC on MRC:<5-3-MONITOR> has one Stanfordism: MAXWPM was moved from IMPDV to STG as we have a network which has uses a larger packet size than ARPANET. -- Mark -- PS to KWP: Please snarf these sources. In particular, please note the comments in TCPJFN re: EA.ENT in TCPOTS and why it is necessary. ------- 1-May-84 01:29:58-PDT,1175;000000000000 Mail-From: MRC created at 1-May-84 01:29:50 Date: Tue 1 May 84 01:29:50-PDT From: Mark Crispin Subject: Announcing: TOPS-20 Logo To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A TOPS-20 implementation of the popular teaching language "Logo" is now available. This is a port of the Unix implementation of Logo, which is more or less compatible with Apple and Atari Logo. Logo is written in C. Its source and EXE files can be FTP'd from SU-SCORE from PS:. The total size of the package including source and documentation files is less than 600 pages. There are also MIC procedures for building Logo, but you'll need the University of Utah's TOPS-20 PCC compiler to re-build Logo. More or less all the facilities of Unix Logo are implemented, including turtle graphics and the edit and pots commands. Kudos to Brian Harvey, the author of Unix Logo, for his help is porting it to Score. If anybody has any questions/comments/etc. about Logo they may be directed to BUG-LOGO@SU-SCORE. ------- 1-May-84 15:06:57-PDT,1132;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 1 May 84 15:06:48-PDT Date: Tue 1 May 84 15:09:32-PDT From: Greg Satz Subject: SPR Blues To: tops-20@SU-SCORE.ARPA I just received an answer to an SPR I sent in over one and a half years ago. At the time, I thought it was a fairly simple request. I asked DEC to pass more info to ACJ when a CRDIR% is executed; the Stanford monitor, and others I am sure, already do this. I was foolish enough to think DEC would be interested also. Here was DEC's reply: Thank you for your SPR. CRDIR% permission from ACJ was intended only to determine if the user should be permitted to create a directory. It is very difficult to return the parameters you request because the ACJ decision must be made before the directory is actually created. We will consider your suggestion ... To think that I waited for over a year for that? With todays modern form letter software, you would think DEC could have shot it down a little faster. Guess how I am going to fill out their SPR Answer Survey. ------- 1-May-84 16:13:58-PDT,843;000000000000 Mail-From: MRC created at 1-May-84 16:13:37 Date: Tue 1 May 84 16:13:37-PDT From: Mark Crispin Subject: Re: SPR Blues To: Satz@SRI-NIC.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Greg Satz " of Tue 1 May 84 15:06:59-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) That SPR answer, like many other SPR answers out of DEC, is full of it. It sometimes helps to include the working code to implement the desired feature, but nothing is guaranteed. Tell them the answer was unacceptable. WE are the customers; what we want is right by definition. At the obscene prices we pay for DEC-20's and DEC support we deserve better service than a 1 1/2 year delay to be told "see figure 1." ------- 1-May-84 20:50:06-PDT,1174;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 1 May 84 20:49:45-PDT Date: 1 May 1984 2322-EDT From: Tim Grady To: Greg Satz , tops-20 at SU-SCORE DTN: 231-6328 Mail Stop: MRO1-2/L10 Subject: Re: SPR Blues Message-ID: <"MS11(2370)+GLXLIB1(1056)" 12011999204.38.492.26012 at DEC-MARLBORO> References: Message from Greg Satz of 1-May-84 1813-EDT The delay is unfortunate, but is not a refusal. From your message, it sounds like you sent a suggestion, and it's being considered along with the hundreds of other suggestions that arrive in the form of SPR's. Sometimes the number and severity of critical SPR's can cause mistakes like the one that delayed your answer, but it does not sound like your suggestion was denied. I think you should indicate your dissappointment in the extreme delay, but I think that comments that categorize the content of the reply as a 'see figure 1' are exagerrated, and just plain uninformed. What was the additional information you requested CRDIR% supply to the ACJ? -------- 2-May-84 01:40:11-PDT,672;000000000000 Mail-From: ERIC created at 2-May-84 01:40:04 Date: Wed 2 May 84 01:40:04-PDT From: Eric Ostrom Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Grady " of Tue 1 May 84 20:22:00-PDT After 14 years of working with PDP-10's (including TENEX and TOPS-20), I regret to state that DEC's current treatment of 36-bit users could not be denigrated enough. Anyone who could characterize DEC's treatment of these customers (who made DEC), as anything BUT "See figure 1... (oh sorry, that document is no longer published)"...is just plain uninformed. eric ------- 2-May-84 07:34:36-PDT,1334;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 2 May 84 07:34:23-PDT Date: 2 May 1984 1032-EDT From: Tim Grady To: Eric Ostrom , TGRADY at DEC-MARLBORO, tops-20 at SU-SCORE DTN: 231-6328 Mail Stop: MRO1-2/L10 Subject: Re: SPR Blues Message-ID: <"MS11(2370)+GLXLIB1(1056)" 12012121263.29.492.19213 at DEC-MARLBORO> I'm not trying to address the treatment of all 36-bit customers over the recent past. My comments address the issue of 'suggestion' SPR's, and the fact that answers such as the one described, although delayed to an extreme, was not a 'see figure 1'. That is the field in which I have the expertise to respond. It would not be my place to try to explain the entire behaviour of the corporation, it's business decisions of the recent past, or their effects upon 36-bit customers. I understand such feelings, but I'm not in a position to do anything constructive about it, so if I can't say anything nice....I'll say nothing about it at all. I'm not pleased with the current strained relations between DEC and its 36-bit customers, and I'm actively involved in trying to improve that situation. That is the only reason I would get involved in such a discussion as this. -------- 2-May-84 07:44:53-PDT,874;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Wed 2 May 84 07:44:40-PDT Date: Wed 2 May 84 08:46:49-MDT From: Norm Samuelson Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA, Satz@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Grady " of Tue 1 May 84 21:22:00-MDT Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 At the very least, ACJ should see the bits which specify what the user is trying to change. I added that to the CRDIR% code a long time ago to prohibit users from changing their own passwords. The acutal arguments would be great, that would allow ACJ to validate a password for example, but the way it works now is almost useless. - Sam - ------- 2-May-84 08:44:22-PDT,1107;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 2 May 84 08:44:09-PDT Date: Wed 2 May 84 08:46:28-PDT From: Greg Satz Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Grady " of Tue 1 May 84 20:22:00-PDT Since Norm Samuelson has already described the CRDIR% enhancements, I won't bother. I am glad he did so as I probably would have told you to look up my original SPR. Isn't that what they are for? More and more I am learning that "I am on my own" when it comes to DEC to stand behind their DEC-20 product. Everyone is entitled to a mistake, but only if there is some activity to prevent such things from reoccurring. Why are good people, like yourself, staying with a company that doesn't want to continue doing good things for their customers? No one more than I would like to believe that DEC is willing to support their DEC-20s. However, when such things happen, as this SPR, it is painful to be reminded of reality. ------- 2-May-84 11:50:43-PDT,1926;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 2 May 84 11:50:27-PDT Date: 2 May 1984 1450-EDT From: Tim Grady To: Greg Satz cc: TOPS20 at SU-SCORE DTN: 231-6328 Mail Stop: MRO1-2/L10 Subject: Re: SPR Blues Message-ID: <"MS11(2370)+GLXLIB1(1056)" 12012168145.25.492.28906 at DEC-MARLBORO> That's the reason I suggested you express your dissappointment. The SPR answering mechanism is measured to a significant extent by the customer response to SPR answers, along with the number of outstanding unanswered SPR's (i.e. 'the backlog'), the number of really old ones (a year or more is truly ridiculous), and the number of high-priority ones. Periodically, an emphasis may be made on getting the really high-priority ones answered, which could cause what you experienced - I don't know for sure. High priority SPR's are typically not only important, but very difficult, and take up enormous resources. Take a look at the number of SPR's over the years that deal with PTNIC1 BUGHLT's. That was one single problem, with several attempts to patch, or mousetrap the cause, spread over six or seven years of effort. It finally got fixed last fall. I've been with DEC for years, and enjoy working in a large scale engineering development environment. Some of us have this personality deficiency that makes us want to be the vendor, and not the customer, I think. I don't think I could deal with being a customer. I have, in the past, done so as a customer of DEC, DG, and a few others, and found that DEC isn't any worse than most -- we could just be a lot better. Most important of all, though, is that a business is best served when we all act like businessmen, and all of the emotionalism in phrases like the 'see figure one' comments produces nothing but bad feelings. -------- 3-May-84 06:16:36-PDT,979;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 3 May 84 06:16:29-PDT Date: Thu 3 May 84 07:18:30-MDT From: Norm Samuelson Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA, Satz@SRI-NIC.ARPA cc: TOPS20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Grady " of Wed 2 May 84 12:50:00-MDT Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 DEC has officially told all their 36-bit customers to "see figure 1"! We have heard it from DEC so much that I did something yesterday I never thought I would have to do - I talked with an IBM salesman. It is irritating when the folks who choose to stay with DEC get irate when an EX-customer reminds them that DEC no longer cares for their business. If you get the idea that your comments irritated me, you are absolutely right! - Sam - ------- 3-May-84 08:19:38-PDT,585;000000000000 Mail-From: G.TJM created at 3-May-84 08:19:25 Date: Thu 3 May 84 08:19:25-PDT From: Ted Markowitz Subject: Re: SPR Blues To: Samuelson@SANDIA.ARPA, TGRADY@DEC-MARLBORO.ARPA, Satz@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Norm Samuelson " of Wed 2 May 84 07:45:07-PDT WHne trying to build some security checking in the ACJ for failed passwords, I found the lack of access to the argan enormous deficiency. I have to agree with Sam that the way it is now is almost completely useless. --ted ------- 3-May-84 12:45:55-PDT,1179;000000000001 Mail-From: MRC created at 3-May-84 12:45:36 Date: Thu 3 May 84 12:45:36-PDT From: Mark Crispin Subject: addendum to IMPDV fixes To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Problem: When using my IMPDV fixes, the system can crash with an INTBUF bughlt. Not as often as the SKDPF1/IOPGF/ILULK2 bugs, but still annoying. Diagnosis: IPIPIP objects to being told to fix a buffer that RLNTBF has already said is freed. Solution: In IMPDV.MAC, in the RLNTBF routine, there is a SETONE NBBSZ,(T2) ;MAKE THIS A FREE BUFFER which is above three instructions: CAML T2,[INTSEC,,BF1822] ;IS THIS AN 1822 BUFFER? CAML T2,[INTSEC,,BF1822+BF18SZ] ; ? JRST INTRBF ;NO, RELEASE TO INTERNET AREA Move the SETONE to below these three instructions (e.g. don't do it if we end up going to INTRBF). This is only appropriate for systems running my fixed IMPDV. Score was up for almost 90 hours with it, an uptime duration we haven't had since before we ran the latest DEC release of the monitor. ------- 3-May-84 15:12:03-PDT,1643;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Thu 3 May 84 15:11:33-PDT Date: Thu 3 May 84 16:13:30-MDT From: Norm Samuelson Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA cc: paetzold@DEC-MARLBORO.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Grady " of Thu 3 May 84 14:13:00-MDT Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 I will admit that DEC has not completely abandoned their 36-bit customers, if the recent cache and pager upgrades can help some people that is good. DEC has given up hope of developing a JUPITER-class machine, and that is what many of us need. What I am irritated about is that you went to the trouble of telling us we should be happy about it. WE ARE NOT HAPPY and we dont want to be told to look happy. If you can deliver a significantly faster 36-bit system to run TOPS-20 and ALL of our APPLICATIONS, then and only then will I look happy. The original note that started this was a simple complaint about a ridiculously bad answer to a simple request. Is that what you want us to be happy about? Is that the way DEC is demonstrating that the have not abandoned their 36-bit customers? Dont expect to change my opinion - it has taken time for me to develop the feelings I now have for DEC and it will take a long time for DEC to change them. Come back when the FOLLOW ON to the VENUS is ready and maybe you can win my loyalty back, but dont expect me to hold my breath. - Sam - ------- 3-May-84 22:20:02-PDT,664;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 3 May 84 22:19:51-PDT Date: 4 May 84 01:23:41 EDT From: Mel Subject: ACJ gaining access to passwords To: tops-20@SU-SCORE.ARPA Office: H028 - Hill Cntr, Busch Camp, Rutgers Univ, Piscataway, NJ x2287 Home: 81 Gage Road, East Brunswick, NJ 08816, (201) 828-8252 Just in case anyone is interested, we've developed the code in the monitor which will pass passwords to ACJ to look at. We haven't done much with it thus far but we do know that the monitor code works. If anyone is interested, just drop a line... -Mel ------- 2-May-84 00:28:46-PDT,2076;400000000001 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Wed 2 May 84 00:28:38-PDT Date: Wed 2 May 84 03:30:37-EDT From: Chris Maio Subject: Re: TCP bug hangs TOPS-20 To: VAF@CMU-CS-C.ARPA cc: Paetzold@DEC-MARLBORO.ARPA, MRC@SU-SCORE.ARPA In-Reply-To: Message from "Vince Fuller " of Wed 2 May 84 01:28:44-EDT I got a little further with the problem after my qual: Somebody is clearing the queue head that TCPBDQ points to, and REMBFS(TCPTCP) tries to chase down this list of buffers looking for buffers owned by a given TCB. Since the queue head pointed at by TCPBDQ is zero, REMBFS thinks that the first buffer on the list is at the beginning of INTSEC, and since the first page of INTSEC normally is normally non-existent, the would-be buffer looks like all zeros to REMBFS; at this point the list points to itself (the exit condition is a next-pointer that matches TCPBDQ). Since the internet fork has TCBHLK locked, ABTJCS (called from CLZFF%, RESET%, etc) hangs forever on the lock. Removing the NOINT/OKINT jacket would let you get into MDDT to fix things, but could cause other problems (it's there to ensure that TCBs aren't inherited by new forks with the same number as old one; I must have been asleep when I looked at it the first time). Anyway, it looks like the IPQDSW conditional stuff is either causing the problem or tickling a more subtle bug (especially since you're having the same problem with IPQDSW turned on). Our problems started after I had turned this on a while ago to try to track down a different problem which, (un)fortunately, hasn't appeared again. Rather than spend more time trying to figure out why the debugging code was causing the problem, I just turned it off. If you're interested in tracking it down, I've added a few debugging bugchks and some code in REMBFS to fix the bad pointer instead of looping forever (I haven't seen any problems since I put up the new monitor a few days ago). - Chris ------- 6-May-84 19:37:15-PDT,1422;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sun 6 May 84 19:37:01-PDT Date: 6 May 84 22:41:18 EDT From: Charles Hedrick Subject: anybody know how to do this? To: tops-20@SU-SCORE.ARPA In Common Lisp, there is a function LISTEN. It is supposed to return T if it is possible to read something immediately from a certain file, and NIL if not. NIL indicates either an asynchronous device (e.g. terminal) which is open but has no characters in the buffer at the moment, or a file that is at end of file. Is there some simple way to do this in Tops-20? I can't think of any. I don't see any way to tell whether there are any characters left before EOF. In GTSTS, the EOF bit isn't set until one tries to read beyond the EOF. We want to predict whether there is another character or not. I realize that I can implement this with device-specific code. I even know what that code would look like for many devices. But somebody could always open a device I don't know about (e.g. DECnet). And I don't see any way to tell about EOF on a tape drive or a network without actually trying to read the next character. At least for a network connection, if there is nothing in the input buffer, that read could cause the program to go into input wait, which is what this function is trying to prevent in the first place. ------- 7-May-84 06:46:28-PDT,756;000000000001 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 7 May 84 06:46:16-PDT Date: Mon 7 May 84 07:49:35-MDT From: Randy Frank Subject: Continued Use of DLUSER To: tops-20@SU-SCORE.ARPA Is there any good reason to be continuing to run DLUSER as part of a file save procedure to save directory information, or is it now totally redundant since DUMPER can now save and restore directory information. We (for historical reasons) have continued to DLUSER to save and restore directory information, but in thinking about it I can't see any good reason for doing it. Am I missing something? Is there still some (good) reason for using DLUSER, or is it a relic from the past. ------- 7-May-84 07:07:52-PDT,1618;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 7 May 84 07:07:40-PDT Date: 7 May 1984 1008-EDT From: Tim Grady To: Samuelson at SANDIA, TGRADY at DEC-MARLBORO cc: paetzold at DEC-MARLBORO, tops-20 at SU-SCORE DTN: 231-6328 Mail Stop: MRO1-2/L10 Subject: Re: SPR Blues Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12013427621.24.492.10196 at DEC-MARLBORO> Regarding: Message from Norm Samuelson of 5-May-84 1047-EDT No, we're getting closer to the right idea here....Once again, my only contention from the start of this discussion is that DEC has not abandoned 36-bit customers, and that the only productive way to deal with objections to the business decisions that have been made over the recent past is to do so in a business-like fashion, and not with emotionalism. I don't expect people to be happy with the way things are, and I indicated in the case of this SPR how to express that unhappiness in a fashion that is properly directed. It's a shame that things were handled so badly that such bad feelings were inspired, but nevertheless there are two ways to express them: one of which will be productive. Once again, the original SPR was answered in the only reasonable way, but took a ridiculously long time to get answered. The right way to indicate displeasure is through the little customer satisfaction card that comes with the answer (they really do get used). In the mean time I hope I've shead some light on the way SPR's are dealt with. -------- 7-May-84 12:16:08-PDT,508;000000000000 Return-Path: Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Mon 7 May 84 12:15:58-PDT Date: 7 May 1984 15:17-EDT Sender: DIPACE@BBNF.ARPA Subject: TENEX era ends From: DIPACE@BBNF.ARPA To: Tops-20@SU-SCORE.ARPA Cc: Chipman@BBNF.ARPA Message-ID: <[BBNF.ARPA] 7-May-84 15:17:32.DIPACE> A note in passing... Today BBN shut down BBNB it's last TENEX system. The KA10 based TENEX systems, that had been away of life at BBN for over a decade, are now part of the past. 7-May-84 12:45:36-PDT,759;000000000001 Mail-From: G.DAIR created at 7-May-84 12:45:01 Date: Mon 7 May 84 12:45:01-PDT From: Willis Dair Subject: Re: Continued Use of DLUSER To: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Mon 7 May 84 06:46:33-PDT Phones: Work - 408/984-4082; Home - 408/923-BRIM Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053 All of our refreshes are done with the CREATE command in DUMPER. Seems to work fine, except for when we found the awful CRDIR% bug in DUMPER 402/Monitor. Since fixing the bug, it works fine again. The only reason I use DLUSER is for moving data from one structure to another by creating the directories first and doing copies. Willis ------- 7-May-84 13:30:46-PDT,1681;000000000000 Mail-From: MRC created at 7-May-84 13:30:23 Date: Mon 7 May 84 13:30:23-PDT From: Mark Crispin Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA cc: Samuelson@SANDIA.ARPA, paetzold@DEC-MARLBORO.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tim Grady " of Mon 7 May 84 07:08:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Dear Tim - I fear you still don't understand: (1) The SPR was NOT answered in a "reasonable way." The answer implies that nobody took more than the most casual look at the problem, because several customer sites (including Stanford) have fixed this deficiency. It is not that difficult a problem to fix. I imagine even a DDT patch is practical. (2) DEC HAS abandoned 36-bit customers. Any statement to the contrary is pure unadulterated bull. The only thing which would not constitute abandonment of 36-bit customers is active and aggressive development of new 36-bit CPU's. (3) DEC's customers HAVE abandoned DEC. We may still buy DEC products because we are locked into DEC, but we are working actively to punt that dependency as soon as possible. Never again will we buy another hardware-vendor proprietary operating system. From now on, we'll buy from DEC only when DEC has the best product to offer (hint: it ain't VAX in hardware, or VMS in software). I will however admit that you are the wrong person to flame at. It is important to realize that you are inviting those flames by defending an essentially indefensible position. -- Mark -- ------- 7-May-84 14:28:09-PDT,1849;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Mon 7 May 84 14:27:51-PDT Date: Mon 7 May 84 15:29:42-MDT From: Tom Linnerooth Subject: Re: SPR Blues To: TGRADY@DEC-MARLBORO.ARPA cc: TOPS-20@SU-SCORE.ARPA As long as you are willing to become involved in this issue, I will add a recent experience. On 16-Mar-83, I submitted SPR 20-19018 which was acknowledged by DEC on 30-Mar-83. This SPR pertained to the failing of DSK*: when used with a public structure having a name other than PS:. This SPR was never answered. (I submitted it as a PROBLEM/ERROR with MINOR SYSTEM IMPACT). In the 1-May-84 DISPATCH, an identical SPR (No. 20-19927, page 3-71) was answered. (This SPR was also submitted as a PROBLEM/ERROR with MINOR SYSTEM IMPACT). Why was my SPR not answered in over 13 months while the other was answered in less than 4 months? I always felt I have been patient and tolerant with DEC, but apparently this cuts no ice. What is it that I don't understand about the SPR submittal process? Am I supposed to enclose some money in addition to the outrageous monthly fee I understood to include SPR service? What does it take to get your attention? Incidently, i just submitted another SPR saying the same thing as this message. Coincidentally, today I recieved a notebook entitled "Digital's Software Information Network - User's Guide". The first paragraph in the cover letter includes the following: "This manual supplies detailed information on ways to make the best use of this exciting new software service tool." I have a very sick feeling that with respect to TOPS-20, this "exciting new" tool will be almost as useful as the current service (or lack thereof) that I am presently getting. Tom Linnerooth ------- 7-May-84 15:18:45-PDT,1710;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Mon 7 May 84 15:18:21-PDT Date: 07 May 84 15:20:29 PDT (Mon) To: tops-20@Su-Score cc: raj@UCI-750a Subject: Mail problems on 2020's From: Richard Johnson We are currently running Tops-20 V4.1 autopatch level 6 on two 2020's. On our system (I'm not sure how standard this is) whenever anyone sends someone a mail message the "last writer" field is set to the textual name of the sender. When the person next logs in he receives a message via the EXEC something like: RAJ has mail from JOE SMITH at 10:32:55 The problem with this is that the "last writer" field is printed out using (evidently) a subroutine which interprets such things as "%A", "%B", etc. as different formatting options. This means that if a person receives mail over a network (we have a local network which allows 2020 users to communicate with the ARPANET) he may get a message like: RAJ has mail from JOE SMITH00:00:03 at 10:32:55 since the "from" address may be: "JOE SMITH%ANYHOST and the "%A" means (for instance) "print CPU time for the job so far". The problem arises when a local user receives mail from: RESTIVO%SU-(something) (I forgot the actual address) and the "%S" means to print the next argument to the routine as a string. This generates an illegal memory reference, etc., etc., and results in not allowing the person to login. Question: Is this a local problem or does it occur elsewhere? It seems to be a problem with the DEC EXEC (with no local modifications) but I want to be sure. Is there a fix? (We don't have sources.) Richard Johnson UCI ICS Support Group 7-May-84 16:53:50-PDT,599;000000000000 Mail-From: MRC created at 7-May-84 16:53:41 Date: Mon 7 May 84 16:53:41-PDT From: Mark Crispin Subject: Re: Mail problems on 2020's To: raj@UCI-750A.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Richard Johnson " of Mon 7 May 84 15:20:29-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Richard - It is an EXEC bug; there was an SPR fix for it. You have to use %M instead of %\ in the string pointed to by a HRROI at MALCH2-2. -- Mark -- ------- 9-May-84 06:30:12-PDT,1253;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Wed 9 May 84 06:30:01-PDT Date: Wed 9 May 84 09:30:05-EDT From: Donna Lynch Subject: Autopatch 7/Link To: Tops-20@SU-SCORE.ARPA Can anyone help? I am trying to AUTOPATCH again, this time tape 7 and LINK. I tried the RESTORE, DESELECT and SELECT as suggested in the README.007. I got a signal failure from PEPB. I then got rid of all the link files to start as if never having AUTOPATCHED. I restored files from INSTALLATION and DISTRIBUTION tapes. Same error. The first time the "?UPDDEL text ..." outputted between PLTIO and LNKLOD and the last time after all the files as shown below: @RUN ASL:UPDATE **@PAT:LNKV51.SUP PAT:LNKCOR.MAC=ASL:LNKCOR.MAC,PAT:LNKCOR.C06 PAT:PLTIO.MAC=ASL:PLTIO.MAC,PAT:PLTIO.C06 PAT:LNKLOD.MAC=ASL:LNKLOD.MAC,PAT:LNKLOD.C06 . . . PAT:LNKINI.MAC=ASL:LNKINI.MAC,PAT:LNKINI.C07 PAT:OVRLAY.MAC=ASL:OVRLAY.MAC,PAT:OVRLAY.C07 ?UPDDEL Text to be deleted doesn't match base file at 2/1 * These files were all restored from the distribution and installation tapes. I don't know where to go from here. Thanks for any help, Donna ------- 9-May-84 11:26:46-PDT,456;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 9 May 84 11:26:27-PDT Received: ID ; Fri 4 May 84 15:34:55-EDT Date: Fri 4 May 84 15:34:55-EDT From: Vince Fuller Subject: TFTP/UDP query To: TOPS-20@SU-SCORE.ARPA Does anyone know if a general TOPS-20 implementation of UDP exists? Also, has anyone written a TFTP user and/or server program? --Vince ------- 10-May-84 11:00:33-PDT,493;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.BILL@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 10 May 84 11:00:23-PDT Received: from CU20B by CUCS20 with DECnet; 10 May 84 14:03:45 EDT Date: Thu 10 May 84 14:03:03-EDT From: Bill Schilit Subject: FTS-20 To: tops-20@SU-SCORE.ARPA DEC sells a spooled DECnet file transfer program (something like a spooled NFT) called FTS-20. Has anyone heard any good/bad news about this product? - Bill ------- 10-May-84 14:10:27-PDT,1476;000000000001 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 10 May 84 14:10:06-PDT Date: Thu 10 May 84 16:14:05-CDT From: Clive Dawson Subject: DEC Advertising screwup To: tops20@SU-SCORE.ARPA cc: oc.maltz%CU20B@COLUMBIA-20.ARPA In the last couple of days some of you may have received a DEC advertising flyer for the TU80 streaming tape subsystem. Let me quote from some of the listed highlights: Fully supported on ALL Digital operating systems [My emphasis.] The flyer tells you to call 800-343-4040 x 682 for more information. I would like to urge people on this list to call the number and ask about getting one of these units for your DEC-20. When they tell you it won't run on a 20, give 'em hell for false advertising! Incredible as it may seem, when I did this, the yo-yo on the other end of the line actually tried to tell me the above statement was true, because "the operating system is software, but actually the TU80 isn't supported on the DEC-20 hardware"...!! Once again we see evidence that despite oral claims to the contrary, DEC is on its way toward forgetting that 36-bit systems and customers ever existed. In case it's not clear, I don't really care whether the TU80 ever runs on the 20 or not; what gripes me is the fact that DEC has apparently chosen to redefine the word "all" when refering to its product line. Cheers, Clive ------- 10-May-84 14:53:29-PDT,417;000000000000 Mail-From: MRC created at 10-May-84 14:53:11 Date: Thu 10 May 84 14:53:11-PDT From: Mark Crispin Subject: portable Logo update To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is a new release of portable Logo on PS: at Score. It contains a few bug-fixes. ------- 10-May-84 17:37:08-PDT,414;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 10 May 84 17:36:57-PDT Date: Thu 10 May 84 17:42:17-PDT From: Haruka Takano Subject: Swap space To: TOPS-20@SU-SCORE.ARPA Does anyone out there have a program that will tell me who's currently eating up swap space? Anyone have any ideas on how to go about doing this? --Haruka ------- 10-May-84 21:09:11-PDT,1411;000000000000 Mail-From: ALMQUIST created at 10-May-84 21:08:58 Date: Thu 10 May 84 21:08:58-PDT From: Philip Almquist Subject: Re: FTS-20 To: Sy.Bill%CU20B@COLUMBIA-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bill Schilit " of Thu 10 May 84 11:00:36-PDT Bill, I have never actually used FTS-20, but my recollections of a conversation with someone who saw a very early version of it suggested it would be less than wonderful. Hopefully these comments are obsolete or based on poor memory on my part, but.. FTS-20 seemed to have been ported from a PDP-11 system with the minimum possible modification. File transfer was affected by CRJOB'ing a job as the user who had made the request and forcing it to run NFT (the DECnet file transfer program, for the benefit of you ARPA readers). It seemed rather likely that there were security problems resulting from this implementation choice. Although FTS-20 uses a queue and transfers are initiated by the operator no attempt had been made to integrate FTS-20 with Galaxy, making it necessary for both users and operators to learn a new interface. It seemed to me that some sort of intelligent automatic starting and stopping of queued transfers based on load average, net traffic, or whatever might have been a good idea, but there was no sign of any such feature. Philip ------- 11-May-84 06:40:23-PDT,797;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Fri 11 May 84 06:40:16-PDT Date: Fri 11 May 84 07:43:06-MDT From: Norm Samuelson Subject: Re: FTS-20 To: Sy.Bill%CU20B@CMU-CS-C.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bill Schilit " of Thu 10 May 84 12:06:34-MDT Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 As I remember it, FTS-20 is already obsolete. DEC did something with the Data Interchange Library (DIL) and talked about a product called DIU (Data Interchange Utility) that was to replace FTS-20. I have never used either one, but my guess is that FTS-20 is not worth anything. - Sam - ------- 11-May-84 09:44:58-PDT,1265;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Fri 11 May 84 09:44:42-PDT Date: Fri, 11 May 84 09:47 PDT From: Samuelson%LLL@LLL-MFE.ARPA Subject: Looking for a DA-28 To: tops-20@su-score.arpa The Magnetic Fusion Energy Network (MFEnet) is somewhat dependent on an old, obsolete piece of DEC equipment of which few were ever manufactured. That is the DA-28 Inter Processor Buffer (It allows DMA transfers between a PDP-11 and a PDP-10). A while back we lost one of the DA-28s on our net, and that host was off the net for six weeks while waiting for DEC to fix it. The only reason they got up after six weeks was that a spare DA-28 was found in Canada. DEC still has not been able to fix the old one. This has raised some concern amongst the MFEnet managers and the Department of Energy. We are trying to find a way out of this bad situation to keep our network running until the PDP-10s are retired. One possible solution is to find another DA-28 sitting in some closet collecting dust. If you have a DA-28, or if you know of one that might be available, PLEASE let me know. We had a lead on one last year, but somebody lost the only record we had of it (a business card)... - Sam - 11-May-84 13:09:23-PDT,1097;000000000000 Mail-From: MRC created at 11-May-84 13:09:13 Date: Fri 11 May 84 13:09:13-PDT From: Mark Crispin Subject: SPR's again To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) At a DECUS symposia, I asked about the possibility of having a bit added to ODTIM% for RFC 822 format (apparently it is based on some other standard time format, so it isn't unreasonable). Right now, ODTIM% cannot output a date in the form Fri, 4 May 84 13:08:23 PDT The developers at DECUS said "okay, we'll do it, but you should SPR it too." I did so. The answer I got was, in effect, "see figure 1." It stated that this change would not be put in, and indeed, it doesn't appear to be in release 6. The wording of the answer was also rather rude. I personally feel that SPR'ing something is almost worthless. The percentage of good SPR answers seems to be about only 30-40%. Unlike certain people, I don't get off on sending 10 SPR's a month. ------- 11-May-84 13:28:12-PDT,944;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 11 May 84 13:27:45-PDT Date: 11 May 1984 1630-EDT From: Kevin Paetzold To: MRC at SU-SCORE, TOPS-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: Re: SPR's again Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12014545701.32.126.13314 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 11-May-84 1617-EDT as a matter of fact i have a copy of your odtim request in my office and it is on my list of things to do. i suspect i will get at it sometime before 6.1 goes out the door. you did not receive a "see figure one" regardless of what you think. i guess we should have worked on your bit for odtim instead of things like cfs. must be our priorities are all wrong. -------- 11-May-84 13:58:12-PDT,882;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 11 May 84 13:57:58-PDT Date: 11 May 1984 1700-EDT From: Kevin Paetzold To: MRC at SU-SCORE cc: tops-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: Re: SPR's again Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12014551189.32.126.20014 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 11-May-84 1617-EDT as a matter of fact I just checked and spr number 20-19776 which is your idtim/odtim spr is in my office and i have not answered it. you received a standard form letter which happens whenever an spr has been classed as a suggestion. a suggestion is anything that is not a bug in existing code. -------- 12-May-84 14:34:04-PDT,1302;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 12 May 84 14:34:01-PDT Date: Sat 12 May 84 14:33:46-PDT From: Kirk Lougheed Subject: PUP crashes To: su-tops-20@SU-SCORE.ARPA I've found the source of the PUP related crashes whose symptoms were that the iorb free list would become entangled with one of the PUP packet buffer free lists. Trying to remove a buffer from the tangled lists would result in an ILMNRF, an ILPSEC, or a PITRAP bughlt. Such bughlt's were common when the Ethernnet cable was cut or when Len was TDR'ing a stretch of cable near a -20. The problem was in the PUP read termination room (PUPINR). After detecting a bad transfer (error flag in the iorb status word), the code would release first the packet buffer, then the iorb. Releasing the packet buffer first caused the pointer to the iorb to be trashed, resulting in junk (usually a free list header) being appended to the iorb queue. The solution is to reverse the order in which the packet and the iorb are released. The DDT patch is as follows: PUPINR+13/ CALL RELPBI -> CALL RELIRB +14/ JRST RELIRB -> JRST RELPBI The corrected source is PS:<5-3-MONITOR>PUP.MAC.669 on Sierra. Kirk ------- 13-May-84 23:00:09-PDT,1278;000000000000 Mail-From: MRC created at 13-May-84 22:59:59 Date: Sun 13 May 84 22:59:59-PDT From: Mark Crispin Subject: more TOPS-20 Logo To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have done some additional work to TOPS-20 Logo, as well as incorporating Brian Harvey's latest bugfixes to the language. The newest batch of fixes are in the handling of the "edit" and "unix" commands. Under Unix, it is not necessary to preserve and restore the terminal modes when invoking an inferior process but on TOPS-20 it is. Needless to say, the C compiler should do the work, but it doesn't. Also, Logo now has its own private version of the C execv and execl subroutines which correctly place an end of line character in the rescan buffer for programs which really expect to see eol to terminate a rescan command. The new version of portable Logo is on PS: at Score. You will need the University of Utah's Portable C compiler (PCC) to build Logo, otherwise just use the LOGO.EXE on PS:. On Score, a jacket program called PLOGO is on SYS: to run PS:LOGO.EXE to avoid confusion with the LOGOUT command. ------- 14-May-84 14:34:50-PDT,584;000000000000 Mail-From: MRC created at 14-May-84 14:34:36 Date: Mon 14 May 84 14:34:36-PDT From: Mark Crispin Subject: minor IPFREE bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This bug isn't too important, as the assembled code is right, but the DEFSTR of USIZE in IPFREE.MAC should read as DEFSTR(USIZE,0,17,18) and not DEFSTR(USIZE,0,17,35) the way it is in the code. Fortunately, a size of 35 bits up to bit 17 doesn't mean too much. ------- 14-May-84 17:29:23-PDT,554;000000000000 Mail-From: MRC created at 14-May-84 17:29:15 Date: Mon 14 May 84 17:29:15-PDT From: Mark Crispin Subject: TCPJFN bug? To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think there should be a SETZM FILTCB(JFN) at TCPCLX+5 or thereabouts (after the ABORT%). This seems to be a path that FILTCB isn't cleared that ultimately leads us to bogusly flush it at TCPRJF. This may be a cause of INTFR1 bughlts. ------- 14-May-84 17:31:50-PDT,371;000000000000 Mail-From: MRC created at 14-May-84 17:31:34 Date: Mon 14 May 84 17:31:34-PDT From: Mark Crispin Subject: more FILTCB To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I also suspect there should be one after the ABORT% in TCPOP4. ------- 15-May-84 06:54:46-PDT,829;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 15 May 84 06:54:36-PDT Date: 15 May 1984 0956-EDT From: Allan Titcomb To: TOPS-20 at SU-SCORE DTN: 231-4849 LOC: MR2-2/8D2 Subject: TOPS-10 Systems on ARPANET Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12015522529.10.270.7728 at DEC-MARLBORO> Does anyone know of a TOPS-10 system on the net? The University of Saarlandes, Saarbruecken (Germany) would like to demo during a trip here their natural language package called HAM-ANS. They seem to have developed it under TOPS-10 using UCI-Lisp/Fuzzy. I suppose that I am the one that should know the answer to this question since WPAFB uses/used TOPS-10 and was on the net for many years back in the NCP days. Allan -------- 15-May-84 09:05:02-PDT,644;000000000000 Return-Path: Received: from CMU-CS-A.ARPA by SU-SCORE.ARPA with TCP; Tue 15 May 84 09:04:37-PDT Date: 15 May 84 1203 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: Allan Titcomb Subject: Re: TOPS-10 Systems on ARPANET CC: TOPS-20@SU-SCORE.ARPA In-Reply-To: <"MS10(2124)+GLXLIB1(1136)" 12015522529.10.270.7728 at DEC-MARLBORO> Message-Id: <15May84.120315.IM2P@CMU-CS-A.ARPA> Umm.. CMU-CS-A CMU-CS-B LLL-MFE WPAFB-AFAL The last of the bottoms-10...still going strong though. The best part is the two CMU sites are still running 6.02! Well...not for long. -Rudy 15-May-84 12:16:32-PDT,1503;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Tue 15 May 84 12:16:11-PDT Date: 15 May 1984 12:15-PDT Sender: JAMES@USC-ECL Subject: Mailing List From: JAMES@USC-ECL Bcc: AILIST-REQUEST@SRI-AI Bcc: AMETHYST-USERS-REQUEST@SIMTEL20, APOLLO-REQUEST@YALE Bcc: ARMS-D-REQUEST@MIT-MC, KOOLISH@BBN-UNIX Bcc: CADINTEREST^.ES@PARC-MAXC, CHESS-REQUEST@SRI-UNIX Bcc: COMICS-LOVERS-REQUEST@SRI-NIC Bcc: CUBE-LOVERS-REQUEST@MIT-MC Bcc: EDITOR-PEOPLE-REQUEST@SU-SCORE Bcc: EXTENDED-ADDRESSING-REQUEST@SANDIA Bcc: HUMAN-NETS-REQUEST@RUTGERS Bcc: ICON-GROUP-REQUEST.ARIZONA@RAND-RELAY Bcc: INFO-ADA-REQUEST@MIT-MC, INFO-APPLE-REQUEST@BRL-TGR Bcc: INFO-ATARI-REQUEST@SU-SCORE Bcc: INFO-AUDIO-REQUEST@MIT-MC, INFO-CPM-REQUEST@MIT-MC Bcc: INFO-GRAPHICS-REQUEST@UTEXAS-20 Bcc: INFO-MAC-REQUEST@SUMEX-AIM Bcc: INFO-TERMS-REQUEST@MIT-MC, INFO-VAX-REQUEST@SRI-CSL Bcc: INFO-VLSI-REQUEST@SANDIA Bcc: LASER-LOVERS-REQUEST@WASHINGTON, ZELLICH@SRI-NIC Bcc: NESFA-REQUESTS@MIT-MC, PHYSICS-REQUEST@SRI-UNIX Bcc: PROLOG-REQUEST@SCORE, SF-LOVERS-REQUEST@RUTGERS Bcc: MCGREW.SMAUG@RU-BLUE, SPACE-REQUEST@MIT-MC Bcc: TEXHAX@SU-AI, TOPS-20@SU-SCORE Bcc: UNIX-EMACS-REQUEST@CMU-CS-C Bcc: UNIX-TEX-REQUEST@WASHINGTON Bcc: VIDEODISC-REQUEST@MIT-MC, HOME-SAT-REQUEST@MIT-MC Bcc: KAHN@UCLA-CS Message-ID: <[USC-ECL]15-May-84 12:15:22.JAMES> Please include me on your mailing list. My name is Mark L. James and I work for JPL-NASA. Thank You, Mark 15-May-84 12:25:17-PDT,998;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Tue 15 May 84 12:24:59-PDT Date: Tue 15 May 84 15:24:53-EDT From: Donna Lynch Subject: AP#7/LINK To: TOPS-20@SU-SCORE.ARPA cc: ADMIN@RADC-TOPS20.ARPA I received a call from an autopatch person in Marlboro. There is an error in LNKV51.CTL: LINK:: @PEPB *INITIALIZE LINK-20-V5-1 *EXIT ! ! Delete all older intermediate sources. ! @DELETE PAT:LNK%%%.MAC,PAT:PLT%%%.MAC This last line should read: @DELETE PAT:LNK*.MAC,PAT:PLT*.MAC,PAT:OVR*.MAC with the previous line PLTIO.MAC does not get deleted and obviously OVRLAY.MAC didn't get deleted. Much to my dismay, I also found out that I didn't have to AUTOPATCH Link, I could just use the LINK.EXE that is on the AUTOPATCH tape. Was I supposed to know this? I have done autopatch one time previous to this. Are there other little (big) hints that I should know about? --Donna ------- 15-May-84 12:31:11-PDT,1503;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Tue 15 May 84 12:30:49-PDT Date: 15 May 1984 12:15-PDT Sender: JAMES@USC-ECL Subject: Mailing List From: JAMES@USC-ECL Bcc: AILIST-REQUEST@SRI-AI Bcc: AMETHYST-USERS-REQUEST@SIMTEL20, APOLLO-REQUEST@YALE Bcc: ARMS-D-REQUEST@MIT-MC, KOOLISH@BBN-UNIX Bcc: CADINTEREST^.ES@PARC-MAXC, CHESS-REQUEST@SRI-UNIX Bcc: COMICS-LOVERS-REQUEST@SRI-NIC Bcc: CUBE-LOVERS-REQUEST@MIT-MC Bcc: EDITOR-PEOPLE-REQUEST@SU-SCORE Bcc: EXTENDED-ADDRESSING-REQUEST@SANDIA Bcc: HUMAN-NETS-REQUEST@RUTGERS Bcc: ICON-GROUP-REQUEST.ARIZONA@RAND-RELAY Bcc: INFO-ADA-REQUEST@MIT-MC, INFO-APPLE-REQUEST@BRL-TGR Bcc: INFO-ATARI-REQUEST@SU-SCORE Bcc: INFO-AUDIO-REQUEST@MIT-MC, INFO-CPM-REQUEST@MIT-MC Bcc: INFO-GRAPHICS-REQUEST@UTEXAS-20 Bcc: INFO-MAC-REQUEST@SUMEX-AIM Bcc: INFO-TERMS-REQUEST@MIT-MC, INFO-VAX-REQUEST@SRI-CSL Bcc: INFO-VLSI-REQUEST@SANDIA Bcc: LASER-LOVERS-REQUEST@WASHINGTON, ZELLICH@SRI-NIC Bcc: NESFA-REQUESTS@MIT-MC, PHYSICS-REQUEST@SRI-UNIX Bcc: PROLOG-REQUEST@SCORE, SF-LOVERS-REQUEST@RUTGERS Bcc: MCGREW.SMAUG@RU-BLUE, SPACE-REQUEST@MIT-MC Bcc: TEXHAX@SU-AI, TOPS-20@SU-SCORE Bcc: UNIX-EMACS-REQUEST@CMU-CS-C Bcc: UNIX-TEX-REQUEST@WASHINGTON Bcc: VIDEODISC-REQUEST@MIT-MC, HOME-SAT-REQUEST@MIT-MC Bcc: KAHN@UCLA-CS Message-ID: <[USC-ECL]15-May-84 12:15:22.JAMES> Please include me on your mailing list. My name is Mark L. James and I work for JPL-NASA. Thank You, Mark 16-May-84 07:01:33-PDT,562;000000000001 Return-Path: <@CMU-CS-C.ARPA:WEINSTOCK%TARTAN@CMU-CS-C.ARPA> Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 07:01:25-PDT Received: from TARTAN by CMU-CS-C with TLnet; 16 May 84 10:03:11-EDT Received: ID ; Wed 16 May 84 09:27:03-EDT Date: Wed 16 May 84 09:27:02-EDT From: Charles B. Weinstock Subject: TU80 To: Tops-20@SU-SCORE.ARPA I just called the 800 number. "Sure it's supported on all operating systems, but TOPS-20 is a big system!" Incredible. ------- 16-May-84 07:27:42-PDT,754;000000000001 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 07:27:33-PDT Date: Wed 16 May 84 10:32:49-EDT From: Gordon Strong Subject: TU80 To: tops-20@SU-SCORE.ARPA When we called the number, we said that we wanted to see one running on a -20 before we bought one. The guy on the phone said "there must be 6 or 7 at MIT by now". There are 4 -20's here and none of them have the TU80. The people they put on these "hotlines" must be dropouts of VAX repair school or something. He didn't even know that they wouldn't work under Tops-20, he had to ask someone. We told him "but the worst thing is that the flyer is ORANGE. Everyone knows that is the -20's color..." ------- 16-May-84 07:38:35-PDT,334;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 07:38:26-PDT Date: Wed 16 May 84 10:41:40-EDT From: Rich Cower Subject: 20 Color To: tops-20@SU-SCORE.ARPA I've heard the new color scheme is BLACK. Seems appropriate... ..Rich ------- 16-May-84 08:18:20-PDT,539;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 08:18:11-PDT Date: Wed 16 May 84 08:20:29-PDT From: Greg Satz Subject: Re: 20 Color To: COWER@COLUMBIA-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Rich Cower " of Wed 16 May 84 07:49:37-PDT Speaking of black, has anyone looked at all of the "integration" titles in the DECUS preregistration booklet? Maybe we should all wear black for the entire week. ------- 16-May-84 12:57:47-PDT,604;000000000000 Return-Path: Received: from SANDIA.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 12:57:33-PDT Date: Wed 16 May 84 13:59:44-MDT From: Norm Samuelson Subject: Re: TOPS-10 Systems on ARPANET To: TITCOMB@DEC-MARLBORO.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Allan Titcomb " of Tue 15 May 84 07:56:00-MDT Postal-Address: LLNL, POBox 5511, L-630, Livermore, CA 94550 Telephone: (415) 422-0661, [FTS 532-0661], home (415) 447-5345 LLL-MFE is a TOPS-10 system that is on the arpanet (milnet). - Sam - ------- 16-May-84 17:58:46-PDT,1384;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 17:58:22-PDT Date: Wed 16 May 84 19:01:29-MDT From: Randy Frank Subject: 2065 and 64K memory announced To: tops-20@SU-SCORE.ARPA the KL cache and hardware page table upgrade, and 64K memory have been announced. The 2065 upgrade (which supposedly gives you a 20% performance improvement) is $40K, and the new memory is $28K a megaword. I guess the good news is that memory prices are finally coming down from the stratosphere (about $6K a megabyte is at least within shooting range of Vaxc memory prices, although why DEC couldn't just byte the bullet and make the 20 competitive for once with equivalent Vax hardware prices is beyond me). Also, as I understand it, the megaword memory can be installed in existing MF20 memory cabinets, although you can't mix 16K chip and 64K chip memory in the same cabinet. However, you supposedly can have one 16K chip cabinet (768K total) and one 64K chip cabinet (3MW total). I don't know if the 4 memory control boards in each cabinet have to change for the new memory, and if they do if the first megaword per cabinet therefore costs more than add-ins (I assume if you need an add'l cabinet and power supply there is an extra cost item). Anyone else have more technical details? ------- 16-May-84 18:17:02-PDT,1081;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 18:16:49-PDT Date: Wed 16 May 84 19:19:58-MDT From: Randy Frank Subject: juicy dec 10/20 article To: tops-20@SU-SCORE.ARPA see this month's (May 15) issue of Datamation, page 77. At least I'm grateful I'm not some DP manager who stuck my neck out 2 or 3 years and argued for converting to DEC-20s. The article doesn't mention one point which I think that at times even DEC doesn't appreciate: even if DEC has all the best intentions in the world of providing continued support, in three or four years you'll be able to BUY OUTRIGHT a processor with the power of a KL for what we pay a year for maintenance alone on a KL (we're paying about $50K a year, and I suspect that's typical). Holding the line of maintenance prices for the KL is a joke. In order for us to be able to continue to operate a KL three or four years from now, it had better cost 75% LESS than current maintenance prices, and I'm not holding my breath. ------- 16-May-84 18:27:28-PDT,1298;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 18:27:18-PDT Date: Wed 16 May 84 18:28:48-PDT From: David Roode Subject: Re: 2065 and 64K memory announced To: FRANK@UTAH-20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Wed 16 May 84 18:08:47-PDT Location: EJ286 Phone: (415) 859-2774 I have a slight amount of additional technical information. The word I got was that the limit was 1.5 Megaword per MF20-LC backplane, making a limit of 3 Megawords in the DEC-20 without going to an expansion cabinet. Supposedly, a 2 for 1 density improvement was obtained using 64K chips instead of 16K chips. I would appreciate confirmation or denial of this fact from other sources. The Model MG20-E lists for $28,000 and is 1 Megaword of expansion modules whereas the Model MG20-LG lists for $50,000 with 2 Megawords. Both are supposed to install using existing model MF20-LC backplanes and controllers. Basic monthly maintenance is a vastly reduced $300 for the former and $600 for the latter. A trade in of $2000 per 256K MF20-E is being allowed. I am assuming that means $2000 for the 256K memory usually sold as part of the MF20-LC as well. ------- 16-May-84 18:28:32-PDT,4005;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 18:28:14-PDT Mail-From: NOT-LOGGED-IN created at 16-May-84 19:21:55 Return-Path: Received: from DEC-MARLBORO.ARPA by UTAH-20.ARPA with TCP; Wed 16 May 84 19:21:57-MDT Date: 16 May 1984 2121-EDT From: Reed B. Powell To: FRANK at UTAH-20 Large-Systems-Marketing: Integration Program Office Location: "231-4261 MRO2-2/3C (Pole 4A)" REPLY: "MARKET:: or MRVAX::" Subject: Re: 2065 and 64K memory announced Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12015909371.24.146.38157 at DEC-MARLBORO> Regarding: Message from Randy Frank of 16-May-84 2106-EDT ReSent-date: Wed 16 May 84 19:31:24-MDT ReSent-from: Randy Frank ReSent-to: tops-20@SU-SCORE.ARPA This is the scoop on mixing old and new memory. First some nomenclature: There are two MOS memory controllers inside the cabinet of a KL10-E or KL10-R (aka 1091, 2040, 2060). There are slots in each controller for up to three memory stacks. The "old" MF20 memory had 256KW per stack, which equates to 3/4 meg of memory per controller, or 1.5MW inside the processor. TO expand beyond this, you added an expansion cabinet, which in turn could hold two controllers, and which was configured exatly as I described above for the processor cabinet. Therefore, the maximum abount of MOS memory for a system as 3.0 MW. Note that the architectural limit for a PDP10 is 4.0 MW. Enter the new MG20 MOS memory, using 64K bit chips. The current controllers were designed and build with such densities in mind. There are EXACTLY ZERO changes to the controllers, including their backplanes, to handle the new memory. However, the new chips are a little more power hungry (more bits to feed), and so you can only put 2 (not three) stacks per controller. Note that this is no problem, since 4 stacks equals 4.0 MW equals the architectural limit of the PDP10 anyway. Now for mixing and matching. You can mix the old and the new, BUT ONLY AT THE CONTROLLER LEVEL. in other words, one controller can have MF20, and the other can have MG20. This would give a maximum configuration of 2.75MW (0.75 of MF plus 2.0 of MG). Note that you no longer go to the expansion cabinet. If you have 768KW or less right now, and have a machine that was manufactured within the last 2-3 years, all you need to do is add MG20 stacks (up to 2). Older machines may need to add an MF20-L option, which is the second memory controller (consult you field service person to see if this is necessary for you specific system). If you have more that 768KW, then something has got to give, since you have MF20 sitting where the MG20 wants to go. You can trade it in to DEC on the MG20, sell it outright, use if for spares, or hang it on you wall. In any event, you need to free up one of the memory controllers for the new memory. There is one exception to the rule that we no longer use the external expansion cabinets that I mentioed at the beginning of this epistle: KL10-D based systems, otherwise know as 1090s. Single processor 1090s, with no external memory IO devices (such as DX10, DL10, DF10, etc) can make use of this new memory. Since it is physically impossible for the memory to reside inside of the processor cabinet as it does on the 1091/2040/2060, we use those external cabinets for something new: Put the MG20 memory in them (remember, nothign changed except the stacks themselves), slapped that expansion cabinet against the side of a 1090, installed a new side panel (the cabs are different heights), and voila! You now have a 1090 with up to 4.0 MW of memory which is about twice as fast as the external core memory, does single bit fixups, and is a whole lot smaller (1/16 the size for 4.0 MW) that the external MH-10s. I hope this answers all possibilities, -reed -------- 16-May-84 18:35:04-PDT,464;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 18:34:54-PDT Date: Wed 16 May 84 18:37:29-PDT From: David Roode Subject: maintenance savings To: TOPS-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 To further elaborate, current basic maintenance charges for memory on a 3MW DEC-20 are $3093 per month. With the MG20 memory, that is cut to $900 per month. ------- 16-May-84 18:44:41-PDT,782;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 18:44:30-PDT Date: 16 May 1984 2144-EDT From: Reed B. Powell To: ROODE at SRI-NIC, FRANK at UTAH-20, tops-20 at SU-SCORE Large-Systems-Marketing: Integration Program Office Location: "231-4261 MRO2-2/3C (Pole 4A)" REPLY: "MARKET:: or MRVAX::" Subject: Re: 2065 and 64K memory announced Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12015913499.24.146.64612 at DEC-MARLBORO> Regarding: Message from David Roode of 16-May-84 2141-EDT You are off by one order of magnitude: it is 0.75MW per controller, 1.5MW per cabinet (either the processor cabinet, or the expansion cabinet). -reed -------- 16-May-84 19:41:21-PDT,2051;000000000000 Mail-From: MRC created at 16-May-84 19:41:12 Date: Wed 16 May 84 19:41:11-PDT From: Mark Crispin Subject: last DECUS? To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There seems to be a general feeling that this forthcoming DECUS, or possibly Anaheim, will be the last DECUS that many of us will go to. This is a shame, since DECUS was also a chance for all of us TOPS-20 people to get together for social and technical intercourse at a higher level than this list (also including people who can't get netmail). On the other hand, I certainly agree that it has become almost useless to go to DECUS. We will continue to be told by DEC how wonderful the world is and is going to be for us. We will continue to hear how wonderful insignificant price reductions are, and how grateful we should be for the promise that increases in support prices will be limited to 15%. We will continue to be insulted by DEC. I expect a clone of the Las Vegas DECUS "Wednesday morning flight" stunt. I'm referring, of course, to a certain unnamed Product Group Manager of Large Systems Marketing (whose initials are R.A.G.) who left DECUS early Wednesday morning. One was left with the feeling that DEC asked us to withhold our comments about DEC's integration "strategy" until Wednesday with the knowledge that said person wouldn't be around to hear them... What I would like to suggest is that we should have a "last great TOPS-20 people's get-together dinner/BS session" in Cincinnati. Since that is Chuck Hedrick's hometown, I hope he can recommend a suitable establishment to hold this session. It may also be a good idea for us to think of a substitute for DECUS, such as possibly a TOPS-20 equivalent to the Usenix conference. Even if that doesn't come to pass, I think we should start thinking of our group as separate from a subset of DECland. -- Mark -- ------- 16-May-84 22:31:34-PDT,2752;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Wed 16 May 84 22:31:03-PDT Date: Thu 17 May 84 00:35:20-CDT From: Clive Dawson Subject: 36-Bit Birthday Party To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Wed 16 May 84 22:20:38-CDT One of the things you'll be hearing about in Cincinatti is that plans are in the works to hold a 20-year birthday party for the 36-bit machines in Anaheim. Yes folks, it was some time in the last half of 1964 that DEC announced the PDP-6. (Can anybody with some old Datamations or something dig up the exact date for me?) A similar party was held last year by the RSX SIG for their 10 year anniversary, and it was apparently quite a success. Plans are underway to schedule special sessions at Anaheim dealing with some of the early history of the 36-bit line, war-story exchange, memorabilia display, button swaps, etc. We are hoping to get some help from the Digital Museum as well as DEC in these plans. It would certainly be great if many of the original DEC designers/engineers/programmers that worked on these systems could be convinced to travel to Fall Decus. One problem of course is money. We will probably arrange to have a surcharge on the DECUS registration for those who want to attend the 36-bit birthday party. Hopefully the cost of a catered dinner in Anaheim will be such that we can keep this charge in the $20-$25 range, but this may be wishful thinking. Anyway, plans are still quite tentative. I'd be most interested to hear from people who would be willing to work on this to make it a success. Full details about all the work there is to be done will be available in Cincinatti. It is important to stress one thing: this is meant to be a celebration, NOT a wake. The idea is that for at least one night, we can all get together, forget our troubles, and celebrate 20 years of life for some truly fine machines. We will try very hard to get certain key folks to join us, some of whom still even work for DEC. It would not be fair to expect them to accept our invitation only to have any sort of guilt trip or other harassment laid on them. Everybody is encouraged to spread the word about this and come up with good ideas that will make this a memorable occasion. Also, we are compiling a list of the people (not necessarily DEC people) who it would be important to invite (regretably at their own expense, unless we find a millionaire philanthropist who's a 36-bit hacker at heart!) Please mail me any suggestions. Cheers, Clive Dawson Large Systems SIG Steering Committee ------- 17-May-84 01:14:33-PDT,786;000000000000 Mail-From: MRC created at 17-May-84 01:14:21 Date: Thu 17 May 84 01:14:21-PDT From: Mark Crispin Subject: Re: 36-Bit Birthday Party To: CC.Clive@UTEXAS-20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Wed 16 May 84 22:31:20-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think a wake is an excellent idea. Don't forget, a wake is *not* a funeral. It is a party -- a celebration of the life of the deceased. I believe the 3rd party 36 bit vendors -- Foonly, Systems Concepts, and Tymshare, should be invited to attend the party as guests. It just may be that we will have a resurrection. ------- 17-May-84 07:26:11-PDT,2212;000000000001 Return-Path: <@CMU-CS-C.ARPA:WEINSTOCK%TARTAN@CMU-CS-C.ARPA> Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 17 May 84 07:25:54-PDT Received: from TARTAN by CMU-CS-C with TLnet; 17 May 84 10:24:55-EDT Received: ID ; Thu 17 May 84 10:27:46-EDT Date: Thu 17 May 84 10:27:40-EDT From: Charles B. Weinstock Subject: Olsen Speaks To: Tops-20@SU-SCORE.ARPA In February, Ken Olsen addressed the New York Society of Security Analysts. Here is a relevant excerpt: Question: Regarding your decision to continue to develop a new, larger 36-bit product line, how are you areacting and what are you doing to convey your plans to the customers? Mr. Olsen: The situation is harder than we expected. In that community, customers have developed an almost religious fervor. It's the only operating system they ever want to use. It's been the standard time-sharing system for years. Some big companies would buy one a month. All they wanted from a new computer was less floor space. Their technical people, both financial and engineering, just kept growing and growing. So they looked forward to a new machine that would take less floor space and cost fewer dollars per operation. We have an answer for them. We are not giving up on them. We are making a substantial investemnt in clustering, tying several of the present machines together, connecting the terminals with Ethernet and putting personal computers in at the users' end. We feel that we'll be able to give customers even more than they would have had with a new 36-bit machine. Many of these people are not great experimenters or changers. They have problems they want solved, and the computer is just a tool. The last thing they want to do is explore a different way of doing things. Many of them don't want a personal computer. They've been working with this thing for ten years and that's all they want. So we have an educational program to carry out. We think we can satisfy most of their needs with technology. The immediate reaction has been negative, but we haven't given up, and we're still investing very heavily. ------- 17-May-84 09:07:49-PDT,5373;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 17 May 84 09:07:18-PDT Date: 17 May 1984 1209-EDT From: Kevin Paetzold To: tops-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: [Kevin Paetzold : [MOSER at GIDNEY: [LSHAVEL at KL2102: [Janet Blau : [HOVEY at PIXEL: Things go better with coke.]]]]] Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12016070941.20.126.6125 at DEC-MARLBORO> - - - - - - - Begin message from: Kevin Paetzold Sender: PAETZOLD at GIDNEY Date: 17 May 1984 1202-EDT From: Kevin Paetzold To: paetzold at MARKET Reply-to: Paetzold at GIDNEY DTN: 231-7430 Mail-Stop: MRO1-2/L10 Subject: [MOSER at GIDNEY: [LSHAVEL at KL2102: [Janet Blau : [HOVEY at PIXEL: Things go better with coke.]]]] Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12016069767.32.393.27421 at GIDNEY> - - - - - - - Begin message from: MOSER at GIDNEY Sender: MOSER Date: 10 May 1984 1610-EDT From: MOSER at GIDNEY To: Braithwaite at GIDNEY, CDunn at GIDNEY, CJohnson at GIDNEY, DMcDaniel at GIDNEY, Evans at GIDNEY, Flemming at KL2102, GLindell at GIDNEY, Grant at GIDNEY, Grossman at GIDNEY, Gunn at GIDNEY, Hall at GIDNEY, Halpin at GIDNEY, Haudel at GIDNEY, Leache at GIDNEY, Lomartire at GIDNEY, Mayberry at GIDNEY, Mayo at GIDNEY, McCollum at GIDNEY, McIntee at GIDNEY, McLean at GIDNEY, Melohn at GIDNEY, Miller at GIDNEY, Moser at GIDNEY, Murphy at GIDNEY, Nichols at GIDNEY, Paetzold at GIDNEY, Palmieri at GIDNEY, Pratt at GIDNEY, Purretta at GIDNEY, Shtil at GIDNEY, TBoyle at GIDNEY, TGrady at GIDNEY, Weisbach at GIDNEY, Wing at GIDNEY Subject: [LSHAVEL at KL2102: [Janet Blau : [HOVEY at PIXEL: Things go better with coke.]]] Message-ID: <"MS11(2367)+GLXLIB1(1056)" 12014279802.153.585.38274 at GIDNEY> - - - - - - - Begin message from: LSHAVEL at KL2102 Sender: LSHAVEL at KL2102 Date: 10 May 1984 1535-EDT From: LSHAVEL at KL2102 To: moser at GIDNEY Subject: [Janet Blau : [HOVEY at PIXEL: Things go better with coke.]] Message-ID: <"MS11(2366)+GLXLIB1(1056)" 12014273562.162.383.31707 at KL2102> you'll LOVE this one!! - - - - - - - Begin message from: Janet Blau Date: 9 May 1984 1156-EDT From: Janet Blau To: sclemens at KL2137, adilsworth at KL2137, lshavel at KL2102 DTN: 231-5342. Mail-Stop: MRO1-2/L14. Subject: [HOVEY at PIXEL: Things go better with coke.] Message-ID: <"MS10(2123)+GLXLIB1(1136)" 12013971521.23.51.64741 at KL2137> - - - - - - - Begin message from: HOVEY at PIXEL Date: 9 May 1984 0836-EDT From: HOVEY at PIXEL To: JBLAU at KL2137 Subject: Things go better with coke. Mailed to: MONTY::KL2137::JBLAU From: PIXEL::WARD "Geoffrey Ward.. DTN: 264-6698" 7-MAY-1984 11:13 To: KING,HOVEY,WONG,COHEN Subj: Strange music From: PICA::BLANCHETTE "BoB" 7-MAY-1984 11:11 To: GOFF,AL Subj: From: COPPOLA "Victor A. Coppola" 7-MAY-1984 11:06 To: @SYS$SYSTEM:PICA From: TOPCAT::MANON 7-MAY-1984 11:04 To: PICA::COPPOLA,PICA::VILLANDRY Subj: boot it! From: HOGAN "Tom Hogan" 7-MAY-1984 09:46 To: MANON Subj: Songbreak... Subj: boot it Subj: Here's another Jackson special... Newsgroups: net.jokes Path: decwrl!decvax!harpo!ulysses!mhuxl!ihnp4!inuxc!pur-ee!uiucdcs!channic Subject: BOOT IT - (nf) Posted: Mon Apr 30 07:10:00 1984 Sing this one to Michael Jackson's "Beat it".... You're processing some words when your keyboard goes dead, Ten pages in the buffer, should have gone to bed, The system just crashed, but don't lose your head, Just BOOT IT, just BOOT IT. Better think fast, better do what you can, Read the manual or call your system man, Don't want to fall behind in the race with Japan, So BOOT IT, Get the system manager to BOOT IT, BOOT IT, Even though you'd rather shoot it. Don't be upset, it's only some glitch. All that you do is flip a little switch. BOOT IT, BOOT IT, Get right down and restitute it. Don't get excited, all is not lost. CP/M, UNIX or MS/DOS Just BOOT IT, boot it, boot it, boot it... You gotta have your printout for the meeting at two, The system says your jobs at the head of the queue, Right then the thing dies but you know what to do, BOOT IT. You always get so worried when the system runs slow, And when it finally crashes, man you feel so low, But computers make mistakes (they're only human you know) So BOOT IT, Call the local guru to BOOT IT, BOOT IT, Go ahead re-institute it. If you're not lucky, get the book off the shelf, But if you are, it'll do itself. BOOT IT, BOOT IT, Then go find the guy who screwed it! Operating systems are built to bounce back, Whether it's a Cray or a Radio Shack. BOOT IT, BOOT IT, Wed 9-May-1984 08:34 Merrimack N.H. -------- - - - - - - - End forwarded message -------- - - - - - - - End forwarded message -------- - - - - - - - End forwarded message ======== - - - - - - - End forwarded message -------- - - - - - - - End forwarded message -------- 17-May-84 09:52:22-PDT,1509;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 17 May 84 09:52:05-PDT Date: 17 May 1984 1254-EDT From: Kevin Paetzold To: MRC at SU-SCORE, TOPS-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: Re: last DECUS? Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12016079129.20.126.17129 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 16-May-84 2248-EDT Certainly the world is not what we want it to be but that does not mean that you should just give up. At Spring DECUS it will have been one year since DEC canceled Jupiter. Not one year and a month. One year. DEC people found out internally about what was happening the Wednesday afternoon before DECUS. There was no time for preparation. There was also not much usefull discussion. DEC is a pretty big company. Engineering throughout the corporation and even Large Systems Engineering itself is a pretty big organization. There is a large inertia problem. Things do not change over quickly. At the time of Spring DECUS we were still developing code for Jupiter. I think it would be to everyones advantage to keep an open mind at the next several DECUS symposiums. Don't close yourselves out just yet. In any case with "integration" i think the DECUS symposiums are going to be even more important. -------- 17-May-84 10:14:34-PDT,1882;000000000000 Return-Path: Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Thu 17 May 84 10:13:39-PDT Date: 17 May 1984 13:14-EDT Sender: DIPACE@BBNF.ARPA Subject: TENEX Remembered Subject: [DCHAPPLE@BBNF.ARPA: good night Sweet Prince] From: DIPACE@BBNF.ARPA To: Tops-20@SU-SCORE.ARPA Message-ID: <[BBNF.ARPA]17-May-84 13:14:25.DIPACE> One of our Operations people, while lamenting the lose of BBNB, came up with the following. Forgive the poetic license, but null sounds better then 1b0. Frank P.S. Our TENEX "wake" is scheduled for next week. Begin forwarded message Received: DCHAPPLE created at 16-May-84 11:53:40 Date: Wed 16 May 84 11:53:39-EDT From: DCHAPPLE@BBNF.ARPA To: dipace@BBNF.ARPA Subject: good night Sweet Prince 16-MAY-84 GOOD NIGHT SWEET PRINCE They crept along in silence, as quiet as a mouse their goal to kill a Tenex, the last one in the house Deposit null in 20 I heard one of them say. Stop this old horse in its tracks right here, right now, today. Demand-paged-virtual memory, the first one of its kind; it ceased without a whimper, it hardly seemed to mind. And so we close a chapter in the course of history and lay to rest the system that was known as BBNB. Pull out the plugs and cables. Turn off the Calcomp drives. But box it up please gently, t'was a big part of our lives. Dave Chapple - RCC/BBN -------------------- End forwarded message 17-May-84 13:29:32-PDT,1426;000000000001 Mail-From: MRC created at 17-May-84 13:29:19 Date: Thu 17 May 84 13:29:19-PDT From: Mark Crispin Subject: Re: Olsen Speaks To: Weinstock%TARTAN@CMU-CS-C.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles B. Weinstock " of Thu 17 May 84 07:26:14-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) My only comment is to quote from PDQ Bach's "Twelve Quite Heavenly Songs", specifically, the one to Taurus: Can you lend me twenty quid? My situation's bad; I met three monks who had nothing to eat And I gave them all I had. Bull, bull, bull! How well I know that sound: Sir, you take the grand prize For throwing the bull around. Here's a little fish I caught This morning by the dock; I had another three times as long But I lost it to a hawk. Bull, bull, bull! How well I know that sound: Sir, you take the grand prize For throwing the bull around. John my friend I must admit This piece is really schlock; I hereby resolve to never uncover Any more by PDQ Bach. Bull, bull, bull! How well I know that sound: Sir, you take the grand prize For throwing the bull around. I'll treat whomever comes up with the best verse for the 36 bit follies to a beer, payable at DECUS... -- Mark -- ------- 18-May-84 08:19:52-PDT,395;000000000000 Return-Path: Received: from USC-ECLB.ARPA by SU-SCORE.ARPA with TCP; Fri 18 May 84 08:19:45-PDT Date: Fri 18 May 84 08:22:42-PDT From: Gus Subject: Mailing list To: tops-20@SU-SCORE.ARPA cc: Gus%KYLARA@ECLA Please add me to your Mailing list . I work for U.S.C. and my user name is . Thank You in advance. Gus ------- 18-May-84 15:01:58-PDT,999;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 18 May 84 15:01:45-PDT Date: Fri 18 May 84 16:31:18-EDT From: Clifford Neuman Subject: Re: Olsen Speaks To: Weinstock%TARTAN@CMU-CS-C.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles B. Weinstock " of Fri 18 May 84 16:16:30-EDT Here is my favorite quote from the report. Question: Could you comment on the timing of Venus? Mr. Olson: I hope we're shipping them before the end of this calendar year. Things are going well, we're making them, productions lines are being set up, the inventory is there. There will undoubtedly be some initial problems putting something that complicated together in production. This was the first question posed to Ken Olson after he gave his presentation. I made the assumption that his other answers were not going to be much more accurate. ~ Cliff ------- 19-May-84 18:33:44-PDT,487;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 19 May 84 18:33:35-PDT Date: Sat 19 May 84 18:37:13-PDT From: Ed Pattermann Subject: Usage Records question To: tops20@SU-SCORE.ARPA I have noticed that when the system crashes, there is no 'incomplete session entry' usage record written out for job 0. Have others seen this? Is there a fix for it anywhere? SPR maybe? Thanks! -- Ed ------- 21-May-84 12:16:44-PDT,990;000000000000 Mail-From: MRC created at 21-May-84 12:16:27 Date: Mon 21 May 84 12:16:27-PDT From: Mark Crispin Subject: [VAF@CMU-CS-C.ARPA: TCPJFN changes] To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Vince is correct. If you've been following my TCP changes, you should make sure you have this fix in. --------------- Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 21 May 84 09:49:24-PDT Received: ID ; Mon 21 May 84 12:51:35-EDT Date: Mon 21 May 84 12:51:34-EDT From: VAF@CMU-CS-C.ARPA Subject: TCPJFN changes To: MRC@SU-SCORE.ARPA It would appear that there is a typo in one of your changes. At TCPOP5+1 you have a SKIPE T1,FILTCB(TCB). This should probably be a SKIPE T1,FILTCB(JFN) and is a good way to get ILMNRF's the way it is now. --Vince ------- ------- 22-May-84 18:48:17-PDT,1057;000000000000 Return-Path: Received: from MIT-MC by SU-SCORE.ARPA with TCP; Tue 22 May 84 18:47:58-PDT Date: 22 May 1984 21:50-EDT From: Mark Crispin Subject: memories of old time... To: TOPS-20 @ SU-SCORE The following made the rounds when the VAX was introduced...it is just as valid today as it was then... VAXOLOGY There is a computer named VAX, Which is totally loaded with hacks, But the real piece of crap Is the overflow trap, Which an old-PC register lacks. It's got byte-string instructions galore, But the packed decimal format is poor, And the halfword length means That it isn't worth beans, Just like the 360's of yore. Oh, the branch mnemonics are losing, And the right to left numbers confusing, But the thing that's a pain, An efficiency drain, Is the miniscule page size they're using. Well, they give you lots of good stuff, And the address space size is enough, But you can't do an "exch", And it makes you say "bletch", When you see all the RSX cruft. 23-May-84 12:43:27-PDT,1575;000000000000 Mail-From: MRC created at 23-May-84 12:43:05 Date: Wed 23 May 84 12:43:05-PDT From: Mark Crispin Subject: latest rumor To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The following comes from reliable sources within DEC: DEC has cranked up KL production to work around the clock in 3 shifts, 7 days. The plan is to make 2000 black -20s and then shut down the production line permanently. Apparently, DEC needs (and wants) to convert the floor space for Venus production. My comment: I believe that at the present time there are something like 2500 KL's in the world today. So, 2000 black KL's IS a significant addition to the existing CPU pool, even if this is the end. DEC probably will have to end up selling many of them at sacrifice prices (tr: what DEC should have sold KL's at for the past few years -- e.g. $100K or less), which would (in their eyes) justify their axing the product line. Since KO has committed DEC to shipping Venus by the end of the year, it's obvious they will have to hurry up on getting Venus out the door in large quantities. I wonder if DEC hasn't seriously over-extended itself with Venus, though. In many of the trade rags I've seen that many of DEC's competitors have looked at VAX and found it vulnerable. I get the strangest feeling that when Venus does appear many people who've been holding their breath for it will ask "is that all?" ------- 23-May-84 23:00:15-PDT,981;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 23 May 84 23:00:12-PDT Date: Wed 23 May 84 23:00:08-PDT From: Kirk Lougheed Subject: Save a tree To: su-tops-20@SU-SCORE.ARPA by running the new PUPGSV. I have added flags to silence the noisy PUPGSV output that has been littering at least Sierra's CTY log for the past few days. When SILENT is set to -1, no routing messages are displayed at all. If the server gets a fatal JSYS error, however, you will hear about it. If SILENT is 0 and NOHOPS is -1, only subnet up/down messages are displayed. No hop count changes are displayed. I believe I've also fixed the bug whereby PUPGSV would continously tell us about a timed out subnet. If both SILENT and NOHOPS are 0, then you'll get everything. The source is PS:PUPGSV.MAC on Sierra. The EXE version on SYSTEM: on Sierra has SILENT = 0 and NHOPS = -1. Kirk ------- 24-May-84 20:59:12-PDT,1415;000000000000 Mail-From: MRC created at 24-May-84 20:59:04 Date: Thu 24 May 84 20:59:04-PDT From: Mark Crispin Subject: mailsystem changes To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The latest version of MMailr on MRC:MMAILR.MAC at Score has a major operational change. In particular, the FTLOG assembly switch is no more. Replacing it is a runtime cell called LOGP which if set non-zero will instruct MMailr to make logs. It is assembled as zero, that is, do not make any logs. There is also a new facility for statistics. If the runtime cell STATP is set non-zero MMailr will make statistics files. At present, the format of the statistics file is destination_host,message_byte_count for each network interaction that was in some way "successful". However, this format is subject to enhancement, revision, or other change without notice once it is clearer what statistics are really needed. It is intended that statistics be less massive than logs. To run the latest MMailr with either facility enabled, replace "R MMAILR" or "MMAILR" in your SYSJOB.RUN (or PTYCON.ATO) with the following procedure: GET SYS:MMAILR DEPOSIT LOGP 1 ;if you want logs DEPOSIT STATP 1 ;if you want statistics START -- Mark -- ------- 25-May-84 02:22:27-PDT,2494;000000000000 Return-Path: <-iphonenet@csnet-relay.csnet> Received: from csnet-relay by SU-SCORE.ARPA with TCP; Fri 25 May 84 02:22:15-PDT Received: From nmt.csnet by csnet-relay; 25 May 84 5:15 EDT From greg@NMT Thu May 24 14:19:03 1984 Received: by nmtvax (4.12/4.7) id AA26191; Thu, 24 May 84 14:19:03 mdt Date: Thu, 24 May 84 14:19:03 mdt From: Greg Titus Message-Id: <8405242019.AA26191@nmtvax> To: tops-20@su-score.arpa Subject: interested in DEC-20 C compiler? New Mexico Tech is about (approximately September) to hatch a version 7 C compiler for DEC-20s running TOPS-20, and we have some interest in selling said compiler to other TOPS-20 sites. Our best guess as to cost is something like 500 dollars for educational sites (colleges and universities) and 2500 dollars for non-educational sites (big business). First, a short description of what we expect to offer: 1) Not just another hack of the version of the portable C compiler which is available on -20s, but a completely new implementation. 2) Output in .REL file format, instead of MACRO-20, which is what is produced by all of the other compilers I've seen for -20s. 3) A code generator which goes to some effort to emit code which makes full use of the -20 instruction set. 4) An eyacc parser, as exemplified by the 4.xbsd Pascal compiler (not interpreter), with good error reporting and recovery. 5) Support for calling TOPS-20 FORTRAN (thus access to all of the floating-point functions). 6) Decent compilation speed, on the order of 40,000 lines/minute of cpu time, assuming some average mix of preprocessor commands, comments, and real code. 7) Behavior which is highly compatible with that of the VAX/VMS C compiler. Thus, a question: How much interest is there in such a compiler? If you like the idea but not the price, tell me anyway. To some limit, we would rather distribute lots of compilers for less money per each than a few compilers for more each. Please reply to me personally instead of to the net. thanks, greg Greg Titus ..!ucbvax!unmvax!nmtvax!greg (uucp) NM Tech Computer Center ..!cmcl2!lanl-a!nmtvax!greg (uucp) Box W209 C/S greg.nmt@rand-relay (arpa) Socorro, NM 87801 greg@nmt (CSnet) (505) 835-5735 ====================================================================== 25-May-84 02:22:50-PDT,1738;000000000000 Return-Path: <-iphonenet@csnet-relay.csnet> Received: from csnet-relay by SU-SCORE.ARPA with TCP; Fri 25 May 84 02:22:24-PDT Received: From nmt.csnet by csnet-relay; 25 May 84 5:15 EDT From greg@NMT Thu May 24 14:19:42 1984 Received: by nmtvax (4.12/4.7) id AA26201; Thu, 24 May 84 14:19:42 mdt Date: Thu, 24 May 84 14:19:42 mdt From: Greg Titus Message-Id: <8405242019.AA26201@nmtvax> To: tops-20@su-score.arpa Subject: C compiler validation suite wanted Does anybody out there know of the existence of a validation suite for version 7 C compilers? New Mexico Tech is in the middle of producing a v7 C compiler for DEC-20s (TOPS-20), and it would be nice if we could be reasonably sure that the language it compiled really was C. We are willing to beg (if it doesn't cost too much pride), buy (if it doesn't cost too much money), or borrow such a beast. It doesn't have to be a *real* standard validation suite or anything like that; it just has to exercise the compiler (all phases) fairly strenuously. I would think that, at the very least, any vendor selling C with its machines would have something like this. I prefer replies to me personally; replies to the net are ok, except that I will only look for them in net.lang.c (not in net.lang or net.wanted). Thanks in advance. i remain, greg Greg Titus ..!ucbvax!unmvax!nmtvax!greg (uucp) NM Tech Computer Center ..!cmcl2!lanl-a!nmtvax!greg (uucp) Box W209 C/S greg.nmt@rand-relay (arpa) Socorro, NM 87801 greg@nmt (CSnet) (505) 835-5735 ====================================================================== 25-May-84 06:13:38-PDT,1483;000000000000 Return-Path: Received: from BBNG.ARPA by SU-SCORE.ARPA with TCP; Fri 25 May 84 06:13:30-PDT Date: Fri 25 May 84 09:15:41-EDT From: Dan Tappan Subject: 5.3 race condition To: Tops20@SU-SCORE.ARPA In MEXEC there is the following code, where the two lines marked with a * were added since 5.0. ------- MOVEI 1,100 * MOVEI 2,3B33 ;SET TO HDX HERE, SO SETTING TO FDX * STPAR ;BELOW WILL FORCE OUT TELNET CONTROL MOVE 2,NORMTF ;GET TTY TO STANDARD STATE SFMOD STPAR ;SET DEVICE PARAMETERS TOO MOVE B,CTRLTT ;GET CONTROLLING TERMINAL CALL CHKTVT ;SEE IF A TCP VIRTUAL TERMINAL JRST SYSINQ ;NEITHER. MUST BE NORMAL. SYSINO: SKIPA T2,[.TTIDL] ;SOMEKIND OF NET TERMINAL -- IDEAL -------- What this does is cause a race condition such that following echo negotiations can occur when connecting to a TVT: Remote: DO ECHO Tops20: WILL ECHO Tops20: WONT ECHO (First STPAR) Remote: DONT ECHO Tops20: WILL ECHO (Second STPAR) Remote: DO ECHO On a fast local net connection this race is almost always lost. Not only does this negotiation look silly, but it can cause type-ahead to not be echoed properly. It also causes problems with some 4.2 unix telnet user programs that do not respond to the WONT ECHO negotiation (causing the job to hang until the negotiation times out). I believe that this change was unnecessary, and certainly causes more problems then it solves. Dan ------- 25-May-84 11:22:09-PDT,1516;000000000000 Return-Path: Received: from USC-ECLC.ARPA by SU-SCORE.ARPA with TCP; Fri 25 May 84 11:21:56-PDT Date: Fri 25 May 84 11:24:24-PDT From: mark thompson Subject: the last KL: a modest suggestion To: tops-20@SU-SCORE.ARPA Phone: (213) 743-4800 36 bit processors have a long and respectable tradition, beginning the IBM 7xx series of scientific processors (arguably the best archi- tected machines they have built) and including machines from Univac and Digital with a similar flavor. The PDP-10's demise brings an interesting parallel to BWM's recent discontinuance of (bear with me here...) their large twin-cylinder motorcycles after a 60 year history (quite a while for any technology). These machines were fine performers for their class, and well loved by their owners, though on the pricey side. In contrast to DEC's situation, however, their replacements are obviously better machines, and current owners are lining up to buy them. What brings this subject up is the report that DEC is building the last run of KL processors ever. Before BMW shut down their production line, they created a 'final edition', with special graphics. Each one comes with a fancy plaque commemorating the 'last BMW R100 motorcycles'. Then they sent a glossy flyer to all current owners, telling them of the special edition and inviting them to hurry down and buy. Maybe DEC could help their -20 sales this way...whaddaya think? -mark ------- 25-May-84 11:41:35-PDT,1502;000000000000 Mail-From: MRC created at 25-May-84 11:41:27 Date: Fri 25 May 84 11:41:27-PDT From: Mark Crispin Subject: more 36-bit rumors To: tops-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The following comes from a reliable source who shall remain anonymous: DEC's 1981 Corporate Red Book contains some interesting material outlining the "integration" strategy. The late lamented Jupiter was to "cap-off" the 36-bit product line and keep the customer base until VAX/VMS V4 and Venus were ready. Over time, 36-bit products would become less attractive compared to the VAX in terms of price and function, because both would hold still for VAX/VMS to catch up. R.A.G. spoke to DEC's engineers in Marlboro on "the future of large systems." She handles hostile engineers as well as she handles hostile customers; questions ended when the going got rough. She revealed some interesting facts: half of the 36-bit customers have stuck with DEC, 5% left, and the rest are still undecided. IBM and Honeywell are working hard to get the latter. VAXen have very poor database market penetration, far worse than 36-bits; IBM owns the market and is in an excellent position to win most of the 10/20 database sites. It's hard to change the perception of VAX as an engineer's minicomputer into one of a manager's information system. -- Mark -- ------- 25-May-84 12:24:32-PDT,664;000000000000 Return-Path: <@SRI-CSL:GEOFF@SRI-CSL.ARPA> Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Fri 25 May 84 12:24:11-PDT Date: 25 May 1984 12:20-PDT Sender: GEOFF@SRI-CSL Subject: Re: the last KL: a modest suggestion From: the tty of Geoffrey S. Goodfellow To: THOMPSON@USC-ECLC Cc: tops-20@SU-SCORE Message-ID: <[SRI-CSL]25-May-84 12:20:41.GEOFF> In-Reply-To: The message of Fri 25 May 84 11:24:24-PDT from mark thompson Yeah, sure I think DEC should do the same thing as BMW; then their customers should display their gleeful support by not showing up to buy any of their 'special edition' KLs. g 25-May-84 21:17:18-PDT,693;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 25 May 84 21:17:09-PDT Received: ID ; Sat 26 May 84 00:19:46-EDT Date: Sat 26 May 84 00:19:45-EDT From: VAF@CMU-CS-C.ARPA Subject: Bug in ASNIQ% To: tops-20@SU-SCORE.ARPA At ASNIQF-10 lines there is a call to REL1IQ which is used to initialize an internet queue before reassigning it. It is supposed to take T1/ queue handle. The current code doesn't set up T1 and instead calls it with FLAGS,,JOBNO which results either in clearing a random queue or an ILMNRF, depending on what the flags are. Solution: Add a HRRZ T1,FQ before the CALL REI1IQ. --Vince ------- 25-May-84 21:37:59-PDT,698;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 25 May 84 21:37:47-PDT Received: ID ; Sat 26 May 84 00:40:22-EDT Date: Sat 26 May 84 00:40:21-EDT From: VAF@CMU-CS-C.ARPA Subject: ASNIQ% again To: TOPS-20@SU-SCORE.ARPA It is also probably a bad idea to allow users to specify unknown flags - the documentation claims this isn't possible, but the code doesn't agree. Make it agree: ---------- Right before .ASNIQ add: AQ%NUL==<777700,,0>- ; Unused flag bits At .ASNIQ+3 add: TXNE T1,AQ%NUL ; Any bogus bits on? RETERR(ARGX22) ; Yup. He loses ---------- --Vince ------- 29-May-84 11:54:33-PDT,880;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 29 May 84 11:54:22-PDT Date: 29 May 84 14:58:03 EDT From: Charles Hedrick Subject: Tops-20 update tape -- or -- How's SDC turnaround time these days? To: tops-20@SU-SCORE.ARPA I just got two copies of a tape, AV-R774B-TM. It has a bunch of files on it written in May and June 1983, a cover letter dated July 1938, a Software Bill of Material dated 8/23/83, and somebody's initials 5/22/84. This seems to be a turnaround time of about a year. On it there is a new version of DUMPER. I recognize it as the infamous DUMPER %402 that I saw so many messages about a month or so ago. Is there any concensus about this? If we fix the bugs noted in Tops-20, is it worth moving to, or is it such a disaster that we should just ignore it? ------- 29-May-84 12:05:26-PDT,695;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 29 May 84 12:04:50-PDT Received: ID ; Tue 29 May 84 15:05:19-EDT Date: Tue 29 May 84 15:05:18-EDT From: Vince Fuller Subject: Re: Tops-20 update tape -- or -- How's SDC turnaround time these days? To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Tue 29 May 84 14:58:03-EDT How about the delivery? Mine was sent Federal Express. Seems a little silly to waste the money on quick delivery when the tape sat in a warehouse for about 11 months to begin with... --Vince ------- 30-May-84 05:38:53-PDT,586;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Wed 30 May 84 05:38:46-PDT Date: Wed 30 May 84 08:38:53-EDT From: Donna Lynch Subject: AP#7 EXEC bug To: tops-20@SU-SCORE.ARPA cc: Admin@RADC-TOPS20.ARPA A DEC software specialist in the area informed me of a bug in Autopatch 7 EXEC. The COPY command doesn't work. He reported and received the following fix from the TSC: COPEOF 14/ MOVE B,..DTCH+355 ..DTCH+335/ 17,,100000 should be ..DTCH+355/ 17,,0 ------- 30-May-84 06:58:26-PDT,362;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 30 May 84 06:58:18-PDT Date: Wed 30 May 84 07:59:36-MDT From: Randy Frank Subject: putting tops-20 5.3 (tcp/ip) into autopatch #7 To: tops-20@SU-SCORE.ARPA Has anyone put 5.3 into autopatch #7 yet? Are there any problems/issues? ------- 30-May-84 07:45:32-PDT,604;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Wed 30 May 84 07:45:24-PDT Date: Wed 30 May 84 10:45:31-EDT From: Donna Lynch Subject: more on AP7 EXEC bug To: tops-20@SU-SCORE.ARPA cc: Admin@RADC-TOPS20.ARPA I have been informed by an anonymous source that the previously reported bug is not a bug. The COPY command will not fail if you are running the AP7 monitor. However, the EXEC patch does seem to work and is necessary if you are still running the AP6 monitor without the associated monitor patch. ------- 30-May-84 10:33:50-PDT,1222;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 30 May 84 10:33:28-PDT Date: 30 May 1984 1332-EDT From: Kevin Paetzold To: FRANK at UTAH-20, tops-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO Mail-stop: MRO1-2/L10 Telephone: "617-467-7430 (DTN: 231-7430)" Subject: Re: putting tops-20 5.3 (tcp/ip) into autopatch #7 Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12019493920.19.126.8502 at DEC-MARLBORO> Regarding: Message from Randy Frank of 30-May-84 1023-EDT i am preparing a 5.3 autopatch tape 7 monitor. should be done sometime next week. Also the 5.3 ap#7 monitor will probably be the last 5.3 monitor. sometime this summer i am going to start sending out the 5.4 monitor to everyone. 5.4 has ethernet support and will have some BBN changes (including RFNM support). I am also looking at doing some EGP support for the 5.4/6.1 timeframe. 5.3 basicly looks like the release 6.0 tcp support. 5.4 looks like the release 6.1 tcp support. all these random monitor versions should all merge together in release 6.1 (which is not all that far away). -------- 30-May-84 11:18:32-PDT,934;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 30 May 84 11:17:27-PDT Date: 30 May 1984 1417-EDT From: Bob Longo To: ADMIN at RADC-TOPS20 cc: TOPS20 at SU-SCORE Mail-Stop: LAO Phone: 213-417-4240 Subject: Re: more on AP7 EXEC bug Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12019502272.27.355.14196 at DEC-MARLBORO> Regarding: Message from Donna Lynch of 30-May-84 1049-EDT There is a new bit in the FDB to signify when a file is a FORTRAN data file (FB%FOR). The patch you have removes this bit from the list of FDB bits to be propagated from one file to another by the EXEC's COPY command. The reason the COPY command in the AP7 EXEC will not work on a pre-AP7 monitor is that FB%FOR did not exist prior to AP7, and thus is not defined as a CHFDB% changable bit. -Bob -------- 30-May-84 20:24:30-PDT,3214;000000000000 Mail-From: MRC created at 30-May-84 20:23:53 Date: Wed 30 May 84 20:23:53-PDT From: Mark Crispin Subject: more DEC quotes... To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The following quotes come from a draft copy of the "Central Engineering Corporate Product Strategy Red Book," dated January 1981. "Goal to be achieved by 1990 or sooner: Althought the above ["moving towards a range of systems around a single VAX/VMS family architecture"] is the systems product goal for 1990, DEC will invest to permit a transition from large 16b and 36b configurations to the 32b architecture by the mid-eighties." (Vol. 1, p. 10, "systems goals overview") "36 Bit Coexistence: The investment in TOPS-10/TOPS-20 systems will be maintained at a basic support level including the development of a high performance system (Jupiter) which will be used to cap off the 36 bit systems archetecture. Coexistence tools will facilitate the transition of 36-bit customers to the 32-bit architecture." (v. 1, p. 11) Page 12 contains four graphs of price/functionality ratios over time. Only Unibus and 36-bits show no improvement. "Position VMS as pre-eminent general purpose system by Version 4.... Induce existing RSTS and TOPS-10/20 customers to implement new applications on VMS: Superior VMS features; Implement only those 'migration/coexistence' features required to ensure customers find DEC-to-DEC transition easier than DEC-to-competition; No additional timesharing features for TOPS and RSTS (except for small systems)". (v. 1, p.16) "The 32-bit systems cost and functionality must be sufficient to create market pull away from 16 and 36-bit systems..." (V. 1, p. 43) "36-Bit Systems Strategy: Market Strategy: Base Plan: Maintain a mainframe presence until VAX software matures and Venus is introduced... Grow installed base revenues through Jupiter.... 36-32 Coexistence Plan: Increase the VAX business in the 10/20 market (installed base). Product Strategy: Jupiter. Minimum O.S. investment. Layered product enhancements." (v. 1, p. 48) "The strategy supporting the goal of market leadership with 32-bit systems has 3 steps: By 1985, provide software tools to support the harmonious coexistence of applications on the 32-bit and 36-bit archetectures. The intent is to increase the penetration of 32-bit systems into the 10/20 installed base. By 1988, provide hardware and software products to make it feasible for 10/20 customers to transport their major applications onto 32-bit systems. By 1988, deliver a 32-bit system that is both a functional and performance follow-on to the then current 32 and 36 bit systems. "The third step fulfills the intent of Gordon Bell's strategy [G. Bell Product Strategy, Aug. 1979] relative to providing 10/20 products beyond 1988. All large systems customers (regardless of the archetecture of their installed machines) will be able to grow with the new system." (V. 2, part 9 "Large Systems Strategic Planning Unit", p. 1) ------- 30-May-84 22:31:40-PDT,955;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 30 May 84 22:31:01-PDT Date: Thu 31 May 84 01:34:43-EDT From: John T. Wroclawski Subject: Re: more DEC quotes... To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Wed 30 May 84 23:37:05-EDT From DEC's point of view I think that product strategy made a lot of sense in 1981. An interesting question is how DEC has modified that strategy for 1984, in the presence of non-vax machines of clearly superior price/performance capabilities, both outside and apparently within DEC, and the rapid acceptance of UN*X in previously unimagined market areas. My own view is that parts of DEC have vastly underestimated these forces, as a result of which DEC may continue to be an evolutionary company rather than an innovative leader. They may not mind this, of course. ------- 31-May-84 14:55:28-PDT,1758;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 31 May 84 14:55:08-PDT Date: Thu 31 May 84 15:56:14-MDT From: Randy Frank Subject: more from the rumor mill To: tops-20@SU-SCORE.ARPA The following is being circulated to the DECUS leadership - got it from a friend: -------------------------------- Subject: Rumors about a revived follow-on 36 bit processor The following comes from Digital LCG employees; they want this information to be spread to LCG customers before DECUS so that something can be done about it. 1) Engineers at DEC looked at the possibility of implementing the KL data paths using the MCA technology from the VAX-790 (Venus) project. They decided the resulting processor would be 1.8 to 3.0 times the speed of the KL, be small enough to fit into a single processor bay, and cost less to manufacture due to the reduced component count. They also predicted that it could be put into production in 12 to 18 months. 2) Product Planning agreed to the project; Engineering agreed to the project. Ken Olsen agreed to the project. Everything was "GO". 3) The project then was passed on to new vice President Rose Ann Giardano to do a marketing study. Within 20 minutes she decided there was no market and cancelled the project. Note that existing LCG customers were not consulted. The cancellation was abrupt and rqther arbitrary. If anyone was more details on this problem, please make sure that the true story is given out at Cincinnatti. -------------------------------- I no nothing more than the above; I'm merely copying from a memo sent to various DECUS leadership. Anyone want to comment on its veracity? ------- 31-May-84 15:21:40-PDT,1696;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 31 May 84 15:21:20-PDT Received: ID ; Thu 31 May 84 18:14:57-EDT Date: Thu 31 May 84 18:14:54-EDT From: VAF@CMU-CS-C.ARPA Subject: TCOPR problem To: TOPS-20@SU-SCORE.ARPA Problem: The .TCSPC TCOPR% function is useless for a number of reasons. Diagnosis: First of all, the DTCSPC routine inside the TCOPR% jsys doesn't set up any of the fork ID's in the TCBPIF words in the TCB. Because of this, the code in TCPTCP which gives PSI's never does so. For unopened JFN's, the situation is even worse: DTCSPC sets the channels in the prototype TCB but the OPEN done inside the OPENF% jsys doesn't copy the values - the loop for copying from proto to real TCB doesn't copy any word which is already set in the real TCB and the initial value for TCBPIC is -1. Cure: There seems to be no easy and clean way to solve this although ways to hack it come readily to mind. First, it is necessary to add some code after the loop at TCPOP2 in TCPBBN to specially copy TCBPIC and the TCBPIF words which have undefined and initial values of -1 rather than 0 in the real TCB but have initial values of 0 in the prototype TCB. It is also necessary to add code to DTCSPC to setup the TCBPIF words in the prototype TCB based on the channels specified in the TCOPR% call. I will probably try this at some point when I have debugging time available and will summarize the exact changes to the list if anyone is interested. I suspect that changing things exactly as described in this message is likely to cause system problems. --Vince ------- 31-May-84 22:28:09-PDT,1204;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 31 May 84 22:27:57-PDT Date: 1 Jun 84 01:29:12 EDT From: Charles Hedrick Subject: last gasp dinner To: mrc@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA I will be happy to arrange a place to meet. If there are going to be a lot of people (as I suspect there will), it might be helpful to warn the establishment that we are coming. Mark: what sort of numbers and class of establishment did you have in mind? I assume you don't want white tie, but did you have in mind getting drunk together or having something more civilized? As it happens, Cincinnati has more than its fair share of good eating establishments, of all kinds. By the way, I will probably not be reading computer mail after Friday evening. As of Saturday noon I will be at home. If somebody wants my help in arranging something, you can call me there, at 513-791-2670. Ask for Chuck Hedrick. Charles Hedrick will probably get you the wrong person. Also: Does anybody know what is going on with the TCP session? I agreed to speak, but the chairman never got back to use about topics. ------- 1-Jun-84 12:07:01-PDT,1590;000000000000 Mail-From: MRC created at 1-Jun-84 12:06:51 Date: Fri 1 Jun 84 12:06:51-PDT From: Mark Crispin Subject: Re: last gasp dinner To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Fri 1 Jun 84 01:29:12-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Chuck - Certainly it shouldn't be anything white-tie or otherwise burdened with a dress code. The only places like that around here are discos (ugh!). I have no objections to getting drunk together, but we ought to do something more civilized first. A dinner at a reasonably good Continental restaurant (e.g. some money gets spent) first is more like it. We have two deaths at this wake: the death of 10/20's and the death of the special relationship between us and DEC. As there are more cost-effective Unix engines from other vendors (and we expect there will be more cost-effective TOPS-20 engines from Foonly and Systems Concepts) there really isn't that much of a reason to pay special attention to DEC any more. I suspect that conferences such as Usenix will be much more important than DECUS. I almost regret wasting time and travel money going to this DECUS. I really don't want to hear R.A.G. do her Joseph Goebbels act. I don't want to hear how wonderful (sic) VMS is. The only menu item I have to bring up is "when are RA81's going to work?" (they are a DISASTER on our VAXen). -- Mark -- ------- 1-Jun-84 15:17:19-PDT,4305;000000000000 Mail-From: MRC created at 1-Jun-84 15:17:06 Date: Fri 1 Jun 84 15:17:06-PDT From: Mark Crispin Subject: Stanford University News Service press release To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) STANFORD UNIVERSITY NEWS SERVICE STANFORD, CALIFORNIA 94305 (415) 497-2558 FOR INFORMATION CONTACT: Joel Shurkin FOR IMMEDIATE RELEASE STANFORD COMMISSIONS COMPUTER TO REPLACE LARGE DEC-20'S. STANFORD-- Stanford University is negotiating with a small Silicon Valley company to build large computers to replace the ubiquitous DECSYSTEM-20s now ``orphaned'' by their manufacturer, Digital Equipment Corp. (DEC). The proposed contract, which would total around $1.4 million, would commision two machines from Foonly Inc. of Mountain View for delivery early in 1986. Foonly is owned by former Stanford student David Poole. According to Len Bosack, director of the Computer Science Department's Computer Facilities, the Foonly F1B computer system is about four times faster than the DEC model 2060 and 10 times faster when doing floating-point computations (where the decimal point need not be in the same place in each of the numbers calculated) that are characteristic of large-scale engineering and scientific problems. Ralph Gorin, director of Stanford's Low Overhead Time Sharing (LOTS) Facility -- the academic computer center -- said the Foonly F1B system, which is totally compatible with the DEC-20, is an outgrowth of design work done by Poole and others while at the Stanford Artificial Intelligence Laboratory. Since 1977, Foonly has built one large system, the F1, and several dozen smaller systems. The Foonly F1B is a descendant of the original F1, with changes reflecting advances in integrated circuit technology and the architectural refinements (internal design) of the latest DEC-20s. A spokesman for DEC said the company announced last year it had discontinued work on a successor to the DEC-20, code named ``Jupiter,'' and would continue to sell enhanced versions of the large mainframe. Service on the machines was promised for the next ten years. However, said Sandra Lerner, director of the Computing Facilities at the Graduate School of Business, the discontinuation of DEC-20 development left approximately 1,000 customers world-wide without a practicable ``growth path.'' Ten DECSYSTEM-20 computers on campus make that machine the most numerous large system at Stanford. The Graduate School of Business uses its two DEC-20s for administration, coursework, and research. The Computer Science Department uses two systems for research and administration. LOTS, the academic computer facility, supports instruction and unsponsored research on three systems and hopes to add one more in the time before the F1B is available. Other DEC-20s are at the Department of Electrical Engineering, the artifical intelligence project at the Medical Center (SUMEX), and the recently formed Center for the Study of Language and Information (CSLI). The Stanford University Network (SUNet), the main university computer communications network, links together the 10 DEC-20s, approximately 30 mid-size computers, about 100 high-performance workstations, and nearly 400 terminals and personal computers. The DEC-20 has been a cornerstone of research in artificial intelligence (AI). Most of the large AI systems evolved on the DEC-20 and its predecessors. For this reason, Stanford and other computer science centers depend on these systems for their on-going research. Lerner said the alternative to the new systems would entail prohibitive expense to change all programs accumulated over nearly twenty years at Stanford and to retrain several thousand student, faculty, and staff users of these systems. The acquisition of the Foonly systems would be a deliberate effort to preserve these university investments. 6-1-84 -30- JNS3A EDITORS: Lerner may be reached at (415) 497-9717, Gorin at 497-3236, and Bosack at 497-0445. ------- 4-Jun-84 18:56:52-PDT,1257;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Jun 84 18:56:39-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632701193268900@MIT-MULTICS.ARPA>; 04 Jun 1984 21:53:13 edt Date: 04 Jun 84 12:26 +0200 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: more from the rumor mill Message-ID: <57673@QZCOM> In-Reply-To: <57502@QZCOM> 3) one comes to wonder if vice Presidents of Digital could be hired by a competitor of Digital? I cannot stop wondering why Digital has stopped agressive marketing of TOPS-10/20 (especially 20) - there is a great difference between hardware and software, and yet someone has to show me a system that can be a better base for building easy-to-use applications than TOPS-20. One problem might be this of 36-bit architecture which could make new customers suspicious. But I doubt that it would be any problem to re-implement TOPS in 32-bit land. 6-Jun-84 13:57:18-PDT,403;000000000000 Mail-From: G.ELDRE created at 6-Jun-84 13:57:04 Date: Wed 6 Jun 84 13:57:04-PDT From: Tim Eldredge Subject: LARGE monitors To: tops-20@SU-SCORE.ARPA Has anyone on the list had experience building a monitor with more than 100 (120 to be precise) jobs? I tried it, and it looks like I'll have trouble getting everything to fit. Does anyone have a suggestion? ------- 6-Jun-84 17:48:15-PDT,1037;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Jun 84 17:48:04-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632869606669098@MIT-MULTICS.ARPA>; 06 Jun 1984 20:40:06 edt Date: 06 Jun 84 09:45 +0200 From: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: more from the rumor mill Message-ID: <57984@QZCOM> In-Reply-To: <57673@QZCOM> The best thing that could happen would be if some group of persons decided to write a machine-independent version of the TOPS-20 operating system. Thus the need to rely on a specific machine vendor could be avoided. Since there are a lot of people out there who know about the internals of TOPS-20, such a rewrite could be done well. 11-Jun-84 09:01:00-PDT,839;000000000000 Mail-From: MRC created at 11-Jun-84 09:00:55 Date: Mon 11 Jun 84 09:00:55-PDT From: Mark Crispin Subject: Stanford TOPS-20 uptime To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As of this writing, Score has enjoyed close to 300 hours of uptime. This isn't a Score record, but it remains the largest uptime Score has had since release 4 before Pup or TCP. Does anybody know what the current record uptime is for a TOPS-20 system at Stanford? I am intentionally excluding Tiny; I would like the record for a 2060. If possible, I'd like to see separate numbers that distinguish between Pup/non-Pup, TCP/non-TCP, etc. I am asking because I'd like to go for the record. ------- 11-Jun-84 16:33:37-PDT,701;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Jun 84 16:33:34-PDT Date: Mon 11 Jun 84 15:56:00-PDT From: Ed Pattermann Subject: Re: Stanford TOPS-20 uptime To: MRC@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 11 Jun 84 09:05:57-PDT Mark, I don't know what the Stanford record is, but the SUMEX 2060 was up for quite a while last October. It was exactly October 13th, 8:20pm to November 7th, 10:45pm. I make this 602 hours, and 25 minutes. This was with PUP and TCP. I'm all for competition for uptime records! -- Ed ------- 11-Jun-84 17:00:01-PDT,547;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Jun 84 16:59:55-PDT Date: Mon 11 Jun 84 17:02:19-PDT From: Ed Pattermann Subject: Re: Stanford TOPS-20 uptime To: MRC@SU-SCORE.ARPA, su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Ed Pattermann " of Mon 11 Jun 84 16:38:01-PDT Correction to previous message. Downtimes were only accurate to checkpoint intervals. Actual uptime was 603 hours, 34 minutes. -- Ed ------- 13-Jun-84 11:41:47-PDT,432;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Jun 84 11:41:36-PDT Date: 13 Jun 84 14:41:48 EDT From: Charles Hedrick Subject: SPEAR To: tops-20@SU-SCORE.ARPA Does anyone have a copy of the field service part of SPEAR? We just put up a new SPEAR from an update tape. Our field service people can't find the new version of ANALYZE, etc. ------- 13-Jun-84 22:44:43-PDT,340;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Wed 13 Jun 84 22:44:36-PDT Date: 13 Jun 84 22:42:37 PDT (Wed) To: tops-20@Su-Score Subject: DECUS reports From: Mike Iglesias Can someone give us people who couldn't go to DECUS a report on what happened? How was the wake? 15-Jun-84 11:38:06-PDT,918;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 15 Jun 84 11:37:43-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2633625282214682@MIT-MULTICS.ARPA>; 15 Jun 1984 14:34:42 edt Date: 15 Jun 84 16:52 +0200 From: Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: more from the rumor mill Message-ID: <59163@QZCOM> In-Reply-To: <57984@QZCOM> Why not a "TOPS20 Shell" for unix? It would give unix a usable interface, would be easy to write and would be immediately portable. Simulating the TOPS20 JSYS is another problem. 15-Jun-84 11:39:11-PDT,1905;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 15 Jun 84 11:38:01-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2633625317216416@MIT-MULTICS.ARPA>; 15 Jun 1984 14:35:17 edt Date: 15 Jun 84 18:28 +0200 From: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: more from the rumor mill Message-ID: <59187@QZCOM> In-Reply-To: <59163@QZCOM> Something along those lines has been tried, and we ( among others ) use it regularly at TeleLOGIC. It has filename/command completion plus an emacs-like command-line editor. While we're at it, I think it's a good idea to try and include the good points about the standard shells, that are actually there. Regular expressions should be integrated with completion, for instance. However, the shell should have internal commands, a tree of forked process containers ( for internal image activation ) and normally the user should not use the standard way to start a UNIX command. Also, if real procedures were added, the bourne-shell is as good a programmable shell as I can imagine. The shell in question is called tcsh, and is a mod to the berkeley csh. It has better completion/recognition characteristics then the TOPS20 standard, except that the notion of command structure is limited to the simplistic form: command-in-path file1 file2 file3 That is, no lead texts can be meaningfully produced, and arguments that aren't files can't be expanded for you. The expansion routines are there, for free, however, som it's a simple matter to use it inside special programs. 15-Jun-84 11:40:12-PDT,847;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 15 Jun 84 11:39:01-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2633625360824631@MIT-MULTICS.ARPA>; 15 Jun 1984 14:36:00 edt Date: 15 Jun 84 18:30 +0200 From: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: more from the rumor mill Message-ID: <59188@QZCOM> In-Reply-To: <59187@QZCOM> Sorry, I should have added: Tcsh is based on a program ncsh by Ken Greer at HP, and modded by a Paul Placeway at a university somewhere. 15-Jun-84 11:41:07-PDT,1151;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 15 Jun 84 11:39:23-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2633625396449241@MIT-MULTICS.ARPA>; 15 Jun 1984 14:36:36 edt Date: 15 Jun 84 18:33 +0200 From: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: more from the rumor mill Message-ID: <59190@QZCOM> In-Reply-To: <59163@QZCOM> As Unix is written today, every and all programs expect to be called from the standard shell, and thus the "command language" of Unix is actually parsed by the programs, as in Tops-10. That makes a new "TOPS20 Shell" to also require all the UNIX programs to be rewritten. Of course, the most interesting parts of the TOPS-20 monitor could be extracted (COMND/TEXTI/RDTTY/TBLUK/TBADD/TBDEL/GTJFN/RCDIR/RCUSR) into a library of useful routines. 15-Jun-84 14:36:55-PDT,756;000000000000 Mail-From: MRC created at 15-Jun-84 14:36:43 Date: Fri 15 Jun 84 14:36:43-PDT From: Mark Crispin Subject: Re: more from the rumor mill To: Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message of Fri 15 Jun 84 16:52:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A TOPS-20 Shell for Unix was done at Stanford. Unfortunately, the sources vanished when the developer left. Another problem with it is that it is *very* slow, almost unusably slow even on a bare machine. ------- 18-Jun-84 20:45:32-PDT,1443;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Jun 84 20:45:20-PDT Date: 18 Jun 84 23:45:54 EDT From: Charles Hedrick Subject: interesting hardware (?) problem To: tops-20@SU-SCORE.ARPA Symptom: one of our 3 2060's gets a memory parity error (AR/ARX) every morning at 0:0:30. Sometimes it crashes, sometimes not. Also a few other memory-related crashes at other times. Diagnosis: what do we do at midnight? We run SPEAR, to print out all of the errors in the last day for field service. The frequency and timing of the errors other than midnight is consistent with when field service normally runs SPEAR interactively. Test 1: run spear interactively, with the same command as the batch file (ANALYZE): Result: memory parity error. Totally repeatable. We got a new copy of SPEAR and its pieces, and also recopied ERROR.SYS, in case something was odd about the files. It didn't help. Note that the same version of SPEAR runs fine on all other systems. Test 2: try turning off cache: the problem goes away Test 3: try the newest version of SPEAR (edit 613): the problem goes away. Conclusion: We have found a really nifty cache diagnostic. We have moved it to a safe place, where we can use it to test and future claims by field service to have fixed the memory, and put up the new version on SYS:. ------- 19-Jun-84 14:23:14-PDT,645;000000000000 Mail-From: MRC created at 19-Jun-84 14:22:57 Date: Tue 19 Jun 84 14:22:57-PDT From: Mark Crispin Subject: previous login To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am wondering whether it is really a good idea that the previous login word is set for batch or FTP logins. I am seriously considering making such logins not set the previous login word. Has any other site done this? What do you think? Perhaps there should be a separate timesharing and non-timesharing last login word? ------- 20-Jun-84 10:46:37-PDT,1194;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Jun 84 10:46:17-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2634054184537390@MIT-MULTICS.ARPA>; 20 Jun 1984 13:43:04 edt Date: 19 Jun 84 20:24 +0200 From: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA, Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Mark Crispin" cc: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: Re: more from the rumor mill Message-ID: <59812@QZCOM> In-Reply-To: <59392@QZCOM> Is this distinct from the ncsh / tcsh ? I have a vague notion that Ken Greer went to Stanford, and if it's the same programs, your statement isn't entirely correct. 20-Jun-84 11:23:11-PDT,970;000000000000 Mail-From: MRC created at 20-Jun-84 11:22:44 Date: Wed 20 Jun 84 11:22:44-PDT From: Mark Crispin Subject: Re: more from the rumor mill To: Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA, Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Michael_Walsh__Univ._College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Hans_Albertsson_SUF%QZCOM.MAILNET@MIT-MULTICS.ARPA" of Tue 19 Jun 84 20:24:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The program was called twunix. I have never heard of Ken Greer, and in any case two other persons claimed authorship of twunix. ------- 20-Jun-84 14:58:01-PDT,1400;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Jun 84 14:57:46-PDT Date: 20 Jun 84 17:58:24 EDT From: Charles Hedrick Subject: proposal for modifications to DUMPER To: remarks@RUTGERS.ARPA, operator@RUTGERS.ARPA cc: t: ; Our tests suggest that handling of unlabelled tapes is much more reliable than labelled tapes. However our operators do not want to give up the convenience of labelled tapes. I propose to add the following commands to DUMPER. If anyone sees a better way, please tell me: TAPE mta0:,mta1: DUMPER will cycle through the specified drives, which should all have been set unavailable. VOLID mon DUMPER will generate volids MON1, MON2, ... for the tapes. The VOLID will be stored somewhere in the DUMPER label. If there is no place available, the save set name will be used. Whenever DUMPER knows what the volid of a tape should be (either because of a VOLID command or because this is a retrieve command, in which case QUASAR has told it), it will go to the next tape drive in the list, and issue a read request on the drive. If the tape is either blank or has the correct volid, it will continue with the processing without further confirmation from the operator. If the volid is different, it will print the volid it found and ask for confirmation. ------- 21-Jun-84 10:03:15-PDT,903;000000000000 Return-Path: <@USC-ISIB.ARPA:chase@isib> Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Jun 84 10:03:02-PDT Received: FROM ISI-ALFALFA.ARPA BY USC-ISIB.ARPA WITH TCP ; 21 Jun 84 09:56:07 PDT From: Dale Chase To: Tops-20@SU-SCORE.ARPA Cc: Chase Date: 21 June 1984 09:55-PDT Subject: TVTNTV Problem: A user program doing a STAT% jsys on a bogus tvt line can, under the right circumstances, provoke a TVTNTV Bughlt. Diagnosis: CHKTVT uses the tvt line number as a offset into the TTSTAT table, but doesn't check the range for legality. If it picks up a garbage location which happens to have the right value in the field that indicates terminal line type, we lose. Cure: Add a range check to CHKTVT. Replace the line: CHKTVT+1/ LOAD W1,TTSTY,(T2) with the following: CHKTVT+1/ CAIL T2,NLINES RETBAD LOAD W1,TTSTY,(T2) 25-Jun-84 12:11:40-PDT,631;000000000000 Mail-From: MRC created at 25-Jun-84 12:11:22 Date: Mon 25 Jun 84 12:11:22-PDT From: Mark Crispin Subject: Logo update To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I believe I have fixed the "last bug" in restoring the terminal modes from the EDIT command in TOPS-20 portable Logo. This should fix the "hung" mode Logo can get into when typing any character gets you a Log bug report. The changed files are LOGO.EXE and PROCEDIT.C, PROCEDIT.REL, LOGO.REL. ------- 28-Jun-84 13:49:12-PDT,1000;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Jun 84 13:48:14-PDT Date: Thu, 28 Jun 84 20:48 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: minor bug still in execmi To: tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 I am going thru the autopatch exec sources, merging DECs changes with ours. I found one bug still there that I am sure has been reported before. It keeps control-X from working to single step thru a .MIC file. The fix is very simple. There are two places where .TICCX is used in a literal with 35 in the right half. In the second of those literals, it is just octal 35 when it should be ^D35. I just thought it might be worthwhile to pass that along to any of you who have not seen it yet. - Sam - ------- 1-Jul-84 12:55:35-PDT,1131;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sun 1 Jul 84 12:55:26-PDT Date: Sun 1 Jul 84 12:56:43-PDT From: David Roode Subject: DEC-20 cost of ownership To: tops-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 I suppose the news is out to everyone by now about DEC dropping maintenance charges to the MG20 level as soon as you order MG20 memory rather than waiting for installation. Has anyone got any word about specific maintenance costs for the MG20 memory? Apparently there is no increase in charges per MW for MG20 memory when adding the second controller. Since the controller and 256K of MF20 memory is included in the basic system charge, it appears to be the case that one could retain 256K of MF20 memory on the first controller at no increase of monthly maintenance charges (and then put 2MW of MG20 on the second controller). Furthermore, it appears unclear as to whether there is a charge for the controller when purchasing 2MW of MG20 memory. The numbering scheme would indicate that one is included. ------- 2-Jul-84 09:50:52-PDT,597;000000000001 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jul 84 09:50:40-PDT Received: ID ; Mon 2 Jul 84 12:50:42-EDT Date: Mon 2 Jul 84 12:50:37-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Program to do structure-to-structure copy? To: TOPS-20@SU-SCORE.ARPA I think this issue has been raised before, but I don't remember when... Does anyone have a program (perhaps a modified version of DUMPER) to copy files from one structure to another? Such a program should preserve all FDB info just like DUMPER. --Vince ------- 2-Jul-84 11:22:40-PDT,961;000000000000 Return-Path: Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jul 84 11:22:18-PDT Date: Mon 2 Jul 84 11:22:45-PDT From: YOSHII@EDWARDS-2060.ARPA Subject: 20 to VAX DECNET To: TOPS-20@SU-SCORE.ARPA Is anybody out there running DECNET between a 20 and a VAX? How is your performance? Ours could be better. We are running DECNET-20 V3.0 on a 5.3 monitor, and DECNET-VAX V3.0 (Phase IV) with VMS 3.5. Our line devices on both sides are DMR's, in DMC compatibility, running at 1 megabit, full duplx. On the 20, we are getting a lot of NSPBADs and NSPLAT buginfs, whenever we use the link. We have a number of VAXen here, they all talk to each other fine, but they don't talk to the 20 too well. Is there anyone out there with a similar configuration? How is your DECNET performance? Is there something we can do to soup up our performance? Jim Yoshii YOSHII@EDWARDS-2060 ------- ------- 2-Jul-84 14:03:42-PDT,1470;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jul 84 14:03:29-PDT Date: Mon 2 Jul 84 17:07:20-EDT From: Ken Rossman Subject: Re: 20 to VAX DECNET To: YOSHII@EDWARDS-2060.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "YOSHII@EDWARDS-2060.ARPA" of Mon 2 Jul 84 14:31:19-EDT Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 We run a fairly large DECnet-based network here at CU (it also goes to CMU, Case Western, NYU, and Stevens Institute of Technology), and have many VAXen, some of which talk to DEC-20 DN20's. We run Phase III DECnet on our -20's and I believe Phase IV on most VAXen. We currently run most of our 20-VAX links over 9600 baud or 19.2Kbaud synchronous modems, though, so that's a difference. Our DN20's have DUP11's and KMC's, and the VAXen use either DMR's or DMF32's. Our performance, however, is not so different. We tend to get plenty of NSPLAT's and NSPBAD's. I'm not sure which nodes are the cause of these messages, though, or whether they are related to the VAX-to-20 links or not. Right now, I'm having the most trouble with our 20 to VAX 750 performance, though we have a link to a 780 which rarely gives us much trouble. So far, I have not found any way to make things work better, mainly because I'm not really sure where the problem is exactly. Ken Rossman CU Computer Center ------- 2-Jul-84 15:41:15-PDT,781;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Jul 84 15:41:05-PDT Date: Mon 2 Jul 84 15:40:24-PDT From: Kirk Lougheed Subject: Re: Program to do structure-to-structure copy? To: Vince.Fuller@CMU-CS-C.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Mon 2 Jul 84 11:32:49-PDT The MERLIN program is useful for piecemeal (and wholesale) copying of directory trees from one structure to another. The latest version is on Sierra as PS:MERLIN.MAC. It contains a number of bugfixes and performance improvements on the MERLIN program of a year ago. Columbia's ARTHUR program is a similar directory copying program... Kirk ------- 5-Jul-84 13:57:10-PDT,2111;000000000000 Mail-From: ALMQUIST created at 5-Jul-84 13:56:56 Date: Thu 5 Jul 84 13:56:56-PDT From: Philip Almquist Subject: Re: 20 to VAX DECNET To: YOSHII@EDWARDS-2060.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "YOSHII@EDWARDS-2060.ARPA" of Mon 2 Jul 84 11:22:52-PDT Jim, The DECnet configuration I have experience ran with Phase III software on the VAX's rather than phase IV. Nonetheless, I think I can make some good guesses since I once knew far more about DECnet than is good for a body. NSPLAT means that the 20 thinks that a remote node went down. This message can be generated when a remote node goes down or when all paths to a particular node go down. Since DECnet point-to-point links are not always terribly reliable (or perhaps more to the point, since DN20's are not terribly tolerant of imperfect lines), DECnet topologies that utilize point-to-point links should always contain redundancy. I don't recall that we used to get NSPBAD's. They (unfortunately) can mean either of two things: a message got corrupted in transit, or an unrecognized type of message arrived. The former problem is indicative of line problems. The latter problem might occur if the VAX's erroneously send Phase IV packets to your 20. If you have sources you can add a new kind of BUGCHK to tell which is which and generally give you more information about exactly where in the code the NSPBAD's are being generated. If you don't have sources you may be able to prevail on Ken Rossman to do this on his systems. Another thing you might try is looking at your DECnet errors with Spear's RETRIEVE function (the ANALYZE function doesn't work with DECnet unless they've fixed that pretty recently - ^%$%$#%$). If you don't have any it probably means that DECnet error logging is disabled; if so, turn it on, wait a couple of days, and try again. There is (or at least was) no documenation on what the errors mean, but you can partially guess or (if you have the expensive maintenance) call up the TSC and ask them. Philip ------- 5-Jul-84 15:04:52-PDT,2279;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Jul 84 15:04:32-PDT Date: 5 Jul 1984 14:48 PDT (Thu) Message-ID: From: David Eppstein To: TOPS-20@SCORE Subject: PMAP% bug Problem: Unable to unmap pages from section zero while in non-zero section. Repeat-by: @RUN SYS:SDDT.EXE/USE-SECTION:1 1/ -1 2/ .FHSLF,,0 3/ PM%CNT+PM%EPN+1000 PMAP%$X Diagnosis: I found out by reading the code in PMAP% that I am supposed to set PM%EPN in the PMAP% flags so that the address is absolute and not section-relative. This differs considerably from the documentation (Rel 5 JSYS manual), which states that "The right half of AC2 contains a process page number. If the section containing the page does not exist, a private section is created." The section seems to always be created whether or not PM%EPN is set. Thus the real meaning of PM%EPN seems to be that the page number given is taken as absolute rather than PC-relative. The code to check for PM%EPN is in FKHP1(FORK), jumped into from FKHPTX and FKHPTN. Each of these is supposed to be called with the PMAP% flags in T2; on delete, FKHPTX is the one called. Its caller is FRKMPX, jumped to from CPMAPX, called by PMAP0. Neither FRKMPX nor CPMAPX change T2 before FKHPTX is called, so it is set up by the following lines from PMAP0(JSYSA): CAMN B,[-1] ;DELETE ONLY? TDZA B,B ;YES, NO SECTION CREATES UMOVE B,3 ;NO, GET USER REQUESTED ACCESS Thus for deletes PM%EPN never gets passed to FKHP1, and section-zero pages are always treated as section relative. Solution (untested): Remove the first two of the three lines above, so the flags always get through. Then at FRKMP2, change the following two lines: JUMPE B,PMAPER ;NO CREATES IF B IS ZERO CAME B,[PM%EPN] ;JUST THIS BIT IS THE SAME AS ZERO into the following: MOVE C,SID ;GET SOURCE ID CAME C,[-1] ;NO SECTION CREATES IF DELETING PAGE This always passes the user flags to FKHP1, and puts the check for deletion just before section creation, where it belongs. Also fix the JSYS manual to correctly document PM%EPN. 6-Jul-84 09:36:34-PDT,1044;000000000000 Return-Path: Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Jul 84 09:36:21-PDT Date: Fri 6 Jul 84 09:36:55-PDT From: RALLIS@EDWARDS-2060.ARPA Subject: Avionics Models To: tops20@SU-SCORE.ARPA FROM: TS7821::MORRISON TO: ANY AVIONICS MODEL USER - preferably real-time simulations/emulations Any studies performed regarding the effect of simulation frame delays are of interest. Included is the case where the simulation may "lead" the data that is available to the actual aircraft. I am interested in avionics models for fighter aircraft(particularly the F-16C/D). I have specific interest in models of the following devices: CADC - Central Air Data Computer DTU - Data Transfer Unit FCR - Fire Control Radar HSI - Horizontal Situation Indicator HUD - Head-Up Display ILS - Inertial Localizing System INU - Inertial Navigation System MFD - Multi-Function Display RALT - Radar Altimeter SMS - Stores Management System TACAN ------- 6-Jul-84 12:38:20-PDT,1036;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 6 Jul 84 12:38:11-PDT Date: 6 Jul 1984 1535-EDT From: Mark Pratt To: ALMQUIST at SU-SCORE, YOSHII at EDWARDS-2060 cc: TOPS-20 at SU-SCORE Reply-to: Pratt at DEC-MARLBORO Mail-Stop: MRO1-02/L10 Subject: Re: 20 to VAX DECNET Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12029215664.36.273.12879 at DEC-MARLBORO> Regarding: Message from Philip Almquist of 5-Jul-84 1713-EDT Problem: Many NSPBAD BUGINFs when plugged into a Phase IV DECnet network. Diagnosis: Phase IV retransmitted connect initiate messages are being reported as bad messages. Solution: Before reporting a message as bad, check to see if its a retransmitted CI, and if so, toss the message without complaining. ==================== In NSPSRV, after DOMSG+2, add CAIN T2,150 ;IS THIS A RETRANSMITTED CI? JRST TOSMSG ;YES, TOSS IT, ITS ONLY FOR PHASE IV -------- 9-Jul-84 23:48:25-PDT,1569;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Jul 84 23:48:14-PDT Date: 10 Jul 84 02:43:17 EDT From: Charles Hedrick Subject: APL To: tops-20@SU-SCORE.ARPA 1) Does somebody have a current copy of APLSF? Apparently there was another of Software Services' many database errors, such that we have been paying for support but not getting new versions. Thus we are about 3 years out of date in our APL. 2) Our users have complained that after they exit from APLSF, either by )MON or ^C (5 times), when they CONTINUE it, ^H no longer works. It appears that APLSF carefully resets the initial terminal mode word and COC words, but does not put them back if you continue. The COC word causes the problem with ^H. Not putting back the JFN mode word causes no visible symptoms, but results in a BIN and an RDTXT being done for every character instead of every line. I have done the obvious patch: 77/ 246000,,145302 100/ 52532,,523125 101/ 50425,,653000 102/ movei 1,101 103/ dmove 2,100 104/ sfcoc 105/ move 2,77 106/ sfmod 107/ jrst reente .jbren/ 102 The contents of 77, 100, and 102 are simply the last values set for the JFN mode word and COC words inside APL (determined by trapping the SFMOD and SFCOC jsys's). This is not elegant, but is about all that can be done without source. I have instructed our users to use REENTER intead of CONTINUE. (A similar patch could, of course, be made to the code that is used by CONTINUE.) ------- 10-Jul-84 21:04:57-PDT,2254;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.SLOGIN@CU20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Jul 84 21:04:41-PDT Received: from CU20B by CUCS20 with DECnet; 11 Jul 84 00:05:37 EDT Date: Wed 11 Jul 84 00:05:13-EDT From: Thomas De Bellis Subject: Moving APLSF To: Tops-20@SU-SCORE.ARPA cc: Sy.SLogin%CU20B@COLUMBIA-20.ARPA Reply-To: CC.SLogin@COLUMBIA-20 One of our student machines, CU20A, has always been notoriously short of disk space. Earlier this summer, the situation became critical and we cabled up another RP06 disk drive for additional storage capacity. The structure on the RP06 is used to hold huge libraries such as HELP, DOCUMENTATION and IMSL that infrequently, or almost never, change. We copy the directories off of PS:, change the system logical name definition to point to the library structure and then zap the PS: directory to get more space. This approach has worked out rather well for us for a number of reasons. Disk head contention for PS: is reduced. Since the data on the library pack is never written, we back it up at a much less frequent rate. This makes operations happy because increasing our PS: would have meant going to a four pack RP06 structure and backing that up on our clunky old TU45's would have been a real chore. We also don't have to worry about giving users separate directories on the library structure since PS: has more space, so THAT management headache is elminated. Unfortunately, we are still running out of PS space on CU20A! I've moved all the "easy" stuff and now I'd like to move some of the "hard" stuff. APLSF is a good example of a "hard" thing to move. Here I have 3,000 pages just asking to be put on the library structure. So, I moved everything, redefined APL:, the system logical, deleted the PS: directory and then APLSF blew up! The darned thing is Tops-10 program hardwired to look for PS: and I can't move it off of PS:! So, now that we know what "hard to move" is, has anyone else run into this? Any suggestions before I start DDT'ing? Thanks! -- Thomas De Bellis Columbia Computer Center ------- 13-Jul-84 14:22:04-PDT,658;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Jul 84 14:21:53-PDT Date: 13 Jul 1984 1721-EDT From: Bob Longo To: TOPS-20 at SU-SCORE Mail-Stop: LAO Phone: 213-417-4240 Subject: VMS PHONE Program Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12031069939.23.355.19170 at DEC-MARLBORO> Has anyone ever seen a TOPS-20 program that will communicate over a DECnet link to a VMS user running PHONE? PHONE is a VMS utility that allows multiple users on a VAX (or DECnetted VAXen) to talk to each other via split screen windows on a VT100 terminal. -Bob -------- 14-Jul-84 18:22:29-PDT,388;000000000000 Return-Path: Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Jul 84 18:22:22-PDT Date: Sat 14 Jul 84 21:23:01-EDT From: COLE@BBNF.ARPA Subject: Source for PHOTO To: TOPS20@SU-SCORE.ARPA Would someone provide me with the source to the PHOTO program? Would the keeper of this list add me to it? Thanks in advance, Jon Cole (COLE@BBNF) ------- 15-Jul-84 08:12:11-PDT,396;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sun 15 Jul 84 08:12:04-PDT Date: 15 Jul 84 11:12:41 EDT From: Charles Hedrick Subject: PHOTO To: cole@BBNF.ARPA cc: tops-20@SU-SCORE.ARPA I think PHOTO is one of these things that every site has a slightly different version of. Ours is s:photo.mac. ------- 15-Jul-84 10:47:17-PDT,3723;000000000000 Mail-From: MRC created at 15-Jul-84 10:47:11 Date: Sun 15 Jul 84 10:47:11-PDT From: Mark Crispin Subject: mailsystem release: MAJOR functionality enhancement To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is to announce a major functionality improvement to the TOPS-20 mailsystem (available, as usual, from [SU-SCORE]MRC: via ANONYMOUS FTP): the addition of the "Special" network. By defining systemwide logical name MAILS:, a site may define a set of hosts which are delivered to externally from the mailsystem by creating a directory for the desired host as a subdirectory of MAILS:. The lowest level node of MAILS: defines the local host name on the "Special" network. For example, if MAILS: has been ^EDEFINE'd as being PS:, the local host name on the Special network is MUMBLE (or MUMBLE.#Special). If PS: and PS: exist, you can mail to hosts FOO and BAR. The reason for separate directories is to allow for different means of delivery. For example, you can give the mail delivery program for host FOO user group access to PS: without giving that same program access to any other mail. This is useful in "TTY network" type applications when host FOO would dial you up and pick up its mail. Files queued to the Special network are to the appropriate directory (obviously, mail to the local host is handled directly by MMailr -- not to PS:, etc.). The file name is of the form MAIL.*. The format is DIFFERENT from MMailr queued files - by design: these are not MMailr files. The format is a list of destinations delimited by CRLF, and finally a line with only a form-feed in it. A well-written program should be prepared to discard any line which starts with a form-feed and has other stuff in the line, to allow for future expansion of this format. It should be emphasized that MMailr does not deliver any mail to the Special network. It merely drops messages into a directory for some external process to pick up and deliver. Also, there is no provision for receiving mail from the Special network; it is the responsibility of the external process to build and queue properly formatted MMailr queue files to MAILQ:. Finally, to guarantee that the REPLY command in MM works it is advisable that all the hosts in a "Special cluster" create the subdirectories for all the other hosts (in otherwords, the subdirectories under MAILS: comprise the "host table" for the local Special network). MMailr will take care of any necessary transmogrification in RFC 822 format using the conventions instructed in DOMAINS.TXT. This means that the rubouts around the host name are NOT present in the files written by MMailr in the Special network directory. This frees the external application to do any non-RFC 822 transmogrification which may be necessary (e.g. for UUCP, see below). This can even be used in a more general fashion to support UUCP or MMDF. This is one by defining, say, UUCP as a Special network HOST, instead of the individual sites on UUCP (an impossible task). One could then use the DOMAINS.TXT functionality combined with transmogrification in the UUCP handler to deliver UUCP mail. For example, one might do "foo!bar"@UUCP or if bar is in DOMAINS.TXT foo@bar. Some work is being done in the area of supporting UUCP. The changed modulre HSTNAM and MMailr; of course, since everything uses HSTNAM you'll need to rebuild the entire mailsystem. -- Mark -- ------- 18-Jul-84 07:33:16-PDT,304;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 18 Jul 84 07:33:10-PDT Date: Wed 18 Jul 84 08:34:47-MDT From: Randy Frank Subject: MTU To: tops-20@SU-SCORE.ARPA Was anyone out there ever able to finds to sources to MTU? ------- 19-Jul-84 06:58:53-PDT,462;000000000000 Mail-From: MRC created at 19-Jul-84 06:58:47 Date: Thu 19 Jul 84 06:58:47-PDT From: Mark Crispin Subject: IP bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There should be a SETZRO CMCKS,(CPKT) before the CALL ICMCKS at ICMER9+3 in IPIPIP.MAC. This fixes bad ICMP checksums when rejecting a UDP port request. ------- 20-Jul-84 18:29:20-PDT,3239;000000000000 Return-Path: <@COLUMBIA-20.ARPA:SY.TAI@CU20D> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Jul 84 18:29:04-PDT Received: from CU20D by CUCS20 with DECnet; 20 Jul 84 21:30:20 EDT Date: Fri 20 Jul 84 18:16:13-EDT From: Tai Y Jin Subject: TEXTI EMACS mode To: tops-20@SU-SCORE.ARPA This question is addressed to those who use EMACS (who doesn't anyway?). There are some modifications which can be made to the TEXTI jsys which supposedly makes EMACS faster. These modifications are known as the "TEXTI EMACS mode." Has anyone made these modifications and what were the results of your tests? Is EMACS indeed faster with the modifications or slower (as we have found it to be). Well, here's the story... The modifications to the TEXTI JSYS prevent it from displaying break characters and suppresses the LF after a CR. This allows EMACS to insert text directly into the buffer. When a break character is typed in, the TEXTI jsys will just return and EMACS can then handle the character (a non-self-inserting character). When a non-break character is typed in, the TEXTI jsys handles it and puts it in the buffer specified in the TEXTI argument block. The TEXTI jsys continues to accept characters until a break character is typed in. In the normal EMACS, all input is handled by the PBIN jsys. In the modified EMACS, the input is handled by the PBIN and TEXTI jsyses. This is the way it works... Instead of having the PBIN jsys do all the work and EMACS having to wake up after every character typed in, the TEXTI jsys takes care of self-inserting characters and EMACS only wakes up after the TEXTI jsys returns. This does result in fewer jsys calls from EMACS and that is one factor in speeding things up. Another noticeable speedup will be seen when typing self-inserting characters, the scheduler in that case is doing the echoing, thus giving the appearance of a quick response. However, this is only what you see on the surface. Unfortunately, the TEXTI jsys makes a call to BIN for every character returned into the TEXTI buffer. So in reality you are making at least as many jsys calls as before. And to make things worse, BIN is probably slightly slower than PBIN, and calling the TEXTI jsys itself has some overhead. Anyway, we ran a batch job to test the efficiency of the modified EMACS and the results don't look good. In the batch file, EMACS was started up visiting a file and exited. The runtime of the process was recorded. Then EMACS was continued and hundreds of movement commands were entered and more text was appended to the end of the buffer. EMACS was exited and the runtime recorded. The first file visited was 81 pages and the second one (appended to the end of the buffer) was 98 pages. For the unmodified EMACS, the overall runtime was 5 minutes and 3.7 seconds. The modified EMACS had an overall runtime of 5 minutes and 44.7 seconds. If we can trust these results, they indicate that the modified EMACS is actually slower or more inefficient than a normal EMACS. Has anyone else tried EMACS with these modifications? If so, I'd like to hear of your test results. ------- 21-Jul-84 15:48:40-PDT,1183;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Sat 21 Jul 84 15:48:30-PDT Date: 21 Jul 1984 15:51-PDT Sender: BILLW@SRI-KL Subject: Re: TEXTI EMACS mode From: BILLW@SRI-KL To: sy.tai%CU20D@COLUMBIA-20 Cc: tops-20@SU-SCORE Message-ID: <[SRI-KL]21-Jul-84 15:51:53.BILLW> In-Reply-To: The message of Fri 20 Jul 84 18:16:13-EDT from Tai Y Jin I dont think that a batch job is a good test of the emacs modifications. in particular, whenever a terminal is in TTY input wait for over a second, it gets higher scheduler priority (its more likeley to run again immediately when a single character is typed). Since batch stuffs things into the input buffers, I would think that EMACS in batch would behave much differently than emacs running on a terminal. Also, the mods were specifically designed to increase efficiency durring text typein only - they will certainly be less efficient if you are doing primarilly commands... Im certainly interested if anyone has ideas of a good way to test all this out and get meaningful results... PS: Im biased, they're my modifications... BillW 21-Jul-84 16:06:11-PDT,929;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sat 21 Jul 84 16:06:05-PDT Date: Sat 21 Jul 84 16:06:00-PDT From: David Roode Subject: Re: TEXTI EMACS mode To: sy.tai%CU20D@COLUMBIA-20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tai Y Jin " of Fri 20 Jul 84 18:34:25-PDT Location: EJ286 Phone: (415) 859-2774 A PBIN called by EMACS causes the monitor to have to switch contexts from user to monitor and back again, for each character input. That is where the overhead is. By using TEXTI the number of these context switches is reduced greatly exactly where it is possible--in the case of text input. The context remains in the monitor until events dictate otherwise. Are you running your batch jobs on the dregs queue? If you do one would expect bizarre results such as you have outlined. ------- 21-Jul-84 20:29:20-PDT,1021;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 21 Jul 84 20:29:14-PDT Date: Sat 21 Jul 84 20:29:45-PDT From: Andrew Sweer Subject: GTJFN ? handling To: TOPS20@SU-SCORE.ARPA This note is to announce the availability to the TOPS20 community of the SUMEX GTJFN ? handling feature. For those that haven't seen it in action, it basically allows you to enter a ? anytime in a file specification (except as the 1st character) and have the monitor display the names of the files that match. This is especially useful when you get a beep when trying to use ESC or ^F to complete a field. The directory SS:<5-1-MONITOR> at SUMEX contains .DIF, and .RED files for GTJFN.MAC, COMND.MAC, LOOKUP.MAC, and GLOBS.MAC, as well as some other documentation files. Message me personally if you have further questions or problems integrating it locally. Andy P.S. Sorry to say I don't see a way to distribute this to non source sites. ------- 22-Jul-84 12:06:32-PDT,644;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sun 22 Jul 84 12:06:23-PDT Date: Sun 22 Jul 84 15:08:02-EDT From: Kevin Paetzold Subject: Re: TEXTI EMACS mode To: sy.tai%CU20D@COLUMBIA-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Tai Y Jin " of Fri 20 Jul 84 21:34:22-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 First of all I do not run Emacs. Second of all if anyone every gets the EMACS TEXTI code and sends it to me I will put it into release 6 of the monitor. ------- 22-Jul-84 13:25:32-PDT,787;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sun 22 Jul 84 13:25:24-PDT Date: 22 Jul 84 16:26:31 EDT From: Charles Hedrick Subject: EMACS TEXTI code To: tops-20@SU-SCORE.ARPA I don't see why anyone would expect the code you described to save CPU time. I thought the hope was that it might improve response time under load. That assumes that there is more overhead to rescheduling your job to handle a character than to having TEXTI do it. Does anybody know whether that is true? (I always thought TEXTI ran in a scheduler context that was fairly well equivalent to user code.) The real payoff would be if you could get TEXTI to do the echoing at clock level, or move it to the front end. ------- 22-Jul-84 17:26:42-PDT,1309;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Sun 22 Jul 84 17:26:28-PDT Date: Mon, 23 Jul 84 00:27 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: EMACS TEXTI code To: tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 As I remember it, the best reason I have heard as to why one would want to use TEXTI with EMACS was to allow a front end to do the echoing. That was NOT in the context of the KL, but rather the JUPITER, ie: the echoing might be moved to the ethertip, making emacs give better response and allowing the ethertip to collect a block of text up to the break character before sending anything to the host. I agree with Hedrick that I never heard anybody say it would cut cpu time, but it would improve the responsiveness of emacs and reduce the load the emacs places on the CPU. It has always been my feeling that if you cant run an editor like emacs you are not managing your system properly. Anyone who says the machine is more important that the people using it doesnt have much regard for people costs. - Sam - ------- 22-Jul-84 21:08:20-PDT,6526;000000000000 Return-Path: <@COLUMBIA-20.ARPA:GINGELL@CWR20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Sun 22 Jul 84 21:07:59-PDT Received: from CWR20B by CUCS20 with DECnet; 23 Jul 84 00:09:06 EDT Date: Sun 22 Jul 84 23:30:54-EDT From: Rob Gingell Subject: Re: TEXTI EMACS mode To: TOPS-20%SU-SCORE@CUCS20 In-Reply-To: Message from "Tai Y Jin " of Sat 21 Jul 84 16:55:54-EDT This is all very timely, I was in the middle of inserting the TEXTI% changes when this started. My comments are by way of explaining why I think it will be of benefit to our particular site to include them. As I read the code and intent of the changes, their effect will not be to cut down on the number of JSYSs (it might actually increase them), nor so much the amount of CPU billed to the user as it will be to reduce the number of context switches the system performs during text entry. The unmodified EMACS (potentially) will cause a context switch on every character. The CPU cycles which go to context switching and the related overhead activities are not insignificant, and reducing them gets you more machine to spend on user activities, be it even more EMACSing or whatever. By context switch, I mean the process of switching the machine between different forks and/or the null job. I'm not sure that there's a significant efficiency difference between user mode and monitor mode JSYSes. In answer to Chuck Hedrick's question about the cost of character-by-character PBINs as opposed to using TEXTI% to do it, TEXTI% will do it substantially more efficiently as long as the majority of the TEXTI% calls don't reduce to getting just a single character. While it is true that TEXTI% itself just does BIN%, it does so after first setting up the break mask and field width parameters so that the BIN% will not return until some "significant" event occurs: either an occurrence of a break character, exhaustion of the field width, or of monitor TTY buffer space. Characters which are typed prior to that, are echoed by the monitor during the 60 second scheduler cycle without waking up the process doing the TEXTI%. When the "significant" event occurs, the first character that was typed is returned as the result of the BIN%, and succeeding BIN%s (from TEXTI% or elsewhere) retrieve the pre-processed characters without going into terminal input wait. Where this will lose is if TEXTI% reduces to being a BIN%, because it ends up processing a single character at a time. TEXTI% is obviously more expensive than just BIN%, because it does a pile of JSYSes before calling BIN%. There's some threshold number of characters that TEXTI% should return to be more efficient than the equivalent number of BIN%s. It sounds like Tai's test in fact reduced to this case, as the movement commands will each be "significant" and thus TEXTI% will only return the one character. The TEXTI% modifications can thus win only if the population of "significant" events is small with respect to the total number of character typed. How small depends on how fast TEXTI% pays back for the extra cost of invoking it, hopefully it's paid back after the second character absorbed by a single TEXTI%. So, I would conclude that the TEXTI% win, when it occurs, is to cut down on the number of SKED cycles my machine consumes, not the user CPU time. If SKED gets cut down, I can either support more user load and/or make the load I do support (including EMACS users) more responsive. We made some different modifications to make system handling of EMACS and similar (large ratio of wakeups to compute time) processing more efficient. At present, when a fork goes into TTY input wait it gets a number of "priority" benefits. However, it also gets removed from the balance set and a number of other overhead tasks get invoked because it is anticipated that the fork will sleep for some large amount of time. However, EMACS violates these assumptions because it wakes up much faster than expected. So the system has gone through a considerable amount of work rearranging itself to deal with the sleeping fork, which it must then undo and probably yank the machine away from another fork because the (now) high priority EMACS fork is demanding the machine. Systems with a large number of such forks, or with an otherwise high load, start to get eaten away very quickly as dozens of users request processing at keystroke rates. To minimize the amount of work the system goes through on such occasions, we keep a new piece of information on a per fork basis, called the "wait history". The wait history is an average of the last "several" waits (exponentially decayed, as with the load average) and is used by the scheduler to determine if the fork it's putting to bed (or waking up) is going to sleep for a period long enough to justify the cost of knocking it out of the balance set (or has waited long enough to justify a priority boost). While we haven't settled on what the "good" parameters to this are, the effect on our systems seems to be that EMACS forks don't stay in queue 1 but don't tend to fall below queue 3. Their response remains good to ok because they're "brought in" easier, having not been "removed" in the first place. We're adding the TEXTI% changes in addition to this, because we already have most of our terminals (at this time, a total of 192 ports) on "remote front ends". The terminal service in our monitor "transports" a BIN% to the front-end to be processed except under certain conditions. The effect (when it holds) is that the characters are echoed by the front end and transmitted in a block to the KL when something significant happens. At the moment, this loses for EMACS, because EMACS wants to do all its own character processing, and the front-end doesn't get to handle the BIN%. The response is good in this situation, but sometimes gives one the "network feel" of delayed echoes when there's a big load on either the KL or the front-end. For those that are interested in this, I gave a paper on it at Fall DECUS '82 in Anaheim (the last "fun" 10/20 DECUS) which is in the procedings from there. However, although we are putting in the TEXTI% stuff, this is really a stop-gap measure. The whole screen handling portion of EMACS should be resident in the front-end (or your PC) to win with all of this in a big way. Rob ------- 22-Jul-84 22:15:15-PDT,1067;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Sun 22 Jul 84 22:15:03-PDT Date: Mon, 23 Jul 84 05:15 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: Re: TEXTI EMACS mode To: GINGELL@CWR20B.CCnet cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Rob Gingell " of Sun 22 Jul 84 21:16:40-PDT Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 Your idea about the screen handling being done better in the PC sounds like an editor in use at LLL. It is called COED, a co-resident editor. It runs in both the CRAY and the (IBM) PC. The PC does the screen handling, passing line editing commands to the cray and receiving a screen full of text at a time from the cray. It seems to be fairly popular among the users of PCs. The screen editor is based on FINE, which is a TOPS-10 clone of EMACS. - Sam - ------- 23-Jul-84 01:09:28-PDT,1715;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Jul 84 01:09:13-PDT Date: 23 Jul 1984 01:13-PDT Sender: BILLW@SRI-KL Subject: TEXTI changes and cursor movment... From: William "Chops" Westfield To: tops-20@SCORE, gingell%cwr20b@CUCS20 Message-ID: <[SRI-KL]23-Jul-84 01:13:06.BILLW> 1) I beleive that the texti mods will actually end up reducing the number of jsys calls, since a seperate pbout call is no longer necessary to echo each character. 2) Yes, of course this would be a much bigger win on a sort of remote front end. I beleive that vax DECNET for example, essentially passes (the equivilent of texti) arguments, and lets the local host do echoing and break mask handling. You have to start someplace... 3) It really isnt as bad as you might think if you are merely moving the cursor all around. There are a bunch of conditions that have to be true before the modified emacs will use TEXTI instead of PBIN. An obvious condition is that the cursor be at the end of line. A more subtle condition is that point be at the start of the gap (because characters are read directly into the buffer). Thus when you are doing heavy editing, rather than text entry, you may never do a TEXTI at all. [These conditions are based on the MIT ITS code. Improvements can be made. For example, most modern terminals have INSERT MODE, so TEXTI could be used in the middle of a line. (in general, EMACS handles insert mode type terminals VERY poorly!)] I was wondering if the mods were ever going to provoke any discussion... This is all very interesting.... BillW 23-Jul-84 05:53:56-PDT,1589;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Jul 84 05:53:48-PDT Date: 23 Jul 1984 0850-EDT From: Thomas Blinn To: sy.tai%cu20d at COLUMBIA-20, tops-20 at SU-SCORE Reply-to: Blinn at DEC-MARLBORO Home: "3209 Windsor Ridge Drive, Westboro MA 01581" Office: "One Iron Way, MRO2-2/8D2, Marlboro MA 01752" Telephone: "(617) 467-5562, DTN 231-5562, home (617) 366-0308" Subject: Re: TEXTI EMACS mode Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12033598409.23.275.21263 at DEC-MARLBORO> Regarding: Message from BILLW@SRI-KL of 21-Jul-84 1851-EDT In-reply-to: <[SRI-KL]21-Jul-84 15:51:53.BILLW> Running in batch would have no impact on the total CPU used, but probably would effect the elapsed time (which probably would be lower in batch than at a real terminal). Since the results being reported are for CPU time, not elapsed time, there is probably no artifact of batch. In fact, since certain kinds of overhead are reduced (e.g., paging), it may well be that running in batch makes EMACS look more efficient. The only way to eliminate the batch artifact and still get a reproducible experiment is to use some sort of scripting program driving a "real" TTY port. Due to code in the monitor, programs controlled by PTYs do not get terminal input wait credit (it's not just batch -- any PTY, even PTYCON controlled terminals). Running batch in the dregs queue should have no particular effect on the CPU time used to run a job, but primarily on the elapsed time. -------- 23-Jul-84 07:03:52-PDT,1083;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Jul 84 07:03:42-PDT Received: ID ; Mon 23 Jul 84 09:37:24-EDT Date: Sat, 21 Jul 1984 15:00 EDT Message-ID: From: "Leonard N. Zubkoff" To: Tops-20@SU-SCORE.ARPA Subject: NOFNDU BUGHLT's We have been getting quite a few NOFNDU BUGHLT's of late that all seem to be due to superseding a file with FB%BAT set. Diagnosis and fix for the problem is as follows: If a file with FB%BAT set is GTJFN%'d with GJ%FOU and then OPENF%'d with OF%WR, .OPENF calls DSKOPN which calls DELFL1 to delete and expunge the old contents of the file, and DELFL1 then calls DELPT. DELPT goes to OFNDLN for files without FB%BAT, and to DELBAD for files with FB%BAT. But DELBAD then uses P1 - P5 without restoring them. Since JFN = P2 and DEV = P4, when FNDUNT is later called in .OPENF after return from DELFL1, JFN is garbage and a NOFDNU BUGHLT results. Fix: Change SAVEQ to SAVEPQ at DELPT in PAGEM. 25-Jul-84 14:01:34-PDT,1861;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Mon 23 Jul 84 07:32:45-PDT Date: Mon, 23 Jul 84 14:33 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: EXEC bug To: tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 The autopatch (tape 7) exec has problems with "%" in load class commands. There is a patch in the 1-july-84 dispatch which is a big loose. I got the following from the TSC. They took it from the rel 6 sources and it seems to fix the problem. This is the corrected version of CMPER in EXECCS. ;COME HERE IF "%" SIGN SEEN. WE HAVE TO OUTPUT A COMMA PRECEEDING THE "%" SIGN. ;BUT IF THERE IS AN INDIRECT FILE BEFORE THE "%" SIGN, DON'T WORY ABOUT IT. CMPER: LDB Q1,CDPTR ;LOAD THE LAST OUTPUT CHARACTER CAIN Q1,"," ;IS IT A COMMA? RET ;YES, FORGET ABOUT IT SETO B, ;GET -1 ADJBP B,CMPPT0 ;ADJUST POINTER TO STRING BACK ONE CHAR MOVEM B,CMPPT0 ;SAVE THIS AS ORIGINAL BYTE POINTER MOVE A,CDPTR ;GET POINTER TO DESTINATION BYTE CALL SUBBP ;GET NUMBER OF BYTES TO MOVE SOJ A, ;ADJUST BY ONE MOVN C,A ;TELL SOUT EXACT NUMBER OF BYTES TO MOVE MOVE A,CMPPT0 ;WHERE TO MOVE STRING TO MOVE B,CMPPT0 ;GET NEW START OF STRING IBP B ;MAKE OLD START OF STRING SKIPGE C ;DON'T DO SOUT IF ZERO! SOUT% ;MOVE THE STRING BACKWARDS MOVEI B,"," ;GET A COMMA IDPB B,A ;STORE IT BEFORE "%" MOVEI A,"%" ;GET BACK '%' RET ;DONE. CONTINUE PROCESSING ;MAIN PARSER PARSE: CALL RDFLD ;HERE TO READ A FIELD This patch is needed if you have the autopatched exec and want to build MM using the .CTL file supplied by MRC. - Sam - ------- 27-Jul-84 23:17:57-PDT,1061;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Jul 84 23:17:45-PDT Date: Fri 27 Jul 84 23:18:04-PDT From: Charles Hedrick Subject: Rutgers is temporarily off the net To: tops-20@SU-SCORE.ARPA, header-people@MIT-MC.ARPA, paetzold@DEC-MARLBORO.ARPA Rutgers is in the process of moving from NYU (a DDN node) to Columbia (an Arpnaet node). Unfortunately, only half of the necessary workorders were issued, so our phone line has now been moved, but not the equipment necessary for us to connect to the IMP. We hope to be back on the net sometime this week. You can contact us via UUCP through allegra: ... allegra!ru-blue!user@color where color is one of Red, Blue, or Green. (the Arpanet node is Red.) You can also send mail to HEDRICK@SUMEX. I will log in here at least once a day, and will forward message to others at Rutgers. However I will forward them by writing them down and resending them, so please only use this for critical cases. ------- 29-Jul-84 18:40:02-PDT,411;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sun 29 Jul 84 18:39:53-PDT Date: Sun 29 Jul 84 19:41:40-MDT From: Randy Frank Subject: modem program To: tops-20@SU-SCORE.ARPA reference is made in the new Macterm documentation to the fact that it will work with the "SRI modem" program. Anyone know where I can get this? Randy ------- 30-Jul-84 15:57:45-PDT,851;000000000000 Mail-From: ALMQUIST created at 30-Jul-84 15:57:37 Date: Mon 30 Jul 84 15:57:37-PDT From: Philip Almquist Subject: Re: TEXTI EMACS mode To: Blinn@DEC-MARLBORO.ARPA cc: sy.tai%cu20d@COLUMBIA-20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Thomas Blinn " of Mon 23 Jul 84 05:50:00-PDT Yes, the code in the monitor assumes that anything on a PTY should not get terminal input wait credit (because it is presumably a batch job?). That is silly but simple to fix. Take a look at the CMU-CS-C monitor (SCHED, TTYSRV, FILMSC?) for the fix that I wrote when I was there. It should perhaps be redone, since it was a very general solution intended to allow us to some things we never actually got around to doing, but it shows in general what needs to be done. Philip ------- 31-Jul-84 14:43:22-PDT,2001;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 31 Jul 84 14:43:06-PDT Date: Tue 31 Jul 84 14:44:12-PDT From: Greg Satz Subject: rwhod for tops-20 To: tops-20@SU-SCORE.ARPA, unix-wizards@BRL-TGR.ARPA I just finished up an rwho daemon with the associated ruptime and rwho user programs for TOPS-20. For those of you who don't know what the rwho daemon does, let me explain. 4.2bsd Unix has a daemon which runs in the background transmitting and listening for broadcast UDP packets over an ethernet. The packets contain information about particular systems, such as their names, number of users, load averages, uptime as well as some info about each user who is on the system at the time. At five minute intervals, rwhod wakes up and sends out this information to other systems. rwhod writes out this info into one file per host where rwho and ruptime can read it. ruptime displays one line per system containing the system name, number of users on, load averages, and uptime. rwho displays all of the users on all of the systems. Mike Muuss (mike@brl) made changes to the Unix rwho daemon to allow it to send packets to hosts not on an ethernet. This allows agreeing Internet sites to exchange user/host info. My version for TOPS-20 can exchange rwho UDP packets with any 4.2bsd or TOPS-20 site running the daemon. It utilizes Vince Fuller's UDP library package for all UDP transactions. At startup, the daemon reads the file SYSTEM:HOSTS.UDP for a list of hosts to send udp packets to. Each host is on a separate line and A.B.C.D address are accepted. A version of the user programs exist but aren't fully implemented. ruptime only outputs hosts in alphabetical order. rwho just outputs users in the order they are received in the packet. To be useful, it should sort the usernames alphabetically like the unix version. If anyone is interested in a copy of these programs, let me know. ------- 1-Aug-84 09:54:31-PDT,574;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 1 Aug 84 09:53:02-PDT Received: ID ; Wed 1 Aug 84 12:53:55-EDT Date: Wed 1 Aug 84 12:53:50-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: TTYSRV curiosity To: tops-20@SU-SCORE.ARPA Does anyone know why the decnet code in TTYSRV is not organized into a submodule like the TVT code? I recently removed all of the MCB-conditional code from TTYSRV and TTPHDV into a new submodule, TTMCDV and don't see why this wan't done all along. --Vince ------- 2-Aug-84 08:27:34-PDT,1399;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 2 Aug 84 08:27:24-PDT Received: ID ; Thu 2 Aug 84 11:00:33-EDT Date: Thu 2 Aug 84 09:52:10-EDT From: Aaron.Wohl@CMU-CS-C.ARPA Subject: illuuo crashes To: tops20@SU-SCORE.ARPA cc: remarks%CMU-CC-TE@CMU-CS-C.ARPA Symtom: Long GTJFN% with bogus byte pointer in argument block gets ILUUO. For example, 777300,,107001 in default device word. Diagnosys: In GTJFN% at REDFL1 there is an XCT whose effective address is a STKVAR containing a PXCT of an ILDB. When the ILDB attempts to touch the bad byte size byte pointer it generates an illegal instruction. KIMXCR in APRSRV attempts to check for PXCT of byte pointer instructions and trap to user instead of ILLUUO. Unfortunetly KIMXCR has STKVARs of its own so when it chases down the XCT chain it gets the wrong address and concludes that the instruction was not an ILDB. Solution: KIMXCR is being optomistic about its powers to simulate the tops-20 effective address calculation procedure. The microcode should realy have a PXCT trap so all this doesn't have to be guessed at. For a simple fix for the GTJFN case: at labek REDFL1 change: XCT XCTV to: MOVE T2,XCTV ;get address in a register where XCT T2 ;KIMXCR can find it Aaron Wohl (WOHL@CMU-CS-C) ------- 2-Aug-84 16:24:05-PDT,2832;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 2 Aug 84 16:23:48-PDT Date: Thu 2 Aug 84 18:24:43-CDT From: Clive Dawson Subject: 20th Anniversary of 36 Bits To: arpanet-bboards@MIT-MC.ARPA, tops-20@SU-SCORE.ARPA 1984 marks the 20th Anniversary for DEC's 36-bit family of computers. Everything started back in 1964 when the ancestor of today's DECSYSTEM-10's and DECSYSTEM-20's, the PDP-6, was announced. The Fall DECUS Symposium, to be held in Anaheim from DEC-10 through DEC-14, 1984, will have several sessions as well as a banquet to celebrate the last 20 years. One of the sessions being planned is a "36-Bit Pioneers Rountable" in which people who have significantly influenced the history of DEC's 36-bit machines will participate in a panel discussion and reflect on the developments of the last 20 years, share old war stories, etc. Another session being planned is the "36-Bit Trivial Pursuit" session in which a team from DEC will meet a team of customers in a contest patterned after the old college bowl. SO...I need the help of all the old DEC-10/20 hackers out there: 1. We are making up a list of all the people who played a role in 36-bit history. This does NOT only include DEC people, but also users who influenced the development of the hardware or software. Many of these folks have left the scene over the years, and we would like to track them down to let them know of the plans for Anaheim. It would be a shame if somebody missed out on the fun simply because they were never told about it. From this list we will pick the people who will be invited to be in the Pioneer's Round Table session. If you have strong feelings about who these people should be, let me know. Please send me names as well as pointers to where these folks might be contacted if you happen to know. 2. I need volunteers for the 36-Bit Trivial Pursuit customer team, AND, even more important, I need trivia questions!!! Get those old manuals and printouts out and start digging! 3. We are also planning to put together a special edition of the Large Systems SIG newsletter, available at DECUS, full of as much 36-bit memorabilia as we can get our hands on. Please go through your old files, bookcases, store rooms, etc., and mail me any neat stuff you find. Examples would be funny SPR's, written accounts of strange happenings related to either hardware or software, etc. Net mail address: CLIVE@UTEXAS-20 U.S. mail address: Clive Dawson Computation Center Univ. of Texas Austin, TX 78712 Thanks!! Hope to see you at Anaheim. Clive ------- 3-Aug-84 10:43:51-PDT,713;000000000000 Return-Path: Received: from RUTGERS.ARPA ([10.1.0.89].#Internet) by SU-SCORE.ARPA with TCP; Fri 3 Aug 84 10:43:35-PDT Date: 3 Aug 84 13:43:22 EDT From: Charles Hedrick Subject: change in host address for RUTGERS To: tops-20@SU-SCORE.ARPA Please make sure that your HOSTS.TXT show Rutgers as 10.1.0.89. Our network connection has moved from NYU to Columbia, so we have a different IMP number. Here are the correct entries: HOST : 10.1.0.89 : RUTGERS,RU-RED : DEC-2060T : TOPS20 : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : HOST : 10.1.1.89 : RU-GREEN : DEC-2060 : TOPS20 : TCP/SMTP : HOST : 10.1.2.89 : RU-BLUE : DEC-2060 : TOPS20 : TCP/SMTP : ------- 3-Aug-84 11:19:33-PDT,1846;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Aug 84 11:18:56-PDT Date: 3 Aug 84 14:18:38 EDT From: Charles Hedrick Subject: bug in MACRO's number-reading code To: tops-20@SU-SCORE.ARPA Problem: MACRO can't read the number -34359738368 (i.e. 400000,,0) in decimal radix. Diagnosis: At NUM1, there is a typical multiply-add loop for scanning integers. The multiply is carefully done using double- precision, so that one bit of overflow is handled. This is what allows MACRO to be able to read 4xxxxxxxxxxx in octal. Unfortunately, they do not handle overflow on the ADD. In most cases, the overflow will happen on the multiply. (Indeed in radix 8, it always happens there, which is why the problem never showed up in octal.) However for about 9 particular bit patterns, the overflow will occur at the ADD, and the result is incorrect. In case you wonder why I am spending so much time analyzing this, it is to convince you that the proposed patch is safe. If MACRO just truncated decimal numbers at bit 0, then there might be code that depended upon the fact that large decimal integers got truncated. (I know it sounds like bad programming practice, but there are more unlikely things done in GLXLIB.) However since the code is obviously intended to handle this case, and does so almost all the time, it seems safe enough to fix it. Cure: File 1) MACRO.MAC.3, 2-Aug-84 22:50:05 File 2) MACRO.DEC.1,30-Aug-82 23:00:47 ;insert code after NUM1+7: ************** 1)31 tlze ac1,400000 ;[1] check for overflow 1) aoj ac0, ;[1] and propagate it 1) CAML C,CURADX ;[613] IS NUMBER LESS THAN CURRENT RADIX? **** 2)31 CAML C,CURADX ;[613] IS NUMBER LESS THAN CURRENT RADIX? ************** ------- 3-Aug-84 12:21:00-PDT,505;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Aug 84 12:20:51-PDT Date: Fri 3 Aug 84 12:21:45-PDT From: David Roode Subject: Dired tailored to ARCSYS To: TOPS-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 Does anyone have a DIRED type of program or EMACS Macro that can display archive attributes (such as only working on files that have been archived) and also Delete with the Contents-Only option? ------- 3-Aug-84 12:49:43-PDT,523;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Aug 84 12:49:27-PDT Date: 3 Aug 84 15:48:05 EDT From: Don Subject: Re: Dired tailored to ARCSYS To: ROODE@SRI-NIC.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "David Roode " of 3 Aug 84 15:21:45 EDT We've hacked REV to know quite a bit about the archive system (including the subcommands for DELETE). The source lives on S:<5-1-BUNDLED>REV.MAC. Don ------- 3-Aug-84 13:18:43-PDT,1388;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Aug 84 13:18:30-PDT Date: 3 Aug 1984 1617-EDT From: Alan H. Martin To: TOPS-20 at SCORE DTN: 231-4528 Mail-Stop: MR1-2/L14 Office-location: "MR1-2/M8 (By the cat posters)" Subject: Re: bug in MACRO's number-reading code Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12036563351.34.659.106271 at DEC-MARLBORO> If I understand the problem correctly, there is a more elegant solution: Macro presently accumulates digits by adding them into a running sum, and negating the result if it should be negative (if NEGSW is set). Instead, *subtract* them from the running sum and negate the result if the number is supposed to be *positive*. This handles both positive and negative infinity correctly. It even works with single precision. Unfortunately, Macro is too complex for me to figure out how to make the change before my attention span would run out. I will forward your mail to the Macro maintainer, but you should submit an SPR to be sure that the problem is tracked and fixed. Compiler writers on the list might want to use this trick for their own front ends. This comes directly from "A Short Note on Scanning Signed Integers" by James R. Low on pp 55-56 of Jan-79 SIGPLAN Notices (Vol 14, #1). /AHM/THX -------- 3-Aug-84 19:47:47-PDT,800;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Aug 84 19:47:30-PDT Date: 3 Aug 84 22:47:24 EDT From: Charles Hedrick Subject: MACRO's number scanning To: amartin@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA The reason I didn't do what you suggest is that in MACRO you can normally specify full 36-bit quantities in positive form. Consider for example that you can specify 400000,,400000 as exp 400000400000, when you are working in octal. Obviously the code was designed to allow you to do this in all radices. It just didn't always work except in octal. To make this work, we have to use full 36-bit unsigned arithmetic. That's what the current code does, and my patch just fixes it to work all the time. ------- 6-Aug-84 14:15:18-PDT,688;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 6 Aug 84 14:14:38-PDT Date: Mon 6 Aug 84 14:14:08-PDT From: Kirk Lougheed Subject: PLOT10 routines To: tops-20@SU-SCORE.ARPA cc: acken@SU-SIERRA.ARPA, ferd@SU-SIERRA.ARPA We recently purchased the PLOT10 plotting package from Tektronix and discovered that we needed some system dependent routines. We were able to scrape together a couple of the essential routines (e.g. output to the terminal). Before we go off and reinvent the wheel, however, has any one else written the system dependent PLOT10 routines for TOPS-20? Thanks, Kirk ------- 6-Aug-84 16:52:41-PDT,1165;000000000000 Received: from LOTS-A by Score with Pup; Mon 6 Aug 84 16:52:37-PDT Date: Mon 6 Aug 84 16:38:21-PDT From: M.MACHEFSKY@LOTS-A Subject: CI/HSC50 TECHNICAL SEMINAR To: SU-TOPS-20@Score SUNDEC TECHNICAL SEMINAR PLACE: TERMAN AUDITORIUM, STANFORD UNIVERSITY TIME: WEDNESDAY AUGUST 8, 4:15-5:15 SUBJECT: THE COMPUTER INTERCONNECT (CI) AND THE HSC50 SPEAKER: KERBEY ALTMANN, DIGITAL EQUIPMENT CORPORATION The Computer Interconnect (CI) is DEC's high speed interprocessor bus used in the creation of loosely-coupled multiprocessor configurations called "Clusters". The HSC50 is the mass storage server designed specifically for Cluster environments that is able to answer I/O requests over the CI from multiple, independent host systems. Kerbey Altmann was the project leader for the implementation of CI and HSC50 support in VMS. He will be joined by Ken Bates from the HSC50 engineering group in Colorado Springs. The presentation will concentrate on the technical details of the CI and HSC50 and the considerations involved in supporting it in VMS. Refreshments will be served proir to the presentation at 4:00. ------- 6-Aug-84 21:16:24-PDT,1382;000000000000 Mail-From: MRC created at 6-Aug-84 21:16:15 Date: Mon 6 Aug 84 21:16:15-PDT From: Mark Crispin Subject: changes... To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I started work today at Systems Concepts, where I will be doing software development on Mars ("Mars is like Jupiter, only it's smaller and it's closer"). The first prototype of Mars already runs TOPS-10; my job will be to get it to run TOPS-20 as well. I will continue to work at Stanford at 1/8 time, and will also, with the agreement of the membership, continue to moderate the TOPS-20 list. If it turns out that I can't continue to do so, I'll turn over the list to someone I'm sure will ensure its continued viability. The most important change affecting the list is that I am no longer in a position to pass on, or to comment about, any rumors concerning DEC or especially Systems Concepts. I encourage people to continue seeking juicy tidbits out and posting them on the list; however, such posting must not be considered in any way to be a statement reflecting the opinions of the management of Systems Concepts or myself. Except for points about announced information, I will not be willing or able to confirm or deny any rumors. ------- 9-Aug-84 08:20:01-PDT,711;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Thu 9 Aug 84 08:19:52-PDT Received: ID ; Thu 9 Aug 84 11:17:14-EDT Date: Thu, 9 Aug 1984 11:17 EDT Message-ID: From: "Leonard N. Zubkoff" To: Tops-20@SU-SCORE.ARPA Subject: Query What is the maximum amount of memory TOPS-20 can handle? I'm aware that for most applications, more than 2 - 3 meg is not usually justified. We run a strange mix and I'm curious just how much memory can be thrown at the problem. We have a source license, so we can modify the monitor if necessary to support additional memory. Leonard 9-Aug-84 09:12:01-PDT,691;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 9 Aug 84 09:11:51-PDT Date: Thu 9 Aug 84 12:14:27-EDT From: Gordon Strong Subject: Re: Query To: Zubkoff@TL-20B.ARPA cc: Tops-20@SU-SCORE.ARPA, GS@MIT-XX.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of Thu 9 Aug 84 11:34:00-EDT Date: Thu, 9 Aug 1984 11:17 EDT From: "Leonard N. Zubkoff" What is the maximum amount of memory TOPS-20 can handle? ... I believe that the maximum under V5 is 2M. I have heard that V6 will bump that figure up to 3M. However, 4M is the architectural limit. Gordon ------- 9-Aug-84 09:56:24-PDT,1032;000000000000 Mail-From: MRC created at 9-Aug-84 09:56:13 Date: Thu 9 Aug 84 09:56:13-PDT From: Mark Crispin Subject: Re: Query To: Zubkoff@TL-20B.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of Thu 9 Aug 84 08:20:04-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) My experience suggests that a TOPS-20 system can always do with more memory. Demand grows to fit the resources. This is especially true on research systems, however academic and industrial systems aren't far behind. It's a management problem to decide how much memory is the proper balance between need and cost. A KL processor is limited to 4 meg by the hardware, and the KL pager is limited by its format to 8 meg. Any machine with larger amounts of memory would have to have a different page table format. Fortunately, the extension is fairly obvious and it would go to all 30 bits. ------- 9-Aug-84 10:10:25-PDT,952;000000000000 Mail-From: MRC created at 9-Aug-84 10:10:03 Date: Thu 9 Aug 84 10:10:03-PDT From: Mark Crispin Subject: Re: Query To: Zubkoff@TL-20B.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of Thu 9 Aug 84 08:20:04-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The limiting factor in TOPS-20 for memory is the size of the various pager data structures which are resident (and consume address space). These are the SPT (Shared Page Table) and the various CST's (Core Status Table). Off the top of my head, I believe you need 4 pages of address space for every moby or 16 pages for each meg just for CST0 through CST3. The SPTx and CST5 stuff aren't word-per-page like the CST's are, but they are a function of the amount of memory so they grow as your system grows as well. ------- 9-Aug-84 10:47:28-PDT,1377;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 9 Aug 84 10:47:15-PDT Date: Thu 9 Aug 84 13:47:42-EDT From: Kevin Paetzold Subject: Re: Query To: Zubkoff@TL-20B.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of Thu 9 Aug 84 11:30:17-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 There are hardware limits to how much memory you can put on your machine. The machine can only address 22 bits of memory (which limits you to four meg). However there are also limits too how many memory controllers you can put on the SBUS. Depending on what kind of memory you have determines how much you can get. Going above 3 meg is sort of hard. If you rebuild your monitor setting MAXCOR to the desired value and adjusting other parameters (eg. NJOBS, NFKS etc...) you may be able to build a 3 meg monitor. If you want a lot of jobs and a lot of memory then you have some trouble. The alternative is to move the CSTs to a non zero section. We have done this for release 6. Moving the CSTs is not easy and requires very extensive modifications to most of the core modules of the monitor. LINKABIT does however have a release 5 era monitor with extended CSTs. ------- 9-Aug-84 10:52:55-PDT,871;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 9 Aug 84 10:52:29-PDT Date: Thu 9 Aug 84 13:52:55-EDT From: Kevin Paetzold Subject: Re: Query To: Zubkoff@TL-20B.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of Thu 9 Aug 84 11:30:17-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 additional comments... my experience is that above 3 meg the system does not go any faster it just does not page most of the time. With that much memory the monitor can almost always find something usefull to do and adding more memory does not help things. It is always possible that you have some obscure bizarre application with a 4000 page working set and that you can use the eztra memory... ------- 10-Aug-84 10:47:13-PDT,1545;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 10 Aug 84 10:46:47-PDT Date: Fri 10 Aug 84 10:47:38-PDT From: Andrew Sweer Subject: Hung TCP Connections To: TOPS20@SU-SCORE.ARPA Have other sites been experiencing gradual TCP connection decay? It seems that we "lose" 1 or 2 connections per day, so that after uptimes of a week or so, we begin seeing messages like "Maximum TCP connections exceeded", or "Insufficient System Resources (Job Storage Block full)". Retrying the connection usually succeeds, although after a while it be- comes annoying enough that we resort to reloading the system. I find it a tad difficult to describe the hung connections, due to the varying status reporting programs around, including TSTATS, NETSTAT, IPSTAT, and SYSDPY, but I can say a few things. The hung connections seem to originate on both TELNET and FTP ports, and always indicate that a TVT is present (TTVT bit on in the TCB Flags word) but the contents of TVTL are zero! It also appears that the Receive side of the connection is established, while the send side is not; perhaps indicating that the hung condition stems from a failure from the foreign end at an inopportune time. Finally, I must note that we (SUMEX) are running some Stanford variations from the vanilla monitor, but seeing the recent report about the missing index on the send timeout (TSTO) reference makes me wonder if this phenomenom isn't more wide-spread. Andy ------- 10-Aug-84 11:19:58-PDT,808;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 10 Aug 84 11:19:44-PDT Date: 10 Aug 84 14:22:19 EDT From: Charles Hedrick Subject: hung TCP connections To: tops-20@SU-SCORE.ARPA Yes, we see something like this. We currently have 3 connections that look like J,JCN TVT STATE 0,4 0 -3-.PND The windows look like a connection is open (i.e. not 0 or 1). The local socket is 23. I assume these are incoming Telnet connections that got closed badly. They have never caused us trouble. We don't stay up that long, and they don't accumulate fast enough. Note that we are running 5.3. It will be interesting to see whether the problem continues after we bring up 5.4 (which we should do this evening). ------- 10-Aug-84 11:49:18-PDT,479;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 10 Aug 84 11:49:01-PDT Date: Fri 10 Aug 84 14:48:40-EDT From: Kevin Paetzold Subject: Re: hung TCP connections To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Fri 10 Aug 84 14:22:19-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 ------- 10-Aug-84 12:39:48-PDT,1197;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 10 Aug 84 12:39:29-PDT Date: Fri 10 Aug 84 12:40:03-PDT From: Greg Satz Subject: Re: Hung TCP Connections To: SWEER@SUMEX-AIM.ARPA cc: TOPS20@SU-SCORE.ARPA In-Reply-To: Message from "Andrew Sweer " of Fri 10 Aug 84 10:56:38-PDT Here at the NIC, we see a few hung connections every day. The symptoms seem to be the same as yours. We recycle the system weekly to prevent network clogging. Most of our servers clean up after themselves. That is, they check the status of the connection and abort them after a while if they are in an unknown state. The worst problem we have is with hung FTP connections. We were using MRC's netsrv for a while but switched to FTTCTT to see if that might help. It seems to but we still get some hung connections. It seems that there is no way to abort them. TELNET is a problem, except we have a program from Alan Larson that can be run under SYSJOB that scans all of the open connections looking for ones in EST.NOT or NOT.EST and aborts them. We are also running a Stanford flavored monitor. ------- 14-Aug-84 22:42:04-PDT,949;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Tue 14 Aug 84 22:41:51-PDT Date: Wed, 15 Aug 84 05:42 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: bug in RENAME command? To: tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 If you use the RENAME command to change a file to the same name in the same directory and there is more than one generation of the file then you wind up in a continuous loop renaming to successively higher generations. I know that seems like a silly thing to try to do, but consider a procedure which wants to rename a file into a particular directory, but for once it is run while connected to that directory. Any ideas on how to prevent it? - Sam - ------- 15-Aug-84 12:22:24-PDT,1188;000000000000 Mail-From: CRISPIN created at 15-Aug-84 12:22:02 Date: Wed 15 Aug 84 12:22:02-PDT From: Mark R. Crispin Subject: PHYSIO question To: TOPS-20@SU-SCORE.ARPA Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 Can anybody give me a GOOD reason why the DSKUTP, DSKSIZ, and NAMUTP tables are in PHYSIO instead of STG where they really ought to be? My guess is that somebody didn't want to let STG search PHYPAR (one less source file you'd HAVE to give customers). However, this `feature' means that you cannot add a new disk type to the system without one of: . having sources . being external to PHYSIO . DDT patching out one of the other disk types . pretending that the new disk type is one of the other disk types In particular, you can't merely supply a REDIT to STG, a new LNKxxx.CCL file, and some additional REL's to the DEC-supplied TOPS20.REL. You have to go in and alter PHYSIO (supplying an altered PHYSIO.REL to non- source sites) or saddle the customer with "required DDT patches"... I hope DEC will either come up with a convincing reason for the status quo or change it. ------- 16-Aug-84 00:50:59-PDT,693;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Thu 16 Aug 84 00:50:48-PDT Received: from CU20B.ARPA by columbia.arpa; Thu, 16 Aug 84 03:51:50 edt Date: Thu 16 Aug 84 03:51:06-EDT From: Jeff Damens Subject: Re: Norm Samuelson To: SAMUELSON%LLL@LLL-MFE.ARPA Cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "SAMUELSON%LLL@LLL-MFE.ARPA" of Wed 15 Aug 84 23:31:30-EDT You could supply an explicit generation number of 0 for the source file (instead of the exec's default '*'). That would prevent the loop, but would only rename the highest generation of the file. Jeff ------- 16-Aug-84 09:13:34-PDT,694;000000000000 Mail-From: CRISPIN created at 16-Aug-84 09:13:27 Date: Thu 16 Aug 84 09:13:27-PDT From: Mark R. Crispin Subject: RH2CKU code in PHYH2 To: TOPS-20@SU-SCORE.ARPA Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 I don't know why that routine is commented out (other than perhaps being a bad idea), but it can't possibly work anyway because it does a MOVE Q1,(P) to get the device code. Unfortunately, the right half contains the CHNTAB index for that RH20 (a copy of P4), so the net effect is that the instruction executed would be CONO RHn,n for n=0 to 7. Only for RH#0 would this do the right thing. ------- 16-Aug-84 09:19:12-PDT,974;000000000000 Mail-From: CRISPIN created at 16-Aug-84 09:19:04 Date: Thu 16 Aug 84 09:19:04-PDT From: Mark R. Crispin Subject: RH2UNS routine in PHYH2 To: TOPS-20@SU-SCORE.ARPA Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 This routine is the only part of PHYH2/PHYH11 which is called externally without going through a vector. Specifically, the call is in the DIAG% JSYS. This is "alright" only if your channels are only RH20's or RH11's. RH11's only work because instead of doing the right thing PHYH11 is a hacked version of PHYH2 and mostly has PHYH2 symbols!!! I think a better idea is to write a CHNUNS routine in STG which dispatches based on the channel type and make DIAG% call that. That way you can have multiple channels, including RH's with other channels. I've done that, although to avoid modifying DIAG.MAC I have RH2UNS eqv'd to CHNUNS if RH20F!RH11F=0. ------- 16-Aug-84 11:34:56-PDT,669;000000000000 Mail-From: CRISPIN created at 16-Aug-84 11:34:15 Date: Thu 16 Aug 84 11:34:15-PDT From: Mark R. Crispin Subject: EPT locations 500-507 To: TOPS-20@SU-SCORE.ARPA Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 Does anybody know of any device (whether DEC or third-party) which uses or plans to use locations 500-507 in the EPT? These locations are marked as reserved for future hardware. I don't think there will be any new DEC CPU's which use those locations. This nice little 8-word block looks like a perfect place for a vectored interrupt vector for our channels. ------- 18-Aug-84 02:13:27-PDT,989;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 18 Aug 84 02:13:23-PDT Date: Sat 18 Aug 84 02:12:58-PDT From: Kirk Lougheed Subject: Sierra is dual homed To: nethax@SU-GREGORIO.ARPA cc: su-tops-20@SU-SCORE.ARPA Sierra is now dual homed on the CSD-CSL-Net (36.40.0.213) and on the CSL-10MB-Net (36.10.0.13). I seem to be able to speak IP with my neighbors on that subnet (STAR, Amador, CSL-Vax, etc.). Is there anyone else on that subnet (or anywhere else, for that matter) that claims to speak PUP protocols on the 10MB Ethernet? There appear to be two gateways between the CSD-CSL-Net and CSL-10MB-Net. I get stoney silence from both sides of the Durand-A-Gateway when I run PUPECHO. I take that to mean that that gateway has crashed. The ERL-Gateway responds to me only on the 3MB side; nothing comes back on the 10MB side. Question: do the SUN gateways speak ARP? Kirk ------- 20-Aug-84 10:34:23-PDT,1120;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 20 Aug 84 10:34:09-PDT Received: ID ; Mon 20 Aug 84 13:32:45-EDT Date: Mon 20 Aug 84 13:32:43-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Ephemeral blues... To: cc-monex@COLUMBIA-20.ARPA, tops-20@SU-SCORE.ARPA As someone mentioned some time ago, there are a number of bugs in the Exec stemming from mishandling of ephemerals... Well, here's a cure for one of them. At REPH2+4 there is a call to MAPPF while setting up ephemeral. Well, since MAPPF normally returns +2, the call to PIOFF immediately after it is usually not executed resulting in wierd things should a user ^C at the wrong point in the ephemeral setup. Since there isn't really anything useful to do if MAPPF fails, just add a TRN after the call. I discovered this while adding a hack to LOGIN which automatically runs a program during login under certain conditions. I couldn't figure out why INTDF was being cleared and the program being ^C'ed (due to the matching PION a little later in this code). --Vince ------- 20-Aug-84 14:40:55-PDT,2596;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Mon 20 Aug 84 14:40:41-PDT Date: Mon 20 Aug 84 16:42:06-CDT From: Clive Dawson Subject: Valuable lesson and some questions To: tops20@SU-SCORE.ARPA Every so often I learn a valuable lesson as a result of some minor or major disaster. Then a few years go by and I forget the lesson just before the next problem comes up when I need it again. The latest example of this has to do with bringing up your system after it was been powered down for an extended period of time. We had a scheduled power outage in our building last Sunday. We gracefully brought down the system ahead of time and powered off the machine. Eight hours later the power came back, so we turned the machine on and tried to boot the system. During the next hour we experienced at least half a dozen separate problems which prevented the system from coming up. These included flakey PDP-11 memory, problems with a DH11, Boot unable to find PS:, Boot finally finding PS: but not able to find MONITR.EXE, parity errors detected by the APR, etc. All of these problems eventually disappeared, but not before some disk channel problems succeeded in clobbering my directory quite badly. This in turn caused an infinite loop of FILBAT BUGINF's (the monitor getting more FILBAT's every time it tried to log the previous FILBAT!) After JFCLing the FILBAT I was able to bring the system up stand-alone, but still couldn't delete the damaged directory since it was mapped by the SYSERR fork. I finally got around this by patching the monitor so it would use instead of . Anyway, the lesson of this story (which I'm doomed to forget again) is that whenever your system has been powered off for an extended period time, do NOT attempt to boot immediately after restoring power. Give the system an hour or two to stabilize before trying to do anything. This is especially important if the room temperature or humidity underwent a big change during the period. Now for my question: after running CHECKD to make sure no other problems existed, I noticed that the number of disk pages assigned to is about 200,000 more than it should be. Is there an easy way to fix this? Do I have to rename all the files to some other directory, then kill and recreate ? I tried things like EXPUNGE,REBUILD which didn't work. As a last resort I'll map the directory and patch the word, I guess. Clive ------- 20-Aug-84 17:06:06-PDT,2147;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 20 Aug 84 17:05:55-PDT Date: Mon 20 Aug 84 17:05:45-PDT From: Kirk Lougheed Subject: Hung TCP connections To: tops-20@SU-SCORE.ARPA The following patch to TCPTCP.MAC relieves the problem of TCP connections being hung in an EST.NOT state. The key word is "relieve". The following code does not solve the original problem; it instead detects the hung TCB's and aborts them. I've run it for a couple of days on Sierra and it has aborted a number of hung connections without any adverse side effects. Kirk -------------- FUNCS: PUSH P,T1 ; Arg is pointer to dead queue head SKIPE INTSVR ; Scavenge free storage requested? CALL SCAVNG ; Yes. Do it to this TCB. CALL UPDATE ; Update Retransmission variables IFN STANSW,< CALL FIXHNG ; Flush TCB's hung in EST.NOT >;IFN STANSW POP P,T1 ; Get back arg for DEADP CALL DEADP ; Check for completely closed RET IFN STANSW,< ;FIXHNG - flush hung TCB's by aborting them. The better way of dealing with ; this problem is to not put TCB's into a hung state, but until such time as ; someone solves that problem, we'll use this after the fact method. ;TCB must satisify the following criteria: ; - owned by job zero, associated with a TVT, TVT line number is zero ; - RCV.SND state is EST.NOT ;Takes TCB/ pointer to locked TCB ;Returns +1 always NR STAFIX,1 ; *** TEMP *** Count of TCB's aborted by FIXHNG FIXHNG: JN TOWNR,(TCB),R ; Quit if TCB owner is other than job zero JE TTVT,(TCB),R ; Quit if TCB not associated with a TVT JN TVTL,(TCB),R ; Quit if TVT is still there LOAD T1,TSSYN,(TCB) ; Get Send state CAIE T1,NOTSYN ; NOT? RET ; Quit if send side still active LOAD T1,TRSYN,(TCB) ; Get Recv state CAIE T1,SYNCED ; EST? RET ; Quit if receive side is other than active AOS STAFIX ; *** TEMP *** Keep count of aborted TCB's MOVEI T1,EFP+^D7 ; T1/ error code is "Connection RESET" CALL ABTCON ; Flush buffers, set to NOT.NOT RET ; Return to caller >;IFN STANSW ------- 20-Aug-84 23:05:38-PDT,939;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Mon 20 Aug 84 23:05:30-PDT Date: Tue, 21 Aug 84 06:06 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: REL File sort program available To: tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 I spent the last week modifying a program written a few years ago by Neil Maron. It is called LIBORD. It creates a .MIC file which will put a group of .REL modules into a library in the proper order to allow loading in search mode in one pass. In case anyone is interested, the files needed are all in at SCORE. They are: LIBORD.FOR, LIBORD.COM, and LIBM.MAC. If you find any bugs please report them to me. - Sam - ------- 21-Aug-84 11:39:28-PDT,733;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Aug 84 11:39:12-PDT Date: Tue 21 Aug 84 11:38:41-PDT From: Bjorn Lindskog Subject: Changing forms on LPT To: tops-20@SU-SCORE.ARPA Does anyone know of a way for a NON-privileged user to halt a LPT stream, tell QUASAR that the forms have been changed and then restart that stream again? We need this since people want to switch from plain paper to labels once in a while on one of our printers and there is not always someone around with OPR privileges who can run OPR. Would it be possible to have a non-privileged program talking to QUASAR and doing what we need? Thanks, Bjorn ------- 21-Aug-84 12:41:29-PDT,1238;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Aug 84 12:41:17-PDT Date: Tue 21 Aug 84 13:43:31-MDT From: Randy Frank Subject: Re: Changing forms on LPT To: BJORN@WASHINGTON.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bjorn Lindskog " of Tue 21 Aug 84 13:28:05-MDT I actually looked into doing this once and decided that I wasn't going to do it in 10 minutes, so it never got done. The problem is that both OPR, ORION, and QUASAR all needed to be changed to allow a non-priv user to do what you want. It certainly is feasible, but will require hacking more than one component of galaxy. Another solution I thought of (but also never did...) was to have a priv program invoke OPR as a sub-fork feeding it input, and receiving requests (IPCF or the like) from user form change request programs. This has the advantage of not requiring changes to galaxy, as well as making it a lot easier to control what users can and cannot do (have the program act as a filter). My recollection is that allowing non-priv programs to ipcf directly to orion/quasar had the potential for opening up security holes. ------- 21-Aug-84 13:12:12-PDT,1449;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Aug 84 13:11:56-PDT Date: Tue, 21 Aug 84 19:53 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Norm Samuelson To: tops-20@SU-SCORE.ARPA Subject: Re: Changing forms on LPT To: BJORN@WASHINGTON.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bjorn Lindskog " of Tue 21 Aug 84 11:49:27-PDT Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 We have a stripped down version of OPR, which we call LPTCON, which has no way out (no exit, no push, and control-c trap) with all the commands which would change anything but the printer removed, which we fire up on a terminal next to each of our printers. It has been working for a few months. The job is CRJOB'd by a program run as the system is coming up. There is a small window, between the time we create the OPERATOR job and the time that LPTCON is started, but the program checks to be sure something named LPTCON is going on that terminal within a minute, if not it logs it out. It is not exactly what you asked for, but I dont think you could let non-privileged jobs send printer control commands to QUASAR/ORION without a great deal of checking to be sure they were not doing something wrong. - Sam - ------- 21-Aug-84 15:57:57-PDT,1732;000000000001 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 21 Aug 84 15:57:32-PDT Received: from CU20B.ARPA by columbia.arpa; Tue, 21 Aug 84 18:58:46 edt Date: Tue 21 Aug 84 18:57:38-EDT From: Thomas De Bellis Subject: Re: Changing forms on LPT To: FRANK@UTAH-20.ARPA Cc: BJORN@WASHINGTON.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Tue 21 Aug 84 15:47:40-EDT Hi Randy, I don't see what you are talking about, there is absolutely no need to touch OPR. The changes he wants are trivial, we've had them at Columbia for years. 1) Modify GLXMAC to define an extra priv bit. At MDB.PV: put something like MD.OPR (for OPR capability) after MD.PMT, the maintenance bit. This lets all Galaxy programs know about the bit. 2) In GLXIPC, at RCVM.2:, after it does the receive, after the TXO P3,MD.PMT, put in a TXNE S2,SC%whateveryourlocalcapabilitybitis, and a TXO P3,MD.OPR. The guy will have to worry about giving the local capability out. **Your GLXLIB now knows about your local capability** To allow the person to use OPR, you modify Orion. 3) At COMMAN:, replace the MOVX T1,MD.PHW!MD.POP with a MOVX T1,MD.PHW!MD.POP!MD.OPR, at CHKWHL+2:, do the same thing so the local capability is regarded as a form of Galaxy wheel. 4) You're done. You do *not* modify Quasar in any way. If you modify A$WHEEL in QSRADM (for 4.2 Galaxy), you risk letting them issue a create request and not having QSRT20 valid the owner field--bad security bug. Quasar will let them change the printer forms but not much else, just what he wants, I guess. -- Tom ------- 22-Aug-84 14:03:05-PDT,1213;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Aug 84 14:02:52-PDT Date: Wed 22 Aug 84 14:02:17-PDT From: Greg Satz Subject: MMAILR modifications for large mailing lists To: tops-20@SU-SCORE.ARPA Phone: (415) 497-1004 I modified MMAILR and MMAILBOX so that the sender field for mail sent to mailing lists is replaced with something more appropriate. These changes cause returned mail containing errors, etc. to be returned to some mailing list entity, if it exists, instead of the person sending the mail. When mail arrives, MMAILR looks at each recipient to see if there is a list expansion (via MMAILBOX). If the entity list-RELAY exists, MMAILR writes out a separate mail queue file with the sender field changed to be list-RELAY. This is done for each expanable recipient for which a -RELAY exists in the MAILING-LISTS.TXT file. Mailing lists without the -RELAY are handled in the old manner. The changes can be retrieved from host SRI-NIC, in the directory PS:. You want the files MMLBX.RED, and MMAILR.RED. They are fairly straight forward, but if you have any questions, feel free to ask. ------- 22-Aug-84 15:41:28-PDT,772;000000000000 Mail-From: CRISPIN created at 22-Aug-84 15:41:02 Date: Wed 22 Aug 84 15:41:02-PDT From: Mark R. Crispin Subject: Satz's MMailr modifications To: TOPS-20@SU-SCORE.ARPA Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 Please note that these are not supported modifications. I have sent Satz a specification of a much more general design which does not require the usage of -RELAY but instead allows a specification in MAILING-LISTS.TXT of the desired return address. He seems to feel that getting the code out is more important than future generality. Unless you absolutely need this feature, I recommend against installing it as the functionality will not be done in this way. ------- 22-Aug-84 17:33:14-PDT,751;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 22 Aug 84 17:33:04-PDT Date: Wed 22 Aug 84 17:34:02-PDT From: David Roode Subject: Re: Satz's MMailr modifications To: Crispin@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark R. Crispin " of Wed 22 Aug 84 15:52:40-PDT Location: EJ286 Phone: (415) 859-2774 It probably only matters on sites with large mailing lists involving many network hosts. Note that the usage of -RELAY still allows full specification of the destination of the messages sent to the address in the SMPT Return Path, because the -RELAY address is itself defined in the MAILING-LISTS.TXT file. ------- 23-Aug-84 09:30:33-PDT,824;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 23 Aug 84 09:30:18-PDT Date: Thu 23 Aug 84 09:29:44-PDT From: Greg Satz Subject: gdsts% on TCP: bug To: tops-20@SU-SCORE.ARPA Phone: (415) 497-1004 When a gdsts% is done on a jfn gotten from TCP:, the rcv.snd states are reversed. The documentation I have says AC2 should return receive,,send. TCPGTD: ;GDSTS Handling SAVEAT ;save most acs MOVE TCB,FILTCB(JFN) ;get the TCB address IFE STANSW,< LOAD T1,TRSYN,(TCB) ;get the receive state LOAD T2,TSSYN,(TCB) ;get the send state >;IFE STANSW IFN STANSW,< LOAD T1,TSSYN,(TCB) ;get the send state LOAD T2,TRSYN,(TCB) ;get the receive state >;IFN STANSW HRL T1,T2 ;receive in the left half, send in the right ------- 24-Aug-84 09:37:58-PDT,1408;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Fri 24 Aug 84 09:37:44-PDT Date: Fri 24 Aug 84 11:39:20-CDT From: Clive Dawson Subject: Reloading host tables To: tops20@SU-SCORE.ARPA I learned something interesting the other day which explains some sporadic lossage by the mail system. The other night I received a message from MMAILR telling me that a message could not be delivered because the host was non-existent. This was rather confusing since many messages were properly delivered to that host both immediately before and immediately after the problem message. Finally I realized that the delivery attempt had happened at the precise instant that I had been reloading the monitor's host tables with a new copy of HOST.TXT. There is no locking mechanism in the monitor to prevent a JSYS from referencing the host tables while they're being reloaded. As a result, there is a small window during which processes like MMAILR can fail. One interesting question is how such a locking mechanism should work. If reloading the host tables fails, they will be screwed up. Do you keep the lock on, release the lock, or crash?! Anyway, this doesn't happen often enough to be a critical problem, but at least it explains certain problems which used to be phase-of-the-moon. Cheers, Clive ------- 24-Aug-84 10:36:38-PDT,1179;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Fri 24 Aug 84 10:36:23-PDT Received: ID ; Fri 24 Aug 84 13:40:01-EDT Date: Fri, 24 Aug 1984 13:39 EDT Message-ID: From: "Leonard N. Zubkoff" To: Clive Dawson Cc: tops20@SU-SCORE.ARPA Subject: Reloading host tables In-reply-to: Msg of 24 Aug 1984 12:39-EDT from Clive Dawson Clive, I use the following batch job to install a new host table. Extension to other daemons that access the host table should be obvious. This doesn't address the locking problem, but it does prevent some lossage. @; Batch Job to Install a New Internet Host Table @ @ @enable @Setpri Enable ;This puts the job in queue 103 @speak @job 0/ @freeze SMTPSV @freeze FTSCTT @freeze MMAILR @/ @ @SDDT *1!.SfNhi *2!1 *SMONX * @speak @job 0/ @fork SMTPSV @continue,background @fork FTSCTT @continue,background @fork MMAILR @continue,background @/ @ %ERR: @MM send Zubkoff *Host Table Installation Failed. * @ %FIN:: 24-Aug-84 16:29:59-PDT,821;000000000000 Mail-From: MRC created at 24-Aug-84 16:29:51 Date: Fri 24 Aug 84 16:29:51-PDT From: Mark Crispin Subject: Re: Reloading host tables To: CC.Clive@UTEXAS-20.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Fri 24 Aug 84 09:38:01-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Clive is right. You should always pause MMailr before reloading the TOPS-20 HOSTS.TXT host table (whether by CALL HSTINI in MDDT, the INITIALIZE command in TELNET, or whatever your favorite command is). I usually advise the PTY MMailr is running on, CTRL/C it, then run MDDT (SYS:MDDT.EXE is ephemeral here), CALL HSTINI, then CTRL/Z out of MDDT and CONTINUE MMailr. ------- 24-Aug-84 18:50:42-PDT,643;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 24 Aug 84 18:50:28-PDT Date: Fri 24 Aug 84 17:07:50-PDT From: Andrew Sweer Subject: Reloading host tables To: Tops20@SU-SCORE.ARPA I've found that when MMAILR can't do its thing because the host tables are being updated, it leaves the message around as something like: [--BAD-QUEUED-MAIL--].NETWORK (or .RETRANSMIT) You can recover simply by renaming the file to: [--QUEUED-MAIL--].NETWORK (or .RETRANSMIT) Andy P.S. Don't forget to type a ^V before the left and right square brackets. ------- 25-Aug-84 08:24:48-PDT,1148;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Aug 84 08:24:40-PDT Date: Sat 25 Aug 84 09:25:57-MDT From: Randy Frank Subject: Auto-reloading after coming up stand-alone To: tops-20@SU-SCORE.ARPA For a while I thought I was imagining this, but now I think it's for real: It seems, at least on our system, that after bringing up the system stand-alone (DBUGSW=2) and then re-loading the system normally (DBUGSW=0) that if a KL crash then occurs that 20F doesn't reload the front-end, even though 20F claims that RELOAD ENABLE=ON. The only way around this seems to be to reload 20F after bringing up the system stand-alone. Has anyone else noticed this? It's clear that 20F knows the system is stand- alone, since it doesn't print %DECSYSTEM NOT RUNNING when the system is SHUT after being up stand-alone, so it doesn't surprise me if internal to 20F somewhere it's doing something different if KL was brought up stand-alone. Does this ring a bell to anyone else, and if so am I missing something, is this an actual bug, or whatever. Randy ------- 25-Aug-84 08:58:57-PDT,803;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Aug 84 08:58:48-PDT Date: Sat 25 Aug 84 12:00:27-EDT From: Kevin Paetzold Subject: Re: Auto-reloading after coming up stand-alone To: FRANK@UTAH-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Sat 25 Aug 84 11:30:48-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 What you see is the way it works. not clear if this is a bug or a feature. it is probably a feature because it is also tied to the %DECSYSTEM-20 NOT RUNNING messages. Although you may think that this is a bad feature most people in the monitor group will disagree (we spend a lot of time in EDDT).... ------- 25-Aug-84 09:15:19-PDT,726;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Aug 84 09:15:09-PDT Date: Sat 25 Aug 84 10:15:25-MDT From: Randy Frank Subject: Re: Auto-reloading after coming up stand-alone To: PAETZOLD@DEC-MARLBORO.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kevin Paetzold " of Sat 25 Aug 84 09:59:28-MDT it there any way to turn on auto-reloading without re-booting 20F? I don't mind it turning off reloading after bringing up the system stand-alone, but requiring you to re-boot 20F to reverse the action seems to be drastic, especially since I often re-load and debug the system from home over klinik. ------- 25-Aug-84 09:18:09-PDT,595;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Aug 84 09:18:00-PDT Date: Sat 25 Aug 84 12:19:05-EDT From: Kevin Paetzold Subject: Re: Auto-reloading after coming up stand-alone To: FRANK@UTAH-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Sat 25 Aug 84 12:16:48-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 right now there is no way to reverse this (that i know of). you could always reboot 20f from home... ------- 25-Aug-84 19:24:45-PDT,1346;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Aug 84 19:24:31-PDT Received: ID ; Sat 25 Aug 84 21:56:57-EDT Date: Sat 25 Aug 84 21:54:52-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Re: Auto-reloading after coming up stand-alone To: PAETZOLD@DEC-MARLBORO.ARPA cc: FRANK@UTAH-20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kevin Paetzold " of Sat 25 Aug 84 12:26:42-EDT Seems to me a simple fix to this would be to add an extra entry to DTJZCD in DTESRV as follows: DTJZC0::SKIPE DBUGSW ;Are we standalone? RET ;Nope. Don't mess with this unless normal SETOM FEDBST ;Make TOPS-20 believe that -11 thinks debug... DTJZCD: SKIPE T1,DBUGSW ;MONITOR IN DEBUG MODE? ... Assuming that RSX-20F knows how to accept .DFDBF messages (it already knows about .DFDBN messages), calling DTJZC0 somewhere during system startup would solve this problem. It should also be possible to fix this from MDDT (or EDDT) just by doing: DBUGSW/0 FEDBST/-1 CALL DTJZCD$X (or you can omit the call and wait for job 0 to figure it out itself). --Vince P.S. I recall this because for the longest time we couldn't use DTJZCD because we had to run a very old version of RSX-20F that didn't support it... ------- 25-Aug-84 19:28:18-PDT,1017;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Aug 84 19:28:05-PDT Date: Sat 25 Aug 84 20:27:02-MDT From: Randy Frank Subject: Re: Auto-reloading after coming up stand-alone To: Vince.Fuller@CMU-CS-C.ARPA, PAETZOLD@DEC-MARLBORO.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Sat 25 Aug 84 19:59:57-MDT Thanks for showing me how to clear it up. After looking at the code the Vince pointed out, it's clear to me that the current behavior is indeed a bug: the intent of the code in DTESRV is indeed for the front-end to follow the behavior of DBUGSW. It's just that if the monitor is halted with DBUGSW <> 0 and then re-started with DBUGSW = 0 the DBUGSW = 0 monitor never realizes that 20F thinks it's in debug mode and so it never takes it out of debug mode, as it would if DBUGSW was changed while the monitor was running. Kevin - do you agree now it's a bug?? Randy ------- 26-Aug-84 10:04:34-PDT,648;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sun 26 Aug 84 10:04:20-PDT Date: Sun 26 Aug 84 13:05:25-EDT From: Kevin Paetzold Subject: Re: Auto-reloading after coming up stand-alone To: FRANK@UTAH-20.ARPA cc: Vince.Fuller@CMU-CS-C.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Randy Frank " of Sat 25 Aug 84 22:29:40-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 if it is a bug it is an old bug. a lot of people know about how it currently behaves. not clear that it is worth changing. ------- 26-Aug-84 16:05:26-PDT,1223;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 26 Aug 84 16:03:35-PDT Date: Sun 26 Aug 84 16:03:32-PDT From: Kirk Lougheed Subject: Stanford FTP To: tops-20@SU-SCORE.ARPA A new version of the Stanford FTP program is now available. Among the additions and bugfixes are: - occasional screwups with paged mode receive have been fixed. - a QUOTE command has been added for sending commands directly to the foreign FTP server. - very long filenames and pathnames for TOPS-20 and UNIX have been fixed. - better filename defaulting for UNIX. - miscellaneous bugfixes for smoother use with UNIX (2.9 and 4.2 BSD) as well as TENEX, VAX/VMS, and ITS operating systems. Sources for a TCP only version of this FTP are in PS: on SU-SCORE. If you are interested in PUP protocol support, you should look in the primary source directory, PS: on SU-SIERRA. Note that you must be running the March 1984 version of TOPS-20 Release 5.3 (or better) to use this software, since it depends on a working TCP: device. Bug reports and feature requests should be sent to BUG-FTP@SU-SIERRA. ------- 26-Aug-84 16:37:03-PDT,2309;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 26 Aug 84 16:36:57-PDT Date: Sun 26 Aug 84 16:36:54-PDT From: Kirk Lougheed Subject: MEIS upgrades To: su-tops-20@SU-SCORE.ARPA cc: gfs@SU-AI.ARPA, g.eldre@SU-SCORE.ARPA Within the next couple of weeks George Schnurle and I will be visiting each DEC-20 site at Stanford to upgrade each MEIS device. The only site that will not need an upgrade is Sierra. Since we have two spare sets of MEIS boards, the upgrades should go quite quickly. We will take a system down, swap in the new boards, and then run the new diagnostic to make sure everything still works. The entire operation should take less that a half hour. We will then use LOTSC to test out the upgraded boards before they are swapped into the next system. The only sticky part of this operation is the software. During the development of the 10MB MEIS, we were forced to rework the MEIS status register in order to support two interfaces on one MEIS controller. The monitor that is currently running on Sierra knows about old and new register boards and will work correctly on all hardware. Old monitors, however, will **NOT** run correctly on new hardware. You must have a new monitor installed before the upgrade can happen. User sofware is unaffected. The new monitor software is in PS:<5-3-MONITOR> on Sierra. I consider it to be as stable as monitors around here can get. The changes are mostly to support 10MB Ethernet, ARP, multiple interfaces onto a Internet network, and extensions to PKOPR% for network monitoring. The Stanford specific modules now have REL6 conditional assembly switches that default to on; you should take a look at ASMSRA.CMD to see which modules need the file REL5.MAC prepended. The directory PS: contains the most recent diagnostic. It is less intelligent than the operating system in that it assumes the latest revision level of the MEIS device. I'll be coordinating the upgrades, so let me know when you want your system upgraded. I would like very much that these upgrade happen within the next couple of weeks so that George and I can go on to other things (such as PC versions of the 10MB MEIS). Kirk ------- 26-Aug-84 17:14:39-PDT,2115;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 26 Aug 84 17:14:33-PDT Date: Sun 26 Aug 84 17:14:31-PDT From: Kirk Lougheed Subject: More software To: su-tops-20@SU-SCORE.ARPA This message lists some software changes done at Sierra in recent weeks that people may find useful or should know about. The only critical change is with the FTP user program. In the directory PS:: - A new version of Stanford FTP with a number of bugfixes. The severity of the paged mode receive problem is such that I recommend that anyone who doesn't have this bugfix should install a new version of FTP.EXE as soon as possible. In the directory PS:: - PUPMSV now creates subforks with JP%SYS bit set. This prevents boot requests being serviced by a loaded -20 from timing out. - PUPTSV runs with JP%SYS set to prevent timeouts when trying to connect to a -20 from a tip. - PUPECHO. Code cleanup. Better error recovery. Can run indefinitely without crashing - old version would eventually get a PDL overflow. - PUPGSV resets monitor routing table on startup. This allows us to flush the current PUPROU table by rerunning PUPGSV. In the directory PS:: - SYSDPY has improved ME display for multiple interfaces. An ARP command has been added to show the Stanford ARP table. A new column, ANC-LHOST, has been added to the ANC command to show which local interfaces is being used. In the directory PS:: - FTPSER/FTPSRT from CMU has been trained to run under NETSRV. Vince Fuller has taken back the changes. Until such time as someone here writes a new FTP server, I suggest we use CMU's server since it is being maintained. In the directory PS:: - Ralph Gorin's DSKOP program has been trained to work on large filesystems such as in use at Score, CSLI, and Sierra. - The TAPLBL (TAPELABEL) program now knows about 6250 bpi drives and is re-entrant. A number of minor cleanups. ------- 27-Aug-84 09:32:15-PDT,792;000000000000 Mail-From: MRC created at 27-Aug-84 09:32:13 Date: Mon 27 Aug 84 09:32:13-PDT From: Mark Crispin Subject: FTP server To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The entire command structure of a new FTP server has already been written. All it needs is the data transfer stuff, which in my design would run in a subfork (so all the abort, etc. stuff in the FTP protocol would work). It also has any number of other fixes, such as a working CWD command, autologin as ANONYMOUS for unlogged-in RETR, and even support for the third-party file transfer stuff. So if somebody wants to write the FTP transfer fork, everything else exists. ------- 27-Aug-84 17:30:57-PDT,1038;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 27 Aug 84 17:30:52-PDT Date: Mon 27 Aug 84 17:30:38-PDT From: Greg Satz Subject: 6-EXEC bug with GTJFN and question mark To: su-tops-20@SU-SCORE.ARPA Phone: (415) 497-1004 Here is a log of when I try to type a question mark after a single letter to the EXEC. It seems that the GTJFN file parse code is outputing files from the current connected directory. I was connected to PS:<6-EXEC> at the time. Please note the [BELL] at the end of the last two tests. When a file wasn't found that matched, I was beeped. !m? Command, one of the following: MAP MERGE MODIFY MOUNT or kept fork name, MICPRM MKEXEC MKMEXC MKSUEX !a? Command, one of the following: ACCESS ADVISE APPEND ASSIGN ATTACH or kept fork name, [BELL] !b? Command, one of the following: BACKSPACE BBOARD BLANK BREAK BRUN BUILD or kept fork name, [BELL] ------- 27-Aug-84 22:19:06-PDT,1319;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 27 Aug 84 22:19:02-PDT Date: Mon 27 Aug 84 22:19:42-PDT From: Andrew Sweer Subject: Re: 6-EXEC bug with GTJFN and question mark To: SATZ@SU-SIERRA.ARPA cc: su-tops-20@SU-SCORE.ARPA The beep you "sometimes" get when you type a single letter followed by a ? to the EXEC is (are you ready for this?) not a bug, but a feature. I'm copying the rest of SU-TOPS-20 on this response in order to clear up a couple points in your original message. First, the beep is intended to amplify to the user that there are no files that match the given file specification. This is intended to be in the same vein as the beep you get when you give a ^F or ESC to complete a file specification that is ambiguous. The points I wanted to clear up are that it is a monitor feature, and as far as I can tell, works the same in the 5 series EXECs. Also, the files listed are those that match the first logical name in your SYS: definition. It appears you have DSK: as the first thing in your SYS: definition, so typing the file names of the .EXE files in your connected directory is, I believe, the appropriate thing to do. For some others, the matching files in NEW: may show up. Andy ------- 28-Aug-84 02:22:26-PDT,1158;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Aug 84 02:22:14-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2639985497650357@MIT-MULTICS.ARPA>; 28 Aug 1984 05:18:17 edt Date: 08 Aug 84 20:37 +0200 From: Conor_Cahill_of_Trinity_College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Conor_Cahill_of_Trinity_College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20@SU-SCORE.ARPA Subject: FLASH Message-ID: <65025@QZCOM> In the Software Dispatch (1-Aug-84) there is an unanswered SPR (# 20-20192) on the MONITOR in which there is a reference to a program entitled FLASH. This program is mentioned in the same context as KERMIT and both are described as "the poor man's network". As I have a KERMIT distribution which I am quite pleased with I would be doubly pleased to receive any information on FLASH, particularly ow to obtain a copy of it. 28-Aug-84 15:09:15-PDT,476;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Aug 84 15:09:09-PDT Date: Tue 28 Aug 84 15:08:56-PDT From: Kirk Lougheed Subject: TAR? To: su-tops-20@SU-SCORE.ARPA I thought I had the source to the TOPS-20 TAR program that was written at UC Irvine, but for the life of me I can't find a copy on Sierra. Does anyone else happen to know where the TAR source might be? Kirk ------- 29-Aug-84 17:02:41-PDT,752;000000000000 Mail-From: G.FUSSELL created at 29-Aug-84 17:02:29 Date: Wed 29 Aug 84 17:02:28-PDT From: Carl Fussell Subject: video display projection To: tops-20@SU-SCORE.ARPA Address: Santa Clara University At a LUG meeting once, a device was used to take the composite video from a terminal and display (project) it upon a normal slide projector screen. We have need of something like this now (classroom/seminar environment) and I was hoping that someone on the list might be familiar with this sort of equipment (or alternatives) and point me towards a vender. Any suggestions would be greatly appreciated since I am not even sure where to begin searching for this sort of equipment. Thanks... Carl ------- 30-Aug-84 18:39:56-PDT,587;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 30 Aug 84 18:39:44-PDT Date: Wed 29 Aug 84 21:52:47-MDT From: Randy Frank Subject: Re: video display projection To: G.FUSSELL@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Carl Fussell " of Wed 29 Aug 84 18:40:49-MDT two main vendors in this area are: Electrohome (low cost: $5K for B&W and $15K for color) General Electric - man'f "light valve" projector; very high quality, very big bucks (>$50K) ------- 30-Aug-84 19:41:41-PDT,878;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 30 Aug 84 19:41:32-PDT Date: 30 Aug 1984 00:20:40 PDT Subject: Re: video display projection From: Bob Knight To: Carl Fussell cc: tops-20@SU-SCORE.ARPA In-Reply-To: (Message from "Carl Fussell " of Wed 29 Aug 84 17:02:28-PDT) Hi - you want to talk to an Electrohome distributor. There's one in Redwood City that's probably closest. Monochrome (eg. green) is simple and relatively inexpensive. Color is about $17K with an RGB output. If you have an IBM=PC composite color output, then you need about $500 more. Give Jim Peterson at Symantec in Cupertino a call. He has both types of monitors in house, and would be happy to point you to the place to get them. Bob ------- 31-Aug-84 05:02:57-PDT,803;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Fri 31 Aug 84 05:02:47-PDT Date: Thu 30 Aug 84 10:05:50-EDT From: Donna Lynch Subject: Labelled tapes To: tops-20@SU-SCORE.ARPA cc: Admin@RADC-TOPS20.ARPA Can anyone give me an explanation for the following? This happened with the last 3 of 4 tapes I tried and on 2 different drives. Can it be the tapes? $opr OPR>set tape mta3: ini /lab:ansi /tape:hold /vol:28012 OPR> 9:29:26 -- MTA3: Volume 28012 Initialized -- Label type: ANSI Density: 1600 OPR> 9:29:26 -- INITIALIZE Completed -- MTA3: available for user tape requests 9:29:32 -- MTA3: Unlabeled tape mounted -- OPR> ------- 4-Sep-84 12:20:48-PDT,1020;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Sep 84 12:20:15-PDT Received: ID ; Tue 4 Sep 84 15:15:59-EDT Date: Tue 4 Sep 84 15:15:57-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Galaxy question To: tops-20@SU-SCORE.ARPA Does anyone know if there is a way for a Galaxy componenet (say, LPTSPL) to tell QUASAR that it is unavailable after it has been started? In particular, I need to be able to tell QUASAR that some device has gone down and thus to not send any more NEXTJOB's until I tell QUASAR that the device is up again (I also REQUEUE the current job, since more than one server may be able to take care of the request, so QUASAR should try elsewhere). Is this possible? The DEVICE-STATUS-UPDATE message does not seem to do what I want and a RESPONSE-TO-SETUP does the right thing, but only in response to a SETUP. I can't find any other message types which send device status information such as this. --Vince ------- 4-Sep-84 21:31:11-PDT,2374;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Sep 84 21:30:57-PDT Date: 5 Sep 84 00:31:19 EDT From: Rob Liebschutz Subject: Re: Galaxy question To: Vince.Fuller@CMU-CS-C.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of 4 Sep 84 15:15:57 EDT I have implemented something which I believe is almost exactly what you are looking for. I added another device status code to quasar, that is used to indicate that the printing device associated with the a LPTSPL is down. LPTSPL sends a device status message with this code to QUASAR and then requeues the job before releasing it. To clear the down status of the device, LPTSPL sends a %RESET device status code. During the period in which the device has a down status, Quasar does not spool any print jobs to it. Our Quasar is also setup to output a message about the device being down in an "INFO OUTPUT" or "OPR>SHO QUEUE PRINTER". An "OPR>show status printer" will also show the device as being down. If you kill the LPTSPL associated with the down device, the next time an object signs on to QUASAR and QUASAR scans all of the objects, it discovers that the LPTSPL is missing and clears the down status of the device. Here's roughly how to tell QUASAR that this device is down from LPTSPL: define your own flag which gets lit when the device is down, SETOM JOBCHK(S1) to request a device status update. $DSCHD(0) to force a scheduler pass This should cause the UPDTST routine to run. In UPDTST: you need to add something like: Skip if your down condition is false MOVX p1,%AS9DN ;where AS9DN is the name of our down device status code To tell QUASAR that the device is back up, you need to send a %reset device code in a similar way. I had to add a few instructions to the main idle loop at MAIN+2 which called UPDTST when the device came back up. The changes to QUASAR can be found on RUTGERS in S:<4-2-galaxy>*.dif or as edit [25] in the source files. The changes are as follows: QSRADM.MAC - The changes to the job queue manager. QSRMAC.MAC - symbols for new flag bits and device status codes QSRDSP.MAC - The code to display a down message in the EXEC's "INFO OUTPUT" command. Let me know if you have any further questions. Rob ------- 5-Sep-84 14:13:23-PDT,2961;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Wed 5 Sep 84 14:13:06-PDT Received: from CU20B.ARPA by columbia.arpa; Wed, 5 Sep 84 17:13:57 edt Date: Wed 5 Sep 84 17:11:44-EDT From: Thomas De Bellis Subject: Re: Galaxy question To: Vince.Fuller@CMU-CS-C.ARPA Cc: tops-20@SU-SCORE.ARPA, Pleasant@RUTGERS.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Tue 4 Sep 84 15:32:26-EDT Hi Vince, You are wrong about the response to setup. You can send it at *ANY* time. Your (CMU/CU) LPTSPL allready does this--I wrote the code a few (2?) years ago to do it. For DRP's, if I encounter a DECnet error, I close the file and send a response-to-setup while I am in stream context and then jump back to the main scheduler. Everything (other than DAP memory allocation problems), works fine. If you are not up to date, check our version 5 Galaxy sources on SNARK:<5.GALAXY.US>. Here is what happens: When Quasar tries to schedule a job, it goes chasing down a linked list of generic Galaxy objects looking for a non-interlocked one that meets the type requirements of the eligible job. If a generic object exists and is non-interlocked and is conditioned, the job is interlocked on that object and a NEXTJOB is sent to the processor locked on the object to actually do whatever ist is that the job wants done. If a processor is not locked on that object, then Quasar goes bopping down a linked list of non-allocated processors to find a specific processor than can handle the generic object's queue type. Thus, you can see how Quasar dynamically allocates LPTSPLs for requests. Quasar plugs the processor into the object by sending a SETUP and the object is considered conditioned. Sometimes a few sparks fly out and the processor can't use the requested device. A response-to-setup is set with the device is not-availible-right-now (or device is DEAD) bit set and Quasar requeues the job, breaks the job to object interlock and unplugs the (possibly dead) processor from the other side of the generic object. ...Five minutes pass... Quasar now tries to find another processor for the object since an eligible job for the object is still outstanding and the object block still exists (assuming an intervening SHUTDOWN was never issued). It is now that Galaxy processor's job to figure out if the device (TCP in your case, I suppose) is availible, temporarily unavailable or permanently unavailible. It responds to Quasar's new SETUP message with another respnse-to-setup message. If the object is temporarily unavailable, then previously mentioned song and dance indefinitely repeats. This is a form of polling: you don't tell Quasar that the device is ok, it just keeps asking every five minutes until it is. -- Tom Ps: Isn't it nice how simple they made all this? ------- 5-Sep-84 18:15:28-PDT,443;000000000000 Return-Path: Received: from purdue.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Sep 84 18:15:17-PDT Date: Wed, 5 Sep 84 20:16:41 est From: Robert J Graham Message-Id: <8409060116.AA16804@purdue.ARPA> Received: by purdue.ARPA; Wed, 5 Sep 84 20:16:41 est To: CC.Clive@UTEXAS-20.ARPA, arpanet-bboards@MIT-MC.ARPA, tops-20@SU-SCORE.ARPA Subject: Re: 20th Anniversary of 36 Bits q mail n q : 6-Sep-84 12:36:22-PDT,2393;000000000001 Mail-From: MRC created at 6-Sep-84 12:36:11 Date: Thu 6 Sep 84 12:36:11-PDT From: Mark Crispin Subject: fun with DVCHR% To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Background: for my development system I have a 2020 which is, essentially, a personal computer. It's impressive array peripherals consists of an RM03 and something that only charitably can be called a tape drive. It's a Western Perpherals TC-190 tape controller which the documentation claims is "fully compatible with the 2020" and "emulates a TM-11/TU-10 tape subsystem." On the other hand, if you didn't buy it you can't complain too much. Needless to say, I had to do something about support for this loser, otherwise I would have no way of backing up or transferring files. I was in a hurry, so I wrote this module called MTPSRV which implements an MTP: device. It's all JSYS-level code; no interrupt processing and only one scheduler test. While debugging it with DUMPER I discovered something absolutely charming and thought I'd share it with you. In the device characteristics word returned by DVCHR%, the right half is defined as containing "unit number for devices that have units, arbitrary code for structures, or -1 for nonstructure devices that do not have units." Well guess what. Some cretin improved it. Now, unit number is supposed to be only the low order 15 bits in the right half, and there is a new bit called DV%PSD (bit 18) which says the device is a "pseudo device". So far as I can see, the bit exists for only one purpose, and is used but once: to let DUMPER know that the magtape unit is an MT device instead of an MTA. Only MT's have DV%PSD set. DUMPER's test simply sees if DV%PSD is set and if so assumes that it is an MT. Guess what happens when DUMPER is given a magtape device which doesn't have units, especially when said device declines to accept MT-only MTOPR%'s. I find it extremely difficult to believe that the bit couldn't have been put someplace else, where it wouldn't be ambiguous. It's ridiculous for DUMPER to assume that anything which may be given to it as a device to do its output on will have units. It's bad enough that DUMPER insists it be a magtape. ------- 6-Sep-84 17:47:18-PDT,1550;000000000000 Mail-From: MRC created at 6-Sep-84 17:47:10 Date: Thu 6 Sep 84 17:47:10-PDT From: Mark Crispin Subject: crashing the system with MT's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It appears that if there are no MTA's when the system is booted and there isn't a MOUNTR or something to grab the MT's, one can trivially crash a TOPS-20 system by doing: ASSIGN MTn: then DEASSIGN MTn: where n is any number. This is because the MTAINI code initializes the "associated MTA drive" for the MT to MTA0 instead of "no tape" (a mask of all ones). MTAKIL is called on this non-existant MTA0, when then proceeds to call PHYKIL with a 0 argument instead of a block pointer. PHYKIL doesn't validate its arguments either, and so it treats the AC's as a block. It ends up stepping on P with predictable results. I imagine, although I have not tested, that if you don't have a MOUNTR to slurp up the MT's that you can trivially screw anybody who happens to be using MTA0 by frobbing an MT. Moral: run MOUNTR. Maybe MTAINI should be smarter and set the "associated MTA" to "none" instead of MTA0. I also suggest adding JE TPVV,,CLRVV0 at CLRVV+1 in TAPE (untested as yet, but should work). Instruct people writing monitor code on the wonderous improvements to reliability which can be accomplished if a routine would only take an instruction or two to validate its argument. ------- 7-Sep-84 23:11:09-PDT,538;000000000000 Mail-From: MRC created at 7-Sep-84 23:11:00 Date: Fri 7 Sep 84 23:11:00-PDT From: Mark Crispin Subject: wheel reinvention avoidance To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) If any of you have a 2020 with a Western Peripherals TC-190 tape controller, I have a TOPS-20 device driver for it. It's on [SU-SCORE] MTPSRV.MAC with a MTPSRV.DOC file which pretty much describes it. ------- 11-Sep-84 21:05:49-PDT,729;000000000000 Mail-From: MRC created at 11-Sep-84 21:05:41 Date: Tue 11 Sep 84 21:05:41-PDT From: Mark Crispin Subject: MAIL.TXT To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) What does the TOPS-20 community think about a change to the monitor to disallow generations of MAIL.TXT other than 1? It is almost always a user error to have such, and it may save some poor user from lost mail. MAIL.TXT is already a special file as far as the operating system is concerned (when CRDIR% creates a non-FILES-ONLY directory it makes a deleted permanent MAIL.TXT), so this would only extend it slightly. ------- 12-Sep-84 14:14:08-PDT,1811;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Sep 84 14:13:56-PDT Date: Wednesday, 12 September 1984, 13:13-PDT From: Ken Olum Subject: Enforcing MAIL.TXT version 1 To: TOPS-20 at SU-SCORE.ARPA In-reply-to: The message of 11 Sep 84 21:05-PDT from Mark Crispin I think this is a very bad idea. Instead, why not do the following: Flush from the explicit generation-number from all programs that refrence MAIL.TXT, so that the most recent version is used in all cases. This means that if the user edits her MAIL.TXT, creating version 2, then all programs will use version 2 and version 1 will be deleted if the generation-retention count says so, or if the user deletes it, and the FDB will be kept since the file is permanent. Then everything will happen normally using MAIL.TXT.2. If the user the deletes MAIL.TXT.2, either by hand or by deleting all the messages with MM, then the file will not be permanent, and will be expunged, and the next attempt to deliver mail will undelete and use MAIL.TXT.1 What do people this of this alternative? Is there really a good reason to have programs use the explicit version, except that if any program does this then all programs must do it to avoid trouble. While we're questioning assumptions, is creating the file on CRDIR% really a good idea. We now have all mail-delivery done by MMAILR, running enabled, so MMAILR could create the MAIL.TXT if it wasn't there already, and set it permanent, just as easily as it could undelete the deleted copy. I ask people to really think about the implications of these ideas, rather than just dimissing them as wrong-headed, merely because we have been doing it another way for so long. Ken 12-Sep-84 15:00:32-PDT,1319;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Sep 84 15:00:14-PDT Date: Wed 12 Sep 84 17:01:05-CDT From: Clive Dawson Subject: DECUS Alternative Migration Strategy session To: tops20@SU-SCORE.ARPA The Large S SIG will once again be scheduling the Alternative Migration Strategy session for Fall DECUS. The purpose of the session is to present different strategies available to customers faced with the extinction of the DEC-10/20. This has been a rather successful session during the past two DECUS symposia. I am in the process of organizing this session, and would like to hear from users and/or third-party vendors who would like to participate in the session. In the past most of the speakers have represented third-party vendors discussing hardware compatible with the 36-bit architecture. It would be nice if this time around we could add some customers to the list of speakers who have actually tried these or other strategies so that we may hear the results. Thanks, Clive P.S. It goes without saying that the most welcome speakers of all at this session would representatives from DEC, since this would imply that they had something to announce other than conversion to VAXen. ------- 12-Sep-84 16:48:14-PDT,1967;000000000000 Mail-From: MRC created at 12-Sep-84 16:47:58 Date: Wed 12 Sep 84 16:47:58-PDT From: Mark Crispin Subject: Re: Enforcing MAIL.TXT version 1 To: KDO@SRI-KL.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Olum " of Wed 12 Sep 84 14:14:10-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Ken - The problem is that MM and friends do not comprise all programs which deal with MAIL.TXT files. Right off the top I can think of: Babyl, Hermes, DEC IPCF MAIL, DECmail/MS, MSG, SNDMSG, MH, etc. All of these need to be changed. Charlotte Mooers and I can tell enough horror stories about the fun we had synchronizing MM and Hermes. The important thing is that it has to be in some way upwards-compatible with anything that DEC does, otherwise it can't be ported to many systems. The whole winning thing about MM is that it is completely portable to any TOPS-20 system. The other problem is that users constantly accidentally create higher versions of MAIL.TXT files, and then get upset when they lose some mail as a result. What does having multiple versions of a mail file mean? What happens when the higher-generation file is older than the lower generation file (e.g. copying one directory to another)? None of these questions can be answered simply. I can almost never think of a case where having multiple versions, or even writing a new version of a MAIL.TXT file is the right thing. Even the editor case may not necessarily mean that's what the user wanted; she may have merely wanted to find something in the file via the editor and it wrote out a "new" version. I think that the real problem is in the way mail is implemented in TOPS-20 as a whole. The question is: at this late point in the game do we really want to change it that much? -- Mark -- ------- 12-Sep-84 19:52:15-PDT,435;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Sep 84 19:52:07-PDT Date: Wed 12 Sep 84 21:53:11-CDT From: Clive Dawson Subject: Problem of the day To: tops20@SU-SCORE.ARPA Q: Can anybody find three "bugs" in version 380 of the host tables recently released by the NIC? Hint: The first two are [128.49.0.1] and [192.12.11.17]. ------- 12-Sep-84 21:30:40-PDT,2818;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Sep 84 21:30:30-PDT Date: Wednesday, 12 September 1984, 19:49-PDT From: Ken Olum Subject: Enforcing MAIL.TXT version 1 -- replies To: TOPS-20 at SU-SCORE.ARPA In-reply-to: The message of 12 Sep 84 14:54-PDT from SAMUELSON%LLL at LLL-MFE.ARPA, The message of 12 Sep 84 16:47-PDT from Mark Crispin [From Sam:] 1) if a user has MAIL.TXT.1 and MAIL.TXT.2 and they are BOTH deleted but NOT expunged, which one should be written to? Add to that the possibility that MAIL.TXT.2 has some messages (like most deleted files, but unlike the current way MAIL.TXT.1 is handled), and you can see what kinds of questions you get into about just what is right. This is a problem. However it's a problem right now, since in the current monitor when you delete MAIL.TXT.1 it does NOT get immediately expunged. Thus when new mail comes in, and the user has a deleted mail-file you have to decide whether to flush the old messages or undelete them. The version of MMAILR we are running undeletes the file with the old messages in it, the old IPCF-mailer used to flush the old contents. Since no one has every complained about this I doubt that it's a serious problem. 2) MMAILR should NOT create MAIL.TXT, since that is the only way MMAILR can tell if someone doesnt want mail delivered here, but might want it forwarded. Yeah, but that's not a feature. A lot of sites have changed MMAILR to check the mailing list before looking for the MAIL.TXT file. This is a win since it enables you to have old mail in MAIL.TXT but new mail forwarded, and because it allows things like KDO= *MAIL.TXT FOO to send a copy of all my mail to address FOO, but sill allow me normal mailreading facility. [From Mark:] The problem is that MM and friends do not comprise all programs which deal with MAIL.TXT files. Right off the top I can think of: Babyl, Hermes, DEC IPCF MAIL, DECmail/MS, MSG, SNDMSG, MH, etc. All of these need to be changed. Charlotte Mooers and I can tell enough horror stories about the fun we had synchronizing MM and Hermes. This is a the real problem. However I think it is probably not too late to make the change for the following reason. If MM and MMAILR are changed to use MAIL.TXT.0 and other programs continue with .1, then the only losing case is when the user has two MAIL.TXT versions. If he only has a .1 then everybody will use it and nobody will create a new one. If he has two version then he ALREADY tends to lose, as we have been discussing. The change would be upward-compatible in this sense, and MM would still be portable. Ken 13-Sep-84 01:09:45-PDT,943;000000000000 Mail-From: ALMQUIST created at 13-Sep-84 01:09:43 Date: Thu 13 Sep 84 01:09:43-PDT From: Philip Almquist Subject: Domains.Txt update To: su-tops-20@SU-SCORE.ARPA I recently tried sending mail to Tartan and lost badly. It seems that there is and entry for Tartan in Domains.Txt which overrides the entry in the NIC host table. Because of the entry in Domains.Txt, the mail was sent to CMU-CS-C, where it was promptly dropped on the floor since CMU-CS-C refuses to gateway mail. I fixed the problem on Score by removing all references to "Tartan" and "TLnet" from Domains.Txt. I didn't fix it anywhere else. So I will know in the future: is there a master copy of Domains.Txt somewhere which is the "right" place to fix things like this? Should this message have gone to the full Tops-20 list (ie, does this error exist on every 20 in the country that runs MRC mail)? Philip ------- 13-Sep-84 06:01:30-PDT,676;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Sep 84 06:01:15-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641366212336824@MIT-MULTICS.ARPA>; 13 Sep 1984 04:50:12 edt Date: 12 Sep 84 22:38 +0200 From: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bjorn_Danielsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20@SU-SCORE.ARPA Subject: MAIL.TXT Message-ID: <69528@QZCOM> In-Reply-To: <69494@QZCOM> Sounds reasonable. Maybe creation of *.DIRECTORY should be disallowed as well, except when done by CRDIR%. 13-Sep-84 08:27:53-PDT,640;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Sep 84 08:27:46-PDT Date: Thu 13 Sep 84 08:27:12-PDT From: Greg Satz Subject: Re: Domains.Txt update To: ALMQUIST@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Philip Almquist " of Thu 13 Sep 84 01:11:00-PDT Phone: (415) 497-1004 If there is a master copy around, I don't know about it. I fixed up our domains.txt file so user%host.dec@decwrl and user%host.bitnet@berkeley work. This is useful enough that more people might want to know about it. ------- 13-Sep-84 08:45:38-PDT,1299;000000000000 Mail-From: MRC created at 13-Sep-84 08:45:28 Date: Thu 13 Sep 84 08:45:28-PDT From: Mark Crispin Subject: Re: Domains.Txt update To: ALMQUIST@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Philip Almquist " of Thu 13 Sep 84 01:09:46-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Philip - I don't know what site you tried to mail to Tartan from but I'll bet it was not from Score. This is because the modern version of the mailsystem always uses the network naming registries before DOMAINS.TXT. DOMAINS.TXT was intended as a "last resort" database but at some point in its history it was made a "check first" database to allow redirection of mail against the advice of the network naming registries. Due to the kind of problem you observed the original functionality was restored some time ago. My intention is that if redirection is really necessary something like the old XMAILR-ROUTING-HOOKS.TXT functionality should be reimplemented. Anyway, the official version of DOMAINS.TXT is on MRC: and I have updated it with your changes. Clearly the TLnet crock should vanish now. -- Mark -- ------- 13-Sep-84 09:38:03-PDT,894;000000000000 Mail-From: MRC created at 13-Sep-84 09:37:28 Date: Thu 13 Sep 84 09:37:28-PDT From: Mark Crispin Subject: Re: Enforcing MAIL.TXT version 1 -- replies To: KDO@SRI-KL.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Olum " of Wed 12 Sep 84 21:30:42-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The reason MMailr undeletes the MAIL.TXT file instead of flushing it is because the GJ%FOU feature of magic undeletion doesn't quite work right in DEC-supplied TOPS-20. The bug is fixed at Stanford but that doesn't help portability. The "change to MMailr to check the mailing list before looking for the MAIL.TXT file" is not a change to MMailr. That is the behavior of the distributed MMailr, and has been since it was XMailr. ------- 14-Sep-84 09:28:47-PDT,2282;000000000001 Mail-From: MRC created at 14-Sep-84 09:28:35 Date: Fri 14 Sep 84 09:28:35-PDT From: Mark Crispin Subject: A Tale of Tapes To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As I mentioned in an earlier message, I recently had the opportunity to write a simple-minded device driver for a TC-190 tape controller (I use the term charitably, even by DEC standards) on a 2020. Basically, the 2020 and TC-190 are on loan to us and I'm using it for software development (hey, it's better than TOPS-10!); this stuff will NOT be on Mars. While doing this, I spent some time understanding how tapes in general work on TOPS-20, and DUMPER in particular. I've found some answers to problems which have plagued us for ages. One common complain made to Field Service is that certain tape drives (the TU78 comes immediately to mind) fail to sense EOT and the tape runs off the reel. There has been some note made that it happens with larger DUMPER blocking-factors, but that was dismissed merely as how the "hardware bug" was provoked. I have since discovered that this is NOT true. I am encountering this same problem with a blocking-factor of 8 on a 1600 BPI dump. After the third or fourth time this happened to me, I decided to take a closer look at the problem. I discovered that the TC-190 was sensing EOT at the right time and my device driver was catching it and dutifully reporting it back to DUMPER. There was a bug in my code in that it was not treating MT%EOT as an error condition which should set ERRF in the device driver. This didn't matter too much, though, because MT%DAE was set at about the same time and I was setting ERRF for that. What was NOT happening was DUMPER rewinding the tape in time. It turns out that DUMPER wants to rewrite bad records and write a trailer record. That may be enough to pop it off the reel if you are using a large enough blocksize. The workaround for now is to use smaller records. DUMPER really ought to be fixed to not write beyond EOT, even if it means backspacing a few records and restarting the reel from there. ------- 14-Sep-84 12:33:05-PDT,663;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Sep 84 12:32:47-PDT Date: 14 Sep 1984 1531-EDT From: Allan Titcomb To: TOPS-20 at SU-SCORE DTN: 231-4849 LOC: MR2-2/8D2 Subject: TOPS-20, TCP, and Ethernet Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12047564982.28.270.13558 at DEC-MARLBORO> It would be most helpful to me if those who know would advise whether or not their systems run TOPS-20 (with TCP directly or indirectly from us) and what their plans are with respect to running TCP on an ethernet. I look forward to hearing from you. Allan -------- 14-Sep-84 15:11:28-PDT,1898;000000000001 Mail-From: MRC created at 14-Sep-84 15:10:39 Date: Fri 14 Sep 84 15:10:38-PDT From: Mark Crispin Subject: The Tapes Strike Back To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have uncovered more information about the problem of tapes running off the end of the reel. The following ought to bring joy and merriment to all and sundry. When DUMPER in MTOUT2 finds that an I/O error has occurred in writing a record, it reacts by calling the WFERR routine. WFERR analyzes the error and if a real error (e.g. data error) occurs it jumps to WFTRY to write a new copy of the record. If WFTRY fails it jumps back to WFERR, so basically it is in a loop until such time as the error drops. Of course, end of tape is not really a write error, so it just sets the end of tape flag and returns. Now, MTOUT2 checks the overlap bit, and seeing that it is lit, loops back to write the record over again. It does this because since with overlap mode the EOT was sensed on the previous record, and an error prevents the new record from being written. Add the TC-190. It has the IBM tape feature that once EOT is lit in the hardware it stays lit. It doesn't go off until a rewind happens or a backspace past the EOT marker. MTOUT2 assumes that the DUMPO% on its loopback can't possibly fail, since the error status was cleared by WFTRY and nothing has been done to the hardware since. However, if you really have a sticky EOT flag, then this loop will continue to write the same record over and over again until the tape runs off the end of the reel. Since my device driver didn't support overlap mode anyway, it was easiest for me to patch NWTBT0 to 0 so that it never tried to do the overlap retry. ------- 14-Sep-84 15:23:42-PDT,2395;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Sep 84 15:23:17-PDT Date: 14 Sep 1984 1813-EDT From: Thomas Blinn To: MRC at SU-SCORE, TOPS-20 at SU-SCORE Reply-to: Blinn at DEC-MARLBORO Home: "3209 Windsor Ridge Drive, Westboro MA 01581" Office: "One Iron Way, MRO2-2/8D2, Marlboro MA 01752" Telephone: "(617) 467-5562, DTN 231-5562, home (617) 366-0308" Subject: Re: A Tale of Tapes Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12047594592.22.275.79279 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 14-Sep-84 1238-EDT Yes, I identified that same problem over 3 years ago when I was a customer working with TU77s for the first time. I had a ZORK.SAVE file that simply couldn't be saved at a blocking factor of 8 (there may (MUST??) have been a problem with the TU77s as well), and had the tape run off the end of the reel many times. There is not much of a problem if DUMPER recovers in a reasonable number of tries. At the supported blocking factors, it can retry up to about 100 times with the usual amount of tape that follows the EOT marker without running the tape off the reel. Unfortunately, there seem to be some failure modes in which DUMPER can NEVER recover. In those, it's bye-bye tape. I worked out a patch to have DUMPER notice it was at the end of the reel and count its retry attempts (since it will normally retry the same record an unlimited number of times -- if you can't write it after, say, 100 attempts, something must be seriously wrong, but DUMPER doesn't care, just goes merrily on its way...), and after 25 attempts, stop and ask the operator if it should keep trying. A YES would result in up to 25 more attempts, and a NO would abort DUMPER (what can you do, really, that is any better??). I SPRed the problem, and the response was that it could not be reproduced. I believe I resubmitted the SPR, pointing out that mere inspection of the code would reveal that DUMPER would never stop writing inside the error recovery loop, even if EOT was sensed. As I recall, I never got a response to the second SPR. At that point, I simply kept my mods in my DUMPER, and was not bothered by it again. Pleased to hear someone else has found and fixed the same problem. Regards Tom -------- 14-Sep-84 19:27:21-PDT,1306;000000000001 Mail-From: MRC created at 14-Sep-84 19:27:13 Date: Fri 14 Sep 84 19:27:13-PDT From: Mark Crispin Subject: /FULL-INCREMENTAL switch in DUMPER To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I wonder if anybody else has been bit by believing the help file for DUMPER on the /FULL-INCREMENTAL switch. I was setting up a backup system, and wanted to have a weekly full dump with 5 daily incrementals. The idea was that the full dump would be done on Friday evening and I would use the /INCREMENTAL:5 switch in DUMPER. That would guarantee that in the event of a filesystem refresh all I would need to do would be to use the full dump and the last incremental. I trusted the help file on the /FULL-INCREMENTAL switch, which only said that it dumped everything and marked the file as dumped (as opposed to an ordinary dump, which doesn't mark the file as dumped). I assumed this meant that it would dump all files and bump their dump counts. It doesn't. It resets the dump count to 1! That means that if you do a /INCREMENTAL with an argument greater than 1 it will do another full dump! What a useless option. -- Mark -- ------- 14-Sep-84 20:35:40-PDT,1411;000000000001 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Sep 84 20:35:28-PDT Received: ID ; Fri 14 Sep 84 23:37:34-EDT Date: Fri, 14 Sep 1984 23:37 EDT Message-ID: From: "Leonard N. Zubkoff" To: Mark Crispin Cc: TOPS-20@SU-SCORE.ARPA Subject: /FULL-INCREMENTAL switch in DUMPER In-reply-to: Msg of 14 Sep 1984 22:27-EDT from Mark Crispin Mark, CMU added a /Cumulative-Incremental switch to DUMPER which causes all files written since the last /Full-Incremental to be saved. I got so disgusted with the poor performance of DUMPER in doing /Cumulative-Incrementals on our 2-pack RP07 structures (with whole directories full of migrated files), that I implemented a "file has been written or renamed into this directory" bit in the directory. Openf% for write and Rnamf% set this bit. The /Cumulative -Incremental is then done by setting Gn%Cum to Gnjfn%. This causes Gnjfn% to only return files that DUMPER will dump. Finally, Gn%Ful is used during the /Full-Incremental to clear the bit. Yeah, it's a somewhat ugly hack. But our daily incremental dumps went from taking three hours of real time and loading the disk channel down greatly to about an hour of real time and a much less perceptible disk load. 15-Sep-84 01:13:47-PDT,688;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Sat 15 Sep 84 01:13:38-PDT Date: Fri 14 Sep 84 17:08:25-PDT From: Ken Olum Subject: Re: TOPS-20, TCP, and Ethernet To: TITCOMB at DEC-MARLBORO, TOPS-20 at SU-SCORE In-Reply-To: Your message of Fri 14 Sep 84 12:31:00-PDT Fairchild A.I. Lab runs TCP over Ethernet via a DTE and an -11 running MINITS. It works like a charm (well, as well as any TCP implementation that doesn't get used very often). (We also run CHAOSNet using the same -11 and Ether cable if anyone is interested.) The TCP implementation is a variant of Stanford's variant of DEC's. Ken ------- 17-Sep-84 06:57:55-PDT,648;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Sep 84 06:57:46-PDT Received: ID ; Mon 17 Sep 84 09:27:38-EDT Date: Mon 17 Sep 84 08:30:34-EDT From: Marc Shapiro Subject: reading "tar" taes To: mrc@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA, bug-xx@MIT-XX.ARPA I need to read Unix "tar" tapes on a Tops-20 computer. Can someone help me locate a program to do this (I know one exists) ? I need either Arpanet-accessible source code, or a binary tape. I can't transfer binaries accross the net. Thanks for any pointers. ------- 17-Sep-84 09:20:16-PDT,1086;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Sep 84 09:20:06-PDT Received: ID ; Mon 17 Sep 84 12:19:28-EDT Date: Mon 17 Sep 84 12:19:23-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Bliss-36 query To: tops-20@SU-SCORE.ARPA I have need for a wizzy pair of macros which will make MACSYM (and Galaxy) masks usable by Bliss programs. In particular, I'd like macros MSKB and MSKL which work such that: MSKB(FOO) returns the LSB of the mask, in Bliss bit numbering and MSKL(FOO) returns the number of bits in the mask thus one could say: VALUE to extract the .FBBSZ value of data returned by GTFDB% (assuming that $FBBSZ is equated to .FBBSZ) This seems like such a generally useful thing to have that I would think that someone must have written it by now... My limited knowledge of Bliss macros indicates to me that this would be rather difficult to do, so I'd like to find out if it has been done before attempting to do it myself. --Vince ------- 17-Sep-84 13:16:33-PDT,867;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Sep 84 13:16:22-PDT Date: 17 Sep 1984 1434-EDT From: Alan H. Martin To: TOPS-20 at SCORE DTN: 231-4528 Mail-Stop: MR1-2/L14 Office-location: "MR1-2/M8 (By the cat posters)" Subject: Re: Bliss-36 query Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12048341173.36.659.29669 at DEC-MARLBORO> Regarding: Message from Vince.Fuller@CMU-CS-C.ARPA of 17-Sep-84 1230-EDT I've seen some macros for playing with masks someplace, but you can do better than macros for what you seem to need. Use the MONWORD and MONBLOCK structures defined in TENDEF.R36 starting with Bliss V3.0: LOCAL VALUE : MONWORD; . . . .VALUE[$FBBSZ] . . . I assume you are using Bliss-36 and not Bliss-10. /AHM -------- 18-Sep-84 08:51:46-PDT,861;000000000000 Mail-From: MRC created at 18-Sep-84 08:51:35 Date: Tue 18 Sep 84 08:51:35-PDT From: Mark Crispin Subject: Re: DECUS Alternative Migration Strategy session To: CC.Clive@UTEXAS-20.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Wed 12 Sep 84 15:00:37-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Clive - Systems Concepts will have a booth at DEXPO, #4121, and we will have an SC-30M (a.k.a. Mars I) running TOPS-10/20 there. I don't know whether or not we'll be speaking at the Alternative Migration Strategy yet due to the obvious problems. But everybody is invited to stop by our booth. I hope this isn't too "commercial" a message for the TOPS-20 list! -- Mark -- ------- 19-Sep-84 03:34:34-PDT,545;000000000000 Return-Path: Received: from ornl-msr.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Sep 84 03:34:25-PDT Received: by ornl-msr.ARPA (4.12/4.7) id AA22763; Wed, 19 Sep 84 06:38:03 edt Date: Wed, 19 Sep 84 06:38:03 edt From: dunigan@ornl-msr (Tom Dunigan) Message-Id: <8409191038.AA22763@ornl-msr.ARPA> To: tops-20@su-score Subject: TOPS20 file daemon We are about to undertake implementing a TOPS-10-like file daemon facility for TOPS-20. Has anyone already done same? replies to: dunigan@ornl-msr thanks tom dunigan 19-Sep-84 07:55:59-PDT,775;000000000000 Return-Path: Received: from CMU-CS-A.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Sep 84 07:55:45-PDT Date: 19 Sep 84 1046 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: dunigan@ORNL-MSR.ARPA (Tom Dunigan) Subject: Re: TOPS20 file daemon CC: tops-20@SU-SCORE.ARPA In-Reply-To: <8409191038.AA22763@ornl-msr.ARPA> Message-Id: <19Sep84.104630.EN0C@CMU-CS-A.ARPA> What advantage do you see in making a TOPS-10 like file daemon for TOPS-20? You can do all those FILOP. functions including the checkpoint function via simple JSYS like UFPGS and so forth. If you are actually extending PA1050 so that you can run 6.02+ version TOPS-10 programs under TOPS-20..I don't see a problem other then getting a hold of the PA1050 sources. Good luck, -Rudy 19-Sep-84 08:27:21-PDT,1338;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Sep 84 08:27:08-PDT Date: Wed, 19 Sep 84 15:27 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: TOPS20 file daemon To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: Rudy.Nedved@CMU-CS-A.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A.ARPA" of Wed 19 Sep 84 10:46:00-PDT Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 Rudy, You are obviously mixed up as to what the File Daemon on TOPS-10 really is. The FILOP. functions to do checkpoints, etc, are really not related to the File Daemon. The file daemon essentially adds Access Control Lists to the file protection mechanism, including optional logging of file accesses. On a file-by-file (with wildcards) basis, a user can specify WHO can do WHAT with each file. I used the File Daemon on TOPS-10 years ago, and found it quite useful. It is more flexible than the multi-group structure of TOPS-20's protection scheme, but it is also more complex and has more overhead (but only in those cases where it is invoked, ie: it does not cause extra overhead on every file access). - Sam - ------- 19-Sep-84 09:00:12-PDT,550;000000000000 Return-Path: Received: from CMU-CS-A.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Sep 84 08:59:42-PDT Date: 19 Sep 84 1145 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: TOPS20 file daemon CC: TOPS-20@SU-SCORE.ARPA In-Reply-To: "SAMUELSON%LLL@LLL-MFE.ARPA's message of 19 Sep 84 10:27-EST" Message-Id: <19Sep84.114501.EN0C@CMU-CS-A.ARPA> Oh yea. The access stuff. Well...I would modify the ACJ stuff to get that kind of support...CMU does have access list for various functions. -Rudy 20-Sep-84 10:40:51-PDT,1131;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Sep 84 10:40:33-PDT Date: Thu 20 Sep 84 10:40:23-PDT From: Greg Satz Subject: Receiving broadcast packets To: tops-20@SU-SCORE.ARPA Phone: (415) 497-1004 Here is the change I had to make to get IP to accept broadcast packets. This assumes that your driver puts broadcast packets in the packet queue. IPIPIP.MAC: LOAD T1,PIDH,(PKT) ; Get 32-bit internet destination IFE STANSW,< SKIPN SRP+IPOPA ; Must forward if it has a route option >;IFE STANSW IFN STANSW,< SKIPE SRP+IPOPA ; Must forward if it has a route option JRST RCVGA6 ; No, packet to be forwarded DEFSTR HSTBYT,,35,8 ; Fourth byte in IP address LOAD T2,HSTBYT,T1 ; Get fourth byte of address CAIN T2,377 ; Is it broadcast address? JRST RCVGA7 ; Then we want it, but don't forward it! >;IFN STANSW CALL LCLHST ; Is it one of us? JRST RCVGA6 ; No, packet to be forwarded JRST RCVGA7 ; Yes, deliver a packet to host ; Option problem RCVGA4: HRRZ T1,T2 ; Error code or pointer? ------- 21-Sep-84 10:08:06-PDT,580;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 21 Sep 84 10:07:49-PDT Date: 21 Sep 84 13:11:05 EDT From: Roy Subject: TCP subnegotiations To: tops-20@SU-SCORE.ARPA We would like to implement the Telnet terminal type, output width, and output length options. As far as I can see, the code in TTANDV and TTNTDV is not set up to handle any options that require subnegotiations. Does anyone happen to have code for handling subnegotiations, either the ones we are interested in or others? ------- 21-Sep-84 10:43:45-PDT,740;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 21 Sep 84 10:42:13-PDT Date: 21 Sep 84 13:45:15 EDT From: Roy Subject: udp for Tops-20? To: tops-20@SU-SCORE.ARPA Has anyone implemented UDP for Tops-20? We are starting to use TCP as our primary local protocol. Our experience with PUP suggests that we are going to need a number of miscellaneous services, e.g. asking who is on a given socket, verifying privileges, etc. These seem easiest to do with a simple miscellaneous server that sends single response packets as replies to single request. TCP designs are also possible, but typically require spawning a process to handle each request. ------- 21-Sep-84 11:29:30-PDT,920;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 21 Sep 84 11:28:52-PDT Received: ID ; Fri 21 Sep 84 14:31:27-EDT Date: Fri 21 Sep 84 14:30:23-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Re: udp for Tops-20? To: MARANTZ@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Roy " of Fri 21 Sep 84 13:45:15-EDT I have implemented a cheap UDP by creating a user level library that uses the Internet User Queue facility. You are welcome to it, if you want. I have been considering implenting a real UDP device for TOPS-20 and even started to do the preliminary work on it before getting side-tracked. My thought was to follow the PUP code: implement GTJFN%, OPENF%, UDPI%, UDPO%, GDSTS% and maybe some MTOPR's for interrupt handling, etc. Doing this didn't appear to be too difficult. --Vince ------- 23-Sep-84 17:44:55-PDT,1133;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sun 23 Sep 84 17:44:44-PDT Date: 23 Sep 84 20:48:06 EDT From: Charles Hedrick Subject: network addresses for Rutgers systems To: tops-20@SU-SCORE.ARPA In case anyone is interested: Our networking arrangements are currently in transition. The network addresses advertised for RU-BLUE and RU-GREEN are in fact fakes. They connect to RUTGERS, our Arpanet host. Because of hacks in MAISER, they can be used for mail to RU-BLUE and RU-GREEN. However attempts to use them for Telnet or FTP will get you RUTGERS. The correct network addresses are ru-green: 128.6.0.3 ru-blue: 128.6.0.4 Within a week or so, we will ask NIC to change the official host tables to point to these addresses. Until we have set up proper access control, they will be used only intermittently, for testing. It is likely that during the interim the 128.6 address for ru-blue will work but ru-green will not. We will continue to accept mail to the old addresses for a fairly long time after the changeover. ------- 24-Sep-84 07:03:04-PDT,912;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Sep 84 07:02:55-PDT Received: ID ; Mon 24 Sep 84 10:04:01-EDT Date: Mon 24 Sep 84 10:03:55-EDT From: Vince Fuller Subject: Re: TOPS-20, TCP, and Ethernet To: TITCOMB@DEC-MARLBORO.ARPA cc: TOPS-20@SU-SCORE.ARPA, Gripe@CMU-CS-C.ARPA In-Reply-To: Message from "Allan Titcomb " of Fri 14 Sep 84 15:31:00-EDT CMU is using custom routing software in a PDP-11 connected to the 20 over a DTE link. This software supports Ethernet (both 3MB and 10MB), proNET, and a number of other networking technologies. It is sufficiently general that it can be extended to use other interfaces by the addition of device drivers. We use the same software for connecting the different cables of our network together using ARP to locate hosts. ------- 24-Sep-84 21:13:14-PDT,515;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Sep 84 21:12:57-PDT Date: 24 Sep 1984 22:16 MDT (Mon) Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE cc: WANCHO@SIMTEL20 Subject: HOSTS.TXT.385 NOTE: The just announced HOSTS.TXT.385 no longer has .ARPA as part of the official host names. Installing this version will most likely break your MMAILR into tiny little pieces... --Frank 24-Sep-84 21:43:49-PDT,480;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Sep 84 21:43:35-PDT Date: 24 Sep 1984 22:46 MDT (Mon) Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE cc: WANCHO@SIMTEL20 Subject: Correction Actually, it will not break your MMAILR. It will cause MAISER to refuse mail from hosts which identify themselves with the .ARPA official host name. --Frank 25-Sep-84 13:51:31-PDT,745;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 25 Sep 84 13:51:12-PDT Date: Tue 25 Sep 84 14:55:32-MDT From: Randy Frank Subject: TTY parity control question To: tops-20@SU-SCORE.ARPA I'm trying to interface a new HP laserjet printer to the 20, and have come against something where either I'm missing something or there is no solution. This device inherent is an 8 bit device; sending it parity screws it up royally. However, I don't want to be in binary mode since I still want CCOC translation, tab expansion, etc. Am I out of luck, or can I get an 8-bit (with no parity) mode but still get normal 7 bit features such as CCOC and tab expansion. ------- 25-Sep-84 15:26:20-PDT,463;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 25 Sep 84 15:26:06-PDT Date: Tuesday, 25 September 1984, 14:14-PDT From: Ken Olum Subject: migration-resist bits not propagated to new generations To: tops20 at score In DIRECT after VRLK6A a file created with a new generation doesn't get bits AR%EXM and AR%RAR propagated, because the codes sets them in word .FBBK0 instead of .FBBBT. Ken 25-Sep-84 19:13:59-PDT,3065;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 25 Sep 84 19:13:44-PDT Date: 25 Sep 84 22:15:46 EDT From: Charles Hedrick Subject: change in Rutgers addresses To: hostmaster@SRI-NIC.ARPA cc: tops-20@SU-SCORE.ARPA, postmaster@SRI-PRISM.ARPA It seems that RUTGERS-GW is now in production. Columbia has kindly consented to consider us as part of their network, for purposes of doing EGP. Thus the core gateways are all getting the necessary information about us from COLUMBIA-GW. I have verified with Postel that this does not violate any of the rules for EGP. (Of course Columbia is not actually processing any packets destined for our system. They simply include our network number and gateway address in their EGP update messages.) The following is a complete list of our hosts. HOST : 10.1.0.89, 128.6.0.2 : RUTGERS,RU-RED,RED : DEC-2060T : TOPS-20 : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : HOST : 128.6.0.3 : RU-GREEN,GREEN : DEC-2060 : TOPS-20 : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : HOST : 128.6.0.4 : RU-BLUE,BLUE : DEC-2060 : TOPS-20 : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : HOST : 128.6.0.5 : NB,NB-VAX : VAX-11/780 : VMS :: TCP/TELNET,TCP/FTP,TCP/SMTP : HOST : 128.6.0.194 : TOPAZ,RU-TOPAZ : PYRAMID-90X : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP : HOST : 128.6.0.195 : OPAL,RU-OPAL : SUN-150 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : Note that this represents changes in address for RU-GREEN and RU-BLUE, and two additional hosts (NB and TOPAZ). This host listing is in internal Rutgers form. You will probably want to perform the following pruning operations on these listings: - Typically you remove the nicknames Red, Blue, and Green, presumably on the theory that it is a bit cheeky of Rutgers to attempt to reserve all 3 primary colors. - We included the nicknames RU-TOPAZ and RU-OPAL only in case you want all of our names to show RU-. Our prefered names are simply TOPAZ and OPAL. If you find those names acceptable, we will delete the RU- nicknames. - You may wish to prune the list of hosts. NB will be administratively prohibited from using the Arpanet. Of course it is possible that the host name might leak out into the network in the headers of messages forwarded from local recipients. TOPAZ and OPAL will be making some use of the network, but only on a limited basis. We would find it acceptable for them to be omitted from the host table, though a few sites might find it necessary to add them locally. We expect to be adding some more hosts early in 1985, but by then we hope domains will be in effect, and you will be out of the business of keeping full host lists. Note that the machine name PYRAMID-90X is not in the official list of machine names (RFC900). You might want to add it. RU-BLUE and RU-GREEN will also continue to accept mail on the old host addresses (as well as the new, of course) until it appears that everyone has gotten the message. ------- 28-Sep-84 09:11:43-PDT,1659;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 28 Sep 84 09:11:28-PDT Date: 28 Sep 84 12:14:24 EDT From: Charles Hedrick Subject: is anyone using Macsyma on the 20? To: tops-20@SU-SCORE.ARPA We are looking for anyone who is using Macsyma on a DEC-20? We just got a copy under the special educational license arrangement from Symbolics. A number of things that we try refer to missing or nonsensical files. We called Symbolics and were told that the educational license was on an as-is basis, so they might not be able to help, though we still have not gotten a final answer from them. (I can understand their position, since we paid something that is little more than a distribution fee.) Typical problems are - attempts to call various things result in the system trying to load files like nusum.^V>. It looks like somebody forgot to set a Tops-20 switch, and we are getting ITS filenames. - an attempt to load a file given to us by someone at MIT results in an attempt to load the file module.^V* - we would like to get the effect of (sstatus linmode t). Putting that in the fixup file that is automatically loaded at startup has no effect. It looks like Macsyma is using some channel other than the normal tyi to do its input. Without source it is hard to figure out what to do. Since they don't distribute source, there isn't a lot I can do to investigate these problems. I am not expecting continued support from anybody. But if there are tricks in setting Macsyma up, I would love to hear them. ------- 28-Sep-84 22:54:26-PDT,1754;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Fri 28 Sep 84 22:54:16-PDT Date: Fri 28 Sep 84 22:56:42-PDT From: Richard Furuta Subject: Anyone using electronic mail to distribute telephone messages? To: Human-Nets@RUTGERS.ARPA, Tops-20@SU-SCORE.ARPA, Unix-Wizards@BRL.ARPA cc: Furuta@WASHINGTON.ARPA Is anyone out there using electronic mail to distribute telephone messages? The system we use now is to write the message on a little green piece of paper which is subsequently filed for the recipient. We are interested in switching to an electronic mail based system. However, it's unfair to ask the already busy person answering telephone calls to switch to a system for message taking that will increase the workload. It seems to us that using a vanilla mail interface will increase that workload particularly since the information that comes in on the message often doesn't arrive in a linear form (e.g., the telephone number may be given before the name of the caller and each might precede the name of the intended recipient). What I hope is that someone has already solved the problem and can point me to a piece of software (preferably running on Tops-20 or on Berkeley Unix) to aid in this process. In any case, I'd be interested to hear from anyone whose organization is using electronic mail for the telephone messages with details of how it is done and how well it is working. Since the amount of information on Human-Nets and Unix-Wizards overwhelmed me long ago, I'd appreciate it if responses could be mailed directly to me. --Rick Furuta@Washington (Arpanet, CSnet) ihnp4!uw-beaver!furuta (Usenet) ------- 29-Sep-84 11:14:09-PDT,1964;000000000001 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Sat 29 Sep 84 11:13:56-PDT Received: from CU20B.ARPA by columbia.arpa; Sat, 29 Sep 84 14:16:50 edt Date: Sat 29 Sep 84 14:15:58-EDT From: Travis Lee Winfrey Subject: Re: is anyone using Macsyma on the 20? To: hedrick@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA Cc: Us.Travis%CU20B@COLUMBIA, sy.ken%CU20B@COLUMBIA In-Reply-To: Message from "Ken Rossman " of Fri 28 Sep 84 21:23:18-EDT We have Macsyma here on cu20b. It's heavily used, but by the same group of people (mostly people in the apne department), so I doubt that all of the code is being exercised here. So far we've had three problems, all minor. Twice, people couldn't read or write something because of protection problems with a directory or a file. And once a file refered to another file that wasn't available, but since the specified directory wasn't , or , it looked like a little personal hack that slipped by the people at Symbolics. I think you're right in that someone forgot to set a tops20 switch; we've never seen references to filespecs like that. Symbolics should probably swap tapes with you. Support for the 20 or not, you got the wrong tape. I can't help you with (sstatus linmode t) as I prefer it the way it is now. If you manage to get it set, then you will break all the routines that require single-space input, like DEMO. It may be hard to set permanently: the read-eval-print loop resets it to the previous value from another variable (I think). You can still line-edit with it as it is: ^K retypes, ?? erases the whole line (no, I don't like that), and DEL erases the last character, typing it out again. "Foo" followed by three DEL's will show "FooooF". ^H triggers a cute little interrupt that tells you to use DEL instead, and doesn't erase anything. Travis ------- 30-Sep-84 12:27:39-PDT,863;000000000000 Return-Path: <@COLUMBIA-20.ARPA:GINGELL@CWR20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Sep 84 12:27:29-PDT Received: from CWR20B by CUCS20 with DECnet; 30 Sep 84 15:30:37 EDT Date: Sun 30 Sep 84 15:28:59-EDT From: Rob Gingell Subject: Wordstar Customizations for EMACS To: Tops-20%SU-SCORE@CUCS20 We have a number of users who are used to using Wordstar, and are occasional users of EMACS. They would like to have EMACS customized to be Wordstar-like, where the customization could be a simple as simply changing the key bindings so that the keystrokes they are used to making do the same thing in both editors or as complicated as providing some of the other Wordstar functional and display effects. Has anyone already build a "WRDSTR.EMACS"? Thanks for any and all information. Rob ------- 30-Sep-84 19:10:57-PDT,1815;000000000001 Mail-From: ALMQUIST created at 30-Sep-84 19:10:43 Date: Sun 30 Sep 84 19:10:43-PDT From: Philip Almquist Subject: Re: is anyone using Macsyma on the 20? To: HEDRICK@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Fri 28 Sep 84 12:14:24-PDT Chuck, I (unfortunately) have spent a great many hours trying to get Tops-20 Macsyma to work, both here and while I was at CMU. The stuff I've done here is not in any shape to be distributed (and won't be anytime soon given my employer's priorities), but you can make a number of the bugs go away by getting the stuff I did at CMU. It is for an older version of Macsyma but I think will mostly work anyway. I think that I have put all of the necessary files in Ps: on CMU-CS-C. They are: CMUFIX.LSP - source file for the mods LISP.INI - reloads your Macsyma; see instructions within it. You may have to insert the mods to this file into the current distributed LISP.INI to get a working Macsyma. CURSORPOS.LSP - terminal I/O; this file and/or the next one may have to be modified to support your terminal types TTYSCAN.LSP - more terminal support CPOS.MID - yet more terminal support You should probably also look at TOPS20.FIX and any files it references, since I'm suddenly not sure if I changed them. Good luck; I will answer (a small number of) questions if you have problems. The problem with *'s in filenames is a problem with Maclisp rather than with Macsyma. No good cure for this problem is currently known. If you send me mail about other problems not fixed by the above I may (or may not) have a fix for them or become interested in solving it. Philip ------- 30-Sep-84 23:24:33-PDT,2356;000000000001 Mail-From: ALMQUIST created at 30-Sep-84 23:24:23 Date: Sun 30 Sep 84 23:24:23-PDT From: Philip Almquist Subject: Re: is anyone using Macsyma on the 20? To: Us.Travis%CU20B@COLUMBIA.ARPA cc: hedrick@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA, sy.ken%CU20B@COLUMBIA.ARPA In-Reply-To: Message from "Travis Lee Winfrey " of Sat 29 Sep 84 11:14:11-PDT Sadly, they do seem to have the right tape. You see, there isn't really a Tops-20 switch. They have a PDP-10 switch, which I think is supposed to be things that are Maclisp-specific, but I think it also throws in a few things that are ITS-specific. Not that that matters much, since the current distributed version also has the ITS switch on (in fact, it loses even worse than it does now if one turns off the ITS switch!). As far as I can tell, the only real difference between the Tops-20 version and the ITS version is that they load different fix files at startup. The CMU hacks mentioned in my previous message fix the problem of looking for things on random ITS directories. Unfortunately, this doesn't solve the problem that you don't get all the FASL files that reside in random directories on MC. The protection problem was probably with the PRIMER command, also fixed by the CMU hacks. They also fix the problem with DEL handling ("FooooF") a la SOS. Sadly, they don't fix some of the unfortunate choices of editing characters. Philip Ps: to make the filename stuff work a @i(tiny) bit better, try creating a file called TOPS20.FIX.n, where n is the Macsyma version number, on PS:. Note carefully: Macsyma 304 was shipped with a version 303 fix file; if your Macsyma and your fix file have different versions be sure to start with an empty file rather than editing the wrong version of the fix file! Also note carefully: never change the generation number of a fix file. Anyway...your fix file should contain: (setq $file_search ($make_list '|PS:| 'bar 1 1)) Don't ask me what the hell the "'bar" does; I don't know, but it seems to work. Alternatively, if you want to avoid making Macsyma's painfully slow startup even slower, you can put that line right before the suspend in LISP.INI and rebuild your Macsyma. ------- 1-Oct-84 06:44:00-PDT,985;000000000001 Mail-From: MRC created at 1-Oct-84 06:43:53 Date: Mon 1 Oct 84 06:43:53-PDT From: Mark Crispin Subject: more MACSYMA To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) According to Symbolics' MACSYMA Newsletter, dated July 1984, the TOPS-20 version of MACSYMA is "discontinued", "as-is", "no support is available." Both the ITS and Multics versions are "not scheduled" for later releases; I presume the difference is that they will give your Multics or ITS MACSYMA bug reports the time of day. Release dates for later versions are announced for: 3600, Unix, EUNICE, REX, and Unix/68000. Disgusting, isn't it? I'll bet that if any of the universities trying to use TOPS-20 MACSYMA tied having a working version to any large 3600 purchases Symbolics would suddenly discover an inclination to fix it. Too bad it's unlikely to happen. ------- 1-Oct-84 12:02:48-PDT,451;000000000001 Mail-From: G.EGK created at 1-Oct-84 12:00:26 Date: Mon 1 Oct 84 12:00:26-PDT From: Edjik Subject: Re: more MACSYMA To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA, G.EGK@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 1 Oct 84 06:44:06-PDT Maybe Symbolics "discontinuing" TOPS20 MACSYMA is the first step in having "DOE MACSYMA" become the official TOPS20 MACSYMA? --E+ ------- 2-Oct-84 18:28:37-PDT,530;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Oct 84 18:28:26-PDT Date: Tue 2 Oct 84 21:25:42-EDT From: Kevin Paetzold Subject: new tops-20an monitor To: tops-20@SU-SCORE.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 I just sent messages notifying people of a major new release of the TOPS-20 TCP monitor. If you did not receive notification and you think you should have please let me know. ------- 2-Oct-84 15:20:18-PDT,3070;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Oct 84 15:20:02-PDT Date: Tue 2 Oct 84 18:12:02-EDT From: Kevin Paetzold Subject: TOPS-20 Release 5.4 To: tcpip@DEC-MARLBORO.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 +---------------------------+ ! ! ! ! ! ! ! ! ! d ! i ! g ! i ! t ! a ! l ! ! ! ! ! ! ! ! ! +---------------------------+ Date: October 2, 1984 From: Kevin W. Paetzold Dept: TOPS-20 Monitor Group DTN: 231-7430 Telephone: 617-467-7430 LOC/MAIL STOP: MRO1-2/L10 Subject: Release 5.4 Latest and Greatest TOPS-20AN TCP/IP Monitor TOPS-20 Release 5.4 is now ready for distribution to all existing licensed TOPS-20AN sites. Release 5.4 supports TCP/IP on the Ethernet using Digital's KLNI hardware interface. Additional information on the Ethernet support aspects of release 5.4 is available upon request. Release 5.4 has few functionality differences from release 5.3 in the absence of the KLNI hardware. Many bugs and problems have been fixed. It is to the advantage of all sites to convert from release 5.3 to release 5.4 as soon as possible due to the number of problems fixed in 5.4. TOPS-20 Release 5.3 is no longer supported at this time. The 5.4 monitor is based on TOPS-20 autopatch tape # 8 [sic] sources. Autopatch tape 8 is being released from the SDC at this time and should be arriving at your site shortly. The last version of release 5.3 that was shipped was based on autopatch tape # 6 [sic] sources. Due to the coincidence of autopatch tape #8 it was decided to base this monitor shipment on tape # 8 and not on tape # 7. As with previous release 5.3 shipments this shipment is made up of EXE, REL, and UNV files. In addition to the above files MAC, CCL, CTL, CMD, and RED files have been provided for those sites wishing to build and/or configure local monitors. For those source files not provided RED files have been provided to allow REDIT to convert MAC files from the autopatch tape # 8 sources to release 5.4 sources. Sources for the KLNI specific modules have not been provided. Specifically NISRV.MAC, PHYKNI.MAC, IPNIDV.MAC, TOPS.MAC, NIPAR.MAC, NISYM.MAC, NIUSR.MAC, and NITEST.MAC. The CTL and CMD files for this shipment expect these modules to be present and may have to be modified. These modules are only available to sites with TOPS-20 source licenses and are available upon request. Future shipments will include RED files for the changes to these modules. Details on the exact procedure for distribution of the files will be forthcoming shortly. This message was intended to give advance warning of my intentions. ------- 2-Oct-84 18:52:03-PDT,12117;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Oct 84 18:51:25-PDT Date: Tue 2 Oct 84 21:17:04-EDT From: Kevin Paetzold Subject: Distribution of TOPS-20AN Release 5.4 To: tcpip@DEC-MARLBORO.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 +---------------------------+ Date: October 2, 1984 ! ! ! ! ! ! ! ! From: Kevin W. Paetzold ! d ! i ! g ! i ! t ! a ! l ! Dept: TOPS-20 Monitor Group ! ! ! ! ! ! ! ! DTN: 231-7430 +---------------------------+ Telephone: 617-467-7430 LOC/MAIL STOP: MRO1-2/L10 Subject: Distribution of TOPS-20AN Release 5.4(1025) The end of this message contains a detailed directory listing of the files which make up the latest release of the 5.4 monitor with sequential checksums listed. The MACSYM that is being shipped with this monitor should only be used for building this monitor from sources and is not supported for any other purpose. The name of the SYSTEM:SITE-ADDRESS.TXT file has been changed to SYSTEM:INTERNET.ADDRESS. Be sure to rename (or copy) your address file to the new name. The IPHOST being shipped with this monitor has much additional functionality including a RETRIEVE command which will get new HOST and GATEWAY files from the NIC via the NIC NAME server. Six prebuilt monitors are included with this release. The following table is an attempt to explain the differences between the prebuilt monitors. Sites running a prebuilt monitor will probably want AN-MONLGE, AN-MONLGD, or AN-MONBIG. Name Size Decnet Support AN20 Support KLNI Support -------------------------------------------------------------------- AN-MONBIG.EXE Big No Yes No AN-MONLGE.EXE Large No Yes No AN-MONLGD.EXE ? Yes Yes No AN-MONLND.EXE ? Yes Yes Yes AN-MONLNI.EXE Large No Yes Yes AN-MONNAN.EXE Large No No Yes Several distribution methods are available (or being attempted for the first time). Sites will be allowed to FTP the files from DEC-TOPS20 at published prearranged times. On request (and with site cooperation) we will FTP the files to directories on the customer's system. On special request we will make a tape and ship the tape to a customer site. A forthcoming message will detail times that DEC-TOPS20 will be available for FTP'ing. Customers are encouraged to obtain the files for this release as soon as possible even though the autopatch # 8 tape has not arrived at the site. Customers asking for us to FTP the files to their system should create directories that are accessable via FTP with the following names: After creating the directories please notify me (ie. Paetzold@DEC-MARLBORO). I will notify the sites when I start FTP'ing the files and when I am finished. As always problems to me. ----------------------------------------------------------------------- AN-MONBIG.EXE 379 194048(36) 1-Oct-84 18:21:09 PAETZOLD 013266 AN-MONLGD.EXE 402 205824(36) 1-Oct-84 19:21:33 PAETZOLD 735217 AN-MONLGE.EXE 379 194048(36) 1-Oct-84 18:31:08 PAETZOLD 157526 AN-MONLND.EXE 418 214016(36) 1-Oct-84 19:35:19 PAETZOLD 715043 AN-MONLNI.EXE 397 203264(36) 1-Oct-84 18:44:40 PAETZOLD 100613 AN-MONNAN.EXE 391 200192(36) 1-Oct-84 18:55:51 PAETZOLD 710576 BUGSTRINGS.TXT 13 32366(7) 2-Oct-84 17:35:44 PAETZOLD 546656 ERRMES.BIN 18 8717(36) 26-Sep-84 08:11:51 PAETZOLD 764631 MONSYM.UNV 50 25372(36) 1-Oct-84 15:49:58 PAETZOLD 070232 NSPPAR.UNV 6 2621(36) 1-Oct-84 15:53:52 PAETZOLD 552647 PHYPAR.UNV 2 946(36) 1-Oct-84 15:53:37 PAETZOLD 172142 PROKL.UNV 1 236(36) 1-Oct-84 15:53:25 PAETZOLD 350060 PROLOG.UNV 82 41925(36) 1-Oct-84 15:53:09 PAETZOLD 302745 SERCOD.UNV 2 612(36) 1-Oct-84 15:54:03 PAETZOLD 425130 T20-AN.LOG 29 14790(36) 1-Oct-84 19:11:42 PAETZOLD 363534 T20AN.REL 690 352883(36) 1-Oct-84 18:01:40 PAETZOLD 475606 Total of 3259 pages in 16 files, Checksum = 535545 5221BM.MEM 43 21550(36) 21-Nov-83 15:58:02 PAETZOLD 413124 BBN-IP-JSYS.DOC 7 15940(7) 12-Dec-82 20:37:02 PAETZOLD 256543 BBN-TCP-JSYS.DOC 11 25913(7) 12-Dec-82 20:37:50 PAETZOLD 710143 TCPIP-SPEC.DOC 22 54286(7) 13-Sep-84 14:14:27 PAETZOLD 635634 Total of 83 pages in 4 files, Checksum = 766611 ANAUNV.MAC 23 58791(7) 24-Sep-84 13:53:14 PAETZOLD 007474 ANNDBG.MAC 1 484(7) 17-Nov-83 14:59:38 PAETZOLD 600242 ANNLGD.MAC 1 488(7) 17-Nov-83 14:59:41 PAETZOLD 011350 ANNLND.MAC 1 424(7) 9-Jun-84 11:07:43 PAETZOLD 755060 ANNLNI.MAC 1 417(7) 9-Jun-84 11:07:00 PAETZOLD 130366 ANNNAN.MAC 1 437(7) 17-Jun-84 09:59:58 PAETZOLD 566111 ANPBIG.MAC 1 1166(7) 10-Jun-84 15:27:08 PAETZOLD 105503 ANPLDD.MAC 1 1026(7) 19-Jul-84 14:43:02 PAETZOLD 023355 ANPLGD.MAC 1 2288(7) 10-Jun-84 15:27:16 PAETZOLD 161175 ANPLGE.MAC 1 1443(7) 10-Jun-84 15:27:22 PAETZOLD 730133 ANPLND.MAC 1 1125(7) 15-Aug-84 11:19:22 PAETZOLD 744544 ANPLNI.MAC 1 1128(7) 15-Aug-84 11:19:42 PAETZOLD 462223 ANPNAN.MAC 1 1236(7) 15-Aug-84 11:19:48 PAETZOLD 655706 APRSRV.RED 4 7703(7) 1-Oct-84 15:51:39 PAETZOLD 503273 ASEMBL.CMD 2 3149(7) 25-Aug-84 16:45:37 PAETZOLD 760126 BUGS.MAC 84 213343(7) 25-Sep-84 11:13:05 PAETZOLD 534066 FILINI.RED 1 990(7) 1-Oct-84 15:52:10 PAETZOLD 264506 FORK.RED 2 2777(7) 1-Oct-84 15:52:28 PAETZOLD 165244 GLOBS.MAC 25 61885(7) 25-Sep-84 11:14:24 PAETZOLD 162617 GTJFN.RED 3 7393(7) 1-Oct-84 15:52:58 PAETZOLD 734324 IMPANX.MAC 11 25997(7) 24-Sep-84 13:53:37 PAETZOLD 412040 IMPDV.MAC 21 52717(7) 24-Sep-84 13:53:53 PAETZOLD 705233 IO.RED 4 8464(7) 1-Oct-84 15:53:17 PAETZOLD 316543 IPFREE.MAC 11 27841(7) 30-Sep-84 23:41:39 PAETZOLD 530324 IPIPIP.MAC 58 147330(7) 1-Oct-84 14:14:22 PAETZOLD 202012 JSYSA.RED 2 3798(7) 1-Oct-84 15:53:30 PAETZOLD 324160 JSYSF.RED 1 1924(7) 1-Oct-84 15:54:31 PAETZOLD 212367 LNKADD.CCL 1 579(7) 6-Sep-84 09:25:50 PAETZOLD 127602 LNKAN2.CCL 1 1350(7) 25-Aug-84 16:45:49 PAETZOLD 070261 LNKAND.CCL 1 492(7) 5-Jun-84 19:52:41 PAETZOLD 010670 LNKANS.CCL 1 753(7) 8-Sep-84 11:50:12 PAETZOLD 162545 MEXEC.RED 5 12262(7) 1-Oct-84 15:55:10 PAETZOLD 021445 MNETDV.MAC 21 52004(7) 24-Sep-84 13:55:03 PAETZOLD 642072 MONSYM.RED 11 26156(7) 1-Oct-84 15:55:34 PAETZOLD 035166 NSPSRV.RED 6 13654(7) 1-Oct-84 15:56:05 PAETZOLD 566604 PAGEM.RED 2 4312(7) 1-Oct-84 15:57:01 PAETZOLD 331245 PARAMS.RED 2 3099(7) 1-Oct-84 15:57:43 PAETZOLD 347552 PHYH2.RED 2 3874(7) 1-Oct-84 15:57:48 PAETZOLD 435275 PHYPAR.RED 1 1391(7) 1-Oct-84 15:57:53 PAETZOLD 341510 PROLOG.RED 4 9950(7) 1-Oct-84 15:57:56 PAETZOLD 137416 REL5.MAC 1 10(7) 26-Oct-83 16:57:19 PAETZOLD 707142 SCHED.RED 1 1171(7) 1-Oct-84 15:58:14 PAETZOLD 343472 SERCOD.RED 1 1349(7) 1-Oct-84 15:58:48 PAETZOLD 263472 STG.RED 32 81522(7) 1-Oct-84 15:58:51 PAETZOLD 024024 T20-AN.CTL 3 5389(7) 25-Aug-84 16:44:32 PAETZOLD 376054 TCPBBN.MAC 22 56134(7) 24-Sep-84 13:55:26 PAETZOLD 435335 TCPCRC.MAC 6 12935(7) 24-Sep-84 13:55:39 PAETZOLD 431023 TCPJFN.MAC 27 67790(7) 24-Sep-84 13:55:46 PAETZOLD 640652 TCPTCP.MAC 79 200450(7) 24-Sep-84 13:55:59 PAETZOLD 543653 TOPS.MAC 1 90(7) 27-Apr-84 13:34:33 PAETZOLD 470511 TTANDV.MAC 20 49819(7) 24-Sep-84 13:56:30 PAETZOLD 351362 TTPHDV.RED 1 1424(7) 1-Oct-84 15:59:53 PAETZOLD 010700 TTYSRV.RED 9 21305(7) 1-Oct-84 16:00:03 PAETZOLD 572714 VERSIO.MAC 3 6087(7) 1-Oct-84 14:14:08 PAETZOLD 626142 Total of 528 pages in 54 files, Checksum = 756610 5-4-SETSPD.EXE 10 5120(36) 26-Sep-84 08:00:44 PAETZOLD 712563 IPHOST.EXE 13 6656(36) 26-Sep-84 08:03:09 PAETZOLD 216705 IPHOST.MAC 32 81478(7) 26-Sep-84 07:57:46 PAETZOLD 530770 MACSYM.MAC 38 96580(7) 28-Mar-84 21:58:58 PAETZOLD 721634 MACSYM.UNV 18 8788(36) 4-Sep-84 17:52:35 PAETZOLD 771345 SETSPD.MAC 24 60334(7) 31-Mar-84 18:47:07 PAETZOLD 371374 Total of 135 pages in 6 files, Checksum = 537631 Grand total of 4005 pages in 84 files, Checksum = 246606 ------- 3-Oct-84 02:41:35-PDT,1245;000000000001 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Oct 84 02:41:24-PDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2643096626678570@MIT-MULTICS.ARPA>; 03 Oct 1984 05:30:26 edt Date: 03 Oct 84 01:25 +0100 From: Bengt_Olsen_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Bengt_Olsen_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, IPL_Software_Enquiries%QZCOM.MAILNET@MIT-MULTICS.ARPA, Sven_Olofsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Jurek_Wolodarski_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, "Charles Hedrick" cc: IPL_Software_Enquiries%QZCOM.MAILNET@MIT-MULTICS.ARPA, Sven_Olofsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Jurek_Wolodarski_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: is anyone using Macsyma on the 20? Message-ID: <71811@QZCOM> In-Reply-To: <71559@QZCOM> We also have bought the tape at QZ but I am not aware if we have met those problems. 4-Oct-84 08:24:22-PDT,567;000000000000 Mail-From: MRC created at 4-Oct-84 08:24:07 Date: Thu 4 Oct 84 08:24:06-PDT From: Mark Crispin Subject: new MM To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is a new version of MM at Score which removes the old support for MIT I.T.S. "structured addresses" (using parenthesis). This means that REPLY will now do the right thing with an address which starts with a comment, e.g. From: (the only) Foobar@Zowie ------- 4-Oct-84 10:56:54-PDT,1935;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 10:56:46-PDT Date: Thu 4 Oct 84 10:54:01-PDT From: Greg Satz Subject: [Kevin Paetzold : Re: packet size constraints] To: su-tops-20@SU-SCORE.ARPA cc: hansen@SU-SIERRA.ARPA Phone: (415) 497-1004 sigh. --------------- Return-Path: Received: from SRI-NIC.ARPA by SU-SIERRA.ARPA with TCP; Thu 4 Oct 84 10:50:34-PDT Received: from DEC-MARLBORO.ARPA by SRI-NIC.ARPA with TCP; Thu 4 Oct 84 10:10:11-PDT Date: Thu 4 Oct 84 13:08:10-EDT From: Kevin Paetzold Subject: Re: packet size constraints To: CLYNN@BBNA.ARPA cc: HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "CLYNN@BBNA" of Wed 3 Oct 84 14:19:00-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 Well, lets get the story straight. We (TOPS-20 Monitor group) met with BBN early this year (or late last year) about the code in question from BBN. At that time we talked about the schedules that TOPS-20 had at that point and informed BBN that we needed to have the code from them by sometime in February to meet release 6 schedules. We did not get the code in time for release 6. It was at least 4 months late for release 6. It will not be in release 6. We have not been sitting on our hands however. We went ahead and implemented the DEC KLNI ethernet hardware, driver, and IP interface. Also cleaned up lots of stuff in TCP/IP in general. I have not had a chance to even look at the BBN changes yet. I was not aware that it even supported larger messages. It is not clear that I will get the chance to merge this stuff before the release 6.1 schedule shuts me out. There is a little bit more to TOPS-20 than the TCP/IP code. ------- ------- 4-Oct-84 22:43:47-PDT,531;000000000000 Mail-From: G.FUSSELL created at 4-Oct-84 22:43:34 Date: Thu 4 Oct 84 22:43:34-PDT From: Carl Fussell Subject: DEC-20 C compiler To: tops-20@SU-SCORE.ARPA Address: Santa Clara University a few months back there was a notice on this list about a DEC 20 C compiler... I think it was from a university in the Southwest. I was wondering if anyone else has heard more about this compiler or recalls the sender's name. Did it ever become available? thanx for any info... carl ------- 4-Oct-84 23:04:18-PDT,1155;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 23:04:03-PDT Date: Fri 5 Oct 84 02:02:56-EDT From: Rob Austein Subject: Re: DEC-20 C compiler To: G.FUSSELL@SU-SCORE.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Carl Fussell " of Fri 5 Oct 84 01:47:02-EDT Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341 Return-Path: Received: from SU-SCORE.ARPA by MIT-XX.ARPA with TCP; Fri 5 Oct 84 01:46:56-EDT Date: Thu 4 Oct 84 22:43:34-PDT From: Carl Fussell Subject: DEC-20 C compiler To: tops-20@SU-SCORE.ARPA a few months back there was a notice on this list about a DEC 20 C compiler... I think it was from a university in the Southwest. I was wondering if anyone else has heard more about this compiler or recalls the sender's name. Did it ever become available? ------- Don't know about availability, but the sender was Greg Titus at New Mexico Tech. ------- 4-Oct-84 23:05:37-PDT,861;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 23:05:22-PDT Received: from CU20B.ARPA by columbia.arpa; Fri, 5 Oct 84 01:52:21 edt Date: Fri 5 Oct 84 01:51:55-EDT From: Ken Rossman Subject: TM03/TM78 query To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Does anyone know offhand if it's at all possible to run TU77 tape drives on a TM78 controller? For example, can TU77's and TU78's be mixed on the same TM78 controller? I'm assuming that a TM03 can't hack TU78's because of the dual port capabilities of the TU78 (not to mention numerous other internal electronic differences that must certainly exist). It's not clear that one can't run a TU77 on a TM78, though, so I thought I'd ask. /Ken ------- 5-Oct-84 14:19:15-PDT,551;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Oct 84 13:58:52-PDT Date: Fri 5 Oct 84 13:59:48-PDT From: Bruce Tanner Subject: Laser printers To: Tops-20@SU-SCORE.ARPA Has there been anything new in tha area of laser printers and -20s since a DECUS session I went to a few years ago? We're planning on getting a Xerox 2700 to hang off a terminal line. Is there a better medium-duty (i.e. sturdier than the Cannon printer based) laser printer? -Bruce ------- 5-Oct-84 21:36:34-PDT,679;000000000001 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Oct 84 21:36:24-PDT Date: 5 Oct 1984 22:38 MDT (Fri) Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE Subject: HOSTS Table size Isn't anyone getting fed up enough when the HOSTS.TXT no longer fits and a new MONITR has to be built again every so often, to rattle some cages? Or, have you all found an obsurdly high prime value that you've never been bit? If so, just tell all of us that number and I'll go away quietly. Then, the next time the table overruns, we can all scream together.... --Frank 6-Oct-84 09:40:41-PDT,998;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 6 Oct 84 09:40:31-PDT Date: Sat 6 Oct 84 12:41:42-EDT From: Kevin Paetzold Subject: Re: Laser printers To: CERRITOS@USC-ECL.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bruce Tanner " of Fri 5 Oct 84 18:46:18-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 This might be out of the range of what you are interested in, but: In marlboro we are currently using two Xerox 8700s interfaced through a Vax on the Ethernet (ie. DECNET) to provide printing services for most of the engineering systems in Marlboro (about 20 DEC20s and countless hordes of VAXen). Code exists for interfacing the spooling system on the Vaxen (which I do not know much about) and the spooling system on the 20 (Galaxy). It all works pretty well. If you are interested in more details let me know. ------- 6-Oct-84 09:45:19-PDT,618;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 6 Oct 84 09:45:09-PDT Date: Sat 6 Oct 84 12:46:20-EDT From: Kevin Paetzold Subject: Re: HOSTS Table size To: WANCHO@SIMTEL20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from ""Frank J. Wancho" " of Fri 5 Oct 84 22:38:00-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 The monitors I am shipping are built for 4001. hosts. THe current HOSTS.TXT has less than 2000. names in it. I hope that carries us for a while. ------- 10-Oct-84 11:55:15-PDT,777;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 10 Oct 84 11:55:01-PDT Date: 10 Oct 1984 12:56 MDT (Wed) Message-ID: From: "Frank J. Wancho" To: BUG-EMACS@MIT-MC Cc: TOPS-20@SCORE Subject: EMACS trademarked?!? I don't know how I missed this, but since the August issue of BYTE, UNIPRESS is claiming a trademark on EMACS in their ads. I say "claiming" because the first requirement to be able to register a trademark is to have claimed the trademark associated with a product or service for at least a year. If such a claimed trademark goes unchallenged, I suspect we may be forced to give up using the name EMACS, as absurd as it sounds... --Frank 10-Oct-84 13:53:04-PDT,401;000000000000 Return-Path: Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 10 Oct 84 13:52:36-PDT Date: 10 October 1984 16:33-EDT From: Leigh L. Klotz Subject: EMACS trademarked?!? To: WANCHO @ SIMTEL20 cc: BUG-EMACS @ MIT-MC, TOPS-20 @ SU-SCORE In-reply-to: Msg of 10 Oct 1984 12:56 MDT (Wed) from Frank J. Wancho We're looking into this... 10-Oct-84 19:52:53-PDT,1447;000000000000 Mail-From: MRC created at 10-Oct-84 19:52:45 Date: Wed 10 Oct 84 19:52:44-PDT From: Mark Crispin Subject: Re: EMACS trademarked?!? To: KLOTZ@MIT-MC.ARPA cc: WANCHO@SIMTEL20.ARPA, BUG-EMACS@MIT-MC.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Leigh L. Klotz " of Wed 10 Oct 84 13:33:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think it is quite unlikely that that trademark would stand up in court. The original meaning of "EMACS" became lost once the EMACS interface was implemented in other than TECO on a PDP-10, and has since come to mean a generic class of display editors with certain characteristics. This is precisely the sort of thing which keeps a name from being a trademark -- in the USA "Asprin" lost its trademark status and great lengths are gone to protect "Kleenex" and "Xerox" from becoming generic names for tissues and copying machines respectively. Because of this, even RMS couldn't trademark the name EMACS (assuming he wanted to) any more. The question is, who is going to sue Unipress? I suspect it'll be one of the other companies which have proprietary versions of EMACS. A pity, because Unipress ought to be hit for a nice amount in $$ for damages (restraint in trade, etc.) and it'd be nice if the people who worked on PDP-10 EMACS got it... ------- 11-Oct-84 07:31:42-PDT,781;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Oct 84 07:31:32-PDT Date: 5 Oct 1984 1805-EDT From: Thomas Blinn To: sy.Ken%CU20B at COLUMBIA, TOPS-20 at SU-SCORE Reply-to: Blinn at DEC-MARLBORO Home: "3209 Windsor Ridge Drive, Westboro MA 01581" Office: "One Iron Way, MRO2-2/8D2, Marlboro MA 01752" Telephone: "(617) 467-5562, DTN 231-5562, home (617) 366-0308" Subject: Re: TM03/TM78 query Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12053098131.17.275.39124 at DEC-MARLBORO> Regarding: Message from Ken Rossman of 5-Oct-84 1556-EDT Can't be done. The TM78 doesn't support the 800bpi NRZI mode of the TU77, among other problems. -------- 11-Oct-84 13:53:24-PDT,445;000000000001 Return-Path: <@MIT-MC:RMS@MIT-OZ> Received: from MIT-MC by SU-SCORE.ARPA with TCP; Thu 11 Oct 84 13:52:24-PDT Date: Thu 11 Oct 84 16:50:58-EDT From: Richard M. Stallman Subject: EMACS(tm) To: bug-emacs@MIT-MC, tops-20@SU-SCORE.ARPA I got the MIT patent office to send Unipress a letter. I also heard that CCA sent them a letter and that Unipress agreed to stop claiming rights to the term "EMACS". ------- 11-Oct-84 15:58:01-PDT,528;000000000000 Return-Path: Received: from MIT-MC by SU-SCORE.ARPA with TCP; Thu 11 Oct 84 15:57:30-PDT Date: 11 October 1984 18:56-EDT From: Leigh L. Klotz Subject: EMACS trademarked?!? To: MRC @ SU-SCORE cc: BUG-EMACS @ MIT-MC, TOPS-20 @ SU-SCORE, WANCHO @ SIMTEL20 In-reply-to: Msg of Wed 10 Oct 84 19:52:44-PDT from Mark Crispin I have word that the Unipress people had already backed down on the matter, and that their ads will reflect the change after a short delay. 11-Oct-84 19:41:09-PDT,2072;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Oct 84 19:40:38-PDT Date: 11 Oct 84 22:42:20 EDT From: Charles Hedrick Subject: Trademarking EMACS To: tops-20@SU-SCORE.ARPA, bug-emacs@MIT-MC.ARPA, info-emacs@CMU-CS-C.ARPA There was recently some discussion on the Tops-20 mailing list (and I think maybe some others as well) about ads from Unipress that have shown EMACS as a trademark. Since I had more confidence than some of you in the sanity of the folks at Unipress, I decided to check with them to find out what is going on. The following response is from Mike Gallaher, one of the EMACS technical support staff. It was written in consultation with the president of Unipress. ------------------ Unipress is NOT trying to claim the name "EMACS" as a trademark. We do claim the names "Unipress Emacs" and "Gosling Emacs" as trademarks, which we have done for three or four months now. For a period of about two months, between April and June, we did ill-advisedly place the TM device on the name Emacs. Because of the lead time for magazine ads, the ads with Emacs(tm) just appeared in the last two or three issues of BYTE. Originally, our ads simply used the word EMACS, with no TM. We received many threatening letters and phone calls from several LARGE computer companies who claimed that they owned the name EMACS and that we could not use it. The use of TM on the name EMACS was a hasty action to defend ourselves from such threats. After realizing that it is absurd to trademark the name EMACS, because it has really become a name for a generic class of editors (as Mark Crispin noted), and to avoid conflicts with trademarks like "CCA EMACS", we decided to claim the phrases "Unipress Emacs" and "Gosling Emacs" instead. Our reason for claiming a trademark in the first place was in self-defense. We certainly have no intention of keeping anyone from using the name Emacs for any program, public-domain or otherwise. ------- 12-Oct-84 09:28:37-PDT,1045;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Oct 84 09:28:22-PDT Date: 12 Oct 84 12:30:30 EDT From: Don Subject: Internet background fork response improvement To: Paetzold@DEC-MARLBORO.ARPA cc: Tops-20@SU-SCORE.ARPA Comparing response time for PUP connections between our machines to internet ones, we observed that internet connections were much more sluggish on response time and echo. Looking at the sources, we determined a difference in the way each claimed priority. Replacing the MOVX T1,JP%SYS ; GET THE SYS BIT MOVEM T1,JOBBIT ; MAKE SURE WE CAN GO FAST just after INTBP0 (in IPIPIP) with MOVX T1,.FHSLF ;Run in queue zero MOVEI T2,1 SPRIW% produced a dramatic improvement in internet response time to this machine. Even with the "sys" bit, it's still got to climb out of a low queue under a heavy load, right? Is it advisable/dangerous to use both methods (system *and* queue zero) for this fork? Don ------- 12-Oct-84 10:31:32-PDT,2213;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Oct 84 10:31:15-PDT Date: Fri 12 Oct 84 10:29:10-PDT From: Kirk Lougheed Subject: Re: Internet background fork response improvement To: Watrous@RUTGERS.ARPA cc: Paetzold@DEC-MARLBORO.ARPA, Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Don " of Fri 12 Oct 84 12:30:30-PDT Beware of queue zero. When I was doing performance debugging of the PUP background fork at Stanford a couple of years ago, I discovered that JP%SYS processes do indeed sink into lower queues when the system load climbs. We were having problems with PUP NVTs timing out when the load reached 20 or more. When I experimented with running the PUP background process in queue zero, I discovered all sorts of potential problems. For one thing, a queue zero process has the highest scheduling priority; only another queue zero process can pre-empt it. It is very easy to get into the situation where the queue zero process is the only one that can possibly run. The system just quietly goes away.... I finally had to rework the PUP background process to NEVER block except in the main background test. I also had to be careful to ensure that I never got myself into infinite loops. For example, if I couldn't scan the NVT's, the temptation was to set the wakeup flag to scan NVT's again and then block. However since the process was in queue zero, it was the first one on the GOLIST. The background process would be immediately rescheduled without giving the process who owned the NVT lock a chance to release it. Bye-bye system unless you could force it into EDDT. My solution was a set of deferred wakeup conditions to allow the rest of the system to run. I also installed some defensive code that makes sure the PUP process doesn't monopolize the system. Unless someone has been very careful in coding the Internet background fork, you are likely to get yourself into trouble running it in queue zero. I also certainly understand your frustration with the sluggish response of Internet NVT's when compared with PUP NVT's. Kirk ------- 12-Oct-84 11:19:22-PDT,1058;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Oct 84 11:18:59-PDT Date: 12 Oct 84 14:21:18 EDT From: Charles Hedrick Subject: queue 0 To: tops-20@SU-SCORE.ARPA It was our impression that making the TCP fork a system fork also prevented rescheduling, so TCP would have to have been coded carefully anyway. We had noticed the code that you described in PUP.MAC. We were getting the system into trouble anyway: When the Internet fork does not get enough time, it starts dumping buginf's to the console. At the very least this prevents us from getting to the console, but there have also been situations where the system became unusable to the users as well. If it happens when there is no operator present, it could result in the console running out of paper, which (unless something has changed recently) also hangs the system. It will take a few days to see, but it is my guess that the current code will cause less trouble than what was there before. ------- 14-Oct-84 08:54:17-PDT,2844;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Sun 14 Oct 84 08:53:51-PDT Received: ID ; Sun 14 Oct 84 11:53:31-EDT Date: Sun, 14 Oct 1984 11:53 EDT Message-ID: From: "Leonard N. Zubkoff" To: Tops-20@SU-SCORE.ARPA Subject: Bug in TVT Output An application which negotiates binary transmission over a telnet connection does not get a transparent, eight bit wide data path. According to the telnet protocol, to transmit an IAC byte (255 decimal), the 20 should be sending two IAC's. Since only one is sent, the remote client will see this as some sort of (probably undefined) option negotiation. A fix to TTYSRV that's been working for us for several months follows (see lines labelled TL10): ;PHYSICAL LINE. APPLY PARITY TCOUT: SKIPL CHITAB(1) ;TEST PARITY BIT FOR THIS CHAR JRST TCOU1 ;NO PARITY NEEDED. GO ON CALL SPARTY ;SET PARITY BIT AS NEEDED ;FULLY ACTIVE LINE. PROCESS LINES LINKED TO THIS ONE TCOU1: MOVE C,TTLINK(B) ;ANY LINKS? CAME C,[-1] CALL TTLNK3 ;YES. GO DO THEM ;SEE IF THERE IS ROOM IN THE OUTPUT BUFFER TCOU3: JN TOFLG,(T2),R ;LOSE CHARACTER IF CTRL/O TYPED TCOUM1: DYNST T3 ;GET INTERNAL LINE NUMBER CAMN T3,CTYINT ;IS THIS AN ALIAS FOR THE CTY? RET ;YES. IGNORE CHARATCER CAIE T1,IACCH ;TL10 Output Byte = IAC? JRST TCOU6 ;TL10 No, output the character TDCALL D,<> ;TL10 Call TCOBTV if a TVT TCOU6: LOAD 3,TOMAX,(2) ;CAPACITY OF OUTPUT BUFFERS SKIPE IMECHF ;IMMEDIATE ECHO CHARACTER? ADDI 3,2 ;YES. EXTRA ROOM FOR THIS CHARACTER CAMLE 3,TTOCT(2) ;FULL? JRST TCOU5 ;NO ; .. ; .. ;ACTION WHEN BUFFER FULL SKIPN INSKED ;ARE WE IN THE SCHEDULER? SKIPE NSKED ;NO. ARE WE NOSKED? JRST [ SETOM TCOERR ;YES. INDICATE FAILURE FOR SCHEDULER RET] ; AND RETURN TDCALL D,<> ;CHECK FOR PTY ACTION NEEDED SETONE TTBKO,(T2) ;NOTE BLOCKE FOR OUTPUT EVENT PUSH P,1 ;SAVE CHARACTER DYNST T1 ;GET LINE NUMBER PUSH P,T1 ;SAVE LINE # CALL ULKTTY ;UNLOCK THE TTY MOVEI 1,TCOTST ;SETUP SCHEDULER TEST WORD HRL 1,0(P) ; LINE NO,,TEST ROUTINE ADR MOVSI T2,FHV5 ;WAIT PRIORITY HDISMS MOVE T2,0(P) ;GET STATIC LINE NUMBER CALL LCKTTY ;LOCK UP THE TTY JRST [CALL ULKTTY ;UNLOCK THE LINE I CASE IT GOT LOCKED MOVE T2,0(P) ;GET BACK LINE NUMBER CALL TCOU7 ;GET SPECIAL BLOCK JRST .+1] ADJSP P,-1 ;CLEAN UP STACK POP P,T1 ;CHARACTER JRST TCOU3 ;TL10 Double IAC characters on TVT's TCOBTV: PUSH P,T2 ;TL10 Save Line Number CALL TCOU6 ;TL10 Output the IAC POP P,T2 ;TL10 Restore Line Number MOVEI T1,IACCH ;TL10 Output a second IAC RET ;TL10 Return to output second IAC 14-Oct-84 09:03:33-PDT,1565;000000000001 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Sun 14 Oct 84 09:03:20-PDT Received: ID ; Sun 14 Oct 84 12:03:00-EDT Date: Sun, 14 Oct 1984 12:02 EDT Message-ID: From: "Leonard N. Zubkoff" To: Tops-20@SU-SCORE.ARPA Subject: Bug in Rnamf% There is a bug in Rnamf% which can cause a file not to be incrementally dumped by DUMPER. When a disk file is renamed on top of an existing disk file, thereby destroying the existing file, the .FBCNT word of the renamed file is taken from the source file but the .FBBK0 word is taken from the existing file. Note that this problem is obscure but does occur - the MacLisp compiler, for example, opens a temporary output file and then renames it to be the correct file, preserving the generation number from the source file; EMACS also can tickle this if a file is written back to the same generation number, as it used the same temporary output file renaming trick (BABYL files for example). The fix I applied is to change DSKREN to always zero the .FBBKn words of the resulting file: ;UPDATE .FBCRE WORD IN FDB CALL UPDDTM ;GET CURRENT TIME IN A MOVE B,A ;COPY TO B MOVE A,DSTFDB ;GET DESTINATION FDB ADDRESS SKIPL B ;CURRENT DATE AND TIME KNOWN? STOR B,FBCRE,(A) ;YES, STORE INTO FDB SETZM .FBBK0(A) ;TL5 Set .FBBK0 to 0 SETZM .FBBK1(A) ;TL5 Set .FBBK1 to 0 SETZM .FBBK2(A) ;TL5 Set .FBBK2 to 0 MOVE D,DIRORA ;GET ADR OF DIR AREA 14-Oct-84 17:13:27-PDT,597;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Sun 14 Oct 84 17:13:08-PDT Date: Sun 14 Oct 84 20:14:53-EDT From: Clifford Neuman Subject: Re: Bug in Rnamf% To: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of Sun 14 Oct 84 17:22:04-EDT When renaming files there are other things besides the .FBBK0 word which should be taken from the source file but aren't. Two of these are author and last-writer. I'll leave it to the reader to guess what holes this opens. ~ Cliff ------- 15-Oct-84 07:01:04-PDT,1226;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Oct 84 07:00:53-PDT Received: ID ; Mon 15 Oct 84 10:00:10-EDT Date: Mon 15 Oct 84 10:00:09-EDT From: Marc Shapiro Subject: bug: tty falsely considered assigned To: tops-20@SU-SCORE.ARPA cc: berlin@MIT-XX.ARPA, bug-xx@MIT-XX.ARPA There is a bug on our system (not CMU-CS-C), by which a tty line is considered assigned to a non-existent job, or to a job it is not really assigned to. Here is one way to reproduce the bug: 1) log in. (Say you logged on line tty100: with job 10.) 2) run KERMIT SERVER 3) from an other job, UNATTACH the previous job. 4) then kill it. The symptom is that when a user says ASSIGN TTY100: the system answers "?Already assigned to job 10", even if job to is non-existent. Logging in as job 10 does not solve the problem. Questions: 1) is there a way of getting back line 100 other than re-booting? 2) is there a fix to the monitor so this doesn't happen any more? Ours is a 2060 with 128 tty lines, running MIT's version of Tops-20, with Chaosnet. PS. Please reply directly to me, not to the list. ------- 15-Oct-84 13:17:23-PDT,779;000000000000 Mail-From: MRC created at 15-Oct-84 13:17:03 Date: Mon 15 Oct 84 13:17:03-PDT From: Mark Crispin Subject: Re: Bug in Rnamf% To: BCN@MIT-XX.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Clifford Neuman " of Sun 14 Oct 84 17:13:32-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Lots of programs know that the author and last writer words are not preserved by RNAMF%, e.g. MMailr. I guess the presumption is that the renamer should be considered to be the entity which "created" and "last wrote" the file. If you think of those words as being who "created" and "last wrote" the FDB instead of the file it makes some sense. ------- 15-Oct-84 15:20:24-PDT,1181;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Oct 84 15:20:04-PDT Date: Mon 15 Oct 84 18:21:43-EDT From: Clifford Neuman Subject: Re: Bug in Rnamf% To: MRC@SU-SCORE.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 15 Oct 84 17:59:26-EDT My mistake about the author. You are quite right that the author should be retained from the destination FDB. I also really messed up in the wording of my previous message. What I meant to say is that the last writer field should be filled in with the name of the user doing the rename. To demonstrate my point try the following. . Create file called FOO.BAR.1 containing anything you want. . Set its protection so that you can write to it from another account. . Log into another account, create the file BAR.BAS containing something different than whats in FOO.BAR.1 . Rename BAR.BAS over the existing generation of FOO.BAR. . Look at the last writer. What you will discover is that the file now has new contents, but you can't tell who it was that changed them. ~ Cliff ------- 15-Oct-84 15:39:40-PDT,528;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Mon 15 Oct 84 15:39:16-PDT Date: 15 Oct 84 15:39:49 PDT (Mon) To: tops-20@su-score Subject: Large systems 20th anniversary dinner From: Mike Iglesias Received: from Localhost by UCI-750a; 15 Oct 84 15:40:22 PDT (Mon) How formal (attire wise) is the 20th anniversary dinner at the Fall DECUS going to be? Suit and Tie? Jeans and t-shirt? Something inbetween? Mike Iglesias University of California, Irvine 16-Oct-84 14:45:09-PDT,590;000000000001 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 16 Oct 84 14:44:59-PDT Date: Tue 16 Oct 84 14:49:03-PDT From: Haruka Takano Subject: DTR ON/OFF To: Tops-20@SU-SCORE.ARPA I've heard (from DEC) that RSX20F VB15-13 has DTR ON/OFF capability, but that this facility is not easily accessible from the operating system. Does anyone out there have a monitor patch to turn DTR ON using an unmodified 15-13? DEC seems very hesitant to give out the in-house patch that they are apparently using. Haruka ------- 16-Oct-84 22:36:30-PDT,581;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Tue 16 Oct 84 22:36:20-PDT Date: Wed 17 Oct 84 00:38:00-CDT From: Clive Dawson Subject: Re: Large Systems 20th Anniversary dinner To: tops20@SU-SCORE.ARPA Regarding dress code for the banquet, I suppose the only real requirement would be shoes. Suit & tie preferred but not required. Cheers, Clive Dawson Large Systems SIG P.S. Rumor has it that DEC has plans to donate some really good door prizes for the banquet. Be there! ------- 17-Oct-84 12:54:26-PDT,941;000000000001 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 17 Oct 84 12:54:12-PDT Date: Wed 17 Oct 84 11:51:56-PDT From: Ken Olum Subject: Re: DTR ON/OFF To: Haruka at SRI-KL, Tops-20 at SU-SCORE In-Reply-To: Your message of Wed 17 Oct 84 10:00:00-PDT DTR is turned off on any RSX20F by sending a HANGUP code to the front-end. If DEC did anything normal, then you can set DTR by sending a DIALUP code, which has previously been used only in the 11->10 direction. If it's not implemented this way then DIALUP will either crash the front end or be ^Eset logins no remote, depending on whether a certain bug has been fixed. Speaking of which I had a patch for setting DTR when you open or assign a tty line and clearing it when you deassign or close it, as part of the RSX20F patches for setting DTR that I was distributing. Anyone is welcome to either. Ken ------- 22-Oct-84 17:44:32-PDT,931;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Oct 84 17:44:26-PDT Date: Mon 22 Oct 84 17:24:52-PDT From: Kirk Lougheed Subject: Sun Gateways To: su-tops-20@SU-SCORE.ARPA cc: nethax@SU-GREGORIO.ARPA The SUN Gateways appear to be somewhat broken with regard to IP packets. From looking at the code it appears that the largest packet that they will pass is 554 bytes, not the IP standard mininum of 576 bytes. After the MJH-B-Gateway was installed last Friday, Sierra started having terrible problems receiving large pieces of mail. After editing the PACKET-SIZE parameter in SYSTEM:SITE-ADDRESS.TXT to be 554 bytes and doing a CALL ADRINI in MDDT, the mail started pouring in. The gateways need to be fixed, but in the meantime lowering the maximum IP packet size appears to alleviate the most severe problems. Kirk ------- 22-Oct-84 21:18:23-PDT,651;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Oct 84 21:18:18-PDT Date: Mon 22 Oct 84 21:22:31-PDT From: Bill Subject: Re: Sun Gateways To: Lougheed@SU-SIERRA.ARPA cc: su-tops-20@SU-SCORE.ARPA, nethax@SU-GREGORIO.ARPA In-Reply-To: Message from "Kirk Lougheed " of Mon 22 Oct 84 17:51:02-PDT Kirk, I just double checked and the gateways over here pass 576 bytes[Actually they'll take 578]. The 554 is in fact used in the calculation of total packet size. But you need to add 22 bytes to this which gives 576. Bill ------- 22-Oct-84 23:17:07-PDT,638;000000000000 Mail-From: MRC created at 22-Oct-84 23:16:39 Date: Mon 22 Oct 84 23:16:39-PDT From: Mark Crispin Subject: MRC: back online To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) To all of you who have been trying to get MM from Score, the MRC: directory is now back online. MRC: suffered a head crash about a month ago and this is the first chance I've gotten to restore the structure. To those of you waiting for tapes, they will be coming soon. The head crash was what held things up. ------- 23-Oct-84 11:27:57-PDT,2050;000000000000 Return-Path: Received: from Navajo.ARPA (SU-NAVAJO.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Tue 23 Oct 84 11:27:51-PDT From: Jeff Mogul Date: 23 Oct 1984 1127-PDT (Tuesday) To: Kirk Lougheed Cc: nethax@SU-GREGORIO.ARPA, su-tops-20@SU-SCORE.ARPA Subject: Re: Sun Gateways In-Reply-To: Kirk Lougheed / Mon 22 Oct 84 17:24:52-PDT. The SUN Gateways appear to be somewhat broken with regard to IP packets. From looking at the code it appears that the largest packet that they will pass is 554 bytes, not the IP standard mininum of 576 bytes. After the MJH-B-Gateway was installed last Friday, Sierra started having terrible problems receiving large pieces of mail. After editing the PACKET-SIZE parameter in SYSTEM:SITE-ADDRESS.TXT to be 554 bytes and doing a CALL ADRINI in MDDT, the mail started pouring in. This is a bug that I pointed out to Phil and others months ago; at that time, I was assured that the only reason the packet size was so small was that the PDP-11 gateway in Pine Hall didn't have enough memory, and nobody had bothered to created different versions of the gateway code with varying packet sizes. I was also told that "when this becomes a problem" the PDP-11 would be scrapped and replaced by a Sun. Well, it is a problem. I suggest that the internal gateways be upgraded immediately to use 1500 byte buffers (the 10Mbit Ethernet MTU), and that we agree to limit 3Mbit Ethernet packets arbitrarily to the same size. If this means scrapping the PDP-11 in Pine Hall ... By the way, I've been told that the next release of Golden's software will fragment IPs, so we could (if we wanted to) start using packets larger than 1000 bytes (approximately the ARPAnet MTU) at that point; on the other hand, it appears that fragmentation should be avoided whenever possible, and so the Vax 4.2 code running at Stanford uses 576 byte packets whenever a gateway is involved. -Jeff 23-Oct-84 12:46:01-PDT,518;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Oct 84 12:45:57-PDT Date: Tue 23 Oct 84 12:29:15-PDT From: Bill Subject: Re: Sun Gateways To: mogul@SU-NAVAJO.ARPA cc: Lougheed@SU-SIERRA.ARPA, nethax@SU-GREGORIO.ARPA, su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Jeff Mogul " of Tue 23 Oct 84 11:27:00-PDT The pdp-11 gateway will handle 576 bytes. Bill PS>In fact it has 1024 byte buffers... ------- 23-Oct-84 17:23:52-PDT,776;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Oct 84 17:23:38-PDT Received: ID ; Tue 23 Oct 84 20:24:40-EDT Date: Tue 23 Oct 84 20:24:40-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: 5.4 & AP#8 - a warning To: TOPS-20@SU-SCORE.ARPA In order to save others the confusion that I went through, here's a little hint on merging the new Autopatch version #8 release: the AP#8 MONSYM.MAC is NOT on the source tape for AP#8. It is, however, on the first saveset of the 5.1 Autopatch Tape #8 with all of the other Autopatch stuff that is distributed to all Autopatch customers, not just the source customers. This should save a bit of thrashing on the part of others out there... --Vince ------- 24-Oct-84 06:36:34-PDT,538;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Oct 84 06:36:25-PDT Date: Wed 24 Oct 84 09:38:20-EDT From: Rich Cower Subject: DEC 2050 To: tops-20@SU-SCORE.ARPA 2050 being offered by the GSA - for details see the Automatic Data Processing Resources Availability List, July 17 1984, Page 19. The item number is W84-95-8. Call 202-566-1284 if you want more information. They should be able to point you in the right direction. ..rich ------- 24-Oct-84 10:52:33-PDT,808;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Oct 84 10:52:21-PDT Date: Wed 24 Oct 84 13:40:14-EDT From: Kevin Paetzold Subject: chain letters To: tops-20@SU-SCORE.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 Once again the infamous network chain letters are circulating through the network. They are circulating through DECs engineering net to a very great extent. From the address lists it appears it is also circulating around the arpanet. It would probably be a good idea if we took steps to curtail this round of the chain letter before it gets any worse. I have allready taken steps to curtail it in DEC. You might want to do the same.... ------- 24-Oct-84 13:04:10-PDT,786;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Oct 84 13:03:54-PDT Date: Wed, 24 Oct 84 20:04 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Autopatch EXEC question To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: TOPS-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 In the EXEC sources, at least since tape 7, there is a symbol VI%DEC which has to do with decimal version numbers. But VI%DEC is not defined anywhere that I can find. Can someone tell me (1) what the value of VI%DEC should be, and (2) where to find the file (MONSYM?) that defines it? - Sam - ------- 24-Oct-84 14:04:58-PDT,1832;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Oct 84 14:04:36-PDT Date: 24 Oct 1984 1703-EDT From: Alan H. Martin To: TOPS-20 at SCORE DTN: 231-4528 Mail-Stop: MR1-2/L14 Office-location: "MR1-2/M8 (By the cat posters)" Subject: Re: Autopatch EXEC question Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12058067505.25.659.67596 at DEC-MARLBORO> Regarding: Message from SAMUELSON%LLL@LLL-MFE.ARPA of 24-Oct-84 1616-EDT VI%DEC was defined by edit 967 to the 5.1 EXEC (PCO 20-EXEC-208) in answer to SPR 20-16854. The answer appears on pages 3-19 and 3-20 in the 1-Sep-83 DECSYSTEM-20 Software Dispatch. Unfortunately, the actual code changes were not published there. I am told that there is a known problem with this symbol being undefined on Autopatch tape 7. This was supposedly corrected on Autopatch tape 8 by shipping the correct versions of universal file(s) as part of the base-building software. Tape 8 for KL Tops-20 machines was "released" on 17-Sep-84. Here are the definitions of the VI%??? symbols from some flavor of a release 6.0 MACSYM.MAC. I can't swear that this is exactly what appears in field image software, so caveat programmer: ;MASKS FOR THE ABOVE VI%WHO==:7B2 ;Customer edit code VI%MAJ==:777B11 ;Major version number VI%MIN==:77B17 ;Minor version/update VI%EDN==:377777B35 ;Edit number VI%DEC==:1B18 ;Decimal Note that VI%DEC stole a bit from VI%EDN. If you are encountering a problem in building software from the Autopatch tapes, and the above does not clear things up, please submit an SPR detailing the problem. I don't work on the EXEC or Autopatch, so I regret if this mail hasn't gotten to the bottom of things. /AHM/THX -------- 24-Oct-84 19:04:21-PDT,1406;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Oct 84 19:04:11-PDT Date: 24 Oct 1984 2204-EDT From: Bob Longo To: SAMUELSON%LLL at LLL-MFE cc: TOPS-20 at SU-SCORE Mail-Stop: LAO Phone: 213-417-4240 Subject: Re: Autopatch EXEC question Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12058122397.22.355.42132 at DEC-MARLBORO> Regarding: Message from SAMUELSON%LLL@LLL-MFE.ARPA of 24-Oct-84 1616-EDT VI%DEC, the bit that indicates if the edit number is decimal or octal, is defined in MACSYM. Unfortunately, the source was not sent on the Autopatch-7 tape as it should have been. Below is a FILCOM of the new (AP7) vs. distribution MACSYM. File 1) A1:[4,243] created: 1457 22-Feb-1982 File 2) A2:[4,20] created: 0956 07-Jul-1983 1)1 ; UPD ID= 82, SNARK:<5.UTILITIES>MACSYM.MAC.43, 22-Feb-82 17:57:38 by MURPHY **** 2)1 ;Edit 2987 to MACSYM.MAC by WEETON on Thu 7-Jul-83, for SPR #16854 2) ; Add new bit to make INFO VER work with decimal numbers 2) ; UPD ID= 82, SNARK:<5.UTILITIES>MACSYM.MAC.43, 22-Feb-82 17:57:38 by MURPHY ************** 1)1 VI%EDN==:777777B35 ;Edit number 1) ;ADDED VI%XXX **** 2)1 VI%EDN==:377777B35 ;Edit number 2) VI%DEC==:1B18 ;[2987]radix of version number 2) ;ADDED VI%XXX ************** Hope this is of some help. -Bob -------- 24-Oct-84 20:53:57-PDT,552;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Oct 84 20:53:46-PDT Date: 24 Oct 1984 20:49:36 PDT Subject: Re: DEC 2050 From: Bob Knight To: Rich Cower , tops-20@SU-SCORE.ARPA In-Reply-To: (Message from "Rich Cower " of Wed 24 Oct 84 09:38:20-EDT) Before everybody goes off and tries to freeze that item, New Mexico Tech has taken delivery of it and has it up and running. The early bird... Bob ------- 25-Oct-84 15:18:13-PDT,1011;000000000000 Mail-From: G.FUSSELL created at 25-Oct-84 15:18:01 Date: Thu 25 Oct 84 15:18:01-PDT From: Carl Fussell Subject: looking for information... To: tops-20@SU-SCORE.ARPA Address: Santa Clara University I need to find out some information about throughput and was hoping someone on the list might know... We have an RP20 disk connected through a DX20 to a 2060 (KL10E). I had heard that although the bandwidth of the RP20 was just over 1 MB/sec, that the DX20 was less(?) and that it was the real bottleneck on this subsystem. Is that true? If it is not, then I would think then I would think that one could say that the RP20/DX20 was capable of about 1/2 the performance of say an RP07 with 2.2 MB/sec band. I also realize that average access time (at least seek and latency) will affect any comparisons but I do not know what they are for the above drives. Any information/enlightenment would sure be appreciated. Thanx... Carl Fussell ------- 26-Oct-84 09:56:38-PDT,1243;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 26 Oct 84 09:56:22-PDT Date: 26 Oct 84 12:56:18 EDT From: Charles Hedrick Subject: how to trash a file system To: tops-20@SU-SCORE.ARPA For the second time, a CE has fallen into a sort of interesting trap, and trashed our file system. It happens this way: CE dismounts our packs, mounts the KLAD pack, and starts running diagnostics. He finds out everything he wants to know. He then gets distracted and goes to work on a VAX. When he comes back, he forgets that the diagnostic is still running. He halts the 11, takes down the KLAD pack, and puts up our packs. When we try to boot, we find that PS: is no more. What happened is that the diagnostic was running on the 10 side. Stopping the 11 didn't affect it. Apparently it isn't bright enough to notice when the disks are changed, so it merrily goes on its way scribbling all over PS:. Moral of the story: make sure that both the 10 and the 11 are halted before putting your packs back on. Many older CE's have had enough strange happenings that they always clear core on the 10 before turning over the machine to the customer. ------- 26-Oct-84 10:11:42-PDT,911;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Fri 26 Oct 84 10:11:10-PDT Date: Fri, 26 Oct 84 17:11 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: how to trash a file system To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: HEDRICK@RUTGERS.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Charles Hedrick " of Fri 26 Oct 84 12:56:18-PDT Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 Sounds like you have found one of the really useful things that LIGHTS on the memory were good for. We are running AMPEX CORE on our 1090 running TOPS-20. We can see in the memory lights if the CPU is doing anything. Some times (not often) that is actually useful information. - Sam - ------- 26-Oct-84 10:38:56-PDT,609;000000000000 Return-Path: Received: from USC-ECLC.ARPA by SU-SCORE.ARPA with TCP; Fri 26 Oct 84 10:38:36-PDT Date: Fri 26 Oct 84 10:39:17-PDT From: mark thompson Subject: Re: how to trash a file system To: SAMUELSON%LLL@LLL-MFE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "SAMUELSON%LLL@LLL-MFE.ARPA" of Fri 26 Oct 84 10:27:11-PDT Organization: University of Southern Calif. Computing Services Phone: (213) 743-4800 The moral of the story is to have a system person watch the CE. Preferably, your most paranoid system person. -mark ------- 29-Oct-84 04:56:18-PST,781;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Oct 84 04:56:07-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA06341; Mon, 29 Oct 84 13:57:39 -0100 Date: 29 Oct 1984 13:46-EST From: T S Lande Subject: TeX and Laser Graphics 800 To: TOPS-20@SU-SCORE Message-Id: <467902001/bassen@oslo-vax> I have two questions concerning TeX on TOPS-20: 1. Does anybody know where to obtain a TeX-distribution for TOPS-20? In case I have a choice which one is the best? 2. Are anybody using Laser Graphics 800 on TOPS-20 as TeX output-medium? I am interested in experience, advices and software. Tor Sverre Lande Institute of Informatics University of Oslo P.o. Box 1080, Blindern N-316 Oslo, Norway 30-Oct-84 09:47:52-PST,2402;000000000000 Mail-From: MRC created at 30-Oct-84 09:47:31 Date: Tue 30 Oct 84 09:47:31-PST From: Mark Crispin Subject: DECUS videotaping To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As many of you know, ever since last DECUS I have been working on trying to get permission to videotape the 36-bit historical sessions for posterity. My original plans were to bring professional-quality equipment (3/4" U-MATIC and 3-tube camera, if you know what that means) and make copies for distribution at whatever price recovers my expenses. Clive Dawson and Leslie Maltz seem to have spent some time trying to get the needed permissions. A few weeks ago, I was told that DEC has decided to videotape those sessions itself. Given that information, I was merely going to bring a Beta Porta-pak to have a "backup copy." I suspect my proposal had prompted this; in any case, I received a call from Judy Arsenault at DECUS that my request for permission had been denied this morning. According to Arsenault, the reason for denial is that allowing videotaping will open up a "Pandora's Box" where "anybody" could make videotapes of sessions. When I pressed her for a further explanation of what the problem, she implied that videotaping was "unprofessional" and then clammed up and passed the buck to the DECUS Executive Committee. This, by the way, is the same individual who was personally responsible for holding up the ARPANET BOF a couple of years ago when the TCP/IP transition required all of us to get together with DEC. In any case, I am going to try to contact the DECUS Executive Committee personally and see what the problem (if Arsenault actually did ask the Executive Committee instead of denying permission on her own initiative) really is. However, it looks bad right now. I have no idea what the distribution of the DEC copy -- if any -- will be. Nor do I have any idea what kind of equipment they will use; they had *better* use something more than a Portapak!!! If it turns out that the record of these historically important sessions is lost or buried forever (having DEC record it is like asking Idi Amin to write about atrocities in Uganda), you'll know what happened. -- Mark -- ------- 30-Oct-84 21:14:08-PST,1677;000000000000 Mail-From: MRC created at 30-Oct-84 21:14:00 Date: Tue 30 Oct 84 21:14:00-PST From: Mark Crispin Subject: news from Mars To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As of last night, 10/29/84, TOPS-20 ran on the Systems Concepts' SC-30M processor (a.k.a. Mars I). Both disk and IBM tape service work; it was tested with a Memorex drive (a DEC RP06 without the DEC controller) and both created its own filesystem and successfully accessed DEC RP06 packs with KL-created RP06 filesystems. Benchmarking has not yet been done. The microcode wasn't ready to even start testing TOPS-20 until last Friday. It was on Friday that TOPS-20 first read home blocks. On Monday (I took the weekend off) the disk code was working. Today was identifying the things in the microcode that needed to be done. It turns out that *lots* of stuff on TOPS-20 actually uses the EXTEND instruction, as well as subtle bugs in ADJBP and the pager. This should be taken care of in a few days. This is, by the way, all for Model A simulation. I don't know when Model B support will be done. Due to the lack of benchmarking, I can't really comment, but a LINK of the monitor under TOPS-20 does seem to be somewhat faster than a KL. It is certainly much faster than a LINK under TOPS-10. I imagine that they'll be ready to have people try running real test programs on the machine in a few days. I'm now turning to other pursuits as an independent consultant. Much of it, including portable mailsystem work, is quite exciting! ------- 31-Oct-84 05:26:29-PST,460;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 31 Oct 84 05:26:21-PST Received: ID ; Wed 31 Oct 84 08:27:31-EST Date: Wed 31 Oct 84 08:27:30-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: Re: news from Mars To: MRC@SU-SCORE.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Wed 31 Oct 84 00:58:43-EST Go for it, Systems Concepts! ------- 1-Nov-84 02:18:25-PST,3455;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 1 Nov 84 02:18:14-PST Date: 1 Nov 1984 02:19-PST Sender: BILLW@SRI-KL Subject: [Richard Garland : VENUS an...] From: BILLW@SRI-KL To: tops20@SCORE Message-ID: <[SRI-KL] 1-Nov-84 02:19:38.BILLW> For your amusement. Looks like its about as fast as a KL. Oh wow. Begin forwarded message Date: Wed 31 Oct 84 23:51:18-EST From: Richard Garland To: Info-VAX@SRI-KL.ARPA Cc: OC.GARLAND%CU20B@COLUMBIA.ARPA Subject: VENUS announcement DEC announcement: Oct. 31, 1984 I was at the official DEC announcement today of the "VAX 8600" code named "VENUS". This was announced simultaneously in NY (where I was) Marlboro Mass. (where it is being built) and I think 180 other cities world-wide. For completeness, DEC also announced the VAXstation-1. This is a VAXstation plugged into a microVAX which was actually announced in the trade press 2 weeks ago. I was dissapointed the low end announcement wasn't the microVAX-2 so I skipped listening to most of the VS-1 information. The VAX 8600 - "More than a mainframe" (That catch phrase was spoken about a dozen times.) This is the long awaited VENUS. The basic details as I jotted them down and from the glossy handout: Basic cycle time: 80 nsec Control store: 8k x 86 bits Data path width: 32 bits 4 stage instruction pipeline Memory Cache: 16k write-back Memory bandwidth: 28 MegByte/sec (private bus) IO bandwith (aggregate) 20 MegByte/sec (with 2 SBI's) FPA 4.43 MegWhetstones/sec single Memory limit 32 MegByte in basic box (256 k chips) quoted speed 4.2 x VAX 11-780 Console subsystem: PDP-11 RL02 diagnostics, environmental monitoring, etc. while main processor is running. Size: Same as basic 780. Quieter, slightly less power Availability: First customer ship April 1985 "Widely available" Mid-summer 1985 Packages: 2 were announced: #1 - Cluster Starter: basic box Star coupler HSC cost $500k B.M.C. $1659 (you add tape drive and disk drive: $578k) # 2 - Cluster upgrade: basic box cost $450k B.M.C. $1492 Basic box in above packages: 8600 CPU FPA 12 MegByte memory SBI with: CI UBA with: 1 BA11 box with: 1 DMF32 1 DEUNA Console subsystem with RL02 VMS and DECnet licenses bundled in I believe most figures are accurate but I may have missed some. The basic monthly maintenance charge seems particularly low, either indicating a real bargain in operating cost, or indicating I got the numbers wrong. Check with your salesman obviously. DEC indicated that other packages would be forthcomming but that these initial packages were to satisfy large end customers first. Much emphasis was placed on clusters as a means to obtain "More than a mainframe" total system performance. They kept speaking of 4, 8, 12 etc Mips systems (meaning clusters with 1, 2, 3 etc. 8600's). They stated clusters had advantages over tightly coupled systems such as the 782 and various competitor's machines. No explanation was given for the choice of "8600" except to indicate it was a new class of systems. It does not stand for "twice a 4300". Rg (I have no connection with DEC except as a customer.) ------- ----------------- End forwarded message 1-Nov-84 08:18:33-PST,707;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 1 Nov 84 08:18:23-PST Date: 1 Nov 1984 08:17:09 PST Subject: VENUS From: Bob Knight To: tops-20@SU-SCORE.ARPA I was at the announcement in Albuquerque. Yawn. If I want a UNIX box, I'll look elsewhere. I don't need a VMS box. The most amusing thing about it was when the marketing clone said, "And it's a great timesharing machine too. We've benchmarked it against a VAX DECSYSTEM-2060, which, as some of you may know, is a 36 bit computer we've marketed for several years now and the 8600's three times as fast." I left. Bob ------- 2-Nov-84 11:23:52-PST,1298;000000000000 Mail-From: BOSACK created at 2-Nov-84 11:23:24 Date: Fri 2 Nov 84 11:23:24-PST From: Len Bosack Subject: Ethernet for the DEC20 To: Tops20@SU-SCORE.ARPA At Stanford, we have developed an Ethernet interface for the -20. We have been using this device for about 2 years now on our 10 machines. We have had several requests asking if we could make this device available outside of Stanford. After surmounting several legal and institutional barriers, we have arranged for the devices to be made available through a third party. As many of you are aware, Digital is in the process of producing an Ethernet interface (NI-20) of its own devise. We are making our device available to aid those who have a more pressing need for Ethernet than can be satisfied by Digital. As they will be fabricated in modest quantities, it is expected that these devices will be more expensive than the NI-20. We expect to provide the first devices this month to Washington, Ohio State, Weslyan, and U. of Chicago. Additional devices will be available at roughly 4-6 week intervals thereafter. If you have a pressing need for Ethernet on your -20, send me mail asking for further information. Len Bosack Director, Stanford Computer Science Computer Facilites ------- 2-Nov-84 13:00:10-PST,796;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 2 Nov 84 12:59:53-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2645729806584183@MIT-MULTICS.ARPA>; 02 Nov 1984 15:56:46 est Date: 02 Nov 84 14:20 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA Subject: VENUS versus MARS Message-ID: <76990@QZCOM> In-Reply-To: <[SRI-KL] 1-Nov-84 02:19:38.BILLW> Does anyone know anything about price/performance of the VENUS versus the MARS CPU-s? 2-Nov-84 13:47:12-PST,717;000000000000 Mail-From: MRC created at 2-Nov-84 13:46:59 Date: Fri 2 Nov 84 13:46:59-PST From: Mark Crispin Subject: Re: VENUS versus MARS To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" of Fri 2 Nov 84 14:20:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) My belief is that Mars will be priced to be price/performance competitive with Venus. That is not difficult; Venus is disgustingly overpriced. ------- 5-Nov-84 13:32:26-PST,1127;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 5 Nov 84 13:31:47-PST Date: 5 Nov 84 16:30:39 EST From: Charles Hedrick Subject: problem in TCPBBN, leads to TVTNTV bughlt To: tops-20@SU-SCORE.ARPA cc: paetzold@DEC-MARLBORO.ARPA It appears that if you pass an illegal TVT to STAT%, the system may crash. .STAT calls CHKARG. CHKARG does calls CHKTVT to see whether the terminal number is legal. If not, it returns an error to the user. If so, CHKARG then calls TVTCHK. TVTCHK then does a somewhat more strict test to see whether the number is legal. If not, it bughlt's, TVTNTV. So if the argument passes the first test and fails the second, the system crashes. The obvious fix is to make CHKTVT do the same test as TVTCHK. The following patch adds 2 lines. I have tested it with this code patched in using MDDT. CHKTVT:: ACVAR ;GET AN AC TO WORK WITH cail t2,nlines ;[137] Legal terminal line number? retbad ;[137] No good LOAD W1,TTSTY,(T2) ;GET LINE TYPE FOR THIS LINE CAIE W1,TT.TVT ;IS IT A TVT? ------- 6-Nov-84 15:26:19-PST,1528;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Tue 6 Nov 84 15:26:01-PST Date: 06 Nov 84 15:26:24 PST (Tue) Message-ID: <376.468631584@uci-750a> To: tops-20@su-score Subject: Comparing 750s and 2020s Reply-To: raj@uci-750a From: Richard Johnson Received: from Localhost by UCI-750a; 06 Nov 84 15:26:39 PST (Tue) We have two 2020s here and lots of Vax 750s. The 750s are on a local network and the 2020s are not (basically because Dec makes no provisions for 2020 ethernet connections and we don't have source). Lots of people here are looking at purchasing 750 class machines and selling one of the 2020s. I have heard lots of talk on this bboard and other places about 20s being faster than 750s. What we would like to know is if anyone has figures on the speed of a 2020 running Tops-20 4.1 as compared to a 750 running Unix 4.2BSD. Also raw speed comparisons would be interesting. I have been told there are large speed differences between 2020s and larger 20s so please make sure any comparisons are specifically about 2020s. I read this bboard regularly so replies can be sent either directly to me or to the bboard (if you believe others are really interested in this). Thank you for any information you can furnish. ------------------------------------------------------------------------ Richard Johnson raj@uci (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) 8-Nov-84 20:20:45-PST,2286;000000000001 Return-Path: Received: from decwrl.ARPA ([26.7.0.16].#Internet) by SU-SCORE.ARPA with TCP; Thu 8 Nov 84 20:20:39-PST Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34) id AA17914; Thu, 8 Nov 84 20:22:03 pst Message-Id: <8411090422.AA17914@decwrl.ARPA> Date: Thursday, 8 Nov 1984 20:21:02-PST From: budne%mrfort.DEC@decwrl.ARPA (Phil Budne) To: mrc@su-score Subject: New TOPS-20 features (6.0) Well it looks like some long standing pains in my butt in TOPS-20 have been fixed. From recent MONSYM.MAC: ; UPD ID= 604, SNARK:<6.UTILITIES>MONSYM.MAC.263, 9-Oct-84 10:21:04 by GLINDELL ;Add ND%LGL and ND%RCH .... .NDVFY==:15 ;VERIFY NODE NAME .NDFLG==:1 ;FLAGS RETURNED BY MONITOR ND%EXM==:1B0 ;NODE SPECIFIED EXACTLY MATCHES A KNOWN NODE ND%LGL==:1B1 ;NODE NAME IS A LEGAL NODE NAME ND%RCH==:1B2 ;NODE IS REACHABLE ND%RUK==:1B3 ;Reachability of node is unknown (out of area) .... ; UPD ID= 620, SNARK:<6.UTILITIES>MONSYM.MAC.272, 28-Oct-84 11:26:32 by PRATT ;TCO 6.1.1022 - Add NTINF% jsys and it's symbols ... DEFJS NTINF,632,MSEC1 ;NETWORK INFORMATION JSYS ... ;NTINF% JSYS .NWABC==:0 ;ARGUMENT BLOCK COUNT (INCLUDES THIS WORD) .NWFNC==:1 ;FUNCTION CODE .NWRRH==:0 ; RETURN REMOTE HOST INFORMATION .NWLIN==:2 ;TTY DESIGNATOR, JOB # OR -1 FOR THIS JOB .NWNNP==:3 ;BYTE POINTER TO STORE NODE NAME .NWTTF==:4 ;TERMINAL TYPE AND FLAGS ; B0-B8 FLAGS NW%NNN==:1B0 ; NO NODE NAME KNOWN ; B9-B17 NETWORK TYPE NW%NNT==:0 ; NON NETWORK TERMINAL NW%TCP==:1 ; INTERNET TCP NW%DNA==:2 ; DECNET NW%LAT==:3 ; LAT ; B18-B35 LINE TYPE NW%UND==:0 ; UNDEFINED TERMINAL TYPE NW%FE==:1 ; FRONT END TERMINAL NW%PT==:2 ; PSUEDO TERMINAL NW%MC==:3 ; NRT NW%TV==:4 ; TVT NW%CH==:5 ; CTERM NW%LH==:6 ; LAT .NWNNU==:5 ;NODE NUMBER WORD 1 .NWNU1==:6 ;NODE NUMBER WORD 2 So SYSTAT and FINGER can *FINALLY* do the right thing! I'm not sure what the actual behavior of the .NDVFY stuff is, I'll have to beat on it some. ------- 9-Nov-84 12:56:09-PST,884;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Fri 9 Nov 84 12:55:52-PST Date: 09 Nov 84 12:56:20 PST (Fri) Message-ID: <376.468881780@uci-750a> To: tops-20@su-score Subject: 2020s vs. 750s Reply-To: raj@uci-750a From: Richard Johnson Received: from Localhost by UCI-750a; 09 Nov 84 12:56:34 PST (Fri) I believe I have enough information about 750s vs. 2020s now. It appears as though a 2020 is about 1.1 - 1.3 times a 750. That's not really much difference. The ease of networking, availability of peripherals, etc. on 750s more than makes up for the difference. Thanks to all who responded. ------------------------------------------------------------------------ Richard Johnson raj@uci (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) 9-Nov-84 15:06:25-PST,551;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 9 Nov 84 15:06:13-PST Received: ID ; Fri 9 Nov 84 18:07:19-EST Date: Fri 9 Nov 84 18:07:17-EST From: Eric.Crane@CMU-CS-C.ARPA Subject: Connecting a QMS 2400 To: Tops-20@SU-SCORE.ARPA Has anyone out there connected a QMS 2400 up to a 20? I am looking for the ability to do font downloading and all of the fun stuff that you can do with a QMS from GALAXY. - Eric Crane Carnegie-Mellon University Erc@Cmu-Cs-C ------- 11-Nov-84 02:02:12-PST,1444;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sun 11 Nov 84 02:01:58-PST Date: Sun 11 Nov 84 02:02:53-PST From: David Roode Subject: 2020's To: raj@UCI-750A.ARPA cc: TOPS-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 You could add your own devices to the TOPS-20 if you had source code. Since DEC is abandoning 20's, they ought to be willing to give you the source code you need to maintain existing systems for free. They have not yet been known to do this yet but it is conceivable. I suspect you have source code for Unix which you use on your 750's. The full benefits of a 20 are not available on a 2020, so I can understand your desire to move from them. You might consider one of the alternate source 20 replacements. Tymshare has a system which is roughly 5 times the power of a 2020 for under twice the price (and becoming cheaper). Systems Concepts is working on an even more powerful system that will be similarly (or more) cost effective. Space requirements are about the same as a 2020 in Tymshare's case, and much less for Systems Concepts. If you do decide to purchase 750's to replace your 2020's, do not overlook DEC's obligation to make you a good deal, since you would not feel the same need to make the change if not for their actions. They have indicated an inclination to take this into consideration. ------- 11-Nov-84 11:14:54-PST,1152;000000000000 Mail-From: MRC created at 11-Nov-84 11:14:47 Date: Sun 11 Nov 84 11:14:47-PST From: Mark Crispin Subject: 2020's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am looking to buy a 2020 system in the $10K-$20K range (depends upon what peripherals are offered with it). It must have a full 512K of memory and be in good condition. I do not think any of the existing 36 bit alternatives are very cost-attractive at the present time. A 2060 system should not cost more than $100K now. Tymshare's machine, which is about 40% of a KL, should be more like $40K, not the $300K I was last quoted. A machine of the power of Systems Concepts' SC-30M should go for no more than $200K; I don't know what it will actually sell for but I suspect it will be for more than that. DEC is aggressively dropping the 10/20 line right now. Already, customers are being told to buy spares now, as they won't be available in 1-2 years. Given that sort of situation, prices should be MUCH lower. ------- 13-Nov-84 12:26:37-PST,547;000000000000 Return-Path: Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Tue 13 Nov 84 12:26:27-PST Date: Tue 13 Nov 84 12:27:38-PST From: WILLIAMS@EDWARDS-2060.ARPA Subject: Public domain ADA compiler for the 20 To: tops-20@SU-SCORE.ARPA To all comers: Is there now, or has there ever been, an ADA compiler available for the DEC-20? Is it public domain, or is it for sale? I'd love to hear from any and all with info... Thanks, Marc (WILLIAMS@EDWARDS-2060) ------- 16-Nov-84 03:56:36-PST,1210;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 16 Nov 84 03:56:27-PST Date: Wed 14 Nov 84 20:24:59-EST From: Judy Hall Subject: Crash analysis session at DECUS To: tops-20@SU-SCORE.ARPA I am scheduled to give a TOPS-20 crash analysis session at DECUS. I'd like to get some idea of how many people might attend, and what you'd like to hear about. I'm inclined to concentrate on the CI-related stuff, since that's what I've been working on lately, but I'm open to suggestion. Kevin will be there, too, so you can ask him your favorite ARPA question. This session was originally scheduled for Monday night at 9:00 (yawn). It's now on Tuesday evening at 7:00. (The reception starts at 8:00.) We're going to be in the machine room, using a live system and a monitor, so you can watch all my mistakes. If this interests you, please let me know what you want to hear about. It would help if you gave me some indication of your background, too. Otherwise, I'll assume that people are experienced at analyzing 5.1 crashes, and just want to learn about how release 6 is different. Judy Hall ------- 16-Nov-84 15:28:32-PST,1807;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 16 Nov 84 15:28:15-PST Date: 16 Nov 1984 15:27 PST (Fri) Message-ID: <[SRI-NIC].IAN.16-Nov-84 15:27:18> From: Ian Macky To: tops-20@score Subject: OPENF bug Bug: OPENF updates the last-writer, write date & time, and write-count before trying to get an OFN on the file. If it can't get an OFN (say because of invalid simultaneous access), the writer information remains updated. Fix: Just move the writer-information code down to after an OFN has been gotten. The writer stuff was done in a fall-through right before OPENF0; you can just make a subroutine out of it and call it... . . . BP$004: ;BREAKPOINT FOR OPEN EXISTING FILE ;SEE ASSUMPTIONS FOR BP$003 HRLM A,FILOFN(JFN) OPENF3: TQO ;NO WINDOWS YET, AND ALLOW SIZE CHANGE TQNN ;OPENING FOR WRITE? IFSKP. ;IF SO MOVE B,OPNFDB ;GET FDB ADDRESS SETONE FB%WNC,.FBCTL(B) ;AND SET WRITE IN PROGRESS BIT ---> CALL UPDWTR ;[NIC5737] And update the file's writer &tc ENDIF. . . . UPDWTR: TRNE F1,OF%PDT ;SUPPRESS REFERENCE UPDATE? RET ;YES MOVE A,OPNFDB ;No, so do it. LOAD B,FBVER,(A) ;CHECK FDB VERSION CAIGE B,1 ;LATER THAN VER #1 JRST [MOVE B,JOBNO ;VER 0 - SET DIR # HRRZ B,JOBDIR(B) STOR B,FBLW0,(A) ;INTO FDB JRST DSKOPB] ;CONTINUE MOVEI B,USRNAM ;POINT TO USER NAME MOVEI C,.FBLWR ;UPDATE LAST-WRITER CALL INSUNS ;INSERT NAME STRING MOVE A,OPNFDB ;RESTORE FDB ADDRS DSKOPB: MOVSI B,1 ADDM B,.FBCNT(A) ;COUNT NUMBER OF WRITES CALL UPDDTM ;GET TIME OF DAY AND UPDATE DIR TIME MOVE B,A ;SAVE TIME MOVE A,OPNFDB ;GET BACK FDB ADR CAME B,[-1] ;TIME SET YET? STOR B,FBWRT,(A) ;SET DATE OF LAST USER WRITE RET 17-Nov-84 10:10:37-PST,3811;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sat 17 Nov 84 10:10:21-PST Date: 17 Nov 84 13:10:11 EST From: Don Subject: IPHOST speedup To: Tops-20@SU-SCORE.ARPA Ever wish IPHOST didn't take so long to do the first NAME command? I've hacked it to write the tables it builds then to SYSTEM:HOSTS.PMAP.n (where n matches the generation of the latest SYSTEM:HOSTS.TXT). Any command which forces a reload of IPHOST's internal tables (e.g., it's RELOAD command), rewrites ths .PMAP file. The file is automatically created if you have the right access, need it, and it doesn't exist. (My code assumes that the latest version of SYSTEM:HOSTS.TXT is currently loaded.) The saving here is 15 cpu seconds. Difference file follows. Don File 1) IPHOST.MAC.5,15-Nov-84 12:55:09 File 2) IPHOST.MAC.3,21-Sep-84 13:31:56 1)7 fstpag==.loc ;remember locations 1) PG UHSTNM,4 ;USER HOST NAME TABLE **** 2)7 PG UHSTNM,4 ;USER HOST NAME TABLE ************** 1)7 lstpag==.loc 1)8 SUBTTL GHT Building Data Structure Definitions **** 2)8 SUBTTL GHT Building Data Structure Definitions ************** 1)10 hstjfn: z ;jfn for SYSTEM:HOSTS.PMAP 1) hbnfrc: z ;-1 if forcing creation of HOSTS.PMAP 1) PSHFRK: Z ;FORK HANDLE FOR PUSHED EXEC **** 2)10 PSHFRK: Z ;FORK HANDLE FOR PUSHED EXEC ************** 1)30 setom hbnfrc ;force creation/update of file 1) JRST HSTLD2 ;AND JOIN LOADING CODE **** 2)30 JRST HSTLD2 ;AND JOIN LOADING CODE ************** 1)30 setzm hbnfrc ;don't force creation/update of file 1) HSTLD2: ;HERE TO FORCE A NAME LOAD 1) stkvar <> ;temporary buffer space 1) hstl2a: seto t1, ;be sure nothing is mapped 1) move t2,[.fhslf,,fstpag/pgsiz] 1) move t3,[pm%cnt!</pgsiz>] 1) pmap 1) jsysf 1) skipe t1,hstjfn ;toss old jfn if there is one 1) closf 1) ercal [ move t1,hstjfn 1) rljfn 1) erjmp r 1) ret] 1) setzm hstjfn 1) movx t1,gj%sht!gj%old ;get jfn for hosts.txt 1) hrroi t2,[asciz \system:hosts.txt\] 1) gtjfn 1) erjmp hstldx ;can't get file - use slow method 1) move t2,t1 ;find out it's generation number 1) hrroi t1,tmpbuf 1) movx t3,fld(.jsaof,js%gen) 1) jfns 1) jsysf 1) move t1,t2 ;toss jfn 1) rljfn 1) jsysf 1) hrroi t1,tmpbuf ;convert from text to number 1) movei t3,^d10 1) nin 1) jsysf 1) movx t1,gj%sht!gj%flg ;now get jfn on .pmap file 1) hrr t1,t2 1) hrroi t2,[asciz \system:hosts.pmap\] 1) gtjfn 1) erjmp hstldx ;can't get file - use slow method 1) movem t1,hstjfn ;save jfn 1) hrrzs t1 ;see if file exists 1) move t2,[1,,.fbctl] 1) movei t3,t3 1) gtfdb 1) jsysf 1) txne t3,fb%nxf ;if file doesn't exist 1) setom hbnfrc ; we're writing it now 1) movx t2,of%rd ;get read access 1) skipe hbnfrc ;unless we need to write it 1) movx t2,of%rd!of%wr ; then add write 1) openf 1) erjmp hstldx ;can't open file - use slow method 1) hrlzs t1 ;map file to memory 1) move t2,[.fhslf,,fstpag/pgsiz] 1) move t3,[pm%cnt!pm%rd!pm%wr!</pgsiz>] 1) pmap 1) jsysf 1) skipe hbnfrc ;if we're not writing file 1) ifskp. 1) setone f%name ;note names are loaded 1) setzro f%hsob ;turn off bitch flag 1) ret ;we're done 1) else. 1) call hstldx ;otherwise load names, creating/updating file 1) jrst hstl2a ;then go back and just read file 1) endif. 1) hstldx: 1) SETZRO F%DIDB ;TURN OFF THE DID BITCH FLAG **** 2)30 HSTLD2: ;HERE TO FORCE A NAME LOAD 2) SETZRO F%DIDB ;TURN OFF THE DID BITCH FLAG ************** 1)30 setzm hbnfrc ;not forced write anymore 1) TMNN F%DIDB ;DID WE BITCH? **** 2)30 TMNN F%DIDB ;DID WE BITCH? ************** ------- 20-Nov-84 17:27:48-PST,658;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Nov 84 17:27:35-PST Date: 20 Nov 84 20:33:48 EST From: Charles Hedrick Subject: MIDAS bug To: tops-20@SU-SCORE.ARPA Does anyone have source to Midas? Our Common Lisp was giving incorrect results for MINUSP. It turns out that the code jrst [docar o1,o1 ? jrst minusp] was assembling into jrst [garbage] When I replace docar o1,o1 with move o1,(o1) [which is its expansion] the code is correct. I would like to fix this problem, since I find the concept of an assembler that produces bad code very scary. ------- 20-Nov-84 17:40:07-PST,658;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Nov 84 17:39:53-PST Date: 20 Nov 84 20:43:01 EST From: Charles Hedrick Subject: Would Common Lisp users please identify yourselves? To: tops-20@SU-SCORE.ARPA I have managed to lose track of the places to which I have sent copies of Common Lisp. Could those sites that have a copy please send me computer mail addresses for the person who is responsible for keeping your version up to date? I have a bug fix, and within the next couple of months there will be new releases, as we start distributing the compiler. ------- 20-Nov-84 23:46:56-PST,2586;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Nov 84 23:46:45-PST Date: Tue 20 Nov 84 23:45:44-PST From: Ken Harrenstien Subject: Re: MIDAS bug To: HEDRICK@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: Message from "Charles Hedrick " of Tue 20 Nov 84 20:33:48-PST MIDAS has been around for a long time, and while it may yet have bugs, this is not one of them. Hedrick's problem sounds like DOCAR is a macro which someone either wrote or used improperly. He implies that DOCAR X,Y becomes MOVE X,(Y). Let's look at the bad line: JRST [ DOCAR O1,O1 ? JRST MINUSP] Now, Hedrick claims this produced something like JRST [ ,,254000] JRST has the value (254000). Somehow the JRST MINUSP got its halves reversed. Now this is just what MIDAS parentheses do, and the DOCAR macro obviously has parentheses (so as to achieve indexing). What this immediately suggests to me is that the macro argument reader was reading too much of the line. Thus the first argument was "O1" and the second argument was probably "O1 ? JRST MINUSP". So, let us guess that the actual code produced by the macro (which Hedrick could have seen by assembling the code with the (LL) switch) looked like this: JRST [ MOVE O1,(O1 ? JRST MINUSP)] ; Macro expansion This will reduce to JRST [MOVE O1,(JRST MINUSP)] ; Expression evaluation which is the same as JRST [+] The mistake here (which others have made, so don't feel too bad) is assuming that "?" is the same as CRLF. It is not. It does serve to separate words, but the meaning of this depends on the context. In a "normal" mode of evaluating and punching words, this will separate instructions which otherwise would have to be specified on one line. Expression evaluation treats words differently and just uses the last value arrived at. And macro argument reading does not pay any attention to "?". If you wish to use "?"s with macros, you can either be careful in how you define the macro (eg ask for parenthesized args), or in how you invoke it. If you don't want to spend the time reading about all the different kinds of macro arguments and specifications that MIDAS provides, just use CRLF (like MACRO). If you didn't have the MIDAS source, you may not have had the MIDAS documentation files either. This is INFO;MIDAS > on MIT-MC. (The canonical source is located in the MIT-MC MIDAS; directory, by the way.) --Ken ------- 21-Nov-84 00:32:31-PST,645;000000000000 Return-Path: Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Nov 84 00:32:21-PST Date: 21 Nov 1984 00:30 PST (Wed) Message-ID: From: Atty Mullins To: Charles Hedrick Cc: Atty@SU-CSLI.ARPA, tops-20@SU-SCORE.ARPA Subject: Would Common Lisp users please identify yourselves? In-reply-to: Msg of 20 Nov 1984 17:43-PST from Charles Hedrick Hi. We have a copy of Common Lisp at CSLI. My name is Atty Mullin ( Atty@CSLI ) and I'm responsible for keeping things up to date. atm 21-Nov-84 12:44:20-PST,511;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Nov 84 12:44:07-PST Date: Wed 21 Nov 84 12:47:20-MST From: Randy Frank Subject: Re: Crash analysis session at DECUS To: HALL@DEC-MARLBORO.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Judy Hall " of Fri 16 Nov 84 06:08:51-MST I'd like someone (Kevin?) to spend alittel time going through the tcp internals, if possible. thanks. randy ------- 21-Nov-84 17:35:37-PST,699;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Wed 21 Nov 84 17:35:13-PST Received: ID ; Wed 21 Nov 84 20:35:17-EST Date: Wed 21 Nov 84 20:35:16-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: Domain resolver update? To: tops-20@SU-SCORE.ARPA Does anyone know what the current status of the domain resolver development for TOPS-20 systems? With the release of RFC921 (Domain Implementation Schedule), we are investigating whether or not we will need to create our own domain server/resolver systems and, in particular, I am interested in finding out what is planned to be importable in the TOPS-20 world. --Vince ------- 26-Nov-84 16:29:57-PST,608;000000000000 Mail-From: G.JIN created at 26-Nov-84 16:27:58 Date: Mon 26 Nov 84 16:27:58-PST From: Tai Jin Subject: sctty% To: tops-20@SU-SCORE.ARPA I've been having trouble using the sctty% jsys. This is with v5 of the monitr. According to the documenatation, sctty% does not change the primary jfns for the process. But I have discovered that it does set them to the terminal given in the sctty% call. Furthermore, I was unable to change the primary jfns of that process with the spjfn% jsys. Is this a known problem in v5? Or am I just crazy for asking this? ...tai ------- 28-Nov-84 04:44:25-PST,853;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Nov 84 04:44:18-PST Date: 28 Nov 1984 04:45-PST Sender: BILLW@SRI-KL.ARPA Subject: PODTYP/DIABLO/etc From: William "Chops" Westfield To: tops20@SU-SCORE.ARPA Message-ID: <[SRI-KL.ARPA]28-Nov-84 04:45:53.BILLW> Now that unilogic is no longer supporting PODTYP or the equivilent (for typing scribe output on a diablo or other smart hardcopy terminal), I was wondering what other people out there are using to do this. Ideally, I would like to find something that does: 1) Output .POD files from scribe onto diablo/qume/agile/etc... 2) Do pagination/pause at end of page/etc for normal .TXT files to list them on a diablo type printer. Someone MUST have programs that do these sorts of things... Thanks Bill W 28-Nov-84 06:03:25-PST,977;000000000000 Return-Path: Received: from CMU-CS-A.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Nov 84 06:03:14-PST Date: 28 Nov 84 0853 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: William "Chops" Westfield Subject: Re: PODTYP/DIABLO/etc CC: tops20@SU-SCORE.ARPA In-Reply-To: <[SRI-KL.ARPA]28-Nov-84 04:45:53.BILLW> Message-Id: <28Nov84.085328.EN0C@CMU-CS-A.ARPA> What problems are you having? I must admit that my only interest is in CMU CS/RI people that have diablos being able to do what they currently do...maintaining the status quo or fixing bugs that are major headaches... In the long term, it is just not a wise move to commit resources to supporting devices that are not powerful print machines like laser printers... If you want information on .POD to Diablo print, I can probably help you since I recently wrote a podtype for Unix based on the PODType and ScrType programs...which happen to be written in SAIL... -Rudy 28-Nov-84 06:27:27-PST,1134;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 28 Nov 84 06:27:17-PST Date: 28 Nov 84 09:26:57 EST From: Don Subject: Re: PODTYP/DIABLO/etc To: BillW@SRI-KL.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "William "Chops" Westfield " of 28 Nov 84 07:45:00 EST Now that unilogic is no longer supporting PODTYP... Did they ever? I was under the impression that Unilogic's attitude was that they would produce a file which would make the printing device do the right thing and that it was up to you to get it to that device. The last time I had to find a .POD output program, I was put in touch with Janet Walker (JWALKER@BBNA) whom I believe worked with Brian Reid on Scribe at CMU. She directed me to PODTYP, the files for which were on her directory on XX. The files you'd want to look at are: [XX]PODTYP.* [XX]PSEUDOPOD.* [XX]SCRTYP.* I believe I had to hack PODTYP to know where to look for its help file. Let me know if you need further help on this. Don ------- 30-Nov-84 00:34:50-PST,435;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Fri 30 Nov 84 00:34:35-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA11384; Fri, 30 Nov 84 09:37:08 -0100 Date: 30 Nov 1984 09:35-EST From: T S Lande Subject: C on TOPS-20 To: TOPS-20@su-score Cc: bassen@oslo-vax Message-Id: <470651737/bassen@oslo-vax> Anybody know where to obtain a C-compiler for TOPS-20? 30-Nov-84 19:49:58-PST,4901;000000000000 Mail-From: MRC created at 30-Nov-84 19:49:51 Date: Fri 30 Nov 84 19:49:51-PST From: Mark Crispin Subject: ["#M.CONDICT" : VMS is UNIX spelled backwards (almost)] To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I thought the TOPS-20 list would be interested in this: --------------- Return-Path: Received: from BRL-TGR by SU-SCORE.ARPA with TCP; Fri 30 Nov 84 19:32:59-PST Received: from usenet by BRL-TGR.ARPA id a021617; 30 Nov 84 21:43 EST From: "#M.CONDICT" Newsgroups: net.unix-wizards Subject: VMS is UNIX spelled backwards (almost) Message-ID: <378@hou2g.UUCP> Date: 28 Nov 84 19:29:05 GMT To: unix-wizards@BRL-TGR.ARPA Reply-To: unix-wizards@BRL-TGR.ARPA Those VMS-ites who enjoy denigrating UNIX should show some respect. Virtually every feature in the early versions of VMS that made it useable (barely!) was copied from UNIX -- this is well known within the original development group, which was headed by a UNIX-lover (gasp, gasp!). In fact, Version 1.0 of VMS was a system apparently designed by concatenating the RSX-11M Operating Sys. manuals with the UNIX Version 7 manuals, then shuffling or deleting a few pages. I guess the idea was to be upward compatible with RSX while putting in all the UNIX goodies as well. Here are a few examples for your amusement: o They saw the utility of a command processor as powerful and flexible as the Bourne shell, so they tried to put one in VMS. Unfortunately, what they ended up with (DCL) was an interpreter for, roughly, a subset of FORTRAN. Whoopee! o The notion of standard input and output was implemented through the use of logical names SYS$INPUT, SYS$OUTPUT. Unfortunately, many standard commands do not read SYS$INPUT or write SYS$OUTPUT, and anyway they forgot to put any I/O redirection syntax into the shell. Very useful indeed! o Unix pipelines were implemented as VMS mailbox devices. Unfortunately, they neglected to put anything in the shell that would automatically construct such mailbox-pipelines and connect commands through them. In fact, by default, users are not even given permission to make such mailbox devices. o Tree-structured file systems are wonderful, so they just had to have them in VMS. Unfortunately, they attempted to overlay the notion on top of the RSX "two-dimensional array of directories" syntax, producing the wonderfully elegant notation "DB0:[USER.GLERP]WHATEVER.FTN;13" for a file that in UNIX would be something like "/usr/glerp/whatever.c". Also, to ensure compatibility with RSX and avoid frightening users, they restricted each name in a directory path to nine letters or digits, upper-case only, thank you very much. Oh, and they forgot to put in the device-independent, single directory tree -- every file name must be preceded by the device-name on which the file resides, unless this device is the default. Strange things are done with logical names in a futile attempt to relieve the user from knowing the full device name of various commonly used files and devices. o They weren't impressed at all with the UNIX "&" construct for invoking background processes, so they ignored it, almost. By writing a program you could get a parallel process started up, but don't ask the shell to do it for you (in fairness, they've since implemented a very badly designed "SPAWN" command, intended to serve this purpose). o As in RSX, they had a facility for getting user-supplied arguments into user-written programs. Unfortunately, as in RSX, the shell could not be induced to pass such arguments to such programs, which had to be invoked by saying "RUN program". This also, apparently, was intended to avoid frightening users, most of whom were assumed to be FORTRAN-hacking engi- neers who don't trust software anyway. The most recent time I was forced to use VMS, I promptly implemented a DCL program that provided a UNIX-like shell, with I/O redirection, "echo" and "read" commands, background processes, a history mechanism and even a rudimentary pipe-line facility. Its utility was somewhat limited by the above-described brain-damage, however, and I eventually switched to Eunice. I called the program DSH (for Dumb Shell) and it is still in use at NYU as far as I know. If I've made any statements that are not true of the latest and greatest version of VMS, it is because I escaped from VMS at Version 3.0. Please forgive any such inaccuracies and may I roast in hell for defaming DEC's finest operating system. Michael Condict ...!{allegra|decvax}!hou2g!mikec AT&T Bell Labs Holmdel, NJ ------- 3-Dec-84 08:56:20-PST,378;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Dec 84 08:55:55-PST Date: Mon 3 Dec 84 08:57:38-PST From: Ed Pattermann Subject: Disk statistics program To: su-tops-20@SU-SCORE.ARPA Does anyone have any nice simple programs for compiling disk usage statistics? Thanks, Ed ------- 3-Dec-84 10:00:54-PST,550;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Dec 84 10:00:44-PST Date: Mon 3 Dec 84 12:02:09-CST From: Clive Dawson Subject: Source to WORDS To: tops20@SU-SCORE.ARPA There is a program called WORDS floating around which allows you to access a large Spell-type dictionary via the COMND Jsys (i.e. each word is a command, so you can use ? and nicely.) Does anybody know where this program came from and/or where the source can be found? Thanks, Clive ------- 3-Dec-84 12:33:13-PST,621;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Dec 84 12:33:10-PST Date: Mon 3 Dec 84 12:35:39-PST From: Kirk Lougheed Subject: Re: Disk statistics program To: PATTERMANN@SUMEX-AIM.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Ed Pattermann " of Mon 3 Dec 84 09:10:12-PST You might try the DSKUSE program. A copy of the source is on PS: on Sierra. I believe it sorts by disk used, username, and date of last login. I've found it adequate for my needs. Kirk ------- 3-Dec-84 17:00:47-PST,431;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Dec 84 17:00:21-PST Date: Mon 3 Dec 84 17:02:12-PST From: Ed Pattermann Subject: Disk usage program wanted To: tops-20@SU-SCORE.ARPA I am looking for a nice simple disk usage program which can summarize disk statistics by account. Anyone have something like this? Thanks, Ed ------- 4-Dec-84 00:35:32-PST,1256;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Dec 84 00:34:59-PST Date: 4 Dec 84 03:36:25 EST From: Charles Hedrick Subject: in case anyone else is using our accounting software To: tops-20@SU-SCORE.ARPA I don't recall whether anyone else is using our accounting software, but if so, beware that the latest autopatch causes us to lose lots of data. Session records are now written at the drop of a hat. According to the comments, at attach, detach, and set session remark, but I have a feeling more things may do it. We had seen some duplicate session entries under old monitors (typically when a job can't be logged out - one was written at each retry). So there is code that keeps track of the start time of each job. If we see a session record with the same job number and start time as an old session record, we take it to be a duplicate, and discard it. This will no longer work. Also a session shift does seem to update the start of session, the newer things that write session entries do not do so. I am going to have to remove the duplicate record detection, as there is no longer enough reduncancy in the data to detect duplicates. ------- 4-Dec-84 14:57:18-PST,908;000000000001 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Dec 84 14:56:51-PST Date: Tue 4 Dec 84 16:58:46-CST From: Clive Dawson Subject: Using dial-out modems with TOPS-20 To: tops20@SU-SCORE.ARPA Does anybody have dial-out modems connected to a TOPS-20 system out there? I'm trying to get a call-back security system installed for use with a 20, but can't get it to work. The problem is that when the call-back unit places an outgoing call on our Vadic 3480 modem, RI isn't seen by the 20, and therefore DTR isn't raised by the front end, and therefore the carrier is never established. If we force DTR on in the modem, then things work except that we lose the ability for the 20 to hang up the line by dropping DTR. Has anybody hacked this sort of thing before and gotten it to work? Thanks, Clive ------- 4-Dec-84 19:29:56-PST,604;000000000001 Mail-From: G.EGK created at 4-Dec-84 19:29:49 Date: Tue 4 Dec 84 19:29:48-PST From: Edjik Subject: Re: Using dial-out modems with TOPS-20 To: CC.Clive@UTEXAS-20.ARPA cc: tops20@SU-SCORE.ARPA, G.EGK@SU-SCORE.ARPA In-Reply-To: Message from "Clive Dawson " of Tue 4 Dec 84 14:57:41-PST hi clive, you need the stanford patch to unhangup the fone by rasing DTR, you already have the hangup routine to drop DTR. Lemme know if someone else doesnt send the info to you and Ill dig up the origial note on blurb on how to do this. --Edjik ------- 5-Dec-84 00:03:51-PST,1112;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Dec 84 00:03:33-PST Date: Wed 5 Dec 84 00:03:46-PST From: David Roode Subject: Re: Disk usage program wanted To: PATTERMANN@SUMEX-AIM.ARPA, tops-20@SU-SCORE.ARPA cc: vivian@SRI-NIC.ARPA, hss@SRI-NIC.ARPA In-Reply-To: Message from "Ed Pattermann " of Mon 3 Dec 84 17:54:55-PST Location: EJ286 Phone: (415) 859-2774 Harry Sameshima here at NIC put a "sort by account" feature into a nice disk usage reporting program from Columbia known as "HOG." The program reports the status of a wildcard group of directories. With the "alphanumeric sort by account" option selected, the directories are sorted into account groups and a summary is printed at the end of each group. However, in keeping with the style of accounting in use on our system, the program assumes all files in a directory are charged to the account which is listed as the directory's default for login. This program is available from SRC:HOG.MAC on SRI-NIC. ------- 5-Dec-84 15:36:06-PST,388;000000000000 Mail-From: G.ELDRE created at 5-Dec-84 15:35:54 Date: Wed 5 Dec 84 15:35:54-PST From: Tim Eldredge Subject: AMAR Software. To: tops-20@SU-SCORE.ARPA Can anyone on the list please tell me something about the availability of this software. It appears from what little I know to be exactly what I need for a very pressing problem. Thanks Tim ------- 6-Dec-84 01:43:06-PST,1049;000000000001 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Dec 84 01:42:58-PST Date: Wednesday, 5 December 1984, 17:49-PST From: Ken Olum Subject: Using dial-out modems with TOPS-20 To: CC.Clive at UTEXAS-20, tops20 at SU-SCORE In-Reply-To: The message of 4 Dec 84 14:58-PST from Clive Dawson Message-ID: <841205174915.3.KDO@SPIDER.FLAIR> I have some patches to allow the KL to request the FE to set DTR on a line, but I'm not sure this will quite do what you want. If the call-back stuff isn't being originated from the 20, then how is the 20 supposed to know that it should be telling the FE to raise DTR. Maybe you can set DTR always and just toggle it in TTHNGU. My stuff is source-level patches for an old version of RSX20F, but if you have the sources and the willingness to frob with them it is very easy to deal with. DEC also had a patch a while ago where setting a line remote raised DTR -- theirs could be installed with FEDDT. Ken 6-Dec-84 06:52:52-PST,1621;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Dec 84 06:52:44-PST Date: Thu 6 Dec 84 03:06:54-CST From: Clive Dawson Subject: Attention DECUS attendees! To: tops20@SU-SCORE.ARPA Here's a final reminder to those of you who will be attending DECUS next week in Anaheim: The 36-Bit 20th Anniversary events are all scheduled for Wednesday afternoon and evening, except for the Memorabilia Exhibit and Swap. Regarding memorabilia -- if you have any interesting items of 36-Bitiana be sure to bring them along. This includes rare documents, manuals, listings, photographs, etc. The memorabilia exhibit will be in a secure location in the main exhibit area. People who lend items to the exhibit will get them back on Thursday in time for the Swap on Friday. A special request: I am trying to put together an exhibit called "Great Moments in SPR History". If you have any favorite SPR's which exhibit any special characteristic such as stupidity, brilliance, confusion, sarcasm, humor, on the part of the submitter or DEC, and you have time to dig them up, please bring them along. Don't forget the 36-Bit Magic and War Stories session. Come prepared to share your favorite yarns, hacks, and horrors. Each item will be limited to 5 minutes. Props are welcome! By the way, the Large Systems SIG has produced a really *great* 20th Anniversary Poster which will be on sale at the DECUS store. This promises to be a very hot item, so plan on getting yours early. See you next week! Clive ------- 6-Dec-84 12:40:53-PST,959;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Dec 84 12:40:46-PST Date: Thu 6 Dec 84 12:44:02-PST From: Kirk Lougheed Subject: Score's MEIS problems To: mrc@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA, tom@SU-SCORE.ARPA Score's 10MB Ethernet problems this morning were caused by someone unplugging the 10MB MEIS from its transceiver and plugging it back in again (possibly into another transceiver). The high level symptom of this action is incredibly slow connections whose data appears to be a random mix of packets going by the net. My hypothesis is that the state machine on the NI board becomes horribly confused by the temporary disconnection and has no way of recovering. A drive reset will clear this condition. The easiest way to do this is to call MEIFIX from MDDT; MEIFIX resets all MEIS controllers and interfaces on a system. Kirk ------- 8-Dec-84 00:13:23-PST,731;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sat 8 Dec 84 00:10:33-PST Date: 8 Dec 1984 00:11 PST (Sat) Message-ID: <[SRI-NIC].IAN. 8-Dec-84 00:11:09> From: Ian Macky To: TOPS-20@Score cc: Greg Satz Subject: TCOPR% fixes There are a couple nasty brainos in TCPJFN having to do with setting flags in a TCB: At DTCPSH+1 (source line) the SETONE should be SETONE TCDPU,(TCB) At DTCSUD+2 and +3 the same thing happens; two more bad SETONE's. Those were the only ones me and Greg found. The bits were being set in BUTCMD, past the filename, so it wasn't harming anything. Not that they did much good, but, eh, what can you say... 11-Dec-84 14:08:27-PST,725;000000000000 Return-Path: Received: from USC-ISIF.ARPA by SU-SCORE.ARPA with TCP; Tue 11 Dec 84 14:07:37-PST Date: 11 Dec 1984 14:08:20 PST From: MOCKAPETRIS@USC-ISIF.ARPA Subject: Re: Domain resolver update? To: Vince.Fuller@CMU-CS-C.ARPA, tops-20@SU-SCORE.ARPA cc: MOCKAPETRIS@USC-ISIF.ARPA In response to the message sent Wed 21 Nov 84 20:35:16-EST from Vince.Fuller@CMU-CS-C.ARPA We have a domain server for TOPS-20 which is available now and has been in operation on ISIF, ISIB, and SRI-NIC for some time. A resolver based on a JSYS inteface a la GTHST is under development. The code is a combination of PASCAL and macro. If you have any questions, let me know. paul ------- 13-Dec-84 07:38:54-PST,675;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Dec 84 07:38:47-PST Date: Thu, 13 Dec 84 15:40 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: %No such device - DSK*: To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: TOPS-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 If your public structure is NOT named PS: (I changed ours to BLUE: yesterday), everything seems to work pretty well EXCEPT that DSK*: is broken. Does anyone know how to fix it? - Sam - ------- 13-Dec-84 09:27:18-PST,1191;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Dec 84 09:26:59-PST Date: 13 Dec 1984 1228-EST From: Alan H. Martin To: TOPS-20 at SCORE DTN: 231-4528 Mail-Stop: MR1-2/L14 Office-location: "MR1-2/M8 (By the cat posters)" Subject: Re: %No such device - DSK*: Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12071135585.28.659.37785 at DEC-MARLBORO> Regarding: Message from SAMUELSON%LLL@LLL-MFE.ARPA of 13-Dec-84 1046-EST I don't know of a fix for this, but I hear that DSK*: is a known problem area in some monitors. Please SPR (or QAR) the problem to make sure it is tracked and fixed. Apparently it would be of particular assistance to send specific example(s) of the problem, and the exact monitor version and edit numbers. In the meantime, you may find that you can work around the problem by defining a logical name (such as "ALL:") to be "DSK*:", and using that logical name. However, while this does all good things and no bad things on *my* system, you might want to first try this during in off-hour just in case it crashes the system. /AHM -------- 14-Dec-84 12:47:50-PST,958;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Dec 84 12:47:32-PST Date: Fri 14 Dec 84 12:52:31-PST From: David Roode Subject: TOPS-20 Source Update Services To: TOPS-20@SU-SCORE.ARPA cc: GaeAnn@SRI-KL.ARPA, Polly@SRI-KL.ARPA Location: EJ286 Phone: (415) 859-2774 Been getting source updates for the release 4 version of TOPS-20 frozen for use on 2020's? Wonder why? DEC pulled a cute one. The numbers which for releases 1 through 4 meant "update service for the current version" were converted to refer to the frozen 2020 version! Furthermore, the fact was not made clear in the description for the particular order number. Mention of 2020 was obscure or only added relatively recently. Here is the change that needs to be made: if you have you want ---------- -------- Exec QT038 QT101 Monitor QT030 QT100 Both + FE QT040 QT102 ------- 14-Dec-84 16:32:19-PST,684;000000000000 Mail-From: ALMQUIST created at 14-Dec-84 16:32:16 Date: Fri 14 Dec 84 16:32:16-PST From: Philip Almquist Subject: Talking IP to Score To: su-tops-20@SU-SCORE.ARPA Problem: DEC-20's at Stanford don't seem to be able to send IP packets to Score. PUP packets are unaffected. Diagnosis: DEC-20's at Stanford try to use Score's 10MB address. Since that address is disabled the packets don't get through. Cure: Reverse the order of Score's 3MB and 10MB addresses in the NIC host table. I have asked the NIC to do that in next week's host table, but in the meantime you should do this manually on your system. Philip ------- 15-Dec-84 13:43:38-PST,457;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 15 Dec 84 13:43:34-PST Date: Sat 15 Dec 84 13:46:43-PST From: Kirk Lougheed Subject: Re: Talking IP to Score To: ALMQUIST@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Philip Almquist " of Fri 14 Dec 84 18:24:28-PST Why was Score's 10MB address disabled? Kirk ------- 15-Dec-84 20:35:12-PST,4271;000000000000 Mail-From: MRC created at 15-Dec-84 20:35:06 Date: Sat 15 Dec 84 20:35:05-PST From: Mark Crispin Subject: report from DECUS To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This DECUS was, for me, mostly to attend the various 36-bit parties and to drum up some business for my new company, Panda Programming (which for obvious commercialism reasons I won't discuss on this list!). But I did collect the following set of notes which may be of general interest. There was no flaming at this DECUS, and a lot of familiar faces were either gone or only attended on Wednesday. The product line panel was quite quiet -- nobody asked any questions or made any statements -- and was distinguished mostly by the following points: . DEC claims they are still manufacturing KL's . The official name of the "integration strategy" is now the "integration/migration strategy". This was supposedly done to satisfy customer requests. Systems Concepts showed the SC-30M at DEXPO. When I stopped by there they were running my TOPS-20 code, but hadn't quite gotten their front end to emulate a DTE correctly so only one terminal was usable. There seemed to be a general recognition by all concerned that the hardware product was great, but SC is still unable or unwilling to deal with complete system packages (which includes software). There was also the question that the only disks they support are IBM-compatible; no SMD or MASSBUS devices. The 36-bit festivities on Wednesday included a horror stories session including Clive Dawson's "Great Moments in SPR History", a trivia bowl won by the customer team, and a 36-Bit Pioneers' session which brought together many of the old-time hackers from way back. I regret to report that the audio tapes DEC made of these sessions are of mediocre to POOR quality. I listened to them on the drive back up; many places are unintelligable, especially in the trivia bowl and the pioneers' session. The same company did these as did the taping for earlier DECUS symposia, but the quality is much lower. They were also the same people who ended up doing the video taping of these sessions (using pretty much the same set of equipment I would have). I hope they did a better job on that. The 36-bit banquet included a carved pencil holder and a copy of "Tony in RH20-Land" for everybody. Several KA-10 console panels were also given away and a KA and KI console were auctioned off. I mistakenly believed that there were TWO KA consoles being auctioned and dropped out of the bidding earlier than I otherwise would have (there was only one other person bidding against me after a while...). I'm still looking; anybody have a KA console panel they want to get rid of? Pete Hurley gave a repeat of his "History of TOPS" talk, with a few more details. A good time was had by all. A mild bit of comic relief came about in the form of T-shirts. One of the attendees had made up a set of orange T-shirts which had the VAX cheshire cat inside an international "no" circle (as in "no smoking", etc.) with the inscription "I ain't afraid of no VAX" on the front and "VAXBUSTERS DECSYSTEM-20 continued" on the back. These T-shirts were a popular and hot item, in more ways than one. Apparently one of the members of the DECUS Executive Board representing the VAXen got *very* upset by these T-shirts, and wanted to have the badges pulled from any attendee caught wearing one. This was eventually straightened out, but the sellers of these T-shirts had to become much more discreet. Other than that, I really can't think of much that happened. DEC announced all the wonderful hardware and software things they are doing to 36-bits to a customer base that basically had stopped caring. There was some attempt to get some "new features" type of menu items called to people's attentions, but mostly people were there to party and say goodbye. The theme of this symposium for the 36-bit people is best expressed in the LCG poster: "Digital's 36-Bit Systems: Nobody Did It Better." -- Mark -- ------- 15-Dec-84 21:16:12-PST,1948;000000000000 Mail-From: MRC created at 15-Dec-84 21:16:05 Date: Sat 15 Dec 84 21:16:05-PST From: Mark Crispin Subject: Amusement: TOPS-20 vs. VMS vs. Unix To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The following comes from DECWORLD, an internal DEC publication. Most of the issue is devoted to how great LCG and its customers are. Each article usually ends withs something about "...and now we're giving them integration...". Digital pats itself on the back. One of the questions that comes up all the time is: How enthusiastic is our support for UNIX? UNIX was written on our machines and for our machines many years ago. Today, much of UNIX being done is done on our machines. Ten percent of our VAXs are going for UNIX use. UNIX is a simple language, easy to understand, easy to get started with. It's great for students, great for somewhat casual users, and it's great for inter- changing programs between different machines. And so, because of its popularity in these markets, we support it. We have good UNIX on VAX and good UNIX on PDP-11s. It is our belief, however, that serious profess- ional users will run out of things they can do with UNIX. They'll want a real system and will end up doing VMS when they get to be serious about programming. With UNIX, if you're looking for something, you can easily and quickly check that small manual and find out that it's not there. With VMS, no matter what you look for -- it's literally a five-foot shelf of documentation -- if you look long enough it's there. That's the difference -- the beauty of UNIX is it's simple; and the beauty of VMS is that it's all there. The most ironic thing is another article that starts with "One architecture, one software system". ------- 17-Dec-84 12:30:39-PST,1315;000000000000 Return-Path: Received: from SANDIA-CAD.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Dec 84 12:30:26-PST Date: Mon 17 Dec 84 13:30:43-MST From: Tom Linnerooth Subject: Re: %No such device - DSK*: To: SAMUELSON%LLL@LLL-MFE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "SAMUELSON%LLL@LLL-MFE.ARPA" of Thu 13 Dec 84 08:52:44-MST Return-Path: <@SU-SCORE.ARPA:SAMUELSON%LLL@LLL-MFE.ARPA> Received: from SU-SCORE.ARPA by SANDIA-CAD.ARPA with TCP; Thu 13 Dec 84 08:52:37-MST Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Dec 84 07:38:47-PST Date: Thu, 13 Dec 84 15:40 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: %No such device - DSK*: To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: TOPS-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 If your public structure is NOT named PS: (I changed ours to BLUE: yesterday), everything seems to work pretty well EXCEPT that DSK*: is broken. Does anyone know how to fix it? - Sam - ------- I send an SPR to DEC in March, 1983 addressing the DSK*: problem if PS is not named PS:. The SPR has not been answered yet. Tom ------- 17-Dec-84 13:58:56-PST,1048;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Dec 84 13:58:44-PST Date: Mon 17 Dec 84 16:59:13-EST From: John T. Wroclawski Subject: Re: %No such device - DSK*: To: Linnerooth@SANDIA-CAD.ARPA cc: SAMUELSON%LLL@LLL-MFE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Tom Linnerooth " of Mon 17 Dec 84 15:39:34-EST DEC took a shot at fixing the DSK*: problem in the AP8 monitor, but backed out of the edit. Fixing this in the general case requires some care with JSB string space storage (re)allocation, maybe that baffled someone. IF your PS-that-isn't-called-PS has 4 characters or less in the name (like BLUE), you can "fix" this by patching the literal referenced at STRDEV+5 (move t2,literal-address) to contain the name of your PS in ASCIZ. (It should have PS now). The code counts on the literal being ASCIZ and one word long, so it won't work if the structure name has 5 or 6 characters in it. Kludge, Kludge... ------- 24-Dec-84 20:40:40-PST,584;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Dec 84 20:40:31-PST Date: 24 Dec 84 23:42:12 EST From: Jon Solomon Subject: telnet bug in release 5.4 of TOPS-20 To: tops-20@SU-SCORE.ARPA When I'm telnetting to BBNCCA (a V7 unix system at BBN), randomly I get repeated lines of text that type out on my screen. this can be annoying, especially when you are using emacs and it duplicates several lines of text and messes up the display. Repainting the screen only makes it worse. Sigh, --JSol ------- 25-Dec-84 12:03:56-PST,830;000000000000 Mail-From: MRC created at 25-Dec-84 12:03:48 Date: Tue 25 Dec 84 12:03:48-PST From: Mark Crispin Subject: Re: telnet bug in release 5.4 of TOPS-20 To: JSol@RUTGERS.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Jon Solomon " of Mon 24 Dec 84 23:42:12-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Why was this message sent to the entire TOPS-20 list? First, the bug isn't a TOPS-20 or TOPS-20 TELNET bug at all; it's a well-known bug in the Unix Telnet server! Second, if the bug were in the TOPS-20 software there are only a few people (most notably Paetzold and myself) who are in a position to fix the bug, so why bother the 100+ people on this list who can't? -------